Uvod u relacione baze podataka i SQL

Uvod

U teoriji, termin "baza podataka" odnosi se na bilo kakvu organizovanu kolekciju podataka koja se čuva u elektronskom obliku, * međutim godinama unazad navedeni pojam se tipično poistovećuje sa relacionim bazama podataka, budući da su upravo relacioni sistemi za skladištenje i obradu podataka (SQL Server, Oracle, Db2, MySql, PostgreSQL - da navedemo samo neke), najrasprostranjeniji i najčešće korišćeni. **

Za prosleđivanje uputa, ili jednostavnije rečeno - za poslove administracije relacionih baza - koristi se SQL (Structured Query Language), deskriptivni (neproceduralni) jezik specifično namenjen radu sa bazama podataka.

Opšte je poznato da se baze podataka koriste u većini desktop aplikacija i na skoro svim sajtovima, da je značaj baza podataka izuzetno velik - i to je više nego dobar razlog da se u nastavku upoznamo sa relacionim bazama podataka i SQL-om.

Osnove relacionog modela

Relacionu bazu podataka (najpraktičnije) možemo shvatiti kao sistem međusobno povezanih tabela, u kome se teži što racionalnijem i što ekonomičnijem zapisu podataka.

Da bismo što bolje ilustrovali osnovnu ideju koja stoji iza relacionog modela (i takođe, principe dizajna i upotrebe relacionih baza podataka), kreiraćemo bazu podataka koja pamti informacije o prodavcima i prodaji artikala (u fiktivnoj prodavnici) i proći kroz sve korake u projektovanju.

Prva tabela sadržaće podatke o prodavcima i neće se mnogo (gotovo ni malo) razlikovati od tabele kakvu bismo za slične potrebe napravili u Excel-u:

Sa druge strane, dizajn tabele prodaja (u kojoj se u svakom slogu beleže podaci o prodaji jednog artikla), podrazumeva malo više promišljanja, pa ćemo pažljivije razmotriti kako treba organizovati ovakvu tabelu.

Za početak, pogledaćemo zašto određene formate zapisa (koji bi u ovom trenutku vrlo verovatno mogli da vam padnu na pamet) - ne treba koristiti.

Teoretski bismo mogli da (pored ostalih podataka o prodaji), beležimo samo ime i prezime prodavca:

Drugi način (koji takođe nije pravo rešenje), je da u tabeli prodaja beležimo sve podatke o prodavcu:

Prvi format zapisa ima dva nedostatka:

• pre svega, kombinacija imena i prezimena nije jedinstven podatak i ne upućuje obavezno na jednu osobu ("Petar Jovanović" može biti ime i prezime dva različita prodavca) *
• ukoliko želimo da dobijemo više informacija o prodavcu:
• u tabeli prodaja nema dodatnih podataka
• ako ručno tražimo podatke o prodavcu u tabeli prodavci, ne možemo biti sigurni da čitamo prave podatke (iz gore navedenih razloga)

Drugi format zapisa je potpun: svi podaci o prodavcu (koje inače beležimo, u tabeli prodavci) jesu zapisani - i jeste moguće razlikovati prodavce, * ali ....

U pitanju je format koji nije ni malo elegantan i pregledan (baš, baš - nimalo ), a ako bismo "skroz preterali" i podatke upisivali ručno, neelegantnosti i nepreglednosti bismo mogli dodati i povećanu mogućnost pojave grešaka.

Doduše, to važi i za prvi format (mada je manje očigledno na prvi pogled, zbog manje količine podataka), pa zapravo - u oba slučaja - krajnje nepotrebno beležimo iste podatke na dva mesta (a jasno je i to da između istih podataka u dve tabele zapravo ne postoji veza).

Potrebno je naći rešenje koje omogućava da u tabeli prodaja jedinstveni prodavac bude naveden na jednostavan, ekonomičan i nedvosmisleno prepoznatljiv način - po mogućnosti preko samo jednog podatka (a pogotovo bez navođenja (svih) detalja putem "copy-paste" metoda), a potrebno je istovremeno i da podaci o prodavcima budu ("negde i nekako") zapisani - i po potrebi dostupni.

Pošto su podaci o prodavcima već zapisani (u zasebnoj tabeli), rešenje je da svakom prodavcu pripišemo jedinstven identifikacioni broj i da potom povežemo tabele.

Primarni ključ

U tabeli prodavci, dodaćemo kolonu sa nazivom id, u kojoj će redom biti upisane celobrojne vrednosti od 1 do n, tako da svaki broj upućuje na jednog prodavca (uvek istog).

Jedinstveni podatak u okviru jednog sloga (reda) po kome je moguće prepoznati ceo slog naziva se primarni ključ.

U praksi se za primani ključ gotovo uvek koriste celobrojne vrednosti (redni brojevi) i kolona se tipično označava sa "id".

Uspostavljanje veze između tabela (sekundarni ključevi)

Pošto smo u tabeli prodavci definisali primarni ključ, potrebno je da uspostavimo vezu između tabela prodavci i prodaja.

Kada uspostavimo vezu između tabela (videćemo kasnije kako se to tehnički izvodi), u tabeli prodaja više nećemo navoditi ime i prezime prodavca (a pogotovo ne sve podatke), već samo identifikacioni broj (primarni ključ) iz tabele prodavci, što (naravno) znači da se polje prodavac_id * u tabeli prodaja nadalje popunjava podacima brojčanog (a ne tekstualnog) tipa, koji se u svakom slogu poklapaju sa primarnim ključem prodavca koji je prodao navedeni artikl.

Kada primarni ključ iz jedne tabele upotrebimo u drugoj tabeli (radi prepoznavanja podataka iz prve), takav podatak nosi naziv sekundarni ključ.

Prirodni i surogatni primarni ključevi

U prethodnim odeljcima opisali smo tipičan postupak koji podrazumeva da se za primarni ključ tabele biraju celobrojne vrednosti, međutim, iako celobrojna vrednost u polju id jeste vezana za samo jedan red (to jest, vrednosti se ne ponavljaju po redovima), broj 1 - sam po sebi - nema nikakve suštinske i prirodne veze sa osobom "Petar Jovanović" (čiji su podaci zabeleženi u prvom redu), pa možemo reći da takav podatak predstavlja surogatni (veštački) primarni ključ, a naravno - postavlja se i pitanje da li je ceo pristup optimalan.

