Komputerowy montaż dźwięku i obrazu

BAZY DANYCH
model relacyjny
Opracował:
dr inż. Piotr Suchomski
Relacyjny model danych

Relacyjny model danych posiada trzy
podstawowe składowe:
– relacyjne struktury danych
– operatory algebry relacyjnej, które umożliwiają
tworzenie, przeszukiwanie i modyfikowanie danych
– ograniczenia (więzy) integralnościowe jawnie lub
niejawnie określającymi możliwe/dopuszczalne
wartości danych.
Relacja
Podstawową strukturą danych modelu
relacyjnego jest relacja, będąca podzbiorem
iloczynu kartezjańskiego wybranych domen i
przedstawiana w postaci dwuwymiarowej
tabeli. W tym ujęciu pojęcia relacji (ang.
relation) i tabeli (ang. table) są synonimami.
 Pojęcie relacji używane jest na poziomie teorii
baz relacyjnych i modelu konceptualnego, a
pojęcie tabeli na poziomie realizacji fizycznej.

Relacja
Relacja (bazodanowa) jest to dowolny podzbiór
produktu kartezjańskiego skończonej liczby
dziedzin prostych.
 Dziedzina jest prosta, jeili jej elementy są
nierozkładalne (atomowe).
 Niech D1, D2,…,Dn są to dziedziny proste,
0<n<∞ , D1 x D2 x… x Dn – to produkt
kartezjański tych dziedzin prostych: zbiór
wszystkich krotek (d1, d2,…,dn ) takich, że
d1D1, d2D2,…, dnDn,
 Wartość n określa stopień relacji

Relacja
Poszczególne pozycje krotek relacji
nazywamy atrybutami relacji.
 Atrybuty relacji muszą być atomowe.
Spełnienie tego wymogu jest warunkiem
aby relacja była w pierwszej postaci
normalnej (1NF).

Właściwości relacji
wszystkie jej krotki są różne,
 wszystkie jej atrybuty są różne,
 kolejność krotek nie ma znaczenia i w
ogólności nie jest ona znana,
 kolejność atrybutów nie ma znaczenia,
 wartości atrybutów są niepodzielne
(atomowe), tj. nie mogą być zbiorem
wartości.

Schemat relacji

Nazwa relacji oraz zbiór jej atrybutów,
umieszczonych wnawiasie, nazywany jest
schematem relacji. Atrybuty w schemacie
relacji nie są listami ale zbiorami. Jednak dla
porządku ustala się standardowy porządek
atrybutów i jest on wiążący w całym projekcie.
Pracownik(nr_ewid, imie, nazwisko, stanowisko, dział)
Samochód(nr_rej, marka, poj_silnika)

Projekt relacyjnej bazy danych może składać się
z jednego lub kilku schematów relacji. Zbiór
schematów relacji nazywany jest schematem
relacyjnej bazy danych.
Instancja relacji
Relacja nie jest tworem statycznym, gdyż
zmienia się w czasie. Zmiany te dotyczą
poszczególnych krotek. Mogą pojawiać się
nowe krotki, inne mogą być usuwane lub
modyfikowane są wartości poszczególnych
atrybutów. Stan relacji w danej chwili nazywany
jest instancją relacji.
 W relacji zmianie może ulec również jej
schemat, jednak takie operacje są bardzo
kosztowne i zdarzają się rzadko.

Intensja i ekstansja relacji

Z punktu widzenia semantyki (znaczenia)
rozróżnia się dwa pojęcia - pojęcie intensji
relacji oraz ekstensji relacji.
 Intensja relacji odpowiada znaczeniu relacji predykat związany z relacją stanowi element jej
intensji. Na intensję relacji mogą poza tym
składać się inne jej własności.
 Ekstensja relacji jest zbiorem krotek
