Seminarium (Łukasz Rolbiecki)

Bazy danych

06.04.05

Relacyjne bazy danych (RDBMS)

Technologia relacyjnych baz danych zostala opracowana przez E. F. Codda i zaimplementowana pozniej m.in. przez IBM. Ostatecznie standard RDBMS zostal opracowany przez ANSI X3H2. Zwykle produkt kwalifikuje sie przy pomocy wersji specyfikacji jezyka SQL (ostatni to SQL2). Z czasem relacyjne bazy danych oddalaly sie od swej teoretycznej podstawy - algebry relacji.

Model danych

Dane przechowywane sa w tabelach, z ktorych kazda ma stala ilosc kolumn i dowolna ilosc wierszy. Wiersze odpowiadaja niepodzielnym krotkom (tuple), a kolumny odpowiednim atrybutom (attribute). Kolumny zawieraja dane okreslonego typu, po jednej wartosci w wierszu. Typy sa zdefiniowane na etapie projektowania bazy danych i jest ich okreslona ilosc, maja staly rozmiar i zwykle sa to ogolnie znane typy proste (liczba, data, godzina, ciag znakow, znak, itp.). Kazda tabela (relacja) ma zdefiniowany klucz (key) - wyrozniony atrybut lub kilka atrybutow, ktorego wartosc jednoznacznie identyfikuje dany wiersz.

Jezyk zapytan

Widok (view) jest to pewien podzbior bazy danych podawany w formie tabeli, bedacy wynikiem wykonania zapytania. Dane z bazy sa wybierane na podstawie wartosci w konkretnych pol w krotkach. Zapytania moga miec prosta postac i wymagac danych z wylacznie jednej tabeli, jak rowniez moga byc bardzo wyrafinowane wymagajac od systemu operowania laczeniem (join), zagniezdzaniem (nesting), roznica i suma teorii zbiorow (set union/difference) oraz innymi operacjami.

Model obliczeniowy

Wszelkie przetwarzanie oparte jest na wartosciach pol w krotkach. Krotki nie posiadaja uniwersalnego identyfikatora (niezmiennego w czasie). Nie ma tez zabezpieczenia przed odnoszeniem sie do innego wiersza tej samej tabeli. Przegladanie wynikow zapytan odbywa sie przy pomocy "kursora" umozliwiajacego przegladanie wiersz po wierszu. Podobnie ma sie sprawa uaktualniania danych. Manipulacja relacjami odbywa sie w sposob globalny przy uzyciu operatorow algebry relacji (lub temu podobnych jezykow) - przetwarzanie wiersz po wierszu nie jest dozwolone.

Liczace sie na rynku RDBMS

Oracle (wersje 7.x), System 10/11 [Sybase], Dynamic Server [Informix], DB/2 [IBM], OpenIngres [Computer Associates]

Obiektowe bazy danych (ODBMS)

Obiektowe bazy nie sa okreslone zadnym oficjalnym standardem. Obowiazujacy obecnie standard (opracowany przez ODMG - dzis już rozwiazana) zostal opublikowany w 2001 roku. Jednym z podstawowych celow modelu obiektowego jest bezposrednie odwzorowanie obiektow i powiazan miedzy nimi wchodzacych w sklad aplikacji na zbior obiektow i powiazan w bazie danych. Dzieki mechanizmom obiektowym mozna tez zwiekszyc niezaleznosc danych od aplikacji poprzez przeniesienie procedur obslugi danych (w postaci metod) do systemu zarzadzania baza.

Model danych

Model danych stosowany w obiektowych bazach danych korzysta z pojec takich jak klasy, atrybuty, metody, udostepnia identyfikatory obiektow (OID), hermetyzacje danych oraz metod, wielokrotne dziedziczenie, etc.

Obiektowe bazy danych lacza wlasnosci obiektowosci i obiektowych jezykow programowania z mozliwosciami systemow bazodanowych, a wiec nie tylko przechowywanie danych czy obiektow. Rozszerzaja mozliwosci obiektowych jezykow programowania (takich jak C++, Java czy Smalltalk) czyniac z nich narzedzia do latwego i efektywnego tworzenia systemow baz danych zmniejszajac stopien zlozonosci i ilosc kodu programow dzieki zgodnosci koncepcyjnej na kazdym etapie powstawania produktu.

Jezyk zapytan

Obiektowo zorientowany jezyk staje sie zarowno jezykiem programowania jak i jezykiem bazy danych, zapewniajac bezposrednia zaleznosc miedzy obiektem w aplikacji a obiektem w bazie. Z takiej bezposredniej zaleznosci korzystaja jezyki definicji danych, przetwarzania danych oraz zapytan. OBDMS zostaly do tej pory zintegrowane z jezykami C++, C, Smalltalk, Java i LISP.

Standard ODMG-93 dostarcza dodatkowo deklaratywny jezyki OQL. Jezyk ten nie jest w pelni kompatybilny z SQL. SQL2 pomija zupelnie pojecie typu w znaczeniu postrzeganym przez model obiektowy. Wynik zapytania w jezyku OQL moze natomiast byc struktura, literalem, obiektem lub zbiorem obiektow. Wiekszosc baz obiektowych jest jednak wyposazona w SQL w celu zapewnienia zgodnosci ze standardem ODBC (Object Database Connectivity).

Model obliczeniowy

Mimo, ze podobnie jak w RDBMS, wciaz mozliwe sa zapytania deklaratywne, glownym sposobem tworzenia i modyfikacji obiektow jest korzystanie bezposrednio z odpowiedniego dla bazy obiektowego jezyka programowania. Ponadto tworzone obiekty otrzymuja unikalne identyfikatory niezmienne w czasie, ktore moga byc wykorzystywane przez inne obiekty w celu definiowania powiazan z tymi obiektami. Zwykle identyfikatory sa konwertowane na wskaznik do pamieci w chwili wczytywania konkretnego obiektu - uzyskujemy dzieki temu skrocenie dostepu do obiektu gdy jest on obecny np. w pamieci podrecznej.

Liczace sie na rynku ODBMS

