Bazy danych. Andrzej Bobyk

Transkrypt

1 Bazy danych Andrzej Bobyk

2 Literatura P. Beynon-Davies: Systemy baz danych. WNT, Warszawa 2003 C. J. Date: Wprowadzenie do systemów baz danych. WNT, Warszawa 2000 J. D. Ullman, J. Widom: Podstawowy wykład z systemów baz danych. WNT, Warszawa 2000 T. M. Connolly, C. E. Begg: Systemy baz danych. Praktyczne metody projektowania, implementacji i zarządzania. RM, Warszawa 2004

3 Literatura (c.d.) C. J. Date, H. Darwen: SQL. Omówienie standardu języka. WNT, Warszawa 2000 J. S. Bowman, S. L. Emerson, M. Darnowsky: Podręcznik języka SQL. WNT, Warszawa 2001 H. Ladanyi: SQL. Księga eksperta. Helion, Gliwice 2000 A. Jakubowski: Podstawy SQL. Ćwiczenia praktyczne. Helion, Gliwice 2001 R. Wrembel, J. Jezierski, M. Zakrzewicz: System zarządzania bazą danych Oracle 7 i Oracle 8. Nakom, Poznań 1999

4 Czym są bazy danych (BD)? Magazyn danych z nałożoną na niego pewną strukturą Model pewnego aspektu rzeczywistości organizacji (tzw. obszaru analizy OA) Zbiór powiązanych ze sobą danych, którego zadaniem jest reprezentowanie OA (część ekstensjonalna) Definicje struktur danych służących do organizowania i przechowywania danych (część intensjonalna schemat BD)

5 Piramida wiedzy

6 Kontekst bazy danych Związki z rzeczywistością Użytkownicy Baza danych Źródło danych

7 Historia zarządzania danymi 4000 p.n.e 1900 n.e - ręczne zarządzanie zapisami pierwszy znany zapis obejmujqcy majątek królewski i podatki w Sumatrze zarządzanie zapisami na kartach perforowanych Maszyna Holleritha (bazująca na wynalazku Jacquarda z 1801 roku)

8 Historia zarządzania danymi programowane zarządzanie zapisami 1950 rok wynalezienie taśmy magnetycznej (na jednej mieściły się dane z ok kart perforowanych) praca wsadowa na plikach i rekordach (nie daje możliwości wychwycenia błędów aż do zakończenia wsadu)

9 Historia zarządzania danymi sieciowe zarządzanie danymi on-line praca on-line, przetwarzanie bieżących transakcji pliki indeksowane zastosowanie bębnów i dysków magnetycznych trzypoziomowa architektura bazy danych

10 Historia zarządzania danymi relacyjne zarządzanie danymi model Codd a powszechne SZBD na komputery PC najczęściej stosowany model architektura klient-serwer Obiektowe bazy danych dane aktywne oparte o mechanizmy dziedziczenia często przechowują dane różnych typów np.: głos, obraz, dane GIS itp.

11 Rozwój systemu informacyjnego Informatyzacja zwyczajowo odbywała się po kawałku (każdy dział oddzielnie) Informatyzacja po kawałku najczęściej prowadzi do powstania wielu oddzielnych systemów z własnymi plikami, danymi i programami

12 Rozwój systemu informacyjnego Izolowane systemy nie reprezentują sposobu, w jaki działa organizacja. Wymiana danych między systemami odbywa się poza nimi. Informacje wygenerowane przez kilka systemów są dla personelu mniej wartościowe, gdyż nie dają pełnego obrazu działalności organizacji. Dane mogą być powielane w wielu plikach używanych przez różne systemy. W nowoczesnych systemach informatycznych dane są zintegrowane - dzięki czemu mogą być wykorzystywane na wiele sposobów

13 Zalety komputerowych BD Szybkość wyszukiwania informacji Oszczędność miejsca Integralność danych Dostęp dla wielu użytkowników Wygodne interfejsy Zabezpieczenia dostępu

14 Przykłady BD Książki telefoniczne Systemy rezerwacji miejsc Katalogi biblioteczne Systemy finansowo-księgowe Systemy wspomagające zarządzanie Witryny WWW

15 Część ekstensjonalna BD Encje (klasy) rzeczy istotne dla OA każda encja musi być jednoznacznie identyfikowalna (nazwa w liczbie pojedynczej) każda instancja (wystąpienie) encji musi być wyraźnie odróżnialna od wszystkich innych instancji encji tego samego typu (identyfikator, klucz główny) BD jest zbiorem faktów (asercji) pozytywnych na temat OA fakty negatywne nie są reprezentowane BD znajduje się w pewnym stanie (zawiera zbiór faktów, które są prawdziwe w danej chwili) Dane w bazie są traktowane jako trwałe

16 Integralność BD BD ma właściwość integralności, jeżeli jest dokładnym odbiciem swojego OA Jeżeli BD jest używana do celów referencyjnych, to integralność nie jest istotna Integralność sprawia, że BD zmienia się w przestrzeni, określonej przez zbiór stanów poprawnych

17 Więzy integralności Określają, w jaki sposób baza ma pozostać dokładnym odbiciem swojego OA Więzy statyczne określają, które stany bazy są poprawne Więzy przejść reguły, które wiążą ze sobą stany BD

18 Część intensjonalna BD Encje mają atrybuty (właściwości) Między encjami zachodzą pewne zależności, które mogą być opisywane przez diagramy związków encji (ERD) Tworzenie schematu BD to projektowanie BD

19 Rodzaje atrybutów wymagane vs. opcjonalne np. sygnatura ( 1234/AB ) vs. data_wypożyczenia (null) proste vs. złożone np. nazwisko ( Kowalski ) vs. adres ( Dworcowa 11 m. 7, Koszalin ) ulica ( Dworcowa ), nr_domu ( 11 ), nr_lokalu ( 7 ), kod_pocztowy ( ), miasto ( Koszalin ) jedno- vs. wielowartościowe nazwisko ( Kowalski ) vs. nr_telefonu ( , , ) podstawowe vs. pochodne data_urodzenia ( ) vs. wiek ( 15 ) wiek = data_bieżąca data_urodzenia

20 Diagram związków encji (ERD) Diagram prezentujący dane i związki logiczne pomiędzy nimi Na diagramie występują: encje o określonych właściwościach (atrybutach) związki między nimi (odniesienia) Notacje: kurza łapka UML i szereg innych

21 Związki encji Stopień związku: unarne (rekurencyjne) binarne (najczęściej spotykane) tercjarne, ternarne, n-arne Więzy strukturalne (krotności) liczność jeden-do-jednego (1:1) jeden-do-wielu (1:N, 1:*) wiele-do-wielu (N:M, *:*) uczestnictwo obowiązkowe opcjonalne

22 Diagram związków encji (ERD)

23 Diagram związków encji

24 Rozszerzony model związków encji (EER) Specjalizacja/generalizacja hierarchia encji związki nadklasa-podklasa dziedziczenie atrybutów Agregacja i kompozycja

25 Funkcje BD Funkcje aktualizujące dokonują zmian na danych Funkcje zapytań wydobywają dane z bazy proste złożone

26 Planowanie bazy danych Definicja systemu Gromadzenie i analiza wymagań Selekcja SZBD Tworzenie prototypów Projektowanie bazy danych Konceptualne projektowanie bazy danych Logiczne projektowanie bazy danych Fizyczne projektowanie bazy danych Projektowanie aplikacji Implementacja Cykl życia bazy danych Konwersja i przenoszenie danych Testowanie Bieżąca konserwacja

