Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Bazy danych 2.Relacyjny model baz danych Algebra relacji P. F. Góra semestr letni 2007/08.

Podobne prezentacje


Prezentacja na temat: "Bazy danych 2.Relacyjny model baz danych Algebra relacji P. F. Góra semestr letni 2007/08."— Zapis prezentacji:

1 Bazy danych 2.Relacyjny model baz danych Algebra relacji P. F. Góra semestr letni 2007/08

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

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

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

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

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

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

8 Bazy danych - wykład 28 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…

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

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

11 Bazy danych - wykład 211 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 ć …

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

13 Bazy danych - wykład 213 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.

14 Bazy danych - wykład 214 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 ą.

15 Bazy danych - wykład 215 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 ą.

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

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

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

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

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

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

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

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

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

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

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

27 Bazy danych - wykład 227 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

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

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

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

31 Bazy danych - wykład 231 Relacyjne j ę zyki zapyta ń (Relational Query Languages) Pozwalaj ą na manipulacje danymi i pobieranie danych z bazy Maj ą mocne podstawy teoretyczne (algebra relacji!) Pozwalaj ą na znaczn ą optymalizacj ę Nie s ą zwyk ł ymi j ę zykami programowania, przeznaczonymi do skomplikowanych oblicze ń Pozwalaj ą u ż ytkownikom zdefiniowa ć co chc ą osi ą gn ąć, nie za ś jak to trzeba obliczy ć (Non-operational, declarative ) Cho ć w w praktyce na ogó ł zawieraj ą poka ź ny zestaw niebazodanowych funkcji

32 Bazy danych - wykład 232 Zrozumienie algebry relacji jest konieczne dla zrozumienia i prawid ł owego pos ł ugiwania si ę SQL Zapytania odnosz ą si ę do wyst ą pie ń (instancji) tabel. Wynikiem zapyta ń te ż s ą wyst ą pienia (instancje) tabel. –Schematy tabel wej ś ciowych zapytania s ą ustalone. –Schematy tabel wyj ś ciowych zapytania s ą okre ś lone przez definicje j ę zyka zapyta ń. Zapytanie odnosi si ę do konkretnego wyst ą pienia tabeli (lub tabel) o ustalonym schemacie.

33 Bazy danych - wykład 233 Przyk ł adowe wsyt ą pienia tabel w pewnej bazie Rezerwacje R1 Łódki B1 Żeglarze S1 Żeglarze S2 Angloj ę zyczna wersja tego przyk ł adu jest dost ę pna w co najmniej dwu niezale ż nych miejscach w sieci…

34 Bazy danych - wykład 234 Podstawowe operacje Działania teoriomnogościowe: Suma mnogościowa (unia) Przecięcie (iloczyn) zbiorów Różnica zbiorów Iloczyn kartezjański Rzutowanie Selekcja Przemianowanie Złączenie Technicznie rzecz bior ą c, to te ż nie jest podstawowa operacja, ale wyst ę puje w praktyce tak cz ę sto, ż e jest osobno implementowana Wynikiem ka ż dej operacji jest tabela (relacja), mo ż na wi ę c tworzy ć operacje z ł o ż one. Algebra relacji jest domkni ę ta!

35 Bazy danych - wykład 235 Operacje teoriomnogo ś ciowe Schematy obu tabel (relacji) wej ś ciowych musz ą mie ć identyczne zbiory atrybutów Zanim zostanie obliczona suma mnogo ś ciowa, przeci ę cie lub ró ż nica zbiorów, nale ż y uporz ą dkowa ć atrybuty obu tabel tak, aby kolejno ś c atrybutów by ł a taka sama.

36 Bazy danych - wykład 236 Suma mnogo ś ciowa R S zbiór krotek, z których ka ż da nale ż y do R lub do S (lub do obu jednocze ś nie) S1 S2 Poniewa ż jest to zbiór, kolejno ść krotek nie ma znaczenia.

37 Bazy danych - wykład 237 Przeci ę cie mnogo ś ciowe R S zbiór krotek, z których ka ż da nale ż y jednocze ś nie do R i S S1 S2 Ró ż nica mnogo ś ciowa R - S zbiór tych krotek z R, które nie nale żą do S S1 – S2

38 Bazy danych - wykład 238 Uwaga na wielozbiory! Tabele (relacje) w modelu relacyjny powinny by ć zbiorami (krotki nie mog ą si ę powtarza ć ), ale niekiedy nie s ą je ś li dopuszczamy powtórzenia krotek, czyli zbiory zast ę pujemy wielozbiorami, zmieniaj ą si ę definicje operacji mnogo ś ciowych. Suma R S krotka w wyniku wyst ę puje tyle razy, ile wyst ę puje w R plus tyle razy, ile wyst ę puje w S. Uwaga: je ś li nawet R i S s ą zbiorami, R S mo ż e by ć wielozbiorem! Iloczyn R S krotka w wyniku wyst ę puje tyle razy, ile wynosi minimum jej wyst ą pie ń w R i S. Ró ż nica R–S krotka w wyniku wyst ę puje tyle razy, ile wyst ę puje ona w R minus tyle razy, ile wyst ę puje ona w S, ale nie mniej ni ż 0 razy.

39 Bazy danych - wykład 239 Przyk ł ad: R = {A,B,B},S = {A,B,C,C} R S = {A,A,B,B,B,C,C} R S = {A,B} R–S = {B}

