Bazy danych - Politechnika Białostocka

Plan wykáadu
•
•
•
•
•
Bazy danych
Wykáad 4: Relacyjny model danych zale*noci funkcyjne.
Deficja zale*noci funkcyjnych
Klucze relacji
Reguáy dotyczce zale*noci funkcyjnych
Domkni
cie 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, dzi
ki 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
Maágorzata Kr
towska
Wydziaá Informatyki
Politechnika Biaáostocka
•
SQL - funkcje cd. Záczenia zewn
trzne.
Bazy danych
2
Definicja zale*noci funkcyjnych
Zale*noci funkcyjne
A→B
Zale*noü funkcyjna:
A1A2...An → B
Interpretacja: jeli dwie krotki relacji R s zgodne dla atrybutów A1,
A2, .., An (tzn. obie krotki maj takie same wartoci skáadowych
dla wymienionych atrybutów), to musz byü równie* zgodne w
pewnym innym atrybucie B.
A
B
x
– Odczyt zapisu: „A1, A2, ..., An okrelaj funkcyjnie B”
– Jeli zbiór atrybutów A1, A2, ..., An okrela funkcyjnie wi
cej ni*
jeden atrybut tzn.
y
A1A2...An → B1
A1A2...An → B2
A1A2...An → B3
To taki zbiór zale*noci skrótowo przedstawiamy jako:
Jeli x i y s
zgodne dla
atrybutów A
A1A2...An → B1B2B3
Bazy danych
3
Bazy danych
To musz byü
zgodne równie*
dla atrybutów B
4
Klucze relacji
Nadklucze
• Atrybut lub zbiór atrybutów {A1, A2,..., An} tworzy klucz relacji,
jeli:
• Nadklucz - zbiór atrybutów, który zawiera klucz
• Ka*dy klucz jest nadkluczem
– 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 A1, A2,..., An.
– Nie istnieje taki podzbiór wáaciwy zbioru {A1, A2,..., An}, od którego
pozostaáe atrybuty relacji R s zale*ne funkcyjnie, tzn. klucz musi
byü minimalny
– 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
Reguáy wykrywania kluczy w relacji
Klucze relacyjne i E/R
• Reguáa 1
• Klucze w ERD s atrybutami encji
– Jeli relacja pochodzi z przeksztaácenia zbioru encji, to jej kluczem
s atrybuty kluczowe tego zbioru encji
• Klucze w relacjach s atrybutami krotek
• Reguáa 2 (dotyczy zwizków binarnych)
• Zazwyczaj, jedna krotka odpowiada jednej encji, wówczas idea
jest taka sama
– Jeli zwizek jest typu wiele do wiele, to klucze obu zbiorów encji
obj
tych 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.
Bazy danych
6
• W niewáaciwie skonstruowanych relacjach, jedna encja mo*e
byü opisana przez kilka krotek, wówczas klucze w diagramach
E/R i relacjach b
d si
ró*niáy.
7
Bazy danych
8
Zasady podziaáu i áczenia
Reguáy dotyczce zale*noci funkcyjnych
• Zasady, które pozwalaj na zast
powanie zbioru zale*noci
funkcyjnych zbiorami równowa*nymi lub na doáczanie do zbioru
tych zale*noci, które wynikaj ze zbioru pocztkowego.
• Reguáa podziaáu
Zale*noü funkcyjn A1A2...An → B1B2 ... Bm mo*emy zastpiü zbiorem
zale*noci funkcyjnych A1A2...An → Bi, gdzie i=1,2,...,m
• Wyró*niamy nast
pujce reguáy:
• Reguáa áczenia
– reguáa áczenia
– reguáa podziaáu
– reguáa przechodnioci
Bazy danych
Zbiór zale*noci funkcyjnych A1A2...An → Bi, gdzie i=1,2,...,m mo*emy
zastpiü pojedyncz zale*noci funkcyjn A1A2...An → B1B2 ... Bm
9
Bazy danych
Zale*noci trywialne
Domkni
cie zbioru atrybutów
• Zale*noü funkcyjna A1A2...An → B jest trywialna, jeli B jest
równe któremu z A
• Zaáo*enia:
– {A1, A2, ..., An} - zbiór atrybutów
– S - zbiór zale*noci funkcyjnych
– tytuá rok → tytuá
• Mówimy, *e zale*noü A1A2...An → B1B2 ... Bm 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
• Domkni
ciem zbioru {A1, A2, ..., An} 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ü A1 A2... An → B, a zatem zale*noü A1 A2... An → B
wynika z S.
• Atrybuty, które wyst
puj równoczenie z prawej i lewej strony
zawsze mo*na pominü po prawej tronie, std prawdziwe jest
twierdzenie (reguáa zale*noci trywialnych)
• Domkni
cie zbioru atrybutów {A1, A2, ..., An} oznaczamy przez
{A1, A2, ..., An}+.
– Zale*noü funkcyjna A1A2...An → B1B2 ... Bm jest równowa*na zale*noci
A1A2...An → C1C2 ... CK, gdzie C s tymi elementami z B, które nie s równe
A.
Bazy danych
10
11
Bazy danych
12
Algorytm obliczania domkni
cia zbioru
atrybutów {A1, A2, ..., An}
Przykáad
• Niech X oznacza nazw
zbioru domkni
cia.
Na pocztku X= {A1, A2, ..., An}.
• Znajdujemy tez wszystkie zale*noci funkcyjne postaci
B1B2 ...Bm → C
X+
gdzie B1B2 ...Bm nale* do zbioru X, a C nie nale*y. Wówczas
doáczamy C do zbioru X.
Y
B
Nowy X+
• Powtarzamy krok 2 tak dáugo, jak dáugo nie b
dzie mo*na
doáczyü do X *adnego nowego atrybutu.
• Jeli ju* *adnego atrybutu nie mo*na doáczyü do X, to znaczy,
*e otrzymalimy domkni
cie zbioru {A1, A2, ..., An}+
Bazy danych
13
Bazy danych
14
Cel
Domkni
cie i klucze
• Majc dane domkni
cie zbioru atrybutów {A1, A2, ..., An} mo*emy
sprawdziü, czy dana zale*noü funkcyjna wynika ze zbioru
zale*noci S.
• Zbiór {A1, A2, ..., An}+ zawiera wszystkie atrybuty relacji R wtedy i
tylko wtedy, gdy elementy A1, A2, ..., An s nadkluczem w R.
• Stwierdzenie, czy atrybuty A1, A2, ..., An stanowi klucz relacji,
mo*e polegaü na sprawdzeniu:
• Jeli B nale*y do {A1, A2, ..., An}+ to oznacza, *e
A1A2...An → B
– czy wszystkie atrybuty R nale* do zbioru {A1, A2, ..., An}+
– czy X+ otrzymane z dowolnego X, który utworzymy przez usuni
cie
choüby jednego elementu sporód A1, A2, ..., An, nie zawiera
wszystkich atrybutów R
wynika z S.
• Przykáad:
–
–
–
–
Bazy danych
15
Bazy danych
Relacja Filmy(tytuá, rok, czas, rodzaj, nazwaStudia, adresStudia)
Uzasadniü, *e kluczem jest zbiór (tytuá, rok)
tytuá rok → nazwaStudia
nazwaStudia → adresStudia
16
Reguáa przechodnioci
Plan wykáadu
• Proces dobrego projektowania relacyjnego schematu bazy
danych:
• Reguáa przechodnioci umo*liwia kaskadowe áczenie
zale*noci:
– 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, dzi
ki 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
– jeli w relacji R zachodz zale*noci A1A2...An → B1B2 ... Bm oraz
B1B2 ... Bm → C1C2...Ck , to w relacji R zachodzi tak*e zale*noü
A1A2...An → C1C2...Ck.
– Uzasadnienienie powy*szej reguáy => wyliczenie domkni
cia {A1,
A2, ..., An}+.
• SQL cd
Bazy danych
17
Bazy danych
Anomalie
Dekompozycja relacji
• Anomalie - problemy, jakie powstaj, gdy próbujemy do
pojedynczej relacji wáczyü zbyt wiele danych
• Dekompozycja relacji - sposób eliminowania wymienionych
anomalii przez podziaá atrybutów relacji R mi
dzy dwa schematy
nowych relacji.
• Relacj
R o schemacie {A1, A2,..., An} dekomponujemy mi
dzy
dwie relacji S i T o schematach odpowiednio {B1, B2,..., Bm} i {C1,
C2,..., Ck} wedáug nast
pujcych zasad:
– redundancja - dane niepotrzebnie powtarzaj si
w kilku krotkach
– anomalie modyfikacji - sytuacje, w których wartoü zostaje
zmodyfikowana w jednej krotce, a w innej nie
– {A1, A2,..., An} = {B1, B2,..., Bm} ∪ {C1, C2,..., Ck}
– Krotki relacji S powstaj przez rzutowanie wszystkich krotek relacji
R na zbiór atrybutów {B1, B2,..., Bm}, tzn. z ka*dej krotki t bie*cej
instancji relacji R pobieramy wartoci atrybutów {B1, B2,..., Bm} 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.
– anomalie usuni
ü - usuni
cie krotki mo*e powodowaü usuni
cie
wa*nej informacji z bazy danych
Bazy danych
18
19
Bazy danych
20
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 wyst
puj omówione
wczeniej anomalie.
Jeli proces dekompozycji b
dziemy powtarzaü dostatecznie dáugo, to
ka*da otrzymana relacja b
dzie si
skáadaáa z kolekcji podzbiorów
atrybutów, które:
– b
d schematami relacji w postaci BCNF
– dane z pierwotnej relacji b
d wiernie reprezentowane w relacjach
powstaáych w wyniku dekompozycji => b
dzie istniaáa mo*liwoü
dokáadnego odtworzenia pierwotnej relacji, na podstawie relacji
utworzonych przez wielokrotne dekompozycje.
• Relacja R jest w postaci normalnej BCNF wtedy i tylko wtedy,
gdy dla ka*dej nietrywialnej zale*noci A1, A2,..., An →B, zbiór
{A1, A2,..., An} jest nadkluczem R
•
Strategia dekompozycji:
– Dane: relacja R z zale*nociami funkcyjnymi ZF
– Znalezienie pewnej nietrywialnej zale*noci funkcyjnej {A1, A2,..., An} →
{B1, B2,..., Bm} , która narusza warunek BCNF (tzn. {A1, A2,..., An} nie jest
nadkluczem).
– Wyliczenie dopeánienia zbioru atrybutów {A1, A2,..., An}+.
• Dopeánienie zawiera wszystkie atrybuty, gdy {A1, A2,..., An} jest
nadkluczem.
Bazy danych
21
Dekompozycja R do postaci BCNF
R-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 nast
pujce 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
R1
X
22
Projektowanie zale*noci funkcyjnych
– Zamie relacj
R na relacje o schematach:
• R1= {A1, A2,..., An}+
• R2 = (R-{A1, A2,..., An}+) ∪ {A1, A2,..., An}
R2
Bazy danych
X+-X
R
Bazy danych
23
Bazy danych
24
Problem
Trzecia postaü normalna
• Wyst
puje jedna struktura zale*noci funkcyjnych, która mo*e
powodowaü problem w trakcie dekompozycji.
AB →C i C → B
Mówimy, *e relacja jest w trzeciej postaci normalnej (3NF) wtedy i
tylko wtedy, gdy jest speániony nast
pujcy warunek:
jeli A1, A2,..., An→ B jest zale*noci nietrywaln, to albo {A1, A2,..., An} jest
– Przykáad: Relacja Zamówienia
• A - tytuá filmu;
• B - miasto, gdzie znajduje si
kino;
• C - nazwa kina, w którym wywietlany jest film;
– Wyodr
bniamy tutaj nast
pujce zale*noci funkcyjne:
• kino → miasto
• tytuá miasto → kino
– Klucze
• {tytuá, miasto}
• {kino, tytuá}
Bazy danych
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.
25
Bazy danych
SQL
26
Funkcje konwersji
• Funkcje cd
• Záczenia zewn
trzne
• 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
Funkcja TO_CHAR
konwersja dat
•
Funkcja TO_CHAR
konwersja liczb
SQL> SELECT TO_CHAR(SYSDATE,'DAY,DD MONTH YYYY') FROM DUAL
;
•
•
SQL> SELECT TO_CHAR(SAL, '$9,999') FROM EMP;
TO_CHAR
------$800
$1,600
$1,250
$2,975
TO_CHAR(SYSDATE,'DAY,DDMONTHYYYY
-------------------------------,21 PA'DZIERNIK 2005
PITEK
SQL> SELECT TO_CHAR(SYSDATE,'HH:MI:SS') FROM DUAL
;
TO_CHAR(
-------02:06:30
Formaty dla liczb:
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
•
099999
1234
001234
$99999
$1234
99999.99 1234.00
30
Funkcje polimorficzne
Funkcja DECODE
SQL> SELECT EMPNO, ENAME,JOB,SAL FROM EMP WHERE
SAL>TO_NUMBER('1500');
EMPNO ENAME
JOB
---------- ---------- --------- ---------7499 ALLEN
SALESMAN
7566 JONES
MANAGER
7698 BLAKE
MANAGER
7782 CLARK
MANAGER
PrzykáDG
99999
Bazy danych
Funkcja TO_NUMBER i TO_DATE
•
Wzorzec Znaczenie
9
Pozycja cyfry – liczba
dziewiWHNRNUH OD
szerokoüZ\ ZLHWODQLD
0
WyZLHWODQL]HU
wiodF\FK
$
Ruchomy znak dolara
.
Pozycja kropki
dziesi
WQHM
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 j
zyków.
SAL
1600
2975
2850
2450
• DECODE(wyra*enie, wyr1, wynik1,
SQL> SELECT EMPNO, ENAME, HIREDATE FROM EMP WHERE
HIREDATE=TO_DATE ('GRUDZIEÑ 17, 1980','MONTH DD,YYYY');
[wyr2, wynik2,
......................]
wynik domylny)
EMPNO ENAME
HIREDATE
---------- ---------- -------7369 SMITH
80/12/17
Uwagi:
– wyra*enie mo*e byü dowolnego typu
– wartoü wyr musz byü takiego samego typu jak wyra*enie
Bazy danych
31
Bazy danych
32
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
1 15%
SQL> SELECT GRADE,
DECODE(GRADE, 1, '15%',
2, '10%',
3, '8%',
'5%') BONUS
FROM SALGRADE;
GRADE BON
---------- --1 15%
2 10%
3 8%
4 5%
5 5%
•
33
Bazy danych
Inne funkcje
Záczenia zewn
trzne
SELECT wyra*enia
FROM tabele
WHERE warunki áczce tabele [inne warunki]
Dziaáanie:
wywietlane s wiersze speániajce warunki záczenia
• NVL (wyra*enie1, wyra*enie2) - zmienia wartoü NULL w
pierwszym argumencie na wartoü2
• GREATEST (wartoü1, wartoü2,...) - zwraca najwi
ksz
wartoü z listy
•
• LEAST(wartoü1, wartoü2,...) - zwraca najmniejsz wartoü
sposród podanych argumentów
Bazy danych
34
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
35
Bazy danych
36
Záczenia zewn
trzne
Powizanie tabeli samej ze sob
• W jaki sposób wywietliü równie* informacje o departamencie
40, w którym nikt nie pracuje?
•
•
•
Powizanie tabeli samej ze sob jest mo*liwe dzi
ki 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;
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
•
•
EMP_NAME
EMP_SAL MGR_NAME
---------- ---------- ---------- ---------SMITH
800 FORD
3000
ALLEN
1600 BLAKE
2850
WARD
1250 BLAKE
2850
JONES
2975 KING
5000
MARTIN
1250 BLAKE
2850
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 zewn
trznego áczenia (+).
Powinien byü on umieszczany po tej stronie warunku áczcego, która dotyczy tabeli z
niepeán informacj.
Bazy danych
37
Bazy danych
MGR_SAL
38