Rozproszone i obiektowe systemy baz danych

Dr inż. Robert Wójcik

Wykład 8. Modele rozproszonych i obiektowych bazy danych

8.1. Metody projektowania rozproszonych baz danych 8.2. Model obiektowej baz danych

2

[lit] Stasiecka A., Stemposz E., Subieta K., Rozproszone obiektowe bazy danych, IPI PAN, Warszawa, 1998. [lit] Wykład_04 ze strony: http://wazniak.mimuw.edu.pl/index.php - systemy rozproszone, zaawansowane systemy baz danych – obiektowe bazy danych. [lit] Subieta K., Rozproszone, federacyjne bazy danych.

8.1. Metody projektowania rozproszonych baz danych Projektowanie rozproszonych baz danych jest w ogólnym przypadku podobne do projektowania scentralizowanych baz danych. Różnice wynikają z konieczności rozpraszania danych oraz konstrukcji mechanizmów dostępu, integracji a także przetwarzania informacji pochodzących z rozproszonych źródeł danych. W przypadku projektowania baz danych wyróżniamy dwa podejścia: Od góry do dołu („top-down”); w tym podejściu cała baza jest

projektowana odgórnie, uwzględniając od początku konieczność optymalizacji rozmieszczenia (rozproszenia) danych w oparciu o fakt geograficznego rozproszenia źródeł i konsumentów danych, jakości łączy transmisji danych oraz mocy obliczeniowych serwerów baz danych, a także inne kryteria decydujące o efektywności działania rozproszonego systemu baz danych.

Od dołu do góry („bottom-up”); to podejście polega na integrowaniu już

istniejących (spadkowych) lokalnych baz danych w jedną globalną rozproszoną bazę danych.

top-down

bottom-up

3

Podejście top-down 1) Faza analizy systemowej, która obejmuje rozpoznanie wymagań oraz

precyzowanie kontekstu przyszłej bazy danych. 2) Projekt scentralizowanego schematu pojęciowego (opis rzeczywistości). 3) Projekt struktury logicznej (scentralizowany model logiczny). 4) Modyfikacja struktury modelu logicznego w oparciu o kryteria rozproszenia

związane z faktem fizycznego rozproszenia źródeł i odbiorców danych oraz autonomii lokalnych baz danych. Ustalają one decyzje, które fragmenty projektu pojęciowego będą przechowywane w poszczególnych miejscach, a także jak należy zdekomponować schemat logiczny na poszczególne miejsca.

Analiza

Model pojęciowy

scentralizowany

Model logiczny

scentralizowany

Kryteria

rozproszenia

Modele logiczne

dla

poszczególnych

miejsc

4

Kolejne etapy projektowania w oparciu o podejście top-down mogą obejmować: Określenie danych podlegających replikacjom (lokalnych kopii) oraz

strategii replikacji. Zróżnicowanie logicznego schematu danych w zależności od typu SZBD w

poszczególnych miejscach. Określenie lokalnych schematów dla poszczególnych miejsc. Określenie danych autonomicznych dla poszczególnych miejsc, nie

uczestniczących w rozproszonej bazie danych; co prowadzi do określenia schematu pojęciowego i logicznego dla danych widzianych z zewnątrz.

Podział schematu logicznego: według różnych reguł związanych na ogół z

fizycznym ulokowaniem obiektów rzeczywistych (np. osób zatrudnionych, sprzętu, co pociąga za sobą odpowiedni podział schematu logicznego) lub też z fizycznym ulokowaniem programów aplikacyjnych działających na tych obiektach.

W praktyce największe znaczenie mają podział poziomy (fragmentacja

pozioma) oraz podział pionowy (fragmentacja pionowa) schematu logicznego (w przypadku baz relacyjnych oba podejścia zostały omówione).

5

Fragmentacja pozioma Fragmentacja pozioma oznacza rozbicie populacji obiektów danej klasy na dwa lub więcej miejsc geograficznych. Fragmentacja pozioma może być dokonywana na podstawie różnych kryteriów, które często wiązane są z geograficznym ulokowaniem obiektów rzeczywistych, lub też z geograficznym ulokowaniem przetwarzania tych obiektów.

6

Fragmentacja pionowa Fragmentacja pionowa oznacza przyporządkowanie poszczególnych klas obiektów do poszczególnych miejsc, lub rozbicie obiektów danej klasy na dwa lub więcej podobiektów, przy czym takie podobiekty są przechowywane w różnych miejscach. Taki podział może wymagać powielenia identyfikatorów obiektów (tabel) w każdej lokalizacji w celu umożliwienia ewentualnego scalenia informacji. Fragmentacja pionowa może oznaczać konieczność odpowiedniego podziału informacji zawartych w klasach obiektów oraz ustalenia środków podtrzymania jednoznacznej tożsamości obiektów.

7

Inne fragmentacje danych w rozproszonej bazie danych Możliwe są inne, bardziej złożone fragmentacje danych, które łączą fragmentacje pionowe, fragmentacje poziome oraz redundantne dane (replikacje). Bardziej złożone fragmentacje rodzą trudności z: zarządzaniem metadanymi: gdzieś muszą być ulokowane informacje

odnośnie tego w jaki sposób podzielone dane mają być scalone w kompletne obiekty lub kolekcje w ramach rozproszonej bazy danych; jest to rola metadanych oraz mechanizmu właściwej dystrybucji metadanych pomiędzy uczestników rozproszonej bazy danych;

przetwarzaniem zapytań: dekompozycja zapytania na pod-zapytania

adresowane do poszczególnych miejsc staje się znacznie bardziej kłopotliwa; przesyłanie fragmentów obiektów celem ich zmaterializowania po stronie klienta może być zbyt kosztowne.

Bardziej złożone fragmentacje mogą być nie do uniknięcia w rozproszonej bazie danych integrującej istniejące bazy danych (podejście bottom-up). Ma to konsekwencje dla zarządzania metadanymi.

Podejście bottom-up Omówione poprzednio podejście top-down ma miejsce wtedy, gdy rozproszona baza danych jest konstruowana od początku, a projektanci nie są obciążeni zastanym stanem infrastruktury informatycznej. W przypadku, gdy podczas projektowania rozproszonej bazy danych trzeba uwzględniać: konieczność bieżącej eksploatacji baz już istniejących; konieczność zintegrowania wielu heterogenicznych baz danych w jedną

spójną całość (tj. baz często różniących się strukturą, wykorzystywanymi modelami danych, platformami sprzętowymi, systemami operacyjnymi oraz obsługiwanymi przez różne SZBD),

wówczas taka sytuacja wymusza podejście bottom-up.

8

Podejście bottom-up może być zrealizowane na kilka sposobów:

Podejście ad hoc: budowa uniwersalnych lub specyficznych dla danego zastosowania pomostów (gateways) umożliwiających dostęp z danego systemu bazy danych do innych baz danych; pomost może (nie musi) zapewniać przezroczystość rozproszenia.

Podejście oparte o globalny schemat: wszystkie składniki rozproszonej BD są objęte jednym globalnym schematem, jednakowym dla każdego miejsca i zapewniającym przezroczystość rozproszenia; istotną wadą podejścia opartego na globalnym schemacie jest brak możliwości sterowania zakresem autonomii każdego lokalnego systemu.

Federacyjna baza danych: każda lokalna baza danych zachowuje swoją autonomię, udostępniając tylko część danych dla innych miejsc w RBD; podejście federacyjne zakłada, że każda lokalna baza danych jest widziana poprzez pewną perspektywę (view), ukrywającą niektóre dane dla rozproszonych aplikacji.

Federacyjna baza danych tworzona metodą bottom-up Podejście federacyjne okazało się skuteczne ze względu na zapewnienie autonomii, bezpieczeństwa i efektywności. Powoduje jednak dużo problemów, m.in. z zapewnieniem jednolitej ontologii biznesowej, uniwersalnością aplikacji, wydajnością, itd.

Baza

danych 1

Miejsce 1

Schemat lokalny 1

Aplikacje

lokalneAplikacje

lokalneAplikacje

lokalne

Baza

danych 2

Miejsce 2

Schemat lokalny 2

Aplikacje

lokalneAplikacje

lokalneAplikacje

lokalne

Schemat federacyjnej bazy danych

Perspektywa

Mediator

Osłona

Perspektywa

Mediator

Osłona

Aplikacje globalneAplikacje globalneAplikacje globalne

.....

9

Osłona Moduł oprogramowania umożliwiający przystosowanie interfejsu lokalnej bazy danych do pewnego standardu obowiązującego w systemie rozproszonym. Podstawowe zadanie: fizyczne połączenie różnych baz danych. Inne cechy: Osłona realizuje translację danych, parametrów i wywołań funkcji płynących

z zewnątrz lokalnego systemu (o specyficznych formatach i reprezentacji) na analogiczne dane, parametry i funkcje wyrażone w API konkretnego lokalnego systemu bazy danych.

Dla niektórych przypadków, np. dla niektórych stron HTML, napisanie

osłony jest bardzo trudnym zadaniem ze względu na nieregularności formatu (dane pół-strukturalne, semi-structured).

Osłona jest niezbędna do tego, aby budować bardziej wyrafinowane środki

odwzorowania schematów i aplikacji, takie jak mediatory i perspektywy

Osłony w federacyjnych BD Osłona udostępnia dane i usługi lokalnego systemu i (dostępne w pewnym API i) dla aplikacji globalnych (wykorzystujących wspólny API f). Osłony przystosowują lokalne SZBD do interfejsu programistycznego obowiązującego w federacji. Problem mapowania relacyjnej bazy danych na model obiektowej aplikacji.

FederacyjnySZBD

Lokalny

SZBD 2

Osłona 2

API 2

Lokalny

SZBD n

Osłona n

API nAPI 1

Lokalny

SZBD 1

Osłona 1

API f API f API f

...

10

Mediator Mediator jest modułem oprogramowania, który stanowi warstwę pośrednią pomiędzy lokalną bazą danych a globalnymi aplikacjami. Jest on konieczny wtedy, gdy pojawiają się niezgodności i konflikty pomiędzy formatami informacji w lokalnych bazach danych. Niezgodności te dotyczą różnych aspektów organizacji i działania tych systemów. Np. w jednej bazie danych podany jest zarobek brutto z ubezpieczeniem, w innej zarobek brutto bez ubezpieczenia. Tego typu rozbieżności są rozwiązywane przez mediatory. Typowe niezgodności: Niezgodności pomiędzy schematami pojęciowymi. Niezgodności pomiędzy schematami logicznymi. Niezgodności dotyczące budowy i środków dostępu do katalogów. Niezgodności w zakresie interpretacji semantycznej danych. Niezgodności w sposobach dostępu do bazy. Niezgodności dotyczące reprezentacji danych. Niezgodności dotyczące odniesienia danych do skali czasowej.

Zadania mediatora Rozstrzyganie rozbieżności pomiędzy schematem lokalnym a schematem federacyjnym. Wspomaganie wyboru cech formalnych z danych niesformatowanych. Selekcja właściwej informacji. Wspomaganie przetwarzania informacji sumarycznych, wyliczalnych oraz o większym stopniu abstrakcji. Wspomaganie wykrywania niezidentyfikowanych związków w danych (eksploracja danych).

11

Cechy mediatora Zasady konstrukcji mediatorów nie są jasne. W większości przypadków mediator musi być zaprojektowany ad hoc, pisany techniką niskiego poziomu i przypisany do konkretnej aplikacji (nie uniwersalny).

