Bazy danych 1

Bazy danych 1
Wykład 5
Metodologia projektowania baz danych
(projektowanie logiczne)
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 1)
1. Usuń własności niekompatybilne z
modelem relacyjnym
Związki złoŜone
Atrybuty wielowartościowe
Usunięcie związków złoŜonych
Personel
Rejestruje
Biuro
1..1
1..1
0..*
Klient
Personel
Przetwarza
Rejestruje
Rejestracja
1..1
0..*
0..*
1..1
Potwierdza
1..1
Klient
Biuro
1..1
Usunięcie atrybutów
wielowartościowych
Biuro
NrBiura
Adres
NrTel [1..3]
Biuro
NrBiura
Adres
Udostępnia
1..1
Telefon
1..3
NrTel
Projektowanie logiczne (krok 2)
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)
Przykład definicji relacji w DDL
Relacja_A
Relacja_B
Klucz_A
<pk>
AtrybutA1
Klucz_B
<pk>
Klucz_A
<fk>
AtrybutB1
Relacja_A (Klucz_A, AtrybutA1)
Primary Key Klucz_A
Relacja_B (Klucz_B, Klucz_A, AtrybutB1)
Primary Key Klucz_B
Foreign Key Klucz_A references Relacja_A(Klucz_A)
Projektowanie logiczne (krok 2)
– reguły transformacji
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.
Reguły transformacji –
związki typu 1:1
Uczestnictwo obowiązkowe po obu stronach związku
A
1..1
1..1
B
- Klucz_B
- Klucz_A
Z encji A i B tworzymy jeden schemat relacji RAB, który zawiera atrybuty
obu encji, a kluczem głównym jest klucz główny encji A lub klucz
główny encji B.
RAB
Klucz_A <pk>
Klucz_B
Reguły transformacji –
związki typu 1:1
Uczestnictwo obowiązkowe po jednej stronie związku
A
- Klucz_A
1..1
0..1
B
- Klucz_B
Z encji A i B tworzymy schematy relacji RA i RB; do schematu RB
wstawiamy jako dodatkowy atrybut klucz główny ze schematu RA.
RA
RB
Klucz_A <pk>
Klucz_B <pk>
Klucz_A <fk>
Reguły transformacji –
związki typu 1:1
Uczestnictwo opcjonalne po obu stronach związku
A
0..1
0..1
- Klucz_A
B
- Klucz_B
Dopuszczalne róŜne rozwiązania:
-tworzymy relacje RA i RB przy czym klucz główny jednej z nich
umieszczamy w relacji drugiej jako klucz obcy (wartości NULL)
- tworzymy schematy relacji RA i RB, a związek reprezentujemy
nowym schematem RAB, który zawiera dwa klucze obce - klucz główny
relacji RA i klucz główny relacji RB
RA
Klucz_A <pk>
RB
RAB
Klucz_A <pk,fk1>
Klucz_B <pk,fk2>
Klucz_B <pk>
Reguły transformacji – związki
typu 1:1 z atrybutami
Przypadek gdy związek ma atrybuty
A
1..1
1..1
B
- Klucz_B
- Klucz_A
Zwiazek
- Atrybut_Zwiazku
Z encji A i B tworzymy schematy relacji RA i RB; związek reprezentujemy
schematem RAB, który zawiera dwa klucze obce – klucz główny ze
schematu RA i klucz główny ze schematu RB - oraz atrybuty związku
RA
RB
Klucz_A <pk>
Klucz_B <pk>
RAB
Klucz_A
<pk,fk1>
Klucz_B
<pk,fk2>
Atrybut_Zwiazku
Reguły transformacji – związki
rekurencyjne typu 1:1
Uczestnictwo obowiązkowe po obu stronach związku
1..1
Rola2
A
- Klucz_A
1..1
Rola1
Tworzymy jeden schemat relacji RA zawierający dwie kopie klucza
głównego. Jedna kopia jest kluczem obcym i powinna mieć nazwę
wskazującą na reprezentowany związek (rola).
RA
Klucz_A
<pk>
Rola1_Klucz_A <fk1>
Reguły transformacji – związki
rekurencyjne typu 1:1
Uczestnictwo opcjonalne po jednej stronie związku
1..1
Rola2
A
- Klucz_A
0..1
Rola1
Tworzymy schemat relacji RA z kluczem głównym odpowiadającym
kluczowi głównemu encji A oraz schemat RAA, który zawiera dwa
klucze obce – klucze główne ze schematu RA - opatrzone rolą, którą
encja sprawuje w związku.
RA
RAA
Klucz_A <pk>
Rola1_Klucz_A <pk,fk1>
Rola2_Klucz_A <pk,fk2>
Reguły transformacji – związki
rekurencyjne typu 1:1
Uczestnictwo opcjonalne po obu stronach związku
0..1
Rola2
A
- Klucz_A
0..1
Rola1
Tworzymy schemat relacji RA z kluczem głównym odpowiadającym
kluczowi głównemu encji A oraz schemat RAA, który zawiera dwa
klucze obce – klucze główne ze schematu RA - opatrzone rolą, którą
encja sprawuje w związku.
RA
RAA
Klucz_A <pk>
Rola1_Klucz_A <pk,fk1>
Rola2_Klucz_A <pk,fk2>
Reguły transformacji – związki
rekurencyjne typu 1:1 z atrybutami
Przypadek gdy związek ma atrybuty
1..1
Rola2
A
- Klucz_A
1..1
Rola1
Zwiazek
- Atrybut_Zwiazku
Tworzymy schemat relacji RA z kluczem głównym odpowiadającym
kluczowi głównemu encji A oraz schemat RAA, który zawiera dwa
klucze obce – klucze główne ze schematu RA - opatrzone rolą, którą
encja sprawuje w związku oraz atrybuty związku.
A
RAA
Klucz_A <pk>
Rola1_Klucz_A <pk,fk1>
Rola2_Klucz_A <pk,fk2>
Atrybut_Zwiazku
Reguły transformacji –
związki typu 1:*
Uczestnictwo obowiązkowe po stronie wiele związku
A
- Klucz_A
1..1
0..*
B
- Klucz_B
Z encji A i B tworzymy schematy relacji RA i RB; do schematu RB
wstawiamy jako dodatkowy atrybut klucz główny ze schematu RA.
RA
RB
Klucz_A <pk>
Klucz_B <pk>
Klucz_A <fk>
Reguły transformacji –
związki typu 1:*
Uczestnictwo opcjonalne po stronie wiele związku
A
0..1
0..*
- Klucz_A
B
- Klucz_B
• jak wyŜej
• Z encji A i B tworzymy schematy relacji RA i RB, jeśli duŜo wystąpień
encji B nie uczestniczy w związku, to związek reprezentujemy schematem
RAB, który zawiera dwa klucze obce – klucz główny ze schematu RA i
klucz główny ze schematu RB.
RA
Klucz_A <pk>
RB
RAB
Klucz_A <pk,fk1>
Klucz_B <pk,fk2>
Klucz_B <pk>
Reguły transformacji – związki
typu 1:* z atrybutami
Uczestnictwo obowiązkowe po stronie wiele związku
A
1..1
B
0..*
- Klucz_A
- Klucz_B
Zwiazek
- Atrybut_Zwiazku
Z encji A i B tworzymy schematy relacji RA i RB; do schematu RB
wstawiamy jako dodatkowy atrybut klucz główny ze schematu RA
oraz atrybuty związku.
RA
RB
Klucz_A <pk>
Klucz_B
<pk>
Klucz_A
<fk>
Atrybut_Zwiazku
Reguły transformacji – związki
typu 1:* z atrybutami
Uczestnictwo opcjonalne po stronie wiele związku
A
0..1
0..*
- Klucz_A
B
- Klucz_B
• Z encji A i B tworzymy schematy relacji RA i RB, jeśli duŜo wystąpień
encji B nie uczestniczy w związku, to związek reprezentujemy schematem
RAB, który zawiera dwa klucze obce – klucz główny ze schematu RA i
klucz główny ze schematu RB oraz atrybuty związku.
RA
RB
Klucz_A <pk>
Klucz_B <pk>
RAB
Klucz_A
<pk,fk1>
Klucz_B
<pk,fk2>
Atrybut_Zwiazku
Reguły transformacji – związki
typu *:* (bez i z atrybutami)
Uczestnictwo opcjonalne po obu stronach
A
0..*
0..*
- Klucz_A
B
- Klucz_B
Zwiazek
- Atrybut_Zwiazku
•Z encji A i B tworzymy schematy relacji RA i RB, związek reprezentujemy
schematem RAB, który zawiera dwa klucze obce – klucz główny ze
schematu RA i klucz główny ze schematu RB (oraz atrybuty związku).
RA
RB
Klucz_A <pk>
Klucz_B <pk>
RAB
Klucz_A
<pk,fk1>
Klucz_B
<pk,fk2>
Atrybut_Zwiazku
Reguły transformacji – związki rekurencyjne typu *:* (bez i z atrybutami)
Uczestnictwo opcjonalne po obu stronach
0..*
Rola2
A
- Klucz_A
0..*
Rola1
Zwiazek
- Atrybut_Zwiazku
• Z encji A schemat relacji RA, związek reprezentujemy schematem RAA,
który zawiera dwa klucze obce – klucze główne ze schematu RA
opatrzone rolą, którą encja sprawuje w związku (oraz atrybuty związku).
RA
RAA
Klucz_A <pk>
Rola1_Klucz_A <pk,fk1>
Rola2_Klucz_A <pk,fk2>
Atrybut_Zwiazku
Przekształcenie uogólnienia
w schemat relacyjny
Metoda 1:
tworzymy tabele: jedną dla nadklasy i po jednej dla kaŜdej podklasy;
w tabelach podklas wstawiamy klucz tabeli nadklasy (jako klucz obcy).
Wykorzystanie praktyczne:
Schemat relacyjny uzyskany w ten sposób jest najlepszy z punktu
widzenia normalizacji, moŜe on być jednak niewydajny przy częstych
złączeniach tabeli nadrzędnej z tabelami podrzędnymi.
Metoda ta moŜe przynieść dobre wyniki, jeśli:
podklasy znacznie róŜnią się od siebie (mają wiele róŜnych
atrybutów);
podklasy są silnie przecinające się (jest wiele obiektów, które
jednocześnie naleŜą do więcej niŜ jednej podklasy) – wówczas
łatwiej uniknąć jest niespójności danych (np. określona osoba moŜe
być jednocześnie naleŜeć do klasy Student i Pracownik; modyfikując
jej dane, na przykład atrybut „Email”, mamy pewność, Ŝe wystarczy
nanieść zmiany w jednym miejscu: w tabeli [Osoba]).
Przekształcanie uogólnienia
w schemat relacyjny – metoda 1
Diagram klas
Schemat relacji
Przekształcanie hierarchii
uogólnienia w schemat relacyjny
Metoda 2:
tworzymy po jednej tabeli dla kaŜdej podklasy;
do kaŜdej tabeli wstawiamy wszystkie atrybuty nadklasy.
Wykorzystanie praktyczne:
Stosujemy te metodą, gdy kaŜde wystąpienie nadklasy musi
naleŜeć do przynajmniej jednej podklasy oraz podklasy dość
znacznie róŜnią się
Schemat ten jest wydajnie przetwarzany, jeśli są częste
odwołania do tabel powstałych z podklas (unikamy złączeń
tabel).
Posługując się tą metodą tracimy zysk z zamodelowanego
wcześniej uogólnienia (dziedziczenia) – na przykład system nie
rozpoznaje faktu, Ŝe obiekt zapisany w tabeli Student i Pracownik
moŜe być samą osobą.
Przekształcanie uogólnienia
w schemat relacyjny – metoda 2
Diagram klas
Schemat relacji
Przekształcanie hierarchii
uogólnienia w schemat relacyjny
Metoda 3:
tworzymy dwie tabele: jedna reprezentuje nadklasę, a druga
podklasy,
do drugiej tabeli wstawiamy wszystkie atrybuty podklas oraz
klucz główny nadklasy jako klucz obcy;
w razie potrzeby dodajemy pole rozróŜniające, informujące, z
której podklasy pochodzi dany obiekt.
Wykorzystanie praktyczne:
Rozwiązanie to moŜe być zastosowane tylko wtedy, gdy podklasy
róŜnią się między sobą minimalnie (np. pojedynczymi atrybutami)
oraz wystąpienie nadklasy nie musi naleŜeć do Ŝadnej z podklas.
Przekształcanie uogólnienia
w schemat relacyjny – metoda 3
Osoba
Id_Osoby
Imie
Nazwisko
NIP
PESEL
itd.
integer
<pk>
varchar
varchar
varchar
varchar
<Undefined>
Pracownik_Student
Id_Osoby
Nr_Pracownika
Nr_Indeksu
Data_Zapisania
Data_Wypisania
Tytul
Stanowisko
Data_Zatrudnienia
Okres_Zatrudnienia
itd.
int
<fk>
int
int
date
date
varchar
varchar
date
int
<Undefined>
Przekształcanie hierarchii
uogólnienia w schemat relacyjny
Metoda 4:
tworzymy jedną tabelę;
wstawiamy do niej wszystkie atrybuty z nadklasy i podklas;
w razie potrzeby dodajemy pole rozróŜniające, informujące, z
której podklasy pochodzi dany obiekt.
Wykorzystanie praktyczne:
Rozwiązanie to moŜe być zastosowane tylko wtedy, gdy
podklasy róŜnią się między sobą minimalnie (np. pojedynczymi
atrybutami), a wystąpienie nadklasy naleŜy przynajmniej do
jednej z podklas
W przeciwnym razie w wierszach moŜe występować wiele
wartości NULL (jest to bardzo niekorzystne z punktu widzenia
normalizacji schematu relacyjnego i potencjalnych anomalii przy
aktualizacji danych).
Przekształcanie uogólnienia
w schemat relacyjny – metoda 4
Diagram klas
Schemat relacji
Dodatkowe
pole
rozróŜniające
Dziękuję za uwagę!!!