Svaka relaciona baza podataka je ER (Entity Relationship) baza. Znači svaka koja ima više tabela (a ne samo jednu flat) koje su povezane i koje poštuju pravila normalizacije, referencijalnog integriteta, kardinalnosti.......
ER model, ako misliš na grafičko-tekstualni ima svoju ulogu, da se pravilno uradi modelovanje na logičkom nivou i da na kraju krajeva ostane grafičko-tekstualna dokumentacija onima koji će naslediti bazu podataka.
Direktno implementiranje iz ER modela u ER bazu, odnosno sa logičkog modela u fizičku bazu podataka koja je spremna za punjenje podacima je moguće u mnogim alatima koji se bave Informacionim modeliranjem. Ja koristim ErWin 4.1 i on podržava 18 SQL DBMS-a i 5 Desktop DBMS-a.

Hijerarhijski, mrežni i relacioni modeli baze podataka se mogu realizovati u odgovarajućim bazama podataka, npr.
- hijerarhijski model baze podataka može da se realizuje u hijerarhijskoj bazi, recimo IMS koju pravi IBM ili DMS II koju pravi Unisys;
- mrežni model baze podataka može da se realizuje u mrežnoj bazi, recimo IDMS koju sada održava CA;
- relacioni model baze podataka može da se realizuje u relacionoj bazi, recimo MySQL, ili DB2.

ER model mora da se transformiše u relacioni (ili neki drugi) model pa tek tada da se realizuje u relacionoj (ili nekoj drugoj) bazi. Prilikom transformacije se semantika modela značajno redukuje jer je ER model izražajno bogatiji od drugih modela. Zar ne bi bilo zgodno da postoji ER baza pa da se ER model direktno implementira? U kojoj meri objektne baze pokrivaju ER semantiku? A objektno relacione?

Za početak zaboravi mrežne i hijerarhijske baze. One postoje samo u udžbenicima.

Onda pitanje : za šta ti treba ta baza ? Ako hoćeš da odradiš neki konkretan posao, onda naravno da ćeš da praviš relacionu bazu i da joj pristupaš u SQLu. I nije neki problem odraditi tu konverziju (postoje i alati, kao što reče čovek). I sad ne mogu da se setim koja se logika (semantika) tu gubi usput, ali relacioni model je sasvim zadovoljavajuće semantički bogat.
Praktično sve što se danas radi sa bazama, radi se relaciono i ti to ne možeš izbeći.
Ako pokušaš da eksperimentišeš sa nečim drugim, teško ćeš naći nekoga da ti primogne kad zapneš.


Pa možda i ne bi. Takvoj bazi ne bi mogao da pristupaš iz SQLa. Znači trebao bi ti neki drugi (složeniji) upitni jezik koji ima snagu SQLa. A nisam baš siguran koliko tako nešto postoji na tržištu.

pogledaj:
http://www.geocities.com/idmssql/idms91.htm
http://publib.boulder.ibm.com/...bm.zmiddle.doc/zmiddle_76.html



Ako moja baza treba da podržava objekte koji nisu tabele (npr. gasovodna mreža ili organizaciona struktura firme) tada od relacionog modela imam slabe vajde. Pokušaj da zamisliš SQL upit kojim se proverava koji sve čvorovi postoje između dva zadata čvora u nekoj mreži? Ili, kako u sistematizaciji pronaći šefa nekom radniku ako je hijerarhija proizvoljne dubine?

Fitopatolog pogledaj ovaj http://msdn2.microsoft.com/en-us/library/aa697427(VS.80).aspx

Ovo nije sastavni deo neke baze (doduse ovo je MS specific, tako da se najvise odnosi na SQL Server) ali vremenom ce sve vise dobijati podrsku na samoj bazi. Sta se ovime dobija? Mnogo toga. U sustini, na samoj bazi ce biti sve isto, ali cela komunikacija izmedju baze i DBA koja se danas vrsi bi trebalo da padne na ledja programera, dok bi DBA trebalo da radi database specific stvari. Dajem ruku da su relacione baze postale popularne samo zbog jedne stvari, ne zbog toga sto imaju bog zna kakvu superiornu organizaciju, nego samo zbog onog svog deklarativnog dela koji se ogleda u DML-u.
Naravno, sve ovo je otislo toliko daleko da niko ne dovodi u pitanje kvalitet relacionih baza ali samo odrzavanje i razvijanje relacionog modela u odnosu na neke druge modele (objektne ) je, blago receno, katastrofalno.

