dr Łukasz Murowaniecki T-109

Prezentacja na temat: "dr Łukasz Murowaniecki T-109"— Zapis prezentacji:

1 dr Łukasz Murowaniecki lukaszm@uni.lodz.pl T-109
Banki danych WYKŁAD 5 dr Łukasz Murowaniecki T-109 Łódź 2008

2 Modele baz danych Model hierarchiczny Model sieciowy Model relacyjny
Model obiektowy Model relacyjno-obiektowy Łódź 2008

3 Model hierarchiczny W bazie przechowywane są różne typy rekordów (struktur danych). Dane każdego typu przechowywane są na zasadzie drzewa; każdy rekord z wyjątkiem głównego, posiada dokładnie jeden rekord nadrzędny; jest to powiązanie jeden do wielu. Łódź 2008

4 Model sieciowy (grafowy)
Struktura danych składa się z: Typów rekordów – struktura danych Typów kolekcji – opis związków jeden do wielu między dwoma typami rekordów Łódź 2008

5 Model obiektowy Obiektowa baza danych:
Zbiór obiektów, ich stan, zachowanie się i związki występujące między nimi określone są zgodnie z obiektowym modelem danych Jest to system, który umożliwia zarządzanie bazą danych, zorientowany obiektowo Jest to system, który dziedziczy wszystkie zasadnicze cechy technologii obiektowej Łódź 2008

6 Model obiektowy Cechy obiektowości: pojęcie obiektu i klasy,
abstrakcja, enkapsulacja, dziedziczenie, polimorfizm Łódź 2008

7 Model obiektowy Podstawowe pojęcia: Obiekt – „wszystko jest obiektem”
Klasa – „typ” obiektu Atrybuty – „zmienne” klasy Metody – „funkcje” klasy Komunikat – wywołanie metod służące do wymiany informacji pomiędzy obiektami Enkapsulacja (hermetyzacja) – struktura wewnętrzna obiektu nie jest widziana na zewnątrz obiektu Identyfikator obiektu – adres obiektu pozwalający na odwoływanie się do niego Dziedziczenie – obiekty klasy X dziedziczą zmienne instancji oraz metody klasy Y, czyli można korzystać z obiektu X wszędzie tam gdzie można wykorzystać obiekt Y. Polimorfizm – można stosować metodą o tej samej nazwie do obiektów różnych klas. Łódź 2008

8 Model obiektowy Podstawowe pojęcia:
Atrybuty opisujące obiekty duże BLOB (Binary Large Objects) – głównie dla zasobów multimedialnych; semantycznie traktowane są jako typ prosty, fizycznie nie są przechowywane w pamięci; Atrybuty referencyjne – modelują powiązania pomiędzy obiektami Atrybuty wielowartościowe (kolekcje) – atrybuty typu lista, tablica Atrybuty wyliczalne (derived attributes) – wartość atrybutu nie jest przechowywana, ale jest wyliczana w momencie ich wywołania Więzy integralności – definiowane na poziomie klasy, określają jakie kryteria muszą spełniać wartości atrybutów dla obiektu należącego do danej klasy Demony – procedury uaktywniane przez zdarzenia mające miejsce w bazie danych (np. usunięcie obiektu) Obiekt kompozytowy – jest związek pomiędzy obiektami różnych klas, gdzie jeden obiekt ma być częścią składową drugiego poprzez odwołanie się do niego przy pomocy atrybutu Łódź 2008

9 Model obiektowy Wersjonowanie obiektów
Pozwala na zachowanie poprzednich danych Wersja obiektu – semantycznie znaczący rzut obiektu, dokonany w pewnym momencie czasu Historia wersji – graf typu drzewiastego, którego węzły odpowiadają poszczególnym wersjom Konfiguracja obiektu – związek między wersjami obiektu kompozytowego a wersjami każdego z obiektów składowych danego obiektu Łódź 2008

10 Model obiektowy Trwałość danych:
trwałość - zdolność do istnienia poza czasem działania systemu zarządzania bazą danych ; trwałość jest cechą konkretnych obiektów a nie klasy definiującej dany typ obiektu nadawanie trwałości danym może następować poprzez typ (klasy), jawne nadanie cechy trwałości dla obiektu lub poprzez powiązanie do innych, trwałych, obiektów. Łódź 2008

11 Model obiektowy Składowanie danych:
Sposoby przechowywania obiektów złożonych: model znormalizowany – podział obiektu na pola i zapisanie ich w różnych miejscach model bezpośredni – obiekt złożony w całości, wraz z innymi obiektami tej klasy Łódź 2008