Da li (možda) postoji podatak u okviru sloga koji na prirodan način identifikuje osobu, to jest, da li se neko od već postojećih polja javlja kao prirodni primarni ključ, koji može i formalno da se pojavi kao primarni ključ? Da li onda takvo polje (ako postoji) treba da se pojavi kao primarni ključ?

Načelno je moguće izabrati da jedan od već postojećih podataka bude primarni ključ, ali, to (razume se) može biti samo podatak koji se u okviru date kolone ne ponavlja.

U našem primeru, ime nije jedinstven podatak (više prodavaca može imati ime Petar, ili bilo koje drugo ime), prezime takođe nije jedinstven podatak (a nije ni datum rođenja).

E-mail adrese (kao što smo već naveli) zapravo jesu jedinstvene - pod uslovom da su verifikovane, međutim, u pitanju je podatak tekstualnog tipa, a tekstualni podaci se pretražuju na manje efikasan način od brojčanih.

Stoga ćemo za primarni ključ izabrati jedinstven celobrojni podatak iz kolone "id", ali - u praksi se najčešće koriste oba ključa u jednom slogu (to jest, nećemo se "odreći" prirodnog primarnog ključa zato što smo uveli veštački).

"Veštački" primarni ključ (id) je stvar prakse (većina tabela u bazama podataka ima primarni ključ celobrojnog tipa, sa nazivom "id"), a prirodni primarni ključ je tu da spreči dupliranje slogova po kolonama.

U svakom slučaju - i onda kada prepoznamo i koristimo polje koje predstavlja prirodni primarni ključ (i pri tom tabeli pridodamo veštački PK) - moramo i dalje biti pažljivi pri dodavanju slogova (to jest, svejedno je potrebno da implementiramo mehanizam koji proverava podatke).

Pri dodavanju novog prodavca u tabelu, prodavcu će id (tipično) biti dodeljen automatski (i neće imati "prirodne i suštinske" veze sa prodavcem), pa za proveru novog prodavca (u smislu toga da li prodavac sa navedenim podacima već postoji u tabeli), moramo koristiti ostale podatke.

Ako među podacima koji se koriste za upis novog prodavca postoji podatak koji predstavlja prirodan primarni ključ (JMBG, verifikovana e-mail adresa i sl), možemo proveriti da li u tabeli već postoji slog u kome je dati podatak naveden (da li već postoji prodavac sa datim JMBG-om, ili sa datom e-mail adresom), dok - ukoliko među podacima nema prirodnog primarnog ključa - zapravo nemamo načina da raspoznajemo slogove!

Entiteti i atributi

Pošto smo razumeli kako se podaci (u okviru relacionog modela) raspoređuju po tabelama, potrebno je da se upoznamo i sa nekoliko terminima koji opisuju pojave sa kojima smo se prethodno upoznali.

Entitet(i)

Pojam entiteta u bazama podataka, u opštem smislu, označava (tipično složeni) objekat, koji u datom sistemu ima značaj i koji se može nedvosmisleno odrediti i zapisati.

Entiteti iste kategorije zapisuju se u okviru jedne tabele i za svaki entitet je vezan jedinstven primarni ključ i takođe (kao što smo već videli), entiteti iz jedne tabele se mogu navoditi u drugim tabelama preko (sekundarnih/spoljnjih) ključeva.

U bazi koju projektujemo, entitet je prodavac (sledi "prevod" gornja dva pasusa):

• svaki prodavac određen je skupom pojedinačnih podataka (ime, prezime, datum rođenja i sl), to jest "nedvosmisleno je određen i zapisan"
• svaki prodavac u tabeli prodavci označen je jedinstvenim primarnim ključem
• prodavci se (kao entiteti) pojavljuju u tabeli prodaja - preko spoljnjih ključeva (a mogu se naravno pojavljivati i u drugim tabelama)

Atribut(i)

Pojam atributa označava pojedinačni podatak koji se koristi pri definisanju određenog entiteta, a u opštijem smislu, možemo reći i da atribut predstavlja jednu od zajedničkih osobina svih entiteta određene kategorije.

Da pojasnimo:

• jedan entitet ima više atributa (za prodavca: atributi su ime, prezime, datum rođenja, datum stupanja u radni odnos i sl)
• bilo koji entitet iz određene grupe entiteta (praktično, iz iste tabele) ima svaki od atributa koji su pripisani svim entitetima date kategorije: svi prodavci imaju ime i prezime (pri čemu svakog prodavca odlikuje njegovo sopstveno ime i prezime), za sve prodavce se beleži datum stupanja u radni odnos (pri čemu se za svakog prodavca beleži datum stupanja u radni odnos koji se odnosi na datog prodavca) i sl.

Tipovi relacija između entiteta

U smislu toga koliko puta se spoljni ključ iz jedne tabele može pojaviti u drugoj tabeli, razlikujemo sledeće tipove relacija:

• relacija 1:1 (jedan prema jedan) - spoljni ključ određenog entiteta iz jedne tabele, može se u drugoj tabeli pojaviti samo u jednom slogu
• relacija 1:n (jedan prema više) - spoljni ključ određenog entiteta iz jedne tabele, može se u drugoj tabeli pojaviti u više slogova
• relacija n:n (više prema više) - više entiteta iz jedne tabele može se povezati sa više entiteta iz druge tabele (preko posredničke tabele)

Relacija 1:n (jedan prema više)

Tipično se među entitetima uspostavlja relacija 1:n (jedan prema više) koja (kao što je već navedeno) podrazumeva da se entitet iz tabele T1 može (preko spoljnjeg ključa), u tabeli T2 pojaviti proizvoljan broj puta:

Kao konkretan primer možemo uzeti tabelu prodaja: jedan prodavac (entitet iz tabele prodavci) može se pojaviti u više slogova u tabeli prodaja.

Relacija 1:1 (jedan prema jedan)

Relacija 1:1 nije uobičajena kao 1:n, ali se svakako pojavljuje (dovoljno često). Ovoga puta, svaki entitet iz tabele T1 može se u tabeli T2 pojaviti samo jednom:

Kako konkretan primer, zamislićemo bazu podataka u kojoj se beleže podaci u okviru određene sportske lige: ako, na primer, zamislimo da svaki klub (entitet iz tabele klubovi) može imati samo jednog glavnog trenera i da svaki glavni trener (entitet iz tabele osoblje) ima pravo da trenira samo jedan klub, možemo zamisliti i tabelu treneri (preko koje je zabeleženo koji trener trenira koji klub); tabela treneri je sa druge dve navedene tabele povezana relacijama 1:1.