Već sam nešto pisao o ovome : http://www.elitesecurity.org/t299048-0#1780313 . Nije idealno rešenje, ali za gro uobičajenih problema odlično radi posao. Recimo za org strukturu prosečne multinacionalne kompanije.

A za mrežu bih, priznajem, morao da deklarišem kursora.

Porediti "ER model" sa relacionim modelom podataka je u najmanju ruku smešno. To je isto kao da poredite kokoške i ptice. ER dijagram je način da se grafički prikaže podskup relacionog modela podataka (i to samo strukturalni deo).

Relacioni model podataka je popularan zato što je to jedini model podataka koji ima matematičku osnovu, a osnovu mu čine skupovi. Skupovi su toliko jednostavni i prosti da je prvo susretanje s matematikom (još u obdaništu) upravo susretanje sa skupovima. Relacioni model svoju popularnost duguje upravo toj jednostavnosti.

Sve baze imaju dobru matematičku osnovu. Hijerarhijska i mrežna baza operišu sa grafovima (prva sa grafovima u obliku stabala a druga sa grafovima koji imaju strukturu mreže). Grafovi su dobro poznate matematičke strukture. Svaka od baza ima i svoj jezik za manipulisanje podacima. Ono što je SQL doneo kao upitni jezik za relacione baze jeste to da je specifikaconog a ne navigacionog tipa. To znači da korisnik prosto specificira uslove pretraživanja bez potrebe da zna fizičku organizaciju podataka i da vrši navigaciju kroz datoteke i slogove. SQL je zasnovan na relacionom računu tako da je rezultat svake SQL operacije nova relacija. Dakle, relacione baze rade sa relacijama (tabelama) i rezultat svake SQL operacije nad njima je takođe relacija (tabela). To je sasvim u redu dok su objekti sa kojima treba raditi uglavnom tabele, što je slučaj u svim poslovnim aplikacijama (relacione baze tome duguju svoj komercijalni uspeh). Problem nastaje kada treba napraviti bazu koja opisuje objekte koji nisu tabelarne strukture - zbog toga je ono pitanje u naslovu teme.

_{[Ovu poruku je menjao Fitopatolog dana 14.12.2007. u 15:10 GMT+1]}

Relacije i tabele nemaju veze jedne sa drugima. To što smo navikli da relacije crtamo u vidu tabele ne znači da je relacija = tabela.

Tabela ima dve dimenzije: redove i kolone.
Koliko dimenzija ima relacija R(a1, a2, a3)? Tri! Svaki atribut je jedna dimenzija. A opet ćemo uspeti da nacrtamo tu relaciju u vidu tabele na dvodimenzionalnom papiru, jer je tabela sasmo reprezentacija relacije.

Pročitaj bilo šta o teoriju relacionog modela podataka i nećeš naći spominjanje tabela!

Znam šta su i grafovi sa matematičke tačke. Znam i šta je predikatski račun i šta je relacioni model podataka sa matematičke tačke, ali priznajem da nisam čitao matematičke osnove hijerarhijskog/mrežnog modela podataka. Iskreno ne znam ni da li takvo nešto postoji. Jedino što sam čitao o hijerarhijskim/mrežnim bazama podataka (a ne 'modelu podataka') je oko 50 stranica teksta iz neke knjige.

I odgovor na postavljeno pitanje 'Da li postoji ER baza?' je: Ne postoji zato što ne postoji ni ER model podataka.

Kada ER dijagramu ukineš grafičku komponentu ne ostaje ti ništa!

Šta je relacija R(a1, a2, a3)? To je skup uređenih trojki (a1, a2, a3). Na primer, ako pretpostavimo da je a1 šifra, a2 ime a a3 godina rođenja, relaciju R možemo napisati kao sledeći skup:

{(1,Sima,1989), (2,Pera,1988) (3,Milica,1988) };

Ovaj skup možemo prikazati tabelarno:

a1 a2 a3
1 Sima 1989
2 Pera 1988
3 Milica 1988

