3

Relacyjny model danych

Mimo że omawiane w rozdziale drugim podejście do projektowania baz danych, oparte na związkach encji i zorientowane obiektowo, są użyteczne i właściwe do opisu struktur danych, to obecnie implementacje bazy danych prawie zawsze opierają się na innym sposobie podejścia, nazywanym modelem relacyjnym. Ten relacyjny model jest najbardziej użyteczny, co wynika z faktu, że bazuje on na jednym pojęciu modelowania danych: na relacji, czyli dwuwy­miarowej tabeli, do której wpisuje się dane. W rozdziale 5 przekonamy się, że właśnie model relacyjny jest odpowiedni do współdziałania z językiem zapytań bardzo wysokiego poziomu SQL (structured query language - strukturalny język zapytań). W języku SQL można zapisywać proste programy, które gene­rujązłożone wyniki, operując na danych zapamiętanych w postaci relacji.

Często jednak jest łatwiej zaprojektować bazę danych w jednym z modeli opisanych w rozdziale 2. Dlatego naszym podstawowym celem jest poznanie sposobu przekształcenia projektu zapisanego w jednej z tamtych notacji do postaci modelu relacyjnego. Potem okaże się, że model relacyjny obejmuje również właściwą sobie teorię projektowania. Teoria ta bywa często nazywa­na normalizacja relacji i operuje pojęciem „zależności funkcyjnych", które z kolei rozszerza pojęcie klucza; klucze w sposób nieformalny już opisano w p. 2.5.1. Korzystając z teorii normalizacji, często udaje się poprawić relacje opisujące pewien projekt bazy danych.

3.1. Podstawy modeli relacyjnych

Model relacyjny dostarcza tylko jednego sposobu reprezentowania da­nych: jest nim dwuwymiarowa tabela, nazywana relacja. Przykład relacji przedstawiono na rys. 3.1. Nazwą relacji jest Film i zamierzamy w niej przechowywać takie same dane, jak w prostej klasie modelu ODL o nazwie Film, która była zdefiniowana w przykładzie 2.1 na rys. 2.4 oraz powtórzona

3.1. PODSTAWY MODELI RELACYJNYCH I ł I

na rys. 3.2. Warto przypomnieć sobie, że nie była to ostateczna wersja definicji klasy Film i obejmowała tylko atrybuty tytuł, rok, długość i typFilmu.

tytuł rok Gwiezdne Wojny 1977 Potężne Kaczory 1991 Świat Wayne'a 1992

cllugość typFihrau

124 kolor

104 kolor

95 kolor

RYSUNEK 3.1 Relacja Film

1) interface Film{

2) attribute string tytuł; 3) attribute integer rok;

4) attribute integer długość;

5) attribute enumeration (kolor, czarno-biały) typFilmu;

};

RYSUNEK 3.2

Opis klasy Film w języku ODL

3.1.1. Atrybuty

W nagłówku relacji są podane atrybuty. Na rysunku 3.1 atrybutami są: tytuł, rok, długość i typFilmu. Atrybuty relacji służą do nazywania kolumn relacji. Na ogół atrybuty oddają znaczenie danych umieszczanych w kolumnach pod nimi. Na przykład w kolumnie z atrybutem długość umieszcza się czas trwania (czyli długość) poszczególnych filmów.

Zauważmy, że atrybuty relacji Film z rys. 3.1 odpowiadają elementom struktury danych definicji ODL z rys. 2.4, nazywanym tam również atrybuta­mi. Taki sposób dobierania atrybutów relacji jest dość powszechny. Jednak to, że atrybuty relacji mają jakieś odpowiedniki w składnikach modelu encji lub obiektowym modelu opisu danych, nie musi być obowiązująca regułą.

3.1.2. Schematy

Nazwa relacji oraz jej zbiór atrybutów nazywają się schematem relacji. Schemat relacji zapisujemy za pomocą jej nazwy, po której występuje lista atrybutów ujęta w nawiasy okrągłe. Schemat relacji Film z rys. 3.l jest na­stępujący:

Film (tytuł, rok, długość, typFilmu)

I Z 2 3. RELACYJNY MODEL DANYCH

Mimo że atrybuty schematu relacji nie stanowią listy, bowiem są zbiorem, to aby móc opowiadać o relacji, często trzeba określić „standardowy" porządek atrybutów. Stąd też, jeśli gdziekolwiek wprowadzimy schemat relacji w po­wyższej postaci, z listą atrybutów, to porządek na liście będziemy traktować wiążąco i przestrzegać go wszędzie tam, gdzie trzeba będzie rysować relacje lub jej wiersze.

W modelu relacyjnym projekt składa się z jednego lub kilku schematów relacji. Zbiór schematów relacji projektu jest określany schematem relacyj­nym bazy danych lub po prostu schematem bazy danych.

3.1.3. Krotki

Wiersze relacji, poza wierszem nagłówka, zawierającym atrybuty relacji, są nazywane knotkami. W krotce każdy atrybut ma swój odpowiednik w po­staci składowej knotki. Na przykład pierwsza z trzech knotek z rys. 3.1 ma cztery skladowe: Gwiezdne Wojny, 1977, 124 oraz kolor, które są kolęj­nymi wartościami atrybutów: tytuł, rok, długość oraz typFilmu. Jeśli przedstawiamy wyodrębnioną krotkę, a nie wskazujemy wiersza relacji, to jej składowe oddzielamy przecinkami, a samą krotkę ujmujemy w nawiasy. Na przykład:

(Gwiezdne Wojny, 1977, 124, kolor)

jest pierwszą krotką z rys. 3.1. Zauważmy, że jeśli knotka występuje osobno, nie w tabeli, to nie ma opisanych atrybutów, zatem trzeba mieć jakąś dodat­kową wskazówkę, aby określić, o którą relację chodzi. Dlatego będziemy stosować ten sam porządek wartości, w którym definiuje się atrybuty w sche­macie relacji.

Często traktuje się knotki tak jak obiekty, a relacje, tak jakby były klasami tych obiektów. Na pewno tak się dzieje z naszą przykładową relacją filmów, każda knotka reprezentuje obiekt typu film. Składowe knotek i właściwości obiektów z klasy opisanej na rys. 3.2 są identyczne. Jednak trzeba sobie zdawać sprawę, że obiekty mają toźsamość, a knotki nie. Oznacza to, że w reprezentacji obiektowej filmów mogą wystąpić dwa obiekty o takich samych wartościach wszystkich atrybutów, aczkolwiek, jak już wspomnieliśmy w przykładzie 2.23, taki przypadek wśród filmów nie powinien się zdarzyć.

Relacje natomiast są zbiorami knotek, a zatem jedna knotka nie może wy­stąpić w danej relacji więcej niż jeden raz. Jeśli więc relacja służy do przed­stawienia obiektów pewnej klasy, to trzeba się upewnić, że ma dostatecznie szeroko określony zbiór atrybutów, po to by żadne dwa obiekty nie miały tych samych wartości atrybutów relacji. W przykkadzie 2.23 stwierdziliśmy, że nie może się zdarzyć, aby dwa różne filmy miały identyczny tytuł i rok produkcj i. Jednak w najgorszym przypadku może okazać się potrzebne utworzenie

3.1. PODSTAWY MODELI RELACYJNYCFf I I 3

sztucznego atrybutu, który stanowiłby o identyfikacji obiektu. Na przykład każdemu filmowi można by nadawać jednoznaczny numer „IdFilmu" oraz dodać zdFilmu do zbioru atrybutów naszej przykładowej relacji.

3.1.4. Dziedziny

W modelu relacyjnym każda składowa każdej relacji musi mieć określony typ atomowy, tzn. jej typ musi należeć do typów elementarnych, np. musi być to typ całkowity lub znakowy. Wartość atrybutu nie może być ani rekordem, ani listą, ani tablicą, ani zbiorem, ani żadną inną strukturą, którą można podzie­lić na niniejsze części. Właśnie to wymaganie sprawia, że atrybuty z notacji ODL nie mogą być automatycznie przekładane na pojedyncze atrybuty relacji. Jeśli na przykład atrybut nazwisko w ODL zapisuje się jako strukturę:

Struct nazwisko {string pierwsze, string drugie}

to w odpowiadającej relacji muszą zostać uwzględnione osobno dwa atrybuty: pierwsze i drugie. Obszerniejsze omówienie tego zagadnienia znajduje się w p. 3.2.2.

Zakłada się, że z każdym atrybutem relacji jest powiązana dziedzina, czyli pewien określony typ elementarny. Każda składowa każdej krotki w relacji ma wartość, która należy do dziedziny odpowiedniej kolumny. Na przykład w krotkach relacji Film z rys. 3.1 pierwsza składowa musi mieć wartość typu string, druga i trzecia - typu integer, a czwarta musi mieć okre­ślonąjednązdwóch wartości: Kolor lub czarno-biały.

3.1.5. Równoważne sposoby reprezentowania relacji

Jak już wiemy zarówno schematy, jak i krotki relacji są zbiorami, a nie listami. A zatem porządek, w jakim je przedstawimy, nie ma znaczenia. Na przykład trzy krotki z rys. 3.1 możemy przedstawić w dowolnym z sześciu możliwych porządków. Jednak'ze będzie to ciągle ta sama relacja przedsta­wiona na rys. 3.1.

Ponadto możemy zmieniać kolejność atrybutów relacji w dowolny spo­sób, a sama relacja nie ulegnie przez to zmianie. Jednak, jeśli zmienimy ko­lejność atrybutów w schemacie relacji, to trzeba zawsze brać pod uwagę, że są one także nagłówkami kolumn. A więc, jeśli zmieniamy kolejność atrybutów, to musimy także zmienić odpowiednio kolejność kolumn. Jeśli zmienia się położenie kolumny w tabeli, to zarazem zmienia się kolejność skladowych w krotkach relacji. W wyniku zmiany kolejności atrybutów musi zatem rów­nież zajść właściwa permutacja składowych krotek.

114

rok tytul typFilmu

1991 Pot~żne Kaczory kolor

1992 Świat Wayne'a kolor

1997 Gwiezdne Wojny kolor

RYSUNEK 3,3

Inny układ relacji Film

3. RELACYJNY MODEL DANYCH

dlugość 104

94 124

Jako przykkad na rys. 3.3 została przedstawiona jedna z wielu relacji, któ­re można otrzymać w wyniku permutacji wierszy i kolumn na rys. 3.1. Obie relacje można traktować jako „tę samą". A mówiąc ściślej, te dwie tabele są różnymi obrazami tej samej relacji.

Wynik permutowania atrybutów i kolumn musi być widoczny również w krotkach przedstawianych osobno, poza tabelą.

PRZYKŁAD 3.1 Krotka

(Gwiezdne Wojny, 1977, 124, kolor)

z rys. 3. I oraz krotka

(1977, Gwiezdne wojny, kolor, 124)

z rys, 3.3 prezentują ten sam obiekt. Ale tej równoważności jesteśmy świa­domi wyłącznie wtedy, kiedy znamy kolejność atrybutów w odpowiadającym knotkom relacjach. Zatem zalecamy generalnie, aby ustalić kolejność atrybu­tów relacji i przestrzegać jej tak długo, jak korzysta się z tej relacji.

0

Formalny zapis knotki

W naszej książce postanowiliśmy przedstawiać knotki w postaci list, z ustalonym porządkiem atrybutów w relacji, jednak istnieje sposób zapisu knotek, który pozwala unikać takiego ustalonego porządku atrybutów. O krotce możemy bowiem myśleć jako o funkcji przeprowadzającej atry­buty ze schematu relacji do ich zbiorów wartości - do składowych tych knotek. Na przykład reprezentowana już dwojako knotka w przykładzie 3.1 może być przedstawiona jako następująca funkcja:

tytuł --> Gwiezdne Wojny rok --> 1977

długość --~ 124 typFilmu --~ kolor

3.1. PODSTAWY MODELI RELACYJNYCH

3.1.6. Instancje relacji

115

Relacja dotycząca filmów nie jest statyczna, zmienia się bowiem w cza­sie. Zmiany, których należy oczekiwać, dotyczą krotek relacji , na przykład wstawiania nowych krotek w przypadku zapisywania w bazie danych nowych filmów, zmiany istniejących krotek w przypadku uzyskania danych korygują­cycki istniejące w bazie wartości i być może usuwania krotek opisujących filmy, które z jakichś powodów mają zniknąć z bazy danych.

Rzadziej natomiast ulega zmianie schemat relacji. Jednak mogą wystąpić takie sytuacje, w których okazuje się pożądane dodanie lub usunięcie atrybu­tów. Zmiany schematu w systemach komercyjnych są niezwykle kosztowne, jeśli w ogóle wykonalne, ponieważ wówczas każda, spośród nawet miliono­wej liczby krotek, musi być przepisana, żeby dołączyć lub usunąć skladowe. W przypadku dołączania atrybutu może się poza tym okazać niemożliwe określenie wartości nowych skladowych niektórych krotek.

Zbiór krotek danej relacji będziemy nazywać instancją relacji. Na przykład trzy krotki z rys. 3.1 stanowią pewną instancję relacji Film. Prawdopodobnie relacja Film zmieniała się już i będzie się zmieniać w dalszym ciągu. Na przyklad w 1980 roku z pewnością nie występowaly w niej krotki opisujące Świat Wayne'a czy Kipera. Jednak w konwencjo­nalnych systemach baz danych udostępnia się tylko jedną wersję każdej relacji: zbiór krotek, które są w relacji „teraz". Te instancje relacji nazy­wamy ihstarrcjami bieżc~cymi.

Schematy i instancje

Nie wolno zapomnieć o ważnej różnicy między schematem relacji a jej in­stancją. Schemat obejmuje nazwę relacji i jej atrybuty i w zasadzie jest niezmienny. Instancja stanowi zbiór krotek relacji i może często ulegać zmianom.

W modelowaniu danych powszechnie korzysta się z rozróżnienia schematu i instancji. W rozdziale 2 na przykład odróżnialiśmy definicję interfejsu w ODL, która służyła do zdefiniowania struktury klasy obiek­tów, od zbioru obiektów tej klasy. Definicja klasy stanowi odpowiednik schematu, a zbiór obiektów zdefiniowanej klasy jest instancją. Analogicz­nie, zbiór encji i opis związków stanowią sposób definiowania schematu w modelu związków encji, a zbiory encji i zbiory związków tworzą instan­cje schematu związków encji. Warto jednak pamiętać o tym, że w fazie projektowania bazy danych jej instancja nie wchodzi do projektu. Staramy się tylko wyobrazić sobie, jak będą wyglądać typowe instancje po zakoń­czeniu projektu.

I I C) 3. RELACY.TNY MODEL DANYCH

3.1.7. Ćwiczenia do podrozdzia~u 3.1

Ćwiczenie 3.1.1. Na rysunku 3.4 są przedstawione instancje dwóch relacji, które mogą stanowić część bazy danych banku. Należy określić:

a) Atrybuty poszczególnych relacji. b) Krotki każdej relacji.

c) Składowe jednej krotki w każdej relacji. d) Schemat każdej relacji.

e) Schemat bazy danych.

Właściwą dziedzinę dla każdego atrybutu.

g) Inny, równoważny sposób przedstawienia każdej z relacji.

nrKonta typ saldo

12345 oszczędnościowy 12000

23456 rozliczeniowy 1000

34567 oszcz~dnościowy 25

Relacja Konta

Imię Nazwisko NrID konto

Robbie Banks 901-222 12345

Lena Hand 805-333 12345

Lena Hand 805-333 23456

Relacja Klienci

RYSUNEK 3.4

Dwie relacje w bazie danych banku

!! Ćwiczenie 3.1.2. Ile istnieje różnych sposobów (biorąc pod uwagę różną kolejność atrybutów i krotek) reprezentowania instancji relacji, jeśli składa się ona z:

*a) Trzech atrybutów i trzech krotek, podobnie jak relacja Konta z rys. 3.4? b) Czterech atrybutów i pięciu krotek?

c) n atrybutów i m knotek?

3 .2. Od projektów ODL do projektów relacyjnych

Rozważmy proces tworzenia nowej bazy danych, podobnej do naszej ba­zy danych filmów. Zaczyna się on od fazy projektowania, kiedy to trzeba określić zakres i rodzaj przechowywanych danych, powiązania między róż­nymi rodzajami danych, założenia dotyczące więzów zarówno klucza, jak

3.2. OD PROJEKTÓW ODL DO PROJEKTÓW RELACYJNYCH I I %

i integralności referencyjnej. Ta faza może rozciągnąć się w czasie, ponieważ ocenia się rozmaite warianty oraz podsumowuje różne opinie.

Po fazie projektowania następuje faza implementacji w rzeczywistym systemie baz danych. Ponieważ znakomita większość komercyjnych syste­mów baz danych stosuje model relacyjny, więc preferuje się tworzenie pro­jektu również w modelu relacyjnym, a nie w modelu obiektowym, jak ODL czy związków encji, które były omówione w rozdziale 2.

Mimo to w praktyce dość często jest łatwiej rozpocząć od postaci opisa­uych w rozdziale 2, utworzyć projekt w tym modelu, a potem przekształcić go do postaci relacyjnej. Jedna z przyczyn takiego postępowania leży w braku elastyczności modelu relacyjnego, który zawiera tylko jeden rodzaj elemen­tów - relacje i nie operuje innymi wygodnymi pojęciami (np. zbiorami encji i związków z modelu związków encji), a jest to znacznie łatwiej obsługiwać już po określeniu struktury projektu.

W bieżącym rozdziale zastanowimy się, w jaki sposób przekształcać mo­dele zapisane w języku ODL do postaci projektów relacyjnych. Z kolei kon­wersje między modelem związków encji a modelem relacyjnym omówimy w podrozdziale 3.3. Następnie poświęcimy trochę uwagi podklasom w pod­rozdziale 3.4. Ponieważ ujęcie podklas (związków isa) jest różne w języku ODL i w związkach encji, to również ich przekształcanie do modelu relacyj­nego będzie się różniło.

Często do schematu bazy danych dołącza się więzy. Więzy z modelu ODL i modelu związków encji, takie jak klucze i więzy integralności, można także wyrazić w modelu relacyjnym. Ważna kategoria więzów, nazywana zależnościami funkcyjnymi, w modelu relacyjnym będzie przedstawiona w podrozdziale 3.5. Omówienie innych rodzajów więzów modelu relacyjnego rozpocznie się od podrozdziału 4.5.

3.2.1. Od atrybutów w języku ODL do atrybutów relacji

Na początek załóżmy, że każda klasa będzie miała swój odpowiednik w postaci jednej relacji, a w tej relacji dla każdej właściwości będzie określony jeden atrybut. Zobaczymy później wiele sposobów modyfikacji tych założeń, lecz na chwilę przyjmijmy najprostszy przypadek, kiedy możemy bezpośrednio przekształcić klasy na relacje, a właściwości na atrybuty. A oto nasze założenia:

1. Wszystkie właściwości klas zapisuje się jako atrybuty (nie ma ani związków, ani metod).

2. Typy atrybutów sątylko atomowe (nie ma ani struktur, ani zbiorów). n

PKZYKŁAD'. 3.2

Na rysunku 3.2 został pokazany przykład klasy, odpowiadający przyjętym założeniom. Występują tam cztery atrybuty i nie określono żadnych innych

I I S 3. RELACYJNY MODEL DANYCH

właściwości. Każdy atrybut ma określony typ atomowy: tytuł jest napisem, rok i długość są typu całkowitego, a typFilmu może przyjmować jedną z dwóch wartości.

Tworzymy relację o takiej samej nazwie jak nazwa klasy, w tym przy­padku Film. Relacja ma cztery atrybuty, po jednym odpowiedniku dla każde­go atrybutu klasy. Nazwy atrybutów relacji mogą być takie same jak nazwy odpowiednich atrybutów klasy. Zatem otrzymujemy następujący schemat dla tej relacji:

Film (tytuł, rok, długość, typFilmu)

taki sam jak w p. 3.1.1.

W obiektach klasy są określone wartości dla każdego atrybutu klasy. Każdemu obiektowi może odpowiadać krotka, której składowe są równe wartościom poszczególnych atrybutów obiektu. Wynik takiego przekształce­nia już widzieliśmy. Na rysunku 3.1 przedstawiono bowiem przykład prze­kształcenia obiektów klasy Film do postaci krotek.

0

3.2.2. Atrybuty nieatomowe w klasach

Niestety, nawet jeśli wszystkie właściwości klasy są atrybutami, to przy przekształcaniu klasy do postaci relacji mogą pojawić się problemy. Ich powo­dem może być złożony typ atrybutów w języku ODL, które bywają opisywane strukturami, zbiorami, wielozbiorami lub listami. Natomiast podstawowe zało­żenie modelu relacyjnego stanowi o tym, że typy atrybutów mogą być wyłącz­nie atomowe, takie jak liczby lub napisy. Stąd też istnieje potrzeba określenia sposobu przedstawiania nieatomowych typów atrybutów w postaci relacji.

Reprezentowanie typów wyliczeniowych i dat

W modelu ODL istnieją pewne typy atomowe, w praktyce daty i typy wy­liczeniowe, które nie mają odpowiedników w typach atomowych standar­dowego modelu relacyjnego. Na przykład typ wyliczeniowy, to jest to tak naprawdę zbiór odpowiedników dla pierwszych kilku liczb całkowitych. Zatem na przykład pole typu wyliczeniowego dla dni tygodnia można za­stąpić atrybutem typu integer, a korzystać w krotkach tylko z wartości cał­kowitych od 1 do 6. W alternatywny sposób można korzystać z atrybutu typu string, a dni tygodnia przedstawiać wartościami „Pon", „wt" itd. W podobny sposób można w modelu relacyjnym stosować typ string do reprezentowania atrybutów, które w modelu ODL mają określony typ jako data. W rozdziale S przy omawianiu relacyjnego języka zapytań SQL oka­że się, że tak samo jak w języku ODL można tam używać atrybutów, które sątypu wyliczeniowego i typu daty.

3.2. OD PROJEKTÓW ODI, DO PROJEKTÓW RELACYJNYCFI ł I g

Struktury takie jak rekordy, których pola są z założenia typu atomowe­go, obsługuje się najłatwiej. Po prostu rozszerza się wówczas definicję struktury, dodając do relacji po jednym atrybucie dla każdego pola struktu­ry. Jedyny kłopot może wynikać wówczas, gdy dwie struktury w klasie mają jednakowe nazwy pól, i w takim przypadku trzeba wymyślić dla jednego z powstających w tej parze atrybutów nową nazwę po to, by w relacji można je było odróźnić.

interface Gwiazda { attribute string nazwisko; attribute Struct Adr

{string ulica, string miasto} adres; };

RYSUNEK 3.5

Klasa z atrybutem strukturalnym

PRZYKŁAD 3,3

Rozważmy wstępną definicję klasy gwiazda z przykładu 2.3, podajemy ją ponownie na rys. 3.5. Atrybut nazwisko jest typu atomowego, ale już atrybut adres jest strukturą o dwóch polach: ulica oraz miasto. A więc w relacji odpowiadającej tej klasie trzeba utworzyć 3 atrybuty. Pierwszy z nich to bę­dzie nazwisko i odpowiada on atrybutowi o tej samej nazwie z języku ODL. Drugi i trzeci atrybut nazwiemy odpowiednio ulica oraz miasto, będą one stanowić odpowiedniki dwóch pól struktury adres i łącznie stanowić opis adresu. Schemat relacji przedstawia się zatem następująco:

Gwiazda (nazwisko, ulica, miasto)

PI-zykład instancji tej relacji z arbitralnie dobranymi krotkami zostal przed­stawiony na rys. 3.6.

nazwisko

Carrie Fischer Marle Hamill Harrison Ford

ulica 123 Maple St 456 Oak Rd. 789 Palm Dr.

miasto Hollywood Brentwood Beverly Hills

RYSUNEK 3.6

Relacja reprezentująca gwiazdy

0

Ale to nie struktura typu rekord jest najbardziej skomplikowana wśród typów atrybutów, którymi można określać atrybuty w definicjach klas w mo­delu ODL. Można budować wartości, korzystając z konstruktorów typów takich jak: set, bag, array i list. Każdy z nich stanowi osobny problem

IZO 3. RELACY.INY MODEL DANYCH

przy migracji do modelu relacyjnego. Szczegółowo omówimy tylko kon­struktor set, który rozpowszechnil się najbardziej.

Uwagi na temat jakości danych :-)

Podczas obmyślania stosownych przykładów danych osobowych, zdecy­dowaliśmy się używać wymyślonych wartości adresów i innych atrybutów określających prywatną sferę życia gwiazd filmowych, po to by chronić prywatność ludzi sceny, bowiem bywają oni nadwrażliwi i często unikają publiczności.

Jedna z metod reprezentowania zbioru wartości atrybutu A polega na utworzeniu dla każdej wartości odpowiadającej jej krotki. Taka krotka zawie­ra wówczas stosowne wartości wszystkich pozostałych atrybutów klasy. Na początku prześledzimy przykład, w którym ta metoda działa poprawnie, do­piero potem opiszemy kryjące się w niej pułapki.

PRZYKŁAD 3.4

Przypuśćmy, że klasę Gwiazda zdefiniowano w ten sposób, że każdej gwieź­dzie jest przypisany zbiór adresów. Definicję klasy można wówczas zapisać w języku ODL, tak jak zrobiono to na rys. 3.7. Załóżmy ponadto, że Carrie Fischer posiada również domek na plaży, a pozostałe dwie gwiazdy filmowe, wymienione na rys. 3.6 mają tylko jeden dom. Wówczas zapisujemy dwie krotki, w których atrybut nazwisko ma wartość Carrie Fischer, co jest przedstawione na rys. 3.8. Inne krotki pozostajątakie same jak na rys. 3.6.

interface Gwiazda { attribute string nazwisko; attribute Set<

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

);

RYSUNEK 3.7

Gwiazdy ze zbiorami adresów

nazwisko

Carrie Fischer Carrie Fischer Mark Hamill Harrison Ford

RYSUNEK 3.8 Dopuszczenie zbioru adresów

ul ica miasto

123 Maple St. Hollywood 5 Locus Ln. Malibu 456 Oak Rd. Brentwood 789 Palm Dr. Beverly Hills

D

3.2. OD PRO.IEKTÓW ODL DO PRO.IEKTÓW RELACYJNYCH I2I

Trzeba jednak przestrzec przed sytuacjami, gdy taka technika rozszerzenia zbioru na kilka krotek doprowadza do utworzenia źle zaprojektowanych relacji. W podrozdziale 3.7 rozważymy problemy, które mogą wówczas się pojawić, oraz dowiemy się, w jaki sposób przekształcić schemat bazy danych. Tutaj zastanówmy się po prostu przez chwilę nad mogącymi się pojawić problemami.

Wartości atomowe: błędy czy właściwości?

Wydaje się, że model relacyjny rzuca nam kłody pod nogi w tych miej­scach, gdzie model ODL jest bardziej elastyczny i dopuszcza opisywanie właściwości w postaci struktur złożonych. Można nawet poczuć chęć to­talnego odrzucenia modelu relacyjnego lub potraktowania go jako prymi­tywnej koncepcji wypartej przez elegantsze techniki obiektowe, takie jak ODL. Jednak w rzeczywistości na rynku dominują systemy baz danych re­alizowane w modelu relacyjnym. Jednym z powodów takiego stanu rzeczy jest to, że prostota modelu relacyjnego umożliwia tworzenie zapytań do baz danych poprzez silne narzędzia języków zapytań. W podrozdziałach 4.1 i 4.2 wprowadzimy abstrakcyjne języki programowania, algebrę relacji i Datalog. Ważniejsze jest pewnie jednak ich wcielenie w SQL, języko­wym standardzie dostarczanym obecnie w prawie wszystkich systemach baz danych.

PRZYKŁAD 3.5

Załóżmy, że w definicji klasy Gwiazda wystąpi dodatkowo atrybut dataU­rodzenia, skorzystamy więc z definicji zapisanej na rys. 3.9. Do rysunku 3.7 dołączyliśmy atrybut dataUrodzenia typu Data, który w modelu ODL jest typem atomowym. A zatem schemat relacji Gwiazda z nowym atrybutem dataUrodzenia wygląda następująco:

Gwiazda (nazwisko, ulica, miasto, dataUrodzenia)

Wprowadźmy jeszcze jednązmianę do danych z rys. 3.8. Ponieważ zbiór adresów może być pusty, więc załóżmy, że w bazie nie figuruje adres Harri­sona Forda. Tak zmodyfikowana relacja została przedstawiona na rys. 3.10.

interface Gwiazda {

attribute string nazwisko; attribute Set<

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

attribute Date dataDrodzenia;

RYSUNEK 3.9.

Zbiór adresów i dat urodzenia gwiazd

122 nazwisko Carri.e Fischer Carrie Fischer Marle Hamill

RYSUNEK 3.10 Dołączenie dat urodzenia

3. RELACYJNY MODEL DANYCH

ulica miasto dataUYOdzenia 123 Maple St. Hollywood 9/9/99

5 Locus Ln. Malibu 9/9/99 456 Oak Rd. Brentwood 8/8/88

Na rysunku 3.10 znajdują się dwa niekorzystne elementy. Po pierwsze data urodzenia Carrie Fischer powtarza się w każdej krotce. A zatem relacja zawiera redundancję. Jej nazwisko jest co prawda również powtórzone, ale nie wytwarza to redundancji, ponieważ bez tego nazwiska nie wiedzieliby­śmy, że oba adresy należy wiązać z Carrie Fischer. Różnica polega tu na tym, że nazwisko, powtarzające się w każdej krotce, jest kluczem obiektu repre­zentowanego w relacji i dlatego musi wystąpić we wszystkich krotkach doty­czących tej gwiazdy. W przeciwieństwie do tego data urodzenia jest daną o gwieździe i nie stanowi części klucza reprezentowanego obiektu, a zatem powtórzenie tej daty jest redundancją.

Drugi problem polega na tym, że ponieważ stowarzyszony z Harrisonem Fordem zbiór adresów jest pusty, więc utraciliśmy o nim wszelkie dane. W szczególności jego data urodzenia nie pojawi się w relacji, nawet jeśli ist­nieje obiekt Ford w klasie Gwiazda. Trzeba pamiętać, że żaden z tych dwóch problemów nie dyskwalifikuje naszej metodologii przeksztalcania schematów ODL do postaci relacyjnej. Jednak trzeba dostrzegać zagrażające niebezpie­czeństwa i poprawiać schematy relacyjne za pomocą technik normalizacji, opisanych w podrozdziale 3.7.

0

Jeśli w definicji klasy kilka atrybutów zdefiniowano jako kolekcje (bę­dziemy je nazywać atrybutami wielowartościowymi), to liczba krotek repre­zentujących jeden obiekt będzie się mnożyć. Trzeba bowiem tworzyć osobne krotki dla każdej kombinacji wartości ahybutów wielowartościowych, Powró­cimy do tego zagadnienia w p. 3.2.5 w kontekście związków między zbiorami.

3.2.3. Reprezentowanie konstruktorów innych typów

Poza strukturami rekordów oraz zbiorami w definicji klasy w języku ODL można stosować konstruktory Bag, Array oraz List. Przy reprezento­waniu wielozbioru (bag), w którym dana wartość może występować rz razy, nie możemy po prostu wprowadzić do relacji n identycznych krotek~. Zamiast

" Sciślej, w abstrakcyjnym modelu relacyjnym. który opisujemy w bieżącym rozdziale, nie jest dopuszczalne, aby w relacji występowały identyczne krotki. .łednak w relacyjnych

3.2. OD PROJEKTÓW ODL DO PROJEKTÓW RELACYJNYCH 123

tego proponujemy dołączyć do schematu relacji nowy atrybut licznik, okre­ślający, ile razy dany element występuje w wielozbiorze. Przyjmijmy na przykład, że adres z rys. 3.7 jest wielozbiorem, a nie zbiorem. Wówczas można by określić, że 123 Maple St., Hollywood jest adresem Carrie Fischer dwukrotnie, a z kolei 5 Locust Ln., Malibu jest jej adresem trzykrotnie, sto­sując następujący zapis:

nazwisko I ulica

Carrie Fischer 123 Maple St Carrie Fischer 5 Locus Ln.

miasto licznik Hollywood 2 Malibu 3

Lista adresów może być reprezentowana przez nowy atrybut pozycj a, wskazujący pozycję w obrębie listy. Na przykład możemy przedstawić listę adresów Carrie Fischer, z adresem w Hollywood na pierwszym miejscu, w postaci następującej relacji:

nazwisko Carrie Carrie

ulica

Fischer1123 Maple St Fischer 5 Locus Ln.

miasto Hollywood 1 Malibu 2

W końcu macierz adresów, która ma ustaloną długość, może być repre­zentowana przez atrybuty utworzone dla każdej pozycji w macierzy. Jeśli zatem adres miałby być tablicą zawierającą dwie struktury miasto-ulica, to jeden obiekt typu Gwiazda byłby przedstawiony jako:

nazwisko I ulical

Carrie Fischer 1123 Maple St

rniastol ulica2 miasto2 Hollywood 5 Locus Ln. Malibu

3.2.4. Reprezentowanie relacji jednowartościowych

Zdarza się często, że definicja pewnej klasy w ODL zawiera związki z innymi klasami w tym modelu. Jako przykład rozważmy pełną definicję klasy Film z rys. 2.6, którą powtarzamy na rys. 3.l 1.

Najpierw skoncentrujmy uwagę na związku należyDo, wiążącym każdy film ze studiem, które go wyprodukowało. Pierwsza myśl, jaka się nasuwa, to potraktowanie związku tak samo jak atrybutu. Moglibyśmy w relacji określić atrybut lub zbiór atrybutów, aby reprezentować atrybuty obiektów powiązanej klasy, podobnie jak to czyniliśmy w przypadku, gdy atrybuty w modelu ODL

systemach wyposażonych w SQI_ dopuszcza się powtarzanie się krotek, tzn. w języku SQL relacje są wielozbiorami, a nie zbiorami (patrz podrozdz. 4.6 i ~.4). Jeśli liczba krotek zaczyna być znacząca, to jednak doradzamy korzystanie ze scheanatów opisywanych w bieżącym roz­dziale, nawetjeśli rzeczyvisty DBMS dopuszcza powtarzanie się krotek.

I 24 3. RELACYJNY MODEL DANYCH

miały strukturę złożoną zbioru lub zbioru struktur. W przypadku związku należyDo, do schematu relacji Film dołączylibyśmy po jednym atrybucie dla każdej właściwości klasy studio.

interface Film{

attribute string tytuł; attribute integer rok; attribute integer dlugość;

attribute enumeration(kolor, czarno-biały) typFilmu;

relationship Set<Gwiazda> gwiazdy

inverse Gwiazda:: występujeW; relationship Studio należyDo;

inverse Studio:: posiada;

RYSUNL;K 3.1 1

Pełna definicja klasy Film

Przy takim podejściu pojawia się jednak kłopot polegający na tym, że obiekty studio pozostają również we własnym związku posiada, który definiuje z powrotem zależność do obiektów klasy Film. Do reprezentowania tego związku w każdej krotce relacji film trzeba by zawrzeć dane o wszyst­kich innych filmach wyprodukowanych przez jego studio. Z kolei dane o każ­dym z tych filmów obejmują również dane ich studia, co skłania nas do po­nownego włączenia danych o filmach powiązanych ze studiem. A zatem taka technika może doprowadzić do istotnych komplikacji, jeśli uda się ją stoso­wać w praktyce.

Lepszą metodę uzyskamy, gdy zastanowimy się, w jaki sposób naprawdę obiekty są rozmieszczone w pamięci komputera. Jeśli obiekt O~ zawiera do­wiązanie do innego obiektu O2, to wcale nie tworzymy nowej kopii obiektu OZ w O~. Na ogół po prostu określa się wewnątrz Ol wartość wskaźnika poka­zującego na obiekt O2.

Ale model relacyjny nie zawiera pojęcia wskaźnika ani żadnego innego podobnego elementu. Zamiast tego musimy symulować efekt, uzyskiwany poprzez wskaźniki, zbiorem wartości definiującyclo powiązany obiekt. Trzeba nam po prostu zbioru atrybutów powiązanej klasy, które tworzą w niej klucz. Jeśli to określimy, to możemy potraktować związek tak, jakby był atrybutem lub atrybutami kluczowymi wskazywanej klasy. Tę technikę ilustruje następ­ny przykład.

` O ile łańcuch filmów i studia nie wychodzi nigdy poza jedno studio, to już analogiczne postępowanie w przypadku związku gwiazdy i odwrotnego doń związku występujew pro­wadziłoby od filmu do jego gwiazd, do wszystkich filmów powiązanych z gwiazdami, do wszystkich gwiazd, które tam występowały, i tak dalej, bardzo szybko doprowadzając do konieczności uwzględnienia w jednej krotce prawie wszystkich filmów i gwiazd umieszczo­nych w bazie danych.

32. OD PROJEKTÓW ODL DO PROJEKTÓW RELACYJNYCH I2S

PRZYKŁAD 3.6

Załóżmy, że atrybut nazwa stanowi klucz dla klasy studio. Definicję tej klasy przepisujemy zgodnie z rys. 2.6

interface Studio { attribute string nazwa; attribute string adres;

relationship Set<Film> posiada inverse Film::należyDo; );

Możemy zmodyfikować schemat relacji Film z rys. 3.1 tak, aby zostały do niego dołączone atrybuty określające studio właściciela. Arbitralnie nazwie­my ten atrybut nazwastudia. Na rysunku 3.12 zostało przedstawione takie rozszerzenie o atrybut nazwastudia oraz pewne przykładowe krotki.

tytu~ rok długość typFilmu nazwaStudia

Gwiezdne Wojny 1977 124 kolor Fox

Potężne Kaczory 1991 104 kolor Disney

Swiat Wayne'a 1992 95 kolor Paramount

RYSUNEK 3.12

Relacja Film z nowym atrybutem określąjącym studio właściciela

O

3.2.5. Reprezentowanie związków wielowartościowych

Związek gwiazdy z rys. 3.11 przedstawia problem, który nie występuje w przypadku związku należyDo. Jeśli typem związku jest klasa, to mówimy, że związek jest jednowartościowy. Związek należyDo, którego typem jest klasa studio, jest związkiem jednowartościowym. Jednak jeśli typem związ­ku jest pewna struktura, np. kolekcja, zastosowana do klasy, to wówczas mó­wimy, że związek jest wielowartościowy. Związek gwiazdy jest wielowarto­ściowy, ponieważ jego typ określono jako set<Gwiazda>. Mówiąc inaczej, każdy związek typu jeden do wiele lub wiele do wiele z klasy A do klasy B jest związkiem wielowartościowym od A do B.

W celu reprezentowania związków wielowartościowych musimy zasto­sować kombinację dwóch technik:

1. Tak jak w przypadku związku jednowartościowego, trzeba znaleźć klucz reprezentujący powiązane obiekty.

2. Tak jak w przypadku atrybutów ze zbiorem wartości, do reprezento­wania obiektów powiązanych trzeba tworzyć osobne krotki dla po­

I ZG 3. RELACYJNY MODEL DANYCH

szczególnych wartości. I tak jak w przypadku atrybutów o typie zbio­ru, przy tej technice zagadnienie redundancji pozostaje otwarte, po­nieważ wartości innych atrybutów relacji muszą się powtarzać dla każdego elementu ze zbioru. Ten problem zostanie rozwiązany w pod­rozdziale 3.7, więc na razie pogodzimy się z takim stanem rzeczy.

PRZYKŁAD 3.7

Załóżmy, że nazwisko jest kluczem w klasie Gwiazda. Wówczas relację, zaprojektowaną dla klasy Film, możemy rozszerzyć, dołączając do niej atry­but o przykładowej nazwie nazwiskoGwiazdy, którego wartości będą od­powiadać nazwiskom poszczególnych gwiazd. Wówczas jeden film będzie opisany przez tyle krotek, ile gwiazd występujących w danym filmie umiesz­czono w bazie danych. Pewne przykłady danych zamieszczono na rys. 3.13. Wyraźnie widać już redundancję, wszystkie pozostałe dane o filmie są powta­rzane dla każdej gwiazdy występującej w tym fiknie.

tytuł rok dlugość typFilmu nazwaStudia nazwisko-

Gwiazdy

Gwiezdne 1977 124 kolor Fox Carie

Wojny Fischer

Gwiezdne 1977 124 kolor Fox Mark

Wojny Hamill

Gwiezdne 1977 124 kolor Fox Harrison

Wojny Ford

Potężne 1991 104 kolor Disney Emilio

Kaczory Estevez

Świat 1992 95 kolor Paramount Dana

Wayne'a Carvey

Świat 1992 95 kolor Paramount Mike

Wayne'a Meyers

RYSUNEK 3.13

Relacja Fi lm z danymi gwiazd

O

Może się również zdarzyć, że w klasie wystąpi więcej niż jeden związek wielowartościowy. Wówczas liczba powstałych krotek w relacji gwałtownie się zwiększa. Załóżmy, że w klasie C określono związki wielowartościowe R,, R2, ..., Rk. Wówczas relacja zaprojektowana dla klasy C ma atrybuty od­powiadające wszystkim atrybutom C oraz atrybuty odpowiadające atrybutom klucza wszystkich związków jednowartościowych z C. Poza tym muszą wy­stąpić atrybuty reprezentujące klucze klas powiązanych związkami R,, RZ, ..., Rk.

Załóżmy, że pewien obiekt o z klasy C jest powiązany poprzez związek R, z n, obiektami, poprzez związek RZ z n, obiektami i tak dalej. Wówczas dla

3.2. OD PROJEKTÓW ODL DO PROJEKTÓW RELACYJNYCH 12%

wszystkich możliwych kombinacji tych obiektów tworzymy po jednej krotce, która odpowiada obiektowi o. A zatem, w wyniku otrzymamy n~ x n2 x ... x nk krotek, które trzeba umieścić w relacji, jeśli chcemy reprezentować obiekt o w tym modelu.

PRZYKŁAD 3.8

Załóżmy, że w klasie C zdefiniowano zbiór jednowartościowych atrybutów X oraz dwa wielowartościowe związki R, i R2. Niechaj te związki łączą klasę C z klasami, których kluczowe atrybuty tworzą odpowiednio zbiory Y i Z. A teraz rozważmy obiekt c klasy C, który poprzez związek R~ jest powiązany z obiektami o kluczach yJ i y2, a poprzez związek Rz z obiektami o kluczach z,, zz oraz z3. Niech x reprezentuje wartości obiektu c w zbiorze atrybutów X.

Wówczas obiekt c w relacji utworzonej do reprezentowania klasy C sam jest reprezentowany przez sześć krotek. Możemy je oznaczyć symbolicznie w następujący sposób:

(x~ Ya zO (x~ Yo zz) (x~ Yn z3) (x~ Y2~ ~t) (x~ Yz~ z2) (x~Yz~ z3)

Klucze z Y zostały tu połączone w pary z kluczami z Z na wszystkie możliwe sposoby.

0

3.2.6. A gdy nie ma klucza...

W modelu obiektowym, takim jak ODL, dopuszcza się występowanie dwóch obiektów tej samej klasy z identycznymi wartościami wszystkich wła­ściwości. Musimy zatem przygotować się do rozwiązania problemów takich, jak na przyklad istnienie dwóch gwiazd o dokładnie takich samych nazwi­skach. Jeśli tak się zdarzy, to oznacza, że sam atrybut nazwisko nie wystar­cza jako klucz klasy gwiazda, zatem nie możemy go w tym charakterze sto­sować w krotkach relacji Film. Przypuszczalnie, aby otrzymać klucz, mogli­byśmy dolączyć inne atrybuty gwiazd, ale nigdy nie będziemy mieć gwaran­cji, że dwie różne gwiazdy filmowe nie majątakich samych nazwisk i imion, takich samych adresów, nie są urodzone tego samego dnia i tak dalej, bez względu na rodzaj właściwości gwiazdy, dołączonych do bazy danych.

Jedyne gwarantowane rozwiązanie polega na utworzeniu nowego atry­butu, który reprezentowałby „identyfikator obiektu" klasy odpowiadającej relacji. Na przykład, jeśli nie bylibyśmy pewni, że atrybut nazwisko może być kluczem gwiazd, to możemy utworzyć dla każdej gwiazdy jej „numer certyfikatu", który może stanowić numer czlonkowski w Związku Aktorów. Numery certyfikatów są jednoznaczne, ponieważ istnieje centrala, która jest odpowiedzialna za ich obsługę oraz kontroluje, które numery sąw użyciu.

I 2ó 3. RELACYJNY MODEL DANYCH

PRZYKł.AD 3.9

Jeśli wprowadzimy jednoznaczne numery certyfikatów dla gwiazd i zdefiniu­jemy klucz gwiazdy w relacji poprzez ten numer, to relacja Film przyjmie następującą postać:

rok I dluQOŚĆ I tvpFilmu I nazwaStudio I cert#

Gwiezdne Wojny 11977 1124 (kolor IFox 112345 Podajemy tu tylko jedną krotkę i zakładamy, że 12 345 jest numerem cer­

tyfikatu Carrie Fisher. Do relacji Gwiazda trzeba również dołączyć atrybut określający numer certyfikatu, a także wszystkie inne dane o gwieździe, które wynikająz definicji klasy Gwiazda zapisanej w języku ODL. Na przykład: -cert# ~ nazwisko ~ ulica ~ miasto ~wyste~ujeW

12345 Carrie Fisher 123 Maple St. Hollywood Gwiezdne Wojny opisuje pewien schemat relacji oraz jedną z kilku krotek odpowiadających Carrie Fisher.

0

3.2.7. Reprezentowanie relacji oraz jej odwrotności

W zasadzie przy bezpośrednim tłumaczeniu opisu w modelu ODL na model relacyjny dwukrotnie reprezentujemy relację, jeden raz w każdym kie­runku. W przykładzie 3.7 przechowywaliśmy każdą gwiazdę filmu w krotce, która nosiła nazwę tego filmu. Gdy projektowaliśmy relacje dla klasy Gwiaz­da, to reprezentowaliśmy związek występujeW przez utworzenie tylu krotek dla każdej gwiazdy, w ilu filmach ona występowała, z podaniem tytulu i roku każdego z filmów w osobnych krotkach (pamiętamy przecież, że tytuł i rok razem stanowią klucz filmów).

Jednak zauważmy, że przechowywanie zarówno związku gwiazdy, jak i jego odwrotności, jest redundantne. Każdy z nich dostarcza bowiem tych samych danych co ten drugi. A zatem możemy w relacji Gwiazda całkiem pominąć związek wystepuj eW. Zamiast tego możemy utrzymać wszystkie dane w relacji Gwiazda, a usunąć atrybut nazwiskoGwiazdy z relacji Film. W punkcie 3.3.2 opiszemy trzecią metodę, polegającą na tym, że związek i jego odwrotność są oddzielane i razem tworzą nową relację. Czasami, acz­kolwiek nie zawsze, taka metoda jest najwłaściwsza. Jednak jeśli tak się zda­rzy, że oddzielna relacja dla związków jest najlepszym sposobem, to proces normalizacji, który omówimy w podrozdziale 3.7, zmusi nas do utworzenia jej, nawet jeśli sami we wstępnym projekcie relacyjnym tego nie zrobimy.

Zauważmy, że w modelach ODL zarówno związek, jak i jego odwrot­ność są niezbędne, ponieważ zawierają wskaźniki od gwiazd do ich filmów

3.2. OD PROJEKTÓW ODL DO PRO.tEKTÓW RELACYJNYCH 129

oraz od filmów do ich gwiazd. Nie można posługiwać się bowiem wskaźni­kami odwrotnie do ich kierunku, wiec w przeciwnym razie musiałyby po­wstać wskaźniki dwukierunkowe". Lecz zarówno w modelu relacyjnym, jak i w modelu związków encji, związki definiuje się przez powiązane wartości (kluczy). Krotki zawierające pary powiązanych kluczy, ua przykład tytuł i rok dla filmu oraz nazwisko gwiazdy, można stosować zarówno do analizowania związku, jak i jego odwrotności.

Reprezentowanie związków w jednym kierunku

Jeśli binarny związek zachodzi między dwoma zbiorami encji, to można wybrać jednąz relacji, w której zostanie zapisany związek: relację definiują­cą którykolwiek ze zbiorów encji. Czy ma znaczenie, którą z nich wybie­rzemy? Jeśli związek jest typu jeden do jeden lub wiele do wiele, to naj­prawdopodobniej nie ma to znaczenia. Ale jeśli związek jest typu wiele do jeden, to warto wprowadzić związek po stronie wiele, tzn. do tego zbioru encji, w którym wiele encji może być powiązanych z jedną encją drugiego zbioru encji. W ten sposób bowiem uda się nam uniknąć redundancji.

Na przykład związek Posiada między Filmami i Studiami jest lepiej umieścić w zbiorze Filmy. W ten sposób po prostu tylko rozszerza się zbiór atrybutów filmu o nazwę właściwego dla filmu studia i każda krotka rozszerza się o jedną wartość. Gdybyśmy natomiast dołączyli związek do relacji Studia, to musielibyśmy każdą krotkę w tej relacji rozszerzyć o wiele innych krotek, dodając dla każdego studia tyle krotek, ile filmów ono posiada. W wyniku takich działań powielilibyśmy wszystkie inne dane na temat studia tyle razy, ile ma ono filmów.

3.2.8. Ćwiczenia do podrozdzia~u 3.2

Ćwiczenie 3.2.1. Należy przeksztalcić projekty w języku ODL z wymienionych poniżej ćwiczeń do postaci relacyjnego schematu bazy danych.

*a) Ćwiczenie 2.1.1.

b) Ćwiczenie 2.1.2 (włączając wszystkie cztery modyfikacje wyspecyfikowane w tamtym ćwiczeniu).

c) Ćwiczenie 2.1.3. d) Ćwiczenie 2.1.4. *e) Cwiczenie 2.1.5.

Ćwiczenie 2.1.6.

" Oczywiście nie można zakładać, że dana impłementacja ODL będzie zawierała wskaź­niki o pożądanych właściwościach, ale może się zdarzyć, że istnieje taka implementac_ja, która dla pary związków odwrotnych ma pojedynczą reprezentację.

I 3 O 3. RELACYJNY MODEL DANYCH

Wskaźniki: właściwości czy błędy?

Związki w modelu ODL są z założenia albo wskaźnikami, albo referen­cjami od każdego obiektu do odpowiadających obiektów. Taki sposób im­plementacjijest bardzo wygodny, ponieważ szybko można uzyskać dostęp do obiektu powiązanego. W porównaniu z tym w modelu relacyjnym, gdzie obiekty reprezentuje się przez wartości ich kluczy, a nie przez wskaźniki, nawigacja od obiektu do powiązanych z nim wartości wydaje się wolniejsza.

Na przykład obiekt Film z przykładu 3.7 obejmował po jednej krotce dla każdej gwiazdy z tego filmu, w krotce było umieszczone wyłącznie nazwisko gwiazdy, bez żadnych innych jej danych. Gdybyśmy chcieli znaleźć na przykład adresy gwiazd występujących w „Świecie Wayne'a", to trzeba by na podstawie nazwisk gwiazd w relacji Gwiazda wyszukać wszystkie krotki danej gwiazdy. Dopiero w ten sposób uzyskalibyśmy ich adresy.

Można by zatem pomyśleć, że brak wskaźników w modelu relacyj­nym był czymś w rodzaju błędu w tym modelu. Jednakże w praktyce bu­duje się na relacjach indeksy, które umożliwiają bardzo efektywne poszu­kiwanie krotek, które mają określoną wartość w danej składowej (patrz: p. 1.2.1 oraz 5.7.7). A więc w praktyce niewiele się traci przez brak wskaźników. Ponadto, o ile wskaźniki są bardzo potrzebne w programach, które działają na danych w pamięci operacyjnej, a ich wykonanie trwa nie dłużej niż ułamek sekundy, o tyle w bazach danych stosuje się zupełnie in­ne metody. Implementacja wskaźników między obiektami, które istnieją latami w bazie, a mogą być przechowywane w sposób rozproszony na róż­nych urządzeniach pamięci zewnętrznych dołączonych do szeroko rozpro­szonych systemów komputerowych, jest znacznie trudniejsze. Tutaj dopie­ro widać, jak silne są argumenty przemawiające za rozwiązaniami stoso­wanymi w modelu relacyjnym, gdzie nie używa się wskaźników.

interface Klient{

attribute Struct nazwisko

{string imię, string nazwisko} nazwisko; attribute Set<

Struct Tel {string typ, int numer}

>telefony; relationship Klient określonyPrzez inverse

wprowadzenia; relationship Set<Klient> wprowadzenia; inverse Studio:: określonyPrzez;

KYSUNEK 3.14 Rekordy Klienta

3.3. OD DIAGRAMÓW ZWIĄZKÓW ENCJI DO PROJEKTÓW RELACYJNYCH 131

Ćwiczenie 3.2.2. Należy przekształcić opis w języku ODL z rys. 2.7 do relacyjnego schematu bazy danych. W jaki sposób trzy modyfikacje wyspecyfikowane w ćwicze­niu 2.1.8 wpływają na postać schematu relacyjnego?

!Ćwiczenie 3.2.3. Na rysunku 3.14 przedstawiono w języku ODL definicję klasy klienci. W obiektach tej klasy przechowuje się zbiór różnych rodzajów telefonów (np. domowy, biurowy, fax) oraz zbiór „dołączonych", w którym klient otrzymuje kredyt przy pozyskaniu dla firmy nowych klientów. Należy przekształcić tę specyfikację z języka ODL do schematu relacyjnego bazy danych.

3.3. Od diagramów związków encji do projektów relacyjnych

Przekształcanie diagramów związków encji na schemat bazy danych bar­dzo przypomina przekształcanie projektów w języku ODL do schematu bazy danych. Jednakże w pewnym sensie model związków encji stanowi postać pośrednią między projektami obiektowym a relacyjnym. Oznacza to, że gdy dysponujemy modelem związków encji, to unikamy części ciężkiego trudu. Dwie istotne różnice polegają na tym, że:

1. W modelu związków encji związki są wyodrębnione jako samoistne pojęcie, a nie są elementem składowym pojęcia klasy. Ta różnica po­zwala uniknąć redundancji pewnego rodzaju, które omawialiśmy w p. 3.2.2, kiedy zdecydowaliśmy, żeby włączyć związek wielowarto­ściowy, taki jak gwiazdy, do krotek reprezentujących obiekty klasy Film.

2. W modelu ODL dla atrybutów można określać złożony typ, np. <set>. Modele związków encji mają bardziej wyważony charakter i mimo że wartości strukturalne są w nich zasadniczo dopuszczalne, to nie są to ani wartości typu Set, ani inne konstruktory typu kolekcji". Wskutek tego atrybut, którego wartości mają postać zbioru elemen­tów, takie jak np. zbiór adresów gwiazdy omawiany w przykładzie 3.4, zmusza projektanta do tego, aby w modelu związków encji zbiór adresów określać jako zbiór encji oraz utworzyć związek Mieszka-w, który wiąże gwiazdę z jej adresami.

3. W modelu związków encji można określać atrybuty związków. W modelu ODL nie istnieje równoważne pojęcie.

' .lednak istnieją takie definicje formalizmu związków encji. w których typy atrybutów traktuje się podobnie jak w języku ODL: dopuszcza się tam i zbiory i kolekcje lub jeszcze prostszy typy.

132

3.3.1. Od zbiorów encji do relacji

3. RELACYJNY MODEL DANYCH

Na początku rozważmy zbiory encji, które nie są słabe. Modyfikacje, które są potrzebne do przekształcenia słabych związków encji, wprowadzimy w p. 3.3.3. Dla każdego zbioru encji, który nie jest słaby, utworzymy relację o takiej samej nazwie i z takim samym zbiorem atrybutów. W tej relacji nie będzie żadnych danych dotyczących związków, w których dany zbiór uczest­niczy. Związki zostaną zdefiniowane przez osobne relacje, omówimy to za­gadnienie w p. 3.3.2.

PRZYKŁAD 3.10

Rozważmy trzy zbiory encji: Filmy, Gwiazdy oraz Studia z rys. 2.8, który odtwarzamy na rys. 3.15. Atrybutami zbioru eneji Filmy są: tytuł, rok, długość oraz typFilmu. Zatem relacja Filmy wygląda zupełnie tak samo jak relacja Film z rys. 3.1, którym rozpoczęliśmy podrozdział 3.1.

tytuł ) ( rok ) ~nazwisko~ ( adres

Filmy Gwiazdy-w~ ~ Gwiazdy

długość) ~ typFilmu

nazwa

Posiada

Studia

adres

RYSUNEK 3.15

Diagram E/R bazy danych filmów

O

PRZYKŁAD 3.11

A teraz rozważmy zbiór encji Gwiazdy z rys. 3.15. Tutaj występują dwa atrybuty: nazwisko i adres. A więc odpowiednia relacja mogłaby wyglądać następująco:

3.3. OD DIAGRAMÓW ZWIĄZKÓW ENCJI DO PROJEKTÓW RELACYJNYCH I33

>`razwisko adres

Carrie Fisher 123 Maple St., Hollywood Mark Hamill 456 Oak Rd., Brentwood Harrison Ford 789 Palm Dr, Beverly Hills

Ta relacja przypomina relację Gwiazda z rys. 3.6, którą utworzyliśmy w przykładzie 3.3. Jednak miała ona trzy atrybuty, dwa z nich: ulica i mia­sto reprezentowały strukturę adresu. Różnica jest niewielka. Moglibyśmy równie dobrze zaprojektować nasz diagram związków encji z rys. 2.8 tak, aby zbiór encji Gwiazdy miał osobne atrybuty ulica i miasto, co uczyniłoby relację Gwiazdy identycznąz relacjąGwiazda z rys. 3.6.

0

3.3.2. Od związków encji do relacji

Związki z diagramów encji także przyjmują postać relacji. Relacja dane­go związku R ma następujące atrybuty:

1. Dla każdego zbioru encji uczestniczącego w R umieszczamy w sche­macie relacji odpowiadającej R klucze tych zbiorów jako atrybuty tej relacj i.

2. Jeśli związek ma własny klucz, to też dołączamy jego atrybuty do zbioru atrybutów relacji.

Jeśli zbiór eucji uczestniczy w związku wielokrotnie, to musimy przemiano­wać atrybuty po to, by uniknąć konfliktu nazw. Podobnie, jeśli zdarzy się, że te same atrybuty muszą wystąpić w relacji R, jako jej własne atrybuty oraz jako pochodzące ze zbioru uczestniczącego w związku, to też nie można do­puścić do powtarzania się nazw i trzeba dokonać przemianowania.

PRZYKŁAD 3.12

Rozważmy związek Posiada z rys. 3.15. Ten związek łączy ze sobą zbiory Filmy i studia. W schemacie relacji Posiada korzystamy z klucza dla Filmów, czyli atrybutów tytuł i rok, oraz z klucza do Studiów, którym jest nazwa. Poniżej przedstawiamy schemat relacji:

tui rok nazwaStudia Gwiezdne Wojny 1977 Fox Potężne Kaczory 1991 Disney Świat Wayne'a 1992 Paramount

Atrybut nazwa z relacji studia nazwaliśmy tutaj nazwaStudia, aby schemat był bardziej zrozumiały.

I34 3. RELACY.INY MODEL DANYCH

Zauważmy, że powyższy związek oraz związek z przykładu 3.10, który utworzyliśmy dla zbioru encji Filmy (przedstawiony na rys. 3.1), zawierają do­kładnie te same dane, które zawiera związek z rys. 3.12, utworzony w przykładzie 3.6 dla klasy Film, jedynie z pominięciem właściwości gwiazdy.

0

PRZYKŁAD 3.13

Postępując w podobny sposób, można przekształcić związek Gwiazdy-w z rys. 3.15 do postaci relacji z atrybutami tytuł oraz rok (klucz Filmu) oraz z atrybutem nazwiskoGwiazdy, który stanowi klucz do zbioru encji Gwiaz­dy. Na rysunku 3.16 pokazano przykład relacji Gwiazdy-W. Zauważmy, że ta relacja oraz rys. 3.16 zawierają te same dane co rys. 3.13, nie obejmują one tylko tych atrybutów klasy Gwiazda, które nie wchodzą w skład klucza (atry­butów długość i typFilmu), umieszczone na rys. 3.13.

tytu~ rok nazwiskoGwiazdy

Gwiezdne Wojny 1977 Carrie Fisher

Gwiezdne Wojny 1977 Mark Hamill

Gwiezdne Wojny 1977 Harrison Ford

Potężne Kaczory 1991 Emilio Estevez

Świat Wayne'a 1992 Dana Carvey

Świat Wayne'a 1992 Mike Meyers

RYSUNEK 3.16

Relacja związku Gwiazdy-w

Może się wydawać, że na rys. 3.16 atrybut rok jest redundancyjny. Ale wynika to tylko z faktu, że w tym przykładzie nazwy filmów nie powtarzają się. Gdyby tam występowało kilka frlmów o tym samym tytule, np. „King Kong", to rok byłby istotny na przykład do rozstrzygnięcia, które gwiazdy występująca której wersji filmu.

0

Zobaczmy, jakie są zalety schematu bazy danych, który otrzymamy, za­czynając od modelu związków encji w porównaniu ze schematem bazy prze­kształconym z modelu ODL.

• Relacje częściej występują w postaci znormalizowanej niż klasy, co oznacza, że zawierają mniej redundancji niż przy bezpośredniej trans­formacji z opisu ODL.

• Dwukierunkowy związek w modelu ODL zostaje zastąpiony pojedyn­czą relacją, która odzwierciedla związek w obu kierunkach.

PRZYKŁAD 3.14

Również związki wieloargumentowe można w łatwy sposób przekształcić w relacje. Rozważmy'czteroargumentowy związek Kontrakty z rys. 2.12, po­

3.3. OD DIAGRAMÓW ZWIĄZKÓW ENCJI DO PROJEKTÓW RELACYJNYCf~ I3S

wtórzony na rys. 3.17, który obejmuje gwiazdę, film i dwa studia, pierwsze utrzymujące kontrakt z gwiazdą i drugie, które pozyskuje gwiazdę do udziału w konkretnym filmie. Związek ten jest reprezentowany przez relację Kon­trakty, której schemat składa się z atrybutów czterech następujących kluczy dla czterech zbiorów encji:

1. Klucz nazwiskoGwiazdy dla zbioru gwiazd.

2. Klucz złożony z atrybutów tytuł oraz rok dla filmu.

3. Klucz studioGwiazdy wskazujący nazwę pierwszego studia, jak pamiętamy przyjęliśmy założenie, że nazwa studio jest kluczem zbio­ru encji studio.

4. Klucz studioProducenta, który stanowi nazwę tego studia, które produkuje film z udziałem gwiazdy.

Filmy

Kontrakty

Studio ~ ' Studio gwiazdy ) producenta

Studia

RYSUNEK 3.17 Związek Kontrakty

Od ODL do relacji

Jak już wspomnieliśmy, w wyniku przekształcenia związku z modelu związków encji do schematu relacji czasami otrzymujemy lepszy schemat relacyjny bazy danych niż w sytuacjach, gdy przekształcamy związki w ODL do postaci relacji. Jednakże nic nie stoi na przeszkodzie, aby z modeli związków encji zapożyczyć technikę wydzielania w osobną rela­cję związków typu wiele do jeden albo wiele do wiele. Pozwoli to wyeli­minować redundancję oraz mnożenie się liczby encji, co dzieje się czasami przy próbach implementowania związku wielowartościowego w języku ODL przez definiujące go klasy. Poza tym przypomnijmy ponownie, że w podrozdziale 3.7 będzie można poznać automatyczny sposób naprawie­nia schematu relacji, otrzymanego bezpośrednio z opisu w języku ODL.

136

3. RELACYJNY MODEL DANYCI~1

Nazwy atrybutów wprowadzonych do relacji zostały uważnie wybrane, po­nieważ, jeśli jak dotychczas używalibyśmy określenia „nazwa", to nie byłoby jak odróżnić, czy chodzi o nazwę studia producenta, czy o studio gwiazdy.

0

3.3.3. Zasady postępowania ze słabymi zbiorami encji

Jeśli w diagramie związków encji występuje słaby zbiór encji, to trzeba przestrzegać trzech różnych zasad:

Relacja odpowiadająca slabemu zbiorowi encji W musi zawierać nie tylko atrybuty W, ale także te atrybuty kluczy z innych zbiorów enaji, które wchodzą w skład zbioru W. Te wspomagające zbiory encji są łatwe do rozpoznania, ponieważ uczestniczą wraz z W w związkach wiele do jeden, a te związki z kolei w diagramie są oznaczone po­dwójnym rombem.

Każdy związek, który obejmuje słaby zbiór encji W, musi korzystać ze wszystkich atrybutów klucza W, wląezając w to klucze W pochodzące z innych zbiorów encji, które uczestniczą w W.

Jednakże, jak się przekonamy później, związki oznaczane podwójnym rombem, które istnieją po to, aby udostępnić dla zbioru W atrybuty klucza z właściwych zbiorów encji, wcale nie muszą być przekształ­cone w osobną relację. Atrybuty tych związków zawsze będą bowiem stanowić podzbiór słabego zbioru encji W, a tego typu związki nie do­starczają poza tym żadnych innych danych, ich jedyna funkcja polega na odnalezieniu właściwego klucza dla W.

Oczywiście, przy wprowadzaniu do słabego zbioru eneji tych dodatkowych atrybutów trzeba zachować ostroźność i nie dopuścić do tego, aby jakaś na­zwa wystąpiła dwukrotnie. Jeśli jest to konieczne, to część atrybutów, lub nawet wszystkie, trzeba przemianować.

numer ~ ( nazwa ) ( adres

Zespoły ~ednostka-~~ Studia

RYSUNEK 3,18

Zespołyjaka przy=kład stabego zbioru encji

3.3. OD DIAGRAMÓW ZWIĄZKÓW ENCJI DO PROJEKTÓW RELACYJNYCH I3 %

PRZYKŁAD 3.15

Rozważmy słaby zbiór encji Zespo~y z rys. 2.27, który zamieściliśmy ponow­nie na rys. 3.18. Z tego diagramu tworzymy trzy relacje o następujących schematach:

Studia (nazwa, adr)

Zespoły (numer, nazwaStudia) Jednostka-w(numer, nazwaStudia, nazwa)

Pierwsza relacja studia jest wynikiem najprostszego przekształcenia ze zbioru encji o takiej samej nazwie. Druga relacja zespoły jest odpowiedni­kiem słabego zbioru encji Zespoty. Atrybutami tej relacji są atrybuty klucza zbioru Zespo~y. Jeśli istniałyby w tym zbiorze jeszcze inne atrybuty, to trzeba by je dołączyć również do schematu tej relacji. Atrybut w relacji zespoły o nazwie nazwastudia stanowi odpowiednik atrybutu nazwa w zbiorze encj i Studia.

Trzecia relacja Jednostka-w powstaje ze związku o takiej samej na­zwie. Jak we wszystkich przypadkach, tak i tu związek encji reprezentujemy w modelu relacyjnym relacją, której schemat zawiera atrybuty kluczy wszyst­kich zbiorów encji objętych oryginalnym związkiem. W rozważanym przy­padku relacja Jednostka-w zawiera atrybuty numer oraz nazwaStudia, które są kluczem słabego zbioru encji Zespoły oraz atrybut nazwa, który jest kluczem zbioru encji Studia. Zauważmy jednak, że studio o kluczu nazwa­studia jest tym samym studiem, którego kluczem jest nazwa, ponieważ Jednost ka-w jest związkiem wiele do jeden.

Załóżmy na przykład, że Disney #3 oznacza jeden z zespołów w studio Disneya. Zatem w zbiorze związku.7ednostka-w występuje para

(Disney #3, Disney)

Para ta w krotce relacji Jednostka-w będzie reprezentowana następująco:

(3, Disney, Disney)

W konsekwencji możemy w relacji Jednostka-w polączyć atrybuty nazwastudia i nazwa, co da prostszy schemat:

Jednostka-w(numer, nazwa)

A teraz widać już, że można całkiem pominąć relację Jednostka-w, ponie­waż jej atrybuty są podzbiorem atrybutów relacji zespoły.

0

I'R7,YK(,AD 3.16

Rozważmy teraz słaby zbiór encji Kontrakty z przykładu 2.31 i rys. 2.28 z p. 2.6.1. Powtarzamy ten diagram na rys. 3.19. Poniżej zamieszczamy sche­mat relacji Kontrakty:

---