Relacija n:n (više prema više)

Što se tiče relacije n:n (više prema više), razmotrićemo verovatno najtipičniji primer ovakve veze: povezivanje glumaca sa filmovima u kojima su se pojavljivali.

Ako kao entitete zamislimo glumce i filmove (kojima odgovaraju tabele glumci i filmovi), ostaje pitanje gde i kako (u kom formatu) zabeležiti podatke o tome u kojim filmovima se određeni glumac pojavljivao (ili - koji glumci su se pojavili u određenom filmu).

Intuitivno možete zaključiti da bi pokušaj da (na primer), u tabeli glumci, u jednom slogu navedemo sve filmove koji se vezuju za glumca, veoma podsećao na "pokušaj" (koji smo videli ranije) da u tabeli prodaja navedemo sve podatke o prodavcu.

Za sada je najbitnije znati da se podaci ne mogu na efikasan način povezati preko jedne tabele, to jest, da je potrebna posrednička tabela. Međutim, budući da zadatak nije skroz trivijalan, detaljniju diskusiju o implementaciji relacije n:n ćemo ostaviti za kasnije, jer smatramo da je potrebno da se prvo detaljnije upoznamo sa ostalim osnovnim odrednicama baza podataka (i takođe sa SQL sintaksom), da bismo što bolje razumeli kako (i pre svega - zašto) se n:n relacije implementiraju na specifičan način koji ćemo opisati (ali bez brige, nije ni iz daleka komplikovano).

Struktura relacione baze i organizacija podataka

Da bi baza podataka bila u stanju da korisnicima na brz i efikasan način ponudi korisne informacije (a svakako je upravo to svrha relacionih i drugih baza podataka), potrebno je da tabele budu pravilno koncipirane i pravilno strukturirane i takođe - potrebno je koristiti efikasne upite.

Za početak, pozabavićemo se strukturom tabela.

Tabela, polje, slog

Tabela je sistem međusobno povezanih ćelija (raspoređenih u redove i kolone), u koje se upisuju podaci (o određenoj kategoriji entiteta).

Pojedinačna ćelija naziva se "polje":

Polje je odrednica koja se koristi i za celu kolonu (budući da cela kolona sadrži polja istog tipa):

Ceo red naziva se "slog":

U svakoj tabeli, slog predstavlja jedan složeni podatak (jedan entitet), pa tako u tabeli prodavci svaki red sadrži sve podatke koje beležimo o jednoj osobi (što znači da cela tabela sadrži podatke o osobama); podaci o osobama koje učestvuju u prodaji se (nadalje) ne zapisuju direktno u drugim tabelama (što bi samo povećalo memorijsko zauzeće i mogućnost pojave grešaka), već se po potrebi koriste podaci iz tabele prodavci (preko ključa) - kao što smo već ustanovili.

Svaki od podataka u jednom slogu pripada određenom (prigodno odabranom) tipu podataka: primarni ključ je (gotovo uvek) celobrojna vrednost, a ostali podaci se mogu zapisivati kao: brojevi, tekst, datumi (u posebnom formatu), boolean vrednosti (true i false) i sl.

Atomski podaci

Budući da je tabela u bazi podataka namenjena zapisivanju kolekcija složenih podataka (tako da se u svakom slogu pojavljuje jedan entitet), jedno od osnovnih pitanja je: kako (tačno) treba organizovati (odnosno zapisati) podatke u okviru jednog sloga.

Ako bismo u tabeli prodavci za zapis podataka (u svakom slogu) odredili svega dva polja: id (int) i osoba (text), prva kolona bi sadržala redni broj, dok bismo u drugu upisivali "sve ostale" podatke, što bi (na primeru jednog sloga) imalo sledeći oblik:

		
id:    1
osoba: "Jovan Petrović, Ruzveltova 25, 41 godina, Mašinski inženjer, jocapet79@gmail.com"
		
	

Nije teško intuitivno zaključiti da u gornjem zapisu "nešto ne štima", iako deluje da je u tehničkom smislu sve u redu.

U smislu efikasne obrade, prethodni format zapisa ne pomaže ni najmanje: ukoliko je potrebno doći do nekog od "unutrašnjih" podataka, moramo (umesto da podatak pročitamo neposredno), proći kroz nisku znakova (polje osoba je samo obična niska) i izdvojiti delove koji nas zanimaju (a ukoliko izdvojeni podatak nije tekstualnog tipa, izvesna količina procesorskog vremena biće utrošena i na konverziju podatka iz tekstualnog u brojčani zapis).

Umesto zapisa preko (jedne) niske, složeni podaci se dele na "atome" (podatke koji se ne mogu dalje usitnjavati) i za svaki podatak se (kao što smo već nagovestili) koristi odgovarajući tip.

U tabeli koju projektujemo, za id treba izabrati celobrojni tip, a za ime, prezime i e-mail - niske. Za datum ćemo koristiti specijalizovani tip podatka (datetime), koji nije običan tekst, već podatak brojčanog tipa.

Sada možemo definisati mnogo praktičniji format tabele prodavci:

		
polje           | vrednost            | tip podatka
-----------------------------------------------------
id:             | 1                   | celobrojni
ime:            | Jovan               | niska znakova  
prezime:        | Petrović            | niska znakova
ulica:          | Ruzveltova          | niska znakova
broj:           | 25                  | celobrojni
datum_rodjenja: | 18.08.1979.         | datum
zanimanje:      | Mašinski inženjer   | niska znakova
email:          | jocapet79@gmail.com | niska znakova
		
	

Obrada podataka - Upiti i osnove SQL-a

Rad sa bazama podataka podrazumeva korišćenje tekstualnih komandi, bilo da bazama pristupamo preko programa koji dolaze uz RDBMS (konzolni program, web aplikacija), ili preko programskih jezika, pa je stoga neophodno dobro se upoznati sa sa SQL sintaksom.

U praksi, SQL sintaksa nije univerzalna i svaki RDBMS ima svoju sintaksu, * ali srećom, međusobne razlike u većini situacija nisu velike i suštinske, već je svaka konkretna SQL implementacija svojevrsna "varijacija na temu" i u svemu ima mnogo više sličnosti nego razlika.

Pojam upita u bazama podataka

