Pitanje u vezi primarnih i spoljnih kljuceva...

Pozdrav svima,

Zeleo bih da postavim jedno ili vise pitanja :) konkretno okacio sam sliku da bih stvar bila jasnija. Naime pri prevodu u relacioni model, koji je manje
vise sablonski, kad sam prevodio ovaj model u relacioni, pitao sam se sto konkretno u agregaciji "polozio" se agregiraju 3 primarna kljuca,
posto isti posao mozemo da uradimo kada bih napravili spoljne kljuceve tj da svaki od tih kljuceva pokazuje na jedan entitet "student,profesor,predmet"
.Konkretno sama primena vise primarnih kljuceva me buni posto ne znam cemu svrha kada mozemo da upotrebimo spoljne kljuceve(foreign key)
za povezivanje entiteta, a da ti spoljni ukazuju na primarne u istim...Konkretno evo u agregaciji ili bilo kojom vezom vise prema vise posto se
u takvim vezama pravi nova relazija sa spoljnim kljucevima. Nadam se da ce iko razumeti moje pitanje :) Unapred Hvala...

A sad preformuliši i napiši razumljivo...

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Ako sam te dobro shvatio, evo primjer zašto:

Tablica:


Primjer podataka:

Potpis

F

Tabela Polozio treba da izgleda ovako:



Kolone StudentID, PredmetID i ProfesorID su ti spoljni kljucevi na tabele.
Ove tri kolone takodje grade primarni kljuc, ali to je primarni kljuc Polozio tabele a ne ovih stranih tabela.
Samo postojanje primarnog kljuca u tabeli Polozio nije neophodno ali je zgodno zbog
same prirode primarnog kljuca - ne dozvoljava duplikat (polozenog ispita).
Ne znam sta ti tu nije jasno i kako/zbog cega bi radio drugacije.

Pozdrav!

Ok, jasno mi sad svrha vise primarnih kljuceva. Ali sad prevod u relacioni bih bio ovakav:
Polozio(StudentID) references Student(StudentID)
Polozio(PredmetID) references Predmet(PredmetID)
Polozio(ProfesotID) references Profesor(ProfesorID)

Da li je ovako? Posto ako imamo ovako nesto:

Ovde mi sad sistem dozvoljava da napravim ovako nesto. Ali kako da napravim da jedan profesor samo moze da ukazuje na jedan predmet ili na dva ukoliko mozda neki od njih predaje dva :), posto ovde ispada da jedan profesor moze da predaje sve predmete, ovde sam imao 3 predmeta , ali sta ako ih imam 10, mogao bih da stavim da jedan profesor moze da predaje 10 predmeta, kako da napravim da u tabeli "Polozio" ne dozvolim da je ovako nesto moguce , posto mozes da pogresis pri kucanju i da stavis slucajno pogresan Id Predmeta ,Pogresan Id Profesora i da prodje kroz sistem. Kako da se prevazidje ovakav problem? :) Hvala Unapred svima koji pomognu!!!

U modelu koji si dao nema nikakve (dodatne) veze između profesora i predmeta koja bi označavala koje predmete profesor može da predaje.

Potpis

Owl

Ne radi se o 'vise primarnih kljuceva' nego se u tvom slucaju 'primarni kljuc sastoji od vise kolona' {StudentID, ProfesorID, PredmetId}.

Ima i situacija kad imas vise od jedne kombinacije kolona u tabeli takvih da svaka od njih moze biti primarni kljuc (jedinstveno odredjuje red u tabeli), ali ova tvoja situacija to nije. Evo primer tabele koja ima vise kljuceva (onda ih zovemo alternativni kljucevi). Imas recimo tabelu PeriodniSistemElemenata= {Naziv, RedniBroj, AtomskaTezina}. Svaka od tri kolone jdinstveno odredjuje redove u tabeli. I svaka moze da se proglasi da je primarni kljuc (PRIMARY KEY). Za druge dve koje nismo odabrali za PK, moramo da stavimo UNIQUE CONSTRAINT. PK je samo jedan, proizvoljno izabran kljuc iz skupa alternativnih kljuceva. Ako tabela ima samo jedan kjuc onda je to istovremeno i primarni kljuc. Ako ima vise kljuceva, onda je svejedno koji proglasimo primarnim, svi imaju istu logicku funkciju i podjednako su vazni. Vazna je osobina jedinstvenosti, nije vazno kakao zovemo kljuc.

Da se vratimo na tvoju tabelu,

POLOZIO= {StudentID, PredmetID, ProfesorID, Datum_isp, Ocena_pred}
Potrebno je da definises sledeca ogranicenja:

