Zsbd Obiektowe Bazy danych

ZSBD
OBIEKTOWE BAZY DANYCH
Wykład 6
Prowadzący: dr Paweł Drozda
Program wykładu






Wprowadzenie
Model obiektowy
Standard ODMG 3.0
Język ODL
Język OQL
Obiektowość a cechy bazy danych
dr P. Drozda
Przykład wprowadzający
OSOBA
Nazwisko
Imię
Płeć
telefon
Kierownik
Wycieczka (*)
Wynagrodzenie
Program dnia
Wycieczka
Klient
Jest uczestnikiem (*)
Wpłacił
Kwota do zapłaty
Uczestnicy(*)
Data
Program (*)
Koszt
Liczba miejsc
Dzień
Początek
Obiad
element
…
Czas trwania()
dr P. Drozda
…
Jak to wygląda w m. relacyjnym




Osoba(Nazwisko, Imię, Płeć, Telefon) – co z kluczem?
Kierownik (wynagrodzenie) – co z wycieczką, kluczem,
odwołaniem do osoby
Klient (Wpłacił) - …
Co z metodami (czasem wystarczy DML, na ogół
kodowanie poza relacyjnym modelem danych;
procedury, funkcje nie należą do m. relacyjnego)
dr P. Drozda
Zastosowanie obiektowych baz danych

Charakterystyka dziedzin
Złożone typy danych
 Złożone struktury
 Zależności hierarchiczne


Dziedziny zastosowań
Telekomunikacja (złożona infrastruktura)
 Informacja przestrzenna
 Multimedialne bazy danych (produkcja – Ford, Boening, Simens)
 http://www.objectivity.com/pages/object-oriented-databasevs-relational-database/examples.html

dr P. Drozda
Obiektowa baza danych - koncepcja

Dane wykorzystują założenia modelu obiektowego
Klasy
 Dziedziczenie
 Metody
 Przeciążanie metod
 Referencje do obiektów itd.

dr P. Drozda
Obiektowa baza danych – koncepcja

Zapewnione założenia baz danych
Trwałość danych
 Integralność danych
 Współbieżne wykonywanie transakcji
 Interakcyjne uzyskiwanie informacji z bazy
 Odzyskiwanie danych w wyniku awarii
 Kontrola dostępu uprawnionych użytkowników

Po co obiektowe bazy




Brak podziału aplikacja – baza
Bogatszy model danych – więcej można określić w
samym modelu
Możliwość rozszerzania modelu danych
(definiowanie typów przez użytkownika)
Łatwiejsze modelowanie hierarchii
dr P. Drozda
Podejścia w tworzeniu

Tworzenie od podstaw – obiektowe bazy tworzone od
początku – nie wykorzystują wcześniej stworzonych
relacyjnych baz
Standard modelu ODMG 3.0 (Object Database Management
Group)
 Dodatkowa warstwa zawierająca funkcjonalność obiektową –
na dowolnym modelu danych – standard JDO (Java Database
Objects)


Modyfikacja, rozszerzenie relacyjnej bazy na potrzeby
danej dziedziny do własności modelu obiektowego SQL3
dr P. Drozda
Standard ODMG 3.0
Cztery składniki:
 Opis modelu
 Definicja danych – ODL
 Język zapytań – OQL
 Rozszerzenia Javy, Smalltalka, C++ do przetwarzania
trwałych obiektów bazy danych – OML
Standard ODMG 3.0 – opis modelu

Struktura danych




Wielodostęp, transakcje



Obiekty, literały
Typy obiektów – atomowe, kolekcje (krotka, zbiór, wielozbiór, lista,
tablica, słownik)
Możliwe związki binarne1:1, 1:n, m:n poprzez referencje
Transakcja jako jednostka programowa przeprowadzająca z bazę
ze stanu spójnego w inny stan spójny
Wielodostęp realizowany przez blokady (odczyt, zapis)
Integralność danych


Unikalności obiektów – Poprzez OID
Referencyjna – poprzez referencje w obiektach
Elementy modelu obiektowego


Klasa – zawiera elementy opisujące zbiór obiektów
świata rzeczywistego (cechy i zachowanie)
Cechy obiektów
 OID
– systemowy identyfikator obiektu
 Atrybuty – definiowane przez typy danych
 Związki – odwołania do innych obiektów

Metody – opisują działania, jakie mogą wykonać
obiekty danej klasy
dr P. Drozda
Elementy modelu obiektowego



Enkapsulacja – Oddzielenie specyfikacji od ciała –
z zewnątrz widoczne tylko deklaracje atrybutów i
metod – implementacja w ciele
Dziedziczenie – relacja pod/nadklasa – podklasa
dziedziczy metody i atrybuty
Przeciążanie, polimorfizm – zdefiniowanie metody o
tej samej nazwie w podklasach, wywołanie funkcji
dla różnych podklas (późne wiązanie)
Przykład
Figura
Punkt
Typ
X
Y
Pole()
Elipsa
koło
Trójkąt
P1
P2
środek
Promień
środek
Wierzchołki[3]
Pole()
Pole()
Pole()
Prostokątny
Równoboczny
Pole()
Pole()
Język ODL





Służy do definicji danych
Definiuje klasy
Funkcjonalność klasy definiowana poprzez atrybuty
związki i metody
Atrybuty – nazwa + typ
Typy:
 Proste
– liczbowe, tekstowe, daty
 Złożone: krotki – struct, zbioru – set, wielozbioru –
multiset, listy – list, tablicy – array, słownika – dictionary,
odwołujące się do innej klasy
Język ODL cd.



Związki – zawiera nazwę, typ i odwołanie do
związku zwrotnego
Metody – zawierają typ zwracanej wartości, nazwę
oraz listę parametrów przekazywanych do metody,
dodatkowo może wystąpić lista wyjątków
Rodzaje i typy parametrów
 In,