Jasmine [Computer Associates], Gemstone, O2, Object Store [Object Design], Objectivity/DB [Objectivity], Versant ODMBS [Versant]

Obiektowo-relacyjne bazy danych (ORDBMS)

Stanowia bardzo silna grupe systemow, ktora w ostatnim czasie dobrze zaznaczyla sie na rynku oprogramowania. Nazywane sa Object Relational lub Extended Relational. Sa wynikiem ostroznej ewolucji systemow relacyjnych w kierunku obiektowych. Kierunek rozwoju jest wyznaczany przez dwie tendencje:

• dazenie do zniwelowania niedostatkow technologii relacyjnej, szczegolnie w zakresie danych multimedialnych, dolaczania metod lub regul "zachowania sie" danych, modelowania pojeciowego,

• chec wprowadzenia wielu cech obiektowosci, takich jak klasy, metody, dziedziczenie, abstrakcyjne typy danych (ADT) - wlasnosci potwierdzajace choc czesciowa obiektowosc systemu relacyjnego.

Model danych

ORDBMS korzysta z modelu danych zawartego w standardzie SQL3, ktory mowi, ze "obiektowo-relacyjny model danych probuje dodac obiektowosci do tablic". Dane sa wciaz przechowywane w tabelach, jednak wartosci moga miec nieco bogatsza niz dotychczas postac - ADT (Abstract Data Type). Pola typu ADT zachowuja funkcjonalnosc zwyklych pol (moga byc uzywane do indeksowania, wyszukiwania, pobierania lub umieszczania danych) przy nowych zawartosciach (jak np. multimedia).

Jezyk zapytan

Poniewaz ten model rozszerza model relacyjny, dlatego opracowywany obecnie SQL3 (nazywany tez ObjectSQL) jest rozszerzeniem SQL. Rozszerzenie dotyczy rozbudowy mozliwosci zapytan o obiekty zagniezdzone, ADT, atrybuty o wartosci wyliczanej (np. metody obiektu), itp. Wyniki sa jednak wciaz podawane w formie tabel krotek, a nie jako kolekcje obiektow.

Model obliczeniowy

Rozszerzony jezyk SQL jest podstawowym interfejsem dostepu do danych. Bezposrednie odwzorowanie miedzy obiektami z jezyka programowania a obiektami / tabelami w bazie nie istnieje, tlumaczenie wciaz obciaza programiste.

Liczace sie na rynku ORDBMS

Oracle (wersje 8.x), Illustra (Universal Server) [Informix], DB/2 Extenders (Universal Database) [IBM], UniSQL/X [UniSQL], OSMOS [Unisys]

Migracja

--- typy wędrują do klas, nie są więc z góry zadane, ale można je „definiować” ---

Na powyzszym schemacie widac najistotniejsze zmiany architektury dokonane przy przejsciu z modelu relacyjnego na obiektowy. Nalezy tu szczegolnie zwrocic uwage, ze czesc informacji tkwiacej w bibliotekach, typach, aplikacjach i modulach zostala usystematyzowana i umieszczona bezposrednio w klasach.

Obiektowe bazy danych

W miare rozpowszechnienia technologii obiektowej oraz wraz z rosnaca krytyka modelu relacyjnego powstala nowa generacja baz danych znanych jako obiektowe bazy danych (ODB). ODB przechowuja obiekty - zakapsulkowane kombinacje danych o dowolnej strukturze razem ze skojarzonymi procedurami (metodami).

Obiektowe bazy danych powstaly poczatkowo jako rozwiniecie programowania zorientowanego obiektowo. Programisci Smalltalk i C++ potrzebowali magazynowac tzw. trwale dane, czyli dane, ktore pozostaja po zakonczeniu tworzacego je procesu. Pozniej zastanawiano sie nad odpowiednim zarzadzaniem zgromadzonymi danymi, wiec dolaczono cechy charakterystyczne dla baz danych. ODB dziedzicza wiec wszystkie zasadnicze cechy technologii obiektowej (istnienie zlozonych obiektow, tozsamosc obiektow, enkapsulacja danych i procedur, dziedziczenie, funkcje polimorficzne, rozszerzalnosc o nowe typy danych) i baz danych (trwalosc danych, oddzielenie logicznego i fizycznego poziomu danych, zarzadzanie wielodostepem, odtwarzanie spojnego stanu danych po awariach, zapytania ad hoc, zarzadzanie transakcjami i in.).

OBD maja przewage w stosunku do tradycyjnych baz danych przy przechowywaniu danych zorientowanych obiektowo, aktywnych, o dowolnej strukturze zlozonej czy zagniezdzonej, hierarchicznie uporzadkowanej czy zwiazanej siecia roznorodnych polaczen.

Najistotniejszym problemem dla OBD jest kwestia zapytan. Wiekszosc wspolczesnych obiektowych baz danych pozwala jedynie na proste przeszukiwanie przechowywanych obiektow. Takie udogodnienia jak zapytania zagniezdzone, kombinacje zapytan (suma, przeciecie, roznica), grupowanie, funkcja agregacji itd., czyli to, co relacyjne bazy danych w pelni dostarczaja, w przypadku obiektowych baz danych sa na razie nieosiagalne i znajduja sie w stadium rozwojowych prac badawczych. Rowniez kwestia optymalizacji zapytan w przypadku obiektowych baz danych jest znacznie bardziej skomplikowana.

Podstawowe pojecia

Obiekt
    Obiekt jest podstawowym pojęciem dla obiektowości. Obiekt reprezentuje sobą konkretny pojedynczy byt (książkę, osobę, samochód), charakteryzowany poprzez opis stanu (atrybuty obiektu) i zachowania tego bytu (metody obiektu). Opis ten jest realizowany przy użyciu klasy.