Perspektywy Perspektywa (view) jest to odwzorowanie schematu lokalnego w inny (zmodyfikowany) schemat. Takiemu odwzorowaniu towarzyszy odwzorowanie danych rzeczywistych lokalnej bazy danych na dane wirtualne lub dane zmaterializowane (wyliczone). Przykładem są perspektywy w SQL.

8.2. Model obiektowej bazy danych

Wykład_04 ze strony: http://wazniak.mimuw.edu.pl/index.php - systemy rozproszone, zaawansowane systemy baz danych - obiektowe bazy danych. http://mst.mimuw.edu.pl/lecture.php?lecture=bad&part=Ch13 Model danych: jest rodzajem abstrakcyjnego metajęzyka, który definiuje pojęcia i terminologię wykorzystywaną do opisu danych i systemów baz danych, a także do reprezentacji i przetwarzania danych na poziomie aplikacji w szczególności aplikacji bazodanowych. Na model danych składają się:

struktura: kolekcja struktur wykorzystywanych do przedstawiania obiektów i encji modelowanego mini-świata;

ograniczenia: reguły zapewniające spójność i poprawność danych;

operacje: zbiór operatorów stosowalnych do struktur w celu czytania i pisania danych.

12

Typy baz danych i generacje modeli danych Dotychczasowe modele danych i typy baz danych nie do końca spełniały wymagania stawiane systemom wykorzystywanym w nowych dziedzinach zastosowań systemów baz danych, jak np. systemy multimedialne.

Pliki płaskie, w których dane są zapisywane sekwencyjnie (liniowo) w postaci tekstowej lub binarnej. Dane zapisywane są w postaci ciągu rekordów. Rozwiązania przydatne dla systemów, w których są przetwarzane małe ilości danych. Podstawowe operacje są związane z przeszukiwaniem pliku od początku, aż do znalezienia żądanego rekordu. Wykorzystywane przed pojawieniem się komercyjnych systemów baz danych.

Hierarchiczne bazy danych (HBD) – dane (rekordy, tabele) są zorganizowane w postaci odwróconego drzewa. Jedna z tabel pełni rolę korzenia drzewa a pozostałe mają postać gałęzi, które biorą swój początek w korzeniu. Każdy rekord może posiadać wiele rekordów-dzieci, ale tylko jeden rekord-rodzica. W modelu tym użytkownik rozpoczyna przeszukiwanie drzewa od korzenia przez całe drzewo, aż do poszukiwanego elementu. Aby odnaleźć element należy dobrze znać strukturę bazy danych. Konstrukcja taka dobrze sprawdzała się do w modelowaniu relacji jeden-do-jednego oraz jeden-do-wielu, lecz uniemożliwiała wyrażenie relacji wiele-do-wielu. Najbardziej znanym przykładem HBD jest opracowany przez IBM w połowie lat 60-tych system IMS (Information Management System).

Sieciowe (grafowe) bazy danych stanowią rozszerzenie hierarchicznych baz danych, poprzez ich usprawnienie w wyniku dodania możliwości opisu relacji wiele-do-wielu. Dane są przedstawiane w postaci grafu. Między dowolnymi węzłami grafu (tabelami) można zdefiniować dowolną liczbę powiązań (kolekcji), a każda tabela może być powiązana z wieloma różnymi kolekcjami. Jednym z pierwszych przykładów tego typu baz danych był system IDS (Integrated Data Store) opracowany przez firmę General Electric.

Relacyjne bazy danych powstały na początku lat 70-tych po opublikowaniu przez E. F. Codda postulatów teorii relacyjnych baz danych. Model relacyjny wykorzystuje pojęcie relacji, która jest fizycznie reprezentowana jako tabela. Relacje są pewnym zbiorem rekordów, które posiadają identyczną strukturę. Rekordy są ze sobą wewnętrznie powiązane za pomocą związków zachodzących między danymi, wyrażonymi za pomocą wartości atrybutów. Operacje na danych wykonywane są za pomocą języka zapytań SQL.

13

Relacyjno-obiektowe bazy danych stanowią poziom pośredni między relacyjną a obiektową bazą danych. Ten rodzaj bazy danych pozwala użytkownikom na definiowanie własnych typów danych oraz uzupełnianie języka zapytań SQL o składnię i semantykę wykorzystywaną wewnątrz abstrakcyjnych typów danych. Wewnętrzna struktura bazy danych oraz mechanizm przechowywania danych są relacyjne. Obiekty są definiowane jako prymitywne typy danych w ramach rekordów. W celu komunikacji z aplikacją obiektową użytkownika wymagane jest mapowanie obiektowo-relacyjne (ORM), np. Oracle.

Obiektowe bazy danych przechowują informacje w postaci obiektów i są związane z konkretnym językiem programowania obiektowego. Składowane dane wykorzystują ten sam model obiektowy co aplikacja. Oprócz stanu obiektu opisanego za pomocą jego atrybutów, model ten zawiera także informacje o zachowaniu się obiektów (operacje związane z obiektem), a także związkach między obiektami. System ten dziedziczy wszystkie zasadnicze cechy technologii obiektowej: istnienie złożonych obiektów, tożsamość obiektów, enkapsulacja danych i metod, dziedziczenie, funkcje polimorficzne, a także baz danych: trwałość danych, oddzielenie logicznego i fizycznego poziomu danych, zarządzanie wielodostępem, odtwarzanie spójnego stanu danych po awariach, zarządzanie transakcjami, zarządzanie informacjami o stanie bazy danych (logi), np. DB4o, ObjectStore. W systemach baz danych dominuje model relacyjny, w którym organizacja danych opiera się na pojęciu zbioru. Nowe dziedziny zastosowań baz danych wymusiły powstanie języków programowania obiektowego oraz modelu obiektowego, w którym organizacja danych opiera się na pojęciu obiektu, występującego w obiektowych językach programowania; model ten w znacznym stopniu jest rozszerzeniem dawnego sieciowego modelu danych, stosowanego w grafowych bazach danych. /wykład/wazniak/bazy obiektowe

Nowe dziedziny zastosowań baz danych - systemy wspomagania projektowania; - systemy informacji przestrzennej; - systemy multimedialne;

14

Nowe struktury danych i sposób ich przetwarzania - złożone struktury danych; - złożone mechanizmy przetwarzania danych; - nowe technologie budowy aplikacji: języki programowania obiektowego. W czasie powstawania relacyjnego modelu danych typowymi dziedzinami zastosowań systemów baz danych były bankowość, ubezpieczenia, finanse, gospodarka magazynowa, itp. Wspólna charakterystyka systemów tej klasy obejmuje proste struktury danych i prosty model ich przetwarzania. Typowymi wartościami atrybutów danych są teksy, liczby i daty. Na początku lat osiemdziesiątych, rozpoczęły się próby stosowania systemów baz danych w nowych dziedzinach, takich jak, systemy wspomagania projektowania, systemy informacji przestrzennej lub systemy multimedialne. Charakterystyka tej klasy zastosowań jest diametralnie odmienna. Przetwarzane i składowane dane są złożone strukturalnie. Typowe są hierarchicznie złożone struktury danych oraz liczne i intensywnie przetwarzane powiązania między danymi. Powiązanie te mają złożoną semantykę: referencji, agregacji lub kompozycji. Również semantyka danych jest bardziej złożona. Informacje, które są przetwarzane w nowych dziedzinach zastosowań to długie dokumenty tekstowe, obrazy, animacje, dane wielowymiarowe, itp. Lata osiemdziesiąte to również okres, kiedy rozpowszechniły się języki obiektowe. Chętnie i powszechnie stosowanymi narzędziami programowymi stosowanymi do budowy aplikacji stały się języki, takie jak: C++, Java, C#. Integracja aplikacji baz danych pisanych za pomocą języków obiektowych z relacyjnymi bazami danych była trudna i nienaturalna ponieważ system typów relacyjnej bazy danych i system typów aplikacji obiektowej są całkowicie odmienne.

15

Przykład reprezentacji złożonych struktur danych z wykorzystaniem modelu obiektowego.

Rodzaje widoczności (dostępności - czy i jak widoczna jest cecha lub operacja dla innych elementów systemu). + publiczny - widoczny z każdego miejsca systemu, - prywatny - widoczny tylko wewnątrz swojej klasy, # chroniony - widoczny wewnątrz klasy i jej podklas, ~ publiczny w zakresie pakietu - widoczny wewnątrz własnego pakietu, czyli w obrębie pewnego zestawu klas. Na rysunku przedstawiono model fragmentu świata rzeczywistego o charakterystyce reprezentatywnej dla wymienionych nowych dziedzin zastosowań. Przykład został zamodelowany za pomocą diagramu klas języka UML. Pierwszą charakterystyczną cechą zamodelowanej rzeczywistości są złożone struktury danych. Przykładem jest klasa „Obraz”, która jest nieograniczoną kolekcją elementów składowych, którymi są „Figury”. Poszczególne typy figur również mają złożoną konstrukcję.

16

Na przykład „Wielokąty” są kolekcjami krawędzi, które z kolei są parami „Wierzchołków”. Na koniec typami danych „Wierzchołków” jest klasa „Punkt”. Kolejną cechą przykładu jest zdefiniowana przez użytkownika semantyka operacji dostępnych dla zdefiniowanych klas, wykraczająca poza operacje predefiniowanych typów danych. Przykładem są operacje dostępne dla klasy „Figura”: wyznaczanie powierzchni i przesuwanie figur na płaszczyźnie. Demonstrowany przykład obejmuje również hierarchię klas, której korzeniem jest abstrakcyjna klas „Figura”, a liśćmi klasy reprezentujące różne typy figur: „Odcinki”, „Koła” i „Wielokąty”. Dzięki temu atrybut „Elementy” klasy „Figura” ma charakter polimorficzny. Wartościami kolekcji „Elementy" są obiekty o różnej strukturze i semantyce operacji. Ostatnią specyficzną własnością ilustrowaną przez przykład są jawne związki między klasami. Są to: binarny związek między klasą „Obraz” i klasą „Osoba” reprezentujący autorstwo poszczególnych „Obrazów” oraz unarny związek między „Obrazami”, reprezentujący zapożyczenia między „Obrazami”. Reprezentacja przedstawionego fragmentu rzeczywistości za pomocą relacyjnego modelu danych nie jest ani prosta, ani naturalna. Relacje (krotki) opisujące występujące zależności (schemat bazy). Figury(id_f PK, typ, powierzchnia) Odcinki(id_odc PK FK(Figury), typ, x1, y1, x2, y2) Wielokąty(id_w PK FK(Figury), typ) Krawędzie(id_k PK, x1, y1, x2, y2, id_w FK(Wielokąty)) Koła(id_k PK FK(Figury), typ, x, y, promień) Obrazy(id_ob PK, utworzony) Osoby(id_os PK, imię, nazwisko, miasto, ulica, numer_domu) Autorstwo(id_ob FK(Obrazy), id_os FK(Osoby)) Modyfikacje(wzorzec FK(Obrazy), modyfikacja FK(Obrazy))

17

W przykładzie występują złożone struktury danych, a jedyną strukturą dostępną w relacyjnym modelu danych jest krotka, czyli płaska lista prostych wartości.

Ograniczenia relacyjnego modelu danych

