Relacyjny model baz danych, model związków encji, normalizacje

Transkrypt

1 Relacyjny model baz danych, model związków encji, normalizacje Wyklad 3 mgr inż. Maciej Lasota mgr inż. Karol Wieczorek Politechnika Świętokrzyska Katedra Informatyki Kielce, 2009

2 Definicje Operacje na relacjach Relacja definicja Relacyjny model baz danych pojawił się po raz pierwszy w artykule naukowym Edgara Codda w 1970 roku. W terminologii matematycznej baza danych jest zbiorem relacji. Stąd historyczne pochodzenie nazwy relacyjny model danych i relacyjna baza danych. W matematyce relację definiuje się jako podzbiór iloczynu kartezjańskiego zbiorów wartości. Reprezentacją relacji jest dwuwymiarowa tabela złożona z kolumn i wierszy.

3 Definicje Operacje na relacjach Relacja W relacji cechy rzeczywistości opisywane są w atrybutach: Schemat relacji to zbiór nazw atrybutów: S = {A 1,..., A n } Wartość atrybutów należy do dziedziny: {D 1,..., D n } Relacja na schemacie S to podzbiór iloczynu kartezjańskiego dziedzin atrybutów (zbiorów wartości): R D 1 x,..., xd n Relacja R jest zbiorem krotek, zbiór krotek może być reprezentowany jako tabela (kolumny odpowiadają atrybutom, wiersze odpowiadają krotkom): R { k 1,..., k n }

7 Definicje Operacje na relacjach Klucz relacji Klucz relacji K jest zbiorem atrybutów (jeden lub wiele), które jednoznacznie wyznaczają krotkę (wiersz). Klucze możemy podzielić: klucze właściwe (żaden podzbiór właściwy klucza właściwego nie jest kluczem), klucze główne (jeden klucz właściwy relacji, wybrany do identyfikacji krotki).

8 Definicje Operacje na relacjach Operacje na relacjach 1 Selekcja wybór krotek (wierszy): Σ w (R) ={K R:w(k)} w - warunek selekcji 2 Projekcja (rzut) wybór atrybutów (kolumn): Π w (S ) ={k(s ) : k R} S - podzbiór schematu S 3 Złączenie operacje na dwóch relacjach 4 Operacje teoriomnogościowe (suma, iloczyn, różnica)

12 wstęp Jak zacząć? Etapy projektowania Model związków encji Podczas projektowania bazy danych bardzo ważnym elementem jest zrozumienie celu, oraz tego, co próbujemy osiągnąć poprzez stworzenie bazy danych. Każda nowo projektowana baz danych powinna posiadać następujące kluczowe cechy i właściwości: Zdolność przechowywania potrzebnych danych Zdolność obsługi wymaganych związków (relacji) Zdolność rozwiązywania problemu Zdolność do narzucania integralności danych Zdolność narzucania wydajności w przetwarzaniu danych Zdolność uwzględniania przyszłych zmian

18 Etapy projektowania Relacja Jak zacząć? Etapy projektowania Model związków encji 1 Pierwszym etapem w projektowaniu bazy danych jest zebranie informacji o tym, do czego ma nam ona służyć. Na pierwszym miejscu należy określić cel projektowania bazy danych. Ważne jest znać cel przed rozpoczęciem zbierania bardziej szczegółowych informacji. 2 Drugim etapem jest określenie obiektów, czyli zdefiniowanie kluczowych obiektów, które powinny się znaleźć w bazie danych. np. projektując bazę sklepu kluczowymi obiektami są klienci, zamówienia, produkty itd. Każdy stworzony obiekt posiada określone cechy np. klient posiada imię, nazwisko, adres itd.

19 Etapy projektowania Relacja Jak zacząć? Etapy projektowania Model związków encji 1 Pierwszym etapem w projektowaniu bazy danych jest zebranie informacji o tym, do czego ma nam ona służyć. Na pierwszym miejscu należy określić cel projektowania bazy danych. Ważne jest znać cel przed rozpoczęciem zbierania bardziej szczegółowych informacji. 2 Drugim etapem jest określenie obiektów, czyli zdefiniowanie kluczowych obiektów, które powinny się znaleźć w bazie danych. np. projektując bazę sklepu kluczowymi obiektami są klienci, zamówienia, produkty itd. Każdy stworzony obiekt posiada określone cechy np. klient posiada imię, nazwisko, adres itd.

20 Etapy projektowania c.d. Jak zacząć? Etapy projektowania Model związków encji 3 Trzeci etap, gdy każdemu obiektowi bazy danych przypiszemy określone cechy możemy dane obiekty przekształcić w tabele (w przypadku modelu relacyjnego). Na tym etapie obiekty nazywane są tabelami natomiast cechy określają kolumny w tabelach. Każda kolumna posiada określoną nazwę np. tabela klienci może posiadać kolumny imię, nazwisko, adres itd. 4 Czwarty etap, najtrudniejszy polega na określeniu relacji między tabelami oraz krotności. Należy rozbić te kolumny, które mogą występować po kilka razy dla każdej tabeli. Dodatkowo należy zdecydować w jaki sposób poszczególne tabele wiążą się ze sobą

