70840 ullman074 (2)

04 i. RELACYJNY MODEL DANYCH

będzie oczywiste, co jest kluczem relacji bez wnikania w to. które zbiory' encji są funkcyjnie zależne od innych zbiorów encji. Możemy tylko zapewnić, że:

• Jeśli ze związku wieloargumentowego R wy chodzi strzałka w kierunku zbioru encji E. to dla odpowiadającej relacji istnieje co najmniej jeden klucz, który eliminuje klucz F..

Inne notacje zależności funkcyjnych

Wyznajemy pogląd, że po lewej stronie zależności funkcyjnej może występować wiele atrybutów¹, natomiast po prawej występuje dokładnie jeden. Ponadto ten atrybut, który występuje po prawej stronie zależności nic może pojawiać się po lewej stronie tej samej zależności. Jednakże dopuszczamy skrótowy zapis dla kilku zależności, które mają takie same atrybuty z lewej strony, w postaci jednej zależności z prawą stroną otrzymaną z połączenia wszystkich prawych stron zależności wejściowych. Czasami również bywa wygodnie dopuście zależności „trywialne”, w których prawa stronę stanowi jeden z atrybutów lewej strony.

W innych opracowaniach jest prezentowany pogląd, że zarów no prawa, jak i lewa strona zależności funkcyjnej jest zbiorem atrybutów, a te same atrybuty mogą występować po obu stronach jednocześnie. Między tymi dwoma poglądami nie ma zbyt dużej różnicy, ale w naszych rozważaniach będziemy utrzymywać zasadę, żc żaden atrybut nie pojawia się jednocześnie po obu stronach zależności funkcyjnej, chyba że wyraźnie to zostanie stwierdzone.

3.5.5. Klucze relacji powstających z opisów w języku ODL

Sytuacja komplikuje się w przypadku, gdy projekt relacyjny powstaje na podstawie opisu w języku ODL. Po pierwsze w klasie ODL może być określonych wiele kluczy, a może ich nic być wcale. W takim przypadku trzeba na własną rękę wymyślić w relacji atrybut zastępujący identyfikatory obiektów klasy, w spominaliśmy już o tym problemie w p. 3.2.6.

Jednakże bez względu na to, czy klasa w języku ODL ma własny klucz, czy też trzeba tworzyć odpowiednik dla identyfikatora obiektów , istnieją takie okoliczności, kiedy klucz klasy nic może stanow ić klucza relacji. Masz sposób przekształcania projektu z postaci ODL do postaci relacji powoduje bowiem, że czasami zbył dużo danych umieszcza się w pojedynczej relacji. Problem ten pojawia się, gdy relacja jest częścią składową definicji klasy.

Załóżmy na początek, żc w klasie C określono jednow artościowy związek R. skierowany do klasy D. Wówczas zgodnie ze wskazówkami z p. 3.2.4 klucz D zostaje dołączony do relacji tworzonej dla klasy C. Klucz klasy C pozostaje nadal kluczem relacji.

Problem pojawia się wówczas, gdy związek R z C do klasy Z) jest wielo-wartościowy. Jeśli w kierunku odwrotnym związek odwrotny do R jest jed-nowartościowy (związek R jest typu jeden do wiele), to możemy związek R reprezentować wyłącznie przez jego odwrotność w relacji powstającej dla klasy D; była o tym mowa w ramce pt. „Reprezentowanie związków w jednym kierunku” w p. 3.2.7. Odwrotność związku R nie stwarza problemu, ponieważ w klasie D jest on jednow artościowy.

Ale załóżmy, że związek R jest typu wiele do wiele, a wiec w obu kierunkach między klasami CaD związek ten jest wielo wartościowy. Wówczas może się zdarzyć, ze w relacji tworzonej dla klasy C wystąpi wiele krotek reprezentujących pojedynczy obiekt klasy C. A zatem klucz klasy C nie będzie mógł być kluczem w odpowiadającej klasie C relacji. Aby otrzymać klucz relacji odpowiadającej klasie C. trzeba będzie połączyć klucze klas C i D.

PRZYKŁAD 3.25

W przykładzie 3.7, tworząc relację odpowiadającą klasie ODL Film, do atrybutów relacji Film dołączyliśmy:

1. Klucz nazwaStudia z. klasy Sr.udio, z którą klasa Film jest połączona związkiem jednowartościowym należyDo oraz

2. Klucz nazwiskoGwiazdy z klasy Gwiazda (z którą klasa Film jest objęta związkiem wielowartościowym gwiazdy).

Pierwszy z nich pochodzi z jednowartościowego związku, a zatem nie ma wpływu na klucz relacji Film. Jednakże drugi z nich, ponieważ pochodzi ze związku wielowartościowego, musi zostać dołączony do zbioru atrybutów klucza relacji Film, który przyjmuje następującą postać:

{tytuł, rok, nazwiskoGwiazdy}.

Analiza przykładu relacji r lim z rys. 3.13 stanowi potwierdzenie tego, że same atrybuty tytuł i rok nie stanowią klucza relacji Fi m, ale dołączenie do tego zbioru atrybutu nazwiskoGwiazdy już wystarczy do określenia klucza.

□

Mówiąc ogólniej: jeśli w relacji dla klasy C trzeba reprezentować kilka związków wielowartościowych z C, to wszystkie klucze klas, uczestniczących W' tych związkach wraz z klasą C, trzeba dołączyć do pierwotnego klucza klasy C i dopiero wówczas powstaje klucz relacji C. Jeśli kilka związków wielowartościowych łączy klasę C z tą sama klasą D, to w relacji C pojawiają się różne atrybuty reprezentujące klucz klasy D w różnych związkach C i D.

Często zdarza się, że trzeba poprawiać projekt relacji, otrzymany w wyniku postępowania zgodnego z procedurą tworzenia relacji, którą opisano w podrozdziale 3.2, ponieważ klucz, klasy z ODL może paradoksalnie nie być

Wyszukiwarka

Podobne podstrony:
53442 ullman073 (2) 15Z 3. RELACYJNY MODEL DANYCH {tytuł, rok, nazwiskóGwiazdy) jest nadkluczem, ale
ullman094 (2) 194 3. RELACYJNY MODEL DANYCH atrybutów typu B. A oczywiście krotka u jest zgodna sama
16212 ullman068 (2) 142 3. RELACYJNY MODEL DANYCH sy i broń, które pochodzą z pozostałych dwóch nadk
18968 ullman090 (2) 186 3. RELACYJNY MODEL DANYCH spełniają zadane zależności funkcyjne. Natomiast p
28640 ullman078 (2) 162 3. RELACYJNY MODEL DANYCH PRZYKŁAD 3.28 Rozważmy relację z atrybutami: A, B,
ullman059 (2) 124 .1 RELACYJNY MODEL DANYCH miały strukturę złożoną zbioru lub zbioru struktur. W pr
ullman060 (2) 126 3 RELACYJNY MODEL DANYCH szczególnych wartości. I tak jak w przypadku atrybutów o

więcej podobnych podstron