Bazy danych 1. Wykład 4 Metodologia projektowania baz danych

Transkrypt

1 Bazy danych 1 Wykład 4 Metodologia projektowania baz danych

2 Fazy cyklu Ŝycia aplikacji bazodanowych Planowanie bazy danych Definicja systemu Gromadzenie i analiza wymagań Projektowanie bazy danych Konceptualne projektowanie bazy danych Logiczne projektowanie bazy danych Projektowanie aplikacji Fizyczne projektowanie bazy danych

3 Fazy cyklu Ŝycia aplikacji bazodanowych (cd) Implementacja Powrót do początku Konwersja i przenoszenie danych Faza Testowanie BieŜąca konserwacja

4 Cykl Ŝycia aplikacji bazy danych Faza Planowanie bazy danych Definicja systemu Gromadzenie i analiza wymagań Projektowanie bazy danych Selekcja DBMS (opcjonalnie) Projektowanie aplikacji Tworzenie prototypów (opcjonalnie) Implementacja Konwersja i przenoszenie danych Testowanie Bieżą żąca konserwacja Główne czynności Planowanie najbardziej skutecznych i wydajnych metod realizacji faz cyklu życia. Określenie zakresu i granic stosowania danej aplikacji bazy danych,, wskazanie jej użytkowników oraz obszarów zastosowań. Zbieranie i analiza wymagań pochodzących od użytkowników i wynikających z obszarów zastosowań. Projektowanie konceptualne, logiczne i fizyczne bazy danych. Wybór DBMS odpowiedniego dla aplikacji bazy danych. Projektowanie interfejsów użytkowników i programów użytkowych, które będą przetwarzać bazę danych. Budowanie działającego modelu aplikacji bazy danych, który pozwala projektantom i użytkownikom zobrazować i ocenić sposób działania i wygląd końcowego systemu. Tworzenie zewnętrznych, konceptualnych i wewnętrznych definicji bazy danych i programów użytkowych. Przenoszenie danych ze starego systemu do nowego. Testowanie i usuwanie błę łędów z aplikacji bazy danych oraz sprawdzanie zgodności z wymaganiami użytkowników. Aplikacja bazy danych jest w pełni zaimplementowana. System jest na bieżą żąco monitorowany i konserwowany. W razie potrzeby do aplikacji bazy danych są wprowadzane nowe wymagania poprzez ponowne przejście przez powyższe fazy.

5 Metody projektowania bazy danych Metoda wstępująca nadaje się do projektowania prostych baz danych zawierających względnie małą liczbę atrybutów, proces projektowania bazy danych rozpoczyna się od zidentyfikowania wszystkich atrybutów, a następnie poprzez analizę zaleŝności funkcyjnych (powiązań) pomiędzy atrybutami łączy się je w relacje (tabele) Metoda zstępująca nadaje się do projektowania złoŝonych baz danych zawierających względnie duŝą liczbę atrybutów, proces projektowania bazy danych rozpoczyna się od zidentyfikowania istotnych encji (bytów) oraz związków pomiędzy nimi, a następnie stosując metodę kolejnych uściśleń wprowadza się encje, związki oraz atrybuty niŝszego poziomu.

6 Etapy projektowania bazy danych Konceptualne projektowanie bazy danych to proces konstrukcji modelu danych, który jest niezaleŝny od wszelkich aspektów fizycznych (specyficzny model danych, docelowy SZBD, programy uŝytkowe, języki programowania, platforma sprzętowa) Logiczne projektowanie bazy danych to proces konstrukcji modelu, który jest oparty na specyficznym modelu danych (np. model relacyjny, model obiektowy) ale niezaleŝny od konkretnego SZBD i innych aspektów fizycznych. Fizyczne projektowanie bazy danych to proces tworzenia opisu implementacji bazy danych w pamięci zewnętrznej. Opis ten zawiera bazowe relacje oraz organizacje plików i indeksów zapewniających efektywny dostęp do danych, realizacje więzów integralności i środków bezpieczeństwa danych.

7 Metodologie tworzenia systemów Obecnie stosowane są dwie główne metodologie tworzenia systemów informatycznych. Metodologia strukturalna podejście starsze, ale ciągle jeszcze rozpowszechnione w praktyce. Metodologia obiektowa podejście nowsze, zdobywające coraz większą popularność na rynku.

8 Podejście strukturalne czyli encje i związki

