ITA 101 Modul 01

background image

ITA-101 Bazy danych

Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski

Moduł 1

Wersja 1.0

Budowa diagramów ERD

Spis treści

Budowa diagramów ERD ..................................................................................................................... 1

Informacje o module ........................................................................................................................... 2

Przygotowanie teoretyczne ................................................................................................................. 3

Przykładowy problem ................................................................................................................. 3

Podstawy teoretyczne ................................................................................................................. 3

Przykładowe rozwiązanie ............................................................................................................ 7

Porady praktyczne .................................................................................................................... 12

Uwagi dla studenta ................................................................................................................... 13

Dodatkowe źródła informacji .................................................................................................... 13

Laboratorium podstawowe ............................................................................................................... 14

Problem (czas realizacji 40 min) ................................................................................................ 14

Laboratorium rozszerzone ................................................................................................................ 16

Zadanie 1 (czas realizacji 45 min) .............................................................................................. 16

Zadanie 2 (czas realizacji 45 min) .............................................................................................. 16

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 2/18

Informacje o module

Opis modułu

W tym module zajmiemy się pierwszym krokiem, jaki należy wykonad
projektując bazę danych. Będzie nim identyfikacja encji i narysowanie na
diagramie, zwanym diagramem ERD, zależności między nimi. Prawidłowy
i przejrzysty diagram ERD jest kluczowym czynnikiem sukcesu dla
zaprojektowania, a później eksploatacji bazy danych.

Cel modułu

Celem modułu jest wykształcenie umiejętności budowania poprawnych,
przejrzystych

i dobrze

udokumentowanych

diagramów

ERD

z wykorzystaniem narzędzia MS VISIO.

Uzyskane kompetencje

Po zrealizowaniu modułu będziesz:

rozumiał, czym jest diagram ERD,

rozumiał, w jaki sposób buduje się diagramy związków encji na
różnych poziomach abstrakcji,

umiał zbudowad poprawny diagram ERD,

umiał dokonad przekształcenia diagramu ERD tak, aby był on
implementowany w relacyjnej bazie danych.

Wymagania wstępne

Przed przystąpieniem do pracy z tym modułem powinieneś:

rozumied, czym jest baza danych i jakie powinna mied cechy,

znad założenia modelu relacyjnego baz danych.

Mapa zależności modułu

Przed przystąpieniem do realizacji tego modułu nie są wymagane inne
moduły.

Moduł 1

Dodatek

Moduł 2

Moduł 3

Moduł 4

Moduł 5

Moduł 6

Moduł 7

Moduł 8

Moduł 9

Moduł 10

Moduł 11

Moduł 12

Moduł 13

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 3/18

Przygotowanie teoretyczne

Przykładowy problem

Wyobraź sobie, że zostałeś poproszony o przygotowanie bazy danych ułatwiającej zarządzanie
przydziałem sal i zajęd na swoim wydziale na uczelni. Pani Jola zajmująca się przydzielaniem sal na
zajęcia chciałaby uzyskad narzędzie do kontroli i monitorowania obciążenia sal przez różne zajęcia
dydaktyczne oraz chciałaby przy tej okazji zminimalizowad liczbę popełnianych błędów. Błędy
polegają najczęściej na tym, że w jednej sali umieszczane są w tym samym czasie różne zajęcia lub
na tym, że ta sama grupa studencka ma zajęcia w różnych salach w jednym czasie. Pani Jola
chciałaby też mied możliwośd szybkiego generowania raportów o przydziale sal i zajęd. Dla
uniknięcia nieporozumieo przy pracach nad narzędziem wspomagającym pracę pani Joli zostałeś
poproszony o przygotowanie prostego i krótkiego dokumentu przedstawiającego, jakie dane będą
gromadzone w bazie danych i jakie będą między nimi zależności. Dokument ten powinien zostad
zweryfikowany i zaakceptowany przez panią Jolę przed przystąpieniem do dalszych prac.

Podstawy teoretyczne

Przy modelowaniu baz danych możemy posłużyd się notacją graficzną modelowania danych –
diagramem związków encji (ERD, ang. Entity-Relationship Diagram). 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 niemają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), chod jego odmiany mogą zawierad informacje specyficzne dla danego języka lub
środowiska implementacyjnego. Staje się on wówczas modelem projektowym

Encja
Encja
(ang. entity) jest to coś, co istnieje, co odróżnia się od innych, o czym trzeba mied informacje.
Zbiory encji reprezentują zbiór elementów występujących w rzeczywistym świecie i każdy element
tego zbioru musi posiadad następujące cechy:

Każdy element musi byd unikalny, jednoznacznie określony, w celu odróżnienia go od
pozostałych.

Każdy element musi odgrywad jakąś rolę w projektowanym systemie, nie może zdarzyd się
sytuacji, w której system może działad bez dostępu do danego elementu.

Każdy element powinien byd opisany przez odpowiednią liczbę atrybutów.

W diagramach ERD encja jest reprezentowana przez prostokąt, a jej nazwa powinna byd
rzeczownikiem.

Atrybut
Atrybut
(ang. attribute) jest pewną własnością encji, o której chcemy przechowywad informacje.
Atrybut jest reprezentowany przez pewną wartośd. Na przykład encja Student może mied atrybut
Nazwisko reprezentowany przez wartośd Kowalski.

