KAd se 'odenjuje lkvalitet baze', gledaju se dve stvari:
a) formalne greske i problemi
b) funkcionalni kvalitete - koliko baza zaista podrzava posmatrani poslovni proces.
Da bi ocenili funkcionalni kvalitet, moramo prvo da znamo sta se od baze trazi. U ovom slucaju to ne znamo, pa ne mozemo nsita reci o tome. Ako si bazu pravio onako, iz glave, bez prethodne analize i nekakve dokumentacije o tome sta treba napraviti, niej dobro, jer je to onad 'slobodna tema'.
Formalne greske se mogu naci, i evo nekih od njih:
- Kolona ID postoji u svakoj tabeli i bas je ona Priemry Key.
Veoma pogresno ,jer ne postoje druga ogranicenja koja bi garantovala kakav-takav integritet podataka. Na primer, lako sam dodao jos jedan mesec u tabelu Mjesec, nazvao sam ga Zidar, pa sad imam 13 meseci. Nisam tu stao, nego sam dodao jos jedan mesec, ovoga puta Travanj, tako da sada moja godina ima dva Travnja i mesec Zidar. Isto tako sam dodao godinu 2010 jos jednom. Mnogo mi se svidja ta godina pa sam je dodao u tabelu jos jednom. Isto vazi za sve ostale tabele. Mozes dodati jednog istog Zaposlenika nekoliko puta.
- Ni jedna kolona nema Required= YES (ekvivalentno NOT NULL u SQL jezicima). bez da probam da preksim to pravilo, vidim u tabeli Place_Zaposlenika jedna rekord, ID=3, koji ne pripada ni jednom zaposleniku
- nigde nije definisana plata zaposlenika, kolika treba da bude. Znaci li to da u tabelu Place_Zaposlenika mogu da unesem kakve hocu brojeve? Pokusao sam i uspeo. Zdravku sam dodelio 6800 sati za Travanj, a onda sam nekom dodelio -32000 sati za neki tamo mesec. takodje se ne vidi koliko je kome isplaceno. To je suvis evazan podatak da se ne bi cuvao.
- Sve moze da bude NULL, sto izaiziva prazne rekorde u 'child' tabelama
- nigde nema nikakvih drugih ogranicenja za bilo koji podatak u bilo kojoj tabeli. Brojevi mogu da budu negativni i nerazumno veliki ili mali,
- tekstualni podaci prihvataju prazan string, ime moze da se unese kao '1234'
- Zaposlenik i Zaposlenik_Podaci - ne vidim zasto bi se tabela podelila na dve, ali ajde, teorisjki to moze, samo mi ovd ene izgleda da tako i treba.
Spisak nije konacan, ovo je samo ono sto vidim na prvi pogled.
Za pocetak zanci, formalno, mnogo toga ne valja. Funkcionalno, ne bih da ocenjujem, to moze neko ko o ovakvim poslovnim procesima zna vise od mene. Funkcionalni zahtevi odredice kako treba da izgledaju relacije, pa ni to ne bidh da komentarisem.