9 Modelowanie strukturalne W podejściu strukturalnym do modelowania danych wykorzystujemy głównie diagram związków encji Diagram związków encji (ang. Entity Relationship Diagram, ERD) opisuje warstwę danych w systemie; składa się ze zbioru obiektów - encji i struktury powiązań między nimi. Diagramy ERD szczególnie dobrze nadają się do modelowania relacyjnych baz danych, poniewaŝ umoŝliwiają prawie bezpośrednie przejście od diagramu do końcowego schematu relacyjnego. PowyŜsza cecha sprawia, Ŝe diagramy ERD i obejmująca je metodologia strukturalna są ciągle rozpowszechnione w praktyce firm rozwijających oprogramowanie. Diagramy ERD posiadają ograniczenia reprezentacji charakterystyczne dla relacyjnego modelu danych (m.in. problemy z modelowaniem dziedziczenia) i mogą sprawiać problemy przy integracji warstwy danych z obiektowym modelem reszty aplikacji. Cechy te skłaniają wytwórców oprogramowania do stopniowego zastępowania metodologii strukturalnej obiektową.

10 Diagram związków encji (ERD) Podstawowe pojęcia zbiór (typ) encji (ang. entity type) to grupa obiektów wziętych z rzeczywistego świata o tych samych właściwościach (cechach). wystąpienie (instancja) encji (ang. entity) to unikalny i rozpoznawalny obiekt ze zbioru encji; związek (ang. relationship) to zbiór powiązań pomiędzy jednym lub większą liczbą uczestniczących w tym związku encji. wystąpienie związku to unikalne i identyfikowalne powiązanie zachodzące pomiędzy pojedynczymi wystąpieniami encji z uczestniczących w związku zbiorów encji atrybut (ang. attribute) własność, cecha encji lub związku asocjacja (ang. association) reprezentuje związek między encjami, który posiada pewne cechy, ale nie ma bezpośredniej interpretacji jako obiekt świata rzeczywistego.

11 Encje Encja Encja jest rzeczą, która w modelowanej organizacji jest rozpoznawana jako istniejący niezaleŝnie obiekt, zdarzenie lub pojęcie. Encja daje się wyodrębnić i odróŝnić od pozostałych elementów opisu świata. ENCJE Charakter fizyczny np. Personel, Nieruchomość. Charakter pojęciowy np. Wizyta, SprzedaŜ. Encja jest wystąpieniem typu encji, czyli obiektem, który jest elementem pewnej klasy (np. encja Sieciowe bazy danych jest wystąpieniem typu encji Przedmiot ). JednakŜe w metodologiach projektowych powszechnie uŝywa się terminu encja w znaczeniu typ encji.

12 Związki Związek reprezentuje powiązanie między encjami, wynikające z opisu modelowanego fragmentu rzeczywistości Przykład: Zazwyczaj rozpatrujemy związki binarne, to znaczy łączące jednocześnie dwie encje. Związki mogą być równieŝ wieloelementowe łączące wiele encji. Przykład: Biuro zatrudnia Personel Związek binarny - Biuro zatrudnia Personel Związek potrójny Personel rejestruje Klienta w Biurze Kontekst związku między encjami jest często wyznaczany przez rolę, którą jedna encja pełni względem drugiej (np. encja Grupa składa się ze Studentów ; Wykładowca prowadzi Przedmiot ). Między dwiema encjami moŝe istnieć więcej niŝ jeden związek, co moŝe wynikać z róŝnych ról, które są wzajemnie pełnione przez encje (np. Grupa składa się ze Studentów, ale jednocześnie Student jest starostą w Grupie ).

13 Związki KaŜdy związek jest opisywany przez dwie cechy: liczebność i uczestnictwo. Liczebność (stopień) określa liczbę wystapień encji biorących udział w związku: 1:1 (jeden-do-jednego), 1:N (jeden-do-wielu), N:M (wiele-do-wielu).

14 Związki Uczestnictwo (opcjonalność): opcjonalne - jeśli istnieje przynajmniej jedna instancja encji, która nie bierze udziału w związku (w diagramach reprezentowane przez kółko przy encji); wymagane - jeśli wszystkie instancje muszą brać udział w związku (w diagramach reprezentowane przez kreskę przy encji).

15 Związki Przykład: PoniŜszy diagram mówi, Ŝe kaŝdy student moŝe naleŝeć do jednej grupy, a grupa musi się składać się przynajmniej z jednego studenta. Tak więc uczestnictwo encji Grupa w związku jest opcjonalne (w danym okresie student moŝe nie naleŝeć do Ŝadnej grupy na przykład w czasie urlopu dziekańskiego), natomiast uczestnictwo encji Student w związku jest obowiązkowe (nie moŝe powstać grupa, w której nie ma Ŝadnych studentów).

