Za grebenar:
Na pocetku je covek pitao ovo:
Citat:
U teoriji se, kod prevodjenja u relacioni model, u ovom slucaju formiraju tri relacije
1. Radnik(RadnikID, Ime, DatumZaposlenja...)
2. Zadatak(ZadatakID, Opis, ...)
3. Radnik_Zadatak(RadnikID, ZadatakID)
medjutim, u praksi se uglavnom srece razlicitost kod trece relacije pa ona postaje
3. Radnik_Zadatak(Radnik_ZadatakID, RadnikID, ZadatakID)
ZASTO????
Na kraju smo dosli do tvrdnje:
Citat:
pitanje:
popne se alpinasta do svog prozora, počne ga prati i vidi da ga zovu sa Mt.Blana. Skokne tamo, vrati se, a njegov prozor još nije do kraja opran. Uključi se u rad i na opštu radost prozor konačno bude čist
Ovo su u vremenu dvije konkretizacije relacije radnik-zadatak koje kompozitni kljuc Id_radnik, id_zadatak ne može pokriti.
Zasto ne bi mogao kompozitni kljuc (Id_radnik, id_zadatak ) da pokrije ovo? Ovim pitanjem uvodis u stvari novi entitet - "working session". Kljuc (Id_radnik, id_zadatak) u tabeli Radnik_Zadatak samo govori da je id_radnik dodeljen zadatku id_zadatak. Kad god radnik radi nesto, u nekom danu, na nekom zadatku, to je "working session" (kako se ovo prevodi na srpski?) To ne pise u tabeli Radnik_Zadatak. Meni se cini da nam treba nova tabela, WorkingSessions, gde je deo PK ono 1) sto je PK u tabeli RadniciNaZadacima. Otprilike ovako:
Teorijski nacin:
Radnik_Zadatak(Id_radnik, id_zadatak... ) PK =(Id_radnik, id_zadatak)
WorkingSessions ( Id_radnik, id_zadatak, SessionNum, Datum, KolikoSatiJeRadio) PK= (Id_radnik, id_zadatak, SessionNum)
Na ovaj nacin znam ko je dodeljen kom zadatku i koliko je kog dana radio. Jedan dan radi, drugi dan ne radi, pa opet radi.
Nacin 'iz prakse' :
RadniciNaZadacima (Radnik_ZadatakID, RadnikID, ZadatakID) onda imas PK = Radnik_ZadatakID i AK (RadnikID, ZadatakID)
WorkingSessions (Radnik_ZadatakID, SessionNum, Datum, KolikoSatiJeRadio) PK (Radnik_ZadatakID, SessionNum)
Znaci moze i na jedan i na drugi nacin. Ajde da uporedimo:
Teorijski nacin ima jednu kolonu vise u WorkingSessions. Nacin 'iz prakse' ima jedan index vise u RadniciNaZadacima (AK, Alternate Key). Po pitanju upotrebe prostora smo dakle gotovo isti. Ti si malo bolji, jer u tabeli WorkingSessions imas 2 kolone u PK, a ja imam 3. Prostor nije skup u danasnje vreme, pa se ne bih o tome previse brinuo.
Sto se tice efikasnosti, ja znam direktno iz tabele ko je radio na kom zadatku u kom danu, a tebi treba JOIN.
Sto se tice rada, ti imas vise da radis (jedan index vise, jedan JOIN vise). Da li je to mnogo vise rada - nije. Da li tvoj Radnik_ZadatakID radi brze nego moj (Id_radnik, id_zadatak), to ne mogu da kazem zasigurno, ni da ni ne.
Eto, opet nismo odgovorili coveku - zasto bas mora Radnik_ZadatakID umesto (RadnikID, ZadatakID)? Mala usteda u prostoru? Ma kako zvucalo neprijatno, i dalje stoji ono - 'lakse se pise JOIN ako imas PK od jende kolone'
Osim ako mi ne pokazes kako bi pomocu kljuca Radnik_ZadatakID resio problem koji si postavio na efikasniji nacin nego sto sam predlozio.
----- ovde menjam temu na ovo ----------------
Ja bih pitao ovakva pitanja:
1) Neka imamo tabelu WorkingSessions (Radnik_ZadatakID, SessionNum, Datum, KolikoSatiJeRadio) , kakav god da je PK, nema veze. Ako radnik u isto vreme moze da bude rasporedjen, na nekoliko zadataka, kako obezbediti da u jednom danu nema vise od 8 sati rada? Kako spreciti ovo u tabeli:
RadnikD_ZadatakID, SessionNum, Datum, KlikoSatiJeRadio
1 1 24 Juli 2006 6
1 1 24 Juli 2006 8
Eto, covek odradio 14 sati. Kako to spreciti? Front End resenja ne dolaze u obzir.
2) Ako je tabele WorkingSessions ovkava:
WorkingSessions (Radnik_ZadatakID, SessionNum, Datum, PocetakRada, Krajrada) Pocetakrada, KrajrRada = sati u okviru dana, (ovo mu dodje kao neki timesheet)
Kako obezbediti da se u tabelu ne unose preklapajuci intervali? na primer, da se ne moze uneti:
RadnikID=1, ZadatakID=1, Datum = 24 Jul 2006, PocetakRada = 8:30 , KrajRada = 15:45
RadnikID=1, ZadatakID=2, Datum = 24 Jul 2006, PocetakRada = 10:15, KrajRada = 12:20
I ovaj krade na satima. Bio na dva zadatka u isto vreme.