12 Model obiektowy Indeksowanie w bazach obiektowych:
obecność predykatów zagnieżdżonych - obiekty mogą mieć strukturę zagnieżdżoną tj. jeden obiekt poprzez wartość atrybutu odwołuje się do innego, a ten znów do innego dziedziczenie - zapytanie może dotyczyć obiektów konkretnej klasy, ale też może dotyczyć wszystkich obiektów wynikających z hierarchii dziedziczenia dla tej klasy występowanie metod - metody mogą występować w pytaniach w dwóch funkcjach jako cel pytania i jako predykat w określaniu warunków Łódź 2008

13 Model obiektowy Wielodostęp do baz danych: Dostęp poprzez transakcje
Synchronizacja transakcji: Metoda pesymistyczna – blokowanie Metoda optymistyczna – wykrywanie konfliktów Mechanizm zamków: zamykanie przez transakcje dostępu do obiektów: Zamknięcie do czytania – czytany obiekt nie może być aktualizowany Zamknięcie do aktualizacji – obiekt nie może być czytany ani aktualizowany przez inną transakcję Łódź 2008

14 Model obiektowy Wielodostęp do baz danych:
Zakleszczenia: pojawia się, gdy występuje duża ilość krótko trwających zamknięć do aktualizacji Strategie zapobiegające zakleszczeniom: Wstępne rezerwowanie obiektów Wykrywanie i usuwanie zakleszczeń Łódź 2008

15 Model obiektowy Tryby zamknięć w obiektowych bazach danych:
IS (Intention Share) w tym trybie obiekty danej klasy są przez transakcje zamykane do czytania IX (Intention Exclusive) w tym trybie obiekty danej klasy są przez transakcje zamykane do aktualizacji S (Shared) w trybie tym definicja klasy jest zamknięta do czytania oraz wszystkie obiekty klasy są zamknięte do czytania SIX (Shared Intention Exlusive) w trybie tym definicja klasy i wszystkie jej obiekty są zamykane w trybie zamknięcia do czytania, poza tym poszczególne obiekty tej klasy mogą być przez transakcje zamykane do aktualizacji X (Exlusive) w tym trybie zarówno definicja klasy jak i wszystkie jej obiekty są zamykane do aktualizacji Łódź 2008

16 Model obiektowy Czynniki wpływające na powstanie niespójności lub utratę danych: błąd działania transakcji aktualizującej obiekty błąd pracy systemu operacyjnego błąd sprzętowy Łódź 2008

17 Model obiektowy Ochrona danych – kopie bezpieczeństwa
dziennik transakcji - przechowywane są w nim informacje o wszystkich transakcjach, które miały miejsce od czasu utworzenia ostatniej kopii bezpieczeństwa przywracanie spójności bazy danych odbywa się na podstawie dziennika transakcji w dzienniku zapisywane są następujące informacje: unikalny identyfikator transakcji adresy wszystkich obiektów aktualizowanych przez daną transakcję stan obiektu sprzed modyfikacji i stan po modyfikacji informacje dotyczące przebiegu transakcji Łódź 2008

18 Model obiektowo-relacyjny
ORDBMS (Object Relational lub Extended Relational) – wynik ewolucji baz danych relacyjnych w stronę danych obiektowych Tendencje wpływające na kierunek rozwoju: dążenie do zniwelowania niedostatków technologii relacyjnej, szczególnie w zakresie danych multimedialnych, dołączania metod lub reguł "zachowania się" danych, modelowania pojęciowego chęć wprowadzenia wielu cech obiektowości, takich jak klasy, metody, dziedziczenie, abstrakcyjne typy danych - własności potwierdzające choć częściową obiektowość systemu relacyjnego Łódź 2008

19 Podstawy baz danych – model obiektowo-relacyjny
Korzysta z modelu danych zawartego w standardzie SQL3: próbuje dodawać obiektowość do tablic dane są wciąż przechowywane w tabelach, jednak wartości mogą mięć nieco bogatsza niż dotychczas postać Pola typu ADT (Abstact Data Type) zachowują funkcjonalność zwykłych pól (mogą być używane do indeksowania, wyszukiwania, pobierania lub umieszczania danych) przy nowych zawartościach (jak np. multimedia) Łódź 2008

