Banki danych WYKŁAD 5 dr Łukasz Murowaniecki
[email protected] T-109
Łódź 2008
Modele baz danych
Model Model Model Model Model
hierarchiczny sieciowy relacyjny obiektowy relacyjno-obiektowy
Łódź 2008
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.
AUTO
OSOBA
Łódź 2008
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
OSOBA
WŁASNOŚĆ
AUTO
...
...
...
Łódź 2008
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
Model obiektowy
Cechy obiektowości:
pojęcie obiektu i klasy, abstrakcja, enkapsulacja, dziedziczenie, polimorfizm
Łódź 2008
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
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
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
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
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
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
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
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
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
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
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
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
Podstawy baz danych – model obiektoworelacyjny
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
Podstawy baz danych – model obiektoworelacyjny
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
Podstawy baz danych – model obiektoworelacyjny
Migracja modelu relacyjnego do obiektowego
Łódź 2008
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
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
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
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
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
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
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
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ń
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
trudne do zrealizowania
daje sobie radę z dowolną złożonościa dziedziny, użytkownicy mogą pisać metody i dołączać struktury
rozszerzalność
złożone dane i powiązania miedzy nimi
brak
trudne do zrealizowania
Łódź 2008
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)
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
możliwość utrzymania się na rynku
Łódź 2008
Podstawy baz danych – porównanie modeli baz danych RELACYJNE
Cechy podstawowe
Przykłady systemów
•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
Oracle, Informix, Sybase, Ingres, DB2, Progress, Gupta, Access Łódź 2008
OBIEKTOWE
•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 GemStone, O2, Persistence, Versant, POET, Objectivity, ODI
Podstawy baz danych – porównanie modeli baz danych
Stan na dzisiaj
Zalety
RELACYJNE
OBIEKTOWE
Dominuje w zastosowaniach komercyjnych (ok. 95% rynku baz danych)
Mniej popularne, jednak dobrze rokują na przyszłość
•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 Łódź 2008
•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
Podstawy baz danych – porównanie modeli baz danych RELACYJNE
Wady
OBIEKTOWE
•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) Łódź 2008
•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
Podstawy baz danych – porównanie modeli baz danych RELACYJNE
Lepsze gdy...
OBIEKTOWE
•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
Łódź 2008
•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
