Već sam dva puta na dva različita mesta pisao istu ovu priču, pa kapiram da bi vredelo da se nađe i ovde kada se već iscimao i napisao nešto o samoj normalizaciji.
Osnovni problem sa kojim se susrećemo gledajući šta klijenti rade je loš / očajan DB Model. Ja to zovem „sindrom clipper“ pošto su to uglavnom bivši clipper programeri ili učenici bivših clipper programera koji se sada odjednom nalaze u dodiru sa RDBMS-om i ne znaju kako da mu priđu. Nadam se da će ovaj tekst, koliko je moguće, pomoći da se shvati pravilan način za modeliranje baze podataka, razlog zbog kog je to neophodno i sve prednosti koje takav model donosi. Takođe se iskreno nadam da će svi „vajni programeri“ shvatiti da RDBMS nije isto što i podaci snimljeni u tekstuali fajl.
Modeliranje baze podataka – Normalizacija
Normalizacija modela baze podataka je proces definisanja strukture baze podataka (entiteti, atributi i relacije) u optimalni format. Standardne normalne forme su aditivne, dakle ako je neki model sveden na treću normalnu formu, automatski je u drugoj i prvoj normalnoj formi. Osnovne forme DB modela su:
- 1NF: Prva normalna forma
- 2NF: Druga normalna forma
- 3NF: Treća normalna forma
- BCNF: Boyce/Codd normalna forma
- 4NF: Četvrta normalna forma (aka izolacija nezavisnih relacija)
- 5NF: Peta normalna forma (aka izolacija semantički povezanih relacija)
- DKNF: Domen/Ključ normalna forma (aka savršen model)
- 6NF: Šesta normalna forma (aka „bez ne-trivijalnih“ join zavisnosti – razbija relacije na najmenju moguću jedinicu, upotrbljivo isključivo kod temporalnih vrednosti gde se vremenski intervali razbijaju na pojedinačne vrednosti )
Terminologija / pravila
Funkcionalna zavisnost
Funkcionalna zavisnost atributa X nad atributom Y (Y→X) postoji ako za svako Y (za svaku vrednost atributa Y) postoji tačno jedan X. Ako se vrednost Y ponavlja u tuplu onda se i vrednost X takođe ponavalja. Ako to uporedimo sa primerom modela u trećoj normalnoj formi KORISNIK_ID je u funkcionalnoj zavisnosti sa DRZAVA_ID zato što je jedna vrednost za KORISNIK_ID uvek vezana za jednu i samo jednu vrednost za DRZAVA_ID. Obratiti pažnju da obrnuto ne važi pošto u jednoj drzavi moze da živi više korisnika te DRZAVA_ID nije funcionalno zavisna od KORISNIK_ID.
Atribut može biti funkcionalno zavistan ili u odnosu na drugi atribut ili u odnosu na kombinaciju atributa. Nije moguđe odrediti nivo normalizacije DB modela bez razumevanja međusobnih funkcionalnih zavisnosti atributa koji čine isti.
Trivijalna funkcionalna zavisnost
Trivijalna funkcionalna zavisnost je funkcionalna zavisnost atributa prema supersetu sebe.
Potpuna funkcionalna zavisnost
Atribut je potpuno funkcionalno zavistan od seta atributa X ako je funkcionalno zavistan od X ali nije funkcionalno zavistan ni od jednog podskupa seta X.
Tranzitivna zavisnost
Tranzitivna zavisnost je indirektna zavisnost gde A→C samo zato što A→B i B→C.
Višeznačna zavisnost
Višeznačna zavisnost je potpuna veza dva seta atributa u relaciji. Za razliku od potpune zavisnosti, višeznačna zavisnost zahteva da određeni tuplovi butu prisutni u relaciji te je višeznačna zavisnost specijalni slučaj tuple-generisane zavisnosti. Ova vrsta zavisnosti igra ulogu kod četvrte normalne forme.
Vezna zavisnost
Entitet T je vezno zavistan ako se može rekreirati vezivanjem više tabela od kojih svaka ima podskup atributa entiteta T.
Superkey – superključ
Superključ je atribut ili set atributa koji jedinstveno određuju slog u tabeli, tj. dva jedinstvena sloga u tabeli će garantovano imati iste superključeve.
Ključ kandidat
Ključ kandidat je minimalni superključ, tj. to je superključ koji nema podskup koji je takodje superključ.
Non-prime attribut
Non-prime attribut je atribut koji se ne javlja ni u jednom ključu kandidatu.
Primarni ključ
Primarni ključ je ključ koji po definiciji određuje slog u tabeli, dakle ključ koji je postavljen kao definišući odlukom a ne svojstvom.
Нисам знао да постоји и 6.НФ :D
Иначе, ја не идем даље од 3.НФ, понекад некако сведем на БКНФ. Углавном, малтене из прве направим добро нормализован модел, у зависности од захтева, потреба и могућности задатка/пројекта.
Добро, кратко и јасно објашњено, што је иначе и најбоље објашњење :)
Hvala hvala, realno sve preko BCNF je uglavnom „common sense“, kad steknes osecaj – iako ti je cilj 3nf vrlo cesto baza bude mnooogo vislje na skali :)
Lepo napisano ali valjda je DRZAVA_ID funkcionalno zavisna od KORISNIK_ID, a ne obrnuto kako stoji u tekstu?
za (Y→X) X je drzava a Y korisnik, pa ti sad racunaj koje tu zavistan od koga :D ali ipak bih rekao da je korisnik funkcionalno zavistan od drzave kao sto pise
Početnik sam u svemu ovome ali evo kako sam ja to shvatio. Imam i predmet Baze podataka na fakultetu pa sam iz literature, a i radeći zadatke, zaključio sledeće: za svaki KORISNIK_ID postoji tačno jedan DRZAVA_ID, obrnuto naravno ne važi, tako da je KORISNIK_ID→DRZAVA_ID tj. DRZAVA_ID funkcionalno zavisi od KORISNIK_ID. Nebitno je, važno je da razumem o čemu se govori, ali eto čisto forme radi postavio pitanje jer me je ovo malo zbunilo.
Primer Korisnik_ID Drzava_ID nije ok sam po sebi, jer ljudi zive i registrovani su u vise drzava i mogu imati vise drzavljanstava. Bolje ici varijantom Zemlja_ID pa sve ostalo, a u skorije vreme SolarniSistem_ID :D
dragi Vlado, ovo je primer koji se bavi modeliranjem baze ne politicke situacije u zemlji … tako da, bitno je da skontas primer, a to sto mi na balkanu imamo po 3 ilegalna pasosa i jos se time hvalimo, to je za neki b92 ili tako nesto
Prvo srdacan pozdrav!
Skoro sam naisao na sajt gdje je odradjena baza za zakazivanje termina putem interneta. Pa ako ima mjesta na ovom sajtu vole bih da prokomentarisemo vezano za tu bazu. Recimo da li je dobro ili nije dizajnirana ?
Link:
http://www.javaguicodexample.com/databaseanalyzedbdesigner.html
mislim da je za takav tip „komentarisanja“ mnogo bolje neki forum nego ovde :)
inace ovako na prvi pogled izgleda ok (jedino sto je mnogo bolje uzeti workbench nego dbdesigner)