Bazy danych 2. Wykład 2 czyli Kilka słów o tworzeniu aplikacji bazodanowej

Transkrypt

1 Bazy danych 2 Wykład 2 czyli Kilka słów o tworzeniu aplikacji bazodanowej

2 Metody projektowania baz 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.

3 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 BDMS, 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 BDMS 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.

4 Zanim utworzymy model konceptualny

5 Zanim zrobimy model konceptualny 1. Cel projektu 2. Analiza wycinka rzeczywistości 3. Słownik pojęć 4. Wyodrębnienie kategorii KAT/OO1 Towar Opis: Kategoria Towar służy do opisu towaru przechowywanego w magazynie; Towar może być dostarczany przez różnych dostawców Atrybuty: Symbol towaru - unikatowy symbol towaru Nazwa Jadnostka miary 5. Reguły funkcjonowania REG/001 Towar przyjmowany jest na podstawie dokumentu PZ

6 Zanim zrobimy model konceptualny 1. Ograniczenia dziedzinowe OGR/001 Długość nazwy towarów nie może być wieksza niż 20 znaków 2. Zdefiniowanie transakcji TRA/001 Wprowadzenie towaru Opis: Zadaniem transakcji jest wprowadzenie danych towaru i wygenerowaqnie unikatowego symbolu towaru Uwarunkowania: - dane towaru nie mogą znajdować się w bazie; - wszystkie atrybuty musza mieć podana wartość (być wypełnione) Użytkownik Baza danych Wejście Dane towaru Unikatowy symbol towaru Wyjście - Dane towaru

7 Projektowanie konceptualne przegląd 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

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

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

10 Projektowanie logiczne przegląd Wyznacz relacje dla logicznego modelu danych Wykonaj normalizację relacji Sprawdź, czy relacje umożliwiają realizacje transakcji. Wyznacz więzy integralności. Omów logiczny model danych z użytkownikiem.

11 Projektowanie logiczne (krok 1) 1. Wyznacz relacje dla logicznego modelu danych Relacje będziemy opisywać za pomocą języka definiowania bazy danych DBDL (DataBase Definition Language) Definicja (uproszczona) relacji w DBDL zawiera: nazwę relacji (w liczbie mnogiej), ujętą w nawiasy listę prostych atrybutów relacji, klucz główny, wszystkie klucze alternatywne i obce, nazwę relacji zawierającą wskazany klucz obcy jako klucz główny listę atrybutów pochodnych wraz z wyrażeniami definiującymi sposób wyliczenia ich wartości.

12 Projektowanie logiczne (krok 2) Przykład definicji relacji w DDL Relacj a_a Klucz_A Atrybu ta1 <pk> Rel acja_b Klu cz_b Klu cz_a AtrybutB1 <pk> <fk> Relacja_A (Klucz_A, AtrybutA1) Primary Key Klucz_A Relacja_B (Klucz_B, Klucz_A, AtrybutB1) Primary Key Klucz_B Foreign Key Klucz_A references Relacja_A(Klucz_A)

13 Projektowanie logiczne (krok 1) reguły transformacji 1. Dla każdej encji tworzymy schemat relacji (reprezentacją relacji jest tabela). Najczęściej nazwa relacji jest taka sama jak nazwa encji, tylko w liczbie mnogiej ze względu na to, ze relacja zawiera wiele wystąpień obiektu. 2. Atrybuty encji stają się atrybutami w schemacie relacji. Atrybuty odpowiadające kluczom głównym stają się kluczami głównymi relacji. Atrybuty opcjonalne stają się kolumnami o dopuszczalnych wartościach NULL, atrybuty obligatoryjne stają się kolumnami NOT NULL. 3. Sposób tworzenia kluczy obcych zależy od liczności (krotności) oraz uczestnictwa encji w związku.

14 Reguły transformacji związki typu 1:1 Uczestnictwo obowiązkowe po obu stronach związku A - Klucz_A B - Kl ucz_b Z encji A i B tworzymy jeden schemat relacji RAB, który zawiera atrybuty obu encji, a kluczem głównym jest klucz główny encji A lub klucz główny encji B. RAB Klucz_A Klucz_B <pk>