Płaskie jednowymiarowe struktury danych.

Potrzeba sztucznych kluczy podstawowych.

Semantyka niestandardowych operacji musi być implementowana poza bazą danych.

Brak pojęcia związków.

Brak hierarchii typów. Relacyjny model danych nie umożliwia zagnieżdżania konstruktorów typów danych. W związku z tym, relacyjna reprezentacja przykładu jest rozproszonym zbiorem niepowiązanych i jednowymiarowych struktur danych. Przedstawiony wcześniej schemat relacyjnej bazy danych nie potrafi odzwierciedlić hierarchicznych zależności między danymi. Metodyki poprawnego projektowania schematów relacyjnych baz danych wykluczają również składowanie w bazie danych złożonych wartości atrybutów w sposób transparentny dla modelu danych. Ograniczenie to jest zdefiniowane jako tak zwana pierwsza postać normalna. Potrzeba jednoznacznej identyfikacji pojedynczych danych przechowywanych w bazie danych wymaga rozszerzania schematów relacji o sztuczne klucze podstawowe. Dotyczy to przypadków, gdy zdefiniowane atrybuty nie gwarantują unikalności wartości poszczególnych danych. Ponieważ klasy Figura, Koło, Wielokąt, Odcinek nie posiadają atrybutów jednoznacznie identyfikujących ich wystąpienia transformacja tych klas do schematu relacyjnej bazy danych wymaga dodania sztucznych kluczy podstawowych (PK) do reprezentujących je relacji.

18

Relacyjny model danych pozwala na korzystanie jedynie z ograniczonego zbioru prostych predefiniowanych typów danych. Niestandardowa semantyka przetwarzania danych w rozwiązaniach relacyjnych musi być w całości zaimplementowana poza systemem bazy danych, w aplikacjach bazy danych. Relacyjny model danych nie obejmuje pojęcia związków między danymi. Związki między danymi nie mogą, więc być składowane w bazie danych. Zależności klucz obcy – klucz podstawowy służą jedynie do weryfikacji poprawności danych i nie mogą być wykorzystane do nawigacji między danymi. Związki między danymi są kreowane dynamicznie przez operacje połączenia. Systemy relacyjne realizując operacje połączenia dopiero „w locie” ustalają powiązania między danymi. Kolejnym ograniczeniem modelu relacyjnego jest brak możliwości modelowania hierarchicznych zależności między kolekcjami danych, między którymi zachodzi relacja podzbioru. Integracja danych reprezentujących różne podzbiory Figur będzie wymagać wykonywania operacji połączenia lub sumy. Podsumowując relacyjna implementacja bardziej złożonej rzeczywistości wymaga przeniesienia części jej semantyki do aplikacji bazy danych. Taka semantyka jest trudniej utrzymywana, bo informacji o niej nie ma w bazie danych, lecz trzeba ją utrzymywać w źródłowym kodzie aplikacji. Ponadto, odpowiedzialność za wydajne przetwarzanie semantycznych danych, musi być w tym wypadku przeniesiona z systemu zarządzania bazą danych na programistów tworzących aplikacje. W związku z tym będą to rozwiązania mniej skalowalne.

Przesłanki wprowadzenia nowej generacji baz danych Reprezentacja świata rzeczywistego o złożonej semantyce wymaga odpowiednio silnego modelu danych. Takiego modelu danych, który pozwoli bezpośrednio wyrazić całą semantykę wybranego fragmentu rzeczywistości. Dzięki temu, aplikacje będą odpowiedzialne „tylko” za realizację logiki procesów biznesowych oraz interfejs z użytkownikami.

19

Cechy nowego modelu: - bogatszy model danych, umożliwiający wyrażenie semantyki rzeczywistości; - rozszerzalny model danych umożliwiający ścisłe dopasowanie dla dowolnych dziedzin zastosowań; - ściślejsza integracja z obiektowymi aplikacjami bazy danych.

Idealny model danych powinien również być uniwersalny, po to by można go było dopasować do charakterystyki dowolnej dziedziny zastosowań. Pomysł ten prowadzi do idei „rozszerzalnego modelu danych”. To jest modelu, w którym użytkownicy mogą rozszerzać predefiniowany system typów danych, o dowolnie złożone własne typy danych. Pozwoli to w każdej sytuacji zastosować dokładnie taką siłę modelu, jaka będzie potrzebna dla konkretnego przypadku. Dodatkowo poszukiwany model danych systemu bazy danych powinien umożliwiać łatwą integrację z nowoczesnymi aplikacjami baz danych budowanymi za pomocą języków obiektowych. Idealna sytuacja polegałaby na przepływie danych między bazą danych a aplikacją bez konwersji niezbędnej dla niedopasowanych systemów typów danych (np. mapowania ORM). Modelem danych, który spełnia większość wymienionych wymagań jest model wypracowany dla obiektowych języków programowania. Model ten został zaadoptowany do potrzeb systemów baz danych.

20

Podstawowe cechy modelu obiektowego

Obiekt: stan i funkcjonalność

Cechy obiektów: atrybuty i związki

Funkcjonalność obiektu: metody

Tożsamość obiektu - identyfikatory

Hermetyczność obiektów

Klasa: typ danych i moduł programowy

Dziedziczenie: współdzielenie implementacji i relacja podtypu

Przeciążanie i dynamiczne wiązanie funkcjonalności obiektów

Podstawowym pojęciem tego modelu jest pojęcie obiektu, który umożliwia reprezentowanie cech strukturalnych i behawioralnych obiektów świata rzeczywistego. Struktura obiektu jest opisana przez zbiór atrybutów i związków nazywanych łącznie cechami obiektu. Wartościami atrybutów mogą być wystąpienia prostych typów danych lub obiekty składowe. Wartościami związków są referencje na inne, zewnętrzne obiekty. Zbiór wartości wszystkich atrybutów i związków tworzy stan obiektu. Z kolei własności behawioralne obiektu są reprezentowane przez zbiór dedykowanych procedur zwanych metodami. Obiekty są jednoznacznie identyfikowane za pomocą systemowego atrybutu nazywanego identyfikatorem obiektu lub w skrócie - OID. Wartości tego atrybutu są unikalne i niezmienne. Wewnętrzna struktura obiektu oraz implementacja metod są ukryte przed użytkownikami obiektu. Mówi się, że są to prywatne własności obiektów, niedostępne z zewnątrz. Dostęp do obiektów umożliwia ich publiczny interfejs, czyli wywołania metod obiektu. Metody obiektu są wywoływane przez wysyłanie do obiektu odpowiednich komunikatów. Obiekty o tej samej strukturze i metodach należą do tej samej klasy obiektów. Klasy posiadają dualną naturę. Z jednej strony są odpowiednikami typów danych. Są definicjami własności obiektów. Z drugiej strony klasy są modułami programowymi, które zawierają implementację funkcjonalności typów danych.

21

Klasy mogą być definiowane jako specjalizacje innych klas. Klasa wyspecjalizowana jest nazywana podklasą i dziedziczy ona cechy i metody swojej nadklasy. Dziedziczenie umożliwia współdzielenie implementacji klas. Dodatkowo klasa wyspecjalizowana jest podtypem swojej nadklasy. Umożliwia to polimorficzne przetwarzanie kolekcji klas i dynamiczne wiązanie przesyłanych komunikatów z metodami klasy właściwej dla danego obiektu.

Rozwój obiektowych baz danych Istnieją dwie podstawowe strategie budowy systemów baz danych o obiektowym modelu danych: rewolucyjna, w której nowe systemy baz danych są budowane w całości od podstaw oraz ewolucyjna, w której obiektowe bazy danych powstają przez przyrostowe modyfikacje istniejących systemów baz danych.

Historycznie pierwszym rozwiązaniem była budowa systemów baz danych od nowa na bazie obiektowych języków programowania. Rozwiązanie to polega na rozszerzeniu funkcjonalności obiektów tworzonych i przetwarzanych przez języki obiektowe o własności typowe dla danych przechowywanych w systemach baz danych, to jest:

22

- trwałości, - współdzielenia, - synchronizacji dostępu, - odtwarzania spójnego stanu po awarii, - wydajnego przetwarzania dużych zbiorów obiektów, itp. Wynikiem tej strategii są „czysto” obiektowe bazy danych posiadające jednorodny obiektowy model danych. Standard dla modelu danych tej klasy systemów został opracowany przez organizację „Object Database Management Group” i od nazwy tej grupy jest nazwany „ODMG 3.0”. Kontynuatorem tej strategii jest rozwiązanie, w którym funkcjonalność obiektowego modelu danych jest implementowana przez dodatkową warstwę programową budowaną na systemie bazy danych o dowolnym modelu danych (relacyjnym, obiektowym). Standardem związanym z tą strategią jest „Java Data Objects” - JDO. Całkowicie odmiennym rozwiązaniem jest ewolucyjna modyfikacja relacyjnych systemów baz danych polegająca na rozszerzeniu relacyjnego modelu danych o własności modelu obiektowego: hermetycznych obiektów zintegrowanych z metodami, dziedziczenia, polimorfizmu, dynamicznego wiązania, itp. Wynikiem jest obiektowo-relacyjny model danych, który jest konglomeratem cech relacyjnych i obiektowych. Własności modelu obiektowo-relacyjnego są opisane w standardzie SQL3 (SQL99).

23

Architektury obiektowych i obiektowo-relacyjnych

systemów baz danych Obiektowo-relacyjne systemy bazy danych dziedziczą po systemach relacyjnych cechę niedopasowania systemów typów danych bazy danych i aplikacji bazy danych, co zostało zilustrowane na rysunku po lewej stronie.

Dane przechowywane w bazie danych mają inną strukturę i semantykę niż dane przetwarzane przez aplikacje. Ta sama informacja w ciągu swojego cyklu życia obejmującego przenoszenie jej między pamięcią dyskową, a pamięcią operacyjną zmienia swoją fizyczną reprezentację. W bazie danych jest krotką o określonej reprezentacji fizycznej poszczególnych typów danych, tekstowych, numerycznych i dat. Z kolei podczas wizualizowania na ekranie komputera przez aplikacje ta sama informacja jest kolekcją danych o odmiennych reprezentacjach fizycznych. Na przykład, nazwisko studenta w bazie danych jest przechowywane w polu o typie VARCHAR(20), którego fizyczna reprezentacja jest dwuelementową tablicą, której pierwszy element pamięta faktyczną długość tekstu, a drugi jest łańcuchem kodów ASCII.

24

Tymczasem aplikacja napisana w języku C++ przechowuje nazwisko studenta w zmiennej wskaźnikowej na tekst, który jest ciągiem kodów ASCII zakończonym wyróżnioną wartością zera binarnego. Przenoszenie informacji między bazą danych, a aplikacją wymaga więc bezustannej transformacji fizycznej reprezentacji tej informacji. Niedopasowanie systemów typów danych ogranicza wydajność działania oraz komplikuje tworzenie aplikacji. Czysto obiektowe bazy danych nie posiadają tej wady. Obiekty w bazie danych i obiekty przetwarzane przez aplikacje mają dokładnie taką samą strukturę i semantykę. Przenoszenie danych między pamięcią operacyjną i dyskową nie wymaga żadnego przekształcania danych (rysunek po prawej stronie).

Baza danych jako zbiór kolekcji obiektów

