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

Primarni i spoljni kljucevi ?

[es] :: Baze podataka :: Primarni i spoljni kljucevi ?

[ Pregleda: 4441 | Odgovora: 15 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Serbiankum
Srbija

Član broj: 54947
Poruke: 240
*.adsl-a-1.sezampro.yu.

Sajt: www.drvoumomdvoristu.com


Profil

icon Primarni i spoljni kljucevi ?04.01.2009. u 18:08 - pre 138 meseci
Kada se pravi baza, tacnije kada se projektuju tabele, i kada u nekoj tabeli odredimo primarni kljuc, i kada tu tabelu spajamo sa nekom drugom tabelom, kada ce biti primarni a kada preneseni (FK) kljuc u toj drugoj tabeli? Na kom logickom nivou se to reseva?
 
Odgovor na temu

Getsbi

Član broj: 124608
Poruke: 2733



+33 Profil

icon Re: Primarni i spoljni kljucevi ?04.01.2009. u 20:28 - pre 138 meseci
Kad je entitet “dete” identifikaciono zavistan od entiteta “roditelj” (jaka veza), PK “roditelja” prelazi u ključne atribute entiteta „dete“. (slučaj Dokument----->DokumentStavka, identifikujuća veza)

Kad je entitet „dete“ identifikaciono nezavistan od entiteta „roditelj“ (slaba veza) onda PK „roditelja“ prelazi u neključne atribute entiteta „dete“. (slučaj JedinicaMere------->DokumentStavka, neidentifikujuća veza)
To se dešava na jednom jedinom logičkom nivou i zavisi od razumevanja poslovnog problema. Slika će ti reći više nego da bilo šta napišem.




 
Odgovor na temu

Serbiankum
Srbija

Član broj: 54947
Poruke: 240
*.adsl-a-1.sezampro.yu.

Sajt: www.drvoumomdvoristu.com


Profil

icon Re: Primarni i spoljni kljucevi ?04.01.2009. u 23:37 - pre 138 meseci
Evo jedan jednostavan primer ordinacije. Postoje sifarnici doktor i pacijent. I postoje Pregledi ili nalazi. Tu bi trebao da se pise izvestaj o pregledu. E sad da li ovi sifarnici (pacijent i doktor) postoju primarni kljucevi u ovoj tabeli nalazi(slika 1) ili postaju preneseni(slika 2) ili ima neko drugo resenje. Sta je ispravnije i zasto?

Znaci kako kad se projektuju baze znati kada primarni kljuc jedne tabele postaje primarni kljuc druge, ili preneseni kljuc u toj drugoj tabeli?





 
Odgovor na temu

kime1
Srbija

Član broj: 13275
Poruke: 939
212.200.65.*



+2 Profil

icon Re: Primarni i spoljni kljucevi ?05.01.2009. u 00:35 - pre 138 meseci
mislim da u ovom slučaju moraš uvesti novu šifru, jer ti šifra doktora i pacijenta ne fiksira neki jedinstveni pregled, tj. može ih biti više za istog pacijenta i istog doktora... kada bi morao biti samo jedan pregled, onda bi uzeo oba fk kao pk, ili samo jedan u nekim slučajevima... moraš sam da uvidiš odnose među entitetima, ne postoji algoritam za svaki slučaj kako se radi...
 
Odgovor na temu

Getsbi

Član broj: 124608
Poruke: 2733



+33 Profil

icon Re: Primarni i spoljni kljucevi ?05.01.2009. u 07:22 - pre 138 meseci


Kao što sam već napisao u prvom odgovoru, zavisi od razumevanja poslovnog problema. Poslovna pravila su ta koja će te dovesti do rešenja. Ne postoje nikakvi standardi, propisi ili slično. Svaki poslovni problem je slučaj za sebe.

Kime1 je lepo primetio suštinu. I u jednom i u drugom slučaju ti treba još jedan atribut PregledID.

Na prvoj slici, novi atribut bi se našao u delu primarnih ključeva odmah ispod SifraPacijenta(FK) i SifraDoktora(FK). Ta bi veza bila dosta utegnuta i govorila bi da ni jedan pregled ne može biti identifikovan ukoliko se ne znaju sva tri dela složenog ključa. Ovo je varijanta nasleđivanja primarnih ključeva. Tvrđa je i nešto teža za realizaciju prilikom aplikativnog modeliranja.

Na drugoj slici, valjalo bi samo dodati atribut PregledID u ključne atribute i ostvariti takozvanu mekšu varijantu. Primarni ključevi se ne nasleđuju, već prenose u neključne atribute. Lakše je za realizaciju. S tim što treba voditi računa da ne može ostati ovako kako si ti naveo IE otacijom Nulls Allowed (dozvoljeni Null podaci). Kakav bi to pregled bio ako može da se unese zapis, a da se nezna PacijentID i DoktorID. Znači treba ti obavezna neidentifikujuća veza.

Tako bi imao dva rešenja. Nemoj da te zbunjuje što postoje više ispravnih rešenja. Ti odlučuješ koju ćeš varijantu da primeniš. Dakle nema zakucanih pravila. Jedan deo toga zavisi od načina na koji projektant i analitačr problema tumače poslovno okruženje. Sve se rešava kroz intervju projektanta i specijaliste za poslovni problem. U tvom slučaju specijalista je neka medicinska sesta koja vodi evidenciju pregleda u lekarskoj ambulanti.

 
Odgovor na temu

Serbiankum
Srbija

Član broj: 54947
Poruke: 240
*.adsl-a-1.sezampro.yu.

Sajt: www.drvoumomdvoristu.com


Profil

icon Re: Primarni i spoljni kljucevi ?05.01.2009. u 22:13 - pre 138 meseci
Znaci i prvi primer i drugi primer su dobri?
Samo sto kod drugog primera treba staviti Not Nulls.

Pitanje za prvi primer sa dokumentima i stavkama dokumenata. DokumentID je primarni kljuc i u drugoj tabeli. Da li moze DokumentID da bude neidentifikujuca veza, sa opcijom not nulls?

 
Odgovor na temu

Getsbi

Član broj: 124608
Poruke: 2733



+33 Profil

icon Re: Primarni i spoljni kljucevi ?06.01.2009. u 07:04 - pre 138 meseci
Citat:
Serbiankum: .......Pitanje za prvi primer sa dokumentima i stavkama dokumenata. DokumentID je primarni kljuc i u drugoj tabeli. Da li moze DokumentID da bude neidentifikujuca veza, sa opcijom not nulls?



Da bi dobio odgovor, postavi sebi pitanje:
Da li može stavka dokumenta da se identifikuje bez znanja o broju dokumenta?
Zamisli da si odsekao više dokumenata na onaj deo gde je zaglavlje i onaj gde su stavke. Kad promešaš tako isečene dokumente, hoćeš li znati da ih sastaviš? Verovatno nećeš. Trebalo bi da u delu gde su ostale stavke, ispred svakog rednog broja stavke imaš i broj dokumenta. Recimo ovako:


136.......1
136.......2
136.......3

137.......1
137.......2
.
.
Tada bi mogle stavke da se identifikuju.

Stavke su takozvani slab entitet. Zasebno ne mogu da obitavaju. Potrebna im je jaka veza (identifikujuća). Otuda DokumentID u mom primeru ne može da bude u tabeli DokumentStavka u neključnim atributima i veza ne može da bude neidentifikujuća (ni obavezna ni neobavezna).

Suprotna situacija je sa vezom JedinicaMere------->DokumentStavka. Stavka može da se identifikuje bez znanja o jedinici mere. Odluku da li obavezna ili neobavezna veza donosiš na osnovu toga da li može da postoji zapis stavke bez ukucane jedinice mere. Identifikaciona i egzistencijalna zavisnost je nešto što ćeš naučiti u teoriji relacionih baza. Pitanja: Da li može da postoji (egzistira) i da li možeda se identifikuje treba da razumeš i primeniš.


Slična analogija važi i za tvoju odluku oko Pregleda. Slučaj prvi ili Slučaj drugi? Odluku treba da doneseš uz kaficu sa "sestricom", analizirajući trenutnu papirnu evidenciju lekarske ordinacije za čije potrebe projektuješ model podataka.
 
Odgovor na temu

Serbiankum
Srbija

Član broj: 54947
Poruke: 240
*.adsl-a-1.sezampro.yu.

Sajt: www.drvoumomdvoristu.com


Profil

icon Re: Primarni i spoljni kljucevi ?06.01.2009. u 22:08 - pre 138 meseci
Primer za ordinaciju radim za sebe kao vezba, znaci ne pravim program komercijalno.

Vezano za te preglede, zar nije "logicno" da pregled cini pacijent i doktor? Znaci po logici, pregled je zavistan od pacijenta i doktora, jer to cini pregled. Da li bi po tome SifraPacijenta i SifraDoktora bili primarni kljucevi u tabeli pregledi?

 
Odgovor na temu

kime1
Srbija

Član broj: 13275
Poruke: 939
212.200.65.*



+2 Profil

icon Re: Primarni i spoljni kljucevi ?06.01.2009. u 22:23 - pre 138 meseci
a šta ćeš ako ti pacijent više puta poseti istog doktora, PK po definiciji mora da izdvoji jedan element, a ne više njih?

Imaš varijantu da preglede brojiš počev od 1 za svakog doktor-pacijenta (u kom slučaju bi bili deo primarnog ključa), ili da brojiš sve preglede, nevezano za doktore i pacijente, što je mislim praktičnije, i u tom slučaju ti je samo to PK...
 
Odgovor na temu

Crtani
Dejan Savic
Beograd

Član broj: 95930
Poruke: 46
*.ADSL.neobee.net.

Sajt: www.klikeri.net


Profil

icon Re: Primarni i spoljni kljucevi ?22.01.2009. u 23:22 - pre 138 meseci
Citat:
Serbiankum
Vezano za te preglede, zar nije "logicno" da pregled cini pacijent i doktor? Znaci po logici, pregled je zavistan od pacijenta i doktora, jer to cini pregled. Da li bi po tome SifraPacijenta i SifraDoktora bili primarni kljucevi u tabeli pregledi?


Osim pacijenta i lekara, jedan pregled cini i, najprostije receno, vreme kada je pacijent bio kod lekara.


Da resimo sve dileme:

1) Ako zelis da evidentiras Preglede tj. dinamiku/istoriju (recimo, Pera je 22. januara posetio Doktora Ziku)
onda kombinacija pacijent+lekar ne treba da bude jedinstvena (jer ce Pera doci ponovo na pregled kod Doktora Zike 29.januara, na kontrolu)
U tom slucaju (kao i u velikoj vecini drugih situacija) najbolje koristiti vestacki primarni kljuc, recimo PregledID.
Tu nema nikakve dileme.