27 Administracja danymi i bazą danych Administracja danymi oznacza zarządzanie zasobami danych, w tym planowanie bazy danych, tworzenie i utrzymywanie standardów, założeń i procedur oraz konceptualne i logiczne projektowanie bazy danych. Administracja bazą danych oznacza zarządzanie fizyczną realizacją aplikacji, w tym fizyczne projektowanie i implementację bazy danych, definiowanie zasad bezpieczeństwa i więzów integralności, monitorowanie wydajności bazy danych oraz przeprowadzanie jej reorganizacji w razie potrzeby.

28 Zadania administratora danych Wybór odpowiednich narzędzi systemowych. Wspieranie rozwoju technologii informacyjnych w przedsiębiorstwie i związanych z nimi strategii. Przeprowadzanie badań realizowalności oraz planowanie rozwoju bazy danych. Tworzenie modelu danych przedsiębiorstwa. Określanie wymagań instytucji odnośnie do danych. Ustalanie standardów gromadzenia danych i ich formatów. Szacowanie objętości danych i perspektyw wzrostu. Wyznaczanie sposobów i częstości użycia danych. Wyznaczanie wymagań względem metod dostępu do danych oraz określanie zabezpieczeń, realizujących prawne i firmowe wymagania tego typu. Realizacja konceptualnego i logicznego projektu bazy danych.

29 Zadania administratora danych Łączność z administratorami bazy danych i wykonawcami aplikacji, służąca zapewnieniu wypełniania przez aplikacje wszystkich ustalonych wymagań. Szkolenie użytkowników w zakresie standardów danych i odpowiedzialności prawnej. Bieżące śledzenie technologii informacyjnych i postępu w przedsiębiorstwie. Zapewnienie kompletności dokumentacji, włączając w to model przedsiębiorstwa, standardy, założenia, procedury, użycie słownika danych i nadzór nad użytkownikami. Zarządzanie słownikiem danych. Łączność z użytkownikami służąca określaniu nowych wymagań i rozwiązywaniu problemów dotyczących dostępu do danych i wydajności. Tworzenie założeń dotyczących bezpieczeństwa.

30 Zadania administratora bazy danych Ocena i wybór SZBD. Realizacja fizycznego projektu bazy danych. Implementacja fizycznego projektu bazy danych w docelowym SZBD. Definiowanie zasad bezpieczeństwa i więzów integralności. Łączność z wykonawcami aplikacji bazy danych. Tworzenie strategii testowania. Szkolenie użytkowników. Końcowy odbiór zaimplementowanych aplikacji bazy danych. Monitorowanie wydajności systemu i dostrajanie systemu w razie potrzeby.

31 Zadania administratora bazy danych Regularne wykonywanie kopii zapasowych. Zapewnienie dostępności mechanizmów i procedur odzyskiwania danych. Zapewnienie kompletności dokumentacji, w tym materiałów wytworzonych własnymi siłami. Bieżące śledzenie rozwoju sprzętu i oprogramowania oraz ich cen. Instalacja koniecznych aktualizacji.

32 Własności BD Współdzielenie danych używanie bazy przez więcej niż jednego użytkownika, być może w tym samym czasie Integracja danych przechowywanie jednego logicznego elementu danych tylko w jednym miejscu Integralność danych baza danych ma dokładnie odzwierciedlać obszar analizy, którego jest modelem

33 Własności BD Bezpieczeństwo danych określenie zbioru użytkowników i ich uprawnień, ograniczenie dostępu do bazy Abstrakcja danych przechowywanie w bazie tylko istotnych szczegółów, dotyczących OA Niezależność danych oddzielenie danych od procesów, które używają tych danych organizacja danych ma być niewidoczna dla użytkowników

34 System zarządzania BD (SZBD) Zbiór programów, umożliwiających tworzenie i eksploatację BD Zarządza transakcjami (interakcja z użytkownikami) Zarządza dostępem do danych (wprowadzanie, usuwanie i modyfikacja) System bazy danych = BD + SZBD

35 użytkownik System BD transakcja S Z B D Moduł zarządzania transakcjami Moduł zarządzania dostępem do danych schemat BD dane

36 System baz danych (SBD) System Baz Danych to skomputeryzowany system przechowywania i przetwarzania danych. Składa się z następujących elementów: modelu danych oprogramowania System Zarządzania Bazą Danych inne oprogramowanie baz danych

37 System baz danych (SBD) Często do sytemu baz danych zalicza się również: sprzęt pamięci masowe urządzenia systemowe użytkowników programiści aplikacji - tworzą programy umożliwiające innym użytkownikom dostęp do bazy danych użytkownicy końcowi - obsługujący bazę danych - wprowadzający dane, generujący raporty itp. administratorzy BD - odpowiadają za tworzenie i konserwację rzeczywistej bazy danych oraz jej bezpieczeństwo

38 Funkcje SZBD Zarządzanie plikami dodawanie nowych plików do BD usuwanie plików z BD modyfikowanie struktury istniejących plików wstawianie nowych danych do istniejących plików aktualizowanie danych w istniejących plikach usuwanie danych z istniejących plików

39 Funkcje SZBD (c.d.) Wyszukiwanie informacji wydobywanie danych z istniejących plików do stosowania przez użytkowników wydobywanie danych do stosowania przez programy użytkowe Zarządzanie BD tworzenie i monitorowanie użytkowników BD ograniczanie dostępu do plików w BD monitorowanie działania BD

40 Architektura SZBD W 1975 (ANSI-SPARC) zaproponował trzypoziomową architekturę SZBD: poziom zewnętrzny (użytkownika) - opisuje jak użytkownicy widzą dane, poziom koncepcyjny (pojęciowy) - opisuje widok wszystkich danych w bazie. Poziom ten opisuje logiczny widok baz danych, bez szczegółów dotyczących realizacji, poziom wewnętrzny (fizyczny) - opisuje sposób przechowywania danych oraz metody dostępu do nich. Pomiędzy warstwami istnieją dwa poziomy odwzorowania przekładające się na dwa poziomy niezależności danych: logiczna niezależność danych - oznacza niewrażliwość schematów zewnętrznych na zmiany w schemacie koncepcyjnym, fizyczna niezależność danych - oznacza niewrażliwość schematu koncepcyjnego na zmiany w schemacie fizycznym.

41 Architektura SZBD (c.d.)

42 Architektura SZBD (c.d.)

43 Transakcja Jednostka interakcji użytkownika z BD Składa się z ciągu akcji (pojedynczych operacji) Przeprowadza BD z jednego stanu w drugi Może zostać zatwierdzona (commit) lub wycofana (rollback)

44 Cechy transakcji (ACID) Niepodzielność Spójność Izolacja Trwałość (Atomicity) (Consistency) (Isolation) (Durability) Transakcja jest funkcją aktualizującą

45 Architektoniczne modele danych Zbiór ogólnych zasad posługiwania się danymi: 1. definicja danych (określa strukturę danych) 2. operowanie danymi 3. integralność danych (określa, które stany bazy są poprawne) Każda baza danych i każdy SZBD muszą się stosować do zasad pewnego modelu danych

46 Architektoniczne modele danych (c.d.) Proste modele danych (plik rekord pole) Klasyczne modele danych model hierarchiczny model sieciowy model relacyjny Semantyczne modele danych model obiektowy

47 Generacje baz danych systemy plików (takie jak: ISAM i VSAM), hierarchiczne baz danych (ISM, System 2000), sieciowe bazy danych CODASYL (m.in. IDS, IDMS), relacyjne bazy danych, obiektowe bazy danych, postrelacyjne (obiektowo-relacyjne) bazy danych.

48 Chronologia powstawania modeli danych

49 Cechy modeli klasycznych struktura bazy danych opiera się na rekordach różnych typów o stałym formacie każdy rekord definiowany jest poprzez stałą liczbę atrybutów każdy atrybut jest zazwyczaj określonego rozmiaru co ułatwia implementację nie zawierają mechanizmów bezpośredniej reprezentacji kodu w bazie danych

50 Cechy modeli klasycznych z modelami związane są języki zapytań umożliwiające realizację zapytań oraz modyfikację danych opis danych na poziomie konceptualnym oraz na poziomie wyglądu całościowa specyfikacja konceptualnej struktury bazy danych opis implementacji bazy danych na wysokim poziomie

51 Hierarchiczne bazy danych W hierarchicznym modelu danych (HMBD) dane maja strukturę, którą można najprościej opisać jako odwrócone drzewo. Jedna z tabel pełni rolę korzenia drzewa, a pozostałe mają postać gałęzi biorących swój początek w korzeniu.

52 Hierarchiczne bazy danych Związki w HMBD są reprezentowane w kategoriach ojciec/syn (nadrzędny/podrzędny). Oznacza to że tabela-ojciec może być powiązana z wieloma tabelami/synami, lecz pojedynczy syn może mieć tylko jednego ojca. Tabele te mogą być powiązane jawnie, przez wskaźniki, lub przez fizyczną organizację rekordów wewnątrz tabel.

53 Hierarchiczne bazy danych Aby uzyskać dostęp do danych w modelu hierarchicznym, użytkownik zaczyna przeszukiwanie od korzenia i przedziera się przez całe drzewo danych, aż do interesującego go miejsca. Oznacza to jednak, że użytkownik musi dobrze znać strukturę bazy danych.

54 Model hierarchiczny Książki Beletrystyka Podręczniki Historyczne Obyczajowe Informatyka Fizyka Edytory Bazy danych Arkusze Optyka Magnetyzm P. Beynon-Davies: Systemy baz danych

55 Przykład 1: System plików UNIX/Linux/DOS/Windows

56 Przykład 2: Rejestr systemu Windows

57 Przykład 3: Usługi katalogowe (NDS/eDirectory, LDAP/ActiveDirectory)

58 Model sieciowy Architektura Malarstwo Rzeźba Gotyk Renesans Barok Modernizm Polska Francja Włochy Anglia Leonardo da Vinci: Mona Lisa

59 Model relacyjny Twórca: E.F. Codd (od 1968 do dziś) Cele: zdyscyplinowany sposób posługiwania się danymi (narzędzia matematyczne teorii zbiorów) podniesienie poziomu niezależności między programami a danymi wzrost wydajności tworzenia oprogramowania Jedna struktura danych: relacja (tabela relacyjna) Operacje na relacjach tworzą tzw. algebrę relacyjną Nieproceduralny język zapytań

60 Wady klasycznych baz danych i SZBD model danych (szczególnie relacyjny) jest zbyt prosty do zamodelowania złożonych, zagnieżdżonych encji, systemy baz danych oferują tylko kilka prostych typów danych (integer, character), nie obsługują ogólnych typów danych występujących w językach programowania, &

61 Wady klasycznych baz danych i SZBD model danych nie zawiera często używanych pojęć semantycznych (np.: generalizacja, agregacja), a co za tym idzie SZBD nie oferuje mechanizmów do reprezentacji takich związków i zarządzania nimi (programiści muszą sami zaimplementować takie mechanizmy w aplikacjach),

62 Wady klasycznych baz danych i SZBD zbyt wolne działanie systemów baz danych z programami użytkowymi wymagającymi szybkich i skomplikowanych obliczeń (szczególnie symulacyjnych), różnice między językami baz danych (SQL, DL/1, CODASYL DML), a językami programowania (COBOL, FORTRAN, PL/1, C++, Java) zarówno pod względem wykorzystywanego modelu danych, jak i struktur danych,

63 Wady klasycznych baz danych i SZBD systemy baz danych nie dostarczają narzędzi do reprezentowania i zarządzania temporalnymi aspektami baz danych (m.in.: pojęciem czasu, wersjami obiektów i schematu).

64 Model obiektowy Jest przykładem semantycznego modelu danych Semantyka (znaczenie) informacji zawarte w samej bazie danych Naturalne powiązanie danych i sposobów operowania na nich (enkapsulacja) Najczęściej realizowany jako dodatkowa opcja w modelu relacyjnym Ułatwione odwzorowanie danych do obiektowych języków programowania (np. Java)

65 Relacyjna i obiektowa struktura aplikacji

66 Zalety obiektowych baz danych reprezentacja złożonych obiektów typy danych definiowane przez użytkownika tożsamość obiektów (identyfikator), trwałość hermetyzacja, hierarchia, dziedziczenie rozszerzalność zgodność we wszystkich fazach życia bazy i danych

67 Zalety obiektowych baz danych metody i funkcje przechowywane wraz z danymi nowe możliwości (wersjonowanie, rejestracja zmian, powiadamianie...) możliwość nowych zastosowań mniejszym kosztem (bazy multimedialne, przestrzenne, bazy aktywne...) porównywalna wydajność (i wciąż rośnie)

68 Wady obiektowych baz danych brak optymalizacji zapytań (rozumianej jak w poprzednich modelach) niedopracowane mechanizmy zarządzania dużą bazą obiektów, sterowania wersjami,... mała liczba ekspertów od technik obiektowych nie wiadomo z jakimi kosztami wiąże się migracja dużych systemów brak dopracowanych standardów

69 Model relacyjny zasady Jedna struktura danych relacja (tabela relacyjna) Relacja jest skończonym zbiorem krotek (wierszy tabeli) o różnych wartościach i takiej samej strukturze (schemacie) schemat relacji lista nazw kolumn (atrybutów relacji) plik encja relacja - tabela rekord instancja - krotka wiersz tabeli atrybut - kolumna zbiór wartości danego atrybutu wartość atrybutu - pole rekordu pole tabeli (na przecięciu wiersza i kolumny)

70 Przedmioty Przykład relacji Nazwa Semestr KodKierunku NrPrac Systemy baz danych 1 INF 234 Podstawy programowania 1 INF 234 Informatyka 3 ADM 345 Projektowanie sieci komputerowych 3 INF 345 Prawo administracyjne 2 ADM 456

71 Cechy relacji 1. Każda relacja w bazie ma jednoznaczną nazwę 2. Każda kolumna w relacji ma jednoznaczną nazwę w ramach relacji 3. Wszystkie wartości w kolumnie są tego samego typu 4. Porządek kolumn w relacji nie jest istotny 5. Każdy wiersz w relacji musi być różny 6. Porządek wierszy nie jest istotny 7. Każde pole zawiera wartość atomową (niepodzielną)