Upit je niz tekstualnih komandi (praktično, omanja skripta), preko kojih se od baze zahteva određeni vid obrade podataka: kreiranje nove baze ili nove tabele u postojećoj bazi, unos podataka, čitanje, izmena, brisanje, dodavanje ili uklanjanje kolona (a postoje i određene komande koje prevazilaze okvire ovog članka, te im nećemo posvećivati pažnju).

Upiti se pokreću upisivanjem (unapred definisanih) komandi programskog jezika SQL.

SQL (Structured Query Language) - osnovne postavke

SQL (Structured Query Language) je deskriptivni programski jezik koji se, u sistemima za upravljanje bazama podataka, koristi za prosleđivanje upita i pošto je u pitanju pristup koji se razlikuje od proceduralnih jezika, napravićemo malu digresiju i objasniti razliku.

Jezici u kojima je potrebno detaljno opisati postupak za rešavanje određenog problema (primer takvog jezika je C), pripadaju kategoriji proceduralnih programskih jezika.

Nasuprot tome, deskriptivni jezici (deskripcija = opis) koriste se za opisivanje (prirode) problema, korišćenjem unapred definisane sintakse - pri čemu se ne opisuje procedura za rešavanje problema.

Na primer: U SQL-u, pri pozivanje upita za čitanje tabele, korisnik navodi tip upita (čitanje), naziv tabele i po potrebi ograničenja i uslove ("učitati i prikazati podatke iz tabele 'xyz', ali, samo podatke koji se odnose na jun 2020."), posle čega sistem pristupa pronalaženju podataka i prikazuje rezultat korisniku.

U nastavku ćemo prikazati upite preko kojih se može kreirati baza koju smo u uvodnim poglavljima koristili kao primer, s tim da ćemo se prvo upoznati (ukratko) sa konkretnim DBMS sistemom koji ćemo koristiti (a to je, kao što smo već nagovestili - MySql).

Kratak uvod u MySql

MySql je open-source sistem za upravljanje bazama podataka koji se može instalirati samostalno, a dolazi i uz XAMPP, paket aplikacija o kome smo pisali u članku o pokretanju lokalnog web servera.

U pitanju je kvalitetan i jednostavan * DBMS koji se koristi na brojnim sajtovima i omogućava veliku brzinu i efikasnost u obradi podataka.

Za isprobavanje primera iz članka, pokrenite XAMPP (pokrenite servise Apache i MySql) i u browseru unesite adresu:

		
localhost/phpmyadmin
		
	

.... čime se pokreće web aplikacija preko koje se može pristupati bazama podataka na sistemu.

Kreiranje baze preko upita (CREATE DATABASE)

Da bismo mogli da prosleđujemo upite, potrebno je pokrenuti prozor za upis SQL upita (uz MySql dolazi i "pravi" konzolni program, ali, uvažićemo da je rad u grafičkom okruženju ipak udobniji za početno upoznavanje) ....

Novu bazu možemo kreirati preko sledećeg upita:

		
CREATE DATABASE prodaja;
		
	

Prethodni upit poslužiće sasvim dobro, ali, ako želimo da budemo skroz "zvanični", možemo koristiti nešto potpuniji upit ....

		
CREATE DATABASE IF NOT EXISTS prodaja
	CHARACTER SET utf8
	COLLATE utf8_general_ci;
		
	

.... koji će biti izvršen samo ukoliko baza sa navedenim imenom ne postoji (a usput smo definisali i metod enkodiranja znakova koji dozvoljava unos ćiriličnih i latiničnih znakova).

Kreiranje tabela preko upita (CREATE TABLE)

Pošto smo kreirali novu bazu (i prethodno osmislili strukturu tabela), možemo napisati upite za kreiranje tabela:

		
USE prodaja;

CREATE TABLE prodavci
(
	id int NOT NULL AUTO_INCREMENT PRIMARY KEY,
	ime varchar(255) NOT NULL,
	prezime varchar(255) NOT NULL,
	datum_rodjenja datetime NOT NULL,
	adresa varchar(255) NOT NULL,
	broj int NOT NULL,
	email varchar(255) NOT NULL
);

CREATE TABLE prodaja
(
	id int NOT NULL AUTO_INCREMENT PRIMARY KEY,
	datum datetime NOT NULL,
	artikl varchar(255) NOT NULL,
	cena double NOT NULL,
	kolicina double NOT NULL,
	prodavac_id int NOT NULL,
	FOREIGN KEY (prodavac_id) REFERENCES prodaja(id)
)
		
	

Kao što vidite, birali smo odgovarajuće tipove podataka za svako polje, polje id smo proglasili za primarni ključ u obe tabele, a dodali smo i direktivu AUTO_INCREMENT, koja će omogućiti da se (u obe tabele) id automatski uvećava za 1 pri unosu svakog novog sloga.

Takođe, primetimo da su dva nezavisna upita za kreiranje tabela odvojena znakom ; (tačka-zarez), što moramo raditi ukoliko želimo da dva ili više upita prosledimo odjednom.

Budući da se u tabeli prodaja pozivamo na id-ove prodavaca iz tabele prodavci (FOREIGN KEY (prodavac_id) REFERENCES prodaja(id)) i da je unos podataka u tabele naš sledeći korak, razmotrićemo mehanizam koji proverava da li prodavci koje navodimo u tabeli prodaja zapravo postoje.

Referencijalni integritet

Pretpostavljamo da mnogi čitaoci unapred razumeju šta bi moglo da se desi ukoliko pokušamo da u tabelu prodaja unesemo nepostojeći id prodavca, ali, prodiskutujmo ipak malo više o celoj problematici (uz pretpostavku da za početak ne vodimo računa o "referencijalnom integritetu").

Ukoliko u tabelu prodaja pokušamo da unesemo novi slog (na primer: prodaju artikla koju je obavio prodavac sa rednim brojem 17), podatak će biti uredno unet i tabela prodaja će sama po sebi biti korektna (još jednom - pretpostavka je da za sada ne vodimo računa o referencijalnom integritetu), međutim, ako nakon unosa prosledimo (drugi) upit, kojim se zahtevaju podaci o "fantomskom" prodavcu #17 - čiji id ne postoji u tabeli prodavci - sistem će (opravdano) prijaviti grešku.

Da se to ne bi dešavalo, potrebno je da baza podataka pri svakom upisu u određenu tabelu, vodi računa o tome da li spoljnji ključ koji se upisuje (zapravo) postoji u tabeli za koju je vezan, a pojam referencijalnog integriteta odnosi se upravo na mere koje DBMS preduzima da onemogući korisnike da se pozivaju na podatke (entitete) koji ne postoje u bazi.

