Teorija Vs. Praksa

[ chachka @ 17.07.2006. 11:39 ] @

Citat:

broker:
Cacka, bez ljutnje, ali ovakav pristup pokazuje neiskustvo.

Neljutim se, jer se uvek prica izmedju muskaraca svodi na to ko ima veci.

Citat:

broker:
Sasvim je normalno da u ima mnogo polja za koja korisnik aplikacije ne mora uopste da ni dapostoje a kamoli da zna kakva im je svrha.

Normalno je da postoji masa parametara koji sluze radu aplikacije, radu Windows-a, radu kompjutera, ali su ti parametri u sluzbi resavanja problema, a nisu deo samog problema (sistema koji se automatizuje).

Baze podataka su i nastale kao potreba za nezavisnoscu podataka od aplikacija.

Citat:

broker:
Model baze se ne menja tek tako, zbog toga je neophodno da se pre projektovanja sagledaju sve potrebe i model napravi tako da ih ispuni, a ako postoje potrebe koje u datom momentu ne mogu da se artikulisu, treba ih prepoznati kao takve i u modelu ostaviti prostor da se moze prosiriti bez velikih intervencija. Najvaznje je obezbediti da prosirenja baze ne menjaju postojece relaciej izmedju tabela, vec da se uglavnom svode na dpodavanej novih polja ili celih novih tabela sa novim relacijama koje se uklapaju u postojeci model.

Kazes urbanisti Uzica:

"Majstore ovo je dosadasnji urbanisticki plan grada. Nesmes da srusis ni jednu zgradu, ni jednu kucu. Namoj slucajno da izvadis drvo, ako ti zasmenta pri izgradnji puta. Mozes da dodajes nove zgrade i puteve na periferiji grada, mozes da farbas postojece zgrade u raznim bojama, da krpis puteve i da zalivas parkove."

"Usput posto mi neznamo sta hocemo, isplaniraj ti nama lepo i prostor za metro, i fudbalski teren koji prima 200.000 posetilaca, i prostor za nuklearnu centralu, i kosmodrom koji je veci od NASA-inog, jednom recju isplaniraj ti nama SVE."

"I nemoj da gresis u projektovanju, jer cemo ti posle dozvoliti samo da menjas boju crepa na krovovima, a ako bas imas potrebe, velikodusno cemo ti dozvoliti da naknadno odredis prostor za jos jednu policijsku stanicu."

"To sto sada isplaniras MORA da traje 15000 godina, ima da nadzivimo i Keopsovu piramidu."

Sta ce ti urbanista na to odgovoriti?

[ Miloš Baić @ 17.07.2006. 12:46 ] @

Citat:

"Majstore ovo je dosadasnji urbanisticki plan grada. Nesmes da srusis ni jednu zgradu, ni jednu kucu. Namoj slucajno da izvadis drvo, ako ti zasmenta pri izgradnji puta. Mozes da dodajes nove zgrade i puteve na periferiji grada, mozes da farbas postojece zgrade u raznim bojama, da krpis puteve i da zalivas parkove."

"Usput posto mi neznamo sta hocemo, isplaniraj ti nama lepo i prostor za metro, i fudbalski teren koji prima 200.000 posetilaca, i prostor za nuklearnu centralu, i kosmodrom koji je veci od NASA-inog, jednom recju isplaniraj ti nama SVE."

"I nemoj da gresis u projektovanju, jer cemo ti posle dozvoliti samo da menjas boju crepa na krovovima, a ako bas imas potrebe, velikodusno cemo ti dozvoliti da naknadno odredis prostor za jos jednu policijsku stanicu."

"To sto sada isplaniras MORA da traje 15000 godina, ima da nadzivimo i Keopsovu piramidu."

Sta ce ti urbanista na to odgovoriti?

Svidja mi se odgovor...

Citat:

Ne ljutim se, jer se uvek prica izmedju muskaraca svodi na to ko ima veci.

Slažem se s ovom konstatacijom...

[ jablan @ 17.07.2006. 13:00 ] @

chacka, poređenje ti je samo prividno na mestu. Zna se otprilike verovatnoća, sa jedne strane da se proširi model ili dodaju neka informativna polja na tabelu (prilična) i sa druge strane da Užice naprasno započne svemirski program (zanemarljiva).
Nije jedina svrha baze nezavisnost podataka od aplikacije. Primarna svrha baze je brzo i pouzdano baratanje perzistentnim podacima.

Pri modeliranju baze uvek se pravi kompromis između realnog (seka iz knjigovodstva) i aplikativnog (bata programer) modela. Ako ja imam složeni ključ od 3 ili 4 polja i u svakom upitu sam prinuđen da pišem par dodatnih uslova u where delu, normalno je da ću da dodam surogat ključ. Ili ako se moj aplikativni model svejedno zasniva na jedinstvenom ključu, logično mi je da ga prenesem i u bazu.

[ Dejan Topalovic @ 17.07.2006. 13:01 ] @

Citat:

broker: Model baze se ne menja tek tako, zbog toga je neophodno da se pre projektovanja sagledaju sve potrebe i model napravi tako da ih ispuni, a ako postoje potrebe koje u datom momentu ne mogu da se artikulisu, treba ih prepoznati kao takve i u modelu ostaviti prostor da se moze prosiriti bez velikih intervencija. Najvaznje je obezbediti da prosirenja baze ne menjaju postojece relaciej izmedju tabela, vec da se uglavnom svode na dpodavanej novih polja ili celih novih tabela sa novim relacijama koje se uklapaju u postojeci model.

chacka je uz opisnu analogiju dao odlican odgovor, a ja bih samo jos dodao, da u praksi jos nisam sreo bazu, ciji osnovni dio vremenom nije barem malkice promijenjen. Osim toga, koji poslodavac ce ti platiti da mu radis nesto prekompleksno i ono sta mozda nikad nece koristiti?

Proces poslovanja se mijenja vremenom, dodaju se nove stvari, izbacuju zastarjele i suvisne. Samim tim moras mijenjati i dizajn baze.

Cak i ako se server sa bazom mora resetovati, izmjene su katkad neminovne.

Brzi edit: Ja inace ne koristim kompleksne surogat kljuceve, jer zelim imati sto jednostavniji i pregledniji dizajn baze. Dakle, moja opcija bi bila:
Radnik_Zadatak(RadnikID, ZadatakID)

[ broker @ 17.07.2006. 13:26 ] @

Ljudi, ne ide nikuda ako svoje stanoviste zelite da dokazujete koristeci bukvalna tumacenja i drasticne primere koji samo naizgled imaju veze sa temom. Ako vi projektujete model sa stanovistem da nije bitno da li cete za neke inace sitne dorade morati ceo modela da preradujete, onda negde debelo gresite.

Sam stav "o tome cu da razmisljam kada se problem pojavi" je prilicno neobican za nekoga ko se predstavlja da zna da projektuje baze podataka.

Ja nisam pricao o korenitim promenama nego o nadogradnjama postojeceg modela koje bi trebale da budu bezbolne za postojeci sistem. Takve dorade projektant treba da predvidi, naravno ne bukvalno, nego nacelno i da u modelu ostavi prostor da moze da ih implementira a da ne prekraja ceo model.

Ako vam se desi da narucilac zatrazi nesto sto zahteva korenitu promenu na bazi to je ili znak da ste LOSE obavili svoj posao projektanta ili da naruciocu treba napraviti potpuno novu bazu jer se novi posao ne moze obaviti kroz staru bazu.

Prosto receno: svaka korenita izmena na modelu baze nakon sto je ona isprojektovana i realizovana je znak da je negde napravljena greska: ili narucilac nije dao dovoljno podataka u projektom zahtevu, ili projektant nije dovoljno dobro sagledao sve zadatke koje baza treba da obavlja.

[ Dejan Topalovic @ 17.07.2006. 14:11 ] @

@broker: Sorry, ali ti kao da nemas prakse u dizajniranju baza podataka, nego sve govoris samo iz teorije, koja bi u svim slucajevima trebala biti idealna i u praksi, mislim ako si nesto procitao u knjizi, ne mora znaciti da se to mora i moze tako odraditi i u praksi.

Evo, navescu ti samo jedan primjer...

Za Telekom Austria je davno radjen kompletan OSS/BSS sistem zasnovan na Oracleu. Odredjeni dio aplikacija je radio u Perlu ili C-u (Pro C), a i nije bilo ADSL-a i ostalih novih tehnologija... Menadzeri i glavni projekt lideri su kreirali projektnu dokumentaciju i osmislili funkcionalnost sistema, trudeci se obuhvatiti/pokriti sto je moguce vise planiranih zahtjeva, ostavljajuci mjesta i fleksibilnim izmjenama. Godinama su se izvrsavale sitne izmjene, takoreci "patch na patch". Ali tehnologija se mijenja, pa je i Telekom Austria morao promijeniti funkcionalnost svog sistema.

Kako god projektanti tada projektovali bazu, nemoguce je bilo isplanirati i pokriti sve moguce situacije obrade podataka. Prosle godine je zapoceta generalka - veliki dio sistema je poboljsan, prepravljen, izmijenjeno je nekoliko glavnih tabela, dodana je hrpa aplikativnog kôda (PL/SQL, Java i td.)...

Da samo znas, koliko su se prakticna rjesenja razlikovala od teoretskih...

Jedino sto se slazem je to, da takve velike izmjene treba posebno naplatiti, sto je ovom prilikom i dogovoreno. Jedno je ugovor o odrzavanju, a drugo je ugovor o velikim izmjenama u sistemu.

Brzi edit: Npr. u teoriji se navodi, da je dobro dizajnirana baza samo ona, koja ima nivo normalizacije veci od 2 (npr. 2 NF, 3 NF ...), ali iznenadio bi se koliko se denormalizacijom visoko normalizovanih tabela (sa 3 NF na 1 NF) dobija na performansama, pogotovo ako se radi o Data Warehouse sistemu, gdje su ucestali full table scanovi, pa je brze i optimalnije ucitati vise blokova odjednom IZ JEDNE TABELE nego slati upite ka vise normalizovanih tabela.
Ili slucaj, kada je u OLTP okruzenju pozeljno imati visoko normalizovane tabele...

[ Miloš Baić @ 17.07.2006. 14:38 ] @

Pozdrav,

samo jedan mali komentar...
Na fax-u nas uče teoriju i to ne baš nešto konkretno. Ali neke konkretne stvari,
kao projektovanje baze se ipak uči u praksi. Moj stav je sledeći, svaka čast
teoretskom znanju koje stičemo na fax-u, ali prednost ipak dajem ljudima koji
rade sa BP i imaju dugogodišnje iskustvo. A ako su još iskustvo stekli na nekim
velikim projektima, stvarno su majstori.
Ne trebamo pokazivati, ko ima veći, nego svojim argumentima ubediti zašto je nešto bolje
i nemati toliki ego da ne priznamo tu činjenicu...
Za mene, ako neko ima bolje, optimalnije rešenje je poklon jer tada stičem nešto novo
što nisam sam mogao skontati, naravno, ako me ubedi da je to stvarno bolje rešenje...

Nadam se da nisam izašao iz teme...

[ broker @ 17.07.2006. 14:55 ] @

Dejane, ja pricam upravo na osnovu dugog niza godina prakticnog iskustva.

Uostalom, upravo primeri koje smo dali pokazuju da iskustva iz prakse navode na resenja koja nisu skolska i objasnili zbog cega.

Ti uporno navodis primere koji su predstavljaju drasticne izmene. Ja sam na terenu nebrojeno puta video baze podataka prepune zakrpa koje samo drze vodu, jer u osnovi sistem nije dobro osmisljen i nije bio fleksibilan za sitne izmene. Kad su krupne izmene u pitanju prica je sasvim druga, rasturis to sto imas i napravis iznova gledajuci da iskoristis podatke iz ranijeg modela. Ne mozes to porediti sa doradama modela o kojima mi ovde pricamo.

Uostalom, covek je pitao zasto postoje dva nacina resavanja problema na koji je naisao, i to mu je objasnjeno. Koji ce on da primeni zavisi od toga sta ce dalje biti sa tim modelom koji radi, a ne od necijih afiniteta.

[ Zidar @ 17.07.2006. 14:59 ] @

Citat:

Pri modeliranju baze uvek se pravi kompromis između realnog (seka iz knjigovodstva) i aplikativnog (bata programer) modela. Ako ja imam složeni ključ od 3 ili 4 polja i u svakom upitu sam prinuđen da pišem par dodatnih uslova u where delu, normalno je da ću da dodam surogat ključ.

Druga recenica iz citata objasnjava zasto se koriste surogatni kljucevi - zato sto progarmera mrzi da pise JOIN i WHERE po nekoliko kolona umasto po jednoj. Pa sta ako moras da pises par ddatnih uslova/ To je tvoj posao za koji si placen. tesko/ Tough luck. Uvodjenje surogat kljuca otvara vrata za nevidjene stvari. Recimo,

Zadaci (SurogatID PK, RadnikID, ZadatakID) dozvoljava da se za RadnikId=1 i zdatakID=5 odradi ovo:

INSERT INTO Zadaci VALUES (1,1,5)
INSERT INTO Zadaci VALUES (2,1,5)
INSERT INTO Zadaci VALUES (3,1,5)
INSERT INTO Zadaci VALUES (4,1,5)
INSERT INTO Zadaci VALUES (5,1,5)

Znaci, 5 redova, isti radnik, isti zadatak. i sve je OK, jer zaboga PK je unique. Naravno, ovo ne dozvoljavamo u praksi, pa onda dodamo jos jedan unique index (RadnikID, ZadatakID). Eto, nema vise duplikata. jeste, ali imamo i dva indeksa. jedan po SurogatID, verovatno je taj i CLUSTERED, i jos jedan (RadnikID,ZadatakID), kpji nije clustered. I gde je tu performance improvement? Viska polje, koje je INT ili cak LongINt, dva indeksa. jedino poboljsanje jeste sto je naoko progarmeru lakse da napise JOIN kao

JOIN ON Zadaci AS Z ON Z.SurogatID=NekaTabela.SurogatID

umesto

JOIN ON Zadaci AS Z ON Z.RadnikID=NekaTableaRAdnik.ID AND Z.ZadatakID = NekaTabela.ZadatakID

I naravno, NekaTable imala bi samo SurohgatID za vezu sa Zadaci. Eto ustede - jedno polje se migrira u child tabelu, umesto dva.

amislite tableu IstorijaZadatka u koju se belzi sta je i kada uradjeno na nekom zadatku. Parent table je Zadaci a child atbela je IstorijaZadatka.
Varijanta 1: IstorijaZadatka (SurogatID,DAtum,StajUradjeno)
Ptanje glasi: Prikazati sve sta je neki radnik uradio i akda je uradio.
Posto imamo samo SurogatID za vezu sa Zadaci, onda nam je nophodan kveri da nam pklaze KOJI ranik je odradio Jednostavan SELECT koji daje sta nam treba:

SELECT I.SurogatID, I.DAtum, I.StajUradjeno, Z.radnikID
FROM IstorijaZadatka AS I
JOIN Zadaci ON I.SurogatID=Zadaci.SurogatID

Varijanta 2: IstorijaZadatka (RadnikID, ZadatakID, Datum, Sta jeUradjeno)
U ovom slucaju nam NE TREBA kveri koji povezujeIstorijaZadatka sa Zadaci. Select bi zigledao ovako:

SELECT RadnikID, ZadatakID, Datum, Sta jeUradjeno
FROM IstorijaZadatka

SELECT je select neko ce reci. Da li bas? Otkad je SELECT koji ima JOIN brrzi od selecta koji nema JOIN?

Znaci, upravo kveri za koji sebi pokusavata da olaksate pisanje, nece vam ni trebati ako migrirate slozeni kljucu child tabelu. Lakse je ne pisati kveri uopste, nego pisati najjednostavniji moguci kveri. Eto, i programer profitira ako se migrira slozeni kluc :-)

Ovo nisam ja izmislio, E. Codd je jos pre trideset godina rekao da se migrira ceo PK iz parent u child tabele. Onda je neko ustvrdio da je to teoretisanje i da je brze raditi sa surogat kljucevima. Mozda je tako bilo pre trideset godina, kompjuteri su bili sporiji i diskovi skuplji.

Nazalost, bez surogata se ne moze. Ima situacija kada u realnom sistemu ne postoji nista sto bi jednoznacno odredilo red u tabeli. Na primer - kasa u samousluzi. Racun koji dobijete je modelovan tabelom StavkeRacuna. Nije dobro da su stavke racuna modelovane ovako:

StavkeRacuna (RacunID, ArtiklID,Kolicina) PK (RacunID, ARtiklID)

Zasto? Pa svaki artikl moze da se pojavi na racunu tacno jedamput. Ako je korpa velika, i kupili ste 10 identicnih jogurta, ne znaci da ce kasir da skenira jedan i onda unese kolicinu. Kasir skenitra svaki artikl. Znaci, za 10 identicnih jogurta treba 10 redova u tabeli. Tu nam treba nesto da dobijemo PK. Nekakav brojac artikala na racunu. Ako ne prikazujemo taj brojac na racunu (redni broj artikla) onda je OK da stavimo na primer neki identity koji ce da obezbedi jedinstvenost. Ali, ako nam treba brojac stavki, i da ide od 1 pa nadalje, onda opet ne moze surogat key, mora da se nekako obezbedi brojac od 1 do N.

[ Dejan Topalovic @ 17.07.2006. 15:10 ] @