21 Etapy projektowania c.d. Jak zacząć? Etapy projektowania Model związków encji 3 Trzeci etap, gdy każdemu obiektowi bazy danych przypiszemy określone cechy możemy dane obiekty przekształcić w tabele (w przypadku modelu relacyjnego). Na tym etapie obiekty nazywane są tabelami natomiast cechy określają kolumny w tabelach. Każda kolumna posiada określoną nazwę np. tabela klienci może posiadać kolumny imię, nazwisko, adres itd. 4 Czwarty etap, najtrudniejszy polega na określeniu relacji między tabelami oraz krotności. Należy rozbić te kolumny, które mogą występować po kilka razy dla każdej tabeli. Dodatkowo należy zdecydować w jaki sposób poszczególne tabele wiążą się ze sobą

22 Etapy projektowania c.d. Jak zacząć? Etapy projektowania Model związków encji 5 Ostatni etap, każdej tabeli przypisujemy klucze główne. Wyodrębniamy klucze kandydatów - potencjalne dane, które mogą się przyczynić do jednoznacznej identyfikacji każdego wiersza. Następnie wybieramy jeden z nich na klucz główny całej tabeli. W przypadku gdy nie można jednoznacznie określić żadnego klucza głównego lub uważamy, że klucze - kandydaci nie nadają się do tego możemy stworzyć tzw. logiczny klucz główny. Logiczny klucz główny to dodatkowa kolumna w tabeli jednoznacznie identyfikująca każdy wiersz tabeli.

23 Model związków encji Jak zacząć? Etapy projektowania Model związków encji Najbardziej powszechnym modelem abstrakcyjnie przedstawiającym strukturę bazy danych jest model związków encji (model E/R). W modelu E/R struktura danych jest reprezentowana graficznie jako diagram związków encji, w którym korzysta się z trzech typów elementów: encje atrybuty związki

24 Zbiory encji Relacja Jak zacząć? Etapy projektowania Model związków encji Encje są pewnego rodzaju obiektami abstrakcyjnymi, a kolekcja podobnych encji tworzy zbiór encji. Encje określają coś co istnieje, co jest odróżnialne od innych, o czym informację trzeba znać lub przechowywać. Reprezentacją graficzną zbioru encji jest prostokąt:

25 Atrybuty Relacja Jak zacząć? Etapy projektowania Model związków encji Atrybuty są to właściwości encji danego typu, reprezentują pewną wartość np. liczbę całkowitą, rzeczywistą lub napis. Opisują encje i dla każdego egzemplarza encji powinny przyjmować pojedynczą atomową wartość. Reprezentacją graficzną atrybutu jest elipsa:

26 Związki Relacja Jak zacząć? Etapy projektowania Model związków encji Związki są połączeniami między dwoma lub większą liczbą zbiorów encji. Wyróżniamy związki binarne (najczęściej stosowane) oraz związki wieloargumentowe. Reprezentacją graficzną związku jest romb:

27 Diagramy związków encji Jak zacząć? Etapy projektowania Model związków encji Diagramy związków encji są grafami reprezentującymi zbiory encji, atrybuty i związki. Elementy tych różnych typów są reprezentowane jako wierzchołki grafów.

28 Relacja Jak zacząć? Etapy projektowania Model związków encji Nr Imie Nazwisko Adres 10 Karol Wieczorek Jan Serce Hans Kloss Clark Kent Bruce Wayne 104 Nr Miasto Kod pocztowy Ulica Nr m 100 Kielce Padarewskiego Kraków Smocza Warszawa Woronicza Kielce Warszawska Morawica Kielecka 34

29 Diagram związków encji Jak zacząć? Etapy projektowania Model związków encji

30 Normalizacja definicja Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Normalizacja to proces organizacji danych w bazie danych. Polega on na tworzeniu tabel i ustanawianiu pomiędzy nimi powiązań według reguł obowiązujących zarówno przy ochronie danych, jak i uelastycznianiu bazy danych przez eliminowanie powtarzających się i niespójnych zależności. Normalizując bazę danych usuwamy z niej nadmiarowość tzw. redundancję. Nadmiarowość w bazie danych bywa szkodliwa. Jej istnienie powoduje niepotrzebny wzrost objętości bazy danych, oraz prowadzi do problemów z utrzymaniem spójności danych czyli tzw. anomalii.

31 Schemat normalizacji Relacja Wprowadzenie Omówienie PN Dodatkowe PN Wnioski