out, inout
 Typy dowolne – tak jak typy danych
Składnia deklaracji

Klasa
class nazwa_klasy [extends nadklasa][:interfejs]
[(extent ekstensja)]{ … };
class Pracownik extends Osoba { …};

Atrybuty
attribute dziedzina nazwa_atrybutu;
attribute string Imie;
attribute Address adres;
attribute set<Telefon> numery_telefonu;
Składnia deklaracji cd.

Relacje
relationship powiązana_klasa nazwa_relacji
inverse powiązana_klasa::nazwa_relacji_w_pow_klasie
relationship Nauczyciel teacher
inverse Nauczyciel::uczniowie;
relationship set<Uczeń> uczniowie
inverse Uczeń::nauczyciel;

Metody
typ nazwa(parametry)
raises (listaWyjątków);
void podajNumer(out string kierunkowy, out string numer)
raises (nieMAtakiegoNUMERU);
Przykład podsumowujący
interface Osoba {
attribute string imie;
attribute string nazwisko;
attribute Adres AdresDomowy;
void PodajNumer(out string oprefix, out string onumer)
raises(zlyNumer);
}
class Student : Osoba{
(extent Studenci)
attribute set<otrzymaneOceny> oceny;
relationship set<Rodzice> dziecko
inverse Rodzice::rodzic;
void drukujOceny();
void drukujOceny(in string iPrzedmiot);
void drukujOceny(in integer iRok);
float średnia(in set<otrzymaneOceny> oceny);
}
Konwencja tworzenia obiektów




atrybuty i metody definiowane na najwyższym
możliwym poziomie
przeciążanie metod w miejscach ułatwiających
„życie”
definicja możliwych wyjątków
nazwy parametrów poprzedzane i dla parametrów
wejściowych i o dla wyjściowych
OQL




Wzorowany na SQL
Obejmuje tylko zapytania
Ogólna składnia – SELECT FROM WHERE –
bardziej rozbudowane atrybuty
Przykład
SELECT struct(ilosc: count(*)) FROM s IN studenci WHERE
s.średnia(oceny) >3.8;
SELECT struct(imie: o.imie,nazwisko: o.nazwisko, oceny:
(SELECT struct(r: oc.rok,p: oc.przedmiot, o: oc.ocena)
FROM oc FROM otrzymaneOceny)) FROM o in Osoba;
OQL – ciąg dalszy

Wyrażenia ścieżkowe – możliwość odwołania się do
obiektów poprzez relację pomiędzy obiektami
SELECT egzaminator: student.oceny.przedmiot.prow.nazwisko FROM
student IN Studenci;

Operacje łączenia

poprzez związki między obiektami
SELECT struct(d: d.nazwa, z: z.nazwisko) FROM z IN zawodnicy, d IN
z.graW

ustalane przez użytkownika
SELECT struct(zaw1: z1.nazwisko, zaw2: z2.nazwisko) FROM z1 IN
zawodnicy, z2 IN zawodnicy WHERE z1.miasto = z2.miasto

Polimorfizm i dynamiczne wiązanie
SELECT f.powierzchnia() FROM f IN figury
Trwałość danych






Koniczność składowania danych przez dłuższy czas (nie
tylko podczas działania aplikacji)
Rozróżnienie pomiędzy danymi trwałymi a działającymi
lokalnie w programie (nietrwałe)
Trwałość przypisana do obiektów a nie do całej klasy
Obiekty mogą być zmieniane z trwałych na nietrwałe i na
odwrót
Przetwarzanie obiektów trwałych i nietrwałych nie różni się
Dwa typy obiektów trwałych


Utrwalone
Odwołujące się do obiektów trwałych
Integralność danych



Unikatowość zapewniona przed OID
Referencyjna zapewniona przez związki pomiędzy
obiektami
Integralność użytkownika
 dotycząca
danych jednostkowych, np. nazwisko
niepuste
 właściwe zależności w danej klasie, np. data urodzenia
nie większa niż data zgonu
 przy modyfikacji danych – uwzględnienie znikających
obiektów
Integralność danych

Specyficzna dla modelu obiektowego
 możliwość
przechodzenia z jednej klasy do innej
 możliwość przynależności do wielu klas, klasy rozłączne
 ograniczenia dotyczące podklas
 redefinicja
metod, atrybutów – można zabronić
 możliwość dodania nowych metod względnie atrybutów
Współbieżne przetwarzanie

Dwie strategie wykorzystywane z relacyjnych baz
danych
blokowania dwufazowe – ma sens gdy działamy na
niewielkiej liczbie obiektów (transakcje albo ustawione w
kolejce, albo wycofywane)
 strategia optymistyczna – najpierw robimy na danych
tymczasowych, potem dopiero zatwierdzamy


Dodatkowe strategie (oparte na podziale transakcji)
Potwierdzenie szeregowalności – transakcje dają się
uszeregować – ale nie odpowiadają ciągowi transakcji
wejściowych np. jedna podzielona na odczyt i aktualizację
 Transakcje zagnieżdżone – transakcja główna generuje
podtransakcje – niezależne od transakcji głównej

Bezpieczeństwo danych


Kopie bezpieczeństwa – na ogół duże bazy –
wysoki koszt tworzenia kopii bezpieczeństwa
Dzienniki transakcji – zawierają wszystkie
transakcje od ostatniej kopii bezpieczeństwa
Transakcja

Dziennik
Transakcji
Baza
danych
Przywracanie spójności – poprzez wycofanie
niezatwierdzonych transakcji bądź wykonanie ponownie
zatwierdzonych, dodatkowa pomoc - savepointy