Stan obiektowej bazy danych jest zbiorem kolekcji trwałych i rozróżnialnych obiektów.

Obiekt jest podstawową jednostką danych składowanych w obiektowej bazie danych. W przeciwieństwie do obiektów przetwarzanych w zwykłych programach obiektowych, obiekty utworzone przez aplikacje obiektowych baz danych są autonomiczne w stosunku do tych aplikacji i trwałe. Autonomia obiektów polega na możliwości istnienia obiektu poza programem, który go utworzył. Natomiast trwałość oznacza, że czas życia obiektu jest dłuższy niż czas życia zmiennej, której był przypisany w momencie utworzenia. Aplikacja, która utworzyła obiekt może zostać wyłączona, a utworzone przez nią trwałe obiekty będą pamiętane w bazie danych.

Schemat obiektowej bazy danych jest zbiorem klas, które definiują strukturę i funkcjonalność obiektów.

W obiektowych bazach danych rozróżnia się pojęcie klasy jako definicji własności obiektów od pojęcia rozszerzenia klasy będącego zbiorem trwałych obiektów.

25

class Figura { // nazwa klasy jako typu (extent Figury) // nazwa rozszerzenia klasy jako zbioru wystąpień Struktura i funkcjonalność obiektów bazy danych jest zdefiniowana za pomocą klas. Zbiór definicji klas tworzy schemat bazy danych. W przeciwieństwie do systemów relacyjnych, gdzie relacja pełniła jednocześnie rolę definicji struktury danych oraz zbioru wszystkich danych o tej strukturze, w obiektowych bazach danych te role są rozdzielone. Zbiór trwałych wystąpień danej klasy tworzy tak zwane rozszerzenie klasy. Np. „Figura” jest nazwą klasy definiującej własności obiektów, a „Figury” są nazwą rozszerzenia, które jest zbiorem wszystkich trwałych wystąpień klasy „Figura”.

Abstrakcyjne typy danych Relacyjne bazy danych oferują projektantowi schematu bazy danych ograniczony zbiór prostych, predefiniowanych typów danych dla atrybutów relacji. Przykładem mogą być systemowe typy tekstowe: varchar i char, numeryczne: int i float oraz temporalne: date. Typy danych niedostępne w relacyjnym modelu danych muszą być implementowane poza systemem bazy danych. Kod obsługujący ich semantykę musi być implementowany i powielany we wszystkich aplikacjach bazy danych. Obiektowe bazy danych umożliwiają projektantom definiowanie nowych typów danych. Definiowanie własnego typu danych obejmuje definicję struktury i funkcjonalności typu. Definicje typów są składowane w systemie bazy danych. Sposób korzystania z typów danych zdefiniowanych przez użytkownika nie różni się niczym od korzystania z typów systemowych.

26

Dzięki temu obiektowy model danych jest rozszerzalny. Można go elastycznie dopasowywać do dowolnej dziedziny zastosowania wymagającej unikalnych, specyficznych typów danych. Rolę typów danych definiowanych przez użytkownika pełnią w obiektowych bazach danych klasy i interfejsy. Definicja interfejsu jest opisem funkcjonalności nowego typu danych, czyli opisem operacji dostępnych dla danego typu. Definicja klasy obejmuje dodatkowo implementację typu danych: to jest wewnętrzną strukturę danych służącą do przechowywania stanu wystąpień typu danych oraz kod operacji zdefiniowanych dla danego typu danych.

W zaprezentowanym przykładzie zdefiniowano dwa typy danych użytkownika: klasy Punkt i Odcinek. Część strukturalna klasy Punkt to dwa atrybuty X i Y reprezentujące lokalizację punktu na płaszczyźnie. Część funkcjonalna tej klasy jest

ograniczona do metody przesuń służącej do zmiany lokalizacji punktów. Klasa Punkt została wykorzystana jako typ danych dla atrybutów W1 i W2 klasy Odcinek. Wystąpienia klasy Punkt będą wartościami tych atrybutów. Klasa Odcinek służy do definiowania typu obiektów składowanych w bazie danych. Metoda przesuń jest zaimplementowana jako sekwencja wykonania operacji przesunięcia dla dwóch końców W1 i W2 danego odcinka.

27

Dziedziczenie W obiektowych bazach danych można definiować nowe klasy i interfejsy wywodząc je ze zdefiniowanych wcześniej klas lub interfejsów. Model ODMG rozróżnia dwa typy powiązań między klasami lub interfejsami: związek relacji podtypu i związek dziedziczenia. W językach obiektowych te dwa związki są traktowane jako tożsame.

Związek relacji podtypu może dotyczyć klas i interfejsów. Oznacza on dziedziczenie przez typ pochodny funkcjonalności typu bazowego. Klasy i interfejsy połączone związkiem podtypu tworzą sieć powiązań o topologii grafu acyklicznego skierowanego. Oznacza to, że pojedyncza klasa lub interfejs może dziedziczyć funkcjonalność po wielu klasach lub interfejsach. Związek dziedziczenia łączy jedynie klasy. Oznacza on dziedzicznie zarówno funkcjonalności jak i implementacji. Związek dziedziczenia obejmuje semantykę relacji podtypu. Klasy połączone związkiem dziedziczenia tworzą sieć powiązań o topologii hierarchii. Oznacza to, że pojedyncza podklasa może dziedziczyć zarówno funkcjonalność jak i implementację po dokładnie jednej nadklasie. Dziedziczona funkcjonalność może być rozszerzona w stosunku do typu bazowego. Dziedziczona implementacja może być rozszerzana lub przesłaniana. Przez przesłaniane rozumie się definicje nowego kodu dla odziedziczonych metod, który zastąpi stary kod.

28

Przedstawiony na rysunku przykład pokazuje dwa alternatywne rozwiązania. W pierwszym klasa Wielokąt dziedziczy po klasie Figura funkcjonalność i implementację, w drugim klasa Wielokąt przez relację podtypu dziedziczy funkcjonalność bez implementacji.

Złożone struktury danych Kolejnym ograniczeniem przełamanym przez obiektowy model danych jest możliwość przechowywania w bazie danych, obiektów o złożonej strukturze. Elementem standardów ODMG i SQL3 jest bogaty zbiór konstruktorów złożonych typów danych. Kompletna lista obejmuje konstruktory: krotki, zbioru, wielozbioru, listy, tablicy i słownika. Konstruktory złożonych typów danych mogą być wielopoziomowo zagnieżdżane. Przykład na slajdzie pokazuje transformację do schematu obiektowej bazy danych klasy Wielokąt o atrybucie wielowartościowym i złożonym. Atrybutem klasy Wielokąt jest zbiór Odcinków, z których każdy jest strukturą pary Punktów, które z kolei są strukturą pary współrzędnych. W przykładzie zastosowano dwa typy konstruktorów typów złożonych w języku ODL: konstruktora krotki – „struct” i konstruktora zbioru – „set”.

29

Związki między danymi Obiektowy model danych pozwala na definiowanie i składowanie w bazie danych związków między danymi.

Obiektowy model danych pozwala na jawną reprezentację związków między danymi. W przeciwieństwie do relacyjnego modelu danych, gdzie związki są ustalane w sposób dynamiczny w momencie wykonywania zapytań, a dokładniej operacji połączenia (ang. join), w obiektowym modelu danych związki są pamiętane w bazie danych. Podczas przetwarzania powiązanych danych dostępna jest operacja nawigacji wzdłuż tych powiązań. W modelu ODMG przyjęto dodatkowo, że wszystkie związki są dwukierunkowe, co oznacza, że dla powiązanych obiektów A i B możliwa jest nawigacja od obiektu A do obiektu, jak i na odwrót, od obiektu B do obiektu A. Model obiektowy nie stawia ograniczeń na krotność związku. Dozwolone są powiązania jednokrotne i wielokrotne. Na rysunku pokazano przykład związku łączącego klasę Obraz z klasą Osoba, które je utworzyły. Obiekty obydwu tych klas przechowują informacje o obiektach, z którymi są powiązane. Po stronie osób związek ten nosi nazwę: „jest_autorem”, a po stronie obrazów: „jest_utworzony_przez”. Po obydwu stronach jest to powiązanie wielokrotne.

30

Pojedyncza osoba może być autorem wielu obrazów, a pojedynczy obraz może mieć wielu autorów. Wartością związku „jest_autorem” jest zbiór identyfikatorów obiektów, które reprezentują obrazy utworzone przez daną osobę. Analogicznie wartością związku „jest_utworzony_przez” jest zbiór identyfikatorów obiektów, które reprezentują osoby będące autorami danego obrazu.

Hierarchia kolekcji obiektów

Związek dziedziczenia lub czysta relacja podtypu łączące klasy definiuje relację podzbiorów między ich rozszerzeniami. Rozszerzenie klasy pochodnej jest podzbiorem rozszerzenia klasy bazowej. Rozszerzenie klasy bazowej obejmuje rekurencyjnie obiekty należące do wszystkich rozszerzeń bezpośrednich i pośrednich klas pochodnych. Relacja ta pozwala na przetwarzanie heterogenicznych zbiorów obiektów. Operacje wykonywane na rozszerzeniu klasy bazowej są automatycznie propagowane na rozszerzenia wszystkich klas pochodnych. Na rysunku jest to zilustrowane przykładem relacji podzbioru łączącej rozszerzenie „Figury” klasy „Figura” z rozszerzeniem „Wielokąty” klasy „Wielokąt”. Operacje wykonywane na zbiorze wystąpień klasy „Figura” będą wykonywane również na wystąpieniach klasy „Wielokąt”.

31

Polimorfizm i późne wiązanie Relacja podtypu łącząca klasy i interfejsy umożliwia podstawienia polimorficzne polegające na podstawieniu pod zmienną typu klasy bazowej obiektu, który jest wystąpieniem klasy pochodnej. Podstawienia polimorficzne umożliwiają dynamiczne wiązanie nazw metod.

O obiektach składowanych w rozszerzeniach klas, które mają klasy pochodne mówi się, że są polimorficzne, bo mają różne cechy i metody. Na przykład wystąpienia klasy Figura mają określony atrybut „Typ” służący do przechowywania informacji o typie figury oraz metodę „Powierzchnia” służącą do wyznaczania powierzchni figur. Z kolei wystąpienia klasy pochodnej „Wielokąt” oprócz odziedziczonego atrybutu „Typ” mają dodatkowo wielowartościowy atrybut „Krawędzie”. Odziedziczona po klasie „Figura” metoda „Powierzchnia” jest w klasie „Wielokąt” redefiniowana ponieważ sposób wyznaczania powierzchni wielokątów jest inny niż uniwersalnych figur. Rozszerzenie klasy „Figura” obejmuje zarówno obiekty klasy „Figura”, jak również różniące się od nich obiekty, które są wystąpieniami klasy „Wielokąt”. Na poziomie składni języków obiektowych polimorfizm obiektów wyraża się w występowaniu zmiennych polimorficznych i podstawień polimorficznych. Przez zmienną polimorficzną rozumie się taką zmienną, pod którą są podstawiane obiekty, które są wystąpieniami różnych klas, ale które występują w relacji podtypu z typem zmiennej polimorficznej.

32

W podanym przykładzie, zmienną polimorficzną jest zmienna „f”. Mimo, że typem zmiennej „f” jest klasa „Figura”, to przypisywane są jej obiekty innych klas. Najpierw pod zmienną „f” jest podstawiony obiekt typu „Koło”, a później obiekt typu „Wielokąt”. Następnie przez zmienną „f” do przypisanych jej obiektów są przesyłane komunikaty o nazwie „Powierzchnia”. Właściwy kod metody wyznaczania powierzchni jest ustalany dynamicznie na podstawie typu obiektu przypisanego w danym momencie zmiennej „f”. W pokazanym przykładzie najpierw jest to kod metody „Powierzchnia” zdefiniowanej w klasie „Koło”, następnie kod metody „Powierzchnia” klasy „Wielokąt”.

Tożsamość danych w językach programowania W obiektowych językach programowania dane są identyfikowane przez symboliczną nazwę zmiennej oraz fizyczny adres w pamięci, który odpowiada tej zmiennej w programie wykonywalnym.

Dostęp do danych w bazie danych z poziomu aplikacji bazy danych wymaga mechanizmu identyfikacji danych. Programista musi dysponować jakimiś środkami wyrazu, które pozwolą mu wskazać te dane, które chce przetwarzać. Dostęp do danych lokalnych programów jest realizowany poprzez zmienne przypisane przetwarzanym danym. Nazwy zmiennych są środkiem jednoznacznej identyfikacji danych. W danej części programu nazwy zmiennych muszą być unikalne. W przedstawionym przykładzie zmienna o nazwie Nowak jednoznacznie określa podstawiony pod nią obiekt, który jest wystąpieniem klasy Osoba. Przesyłanie komunikatów do tego właśnie obiektu wymaga użycia nazwy zmiennej.

33

W wykonywalnej postaci programów nazwy zmiennych są transformowane do adresów w pamięci operacyjnej, pod którymi obiekty zostaną ulokowane. W przykładzie symboliczna nazwa Nowak zostaje zamieniona na adres pamięci operacyjnej 0c78:89ad.

Tożsamość danych w relacyjnym modelu danych W modelu relacyjnym dane są identyfikowane przez ich wartości. Jednoznaczna identyfikacja danych wymaga zdefiniowania dla każdej relacji – klucza podstawowego.

Cechą relacyjnego modelu danych jest identyfikacja danych poprzez wartość. W przeciwieństwie do danych przetwarzanych w proceduralnych językach programowania, pojedyncze krotki w bazie danych nie mają przypisanych żadnych symbolicznych nazw. Przez nazwę identyfikowalne są jedynie całe relacje. Również fizyczna lokalizacja krotek w pamięci dyskowej nie jest podstawą do ustalenia ich tożsamości. Fizyczna reorganizacja danych może się bowiem wiązać z realokacją krotek w pamięci dyskowej. Jedyną cechą danych do której można się odwołać wyszukując ich w bazie danych są ich wartości. Zapytania w relacyjnych bazach danych wyrażane w języku SQL opierają się na wyrażeniach logicznych odwołujących się do wartości wybranych atrybutów krotek. Pokazuje to przykład na slajdzie, w którym w zbiorze Płatników są wyszukiwane osoby, dla których wartość atrybutu Nazwisko jest równa stałej tekstowej „Nowak”. W sytuacji gdy atrybuty, do których odwołuje się zapytanie nie mają cechy unikalności identyfikacja poprzez wartość nie jest jednoznaczna.

34

W podanym przykładzie, aż trzy osoby noszą nazwisko Nowak. Dla jednoznacznej identyfikacji danych schematy relacji muszą posiadać atrybuty o własności klucza podstawowego. Dopiero odwołanie się w zapytaniu do wartości klucza podstawowego gwarantuje jednoznaczność identyfikacji i pozwala na dostęp do pojedynczych krotek.

Tożsamość danych w obiektowej bazie danych W obiektowych bazach danych wprowadzono nowy mechanizm identyfikacji danych. Obiekty są identyfikowane za pomocą systemowego identyfikatora OID. Jest to dodatkowy atrybut każdego obiektu, którego wartości są generowane i utrzymywane w sposób transparentny dla użytkowników przez system zarządzania bazą danych. Wartość tego atrybutu jest generowana w momencie tworzenia każdego obiektu i niemodyfikowalna w ciągu całego życia obiektu. Identyfikacja przez OID jest niezależna od wartości atrybutów obiektu Identyfikatory obiektów są wykorzystywane do implementacji związków między obiektami. Powiązane obiekty pamiętają nawzajem swoje identyfikatory.

Na przykładzie zilustrowano własności identyfikatorów obiektów. Identyfikator obiektu reprezentującego osobę Jana Kowalskiego został zapamiętany w obiekcie reprezentującym żonę Kowalskiego Janinę Kowalską. Mimo zmiany wartości kluczowych atrybutów obiektu, takich jak nazwisko, numer PESEL i płeć, obiekt reprezentujący byłego Kowalskiego nie zmienił swojej tożsamości określonej za pomocą jego identyfikatora.

35

Trwałość danych

Obiekty mogą być tworzone w trwałym lub ulotnym obszarze składowania.

Trwałość powinna być własnością poszczególnych obiektów, a nie klas obiektów.

Trwałość powinna być własnością obiektów dowolnej klasy.

Sposób operowania na obiektach trwałych i ulotnych powinien być taki sam.

Obiekty w ciągu cyklu życia mogą być przenoszone między trwałym i nietrwałym obszarem składowania.

W obiektowych bazach danych powstałych jako rozwinięcie języków obiektów jest potrzebny dodatkowy mechanizm utrwalania w bazie danych wybranych obiektów tworzonych przez obiektowe aplikacje bazy danych. W świecie systemów relacyjnych programiści tworzący aplikacje bazy danych muszą korzystać z dwóch języków o diametralnie różnej filozofii. Po pierwsze z języka dostępu do trwałych danych składowanych w bazie danych, na przykład języka SQL i po drugie z języka służącego do budowy funkcjonalności i interfejsu aplikacji. Jednym z celów budowy obiektowych baz danych była jednorodność języka służącego do pisania logiki przetwarzania aplikacji i dostępu do bazy danych. Aby ten cel osiągnąć poszukiwane rozwiązania muszą spełniać pięć podstawowych wymagań.

1) Pierwszym wymaganiem jest by aplikacje baz danych mogły równolegle tworzyć i przetwarzać zarówno zwykłe nietrwałe lokalne obiekty aplikacji, jak i obiekty trwałe, składowane w bazie danych.