@Zidar: Da, u toj namjeni je surogatni kljuc itekako pozeljan. Medjutim, u slucaju Radnik i Zadatak surogatni kljuc ti ne treba, jer ne bi imalo smisla da jednom Radniku dodijelis 10 puta isti zadatak, zar ne? :)
Osim ako imas Radnika, koji npr. svakih sat vremena obavlja jedan te isti zadatak, pa zelis za svaku tu kombinaciju osigurati jedinstvenost...
No, kako god okrenes, sve se svodi na rjesenje individualne namjene...

[ jablan @ 17.07.2006. 15:43 ] @

Citat:

Zidar: Druga recenica iz citata objasnjava zasto se koriste surogatni kljucevi - zato sto progarmera mrzi da pise JOIN i WHERE po nekoliko kolona umasto po jednoj. Pa sta ako moras da pises par ddatnih uslova/ To je tvoj posao za koji si placen. tesko/ Tough luck. Uvodjenje surogat kljuca otvara vrata za nevidjene stvari.

Hm, nije u redu da ovako implantiraš... ;) Nije (uvek) u pitanju lenjost. Ima nešto i u kratkoći (ergo jasnoći) kôda i smanjenju mogućnosti greške. Pored toga, može da postoji još ceo spektar razloga koji su uslovljeni aplikativnim rešenjem, a koje ovde nismo ni pominjali.

Primeri koje si naveo stoje, ali su odabrani tako da ističu loše strane surogat ključeva. Poenta je upravo u tome da je model baze kompromis - nekad je bezbolnije/brže/praktičnije koristiti pun ključ, a nekad ne.

[ chachka @ 17.07.2006. 16:05 ] @

Citat:

loshmiscg:
Moj stav je sledeći, svaka čast teoretskom znanju koje stičemo na fax-u, ali prednost ipak dajem ljudima koji rade sa BP i imaju dugogodišnje iskustvo.

Teorija ti treba da bi vozio bicikl s motorom, teorija ti treba da bi postao kuvar, teorija ti treba da bi bio sef gradilista, da bi bio advokat, zubni tehnicar... Ali da bi bio programer teorija ti netreba. Dovoljna je samo praksa. Cak je dovoljna praksa od 3 godine igranja video igara pa da u komsiluku steknes status "mali je haker, zna sve o kompjuterima", a onda se to siri poput lavine.

Problem programiranja je u tome sto su svi koji se bave, zive od programiranja poput James Bond-a - svi imaju "Licence to Kill".

[ jablan @ 17.07.2006. 16:24 ] @

Citat:

chachka: Problem programiranja je u tome sto su svi koji se bave, zive od programiranja poput James Bond-a - svi imaju "Licence to Kill".

Ja te ne razumem, pojasni malo ako nije problem.

Inače, ne znam nijednu kevu koja je završila za kuvaricu, pa su opet keve poznate kao dobre kuvarice. ;)

[ amladjo @ 17.07.2006. 17:24 ] @

Citat:

chachka: Teorija ti treba da bi vozio bicikl s motorom, teorija ti treba da bi postao kuvar, teorija ti treba da bi bio sef gradilista, da bi bio advokat, zubni tehnicar... Ali da bi bio programer teorija ti netreba. Dovoljna je samo praksa. Cak je dovoljna praksa od 3 godine igranja video igara pa da u komsiluku steknes status "mali je haker, zna sve o kompjuterima", a onda se to siri poput lavine.

Još nisam sreo čoveka koji je "pročitao iz knjiga" kako se kuva... i kuvao bolje od onih koji "nisu čitali knjige" nego samo voleli svoj posao. Primeri su ti skroz pogrešni i negde si jednostavno promašio suštinu.

Teorija je osnova, pa makar to bilo samo usmeno "sedneš na biciklu i pritisneš ovo", praksa je sve ostalo.
Nemoj zaboraviti da je sva teorija nastala iz prakse. I još uvek nastaje. Ovaj forum je primer za to.

U mnogo slučajeva je teorija nezamenjiva u mnogo slučajeva je to praksa, govorim konkretno za programiranje. Najbolje je kada pronađeš "dobitnu kombinaciju" i iskoristiš i teoriju i praksu.

Citat:

chachka: Problem programiranja je u tome sto su svi koji se bave, zive od programiranja poput James Bond-a - svi imaju "Licence to Kill".

Nemam komentar, pa ti nas i ne poznaješ.

[ Miloš Baić @ 17.07.2006. 17:52 ] @

Još jedan mali komentar...
Potrudite se da ovo ne pređe u neko vređanje, .etc!!!

Jasno je, da školovani programeri, ETF, PMF, ..., .etc, su traženiji i cenjeniji od samoukih. Bar je moje iskustvo takvo, nek mi ne zamere oni koji nisu školovani programeri a znaju i imaju puno iskustva...
Po meni, dobitna kombinacija profesionalca u ovom poslu, jeste završen fakultet te branše sa najmanje 5 godina iskustva u tom poslu na velikim projektima. Mislim da su to ljudi koji nam mogu reći šta je i zašto najbolje odraditi.
Još jednom, ne sumnjam u znanje i samoukih programera, samo ovima dajem prednost.

BTW, praksa je teorija, teorija je nastala iz prakse... I sve se vrti oko iste stvari, shvatiti ono što radiš, iz prakse ili teorije, nebitno je.

P.S. BP treba projektovati tako da izmene, suštinske ili neke manje, koje vršimo budu što manje bolne i po nas i po korisnika baze. A za to treba odlično poznavanje teorije i veliko iskustvo u praksi.

[ Zidar @ 17.07.2006. 19:28 ] @

Za Dejana

Citat:

Osim ako imas Radnika, koji npr. svakih sat vremena obavlja jedan te isti zadatak, pa zelis za svaku tu kombinaciju osigurati jedinstvenost...

To sam i pokusao da kazem, ali sam kao i obicno otisao u sirinu, pa se izgubilo

Surogat PK dozvoljava da jednom radniku dodelis isti zadatak 10 (a i vise ;-) I zato ga ne volim i upotrebim ga samo kad bas nema nista drugo

Za Jablana: ne ljuti se, nista licno. I ja sam kriv za isti greh, imam gomilu projekata gde sam upotrebio surogat key, a da nije moralo. I uvek mi se to obilo o glavu, pa sam jednog dana shvatio zasto. Sto se tice primera Radnik-Zadatak - taj primer je dat na pocetku, pa rekoh ajde da to iskoristimo. Bez obzira koji problem razmatramo, ako nemas drugih kljuceva (Alternativni kljuc) osim surogata, uvek mozes da visestruko uneses jedan isti red. Vazi dakle u SVAKOM slucaju. Proizilazi da je to dakle samo ponekad dobra stvar (samousluga), inace ne valja. Iz toga sledi da surogat kljucevi ne valjaju u vecini slucajeva.

To sto programeri svesno prekrse norme teorije rezultat je upravo toga sto je svako 'lecenced to kill'. Pre nego sto sam postao ovo sto jesam bio sam gradjevinski inzenjer. Kad nacrtam zgradu, most ili vodovod, morao sam da objasnim sta sam uradio, zasto sam to uradio, zasto sam izabrao resenje A a ne resenje B, i naravno da sve potvrdim proracunima, koji uglavnom slede iz teorije. I da sve to potpisem. I jos neko stariji od mene je to morao da pregleda i potvrdi da sam ja postovao propise i praksu. Bio je papir na pocetku projekta gde stariji inzenjer kaze : "Ja, Patar Tomic, potvrdjujem da je Zidar uradio ovaj projekat u skladu sa zakonom i nacelima gradjevinske prakse. Potvrdjuem da sam pregledao i prekontrolisao rad." I onda, ako nesto ne valja, padne zgrada ili se raspukne cevovod, moj kolega Petar Tomic i ja idemo na robiju. Nekeo smo uspeli da nam se ne srusi ni jedna zgrada ni most i nikad nismo bili na robiji

A ljudi ko ljudi, cesto svesno krse norme i opstepoznate mudrosti. Svi znaju da pusenje ubija, opet ljudi puse. Ili piju pa voze i slicne stvari. Pa sto ne bi koristili surogat kljuceve, iako ne valja? Bar nikog nece ubiti

[ jablan @ 17.07.2006. 20:03 ] @

Čekaj malo, Zidar... Sad ispade da je uvođenje surogat ključa prekršaj i samo je pitanje trenutka kad će nekom da se baza sa surogat ključevima sruši na glavu... Pa valjda je stoput rečeno da se nekad normalizacija svesno krši, tj. ne ide do kraja po knjizi, iz najrazličitijih razloga. I sam kažeš da programeri često uvode surogat ključeve. Za to mora da imaju neki razlog, zar ne? Pa i lenjost je neki razlog: čovek hoće da piše manje koda, brže završi, smanji moguće greške u budućnosti, poveća čitljivost upita, olakša mapiranje aplikativnog modela na model podataka itd itd. Nekad postoji stvarno dosta razloga za uvođenje surogat ključa. I naravno da se u tom slučaju, kao što si lepo objasnio, dodaje UNIQUE indeks kako bi se sprečilo unošenje duplih ključeva.

[ chachka @ 17.07.2006. 20:47 ] @

Citat:

amladjo: Nemoj zaboraviti da je sva teorija nastala iz prakse.

Ma nemam ja nista protiv prakse. Cim radim bavim se i praksom :)
Ali se mora imati veca ili manja doza teorije. Po meni je lakse ako teorija ide pre prakse.

Citat:

jablan: Ja te ne razumem, pojasni malo ako nije problem.

U mnogim granama ljudskog rada postoje strucni ispiti, drzavni ispiti, dozvole za rad, inspekcije (komunalna, zdravstvena,...) , policije (saobracajna, finansijska,... ). Znaci postoje provere znanja, provere rada i sankcionisanje nemara. Nista od toga ne postoji u IT sektoru. (Ovde preskacem MS, Oracle, CISCO,... sertifikate jer iza njih stoje kompanijski komercijalni interesi)

U IT sektoru je dopusteno da radi ko hoce i sta hoce. Stavimo na pocetku programa "Autor ne odgovara za greske nastale u radu programa" i ne boli nas glava. Koliko programera znate da im je sudjeno za programe koji su lose obavljali posao zbog kojih su napisani? Program lose obracuna porez, programer nije kriv pred zakonom, program lose regulise svetlosnu signalizaciju i prouzrokuje saobracajnu nesrecu, programer nije kriv pred zakonom. Programeru se skida s plate, dobija otkaz (i odlazi u drugu firmu :)), ali ne odgovara pred zakonom.

Ponta "Licence to Kill" je da nam je dopusteno da radimo sta hocemo, bez vecih posledica.

Srdjan

PS: Zaista nikoga ovim ne prozivam, cak sam i sebe svrsta u celu pricu upotrebom "mi", "nas", neodredjenog "programer" . Pozdrav killer-ima :)

PPS: Predhodan i ovaj post su mi skroz offtopic. Zbog toga vise necu nastavljati ovu granu diskusije.

[ jablan @ 17.07.2006. 23:36 ] @

Nemam ništa protiv offtopica, kad je ovako interesantan. A i topic nam se manje-više istrošio...

U prvoj poruci bio si nejasan, pominjao si teoriju. Ni građevincima nije dovoljno da završe fakultet da bi mogli da lupaju pečat na projekte... Niti je diploma garancija da se nekom od njih neće srušiti most ili pasti pijani radnik sa skele. Doslednost i sistematičnost u poslu (svakom poslu) nije nešto što se uči iz knjige (mada fakulteti, kursevi, sertifikati teško mogu da škode).

Što se tiče programera, tačno je da nisu opterećeni prevelikom odgovornošću. Ali nije tačno da njihovi propusti prolaze bez posledica. Tržište je to koje osigurava kvalitet, ukratko rečeno: napravi drljav program i niko ga neće kupiti dvaput. Firma koja drži do sebe će vremenom obezbediti sistem kvaliteta koji će se odraziti i na programerski tim - sistem revizije kôda od strane starijih programera, pažljiva selekcija pri zapošljavanju i permanentno obrazovanje ipak daju neke garancije kupcu da mu se program neće srušiti na glavu.

Da se vratim na teoriju: postoji mnogo faktora koji prave razliku između dobrih i loših inžinjera, kao i mnogo različitih puteva do veštine: neko nauči neke stvari kroz 10 godina iskustva, neko te iste stvari nauči za 6 meseci iz knjiga, neko istu knjigu mrljavi 10 godina i ne nauči ništa... Programiranje je možda najilustrativnija oblast za ispoljavanje individualnih razlika: dokazano je da su oni najbolji i za red veličine produktivniji od onih prosečnih.

[ amladjo @ 18.07.2006. 00:48 ] @

Shvatam da vam se ideja dodatnog ključa tipa Radnik_Zadatak(ID,RadnikID,ZadatakID,...) ne sviđa.
Pronalaženje dokaza u upoređivanju sa građevinom, pušenjem i lošom IT strukturom i zaključivanjem da se te teorije treba držati "po svaku cenu" također mogu shvatiti kao Vaš lični izbor, naravno da na njega imate pravo.
Ne slažem se Vašim upoređivanjem.
Projektovanje baze, o čemu sve vreme pričamo, nije tako jednostrano. Moje iskustvo je pokazalo da je manja greška dodati takav ključ nego ostati bez njega. Vaše iskustvo (ili neiskustvo - nije na meni da sudim) je drugačije i drago mi je zbog toga

- niste ni svesni koliko imate sreće.
Onog trenutka kada se ustanove pravila da za sve mora postojati projekat i kada samo školovani i stručni kadrovi budu mogli da rade ovaj posao i kada svako bude odgovarao za svoje greške - ja ću biti prvi koji će to podržati. Do tada, niko me i ne pita, moram da se snalazim kako umem i znam i stvaram nemoguće. I bez obzira na sve uvek odgovaram za svoje greške i neispravno izvršavanje programa.
Da sam se toliko striktno držao teorije na koju sam u početku naučen ne bih stvorio ništa, ili preciznije, ako ćemo o materijalizmu - ništa vredno.

Da se vratim primeru,

1. Način (RadnikID,ZadatakID)
2. Način (ID,RadnikID,ZadatakID)

Ako ću raditi na projektovanju baze koja će biti dinamična i sklona stalnim izmenama - obavezno upotrebljavam 2. način.
Ako ću raditi na projektovanju baze koja će biti statična (imam projekat, ne marim za šefa ili šef za mene - govorim o šefu iz prethodnih postova) i ako moram da obezbedim N:M vezu bez dodatnih atributa upotrebiću 1. način.
Dodatno, ako u tabeli koja čuva vezu tipa N:M između neke druge dve tabele imam (ili planiram da imam) dodatna polja (atribute) koja pobliže objašnjavaju izvedenu vezu obavezno upotrebljavam 2. način.
Još nikad nisam dobio projekat koji je zamišljen kao statičan. Dakle, uvek upotrebljavam 2. način.
Upravo sam tako rekao još prvi put, ovaj put možda malo jasnije.

Razlozi?
- baza se lakše širi kada svaki upisani podatak ima neko jednostavno ime, sadržaj primarnog ključa i naziv tabele je ime upisanog podatka - eh moji meksikanci

- performanse se malo poboljšavaju kada moja veza ima više atributa koji je opisuju - provereno na MS SQL
- performanse se rapidno poboljšavaju ako moja veza ima dečije tabele - provereno na MS SQL
- upiti su jednostavniji, mada ovo i nije jako bitan razlog
- prenos, sinhronizacija podataka i replikacija se jednostavnije realizuju... ovo je svakom jednom trebalo

Slobodno mi kažite gde grešim ali nemojte da se sakrivate iza građevine, pušenja i loše IT strukture.
Zar nismo ovde da bismo o tome diskutovali?

Arbutina Mladen

[ broker @ 18.07.2006. 07:49 ] @

Milslim da je najveci razlog neslaganja u misljenjima to sto mi pricamo svi o nekim imaginarnim problemima.
Sta mislite da uzmemo neki konkretan problem i vidimo kako ce stvar da se ponasa tada?

Evo da malo prosirimo problem sa pocetka price:

Treba da se obezbedi model koji ce da omoguci sledece:

- podatke o radnicima (ime, prezime, datum rodjenja, radno mesto, ...). Tabela neke se zove RADNICI

- podatke o zadacima koji se dodeljuju radnicima (naziv zadatka, trajanje, potrebno radno mesto, ...). Tabela neke se zove ZADACI

- podatke o materijalima koji su potrebni za obavljanje nekog zadatka (vrsta materijala, kolicina). Tabela neka se zove MATERIJALI_ZADATAKA

- podatke o poslovima (zadacima koji su dodeljeni radnicima: vreme dodele, vreme pocetka posla, vreme zavrsetka posla, ...). Tabela neka se zove POSLOVI

- podatke o materijalima koji su radniku izdati za obavljanje konkretnog posla (vrsta materijala, datum izdavanja, izdata kolicina, utrosena kolicina, datum vracanja viska). Tabela neka se zove IZDATI_MATERIJALI.

- podatke o alatima koji su radniku izdati za obavljanje konkretnog posla (vrsta alata, datum izdavanja, kolicina, datum vracanja). Tabela neka se zove IZDATI_ALATI

Zbog lakseg pracenja razlicitih resenja, uvescemo pravilo da se polja koja su kljucevi tabela nazivaju tako da imaju ID_ kao prefiks, recimo ID_RADNIKA, ID_ZADATKA, ID_POSLA, ID_MATERIJALA...

[ Radudzoni @ 18.07.2006. 10:17 ] @

Evo i ja bih da uputim apel za podrusku ovom "broker"-ovom predlogu...
Mislim da je izuzetno konstruktivan.

Predlazem da to uradimo na sledeci nacin:
da problem , ovakav kakav je predlozio broker izmodeliramo i iskomentarisemo, a zatim da se pojavi "sef" koji ce da promeni nekoliko zahteva, pa onda na osnovu toga da se izvrse izmene na modelu...

