Srodne teme
Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Teorija Vs. Praksa

[es] :: Baze podataka :: Teorija Vs. Praksa

Strane: 1 2 3 4

[ Pregleda: 21442 | Odgovora: 73 ] > FB > Twit

Postavi temu Odgovori

Autor
Pretraga teme: Traži
Markiranje Štampanje RSS

jablan

Član broj: 8286
Poruke: 4541



+710 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 15:43 - pre 216 meseci
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.
 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.tippnet.co.yu.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 16:05 - pre 216 meseci
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".
"The best code is no code at all."
 - Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
 - A. Neil Pappalardo
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+710 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 16:24 - pre 216 meseci
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. ;)
 
Odgovor na temu

amladjo
Mladen Arbutina
Novi Sad

Član broj: 30160
Poruke: 53
*.ptt.yu.

Sajt: www.dynasoft.rs


Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 17:24 - pre 216 meseci
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š.
 
Odgovor na temu

Miloš Baić
Miloš Baić
ERP (Dynamics NAV) programer
Beograd

Član broj: 72468
Poruke: 1155
*.neobee.net.



Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 17:52 - pre 216 meseci
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.
Someone's sitting in the shade today because someone planted a tree a long time ago.
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.eqao.com.



+79 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 19:28 - pre 216 meseci
Za Dejana
Citat:
@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...

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
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+710 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 20:03 - pre 216 meseci
Č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.
 
Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.tippnet.co.yu.

Sajt: www.baze-podataka.net


+4 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 20:47 - pre 216 meseci
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.
"The best code is no code at all."
 - Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
 - A. Neil Pappalardo
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+710 Profil

icon Re: Teorija Vs. Praksa17.07.2006. u 23:36 - pre 216 meseci
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.
 
Odgovor na temu

amladjo
Mladen Arbutina
Novi Sad

Član broj: 30160
Poruke: 53
*.ptt.yu.

Sajt: www.dynasoft.rs


Profil

icon Re: Teorija Vs. Praksa18.07.2006. u 00:48 - pre 216 meseci
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
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: Teorija Vs. Praksa18.07.2006. u 07:49 - pre 216 meseci
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...
 
Odgovor na temu

Radudzoni
Radoslav Jovanovic
Beograd

Član broj: 8384
Poruke: 133
*.fiberop.matgnet.com.



Profil

icon Re: Teorija Vs. Praksa18.07.2006. u 10:17 - pre 216 meseci
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.
 
Odgovor na temu

amladjo
Mladen Arbutina
Novi Sad

Član broj: 30160
Poruke: 53
*.ptt.yu.

Sajt: www.dynasoft.rs


Profil

icon Re: Teorija Vs. Praksa18.07.2006. u 10:18 - pre 216 meseci
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).
 
Odgovor na temu

amladjo
Mladen Arbutina
Novi Sad

Član broj: 30160
Poruke: 53
*.ptt.yu.

Sajt: www.dynasoft.rs


Profil

icon Re: Teorija Vs. Praksa18.07.2006. u 10:21 - pre 216 meseci
Eh, okasnih nekoliko sekundi

Šefe, javi se
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: Teorija Vs. Praksa18.07.2006. u 11:21 - pre 216 meseci
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)
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: Teorija Vs. Praksa18.07.2006. u 11:37 - pre 216 meseci
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.
 
Odgovor na temu

amladjo
Mladen Arbutina
Novi Sad

Član broj: 30160
Poruke: 53
*.ptt.yu.

Sajt: www.dynasoft.rs


Profil

icon Re: Teorija Vs. Praksa18.07.2006. u 12:02 - pre 216 meseci
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.
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.eqao.com.



+79 Profil

icon Re: Teorija Vs. Praksa18.07.2006. u 13:45 - pre 216 meseci
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) :-)
 
Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*



+11 Profil

icon Re: Teorija Vs. Praksa18.07.2006. u 13:47 - pre 216 meseci
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
 
Odgovor na temu

amladjo
Mladen Arbutina
Novi Sad

Član broj: 30160
Poruke: 53
*.ptt.yu.

Sajt: www.dynasoft.rs


Profil

icon Re: Teorija Vs. Praksa18.07.2006. u 14:01 - pre 216 meseci
Citat:
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.


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

[es] :: Baze podataka :: Teorija Vs. Praksa

Strane: 1 2 3 4

[ Pregleda: 21442 | Odgovora: 73 ] > FB > Twit

Postavi temu Odgovori

Srodne teme
Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.