Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski. Bazy danych ITA-101. Wersja 1

Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski Bazy danych ITA-101 Wersja 1 Warszawa, wrzesień 2009

Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski ITA-101 Bazy danych 2008 Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski. Autorzy udzielają prawa do bezpłatnego kopiowania i dystrybuowania wśród pracowników uczelni oraz studentów objętych programem ITAcademy. Wszelkie informacje dotyczące programu można uzyskać: pledu@microsoft.com. Wszystkie inne nazwy firm i producentów wymienione w niniejszym dokumencie mogą być znakami towarowymi zarejestrowanymi przez ich właścicieli. Inne produkty i nazwy firm używane w treści mogą być nazwami zastrzeżonymi przez ich właścicieli. Strona i-2

Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski ITA-101 Bazy danych Wprowadzenie Informacje o kursie Opis kursu We współczesnej informatyce coraz większą rolę odgrywa przepływ informacji. Dane są gromadzone i przekazywane w ilościach dotąd niespotykanych. Od umiejętnego sterowania przepływem danych zależy los wielu wielkich firm. Odpowiednia automatyzacja procesu przepływu informacji daje ogromne wymierne korzyści. Bazy danych i systemy zarządzania bazami danych służą właśnie temu, by móc przechowywać nawet ogromne ilości danych bez narażenia na ich utratę oraz by móc odpowiednio szybko i wygodnie sterować ich przepływem. Bazy danych wdarły się zarówno do sieci lokalnych w firmach, gdzie gromadzone są dane na potrzeby pracowników, jak również do Internetu, gdzie dostęp do nich mają miliardy użytkowników na całym świecie. Dynamiczny rozwój baz danych implikował powstanie wielu nowych technologii programowania ukierunkowanych na jeszcze wydajniejsze wykorzystanie baz danych w aplikacjach. Z kolei administracja systemami zarządzania bazami danych stała się osobną gałęzią informatyki, tak jak administracja systemami operacyjnymi komputerów lub administracja sieciami komputerowymi. Wielu pracodawców poszukuje wykwalifikowanych specjalistów z zakresu określonych systemów zarządzania bazami danych (jak Oracle czy MS SQL Server). Znajomość zarówno teorii baz danych, jak i konkretnego środowiska pracy z nimi, jest więc okazją podniesienia swoich kwalifikacji. Wykorzystując możliwości systemu zarządzania bazami danych Microsoft SQL Server 2008 postaramy się w niniejszym podręczniku zilustrować podstawowe własności baz danych (w szczególności relacyjnych baz danych) oraz systemów zarządzania tymi bazami. Mamy nadzieję, że podręcznik pozwoli Państwu na bliższe zapoznanie się z tematyką baz danych oraz systemem Microsoft SQL Server 2008. Życzymy owocnej pracy z naszym podręcznikiem. Uzyskane kompetencje Po zrealizowaniu kursu będziesz: Zrozumieć schemat, zaprojektować i zoptymalizować prostą bazę danych, Administrować serwerem bazodanowym MS SQL Sever 2008 na poziomie podstawowym, Zaimplementować prostą bazę danych w systemie SZBD opartym o MS SQL Sever 2008, Tworzyć skrypty w języku T-SQL, Monitorować i dokonywać tuningu baz danych, Dbać o bezpieczeństwo systemów SZBD w podstawowym zakresie, Używać języka XML w procesie komunikacji z SZBD, Tworzyć raporty przy użyciu MS SQL Reporting Services Strona i-3

Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski ITA-101 Bazy danych Zakres tematyczny kursu Wymagania wstępne Aby przystąpić do pracy z podręcznikiem musisz: umieć obsługiwać komputer z zainstalowanym systemem operacyjnym Microsoft Windows 9X/NT/2000/ME/XP/2003, znać podstawowe zagadnienia dotyczące programowania (m.in. wiedzieć, co to jest zmienna, procedura, pętla), nie musisz znać teorii baz danych - poznasz ją czytając wykłady zawarte w niniejszym podręczniku. Opis modułów W Tab. 1 przedstawiony został opis modułów, zawierający podział na zajęcia. Każde zajęcie jest zaplanowane na 90 minut. Wykładowca może dostosować harmonogram do swoich potrzeb. Tab. 1 Zakres tematyczny modułów Numer moduł Tytuł Moduł 1 Budowa diagramów ERD Moduł 2 Instalacja i konfiguracja MS SQL Server 2008 Moduł 3 Definiowanie i zarządzanie bazą danych Moduł 4 Wewnętrzna struktura bazy danych Moduł 5 Język SQL - DCL, DDL Opis 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. W tym module znajdziesz informację o podstawowych zadaniach administratora systemu bazodanowego. Do zadań tych należy instalacja serwera baz danych, konserwacja oraz aktualizacji serwisów serwera. Prawidłowe przygotowanie środowiska pracy zapewni stabilność oraz pozwoli na poznanie systemu bazodanowego od podstaw. Dobry administrator Systemu Zarządzania Bazami Danych wie wszystko o bazach danych. W dzisiejszych czasach rola administratora nie ogranicza się do zarządzania istniejącymi bazami danych, ale również wymaga umiejętności zakładania, konserwacji oraz aktualizacji baz danych znajdujących się pod jego opieką. Moduł przybliży wszystkie te zagadnienia W tym module znajdziesz informacje w jaki sposób w SQL Server 2008 przechowywane są dane oraz w jaki sposób przechowywane są podstawowe obiekty w bazie danych. Język SQL został opracowany w 1987 roku z myślą o relacyjnych bazach danych. Składa się on z trzech składowych: języka definiowania danych (DDL), języka sterowania danymi (DCL) oraz języka operowania na danych (DML). W module tym zostaną wprowadzone, a następnie przedstawione na przykładach podstawowe instrukcje języka definiowania danych języka SQL DDL oraz języka sterowania danymi języka SQL DCL. Strona i-4

Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski ITA-101 Bazy danych Moduł 6 Język SQL - DML Moduł 7 Indeksy i transakcje Moduł 8 Programowanie zaawansowane w T-SQL Moduł 9 Procedury składowane i wyzwalacze Moduł 10 Bezpieczeństwo w bazach danych Moduł 11 Praca z XML Moduł 12 Praca z Reporting Services Język SQL składa się z trzech składowych: języka definiowania danych (DDL), języka sterowania danymi (DCL) oraz języka operowania na danych (DML). W module tym zostaną wprowadzone, a następnie przedstawione na przykładach podstawowe instrukcje języka sterowania na danych języka SQL DML W module tym znajdziesz informacje na temat dostępu fizycznego do danych oraz optymalizacji dostępu. Poznasz indeksy i ich rodzaje a następnie dowiesz się jakie operacje wykonywane są na indeksach. Dowiesz się, że jest to parametr niezbędny do zapewnienia rozsądnych czasów wyszukiwania informacji. W drugiej części poznasz transakcje, które służą do zapewnienia spójności bazy danych i mają wpływ na wydajność bazy danych. Dowiesz się, że obsługa transakcji nie jest rzeczą łatwą i wymaga rozwiązywania wielu trudnych problemów. Programowanie w języku zapytań to ważna umiejętność. Powinni ją opanować zarówno programiści, jak i administratorzy. Różne dialekty języka SQL oferują różne składnie, jednak reguły, jakimi powinien kierować się tworzący kod, są te same niezależnie od SZBD. Bardzo często opanowanie w zaawansowanym stopniu składni jednego języka pozwala w przyszłości na łatwe opanowanie innego. W module tym znajdziesz informację na temat zaawansowanego programowania w T-SQL. W module zostanie zaprezentowany sposób działania oraz podstawy tworzenia procedur składowanych. Dowiesz na czym polega różnica pomiędzy zwykłym zapytaniem T-SQL a procedurą składowaną oraz co to jest kompilacja i rekompilacja procedury. Zostanie wprowadzony również specjalny rodzaj procedury składowanej wyzwalacz. W tym module dowiesz się, jak należy rozumieć bezpieczeństwo baz danych oraz jakie są poziomy bezpieczeństwa. Ponadto dowiesz się, jakim zagrożeniom należy przeciwdziałać, a jakich nie da się uniknąć oraz jak należy planować implementację poszczególnych poziomów bezpieczeństwa w aplikacji bazodanowej. Wymiana danych z relacyjnymi bazami danych może być utrudniona ze względu na różnice programowo sprzętowe itp. Rozwiązaniem jest język XML, który jest niezależny od standardów sprzętowych / programowych. Aby osiągnąć sukces na dzisiejszym, konkurencyjnym rynku, przedsiębiorstwa gromadzące duże ilości danych powinny wprowadzić rozwiązania biznesowe działające w czasie rzeczywistym zapewniające bezproblemową, skuteczną wymianę informacji pomiędzy własnymi oddziałami, swoimi partnerami, a także klientami. Microsoft SQL Server Reporting Services jest rozwiązaniem, które pozwala szybko i komfortowo dzielić i udostępniać dane biznesowe, przy niższych nakładach rozmaitych zasobów. Strona i-5

Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski ITA-101 Bazy danych Moduł 13 Budowa interfejsu Dodatek Podstawy W module tym napiszemy aplikację, która będzie wyciągała informacje z bazy danych Prace Dyplomowe. Zostanie pokazane jak za pomocą Visual Studio utworzyć bazę danych, jak połączyć się z bazą danych w jaki sposób wprowadzać dane. Następnie stworzymy aplikacje Windows, która będzie korzystała z tych danych. W tym module zajmiemy się zebraniem najważniejszych informacji na temat baz danych niezbędnych do zrozumienia i pełnego wykorzystania dalszych modułów. Zebrane, najważniejsze pojęcia nie zastępują pełnego wykładu na ten temat i nie zwalniają Cię z przestudiowania wykładu lub podręcznika z zakresu baz danych. Mają one jedynie na celu zebrać i utrwalić najważniejsze elementy potrzebne do wykonywania kolejnych modułów. Zazwyczaj pierwsze zajęcia laboratorium są zajęciami organizacyjnymi. Strona i-6