15 Reguły transformacji związki typu 1:1 Uczestnictwo obowiązkowe po jednej stronie związku A - Klucz_A B - Klucz_B Z encji A i B tworzymy schematy relacji RA i RB; do schematu RB wstawiamy jako dodatkowy atrybut klucz główny ze schematu RA. RA RB Klucz_A <pk> Klucz_B Klucz_A <pk> <fk>

16 Reguły transformacji związki typu 1:1 Uczestnictwo opcjonalne po obu stronach związku A - Klucz_A B - Klucz_B Dopuszczalne różne rozwiązania: -tworzymy relacje RA i RB przy czym klucz główny jednej z nich umieszczamy w relacji drugiej jako klucz obcy (wartości NULL) - tworzymy schematy relacji RA i RB, a związek reprezentujemy nowym schematem RAB, który zawiera dwa klucze obce - klucz główny relacji RA i klucz główny relacji RB RA Klucz_A <pk> Klucz_A Klucz_B RAB <pk,fk1> <pk,fk2> RB Klucz_B <pk>

17 Reguły transformacji związki typu 1:1 z atrybutami Przypadek gdy związek ma atrybuty A - Klucz_A Zwiazek - Atrybut_Zwiazku B - Klucz_B Z encji A i B tworzymy schematy relacji RA i RB; związek reprezentujemy schematem RAB, który zawiera dwa klucze obce klucz główny ze schematu RA i klucz główny ze schematu RB - oraz atrybuty związku RA RB Klucz_A <pk> Kl ucz_b <pk> RAB Klucz_A Klucz_B Atrybut_Zwiazku <pk,fk1> <pk,fk2>

18 Reguły transformacji związki rekurencyjne typu 1:1 Uczestnictwo obowiązkowe po obu stronach związku 1..1 Rola2 A - Klucz_ A 1..1 Rola1 Tworzymy jeden schemat relacji RA zawierający dwie kopie klucza głównego. Jedna kopia jest kluczem obcym i powinna mieć nazwę wskazującą na reprezentowany związek (rola). RA Klucz_A Rola 1_Klu cz_a <pk> <fk1>

19 Reguły transformacji związki rekurencyjne typu 1:1 Uczestnictwo opcjonalne po jednej stronie związku 1..1 Rola2 A - Klucz_A 0..1 Rola1 Tworzymy schemat relacji RA z kluczem głównym odpowiadającym kluczowi głównemu encji A oraz schemat RAA, który zawiera dwa klucze obce klucze główne ze schematu RA - opatrzone rolą, którą encja sprawuje w związku. RA RAA Klucz_A <pk> Rola1_Klucz_A Rola2_Klucz_A <pk,fk1> <pk,fk2>

20 Reguły transformacji związki rekurencyjne typu 1:1 Uczestnictwo opcjonalne po obu stronach związku 0..1 Rola2 A - Klucz_A 0..1 Rola1 Tworzymy schemat relacji RA z kluczem głównym odpowiadającym kluczowi głównemu encji A oraz schemat RAA, który zawiera dwa klucze obce klucze główne ze schematu RA - opatrzone rolą, którą encja sprawuje w związku. RA RAA Klucz_A <pk> Rola1_Klucz_A Rola2_Klucz_A <pk,fk1> <pk,fk2>

21 Reguły transformacji związki rekurencyjne typu 1:1 z atrybutami Przypadek gdy związek ma atrybuty 1..1 Rola2 A - Klucz_A 1..1 Rola1 Zwi azek - Atrybut_Zwiazku Tworzymy schemat relacji RA z kluczem głównym odpowiadającym kluczowi głównemu encji A oraz schemat RAA, który zawiera dwa klucze obce klucze główne ze schematu RA - opatrzone rolą, którą encja sprawuje w związku oraz atrybuty związku. A RAA Klucz_A <pk> Rola 1_Klucz_A Rola 2_Klucz_A Atrybut_ Zwiazku <p k,fk1> <p k,fk2>