Pozdrav.

[ amladjo @ 18.07.2006. 10:18 ] @

RADNIK (ID_Radnika,Prezime,Ime,DatumRodjenja,ID_RadnoMesto)
ZADACI (ID_Zadatka,NazivZadatka,Trajanje,PotrebnoRadnoMestoID)
MATERIJALI_ZADATKA (ID_MZ,MaterijalID,Kolicina)
POSLOVI (ID_Posla,RadnikID,ZadatakID,Dodeljen,Zapocet,Zavrsen)
IZDATI_MATERIJALI (ID_IM,MaterijalID,PosaoID)
IZDATI_ALATI (ID_IA,AlatID,DatumIzdavanja,DatumVracanja,Kolicina)

- radnik ima mnogo atributa (mesto stanovanja, JMBG, itd, oni se ovde podrazumevaju)
- slično je sa ostalim tabelama - isto su izbačeni kao nebitini za primer
- uveo sam tabelu materijala, jedan materijal može da učestvuje u više zadataka
MATERIJALI (ID_Materijala,NazivMaterijala,VrstaMaterijala)

- uveo sam poseban šifarnik radnih mesta:
RADNO_MESTO (ID_RadnoMesto,NazivRadnogMesta)

Razlog? Često klijenti ne znaju šta im treba i nemaju dobro organizaciju poslovanja. Stvaranjem šifarnika uređuju se neke stvari koje su do tada bile prilično neorganizovane.

- nedostaje tabela alata:
ALATI (ID_Alata,NazivAlata)

- imam naviku da svakoj tabeli dodam ista četiri polja: Opis,Kreirano,Menjano,KorisnikID - ovde nisu prikazani a predstavljaju slobodan opis određenog sloga, vreme kreiranja sloga, vreme zadnje izmene sloga i korisnik zadnje izmene sloga respektivno.

- tabele projektujem u MS SQL, šifre su mi uvek tipa uniqueidentifier, kada klijent od pre poseduje sopstvene šifarnike imaju potrebu da nastave sa radom na sličan način. Zbog toga uvodim posebne numeričke šifre kojom operateru omogućavam brz poziv određenog podatka na osnovu takve šifre - mnogi operaterima to odgovara, mnogima ne. S obzirom da baza mora biti uopštena (ne vezana za MS SQL) takva polja sam izostavio.

Ostavljam sada Vama da ovaj model dopunite i izmenite. U ovom slučaju toga svakako ima (i dok pišem mi je "sinulo" nekoliko ideja).

[ amladjo @ 18.07.2006. 10:21 ] @

Eh, okasnih nekoliko sekundi

Šefe, javi se

[ broker @ 18.07.2006. 11:21 ] @

Svidja mi se pocetak. Amljadjo, tvojprisup je sasvim u redu, posebno je dobro sto odmah u model uvodis nove tabele koje samim zadatkm nisu trazne ali se iz same sustine zadatka vidi da su potrebne.

Prekoscio si da napravis vezu tabele MATERIJALI_ZADATKA sa tabelom ZADACI, kao i da napravis vezu izmedju IZDATI_ALATI i POSLOVI. Pretpostavljam da se radi o previdu.

Mislim da nema potrebe da se tabelama MATERIJALI_ZADATKA, IZDATI_MATERIJALI i IZDATI_ALATI uvodi posebno polje kao kljuc tabele. Ne vidim da je moguce da se pokaze potreba da se te tabele povezu sa nekim drugim tabelama osim sa onima koje su predvidjene u zadatku tak da se uvodjenjem takvog polja nista ne dobija.

Suprotno tome, U tabeli POSLOVI je uvodjenje posebnog polja za kljuc tabele sasvim opravdano jer postoji veza ka tabelama IZDATI_MATERIJALI i IZDATI_ALATI koju bi bilo neprakticno praviti ako se koristi kljuc koji se sastoji od polja ID_RADNIKA i ID_ZADATKA. Ovde pre sveg amislim na unos podataka, jer bi magacioner koji izdaje materijale i alate, morao da upisuje radnika i zadatak koji se obavlja u trebovanju a ako postoji ID_POSLA, on samo upisuje posao i materijale i alate koji su potrebni za taj posao, ne uzlazeci u to koji je konkretan zadatak i ko ga obavlj a(osim utoliko sto taj radnke terba da mu potpise trebovanje. Uvodjenjem polja ID_POSLA se unos podataka znatno pojednostavljuje i smanjuje s emogucnsot pogresnog unosa.

Evo kako bi izgledale tabele uz moje dopune:

Code:

RADNIK (ID_RADNIKA, Prezime, Ime, DatumRodjenja, ID_RADNOG_MESTA)

ZADACI (ID_ZADATKA, Naziv, Trajanje, ID_POTREBNOG_RADNOG_MESTA)

MATERIJALI_ZADATKA (ID_MATERIJALA, ID_ZADATKA, Kolicina)

ALATI_ZADATKA (ID_ALATA, ID_ZADATKA, Kolicina)

POSLOVI (ID_POSLA, ID_RADNIKA, ID_ZADATKA, Dodeljen, Zapocet, Zavrsen)

IZDATI_MATERIJALI (ID_MATERIJALA, ID_POSLA, DatumIzdavanja, DatumVracanja, Izdata_Kolicina, Utrosena_Kolicina)

IZDATI_ALATI (ID_ALATA, ID_POSLA, DatumIzdavanja, DatumVracanja, Kolicina)

MATERIJALI (ID_MATERIJALA, Naziv, Vrsta)
RADNA_MESTA (ID_RADNOG_MESTA, Naziv)
ALATI (ID_ALATA, Naziv)

Razlike u odnosu na tvoj model su manje-vise kozmeticke prirode, uz izbacena polja za koja mislim da sunepotrebna.

Dodao sam i tabelu ALATI_ZADATKA koja nije navedena u zadatku ali je ocigledno potrebna, slicno kao i tabela MATERIJALI_ZADATKA, da bi se samom defincijom zadatka moglo definisatii koji su materijali i koji alati potrebni za izvrsenje zadatka (a to je potrebno magacioneru koji izdaje materijale i alate da bi znao sta treba da izda radniku koji obavlja posao).

Poredjenja radi, evo kako bi mogao da izgleda model ako se ne bi korsitilo polje ID_POSLA u tabeli POSLOVI:

Code:

RADNIK (ID_RADNIKA, Prezime, Ime, DatumRodjenja, ID_RADNOG_MESTA)

ZADACI (ID_ZADATKA, Naziv, Trajanje, ID_POTREBNOG_RADNOG_MESTA)

MATERIJALI_ZADATKA (ID_MATERIJALA, ID_ZADATKA, Kolicina)

ALATI_ZADATKA (ID_ALATA, ID_ZADATKA, Kolicina)

POSLOVI (ID_RADNIKA, ID_ZADATKA, Dodeljen, Zapocet, Zavrsen)

IZDATI_MATERIJALI (ID_RADNIKA, ID_ZADATKA, ID_MATERIJALA, ID_POSLA, DatumIzdavanja, DatumVracanja, Izdata_Kolicina, Utrosena_Kolicina)

IZDATI_ALATI (ID_RADNIKA, ID_ZADATKA, ID_ALATA, DatumIzdavanja, DatumVracanja, Kolicina)

MATERIJALI (ID_MATERIJALA, Naziv, Vrsta)
RADNA_MESTA (ID_RADNOG_MESTA, Naziv)
ALATI (ID_ALATA, Naziv)

[ broker @ 18.07.2006. 11:37 ] @

Trebalo bi sacekati sa postavljanjem dodatnih zahteva za izmenu modela. U disksuiji je bilo jos ljudi koji su imali sta da kazu i treba ih sacekati da daju svoje vidjenje modela, a tek onda postaviti zahteve za izmene da bi smo videli kako koji model trpi izmene.

Inace kod zahteva za izmene mislim da treba napraviti jasnu razliku izmedju izmena koje je projektant modela trebao da prepostavi, ne samo u smislu da u modelu stvori prostor za takve vrste izmena, nego i da o tim mogucim izmenama direktno razgovara sa onim ko mu je dao projektni zadatak i izmena koje je nemoguce pretpostaviti a posledice su naknadnih izmena u potrebi koriscenja zadatog informacionog sistema.

U gornjim primerima se moglo videti ako projektant sam prepoznaje neke elemente moji su u modelu neophodni, iako ih nalogodavac nije naveo u zahtevu, ali je sasvim sigurno da bi i on vrlo brzo uvideo nedostatke i trazio bi da budu implementirani. Tu se radilo o elemntimakoji su ocigledno potrebni ali nije uvek moguce da projektant sam zakljuci sta je sve u modelu neophodno ili sta moze da zatreba. Ipak, potrebno je da se potrudi da predvidi sto je moguce vise naknadnih zahteva potrebno, makar samo kao principe, a ne konkretne moguce izmene.

[ amladjo @ 18.07.2006. 12:02 ] @

Ma jeste previd, tabela MATERIJALI_ZADTAKA mora imati ZadatakID i tabela IZDATI_ALATI mora imati PosaoID.

Zanimljivo je da u realnim uslovima uvek imam ovakve previde koji se isprave kod krenem sa izradom forme za unos.

Kod tabela MATERIJALI_ZADATKA, ALATI_ZADATKA, IZDATI_MATERIJALI, IZDATI_ALATI ipak moram biti oprezan.
Možda mi nešto promiče, možda ne poznajem suštinu posla koji želim da zaokružim. U tim tabelama bih ipak stavio poseban ID nerazmišljajući kojim putem će ovaj primer ići.

Dakle brokerove korekcije su sasvim na mestu ali "tvrdoglavo" zadržavam posebne ID ključeve.

Čekam da mi se javi šef, u međuvremenu izrađujem strukturu baze i pravim potrebne forme.

[ Zidar @ 18.07.2006. 13:45 ] @

Za Jablana:

Citat:

Čekaj malo, Zidar... Sad ispade da je uvođenje surogat ključa prekršaj i samo je pitanje trenutka kad će nekom da se baza sa surogat ključevima sruši na glavu...

Tacno, jete prekrsaj. Relacioni model podataka zahteva da sve sto se cuva u bazi ima neki smisao i vezu sa realnim svetom. Prekrsaj sustine relaciong modela. S neba uvodis podatak koji ne predstavlja nista. I tacno je da se baza pre ili kasnije srusi, ali se to sakrije i ne priznaje. Znas ono, 'dodatni radovi u gradjevinarstvu'.

Citat:

Pa valjda je stoput rečeno da se nekad normalizacija svesno krši, tj. ne ide do kraja po knjizi, iz najrazličitijih razloga.

Na zalost, nije NEKAD, nego je UVEK ili bar U VECINI SLUCAJEVA. Svaki dan vidjam ovako rezonovanje: "Posto se na kraju sve denormalizuje, zasto uopste normalizovati?" i onda dobijemo flat table sistem gde su tabele spakovane u MS SQL ili ORACLE. Uvodjenej surogat kljuca jeste denormalizacija. Ako se to uradi na pocetku projekta, znaci da ni nema normalizacije. Ponovo prekrsaj, iz lenjosti iako u sustini an duzi rik zahteva vise rada nego normalizovano resenje.

Primer koji se off topic projektuje: interesantno da za sada jos ne vidimo nista sto je surogat key, u smislu onoga ID u tabeli RadnikNaZadatku (ID, RadnikID, ZadatakID) :-)

[ broker @ 18.07.2006. 13:47 ] @

He he, dok se sef ne javi, dozvoljeno je postavljati pitanja u vezi modela, u smislu, "a sta ako...", i "da li ce mozda trebati..."

Citat:

amladjo:
Zanimljivo je da u realnim uslovima uvek imam ovakve previde koji se isprave kod krenem sa izradom forme za unos.

Ne valja ti to. Kada dodjes do izrade forme vec si daleko dogurao. Volim graficke alate za projektovanje modela upravo zato sto vizuelno pokazuju tabele i njihove veze pa je lako videti ovakve propuste dok je vreme.

Druga stvar, mi ovde, zbog jednostavnosti, ne prikazujemo i same veze izmedju tabela, ali kada projektujes bazu moras i to da definises i tada sigurno vidis ovakve propuste.

Citat:

Zidar:
Primer koji se off topic projektuje: interesantno da za sada jos ne vidimo nista sto je surogat key, u smislu onoga ID u tabeli
RadnikNaZadatku (ID, RadnikID, ZadatakID) :-)

Pogledaj tabelu POSLOVI

[ amladjo @ 18.07.2006. 14:01 ] @

Citat:

U pravu si, primer je "izleteo iz glave", otuda i propusti

[ jablan @ 18.07.2006. 14:03 ] @

Citat:

Zidar: Na zalost, nije NEKAD, nego je UVEK ili bar U VECINI SLUCAJEVA. Svaki dan vidjam ovako rezonovanje: "Posto se na kraju sve denormalizuje, zasto uopste normalizovati?" i onda dobijemo flat table sistem gde su tabele spakovane u MS SQL ili ORACLE. Uvodjenej surogat kljuca jeste denormalizacija. Ako se to uradi na pocetku projekta, znaci da ni nema normalizacije. Ponovo prekrsaj, iz lenjosti iako u sustini an duzi rik zahteva vise rada nego normalizovano resenje.

Šta da kažem, osim da imaš vrlo pesimističan pogled na svet oko sebe. :)

Nikad nisam imao razumevanja za isključive stavove tipa: "Ili projektuješ po knjizi i to je savršeno, ili ne normalizuješ uopšte, sve podatke trpaš u BLOB polja, nemaš referencijalne zavisnosti, svuda pakuješ surogat ključeve, siluješ male dečake i zaslužuješ da goriš u paklu sledeće tri večnosti!". Po mom iskustvu, sweet spot je uvek negde između, a uzroci najvećih problema u svakom softverskom projektu obično leže u mnogo banalnijim pojavama od surogat ključeva.

[ Zidar @ 18.07.2006. 15:07 ] @

Za Broker: U pravu si, nasm primetio. Ovako stoji:
POSLOVI (ID_POSLA, ID_RADNIKA, ID_ZADATKA, Dodeljen, Zapocet, Zavrsen)
IZDATI_MATERIJALI (ID_MATERIJALA, ID_POSLA, DatumIzdavanja, DatumVracanja, Izdata_Kolicina, Utrosena_Kolicina)
IZDATI_ALATI (ID_ALATA, ID_POSLA, DatumIzdavanja, DatumVracanja, Kolicina)

A moglo je i ovako:
POSLOVI (ID_RADNIKA, ID_ZADATKA, Dodeljen, Zapocet, Zavrsen)
IZDATI_MATERIJALI (ID_MATERIJALA, ID_RADNIKA, ID_ZADATKA, DatumIzdavanja, DatumVracanja, Izdata_Kolicina, Utrosena_Kolicina)
IZDATI_ALATI (ID_ALATA, ID_RADNIKA, ID_ZADATKA,, DatumIzdavanja, DatumVracanja, Kolicina)

U tom slucaju vidm direktno u tabelama da je neki materiajl ili alat izdat radniku ID_Radnika koji radi na zadatku ID_Zadataka.

Onako kako ste stavili, sa ID_Posla, ako hoces da vidis koji materijal je izdat kom radniku i zasto, treba ti JOIN:

SELECT
M.ID_MAterijala, M.ID_Posla,
P.ID_Radnika
FROM IZDATI_MATERIJALI
JOIN POSLOVI AS P ON P.ID_Posla=M.ID_Posla

Isto tako za izdati alat:
SELECT
A.ID_Alata, A.ID_Posla,
P.ID_Radnika
FROM IZDATI_ALATI AS A
JOIN POSLOVI AS P ON P.ID_Posla=A.ID_Posla

Surogat key ID_POsla ste uveli da bi se lakse piso JOIN u dva pokazana SELECT iskaza. Medjutim, da ste ostavili PK u POSLOVI kao (ID_RADNIKA, ID_ZADATKA), ta dva SELECT izkaza ne bi vam ni trebali. Ponavljam ono sto sam rekao na pocetku; lakse je ne pisati JOIN uopste nego pisati veoma jednostavan JOIN (dva u ovom slucaju)

Doduse, ako sef nije trazio da vidi koji materijal je izdat kom radniku i za koji posao, moja promedba je bespredmetna. Cini mi se ipak da je pitanje vrlo logicno, pa cak i kao sef ne trazi to odmah na pocetku, trazice kasnije, sigurno. A kad bude trazio sef, onda ce svaki SELECT (2 komada) da se pretvore u VIEW (2 komada) koje ce da koristi front end i tako dalje...
Pa kad dodate jos jednu kolonu nekad u neku tabelu, onda morte da se setite da je dodate u view i tako dalje..

ZA Mladju:

Citat:

Ovde pre sveg amislim na unos podataka, jer bi magacioner koji izdaje materijale i alate, morao da upisuje radnika i zadatak koji se obavlja u trebovanju a ako postoji ID_POSLA, on samo upisuje posao i materijale i alate koji su potrebni za taj posao, ne uzlazeci u to koji je konkretan zadatak i ko ga obavlj a(osim utoliko sto taj radnke terba da mu potpise trebovanje. Uvodjenjem polja ID_POSLA se unos podataka znatno pojednostavljuje i smanjuje s emogucnsot pogresnog unosa.

Radnik uglavnom treba da potpise trebovanje, nista ne izlazi iz magacina a da neko ne potpise trebovanje. Sefovi ne trebuju za radnike. Ako mogu sefovi da trebuju za radnike, onda nesto fali u modelu. Ko trebuje, mora biti u modelu. Kako je model postavlje, proizilazi da se radnik zaduzuje kmaterijalom. prema tome on ce i da potpise trebovanje. Gresku na unosu eliminise referential integrity a ne ID_POSLA . Ne vidim kako ID_POSLA smanjuje mogucnost greske. Pojednostavljuje upis, da. Kuca se jedan podatak umesto dva. Bez mogucnosti kontrole. Ako je ID_POSLA = 1276676684, da li je moguce da ce magacioner ukucati 1276676864 a da ne primeti? Ako ne primeti, zaduzio si Lazu sa materijalom koji je u stvari uzeo Pera. A Laza je bivsi bokser i ne voli da ga duize tudjim materijalom.

Kako ce se raditi je stvar ukusa, bice da sam ja isuvise star da bih shvatio prednosti negiranja teorije na kojoj je cela relaciona prica bazirana. Necu vise da vas davim.

srecan rad

_{[Ovu poruku je menjao Zidar dana 18.07.2006. u 16:25 GMT+1]}

[ chachka @ 18.07.2006. 18:59 ] @

Evo mog resenja. Poduze je ali samo tako mogu u potpunosti da se izrazim.Source govori sam za sebe :)

