|
A. Advanced SQL-ing 
Ovo je Appendix  kao sto imate po knjigama. Zelim da vam pokazem neke naprednije upite koji sam ja koristio i koju su veoma korisni.
Zamislite sledecu situaciju.
Zelite da napravite nesto, da kazemo katalog knjiga (strucna literatura ).
Izmedju ostalog, ta aplikacija treba da sadrzi i ime knjige i grupu u kojoj pripada radi lakseg pronalazenja iste.
Vidjao sam da su neki sve te informacije (ime knjige, grupa, korisnik koji je uzeo knjigu...) dodavali u jednu tabelu. To nije dobro resenje jer se tu javljaju tri osnovne (i jedine) anomalije.
1. Pri dodavanju zapisa
2. Azuriranju zapisa (Update)
3. Brisanju zapisa
Stim sto jos pravite redudantne podatke (bespotrebno ponavljanje zapisa/podataka).
Da obajsnim svaku od anomalija.
1. Anomalija pri dodavanju zapisa:
Uzmimo primer ove nase aplikacije za knjige.
Ako imamo tabelu u kojoj su smesteni korisnici te biblioteke i tabelu u kojoj su smestene knjige.
Radnik koji radi u knjizari, ne moze da doda zapise o nekom korisniku osim ako taj korisnik ne uzme neku knjigu.
Zasto?
Zato sto se to sve nalazi u jednoj tabeli, a zamislite kako bi izgledala ta jedna tabela kada bi pola zapisa bilo prazno i jos bi se i ponavljali neki. Stim sto se pri projektovanju baze, za neka polja stavlja da ne mogu da prime null vrednost. Drugim recima, MORATE da upisete nesto.
Takvo polje bi bilo za ime knjige, grupu. Korisnik koji je uzeo knjigu je opciono.
Kako bi se zapis dodao u bazu, sva tri polja moraju biti popunjena (pored onih ostalih).
Isto to vazi i za knjige. Ne mozemo dodati novu knjigu ako nemamo kome da je iznajmimo.
2. Anomalije pri azuriranju zapisa:
Kada promenimo ime knjige (iz bilo kod razloga) npr. tek posle nekoliko godina smo shvatili da nismo lepo napisali naslov knjige.
Sve te izmene moramo da vrsimo onoliko koliko je neko puta uzimao knjigu sto moze da dovede do greske i samim tim ne validnih podataka.
To isto vazi i za grupe i korisnike......
3. Anomalije pri brisanju zapisa:
Ako nam je neka knjiga slucajno ispala sa mosta i naravno unistena, ljudi u knjizari (pored naplate stete ) moraju i da obrisu knjigu koja je bila prva knjiga u biblioteci staroj nekoliko
vekova .
Da bi obrisali tu knjigu, moraju da brisu onoliko puta koliko je neko iznajmio tu knjigu. Samim tim (brisanjem) gube se informacije o korisnicima koji su uzimali tu knjigu.
Ista stvar je i sa grupama i korisnicima......
'Tri tabele' To the rescue
Ipak, postoji nacin da se resi sve ovo.
U nasem slucaju (knjige, grupe i korisnici) trebamo da napravimo tri tabele.
Jedna tabela za spisak svih knjiga sa svim njenim informacijama (sta god vam padne na pamet).
Tabela sa spiskom svih mogucih grupa (beletristika, kompjuteri, kompjuterska filozofija ...)
I tabela sa spiskom korisnika koji bi trebalo da uzimaju te knjige sa svim njihovim informacijama.
Kontrolni broj, broj dece...
U tabeli za knjige treba da se dodaju jos dva atributa (pored onih sa informacijama za knjige) za grupe i korisnike preko kojih ce se tabela knjige povezivati sa abelom grupe i tabelom
korisnici.
Sve tri tabele imaju atribut ID koji je primarni kljuc. Ime knjige je obavezno polje (ono not null) kao i grupaID dok je korisnikID opciono.
knjige
+----------------------------------------------------------+
| id | ime knjige | grupaID | korisnikID |
+----------------------------------------------------------+
| 01 | kompjuterska fil. | 01 | |
| 02 | tom sojer | 02 | |
| 03 | dig. integr. el. | 03 | |
+----------------------------------------------------------+
grupe
+-----------------------------+
| id | ime grupe |
+-----------------------------+
| 01 | kompjuteri |
| 02 | lektira |
| 03 | elektronika |
+-----------------------------+
korisnici
+----------------------------+
| id | ime korisnika |
+----------------------------+
| 01 | Mika |
| 02 | Pera |
| 03 | Sima |
+----------------------------+
Tabele izgledaju ovako.
Kada zelimo da dodamo novog korisnika, Sve njegove informacije dodajemo u tabelu korisnici.
Kada zelimo da dodamo grupu, sve informacije o grupi dodajemo u tabelu grupe.
Isto tako i za knjige.
Kada dodje neki korisnik (Mika npr.) i zeli da uzme knjigu 'kompjuterska filozofija', operater zapisuje te podatke u tabelu knjige i to za tu knjigu koju je taj korisnik uzeo.
Tabela izgleda ovako:
knjige
+-------------------------------------------------------+
| id | ime knjige | grupaID | korisnikID |
+-------------------------------------------------------+
| 01 | kompjuterska fil. | 01 | 01 |
| 02 | tom sojer | 02 | |
| 03 | dig. integr. el. | 03 | |
+-------------------------------------------------------+
Vidimo da je Mika povezan sa knjigom koju je uzeo preko njegovog ID (iz tabele korisnici) i ID iz tabele knjige tako da se zna ko je uzeo koju knjigu.
Kad bi ovo trebali da ispisemo, dobili bismo ne bas razumne podatke (mislim ovo, 01, 03, 10003, 383....).
Za ispisivanje pravih podataka, treba nam malo komplikovaniji SQL upit, ali radi posao.
Teorijski opis SQL upita:
SQL upit treba da selektuje sve iz tabele knjige gde je grupaID=ID id tabele grupe I gde je korisnikID=ID iz tabele korisnici.
Prakticni opis SQL upita:
SELECT * FROM knjige,grupe,korisnici WHERE knjige.grupaID=grupe.ID AND knjige.korisniciID=korisnici.ID;
Posle ovog SQL upita, normalno mozemo da pristupamo poljima i da ih ispisujemo gde treba.
Ako niko nije uzeo ni jednu knjigu, SQL upit nece vratiti ni jedan zapis.
To bi bilo to. Za sada. Ako imate nekih pitanja, slobodno pitajte.
Izvinjavam se zbog neurednosti tabela. Primetio sam tek kada sam postovao ovde, a sada me mrzi da ih ispravljam .
Update: Sredio sam tabele .
Navigation
----------------------------------
prev | ...
|