Wśród atrybutów encji wyróżniamy jeden atrybut lub zbiór atrybutów, którego wartośd w sposób
jednoznaczny identyfikuje instancję (egzemplarz) encji. Taki atrybut lub zbiór atrybutów nazywamy
kluczem głównym encji. Klucz główny oznacza się często na wykresach symbolem PK (ang. Primary
Key
) umieszczanym obok nazwy atrybutu.

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 4/18

Drugim rodzajem klucza 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.

Rys. 1. Przykład klucza obcego (FK1)

Związek

Bardzo ważnym elementem w modelu danych są związki (ang. relationship) pomiędzy encjami
i warunki określające te związki – elementy łączące encje między sobą. Zdecydowana większośd
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ępowad 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 podzielid
encje na słabe lub regularne. Encje słabe charakteryzują się całkowitym uczestnictwem
w powiązaniu, to oznacza, że encja nie może istnied bez tego powiązania (np. encja Zamówienia
nie może istnied bez powiązania z encją Klienci), natomiast uczestnictwo encji regularnych
w związku jest tylko częściowe, czyli encja może istnied samodzielnie bez powiązania (np. encja
Klienci może istnied 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ąpieo w danej encji), które mogą byd powiązane
z instancją innej encji. Ze względu na wartośd mocy możemy wyróżnid trzy typy powiązao:

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 dosyd znaczne
ograniczenia, gdyż warunek jeden do jednego musi byd zawsze spełniony. Opcjonalnie przy
powiązaniu jeden może występowad również opcja żadne, oznaczana graficznie w postaci okręgu.

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 byd połączona z jedną lub wieloma instancjami drugiej encji. Ze względu
na swoją uniwersalnośd i małą kłopotliwośd, ten typ powiązania jest najczęściej stosowany.
Opcjonalnie przy powiązaniu jeden lub wiele może występowad również opcja żadne, oznaczana
graficznie w postaci okręgu.

Rys. 2. Związek jeden-do-wielu

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 5/18

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 implementowad 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ązao 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łceo.

Rys. 3. 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ązanie realizowane jest w podobny sposób jak w przypadku powiązao binarnych, ale
odnosi się do jednej encji. Klucz główny tej encji jest dodawany do tej encji.

Rys. 4. Związek unarny

Powiązania unarne tak jak powiązania binarne mogą byd różnej mocy. To znaczy mogą występowad
powiązania jeden do wielu, które mogą byd opcjonalne po stronie „jeden”. Ten typ powiązania jest
stosowany przy odwzorowywaniu struktur hierarchicznych.

Powiązania unarne mogą byd również realizowane jako powiązania wiele do wielu. Wtedy,
podobnie jak przy powiązaniach binarnych, muszą byd 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ą byd realizowane bezpośrednio w relacyjnych bazach
danych.

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 6/18

Rys. 5. Związek ternarny

Związki ternarne nie są bezpośrednio implementowane w relacyjnych bazach danych i wymagają
dodatkowych przekształceo.

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 IBM Rational
Rose możliwe jest użycie kilku różnych notacji). Bodaj najpopularniejsza jest notacja czysto
graficzna.

Metody przekształcania związków

Związki binarne wiele-do-wiele oraz związki ternarne nie są implementowane w relacyjnych bazach
danych. Przed zamodelowaniem ich w bazie relacyjnej wymagają one pewnych przekształceo.
Przykłady takich przekształceo zaprezentowane są poniżej

Przekształcanie związków wielo-wieloznacznych

Jeśli mamy związek binarny wielo-wieloznaczny, to należy wprowadzid dodatkową encję oraz dwa
nowe związki jednoznaczne. Nowa encja powinna wśród atrybutów zawierad klucze obce
odnoszące się do kluczy głównych dwóch pozostałych encji.

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

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 7/18

Rys. 7. Przekształcanie związków ternarnych

Podobnie postępujemy, jeśli mamy do czynienia ze związkami o większej liczbie argumentów.

Podsumowanie
W tym rozdziale przedstawione zostało podejście do modelowania konceptualnego bazy danych
z wykorzystaniem techniki zwanej diagramami związków encji.

Dowiedziałeś się, czym jest encja, jakie posiada cechy oraz czym jest związek encji. Pamiętaj, że nie
wszystkie typy związków encji są bezpośrednio implementowane w relacyjnej bazie danych. Związki
typu wiele do wielu oraz związki więcej niż dwu encji wymagają przekształcenia modelu
konceptualnego do postaci dającej się implementowad w modelu relacyjnym. Przekształcenie to
polega zazwyczaj na wprowadzeniu dodatkowej encji i dodaniu nowych związków.

Projektując bazę danych warto zawsze rozpocząd modelowanie danych od diagramów ERD.
Diagramy takie powinny przede wszystkim, w pierwszym etapie projektowania, odzwierciedlad
w możliwie przejrzysty sposób dane i zależności występujące w świecie rzeczywistym – na przykład
obiekty biznesowe i zależności między nimi. W pierwszym etapie diagram ERD pokazuje więc często
związki wiele do wielu oraz związki wieloencyjne (rzadziej). Kolejne kroki prowadzą do
przekształcania takiego diagramu aż do postaci modelu zgodnego z modelem relacyjnym.

Przykładowe rozwiązanie

Przypomnijmy problem z początku tego rozdziału dotyczący przygotowania bazy danych
ułatwiającej zarządzanie przydziałem sal i zajęd na wydziale uczelni.

Naszym celem jest przygotowanie modelu danych, który będzie spełniał dwa podstawowe cele:

pozwalał zweryfikowad wymagania stawiane przez panią Jolę oraz

stanowił podstawę do zbudowania relacyjnej bazy danych.

Jak widad musimy posłużyd się językiem wyrazu zrozumiałym zarówno dla osoby niemającej
wykształcenia czy tez doświadczenia informatycznego jak i przydatnym dla informatyka budującego
bazę danych. Jaki środek wyrazu, język wybrad? Dosyd powszechny jest tutaj pogląd, że takim
uniwersalnym środkiem wyrazu spełniającym stawiane przed nami wymagania jest język
obrazkowy – diagramy związków encji.

Sformułujmy więc teraz cel naszych działao w następujący sposób:

Naszym zadaniem jest opracowanie diagramu związków encji, który będzie jednoznacznie
i przejrzyście przedstawiał wymagania pani Joli w zakresie przetwarzanych przez nią danych oraz
umożliwiał zbudowanie na jego podstawie relacyjnej bazy danych.

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 8/18

Przypominamy, że diagram związków encji powstaje w sposób iteracyjny. Wynikiem naszych prac
powinien byd nie jeden diagram, ale zestaw diagramów przedstawiający nasz problem na różnych
poziomach abstrakcji (np. z różną liczbą szczegółów).

Spróbujemy teraz przedstawid w punktach nasze działania. Co więc i w jakiej kolejności powinniśmy
wykonad?

Krok 1
Powinniśmy uważnie wysłuchad, co ma do powiedzenia ekspert dziedzinowy, czyli pani Jola. Na
podstawie zebranych informacji możemy zidentyfikowad i wypisad encje występujące w naszym
problemie. Dobrym zwyczajem jest też wypisanie kilku przykładowych instancji encji dla każdej ze
zidentyfikowanych encji.

Krok 2
Powinniśmy zidentyfikowad związki występujące między encjami. Dobrze jest nazwad te związki
i określid role, jakie w nich odgrywają poszczególne encje. Koniecznie powinniśmy też
zidentyfikowad liczności związków.

Krok 3
Powinniśmy wykonad pierwszy rysunek diagramu związków encji, na którym zamieszczamy:

nazwa encji,

związki między encjami,

liczności związków.

Warto też umieścid na nim nazwy związków i nazwy ról. Często jednak dla zachowania
przejrzystości rysunku rezygnujemy z umieszczania na diagramie ERD tych informacji.

UWAGA: Diagram związków encji będący wynikiem kroku 3 jest często w postaci
nieznormalizowanej i nierealizowalnej w bazie relacyjnej (np. przedstawia związki wiele do wielu).
Na tym etapie najczęściej nie należy dokonywad przekształceo tego diagramu.

Krok 4
Diagram z kroku 3 powinniśmy skonsultowad z ekspertem dziedzinowym. Na tym etapie diagram
ERD nie zawiera zbyt wiele szczegółów, jest więc prosty i przejrzysty. Pozwoli nam to na
upewnienie się, że dobrze zrozumieliśmy stawiane przez eksperta wymagania dotyczące
przetwarzanych danych oraz umożliwi dokonanie niezbędnych poprawek i uzupełnieo już na tym
wstępnym etapie.

Krok 5
Rozpoczynamy identyfikowanie atrybutów dla każdej z przedstawionych na diagramie encji.
Powinniśmy zidentyfikowad wszystkie atrybuty, które są wykorzystywane w procesach
opisywanych przez eksperta dziedzinowego – czyli tak zwane atrybuty biznesowe. Nie wszystkie ze
zidentyfikowanych na tym etapie atrybutów muszą znaleźd swoje odzwierciedlenie w koocowym
projekcie bazy danych.

Na przykład: na pewnym wydziale po drugim roku studiów dokonywany jest przez studenta wybór
specjalizacji dalszych studiów. O klasyfikacji na specjalizację decyduje, w wypadku braku miejsc,
średnia ocen uzyskanych przez studenta z pierwszych czterech semestrów studiów. Dla osoby
opisującej proces klasyfikacji studentów na specjalizację istotnym atrybutem każdego studenta jest
jego średnia z pierwszych czterech semestrów nauki. Powinniśmy dla encji Student
zidentyfikowad atrybut biznesowy srednia_z_czterech_semestrow. W trakcie kolejnych
iteracji budowy diagramu ERD możemy zdecydowad, że nie będziemy przechowywad w bazie tej
średniej, ale wyliczad ją, gdy będzie potrzebna, na podstawie ocen cząstkowych.

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 9/18

Krok 6
Diagram z kroku 5 powinniśmy skonsultowad z ekspertem dziedzinowym.

Krok 7
Dla każdego atrybutu powinniśmy zidentyfikowad i zapisad jego dziedzinę. Pamiętaj, że dziedzina
atrybutu to nie to samo, co jego typ. Dziedzina związana jest z wyższym poziomem abstrakcji
modelu i dotyczy wartości, które może przyjmowad atrybut wynikających z modelu biznesowego
procesu. Typ natomiast związany jest z niższym poziomem abstrakcji modelu i dotyczy
reprezentacji danych w silniku bazy danych. Na przykład dziedziną dla atrybutu Ocena może byd
zbiór { 2; 3; 3,5; 4; 4,5; 5 }, a typem tego atrybutu Integer.

Krok 8
Diagram lub tabelę z kroku 7 powinniśmy skonsultowad z ekspertem dziedzinowym.