Atrybuty
    Atrybuty stanowią opis statycznej struktury klasy i obiektów, opis ich poszczególnych cech. Wyróżnia się:
    a) atrybuty klasy czyli tzw. atrybuty dzielone (shared attributes) np.: zestaw nadklas danej klasy oraz atrybuty wspólne dla wszystkich obiektów (czyli występujące jednorazowo dla wszystkich obiektów klasy a nie dla każdego obiektu osobno),
    b) atrybuty obiektów klasy czyli zbiór atrybutów występujących każdorazowo wraz z występowaniem obiektu; atrybuty te mogą być proste (należące do prostych typów danych) lub złożone.

Metody
    Metody stanowią opis dynamicznych zachowań obiektów, czyli operacje widocznych na zewnątrz obiektu a pozwalające dokonywać manipulacji na danych; metoda aktywowana jest przez komunikat adresowany do tzw. obiektu docelowego (target object) i w standardowym przypadku operuje wyłącznie na danych wchodzących w skład tego obiektu.

Enkapsulacja
    Koncepcja enkapsulacji (hermetyzacji) wywodzi się potrzeby rozdzielenia deklaracji i implementacji operacji oraz z potrzeby strukturyzacji programu poprzez jego podział na funkcjonalnie niezależne moduły.
Samo pojęcie wywodzi się z obiektowych języków programowania i odwołuje się do pojęcia abstrakcyjnych typów danych. W tym podejściu rozróżniamy: deklarację danej struktury i jej definicję. W części deklaracyjnej wyszczególnia się zestaw operacji jakie mogą być wykonywane na danym obiekcie - dla użytkownika jest to jedyna widoczna część obiektu. Część definicyjna składa się z definicji danych, czyli atrybutów i definicji procedur - metod.
Pojęcie enkapsulacji dla baz danych ma podobne znaczenie.

Tożsamość obiektu
    Tożsamość (object identity) jest stałą cechą obiektu. Jest to taka własność obiektu, która pozwala odróżnić go od każdego innego obiektu, który  istnieje w systemie lub który może się w nim pojawić.

Metody konstrukcji identyfikatorów obiektów
    Identyfikatory obiektów mogą być fizyczne albo logiczne. Identyfikatory fizyczne zawierają aktualny adres obiektu, identyfikatory logiczne są jedynie indeksem, dzięki któremu może być uzyskany właściwy adres fizyczny.
    Można rozróżnić co najmniej cztery typy identyfikatorów:
    - adres fizyczny - identyfikator jest adresem fizycznym obiektu, ta reprezentacja jest zwykle używana przez języki programowania, dla obiektowych baz danych jest nieużyteczna ze względu np. na przesuwanie obiektu
    - adres strukturalny - identyfikator składa się z dwóch części - pierwsza określa numer segmentu i numer strony, na której znajduje się obiekt, druga część zawiera logiczny numer szczeliny - pozycji, która określa położenie obiektu na stronie.
    - surogat - identyfikator jest generowany przy użyciu algorytmu, który gwarantuje jego unikalność; takie identyfikatory przekształcane są na adres fizyczny obiektu
    - surogat odwołujący się do typu - wariant poprzedniej metody, w którym korzysta się z identyfikatora typu (klasy) jak i części identyfikującej obiekt

Dziedziczenie
    Mechanizm dziedziczenia pozwala na tworzenie nowych klas, zwanych podklasami, z klas już istniejących. Nowe klasy przejmują (dziedziczą) struktury danych i metody klas, ponadto dołączane są do nich nowe własne struktury i procedury.
Dziedziczenie może mieć charakter bezpośredni (oznacza to, że struktura danych i metody są przenoszone do podklasy bez zmian) lub dokonywana jest transformacja składników klasy przed przekazaniem ich do podklasy.

Standard

Ogolne trendy we wspolczesnym przemysle komputerowym wskazuja na dalszy nieuchronny wzrost popularnosci obiektowych baz danych. Tradycyjne systemy baz danych uksztaltowaly sie w srodowisku hardware'owym zakladajacym istnienie jednego poteznego komputera (mainframe) przechowujacego i zarzadzajacego danymi oraz wielu zdalnie polaczonych prymitywnych terminali. W ciagu ostatnich lat sytuacja jednak zmienila sie. Gwaltowny rozwoj sieci spowodowal decentralizacje magazynowania danych. Dodatkowo komputery osobiste, najczesciej pelniace role terminali, dysponuja dzis znaczna moca obliczeniowa, ktora w ten sposob jest rozproszona w calej sieci. W konsekwencji coraz wieksza popularnosc zyskuja systemy rozproszone, w ktorych szczegolna role pelni tzw. technologia obiektow rozproszonych. Obiekty w tym systemie, bedac autonomicznymi "kawalkami" kodu, tworza otwarte srodowisko, w ktorym aplikacja moze korzystac z uslug wielu specyficznych obiektow zaimplementowanych za pomoca roznych jezykow programowania oraz dzialajacych na roznych platformach hardware'owych. Najbardziej rozpowszechnionym standardem okreslajacym zasady wspoldzialania rozproszonych obiektow jest specyfikacja CORBA (Common Object Request Broker Architecture), zdefiniowana przez gremium OMG (Object Management Group) zajmujace sie normowaniem software'u obiektowego. W 1993 roku inny komitet ODMG (Object Database Management Group) nalezacy do gremium OMG oraz skupiajacy wiodacych producentow OBD zdefiniowal ujednolicony standard dla obiektowych baz danych ODMG-93. Glownym celem takiego standardu bylo zapewnienie przenoszalnosci danych pomiedzy roznymi systemami OBD oraz mozliwosci "przepytywania" jednego systemu przez drugi. Standard ODMG sklada sie z modelu obiektowego, jezyka zapytan OQL (Object Query Language) oraz zbioru dowiazan jezykow programowania. Nalezy podkreslic, iz standard ODMG-93 jest zaprojektowany z mysla o integracji OBD ze standardem CORBA, co jest szczegolnie wazne dla systemow obiektow rozproszonych. Dzis prawie kazdy komercyjny system OBD oferuje mechanizmy wspolpracy bazy danych ze srodowiskiem CORBA. Podsumowujac mozna powiedziec, ze przejscie od architektury klient-serwer w kierunku technologii obiektow rozproszonych stwarza dobre perspektywy rozwoju dla OBD.

