[ Mikelly @ 31.07.2009. 11:08 ] @
Ovako, imam tri entiteta (Firme, Poslovne jedinice i Radnici), i svaki od tih entiteta moze imati jedan ili vise brojeva telefona i brojeva ziro-racuna.

Zbog normalizacije trebao nih napraviti zasebne entitete telefoni i ziro racuni.

Moje pitanje je: da li napraviti tri zasebne tabele telefona i ziro racuna za sve gornje entitete, ili napraviti samo po jednu tabelu sa po tri strana kljuca u njoj, pa onda strani kljuc koji za dati telefon/ziro racun nije NULL referencira ili firmu ili poslovnu jedinicu ili radnika?

Izgleda moguce, ali ne znam da li je to dobra praksa, i da li je to dobro sa stanovista referencijalnog integriteta?

Pozdrav i hvala.
[ Getsbi @ 31.07.2009. 13:09 ] @
Ovako nekako sam ja to shvatio. Prva tri rečena entiteta su hijerarhijski povezana (identifikujuća veza i imaju nasleđene PK). TelefonskiImenik i ZiroRacuni imaju po tri prenesena ključa FK (neidentifikujuća veza i svaki može da bude NULL). Prilikom unosa podataka, recimo na formi Telefoskog imenika, zahtevaš unos bar jednog od FK.
[ mr.zhile @ 31.07.2009. 13:47 ] @
@Getsbi
Imao bih par ispravki dijagrama.1.zasto ce u radnjiku IDFirme,kad on radi u poslovnojj jedinici?....ja bi stavio u poslovna jedinica kao PK FIRMAID+Poslovna JedinicaID(pjID) gde bi pjId bio autoincrement....
2.primedba da se ne stavlja ImePrezime zajedno vec to razdvoji,to je osnovno pravilo denormalizacije....
3.Entiteti Ziro RAcun i broj tel su po meni bzvz ja bi mozda tovodio za svakog od entiteta Firma,Poslovna jedinica,RAdnik....ali ni to nije bas najsrecnije...videceom mozda se javi neko ko ima vise znanja..
pozdav
[ Getsbi @ 31.07.2009. 14:35 ] @
@ mr.zhile
Nisam ja njemu pravio model, jer za to nemam sve informacije. Samo sam mu nacrtao veze i ključeve.
1. To je pravilo nasleđivanja ključeva. Inače da bi te rasporedili u Poslovnu jednicu prvo moraju da te prime u Firmu.
2. PrezimeIme je legalan atribut kolko i odvojeno Prezime, odvojeno Ime. Slažem se da je bolje razdvojeno, pogotovo ako hoćeš svim Jovanama da čestitaš imendan ali još jednom kažem da mi nije namera bila da pravim model. Mogao sam čak i da ne unesem neključne atribute.
3. To je stvar viđenja projektnog problema. Ako se zahteva na jednom mestu držanje svih ZiroRacuna (recimo zbog plata i slično) i ako sva tri gornja entiteta mogu imati više od jednog žiro-računa, onda ne vidim zašto bi to bilo "bzvz". Ili napraviti Telefonski imenik firme u sklopu nekog IS.





[Ovu poruku je menjao Getsbi dana 31.07.2009. u 15:50 GMT+1]
[ Zidar @ 31.07.2009. 15:25 ] @
Getsbijev model izgleda OK.

1) Prenos PK u celosti ili Autonumber? Moze i jedno i drugo, u ovom konkretnom slucaju, ali je Getsbijev pritup bolji. Evo zasto.

Na raspolaganju nam je jako malo podataka o tome sta se modelira i zato dobijamo cistu hijerarhiju Firna->Radna Jedinica->Radnik za okosnicu sistema. Kad je u pitanju tako cista hijerarhija, onda moze i ovo sto Zile kaze, da se ne prenosi ceo PK iz tabele u tabelu, nego da Rdanjedinica ima autonumber PK, pa se samo RadnaJedinicID prenosi radniku. Medjutim, u zivotu nsita njie cista hijerarhija, pa je Getsbijev pristup zdraviji, jer dopusta prosirenje modela uz ocuvanje integriteta.

