Bazy danych 1

Bazy danych 1
Wykład 4
Metodologia projektowania baz danych
Fazy cyklu Ŝycia aplikacji bazodanowych
Planowanie bazy
danych
Definicja systemu
Gromadzenie i analiza
wymagań
Projektowanie
bazy danych
Konceptualne
projektowanie bazy
danych
Logiczne projektowanie
bazy danych
Fizyczne projektowanie
bazy danych
Projektowanie
aplikacji
Fazy cyklu Ŝycia aplikacji bazodanowych (cd)
Implementacja
Powrót do
początku
Konwersja i
przenoszenie danych
Faza
Testowanie
BieŜąca konserwacja
Cykl Ŝycia aplikacji bazy
danych
Faza
Głłówne czynnoś
ści
Planowanie bazy danych
Planowanie najbardziej skutecznych i wydajnych metod realizacji faz cyklu życia.
Definicja systemu
Okreś
ślenie zakresu i granic stosowania danej aplikacji bazy danych, , wskazanie jej
uż
żytkowników oraz obszarów zastosowań
ń.
Gromadzenie i analiza
wymagań
ń
Zbieranie i analiza wymagań
ń pochodzą
ących od uż
żytkowników i wynikają
ących z
obszarów zastosowań
ń.
Projektowanie bazy danych
Projektowanie konceptualne, logiczne i fizyczne bazy danych.
Selekcja DBMS (opcjonalnie)
Wybór DBMS odpowiedniego dla aplikacji bazy danych.
Projektowanie aplikacji
Projektowanie interfejsów uż
żytkowników i programów uż
żytkowych, które bę
ędą
ą
przetwarzać
ć bazę
ę danych.
Tworzenie prototypów
(opcjonalnie)
Budowanie działłają
ącego modelu aplikacji bazy danych, który pozwala projektantom i
uż
żytkownikom zobrazować
ć i ocenić
ć sposób działłania i wyglą
ąd koń
ńcowego systemu.
Implementacja
Tworzenie zewnę
ętrznych, konceptualnych i wewnę
ętrznych definicji bazy danych i
programów uż
żytkowych.
Konwersja i przenoszenie
danych
Testowanie
Przenoszenie danych ze starego systemu do nowego.
Bieżą
żąca
żą konserwacja
Testowanie i usuwanie błę
łędów
z aplikacji bazy danych oraz sprawdzanie zgodnoś
ści z
łę
wymaganiami uż
żytkowników.
Aplikacja bazy danych jest w pełłni zaimplementowana. System jest na bieżą
żąco
żą
monitorowany i konserwowany. W razie potrzeby do aplikacji bazy danych są
ą
wprowadzane nowe wymagania poprzez ponowne przejś
ście przez powyż
ższe fazy.
Metody projektowania bazy 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 SZBD, 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 SZBD 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.
Metodologie tworzenia systemów
Obecnie stosowane są dwie główne metodologie
tworzenia systemów informatycznych.
Metodologia strukturalna – podejście starsze,
ale ciągle jeszcze rozpowszechnione w praktyce.
Metodologia obiektowa – podejście nowsze,
zdobywające coraz większą popularność na rynku.
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
np. Personel,
Nieruchomość.
Charakter pojęciowy
np. Wizyta,
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
(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
asocjacja
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 pojedynczego 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 pochodzących 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.
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 konceptualne –
przegląd krok po kroku
1.
2.
3.
4.
5.
6.
7.
8.
9.
Określ występujące zbiory encji
Ustal typy występujących związków
Określ atrybuty odpowiadające poszczególnym
encjom
Określ dziedziny poszczególnych atrybutów
Ustal klucze kandydujące i klucze główne
RozwaŜ moŜliwość zastosowania zaawansowanych
metod modelowania
Zweryfikuj utworzony model pod kątem
występowania redundancji
Zweryfikuj moŜliwość realizacji transakcji
Omów konceptualny model z uŜytkownikiem
Projektowanie konceptualne (krok 1)
Określ występujące zbiory encji
Nazwa zbioru
encji
Opis
Aliasy
Własności
Firma
Pojęcie ogólne
opisujące
wszystkie firmy
koncernu
Zakład
Wydział
Pojęcie ogólne
opisujące
wszystkie
oddziały firm
koncernu
KaŜdy oddział naleŜy
do jednej firmy i
Wydział- kaŜdy wydział
zatrudnia
firmy
przynajmniej
jednego pracownika
KaŜda firma ma 4
wydziały
Rozmiar
zbioru
20
80
Projektowanie konceptualne (krok 2)
Ustal typy występujących związków
•
•
•
•
•
UŜywaj diagramów związków encji
Ustal krotności w poszczególnych związkach encji
Sprawdź, czy nie występują pułapki wachlarzowe lub szczelinowe
Sprawdź, czy kaŜdy zbiór występuje przynajmniej w jednym związku
Udokumentuj typy związków
Nazwa
encji
Rola
Krotność
Związek
Nazwa encji
Krotność
Rola
Firma
x
1..1
Ma
Wydział
4..4
x
Wydział
Pracodawca
1..1
1..*
Pracobiorca
Zatrudnia Pracownik
Projektowanie konceptualne (krok 3)
Określ atrybuty odpowiadające
zbiorom encji i związkom
– Potencjalne problemy
• Atrybut naleŜy do więcej niŜ jednego zbioru encji
– Zidentyfikowaliśmy zbiory encji, które powinny być
reprezentowane jako jedna encja
– Wykryliśmy nowy związek między encjami
– Opis atrybutów
Firma
Id_Firmy, Nazwa, Adres_siedziby (złoŜony:
ulica, nr, Kod, Miejscowość), Nr_Wpisu_KRG
Projektowanie konceptualne (krok 3)
Określ atrybuty odpowiadające
zbiorom encji i związkom
– Dokumentowanie informacji o atrybutach
• Nazwa i opis atrybutu
• Typ danych, długość i dziedzina atrybutu
• Wszystkie aliasy danego atrybutu
• Czy atrybut jest złoŜony
• Czy jest to atrybut wielowartościowy
• Czy jest to atrybut pochodny, formuła słuŜąca do wyliczenia
• Domyślna wartość atrybutu
Projektowanie konceptualne (krok 3)
Określ atrybuty odpowiadające
zbiorom encji i związkom
Nazwa
zbioru encji
Atrybuty
Opis
Typ
danych
Długość
Dziedzina
Aliasy
Pracownik
ID_Pracownika
Jednoznacznie
identyfikuje
pracownika
Łańcuch
4
Numer
Personel
Imię
pracownika
Nazwisko
pracownika
Data
urodzenia
pracownika
Łańcuch
maks.
15
maks.
20
Tekst
X
Tekst
X
Data_ur
x
ImięNazwisko
Imię
Nazwisko
DataUrodzenia
Łańcuch
Data
Projektowanie konceptualne (krok 3)
Określ atrybuty odpowiadające
zbiorom encji i związkom
Atrybut
Wartości
puste
Wielowartościowy
Pochodny
Wartość
domyślna
ID_Pracownika
Nie
Nie
Nie
Brak
ImięNazwisko
Imię
Nie
Nie
Nie
Brak
Nazwisko
Nie
Nie
Nie
Brak
Data urodzenia
Tak
Nie
Nie
Brak
Projektowanie konceptualne (krok 4)
Określ dziedziny poszczególnych atrybutów
•
•
•
Dziedzina to zbiór wartości, które moŜe przyjmować
jeden atrybut
Określenie dziedziny powinno obejmować:
–
Dopuszczalny zbiór wartości atrybutu
–
Dopuszczalny zakres długości i format atrybutu
NaleŜy dokumentować zdefiniowane dziedziny w
słowniku danych
Nazwa
dziedziny
Typ
danych
Długość
Format
Dopuszczalny zbiór
wartości atrybutu
Płeć
Znak
1
X
„M” lub „K”
Data
Data_ur
x
rrrr-mm-dd
od 1945-01-01
do data bieŜąca – 18 lat
Projektowanie konceptualne (krok 5)
Ustal klucze kandydujące i klucze główne
• W tym kroku ustalamy klucze kandydujące i klucze główne
• Przy wyborze klucza głównego warto rozwaŜyć
–
–
–
–
–
Klucz o najmniejszej liczbie atrybutów
Klucz, którego wartości najrzadziej ulęgają zmianom
Klucz kandydujący o najmniejszej liczbie znaków
Klucz o najmniejszej wartości maksymalnej
Klucz z którego najłatwiej będzie korzystać uŜytkownikowi
Nazwa encji
Klucze kandydujące
Klucz główny
Firma
Id_Firmy
Nazwa
Nr_Wpisu_KRG
Id_Firmy
Projektowanie konceptualne (krok 5)
Ustal klucze kandydujące i klucze główne
•
Encję nazywamy silną jeśli jej istnienie nie jest zaleŜne od innych zbiorów
encji, cechą charakterystyczną jest jednoznaczna identyfikacja kaŜdego
wystąpienia encji przez atrybut(y) klucza głównego
•
Encję nazywamy słabą jeśli jej istnienie zaleŜy od innych zbiorów encji, cechą
charakterystyczną jest brak jednoznacznej identyfikacji kaŜdego wystąpienia
encji za pomocą atrybutów przypisanych wyłącznie tej encji.
•
Przykład:
Klient
Nr_klienta
•
Określa
Preferencje
Typ_preferencji
Encja Personel nie ma swojego klucza głównego, zidentyfikowanie klucza
głównego tej encji jest moŜliwe dopiero po odwzorowaniu tego zbioru encji na
relacje (klucz obcy)
Projektowanie konceptualne (krok 6)
RozwaŜ moŜliwość zastosowania zaawansowanych
metod modelowania (krok opcjonalny)
• Brak jest ścisłych reguł wskazujących, w jakich sytuacja ch naleŜy
zastosować w modelu związków encji zaawansowane metody
modelowania, wybór jest zazwyczaj subiektywny i zaleŜy od
specyfiki modelowanego zagadnienia.
• Przy wyborze naleŜy kierować się zasadą wyboru jak
najczytelniejszej reprezentacji w diagramie ER dla istotnych zbiorów
encjii związków miedzy nimi.
• Po wykonaniu tego kroku wykonujemy pełny digram związków encji
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.
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ść *
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.
Projektowanie konceptualne (krok 7)
Zweryfikuj utworzony model pod kątem
występowania redundancji
• Ponowne sprawdzenie zwiazków wzajemnie jednoznacznych (1:1)
– W trakcie ustalania występujących zbiorów encji moŜe dojść do utworzenia
dwóch róŜnych zbiorów reprezentujących te same obiekty ze świata
rzeczywistego, naleŜy w tej sytuacji te zbiory encji połączyć
• Usunięcie związków redundantnych
– O związku moŜna powiedzieć, Ŝe jest redundantny (nadmiarowy), jeśli
informacje, których on dostarcza, moŜna uzyskać w oparciu o inny związek.
Związki nadmiarowe mogą zostać usunięte, poniewaŜ nie wnoszą nowej
informacji. Zalecana ostroŜność.
• Sprawdzenie, czy nie występują pułapki wachlarzowe i szczelinowe
Projektowanie konceptualne (krok 8)
Transakcja – to jedna lub kilka operacji odwołujących się do
zawartości bazy danych lub ją modyfikujących, które
przeprowadza pojedynczy uŜytkownik lub aplikacja
Własności transakcji to:
• niepodzielność – transakcja jest wykonywana w całości
albo wcale
• spójność – transakcja zachowuje spójność bazy danych
• izolacja – transakcje, są całkowicie od siebie niezaleŜne
• trwałość – zmiany dokonane przez pomyślnie
zakończoną transakcję są zachowywane na trwale
• Weryfikacji opisanej w punkcie 8 moŜemy dokonać poprzez:
• sporządzenie opisu transakcji
• wykorzystanie ścieŜek transakcji
Na tę chwilę to koniec (uff)
c.d.n.
Dziękuję za uwagę!