22 Reguły transformacji związki typu 1:* Uczestnictwo obowiązkowe po stronie wiele związku A - Klu cz_a * B - Klucz_B Z encji A i B tworzymy schematy relacji RA i RB; do schematu RB wstawiamy jako dodatkowy atrybut klucz główny ze schematu RA. RA RB Klucz_A <pk> Klucz_B Klucz_A <pk> <fk>

23 Reguły transformacji związki typu 1:* Uczestnictwo opcjonalne po stronie wiele związku A - Klucz_A * B - Klucz_B jak wyżej Z encji A i B tworzymy schematy relacji RA i RB, jeśli dużo wystąpień encji B nie uczestniczy w związku, to związek reprezentujemy schematem RAB, który zawiera dwa klucze obce klucz główny ze schematu RA i klucz główny ze schematu RB. RA Klucz_A <pk> Klucz_A Klucz_B RAB <pk,fk1> <pk,fk2> RB Klucz_B <pk>

24 Reguły transformacji związki typu 1:* z atrybutami Uczestnictwo obowiązkowe po stronie wiele związku A - Klucz_A * Zwiazek - Atrybut_Zwiazku B - Klucz_ B Z encji A i B tworzymy schematy relacji RA i RB; do schematu RB wstawiamy jako dodatkowy atrybut klucz główny ze schematu RA oraz atrybuty związku. RA Klucz_A <pk> RB Kl ucz_b Kl ucz_a Atrybut_Zwi azku <pk> <fk>

25 Reguły transformacji związki typu 1:* z atrybutami Uczestnictwo opcjonalne po stronie wiele związku A - Klucz_A * B - Klucz_B Z encji A i B tworzymy schematy relacji RA i RB, jeśli dużo wystąpień encji B nie uczestniczy w związku, to związek reprezentujemy schematem RAB, który zawiera dwa klucze obce klucz główny ze schematu RA i klucz główny ze schematu RB oraz atrybuty związku. RA Klucz_A <pk> RB Kl ucz_b <pk> RAB Klucz_A Klucz_B Atrybut_Zwiazku <pk,fk1> <pk,fk2>

26 Reguły transformacji związki typu *:* (bez i z atrybutami) Uczestnictwo opcjonalne po obu stronach A - Klu cz_a 0..* 0..* Zwiaze k - A trybu t_zwi azku B - Klucz_B Z encji A i B tworzymy schematy relacji RA i RB, związek reprezentujemy schematem RAB, który zawiera dwa klucze obce klucz główny ze schematu RA i klucz główny ze schematu RB (oraz atrybuty związku). RA RB Klucz_A <pk> Klucz_B <pk> RAB Kl ucz_a Kl ucz_b Atrybut_Zwi azku <pk,fk1> <pk,fk2>

27 Reguły transformacji związki reku-rencyjne typu *:* (bez i z atrybutami) Uczestnictwo opcjonalne po obu stronach 0..* Rola2 A - Klucz_A 0..* Rola1 Zwia zek - Atryb ut_zwia zku Z encji A schemat relacji RA, związek reprezentujemy schematem RAA, który zawiera dwa klucze obce klucze główne ze schematu RA opatrzone rolą, którą encja sprawuje w związku (oraz atrybuty związku). RA RAA Kl ucz_a <pk> Rola1_Klucz_A Rola2_Klucz_A Atrybut_Zwiazku <pk,fk1> <pk,fk2>

