3. Modelowanie baz danych (cd)

Prezentacja na temat: "3. Modelowanie baz danych (cd)"— Zapis prezentacji:

1 3. Modelowanie baz danych (cd)
Bazy danych 3. Modelowanie baz danych (cd) P. F. Góra semestr letni 2004/05

2 Diagramy związków encji (E/R)
tytuł rok nazwisko adres Gwiazdy-w Filmy Gwiazdy Posiada długość TypTaśmy nazwa Studia adres Bazy danych - wykład 3

3 Diagramy E/R dopuszczają związki wieloargumentowe
Kontrakty Filmy Gwiazdy Studia Bazy danych - wykład 3

4 W diagramach E/R związki mogą mieć swoje atrybuty
Wynagrodzenie tytuł rok nazwisko adres Kontrakty Filmy Gwiazdy długość TypTaśmy Studia nazwa adres Bazy danych - wykład 3

5 Czteroargumentowy związek z atrybutami
Wynagrodzenie tytuł rok nazwisko adres Kontrakty Filmy Gwiazdy długość TypTaśmy Studia Studio producenta Studio gwiazdy nazwa adres Bazy danych - wykład 3

6 Atrybuty związków zastępujemy dodatkowymi zbiorami encji
Wynagrodzenie Gaże tytuł rok nazwisko adres Kombinacja Filmu i Gwiazdy wyznacza jednoznaczną Gażę Kontrakty Filmy Gwiazdy długość TypTaśmy Gwiazda wyznacza jednoznaczne Studio gwiazdy Film wyznacza jednoznaczne Studio producenta Studia nazwa adres Bazy danych - wykład 3

7 Związki wieloargumentowe można zastąpić dodatkowymi zbiorami encji i związkami dwuargumentowymi
Zbiór encji Kontrakty nie ma atrybutów, ma same związki Gwiazdy Filmy Film-w Gwiazda-czego Jaka-gaża Kontrakty Studio-prod. Studio-gwiazdy Studia Gaże Może zbiór encji Gaże wcale nie jest potrzebny? Wynagrodzenie Bazy danych - wykład 3

8 Gwiazdy Filmy Kontrakty Studia
Zbiór encji Kontrakty ma jeden atrybut i wchodzi w cztery związki dwuargumentowe Gwiazdy Filmy Film-w Gwiazda-czego Kontrakty Wynagrodzenie Studio-gwiazdy Studio-prod. Studia Zbiór encji powstały z rozbicia związku wieloargumentowego na relacje binarne nazywa się zbiorem łączącym. Bazy danych - wykład 3

9 Podklasy i dziedziczenie
Jeśli mam zdefiniowaną klasę, mogę zdefiniować podklasę, która dziedziczy wszystkie atrybuty i związki nadklasy, ale może mieć swoje własne atrybuty i wchodzić w związki, w które nadklasa nie wchodzi. Bazy danych - wykład 3

10 Obiekt klasy Kreskówka ma określony atrybut tytuł.
Zdefiniowanie podklasy Kreskówka zmusza nas do zmiany definicji klasy Gwiazda! interface Filmy { attribute string tytuł; attribute integer rok; attribute integer długość; attribute enum Taśma {kolor, czarno-biała} TypTaśmy; relationship Set<Gwiazda> gwiazdy inverse Gwiazda::występujeW; relationship Studio należyDo inverse Studio::posiada; }; interface Kreskówka: Filmy { relationship Set<Gwiazdy> głosy inverse Gwiazdy::podkłada; }; Obiekt klasy Kreskówka ma określony atrybut tytuł. Obiekt klasy Filmy nie wchodzi w związek głosy. Bazy danych - wykład 3

11 Dziedziczenie wielokrotne
interface Kryminał: Filmy { attribute string broń; }; Kto wrobił Królika Rogera interface Kreskówka-Kryminał: Kreskówka, Kryminał {}; Podklasa Kreskówka-Kryminał nie wprowadza żadnych nowych atrybutów bądź związków, ale obiekt tej klasy ma wszystkie atrybuty klasy Filmy, wchodzi we wszystkie związki zdefiniowane w tej klasie, a ponadto ma atrybut broń oraz wchodzi w związek głosy. Chociaż mogłaby… Bazy danych - wykład 3

