Ja bih rekao da je ispravno da prepoznaš da ti nedostaje identifikator za profesora i da ga uvedeš a onda uradiš isto što i sa predmetom.

I Ocjena polje bi morao nekako ograničiti, da ne mogu unositi što ih volja. I da budem iskren, ne sviđa mi se da ti polje Datum bude PK. Nemam iskustva sa datumima kao PK, ali nekako mislim da to nije dobra praksa. Možda da kroistiš redni broj dana u godini uz dodatak oznake godine? 00117, 00217 itd.? To je samo jedna od mogućnosti.

Datum spada u precizni tip podatka i skladisti se kao int24 tako da ne vidim ni jedan razlog zasto ovo ne bi bila dobra praksa.

Da, nisam o tome razmišljao, ali ipak mi je nekako nezgrapno da mi je datum PK :)

Nema tu što biti nezgrapno. Datum jednoznačno određuje dan, mjesec i godinu, te zato može biti primarani ključ ili jedan njegov dio.

Na jedan ispit, istog dana, može da izađe više od jednog studenta, ili ni jedan. Zato kombinacija PredmetID, DatumIspita može da se izdvoji u posebnu tabelu. Šta ako je predviđen ispit iz nekog predmeta za koji se nije prijavio ni jedan student? Raspored ispita po danima bi trebalo da postoji pre nego što se studenti prijave (ili ne prijave) za taj ispit.

...ali samo jedanput! Zato je i StudentID dio primarnog ključa tablice.

Nedaš mi utjehe :)

Nevezano za datum kao PK, ja bi možda rađe stavio RedniBrojIspita kao PK umjesto DatumIspista, recimo jedan razlog - upisali su krivi datum ispita ili se promijenio datum ispita. Nije zgodno mijenjati primary key.

Zato se za PK stavi autoincrement i ne vezuje se za prirodni ključ tabele.

Ali kako ćeš onda zabraniti da student ne može na isti dan dva ili više puta polagati isti ispit? Jasno, moglo bi se to programski riješiti, ali bolje je imati pravila u bazi pa nek se klijent prilagođava..

A kako ćeš sprečiti da student prijavi ispit nekog drugog dana, a ne onda kada se održava? predmetid i datumispita nisu dobar izbor za polja tabele, a još manje za delove primarnog ključa. Treba da imaš evidenciju studenata (sa id studenta), raspored ispita (sa id, datumom, predmetom, profesorom...) i tabelu prijave sa PK (id_studenta, id_ispita).

To bi rješio sustav (klijent aplikacija) koja sigurno ne bi dozvolila studentu da odabere datum slobodnim unosom već da npr. izabere jedan od ponuđenih (unaprijed definiranih datuma) iz combobox-a. A može se napraviti i šifrarnik datuma po ispitu i tada sama baza ne bi dopustila kršenje referencijalnog integriteta ako bi se unio krivi datum. Ali to nema veze s ovom pričom o normalnim formama. Ovo je tek primjer zadatka kojeg sam našao pa preko njega pokušavam prokužiti normalizaciju.

EEEEEEK! Wrong answer! :)

Naopako! Ne radi se to tako. Lepo je djoka_l objasnio.

Svašta se ovdje objasnilo osim onoga što sam ja pitao :) Ali nema veze, već sam našao odgovor na drugom mjestu.

I što se tiče tablice, ona je takva zadana zadatkom pa o njenom dizajnu nema smisla puno raspravljati.

_{[Ovu poruku je menjao itf dana 25.05.2017. u 18:47 GMT+1]}

Ama baš sve što je napisano u ovoj temi je napisano da ti se pomogne oko i pitanja koj si postavio i sve je itekako na zadatu temu (normalizacija date strukture baze).

E sad, ako ti to ne razumeš ili ti se ne dopada, to je tvoj problem.