20 Podstawy baz danych – model obiektowo-relacyjny
Język zapytań: SQL3 (Object SQL) – rozszerzony SQL o możliwości zapytań o obiekty zagnieżdżone, ADT, atrybuty o wartości wyliczanej (np. metody obiektu), itp. Wyniki są jednak wciąż podawane w formie tabel i krotek, a nie jako kolekcje obiektów Model obliczeniowy: Rozszerzony język SQL jest podstawowym interfejsem dostępu do danych. Bezpośrednie odwzorowanie między obiektami z języka programowania a obiektami / tabelami w bazie nie istnieje, tłumaczenie wciąż obciąża programistę Łódź 2008

21 Podstawy baz danych – model obiektowo-relacyjny
Migracja modelu relacyjnego do obiektowego Łódź 2008

22 Podstawy baz danych – porównanie modeli baz danych
RDBMS – relacyjny model danych: Zalety: oparte na solidnych podstawach teoretycznych (zainteresowanie świata nauki, a nie tylko biznesu) stabilna pozycja na rynku optymalizacja zapytań Wady: z góry ustalony konstruktor, brak złożonych obiektów brak środków hermetyzacji i modularyzacji (brak oddzielenia implementacji od specyfikacji) brak środków do przechowywania informacji proceduralnych niezgodność impedancji – problem połączenia języka programowania z językiem zapytań niezgodność modelu pojęciowego z modelem implementacyjnym Łódź 2008

23 Podstawy baz danych – porównanie modeli baz danych
ODBMS – obiektowy model danych: Zalety: złożone obiekty typy danych definiowane przez użytkownika tożsamość obiektów (identyfikator), trwałość hermetyzacja, hierarchia, dziedziczenie rozszerzalność zgodność we wszystkich fazach życia bazy i danych metody i funkcje przechowywane wraz z danymi nowe możliwości (wers jonowanie, rejestracja zmian, powiadamianie ...) możliwość nowych zastosowań mniejszym kosztem (bazy mulitmedialne, przestrzenne, bazy aktywne...) porównywalna wydajność (i wciąż rośnie) Łódź 2008

24 Podstawy baz danych – porównanie modeli baz danych
ODBMS – obiektowy model danych: Wady: brak optymalizacji zapytań niedopracowane mechanizmy zarządzania dużą baza obiektów, sterowania wersjami, ... mała liczba ekspertów od technik obiektowych nie wiadomo z jakimi kosztami wiąże się migracja dużych systemów brak dopracowanych standardów Łódź 2008

25 Podstawy baz danych – porównanie modeli baz danych
ORDBMS – obiektowo - relacyjne model danych: Zalety: przystosowanie do multimediów (duże obiekty BLOB, CLOB i dane binarne) dane przestrzenne (spatial) abstrakcyjne typy danych (ADT) metody (funkcje i procedury) definiowane przez użytkownika w rożnych językach (C++, VisualBasic, Java) kolekcje (zbiory, wielozbiory, sekwencje, tablice zagnieżdżone, tablice o zmiennej długości) typy referencyjne przeciążanie funkcji optymalizacja zapytań Łódź 2008

26 Podstawy baz danych – porównanie modeli baz danych
ORDBMS – obiektowo - relacyjne model danych: Wady: wciąż nie uniknięto wielu błędów modelu relacyjnego (np. niezgodności impedancji) brak perspektyw na przyszłość produkt hybrydowy "dwa w jednym" (redundancja kodu i danych) brak bazy intelektualnej zmiany wprowadzane ad hoc (kumulowanie błędów koncepcyjnych) Łódź 2008

27 Podstawy baz danych – porównanie modeli baz danych
Cecha RDBMS ORDBMS ODBMS Standard SQL2 (ANSI X3H2) SQL3/4 ODMG-v2.0 współpraca z obiektowymi językami programowania słaba, programiści musza dostosowywać program obiektowy do potrzeb bazy ograniczona głownie do nowych typów danych bezpośrednia, szeroko rozumiana użytkowanie łatwa do zrozumienia struktura, wiele narzędzi dla użytkowników zapewnia niezależność danych od aplikacji, trudno odzwierciedlać złożone powiązania łatwe dla programistów, użytkownikom pozostaje pewien dostęp przez SQL Łódź 2008

