načrtovanje pb

PODATKOVNE BAZEModul: Načrtovanje PB©Laboratorij za podatkovne tehnologije

- 1 -

Načrtovanje PB

Pristopi k načrtovanju PB Nivojsko načrtovanje Konceptualno modeliranje Logično modeliranje Fizično modeliranje


- 2 -

Pristopi k načrtovanju PB

Obstajata dva glavna pristopa k načrtovanju podatkovne baze:– Pristop od spodaj navzgor in – Pristop od vrha navzdol.

Pristop od spodaj navzgor:– začne z atributi ter jih združuje v skupine – Tak pristop predstavlja normalizacija

Normalizacija = identifikacija potrebnih atributov in njihovih agregacij v normalizirane relacije na osnovi funkcionalnih odvisnosti.


- 3 -

Pristop z vrha navzdol

Pristop od spodaj navzgor primeren za enostavne podatkovne baze z majhnim številom atributov.

Za večje baze primeren pristop z vrha navzdol. – Na začetku podatkovni modeli z le nekaj osnovnih

entitetnih tipov in razmerij– Korakoma razgradnja na pod-entitete, povezave in

atribute– Tak pristop predstavlja uporaba tehnike Entiteta –

Razmerje (E-R).


- 4 -

Pristop znotraj navzven

Pristop znotraj navzven povezan s pristopom od spodaj navzgor– Najprej identificiramo nekaj najpomembnejših

entitetnih tipov iz domene– Korakoma dodajamo nove entitetne tipe, razmerja in

atribute


- 5 -

Pristop po delih

V praksi najbolj uporabna strategija Načrtovanje razdelimo na več lažje

obvladljivih delov:– Najprej kreiramo okvirno shemo z najpomembnejšimi

entitetnimi tipi in razmerji med njimi– Shemo razdelimo na področja (jedra so identificirani

entitetni tipi)– Za vsako področje so vključeni poznavalci področja– Načrtovanje za posamezna področja lahko poteka

vzporedno– Posamezne sklope na koncu združimo v eno shemo


- 6 -

Shema pristopa po delih

Delitev poslovne domene na področja, kreiranje

osnovne sheme

Okvirnashema

Področje 1 ...

Področnashema 1

Področnashema 2

Področnashema n

Končnashema

Področje 2 Področje n


- 7 -

Trije nivoji načrtovanja – trije modeli... Konceptualno načrtovanje – konceptualni

oz. semantični podatkovni model Logično načrtovanje – logični podatkovni

model Kreiranje fizične podatkovne baze – fizična

podatkovna baza oz. fizični podatkovni model

Prehodi med modeli in avtomatizacija prehodov


- 8 -

Trije nivoji načrtovanja – trije modeli

SUPB

Konceptualni PM

Konceptualni PM

Logični PMLogični PM

Fizični PM(skripta)


Podatkovna baza

i-CASE

ODBC

Reverse Engineering

Odločitev o PB:- Relacijska- Hierarhična- Objektna


- 9 -

Konceptualno načrtovanje

Konceptualno načrtovanje je opredelitev podatkovnih potreb oz. zahtev poslovne domene s pomočjo konceptualnega modela.

Konceptualno načrtovanje preko konceptualnega modela poskrbi za opis pomena podatkov, potrebnih za poslovno domeno.

Konceptualnega načrtovanja ne moremo avtomatizirati, za njegovo izvedbo je odgovoren analitik. Gre za prenos semantike v model.

Model je poenostavitev realnosti, pri čemer je abstrakcija realnosti poljubno natančna.

Pomembno je, da model prikazuje pomembne elemente in izpušča tiste, ki nas ne zanimajo.

Modele razvijamo zato, da bi sisteme bolje razumeli.


- 10 -

Pomen konceptualnega načrtovanja

Je najbolj kritično – napake se prenašajo naprej na naslednje modele.

Zahteva sodelovanje uporabnikov. Uporabniki so nosilci znanja o poslovni domeni, so poznavalci semantike.

Konceptualno načrtovanje mora upoštevati tudi poslovna pravila.


- 11 -

Umestitev konceptualnega načrtovanja

svet mentalni model konceptualni model logični model PB


- 12 -

Predstavitev konceptualnih modelov

Najpogosteje uporabljana tehnika za predstavitev konceptualnih podatkovnih modelov sta entitetni model (model entiteta-razmerje) ter razredni diagram. Obravnavali bomo prvega!

Nazivi, ki se uporabljajo:– Konceptualni podatkovni model– Podatkovni model– Entitetni model– ER model

Obstaja tudi razširjeni model entiteta razmerje


- 13 -

Gradniki entitetnega modela

Entitetni tip Atribut Razmerje Enolični identifikator


- 14 -

Entitetni tip – entiteta...

Entitete so posamezni primerki tipov objektov iz poslovne domene: dogodki, predmeti, osebe, pravila, dejstva

O entitetah obstaja določena predstava o tem:– kakšne lastnosti dejansko imajo– kakšne lastnosti jim moramo določiti (morajo imeti),

da bodo izpolnjevale poslanstvo entitetnega modela

Na osnovi predstave o tem in percepcije, lahko entitete klasificiramo v entitetne tipe: vse entitete, ki ustrezajo določeni predstavi, pripadajo posameznemu entitetnemu tipu.


- 15 -

Entitetni tip – entiteta...

Prevozna sredstva

Osebe

Živali

Hiše


- 16 -

Entitetni tip – entiteta

Vsak trenutek pripada posameznemu entitetnemu tipu množica entitet tega entitetnega tipa, ki jo imenujemo entitetna množica

Entitetna množica je časovno spremenljiva: entitete nastajajo, se spreminjajo in tudi izginjajo (izstopajo iz množice).

Entitetna množica je v nekem trenutku lahko tudi prazna.


- 17 -

Predstavitev entitetnega tipa

Ime entitetnega

tipa

Ime entitetnega tipa

Prostor za atribute


- 18 -

Atribut...

Entitete imajo določene lastnosti, posamezne entitete (istega entitetnega tipa) se med seboj razlikujejo po vrednosti njihovih lastnosti

Entiteta ima praviloma veliko lastnosti, le del teh lastnosti je zanimiv oz. pomemben za opazovano poslovno domeno

Lastnosti, ki so pomembne za opazovano poslovno domeno, vključimo v konceptualni model tako, da jih kot atribute določimo entiteti (entitetnemu tipu)


- 19 -

Atribut...

Govorimo lahko o več vrstah lastnosti:– Entitetna imena: naziv, ime, opis– Prave entitetne lastnosti: višina, teža, cena, vrednost– Lastnosti, ki jih določimo za potrebe poslovnih

procesov, poslovnih funkcij in poslovnih pravil: statusi

Atribut določimo za tisto lastnost, ki je za poslovno domeno pomembna


- 20 -

Atribut

Kardinalnost atributa je minimalna in maksimalna Glede na kardinalnost atributa ločimo:– Totalni atribut (1,n), kjer je n >= 1– Parcialni atribut (0,n), kjer je n >= 1– Enovrednostni atribut (m,1), kjer je m € {0,1}– Večvrednostni atribut (m,n), kjer je m € {0,1}

in n>1 Minimalna števnost 0 pomeni, da je atribut

lahko brez vrednosti (ni obvezen). Atribut pripada določenemu tipu:

numerični, znakovni,… Za večino tipov je potrebno

določiti tudi dolžino.OSEBA

(1,1)(1,3)

(1,1)

(0,n)

EMŠO

Ime

Priimek

Vzdevek


- 21 -

Predstavitev atributa

OSEBA

(1,1)(1,3)

(1,1)

(0,n)

EMŠO

Ime

Priimek

Vzdevek

OSEBA

EMŠOImePriimekVzdevek


- 22 -

Razmerja med entitetami

Entitete niso svet zase, medsebojno se povezujejo preko razmerij, povezav

Razmerje ima določen pomen Predstavitev razmerja v modelu entiteta-

razmerje je povezava. Med opazovanim parom (v splošnem

podmnožici) entitet je lahko več razmerij: OSEBA, KRAJ – stalno bivališče, začasno bivališče


- 23 -

Predstavitev razmerja...

OSEBA KRAJživi

OSEBA KRAJživi

Pomen razmerja


- 24 -

Predstavitev razmerja

OSEBA KRAJživi

OSEBA KRAJživi v ima

Vloga entitete v razmerju


- 25 -

Kardinalnost razmerja...

Kardinalnost (števnost) predstavlja število entitet entitetnega tipa, ki so v razmerju glede na pomen razmerja.

Vsaka entiteta ima svojo kardinalnost v razmerju – kardinalnost glede na vlogo. Entiteti OSEBA, POŠTA:– Ena (naključno izbrana) oseba ima stalno bivališče v

enem kraju– V enem (naključno izbranem) kraju ima stalno

bivališče več oseb


- 26 -

Kardinalnost razmerja...

A B

A B

A B

A B

A

B

povezava

(n,m)

(p,r)


- 27 -

Kardinalnost razmerja

Razmerji med entitetama OSEBA in POŠTA

OSEBA POŠTA

Stalno prebivališče

Začasno prebivališče


- 28 -

Obveznost razmerja

Obveznost pove, ali sta dve entiteti vedno v razmerju ali lahko tudi nista v razmerju: obvezno, neobvezno razmerje

Obveznost lahko obravnavamo pod okriljem števnosti, zaradi česar dodatno uvedemo števnost 0


- 29 -

Razmerje tudi opisuje lastnost entitete Razmerje tudi opisuje lastnost entitete Primer: OSEBA, POŠTA Razmerje ima atributiven značaj


- 30 -

Enolični identifikator entitete...

Enolični identifikator entitete je podmnožica lastnosti entitete (atributov in razmerij – drugih entitet), ki enolično razlikujejo posamezno instanco entitete znotraj entitetne množice

