Teorija vs. praksa - modeliranje lige u nekom sportu

[Quote]Delalt je mislio na rešavanje problema kad u istom kolu staviš u jednoj utakmici da igraju Tim1 - Tim2, a u drugoj Tim2 - Tim1.[/quote]
U pravu set 100%. Ovoga se nisam setio. Odlicna observacija konsultanta
U modelu koji je predlozio Chachka dakel mozemo da obezbedimo sledece:
1. ni jedan tim ne moze da bude domacin vise od jednom u jednom kolu (UNIQUE constraint UC1)
2. ni jedan tim ne moze da bude gost vsie od jednom u jednom kolu (UNIQUE constraint UC2)
3. tim ne moze da igra protiv samog sebe (CHECK)
Sta ne mozemo da pokrijemo - isti tim moze u istom kolu da bude jednom gost a jednom domacin. Gresim, nije tacno da ne mozemo, mozemo, ako je baza koju koristimo prati SQL standard. Delalt je tacno (verujem) napisao kako se to izvodi, a Chachka je odlicno primetio da to moze samo u dve baze, a ne moze recimo u ORACLE ili SQL, ne na taj nacin. Valjda bi trigger morao da se pise, da to obezbedi.

Ako bismo malo drugacije modelovali utakmice i timove, i problem "jedan tim gost/domacin u istom kolu" bi mogao da se resi. Pitanje je samo da li je to vredno truda i problema koje donosi. Ako pazljivo pogledamo tabelu Utakmice, u svim ponudjenim modelima imamo Domacin, Gost kolone. Formalno, to je narusavanje 2NF mislim. Svaka utakmica 'ima' dva tima. Ako ih ziovenmo Tim1 i Tim2 onda se lakse vidi da narusavamo 2NF. To je isto kao kad bi stavili u fakturi kolone Proizvod1, proizvod2, proizvod3...ProizvodN. Zbog tog narusavanja 2NF imamo dav UNIQUE constraints i CHECK i problem da pokrijemo zahtev "jedan tim ne sme biti gost i domacin u istom kolu". Ako bi timovi bili u dodatnoj tabeli TimoviKojiIgarjuUtakmicu, bilo bi Utakmica : TimoviKojiIgarjuUtakmicu= 1 : 2. Jedan jedini UNIQUE Constraint na tabeli TimoviKojiIgarjuUtakmicu bi obezbedio da
- svaki tim u jednom kolu se pojavljuje ne vise od jednom => ne moze biti Tim1 i Tim 2 istovremeno. Takodje sledi da se ne moze pojaviti dva puta u istom kolu i sledi da ne moze da igra protiv samog sebe, jer svi ovi uslovi narusavaju jedan te isti UNIQUE constraint. Ja ipak ne preporucujem ovaj nacin, jer se ni u jednom SQL sistemu, ni po standardu ne moze obezbediti trazeni kardinalitet. Mozete nekako (triggeri?) da obezbedite da utakmica nema vise od dva tima u tabeli TimoviKojiIgarjuUtakmicu, ali ne mozete da garantujete da ce uvek biti bas dva. Mozete da sprecite da se obrise jedan od dva tima, ali na INSERT idu jedn po jedan. Sta ako prvi ISNERT prodje, a drugi ne? Reci cete - resenje je stored procedure, ali ko ce da mnatera programera da koristi store procedure. Stored procedure su ekvivalentne resenju na front endu. Znaci, teorijski, kardinalnost se ne moze ili se jako tesko obezbedjuje bez oslanjanja na front end.

Ja u praksi koristim model koji je dao Chachka, a uslov da se jedan tim ne moze pojaviti u jednom kolu vise od jednom, bilo kao gost ili domacin obezbedjujem algoritmom za kombinovanje timova, koji za svako kolo uzima svaki tim tacno po jednom. Znaci, opet se oslanjam na front end. ne kazem da se ne treba oslanjati na front end, samo kazem da se ponekad bez front enda ne moze.