28 Podstawy baz danych – porównanie modeli baz danych
Cecha RDBMS ORDBMS ODBMS programowanie zapewnia niezależność danych od aplikacji, trudno odzwierciedlać złożone powiązania obiekty w naturalny sposób odzwierciedlają dziedzinę, łatwość modelowania różnorodnych typów i powiązań rozszerzalność brak głównie ograniczona do nowych typów danych daje sobie radę z dowolną złożonością dziedziny, użytkownicy mogą pisać metody i dołączać struktury złożone dane i powiązania miedzy nimi trudne do zrealizowania daje sobie radę z dowolną złożonościa dziedziny, użytkownicy mogą pisać metody i dołączać struktury Łódź 2008

29 Podstawy baz danych – porównanie modeli baz danych
Cecha RDBMS ORDBMS ODBMS "dojrzałość" systemów bardzo dojrzale, dobrze poznana i przetestowana metodologia, liczne implementacje, stabilność na rynku niedojrzałe, rozszerzenia są nowe, wciąż ewoluujące i stosunkowo słabo poznane dość dojrzale (dzięki powszechności OOA i OOD) możliwość utrzymania się na rynku przewidywana dla dużych przedsiębiorstw obecnych na rynku przewidywana dla przedsiębiorstw znanych z RDBMS, dołączają się nowi na razie trudno prognozować mimo iż sukces modelu obiektowego wydaje się oczywisty Łódź 2008

30 Podstawy baz danych – porównanie modeli baz danych
RELACYJNE OBIEKTOWE Cechy podstawowe Dane zawarte w tabelach Tabele składają się z kolumn Typy - predefiniowalne Liczba wierszy zmienna Value-based Nie ma wskaźników lecz klucze zewnętrzne Obiekt w bazie reprezentuje obiekt w świecie rzeczywistym Typ obiektowy (klasa): definicja złożonego typu danych (może zawierać inne typy obiektowe lub ich kolekcje) procedury (metody) i operatory do manipulowania tymi danymi Identity-based Enkapsulacja Dziedziczenie: strukturalne: potomek dziedziczy strukturę danych. behawioralne: potomek dziedziczy metody i operatory Przykłady systemów Oracle, Informix, Sybase, Ingres, DB2, Progress, Gupta, Access GemStone, O2, Persistence, Versant, POET, Objectivity, ODI Łódź 2008

31 Podstawy baz danych – porównanie modeli baz danych
RELACYJNE OBIEKTOWE Stan na dzisiaj Dominuje w zastosowaniach komercyjnych (ok. 95% rynku baz danych) Mniej popularne, jednak dobrze rokują na przyszłość Zalety niezależność od języka programowania sprawdzone, dobrze zdefiniowana teoria możliwość zarządzania wielka ilością danych możliwość złożonych kryteriów wyszukiwawczych możliwość dostępu do danych fizycznych dobre mechanizmy kontroli dostępu do danych mechanizmy perspektyw dość łatwa reprezentacja świata dokładnie reprezentuje złożone zależności miedzy obiektami łatwość działania na złożonych obiektach duża podatność na zmiany możliwość definiowania własnych typów, metod dobra integracja z językami programowania ogólnego przeznaczenia (np. C++, Smalltalk) ujednolicony model pojęciowy - obiektowe podejście do analizy, projektowania i implementacji Łódź 2008

32 Podstawy baz danych – porównanie modeli baz danych
RELACYJNE OBIEKTOWE Wady brak bezpośredniej reprezentacji n-m dla trudniejszych problemów bardzo dużo tabel mało naturalna reprezentacja danych ograniczona podatność na zmiany brak złożonych typów danych trudne operowanie na danych złożonych trudne operowanie na danych rozproszonych w sieci heterogenicznej niezgodność z modelem używanym przez języki ogólnego przeznaczenia (impedance mismatch) powiązanie z jednym językiem programowania słaba obsługa przeszukiwania danych brak powszechnie zaakceptowanego języka zapytań brak możliwości optymalizacji zapytań trudny lub nawet niemożliwy dostęp do fizycznych danych słaba kontrola dostępu małe możliwości optymalizacji pracy serwera Łódź 2008

33 Podstawy baz danych – porównanie modeli baz danych
RELACYJNE OBIEKTOWE Lepsze gdy... dane są proste, niezagnieżdżone, łatwe do umieszczenia w tablicy dane mają postać bierna, a procesy korzystające z danych stale się zmieniają często potrzeba wyszukiwać dane spełniające różnorodne warunki dane mają złożoną lub zagnieżdżoną strukturę zdefiniowana przez użytkownika dane tworzą hierarchie dane są rozproszone w sieci heterogenicznej dane dynamicznie zmieniają rozmiar Łódź 2008