Getsbi je lepo odgovorio. Evo i mog dodatka:
Da li je onda projektovanje baza podataka:
a) Inženjerska disciplina
b) Umetnost
c) Crna magija
d) Sve ovo zajedno
e) Ništa od gore navedenog...
???
a) Inženjerska disciplina
Nazalost nije. Ali je na putu da to postane, pre ili kasnije. Inzinjerske discipline zasnivaju se na matematice, fizici i hemiji recimo, ali idu dalje od naucnih principa. Iz fizike se uci na primer kosi hitac, i svesno se zanemaruje otpor vazduha, kao nebitan uticaj u principu. Medjutim, u praksi je otpor vazduha i te kako bitan, toliko bitan da mu se vise paznje poklanja nego samom principu, koji se prihvata skoro zdravo za gotovo. Inzenjerske prihvataju principe iz fizike, koji definisu STA se radi. Inzenjerske discipline principe ne dokazuju, to je uradila fizika. One ih nadgradjuju i odatle proizilaze pravila KAKO se nesto radi. Ako gradjevinskom inzinjeru date da sracuna sile i momente za neki nosac, on to moze uraditi graficki, rucno, pomocu šibera, digitronom, racunarskim programom i razultati ce uvek biti isti. Provera tacnostije uveki ista i jednostavno se radi bez ikakvih pomagala: suma svih sila i momenta u bilo kom preseku nosaca mora biti nula. Za to ne treba ni digitron, rucno sabiranje je savrseno moguce.
Projektovanje baza podataka postace inzenjerska disciplina kada budemo mogli da pogledamo u dijagram baze i da vidimo da li je dijagram "dobar", na nacin na koji proveravanmo da li je zbir sila i momenata nula u svim tackama na nosacu. Za to moramo da znamo "vanjske sile koje deluju na sistem". U bazama podataka vanjske sile su poslovna pravila i uslovi integriteta, kardinalnost i slicno. Vanjske uticaje daje nam dijagram biznis procesa. Odatle sledi dijagram baza podatka. Kad imamo gotov dijagram baze podataka, i poznajemo vanjske uticaje, onda mozemo recimo da proverimo da li je baza podataka normalizovana. Znaci, pravila normalizacije treba primeniti na kraju, kao proveru da li je baza dobro uradjena. I zaista, kad projektujemo bazu, smisljamo tabele i sta u koju ide i kako se one odnose jedna prema drugoj, mi vidimo da nesto treba razbiti na vise tabela. Niko ne kaze "Prvo cu sve da stavim u flat tabelu. Pa cu sad cu sve da dovedem na 1NF. Dobro, sad cu da 1NF prevedem u 2NF i tako dalje". Posle ovoliko godina mi jednostavno 'znamo' da se fakture stavljaju u jednu tabelu, artikli u drugu a da se stavke fakture stavljaju u trecu tabelu koja povezuje artikle i fakture.
Rekosmo kako dijagramu baze podataka prethodi dijagram biznis procesa. U gradjevinarstvu, postoji arhitektonski crtez (1). Sa njega inzenjer je u stanju da vidi staticke uticaje, pa sledi dijagram nosaca sa silama koje na njega deluju (2). Onda sledi proracun (3), pa provera proracuna (4). A onda dodje dimenzionisanje elemenatka konstrukcije grede, ploce , zidovi, temelji (5) i onda neko to sve napravi i dobijemo gotov proizvod - kucu, most, vodovod (6)
Vidimo 6 jasno definisanih koraka. Svaki korak je regulisan pravilima prakse, profesionalnom etikom i drzavnim zakonima. Zakon zahteva da se pre koraka (6), izgradnja, napravi revizija projektne dokumntacije. Nezavistan inzenjer proverava da li su projektanti (tim) odradili sve korake, da li je svaki korak odradjen u skladu sa pravilima struke i po zakonima. Tek onda se ide u izgradnju, koja se opet kontrolise - imate nadzorni organ na gradilistu. Svega toga u projektovanju baza podataka i izradi informacionog sistema nema. Ima nekih elemenata, ali jasan sistem ne postoji, niti zakonska regulativa. A ne daj boze da se ztrazi revisija projektne dokumentacije, da se pogleda dizajn baze ili dizajn programskiog koda pre nego sto se pristupi pisanju aplikacija i fizickom kreiranju baze. Inzenejri kad god otkriju nesto novo, neki postupak, materijal, brze bolje trce da to objave negde da i ostali vide i mozda nauce. Softverasi se ubise pokusavajuci da sakriju kod od drugih, sto je jako glupo, ali ne vredi govoriti onom ko ne zeli da slusa.
Zato projektovanje baza podataka nije inzenjerska disciplina i ljudi ne zele da to postane. Ali ce morati d apostane inzenjerska disciplina li ce jednostavno nestati kao profesija. ne mozete sebe proglasiti inzenjerom. Ali i te kako mozete sebe da proglasite programerom ili projektantom baza podatka.
b) Umetnost
Jeste donekle. Za umetnost je potreban talenat, za projektovanje baza podatka takodje. Svaka inzenjerija je umetnost.
c) Crna magija
Nekada se alhemija smatrala hemijom, posto hemija nije postojala. Ukoliko prihvatimo da jos uvek ne postoji hemija za baze podataka kao inzenjerska disciplina, odgovor je da, jeste po malo i magija, bela ili crna, jer trenutno nemamo nista bolje na raspolaganju.
d) Sve ovo zajedno
Ocigledno je da jeste sve ovo zajedno, ali ce se verovatno kroz vreme zastupljenost pojedinih komponenti promeniti u korist rigorozne inzinjerske discipline.
e) Ništa od gore navedenog...
Posto je projektovanje baza podataka sve gore navedeno, onda ocigledno ne moze biti "nista od ovoga navedenog"
???
Evo kako bi moglo sa dijagranma biznis procesa da se dodje do modela baze podataka:
1) Procitati akcije koje se vide na dijagramu poslovnog procesa. Primer: Kupac kupuje robu od prodavca.
2) Svaka imenica u jednoj ovakvoj recenici je potencijalni entitet, sto ce mozda postati tabela. Imenice u jednoj reenici su ocigledno povezane. Eto potencijalnog Foreign Key. Slede entiteti/tabele tblKupci, tblRoba, tblKupljenaRoba
3) Pored akcija, mogu se uociti i neki dokumenti koji postoje ili nastaju u procesu. Dokumenti su u stvari nacin zapisivanja akcija. Primer: Kupac kupuje robu od prodavca. nastaje dokumet Racun. Racun ima zaglavlje i stavke. Racun se izdaje kupcu. Sve osim poslednje recenice imamo pokriveno tabelama do sada. Dodajemo novu tabelu, Racuni kojoj je roditelj Kopci, a dete je KupljenaRoba, koju mozemo preimenovati u StavkeRacuna
Znaci, (dijagram poslovnog procesa) => (recenice koje opisuju proces, dokumenti u procesu) => entiteti
Kad smo definisali nekoliko kljucnih entiteta, onda im dodamo atrinute, koji opet dolaze sa dijagrama procesa i/ili dokumenata.
4) Onda pogledamo da li trenutni raspored entiteta i njihovih veza dovodi do anomalija prilikom INSERT/UPDATE/DELETE operacija (Ovo se cesto predaje kao uvod u normalizaciju)
5) Pokusamo da otklonimo uocene anomalije pravljenjem novog rasporeda entiteta i atributa
6) Kad msilimo da imamo dobar raspored entiteta i atributa, proverimo da li trenutni model zadovoljava uslove normalnih formi, recimo do trece. Pravila prakse bi trebalo da definisu do kog stepena normalizaciej (do koje forme) treba ici u kom slucaju, kao i minimum. Na primer 3NF je minimum, a ako se uvodi vremenska komponenta u igru onda mora biti zadovoljena 5NF.
Ako bismo objavljivali radove i objasnjavali kako je sta uradjeno, ubrzo bismo naucili sta je najbolje raditi kad se projektuje IS za bakalnicu, a sta radi dobro kad se projektuje IS za autobusku stanicu ili aero saobracaj. Ili distribucija gasa, vode, struje. Ili sta je najbolje raditi kada se projektuje IS za skole ili lekarske ordinacije.
E tada cemo psotati inzenjerska disciplina.