spełniających własności, które stanowią intensję
relacji. Własności te nazywa się warunkami
integralności.
Intensja a ekstensja relacji
Dla relacji R(PRZEDMIOT, DZIEŃ, GODZINA, SALA,
WYKŁADOWCA):
- intensję relacji wyrażają następujące warunki
integralności:
1. predykat związany z relacją R mówi o tym, że
„wykładowca w prowadzi zajęcia z przedmiotu p w dniu
d, o godzinie g, w sali s”;
2. dziedzina atrybutu GODZINA jest zbiorem liczb
całkowitych z przedziału <7, 24>;
3. dany wykładowca moŜe znajdować się o określonej
godzinie tylko w jednej sali.
- ekstensję relacji R stanowi zbiór krotek spełniających
własności (1), (2), (3).
Definicja zależności funkcyjnej
Jeżeli dwie krotki relacji R są zgodne dla
atrybutów A1A2…An, to muszą być również
zgodne w pewnym innym atrybucie B.
 Zależność tą można zapisać:
A1A2…An -> B,
A1A2…An określają funkcyjnie B
 Jeśli zbiór atrybutów A1,A2,…,An określa więcej
niż jeden atrybut B to można skrótowo zapisać:
A1A2…An -> B1B2…Bm

Zależność funkcyjna
Klucze relacji

Atrybut lub zbiór atrybutów {A , A ,..., A } tworzy
klucz relacji jeśli:
1
2
n
– wszystkie pozostałe atrybuty relacji są funkcyjnie
zależne od tych atrybutów (nie może się zdarzyć aby
dwie różne krotki relacji R były zgodne dla
wszystkich atrybutów A , A ,..., A )
– Nie istnieje taki podzbiór właściwy zbioru {A , A ,...,
A }, od którego pozostałe atrybuty relacji R są
zależne funkcyjnie, tzn. klucz musi być minimalny
1
2
n
1
n

Klucze w diagramach E/R nie spełniają
drugiego wymagania
2
Nadklucze
Nadklucz – zbiór atrybutów, który zawiera klucz.
 Każdy klucz jest nadkluczem.


Wykrywanie kluczy w relacji
Reguła 1
– Jeśli relacja pochodzi z przekształcenia zbioru encji, to
jej kluczem są atrybuty kluczowe tego zbioru encji

Reguła 2 (dotyczy związków binarnych)
– Jeśli związek jest typu wiele do wiele, to klucze obu
zbiorów encji objętych związkiem tworzą zbiór
atrybutów klucza R
– jeśli związek ze zbioru encji E1 do zbioru encji E2 jest
typu wiele do jeden, to atrybuty klucza E1 stają
się kluczem R, ale atrybuty klucza E2 nie wchodzą do
klucza relacji R.
– Jeśli związek jest typu jeden do jeden, to atrybuty
klucza któregokolwiek ze zbiorów mogą być kluczem
R. W tej sytuacji nie ma tylko jednego klucza.
Klucze relacji - notacja
Klucze główne:
Książki(ISBN, tytuł, autor, rok)
Klienci(NIP, Nazwisko, adres, status)
Książki(ISBN, tytuł, autor, rok)
 Klucze obce:
Książki(ISBN, tytuł, autor, rok, id_wyd REF
Wydawnictwo)
Klucz obcy
Wydawnictwo(ident, nazwa, miasto)
 Klucz obcy może wchodzić w skład klucza
głównego.

Relacje a zbiory encji
Reprezentacja zbiorów encji
Każdy zbiór encji zamieniany jest na relację, której
klucz główny jest równy kluczowi zbioru encji.
 Reprezentacja związków

– Związki 1:1 – reprezentowane są przez klucz obcy
wstawiany do jednej z relacji.
– Związki 1:n – reprezentowane są przez klucz obcy
wstawiany do relacji po stronie n.
– Związki n:m – reprezentowane są przez dodatkową
relację, której klucz główny powstaje ze złożenia
kluczy głównych związanych zbiorów encji.
Relacje a zbiory encji

Związek może być reprezentowany przez
oddzielną relację również w przypadku
związków 1:1 i 1:n co zapewni większą
elastyczność i zapewni symetrię, natomiast
wadą jest to, że powstaje dodatkowa relacja.
Relacje a zbiory encji - przykład
Data
PESEL
Mężczyźni

