Projektovanje baza podataka

Konceptualni model podataka

 Ishodi predavanja
• Određivanje atributa veza kao i dodatnih uslova
veze između entiteta,
• Projektovanje detaljnog modela objekti veze (MOV
i/ili PMOV),
• Poslovna pravila i uslovi, ograničenja koja postoje u
sistemu.
• Definicija domena i ograničenja vrednosti podataka.
• Povezivanje sa normalizacijom.
 Najava sledećeg časa
• Na sledećem času se objašnjava
postupakdetaljizacije PMOV, kao definisanje
domena i uvođenje sistemskih i ograničenja
vrednosti podataka.
 Atributi veza između entiteta

• Ako veza ima sopstvene atribute mora se

modelovati kao entitet (nezavisno od tipa veze:
1:1, 1:N, N:N)!!!
• Ako je veza više prema više uvek se mora
modelovati kao entitet (nezavisno da li ima
sopstvene atribute ili ne).
 Dodatni uslovi koji se odnose na
vezu između entiteta
• Koji je najmanji i najveći broj zapisa koji može
postojati na strani jedan i/ili više u vezi jedan prema
jedan, jedan prema više i više prema više?
• Da li neki uslovi moraju biti ispunjeni pre nego se
dozvoli uspostavljanje veze?
• Postoje li uslovi pod kojima veza mora da postoji?
 Dodatni uslovi koji se odnose na vezu
između entiteta
• U ovom primeru veza između entiteta Porudzbina i
NacinDostave nije obavezna samo ako su zadata
posebna uputstva.
• Porudžbina ne može biti prihvaćena ako ne važi
kreditna kartica kupca, ili je vrednost veća od kredita.
• Na dijagramu treba bar naznačiti da postoje uslovi, a
oni se mogu navesti i dokumentovati na nekom drugom
mestu.
Detaljan E-R dijagram obrade
porudžbina
 Ponovno razmatranje entiteta
• Za svaki entitet treba utvrditi sledeće:
– Vezu između entiteta i prostora problema.
– Radne procese koje generišu, koriste, menjaju ili brišu
dati entitet (CRUD).
– Druge entitete na koje utiču ili koji na njega utiču, ili od
kojih zavisi.
– Poslovna pravila i uslove koji se odnose na taj entitet.
– Atribute entiteta.
 Veza između entiteta i prostora
problema
• Entitet modeluje objekte iz prostora problema (entitet Kupac
modeluje fizičke osobe i preduzeća koja kupuju naše
proizvode).
• Ako je veza modelovana kao entitet, direktna veza sa
prostorom problema se teže otkriva.
• Neki objekti iz prostora problema modeluju se pomoću više
logičkih entiteta u modelu podataka (dokument porudžbina
predstavljen je preko 2 entiteta: Porudzbina i
StavkePorudzbine).
Radni procesi koji utiču na entitet

• U dokumentaciji entiteta treba navesti radne

procese u kojima se koriste podaci iz tog entiteta.
• Ako se kasnije promeni struktura entiteta
(obrišemo ili dodamo atribut) odmah imamo na
jednom mestu sve procese na koje bi to moglo
imati uticaja.
• U protivnom bi trebalo analizirati sve procese i
videti da li to na njih utiče.
 Interakcija između entiteta
• E-R dijagrami dovoljno dobro dokumentuju
interakciju sem u retkim slučajevima:
• Ako entiteti imaju složene interakcije koje se ne
mogu prikazati na E-R dijagramu, treba ih prikazati
u opisima entiteta u dokumentaciji.
• Ako je model složen i zahteva više dijagrama
entiteta, a neki entitet se pojavljuje na više
dijagrama onda u opisu entiteta treba navesti sve
entitete sa kojima je povezan (entiteti koji sadrže
referentne vrednosti korišćene na više mesta).
 Poslovna pravila i uslovi
• Opis uslova koji se odnose na neki entitet.

• Treba dokumentovati svaki uslov u kojem se

pominje više atributa
• Pravilo: Ne mogu biti prazna oba atributa
NačinDostave i PosebnaUputstva, mora biti
dokumentovano.
 Atributi
• Spisak atributa i njihovih domena.
• Spisak atributa sadrži:
– Sve atribute dobijene na osnovu izvornih dokumenata i
– Spoljne ključeve (ako ih ima) koji su potrebni za očuvanje
referencijalnog integriteta.
• Proveriti da li postoji bar jedan kandidat za primarni
ključ (identifikacija primeraka).
• Ako postoji, on će postati primarni ključ tabele u bazi
podataka.
 Atributi
• Primarni ključ tabele ne može imati Null vrednost,
pa možda ne postoji atribut ili kombinacija atributa
koji čine primarni ključ.
• Odabrati proizvoljan identifikator koji će se
automatski generisati (veštački primarni ključ, npr.,
auto number, u SQL Serveru Identity).
• U našem primeru za entitet Kupac potreban je takav
veštački identifikator. Zašto?
Spisak atributa entiteta Kupac
Kupac
ImeFirme: Ime
LicnoIme: Ime
Adresa1: AdresaUlice
Adresa2: AdresaUlice
Opstina: Opstina
Grad: Grad
Drzava: Drzava
PostBroj: PostanskiBroj
NivoKredita: NivoKredita
 Primarni ključ entiteta Kupac
