Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Bazy danych 2a. Zwi ą zki encji. 2b.Relacyjny model baz danych P. F. Góra semestr letni 2006/07.

Podobne prezentacje


Prezentacja na temat: "Bazy danych 2a. Zwi ą zki encji. 2b.Relacyjny model baz danych P. F. Góra semestr letni 2006/07."— Zapis prezentacji:

1 Bazy danych 2a. Zwi ą zki encji. 2b.Relacyjny model baz danych P. F. Góra semestr letni 2006/07

2 Bazy danych - wykład 22 Wi ę cej o zwi ą zkach encji (E/R) Filmy tytu ł rok TypTa ś myd ł ugo ść Gwiazdy nazwiskoadres Studia nazwa adres Gwiazdy-w Posiada

3 Bazy danych - wykład 23 Diagramy E/R dopuszczaj ą zwi ą zki wieloargumentowe FilmyGwiazdy Studia Kontrakty

4 Bazy danych - wykład 24 Inny przyk ł ad o takiej samej strukturze DostawcaTransport Magazyn Dostawa Co oznacza strzałka? Dostawca i transport jednoznacznie identyfikują miejsce, do którego trafia dostawa.

5 Bazy danych - wykład 25 W diagramach E/R zwi ą zki mog ą mie ć swoje atrybuty FilmyGwiazdy Studia Kontrakty Wynagrodzenie tytu ł rok TypTa ś myd ł ugo ść nazwiskoadres nazwaadres

6 Bazy danych - wykład 26 Czteroargumentowy zwi ą zek z atrybutami FilmyGwiazdy Studia Kontrakty Wynagrodzenie tytu ł rok TypTa ś myd ł ugo ść nazwiskoadres nazwaadres Studio producenta Studio gwiazdy

7 Bazy danych - wykład 27 Atrybuty zwi ą zków zast ę pujemy dodatkowymi zbiorami encji FilmyGwiazdy Studia Kontrakty Wynagrodzenie tytu ł rok TypTa ś myd ł ugo ść nazwiskoadres nazwaadres Ga ż e Kombinacja Filmu i Gwiazdy wyznacza jednoznaczn ą Ga żę Film wyznacza jednoznaczne Studio producenta Gwiazda wyznacza jednoznaczne Studio gwiazdy

8 Bazy danych - wykład 28 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 Wynagrodzenie Mo ż e zbiór encji Ga ż e wcale nie jest potrzebny?

9 Bazy danych - wykład 29 GwiazdyFilmy 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 ą.

10 Bazy danych - wykład 210 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.

11 Bazy danych - wykład 211 Tylko jeden sposób reprezentowania danych: dwuwymiarowa tabela (Ullman i Widom nazywaj ą j ą relacj ą ) Nazwa tabeli Nazwy kolumn (atrybuty) Krotka Sk ł adowa krotki

12 Bazy danych - wykład 212 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.

13 Bazy danych - wykład 213 Troch ę terminologii: Wi ę zy Klucze Wi ę zy jednoznaczno ś ci Wi ę zy integralno ś ci referencyjnej Wi ę zy domenowe (zakresu) Wi ę zy ogólne

14 Bazy danych - wykład 214 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. Nie jest to ś cis ł a definicja klucza definicj ę ś cis łą poznamy w przysz ł o ś ci.

15 Bazy danych - wykład 215 Gdyby ś my próbowali utworzy ć w jednej klasie dwa ró ż ne obiekty o takich samych kluczach, DBMS powinien to uniemo ż liwi ć.

16 Bazy danych - wykład 216 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…

17 Bazy danych - wykład 217 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.

18 Bazy danych - wykład 218 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!

19 Bazy danych - wykład 219 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 ć …

20 Bazy danych - wykład 220 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

21 Bazy danych - wykład 221 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.

22 Bazy danych - wykład 222 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 ą.

23 Bazy danych - wykład 223 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 ą.

24 Bazy danych - wykład 224 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.

25 Bazy danych - wykład 225 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 ą

26 Bazy danych - wykład 226 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.

27 Bazy danych - wykład 227 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. FilmyGwiazdy Gwiazdy-w 10 Nie wi ę cej ni ż 10 gwiazd w jednym filmie

28 Bazy danych - wykład 228 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.

29 Bazy danych - wykład 229 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.

30 Bazy danych - wykład 230 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!

31 Bazy danych - wykład 231 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.

32 Bazy danych - wykład 232 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.

33 Bazy danych - wykład 233 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 ę.

34 Bazy danych - wykład 234 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…

35 Bazy danych - wykład 235 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

36 Bazy danych - wykład 236 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.

37 Bazy danych - wykład 237 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!

38 Bazy danych - wykład 238 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


Pobierz ppt "Bazy danych 2a. Zwi ą zki encji. 2b.Relacyjny model baz danych P. F. Góra semestr letni 2006/07."

Podobne prezentacje


Reklamy Google