Te stvari se ipak moraju naučiti iz knjiga, a kad zapne ....
E zato i postoje forumi slični ovom.
Kada stvarno uđeš u problematiku i zapneš na nekom problemu više ćeš da cijeniš zlatne savjete koji se nalaze na ovakvim forumima.
Ja lično sam pročitao tuce knjiga o bazama (što ti savjetujem da i sam učiniš ako te to već zanima), alat kojim se služim je moja glava, iskustvo, nos i ostalo.

savjet 1 :
Najbolje se uči na primjerima.

savjet 2 :
Ne možeš naučiti plivati ako ne skočiš u vodu.

savjet 3 :
Da bi našao sagovornika moraš postavljati konkretna pitanja.

Misim da si me pogrešno razumeo. Nisam ovo pitanje postavio iz ugla početnika u projektovanju, već iz ugla iskusnog profesionalca. Lično, koristim alatke kakav je ERwin ili Power Designer, te sam hteo da vidim sa kojim alatima rade ostale kolege i kakva su im iskustva sa tim drugim alatima (ukoliko ih ima).



Znanja iz ove oblasti sam sticao sa predavanja na fakultetu (predmeti Baze podataka i Softverski inženjering) i odgovarajuće stručne literature. Ako misliš da iole ozbiljan projekat možeš da uradiš u svojoj glavi, grdno se varaš. Osnovna stvar pri projektovanju je dokumentovanje i sistemski pristup.

Ne bih da dužim dalje.

Projektovanje baze je samo jedan mali segment iz projektovanje celog projekta, licnoe preferiram Dia koji radi fenomenalno posao sa UML diagramima, ali konkretna implementacija SQL koda najcesto sam pisem.

U svakom slucaju pretstavljanje problema sa UML diagramima je pocetak uspesnog projekta. Mogu samo svima preporuciti "Osnove objektnog modelinja - UML" autor je Alempije Veljovic i moze se naci u svim knizarama (jedino ako kao mene ne zivite u Yu, pa morate da se sluzite kopijama )

Pa, ne bih rekao. Projektovanje baza podataka odnosno funkcionalnog modela podataka predstavlja veoma važan segment ukupnog projekta nekog (naročito poslovnog) softverskog proizvoda, kao i naravno, model funkcija (procesa).

Spominjete UML dijagrame, pa treba reći da oni pripadaju objektno-orijentisanoj metodologiji, što je dosta različito od druge opšteprihvaćene metodologije - Strukturnog projektovanja (Tom De Marco) u koju spadaju i BSP, SADT, HIPO...

Ja lično preferiram ovaj drugi, strukturirani pristup projektovanju (zbog jednostavnosti i fleksibilnosti), jer se njim i najviše koristim. Naravno, ne treba favorizovati nijedan od ovih pristupa, bitno je samo striktno ispoštovati standardnu metodologiju koja je propisana. Koliko mogu da vidim iz Vašeg odgovora:



mislim da se ne pridržavate standardnih postupaka i njihove sledstvenosti, jer sam SQL kod predstavlja derivat jedne od faza projektovanja.

Projektovanje baze podata jeste samo jedan segment celog projekta i predstavjla odprilike petinu celog projektovanja, a niposto nisam rekao da nije znacajan segment.
Sam SQL kod predstavlja vazna faza implementacije ali ipak mislim da je najbolje taj deo ostaviti DB Administratora koji je normalno pozelno koristiti ERWin ili slicni alat.

Ali ako je dijagram dobro definiram samo je pitanje vremena ako koristis alat za modeliranje baze a ne radis implementaciju rucno. SQL kod, isto kao i programski kod u koriscenom jeziku se radi posle modeliranja sistema, i nije u zavisan od modeliranja u tom stepenu kojeg ga ti velicas.

Objektno modeliranje se opsto prihvacena metodologija modernih sistema koja je prevazisla strukturnog modeliranja, ali ipak je stvar ukusa koje da se koristi.

Mislim da me niste dobro razumeli, a i rečenice u odgovoru su Vam pomalo haotične:



Ono što sam hteo da istaknem u prethodnom odgovoru je potreba pridržavanja striktne metodologije projektovanja softverskih proizvoda i dokumentovanja svakog dela projekta. Projektovanje zasnovano na zdravom razumu, intuiciji, pa i (samo) iskustvu, prouzrokuju stihiju, neprofesionalni odnos i softverska rešenja veoma lošeg kvaliteta. Što nije teško utvrditi merenjem kvaliteta softverskih proizvoda, recimo metodom LSP koju je razvio prof. Jozo Dujmović sa beogradskog ETF-a.