Co nowego wprowadzaja OBD?

W odroznieniu od relacyjnych baz danych, OBD przechowuja informacje w postaci obiektow - zakapsulkowanych kombinacji danych razem ze skojarzonymi z nimi procedurami (metodami) ich dotyczacymi. Przede wszystkim OBD pozwalaja w ten sposob na przechowywanie danych o dowolnej strukturze zdefiniowanej przez projektanta bazy (definiowanie klas obiektow), ktory jest zwolniony z obowiazku "splaszczania" danych do postaci dwuwymiarowej tablicy (relacji), majac do dyspozycji jedynie wbudowane proste typy danych (np. integer, string, date). Dodatkowo w relacyjnych bazach danych caly dostep do danych jest realizowany poprzez ich wartosc - w konsekwencji w obrebie jednej relacji nie moga wystepowac krotki majace we wszystkich polach identyczne wartosci. W przypadku OBD wszystkie obiekty - nosniki informacji - posiadaja swoj unikalny identyfikator (object identifier - OID) niezalezny od wartosci ich atrybutow. Poprzez ten wewnetrznie generowany identyfikator jest jednoznacznie okreslony dostep do obiektu. System moze wiec rozroznic, czy dwa opisywane obiekty przedstawiaja ten sam obiekt (operacja sprawdzania identycznosci), czy tez dwa rozne obiekty, wszystkie atrybuty ktorych maja rowne wartosci. Cecha ta jest szczegolnie wazna, gdyz pozwala systemowi na przechowywanie i udostepnianie tzw. danych zagniezdzonych (danych skladajacych sie z podczesci i tworzacych np. zlozona strukture drzewiasta) w sposob znacznie bardziej efektywny niz w przypadku dokonywania kosztownych operacji scalania tablic w RBD. Obiekty zagniezdzone sa laczone bezposrednio poprzez identyfikatory, co w porownaniu z modelem relacyjnym zmniejsza czas dostepu do danych az 10 (a w niektorych przypadkach - nawet 100!) krotnie. Posiadanie przez kazdy obiekt swojego identyfikatora, czyli wystepowanie tozsamosci obiektow umozliwia rowniez modelowanie roznorodnych powiazan miedzy danymi, traktujac skojarzone z danym obiektem zewnetrzne obiekty jako czesc jego wewnetrznej struktury. Powiazania te moga miec charakter relacji jednoznacznych (one-to-one), jeden do wielu (one-to-many) lub wzajemnie wieloznacznych (many-to-many). Wszystko to sprawia, ze obiektowe bazy danych sa znacznie lepiej przystosowane do przechowywania nowych typow danych, takich jak dane multimedialne, dane przestrzenne, strony HTML i in. Z tego powodu OBD z powodzeniem dotychczas stosowano przede wszystkim przy aplikacjach pracujacych z danymi zlozonymi (CAD/CAE - Computer Aided Design - Projektowanie wspomagane komputerem, GIS - Geographic Information System - System informacji geograficznej). OBD stanowia ponadto naturalne srodowisko dla tworzenia wielu wersji danych (obiektow rozroznialnych za pomoca OID) oraz konstrukcji tzw. aktywnych baz danych, czyli baz danych pozwalajacych na uruchamianie w obrebie systemu pewnych procedur w odpowiedzi na okreslone wydarzenia zachodzace w systemie.

Impedancja

Jedna z glownych zalet OBD jest zniesienie niedopasowania modelu bazy danych do modelu uzywanego przez programiste aplikacji (impedance mismatch) - bowiem OBD wykorzystuja obiektowy model danych, ktory jest zgodny z wieloma obiektowymi jezykami programowania ogolnego przeznaczenia (np. C++, Smalltalk). Dane, jak to jest w przypadku baz relacyjnych, nie musza byc "konwertowane" z formatu modelu fizycznego na reprezentacje uzywana w jezyku programowania, co jest bardzo "kosztownym" i mocno narazonym na bledy procesem. W przypadku OBD znika praktycznie scisla granica dzielaca programy aplikacji i elementy definicji bazy danych: niektore egzemplarze obiektow danego typu moga byc tymczasowe, inne stale, ale niezaleznie od tego moga byc w identyczny sposob traktowane w instrukcjach i wyrazeniach jezyka programowania.

Inna istotna zaleta OBD jest ujednolicony model pojeciowy, na ktorym operuja analityk, projektant i programista. Polepsza to w sposob zasadniczy ich wspoldzialanie oraz redukuje ryzyko powstawania bledow przy przejsciach pomiedzy roznymi fazami powstawania aplikacji. W tradycyjnych systemach baz danych programista musi wymyslic, jak wydobyc dane z tabel oraz jak je w nich umiescic. Natomiast w OBD programista ma do czynienia z obiektami chwilowymi i trwalymi w ujednolicony sposob - nie ma zadnych roznic pojeciowych pomiedzy programowaniem a baza danych. Analiza obiektowa odwzorowuje bezposrednio dziedzine zastosowania i zakres czynnosci systemu na model - definiowane sa obiekty wysokiego poziomu oraz ich zachowanie. Z kolei projektant "przerabia" je na obiekty niskiego poziomu, ktore dziedzicza wlasnosci i zachowania obiektow wyzszego poziomu (nie ma mozolnego "przejscia do projektowania"). Majac do dyspozycji wyspecyfikowane przez projektanta obiekty programista z latwoscia moze zaimplementowac pozadana funkcjonalnosc za pomoca obiektowego jezyka programowania oraz narzedzi OO-CASE (Object-Oriented Computer Aided Software Engineering).

Przejście do z modelu relacyjnego na obiektowy

Oczywiscie, mimo opisanych zalet OBD, dla wiekszosci uzytkownikow, ktorzy zainwestowali juz duze srodki finansowe w zainstalowany i dzialajacy software oraz w pracownikow obslugujacych systemy RBD, szybkie zaadoptowanie nowej technologii baz danych jest niemozliwe.