2) Ako tabela pregledi treba samo da pokaze ODNOS ko je ciji lekar (dakle, da prikazemo stanje stvari, odnose, strukturu, a ne dinamiku), onda stvar posmatras ovako:
Posto jedan doktor ima vise pacijenata, a svaki pacijent bira jednog doktora (odnos je 1:N) onda ti ne treba treca tabela, nego samo strani kljuc SifraDoktora u tabeli Pacijenti.

PACIJENTI
----------
SifraPacijenta (PK)
Ime
...
Doktor (FK) ----> Doktori.SifraDoktora

2a) Eventualno, ako mislis da je ovaj odnos slozeniji, i da u jednom trenutku pacijent moze da ima vise svojih doktora, onda je odnos N:N, i onda ti treba treca tabela (ali tu tabelu ne treba nazvati Pregledi, nego npr. KoJeCijiLekar) i u njoj je kombinacija lekar+pacijent jedinstvena, pa treba bas takav primarni kljuc staviti: SifraPacijenta+SifraDoktora). Medjutim, ako je ovo slucaj, onda to u prevodu verovatno znaci da pacijent moze da ide kod bilo kog doktora, pa se ne bih ni trudio da evidentiram KoJeCijiLekar.

Zakljucak: mala je sansa da ce primarni kljuc SifraPacijenta+SifraLekara imati smisla.