Code:

CREATE TABLE Alati (
    id_alata INTEGER NOT NULL,
    naziv_alata VARCHAR(50) NOT NULL,
  CONSTRAINT pk_ala PRIMARY KEY (id_alata)
);

CREATE TABLE Materijali (
    id_materijala INTEGER NOT NULL,
    naziv_materijala VARCHAR(50) NOT NULL,
  CONSTRAINT pk_mat PRIMARY KEY (id_materijala)
);

CREATE TABLE Radna_Mesta (
    id_radnog_mesta INTEGER NOT NULL,
    opis_radnog_mesta VARCHAR(50) NOT NULL,
  CONSTRAINT pk_ram PRIMARY KEY (id_radnog_mesta)
);

CREATE TABLE Radnici (
    id_radnika INTEGER NOT NULL,
    id_radnog_mesta INTEGER NOT NULL,
    ime_radnika VARCHAR(15) NOT NULL,
    prezime_radnika VARCHAR(30) NOT NULL,

  CONSTRAINT pk_rad PRIMARY KEY (id_radnika),

  CONSTRAINT un_rad UNIQUE (id_radnika, id_radnog_mesta),

  CONSTRAINT fk_rad_ram FOREIGN KEY (id_radnog_mesta)
    REFERENCES Radna_Mesta (id_radnog_mesta)
    ON UPDATE CASCADE ON DELETE RESTRICT
);

CREATE TABLE Zadaci (
    id_zadatka INTEGER NOT NULL,
    id_radnog_mesta INTEGER NOT NULL,
    naziv_zadatka VARCHAR(50) NOT NULL,
    trajanje_zadatka INTEGER NOT NULL CHECK (trajanje_zadatka > 0), -- u danima??

  CONSTRAINT pk_zad PRIMARY KEY (id_zadatka),

  CONSTRAINT un_zad UNIQUE (id_zadatka, id_radnog_mesta),

  CONSTRAINT fk_zad_ram FOREIGN KEY (id_radnog_mesta)
    REFERENCES Radna_Mesta (id_radnog_mesta)
    ON UPDATE CASCADE ON DELETE RESTRICT
);

CREATE TABLE Poslovi (
    id_radnika INTEGER NOT NULL,
    id_zadatka INTEGER NOT NULL,
    id_radnog_mesta INTEGER NOT NULL,
    datum_dodele DATE NOT NULL,
    datum_pocetka DATE,
    datum_zavrsetka DATE,

  CONSTRAINT pk_pos PRIMARY KEY (id_radnika,id_zadatka),

  CONSTRAINT fk_pos_rad FOREIGN KEY (id_radnika, id_radnog_mesta)
    REFERENCES Radnici (id_radnika, id_radnog_mesta)
    ON UPDATE CASCADE ON DELETE RESTRICT,

  CONSTRAINT fk_pos_zad FOREIGN KEY (id_zadatka, id_radnog_mesta)
    REFERENCES Zadaci (id_zadatka, id_radnog_mesta)
    ON UPDATE CASCADE ON DELETE RESTRICT,

  CONSTRAINT ch_pos_datum_pocetka CHECK (   (datum_dodele <= datum_pocetka)
                                         OR (datum_pocetka IS NULL)),

  CONSTRAINT ch_pos_datum_zavrsetka CHECK (   (datum_pocetka <= datum_zavrsetka)
                                           OR (datum_zavrsetka IS NULL))
);

CREATE TABLE Potrebni_Alati (
    id_zadatka INTEGER NOT NULL,
    id_alata INTEGER NOT NULL,
    normativna_kolicina NUMERIC(16,3) NOT NULL CHECK (normativna_kolicina > 0),

  CONSTRAINT pk_poa PRIMARY KEY (id_zadatka, id_alata),

  CONSTRAINT fk_poa_zad FOREIGN KEY (id_zadatka)
    REFERENCES Zadaci (id_zadatka)
    ON UPDATE CASCADE ON DELETE RESTRICT,

  CONSTRAINT fk_poa_ala FOREIGN KEY (id_alata)
    REFERENCES Alati (id_alata)
    ON UPDATE CASCADE ON DELETE RESTRICT
);

CREATE TABLE Potrebni_Materijali (
    id_zadatka INTEGER NOT NULL,
    id_materijala INTEGER NOT NULL,
    normativna_kolicina NUMERIC(16,3) NOT NULL CHECK (normativna_kolicina > 0),

  CONSTRAINT pk_pom PRIMARY KEY (id_zadatka, id_materijala),

  CONSTRAINT fk_pom_zad FOREIGN KEY (id_zadatka)
    REFERENCES Zadaci (id_zadatka)
    ON UPDATE CASCADE ON DELETE RESTRICT,

  CONSTRAINT fk_pom_mat FOREIGN KEY (id_materijala)
    REFERENCES Materijali (id_materijala)
    ON UPDATE CASCADE ON DELETE RESTRICT
);

CREATE TABLE Izdati_Alati (
    id_radnika INTEGER NOT NULL,
    id_zadatka INTEGER NOT NULL,
    id_alata INTEGER NOT NULL,
    datum_izdavanja DATE NOT NULL,
    izdata_kolicina NUMERIC(16,3) NOT NULL CHECK (izdata_kolicina > 0),
    datum_vracanja DATE,

  CONSTRAINT pk_iza PRIMARY KEY (id_radnika, id_zadatka, id_alata),

  CONSTRAINT fk_iza_pos FOREIGN KEY (id_radnika, id_zadatka)
    REFERENCES Poslovi (id_radnika, id_zadatka)
    ON UPDATE CASCADE ON DELETE RESTRICT,

  CONSTRAINT fk_iza_poa FOREIGN KEY (id_zadatka, id_alata)
    REFERENCES Potrebni_Alati (id_zadatka, id_alata)
    ON UPDATE CASCADE ON DELETE RESTRICT,

  CONSTRAINT ch_iza_datum_izdavanja CHECK(   (datum_izdavanja <= datum_vracanja)
                                          OR (datum_vracanja IS NULL))
);

CREATE TABLE Izdati_Materijali(
    id_radnika INTEGER NOT NULL,
    id_zadatka INTEGER NOT NULL,
    id_materijala INTEGER NOT NULL,
    datum_izdavanja DATE NOT NULL,
    izdata_kolicina NUMERIC(16,3) NOT NULL CHECK (izdata_kolicina > 0),
    vracena_kolicina NUMERIC(16,3) NOT NULL CHECK (vracena_kolicina >= 0),
    datum_vracanja DATE,

  CONSTRAINT pk_izm PRIMARY KEY (id_radnika, id_zadatka, id_materijala),

  CONSTRAINT fk_izm_pos FOREIGN KEY (id_radnika, id_zadatka)
    REFERENCES Poslovi (id_radnika, id_zadatka)
    ON UPDATE CASCADE ON DELETE RESTRICT,

  CONSTRAINT fk_izm_pom FOREIGN KEY (id_zadatka, id_materijala)
    REFERENCES Potrebni_Materijali (id_zadatka, id_materijala)
    ON UPDATE CASCADE ON DELETE RESTRICT,

  CONSTRAINT ch_izm_datum_izdavanja CHECK(   (datum_izdavanja <= datum_vracanja)
                                          OR (datum_vracanja IS NULL))
);

Napomena: SQL skript je proveren na PostgreSQL DBMS-u. PostgreSQL ima DATE tip podataka, dok koliko znam MS SQL nema - Find/Replace All sa DATETIME.

Pojasnjenje tabela:

- Tabele 'Alati', 'Materijali', 'Radna_Mesta' su trivijalne.

- Tabela 'Radni_Zadaci' referencira ka tabeli 'Radna_Mesta'. Ovoj tabeli je dodat UNIQUE index (kasnije ce biti objasnjeno zasto).

- Tabela 'Radnici' referencira ka tabeli 'Radna_Mesta' u smislu da je radnik rasporedjen (kvalifikovan) na odredjeno radno mesto. Ovoj tabeli je dodat UNIQUE index (kasnije ce biti objasnjeno zasto).

- Tabela 'Zadaci' takodje referencira ka tabeli 'Radna_Mesta' u smislu da se zadatak izvrsava na tom radnom mestu. Ovoj tabeli je dodat UNIQUE index (kasnije ce biti objasnjeno zasto).

- Tabela 'Poslovi' referencira ka tabelama 'Radnici' i 'Zadaci' preko gore spominjanih UNIQUE indexa. Ovim je obezbedjeno da se radnik ne moze poslati da radi zadatak za koji nije kvalifikovan i koji se ne radi na njegovom radnom mestu. Tabeli je takodje dodata prosta provera ispravnosti datuma.

- Tabela 'Potrebni_Alati' ima kompozitni prirodni kljuc od dva atributa. Na ovaj nacin je spreceno da se za isti zadatak navede potreba za dva ista alata, i obratno.

- Tabela 'Potrebni_Materijali' takodje ima kompozitni prirodni kljuc od dva atributa. Slicno predhodnoj tabeli, na ovaj nacin je spreceno da se za isti zadatak navede potreba za dva ista materijala, i obratno.

- Tabela 'Izdati_Alati' referencira ka tabeli 'Radnik' kome je taj alat izdat. Takodje tabela referencira ka tabeli 'Potrebni_Alati'! Na ovaj nacin je spreceno da se radniku izda alat koji mu nije potreban za obavljanje konkretnog zadatka. Citiracu Brokerov originalni zadatak: 'podatke o alatima koji su radniku izdati za obavljanje konkretnog posla'. Tabela opet ima kompozitni kljuc koji je ovog puta sastavljen od tri atributa. Tabeli sam takodje dodao trivijalnu proveru ispravnosti datuma vracanja alata.

- Tabela 'Izdati_Materijali' referencira ka tabeli 'Radnik' kome je materijal izdat. Takodje tabela referencira ka tabeli 'Potrebni_Materijali'! Na ovaj nacin je spreceno da se radniku izda materijal koji mu nije potreban za obavljanje konkretnog zadatka. Opet citiram Brokerov originalni zadatak: 'podatke o materijalima koji su radniku izdati za obavljanje konkretnog posla'. Tabela opet ima kompozitni kljuc koji je takodje sastavljen od tri atributa. Tabeli sam takodje dodao trivijalnu proveru ispravnosti datuma vracanja materijala i vracene kolicine.

Svoje resenje sam prezentovao u SQL-u jer je to univerzalni jezik baza podataka zasnovanih na relacionoj teoriji. Lako vam je da uradite copy/paste uz blage izmene i mozete proveriti moje tvrdnje na RDBMS-ima koje upotrebljavate.

Resenja (ili je bolje reci resenje?) koja su ponudili Amladja i Broker prvo pate od nedostatka referencijalnih integriteta (u daljem tekstu RI).
Ako ne modelirate i ne upotrebljavate RI onda slobodno umesto Relacionih sistema za upravljanje podacima (RDBMS) mozete koristiti FAJL SISTEME!

Navedena resenja su data u obliku kvazi matematicke notacije relacionog modela podataka.

U toj notaciji se RI pisu upotrebom projekcije i relacije 'je podskup od'. Na primer

Code:

RADNA_MESTA (ID_RADNOG_MESTA, Naziv)

RADNIK (ID_RADNIKA, Prezime, Ime, DatumRodjenja, ID_RADNOG_MESTA)

RADNIK[ID_RADNOG_MESTA] je podskup od RADNA_MESTA[ID_RADNOG_MESTA]

Ponudjenim resenjima takodje nedostaje provera unetih podataka koje sam naveo u resenju koje sam ja prikazao. U tim resenjima je sasvim legitimno dati posao radniku na nekom zadatku, a da radnik nije ni kvalifikovan za taj zadatak. Sasvim je legitimno radniku izdati alat koji mu nije potreban.

Price da se to resava u aplikativnom delu ne drze vodu, jer kako cete spreciti cak i ispod prosecnog korisnika SQL DML-a da uradi

Code:

INSERT INTO POSLOVI (ID_POSLA, ID_RADNIKA, ID_ZADATKA, Dodeljen, Zapocet, Zavrsen)
VALUES (1, 1, 1, '2006-07-15', '2006-07-07', '2006-01-01');
COMMIT;

ako u tabeli RADNIK imate da je radnik sa RADNIK.ID_RADNIKA = 1 zaposlen na radnom mestu RADNIK.ID_RADNOG_MESTA = 2? (Obratite paznju da je posao uradjen pre nego sto je i dodeljen!)

Ovakvo nesto se moze spreciti samo fizickim metodama represalija nad zaposlenima u firmi. Zabrana instaliranja generickih SQL programa cak i administratorima jer boze moj on je mozda drug nekome ko zna SQL.

I na kraju zbog jake simetricnosti modela (slicnost izmedju 'Alati' i 'Materijali' i njihove upotrebe) bi se dalo razmisljati i o generalizaciji ove dve tabele u tabelu 'Resursi', pa onda samo jedna tabela 'Potrebni_resursi' i jos jedna tabela za 'Izdati_Resursi'. Ali ova ideja je data nakon povrsnog razmatranja modeliranog sistema i sigurno bi trebalo dublje analizirati sistem da bi ova ideja bila primenjena.

[ Dejan Topalovic @ 18.07.2006. 20:46 ] @

Svaka cast momci! Ovo se zove konstruktivna diskusija! Mogao bi moderator ovu temu TOPovati?

Nego, sad shef kad dodje, moze samo da potvrdno klimne glavom i da odrijesi kesu za gajbu pive i neko dobro pecenje.

Ne znam ima li smisla sada, da i ja dodajem svoje vidjenje ovog zadatka, jer se ne bi skoro nimalo razlikovalo od vec napisanih.

[ amladjo @ 18.07.2006. 23:54 ] @

@chachka, svaka čast na detaljnosti!

Citat:

Resenja (ili je bolje reci resenje?) koja su ponudili Amladja i Broker prvo pate od nedostatka referencijalnih integriteta (u daljem tekstu RI).
Ako ne modelirate i ne upotrebljavate RI onda slobodno umesto Relacionih sistema za upravljanje podacima (RDBMS) mozete koristiti FAJL SISTEME!

Nisam primetio da ti nešto nije bilo jasno u skraćenoj notaciji koju sam naveo, tvoja je svakako detaljnija ali opet bežiš od konkretne stvari pravdajući se da kao nisam naveo to i to. Tvoje rešenje će možda moći da sprovede i Seka ali da li mi pričamo o tome?

Dopusti, kako kaže Dejan, da nas šef časti pivom.
Naš šef bi recimo poželeo da jedan radnik radi na jednom zadatku kroz više etapa. Naš šef nas je također obavestio da podatke koje su operateri u međuvremenu uneli hteo da zadrži i samo "proširi" za ovu varijantu.
Nadam se da nećeš razočarati našeg šefa i reći da moraš praviti novi "projekat" i da će to trajati toliko dugo kao osnovni jer ipak, ovo je samo jedna sitnica koje nije uspeo da se seti.
Šefu se jako sviđa tvoja notacija, puno je bolja i, nekako stručnija, pa te moli ako može isto tako

- da bi ga Seka lakše sprovela.

Još nešto, šef kaže: "Nisi dobro razumeo Seku ili se ona nije dobro izrazila ali njoj ne trebaju samo datumi nego i datum i vreme početka i kraja zadatka pa ako možeš i to da napraviš. Hvala."

Veliki pozdrav za Zidara, mada me nije dobro citirao.
Šef će svakako tražiti sve moguće izveštaje po svemu mogućem što se unosi, to je stvar kreiranja upita, i to ćeš lako/teško izvesti, to svakako zavisi od toga kako je projektovana baza. Mislim da još nije izmišljena baza u kojoj ćeš sve upite napraviti bez korišćenja JOIN-a i kad moraš da upotrebiš JOIN jednostavno moraš. Odnosno, kakva god da se baza smisli uvek će se desiti da Šef traži izveštaj koji zahteva JOIN i onda: "da je baza projektovana tako i tako upit bi mogao biti bez njega".
Pitanje grešaka operatera je vrlo zanimljivo, znači ako umesto šifre radnika 1232 upišem 1233 a šifru zadatka tačno pogodim (čudnim čudom) umesto boksera će mi doći lepa Kata? Da mi "pokaže" kako se trebuje? Ljudi, pa ovo NIJE smešno, koristim li ja išta osim šifara?

[ chachka @ 19.07.2006. 09:33 ] @

Citat:

amladjo:
Nisam primetio da ti nešto nije bilo jasno u skraćenoj notaciji koju sam naveo, ...

Meni je jasno, ali ova tema moze biti nekome od koristi. Ne meni i ne tebi, od nje nema koristi ni Broker, ni Dejan, ni Zidar (izvinjavam se svima koji nisu nabrojani, a i onima koji jesu, a osete se uvređeni :). Ova tema može da pomogne ljudima koji tek ulaze u svet programiranja baza podataka, npr. loshmiscg (veoma je aktivan na forumima o Delphi-ju i Access-u, vidi se da se trudi da nauči).