Zile, zamisli da se sad doda entitet, kao sto ce se dodati zasigurno, samo nam jos nisu kazali, entitet dakle, Kancelarije. Svaka kancelarija pripada ponekoj firmi, a radnici rade u kancelarijama. Ono sto je Getsbi napravio nece dopustiti da se radnik iz firme A smesti u kancelatriju koja pripada firmi B. Ako se ne prenosi kljuc od Firme do Radnika, imaces

Firma (FirmaID PK)
RadnaJedinica (RadnaJediciaID PK, FirmaID FK)
Radnik (RadnikID PK, RadnaJedinicID FK)

Dodajemo Kancelarije (FirmaID FK, KancelarijaID PK) i naravno, RadnicUKancelarijama (RadnikID PK, KancelarijaID PK)

Evo nam tempirane bombe. RadnicUKancelarijama je vezna tabela, iliti relacija, koja povezuje Radnike i Kancelarije. Ima PK (RadnikID, KancelariajID). Bilo koja kancelarija moze se dodeliti bilo kom radniku. Not good, not at all .....


Getsbijev model:

Firma (FirmaID PK)
RadnaJedinica (RadnaJediciaID , FirmaID FK) PK = (RadnaJediciaID , FirmaID )
Radnik (RadnikID , FirmaID FK, RadnaJedinicID FK), PK = (RadnaJediciaID , FirmaID , RadnikID)
Kancelarije (FirmaID FK, KancelarijaID PK)
RadnicUKancelarijama (RadnaJediciaID, FirmaID, RadnikID, KancelarijaID), PK = (RadnaJediciaID, FirmaID, RadnikID, KancelarijaID)

Sad vec ne moze da se radnik smesti u kancelariju druge firme.

Slozeni PK, kako je getsbi uradio ima i druge dobre strane. Neki veoma cesti kveriji se pojednostavljuju. Na primer, "ko radi u kojoj firmi?". getsbijevo resenje dopusta da se uradi jednostavno
SELECT * FROM Radnici
i tu sve pise. Znam, znam, ne vidi se puno ime firme. ako treba dodos JOIN i vidis ga. Uoci ovo 'ako treba'. Mnogo puta to 'ako treba' ne stoji, pa ti ne treba JOIN. Kveri bez JOIN je uvek brzi nego kveri sa JOIN.
Dalje, ako ovi silni ID nisu briojevi, nego text, neke skracenice, onda bi SELECT * FROM Radnici dalo nesto kao

'Petar Markovc', 'PtMrk00001', 'EnrgPrj,'NskGrd'
'Janko Jankovic', 'JnJnk00007','GSP','MehRad'
'Janko Popovic', 'JnPpv00006','GSP','Nab'


Ovo vec daje lepu informaciju. Za mnoge kverije bice dovoljno procitati EnrgPrj i znati d aje to EnergoProjekt, ili GSB. Zatim NskGrd bi mogla biti 'Niskogradnja', 'MehRad' bi mogao biti 'mehanicarska radionica', 'Nab' bi bila 'Nabavna sluzba'


2. . ti je Getsbi odgovorio, stvar projektanta kako ce da vidi sistem. U ovoj fazi, svakako dovoljno dobro.

3. Jedino sto nedostaje, jesu neke CONSTARINTS. Na primer, ako je u pitanju Ziroracun firme, onda PoslovnJedinicID i RadnikID treba da su NULL u tabeli ZiroRacuni. Tako za sve ostale kombinacije. Da izbegnemo komplikovane CONSTRAINTS, mozemo da uvedemo tipove za entitete ZiroRacun i Telefon, pa na kraju dobijemo nesto ovako:




Mnogo tabela? Slazem se, ali shema barem garantuje integritet podataka. Ako se pretpostavi da ce biti tacno tri nivoa hijerarhije, Firme/RadnaJedinic/Radnik, onda je shema OK. I tipizacija podataka je OK. Tabela ZiroRacuni ima PK Brojracuna. Svaki racun ima tip koji pokazuje kojoj vrsti entiteta taj racun pripada. Moze pripadati frmi, radnioj jedinici, radniku. U Banci su svi racuni na gomili i inace. Broj racuna izdaje banka, firma ga samo belezi u ovoj tabeli da bi finansijska sluzba mogla da upotrebi te brojeve za svoj radnje. Tabela ZR_Firme ima kolonu TipRacuna koji moze biti samo i samo 'F'. Znaci tu je moguce upisati samo one acune koji u tabeli Racuni imaju tip 'F'. Isto je za tabele ZR_PJ i ZR_Radniak, svaka ima fiksiran TipRacuna koji mzoe da primi. Time se eliminise svaka mogucnost da se isti racun unese u na dva mesta.

