U faj sistemu, tabele (podaci) nemaju nikakvu inteligenciju. Relacioni sistemi imaju inteligenciju na nivou tabela (podataka). U tome je kljucna razlika.
Sam si rekao:
Citat:
Npr. ne znam kako se zove na sprskom onaj sisitem koji postoji kod savremenih DB-ova da se, pod određenim uslovima, jedna operacija ne izvrši ako se ne izvrše sve operacije iz zahtevanog skupa (bitno kod transfera novca gde se jednim upitom skidaju sredstva sa jednog računa, a drugim prebacuju deo na jedan, a trećim upitom na drugi računa, pa ako nestane struje tokom izvršenja prvog upita, onda nema para na prvom računu, a nisu prebačene na druga dva; da li sam dovoljno plastičan?). Ili slučaj referencijalnog integriteta gde se neki podatak iz tabele ne može izbrisati sve dok postoje zapisi koji referenciraju na njega (npr. ne možeš da izbrišeš stanje robe u magacinu, ako ta roba ima cenu u cenovniku). Ovi primeri mi sad padaju na pamet, a navodim ih jer sumnjam da bi oni mogli da se realizuju na FS-u (pre u middle layer-u, ali to je druga tema).
Upravo si odgovorio na svoje pitanje. Relacioni sistemi podrzavaju transakcije i integritet podataka je deklarativne prirode a ne proceduralne.
Sta ovo znaci, deklarativno i proceduralno? Proceduralno je na nivou programskog koda, middle layer ili middle tier, ili sta bilo, uglavnom aplikacija vodi racuna o integritetu podataka. Deklaartivo znaci da je inteligenciaj na nivou podataka (tabele, baza). Kod relaqcionih sistema, jednostavno kazes pri definisanju tabela 'roba ne moze da bude u tabeli ULAz ako ne postoji u tabeli ROBA'. Gotova prica. Onda programeri ne moraju o tome da vode racuna, nego se fokusiraju na funkcije sistema, ono sto sistem treba zaista da radi. Ako malo razmislis, progarmirati integritet podataka ne doprinosi fukcionalnosti sistema. Toje samo preduslov da bi sistem uopste mogao da obavlja ono sta se od njega trazi. Integritet sistema je nezavisan od funkcija sistema. To ti je kao razlika izmedju motora u autu i volana. Jasno je da auto ne moze da ide bez motora. Ali stavi samo motor u auto, bez volana, takodje ne ide. Motor koji stavljas u auto mozes da stavis u brod ili u neku lokomotivu, ili cak da pokrece cekrk za zicaru ili pilanu. Motor ja dakle preduslov, nesto sto stvara rotacino kretanje. Rotaciono kretanje ce biti upotrebleno u neku svrhu (funkcija sistema) Volan je nesto sto ti omogucuje da upravljas autom, da ides gde hoces. Tako i u bazama podataka. Inegritet je nuzan preduslov. Aplikacija je volan. istu bazu mogu da koriste razne aplikacije. Dakle, aplikacija moze da bude i brod i pilana. A sve na istom motoru. Posto uspostavljanje i odrzavanje integriteta trazi mnogo programiranja, neko se setio da je na duzi rok jeftinije da progarmeri to ne moraju da rade, nego samo kazu 'artikl ne moze u magacin ako ne postoji na spisku artikala'. Ili kazes 'ne sme duplikat u tamo neko polje'. Ako aplikacija i propusti duplikat, baza ga nece prihvatiti => integritat podataka nije narusen.
Ima jedna situacija u Accesu kad se vidi prceduralni mentalite programera. Programira se unos necega gde se trazi jedinstven kljuc. 99% programera na formi za unos programira nesto kao "pre nego sto sacuvas rekord, proveri da li je vrednost za kljucno polje vec u tabeli, pa ako jeste, obustavi akciju cuvanja rekorda". Naravno, nema nista lose u proveri duplikata pre unosa. Da li bas? Ako u tabeli imas 2,000,000 rekorda ili 20 miliona, pa za svaki unos ides u tabelu i trazis nesto cega u 99% slucajeva nema, imas bespotrebnu komunikaciju izmedju aplikacije i baze. Kako god da je tabela lepo indeksirana, 2 miliona rekorda je dva miliona rekorda. Ispravno resenje: nemoj ni da proveravas da li je ponudjena vrednost duplikat. Ako jeste duplikat, sama baza ce da spreci unos i bez intervencije programera. Sta treba dakle programer da uradi? Nista. Da pokusa unos, pa kao se javi greska, da izvesti korisnika ili da mozda tek onda pronadje gde je duplikat i tako dalje. Ako u 99% slucajeva korisnik unosi ne-duplikat, nece se desiti nista, sve ide OK. U onom 1% baza ce se pobuniti i tek tada ce program morati da komunicira sa bazom, da trazi gde je duplikat i slicno. I kada je verovatnoca dupliakat velika, neka je 99%, ponovo komunikacija sa baziom je nepotreban, baza ce sama da odbaci unos i javice gresku. A sve zato sto je tabela sama po sebi 'inteligentna'. Ovo se ne desava u fajl sistemima. Aplikacija mora da brine ama bas o svemu.
U faj sistemu, tabele (podaci) nemaju nikakvu inteligenciju. Relacioni sistemi imaju inteligenciju na nivou tabela (podataka). U tome je kljucna razlika.