Bazy danych. Plan wykáadu. Zale*noci funkcyjne. Wykáad 4: Relacyjny model danych - zale*noci funkcyjne. A B

Transkrypt

1 Plan wykáadu Bazy danych Wykáad 4: Relacyjny model danych - zale*noci funkcyjne. Maágorzata Krtowska Wydziaá Informatyki Politechnika Biaáostocka Deficja zale*noci funkcyjnych Klucze relacji Reguáy dotyczce zale*noci funkcyjnych Domknicie zbioru atrybutów Proces dobrego projektowania relacyjnego schematu bazy danych: szczegóáowy opis problemów, które wynikaj przy tworzenu schematu przedstawienie metody dekompozycji, która polega na podziale schematu relacji (zbioru atrybutów) na dwa mniejsze schematy opis postaci normalnej Boyce a-codda (BCNF) czyli taki warunek naáo*ony na schemat, dziki któremu mo*na wyeliminowaü jego niedoskonaáoci informacja o tym, w jaki sposób zapewniü speánienie warunków BCNF przez dekompozycj schematów relacyjnych SQL - funkcje cd. Záczenia zewntrzne. Bazy danych 2 Definicja zale*noci funkcyjnych Zale*noci funkcyjne Zale*noü funkcyjna: A 1 B Interpretacja: jeli dwie krotki relacji R s zgodne dla atrybutów A 1,,.., A n (tzn. obie krotki maj takie same wartoci skáadowych dla wymienionych atrybutów), to musz byü równie* zgodne w pewnym innym atrybucie B. Odczyt zapisu: A 1,..., A n okrelaj funkcyjnie B Jeli zbiór atrybutów A 1,..., A n okrela funkcyjnie wicej ni* jeden atrybut tzn. A 1 B 1 A 1 B 2 A 1 B 3 To taki zbiór zale*noci skrótowo przedstawiamy jako: A 1 B 1 B 2 B 3 Bazy danych 3 x y A Jeli x i y s zgodne dla atrybutów A A B B To musz byü zgodne równie* dla atrybutów B Bazy danych 4

2 Klucze relacji Atrybut lub zbiór atrybutów {A 1 } tworzy klucz relacji, jeli: wszystkie pozostaáe atrybuty relacji s funkcyjnie zale*ne od tych atrybutów => nie mo*e byü sytuacji, w której dwie ró*ne krotki relacji R zgodne dla wszystkich atrybutów A 1. Nie istnieje taki podzbiór wáaciwy zbioru {A 1 }, od którego pozostaáe atrybuty relacji R s zale*ne funkcyjnie, tzn. klucz musi byü minimalny Nadklucze Nadklucz - zbiór atrybutów, który zawiera klucz Ka*dy klucz jest nadkluczem Przykáady nadkluczy w relacji Film: (tytuá, rok, nazwisko Aktora, czas) (tytuá, rok, nazwisko Aktora, rodzaj) Klucze w diagramach E/R nie speániaj wymagania (2) Bazy danych 5 Bazy danych 6 Reguáy wykrywania kluczy w relacji Reguáa 1 Jeli relacja pochodzi z przeksztaácenia zbioru encji, to jej kluczem s atrybuty kluczowe tego zbioru encji Reguáa 2 (dotyczy zwizków binarnych) Jeli zwizek jest typu wiele do wiele, to klucze obu zbiorów encji objtych zwizkiem tworz zbiór atrybutów klucza R jeli zwizek ze zbioru encji E1 do zbioru encji E2 jest typu wiele do jeden, to atrybuty klucza E1 staj si kluczem R, ale atrybuty klucza E2 nie wchodz do klucza relacji R. Jeli zwizek jest typu jeden do jeden, to atrybuty klucza któregokolwiek ze zbiorów mog byü kluczem R. W tej sytuacji nie ma tylko jednego klucza. Klucze relacyjne i E/R Klucze w ERD s atrybutami encji Klucze w relacjach s atrybutami krotek Zazwyczaj, jedna krotka odpowiada jednej encji, wówczas idea jest taka sama W niewáaciwie skonstruowanych relacjach, jedna encja mo*e byü opisana przez kilka krotek, wówczas klucze w diagramach E/R i relacjach bd si ró*niáy. Bazy danych 7 Bazy danych 8