Krok 9
Po zaakceptowaniu diagramu związków encji przez eksperta dziedzinowego możemy przystąpid do
normalizacji, określenia kluczy głównych i kluczy obcych, dokonad zmian atrybutów (na przykład
dodad atrybuty sztuczne) oraz przekształcenia związków nierealizowalnych w modelu relacyjnym
(np. zamiana związków wiele do wielu na związki jedne do wielu).

Krok 10
Proponujemy aby w tym kroku określid typy wszystkich atrybutów uwzględniając typy silnika bazy
danych, na której będzie realizowana baza danych, zdefiniowad niezdefiniowane jeszcze klucze
główne i klucze obce oraz wskazad pola indeksowane.

Na zakooczenie powinniśmy dokonad przeglądu diagramu ERD pod kątem jego spójności
i kompletności. W naszym wypadku zadanie jest dosyd proste, gdyż problem, z którym mamy do
czynienia nie jest skomplikowany. Przystępujemy więc do kolejnych kroków budowy diagramu ERD.

Krok 1
Po spotkaniu z panią Jolą identyfikujemy trzy encje: Sala, Zajecia i Grupa.

Przygotowujemy też zestawienie przykładowych instancji encji.

Tabela 1. Zestawienie instancji encji
Encja

Sala

Zajęcia

Grupa

Przykład

instancji

encji

110

C155

A001

Bazy danych – wykład

Bazy

danych

laboratorium

Podstawy informatyki

Programowanie
obiektowe

101

112

203

315c

Krok 2
Identyfikujemy związki:

Tabela 2. Liczności związków
Nazwa związku

Encje

Liczności

Zajecia_w_Sali

Sala, Zajęcia

Wiele do jeden (*..1)

Grupa_na_zajeciach

Grupa, Zajęcia

Wiele do wiele (*..*)

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 10/18

Krok 3
Przedstawiamy diagram ERD z uwzględnieniem związków i ich liczności.

Sala

Zajecia

Grupa

Rys. 8. Diagram ERD z uwzględnieniem związków i ich liczności

Krok 4
Pani Jola po obejrzeniu naszego diagramu zauważa, że mogą byd zajęcia, które w danym semestrze
nie odbywają się, ale znajdują się w katalogu zajęd (np. przedmiot obieralny, który nie został
w danym semestrze wybrany przez wystarczającą liczbę chętnych). Nie są one przypisane do żadnej
sali ani do grupy studentów.

Dostrzegamy też błąd polegający na początkowym przypisaniu do konkretnej sali tylko jednych
zajęd. Oczywiście na taki luksus żaden wydział nie może sobie pozwolid. Zamieniamy licznośd
związku Zajęcia_w_Sali na wiele do wielu.

Uwagę tę powinniśmy uwzględnid na naszym diagramie ERD. Wprowadzamy stosowną poprawkę
na diagramie.

Sala

Zajecia

Grupa

Rys. 9. Diagram ERD po uwzględnieo poprawy liczności związku

Krok 5
Przystępujemy do identyfikacji atrybutów. Wygodnie jest informacje o atrybutach zebrad w tabeli
podając jednocześnie przykład wartości atrybutu.

Tabela 3. Przykładowe wartości atrybutów
Encja

Atrybut

Przykład

Sala

Numer Sali

C101

Liczba miejsc

120

Zajecia

Nazwa zajęć

Bazy danych – wykład

Grupa

Nazwa grupy

112

Liczność

35

Na diagramie ERD:

Sala

Numer sali
Liczba miejsc

Zajecia

Nazwa zajęć

Grupa

Nazwa grupy

Liczność

Rys. 10. Diagram ERD z zaznaczonymi atrybutami

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 11/18

Krok 6
Pokazujemy nasz diagram ERD pani Joli. Jeśli zostanie on zaakceptowany, przechodzimy do kroku
siódmego.

Krok 7
Powinniśmy teraz określid dla każdego atrybutu jego dziedzinę. Najwygodniej będzie nam to
wykonad znowu w postaci tabelki takiej jak tabela xxx uzupełnionej o kolumnę Dziedzina atrybutu.

Tabela 4. Dziedziny atrybutów

Encja

Atrybut

Przykład

Dziedzina atrybutu

Sala

Numer
sali

C101

Ciąg

składający

się

z litery

reprezentującej budynek oraz co
najwyżej czterech cyfr

Liczba
miejsc

120

Przedział od 15 do 250

Zajecia Nazwa

zajęć

Bazy danych – wykład

Lista zajęd

Grupa

Nazwa
grupy

112

Ciąg składający się z 3 lub 4 cyfr
i/lub litery

Liczność 35

Przedział od 12 do 40

Krok 8
Powinniśmy znowu skonsultowad wyniki naszej pracy z panią Jolą. Jeśli uzyskamy akceptację,
możemy przejśd do kroku dziewiątego. W przeciwnym razie nanosimy poprawki i ponownie
prosimy o akceptację.

Krok 9
Jeśli dobrnęliśmy aż tutaj, to oznacza, że zakooczyliśmy konsultację z panią Jolą i możemy
przystąpid do prac zmierzających do nadania naszemu modelowi postaci dającej się
zaimplementowad w relacyjnej bazie danych.

W naszym diagramie ERD występują związki wiele do wiele. Są to związki nieimplementowane
bezpośrednio w modelu relacyjnym, dlatego musimy dokonad ich przekształcenia. Wprowadzamy
nowe encje ObciazenieSali i ZajeciaGrupy tak jak na rysunku.