40 Bazy danych - wykład 240 Uwaga na wielozbiory (cd)! Tabele (relacje) w modelu relacyjny powinny by ć zbiorami (krotki nie mog ą si ę powtarza ć ), ale niekiedy nie s ą. W dobrze zaprojektowanej relacyjnej bazie danych tabele musz ą by ć zbiorami. Kiedy mog ą pojawia ć si ę wielozbiory? Wielozbiory w dobrze zaprojektowanych relacyjnych bazach danych pojawiaj ą si ę (i to do ść cz ę sto) jako tabele wynikowe pewnych zapyta ń. Tabele te mog ą by ć tabelami wej ś ciowymi kolejnych zapyta ń …

41 Bazy danych - wykład 241 Selekcja C (R) Wybierz z tabeli R tylko te wiersze, które spe ł niaj ą warunek wyboru C. –W warunku wyboru mog ą pojawia ć si ę operatory logiczne! Schemat wyj ś ciowej relacji jest taki sam, jak relacje wej ś ciowej. Je ś li R jest zbiorem, nie ma duplikatów. –W praktyce duplikaty niekiedy si ę pojawiaj ą W SQL rozró ż nienie SELECT vs SELECT DISTINCT.

42 Bazy danych - wykład 242 Przyk ł ad S2 Rating > 8 (S2) Wybierz tylko te wiersze z tabeli S2, dla których Rating > 8

43 Bazy danych - wykład 243 Rzutowanie A 1,A 2,… (R) Utwórz now ą relacj ę, która zawiera tylko te kolumny relacji R, które wymienione s ą na li ś cie rzutowania A 1,A 2,… Schemat rejacji wyj ś ciowej zawiera tylko kolumny wyst ę puj ą ce na li ś cie rzutowania. W formalizmie matematycznym operator rzutowania eliminuje duplikaty –W praktyce (SQL) eliminowania duplikatów trzeba za żą da ć explicite.

44 Bazy danych - wykład 244 Przyk ł ad S2 Imię,Rating (S2) Wiek (S2) Usuni ę to duplikaty! Wybierz tylko kolumny Imi ę, Rating z tabeli S2

45 Bazy danych - wykład 245 Sk ł adanie operatorów Relacja wyj ś ciowa jednego zapytania mo ż e sta ć si ę relacj ą wej ś ciow ą kolejnego zapytania powstaje operator z ł o ż ony. S2 Imię,Rating ( Rating > 8 (S2))

46 Bazy danych - wykład 246 Przemianowanie S(A 1,A 2,…,A n ) (R) W wyniku operacji S(A 1,A 2,…,A n ) (R) z relacji R otrzymujemy relację S, mającą tyle samo atrybutów, co R. Nowymi nazwami atrybutów staj ą si ę A 1, A 2, …, A n. Kolejno ść atrybutów zostaje zachowana. Je ś li chcemy tylko zmieni ć nazw ę samej relacji, bez zmiany nazw atrybutów, piszemy S (R).

47 Bazy danych - wykład 247 Jak zapamiętać te oznaczenia? sigma select pi project rho rename

48 Bazy danych - wykład 248 Iloczyn kartezja ń ski R S ka ż da krotka (wiersz) z R zostaje po łą czona z ka ż d ą krotk ą (wierszem) S Schemat wyniku ma po jednym atrybucie (kolmnie) na ka ż dy atrybut R i po jednym atrybucie na ka ż dy atrybut S. Nazwy atrybutów s ą, o ile to mo ż liwe, dziedziczone. S1 R1 Konflikt mi ę dzy nazwami kolumn, który trzeba rozwi ą za ć przez przemianowanie

49 Bazy danych - wykład 249 Z łą czenie warunkowe (z łą czenie theta) Z iloczynu kartezja ń skiego R S wybieramy tylko te krotki, które spe ł niaj ą warunek C. (Na ogó ł ) mniej krotek ni ż w iloczynie kartezja ń skim. Schemat wyniku taki, jak schemat iloczynu kartezja ń skiego.

50 Bazy danych - wykład 250 Z łą czenie równo ś ciowe (equi-join) Z łą czenie warunkowe, w którym warunek C zawiera same równo ś ci. Schemat wyniku podobny do schematu iloczynu kartezja ń skiego, ale zawiera tylko jedno wyst ą pienie ka ż dej kolumny, dla której za żą dano równo ś ci. Z łą czenie naturalne z łą czenie równo ś ciowe, dla którego za żą dano równo ś ci we wszystkich wspólnych kolumnach.

51 Bazy danych - wykład 251 Wa ż na uwaga Z łą czenie jest definiowane jako podzbiór iloczynu kartezja ń skiego tabel. Nie oznacza to jednak, ż e z łą czenie jest w praktyce realizowane przez RDBMS w ten sposób, i ż najpierw tworzy si ę iloczyn kartezja ń ski, a pó ź niej wybiera z niego krotki spe ł niaj ą ce warunek z łą czenia.

52 Bazy danych - wykład 252 Znajd ź imiona ż eglarzy, którzy zarezerwowali ł ódk ę nr 103 Rozw. 1: Rozw. 2: Rozw. 3:

53 Bazy danych - wykład 253 Podsumowanie Model relacyjny ma ś ci śł e, formalnie zdefiniowane regu ł y zadawania zapyta ń, proste, ale pot ęż ne. Algebra relacji jest bardzo u ż yteczna do reprezentowania planów wykonania zapyta ń. Jedno zapytanie zazwyczaj mo ż na zrealizowa ć na kilka sposobów. Optymalizator dobrego RDBMS powinien wybra ć sposób najlepszy, ale niekiedy trzeba to zrobi ć r ę cznie.


Pobierz ppt "Bazy danych 2.Relacyjny model baz danych Algebra relacji P. F. Góra semestr letni 2007/08."

Podobne prezentacje


Reklamy Google