PES_M
PES_K
Małżeństwo
PESEL
Kobiety
Schemat relacyjnej bazy danych:
Mężczyźni(PESEL, imię, nazwisko,…)
Kobiety(PESEL, imię, nazwisko,…)
Małżeństwo(PES_M REF Mężczyźni, PES_K
REF Kobiety, Data)
Anomalie aktualizacji
Anomalie pojawiają się wtedy gdy do jednej
relacji próbujemy włączyć zbyt wiele danych.
 Podstawową anomalią jest redundancja danych.
W wielu krotkach pojawiają się te same dane.
 Problem modyfikacji relacji obarczonej anomalią
polega na tym, że zmieniana wartość atrybutu
musi być zmieniona we wszystkich krotkach
relacji, w których ta wartość występuje.
 Problem usuwania danych. Wraz z usuwaną
krotką można usuną dane, które mogą być
przydatne. Istnieje również zagrożenie spójności
i integralności danych.

Dekompozycja relacji

Właściwym sposobem eliminacji anomalii jest
dekompozycja relacji. Polega ona na podziale
atrybutów relacji R na dwa nowe schematy
relacji. Reguła dekompozycji dotyczy również
krotek relacji R (podział danych do nowych
relacji), dzięki operacji rzutowania krotek R.
Dekompozycja relacji

Relację R o schemacie R(A1,A2,…An) dekomponujemy
między 2 relacje S i T o schematach S(B1,B2,…Bn) i
T(C1,C2,…Cn) według następujących reguł:
– {A1,A2,…,An} = {B1,B2,…Bn}{C1,C2,…,Cn},
– Krotki relacji S powstają przez rzutowanie wszystkich
krotek relacji R na zbiór atrybutów {B1,B2,…,Bm}.
Oznacza to, że z każdej krotki t z bieżącej instancji
relacji R pobieramy wartości atrybutów B1,B2,…,Bm, i
tworzymy w ten sposób krotkę relacji S, należącą do
jej bieżącej instancji. Ponieważ relacje są zbiorami,
więc taką samą krotkę S można uzyskać z
rzutowania różnych krotek relacji R. W takich
przypadkach w S umieszcza się tylko jedną kopię
każdej krotki.
Dekompozycja relacji
– W podobny sposób z rzutowania krotek bieżącej
instancji relacji R na zbiór atrybutów {C1,C2,…,Ck}
otrzymuje się krotki relacji T.
Normalizacja
PARTICIPANTS(IDENT, NAME, CITY, INHAB, COURSE, GRADE)
Student o identyfikatorze IDENT i nazwisku NAME, pochodzący z
miasta CITY, o liczbie mieszkańców INHAB, ukończył kurs
COURSE, z oceną GRADE.
Normalizacja

Tablica PARTICIPANTS wykazuje wiele anomalii
ze względu na redundancję danych.
– Chcąc zmienić liczbę mieszkańców trzeba to zrobić w
wielu wierszach (aby zachować integralność)
– Usuwając rekord danych o kursancie Rodin usuwane
są również dane o liczbie mieszkańców miasta
Aberdeen.
– Chcąc dodać informacje o innym kursie, który ukończył
kursant trzeba też dodać dane, które w bazie już
istnieją.

Celem normalizacji jest usunięcie
redundancji tak, by każda informacja była
przechowywana w bazie tylko raz.
Zależności funkcyjne – cd.
Zbiór atrybutów B jest w pełni funkcyjnie
zależny od zbioru atrybutów A w schemacie R,
jeżeli A→B i nie istnieje podzbiór A’ ⊂ A taki, że
A’→B.
 Zbiór atrybutów B jest częściowo funkcyjnie
zależny od zbioru atrybutów A w schemacie R,
jeżeli A → B i istnieje podzbiór A’ ⊂ A taki, że
A’→B.

