74563 ullman069 (2)

3. RELACYJNY MODEL DANYCH

ciu. jeśli chcemy odszukać określony obiekt, to tr/.cba przeszukać szereg relacji, zanim trafi się na właściwą. Jeżeli na przykład chcemy odszukać czas trwania pewnego filmu, to korzystając ze schematu z przykładu 3.17, zanim znajdziemy właściwy film, musimy przeszukać cztery różne relacje, w których umieszcza się filmy.

Przy przekształcaniu diagramów encji natomiast trzeba dla danego obiektu w każdym zbiorze encji lub związku, w którym pojawia się obiekt, powtórzyć jego klucz. Takie powtórzenia są marnowaniem przestrzeni na dysku. Ponadto la metoda powoduje, że powstaje konieczności uzyskiwania danych o obiekcie z wielu relacji. Taki przypadek pojawiłby się w schemacie bazy danych z przykładu 3.18, gdybyśmy chcieli uzyskać dane jednocześnie o czasie trwania kryminału, jak i użytej tam broni.

3.4.4. Tworzenie relacji z wartościami pustymi

Jeszcze inny sposób reprezentowania danych o strukturze hierarchicznej polega na zastosowaniu pustych wartości, które oznacza się NUT',. Jeśli w jakiejś krotce występuje pusta wartość pewnego atrybutu, to oznacza to nieformalnie, że w tej krotce wartość tego atrybutu nic może zostać określona. Mimo że wartości puste nie występują w tradycyjnym ujęciu modelu relacyjnego, to są bardzo wygodne i odgrywają znaczącą role w języku zapytań SQL, o czym przekonamy się w podrozdziale 5.9.

Jeśli jednak dopuścimy stosowanie w krotkach wartości null, to hierarchie klas można przedstawić w jednej relacji. Relacja taka ma wszystkie atrybuty, które dotyczą właściwości obiektów z dowolnej klasy w hierarchii. Dzięki temu jeden obiekt jest opisywany w jednej krotce. Atrybuty, które są spoza podklasy danego obiektu, przyjmują w krotce wartości NULL.

PRZYKŁAD 3.19

Gdybyśmy zastosowali ten sposób do rozwiązania problemu z przykładu 3.17, to otrzymalibyśmy jedną relację, o następującym schemacie:

Film (tytuł, rok, długość, typFilmu, nazwaStudia, nazwiskoGwiazdy, głos, broń)

Pilmy takie jak na przykład Kto zabił królika Rogera?, które są zarówno kreskówkami. jak i kryminałami, byłyby tu reprezentowane jako kilka krotek, w których nie pojawia się wartość pusta, bowiem dla każdego głosu musiałaby istnieć osobna krotka'. Natomiast taki film jak Mała Syrenka, który jest

W rzeczywistości, ponieważ w filmie o Króliku Rogerze występują nie tylko głosy gw iazd, lecz również same gwiazdy, więc dla każdej pary (gwiazda, głos) musiałaby w relacji pojawić się odrębna krotka Film. który jest czystą kreskówką, miałby przypisaną wartość pustą dla atrybutu nazwiskoGwiazdy, a głosy i inne dane byłyby podane.

kreskówką, ale nie jest kryminałem, miałby przypisaną wartość NULL do atrybutu broń. Film Orient Ekspres miałby określoną wartość NULL dla atrybutu głosy, podczas gdy dla Przeminęło z iwiatrem wartość NULL pojawiłaby się zarówno w polu atrybutu głos, jak i broń.

□

Zauważmy, że w wyniku zastosowania tego podejścia, tak samo jak w przypadku metody opisanej w p. 3.4.2, w jednej relacji występują wszystkie krotki z wszystkich klas tworzących hierarchię. Ponadto, podobnie jak przy użyciu sposobu przedstawionego w p. 3.4.1, możemy wszystkie dane o obiekcie odnaleźć w jednej relacji.

3.4.5. Ćwiczenia do podrozdziału 3.4

Ćwiczenie 3.4.1. Należy przekształcić diagram związków encji przedstawiony na rys. 3.23 do postaci relacyjnego schematu bazy danych.

RYSUNbK 3.23

Diagram K/R dla ćwiczenia 3.4.1

Ćwiczenie 3.4.2. Na rysunku 3.24 przedstawiono w języku ODL opis schematu, który przypomina diagram związków encji z ćwiczenia 3.4.1. Trzeba ten opis przekształcić do postaci relacyjnego schematu bazy danych. Należy przy tym pamiętać, ze obiekt Wykład ma „identyfikator obiektu'' i można w związku z tym wprowadzić własny atrybut odpowiadający temu identyfikatorowi, np. idWykładu. Nie trzeba jednak tutaj stosować strategii przekształcania słabych zbiorów encji, którą opisywaliśmy przy okazji ćwiczenia 3.4.1 (chyba że ktoś koniecznie chce).

interface Wykład{

attribute int numer; actribute string sala;