Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

38
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

description

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. Gwiazdy-w. Posiada. Więcej o związkach encji (E/R). tytuł. rok. nazwisko. adres. Filmy. Gwiazdy. długość. TypTaśmy. nazwa. Studia. adres. - PowerPoint PPT Presentation

Transcript of Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Page 1: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

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

Page 2: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 2

Więcej o związkach encji (E/R)

Filmy

tytuł rok

TypTaśmydługość

Gwiazdy

nazwisko adres

Studia

nazwa

adres

Gwiazdy-w

Posiada

Page 3: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 3

Diagramy E/R dopuszczają związki wieloargumentowe

Filmy Gwiazdy

Studia

Kontrakty

Page 4: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 4

Inny przykład o takiej samej strukturze

Dostawca Transport

Magazyn

Dostawa

Co oznacza strzałka?

Dostawca i transport jednoznacznie

identyfikują miejsce, do którego trafia dostawa.

Page 5: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 5

W diagramach E/R związki mogą mieć swoje atrybuty

Filmy Gwiazdy

Studia

Kontrakty

Wynagrodzenietytuł rok

TypTaśmydługość

nazwisko adres

nazwa adres

Page 6: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 6

Czteroargumentowy związek z atrybutami

Filmy Gwiazdy

Studia

Kontrakty

Wynagrodzenietytuł rok

TypTaśmydługość

nazwisko adres

nazwa adres

Studio producenta

Studio gwiazdy

Page 7: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 7

Atrybuty związków zastępujemy dodatkowymi zbiorami encji

Filmy Gwiazdy

Studia

Kontrakty

Wynagrodzenie

tytuł rok

TypTaśmydługość

nazwisko adres

nazwa adres

Gaże

Kombinacja Filmu i Gwiazdy wyznacza jednoznaczną Gażę

Film wyznacza jednoznaczne

Studio producenta

Gwiazda wyznacza jednoznaczne

Studio gwiazdy

Page 8: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 8

Związki wieloargumentowe można zastąpić dodatkowymi zbiorami encji i związkami

dwuargumentowymi

Gwiazdy

Gaże

Filmy

Kontrakty

Studia

Gwiazda-czego

Jaka-gaża

Studio-prod.Studio-gwiazdy

Film-w

Zbiór encji Kontrakty nie ma atrybutów, ma

same związki

WynagrodzenieMoże zbiór encji Gaże

wcale nie jest potrzebny?

Page 9: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 9

Gwiazdy Filmy

Kontrakty

Studia

Gwiazda-czego

Studio-prod.Studio-gwiazdy

Film-w

Zbiór encji Kontrakty ma jeden atrybut i wchodzi w

cztery związki dwuargumentowe

Wynagrodzenie

Zbiór encji powstały z rozbicia związku wieloargumentowego na relacje binarne nazywa się zbiorem łączącym.

Odpowiednią tabelę nazywa się tabelą pomostową.

Page 10: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 10

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.

Page 11: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 11

Tylko jeden sposób reprezentowania danych:

dwuwymiarowa tabela

(Ullman i Widom nazywają ją „relacją”)

TOsoba

ImięNazwisko DataUr Płeć

Ignacy Janowski 17.03.1936 M

Karol Janowski 23.11.1957 M

Ludwik Janowski 03.02.1983 M

Patrycja Janowska 07.01.2005 K

… … …

Nazwa tabeli

Nazwy kolumn

(atrybuty)

Krotka

Składowa krotki

Page 12: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 12

Intuicja, jaką niesie słowo „tabela”, może być myląca:

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

Tyle teoria.

W praktyce różnie to bywa, RDBMS niekiedy dopuszcza powtarzające się

krotki. Wówczas tabela nie jest zbiorem, ale wielozbiorem.

Page 13: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 13

Trochę terminologii:Więzy

• Klucze

• Więzy jednoznaczności

• Więzy integralności referencyjnej

• Więzy domenowe (zakresu)

• Więzy ogólne

Page 14: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 14

KluczeKlucz — 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.

Nie jest to ścisła definicja klucza —

definicję ścisłą poznamy w przyszłości.

Page 15: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 15

Gdybyśmy próbowali utworzyć w

jednej klasie dwa różne obiekty o

takich samych kluczach, DBMS

powinien to uniemożliwić.

Page 16: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 16

Właściwy dobór kluczy jest trudny, bo muszą one dobrze odpowiadać

rzeczywistości

Osoba: Imię i Nazwisko?

Nie wystarczy.

Osoba: Imię, Drugie Imię i Nazwisko?

Nie wystarczy.

Osoba: Imię, Drugie Imię, Nazwisko i Data Urodzenia?

W bazie reprezentującej odpowiedno duży zbiór ludzi nie wystarczy.

Czasami wprowadza się nowe pole tylko po to, aby mogło służyć jako indeks

Studenci:

Numer Indeksu

„Rządowa” baza danych:

PESEL

Ściśle rzecz biorąc, PESEL nie służy tylko

jako indeks, ale to jest zupełnie inna historia…

Page 17: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 17

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.

Page 18: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 18

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!

Page 19: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 19

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ć…

Page 20: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 20

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”

Page 21: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 21

Dygresja: Zbiory słabych encjiJeś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.

Page 22: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 22

Reprezentacja graficzna zbiorów słabych encji

Szkoły

numer

Leży w mieście

Miasto

…nazwa

Klucz zbioru Szkoły

Liczne inne atrybuty Miasta

Zbiór słabych encji i związki łączące go z „dostarczycielami”

(części) klucza oznaczam podwójną

linią.

Page 23: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 23

Dane a metadaneTabela (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ą.

Page 24: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 24

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.

Page 25: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 25

Więzy integralności referencyjnej

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.

Na przykład każda informacja o dostawie towarów do magazynu musi być powiązana z

dostawcą

Page 26: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 26

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.

Page 27: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 27

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 GwiazdyGwiazdy-w10

Nie więcej niż 10 gwiazd w jednym

filmie

Page 28: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 28

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.

Page 29: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 29

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.

Page 30: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 30

Dwanaście zasad Codda dla RDBMS (cd)

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.

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!

Page 31: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 31

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.

Page 32: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 32

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.

Page 33: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 33

Dziesiąta zasada CoddaWię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ę.

Page 34: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 34

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…

Page 35: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 35

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

Page 36: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 36

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.

Page 37: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 37

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!

Page 38: Bazy danych 2a. Związki encji. 2b.Relacyjny model baz danych P. F. Góra

Bazy danych - wykład 2 38

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