32 1PN definicja Relacja Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Pierwsza postać normalna dotyczy powtarzających się grup danych, jeżeli zależności funkcyjne pomiędzy danymi wskazują na związki jeden do wielu, wskazuje to na istnienie grup danych. Definicja pierwszej postaci normalnej Relacja jest w pierwszej postaci normalnej wtedy i tylko wtedy gdy każdy atrybut niekluczowy jest funkcyjnie zależny od klucza głównego Pierwsza postać normalna wymaga, aby żaden atrybut(kolumna) w tabeli nie był podzielny dalej, a także, aby nie było powtarzających się grup.

33 2PN definicja Relacja Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Druga postać normalna dotyczy zależności funkcyjnych od części klucza złożonego, normalizacja do drugiej postaci ma na celu wykluczenie takich zależności. Definicja drugiej postaci normalnej Relacja jest w drugiej postaci normalnej wtedy i tylko wtedy, gdy jest w pierwszej postaci normalnej i każdy atrybut niekluczowy, czyli nie należący do zadanego klucza, jest w pełni funkcyjnie zależny od klucza głównego. Druga postać normalna mówi, że żadna informacja w wierszu nie może zależeć tylko od części klucza podstawowego (głównego).

34 3PN definicja Relacja Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Trzecia postać normalna ma na celu wykluczenie zależności przechodnich pomiędzy danymi poprzez określenie danych determinujących spośród niekluczowych atrybutów relacji. Definicja trzecia postaci normalnej Relacja jest w trzeciej postaci normalnej wtedy i tylko wtedy, gdy jest w drugiej postaci normalnej i każdy niekluczowy atrybut jest bezpośrednio, a nie przechodnio, zależny od klucza głównego. Trzecia postać mówi, że żadna informacja w kolumnie, która nie jest kluczem podstawowym, nie może zależeć od niczego innego, jak tylko od klucza podstawowego.

35 normalizacji 1 Wprowadzenie Omówienie PN Dodatkowe PN Wnioski W poniższych krokach przedstawiono proces normalizacji fikcyjnej tabeli student. Mamy tabelę student w postaci nieznormalizowanej: 1 Autorprzykadu : PiotrGawrysiak pgawrysiak@supermedia.pl PolitechnikaWarszawska

36 normalizacji c.d. Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Pierwsza postać normalna cechy: Brak powtarzających się grup Tabele powinny mieć tylko dwa wymiary Ponieważ jeden student ma kilka klas, klasy powinny znajdować się w oddzielnej tabeli Występowanie pól Klasa 1, Klasa 2 i Klasa 3 w powyższych rekordach jest oznaką problemów podczas projektowania

37 normalizacji 1PN Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Pierwsza postać normalna 1PN:

38 normalizacji 2PN Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Druga postać normalna cechy: Eliminowanie powtarzających się danych W powyższej tabeli dla każdego pola Nr Studenta istnieje wiele wartości w polach Nr Klasy Pole Nr Klasy nie jest zależne od pola Nr Studenta (klucz podstawowy), dlatego ta relacja nie znajduje się w drugiej postaci normalnej

39 normalizacji 2PN Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Drugą postać normalną przedstawiono na następujących dwóch tabelach: studenci i rejestracja

40 normalizacji 3PN Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Trzecia postać normalna cechy: Eliminowanie danych, które nie zależą od klucza W ostatnim przykładzie pole Pokój (numer pokoju opiekuna) jest zależne od atrybutu Opiekun Rozwiązaniem jest przeniesienie tego atrybutu z tabeli Studenci do tabeli Wydział

41 normalizacji 3PN Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Trzecia postać normalna 3PN:

42 Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Postać normalna Beyoce a - Codda Definicja postaci normalnej Boyce a-codda stanowi właściwie sumę pierwszej, drugiej i trzeciej postaci normalnej. Posługując się wyłącznie tą definicją można stwierdzić, czy relacja spełnia warunki relacyjnego modelu danych. PN B-C Relacja jest w postaci normalnej Boyce a-codda wtedy i tylko wtedy, kiedy każdy jej atrybut zależy funkcjonalnie tylko od jej klucza głównego.

43 4 i 5 PN definicje Relacja Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Czwarta postać normalna służy do eliminacji relacji między tabelami typu (jeden do wielu) zachodzących między niezależnymi kolumnami. Piąta postać normalna polega na podziale tabeli źródłowej na maksymalną ilość tabel w celu uniknięcia redundancji (nadmiarowości).

44 Wnioski Relacja Wprowadzenie Omówienie PN Dodatkowe PN Wnioski Bardzo często bazy danych są normalizowane do 3PN lub BCPN. Dalsza normalizacja zazwyczaj nie jest nieopłacalna ze względu na duży spadek wydajności tak znormalizowanych baz danych (głównie chodzi o czas realizacji zapytań w przypadku dużych zbiorów danych). Znormalizowanie bazy do postaci 5PN powoduje, że zwiększa się ilość prostych zapytań do bazy danych w ramach uzyskania danych z wielu tabel, co znacznie wpływa no obniżenie prędkości wykonania zapytań.

45 Pytania?

46 Koniec Dziękuję za uwagę