BAZY DANYCH model obiektowy Opracował: dr inż. Piotr Suchomski
Wprowadzenie Relacyjny model danych jest zbyt płaski i prosty do reprezentacji danych o bardziej skomplikowanej i nieregularnej strukturze (p. dane multimedialne). W teorii baz danych istnieją inne modele, za pomocą których można lepiej odwzorować rzeczywiste obiekty danych. Głównym, alternatywnym do relacyjnego modelu danych jest model obiektowy.
Obiektowy model danych Obiektowa koncepcja baz danych bazuje na rozszerzonej koncepcji obiektowych języków programowania takich jak C++ czy Java o mechanizmy zapewniające trwałość danych. W czasie wykładu zostanie przedstawiony czysty model obiektowy ODL Object Definition Language, zdefiniowany przez organizację ODMG Object Data Managment Group)
Cechy obiektowości Rozbudowany system typów, Pojęcie klasy, które są typami związanymi z ekstensją lub zbiorem obiektów należących do danej klasy. Klasa oprócz atrybutów, które mogą być typami atomowymi lub złożonymi, może zawierać metody, które są procedurami stosowanymi do obiektów danej klasy. Tożsamość obiektu (jednoznaczny identyfikator) niezależna od jego wartości. Dziedziczenie, które pozwala tworzyć hierarchiczną organizację klas, w której klasy niższe dziedziczą właściwości klasy wyższej.
System typów Można korzystać z typów atomowych (liczby całkowite, rzeczywiste, łańcuchy znaków, typy logiczne itp.) Korzystając z tzw. konstruktorów typów można tworzyć nowe typy:
System typów Typ struktury służy do tworzenia typu rekordu. Analogicznie jak struktury w języku C i C++ składają się z określonej liczby pół, a każde pole jest określonego typu. Typ kolekcji gdy jest dany jakiś typ T to za pomocą różnych operatorów kolekcji można utworzyć np. tablice, listy, zbiory (np. lista liczb całkowitych, zbiór liczb naturalnych, tablica rekordów itp.) Typ referencji Referencją do typu T jest typ, którego wartości jednoznacznie wskazują na wartości typu T (wskaźniki).
Identyfikacja obiektu W modelu obiektowym zakłada się, że każdy obiekt posiada dokładnie jeden, niepowtarzalny identyfikator (OID object identity). W modelu obiektowym mogą istnieć dwa obiekty o takich samych wartościach ale różnych identfikatorach.
Metody i hermetyzacja Klasa może, ale nie musi, posiadać funkcje/metody pozwalające przetwarzać dane obiektów danej klasy. Dzięki metodom możliwa jest realizacja hermetyzacji (encapsulate). Ograniczony jest dostęp bezpośredni do danych obiektów. Wszystkie operacje na danych wykonywane są wyłącznie za pomoca metod. Takie rozwiązanie pozwala zabezpieczyć obiekty danych przed modyfikacjami jakich nie przewidział projektan bazy. Hermetyzacja jest jedną z podstaw tworzenia niezawodnego oprogramowania.
Hierarchia klas - dziedziczenie Pewna klasa C może być podklasą klasy D. Podklasa C dziedziczy wszystkie własności oraz metody klasy D włącznie z jej typem. W klasie C mogą być zdefiniowane dodatkowe własności oraz metody lub metody klasy C mogą zastępować metody klasy D.
Jezyk ODL Język ODL jest standardowym językiem do specyfikowania struktury bazy danych w terminologii obiektowej. Stanowi on rozszerzenie języka IDL (Interface Description Language), który jest składnikiem standardu CORBA (Common Object Request Broker Architecture) znany standard obiektowego przetwarzania rozproszonego.
Projekt klas w ODL W skład projektu klas w języku ODL wchodzą 3 składniki: Atrybuty wartości związane z obiektami danej klasy, Związki opisują powiązanie danego obiektu z obiektami innych klas, Metody funkcje, które pozwalają przetwarzać dane obiektów danej klasy. Atrybuty, związki i metody tworzą własności klasy.
Atrybuty W modelu obiektowym atrybuty nie muszą być typu atomowego. Class Film{ }; attribute string tytul; attribute integer rok_prod; attribute integer czas_trwania; attribute enum dźwięk{mono, stereo, DD, SDDS} standarddzwieku; Class Aktor{ }; attribute string nazwisko; attribute Struct Adr{miasto, ulica, nr_domu} adres;
Typy w języku ODL Typy atomowe typy całkowite, zmiennoprzecinkowe, łańcuchy znaków, logiczne, wyliczeniowe. Nazwy klas, Typy strukturalne powstają z typów bazowych za pomocą tzw. konstruktorów typów (tzw. typy kolekcji): Zbiór Jeżeli T jest nazwą jakiegoś typu, to Set<T> oznacza typ, którego wartość są dowolnymi skończonymi zbiorami elementów typu T. W zbiorze każdy element występuje tylko raz.
Typy w języku ODL Wielozbiór - Jeżeli T jest nazwą jakiegoś typu, to Bag<T> oznacza typ, którego wartości są dowolnymi skończonymi zbiorami z powtórzeniami. W wielozbiorze element może występować wielokrotnie. Lista - Jeżeli T jest nazwą jakiegoś typu, to L1st<T> oznacza typ, którego wartości są dowolnymi skończonymi listami zero lub więcej elementów typu T. Szczególny przypadek stanowi typ strlng, który jest skrótowym zapisem typu List<char>. W liście ważny jest porządek elementów np. {3,5,3} i {3,3,5} to takie same wielozbiory, ale różne listy. Tablica - Jeśli T jest nazwą typu oraz i jest nazwą typu integer, to Array<T, i> oznacza typ, którego elementami są tablice i elementów typu T.
Typy w języku ODL Słownik - jeśli T i S są typami, to Dictionary<T,S> oznacza typ, którego wartościami są skończone zbiory par. Każda para składa się z wartości klucza typu T oraz wartości zakresu typu S. W słowniku nie mogą wystąpić dwie pary z taką samą wartością klucza. Z założenia metoda implementacji słownika jest efektywna w sensie wyszukiwania wartości z zakresu typu S na podstawie określonej wartości t klucza typu T. Struktura (analogicznie jak w języku C i C++) posiada pola, które mogą być również złożonego typu.
Związki Związki pozwalają określić powiązania z innymi obiektami tej klasy lub innej klasy. Class Film{ }; attribute string tytul; attribute integer rok_prod; attribute integer czas_trwania; attribute enum dźwięk{mono, stereo, DD, SDDS} standarddzwieku; relationship Set<Aktor> aktorzy; W każdym obiekcie typu Film istnieje zbiór referencji do obiektów klasy Aktor.
Związki odwrotne Bardzo często istnieje potrzeba wyrażenia tego, że istnieje związek odwrotny do zadeklarowanego związku (np. w danym filmie występują różni aktorzy, ale każdy aktor może występować w różnych filmach). Jeżeli związek R w klasie C wiąże obiekt x klasy C ze zbiorem jednego lub więcej obiektów y 1, y 2,,y n klasy D, to związek odwrotny do R wiąże z każdym z obiektów y i obiekt x.
Związki odwrotne Class Film{ }; attribute string tytul; attribute integer rok_prod; attribute integer czas_trwania; attribute enum dźwięk{mono, stereo, DD, SDDS} standarddzwieku; relationship Set<Aktor> obsada Class Aktor{ inverse Aktor::zagrałW; attribute string nazwisko; attribute Struct Adr{miasto, ulica, nr_domu} adres; relationship Set<Film> zagrałw inverse Film::obsada;
Krotność związków Analogicznie jak w przypadku związków E/R para związków odwrotnych może być wiele do wiele, wiele do jeden, jeden do wiele i jeden do jeden. m:n między klasami C i D typem związku w klasie C jest Set<D>, a w klasie D typem związku jest Set<C>; n:1 z klasy C do D typem związku w C jest D, a w klasie D typem związku jest Set<C>; 1:n (odwrotnie niż w punkcie poprzednim); 1:1 typem związku w C jest D, a w D jest C.
Związki wieloargumentowe ODL wspiera tylko związki binarne. Związki wieloargumentowe należy zamienić na wiele związków binarnych.
Metody Metody stanowią fragment kodu wykonywalnego na obiektach danej klasy. W ODL można zadeklarować nazwy metod związanych z daną klasą oraz typy wejść/wyjść (sygnatury). Kod funkcji nie jest elementem języka ODL. Kod metody zapisywany jest w języku podstawowym. Deklaracja metod występuje w deklaracji klasy razem z atrybutami i związkami. Tak jak w językach programowania metoda jest związana z daną klasą i działa na obiektach tej klasy
Metody - syntaktyka Syntaktyka deklaracji jest zbliżona do języka C. Dodatkowo rozszerzona została o dwa elementy: Parametry metod określane są dyrektywami in, out oraz inout. Wartości parametrów out i inout mogą być zmieniane i dlatego są przekazywane przez referencję, natomiast parametr in jest niezmienny i jest przekazywany przez wartość. Ponadto (tak jak w C) metoda może zwrócić wartość. W metodzie mogą pojawiać się tzw. wyjątki odpowiedzi na zdarzenia nietypowe, nie mieszczące się w standardowym mechanizmie komunikacji przez zwracane parametry. W ODL wyjątki oznaczane są słowem kluczowym raises.
Metody class Film{ } attribute string tytul; relationship Set<Aktor> obsada inverse Aktor::zagrałW; float DługośćWGodzinach() reises(brakdługości) void PokażObsadę(out Set<string>); void DorobekGwiazdy(in Aktor, out Set<Film>) raises (braktakiegoaktora)
Dziedziczenie - podklasy W standardzie ODL dziedziczenie oznaczane jest słowem kluczowym extends. Class Animowany extends Film{ } attribute enum AnimTyp{2D, 3D, poklatkowa} typanimacji; relationship Set<Aktor> dubbing inverse Aktor::udzieliłGłosu; Każdy obiekt klasy Animowany posiada własności klasy Film oraz dodatkowo własne właściwości (atrybut i związek).
Dziedziczenie wielokrotne Mimo, że w rzeczywistości mogą istnieć obiekty, które posiadają cechy kilku klas, nie można w technice obiektowej tworzyć obiektów, które przynależą do kilku klas. Należy zdefiniować inną klasę, która będzie dziedziczyć po kilku klasach. Class KomediaAnimowana extends Komedia: Anmimowany; W przypadku dziedziczenia mnogiego istnieje potencjalny konflikt nazw własności, które w różnych klasach nadrzędnych mogą nazywać się tak samo. Potrzebny jest mechanizm, który wskaże o jaką własność klasy bazowej chodzi.
Dziedziczenie mnogie - konflikty Można unikać (bądź nieudostępnić) mechanizmu dziedziczenia po wielu klasach. Opracowanie mechanizmu, który pozwoli wskazać, z której klasy bazowej własność o podanej nazwie ma być dziedziczona. Można tą własność w nowej klasie przejąć pod inną, unikatową nazwą.
Ekstensje Należy odróżnić definicję klasy od jej obiektów. Sytuacja analogiczna do odróżnienia schematu relacji od jej instancji. W standardzie ODL rozróżnienie to jest jawne klasie i obiektom nadaje się różne nazwy. Nazwa klasy określa schemat klasy, a ekstensja identyfikuje zbiór obiektów danej klasy. Class Film (extent Filmy){ attribute string tytul; };
Deklaracja kluczy w ODL W technice obiektowej jednoznaczna identyfikacja obiektu odbywa się na podstawie jego identyfikatora, dlatego definiowanie kluczy w tym modelu jest opcjonalne (niedopuszczalne w modelu E/R i relacyjnym). Można zadeklarować jeden bądź kilka kluczy używając słowa kluczowego key bądź keys. Class Student (extent Studenci keys (nazwisko, data_ur), nr_indeksu){ };
Przejście do modelu relacyjnego ODL może być stosowany do stworzenia pierwotnego projektu bazy danych, który przed implementacją jest przekształcany do postaci relacyjnej. Konwersja ta przypomina pod wieloma względami przejście od modelu E/R do schematu relacyjnego. Mimo, że w modelu obiektowym łatwiej i dokładniej można zamodelować rzeczywistość to przekształcenie do modelu relacyjnego łatwiejszego w implementacji, obarczone jest kilkoma problemami, które na etapie tego przejścia trzeba rozwiązać.
Typowe problemy przekształcenia W modelu relacyjnym wymagane jest bezwzględnie określenie kluczy, które w modelu obiektowym są opcjonalne. Często istnieje konieczność definiowania dodatkowych atrybutów, które mogą tworzyć klucze. W modelu relacyjnym atrybuty muszą być atomowe. Przekształcenie atrybutów typu kolekcji do postaci atomowej wymaga wielu sztuczek, które wymagają późniejszej normalizacji. Istnieje poważna trudność konwersji metod do postaci relacyjnej
Przekształcenia atrybutów Przekształcenie atrybutów atomowych jest zagadnieniem trywialnym. W przypadku struktury przekształca się jej pola do postaci atrybutów relacji. Class Student (extent Studenci){ } attribute string nazwisko; attribute Struct Adr{string miasto, string ulica, integer nr_domu}adres; Studenci(nazwisko, miasto, ulica, nr_domu)
Przekształcenia atrybutów Najwięcej trudności sprawia przekształcenie atrybutów typu kolekcji (zbiór, wielozbiór, lista, tablica itp.). Każdy typ posiada specyficzny sposób konwersji. Jedna z metod reprezentowania zbioru wartości atrybutu A polega na utworzeniu dla każdej wartości odpowiadającej jej krotki. Taka krotka zawiera wówczas stosowne wartości wszystkich pozostałych atrybutów klasy. Niestety taka technika zastępowania obiektów atrybutami o wartościach zbiorowych przez kolekcje krotek, po jednej dla każdej kombinacji wartości tych atrybutów może prowadzić do postaci nieznormalizowanych.
Przekształcanie atrybutów Class Aktor(extent Aktorzy){ }; attribute string nazwisko; attribute Set<Struct Adr{string miasto, string ulica}> adres; nazwisko miasto ulica Carrie Fischer Hollywood 123 Mapie St. Carrie Fischer Malibu 5 Locust Ln. Mark Hamill Brentwood 456 Oak Rd. Harrison Ford Beverly Hills 789 Palm Dr.
Przekształcenie wielozbiorów W przypadku wielozbiorów metoda przekształcenia dla zbiorów komplikuje się, ponieważ w bazie krotki nie mogą się powtarzać. Rozwiązaniem tego problemu jest wprowadzenie dodatkowego atrybutu np. licznika, który będzie przechowywał informację o ilości identycznych krotek.
Model obiektowo-relacyjny Model obiektowy nie znalazł szerszego wykorzystania w praktycznej implementacji systemów baz danych. Nie nastąpił rozwój obiektowych systemów baz danych kosztem relacyjnych baz danych. Jednak od lat 90 obserwuje się tendencję wykorzystywania niektórych zalet podejścia obiektowego w relacyjnych systemach baz danych. To spowodowało wyodrębnienie się grupy obiektowo-relacyjncyh baz danych.
Rozszerzenie modelu relacyjnego Atrybuty nie muszą być atomowe. Dużą uwagę skupia się na zbiorach struktur, które same w sobie tworzą relację. Składową krotki może być cała relacja. Wykorzystanie metod. Można zdefiniować i stosować specjalne operacje dla typów zdefiniowanych przez użytkownika. Identyfikatory krotek. Krotki odgrywają rolę obiektów. Zazwyczaj identyfikator krotki jest ukryty, ale w specyficznych sytuacjach może być widoczny. Referencje - wskaźniki do krotek.
Od ODL do modelu obiektoworelacyjnego Znacznie prostsza jest konwersja z modelu obiektowego do obiektowo-relacyjnego niż do modelu relacyjnego ze względu na wprowadzone rozszerzenia (nieatomowe atrybuty, metody, referencje itp.). Reprezentacja związków w modelu obiektoworelacyjnym jest taka sama jak w modelu relacyjnym. Problem tłumaczenia modelu z metodami do czystego modelu relacyjnego w przypadku modelu obiektowo-relacyjnego praktycznie nie