12 Problemy z dziedziczeniem wielokrotnym
interface Romans: Filmy { attribute enum JakiKoniec {szczęśliwy, smutny} koniec; }; interface Sąd: Filmy { attribute enum JakiWyrok {winny, niewinny} koniec; interface Romans-Sąd: Romans, Sąd {}; Ze zbioru jakich wartości pochodzi atrybut koniec obiektu klasy Romans-Sąd? Składnia języka ODL tego nie rozstrzyga, zostawiając to do (ewentualnej) implementacji. Bazy danych - wykład 3

13 Problemów z dziedziczeniem wielokrotnym można uniknąć…
interface Romans: Filmy { attribute enum JakiKoniec {szczęśliwy, smutny} Romans_koniec; }; interface Sąd: Filmy { attribute enum JakiWyrok {winny, niewinny} Sąd_koniec; interface Romans-Sąd: Romans, Sąd {}; …jeśli stosuje się przemyślaną konwencję nadawania nazw atrybutom. W dużych projektach jest to nieodzowne. Bazy danych - wykład 3

14 Podklasy w związkach encji
atr1 „B is a A” isa atr2 B B jest podklasą A, może mieć swoje atrybuty (i związki) Bazy danych - wykład 3

15 Więzy Klucze Więzy jednoznaczności Więzy integralności referencyjnej
Więzy domenowe (zakresu) Więzy ogólne Bazy danych - wykład 3

16 A jeśli występują i są różne, to znaczy, że klucz został źle dobrany.
Klucze Klucz — atrybut lub zbiór atrybutów, który jednoznacznie definiuje obiekt wewnątrz klasy lub encję wewnątrz zbioru encji. W danej klasie nie występują dwa obiekty, które miałyby identyczne wartości atrybutów tworzących klucz. A jeśli występują i są różne, to znaczy, że klucz został źle dobrany. Uwaga: abstrakcyjny obiekt w pamięci komputera nie musi mieć klucza, bo jest jednoznacznie identyfikowany przez adres przydzielonego mu obszaru pamięci. Bazy danych - wykład 3

17 Gdybyśmy próbowali utworzyć w jednej klasie dwa różne obiekty o takich samych kluczach, DBMS powinien to uniemożliwić. Bazy danych - wykład 3

18 Właściwy dobór kluczy jest trudny, bo muszą one dobrze odpowiadać rzeczywistości
Osoba: Imię, Drugie Imię i Nazwisko? Nie wystarczy. Osoba: Imię, Drugie Imię, Nazwisko i Data Urodzenia? W bazie reprezentującej odpowiedno duży zbiór ludzi nie wystarczy. Osoba: Imię i Nazwisko? Nie wystarczy. Ściśle rzecz biorąc, PESEL nie służy tylko jako indeks, ale to jest zupełnie inna historia… Czasami wprowadza się nowe pole tylko po to, aby mogło służyć jako indeks Studenci: Numer Indeksu „Rządowa” baza danych: PESEL Bazy danych - wykład 3

19 Inny przykład — faktury
Firma ma bazę gromadzącą dane o wystawianych fakturach. Co będzie kluczem? Numer Faktury. Jeśli numeracja zaczyna się od początku w każdym roku, Numer Faktury i Rok. Jeśli poszczególne działy stosują własną numerację faktur, Numer Faktury i Nazwa Działu lub Numer Faktury, Nazwa Działu i Rok. Jak widać, właściwy dobór klucza zależy od rzeczywistości, którą chcemy przedstawić w bazie danych. Bazy danych - wykład 3

20 Wówczas zbiór atrybutów {PESEL, Nazwisko} także jest kluczem!
Ważna uwaga: Przypuśćmy, że mamy „rządową” bazę danych osobowych, w której kluczem jest atrybut PESEL. Wówczas zbiór atrybutów {PESEL, Nazwisko} także jest kluczem! Bazy danych - wykład 3

21 W rzeczywistości trzebaby to sprawdzić…
Podobnie, jeśli tworzymy bazę danych szkół podstawowych, zbiór atrybutów {Ulica, NrDomu, NrSzkoły} będzie kluczem. Załóżmy, że tak jest. Jeśli rozszerzymy ten zbiór do {Miasto, Ulica, NrDomu, NrSzkoły}, także otrzymamy klucz. Podobnie będzie jeśli dodamy informację o województwie. W rzeczywistości trzebaby to sprawdzić… Bazy danych - wykład 3

22 Klucze minimalne. Nadklucze.
W poprzednim przykładzie może się zdarzyć, że w dwu różnych miastach będą istnieć ulice Kościuszki i w dodatku na każdej z tych ulic pod numerem 1 będzie mieścić się szkoła podstawowa. Podobnie w dwu miastach na ulicy Dąbrowskiego (ale w budynkach o różnych numerach!) mogą się mieścić szkoły podstawowe o numerze 16. Wreszcie może się zdarzyć, że szkoły o numerze 53 (w różnych miastach) będą się mieścić w budynku o numerze 8 (przy ulicach o róznych nazwach). Zbiór {Ulica, NrDomu, NrSzkoły} nazywamy w tej sytuacji kluczem minimalnym. Jego nadzbiór nazywamy nadkluczem. Bazy danych - wykład 3

23 Reprezentowanie kluczy w ODL
interface Gwiazda (key nazwisko) { attribute string nazwisko; … }; Atrybut nazwisko jest kluczem interface Filmy (key (tytuł, rok)) { attribute string tytuł; attribute integer rok; … }; Zbiór atrybutów {tytuł, rok} jest kluczem Bazy danych - wykład 3

24 Klucz złożony z dwu atrybutów
Uwaga interface Podatnik: Osoba (key (PESEL, NIP)) { attribute integer PESEL; attribute string NIP; … }; Klucz złożony z dwu atrybutów interface Podatnik: Osoba (key PESEL, NIP) { attribute integer PESEL; attribute string NIP; … }; Dwa klucze! Bazy danych - wykład 3

25 Reprezentowanie kluczy w diagramach E/R
Nazwy atrybutów, których zbiór tworzy klucz, są podkreślone. tytuł rok Filmy długość TypTaśmy W diagramach E/R nie ma możliwości reprezentowania więcej niż jednego klucza. Bazy danych - wykład 3

26 Więzy jednoznaczności
Istnieje co najwyżej jeden obiekt z klasy B, który wchodzi w relację R z pewnym obiektem klasy A. Ten obiekt z klasy B nie musi istnieć, może być obiektem pustym. Innymi słowy, nie wszystkie obiekty z A muszą wchodzić w związek R. R A B Bazy danych - wykład 3

27 Więzy integralności referencyjnej
Na przykład każda informacja o dostawie towarów do magazynu musi być powiązana z dostawcą Istnieje dokładnie jeden obiekt z klasy B, który wchodzi w relację R z pewnym obiektem klasy A. Ten obiekt z klasy B musi istnieć, nie może być obiektem pustym. Innymi słowy, wszystkie obiekty z A muszą wchodzić w związek R z obiektami B. R A B W książce oznaczają to przez półokrąg. Bazy danych - wykład 3

28 Więzy integralności referencyjnej wymuszają istnienie wskazywanego obiektu. Jeślibyśmy więc zażądali usunięcia obiektu związanego więzami integralności referencyjnej, DBMS Uniemożliwi usunięcie takiego obiektu lub Usunie także wszystkie obiekty, które na obiekt usuwany wskazują. Jeśli one też są związane więzami integralności referencyjnej, usunięte zostaną obiekty, które na nie wskazują. I tak dalej.  Usuwanie kaskadowe. Bardzo niebezpieczne — nie każdego stać na zatrudnienie stu osób do wklepywania utraconych danych. Bazy danych - wykład 3

29 Nie więcej niż 10 gwiazd w jednym filmie
Inne rodzaje więzów 1. Więzy domenowe (zakresu) — atrybut może przyjąć wartości tylko z pewnego zakresu. 2. Więzy ogólne — na przykład ograniczenie stopnia związku, to jest ilości „partnerów” w relacji. Gwiazdy-w 10 Filmy Gwiazdy Nie więcej niż 10 gwiazd w jednym filmie Bazy danych - wykład 3

30 Zbiory słabych encji Jeśli niektóre (lub wszystkie) elementy klucza pewnego zbioru encji wybiera się spośród atrybutów innego zbioru encji, zbiór o tak utworzonym kluczu nazywa się zbiorem słabych encji. Typowo Przy strukturze hierarchicznej nazwa (czy inny atrybut) obiektu może identyfikować go w podhierarchii, ale nie w całej hierarchii. Na przykład Numer Szkoły identyfikuje szkołę w mieście, ale nie w województwie. Zbiór encji szkoły będzie musiał brać część swojego klucza z innego zbioru encji (miasta), więc będzie to słaba encja. Zbiór łączący, powstały w celu wyeliminowania relacji wieloargumentowych, prawie zawsze będzie słaby. Bazy danych - wykład 3

31 Reprezentacja graficzna zbiorów słabych encji
Klucz zbioru Szkoły numer nazwa … Liczne inne atrybuty Miasta Szkoły Miasto Zbiór słabych encji i związki łączące go z „dostarczycielami” (części) klucza oznaczam podwójną linią. Leży w mieście Bazy danych - wykład 3

32 Zasady projektowania Dokładność — projekt powinien odpowiadać specyfikacji, klasy lub zbiory encji powinny odzwierciedlać świat rzeczywisty. Unikanie redundancji — bo zajmuje się zbyt wiele miejsca i ryzykuje się, że nie wszystkie wystąpienia danej informacji będą uaktualnione. Prostota — tylko tyle elementów, ile naprawdę potrzeba. Dobór właściwych elementów — nie wszystko modelujemy jako atrybuty! Bazy danych - wykład 3

33 Caveat emptor! Bazy danych są cenne i trzeba je chronić.
Bazy danych wymagają konserwacji i administracji. DBMS jest potencjalnym kanałem, przez który cracker może włamać się do systemu. Bazy danych wymagają regularnego sporządzania kopii zapasowych (backup). Bazy danych - wykład 3