Vi govorite o "projektovanju projekta", šta ste ovde imali u vidu? Projekat informacionog sistema? Projekat softverskog proizvoda? Ili nešto treće?

Kao što sam rekao SQL je sasvim sekundaran, a Vi ste ga naveli kao vrlo bitan deo.



Po ovome, projekatovanje softverskog proizvoda izvodite objektno-orijentisanom metodologijom, a zatim dokumentaciju predajete DBA da on dodatno "isprojektuje bazu podataka". Ukoliko se pridržavate principa bilo koje metodologije, DBA-u ostaje samo "daktilografski" deo posla koji on odrađuje na osnovu dostavljene dokumentacije. Ukoliko koristite neki projektantski (ima i drugih vrsta) CASE alat, možete izbaciti ovaj deo. Na programerima je sličan posao. Treba jasno odvojiti projektante od izvršilaca koji rade po specifikaciji projektne dokumentacije.

Da kažem i to kada već ulazimo u temu projektovanja softverskih proizvoda, da je neophodno da se već na samom početku odlučimo za Standarde kojih ćemo se pridržavati prilikom definisanja, vođenja izradom i načina upravljanja projektom (i dalje se misli na SW projekat). I ovde nema potrebe za mnogo lutanja, sve potrebne smernice za razvoj softvera su date međunarodnim standardom koji je lokalizovan kod nas - JUS ISO 9000:2001-3 Smernice za primenu ISO 9001 u razvoju, isporuci i održavanju softvera, kao i JUS ISO 6592 koji daje smernice za dokumentovanje aplikacionih rešenja zasnovanih na računarima.

Otprilike toliko, da ne dužim dalje.

Slazem u vezi sve sto si rekao, ipak je izgleda doslo do nesporazuma.



Osim za to da sve je daktilografski posao koji ostaje DBA-u, ipak ima puno optimizacije, denormalizacije i sl. sto treba da se uradi, ali grube crte projektovanje se moraju zapaziti.

Cek da ti ja odgovorim. Valjda ces malo bolje razumeti. Riste je izgleda morao da se slozi. Njegove recenice su pomalo haoticne samo zato sto ne barata srpskim jezikom kao ti. Inace, siguran sam da zna sta hoce da kaze i to sto hoce da kaze ima itekakvog smisla.

Strukturne metodologije i radovi Toma De Marca iz te oblasti su deo proslosti i znacajan deo IT istorije. Kao i COBOL, kao i PL/1. Bile su hit kada su se pojavile i ljudi su ih sa zahvalnoscu koristili jer su tako resili gomilu tadasnjih problema. A onda su shvatili da te metodologije, na zalost, imaju i nekih mana. Cak se pokazalo da su te mane tolike da se preslo na nesto drugo. Nesto novo. Tesko za verovati, zar ne? Deo tog neceg novog je i UML. Objektno orijentisane metodologije se ne porede sa strukturnim metodologijama kao dve alternative slicnih karakteristika, pa je onda stvar ukusa koja ce da se koristi. To su dva stadijuma u evoluciji. Kao reptili i sisari.

Sta je bio problem sa toliko obozavanim strukturnim metodologijama? Projekti radjeni na taj nacin su poceli sve vise da premasuju budzete i probijaju rokove i nekome se to nije dopalo. Jedan od vecih problema je bio sto su glavne faze projektovanja (analiza, dizajn, kodiranje, testiranje i deployment) bile jasno odvojene i nisu dopustale da se zahtevi korisnika mnogo menjaju jednom kada izrada projekta pocne. Dva meseca cemo da radimo analizu, pa dva meseca dizajn, pa cemo da kodiramo itd. itd. Zivot je na veliku zalost teoreticara i ponekih profesora malo drugaciji. Nije idealan, a i ljudi nisu Bogovi. Ne moze da se isprojektuje baza od 200 tabela i da onda pocne kodiranje. Cesto se desi da iz ovog ili onog razloga, baza ne zadovoljava sve zahteve korisnika. Ili neki od tih zahteva dodju kasnije, kada je baza gotova i kad imamo hiljade strana "projektne dokumentacije". Onda se to popravlja, a kod koji podrzava prethodnu verziju se baca. Programeri, naravno dobiju svoje pare, a projektnu dokumentaciju nose deci kuci kao papir da pisu i crtaju. Izgubljeno je i nesto vremena. I tako Jovo nanovo. Posle par izmena, jasno je da nesto ne valja. Ne pomazu cak ni dobro definisani ISO standardi koje cuvaju i njihovu primenu nadziru dve prvostepene i tri drugostepene komisije. Mozda je sve bilo jednostavno, ali je bilo daleko, daleko od fleksibilnog.