Ne vidim neku veliku razliku (osim kozmetičke) između ova dva načina prikazivanja relacija.

Posto je ovo forum o MS SQL, moram da primetim da MS SQL u verziji 2005 ima veoma jaku podrsku za upravo ovo sto si pomenuo. (npr. gasovodna mreža ili organizaciona struktura firme). I pre verzije 2005, cak i u Accesu bilo je i jos uvek je moguce modelovati hijerarhijske strukture tipa organizaciona struktura firme. Problem je bio kako generalizovati pretrazivanje, update i insert. MS SQL 2005 je to resio, koliko znam ORACLE je to resio jos odavno (pre nekoliko godina).

Iz licnog iskustva, gasna mreza se veoma jednostavno modeluje u bilo kom RDBMS, zato sto izgleda kao drvo. Vodovodna mreza je za red velicine komplikovanija nego gasna, zato sto izgleda kao mreza zatvorenih kontura, ali i to radi savrseno pod RDBMS, provereno. Neki proracuni su se morali izvoditi kroz jednostavne petlje, u programskom kodu, zato sto nije bilo moguce generalizovati ono sto ti nazivas navigacijom kroz drvo/mrezu. Danas je absolutno moguce odraditi proracune gasnih/kanalizacionh/vodovodnih mreza potpuno u nekom RDBMS. To niko ne radi jer to nije najbolji nacin za resavanje ove vrste problema.

Sigurno je da sitemi koji se komercijalno nazivaju 'hijerarhijske baze' mogu to da odrade brze. To je mogao da efikasno odradi i Fortran 4, i Pascel i (V)BASIC, ako se podaci o konfiguraciji grafa unesu u pametno organizovane nizove. Tako se to i radilo, jos od ranih sedamdesetih. Onda su se pojavili razni sistemi za 'baze podataka' i neko se setio da se ulazni podaci za proracune mreza mogu komotno cuvati u eksternim fajlovima. Moj prvi program za proracun mreze radio je na Fortran kartice. Posle smo ulazne podatke prebacili u tekstualne datoteke, pa u Lotus/Symphony/Excel/Quattro, pa u dBase, i na kraju na MS SQL Server. Procesiranje je ostalo gde je i bilo - u nekakvom .exe programu, ili VB ili sta bilo, a podaci se ucitavaju u nizove iz tabela koje sede u MS SQL. Na taj nacin, svako radi svoj posao. MS SQL (ili bilo sta slicno) CUVA podatke, a neki efikasniji program ih efikasnije obradjuje. I onda ispljune rezultate u Excel i/ili u ACAD, da bi odradili prezentaciju. Uoci tri dela: cuvanje podataka, procesiranje, prezentacija :-D

Rekoh, sitemi koji se komercijalno nazivaju 'hijerarhijske baze' mogu to garantovano da odrade brze. Problem je u tome sto prosecan covek tesko danas moze da dodje u posed jednog takvog sistema da bi na njemu razvijao sta mu vec treba.

Ako je ovo diskusija cisto akademskog tipa o tome koji sistemi su bolji za resavanje pojedinih klasa problema, mislim da gubimo vreme, jer od toga nece izaci nikakva prakticna korist. Mrezni i hijerarhijski sistemi su deo istorije, dok su RDBMS ovde i ostace tu poduze. Ako zelis da nesto prakticno uradis, predlazem da pogledas knjige koje pise Joe Celko, na primer "Joe Celko's SQL for Samrties, Advanced SQL programming" izd. Morgan Kaufman ili "Joe Celko's Trees and Hierarchies fro Smarties" od istog izdavaca.

Ako ne mozes da dodjes do ovih knjiga, prouci iz Hlep-a jednu novinu koju je doneo SQL 2005 - CTE expressions. U Books On Line imas primer koji odradjue upravo hijererhiju zamisljene firme. Upotrebu CTE za svasta, pa i za hijerarhije lepo je obradio Anthony Molinaro u knjizi "SQL CookBook". Imas je negde na webu kao besplatnu PDF verziju. Ako ne mozes da je nadjes, ostavi mail pa cu ti je poslati.

Upravo si i sam rekao: tabela je način prikazivanja relacije, a ja ću nastaviti, ali nikako nije isto što i relacija. Da je to isto, onda bi Excel bio relacioni sistem za upravljanje bazama podataka.