2) Drugie wymaganie postuluje by własność trwałości dotyczyła pojedynczych obiektów, a nie całych klas obiektów. Oznacza, to że wystąpienia tej samej klasy mogą być zarówno trwałe jak i nietrwałe. Wymaganie to istotnie różni modele obiektowy i relacyjny. W modelu relacyjnym równolegle funkcjonują dwa systemy typów danych to jest trwałe relacje i lokalne dane aplikacji.

36

3) Trzecie wymaganie ma pozwolić by można było tworzyć trwałe wystąpienia dowolnych klas definiowanych przez użytkowników, a nie tylko wyróżnionych klas systemowych. W praktyce, klasy dla których chcemy tworzyć trwałe wystąpienia, muszą być wywiedzione z wyróżnionych klas systemowych o dodatkowej wymaganej funkcjonalności.

4) Czwarte wymaganie postuluje by konstrukcje języka obiektowego zastosowanego do budowy aplikacji bazy danych nie rozróżniały obiektów trwałych i nietrwałych. To znaczy, że sposób przetwarzania trwałych i nietrwałych wystąpień tej samej klasy ma być taki sam.

5) Ostatnim wymaganiem jest by obiekty w ciągu swojego życie mogły wielokrotnie przechodzić między trwałym i nietrwałym obszarem składowania.

Obiekty stają się trwałe przez jawne utrwalenie lub przez bycie osiągalnymi przez inne obiekty trwałe.

W rozwiązaniach wypracowanych przez standardy ODMG i JDO wyróżnia się dwie klasy obiektów trwałych. Do pierwszej klasy należą obiekty, które stają się trwałe poprzez bezpośrednie wywołanie wyspecjalizowanej metody systemowej przesuwającej dany obiekt lub zbiór obiektów z nietrwałego do trwałego obszaru składowania. Na rysunku przykładem takiego obiektu jest obiekt „o1”.

37

Do drugiej klasy należą obiekty, które są utrwalane w sposób pośredni, przez powiązanie ich z obiektami trwałymi. Obiekty należące do tej klasy są tak długo trwałe, jak długo są osiągalne z obiektów trwałych. Przykładem obiektu należącego do tej klasy trwałości jest obiekt „o2”. Tymczasem obiekt „o3”, który przez jakiś czas był trwały, w wyniku usunięcia powiązania z obiektem „o2” zostaje przesunięty do nietrwałego obszaru składowania. Jeżeli dodatkowo obiekt ten przestanie być osiągalny przez tymczasowe zmienne aplikacji bazy danych, zostanie z czasem usunięty przez systemowe procesy oczyszczania bazy danych. W przedstawionym kodzie wykorzystano rozwiązania wypracowane w standardzie JDO. Obiekty „p” i „k” są w momencie utworzenia nietrwałe. Metoda systemowa „MakePersistent” przenosi obiekt „k” do bazy danych. Obiekt „k” należy do pierwszej klasy trwałości. Obiekt „p” zostanie również utrwalony przez związek łączący go z obiektem „k”. Obiekt „p” należy do drugiej klasy trwałości.

38

Podsumowanie cech relacyjnych i obiektowych modeli danych

Elementy relacyjnego modelu danych Podstawowe składowe: relacje odpowiadające zarówno typom encji (entity), jak i typom związków (relationship); wiersze (krotki, rekordy) reprezentujące egzemplarze (wystąpienia) encji i związków; kolumny reprezentujące atrybuty; zbiór wartości, które można umieszczać w danej kolumnie, nazywa się jej dziedziną; relacja jest fizycznie reprezentowana jako tabela, tj. zbiór rekordów; rekordy są ze sobą wewnętrznie powiązane za pomocą związków zachodzących między danymi. W modelu relacyjnym operacje na danych opisuje się za pomocą: - algebry relacji; - rachunku relacji (specjalizacja rachunku predykatów pierwszego rzędu). W praktyce używa się języka SQL łączącego obie te metody. Google: wyklad_obiektowe bazy danych, język zapytań

Zalety relacyjnych baz danych - struktury danych nie zależą od konkretnego języka programowania (dane w postaci tabel rekordów); - sprawdzone, dobrze zdefiniowana teoria; - możliwość zarządzania wielką ilością danych; - możliwość złożonych kryteriów wyszukiwawczych; - możliwość dostępu do danych fizycznych;

39

- dobre mechanizmy kontroli dostępu do danych; - mechanizm perspektyw.

Wady relacyjnych baz danych Zorientowane na rekordy (dziedzictwo implementacyjne). Konieczność wcześniejszego określenia ,,schematu” bazy danych, dopiero potem można coś do bazy wstawiać. Nie można wstawiać danych nie pasujących do schematu, oficjalnie nie wolno dodawać nowych atrybutów. Za słaby do reprezentacji wiedzy: tylko jedna konstrukcja (tabela), atomowe atrybuty. 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), konieczność mapowania ORM.

Zastosowania relacyjnych baz danych:

przeznaczone dla systemów, w których dane są proste, niezagnieżdżone i łatwe do umieszczenia w tablicy;

dane mają postać bierną, a procesy korzystające z danych stele się zmieniają;