Danas, ko zeli da zavrsi to sto pocne, ne odvaja projektovanje od kodiranja, testiranja i deploymenta kao sto se to radilo nekada. Te faze i dalje postoje (ne kodira se nista dok se ne isplanira), ali se to radi malo drugacije. Uzme se mali funkcionalno kompletan deo domena, uradi se analiza, dizajn, kodiranje, instalacija i onda se predje na sledeci deo. Neki cak prave testove i pre nego sto je kod napisan. Onda opet tako - malo planiranja, malo dizajna, malo kodiranja, testiranja itd. Vrlo brzo po pocetku projekta mozete da pokazete nesto korisniku i ubedite ga da ne daje svoje pare uzalud. Korisnik cesto i ne zna sta tacno zeli dok nesto ne vidi i onda kaze sta mu se svidja, a sta ne. Kada se nesto buni i zeli izmene, te izmene se lako lokalizuju, jer su veze izmedju delova sistema dobro definisane i izmene u jednom delu sistema po pravilu imaju minimalan uticaj na ostale delove. Svet i dalje nije idealan i dalje ima problema, ali se pokazalo da su mnogo manji nego sto su bili ranije. Sledeci korak u "evoluciji" je AOSD (Aspect Oriented Software Development) i polako pocinje da se primenjuje, ali zbog krize u IT industriji sve ide dosta sporo.

Glavni predstavnik novijih metodologija je RUP (Rational Unified Process) i od pre par godina XP (eXtreme Programming). RUP je ogroman, dok su ostale, takozvane Agile Methodologies lakse i brzo se uce. Najbolje je sto ne morate da cekate sest meseci na prve opipljive rezultate svog (ili tudjeg) rada.

Ako slucajno nekoga to vise interesuje, poslacu par linkova.

Na kraju, koristim PowerDesigner i to sto je manje moguce. Kao sto Riste rece, sa tim moze da se dobije malo u vremenu i to je sve. Iskustva su mi pozitivna.

slazem se da standardi i slicno ne pomazu kada se radi na projektu sa vrlo ogranicenim budzetom, i koji u startu kasni koji mesec..

mislim, korisno je znati to (kao i bilo koje drugo znanje/iskustvo), ali svet nije tako idealan. mnogo puta se i u najozbiljnijim projektima neke funkcije "hackuju", samo da bi se projekat isporucio na vreme, i uzeo vazduh. posle se moze vratiti na doticni problem, ako je bash veliki hack, ali ponekad i ne..


elem, mene zanima XP u zadnje vreme. mnogo toga sam cuo, deluje prilicno fino, ali josh nisam bash do kraja sKvatio poJentu.. ako mozes nesto o tome... i ako znash neki real-world example...

Ne bih rekao da su deo prošlosti. I strukturne i OO metodologije "žive" zajedno već gotovo 30 godina. OOA/OOD nije ništa novo, prvi jezici (kao što je npr. i UML) i OO metodologije pojavile su se još sredinom 70-tih godina prošlog veka. Pa tako smo 1994. godine imali preko 50 OO metoda.

Ono što treba reći je da ove dve metodologije mogu da se kombinuju i da se na taj način potpuno iskoriste njihove prednosti, a istovremeno prevaziđu njihove mane. Za sistem analizu (modelovanje inform. tokova i sadržaja) najpogodnija je neka od tehnika SSA (SADT, MBA SSADM...) jer se ovom metodologijom funkcije sistema predstavljaju u formi transformacija informacija, a omogućen je i nezavisan timski rad.

Za dizajn je sigurno bolja neka od tehnika OOD, i to ne toliko u procesu razvoja (često je efikasnije koristiti strukturni dizajn) koliko u fazi održavanja o kojoj i Vi govorite.