Kad budete izracunavali tabelu iz tabele Utakmice koja ima kolone Domacin i Gost, opet ce vas udariti po glavi narusavanje 2NF, keviriji ce bit prilicno zakukuljeni. Ipak, te cete kverije napisati jednom u zivotu i gotovo. Ostali stvari koje ce doci kad se bude pravio front end - prezentacija podataka korisniku, unos, editovanje su monog, ali mnogo, laksi ako se prihvati ovakva nepotpuna normalizacija. bar je meni bilo mnogo lakse.

Medjutim, kad dodje do zapsivanja kazni, opet problemi. Kako cete da zpiste kazne za igrace koje su zaradili na jednoj utakmici, za oba tima? Zamislajmo neki FK sa tabele Utakmice na tabelu Kazne. FK, ali sa kojih polja? Ispada (Utakmica,Domacin) u tabeli Utakmice motra da odgovara (Utakmica,Domacin) u tabeli Kazne. Ali, isto tako mora (Utakmica,Gost) da odgovara (Utakmica, Tim) u tabeli Kazne. A to ne moze da se postavi u SQL. Da pravimo jednu tabelu za kazne koje se pripisuju Gostu i jednu za kazne koje se pripisuju Domacinu? Tek onda ulazite u probleme.

Kad sam malo razmislio o svemu ovome, odlucio sam da redukujem pocetni zahtev. To je problem relacionih baza. Do jenog nivoa slozenosti, moguce je napravidi razumljiv model. Kad se predje odredjeni prag, stavri se eksponencijalno usloznjavaju. Tada je pravo vreme da se malo model denormalizuje. Kad nastupa pravi trenutak za denormalizaciju, tesko je reci. Tu pocinje umetnost, pocinje ulogu da igra praksa i iskustvo a prestaje da bude primarna teorijska nauka. Na zalost, programeri su sve bolji i bolji i na front endu se bukvalno sve moze resiti. Zbog toga se mnogi projekti prerano rastanu sa normalizacijom. Sve flat tabele sa po 250 kolona, lepo spakovane u SQL ili ORACLE a timovi programera vredno rade na odrzavanju baze i super s eosecaju jer je bukvalno savki, pa i najprostiji zahtev pravi programerski izazov. A dobri programeri uzivaju u izazovima.

Posto mislim da smo dostigli tacku posle koje se nas model veoma usloznjava, ne mislim da pravim 'potpun model' kako je Inherited zatrazio
ako neko hoce, uzmite Chachkin model i dodajte 'sport'. Onda dodajte recimo Sudije, tako da svaki sudija moze da sudi samo sport za koji je kvalifikovan. Rezultujuci model ne bi trebao da narusi nist od ovoga sto vec imamo, treba samo dodati po kolonu ili dve tu i tamo, i jos po neku tabelu. Videcete da nije ni malo jednostavno.

Postojeci model je u praksi sasvim dovoljan. Ako ga prodate fudbalskom savezu sta vas briga za kosarku i bejzbol. Mali klubovi koji imaju vise sportova su dovoljno mali da se tacni poadci mogu obezbediti veoma lako 'rucnim nacinom i kontrolom'. Ako je Laza sudija za hokej, a Pera sudija za bejzbol, malo je verovatno da ce ih direktor kluba pomesati. Ako se i napravi greska, to se lako ispravlja, i na terenu i u bazi - greska nije skupa.

Zato bih da zastanemo ovde sa razvojem modela. Ostaje zahtev da se naoisu kveriji koji izracunavaju tabelu i odgovaraju na pitnja koja sam postavio u postu od petka.

Nisam jos procitao gornji post :)

Saljem trenutno stanje. Jos nisam zavrsio, jer:
- nisam obradio sva pravila poslovanja
- nisam obradio sve zahteve za informacijama
- nisam resio sigurnost baze

Nisam uradio zabranu preklapanja termina, jer je to prica za sebe! Takodje nisa zadovoljan pogledom koji generise stanje na tabeli jer jos nezna da sortira tabelu po petom kriterijumu (medjusobni skor timova) niti jos ispisuje pozicije.

Zadrzao sam dugacka imena u SQL skripti sto moze da zasmeta nekim DBMS-ima. Mrzelo me da ih skracujem, koliko god to glupo zvucalo. Ja cesto koristim atribute cija su imena 20 znakova. Preterujem ali ne mogu da se izlecim :)