Ako smo krenili sa rešavanjem konkretnog problema, dajte rešenje kompletno. Prepiska između tebe i Brokera se svela na to 'ma da jesi (jesam) pogrešio, ali se to sigurno nebi desilo sa si (sam) koristio foreign key-jeve'. Ko brani momentalnu upotrebu foreign key-jeva?

Digresija: Imam kolegu koji je jednom prilikom kreirao stotinjak tabela u bazi. Pitam ga: Gde su referencijalni integriteti? Kaže: To ću uraditi posle. Ni posle godinu dana ih nije ubacio!

Meni je bilo jasno da podrazumevate referenciranje tabele upotrebom primary key-jeva, ali to nemora da bude tako. Referenciranje ka drugoj tabeli se može ostvariti preko bilo kojeg ključa (alternativnog, surogatnog, prirodnog, kandidata za ključ). U sadašnjim implementacijama SUBP-a se to postiže kreiranjem dodatnih UNIQUE INDEX-a.

Razlika između fajl sistema i SUBP-a je između ostalih i ta što fajlovi nemaju vezu ka drugim fajlovima. Tabele mogu i moraju da imaju veze (FOREIGN KEY) ka drugim tabelama. I fajlove i tabele možeš da čitaš, pišeš, menjaš, brišeš, razlika je u vezama.

(Ko je to viknuo WinFS?!!) :)

Nije ni moje rešenje bez propusta. Još kako bih u stvarnom projektu imao što-šta da priupitam i seku kadrovkinju, i batu šefa i tatu direktora. Ali bi se takva pitanja i odgovori preko foruma otegli nedeljama. (Zidar je to radio u nekim temama.)

Citat:

amladjo: Naš šef bi recimo poželeo da jedan radnik radi na jednom zadatku kroz više etapa. Naš šef nas je također obavestio da podatke koje su operateri u međuvremenu uneli hteo da zadrži i samo "proširi" za ovu varijantu.

Citat:

amladjo: Još nešto, šef kaže: "Nisi dobro razumeo Seku ili se ona nije dobro izrazila ali njoj ne trebaju samo datumi nego i datum i vreme početka i kraja zadatka pa ako možeš i to da napraviš. Hvala."

Da li su ovo nove dopune zahteva originalnom Brokerovom problemu? Ako jesu, rado ću dopuniti model nakon svojih dnevnih obaveza.

Srdjan

PS: Nedavno si mi rekao da ja vas (malo slovo - množina) ne poznajem. S obzirom da ni vi ne poznajete mene, nemojte mi zameriti ako čas koristim ti, čas vi, čas mi (Matematičar - imao 3 iz Srpskog :( ). Iako sam citirao Amladju obraćam se svim učesnicima foruma (i onima koji pišu i onima koji samo čitaju)

[ Dejan Topalovic @ 19.07.2006. 09:57 ] @

Bilo bi dobro da sada dodje seka iz kadrovskog i izdiktira, koje sve informacije i u kojim slucajevima zeli imati prikazane na ekranu. Programer/projektant odmah konvertuje te njene zelje u SQL upite. Dakle, zgodno za nastavak konstruktivne diskusije bi bilo to, da uzmemo jedan od ponudjenih modela(kako odluciti, koji je najidealniji?) i na osnovu njega sklepamo 10-20 smislenih SQL upita za seku iz kadrovskog.

Vjerujem da bi bilo zanimljivo vidjeti razlicita rjesenja i ponesto nauciti od starijih i iskusnijih kolega.

Shefe, de posalji seku iz kadrovskog, da nam izdiktira svoje zelje!

[ amladjo @ 19.07.2006. 11:09 ] @

Nikada mi nije bila namera da bilo kojeg programera početnika uporedim sa Sekom. Seka je izmišljeni i karikirani lik koji predstavlja operatera. Operateri su ljudi od krvi i mesa koji vrlo konstruktivno mogu učestvovati u izradi projekta. Seka je samo kroz humor trebala da skrene pažnju na to šta joj je bitno, bez namere da se neko uvredi. I Šef je takav lik.
I sam sam neko vreme bio operater tako da mi to pomaže da lakše razumem njihove probleme i pokušam što jednostavnije da ih rešim.

Tebi je izgleda samo bitno, moram tebe da citiram, ko ima duži.
Meni to, od početka, nije bila namera. Moja je namera, između ostalog, da uporedim svoje iskustvo sa drugim ljudima, možda i ja nešto naučim iz toga a ne samo početnici. Profesija kojom se bavim upravo to od mene i zahteva, da se stalno usavršavam. Najmanje što želim jeste da sve ljude koji ovde diskutuju poslažem po "dužini" što ti uporno činiš.

Ako hoćeš da neko nešto konstruktivno nauči iz ove teme nemoj da bežiš od početnog problema:
Da li je bolje dodati ID kao primarni ključ i N:M vezi ili nije.

Izneo si svoj model ali si stao kod prve promene. Upravo sam o tome i pričao u prethodnim postovima. Tvoj model jednostavno ne trpi izmene a ti me ispravi ako grešim.

Veliki broj tvoj komentara u ovoj temi je ostao bez odgovora, namerno.
Ako ti je stvarno cilj da ovde nešto pokažemo bilo bi dobro da razmisliš i takve komentare jednostavno izbaciš. Moramo li da dokazujemo da nemaju veze sa početnim problemom.

Da rezimiram, napravljen je projekat, on funcioniše nekoliko meseci i onda NAM Šef javlja sa zahtevom za izmenu strukture. Dajte zahteve. Dajte rešenja.

[ Zidar @ 19.07.2006. 14:33 ] @

Citat:

Da rezimiram, napravljen je projekat, on funcioniše nekoliko meseci i onda NAM Šef javlja sa zahtevom za izmenu strukture. Dajte zahteve. Dajte rešenja.

Mladjo, sef nikad ne trazi promenu strukture. On ti iskazuje novu potrebu, koju nije spomenuo kad se projekt razvijao. To ce ponekad zahtevati izmenu strukture a nekada ne. Da definisemo izmenu strukture: Bilo koja od sledece tri stvari:
1. dodavanje nove tabele ili
2. dodavanje novog polja u postojecu tabelu bez uticajka na PK
3. dodavanje novog polja koje je deo PK, pa se propagira svuda u child tabele gde iamo migrirani PK
Dodabanje novog view-a nije promena strukture baze

Surogat key 'pomaze' samo u trecem slucaju, ali samo prividno. Uvodjenjem surogat key bilo sta ce postati jedinstveno i 'normalizovano'. Sve sto moze surogat key, moze o kompozitni, samo ima vise pisanja kad se rade JOINs. Sistem bez surogat keys garantuje manje potreba za JOIN, iako su oni koji ipak moraju da se rade slozeniji, idu po vise polja. Manje JOINa, manje view-a => ukupan broj objekata o kojima treba voditi racuna tokom razvoja i zivota sustema je manji. Iz toga sledi da je u stvari manje posla ako se ne koriste surogat kljucevi. Ponekad se ne mogu izbeci, ali ne treba gurati pravilo "Po svaku cenu treba koristi surogate umesto kompozitnih kljuceva jer su bolji".

Pusti pricu o teoriji i praksi. Moja prababa je znala iz prakse da budjav hleb pomaze da rana zaraste, a zivela je u 19. veku. Ipak je trebalo da dodje 1943 i da Aleksandar Fleming shvati da je budj gljiva od koje se moze napraviti lek zvani penicilin. Danas niko ne stavlja budjav hleb na rane, iako je praksa pokazala da to radi. Onda su od penicilina razvili i streptomicin, kao bolji od penicilina. Pa su ga u praksi doktori davali svima, maloj deci pogotovo. Zato ja danas imam zelene zube i ne cujem na jedno uvo. Onda je neko proucio i praksu i teoriju i zabranio streptomicin za davanje deci i preporucio da se bas i ne koristi ako ne mora ni za odrasle.

Surogat key je isto kao neutralni element u matematici. Sta god pomnozis sa 1 dobijes to isto. To ne znaci da svakom mnozenju treba pripisati x1. ili svakom sabiranju dodati +0. To radi suragat key, mnozi sa jedinicom i dodaje nulu u svaku racunsku operaciju. Ne pomaze nista, ali za razliku od matematike moze da napravi stetu. Medjutim, ako se pazljivo radi, i ne mora da nanese stetu. Jedino kad ima previse 'moze' i 'ako' stvari lako krenu naopako.

Opet ne kazem nemoj da koristis surogat keys. Ne kazem da ti radis pogresno, niti da treba da menjas stil rada. Dozvoli samo ideju i mogucnost da ce sistemi bez ili sa minimalnom upotrebom surogata isto tako raditi kao i oni sa surogatom. Svacija je praksa razlicita. Moja traje vise od 20 godina, svasta sam video, svasta probao, svakojake greske napravio i na osnovu toga mogu da kazem da je od surogat keys veca steta nego korist. Dozvoli samo da oni sa manje iskustva koji citaju ovaj forum imaju vise od jedna opcije na raspolaganju i da cuju za i protiv pa neka sami vide sta ce.

:-)

[ amladjo @ 19.07.2006. 18:03 ] @

Čini mi se da je ova poruka Zidara negde najviše pogodila suštinu.
Moram komentarisati kako je za streptomicin praksa bila lošija od teorije pa zbog toga moramo uvek i u svakom slučaju da se tako ponašamo. Smatraću to, u ovom slučaju, samo želju da se po svaku cenu izbegne poseban primarni ključ jer nije deo teorije već prakse. Poštujem odluku.

Smatraću takođe da se kompozitni ključ koji se proteže u nekoliko child tabela može promeniti iz dva polja u, recimo, četiri i da pravi stručnjak svog zanata ipak drži konce u rukama. Moguće je, i sam sam to nekada činio.
Ubiješ sve foreing ključeve, ubiješ postojeći primarni ključ, dodaš potrebno polje u glavnu tabelu i sve child tabele, stvoriš primarni ključ, stvoriš sve foreing ključeve, zatim menjaš sve upite (i view-ove) da bi sve to profunkcionisalo.
Jeste dugotrajan proces ali je moguć.

Lično, negde na pola puta sam se umorio od toga. Posle toga, ova odluka mi je olakšala i ubrzala dane i dane posla. Ja sam imao više slobodnog vremena a klijentu je ispunjen zahtev na vreme. Nije mi se "lupilo o glavu", barem ne do sada. Upiti nisu sporiji, čak su ponekad puno brži. Negde je to i poruka koju sam "slao" ovde.

Citat:

Opet ne kazem nemoj da koristis surogat keys. Ne kazem da ti radis pogresno, niti da treba da menjas stil rada. Dozvoli samo ideju i mogucnost da ce sistemi bez ili sa minimalnom upotrebom surogata isto tako raditi kao i oni sa surogatom. Svacija je praksa razlicita.

Citat:

Dozvoli samo da oni sa manje iskustva koji citaju ovaj forum imaju vise od jedna opcije na raspolaganju i da cuju za i protiv pa neka sami vide sta ce.

Čini mi se da će oni sa manje iskustva koji čitaju ovaj forum upravo doći do tog zaključka.

Pozdrav Zidaru :)

[ chachka @ 19.07.2006. 20:56 ] @

@amladjo

PRVO

Citat:

amladjo: Da li je bolje dodati ID kao primarni ključ i N:M vezi ili nije.

Brokerov prvi post:

Citat:

broker: ... zavisi ...

Moj prvi post:

Citat:

chachka: ... zavisi ...

DRUGO

Citat:

amladjo: Tvoj model jednostavno ne trpi izmene a ti me ispravi ako grešim.

Ne grešiš. Moj model zaista ne trpi izmene i ja ne mogu da ga izmenim, pogotovo ako mi u PostgreSQL-u uradis

Code:

REVOKE CREATE ON SCHEMA public FROM chachka;

TRECE

Tvoj prvi post

Citat:

amladjo: ... za koju varijantu ću se onda odlučiti?
Naravno za drugu varijantu sa posebnim primarnim ključem kroz jedno polje ...

Nakon toga Broker postavlja problem, a ti dajes resenje.
Broker to resenje komentarise sa

Citat:

broker: Mislim da nema potrebe da se tabelama MATERIJALI_ZADATKA, IZDATI_MATERIJALI i IZDATI_ALATI uvodi posebno polje kao kljuc tabele.

A ti na to kazes:

Citat:

amladjo: Dakle brokerove korekcije su sasvim na mestu ali "tvrdoglavo" zadržavam posebne ID ključeve.

Izvini sto sam rekao

Citat:

chachka: ... ova tema moze biti nekome od koristi. Ne meni i ne tebi, ...

jer si ti ocigledno prihvatio da se surogat kljuc ne trpa po default-u u svaku tabelu.

[ amladjo @ 19.07.2006. 21:31 ] @

@chachka

Citat:

Dakle, kada se pojavi sef sa zahtevima, tada cu prilagodjavati model.

Šef se javio a mi još uvek čekamo...
Ili si jednostavno odlučio da zanemariš šefa (Izabrao si "1. način")?
Sa REVOKE si to jednostavno dokazao.

[ broker @ 20.07.2006. 00:33 ] @

NE bih bas sad da ulazim u polemiku ali bih rekao da radi produktivnosti treba ostaviti po strani sujetu i zelju da se pokaze znanje, nego da gledamo da ova diskusiaj bude korsina onima koji tek uce. Dakle, valjalo bi izbegavati ijave tipa "mator sam ja da bi vama objasnjavao", "imam preca posla", a narocito zalazenej u neke detalje koji nisu bitni a odvlace paznju od onoga sto jeste bitno.

Uzgred, sef ostavio ceduljce:

"Zaboravio sam reci, jedan posao moze da radi vise radnika".

Kajla. Ovo je jedna od stvari koje projektant MORA da predvidi unapred i da pre nego sto pocne da radi projekat, razresi sa nalogodavcem da li je takva potreba ili nije.

Na poledjini cedulje stoji napomena za Cacku:

"Magacioneri se salbo snalaze sa racunariam i bune se da im je unos podataka u trebovanja komplikovan. Magacioner treba da u sto manje koraka dobije sve potrebne podatke za izdavanje materijala i robe i mogucnost da potvrdi sta je od potrebnog izdato i u kojoj kolicini. Potreba unosa sifre radnika i sifre zadatka je neprihvatljiva i treba iskoristiti to sto je vec jednom radniku dodeljen zadatak da se izbegne nepotrebno ponovno unosenje iste dodele prilikom izdavanja materijala. Cesto se desavaju i greske da se prilikom izdavanja materijala, izda materijal radniku za pogresan zadatak ili za neki raniji zadatak, a ne onaj koji je trebalo da se uradi".

[ chachka @ 20.07.2006. 13:35 ] @

"Creating a database can be like creating a universe, only more complicated. At least when the universe was created, there was no one around to complain."
- Michael J. Hernandez

Citat:

broker: NE bih bas sad da ulazim u polemiku ali bih rekao da radi produktivnosti treba ostaviti po strani sujetu i zelju da se pokaze znanje, nego da gledamo da ova diskusiaj bude korsina onima koji tek uce. Dakle, valjalo bi izbegavati ijave tipa "mator sam ja da bi vama objasnjavao", "imam preca posla", a narocito zalazenej u neke detalje koji nisu bitni a odvlace paznju od onoga sto jeste bitno.

Zamerka prihvacena, slazem se i prekidam takvo ponasanje.

Sta se novo izdesavalo po pitanju korisnickih zahteva?

Citat:

broker: Magacioneri se salbo snalaze sa racunariam i bune se da im je unos podataka u trebovanja komplikovan. Magacioner treba da u sto manje koraka dobije sve potrebne podatke za izdavanje materijala i robe i mogucnost da potvrdi sta je od potrebnog izdato i u kojoj kolicini. Potreba unosa sifre radnika i sifre zadatka je neprihvatljiva i treba iskoristiti to sto je vec jednom radniku dodeljen zadatak da se izbegne nepotrebno ponovno unosenje iste dodele prilikom izdavanja materijala. Cesto se desavaju i greske da se prilikom izdavanja materijala, izda materijal radniku za pogresan zadatak ili za neki raniji zadatak, a ne onaj koji je trebalo da se uradi".

Ovo su zahtevi koji se odnose na graficki (tekstualni?) interfejs izmedju korisnika i baze podataka. Ovo je forum o bazama podataka, a ne o izradi GUI-a. Ja za izradu programa koristim Delphi te nakon dizajna baze mozemo preci u forum o Delphi-ju i pokusati da sklepamo neku aplikaciju. Sumnjam da bi to uspelo jer se onda vec pokrece pitanje ko ima pristup kojem SUBP-u zbog kreiranje baze, SQL script bi morao biti potpuno standardizovan zbog raznih SUBP-ova, pa nacin konekcije na bazu (ODBC, ADO, BDE, DBExpress, ...), pa izrada reporta jer uz Delphi 7 dolazi Rave Report kojeg ja u zivotu nisam koristio, ... Ovo se jako tesko moze uspesno dovesti do kraja.

Zidar je radio nesto slicno upotrebom Access-a i za deo baze i za deo GUI-a. Ja Access ne koristim.

Citat:

broker: "Zaboravio sam reci, jedan posao moze da radi vise radnika".

Ovo vec prerasta u ozbiljan projekat pracenja proizvodnje te mu se ozbiljno mora i pristupiti.

Citat:

broker: Ovo je jedna od stvari koje projektant MORA da predvidi unapred i da pre nego sto pocne da radi projekat, razresi sa nalogodavcem da li je takva potreba ili nije.

