Trecu tabelu treba da razbijes na tri tabele:
1) Trening (Lokacija, Datum, Vreme)
PRIMARY KEY (Lokacija, Datum, Vreme)
- 1 rekord po treningu

2) IgraciNaTreningu (Lokacija, Datum, Vreme,id_igraca)
- PK (Lokacija, Datum, Vreme,id_igraca) - jeste, sve cetiri kolone
- FK (Lokacija, Datum, Vreme) REF Trening (Lokacija, Datum, Vreme)
- N rekorda po treningu, po jedan za svakog prisutnog igraca

3) TreneriNATrening (Lokacija, Datum, Vreme,id_igraca, TrenerID)
- PK (Lokacija, Datum, Vreme, TrenerID) - jeste, sve cetiri kolone
- FK (Lokacija, Datum, Vreme) REF Trening (Lokacija, Datum, Vreme)
- N rekorda po treningu, po jedan za svakog trenera koji je na treningu

Za tabelu Trening treba ti jednostavna forma, unosi se jedan rekord po treningu. Za druge dve tabele, lako ces napraviti subforme koje se vezuju za formu frmTrening, vezuju se po poljima (ime, prezime, telefon), jer je to primarni kljuc tabele roditelj. Ako je tvoja baza pamaetna makar kao Access, onda se ovaj PK prenosi u subforme automatski, ne moras da kucas iste podatke (I izgubio si redundansu koju si imao )

Predpostavljam da ces da se bunis zbog PK sa tri ili cetiri kolone. Ako ti se ne dopada, uvek mozes da uvedes nekakav TreningID u tabeli Trening pa da to prenosis u druge dve tabele, a tamo da ti kljuc bude (TreningID, IgracID) i (TreningID, TrenerID), da bi svaki igrac bio na treningu ne vise od jednog puta.

Ja licno ne bih uvodio TreningID, ali to je duga prica, koja na kraju te mozda i ne ubedi, pa da to preskocimo u ovom slucaju.

Srecan rad

Zidar hvala na iscrpnom odgovoru.
Da li sam te dobro razumeo?

Ako između igrača i trenera u podacima nema neke suštinske razlike, ja bih ih držao sve u jednoj tabeli samo bih dodao identifikator da li se radi o igraču ili treneru.

Mislim da ima. Ako ništa drugo tabela u kojoj su podatci vezani za igrača treba da sadrži znatno više ličnih podataka, dok je tabela Trener možda i suvišna.

Ako su Treneri i Igraci u razlicitim tabelema, onda je ova slika sasvim OK. Ako bi stavili trenere koji vode trening i igrace prisutne na treningu u istu tabelu, ne bismo mogli da postavimo vezu izmedju te zajednicke tabele i zasebnih tabela Treneri i Igraci.

A verujem da je shema dobra u svakom slucaju jer su logicki predikati za relacije TreneriNaTrening i IgraciNaTrening potpuno razlicite, ovako:

Predikat TreneriNaTreningu = "Trener [TrenerID] vodio je trening na lokaciji [LokacijaID] dana [Datum] u [Vreme] sati"
Predikat IgraciNaTreningu = "Igrac [IgracID] bio je treningu na lokaciji [LokacijaID] dana [Datum] u [Vreme] sati"

Tabele za oba predikata svakako da izgledaju isto, ali tabele nisu isto sto i relacije. Relacije se predstavljaju tabelama, i to samo priblizno. Relacija je skup logickih iskaza koji se svi izvode iz istog predikata. Posto ovde imamo dva razlicita logicka predikata, onda cemo imati dve razlicite relacije. To sto tabele koje predstavljaju relacije mogu da izgledaju isto, ne znaci nista.

Zamenom realnih vrednosti u parametre logickog predikata relacije (atributi relacije, kolone tabele), dobijamo skup logickih iskaza (smatramo da su tacni iskazi)

Primeri propozicija:

TreneriNaTreningu
---------------------
Trener [1250-17] vodio je trening na lokaciji [Pomocni teren] dana [11 Septembra 2001] u [11] sati.
Trener [3333-17] vodio je trening na lokaciji [Pomocni teren] dana [12 Septembra 2014] u [11] sati.
Trener [4444-17] vodio je trening na lokaciji [Glavni teren] dana [11 Septembra 2015] u [11] sati.
Trener [1250-17] vodio je trening na lokaciji [Glavni teren] dana [12 Septembra 2001] u [10] sati.