Nije dobro da se mešaju sistemi za upravljanje bazama podataka sa samim bazama podataka. Relaciona baza se može realizovati i pomoću običnih fajlova, isto kao i pomoću Excelovih tabela. Znam za relacionu bazu koja služi za kompletan obračun zarada za oko 100 radnika koja je realizovana samo u Excelu i radi sasvim pristojno iako se nigde ne koristi SQL jezik. Suština je da se sa najmanjim ulaganjima (živog rada, novca) ostvare najbolji rezultati (brza obrada, prosto održavanje, lako korišćenje, jednostavno obučavanje korisnika, dobra povezanost sa okruženjem, itd.). Zbog toga pitanje navedeno u naslovu teme, iako sa akademskim prizvukom, ima vrlo praktičan značaj. Dodavanjem objektno-relacionih mogućnosti u DB2 i Oracle dobija se utisak kao da se radi sa objektima iako se ti objekti dekomponuju u relacije i tako čuvaju u bazi. Da li smo sa objektno-relacionim bazama bliži ER modelu ili su možda objektne baze u tom smislu bolje od njih?

A kako bi ti definisao relaciju?

Nije problem u definiciji relacije, nego je problem u definiciji tabele (tj. nedostatku definicije tabele).

Moglo bi ovako:
Relacija (lat. relatio) odnos, veza, poslovna veza
Relacija – Logička struktura koja organizuje podatke u redove i kolone
Torka – Red u relaciji
Model podataka – Konceptualni opis prostora problema pomoću izraza iz relacione teorije
Relaciona baza podataka – Fizička izvedba relacionog modela
Šema baze podataka – Fizička struktura tabela u bazi podataka
Tabela – Fizički oblik relacije iz šeme baze podataka

(definicije povađene: Rebecca M.Riordan - Projektovanje baza podataka)

Naravno, kao ni bilo koje druge definicije ni ove nisu "svetinja". Samo pomažu da se bolje razume predmet rasprave. Sve je stvar konvencije. Ako se mi dogovorimo da nešto zovemo ER baza, onda će to za nas biti ER baza, a ostatku javnosti možemo nametnuti da smo u pravu ukoliko nas ima dovoljno i ukoliko smo od autoriteta. Od jalove teoretske diskusije mnogo je važnije da razumemo čemu šta služi i kako da se upotrebi. Dakle pragmatizam, pre svega.

Definicija: Relacija R nad skupovima A1, A2, ..., An je podskup Dekartovog proizvoda A1 x A2 x ... x An.

Dotična Rebecca M.Riordan iznosi budalaštinu da je relacija: "Logička struktura koja organizuje podatke u redove i kolone". Ovo je populistička definicija koja pristaje knjigama tipa: "Naučite relacionu teoriju za 60 minuta".

Gde se to u definiciji relacije spominju redovi i kolone?

E super. Sad za nas koji smo relacionu teoriju naučili za 60 minuta, prevedi definiciju: "Relacija R nad skupovima A1, A2, ..., An je podskup Dekartovog proizvoda A1 x A2 x ... x An." sa apstraktnog nivoa na realni ili bar na niži nivo apstrakcije, jer bez praktične vrednosti i koristi za život teško da će inženjerima i programerima ona značiti mnogo.

Chachka, nisam imao nameru da rasplamsavam diskusiju već da ukažem da je sve stvar konvencije i polazne tačke gledišta, bez želje da se bilo šta banalizuje. Zato sam i stavio prvo prevod reči sa latinskog jer je ona (Relacija) mnogo šireg značenja nego sušta matematička interpretacija i napisao "Moglo bi i ovako...." :-)

Najveća fora je što relacionih baza ni nema. Sve one koje znamo su lažno relacione, tek par opitnih SUBP su potpuno relacioni: http://www.oreillynet.com/onla...source_relational_databas.html

U pravu si, uz malu korekciju da se ne radi o relacionim bazama već o softveru za upravljanje relacionim bazama podataka (SURBP) (I ja sam u naslovu napravio istu grešku pa sada moram da se vadim :-) ). I pored toga što se razlikuju od idealnih SURBP (Edgar F. Kod je 1972. objavio čuvenih 12 pravila koje svaki SURBP treba da zadovoljava) savremeni SURBP (Oracle, DB2, MS SQL ...) su vrlo upotrebljivi.