Tacno! Slicno nesto sam napisao i ja

Citat:

chachka: Nije ni moje rešenje bez propusta. Još kako bih u stvarnom projektu imao što-šta da priupitam i seku kadrovkinju, i batu šefa i tatu direktora.

Mada smo izgleda ostali bez seke :(, jer se neradi o kadrovskoj evidenciji. Izgleda smo dobili jos jednog batu magacionera :)

Zato evo pitanja:

1. Za kakvu firmu mi to uopste radimo? Da li je firma nova, ili vec duze vreme posluje? Kakav je kadar u firmi? Da li sef proizvodnje ima iskustva na toj poziciji, ako ne da li je bar bio radnik u firmi koja se bavi slicnom proizvodnjom? Da li je upoznat sa tehnoloskim procesima proizvodnje ili ce i on da se uci usput kako firma bude napredovala?

2. Sta firma uopste proizvodi? Da li se radi o pojedinacnoj, serijskoj, masovnoj proizvodnji? Da li se u proizvodnji koriste samo alati i materijali ili se koriste jos neki resursi (vreme, usluge drugih firmi, energenti, masine, sudovi za odlezavanje)?

3. Da li se koriste radni nalozi? Ako ne, na osnovu cega se vrsi obracun kostanja gotovog proizvoda?

4. Ako vec postoji grupa radnika koja radi na jednom poslu, da li medju njima postoji predradnik? Da li se radnici zaduzuju za jos nesto (radna odela, zastitnu opremu) osim za alate?

5. Da li se desava da se alat pokvari? Da li se pokvareni alat vraca magacioneru ili se otpisuje ili se daje sluzbi odrzavanja? Sta se desava ako je sav izdati materijal skart?

6. Da li imamo jedno ili vise radnih centara (Nis, Beograd, Novi Sad)? Da li imamo jednog ili vise magacionera (magacioner alata, magacioner materijala, magacioner gotovih proizvoda)? Cak i ako ih nemamo da li imamo potrebu za vise magacina?

7. Da li su propisana potrebna radna mesta po etapama proizvodnje? Da li se sme izdavati materijal i alat za poslednju etapu iako prva jos nije zavrsena? Koliko radnika radi na jednoj etapi? Da li se alat i materijal koriste u jednoj etapi ili se koriste za vise etapa?

Ima tu verovatno jos pitanja, ali cu stati.

[ chachka @ 20.07.2006. 22:39 ] @

Ok, predpostavio sam da ce ovo tesko ici, te cu ja dati i odgovor na pitanja (teram vodu na svoju vodenicu :)

1. i 2.

Angazovala nas je novo formirana firma da izradimo informacioni sistem cija je namena pracenje procesa proizvodnje. Firma se bavi proizvodnjom crpnih pumpi (o ovome nemama pojma, mozda i lupim koju te me ispravite :). Proizvodnja se radi po narudzbini za poznatog kupca.

Direktor proizvodnje je kvalifikovano tehnicko lice sa velikim iskustvom u slicnim firmama. Direktor proizvodnje je zaduzen kako za pracenje i unapredjenje proizvodnje, tako i za kontrolu kvaliteta materijala, alata, gotovih proizvoda. U ovom trenutku je firmi preko potrebno pracenje proizvodnje, dok sam deo kontrole kvaliteta ostavljaju za kasniju doradu informacionog sistema. Pored direktora proizvodnje imamo i dva sefa proizvednje koji su neposredno nadredjeni radnicima u proizvodnji. Sefovi su po recima direktora proizvodnje solidnog znanja, sa prostorom za napredovanje.

U proizvodnji se koriste materijali i alati. Postoji i znacajan utrosak elektricne energije, ali se on ne moze precizno izmeriti po proizvedenoj pumpi. Direktor kaze da se troskovi elektricne energije obracunavaju na mesecnom nivou.

3.

Radni nalog postoji i potpisuje ga sef proizvodnje. Na radnom nalogu je naveden datum izdavanja radnog naloga, broj radnog naloga, koja pumpa se proizvodi, ko sve od radnika ucestvuje u proizvodnji, koji su materijali potrebni i u kojoj kolicini i koji su alati potrebni i u kojoj kolicini. Primopredaji materijala i alata obavezno prisustvuje sef proizvodnje koji i potpisuje da su mu alati i materijali izdati od strane magacionera.

Iako se proizvodnja odvija u etapama materijali i alati se izdaju za konkretanu pumpu, i mogu se izdati odjednom ili u vise navrata.

3a. U ovom momenti pitamo direktora da li postoje normativi za proizvodnju pumpi?

Da, normativi postoje (Nasi stari poznanici 'Potrebni_Materijali' i 'Potrebni_Alati' :), ali se mogu izdati i vece kolicine zbog brzog prevazilazenje problema ako je povecan skarti ili ako se alat osteti (a magacioner je bas otisao na dorucak?).

4.

Nema predradnika, sef ih stalno nadgleda i prati procese proizvodnje i upotrebu resursa. Zastitna oprema postoji, ali je njen rok trajanja godinu i po dana te se ona daje radniku na duze koriscenje. Radnici sami brinu o svojoj opremi. U slucaju da radnik ostane bez opreme ili mu se oprema osteti, odmah mu se daje druga.

4a. Direktore, ovakvim davanjem opreme na koriscenje moze doci do zloupotrebe opreme. Kako sprecavate zloupotrebu?

U ovom trenutku se ne razmislja o tome, veruje se radnicima, imaju dobre uslove rada i solidne plate, te se smatra da nece biti zloupotreba. U svakom slucaju, direktor ce u jednom trenutku uporediti koliko je sluzba nabavke nabavila opreme, a koliko on ima radnika (svaki radnik ima jednu opremu). Ako bude velikih odstupanja morace da smisliti sistem za pracenje upotrebe opreme.

5.

Vec je ranije spomenuto da moze doci do ostecenja alata. Osteceni alat se daje sluzbi kontrole kvaliteta, koka dalje preuzima nadleznost nad ostecenim alatom. I materijal i alat se mogu dodatno izdati na zahtev sefa proizvodnje.

6.

Postoji samo jedna lokacija na kojoj se vrsi proizvodnja pumpi. Zbog cene potrebnog alata i zalihe materijala, uopste se ne razmislja o joj jednoj fabrici. Postoje dva agacionera, ali zajedno duze magacin, jedan u prvoj smeni, a drugi u drugoj smeni. Moze se reci da se i materijal i alat drze u jednom magacinu, s tim da se alat drzi u posebno ozidanoj prostoriji. Proizvedene pumpe se odmah otpremaju kupcu, bez zadrzavanja u magacinu. Ako i dodje do zastoja u isporuci pumpa ostaje u proizvodnoj hali.

7.

Na jednom radnom mestu se mogu izvrsavati sve etape u proizvodnji konkretne pump. Etape sluze da se prati vremenski napredak proizvodnje. Vec je receno da se materijal izdaje za konkretnu pumpu, nezavisno od etape u kojoj se teenutno nalazi proizvodnja. Svaku etapu izvrsavaju svi radnici zajedno (eventualno je neki na pus pauzi). Alat je univerzalan za sve etape. Izdavanje alata i materijala se, kako je vec recno moze obaviti u celosti ili u vise navrata (na kašičicu)

Ima li ko sta da dodada na ove odgovore? Da li da ih usvojimo ili neko ima bolje ideje? Nisam uspeo da ubacim 'Zadaci' iz originala, ali njihovu ulogu ovde potpuno identicno obavljaju 'Gotovi_Proizvodi'

Srdjan

PS: Ljudi pomagajte vodim diskusiju sam sa sobom!!!!! :)

_{[Ovu poruku je menjao chachka dana 20.07.2006. u 23:52 GMT+1]}

[ Miloš Baić @ 21.07.2006. 11:12 ] @

Pozdrav,

neću remetiti odgovore, sem da bi možda trebali odraditi prvo magacin zaliha (materijala) i alata, tabele, povezivanje, kljucevi, pogledi... Pa onda redom...

p.s. mogao bih propratiti pravljenje korisničkog interfejsa u delphi - u...

[ Zidar @ 21.07.2006. 13:43 ] @

Predlazem da se promeni delatnost firme. 'Crpne pumpe' se ne proizvode na opisani nacin - radnici zaduze materijal i alat i onda naprave pumpu, pa posle vrate alat i vrate visak materijala. Sa takvim procesom propali bi posle sest meseci i niakd nam ne bi platili projekat.

Opisani nacin sa izuzumanjem materijala i alata vise odgovara usluznimdelatnostima - opravka puteva, opravka vodovoda, molerski radovi, pranje prozora, ciscenje.

Predlazem dve opcije:
a) Molerska firma. Firma radi na ugovor za vece firme. Kad se ugovori posao, odrede se tim (radnici + predradnik) koji ce na tome raditi. Naruci se materijal, koji stize u magacin, odakle ga tim izuzima. Zavisno od konkretnog posla, potreban je razliciti alat (merdevine razlictih velcina, kompresori, cetke) i materijal (boje, lakovi, razredjivaci). Radnici naravno duze i radna odela i zastitnu opremu. Radna odela se zaduzuju dva puta godisnje, ili po potrebi.
Firma naplacuj 'djuture' - dogovorenu sumu za ceo posao. Firma radi sa nekoliko dobavljaca za boje. Za svaki posao, trze ponudu od dobavljaca i opredeljuju se za jednog. Firma dobija poslove na licitacijama - za svaki posao sastavlja ponudu koju podnosi potencijalnom poslodavcu. U ponudi su opisani radovi koji ce se izvesti. Cesto se radovi izvode na osnovu predmera i predracuna koji dostavi narucilac radova.

b) Firma za pranje prozora. Firma pere prozore na velikim (poslovnim) zgradama. Kad se ugovori posao, odrede se tim (radnici + predradnik) koji ce na tome raditi. Firma ima svoju zalihe deterdzenta za pranje i potrosnog materijala - krpe, cetke. Zaliha se dopunjava po potrebi. Od velikog alata koriste se merdevine, pokretne skele ili hidraulicne platforme, elektricni vitlovi, produzni gajttani, agregati za struju. Firmu su osnovali alpinisti, pa svako imalicnu opremu - konopce i one kajase koje uz to idu. Firma kupuje radnicima jednom godisnje novu licnu opremu.
Firma naplacuj 'djuture' - dogovorenu sumu za ceo posao. Firma ima jednog snabdevaca za deterdzent i potrosni materijal. naruceni materijal placa se u roku od 30 dana. Firma dobija poslove na licitacijama - za svaki posao sastavlja ponudu koju podnosi potencijalnom poslodavcu. U ponudi su opisani radovi koji ce se izvesti.
Radnici koji rade u firmi nisu zaposleni, nego ih frima poziva na ugovor. Placa ih djuture, po obavljenom poslu. Isplate su na ziro racun. Posto su potnijlni radnici alpinisti, cesto su odsutnni, idu na Kilimadzaro ili Anapurnu po nekoliko meseci. Firma vodi kalendar raspolozivosti radnika.

[ grebenar @ 21.07.2006. 14:42 ] @

Zdravo svima
zaista sam se moraou ukljuciti u diskusiju. Rijec je zapravo o tome da li neki pojam smatramo relacijom ili entitetom, i to u svom prvom poimanju pri razvoju baze. Napomenucu da sve vise "prakticara" zastupa tezu o OID-u tj. rjesenju tipa (id, radnik_ID, zadatak_id) Dakle, bez pozivanja na ev. modifikacije, u startu je jasno da sa entitetima (sa uvedenim id) imamo fleksibilniju postavku baze za daljnji razvoj. Domenu ovako uvedenog ID cak dijeli vise tabela za primarni kljuc (generisu se iz jedne sekvence)

[ misk0 @ 23.07.2006. 13:11 ] @

Odem na odmor, kad se vratim imam sta da citam. Kvalitetna diskusija, svi su se potrudili, svaka cast! Ide u TOP
Zamolio bih vas sve, kad dodje do sukoba misljenja tj neslaganja, nemojte pokusavati da diskreditujete sagovornika govoreci 'ti si ovakav ili onakav, ti si ucio ili nisi ucio i slicno' .. ne daje fin miris citavoj diskusiji :).

[ chachka @ 23.07.2006. 17:24 ] @

Citat:

Zidar: Sa takvim procesom propali bi posle sest meseci i niakd nam ne bi platili projekat.

Znaci firma bi radila jos punih 5 meseci nakon propasti naseg IS-a

Za koju smo se "firmu" odlucili? Zidarevi moleri deluju sasvim OK. S tim da ja nebih dalje produbljivao problem na nabavku, prodaju, ugovaranje.

[ amladjo @ 24.07.2006. 01:20 ] @

Svaka firma je zanimljiva na svoj način. Od ponuđenih, odlučio bih se za molersku firmu. Nekako je najbliža onome što poznajem iz vanračunarske prakse. Najviše bi mi prijala firma za pranje prozora ali da sam radnik na odmoru

Svemu ponuđenom dodao bih i stolarsku radnju.
Firma uglavnom radi izradu kancelarijskog nameštaja po narudžbi ali se povremeno javljaju potrebe za izradom ostalog kućnog nameštaja (kuhinje, kupatila, ...). Naš šef je i vlasnik firme i vrlo dobro poznaje svoj posao (dugi niz godina je bio radnik jedne veće fabrike nameštaja) ali mu je sve ostalo velika nepoznanica

Firma je do sada bila, manje-više porodična. Zbog naglog povećanja obima posla planira zapošljavanje većeg broja radnika i pozvao je nas da mu sve to "kompjuterizujemo". Ova je firma dobar primer za IS koji mora biti spreman za česte izmene sistema koje se ne mogu videti na početku.

Svakako bih iz IS izbacio sve ostale delatnosti firme kao što su nabavka, prodaja, vođenje zaliha itd. Ove delatnosti su jako bitne ali i dosta povećavaju "gabarite" projekta. Možemo ih ostaviti za kasnije diskusije.

Možda bi bilo zanimljivo ujediniti IS za ove firme kao potrebu da se napravi program koji će zadovoljiti praćenje proizvodnje u svim firmama sličnih karakteristika.

[ grebenar @ 24.07.2006. 11:58 ] @

U svom prethodnom postu rekoh da je polazno pitanje zapravo dilema da li nesto u startu proglasiti entitetom (normalizovan pojam od interesa sa uvedenim "surogat ključem") iako na prvi pogled liči na relaciju. Svi koji čitaju a sigurno oni koji diskutuju pomisliše- ovaj nešto bubnu - idemo dalje.
Ali, suština je da se surogat ključ uvodi tamo gdje se ne možemo pouzdati u prirodan podskup atributa koji bi činili ključ - što je potpuno drugačije od želje da neki pojam praglasimo pojmom od interesa i da pratimo sve relacije (od interesa) koje gradi sa drugim pojmovima - kako to analiza budućeg sistema zahtjeva..
Diskusija dođe do predloga da se napravi sistem za praćenje proizvodnje firmi određenog tipa. Praćenje proizvodnje kao brojanje mrtvih ne dolazi u obzir - dakle planiranje i praćenje proizvodnje! U Japanu to rade (ili su radili do nedavno) bez računarske podrške - imaju KANBAN sistem koji je zalihe ostavio kod kooperanta pa je dostavno vozilo magacin (trpaš u njega - do linije - kad god ti je na utovarnom mjestu). Na zapadu je ta računarska oblast poznata pod MRP (material requirement planing) i predstavlja kapu jedne oblasti primjene računarske podrške. U njemu su dokumenti unaprijed pripremljeni pa bilo da su u digitalnoj formi ili papir pa je unos sveden na minimum uz obezbjeđene recoveri procedure. Dakle, i jedno i drugo je predmet detaljnih analiza, vrhunskuog poznavanja i proizvodnih procesa i mogućnosti informatičke platforme(i) za implementaciju.
Izuzev par iskrica u ovoj diskusiji, svi se drže jednog (tehničkog) dijela problema pa imaju za / protiv dugačkog join-a i šta je zadatak BP dizajna a šta se ostavlja za GUI. Sada, kada je u jednoj osobi najčešće i projektant sistema i dizajner baze podataka (ne rijetko i koder GUI npr. u Delphiju), jako je važno odgovoriti na polazno pitanje u smislu prve rečenice. Naime, projekat nije nikad dobro ( i do kraja) definisan i najčešće je riječ o otvorenom sistemu - koji odmah treba da daje neke rezultate i da se razvija dalje uz ili bez daljnje naknade ali sigurno sa što manje dodatnih napora ??? Da skratim: sve što želimo pratiti kroz ciklus: planiranje-rođenje-eksploatacija(život)-odumiranje-analiza - planiranje TREBA i MORA biti izdvojeno kao Entitet tj. dodjelit mu ID za čiju integralnost i unikatnost mi odgovaramo i koji u startu dozvoljava multiciplitet na podskupu atributa koji bi inače činili primarni (prirodni) ključ. Ovo nije zahtjev iz teorije baze podataka već iz primjene istih u podršci procesima. Ovim u potpunosti podržavam ono "tvrdoglavo" uvođenje ključeva. Poenta je u tome da je to interna stvar na nivou baze i korisnik je i ne vidi. Ako pri tome ima mogučnost da svoje transakcije nad objektima korektno izvršava - cilj je postignut !

pitanje:
popne se alpinasta do svog prozora, počne ga prati i vidi da ga zovu sa Mt.Blana. Skokne tamo, vrati se, a njegov prozor još nije do kraja opran. Uključi se u rad i na opštu radost prozor konačno bude čist

Ovo su u vremenu dvije konkretizacije relacije radnik-zadatak koje kompozitni kljuc Id_radnik, id_zadatak ne može pokriti.

[ Zidar @ 24.07.2006. 19:18 ] @

