Wykład 2

Bazy danych 2
Wykład 2
czyli
Kilka słów o tworzeniu aplikacji
bazodanowej
Metody projektowania baz danych
Metoda wstępująca – nadaje się do projektowania prostych baz
danych zawierających względnie małą liczbę atrybutów, proces
projektowania bazy danych rozpoczyna się od zidentyfikowania
wszystkich atrybutów, a następnie poprzez analizę zależności
funkcyjnych (powiązań) pomiędzy atrybutami łączy się je w relacje
(tabele)
Metoda zstępująca – nadaje się do projektowania złożonych baz
danych zawierających względnie dużą liczbę atrybutów, proces
projektowania bazy danych rozpoczyna się od zidentyfikowania
istotnych encji (bytów) oraz związków pomiędzy nimi, a następnie
stosując metodę kolejnych uściśleń wprowadza się encje, związki oraz
atrybuty niższego poziomu.
Etapy projektowania bazy danych
Konceptualne projektowanie bazy danych – to proces konstrukcji modelu
danych, który jest niezależny od wszelkich aspektów fizycznych
(specyficzny model danych, docelowy BDMS, programy użytkowe, języki
programowania, platforma sprzętowa)
Logiczne projektowanie bazy danych – to proces konstrukcji modelu, który
jest oparty na specyficznym modelu danych (np. model relacyjny, model
obiektowy) ale niezależny od konkretnego BDMS i innych aspektów
fizycznych.
Fizyczne projektowanie bazy danych – to proces tworzenia opisu
implementacji bazy danych w pamięci zewnętrznej. Opis ten zawiera
bazowe relacje oraz organizacje plików i indeksów zapewniających
efektywny dostęp do danych, realizacje więzów integralności i środków
bezpieczeństwa danych.
Zanim utworzymy
model konceptualny
Zanim zrobimy model konceptualny
1.
2.
3.
4.
5.
Cel projektu
Analiza wycinka rzeczywistości
Słownik pojęć
Wyodrębnienie kategorii

KAT/OO1 Towar
Opis: Kategoria Towar służy do opisu towaru przechowywanego w
magazynie; Towar może być dostarczany przez różnych
dostawców
Atrybuty:
 Symbol towaru - unikatowy symbol towaru
 Nazwa
 Jadnostka miary
Reguły funkcjonowania

REG/001 Towar przyjmowany jest na podstawie dokumentu PZ
Zanim zrobimy model konceptualny
1.
Ograniczenia dziedzinowe

2.
OGR/001 Długość nazwy towarów nie może być wieksza niż 20 znaków
Zdefiniowanie transakcji

TRA/001 Wprowadzenie towaru
Opis: Zadaniem transakcji jest wprowadzenie danych towaru i
wygenerowaqnie unikatowego symbolu towaru
Uwarunkowania:
- dane towaru nie mogą znajdować się w bazie;
- wszystkie atrybuty musza mieć podana wartość (być wypełnione)
Wejście
Wyjście
Użytkownik
Dane towaru
-
Baza danych
Unikatowy symbol
towaru
Dane towaru
Projektowanie konceptualne – przegląd
1.
Określ występujące zbiory encji
2.
Ustal typy występujących związków
3.
Określ atrybuty odpowiadające poszczególnym encjom
4.
Określ dziedziny poszczególnych atrybutów
5.
Ustal klucze kandydujące i klucze główne
6.
Rozważ możliwość zastosowania zaawansowanych
metod modelowania
7.
Zweryfikuj utworzony model pod kątem występowania
redundancji
8.
Zweryfikuj możliwość realizacji transakcji
9.
Omów konceptualny model z użytkownikiem
Pułapki
 Pułapka wachlarzowa – występuje w sytuacji, gdy model
przedstawia związek pomiędzy pewnymi zbiorami encji
(klasami), ale wynikające z tego ścieżki pomiędzy
wystąpieniami encji (obiektami) nie są jednoznaczne; pułapka
taka może wystąpić, gdy co najmniej dwa związki typu 1:*
wychodzą z tej samej encji (klasy)
Problem:
Rozwiązanie:
Pułapki
 Pułapka szczelinowa – występuje gdy model sugeruje
