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 Dzień Początek Obiad element … Czas trwania() Wycieczka Uczestnicy(*) Data Program (*) Koszt Liczba miejsc Klient Jest uczestnikiem (*) Wpłacił Kwota do zapłaty 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-database- vs-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 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 Wielodostęp, transakcje 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 Typ Pole() Punkt X Y koło Promień środek Pole() Trójkąt Wierzchołki[3] Pole() Elipsa P1 P2 środek Pole() Prostokątny Pole() Równoboczny 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 Atrybuty 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 Baza danych Dziennik Transakcji Transakcja Przywracanie spójności – poprzez wycofanie niezatwierdzonych transakcji bądź wykonanie ponownie zatwierdzonych, dodatkowa pomoc - savepointy