Citat:
Da sumiram:
1. Na pocetnoj strani (prijem racunara) budu polja za unos podataka o klijentu (licni podaci), o problemu koji racunar ima, datum prijema i radni broj naloga.
Sve bi se to unosilo u bazu nakon klika na jedno dugme;
2. Druga strana bi bila rezervisana za servisere. Znaci samo jedan UPDATE vec postojecih zapisa u tabelama gde bi se dodao opis uradjenog posla i da je
racunar zavrsen;
3. Osnovni izvestaji. Pregled cele baze i prikaz zavrsenih ili nezavrsenih racunara, u zavisnosti od atributa koji serviser izmeni u stavci 2.
4. Pretraga baze po broju naloga.
To je tacno ono sto zelim da imam za pocetak. Nadam se da razumete taj moj inat da uradim bas ovo, jer onda znam da sam ispunio ono sto sam rekao sebi.
Ti ne pricas o bazi, nego o aplikaciji, kako si zamislio da izgleda i sta da radi. Bazu imas i zelis da je pregledamo. OK, da je pogledamo. Molim te da budes strplijiv ida procitas sve do kraja, da se ne naljutis negde u sredini :-)
Za pocetak, nije data kompletna definicija baze. Date su samo tabele i osnovni atributi. Nedostaju ogranicenja. Dobro, mozda ono $ predstavlja PK a ono # predstavlja FK.
Code:
klijenti ($idklijenta, ime, prezime, telefon)
racunari ($idracunara, opis_kvara, opis_servisa, napomena, #idservisa)
servis ($idservisa, datum_prijema, racunar_zavrsen)
na_servisu ($broj_naloga, #idklijenta, #idracunara)
Tabela Klijenti je nezavisna, nema FK, ne gleda ni u jednu drugu tabelu, redovi se mogu dodavati po volji. Mali problem je sto kiljent (ime Bata, prezime Son, tel 123-456-789) moze da bude unesen 9999 puta u tabelu, ali to mozemo da zanemarimo za trenutak, mozda tako i treba.
Jos jedna nezavisna tabela je
servis ($idservisa, datum_prijema, racunar_zavrsen). Ne gleda ni u jednu drugu tabelu, sve se unosi po volji. Mogu da unesem 100 redova odmah, sa istim ili razlicitim datumom, a mogu i da upisem i da je racunar_zavrsen = TRUE. Nista me ne sprecava, osim mozda briljantno programiranje u PHP. Svejedno je sta upisem, ionako mi nista ne kaze ni koji je racunar, ni koji je klijent u pitanju.
Ostale tabele su zavisne od ove dve. Tabela racunari ($idracunara, opis_kvara, opis_servisa, napomena, #idservisa) zavisi od #ID servisa. Znaci, iz onih 100 odabranih servisa, izaberem neki i dodelim ga bilo kom racunaru. opis_kvara ce mi kazati klijent, opis_servisa ne znma, jer jos nisam nista uradio, tek sam primio racunar, napomena ne znam cemu sluzi i sta predstavlja. Ali me nsita i ne sprecava da unesem opis servisa unapred.
Posto sam lepo uneo racunar u tabelu, sada lepo mogu da unesem novi red u tabelu
na_servisu ($broj_naloga, #idklijenta, #idracunara). Neku unique vrednost dodelim u kolonu broj_naloga, to je jel'te PK. #Idklijenta prepisem iz tabele Kiljenti, i IDracunara prepisem iz tabele Racunari. Moram samo nekako da unesem tacno onaj racunar koji je doneo doticni klijent. Pri tom mogu lako da napravim gresku, jer me nista u tabelama ne sprecava da je napravim. Osim mozda opet briljantno programiranje u PHP.
U bazam apodataka generalno se trudimo da ne zavisimo od programiranja, da nam podatke (integritet podataka) cuva sama baza, ako je ikako moguce. To je prva, generalna greska.
Druga, konkretna greska je izbor i konstrukcija tabela, tako da integritet podataka nije ama bas nikako obezbedjen. - proizasla iz prekrsenog prvog pravila.
Treca greska je sto data baza ne odgovara ni izbliza realnosti u servisnoj firmi. Ako pretpostavimo da se nikada ne ide na teren, znaci musterija donese racunar u firmu. Onda se saslusa sta ga muci. Onda se pogleda racunar, odrade neki testovi, da bi se postavila dijagnoza. Onda se racunar ili popravi - promene se delovi koji ne valjaju, ako treba, ili se narucuju delovi, ako ih nemamo. Ako su delovi mnogo skupi, ponekad moramo da zovnemo klijenta i da pitamo za dozvolu, ili potvrdu. On moze da se slozi ili odbije. Ako se slozi, narucujemo delove (i cekamo na njih nekoliko dana) i na kraju ih ugradimo. Onda korisnik preuzme racunar, ali se ponekad desi da bas i ne radi kako smo predvideli, pa ga vrati - reklamacija, cime se problem ponovo otvara. Ako se klijent ne slozi sa kupovinom delova, ceo posao se obustavlja i gledamo kako da naplatimo vreme utroseno na dijagnozu.
Kao sto vidis, ima mnogo koraka koje treba proci, iako se ne prolaze uvek svi koraci, od momenta donosenja racunara u servis, do zavrsetka ili obustave posla. Imamo tacno jedan pocetak, sa dva moguca ishoda, i promenljivim brojem koraka izmedju pocetka i kraja procesa. Osim ako sve to ne upisemo u kolonu 'napomene'. U skoli te nisu ucili nazalost kako se ovakve situacije resavaju, jer se tuo us kolama generalno ne uci. Zato sam ti rekao da promenis temu. A ti se zainatio.
Modal na koji te Getsbi uputio je nesto bolji, tamo se zna ko je doneo koji akumulator na pregled, to bar ne moze da se izmesa. Zapisuje se na bolji nacin sta fali akumulatoru - dozvoljava se vise od jedne 'greske' po 'evidenciji'. Evidencija tamo odgovara nakakvom 'radnom nalogu'. Takodje je bolje opisano sta je radjeno - u tabeli EvidencijaNacinaResavnja. I dozvoljavaju se reklamacije. Medjutim, i taj model ne prati desavanja u toku procesa, osim mozda kroz kolonu Evidencija.Napomena. Isto, kod reklamacije se ne vidi sta se to reklamira, nema ukazatelja ne neki prethodni servis - evidenciju. Lepo je sto se u tom modelu mislilo i na pozajmicu - nekome pozajmimo akumulator dok ne popravimo njegov. Ali ne vidimo da li je pozajmljeni akumulator i vracen, kada i u kakvom stanju na primer.
Sve u svemu, i taj model tek 'moze da prodje' ako zazmurimo za neke stvari. Iako je mnogo truda, znanja i iskustva ulozeno. A taj program nije radio neki neznalica ili pocetnik, stavise, radio ga je majstor vredan svakog postovanja. problem nije do majstora, nije ni do tebe, problem je jednostavno takav da se tesko resava. Ono sto je potrebno za ovakav problem, za sada se ne uci u skoli, ni kod tebe u Srbiji ili bivsoj YU, ni ovde u Kanadi, ni u USA. Pisu se sistemi koji 'mogu da prodju', i prolaze, i rade i to dobro rade, pa se sve pusi. Ali nisu dobar primer za ucenje baza jer nema sta iz njih da se nauci.
Zato treba izabrati nesto drugo, za vezbanje i za pocetak, ako su baze podatak cilj. Ako je cilj pokazati kako se kreativnim progarmiranjem mogu prebroditi problemi za koje naoko nemamo resenja u bazam, onda je OK, ovo je pravi primer za to.
Nadam se da se ne ljutis, samo sam pokusao da to ustedim vreme.
:-)
Pomoc oko relacionog modela
). 
