4 - Modeliranje

BAZE PODATAKA Predavanje 24/02/2010 4. Modeliranje podataka

http://www.riteh.hr/zav_katd_sluz/zr/nastava/bp

Prola predavanja

Uvod u baze podataka DBMS Relacijski model Relacijska algebra

Matematika definicija relacije Unijska kompatibilnost Operacije nad relacijama:

unija, presjek, razlika, Kartezijski produkt, projekcija, selekcija

Sadraj predavanja

ivotni vijek baze podataka Modeliranje podataka Model entiteti-veze (ER model) Konstrukcija ER modela

ivotni vijek baze podataka

ivotni vijek baze podatakaAnaliza zahtjeva (requirements analysis) Projektiranje

Modeliranje podataka Projektiranje logike strukture Projektiranje fizike strukture

Implementacija Testiranje Odravanje

Prikupljanje i analiza zahtjeva(requirements gathering and analysis)

kontakt sa buduim korisnicima baze podataka radi prikupljanja svih relevantnih podataka o aplikaciji

nain poslovanja, podaci koji se koriste, kako se koriste, gdje se koriste, koliko esto, koje vrste operacija itd. veze meu podacima sigurnosni zahtjevi, funkcionalnosti, itd...

prikupljeni podaci se analiziraju i sastavlja se specifikacija sustava bez potpune slike o nainu poslovanja (poslovni procesi) i dokumentiranih specifikacija projekt srlja u propast!

naruitelji/korisnici baze moraju biti ukljueni. Prikupljeni zahtjevi i dokumentirana specifikacija nakon analize moraju biti stvoreni u dogovoru sa, te odobreni od strane naruitelja.

Projektiranje baze podataka

Modeliranje podataka

... u ovom predavanju

definiranje vrste podataka i veza meu njima prema informacijama dobivenim analizom potreba. => stvaranje konceptualnog modela

Projektiranje logike strukture

izvoenje relacijskog modela takoder je potrebno provesti odreeno regrupiranje, kako e se podaci organizirati (normalizacija podataka) radi budueg efikasnijeg rada baze podataka => stvaranje logikog modela

Projektiranje fizike strukture=> stvaranje fizikog modela

Implementacija i testiranje

Implementacija:

u velikoj mjeri ovisi o odabranom DBMS i ukljuuje: stvaranje baze u DBMS prema logikom modelu razvoj potrebnih aplikacija za rad poetno punjenje baze podataka s podacima podrka korisnika nastoje se otkriti greke, kako u aplikacijama tako i u logikoj strukturi (puno gore) "fine-tuning" baze

Testiranje

Odravanje baze podataka

Za redovno odravanje baze potrebno je u prethodnim fazama definirati strategije upravljanja bazom

Koliko esto vriti backup podataka? Koji su mehanizmi provjere potrebni? Koji korisnici mogu vriti koje funkcije? Koje alate e korisnici moi koristiti za pristup podacima? Koja izvjea i koliko esto ih je potrebno dostavljati? ispravljanje manjih greaka koje su se naknadno otkrile prilagoavanje korisnicima nadogradnje koje odravaju konziztentnost podataka itd...

Uvoenje promjena i poboljavanje sustava



Obavlja se u svim fazama razvoja sustava

od analize zahtjeva do izgradnje baze podataka konceptualno modeliranje

Postupak modeliranja dijelimo na:

rezultat su najee ER dijagrami (Entity-Relationship diagram) rezultat (u relacijskoj bazi): relacije, n-torke, ... rezultat: fiziki slogovi, adresiranje

logiko modeliranje

fiziko modeliranje

Modeliranje podatakastvarni svijet (poslovni sustav) perspektiva korisnika Konceptualni model

Logiki model

perspektiva projektanta

Fiziki model

perspektiva izvoaa

Baza podataka



Ciljevi modeliranja:

dokumentiranje informacijskih zahtjeva izgradnja baze koja:

ima minimalnu redundanciju ima maksimalnu integriranost i konzistentnost podataka nema potrebe za mijenjanjem strukture izgradnjom novih aplikacija (stabilnost) lako prihvaa promjene informacijskih procesa (fleksibilnost) ima dobru iskoristivost

poveanje vrijednosti podatkovnih resursa

ER modeliranje

ER modeliranje

Model entiteti veze (entity-relationship model)

bolje: model entiteti veze atributi je sastavljeno iz entiteta, veza i atributa je slikovni prikaz sustava baze podataka je neovisno o DBMS i hardveru predstavlja konceptualni model visokog nivoa podrava korisnikovu percepciju podataka je alat za projektiranje

