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

Modele baz danych Model hierarchiczny Model sieciowy Model relacyjny Model obiektowy Model 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. Łó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 Łó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 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

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

Podstawy baz danych – model obiektowo-relacyjny 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 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

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

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

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

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

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