BD2 wyklad 2

Bazy danych 2

Wykład 2

czyli

Kilka słów o tworzeniu aplikacji

bazodanowej

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.

Metody projektowania baz 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.

Etapy projektowania bazy danych

Zanim utworzymy

model konceptualny

Zanim zrobimy model konceptualny

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

Ograniczenia dziedzinowe



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)

Dane towaru

Unikatowy symbol
towaru

Baza danych

Dane towaru

Użytkownik

Wyjście

Wejście

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)

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

Relacja_A

Klucz_A
AtrybutA1

<pk>

Relacja_B

Klucz_B
Klucz_A
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

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.

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.

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

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

1..1

- Klucz_A

- Klucz_B

RAB

Klucz_A
Klucz_B

<pk>

Reguły transformacji – związki typu 1:1

Uczestnictwo obowiązkowe po jednej stronie związku

Z encji A i B tworzymy schematy relacji RA i RB; do schematu RB wstawiamy

jako dodatkowy atrybut klucz główny ze schematu RA.

1..1

0..1

- Klucz_A

- Klucz_B

Klucz_A <pk>

Klucz_B
Klucz_A

Reguły transformacji – związki typu 1:1

Uczestnictwo opcjonalne po obu stronach związku

0..1

- Klucz_A

- 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

Klucz_A <pk>

Klucz_B <pk>

RAB

Klucz_A
Klucz_B

<pk,fk1>
<pk,fk2>

Reguły transformacji – związki typu 1:1 z
atrybutami

Przypadek gdy związek ma atrybuty

1..1

- Klucz_A

- 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

Klucz_A <pk>

Klucz_B <pk>

RAB

Klucz_A
Klucz_B
Atrybut_Zwiazku

<pk,fk1>
<pk,fk2>

Reguły transformacji – związki rekurencyjne
typu 1:1

Uczestnictwo obowiązkowe po obu stronach związku



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

1..1

Rola1

1..1

Rola2

- Klucz_A

Klucz_A
Rola1_Klucz_A

Reguły transformacji – związki rekurencyjne
typu 1:1

Uczestnictwo opcjonalne po jednej stronie związku



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.

0..1

Rola1

1..1

Rola2

- Klucz_A

Klucz_A <pk>

RAA

Rola1_Klucz_A
Rola2_Klucz_A

<pk,fk1>
<pk,fk2>

Reguły transformacji – związki rekurencyjne
typu 1:1

Uczestnictwo opcjonalne po obu stronach związku



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.

0..1

Rola1

0..1

Rola2

- Klucz_A

Klucz_A <pk>

RAA

Rola1_Klucz_A
Rola2_Klucz_A

<pk,fk1>
<pk,fk2>

Reguły transformacji – związki rekurencyjne typu 1:1
z atrybutami

Przypadek gdy związek ma atrybuty



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.

1..1

Rola1

1..1

Rola2

- Klucz_A

Zwiazek

- Atrybut_Zwiazku

Klucz_A <pk>

RAA

Rola1_Klucz_A
Rola2_Klucz_A
Atrybut_Zwiazku

<pk,fk1>
<pk,fk2>

Reguły transformacji – związki typu 1:*

Uczestnictwo obowiązkowe po stronie wiele związku



Z encji A i B tworzymy schematy relacji RA i RB; do schematu RB

wstawiamy jako dodatkowy atrybut klucz główny ze schematu RA.

1..1

0..*

- Klucz_A

- Klucz_B

Klucz_A <pk>

Klucz_B
Klucz_A

Reguły transformacji – związki typu 1:*

Uczestnictwo opcjonalne po stronie wiele związku

0..1

0..*

- Klucz_A

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

Klucz_A <pk>

Klucz_B <pk>

RAB

Klucz_A
Klucz_B

<pk,fk1>
<pk,fk2>

Reguły transformacji – związki typu 1:* z
atrybutami

Uczestnictwo obowiązkowe po stronie wiele związku



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.

1..1

0..*

- Klucz_A

- Klucz_B

Zwiazek

- Atrybut_Zwiazku

Klucz_A <pk>

Klucz_B
Klucz_A
Atrybut_Zwiazku