Aby zapewnic bardziej lagodne przejscie od technologii relacyjnej do technologii obiektowej w ostatnich latach a takze aby moc wykorzystac wszystkie zalety modelu relacyjnego powstalo wiele tzw. obiektowo-relacyjnych (lub hybrydowych) baz danych (np. POSTGRES, OpenOBD, Illustra), ktore w wiekszym lub mniejszym stopniu wykorzystuja elementy modelu relacyjnego. Glowna zasada dzialania takich systemow jest budowanie nad systemem zarzadzania relacyjna baza danych warstwy programowej pozwalajacej przetwarzac obiekty logiczne na skladniki podstawowe modelu relacyjnego, czyli umozliwiajace przechowywanie obiektow w tablicach relacyjnej bazy danych. Duza popularnosc zyskaly rowniez narzedzia middleware sluzace do pogodzenia modelu obiektowego z relacyjnym (np. Persistence, DBtools.h++). Za ich pomoca dokonuje sie konwersji obiektow na postac odpowiednia do przechowywania ich w istniejacych RBD. Podejscia te pozwalaja na korzystanie z dobrodziejstw jakie niesie technologia obiektowa przy zachowaniu podrzednego relacyjnego modelu bazy danych.

Oracle od Oracle8 - obiektowo-relacyjny serwer Oracle8, rozszerzony o mozliwosci obslugi dodatkowych typow danych takich jak wideo, audio, tekst oraz dane przestrzenne. Oracle8 zostal zintegrowany z najnowsza koncepcja Oracle'a - architektura przetwarzania sieciowego (Network Computing Architecture), ktora dostarcza srodowisko dla tworzenia, przechowywania i zarzadzania "komponentami" (autonomicznymi fragmentami kodu), ktore moga byc wykorzystywane przy tworzeniu aplikacji sieciowych dzialajacych w srodowisku heterogenicznym.

Informix od dluzszego czasu inwestuje w system Illustra, bedacy jednym z najbardziej zaawansowanych obiektowo-relacyjnych baz danych, dostepnych na rynku. Informix zapowiedzial wprowadzenie na rynek tzw. Universal Server, skupiajacego zaawansowane cechy obu tych narzedzi (relacyjnej i obiektowo-relacyjnej bazy danych).

Sybase natomiast wybral inna droge pogodzenia modeli relacyjnego i obiektowego. Wspolpracujac z Persistence Software Inc. Sybase postanowil utworzyc specjalny pomost (gateway) pomiedzy relacyjna baza danych a obiektowa aplikacja uzytkowa, ktory "w locie" wykonuje konwersje obiektow na relacje przechowywane w bazie danych. Pozwala to na szybsze wprowadzenie na rynek produktu obslugujacego obiekty, poniewaz podrzedny relacyjny system Sybase'a jest pozostawiany bez zmian. Na dluzsza mete jednak podejscie to nie jest konkurencyjne wskutek niedopuszczalnie duzych kosztow czasowych przejscia danych poprzez posrednie warstwy przetwarzania podczas translacji obiektowo-relacyjnej.

Podsumowanie

Podsumowujac, mozna powiedziec, ze OBD juz teraz sprawuja sie najlepiej w zastosowaniach, gdzie relacyjny model tradycyjne napotyka na trudnosci. Przede wszystkim sa to systemy, przechowujace dane o naturze zagniezdzonej. Jest wiec wielce prawdopodobne, ze w miare wzrostu potrzeby przechowywania danych multimedialnych, rozwoju Internetu i WWW OBD beda szybko zyskiwac na popularnosci dzieki ich naturalnemu dopasowaniu do takich zastosowan.

Metodyki obiektowe projektowania

    Najbardziej znane to:
    Metodyka Raumbaugh/OMT (Object Modelling TechniQue) - opisuje klasy i ich związki w trakcie procesu tworzenia projektowanego systemu. Proces tworzenia systemu został podzielony na siedem faz: strategii, analizy, projektu systemu, projektu obiektów, implementacji, testowania, pielęgnacji.
    W trakcie tych faz modeluje się system z trzech punktów widzenia używając do tego trzech różnych powiązanych ze sobą modeli:
    - Model Obiektów - opisuje statyczną stronę systemu pokazując strukturę obiektów w systemie wraz z informacjami o ich atrybutach, metodach i wzajemnych powiązaniach;
    - Model Dynamiczny - opisuje zmieniające się w czasie zachowanie projektowanego systemu, podstawowe pojęcia z nim związane to zdarzenie oraz stan, rozumiany jako kolekcja powiązań obiektu z innymi obiektami; model umożliwia opis zdarzeń zachodzących w systemie i dozwolonych sekwencji zdarzeń dla każdego obiektu;
    - Model Funkcjonalny - opisuje działania wykonywane przez system: przepływ danych i współdziałanie obiektów;

Metodyka Boocha skupia się na dostarczeniu narzędzi umożliwiających w miarę proste przedstawienie pojedynczego systemu tak by mógł być łatwo zaimplementowany. Proces rozwoju systemu podzielono na fazy: strategii, analizy, projektu, zmian i pielęgnacji systemu. Metodyka dostarcza różnych, powiązanych ze sobą modeli:
    - Model Logiczny - opisuje klasy i obiekty projektowanego systemu;
    - Model Fizyczny - opisuje oprogramowanie i sprzęt, które ma się składać na projektowany system;
    - Model Statyczny - opisuje statyczne niezmienne w czasie aspekty systemu: klasy, obiekty, moduły, procesy;
    - Model Dynamiczny - opisuje dynamiczne, zmieniające się w czasie cechy systemu: zmiany stanów i scenariusze;

    Metodyka Fusion jest metodyką drugiej generacji dla analizy i projektowania obiektowego. Dostarcza ona nie tylko zestawu notacji dla modelowania systemu na różnych etapach projektu, ale też systematyzuje opis poszczególnych faz projektu od specyfikacji, poprzez analizę i projekt do implementacji projektowanego systemu.

    Metodyka Shlaer/Mellora jest metodyką typu Object-Oriented Analysis, skupia się na analizie projektowanego systemu. Opisuje klasy, ich związki i powiązania między klasami w trakcie życia modelowanego systemu. Wyróżnione zostały trzy poziomy opisu: Poziom Systemu z wyróżnionym Zakresem Prac i Grafikiem Projektu. Poziom Zakresu dostarczający modele opisujące ogólny zakres planowanych podsystemów, Poziom Podsystemów w skład którego wchodzą:.
    - Model Informacyjny - opisuje klasy, ich własności (atrybuty) i związki z innymi klasami
    - Model Stanów - opisuje zachowania klas i ich związki w czasie
    - Model Procesów - służy do modelowania przetwarzania dla akcji opisanych przez Model Stanów

    Metodyka Coad/Yourdona jest metodyką typu  Object-Oriented Analysis and Object-Oriented Design method. Zakłada zatem wspomaganie procesu analizy i projektowania systemu. Wyróżnia poziomy: zagadnień, klas i obiektów, struktury, atrybutów usług, oraz komponenty: zakresu problemów, współpracy z człowiekiem, zarządzania zadaniami, zarządzania danymi.

