OK, sad bar znamo sta radimo
Citat:
ps Da znam opseg, svrhu i cilj projekta moram definirati, pa defnirati osnovno set radnih procesa koje ću obavljati nad podacima, pa zatim izraditi logicki model, ali ne ide jer nikako pravilno postaviti ove prve korake.....
Ne brini, nisi ti kriv. Zadatak koji si dobio nije bas tipican primer za ucenje i/ili pokazivanje znanja iz 'kako se normalizuju tabele'.
Ovde vidim dva najvise tri kvazi entiteta.
Imas dakle kontrolne tacke na autoputu. Uz njih bi bilo dobro da pamtis i njihove stacionaze. Stacionaza je udaljenost tacke na putu od neke polazne tacke. Recimo, put je Zagreb - Beograd. Uzmes da pocinje u Zagrebu a zavrsava u Beogradu, ili obrnuto, potpuno je nebitno. Imao bi ovako tacke i stacionaze:
Entitet Tacke (Tacka, Stacionaza)
Tacka Stacionaza
----------------
Zagreb, 0
Novska, 120
Vinkovci, 200
Sremska Mitrovica, 270
Beograd, 350
Vozaci prelaze neki put, ono sto ste nazvali "Voznja". Ako vozac udje na put u tacki "Novska" i vozi do Sremske Mitrovice, on je presao put
Stacionaza(Mitrovica) - Stacionaza(Novska) = 270 - 120 = 150 km.
Da bi se vratio, on mora da izadje sa puta i ponovo udje. Nazad vozi od sr.Mitrovic do Novske.
Duzina puta = ABS( Stacionaza(Novska)- Stacionaza(Mitrovica) ) = ABS (120-270) = ABS (-150) = 150 km
Kad god izadje sa autoputa, vozac mora da plati. Nacini placanja su {Gotovina, Cek, Master CArd, VISA, PretplatnickaKartica}. Jedna voznja = jedan racun. Ako je izgubio karticu voznjem, platice kaznu. Ponovo, jedna voznja = maximalno jedna kazna.
Iz ovoga sledi da mogu da definisem entitet Voznja ovako:
Voznja {IDvoznje, KoJeIzdaoKarticuVoznje, UlaznaTacka, UlaznoVreme, IzlaznaTacka, IzlaznoVreme, StajePlaceno, NacinPlacanja, BrojKartice, NaplaceniIznos, KojeNaplatio}
IDvoznje = neki autonumber, identity, brojac za one kartice koje se izdaju na ulazu, pripada skupu zaposlenih = > FK na entitet Zaposleni koga ces da kreiras)
KoJeIzdaoKarticuVoznje = zaposleni koji je izdao karticu na pocetku voznje ili oznaka masine koja je to uradila
UlaznaTacka, mora pripadati skupu tacaka => FK na entitet Tacka
UlaznoVreme = ocigledno
IzlaznaTacka mora pripadati skupu tacaka => FK na entitet Tacka
IzlaznoVreme = ocigledno, ovo se evidentira na izlazu
StajePlaceno = 1 = racun, 2 = kazna, 0 = nista jos nije placeno
NacinPlacanja = jedan od {Gotovina, Cek, Master CArd, VISA, PretplatnickaKartica}
BrojKartice = broj kartice koja se zaduzuje. NULL ako se placa cashom.
NaplaceniIznos = izracuna se na osnovu stacionaze ako se palca racun, upise se iznos kazne ako se placa kazna
KojeNaplatio = zaposleni koji je izvrsio naplatu na izlazu, pripada skupu zaposlenih = > FK na entitet Zaposleni koga ces da kreiras) ili oznaka masine koja je to uradila (iz sjupa Masina, logicki isto sto i skup Zaposlenih)
Uslovi:
- ako postoji UlaznaTacka, mora da postoji UalznoVreme (ovo narusava normalizaciju, dva atributa zavise jedan od drugog)
- isto za IzlaznuTacku i IzlaznoVreme
- ne moze postojati Izlana tacka a da ne postoji ulazna tacka (ponovo dva atributa zavise jedan od drugoga)
- ne moze se naplatiti ako ne postoje ulazna i izlazna tacka, obe moraju postojati
- ako je napalcena kazna, vrednost uvek mora biti jednaka nekom iznosu X
- ako je naplacena kilometraza, vrednost mora biti jednaka broju kilometara izmedju dev tacke puta cena po kilometru
Svi nabrojani uslovi ukazuju da atributi zavise jedni od rugih, sto je u lepo normalizovanoj shemi nedopustivo. Ova narusavanja normalizacije dolaze od uticaja vremena.
Hajde da kriticki komentarisemo tabelu Voznje:
Zasto bismo upisivali naplaceni zinos, kad se on moze izracunati? Zato sto se cena menja kroz vreme. Ako ne bismo upisali naplaceni zinos, onda bi pri svakoj promeni cene svi iznosi iz proslosti bili nanovo izracunati. Ponovo nam vreme stvara glavobolju.
Sledeci problem sa ovako dizajniranom tabelom je sto se ne moze kompletan rekord uneti, zato sto svi podaci nisu raspolozivi u momentu kreiranja rekorda. Rekord se kreira kad vozac udje na autoput i tad imamo IDvoznje , UlaznaTacka,UlaznoVreme, KoJeIzdaoKarticuVoznje . Kad izadje, doisuju se IzlaznaTacka , IzlaznoVreme . Kad se vozac masi za novcanik, tek tada saznajemo cime ce da plati. Znaci, pojedini 'delovi' rekorda stvaraju se u razlicita vremena. Otuda oni uslovi.
Moze li tabela Voznje da se normalizuje? Moze, ali ce se samo izlomiti na nekoliko tabela koje su u vezi 1:1. A ER modeliranej nas uci da ako su dve stvari u vezi 1:1 to je u stvari jedna stvar, sto nas vraca na pocetak - jedna tabela i gotovo.
Svaka voznja ima pocetnu i izlaznu tacku. Znaci, pocetne i izlazne tacke su atributi za entitet voznja. UlaznoVreme definise pocetak putovanja (voznje), izlazno vreme definise ktraj putovanja. Ova vremena i nisu bitna, jer se ne naplacuje provedeno vreme, nego predjena kilometraza, pa se mozda mogu i izbaciti iz modela (samo teorijski, neka ih, mi smo ljudi i volimo da pratimo vreme). Za jednu voznju izdaje se tacno jedan racun. Zasto bismo mali posebnu tabelu za racune, kad ce biti u odnosu 1:1 sa voznjom?
Nacin placanja je intersantan. Posto smo dodali ptetplatnicku karticu na listu nacina placanja, eliminisali smo potrebu da posebno vodimo prtplatnike i ne-pretplatnike. Opet, nekkao je prirodno da postoji negde tabela sa pretplatnicima. Tako ce i biti. Kako da uspostavimo odnos tabele pretplatnika sa tabelom Voznje? Pa nikako. Mogli bismo kad bi za svaku voznju uveli 'tip voznje' pa onda naplatu izvadili iz tabele Voznje i prebacili je u tabelu 'TipVoznje'. Posebna tabela za Tip = pretplatnik i posabna za tip = ne-pretplatnik. E, onda bi ona VoznjaPretplatnik imala vezu sa tabelom Prtplatnici, q pretplatnik = vise voznji. A sta bizmo iamli za ne-pretplatnike? tabelu gde bi s eupisivale naplate, a ta bi tabela bila u vezi 1:1 sa voznjom? Zasto onda ne bi dodali jednog fiktivnog pretplatnika, btroj '00000' u tabelu pretplatnici, pa na nju knjizili sve ne-prtplatnike? To bi moglo, ali nam u stvari nista ne donosi. I uopste,pousaj da spojimo prtplatnike i voznje nam ne donosibog zna sta, samo se zapetljavamo. Zato sam rekao da se tabela Voznje ne mora normalizovati i u stvari ni ne treba.I tabela Prtplatnici ce sedeti sama za sebe.
Program koji ce biti napisan morace da proverava ispravnost broja ponudjene pretplatnicke kartice, kad se ova ponudi. Tabela voznje trebace mnogo CHECK CONSTRAINTS da bi se obezbedila naoko cudna pravila. Ta ista pravila bi se mogla obezbediti i rabijanjem tabele Voznje na nekoliko manjih tabela koje su sve u vezi 1:1 i da nista ne bude u sustini jednostavnije. Primer je lose izabran i cudi me da profesori ne ramisljaju o tome sta se zadaje djacima.
Ja bih u praksi isao s ovim:
Tacke: (Tacka, Stacionaza)
Zaposleni ILI masine koje izdaju/citaju kartoncice za svaku voznju: (Id, Tacka)
Voznje: - onako kako smo opisali, sa FK na Tacke, NacinePlacanja, i sve ostalo i CHECK uslovima
NaciniPlacanja: (NacinPalcanja)
OniKojiNaplacuju: (IDongKoNaplacuje)
Shema ce da izgleda zvezdasto, jedna tabela u sredini i nekoliko tabela koje su domaini za vrednosti atributa u centralnoj tabeli. Tako normalizovane sheme ne izgledaju, ali sta da se radi, takav je zadatak.
Treba ti kveri koji izracunava predjenu kilometrazu. Pretpostvi da je can kilometra izta na celom putu, da ne komplikujemo dalje bez potrebe.
Treba ti izvestaj - ispis racuna. Na racunu ce pistai iznos i cime je placeno pa ce se tekst razlikovati:
Placeno gotovinom
Placeno kreditnom karticom ----XXXXXX
Placeno pretplatnickom karticom, zbirni racun za sve voznje ovog meseca bice poslat pretplatniku na kraju meseca.
I to je sve. Jos jednom, primer je lose izabran i cudi me da profesori ne ramisljaju o tome sta se zadaje djacima.