Reguły transformacji – związki typu 1:* z
atrybutami

Uczestnictwo opcjonalne po stronie wiele związku

0..1

0..*

- Klucz_A

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

Klucz_A <pk>

Klucz_B <pk>

RAB

Klucz_A
Klucz_B
Atrybut_Zwiazku

<pk,fk1>
<pk,fk2>

Reguły transformacji – związki typu *:* (bez i z
atrybutami)

Uczestnictwo opcjonalne po obu stronach

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

Klucz_A <pk>

Klucz_B <pk>

RAB

Klucz_A
Klucz_B
Atrybut_Zwiazku

<pk,fk1>
<pk,fk2>

0..*

- Klucz_A

- Klucz_B

Zwiazek

- Atrybut_Zwiazku

Reguły transformacji – związki reku-rencyjne typu *:* (bez i z
atrybutami)

Uczestnictwo opcjonalne po obu stronach

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

0..*

Rola1

0..*

Rola2

- Klucz_A

Zwiazek

- Atrybut_Zwiazku

Klucz_A <pk>

RAA

Rola1_Klucz_A
Rola2_Klucz_A
Atrybut_Zwiazku

<pk,fk1>
<pk,fk2>

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:

Zarządza

Personel

Nr_Pracownika <pk>

Nieruchomość

Nr_Nieruchomosci
Nr_Pracownika

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.

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

ENCJE

Charakter fizyczny

np. Personel,
Nieruchomość.

Charakter pojęciowy

np. Wizyta,
Sprzedaż.

Związki



Związek reprezentuje powiązanie między encjami, wynikające z opisu

modelowanego fragmentu rzeczywistości

 Zazwyczaj rozpatrujemy związki binarne, to znaczy łączące jednocześnie
dwie encje. Związki mogą być również wieloelementowe – łączące wiele
encji.

 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”).

Przykład: Biuro zatrudnia Personel

Przykład: Związek binarny - Biuro zatrudnia Personel

Związek potrójny – Personel rejestruje Klienta w Biurze

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



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.



Atrybut złożony – to atrybut zbudowany z wielu składowych z których

każda może istnieć niezależnie.

Przykład: Atrybuty stanowisko i pensja w encji Personel

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.



Atrybut wielowartościowy – to atrybut, który może zawierać wiele

wartosci dla pojedynvczego wystąpienia encji.

Przykład: Atrybut biuroNr w encji Biuro

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

Atrybuty

Klucz kandydujący – to najmniejszy zbiór atrybutów, który jednoznacznie
identyfikuje każde wystąpienie encji w zbiorze encji.

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.

Przykład: Atrybut biuroNr jest kluczem kandydującym dla

zbioru encji Biuro

Klucz złożony – to klucz kandydujący, który składa się co najmniej z dwóch
atrybutów.

Klucze

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.

Pracownik

-
-
-

ID_Pracownika
Im ie
Nazwisko

: int
: String
: String

+
+
+
+

Dodaj_Pacownika ()
Usun_Pracownika ()
Edytuj_Pracownika ()
Ile_pracownikow ()

: int

Nazwa klasy

Lista atrybutów

Typ atrybutu

Sekcja metod

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”);

„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”).

„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”);

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”);

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

(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



asoccjacja n-arna

( w zależności od narzędzia)

Personel

Klient

Biuro

Rejestruje

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

Rola

Liczebność

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



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ę!!!

Wyszukiwarka

Podobne podstrony:
BD2 wyklad 4
BD2 wyklad 3
BD2 wyklad 5
BD2 wyklad 6
BD2 wyklad 1
BD2 wyklad 4
Napęd Elektryczny wykład
wykład5
Psychologia wykład 1 Stres i radzenie sobie z nim zjazd B
Wykład 04
geriatria p pokarmowy wyklad materialy
ostre stany w alergologii wyklad 2003
WYKŁAD VII
Wykład 1, WPŁYW ŻYWIENIA NA ZDROWIE W RÓŻNYCH ETAPACH ŻYCIA CZŁOWIEKA
Zaburzenia nerwicowe wyklad
Szkol Wykład do Or

więcej podobnych podstron