Sala

PK

ID_Sala

Numer sali

Liczba miejsc

Zajecia

PK

ID_Zajecia

Nazwa zajęć

Grupa

PK

ID_Grupa

Nazwa grupy

Liczność

ZajeciaGrupy

PK,FK1

ID_Zajecia

PK,FK2

ID_Grupa

ObciazenieSali

PK,FK1

ID_Sala

PK,FK2

ID_Zajecia

Dzien

GodzinaOd

GodzianDo

Rys. 11. Diagram ERD

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 12/18

Informację na diagramie możemy uzupełnid o typy danych, tak jak przedstawiamy to na Rys. 12.
Diagram ERD z typami danych

Sala

PK

ID_Sala

uniqueidentifier

Numer sali

varchar(6)

Liczba miejsc

uniqueidentifier

Zajecia

PK

ID_Zajecia

uniqueidentifier

Nazwa zajęć

varchar(255)

Grupa

PK

ID_Grupa

uniqueidentifier

Nazwa grupy

char(10)

Liczność

smallint

ZajeciaGrupy

PK,FK1

ID_Zajecia

int

PK,FK2

ID_Grupa

int

ObciazenieSali

PK,FK1

ID_Sala

int

PK,FK2

ID_Zajecia

int

Dzien

char(10)

GodzinaOd

char(10)

GodzianDo

char(10)

Rys. 12. Diagram ERD z typami danych

Krok 10
W ostatnim kroku dokonujemy przeglądu naszego modelu ERD. Rzadko kiedy pierwsze podejście
będzie całkowicie wolne od błędów, pomyłek czy niedopatrzeo, dlatego zawsze należy
przeprowadzid weryfikację poprawności diagramu.

Porady praktyczne

Pamiętaj, że diagram związków encji ma byd zrozumiały nie tylko dla informatyka. Ma on
służyd dialogowi między projektantem a użytkownikiem, który formułuje wymagania dla
przyszłej bazy danych. Modelując dane należy posługiwad się jasnym, prostym i przejrzystym
językiem i formami wyrazu.

Budując diagram związków encji nie spiesz się. Nie dokonuj zbyt pochopnie przekształceo
i nie wprowadzaj od razu zbyt wielu szczegółów, nawet jeśli przekształcenia wydają Ci się
oczywiste, a definiowanie typów danych czy określanie kluczy natychmiastowe. Pamiętaj, że
kluczowym elementem budowanych diagramów jest ich czytelnośd i zrozumiałośd dla osoby
definiującej wymagania, czyli tak zwanego eksperta dziedzinowego (w każdym razie
w początkowych etapach tworzenia diagramów ERD).

Przy identyfikowaniu encji bardzo zachęcamy do tego, aby zawsze wypisad kilka przykładów
instancji encji. Podejście to pozwala na lepsze zrozumienie świata rzeczywistego i weryfikację
poprawności identyfikacji encji. Nazwa encji często nie oddaje jej istoty i może byd różnie
rozumiana przez różne osoby biorące udział w budowaniu modelu danych. Szybko docenisz
tę technikę podczas dialogu z przyszłym użytkownikiem bazy, który z pewnością będzie lepiej
rozumiał prezentowane przez Ciebie modele.

Rysowanie diagramów związków encji najlepiej zacząd od rysowania na dużej kartce papieru
lub tablicy. Dopiero pod koniec (krok 9) warto jest przenieśd diagramy związków encji do
narzędzia wspomagającego pracę z diagramami ERD. Narzędzi takich jest wiele. My
proponujemy wykorzystad do tego celu program MS Visio – znany i wygodny program do
rysowania wyposażony w specjalny moduł wspomagający projektowanie baz danych.

Zwracamy uwagę, że w teorii relacyjnych baz danych pod pojęciem relacji rozumie się
dwuwymiarową tabelę danych. Tabele te odpowiadają na etapie projektowym pojęciu encji,
natomiast powiązania między tabelami (encjami) noszą nazwę związków. W niektórych
aplikacjach i w żargonie informatycznym słowo relacja ma jednak czasem inne znaczenie

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 13/18

i oznacza powiązanie między tabelami (encjami), czyli związek. Takie nazewnictwo
stosowane jest na przykład w polskich wersjach aplikacji firmy Microsoft.

Ostateczny projekt bazy danych zależy w istotnym stopniu od zwyczajów i upodobao
projektanta. Modele ERD bazy danych zbudowane dla tego samego problemu mogą się
różnid. Nie zawsze potrafimy jednoznacznie wskazad, który z modeli jest lepszy. Często są
one po prostu jednakowo dobre.

Zwród uwagę, że notacja proponowana przez nas w tym module nie jest jedyną notacją
stosowaną przy modelowaniu danych. Popularnośd zyskuje modelowanie baz danych
z wykorzystaniem języka UML. Modelowanie w języku UML bazuje na podejściu obiektowym
do analizy i projektowania systemów. Chod założenia, na których opiera się modelowania
diagramami ERD i językiem UML są inne, to jednak ogólna droga postępowania jest bardzo
podobna. Jeśli znasz język UML i zasady modelowania obiektowego, to do projektowania baz
danych możesz zamiast diagramów ERD wykorzystad diagramy klas języka UML.

Uwagi dla studenta

Jesteś przygotowany do realizacji laboratorium, jeśli:

rozumiesz, czym jest encja i związek między encjami,

rozumiesz, na czym polega proces dochodzenia do koocowego diagramu związków encji,

umiesz dokonad przekształcenia związków nieimplementowanych w relacyjnych bazach
danych do związków binarnych jednoznacznych,

potrafisz przedstawid diagram ERD na różnym poziomie abstrakcji,

wiesz, jakie jest znaczenie słowa relacja w teorii relacyjnych baz danych i w żargonie
informatycznym.

Pamiętaj o zapoznaniu się z uwagami i poradami zawartymi w tym module. Upewnij się, że
rozumiesz omawiane w nich zagadnienia. Jeśli masz trudności ze zrozumieniem tematu zawartego
w uwagach, przeczytaj ponownie informacje z tego rozdziału i zajrzyj do notatek z wykładów.

Dodatkowe źródła informacji

1. Rebeca R. Riordan, Projektowanie relacyjnych baz danych, Microsoft Press, 2000

Książka poświęcona jest praktycznym aspektom projektowania relacyjnych baz
danych w środowisku aplikacji firmy Microsoft. Znajdziesz w niej między innymi
przegląd modeli normalizacyjnych, których nie omawialiśmy w tym module
bezpośrednio. Rebeca Riordan znana jest z łatwego i zrozumiałego języka i łatwości
tłumaczenia zagadnieo trudnych. Ten swój talent wykorzystuje również w tej
pozycji. Jeśli nie interesuje Cię zgłębianie teoretycznych podstaw działania baz
danych, a bardziej nastawiony jesteś na praktyczne wykorzystanie wiedzy, to jest to
książka dla Ciebie.

2. C.J.Date, Wprowadzenie do systemów baz danych, WNT, 2000

Jest to pełny podręcznik do wykładu z baz danych znanego i cenionego na całym
świecie autora. Znajdziesz w nim szersze spojrzenie na problematykę budowy
i modelowania baz danych. Polecamy ją wszystkim, którzy chcieliby poszerzyd
swoje wiadomości z tego zakresu.

3. System pomocy programu Visio

Jeśli po raz pierwszy spotykasz się z programem Visio, to zajrzyj koniecznie do jego
systemu pomocy. Znajdziesz tam wszystkie niezbędne informacje, aby efektywnie
korzystad z tego oprogramowania.

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 14/18

Laboratorium podstawowe

Problem (czas realizacji 40 min)

Jesteś projektantem bazy danych. W wyniku spotkao z ekspertem dziedzinowym (przyszłym
użytkownikiem bazy) opracowałeś model diagramu związków encji opisany w rozdziale
Przykładowe rozwiązanie. Model i wszystkie dodatkowe dane (np. tabele) zostały zapisane jedynie
na papierze. Teraz warto jest przenieśd tę dokumentację „do komputera”. Umożliwi to łatwiejszą
archiwizację modelu, wprowadzanie zmian i wymianę informacji między członkami zespołu.
Dodatkowo może też skrócid czas projektowania bazy danych dzięki wykorzystaniu narzędzi RAD
(ang. Rapid Application Design). Jako aplikację wspomagającą prace na tym etapie budowy modelu
bazy danych wybrana została aplikacji MS Viso 2007. Twoim zadaniem będzie utworzenie przy
pomocy tego programu modelu danych i diagramu ERD zgodne z wymaganiami „papierowymi”.

Zadanie

Tok postępowania

1. Uruchom
projekt bazy
danych
w programie MS
Visio 2007

Uruchom aplikację MS Visio 2007.

Z panelu Wprowadzenie do programu Microsoft Office Visio wybierz
grupę Diagram modelu bazy danych.

2. Wprowadź
tabele

W obszarze roboczym wyłącz linie siatki wybierając polecenie
Widok -> Siatka.

Z zasobnika Model encja-relacja przeciągnij element Encja na obszar
roboczy (kartka). Na obszarze roboczym zostanie utworzona encja
o nazwie Tabela1.

Zaznacz encję Tabela1. W oknie Właściwości bazy danych wskaż
element Definicja, a następnie w polu Nazwa koncepcyjna wprowadź
tekst Sala.

Nazwa encji na obszarze roboczym powinna zmienid się na Sala.

Powtórz powyższe czynności dla pozostałych encji w modelu.

Rys. 13. Fragment okna programu Visio

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 15/18

3. Wprowadź
atrybuty

Zaznacz encję Sala.

W oknie Właściwości bazy danych zaznacz element Kolumny.

W kolumnie Nazwa fizyczna wprowadź Numer_Sali.

Na dole okna Właściwości bazy danych upewnij się, że zaznaczony jest
wybór Fizyczny typ danych (Microsoft SQL Server). Jeśli wyświetlany
jest inny sterownik wybierz z menu Baza danych -> Opcje -> Sterowniki,
a w oknie Sterowniki bazy danych z karty Sterowniki sterownik
Microsoft SQL Server.

jako typ danych dla kolumny Numer_Sali wybierz varchar(6), wskaż to
pole jako wymagane, a w uwagach wpisz: Numer sali; litera oznacza
symbol budynku
.

Sprawdź w systemie pomocy co oznacza typ danych varchar(6). Czy
zgadzasz się z takim wyborem typu dla pola Nazwa_Sali?
Sprawdź, co stanie się po zmianie wyboru na Pokaż: Przenośny typ

danych?