U sledecoj poruci primer kako smanjiti broj tabela. Uz jedno veliko ALI....



[Ovu poruku je menjao Zidar dana 31.07.2009. u 16:49 GMT+1]


[Ovu poruku je menjao Zidar dana 31.07.2009. u 16:52 GMT+1]
[ Zidar @ 31.07.2009. 20:23 ] @
Moze i ovako:


Ovako bi izgledao unos u tabelu Eniteti, za firmu (EntiteID=1), koja ima dve poslovne jedinice EntitetID (2,6), i svaka poslovna jedinica ima neke radnike:

Code:

EntiteID TipEntitetea Roditelj
1,            'F',        NULL
2,            'PJ',        1
3,            'R',        2
4,            'R',        2
5,            'R',        2
6,            'PJ',        1
7,            'R',        6
8,            'R',        6


lepo s evidio ko je kakav tip entitetea, ko kome 'pripada' u hijerarhiji. nema problema sa racunima i telefonima, lako mozemo da dodamo i vise racuna po entitetu i vise telefona po netiteteu. Samo ce se promeniti uslovi za jedinstvenost redova u tabelama Telefoni i Racuni. Opet cemo imati tri podtip tabele, za radnike, radne ejdinice i frime. Svaka ima svoje atribute, koji odgovaraju tom tipu entiteta.

Sva bajnio i sjajno, osim nekih sitnih problema. Na primer:

Problem 1: Napisati kveri koji izlistava sve radnike koji rade u istoj firmi
Problem 2: Sabarti plate po radnim jedinicama

Posle gledanaj u ove probleme, ona prva shema postaje sve atraktivnija :-)
[ Mikelly @ 31.07.2009. 20:49 ] @
Getsbi je skroz dobro napravio model.

Ono sto je mene najvise interesovalo i zbog cega sam postavio pitanje je ono cega se Zidar dotakao na pocetku njegove stavke 3.

Samo jedan strani kljuc u tabelama telefoni i ziro racuni moze biti ne NULL. I bas me interesuju ti komplikovani CONSTRAINTS.

Dobro, ovo tvoje rjesenje sa, aj' da ih tako nazovem "apstraktnim" tabelama telefoni i ziro racuni je skroz ok, ali ja sam upravo htio da izbjegnem vise tabela sa ziro racunima i telefonima.

A ja bih u tabelu Radnici, osim kljuca te tabele stavio samo strani kljuc tabele Poslovne jedinice. Jer, nekako gledam, staviti tu i strani kljuc tabele Firme je redundantnost (ok necemo zbog toga umrijet', ali svakako malo komplikujemo stvari).

I, ako dobro citam dijagram, ti i u tabeli Poslovne jedinice i u tabeli radnici pravis kompozitne primarne kljuceve koji sadrze i primarni kljuc (sada kao FK) tabele viseg nivoa. Je li to dobra praksa, pravilo, jer ja ne vidim potrebu za tim? Moj dijagram je u attachmentu.

Onda, kad nam trebaju sve informacije povezani JOIN:
Code:
SELECT -- FROM Firme INNER JOIN Poslovne_Jedinice ON Firme.ID_Firma = Poslovne_Jedinice.FK_Firma INNER JOIN Radnici ON Poslovne_Jedinice.ID_PJ = Radnici.FK_PJ


Svakako nam treba poneki JOIN kad povezujemo tabele.

Ne znam, ja to nekako tako vidim, ako sam u krivu, pokazite mi kako treba :)

Pozdrav.