istnienie związku pomiędzy zbiorami encji (klasami), ale nie
istnieje ścieżka łącząca pewne wystąpienia tych encji
(obiekty); pułapka ta może wystąpić, gdy w modelu znajduje
się co najmniej jeden związek o minimalnej krotności zero ,
który jest elementem ścieżki pomiędzy powiązanymi encjami
(klasami)
Problem:
Rozwiązanie:
Projektowanie logiczne – przegląd

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.
Wyznacz relacje dla logicznego modelu danych

Relacje będziemy opisywać za pomocą języka definiowania bazy
danych DBDL (DataBase Definition Language)

Definicja (uproszczona) relacji w DBDL 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
Relacj a_A
Rel acja_B
Klucz_A
<pk>
Atrybu tA1
Klu cz_B
<pk>
Klu cz_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 1) – 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
- Kl ucz_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>
Kl ucz_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
Rola 2
A
- Klucz_ A

1..1
Ro la 1
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>
Rola 1_Klu cz_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
Zwi azek
- 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>
Rola 1_Klucz_A <p k,fk1>
Rola 2_Klucz_A <p k,fk2>
Atrybut_ Zwiazku
Reguły transformacji – związki typu 1:*
Uczestnictwo obowiązkowe po stronie wiele związku
A
- Klu cz_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..*
- Klu cz_ A
B
- Klu cz_ 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
Klucz_A <pk>
RB
Kl ucz_B
<pk>
Kl ucz_A
<fk>
Atrybut_Zwi azku
Reguły transformacji – związki typu 1:* z
atrybutami
Uczestnictwo opcjonalne po stronie wiele związku
A
0..1
0..*
- Klu cz_ A
B
- Klu cz_ 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>
Kl ucz_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..*
- Klu cz_A
B
- K lu cz_ B
Zwiaze k
- A trybu t_Zwi azku
•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
Kl ucz_A
<pk,fk1>
Kl ucz_B
<pk,fk2>
Atrybut_Zwi azku
Reguły transformacji – związki reku-rencyjne typu *:* (bez i z
atrybutami)
Uczestnictwo opcjonalne po obu stronach
0..*
Ro la 2
A
- Klucz_A
0..*
Rola1
Zwia zek
- Atryb ut_Zwia zku
• 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
Kl ucz_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
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 3
Diagram klas
Schemat relacji
Dodatkowe
pole
rozróżniające
Projektowanie logiczne (krok 2)
Wykonaj normalizację relacji

Celem tego kroku jest przekształcenie każdej relacji co najmniej do postaci
Boyce’a-Codda (BCNF).

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 3)
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
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ę!!!
Powtórka z modelowania danych
Podejście obiektowe i strukturalne
Podejście strukturalne
czyli encje i związki
Modelowanie strukturalne

W podejściu strukturalnym do modelowania danych wykorzystujemy
głównie diagram związków encji

Diagram związków encji (ang. Entity Relationship Diagram, ERD)
opisuje warstwę danych w systemie; składa się ze zbioru obiektów - encji i
struktury powiązań między nimi.

Diagramy ERD szczególnie dobrze nadają się do modelowania relacyjnych
baz danych, ponieważ umożliwiają prawie bezpośrednie przejście od
diagramu do końcowego schematu relacyjnego.

Powyższa cecha sprawia, że diagramy ERD i obejmująca je metodologia
strukturalna są ciągle rozpowszechnione w praktyce firm rozwijających
oprogramowanie.

Diagramy ERD posiadają ograniczenia reprezentacji charakterystyczne dla
relacyjnego modelu danych (m.in. problemy z modelowaniem
dziedziczenia) i mogą sprawiać problemy przy integracji warstwy danych z
obiektowym modelem reszty aplikacji.

Cechy te skłaniają wytwórców oprogramowania do stopniowego
zastępowania metodologii strukturalnej obiektową.
Diagram związków encji (ERD)
Podstawowe pojęcia
 zbiór (typ) encji (ang. entity type) – to grupa „obiektów” wziętych z
„rzeczywistego świata” o tych samych właściwościach (cechach).
 wystąpienie (instancja) encji (ang. entity) – to unikalny i
rozpoznawalny obiekt ze zbioru encji;
 związek (ang. relationship) – to zbiór powiązań pomiędzy jednym lub
większą liczbą uczestniczących w tym związku encji.
 wystąpienie związku – to unikalne i identyfikowalne powiązanie
zachodzące pomiędzy pojedynczymi wystąpieniami encji z
uczestniczących w związku zbiorów encji
 atrybut (ang. attribute) – własność, cecha encji lub związku
 asocjacja (ang. association) – reprezentuje związek między encjami,