Wprowadź pozostałe kolumny tabeli Sala. Wskaż, że kolumna ID_Sala
jest kluczem głównym w tej tabeli.
Wprowadź atrybuty pozostałych tabel. Pamiętaj o wskazaniu, które
kolumny stanowią klucz główny oraz które wartości są wymagane.

4. Zmieo widok
dokumentu

Program MS Visio pozwala na przestawienie modelu ERD z różnym
zestawem informacji (np. można ukryd lub pokazad typy danych,
oznaczenia kluczy głównych itd.).

Przejdź do menu Baza danych -> Opcje -> Dokument i w karcie Opcje
dokumentu bazy danych
wypróbuj różne ustawienia wyświetlania
modelu ERD.

Jakie opcje należy wybrad, aby na diagramie były widoczne typy
danych zdefiniowane w oknie Właściwości bazy danych dla
poszczególnych atrybutów?

5. Dodaj związki
między encjami

Z zasobnika Model encja-relacja przeciągnij element Relacja na obszar
roboczy (kartka). Na obszarze roboczym zostanie utworzona relacja.
Przeciągnij kooce relacji odpowiednio na encje Sala i ObciazenieSali, tak
aby uzyskad zakotwiczenie relacji (jeśli następuje zakotwiczenie, to
program wyróżnia encję czerwonym obramowaniem).

Wskaż utworzoną relację. W oknie Właściwości bazy danych wskaż
kategorię Nazwa. W pola Fraza orzeczenia, Fraza odwrotna, Nazwa
fizyczna i Uwagi
wpisz odpowiednie Twoim zdaniem wartości.

Przejdź do kategorii Różne. Sprawdź, jaki wpływ na diagram ma wybór
różnych opcji kardynalności (liczności). Ustaw prawidłowe Twoim
zdaniem kardynalności dla tej relacji.

Zdefiniuj pozostałe związki między encjami.

Co należy zrobid, aby w widoku roboczym nie były wyświetlane
związki?

6. Zmiana notacji
diagramu

Wybierz z menu Baza danych -> Opcje -> Dokument i na karcie Relacja
zmieo zaznaczenie opcji Kurze łapki. Zaobserwuj zmiany notacji na
diagramie ERD.

7. Zapisz model

Zapisz model w odpowiednim pliku na dysku.

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 16/18

Laboratorium rozszerzone

Zadanie 1 (czas realizacji 45 min)

W pewnej uczelni (jeśli nie w każdej) student kooczący pewien etap edukacji musi wykonad
i obronid pracę koocową zwaną pracą dyplomową. Praca dyplomowa realizowana jest na koniec
każdego etapu studiów. Tak więc prace dyplomową piszą studenci studiów licencjackich,
inżynierskich i magisterskich. W przyszłości uczelnia planuje poszerzyd swoją ofertę studiów o nowe
rodzaje studiów, które też będą kooczyd się pracą dyplomową. Każdy student oprócz imienia
i nazwiska ma przypisany na uczelni jednoznaczny identyfikator w postaci numeru indeksu. Numer
indeksu jest ciągiem złożonym z 10 znaków i w sposób jednoznaczny identyfikuje studenta
studiującego na uczelni.

Student chcąc ukooczyd dany rodzaj studiów musi wybrad temat pracy dyplomowej. Z tematem
pracy związany jest oczywiście jej opiekun zwany zazwyczaj promotorem pracy. Zasadą jest, że
jeden temat kierowany jest przez jednego promotora – pracownika uczelni ze stopniem doktora,
doktora habilitowanego lub profesora.

Władze uczelni zachęcają swoich studentów do pisania prac indywidualnych. Ale dopuszczają
również możliwośd realizacji prac przez dwóch lub trzech studentów. Więcej osób nie może pisad
jednej pracy dyplomowej.

Po napisaniu praca podlega recenzji. Recenzja wykonywana jest przez jednego lub kilku
pracowników uczelni i oceniana. Każdy recenzent może ocenid pracę w skali od 2 do 5. Praca
oceniana jest również przez promotora.

Do pracy przyporządkowywane są pewne słowa ze z góry zdefiniowanego zbioru. Są to tak zwane
słowa kluczowe, które pozwalają przypisad tematykę pracy do określonego obszaru, a następnie
odnajdywad prace związane z podobną tematyką. Słowami kluczowymi mogą byd: informatyka,
systemy operacyjne, konstrukcje żelbetowe itp. Każda praca powinna mied przypisane co najmniej
jedno słowo kluczowe.

Po napisaniu pracy student przystępuje do obrony pracy. Obrona ta odbywa się w wyznaczonym
dniu i kooczy się wystawieniem pracy dyplomowej koocowej, ostatecznej oceny.

Uczelnia chciałaby usprawnid obsługę prac dyplomowych i związanych z tym procesów. Dlatego
planuje opracowad system informatyczny wspierający obsługę tych procesów. Pierwszym etapem
prac ma byd zbudowanie bazy danych, która będzie spełniad następujące wymagania:

1. Umożliwi przechowywanie informacji o obronionych pracach dyplomowych wszystkich

studentów uczelni.

2. Umożliwi szybkie i łatwe wyszukiwanie prac związanych z daną tematyką lub prowadzonych

przez określonego promotora.

3. Umożliwi raportowanie o pracach dyplomowych:

recenzowanych przez pracowników uczelni,

obronionych w danym dniu, miesiącu, roku,

obronionych na danym rodzaju studiów.