[ Zidar @ 31.07.2009. 21:33 ] @
@ mikelly : Dobro, neces kompozitne kljuceve, to je OK ako se shema nece prosirivati, ako ostaje sva bas ovako. Moze da prodje. Medjutim, ne valja tabela Ziroracuni. Imas ZiroracunID kao PK, verovatno opet autonumber. To je Ok. Medjutim, ako nemas UNIQUE cnstraint na Broj_ZR moze se desiti da jedan isti Broj_ZR imaju dve osobe/firme/radne jedinice. Stavi bar da je Broj_ZR UNIQUE.

Komplikovane constraints za tabelu Ziro racuni:? Ovo je logika:

Moraju biti zadovoljena sledeca tri uslova istovremeno:

1) Ako sam radnik, onda kolone FK_Firma, FK_PJ moraju biti NULL a FK_RAdnik mora biti NOT NULL,
2) Ako sam PJ, onda FK_PJ IS NOT NULL i FK_RAdnik = NULL i FK_Firma = NULL
3) Ako sam Firma, onda FK_Firam IS NOT NULL i FK_RAdnik = NULL i FK_Firma IS NULL

To se pise otprilike ovako nekako:
Code:

ALTER TABLE Ziro_Racuni
ADD CONSTRAINT ck_ZiroRacuni_Samo_jedan_NOT_NULL 
CHECK
 (
1 =
CASE
    WHEN PK_RAdnik IS NULL AND FK_PJ IS NULL AND FK_Firma IS NOT NULL THEN 1
    WHEN PK_RAdnik IS NULL AND FK_PJ IS NOT NULL AND FK_Firma IS NULL THEN 1
    WHEN PK_RAdnik IS NOT NULL AND FK_PJ IS NULL AND FK_Firma IS NULL THEN 1
    ELSE 0
END
)


Q:
Citat:
A ja bih u tabelu Radnici, osim kljuca te tabele stavio samo strani kljuc tabele Poslovne jedinice. Jer, nekako gledam, staviti tu i strani kljuc tabele Firme je redundantnost (ok necemo zbog toga umrijet', ali svakako malo komplikujemo stvari).

I, ako dobro citam dijagram, ti i u tabeli Poslovne jedinice i u tabeli radnici pravis kompozitne primarne kljuceve koji sadrze i primarni kljuc (sada kao FK) tabele viseg nivoa. Je li to dobra praksa, pravilo, jer ja ne vidim potrebu za tim? Moj dijagram je u attachmentu.


Redundantnost se ne vidi brojanjem kolona u PK. I nije cilj normalizacije da se PK napravi sa sto manje kolona. Sve zavisi od logike i polsovnog procesa koji modelujes. Ako ce tvoj sistem ostati ovakav kakv je, moze kako hoces. Potreba za komplikovanim CONSTRAINTS ukazuje na propuste u dizajnu. Stalno govorim 'ovo sto si uradio moze da prodje. To znaci da teorijski nije najcistije, ali za praksu, pod odredjenim uslovima, moze i tako. Iz prkase znam da se uslovi menjaju, ni jedan realan sistem nema 5 tabela i ni jedan realan sistem ne izgleda kao cista hijerarhija. 'Apstraktne' tabele uopste nisu apstraktne. One su ono sto nedostaje tvom modelu da bi izbegao rogobatne constraints. Ne modelira se samo ono sto se okom vidi. Kao kad u matematici pomnozis obe strane jednacine s nekim brojem da bi resio sitem. Bazu kad pravis zaozbiljno, pravis je tako da moze da trpi promene u buducnosti. A kompozitni kljucevi tu bolje funkcionisu nego autonuber.

Kad vec ne volis redundansu, cemu ti sluzi kolona ID_ZiroRacun? Ako je sam ziro racun jedinstven, ne mogu dva coveka ili dve firnme imati isti ZR, cemu ti sluzi ID_ZiroRacuna? Razum ID_Firme i ID_PJ - to je za vezu izmedju tabela, i da 'smanjis redundansu'. Tabela ZiroRacuni je rubna tabela, ona nema dece u tvom modelu. Sa cim ce se povezati ID_ZiroRacun? Ako se nece povezati ni sa cim, cemu ti sluzi, s obzirom da vec postoji jedinstvena kolona?

Problem sa autonumber PK je sto ljudi naprosto zalepe po jedan na svaku tabelu i ne razmisljajuci o logici i onda to pocnu da sele iz tabele u tabelu, misleci da su obezbedili integritet podataka. kad nalepis identity i proglasis ga za PK, to je kao kad u matematici pomnozis sa 1. Nista se ne mnja, a ti kao nesto uradio.



[ Mikelly @ 31.07.2009. 22:42 ] @
Ok, prvo, super je fora za CHECK CONSTRAINT, vazda se od tebe ima sto naucit'.

Drugo, vidim da ti ne volis autonumber. OK. I sto se tice ID_Ziro_racun, to 100% stoji, nisam razmisaljao dovoljno daleko, jer sam i ja jedan od onih ljudi sto vole da prilijepe po jedan autonumber svakoj tabeli. To necu uraditi samo ako postoji bas ocegledna jedinstvena kolona u tabeli. Ali ne vidim sta ima lose u tome da svakako jedinstveno oznacis zapise tabele. Uvijek sam nekako smatrao da primarni kljuc i strani kljuc mogu biti jedina 'dozvoljena' redundansa, strani kljuc to svakako jeste. Znam da se vrijednosti autonumber primarnog kljuca mogu poklapati izmedju tabela, ali je veza PK->FK kristalno jasna.

Ovo svakako otvara novu perspektivu. Ajd' mi prokomentarisi sledece:

Da li je, u tvom prvom dijagramu, polje PoslovnaJedinicaID autonumber ili ne? I u tabeli Radnici, zasto imas i RadnikID i RadnikAutonumber? Jesu li PoslovnaJedinicaID i RadnikID Unique?

Fala :)
[ Zidar @ 04.08.2009. 15:54 ] @
Citat:
Drugo, vidim da ti ne volis autonumber.

