Bazy danych 1

Bazy danych 1
Wykład 6
Metodologia projektowania baz danych
(projektowanie logiczne - Normalizacja)
Projektowanie logiczne –
przegląd krok po kroku
1.
2.
3.
4.
5.
6.
Usuń własności niekompatybilne z modelem
relacyjnym
Wyznacz relacje dla logicznego modelu danych
Wykonaj normalizację relacji
Sprawdź, czy relacje umoŜliwiają realizacje transakcji.
Wyznacz więzy integralności.
Omów logiczny model danych z uŜytkownikiem.
Projektowanie logiczne
(krok 2 - przypomnienie)
2.
Wyznacz relacje dla logicznego modelu danych
Relacje będziemy opisywać za pomocą języka definiowania bazy
danych DDL (DataBase Definition Language)
Definicja (uproszczona) relacji w DDL zawiera:
nazwę relacji (w liczbie mnogiej),
ujętą w nawiasy listę prostych atrybutów relacji, klucz główny,
wszystkie klucze alternatywne i obce,
nazwę relacji zawierającą wskazany klucz obcy jako klucz
główny
listę atrybutów pochodnych wraz z wyraŜeniami definiującymi
sposób wyliczenia ich wartości.
Projektowanie logiczne
(krok 2 - przypomnienie)
1.
Dla kaŜdej encji tworzymy schemat relacji (reprezentacją
relacji jest tabela). Najczęściej nazwa relacji jest taka
sama jak nazwa encji, tylko w liczbie mnogiej ze względu
na to, ze relacja zawiera wiele wystąpień obiektu.
2.
Atrybuty encji stają się atrybutami w schemacie relacji.
Atrybuty odpowiadające kluczom głównym stają się
kluczami głównymi relacji. Atrybuty opcjonalne stają się
kolumnami o dopuszczalnych wartościach NULL, atrybuty
obligatoryjne stają się kolumnami NOT NULL.
3.
Sposób tworzenia kluczy obcych zaleŜy od liczności
(krotności) oraz uczestnictwa encji w związku.
Projektowanie logiczne
(krok 2 - przypomnienie)
1.
W przypadku związków „jeden do jeden” najczęściej
tworzymy jedną relację zawierająca atrybuty obu encji
2.
W przypadku związków „jeden do wiele” najczęściej do
schematu do schematu po stronie wiele wstawiamy jako
dodatkowy atrybut klucz główny z relacji po stronie
jeden.
3.
W przypadku związków „wiele do wiele” związek ten
reprezentujemy dodatkową relacją , który zawiera dwa
klucze obce – związek reprezentujemy dodatkową
relacją, który zawiera dwa klucze obce – klucze główne z
relacji po obu stronach związku (oraz atrybuty związku).
Normalizacja (krok 3)
Aby uniknąć w bazie redundancji (powtórzeń) i
związanych z nią anomalii róŜnego typu,
przeprowadza się normalizacje relacji
wchodzących w skład bazy.
6
ZaleŜność funkcyjna
Niech R będzie schematem relacji i X,Y⊆R
Definicja
Zbiór Y jest w zaleŜności funkcyjnej względem
zbioru X (X→Y) wtw, gdy dla kaŜdej relacji o
schemacie R wartości atrybutów ze zbioru X
jednoznacznie wyznaczają wartości atrybutów ze
zbioru Y.
7
ZaleŜność funkcyjna - przykład
Niech schemat relacji R określa rozkład zajęć w
szkole. Ma on następujące atrybuty:
N (nauczyciel),G (godzina),S (sala),K (klasa),P (przedmiot).
KaŜda z krotek relacji r oznacza, Ŝe:
„Nauczyciel N wykładający przedmiot P prowadzi zajęcia o godzinie G w
sali S z klasą K”
Dla tego schematu określamy następujące zaleŜności
funkcyjne:
dany nauczyciel o danej godzinie prowadzi zajęcia
tylko z jedną klasą - NG→K
o danej godzinie w danej sali znajduje się tylko
jeden nauczyciel - GS→N
8
ZaleŜność funkcyjna
Sformułowanie zaleŜności funkcyjnych oznacza
ustalenie pewnych związków między atrybutami
odzwierciedlających związki między odpowiednimi
obiektami w świecie rzeczywistym.
Wybór zaleŜności funkcyjnych nie pozostaje bez
wpływu na organizację danych. Np.. ustalenie zaleŜności
N→P oznacza, Ŝe Ŝaden nauczyciel nie będzie mógł
wykładać kilku przedmiotów.
9
Klucz relacji
Definicja
Zbiór atrybutów X tworzy klucz, gdy:
wszystkie pozostałe atrybuty są funkcyjnie zaleŜne od
atrybutów X; jest to minimalny taki zbiór, tzn. nie
istnieje podzbiór właściwy zbioru X wyznaczający
funkcyjnie pozostałe atrybuty relacji.
10
Klucz relacji
Niech F będzie zbiorem zaleŜności funkcyjnych dla
schematu relacji R.
Definicja
ZaleŜność funkcyjna X→Y wynika logicznie ze zbioru
zaleŜności F (F |= X→Y), jeśli kaŜda relacja o
schemacie R spełniająca wszystkie zaleŜności
funkcyjne z F spełnia równieŜ zaleŜność X→Y.
11
Domknięcie zbioru zaleŜności
Definicja
Domknięciem F+ zbioru F zaleŜności funkcyjnych dla
schematu relacji R nazywamy zbiór wszystkich
zaleŜności funkcyjnych wynikających logicznie ze
zbioru F.
12
ZaleŜności trywialne
Definicja
ZaleŜność funkcyjna X→Y jest
trywialna, gdy Y⊆X,
nietrywialna, gdy Y∩X≠∅ i ¬Y⊆X,
13
Rozkład schematu relacji
ZaleŜność od klucza jest jedyną „zdrową” zaleŜnością funkcyjną i
najlepiej by było, Ŝeby kaŜda relacja reprezentowała tylko jedną
taką zaleŜność funkcyjną.
ZaleŜność nie od klucza wprowadza wewnętrzną zaleŜność
między atrybutami, moŜliwość przewidywania wartości jednych
atrybutów przez inne, co oznacza redundancję.
Usunięcie z relacji anomalii i redundancji odbywa się poprzez
podział (rozkład) relacji na kilka nowych.
14
Rozkład schematu relacji
Definicja
Rozkładem schematu relacji R nazywamy rodzinę
{Ri}i∈{1,...,k} podzbiorów R taką, Ŝe R=R1∪...∪Rk.
Krotki relacji o schemacie Ri otrzymujemy poprzez
rzutowanie relacji o schemacie R na zbiór atrybutów
Ri: ri = ΠRi(r)
Rozkład schematu nie moŜe być byle jaki, powinien
on być poprawny, tzn. zachowywać informację i
zaleŜności funkcyjne wyjściowego schematu.
Rozkład odwracalny
(bezstratny)
Definicja
Rozkład R=Q∪S jest odwracalny względem F wtw
gdy kaŜda relacja o schemacie R i spełniająca
zaleŜności z F jest złączeniem naturalnym swoich
rzutów na Q i S
16
Rozkład zachowujący zaleŜności funkcyjne
Definicja
Rozkład R=Q∪S zachowuje zbiór zaleŜności F, jeśli
wszystkie zaleŜności naleŜące do F wynikają logicznie
z sumy wszystkich zaleŜności naleŜących do rzutów
zbioru F na Q i S.
17
Postacie normalne
Pojęcie postaci normalnej wprowadził Codd.
Zaproponował on trzy postacie normalne: pierwszą
(1NF), drugą (2NF) i trzecią (3NF). Kolejnymi
postaciami normalnymi są postać normalna
Boyce’a-Codda (BCNF), czwarta postać normalne
(4NF) i złączeniowa postać normalna (5NF).
Najczęściej najbardziej poŜądaną jest postać
normalna Boyce’a-Codda.
18
Postać Boyce’a-Codda
Definicja
Schemat relacji jest w BCNF wtw, gdy dla kaŜdej
zaleŜności X→A∈F+ zachodzi jeden z przypadków:
A∈X (czyli jest to zaleŜność trywialna)
X jest nadkluczem
Jeśli schemat jest w BCNF, nie ma redundancji, tzn.
nie moŜna przewidzieć jednych wartości w oparciu o
inne.
19
Postać Boyce’a-Codda
Przykład.
Niech R = {M (miasto), U (ulica), K (kod)} i
F = {MU→K, K→M}.
Schemat nie jest w BCNF, gdyŜ są dwa klucze: {M, U} i
{K, U} i nie są spełnione warunki definicji dla
zaleŜności K→M (K nie jest nadkluczem).
Twierdzenie
KaŜdy schemat albo jest w BCNF albo daje się
rozłoŜyć na sumę schematów relacji w BCNF z
zachowaniem informacji (ale niekoniecznie z
zachowaniem zaleŜności).
20
Trzecia postać normalna
Definicja
Schemat relacji jest w 3NF wtw, gdy dla kaŜdej
zaleŜności X→A∈F+ zachodzi jeden z przypadków:
A∈X (zaleŜność trywialna),
X jest nadkluczem,
A jest atrybutem kluczowym (naleŜy do co najmniej
jednego klucza).
21
Trzecia postać normalna
Uwaga: Schemat relacji w BCNF jest w 3NF, ale nie
odwrotnie
Przykład. Niech R = {M (miasto), U (ulica), K (kod)} i
F = {MU→K, K→M}. Są dwa klucze: {M,U} i {K,U}.
Schemat jest w 3NF ({M, U} jest nadkluczem a M jest
atrybutem kluczowym).
Twierdzenie
KaŜdy schemat relacji daje się rozłoŜyć na sumę
schematów relacji w 3NF z zachowaniem informacji i
zaleŜności funkcyjnych.
22
Druga postać normalna
Definicja
ZaleŜność funkcyjna X→A jest zaleŜnością częściową, gdy
X jest właściwym podzbiorem pewnego klucza.
Definicja
ZaleŜność funkcyjna X→A jest zaleŜnością przechodnią,
gdy X nie jest właściwym podzbiorem Ŝadnego klucza.
Definicja
Schemat relacji jest w 2NF wtw, gdy nie zawiera
zaleŜności częściowych.
23
Druga postać normalna
Przykład. Schemat relacji w BCNF i 3NF jest w 2NF.
Przykład. Niech R={A, B, C, D} i F={AB→C, AC→D}. Jedynym
kluczem jest {A, B}. Schemat nie jest w 3NF (D nie jest
atrybutem kluczowym). W schemacie nie ma zaleŜności
częściowych. Schemat jest w 2NF. W schemacie istnieje
zaleŜność przechodnia: AC→D.
Przykład. Niech R={A, B, C, D} i F={AB→C, B→D, BC→A}.
Jedynymi kluczami są {A, B} i {B, C}. D jest atrybutem
niekluczowym i {B} jest podzbiorem właściwym klucza, więc
zaleŜność B→D jest zaleŜnością częściową. Schemat nie jest w
2NF.
Twierdzenie
Schemat relacji jest w 3NF wtw, gdy jest w 2NF i nie zawiera
zaleŜności przechodnich.
24
Pierwsza postać normalna
Definicja
Schemat relacji jest w 1NF wtw, gdy jego atrybuty
przyjmują wartości atomowe (wartości atrybutów nie
są zbiorami).
25
Postacie normalne - przykład
Hodowca zaproponował następujący schemat bazy danych:
Hodowle (Nr_strusiarni, Liczba_strusi, Imię_strusia, Płeć_strusia,
Wiek_strusia,Opiekun_strusiarni, Nazwisko_opiekuna,
Imię_opiekuna)
1.
2.
3.
4.
5.
Nr_strusiarni → Liczba_strusi
Nr_strusiarni → Opiekun_strusiarni
Imię_strusia, Nr_strusiarni → Płeć_Strusia
Imię_strusia, Nr_strusiarni → Wiek_Strusia
Opiekun_strusiarni → Nazwisko_opiekuna, Imię_opiekuna
Normalizacja (krok 3)
Projekt logiczny (po wykonaniu normalizacji) nie musi
być projektem ostatecznym. Jeśli wymagają tego kryteria
dotyczące wydajności, projekt fizyczny moŜe się róŜnić od
logicznego – jedną z moŜliwości jest denormalizacja
niektórych relacji.
Normalizacja słuŜy udoskonaleniu modelu danych tak,
aby spełniał szereg warunków pozwalających uniknąć
duplikowania danych, dzięki normalizacji model lepiej
odwzorowuje informacje modelowanego
przedsiębiorstwa, staje się spójny, zapewnia minimum
redundancji i maksimum stabilności.
Realizacja transakcji (krok 4)
Sprawdź, czy relacje umoŜliwiają realizacje
transakcji
Celem tego kroku jest sprawdzenie, czy logiczny model danych
umoŜliwia wykonanie transakcji opisanych w specyfikacji wymagań
uŜytkownika.
W kroku tym próbujemy wykonać manualnie poszczególne operacje
zawarte w transakcjach, korzystając z relacji, powiązań między
kluczami głównymi i obcymi relacji.
Więzy integralności (krok 5)
Wyznacz więzy integralności
Więzy integralności to dodatkowe warunki, których spełnienie
zapobiega niespójności bazy danych.
Na tym etapie koncentrujemy się na wysokopoziomowym opisie
specyfikującym, jakie więzy integralności powinny być spełnione,
niezaleŜnie od tego, w jaki sposób zapewniona będzie ich realizacja.
Po ustaleniu więzów integralności logiczny model danych moŜna
uznać za kompletna reprezentacje rzeczywistości.
Więzy integralności
RozwaŜamy pięć typów więzów integralności:
•
wymagana obecność danych – niektóre atrybuty nie powinny
zawierać wartości pustych; więzy tego typu powinny być ustalone
na etapie dokumentowania informacji o atrybutach w słowniku
danych.
•
więzy dziedzin atrybutów – z kaŜdym atrybutem związana
jest dziedzina, czyli zbiór dopuszczalnych wartości; wiązy tego
typu naleŜy ustalić wraz z wyborem dziedzin atrybutów.
•
integralność encji – klucz główny encji nie moŜe przyjmować
wartości pustych; ograniczenie to naleŜy uwzględnić przy
wyborze klucza głównego dla danego zbioru encji.
Więzy integralności
•
więzy ogólne – są nazywane regułami biznesowymi (lub
zasadami działania); reguły te wynikają z zasad obowiązujących
w opisywanym przez nie fragmencie „świata rzeczywistego”, np.
Promotor moŜe prowadzić 10 prac dyplomowych studentów
•
integralność referencyjna – klucz obcy wiąŜe krotkę relacji
podrzędnej z krotką relacji nadrzędnej o pasującej wartości
klucza kandydującego; integralność referencyjna oznacza, Ŝe jeśli
wartość klucza obcego jest określona, to wartość ta musi
odpowiadać istniejącej krotce w relacji nadrzędnej.
Więzy integralności
Integralność referencyjna
Przykład:
Personel
Nr_Pracownika <pk>
Zarządza
Nieruchomość
Nr_Nieruchomosci <pk>
Nr_Pracownika
<fk>
Atrybut Nr_Pracownika w relacji Nieruchomość wiąŜe nieruchomość
do wynajęcia z krotką w relacji Personel zawierającą dane pracownika
zarządzającego daną nieruchomością. Jeśli wartość Nr_Pracownika (w
relacji Nieruchomość) jest określona, to powinna ona zawierać
„poprawny” numer pracownika, występujący jako wartość
Nr_Pracownika w relacji Personel.
Więzy integralności
Integralność referencyjna
Pierwszym problemem jest kwestia, czy dozwolone są wartości
puste klucza obcego.
•
W przypadku opcjonalnego uczestnictwa relacji podrzędnej wartości
puste są dozwolone, np. dopuszczamy moŜliwość przechowywania
informacji o nieruchomości do wynajęcia bez podania pracownika
zarządzającego tą nieruchomością
•
W przypadku obowiązkowego uczestnictwa relacji podrzędnej
wartości puste nie są dozwolone, np. nie dopuszczamy moŜliwości
przechowywania informacji o nieruchomości do wynajęcia bez
podania pracownika zarządzającego tą nieruchomością
Więzy integralności
Integralność referencyjna
Kolejnym problemem jest sposób zapewnienia integralności
referencyjnej. Operacje na bazie danych mogą naruszyć więzy
referencyjne.
Przypadek 1. Wstawienie krotki do relacji podrzędnej –
dla zachowania integralności referencyjnej konieczne jest
sprawdzenie , czy klucz obcy w relacji podrzędnej ma wartość
pusta lub jest równy wartości występującej w jednej z krotek
relacji nadrzędnej
Przypadek 2. Usunięcie krotki z relacji podrzędnej – nie
narusza integralności referencyjnej
Przypadek 3. Modyfikacja klucza obcego krotki w relacji
podrzędnej – sytuacja podobna do przypadku 1
Więzy integralności
Integralność referencyjna
Przypadek 4. Wstawienie krotki do relacji nadrzędnej –
nie narusza integralności referencyjnej
Przypadek 5. Usunięcie krotki z relacji nadrzędnej – moŜe
naruszyć integralność referencyjną w przypadku, gdy w relacji
podrzędnej występuje krotka wskazującą na usuniętą krotkę
nadrzędną (patrz dalej)
Przypadek 6. Modyfikacja klucza głównego krotki
nadrzędnej - moŜe naruszyć integralność referencyjną w
przypadku, gdy w relacji podrzędnej występuje krotka
wskazującą na wartość klucza głównego sprzed modyfikacji
(patrz dalej)
Więzy integralności
Integralność referencyjna
W przypadku 5 i 6 moŜna wybrać kilka moŜliwości:
NO ACTION lub RESTRICT - uniemoŜliwia usunięcie
(modyfikację) krotki z relacji nadrzędnej jeśli występują
jakiekolwiek krotki od niej zaleŜne.
CASCADE – usunięcie (modyfikacja) krotki nadrzędnej pociąga za
sobą usunięcie (modyfikację) wszystkich związanych z nią krotek
podrzędnych; jeśli krotka podrzędna pełni rolę nadrzędną w
innym związku, analogiczna operacja usuwania (modyfikacji)
powinna być wykonana dla krotek podrzędnych tego związku.
SET NULL – usunięcie krotki nadrzędnej pociąga za soną
automatyczne nadanie wartości pustych odpowiednim kluczom
obcym wszystkich krotek
SET DEFAULT – usunięcie krotki nadrzędnej pociąga za soną
automatyczne nadanie wartości domyślnych odpowiednim
kluczom obcym wszystkich krotek podrzędnych.
Nieruchomość(
nieruchomośćNr NumerNieruchomości
NOT NULL
ulica
Ulica
NOT NULL
miasto
Miasto
NOT NULL
typ
TypNieruchomości
NOT NULL DEFAULT ‘F’
pokoje
NieruchomośćPokoje
NOT NULL DEFAULT 4
czynsz
NieruchomośćCzynsz
NOT NULL DEFAULT 600
właścicielNr
NumerWłaściciela
NOT NULL
pracownikNr
NumerPracownika
NOT NULL
biuroNr
NumerBiura
NOT NULL
kaucja
NieruchomośćCzynsz
NOT NULL
PRIMARY KEY (nieruchomośćNr)
ALTERNATE KEY (ulica, miasto)
FOREIGN KEY (pracownikNr) REFERENCES Personel(pracownikNr) ON
UPDATE CASCADE ON DELETE SET NULL
FOREIGN KEY (właścicielNr) REFERENCES WłaścicielPrywatny(właścicielNr)
and WłaścicielInstytucjonalny(właścicielNr) ON UPDATE
CASCADE ON DELETE NO ACTION
DERIVED kaucja (czynsz*0,1)
Dziękuję za uwagę!!!