[es] - Teorija Vs. Praksa

amladjo
Mladen Arbutina
Novi Sad

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

Sajt: www.dynasoft.rs

Profil

^{24.07.2006. u 01:20 - pre 216 meseci}

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.

Odgovor na temu

grebenar
Pavle Grebenar
IT manager
Zavidovici

Član broj: 86758
Poruke: 8
*.dlp62.bih.net.ba.

Profil

Re: Teorija Vs. Praksa

^{24.07.2006. u 11:58 - pre 216 meseci}

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.

Odgovor na temu

Zidar
Canada

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

+79 Profil

Re: Teorija Vs. Praksa

^{24.07.2006. u 19:18 - pre 216 meseci}

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.

Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*

+11 Profil

Re: Teorija Vs. Praksa

^{24.07.2006. u 20:20 - pre 216 meseci}

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.

Odgovor na temu

Zidar
Canada

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

+79 Profil

Re: Teorija Vs. Praksa

^{24.07.2006. u 21:13 - pre 216 meseci}

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.

;-)

Odgovor na temu

amladjo
Mladen Arbutina
Novi Sad

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

Sajt: www.dynasoft.rs

Profil

Re: Teorija Vs. Praksa

^{24.07.2006. u 22:14 - pre 216 meseci}

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

Odgovor na temu

Zidar
Canada

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

+79 Profil

Re: Teorija Vs. Praksa

^{24.07.2006. u 22:59 - pre 216 meseci}

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]}

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

Re: Teorija Vs. Praksa

^{25.07.2006. u 00:23 - pre 216 meseci}

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]}

"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

amladjo
Mladen Arbutina
Novi Sad

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

Sajt: www.dynasoft.rs

Profil

Re: Teorija Vs. Praksa

^{25.07.2006. u 03:40 - pre 216 meseci}

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.

Odgovor na temu

broker

Član broj: 2415
Poruke: 8514
212.62.59.*

+11 Profil

Re: Teorija Vs. Praksa

^{25.07.2006. u 07:17 - pre 216 meseci}

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.

Odgovor na temu

grebenar
Pavle Grebenar
IT manager
Zavidovici

Član broj: 86758
Poruke: 8
*.dlp148.bih.net.ba.

Profil

Re: Teorija Vs. Praksa

^{25.07.2006. u 07:33 - pre 216 meseci}

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.

Odgovor na temu

Zidar
Canada

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

+79 Profil

Re: Teorija Vs. Praksa

^{25.07.2006. u 14:45 - pre 216 meseci}

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.

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

Re: Teorija Vs. Praksa

^{25.07.2006. u 17:12 - pre 216 meseci}

Citat:

Zidar:Drugo pitanje je kako na nivou CHECK constrainys ili nesto tako spreciti preklapanje etapa?.

Da li si čitao knjigu od Richard T. Snodgrass - Developing Time-Oriented Database Applications in SQL? Besplatno se može skinuti u PDF formatu sa njegovog sajta u odeljku Recent Books.

Citat:

Zidar:SQL standard predvidja da se u CHECK CONSTRAINT mogu koristiti SELECT izkazi ali ne znam da li je to negde stavrno uradjeno.

InterBase dozvoljava upotrebu SELECT-a u okviru CHECK CONSTRAINT-a. Na primer:

Code:

CREATE TABLE Temp (
info INTEGER NOT NULL,
CONSTRAINT ch_tmp_samo_pet_redova CHECK ((SELECT COUNT(*) FROM Temp) < 5)
);

CHECK CONSTRAINT ch_tmp_samo_pet_redova dozvoljava da tabela Temp ima maksimalno 5 redova.

"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