Delalt je u pravu da se projekti ne mogu spajati. I nije poenta u spajanju. Sta fali da imamo 2-3 pa i 5 nezavisnih projekata? Svako moze posle da odabere svog favorita. SLOBODA IZBORA.

Model je pretrpeo izmene, saljem i SQL skript.

SQL skript sam podelio na 3 dela:
- Standardni - koji bi trebao da prodje na vecini DBMS-a (ako se ne varam IB nece progutati zbog CASE i COALESCE). Ovde su i INSERT-i za popunjavanje tabela sa kodovima.
- PostgreSQL - ovo nije alternativa, nego nastavak prethodnog ali radjen tako da prolazi na PostgreSQL-u. Ovde su prvenstveno resene funkcije za generisanje i proveru sifre trenera i deteta (nije vise igrac!), i njihovo automatsko dodeljivanje nakon INSERT-a. Ovde je resen i CREATE ASSERT upotrebom trigera koji brani da se jedan tim pojavi dva puta u istom kolu.
- Testni podaci - ovde su neki moji test podaci.

Projekat sam izdelio na vise fajlova, a poslao sam i sve u jednom fajlu da nemorate da skidate jedan po jedan.


@narucilac projekta
Ipak se moram vratiti na vezu izmedju kola i divizija. Rekli ste da "Broj kola jeste broj timova u diviziji minus jedan”. Ako jedna divizija ima 4 tima a druga 7 timova, prva divizija ce se zavrsiti nakon 3 nedelje, a druga ce se igrati jos cele tri nedelje. Zasto deca iz prve divizije ne odigraju jos jedan krug utakmica (tj jos tri kola svako sa svakim)? Rekli ste da je cilj da se svi igraju!

---