3 Reguáy dotyczce zale*noci funkcyjnych Zasady, które pozwalaj na zastpowanie zbioru zale*noci funkcyjnych zbiorami równowa*nymi lub na doáczanie do zbioru tych zale*noci, które wynikaj ze zbioru pocztkowego. Zasady podziaáu i áczenia Reguáa podziaáu Zale*noü funkcyjn A 1 B 1 B 2... B m mo*emy zastpiü zbiorem zale*noci funkcyjnych A 1 B i, gdzie i=1,2,...,m Wyró*niamy nastpujce reguáy: reguáa áczenia reguáa podziaáu reguáa przechodnioci Reguáa áczenia Zbiór zale*noci funkcyjnych A 1 B i, gdzie i=1,2,...,m mo*emy zastpiü pojedyncz zale*noci funkcyjn A 1 B 1 B 2... B m Bazy danych 9 Bazy danych 10 Zale*noci trywialne Domknicie zbioru atrybutów Zale*noü funkcyjna A 1 B jest trywialna, jeli B jest równe któremu z A tytuá rok tytuá Mówimy, *e zale*noü A 1 B 1 B 2... B m jest: trywialna - jeli zbiór záo*ony z atrybutów typu B jest podzbiorem zbioru atrybutów typu A nietrywialna - jeli co najmniej jeden z atrybutów typu B znajduje si poród atrybutów A caákowicie nietrywialna - jeli *aden z atrybutów typu B nie znajduje si poród atrybutów typu A Atrybuty, które wystpuj równoczenie z prawej i lewej strony zawsze mo*na pominü po prawej tronie, std prawdziwe jest twierdzenie (reguáa zale*noci trywialnych) Zale*noü funkcyjna A 1 B 1 B 2... B m jest równowa*na zale*noci A 1 C 1 C 2... C K, gdzie C s tymi elementami z B, które nie s równe A. Bazy danych 11 Zaáo*enia: {A 1,..., A n } - zbiór atrybutów S - zbiór zale*noci funkcyjnych Domkniciem zbioru {A 1,..., A n } nad zbiorem zale*noci S nazywamy taki zbiór atrybutów B, *e jeli pewna relacja R speánia wszystkie zale*noci ze zbioru S, to speánia tak*e zale*noü A 1... A n B, a zatem zale*noü A 1... A n B wynika z S. Domknicie zbioru atrybutów {A 1,..., A n } oznaczamy przez {A 1,..., A n } +. Bazy danych 12

4 Algorytm obliczania domknicia zbioru atrybutów {A 1,..., A n } Przykáad Niech X oznacza nazw zbioru domknicia. Na pocztku X= {A 1,..., A n }. Znajdujemy tez wszystkie zale*noci funkcyjne postaci B 1 B 2...B m C gdzie B 1 B 2...B m nale* do zbioru X, a C nie nale*y. Wówczas doáczamy C do zbioru X. X + Y B Nowy X + Powtarzamy krok 2 tak dáugo, jak dáugo nie bdzie mo*na doáczyü do X *adnego nowego atrybutu. Jeli ju* *adnego atrybutu nie mo*na doáczyü do X, to znaczy, *e otrzymalimy domknicie zbioru {A 1,..., A n } + Bazy danych 13 Bazy danych 14 Cel Domknicie i klucze Majc dane domknicie zbioru atrybutów {A 1,..., A n } mo*emy sprawdziü, czy dana zale*noü funkcyjna wynika ze zbioru zale*noci S. Jeli B nale*y do {A 1,..., A n } + to oznacza, *e wynika z S. A 1 B Zbiór {A 1,..., A n } + zawiera wszystkie atrybuty relacji R wtedy i tylko wtedy, gdy elementy A 1,..., A n s nadkluczem w R. Stwierdzenie, czy atrybuty A 1,..., A n stanowi klucz relacji, mo*e polegaü na sprawdzeniu: czy wszystkie atrybuty R nale* do zbioru {A 1,..., A n } + czy X + otrzymane z dowolnego X, który utworzymy przez usunicie choüby jednego elementu sporód A 1,..., A n, nie zawiera wszystkich atrybutów R Przykáad: Relacja Filmy(tytuá, rok, czas, rodzaj, nazwastudia, adresstudia) Uzasadniü, *e kluczem jest zbiór (tytuá, rok) tytuá rok nazwastudia nazwastudia adresstudia Bazy danych 15 Bazy danych 16