16 Związki Liczebność i uczestnictwo moŝna wyraŝać poprzez podanie przedziałów (Min, Max) lub Min, Max lub Min..Max po kaŝdej stronie encji: 0, 1 lub znaczenie 1 :?, opcjonalne; 1, 1 lub znaczenie 1 :?, wymagane; 0, N lub 0..N - znaczenie N :?, opcjonalne; 1, N lub 1..N - znaczenie N :?, wymagane. Wybór konkretnej formy reprezentacji liczebności i uczestnictwa zaleŝy od moŝliwości narzędzia, w którym tworzymy diagramy ERD.

17 Związki Związek rekurencyjny to związek, w którym ten sam zbiór encji występuje więcej niŝ jeden raz w róŝnych rolach Przykład: Związek rekurencyjny Personel (kierownik) kieruje Personelem (kierowanymi)

18 Asocjacja asocjacja (ang. association) reprezentuje związek między encjami, który posiada pewne cechy, ale nie ma bezpośredniej interpretacji jako obiekt świata rzeczywistego. asoscjacja posiada więc swoje własne atrybuty

19 Atrybuty Atrybut to cecha encji lub związku Dziedzina atrybutu to zbiór dopuszczalnych wartości dla danego atrybutu Atrybut prosty to atrybut zawierający tylko jedną składową, która moŝe istnieć niezaleŝnie. Przykład: Atrybuty stanowisko i pensja w encji Personel Atrybut złoŝony to atrybut zbudowany z wielu składowych z których kaŝda moŝe istnieć niezaleŝnie. Przykład: Atrybut adres w encji Biuro ma składowe ulica, miasto, kod

20 Atrybuty Atrybut jednowartościowy to atrybut, który ma tylko jedną wartość dla kaŝdego wystąpienia encji. Przykład: Atrybut biuronr w encji Biuro Atrybut wielowartościowy to atrybut, który moŝe zawierać wiele wartosci dla pojedynczego wystąpienia encji. Przykład: Atrybut telnr moŝe przyjmować wiele wartości dla kaŝdego wystąpienia encji Biuro Atrybut pochodny to atrybut reprezentujący wartość, która jest wyliczana z innego atrybutu lub zbioru atrybutów, niekoniecznie pochodzących z tego samego zbioru encji Przykład: Atrybut okresnajmu moŝe być wyliczony z atrybutów wynajeteod i wynajetedo

21 Klucze Klucz kandydujący to najmniejszy zbiór atrybutów, który jednoznacznie identyfikuje kaŝde wystąpienie encji w zbiorze encji. Przykład: Atrybut biuronr jest kluczem kandydującym dla zbioru encji Biuro Klucz główny (ang. primary key) to klucz kandydujący. Który został wybrany do jednoznacznej identyfikacji kaŝdego z wystąpień encji w zbiorze encji. Klucz złoŝony to klucz kandydujący, który składa się co najmniej z dwóch atrybutów.

22 Pułapki Pułapka wachlarzowa występuje w sytuacji, gdy model przedstawia związek zek pomiędzy pewnymi zbiorami encji (klasami), ale wynikające z tego ścieŝki pomiędzy wystąpieniami encji (obiektami) nie sąs jednoznaczne; pułapka taka moŝe e wystąpi pić,, gdy co najmniej dwa związki zki typu 1:* wychodzą z tej samej encji (klasy) Problem: Rozwiązanie: zanie:

23 Pułapki Pułapka szczelinowa występuje gdy model sugeruje istnienie związku zku pomiędzy zbiorami encji (klasami), ale nie istnieje ścieŝka łącz cząca ca pewne wystąpienia tych encji (obiekty); pułapka ta moŝe e wystąpi pić,, gdy w modelu znajduje się co najmniej jeden związek zek o minimalnej krotności zero, który jest elementem ścieŝki pomiędzy powiązanymi encjami (klasami) Problem: Rozwiązanie: zanie:

24 Projektowanie konceptualne przegląd krok po kroku 1. Określ występujące zbiory encji 2. Ustal typy występujących związków 3. Określ atrybuty odpowiadające poszczególnym encjom 4. Określ dziedziny poszczególnych atrybutów 5. Ustal klucze kandydujące i klucze główne 6. RozwaŜ moŝliwość zastosowania zaawansowanych metod modelowania 7. Zweryfikuj utworzony model pod kątem występowania redundancji 8. Zweryfikuj moŝliwość realizacji transakcji 9. Omów konceptualny model z uŝytkownikiem