POET

Mechanizmy jakimi zarządza POET

POET dostarcza system tworzenia obiektowych baz danych, który w pełni dostosowany jest do semantyki C++. POET jest zorientowany obiektowo, oznacza to, że jego klasy i obiekty posiadają następujące własności:

• Enkapulsacja

• Dziedziczenie

• Polimorfizm

• Typy danych definiowanych przez użytkownika

• Identyczność (tożsamość)

• Naturalne modelowanie powiązań pomiędzy obiektami

Jako baza danych dostarcza następujących własności:

• Długi czas składowania

• Duża pojemność dla składowania

• Zapytania bazujące na wartościach

• Dzielenie obiektów pomiędzy programami

• Format niezależny od urządzenia (platformy)

Jako obiektowa baza danych dostarcza:

• Zapytania bazujące na wartościach wraz z sortowaniem wyniku

• Indeksy

• Inteligentne zarządzanie obiektami

• Chwilowe składowe

Programowanie zorientowane obiektowo jest odpowiednie dla obszernych oraz złożonych programów, bazy danych natomiast dla dużej ilości danych oraz szybkich zapytań bazujących na wartościach. POET łączy obydwa te wymagania dostarczając narzędzi koniecznych dla złożonych programów, wykorzystujących dostęp do dużej ilości danych.

Cechy POET'a

• POET pracuje na wielu platformach systemowych (Win 16, NT, OS/2, Mac, HP-UX, AIX, SGI Iris, Solaris, SCO, NeXTStep).

• POET dla wszystkich platform generuje taki sam format bazy danych, stąd możliwość wykorzystania obiektów stworzonych na innym komputerze. Wszystkie platformy POET'a posiadają kompatybilny kod źródłowy, dlatego też w celu uruchomienia na innym systemie operacyjnym konieczna jest jedynie rekompilacja kodu.

• Współpracuje z wieloma kompilatorami (Visual C++, Borland C++, Java).

• POET ściśle stosuje semantykę C++. Ułatwia to programistom C++ zrozumienie kodu.

• POET posiada prawdziwą architekturę client/server (m in. zapytania są przetwarzane po stronie serwera).

• POET dobrze współpracuje z narzędziami służącymi do rozwijania aplikacji, włączając narzędzia GUI, frameworks, biblioteki oraz debugery.

• POET współpracuje wraz z innymi aplikacjami, zapewniając mechanizmy integracji.

• POET Developer's Workbench oraz POET Administrator's Workbench dostarcza narzędzi koniecznych do rozwijania oraz administracji rzeczywistej aplikacji.

Tworzenie aplikacji z wykorzystaniem POET'a

W celu przedstawienia podstawowych operacji bazodanowych w POET'cie oraz zaprezentowania modelu programowania posłużymy się prostym przykładem - systemem fakturowania operacji sprzedaży. System posiada następującą strukturę klas:

Przykład: faktury - hierarchia klas

Tworzenie klas trwałych (persistent)

 Każdy obiekt klasy trwałej może być składowany w bazie danych. Klasę trwałą uzyskujemy przez dopisanie słowa kluczowego „persistent” do deklaracji klasy w C++:

 

persistent class Product{

private:

PtString name;

long list_price;

public:

Product();

virtual ~Product();

 

virtual void Show();

virtual void Fill();

};

Tworzenie bazy danych

Deklarację klas trwałych umieszcza się w pliku o rozszerzeniu *.HDC. Prekompilator POET'a, PTXX, wykorzystuje tę deklarację do utworzenia słownika klas dla bazy danych oraz specyficznej klasy administrującej klasy, która umożliwia wykonywanie zapytań oraz zarządzanie zbiorami obiektów trwałych. Każdy obiekt klasy trwałej może być zapisywany w bazie danych. POET tworzy bazę danych w oparciu o deklarację klas trwałych, rejestrując deklaracje klas w słowniku. Prekompilator stosuje się dla deklaracji nowych klas trwałych lub po ich modyfikacji w celu wygenerowania kodu rozpoznawanego przez kompilatory C++. PTXX generuje dołączany plik C++ który umożliwia obsługę klas trwałych przez dowolny kompilator C++.

PTXX - schemat kompilatora

 Kompilator PTXX wykonuje następujące operacje:

• tworzy słownik klas, wykorzystując deklarację klas trwałych jako schematu;

• tworzy deklarację klas w C++ dla klas trwałych, tak aby była ona rozumiana przez kompilatory kodu C++;

• tworzy dodatkowe informacje o klasach tak aby wiedział w jaki sposób odczytywać, zapisywać klasy, wykonywać zapytania na nich;

• tworzy klasy, które pozwalają na dostęp do klas w bazie oraz na realizację zapytań.

Podczas kompilacji plików *.HCD PTXX dodaje każdą napotkaną klasę do słownika, a następnie tworzy trzy pliki: *.HXX, *.CXX, oraz *.PTX. 

Schemat kompilatora PTXX	Schemat kompilacji i rejestracji bazy danych

 Poniższa tabela przedstawia cele wszystkich plików generowanych przez PTXX:        