PRIMARY KEY = {StudentID, PredmetID, ProfesorID};
FK1 : Polozio(StudentID) references Student(StudentID);
FK2 : Polozio(PredmetID) references Predmet(PredmetID);
FK3 : Polozio(ProfesotID) references Profesor(ProfesorID);
CHECK : Ocena_pred>5;

Ovaj CHECK ce spreciti da se uense ocena 5 za studenta koji je polozio ispit, jer su prolazne ocene 6,7,8,9,10 ali ne i 5. Naoko sitnica, ali veoma vazna.

Inace, kad u tekstu definises tabelu treba da navedes 3 stvari:
1. Smisao tabele
2. Zaglavlje tabele
3. Ogranicenja

Ovako bi to bilo u tvom slucaju:
1. Smisao tabele: "Student [StudentID] je polozio ispit iz predmeta [PredmetId] kod profesora [ProfesorID] na dan [Datum_SIp] i dobio ocenu [Ocena_Pred]."

2. Zaglavlje tabele:
POLOZIO= {(StudentID, int) , (PredmetID, int), (ProfesorID, int), (Datum_isp, date), (Ocena_pred, int)}

3. Ogranicenja:
PRIMARY KEY = {StudentID, PredmetID, ProfesorID}
PRIMARY KEY = {StudentID, PredmetID, ProfesorID};
FK1 : Polozio(StudentID) references Student(StudentID);
FK2 : Polozio(PredmetID) references Predmet(PredmetID);
FK3 : Polozio(ProfesotID) references Profesor(ProfesorID);
CHECK : Ocena_pred>5;

Na ovaj nacin si svima koji treba da rede sa tabelom POLOZIO dao strasno mnogo korisnih informacija. Ovo opisivanje tabele definisanjem smisla, zaglavlja i ogranicenja treba da bude sastavni deo dokumntacije. Znaci, u dokumentaciju ide tvoj dijagram objekata i veza, i zatim za svaku tabelu kazes ove tri stvari. Svikoji budu nesto radili sa tvojm bazom bice ti beskrajno zahvalni.

@ Zidar
Dobar primer sa tabelom PeriodniSistemElemenata za alternativne ključeve. Dodao bih još pored punog naziva elementa i Simbol.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Da to je sve ok, tabela polozio je agregacija tj u agregaciji imamo sifru studentid,predmetid i profesorid.
Ali sta ako napisemo ovako:



E ovde je problem sto u tabeli Polozio imamo da je student pod sifrom 1 polozio predmet pod sifrom 1 kod porfesora pod sifrom 1
datuma 01.01.2014 sa ocenom 8. A sad dole istog studenta, polozio predmet 1 kod drugog profesora 2 istog dana sa ocenom 10
znaci ukoliko je u tabeli
POLOZIO= {(StudentID, int) , (PredmetID, int), (ProfesorID, int), (Datum_isp, date), (Ocena_pred, int)}
PRIMARY KEY = {StudentID, PredmetID, ProfesorID}
Onda mozemo da uradimo ovako nesto kao sto je gore prikazano, zato sto nam je PK= {StudentID, PredmetID, ProfesorID} i konbinaciom kolona dobijamo potpuno novi PK. Sad u realnosti ovo je prakticno nemoguce. Ako bih mogao neko da objasni detaljno ovo...

I samo da pitam kako bih napravili relaciju od kardinalnosti (1,1) <-> (1,1) posto nigde nisam video da je neko pravio relaciju sa
ovom kardinalnoscu. Obicno je to (0,1)<->(1,1)


Izvinjavam se malo kasnim sa porukom imao sam dosta obaveza pa nisam stizao
Unapred hvala...

Ako je realnost takva da je nemoguce da jedn student polaze isti ispit kod dva profesora, onda tvoje relacije treba tu realnost verno da predstave.
Mislim da ti nedostaje nekoliko relacija:

Predikat Profesor [SifraProf] predaje predmet [SifraPred] ima relaciju definisanu ovako;
ProfesorPredmet:{SifraProf, SifraPred}, PK :{SifraProf, SifraPred},
Relacija ProfesorPredmet dozvoljavaa vise profesora predaje isti predmet.

Student slusa jedna predmet kod tacno jednog profesora (realnost o kojoj pricamo). Predikat bi bio:
Student [SifraStud] slusa predmet [SifraPred] kod profesora [SifraProf] , sto daje relaciju:
StudentSlusaPredmete = {SifraStud, SifraProf, SIfraPred},
PRIMARY KEY {SifraStud, SifraPred} -> svaki ispit student slusa tacno jednom
FOREIGN KEY (SifraProf, SifraPred) REFERENCES ProfesorPredmet(SifraProf, SifraPred) -> ispist slusa samo kod onog profesora koji taj ispit i predaje (vise profesora moze da predjae isti ispit, ali je samo jedan od njih dodeljen nasem studentu)