Relacija i jeste apstraktan pojam. Relacija je ona linija koju deca u obdaništu crtaju između elemenata dva skupa, relacija je i operacija sabiranja i sinusna funkcija.

Moj brak je relacija između moje supruge i mene. To je apstraktan pojam koji ima neke svoje fizičke manifestacije u vidu izvoda iz knjige venčanih i prstena. Ako bih bacio prsten u Planinu Usuda ja bih i dalje ostao u braku. Uništavanjem tog prstena ne uništavam brak, već samo fizičku prezentaciju braka.

Uobičajeni način da se relacija prikaže na papiru (ili monitoru) je u vidu tabele.

'ajde!?

:-)

Ne zaboravite da je relacija SKUP, kakogod da se prikaže.

Ne vidim poentu sarkazma jer sam to isto već bio napisao u ovoj temi još pre dva dana.

Upravo tako, ali nemoj ni ti zaboraviti da tabela nije skup.

:)

Ovo mi se već više dopada. Iako ne sporim matematičku definiciju relacije koju si dao. Počinje da naginje ka realnosti i počinje da liči na "Relacija – Logička struktura koja organizuje podatke u redove i kolone", jer crtanje i nije nita drugo do logički prikaz realnosti na papiru. Iako sam ja u obdaništu zamišljao da je to što crtam stvarno. :-)


Nešto sam zaboravio matematiku. Da li je i prazan skup takođe skup ? Da li je nula takođe realan broj ? Rekao bih da jeste. Al' ko zna. Možda se nešto i promenilo. :-) I ovako bi mogli u nedogled, jer svaka reč ima rep. Kaže narod.

No šalu na stranu. Mislim da je najvažnije napraviti granicu koliko je moguće između logičkog (konceptualnog) i fizičkog (realnog, opipljivog). Tako nam definicije iz jednog sveta neće ometati shvatanje ovog drugog. Možda se ne bih ni uključio u ovu akademsku raspravu (želja mi je bila da pomognem) da nisi napisao:

te sam potrčao da je pronađem, a kako ona zahteva i neka dodatana objašnjenja, ispred sam povadio i njih. Čovek svemu oko sebe teži da da definiciju. Pa zašto bi tabele bile izuzetak. :-)

Nije sarkazam već podsetnik na tvoju rečenicu: "Relacije i tabele nemaju veze jedne sa drugima."

Verovatno sam loše izabrao reči, ono što sam mislio je da relacija nije isto što i tabela što se vidi iz rečenice koja neposredno sledi spomenutu rečenicu i glasi:"To što smo navikli da relacije crtamo u vidu tabele ne znači da je relacija = tabela." Usput, ovom rečenicom sam ustvari uspstavio relaciju (odnosno vezu) između pojma tabela i pojma relacija, a ta veza je veza nejednakosti.

Naravno da se između svaka dva pojma ili predmeta može uspostaviti nekakva veza.

Pošto nam i dalje fali definicija tabele, pokušaću ja da je dam: Tabela je dvodimenzionalna matrica.

Pošto su matrice ustvari funkcije, a funkcije su relacije, sledi da su i tabele specijalne relacije. Svaka tabela je relacija, ali nije svaka relacija tabela! Evo nam još jedne veze između pojma tabela i pojma relacija.

Nemože se reći: "Dakle, relacione baze rade sa relacijama (tabelama) i rezultat svake SQL operacije nad njima je takođe relacija (tabela)"

Relacione baze rade sa relacijama, a ne sa tabelama. Baze zasnovane na SQL jeziku nisu relacione baze (a to je i Au197/79 primetio), baš zato što nije rezultat svake SQL operacije relacija! Relacija je skup, skup nema duplih elemenata, a SQL izrazi itekako vraćaju duple elemente. SQL je zasnovan na vrećama ("bag" na engleskom, nisam čitao ništa na srpskom po ovom pitanju pa nisam siguran da li je prevod adekvatan), a ne na skupovima.