• Problemi:
– Ako je kupac osoba onda atribut ImeFirme ima vrednost Null
– Ako je kupac preduzeće onda atribut LicnoIme ima vrednost
Null
– Posto je jedno od ova dva atributa uvek Null to ni jedan od
njih ne može biti ključ
– Dodatno moguće je dupliranje imena osoba (nije
jedinstveno)
– Čak ni kombinovanje svih atributa nije jedinstveno
• Rešenje: uvesti atribut IdKupca (veštački primarni ključ)
 Primarni ključ entiteta Kupac
• Entitetu kupac treba dati proizvoljan identifikator čak i
kada bi kombinacija imena i adrese bila jedinstvena, jer
će se previše podataka kopirati na druga mesta
(primarni ključ jednog entiteta se javlja kao spoljni ključ
u drugim entitetima).
• Kada se koriste proizvoljni identifikatori (veštački ključ)
treba obezbediti alternativni način identifikacije.
• Ne treba odbiti porudžbinu jer je kupac zaboravio svoju
šifru.
 Analiza domena
• Kada su u pitanju baze podataka za atribute se
mogu definisati posebni domeni koji mogu
bolje da opišu atribute od prostog tipa podatka.
• Atributi licnoIme i ImeFirme vuku vrednosti iz
domena Ime.
• Domen Ime se može definisati kao:
Grupa jedne ili više reči, pravilno napisanih, dužine
do 75 znakova, koje čine slova, zarez i tačka
 Analiza domena
• Domen se može definisati samo jednom, a može se
koristiti neograničen broj puta u celom sistemu (za
proizvoljan broj atributa).
• Atributi definisani nad istim domenom mogu se logički
porediti.
• Pronalaženje kupaca sa istom adresom je logično, a
poređenje imena kompanija sa šifrom kupca nije
logično iako su možda istog tipa.
 Definicija domena
• Domen je skup vrednosti iz kojeg mogu poticati
vrednosti nekog atributa.
• Moraju se odrediti sledeća 3 elementa:
– Tip podatka u domenu
– Uslove i ograničenja opsega vrednosti koje su
prihvatljive za zadati tip podatka.
– Formatiranje podataka iz domena (po potrebi).
 Biranje osnovnog tipa podatka
• Tip podatka je skraćeni opis opsega vrednosti.
• Vrednosti podatka u domenu Kolicnia su celobrojne
(tip).
• Ako se koriste baze podataka onda svaka mašina
baze podataka podržava određeni (veliki) skup
tipova podataka. Ali koja će se baza koristiti
određuje se tek pri fizičkoj realizaciji.
• Tip podatka domena može biti i drugi domen
(DatumIsporuke je tipa Datum, a Datum je opšti
domen koji smo definisali dd-mm-gggg).
 Ograničavanje opsega vrednosti

• Količina je pozitivna celobrojna vrednost.

• Može se zadati lista dozvoljenih vrednosti, tada je
domen definisan kao entitet.
• Kada domen sadrži vrlo mali broj nepromenljivih
vrednosti onda je besmisleno praviti entitet (Da, Ne),
(Tačno, Netačno).
• Entiteti se koriste za modelovanje domena koji se
moraju definisati pomoću više od jednog atributa.
 Ograničavanje opsega vrednosti

• Entiteti se koriste za modelovanje domena koji se

moraju definisati pomoću više od jednog atributa.
– Ako u entitetu Kupac ne bi postojao atribut Grad onda
domen Opstina ne može tačno definisati samo jedan
atribut.
– Opština Centar postoji i u Nišu, i u Novom sadu, i u
Sarajevu, ... (ako ne bi znali grad ne bi znali da je ta
vrednost tačna).
 Ograničavanje opsega vrednosti

• Za svaki atribut se mora odrediti da li je za njega

dozvoljena vrednost Null iako pripada nekom
domenu.
• Definisanje domena je iterativan posao. Određuju
se odmah pri formiranju liste atributa a posle se
mogu naknadno proveravati i dodavati uslovi:
– Svi datumi moraju biti posle početka rada firme,
– DatumDostave mora biti mlađi (veći) od
DatumPorudzbine itd.
 Definisanje formata

• Nije obavezno.
• Obično se odnosi na podatke tipa datuma (gggg-
mm-dd), decimalnih brojeva (broj decimala), i sl.
• Ovo se zada na jednom mestu i ne mora se
ponavljati kod svih datuma ili brojeva.
 Normalizovanje
• Ako se poštuje ova procedura: krene se od
elemenata podataka koje organizujemo u entitete,
usput eliminišemo grupe koje se ponavljaju i veze
tipa više prema više, verovatno će rezultat biti
model koji je u trećoj normalnoj formi.
• Proveriti da li svaki atribut u entitetu zavisi od
ključa, celog ključa i samo od ključa.
(Funkcionalna, potpuna i netranzitivna zavisnost)
 Pitanja za proveru znanja:
• Da li najpre treba analizirati veze ili celoviti skup
atributa?
• Zašto je važno odrediti primarni ključ i da li on uvek
postoji?
• Šta treba odrediti kada je u pitanju domen
atributa?
• U kojoj normalnoj formi će biti entiteti ako se
dosledno sprovede opisani postupak?
 Najava sledećeg časa

• Na primeru baze podataka Preduzeće pokazati

postupak normalizacije.