2NF i 3NF normalne forme

Malo me buni 2. i 3. normalna forma. Recimo da imam sljedeću tablicu "Ispit" koja je već u 1NF:


Znači, jedan student na određeni datum može samo jednom izaći na ispit iz jednog predmeta (ali taj dan može izaći na više ispita tj. iz više različitih predmeta).

U ovoj tablici očito je redundantna kolona 'PredmetNaziv' jer je ona već opisana stupcom 'PredmetID'. Stoga bih za zadovoljavanje 2NF umjesto ove gore tablice napravio dvije tablice:



Ali nisam siguran što je sa kolonama ProfesorIme i ProfesorPrezime. Za razliku od kolone PredmetNaziv ove dvije kolone nisu opisane niti jednim dijelom primarnog ključa tablice "Ispit" i čini mi se da bi se njih trebalo eliminirati tek u 3NF?

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.

Potpis

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

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.

Potpis

F

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

Potpis

F

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.

Potpis

F

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

Potpis

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

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.

Potpis

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

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.

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.

Potpis

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

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

Potpis

F

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.

Potpis

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