ER modeliranje:

ER modeliranje

Entiteti

Entitet je bilo koji objekt u sustavu koji elimo modelirati i o kojem elimo sauvati informaciju

Pojedinani objekti zovu se entiteti Skupine objekata istog tipa zovu se tipovi entiteta ili skupovi entiteta Entitet je predstavljen s pravokutnikomStudent Chenova notacija Student ostale notacije

Mogua su dva tipa entiteta: slabi i jaki

Atributi

Svi podaci vezani za pojedini entitet sadrani su u atributima Atribut je karakteristika entiteta Svaki atribut moe imati bilo koju vrijednost iz svoje domene Atribut moe:

biti jednostavan ili sloen sadravati jednu ili vie vrijednostiIme Student

Pojavljuju se unutar elipsa i vezani su za svoj entitet Atribute entiteta prikazujemo na ER modelu samo ako pridonose informativnosti modela

Veze

Tip veze je smislena veza izmeu entiteta Veze su na ER dijagramu predstavljene s linijama meu entitetima Postoji vie notacijaOriginalna Chenova notacija:

Direktor

upravlja

Zaposlenik

Alternativna notacija:

Direktor

upravlja

Zaposlenik

Red veze

Broj entiteta koji sudjeluje u vezi nazivamo red veze Binarni tip - ako su dva entiteta povezana

Direktor

upravlja

Zaposlenik

Ternarni tip ako su tri entiteta povezanaProdava prodaja Kupac Proizvod

Red veze

Mogue su naravno i n-narne veze Unarni tip veze je rekurzivna (povratna) veza Unarna veza gdje isti entitet vie puta egzistira u razliitim ulogamaupravlja

Zaposlenik

Na slici: zaposlenik upravlja zaposlenikom Ako je potrebna informacija o tome tko upravlja kime, mogli bi dodati drugi entitet, npr. poslovoa

Red veze

Mogue je i vie razliitih veza izmeu entitetaupravlja Odjel zapoljava Zaposlenik

U prikazu koji koristimo nije mogue predstaviti atribute kao dio veze. Za to trebamo druge tipove entiteta

Zamjena ternarnih veza

Kada se ternarna veza pojavi u ER modelu, mora se zamijeniti prije dovravanja modela Ponekad ju je mogue zamijeniti skupom binarnih vezaprodaja Kupac

Prodava

Proizvod

Prodava pomae

prodaja Kupac

Proizvod kupuje


Prilikom takve zamjene moe doi do gubitka informacije nije vie jasno koji je prodava prodao odreenom kupcu neki proizvod Umjesto toga, uvedemo novi entitet u centar ternarne vezeProdava prodaja Kupac Proizvod

Prodava pomae

prodaja Kupac

Proizvod kupuje


Veze su obino glagoli, pa novi entitet izvedemo iz tog glagola Veza prodati moe postati entitet prodajaProdavanapravi

Prodajazahtjeva

ukljuuje

Proizvod

Kupac

Na taj nain je prodava povezan i s kupcem i s proizvodom Isti postupak moemo primijeniti i na vezama vieg reda

Kardinalnost

Veina veza nije 1:1

npr. jedan poslovoa upravlja s vie zaposlenika

Odnos omjera meu povezanim entitetima nazivamo kardinalnost veze

Mogue kardinalnosti su:

Jedan na jedan (1:1), Jedan na vie (1:m), Vie na jedan (m:1) i Vie na vie (m:n)

Na krajevima veze se kardinalnost 1 oznaava s jednom vertikalnom crticom, dok se kardinalnost m oznaava s dvije kose crtice

Kardinalnost

Veza 1:1 mukarac moe istovremeno biti oenjen samo s jednom enom i ena moe istovremeno biti udata samo za jednog mukarca1 je oenjen 1

Mukarac

enom

Veza 1:n jedan poslovoa upravlja s vie zaposlenika, ali svaki zaposlenik ima samo jednog poslovouDirektor1 upravlja m

Zaposlenik

Kardinalnost

Veza m:1 vie studenata studira isti studij ali ih svaki student ne moe studirati vie istovremeno.

Student

m

studira

1

Studij

Veza m:n jedan nastavnik poduava vie studenata i svaki student je poduavan od strane vie nastavnikam poduava n

Nastavnik

Student

Opcionalnost vs. obaveznost

Veza moe biti opcionalna ili obavezna Ako je veza obavezna

