| Obiektowy model danych |
|---|
| Napisane przez Wed 08 Feb 2006 przez Artur (3273 cztane) |
|
Podstawową ideą wprowadzenia tego modelu danych było podniesienie poziomu abstrakcji. Rozumowanie to przekłada się na odrzucenie rozwiązań zaczerpanych z komputerowych tworów takich jak rekordy, a zamiast tego zbliżyć się do obiektów i operacji na nich wykonywanych, co przypomina znaczniej odpowiedniki ze świata rzeczywistego. Połączenie pojęć obiektowości z języków programowania wraz z koncepcjami baz danych w rezultacie dała obiektowe bazy danych. Wielka niejednoznaczność tego modelu wynika z rozwoju podejścia obiektowego w trzech różnych obszarach: językach programowania, sztucznej inteligencji, oraz bazach danych. Różne języki programowania i reprezentowania wiedzy wnoszą pewne różnice w interpretowaniu obiektów. Rezultatem tego jest standard ODMG, który nie doczekał jeszcze formalnego zatwierdzenia przez ANSI, IEEE, czy ISO. Innymi słowy w obecnych czasach w dalszym ciągu są prowadzone prace nad wprowadzeniem standardu pojęć obiektowych w dziedzinie baz danych [1]. Ewolucja inżynierii oprogramowania obecnie skłania się w kierunku obiektowości, co z kolei wprowadza szereg problemów związanych się z niezgodnością modelu danych z architekturą systemu. Przykładem tu może być choćby trud włożony w konwersję typów danych pomiędzy systemami obiektowymi a systemami opartymi o SQL. Tak jak wspomniałem, grupa ODMG (od ang. Object - Oriented Data Model) skupiająca wielu producentów jest obecnie jedynym rozwiązaniem dla standaryzacji obiektowego modelu danych. Istotą tego jest określenie wewnętrznej semantyki zrozumiałej dla obiektowych systemów zarządzania bazą danych. Obecny standard ODMG 3.0 posłuży mi w dalszej części tego artykułu jako podstawa do opisu obiektowego modelu danych. Struktura danych Podstawowymi elementami modelowania są obiekty i literały. Obiekty są tu opisywane przez strukturę, identyfikator, nazwę i czas życia. Struktura obiektu uzależniona jest od jego typu. Wyróżnia się obiekty typu: atomowe, typy kolekcji i strukturalne. Jako, że typ również jest obiektem, można powiedzieć, że obiekty atomowe mogą być definiowane przez użytkownika. W obiektach kolekcji wyróżniamy Set, Bag, List, Array, Dictionary, natomiast w obiektach strukturalnych Date, Time, Timestamp, Interval. Za unikalną tożsamość odpowiadają tu tzw. identyfikatory obiektu, które nie ulegają zmianie i nawet po usunięciu obiektu nie są wykorzystywane. Dla przejrzystości i zrozumienia dla użytkownika, obiekt może zawierać nazwę. Czas życia, niezależny od typu jest określany w momencie tworzenia obiektu. Wyróżnia się w tym kontekście obiekty ulotne i trwałe. Ulotny kiedy system zarządzania pamięcią języka programowania decyduje kiedy pamięć obiektu jest alokowana i zwalniana w trakcie działania programu. Trwały kiedy zarządzany jest przez system zarządzania danymi. Literały cechują się wartością stałą, która dopuszcza złożoność struktury. Nie ma sposobu na bezpośrednie odwoływanie się do nich, gdyż zważywszy, że nie posiadają identyfikatora zawsze należą do jakiegoś obiektu. Typy literałów dzielimy na: atomowe, kolekcji, strukturalne i puste. Literały strukturalne zawierają stałą liczbę nazwanych, różnorodnych elementów (date, time, timestamp, interwal, structure). Literały atomowe to: long, long long, short, unsigned long, unsigned short, float, double, boolean, octet, char, string, enum. Literały kolekcji to: set, bag, list, array, dictionary. Kolekcje zawierają dowolną liczbę nienazwanych elementów jednolitego typu, z których każdy może być wystąpieniem typu atomowego, innej kolekcji lub typu literału. Przechodzenie przez poszczególne elementy kolekcji jest realizowane przez tzw. iteratory, które przechowują aktualną pozycję w ramach danej kolekcji. Model obiektowy dopuszcza pięć wbudowanych podtypów kolekcji: Set, Bag, List, Array, Dictionary. Zdefiniowane przez użytkownika obiekty, które nie należą do obiektów kolekcji nazywamy obiektami atomowymi. Obiekty atomowe przedstawia się klasą z opisującym ją stanem i zachowaniem. Stan określany jest przez wartości atrybutów lub związek pomiędzy danym i drugim obiektem. Znając typ obiektu można określić atrybut, który może przyjmować jako wartość literał lub identyfikator obiektu. Zachowanie definiowane jest przez operacje, które mogą być wykonywane przez obiekt lub na obiekcie. Każda operacja zawiera sygnaturę, która określa nazwę i typy jej argumentów, nazwy wyjątków które mogą wystąpić w trakcie operacji i jeżeli istnieją to nazwy zwracanych wartości. Omawiany model przewiduje jedynie związki binarne o krotności 1:1, 1:* oraz *:*. Nie wyróżnia się przy tym nazwy. Określa się tu ścieżki przejścia w obu kierunkach. W pewnym kontekście zostały również rozróżnione takie pojęcia jak: interfejsy i klasy. Interfejsem nazwano opis abstrakcyjnego zachowania typu obiektu za pomocą specyfikacji operacji. I w przeciwieństwie do klasy nie jest możliwe tworzenie wystąpień interfejsów, innymi słowy jest to pojęcie abstrakcyjne. Klasa natomiast definiuje abstrakcyjny stan oraz zachowanie, a ponad to jest pojęciem implementacyjnym. Dodatkowo definicja klasy może określać ekstensje i klucze. Ekstensja jest zbiorem wszystkich wystąpień danego typu w konkretnym systemie zarządzania danymi. Klucz natomiast jest jednoznacznym identyfikatorem każdego wystąpienia typu. Transakcje zostały po prostu zdefiniowane jako logiczna jednostka pracy która przeprowadza bazę danych ze stanu spójnego w stan spójny. Mowa tu o założeniu, z którego wynika że realizacja sekwencji transakcji odbywa się w ramach wątku sterowania. Wielodostęp realizuje tzw. protokół pesymistyczny za pośrednictwem standardowych blokad zapisu i odczytu. Integralność danych Możliwe, że powyższe pojęcia niezbyt oczywiście ukazały, jak w obiektowym modelu danych realizowane są reguły integralności. Omówione pojęcie tożsamości świetnie spełnia to zadanie. Przypisanie każdemu utworzonemu obiektowi, tzw. OID (Object Identifier), identyfikatora obiektu decyduje o jego unikalności. Zaletą jest fakt, iż unikalność obiektu ma zasięg w całym systemie co w porównaniu z integralnością referencyjną w modelu relacyjnym jest znacznie skuteczniejsze. Efektywność tego rozwiązania wynika z faktu, iż nie wymaga wielkiej pamięci nawet dla skomplikowanego obiektu. Zauważa się nawet rozmiar mniejszy od nazwy słownej. Niezależność wartości identyfikatora od danych obiektu, należy również dla pożądanej cechy. Integralność referencyjna jest zachowana automatycznie przez system zarządzania danymi. Próba skorzystania ze ścieżki przejścia do obiektu, który został usunięty kończy się wygenerowaniem błędu. Wbudowane operatory pozwalają dodawać i usuwać elementy ze związku przy możliwości kontrolowania więzów integralności. Operowanie danymi Operowanie danymi, podobnie jak w całym omawianym obszarze nie ma tak solidnej podstawy matematycznej jaką ma model relacyjny. Model ODMG wprowadził natomiast obiektowy język zapytań OQL co pozwala na deklaratywny dostęp do bazy danych. W podobieństwie do SQL, można OQL używać samodzielnie lub jako język osadzony w innym języku programowania, dla którego oczywiście zostało zdefiniowane odpowiednie wiązanie ODMG (Smalltalk, C++, JAVA). OQL można stosować do dostępu asocjacyjnego oraz nawigacyjnego. Wynikiem zapytania asocjacyjnego jest kolekcja obiektów, podczas gdy zapytania nawigacyjne stosuje się dla odwołania do pojedynczych obiektów[2]. Teraźniejsze aplikacje baz danych to wysoce zaawansowane systemy wykorzystujące technologię obiektową. Brak jednoznacznego modelu danych, który można by było porównać analogicznie do relacyjnego, wprowadził na rynek wiele komercyjnych rozwiązań. Pojęcia obiektowego modelu danych były i są rozwijane w wielu różnych dziedzinach, przez wielu różnych producentów. O wprowadzeniu jednoznacznie interpretowanego standardu nie trzeba było przekonywać nikogo. Grupa ODMG założona przez wielu producentów, zdefiniowała model obiektowy, który opisuje standardowy model semantyki obiektów bazy danych. Obiektowy model danych zalicza się trzeciej generacji modelu danych gdzie istnieje możliwość wiernego odwzorowania rzeczywistych obiektów, co było i jest niezmiernie pożądane. Jak wspominałem wcześniej istnieje wiele dziedzin w których jedynie obiektowa baza danych staje na wysokości zadania. Możliwość stosowania powiązań wiele do wiele, konstrukcji obiektów złożonych jest tu nie tylko realne ale znacznie prostsze jak w poprzednich modelach. Redundancja danych jest dobrze znanym problem w bazach danych, tu w modelu obiektowym można tworzyć nadklasę na podstawie wybrania cech wspólnych dla kilku klas. Przejrzystość struktury za sprawą generalizacji i dziedziczenia wpływa korzystnie na wprowadzane zmiany, co w połączeniu ze ścisłym powiązaniem danych i aplikacji pozwala na prostszą ewolucję schematu. Odmienny jest również dostęp nawigacyjny, w stosunku do dostępu zbiorowego w SQL. Taki dostęp, jest bardziej odpowiedni chociażby przy obsłudze części o wielu podzespołach czy też w realizacji zapytań rekurencyjnych. -------------------------------------------------------------------------------- [1] Thomas Connolly, Carolyn Begg. Sytemy baz danych. Tom II. Warszawa 2004. [2] Ian Graham. Metody obiektowe w teorii i praktyce. Warszawa 2004. |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.