Bazy danych

Bazy danych
2a. Związki encji.
2b.Relacyjny model baz
danych
P. F. Góra
http://th-www.if.uj.edu.pl/zfs/gora/
semestr letni 2006/07
Więcej o związkach encji (E/R)
tytuł
rok
Filmy
długość
nazwisko
Gwiazdy-w
adres
Gwiazdy
TypTaśmy
nazwa
Posiada
Studia
adres
Bazy danych - wykład 2
2
Diagramy E/R dopuszczają
związki wieloargumentowe
Filmy
Kontrakty
Gwiazdy
Studia
Bazy danych - wykład 2
3
Inny przykład o takiej samej
strukturze
Dostawca
Dostawa
Transport
Magazyn
Co oznacza strzałka?
Dostawca i transport
jednoznacznie identyfikują
miejsce, do którego trafia
dostawa.
Bazy danych - wykład 2
4
W diagramach E/R związki mogą
mieć swoje atrybuty
tytuł
rok
Wynagrodzenie
Filmy
długość
Kontrakty
nazwisko
adres
Gwiazdy
TypTaśmy
Studia
nazwa
adres
Bazy danych - wykład 2
5
Czteroargumentowy związek
z atrybutami
tytuł
rok
Wynagrodzenie
Filmy
długość
Studio
producenta
Kontrakty
nazwisko
adres
Gwiazdy
TypTaśmy
Studia
nazwa
adres
Bazy danych - wykład 2
Studio
gwiazdy
6
Atrybuty związków zastępujemy
dodatkowymi zbiorami encji
Wynagrodzenie
tytuł
Gaże
rok
Filmy
długość
nazwisko
Kontrakty
adres
Gwiazdy
TypTaśmy
Film wyznacza
jednoznaczne
Studio producenta
Kombinacja
Filmu i
Gwiazda
wyznacza
Gwiazdy
wyznacza
jednoznaczne
jednoznaczną
Gażę
Studio gwiazdy
Studia
nazwa
adres
Bazy danych - wykład 2
7
Związki wieloargumentowe można zastąpić
dodatkowymi zbiorami encji i związkami
dwuargumentowymi
Gwiazdy
Zbiór encji Kontrakty
nie ma atrybutów, ma
same związki
Filmy
Film-w
Gwiazda-czego
Kontrakty
Jaka-gaża
Studio-prod.
Studio-gwiazdy
Studia
Może zbiór encji Gaże
wcale nie jest potrzebny?
Bazy danych - wykład 2
Gaże
Wynagrodzenie
8
Zbiór encji Kontrakty ma
jeden atrybut i wchodzi w
cztery związki
dwuargumentowe
Gwiazdy
Filmy
Film-w
Gwiazda-czego
Kontrakty
Studio-gwiazdy
Wynagrodzenie
Studio-prod.
Studia
Zbiór encji powstały z rozbicia związku wieloargumentowego na
relacje binarne nazywa się zbiorem łączącym.
Odpowiednią tabelę nazywa się tabelą pomostową.
Bazy danych - wykład 2
9
Relacyjne systemy baz danych
…zdominowały rynek. Systemy nierelacyjne
mają status eksperymentalny, lub stosowane
są w bardzo specjalistycznych kontekstach.
Dlatego zdecydowana większość tego, o czym
będziemy mówić, dotyczyć będzie systemów
relacyjnych.
Bazy danych - wykład 2
10
Tylko jeden sposób reprezentowania danych:
dwuwymiarowa tabela
(Ullman i Widom nazywają ją „relacją”)
Nazwa tabeli
Krotka
TOsoba
ImięNazwisko
Ignacy Janowski
Karol Janowski
Ludwik Janowski
Patrycja Janowska
…
DataUr
17.03.1936
23.11.1957
03.02.1983
07.01.2005
…
Składowa krotki
Bazy danych - wykład 2
Płeć
M
M
M
K
…
Nazwy
kolumn
(atrybuty)
11
Intuicja, jaką niesie słowo
„tabela”, może być myląca:
Tyle teoria.
W praktyce różnie to bywa, RDBMS niekiedy
dopuszcza powtarzające się krotki.
Wówczas tabela nie jest zbiorem, ale
wielozbiorem.
W modelu relacyjnym „tabela” nie
jest listą, ale zbiorem
•W jednej tabeli nie mogą wystąpić dwie
takie same krotki
•Kolejność, w jakiej występują krotki, nie
ma znaczenia
Bazy danych - wykład 2
12
Trochę terminologii:
Więzy
• Klucze
• Więzy jednoznaczności
• Więzy integralności referencyjnej
• Więzy domenowe (zakresu)
• Więzy ogólne
Bazy danych - wykład 2
13
Nie jest to ścisła
definicja klucza —
definicję ścisłą poznamy
w przyszłości.
Klucze
Klucz — atrybut lub zbiór atrybutów, który
jednoznacznie definiuje krotkę w tabeli lub encję
wewnątrz zbioru encji.
W danej tabeli nie występują dwie krotki, które
miałyby identyczne wartości wszystkich atrybutów
tworzących klucz.
A jeśli występują i są różne, to znaczy, że „klucz” nie jest kluczem.
Uwaga: abstrakcyjny obiekt w pamięci komputera nie musi mieć
klucza, bo jest jednoznacznie identyfikowany przez adres
przydzielonego mu obszaru pamięci.
Bazy danych - wykład 2
14
Gdybyśmy próbowali utworzyć w
jednej klasie dwa różne obiekty o
takich samych kluczach, DBMS
powinien to uniemożliwić.
Bazy danych - wykład 2
15
Właściwy dobór kluczy jest trudny, bo
muszą one dobrze odpowiadać
rzeczywistości
Osoba: Imię,
Imię iDrugie
Nazwisko?
Imię iNazwisko
Imię,
Nazwisko?i Data Urodzenia?
Ściśle rzecz biorąc, PESEL
W
bazie
odpowiedno duży zbiór ludzi nie
Nie
wystarczy.
nie
służyreprezentującej
tylko jako
indeks, ale to jest
wystarczy.
zupełnie inna historia…
Czasami wprowadza się nowe pole tylko po to, aby mogło
służyć jako indeks
Studenci:
„Rządowa” baza danych:
Numer Indeksu
PESEL
Bazy danych - wykład 2
16
Inny przykład — faktury
Firma ma bazę gromadzącą dane o wystawianych fakturach.
Co będzie kluczem?
•Numer Faktury.
•Jeśli numeracja zaczyna się od początku w każdym roku,
Numer Faktury i Rok.
•Jeśli poszczególne działy stosują własną numerację faktur,
Numer Faktury i Nazwa Działu lub
Numer Faktury, Nazwa Działu i Rok.
Jak widać, właściwy dobór klucza zależy od rzeczywistości,
którą chcemy przedstawić w bazie danych.
Bazy danych - wykład 2
17
Ważna uwaga:
Przypuśćmy, że mamy „rządową” bazę
danych osobowych, w której kluczem jest
atrybut PESEL.
Wówczas zbiór atrybutów {PESEL, Nazwisko}
także jest kluczem!
Bazy danych - wykład 2
18
Podobnie, jeśli tworzymy bazę danych szkół
podstawowych, zbiór atrybutów {Ulica,
NrDomu, NrSzkoły} będzie kluczem. Załóżmy, że
tak jest. Jeśli rozszerzymy ten zbiór do {Miasto,
Ulica, NrDomu, NrSzkoły}, także otrzymamy
klucz. Podobnie będzie jeśli dodamy informację o
województwie.
W rzeczywistości trzebaby
to sprawdzić…
Bazy danych - wykład 2
19
Klucze minimalne. Nadklucze.
W poprzednim przykładzie może się zdarzyć, że w dwu różnych
miastach będą istnieć ulice Kościuszki i w dodatku na każdej z
tych ulic pod numerem 1 będzie mieścić się szkoła podstawowa.
Podobnie w dwu miastach na ulicy Dąbrowskiego (ale w
budynkach o różnych numerach!) mogą się mieścić szkoły
podstawowe o numerze 16.
Wreszcie może się zdarzyć, że szkoły o numerze 53 (w różnych
miastach) będą się mieścić w budynku o numerze 8 (przy ulicach
o różnych nazwach).
Zbiór {Ulica, NrDomu, NrSzkoły} nazywamy w tej
sytuacji kluczem minimalnym. Jego nadzbiór
nazywamy nadkluczem.
W innej terminologii „klucz
minimalny” zwany jest po
prostu „kluczem”
Bazy danych - wykład 2
20
Dygresja: Zbiory słabych encji
Jeśli niektóre (lub wszystkie) elementy klucza pewnego zbioru
encji wybiera się spośród atrybutów innego zbioru encji,
zbiór o tak utworzonym kluczu nazywa się zbiorem słabych
encji. Typowo
1. Przy strukturze hierarchicznej nazwa (czy inny atrybut)
obiektu może identyfikować go w podhierarchii, ale nie w
całej hierarchii. Na przykład Numer Szkoły identyfikuje szkołę
w mieście, ale nie w województwie. Zbiór encji szkoły będzie
musiał brać część swojego klucza z innego zbioru encji
(miasta), więc będzie to słaba encja.
2. Zbiór łączący, powstały w celu wyeliminowania relacji
wieloargumentowych, prawie zawsze będzie słaby.
Bazy danych - wykład 2
21
Reprezentacja graficzna zbiorów
słabych encji
Klucz zbioru Szkoły
numer
Szkoły
Zbiór słabych encji i
związki łączące go z
„dostarczycielami”
(części) klucza oznaczam
podwójną linią.
nazwa
Liczne inne atrybuty
Miasta
…
Miasto
Leży w mieście
Bazy danych - wykład 2
22
Dane a metadane
Tabela (realcja) to obiekt abstrakcyjny. Ma swoje
atrybuty i więzy. Zbiór wszystkich takich
„projektów” tabel nazywa się schematem bazy
danych. Schemat wraz z informacjami o
użytkownikach i ich uprawnieniach stanowi
metadane („dane o danych”). Schemat tabeli w
zasadzie — w czasie normalnego użytkowania —
nie zmienia się w czasie.
Zbiór wszystkich krotek danej tabeli („zawartość
tabeli”) może się zmieniać w czasie. Zbiór taki
nazywa się instancją tabeli (relacji). Instancję
istniejącą teraz nazywa się instancją bieżącą.
Bazy danych - wykład 2
23
Więzy jednoznaczności
A
R
B
Istnieje co najwyżej jeden obiekt z klasy B,
który wchodzi w relację R z pewnym
obiektem klasy A.
Ten obiekt z klasy B nie musi istnieć,
może być obiektem pustym. Innymi słowy,
nie wszystkie obiekty z A muszą wchodzić
w związek R.
Bazy danych - wykład 2
24
Więzy integralności referencyjnej
Na przykład każda
informacja o dostawie
towarów do magazynu
musi być powiązana z
dostawcą
A
R
B
Istnieje dokładnie jeden obiekt z klasy B,
który wchodzi w relację R z pewnym
obiektem klasy A.
Ten obiekt z klasy B musi istnieć, nie
może być obiektem pustym. Innymi słowy,
wszystkie obiekty z A muszą wchodzić w
związek R z obiektami B.
W książce oznaczają to
przez półokrąg.
Bazy danych - wykład 2
25
Więzy integralności referencyjnej wymuszają istnienie
wskazywanego obiektu. Jeślibyśmy więc zażądali usunięcia
obiektu związanego więzami integralności referencyjnej,
DBMS
1. Uniemożliwi usunięcie takiego obiektu lub
2. Usunie także wszystkie obiekty, które na obiekt usuwany
wskazują. Jeśli one też są związane więzami integralności
referencyjnej, usunięte zostaną obiekty, które na nie
wskazują. I tak dalej.
 Usuwanie kaskadowe.
Bardzo niebezpieczne — nie każdego stać na
zatrudnienie stu osób do wklepywania
utraconych danych.
Bazy danych - wykład 2
26
Inne rodzaje więzów
1. Więzy domenowe (zakresu) — atrybut może przyjąć
wartości tylko z pewnego zakresu.
2. Więzy ogólne — na przykład ograniczenie stopnia
związku, to jest ilości „partnerów” w relacji.
Filmy
Gwiazdy-w
10
Gwiazdy
Nie więcej niż 10
gwiazd w jednym filmie
Bazy danych - wykład 2
27
Dwanaście zasad Codda dla
RDBMS
1. Informacje są reprezentowane logicznie
w tabelach.
2. Dane są logicznie dostępne przez
podanie nazwy tabeli, wartości klucza
podstawowego i nazwy kolumny.
3. Wartości null są traktowane w jednolity
sposób jako „brakujące informacje”. Nie
mogą być traktowane jako puste
łańcuchy czy zera.
Bazy danych - wykład 2
28
Dwanaście zasad Codda dla
RDBMS (cd)
4. Metadane są umieszczone w bazie
danych tak, jak zwykłe dane.
5. Język obsługi danych ma możliwość
definiowania danych i perspektyw,
więzów integralności, przeprowadzania
autoryzacji, obsługi transakcji i
manipulacji danymi.
6. Perspektywy reagują na zmiany swoich
tabel bazowych. Zmiana w perspektywie
powoduje zmianę w tabeli bazowej.
Bazy danych - wykład 2
29
Dwanaście zasad Codda dla
RDBMS (cd)
W praktyce w systemach komercyjnych robi się to
bardzo rzadko. Z całą pewnością nie jest to
operacja, jaką rutynowo przeprowadza zwykły
użytkownik!
7. Istnieją pojedyncze operacje
pozwalające na wyszukanie, wstawienie,
uaktualnienie i usunięcie danych.
8. Operacje użytkownika są logicznie
oddzielone od fizycznych danych i
metod dostępu.
9. Operacje użytkownika pozwalają na
zmianę schematu bazy danych bez
konieczności tworzenia bazy od nowa.
Bazy danych - wykład 2
30
Dwanaście zasad Codda dla
RDBMS (cd)
10. Więzy integralności są umieszczone w
metadanych, nie w zewnętrznej
aplikacji.
11. Język manipulacji danymi powinien
działać bez względu na to jak i gdzie są
rozmieszczone fizyczne dane oraz nie
powinien wymagać zmian, gdy fizyczne
dane są centralizowane lub
rozpraszane.
Bazy danych - wykład 2
31
Dwanaście zasad Codda dla
RDBMS (cd)
12. Operacje na pojedynczych rekordach
przeprowadzane w systemie podlegają
tym samym zasadom i więzom, co
operacje na zbiorach danych.
Różnica wobec programowania
proceduralnego, gdzie zawsze
trzeba powiedzieć jak manipulować
danymi.
Bazy danych - wykład 2
32
Dziesiąta zasada Codda
Więzy integralności są umieszczone w
metadanych, nie w zewnętrznej aplikacji.
Bardzo ważna
zasada!
Jeśli modelowany fragment rzeczywistości
zawiera jakieś ograniczenia, powinny one się
znaleźć w samym projekcie bazy danych, nie
w aplikacji obsługującej tę bazę.
Bazy danych - wykład 2
33
Dlaczego ograniczenia umieszczamy w
metadanych, nie w aplikacji?
•Bo osoba pisząca aplikację może nie wiedzieć
o tych ograniczeniach, może nie uznać je za
istotne i może nie umieścić ich w swoim
projekcie.
•Bo osoba pisząca kolejną aplikację może nie
umieścić ich w swoim projekcie (z powodów jak
wyżej).
•Bo doświadczenie uczy, że jeśli ograniczenia
nie są wbudowane w projekt bazy, prędzej czy
później zdarzy się jakieś nieszczęście…
Bazy danych - wykład 2
34
Przykład
Dobrze zaprojektowana baza danych studentów i
grup ćwiczeniowych musi mieć wbudowane
ograniczenie stanowiące, że do jednej grupy
mającej zajęcia w pracowni komputerowej A, nie
można zapisać więcej niż 21 studentów.
Ostatnio na zajęcia zgłosiło się 40 osób, wszystkie
legalnie wpisane w systemie USOS
Bazy danych - wykład 2
35
Jak realizujemy więzy?
Zgodnie z pierwotną ideą Codda, więzy powinny być zawarte w
samej strukturze tabel — metadane same w sobie stanowią
część dokumentacji projektu bazodanowego.
Niekiedy robi się też tak: Baza danych nie udostępnia swoich
tabel zewnętrznym aplikacjom bezpośrednio, a jedynie za
pomocą procedur składowanych.
Złożone zapytania warto jest umieszczać w samej bazie danych,
na przykład w postaci perspektyw.
Bazy danych - wykład 2
36
Zasady projektowania
• Dokładność — projekt powinien odpowiadać
specyfikacji, tabele lub zbiory encji powinny
odzwierciedlać świat rzeczywisty.
• Unikanie redundancji — bo zajmuje się zbyt
wiele miejsca i ryzykuje się, że nie wszystkie
wystąpienia danej informacji będą uaktualnione.
• Prostota — tylko tyle elementów, ile naprawdę
potrzeba.
• Dobór właściwych elementów — nie wszystko
modelujemy jako atrybuty!
Bazy danych - wykład 2
37
 Projekt ma odpowiadać rzeczywistości, nie widzimisię lub
(na ogół błędnej) intuicji projektanta
 Projektowanie bazy danych to PRACA, za którą twórca
powinien być odpowiednio wynagradzany
 Projekt musi być zatwierdzony przed realizacją
 Zmiana projektu w takcie realizacji jest bardzo bolesna;
powinno się jej dokonywać tylko wtedy, gdy jest ona
naprawdę konieczna
Bazy danych - wykład 2
38