72 Dziedzina Zbiór wartości, z którego pochodzą elementy, pojawiające się w kolumnach tabeli Wartość null oznacza niepełną lub nieznaną informację Trzeba stosować logikę trójwartościową

73 Klucze główne Kolumna (lub zbiór kolumn), której wartości jednoznacznie identyfikują każdy wiersz tabeli Klucz główny wybierany jest spośród kluczy kandydujących Integralność encji: każda tabela musi mieć klucz główny; kolumna (lub kolumny) wybrane jako klucz główny powinny być jednoznaczne i nie zawierać wartości null

74 Klucze kandydujące/główne Wykładowcy NrPrac Nazwisko Status 234 P. Beynon-Davies AS 345 C.J. Date AD 456 J. Ullmann PR 666 B. Devil PE

75 Klucze kandydujące/główne Przedmioty Nazwa Semestr KodKierunku NrPrac Systemy baz danych 1 INF 234 Podstawy programowania 1 INF 234 Informatyka 3 ADM 345 Projektowanie sieci komputerowych 3 INF 345 Prawo administracyjne 2 ADM 456

76 Klucze kandydujące/główne Przedmioty Nazwa Semestr KodKierunku NrPrac Systemy baz danych 1 INF 234 Podstawy programowania 1 INF 234 Informatyka 3 ADM 345 Projektowanie sieci komputerowych 3 INF 345 Prawo administracyjne 2 ADM 456 Informatyka 1 MAT null

77 Klucze obce Kolumna (lub zbiór kolumn) tabeli, która czerpie swoje wartości z tej samej dziedziny, co klucz główny tabeli z nią powiązanej Integralność referencyjna: każda wartość klucza obcego może bądź odwoływać się do wartości klucza głównego tabeli powiązanej, bądź przyjmować wartość null

78 Klucze obce Przedmioty Nazwa Semestr KodKierunku NrPrac Systemy baz danych 1 INF 234 Podstawy programowania 1 INF 234 Informatyka 3 ADM 345 Projektowanie sieci komputerowych 3 INF 345 Prawo administracyjne 2 ADM 456 Informatyka 1 MAT null Wykładowcy NrPrac Nazwisko Status 234 P. Beynon-Davies AS 345 C.J. Date AD 456 J. Ullmann PR 666 B. Devil PE

79 Utrzymywanie integralności referencyjnej 1. Usuwanie ograniczone (podejście ostrożne) 2. Usuwanie kaskadowe (podejście ufne) 3. Wstawianie null (podejście wyważone)

80 Integralność dodatkowa Aspekt integralności, którego nie można wyrazić za pomocą reguł integralności wewnętrznej (semantyka) Ciąg definicji więzów, najczęściej wyrażany za pomocą reguł algebry relacyjnej, wyrażeń SQL itp.

81 Algebra relacyjna selekcja (ograniczenie) projekcja (rzut) złączenia iloczyn kartezjański suma przecięcie różnica iloraz

82 Selekcja Przedmioty Nazwa Semestr KodKierunku NrPrac Systemy baz danych 1 INF 234 Podstawy programowania 1 INF 234 Informatyka 3 ADM 345 Projektowanie sieci komputerowych 3 INF 345 Prawo administracyjne 2 ADM 456

83 Selekcja σ Semestr=1 Przedmioty Nazwa Semestr KodKierunku NrPrac Systemy baz danych 1 INF 234 Podstawy programowania 1 INF 234

84 Projekcja Przedmioty Nazwa Semestr KodKierunku NrPrac Systemy baz danych 1 INF 234 Podstawy programowania 1 INF 234 Informatyka 3 ADM 345 Projektowanie sieci komputerowych 3 INF 345 Prawo administracyjne 2 ADM 456

85 Projekcja π Nazwa,Semestr Przedmioty Nazwa Systemy baz danych Semestr 1 Podstawy programowania 1 Informatyka 3 Projektowanie sieci komputerowych 3 Prawo administracyjne 2

86 Złączenia równozłączenie złączenie naturalne złączenia zewnętrzne lewostronne prawostronne obustronne

87 Równozłączenie Równozłączenie relacji Przedmioty i Wykładowcy Przedmioty EQUIJOIN Wykładowcy Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko Status Systemy baz danych Podstawy programowania 1 INF P. Beynon- Davies 1 INF P. Beynon- Davies Informatyka 3 ADM C.J. Date AD Projektowanie sieci komputerowych Prawo administracyjne 3 INF C.J. Date AD 2 ADM J. Ullmann PR AS AS

88 Złączenie naturalne Złączenie naturalne relacji Przedmioty i Wykładowcy Przedmioty JOIN Wykładowcy Nazwa Semestr KodKierunku NrPrac Nazwisko Status Systemy baz danych Podstawy programowania 1 INF 234 P. Beynon- Davies 1 INF 234 P. Beynon- Davies Informatyka 3 ADM 345 C.J. Date AD Projektowanie sieci komputerowych Prawo administracyjne AS AS 3 INF 345 C.J. Date AD 2 ADM 456 J. Ullmann PR

89 Złączenia zewnętrzne Lewostronne złączenie zewnętrzne relacji Przedmioty i Wykładowcy Przedmioty LEFT OUTER JOIN Wykładowcy Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko Status Systemy baz danych Podstawy programowania 1 INF P. Beynon- Davies 1 INF P. Beynon- Davies Informatyka 3 ADM C.J. Date AD Projektowanie sieci komputerowych Prawo administracyjne 3 INF C.J. Date AD 2 ADM J. Ullmann PR Informatyka 1 MAT null null null null AS AS

90 Złączenia zewnętrzne Prawostronne złączenie zewnętrzne relacji Przedmioty i Wykładowcy Przedmioty RIGHT OUTER JOIN Wykładowcy Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko Status Systemy baz danych Podstawy programowania 1 INF P. Beynon- Davies 1 INF P. Beynon- Davies Informatyka 3 ADM C.J. Date AD Projektowanie sieci komputerowych Prawo administracyjne 3 INF C.J. Date AD 2 ADM J. Ullmann PR null null null null 666 B. Devil PE AS AS

91 Złączenia zewnętrzne Obustronne złączenie zewnętrzne relacji Przedmioty i Wykładowcy Przedmioty FULL OUTER JOIN Wykładowcy Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko Status Systemy baz danych Podstawy programowania 1 INF P. Beynon- Davies 1 INF P. Beynon- Davies Informatyka 3 ADM C.J. Date AD Projektowanie sieci komputerowych Prawo administracyjne 3 INF C.J. Date AD 2 ADM J. Ullmann PR Informatyka 1 MAT null null null null null null null null 666 B. Devil PE AS AS

92 Operatory teoriomnogościowe Suma, przecięcie, różnica Operują na relacjach o zgodnych schematach, tj. zawierających te same zbiory atrybutów, określonych na tych samych dziedzinach Traktują relacje jako zbiory krotek

93 Suma, przecięcie, różnica Wykładowcy NrPrac Nazwisko Status 234 P. Beynon-Davies AS 345 C.J. Date AD 456 J. Ullmann PR 666 B. Devil PE Administratorzy NrPrac Nazwisko Status 234 P. Beynon-Davies AS 345 C.J. Date AD 777 A. Angel PR 1001 S. Jones UR 1023 R. Evans SU

