05-Model relacyjny.pdf

(323 KB) Pobierz
Relacyjne bazy danych
System zarządzania relacyjną bazą danych
jest to system mający
co najmniej następujące cechy:
Model relacyjny
• użytkownik
postrzega
dane jako
tabele
•
operatory
jakimi użytkownik dysponuje - tj. instrukcje do
przetwarzania danych - generują z istniejących tabel nowe tabele i
obejmuje co najmniej operatory:
Projektowanie i Zarządzanie Bazami Danych
09/05
–
wyboru
SELECT - wybiera określone wiersze tabeli
–
rzutu
PROJECT - wybiera określone kolumny z tabeli
–
złączenia
JOIN - łączy dwie tabele na podstawie tych samych
wartości we wspólnej kolumnie
Relacyjne bazy danych
Cechy:
•
wynik
realizacji każdego z powyższych poleceń jest
tabelą,
która
może stanowić dane wejściowe dla kolejnego polecenia - tabele
będące wynikami operacji nie muszą być tabelami fizycznie
istniejącymi- mamy na myśli raczej koncepcyjny punkt widzenia
• poszczególne operacje przetwarzają
całe zbiory rekordów,
nie
pojedyncze rekordy - zarówno dane wejściowe jak i wyjściowe są
całymi tabelami -
główny wyróżnik systemów relacyjnych
• wszystkie wartości danych są
atomowe
- każdy element tabeli jest
pojedynczą wartością, a nie ich grupą
• prócz tabel
bazowych (podstawowych),
fizycznie istniejących w
bazie, istnieją tabele
pochodne
będące wynikiem wykonania operacji
na pozostałych tabelach - nie muszą być przechowywane
•
perspektywa
to nazwana tabela
pochodna
Relacyjne bazy danych - przykład
• tabela
Dostawcy:
każdy dostawca posiada jednoznaczny numer
dostawcy, nazwisko, ocenę lub status i siedzibę; zakładamy, że
dostawca jest ulokowany dokładnie w jednym mieście
• tabela
Części:
każda część posiada jednoznaczny numer części, nazwę,
kolor, ciężar w kilogramach i miejsce przechowywania; zakładamy, że
każdy rodzaj części posiada dokładnie jeden kolor i jedno miejsce
przechowywania
• tabela
Dostawy:
jest w pewnym sensie łączy dwie poprzednie tabele;
zawiera numer dostawcy, numer części i wielkość dostawy
• tabele
Dostawcy
i
Części
mogą być uważane za encje, natomiast tabela
Dostawy
opisuje związek między nimi
Definicja danych
- baza dostawcy i części
Wartości S# i P#
jednoznacznie identyfikują
dostawców i części. Zakładamy, że w
dostawach istnieje tylko jedna dostawa
wybranej części od konkretnego dostawcy.
Przykład – baza dostawcy i części
S
SP
P
1
Model relacyjny – podstawowe pojęcia
Dziedziny
Dziedziną
danego atrybutu nazywamy zbiór wartości skalarnych
(atomowych) będących tego samego typu co dany atrybut oraz
posiadających odpowiedni dla niego zakres wartości.
Np.: dziedzinę dla atrybutu QTY (wielkości dostaw) tabeli Dostawy
możemy zdefiniować jako liczby całkowite z zakresu <0..10000>.
Porównania ograniczone dziedzinami.
Części.P# = Dostawy.P#
Części.WEIGHT=Dostawy.QTY
Oba powyższe porównania są poprawne z matematycznego p. widzenia.
Pierwsze
porównuje dwa atrybuty
o wspólnej dziedzinie,
natomiast
drugie
porównuje dwie wielkości liczbowe
o różnych dziedzinach,
co oznacza, że argumenty te są nieporównywalne (semantycznie).
Relacje, a teoria mnogości
Relacja
to podzbiór iloczynu kartezjańskiego listy dziedzin.
Dziedzina
to zbiór wartości.
Iloczyn kartezjański dziedzin
D1, D2,… Dk, zapisywany jako D1 x D2 x… x
Dk, jest zbiorem wszystkich k-krotek (v1, v2, …, vk), takich, że v1 należy do
D1, v2 należy do D2 itd.
Przykład:
k = 2, D1 = {0, 1}, D2 = {a, b, c}
to
D1 x D2 = {(0, a), (0, b), (0, b), (1, a), (1, b), (1, c) }
Relacja
to dowolny podzbiór iloczynu kartezjańskiego jednej lub więcej dziedzin.
Schemat relacji
to zbiór nazw atrybutów związanych ze zbiorem dziedzin.
wartością relacji.
Relacje
Zmienna relacji
jest to
nazwana zmienna,
której wartość w danej chwili jest
Relacja
R określona na zbiorze dziedzin D1, D2, ..., Dn składa się z:
•
•
nagłówka
(nazwy kolumn i ich typy): jest to ustalony zbiór par
{<
nazwa-atrybutu : nazwa-dziedziny
>,…}
treści:
jest to zbiór krotek, z których każda jest zbiorem par
{<
nazwa-atrybutu : wartość
>,…}
dla każdego atrybutu A
j
dla
1
j
n
w każdej krotce istnieje jedna para
dla
1
i
m
gdzie m jest liczbą krotek w zbiorze oraz
v
ij
D
j
Liczby m i n są nazywane odpowiednio
liczebnością i stopniem
relacji R.
A
j
:
v
ij
Relacje - przykład
Tabele nie są relacjami
w sensie poprzedniej definicji. Można je jednak
traktować jako obraz relacji - o ile ustalimy jak czytać taki obraz.
Przeczytajmy tabelę dostawców:
Nagłówek:
Treści: tabela to zbiór wierszy, każdy
wiersz możemy interpretować jako
zbiór par, np. wiersz
Relacje - własności
•
nie ma podwójnych krotek:
relacja jest zbiorem, więc nie może
zawierać powtórzeń - tabela może - krotki są
rozróżnialne
i można
wyznaczyć
klucz główny
•
krotki nie są uporządkowane:
relacje są zbiorami; tabele są
uporządkowane
•
atrybuty nie są uporządkowane:
krotki relacji są zbiorami par; tabele
posiadają uporządkowanie kolumn
interpretujemy jako:
•
wszystkie wartości atrybutów są atomowe:
jest to konsekwencją
tego, że dziedziny posiadają tylko wartości atomowe - o relacji, która
nie zawiera grup wielokrotnych
(wartości nieatomowych) mówimy,
że
jest w I postaci normalnej
2
Relacje - rodzaje
•
nazwana:
jest zmienną relacji, która została zdefiniowana dla danego
DBMS
•
podstawowa:
relacja nazwana, która nie jest relacją pochodną - jest
autonomiczna
•
pochodna:
relacja zdefiniowana za pomocą wyrażeń relacyjnych, tj.
przez operacje na innych relacjach nazwanych, a w końcu przez relacje
podstawowe
•
wyprowadzalna:
relacja, którą można otrzymać ze zbioru nazwanych
relacji za pomocą jakiegoś wyrażenia relacyjnego; każda nazwana
relacja jest relacją wyprowadzalną ale nie odwrotnie
•
perspektywa:
nazwana relacja pochodna - jest wirtualna tj. w systemie
reprezentowana jedynie przez inne relacje nazwane
Relacje - rodzaje – c.d.
•
migawka:
podobnie jak perspektywa, jest nazwaną relacją pochodną, z
tym, że jest rzeczywista (nie wirtualna) - czasem zwane raportami
•
zachowana:
relacja wyprowadzalna, która jest zapisana w pamięci
fizycznej
Reguły poprawności:
są to wyrażenia logiczne (predykaty) opisujące
poprawne krotki relacji. DBMS posiadający reguły poprawności
sprawdza je przed każdą aktualizacją bazy. W przypadku niespełnienia
reguł aktualizacja zostaje odrzucona.
Klucze kandydujące
Niech
R
będzie relacją.
Klucz kandydujący
relacji R jest podzbiorem K
zbioru atrybutów relacji R, posiadającym własności:
•
jednoznaczności:
żadne dwie różne krotki relacji R nie mają tej samej
wartości dla K
•
nieredukowalności:
żaden właściwy podzbiór K nie posiada
własności jednoznaczności
Przykłady
• określić klucze kandydujące w bazach: Dostawcy, Części, Uczelnia,
• jakie klucze kandydujące posiada tabela
Pierwiastki
przechowująca
układ okresowy pierwiastków (pola: nazwa, symbol, liczbę atomową)
Każde pole jednoznacznie identyfikuje pierwiastek, więc każde pole jest
kluczem kandydującym.
Klucze główne i alternatywne
Kluczem głównym
danej relacji nazywamy wybrany jej klucz
kandydujący. Pozostałe klucze kandydujące tabeli nazywamy
kluczami alternatywnymi.
W tabeli
Pierwiastki
jako klucz główny możemy wybrać dowolne
pole tabeli np. liczbę atomową, pozostałe pola będą wówczas
kluczami alternatywnymi.
Uwaga:
Jeżeli dana tabela posiada wiele kluczy kandydujących, to wybór
klucza głównego jest w zasadzie
dowolny.
Wybór klucza
głównego powinien mieć na względzie
prostotę rozwiązania,
jednak kwestia ta leży
poza zakresem modelu relacyjnego.
Klucze obce
Klucz obcy
relacji podstawowej R
2
jest to podzbiór FK, zbioru atrybutów
relacji R
2
, taki że:
• istnieje relacja podstawowa R
1
(R
1
i R
2
nie muszą być różne) z
kluczem kandydującym CK oraz
• w każdej chwili każda wartość FK w aktualnej wartości relacji R
2
jest
taka sama, jak wartość CK w pewnej krotce aktualnej wartości relacji
R
1
.
Przykład
• W tabeli
Dostawy
bazy
Dostawcy
i
Części
zbiory {S#} oraz {P# }są
przykładami kluczy obcych tabeli
Dostawy.
Zbiory te są jednocześnie
kluczami kandydującymi tabel
Dostawcy
i
Części.
S
Klucze obce - przykład
P
Dostawcy
Części
SP
Wpis do SP nie może istnieć bez
powiązanych wierszy z S i P
zawierających wartości atrybutów
przynależącymi do klucza obcego
Dostawy
3
Klucze obce - uwagi
• każda wartość danego klucza obcego
musi pojawić
się jako wartość
odpowiedniego klucza kandydującego; sytuacja odwrotna nie jest
wymagana; np. w bazie
Dostawcy
i
Części
numer dostawcy S5
występuje w tabeli
Dostawcy,
natomiast nie występuje w tabeli
Dostawy
• klucz obcy jest złożony (posiada więcej niż dwa atrybuty) wtedy i
tylko wtedy, gdy klucz kandydujący, któremu on odpowiada, jest także
złożony - analogicznie dla kluczy prostych
• wartość klucza obcego stanowi
odwołanie
do krotki zawierającej
wartość odpowiadającego mu klucza kandydującego
•
integralność referencyjna
to zapewnienie by baza danych nie
zawierała żadnych niedopuszczalnych wartości klucz obcego
Klucze obce - reguły zachowania
integralności referencyjnej
•
usuwamy
adresata referencji klucza obcego; np.
dostawcę
S1:
– operacja usuwania jest
ograniczona
do przypadku, w którym nie ma
powiązanych rekordów - usunięcie
dostawcy
S1 z tabeli
Dostawcy
zostanie
odrzucone, ponieważ w tabeli
Dostawy
istnieją powiązane z nim rekordy
– operacja usuwania jest
kaskadowo propagowana
do powiązanych
rekordów - usunięcie
dostawcy
S1 z tabeli
Dostawcy
spowoduje usunięcie
odpowiadających mu rekordów z tabeli
Dostawy
•
aktualizacja
klucza kandydującego, który jest adresatem referencji
jakiegoś klucza obcego; np. zmieniamy numer dostawcy S1 na S10:
– operacja aktualizacji jest
ograniczona
do przypadku, w którym nie ma
powiązanych rekordów - zmiana numeru
dostawcy
z S1 na S10 zostanie
odrzucona, natomiast z S5 na S50 nie
– operacja aktualizacji jest kaskadowo propagowana do powiązanych
rekordów
Integralność referencyjna - przykład
SP
S
Dostawcy
Dostawy
Zmiana wartości lub usunięcie S1 z relacji S,
wymusza konieczność operacji na relacji SP.
Wiersz z wartością S5 jest niezależny od SP.
4

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin