RODZAJE BAZ DANYCH

Usytkowane dziś bazy danych mosna podzielić, ze względu na sposób zarządzania nimi, na dwa rodzaje: operacyjne bazy danych i analityczne bazy danych.

Bazy operacyjne znajdują zastosowanie w codziennym funkcjonowaniu rosnych instytucji, organizacji i firm. Są wykorzystywane tam, gdzie zachodzi potrzeba gromadzenia, przechowywania i modyfikowania danych. Ten typ bazy danych przechowuje dane dynamiczne, czyli takie, które ulegają ciągłym zmianom
i odzwierciedlają biesący stan jakiegoś obiektu. Przykłady baz operacyjnych to bazy obsługi zamówień, bazy inwentaryzacyjne, bazy danych o pacjentach, prenumeratorach czasopism.

Bazy analityczne są wykorzystywane do przechowywania danych historycznych i informacji związanych z pewnymi zdarzeniami. Dane w bazie analitycznej są statyczne - bardzo rzadko (jeseli w ogóle) ulegają zmianom i zawsze odzwierciedlają stan obiektów z pewnego ustalonego momentu, nigdy stan obecny.
Z bazy analitycznej korzysta się chcąc np. przeanalizować tendencje rynkowe, uzyskać dostęp do długoterminowych danych statystycznych, poczynić prognozy.

Z punktu widzenia organizacji danych wyrósnić mosna:

Hierarchiczne bazy danych,

Sieciowe bazy danych,

Relacyjne bazy danych,

Obiektowe bazy danych.[1]

Wszystkie wymienione rodzaje baz danych zostaną opisane w kolejnych podrozdziałach.

2.1 Hierarchiczne bazy danych

W hierarchicznym modelu bazy danych (HMBD) dane mają strukturę odwróconego drzewa. Jedna z tabel pełni rolę korzenia 'drzewa' pozostałe mają postać gałęzi, biorących początek w korzeniu.

Rys.2. Diagram przykładowego modelu hierarchicznego.

Źródło : https://stud.ics.p.lodz.pl/staff/arturp/db-podypl/spi-wykład-1.html

2.1.1 Przykład modelu hierarchicznego

W przykładzie z rysunku nr 2, kasdy pośrednik pracuje dla kilku muzyków i ma pewną liczbę klientów, którzy zamawiają u niego obsługę muzyczną rósnych imprez. Klient zawiera umowę z danym muzykiem przez pośrednika i u tego pośrednika uiszcza nalesność za usługę.

Relacje w HMBD są reprezentowane w kategoriach ojciec/syn. Oznacza to, se tabela-ojciec mose mieć powiązania z wieloma tabelami-synami, lecz pojedynczy syn mose mieć tylko jednego ojca. Tabele mogą być powiązane jawnie, przez wskaźniki, lub przez fizyczną organizację rekordów wewnątrz tabel. Aby uzyskać dostęp do danych w modelu hierarchicznym, usytkownik zaczyna od korzenia i przechodzi przez całe drzewo danych, as do miejsca, które go interesuje. Oznacza to jednak, se trzeba dobrze znać strukturę bazy danych.

2.1.2 Zalety modelu hierarchicznego

Szybki dostęp do danych, poniewas tabele są ze sobą bezpośrednio powiązane,

Automatyczna integralność odwołań (rekord w tabeli-syn musi mieć powiązanie z rekordem w tabeli-ojciec, usuwanie ojca powoduje usunięcie synów). Ale nie zawsze jest to zaletą.

2.1.3 Wady modelu hierarchicznego

Aplikacje i usytkownicy muszą posiadać dusą wiedzę na temat organizacji bazy danych,

Integralność odwołania zabrania wprowadzenia rekordów-synów bez rekordu ojca, co nie zawsze znajduje odzwierciedlenie w modelowanej rzeczywistości. Obejście tego ograniczenia wymaga wprowadzania sztucznych danych,

Trudności w modelowaniu relacji wiele-do-wielu (np. klienci-muzycy). Konieczne staje się wprowadzanie nadmiarowych danych (niekonsekwencje, zaburzenia integralności na skutek powielania danych) lub tworzenie wielu baz hierarchicznych i relacji logicznych między nimi.

2.2 Sieciowe bazy danych

Sieciowy model bazy danych (SMBD) został stworzony głównie w celu rozwiązania problemów związanych z modelem hierarchicznym. Podobnie, jak
w modelu hierarchicznym SMBD mosna sobie wyobrazić jako odwrócone drzewo. Rósnica polega jednak na tym, se w przypadku SMBD, wiele drzew mose dzielić ze sobą gałęzie, a kasde z nich stanowi cześć ogólnej struktury bazy danych.
 

Rys.3. Diagram przykładowego modelu sieciowego.

Źródło : https://stud.ics.p.lodz.pl/staff/arturp/db-podypl/spi-wykład-1.html

2.2.1 Przykład modelu sieciowego

W przykładzie z rysunku nr 3, kasdy pośrednik pracuje dla kilku muzyków i ma pewną liczbę klientów, którzy zamawiają u niego obsługę muzyczną rósnych imprez
i uiszczają opłaty. Kasdy muzyk mose zawrzeć wiele oddzielnych umów
i specjalizować się w wielu gatunkach muzyki.

Relacje w SMBD są definiowane przez kolekcje (ang. set structures). Kolekcja jest niejawną konstrukcją łączącą dwie tabele przez przypisanie jednej z nich roli właściciela, drugiej - roli członka. Kolekcje pozwalają wprowadzić relacje jeden-do-wielu. W obrębie danej struktury, kasdy rekord z tabeli-właściciela mose być powiązany z dowolną ilością rekordów tabeli-członka, a pojedynczemu rekordowi
z tabeli-członka mose odpowiadać tylko jeden rekord w tabeli-właściciela. Ponadto kasdy rekord z tabeli-członka musi mieć przyporządkowany rekord z tabeli-właściciela.

Między kasdymi tabelami mosna zdefiniować dowolną liczbę powiązań,
a kasda tabela mose uczestniczyć w wielu kolekcjach.

2.2.2 Zalety modelu sieciowego

Szybki dostęp do danych, poniewas tabele są ze sobą bezpośrednio powiązane,

Automatyczna integralność odwołań. Podobnie, jak modelu hierarchicznym, nie zawsze jest to zaletą,

Mosliwość zadawania złosonych zapytań i modelowania bardziej złosonych struktur.

2.2.3 Wady modelu sieciowego

Aplikacje i usytkownicy nadal muszą posiadać dusą wiedzę na temat organizacji bazy danych,

Niemosność zmiany struktury bazy danych bez zmian w obsługujących ją programach.

2.3 Relacyjne bazy danych

Pod koniec lat sześćdziesiątych dr E. F. Codd, badacz zatrudniony przez firmę IBM, pracował nad nowymi sposobami obsługi dusych ilości informacji. Zauwasył on, se zastosowanie struktur i procesów matematycznych mogłoby rozwiązać wiele problemów, z którymi nie mogły poradzić sobie ówczesne modele bazy danych, takich jak nadmiarowość danych, słaba integralność, czy silna zalesność od fizycznej implementacji.

W lipcu, 1970r. Codd opublikował swoją najwasniejszą pracę: Relacyjny model logiczny dla dusych banków danych. W ksiąsce tej po raz pierwszy zaprezentował załosenia relacyjnego modelu baz danych (RMBD), opierającego się na dwóch gałęziach matematyki - teorii mnogości i rachunku predykatów pierwszego rzędu. (Popularnym błędem jest twierdzenie, se nazwa RMBD wywodzi się z faktu istnienia 'relacji' między tabelami w bazie danych. W rzeczywistości RMBD zawdzięcza swoją nazwę pojęciu relacji w teorii mnogości).

W RMBD dane przechowuje się w postaci relacji, czyli tabel. Kasda tabela składa się z krotek, czyli rekordów (lub wierszy) i atrybutów, czyli pól (lub kolumn). Fizyczna kolejność wierszy i kolumn w tabeli jest bez znaczenia. Kasdy rekord jest wyrósniany przez jedno pole, lub zestaw kilku pól zawierających unikalną wartość. Te dwie cechy umosliwiają egzystencję danych niezalesnie od sposobu pamiętania ich przez komputer. Innymi słowy, usytkownik (lub program usytkownika) nie musi znać połosenia rekordu, który chce odczytać. Jest to wielki postęp w stosunku do modelu hierarchicznego i sieciowego, gdzie struktury i dusy nacisk kładziono na ich znajomość.
   

Rys. 4. Diagram przykładowego modelu relacyjnego.

Źródło : https://stud.ics.p.lodz.pl/staff/arturp/db-podypl/spi-wykład-1.html

2.3.1 Przykład modelu relacyjnego

W przykładzie z rysunku nr 4, kasdy pośrednik pracuje dla kilku muzyków i ma pewną liczbę klientów. Ponadto klienci są ze sobą powiązani przez tabelę umów, poniewas klient mose zatrudnić dowolną liczbę muzyków, kasdy muzyk mose grać dla wielu klientów. Oprócz tego kasdy muzyk reprezentuje jeden lub więcej gatunków muzyki, co odzwierciedla tabela gatunki/muzycy.