28 Przekształcenie uogólnienia w schemat relacyjny Metoda 1: tworzymy tabele: jedną dla nadklasy i po jednej dla każdej podklasy; w tabelach podklas wstawiamy klucz tabeli nadklasy (jako klucz obcy). Wykorzystanie praktyczne: Schemat relacyjny uzyskany w ten sposób jest najlepszy z punktu widzenia normalizacji, może on być jednak niewydajny przy częstych złączeniach tabeli nadrzędnej z tabelami podrzędnymi. Metoda ta może przynieść dobre wyniki, jeśli: podklasy znacznie różnią się od siebie (mają wiele różnych atrybutów); podklasy są silnie przecinające się (jest wiele obiektów, które jednocześnie należą do więcej niż jednej podklasy) wówczas łatwiej uniknąć jest niespójności danych (np. określona osoba może być jednocześnie należeć do klasy Student i Pracownik; modyfikując jej dane, na przykład atrybut , mamy pewność, że wystarczy nanieść zmiany w jednym miejscu: w tabeli [Osoba]).

29 Przekształcanie uogólnienia w schemat relacyjny metoda 1 Diagram klas Schemat relacji

30 Przekształcanie hierarchii uogólnienia w schemat relacyjny Metoda 2: tworzymy po jednej tabeli dla każdej podklasy; do każdej tabeli wstawiamy wszystkie atrybuty nadklasy. Wykorzystanie praktyczne: Stosujemy te metodą, gdy każde wystąpienie nadklasy musi należeć do przynajmniej jednej podklasy oraz podklasy dość znacznie różnią się Schemat ten jest wydajnie przetwarzany, jeśli są częste odwołania do tabel powstałych z podklas (unikamy złączeń tabel). Posługując się tą metodą tracimy zysk z zamodelowanego wcześniej uogólnienia (dziedziczenia) na przykład system nie rozpoznaje faktu, że obiekt zapisany w tabeli Student i Pracownik może być samą osobą.

31 Przekształcanie uogólnienia w schemat relacyjny metoda 2 Diagram klas Schemat relacji

32 Przekształcanie hierarchii uogólnienia w schemat relacyjny Metoda 3: tworzymy dwie tabele: jedna reprezentuje nadklasę, a druga podklasy, do drugiej tabeli wstawiamy wszystkie atrybuty podklas oraz klucz główny nadklasy jako klucz obcy; w razie potrzeby dodajemy pole rozróżniające, informujące, z której podklasy pochodzi dany obiekt. Wykorzystanie praktyczne: Rozwiązanie to może być zastosowane tylko wtedy, gdy podklasy różnią się między sobą minimalnie (np. pojedynczymi atrybutami) oraz wystąpienie nadklasy nie musi należeć do żadnej z podklas.

33 Przekształcanie uogólnienia w schemat relacyjny metoda 3

34 Przekształcanie hierarchii uogólnienia w schemat relacyjny Metoda 4: tworzymy jedną tabelę; wstawiamy do niej wszystkie atrybuty z nadklasy i podklas; w razie potrzeby dodajemy pole rozróżniające, informujące, z której podklasy pochodzi dany obiekt. Wykorzystanie praktyczne: Rozwiązanie to może być zastosowane tylko wtedy, gdy podklasy różnią się między sobą minimalnie (np. pojedynczymi atrybutami), a wystąpienie nadklasy należy przynajmniej do jednej z podklas W przeciwnym razie w wierszach może występować wiele wartości NULL (jest to bardzo niekorzystne z punktu widzenia normalizacji schematu relacyjnego i potencjalnych anomalii przy aktualizacji danych).

35 Przekształcanie uogólnienia w schemat relacyjny metoda 3 Diagram klas Schemat relacji Dodatkowe pole rozróżniające

36 Projektowanie logiczne (krok 2) Wykonaj normalizację relacji Celem tego kroku jest przekształcenie każdej relacji co najmniej do postaci Boyce a-codda (BCNF). Projekt logiczny (po wykonaniu normalizacji) nie musi być projektem ostatecznym. Jeśli wymagają tego kryteria dotyczące wydajności, projekt fizyczny może się różnić od logicznego jedną z możliwości jest denormalizacja niektórych relacji. Normalizacja służy udoskonaleniu modelu danych tak, aby spełniał szereg warunków pozwalających uniknąć duplikowania danych, dzięki normalizacji model lepiej odwzorowuje informacje modelowanego przedsiębiorstwa, staje się spójny, zapewnia minimum redundancji i maksimum stabilności.

