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
Informacje o module
Opis modułu
W tym module zajmiemy się pierwszym krokiem, jaki należy wykonać 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ł zbudować poprawny diagram ERD,
• umiał dokonać 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ś:
• rozumieć, czym jest baza danych i jakie powinna mieć cechy,
• znać 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.
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ęć na swoim wydziale na uczelni. Pani Jola zajmująca się przydzielaniem sal na zajęcia chciałaby uzyskać narzędzie do kontroli i monitorowania obciążenia sal przez różne zajęcia dydaktyczne oraz chciałaby przy tej okazji zminimalizować 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ż mieć możliwość szybkiego generowania raportów o przydziale sal i zajęć. Dla uniknięcia nieporozumień 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 zostać zweryfikowany i zaakceptowany przez panią Jolę przed przystąpieniem do dalszych prac.
Podstawy teoretyczne
Przy modelowaniu baz danych możemy posłużyć 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), choć jego odmiany mogą zawierać 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 mieć informacje.
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 encja jest reprezentowana przez prostokąt, a jej nazwa powinna być rzeczownikiem.
Atrybut
Atrybut (ang. attribute) jest pewną własnością encji, o której chcemy przechowywać informacje.
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 jeden 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łówny oznacza się często na wykresach symbolem PK (ang. Primary Key) umieszczanym obok nazwy atrybutu.
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ść 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.
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. 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. 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ązań 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ą 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. 5. 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 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łceń.
Przykłady takich przekształceń zaprezentowane są poniżej 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. 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.
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ę implementować 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ąć modelowanie danych od diagramów ERD.
Diagramy takie powinny przede wszystkim, w pierwszym etapie projektowania, odzwierciedlać 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ęć na wydziale uczelni.
Naszym celem jest przygotowanie modelu danych, który będzie spełniał dwa podstawowe cele:
• pozwalał zweryfikować wymagania stawiane przez panią Jolę oraz
• stanowił podstawę do zbudowania relacyjnej bazy danych.
Jak widać musimy posłużyć 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 wybrać? Dosyć 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łań 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.
Przypominamy, że diagram związków encji powstaje w sposób iteracyjny. Wynikiem naszych prac powinien być 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 przedstawić w punktach nasze działania. Co więc i w jakiej kolejności powinniśmy wykonać?
Krok 1
Powinniśmy uważnie wysłuchać, co ma do powiedzenia ekspert dziedzinowy, czyli pani Jola. Na podstawie zebranych informacji możemy zidentyfikować i wypisać 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 zidentyfikować związki występujące między encjami. Dobrze jest nazwać te związki i określić role, jakie w nich odgrywają poszczególne encje. Koniecznie powinniśmy też zidentyfikować liczności związków.
Krok 3
Powinniśmy wykonać 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ścić 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 dokonywać przekształceń tego diagramu.
Krok 4
Diagram z kroku 3 powinniśmy skonsultować 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łnień już na tym wstępnym etapie.
Krok 5
Rozpoczynamy identyfikowanie atrybutów dla każdej z przedstawionych na diagramie encji.
Powinniśmy zidentyfikować 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źć swoje odzwierciedlenie w końcowym 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 zidentyfikować atrybut biznesowy srednia_z_czterech_semestrow. W trakcie kolejnych iteracji budowy diagramu ERD możemy zdecydować, że nie będziemy przechowywać w bazie tej średniej, ale wyliczać ją, gdy będzie potrzebna, na podstawie ocen cząstkowych.
Krok 6
Diagram z kroku 5 powinniśmy skonsultować z ekspertem dziedzinowym.
Krok 7
Dla każdego atrybutu powinniśmy zidentyfikować i zapisać 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 przyjmować 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 być 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 skonsultować z ekspertem dziedzinowym.
Krok 9
Po zaakceptowaniu diagramu związków encji przez eksperta dziedzinowego możemy przystąpić do normalizacji, określenia kluczy głównych i kluczy obcych, dokonać zmian atrybutów (na przykład dodać 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ślić typy wszystkich atrybutów uwzględniając typy silnika bazy danych, na której będzie realizowana baza danych, zdefiniować niezdefiniowane jeszcze klucze główne i klucze obce oraz wskazać pola indeksowane.
Na zakończenie powinniśmy dokonać przeglądu diagramu ERD pod kątem jego spójności i kompletności. W naszym wypadku zadanie jest dosyć 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 (*..*)
Krok 3
Przedstawiamy diagram ERD z uwzględnieniem związków i ich liczności.
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ą być zajęcia, które w danym semestrze nie odbywają się, ale znajdują się w katalogu zajęć (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ęć. Oczywiście na taki luksus żaden wydział nie może sobie pozwolić. Zamieniamy liczność związku Zajęcia_w_Sali na wiele do wielu.
Uwagę tę powinniśmy uwzględnić na naszym diagramie ERD. Wprowadzamy stosowną poprawkę na diagramie.
Rys. 9. Diagram ERD po uwzględnień poprawy liczności związku
Krok 5
Przystępujemy do identyfikacji atrybutów. Wygodnie jest informacje o atrybutach zebrać 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:
Rys. 10. Diagram ERD z zaznaczonymi atrybutami
Krok 6
Pokazujemy nasz diagram ERD pani Joli. Jeśli zostanie on zaakceptowany, przechodzimy do kroku siódmego.
Krok 7
Powinniśmy teraz określić dla każdego atrybutu jego dziedzinę. Najwygodniej będzie nam to wykonać 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ęć
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 skonsultować wyniki naszej pracy z panią Jolą. Jeśli uzyskamy akceptację, możemy przejść 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 zakończyliśmy konsultację z panią Jolą i możemy przystąpić do prac zmierzających do nadania naszemu modelowi postaci dającej się zaimplementować 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 dokonać ich przekształcenia. Wprowadzamy nowe encje ObciazenieSali i ZajeciaGrupy tak jak na rysunku.
Rys. 11. Diagram ERD
Informację na diagramie możemy uzupełnić 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 niedopatrzeń, dlatego zawsze należy przeprowadzić weryfikację poprawności diagramu.
Porady praktyczne
• Pamiętaj, że diagram związków encji ma być zrozumiały nie tylko dla informatyka. Ma on służyć dialogowi między projektantem a użytkownikiem, który formułuje wymagania dla przyszłej bazy danych. Modelując dane należy posługiwać 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łceń 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ść i zrozumiałość 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 wypisać 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 być 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ąć od rysowania na dużej kartce papieru lub tablicy. Dopiero pod koniec (krok 9) warto jest przenieść diagramy związków encji do narzędzia wspomagającego pracę z diagramami ERD. Narzędzi takich jest wiele. My proponujemy wykorzystać 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
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 upodobań projektanta. Modele ERD bazy danych zbudowane dla tego samego problemu mogą się różnić. Nie zawsze potrafimy jednoznacznie wskazać, który z modeli jest lepszy. Często są one po prostu jednakowo dobre.
• Zwróć uwagę, że notacja proponowana przez nas w tym module nie jest jedyną notacją stosowaną przy modelowaniu danych. Popularność 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. Choć 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 wykorzystać 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 końcowego diagramu związków encji,
• umiesz dokonać przekształcenia związków nieimplementowanych w relacyjnych bazach danych do związków binarnych jednoznacznych,
• potrafisz przedstawić 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 zagadnień 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 poszerzyć 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 korzystać z tego oprogramowania.
Laboratorium podstawowe
Problem (czas realizacji 40 min)
Jesteś projektantem bazy danych. W wyniku spotkań 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ść 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ócić 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 zmienić się na Sala.
• Powtórz powyższe czynności dla pozostałych encji w modelu.
Rys. 13. Fragment okna programu Visio
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. Zmień widok dokumentu
Program MS Visio pozwala na przestawienie modelu ERD z różnym zestawem informacji (np. można ukryć lub pokazać 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 wybrać, 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 końce relacji odpowiednio na encje Sala i ObciazenieSali, tak aby uzyskać 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 zrobić, 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 zmień zaznaczenie opcji Kurze łapki. Zaobserwuj zmiany notacji na diagramie ERD.
7. Zapisz model • Zapisz model w odpowiednim pliku na dysku.
Laboratorium rozszerzone
Zadanie 1 (czas realizacji 45 min)
W pewnej uczelni (jeśli nie w każdej) student kończący pewien etap edukacji musi wykonać i obronić pracę końcową 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 poszerzyć swoją ofertę studiów o nowe rodzaje studiów, które też będą kończyć 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 ukończyć dany rodzaj studiów musi wybrać 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ść realizacji prac przez dwóch lub trzech studentów. Więcej osób nie może pisać 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 ocenić 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ą przypisać tematykę pracy do określonego obszaru, a następnie odnajdywać prace związane z podobną tematyką. Słowami kluczowymi mogą być: informatyka, systemy operacyjne, konstrukcje żelbetowe itp. Każda praca powinna mieć przypisane co najmniej jedno słowo kluczowe.
Po napisaniu pracy student przystępuje do obrony pracy. Obrona ta odbywa się w wyznaczonym dniu i kończy się wystawieniem pracy dyplomowej końcowej, ostatecznej oceny.
Uczelnia chciałaby usprawnić obsługę prac dyplomowych i związanych z tym procesów. Dlatego planuje opracować system informatyczny wspierający obsługę tych procesów. Pierwszym etapem prac ma być zbudowanie bazy danych, która będzie spełniać 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 wymagań i dodał uzupełnienia. W poniższym tekście zostały one uwydatnione.
Zaproponuj diagram ERD dla projektowanej bazy danych po uwzględnieniu rozszerzeń. 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 kończący pewien etap edukacji musi wykonać i obronić pracę końcową zwaną pracą dyplomową. Uczelnia składa się kilku wydziałów. Na każdym wydziale studenci mogą być kształceni na różnych specjalizacjach, a informacja o wydziale i specjalizacji jest istotna przy wykonywaniu sprawozdań 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 poszerzyć swoją ofertę studiów o nowe rodzaje studiów, które też będą kończyć 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 ukończyć dany rodzaj studiów musi wybrać 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ść realizacji prac przez dwóch lub trzech studentów. Więcej osób nie może pisać 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 ocenić pracę w skali od 2 do 5. Praca oceniana jest również przez promotora. Ocena recenzenta i promotora nie może być zbiorczą oceną pracy, ale musi osobno dotyczyć 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ą przypisać tematykę pracy do określonego obszaru, a następnie odnajdywać prace związane z podobną tematyką. Słowami kluczowymi mogą być na przykład:
informatyka, systemy operacyjne, konstrukcje żelbetowe. Każda praca powinna mieć 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 kończy się wystawieniem ostatecznej oceny każdemu studentowi osobno. W czasie egzaminu każdemu studentowi są zadawane i protokołowane trzy pytania. Każde z pytań podlega osobnej ocenie.
Uczelnia chciałaby usprawnić obsługę prac dyplomowych i związanych z tym procesów. Dlatego planuje opracować system informatyczny wspierający obsługę tych procesów. Pierwszym etapem prac ma być zbudowanie bazy danych, która będzie spełniać 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
4. Umożliwić szybkie sprawdzenie przebiegu obrony pracy dyplomowej danego studenta, w tym zadanych pytań i składu komisji.