Za grebenar:
Na pocetku je covek pitao ovo:

Citat:

U teoriji se, kod prevodjenja u relacioni model, u ovom slucaju formiraju tri relacije

1. Radnik(RadnikID, Ime, DatumZaposlenja...)
2. Zadatak(ZadatakID, Opis, ...)
3. Radnik_Zadatak(RadnikID, ZadatakID)

medjutim, u praksi se uglavnom srece razlicitost kod trece relacije pa ona postaje

3. Radnik_Zadatak(Radnik_ZadatakID, RadnikID, ZadatakID)

ZASTO????

Na kraju smo dosli do tvrdnje:

Citat:

pitanje:
popne se alpinasta do svog prozora, počne ga prati i vidi da ga zovu sa Mt.Blana. Skokne tamo, vrati se, a njegov prozor još nije do kraja opran. Uključi se u rad i na opštu radost prozor konačno bude čist

Ovo su u vremenu dvije konkretizacije relacije radnik-zadatak koje kompozitni kljuc Id_radnik, id_zadatak ne može pokriti.

Zasto ne bi mogao kompozitni kljuc (Id_radnik, id_zadatak ) da pokrije ovo? Ovim pitanjem uvodis u stvari novi entitet - "working session". Kljuc (Id_radnik, id_zadatak) u tabeli Radnik_Zadatak samo govori da je id_radnik dodeljen zadatku id_zadatak. Kad god radnik radi nesto, u nekom danu, na nekom zadatku, to je "working session" (kako se ovo prevodi na srpski?) To ne pise u tabeli Radnik_Zadatak. Meni se cini da nam treba nova tabela, WorkingSessions, gde je deo PK ono 1) sto je PK u tabeli RadniciNaZadacima. Otprilike ovako:

Teorijski nacin:
Radnik_Zadatak(Id_radnik, id_zadatak... ) PK =(Id_radnik, id_zadatak)
WorkingSessions ( Id_radnik, id_zadatak, SessionNum, Datum, KolikoSatiJeRadio) PK= (Id_radnik, id_zadatak, SessionNum)

Na ovaj nacin znam ko je dodeljen kom zadatku i koliko je kog dana radio. Jedan dan radi, drugi dan ne radi, pa opet radi.

Nacin 'iz prakse' :
RadniciNaZadacima (Radnik_ZadatakID, RadnikID, ZadatakID) onda imas PK = Radnik_ZadatakID i AK (RadnikID, ZadatakID)
WorkingSessions (Radnik_ZadatakID, SessionNum, Datum, KolikoSatiJeRadio) PK (Radnik_ZadatakID, SessionNum)

Znaci moze i na jedan i na drugi nacin. Ajde da uporedimo:

Teorijski nacin ima jednu kolonu vise u WorkingSessions. Nacin 'iz prakse' ima jedan index vise u RadniciNaZadacima (AK, Alternate Key). Po pitanju upotrebe prostora smo dakle gotovo isti. Ti si malo bolji, jer u tabeli WorkingSessions imas 2 kolone u PK, a ja imam 3. Prostor nije skup u danasnje vreme, pa se ne bih o tome previse brinuo.

Sto se tice efikasnosti, ja znam direktno iz tabele ko je radio na kom zadatku u kom danu, a tebi treba JOIN.

Sto se tice rada, ti imas vise da radis (jedan index vise, jedan JOIN vise). Da li je to mnogo vise rada - nije. Da li tvoj Radnik_ZadatakID radi brze nego moj (Id_radnik, id_zadatak), to ne mogu da kazem zasigurno, ni da ni ne.

Eto, opet nismo odgovorili coveku - zasto bas mora Radnik_ZadatakID umesto (RadnikID, ZadatakID)? Mala usteda u prostoru? Ma kako zvucalo neprijatno, i dalje stoji ono - 'lakse se pise JOIN ako imas PK od jende kolone'

Osim ako mi ne pokazes kako bi pomocu kljuca Radnik_ZadatakID resio problem koji si postavio na efikasniji nacin nego sto sam predlozio.

----- ovde menjam temu na ovo ----------------

Ja bih pitao ovakva pitanja:
1) Neka imamo tabelu WorkingSessions (Radnik_ZadatakID, SessionNum, Datum, KolikoSatiJeRadio) , kakav god da je PK, nema veze. Ako radnik u isto vreme moze da bude rasporedjen, na nekoliko zadataka, kako obezbediti da u jednom danu nema vise od 8 sati rada? Kako spreciti ovo u tabeli:

RadnikD_ZadatakID, SessionNum, Datum, KlikoSatiJeRadio
1 1 24 Juli 2006 6
1 1 24 Juli 2006 8

Eto, covek odradio 14 sati. Kako to spreciti? Front End resenja ne dolaze u obzir.

2) Ako je tabele WorkingSessions ovkava:
WorkingSessions (Radnik_ZadatakID, SessionNum, Datum, PocetakRada, Krajrada) Pocetakrada, KrajrRada = sati u okviru dana, (ovo mu dodje kao neki timesheet)
Kako obezbediti da se u tabelu ne unose preklapajuci intervali? na primer, da se ne moze uneti:
RadnikID=1, ZadatakID=1, Datum = 24 Jul 2006, PocetakRada = 8:30 , KrajRada = 15:45
RadnikID=1, ZadatakID=2, Datum = 24 Jul 2006, PocetakRada = 10:15, KrajRada = 12:20

I ovaj krade na satima. Bio na dva zadatka u isto vreme.

[ broker @ 24.07.2006. 20:20 ] @

Zidar, previse insistiras na optimalnom korsicenju prostora.

Teorija kaze da redudansu treba izbegavati. Mejdti, ta ista teorija dozovljava redundansu ako ce to da ubrza neke procese.

Najvazniji proces koji treba optimizovati to je koriscenaj programa. Mozemo mi da osmilimo bazu najoptimalnije moguce i najtacnije moguce po teoriji, ako taj model u praksi usporava rad, onda on nije dobar.

A ovaj primer za sa radnicima i zadacima je upravo takav slucaj. ako se ne uvede dodatno polje koje ce postati PK tabele poslovi (radnici_zadaci) to znaci a operater svugde gde se referncija par radnik-zadatak, mora da unosi radnika i zadatak. Prvo, to je sporije a drugo dozvoljava greske.

Druga stvar, par radnik-zadatak nije jedinstven. RAdnik moze isti zadatak da obavlja vise puta. To znaci da u pricu mora da se uvede i podatak o vremenu kada radnik obavlja taj zadatak. To znaci da operatre na izdavanj materijala i alata ne moze samo daunese par radnik/zadatak nego radnik/zadatak/vreme obavljanja zadatka. Sve to psotaj ekomlikovano i sklono greska. Ako se uvede novo polej koej je jedinstveni kljuc koji oznacava grupu radnik/zadatak/vreme obavljanaj zadatka, stvari postaju znatno jednostavnije.

[ Zidar @ 24.07.2006. 21:13 ] @

Ponovo ce firma da propadne.

Mora da propadne, ako peraci prozora svakog dana uzimaju i vracaju materijal i alat iz magacina. Preovodice vise vremena na cekanju u redu u magacinu i voznji do magacina i od magacina do radnog mesta, nego sto rade.

Sto se tice prostora na disku, ne opterecuje me uopste

. Teorijska resenja uzimaju za nijansu vise prostora nego uvodjenje surogat kljuca. Tacno je da ako se stalno migrira kljuc u child tabele, zavrsices sa tabelam koje imaju PK sastavljen od 5-6 ili vise polja. To zaista postaje strava da se ordrzava, ali 2-3 olja, to nije nista. Da li ce nesto da bude sporo za operatera na unosu, zavisi od dizajna front enda, ne od toga kakav je PK izabran. Ja sam samo pokazao da problem moze da se resi, na oba nacina, a Grebenar je tvrdio da ne moze da se resi ako se koristi kompozitni kljuc nego mora surogat.

I nikako ne mogu da zamislim radnika koji pamti u glavi koji je njegov kljuc Radnik_Zadatak_ID, za svih pet zadataka na koje je odredjen, a sve da bi operateru bilo lakse. On zna svoje ime i da ce da radi na zgradi u Terazije Br 2 (Palata Albanija?). Valjda treba radniku da bude lakse, jer on donosi pare. Operater je tu da olaksa radniku posao, ne obrnuto.

Ako radnik radi istovremeno na vise zadataka, pa mu treba isti alat za svaki zadatak, hoce li da izuzme isti alat vise puta? Kako na ovo odgovaraju modeli koje smo predlozili? Djoka Alpinista ce danas da pere prozore na tri zgrade. Alat je isti - konopci i sundjer. I deterdzent ne mozi da duzi na parce. On zaduzi kanticu od 10 litara, jer mu za svaki posao treba 3 litra, i jedan mu ostane da vrati nazad. Onda firma zakljuci da je bolje da alpinisti-peraci prozora zaduzuju po 30 litara deterdzenta i da se u centralu vracaju jednom nedeljno, umesto svaki dan, da se ustedi na gorivu. Kako nasi modeli podrzavaju ovo, bez obzira na to koliko kolona imamo u PK?

A moze i ovaj model poslovanja: firma nema magacin uopste, pa ni magacionera. Radnici - peraci, imaju kreditne kartice na ime firme i sami kupuju materijal, koliko im treba, kad im treba. Firma povremeno pravi obracun - koliko je ko materijala potrosio. Radnici ce svakako da ukradu po neki litar sredstva za pranje prozora. Neka ih, jeftinije je to nego placati zakup za magacinski prostor, magacionera i sve sto uz to ide. Posto forma PRATI POSLOVANJE (razlicit pojam od 'vodi kjigovodstvo') onda ce lako da vidi kad neko debelo iskoci van uobicajenih granica potrosnje pa ce da preduzme nesto.

;-)

[ amladjo @ 24.07.2006. 22:14 ] @

Citat:

Teorijski nacin:
Radnik_Zadatak(Id_radnik, id_zadatak... ) PK =(Id_radnik, id_zadatak)
WorkingSessions ( Id_radnik, id_zadatak, SessionNum, Datum, KolikoSatiJeRadio) PK= (Id_radnik, id_zadatak, SessionNum)

Na ovaj nacin znam ko je dodeljen kom zadatku i koliko je kog dana radio. Jedan dan radi, drugi dan ne radi, pa opet radi.

Nacin 'iz prakse' :
RadniciNaZadacima (Radnik_ZadatakID, RadnikID, ZadatakID) onda imas PK = Radnik_ZadatakID i AK (RadnikID, ZadatakID)
WorkingSessions (Radnik_ZadatakID, SessionNum, Datum, KolikoSatiJeRadio) PK (Radnik_ZadatakID, SessionNum

Za "način iz prakse" bolje je rešenje:

RadniciNaZadacima (Radnik_ZadatakID, RadnikID, ZadatakID,SessionNum, Datum, KolikoSatiJeRadio) onda imas PK = Radnik_ZadatakID i AK (RadnikID, ZadatakID, SessionNum)

Ovo je već velika razlika u odnosu na "teoriju", umesto dve tabele imaš samo jednu

[ Zidar @ 24.07.2006. 22:59 ] @

ZA Mladju: Nije dobro, dve stvari su pomesane. Tabela RadniciZadaci kaze ko je dodeljen kom zadatku i nista vise. To ti je kao neki sastav time. Druga tabela kazuje ko je radio koliko sati - predstavlja kolicinu rada. Kolicina rada i pripadnost zadatku su dve razlicite stvari. Sta ako je neko sef, pa u stvari ne radi nista, a dodeljen je na zadatak, ili na vise zadataka? Ako ne prijevi sate, neces ga nigde videti. Ili, neko je bio bolestan, i nije se pojavio pa nemas nista u tabeli. Zato moras da imas dve tabele, RadniciZadaci i WorkSessions. Pa makar neko bio dodeljen zadatku, a ne radio nista. Sve ovo nema veze sa izborom i konstrukcijom PK.

Ako pitas 'Koji radnici su dodeljeni zadatku broj 1' resenje sa jednom tabelom te primorava da pises GROUP BY iskaz, jer neki radnici mogu da su radili vise puta. I opet mozes da promasis one koji nisu radili uopste, a dodeljeni su zadatku. Sa dve tabele, resenje je trivijalno, a ako dodas LEFT JOIN sa WorkSessions i GROUP BY, vidis ko je koliko sati radio, a neko je radio NULL sati, znaci nije radio, a trebao je.

Ako vec i ides sa jednom tabelom, lepo si primetio da ti treba AK, jer bez njega ne mozes da obezbedis jedinstvenost reda. A kad vec imas i moras da imas AK, cemu ti onda sluzi vestacki PK? I na teorijski nacin mozes da izbacis jednu tabelu ako bas insistiras:

WorkingSessions ( Id_radnik, id_zadatak, SessionNum, Datum, KolikoSatiJeRadio) PK= (Id_radnik, id_zadatak, SessionNum)
je isto sto i
RadniciNaZadacima ( Id_radnik, id_zadatak, SessionNum, Datum, KolikoSatiJeRadio) PK= (Id_radnik, id_zadatak, SessionNum)

Samo se ime promenilo. I isto je pogresno, kao sa vestackim kljucem, nema veze sa kljucem, svejedno su pomesane zabe i babe. Ako koristis jednu tabelu, kaok ces uopste da kazes 'dodeljujem radnika br 7 zadatku br 15 a radice tek od sledece nedelje'. 'Jedna tabela' zahteva da se unese SessionNum, Datum, KolikoSatiJeRadio, a to na pocetku NEMAMO. Znaci, jedna tabela ne dozvoljava ono od cega smo poceli - da se radnik dodeli zadatku. 'Jedna tabela' prihvatice unos samo kada vec postoje sati i SessionNum, a to se desava POSLE pocetka radova. Mozes da kazes 'pa ostavicu da mi ta polja budu NULL' i to ce da znaci 'radnik dodeljen zadatku'. I tu ododsmo do djavola. Kako ces da obezbedis da po svakom radniku i zadatku imas tacno po jedan red gde su SessionNum, Datum, KolikoSatiJeRadio NULL vrednosti? Ne volis NULL ? Dobro, upisaces nesto kao Session=0, KolikoSatiJeRadio = 0. Onda imas dve vrste podataka u istom polju. KolikoSatiJeRadio = 0 nije nikakva kolicina rada, to znaci da je radnik dodeljen zadatku, a KolikoSatiJeRadio = 10 je 10 sati. Eto ga na kraju - dve vrste sustinski razlicitih informacija u istoj koloni - sati i 'znacenje'. Ako me pamet ne vara, to je prekrseno 1NF pravilo. A ako nemamo ni 1NF, onda nam ne treba ralaciona baza, moze i file system. A znas zasto je ovo? Vestacki kljuc te prevario i ucinilo ti se da mozes ni manje ni vise nego da izbacis celu jednu tabelu iz modela. E zato ne valjaju vestacki kljucevi, dozvoljavaju puno toga sto inace nije logicno, pa navedu coveka na pogresdan dizajn a da toga nije ni svestan. Taman posla da ih ne treba upotrebljavati, samo treba biti veooooma oprezan. Zacas se okliznes.

Jos jednom, ja nisam pokusavao da dokazem koji je nacin 'bolji', o tome svako ima svoje misljenje i neka ostane tako. Tvrdnja je bila da teorijski nacin nesto 'ne moze', pa sam pokazao da moze.

A sto bi nesto zvali teorijski nacin, ako postoje bar neki ljudi koji ga upotrebljavaju u praksi?

_{[Ovu poruku je menjao Zidar dana 25.07.2006. u 00:16 GMT+1]}

[ chachka @ 25.07.2006. 00:23 ] @

Svo vreme mi se čini da nešto propuštamo. Naslov teme je teorija protiv prakse, a neko je ranije već lepo rekao da teoriju pišu praktičari. Dakle ova tema glasi praksa protiv prakse :)

Postoji formalna, matimatički jasna, teorija relacionog modela podataka, koja ima svoje aksiome, definicije, teoreme, ali NE POSTOJI FORMALNA teorija o dizajnu baza podataka.

Ako dvojici matematičara date dužinu stranice kvadrata sa zadatkom da izračunaju obim, obojica će doći do jednog jedinog ispravnog rešenja. Isto će se desiti i sa bilo kojim zadatkom iz fizike, hemije, postoji samo jedno jedino ispravno rešenje.

Ako dvojica praktičara dizajniranja baza podataka rešavaju isti problem, ne moraju doći do istog rešenja! Ne postoji jasan, zakonima popločan put za rešavanje problema. Neko je već ranije rekao da je dizajniranje baza podataka skup kompromisa! Ja bih dodao da dizajniranje baza (pa i ostalo programiranje) još uvek u sebi sadrže i dobar deo UMETNOSTI. Ta umetnost nam dozvoljava kreativnost u rešavanju zadataka.

Postoje autori koji trpaju surogatni ključ (OID) u svaku tabelu baze podataka (Scott Ambler?).
Postoje autori koji smatraju surogatne ključeve prihvatljivim (C.J. Date).
Postoje autori koji se gnušaju surogatnih ključeva (Joe Celko).

Izbor je individualan.

Citat:

broker:Druga stvar, par radnik-zadatak nije jedinstven. RAdnik moze isti zadatak da obavlja vise puta. To znaci da u pricu mora da se uvede i podatak o vremenu kada radnik obavlja taj zadatak.

Ovo me navodi da relacija Radnik_Zadatak uopšte ne postoji, te da svojim prisustvom i imenom samo uvodi zabune (ja sam je cak ranije bio preimenovao u Poslovi). Sada mi deluje da je ispravno da se umesto Radnik_Zadatak (ili mog Poslovi) uvede element Radni_Nalog, i to nesto poput:

