Predmet: Baze podatka, SQL, MySQL (2+2) dr Milovan Milivojevićvpts.edu.rs/nastavni-materijali/milovanmilivojevic/Baze... · 2020. 3. 10. · Normalizacija baze podataka je tehnika

АКАДЕМИЈА СТРУКОВНИХ СТУДИЈА ЗАПАДНА СРБИЈА

Базе података, SQL, MariaDB др Милован Миливојевић

1

Predmet: Baze podatka, SQL, MySQL (2+2)

dr Milovan Milivojević

Elementi teorije / DATABASE - Osnovi Client/Server arhitekture

Izvor: https://mariadb.com/kb

Izvor: https://mariadb.com/kb/en/database-theory/

БЛОК 1. / (15:00 - 18:30)

What is a database?

Exploring Early Database Models

Before the advent of databases, the only way to store data was from unrelated files.

Programmers had to go to great lengths to extract the data, and their programs had to perform complex parsing and relating.

Without a standard way to access data, systems are:

• more prone to errors,

• are slower to develop, and

• are more difficult to maintain.

❖ Data redundancy (where data is duplicated unnecessarily) and

❖ Poor data integrity (where data is not changed in all locations, leading to wrong or outdated data being supplied)

are frequent consequences of the file access method of data storage.

https://mariadb.com/kbhttps://mariadb.com/kb/en/database-theory/



2

For these reasons, database management systems (DBMSs) were developed to provide a:

✓ standard and

✓ reliable way to access and update data.

They provide an intermediary layer between the application and the data, and the programmer is able to concentrate on developing the application, rather than worrying about data access issues.

A database model is a logical model concerned with how the data is represented.

Instead of database designers worrying about the physical storage of data, the database model allows them to look at a higher, more conceptual level, reducing the gap between the real-world problem for which the application is being developed and the technical implementation.

There are a number of database models.

The next three common models are;

the hierarchical database model

the network database model and

the relational database model (MariaDB, along with most modern DBMSs).

Understanding the Hierarchical Database Model

The earliest model was the hierarchical database model, resembling an

upside-down tree.

Files are related in a parent-child manner, with each parent capable of

relating to more than one child, but each child only being related to

one parent.

https://mariadb.com/kb/en/understanding-the-hierarchical-database-model/https://mariadb.com/kb/en/understanding-the-network-database-model/



3

This model, although being a vast improvement on dealing with

unrelated files, has some serious disadvantages.

It represents one-to-many relationships well (one parent has many

children; for example, one company branch has many employees), but

it has problems with many-to-many relationships.

Relationships such as that between a product file and an orders file

are difficult to implement in a hierarchical model.

Also, the hierarchal model is not flexible because adding new

relationships can result in wholesale changes to the existing

structure, which in turn means all existing applications need to change

as well.



4

This is not fun when someone has forgotten a table and wants it

added to the system shortly before the project is due to launch!

And developing the applications is complex because the

programmer needs to know the data structure well in order to

traverse the model to access the needed data.

When accessing data from two related tables, you only need to know the

fields you require from those two tables.

In the hierarchical model, you’d need to know the entire chain between the

two. For example, to relate data from A1 and D4, you’d need to take the

route: A1, B1, C3 and D4.

Understanding the Network Database Model

The network database model was a progression from the hierarchical

database model and was designed to solve some of that model's problems,

specifically the lack of flexibility.

Instead of only allowing each child to have one parent, this model allows

each child to have multiple parents (it calls the children members and

the parents owners).

It addresses the need to model more complex relationships such as the

orders/parts many-to-many relationship mentioned in the hierarchical

article.

https://mariadb.com/kb/en/understanding-the-hierarchical-database-model/https://mariadb.com/kb/en/understanding-the-hierarchical-database-model/https://mariadb.com/kb/en/understanding-the-hierarchical-database-model/https://mariadb.com/kb/en/understanding-the-hierarchical-database-model/



5

As you can see in the figure below, A1 has two

members, B1 and B2. B1. is the owner of C1, C2, C3 and C4. However, in

this model, C4 has two owners, B1 and B2.

Of course, this model has its problems.

It is more difficult to implement and maintain, and, although more

flexible than the hierarchical model, it still has flexibility problems,

Not all relations can be satisfied by assigning another owner, and the

programmer still has to understand the data structure well in order to

make the model efficient.



6

Osnovno o relacionim bazama

Most databases today are relational databases, named such because they deal

with tables of data related by a common field. For example, Table 1 below shows

the product table, and Table 2 shows the invoice table. As you can see, the

relation between the two tables is based on the common field product_code.

SQL (Structured Query Language) is a powerful way to search for records or

make changes.