Pogledaj 12 Codd-ovih pravila za softver za upravljanje relacionim bazama! Dobar softver za upravljanje relacionim bazama uvažava tvoju primedbu i ne prikazuje duple (ili višestruke) redove u rezultatima SQL selekcija. Odgovornost projektanta baze je da izborom atributa koji čine primarni ključ ne dopusti mogućnost unosa duplih (ili višestrukih) redova u tabelu. Na kraju, kako isključivo pomoću SQL naredbi možeš da obrišeš samo jedan od dva identična reda? NIKAKO!

Opet se pozivam na famoznih 12 pravila E.F.Codd-a: Kod relacionih baza tabela nije matrica jer redosled atributa (kolona) nije bitan, kao ni redosled redova (što je i prirodno, u skupu nije bitan redosled elemenata). Takođe, u SQLu ne možeš da se referišeš na podatak iz tabele preko indeksa reda i kolone, jer bi to značilo da je SQL navigacionog tipa (navigacija preko indeksa kolone i reda!) što nije slučaj.

Koji ti je ovo softver za upravljanje relacionim bazama? Traži da ti vrate pare!

usput, probaj isti upit u ACCESSu!

p.s. Sad videh da treba da se ukloni klauzula ALL pa će biti sve OK!

<sub>[Ovu poruku je menjao Fitopatolog dana 16.12.2007. u 18:29 GMT+1]

[Ovu poruku je menjao Fitopatolog dana 16.12.2007. u 21:29 GMT+1]</sub>

Na kraju, kako isključivo pomoću SQL naredbi možeš da obrišeš samo jedan od dva identična reda? NIKAKO!

Zar "... LIMIT 1" ne radi za DELETE instrukciju?

A koja je svrha ove diskusije? Da definisemo relacije? Da odgovorimo na pitanje 'ima li pravih relacionih sistema/baza/modela/ili kako vec hocete'? Ili da kukamo sto ne postoji ER baza a bilo bi lepo da postoji? Sta mi tu mozemo sto niko jos nije izmislio ER bazu? Sta mi tu mozemo sto ORACLE i MS SQL nisu prave relacione baze? Treba li da prestanemo da ih koristimo? Nismo ih mi ni napravili, pa primedbe o njihovim nedostacima ne treba upucivati na ovaj forum. Da li je sve sto je Codd napisao uopste ostvarljivo? Po Coddu, kase u samousluzi ne bi mogle da rade pod nekom relacionom bazom. Na srecu, postojeci ORACLi i SQLovi nisu bas potpuno relacioni pa eto nekako kase u samouslugama rade.

I opet, a o cemu mi to pricamo ovde i o cemu se raspravljamo? Tuk na luk, ili utuk na utuk. Nisam siguran da bas imamo vremena za to

Kada se neko obrati forumu «Baze podataka» očekuje od sagovornika minimum poznavanja baza podataka. Mada, naša struka je specifična jer teorijsko poznavanje stvari nije neophodan preduslov da bi se neko i praktično bavio time. Ako si vešt u pronalaženju različitih vrsta «objašnjenja» veće znanja od toga ti i ne treba. Ako i to ne upali, postoji čarobna rečenica «tako je to u praksi». Nekada je poznavanje teorije i prepreka za uspeh: Razmotrite samo slučaj (doduše iz druge branše, ali poučan) krivog tornja u Pizi: Majstori Zidari su lepo uzeli mistrije u ruke – kakav statički proračun, kakvi bakrači, odmah praktična realizacija. Jeste da je se posle toranj nakrivio i da niko ne može u njemu da stanuje ali je postao čuven u celom svetu... A da se slušala teorija i poštovala pravila struke, dobili bi samo jedan običan toranj.... Zato treba odmah navaliti na kodiranje, a vreme koje smo trebali utrošiti u projektovanju potrošićemo kasnije da se opravdamo kada stvari pođu naopako.

p.s. Zaboravih smajlija!
:-)

_{[Ovu poruku je menjao Fitopatolog dana 17.12.2007. u 21:19 GMT+1]}

Ako imaš npr. 1000 duplikata (parova), kako da upotrebiš gornju funkciju?

