Projektowanie baz danych

Bazy danych
Projektowanie baz danych
31
32
Bazy danych
Przegląd zagadnień
Cykle zycia oprogramowania
Role i sklad zespolu projektowego
Definiowanie wymagan dla systemu
Pojecie encji, atrybutu i zwiazku
Metody przeksztalcania zwiazków
Model relacyjny
Podsumowanie
Laboratorium
Wykład porusza podstawowe elementy inŜynierii oprogramowania,
które uwaŜamy za niezbędne przy budowie i projektowaniu baz danych.
Dowiecie się z niego, co to jest cykl Ŝycia systemów informatycznych, z jakich
etapów składa się praca przy ich wytwarzaniu, jak określać wymagania dla
systemu.
Wprowadzimy teŜ podstawowe pojęcia związane z modelowaniem
konceptualnym bazy danych, takie jak encja, atrybut i związek. Po tym
wykładzie powinniście umieć zbudować model bazy danych na podstawie
opisu wymagań oraz umieć przekształcić go do postaci realizowalnej w modelu
relacyjnym.
Rys. 2.1 Uproszczony cykl Ŝycia projektu budowy systemu informatycznego
Bazy danych
33
Cykle Ŝycia oprogramowania
Glówne etapy cyklu zycia oprogramowania
Modele cyklu zycia oprogramowania
Model wodospadowy
Model spiralny
Model z prototypem
W ostatnich latach znacznie wzrosły moŜliwości technologiczne
wytwarzania i eksploatacji programów komputerowych. Rosną równieŜ
wymagania uŜytkowników oraz stopień złoŜoności problemów, których
rozwiązanie jest wspierane przez systemy informatyczne. Wszystko to
prowadzi do tego, Ŝe oprogramowanie jest coraz bardziej złoŜone, a jego
wytwarzanie coraz bardziej skomplikowane i wymagające większych sił
i środków.
Aby móc sprostać rosnącej złoŜoności oprogramowania projektanci starają się
usystematyzować
działania
związane
z
procesem
wytwarzania
oprogramowania.
SłuŜą temu określone etapy budowy systemów (cykle Ŝycia), właściwa budowa
zespołów projektowych, określanie i dokumentowanie wymagań uŜytkownika,
budowa modeli projektowanego systemu na róŜnych poziomach abstrakcji
w zaleŜności od etapu projektu oraz wiele innych działać związanych
z zarządzaniem projektem informatycznym, testowaniem, wdraŜaniem itp.
W naszym wykładzie zasygnalizujemy jedynie problem złoŜoności
oprogramowania w stopniu niezbędnym do realizacji naszego prostego projektu
bazy danych.
Chcielibyśmy zwrócić uwagę na potrzebę dokumentowania projektu w całym
jego cyklu Ŝyciowym, nawet jeśli projekt jest niewielki i wydaje się być bardzo
prosty. Tworzenie i zarządzanie dokumentacją projektu jest często traktowane
przez programistów jak rzecz zbędna i narzucona przez kierownictwo projektu.
Patrząc z szerszej perspektywy czas poświęcony na dokumentowanie projektu
nie jest czasem straconym, o czym przekonał się na pewno kaŜdy, kto kiedyś
34
Bazy danych
musiał poprawiać coś w cudzym kodzie lub nawet własnym po dłuŜszym czasie
przerwy.
Większość obecnie powstających aplikacji to złoŜone systemy, których nie
moŜna traktować jak proste programy pisane zazwyczaj przez jedna osobę. W
ich realizacji najczęściej bierze udział wiele osób, a realizacja projektu
przebiega zazwyczaj w kilku etapach.
Cały proces zaczyna się od analizy systemu, nazywanej czasem analizą
wymagań, gdyŜ jej celem jest określenie wymagań stawianych systemowi przez
przedsiębiorstwo i uŜytkowników. Po zakończeniu i zatwierdzeniu analizy
systemu odbywa się jego szczegółowe projektowanie.
Po tej fazie następuje planowanie i wycena. Kolejnymi etapami są
implementacja, testowanie i wdroŜenie systemu. Zakończenie cyklu
projektowania następuje po przetestowaniu i udostępnieniu systemu.
Główne etapy cyklu Ŝycia oprogramowania
•
•
•
•
•
Analiza,
Projektowanie,
Implementacja,
Testowanie,
WdroŜenie.
Modele cyklu Ŝycia oprogramowania
MoŜemy wyróŜnić kilka róŜniących się od siebie podejść do cyklu
Ŝycia oprogramowania. NajwaŜniejsze z nich, to:
•
•
•
•
model wodospadowy,
model spiralny,
model przyrostowy zwany równieŜ ewolucyjnym,
model z prototypem.
Model wodospadowy
Przy zastosowaniu tego modelu kaŜdy etap musi być zakończony
i zatwierdzony, aby moŜna było przejść do następnego. Pozwala to w łatwy
sposób kontrolować zarówno czas realizacji projektu, jak równieŜ stronę
finansową, poniewaŜ poszczególne etapy nie zazębiają się wzajemnie.
Dodatkowym atutem jest fakt, Ŝe notacja tego modelu jest przejrzysta
i estetyczna.
Bazy danych
35
Rys. 2.2 Model wodospadowy
PowyŜsze cechy tego modelu są bardzo korzystne dla małych systemów.
Problem pojawia się przy projektach średnich i duŜych systemów, poniewaŜ
model zakłada, iŜ wszystkie potrzebne informacje są dostępne w trakcje
realizacji kaŜdego etapu i nie pozwala uzupełniać ich na dalszych poziomach.
Model nie pozwala równieŜ na zmianę wymagań dotyczących systemu podczas
realizacji projektu, co przy duŜych, ale przede wszystkim długo trwających,
cyklach projektowania jest nie wskazane.
Nie moŜna zakładać, Ŝe podczas tego czasu nie zostaną zmienione Ŝadne
załoŜenia i wymagania dotyczące systemu. Dlatego największą wadą tego
modelu, z punktu widzenia duŜych projektów, jest brak moŜliwości powrotu do
juŜ zakończonego etapu. Jest to bardzo dobitnie podkreślone w nazwie i samym
wyglądzie modelu, który nawiązuje do spływającej wody.
Model spiralny
Model spiralny jest jednym z kilku modeli alternatywnych dla modelu
wodospadowego. Model ten miał minimalizować problemy związane
z poprzednim modelem.
36
Bazy danych
Rys. 2.3 Model spiralny
Zakłada on szereg iteracji modelu wodospadowego, z których kaŜda słuŜy
rozszerzeniu poprzedniej iteracji. Eliminuje to problem powrotu do poprzednich
etapów. Powoduje jednak powstanie niebezpieczeństwa, Ŝe kolejne iteracji
zdezaktualizują wcześniej wykonaną prace.
Ścisłe stosowanie tego modelu powoduje, Ŝe końcowa postać systemu nie jest
znana do późnych etapów realizacji projektu, nie moŜna równieŜ dokładnie
określić czasu trwania cyklu projektowania, jak i nakładów finansowych. Ma to
szczególnie duŜe znaczenie jeŜeli zmiany dotyczą schematu bazy danych, co
ma wpływ na cały system.
Model przyrostowy
Model przyrostowy określany równieŜ jako ewolucyjny, jest pewnego
rodzaju połączeniem dwóch poprzednich modeli. W modelu tym analiza
i ogólny projekt, mający na celu wyodrębnić poszczególne składowe projektu,
jest wykonywany dla całego systemu przy zastosowaniu modelu
wodospadowego, natomiast kolejne etapy są przeprowadzane przy uŜyciu
modelu spirali.
Model ten przez swoją strukturę eliminuje wady zarówno modelu
wodospadowego, jak i spiralnego, przy jednoczesnym zachowaniu zalet obu
powyŜszych modeli.
Model z prototypem
Model ten ma na celu zmniejszenie ryzyka związanego
z niewłaściwym określeniem wymagań uŜytkownika. W rzeczywistości stanowi
on wstęp do modelu kaskadowego.
Bazy danych
37
Rys. 2.4 Model cyklu Ŝycia oprogramowania - Prototypowanie
NajwaŜniejszą zaletą takiego modelu jest zbudowanie prototypu systemu, który
umoŜliwi wykrycie błędów i nieporozumień między klientem a twórcami
systemu oraz wczesne wykrycie brakujących funkcji. Proponuje się aby
w ramach prototypu ująć tylko te funkcje, które są trudne do określenia i mogą
budzić wątpliwości.
Do zalet naleŜy zaliczyć takŜe moŜliwość szybkiej demonstracji przyszłego
systemu oraz moŜliwość przeszkolenia pracowników zanim system zostanie
ukończony i oddany do uŜytku. Wadą tego modelu jest dodatkowy koszt
związany z budową prototypu, poniewaŜ nie jest on częścią przyszłego
systemu. Zakłada się, Ŝe prototyp jest specyficznym sposobem na określenie
wymagań klienta a budowa systemu rozpoczyna się od początku.
W praktyce moŜe się okazać, Ŝe pewne fragmenty są na tyle trafne, Ŝe mogą
być z powodzeniem wykorzystane w dalszej pracy nad systemem.
38
Bazy danych
Role i skład zespołu projektowego
Kierownik projektu
Analityk
Projektant
Programista
Tester
Wdrozeniowiec
Jak juŜ wspomnieliśmy w pierwszej części naszego wykładu złoŜoność
oprogramowania wymusza na nas konieczność pracy zespołowej.
Kto więc powinien brać udział w tworzeniu systemu informatycznego? Zdania
na ten temat są podzielone i moŜemy spotkać się z róŜnymi rolami
w zaleŜności od przyjętej metodyki budowy systemu.
Bazy danych
39
Kierownik projektu
Kierownik projektu jest osobą, która czuwa nad całością projektu, a jej
najwaŜniejszym zdaniem jest organizowanie i kontrolowanie pracy zespołu,
kontaktowanie się z klientem oraz sprawdzanie czy "wszystko idzie dobrze".
Analityk
Głównym zadaniem analityka jest zbudowanie modelu analitycznego
(konceptualnego) systemu. W tym celu musi on stale kontaktować się
z klientem, dla którego budowane jest oprogramowanie oraz dobrze zrozumieć
jego potrzeby i orientować się w dziedzinie problemowej, której dotyczy
system.
Z całą pewnością nie jest to zadanie łatwe i oprócz rozległej wiedzy wymaga
odpowiedniego doświadczenia i umiejętności pracy z ludźmi. Dobrze
wykonany model analityczny ma kluczowe znaczenie dla powodzenia całego
projektu. Błędy popełnione na tym etapie są później trudne do usunięcia
i zazwyczaj bardzo kosztowne.
Projektant
Zadaniem projektanta jest zbudowanie projektu systemu. Projekt
systemu jest kolejnym modelem systemu, ale na innym poziomie
szczegółowości niŜ projekt wykonany przez analityka. Zawiera on bowiem
informacje o szczegółach implementacyjnych systemu. Projektant musi wobec
tego mieć odpowiednią wiedzę na temat systemu na którym będzie
implementowana aplikacja i narzędzi, które zostaną wykorzystane do jej
budowy.
Programista
Zadaniem programisty jest zakodowanie projektu opracowanego przez
projektanta.
Tester
Zadaniem testera jest przeprowadzenie róŜnorodnych testów aplikacji
zanim trafi ona do klienta.
WdroŜeniowiec
WdroŜeniowiec jest osobą, która przeprowadza uruchomienie
(wdroŜenie) aplikacji u klienta. Powinien on równieŜ umieć przeszkolić
uŜytkownika w uŜytkowaniu produktu, a często jest teŜ twórcą dokumentacji
dla uŜytkownika.
W projekcie mogą teŜ wystąpić inne role lub wymienione role mogą być
łączone (np. projektanta i programisty). ZaleŜy to od konkretnych potrzeb,
wielkości projektu i przyjętej metody prowadzenia projektu. W naszym mini
projekcie będziecie musieli przejść przez wszystkie wymienione role
z wyjątkiem roli wdroŜeniowca.
40
Bazy danych
Definiowanie wymagań dla systemu
Techniki badania wymagan uzytkowników
Analiza dokumentacji
Wywiad
Ankieta
Analiza dokumentów (ciagle powstajacych)
Obserwacja (istniejacego systemu)
Pierwszym krokiem na drodze do wykonania aplikacji jest analiza
problemu i określenie wymagań dla budowanego systemu. Na tym poziomie
musimy skupić się na prześledzeniu tego, co mamy w chwili obecnej, na
podstawie czego nasza aplikacja będzie powstawać. Przede wszystkim jednak
naleŜy określić, czemu będzie słuŜyć i jakie wymagania są przed nią stawiane.
Głównym zadaniem analizy jest jasne określenie celu, który chcemy osiągnąć.
Cel systemu nie jest jedyną rzeczą, którą musimy określić podczas analizy
wykonalności systemu.
Analityk musi zdobyć wiedzę na temat projektu i wymagań podczas pracy
z przyszłymi uŜytkownikami i ekspertami danej dziedziny. Jego rolą jest
zdobycie jak największej ilości informacji i danych o tym, jak ma i powinien
wyglądać w przyszłości projektowany system.
Bazy danych
41
Techniki badania wymagań uŜytkowników
Do najczęściej stosowanych metod badań wymagań uŜytkowników naleŜą:
•
•
•
•
analiza dokumentacji,
ankieta,
analiza dokumentów (dynamicznych),
obserwacja.
Przy niewielkich projektach moŜna stosować jedną z powyŜszych metod,
natomiast przy duŜych systemach konieczne jest stosowanie kilku technik
jednocześnie w celu wnikliwego poznania wymagań uŜytkowników.
Analiza dokumentacji
Zapoznanie się z dokumentacją, która funkcjonuje w danym
przedsiębiorstwie, do której zalicza się:
• schemat organizacyjny,
• dokumentację administracyjna,
• specyfikacje stanowisk pracy,
• opis procedur wewnętrznych,
• dokumentacje szkoleniowe,
• dokumentacje istniejących systemów.
Wywiad
Jest to najpopularniejsza metoda, w której analitycy mogą zebrać
i zweryfikować informacje o systemie, zaakceptować rozwiązania, budowane
jest zaufanie uŜytkownika do systemu.
Najczęściej występujące problemy:
•
•
•
wywiad jest przeprowadzony z niekompetentnymi uŜytkownikami,
zadawane są złe pytania, a uzyskiwane odpowiedzi są niepoprawne,
między analitykami a uŜytkownikami są niewłaściwe stosunki (brak
zaufania).
Ankieta
Przeprowadzana jest po wywiadzie (dla potwierdzenia informacji).
Najczęściej występujące problemy przy ankiecie:
•
•
•
róŜna interpretacja pytań - niejednoznaczność odpowiedzi,
podczas ankiety odpowiedzi uzyskujemy tylko od niewielkiej liczby
ankietowanych,
nie wyjaśnia wszystkich wątpliwości.
Analiza dokumentów (ciągle powstających)
Analiza tych dokumentów, które są tworzone w firmie (raporty,
zestawienia).
Taka analiza ma dać odpowiedź na następujące pytania:
Kto tworzy dokumentacje? - źródło.
Jak jest przygotowywany?
42
Bazy danych
Jakie dane z dokumentacji są wykorzystywane?
Kto uŜywa dokumentacji?
Kto wprowadza dane lub z nich korzysta?
Do jakich celów jest uŜywany?
Jak jest przechowywany?
Jak długo jest przechowywany?
Informacja o obiegu istniejących dokumentów w firmie pozwala wyeliminować
niejasności i powtarzające się dokumenty.
Obserwacja (istniejącego systemu)
UmoŜliwia zaobserwowanie elementów, które dla uŜytkownika
niekoniecznie są waŜne (ale mogą być istotne z punktu widzenia tworzonego
SI).
Bazy danych
43
Pojęcie encji, atrybutu i związku
Encja
Atrybut
Zwiazek
Przy modelowaniu baz danych moŜna posłuŜyć się notacją graficzną
modelowania danych - diagramem związków encji (ERD). Jest to model
sieciowy, opisujący na wysokim poziomie abstrakcji dane które są
przechowywane w systemie.
Model ERD budowany jest przez analityka. SłuŜy on do zobrazowania
w sposób zrozumiały zarówno dla projektanta, jak i osoby nie mającej
wykształcenia informatycznego (np. klienta) obiektów i związków
zachodzących w projektowanej dziedzinie problemowej.
Model ERD nie jest związany z konkretną implementacją systemu (np. na
serwerze MS SQL czy Oracle), choć jego odmiany mogą zawierać informacje
specyficzne dla danego języka lub środowiska implementacyjnego. Staje się on
wówczas modelem projektowym
44
Bazy danych
Encja (ang. entity)
Encja jest to coś co istnieje, co odróŜnia się od innych, o czym trzeba
mieć informację. Zbiory encji reprezentują zbiór elementów występujących
w rzeczywistym świecie i kaŜdy element tego zbioru musi posiadać następujące
cechy:
•
•
•
kaŜdy element musi być unikalny, jednoznacznie określony, w celu
odróŜnienia go od pozostałych,
kaŜdy element musi odgrywać jakąś rolę w projektowanym systemie,
nie moŜe zdarzyć się sytuacji, w której system moŜe działać bez
dostępu do danego elementu,
kaŜdy element powinien być opisany przez odpowiednią liczbę
atrybutów.
W diagramach ERD obiekt, encja jest reprezentowany przez prostokąt, a jego
nazwa powinna być rzeczownikiem.
Atrybut (ang. attribute)
Atrybut jest pewną własnością encji, o której chcemy przechowywać
informację. Atrybut jest reprezentowany przez pewną wartość. Na przykład
encja Student moŜe mieć atrybut Nazwisko reprezentowany przez wartość
Kowalski.
Wśród atrybutów encji wyróŜniamy atrybut lub zbiór atrybutów, którego
wartość w sposób jednoznaczny identyfikuje instancję (egzemplarz) encji. Taki
atrybut lub zbiór atrybutów nazywamy kluczem głównym encji. Klucz głowny
oznacza się często na wykresach symbolem PK (ang. Primary Key)
umieszczanym obok nazwy atrybutu.
Rys. 2.5 Przykład definicji kluczy głównych (PK)
Drugim kluczem stosowanym w bazach relacyjnych jest klucz obcy.
Kluczem obcym nazywamy atrybut encji, który wskazuje na klucz główny
innej encji. Klucz obcy oznacza się często na wykresach symbolem FK (ang.
Foreign Key) umieszczanym obok nazwy atrybutu.
Bazy danych
45
Rys. 2.6 Przykład klucza obcego (FK1)
Przykład ilustrujący pojęcie klucza obcego pokazano na rysunku 2.6.
Związek (ang. relationship)
Bardzo waŜnym elementem w modelu danych są związki pomiędzy
encjami i warunki określające te związku - elementy łączące encje między sobą.
Zdecydowana większość związków to powiązania stopnia drugiego - związki
binarne, charakteryzujące się tym, Ŝe w związku bierze udział dwóch
uczestników (dwie encje). Mogą występować takŜe związki unarne (encja
powiązana z samą sobą), jak równieŜ związki ternarne (z trzema
uczestnikami).
W zaleŜności od tego, jakiego typu jest uczestnictwo encji w danym związku,
moŜemy podzielić encje na słabe lub regularne. Encje słabe charakteryzują się
całkowitym uczestnictwem w powiązaniu, to oznacza, Ŝe encja nie moŜe istnieć
bez tego powiązania (np. encja Zamówienia nie moŜe istnieć bez powiązania
z encją Klienci). Natomiast uczestnictwo encji regularnych w związku jest tylko
częściowe, czyli encja moŜe istnieć samodzielnie bez powiązania (np. encja
Klienci moŜe istnieć bez powiązania z encją Zamówienia).
Bardzo istotnym czynnikiem określanym przy związkach jest moc powiązania,
która definiuje się jako maksymalną liczbę instancji jednej encji (wystąpień w
danej encji), które mogą być powiązane z instancją innej encji. Ze względu na
wartość mocy moŜemy wyróŜnić trzy typy powiązań:
•
•
•
jeden-do-jeden,
jeden-do-wiele,
wiele-do-wiele.
Związki binarne:
Związek jeden-do-jeden (jedno-jednoznaczny)
Jest to najprostszy typ powiązania, występuje wtedy, gdy tylko jedna instancja
pierwszej encji jest powiązana z tylko jedną instancją drugiej encji. Jest to
powiązanie wprowadzające dosyć znaczne ograniczenia, gdyŜ warunek jeden
do jednego musi być zawsze spełniony. Opcjonalnie przy powiązaniu jeden
moŜe występować równieŜ opcja Ŝadne, oznaczana graficznie w postaci okręgu.
Rys. 2.7 Związek jeden-do-jeden
46
Bazy danych
Związek jeden-do-wiele (jedno-wieloznaczny)
Najbardziej typowym rodzajem powiązania jest powiązanie jeden-do-wiele,
w którym pojedyncza instancja jednej encji moŜe być połączona z jedną lub
wieloma instancjami drugiej encji. Ze względu na swoją uniwersalność i małą
kłopotliwość, ten typ powiązania jest najczęściej stosowany . Opcjonalnie przy
powiązaniu jeden lub wiele moŜe występować równieŜ opcja Ŝadne, oznaczana
graficznie w postaci okręgu.
Rys. 2.8 Związek jeden-do-wielu
Związek wiele-do-wiele (wielo-wieloznaczny)
Powiązania tego typu występują równie często jak powiązania jeden do wielu,
jednak nie dają się bezpośrednio implementować w relacyjnych bazach danych.
Są one realizowane przy pomocy encji pośrednich (w modelu relacyjnym są to
tabele sprzęgające) powiązanych z encjami pierwotnymi przy pomocy
powiązań jeden do wielu.
W powiązaniu wiele-do-wiele encjami głównymi są encje pierwotne, natomiast
encją obcą jest relacja sprzęgająca, która zwiera klucze główne relacji
oryginalnej. Dlatego w powiązaniu jeden-do-wiele pomiędzy relacjami
pierwotnymi, a relacją obcą, po stronie relacji oryginalnej znajduje się strona
"jeden" powiązania jeden-do-wiele a po stronie relacji obcej znajduje się strona
"wiele" z tego powiązania. Związki wiele-do-wiele nie są bezpośrednio
implementowane w relacyjnych bazach danych i wymagają dodatkowych
przekształceń.
Rys. 2.9 Związek wiele-do-wielu
Związki unarne
Powiązania tego typu mają tylko jednego uczestnika, czyli relację, która jest
powiązana sama ze sobą. Powiązania są realizowane jest w podobny sposób jak
powiązania binarne, z tym Ŝe odnosi się to do jednej encji. Klucz główny tej
encji jest dodawany do tejŜe encji.
Bazy danych
47
Rys. 2.10 Związek unarny
Powiązania unarne tak jak powiązania binarne mogą być róŜnej mocy. To
znaczy mogą występować powiązania jeden do wielu, które mogą być
opcjonalne po stronie "jeden". Ten typ powiązania jest stosowany przy
odwzorowywaniu struktur hierarchicznych.
Powiązania unarne mogą być równieŜ realizowane jako powiązania wiele do
wielu. Wtedy, podobnie jak przy powiązaniach binarnych, muszą być
modelowane przy uŜyciu tabeli sprzęgającej.
Związki ternarne
Są to powiązania w skład których wchodzą trzy związane ze sobą encje.
Powiązania te, podobnie jak powiązania wiele-do-wiele, nie mogą być
realizowane bezpośrednio w relacyjnych bazach danych.
Rys. 2.11 Związek ternarny
Związki ternarne nie są bezpośrednio implementowane w relacyjnych bazach
danych i wymagają dodatkowych przekształceń.
Notacje związków
W praktyce spotkasz się z róŜnymi sposobami reprezentacji graficznej
związków (dla przykładu: w programach słuŜących m.in. do projektowania
diagramów ERD takich jak Visio lub Rational Rose moŜliwe jest uŜycie kilku
róŜnych notacji). Bodaj najpopularniejsza jest notacja czysto graficzna. PoniŜej
prezentujemy sposób, w jaki za pomocą notacji graficznej moŜna oznaczyć typ
powiązania.
48
Bazy danych
Rys. 2.12 Graficzna notacja typów powiązania
Bazy danych
49
Metody przekształcania związków
Przeksztalcanie zwiazków wielo-wieloznacznych
Przeksztalcanie zwiazków ternarnych
Związki binarne wiele-do-wiele oraz związki ternarne nie są
implementowane w relacyjnych bazach danych. Dlatego wymagają one
pewnych przekształceń. Przykłady takich przekształceń zaprezentowane są
poniŜej
50
Bazy danych
Przekształcanie związków wielo-wieloznacznych
Jeśli mamy związek binarny wielo-wieloznaczny, to naleŜy
wprowadzić dodatkową encję oraz dwa nowe związki jednoznaczne. Nowa
encja powinna wśród atrybutów zawierać klucze obce odnoszące się do kluczy
głównych dwóch pozostałych encji.
Rys. 2.13 Przekształcanie związków binarnych wielo-wieloznacznych
Przekształcanie związków ternarnych
Przy przekształcaniu związków ternarnych postępujemy podobnie jak
w wypadku związków wielo-wieloznacznych binarnych. Wprowadzamy
wówczas dodatkową encję oraz 3 nowe związki jednoznaczne.
Rys. 2.14 Przekształcanie związków ternarnych
Podobnie postępujemy jeśli mamy do czynienia ze związkami o większej
liczbie argumentów.
Bazy danych
51
Model relacyjny
Relacje i terminologia zwiazana z modelem relacyjnym
Podstawowe dzialania na relacjach
Normalizacja
W tej części przedstawimy najwaŜniejsze terminy związane z modelem
relacyjnym, omówimy działania na relacjach i schematy relacji. Będzie teŜ
trochę matematyki związanej z działaniami na relacjach. Przedstawimy równieŜ
problemy związane z normalizacją relacji oraz podamy trzy najwaŜniejsze
i najpopularniejsze postacie normalne relacji.
52
Bazy danych
Relacje i terminologia związana z modelem relacyjnym
W klasycznym modelu relacyjnym pod pojęciem relacji rozumie się
dwuwymiarową tablicę.
Rys. 2.15 Relacja jako dwuwymiarowa tablica
Relacja zdefiniowana jest poprzez tak zwany schemat relacji. Schemat relacji
stanowi coś na kształt definicji tabeli. Składa się on z nazwy relacji oraz zbioru
atrybutów relacji.
Określenie schematu relacji wraz z przykładami zapisu relacji pokazane jest na
rysunku 2.16.
Rys. 2.16 Określenie schematu relacji i przykłady zapisu
Do definicji schematu relacji często dodaje się jeszcze określenie dziedzin dla
poszczególnych atrybutów relacji.
Schemat relacji moŜna rozumieć jako pustą tabelę ze zdefiniowaną nazwą oraz
nagłówkami kolumn.
Kolejnym pojęciem jest krotka (inaczej rekord - ang. tuple lub record).
Krotką nazywamy kaŜdy wiersz relacji, oczywiście z wyjątkiem wiersza
nagłówkowego. Krotki mogą być zapisane w postaci uporządkowanego ciągu
albo w postaci zaleŜności funkcyjnych tak jak to jest przedstawione na rysunku.
Pierwszy z tych zapisów wymaga do prawidłowego odczytania krotki
znajomości definicji schematu relacji, jest natomiast znacznie krótszy.
Rys. 2.17 Krotka i jej zapis
Bazy danych
53
Zbiór krotek danej relacji tworzy instancję relacji (ang. recordset). Warto
zwrócić uwagę, Ŝe schemat relacji w czasie cyklu Ŝycia bazy danych jest
w zasadzie niezmienny (lub podlega bardzo rzadkim zmianom), natomiast
instancja relacji moŜe zmieniać się w bazie bardzo często.
W wielu implementacjach systemów baz danych moŜna się spotkać z róŜnym
słownictwem dotyczącym modeli relacyjnych. Na przykład w polskiej wersji
MS Access pod pojęciem relacji rozumie się związek (choć jak wiadomo, oba
pojęcia oznaczają zupełnie co innego), natomiast na określenie relacji stosuje
się pojęcie tabeli (te dwa pojęcia są akurat równowaŜne). Trzeba się więc mieć
na baczności, aby nie pogubić się w tej plątaninie róŜnych pojęć stosowanych
do określenia róŜnych rzeczy.
Podstawowe działania na relacjach
Do podstawowych działań, które moŜemy wykonywać na relacjach naleŜą:
•
•
•
•
•
•
•
•
suma (ang. union),
róŜnica (ang. difference),
przecięcie (ang. engraving),
iloczyn kartezjański (ang. descartes-product),
rzut (ang. projection),
selekcja (ang. selection),
złączenie (ang. join),
złączenie teta (ang. teta join).
Omówimy je krótko i zilustrujemy przykładami.
Suma relacji
Sumą relacji nazywamy relację, której instancja jest suma instancji tych relacji.
Rys. 2.18 Przykład sumy relacji
Uwaga: Aby działanie to było wykonalne, oba schematy relacje muszą mieć te
same zbiory atrybutów.
54
Bazy danych
RóŜnica relacji
RóŜnicą relacji nazywamy relację,
teoriomnogościową instancji tych relacji.
której
instancja
jest
róŜnicą
Rys. 2.19 Przykład róŜnicy relacji
Uwaga: Aby działanie to było wykonalne, oba schematy relacje muszą mieć te
same zbiory atrybutów.
Przecięcie relacji
Przecięciem relacji nazywamy relację, której instancja jest iloczynem
teoriomnogościowym instancji tych relacji.
Rys. 2.20 Przykład przecięcia relacji
Uwaga: Aby działanie to było wykonalne, oba schematy relacje muszą mieć te
same zbiory atrybutów.
Bazy danych
55
Iloczyn kartezjański
Iloczynem kartezjańskim relacji nazywamy relację, której schemat jest sumą
schematów relacji, a jej krotki powstały jako iloczyn kartezjański krotek relacji
wchodzących w skład tego iloczynu.
Rys. 2.21 Przykład iloczynu kartezjańskiego relacji
Rzutowanie relacji
Wartością rzutu ΠA1,A2,...,An(R) jest relacja, która powstaje z R przez przepisanie
wszystkich atrybutów A1, A2, ..., An. Mówimy wówczas o rzutowaniu relacji
w kierunku A1, A2, ..., An. Operacja rzutowania zmienia schemat relacji.
Rys. 2.22 Przykład rzutowania relacji
Selekcja
W wyniku zastosowania operatora selekcji powstaje nowa relacja, do której
naleŜy pewien podzbiór krotek relacji R spełniający warunek F.
56
Bazy danych
Rys. 2.23 Przykład selekcji
Złączenie
Operacja złączenia polega na połączeniu w pary tych krotek z relacji R oraz S,
które mają identyczne wartości dla określonych atrybutów.
Rys. 2.24 Ilustracja złączenia relacji
Złączenie teta
Złączenie teta polega na połączeniu krotek przy spełnieniu określonego
warunku złączenia.
Rys. 2.25 Symbol złączenia teta
Aby utworzyć złączenie teta naleŜy:
1. Utworzyć iloczyn kartezjański R×S,
2. Z iloczynu kartezjańskiego wybrać te krotki, dla których warunek Θ
jest spełniony.
Rys. 2.26 Przykład złączenia teta relacji, przy warunku aby wartości drugiego
atrybutu relacji R były równe wartości atrybutu 1 relacji S
Bazy danych
57
Normalizacja
Normalizacja danych jest sformalizowaną procedurą stosowaną
podczas projektowania bazy danych w celu uniknięcia pewnego typu anomalii,
do których naleŜą:
•
•
•
- redundancja,
- anomalie modyfikacji,
- anomalie usunięć.
Redundancja jest nieuzasadnioną powtarzalnością danych w kilku krotkach.
Skutkiem nadmiernej redundancji moŜe być zwiększone zapotrzebowanie na
pamięć dyskową do przechowywania danych i wydłuŜony czas przeszukiwania
danych.
Anomalie modyfikacji są równieŜ zjawiskiem niepowołanym, poniewaŜ moŜe
się zdarzyć, Ŝe wartość danej zostanie zmodyfikowana w pewnej krotce,
a w innej nie.
Podobne anomalia mogą zachodzić przy usuwaniu danych, ta sama wartość
moŜe nie być usunięta ze wszystkich miejsc, w których występuje. Generalnie
anomalia te poprzez duplikowanie danych powodują brak spójności.
Normalizację modelu danych przeprowadza się poprzez bezstratną
dekompozycję relacji. Sprowadza się ona do podziału atrybutów relacji
pomiędzy schematy nowych relacji. Następnie następuje połączenie
(powiązanie) nowo powstałych relacji między sobą przy pomocy odpowiednich
atrybutów. Reguła dekompozycji obejmuje równieŜ podział krotek relacji
wejściowej między nowe relacje. Połączenie między relacjami powinno być
zrealizowane w taki sposób, aby odbyło się bez straty Ŝadnej informacji
Przy normalizacji danych moŜna przekształcić relację do jednej z sześciu
postaci normalnych.
Pierwsza postać normalna
Relacja jest w pierwszej postaci normalnej, jeŜeli domeny zdefiniowane dla jej
atrybutów są skalarne (atomowe), czyli kaŜdy atrybut krotki musi zawierać
pojedynczą wartość (kaŜde pole w tabeli musi zawierać tylko jeden typ danych
i kaŜdy element musi być przechowywany w jednym miejscu).
Rys. 2.27 Przykład relacji nie będącej w pierwszej postaci normalnej
58
Bazy danych
Rys. 2.28 Przykład relacji w pierwszej postaci normalnej
Druga postać normalna
Relacja jest w drugiej postaci normalnej, jeŜeli jest w pierwszej postaci
normalnej, a ponadto wszystkie jej atrybuty zaleŜą od całego klucza głównego,
a nie od innych pól tabeli.
Rys. 2.29 Przykład przekształcenia relacji do drugiej postaci normalnej
Trzecia postać normalna
Relacja jest w trzeciej postaci normalnej, jeŜeli jest w drugiej postaci
normalnej, a ponadto wszystkie atrybuty niekluczowe są wzajemnie niezaleŜne,
czyli istnieje moŜliwość zmiany jednego pole w tabeli bez konieczności
przeliczania lub zmiany innych pól tejŜe tabeli.
Rys. 2.30 Przykład przekształcenia relacji do trzeciej postaci normalnej
Postać normalna Boyce'a/Codda
Relacja jest postaci normalnej Boyce'a/Codda wtedy i tylko wtedy, gdy kaŜdy
wyznacznik jest kandydatem na klucz.
Jest to odmiana trzeciej postaci normalnej, dotyczy szczególnego rodzaju
relacji, kiedy atrybuty kandydujące na klucz są: wielokrotne, złoŜone lub
nakładają się na siebie.
Bazy danych
59
Czwarta postać normalna
Relacja jest w czwartej postaci normalnej, jeŜeli jest w trzeciej postaci
normalnej i nie zawiera "wielowartościowej zaleŜności" atrybutów.
Piąta postać normalna
Relacja jest w piątej postaci normalnej, jeŜeli jest w czwartej postaci
normalnej, a jej dekompozycja i ponowne połączenie nie są operacjami
symetrycznymi, nie prowadzą do rekonstrukcji tablicy początkowej.
Trzy pierwsze postaci normalne zostały zawarte w modelu relacyjnym
opracowanym przez dr E. F. Codda w 1970 r. i są często stosowane przy
normalizacji danych, natomiast trzy kolejne postaci normalne wykorzystywane
są dosyć rzadko.
Podsumowanie
60
Bazy danych
Cykle zycia oprogramowania
Role i sklad zespolu projektowego
Definiowanie wymagan dla systemu
Pojecie encji, atrybutu i zwiazku
Metody przeksztalcania zwiazków
Model relacyjny
Wytwarzanie oprogramowania jest procesem złoŜonym wymagającym
wielu działań (nie tylko programowania). Przed przystąpieniem do
programowania trzeba rozpoznać i spisać wymagania dla budowanego systemu
oraz wykonać model tego systemu.
Istnieje wiele róŜnych modeli budowanych na róŜnych etapach tworzenia
systemu i róŜnych poziomach szczegółowości. My w czasie budowania na
szych baz danych będziemy budować na początku model związków encji.
Stanowią one koncepcyjny model dziedziny modelowanego systemu.
Bazy danych
Laboratorium
61
62
Bazy danych
Krok 1. Ocena dokumentów wizji systemu
Prowadzący komentuje dokumenty poszczególnych zespołów oraz
przedstawia własną (modelową) wizję systemu Biblioteka
Krok 2. Stworzenie diagramów ERD systemu biblioteka
KaŜdy z uczestników uruchamia MS Visio 2003 (lub ekwiwalentne
oprogramowanie) i na podstawie uzgodnionego opisu systemu Biblioteka
próbuje stworzyć dla niego diagram ERD.
Krok 3. Zapisanie dokumentów
NaleŜy zapisać diagramy we wspólnej bibliotece serwera SharePoint
lub odpowiednika. Sposób nazewnictwa dokumentów powinien być jasno
sprecyzowany.
Krok 4. Omówienie poprawnego diagramu ERD
Prowadzący pokazuje i omawia poprawny diagram ERD dla systemu
Biblioteka