który posiada pewne cechy, ale nie ma bezpośredniej interpretacji jako
obiekt świata rzeczywistego.
Encje
Encja
 Encja jest „rzeczą”, która w modelowanej organizacji jest rozpoznawana
jako istniejący niezależnie obiekt, zdarzenie lub pojęcie. Encja daje się
wyodrębnić i odróżnić od pozostałych elementów opisu świata.
ENCJE
Charakter fizyczny
Charakter pojęciowy
np. Personel,
np. Wizyta,
Nieruchomość.
Sprzedaż.
 Encja jest wystąpieniem typu encji, czyli obiektem, który jest elementem
pewnej klasy (np. encja „Sieciowe bazy danych” jest wystąpieniem typu encji
„Przedmiot”). Jednakże w metodologiach projektowych powszechnie używa
się terminu „encja” w znaczeniu „typ encji”.
Związki
 Związek reprezentuje powiązanie między encjami, wynikające z opisu
modelowanego fragmentu rzeczywistości
Przykład: Biuro zatrudnia Personel
 Zazwyczaj rozpatrujemy związki binarne, to znaczy łączące jednocześnie
dwie encje. Związki mogą być również wieloelementowe – łączące wiele
encji.
Przykład: Związek binarny - Biuro zatrudnia Personel
Związek potrójny – Personel rejestruje Klienta w Biurze
 Kontekst związku między encjami jest często wyznaczany przez rolę,
którą jedna encja pełni względem drugiej (np. encja „Grupa” składa się ze
„Student-ów”; „Wykładowca” prowadzi „Przedmiot”).
 Między dwiema encjami może istnieć więcej niż jeden związek, co może
wynikać z różnych ról, które są wzajemnie pełnione przez encje (np. „Grupa”
składa się ze „Studentów”, ale jednocześnie „Student” jest starostą w
„Grupie”).
Związki
Każdy związek jest opisywany przez dwie cechy: liczebność
i uczestnictwo.
 Liczebność (stopień) – określa liczbę wystapień encji
biorących udział w związku:
 1:1 (jeden-do-jednego),
 1:N (jeden-do-wielu),
 N:M (wiele-do-wielu).
Związki
 Uczestnictwo (opcjonalność):
 opcjonalne - jeśli istnieje przynajmniej
jedna instancja encji, która nie bierze
udziału w związku (w diagramach
reprezentowane przez kółko przy encji);
wymagane - jeśli wszystkie instancje
muszą brać udział w związku (w
diagramach reprezentowane przez
kreskę przy encji).

Związki
Przykład: Poniższy diagram mówi, że każdy student może należeć do
jednej grupy, a grupa musi się składać się przynajmniej z jednego
studenta. Tak więc uczestnictwo encji „Grupa” w związku jest opcjonalne
(w danym okresie student może nie należeć do żadnej grupy – na przykład
w czasie urlopu dziekańskiego), natomiast uczestnictwo encji „Student” w
związku jest obowiązkowe (nie może powstać grupa, w której nie ma
żadnych studentów).
Związki
Liczebność i uczestnictwo można wyrażać poprzez
podanie przedziałów (Min, Max) lub Min, Max lub Min..Max
po każdej stronie encji:

– 0, 1 lub 0..1
- znaczenie „1 : ?”, opcjonalne;
– 1, 1 lub 1..1
- znaczenie „1 : ?”, wymagane;
– 0, N lub 0..N
- znaczenie „N : ?”, opcjonalne;
– 1, N lub 1..N
- znaczenie „N : ?”, wymagane.
 Wybór konkretnej formy reprezentacji liczebności i
uczestnictwa zależy od możliwości narzędzia, w którym
tworzymy diagramy ERD.
Związki
Związek rekurencyjny – to związek, w którym ten sam
zbiór encji występuje więcej niż jeden raz w różnych rolach
•
Przykład:
 Związek rekurencyjny – Personel (kierownik) kieruje
Personelem (kierowanymi)
Asocjacja
 asocjacja (ang.
association) – reprezentuje związek między
encjami, który posiada pewne cechy, ale nie ma bezpośredniej
interpretacji jako obiekt świata rzeczywistego.
 asoscjacja posiada więc swoje własne atrybuty
Atrybuty
 Atrybut – to cecha encji lub związku
 Dziedzina atrybutu – to zbiór dopuszczalnych wartości dla danego