37 Realizacja transakcji (krok 3) Sprawdź, czy relacje umożliwiają realizacje transakcji Celem tego kroku jest sprawdzenie, czy logiczny model danych umożliwia wykonanie transakcji opisanych w specyfikacji wymagań użytkownika. W kroku tym próbujemy wykonać manualnie poszczególne operacje zawarte w transakcjach, korzystając z relacji, powiązań między kluczami głównymi i obcymi relacji.

38 Więzy integralności Wyznacz więzy integralności Więzy integralności to dodatkowe warunki, których spełnienie zapobiega niespójności bazy danych. Na tym etapie koncentrujemy się na wysokopoziomowym opisie specyfikującym, jakie więzy integralności powinny być spełnione, niezależnie od tego, w jaki sposób zapewniona będzie ich realizacja. Po ustaleniu więzów integralności logiczny model danych można uznać za kompletna reprezentacje rzeczywistości.

39 Więzy integralności Rozważamy pięć typów więzów integralności: wymagana obecność danych niektóre atrybuty nie powinny zawierać wartości pustych; więzy tego typu powinny być ustalone na etapie dokumentowania informacji o atrybutach w słowniku danych. więzy dziedzin atrybutów z każdym atrybutem związana jest dziedzina, czyli zbiór dopuszczalnych wartości; wiązy tego typu należy ustalić wraz z wyborem dziedzin atrybutów. integralność encji klucz główny encji nie może przyjmować wartości pustych; ograniczenie to należy uwzględnić przy wyborze klucza głównego dla danego zbioru encji.

40 Więzy integralności więzy ogólne są nazywane regułami biznesowymi (lub zasadami działania); reguły te wynikają z zasad obowiązujących w opisywanym przez nie fragmencie świata rzeczywistego, np. Promotor może prowadzić 10 prac dyplomowych studentów integralność referencyjna klucz obcy wiąże krotkę relacji podrzędnej z krotką relacji nadrzędnej o pasującej wartości klucza kandydującego; integralność referencyjna oznacza, że jeśli wartość klucza obcego jest określona, to wartość ta musi odpowiadać istniejącej krotce w relacji nadrzędnej.

41 Więzy integralności Integralność referencyjna Przykład: Personel Nr_Pracownika <pk> Zarządza Nieruchomość Nr_Nieruchomosci Nr_Pracownika <pk> <fk> Atrybut Nr_Pracownika w relacji Nieruchomość wiąże nieruchomość do wynajęcia z krotką w relacji Personel zawierającą dane pracownika zarządzającego daną nieruchomością. Jeśli wartość Nr_Pracownika (w relacji Nieruchomość) jest określona, to powinna ona zawierać poprawny numer pracownika, występujący jako wartość Nr_Pracownika w relacji Personel.

42 Więzy integralności Integralność referencyjna Pierwszym problemem jest kwestia, czy dozwolone są wartości puste klucza obcego. W przypadku opcjonalnego uczestnictwa relacji podrzędnej wartości puste są dozwolone, np. dopuszczamy możliwość przechowywania informacji o nieruchomości do wynajęcia bez podania pracownika zarządzającego tą nieruchomością W przypadku obowiązkowego uczestnictwa relacji podrzędnej wartości puste nie są dozwolone, np. nie dopuszczamy możliwości przechowywania informacji o nieruchomości do wynajęcia bez podania pracownika zarządzającego tą nieruchomością

43 Więzy integralności Integralność referencyjna Kolejnym problemem jest sposób zapewnienia integralności referencyjnej. Operacje na bazie danych mogą naruszyć więzy referencyjne. Przypadek 1. Wstawienie krotki do relacji podrzędnej dla zachowania integralności referencyjnej konieczne jest sprawdzenie, czy klucz obcy w relacji podrzędnej ma wartość pusta lub jest równy wartości występującej w jednej z krotek relacji nadrzędnej Przypadek 2. Usunięcie krotki z relacji podrzędnej nie narusza integralności referencyjnej Przypadek 3. Modyfikacja klucza obcego krotki w relacji podrzędnej sytuacja podobna do przypadku 1