Nazwa	Format	Cel	Użycie
Słownik klas	Baza danych (opisująca klasy w tworzonej bazie danych)	Schemat bazy danych.	Utrzymywany przez PTXX automatycznie
Klasa factory	plik *.CXX	Opisuje jak budować i zarządzać obiektami.	Kompilowany i dołączany do programu.
Plik nagłówkowy klasy factory	plik *.PTX	klasy Query , klasy AllSet, klasy ondemand, i klasy set dla klas persistent.	Jest automatycznie dołączany do pliku nagłówkowego klasy
Plik nagłówkowy (deklaracja klas)	plik *.HXX	Standardowa reprezentacja C++ deklaracji z pliku .HCD.	Dołączany do źródeł aplikacji.
Definicja obiektów klas	plik *.OCD	Prekompilowana reprezentacja pliku .HCD.	PTXX łączy je razem aby zbudować schemat bazy danych dla słownika klas.

Dla każdego pliku .hcd, POET tworzy plik .hxx, który zawiera deklaracje klas zawartych w pliku .hcd. Do pliku .hxx automatycznie dołączany jest plik .ptx, który jest plikiem nagłówkowym zawierającym klasy zarządzające bazą stowarzyszone z klasą aplikacji. Na końcu tworzony jest plik .cxx, który dostarcza różnorodne funkcje opisujące obiekty dla POET'a. Ten plik zawiera specjalizowane konstruktory oraz klasy dostarczające informacje ze słownika dla każdej klasy. Są to tzw. factory constructor table, stanowią one kod, który umożliwia zarządzanie klasami bez konieczności pisania kodu przez programistę. Plik ten jest kompilowany i dołączany do aplikacji.

Pliki dołączane oraz biblioteki

Poniżej przedstawiono przykład plików dołączanych do wersji C++ PRODUCT.CPP oraz wersji POET'a: 