atrybutu
 Atrybut prosty – to atrybut zawierający tylko jedną składową, która może
istnieć niezależnie.
Przykład: Atrybuty stanowisko i pensja w encji Personel
 Atrybut złożony – to atrybut zbudowany z wielu składowych z których
każda może istnieć niezależnie.
Przykład: Atrybut adres w encji Biuro ma składowe ulica,
miasto, kod
Atrybuty
 Atrybut jednowartościowy – to atrybut, który ma tylko jedną wartość
dla każdego wystąpienia encji.
Przykład: Atrybut biuroNr w encji Biuro
 Atrybut wielowartościowy – to atrybut, który może zawierać wiele
wartosci dla pojedynvczego wystąpienia encji.
Przykład: Atrybut telNr może przyjmować wiele wartości dla
każdego wystąpienia encji Biuro
 Atrybut pochodny – to atrybut reprezentujący wartość, która jest
wyliczana z innego atrybutu lub zbioru atrybutów,niekoniecznie
pochodzacych z tego samego zbioru encji
Przykład: Atrybut okresNajmu może być wyliczony z
atrybutów wynajeteOd i wynajeteDo
Klucze
Klucz kandydujący – to najmniejszy zbiór atrybutów, który jednoznacznie
identyfikuje każde wystąpienie encji w zbiorze encji.
Przykład: Atrybut biuroNr jest kluczem kandydującym dla
zbioru encji Biuro
Klucz główny (ang. primary key) – to klucz kandydujący. Który został wybrany
do jednoznacznej identyfikacji każdego z wystąpień encji w zbiorze encji.
Klucz złożony – to klucz kandydujący, który składa się co najmniej z dwóch
atrybutów.
Podejście obiektowe
czyli małe przypomnienie
Modelowanie obiektowe
Modelowanie obiektowe (ang. Object-Oriented Modelling, OOM) jest
alternatywną metodologią projektowania i tworzenia systemóww stosunku do
podejścia strukturalnego.
 Modelowanie obiektowe jest bardziej intuicyjnie i ma większą siłę ekspresji
od modelowania strukturalnego, gdyż opiera się na pojęciach, które są dobrze
zrozumiałe dla człowieka, np. obiekt, klasa, atrybut. Możemy powiedzieć, że
człowiek postrzega świat i myśli obiektowo.
 Obiektowy model systemu posiada dwie podstawowe części:
– abstrakcja strukturalna - wyrażająca schemat statyczny bazy i innych
elementów systemu;
– abstrakcja zachowania - określająca dynamikę (zachowanie)
systemu.
 Model obiektowy może być płynnie i wygodnie implementowany w
obiektowych językach programowania (np. C++, Java, C#, VisualBasic,
Delphi), które obecnie dominują na rynku.
Modelowanie obiektowe
Obecnie powszechnie uznaną i stosowaną notacją modelowania
obiektowego jest ujednolicony język modelowania obiektowego
(ang. Unified Modelling Language, UML). W standardzie tym można
tworzyć szereg diagramów z zakresu abstrakcji strukturalnej i
abstrakcji zachowania.
 Istnieje wiele metodologii modelowania obiektowego,
wykorzystujących język UML. Jedną z bardziej znanych jest ogólny
proces wytwarzania oprogramowania RUP (Rational Unified
Process) firmy Rational.
 Na rynku dostępnych jest wiele środowisk wspomagających
tworzenie rozwiązań programistycznych w oparciu o metodologię
obiektową i język UML. Bardziej zaawansowane narzędzia
pozwalają nie tylko na tworzenie modeli i diagramów, ale także na
ich transformowanie do poziomu implementacyjnego (np.
generowanie szablonów klas lub bazy danych).
Obiektowe modelowanie bazy
 Do modelowania baz danych w metodologii obiektowej
wykorzystujemy model strukturalny (ang. structural model),
inaczej model struktury statycznej. W języku UML do budowy tego
modelu służy diagram klas.
 Diagram klas (ang. class diagram) – reprezentuje statyczną
strukturę systemu: klasy i obiekty oraz powiązania między nimi,
takie, jak: związek asocjacyjny, agregacja, złożenie i
uogólnienie (dziedziczenie).
 Diagram klas jest nadzbiorem diagramu ERD. Ten model pozwala