ITA-101 Bazy danych Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski Moduł 1 Wersja 1.0 Spis treści Budowa diagramów ERD 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

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Informacje o module Budowa diagramów ERD 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. Strona 2/18

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Budowa diagramów ERD 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. Strona 3/18

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Budowa diagramów ERD 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. 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 Rys. 1. Przykład klucza obcego (FK1) 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 Strona 4/18

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Budowa diagramów ERD 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. Strona 5/18

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Budowa diagramów ERD 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 wielowieloznacznych binarnych. Wprowadzamy wówczas dodatkową encję oraz 3 nowe związki jednoznaczne. Strona 6/18

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Budowa diagramów ERD 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. Strona 7/18

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Budowa diagramów ERD 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. Strona 8/18

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Budowa diagramów ERD 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 (*..*) Strona 9/18

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Budowa diagramów ERD Krok 3 Przedstawiamy diagram ERD z uwzględnieniem związków i ich liczności. Krok 4 Rys. 8. Diagram ERD z uwzględnieniem związków i ich liczności 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. Krok 5 Rys. 9. Diagram ERD po uwzględnień poprawy liczności związku 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 Na diagramie ERD: Liczność 35 Rys. 10. Diagram ERD z zaznaczonymi atrybutami Strona 10/18

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Budowa diagramów ERD 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 Liczba miejsc Zajecia Nazwa zajęć Grupa Nazwa grupy C101 Ciąg składający się z litery reprezentującej budynek oraz co najwyżej czterech cyfr 120 Przedział od 15 do 250 Bazy danych wykład Lista zajęć 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 Strona 11/18

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Budowa diagramów 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 Liczba miejsc varchar(6) uniqueidentifier Grupa PK ID_Grupa uniqueidentifier Zajecia PK ID_Zajecia uniqueidentifier Nazwa grupy Liczność char(10) smallint Nazwa zajęć varchar(255) Krok 10 ObciazenieSali PK,FK1 ID_Sala int PK,FK2 ID_Zajecia int Dzien GodzinaOd GodzianDo char(10) char(10) char(10) Rys. 12. Diagram ERD z typami danych ZajeciaGrupy PK,FK1 ID_Zajecia int PK,FK2 ID_Grupa int 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 Strona 12/18

W.Dąbrowski, P.Kowalczuk, K.Markowski Moduł 1 ITA-101 bazy danych Budowa diagramów ERD 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. Strona 13/18

W.Dąbrowski, P.Kowalczuk, K.Markowski ITA-101 bazy danych Laboratorium podstawowe Moduł 1 Budowa diagramów ERD 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 1. Uruchom projekt bazy danych w programie MS Visio 2007 2. Wprowadź tabele Tok postępowania Uruchom aplikację MS Visio 2007. Z panelu Wprowadzenie do programu Microsoft Office Visio wybierz grupę Diagram modelu bazy danych. 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 Strona 14/18