44 Więzy integralności Integralność referencyjna Przypadek 4. Wstawienie krotki do relacji nadrzędnej nie narusza integralności referencyjnej Przypadek 5. Usunięcie krotki z relacji nadrzędnej może naruszyć integralność referencyjną w przypadku, gdy w relacji podrzędnej występuje krotka wskazującą na usuniętą krotkę nadrzędną (patrz dalej) Przypadek 6. Modyfikacja klucza głównego krotki nadrzędnej - może naruszyć integralność referencyjną w przypadku, gdy w relacji podrzędnej występuje krotka wskazującą na wartość klucza głównego sprzed modyfikacji (patrz dalej)

45 Więzy integralności Integralność referencyjna W przypadku 5 i 6 można wybrać kilka możliwości: NO ACTION lub RESTRICT - uniemożliwia usunięcie (modyfikację) krotki z relacji nadrzędnej jeśli występują jakiekolwiek krotki od niej zależne. CASCADE usunięcie (modyfikacja) krotki nadrzędnej pociąga za sobą usunięcie (modyfikację) wszystkich związanych z nią krotek podrzędnych; jeśli krotka podrzędna pełni rolę nadrzędną w innym związku, analogiczna operacja usuwania (modyfikacji) powinna być wykonana dla krotek podrzędnych tego związku. SET NULL usunięcie krotki nadrzędnej pociąga za soną automatyczne nadanie wartości pustych odpowiednim kluczom obcym wszystkich krotek SET DEFAULT usunięcie krotki nadrzędnej pociąga za soną automatyczne nadanie wartości domyślnych odpowiednim kluczom obcym wszystkich krotek podrzędnych.

46 Nieruchomość( nieruchomośćnr NumerNieruchomości NOT NULL ulica Ulica NOT NULL miasto Miasto NOT NULL typ TypNieruchomości NOT NULL DEFAULT F pokoje NieruchomośćPokoje NOT NULL DEFAULT 4 czynsz NieruchomośćCzynsz NOT NULL DEFAULT 600 właścicielnr NumerWłaściciela NOT NULL pracowniknr NumerPracownika NOT NULL biuronr NumerBiura NOT NULL kaucja NieruchomośćCzynsz NOT NULL PRIMARY KEY (nieruchomośćnr) ALTERNATE KEY (ulica, miasto) FOREIGN KEY (pracowniknr) REFERENCES Personel(pracownikNr) ON UPDATE CASCADE ON DELETE SET NULL FOREIGN KEY (właścicielnr) REFERENCES WłaścicielPrywatny(właścicielNr) and WłaścicielInstytucjonalny(właścicielNr) ON UPDATE CASCADE ON DELETE NO ACTION DERIVED kaucja (czynsz*0,1)

47 Dziękuję za uwagę!!!

48 Powtórka z modelowania danych Podejście obiektowe i strukturalne

49 Podejście strukturalne czyli encje i związki

50 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ą.

51 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.

52 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.

53 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 ). Związki Związek reprezentuje powiązanie między encjami, wynikające z opisu modelowanego fragmentu rzeczywistości Przykład: Biuro zatrudnia Personel 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: 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 ).

54 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).

55 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).

56 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).

57 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.

58 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)

59 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

60 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

61 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 pojedynvczego 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 pochodzacych z tego samego zbioru encji Przykład: Atrybut okresnajmu może być wyliczony z atrybutów wynajeteod i wynajetedo

62 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.

63 Podejście obiektowe czyli małe przypomnienie

