41692 ullman057 (2)

.v    ur« i mvu« • -

przy migracji do modelu relacyjnego. Szczegółowo omówimy tylko konstruktor Set, który rozpowszechnił się najbardziej.

Uwagi na temat jakości danych :-)

Podczas obmyślania stosownych przykładów danych osobowych, zdecydowaliś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 zaw iera 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, dopiero 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ź-dzic 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ż)', a pozostałe dwie gwiazdy filmowe, wymienione na rys. 3.6 mają tylko jeden dom. Wówczas zapisujemy dw'ie krotki, w których atrybut nazwisko ma wartość Carrie ^Tischer, co jest przedstawione na rys. 3.8. Inne krotki pozostają takie same jak na rys. 3.6.

interface Gwiazda {

attribute strir.g nazwisko; attribute Set<

Struct Adr {string ulica, strir.g miasto}

> adres;

} ;

RYSUNEK 3.7

Gwiazdy zc zbiorami adresów

nazwisko	ulica	miasto
Carrie Fischer	123 Mapie St.	Hollywood
Carrie Fischer	5 Locus Ln.	Maliku
Mark Haznill	456 Oak Rd.	3rentwood
Harrison Ford	789 Palm Dr.	7?overiy Hilłs

RYSUNEK 3.8 Dopuszczenie zbioru adresów

□

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 miejscach, gdzie model ODL jest bardziej elastyczny i dopuszcza opisywanie właściwości w postaci struktur złożonych. Można nawet poczuć chęć totalnego odrzucenia modelu relacyjnego lub potraktowania go jako prymitywnej koncepcji wypartej przez elegantsze techniki obiektowe, takie jak ODL. Jednak w rzeczywistości na rynku dominują systemy baz danych realizowane 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 $QL, językowym 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 Dar a, 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, miasro, dataUrodzer.: a)

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

interface Gwiazda {

attribute string nazwisko; atrribute Set<

Struci Adr {string ulica, string miasto}

> adres;

ar.tribute Dare dataUrodzenia;

};

RYSUNEK 3.9.

Zbiór adresów i dai urodzenia gwiazd