25 Projektowanie konceptualne (krok 1) Określ występujące zbiory encji Nazwa zbioru encji Opis Aliasy Własności Rozmiar zbioru Firma Pojęcie ogólne opisujące wszystkie firmy koncernu Zakład KaŜda firma ma 4 wydziały 20 Wydział Pojęcie ogólne opisujące wszystkie oddziały firm koncernu Wydziałfirmy KaŜdy oddział naleŝy do jednej firmy i kaŝdy wydział zatrudnia przynajmniej jednego pracownika 80

26 Projektowanie konceptualne (krok 2) Ustal typy występujących związków UŜywaj diagramów związków encji Ustal krotności w poszczególnych związkach encji Sprawdź, czy nie występują pułapki wachlarzowe lub szczelinowe Sprawdź, czy kaŝdy zbiór występuje przynajmniej w jednym związku Udokumentuj typy związków Nazwa encji Rola Krotność Związek Nazwa encji Krotność Rola Firma x 1..1 Ma Wydział 4..4 x Wydział Pracodawca 1..1 Zatrudnia Pracownik 1..* Pracobiorca

27 Projektowanie konceptualne (krok 3) Określ atrybuty odpowiadające zbiorom encji i związkom Potencjalne problemy Atrybut naleŝy do więcej niŝ jednego zbioru encji Zidentyfikowaliśmy zbiory encji, które powinny być reprezentowane jako jedna encja Wykryliśmy nowy związek między encjami Opis atrybutów Firma Id_Firmy, Nazwa, Adres_siedziby (złoŝony: ulica, nr, Kod, Miejscowość), Nr_Wpisu_KRG

28 Projektowanie konceptualne (krok 3) Określ atrybuty odpowiadające zbiorom encji i związkom Dokumentowanie informacji o atrybutach Nazwa i opis atrybutu Typ danych, długość i dziedzina atrybutu Wszystkie aliasy danego atrybutu Czy atrybut jest złoŝony Czy jest to atrybut wielowartościowy Czy jest to atrybut pochodny, formuła słuŝąca do wyliczenia Domyślna wartość atrybutu

29 Projektowanie konceptualne (krok 3) Określ atrybuty odpowiadające zbiorom encji i związkom Nazwa zbioru encji Atrybuty Opis Typ danych Długość Dziedzina Aliasy Pracownik ID_Pracownika ImięNazwisko Jednoznacznie identyfikuje pracownika Łańcuch 4 Numer Personel Imię Nazwisko DataUrodzenia Imię pracownika Nazwisko pracownika Data urodzenia pracownika Łańcuch Łańcuch Data maks. 15 maks. 20 Tekst Tekst Data_ur X X x

30 Projektowanie konceptualne (krok 3) Określ atrybuty odpowiadające zbiorom encji i związkom Atrybut Wartości puste Wielowartościowy Pochodny Wartość domyślna ID_Pracownika Nie Nie Nie Brak ImięNazwisko Imię Nie Nie Nie Brak Nazwisko Nie Nie Nie Brak Data urodzenia Tak Nie Nie Brak

31 Projektowanie konceptualne (krok 4) Określ dziedziny poszczególnych atrybutów Dziedzina to zbiór wartości, które moŝe przyjmować jeden atrybut Określenie dziedziny powinno obejmować: Dopuszczalny zbiór wartości atrybutu Dopuszczalny zakres długości i format atrybutu NaleŜy dokumentować zdefiniowane dziedziny w słowniku danych Nazwa dziedziny Typ danych Długość Format Dopuszczalny zbiór wartości atrybutu Płeć Znak 1 X M lub K Data Data_ur x rrrr-mm-dd od do data bieŝąca 18 lat

32 Projektowanie konceptualne (krok 5) Ustal klucze kandydujące i klucze główne W tym kroku ustalamy klucze kandydujące i klucze główne Przy wyborze klucza głównego warto rozwaŝyć Klucz o najmniejszej liczbie atrybutów Klucz, którego wartości najrzadziej ulęgają zmianom Klucz kandydujący o najmniejszej liczbie znaków Klucz o najmniejszej wartości maksymalnej Klucz z którego najłatwiej będzie korzystać uŝytkownikowi Nazwa encji Klucze kandydujące Klucz główny Firma Id_Firmy Nazwa Nr_Wpisu_KRG Id_Firmy