Oryginalne pliki dołączane	Nowe (z użyciem POET'a)
// PRODUCT.CPP #include <iostream.h>   #include <poetapp.hxx> #include <menuapp.hxx> #include "goodies.hxx" #include "product.hxx"	// PRODUCT.CPP #include <iostream.h> #include <poet.hxx> #include <poetapp.hxx> #include <menuapp.hxx> #include "goodies.hxx" #include "product.hxx" #include "product.cxx"

Jak widać zostały dodane dwa nowe pliki:

• POET.HXX który jest plikiem dołączanym dla biblioteki POET'a, musi być umieszczony przed plikiem PODUCT.HXX ponieważ zawiera on kod specyficzny dla POET'a,

• PRODUCT.CXX, która stanowi class factory table dla klasy Product. POET potrzebuje class factory aby móc zarządzać obiektami trwałymi. Plik ten może być kompilowany i linkowany oddzielnie jak również dołączany do pliku zawierającego implementację klasy.

Otwieranie i zamykanie bazy danych

PtBase jest klasą reprezentującą jedną szczególną bazę danych w programie. Otwarcie bazy powoduje stworzenie obiektu PtBase, który można użyć do przydzielenia obiektów do bazy.

Istnieje możliwość otwarcia kilku obiektów PtBase równocześnie, które pozwalają na zarządzania kilkoma bazami danych w programie. Wersja POET'a client/server umożliwia kilku użytkownikom na dostęp do tej samej bazy danych równocześnie z pełną kontrolą współdziałania.

Przez otwarciem PtBase konieczna jest inicjalizacja POET'a przez wywołanie globalnej funkcji InitPOET(), która tworzy obiekt PtRoot zarządzający obiektami PtBase programu. Następnie możemy tworzyć PtBase i otwierać bazę przez wywołanie funkcji PtRoot::GetBase(”nameoftheserver”,” nameofthedatabase”, PtBase*). GetBase() tworzy PtBase, następnie zleca PtBase połączenie z serwerem i otwarcie bazy. Zamykanie bazy realizowane jest przez UngetBase(), następnie DeinitPOET() kończy pracę z POET'em.

#include <poet.hxx>

main()

{

InitPOET("ClientName");

PtBase* pObjBase;

int err = PtBase::POET()->GetBase("LOCAL", "base", pObjBase);

if (err < 0)

{

PtBase::POET()->UngetBase(pObjBase);

ErrorExit("Could not open database", err);

/ now we have an open PtBase...let's close it

tBase::POET()->UngetBase(pObjBase);

InitPOET();

return 0;

}

 Istnieje możliwość otwarcia PtBase bez wykorzystania PtRoot. Jednak PtRoot zapewnia, że zasoby dla każdej PtBase są alokowane tylko raz. Zaoszczędza to pamięć RAM oraz uchwyty do plików.

Składowanie obiektów

POET wyprowadza każdą klasę trwałą z klasy PtObject, klasy bazowej która dostarcza funkcje związane z bazą danych dla obiektów. W celu składowania obiektów trwałych po otwarciu bazy danych należy przypisać obiekt do tej bazy a następnie wywołać metodę Store(): 

Person *pPerson = new Person;

pPerson->Assign(pObjbase);

err = pPerson->Store();

check(err);

Rozszerzenie syntaktyki deklaracji

POET rozszerza standard deklaracji w C++ o deklaracje bazodanowych właściwości dla klas. PTXX wykorzystuje je do generowania słownika klas a następnie usuwa słowa kluczowe aby deklaracje mogły być czytane przez kompilator C++.

Deklaracja klasy trwałej jest następująca:

persistent class Product

Obiekt może posiadać wskaźnik do obiektu innej klasy. Jest to osiągane bezpośrednio używając deklaracji wskaźnika w C++, np.:

Customer* pCustomer;

Słowo kluczowe `ondemand' stosuje się w celu uzyskania referencji „na żądanie”. Oznacza to, że obiekt jest ładowany w żądanym momencie:

ondemand<Customer> odCustomer;

Obiekt może posiadać zbiór innych obiektów (np. faktura składa się ze zbioru pozycji). Zbiór deklarowany jest za pomocą słowa kluczowego `lset' :

lset<Entry*> Entries;

Zbór może być również ładowany na żądanie:

lset <ondemand<Entry>> Entries;

W przypadku gdy egzystencja obiektu zależy od istnienia innego (np. pozycje faktury istnieją gdy istnieje faktura) deklaruje się go poprzedzając słowem kluczowym `depend'. Poniższa linia w deklaracji klasy Invoice mówi, że Entries jest zbiorem „ondemand” obiektów klasy Entry, który zależy od klasy Invoice:

depend lset <ondemand<Entry>> Entries;

Indeksy pozwalają na definiowanie porządku sortowania obiektów oraz przyspieszają realizację zapytań. Słowo kluczowe `useindex' oznacza użycie indeksów:

useindex DateIX;

Dla składowych klas, które nie mają być składowane stosuje się słowo kluczowe `transient':

transient InvoiceDialog* pDialog;

 

Zapytania

Zapytania realizują przeglądanie zbioru obiektów i znajdowanie obiektów o określonych warunkach. POET oferuje kilka sposobów realizacji zapytań. W programie można używać zarówno Object Query Language oraz wywołań funkcji w C++. W obu przypadkach rezultatem zapytania jest zbiór obiektów spełniających pewne warunki. Te obiekty mogą być w każdym momencie użyte w programie. Użytkownik może również realizować zapytania za pomocą ODBC.

Object Query Language (OQL) jest bardzo podobny pod względem syntaktyki do SQL'a, lecz wykorzystuje on system typów języka C++ oraz rozumie semantykę deklaracji klas. ODMG przyjęło OQL jako standardowy język zapytań dla obiektowych baz danych.

Poniżej przedstawiono zapytanie wypisujące faktury, w których przynajmniej jedna pozycja posiada masę większą niż 100 dla produktu, który kosztuje więcej niż 50:

 define extent allInvoices for Invoice;

 

select i

from i in allInvoices,

e in i.Entries

where e.quantity > 100

and e.pProduct.list_price > 50

Zapytania są stringami dlatego też mogą one być przechowywane w bazie danych, przesyłane za pomocą sieci do innych procesów, zachowywane w postaci plików.

Filtry są bardzo podobne do zapytań, przy czym używając filtrów można pokazać każdą wyszukaną pozycję zaraz po jej znalezieniu. Natomiast wykorzystując zapytania rezultat przeszukiwanie dostępny jest dopiero po zakończeniu szukania.

Wszystkie filtry pracują w jednakowy sposób:

• specyfikują warunki zapytania w obiekcie PtQuery,

• instalują obiekt PtQuery jako filtr dla AllSet za pomocą PtAllSet::SetFilter(),

• odczytują obiekty z bazy w normalny sposób, przy czym widoczne są jedynie obiekty spełniające warunki.

Dla każdej klasy trwałej POET tworzy klasę Query, wykorzystywaną do wyspecyfikowania warunków zapytań. Warunki mogą odnosić się do składowych obiektów będących referencjami, może być narzucony warunek na liczbę elementów zbioru spełniających warunek, itp. Warunki mogą być łączone operatorami boolowskimi (PtAND, PtOR, PtXOR, PtNOT, PtNAND, PtNOR, PtNXOR).

Filtr może zostać usunięty poprzez wywołanie PtAllSet::UnsetFilter().

 

Dodatkowe właściwości

Integracja z innymi aplikacjami

 POET zapewnia integrację z innymi aplikacjami poprzez następujące mechanizmy:

• ODBC jest standardem wykorzystywanym do wymiany informacji w relacyjnych bazach danych. Chociaż POET nie jest relacyjną bazą danych może ją markować aby udostępniać powszechnie dostępne narzędzia dla relacyjnych baz.

• Microsoft's OLE 2.0

Architektura Client/server oraz praca grupowa 

POET dostarcza aplikacje dostępne dla wielu użytkowników wykorzystując architekturę client/server . Charakreryzuje się ona wykonywaniem zapytań na serwerze, po zakończeniu przeszukiwania jedynie znaleziony zbiór zostaje przesłany do klienta.

POET dostarcza możliwości zabezpieczania danych poprzez operacje zakazu wykonywania odczytu, zapisu i usuwania obiektów bazy.

POET oferuje różnorodne właściwości które ułatwiają tworzenie aplikacji orientowanych na pracę grupową, podczas której kilka osób pracuje razem używając tych samych obiektów w tym samym czasie.

Pierwszym wymaganiem dla takiego typu systemów jest prawdziwa wieloużytkownikowa architektura. W przypadku gdy jedna osoba dokonuje tymczasowych zmian bardzo ważnym jest zachowanie ich tak aby możliwe było cofnięcie operacji oraz dokonanie zabezpieczeń przed jednoczesną modyfikacją danych przez kilka osób.

POET dostarcza następujące mechanizmy: Watch & notify, możliwość odwołań do obiektów innej bazy danych oraz CheckIn / CheckOut, umożliwiające dokonywanie zmian w przestrzeni użytkownika, które mogą być następnie przerzucone do centralnej bazy danych.

Narzędzia wspomagające tworzenie i administrowanie bazy danych 

POET Developer's Workbench jest zintegrowanym środowiskiem, które umożliwia uruchamianie prekompilatora, tworzenie bazy danych, testowanie deklaracji klas, przeglądanie i edytowanie obiektów w bazie danych, uruchamianie zapytań OQL. Wynikowy zbiór wyświetlany jest za pomocą browsera obiektów, który w prosty sposób umożliwia przeglądanie obiektów bazy.

Narzędzia wspomagające administrowanie bazą danych umożliwiają następujące operacje:

wykonywanie backup'ów on-line, tworzenie pustej bazy danych, regenerację indeksowania, uaktualnianie formatu bazy danych do nowych wersji POET'a, zwiększanie liczby osób mających dostęp, sprawdzanie którzy z użytkowników mają dostęp do serwera, zabezpieczanie danych poprzez kontrolę dostępu, logowanie się użytkowników, prawa dostępu itp.

18

---