64 Modelowanie obiektowe Modelowanie obiektowe (ang. Object-Oriented Modelling, OOM) jest alternatywną metodologią projektowania i tworzenia systemóww stosunku do podejścia strukturalnego. Modelowanie obiektowe jest bardziej intuicyjnie i ma większą siłę ekspresji od modelowania strukturalnego, gdyż opiera się na pojęciach, które są dobrze zrozumiałe dla człowieka, np. obiekt, klasa, atrybut. Możemy powiedzieć, że człowiek postrzega świat i myśli obiektowo. Obiektowy model systemu posiada dwie podstawowe części: abstrakcja strukturalna - wyrażająca schemat statyczny bazy i innych elementów systemu; abstrakcja zachowania - określająca dynamikę (zachowanie) systemu. Model obiektowy może być płynnie i wygodnie implementowany w obiektowych językach programowania (np. C++, Java, C#, VisualBasic, Delphi), które obecnie dominują na rynku.

65 Modelowanie obiektowe Obecnie powszechnie uznaną i stosowaną notacją modelowania obiektowego jest ujednolicony język modelowania obiektowego (ang. Unified Modelling Language, UML). W standardzie tym można tworzyć szereg diagramów z zakresu abstrakcji strukturalnej i abstrakcji zachowania. Istnieje wiele metodologii modelowania obiektowego, wykorzystujących język UML. Jedną z bardziej znanych jest ogólny proces wytwarzania oprogramowania RUP (Rational Unified Process) firmy Rational. Na rynku dostępnych jest wiele środowisk wspomagających tworzenie rozwiązań programistycznych w oparciu o metodologię obiektową i język UML. Bardziej zaawansowane narzędzia pozwalają nie tylko na tworzenie modeli i diagramów, ale także na ich transformowanie do poziomu implementacyjnego (np. generowanie szablonów klas lub bazy danych).

66 Obiektowe modelowanie bazy Do modelowania baz danych w metodologii obiektowej wykorzystujemy model strukturalny (ang. structural model), inaczej model struktury statycznej. W języku UML do budowy tego modelu służy diagram klas. Diagram klas (ang. class diagram) reprezentuje statyczną strukturę systemu: klasy i obiekty oraz powiązania między nimi, takie, jak: związek asocjacyjny, agregacja, złożenie i uogólnienie (dziedziczenie). Diagram klas jest nadzbiorem diagramu ERD. Ten model pozwala na reprezentację bardziej złożonych związków, które nie są bezpośrednio dostępne ani w diagramie ERD, ani w schemacie relacyjnym. W diagramie tym dopuszcza się także modelowanie zachowania.

67 Obiektowe modelowanie bazy Przed przystąpieniem do implementacji bazy danych, model obiektowy musi być przełożony na postać uwzględniającą konkretny model danych (np. relacyjny) oraz system zarządzania bazą danych (DBMS). Jeżeli przekształcamy obiektowy model danych do schematu relacyjnego, niektóre własności obiektowe (np. uogólnienie dziedziczenie) muszą być przekształcone do postaci powiązań płaskich bez hierarchii. Obiektowy model danych pomaga lepiej odzwierciedlić rzeczywistość od modelu strukturalnego, pomimo konieczności późniejszego osłabienia semantyki modelu podczas jego implementacji.

68 Diagram klas - klasy Podstawowymi pojęciami występującymi w diagramie klas są obiekt i klasa. Obiekt (object) - konkretny lub abstrakcyjny byt (wyróżnialny w modelowanej rzeczywistości) posiadający nazwę, jednoznaczną identyfikację, atrybuty i inne własności, np. metody. Klasa (class) - jest to zbiór obiektów tego samego typu. Nazwa klasy Pracownik Lista atrybutów ID_Pracownika Im ie Nazwisko : int : String : String Typ atrybutu Sekcja metod Dodaj_Pacownika () Usun_Pracowni ka () Edytuj_Pracownika () Ile_pracownikow () : int

69 Diagram klas związki W diagramie klas UML mogą występować następujące związki: asocjacja (ang. association) ) równorzędny związek między klasami (np. Pracownik - Przedmiot ); uogólnienie (ang. generalization) ) związek hierarchiczny, w którym klasa nadrzędna jest bardziej ogólna od klasy podrzędnej (np. Osoba - Student, Osoba - Pracownik ). agregacja (ang. aggregation) ) specjalny rodzaj asocjacji, która wyraża relację całość część ; klasa podrzędna może istnieć bez klasy nadrzędnej (np. Grupa - Student ); kompozycja (ang. composition) ) - specjalny rodzaj asocjacji, która wyraża relację całość część ; klasa podrzędna nie może istnieć bez klasy nadrzędnej (np. Przedmiot - Zajęcia ); zależność (ang. dependency) ) zmiany dokonywane w jednej klasie (element niezależny) powodują zmiany w drugiej klasie (element zależny). realizacja (ang. realization) ) związek między klasą, a jej interfejsem.