Code:

CREATE TABLE Radnici (
    id_radnika INTEGER NOT NULL,
    id_radnog_mesta INTEGER NOT NULL,
    ime_radnika VARCHAR(15) NOT NULL,
    prezime_radnika VARCHAR(30) NOT NULL,

  CONSTRAINT pk_rad PRIMARY KEY (id_radnika),

  CONSTRAINT un_rad UNIQUE (id_radnika, id_radnog_mesta),

  CONSTRAINT fk_rad_ram FOREIGN KEY (id_radnog_mesta)
    REFERENCES Radna_Mesta (id_radnog_mesta)
    ON UPDATE CASCADE ON DELETE RESTRICT
);

CREATE TABLE Zadaci (
    id_zadatka INTEGER NOT NULL,
    id_radnog_mesta INTEGER NOT NULL,
    naziv_zadatka VARCHAR(50) NOT NULL,
    trajanje_zadatka INTEGER NOT NULL CHECK (trajanje_zadatka > 0), -- u danima??

  CONSTRAINT pk_zad PRIMARY KEY (id_zadatka),

  CONSTRAINT un_zad UNIQUE (id_zadatka, id_radnog_mesta),

  CONSTRAINT fk_zad_ram FOREIGN KEY (id_radnog_mesta)
    REFERENCES Radna_Mesta (id_radnog_mesta)
    ON UPDATE CASCADE ON DELETE RESTRICT
);

CREATE TABLE Radni_Nalozi (
    id_radnog_naloga INTEGER NOT NULL, -- broj_radnog_naloga
    id_radnika INTEGER NOT NULL,
    id_zadatka INTEGER NOT NULL,
    id_radnog_mesta INTEGER NOT NULL,
    datum_dodele DATE NOT NULL,
    datum_pocetka DATE,
    datum_zavrsetka DATE,

  CONSTRAINT pk_ran PRIMARY KEY (id_radnog_naloga),

  CONSTRAINT fk_ran_rad FOREIGN KEY (id_radnika, id_radnog_mesta)
    REFERENCES Radnici (id_radnika, id_radnog_mesta)
    ON UPDATE CASCADE ON DELETE RESTRICT,

  CONSTRAINT fk_ran_zad FOREIGN KEY (id_zadatka, id_radnog_mesta)
    REFERENCES Zadaci (id_zadatka, id_radnog_mesta)
    ON UPDATE CASCADE ON DELETE RESTRICT,

  CONSTRAINT ch_ran_datum_pocetka CHECK (   (datum_dodele <= datum_pocetka)
                                         OR (datum_pocetka IS NULL)),

  CONSTRAINT ch_ran_datum_zavrsetka CHECK (   (datum_pocetka <= datum_zavrsetka)
                                           OR (datum_zavrsetka IS NULL))
);

I eto ga jedan atribut kao ključ tabele koja povezuje radnike i zadatke! Ali ta tabela više nije relacija (u ERD smislu) nego je postala entitet, čija definicija glasi: Radni nalog je dokument kojim se tim radnika određuje i upućuje na realizaciju jednog posla (ugovora). Ovim radnim nalogom se vraćam na moj prvi post slučaj broj 1.

Citat:

broker:To znaci da operatre na izdavanj materijala i alata ne moze samo daunese par radnik/zadatak nego radnik/zadatak/vreme obavljanja zadatka. Sve to psotaj ekomlikovano i sklono greska.

Ovo je stvar GUI-a. Ni jedan zakon ne nalaže da se za odabir Radnog_Nalog-a moraju koristiti tri ComboBox-a. Može se koristiti jedno dugme sa labelom 'Odabir radnog naloga' na čiji klik se otvara forma koja prikazuje sve nezavršene radne naloge. Pomoću dodatne forme se bira odgovarajući radni nalog.

I slažem se da su tri ComboBox-a potencijalno brža i jednostavnija za programiranje. Kažem 'potencijalno' jer i to zavisi od Application Framework-a koji se koristi.

Što se mene tiče, rezime ove teme glasi:
1. Prednosti surogat ključa:
- brže izvršavanje upita (spomenuo amladjo),
- prostiji JOIN-ovi,
- lakše (brže) povezivanje sa APF-om (jablan), i slično tome lakše (brže) programiranje GUI-a.
2. Prednosti prirodnog ključa
- manje JOIN-ova,
- jači integritet podataka.

Ako izuzmem prednosti vezane za JOIN-ove, ostaje mi da je prednost surogat ključeva u brzini i lakoći, u odnosu na integritet. Brzina se prevazilazi bržim hardware-om, a lakoća kvalitetnijim DBA i programerskim alatima. Brži hardware i kvalitetnije alate donosi budućnost. Ono što budućnost nemože da nam pruži je očuvanje integriteta podataka. Budućnost naprotiv ide na ruku razbijanju integriteta baze podataka.

Moj izbor je jasan. Ne opredeljujem se ni za teoriju ni za praksu. Opredeljujem se za jači integritet baze podataka.

_{[Ovu poruku je menjao chachka dana 25.07.2006. u 01:33 GMT+1]}

[ amladjo @ 25.07.2006. 03:40 ] @

Za Zidara: U pravu si, promakao mi je sastav tima. Ovo je nešto što bi Šef sigurno tražio

Prva varijanta:
ZADACI (ID_Zadatka,NazivZadatka,Trajanje,PotrebnoRadnoMestoID,BrojEtapa)
POSLOVI (ID_Posla,RadnikID,ZadatakID,Etapa,Dodeljen,Zapocet,Zavrsen)

Druga varijanta bi bila:
ZADACI (ID_Zadatka,NazivZadatka,Trajanje,PotrebnoRadnoMestoID,BrojEtapa)
POSLOVI (ID_Posla,RadnikID,ZadatakID,Dodeljen,Zapocet,Zavrsen)
ETAPE (ID_Etape,PosaoID,Dodeljen,Zapocet,Zavrsen)

Alati i materijali su vezani za ID_Posla što mi zabranjuje mogućnost korišćenja alata i materijala po etapama sa druge strane mogu da formiram tim pa etape rešavam u sklopu jednog posla istim alatom i materijalom. Ovo mora da je bitna odluka pri izmeni baze.

Citat:

zidar: E zato ne valjaju vestacki kljucevi, dozvoljavaju puno toga sto inace nije logicno, pa navedu coveka na pogresdan dizajn a da toga nije ni svestan.

Nema razloga da je ovo vezano za izbor ključa, više je stvar odluke šta se želi postići sa etapom. Druga varijanta bolje oslikava našeg alpinistu, nije razdužio alat i materijal već samo "napravio pauzu", prva varijanta je više prilagođena izradi nameštaja: isti je radnik i zadatak a koriste se različiti alati i materijali.

Citat:

chachka: I eto ga jedan atribut kao ključ tabele koja povezuje radnike i zadatke! Ali ta tabela više nije relacija (u ERD smislu) nego je postala entitet, čija definicija glasi: Radni nalog je dokument kojim se tim radnika određuje i upućuje na realizaciju jednog posla (ugovora).

Dugi je put, čini mi se, mnogih relacija koje su postale entitet. Dobar primer je tabela Radnik_Zadatak koja je postala Radni_Nalog. Jedino što sa sigurnošću možemo da tvrdimo jeste da ne znamo kada će se ta transformacija desiti u konkretnom IS-u, možemo samo da se nadamo da previše krut integritet baze neće ostaviti našu bazu daleko iza konkurencije.

[ broker @ 25.07.2006. 07:17 ] @

pquote]chacka:
I eto ga jedan atribut kao ključ tabele koja povezuje radnike i zadatke! Ali ta tabela više nije relacija (u ERD smislu) nego je postala entitet, čija definicija glasi: Radni nalog je dokument kojim se tim radnika određuje i upućuje na realizaciju jednog posla (ugovora).
[/quote]

U pocetnoj postavci zadatka ja zato i nisam stavio tabelu radnik_zadatak, nego tabelu poslovi (a slazem se da vise odgovara radni nalog, mada je u sustini svejedno).

Mejutim, ovom primedbom si ti u stvari najbolje odgovorio coveku koji je zapoceo temu: sustina njegove dileme jeste upravo u tome da i ce na problem koji resava da gleda kao relaciju izmedju dve tabele, ili kao novi entitet u modelu.

Sto se tice surogat kljuca u toj tabeli, nikako se ne zlazem sa idejom da u modelu treba predvidjati da ce nesto da resi GUI. Model mora da radi i kada koristis najprostiji moguci GUI (cak je to i cilj, jer se tako ceo GUI moze uopstiti, i to do te mere da se automatski generise na osnovu modela).

Radnik ne treba nista da pamti, on dobija radni nalog, odstampan na papiru na kome mu pise sve sto treba da zna o poslu koji obavlja. Ideja surogat kljuca je da magacioner sa tog radnog naloga prepise smao jednu sifru i poveze podatke, a ne da mora da prepisuje radni nalog.

Ne slazem se sa tvrdnjom da surogat kljucevi narusavaju integritet baze. Sve je potpuno isto kao i bez njih i sva pravila integriteta mogu da ostanu, samo se prosiruju.

Sto se tice alata, slazem se da je bolja opcija dozvoliti da radnik trebuje alat jednom, a ne svaki put kada treba nesto da radi. To se resava prosto tako sto se iz tabele u kojoj se beleze izdati alati za posao izbaci veza ka poslovima i ostanu samo alati. Tako postoji evidencija koji su alati kod radnika a ako za neki posao treba neki alat koji on nema, moze mu se izdati i taj alat. Verovatno bi valjalo to propratiti i inforamcijom do kada se alat izdaje i verovatno jes nekim atributom vezanim za tu stvar.

Sto se rada u timovima tice, tu postoje dva aspekta:

- prvo, samo posao koji se obavlja je modularan i obavlja ga vise ljudi. To se resava tako sto se prozivod opisuje sastavnicom. Sastavnica opisuje materijale i radnje koje se moraju obaviti kao i njihov redosled. Materijal moze da bude i neki drugi proizvod. Iz same sastavnice ustvari proizilaze pojedinacni zadaci koji se dodeljuju pojedinacnim radnicima. U sustini ne mora da postoji neka jasna definicija tima, jer se prosto pojedini zadaci koji su definisani sastavnicom dodeljuju radnicima.

- drugo, timovi postoje zbog organizacije posla i to je neophodno definisati iz tog razloga. Radniku se ne definise kojoj radnoij grupi pripada, nego i pogonu, kakvo mu je radno vreme (rad u smenama) i slicno.

Mislim da je za skolski primer, koji je predmet naseg razgovora, malo preterano uvlaciti sve to u pricu. I jedno i drugo je previse komplikovano (narocito sastavnica). Treba da se drzimo jednostavnih primera koji pokazuju realne situacije sa kojima se projektant baze srece. Mislim da sastanivcu treba iskljuciti iz price i eventualno otvoriti novu temu za tu namenu (mada je neko skoro bas postavio pitanje u vezi modeliranja sastavnice). Za potrebe skolskog primera, sadasnji zahtev sa zadacima je sasvim dovoljan.

[ grebenar @ 25.07.2006. 07:33 ] @

za Zidara
odgovarajući na moj komentar si između redova odgovorio na postavljeno pitanje. Ja sam mislio da je to bilo jasno iz mojih postova: praksa je prepoznala da je relacija radnik-zadatak najcesce entitet, nazvao ga kako god workingSession, aktivnost, parce_doprinosa. (ovo je chachka rezimirao) Kada ubacis vremensku komponentu obicnim filterom dobivas sastav tima u svakom pojedinom momentu. Dakle, poenta je u tome da je ID_Session dio jedne strukture kojom su definisani i razgranati poslovi i da mu se (putem FK) pridruzuju koji zadatak (čak više njih - u smislu aktivnosti) i koji radnik, i naravno (atributima) kada i koliko. Nadalje su tu pridruzivanje materijala, alata i ev. nekih dodatnih veza ka ostatku sistema.
Ja nisam tvrdio da se moj primjer ne moze rijesiti kompozitnim kljucevima vec da u jednoj tabeli sa kljucem radnikID, zadatakID to ne može pokriti. (tvoje riješenje uvodi novu tabelu što je OK).

Zapravo uopšte ne razmatram koju težinu to donosi na iplementaciju baze, već u najranijoj fazi projekta želim postaviti skup entiteta čije životne cikluse želim pratiti - pri tome nastojim da moj model bude što manji a da je dobra platforma za daljnji razvoj. Iako najčešće sam pišem upite (a u eri query buildera) gotovo mi je nevažno koliko je "dugačak join". Malo mi je bitno i da li ću imati koji index više - sve dok dobivam optimalne planove za izvršavanje upita koji realizuju projektni zadatak.

Moram naglasiti slijedeće: uvođenje objektnih ID (OID - u prethodnom postu sam objasnio da to NISU ni surogat NITI vještački ključevi) kao alternativu kompozitnim ključevima, treba da je konsekventno. Recimo da ih smatramo internim imenima u BP. Dobar dio posla tada otpada na održavanje njihove unikatnosti, integriteta i povezivanja sa alternativnim / prirodnim ključevima. To je u startu minus. Šta dobivamo - vjerniju sliku tj. veću podudarnost modela sa dijelom stvarnog okruženja i gotovo uvijek vec pripremljeni odgovor na dodatne upite i zahtjeve - jer već na nivou modela govrimo o konkretnim stvarima nečekajući da doplivamo do neke relacije - npr. alat može biti u alatnici, kod radnika ili na popravci - ako je kod nas ili može biti tek naručen.

Citat:

Ako koristis jednu tabelu, kaok ces uopste da kazes 'dodeljujem radnika br 7 zadatku br 15 a radice tek od sledece nedelje'.

Praksa MRP i planiranja/praćenja proizvodnje ima "tri Baze Podataka" u jednoj: plansku, aktivnu i rezime. To bitno usložnjava sistem, ali je moguća aproksimacija (koje ce prije ili kasnije tražiti kruha tj. korektniju nadgradnju) da se putem atributa status ta složenost unekoliko prevaziđe.
Što se tiče "kako sprečiti ovo ili ono" to spada u biznis pravila. Dobar dio njih se rješava na serveru (Client/Server) ili danas sve ćešče u okviru poslovnog sloja kod n-tier sistema (radi izdvajanja poslovnih pravila su i uvedeni). Slažem se se da su takve kontrole na front-endu na labavim nogama. Recimo da je rješenje da SP insertuje ili mjenja slog nakon što izvrši određene provjere.

[ Zidar @ 25.07.2006. 14:45 ] @

Dilema je mnogo i resenja ima beskonacno mnogo. Kao sto rece Chachka, jedan deo ovog posla je umetnost. Ta umetnicka komponenta nam omogucuje da za date uslove u datom okruzenju napravimo bazu koja pokriva uglavnom sta se trazi, a fleksibilna je dovoljno da se moze nadgradjivati i dogradjivati.

Ono sto mi je drago i sto postujem veoma je da je svako od nas u svom postu bar jednom upotrebio recenicu tipa 'slazem se .sa kolegom' iako naoko raspravljamo o pristupima koji su razlicitii kao pokusavamo da dokazemo da je pristup A bolji od B. Zadovoljstvo je biti u takvoj raspravi, ili bolje, razmeni misljenja. Svaka cast i uzdravlje.

Imam edno pitanje koje me poduzr muci jer ne nalazim zadovoljavajuci odgovor. U situacijo ovakvoj:

Citat:

Prva varijanta:
ZADACI (ID_Zadatka,NazivZadatka,Trajanje,PotrebnoRadnoMestoID,BrojEtapa)
POSLOVI (ID_Posla,RadnikID,ZadatakID,Etapa,Dodeljen,Zapocet,Zavrsen)

Ocigledno je BrojEtapa odredjuje kardinalnost veze izmedju Zadaci i Poslovi. Kolona Poslovi.Etapa moze bit u opsegu 1,2,3...N, gde je N=BrojEtapa. Pri tome je moguce da je BrojEtapa fiksa n = u tabeli POslovi MORA biti tacno toliko Etapa nakraju, ili je tio samo maksimum = u tabeli Poslovi moze biti maksimalno N Etapa. Pitanje je: kako obezbediti da se ovi zahtevi ispostuju?

Ja ima neka resenja kojima nisam 100% zadovoljan ali ne umem bolje.
- Ako je BrojEtapa fiksan i obavezan, onda naopisem trigger u Zadaci, On INSERT, koji procita BrojEtapa i odmah ubaci u tabelu Poslovi toliko redova. Sve osim PK postaje NULL, pa se kasnije popunjava. Na Poslovi imama tada trigger koji sprecava brisanje i dodavanje.
- Ako je BrojEtapa samo dozvoljeni maksimum = Poslovi mogu da imaju manje ili jednako redova od Zadaci.BrojEtapa, onda nema triggera na Zadaci. Postoji samo trigger na Poslovi koji na INSERT proverava da li vec imamo dozvoljen broj etapa.
Ima li neko nesto sto je jednostavnije za upotrebu od triggera? (front end resenja ne prihvatamo

Drugo pitanje je kako na nivou CHECK constrainys ili nesto tako spreciti preklapanje etapa?. Drugim recima, svka etapa moze da pocne samo posto je prethodna etapa zavrsena. Nesto kao:
NoviRed.POSLOVI.Zapocet <= (SELECT MAX(POSLOVI.Zavrsen) WHERE ID_Posla< NoviRed.ID_Posla)
MS SQL ne dozvoljava SELECT u CHECK constraint, barem do verzije 2000. Da li neki drugi sistem dozvoljava ovakve stvari? SQL standard predvidja da se u CHECK CONSTRAINT mogu koristiti SELECT izkazi ali ne znam da li je to negde stavrno uradjeno.