Bazy danych Andrzej Bobyk http://www.alfabeta.lublin.pl/bd/
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
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
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)
Piramida wiedzy
Kontekst bazy danych Związki z rzeczywistością Użytkownicy Baza danych Źródło danych
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 1900 1955 - zarządzanie zapisami na kartach perforowanych Maszyna Holleritha (bazująca na wynalazku Jacquarda z 1801 roku)
Historia zarządzania danymi 1955 1970 - programowane zarządzanie zapisami 1950 rok wynalezienie taśmy magnetycznej (na jednej mieściły się dane z ok. 10 000 kart perforowanych) praca wsadowa na plikach i rekordach (nie daje możliwości wychwycenia błędów aż do zakończenia wsadu)
Historia zarządzania danymi 1965 1970 - 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
Historia zarządzania danymi 1980 1995 - relacyjne zarządzanie danymi 1970 - model Codd a powszechne SZBD na komputery PC najczęściej stosowany model architektura klient-serwer 1995 - Obiektowe bazy danych dane aktywne oparte o mechanizmy dziedziczenia często przechowują dane różnych typów np.: głos, obraz, dane GIS itp.
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
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
Zalety komputerowych BD Szybkość wyszukiwania informacji Oszczędność miejsca Integralność danych Dostęp dla wielu użytkowników Wygodne interfejsy Zabezpieczenia dostępu
Przykłady BD Książki telefoniczne Systemy rezerwacji miejsc Katalogi biblioteczne Systemy finansowo-księgowe Systemy wspomagające zarządzanie Witryny WWW
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
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
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
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
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, 75-201 Koszalin ) ulica ( Dworcowa ), nr_domu ( 11 ), nr_lokalu ( 7 ), kod_pocztowy ( 75-201 ), miasto ( Koszalin ) jedno- vs. wielowartościowe nazwisko ( Kowalski ) vs. nr_telefonu ( 941234567, 501987654, 666333111 ) podstawowe vs. pochodne data_urodzenia ( 07.07.1997 ) vs. wiek ( 15 ) wiek = data_bieżąca data_urodzenia
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
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
Diagram związków encji (ERD)
Diagram związków encji
Rozszerzony model związków encji (EER) Specjalizacja/generalizacja hierarchia encji związki nadklasa-podklasa dziedziczenie atrybutów Agregacja i kompozycja
Funkcje BD Funkcje aktualizujące dokonują zmian na danych Funkcje zapytań wydobywają dane z bazy proste złożone
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
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.
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.
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.
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.
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.
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
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
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
użytkownik System BD transakcja S Z B D Moduł zarządzania transakcjami Moduł zarządzania dostępem do danych schemat BD dane
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
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
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
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
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.
Architektura SZBD (c.d.)
Architektura SZBD (c.d.)
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)
Cechy transakcji (ACID) Niepodzielność Spójność Izolacja Trwałość (Atomicity) (Consistency) (Isolation) (Durability) Transakcja jest funkcją aktualizującą
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
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
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.
Chronologia powstawania modeli danych
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
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
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.
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.
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.
Model hierarchiczny Książki Beletrystyka Podręczniki Historyczne Obyczajowe Informatyka Fizyka Edytory Bazy danych Arkusze Optyka Magnetyzm P. Beynon-Davies: Systemy baz danych
Przykład 1: System plików UNIX/Linux/DOS/Windows
Przykład 2: Rejestr systemu Windows
Przykład 3: Usługi katalogowe (NDS/eDirectory, LDAP/ActiveDirectory)
Model sieciowy Architektura Malarstwo Rzeźba Gotyk Renesans Barok Modernizm Polska Francja Włochy Anglia Leonardo da Vinci: Mona Lisa
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ń
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, &
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),
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,
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).
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)
Relacyjna i obiektowa struktura aplikacji
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
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)
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
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)
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
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ą)
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ą
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
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
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
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
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
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
Utrzymywanie integralności referencyjnej 1. Usuwanie ograniczone (podejście ostrożne) 2. Usuwanie kaskadowe (podejście ufne) 3. Wstawianie null (podejście wyważone)
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.
Algebra relacyjna selekcja (ograniczenie) projekcja (rzut) złączenia iloczyn kartezjański suma przecięcie różnica iloraz
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
Selekcja σ Semestr=1 Przedmioty Nazwa Semestr KodKierunku NrPrac Systemy baz danych 1 INF 234 Podstawy programowania 1 INF 234
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
Projekcja π Nazwa,Semestr Przedmioty Nazwa Systemy baz danych Semestr 1 Podstawy programowania 1 Informatyka 3 Projektowanie sieci komputerowych 3 Prawo administracyjne 2
Złączenia równozłączenie złączenie naturalne złączenia zewnętrzne lewostronne prawostronne obustronne
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 234 234 P. Beynon- Davies 1 INF 234 234 P. Beynon- Davies Informatyka 3 ADM 345 345 C.J. Date AD Projektowanie sieci komputerowych Prawo administracyjne 3 INF 345 345 C.J. Date AD 2 ADM 456 456 J. Ullmann PR AS AS
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
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 234 234 P. Beynon- Davies 1 INF 234 234 P. Beynon- Davies Informatyka 3 ADM 345 345 C.J. Date AD Projektowanie sieci komputerowych Prawo administracyjne 3 INF 345 345 C.J. Date AD 2 ADM 456 456 J. Ullmann PR Informatyka 1 MAT null null null null AS AS
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 234 234 P. Beynon- Davies 1 INF 234 234 P. Beynon- Davies Informatyka 3 ADM 345 345 C.J. Date AD Projektowanie sieci komputerowych Prawo administracyjne 3 INF 345 345 C.J. Date AD 2 ADM 456 456 J. Ullmann PR null null null null 666 B. Devil PE AS AS
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 234 234 P. Beynon- Davies 1 INF 234 234 P. Beynon- Davies Informatyka 3 ADM 345 345 C.J. Date AD Projektowanie sieci komputerowych Prawo administracyjne 3 INF 345 345 C.J. Date AD 2 ADM 456 456 J. Ullmann PR Informatyka 1 MAT null null null null null null null null 666 B. Devil PE AS AS
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
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
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
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
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.
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
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
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ę
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
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
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
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 (*:*).
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 1..1 0..1 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.
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 0..1 0..* Nieruchomość nieruchomośćnr
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
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 1..1 0..1 biuronr Wszystkie biura są zarządzane (uczestnictwo obowiązkowe dla biur) Nie każdy pracownik zarządza biurem (uczestnictwo opcjonalne dla personelu) Uczestnictwo
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..* 1..1 1..1 1..* Biuro Oddział Prowadzi Biuro 1..1 1..* 1..1 1..* Ma Personel Zmiana struktury modelu
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 1..1 1..* 0..1 0..* Nieruchomość Biuro Ma Nadzoruje Personel 1..1 1..* 0..1 0..* Nieruchomość 1..1 1..* Oferuje Dodanie związku Oferuje
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
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
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
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
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
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
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
Związek binarny 1:1 (1)
Związek binarny 1:1 (2)
Związek binarny 1:1 (3)
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
Związek 1:M (2)
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
Związek M:N (2)
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
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?
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!
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
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.
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.
Związek unarny (1)
Związek unarny (2)
Związki tercjarne
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
Transformacja hierarchii encji (schemat 1 do jednej relacji)
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.
Transformacja hierarchii encji (schemat 2 do dwóch relacji)
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.
Transformacja hierarchii encji (schemat 3 do trzech relacji)
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.
Transformacja związków wyłącznych - schemat 1
Transformacja związków wyłącznych - schemat 2
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
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
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). 1974 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
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
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
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)
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
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)
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
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 Ć
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
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
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 Ć
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
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
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
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
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
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
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
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
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