Ne znam baš tko ovdje ima problema sa razumijevanjem jer moje pitanje je od početka bilo jasno i konkretno. Nisam pitao niti tražio savjet oko tipova podataka, izbora primarnog ključa ili dizajna već postojeće i unaprijed definirane tablice u zadatku, već sam pitao za dvije kolone ProfesorIme i ProfesorPrezime te da li ih treba eliminirati u 2NF ili 3NF. I vrabcu na grani je jasno da trebaju postojati dodatne tablice jer to i jest rezultat normalizacije no mene je zanimao isključivo postupak normalizacije pomoću kojeg dođem do tih tablica tj. da znam koja pravila i na koji način trebam primijeniti u 2NF i 3NF. Svašta se može naći na netu no htio sam to čuti "ljudskim" a ne matematičkim jezikom.

Svejedno, ponavljam, došao sam do rješenja i mislim da nema više potrebe za ovom raspravom.

NHF, ali mislim da ti je pristup krivi :)
Istina, ti si pitao određeno pitanje i svi smo mi pretpostavili da ti je sve van toga pitanja jasno. Ali... Ima jako puno primjera ovdje na forumu kada ljudi pitaju pitanja kao ti, misle da je ostatak dobar i onda mi drage volje ukažemo i na ostale eventualne probleme/greške/primjedbe, kojih možda otvarač tema nije niti bio svjestan. Tako da, sve je u dobroj namjeri :)

Nemam ništa protiv okolne rasprave, pa čak i ako nema toliko direktno veze s temom (ipak je ovo forum), no tablica je unaprijed zadana u takvom obliku. Vjerojatno je sam autor to tako napravio da njome demonstrira 2NF i 3NF. Ja sam dao svoje mišljenje zašto mi se čini logičnom, neki od vas su dali svoje mišljenje zašto bi trebala biti drukčija, no činjenica je da je takva kakva jest.

I inače, odgovor na pitanje:

Ja sam shvatio da treba da uradis normalizaciju tabela koje si naveo u primeru a ne samo tih polja oko prodesora, a verujem i da je smisao zadatka da sve normalizuješ a ne samo ta polja.

Al verovatno ti znbaš bolje i verovatno će ti ocena biti u skladu sa tim.

Šteta potrošenog vremena da ti se objasnjava nesto sto ti misliš da ti nije ni trebalo.

A što to još nije normalizirano? Ako tablica "Ispit" nije u 3NF (što se općenito smatra dovoljnim jer više nema anomalija pri radu s podacima) onda molim te ukaži na grešku u rješenju koje sam dobio i prikazao. Jedino što u rješenju nije rečeno jest da umjesto uklonjenih kolona ProfesorIme i ProfesorPrezime ide njihov strani ključ u tablicu Ispit.

Formalno gledano, tri polja koja bi ti smestio u PK bi mogla značiti da je tabela u 3NF, jer ostala polja, (ocena, i id profesora) zavise samo od ta tri polja i jedinstvena su za relaciju. Ali to je mehanički način normalizacije tabele.
Ono što ja pokušavam da ti ukažem, da taj formalni način NE VALJA AKO NE UKLJUČIŠ SEMANTIKU.

Dao sam ti već primere, datum, iako je deo primarnog ključa nije nezavisan od ostalih podataka, na može PROIZVOLJNO da se odabere.
IspitID i datum ne može da se proizvoljno da se odabere, i tvoja organizacija tabele ne pokriva slučaj da ni jedan student nije prijavio određeni ispit određenog dana.

Na osnovu tvoje tabele, izlistaj mi SVE ZAKAZANE ISPITE 26.5.2017. godine. Naravno, to ne može jer ti neće izaći oni ispiti za koje se nije prijavio ni jedan student.

Kako PRVI student koji se prijavljuje odabira ispit i dan, ako niko pre njega nije prijavio isti ispit istog dana?

djoka_l ti je lepo objasnio ali si mu ti odbrusio da ti to ne treba. Tako da ne mislim da ima svrhe poklušavati opet pošto bi samo ponavljali ono što ti je on već predložio. Ai drugi su ti dali dobre sugestije.

Možda se na tom fakultetu zaista zakazuje ispit za svakog studenta posebno, sa različitim terminom, kod profesora u kancelariji u četri oka :)
U tom slulaju model odgovara :)