na reprezentację bardziej złożonych związków, które nie są
bezpośrednio dostępne ani w diagramie ERD, ani w schemacie
relacyjnym. W diagramie tym dopuszcza się także modelowanie
zachowania.
Obiektowe modelowanie bazy
Przed przystąpieniem do implementacji bazy danych, model
obiektowy musi być przełożony na postać uwzględniającą
konkretny model danych (np. relacyjny) oraz system
zarządzania bazą danych (DBMS).
 Jeżeli przekształcamy obiektowy model danych do schematu
relacyjnego, niektóre własności obiektowe (np. uogólnienie –
dziedziczenie) muszą być przekształcone do postaci powiązań
płaskich – bez hierarchii.
 Obiektowy model danych pomaga lepiej odzwierciedlić
rzeczywistość od modelu strukturalnego, pomimo konieczności
późniejszego osłabienia semantyki modelu podczas jego
implementacji.
Diagram klas - klasy
 Podstawowymi pojęciami występującymi w diagramie klas są obiekt i
klasa.
 Obiekt (object) - konkretny lub abstrakcyjny byt (wyróżnialny w
modelowanej rzeczywistości) posiadający nazwę, jednoznaczną
identyfikację, atrybuty i inne własności, np. metody.
 Klasa (class) - jest to zbiór obiektów tego samego typu.
Nazwa klasy
Lista atrybutów
Sekcja metod
Pracownik
- ID_Pracownika : int
- Im ie
: String
- Nazwisko
: String
+
+
+
+
Dodaj_Pacownika ()
Usun_Pracowni ka ()
Edytuj_Pracownika ()
Ile_pracownikow ()
: i nt
Typ atrybutu
Diagram klas – związki
W diagramie klas UML mogą występować następujące związki:
 asocjacja (ang. association) – równorzędny związek między klasami (np.
„Pracownik” - „Przedmiot”);
 uogólnienie (ang. generalization) – związek hierarchiczny, w którym
klasa nadrzędna jest bardziej ogólna od klasy podrzędnej (np. „Osoba” „Student”, „Osoba” - „Pracownik”).
 agregacja (ang. aggregation) – specjalny rodzaj asocjacji, która wyraża
relację „całość – część”; klasa podrzędna może istnieć bez klasy
nadrzędnej (np. „Grupa” - „Student”);
 kompozycja (ang. composition) - specjalny rodzaj asocjacji, która
wyraża relację „całość – część”; klasa podrzędna nie może istnieć bez
klasy nadrzędnej (np. „Przedmiot” - „Zajęcia”);
 zależność (ang. dependency) – zmiany dokonywane w jednej klasie
(element niezależny) powodują zmiany w drugiej klasie (element zależny).
 realizacja (ang. realization) – związek między klasą, a jej interfejsem.
Diagram klas – związki
 asocjacja
 uogólnienie
 agregacja
 kompozycja
Diagram klas – związki
 zależność
 realizacja
Personel
Rejestruje
 asoccjacja n-arna
( w zależności od narzędzia)
Klient
Biuro
Diagram klas – związki
Związek może mieć :
• nazwę
• role (np.: pracownik, pracodawca)
• kierunek (również dwustronny)
• liczebność (multiplicity)
• atrybuty i metody
• może być związkiem rekurencyjnym
Diagram klas – związki
Liczebność
Rola
Atrybuty
związku
Klasa
asocjacyjna
Diagram klas – związki
Liczebność i opcjonalność wyrażamy poprzez
podanie minimalnej .. maksymalnej liczby obiektów
klasy uczestniczącej w związku, np.
 1..* - od 1 do wielu obiektów, uczestnictwo
wymagane
 0..1 - 0 lub 1 obiekt, uczestnictwo opcjonalne
 3..4 - 3 lub 4 obiekty
*
- 0 lub wiele
Diagram klas – związki
Agregacja (ang. aggregation)
 Związek agregacji jest szczególnym rodzajem asocjacji
wyrażającym zależność pomiędzy całością (klasa agregująca),
a jej częściami (klasa składowa).

Cechą charakterystyczna agregacji – jest to, że klasa
składowa może istnieć bez klasy agregującej
 Dwie klasy objęte związkiem agregacji odnoszą się do
różnych obiektów.
 Przykład: Student należy do Grupy (element – zbiór).