5 Reguáa przechodnioci Reguáa przechodnioci umo*liwia kaskadowe áczenie zale*noci: jeli w relacji R zachodz zale*noci A 1 B 1 B 2... B m oraz B 1 B 2... B m C 1 C 2...C k, to w relacji R zachodzi tak*e zale*noü A 1 C 1 C 2...C k. Uzasadnienienie powy*szej reguáy => wyliczenie domknicia {A 1,,..., A n } +. Plan wykáadu Proces dobrego projektowania relacyjnego schematu bazy danych: szczegóáowy opis problemów, które wynikaj przy tworzenu schematu przedstawienie metody dekompozycji, która polega na podziale schematu relacji (zbioru atrybutów) na dwa mniejsze schematy opis postaci normalnej Boyce a-codda (BCNF) czyli taki warunek naáo*ony na schemat, dziki któremu mo*na wyeliminowaü jego niedoskonaáoci informacja o tym, w jaki sposób zapewniü speánienie warunków BCNF przez dekompozycj schematów relacyjnych SQL cd Bazy danych 17 Bazy danych 18 Anomalie Anomalie - problemy, jakie powstaj, gdy próbujemy do pojedynczej relacji wáczyü zbyt wiele danych redundancja - dane niepotrzebnie powtarzaj si w kilku krotkach anomalie modyfikacji - sytuacje, w których wartoü zostaje zmodyfikowana w jednej krotce, a w innej nie anomalie usuniü - usunicie krotki mo*e powodowaü usunicie wa*nej informacji z bazy danych Dekompozycja relacji Dekompozycja relacji - sposób eliminowania wymienionych anomalii przez podziaá atrybutów relacji R midzy dwa schematy nowych relacji. Relacj R o schemacie {A 1 } dekomponujemy midzy dwie relacji S i T o schematach odpowiednio {B 1, B 2,..., B m } i {C 1, C 2,..., C k } wedáug nastpujcych zasad: {A 1 } = {B 1, B 2,..., B m } {C 1, C 2,..., C k } Krotki relacji S powstaj przez rzutowanie wszystkich krotek relacji R na zbiór atrybutów {B 1, B 2,..., B m }, tzn. z ka*dej krotki t bie*cej instancji relacji R pobieramy wartoci atrybutów {B 1, B 2,..., B m } i tworzymy w ten sposób krotk relacji S. Je*eli z relacji R otrzymamy kilka jednakowych krotek w relacji S, w S umieszczamy tylko jedn kopi. W podobny sposób uzyskuje si krotki relacji T. Bazy danych 19 Bazy danych 20

6 Postaü normalna Boyce a-codda Dekompozycja do postaci BCNF Postaü normalna Boyce a-codda (BCNF) - warunek, którego speánienie zapewnia, *e w schemacie nie wystpuj omówione wczeniej anomalie. Relacja R jest w postaci normalnej BCNF wtedy i tylko wtedy, gdy dla ka*dej nietrywialnej zale*noci A 1 B, zbiór {A 1 } jest nadkluczem R Jeli proces dekompozycji bdziemy powtarzaü dostatecznie dáugo, to ka*da otrzymana relacja bdzie si skáadaáa z kolekcji podzbiorów atrybutów, które: bd schematami relacji w postaci BCNF dane z pierwotnej relacji bd wiernie reprezentowane w relacjach powstaáych w wyniku dekompozycji => bdzie istniaáa mo*liwoü dokáadnego odtworzenia pierwotnej relacji, na podstawie relacji utworzonych przez wielokrotne dekompozycje. Strategia dekompozycji: Dane: relacja R z zale*nociami funkcyjnymi ZF Znalezienie pewnej nietrywialnej zale*noci funkcyjnej {A 1 } {B 1, B 2,..., B m }, która narusza warunek BCNF (tzn. {A 1 } nie jest nadkluczem). Wyliczenie dopeánienia zbioru atrybutów {A 1 } +. Dopeánienie zawiera wszystkie atrybuty, gdy {A 1 } jest nadkluczem. Bazy danych 21 Bazy danych 22 Dekompozycja R do postaci BCNF Projektowanie zale*noci funkcyjnych Zamie relacj R na relacje o schematach: R 1 = {A 1 } + R 2 = (R-{A 1 } + ) {A 1 } R2 R 1 R-X + X X + -X Zaáo*enia: w wyniku dekompozycji relacji R powstaje relacja S oraz jeszcze inna relacja. F - zbiór zale*noci funkcyjnych prawdziwych w R Aby wyznaczyü zbiór zale*noci funkcyjnych prawdziwych w S, nale*y rozwa*yü wszystkie podzbiory X atrybutów S i dla ka*dego wyznaczyü X +. Jeli atrybut B speánia nastpujce warunki B nale*y do S B nale*y do X + B nie nale*y do X, to zale*noü funkcyjna X B jest speániona w relacji S R Bazy danych 23 Bazy danych 24