Z ozirom na to, ali tvorijo enolični identifikator entitete le atributi entitete ali pa je v enoličnem identifikatorju tudi kakšno razmerje, ločimo med močnim entitetnim tipom in šibkim entitetnim tipom


- 31 -

Enolični identifikator entitete

Imamo lahko več enoličnih identifikatorjev, vendar moramo enega izbrati – določiti

Izbrani – določeni enolični identifikator je podlaga za ključ v relacijskem modelu


- 32 -

Predstavitev enoličnega identifikatorja

OSEBA

(1,1)(1,3)

(1,1)

(0,n)

EMŠO

Ime

Priimek

Vzdevek

OSEBA

EMŠOImePriimekVzdevek


- 33 -

Močni entitetni tip Enolični identifikator sestavljajo le atributi

entitete (identifikacijski atributi) {a1, … ak} je enolični identifikator entitete A,

če ustreza naslednjim pogojem:a) a1, … ak so vsi totalni enovrednostni atributi, kar

zagotavlja, da imajo vsi identifikacijski atributi definirano natanko eno vrednost (eno dimenzijo)

b) T: V1 x …x Vk ET je totalna ali parcialna enovrednostna funkcija, kar zagotavlja, da se vsak element kartezijskega produkta vrednostnih množic, ki so območja identifikacijskih atributov, preslika v največ eno entiteto tipa A

c) Je minimalna podmnožica, ne obstaja prava podmnožica, za katero bi tudi veljal pogoj b)


- 34 -

Šibki entitetni tip Enolični identifikator ni sestavljen le iz lastnih

atributov, temveč tudi iz razmerij oz. drugih entitet v razmerju oz. njenih identifikatorjev.

{a1, … ak} IT1 .. ITn je enolični identifikator entitete A, če ustreza naslednjim pogojem:a)a1, … ak so vsi totalni enovrednostni atributi, I pa

identifikatorji entitetnih tipovb)T: V1 x …x Vkx ET1 x .. X ETn ET je totalna ali parcialna

enovrednostna funkcija, kar zagotavlja, da se vsak element kartezijskega produkta vrednostnih množic, ki so območja identifikacijskih atributov, preslika v največ eno entiteto tipa A

c) Je minimalna podmnožica, ne obstaja prava podmnožica, za katero bi tudi veljal pogoj b)


- 35 -

Generalizacija in specializacija...

Entitetni tip A s podtipoma B in C B in C pokrivata A totalno in ekskluzivno,

če velja: EB EC = EA in EB EC = {} B in C pokrivata A totalno in prekrivno, če

velja: EB EC = EA in EB EC ≠ {} B in C pokrivata A delno in ekskluzivno, če

velja: EB EC EA in EB EC = {} B in C pokrivata A delno in prekrivno, če

velja: EB EC EA in EB EC ≠ {}


- 36 -

OSEBA

MOŠKI ŽENSKA

Totalno in ekskluzivno

OSEBA

ŠTUDENT ŠPORTNIK

Delno in prekrivno

Generalizacija in specializacija

Metoda konceptualneganačrtovanja


- 37 -

Logično načrtovanje podatkovne baze... Logično modeliranje podatkovne baze

nastopi za konceptualnim modeliranjem. Osnova logičnega modela je jezik, ki je

razumljiv ciljnemu SUPB. Če izberemo relacijski SUPB, potem

govorimo o relacijskem modelu.



- 38 -

Podpora orodij CASE

SUPB

Konceptualni PM

Konceptualni PM




Podatkovna baza

i-CASE

ODBC

Reverse Engineering


Logično načrtovanje


- 39 -

Prehod iz konceptualnega v logični model Prehod iz konceptualnega v logični model

je navadno avtomatiziran s strani CASE orodij.Primer:

vrsta baze: relacijskaSUPB: Oracle

NAČRTOVANJEANALIZA

Konceptualni model

Entitetni tip

Atribut

Enolični identifikator

Povezava 1:n

Povezava m:n

Atribut / Stolpec

Relacija / Tabela

Vmesna tabela

Tuji ključ

Ključ

Relacijski model


- 40 -

Funkcionalne odvisnosti...

Relacija je model nekega stanja v svetu njena vsebina ne more biti poljubna.

Realne omejitve ne omogočajo, da bi bili odnosi v svetu kakršnikoli; možna so le določena stanja.

Odvisnosti so sredstvo, s katerim lahko v relacijskem modelu povemo, katere vrednosti relacij so veljavne in katere sploh ne morejo obstajati.

Ponovitev


- 41 -


Poznamo več vrst odvisnosti:– Funkcionalne odvisnosti (functional dependency)– Večvrednostne odvisnosti (multivalued dependency)– Stične odvisnosti (join dependency)

Obravnavali bomo funkcionalne odvisnosti; ostale bodo obravnavane v okviru postopka razširjene normalizacije (PB2, drugi semester).


- 42 -


Predpostavimo, da obstaja relacijska shema R z množico atributov, katere podmnožici sta X in Y.

V relacijski shemi R velja X Y (X funkcionalno določa Y oziroma Y je funkcionalno odvisen od X), če v nobeni relaciji, ki pripada shemi R, ne obstajata dve n-terici, ki bi se ujemali v vrednostih atributov X in se ne bi ujemali v vrednostih atributov Y.


- 43 -

Funkcionalne odvisnosti

Množico funkcionalnih odvisnosti, ki veljajo med atributi funkcionalne sheme R in v vseh njenih relacijah, označimo s F

X Y F r ( Sh(r) = R t, u (t r in u r in t.X = u.X t.Y = u.Y )

kjer

t.X, u.X, t.Y in u.Y označujejo vrednosti atributov Xoziroma Y v n-tericah t oziroma u.


- 44 -

Primeri funkcionalnih odvisnosti

Imamo relacijo s shemo Izpit( VpŠt, Priimek, Ime, ŠifraPredmeta, Datum izpita,OcenaPisno, OcenaUstno)

z naslednjim pomenom:Študent z vpisno številko VpŠt ter priimkom Priimek inimenom Ime je na DatumIzpita opravljal izpit iz

predmeta sšifro ŠifraPredmeta. Dobil je oceno OcenaPisno in

OcenaUstno.

Funkcionalne odvisnosti relacijske sheme Izpit so:F { VpŠt (Priimek, Ime), (VpŠt, ŠifraPredmeta,

DatumIzpita) (OcenaPisno, OcenaUstno) }


- 45 -

Ključi relacije...

Ker je relacija množica n-teric, so v njej vse n-terice ločene med seboj.

Za sklicevanje na posamezno n-terico ni potrebno poznati vseh vrednosti atributov n-terice, če v shemi nastopajo funkcionalne odvisnosti.

Množici atributov, ki določajo vsako n-terico, pravimo ključ relacije oziroma ključ relacijske sheme.

Ponovitev


- 46 -

Ključi relacije...

Predpostavimo, da obstaja relacijska shema z atributi A1 A2 ... An katere podmnožica je množica atributov X.

Atributi X so ključ relacijske sheme oziroma pripadajočih relacij, če sta izpolnjena naslednja dva pogoja:

(1) X A1 A2 ... An

(2) ne obstaja X’, ki bi bila prava podmnožica od X in ki bi tudi funkcionalno določala A1 A2 ... An


- 47 -

Ključi relacije...

Poznamo več vrst ključev:– Kandidat za ključ (a key candidate)– Primarni ključ (primary key)– Superključ (superkey)– Tuji ključ (foreign key)

Kandidat za ključ je vsaka podmnožica atributov relacije, ki relacijo enolično določa.


- 48 -

Ključi relacije

Primarni ključ je tisti kandidat za ključ, ki ga izberemo za shranjevanje relacij v fizični podatkovni bazi.

Superključ je vsaka množica atributov, v kateri je vsebovan ključ ključ je podmnožica superključa.

Tuji ključ je množica atributov, v okviru ene relacije, ki je enaka kandidatu za ključ neke druge ali iste relacije.


- 49 -

Primeri ključev

Šifra Naziv Zaloga

A10 Telovadni copati Nike 10

A12 Trenerka Bali 4

BC80 Moška jakna QuickSilver 1

X12 Ženska jakna QuickSilver 0

Račun Šifra artikla Količina

15/05 A10 1

15/05 X12 1

ARTIKEL

RAČUNPrimarni ključ v tabeli Artikel

Primarni ključ v tabeli Račun

Tuji ključ v tabeli Račun kaže na primarni ključ v tabeli Artikel


- 50 -

Normalizacija...

Kaj si bomo pogledali?– Namen normalizacije.– Uporaba normalizacije pri načrtovanju relacijske

podatkovne baze.– Problemi zaradi redundance podatkov v osnovnih

relacijah.– Postopek normalizacije. – Osnovne normalne oblike:

I. normalna oblika, II. Normalna oblika, III. Normalna oblika IV. Poslovna normalna oblika


- 51 -

Namen normalizacije...

Normalizacija je postopek, s katerem pridemo do množice primernih relacij, ki ustrezajo potrebam poslovne domene.

Nekaj lastnosti primernih relacij:– Relacije imajo minimalen nabor atributov zgolj

tiste, ki so potrebni za pokritje potreb poslovnega sistema;

– Atributi, ki so logično povezani, so zajeti v isti relaciji;– Med atributi relacij je minimalna redundanca vsak

atribut (razen tujih ključev) je predstavljen samo enkrat.


- 52 -

Primer

Relacija StaffBranch ima odvečne podatke.

Atribut z odvečnimi (ponavljajočimi) podatki


- 53 -

Ažurne anomalije

Relacije, ki vsebujejo odvečne podatke lahko povzročajo anomalije pri spreminjanju podatkov govorimo o ažurnih anomalijah.

Poznamo več vrst anomalij:– Anomalije pri dodajanju n-teric v relacijo– Anomalije pri brisanju n-teric iz relacije– Anomalije pri spreminjanju n-teric


- 54 -

Anomalije pri dodajanju

Primeri anomalij:– Če želimo dodati podatke o novih članih (staff) za

neko organizacijsko enoto (branch) moramo vpisati tudi vse podrobnosti o organizacijski enoti.

– Če želimo dodati podatke o novi organizacijski enoti, ki še nima nobenega člana, moramo v vsa polja , ki člane opisujejo, vpisati Null.


- 55 -

Anomalije pri brisanju

Primeri anomalij:– Če iz relacije zbrišemo n-terico, ki predstavlja

zadnjega člana v neki organizacijski enoti, zgubimo tudi podatke o tej organizacijski enoti.


- 56 -

Anomalije pri spreminjanju

Primeri anomalij:– Če želimo spremeniti vrednost nekega atributa

določene organizacijske enote (npr. naslov), moramo popraviti vse n-terice, v katerih takšna vrednost atributa nastopa.


- 57 -

Postopek normalizacije

Postopku preoblikovanja relacij v obliko, pri kateri do ažurnih anomalij ne more priti, pravimo normalizacija.

Obstaja več stopenj normalnih oblik. Obravnavali bomo:– 1NO – Prva normalna oblika– 2NO – Druga normalna oblika– 3NO – Tretja normalna oblika in– 4PNO – Četrta poslovna normalna oblika


- 58 -

1NO – prva normalna oblika

Relacija je v prvi normalni obliki, če:– Nima ponavljajočih atributov ne obstajajo atributi

ali skupine atributov, ki bi imele več vrednosti pri isti vrednosti ostalih atributov (na presečišču ene vrstice in enega stolpca je več vrednosti)

– Ima definiran primarni ključ in določene funkcionalne odvisnosti

Koraki:– Odstranimo ponavljajoče atribute– Določimo funkcionalne odvisnosti– Določimo primarni ključ


- 59 -

Primer – relacija v nenormalizirani obliki

VŠ priimek

ime pošta

kraj šifra predmeta

naziv

ocena

64010632

Bratina

Simon

4100

Kranj

200202002120033

ISTPOIPI

1088

64016209

Bizjak Tadeja

2250

Ptuj 2006020033

E1IPI

96

Indeks( VŠ, priimek, ime, pošta, kraj, ( šifra predmeta, naziv, ocena ) )

Skupina ponavljajočih se atributov.


- 60 -

Primer – pretvorba v 1NO...

Indeks( VŠ, priimek, ime, pošta, kraj, ( šifra predmeta, naziv, ocena ) )

Indeks( VŠ, priimek, ime, pošta, kraj, šifra predmeta, naziv, ocena )

Odpravimo ponavljajoče atribute

Identificiramo funkcionalne odvisnosti

F { VŠ (priimek, ime, pošta, kraj), šifra predmeta naziv, pošta kraj, (VŠ, šifra predmeta) ocena }

Določimo primarni ključ

Indeks( VŠ, priimek, ime, pošta, kraj, šifra predmeta, naziv, ocena )


- 61 -

Primer – pretvorba v 1NO

VŠ priimek

ime pošta


naziv

ocena

64010632

Bratina

Simon

4100

Kranj

20020 IS 10

64010632

Bratina

Simon

4100

Kranj

20021 TPO 8

64010632

Bratina

Simon

4100

Kranj

20033 IPI 8

64016209

Bizjak Tadeja

2250

Ptuj 20060 E1 9

64016209

Bizjak Tadeja

2250

Ptuj 20033 IPI 6

VŠ priimek

ime pošta


naziv

ocena

64010632

Bratina

Simon

4100

Kranj

200202002120033

ISTPOIPI

1088

64016209

Bizjak Tadeja

2250

Ptuj 2006020033

E1IPI

96


- 62 -

2NO – druga normalna oblika

Relacija je v drugi normalni obliki:– Če je v prvi normalni obliki in– Ne vsebuje parcialnih odvisnosti noben atribut, ki

ni del ključa, ni funkcionalno odvisen le od dela primarnega ključa, temveč od celotnega ključa

Druga normalna oblika je odvisna predvsem od ključa relacije. Relacija je avtomatsko v drugi normalni obliki, če: – Je njen primarni ključ sestavljen le iz enega atributa,– Je njen primarni ključ sestavljen iz vseh atributov

relacije ali– Je njen primarni ključ sestavljen iz vseh razen enega

atributa relacije


- 63 -


Indeks( VŠ, šifra predmeta, priimek, ime, pošta, kraj, naziv, ocena )

!

Relacijo razbijemo

Študent( VŠ, priimek, ime, pošta, kraj)Predmet( šifra predmeta, naziv)Indeks( #VŠ, #šifra predmeta, ocena)

!


- 64 -

Primer – pretvorba v 2NOVŠ priime

kime pošt

akraj šifra

predmetanaziv

ocena

64010632

Bratina

Simon

4100

Kranj

20020 IS 10

64010632

Bratina

Simon

4100

Kranj

20021 TPO 8

64010632

Bratina

Simon

4100

Kranj

20033 IPI 8

64016209

Bizjak Tadeja

2250

Ptuj 20060 E1 9

64016209

Bizjak Tadeja

2250

Ptuj 20033 IPI 6VŠ priimek

ime pošta

kraj

64010632

Bratina

Simon

4100

Kranj

64016209

Bizjak Tadeja

2250

Ptujšifra predmeta

naziv

20020 IS

20021 TPO

20033 IPI

20060 E1

20033 IPI

VŠ šifra predmeta

ocena

64010632

20020 10

64010632

20021 8

64010632

20033 8

64016209

20060 9

64016209

20033 6


- 65 -

3NO – tretja normalna oblika

Relacija je v tretji normalni obliki:– Če je v drugi normalni obliki in– Če ne vsebuje tranzitivnih funkcionalnih odvisnosti

med atributi, ki niso del primarnega ključa, ni odvisnosti.

Relacija je avtomatsko v tretji normalni obliki, če: – Je njen ključ sestavljen iz vseh atributov relacije– Je njen ključ sestavljen iz vseh razen enega atributa

relacije.


- 66 -


Študent( VŠ, priimek, ime, pošta, kraj)Predmet( šifra predmeta, naziv)Indeks( #VŠ, #šifra predmeta, ocena)

!

Študent( VŠ, priimek, ime, #pošta)Pošta(pošta, kraj)Predmet( šifra predmeta, naziv)Indeks( #VŠ, #šifra predmeta, ocena)

Relacijo razbijemo


- 67 -

Primer – pretvorba v 3NO

VŠ priimek

ime pošta

kraj

64010632

Bratina

Simon

4100

Kranj

64016209

Bizjak Tadeja

2250

Ptuj

VŠ priimek

ime pošta

64010632

Bratina

Simon

4100

64016209

Bizjak Tadeja

2250

pošta

kraj

4100

Kranj

2250

Ptuj


- 68 -

4PNO – četrta poslovna normalna oblika Relacija je v četrti poslovni normalni obliki,

če:– je v tretji normalni obliki in– v relaciji ne obstajajo atributi, ki bi bili odvisni od

vrednosti primarnega ključa.


- 69 -

Primer – pretvorba v 4PNO...

Študent( VŠ, priimek, ime, #pošta, datum plačila šolnine, rok diplome)

Za izredne študenta Za redne študenta

Študent( VŠ, priimek, ime, #pošta)Redni študent( #VŠ, rok diplome)Izredni študent( #VŠ, datum plačila šolnine)


- 70 -

Primer – pretvorba v 4PNOVŠ Priimek Ime Datum plačila

šolnineRok diplome

64010632

Bratina Simon 15.3.2005

64016209

Bizjak Tadeja 19.4.2002

64010670

Berce Marjan 12.4.2004

64620010

Mele Silvana

1.4.2005

65120987

Leban Tibor 15.7.2005

VŠ Priimek Ime

64010632

Bratina Simon

64016209

Bizjak Tadeja

64010670

Berce Marjan

64620010

Mele Silvana

65120987

Leban Tibor

VŠ Datum plačila šolnine

64016209

19.4.2002

64010670

12.4.2004VŠ Rok

diplome

64010632

15.3.2005

64620010

1.4.2005

65120987

15.7.2005


- 71 -

Uporaba nenormaliziranih relacij...

Včasih zavestno uporabljamo relacije, ki ne ustrezajo najvišjim normalnim oblikam.

Prve in druge normalne oblike nikoli ne kršimo.

Višjim normalnim oblikam se včasih odrečemo na račun doseganja boljše učinkovitosti.


- 72 -

Uporaba nenormaliziranih relacij

Primer:– Rezultat (športnik, tekmovanje, čas prvega teka,

čas drugega teka, čas skupaj)– Relacija ni v tretji normalni formi. – Čas skupaj je izpeljan atribut ni odvisen od ključa,

temveč je seštevek časov obeh tekov. – Skupen čas računamo ob vpisu v bazo, zato

izboljšamo učinkovitost pri nadaljnji obdelavi podatkov.

Metoda logičneganačrtovanja


- 73 -

Načrtovanje fizične podatkovne baze... Načrtovanje fizične PB je korak, ki sledi

logičnemu načrtovanju. Logični načrt opredeljuje “kaj”, fizični načrt

pa “kako”. Vhod v načrtovanje fizične PB so:

– Logični podatkovni model,– Relacijska shema– dokumentacija



- 74 -

Načrtovanje fizične podatkovne baze...

SUPB

Konceptualni PM

Konceptualni PM




Podatkovna baza

i-CASE

ODBC

Reverse Engineering


Načrtovanje fizične PB


- 75 -

Načrtovanje fizične podatkovne baze

Fizično načrtovanje PB opredeljuje proces, s katerim izdelamo opis implementacije PB na sekundarnem pomnilnem mediju.

Opisuje – osnovne relacije, – datotečno organizacijo, – indekse za dosego učinkovitega dostopa do

podatkov, – povezane omejitve in – varnostne mehanizme.

Metoda fizičneganačrtovanja


- 76 -

Metoda konceptualnega načrtovanja

Možni koraki konceptualnega načrtovanja:– K1.1: Identificiraj entitetne tipe– K1.2: Identificiraj povezave– K1.3: Identificiraj in z entitetnimi tipi poveži atribute– K1.4: Atributom določi domene– K1.5: Določi kandidate za ključe; izmed kandidatov

izberi primarni ključ

– K1.6: Po potrebi uporabi elemente razširjenega diagrama

entiteta – razmerje– K1.7: Preveri, če v modelu obstajajo odvečni

elementi– K1.8: Preveri, če model “zdrži” transkacije– K1.9: Preveri model z uporabnikom


- 77 -

K1.1 – Identificiraj entitetne tipe...

Na voljo različne tehnike Ena izmed tehnik je pregled uporabniških

zahtev:– Pregledamo vse omenjene samostalnike in fraze (npr. profesor, predmet, izpit, rok, datum izpita,...)

– Pozorni smo na pomembne objekte (npr. ljudje, lokacije...)

– Skušamo ločiti objekte (npr. profesor, izpit,...) od lastnosti objektov (ime, vpisna številka,...)

– Lastnosti objektov združujemo v entitetne tipe


- 78 -

K1.1 – Identificiraj entitetne tipe...

Težave:– Entitete niso vedno jasno predstavljene v

dokumentaciji Uporaba primerov, analogij, sinonimov, homonimov Uporaba konkretnih imen oseb

– Ni vedno jasno, kaj je entitetni tip, kaj povezava in kaj atribut (npr. izpit)

Načrtovanje je subjektivne narave – možnih je več (pravilnih) rešitev.

Načrt zavisi od uporabnikove presoje in izkušenj


- 79 -

K1.1 – Identificiraj entitetne tipe

Entitetne tipe je potrebno dokumentirati Primer dokumentacije:

Naziv entitetnega tipa

Opis Sinonim Število entitet

Profesor Predstavlja pedagoškega delavca, ki je nosilec enega ali več predmetov

Pedagoški delavec

Vsaka katedra ima enega ali več profesorjev

Izpitni rok Predstavlja datum, na katerega je za nek predmet in določeno ciljno skupino (letnik, smer,...) razpisan izpitni rok.

Rok, pisni izpit, kolokvij

Na leto se razpiše okrog 300 pisnih izpitov. Vsak predmet mora imeti vsaj tri roke letno

...


- 80 -

K1.2 – Identificiraj povezave...

Ko smo identificirali entitetne tipe, skušamo opredeliti vse povezave med njimi

Uporabimo lahko podoben postopek kot v K1 (pregled uporabniških zahtev):– Iščemo glagole (npr. profesor razpiše rok, študent polaga izpit, študent izbere mentorja, študent se vpiše v letnik,...)

– Zanimajo nas samo tiste povezave, ki so res potrebne (očitne povezave ali povezave, ki nas ne zanimajo z vidika hranjenja podatkov, so odveč)


- 81 -


Postopek identifikacije povezav (nadaljevanje)– Pozorni smo na povezave, ki niso binarne -

povezujejo več kot dve entiteti ali so rekurzivne. Npr. študent opravi izpit za nek predmet pri nekem profesorju.Ali, pedagoški delavec ima asistenta, ki je tudi pedagoški delavec.

– Preverimo, če smo zajeli vse povezave (načeloma lahko preverimo za vsak par entitetnih tipov, če med njima obstaja povezava) – postopek je lahko zelo potraten, zato ga ne izvajamo vedno (preverjanje modela je stvar K8)


- 82 -


Postopek identifikacije povezav (nadaljevanje)– Povezavam določimo števnost– Preverimo, če obstajajo kakšne dvoumne ali

nepopolne povezave (ang. chasm and fan tramps)Primer dvoumne povezave

1..* 1..1 1..1 1..*Profesor Katedra Laboratorij

je član vključuje

Pr1

Pr2

Pr3

K1

K2

L1

L2

L3


- 83 -

K1.2 – Identificiraj povezave....

Dvoumno povezavo odpravimo z restrukturiranjem modela

Profesor Laboratorij Katedraje član vključuje

Pr1

Pr2

Pr3

L1

L2

K1

K2

K3

1..* 1..1 1..* 1.1


- 84 -


Primer nepopolne povezave

1..1 1..* 0..1 0..*Katedra Član Oprema

ima je skrbnik

K1

K2

K3

Čl1

Čl2

O1

O2

O3Čl3

Kateri katedri pripada oprema O2?


- 85 -


Tudi nepopolno povezavo odpravimo z restrukturiranjem modela

1..1 1..* 0..1 0..*Katedra Član Oprema

ima je skrbnik

K1

K3

Čl1

Čl2

O1

O2

Čl3

1..1 1..*pripada

K2


- 86 -

K1.2 – Identificiraj povezave

Povezave je potrebno dokumentirati Primer dokumentacije:

Entitetni tip

Števnost Povezava Števnost Entitetni tip

Član 1..*1..1

PripadaJe predstojnik

1..10..1

Katedra

Laboratorij 1..* Sodi v 1..1 Katedra

...


- 87 -

K1.3 – Identificiraj atribute...

Skušamo identificirati lastnosti entitet ter povezav

Uporabimo lahko tehniko proučevanja uporabniških zahtev – iščemo samostalnike, ki predstavljajo lastnosti,

opisne vrednosti ali identifikatorje objektov

Korak določanja atributov entitetnih tipov je relativno enostaven


- 88 -


Nekaj primerov, kjer je potrebna pazljivost:– Enostavni in sestavljeni atributi (npr. naslov ulica, hišna številka, številka pošte, naziv pošte). Kaj potrebuje uporabnik?

– Eno- in več-vrednostni atributi (npr. telefonska števila domača, v služni, mobilna...

– Izpeljani atributi (npr. skupna cena računa, starost študenta,...) pogosto ne kažemo v konceptualnih modelih. Obravnavamo pri fizičnem načrtovanju.


- 89 -


Dodatna priporočila:– Če identificiramo atributi, ki navidez pripadajo več

entitetam, preverimo: Ali je možno združiti entitete (npr. asistent in profesor

združimo v pedagoški delavec); Če imajo entitete več skupnih vendar tudi svoje atribute,

razmislimo o uporabi generalizacije (npr. poleg entitetnega tipa asistent in profesor uvedemo še entitetni tip pedagoški delavec, ki prevzame vse skupne atribute.)

– Če identificiramo atribut, ki odraža povezavo (npr. atribut katedra v entitetnem tipu Profesor predstavlja povezavo z entiteto katedra):

Če povezava obstaja, potem je atribut odveč Če povezava ne obstaja, jo je potrebno dodati ter atribut

zbrisati


- 90 -

K1.3 – Identificiraj atribute

Atribute je potrebno dokumentirati:– Naziv atributa, opis, podatkovni tip, dolžina, sinonimi,

ali je atribut sestavljen (iz katerih atributov je sestavljen?), ali je atribut izpeljan (iz katerih atributov je izpeljan?),...

Primer dokumentacije:Entitetni tip

Atributi Opis Podatkovni tip

Dolžina ...

Študent VpisStImePriimek...

Vpisna številka študentaIme študentaPriimek študenta

NumberCharacterCharacter

82020

...

... ...


- 91 -

K1.4 – Atributom določi domene...

Domena je množica vrednosti, ki jih lahko zavzamejo atributi, vključeni v to domeno.

Domeni lahko določimo: – Seznam dovoljenih vrednosti– Minimalno in maksimalno vrednost– Podatkovni tip in dolžino– Dovoljene operacije nad atributom (še v raziskavi)

Primeri domen:– Barva {bela, rumena, oranžna, rdeča}– Opis elementa character 50– Starost [0..120]– EMSO number 13


- 92 -

K1.4 – Atributom določi domene

Tudi domene dokumentiramo Zapišemo naziv domene ter lastnosti oz.

pravila, ki jih domena določa.


- 93 -

K1.5 - Določi kandidate za ključe...

Za vsak entitetni tip določimo kandidate za ključ ter izberemo enega za primarni ključ.

Kandidati za ključ so minimalne podmnožice atributov, ki enolično identificirajo vsako entiteto.

Če je kandidatov več, izberemo enega, ki je primeren za primarni ključ.

Študent

EMŠOVpisStDavcnaStImePriimekDtmRoj

Primer


- 94 -

K1.5 - Določi kandidate za ključe...

Nekaj priporočil za izbiro ključa, če je več kandidatov:– Kandidat z najmanj atributi;– Kandidat, za katerega je najmanj verjetno, da se

bodo njegove vrednosti spreminjale;– Kandidat z najmanjšo dolžino znakov (za

alfanumerične kandidate);– Kandidat z najmanjšo maksimalno vrednostjo (za

numerične kandidate);– Kandidat, ki ga je najlažje uporabiti s stališča

uporabnika


- 95 -

K1.5 - Določi kandidate za ključe

Dodatna priporočila:– Imena navadno niso dober kandidat za ključ– Bodi pozoren na šibke entitetne tipe (šibkim

entitetam v okviru konceptualnega načrtovanja ne moremo določiti ključa)

Tudi primarne in alternativne ključe je potrebno dokumentirati.


- 96 -

K1.6 – uporabi elemente EER diagrama... EER – razširjen ER diagram Elementi razširjenega ER diagrama so:

– Specializacija: ugotovljamo razlike med entitetami doočenega tipa in entitetni tip razbiti na več specializiranih entitet.

– Generalizacija: ugotavljamo skupne lastnosti entitet različnih tipov in kreirati nov tip s skupnimi lastnostmi.

– Agregacija: modeliramo povezavo “je del” oziroma “ima”, s katero določimo pripadnost tipa “del” tipu “celota”.

– Kompozicija: posebna vrsta agregacije z močnim lastništvom “del” ne more obstajati brez “celote”.


- 97 -

K1.6 – uporabi elemente EER diagrama...Primer specializacije

Študent

Redni študent Izredni študent

Znak za specializacijo/generalizacijo.

Lahko tudi:


- 98 -

K1.6 – uporabi elemente EER diagrama...Primer generalizacije

Profesor Asistent

Pedagoški delavec


- 99 -

K1.6 – uporabi elemente EER diagrama...Primer agregacije

Študent Indekspripada

1..1 1..*

Agregacija povečuje semantiko modela


1..1 1..*

Navadna povezava

Znak zaagregacijo.


- 100 -

K1.6 – uporabi elemente EER diagrama...Primer kompozicije


1..1 1..*

Kompozicija povečuje semantiko modela


1..1 1..*

Navadna povezava

Znak zakompozicijo.


- 101 -

K1.6 – uporabi elemente EER diagrama Kdaj uporabiti elemente razširjenega ER

diagrama?– Elementi razširjenega diagrama povečajo semantiko

modela vendar lahko negativno vplivajo na “berljivost” modela

– Berljivost, enostavnost modela naj bo vodilo pri odločanju o uporabi naprednih modelirnih elementov (predvsem agregacija in kompozicija)


- 102 -

K1.7 - Preveri obstoj odvečnih elem.... Preverimo, če v modelu obstajajo

redundantni elementi:– Pregledamo povezava 1 – 1– Odstranimo odvečne povezave– Preverimo “časovni okvir”


- 103 -

K1.7 - Preveri obstoj odvečnih elem.... Povezave 1 – 1

– Pri identifikaciji entitetnih tipov smo morda zajeli več tipov, ki predstavljajo iste objekte (npr. Profesor, Pedagoški delavec, Asistent)

– Če taki tipi obstajajo, jih je potrebno združiti– Če so primarni ključi različni, izberemo enega

ProfesorEMŠODavcnaStImePriimekDtmRoj

AsistentEMŠODavcnaStImePriimekDtmRoj

PedagogEMŠODavcnaStImePriimekDtmRoj


- 104 -

K1.7 - Preveri obstoj odvečnih elem.... Odstrani odvečne povezave

– Povezava je odvečna, če je možno priti do iste informacije prek drugih povezav!

– Izdelati želimo minimalen podatkovni model odvečne povezave zato odstranimo.

– Zgolj pregledovanje poti med entitetnimi tipi ne zadošča (povezave imajo lahko različen pomen)


- 105 -

K1.7 - Preveri obstoj odvečnih elem.... Ali je kakšna povezava odveč?

Profesor Katedraje predstojnik

1..1 0..1

Laboratorij

pripada

1..1

1..*je član

1..1

1..*


- 106 -

K1.7 - Preveri obstoj odvečnih elem.... Ali je kakšna povezava odveč?

Profesor Katedrapripada

1..* 1..1

Laboratorij

pripada

1..1

1..*je član

1..1

1..*


- 107 -

K1.7 - Preveri obstoj odvečnih elem.... Preveri časovni okvir

– Časovni okvir povezav je lahko pomemben

– Povezava „je oče“ ni odveč! Kaj npr. če ima oče otroka iz prejšnjega zakona?

Oče Matije poročen z

0..1 0..1

Otrok

je mati

1..1

0..*je oče

0..*

1..1

?


- 108 -

K1.8 - Preveri če model zdrži transkacije... Preveriti moramo če model, ki smo ga

dobili s koraki od K1 do K7, podpira vse zahtevane transakcije.– Transakcije izvajamo ročno– Če neke transkacije ne uspemo izvesti, je model

pomanjkljiv (manjka bodisi entitetni tip, povezava ali atribut)

Možna dva pristopa:– Preverjanje opisa transakcij– Preverjanje transakcijskih poti


- 109 -

K1.8 - Preveri če model zdrži transkacije... Preverjanje opisa transakcij

– Vsako transakcijo opišemo; – Preverimo, če model zajema vse entitetne tipe,

povezave in atribute, ki jih transakcija potrebuje.


- 110 -

K1.8 - Preveri če model zdrži transkacije... Primer opisa transakcijskih zahtev

– Vnos podatkov: Vnesi podatke o študentih (npr. 24010637, Monika

Jemec,...) Vnesi podatke o predmetih (npr. 70029, Razvoj IS, Letni,...) ...

– Urejanje in brisanje podatkov: Uredi/briši podatke o študentu Uredi/briši podatke o predmetih ...

– Poizvedbe Izpiši vse študente, ki so se vpisali v določen letnik,

določene smeri, določenega programa Izpiši vse predmete, ki jih je opravil določen študent ...


- 111 -

K1.8 - Preveri če model zdrži transkacije... Preverjanje transakcijskih poti

– Transakcije preverimo na modelu – pot transakcije narišemo

– Pristop načrtovalcu omogoča: Da identificira pomanjkljivosti modela (če pot za neko

transkacijo ni možna) Da identificira dele modela, ki so transakcijsko kritični Da odkrije odvečne dele modela (deli, ki jih ne potrebuje

nobena transakcija)

Preverjanje transkacij je zamudno vendar pomembno delo!!


- 112 -

K1.8 - Preveri, če model zdrži transkacije

PrijavaprID

PredmetpredID

SmersmerID

ProgramprogID

RokrokID

ŠtudentvpisSt

IzpitstPol

ima

0..11..1

se predava na

1..*

1..*

za

1..10..*

iz

1..1

0..*

se nanaša na

1..10..*

pripada

1..1

0..*

je opravljal

1..1 0..*

a) Izpiši vse predmete, ki jih je opravil določen študent b) Izpiši vse študente, ki so se vpisali v določen letnik, določene smeri,

določenega programa

a

?b


- 113 -

K1.9 – Preveri model z uporabnikom

Na koncu model preverimo z uporabnikom Anomalije, pomanjkljivosti, napake,... lahko

vodijo v ponovitev korakov od K1 do K9. V mnogih podjetjih mora uporabnik

podpisati podatkovni model

Logičnonačrtovanje


- 114 -

Podatkovni model?

Logičnonačrtovanje

NAC_DEL

PRE_DEL

POTRDILO

ZAHTEVA

NACINPOSTA

STAT_IZPITA

IZPRASEVALEC

OBVESTILASTAT_POSSTAT_PR

NAC_IZV

PRIJAVA_U ROK_U

VRSTA_POT

ZAVOD

VSI

VRSTA_OC

VIPSMER

NAC_OC

VSI_F

VPIS

VIP_F

VAJE

STUDENT

SPP

SKUPINA

SKLEPI

ROK

PRIJAVA

PRE_PRE

PRED_PRPRED_OBC

PRED_IZB

PRED_DIFPRED_AT

PREDPOGPREDMET

PP

IZPIT

IZJEME

IZBIRNIEKVIVAL

DELNA_OC

DELAVEC

APP

a

a

a

a

a

a

a

a

aa

a

a

a

a

a

a

a

a

a

a

a a

a

a

a

a

a

a

a

b

aa

aa

aa

a

a

a

a

a

a

a

a

a

b

a

a

a

a

a

a

ab

a

a

a

a

a

b

a

b

ab

a

ab

b

a

a

bb

c

c

b

b

a

a

r r

a

a

a

a

a

a

aa

a

a

a

a

a

a

a

a

a

a

aa

a

aaa

a

a

a

a

a

a

a

a

a

a

a

a

a

a

aa

a

a

a

a

a

a

a

aa

a

a

a

a

a

a

a

a

a

aa

a a

a

aa

a

a

a a

aa

a

a

a

a

a

a

a

a

a

a

a

a

a

aa

a

a

a

a

a

a

a

a


- 115 -

Metoda logičnega načrtovanja...

Možni koraki logičnega načrtovanja:– K2.1: Za entitetne tipe kreiraj relacije– K2.2: Preveri relacije z normalizacijo– K2.3: Preveri relacije s pregledom uporabniških

transakcij– K2.4: Preveri omejitve integritete– K2.5: Preveri model z uporabnikom– K2.6: Združi lokalne modele v globalni model

(opcijsko)– K2.7: Preveri zmožnosti modela za razširitve


- 116 -

K2.1 – Za entitetne tipe kreiraj relacije... Namen

– Izdelati relacije za logični model, ki bo predstavljal entitete, povezave in atribute, ki smo jih identificirali v okviru konceptualnega modeliranja.

Ta korak je navadno avtomatiziran pretvorba iz konceptualnega v logični model je podprta s strani številnih CASE orodij.


- 117 -

K2.1 – Za entitetne tipe kreiraj relacije... Ročna pretvorba:

– Močni entitetni tipi Za vsak močan entitetni tip kreiraj relacijo, ki vključuje vse

enostavne atribute tega entitetnega tipa. Namesto sestavljenih atributov vključi njihove atribute, ki jih sestavljajo.

– Šibki entitetni tipi Za vsak šibki entitetni tip kreiraj relacijo, ki vključuje vse

enostavne atribute tega entitetnega tipa. Primarni ključ šibkega entitetnega tipa je delno ali v celoti sestavljen iz atributov, ki so ključ v entitetnih tipih, s katerimi je opazovani entitetni tip povezan. Da bi lahko določili ključ, moramo najprej pretvoriti vse povezave.

Enolični identifikator sestavljajo le atributi entitete (identifikacijski atributi)


- 118 -

Primer: močni in šibki entitetni tipi

Študent

EMŠOVpisStDavcnaStImePriimekDtmRojNaslov

Predmet

PredmetOpisStUrLetni

Izpit

DatumOcena

1..1 0..* 0..* 1..1je opravil za

šibki entitetni tip

Študent(EMŠO, VpisSt, DavcnaSt, Ime, Priimek, DtmRoj, Ulica, Mesto)Predmet(Predmet, Opis, StUr, Letni)Izpit(Datum, #VpisSt, #Predmet, Ocena)

Sestavljene atribute razbijemo


- 119 -

K2.1 – Za entitetne tipe kreiraj relacije... Ročna pretvorba (nadaljevanje):

– Povezave 1:* Za vsako povezavo 1:* prenesi ključ entitetnega tipa, ki

nastopa v povezavi na strani 1 (oče) v entitetni tip, ki nastopa v povezavi na strani * (otrok). Dobimo tuji ključ.

– Povezave 1:1 Pri števnosti 1:1 ne moremo vedno enostavno določiti

očeta in otrok. Za odločitev, ali bomo entitetna tipa, ki sta povezana s povezavo 1:1, povezali v eno relacijo ali ju predstavili z dvema, preverimo predvsem, kako je z obveznostjo povezav. Možne omejitve so: obveznost na obeh straneh, neobveznost na eni in obveznost na drugi, neobveznost na obeh straneh.


- 120 -


– Povezave 1:1 (nadaljevanje...) Obveznost na obeh straneh 1:1 povezave

– Entitetna tipa združi v eno relacijo. Za primarni ključ izberi enega izmed primarnih ključev originalnih entitetnih tipov.

Obveznost na eni strani 1:1 povezave– Entitetni tip, ki ni obvezen v povezavi, naj bo oče, entitetni

tip z obvezno povezavo pa naj bo otrok. Kopija primarnega ključa entitetnega tipa očeta se prenese na entitetni tip otroka.

Neobvezna povezava na obeh straneh 1:1 povezave– V primerih, ko sta oba entitetna tipa neobvezna, je težko

določiti očeta in otroka povezave. Ko pridobimo dovolj podatkov, določimo ključ.


- 121 -

Primer: povezave 1:*

Študent


Diploma

DatumOcena

1..1 1..*je opravil

Študent(EMŠO, VpisSt, DavcnaSt, Ime, Priimek, DtmRoj, Ulica, Mesto)Diploma(Datum, #VpisSt, Ocena)

Prenos tujega ključa v smeri ena “proti mnogo”


- 122 -

Primer: povezave 1:1

FakultetaFakultetaNaziv

Dekan

IDImePriimek

1..1 1..1vodi

Dekan(ID, Ime, Priimek, Naziv_fakultete)

Obveznost na obeh straneh: entitetna tipa predstavimo z eno relacijo; izberemo ključ


- 123 -

Primer: povezave 1:1

FakultetaFakultetaNaziv

Profesor

IDImePriimek

1..1 0..1je dekan

Fakulteta(Fakulteta, Naziv, #ID)Profesor(ID, Ime, Priimek)

Obveznost na eni strani: entitetni tip, ki igra vlogo očeta, dobi tuji ključ primarni ključdrugega entitetnega tipa v povezavi se prenese.

oče


- 124 -


– Rekurzivne povezave 1:1 Pri rekurzivnih povezavah tipa 1:1 upoštevaj pravila, ki

izhajajo iz obveznosti povezav. – Obveznost na obeh straneh: rekurzivno povezavo

predstavi z eno relacijo in dvema kopijama primarnega ključa.

– Obveznost na eni, neobveznost na drugi strani: kreiraj eno relacijo z dvema kopijama primarnega ključa ali kreiraj novo relacijo. Nova relacija naj ima samo dva atributa – kopiji primarnega ključa.

– Neobveznost na obeh straneh: kreiraj novo relacijo. Nova relacija naj ima samo dva atributa – kopiji primarnega ključa.

– Kopije primarnih ključev je v rekurzivnih povezavah potrebno ustrezno poimenovati, da lahko ločimo med njimi!


- 125 -

Primer: rekurzivne povezave

PDelavecIDImePriimekNaziv

1..1

0..*

je mentor

PDelavec(ID, Ime, Priimek, Naziv, IDmentorja)

Obveznost na eni strani: kreiramo relacijo z dvema kopijama primarnega ključa. Eden igra vlogo primarnega drugi pa tujega ključa.


- 126 -

Primer: rekurzivne povezave

PDelavecIDImePriimekNaziv

1..1

0..*

je mentor

PDelavec(ID, Ime, Priimek, Naziv)Mentor(#IDmentorja, #IDdelavca)

Obveznost na eni strani: Rekurzivno povezavo pretvorimo v relacijo. Relacija za vsakega pedagoškegadelavca pove, kdo mu je (bil) mentor.


- 127 -


– Povezave med nadtipi in podtipi Identificiraj nadtipe kot očete ter podtipe kot otroke.

Obstajajo različne možnosti, kako takšne povezave predstaviti z relacijami.

Izbira najbolj ustrezne opcije je odvisna od številnih faktorjev: izključevanje, obveznost povezav, število entitet v povezavi....


- 128 -

Primer: nadtipi, podtipi

PREVOZNO SREDSTVO

Registrska št.Datum izdelaveDatum registracijeMoč motorjaBarvaŠt. motorja

OSEBNI AVTO

Št. sedeževKilovatiVrsta motorjaPovprečna poraba

TOVORNO VOZILO

NosilnostTip

x Tip specializacije


- 129 -


– Povezave *:* Kreiraj relacijo, ki predstavlja povezavo ter vse njene

atribute. Primarne ključe entitetnih tipov, ki sta povezana s tako povezavo, vključi v novo relacijo kot tuji ključ. Tuji ključi bodo obenem tudi primarni ključi – samostojno ali v kombinaciji z drugimi atributi relacije.


- 130 -

Primer: povezave *:*

Študent


Predmet

PredmetOpisStUrLetni

0..* je opravil 0..*

Študent(EMŠO, VpisSt, DavcnaSt, Ime, Priimek, DtmRoj, Ulica, Mesto)Predmet(Predmet, Opis, StUr, Letni)Izpit(Datum, #VpisSt, #Predmet, Ocena)


- 131 -

K2.1 – Za entitetne tipe kreiraj relacije Ročna pretvorba (nadaljevanje):

– Več-vrednostni atributi Za predstavitev več-vrednostnih atributov kreiraj novo

relacijo. V novo relacijo vključi tudi ključ entitetnega tipa, iz katerega izhajajo več-vrednostni atributi. V novi relaciji predstavlja tuji ključ. Primarni ključ v novi relaciji je kombinacija tujega ključa in več-vrednostnih atributov. Če več-vrednostni atributi sami predstavljajo kandidata za ključ, potem ni potrebno, da primarni ključ zajema tudi tuji ključ.

Če je število vrednosti za večvrednostni atribut znano in ni veliko (npr. je manjše d 5), lahko tak atribut predstavimo z več atributi v relaciji. Za vsako vrednost svoj atribut.


- 132 -

Primer: večvrednostni atributi…

Študent

VpisStImePriimekDtmRojNaslovTelefon

Študent(VpisSt, Ime, Priimek, DtmRoj, Mesto, Ulica, GSM, StcTelefon)

Večvrednostni atribut: Število vrednosti za Telefon je znano, zato za vsako določimo svoj atribut v isti relaciji.


- 133 -

Primer: večvrednostni atributi…

Konferenca

IDDatumNazivKonfKrajSponzor

Konferenca(ID, Datum, NazivKonf, Kraj)Sponzor(Sponzor, Naziv)SponzorKonference(#ID, #Sponzor)

Večvrednostni atribut: Število vrednosti za atribut sponzor ni znano, zato kreiramo novi relaciji.


- 134 -

K2.2 – Preveri relacije z normalizacijo... Namen tega koraka je preveriti, če so vse

pridobljene relacije v ustrezni normalni obliki. To zagotavlja:– Da imajo relacije minimalno, vendar zadostno število

atributov za potrebe problemske domene;– Da ni odvečnih podatkov (razen za potrebe

povezovanja)

Prevedba konceptualnega modela v logični model navadno da relacije, ki ustrezajo 3NO. – Če to ne drži, so v konceptualnem modelu ali v

postopku prevedbe napake.


- 135 -

K2.2 – Preveri relacije z normalizacijo... Včasih se zdi, da normalizirane relacije ne

omogočajo zadovoljive učinkovitosti podatkovne baze.

Upoštevati je potrebno:– V normaliziranih relacijah so podatki organizirani v

skladu s funkcionalnimi odvisnostmi. – Logični podatkovni model ni dokončen. Predstavlja le,

kako načrtovalec razume pomen in naravo podatkov, potrebnih za obravnavano problemsko domeno; Specifične potrebe v zvezi z učinkovitostjo lahko zahtevajo drugačen fizični model.


- 136 -

K2.2 – Preveri relacije z normalizacijo

Upoštevati je potrebno (nadaljevanje):– Normaliziran načrt je robusten in odporen na

podatkovne anomalije.– Moderni računalniki so veliko zmogljivejši včasih je

upravičeno uporabiti rešitve, ki omogočajo enostavnejšo obdelavo na račun več procesiranja.

– Normalizacija načrtovalca prisili, da se natanko spozna z vsakim atributom relacije.

– Z normalizacijo pridemo do fleksibilnega načrta, ki ga brez težav razširimo.


- 137 -

K2.3 – Preveri relacije z vidika transakcij Podobno kot konceptualni model preverimo

tudi logični model z vidika podpore transakcij, ki jih uporabnik specificira (glej K1.8).

Če vseh transakcij ni moč izvesti ročno, smo pri pretvorbi naredili napako, ki jo je potrebno odpraviti.


- 138 -

K2.4 – Preveri omejitve integritete...

V tem koraku preverimo pravila za zagotavljanje celovitosti podatkov:– Obveznost atributov– Omejitve domen atributov– Števnost– Omejitve entitet (celovitost entitet)– Omejitve povezav (celovitost povezav)– Splošne omejitve


- 139 -

Primeri omejitev povezav


- 140 -

K2.5 – Preveri model z uporabnikom... Namen tega koraka je preveriti model z

uporabnikom ter ugotoviti, če ustreza vsem uporabniškim zahtevam.

Model lahko zajema več uporabniških pogledov. Pri pregledu lahko nastopa več uporabnikov.

Odličen način za pregled celovitosti podatkovnega modela je specifikacija podatkovnih tokov s pomočjo diagrama podatkovnih tokov.


- 141 -

Povezava podatkovni model in DFD

DFD PM


- 142 -

K2.6 – Združi lokalne modele...

Namen tega koraka je združiti vse lokalne modele v en globalni model, ki predstavlja vse uporabniške vidike podatkovne baze.

Čeprav so lokalni modeli preverjeni, lahko pri njihovem združevanju pride do prekrivanja in neskladnosti.

Globalni model preverim podobno kot smo preverjali lokalne modele.

Če pri načrtovanju nismo zajeli več uporabniških vidikov, lahko korak preskočimo.


- 143 -

K2.6 – Združi lokalne modele

Pri združevanju lokalnih modelov uporabimo naslednje korake:– K2.6.1 – Lokalne modele združi v globalni model– K2.6.2 – Preveri globalni model– K2.6.3 – Globalni model preveri z uporabniki


- 144 -

Pravila združevanja lokalnih modelov... Pravila združevanja lokalnih modelov:

– Preveri imena in vsebino relacij ter njihove kandidate za ključ.

– Preveri imena in vsebino povezav in tujih ključev.– Združi relacije z lokalnih podatkovnih modelov – Brez združevanja vključi relacije, ki so unikatne v

posameznih podatkovnih modelih.– Združi povezave in tuje ključe z lokalnih podatkovnih

modelov.


- 145 -

Pravila združevanja lokalnih modelov

Pravila združevanja lokalnih modelov (nadaljevanje):– Brez združevanja vključi povezave in tuje ključe, ki so

unikatni v posameznih podatkovnih modelih.– Preveri, če morda manjkajo relacije, povezave in tuji

ključi. – Preveri tuje ključe.– Preveri pravila za zagotavljanje celovitosti podatkov.– Nariši globalni podatkovni model.– Ažuriraj dokumentacijo.


- 146 -

PrimerPrimer uporabniškega pogleda


- 147 -

PrimerPrimer globalnega logičnega podatkovnegamodela.


- 148 -

K2.7 – Preveri možnosti za razširitve... V primeru, da so predvidene bodoče

razširitve sistema, moramo preveriti, če logični model take razširitve podpira.

Podatkovni model mora biti prilagodljiv; omogočati mora razširitve skladno z novimi zahtevami ter z minimalnim vplivom na obstoječe uporabnike.

Popolnoma odprt sistem za razširitve je težko doseči.

Pravilo agilnega načrtovanja:– Fool me once, shame on you, fool me twice, shame

on me!

Fizičnonačrtovanje


- 149 -

Metoda načrtovanja fizične PB...

Možni koraki načrtovanja fizične PB:– K3 – Pretvori logični model v jezik za ciljni SUPB

K3.1 – Izdelaj načrt osnovnih relacij K3.2 – Izdelaj načrt predstavitve izpeljanih atributov K3.3 – Izdelaj načrt splošnih omejitev

– K4 – Izdelaj načrt datotečne organizacije ter indeksov K4.1 – Analiziraj transakcije K4.2 – Izberi datotečno organizacijo K4.3 – Določi indekse K4.4 – Oceni velikost podatkovne baze

Koraka K1 in K2 se nanašata na izdelavo konceptualnega in logičnega podatkovnega modela


- 150 -

Metoda načrtovanja fizične PB...

Možni koraki načrtovanja fizične PB (nadaljevanje):– K5 – Izdelaj načrt uporabniških pogledov– K6 – Izdelaj načrt varnostnih mehanizmov– K7 – Preveri smiselnost uvedbe nadzorovane

redundance podatkov (denormalizacija)


- 151 -

K3 – Pretvorba v jezik za SUPB

Namen koraka: iz logičnega modela izdelati podatkovno shemo za ciljni SUPB.

Poznati moramo funkcionalnosti ciljnega SUPB, npr.:– Kako izdelati osnovne relacije?– Ali ciljni SUPB podpira primarne, tuje in alternativne

ključe?– Ali podpira obveznost podatkov (NOT NULL)?– Ali podpira domene?– Ali podpira pravila omejitve podatkov?– Ali podpira sprožilce (triggers) in bazne programe

(stored procedures)?


- 152 -

K3.1 – Izdelava osnovnih relacij...

Namen: določiti, kako bodo osnovne relacije predstavljene v ciljnem SUPB.

Vir podatkov je podatkovni slovar, jezik za opis pa DBDL (database definition language)

Za vsako relacijo definiramo:– Naziv relacije;– Listo osnovnih atributov;– Primarni ključ ter kjer smiselno alternativne in tuje

ključe;– Omejitve povezav.


- 153 -

K3.1 – Izdelava osnovnih relacij

V podatkovnem slovarju imamo za vsak atribut :– Domeno, ki se sestoji iz podatkovnega tipa, dolžine

in omejitev domene;– Morebitno privzeto vrednost;– Podatek o obveznosti atributa;– Podatek, ali je atribut izpeljan in če je, kako ga

izračunamo.


- 154 -

Primer opisa osnovnih relacij z DBDL


- 155 -

K3.2 – Predstavitev izpeljanih atributov... Namen: določiti, kako bodo v SUPB

predstavljeni izpeljani atributi. Preuči logični podatkovni model in

podatkovni slovar; izdelaj seznam izpeljanih atributov.

Za vsak izpeljani atribut določi:– Atribut je shranjen v podatkovni bazi– Atribut se vsakokrat posebej izračuna in se ne hrani v

podatkovni bazi.


- 156 -

K3.2 – Predstavitev izpeljanih atributov... Pri odločitvi, kako predstaviti izpeljane

atribute, upoštevaj:– “strošek” shranjevanja in vzdrževanja skladnosti

izpeljanih atributov z osnovnimi atributi, iz katerih je izpeljan;

– “strošek” vsakokratnega izračunavanja izpeljanega atributa.

Izberi stroškovno ugodnejšo rešitev.


- 157 -

Primer hranjenja izpeljanega atributa


- 158 -

K3.3 – Načrt splošnih omejitev

Namen: izdelava načrta splošnih omejitev za ciljni SUPB.

Glede podpore splošnim omejitvam obstajajo velike razlike med SUPB-ji.

Primer splošne omejitve:

CONSTRAINT StaffNotHandlingTooMuchCHECK (NOT EXISTS (SELECT staffNo

FROM PropertyForRent GROUP BY staffNo HAVING COUNT(*) > 100))

Pomen omejitve: nihče od zaposlenih ne sme skrbeti za več kot 100 nepremičnin


- 159 -

K4 – Datotečna organizacija in indeksi Namen: izbrati optimalno datotečno

organizacijo za shranjevanje osnovnih relacij ter potrebne indekse za doseganje ustrezne učinkovitosti.

Načrtovalec mora dobro poznati, kakšne strukture in organizacije SUPB podpira ter kako deluje.

Ključnega pomena so uporabniške zahteve v zvezi z želeno/pričakovano učinkovitostjo transakcij.

Med SUPB-ji velike razlike.


- 160 -

K4.1 – Analiza transakcij...

Namen: razumeti namen transakcij, ki bodo tekle na SUPB ter analizirati tiste, ki so najpomembnejše.

Poskušaj določiti kriterije učinkovitosti:– Pogoste transakcije, ki imajo velik vpliv na

učinkovitost;– Transakcije, ki so kritičnega pomena za poslovanje;– Pričakovana obdobja (v dnevu/ tednu), ko bo SUPB

najbolj obremenjen (peak load).

Preveri tudi:– Atribute, ki jih transakcije spreminjajo– “Iskalne” pogoje v transakcijah...


- 161 -


Pogosto ni moč analizirati vseh transakcij. Pregledamo zgolj najpomembnejše.

Za identifikacijo najpomembnejših transakcij lahko uporabimo:– Matriko transakcija/relacija, ki kaže, katere relacije se

v transakcijah uporabljajo.– Diagram uporabe transakcij, ki kaže, katere

transakcije bodo potencialno zelo frekventno izvajane.


- 162 -


Možen pristop k obravnavi potencialno problematičnih delov modela:– Izdelamo matriko povezav transakcija/relacija,– Ugotovimo, katere relacije se najpogosteje

uporabljajo v transakcijah,– Analiziramo, kateri podatki se uporabljajo v

transakcijah, ki te relacije uporabljajo.


- 163 -

Primer matrike transakcija/relacija

F: Identify the total number of properties assigned to each member of staff at a given branch.

Dodatno lahko zapišemo številooperacij na časovno enoto


- 164 -

Primer diagrama uporabe transakcij

V specifikaciji zahtev je ocenjeno:• 100.000 nepremičnin;• 2.000 zaposlenih v 100 agencijah;• Vsaka agencija ima od 1.000 do 3.000 nepremičnin


- 165 -

Obrazec za podrobno analizo transakcij


- 166 -

K4.2 – Izbira datotečne organizacije

Namen: izbrati učinkovito datotečno organizacijo za vse osnovne relacije.

Datotečne organizacije:– Kopica (Heap), – Hash, – Metoda indeksiranega zaporednega dostopa

(Indexed Sequential Access Method - ISAM), – Drevo B+-– Gruča (Cluster).

Nekateri SUPB-ji ne podpirajo vseh datotečnih organizacij.


- 167 -

K4.3 – Izbira indeksov...

Namen: ugotoviti, ali lahko z dodatnimi indeksi povečamo učinkovitost sistema.

Možen pristop:– Zapise pustimo neurejene.– Izdelamo toliko sekundarnih indeksov, kolikor je

potrebno.

Sekundarni indeks = indeks po atributu, ki ni obenem tudi atribut, po katerem je urejena relacija


- 168 -


Alternativni pristop– Zapise uredimo po primarnem ključu ali po indeksu

gruče. V tem primeru kot atribut za sortiranje izberemo:

Atribut, ki se največkrat uporablja za povezovanja ali Atribut, ki se najpogosteje uporablja za dostop do

podatkov v relaciji. Če je izbrani atribut za sortiranje primarni ključ, potem gre

za primarni indeks sicer za indeks gruče.– Relacija ima lahko primarni indeks ali indeks gruče

Primarni indeks = indeks po primarnem ključu, po katerem je urejena relacija.Vsak zapis ima svojo vrednost.

Indeks gruče = indeks po atributu, ki je obenem tudi atribut, po katerem je urejena relacija, ni pa primarni ključ. Ključ ni unikaten!


- 169 -


Sekundarni indeksi so način, kako omogočiti učinkovito iskanje s pomočjo dodatnih ključev.

Pri določanju sekundarnih indeksov upoštevamo:– Povečanje učinkovitosti (predvsem pri iskanju po PB)– Dodatno delo, ki ga mora sistem opravljati za

vzdrževanje indeksov. To vključuje: Dodajanje zapisa v vsak sekundarni indeks, kadarkoli

dodamo nek zapis v osnovno relacijo Spreminjanje sekundarnega indeksa vsakokrat, ko se

osnovna relacija spremeni Povečanje porabe prostora v sekundarnem pomnilniku Povečanje časovnega obsega za optimizacijo poizvedb

zaradi preverjanja vseh sekundarnih indeksov.


- 170 -


Nekaj smernic za uporabo sekundarnih indeksov:– Ne indeksiraj majhnih relacij. – Če datoteka ni urejena po primarnem ključu, potem

kreiraj indeks na osnovi primarnega ključa. – Če je tuji ključ pogosto v uporabi, dodaj sekundarni

indeks na tuji ključ. – Sekundarni indeks dodaj vsakemu atributu, ki se

pogosto uporablja kot sekundarni ključ.– Sekundarne indekse dodaj atributom, ki nastopajo v

pogojih za selekcijo ali stik: ORDER BY; GROUP BY ali v drugih operacijah, ki vključujejo sortiranje (npr. UNION ali DISTINCT).


- 171 -

K4.3 – Izbira indeksov

Nekaj smernic za uporabo sekundarnih indeksov: (nadaljevanje):– Dodaj sekundarni indeks atributom, ki nastopajo v

vgrajenih funkcijah;– Izogibaj se indeksiranju atributov, ki se pogosto

spreminjajo.– Izogibaj se indeksiranju atributov v relacijah, nad

katerimi se bodo pogosto izvajale poizvedbe, ki bodo vključevale večji del zapisov.

– Izogibaj se indeksiranju atributov, ki so predstavljeni z daljšimi stringi.


- 172 -

K4.4 – Ocena velikosti podatkovne baze Namen: oceniti, koliko prostora v

sekundarnem pomnilniku zahteva načrtovana podatkovna baza.

Ocena je odvisna – od velikosti in števila zapisov ter– od ciljnega SUPB.

Primer: ocena velikosti podatkovne baze s pomočjo orodja PowerDesigner.


- 173 -

K5 – Načrt uporabniških pogledov

Namen: izdelati načrt uporabniških pogledov, ki so bili opredeljeni v okviru zajema uporabniških zahtev.

Uporabimo mehanizem pogledov (view). Pogled je navidezna relacija, ki fizično ne

obstaja v PB, temveč se vsakokratno kreira s pomočjo poizvedbe.


- 174 -

Primer pogleda

create or replace view OBREMENITEV asSelect PMET.PEDAGOG as Predavatelj,

(PDG.PRIIMEK + PDG.IME) as Naziv_predavatelja, count(*) as Stevilo_Predmetov, sum(PMET.STUR) as Stevilo_ur_tedensko

from PREDMET as PMET, PEDAGOŠKI DELAVEC as PDGwhere PMET.NOSILEC = PDG.PEDAGOGgroup by PMET.NOSILEC, (PDG.PRIIMEK + PDG.IME);

Pedagoški delavecPedagog <pk>Vrsta PD <fk>Laboratorij <fk>ImePriimekStatus <fk>

Predmet

Predmet <pk>Smer <fk>Nosilec <fk>Asistent <fk>NazivStUr

Nosilec = Pedagog

Asistent = Pedagog

Obremenitev

Predavatelj Naziv_predavateljaStevilo_PredmetovStevilo_ur_tedensko


- 175 -

K6 – Načrt varnostnih mehanizmov

Namen: izdelati načrt varnostnih mehanizmov skladno z zahtevami naročnika.

SUPB-ji tipično podpirajo dve vrsti varnosti:– Sistemsko varnost: varnost dostopa in uporabe

podatkovne baze (navadno zagotovljeno s pomočjo uporabniških imen in gesel);

– Podatkovno varnost: varnost uporabe podatkov – kdo lahko uporablja določene relacije ter kako.

Med SUPB-ji so velike razlike v mehanizmih, ki jih imajo na voljo za dosego varnosti.


- 176 -

K7 – Uvedba nadzorovane redundance... Namen: ugotoviti, ali je smiselno dopustiti

določeno mero redundance (denormalizacija) ter tako izboljšati učinkovitost.

Rezultat normalizacije je načrt, ki je po strukturi konsistenten ter minimalen.

Včasih normalizirane relacije ne dajo zadovoljive učinkovitosti.

Razmislimo, ali se zavoljo izboljšanja učinkovitosti odpovemo določenim koristim, ki jih prinaša normalizacija.


- 177 -

K7 – Uvedba nadzorovane redundance... Upoštevamo tudi:

– Implementacija denormaliziranih relacij je težja;– Z denormalizacijo velikokrat zgubimo na

prilagodljivosti modela; – Denormalizacija navadno pospeši poizvedbe, vendar

upočasni spreminjanje podatkov.


- 178 -

K7 – Uvedba nadzorovane redundance... Denormalizacija:

– Denormaliacija se nanaša na dopolnitev relacijske sheme, tako da eni ali več relacij znižamo stopnjo normalne oblike (npr. 3NO 2NO).

– Nanaša se tudi na primere, ko dve normalizirani relaciji združimo v eno, ki je še vedno normalizirana, vendar zaradi združitve vsebuje več nedefiniranih vrednosti (NULL).(4PNO 3NO).


- 179 -

K7 – Uvedba nadzorovane redundance... Koraki denormalizacije:

– K7.1 – združevanje 1:1 povezav– K7.2 – Podvajanje neosnovnih atributov v povezavah

1:* za zmanjšanje potrebnih stikov.– K7.3 – Podvajanje tujih ključev v 1:* povezavah za

zmanjšanje potrebnih stikov.– K7.4 – Podvajanje atributov v *:* povezavah za

zmanjšanje potrebnih stikov.– K7.5 – Uvedba ponavljajočih skupin atributov– K7.6 – Kreiranje tabel, ki predstavljajo izvleček

osnovne tabele.– K7.7 – Razbitje relacij.


- 180 -

Primer normaliziranega modela


- 181 -

Primeri relacij


- 182 -

K7.1 – Združevanje 1:1 povezav

Če podatke, ki so v različnih relacijah obravnavamo skupaj, je združitev primerna.


- 183 -

K7.2 – Podvajanje neosnovnih atributov

Ko dostopamo do podatkov o nepremičninah, nas v večini primerov zanima tudi ime lastnika (IName)


- 184 -

“Lookup Tabele”...

LookUp tabele se sestoje zgolj iz šifre in naziva. Prednosti uporabe LookUp tabel so mnoge. Vseeno obstajajo primeri, ko je smiselno (LookUp tabele ukiniti in) podatke podvajati v osnovnih relacijah. Taki primeri so:• Ko se do LookUp tabele frekventno dostopa • Ko so LookUp tabele uporabljene v kritičnih poizvedbah• Ko je majhna verjetnost, da se bodo po vrednosti spreminjale


- 185 -

“Lookup tabele”


- 186 -

K7.3 - Podvajanje tujih ključev


- 187 -

K7.4 - Podvajanje atributov v povez. *:*


- 188 -

K7.5 - Uvedba ponavljajočih skupin


- 189 -

K7.6 – Uporaba izvlečkov

Številne poizvedbe in poročila zahtevajo dostop do več osnovnih relacij ter kompleksne povezave med njimi.

Z namenom izboljšanja učinkovitosti je v določenih primerih smiselno uvesti novo denormalizirano relacijo, ki vsebuje podatke z več osnovnih relacij.


- 190 -

K7.7 – Razbitje relacij

Za povečanje učinkovitosti nad relacijami z zelo velikim številom n-teric uporabimo pristop, kjer relacijo razbijemo na manjše dele - particije.

Dva načina delitve sta: – Horizontalni in – Vertikalni.


- 191 -

Prednosti razbitja relacije na particije

Uporaba particioniranja prinaša številne prednosti:– Boljša porazdelitev vnosa (load balancing)– Večja učinkovitosti (manj podatkov za obdelavo,

paralelnost izvajanja,...)– Boljša razpoložljivost – Boljša obnovljivost– Več možnosti za zagotavljanje varnosti


- 192 -

Slabosti razbitja relacije na particije

Particioniranje ima tudi slabosti:– Kompleksnost (particije niso vedno transparentne za

uporabnike...)– Slabša učinkovitost (pri poizvedbah, kjer je potrebno

poizvedovati po več particijah, je učinkovitost slabša)– Podvajanje podatkov (pri vertikalnem particioniranju)


- 193 -

Primer – particije v SUPB Oracle

CREATE TABLE ArchivedPropertyForRentPartition(propertyNo VARCHAR2(5) NOT NULL,street VARCHAR2(25) NOT NULL,...PRIMARY KEY (propertyNo),FOREIGN KEY (ownerNo) REFERENCES PrivateOwner(ownerNo),...

PARTITION BY HASH (branchNo) (PARTITION b1 TABLESPACE TB01,PARTITION b2 TABLESPACE TB02,...);

načrtovanje pb

Documents