94 Suma, przecięcie, różnica Wykładowcy UNION Administratorzy NrPrac Nazwisko Status 234 P. Beynon-Davies AS 345 C.J. Date AD 456 J. Ullmann PR 666 B. Devil PE 777 A. Angel PR 1001 S. Jones UR 1023 R. Evans SU Wykładowcy INTERSECT Administratorzy NrPrac Nazwisko Status 234 P. Beynon-Davies AS 345 C.J. Date AD

95 Suma, przecięcie, różnica Wykładowcy EXCEPT Administratorzy NrPrac Nazwisko Status 456 J. Ullmann PR 666 B. Devil PE Administratorzy EXCEPT Wykładowcy NrPrac Nazwisko Status 777 A. Angel PR 1001 S. Jones UR 1023 R. Evans SU

96 Modelowanie związków encji Model związków encji (ER Entity-Relationship Model) jeden z przykładów modelu do komunikowania się z użytkownikami. Modelowanie związków encji reprezentuje podejście zstępujące do projektowania bazy danych. Rozpoczyna się mianowicie od wyodrębnienia istotnych danych, nazywanych encjami, i tych związków pomiędzy nimi, które powinny być reprezentowane w modelu. Następnie dodaje się do modelu coraz więcej szczegółów, takich jak informacje, które chcemy przechowywać o encjach i o związkach, nazywane atrybutami, oraz więzy (warunki) odnoszące się do encji, związków i atrybutów. Zbiór encji to grupa obiektów o tych samych właściwościach, które w ramach przedsiębiorstwa zostały uznane za niezależne byty. Wystąpienie encji to unikalny i rozpoznawalny obiekt ze zbioru encji.

97 Graficzna reprezentacja zbiorów encji Każdy zbiór encji jest reprezentowany za pomocą prostokąta oznaczonego nazwą encji, która jest zazwyczaj rzeczownikiem w liczbie pojedynczej. Nazwa encji Personel WłaścicielPrywatny

98 Związki encji Związek to zbiór znaczących powiązań pomiędzy zbiorami 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. Sieć semantyczna: Encja Biuro (biuronr) Związek Ma Encja Personel (pracowniknr) Używając modelu związków encji: B003 r1 SG37 Nazwa związku r2 SG14 B007 r3 SA9 Biuro Ma Personel Biuro ma personel

99 Stopień związku (liczba uczestniczących w nim zbiorów encji) Związek binarny: Właściciel prywatny posiada nieruchomość do wynajęcia WłaścicielPrywatny PPosiada Nieruchomość Związek potrójny: Związek poczwórny: Personel Rejestruje Biuro Prawnik Klient Personel rejestruje klienta w biurze Kupujący Uzgadnia Instytucja finansowa Oferta Prawnik w imieniu kupującego wspieranego przez instytucję finansową uzgadnia ofertę

100 Związki rekurencyjne (związki, w których ten sam zbór encji występuje więcej niż jeden raz w różnych rolach) Personel (kierownik) kieruje personelem (kierowanymi) Kieruje Nazwa roli Przykład encji powiązanych ze sobą poprzez dwa różne związki: Nazwa roli Kierowany Kierownik Personel Dyrektor zarządza biurem oddziału Nazwa roli Dyrektor Personel Zarządza Ma Biuro oddziału Biuro Zbiór encji Personel uczestniczy podwójnie w związku Kieruje. Związkom mogą być przypisane nazwy ról, które są istotne przy związkach rekurencyjnych, aby wskazać funkcje wypełniane w nich przez uczestników. Pracownik Nazwa roli Biuro oddziału Nazwy ról nie są na ogół wymagane, jeśli funkcje, jakie pełnią w związku uczestniczące w nim encje, są jednoznaczne. Biuro oddziału ma pracownika

101 Atrybut (cecha encji lub związku) proste zawierające tylko jedną składową, która może istnieć niezależnie; złożone zbudowane z wielu składowych, z których każda może istnieć niezależnie; jednowartościowy atrybut, który ma tylko jedną wartość; wielowartościowy atrybut, który może zawierać wiele wartości dla pojedynczego wystąpienia encji. pochodny atrybut reprezentujący wartość, która jest wyliczana z podobnego atrybutu lub ze zbioru atrybutów, niekoniecznie pochodzących z tego samego zbioru. Klucz główny Obszar do umieszczania atrybutów Personel pracowniknr (PK) imięnazwisko stanowisko pensja /liczba personelu Zarządza Ma Atrybut pochodny Biuro biuronr (PK) adres ulica miasto kodpocztowy telnr [1..3] [1..*] Atrybut jednowartościowy Atrybut złożony PK primary key PPK partial primary key AK alternate key Atrybut wielowartościowy

102 Atrybuty związków Gazeta ogłasza nieruchomość do wynajęcia Graficzna reprezentacja związku Ogłasza: Gazeta NazwaGazety Ogłasza Nieruchomość NieruchomośćNr Silne i słabe zbiory encji: dataogłoszenia koszt Silny zbiór encji to zbiór encji, którego istnienie nie jest zależne od innych zbiorów encji, natomiast istnienie słabego zbioru encji zależy od innych zbiorów encji. Silna encja Klient klientnr (PK) imięnazwisko imię nazwisko telnr Określa Słaba encja Preferencje typpreferencji maksczynsz

103 Więzy strukturalne Więzy, które mogą być nałożone na zbiory encji biorące udział w związku powinny odzwierciedlać ograniczenia występujące w związkach, które można zaobserwować w rzeczywistości. Głównym typem więzów nakładanych na związki jest krotność liczba lub zakres możliwych wystąpień encji z jednego zbioru, które mogą być w danym związku z pojedynczym wystąpieniem innej powiązanej encji. Krotność ogranicza sposób powiązania encji, reprezentuje założenia określone przez użytkownika lub przedsiębiorstwo. Najbardziej powszechnymi związkami są związki binarne, które można podzielić na: wzajemnie jednoznaczne (1:1); typu jeden do wielu (1:*); typu wiele do wielu. Np.: osoba z personelu zarządza biurem (1:1); osoba z personelu nadzoruje nieruchomości do wynajęcia (1:*); gazety ogłaszają nieruchomości do wynajęcia (*:*).

104 Związki wzajemnie jednoznaczne Sieć semantyczna przedstawiająca dwa wystąpienia związku Personel Zarządza Biuro: Zbiór encji Personel (pracowniknr) SG5 SG37 Związek Zarządza r1 Zbiór encji Biuro (biuronr) B003 SL21 r2 B005 Każde biuro jest zarządzane przez jedną osobę z personelu Personel Zarządza pracowniknr Krotność Osoba z personelu zarządza zero lub jednym biurem Biuro biuronr Wyznaczenie krotności związku wymaga na ogół wykorzystania próbek danych i dokładnego zbadania powiązań pomiędzy danymi występującymi w tym związku.

105 Związek typu jeden do wielu Sieć semantyczna przedstawiająca trzy wystąpienia związku Personel Nadzoruje Nieruchomość: Zbiór encji Personel (pracowniknr) SG5 SG37 SA9 Związek Nadzoruje r1 r2 r3 Zbiór encji Nieruchomość (nieruchomośćnr) PG21 PG36 PA14 PG4 Każda nieruchomość do wynajęcia jest nadzorowana przez zero lub jednego pracownika Każdy pracownik nadzoruje zero lub więcej nieruchomości do wynajęcia Personel Nadzoruje pracowniknr * Nieruchomość nieruchomośćnr