Almost all DBMS’s use SQL, although many have added their own

enhancements to it.

This means that when you learn SQL while using MariaDB, almost all of it is

not specific to MariaDB and can be used with other relational databases as

well, such as PostgreSQL, MySQL, Oracle and SQL Server. MariaDB was

originally-created as a drop-in replacement to MySQL, so MariaDB and

MySQL are particularly close.



7

Database Normalization Overview

Normalizacija baze podataka je tehnika koja pomaže da se izbegnu

anomalije podataka i različiti problemi upravljanja podacima.

Razvijena je 1970-te godine od strane E.F. Cood-a i danas predstavlja

uobičajeni zahtev za savremene relacione DBMS.

Edgar Frank "Ted" Codd (19 August 1923 – 18 April 2003) was an English computer scientist who, while working for IBM, invented the relational model for database management, the theoretical basis for relational databases and relational database management systems. He made other valuable contributions to computer science, but the relational model, a very influential general theory of data management, remains his most mentioned, analyzed and celebrated achievement.

Initially, IBM refused to implement the relational model to preserve revenue from IMS/DB[citation needed]. Codd then showed IBM customers the potential of the implementation of its model, and they in turn pressured IBM. Then IBM included in its Future Systems project a System R subproject – but put in charge of it developers who were not thoroughly familiar with Codd's ideas, and isolated the team from Codd.[citation needed] As a result, they did not use Codd's own Alpha language but created a non-relational one, SEQUEL. Even so, SEQUEL was so superior to pre-relational systems that it was copied, in 1979, based on pre-launch papers presented at conferences, by Larry Ellison, of Relational Software Inc, in his Oracle Database, which actually reached market before SQL/DS – because of the then-already proprietary status of the original name, SEQUEL had been renamed SQL.

Codd continued to develop and extend his relational model, sometimes in collaboration with Christopher J. Date. One of the normalised forms, the Boyce–Codd normal form, is named after

him.

Normalizacija predstavlja transformaciju tabele kroz različite forme:

✓ Prva normalna forma,

✓ Druga normalna forma,

✓ Treća normalna forma itd...

https://en.wikipedia.org/wiki/Computer_sciencehttps://en.wikipedia.org/wiki/International_Business_Machineshttps://en.wikipedia.org/wiki/Relational_modelhttps://en.wikipedia.org/wiki/Relational_modelhttps://en.wikipedia.org/wiki/Databasehttps://en.wikipedia.org/wiki/Relational_databasehttps://en.wikipedia.org/wiki/Relational_database_management_systemhttps://en.wikipedia.org/wiki/Relational_database_management_systemhttps://en.wikipedia.org/wiki/Computer_sciencehttps://en.wikipedia.org/wiki/IMS/DBhttps://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttps://en.wikipedia.org/wiki/IBM_Future_Systems_projecthttps://en.wikipedia.org/wiki/IBM_System_Rhttps://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttps://en.wikipedia.org/wiki/Alpha_(language)https://en.wikipedia.org/wiki/Larry_Ellisonhttps://en.wikipedia.org/wiki/Oracle_Databasehttps://en.wikipedia.org/wiki/IBM_SQL/DShttps://en.wikipedia.org/wiki/SQLhttps://en.wikipedia.org/wiki/Christopher_J._Datehttps://en.wikipedia.org/wiki/Database_normalizationhttps://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_form



8

Cilj normalizacije tabela:

• Izbegavanje redudanse podataka (i time posledično prostora koji u

memoriju zauzimaju);

• Lakša izmena podataka i i zbegavanje anomalija;

• Lakše odršavanje referencijalnog integriteta;

• Stvaranje lako razumljive strukture podataka koja jako podseća na

ono što podaci uistinu predstavljaju;

• Stvaranje podloge za lakše proširenje baze podataka.

Navodi se primer, najpre bez normalizacije da bi se razumeli problemi i

potreba za normalizacijom a potom postupak vođenja tabela kroz faze

normalizacije.

Priemer: BAZA PODATAKA - podaci o biljkama, lokaciji i tlu



9

Podaci pretvoreni u tabelarni formart imaju oblik:

Kako ove podatke unetu u tabele baze podataka? Tabelarni prikaz iznad

