Zsbd Obiektowe Bazy danych

1. ZsbdObiektowe Bazy danych Wykład 6 Prowadzący: dr Paweł Drozda

2. Program wykładu • Wprowadzenie • Model obiektowy • Standard ODMG 3.0 • Język ODL • Język OQL • Obiektowość a cechy bazy danych dr P. Drozda

3. Przykład wprowadzający … dr P. Drozda

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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)

14. Przykład

15. 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

16. 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

17. 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;

18. Składnia deklaracji cd. • Relacje relationshippowiązana_klasanazwa_relacji inversepowiązana_klasa::nazwa_relacji_w_pow_klasie relationship Nauczyciel teacher inverseNauczyciel::uczniowie; relationshipset<Uczeń> uczniowie inverseUczeń::nauczyciel; • Metody typ nazwa(parametry) raises (listaWyjątków); voidpodajNumer(out string kierunkowy, out string numer) raises (nieMAtakiegoNUMERU);

19. Przykład podsumowujący interface Osoba { attributestringimie; attributestring nazwisko; attribute Adres AdresDomowy; voidPodajNumer(out stringoprefix, out stringonumer) raises(zlyNumer); } class Student : Osoba{ (extent Studenci) attributeset<otrzymaneOceny> oceny; relationshipset<Rodzice> dziecko inverseRodzice::rodzic; voiddrukujOceny(); voiddrukujOceny(in stringiPrzedmiot); voiddrukujOceny(in integeriRok); float średnia(in set<otrzymaneOceny> oceny); }

20. 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

21. 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;

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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