106 Związek typu wiele do wielu Sieć semantyczna przedstawiająca cztery wystąpienia związku Gazeta Ogłasza Nieruchomość: Encja Gazeta (nazwagazety) Głos Gazeta Poranny Związek Ogłasza r1 r2 r3 r4 Encja Nieruchomość (nieruchomośćnr) PG21 PG36 PA14 PG4 Każda nieruchomość do wynajęcia jest ogłaszana w zero lub więcej gazet Każda gazeta ogłasza jedną lub więcej nieruchomości do wynajęcia Gazeta Ogłasza nazwagazety 0..* 1..* Nieruchomość nieruchomośćnr

107 Więzy liczności i uczestnictwa Liczność opisuje maksymalną liczbę możliwych wystąpień związku dla encji uczestniczącej w tym związku. Uczestnictwo określa, czy w pewnym związku biorą udział wszystkie, czy tylko niektóre wystąpienia encji. Liczność Jedno biuro jest zarządzane przez jednego pracownika Jeden pracownik zarządza jednym biurem Personel Zarządza Biuro pracowniknr biuronr Wszystkie biura są zarządzane (uczestnictwo obowiązkowe dla biur) Nie każdy pracownik zarządza biurem (uczestnictwo opcjonalne dla personelu) Uczestnictwo

108 Problemy występujące w modelach ER Pułapka wachlarzowa występuje w sytuacji, gdy model przedstawia związek pomiędzy pewnymi zbiorami encji, ale wynikające z tego ścieżki pomiędzy wystąpieniami encji nie są jednoznaczne. Personel Ma Prowadzi Oddział 1..* * Biuro Oddział Prowadzi Biuro * * Ma Personel Zmiana struktury modelu

109 Pułapka szczelinowa występuje, gdy model sugeruje istnienie związku pomiędzy zbiorami encji, ale nie istnieją ścieżki łączące pewne wystąpienia tych encji. Biuro Ma Nadzoruje Personel * * Nieruchomość Biuro Ma Nadzoruje Personel * * Nieruchomość * Oferuje Dodanie związku Oferuje

110 Rozszerzone modelowanie związków encji Specjalizacja to proces maksymalizacji różnic pomiędzy elementami encji, realizowany poprzez identyfikację wyróżniających ich charakterystyk. Generalizacja to proces minimalizacji różnic pomiędzy encjami, realizowany poprzez wyznaczanie ich wspólnych charakterystyk. Agregacja reprezentuje związki typu jest częścią lub ma pomiędzy zbiorami encji, w których jeden uczestnik związku jest całością, a drugi częścią. Kompozycja to specjalna forma agregacji przedstawiająca powiązanie pomiędzy encjami, w którym występuje silny związek posiadania części przez całość oraz zgodność okresów ich istnienia. 110

111 Transformacja ERD do modelu relacyjnego Transformacja encji i ich atrybutów na relacje i ich atrybuty Transformacja związków pomiędzy encjami na związki pomiędzy relacjami Transformacja hierarchii encji (w modelu rozszerzonym) na

112 Przypomnienie pojęć Schemat bazy danych zbiór schematów relacji Relacja (tabela) dwu-wymiarowa tablica kolumny atrybuty wiersze krotki, rekordy każda krotka reprezentuje wystąpienie encji

113 Przypomnienie pojęć Klucz główny (podstawowy) atrybut lub zbiór atrybutów - wybrany spośród kluczy potencjalnych Klucz obcy atrybut lub zbiór atrybutów wskazujący na klucz główny innej relacji atrybut lub zbiór atrybutów w relacji B, będący jednocześnie kluczem głównym w relacji A należy zaznaczyć, że klucz obcy może odnosić się do klucza głównego tej samej relacji, w której został on zdefiniowany

114 Reguły transformacji encji Encja relacja Atrybut encji atrybut relacji Typ danych atrybutu encji typ danych atrybutu relacji Identyfikator encji klucz główny relacji Obowiązkowość atrybutów encji ograniczenie NOT NULL Opcjonalność atrybutów encji ograniczenie NULL Pozostałe ograniczenia integralnościowe atrybutów encji ograniczenia integralnościowe atrybutów relacji

115 Reguły transformacji encji Atrybuty wielowartościowe odrębna krotka w tabeli, dla każdej wartości atrybutu (ale mogą się pojawić anomalie i problemy z normalizacją) odrębna tabela na wartości tego atrybutu (i powiązane z nimi) plus powiązanie z tabelą zasadniczą Atrybuty złożone podział na atrybuty proste dodatkowe kolumny w tabeli

116 Reguły transformacji związków Związek binarny 1:1 klucz obcy we wskazanej tabeli Związek unarny 1:1, 1:M klucz obcy w tej samej tabeli Związek binarny 1:M klucz obcy w tabeli po stronie wiele Związek unarny/binarny M:N, związki stopnia > 2 (tercjarne, ternarne) tabela

117 Związek binarny 1:1 (1)

118 Związek binarny 1:1 (2)

119 Związek binarny 1:1 (3)

120 Związek 1:M (1) Klucz obcy dodawany do relacji po stronie "wiele" Ograniczenia referencyjne definiowane dla klucza obcego Obowiązkowość związku po stronie wiele ograniczenie NOT NULL definiowane na kluczu obcym Opcjonalność związku po stronie wiele ograniczenie NULL definiowane na kluczu obcym relacji Opcjonalność lub obowiązkowość związku po stronie jeden nie jest odwzorowywana w modelu relacyjnym

121 Związek 1:M (2)

122 Związek M:N (1) Reprezentowany poprzez dodatkową relację Nazwa relacji jest złączeniem nazw relacji powstałych z encji Relacja zawiera klucze obce wskazujące na klucze główne relacji powstałych z powiązanych encji Ograniczenia referencyjne definiowane dla kluczy obcych Klucze obce tworzą klucz główny relacji

123 Związek M:N (2)

124 Transformacja związków M:N Związek M:N przenosimy jako nową relację Tworzymy klucze obce na podstawie kluczy głównych dwóch pozostałych relacji Na atrybuty jednego i drugiego klucza obcego nakładamy dwa ograniczenia referencyjne Wszystkie atrybuty relacji tworzą klucz główny

125 Transformacja związków M:N PRACOWNIK # id_pracownika * imię * nazwisko pracuje nad jest realizowany przez PROJEKT # nazwa_proj * data_rozpocz o data_zakoncz A co w przypadku gdybyśmy chcieli przechowywać informację o liczbie godzin tygodniowo przepracowanych przez pracownika nad określonym projektem?

126 Transformacja związków M:N PRACOWNIK # id_pracownika * imię * nazwisko pracuje nad jest realizowany przez PROJEKT # nazwa_proj * data_rozpocz o data_zakoncz Jest to przypadek atrybutu charakteryzującego związek!

127 Transformacja związków M:N PRACOWNIK # id_pracownika * imię * nazwisko pracuje nad jest realizowany przez PROJEKT # nazwa_proj * data_rozpocz o data_zakoncz PRACOWNICY ( Id_pracownika PRIMARY KEY Imię NOT NULL Nazwisko NOT NULL ) PROJEKTY ( Nazwa_projektu Data_rozpocz Data_zakoncz PRIMARY KEY NOT NULL NULL ) UDZIAŁY_W_PROJEKTACH ( Id_pracownika REFERENCES Pracownicy(id_pracownika), Nazwa_projektu REFERENCES Projekty(Nazwa_projektu), Godziny NULL PRIMARY KEY (Id_pracownika, Nazwa_projektu) ) Atrybut związku