Nije da ne volim. Iam situacija kad je autonumber neophodan. Ovde svakako nije, ali se moze primeniti, ponavlanm, pod uslovom da sistem ostane upravo oavkav kakv jeste - cista hijererhija i shema baze koaj se absolutno niakda nece menjati. Drugi razlog je zloupotreba autonumbera.

Kazes
Citat:
Ali ne vidim sta ima lose u tome da svakako jedinstveno oznacis zapise tabele.
Ako vec imas nesto drugo sto zapise oznacava jedinstveno, cemu uvodjenje jos jednog kljuca? Nije li to redundansa, ka sto videsmo iz tabele ZiroRacuni. Rekao sam vec - ljudi uzmu i polepe autonumber na sve tabele, bez razmisljanja. I onda stanu na tome, jer su zaboga time obezbedili jedinstvenost.

Da ti nisam skrenuo paznnju na ejdinstvenost ziroracuna, tvoja tabel abi zigledala nekkao ovako:

CREATE TABLE ZiroRacuni (ID autonumber PK, ZiriRacun text, Entitet int FK)
Super, imas PK koji je autonumber, ali si zaboravio da proglasis ZiriRacun za unique. Pazi ovu seriju SQL naredbi:

INSERT INTO ZiroRacuni (ZiriRAcun, FK) VALUES ('123-456-789', 1);
INSERT INTO ZiroRacuni (ZiriRAcun, FK) VALUES ('123-456-789', 2);
INSERT INTO ZiroRacuni (ZiriRAcun, FK) VALUES ('123-456-789', 3);
INSERT INTO ZiroRacuni (ZiriRAcun, FK) VALUES ('123-456-789', 4);
INSERT INTO ZiroRacuni (ZiriRAcun, FK) VALUES ('123-456-789', 5);
INSERT INTO ZiroRacuni (ZiriRAcun, FK) VALUES ('123-456-789', 6);

Upravo sam dodelio jedan isti ziro-racun petorici tradnika. I nisam narusio jedinstvenost, PK je PK, svaki rekord ima razlicti ID.

Poenta je da se bez realnog PK ne moze, a bez vestackog (autonumber) se moze. AKo s ebez necega moze, to je redundantno, suvisno. Znaci, upotrebom autonumbera pobijas sopstevnu ideju da minimizujes redundansu. Kad se govori o redundansi, misli se na LOGICKU redundansu, a ne na 'fizicku'. Misli se na cuvanje adrese stanovanja na vise mesta, na prepisivanje podataka o klijentu u trabelu Fakture, na cuvanje izracnatih vrednosti, na cuvanje stvari kao sto su stanje na lageru u tabelama.