często trzeba wyszukiwać dane spełniające różnorodne warunki.

40

Elementy obiektowego modelu danych W językach programowania obiekt jest to kontener zawierający pewien zbiór wartości (atrybutów) oraz zbiór specyficznych operacji, umożliwiających zmianę stanu obiektów (wartości atrybutów). Obiekty posiadają swoje nazwy, aby można było się do nich odwoływać i wykonywać któreś z ich operacji. Obiekty mogą się do siebie odwoływać: - obiekty elementarne odwołują się tylko do swoich klas; - obiekty złożone odwołują się (zależą) także do innych obiektów. Model obiektowy jest modelem danych, którego podstawą są pojęcia obiektowości wywodzące się z języków programowania, m.in.: obiekt, klasa, dziedziczenie, hermetyzacja, Prace nad ustandaryzowaniem pojęć obiektowych w dziedzinie baz danych prowadzone były m.in.: przez ODMG (ang. Object Database Management Group). Standard zaproponowany przez ODMG stworzony został w oparciu o trzy istniejące standardy dotyczące: • baz danych (SQL-92), • obiektów (OMG), • obiektowych języków programowania (ANSI). Podobnie jak w językach programowania podstawą modelu jest obiekt, z którym związany jest jego stan i zachowanie. Stan obiektu definiuje się za pomocą wartości jego atrybutów, które mogą być: - wartościami elementarnymi (np. liczby, teksty); - obiektami innych typów (obiekty złożone). Zachowanie obiektu definiuje się za pomocą zbioru metod, czyli procedur działających na jego atrybutach.

41

Każdy obiekt jest jednoznacznie identyfikowany systemowym identyfikatorem (OID). Obiekty muszą mieć własność hermetyzacji, tj. dane i metody są chronione z razem w ramach jednego interfejsu i udostępniane z zewnątrz w sposób kontrolowany. Obiekt jest instancją klasy – typu definiującego strukturę obiektów danej klasy. W niektórych modelach obiekt może być egzemplarzem wielu klas. Obiekty złożone można definiować za pomocą obiektów prostych. Klasy łączy się w hierarchie dziedziczenia, w których podklasa dziedziczy własności i metody z nadklasy, i jednocześnie dodaje swoje specyficzne atrybuty i metody. W niektórych modelach możliwe jest przesłanianie, tj. zmianę odziedziczonej własności lub metody. Komunikacja między obiektami odbywa się za pomocą przekazywania komunikatów: tj. mechanizmu przekazywania danych lub wywoływania czynności między obiektami.

Zalety obiektowych baz danych - ł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++, Java, C#); - ujednolicony model pojęciowy (obiektowe podejście do analizy, projektowania i implementacji);

42

Wady obiektowych baz danych 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.

Zastosowania obiektowych baz danych:

Przeznaczone dla systemów, w których dane mają złożoną lub zagnieżdżoną strukturę zdefiniowaną przez użytkownika.

Dane tworzą hierarchie.

Dane są rozproszone w sieci heterogenicznej.

Dane dynamicznie zmieniają rozmiar.

43

Wykład 9. Bezpieczeństwo rozproszonych baz danych

9.1. Metody uwierzytelniania podmiotów 9.2. Szyfrowanie danych w bazach danych 9.3. System certyfikatów PKI 9.4. Bezpieczna komunikacja – protokół SSL 9.5. Bezpieczna komunikacja: protokół Needham-Schroeder symetryczny (uproszczony Kerberos).

44

Metody uwierzytelniania podmiotów Podmiot – użytkownik, urządzenie, usługa, aplikacja, wymagająca bezpiecznej komunikacji. Uwierzytelnianie (authentication) – proces sprawdzania, czy podmiot jest tym za kogo się podaje; inaczej weryfikacja tożsamości, poświadczanie tożsamości. Podmioty – głównie urządzenia i użytkownicy systemów komputerowych (ludzie). W aspekcie technicznym, problem uwierzytelniania dotyczy: - uwierzytelniania maszyny przez maszynę - uwierzytelniania człowieka przez maszynę. Metody poświadczania tożsamości: słabe: oparte o adres sieciowy lub hasło; silne: oparte o dodatkowe urządzenia, mechanizmy i protokoły; - biometryczne (odcisk palca, rozkład naczyń, skan siatkówki oka); - oparte o tokeny, sms, hasła jednorazowe; - kryptograficzne:

szyfrowanie liczb losowych z wykorzystaniem algorytmów symetrycznych lub asymetrycznych; zastosowanie certyfikatów kluczy publicznych.

45

W przypadku hasła przechowywanie i przesyłanie jego postaci zakodowanej za pomocą: - jednokierunkowej funkcji haszującej; - uzupełnianie hasła liczbą losową znaną właścicielowi hasła (tzw. solą) i przechowywanie (przesyłanie) haszu ze zmodyfikowanego hasła; - kodowanie hasła poprzez szyfrowanie algorytmem symetrycznym (np. DES, instrukcja crypt() Unix).

Szyfrowanie informacji w systemach rozproszonych Do szyfrowania krótkich wiadomości można użyć algorytmów kryptografii asymetrycznej, np. RSA, ElGamala, np. wiadomości poczty elektronicznej PGP. Zastosowanie algorytmów kryptografii asymetrycznej wiąże się z koniecznością potwierdzania źródła pochodzenia kluczy publicznych. Jednym z rozwiązań jest zastosowanie certyfikatów kluczy publicznych X.509 oraz infrastruktury klucza publicznego PKI wykorzystywanej do obsługi certyfikatów. Do zabezpieczania informacji w bazach danych wykorzystuje się głównie algorytmy kryptografii symetrycznej: DES, 3DES, AES. Przed zapisem dane szyfruje się z użyciem klucza tajnego. W momencie odczytu są one deszyfrowane tym samym kluczem. Np. W systemie baz danych MySQL 5.0 dostępne są następujące funkcje szyfrujące - AES_ENCRYPT(kolumna_lub_wyraz, klucz) - szyfruje słowo kluczem; - AES_DECRYPT(kolumna_lub_wyraz, klucz) - odszyfrowuje słowo kluczem; - ENCODE(kolumna_lub_wyraz, ’treść_hasła’) – szyfruje słowo hasłem: - DECODE(kolumna_lub_wyraz, ’treść_hasła’) – odszyfrowuje słowo hasłem;

46

Certyfikat klucza publicznego wykorzystujący standard X.509 Podstawowy problem – upewnienie się, że klucz publiczny danego podmiotu rzeczywiście pochodzi od tego podmiotu. Aby wyeliminować możliwość podstawienia fałszywego klucza publicznego danego podmiotu (podszycia się pod kogoś) zaprojektowano system certyfikatów klucza publicznego (PKI – Public Key Infrastructure). Certyfikat jest to zbiór danych jednoznacznie identyfikujących dany podmiot (np. osobę, komputer) oraz pozwalający stwierdzić, czy ten podmiot, który legitymuje się tym certyfikatem jest rzeczywiście tym za kogo się podaje. Certyfikaty podmiotów są potwierdzane przez zaufane organizacje nazywane Urzędami Certyfikacji (Certyficate Authority – CA). Przykładowe centra certyfikujące CA: - Comodo CA, - GeoTrust CA, - Signet CA, - Entrust CA, - Thawte CA, - VeriSign CA. Certyfikat ma postać cyfrową – elektroniczną (certyfikat cyfrowy). Fizycznie jest to ciąg danych, zapisanych na odpowiednim nośniku (np. dysku, pamięci USB) w postaci pliku. Certyfikat stanowi rodzaj elektronicznego zaświadczenia, które zawiera dane umożliwiające weryfikację przynależności klucza publicznego do danego podmiotu (np. certyfikat serwera banku, wykorzystywany do bezpiecznej komunikacji internetowej w oparciu o protokół SSL). Źródło: www.signet.pl; Jeden z głównych systemów certyfikacji opiera się o standard X.509. Certyfikat X.509 zawiera ciąg danych podpisanych cyfrowo przez określone CA, które wystawiło ten certyfikat. Aby zweryfikować autentyczność certyfikatu wystawionego przez dane CA, należy znać klucz publiczny tego CA (weryfikacja podpisu cyfrowego CA).

47

Klucz taki znajduje się na certyfikacie wystawionym dla CA przez jego nadrzędny organ certyfikujący, czyli nadrzędne CA. Zatem weryfikacja certyfikatu polega na prześledzeniu łańcucha zaufania od certyfikatu, poprzez pośrednie, nadrzędne centra CA, aż do głównego CA, cieszącego się powszechnym zaufaniem, które jako jedyne wystawia certyfikat sam dla siebie, tj. podpisuje go swoim kluczem prywatnym.

Łańcuch zaufania dla certyfikatu CERT: CERT -> CA1 -> CA2 -> ... -> CAG_główne Centra certyfikacji CA, wystawiające i sprzedające certyfikaty cyfrowe płacą za to, aby ich certyfikaty nadrzędne (root) zostały dodane do systemowej bazy certyfikatów w popularnych systemach operacyjnych (Windows, Linux, MacOS), przez co certyfikaty takie stają się zaufane dla użytkowników sieci Internet. W praktyce przeglądarki internetowe rozpoznają i akceptują wystawiane przez te CA certyfikaty bez dodatkowych zapytań kierowanych do użytkowników (objawia się to zieloną kłódeczką w przeglądarce). Najważniejsze informacje zawarte w certyfikacie X.509 (pola zapisane w postaci znaków ASCII): 1) Identyfikator wersji certyfikatu 2) Numer seryjny certyfikatu 3) Algorytm podpisu 4) Wystawca certyfikatu 5) Okres ważności od ... do 6) Nazwa właściciela certyfikatu (podmiot) 7) Klucz publiczny 8) Rozszerzenia: dodatkowe informacje, np. regulaminy certyfikacji, zasady użycia i zastosowanie klucza, punkty dystrybucji unieważnionych certyfikatów (CRL) i inne. 9) Podpis cyfrowy wystawcy certyfikatu Certyfikaty pod Windows - uruchom: certmgr.msc . Mogą być różne klasy certyfikatów w zależności od celu, do którego mają służyć (np. VeriSign): Class 1 – dla podmiotów (osób) prywatnych, z przeznaczeniem dla poczty email.

48

Class 2 – dla organizacji, od których wymagane jest poświadczanie tożsamości. Class 3 – dla serwerów i oprogramowania, zarządzającego certyfikatami kluczy publicznych wystawianymi przez CA. Class 4 – dla transakcji biznesowych pomiędzy firmami. Class 5 – dla zapewniania bezpieczeństwa organizacji prywatnych i rządowych. Zastosowanie kryptografii klucza publicznego wymaga sprawnie działającej infrastruktury PKI. Infrastruktura PKI służy do zarządzania cyfrowymi certyfikatami i kluczami szyfrującymi podmiotów (osób, programów i systemów). Większość najważniejszych systemów bezpieczeństwa teleinformatycznego współpracuje z PKI. Są to m.in.: SSL (Secure Socket Layer), TLS , SMIME (Secure Multipurpose Internet Mail Extensions), SET (Secure Eletronic Transactions), IPSec (IP Security). Infrastruktura PKI jest wykorzystywana w: - bezpiecznej poczcie e-mail, - transakcjach typu e-commerce (handel elektroniczny), - wirtualnych sieciach prywatnych (Virtual Private Network - VPN), - systemach ERP, - zabezpieczeniach stacji roboczej użytkownika (m.in. zawartych na niej danych), - zapewnieniu bezpieczeństwa witryn internetowych, urządzeń i aplikacji klienta.