U tabeli koju smo kreirali, budući da jeste podešeno da baza podataka vodi računa o referencijalnom integritetu, pri pokušaju unosa prodaje koju je obavio prodavac sa id-om 17, bila bi prijavljena greška i slog ne bi bio unet.

Upis podataka u tabele (INSERT)

Sada kada znamo da će nas MySql sprečiti da se "upucamo u nogu" (po pitanju referenciranja nepostojećih prodavaca), pogledajmo kako izgleda upit kojim se podaci unose:

		
INSERT INTO prodavci
	(ime, prezime, datum_rodjenja, email)
VALUES
	("Petar", "Jovanović", "1979-06-15", "petar_jovanovic@str.co.rs"),
	("Ivan", "Kovačević", "1993-04-27", "ivan_kovacevic@str.co.rs"),
	("Jelena", "Marković", "1984-09-09", "jelena_markovic@str.co.rs"),
	("Ana", "Stanković", "1991-08-17", "ana_stankovic@str.co.rs");

INSERT INTO prodaja
	(datum, artikl, cena, kolicina, prodavac_id)
VALUES
	("2020-06-15", "Sveska", 80.00, 4, 1),
	("2020-06-15", "Olovka", 56.57, 2, 1),
	("2020-06-15", "Gumica", 34.96, 2, 2),
	("2020-06-15", "Selotejp", 134.57, 1, 2);
		
	

Po pokretanju gornja dva upita, podaci su uredno uneti u obe tabele (nismo pokušali da "prevarimo" MySql) i možemo ih dalje čitati, menjati, brisati (ili obrađivati na neki drugi način).

Čitanje podataka preko upita (SELECT)

Osnovni upit za čitanje podataka iz određene tabele zadaje se preko komande SELECT i ima sledeću formu:

		
SELECT * FROM prodaja
		
	

Ovakav upit vratiće sve slogove iz tabele prodaja (odnosno: sva polja - svih slogova).

		
ime    | prezime   | datum_rodjenja | email
---------------------------------------------------------------
Petar  | Jovanović | 1979-06-15     | petar_jovanovic@str.co.rs
Ivan   | Kovačević | 1993-04-27     | ivan_kovacevic@str.co.rs
Jelena | Marković  | 1984-09-09     | jelena_markovic@str.co.rs
Ana    | Stanković | 1991-08-17     | ana_stankovic@str.co.rs
		
	

Ukoliko želimo da (zarad preglednosti) prikažemo samo određena polja (recimo, id u prikazu često ne predstavlja bitnu informaciju), ili da upitu dodamo polja koja podrazumevaju obradu postojećih polja (da budemo jasni: takva polja vide se u pregledu koji dobijamo kao rezultat izvršavanja upita i nije u pitanje upis u tabelu), možemo navesti polja pojedinačno, preko sledeće sintakse:

		
SELECT
	datum,
	artikl,
	cena AS 'Cena po artiklu',
	kolicina AS 'Količina',
	cena * kolicina AS 'Ukupna cena po artiklu',
FROM
	prodaja
		
	

Prethodni upit vratiće tabelu sledeće sadržine:

		
datum      | artikl    | Cena po artiklu | Količina | Ukupna cena po artiklu
----------------------------------------------------------------------------
2020-06-15 | Sveska    | 80              | 4        | 320
2020-06-15 | Olovka    | 56.57           | 2        | 113.14
2020-06-15 | Gumica    | 34.96           | 2        | 69.92
2020-06-15 | Selotejp  | 134.57          | 1        | 134.57
		
	

Kao što vidimo, preko upita je moguće dobiti (privremenu) tabelu sa poljima koja predstavljaju rezultat obrade polja tabele (množili smo vrednosti polja cena i kolicina u okviru svakog sloga) i takođe je moguće za polja koristiti preglednije nazive ("alijase").

Da bismo na najbolji način zaokružili priču o SELECT upitima, prikazaćemo kako se podaci mogu filtrirati i sortirati.

• za filtriranje se koristi klauza WHERE (uz precizno navođenje uslova)
• za sortiranje se koristi naredba ORDER BY (uz navođenje konkretnog kriterijuma za sortiranje)

Sledeći upit:

		
SELECT
	datum,
	artikl,
	cena AS 'Cena po artiklu',
	kolicina AS 'Količina',
	cena * kolicina AS 'Ukupna cena po artiklu'
FROM
	prodaja
WHERE
	cena * kolicina > 300
ORDER BY
	cena * kolicina DESC
		
	

.... vratiće samo slogove kod kojih je ukupna vrednost (jednog) prodatog artikla veća od 300 Din (za razliku od upita SELECT bez klauze WHERE - koji vraća sve slogove), a tabela će biti sortirana u nerastući poredak po kriterijumu najveće cene.

Upit za ažuriranje slogova (UPDATE)

Za izmenu već unetih podataka, koristi se komanda UPDATE:

		
UPDATE
	prodavci
SET
	email='petar_m_jovanovic@str.co.rs'
WHERE
	id=1
		
	

Komanda UPDATE sama po sebi nije destruktivna (u tom smislu da ne briše slogove), ali, pri korišćenju ove komande moramo biti jako pažljivi jer će, ukoliko se izostavi WHERE klauza, koja precizira koje slogove je potrebno ažurirati - biti ažurirani svi slogovi!

(Uz klauzu WHERE id=1, upit se odnosi samo na slog u kome polje id ima vrednost 1.)

Upit za uklanjanje slogova (DELETE)

Za uklanjanje slogova, koristi se komanda DELETE:

		
DELETE FROM
	prodavci
WHERE
	id=3
		
	

Naveli smo da pri pozivanju upita za ažuriranje moramo biti veoma pažljivi i da ne smemo izostaviti uslov (osim naravno ukoliko nam jeste namera da polje u svim redovima dobije istu vrednost). *

Sa komandom DELETE moramo biti još pažljiviji, jer je upit za brisanje destruktivan: pri pozivu komande uz uslov, dolazi do nepovratnog brisanja jednog reda (što je slučaj sa gornjim primerom; inače uslov može obuhvatiti i više redova)

Ako se uslov izostavi, biće obrisani SVI slogovi !

Stoga - budite jako pažljivi. :)

Izmena strukture tabele (ALTER TABLE, DROP)