Druga postać normalna
Relacja jest w 2NF jeżeli jest w pierwszej
postaci normalnej (1NF) każdy atrybut
niekluczowy jest w pełni funkcyjnie zależny od
klucza głównego.
 Relacja PARTICIPANT nie jest w 2NF gdyż
zawiera niepełne zależności funkcyjne:

– IDENT->NAME
– IDENT->CITY
– IDENT->INHAB
Druga postać normalna – cd.

Relację PARTICIPANT można sprowadzić do
2NF dokonując dekompozycji (projekcji) na
dwie relacje:
PART_COURSE(IDENT REF PART_DATA, COURSE,GRADE)
PART_DATA(IDENT, NAME, CITY, INHAB)
Druga postać normalna

Relacja PART_DATA nadal posiada
redundancję. Jeśli kliku studentów pochodzi z
tego samego miasta to w bazie powtarzać się
będą dane dotyczące liczby mieszkańców.
Powodem tego jest to, że atrybut INHAB zależy
funkcyjnie od atrybutu niekluczowego CITY.
Zależności funkcyjne – cd.

Zbiór atrybutów B jest przechodnio funkcyjnie
zależny od zbioru atrybutów A w schemacie
relacji R, jeżeli A→B i istnieje zbiór atrybutów C,
nie będący podzbiorem żadnego klucza
schematu relacji R taki, że zachodzi A→C i
C→B. Zależność funkcyjna A→B jest
zależnością przechodnią jeżeli istnieje podzbiór
atrybutów taki, że zachodzi A→C, C→B i nie
zachodzi C→A lub B→C.
Trzecia postać normalna

Relacja jest w trzeciej postaci normalnej (3NF)
jeśli:
– Jest w 2NF,
– Żaden atrybut niekluczowy nie zależy przechodnio od
klucza głównego.

Relację PART_DATA można sprowadzić do
3NF przez dekompozycję na dwie relacje:
PART_ID(IDENT, NAME, CITY REF CITIES)
CITIES(CITY, INHAB)
Trzecia postać normalna
Postać normalna Boyce’a Codda
Wyznacznik to atrybut relacji (może być
złożony), od którego w pełni funkcjonalnie
zależy inny atrybut tej relacji.
 Relacja jest w normalnej Boyce’a Codda (BCNF)
wtedy i tylko wtedy, gdy każdy wyznacznik jest
kluczem kandydującym.
 Postać BCNF jest silniejsza niż 2NF i 3NF.

Zależności wielowartościowe

Niech istnieje relacja R i jej atrybuty A, B, C.
Pomiędzy atrybutami A i B zachodzi zależność
wielowartościowa (A->->B) wtedy i tylko wtedy,
gdy dla każdej wartości A istnieje zbiór
możliwych wartości B i ten zbiór nie zależy od C
Zależności wielowartościowe

Obie tablice są w 3NF (klucz główny składa się ze
wszystkich atrybutów).Ale:
– W obu tablicach istnieje redundancja danych
– SSN->->LANGUAGE (bo znajomość języków nie zależy od
uprawianych sportów),
– SSN->->SPORT (bo uprawiane sporty nie zależą od znanych
języków)
Czwarta postać normalna

Relacja jest w czwartej postaci normalnej (4NF)
jeśli jest w 3NF oraz nie zawiera dwóch lub
więcej zależności wielowartościowych.
 Relację PERSONS można sprowadzić do 4NF
przez dekompozycję na dwie relacje:
PER_LAN(SSN, LANGUAGE)
PER_SPORT(SSN, SPORT)
Normalizacja - podsumowanie
Dobrze zaprojektowana relacja składa się klucza
głównego (prosty lub złożony) i z pewnej liczby
niezależnych od siebie atrybutów, które tylko
zależą od całego klucza głównego.
 W każdym przypadku normalizacja relacji
wymaga jej dekompozycję na kilka innych relacji
drogą projekcji.

Reguły Codd’a
Edgar Frank Codd – znany brytyjski informatyk,
zasłużony w rozwoju teorii relacyjnych baz
danych.
 Opublikował 12 reguł (właściwie 13), których