128 Przykład 1 OA: W pewnej szkole organizowane są konkursy przedmiotowe dla uczniów, którzy za udział w nich otrzymują nagrody. Każdy konkurs ma swojego opiekuna spośród nauczycieli, datę, kwotę przeznaczoną na nagrody itp. Uczniowie uczęszczają do klas o różnym profilu, z których każda ma swojego wychowawcę. Zadanie: Przedstawić opisany powyżej OA w postaci diagramu związków encji i przekształcić go w schemat relacji.

129 Przykład 2 OA: Pewna uczelnia prowadzi projekty finansowane ze źródeł zewnętrznych. Każdy projekt jest kierowany przez swojego kierownika i ma m.in. określony budżet, w projekcie biorą ponadto udział pracownicy różnych działów uczelni (każdy dział ma m.in. także osobę zarządzającą i swój budżet), którzy oprócz regularnej pensji otrzymują dodatkowe wynagrodzenie z tytułu udziału w projekcie. Zadanie: Analogiczne, jak poprzednio.

130 Związek unarny (1)

131 Związek unarny (2)

132 Związki tercjarne

133 Hierarchia encji Schemat 1: jedna wspólna tabela Schemat 2: dla każdej pod-encji tworzona jest tabela, zawierająca atrybuty wspólne i specyficzne Schemat 3: dla atrybutów wspólnych tworzona jest tabela wspólna dla każdej pod-encji tworzona jest osobna tabela z kluczem i atrybutami specyficznymi tabela wspólna i tabele powstałe z pod-encji, powiązane ograniczeniami referencyjnymi

134 Transformacja hierarchii encji (schemat 1 do jednej relacji)

135 Transformacja hierarchii encji (schemat 1 do jednej relacji) PRACOWNIK # id_prac atrybuty_wspólne PRACOWNIK KRAJOWY atr_specyf_kraj PRACOWNIK ZAGRANICZNY atr_specyf_zagr PRACOWNICY ( Id_pracownika PRIMARY KEY atrybuty wspólne atr_specyf_kraj NULL atr_specyf_zagr NULL typ_prac NOT NULL) Zasady transformacji: Tworzymy relację zawierającą atrybuty wspólne, atrybuty specyficzne wszystkich specjalizacji i atrybut określający typ specjalizacji. Wszystkim atrybutom specyficznym poszczególnych specjalizacji nadajemy własność NULL.

136 Transformacja hierarchii encji (schemat 2 do dwóch relacji)

137 Transformacja hierarchii encji (schemat 2 do dwóch relacji) PRACOWNIK # id_prac atrybuty_wspólne PRACOWNIK KRAJOWY atr_specyf_kraj PRACOWNIK ZAGRANICZNY atr_specyf_zagr PRACOWNICY_KRAJ ( Id_pracownika PRIMARY KEY atrybuty wspólne atr_specyf_kraj ) PRACOWNICY_ZAGR ( Id_pracownika PRIMARY KEY atrybuty wspólne atr_specyf_zagr ) Zasady transformacji: Dla każdej specjalizacji tworzymy relację zawierającą atrybuty wspólne, atrybuty specyficzne danej specjalizacji i klucz podstawowy dziedziczony z generalizacji.

138 Transformacja hierarchii encji (schemat 3 do trzech relacji)

139 Transformacja hierarchii encji (schemat 3 do trzech relacji) PRACOWNIK # id_prac atrybuty_wspólne PRACOWNIK KRAJOWY atr_specyf_kraj PRACOWNIK ZAGRANICZNY atr_specyf_zagr PRACOWNICY ( Id_pracownika PRIMARY KEY atrybuty_wspólne, typ_prac NOT NULL ) PRACOWNICY_KRAJ ( Id_pracownika PRIMARY KEY atr_specyf_kraj ) PRACOWNICY_ZAGR ( Id_pracownika PRIMARY KEY atr_specyf_zagr ) Zasady transformacji: Tworzymy jedną relację zawierająca atrybuty wspólne i atrybut określający typ specjalizacji Dla każdej specjalizacji tworzymy relację zawierającą jej atrybuty specyficzne i klucz podstawowy dziedziczony z generalizacji.

140 Transformacja związków wyłącznych - schemat 1

141 Transformacja związków wyłącznych - schemat 2

142 Normalizacja schematu relacji Głównym celem projektowania bazy przeznaczonej dla systemu relacyjnego jest właściwa reprezentacja danych, związków i więzów W identyfikowaniu właściwych relacji pomaga technika nazywana normalizacją, która jest techniką wstępującą ( z dołu do góry ) projektowania bazy danych

143 Normalizacja schematu relacji Normalizacja to technika służąca do wyznaczania zbioru relacji o pożądanych własnościach na podstawie analizy istniejącego zbioru danych Metoda stosowana głównie w organizacjach, które przed wprowadzeniem bazy danych gromadziły dane w innej formie np. w arkuszach kalkulacyjnych lub w formie papierowej

144 Normalizacja schematu relacji 1972 po raz pierwszy przedstawiony proces normalizacji przez E.F.Codda; wówczas zaproponował trzy postacie normalne: 1NF, 2NF, 3NF (normal form) R.Boyce i E.F.Codd wprowadzili silniejszą definicję trzeciej postaci normalnej (BCNF) Powyższe postacie normalne są oparte na zależnościach funkcyjnych pomiędzy atrybutami

145 Normalizacja schematu relacji Wprowadzone kilka lat później wyższe postacie normalne, wychodzące poza BCNF, czwarta i piąta postać normalna (Fagin 1977, 1979) dotyczą sytuacji występujących bardzo rzadko Powyższe postacie normalne są oparte na niefunkcyjnych zależnościach wielowartościowych pomiędzy atrybutami

146 Nadmiarowość danych i anomalie aktualizacji Główne zadanie w projektowaniu relacyjnej bazy danych to pogrupowanie atrybutów w relacje w sposób, który minimalizuje nadmiarowość danych efektem jest zmniejszenie wymagań pamięciowych dla plików implementujących bazowe relacje oraz usunięcie anomalii aktualizacji

147 Anomalie wynikające z nadmiarowości anomalie wstawiania (dopisanie rekordu może powodować niespójność/ dezaktualizację innego pola) anomalie usuwania (usunięcie wiersza powoduje usunięcie większej ilości informacji, niż zamierzaliśmy) anomalie modyfikacji (zmiana jednego rekordu powoduje konieczność zmiany zapisów w innych rekordach)

148 Dekompozycja Poprzez dekompozycję relacji pozbywamy się problemu anomalii aktualizacji Dekompozycja ma dwie ważne własności: bezstratnego złączenia zapewniająca, że każdy stan oryginalnej relacji może być odtworzony z odpowiednich stanów mniejszych relacji zachowania zależności gwarantująca, że więzy na oryginalnej relacji mogą być utrzymane przez proste wymuszenie pewnych więzów na każdej z mniejszych relacji

149 Etapy normalizacji 1. Zebranie danych 2. Przekształcenie do pierwszej postaci normalnej (1NF) 3. Przekształcenie do drugiej postaci normalnej (2NF) 4. Przekształcenie do trzeciej postaci normalnej (3NF)