Za izmenu strukture tabele možemo koristiti komande ALTER TABLE i DROP. Komanda ALTER TABLE (preko prigodne sintakse) umeće nove kolone u postojeće tabele, dok se preko komande DROP uklanjaju postojeće kolone (naravno, sa pripadajućim sadržajem).

Ako je u tabelu prodavci potrebno dodati (na primer) kolonu sa kućnim adresama prodavaca, možemo koristiti sledeći kod:

		
ALTER TABLE
	prodavci
ADD
	kucna_adresa varchar(255) NOT NULL
AFTER
	email;
		
	

Ako je iz tabele potrebno ukloniti određenu kolonu (za svaki slučaj ćemo ukloniti samo kolonu sa kućnim adresama, koju smo dodali samo zarad primera i koja nam ne treba za prave), možemo koristiti komandu DROP (u kombinaciji sa komandom ALTER TABLE):

		
ALTER TABLE
	prodavci
DROP
	kucna_adresa
		
	

Implementacija relacija u MySql-u

Iako ćemo se u većini svakodnevnih situacija sretati sa relacijom 1:n, potrebno je biti upoznat i sa načinima za implementiranje relacija 1:1 (sa kojom ćete se sretati bar ponekad) i pogotovo n:n (koja se sreće prilično često).

Implementacija relacije 1:n

Pri implementaciji relacije 1:n, ne moramo preduzimati dodatne korake (budući da je u pitanju podrazumevana relacija).

Za primer (i podsećanje) uzećemo tabele prodavci i prodaja (koje smo već koristili) i ukoliko pri definisanju polja ne navedemo dodatna ograničenja:

		
CREATE TABLE prodaja
(
	--ostala polja,
	prodavac_id int NOT NULL,
	FOREIGN KEY (prodavac_id) REFERENCES prodavci(id)
)
		
	

.... bilo koji od entiteta koji se referenciraju preko spoljnjeg ključa moći će u tabeli da se pojavi više puta (u gornjem primeru - prodavac, predstavljen preko spoljnjeg ključa prodavac_id, moći će da se pojavi u proizvoljnom broju slogova u tabeli prodaja).

Implementacija relacije 1:1

Relacija 1:1 takođe se definiše na jednostavan način, tako što se uz odgovarajuće polje navodi rezervisana reč UNIQUE.

Uzmimo (ponovo) za primer gradove, države i glavne gradove:

Tabele sa prethodnog dijagrama mogu se kreirati i povezati preko sledećeg SQL koda:

		
CREATE DATABASE IF NOT EXISTS mini_geografija
	CHARACTER SET utf8,
	COLLATE utf8_general_ci;

USE mini_geografija;

CREATE TABLE grad
(
	id int NOT NULL AUTO_INCREMENT PRIMARY KEY,
	naziv varchar(255) NOT NULL,
	broj_stanovnika int NOT NULL
);

CREATE TABLE drzava
(
	id int NOT NULL AUTO_INCREMENT PRIMARY KEY,
	naziv varchar(255) NOT NULL,
	broj_stanovnika int NOT NULL
);

CREATE TABLE glavni_gradovi
(
	id int NOT NULL AUTO_INCREMENT PRIMARY KEY,

	-- uz polje grad_id mora stajati odrednica UNIQUE
	grad_id int NOT NULL UNIQUE,
	
	-- uz polje drzava_id (praktično) NE SME
	-- stajati odrednica UNIQUE
	drzava_id NOT NULL,
	
	FOREIGN KEY (grad_id) REFERENCES gradovi(id),
	FOREIGN KEY (drzava_id) REFERENCES drzave(id)
)
		
	

Ranije smo razmotrili da se grad u tabeli glavni_gradovi može pojaviti jednom, a država više puta, pa stoga, pri definiciji polja tabele glavni_gradovi: uz grad (grad_id) stoji odrednica UNIQUE, dok uz državu (drzava_id) ne stoje nikakve dodatne odrednice.

Implementacija relacije n:n

Videli smo da se relacije 1:1 i (pogotovo) 1:n, implementiraju na vrlo jednostavan način, međutim, za implementaciju relacije n:n je potrebno malo više pažnje i dodatna tabela.

Ako se vratimo na primer sa povezivanjem filmova i glumaca, vidimo da sledeći format sloga u tabeli glumci (kao što smo već nagovestili):

		
id:      1,
ime:     "Danilo",
nadimak: "Bata",
prezime: "Stojković",
filmovi: "Varljivo Leto '68; Ko to tamo peva; Maratonci trče počasni krug;"
		
	

.... umnogome podseća na neodgovarajuće formate za povezivanje entiteta (sa kojima smo se već sretali u članku) - i da stoga ne predstavlja optimalno rešenje za implementaciju relacije n:n.

Budući da zapis podataka preko jedne tabele nije optimalno rešenje, relacija n:n se u praksi tipično implementira preko posredničke tabele (preko koje se spajaju id-ovi odgovarajućih entiteta):

Jedna od osnovnih tabela (u konkretnom primeru), sadrži podatke o glumcima:

		
CREATE TABLE glumci
(
	id int NOT NULL AUTO_INCREMENT PRIMARY KEY,
	ime varchar(255) NOT NULL,
	prezime varchar(255) NOT NULL,
	datum_rodjenja datetime NOT NULL
)
		
	

Druga osnovna tabela sadrži podatke o filmovima:

		
CREATE TABLE filmovi
(
	id int NOT NULL AUTO_INCREMENT PRIMARY KEY,
	naziv varchar(255) NOT NULL,
	godina_proizvodnje int NOT NULL
)
		
	

.... a preko dodatne (posredničke) tabele se entiteti iz prve tabele (glumci) spajaju sa entitetima iz druge tabele (filmovima):

		
CREATE TABLE povezivanje
(
	id int NOT NULL AUTO_INCREMENT PRIMARY KEY,
	glumac_id int NOT NULL,
	film_id int NOT NULL,

	FOREIGN KEY (glumac_id) REFERENCES glumci(id),
	FOREIGN KEY (film_id) REFERENCES filmovi(id)
)
		
	

Na ovaj način smo omogućili povezivanje proizvoljnog broja glumaca sa proizvoljnim brojem filmova (a budući da smo uključili proveru referencijalnog integriteta, možemo se osloniti na to da će sam DBMS voditi računa da se u tabeli povezivanje ne pojave glumci koji ne postoje u bazi, niti filmovi koji ne postoje u bazi).

Ugnežđeni upiti

Za kraj smo ostavili nešto složenije upite.

