Bazy danych

Większość projektowanych aplikacji to systemy bazodanowe. O ile gra lub program edukacyjny może przechowywać dane w pliku(ach), o tyle system wspomagający pracę firmy powinien używać motoru bazy danych. Dysonans polega na tym, że systemy projektuje się i implementuje z użyciem metod/języków obiektowych. Natomiast prymat wśród baz danych wiodą bazy relacyjne. Niniejszy odcinek jest próbą przybliżenia problematyki mapowania modelu relacyjnego na model obiektowy.

W postępowaniu mającym na celu zaprojektowanie systemu informatycznego (który jest realizowany obiektowo ale korzysta z relacyjnej bazy danych) można wyróżnić dwa kierunki:

-wyjście od modelu relacyjnego, który następnie będzie wykorzystany przez obiektową aplikację – tzn. najpierw powstaje projekt bazy danych a później projekt aplikacji klienckiej [1]. W pracy [5] podano, że każdą, nawet nie relacyjną bazę danych należy projektować na poziomie logicznym jako relacyjną odpowiednio później przekształcając projekt.

-wyjście z modelu obiektowego, który następnie mapuje się na model relacyjny [7].

W niniejszym artykule zostanie omówione podejście drugie jako bardziej naturalne. Zastosowanie podejścia pierwszego oznacza w zasadzie odrzucenie metod projektowania obiektowego na rzecz metod strukturalnych i wykorzystanie języka obiektowego do wytwarzania aplikacji klienta. W podejściu drugim samo zdefiniowanie i zaimplementowanie klas biznesowych nie nastręcza w miarę doświadczonemu projektantowi i programiście zbytnich problemów. Pojawiają się one natomiast przy mapowaniu modelu obiektowego na relacyjny:

Poza problemami wynikającymi z teoretycznych różnic pomiędzy modelem relacyjnym i obiektowym istnieją jeszcze pewne konsekwencje natury praktycznej. System informatyczny wytwarzany jest zgodnie z innym, niż wodospadowy, modelem cyklu życia oprogramowania. W kolejnych iteracjach system taki ulega zmianom – są dodawane nowe klasy (encje), moduły czy wreszcie zmienia się zakres danych, które ma przechowywać system. Na skutek tych zmian mapowanie klas (obiektów) na tabele komplikuje się dość znacznie. Zmiany w fizycznym modelu danych pociągają zmiany w kodzie aplikacji klienckiej [6], co możne być przyczyną różnych błędów i trudności. Przejście z jednego modelu na drugi, bez wsparcia ze strony odpowiednich bibliotek czy narzędzi, choć pracochłonne, jest możliwe. Dla zwiększenia efektywności warto jednak używać gotowych rozwiązań.

Jednym z głównych problemów jest mapowanie na model relacyjny dziedziczenia, które jest kluczowe w metodologii obiektowej. W modelu relacyjnym to ostatnie nie występuje. W pracy [7] wyróżniono następujące rozwiązania tego problemu:

1)zmapowanie całej hierarchii klas do pojedynczej tabeli,

2)zmapowanie każdej nieabstrakcyjnej klasy do osobnej tabeli,

3)zmapowanie każdej klasy (również abstrakcyjnej) z hierarchii do osobnej tabeli,

4)zmapowanie hierarchii klas do uniwersalnego (generycznego) schematu.

Zaletą pierwszego z rozwiązań [7] jest prostota i szybkość dostępu do danych. Wadami są: szybki rozrost tabel, możliwa propagacja zmian w obrębie jednej klasy na inne klasy i nieefektywne wykorzystanie miejsca w bazie danych. Ma ono zastosowanie do prostych hierarchii, gdzie nie zachodzi zjawisko wielokrotnego dziedziczenia. Drugie z rozwiązań [7] zapewnia podobnie jak pierwsze łatwy dostęp do danych, ale zmiana w obrębie klasy (dotycząca atrybutów, które mają być przechowywane) pociąga za sobą zmiany w tabeli. Ponadto zmiany w klasie bazowej pociągają zmiany we wszystkich tabelach. Trudno jest zapewnić integralność danych, jak również znacznie ograniczona jest możliwość pełnienia różnych ról przez ten sam obiekt. Rozwiązanie to należy stosować, gdy nie przewiduje się częstych zmian klas (typów) i nie ma wielokrotnego dziedziczenia. Trzecie z rozwiązań jest koncepcyjnie łatwe ale zapis i odczyt danych może trwać dłużej [7], nietrudno natomiast dodawać nowe typy i modyfikować istniejące. Rozwiązanie to można stosować również w przypadku wielokrotnego dziedziczenia.

Ostatnie z rozwiązań [7] jest najbardziej elastyczne ale niestety najbardziej złożone. Jest ono bardzo uniwersalne ale staje się nieefektywne przy dużych ilościach danych.

Na marginesie tych rozważań należy stwierdzić, że choć mapowanie odbywa się w ten sposób, że odpowiednikiem kasy jest tabela (lub kilka tabel) to jest to niezgodne z teorią. W pracy [5] podano, iż odpowiednikiem klasy jest dziedzina a nie tabela.

Zagadnienia związane, z mapowaniem modelu relacyjnego na obiektowy zostaną zaprezentowane na przykładzie (uproszczonego) fragmentu systemu do obsługi przychodni lekarskiej. Oczywiście przedstawiony fragment stosuje najprostsze z możliwych rozwiązanie służące do definiowania specjalności lekarza. Omawiany fragment jest jednak wystarczający do pokazania podstawowych zagadnień związanych z mapowaniem – zawiera zarówno dziedziczenie jak i relację asocjacji typu wiele do wielu. Omawiany fragment systemu przedstawiono na rys. 1. Klasa Lekarz dziedziczy z klasy Osoba. Lekarz ma dowolnie wiele specjalności, jak również może istnieć dowolnie wielu lekarzy danej specjalności.

Język UML