Dok se ne javi Zeljovan, da se i ja ukljucim.
Opis procesa koji je dao Zeljovan je odlicna osnova za dalju analizu i gradjenje sistema. Samo da ne napravimo gresku i bukvalno taj opis prevedemo u model. Nas zadatak ima ugrubo 4 faze:
Faza 1: da od korisnika iscupamo informaciju o procesu.
Faza 2: da interpretiramo informaciju iz faze 1, tako da se od intrepretacije moze napraviti logicki model baze podatka
Faza 3: da napravimo fizicku bazu podatka (tabele)
Faza 4: da se napise program, ili skup programa, koji ce raditi sa fizickom bazom podataka
Ovde je novost Faza 2. Najcesce se pravi greska pa se Faza 1 direktno pretvori u logicki/fizicki model 'jer je tako korisnik trazio'. Djavola, ne ide tako. Faza 1 je korisnikovo vidjenje realnog sistema, kao dijagnoza. Faza 2 je terapija koju lekar specijalista propisuje, faza 3 i 4 jeste aktivno lecenje koje sprovodi isti ili drugi lekar.
Elem, iz Faze 1 vidimo da se ovd eradi o dve stvari, motorima i avionima. Avion je zmaj plus motor. Zmaj je znaci telo aviona, ili kako lepo rece Zeljovan "(Zmaj ti je sve osim motora) u njega stavljaju motor koji je dosao iz USD". Vidimo iz Faze 1 da jedan zmaj moze imati vise motora kroz vreme (samo jedan motor u datom trenutku).
Problem koji je na pocetku izneo Zeljovan je 'kako pamtiti vreme rada MOTORA dok je isti u fabrici, dakle, jos nije ni ugradjen unekog zmaja, niti se zna na koji ce zmaj otici". Ceo posao ziove se "evidencija naleta" Nalet asocira na letenje, a lete zmajevi, tj. avioni. Motori ne lete, barem ne samostalno. Zatim, da zabuna bude veca govori se o 'radu na zemlji, na tehnicki dan', kada opet, avion (zmaj+motor) ne lete, nego sedi na zemlji a MOTOR radi.
Svi do sada predlozeni modeli baze podatka promasili su taj deo sa motorom.
Medjutim, model kolege Zorana moze da odradi posao, u pojednostavljenoj varijanti. Ovako: baza EvidencijaNaleta 20100412.mdb, koja se nalazi u EvidencijaNaleta 20100412.zip, ima tabelu RezimRada. RezimRada ima za sada dve vrednosti: 0="fabrika" i 1="u upotrebi" . Ajde da to malo promenimo, pa uvedemo TRI vrednosti:
0= "fabrika", kao i ranije
1 = "u vazduhu" ili "letacki dan"
2 = "na zemlji" ili "tehnicki dan".
Ovim smo pokrili sev slucajeve koji se javljaju u praksi. Kad motor stigne iz fabrike, ugradi se u nekog zmaja. Tada se za tog zmaja/aviona upise prvi red u tabelu "VazduhoplovEvidencija" sa rezimRada = 0 i brojem sati rada MOTORA na fabrickom stolu.
Ovim se gubi potreba za dve kolone sa satima, 'Sati na zemlji' i 'Sati u vazduhu', pa se model moze pojednostaviti. Za TipDana nisam siguran, cini mi se da i to moze da sada se eliminise iz baze podataka. TipDana na neki nacin opisuje rezim rada vazduhoplova/motora, pa treba videti da li nam zaista treba. No, moze se sve postici i da se nista od ovih promena strukture ne uradi. jednostavno na postojecim formama sakrijem kolone koje mi ne trebaju.
Na osnovu pomenute baze EvidencijaNaleta 20100412.mdb, napravio sam EvidencijaNaleta 20100412_Z02.mdb. Samo sam dopisao jedan red u tabeli ezimRada i promenio opise minimalno izmenio formu koja prikazuje rane sate pojedinacnog vazduhoplova.
Ovde se vidi kvalitet strukture baze podataka, cak i kada realni proces nije u potpunosti pogodjen. Voleo bih da imam Zoranov fenomenalan smisao za generalizaciju i apstrakciju procesa. Primetite da nismo prakticno nista uradili na kverijima ili programu, izmene su minimalne - i napor i ulozen trud je dakle minimalan, a efekat bi mogao biti znacajan. Da Zoran nije vemoa mudro skovao model baze podataka (tabele i njihov odnos), bilo bi mnogo teze promeniti program.
Ovo resenje verovatno 'moze da prodje', ali ima jednu manu - ne vidi se nigde broj motora. Ako se motor skida sa vazduhoplova samo kada motor strada, i taj se motor vise nikada ne vrati na neki drugi avion, onda verovatno nema veze. Medjutim, ako se motor remontuje, pa se ugradi ponovo na neki avion, onda ova baza podatka nema mesta za takve transakcije.