Bazy danych · Baza danych. Związki ... • Integracja danych – przechowywanie jednego...
Transcript of Bazy danych · Baza danych. Związki ... • Integracja danych – przechowywanie jednego...
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)
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
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
Cykl życia bazy
danych
Konceptualne projektowanie bazy danych
Planowanie bazy danych
Definicja systemu
Gromadzenie i analiza wymagań
Projektowanie bazy danych
Selekcja SZBD Projektowanie aplikacji
Logiczne projektowaniebazy danych
Fizyczne projektowanie bazy danych
Tworzenie prototypów Implementacja
Konwersjai 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, proce-dury, 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 (interakcjaz użytkownikami)
• Zarządza dostępem do danych (wprowadzanie, usuwanie i modyfikacja)
• System bazy danych = BD + SZBD
Moduł zarządzania transakcjami
Moduł zarządzania dostępem do danych
S
Z
B
D
użytkownik
schemat BD
dane
System BD
transakcja
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.
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ść (Atomicity)• Spójność (Consistency)• Izolacja (Isolation)• Trwałość (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 danymi3. 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.
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
Podręczniki
Historyczne Obyczajowe
Beletrystyka
Informatyka Fizyka
Bazy danych ArkuszeEdytory Optyka Magnetyzm
P. Beynon-Davies: Systemy baz danych
Model sieciowy
ModernizmGotyk
Architektura Malarstwo Rzeźba
Renesans Barok
AngliaPolska Francja Włochy
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ędemwykorzystywanego 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)
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)
Przykład relacjiPrzedmioty
Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345Prawo administracyjne 2 ADM 456
Cechy relacji1. Każda relacja w bazie ma jednoznaczną
nazwę2. Każda kolumna w relacji ma
jednoznaczną nazwę w ramach relacji3. Wszystkie wartości w kolumnie są tego
samego typu4. Porządek kolumn w relacji nie jest
istotny5. Każdy wiersz w relacji musi być różny6. Porządek wierszy nie jest istotny7. 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ładowcyNrPrac Nazwisko Status234 P. Beynon-Davies AS345 C.J. Date AD456 J. Ullmann PR666 B. Devil PE
Klucze kandydujące/głównePrzedmioty
Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345Prawo administracyjne 2 ADM 456
Klucze kandydujące/głównePrzedmioty
Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345Prawo administracyjne 2 ADM 456Informatyka 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
Wykładowcy
NrPrac Nazwisko Status
234 P. Beynon-Davies AS
345 C.J. Date AD456 J. Ullmann PR666 B. Devil PE
Przedmioty
Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234
Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345
Prawo administracyjne 2 ADM 456Informatyka 1 MAT null
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
SelekcjaPrzedmioty
Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345Prawo administracyjne 2 ADM 456
SelekcjaσSemestr=1 Przedmioty
Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234
ProjekcjaPrzedmioty
Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345Prawo administracyjne 2 ADM 456
ProjekcjaπNazwa,Semestr Przedmioty
Nazwa SemestrSystemy baz danych 1Podstawy programowania 1Informatyka 3Projektowanie sieci komputerowych 3Prawo administracyjne 2
Złączenia• równozłączenie• złączenie naturalne• złączenia zewnętrzne
– lewostronne– prawostronne– obustronne
RównozłączenieRównozłączenie relacji Przedmioty i Wykładowcy
Przedmioty EQUIJOIN Wykładowcy
Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko StatusSystemy baz danych
1 INF 234 234 P. Beynon-Davies
AS
Podstawy programowania
1 INF 234 234 P. Beynon-Davies
AS
Informatyka 3 ADM 345 345 C.J. Date ADProjektowanie sieci komputerowych
3 INF 345 345 C.J. Date AD
Prawo administracyjne
2 ADM 456 456 J. Ullmann PR
Złączenie naturalneZłączenie naturalne relacji Przedmioty i Wykładowcy
Przedmioty JOIN Wykładowcy
Nazwa Semestr KodKierunku NrPrac Nazwisko StatusSystemy baz danych
1 INF 234 P. Beynon-Davies
AS
Podstawy programowania
1 INF 234 P. Beynon-Davies
AS
Informatyka 3 ADM 345 C.J. Date ADProjektowanie sieci komputerowych
3 INF 345 C.J. Date AD
Prawo administracyjne
2 ADM 456 J. Ullmann PR
Złączenia zewnętrzneLewostronne złączenie zewnętrzne relacji Przedmioty i Wykładowcy
Przedmioty LEFT OUTER JOIN Wykładowcy
Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko StatusSystemy baz danych
1 INF 234 234 P. Beynon-Davies
AS
Podstawy programowania
1 INF 234 234 P. Beynon-Davies
AS
Informatyka 3 ADM 345 345 C.J. Date ADProjektowanie sieci komputerowych
3 INF 345 345 C.J. Date AD
Prawo administracyjne
2 ADM 456 456 J. Ullmann PR
Informatyka 1 MAT null null null null
Złączenia zewnętrznePrawostronne złączenie zewnętrzne relacji Przedmioty i Wykładowcy
Przedmioty RIGHT OUTER JOIN Wykładowcy
Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko StatusSystemy baz danych
1 INF 234 234 P. Beynon-Davies
AS
Podstawy programowania
1 INF 234 234 P. Beynon-Davies
AS
Informatyka 3 ADM 345 345 C.J. Date ADProjektowanie sieci komputerowych
3 INF 345 345 C.J. Date AD
Prawo administracyjne
2 ADM 456 456 J. Ullmann PR
null null null null 666 B. Devil PE
Złączenia zewnętrzneObustronne złączenie zewnętrzne relacji Przedmioty i Wykładowcy
Przedmioty FULL OUTER JOIN Wykładowcy
Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko StatusSystemy baz danych
1 INF 234 234 P. Beynon-Davies
AS
Podstawy programowania
1 INF 234 234 P. Beynon-Davies
AS
Informatyka 3 ADM 345 345 C.J. Date ADProjektowanie sieci komputerowych
3 INF 345 345 C.J. Date AD
Prawo administracyjne
2 ADM 456 456 J. Ullmann PR
Informatyka 1 MAT null null null nullnull null null null 666 B. Devil PE
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óżnicaWykładowcy
NrPrac Nazwisko Status
234 P. Beynon-Davies AS
345 C.J. Date AD456 J. Ullmann PR666 B. Devil PE
Administratorzy
NrPrac Nazwisko Status
234 P. Beynon-Davies AS
345 C.J. Date AD777 A. Angel PR1001 S. Jones UR1023 R. Evans SU
Suma, przecięcie, różnicaWykładowcy UNION Administratorzy
NrPrac Nazwisko Status
234 P. Beynon-Davies AS
345 C.J. Date AD456 J. Ullmann PR666 B. Devil PE777 A. Angel PR1001 S. Jones UR1023 R. Evans SU
Wykładowcy INTERSECT Administratorzy
NrPrac Nazwisko Status
234 P. Beynon-Davies AS
345 C.J. Date AD
Suma, przecięcie, różnicaWykł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 UR1023 R. Evans SU
Modelowanie związków encjiModel 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 rozpoznawalnyobiekt 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.
Personel WłaścicielPrywatny
Nazwa encji
Związki encjiZwią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.
Encja Biuro(biuroNr)
Encja Personel(pracownikNr)
B003
B007
r1
r2
r3
SG37
SG14
SA9
Związek Ma
Sieć semantyczna:Używając modelu związków encji:
Nazwa związku
“Biuro ma personel”
Biuro PersonelMa
Stopień związku (liczba uczestniczących w nim zbiorów encji)
“Właściciel prywatny posiada nieruchomość do wynajęcia”
WłaścicielPrywatny NieruchomośćPPosiada
BiuroPersonel Rejestruje
Klient
“Personel rejestrujeklienta w biurze”
InstytucjafinansowaKupujący Uzgadnia
Oferta
Prawnik
“Prawnik w imieniu kupującegowspieranego przez instytucjęfinansową uzgadnia ofertę”
Związek binarny:
Związek potrójny:
Związek poczwórny:
Związki rekurencyjne(związki, w których ten sam zbór encji występuje więcej niż jeden raz w różnych rolach)
Zarządza
MaPersonel Biuro
“Dyrektor zarządza biurem oddziału”
Nazwa roli
Biuro oddziałuDyrektor
“Biuro oddziału ma pracownika”
Nazwa roli
Biuro oddziałuPracownik
Nazwa roli
Nazwa roli“Personel (kierownik) kierujepersonelem (kierowanymi)”
Kieruje
Personel
Kierownik
Kierowany
Zbiór encji Personeluczestniczy 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.
Nazwy ról nie są na ogół wymagane, jeśli funkcje, jakie pełnią w związku uczestniczące w nim encje, są jednoznaczne.
Przykład encji powiązanych ze sobą poprzez dwa różne związki:
Atrybut (cecha encji lub związku)
Klucz główny
Atrybutwielowartościowy
Zarządza
Ma
Personel
pracownikNr (PK)imięNazwiskostanowiskopensja/liczba personelu
Biuro
biuroNr (PK)adres
ulicamiastokodPocztowy
telNr
Obszar doumieszczania
atrybutów Atrybutpochodny
Atrybut złożony
Atrybutjednowartościowy
• 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.
[1..3][1..*]
PK – primary keyPPK – partial primary keyAK – alternate key
Atrybuty związków
Graficzna reprezentacja związku Ogłasza:
Silne i słabe zbiory encji:
Nieruchomość
NieruchomośćNr
Gazeta
NazwaGazety
dataOgłoszeniakoszt
Ogłasza
“Gazeta ogłasza nieruchomość do wynajęcia”
Silna encja Słaba encja
Klient
klientNr (PK)imięNazwisko
imięnazwisko
telNr
Preferencje
typPreferencjimaksCzynsz
Określa
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.
Więzy strukturalneWię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 przedstawia-jąca dwa wystąpienia związku Personel Zarządza Biuro:
Krotność
“Każde biuro jest zarządzaneprzez jedną osobę z personelu”
“Osoba z personelu zarządzazero lub jednym biurem”
Zarządza Biuro
biuroNr
Personel
pracownikNr 1..1 0..1
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.
Zbiór encji Biuro(biuroNr)
Zbiór encji Personel(pracownikNr)
B003
B005
r1
r2
SG5
SG37
SL21
Związek Zarządza
Związek typu „jeden do wielu”
Sieć semantyczna przedstawiająca trzywystąpienia związku Personel NadzorujeNieruchomość:
“Każda nieruchomość dowynajęcia jest nadzorowana przez
pracownika”zero lub jednego
“Każdy pracownik nadzorujenieruchomości
do wynajęcia”zero lub więcej
Nadzoruje Nieruchomość
nieruchomośćNr
Personel
pracownikNr 0..1 0..*
Zbiór encji Nieruchomość(nieruchomośćNr)
Zbiór encji Personel(pracownikNr)
PG21
PG36
PA14PG4
r1
r3
r2
SG5
SG37
SA9
Związek Nadzoruje
Związek typu „wiele do wielu”
Encja Nieruchomość(nieruchomośćNr)
Encja Gazeta(nazwaGazety)
PG21
PG36
PA14
PG4
r1
r3r4
r2Głos
Gazeta
Poranny
Związek Ogłasza
“Każda nieruchomość dowynajęcia jest ogłaszanaw zero lub więcej gazet”
“Każda gazeta ogłaszanieruchomości
do wynajęcia”jedną lub więcej
Ogłasza Nieruchomość
nieruchomośćNr
Gazeta
nazwaGazety 0..* 1..*
Sieć semantyczna przedstawiająca czterywystąpienia związku Gazeta OgłaszaNieruchomość:
Więzy liczności i uczestnictwaLiczność – 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.
“Nie każdy pracownik zarządzabiurem” (uczestnictwo
opcjonalne dla personelu)
“Wszystkie biura są zarządzane” (uczestnictwo
obowiązkowe dla biur)
“Jedno biuro jest zarządzaneprzez jednego pracownika”
“Jeden pracownik zarządza jednym biurem”
Zarządza Biuro
biuroNr
Personel
pracownikNr 1..1 0..1
Liczność
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.
ProwadziMa OddziałPersonel Biuro1..* 1..1 1..1 1..*
Prowadzi MaOddział PersonelBiuro1..1 1..* 1..1 1..*
Zmiana strukturymodelu
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.
NadzorujeMa NieruchomośćPersonelBiuro1..1 1..* 0..1 0..*
NadzorujeMa NieruchomośćPersonelBiuro1..1 1..* 0..1 0..*
Dodanie związku Oferuje
Oferuje1..1 1..*
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łównymw 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
• 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 encji
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 definiowanedla kluczy obcych
• • Klucze obce tworzą klucz główny relacji
Związek M:N (2)
• 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 nadjest realizowany
przez
A co w przypadku gdybyśmy chcieli przechowywać
informację o liczbie godzin tygodniowo przepracowanych
przez pracownika nad określonym projektem ?
PROJEKT# nazwa_proj* data_rozpocz o data_zakoncz
Transformacja związków M:N
PRACOWNIK# id_pracownika* imię* nazwisko
pracuje nadjest realizowany
przez
Jest to przypadek atrybutu charakteryzującego
związek !
PROJEKT# nazwa_proj* data_rozpocz o data_zakoncz
Transformacja związków M:N
PRACOWNIK# id_pracownika* imię* nazwisko
pracuje nadjest realizowany
przez
PROJEKTY (Nazwa_projektuData_rozpocz Data_zakoncz
PRIMARY KEY NOT NULL NULL )
PRACOWNICY (Id_pracownikaImięNazwisko
PRIMARY KEY NOT NULL NOT NULL )
UDZIAŁY_W_PROJEKTACH (Id_pracownika REFERENCES Pracownicy(id_pracownika),Nazwa_projektu REFERENCESProjekty(Nazwa_projektu),Godziny NULLPRIMARY KEY (Id_pracownika, Nazwa_projektu) )
Atrybut związku
PROJEKT# nazwa_proj* data_rozpocz o data_zakoncz
Transformacja związków M:N
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)
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.
PRACOWNIK# id_prac
atrybuty_wspólne PRACOWNIK KRAJOWYatr_specyf_kraj
PRACOWNIKZAGRANICZNYatr_specyf_zagr
PRACOWNICY (Id_pracownika PRIMARY KEYatrybuty wspólne atr_specyf_kraj atr_specyf_zagr typ_prac
NULL NULLNOT NULL)
Transformacja hierarchii encji(schemat 1 – do jednej relacji)
Transformacja hierarchii encji(schemat 2 – do dwóch relacji)
Zasady transformacji:Dla każdej specjalizacji
tworzymy relację zawierającą atrybuty wspólne, atrybuty specyficzne danej specjalizacji i klucz podstawowy dziedziczony z generalizacji.
PRACOWNIK# id_prac atrybuty_wspólne PRACOWNIK
KRAJOWYatr_specyf_kraj
PRACOWNIK ZAGRANICZNYatr_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 )
Transformacja hierarchii encji(schemat 2 – do dwóch relacji)
Transformacja hierarchii encji(schemat 3 – do trzech relacji)
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.
PRACOWNICY (Id_pracownika PRIMARY KEY atrybuty_wspólne,typ_prac NOT NULL )
PRACOWNIK# id_prac atrybuty_wspólne PRACOWNIK
KRAJOWYatr_specyf_kraj
PRACOWNIK ZAGRANICZNYatr_specyf_zagr
PRACOWNICY_KRAJ (Id_pracownika PRIMARY KEY atr_specyf_kraj )PRACOWNICY_ZAGR (Id_pracownika PRIMARY KEY atr_specyf_zagr )
Transformacja hierarchii encji(schemat 3 – do trzech relacji)
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 relacyj-nego 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 organiza-cjach, 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 pozby-
wamy 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 danych2. 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)
Przedmiot Id studenta
Typ oceny
Student Ocena
TOiS 123 W Botas 4
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
Oceny
Przedmiot Id pracownika
Nazwisko pracownika
TOiS 23 Bos
UA 23 Bos
Angielski 34 Kusek
Przedmioty1
*
Tabele w 2NF
Przedmiot Id studenta
Typ oceny
Ocena
TOiS 123 W 4
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
Oceny
Id studenta
Student
123 Botas
143 Moton
134 Koton
321 Ficek
231 Bocek
StudenciPrzedmiot Id
pracownikaNazwisko pracownika
TOiS 23 Bos
UA 23 Bos
Angielski 34 Kusek
Przedmioty1 * 1*
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 pracownikajest 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)
Id pracownika Nazwisko pracownika
23 Bos
34 Kusek
Pracownicy
Przedmiot Id pracownika
Nazwisko pracownika
TOiS 23 Bos
UA 23 Bos
Angielski 34 Kusek
Przedmioty
Przedmiot Id pracownika
TOiS 23
UA 23
Angielski 34
Przedmioty 1*
Tabele w 3NF
Przedmiot Id studenta
Typ oceny
Ocena
TOiS 123 W 4
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
OcenyId studenta
Student
123 Botas
143 Moton
134 Koton
321 Ficek
231 Bocek
StudenciPrzedmiot Id
pracownika
TOiS 23
UA 23
Angielski 34
Przedmioty1* 1*
Id pracownika
Nazwisko pracownika
23 Bos
34 Kusek
Pracownicy1
*
Schemat bazy danych po normalizacji
Pracownicy
Id pracownika
Nazwisko pracownika
Oceny
Przedmiot
Id studenta
Typ oceny
ocena
Studenci
Id studenta
Student
Przedmioty
Przedmiot
Id pracownika
1
*1
*
1*
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