Ma ja se slažem sa Fitopatologom u svemu. Samo mi nije jasno sta smo do sada svi skupa naučili iz ove diskusije. Da li nam je išta jasnije sada nego na početku? Šta je u stvari bilo pitanje? Meni je smesšo i neukusno držati lekciju iz teorije Chachki ili Getsbiju. Ja sam od obojice štosta naučio, a mnogi i od mene naučili ponešto. Lepo. Razumem da hoćeš da pokažeš kako kod svih nas postoje određene šupljine u teorijskom znanju. Lepo. Pomozi nam da te šupljine popunimo. Ako misliš da svaki projekat treba početi crtanjem ER dijagrama, pa tek na osnovu toga crtati logički model baze podataka ( je l' se tako zove ono što se crta u ERWINu? ), lepo nam to kaži. Onda ćemo znati da smo nešto naučili. Ovako samo gubimo vreme.

Što se tiče tornja u Pizi, neće biti baš da su ga sazidali samo mistrijom. Bez proračuna, ovakvog kakav se danas koristi, verovatno. U to vreme ni matematika nije izgledala kako danas izgleda, a kamoli statički proračuni. Zidari koji su ga radili bili su najbolji arhitekti toga doba. Godina početka gradje je 1173, znači pre renesanse ili u najboljem slučaju rana renesansa. Jadničići, nisu ni svesni bili koliko ništa nisu znali i koliko su bili nepotkovani teorijom. Ko zna šta bi bilo da su išli na fakultet pa diplomirali, pa im sad još priznali i master :-D A bili su i te kako svesni da se toranj krivi. Pokušali su da ga isprave doyiđivanjem spratova i postepenim pomeranjem težišta u suprotnom pravcu od pravca naginjanja. Zbog toga je danas opasno pokušati ispraviti toranj, mogao bi da pukne ako se dovede u vertikalu

:-)

Ako pogledaš istoriju postova, videćeš da nisam ja zaoštravao diskusiju. Naprotiv. Samo sam mislio kako bi dobro bilo da imamo ER sistem za upravljanje bazama... Mada sam sada sklon da promenim mišljenje...
p.s. Možda nismo ništa novo naučili, ali smo bar obnovili gradivo iz baza (mada postoji i izreka: "Čovek se uči dok je živ. Posle samo obnavlja materiju"). Bar sam ja opet pročitao ona famozna Codd-ova pravila. Nije strašno ako diskusija u pojedinim momentima i postane žustrija ako jedan prema drugome zadržimo dignitet.

:-)

To bi trebalo svako sa 2 gm mozga da zna a u kompanijama u kojima sam ja radio projektanti baze su imali zadatak da dizajniraju tabele tako da sistem ima sto bolji odziv za datu svrhu pa cak i po cenu da se nesto denormalizuje. Takodje je bitno da znas i koju vrstu indeksa da koristis (reversed, bitmap, B-Tree) i na koje kolone da stavis indeks ili da li za vise tabela treba da stavis cluster key ili da ih napravis da budi index organized itd, bitno je da poznajes prirodu podataka koju ces da koristis da bi znao da podesis parametre baze kako treba...


Koja baza podataka nema neki rowid ili nesto slicno? A i cak i da nemas opet bi moglo da se sredi obicnim SQL-om tako sto iskopiras sve distinct redove u drugu tabelu, obrise prvu i preimenujes drugu da ima isto ime kao prva. To je samo jedan od nacina a postoje i efikasniji...

Sto se tice softvera za modeliranje baza podataka, ja koristim papir i olovku. Upravo radim sa bazom koja ima 450 tabela i 800 stored procedures i funkcija i nista nije bilo toliko komplikovano da nam je trebao neki softver. Samo se treba pridrzavati KISS principa i sve ce biti ok.

Normalizacija i denormalizacija relacionih baza su posebna teorija. ER baze ne pate od tih tegoba (dobro, možda ipak treba neka mala denormalizacija).

ROWID (kod Orakla) je takođe ATRIBUT! Doduše, sa njim moraš biti oprezan, jer se kod reorganizacije baze menja.

Kiss princip je Ajnštajnova ideja (slobodno prepričana glasi: Stvari treba pojednostaviti što je više moguće ali ne više od toga). Sasvim se slažem sa njom.

<sub>[Ovu poruku je menjao Fitopatolog dana 18.12.2007. u 08:59 GMT+1]