7 Problem Trzecia postaü normalna Wystpuje jedna struktura zale*noci funkcyjnych, która mo*e powodowaü problem w trakcie dekompozycji. AB C i C B Przykáad: Relacja Zamówienia A - tytuá filmu; B - miasto, gdzie znajduje si kino; C - nazwa kina, w którym wywietlany jest film; Wyodrbniamy tutaj nastpujce zale*noci funkcyjne: kino miasto tytuá miasto kino Klucze {tytuá, miasto} {kino, tytuá} Mówimy, *e relacja jest w trzeciej postaci normalnej (3NF) wtedy i tylko wtedy, gdy jest speániony nastpujcy warunek: jeli A 1 B jest zale*noci nietrywaln, to albo {A 1 } jest nadkluczem albo B jest elementem pewnego klucza. W przykáadzie: Klucze: {tytuá, miasto} i {kino, tytuá} Relacje: kino miasto i tytuá miasto kino Czy relacja jest w 3NF? zale*noü funkcyjna kino miasto nie speánia postaci normalnej BCNF ale speánia 3NF, poniewa* miasto jest elementem klucza. Bazy danych 25 Bazy danych 26 SQL Funkcje konwersji Funkcje cd Záczenia zewntrzne TO_CHAR (liczba data[,format ]) - zamiana liczby lub daty na cig znaków zgodny z formatem opisanym w parametrze format TO_NUMBER (tekst) - zamiana cigu znaków zawierajcych liczb na dan typu NUMBER TO_DATE( tekst, format ) - zamiana cigu znaków reprezentujcych dat w formacie opisanym w parametrze format na dan typu DATE Bazy danych 27 Bazy danych 28

