87122 ullman091 (2)

188 3 RELACYJNY MODKJ. DANYCH

JĆwiczcnie 3.7.3. Załóżmy, żc relacja R jest taka sama jak w ćwiczeniu 3.7.2, ale zachodzą w niej zależności: A —* B oraz B -> C. Teraz także porównajmy wyniki dekompozycji ze względu na zależność A —> B oraz A -> BC. Wskazówko: wykonując dekompozycję, trzeba przewidywać, jakie zależności będą zachodzić w wynikowych relacjach. Czy wystarczy korzystać tylko z tych podanych zależności, w których występują atrybuty z relacji wynikowej? Jak korzystać z zależności wynikających z podanych zależności?

{Ćwiczenie 3.7.4. Niech dana będzie relacja R(A> B, C), w której zachodzi zależność funkcyjna A —* B. Załóżmy również, że wykonamy dekompozycję, w wyniku której powstają schematy S(A, B) oraz T(B. C). Należy podać przykład takiej instancji relacji R_f dla której rzutowanie i ponowne złączenie (jak to opisano w p. 3.7.6) powoduje uzyskanie innej instancji.

!Ćwiczenie 3.7.5. Załóżmy, że po dekompozycji relacji R(A, B, C, £>, £) otrzymujemy relację S(A, B, Q oraz inną dowolną relację. Należy określić zależności funkcyjne w S dla następujących przypadków- zależności funkcyjnych w R:

*a) AB -* DE, C > E, D —> C oraz E -> A

b)    A -* D. BD —* E, AC -+ E i DE -* B.

c)    AB -* D, AC > £, BC —* D, D —* A \ F, —* B

d)    A—*B,B—*C_yC—>D.D-+EiE—>A

W każdym zadaniu wystarczy podać minimalną bazę zależności w 5.

3.8. Zależności wielowartościowe

„Zależności wielowartościowe’' występują wówczas, gdy dwa lub więcej atrybutów jest od siebie niezależnych. Później przekonamy się, że jest to uogólnienie pojęcia zależności funkcyjnej w tym sensie, żc każda zależność wielowartościowa wynika z zależności funkcyjnej. Istnieją jednak takie sytuacje, kiedy niezależności zbioru atrybutów nie można wytłumaczyć tak jak zależności funkcyjne. W bieżącym podrozdziale określimy powody powstawania zależności wielo wartościowych oraz sposoby korzystania z nich przy projektowaniu schematów baz danych.

3.8.1. Niezależność atrybutów i wynikająca stąd redundancja

Przy projektowaniu schematów relacyjnych często okazuje się, żc schemat ma postać BCNF, ale występuje w nim redundancja, która nie ma związku z zależnościami funkcyjnymi. Najpowszechniejszym źródłem redundancji w schematach BCNF jest niezależność dwóch lub więcej atrybutów wielo-wartościowych pewnej klasy, której projekt przekształcamy z postaci zapisa nej w języku ODL do postaci relacyjnej (co opisano w podrozdziale 3.2).

PRZYKŁAD 3.43

Załóżmy, że w klasie Gwiazda określono atrybuty nazwisko, zbiór adresóv oraz zbiór filmów, w których gwiazda występuje. Definicja tej klasy jest po dobna do tej z rys. 2.5, zmienia się tylko typ atrybutu adres. Tę nową defini cję przedstawiono na rys. 3.38.

interface Gwiazda {

attribute string nazwisko; attribute Set <

Struct Adr {string ulica, string miasto} >address;

relationship Set <Film> występujeW inverse Film::gwiazdy;

};

RYSUNEK 3.38

Definicja gwiazd obejmująca ich adresy i filmy

Z kolei na rys. 3.39 przedstawiono przykładowe krotki lej relacji, w pt staci wynikającej bezpośrednio z definicji klasy z rys. 3.38. Krotki został rozszerzone o składowe odpowiadające atrybutom tytuł oraz rok, które i kluczem klasy Film. Określają one filmy powiązane z gwiazdą związkiei

występuj eW.

nazwisko	ulica	miasto	tytuł	rok
C. Fisher	123 Mapie SI.	Hollywood	Gwiezdne Wojny	1977
C. Fisher	5 Locus Ln.	Malibu	Gwiezdne Wojny	1977
C. Fisher	123 Mapie St.	Hollywood	Imperium kontratakuje	1980
C. Fisher	o 7,ocus Ln.	Malibu	Imperium kontratakuje	1980
C. Fisher	123 Mapie St.	Hollywood	Powrót Jedi	1982
C. Fisher	5 Locus Ln.	Malibu	Powrót Jedi	198 2

RYSUNEK 3.39

Niezależne zbiory adresów i filmów

Na rysunku 3.39 wybraliśmy krotki odpowiadające Carrie Fisher i j dwóm adresom oraz trzem najbardziej znanym filmom, w których wystąpi! Nie ma powodu, by adres wiązać z jednym filmem, a z innym nie. Jedyi sposób wyrażenia faktu, iż adresy i filmy są niezależnymi od siebie właś<