entitet na jednom kraju veze mora biti povezan s entitetom na drugom kraju entiteti na svakom kraju veze mogu (ali ne moraju) biti povezani jedan s drugim Npr. student mora biti na nekom studiju (obaveznost) Po drugoj strani, studij moe postojati ak i prije nego ga itko upie (opcionalnost)

Ako je veza opcionalna

Opcionalnost moe biti razliita na svakom kraju veze

Opcionalnost se oznaava s nulom na onom kraju veze, koji je opcionalan

Opcionalnost vs. obaveznost

Opcionalan dio veze studij studira student je entitet student kod njega dolazi nula

Studij

je studiran od strane 0

Student

Opcionalnosti moraju biti jasno definirane zbog konzistentnosti baze

Dobivanje parametara veze

Da bi provjerili imamo li tone parametre veze, postavimo si dva pitanja: 1) Jedan studij je studiran od strane koliko studenata? Odgovor je 0 ili vie (0 moe biti prije ikakvog upisa)

To nam daje stupanj na strani entiteta student Odgovor 0 ili vie znai:

vie znai kardinalnost m (vie) 0 znai da je ta veza opcionalna

Da je odgovor 1 ili vie, veza bi bila obavezna

Studij


Student

Dobivanje parametara veze2) Jedan student studira koliko studija? Odgovor je 1

To nam daje stupanj na strani entiteta studij

Odgovor 1 oznaava kardinalnost ove veze i istovremeno znai da je veza obavezna Da je odgovor bio 0 ili 1, onda bi kardinalnost veze bila 1, ali bi bila opcionalna

Studij


Student

Redundantne veze

Neki ER dijagrami imaju redundantne veze one, koje se mogu izbaciti iz modela bez gubitka informativnosti modela

potrebno je provjeriti je li mogue razbiti petlju bez gubitka informacije Za tri entiteta povezana na nain A-B, B-C i A-C, potrebno je provjeriti je li mogue putovati od A do C preko B. Ako je mogue, onda je A-C redundantna veza

Primjer: kupac (podaci o kupcu), adresa (adresa kupca) i udaljenost (udaljenost od poduzea do adrese kupca)Kupacod posla ivi na

Adresaod posla

Udaljenost

Razbijanje n:m veza

Veza m:n u ER modelu moe biti razbijena s uvoenjem posrednikog entiteta. To se radi samo ako:

m:n veza skriva entitet rezultirajui ER dijagram bi bilo lake razumijeti

Primjer - Rent-a-car: klijenti unajmljuju vozila jedan klijent moe unajmiti vie vozila; jedno vozilo je bilo unajmljeno od strane vie razliitih klijenataKlijentm unajmljuje n

Vozilo

Vezu vie na vie moemo razbiti uvoenjem entiteta najam, koji sadri atribut datum_najmam n

Klijent

Najam

Vozilo

Konstrukcija ER modela

1. Entiteti

Prije poetka sastavljanja ER modela, potrebno je paljivo prouiti specifikacije problemske domene. Potrebno je dokumentirati bilo kakve pretpostavke.1. Identificiraj entitete zanimljive objekte u sustavu. Bolje ih je na poetku dodati vie pa kasnije odbacivati nepotrebne nego obrnuto. 2. Izbaci duplikate pobrini se da svaki entitet opisuje samo podatke svog tipa

npr. podatak o stalnom boravitu i privremenom boravitu poveemo u boravite nemoj ukljuiti sustav (domenu) kao entitet u modelu npr. ako modelira knjinicu, entiteti e biti knjige, ljudi, itd., dok knjinica nee biti entitet

2. Atributi

Popii atribute svakog entiteta sve karakteristike entiteta, koje su relevantne za primjenu u bazi (aplikaciji)3. Pobrini se da su svi entiteti zaista potrebni

moda su neki entiteti zapravo samo atributi drugih entiteta ako je tako, brii ih kao entitete i zapii kao atribute

4. Izbaci redundantne atribute one koji se pojavljuju u vie entiteta 5. Oznai primarne kljueve 6. Koji atributi jednoznano identificiraju podatke tog tipa entiteta?

Moe biti problem za neke slabe entitete

3. Veze7. Definiraj veze

Proui svaki entitet da vidi u kakvom je odnosu s ostalim entitetima Koja su ogranienja veza meu entitetima

8. Odredi kardinalnosti i opcionalosti veza

9. Izbaci redundantne veze iz modela

ER modeliranje je iterativan postupak realno je oekivati vie razvojnih verzija modela. Postoji vie rjeenja problema neka su optimalnija od drugih.

Documents

4 - Modeliranje