IgraciNaTeningu
-------------------
Igrac [1001] bio je na treningu na lokaciji [Pomocni teren] dana [11 Septembra 2001] u [11] sati.
Igrac [1001] bio je na treningu na lokaciji [Pomocni teren] dana [12 Septembra 2014] u [11] sati.
Igrac [2003] bio je na treningu na lokaciji [Glavni teren] dana [11 Septembra 2015] u [11] sati.
Igrac [4444] bio je na treningu na lokaciji [Glavni teren] dana [12 Septembra 2001] u [10] sati.

Sta je onda tabela? Tabe je skup 'redova' od kojih svaki predstavlja neki iskaz koji se izvodi iz predikata relacije, a dobijate je tako sto iz izkaza izbacimo opisne reci i ostavimo samo vrednosti parametara, i na vrh tabele dopisemo zaglavlje (nazive parametara). Ako napravimo fizicke tabele od posmatranih skupova propozicija, one ce izgledati veoma slicno. Da smo i za trenere i za igrace koristili atribut nazvan ID, onda ne bismo mogli da odredimo sta koja tabela predstavlja. Naravoucenije: cak i ako dve tabele izgledaju isto, ne znaci da one predstavljaju istu relaciju, prema tome one nisu iste, pa se ne mogu ni spojiti na predlozen nacin. Iz ovoga sledi da se gledanjem u tabelu ne moze bas mnogo reci o tome sta ona predstavlja. Potrebno je uvek iskazati logicki predikat za relaciju koju data tabela predstavlje. Tacno je da su i igraci i treneri bili na nekom treningu zajedno, ali u razlicitim ulogama.

Mnogo price za prostu stvar .....

Naravno da, kada sam sugerisao da igraci i treneti mogu biti u jednoj tabeli to menja celu strukturu baze i po mom misljenju pojednostavljuje je i daje vise mogucnosti.

Glavni problem koji ja vidim u odvanaju trenera i igraca je sto se tako, ako se desi (a desava se cesto) da jenda osoba moye da bude i igrac i trener na razlicitim treninzima, morala bi se ta osoba upisati dva puta, jednom u tabelu igraca a drugi put u tabelu trenera sto je ocigledna nepotrebna redudansa.

Dakle tabela sportisti bi po mom predlogu bila:

id_sportiste
ime
prezime


tabela treninzi bi bila

id_treninga
vreme_pocetka
vreme_zavrsetka


I sada bi sve moglo da se poveze samo jednom tabelom prisustva:

id_prisustva
id_treninga
id_sportiste
svojstvo (igrac, trener)

Veze su, mislim, ocigledne:
prisustva.id_treninga -> treninzi->id_treninga
prisustva.id_sportiste -> sportisti.id_sportiste

u polje prisustva.svojstvo se upisuje da li je osoba prisutna u svojstvu igraca ili trenera


Na ovaj nacin je omoguceno:
- sva lica se nalaze u jednoj tabeli pa je lakse odrzavanje
- jedno lice moze na nekom teningu biti u jednom svojstvu a na drugom u drugom svojstvu



Međutim, ja bih iz iskustva ceo model proširio uvođenjem entiteta grupa koji bi predstavljao skup lica koja čine grupu koja ucestvuje na treningu ukljucujuci i svojstva u toj grupi (trener/igrac). To bi predstavljalo poboljsanje u smislu da se samo jednom definisu svojstva lica u grupi a prilikom evidencija prisustva na treningu se samo evidentira koaj lica su prisustvoala, bez potrebe da se svaki put evidentira i svojstvo, jer je svojstvo tada definisano u grupi i sa mogućnošću da se može u korisnickom intrfejsu prikazati izbor samo onih lica koja treba/mogu da prisustvuju datom treningu, jer pripadaju datoj grupi, što može itekako da korsiti ako se adi o većem broju lica, grupa i treninga.

Uh vas dvojica ste to baš malo zakomplikovali. Trebaće meni vremena da to sve odmrsim u svojoj glavi.