Citat:
Da li je, u tvom prvom dijagramu, polje PoslovnaJedinicaID autonumber ili ne? I u tabeli Radnici, zasto imas i RadnikID i RadnikAutonumber? Jesu li PoslovnaJedinicaID i RadnikID Unique?

Tacno, svi autonumber koje si nabrojao su suvisni i nepotrebni. Zadrzao sam ih jer me mrzelo da prepravlajm model potpuno. Dodao sam na model sta sam smatrao da nedostaje, a nisam skinuo nista.

Inace, autonumber imaju veliku ulogu u odredjenim situacijama, ne treba ih izbegavati po svaku cenu. Na primer, modeliras kasu u samousluzi, prilicno set zadatak. Jedna ista roba mzoze se pojaviti X puta. Skeniras cokoladu na pocetku. Zatim skeniras mleko, jogurt, brasno. Pa se pojavi jos jedna cokolada, ista kao na pocetku. Na racunu ce se pojaviti cokolada na pocetku, i jos jedna ista takva negde usredini. U ovoj situaciji ne moze da se uzme (RacunID, ArtiklID) za PK, jer bi se isti ArtiklID pojavio vise od jednog putana istom racunu. Nemamo dakle prirodni PK. E tu nam treba vestacki kljuc, a nista bolje nego autonumber. I tu ponovo ulazimo u opasnost koju sam ilistrovao sa onih 5 INSERT komandi. Prodavacica moze tri puta da skenira istu cokoladu, pa zavrsis sa jednom cokoladiom u torbi, a platio si tri. U vreme privatinih samousluga ovo nije naivna i nezanemarljiva opasnost. Zato stalno vidis ljude na kasi koji 'proveravaju racun', proveravaju da nije kasirka nesto otkucala vise nego sto treba. A sve zato sto Autonumber ne sprecava kasirku da unese de fakto duplikate, a da baza podatak ne vidi da su to duplikati.

Sa autonumber se lako odstupa od stvarnosti, a baza treba da modeluje stvarnost i pravila iz stvarnosti sto je moguce bolje. Zato nije da ih ne volim, ali sam veoma oprezn sa njima. Praksa me naucila da se autonumberu ne sme verovati.

[ misk0 @ 04.08.2009. 21:34 ] @
Citat:
Zidar:
Upravo sam dodelio jedan isti ziro-racun petorici tradnika. I nisam narusio jedinstvenost, PK je PK, svaki rekord ima razlicti ID.

Poenta je da se bez realnog PK ne moze, a bez vestackog (autonumber) se moze. AKo s ebez necega moze, to je redundantno, suvisno. Znaci, upotrebom autonumbera pobijas sopstevnu ideju da minimizujes redundansu. Kad se govori o redundansi, misli se na LOGICKU redundansu, a ne na 'fizicku'. Misli se na cuvanje adrese stanovanja na vise mesta, na prepisivanje podataka o klijentu u trabelu Fakture, na cuvanje izracnatih vrednosti, na cuvanje stvari kao sto su stanje na lageru u tabelama.


Svidjelo mi se objasnjenje i rezonovanje, ali sta se desava ako si greskom unio PK (ziro racun recimo, kako to kazes da bi bilo ispravno) i to ti je veza prema drugoj tabeli? Da li ces dozvoliti korisniku ispravku te greske i ako dozvolis da koje uslove mora da zadovoljava baza podataka da bi se i vezane tabele azurirale?


Citat:
Kasa, autonubemr i to.....


Ne mozes to bas tako plasticno gledati. Ja sam pravio kasu za restorane i kafane i recimo da sam taj niz artikala dok nije doslo do stampanja i placanja drzao samo u memoriji. Nisu to ogromni podaci, a lakse je manipulisati (dodavanje i brisanje stavki, promjena kolicine i sl) dok su u memoriji. Kad bih vrsljao po bazi, mislim da bih daleko vishe bazi napravio posla. To je moje misljenje na datu temu :)
[ Mikelly @ 05.08.2009. 08:22 ] @
Pa rekoh ti ja da gledam na primarykey kao jedinu dozvoljenu redundansu (u slucaju kada je pk autonumber). Dobro si rekao, kada se bez necega moze, to je redundantno. Zbog toga sam i ja nedje ranije rekao, da je FirmaID u tabeli Radnici redundantnost jer je visak, Radnik vec pripada Firmi, posredno kroz vezu Radnik->Poslovna jedinica.