33 Projektowanie konceptualne (krok 5) Ustal klucze kandydujące i klucze główne Encję nazywamy silną jeśli jej istnienie nie jest zaleŝne od innych zbiorów encji, cechą charakterystyczną jest jednoznaczna identyfikacja kaŝdego wystąpienia encji przez atrybut(y) klucza głównego Encję nazywamy słabą jeśli jej istnienie zaleŝy od innych zbiorów encji, cechą charakterystyczną jest brak jednoznacznej identyfikacji kaŝdego wystąpienia encji za pomocą atrybutów przypisanych wyłącznie tej encji. Przykład: Klient Określa Preferencje Nr_klienta Typ_preferencji Encja Personel nie ma swojego klucza głównego, zidentyfikowanie klucza głównego tej encji jest moŝliwe dopiero po odwzorowaniu tego zbioru encji na relacje (klucz obcy)

34 Projektowanie konceptualne (krok 6) RozwaŜ moŝliwość zastosowania zaawansowanych metod modelowania (krok opcjonalny) Brak jest ścisłych reguł wskazujących, w jakich sytuacja ch naleŝy zastosować w modelu związków encji zaawansowane metody modelowania, wybór jest zazwyczaj subiektywny i zaleŝy od specyfiki modelowanego zagadnienia. Przy wyborze naleŝy kierować się zasadą wyboru jak najczytelniejszej reprezentacji w diagramie ER dla istotnych zbiorów encjii związków miedzy nimi. Po wykonaniu tego kroku wykonujemy pełny digram związków encji

35 Uogólnienie Relacja uogólnienia jest jednym z elementów w nie występuj pujących w modelowaniu strukturalnym. Reprezentuje ona informację, Ŝe e dana klasa (nadklasa) jest uogólnieniem innej klasy (podklasy). Podklasa posiada wszystkie cechy nadklasy oraz cechy dodatkowe. Przykład: Klasa Pracownik posiada wszystkie cechy klasy Osoba,, a ponadto szereg atrybutów w dodatkowych, charakterystycznych tylko dla pracowników. w. Nadklasa i podklasa odnoszą się do tego samego obiektu.

36 Uogólnienie Podklasa jest niezaleŝną klasą i dlatego moŝe e sama posiadać podklasy. Wtedy powstaje hierarchia uogólnienia: obiekty znajdujące się niŝej w hierarchii dziedziczą atrybuty i związki zki od obiektów, które sąs nad nimi; uczestnictwo nadklasy w związku zku uogólnienia jest zawsze opcjonalne i ma liczebność 1, natomiast uczestnictwo podklasy w związku zku uogólnienia jest zawsze wymagane i ma liczebność *

37 Uogólnienie Podklasy rozłączne nie mają Ŝadnych wspólnych obiektów. Przykład: Klasy Pracownik administracyjny i Pracownik techniczny (nadklasa Pracownik) są rozłączne, poniewaŝ Ŝaden pracownik nie moŝe być jednocześnie pracownikiem administracyjnym i technicznym. Podklasy przecinające się mogą zawierać wspólne obiekty. Przykład: Klasy Student i Pracownik (nadklasa Osoba) są przecinające się, poniewaŝ dana osoba moŝe być jednocześnie studentem i pracownikiem.

38 Projektowanie konceptualne (krok 7) Zweryfikuj utworzony model pod kątem występowania redundancji Ponowne sprawdzenie zwiazków wzajemnie jednoznacznych (1:1) W trakcie ustalania występujących zbiorów encji moŝe dojść do utworzenia dwóch róŝnych zbiorów reprezentujących te same obiekty ze świata rzeczywistego, naleŝy w tej sytuacji te zbiory encji połączyć Usunięcie związków redundantnych O związku moŝna powiedzieć, Ŝe jest redundantny (nadmiarowy), jeśli informacje, których on dostarcza, moŝna uzyskać w oparciu o inny związek. Związki nadmiarowe mogą zostać usunięte, poniewaŝ nie wnoszą nowej informacji. Zalecana ostroŝność. Sprawdzenie, czy nie występują pułapki wachlarzowe i szczelinowe

39 Projektowanie konceptualne (krok 8) Transakcja to jedna lub kilka operacji odwołujących się do zawartości bazy danych lub ją modyfikujących, które przeprowadza pojedynczy uŝytkownik lub aplikacja Własności transakcji to: niepodzielność transakcja jest wykonywana w całości albo wcale spójność transakcja zachowuje spójność bazy danych izolacja transakcje, są całkowicie od siebie niezaleŝne trwałość zmiany dokonane przez pomyślnie zakończoną transakcję są zachowywane na trwale Weryfikacji opisanej w punkcie 8 moŝemy dokonać poprzez: sporządzenie opisu transakcji wykorzystanie ścieŝek transakcji

40 Na tę chwilę to koniec (uff) c.d.n. Dziękuję za uwagę!