Ugnežđeni upiti (prva kategorija kompleksnijih upita o kojima ćemo diskutovati u uvodnom članku) podrazumevaju korišćenje određenog upita unutar drugog upita.

Za primer ćemo uzeti operaciju koju smo nagovestili na početku: potrebno je pronaći (sve) podatke o prodavcu koji je obavio određenu prodaju.

Ako se pitate "u čemu je problem", podsetićemo se organizacije podataka koju smo (takođe) uveli na početku:

• u tabeli prodaja upisani su samo id-ovi prodavaca (iz tabele prodavci)
• u tabeli prodavci (naravno) ne postoje podaci o prodaji artikala (to jest, podaci o tome ko je od prodavaca prodao koji artikl)

Problem se može rešiti preko sledećeg upita ....

		
SELECT
	ime, prezime, email
FROM
	prodavci
WHERE
	prodavci.id = (SELECT prodaja.prodavac_id FROM prodaja WHERE prodaja.id=3)
		
	

.... koji prvo pronalazi id prodavca, posle čega se nađeni id koristi u upitu koji pretražuje tabelu prodavci.

Da pojasnimo:

• prvo se izvršava unutrašnji upit (koji je obuhvaćen zagradama)
• navedeni upit se svodi na jedan (brojčani) podatak
• navedeni podatak koristi se kao kriterijum za pretragu u WHERE klauzi glavnog upita

Po koracima:

"Unutrašnji" SELECT upit ....

		
SELECT prodaja.prodavac_id FROM prodaja WHERE prodaja.id=3
		
	

.... praktično pronalazi (samo) id prodavca koji je u tabeli prodaja - obavio određenu prodaju.

Rezultat izvršavanja unutrašnjeg upita je jedna celobrojna vrednost, posle čega "glavni" upit praktično postaje:

		
SELECT
	ime, prezime, email
FROM
	prodavci
WHERE
	prodavci.id = 2
		
	

.... što (samo po sebi) predstavlja vrlo jednostavan upit sa kakvim smo se susreli već na početku.

Pridruživanje podataka (JOIN)

Za sam kraj, sagledaćemo još jedan primer koji smo nagovestili na početku (i upoznati se sa 'tehnikalijama' koje stoje iza svega).

Zadatak je: napraviti pregled prodaje u kome su prodavci predstavljeni imenom i prezimenom.

Preko komande JOIN moguće je spojiti (i prikazati) podatke iz dve ili više tabela, pri čemu se kao kriterijum za spajanje koriste podaci koji se pojavljuju u svim tabelama koje učestvuju u spajanju (naravno, kriterijumi se moraju precizno navesti).

Izvršavanjem sledećeg upita:

		
SELECT
	prodaja.datum,
	prodaja.artikl,
	prodaja.cena,
	prodaja.kolicina,
	prodavci.ime,
	prodavci.prezime
FROM
	prodavci INNER JOIN prodaja
ON
	prodavci.id = prodaja.prodavac_id
		
	

.... u pregledu se pojavljuju sve pojedinačne prodaje artikala uz koje stoji ime i prezime prodavca, a rezultat izvršavanja je sledeća tabela:

		
datum      | artikl   | cena   | kolicina | ime   | prezime
-------------------------------------------------------------
2020-06-15 | Sveska   | 80     | 4        | Petar | Jovanović
2020-06-15 | Olovka   | 56.57  | 2        | Petar | Jovanović
2020-06-15 | Gumica   | 34.96  | 2        | Ivan  | Kovačević
2020-06-15 | Selotejp | 134.57 | 1        | Ivan  | Kovačević
		
	

Na ovom mestu se (rekli bismo sasvim prirodno) postavlja i pitanje: kako se tačno podaci izdvajaju i spajaju i kako će (tačno) slogovi biti sortirani?

Kako se podaci spajaju i izdvajaju?

Glavni primer koji koristimo u članku (baza podataka o prodaji artikala) nije u stanju da obuhvati sve situacije do kojih može doći pri spajanju podataka preko komande JOIN, pa ćemo se stoga (privremeno) poslužiti drugim primerom.

Dodatni primer biće baza podataka koja beleži upis studenata na kurseve (na početku akademske godine), a implementiraćemo je preko sledećih tabela:

• studenti - podaci o studentima
• kursevi - podaci o kursevima
• upis - pomoćna tabela preko koje se povezuju podaci iz prethodne dve tabele

Pre nego što se osvrnemo na različite varijacije komande JOIN, osvrnimo se (pre svega) na različite situacije opšteg tipa koje se daju zamisliti tokom upisa studenata na kurseve. *

Dok upis (još uvek) traje, lako je zamisliti da u određenom trenutku:

• među studentima ima onih koji se još nisu prijavili ni za jedan kurs
• postoje kursevi za koje nema prijava (i naravno)
• postoje kursevi za koje je prijavljen određen broj studenata

Različite varijante komande JOIN mogu nam pomoći da dođemo do navedenih informacija.

Razmatraćemo šematski prikaz u kome su tabele popunjene, tako da je određen broj studenata (s1-s4) prijavljen je za određen broj kurseva (k1-k3, k5), preko tabele upis:

INNER JOIN

Ako za spajanje pozivamo komandu INNER JOIN, upit će izdvojiti samo one slogove iz tabele studenti koji su se pojavili u tabeli upis i samo one slogove iz tabele kursevi koji su se pojavili u tabeli upis.

		
SELECT
	CONCAT(studenti.ime, " ", studenti.prezime) AS "Student",
	studenti.br_indeksa,
	kursevi.naziv AS "Kurs"
FROM
	(studenti INNER JOIN upis ON studenti.id=upis.student_id)
	INNER JOIN kursevi ON kursevi.id=upis.kurs_id
ORDER BY
	studenti.id, kursevi.id
		
	

U praktičnom smislu: u pregledu će se pojaviti samo studenti koji su se prijavili za kurseve i samo oni kursevi za koje postoje prijave.

LEFT JOIN

Ako za spajanje pozivamo komandu LEFT JOIN, upit će izdvojiti sve slogove iz tabele studenti i samo one slogove iz tabele kursevi koji su se pojavili u tabeli upis.

		
SELECT
	CONCAT(studenti.ime, " ", studenti.prezime) AS "Student",
	studenti.br_indeksa,
	kursevi.naziv AS "Kurs"
FROM
	(studenti LEFT JOIN upis ON studenti.id=upis.student_id)
	LEFT JOIN kursevi ON kursevi.id=upis.kurs_id