stopień spełnienia określa poziom relacyjności
bazy danych.

12 reguł Codd’a
0. Reguła zerowa. Aby można było uznać dany
system za system zarządzania relacyjnych
baz danych, musi on wykorzystywać
(wyłącznie) relacyjne mechanizmy do
zarządzania bazą danych.
1. Reguła informacyjna. Wymaganie, aby
wszystkie informacje zawarte w bazie danych
były przedstawiane w jeden i tylko jeden
sposób, mianowicie za pomocą wartości
umieszczanych w kolumnach w obrębie
wierszy tabel
12 reguł Codd’a
2. Reguła gwarantowanego dostępu: ta reguła
jest zasadniczo powtórzeniem wymagania
dotyczącego kluczy podstawowych. Stanowi
ona, że każda poszczególna wartość
skalarna w bazie danych musi mieć
zapewnioną możliwość logicznego
adresowania, wykorzystując nazwę
zawierającej ją tabeli, nazwę zawierającej ją
kolumny oraz wartość klucza podstawowego
zawierającego ją wiersza
12 reguł Codd’a
3. Uporządkowana obsługa wartości NULL:
wymaga się, aby DBMS obsługiwał
reprezentację brakujących informacji oraz
informacji nieadekwatnych, tzn. odmiennych
od wszystkich wartości prawidłowych,
niezależnie od typu danych. Przyjmuje się, że
DBMS musi obsługiwać taką reprezentację w
uporządkowany sposób.
12 reguł Codd’a
4. Aktywny katalog dostępny na bieżąco, oparty
na modelu relacyjnym: wymaga się, aby
system obsługiwał wbudowany katalog
relacyjny z bieżącym dostępem dla
uprawnionych użytkowników, używających
ich zwykłego języka zapytań.
12 reguł Codd’a
5. Reguła dotycząca pod-języka obsługi danych o
pełnych możliwościach: system musi obsługiwać
przynajmniej jeden język relacyjny, który:
(a) charakteryzuje się liniową składnią;
(b) może być używany zarówno w trybie
interaktywnym, jak i w obrębie programów
aplikacyjnych;
(c) obsługuje operacje definiowania danych (łącznie
z definiowaniem perspektyw), operacje
manipulowania danymi (aktualizację i wyszukiwanie),
ograniczenia związane z bezpieczeństwem i
integralnością oraz operacje zarządzania
transakcjami (rozpoczynanie, zapis zmian i ponowny
przebieg).
12 reguł Codd’a
6. Reguła aktualizacji perspektyw: wszystkie
perspektywy, które teoretycznie dają się
aktualizować, muszą być aktualizowane
przez system.
7. Polecenia wstawiania, aktualizacji oraz
usuwania w języku wysokiego poziomu:
wymaga się, aby system obsługiwał operatory
INSERT, UPDATE oraz DELETE dotyczące
całych zbiorów.
12 reguł Codd’a
8. Fizyczna niezależność danych. Programy za pomocą
których manipuluje się bazą danych są niezależne od
tego jak baza danych jest fizycznie zorganizowana
9. Logiczna niezależność danych. Programy, za pomocą
których BD jest przetwarzana są niezależne od tego
jak baza danych jest zorganizowana wewnętrznie.
10. Zasady, które artykułują semantyczny stopień
integralności, powinny być możliwe do opisania
wewnątrz języka zapytań DBMS. Możliwe powinno
być również zmagazynowanie ich wewnątrz katalogu
systemu BD i narzucanie przez sam system BD
12 reguł Codd’a
11. Relacyjna BD powinna działać tak samo ,
niezależnie od tego , czy pracuje na
pojedynczej maszynie czy jest udostępniana
sieciowo.
12. Reguła nie prowadzenia "działalności
wywrotowej": jeśli system jest wyposażony w
interfejs niskiego poziomu (operacje na
pojedynczych rekordach), nie może być użyty
do prowadzenia działalności wywrotowej (np.
omijania zabezpieczeń relacyjnych lub
ograniczeń integralnościowych).