Getsbijev model izgleda OK.
1) Prenos PK u celosti ili Autonumber? Moze i jedno i drugo, u ovom konkretnom slucaju, ali je Getsbijev pritup bolji. Evo zasto.
Na raspolaganju nam je jako malo podataka o tome sta se modelira i zato dobijamo cistu hijerarhiju Firna->Radna Jedinica->Radnik za okosnicu sistema. Kad je u pitanju tako cista hijerarhija, onda moze i ovo sto Zile kaze, da se ne prenosi ceo PK iz tabele u tabelu, nego da Rdanjedinica ima autonumber PK, pa se samo RadnaJedinicID prenosi radniku. Medjutim, u zivotu nsita njie cista hijerarhija, pa je Getsbijev pristup zdraviji, jer dopusta prosirenje modela uz ocuvanje integriteta.
Zile, zamisli da se sad doda entitet, kao sto ce se dodati zasigurno, samo nam jos nisu kazali, entitet dakle, Kancelarije. Svaka kancelarija pripada ponekoj firmi, a radnici rade u kancelarijama. Ono sto je Getsbi napravio nece dopustiti da se radnik iz firme A smesti u kancelatriju koja pripada firmi B. Ako se ne prenosi kljuc od Firme do Radnika, imaces
Firma (FirmaID PK)
RadnaJedinica (RadnaJediciaID PK, FirmaID FK)
Radnik (RadnikID PK, RadnaJedinicID FK)
Dodajemo Kancelarije (FirmaID FK, KancelarijaID PK) i naravno, RadnicUKancelarijama (RadnikID PK, KancelarijaID PK)
Evo nam tempirane bombe. RadnicUKancelarijama je vezna tabela, iliti relacija, koja povezuje Radnike i Kancelarije. Ima PK (RadnikID, KancelariajID). Bilo koja kancelarija moze se dodeliti bilo kom radniku. Not good, not at all .....
Getsbijev model:
Firma (FirmaID PK)
RadnaJedinica (RadnaJediciaID , FirmaID FK) PK = (RadnaJediciaID , FirmaID )
Radnik (RadnikID , FirmaID FK, RadnaJedinicID FK), PK = (RadnaJediciaID , FirmaID , RadnikID)
Kancelarije (FirmaID FK, KancelarijaID PK)
RadnicUKancelarijama (RadnaJediciaID, FirmaID, RadnikID, KancelarijaID), PK = (RadnaJediciaID, FirmaID, RadnikID, KancelarijaID)
Sad vec ne moze da se radnik smesti u kancelariju druge firme.
Slozeni PK, kako je getsbi uradio ima i druge dobre strane. Neki veoma cesti kveriji se pojednostavljuju. Na primer, "ko radi u kojoj firmi?". getsbijevo resenje dopusta da se uradi jednostavno
SELECT * FROM Radnici
i tu sve pise. Znam, znam, ne vidi se puno ime firme. ako treba dodos JOIN i vidis ga. Uoci ovo 'ako treba'. Mnogo puta to 'ako treba' ne stoji, pa ti ne treba JOIN. Kveri bez JOIN je uvek brzi nego kveri sa JOIN.
Dalje, ako ovi silni ID nisu briojevi, nego text, neke skracenice, onda bi SELECT * FROM Radnici dalo nesto kao
'Petar Markovc', 'PtMrk00001', 'EnrgPrj,'NskGrd'
'Janko Jankovic', 'JnJnk00007','GSP','MehRad'
'Janko Popovic', 'JnPpv00006','GSP','Nab'
Ovo vec daje lepu informaciju. Za mnoge kverije bice dovoljno procitati EnrgPrj i znati d aje to EnergoProjekt, ili GSB. Zatim NskGrd bi mogla biti 'Niskogradnja', 'MehRad' bi mogao biti 'mehanicarska radionica', 'Nab' bi bila 'Nabavna sluzba'
2. . ti je Getsbi odgovorio, stvar projektanta kako ce da vidi sistem. U ovoj fazi, svakako dovoljno dobro.
3. Jedino sto nedostaje, jesu neke CONSTARINTS. Na primer, ako je u pitanju Ziroracun firme, onda PoslovnJedinicID i RadnikID treba da su NULL u tabeli ZiroRacuni. Tako za sve ostale kombinacije. Da izbegnemo komplikovane CONSTRAINTS, mozemo da uvedemo tipove za entitete ZiroRacun i Telefon, pa na kraju dobijemo nesto ovako:
Mnogo tabela? Slazem se, ali shema barem garantuje integritet podataka. Ako se pretpostavi da ce biti tacno tri nivoa hijerarhije, Firme/RadnaJedinic/Radnik, onda je shema OK. I tipizacija podataka je OK. Tabela ZiroRacuni ima PK Brojracuna. Svaki racun ima tip koji pokazuje kojoj vrsti entiteta taj racun pripada. Moze pripadati frmi, radnioj jedinici, radniku. U Banci su svi racuni na gomili i inace. Broj racuna izdaje banka, firma ga samo belezi u ovoj tabeli da bi finansijska sluzba mogla da upotrebi te brojeve za svoj radnje. Tabela ZR_Firme ima kolonu TipRacuna koji moze biti samo i samo 'F'. Znaci tu je moguce upisati samo one acune koji u tabeli Racuni imaju tip 'F'. Isto je za tabele ZR_PJ i ZR_Radniak, svaka ima fiksiran TipRacuna koji mzoe da primi. Time se eliminise svaka mogucnost da se isti racun unese u na dva mesta.
U sledecoj poruci primer kako smanjiti broj tabela. Uz jedno veliko ALI....
[Ovu poruku je menjao Zidar dana 31.07.2009. u 16:49 GMT+1]
[Ovu poruku je menjao Zidar dana 31.07.2009. u 16:52 GMT+1]