ORDER BY
	studenti.id, kursevi.id
		
	

U praktičnom smislu: u pregledu će se pojaviti svi studenti i samo oni kursevi za koje postoje prijave.

U prethodnom slučaju (INNER JOIN), po izvršavanju upita je pored podataka svakog studenta bio je naveden jedan od kurseva (to nismo prikazali na "plavo-zelenim" šemama, ali, možete primetiti ako pokrenete upite).

U slučaju komande LEFT JOIN, pored podataka o studentu koji nije prijavljen za kurs, stajaće vrednost NULL (na slici simbolično označeno tamnijom nijansom plave).

Na ovaj način (i s obzirom na metodu sortiranja koju smo izabrali), lako u rezultujućoj tabeli možemo primetiti studente koji nisu prijavljeni za kurseve.

RIGHT JOIN

Ako za spajanje pozivamo komandu RIGHT JOIN, upit će izdvojiti samo one slogove iz tabele studenti koji su se pojavili u tabeli upis i (ovoga puta) sve slogove iz tabele kursevi.

		
SELECT
	CONCAT(studenti.ime, " ", studenti.prezime) AS "Student",
	studenti.br_indeksa,
	kursevi.naziv AS "Kurs"
FROM
	(studenti RIGHT JOIN upis ON studenti.id=upis.student_id)
	RIGHT JOIN kursevi ON kursevi.id=upis.kurs_id
ORDER BY
	studenti.id, kursevi.id
		
	

U praktičnom smislu: u pregledu će se pojaviti prijavljeni studenti i svi kursevi, pa će ovoga puta, s obzirom na izabranu metodu sortiranja, biti lako uočiti kurseve za koje ne postoje prijave (na slici označeno tamnijom nijansom zelene).

OUTER JOIN

Ako za spajanje koristimo komandu OUTER JOIN, upit će prikazati sve studente i sve kurseve.

		
SELECT
	CONCAT(studenti.ime, " ", studenti.prezime) AS "Student",
	studenti.br_indeksa,
	kursevi.naziv AS "Kurs"
FROM
	(studenti FULL OUTER JOIN upis ON studenti.id=upis.student_id)
	FULL OUTER JOIN kursevi ON kursevi.id=upis.kurs_id
ORDER BY
	studenti.id, kursevi.id
		
	

Ukoliko je količina podataka umerena, ovakav pregled može (na primer) biti od koristi ako se rezultujuća tabela odštampa (pa odokativnom metodom možemo primetiti informacije koje nas zanimaju).

Kako god da smo izdvojili podatke, ostaje pitanje kako će slogovi u rezultujućoj tabeli biti sortirani.

Sortiranje podataka

Ako pri prosleđivanju upita ne navedemo kriterijum za sortiranje, DBMS će samostalno izabrati način sortiranja (prema rasporedu podataka u memoriji i sl), pa je stoga - ukoliko je potrebno da podaci budu precizno sortirani prema određenom kriterijumu - svakako najbolje da kriterijum navedemo sami.

U primerima sa upisom studenata smo "prećutno" birali odgovarajući metod sortiranja, a za primer iz baze prodaja smo izabrali da podaci budu sortirani po datumu prodaje: ORDER BY prodaja.datum:

		
SELECT
	prodaja.datum,
	prodaja.artikl,
	prodaja.cena,
	prodaja.kolicina,
	prodavci.ime,
	prodavci.prezime
FROM
	prodavci INNER JOIN prodaja
ON
	prodavci.id = prodaja.prodavac_id
ORDER BY
	prodaja.datum
		
	

Uprošćena sintaksa za INNER JOIN i još jedan praktičan primer

SQL dozvoljava da se upit za spajanje podataka, za šta bismo inače koristili INNER JOIN, pozove preko drugačije (i reklo bi se - elegantnije) sintakse:

		
SELECT
	prodaja.datum,
	prodaja.artikl,
	prodaja.cena,
	prodaja.kolicina,
	prodavci.ime,
	prodavci.prezime
FROM
	prodavci, prodaja
WHERE
	prodavci.id = prodaja.prodavac_id
ORDER BY
	prodaja.datum
		
	

.... što deluje "manje zvanično" (budući da ne koristimo komandu INNER JOIN) - ali je rezultat isti.

Preostaje i da se osvrnemo na još jedan primer (koji možete isprobati i preko uprošćene sintakse koju smo maločas prikazali).

Primećujemo da polja cena i kolicina ne upućuju baš najbolje na prirodu podataka koji se pojavljuju u kolonama: za cenu nije naznačeno da li je u pitanju cena po jedinici količine (ili ukupna cena za artikl, koja uzima u obzir i količinu), nije precizirano da li je u cenu uračunat porez (ili nije), za količinu nije naznačena jedinica mere (a mogli bismo navesti i još detalja).

Takođe, što se tiče prodavaca, izdvajanje imena i prezimena u zasebne kolone deluje previše "zvanično" u ovakvom upitu.

Shodno svemu navedenom, upit možemo sažeti i upotpuniti na sledeći način:

		
SELECT
	prodaja.artikl,
	CONCAT(prodaja.cena * prodaja.kolicina, "din.")
		AS "Cena po artiklu (bez PDV-a)",
	CONCAT(prodavci.ime, " ", prodavci.prezime)
		AS "Prodavac"
FROM
	prodavci INNER JOIN prodaja
ON
	prodavci.id = prodaja.prodavac_id
ORDER BY
	prodaja.datum
		
	

• polja cena i kolicina, iz tabele prodaja množimo, a rezultat množenja predstavljamo preko aliasa "Cena po artiklu (bez PDV-a)"
• podatke o prodavcu spajamo preko funkcije CONCAT *

Pokretanjem gornjeg upita, dobijamo tabelu sledećeg sadržaja:

		
artikl   | Cena po artiklu (bez PDV-a) | Prodavac
--------------------------------------------------------
Sveska   | 320                         | Petar Jovanović
Olovka   | 113.14                      | Petar Jovanović
Gumica   | 69.92                       | Ivan Kovačević
Selotejp | 134.57                      | Ivan Kovačević
		
	

Sledeći korak u vezi sa bazama podataka (u smislu članaka koje ćemo objaviti - čemu ćemo se posvetiti u (vrlo) doglednoj budućnosti), biće korišćenje baza podataka u programskim jezicima (konkretno: MySql i PHP).