[Ovu poruku je menjao Fitopatolog dana 18.12.2007. u 09:15 GMT+1]</sub>

Ma baze podataka uopste nisu neka komplikovana stvar i ne treba ti nikakva teorija o tome, samo ti treba malo zdrave logike. Nisam do sada naleteo na sistem koji nije mogao da se normalizuje cistim logickim zakljucivanjem bez formalnog postupka.


Na to sam i mislio, denormalizacija ce ti sigurno kad tad trebati osim ako ne koristis neke manje baze.

Naravno.

Kod ER modela ti je ova veština sasvim nepotrebna.

Problem sa tim je sto u mnogim slucajevima nije prakticno jer npr. nekada iskljucis constraints kada znas da ces na ulazu da dobijes samo nove vrednosti ili kada znas da ce vrednost sigurno da postoji u parent tabeli a ne da proveravas foreign key. Ili stavis hints koji index da se koristi i radis mnoge druge optimizacije odgovarajucom strukturom podataka tako da bi imao denormalizaciju. U ER modelu si dosta ogranicen.

To je slicna prica kao rasprava o tome da li je bolje koristiti funkcionalne jezike ili imperativne. Naravno da je lepse za pisanje i citanje kada koristis deklarativni jezik i smanjujes mogucnost gresaka ali ipak to cesto nije nacin na koji mi razmisljamo pa nam na kraju ispadne ipak lakse da koristimo imperativni jezik, pogotovo sto tu mozemo eksplicitno da izaberemo postupak da se nesto uradi. Mikroprocesori rade sekvencijalno i zato su imperativni jezici bolji ako zelis efikasnost jer mi onda pravimo kod onako kako mislimo da procesoru najvise prija.

srki, rekao bih da ljudi razmisljaju u kombinaciji imperativnih i deklerativnih naredbi. Sasvim sam siguran da ce u buducnosti svi znacajniji jezici dobiti podrsku za funkcionalnu paradigmu i samim tim sadrzati obe. U ostalom, uzmi za primer bilo koji jezik i pogledaj f-ju koja vraca neku vrednost, sama konstrukcija je verovatno kombinacija imperativnih i deklarativnih naredbi, a poziv ka f-ji mozemo reci da je deklarativan. Jedino sto je u programskim jezicima imperativno su naredbe grananja (if, iif, ?, switch, case...) i petlje (mada to znaci goto na lowlevel-u u kombinaciji sa if-om). Sve ostalo jeste deklarativno, tj. kombinacija deklarativnog i imperativnog razmisljanja, mislim, samo treba analizirati recenice koje ljudi govore, sve je to apstrakcija nad apstrakcijom.

Elem, da ne filozofiram mnogo. Mislim da se u nekim stvarima slazem sa Fitopatolog-om ali sada kada ste protresli ovoliku teoriju nisam siguran sta je sta, jedini nacin je da se udubim u "praznu pricu" da bi shvatio o cemu se radi
Inace, ako je pravi relacioni model ono sto mislim, onda mislim - da tacno mislim da je relacioni model ipak dosta fleksibilan i sva mana koju Fitopatolog navodi dolazi od strane SURBP a ne relacionog modela.

Da me ne kritikujete kako favorizujem Codd-a, evo još jedno ime: P.Chen, tata od ER modeliranja.

:-)

_{[Ovu poruku je menjao Fitopatolog dana 19.12.2007. u 11:52 GMT+1]}

Eno ga Chen u MS labsovima, tako da je izgleda samo pitanje vremena kada ce SQL Server dobiti ER model.

Srećom, mi smo evo na vreme krenuli sa obnavljanjem ER modela...

Ova tema pocela je pitanjem o ER bazama. ER pricu je izmislio profesor Chen. Hava bogu, jos je ziv i jos uvek predaje. Neki njegovi papiri su na webu, za javnu upotrebu. Evo link na sajt sa originalnim papirima Dr. Chen-a:

http://bit.csc.lsu.edu/~chen/chen.html

:-)

Da ne zaboravimo i sledeće ljude:
- M.Stonebraker, napisao 13 pravila (ugledajući se na E.F.Codd-a) za proširenje relacionih baza u objektno-relacione;
- M.Atkinson, tata ODMG93 standarda koji definiše objektno-orijentisane baze.

;-)