Literatura R.Colette, Bazy danych : od koncepcji do realizacji, PWE 1988, S.Forte, T.Howe, J. Ralston, Access2000, HELION 2001, R.J.Muller, Bazy danych, język UML w modelowaniu danych, MIKOM 2000, M.Muraszkiewicz, H.Rybiński, Bazy danych, Akademicka Oficyna Wydawnicza RM 1993, J.D.Ullman, J.Widom, Podstawowy wykład z systemów baz danych, WNT 2001. I. Pająk, G. Pająk, K. Łasiński Wprowadzenie do projektowania baz danych, Wyd. Politech. Zielonogórskiej 1998 Systemy informatyczne inżynierii zarządzania (ćwiczenie nr 9, 10), praca zbiorowa pod. red. Z. Banaszaka, Wyd. Politech. Zielonogórskiej 2001 K. Henderson Bazy danych w architekturze klient-serwer, Robomatic 1998 Bazy danych s.1-1
Modelowanie danych pojęcia podstawowe etapy tworzenia projektu informatycznego model relacyjny normalizacja danych Bazy danych s.1-2
Pojęcia podstawowe Baza danych uporządkowany zbiór danych, dostępnych dla licznych użytkowników, w którym można przeprowadzić efektywne wyszukiwanie i aktualizowanie informacji. Poziomy organizacji danych: poziom logiczny opisuje sposób w jaki bazę widzi użytkownik; powinien być skonstruowany tak, aby zapewnić maksymalnie naturalny sposób dostępu do informacji zawartej w bazie, poziom fizyczny związany z samym komputerem i niewidoczny dla użytkownika; powinien zapewniać organizację danych w sposób umożliwiający najszybszy dostęp do informacji, co oznacza konieczność strukturalizacji danych zoptymalizowaną pod kątem sposobu pracy komputera. Model danych dobrze zdefiniowany sposób opisu świata rzeczywistego. Modelowanie danych proces przechodzenia od rzeczywistych obiektów do ich reprezentacji w bazie danych System zarządzania bazą danych (SZBD) program zawierający narzędzia umożliwiające budowę i przetwarzanie bazy danych o dowolnej strukturze. System bazy danych baza danych wraz z jej systemem zarządzania Bazy danych s.1-3
Etapy budowy aplikacji bazodanowej Analiza * Definiowanie przeznaczenia i funkcjonalności aplikacji. Projekt * Projekt bazy danych i procesów aplikacji, niezbędnych do zaimplementowania żądanych funkcji. Budowa (implementacja) Przekształcenie projektu w aplikację poprzez utworzenie odpowiednich składników bazy danych i programu Testowanie * Sprawdzenie aplikacji pod kątem zgodności z założeniami, przeznaczeniem i zakresem funkcji Instalacja (wdrożenie) Uruchomienie aplikacji w środowisku użytkownika, szkolenia z zakresu obsługi. Etapy projektu na podstawie: K.Henderson, Bazy danych w architekturze klient-serwer, Robomatic 1998 Bazy danych s.1-4
Analiza Etap analizy wymaga kontaktu z użytkownikiem końcowym i rozpoznania jego wymagań. Należy unikać zagadnień związanych z wyglądem lub działaniem aplikacji i skupić się na oczekiwaniach użytkownika związanych z funkcjonalnością. Krok 1: Definiowanie przeznaczenia Przeznaczenie aplikacji powinno być wyrażone jednym, prostym zdaniem zawierającym: podmiot (opisuje aplikację), orzeczenie (podstawowe zadanie aplikacji) oraz dopełnienie (opisuje obiekt, którego dotyczy zadanie). Sformułowane przeznaczenie nie zawiera listy funkcji, powinno jednak obejmować wszystkie aspekty przyszłego zastosowania programu. Krok 2: Definiowanie funkcji Listę należy ograniczyć do najważniejszych funkcji aplikacji. Każda powinna bliżej definiować przeznaczenie i nie może wykraczać poza główny cel (kroku 1). Konstrukcja zdań przypomina zdanie wyrażające przeznaczenie całej aplikacji. Krok 3: Schemat opisowy Syntetyczny opis prezentujący funkcjonowanie instytucji dla której aplikacja jest projektowana. Stanowi uzupełnienie listy funkcji, powinien zawierać opis danych, które będą przetwarzane, będzie podstawą do stworzenia modelu danych. Bazy danych s.1-5
Analiza przykład Należy zaprojektować aplikację, która umożliwi przechowywanie i analizę danych związanych ze zwolnieniami chorobowymi pracowników z uwzględnieniem informacji o jednostce organizacyjnej, w której są zatrudnieni. Przeznaczenie: Aplikacja przetwarza dane o zwolnieniach chorob. pracowników. Funkcje: Przechowuje dane osobowe pracowników. Przechowuje dane o zwolnieniach chorobowych. Generuje informacje o historii zwolnień każdego pracownika. Wyznacza liczbę dni chorobowych na każdym wydziale. Schemat opisowy: Podstawową jednostką organizacyjną firmy jest wydział. Każdy wydział ma przypisaną nazwę i unikalny kod. Pracownik w danym okresie zatrudnienia jest przypisany do jednego wydziału. W istniejących już systemach informatycznych każda osoba jest identyfikowana przez numer PESEL, ma przypisane imię i nazwisko. Zwolnienia chorobowe są odnotowywane przez określenie daty początku i końca zwolnienia. Bazy danych s.1-6
Modele danych Elementy świata rzeczywistego obiekt składnik rzeczywistego systemu postrzegany jako istotny przez jednostkę lub grupę, przyszłych użytkowników bazy danych, powiązanie opis stanu, w którym znalazły się co najmniej dwa obiekty. Obiekty i powiązania są opisywane szczegółowo za pomocą atrybutów. Najważniejsze modele danych sieciowy oparty na strukturze grafu. Obiekty są reprezentowane przez wierzchołki grafu, powiązania przez jego krawędzie, hierarchiczny modyfikacja modelu sieciowego, oparty na strukturze drzewa (graf, który nie zawiera cykli), relacyjny wykorzystuje matematyczne pojęcie relacji, przy jej pomocy reprezentuje zarówno obiekty jak i powiązania, obiektowy wprowadza rozszerzone pojęcie obiektu, który jest opisany nie tylko atrybutami, ale zawiera również metody odpowiadające zachowaniom i umiejętnością obiektów występujących w modelowanej rzeczywistości. Bazy danych s.1-7
Model relacyjny definicje (1) Relacją R na zbiorach D 1, D 2,, D n nazywamy dowolny podzbiór iloczynu kartezjańskiego tych zbiorów i zapisujemy: R(D 1, D 2,,D n ), R D 1 D 2 D n. Zapis postaci R(D 1, D 2,,D n ) nazywany jest schematem relacji R, a elementy D 1, D 2,, D n atrybutami lub składnikami relacji. Krotka relacji ciąg wartości atrybutów danego schematu relacji. Przykłady Schemat relacji Pracownik: Pracownik(PESEL, Nazwisko, Imię, DataP, DataK, IDW, NazwaW) Krotka relacji Pracownik: <70052000234, Kot, Jan, 2011-05-16, 2011-05-20, W7, WydzMech> Alternatywna definicja relacji: Relacją R na zbiorach D 1, D 2,, D n nazywamy dowolny zbiór krotek postaci: takich, że: d 1 D 1, d 2 D 2,, d n D n. <d 1, d 2,, d n > Bazy danych s.1-8
Model relacyjny definicje (2) Identyfikator relacji składnik lub ciąg składników, których wartości określają w sposób jednoznaczny krotkę relacji. Identyfikator kluczowy (klucz) relacji jeden, dowolnie wybrany identyfikator relacji (zazwyczaj kryterium wyboru jest długość). Klucz w schemacie relacji jest zaznaczany przez podkreślenie odpowiednich składników. Schemat relacji Pracownik może być zapisany jako: Pracownik(PESEL, Nazwisko, Imię, DataP, DataK, IDW, NazwaW) Uwaga: Poprawność zaproponowanego klucza zostanie zweryfikowana (s.15) Klucz naturalny klucz złożony z atrybutów relacji, których obecność wynika z przeprowadzonej analizy problemu. Klucz sztuczny sztucznie wprowadzony atrybut relacji, którego wartości gwarantują jednoznaczną identyfikację krotek. W roli klucza sztucznego najczęściej występuje liczba porządkowa. Tabela struktura danych zaimplementowana w bazie danych na podstawie schematu relacji. Bazy danych s.1-9
Analiza przykładowej relacji (1) Schemat relacji Pracownik(PESEL, Nazwisko, Imię, DataP, DataK, IDW, NazwaW) Przykładowy zbiór krotek PESEL Nazwisko Imię DataP DataK IDW NazwaW 70052000234 Nowak Andrzej W3 Transport 82012090803 Kowalski Jan W7 Mechaniczny 82012090803 Kowalski Jan 2004-03-05 2004-03-12 W7 Mechaniczny 70052000234 Nowak Andrzej 2005-01-15 2005-01-20 W3 Transport 82012090803 Kowalski Jan 2005-05-07 2005-05-17 W7 Mechaniczny 70052000234 Nowak Andrzej 2005-09-07 2005-05-17 W7 Mechaniczny 82012090803 Kowalski Jan 2006-03-05 2006-03-10 W7 Mechaniczny 70052000234 Nowak Andrzej 2006-04-03 2006-04-13 W7 Mechaniczny Bazy danych s.1-10
Analiza przykładowej relacji (2) Problemy związane z korzystaniem z bazy danych o powyższym schemacie: 1. Anomalie przy wstawianiu w relacji zaprojektowanej w przedstawiony sposób krotki zawierające dane pracowników, którzy nie byli jeszcze na zwolnieniu muszą zawierać puste pola. 2. Redundancja pewne informacje w bazie powtarzają się; np. Jan Kowalski był trzykrotnie na zwolnieniu, co spowodowało konieczność trzykrotnego powtórzenia jego pełnych danych. 3. Anomalie przy aktualizacji (niespójność bazy danych) dane pracowników występują w bazie kilkakrotnie mogą więc pojawić się niezgodności, np. Andrzej Nowak początkowo pracował na wydziale W3, jednak zanim poszedł na zwolnienie lekarskie 7 września 2005 r. zmienił wydział na W7, takie podejście powoduje, że w relacji występują krotki dotyczące tej samej osoby zawierające różne dane. 4. Anomalie przy usuwaniu informacje o wydziałach nie są odseparowane od danych pracowników, nie można usunąć wydziału nie usuwając danych pracowników. Bazy danych s.1-11
Zależność funkcjonalna Składnik B jest funkcjonalnie zależny od składnika A w relacji R(A, B, C, D) jeżeli każdej wartości aa jest przyporządkowana tylko jedna wartość bb. Zależność funkcjonalną B w stosunku do A zapisujemy AB. Np. w relacji Pracownik: Pracownik(PESEL, Nazwisko, Imię, DataP, DataK, IDW, NazwaW) PESELNazwisko jest zależnością funkcjonalną. Każda osoba ma przypisany unikalny numer PESEL, więc każdemu numerowi PESEL odpowiada dokładnie jedno nazwisko. Zależność odwrotna nie będzie zależnością funkcjonalną, ponieważ w zbiorze pracowników może pojawić się kilka osób o tym samym nazwisku, a w takim przypadku nazwisku będzie odpowiadać kilka różnych numerów PASEL. PESELDataP nie jest zależnością funkcjonalną. Jeden pracownik może mieć kilka zwolnień chorobowych (każde z nich rozpoczyna się innego dnia), więc jednemu numerowi PESEL może odpowiadać wiele dat. Bazy danych s.1-12
Zależność funkcjonalna elementarna Składnik B jest w zależności funkcjonalnej elementarnej od składnika A w relacji R(A, B, C, D) jeżeli jest funkcjonalnie zależny od A i nie jest funkcjonalnie zależny od części A. Rozpatrywanie zależności funkcjonalnej elementarnej ma sens jedynie dla składników, które można podzielić na mniejsze części. Np. w relacji Pracownik: Pracownik(PESEL, Nazwisko, Imię, DataP, DataK, IDW, NazwaW) PESEL,DataPDataK jest zależnością funkcjonalną elementarną. Data końca zależy funkcjonalnie od numeru PESEL i daty początku zwolnienia łącznie (wskazanie konkretnej osoby i daty rozpoczęcia zwolnienia jednoznacznie określa jego koniec), ale nie zależy funkcjonalnie tylko od numeru PESEL (analogicznie do zależności PESELDataP) lub tylko od daty początku zwolnienia (tego samego dnia kilku pracowników mogło pójść na zwolnienie). PESEL,DataPNazwisko nie jest zależnością funkcjonalną elementarną. Nazwisko jest zależne funkcjonalnie od samego numeru PESEL (wyjaśnione w przykładzie na stronie poprzedniej). Bazy danych s.1-13
Zależność funkcjonalna bezpośrednia Składnik B jest w zależności funkcjonalnej bezpośredniej od składnika A w relacji R(A, B, C, D) jeżeli jest funkcjonalnie zależny od A i nie istnieje taki składnik C dla którego zachodzi: AC i CB. Np. w relacji Pracownik: Pracownik(PESEL, Nazwisko, Imię, DataP, DataK, IDW, NazwaW) PESELImię jest zależnością funkcjonalną bezpośrednią. Poza numerem PESEL w relacji nie istnieje składnik, od którego Imię jest zależne funkcjonalnie (nazwisko może powtórzyć się u kilku pracowników), nie można więc wskazać składnika, poprzez który uzyskuje się zależność pośrednią. PESEL,DataPNazwaW nie jest zależnością bezpośrednią. Nazwa wydziału jest zależna funkcjonalnie od identyfikatora wydziału, jednocześnie identyfikator jest jednoznacznie wyznaczony przez numer PESEL i konkretną datę zwolnienia (danego dnia konkretny pracownik jest przypisany do jednego wydziału), stąd zachodzi: PESEL,DataPIDW, IDWNazwaW, istnieje więc składnik, poprzez który uzyskuje się zależność pośrednią. Bazy danych s.1-14
I forma normalna relacji Relacja R jest w pierwszej formie normalnej (IFN) jeżeli każdy ze składników, który nie jest elementem klucza, jest w zależności funkcjonalnej od klucza. Np. relacja Pracownik postaci: Pracownik(PESEL, Nazwisko, Imię, DataP, DataK, IDW, NazwaW) nie jest w IFN, ponieważ na etapie wstępnej analizy źle określono jej klucz. Zależność funkcjonalna od numeru PESEL występuje tylko w przypadku nazwiska i imienia pracownika, daty zwolnień chorobowych (DataP i DataK) oraz dane wydziału (IDW, NazwaW) nie są zależne funkcjonalnie od klucza. Inaczej: PESEL nie jest kluczem, ponieważ nie identyfikuje jednoznacznie krotki. Relacja będzie w IFN, gdy klucz zostanie uzupełniony o składnik DataP: Pracownik(PESEL, Nazwisko, Imię, DataP, DataK, IDW, NazwaW) W konkretnym dniu dany pracownik jest przypisany do jednego wydziału, istnieje więc zależność funkcjonalna PESEL,DataPIDW,NazwaW, ponadto PESEL i data początku jednoznacznie określają datę końca zwolnienia, więc również zależność funkcjonalna PESEL,DataPDataK. Bazy danych s.1-15
II forma normalna relacji Relacja R jest w drugiej formie normalnej (IIFN) jeżeli jest w IFN i każdy ze składników, który nie jest elementem klucza, jest w zależności funkcjonalnej elementarnej od klucza. Np. utworzona w poprzednim kroku relacja Pracownik postaci Pracownik(PESEL, Nazwisko, Imię, DataP, DataK, IDW, NazwaW) jest w IFN, ale nie w IIFN, ponieważ istnieją składniki (Nazwisko, Imię), które nie są zależne elementarnie od klucza (PESEL, DataP). Można wykazać, że (strona 12.): PESELNazwisko,Imię. W celu doprowadzenia relacji do IIFN należy dokonać dekompozycji na dwie relacje, których kluczem zostaną składniki będące źródłem zależności elementarnych: Pracownik1(PESEL, DataP, DataK, IDW, NazwaW) Pracownik2(PESEL, Nazwisko, Imię) Bazy danych s.1-16
III forma normalna relacji Relacja R jest w trzeciej formie normalnej (IIIFN) jeżeli jest w IIFN i każdy ze składników, który nie jest elementem klucza jest w zależności funkcjonalnej bezpośredniej od klucza. Np. utworzona w poprzednim kroku relacja Pracownik1 postaci Pracownik1(PESEL, DataP, DataK, IDW, NazwaW) jest w IIFN, ale nie jest w IIIFN, ponieważ istnieje składnik (NazwaW), który nie jest zależny bezpośrednio od klucza. Można wykazać, że (strona 14.): PESEL,DataPIDW, IDWNazwaW W celu doprowadzenia relacji do IIIFN należy dokonać dekompozycji na dwie relacje, których kluczem zostaną składniki będące źródłem zależności bezpośrednich: Pracownik1-1(PESEL, DataP, DataK, IDW) Pracownik1-2(IDW, NazwaW) Relacja Pracownik2 jest zarówno w IIFN jak i w IIIF, ponieważ jej wszystkie składniki zależą funkcjonalnie bezpośrednio od klucza. Bazy danych s.1-17
Podsumowanie Proces kolejnych transformacji, którym poddawana była pierwotna relacja Pracownik (strony 15-17) nazywany jest normalizacją danych. Jego podstawowym celem jest uzyskanie optymalnego modelu danych, pozbawionego redundancji i innych anomalii przedstawionych na stronie 11. Wynikiem normalizacji jest zestaw trzech relacji w IIIFN postaci: Pracownik1-1 (PESEL, DataP, DataK, IDW) Pracownik1-2 (IDW, NazwaW) Pracownik2 (PESEL, Nazwisko, Imię) Ostatnim krokiem tworzenia modelu danych powinna być analiza schematów relacji i przypisanie im nazw określających ich faktyczną zawartość. W tym przypadku relacja Pracownik2 zawiera dane osobowe pracowników, relacja Pracownik1-2 dane wydziałów, a Pracownik1-1 informacje o zwolnieniach chorobowych, więc ostateczny zestaw relacji przyjmuje postać: Pracownicy (PESEL, Nazwisko, Imię) Wydziały (IDW, NazwaW) Zwolnienia (PESEL, DataP, DataK, IDW) Bazy danych s.1-18
Analiza (1) Zawartość zestawu relacji na podstawie przykładowych danych ze strony 10.: Pracownicy PESEL Nazwisko Imię 70052000234 Nowak Andrzej 82012090803 Kowalski Jan Wydziały IDW NazwaW W3 Transport W7 Mechaniczny Zwolnienia PESEL DataP DataK IDW 82012090803 2004-03-05 2004-03-12 W7 70052000234 2005-01-15 2005-01-20 W3 82012090803 2005-05-07 2005-05-17 W7 70052000234 2005-09-07 2005-05-17 W7 82012090803 2006-03-05 2006-03-10 W7 70052000234 2006-04-03 2006-04-13 W7 Przyjmując rozmiary atrybutów (w znakach): PESEL 11, Nazwisko, Imię 25, IDW 2, NazwaW 15, DataP, DataK 10, otrzymujemy rozmiary: pierwotna relacja: (11+25+25+10+10+2+15) 8 = 98x8 = 784 relacje w IIIFN: (11+25+25) 2 + (2+15) 2 + (11+10+10+2) 6 = 122+34+198 = 354 Każde kolejne zwolnienie chorobowe powiększy rozmiar pierwotnej relacji o 98 znaków, natomiast w przypadku relacji w IIIFN będą to 33 znaki. Bazy danych s.1-19
Analiza (2) Cechy uzyskanego modelu danych: 1. Zestaw relacji w IIIFN pozwala wykonać aplikację zgodną z pierwotnym przeznaczeniem, realizującą zaplanowane funkcje (strona 6.). 2. W porównaniu do pierwotnej postaci relacji uzyskano znaczącą redukcję bazy danych (różnice będą tym większe im większa liczba zwolnień). 3. Relacje w IIIFN oferują dużo większą elastyczność, umożliwiając łatwą rozbudowę schematów relacji bez nadmiernego powiększania rozmiaru bazy danych (np. rozbudowa relacji Pracownicy o dodatkowe dane osobowe). 4. Wyeliminowane zostały redundancje, dzięki czemu aktualizacja danych stała się znacznie łatwiejsza (np. zmiana nazwy wydziału). 5. Dodanie nowego pracownika, który nie był jeszcze na zwolnieniu nie powoduje konieczności utworzenia krotki z pustymi danymi. Bazy danych s.1-20