Zaproponuj diagram ERD dla projektowanej bazy danych. Pamiętaj również o udokumentowaniu
przykładowych instancji encji oraz wartości atrybutów, tak jak robiliśmy to w przykładowym
rozwiązaniu w krokach piątym i siódmym. Model zapisz w pliku programu MS Visio.

Zadanie 2 (czas realizacji 45 min)

Wymagania z zadania 1 okazały się niewystarczające. Nasz ekspert dokonał przeglądu wymagao
i dodał uzupełnienia. W poniższym tekście zostały one uwydatnione.

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 17/18

Zaproponuj diagram ERD dla projektowanej bazy danych po uwzględnieniu rozszerzeo. Pamiętaj
również o udokumentowaniu przykładowych instancji encji oraz wartości atrybutów, tak jak
robiliśmy to w przykładowym rozwiązaniu w krokach piątym i siódmym. Model zapisz w pliku
programu MS Visio.

W pewnej uczelni (jeśli nie w każdej) student kooczący pewien etap edukacji musi wykonad
i obronid pracę koocową zwaną pracą dyplomową. Uczelnia składa się kilku wydziałów. Na każdym
wydziale studenci mogą byd kształceni na różnych specjalizacjach, a informacja o wydziale
i specjalizacji jest istotna przy wykonywaniu sprawozdao uczelni z obronionych prac dyplomowych.

Praca dyplomowa realizowana jest na koniec każdego etapu studiów. Tak więc prace dyplomową
piszą studenci studiów licencjackich, inżynierskich i magisterskich. W przyszłości uczelnia planuje
poszerzyd swoją ofertę studiów o nowe rodzaje studiów, które też będą kooczyd się pracą
dyplomową. Każdy student oprócz imienia i nazwiska ma przypisany na uczelni jednoznaczny
identyfikator w postaci numeru indeksu. Numer indeksu jest ciągiem złożonym z 10 znaków i
w sposób jednoznaczny identyfikuje studenta studiującego na uczelni.

Student chcąc ukooczyd dany rodzaj studiów musi wybrad temat pracy dyplomowej. Z tematem
pracy związany jest oczywiście jej opiekun zwany zazwyczaj promotorem pracy. Zasadą jest, że
jeden temat kierowany jest przez jednego promotora – pracownika uczelni ze stopniem doktora,
doktora habilitowanego lub profesora.

Władze uczelni zachęcają swoich studentów do pisania prac indywidualnych. Ale dopuszczają
również możliwośd realizacji prac przez dwóch lub trzech studentów. Więcej osób nie może pisad
jednej pracy dyplomowej.

Po napisaniu praca podlega recenzji. Recenzja wykonywana jest przez jednego lub kilku
pracowników uczelni i oceniana. Każdy recenzent może ocenid pracę w skali od 2 do 5. Praca
oceniana jest również przez promotora. Ocena recenzenta i promotora nie może byd zbiorczą oceną
pracy, ale musi osobno dotyczyd każdego z autorów pracy.

Do pracy przyporządkowywane są pewne słowa ze z góry zdefiniowanego zbioru. Są to tak zwane
słowa kluczowe, które pozwalają przypisad tematykę pracy do określonego obszaru, a następnie
odnajdywad prace związane z podobną tematyką. Słowami kluczowymi mogą byd na przykład:
informatyka, systemy operacyjne, konstrukcje żelbetowe. Każda praca powinna mied przypisane co
najmniej jedno słowo kluczowe.

Po napisaniu pracy student przystępuje do obrony pracy. Obrona ta odbywa się w wyznaczonym
dniu przed komisją składającą się z 3 członków oraz przewodniczącego i kooczy się wystawieniem
ostatecznej oceny każdemu studentowi osobno. W czasie egzaminu każdemu studentowi są
zadawane i protokołowane trzy pytania. Każde z pytao podlega osobnej ocenie.

Uczelnia chciałaby usprawnid obsługę prac dyplomowych i związanych z tym procesów. Dlatego
planuje opracowad system informatyczny wspierający obsługę tych procesów. Pierwszym etapem
prac ma byd zbudowanie bazy danych, która będzie spełniad następujące wymagania:

1. Umożliwi przechowywanie informacji o obronionych pracach dyplomowych wszystkich

studentów uczelni.

2. Umożliwi szybkie i łatwe wyszukiwanie prac związanych z daną tematyką, wydziałem,

specjalizacją lub prowadzonych przez określonego promotora.

3. Umożliwi raportowanie o pracach dyplomowych:

recenzowanych przez pracowników uczelni

obronionych w danym dniu, miesiącu, roku

obronionych na danym rodzaju studiów

background image

W.Dąbrowski, P.Kowalczuk, K.Markowski

Moduł 1

ITA-101 bazy danych

Budowa diagramów ERD

Strona 18/18

4. Umożliwid szybkie sprawdzenie przebiegu obrony pracy dyplomowej danego studenta, w tym
zadanych pytao i składu komisji.


Wyszukiwarka

Podobne podstrony:
ITA 101 Modul 03
ITA 101 Modul 02
ITA 101 Modul 06
ITA 101 Modul 13
ITA 101 Modul 11
ITA 101 Modul 04
ITA 101 Modul 09
ITA 101 Modul Dodatek A
ITA 101 Modul 08
ITA 101 Modul 07
ITA 101 Modul 10
ITA 101 Modul 12
ITA 101 Modul 05
ITA 101 Modul 02 v2

więcej podobnych podstron