Ma ni ne mora da bude takav slučaj, ovo je generalno problem ZAKAZIVANJA.

Istu logiku možemo da primenimo na zakazivanje pregleda kod lekara. Imamo entitete LEKAR, PACIJENT i TERMIN. Lekar može da bude slobodan u nekim TERMINIMA, PACIJENT zakazuje pregled u nekom TERMINU kod nekog LEKARA. Mora postojati slobodan TERMIN i slobodan LEKAR.

Kod ispita, opet, nije jedan student na jedan termin kod jednog profesora, ali i tu možemo da vidimo da imamo entitete STUDENT, TERMIN, ISPIT, PROFESOR. U pojedinom TERMINU može postojati n "slotova" za studente gde n može biti ograničeno na neki način (recimo u jednom terminu PROFESOR prima 5 STUDENATA), ili rezerviše UČIONICU sa 30 mesta itd.

Kako iz predložene tabele sprečiti da student nema više ocena iz istog predmeta? Ako isključimo semantiku iz razmatranja, sasvim je u redu da student u svakom ispitnom roku izlazi na isti predmet i dobija neku ocenu. Koja je onda ocena studenta iz nekog predmeta?

Mene isključivo zanima normalizacija koja je napravljena u skladu sa pravilima normalnih formi, i sukladno tim pravilima objasnio sam rješenja koja sam prikazao. Nije moj problem ako tablica u tom obliku ne daje odgovor na neka od pitanja već je to više problem onoga tko je takvu tablicu i napravio. I opet kažem, čisto sumnjam da netko koristi ovu tablicu u stvarnom radu već je vjerojatno tek za vježbu pa nije niti zamišljena da daje odgovor na sva pitanja.

Da bi se dao odgovor na tvoja pitanja trebalo bi se rastaviti početnu tablicu tako da se datum i PredmetID nalaze u nekoj drugoj tablici (npr. tablica TERMIN koju spominješ). Ali to se ovdje NE SMIJE napraviti jer se u 2NF i 3NF ne radi rastavljanje primarnih ključeva zadane tablice već analiza ovisnosti ne-ključnih kolona o ključnima (2NF) te međusobnoj ovisnosti ne-ključnih kolona (3NF). Dakle, ako su primarni ključevi već definirani (a fino u zadatku piše da je tablica već u 1NF, dakle - jesu) onda je to to i samo se analiziraju ne-ključne kolone.

Ako uzmemo da je normalizaciaj baze podataka postupak kojim se dolazi do osnovnog cilja relacionog modela a to je da baza ne sadrži redundansu onda se to odnosi i na ključeve nad tabelama u toj bazi. Šta je ključ tabele potpuno je nebitno, jer ako tabela nije normalizovana onda naravno da je vrlo moguće da je i ključ takav.

Ili da idemo dalje pa da se pozabavimo drugim ciljem normalizacije a to je da se spreče anomalije održavanja podataka (dodavanje, brisanje i promene) na šta ti je ukazano kao problemi koje tvoj primer sadrži i koji BI TREBALO da se reše normalizacijom.

Normalizacijom se SME napraviti sve što dovodi do pomenutih ciljeva a ne dovodi do gubljenja podataka.

Ako je tablica "Ispit" u 1NF (a u zadatku je definirano da jest) onda su već u 1NF odabrani primarni ključevi i o njima se više nema što raspravljati već ih se tek može prihvatiti takve kakve jesu. Ne može se više u 2NF i 3NF premišljati glede njih.


Pitanje koje se postavilo je
Na ovo pitanje se ne može dati odgovor i čini se da je riječ o anomaliji, no prije bih rekao da je riječ o krivom shvaćanju poante tablice "Ispit". Pravo pitanje bi bilo "izlistaj mi SVE ODRŽANE ISPITE 26.5.2017. godine jer tablica ispit nema popis zakazanih ispita već onih koji su održani. Da je ispit samo zakazan ne bi nužno postojala ocjena ako student nije pristupio, a ako niti jedan student nije pristupio ispitu onda taj ispit nije niti održan.