Pravi efekti OOD se mogu uočiti upravo u fazi održavanja, a posebno ukoliko ima mnogo izmena i naknadnih zahteva. A zna se da ova faza "pokriva" od 70-80% ukupnih troškova razvoja.

Kada govorimo o dizajnu treba reći da se OOD-om formiraju objekti (sa spostvenim stanjima) koji se nalaze u međusobnoj interakciji i da se ovim dizajnom modeluju problemi, dok kod strukturnog dizajna formiramo skup funkcija koje dele jedno zajedničko stanje a krajnji ishod je modelovanje rešenja.

Mislim da smo se malo udaljili od osnovne teme, a to je modelovanje podataka, odnosno CASE alati koji potpomažu ovaj proces, ali ni to nije bitno - bitna je konstruktivna razmena mišljenja, što je i cilj ovog a foruma.

Inače, ukoliko imate saznanja o novim metodologijama i tehnikama, pošaljite linkove, ima zainteresovanih ;) .

OO metodologije su se pojavile i rasirile znatno kasnije od strukturnih, kao rezultat mana ovih potonjih, ali bih da izbegnem rasprave tipa "jeste-nije-jeste-nije"...Ima dosta radova koji se bave istorijom. Ako je bas zapelo, pokusacu da nadjem nesto.

Strukturne i OO metodologije mozda mogu da se kombinuju u teoriji ili kao mentalni eksperiment, ali ja zaista nisam video da to neko radi u stvarnom zivotu, niti sam nasao nesto o tome. Jako bih voleo da to malo elaboriras, mozda i sa primerima iz prakse. Tvorci raznih OO metodologija su uvek na krv i noz izmedju sebe, cak i na samu pomisao kombinovanja srodnih metodologija, a kamoli necega sto je u osnovi razlicito. Svako misli da je bas njegov (cisti i neizmenjeni) metod najbolji :)

Od mnogobrojnih OO metodologija od pre 7-8 godina, tri su se ipak ujedinile (firma Rational je zaposlila njihove tvorce i dala im dovoljno novca da prevazidju svoje sujete). To su Grady Booch, Ivar Jacobson i Jim Rumbaugh, poznatiji kao tri amigosa. Tako je (i tada) nastao UML. Prva specifikacija je, dakle, stara manje od 10 godina (tacnije 8). Pogledaj http://www.omg.org/uml. Mojne da pominjes 70-te.

Analiza, ako pretenduje da bude uspesna, ne bi trebalo da se bavi modelovanjem, vec jednostavno opisom delica realnog sveta koji je od interesa za softver koji se pise. Kazu da je cak je i termin Objektno Orijentisana Analiza kovanica, kako bi sve zvucalo "naucnije", impresionirao se zbunjeni korisnik i uzelo malo vise para. To sam nedavno cuo od Roberta Martina, jednog dedice koji se bavi tim stvarima (http://www.objectmentor.com/). U analizi se ne ulazi u to kako ce nesto da se implementira, kako ce nesto da se transformise ili kako ce timovi da se podele. Dovoljno je da se business process opise tek toliko da bi se napravio model. Nema klasa, nema objekata, nema funkcija. Business Analysts (oni koji rade analizu) cesto nemaju pojma o programskim jezicima i po struci mogu da budu recimo ekonomisti.

Ni u jednom trenutku nisam mislio na odrzavanje. To je prica za sebe. Korisnikovi zahtevi se cesto menjaju u toku samog projekta, kada je jos daleko od zavrsetka. Nema te strukturne metodologije koja to moze da izdrzi, a da ne probije budzet i rokove.



OOD-om se opisuju klase, a ne objekti. Objekti su instance klasa. Moj bato.

Evo par linkova:

http://www.aosd.net - Aspect Oriented Software Development. Ovo je nesto novo, nagovestaj onoga sto dolazi.

http://www.extremeprogramming.org
http://www.xprogramming.org - Extreme Programming (XP)

http://www.agilealliance.org/articles/index - XP je samo jedna od tzv. Agilnih metodologija. Ovo je sajt sa malo vise informacija o tome. Obratite paznju na Agile Manifesto.

http://members.aol.com/acockburn/ - sajt jednog od tvoraca novih metodologija. Nije profesor, ali ima malo vise iskustva iz realnog zivota :)

http://www.rational.com - RUP. Teska artiljerija i perjanica OO metodologija. Malo je teze snaci se na sajtu, ali vredi. Alati su im grozni. Mrzim Clear Case, a moram da radim sa njim.

Izvinjavam se ako sam nekoga uvredio. Ponekad volim da se pravim pametan. I nema persiranja.

Samo da potvrdim ovo u vezi alata firme Rational. Mi smo napravili žurku (bukvalno) kad su nam dozvolili da se sa Clear Case-a prebacimo na VSS (mada i VSS ima ozbiljnih ograničenja, ipak je daleko produktivniji). Što se tiče Rational Rose-a, ista priča - jedino što nije bilo žurke :)