A sto se tice ziro racuna, slazem se da moraju da budu jedinstveni. Opet moj propust. Nadam se da je zbog brzine. Ali polje ziro racun je char/varchar tipa. Sad te pitam, je li bolje da je custered index char ili int? B-stabla su, moras se slozit, efikasnija sa cijelim brojevima. Koliko, ne znam. Sigurno da povecanjem broja zapisa, raste i prednost int-a nad ostalim tipovima.

Tvoje misljenje? Ako imas recimo 500 firmi i polje PIB (8 ili 13 karaktera) im je kljuc i pravis tabelu dnevnih pazara za njih, da li bi radije izabrao kompozitni kljuc FirmaFK, Datum ili bi dodijelio novoj tabeli autonumber?
[ Getsbi @ 05.08.2009. 09:10 ] @
@ Mikelly
Polje Autonumber (Increment), postavljam za PK samo kad ne postoji nijedan dobar kandidat iz grupe prirodnih ključeva, a svaki zapis mora da bude jedinstven. Pošto primarni ključevi često (ne uvek) odražavaju, osim redosleda unosa u neku tabelu i prirodan poredak stvari, onda Autonumber baš i nije podeasan. Ne zaboravite da je Autonumber nepodesan za praćenje poredka, jer ne toleroše brisanje. Imaćete preskočene brojeve u redosledu. Kod FirmaID to možda i ne bude važno, ali kod PoslovnaJedinicaID to može da izazove pometnju i da na kraju imate broj poslovne jedinice u firmi recimo 9, a ta firma ima samo četiri poslovne jedinice.

Redundanca (suvišnost, suvišna informacija, prekomernost, ponavljanje istih podataka) se izbegava tamo gde je to moguće i gde neće da poremeti prirodan tok stvari (u ovom slučaju hijerahiju). Redundanca se nastoji smanjiti i dovesti na razumnu meru. Retki su IS zasnovani na modelima bez neke manje redundance.

„Tvoje misljenje? Ako imas recimo 500 firmi i polje PIB (8 ili 13 karaktera) im je kljuc i pravis tabelu dnevnih pazara za njih, da li bi radije izabrao kompozitni kljuc FirmaFK, Datum ili bi dodijelio novoj tabeli autonumber?“

Ako dodeliš tabeli dnevnih pazara PK = FirmaFK + Datum, siguran si da nećeš moći da uneseš dva puta isti dnevni pazar, a to se za PK = Autonumber ne može reći.


[ Mikelly @ 05.08.2009. 10:50 ] @
Kapiram to. Ono sto mene interesuje je to vs. efikasnosti takvog jednog kompozitnog kljuca. Na nivou godine ce biti oko 150000 zapisa. Koliko ce kompozitni kljuc (char + datetime) biti efikasan nad tolikom kolicinom podataka i da li ce usporavati neke eventualne proracune?
[ Getsbi @ 05.08.2009. 11:01 ] @
Svi ozbiljniji SUBP-ovi održavaju indexe nad poljima primarnog ključa. Indexi se prave i u "letu" prilikom izvršavanja upita nad neindeksiranim poljima. Mislim da ovo nebi rebalo da te zabrinjava. Recimo da za MS-SQL server, cifra od 150.000 zapisa nije velika.
[ Zidar @ 05.08.2009. 14:55 ] @
@misko:
Citat:
Svidjelo mi se objasnjenje i rezonovanje, ali sta se desava ako si greskom unio PK (ziro racun recimo, kako to kazes da bi bilo ispravno) i to ti je veza prema drugoj tabeli? Da li ces dozvoliti korisniku ispravku te greske i ako dozvolis da koje uslove mora da zadovoljava baza podataka da bi se i vezane tabele azurirale?

