ullman035 (2)

76 2. MODELOWANIE BAZ DANYCH

2.3.4. Dobór właściwych elementów

Czasami sytuacja pozwala na wybór typu elementu projektu odpowiadającego obiektowi ze świata rzeczywistego. Wybiera się zazwyczaj między zbiorem encji, atrybutem, klasą lub związkiem. Z reguły jest łatwiej zaimplementować atrybut niż zbiór encji czy klasę lub związek. Jednak określenie wszystkiego jako atrybutu zazw yczaj pow oduje kłopoty.

PRZYKŁAD 2.16

Rozważmy szczególny przypadek. Czy mądrze postąpiliśmy, określając na rys. 2.6 i 2.8 studio jako zbiór encji lub klasę? Być może zamiast tego powinniśmy byli nazwę i adres studia dołączyć do atrybutów filmów i w ten sposób wyeliminować zbiór encji lub klasę studia. Jednym z powodów wyboru bardziej złożonego elementu było to, że w przeciwnym przypadku trzeba by wielokrotnie powtarzać nazwę i adres studia przy każdym filmie. Prowadzi to do redundancji, a w dodatku do kłopotów, jakie są związane z redundancją, omawianych w^f p. 2.3.2; ryzykujemy, że jeśli w bazie nie będzie filmu z określonego studia, to jego dane nie będą dostępne.

Jeśli jednak zdecydujemy, że nie warto przechowywać adresu studia, to nic nie szkodzi, że nazwa studia stanie się atrybutem filmu. Jeśli nic będzie w schemacie bazy adresu, to nie będzie redundancji. Bowiem powtarzanie się tej samej nazwy w cncjach, np. nazwy Disney przy filmach produkowanych w'studio Disney, nic stanowi rzeczywistej redundancji, ponieważ w jakiś sposób trzeba identyfikować właściciela każdego filmu osobno, podanie nazwy studia wydaje się tutaj całkiem na miejscu.

□

Proponujemy stosować ogólną zasadę, polegającą na tym, że jeśli z pewnym elementem wiążą się poza nazw'ą jeszcze inne dane, to trzeba ten element definiować jako zbiór encji albo jako klasę. Natomiast, jeśli w' schemacie ma występować wyłącznie nazwa, to najczęściej lepiej, by pojawiła się ona w charakterze atrybutu. Rozróżnienie to wiąże się ściśle z problematyką normalizacji schematu w modelu relacyjnym, którą przedstawimy w podrozdziale 3.7.

PRZYKŁAD 2.17

Rozważmy zagadnienie, które polega na właściwym wyważeniu proporcji między stosowaniem albo związków wieloargumentowych, albo połączenia zbioru encji i związków binarnych. Rozważaliśmy już przedstawiony na rys. 2.12 związek czteroargumentowy Kontrakty obejmujący gwiazdę, film i dw-a studia oraz jego przekształcenie do zbioru encji Kontrakty z rys. 2.15. Czy jest istotne, którą postać wy bierzemy?

W języku ODI. nie ma wyboru, ponieważ projekty nie mogą zawierać związków wieloargumentowych. W modelu związków encji oba podejścia są

równie właściwe. Jednak drobna zmiana w sformułowaniu zadania może już wymusić konieczność przyjęcia projektu zawierającego zbiór encji, a nie związek wieloargumentowy. Załóżmy, że kontrakt dotyczy aktorki, filmu oraz zbioru studiów. Jest to sytuacja bardziej skomplikowana niż ta, którą opisano na rys. 2.12, gdzie dwa studia występowały w dwóch różnych rolach. Tym razem związek może powstać między różnymi studiami, które są odpowiedzialne za różne przedsięwzięcia, np. jedno za produkcję, drugie za efekty' specjalne, jeszcze inne za dystrybucję itp. Nic można z góry przewidzieć wszystkich funkcji, jakie mogą być pełnione przez studia.

Okazuje się, że zbiór encji związku Kontrakty składa się z trójek postaci:

(gwiazda, film, zbiór-studiów)

a sam związek Kontrakty obejmuje nie tylko zbiory encji Gwiazdy i Filmy, ale również nowy zbiór encji, którego encjami są zbiory różnych studiów. Taka sytuacja może się zdarzyć naprawdę, a traktowanie zbioru zawierającego studia tak samo jak encji podstawowych wydaje się nienaturalne, więc nic zalecamy tego rozwiązania.

W takim przypadku jest lepiej potraktować Kontrakty jako zbiór encji. Tak samo jak na rys. 2.15 encja kontrakt łączy gwiazdę, film i zbiór studiów, ale teraz nie można ograniczać liczby studiów. Związek między kontraktami i studiami jest zatem obecnie typu wiele do wiele, a nie wiele do jeden, jak to było w przypadku, gdy kontrakty były łączącym zbiorem encji. Na rys. 2.18 przedstawiono diagram modelu związków encji. Widać na nim, że kontrakt jest powiązany z jedną gwiazdą, jednym filmem, ale całym zbiorem studiów.

Ten sam sposób projektowania jest właściwy w modelu ODL. Na przykład poprawna jest w modelu ODL poniższa deklaracja interfejsu:

inr.erface Kontrakt.{

relationship Gwiazda taGwiazda; relationship Film ter.Fi lm; relationship Set<studio> studia; ł;

Tutaj obiekty' klasy kontrakty mają trzy związki: z jedną gw iazdą, z jednym filmem oraz zbiorem zawierającym studia. Związki odwrotne zostały pominięte.

□