ullman062 (2)

130 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 referencjami od każdego obiektu do odpowiadających obiektów. Taki sposób implementacji jest 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 Fi ln-. 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 „Swiecie WayneV\ 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 relacyjnym był czymś w rodzaju błędu w tym modelu. Jednakże w praktyce buduje się na relacjach indeksy, które umożliwiają bardzo efektywne poszukiwanie 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 nic dłużej niż ułamek sekundy, o tyle w bazach danych stosuje się zupełnie inne 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 rozproszonych systemów komputerowych, jest znacznie trudniejsze. Tutaj dopiero widać, jak silne są argumenty przemawiające za rozwiązaniami stosowanymi w modelu relacyjnym, gdzie nie używa się wskaźników'.

interface Klient!

attribure Struci: nazwisko

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

Struct Te: (string typ, int numer} >telefony;

relatienship Klient okreśionyPrzez inver.se wprowadzenia;

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

};

RYSUNEK 3.14 Rekordy Klienta

I 31

3 3. OD DIAGRAMÓW ZWIĄZKÓW GNCH DO PROJEKTÓW RF.I.ACYJŃYĆH

Ć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 ćwiczeniu 2.1.8 wpływają na postać schematu relacyjnego?

IĆ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 bardzo przypomina przekształcanie projektów w języ ku 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. Du ie 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ładowy m pojęcia klasy. Ta różnica pozwala 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 elementów¹, takie jak np. zbiór adresów gwiazdy omawiany w przy kł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.

' Jednak 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 prostsze typy.