47796 ullman034 (2)

74 2. MODELOWANIE BAZ DANYCH

2.3.1. Dokładność

Przede wszystkim projekt powinien dokładnie odpowiadać specyfikacji. Oznacza to, że klasy lub zbiory cnej i oraz ich atrybuty powinny odzwierciedlać świat rzeczywisty. Nie należy przypisać atrybutu liczba-cylir.drów do klasy Gwiazda, mimo że taki atrybut może mieć sens dla zbioru cncji lub klasy Automobil. Każdy element dołączony do projektu musi odpowiadać pewnej wiedzy o jakiejś części modelowanego świata rzeczywistego.

PRZYKŁAD 2.14

Związek Gwiazdy-w między Gwiazdą a Filmem powinien być związkiem wiele do wiele. Wynika to z obserwacji, że gwiazda może występować w więcej niż jednym filmie, a z kolei w jednym filmie może występować wiele gwiazd. Dlatego będzie błędem, jeśli związek Gwiazdy-w określimy jako w'iele do jeden (obojętne, w którą stronę), albo jako jeden do jeden.

□

Redundancja i związki odw rotne

Można by pomyśleć, że użycie związku i związku odwrotnego w języku ODL jest przykładem projektu redundancyjncgo (nadmiarowego). A przecież nie należy zakładać, żc związek i jego odwrotność wystąpią jako dwie odrębne struktur)' danych, takie jak wskaźniki w jedną i drugą stronę. Z definicji związku i jego odwrotności wynika bowiem jedynie, że związek można skierować w dowolną stronę.

Jeśli jednak podejmiemy próbę implementowania związku poprzez dwie różne struktury danych, to istotnie narazimy się na ryzyko powstania redundancji. Zwłaszcza programista systemu DBMS bazującego na języku ODL musi ze szczególną uwagą zaimplementować aktualizacje danych, ponieważ wskaźniki muszą być synchronizowane ze zmianami w bazie. Jednak jest to problem na poziomie systemu i można spokojnie założyć, że autor projektu zrobi to (w końcu) dobrze. Mniej znaczące jest i tak ryzyko redundancji na poziomic implementacji wobec faktu znacznego przyspieszenia zmiany kierunku związku dzięki utrzymywaniu wskaźników w obu kierunkach.

2.3.2. Unikanie redundancji

Trzeba starać się, aby unikać powtórzeń. Na przykład utworzyliśmy związek Posiada między' filmami a studiami. Równic dobrze mogliśmy dodać atrybut nazwaStudia do zbioru encji Filmy. Mimo że nic jest to zabronione, to jest to niebezpieczne z kilku powodów:

1.    Dwa wystąpienia danych informujących o fakcie posiadania studia zajmują więcej miejsca niż pojedyncze wystąpienie.

2.    Gdyby film został sprzedany, to mogłoby się zdarzyć, że zmienilibyśmy tylko studio powiązane przez związek Posiada, a zapomnielibyśmy o tym, że trzeba zmienić również wartość atrybutu fiazwaStudia lub na odwTÓt. Oczywiście można się kłócić, czy wolno popełniać błędy, ale w praktyce są one częste i próby określania tego samego w dwóch różnych miejscach są ew identnym szukaniem kłopotów.

W sposób bardziej sformalizowany zostaną potraktowane te zagadnienia w podrozdziale 3.7, tam też poznamy pewne narzędzia pozwalające tak zmienić projekt bazy danych, aby redundancja i problemy, które powoduje, znikły.

2.3.3. Prostota

Należy unikać wprowadzania do projektu w ięcej elementów' niż naprawdę potrzeba.

PRZYKŁAD 2.15

Załóżmy, że zamiast związku między Filmami a Studiami wprowadzimy instytucję „posiadacz-filmu’’, która będzie określać właściciela pojedynczego filmu. W modelu może to być klasa lub zbiór encji Posiadacz. Zależność między filmem a jego posiadaczem opisze w^:ówczas związek jeden do jeden o nazwie Pośredniczy. Schemat z rys. 2.17 uzupełnia związek typu jeden do wiele skierow any od Posiadacza do Studia.

RYSUNEK 2.17

Nieprawidłowy projekt z niepotrzebnym zbiorem encji

Technicznie rzecz ujmując, schemat z rys. 2.17 rzetelnie opisuje rzeczywistość, ponieważ można dla danego filmu na jego podstawie określić właściwe, jedyne studio produkujące ten film, korzystając ze zbioru encji Posiadacz. Jednak, poza takim pośrednictwem, nie widać żadnego innego zastosowania dla Posiadacza, lepiej więc obywać się bez niego. Powoduje on tylko to, że programy korzystające ze związku film-studio są bardziej skomplikowane, zajmuje pamięć i generuje dodatkow-c błędy.

□