Ako hoces da kazes "Student moze da polozi ispit tacno jednom" onda brises profesora iz relacije Polozio, ovako:
POLOZIO= {(StudentID, int) , (PredmetID, int), (Datum_isp, date), (Ocena_pred, int)}
PRIMARY KEY = {StudentID, PredmetID}
FOREIGN KEY (StudentID, PredmetID) REFERENCES StudentSlusaPredmete (SifraStud, SIfraPred)

Na osnovu relacije POLOZIO znamo da je student polozio ispit [SifraIsp]. Iz relacije "StudentSlusaPredmete " znamo da predmet [SIfraPred] studentu predaje profesor [SifraProf], posto student slusa (i polaze) ispit samo kod jednog profesora.




Malo si nezgrapno napisao kardinalnosti. Pise se
1 : (0,1) = jedan prema nula ili jedan (postoji u tabeli "roditelj" ali ne mora da psotoji u tabeli "dete"
1 : 1 jedan prema jedan

1:1 imas na primer ako imas relacije
Radnici: { [SifarRadnika],[Ime],[Prezime],[DatumRodjanja]} PK (SifraRadnika)
i
Plate { [SifarRadnika], [Plata]} PK (SifraRadnika)

1:1 je logicki uslov. Fizicki, danasnji RDBM sistemi ne pruzaju mogucnost da se to izvede. Radnik prvo mora da postoji u tabeli Radnici, pa mu se onda dodeljuje plata. Ako je uslov da ne sme da bude ni jedan radnik u tabeli Radnici koji nema platu, onda se mogu spojiti relacije Radnici i Plate, ovako:
Radnici: { [SifarRadnika],[Ime],[Prezime],[DatumRodjanja],[Plata]}

Medjutim, razlog za razdvajanje relacija jest poverljivost podataka - ne zelimo da svi koji imaju pravo d avide tabelu Radnici vide i njihove plate. U praksi se obicno razdvoje tabele, aonda se zabrani pisanje (INSERT) direktno u tabelu Radnici. Zatim se napravi stored procedure kojoj se posalju parametri (@SifarRadnika,@Ime,@Prezime,@DatumRodjanja,@Plata} pa procedura odradi u jednoj transakciji

BEGIN TRANSACTION
INSERT INTO Radnici (@SifarRadnika,@Ime,@Prezime,@DatumRodjanja
ISERT INTO Plate (@SifarRadnika, @Plata)
COMMIT

Naravno da onaj ko treba da unosi podatke u tabele dobije pravo da izvrsava stored procedure.

Druga opcija je da se cuva plata u tabeli radnici, i da se svima zabrani citanje iz te tabele. Onda se naprave views, jedan koji pokazuje plate, drugi koji ne pokazuje, pa se daju permissions na views onima koji smeju da vide jedno ili drugo.

Prijatelju, prvo da ti se zahvalim na odgovorima, vidi se da zelis da pomognes i na tome ti hvala!!!
Ako treba sta da se plati nije problem

Samo da se vratim na ovaj primer...

Ovde su PK ujedno i FK posto referenciraju na profesora i na predmet jel tako?




Da li ovde SifraStud ujedno i FK posto mi deluje da nije povezan s tabelom student jel sam u pravu ili gresim?



A sad sve sam ovo stavio na papir i povezao na kraju opet slican problem



Unapred svima hvala koji izdvoje svoje dragoceno vreme i pomognu!!!

Pitanje:


Odgovor:
Ovako smo definisali relaciju StudentSlusaPredmete:

Primeti FOREIGN KEY. FK ne dozvoljava da se studentu dodeli kombinacija (SifraProf, SifraPred) koja ne postoji u relaciji ProfesorPredmet.
Stoga nije moguce da bilo kom studentu dodelis kombinaciju Profesor = 3 Predmet = 2 ako takva kombinacija ne postoji u relaciji ProfesorPredmet. Znaci, FK sprecava da dodje do 'mesanja podataka'

Poslovno pravilo, tvrdnja ili iskaz: "svaki ispit student slusa tacno jednom", važi za dobre studente. U Evropi je mahom zastupljena Bolonjska deklaracija. Insistira se na nekoj vrsti aktivnosti u nastavi kroz prikupljanje predispitnih obaveza. Ukoliko student ne položi ispit (pet ispitnih rokova u školskoj godini), obavezan je dogodine da ponovo sluša isti predmet.

Znači, PK je suviše krut i ne odgovara realnosti. Trebalo bi uvesti atribut "SkolskaGodina". Druga stvar je ako je ovo samo teoretski primer.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski