25.05.2010_NOMINALIZACIJA

Postopek s katerim ugotavljamo če smo relacije pravilno oblikovali.

Če ja:

Ni redundance podatke

Ne bo prišlo do težav pri brisanju, vnašanju podatkov v bazo

4 stopnje normalizacije

n      Kaj si bomo pogledali?

n      Namen normalizacije.

n      Uporaba normalizacije pri načrtovanju relacijske podatkovne baze.

n      Problemi zaradi redundance podatkov v osnovnih relacijah.

n      Postopek normalizacije.

n      Osnovne normalne oblike:

n      I. normalna oblika,

n      II. Normalna oblika,

n      III. Normalna oblika

n      IV. Poslovna normalna oblika

Primeri težav/anomalij : glej prosojnice!

• 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

Anomalije pri dodjanju:

–        Č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.

–        Če iz relacije zbrišemo n-terico, ki predstavlja zadnjega člana v neki organizacijski enoti, zgubimo tudi podatke o tej organizacijski enoti.

–        Če želimo spremeniti vrednost nekega atributa določene organizacijske enote (npr. naslov), moramo popraviti vse
n-terice, v katerih takšna vrednost atributa nastopa.

Kako preprečimo anomalije?

Z normalizacijo.

• 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

1. normalna oblika (1NO):

-zahtevamo da ni ponovljajočih skupin atributov

-določimo funkcionalne odvisnosti

- da je definiran ključ

Postopek:

• Koraki:

–        Odstranimo ponavljajoče atribute

–        Določimo funkcionalne odvisnosti

–        Določimo primarni ključ

Primer:

F==množica vseh funkcionalnih odvisnosti

Ključ je množica atributov, ki določa vse ostale atribute. (vpisna št + šifra predmeta)

2. normalna oblika (2NO)

- relacija mora biti v 1NO

- ne sme vsebovati parcialnih odvisnosti

(noben atribut, ki ni del ključa, ni funkcionalno odvisen le od dela primarnega ključa, temveč od celotnega ključa)

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

3. normalna oblika (3NO)

-relacija mora biti v 2NO

- ne vsebuje transitivnih normalnih odvisnosti

Uporabimo lahko dekompozicijo.

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

4 poslovna normalna oblika 4PNO

je v tretji normalni obliki

v relaciji ne obstajajo atributi, ki bi bili odvisni od vrednosti primarnega ključa

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.

FIZIČNO MODELIRANJE

• 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

Metoda logičnega načrtovanja...

• Možni koraki: 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

• 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

Ročna pretvorba: močni + šibki entitetni tipi

Povezave:    1 : *   + 1 : 1

Če je obveznost na obeh straneh 1:1 povezave potem lahko združimo.

Povezava, ki ni obvezna na obeh straneh. Obvezno entiteto vzamemo kot osnovo in njen ključ prenesemo še v drugo smer.

Rekurzivne povezave: problematične, rezultat prenašanja ključev je lahko nerazumljiv.

Definiramo še en ID. Genaerator kar podvoji oznako (t.j. ključ) zato ga ponavadi preimenujemo.

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....

Povezave * : *

Potrebujemo vmesno relacijo.

Več-vrednostni atributi:

Za njih moramo kreirati novo relacijo. (Npr. Telefon je GSM, stac... Se omejimo. Poznamo končno število.)

Če ne vemo koliko je končnih vrednosti  naredimo namesto atributa nov entitetni tip.

Pravila združevanja lokalnih modelov:

• 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.
• 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. 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.

Metoda načrtovanja fizične PB....

Do sedaj smo imeli le modele od tu naprej pa kreiramo fizično bazo

Odločamo o tem:

-kakšne so osnovne relacije

-datotečna organizacija

- kako bomo imeli indekse definirane ...

2. koraka:

k3 + k4

K3:Pretvorimo fizični model v jezik ciljnega SUPBja

K4: Izdelamo načrt datotečne organizacije in indeksov

Podrobnosti: glej ppt!!!

Osnovni vir za kreiranje podatkov je katalog. J

-podatkovni slovar: podatki glej ppt!!!

Predstavitev izpeljanih atributov:

Določiti moramo ali je shranjen v fizični bazi ali ne. Da se jih izračunat. Kaj je večji časovni strošek?

Primer hranjenja izpeljanega atributa

......

Načrt splošnih omejitev....Jih definiramo kot je pač mogoče.

Datotečna organizacija in indeksi ...

Namen je izbrati optimalno datotečno organizacijo.

Analiza transakcij: previrjamo katere so transakcije ki vplivajo na učinkovitost....Pregledamo zgolj najpomembnejše. Naredimo matriko transakcija/relacija in nato diagram transakcij.

Izbira datotečne organizacije....kopica, hash tabela, kakšni bodo indeksi...

Izbira indeksov... à smernice za uporabo sek. Indeksov

Ocena velikosti PB....

Načrt varnostnih mehanizmov: sistemska + podatkovna varnost ....

Uvedba nadzorovane redundance...

Nekaj pravil denormalizacije...

• 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.

»Lookup Tabele« - so najmanjši šifranti imajo zgolj ime in ID.

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

Uporaba izvlečkov....Za poizvedbe ki zahtevajo dostop do več relacij in povezave med njimi zahtevamo da dostopajo do njih bolj hitro.

Razbitje relacij...Relacije ki so zelo velike lahko razbijemo na particije. 2 načina: horizontalni + vertikalni.

Povečevanje učinkovitosti na račun paralerizma.

Prednosti razbitja relacij na particije:

–         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

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)

Vpeljujemo v kontroliranem načinu