Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)

Transkrypt

1 Bazy danych 1 Wykład 5 Metodologia projektowania baz danych (projektowanie logiczne)

2 Projektowanie logiczne przegląd krok po kroku 1. Usuń własności niekompatybilne z modelem relacyjnym 2. Wyznacz relacje dla logicznego modelu danych 3. Wykonaj normalizację relacji 4. Sprawdź, czy relacje umoŝliwiają realizacje transakcji. 5. Wyznacz więzy integralności. 6. Omów logiczny model danych z uŝytkownikiem.

3 Projektowanie logiczne (krok 1) 1. Usuń własności niekompatybilne z modelem relacyjnym Związki złoŝone Atrybuty wielowartościowe

4 Usunięcie związków złoŝonych Personel Rejestruje Klient 0..* Biuro Przetwarza Personel Rejestracja Rejestruje Biuro * 0..* Potwierdza 1..1 Klient

5 Usunięcie atrybutów wielowartościowych Biuro NrBiura Adres NrTel [1..3] Biuro NrBiura Adres Udostępnia Telefon NrTel

6 Projektowanie logiczne (krok 2) 2. Wyznacz relacje dla logicznego modelu danych Relacje będziemy opisywać za pomocą języka definiowania bazy danych DDL (DataBase Definition Language) Definicja (uproszczona) relacji w DDL 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.

7 Projektowanie logiczne (krok 2) Przykład definicji relacji w DDL Relacja_A AtrybutA1 Relacja_A (, AtrybutA1) Primary Key Relacja_B Klucz_B AtrybutB1 <fk> Relacja_B (Klucz_B,, AtrybutB1) Primary Key Klucz_B Foreign Key references Relacja_A()

8 Projektowanie logiczne (krok 2) 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.

9 Reguły transformacji związki typu 1:1 Uczestnictwo obowiązkowe po obu stronach związku A B - Klucz_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_B

10 Reguły transformacji związki typu 1:1 Uczestnictwo obowiązkowe po jednej stronie związku 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_B <fk>

11 Reguły transformacji związki typu 1:1 Uczestnictwo opcjonalne po obu stronach związku 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_B RAB <pk,fk1> <pk,fk2> RB Klucz_B

12 Reguły transformacji związki typu 1:1 z atrybutami Przypadek gdy związek ma atrybuty 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_B RAB Klucz_B Atrybut_Zwiazku <pk,fk1> <pk,fk2>

13 Reguły transformacji związki rekurencyjne typu 1:1 Uczestnictwo obowiązkowe po obu stronach związku 1..1 Rola2 A 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 Rola1_ <fk1>

14 Reguły transformacji związki rekurencyjne typu 1:1 Uczestnictwo opcjonalne po jednej stronie związku 1..1 Rola2 A 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 Rola1_ Rola2_ <pk,fk1> <pk,fk2>

15 Reguły transformacji związki rekurencyjne typu 1:1 Uczestnictwo opcjonalne po obu stronach związku 0..1 Rola2 A 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 Rola1_ Rola2_ <pk,fk1> <pk,fk2>

16 Reguły transformacji związki rekurencyjne typu 1:1 z atrybutami Przypadek gdy związek ma atrybuty 1..1 Rola2 A Rola1 Zwiazek - 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 Rola1_ Rola2_ Atrybut_Zwiazku <pk,fk1> <pk,fk2>

17 Reguły transformacji związki typu 1:* Uczestnictwo obowiązkowe po stronie wiele związku 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_B <fk>

18 Reguły transformacji związki typu 1:* Uczestnictwo opcjonalne po stronie wiele związku 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_B RAB <pk,fk1> <pk,fk2> RB Klucz_B

19 Reguły transformacji związki typu 1:* z atrybutami Uczestnictwo obowiązkowe po stronie wiele związku 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 RB Klucz_B Atrybut_Zwiazku <fk>

20 Reguły transformacji związki typu 1:* z atrybutami Uczestnictwo opcjonalne po stronie wiele związku 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 RB Klucz_B RAB Klucz_B Atrybut_Zwiazku <pk,fk1> <pk,fk2>

21 Reguły transformacji związki typu *:* (bez i z atrybutami) Uczestnictwo opcjonalne po obu stronach A - 0..* 0..* Zwiazek - Atrybut_Zwiazku 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). B - Klucz_B RA RB Klucz_B RAB Klucz_B Atrybut_Zwiazku <pk,fk1> <pk,fk2>

22 Reguły transformacji związki rekurencyjne typu *:* (bez i z atrybutami) Uczestnictwo opcjonalne po obu stronach 0..* Rola2 A - 0..* Rola1 Zwiazek - Atrybut_Zwiazku 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 Rola1_ Rola2_ Atrybut_Zwiazku <pk,fk1> <pk,fk2>

23 Metoda 1: Przekształcenie uogólnienia w schemat relacyjny 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]).

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

25 Przekształcanie hierarchii Metoda 2: uogólnienia w schemat relacyjny 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ą.

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

27 Metoda 3: Przekształcanie hierarchii uogólnienia w schemat relacyjny 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.

28 Przekształcanie uogólnienia w schemat relacyjny metoda 3 Osoba Id_Osoby Imie Nazwisko NIP PESEL itd. integer varchar varchar varchar varchar <Undefined> Id_Osoby Nr_Pracownika Nr_Indeksu Data_Zapisania Data_Wypisania Tytul Stanowisko Data_Zatrudnienia Okres_Zatrudnienia itd. Pracownik_Student int int int date date varchar varchar date int <Undefined> <fk>

29 Metoda 4: Przekształcanie hierarchii uogólnienia w schemat relacyjny 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).

30 Przekształcanie uogólnienia w schemat relacyjny metoda 4 Diagram klas Schemat relacji Dodatkowe pole rozróŝniające

31 Dziękuj kuję za uwagę!!!