Banki danych

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