2NF i 3NF normalne forme

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.

Potpis

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

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 :)

Potpis

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

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.

Potpis

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