Nemoze vise od 7 fajlova :(

---

Ne vredi


Mislis na narusavanje 1NF - ponavljajuce grupe atributa.
U svakom slucaju ni ja nisam za dodavanje jos jedne tabele, niti mi se cini da ovo narusava 1NF jer UVEK ima TACNO 2 ucesnika u utakmici. Utakmica je takmicenje izmedju dva tima (citajte moje definicije :) i to je jedinstvena cinjenica (iskaz) koja zasluzuje da se nalazi na jednom mestu (tabeli).
Ja 1NF interpretiram "ako postoji atribut koji se ponavlja varijabilno od slucaja do slucaja pa se nekad pojavi 4 puta, nekad 7 puta, a nekad 12".
Ni jedan DBMS koliko ja znam ne dozvoljava varijabilan broj atributa (kolona) u svojim tabelama, pa stoga ni jedna tabela ne moze da narusi 1NF.


Tako ce biti (u ovom sliucaju) dok se ne implementira CREATE ASSERTION (CHECK izmedju vise tabela)!


Uradicu to ja ako narucioc projekta bude trazio (Ima da traje do Nove Godine :). Cak sam mislio da je odustajanje od kazni i sudija samo odlaganje i ostavljanje necega i za 'Sve ovo lepo radi, ali mi sad ocemo i ....'.

_{[Ovu poruku je menjao chachka dana 19.12.2008. u 09:11 GMT+1]}

---

Q:@narucilac projekta
Ipak se moram vratiti na vezu izmedju kola i divizija. Rekli ste da "Broj kola jeste broj timova u diviziji minus jedan”. Ako jedna divizija ima 4 tima a druga 7 timova, prva divizija ce se zavrsiti nakon 3 nedelje, a druga ce se igrati jos cele tri nedelje. Zasto deca iz prve divizije ne odigraju jos jedan krug utakmica (tj jos tri kola svako sa svakim)? Rekli ste da je cilj da se svi igraju!

A: Sve je tacno sta kazes. Bolje je recin 'minimalan broj kola u ligi da bi svako sa svakim igrao bar po jedamput jeste N-1, N = broj timova'. Naravno da cemo samo ponoviti sve utakmice, dokle god ima raspolozivih terena i vreme to dozvoljava.

Sto se tice dopune modela kaznama, registracijam, listom strelaca - i dalje stoji da je to direktor kluba izbacio iz zahteva. rekao mu bratanac da to moze da se uradi, ali ce strasno da zakomplikuje i poskupi ceo projekat. Posto je broj pojava kazni jako mali, dovoljan je i najobicniji rokovnik, batali kompjutere.

Ovo nema veze sa bazama podataka, ali lepo je da se zna: Nas klub namerno ne zeli da vodi listu strelaca niti bilo kakve druge individualne statistike. Akcenat je na timskom radu, da je sve uspeh tima. Zbog ogromen razlike u kvalitetu dece, jasno je da u realnom zivotu u ovakvom tipu organizovanja sportskih aktivnosti, u svakom timu postoje deca koja dominiraju i igraju gotovo sami. Nas cilj je ne da najbolji postanu jos bolji, nego da najslabiji pristignu one bolje. Za najbolje, koji zele da jos vise napreduju, postoje drugi vidovi takmicenja, na visem takmicarskom nivou. Tamo nema milosti. Bas kao i srpska prva liga u fudbalu, igraju najbolji, ostali sede na klupi i gledaju sa nadom da jednom mozda uskoce u prvi tim ako dobiju sansu. Nase osnovo pravilo je su 'absolutno nema favorizovanja dece, svi dobijaju podjednaku minutazu na utakmicama i svi su podjednako vazni za uspeh tima' Svi koji pomazu u klubu, treneri, orhanizatori, svi su na istoj talasnoj duzini tako da nema nikave potrebe za prisilom i preteranom kontrolom.

Pogledacu SEELCT izkaze i racunanje stanja na tabeli.

@Chachka:
Q: Nisam uradio zabranu preklapanja termina, jer je to prica za sebe! Takodje nisa zadovoljan pogledom koji generise stanje na tabeli jer jos nezna da sortira tabelu po petom kriterijumu (medjusobni skor timova) niti jos ispisuje pozicije.
A: Ako bas hoces prbaj to da odradis, a mozes i da ostavis gde je. Dovoljno je slozeno i ovako. Ako se zakomplikuje mnogo, mnogi ljudi nece dalje moci da prate

Hteo sam malo i da pokazem kako izgleda zivot projektanta baze. U realnm zivotu, narucioci su mnogo gori nego ja u opisvanju problema. Ja sam se zaista trudio da opisem zahtev, dakle STA treba da se uradi, bez sugerisanja KAKO to u stvari izvesti. I pored truda da budem kratak i jasan, pola vremena smo potrosili da razjasnimo i shvatimo sta se u stvari hoce. Posle je sve bilo cista tehnika. Setite se toga kad se pojavi neko sa zahtevom da mu se uradi 'mali programcic' za ovo ili ono. Zasto 'mali'? Zasto 'programcic'? Ikonica na desktopu je mala. A iz ikonice, ko zna sta je sve i kolko je malo ili veliko.

Tema je do danas (11 sep 2006) imala preko 750 razgledanja, sto znaci da nismo promasili temu.

Hvala svima na saradnji


_{[Ovu poruku je menjao Zidar dana 11.09.2006. u 22:02 GMT+1]}

Evo, neću više da forsiram proširenje zahtjeva. Chachka se stvarno potrudio i uradio dosta posla. Iz njegove priložene dokumentacije može se štošta naučiti.
Ja sam krenuo malo sa širim obimom zahtjeva, zbog kojih sam se u samom početku odlučio za određeni dizajn tabela.
Eto, i sam "malen" zahtjev da se osigura da se isti tim ne može dva puta pojaviti u istom kolu jedne sezone može dosta da iskomplikuje i promijeni dizajn baze. Ovo je bio zahtjev od samog početka, ali zamislite da je to napomenuto na samom kraju, kad je već skoro završeno, napisani SQL upiti... Vrati vas skoro na početak, redizajn tabela, mora ići i redizajn međusobnih zavisnosti, SQL upiti se mijenjaju ili pišu ponovo. Još ako takvih zahtjevčića ima više, skoro pa dupli posao.
Zato sam predvidio mogućnost da se radi o više sezona, više sportova, da treba voditi evidenciju o igračima i njihovom transferu ili odlasku iz tima kroz duži vremenski period, tako i o rezultatima i kaznama na svakoj utakmici. Napominjem da neću da proširujem konačne zahtjeve, ali ću još samo postaviti malo modifikovan dijagram (i dalje nezavršen), zbog ideje kako riješiti onaj već pomenuti problem "da se isti tim ne može dva puta pojaviti u istom kolu jedne sezone". Jedno rješenje je već pomenuto, ako bude moguće koristiti SELECT unutar CHECK-a.
Drugo rješenje je dodavanje jedne pomoćne tabele UT_CHK i korištenje trigera. Triger u ovu pomoćnu tabelu za svaki jedan red u tabeli UTAKMICE upisuje dva reda u tabelu UT_CHK, jedan za domaćina (u kolonu DG se upisuje "1", a drugi za gosta (u kolonu DG se upisuje "2"). Ostale kolone se prepisuju iz tabele UTAKMICE. Sad se još postave UNIQUE indeksi, a transakcija obezbjedi da se uvijek upišu ili obrišu oba reda za istu utakmicu.
Tako se zadržavaju u tabeli UTAKMICE dvije kolone (DOMAĆIN i GOST) jer je takva struktura dosta pogodna (Zidar je to detaljno pojasnio), a pomoćna tabela služi samo zbog onog uslova, i na nju ne treba više obraćati pažnju ni onaj ko radi interfejs, a ni onaj ko koristi bazu. Možda rješenje nije baš uobičajeno, ali možda nekome nekad i riješi problem.
Ostalo zanemarite, trebalo bi i za neke druge tabele takođe koristiti SELECT unutar CHECK, ali to neću dalje razmatrati. Međutim, ovakvi CHECK-ovi bi mogali da skrate dosta posao (puno prije Nove godine).
Eto, i ovo se uklapa u temu "Teorija vs. praksa", po SQL standardu je, a ne može se koristiti u praksi čak i u nekim poznatijim DBMS-ovima.
I dalje ostaje poziv da okačite svoja rješenja, a interesuje me i implementacija na raznim DBMS-ovima (da li ovo može da prođe).

[Quote]ali ću još samo postaviti malo modifikovan dijagram (i dalje nezavršen), zbog ideje kako riješiti onaj već pomenuti problem "da se isti tim ne može dva puta pojaviti u istom kolu jedne sezone". Jedno rješenje je već pomenuto, ako bude moguće koristiti SELECT unutar CHECK-a.
Drugo rješenje je dodavanje jedne pomoćne tabele UT_CHK i korištenje trigera. Triger u ovu pomoćnu tabelu za svaki jedan red u tabeli UTAKMICE upisuje dva reda u tabelu UT_CHK, jedan za domaćina (u kolonu DG se upisuje "1", a drugi za gosta (u kolonu DG se upisuje "2"). Ostale kolone se prepisuju iz tabele UTAKMICE. Sad se još postave UNIQUE indeksi, a transakcija obezbjedi da se uvijek upišu ili obrišu oba reda za istu utakmicu.
Tako se zadržavaju u tabeli UTAKMICE dvije kolone (DOMAĆIN i GOST) jer je takva struktura dosta pogodna (Zidar je to detaljno pojasnio), a pomoćna tabela služi samo zbog onog uslova, i na nju ne treba više obraćati pažnju ni onaj ko radi interfejs, a ni onaj ko koristi bazu. Možda rješenje nije baš uobičajeno, ali možda nekome nekad i riješi problem.
[/quote]
Svako resenje koje omogucuje da se kaze " na pomocnu tabelu ne treba više obraćati pažnju ni onaj ko radi interfejs, a ni onaj ko koristi bazu. " zasluzuje ocenu ODLICAN. Mozda triger moze da se napise na ovaj ili onaj nacin, manje ili vise efikasan i elegantan, to nema veze. kako god da se pise, pise se samo jednom i onda se na njega zaboravi. To je poenta. Napisi i zaboravi na to, radice sledecih 100 godina.

Odlicna ideja.

Resenje jeste zanimljivo, ali posto Interbase/FireBird podrzava SELECT u CHECK-u to se moze uraditi i sa prostim

Ovaj SELECT usput proverava i da je domacin <> gost pa poseban CHECK za to nije potreban.


Drugi nacin: Ako se vec uvode triggeri u igru onda se mogu napraviti trigger-i after insert i after update koji rade istu stvar bez uvodjenja nove tabele.


U svakom slucaju delalt-ovo resenje jeste trik kojeg vredi zapamtiti.

---

@Chachka
Trigeri su ovdje najelegantnije i najefikasnije rješenje. Izbjegava se dodatna tabela, izbjegavaju se suvišni inserti
i trigeri. Jedino dopuna da bi možda bolje bilo napraviti jedan onakav kao što si predložio,
u BEFORE INSERT OR UPDATE.

Ta dodatna tabela mi je pala na pamet kad sam čitao Zidarev komentar:
Iz ovog se vidi da bi najbolje bilo imati obije varijante na raspolaganju, timove kao DOMACIN i GOST u jednom
redu, a u drugoj varijanti jednu kolonu TIM uz obavezno dva inserta, update-a ili brisanja, za domaćina i za
gosta. Pa zašto to onda i ne uraditi, napuštajući pravila koja bi trebalo poštovati, ako će to svima olakšati život.
Ne kažem da će baš i olakšati, ali tema je "Teorija vs. praksa", pa bi se moglo diskutovati o ovome zašto to baš
ne valja. Ja sam dao primjer kako se pomoćna tabela može iskoristiti za provjeru duplih, ali mogla bi se iskoristiti
i za npr. vezu prema nekim drugim tabelama, ako je pogodnija od tabele UTAKMICE. Dodavajući (duplirajući) još
neke ili sve podatke mogla bi poslužiti da uprosti upite potrebne za nekakve izvještaje.
Znači, treba imati na umu da su te dvije tabele podjednako ažurne jer su unutar transakcija i o tome se brine
DBMS. Na kraju dobijete dvije tabele sa istim podacima, različito složene. Pogodno i za pravljenje interfejsa,
a pogodno i za onoga ko bi trebao da pravi upite za složene izvještaje, možda i za onog ko dizajnira (zavisno
od toga šta bi još naručilac posla mogao tražiti).
Naravno, ovo mi se čini veoma pogodno baš za ovaj slučaj praćenja amaterskog ligaškog takmičenja. Količina
podataka je relativno mala, utakmice se održavaju vikendima i to je veoma mala količina podataka, pa dupliranje
nije nikakav problem. Takođe je i frekvencija upisa veoma mala (na kraju dana se upišu rezultati utakmica i još
ponešto, a ako bude potrebno i poneka izmjena). Izvještaji su vjerovatno potrebni sedmično (izvuku se i okače
na oglasnu tablu ili internet). Sve u svemu, nikakav problem za DBMS. Veći je problem onemogućiti greške pri
upisivanju. S druge strane, kod veće količine podataka i visoke frekvencije upisa ili izmjena podataka, ili više njih istovremeno upisuje i čita podatke pri sporim vezama, ovakvo rješenje je sigurno neprihvatljivo.
Pošto se ovdje ipak radi o dizajnu baze, ne bi bilo loše pojasniti zašto ovo valja ili zašto ne valja.
Na greškama se ipak najbolje uči.

Još samo da ispravim jedan moj propust. Zidar se bio potrudio da prokomentariše moj prvi dijagram (dao je to
u prikačenom fajlu Delalt_Comments.doc), bio sam spremio odgovore, ali ih nisam odmah okačio, imao sam
još nekakva podpitanja, pa evo sada:

Q: 1. Imamo tabelu Sezone i mogu da unesem stvari kao:
SezonaID Naziv
1 Kosarka Aug 2006
2 Hokej 2006-2007
3 Oktobar 2006
4 Fudbal, 2007
A: Predviđena je samo da se unose vremenski periodi, bez oznake sporta (postoji posebna tabela SPORTOVI),
sa nekakvom skraćenicom i punim opisom npr.:
SezonaID Naziv
2005 sezona 2005
L05 leto 2005
Z0506 zima 2005/2006
NT0506 mali novogodišnji turnir 2005/2006

Q: 2. Imamo tabelu Divizije, ali ne vidim u kakvoj je vezi Divizija i sezona. U kolonu Sezona u tabeli Divizija
mogu da unesem bilo sta, ne vidim FK od Sezone.
A: Tabela DIVIZIJE je samo šifarnik, trebao bih napraviti još jednu tabelu za vezu, SEZONE_DIVIZIJE, međutim,
na samom početku je rečeno da je raspored timova i utakmica za jednu sezonu već gotov, (Word ili Excel
dokument, koji samo treba unijeti u bazu). U tabeli UTAKMICE vidi se kojoj sezoni koja utakmica pripada
i koji timovi igraju. Timovi pripadaju određenoj diviziji, pa se može napraviti nekakva veza i provjera. Pošto je
rečeno da je moguće praviti mješovite timove (dječaci, djevojčice, ili miješano), onda mogu pripadati i različitim
divizijama, a ipak da igraju međusobno. Zato nisam pravio direktnu vezu.

Q: 3. Ako vec imam sportove, ne vidim da su tereni zavisni od sportova. Sta me sprecava da za hokej ili
odbojku odaberem teren ‘Bazn na Tasmajdanu’. Bolje je da se sportovi izbace iz modela, rekli smo na kraju
da radimo jedan sport.
A: Riješeno tabelom TERENI_SPORTOVI

4. Timovi pripadaju divizijama . OK
5. Timovi imaju sponzora. OK
4. Timovi pripadaju odredjenom sportu.OK, ali cemo zanemariti Sportove nadalje.

Q: 5. Timovi imaju Tim ID. Imaju i Takmicarski Broj. Cemu sluze ove dve kolone?
A: TIMOVI je šifarnik, Takmičarski broj mi nije pogodan za PK, može da se ponavlja iz sezone u sezonu

6. Tabela Sponzori kontrolise unos sponzora u tabelu Timovi. OK
7. Postoji tabela Igraci – svi koji su platili clanarinu. OK
8. postoji tabela Timovi_Igrace, ko je u kom timu, OK, imamo i ko je od kada igrao do kada. I to je OK,
veoma lepo. Izgleda da ‘Ocena Kvalietet Igraca’ se menja od tima do tima. Zanimljivo, i verovatno dobro,
jer se moze pratiti progres igraca. Moze na pocetku sezone da bude los, pa do kraja predje u kategoriju
‘solidan’. Lepo prosirenje od strane projektanta.

Q: 9. Utakmice-Igraci nije potrebna tabela, rekli smo da ne pratimo ko je igrao na kojoj utakmici,
da olaksamo model.
A: U tabelu UTAKMICE_IGRACI upisuju se samo dešavanja na utakmici (šifra utakmice i vrijeme i šifra
igrača koji je postigao pogodak ili dobio kaznu...) a ne spisak svih igrača. Malo sam promašio sa nazivom
tabele. Ova tabela ima kolonu UTAKMICA koja referencira na tabelu UTAKMICE, u kojoj su datumi i
šifre domaćina i gosta. Po ovim šiframa timova, može se upitom, za dati datum održavanja utakmice
preko tabele TIMOVI, TIMOVI_IGRAČI i IGRAČI doći do naziva timova i spiska igrača tih timova koji su
igrali baš na toj utakmici, bez obzira na ranije transfere.
Ovo je urađeno zato što je moguće da baš posuđeni igrač iz nekog drugog tima postigne pogotke i pobjedu
timu, a onda se vrati i nastavi igrati sezonu za svoj matični tim. Ne bi bilo lijepo izostaviti njegovo ime iz
spiska igrača tog tima.

Q: 10. Utakmice: ne vidim iz modela da me nesto sprecava da iamesam timove. Moze “KK Cibona” da igra
protiv “OFK Beograda”, ako nepazljivo kucam. KK = kosarkaski klub, FK = fudbalski klub. Navedeni primer
je malo verovatan, ali moguc. Medjutim, moguce je pomesti timove iz razlicitih divizija, cak i ako se
zadrzimo na jednom sportu. Tabela Utakmice nema podatak koji nam kaze o kojoj se diviziji radi.
A: Postoji CHECK koji provjerava da su iz iste divizije ili za isti sport

_{[Ovu poruku je menjao delalt dana 16.09.2006. u 10:05 GMT+1]}