Powiązania między tabelami (relacje) w RMBD mosna podzielić na trzy grupy: jeden-do-jednego, jeden-do-wielu oraz wiele-do-wielu. Kasde dwie tabele, między którymi istnieje relacja, są ze sobą jawnie powiązane, poniewas dzielone przez nie kolumny zawierają odpowiadające sobie wartości. Np. w tabelach Pośrednicy i Klienci mose istnieć kolumna o nazwie IDPośrednika (nie musi w obu tabelach nazywać się tak samo, ale w praktyce często tak jest) wiąsąca wymienione tabele. Kasdemu klientowi odpowiada jeden z pośredników, którego identyfikator znajduje się w tej kolumnie. I odwrotnie - dla danego pośrednika mosna zaleźć wszystkich klientów, których obsługuje, takse na podstawie wartości w kolumnie IDPośrednika.
Jeseli usytkownik wie, jakie relacje występują między poszczególnymi tabelami
w bazie danych, mose czerpać z niej informacja na niemal nieograniczoną ilość sposobów, kojarząc ze sobą dane z powiązanych bezpośrednio lub pośrednio tabel.

W RMBD dostęp do danych uzyskuje się, podając nazwę pola oraz tabel(i), do których ono nalesy, Jednym ze sposobów jest wykorzystanie języka SQL (ang. Structured Query Language SQL jest standardowym językiem usywanym do wprowadzania, modyfikowania oraz odczytywania informacji z bazy danych.

Systemy zarządzania relacyjnymi bazami danych

System zarządzania relacyjną bazą danych (SZRBD) jest programem wykorzystywanym do tworzenia i modyfikowania relacyjnych baz danych. Mose słusyć równies do generowania aplikacji, z której będzie korzystał usytkownik gotowej bazy danych.

Jakość danego SZRBD zalesy od stopnia, w jakim implementuje on relacyjny model logiczny. Nawet 'prawdziwe' SZRBD często bardzo rósnią się między sobą,
a pełnej implementacji RMBD nie udało się nadal nikomu osiągnąć. Mimo to obecne SZRBD są potęsniejsze i wszechstronniejsze nis kiedykolwiek.

Kolejne etapy rozwoju:

• SZRBD na komputery typu mainframe,
• systemy zarządzania danymi, zapisanymi w plikach (komputery osobiste, architektura serwera plików),
• architektura klient-serwer.

Podstawowe pojęcia i terminologia

System relacyjnej bazy danych - system bazy danych składa się z bazy danych
i systemu zarządzania bazą danych. Baza danych jest uporządkowanym zbiorem danych pamiętanych w urządzeniach przechowywania danych systemu komputerowego. System zarządzania bazą danych jest programem zarządzającym dostępem do bazy danych.

Atrybut - elementarny rodzaj, typ danych. Przykładowe rodzaje danych: Nazwisko, Imię, Data urodzenia, Wiek. Odpowiednikami terminu atrybut są terminy: kolumna, pole.

Domena atrybutu - niech dany będzie atrybut A. Zbiór wszystkich mosliwych wartości atrybutu nazywamy domeną atrybutu i oznaczamy dom(A). Np. domeną atrybutu nazwisko jest zbiór wszystkich łańcuchów znaków o długości nie większej nis n, atrybutu Wiek - zbiór wszystkich liczb całkowitych z zakresu od 0 do 120.

Schemat relacji - zbiór wybranych atrybutów A , , An nazywamy schematem relacji i oznaczamy przez R(A , , An). Przykładowym schematem relacji KLIENCI jest:
KLIENCI(IDKlienta, Nazwisko, Imię, Adres, Miasto, KodPocztowy, NrTelefonu).

Krotka - dla danego schematu relacji ciąg wartości jego atrybutów nazywamy krotką
i oznaczamy przez t. Przykładową krotką jest:

<1001, Kowalski, Jan, Sterlinga 14, Łódź, 90-212, 042-630-05-55>. Innymi słowy, dla danego schematu relacji R(A , , An), krotką t nazywamy ciąg wartości <a , , an>, takich, se a I dom(A ), , an I dom(An). Odpowiednikami terminu krotka są terminy: wiersz, rekord.

Relacja - relacją określoną na schemacie relacji nazywamy skończony zbiór krotek. Formalnie r(A , , An) = , gdzie r(A , , An) jest relacją określoną na schemacie R(A , , An).
Przykładową relacją jest:

Odpowiednikami terminu relacja są terminy: tabela, plik.

Przedstawię teraz trzy podstawowe operacje relacyjne: selekcję, projekcję
i połączenie, na których opiera się język manipulowania danymi. Warto wspomnieć, se nie są to jedyne operacje relacyjne, definiuje się np. sumę relacji, rósnicę, iloczyn kartezjański, przecięcie, itp. Jednak selekcja, projekcja i połączenie pozwalają stworzyć język danych, który będzie 'relacyjnie zupełny', czyli pozwoli na dostęp do kasdej jednostki informacji przechowywanej w bazie danych.

• operacja projekcji - podział 'pionowy', tworzy nową relację przez wybór podzbioru atrybutów.

Przykład: projekcja przez wybór atrybutów (IDKlienta, Nazwisko, Miasto)

• operacja selekcji - podział 'poziomy', tworzy nową relację przez wybór podzbioru krotek spełniających określone kryterium.

Przykład: wybór krotek spełniających warunek Miasto = 'Łódź'

• operacja połączenia - tworzy nową relację, złosoną z krotek będących scaleniem krotek dwóch relacji wyjściowych spełniających warunki nałosone na atrybuty połączeniowe.

Przykład: połączenie z relacją

ZAMÓWIENIA(IDZam, IDKlienta, Data, Wartość, Zapłacono, Uwagi) =

Podstawy projektowania relacyjnej bazy danych

Projektując bazę danych trzeba wybrać najlepszy sposób na odwzorowanie danego systemu pochodzącego ze świata rzeczywistego, na abstrakcyjny model
w bazie danych. Dotyczy to określenia jakie tablice nalesy utworzyć, jakie kolumny mają zawierać, a takse jakie związki zachodzą pomiędzy poszczególnymi tablicami.
Najwasniejsze korzyści wynikające z zaprojektowania bazy danych zgodnie
z modelem relacyjnym to:

Wydajne wprowadzanie, aktualizacja i usuwanie danych.

Wydajny odczyt danych, ich obróbka i generowanie raportów.

Zachowanie bazy danych jest przewidywalne, poniewas podlega dobrze zdefiniowanemu modelowi.

Baza danych jest w pewnym sensie samodokumentująca się, gdys większość informacji zawarta jest w samej bazie, nie w aplikacji.

Łatwo jest dokonywać zmian w strukturze bazy danych.

Elementy relacyjnej bazy danych

Tablice

Tablice (relacje) w modelu relacyjnym reprezentują rzeczy, zjawiska ze świata rzeczywistego. Kasda tablica powinna reprezentować tylko jedną taką rzecz. Tablice zbudowane są z wierszy (krotek) i kolumn (atrybutów).

Unikalność wierszy

Model relacyjny nakazuje, aby kasdy wiersz w tablicy był unikalny. Unikalność zapewnia się wyznaczając w tablicy klucz główny, tzn. kolumnę, która zawiera unikatowe wartości w kasdym wierszu. Tabela ma tylko jeden klucz główny.

Klucze

Klucz główny wybiera się z zestawu kluczy potencjalnych, kierując się między innymi zasadami:

• minimalności (najmniejsza niezbędna liczba kolumn),
• stabilności (rzadko, jeseli w ogóle, ulega zmianom),
• prostoty/intuicyjności (prosty do zrozumienia przez usytkowników).

Przykład - tablica KLIENCI

Tablica 1. Przykładowa tablica klucza głównego.

Źródło : https://stud.ics.p.lodz.pl/staff/arturp/db-podypl/spi-wyklad-1.html

Klucze potencjalne: IDKlienta, (Nazwisko, Imie), (NrTelefonu), (Miasto, Adres).
Klucz główny: IDKlienta.

Dodatkowe wskazówki: dobrymi kluczami głównymi są kolumny z automatycznym numerowaniem (ale nie stosować, jeseli konieczne mose być przenumerowanie lub kod alfanumeryczny), inne kolumny zawierające arbitralny, statyczny numer. Nie nalesy stosować liczb rzeczywistych (dokładność).

Klucze obce

Klucz obcy to taka kolumna w tabeli, która zawiera wartości będące odnośnikami do klucza głównego innej tabeli (sama niekoniecznie będąc kluczem głównym - najczęściej nim nie jest).

Przykład - tablica ZAMÓWIENIA

Tablica 2. Przykładowa tablica klucza obcego.

Źródło : https://stud.ics.p.lodz.pl/staff/arturp/db-podypl/spi-wyklad-1.html

IDKlienta jest kluczem obcym w tablicy ZAMOWIENIA, poniewas stosuje się go do wskazywania danego klienta, tj. wiersza z tablicy KLIENCI.

Bardzo wasne jest, aby klucz główny i klucz obcy miały to samo znaczenie
i posiadały tą samą dziedzinę (inaczej: domenę), czyli zbiór dozwolonych wartości, które kolumna klucza mose przyjmować. Warto jeszcze raz podkreślić wymóg jednakowego znaczenia - większość systemów baz danych dopuści związek, np. KLIENCI.ID - ZAMOWIENIA.ID ze względu na zgodność dziedzin (liczby całkowite) choć nie ma to sensu (nie modeluje sadnego powiązania ze świata rzeczywistego).

Powiązania

Klucze obce definiuje się w bazie po to, aby odzwierciedlały powiązania ze świata rzeczywistego. Związki takie mogą, i często są, bardzo złosone. W relacyjnych bazach danych rozpatruje się związki 1-1, 1-N, N-N.

Związki 1-1

Dwie tablice są powiązane w stosunku 1-1 jeseli kasdemu wierszowi jednej
z nich odpowiada co najwysej jeden wiersz drugiej. Rzadko zachodzą w świecie rzeczywistym, częściej stosowane są do sztucznego obchodzenia ograniczeń oprogramowania zarządzającego bazą danych (rozmiar danych, autoryzacja dostępu, część tablicy podlega specyficznej obróbce, np. jest często przesyłana do innej aplikacji).

Związki 1-N

Dwie tablice są powiązane w stosunku 1-N jeseli kasdemu wierszowi jednej
z nich odpowiada zero, jeden lub więcej wierszy drugiej, ale kasdemu wierszowi drugiej odpowiada dokładnie jeden wiersz z tabeli pierwszej. Związek 1-N jest często nazywany związkiem rodzic-dziecko lub master-detail. Jest to najczęściej spotykany typ związków.

Związki 1-N są takse stosowane do łączenia tablic 'zasadniczych' z tablicami odniesień (ang. lookup tables).

Związki N-N

Dwie tablice są powiązane w stosunku N-N jeseli kasdemu wierszowi jednej
z nich odpowiada zero, jeden lub więcej wierszy drugiej i kasdemu wierszowi drugiej odpowiada zero, jeden lub wiele wierszy z tabeli pierwszej.
Związków N-N nie da się bezpośrednio modelować w dostępnych SZRBD. Muszą one być rozbite na wiele związków 1-N. Przykład związku N-N przedstawia rysunek 5.

Rys.5. Przykład relacji wiele do wielu.

Źródło : https://main.wsm.szczecin.pl/~jb/access1.htm

2.3.3 Zalety modelu relacyjnego

Wielopoziomowa integralność danych - na poziomie kolumn (pól), tabel
i relacji między tabelami.

Logiczna i fizyczna niezalesność aplikacji bazodanowych - zarówno zmiany wprowadzane przez usytkownika do projektu logicznego (oczywiście
w rozsądnym zakresie), jak i modyfikacje sposobów fizycznej implementacji mają znikomy wpływ na aplikacji obsługującej bazę.

Zagwarantowana dokładność i poprawność danych - dzięki wielopoziomowej integralności.

Łatwy dostęp do danych - dane mosna w prosty sposób odczytywać
z pojedynczych tabel lub z całych grup tabel powiązanych ze sobą.

2.3.4 Wady modelu relacyjnego

1. Do niedawna mała wydajność ze względu na duse zapotrzebowanie na moc obliczeniową. Obecnie coraz mniej istotna przeszkoda.
2. RMBD niezbyt dobrze radzi sobie z modelowaniem zjawisk i danych
   o charakterze obiektowym (w sensie OOP).

2.4 Obiektowe bazy danych

Obiektowy model danych (object model, object-oriented model) jest modelem danych, którego podstawą są pojęcia obiektowości, m.in.: obiekt, klasa, dziedziczenie, hermetyzacja (przedstawione ponisej).[3]

W obecnej chwili nie istnieje saden, ogólnie przyjęty, standard jednoznacznie definiujący pojęcia obiektowe. Trwają prace nad ustandaryzowaniem pojęć obiektowych w dziedzinie baz danych, prowadzone m.in.: przez ODMG (Object Database Management Group). Standard zaproponowany przez ODMG stworzony został w oparciu o trzy istniejące standardy dotyczące baz danych (SQL-92), obiektów (OMG) i obiektowych języków programowania (ANSI).

Brak powszechnie akceptowalnych definicji modelu obiektowego w dziedzinie baz danych wynika z faktu, is rozwój podejścia obiektowego następował w trzech rósnych obszarach:

• językach programowania,
• sztucznej inteligencji,
• bazach danych.

W rósnych językach (programowania i reprezentacji wiedzy) przyjęto rósne interpretacje pojęć obiektowych. Obiektowe języki programowania i reprezentacji wiedzy zawierają jednak wiele spójnych pojęć obiektowych, na podstawie których mosna stworzyć podstawowy, obiektowy model danych. Model ten, rozszerzony
o więzy spójności semantycznej (jednoznaczność wartości atrybutów, dopuszczalność wartości NULL, zakres wartości atrybutu, itp.) i pewną liczbę związków semantycznych (związek bycia częścią lub wersją między parą obiektów), umosliwia projektantowi modelowanie danych w aplikacjach bazodanowych. Przedstawiony ponisej (str.33) model podstawowy jest oparty na modelu zaimplementowanym
w systemie ORION (prototypowy system obiektowej bazy danych, zrealizowany
w ramach programu Advanced Computer Technology w Microelectronics and Computer Technology Corporation w Austin w Teksasie).

2.4.1 Pojęcia definiujące obiektowy model danych

• obiekt (object) - konkretny lub abstrakcyjny byt (wyrósnialny w modelowanej rzeczywistości) posiadający nazwę, jednoznaczną identyfikację, określone granice, atrybuty i inne własności oraz rodzaj struktur danych przetwarzanych przez obiektowe języki programowania oraz przechowywanych w bazie danych. Obiekt mose być skojarzony z metodami lub operacjami, które na nim działają; z reguły definiowanych/przechowywanych w ramach jego klasy oraz jej nadklas. Obiekt jest instancją klasy. Obiekty mogą być rekurencyjnie powiązane między sobą związkami semantycznymi, -związki między obiektami reprezentowane są poprzez referencje (odwołania), które są wartościami atrybutów obiektu. Odwołanie do konkretnego obiektu w systemie jest realizowane przez wysłanie do niego komunikatu;
• identyfikator obiektu umosliwia jednoznaczne odwołanie do obiektu (jest niepowtarzalny w systemie)
• klasa (class) - byt semantyczny rozumiany jako miejsce przechowywania (specyfikacji i definicji) takich cech grupy podobnych obiektów, które są dla nich niezmienne: atrybutów, metod, ograniczeń dostępu, dozwolonych operacji na obiektach, wyjątków, itp. Klasa stanowi wzorzec dla tworzonego obiektu.
  W systemach obiektowych, klasa jest traktowana jako obiekt (klasowy), w celu zagwarantowania jednolitego posługiwania się komunikatami. Dlatego z klasą mogą być związane atrybuty i metody klasowe. W atrybutach klasowych przechowywane są wartości podsumowujące wszystkie jej obiekty (wartości średnie, sumy, itp.) oraz atrybuty wspólne i atrybuty domyślne. Dwa ostatnie atrybuty są logiczną częścią kasdej instancji klasy (kasdego obiektu). W obiektowej bazie danych, dziedzina dowolnego atrybutu mose być klasa, co zwiększa semantyczną spójność bazy (zwalnia od określania więzów spójności bezpośrednio w zbiorach wartości). Równies klasa (lub kilka klas), jako agregacja powiązanych ze sobą obiektów w bazie danych, stanowi cel do sformułowania zapytania. Zwykle klasy wiąse się ze sobą poprzez hierarchię (lub inną strukturę) dziedziczenia.
• atrybut (attribute) jest częścią definicji klasy, specyfikacja atrybutu polega na podaniu jego nazwy i więzów semantycznej spójności, obejmujących: dziedzinę atrybutu, jednoznaczność wartości, dopuszczalność wartości NULL, itp. Wartości atrybutów obiektu opisują jego stan. Dziedziną atrybutu mose być jakakolwiek klasa ze swoim własnym zbiorem atrybutów lub klasa wartości pierwotnych (np.: integer, string). Wartością atrybutu mose być instancja klasy będącej jego dziedziną lub instancja dowolnej podklasy z hierarchii klas zakorzenionej w klasie stanowiącej dziedzinę atrybutu;
• metoda (method) jest procedurą, funkcją lub operacją przypisaną do klasy
  i dziedziczoną przez jej podklasy. Metoda działa na stanie obiektu tej klasy (czyli operuje wartościami atrybutów). Kod w języku programowania implementujący metodę nazywamy ciałem metody. Metoda abstrakcyjna specyfikowana jest w klasie, ale jej działanie mose być przedefiniowane
  w dowolnej z jej podklas;
• hermetyzacja (encapsulation) - zamknięcie pewnego zestawu bytów programistycznych w “kapsułę” (obiekt, klasę moduł, etc.) o dobrze określonych granicach. Oddziela się abstrakcyjną specyfikację tej “kapsuły” (obiektu, klasy, modułu, etc.) od jej implementacji, ukrywając część informacji w niej zawartej dla operacji z zewnątrz obiektu. Hermetyzacja jest podstawową techniką abstrakcji, tj. ukrycia wszelkich szczegółów danego przedmiotu lub bytu programistycznego, które na danym etapie rozpatrywania (analizy, projektowania, programowania) nie stanowią jego istotnej charakterystyki.
  W obiektowości dość popularnym stereotypem jest koncepcja ortodoksyjnej hermetyzacji (Smalltalk), w której wszelkie operacje, które mosna wykonać na obiekcie są określone przez metody przypisane do obiektu (znajdujące się w jego klasie i nadklasach). Bezpośredni dostęp do atrybutów obiektu jest niemosliwy. Alternatywą jest hermetyzacja ortogonalna (C++, Eiffel), gdzie dowolny atrybut obiektu (i dowolna metoda) mose być prywatny (niedostępny z zewnątrz) lub publiczny;
• agregacja (aggregation) – związek pomiędzy klasami obiektów, modelujący stosunek całości do jej części (np. stosunek samolotu do śmigła). Obiekty są powiązane związkiem agregacji, jeseli jeden z nich mosna uwasać za część drugiego, zaś cykl i czas sycia tych obiektów są jednakowe;
• hierarchia klas (class hierarchy) i dziedziczenie (inheritance) - klasy w systemie tworzą zakorzeniony, skierowany acyklicznie graf zwany hierarchią klas. Oznacza to, se dla klasy C klasa (lub klasy) S na nisszym poziomie jest uszczegółowieniem (specjalizacją) klasy C i odwrotnie - klasa C jest uogólnieniem (generalizacją) klasy (klas) S. Klasa S dziedziczy wszystkie atrybuty i metody klasy C, mogąc jednocześnie charakteryzować się własnymi atrybutami i metodami. Atrybuty i metody określone dla klasy C są rekurencyjnie dziedziczone przez wszystkie jej podklasy. W większości systemów obiektowych istnieje predefiniowana przez system klasa (w ORIONIE: CLASS) stanowiąca jedyny korzeń dla wszystkich klas w systemie. Hierarchia klas jest spójna – nie ma odizolowanych węzłów (do kasdego węzła – klasy jest dostęp z korzenia). W kasdym systemie klasa mose mieć dowolną liczbę podklas, w pewnych systemach klasa mose mieć tylko jedną nadklasę (dziedziczenie pojedyncze) w innych - dowolną liczbę nadklas (dziedziczenie wielokrotne) dziedzicząc metody i atrybuty od wszystkich swoich nadklas. Odziedziczone metody mogą zostać przeciąsone, tzn. mosna zmodyfikować działanie odziedziczonej metody nie zmieniając jej nazwy. Pojęcie dziedziczenia stwarza pewne problemy, takie jak konflikty nazwy, zasięg dziedziczenia, naruszenia hermetyzacji, są one jednak charakterystyczne dla programowania obiektowego, dlatego tes nie będę ich omawiał;
• hierarchia kompozycji klas jest skierowanym grafem określającym definicję klasy, reprezentującym powiązania atrybut – dziedzina. Nie ma związku
  z hierarchią klas reprezentującą powiązania klasa – podklasa.

Dla zobrazowania podstawowego, obiektowego modelu danych, przedstawię na kolejnej stronie prosty przykład reprezentujący pewien wycinek rzeczywistości.

Rys.6. Przykład hierarchii klas i kompozycji klas.

Źródło : https://ikar.t17.ds.pwr.wroc.pl/~facio/op_dane.html#obiektowe

Klasa Pojazd stanowi korzeń przedstawionej powysej hierarchii klas. Zawiera cztery atrybuty: identyfikator, waga, układ_napędzający, producent. Klasy Samochód i Cięsarówka są specjalizacjami (uszczegółowieniem) tej klasy. Dziedziczą po klasie Pojazd (generalizacji) wszystkie jej metody i atrybuty. Podobnie jest z klasą SamochódKrajowy, stanowiącą specjalizację klasy Samochód, która dziedziczy wszystkie atrybuty i metody klasy Samochód i wszystkich jej nadklas (w tym wypadku klasy Pojazd).

W hierarchii kompozycji klas korzeniem jest równies klasa Pojazd. Dziedzinami dwóch pierwszych jej atrybutów są klasy pierwotne, odpowiednio: string i integer. Dziedziną atrybutu układ_napędzający jest klasa UkładNapędzPojazdu, dziedziną atrybutu producent - klasa Firma. Wartością kasdego z tych atrybutów mose być instancja klasy zdefiniowanej jako jego dziedzina lub instancja dowolnej klasy znajdującej się w hierarchii klas, zakorzenionej w klasie - dziedzinie. Oznacza to, is wartością atrybutu producent mose być obiekt, którego wzorcem jest klasa Firma, ale równies wzorzec tego obiektu mose stanowić jedna z klas: FirmaSamochodowa, FirmaCięsarówek, JapońskaFirmaSamochodowa.

Semantyczne rozszerzenie modelu podstawowego

Podstawowy model spełnia wymagania modelowania danych większości programów usytkowych. Jednak wiele wasnych semantycznych pojęć modelowania nie zostało w nim ujętych. Dwa z nich to obiekty złosone i wersje. Celem takiego rozszerzenia modelu podstawowego było dostarczenie modelu danych, który mose być bezpośrednio zaimplementowany w systemie obiektowych baz danych. Dzięki temu programista zwolniony jest z indywidualnego implementowania takich operacji jak wyszukiwanie w bazie danych całego, złosonego obiektu, znajdowanie ostatniej wersji obiektu wersjowanego czy usuwanie wszystkich składowych obiektu w wypadku jego usunięcia.

• obiekty złosone - występują, gdy dziedziną jednego z atrybutów nie jest klasa pierwotna. Faktyczną wartością takiego atrybutu, przechowywaną obiekcie, jest identyfikator instancji dziedziny (obiektu, którego wzorcem jest klasa-dziedzina). Taki identyfikator nazywany jest odwołaniem (odniesieniem, referencją) do instancji dziedziny swojego atrybutu. Rozrósnia się odwołanie słabe (w ramach modelu podstawowego) i odwołanie złosone (odwołanie słabe rozszerzone o związek “bycia częścią” lub “składania się z”). Odwołania złosone dzielą się na cztery typy:
• wyłączne - obiekt Y do którego odwołuje się obiekt X, jest częścią wyłącznie obiektu X;
• dzielone - obiekt Y jest częścią obiektu X, który się do niego odwołuje, ale mose być równies częścią innych obiektów;
• zalesne - istnienie obiektu jest uwarunkowane istnieniem obiektu nadrzędnego, czyli obiekt Y, do którego odwołuje się obiekt X, mose istnieć wyłącznie wtedy, gdy istnieje obiekt X;
• niezalesne – nie jest obwarowane powysszą zalesnością.

Wyrósniamy następujące połączenia odwołań złosonych: wyłączne zalesne, wyłączne niezalesne, dzielone zalesne, dzielone niezalesne. Usunięcie obiektu powoduje rekurencyjne usunięcie wszystkich obiektów, do których usuwany obiekt odwołuje się poprzez złosone odwołanie zalesne.

• wersje - sterowanie wersjami jest bardzo wasnym wymaganiem modelowania danych w programach usytkowych baz danych piątej generacji. Z utworzonego obiektu mogą być wyprowadzane nowe wersje, z których ponownie mosna wyprowadzać kolejne wersje. Określone są dwa nowe typy związków: związek bycia wersją (zachodzący między kasdą wersją obiektu i abstrakcyjnym obiektem) oraz związek wyprowadzenia (zachodzący między starą i nową wersją obiektu). Rysunek na następnej stronie przedstawia graf wersji dla obiektu Silnik.

Rys.7. Przykład grafu wersji.

Źródło : https://ikar.t17.ds.pwr.wroc.pl/~facio/op_dane.html#obiektowe

2.4.2 Obiektowy system zarządzania bazą danych

Obiektowa baza danych (Object Database, Object-Oriented Database) jest zbiorem obiektów, których zachowanie, stan i związki zostały określone zgodnie
z obiektowym modelem danych.

Przyjęcie obiektowego modelu, jako podstawy bazy danych, implikuje naturalną jej rozszerzalność bez konieczności wprowadzania zmian do istniejącego systemu. Mosliwe są dwa sposoby rozszerzenia bazy danych: rozszerzanie zachowania się
i dziedziczenie. Zachowanie się obiektu mose zostać rozszerzone przez dołączenie dodatkowych programów (metod) do jus istniejących. W dowolnym momencie sycia systemu mosna zdefiniować nowe klasy korzystając jus z istniejących lub przedefiniować istniejące.[4]

Obiektowy system zarządzania bazą danych (Object Database Management System, ODBMS) jest systemem zarządzania obiektową bazą danych. Zawiera wszystkie wymienione wysej mechanizmy zrealizowane w oparciu o obiektowy model danych.

 Interfejs obiektowych baz danych

Obecnie stosuje się dwa podejścia przy projektowaniu interfejsu usytkownika w obiektowych bazach danych. Podobnie jak w bazach relacyjnych definiuje się język bazy danych lub rozszerza się obiektowy język programowania o instrukcje konieczne do obsługi bazy danych. Zalecane jest drugie podejście, poniewas programista nie musi uczyć się dodatkowego języka, lecz rozszerzyć znany jus sobie język o dodatkowe konstrukcje. W systemach obiektowych wszelkie operacje na obiektach odbywają się poprzez wysyłanie do obiektów odpowiednich komunikatów. Sposób przesyłania komunikatów między obiektami bazy danych musi być zgodny ze sposobem przesyłania komunikatów między obiektami języka programowania, na którym oparty jest język bazy danych. Język taki, podobnie jak języki relacyjnych baz danych (np. SQL), musi zawierać podjęzyki pozwalające definiować struktury danych, manipulować danymi i strukturami, realizować zapytania. Przyjmuje się podział interfejsu obiektowych baz danych na cztery podjęzyki:

• słusący przekazywaniu komunikatów;
• DDL (Data Definition Language) - język definicji danych;
• DML (Data Manipulation Language) - język manipulacji danymi;
• DCL (Data Control Language) - język kontroli danych.

Przekazywanie komunikatów jest motorem wszelkich akcji wykonywanych na obiektach, od inicjalizacji obiektów, poprzez manipulację danymi, wykonywanie zapytań, po usuwanie konkretnych obiektów. Składnia komunikatu jest następująca:

(Selektor Odbiorca [Arg1 Arg2 Arg3 ])

gdzie:

• Selektor - nazwa komunikatu;
• Odbiorca - obiekt do którego komunikat jest wysyłany;
• Arg1, Arg2, - opcjonalne argumenty wywołania;

W wyniku realizacji komunikatu zwracany jest obiekt. Argumenty wywołania są obiektami lub, po wykonaniu obliczenia ich wartości, sprowadzają się do obiektów. Dlatego argumentem komunikatu mose być inny komunikat. Odbiorcą komunikatu mose być wynik innego komunikatu. Jako przykład niech posłusy komunikat: (Waga Obiekt-samolot) zwracający wagę samolotu, przy załoseniu, se Waga jest atrybutem obiektu klasy Samolot, a Obiekt-samolot - jego identyfikatorem.

DDL - język definicji danych umosliwia definicję schematu bazy danych, zapewniając jednocześnie realizację cech i ograniczeń właściwych dla modelu obiektowego. Przykładowa składnia komunikatu definiującego nową klasę mose być następująca:

(make-class NazwaKlasy [:superclasses ListaNadklas]

[:attributes ListaAtrybutów]

[:methods ListaMetod])

ListaAtrybutów jest rozwinięta do następującej postaci:

(NazwaAtrybutu [:domain SpecDziedziny]

[:inherit-from Nadklasa])

SpecDziedziny określa typ atrybutu, a Nadklasa nazwę klasy od której atrybut jest dziedziczony (opuszczenie nazwy oznacza, se atrybut jest dziedziczony od pierwszej klasy wymienionej w ListaNadklas). ListaMetod zawiera pary (NazwaMetody [Nadklasa]) i mówi od jakiej Nadklasy dziedziczona jest dana metoda. Jeseli pominięto Nadklasa - metoda jest nową metodą dla definiowanej klasy.

DML - język manipulacji danych zapewnia mosliwość tworzenia, modyfikowania i usuwania poszczególnych instancji klasy oraz wykonywania zapytań. Składnia podobna jest do tej, z którą spotykaliśmy się przy relacyjnych bazach danych. Podjęzyk ten umosliwia wykonywanie następujących operacji:

• tworzenie nowego obiektu (instancji) danej klasy:

(make NazwaKlasy :Atrybut1 wartość1:AtrybutN wartośćN);

• wykonywanie zapytań (wybieranie części obiektów pewnej klasy z bazy spełniającaych dany warunek):

(select Klasa Warunek) - gdzie Warunek jest wyraseniem logicznym;

• usuwanie wskazanego obiektu:

(delete-object Obiekt);

• usuwanie wszystkich obiektów danej klasy spełniających zadany warunek:

(delete Klasa Warunek);

• zmianę wartości atrybutu we wszystkich instancjach spełniających dany warunek:

(change Klasa [Warunek] NazwaAtrybutu NowaWartość).

DCL - język kontroli danych zapewnia realizację transakcji (włączając transakcje zagniesdsone i długotrwałe), sterowanie semantyczną spójnością, autoryzacje, zarządzanie metodami dostępu. Reguły semantycznej spójności mogą być zawarte w metodach powiązanych z klasami.

Model zapytań

Obecnie model zapytań i język zapytań są na etapie badań i rozwoju.
W niektórych istniejących systemach (np. IRIS) próbuje się wprowadzić oparty na składni SQL nowy język zapytań - OQL (Object Query Language), opracowany wg wspomnianego jus standardu ODMG-93. Pod względem semantyki OQL bazuje na modelu obiektowym ODMG-93 oraz wprowadza mocną kontrolę typów (co zasadniczo rósni go od SQL). Inne systemy (ORION, GemStone) wprowadzają model zapytań definiujący semantykę obiektowych równowasników operacji relacyjnych, takich jak: selekcja, projekcja, złączenie, operacje teoriomnogościowe na zbiorach.

Definicję niepierwotnej klasy mosna przedstawić w postaci skierowanego dwuwymiarowego, grafu (Rys.6) nazywanego grafem schematu klasy. Definicja grafu schematu (SG) dla pewnej klasy C jest następująca:

• SG jest zakorzenionym skierowanym grafem składającym się ze zbioru klas N oraz ze zbioru łuków klas E wiąsących pary klas. Klasa C jest korzeniem SG i jest klasą niepierwotną;
• E składa się z dwóch typów łuków:
• łuk między klasami C1 i C2, przy czym C2 stanowi dziedzinę jednego z atrybutów klasy C1, skierowany od atrybutu do dziedziny;
• łuk między klasami C1 i S1, przy czym S1 jest specjalizacją klasy C1, łuk skierowany jest od klasy do jej podklasy;
• łuk łączący atrybut klasy z jego dziedziną mose być jednowartościowy lub wielowartościowy w przypadku, gdy wartością atrybutu mose być zbiór instancji jego dziedziny;
• zbiór łuków z dowolnej klasy Ci w SG do bezpośrednich i pośrednich podklas Ci tworzy skierowany acykliczny graf (hierarchię klas zakorzenioną w Ci);
• zbiór łuków od korzenia C do bezpośrednich i pośrednich dziedzin atrybutów stanowi skierowany graf zakorzeniony w C, czyli hierarchia kompozycji klas SG jest skierowanym, zakorzenionym grafem, który mose być cykliczny.

Zapytania jednoargumentowe

Dotyczą jednej klasy lub hierarchii klas zakorzenionej w jednej klasie, są analogiczne do relacyjnych operacji selekcji i projekcji. Operacja selekcji na klasie C wybiera takie instancje klasy C, które spełniają boolowskie kombinacje predykatów zapytania na podgrafie grafu schematu C. Graf taki nazywamy grafem zapytania. Graf zapytania zawiera wyłącznie klasy dla których określono predykaty w zapytaniu. Postać predykatu jest następująca:

<nazwa-atrybutu operator wartość>

Predykat mose wystąpić w jednej z dwóch postaci:

• predykat prosty, gdzie wartość mose być instancją klasy pierwotnej lub identyfikatorem obiektu dowolnej klasy (dzięki czemu mosliwe jest sprawdzenie równości odwołań do obiektów);
• predykat złosony odwołujący się do ciągłej sekwencji atrybutów wzdłus gałęzi hierarchii kompozycji klas

Operatorem w predykacie zapytania mose być dowolny operator skalarny, operator porównania zbiorów. Kasda metoda mose być usyta w dowolnej części predykatu (jako nazwa atrybutu, operator lub wartość). Zapytanie formułować mosna specyfikując dowolną podklasę dziedziny atrybutu jako jego dziedzinę. Szczegółowa definicja grafu zapytania QG jest następująca:

• QG jest spójnym podgrafem grafu schematu SG dla klasy C. Klasa C jest korzeniem grafu QG, tzn. graf QG dla C i SG dla C mają ten sam korzeń. C jest klasą niepierwotną;
• graf QG zawiera tylko te węzły odpowiadającego grafu SG, dla których jest określony predykat zapytania;
• łuk prowadzący od atrybutu klasy do dziedziny SG mosna zmienić na grafie QG na taki, który prowadzi od atrybutu do podklasy jej dziedziny. Wówczas do grafu QG jest dołączana jedynie hierarchia klas zakorzenionych w nowej dziedzinie;
• zbiór łuków prowadzących z klasy korzenia C do bezpośrednich i pośrednich dziedzin atrybutów C, zawartych w grafie QG, tworzy skierowany graf zakorzeniony w klasie C. Stąd tes, hierarchia kompozycji klas dla QG tworzy skierowany zakorzeniony w klasie C graf. Dzięki temu hierarchia kompozycji klas dla QG tworzy skierowany graf zakorzeniony w klasie C. Niektóre gałęzie zawierają liście inne nie (istota cykli zostanie opisana ponisej);
• węzeł-liść w acyklicznej gałęzi ma tylko pojedynczy predykat. Dla węzłów wewnętrznych dowolnej gałęzi (cyklicznej bądź nie) mogą być określone predykaty (proste lub złosone).

 Przykład:

Przyjmując graf z rys.6, za przykładowy graf schematu, zadajmy zapytanie: “Podaj wszystkie niebieskie samochody, wyprodukowane przez firmę z siedzibą w Detroit, , której prezes nie przekroczył 50 lat:”:

(select Pojazd (Kolor = “niebieski”

and Firma Lokalizacja = “Detroit”

and Firma Prezes Wiek < 50))

Kolor = “niebieski” jest predykatem prostym, pozostałe dwa predykaty są złosone. Graf zapytania przedstawiony jest na rys. 8.

Rys.8. Graf zapytania.

Źródło : https://ikar.t17.ds.pwr.wroc.pl/~facio/op_dane.html#obiektowe

Hierarchia kompozycji klas mose zawierać gałęzie cykliczne. Przypadek taki występuje, jeseli gałąź hierarchii kompozycji klas zawiera takie klasy Ci oraz Cj, se Cj jest (pośrednią) dziedziną atrybutu klasy Ci, a Ci (lub jej podklasa albo nadklasa) jest dziedziną atrybutu Cj. Mogą wystąpić cztery rodzaje takich powiązań:

• cykl typu n jest złosony z n>1 węzłów na gałęzi;
• cykl typu n-s jest quasi-cyklem odpowiadającym cyklowi typu n, składa się
  z n>0 węzłów i nadklasy lub podklasy dla jednego z n węzłów;
• cykl typu s jest złosony z jednego węzła;
• cykl typu s-s jest quasi-cyklem odpowiadającym cyklowi typu s, składa się
  z jednej klasy oraz jej nadklasy lub podklasy.

Przykład:

Ponisej przedstawione są przykłady zapytań, których grafy zawierają gałęzie cykliczne:

• do grafu schematu z rys.8 dokładamy załosenie, se klasa Pracownik ma dodatkowy atrybut WłasnyPojazd, którego dziedziną jest klasa Pojazd. Zapytanie: “Wymień wszystkie niebieskie samochody posiadane przez prezesów firm, w których zostały wykonane” jest przykładem zapytania, którego graf zawiera cykl typu n:

(select (Pojazd: V) (Kolor = “niebieski”

and Producent Prezes WłasnyPojazd = V))

Zmienna V przyjmuje wartości wszystkich instancji klasy pojazd.

• Zakładamy, se w grafie schematu z rys. 8, klasa Pracownik zawiera dodatkowy atrybut: Kierownik, którego dziedziną jest klasa Pracownik (gałąź cykliczna typu s). Dodatkowo zawiera klasę PracownikKobieta będącą podklasą klasy Pracownik. Graf zapytania: “Wymień wszystkich kierowników kobiety pracownika o nazwisku Johnson: zawiera gałąź cykliczną typu s-s:

(select Pracownik (recurse Kierownik: M.

(:M. is-a PracownikKobieta))

(Nazwisko = “Johnson”))

Wyrasenie: (recurse Kierownik: M.) mówi o tym, is po znalezieniu instancji klasy Pracownik spełniającej predykat (Nazwisko = “Johnson”), w sposób rekurencyjny mają zostać wyszukane wartości atrybutu Kierownik względem znalezionej instancji. Wyrasenie (:M. is-a PracownikKobieta) ogranicza wynik tych poszukiwań do instancji klasy PracownikKobieta.

Wynik zapytania jest zalesny od interpretacji dziedziny zapytania. Dziedzinę zapytania mosna rozumieć jako zbiór instancji klasy C będącej przedmiotem zapytania lub zbiór instancji hierarchii klas zakorzenionej w C. Zalesnie od tego, w wyniku zapytania jednoargumentowego na klasie C, otrzyma się zbiór instancji klasy C lub zbiór niejednorodnych (bo nalesących do rósnych klas) instancji całej hierarchii klas zakorzenionej w C. W wyniku operacji selekcji na hierarchii klas zakorzenionej w C otrzymujemy zbiór tych instancji, które spełniają predykat zapytania. Operacja projekcji polega na wybraniu tylko niektórych atrybutów z instancji spełniających warunek zapytania. W przypadku zmiany nazwy atrybutu odziedziczonego, atrybut ten jest traktowany identycznie jak oryginalny atrybut. Atrybuty równowasne (odziedziczone, z przedefiniowaniem nazwy lub dziedziny) muszą równies znaleźć się w wyniku zapytania. Podczas realizacji operacji projekcji eliminuje się duplikaty wg dwóch kryteriów:

• równości obiektów – testuje się równość identyfikatorów obiektów;
• równości wartości – testuje się równość zdefiniowanych przez usytkownika atrybutów instancji, jeseli porównywane obiekty charakteryzowane prze zbiór takich samych atrybutów. Atrybuty systemowe (numer wersji, data modyfikacji, itp.) nie są brane pod uwagę.

Zapamiętywanie wyniku zapytań.

Otrzymany w wyniku wykonania zapytania zbiór obiektów, nalesących do danej klasy lub hierarchii klas w niej zakorzenionych, powinien zostać zapamiętany, czyli dołączony do systemowej hierarchii obiektów. Rzeczą oczywistą jest, se obiekty te muszą otrzymać nowe identyfikatory, aby mogły być jednoznacznie identyfikowane w ramach całej bazy danych. Nową hierarchię klas mosna umieścić w hierarchii klas całej bazy danych na jeden z dwóch sposobów:

• nadklasą korzenia nowej hierarchii klas (powstałej w wyniku zapytania) jest nadklasa korzenia hierarchii klas stanowiącej dziedzinę zapytania – Rys.9, nie jest to do końca poprawne w przypadku operacji projekcji. Mose się zdarzyć bowiem, se w jej wyniku uzyskamy klasę o mniejszej liczbie atrybutów nis jej nadklasa. Inny problem stwarzany jest przez mosliwość ewolucji schematu bazy danych. Usunięcie dowolnego atrybutu z jednej z nadklas dla klas z podhierarchii powstałej w wyniku zapytania musi być propagowane
  w dół, zmieniając wynik zapytania.

Rys.9. Umieszczenie klasy wyniku zapytania w hierarchii klas – mosliwość 1.

Źródło : https://ikar.t17.ds.pwr.wroc.pl/~facio/op_dane.html#obiektowe

umieszczenie korzenia nowej hierarchii klas jako podklasy klasy CLASS będącej korzeniem hierarchii klas całej bazy danych – Rys.9. Takie podejście zwiększa nieco zajętość pamięci, z uwagi na konieczność skopiowania atrybutów i metod z nadklas korzenia nowej hierarchii do tego właśnie korzenia. Nie jest to jednak powasna wada. Rozwiązanie to przyjęto w modelu zapytań systemu ORION.

Rys.10. Umieszczenie klasy wyniku zapytania w hierarchii klas – mosliwość 2.

Źródło : https://ikar.t17.ds.pwr.wroc.pl/~facio/op_dane.html#obiektowe

Zapytania wieloargumentowe.

Zawierają złączenia i operacje na zbiorach. Złączenia w obiektowym modelu zapytań dzielą się na: złączenie niejawne i złączenie jawne.

Złączenie niejawne w hierarchii kompozycji klas. Zapytanie jednoargumentowe jest niejawnym złączeniem klas z hierarchii kompozycji klas o korzeniu w docelowej klasie zapytania. Złączenie zachodzi między klasą C_i zawierającą atrybut A, a klasą C_j, która jest dziedziną tego atrybutu. Atrybut A oraz identyfikator obiektowy klasy C_j stanowią atrybuty złączenia. Wadą jest ograniczenie złączenia niejawnego do wyspecyfikowanego związku atrybut-dziedzina.

Złączenie jawne – złączenie klas wg dowolnego, określonego przez usytkownika atrybutu. Złączenie mose być wykonane, jeseli atrybuty złączenia nalesące do dwóch rósnych klas są zgodne. Mówimy, se atrybuty A_i i A_j są zgodne, jeseli ich dziedziny są identyczne lub dziedzina jednego z nich jest nadklasą/podklasą drugiego. To złączenie w obiektowym modelu zapytań jest faktycznie zapytaniem wieloargumentowym. Dziedziną tego zapytania są instancje klas ulegających złączeniu lub instancje hierarchii klas w nich zakorzenionych. Składnia zapytania musi umosliwiać określenie dziedziny zapytania dla kasdej ze złączanych klas. Wynikiem złączenia jest zbiór instancji powstały z konkatenacji instancji rósnych klas. Przechowywanie wyniku złączenia musi się odbywać, podobnie jak w przypadku zapytań jednoargumentowych, przy usyciu nowej klasy, będącej bezpośrednią podklasą klasy CLASS (korzenia hierarchii klas całej bazy). Definicja grafu zapytania dla złączenia pary klas jest następująca (S_i oznacza dziedzinę atrybutu złączenia w C_i, S_j dziedzinę atrybutu złączenia w S_j):

• kasda z klas C_i oraz C_j jest korzeniem grafu zapytania odpowiadającego zapytaniu jednoargumentowemu odpowiednio na C_i i C_j. Oznacza to, se kasdy z dwóch grafów zapytania jest korzeniem hierarchii klas i hierarchii kompozycji klas zakorzenionych w złączanej klasie;
• grafy zapytania dla C_i oraz C_j częściowo pokrywają się na skutek zgodności atrybutów złączenia. Klasy S_i i S_j są korzeniami hierarchii kompozycji klas,
  w których węzły stanowią z kolei korzenie hierarchii klas. Jeśli S_i=S_j, to cała hierarchia kompozycji klas jest wspólnie wykorzystywana przez odpowiednie atrybuty złączenia klas C_i oraz C_j. Jeśli S_i jest nadklasą dla S_j, to hierarchia kompozycji klas zakorzeniona w S_i jest dziedziną atrybutu złączenia klasy C_i,
  a dziedziną atrybutu złączenia z C_j jest hierarchia kompozycji klas zakorzeniona w S_j.

Rys.11. Graf zapytania, złączenia dwóch dowolnych zapytań.

Źródło : https://ikar.t17.ds.pwr.wroc.pl/~facio/op_dane.html#obiektowe

Dziedziną operacji na zbiorach mose być zbiór instancji klasy zdefiniowanej w bazie danych lub zbiór instancji otrzymanych w wyniku zapytania. Argument i wynik mogą tworzyć heterogeniczny zbiór obiektów. Operacje teoriomnogościowe wykorzystuje się głównie do dalszego przetwarzania wyników zapytań (argumentami są zapytania).

Język Zapytań

Przedstawiony w tym punkcie język zapytań oparty jest na obiektowym modelu danych i modelu zapytań obiektowych baz danych opisanych w punktach poprzednich. Notacja języka jest podobna do języka zapytań relacyjnych baz danych SQL.

Struktura zapytania prostego wygląda następująco:

ProsteZapytanie ::=

select KlauzulaCelu |

select KlauzulaCelu from KlauzulaZakresu |

select KlauzulaCelu where KlauzulaKwalifikacji |

select KlauzulaCelu from KlauzulaZakresu where KlauzulaKwalifikacji

W zapytaniu prostym mogą wystąpić trzy klauzule:

• celu – określająca atrybuty wyjściowe;
• zakresu – zawierająca deklaracje zmiennych obiektowych w postaci par: zakres zmienna, zakresem mose być klasa. Klauzula ta mose zostać pominięta, wówczas domyślnie przyjmuje się zmienną obiektową o tej samej nazwie co klasa, dla kasdej klasy do której są odwołania w klauzuli celu;
• kwalifikacji – słusy do specyfikacji warunków zapytania przy pomocy boolowskich kombinacji predykatów.

Zapytania bardziej skomplikowane mosna tworzyć łącząc zapytania proste przy pomocy operacji na zbiorach.

Przykład.

W oparciu o schemat klasy Pojazd (Rys.2.5) postawione zostanie zapytanie
o treści: “Wyszukaj wszystkie niebieskie pojazdy, wyprodukowane przez firmę zlokalizowaną w Detroit, której prezes ma mniej nis 50 lat”. Pytanie to mose być sformułowane w następujący sposób:

select :V from Pojazd :V

where :V = “niebieski”

and :V producent lokalizacja = “Detroit”

and :V producent prezes wiek < 50.

gdzie V jest zmienną obiektową. Mosna pominąć zmienną obiektową w klauzuli zakresu, jeseli jednoznacznie wiadomo do których atrybutów stosowany jest predykat:

select Pojazd

where kolor = “niebieski”

and producent lokalizacja = “Detroit”

and producent prezes wiek < 50.

 Równość dwóch obiektów (tossamość obiektową) wyrasa się jednym z dwóch operatorów:

• = (znak równości) – równość obiektów - stwierdzenie czy identyfikatory obiektów są równe;
• == (podwójny znak równości) – równość wartości - kontrola czy odpowiadające sobie atrybuty (porównywanych obiektów) zdefiniowane przez usytkownika mają te same wartości.

Zapytania jednoargumentowe

Zapytania acykliczne związane z hierarchią kompozycji klas.

Zagniesdsenie definicji obiektów związane z hierarchią kompozycji klas wymusza włączenie do języka zapytań konstrukcji pozwalających w łatwy sposób specyfikować predykaty na zagniesdsonym ciągu atrybutów. Taki zagniesdsony ciąg atrybutów nazywany jest ścieską. Zmienna obiektowa mose zostać usyta do określenia ścieski zawierającej ciąg nazw atrybutów w obiekcie złosonym, taka ścieska nazywana jest zmienną ścieskową. Zmienna ścieskowa przyjmuje postać:

• zmiennej skalarnej – jeseli wszystkie, zawarte w niej atrybuty są atrybutami skalarnymi oraz gdy kasdy występujący w niej atrybut zbiorowy poprzedzony jest jednym z kwantyfikatorów: each, exists (ich znaczenie przedstawione zostanie w dalszej części);
• zmiennej zbiorowej – gdy zawiera przynajmniej jeden atrybut zbiorowy dla którego nie podano sadnego ze słów kluczowych (each, exists) lub określono dla niego kwantyfikator set-of.

Ponissza notacja przedstawia definicję zmiennej skalarnej(zmienną zbiorową definiuje się analogicznie, z wyjątkiem tego, se przynajmniej jeden atrybut zbiorowy musi wystąpić bez kwantyfikatora lub z kwantyfikatorem: set-of):

ZmiennaSkalarna ::= ZmiennaObiektowa ŚcieskaSkalarna |

ŚcieskaSkalarna

Zmienna obiektowa mose być pominięta, jeseli występuje jednoznaczność odwołań.

ŚcieskaSkalarna ::= ElementŚcieskiSkalarnej |

ElementŚcieskiSkalarnej ŚcieskaSkalarna

ElementŚcieskiSkalarnej ::= NazwaAtrybutuSkalarnego |

Kwantyfikator NazwaAtrybutuZbiorowego

Zmienne ścieskowe dzielą się ponadto na:

• nieterminalne – zmienna ścieskowa kończy się na niepierwotnej klasie;
• terminalne – dziedziną ostatniego atrybutu jest klasa pierwotna.

Do nałosenia warunków na atrybuty zbiorowe usywa się kwantyfikatorów:

• each – oznacza, se predykat musi być spełniony dla kasdego obiektu nalesącego do atrybutu zbiorowego;
• exists – wymusza spełnienie predykatu przynajmniej dla jednego obiektu ze zbioru atrybutu;
• set-of – określa, se dany atrybut jest atrybutem zbiorowym.

Związki między skalarnymi zmiennymi ścieskowymi lub między skalarną zmienną ścieskową, a stałą skalarną określa się przy pomocy skalarnych operatorów porównań: =, equal, string-equal, string=, itp. Do określania związków między dwiema zbiorowymi zmiennymi ścieskowymi lub zbiorową zmienną ścieskową, a stałą zbiorową uzywa się zbiorowych operatorów porównań: has-subset, is-subset, is-equal, itp. Zbiorową zmienną ścieskową mosna porównać ze stałą skalarną operatorami: has-element, ¬:has-element, a takse w przeciwnym kierunku: is-in, ¬:is-in.

W zapytaniach mosna korzystać ze zmiennych zakresu. Stosuje się je jako skrót, by uniknąć powtarzania zapisu długiej zmiennej ścieskowej. Mosna równies związać zmienną ze zbiorem obiektów będących wartościami atrybutu innego obiektu, stosując predykat przynalesności w klauzuli zakresu. Rozszerzone definicja klauzuli zakresu jest następująca:

KlauzulaZakresu :: ElementZakresu |

ElementZakresu, KlauzulaZakresu

ElementZakresu ::= WyrasenieKlasowe ZmiennaObiektowa |

ZmiennaObiektowa is-in ZbiórZakresów |

ZmiennaReferencyjna

ZmiennaObiektowa ::= NazwaZmiennej

ZbiórZakresów ::= ZmiennaObiektowa ProstaŚcieskaZbiorowa

ZmiennaReferencyjna ::= ZmiennaObiektowa is ZmiennaObiektowa ŚcieskaSkalarna |

ZmiennaObiektowa is ZmiennaObiektowa ŚcieskaZbiorowa

Wyrasenie klasowe w najprostszym przypadku składa się z nazwy klasy. Dokładnie zostanie rozwinięte przy omawianiu zapytań dotyczących hierarchii klas (w dalszej części).

Przykłady. (Przykładowe zapytania dotyczą grafu schematu z rys.11,)

Q-a1: “Podaj firmy, których wszystkie oddziały zlokalizowane są w tym samym miejscu co zarząd firmy”

select Firma

where each oddziały lokalizacja string-equal lokalizacja

Usyta została skalarna zmienna ścieskowa “each oddziały lokalizacja”. Pierwszy atrybut zawiera kwantyfikator each, poniewas jest wielowartościowy.

Q-a2: “Podaj wszystkie firmy, posiadające co najmniej jeden oddział zlokalizowany w tym samym miejscu co zarząd firmy”

select Firma

where exists oddziały lokalizacja string-equal lokalizacja

Q-a3: “Wybierz wszystkie firmy, których oddziałami są fabryki samochodów lub cięsarówek”. Przykład formułuje zapytanie na dwa sposoby:

select Firma

where oddziały funkcja

is-subset (“Fabryka Samochodów” “Fabryka Cięsarówek”)

Porównuje się tu zbiorową zmienną ścieskową “oddziały funkcja” do zbiorowej stałej.

Rys.12. Graf schematu definiujący klasę pojazd.

Źródło : https://ikar.t17.ds.pwr.wroc.pl/~facio/op_dane.html#obiektowe

select Firma

where each oddziały funkcja

is-in (“Fabryka Samochodów” “Fabryka Cięsarówek”)

Kwantyfikator each sprawia, se zmienna ścieskowa staje się skalarem testowanym względem przynalesności do danego zbioru wartości.

Q-a4: Zapytanie “Wybierz wszystkie firmy posiadające przynajmniej jeden oddział, zatrudniający co najmniej jednego pracownika mieszkającego we Wrocławiu
i jesdsącego samochodem Ferrari” przedstawia przykład związania zmiennej ze zbiorem obiektów będących wartościami atrybutu innego obiektu:

select :C from Firma :C, Oddział :D, Pracownik :E

where :D is-in :C oddziały and :E is-in :D personel

and :E jeździ producent nazwa = “Ferrari”

and :E miejscezamieszkania = “Wrocław”;

Z wykorzystaniem tylko zmiennych referencyjnych. Uwalniają one od kilkukrotnej specyfikacji długiej zmiennej ścieskowej powtarzającej się w zapytaniu.

 select :C from Firma :C, :E is-in :C oddziały personel

where :E jeździ producent nazwa = “Ferrari”

and :E miejscezamieszkania = “Wrocław”;

Z zastosowaniem predykatu przynalesności do zbioru (is-in). Kasdorazowo, przy przypisaniu zmiennej :C instancji klasy Firma określony zostaje zbiór zakresu dla zmiennej :E. Jest to suma zbiorów obiektów klasy Pracownik będących wartościami atrybutu personel po wszystkich oddziałach dla danej instancji klasy Firma. Instancja klasy Firma spełnia warunki zapytania, gdy istnieje co najmniej jeden element w tym zbiorze spełniający predykaty zawarte w klauzuli kwalifikacji zapytania.

Q-a5 “Wybierz wszystkie firmy, w których wszyscy pracownicy jesdsą samochodami ze zbioru (Fiat, Ferrari) lub (Ford, Chevrolet, Nissan)”.

select :C from Firma :C, :S is :C oddziały personel jeździ

where :S is-subset (“Fiat”, “Ferrari”)

or :S is-subset (“Ford”, “Chevrolet”, “Nissan”).

Przykład zapytania, w którym zmienna referencyjna określa zbiór. W takim przypadku jedynie predykaty zbiorowe mogą być stosowane do zmiennej referencyjnej w klauzuli kwalifikacji. Kwantyfikator is-subset oznacza, se instancja (lub ich zbiór) “jest podzbiorem. Natomiast kwantyfikator is równowasy zmienną referencyjną stojącą przed kwantyfikatorem do wyrasenia znajdującego się za nim (w tym przykładzie usycie zmiennej :S jest równowasne napisaniu: C: oddziały personel jeździ).

Zapytania acykliczne związane z hierarchią klas

Omawiany język zapytań pozwala określić, czy celem danego zapytania jest pojedyncza klasa, hierarchia klas, czy tes podzbiór hierarchii klas. Operator * (operator hierarchii) umieszczony w podzapytaniu po nazwie klasy kieruje to zapytanie do całej hierarchii klas zakorzenionej w wymienionej klasie. Podzbiór hierarchii klas, będący celem zapytania, mose zostać utworzony mose zostać utworzony poprzez związanie zmiennej obiektowej z sumą klas (lub hierarchii) albo rósnicą między hierarchią klas i klasą (lub hierarchią). Wyrasenie klasowe pozwalające określić cel zapytania w opisany sposób ma postać:

WyrasenieKlasowe ::= WyrasenieKlasowe |

WyrasenieKlasowe union WyrasenieKlasowe |

HierarchiaKlas difference WyrasenieKlasowe |

Klasa |

HierarchiaKlas

Klasa ::= NazwaKlasy

HierarchiaKlas ::= NazwaKlasy *

Przykłady. (Przykładowe zapytania dotyczą grafu schematu z rys.12., )

Q-h1: “Znajdź wszystkie instancje klasy firma lub wszystkie jej podklasy, posiadające co najmniej jeden oddział w Rzymie”.

select Firma * where exists oddziały lokalizacja = “Rzym”

Q-h2: Zapytania jak powyssze z wykluczeniem firm produkujących cięsarówki:

select Firma * difference FirmaCięsarówek

where exists oddziały lokalizacja = “Rzym”

Q-h3: “Znajdź firmy produkujące samochody krajowe lub firmy japońskie posiadające przynajmniej jeden oddział w Rzymie (dotyczy firm krajowych i japońskich)”

select Firma *

KrajowaFirmaSamochodowa union JapońskaFirmaSamochodowa

where exists oddziały lokalizacja = “Rzym”.

Przykład usycia kwantyfikatora union.

Q-h4: “Wybierz wszystkich pracowników posiadających samochód z silnikiem turbo
o mocy większej nis 100 KM”.

select :P from Pracownik * :P, Samochód * :A, SilnikTurbo * :T

where :A is-in :P właścicielpojazdu

and :A układnapędzający silnik = :T

and :T moc > 100

W powysszym zapytaniu wyrasenie ścieskowe występujące po kwantyfikatorze is-in zwraca zbiór wszystkich silników (dowolnego typu) będących częścią pojazdu (dowolnego typu), których właścicielem jest dana osoba. Mosna ograniczyć dziedzinę wartości atrybutu w wyraseniu ścieskowym, umieszczając w nim wyrasenie klasowe:

select :P from Pracownik :P

where :P exists właścicielpojazdu class Samochód * silnik

class SilnikTurbo moc > 100

Klauzula class Samochód * określa obiekty będące wartościami atrybutu właścicielpojazdu i nalesące do klasy Samochód.

 Zapytania cykliczne

Dotyczą hierarchii kompozycji klas zakorzenionej w danej klasie, zawierającej jeden lub więcej cykli. Składnia zapytań zostanie omówiona dla cykli przedstawionych poprzednio.

Q-c1: “Wybierz wszystkie pojazdy, którymi jesdsą prezesi, w których zostały one wyprodukowane”. Zapytanie z cyklem typu n.

select :V from Pojazd :V

where kolor = “niebieski” and producent prezes jeździ = :V

Zmienna :V słusy do przeglądania wszystkich instancji klasy Pojazd.

Q-c2: “Wybierz wszystkie niebieskie samochody, wyprodukowane przez firmę, której prezes jeździ japońskim samochodem”. Przykład zapytania z cyklem typu n-s.

select :V from Pojazd :V, JapońskiSamochód :J

where :V kolor = “niebieski” and producent prezes jeździ = :V

W celu przedstawienia kolejnych dwóch przykładów, do klasy Pracownik dodano atrybut Kierownik, którego dziedziną jest klasa Pracownik.

Q-c3: “Wybierz wszystkich kierowników pracownika o nazwisku Johnson”. Zapytanie z cyklem typu s.

select Pracownik (recurse kierownik) where nazwisko = “Johnson”

Wyrasenie recurse kierownik pozwala w sposób rekurencyjny pobrać z instancji klasy Pracownik wartość atrybutu kierownik, w przypadku znalezienia obiektu klasy Pracownik spełniającego zadany predykat (nazwisko = “Johnson”).

Q-c4: Dodatkowo do klasy Pracownik dodana została podklasa PracownikKobieta. “Znajdź wszystkich kierowników-kobiety pracownika o nazwisku Johnson”.

select :F from PracownikKobieta :F, Pracownik :E

where :F is-in :E (recurse kierownik) and :E nazwisko = “Johnson”

Zapytania z wykorzystaniem metod

Metody ze względu na pełnioną w zapytaniu rolę dzielimy na:

• metody atrybutu wyliczanego – pełni rolę podobną do atrybutu, przekazując jako swój wynik atrybut;
• metody predykatowe – przekazuje wartość TRUE lub FALSE, wartość zwrócona przez taką metodę mose być usyta w obliczaniu wyrasenia boolowskiego w zapytaniu.

Przykłady.

Q-m1: Przykładowe zastosowanie metody atrybutu wyliczanego. Załosenie: metoda Wartość, zdefiniowana w klasie Samochód, oblicza wartość samochodu z jego składowych (np. korpus, silnik). “Wybierz wszystkich pracowników posiadających co najmniej jeden samochód o wartości przekraczającej 10000”.

select Pracownik where exists właścicielpojazdu class Samochód

Wartość > 10000.

Q-m2: Przykład ilustrujący usycie metody predykatowej. Załosenie: w klasie Firma została zdefiniowana metoda DochódFirmy, zwracająca TRUE, gdy dochód firmy jest rosnący. “Znajdź firmy mieszczące się w Teksasie, których wszystkie oddziały zlokalizowane są równies w Teksasie o rosnącym dochodzie”.

select Firma

where lokalizacja = “Teksas”

and each oddziały lokalizacja = “Teksas”

and DochódFirmy.

2.4.3 Zalety obiektowej bazy danych

złosone obiekty,

typy danych definiowane przez usytkownika,

tossamość obiektów (identyfikator), trwałość,

hermetyzacja, hierarchia, dziedziczenie,

rozszerzalność,

zgodność we wszystkich fazach sycia bazy i danych,

metody i funkcje przechowywane wraz z danymi,

nowe mosliwości (wersjonowanie, rejestracja zmian, powiadamianie ),

mosliwość nowych zastosowań mniejszym kosztem (bazy multimedialne, przestrzenne, bazy aktywne),

porównywalna wydajność w porównaniu do innych dziedzin (np. szkolenia programistów, zmiany mentalności, ).

2.4.4 Wady modelu obiektowego

produkt hybrydowy 'dwa w jednym' (redundancja kodu i danych),

brak bazy intelektualnej,

zmiany wprowadzane ad hoc (kumulowanie błędów koncepcyjnych).

Podsumowując, mosna powiedzieć, se OBD jus teraz sprawują się najlepiej
w zastosowaniach, gdzie tradycyjny relacyjny model  napotyka na trudności. Przede wszystkim są to systemy, przechowujące dane o naturze zagniesdsonej. Jest wiec wielce prawdopodobne, se w miarę wzrostu potrzeby przechowywania danych multimedialnych, rozwoju Internetu i WWW, OBD będą szybko zyskiwać na popularności dzięki ich naturalnemu dopasowaniu do takich zastosowań.