morao bi se pretvoriti u tabelu ispod (NULL označava vrednosti gde ne

postoje podaci:

Prethodna tabela nije previše korisna. Na primer, za biljku Erica, na osnovu tabele

iznad ne može se odrediti na kojoj je lokaciji se nalazi.

Takođe nijedna od kolona (polja) ne može biti primarni ključ (potrebno je da

primarni ključ jednoznačno identifikuje zapis).

Dakle, zapis (record), ne može pripadati grupi, već se mora posmatrati

samostalno, pojedinačno. Ovo vodi ka sledećem obliku:



10

Polje Location code, ne može biti primarni ključ ali kombinacija polja Location

code/ Plant Code, može jer na jedinstven način identifikuje zapise (redove).

Kada je neki tip biljke identifikovan na nekoj lokaciji, takvu infomaciju kao podatke

dovoljno je uneti samo jednom. Ako bi bilo potrebno dodati broj biljaka na toj

lokaciji dodavalo bi se polje količina (quantity).

Prethodna tabela jeste u tabelarnom formatu i može se definisati primarni ključ,

ali ona još uvek ima problema! Na primer: Kod 11, koji referencira na

Kirstenbosch Garden javlja se tri puta! Pored gubitka prostora, javljaju se i drugi

ozbiljni problemi! (Pogledati pažljivo tabelu ispod)

U drugom redu umesto Kirstenbosch Garden piše Kirstenbosc Garden.

Kako to primetiti ako tabela ima hiljade redova? Sa porastom tabele drastično

raste šansa ka anomalijama podataka.

Potrebno je pokušati UKLONITI DUPLIKATE!



11

Kako?

Potrebno je uočiti polja koja predstavljaju primarni ključ.

A potom kreirati nove tabele u kojima su polja koja se odnose na delove

primarnog ključa:

• Prva tabela, koja sadrži polja koja su vezana za Location code deo iy

primarnog ključa

• Druga tabela, koja sadrži polja koja su vezana za PlantCode deo iz

primarnog ključa

Koja su poboljšanja?



12

• Nazivi lokacija se pojavljuju samo jednom (Kirstenbosch Garden), pa je

monogo veća šansa da se uoče potencijalne greške (na primer, sintaksne!);

• Smanjuje se zauzeće memorije jer se ne ponavlja memorisanje

Kirstenbosch Garden više puta;

• Vidi se da se polja Location code i Plant Code ponavljaju u dve tabele. Ova

polja obezbedjuju da se može uspostaviti relacija među tabelama, odnosno

da grupišete različite biljke na različitim lokacijama. Očigledno je da se ne

može izbeći ponavaljanje ovih polja a da se ne izgubi mogućnost

uspostavljanja relacija. Ali ovo je mnogo efikasniji način. Lakše je ponoviti i

memorisati male kodove nego čitave sentence veliki broj puta. Efikasnije je!

Ipak prethodne tri tabele isu idealne!

✓ U polju Soil description (tabela biljaka) ponovo se javlja redudansa

(sandstone/limestone):

Takođe se krije još potencijalnih mogućnosti za anomalije!

✓ Moguće je da korisnik u polju Soil descrition za kategoriju B, umesto

Sandstone/limestone unese za biljku Restio samo Sandstone:



13

***

Ponovo je rešenje izdvajanje podataka u posebnu tabelu.

Ono što je u stvari urađeno je da se tragalo za tranzitivnim vezama u kojima

su polja, koja nisu u primarnom ključu u vezi sa drugim poljima, koja takođe

nisu u primarnom ključu.



14

Soil description zavisi (u nekom smislu) od Plant code ako se gleda tabela ***, ali

Soil description prvenstvenono zavisi od Soil category, tako da se Soil

description može izdvojiti u posebnu tabelu.

Prethodnim konceptom ponovo se smanjuje šansa da se za kategoriju zemljišta B,

stavlja jednom Sandstone/limestone a drugi put samo Sandstone i sl.

Podatak o opisu zemljišta se unosi samo jednom u posebnoj tabeli i time se

povećava šansa da podaci budu tačni.

Kada se dizajniraju baze, često test podaci često nisu kompletirani, ali i ne moraju

biti ako se razumeju dobro odnosi medju podacima.

Prethodni tekst imao je za cilj da ukaže na probleme skladištenja podataka u

tabele koje nisu normalizovane ali i da ukaže na relacije među poljima. To je

razlog i osnova procesa normalizacije.



15

Database Normalization: 1st Normal Form

Primer: BAZA PODATAKA - podaci o biljkama, lokaciji i tlu

NULTA NORMALNA FORMA

Struktura podataka je:

• Location code

• Location name

• 1-n plant numbers (1-n is a shorthand for saying there are many occurrences of this field. In other words, it is a repeating group).

• 1-n plant names

• 1-n soil categories

• 1-n soil descriptions

Pretvaranje u tabelarni format



16

Nema ključeva, postojanje grupa ...

Tables are in 1st normal form if they follow these rules:

• There are no repeating groups.

• All the key attributes are defined.

• All attributes are dependent on the primary key.

Podaci transformisani iz NULTE noramalne forme u tabelu u

PRVOJ NORMALNOJ FORMI

• Definisati primarni ključ (u ovom primeru Location code/ Plant code)

• Poštovati princip atomičnosti podataka (the principle of atomicity) /

primer: umesto polja-ImePrezima, kreirati posebno polje-Ime i polje-

Prezime.



17

Konačni oblik strukture Tabele u PRVOJ NORMALNOJ FORMI.

###

Polja koja čine primarni ključ su italic.

Database Normalization: 2nd Normal Form A table is in 2nd normal form if:

• it is in 1st normal form

• it includes no partial dependencies (where an attribute is only dependent

on part of a primary key)

Ako se primarni ključ tabele koja je u PRVOJ NORMALNOJ FORMI, sastoji samo od

JEDNOG polja onda je ta tabela AUTOAMTSKI i u DRUGOJ NORMALNOJ FORMI

Tabela kod koje se primarni ključ sastoji od više polja, je u PRVOJ NORMALNOJ

FORMI sadrži atrubute koji zavise od dela PRIMARNOG ključa (parcijalna

zavisnost) (###).

Zbog toga se tabele iz PRVE NORMALNE FORME prevode u oblik više tabela

DRUGE NORMALNE FORME, koje ne sadrže parcijalnu zavisnost.



18

Primer za bazu BILJAKA:

Rezultujuće tabele su u DRUGOJ NORMALNOJ FORMI.



19

Database Normalization: 3rd Normal Form

Skup tabela u DRUGOJ NORMALNOJ FORMI

A table is in 3rd normal form if:

• it is in 2nd normal form

• it contains no transitive dependencies (where a non-key attribute is

dependent on the primary key through another non-key attribute)

Ako tabela sadži samo jedna ne-ključi atribut, onda oa ne može imati tranzitivnu

zavisnost. U takvim slučajevima tabela koja je u DRUGOJ NORMALNOJ FORMI je

automatski i u TREĆOJ NORMALNOJ FORMI.



20

Dalje ...

Plant name is not dependent on either soil category or soil description. Nor is soil

category dependent on either soil description or plant name.

However, soil description is dependent on soil category.

Tako da se postupa kao ranije ….polja se razdvajaju u dve tabele …

Plant table with soil description removed

Plant location table remains unchanged

The new soil table

Location table remains unchanged

Ovo bi važilo za sve tabele u bazi. U Tekućem primeru tabele Plantt Location table

i Location table su već u TREĆOJ NORMALNOJ FORMI.

Sada su sve tabele na prethodnoj slici u TREĆOJ NORMALNOJ FORMI.



21

Treća ormalna forma je uobičajeno dovoljna za najveći broj tabela sa kojima se

operiše u bazama podataka, jer se kroz ovu formu izbegava največi broj

anaomalija koji se mogu sresti kod podataka.

Dakle, predalže se da se pre implementacije tabela u procesu razvoja baza

podataka većina tabela predive u TREĆU NORMALNU FORMU, jer se time u

velikom obimu ostvaruju ciljevi NORMALIZACIJE.

Normalne forme izvan ovih, kao što su Boyce-Codd-ova normalna forma i

ČETVRTA NORMALNA FORMA, retko su korisne za poslovne aplikacije.

U većini slučajeva Tabele u 3. normalnom obliku ionako su već u tim normalnim

oblicima. Ali svaki vešti projektant baze podataka trebao bi znati izuzetke i po

potrebi biti u mogućnosti normalizovati tabele na više nivoe.

Database Normalization: Boyce-Codd Normal Form

Database Normalization: 4th Normal Form

Database Normalization: 5th Normal Form and Beyond

Understanding Denormalization



22

MariaDB 10.4.

Instalacija

There are several packages types, including the source code:

• Windows MSI packages

• Linux YUM packages

• Linux APT packages

• Linux and Windows binaries

• Source code

https://downloads.mariadb.org/



23

After the installation

mysql -u root -p

The following is the location for MariaDB 10.0:

C:\Program Files\MariaDB 10.0\

The MariaDB configuration file

C:\WINDOWS\my.ini

C:\WINDOWS\my.cnf

C:\my.ini

C:\my.cnf

MariaDB Security

MariaDB User Account Management



24

User privileges

The privileges or rights that we can grant to users are many and varied. They

break down into three main categories:

• Global administrative privileges

• Database, table, and column privileges

• Miscellaneous privileges



25



26



27

Using MariaDB

Running the mysql command-line client.

mysql [-u ] [-p] [-h ] []

Using a database

MariaDB [(none)]> USE test;

Database changed

MariaDB [test]>

Listing all databases on a server

MariaDB [(none)]> SHOW DATABASES;



28

Creating and dropping databases

Creating a database

CREATE DATABASE ;

Primer:

MariaDB [kamenica]> create database mona;

Query OK, 1 row affected (0.182 sec)

MariaDB [kamenica]> use mona

Database changed

MariaDB [mona]>

Dropping a database

DROP DATABASE ;



29

Primer:

DROP DATABASE mona;



30

Creating, altering, and dropping tables

Creating a table

Datatypes include things such as:

• numbers,

• text, and

• dates.

For example, if we are creating an employee table, we might decide to store an

employee ID number (number), last name (text), given names (text), preferred name

(text), birthdate (date), and so on.

We might also want to store the e-mail addresses, phone numbers, and home

addresses of the employees, but we don't want to store duplicate data, or define extra

columns that are hardly ever used, so we should put those in separate tables and then

link the records back to the appropriate employee. We do this because people often

have multiple phone numbers and e-mail addresses, and sometimes even extra home

addresses and we might want to store all of them.

The process by which we refine our table definitions is called normalization.

https://mariadb.com/kb/en/recap-the-relational-model.

dalje

https://mariadb.com/kb/en/training-tutorials/

https://mariadb.com/kb/en/training-tutorials/



31

The basic syntax of the CREATE TABLE command is as follows:



32

CREATE TABLE table_name ();

Primer:

MariaDB [mona]> create table zaposleni(

-> zaposleniID INT NOT NULL AUTO_INCREMENT PRIMARY KEY,

-> prezime varchar(100),

-> ime varchar(80)

-> );

Query OK, 0 rows affected (1.441 sec)



33

Exploring the structure of a table

Altering a table / Menjanje, dopune, preuredjivanje tabele

The basic syntax for the ALTER TABLE command is as follows:

ALTER TABLE table_name [, alter_definition] ...;

Adding a column

An attribute of an ALTER TABLE command is used to add a

column has the following pattern:

ADD [FIRST | AFTER ]

Primer:



34

Modifying a column

An alter definition of an ALTER TABLE command to modify a column has the

following pattern:

MODIFY

Primer:



35

Dropping a column

Dropping a table

DROP TABLE

Primer:

DROP TABLE zaposleni;



36

Selecting, inserting, updating, and deleting data

Inserting data

Primer:



37

Primer:



38

Updating data

Primer1:

MariaDB [mona]> UPDATE zaposleni SET

-> nadimak="Micana",datumRodjenja="2000-10-23"

-> WHERE ime="Milica" AND prezime="Kojic";


Rows matched: 1 Changed: 1 Warnings: 0

Primer2:



39

Dodavanje dva zapisa u tabelu zaposleni;



40

Deleting data

Primer:

Reading data



41

A common condition is to grab everything. This is done using an asterisk

(*) as follows:

Primer1:

Primer2:



42

Primer3:

Primer4:

Primer5:



43

We learned some basic commands which are useful when using MariaDB and

connecting with the mysql command-line client program.

We've also become familiar with the basic SQL database Create, Read, Update,

and Delete (CRUD) operations that will be part of nearly all of our interactions in

MariaDB.

Napomena> prethodna materija obradjena za 180 min (4 x 45 min.)



44

СЛЕДИ БЛОК 2. / (8:15 - 10:00')

PRIMER ZA VEZBU

MariaDB [(none)]> create database if not exists biblioteka; #kreiranje baze


MariaDB [(none)]> use biblioteka; #konekcija na bazu

Database changed

MariaDB [biblioteka]>

Kreiranje tabela: knjige, autori i serije:

Polja serijaID i autorID su polja primarnog ključa u tabelama serije i autori,

respektivno.

Ova polja su polja spoljnjeg ključa u tabeli knjige.

Unos podataka u tabelu knjige, pregled structure tabele i podataka u tabeli:



45

Dodavanje novog zapisa na kraj tabele:

MariaDB [biblioteka]> insert into knjige (naslovKnjige,serijaID, autorId)

-> value("Kad su cvetale tikve",2,4);




46

Azuriranje podataka – primer:

Prikaz dela podataka iz tabele knjige - primer



47

Dodavanje kolona u tabelu – primer:

Sada je struktura tabele:



48

Napomena: Varijable koje opisiju podatke iz familije tekstualnih podataka imaju

sledece znacenje:

• CHAR(4) - alfanumerički (tekstualni) podatak fiksne dužine od 4

karaktera

• VARCHAR(100) - alfanumerički (tekstualni) podatak maksimalne dužine

do 100 znakova

• TEXT - duzi znakovni podatak do max. 65535 znakova (bajta)

Primer: Dodavanje kolone opis u tabelu autori:

MariaDB [biblioteka]> ALTER TABLE autori add opis text after autorID;


Records: 0 Duplicates: 0 Warnings: 0

Primer: Uklanjanje kolone opis iz tabele autori:

MariaDB [biblioteka]> alter table autori drop opis;


Records: 0 Duplicates: 0 Warnings: 0

Dodavanje polja (kolona) u tabelu autori:



49

Napomene:

• As a basic convention, reserved words are printed in all capital letters.

• This isn't necessary, though. MariaDB is case-insensitive with regards to

reserved words.

• Database and table names, however, are case-sensitive on Linux. This is

because they reference the related directories and files on the filesystem.

• Column names aren't case sensitive since they're not affected by the

filesystem, per se.



50

Unosenje podataka o autorima – primer:

Ažuriranje podataka u tabeli KNJIGE:

MariaDB [biblioteka]> UPDATE knjige SET

-> izdavacID=1,godIzd=1987,opis="Roman o ljubavi, politici, intelektualna

vrteska, revoluciji u Pragu"

-> WHERE knjigaID=1;


MariaDB [biblioteka]> UPDATE knjige SET

-> izdavacID=2,godIzd=2009,opis="Srbija u srednjem veku"



Rows matched: 1 Changed: 1 Warnings: 0



51

Aktuelni sadržaj tabele knjige:

IZDVAJANJE PODATAKA - SELECT … dodatne opcije

Prosireni oblik naredbe SELECT glasi:



52

Izvor za prethodnu stranu : ***

Primer: Izdvajanje dela podataka iz tabele (sa pocetka baze)>



53

Primer: Izdvajanje dela podataka iz tabele (iz proizvoljnog dela)>



54

Primer: Izdvajanje dela podataka iz tabele uz rastuce SORTIRANJE>

Primer: Izdvajanje dela podataka iz tabele uz OPADAJUCE SORTIRANJE>

Primer: Izdvajanje dela podataka pod uslovom.



55

Tekuce stanje u tabeli autori:

Primer: Upit sa uslovom i klauzulom IN

Primer: Upit sa uslovom i klauzulom NOT IN



56

Primer: Upit sa LOGICKIM uslovom OR u klauzuli WHERE

Primer: Upit sa uslovom BETWEEN u klauzuli WHERE

Izvor za prethodni pasus:



57

Primer: Upit sa uslovom LIKE u klauzuli WHERE

Odredba GROUP BY

Izvor: ***

Opsti primer



58

Za dalji rad detaljno prouciti funkcije i njihovu upotrebu (strane 64-92) iz reference ***:



59

SLEDI generalna sintaksa naredbe SELECT

SELECT

[ALL | DISTINCT | DISTINCTROW]

[HIGH_PRIORITY]

[STRAIGHT_JOIN]

[SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]

[SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]

select_expr [, select_expr ...]

[ FROM table_references

[WHERE where_condition]

[GROUP BY {col_name | expr | position} [ASC | DESC], ... [WITH ROLLUP]]

[HAVING where_condition]

[ORDER BY {col_name | expr | position} [ASC | DESC], ...]

[LIMIT {[offset,] row_count | row_count OFFSET offset}]

procedure|[PROCEDURE procedure_name(argument_list)]

[INTO OUTFILE 'file_name' [CHARACTER SET charset_name] [export_options]

INTO DUMPFILE 'file_name' INTO var_name [, var_name] ]

[[FOR UPDATE | LOCK IN SHARE MODE] [WAIT n | NOWAIT] ] ]

export_options:

[{FIELDS | COLUMNS}

[TERMINATED BY 'string']

[[OPTIONALLY] ENCLOSED BY 'char']

[ESCAPED BY 'char']

]

[LINES

[STARTING BY 'string']

[TERMINATED BY 'string']

]



60

БЛОК 3. / (15:00 - 18:30)

SPAJANJE TABELA: JOIN

Joining Tables with JOIN Clauses

Here is a simple example of three basic JOIN types, which you can experiment

with in order to see what the different joins accomplish:

CREATE TABLE mi1 ( a INT );

CREATE TABLE mi2 ( b INT );

INSERT INTO mi1 VALUES (1), (2), (3);

INSERT INTO mi2 VALUES (2), (4);



61

SELECT * FROM mi1 INNER JOIN mi2 ON mi1.a = mi2.b;

(INNER) JOIN: Returns records that have matching values in both tables

SELECT * FROM mi1 CROSS JOIN mi2;

A CROSS JOIN produces a result set in which every row in each table is joined to

every row in the other table; this is also called a cartesian product.

In MariaDB the CROSS keyword can be omitted, as it does nothing. Any JOIN

without an ON clause is a CROSS JOIN.



62

SELECT * FROM mi1 LEFT JOIN mi2 ON mi1.a = mi2.b;

The LEFT JOIN is an outer join, which produces a result set with all rows from the

table on the "left" (t1); the values for the columns in the other table (t2) depend on

whether or not a match was found.

If no match is found, all columns from that table are set to NULL for that row.

SELECT * FROM mi2 LEFT JOIN mi1 ON mi1.a = mi2.b;

The RIGHT JOIN is similar to the LEFT JOIN, though its resultset contains all rows

from the right table, and the left table's columns will be filled with NULLs when

needed..



63

NAPOMENA: Ako ne postiji u tabeli knjige roman DOROTEJ (izdanje 2017.)

dodati zapis za izdanje romana Dorotej iz 2017.

MariaDB [biblioteka]> INSERT INTO knjige(naslovKnjige,serijaID,autorID,godIzd)

-> VALUE

-> ("Dorotej",2,3,"2017");




64

Tekuće stanje u tabelama autori i knjige:

NAPOMENA!!!: Ako tekuće stanje u tabelama nije kao u tabelama

iznad, ažurirati tabele knjige i autori po uzoru na sledeće naredbe.

INSERT INTO autori(imeAutora, prezimeAutora, porekloAutora)

-> VALUE

-> ("Dobrica","Cosic","Srbija");

ili

UPDATE knjige SET

-> izdavacID=1,godIzd=1987,opis=" Prag, ljubav, politika..."


ili

MariaDB [biblioteka]> INSERT INTO knjige(naslovKnjige, godIzd)

-> VALUE

-> ("Kad su cvetale tikve",1987);



65

Da bi mogli navesti spisak knjiga (nasloveKnjiga) po autorima, mora tablica knjiga

SPOJITI sa tablicom autora. To se moze realizovati pomocu JOIN klauzule:

Notice that the primary table from which we're drawing data is given in

the FROM clause. The table to which we're joining is given in the JOIN clause along with the commonly named column (i.e., autorID) that we're using for the join.

U prethodnom primeru prikazani su svi autori.

Ako je potrebno prikazati samo dela Milana Kundere onda je postupak sledeci:

This statement will list the titles of Kundera books stored in the database.

Notice that we've added the AS parameter next to the column name naslovKnjige to change the

column heading in the results set to Kunderine knjige. This is known as an alias.

https://mariadb.com/kb/en/join-syntax/



66

Primer sa kompletnijim JOIN izrazom:

There are a few possible ways to construct a join.

This method works if you're using a newer version of MariaDB and if both tables

contain a column of the same name and value.

Otherwise you'll have to redo the JOIN clause to look something like this:

...

JOIN autori ON autorID = rowID

...

This excerpt is based on the assumption that the key field in the autori table is not

called autorID, but rowID instead.

There's much more that can be said about joins, but that would make for a much

longer text.

U izrazu WHERE često se, radi fleksibilnosti, koriste džoker znaci:

WHERE name_last LIKE 'Dostoevsk%'

https://mariadb.com/kb/en/join-syntax/



67

PARAMETRI u naredbi SELECT

Kao što je dato u opštem prikazu, izrazi i ključna reč SELECT imaju veliki broj

parametara. Navode se neki, koji mogu biti od koristi:

DISTINCT

KLJUČNA reč DISTINCT, se koristi kada želimo da izbegnemo duplicate u prikazu.

Na primer, ako u bazi postoji više naslova SMESNE LUBAVI od Milana Kundere ali

sa razlicitim ID brojevima (jer su različite godine i/ili izdavači), a potrebno je da se

prikaze samo spisak naslova (nezavisno od izdavača i godine izdavanja onda se

može koristiti DISTINCT.

Ako je potrebno kreirati listing sa prikazima naslova D. Nenadica, onda je sintaksa

sledeca:

Ali ako je potrebno kreirati listing sa prikazima naslova D. Nenadica, ALI BEY

PONAVLJANJA onda je sintaksa sledeca:

SELECT DISTINCT naslovKnjige,

CONCAT(imeAutora,” “,prezimeAutora) AS pisac

FROM knjige

JOIN autori USING (autorID)



68

WHERE prezimeAutora = “Nenadic”

HIGH PRIORITY

Koristi se kod baza koje su veoma opterecene UPITIMA.

SELECT DISTINCT HIGH PRIORITY naslovKnjige,


FROM knjige



ORDER BY naslovKnjige;

SQL_CALC_FOUND_ROWS

Prebrajanje broja zapisa koju su u rezultatu upita - primer

SELECT DISTINCT SQL_CALC_FOUND_ROWS naslovKnjige,


FROM knjige




69


ORDER BY naslovKnjige;



70

Primer UPITA:

MariaDB [biblioteka]> SELECT knjigaID, naslovKnjige,imeAutora,

prezimeAutora

-> FROM knjige

-> RIGHT JOIN autori ON knjige.autorID = autori.autorID

-> ORDER BY autori.autorID;

The RIGHT JOIN keyword returns all records from the right

table (autori), even if there are no matches in the left table

(knjige).

(Pitanje: Zasto u rezultatu upita ne postoji knjiga „Kad su cvetale

tikve“?)

Primer UPITA ver1:

MariaDB [biblioteka]> SELECT knjigaID, naslovKnjige,imeAutora,

prezimeAutora

-> FROM knjige

-> LEFT JOIN autori ON knjige.autorID = autori.autorID




71

The LEFT JOIN keyword returns all records from the left table

(knjige), even if there are no matches in the right table (autori).

Primer UPITA ver2:

SELECT knjigaID, naslovKnjige,imeAutora, prezimeAutora

-> FROM autori

-> LEFT JOIN knjige ON knjige.autorID = autori.autorID


OBRATITI PAZNJU: LEVI I DESNI UPIT MOGU IMATI iste REZULTATE (u zavisnosti od

rasporeda tabela LEVO/DESNO u odnosu na kljucnu rec JOIN)!



72

BRISANJE ZAPISA:

Primer: brisanje knjiga …

DELETE FROM knjige

WHERE navesti uslov;

Podaci se generalno, prema tipu, mogu podeliti u sledeće grupe:

• Numerički podaci

• Tekstualni podaci (alfanumerički podaci)

• Podaci o datumu i vremenu

• Logički podaci

• Ostalo ...

БЛОК 4. / (08:00 - 10:00)

Nastavak .... Vežbe - SPOJEVI

UNUTRAŠNJI SPOJ - INNER JOIN ***

Primer:

INNER JOIN ima isto dejstvo kao JOIN.



73

ILI umesto INNER JOIN pomocu naredbe WHERE

SELECT knjigaID, naslovKnjige, godIzd, imeAutora, prezimeAutora

-> FROM knjige, autori

-> WHERE knjige.autorID=autori.autorID;

Dodavanje TABELE izdavaci

MariaDB [biblioteka]> create table izdavaci(

-> izdavacID INT NOT NULL AUTO_INCREMENT PRIMARY KEY,

-> nazivIzdavaca varchar(100),

-> adresaIzdavaca varchar(50),

-> lokacijaIzdavaca varchar(50));



74

Struktura tabele izdavaci:

Dodavanje dva polja u tabelu izdavaci:

INSERT INTO izdavaci(izdavacID, nazivIzdavaca, adresaIzdavaca,lokacijaIzdavaca)

-> VALUES

-> (1, "Laguna","Krunska 34", "Beograd"),

-> (2, "Matica Srpska","Dositejev trg 77", "Novi Sad");

PRIMER: Spajanje 3 tabele

IZDAVAC ---→KNJIGA



75

ILI umesto INNER JOIN pomocu naredbe WHERE

Primer:

Primer: Dodavanje izdvaca ramanu “Na zapadu nista novo”

UPDATE knjige SET

-> izdavacID=1,

-> WHERE inaslovKnjige="Na zapadu nista novo";



76

Primer: Pregled broja knjiga po izdavacima, za izdavace koji su izdali

JEDNU i VISE knjiga

MariaDB [biblioteka]> SELECT

izdavaci.nazivIzdavaca,COUNT(knjige.autorID) AS brojKnjiga

-> FROM izdavaci,knjige

-> WHERE izdavaci.izdavacID=knjige.izdavacID

-> GROUP BY izdavaci.nazivIzdavaca

-> HAVING COUNT(knjige.autorID)>=1;



77

Primer: ALIASI za tabele / skracena imena za tabele

Dalje obnavljanje OUTER JOIN

Izvor : *** (strana 98)



78

Teorijski primer:



79

Izvor : *** (strana 102) / teorisjki primer

Rad u GUI client-u.



80

Za ucenje i treniranje:

https://www.w3schools.com/sql/

https://www.tutorialspoint.com/mariadb/mariadb_useful_resources.htm

https://www.tecmint.com/learn-mysql-mariadb-for-beginners/
https://www.w3schools.com/sql/https://www.tutorialspoint.com/mariadb/mariadb_useful_resources.htmhttps://www.tecmint.com/learn-mysql-mariadb-for-beginners/

Documents

Predmet: Baze podatka, SQL, MySQL (2+2) dr Milovan Milivojevićvpts.edu.rs/nastavni-materijali/milovanmilivojevic/Baze... · 2020. 3. 10. · Normalizacija baze podataka je tehnika