Logi
čki dizajn baza podataka
korišćenjem normalizacije
Doc. dr
Vesna Popović-Bugarin
Univerzitet Crne Gore
Elektrotehnički fakultet
Logički dizajn baza podataka
Faza unutrašnjeg (internog) dizajna baze podataka -
uključuje dizajniranja „unutrašnjosti“ baze koju većina
korisnika nikada
neće vidjeti.
Zadatak koji bi se trebao obavljati aplikacijom se dijeli u
module (individualne jedinice programiranja aplikacije
koje
će biti napisane i testirane zajedno) i daje se detaljna
specifikacija svakog modula.
Sa stanovišta
buduće baze podataka,
normalizacija
je
najvažnij zadatak u fazi
(logičkog) dizajna baze podataka.
Normalizacija je razvijena od strane Dr. E.F. Codd za dizajniranje
tabela u relacionim bazama podataka, koje su najbolje za sisteme
zasnovane na transakcijama (sistemi koji vrše dodavanja, ažuriranje i
brisanje podataka u tabelama relacionih baza podataka).
Normalizacija nas
uči kako da najbolje organizujemo podatke u
tabelama.
Logički dizajn - tremini
Kroz proces normalizacije
ćemo koristiti logičke izraze za
sve.
Podaci
logički predstavljeni u dvodimenzionalnom
formatu
čine
relaciju.
Fizički dizajn baza podataka je zapravo taj koji vrši
transformisanje normalizovanih relacija u relacione tabele
i
postoji
određeno odstupanje u preslikavanju
normalizovanih relacija u
fizičke tabele.
Logi
č
ki izraz
Fizi
č
ki izraz
Relacija
Tabela
Jedinstveni identifikator
Primarni klju
č
Atribut
Kolona
Torka (tuple)
Vrsta
POTREBA ZA NORMALIZACIJOM
U svom ranom radu o teoriji relacionih baza podataka, Dr
Codd je otkrio da nenormalizovane relacije uvode
određene probleme prilikom pokušaja ažuriranja
podataka u njima.
Za ove probleme Dr Codd je koristio izraz
anomalije
.
Razlog normalizacije relacija je uklanjanje anomalija iz
podataka.
Ove anomalije su od suštinskog značaja za
razumijevanje, jer nam govore kada je prihvatljivo zaobići
pravila prilikom fizičkog dizajna uz pomoć
„denormalizacije“ relacija.
Da bismo zaobišli pravila moramo razumjeti zašto ta
pravila postoje.
ANOMALIJE - INSERT
Anomalija insertovanja
predstavlja situaciju gdje se nova
torka (vrsta) ne može insertovati u relaciju zbog vještačke
zavisnosti od druge relacije.
Greška koja je uzrokovala anomaliju je ta da su atributi
različitih entiteta pomiješani u istu relaciju.
Vidimo da su ID, ime i adresa kupca uključeni u račun
(pogled).
Ako bismo željeli da napravimo relaciju iz ovog pogleda
kakav jeste, a nakon toga i tabelu iz relacije, otkrili bismo
da se novi kupac ne može insertovati u bazu ukoliko
nešto nije kupio. Ovo je stoga što svi podaci vezani za
kupca uključeni u sam račun.