150 Etapy normalizacji Po znormalizowaniu do 3NF relacje najczęściej są już pozbawione anomalii, jeżeli nie to należy je: 4. Przekształcić do postaci normalnej Boyce a- Codd a (BCNF) 5. Przekształcić do czwartej postaci normalnej (4NF) 6. Przekształcić do piątej postaci normalnej (5NF) Proces normalizacji jest włożony, tzn. każda wyższa postać normalna jest podzbiorem postaci niższej

151 Nieznormalizowany zbiór danych Przedmiot Id pracownika Nazwisko pracownika Id studenta Student Ocena Typ oceny TOiS 23 Bos 123 Botas 4 W 4,5 Ć 143 Moton 3,5 Ć 134 Koton 4,5 W 5 Ć UA 23 Bos 321 Ficek 4 W 4,5 Ć Angielski 34 Kusek 231 Bocek 5 Ć

152 Zależność funkcyjna Dwa elementy danych A i B są w zależności funkcyjnej lub relacji zależnej, jeśli ta sama wartość elementu danych B pojawia się zawsze z tą samą wartością elementu danych A. W takim przypadku mówimy, że atrybut A określa (wyznacza) funkcyjnie atrybut B: A B Wszystkie atrybuty w tabeli są funkcyjnie zależne od klucza głównego tej tabeli Wszystkie dane osobowe są zależne funkcyjnie od numeru PESEL osoby

153 Pierwsza postać normalna Relacja jest w pierwszej postaci normalnej wtedy i tylko wtedy, gdy każdy atrybut niekluczowy jest funkcyjnie zależny od klucza głównego (co jest równoważne stwierdzeniu, że w polach relacji mamy wartości atomowe, niepodzielne, a nie listy/zbiory wartości) W pierwszym etapie normalizacji próbujemy znaleźć w relacji klucz główny od którego wszystkie atrybuty niekluczowe byłyby funkcyjnie zależne. Jeśli nie można znaleźć klucza głównego, to relację należy podzielić na mniejsze

154 Znormalizowany zbiór danych (1NF) Przedmiot Id pracownika Nazwisko pracownika Id studenta Student Ocena Typ oceny TOiS 23 Bos 123 Botas 4 W TOiS 23 Bos 123 Botas 4,5 Ć TOiS 23 Bos 143 Moton 3,5 Ć TOiS 23 Bos 134 Koton 4,5 W TOiS 23 Bos 134 Koton 5 Ć UA 23 Bos 321 Ficek 4 W UA 23 Bos 321 Ficek 4,5 Ć Angielski 34 Kusek 231 Bocek 5 Ć

155 Druga postać normalna Relacja jest w drugiej postaci normalnej wtedy i tylko wtedy, gdy jest w pierwszej postaci normalnej i każdy atrybut niekluczowy jest w pełni funkcyjnie zależny od klucza głównego (tzn. od całości klucza, a nie tylko jego części) W tabeli Oceny atrybut Student zależy funkcyjne tylko od atrybutu Id studenta, czyli od części klucza głównego, a nie od całego klucza, podobnie jak Id pracownika i Nazwisko pracownika, które zależą tylko od atrybutu Przedmiot Atrybut Ocena zależy funkcyjnie od całego klucza głównego

156 Przejście do 2NF (z zachowaniem bezstratnego złączenia) * Oceny Przedmiot Id studenta Typ oceny Student TOiS 123 W Botas 4 Ocena 1 Przedmiot Przedmioty Id pracownika TOiS 23 Bos UA 23 Bos Nazwisko pracownika Angielski 34 Kusek TOiS 123 Ć Botas 4,5 TOiS 143 Ć Moton 3,5 TOiS 134 W Koton 4,5 TOiS 134 Ć Koton 5 UA 321 W Ficek 4 UA 321 Ć Ficek 4,5 Angielski 231 Ć Bocek 5

157 Tabele w 2NF 1 Przedmioty * Oceny 1 Przedmiot Id pracownika TOiS 23 Bos UA 23 Bos Nazwisko pracownika Angielski 34 Kusek Przedmiot * Id studenta Typ oceny TOiS 123 W 4 Ocena TOiS 123 Ć 4,5 TOiS 143 Ć 3,5 TOiS 134 W 4,5 TOiS 134 Ć 5 UA 321 W 4 UA 321 Ć 4,5 Angielski 231 Ć 5 Id studenta Studenci Student 123 Botas 143 Moton 134 Koton 321 Ficek 231 Bocek

158 Trzecia postać normalna Relacja jest w trzeciej postaci normalnej wtedy i tylko wtedy, gdy jest w drugiej postaci normalnej i każdy niekluczowy atrybut jest bezpośrednio funkcyjnie zależny (a nie pośrednio zależny) od klucza głównego (inaczej mówiąc, brak jest zależności funkcyjnych atrybutów niekluczowych od innych atrybutów niekluczowych) W tabeli Przedmioty atrybut Nazwisko pracownika jest zdeterminowany przez atrybut Id pracownika, a zatem atrybut Nazwisko pracownika jest przechodnio zależny od klucza głównego atrybutu Przedmiot

159 Przejście do 3NF (z zachowaniem bezstratnego złączenia) Przedmiot Id pracownika Przedmioty TOiS 23 Bos UA 23 Bos Nazwisko pracownika Angielski 34 Kusek Przedmioty 1 Przedmiot TOiS 23 UA 23 Angielski 34 Id pracownika * Id pracownika 23 Bos Pracownicy Nazwisko pracownika 34 Kusek

160 Tabele w 3NF 1 Przedmiot TOiS 23 UA 23 Angielski 34 1 Id pracownika Przedmioty Id pracownika 23 Bos Nazwisko pracownika 34 Kusek * Pracownicy * * 1 Przedmiot Id studenta Oceny Typ oceny TOiS 123 W 4 Ocena TOiS 123 Ć 4,5 TOiS 143 Ć 3,5 TOiS 134 W 4,5 TOiS 134 Ć 5 UA 321 W 4 UA 321 Ć 4,4 Angielski 231 Ć 5 Id studenta Studenci Student 123 Botas 143 Moton 134 Koton 321 Ficek 231 Bocek

161 Schemat bazy danych po normalizacji Przedmioty Oceny Pracownicy Przedmiot 1 * Przedmiot Studenci Id pracownika 1 * Id pracownika Id studenta * 1 Id studenta Nazwisko pracownika Typ oceny Student ocena

162 Podsumowanie Postać nieznormalizowana (0NF zero- th normal form) to tabela nie zawierająca ani jednej powtarzającej się grupy Pierwsza postać normalna (1NF first normal form) to relacja, w której każde przecięcie wiersza i kolumny zawiera tylko jedną wartość Druga postać normalna (2NF) oznacza relację w pierwszej postaci normalnej, w której każdy atrybut spoza klucza głównego jest od niego w pełni funkcyjnie zależny Trzecia postać normalna (3NF) oznacza relację w pierwszej i w drugiej postaci normalnej, w której żaden atrybut spoza klucza głównego nie jest od niego przechodnio zależny 162

163 Przysięga normalizacji Bez powtórzeń (0NF) Pola zależą od klucza (1NF) Od całego klucza (2NF) I niczego innego, tylko klucza (3NF) Tak mi dopomóż Codd