Da produbim temu:
Ako si zainteresovan mozemo da pricamo i o modelu koji kombinuje oba slucaja.
Zelimo da zapisemo samo to da je Pera 22. januara dosao na pregled. Kod kog lekara? Pa, kod SVOG lekara, to je vec opisano stanjem.
Korisnik ce nam biti zahvalan sto je dovoljno da samo jednom upise da je Zika Perin lekar, a ne svaki put.

Medjutim, sta ako je Pera menajo lekare, mozemo li u ovakvom modelu saznati koji su ga sve lekari pregledali? To je vec nova tema...




 
Odgovor na temu

IIacaII
FTN
Srem

Član broj: 227602
Poruke: 55
*.ADSL.neobee.net.

Sajt: rentijer.com


+3 Profil

icon Re: Primarni i spoljni kljucevi ?08.07.2009. u 20:27 - pre 132 meseci
Treba da napravim bazu u kojoj će se evidentirati sve kao i u školskom dnevniku: učenici, predmeti, ocene. Interesuje me da li je bolje da primarni ključ bude na matičnom broju ili nekom običnom ID i zašto uglavnom svugde ime i prezime ide u odvojenim poljima kad se meni čini da bi bilo lakše da ide u jednom polju ?
 
Odgovor na temu

Crtani
Dejan Savic
Beograd

Član broj: 95930
Poruke: 46
*.ADSL.neobee.net.

Sajt: www.klikeri.net


Profil