Określony student jest odrębnym obiektem w stosunku do
Grupy, do której należy.
Diagram klas – związki
Agregacja
Klasa
agregująca
Symbol
agregacji
Klasa
składowa
Diagram klas – związki
Kompozycja (ang. composition)
Związek kompozycji jest podobny do agregacji i zachodzi
pomiędzy całością, a jej częściami.
 W kompozycji „całość” jest odpowiedzialna za zarządzanie
„częściami”, co oznacza, że kompozycja
 Cechami charakterystycznymi kompozycji jest to, że klasa
składowa nie może istnieć bez klasy agregującej (części żyją i
umierają wraz z całością) oraz składowa nie może być
współdzielona (obiekt może być częścią dokładnie jednej
kompozycji w danym czasie)
 Przykład: Zajęcia są częścią Przedmiotu. Zajęcia (np.
„laboratorium z BD”) nie mogą istnieć bez Przedmiotu (w tym
przypadku „BD”), którego są częścią.
Diagram klas – związki
Kompozycja
Klasa
agregująca
Symbol
agregacji
Klasa
składowa
Diagram klas – uogólnienie
Relacja uogólnienia jest jednym z elementów nie
występujących w modelowaniu strukturalnym. Reprezentuje
ona informację, że dana klasa (nadklasa) jest uogólnieniem
innej klasy (podklasy).

 Podklasa posiada wszystkie cechy nadklasy oraz cechy
dodatkowe.
Przykład: Klasa „Pracownik” posiada wszystkie cechy klasy
„Osoba”, a ponadto szereg atrybutów dodatkowych,
charakterystycznych tylko dla pracowników.
 Nadklasa i podklasa odnoszą się do tego samego obiektu.
Diagram klas – uogólnienie
Podklasa jest niezależną klasą i dlatego może sama
posiadać podklasy. Wtedy powstaje hierarchia uogólnienia:

– obiekty znajdujące się niżej w hierarchii dziedziczą
atrybuty i związki od obiektów, które są nad nimi;
– uczestnictwo nadklasy w związku uogólnienia jest
zawsze opcjonalne i ma liczebność 1, natomiast
uczestnictwo podklasy w związku uogólnienia jest
zawsze wymagane i ma liczebność
Diagram klas – uogólnienie
 Podklasy rozłączne nie mają żadnych wspólnych
obiektów.
Przykład: Klasy Pracownik administracyjny i Pracownik
techniczny (nadklasa Pracownik) są rozłączne, ponieważ
żaden pracownik nie może być jednocześnie
pracownikiem administracyjnym i technicznym.
 Podklasy przecinające się mogą zawierać wspólne
obiekty.
Przykład: Klasy Student i Pracownik (nadklasa Osoba)
są przecinające się, ponieważ dana osoba może być
jednocześnie studentem i pracownikiem.
Diagram klas – uogólnienie
Klasa
nadrzędna
Symbol
uogólnienia
Klasa
podrzędna
Diagram klas - metody
 Aby można było opisać dynamikę systemu, należy
uzupełnić diagramy klas w modelu strukturalnym o abstrakcję
zachowania: metody.
 Jeśli diagram klas stanowi model bazy danych, to metody
w klasach odpowiadają transakcjom – operacjom
wykonywanym w bazie, które zmieniają dane tak, aby były on
spójne (stan integralności), czyli z zachowaniem więzów
integralności.
 Operacje definiowane przez metody danej klasy
zasadniczo dotyczą klasy, do której należą. Mogą one jednak
także wywoływać metody innych klas.
Pułapki
 Pułapka wachlarzowa – występuje w sytuacji, gdy model
przedstawia związek pomiędzy pewnymi zbiorami encji
(klasami), ale wynikające z tego ścieżki pomiędzy
wystąpieniami encji (obiektami) nie są jednoznaczne; pułapka
taka może wystąpić, gdy co najmniej dwa związki typu 1:*
wychodzą z tej samej encji (klasy)
Problem:
Rozwiązanie:
Pułapki
 Pułapka szczelinowa – występuje gdy model sugeruje
istnienie związku pomiędzy zbiorami encji (klasami), ale nie
istnieje ścieżka łącząca pewne wystąpienia tych encji
(obiekty); pułapka ta może wystąpić, gdy w modelu znajduje
się co najmniej jeden związek o minimalnej krotności zero ,
który jest elementem ścieżki pomiędzy powiązanymi encjami
(klasami)
Problem:
Rozwiązanie:
Dziekuje za uwagę!!!