ullman099 (2)

ullman099 (2)



3 RELACYJNY MODEL DANYCH

utworzeniu dla każdej podklasy osobnej relacji z właściwymi dla niej atrybutami. Postępując według drugiego sposobu, należy wszystkie eneje lub obiekty reprezentować w relacji nadrzędnej wyłącznie przez atrybuty z najbardziej ogólnej klasy. Encjc i obiekty, należące do pod-klas, wystąpią także w klasach, do których są przypisane specyficznie. W tych relacjach występują tylko atrybuty kluczowe klas nadrzędnych oraz specyficzne atry buty podklasy.

♦    Zależności funkcyjne: Zależność funkcyjna jest wyrażeniem, w którym jest zawarta informacja o tym, że jeśli dwie krotki mają identyczne wartości dla pewnej grupy atrybutów, to również muszą wówczas mieć identyczną wartość pewnego innego atrybutu.

♦    Klucze-. Nadkluczem relacji nazywa się taki zbiór atrybutów, od którego wszystkie inne atrybuty relacji są zależne funkcyjnie. Nadklucz jest kluczem, jeśli nie istnieje laki właściwy podzbiór zbioru jego atrybutów, który jest kluczem.

♦    Wnioskowanie o zależnościach funkcyjnych: Istnieje wiele reguł, których stosowanie pozwala wnioskować o tym, że jeśli w pewnej instancji relacji zachodzą określone zależności funkcyjne, to zachodzi również pew na zależność X —► A. Aby sprawdzić, w najprostszy sposób, czy jest spełniona jakaś zależność X—> A, należy' zazwyczaj obliczyć domknięcie zbioru X, stosując daną zależność tak długo, aż rozszerzany w ten sposób zbiór Albedzie zawierał wszystkie elementy ze zbioru A.

♦    Dekompozycja relacji: Można dekomponować schemat relacyjny na dwa inne bez utraty danych lak długo, aż atrybuty w obu otrzymanych schematach utworzą nadklucze dla przynajmniej jednej z dekompo-nowanych relacji.

♦    Postać normalna Boyce 'a-Codda: Relacja jest w' postaci BCNF, jeśli tylko z nietrywialnych zależności wynika, że pewien nadklucz. wyznacza funkcyjnie jakiś inny atrybut. Bez utraty danych można każdą relację dekomponować do zbioru relacji, gdzie wszystkie są w postaci BCNF. Dzięki zapisow i relacji w postaci BCNF można uniknąć tych redundancji, które są spowodowane istnieniem określonych zależności funkcyjnych.

♦    Trzecia postać normalna: Czasami dzięki dokonaniu dekompozycji do postaci BCNF można uniknąć sprawdzania pewnych zależności funkcyjnych. Trochę słabszą postacią niż BCNF jest 3NF, która polega na tym, że dopuszcza się zależność funkcyjną X —* A nawet wówczas, gdy X nie jest nadkluczem, lecz A jest częścią pewnego klucza. W postaci 3NF może się pojawić redundancja spowodowana przez zależności funkcyjne, jednak najczęściej nie ma jej.

♦    Zależności wielowar(ościowe: Zależność wielowartościowa występuje wówczas, gdy istnieją takie dwa zbiory atrybutów relacji, których wartości występują w relacji we wszystkich dowolnych kombinacjach. Zależność taka pojawia się najczęściej wtedy, gdy w relacji reprezen-

tuje się klasę ODL z dwoma w i elo wartość iowy m i atrybutami lub związkami.

Czwarta postać normalna: Często przyczyną redundancji są również zależności wielowartościowe. Postać 4NF przypomina postać BCNF, ale dodatkowo eliminuje ze schematu zależności wielowartościowe (chyba żc są to zależności funkcyjne w postaci BCNF). Można bez utraty danych dokonać dekompozycji schematu do postaci 4NF.

3.11. Literatura do rozdziału 3

Pozycja [4] zawiera klasyczny opis modelu relacyjnego utworzony przez Codda. W tym artykule pojawiają się pojęcie zależności funkcyjnych oraz. podstawowe pojęcia relacyjne. Tutaj także opisano trzecią posiać normalną, ale postać normalna Hoyce’a-Codda została przedstawiona w późniejszym artykule [5|.

Zależności wielowartościowe oraz czwarta postać normalna zostały zdefiniowane przez Fagina w |7|. Niezależnie pomysł zależności wielowartościowych pojawił się także w opracowaniach I6| oraz [9].    '

Reguły wnioskowania dla zależności funkcyjnych po raz pierwszy określił Armstrong fi). Reguły, które zostały tutaj przedstawione (także te. które nazwaliśmy aksjomatami Armstronga). a lakżc reguły wnioskowania dla zależności wielowartościowych pochodzą z pracy [2). Technika testowania zależności funkcyjnych za pomocą domknięcia zbioru atrybutów pochodzi z kolei z opracowania [3].

W książce nie zmieściło się wiele algorytmów ar.i dowodów ich poprawności. Nie pojawiają się zatem ani dowód poprawności algorytmu domknięcia dla wnioskowania o zbiorze zależności funkcyjnych, ani opis tego. w jaki sposób wnioskować o zależnościach wiclowartościo-wych. ani w jaki sposób rzutować zależności wielowartościowe na relacje wynikowe, ani też w jaki sposób zastosować dekompozycję do postaci 3NF bez utraty możliwości przetestowania zależności funkcyjny ch. Tc oraz jeszcze inne zagadnienia zostały wytłumaczone w pracy [8].

1.    Armstrong W. W.: Dcpcndcncy structurcs of database relationships Proceedings of the i974IFIP Congress. s. 580-583.

2.    Bceri C.. Fagin R.. Howard J. H.: A complctc axiomatization lor iunctional and niultivalu-ed depcndcncics. ACM SJCMOD International Conference on Management of Data. $. 47-61, 1977.

3.    Bernstein P. A.: Synthcsizing third norma! form relations from tunctional dependencics. ACM Transactions on Database Systems 1:4. s. 277-298, 1976.

4.    Codd Lv. I\: A relational model for large shared dat banks. Comm. ACM 13:6, s.377-387. 1970.

5.    Codd 15. F.: Further normalization of the data basc relational model, w Database Systems (R. RuSlin. ed.). Prcnlice Hali, Englcwood CłifFs, NJ. 1972.

6.    Delobel, C: Normalization and hicrarchical dependencies in the relational data model. ACM Transactions on Database Systems 3:3, s. 201-222, 1978.

7.    Fagin R.: Multiva!ued dependencies and a ncw normal form for relational databases. ACM Transactions on Database Systems 2:3, s. 262-278. 1977.

8.    Ullman J. D.: Principles of Database and Knowledge-Base. Systems. Volume 1. Computer Science Press. Ncw York. 1988.

9.    Zaniolo C., MelkanofTM. A.: On the design of relational database schemata. ACM Tran-sactions on Database Systems 6:1. s. 1-47. 1981


Wyszukiwarka

Podobne podstrony:
70840 ullman074 (2) 04 i. RELACYJNY MODEL DANYCH będzie oczywiste, co jest kluczem relacji bez wnika
74563 ullman069 (2) 3. RELACYJNY MODEL DANYCH ciu. jeśli chcemy odszukać określony obiekt, to tr/.cb
ullman097 (2) 3. RELACYJNY MODEL DANYCH “a) Reguła sumowania (The union rule). Jeśli X, Y Z są nazw
40421 ullman052 (2) 3_Relacyjny model danych Mimo że omawiane w rozdziale drugim podejście do projek
33758 ullman093 (2) 192 3 RELACYJNY MODEL DANYCH Oznacza lo, że dla każdej gwiazdy zbiór adresów mus
ullman072 (2) 150 3. RELACYJNY MODEL DANYCH każdej gwiazdy, która wystąpiła w tym filmie. Dlatego te
ullman094 (2) 194 3. RELACYJNY MODEL DANYCH atrybutów typu B. A oczywiście krotka u jest zgodna sama
39559 ullman067 (2) 140 3. RELACYJNY MODEL DANYCH RYSUNEK 3.21 Diagram E/R dla okrętów siostrzanych
16212 ullman068 (2) 142 3. RELACYJNY MODEL DANYCH sy i broń, które pochodzą z pozostałych dwóch nadk

więcej podobnych podstron