Struktura PKI składa się z trzech głównych elementów: Urzędów Rejestracji (ang. Registration Authority - RA), dokonujących

weryfikacji danych użytkownika a następnie jego rejestracji. Urzędów Certyfikacji (ang. Certification Authority - CA), wydających

certyfikaty cyfrowe. Jest to poprzedzone procesem identyfikacji zgłaszającego się o wydanie certyfikatu. Pozytywne rozpatrzenie zgłoszenia kończy się wydaniem certyfikatu.

49

Repozytoriów kluczy, certyfikatów i list unieważnionych certyfikatów (ang.

Certificate Revocation Lists - CRLs). Typowa implementacja to umożliwienie, w oparciu o protokół LDAP, dostępu do certyfikatów i CRLs. Inne sposoby realizacji mogą być oparte na protokołach X.500, HTTP, FTP i poczcie elektronicznej.

Certyfikat może stać się nieważny przed datą jego wygaśnięcia, ze względu np. na zmianę nazwiska lub adresu poczty elektronicznej użytkownika, czy ujawnienie klucza prywatnego. W takich przypadkach CA odwołuje certyfikat i umieszcza jego numer seryjny na ogólnodostępnej liście CRL.

Struktura PKI jest tworzona w oparciu o Główne Urzędy CA. Dla każdego z obszarów zastosowań (np. handel elektroniczny, sektor bankowo-finansowy, administracja publiczna), można tworzyć odrębne CA, podległe Głównemu Urzędowi. Główne CA określa ogólną politykę certyfikacji, natomiast CA, obsługujące dany obszar zastosowań, odpowiada za jego politykę w tym zakresie. Może istnieć dowolna liczba CA, podległych głównemu Urzędowi CA, oraz dowolna liczba użytkowników. Taka struktura tworzy hierarchię uwierzytelniania, która z kolei określa łańcuch certyfikatów, wiodący od użytkowników aż do cieszącego się ich zaufaniem Głównego CA. Krajowa struktura PKI musi współdziałać ze strukturami PKI innych krajów, by zapewnić usługi o podobnym charakterze w kontaktach międzypaństwowych.

50

Podstawowe funkcje PKI Rejestracja (ang. Registration)

Użytkownik końcowy składa wniosek do Organu Rejestracji o wydanie

certyfikatu. W tym celu dostarcza szereg informacji, wymaganych przez Kodeks Postępowania Certyfikacyjnego (Certification Practices Statement - CPS) danego CA. Dane te to np. nazwa własna podmiotu lub osoby wnioskującej o certyfikat, nazwa domenowa czy adres IP. Przed wystawieniem certyfikatu CA potwierdza (korzystając z wytycznych zapisanych w CPS) zgodność z prawdą danych, podanych przez użytkownika. Jeżeli o certyfikat ubiega się osoba fizyczna, CA weryfikuje także autentyczność własnoręcznego podpisu na wniosku o wydanie certyfikatu. Certyfikacja (ang. Certification)

Jeżeli dane, podane przez ubiegającego się o certyfikat, zostaną

potwierdzone, CA wystawia nowy certyfikat (zawierający m.in. klucz publiczny posiadacza) i dostarcza go użytkownikowi. Jednocześnie klucz publiczny zostaje udostępniony wszystkim zainteresowanym poprzez złożenie go we właściwym repozytorium. Generacja kluczy (ang. Key generation)

Para kluczy (prywatny i publiczny) może zostać wygenerowana

samodzielnie przez użytkownika końcowego, może on także powierzyć tę operację CA. W pierwszym przypadku użytkownik przesyła do CA jedynie swój klucz publiczny, w celu poddania go procesowi certyfikacji. Klucz prywatny pozostaje przez cały czas w rękach właściciela, dlatego też metodę tę uważa się za najbardziej bezpieczną. Jeżeli klucze generuje CA, są one dostarczane do użytkownika końcowego w sposób gwarantujący ich poufność, Wykorzystuje się do tego m.in. celu karty mikroprocesorowe (ang. smartcard), karty PCMCIA lub tokeny USB, zabezpieczone dodatkowym kodem PIN.

51

Odnawianie kluczy (ang. Key update) Wszystkie pary kluczy oraz skojarzone z nimi certyfikaty wymagają

okresowego odnawiania. Jest to kolejne zabezpieczenie na wypadek ujawnienia klucza prywatnego skojarzonego z kluczem publicznym umieszczonym na certyfikacie. Wymiana kluczy jest konieczna, gdy:

- Upłynął okres ważności certyfikatu. Jest to sytuacja normalna, występująca regularnie co pewien czas (np. raz do roku). Odbywa się w możliwie krótkim czasie, bez dodatkowych formalności. - Klucz prywatny, skojarzony z umieszczonym na certyfikacie kluczem publicznym, został skompromitowany. Jest to sytuacja wyjątkowa, a więc wymiana kluczy nie będzie już tak płynna i łatwa. W takich przypadkach CA odwołuje certyfikat poprzez umieszczenie jego numeru seryjnego na ogólnodostępnej liście CRL. Od tego momentu stary certyfikat traci ważność i rozpoczyna się procedura wystawiania nowego certyfikatu. Najgorszy przypadek dla każdego CA to kompromitacja klucza prywatnego jego Głównego CA (Root CA). W takim przypadku cała infrastruktura PKI podległa temu CA zostaje uznana za skompromitowaną i musi być tworzona od nowa. Certyfikacja wzajemna (ang. Cross-certification)

Ponieważ społeczność międzynarodowa nie stworzyła dotąd Globalnego

Organu Certyfikacji (Global Root CA), powstało wiele Głównych Organów Certyfikacji (Root CA), początkowo nie powiązanych relacjami zaufania. Certyfikacja wzajemna rozwiązuje ten problem i pozwala użytkownikom z jednej struktury PKI ufać certyfikatom wystawianym przez CA z innej struktury. Główne CA z różnych struktur certyfikują się wzajemnie - może być to certyfikacja jednokierunkowa albo dwukierunkowa. Odwołanie certyfikatu (ang. Revocation)

Istnieją sytuacje, w których zachodzi potrzeba wcześniejszego odwołania certyfikatu. Powodem może być kompromitacja klucza prywatnego, zmiana nazwy przez użytkownika końcowego, bądź odejście pracownika z firmy, która wystawiła mu certyfikat. Zdefiniowana w standardzie X.509 metoda odwoływania certyfikatów wykorzystuje wspomniane już Listy Unieważnionych Certyfikatów (CRL), okresowo publikowane przez CA w repozytorium, w którym są przechowywane certyfikaty. Każdy certyfikat posiada swój unikalny numer seryjny, przypisany przez CA w momencie jego wystawiania. Lista CRL zawiera spis identyfikatorów odwołanych certyfikatów i jest opatrzona znacznikiem czasu, wystawionym przez CA.

52

Odzyskiwanie klucza (ang. Key recovery)

Jest to dodatkowe zabezpieczenie na wypadek sytuacji, gdy użytkownik utraci swoje klucze. Jeżeli wszystkie klucze do szyfrowania albo negocjacji kluczy były przechowywane w bezpiecznym archiwum, będzie można je odzyskać i umożliwić dostęp do zaszyfrowanych danych. Najważniejsze jest zagwarantowanie, że klucze będzie mógł odzyskać tylko ich właściciel, nie zaś osoba trzecia.

Standaryzacja elementów PKI Próbę zestandaryzowania funkcji PKI podjęła grupa robocza IETF (Internet Engineering Task Force), znana również jako grupa PKIX (PKI dla certyfikatów X.509). Cztery podstawowe składniki modelu PKIX to: - użytkownik, - CA, - RA, - repozytorium certyfikatów. Specyfikacja PKIX oparta jest na dwóch innych standardach: - X.509 Międzynarodowego Związku Telekomunikacji (International Telecommunication Union - ITU) i - PKCS Standardów Kryptografii Klucza Publicznego (Public Key Cryptography Standards) autorstwa RSA Data Security. Najpopularniejsze standardy PKCS to: PKCS#7 - Cryptographic Message Syntax Standard (standard

kryptograficznego kodowania wiadomości), PKCS#10 - Certificate Request Syntax Standard (standard kodowania

wniosku o certyfikat), PKCS#12 - Personal Information Exchange Syntax Standard (standard

kodowania informacji poufnych w postaci plików).

53

Ustanawianie klucza sesji z wykorzystaniem certyfikatu Mechanizm ten stanowi podstawę działania protokołu SSL. W tym przypadku klucz publiczny serwera WWW, uzyskany z jego certyfikatu, jest wykorzystywany do szyfrowania danych przesyłanych do serwera przez przeglądarkę internetową. Na podstawie danych wymienianych z serwerem w sposób bezpieczny (zaszyfrowany) ustalany jest tajny klucz sesji, który jest wykorzystywany do szyfrowania danych przesyłanych z serwera do przeglądarki. Szczegóły tej koncepcji stanowią podstawę działania protokołu SSL/TLS.

Zasada działania protokołu SSL https://pl.wikipedia.org/wiki/Transport_Layer_Security

SSL (Secure Socket Layer) jest protokołem szyfrowanej komunikacji stosowanym do realizacji bezpiecznych połączeń z serwerami sieciowymi. Głównym zastosowaniem jest bezpieczna komunikacja przeglądarki internetowej z serwerem (HTTPS). Protokół SSL został opracowany i zaimplementowany przez firmę Netscape, a jego dalszy rozwój odbywa się w ramach protokołu TLS (Transport Layer Security). Protokół SSL składa się z czterech podprotokołów: - protokół uzgadniania (SSL Handshake Protocol); odpowiedzialny za nawiązywanie połączenia; - protokół zmiany specyfikacji szyfru (SSL Change Cipher); zmiana parametrów szyfru; - protokół alarmowy (SSL Alert Protocol); obsługa błędów; - protokół określania formatu pakietów (SSL Record Protocol); podział danych i tworzenie pakietów do wysłania.

54

Protokół SSL dodaje do protokołu sieciowego TCP/ IP warstwę ulokowaną pomiędzy warstwą transportową a warstwą aplikacji. Warstwa aplikacji: - protokół uzgadniania SSL; - protokół zmiany specyfikacji szyfru SSL; - protokół alarmowy SSL; - http; - inne protokoły (FTP, SMTP, POP3, IMAP4, telnet). Protokół określania formatu pakietów Warstwa transportowa Warstwa sieci Warstwa fizyczna Protokół SSL może być wykorzystywany również w połączeniu z innymi protokołami niż http.

HTTP (protokół HTTPS, port 443),

FTP (sFTP, port 22),

protokoły poczty elektronicznej, – Secure SMTP (SSMTP), port 465, – IMAP4 over SSL, port 993, port 585, – Secure POP3 (SSL-POP), port 995,

telnet, protokół SSH, port 22. Funkcje protokołu SSL: • uwierzytelnienie stron biorących udział w transmisji, • zapewnienie poufności transmisji poprzez szyfrowanie przesyłanych danych, • zapewnienie integralności przesyłanych danych (zabezpieczenie danych przed ich modyfikowaniem w czasie transmisji). Do uwierzytelnienia komunikujących się stron protokół SSL wykorzystuje infrastrukturę klucza publicznego (PKI, Public Key Infrastructure), standard X509.