70 Diagram klas związki asocjacja uogólnienie agregacja kompozycja

71 Diagram klas związki zależność realizacja asoccjacja n-arna Personel ( w zależności od narzędzia) Rejestruje Klient Biuro

72 Diagram klas związki Związek może mieć : nazwę role (np.: pracownik, pracodawca) kierunek (również dwustronny) liczebność (multiplicity) atrybuty i metody może być związkiem rekurencyjnym

73 Diagram klas związki Liczebność Atrybuty związku Rola Klasa asocjacyjna

74 Diagram klas związki Liczebność i opcjonalność wyrażamy poprzez podanie minimalnej.. maksymalnej liczby obiektów klasy uczestniczącej w związku, np. 1..* - od 1 do wielu obiektów, uczestnictwo wymagane lub 1 obiekt, uczestnictwo opcjonalne lub 4 obiekty * - 0 lub wiele

75 Diagram klas związki Agregacja (ang. aggregation) Związek agregacji jest szczególnym rodzajem asocjacji wyrażającym zależność pomiędzy całością (klasa agregująca), a jej częściami (klasa składowa). Cechą charakterystyczna agregacji jest to, że klasa składowa może istnieć bez klasy agregującej Dwie klasy objęte związkiem agregacji odnoszą się do różnych obiektów. Przykład: Student należy do Grupy (element zbiór). Określony student jest odrębnym obiektem w stosunku do Grupy, do której należy.

76 Diagram klas związki Agregacja Klasa agregująca Symbol agregacji Klasa składowa

77 Diagram klas związki Kompozycja (ang. composition) Związek kompozycji jest podobny do agregacji i zachodzi pomiędzy całością, a jej częściami. W kompozycji całość jest odpowiedzialna za zarządzanie częściami, co oznacza, że kompozycja Cechami charakterystycznymi kompozycji jest to, że klasa składowa nie może istnieć bez klasy agregującej (części żyją i umierają wraz z całością) oraz składowa nie może być współdzielona (obiekt może być częścią dokładnie jednej kompozycji w danym czasie) Przykład: Zajęcia są częścią Przedmiotu. Zajęcia (np. laboratorium z BD ) nie mogą istnieć bez Przedmiotu (w tym przypadku BD ), którego są częścią.

78 Diagram klas związki Kompozycja Klasa agregująca Symbol agregacji Klasa składowa

79 Diagram klas uogólnienie Relacja uogólnienia jest jednym z elementów nie występujących w modelowaniu strukturalnym. Reprezentuje ona informację, ż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 dodatkowych, charakterystycznych tylko dla pracowników. Nadklasa i podklasa odnoszą się do tego samego obiektu.

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

81 Diagram klas 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.

82 Diagram klas uogólnienie Klasa nadrzędna Symbol uogólnienia Klasa podrzędna

83 Diagram klas - metody Aby można było opisać dynamikę systemu, należy uzupełnić diagramy klas w modelu strukturalnym o abstrakcję zachowania: metody. Jeśli diagram klas stanowi model bazy danych, to metody w klasach odpowiadają transakcjom operacjom wykonywanym w bazie, które zmieniają dane tak, aby były on spójne (stan integralności), czyli z zachowaniem więzów integralności. Operacje definiowane przez metody danej klasy zasadniczo dotyczą klasy, do której należą. Mogą one jednak także wywoływać metody innych klas.

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

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

86 Dziekuje za uwagę!!!