Ako greskom uneses PK u jednu tabelu, pa ne primetis gresku odmah, nego je propagiras u child tabele, onda si u nevoljii i to se tesko ispravlja. Brises sve iz child tabela, pa update za parent, pa vracas nazad ono sto si obrisao iz child tabela sa promenjenom veznom kolonom. I to je ozbiljan proces, neprijatan, ali sta da se radi. Greska na unosu je neprijatan i problem se resava na unosu, kojekekvim kontrolama i proverama. Zato se polja tipa ziro-racun grade po nekim pravilima, da bi se na ulazu smanjila greska. Dodavanje check digit je cest nacin smanjivanja greske. Seti se maticnog broja gradjana. To je racunsko polje, sadrzi datum rodjenja i plus check digit. Check digit sprecava greske u kucanju, ali ne i dodelu 'tacnog' JMBG pogresnoj osobi. Tvoj broj moze da se dodeli meni. Ali, ako trazimo da se datum rodjena poklolpi sa delom maticnog broja, smanjujemo mogucnost greske, jer verovatno nismo rodjeni na isti dan. Tako nesto treba da postoji za sve 'vazne' podatke, kao sto je ziro racun, pa se mogucnost greske znatno smanjuje. A samim tim otpada i potreba za nekim mehanizmom za brzo ispravljanje gresaka (sto omogucava daje autonumber)

Ako imas vestacki kljuc, autonumber, naoko je lakse ispraviti odredjene greske, jer se onaj pravi kljuc (ziro-racun) i ne propagira nigde. To sve vazi iskljucivo za base cija je shema razgranata, izgleda kao drvo, bez zatvorenih petlji. Ako imas zatvorene konture na shemi baze, onda ti vestacki kljuc odmaze jer otvara veci prostor za greske, neke druge, mkoje se mnogo teze i mnogo kasnije otkrivaju. Vidi shemu koju sam dao na pocetku i problem mesanaja kancelarija.

Citat:
Ne mozes to bas tako plasticno gledati. Ja sam pravio kasu za restorane i kafane i recimo da sam taj niz artikala dok nije doslo do stampanja i placanja drzao samo u memoriji. Nisu to ogromni podaci, a lakse je manipulisati (dodavanje i brisanje stavki, promjena kolicine i sl) dok su u memoriji. Kad bih vrsljao po bazi, mislim da bih daleko vishe bazi napravio posla. To je moje misljenje na datu temu :)

E kad bi svaki developer radio tako savesno, ne bismo ni imali ovakve diskusije :-). Ako ti vec na front endu, u memoriji, procistis podatke, onda ti za ovaj slucaj i ne treba autonumber, jer mozes da sve cokolade grupises zajedno. To potvrdjuje moju teoriju da ako se potrudis mozes da izbegnes autonumber. Sto ti radis je jako dobra i pozeljna praksa, koja nazalost nije cesta. Najcesce, developer bi samo da insertuje podatke sa front enda, a da baza odradi sve ostalo. E, ali ih mrzi da bazu projektuju tako da baza odradi sve sto treba da odradi. Pa zavrse sa glupim front endom (dumb terminal) i bazom koja ne moze da obavi funkciju ocuvanaj integriteta podataka, jer je developer korsitio precice (cut corners) = mrzelo ga da promisli o kljucevima koje je zamenio identity vrednostima "jer je tako lakse".

Inace, prica o kasi u samousluzi preuzeta je iz knjige "An Introduction to Database Systems" by C.J. Date, a date je autoritet u ovoj oblasti, valjda jedini zivi koji je radio sa E.F Codd-om licno. U knjizi se problem opisuej kao 'cat food problem' - ja sam cat food zameni cokoladama.


Cela price se svodi na ovo: Nisu autonumber/identity zli sami po sebi. Mogu se korististi, i korisni su, ako se dobro promisli. Autonumbers nisu zamena za daat integrity. Probelm je sto vecina (ne svi, svaka cast) preskoci ovo 'dobro se promisli' i koristi autonumber kao laksi nacin da resi ozbiljan problem - integritet podataka - bez mnogo napora. Problem se samo zamaskira a ne resi se. A naoko sve izgleda bajno i sjajno. ispada da sve zavisi ko ih upotrebljava. neki ljudi znaju da ih upotreba, nazalost vecina ne zna.