55

Dla zapewnienia poufności transmisji wykorzystywane są: • algorytmy asymetryczne RSA, Diffie-Hellmana, Fortezza's Key Exchange Algorithm, inne, • algorytmy symetryczne DES, 3DES, RC4, inne, • algorytmy haszujące MD5, SHA. Za nawiązywanie połączenia w protokole SSL jest odpowiedzialny protokół uzgadniania.

Schemat działania protokołu wygląda następująco (jako K oznaczamy

klienta, a jako S – serwer):

K → S ClientHello

Klient wysyła do serwera zgłoszenie zawierające m.in. obsługiwaną wersję

protokołu SSL, dozwolone sposoby szyfrowania i kompresji danych oraz

identyfikator sesji. Komunikat ten zawiera również liczbę losową używaną

potem przy generowaniu kluczy.

K ← S ServerHello

Serwer odpowiada podobnym komunikatem, w którym zwraca klientowi

wybrane parametry połączenia: wersję protokołu SSL, rodzaj szyfrowania i

kompresji, oraz podobną liczbę losową.

K ← S Certificate

Serwer wysyła swój certyfikat pozwalając klientowi na sprawdzenie swojej

tożsamości (ten etap jest opcjonalny, ale w większości przypadków

występuje).

K ← S ServerKeyExchange

Serwer wysyła informację o swoim kluczu publicznym. Rodzaj i długość tego

klucza jest określony przez typ algorytmu przesłany w poprzednim

komunikacie.

K ← S ServerHelloDone

Serwer zawiadamia, że klient może przejść do następnej fazy zestawiania

połączenia.

56

K → S ClientKeyExchange

Klient wysyła serwerowi wstępny klucz sesji, zaszyfrowany za pomocą klucza

publicznego serwera. Na podstawie ustalonych w poprzednich komunikatach

dwóch liczb losowych (klienta i serwera) oraz ustalonego przez klienta

wstępnego klucza sesji obie strony generują klucz sesji używany do faktycznej

wymiany danych. Uwaga: wygenerowany klucz jest kluczem algorytmu

symetrycznego (np. 3DES, AES)! Jest on jednak ustalony w sposób

bezpieczny i znany jest tylko komunikującym się stronom.

K → S ChangeCipherSpec

Klient zawiadamia, że serwer może przełączyć się na komunikację

szyfrowaną.

K → S Finished

Klient zawiadamia, że jest gotowy do odbierania danych zaszyfrowanych.

K ← S ChangeCipherSpec

Serwer zawiadamia, że wykonał polecenie – od tej pory wysyłał będzie tylko

zaszyfrowane informacje.

K ← S Finished

Klient od razu wypróbowuje mechanizm – ten komunikat jest już wysyłany

bezpiecznym kanałem.

Uwierzytelnianie klienta

Jak widać na schemacie z poprzedniego punktu, w protokole SSL domyślna sytuacja zakłada tylko uwierzytelnianie serwera. Istnieją jednak metody pozwalające na uwierzytelnienie klienta. W tym celu korzysta się z trzech dodatkowych komunikatów:

K ← S CertificateRequest

Po przesłaniu swojego certyfikatu serwer zawiadamia, że chciałby otrzymać

certyfikat klienta.

K → S Certificate

Po otrzymaniu komunikatu ServerHelloDone klient odsyła swój certyfikat.

K → S CertificateVerify

Klient musi potwierdzić jeszcze, że faktycznie posiada klucz prywatny

odpowiadający wysłanemu certyfikatowi. W tym celu klient podpisuje swoim

kluczem prywatnym skrót wszystkich dotychczas ustalonych danych o

połączeniu i wysyła go korzystając z tego komunikatu.

57

Podczas wysyłania danych z użyciem protokołu SSL wykonywane są operacje: - dane dzielone są na pakiety; - pakiety poddawane są kompresji; - dla każdego pakietu obliczany jest kod MAC; - dane są łączone z ich kodem uwierzytelniającym MAC; - uzyskane pakiety są szyfrowane; - pakiety są łączone w pakiety TCP i wysyłane do sieci. Za przeprowadzenie tych operacji jest odpowiedzialny protokół określania formatu pakietów. Jeśli w trakcie wykonywania tych operacji pojawi się pakiet z błędami, to uruchamiany jest protokół alarmów. W przypadku, gdy pojawi się informacja typu ostrzeżenie lub błąd na połączenie nakładane są ograniczenia, w przypadku błędu krytycznego połączenie jest przerywane. Algorytmy szyfrowania pakietów są ustalane w fazie nawiązywania połączenia. Komputer klienta podaje listę obsługiwanych metod, spośród których serwer wybiera najbezpieczniejszą dla danego połączenia. Do szyfrowania danych wykorzystywane są algorytmy kryptograficzne symetryczne (np. AES), natomiast do przesyłania kluczy sesji stosowane są algorytmy asymetryczne.

Protokół Needham-Schroeder symetryczny Rozważamy sieć złożoną z n węzłów, w których znajdują się podmioty, które chcą się bezpiecznie komunikować, wykorzystując kryptografię symetryczną. Podmioty (i, j), które chcą się bezpiecznie komunikować wymagają jednego klucza tajnego kij. W przypadku n podmiotów niezbędny jest jeden klucz dla każdej pary podmiotów:

.

58

Np. dla trzech podmiotów 1, 2, 3 potrzebne są 3 klucze: k12, k13 oraz k23. 1 ---- k12 ----- 2 ----- k23 ------ 3 ----- k13 ----- 1 Liczba kluczy rośnie z kwadratem liczby węzłów. Rozwiązaniem problemu zarządzania kluczami w środowisku rozproszonym złożonym z n podmiotów jest centrum dystrybucji kluczy KDC. Centrum KDC posiada klucze symetryczne do komunikacji z każdym z podmiotów w1, w2, …, wn. Aby zapewnić bezpieczną komunikację pomiędzy parą podmiotów (wi, wj) centrum KDC generuje symetryczny klucz sesji sij, wykorzystywany do szyfrowania połączeń pomiędzy podmiotami, który jest dostarczany do podmiotów w sposób bezpieczny z wykorzystaniem protokołu Needhama-Schroedera. Protokół ten zapewnia bezpieczną komunikację oraz wzajemne uwierzytelnienie podmiotów. Wykorzystuje on pojęcie jednorazówki. Jest to wartość, która w protokole może być wykorzystana tylko raz. Niech A będzie podmiotem, który chce się bezpiecznie komunikować z usługą B, np. serwerem bazodanowym, usługą pocztową. Podmiot A posiada tajny, symetryczny klucz KAC, służący do komunikacji z KDC, natomiast podmiot B posiada klucz KBC. Klucze KAC i KBC znajdują się również w KDC. Celem protokołu jest obopólne poświadczenie tożsamości pomiędzy usługą B, a podmiotem A z wykorzystaniem centrum KDC, a także bezpieczna komunikacja A z B. Niech NA , NA1 oraz NB będą jednorazówkami generowanymi odpowiednio przez A i B. KAB jest kluczem symetrycznym, generowanym przez KDC i służącym jako klucz sesji do komunikacji A z B. Schemat wymiany komunikatów pomiędzy KDC i podmiotami jest następujący.

59

1) Podmiot A wysyła do KDC komunikat, w którym identyfikuje siebie oraz usługę B, z którą chce się komunikować; dodatkowo umieszcza w komunikacie jednorazówkę NA, zapewniającą świeżość komunikatu. A KDC: A, B, NA; 2) W odpowiedzi serwer KDC odsyła komunikat zaszyfrowany kluczem KAC, w którym umieszcza klucz KAB, jednorazówkę NA, identyfikator B, oraz bilet dostępu do B zaszyfrowany kluczem usługi KBC. KDC A: { NA, KAB, B, { KAB, A }KBC }KAC 3) Podmiot A odszyfrowuje komunikat swoim kluczem KAC i uzyskuje klucz KAB oraz bilet dostępu do usługi B. Podmiot A wysyła do B bilet oraz jednorazówkę NA1 zaszyfrowaną kluczem sesji. A B: { KAB, A }KBC ; { NA1} KAB 4) Usługa B odszyfrowuje bilet i uzyskuje klucz sesji KAB, który wykorzysta do bezpiecznej komunikacji z A. Usługa B uwierzytelnia się przesyłając zmodyfikowaną jednorazówkę. B A: { NA1 – 1 }KAB Aby zapewnić obopólne uwierzytelnienie usługa B wysyła do A jednorazówkę NB zaszyfrowaną kluczem sesji. B A: { NB }KAB 5) Podmiot A uwierzytelnia się odpowiadając A B: { NB – 1 }KAB Od tej pory możliwa jest bezpieczna komunikacja pomiędzy A i B z wykorzystaniem symetrycznego klucza sesji KAB (który jednak może zostać złamany).

60

Protokół N-Sch

KDC (podmiot C)

Klucze komunikacyjne:

KAC, KBC,

Klucz sesji: KAB

Podmiot A

Klucze

komunikacyjne:

KAC

Klucz sesji: KAB

Usługa B

Klucze

komunikacyjne:

KBC,

Klucz sesji: KAB

1: A KDC: A, B, NA;

2: KDC A: { NA, KAB, B, { KAB, A }KBC }KAC

3: A B: { KAB, A }KBC ; { NA1} KAB

4: B A: { NA1 – 1 }KAB B A: { NB }KAB

5: A B: { NB – 1 }KAB

61

Gdyby klucz sesji KAB został skompromitowany możliwe byłoby podszycie się pod A poprzez ponowne przesłanie biletu { KAB, A }KBC do B, który nie byłby w stanie wykryć, że jest to bilet nieaktualny. Aby temu zapobiec można dodać jednorazówkę NB1 do biletu przesyłanego do B. 1) Najpierw A wysyła do B żądanie nawiązania komunikacji: A B: A 2) B odpowiada jednorazówką NB1 zaszyfrowaną kluczem przeznaczonym do komunikacji z serwerem KDC: B A: { A, NB1 }KBC 3) Podmiot A wysyła do KDC komunikat, w którym identyfikuje siebie oraz usługę B, z którą chce się komunikować; dodatkowo umieszcza w komunikacie jednorazówkę NA, zapewniającą świeżość komunikatu oraz jednorazówkę od B: A KDC: A, B, NA, { A, NB1 }KBC 4) W odpowiedzi serwer KDC odsyła komunikat zaszyfrowany kluczem KAC, w którym umieszcza klucz KAB, jednorazówkę NA, identyfikator B, oraz bilet dostępu do B zaszyfrowany kluczem usługi KBC oraz uzupełniony o jednorazówkę NB1. KDC A: { NA, KAB, B, { KAB, A, NB1 }KBC }KAC 5) Podmiot A odsyła bilet do B. Jednorazówka NB1 zapewnia świeżość biletu i zapewnia B, że jest to bilet dla A wygenerowany w odpowiedzi na aktualne żądanie. A B: { KAB, A, NB1 }KBC ; { NA1} KAB Powtórzenie biletu wymagałoby przesłania wiadomości postaci { KAB, A, NB1 }KBC z nową, świeżą jednorazówką NB1, czego bez znajomości klucza KBC nie da się zrobić. Powtórzenie jednorazówki NB1 oznaczałoby, że bilet jest nieaktualny.