Za one kojima je potreban software za projektovanje baza na MySQL-u toplo preporucujem DBDesigner koji postoji i za Windows i za Linux i besplatan je (GPL).

http://www.fabforce.net/downloads.php

On je vec pominjan u jednom drugom topicu (http://www.elitesecurity.org/tema/26254/0#181515) ali smatrao sam da treba da postoji link i za jedan MySQL alat ovde obzirom da je ovo TOP tema.

Pozdrav
Dinke

...ljudi - kako je ovo PAMETNO receno - NEMATE POJMA !!!

Mislim da komentare Last Man Standing-a (vrati se gore na 2 mesta), da sad' ne citiram nasiroko: koga interesuje nece mu biti tesko malo da vozi u rikverc...

Ja sam malo u zaksanjenju sa citanjem (iz objektivnih razloga koje mi je nametnuo subjektivni zivot), pa se izvinjavam na zakasnelom komentaru - al' prosto MORAM da kazem i ja koju...

(Samo da napomenem: meni su baze i hobi i posao; poceo sam od Spektruma i ne pusta me do danas... da, i na spekiju se moglo pakovati u podatke... nemam ni dana neke konkretne SQL skole, jedino sto zvanicno imam je Fortran IV sa faka, ali sam se se zato brale bas nacitao svega sto mi je doslo pod oko... da ne pricam jos oko toga, bilo je svega uglavnom... a i danas u 50 i nekoj vrtim po glavi tabele i kojesta jos... i koodiram baze, sta bi drugo...)

Elem - sustine svega je FLEKSIBILOST... Da li nesto iz problematike pisanja programa (da se izrazim prozaicno), moze biti zadovoljavajuce/dovoljno fleksibilno ? ... Ne moze... nikada... !!! ... Onim cuvenim hardverskim krilaticama da memorije i brzine nikad' dosta, moze slobodno da se napasuje i treca softverska: i fleksibilnosti nikad' dosta...

Ako ja, i oni posle mene, mogu LAKO da PRILAGODjAVAJU resenje/kood NOVIM zahtevima/uslovima - tada ce biti lako - odmah cak i NA POCETKU... Izvinite sto vicem velikim slovima, ali moram, toliko je citirano REALNO i PAMETNO i TACNO...

Kad' je rec o AOSD (Aspect Oriented Software Development) - joj majko kol'ko tu ima ISTINE !!! ... Otkud ja to sad'/pa znam (neki tamo matori levak bez skole) ? ... Znam, jer se sada vec odavno bivsi tim entuzijasta od njih 4-5 naveliko bavilo istim jos pre skoro 10 godina! ... Mnogo ? ... Nje ako se razmislja i svojom glavim: ODAVNO smo mi u tom timu prosto "osetili" da su sledeca velika stvar posle (cak!) Objektnog fazona - upravo Aspekti... jeste, namerno je veliko "A", iz postovanja... jer nismo ni svestni da su osnova nase raznolikosti u misljenju oko svega - upravo ti nareceni Aspekti: jedno te ISTO se vidi RAZLICITO samo zato sto se posmatra iz drugog ugla... to je sustina svih problema, ti "uglovi posmatranja": jedan vidi "ovako" a onaj drugi "onako"...

A za "PowerDesigner i to sto je manje moguce" - padni ma grudi brate rodjeni... ne zbog PowerDesigner-a vec zbog "sto je manje moguce"...

Jos jednom: BRAVO za Last Man Standing-a !!!

Offtopic: Jeli istina da ClearCase (cuo sam u prolazu od ljudi ga koji koriste) da se sa njim merge *uvek* radi ručno? Mislim na situacije kada dva čoveka izmene isti fajl.
Malo mi šašavo zvuči ali me baš zanima pošto se s vremena na vreme pojavi poneko ko pokušava da nas natera da koristimo baš ClearCase umesto CVS-a?

Odličan softver, a pri tom i besplatan.

ClearCase najpre pokusa da uradi merge automatski. Ako u tome ne uspe, onda prijavljuje problem i tek tada developer mora rucno da izabere sta ce se naci u rezultujucem fajlu (i to samo kod konfliktnih mesta). Ovo mozda zvuci strasno, ali ja nisam imao (toliko) losih iskustava sa tim, niti se to cesto desavalo. Problem nam se najcesce javljao ako se naprave izmene na kraju fajla.

Ono sto nije dobro, jeste sto ponekad ClearCase nije dovoljno pametan i ne uradi merge kako treba.

-zar je moguce da niko ovde ne radi sa Oracle Designer-om?

Radi, ceo PMF Novi Sad. Mada ja licno preferiram Rational Rose ili Power Designer (zbog MySQL-a).

Diskusija je malo zamrla, ali da dodam i ja nešto. Iako je tema software za prokjektovanje baza, priča je prešla na UML, pa ću i ja u tom pravcu.
Pošto su mi cilj Java aplikacije, kao alat za modeliranje koristim TogetherJ. Stao sam još kod davne verzije 4, sada je mislim aktuelna šestica. Čujem da ima dosta dobrih stvari u šestici, ali za mene je i četvorka još uvek najbolji alat.
Rational Rose je njesra, MagicDrawUML kako-tako, probajte TogetherJ pa ćete videti šta je alat.

Ljudi covek trazi software!
Evo jedan odlican!
CASE Studio 2.xx!
Odlican je!!!

Neko probao Visio for Enterprises Architect? jako je dobar.

Kad se vec prica o metodama, ORM nikome ne pada napamet. Dobro postavljen ORM model (ali dobro, nissam rekao odlicno) u principu zadovoljava 5NF i loko se verbalizuje.

Molim te objasni zasto je RR njesra, imas iskustva u radu mozda pa tvrdis. MOzda i jeste njesra za tebe koji pises Javu. ali barem budi objektivan

Pogledaj Clarion
4GL Rad alat
softvelocity.com
Postoji jos iz doba DOS-a
Mnogo ljudi ga koristi a cuti o tome.

Ovako treba mi neki SQL editor, builder tako nesto ali...
Naime naskidao sam se takvih programčića (dial-up, to je jos jedna otezavajuca okolnost) al' ni jedan ne radi ono sto mi treba. Primeri takvih programa su "DTM SQL editor(standard)", "urSQL", "FoxySQL"... Sa njima mogu da uradim samo neke osnovne stvari, tipa select, insert...
Meni treba neki koji podrzava:
1. Da se u WHERE uslovu spoljneg upita porede ne samo skalarne vrednosti nego i n-torke.
2. Eksplicitno navodjenje uslova spajanja tabela npr. SELECT [NESTO] FROM TAB1 CROSS JOIN TAB2 - ovo je dekartov proizvod koga u ovim programi mogu da ostvarim samp preko SELECT [NESTO] FROM TAB1, TAB2 - a to mi nikako ne odgovara
3....

Na baze se povezujem preko ODBC-a.
Savet, link bilo sta

Power designer je solidan ali kad se koristi za MSsql ima bugova ali sitnih.

Ja trenutno koristim DeZigner for Databases od firme Datanamic i moram priznati da je odlican. Lak za koristenje, pregledan i moze generisati skripte za kreiranje DB objekata i upita...

jel ima neki besplatan?

Na fakultetu za informatiku u Novom Pazaru se baze podataka rade u Accesu, koliko je to efikasno i da li je dovoljno efektivno za pocetnike?

Ja na poslu koristim SAMO oracle designer.

Na faxu sam koristio ERWin i PowerDesigner.

Krenuo sam pre nekog vremena na kurs koji organizuje Oracle na mom fakultetu (Geografski fakultet, nema veze sa IT temama). Polako počinjem da ulazim u celu priču vezanu za dizajn baza podataka. Neko je na temi Teorija vs. praksa pomenuo grafičke alate pomoću kojih je moguće vizuelno predstaviti ERDove. Možete li mi preporučiti neke, jer sad u word-u crtkam softbox-ove i relacije i muka mi je od autoshape-ova...