icon Re: Primarni i spoljni kljucevi ?08.07.2009. u 20:50 - pre 132 meseci
Citat:
IIacaII: Treba da napravim bazu u kojoj će se evidentirati sve kao i u školskom dnevniku: učenici, predmeti, ocene. Interesuje me da li je bolje da primarni ključ bude na matičnom broju ili nekom običnom ID i zašto uglavnom svugde ime i prezime ide u odvojenim poljima kad se meni čini da bi bilo lakše da ide u jednom polju ?


JMBG ne smeš da koristiš kao primarni ključ zato što, veruj mi - doživeo sam, ima đaka koji nemaju JMBG. Ili koji nisu sa ovog područja, pa im je ta identifikacija drugačija. A još realniji problem je to što u trenutku unosa podataka JMBG često nije dostupan, i onda bi to sabotiralo unos celog sloga.

Ime i Prezime se vode odvojeno zato što ih je lakše sastaviti nego rastaviti, ako ništa drugo.
A evo još razloga: u nekim dokumentima će ti trebati da piše samo Ime i Prezima, a u nekim drugim Ime, Ime roditelja, Prezime. Negde prvo ime, a negde prvo prezime.

 
Odgovor na temu

IIacaII
FTN
Srem

Član broj: 227602
Poruke: 55
*.ADSL.neobee.net.

Sajt: rentijer.com


+3 Profil

icon Re: Primarni i spoljni kljucevi ?08.07.2009. u 20:58 - pre 132 meseci
Ok.Hvala. Ostaviću samo polje za JMBG kao neobavezan unos podatka.
 
Odgovor na temu

Crtani
Dejan Savic
Beograd

Član broj: 95930
Poruke: 46
*.ADSL.neobee.net.

Sajt: www.klikeri.net


Profil

icon Re: Primarni i spoljni kljucevi ?08.07.2009. u 21:09 - pre 132 meseci
Citat:
IIacaII: Ok.Hvala. Ostaviću samo polje za JMBG kao neobavezan unos podatka.


E da, možeš da stavis Indeks na JMBG (no duplicates) što će obezbediti prirodnu jedinstvenost svakog sloga, jer ti veštački primarni ključ uvek slepo garantuje jedinstvenost, pa makar sva druga polja bila ista.



 
Odgovor na temu

Tudfa
Jovicevic Vladimir

Član broj: 152699
Poruke: 384
*.dynamic.sbb.rs.



+3 Profil

icon Re: Primarni i spoljni kljucevi ?08.07.2009. u 21:14 - pre 132 meseci
I ja sam za korišćenje surogata tj. ID kolone kao primarnog ključa, a nad JMBG se moze postaviti UNIQUE ograničenje u svakom slučaju.
Ne bih da sad sitničarim ono u vezi integer vs char/varchar za PK, pa i kad bi to zanemarili, uvek bih radije koristio ID nego JMBG.
Citat:
IIacaII:  i zašto uglavnom svugde ime i prezime ide u odvojenim poljima kad se meni čini da bi bilo lakše da ide u jednom polju ?

Na prvi pogled deluje lakše, ali te ustvari ograničava i uvodi dodatno komplikovanje,recimo kod pretrage(traženje samo po imenu ili samo po prezimenu) itd...
 
Odgovor na temu

misk0
.: Lugano :. _.: CH :.

SuperModerator
Član broj: 634
Poruke: 2824
*.adsl.ticino.com.

ICQ: 46802502


+49 Profil

icon Re: Primarni i spoljni kljucevi ?08.07.2009. u 22:01 - pre 132 meseci
Ne morate ovo uzeti kao referencu ali...
Ljudima se desavalo da imaju duple maticne brojeve. Zasto? Zato sto se maticni brojevi izdaju vec dugo godina kad nisu postojali racunari, kad nije bilo 'veza' izmedju maticnih ureda, kad je samo jedna osoba radila svu tu evidenciju (mozda i dan danas ima takvih mjesta, ne znam trenutno stanje) i slicno.
Ja bih iz tog razloga dozvolio da maticni broj bude dupli, ako je vec neobavezan. Buduci da radis sa djecom (djaci) mala je vjerovatnoca da ce to da ti se desi ali nije nemoguce. Ako je rijec o teorijskom poslu - zadatak na faxu onda mozes i staviti UNIQUE, ako je software koji ce biti u upotrebi - ne bih preporucio.

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::
 
Odgovor na temu

[es] :: Baze podataka :: Primarni i spoljni kljucevi ?

[ Pregleda: 4441 | Odgovora: 15 ] > FB > Twit

Postavi temu Odgovori

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