8 Funkcja TO_CHAR konwersja dat SQL> SELECT TO_CHAR(SYSDATE,'DAY,DD MONTH YYYY') FROM DUAL ; TO_CHAR(SYSDATE,'DAY,DDMONTHYYYY PITEK,21 PA'DZIERNIK 2005 SQL> SELECT TO_CHAR(SYSDATE,'HH:MI:SS') FROM DUAL ; TO_CHAR( :06:30 Przykáady formatów dat: YYYY, YYY, YY, Y - 4, 3, 2,lub ostatnia cyfra roku MM - miesic MONTH - nazwa miesica DDD, DD, D - dzie roku, miesica lub tygodnia DAY - nazwa dnia tygodnia HH - godzina MI - minuta; SS - sekunda Bazy danych 29 Funkcja TO_CHAR konwersja liczb SQL> SELECT TO_CHAR(SAL, '$9,999') FROM EMP; TO_CHAR $800 $1,600 $1,250 $2,975 Formaty dla liczb: Wzorzec Znaczenie PrzykáDG 9 Pozycja cyfry liczba dziewiwhnrnuh OD szerokoüz\ ZLHWODQLD 0 WyZLHWODQL]HU wiodf\fk $ Ruchomy znak dolara $99999 $1234. Pozycja kropki dziesiwqhm Bazy danych 30 Funkcja TO_NUMBER i TO_DATE SQL> SELECT EMPNO, ENAME,JOB,SAL FROM EMP WHERE SAL>TO_NUMBER('1500'); EMPNO ENAME JOB SAL ALLEN SALESMAN JONES MANAGER BLAKE MANAGER CLARK MANAGER 2450 SQL> SELECT EMPNO, ENAME, HIREDATE FROM EMP WHERE HIREDATE=TO_DATE ('GRUDZIEÑ 17, 1980','MONTH DD,YYYY'); EMPNO ENAME HIREDATE SMITH 80/12/17 Funkcje polimorficzne Funkcja DECODE Funkcje polimorficzne - funkcje, które nie s zwizane ze szczególnym typem danych, dziaáaj podobnie dla wielu ró*nych danych. DECODE - umo*liwia warunkow realizacj zapyta, gdy* dziaáa na zasadzie typu case czy if-then-else z innych jzyków. DECODE(wyra*enie, wyr1, wynik1, [wyr2, wynik2,...] wynik domylny) Uwagi: wyra*enie mo*e byü dowolnego typu wartoü wyr musz byü takiego samego typu jak wyra*enie Bazy danych 31 Bazy danych 32

9 Funkcja DECODE Funkcja DECODE SQL>SELECT ENAME, JOB, DECODE(JOB, 'CLERK','PRACOWNIK', 'MANAGER', 'SZEF', ' ') àumaczenie T FROM EMP; ENAME JOB TàUMACZEN SMITH CLERK PRACOWNIK ALLEN SALESMAN WARD SALESMAN JONES MANAGER SZEF SQL> SELECT GRADE, DECODE(GRADE, 1, '15%', 2, '10%', 4 3, '8%', 5 '5%') BONUS 6 FROM SALGRADE; GRADE BON Bazy danych % SQL> SELECT GRADE, DECODE(GRADE, 1, '15%', 2, '10%', 3, '8%', '5%') BONUS FROM SALGRADE; GRADE BON % 2 10% 3 8% 4 5% 5 5% Bazy danych 34 Inne funkcje NVL (wyra*enie1, wyra*enie2) - zmienia wartoü NULL w pierwszym argumencie na wartoü2 GREATEST (wartoü1, wartoü2,...) - zwraca najwiksz wartoü z listy LEAST(wartoü1, wartoü2,...) - zwraca najmniejsz wartoü sposród podanych argumentów Záczenia zewntrzne SELECT wyra*enia FROM tabele WHERE warunki áczce tabele [inne warunki] Dziaáanie: wywietlane s wiersze speániajce warunki záczenia SQL> select ename, dept.deptno, dname from emp, dept where emp.deptno=dept.deptno and dept.deptno in (30,40); ENAME DEPTNO DNAME ALLEN 30 SALES WARD 30 SALES MARTIN 30 SALES BLAKE 30 SALES TURNER 30 SALES JAMES 30 SALES Bazy danych 35 Bazy danych 36

10 Záczenia zewntrzne W jaki sposób wywietliü równie* informacje o departamencie 40, w którym nikt nie pracuje? SQL> select ename, dept.deptno, dname from emp, dept where emp.deptno (+) =dept.deptno and dept.deptno in (30,40); ENAME DEPTNO DNAME ALLEN 30 SALES BLAKE 30 SALES MARTIN 30 SALES JAMES 30 SALES TURNER 30 SALES WARD 30 SALES 40 OPERATIONS Departament 40 zostaá powizany z wierszem tabeli EMP zawierajcym same wartoci NULL (mimo, *e taki wiersz w tabeli naprawd nie istnieje) àczenie rozszerzone uzyskuje si za pomoc tzw. operatora zewntrznego áczenia (+). Powinien byü on umieszczany po tej stronie warunku áczcego, która dotyczy tabeli z niepeán informacj. Bazy danych 37 Powizanie tabeli samej ze sob Powizanie tabeli samej ze sob jest mo*liwe dziki zastosowaniu aliasu tabeli. Warunek áczenia odbywa si w taki sposób, jakby to byáy dwie oddzielne tabele: FROM tabela alias1 tabela alias2 Przykáad: Wybraü pracowników, którzy zarabiaj mniej od swoich kierowników. Wypisaü nazwiska i zarobki pracowników i ich kierowników. SQL> select e.ename emp_name, e.sal emp_sal, m.ename mgr_name, m.sal mgr_sal from emp e, emp m where e.mgr=m.empno and e.sal<m.sal; EMP_NAME EMP_SAL MGR_NAME MGR_SAL SMITH 800 FORD 3000 ALLEN 1600 BLAKE 2850 WARD 1250 BLAKE 2850 JONES 2975 KING 5000 MARTIN 1250 BLAKE 2850 Bazy danych 38