Obiektowe Bazy Danych kontra Relacyjne Bazy Danych

1
Obiektowe Bazy Danych kontraRelacyjne Bazy
Danych
Kazimierz Subieta Instytut Podstaw
Informatyki PAN Warszawa
2
Model relacyjny -rys historyczny
1970 Najbardziej znany, najczesciej cytowany
artykul E.F.Codda z IBM proponujacy oparcie sie
na teorii relacji jako podstawie ideologicznej i
teoretycznej architektury, jezyków i interfejsów
systemów zarzadzania bazami danych. Koncepcja
zostala okreslona jako relacyjny model danych,
RDM. 1971 - 1975 Zazarta walka ideologiczna
pomiedzy zwolennikami RDM a zwolennikami
koncepcji sieciowych baz danych opartych o
propozycje grupy DBTG komitetu CODASYL. Walka
toczy sie o pieniadze rzedu 100 miliardów w
skali 20 lat. 1971 - 1985 Intensywny rozwój
teorii zwiazanych z RDM. RDM stal sie ulubionym
konikiem grup teoretycznych na calym swiecie
(kilka tysiecy publikacji). 1975-1989 Intensywny
rozwój technologii opartych o RDM. Kariera wielu
systemów zarzadzania relacyjnymi bazami danych,
takich jak DB2, Oracle, Ingres, dBase nastepnie
Informix, Progress, Sybase, i wiele innych.
Szerokie zastosowania na skale przemyslowa,
ogromna popularnosc i pieniadze. 1975 Pierwsze
publikacje na temat jezyka Sequel, poprzednika
SQL, autorów z IBM (Chamberlin). 1986 Pierwszy
standard jezyka SQL zaaprobowany przez ANSI.
Wykazuje liczne odstepstwa od RDM. 1989, 1992
Nastepne standardy SQL. 1987 E.F.Codd,
sfrustrowany odstepstwami od RDM, publikuje
slynne 12 regul prawdziwego systemu
relacyjnego. Zaden z istniejacych systemów nie
jest prawdziwym systemem relacyjnym. Ma racje,
ale nikt tym sie nie przejmuje. Prawdziwego
systemu relacyjnego chyba juz nigdy nie bedzie.
1985-1997 Intensywna krytyka wad RDM. Swiat
naukowy zredukowal swoje zainteresowanie RDM
praktycznie do zera. Swiat komercyjny rozbudowuje
systemy bez jakiejkolwiek troski o ideologie RDM.
3
Model relacyjny - podstawowe zalozenia
Baza danych sklada sie z prostokatnych tablic,
kazda o okreslonej liczbie kolumn i dowolnej
liczbie wierszy. Takie tablice sa okreslane jako
relacje. Wiersz relacji jest nazywany
krotka. Elementy krotek sa atomowe
(niepodzielne) i sa bezposrednio wartosciami.
Niedozwolone jest tworzenie wskazników
prowadzacych do innych krotek. Niedozwolone jest,
aby element krotki byl zbiorem wartosci. Jest to
tzw pierwsza forma normalna (1NF). Porzadek
krotek nie ma znaczenia. Porzadek kolumn równiez
nie ma znaczenia. Jakiekolwiek cechy odnoszace
sie do reprezentacji relacji lub usprawnienia
dostepu do relacji sa ukryte przed
uzytkownikiem. Relacje i ich kolumny posiadaja
nazwy. Nazwy kolumn sa okreslane jako
atrybuty. Kazda relacja posiada wyrózniony
atrybut lub grupe atrybutów okreslna jako klucz.
Wartosc klucza w unikalny sposób identyfikuje
krotke relacji. Jakakolwiek inna identyfikacja
krotki (np. wewnetrzny identyfikator) jest
niewidoczna dla uzytkownika. Manipulacja
relacjami odbywa sie w sposób makroskopowy przy
pomocy operatorów algebry relacji lub innego tego
rodzaju jezyka. Przetwarzanie krotka po krotce
jest niedozwolone.
4
SQL podstawowy format zdania select
select all distinct expression ,
expression from table_name corr_name
.table_name corr_name where
search_condition1 group by column ,
column having search_condition2
Zapytania SQL moga byc bardzo zlozone. Semantyka
jest dosc czesto niejasna (SQL puzzles).

• Oprócz zdania select SQL wprowadza
• zdania definicji danych
• zdania manipulacji danymi (update, insert,
  delete )

• Mimo to, SQL nie jest pelnym jezykiem
  programowania, w zwiazku z czym wymaga
• Zanurzenia zdan SQL w uniwersalny jezyk
  programowania
• Zdan posredniczacych, które umozliwiaja takie
  zanurzenie

Konsekwencja polaczenia dwóch róznych jezyków
jest niekorzystny efekt okreslany
jako niezgodnosc impedancji.
5
SQL proste zdania select
Zakladamy tablice PRACOWNIK( NR, NAZWISKO,
ZAROBEK, NRDZ) DZIAL( NRDZ, NAZWA, LOKALIZACJA
)
Podaj nazwiska pracowników zarabiajacych mniej
niz 1000
select NAZWISKO from PRACOWNIK where ZAROBEK gt
1000
Podaj nazwiska i nazwy dzialów pracowników
pracujacych w Radomiu
select P.NAZWISKO, D.NAZWA from PRACOWNIK P,
DZIAL D where P.NRDZ D.NRDZ and D.LOKALIZACJA
Radom
Semantyka Zaczynamy od from Specyfikujemy
tablice do przeszukania oraz ew. ich lokalne
synonimy (scislej zmienne krotkowe). Tworzymy
iloczyn kartezjanski tablic. Nastepnie where
Usuwamy z tablicy lub iloczyny kartezjanskiego
takie krotki, które nie spelniaja warunku. Na
koncu select Bierzemy z kazdej wynikowej krotki
to, co jest potrzebne.
Na bazie tego prostego pomyslu utworzono
gigantyczna odwrócona piramide (setki stron
specyfikacji)
6
Co to jest niezgodnosc impedancji? (1)
Zespól niekorzystnych zjawisk towarzyszacych
formalnemu polaczeniu jezyka zapytan (np. SQL) z
uniwersalnym jezykiem programowania (np. C, Cobol
lub PL/I) . Objawia sie niezgodnosciami w
zakresie
Skladni Programista musi w jednym tekscie
programu uzywac dwóch stylów jezykowych i
przestrzegac regul dwóch róznych
gramatyk. Systemu typów Jezyk zapytan operuje
na typach zdefiniowanych w schemacie bazy danych,
m.in. relacjach, natomiast jezyk programowania
posiada zwykle odmienny system typów, w którym
nie wystepuje typ relacja. Wiekszosc jezyków
programowania ma wbudowana statycznej kontrole
typów, podczas gdy SQL takiej kontroli nie
przewiduje. Semantyki i paradygmatów jezyków
Koncepcja semantyki jezyków jest zasadniczo
rózna. Jezyk zapytan bazuje na stylu
deklaracyjnym (co wyszukac, a nie jak) podczas
gdy jezyki programowania bazuja na stylu
imperatywnym (jak zrobic, a nie co). Pragmatyki
uzycia Jezyk zapytan uwalnia programiste od
wielu szczególów organizacji i implementacji
danych (np. organizacji zbiorów, obecnosci lub
nieobecnosci indeksów, itd.), podczas gdy w
jezyku programowania te szczególy musza byc
oprogramowane explicite. Faz i mechanizmów
wiazania Jezyki zapytan sa oparte o pózne
wiazanie (sa interpretowane) podczas gdy jezyki
programowania zakladaja wczesne wiazanie (podczas
kompilacji i konsolidacji). Stwarza to problemy
m.in. dla programów odpluskwiajacych (debugger).
7
Co to jest niezgodnosc impedancji? (2)
Dodatkowo objawia sie niezgodnosciami w zakresie
Przestrzeni nazw i regul zakresu Jezyk zapytan i
jezyk programowania posiadaja wlasne przestrzenie
nazw, które moga zawierac identyczne nazwy o
róznych znaczeniach. Odwzorowania pomiedzy
przestrzeniami nazw wymagaja dodatkowych srodków
syntaktycznych i semantycznych. Przestrzen nazw
jezyka programowania jest zbudowana
hierarchicznie i podlega regulom zakresu opartym
o zasade stosu. Te reguly sa ignorowane przez
jezyk zapytan powodujac wiele trudnosci. Schemató
w iteracyjnych W jezyku zapytan iteracje sa
wtopione w semantyke operatorów takich jak
selekcja, projekcja i zlaczenie. W jezyku
programowania iteracje musza byc organizowane
explicite przy pomocy petli for, while, repeat
lub innych. Przetwarzanie wyników zapytan przy
pomocy jezyka programowania wymaga specjalnych
udogodnien takich jak kursory i
iteratory. Traktowania cechy trwalosci danych
Jezyki zapytan przetwarzaja wylacznie trwale dane
(znajdujace sie na dysku), podczas gdy jezyki
zapytan przetwarzaja wylacznie dane nietrwale
znajdujace sie w pamieci operacyjnej. Polaczenie
jezyków wymaga od programisty uzycia specjalnych
srodków jezykowych do parametryzacji zapytan
przez zmienne jezyka programowania oraz srodków
jezykowych i architektonicznych sluzacych do
transmisji danych z dysku do pamieci operacyjnej
i odwrotnie. Srodków programowania ogólnego
(generic) Srodki te w jezyku zapytan sa oparte o
refleksje (patrz np. dynamiczny SQL). Uzycie
podobnego srodka w jezyku programowania jest
zazwyczaj niemozliwe z powodu wczesnego wiazania.
Stosowane sa inne srodki, takie jak funkcje
wyzszego rzedu, casting, przejscie na nizszy
poziom jezykowy, polimorfizm lub szablony.
8
Co to jest niezgodnosc pomiedzy modelem
pojeciowym i modelem implementacyjnym?
Celem jest uzyskanie jak najmniejszej luki
pomiedzy mysleniem o rzeczywistosci a mysleniem
o danych i procesach, które zachodza na danych.
Mentalna percepcja swiata rzeczywistego
Model pojeciowy
Schemat relacyjnej struktury danych
W modelu relacyjnym model pojeciowy jest budowany
w oparciu o model encja-zwiazek. Model
encja-zwiazek stara sie odwzorowac swiat
rzeczywisty, lecz nie moze byc bezposrednio
zaimplementowany, gdyz relacyjna baza danych na
to nie pozwala. W rezultacie, - schemat
struktury danych gubi znaczna czesc semantyki
danych, - uzytkownik musi kojarzyc dane
explicite w zdaniach SQL, co zwieksza ich
zlozonosc i powoduje wzrost czasów wykonania.
9
Niezgodnosc modelu pojeciowego i relacyjnego(1)
Mama
Zatrudnia
Osoba Nazwisko Adres RokUrodz
Departament NrD NazwaD Lokacja
Pracownik NrPrac Zawód Wyplaty
Dziecko
Pracuje_w
Dziecko
Szef
Tata
Ile schematów relacyjnych potrzeba, aby
zaimplementowac te strukture?
Departament( NrD, NazwaD ) Lokacja( NrLokacji,
NazwaLok, NrD ) Szef( NrD, NrPrac) Pracownik(
NrPrac, NrOsoby) PracDept( NrPrac, NrD) Zawód(
IdZawodu, NazwaZawodu, NrPrac ) Wyplata (
IdWyplaty,Wysokosc, NrPrac ) Osoba( NrOsoby,
Nazwisko, RokUrodz ) Adres( NrAdresu, Miejsce,
NrOsoby ) Mama( NrOsoby, NrOsoby ) Tata( NrOsoby,
NrOsoby )
Czytelna pojeciowa struktura zamienila sie na 11
nieczytelnych schematów relacji Pojawily sie
nowe atrybuty - klucze Semantyka wyrazona
poprzez licznosci zostala czesciowo
zgubiona Semantyka dziedziczenia zostala
zgubiona Odtworzenie semantyki - uzytkownik
musi zrobic explicite poprzez zapytania SQL
10
Niezgodnosc modelu pojeciowego i relacyjnego(2)
Pracownik Zawód
FZ
PZ
Firma( NrF, Nazwa)
Lokal( NrF, Miejsce)
Zatrudnienie( NrF, NrP)
Pracownik( NrP, NrOs)
Oceny( NrOceny, Ocena, NrF, NrP)
Osoba( NrOs, Nazwisko)
Dochód( NrDochodu, Wyplata, NrF, NrP)
Wyszkolenie( Zawód, NrP)
Imiona( NrOs, Imie)
Adresy( NrOs, Adres)
11
Zapytania w OQL i SQL
Podaj adresy pracowników zatrudnionych w firmach
zlokalizowanych w Radomiu
select z.Adres from Firma as x, x.FZ as y, y.PZ
as z where Radom in x.Miejsce
OQL
(26 jednostek leksykalnych)
SBQL
(Firma where Radom in Miejsce).FZ.Zatrudnienie.P
Z.Pracownik.Adres
(17 jednostek leksykalnych)
select a.Adres from Lokal as k, Zatrudnienie as
z, Pracownik as p, Osoba as s, Adresy as a where
k.Miejsce Radom and k.NrF z.NrF and z.NrP
p.NrP and p.NrOs s.NrOs and s.NrOs a.NrOs
SQL
(62 jednostki leksykalne)
12
Garby modelu relacyjnego
Z góry ustalony konstruktor typu danych
(relacja), rozszerzany ad hoc przez
wytwórców systemów relacyjnych. Brak zlozonych
obiektów. Informacje o pojeciach wyróznialnych i
manipulowalnych w rzeczywistosci sa rozproszone w
krotkach wielu tablic.
Skojarzenie tych informacji nastepuje w
zapytaniach SQL, przez co wzrasta ich zlozonosc
oraz czas wykonania (optymalizacja zapytan tylko
czesciowo to rozwiazuje).
Brak wyspecjalizowanych srodków do realizacji
powiazan pomiedzy danymi.
Brak srodków do przechowywania danych
proceduralnych. Wszelkie informacje wykraczajace
poza strukture relacyjna (perspektywy, procedury
bazy danych, BLOBy, aktywne reguly,...) sa
implementowane ad hoc.
Brak srodków hermetyzacji i modularyzacji
wykroczenie przeciwko zasadom abstrakcji i
oddzielenia implementacji od specyfikacji.
Brak uniwersalnosci srodków dostepu do danych,
powodujacy koniecznosc zanurzenia ich w
uniwersalne jezyki programowania, znacznie
nizszego poziomu niezgodnosc impedancji (impedanc
e mismatch). Niespelnione obietnice przetwarzania
makroskopowego (wiele-w-tym-samym-czasie)
powrót do niewygodnej techniki jeden-w-tym-samym-c
zasie.
Niespójne mechanizmy wartosci zerowych, brak
wariantów, brak porzadku w relacjach.
13
Obiektowe bazy danych
Teza bazy danych zawsze byly obiektowe,
chociaz nie realizowaly wszystkich pojec
obiektowosci, takich jak klasy, metody i
dziedziczenie.
Podstawowy wyróznik trwale obiekty
identyfikatory obiektów
Zmniejszenie dystansu pomiedzy fazami analizy,
projektowania i implementacji
Zwiekszenie poziomu abstrakcji w mysleniu
programistów i uzytkowników
Uwzglednienie informacji proceduralnej (metody)
Stworzenie nowego potencjalu dla ponownego uzycia
Docelowa tendencja - ortogonalna trwalosc
Programista podczas programowania nie musi nic
wiedziec o bazie danych, operujac na jej
obiektach tak jak na obiektach/zmiennych
programu. Baza danych powinna byc niewidoczna
(przezroczysta).
14
Co zdarzylo sie w systemach po przejsciu na
technologie obiektowe?
Czesc informacji semantycznej, która
tradycyjnie tkwila w bibliotekach, typach,
aplikacjach, modulach zostala umieszczona i
usystematyzowana w ramach klas.
Relacyjna struktura aplikacji
Obiektowa struktura aplikacji
Pasywne dane (relacje)
Powiazane obiekty
Klasy i typy
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Typy
Biblioteki procedur i funkcji
Moduly aplikacyjne
Moduly aplikacyjne
Procedury bazy danych, perspektywy, reguly
Slowniki, katalogi
Slowniki, katalogi
15
Obiektowy SZBD jest to SZBD
Klasyczne funkcje SZBD

• Zarzadzanie pamiecia zewnetrzna
• Zarzadzanie schematem
• Sterowanie wspólbieznoscia
• Zarzadzanie transakcjami
• Odtwarzalnosc
• Przetwarzanie zapytan
• Kontrola dostepu

Do tych funkcji dolozone sa

• Zlozone obiekty
• Typy definiowane przez uzytkownika
• Tozsamosc obiektów
• Powiazania pomiedzy obiektami
• Hermetyzacja, interfejsy do obiektów
• Typy i/lub klasy oraz hierarchia dziedziczenia
• Przelanianie/przeciazanie/pózne wiazanie
• Kompletnosc obliczeniowa (pragmatyczna)

16
Manifest obiektowych baz danych
polowa 1989
M.Atkinson, F.Bancilhon, D.DeWitt, K.Dittrich,
D.Maier, S. Zdonik
Cechy obowiazkowe

• zlozone obiekty

• przeslanianie z dynamicznym wiazaniem

• tozsamosc obiektów

• rozszerzalnosc

• hermetyzacja

• kompletnosc obliczeniowa

• dziedziczenie

• zarzadzanie pamiecia pomocnicza

• typy lub klasy

• wspólbieznosc, odtwarzanie

• trwalosc

• udogodnienia dla zapytan ad hoc

wielokrotne dziedziczenie, kontrola typów,
rozproszenie, transakcje projektowe, wersje
Cechy opcyjne
paradygmat programowania, metody reprezentacji
obiektów, system typów, jednolitosc
(kompatybilnosc)
Cechy otwarte
17
Manifest baz danych trzeciej generacji (3GBD)
poczatek 1990
M.Stonebraker, L.Rowe, B.Lindsay, J.Gray,
M.Carey, M.Brodie, P.Bernstein, D.Beach

• 3GBD maja wspomagac bogatsze struktury danych i
  reguly
• 3GBD musza posiadac wszystkie pozytywne cechy
  2GBD
• 3GBD musza byc otwarte dla innych systemów

Doktryny
13 postulatów

• 3GBD musza posiadac bogaty system typów
• Dziedziczenie jest dobrym pomyslem
• Funkcje (wlaczajac zapamietane procedury i
  metody) hermetyzacja sa dobrymi pomyslami.
• Unikalne identyfikatory powinny byc stosowane
  wtedy, gdy nie sa dostepne klucze pierw.
• Reguly (wyzwalacze, wiezy) stana sie glówna
  cecha przyszlych systemów
• Caly dostep do bazy danych powinien odbywac sie
  poprzez nieproceduralny jezyk wys.poz.
• Kolekcje powinny byc specyfikowane zarówno przez
  ich wyliczenie jak i poprzez zapytanie
• Aktualizowanle perspektywy sa istotne
• Wlasnosci fizyczne nie maja zwiazku z modelem
  danych i powinny byc z niego usuniete
• 3GBD musza byc dostepne z wielu jezyków
  wysokiego poziomu
• Jezyki te powinny byc wyposazone w ceche
  trwalosci i mozliwosci jezyków zapytan
• Na lepsze i gorsze, SQL jest intergalaktycznym
  jezykiem danych
• Zapytania i odpowiedzi na zap. powinny byc
  dolnym poziomem komunikacji klient-serwer

18
Systemy obiektowo-relacyjne
Powstaja w wyniku ostroznej ewolucji systemów
relacyjnych w kierunku obiektowosci, licza na
pozycje systemów relacyjnych na rynku i odwoluja
sie do ich wiernej klienteli.
Nacisk dwóch tendencji
Rynek domaga sie cech pozwalajacych zniwelowac
niedostatki relacyjnej technologii, szczególnie w
zakresie danych multimedialnych, zwiazania z
danymi informacji behawioralnej (regul, metod),
modelowania pojeciowego i srodków programowania
aplikacji. Pokusa wprowadzenia wielu cech
obiektowosci, takich jak klasy, metody,
dziedziczenie, abstrakcyjne typy danych,
pozwalajacych na twierdzenia o czesciowej
obiektowosci systemów relacyjnych.
Podejscie jest okreslane jako hybrydowe lub
obiektowo-relacyjne. Ostatnio kariere robi
takze termin uniwersalny serwer (universal
server)
19
Kluczowe systemy obiektowo-relacyjne
Informix Universal Server, DB2 Universal
Database (IBM), Oracle8, UniSQL/X, OSMOS
(Unisys), OpenIngres (Computer Associates),
Sybase Adaptive Server, Montage, Omniscience,
Raima Database Manager, Total ORDB ....

• Przystosowanie do multimediów (duze obiekty BLOB,
  CLOB i pliki binarne),
• Dane przestrzenne (spatial),
• Abstrakcyjne typy danych (ADT),
• Metody (funkcje i procedury) definiowane przez
  uzytkownika w róznych jezykach (C, VisualBasic,
  Java)
• Kolekcje (zbiory, wielozbiory, sekwencje,
  zagniezdzone tablice, tablice o zmiennej
  dlugosci),
• Typy referencyjne,
• Przeciazanie funkcji,
• Pózne wiazanie
• ....

Zachowuja wiele technologii, które sprawdzily sie
w systemach relacyjnych, takie jak architektura
klient/serwer, mechanizmy buforowania i
indeksowania, przetwarzanie transakcji,
optymalizacja zapytan
20
Po co systemy obiektowo-relacyjne?
Szybki i pewny zysk
Komercyjny sukces nie jest jednak sprawa pewna
Informix osiagnal w 1997 r. wynik finansowy o
100 mln. nizszy niz zakladal plan, Dobre wyniki
osiaga Oracle8, prawdopodobnie wskutek
zintegrowania produktu z ogromnym pakietem uslug
i udogodnien.
Ideologiczne zalety obiektowo-relacyjnych baz
danych sa nieprzekonywujace z koncepcyjnego
punktu widzenia obiektowe bazy danych wlaczaja
struktury relacyjne jako przypadek szczególny.
Galimatias komercyjnej retoryki powodujacy
mnóstwo nieporozumien. Mnozenie bytów ponad
potrzebe wskutek relacyjnej spuscizny Brak bazy
intelektualnej, a raczej jej rozmydlenie i
rozbeltanie Totalnie niekompatybilne musza
odejsc od standardu SQL-92 (nowe struktury
danych) Powoluja sie na standard SQL3, który
bedzie gotowy (?) za 3-5 lat
Systemy obiektowo-relacyjne maja wyrazny posmak
dekadencji, eklektyzmu i kryzysu koncepcji - cech
swoistych dla granicy epok.
21
SQL 3
Nowy standard jezyka SQL, opracowywany przez ANSI
oraz ISO, nastepca i rozszerzenie SQL-92.
W zalozeniu, uniwersalny jezyk programowania dla
relacyjnych baz danych z obiektowoscia.
Kompatybilnosc w dól ze standardem SQL-92.

• Abstrakcyjne typy danych (ADT),
• Metody pisane w SQL3 lub w innych jezykach.
• Identyfikatory obiektów
• Podtypy
• Dziedziczenie,
• Polimorfizm,
• Integracja z jezykami zewnetrznymi
• Usprawnienia konstrukcji definiujacych tablice
• typy wierszy,
• identyfikatory wierszy
• mechanizm dziedziczenia.
• Struktury sterujace
• Typy parametryczne
• Tablica ma kolumne IDENTITY, która zawiera TID.
• Atrybuty obliczane (metody funkcyjne)

Dla dowolnej zadeklarowanej tablicy mozna
zadeklarowac podtablice, która zawiera wszystkie
kolumny macierzystej tablicy plus niektóre nowe
kolumny.
22
SQL3 -charakterystyka
Jak dotad, rozszerzenia w SQL3 sa redundantne i
niezbyt spójne. Standard znajduje sie w fazie
opracowywania i bedzie gotowy przypuszczalnie w
latach 2000-2002. Kontrowersje wzbudza ogromna
objetosc tego standardu, powodowana przez
nagromadzenie róznych pomyslów bez klarownie
wyartykulowanego modelu danych i podstawy
ideologiczno-teoretycznej. Mówi sie, ze juz ma
1200 - 1500 stron, a ciagle rosnie Kontrowersyjne
jest podjecie prac badawczo-rozwojowych w
zakresie konstrukcji jezyka programowania baz
danych przez cialo standaryzacyjne, statutowo
powolane do innych celów i posiadajace inne
kompetencje. Istnieje koncepcja integracji
jezyków SQL3 i OQL wg standardu ODMG, chociaz
wobec zupelnie innych zalozen hasla integracji
chyba nikt nie traktuje powaznie.
23
Obiektowosc kontra model relacyjnyWarstwa
technologii (1)
Sprzymierzencem wszystkich wdrozonych technologii
baz danych, w tym relacyjnych, jest ogromna
bezwladnosc rynku zastosowan, który niechetnie
zmienia swoje preferencje, szczególnie jezeli
zostaly zainwestowane duze pieniadze i czas.
Jezeli jakas koncepcja technologiczna opanowala
pewna dziedzine zastosowan i/lub teren
geograficzny, wówczas trudno zastapic ja inna
koncepcja, nawet jezeli jest ona lepsza. Klient
baz danych nie lubi kosztownych zmian i musi miec
pewnosc, ze nie pozostanie sam i moze liczyc na
srodowisko specjalistów jak i ogólna kulture
techniczna wytworzona w zwiazku z dana
technologia.
Systemy relacyjne opanowaly duza grupe nisz
ekologicznych i mozna przyjac, ze pozostana w
nich przez kilka, kilkanascie, lub nawet
kilkadziesiat lat.
Systemy obiektowe musza poszukiwac innych nisz,
które nie sa zagospodarowane przez wczesniejsze
technologie. Potencjalnym polem zastosowan
obiektowych baz danych sa multimedia, dziedziny
wymagajace bardziej rozbudowanych struktur
danych, takie jak CAD (Computer Aided Design),
CAM (Computer Aided Manufacturing), CASE, lub
dziedziny implikujace nieregularne,
niesformatowane struktury danych, takie jak
zastosowania pelno-tekstowe, hurtownie danych,
zastosowania biurowe.
24
Obiektowosc kontra model relacyjnyWarstwa
technologii (2)
Prawie wszystkie systemy relacyjne przechodza
etap radykalnych modernizacji (m.in., a moze
przede wszystkim) w zwiazku z wyzwaniem jakie
stawiaja technologie obiektowe. Nastepuje
wzmocnienie struktur danych przechowywanych w
systemach relacyjnych o nowe mozliwosci.
Rozszerzenia te wprowadzaja wiele elementów
obiektowosci. Wiele systemów relacyjnych jest
wyposazane w mozliwosc wspóldzialania z innymi
systemami (w tym nie-relacyjnymi) wedlug
standardu obiektowego OMG CORBA. Ponad 90
programów rzekomo zgodnych ze standardem SQL-92
nie daje sie przeniesc na inne platformy SZBD,
glównie ze wzgledu na niepelnosc tych standardów
oraz niekompatybilne rozszerzenia implementowane
w poszczególnych systemach. Specjalisci
powatpiewaja co do implementowalnosci SQL3 Nie
istnieje wlasnosc systemów relacyjnych, która nie
moglaby byc równie dobrze zrealizowana w
systemach obiektowych Wbrew rozpowszechnianym
mitom, obiektowosc sprzyja wydajnosci m.in.
poprzez technike przemiany wskazników (pointer
swizzling), indeksy sciezkowe (path indices),
oraz poprzez nowe mechanizmy indeksacji i
buforowania umozliwiajacymi istotne przesuniecie
przetwarzania na strone klienta w architekturze
klient-serwer.
25
Obiektowosc kontra model relacyjnyWarstwa
ideologii
Model relacyjny przegral konfrontacje z
obiektowoscia w warstwie ideologicznej. Dzisiaj
nie jest widoczny liczacy sie osrodek naukowy,
który aktywnie rozwijalby model relacyjny od
strony ideologiczno-naukowej.
Glówna wada koncepcyjna modelu relacyjnego jest
to, co mialo byc jego zaleta, mianowicie prostota
struktur danych. Informacje o pojeciach
wyróznialnych w rzeczywistosci sa rozproszone w
krotkach wielu tablic, co burzy zwiazek pomiedzy
pojeciowym obrazem swiata, a pojeciowym obrazem
struktur danych modelujacych ten swiat.
Model relacyjny nie zajmuje sie informacja
proceduralna, która czesto jest istotna skladowa
obrazu pojeciowego danych. Wobec braku
systematycznych srodków, wszelkie informacje
wykraczajace poza strukture relacyjna sa
implementowane ad hoc.
Ideologia relacyjna jest oparta na naiwnych
pogladach co do srodków przetwarzania informacji.
Trzonem tych srodków mialy byc operatory algebry
relacji lub rachunku relacyjnego niestety,
okazaly sie one zbyt malo uniwersalne. Duza
czesc tego przetwarzania musiala byc oddelegowana
do uniwersalnych jezyków programowania, co
doprowadzilo do niekorzystnego efektu
niezgodnosci impedancji. W konsekwencji
postulowane przez model relacyjny przetwarzanie
makroskopowe wrócilo do nieslawnego przetwarzania
niskiego poziomu, np. poprzez kursory w
zagniezdzonym SQL.
26
Obiektowosc kontra model relacyjnyWarstwa teorii
Nieautentyczny, dekoracyjny charakter relacyjnych
teorii. Sa pseudo-naukowymi fasadami.
Zastosowanie teorii zaleznosci funkcjonalnych,
wielowartosciowych i innych, sprowadza sie do
definicji kilku pojec (2NF, 3NF,...) o znaczeniu
marginalnym dla praktyki projektowania. Oparcie
semantyki jezyków zapytan takich jak SQL o
algebre relacji lub rachunek relacyjny jest
pomyslem calkowicie nieudanym. Teorie te sa
niedostatecznie uniwersalne dla SQL. Mitem sa
twierdzenia, ze metody optymalizacji zapytan sa
konsekwencja odkrytych wlasnosci algebry relacji.
Calkowite fiasko badan nad niekompletna
informacja (setki publikacji!) . Rozwiazania w
tym zakresie sa pozbawione logiki i konsekwencji.
Calkowite fiasko rozszerzen teoretycznych takich
jak uniwersalne relacje i dedukcyjne bazy danych
(setki publikacji!). W systemach
post-relacyjnych lub obiektowo-relacyjnych
termin relacyjny ma wylacznie znaczenie
tradycyjno-dekoracyjne. Systemy te, poprzez
rozbudowe wlasnosci struktur danych i jezyków
przetwarzania danych, nie sa w stanie skorzystac
z wlasnosci matematycznego pojecia relacji w
duchu relacyjnego modelu danych.
Twierdzenia, ze model relacyjny posiada solidne
podstawy matematyczne zas obiektowosc ich nie
posiada sa falszywymi stereotypami i popisami
demagogów. Zarówno systemy relacyjne, jak SQL,
jak i systemy obiektowe nie maja istotnej teorii.
27
Czeste mity przy porównaniach (1)
W odróznieniu od systemów obiektowych, systemy
relacyjne i SQL posiadaja solidne podstawy
matematyczne. Nieprawda. Struktury danych
implementowane w systemach relacyjnych (tablice)
odbiegaja od matematycznych relacji. Jakakolwiek
teoria sluszna dla relacji nie musi obowiazywac
dla tych struktur. Semantyka SQL odbiega od ram
formalnych takich jak algebra relacji i rachunek
relacyjny. SQL posiada wiele operatorów nie
rozpatrywanych przez relacyjne teorie, np.
operatory aktualizacyjne, uporzadkowanie,
grupowanie, eliminacja duplikatów, operatory
arytmetyczne, funkcje zagregowane, itd. SQL jest
oparty na logice matematycznej. Przekret w
wykonaniu J. Ullmana. Nie mozna zagniezdzac
obiektowych zapytan, poniewaz nie sa one oparte
na wlasnosci domknietosci (closure property).
Argument dowodzi kompletnego niezrozumienia
tematu. Zapytania w OQL mozna zagniezdzac pomimo
(pozornego) nie spelnienia wlasnosci
domknietosci. Mozna skonstruowac kompletny
jezyk zapytan/programowania oparty wylacznie o
algebre relacji. Te demagogie propaguje utwór
The Third Manifesto H.Darwena i
C.J.Date. Operatory algebry relacji spelniaja te
sama role dla systemów baz danych jak operatory
arytmetyczne dla komputera. Demagogia. Operatory
algebry relacji sa daleko nie wystarczajace do
realizacji nawet najprostszych aplikacji w
systemach relacyjnych. Wewnetrzny mechanizm baz
danych jest oparty o bardzo szeroki zestaw
operatorów, z reguly znacznie odbiegajacych od
operatorów algebry relacji. Systemy obiektowe
nie moga byc (nie sa) wyposazone w jezyki
zapytan. Nieprawda. Moga byc i sa wyposazane np.
w OQL.
28
Czeste mity przy porównaniach (2)
Systemy relacyjne umozliwiajaca matematyczna
weryfikacje poprawnosci zaprojektowanej bazy
danych. Nie umozliwiaja. Projektowanie
relacyjnych baz danych jest z reguly oparte o
calkowicie nieformalny model encja-zwiazek.
Pojecia takie jak 2NF, 3NF, 4NF, BCNF oraz
zwiazane z nimi teorie zaleznosci funkcjonalnych
i wielowartosciowych maja dla praktyki znaczenie
marginalne i sluza prawie wylacznie jako
pseudo-naukowy mul zapychajacy programy nauczania
i podreczniki dla studentów. Projektant
instynktownie unika sytuacji, które nie sa zgodne
z 3NF, 4NF, itd.. Sa sytuacje, kiedy projektant
podejmuje swiadoma decyzje prowadzaca do
niezgodnosci z 3NF i 4NF nie przewiduje ich
teoria. Standard SQL-92 zapewnia pelna
przenaszalnosc oprogramowania pomiedzy róznymi
systemami relacyjnych baz danych. Nie zapewnia.
Sa opinie, ze ponad 95 programów zgodnych z
SQL-92 nie jest przenaszalna. Istnieje kilka
powodów (1) Semantyka SQL-92 jest
wyspecyfikowana nieprecyzyjnie i pozostawia wiele
luk, np. w zakresie dostepu do katalogów (2) SQL
musi byc zanurzony w jezyk programowania (np. C),
którego standaryzacja jest zwykle watpliwa (3)
Dostawcy systemów nie traktuja powaznie kwestii
zgodnosci ze standardem, czyniac dosc dowolne
odstepstwa i rozszerzenia (4) Wiele
oprogramowania bazuje na mutacjach SQL (np. ODBC,
JDBC, PL/SQL systemu Oracle lub OpenRoad systemu
Ingres). Systemy relacyjne umozliwiaja
realizacje dowolnego zastosowania. Nieprawda. Dla
wielu zastosowan struktury relacyjne okazuja sie
zbyt sztywne. Odwzorowanie struktur pojeciowych
(np. struktury klas i asocjacji) na struktury
relacyjne wiaze sie ze znacznym wzrostem
zlozonosci, która moze podwazyc osiagalnosc celów
projektu.
29
Czeste mity przy porównaniach (3)
Obecnosc wskazników w strukturach obiektowych
cofa rozwój do czasów CODASYLu (lat 70-siatych).
Demagogia. W starych systemach sieciowych
programista poslugiwal sie wskaznikami fizycznymi
explicite, co mialo liczne wady. W systemach
obiektowych wskazniki maja charakter pojeciowych
asocjacji, które poprawiaja percepcje schematów
baz danych, znacznie upraszczaja zapytania i
programy, upraszczaja pielegnacje oprogramowania,
redukuja zapotrzebowanie na pamiec i umozliwiaja
znaczna poprawe czasów wykonania poprzez
bezposrednia nawigacje wzdluz wskazników lub np.
poprzez technike przemiany wskazników (pointer
swizzling). Model relacyjny i systemy relacyjne
w unikalny sposób sprzyjaja implementacji
rozproszonych baz danych. Mit uzasadniany
powierzchownymi cechami, takimi jak mozliwosc
latwej dekompozycji relacyjnej bazy danych na
skladowe lub dekompozycji relacji na pod-relacje.
Te cechy nie sa w stanie uproscic zasadniczych
problemów rozproszenia danych, takich jak
przezroczystosc rozproszenia, rozproszone
transakcje, przetwarzanie zapytan w sytuacji
rozproszenia, replikacje, autonomia lokalnych baz
danych, oslony, mediatory i perspektywy do
spadkowych baz danych, itd. Nie widac powodów,
dla których w obiektowych bazach danych te
problemy mialyby byc ciezsze. Pojawienie sie
standardów takich CORBA, DCOM i JavaBeans
sugeruje, ze dalszy rozwój rozproszonych baz
danych bedzie odbywal sie w oparciu o technologie
obiektowe. Obiektowe bazy danych sprowadzaja sie
do dodania cechy trwalosci do obiektowych jezyków
programowania. Nieprawda. Obiektowe bazy danych
sa wyposazane we wszystkie niezbedne mechanizmy
baz danych takie jak zarzadzanie pamiecia
zewnetrzna, schematem, wspólbieznoscia,
odtwarzaniem i transakcjami, srodki
bezpieczenstwa i prywatnosci, przetwarzanie
zapytan, interfejsy do szybkiego tworzenia
aplikacji, srodki wspomagajace rozproszone bazy
danych, i inne.
30
Czeste mity przy porównaniach (4)
Hermetyzacja jest zla, bo bezsensownie ogranicza
bezposredni dostep do danych i uniemozliwia
realizacje jezyka zapytan. Nieporozumienie
wynikajace ze zlej definicji hermetyzacji.
Hermetyzacja, polegajaca na oddzieleniu
specyfikacji od implementacji i ukryciu
nieistotnych szczególów implementacyjnych, jest
podstawowa zasada nie tylko obiektowosci, ale
calej inzynierii oprogramowania. Hermetyzacja w
duchu jezyków Modula-2, C, Java i Eiffel nie
stwarza jakichkolwiek trudnosci koncepcyjnych z
jezykami zapytan lub koniecznosci naruszenia
regul hermetyzacji. Obiektowe jezyki zapytan nie
posiadaja sprawnych metod optymalizacyjnych.
Demagogia, z kilku powodów (1) Podstawowym celem
metod optymalizacyjnych w systemach relacyjnych
jest kosztowna operacja zlaczenia. Poniewaz w
systemach obiektowych zlaczenie jest najczesciej
zmaterializowane w postaci wskazników
(asocjacji), zapotrzebowanie na te operacje jest
znacznie zredukowane (2) Jak wykazuja testy,
optymalizacja relacyjnych jezyków zapytan nie
zawsze jest tak sprawna, jak to jest podkreslane
w literaturze (3) Metody oparte na przepisywaniu
(rewriting), np. przesuwanie selekcji i projekcji
przed zlaczenie, dzialaja tak samo dla jezyków
relacyjnych jak i obiektowych (4) Nie mozna
wskazac powodów, dla których metod sprawnych w
systemach relacyjnych nie mozna zastosowac w
systemach obiektowych (5) Ortogonalnosc i
bardziej precyzyjna semantyka OQL (w stosunku do
SQL) stwarza wiekszy potencjal dla metod
optymalizacyjnych (6) Systemy obiektowe sa o ok.
15 lat mlodsze od relacyjnych, a mimo to wiele
testów pokazuje, ze sa znacznie od nich
sprawniejsze (niekiedy tysiace razy). Obiektowe
bazy danych maja mala wydajnosc. Twierdzenie
dowolne. Patrz wyzej. Obiektowe bazy danych
uniemozliwiaja implementacje perspektyw,
aktywnych regul i zapamietanych procedur.
Twierdzenie dowolne. Ustala stan dzisiejszy jako
niezmienialny.
31
Czeste mity przy porównaniach (5)
Obiektowosc jest teoria, która jak dotad nie
wyszla poza mury uniwersytetów. Odwrotnie,
obiektowosc wynikla z praktyki, zas uniwersytety
dosc czesto nastawily sie wrogo do tej idei,
m.in. ze wzgledu na brak podstaw matematycznych
(t.j. oslabionych mozliwosci budowy teorii,
których jedynym praktycznym celem sa szybkie
akademickie kariery). Obiektowosc jest dobra na
etapie analizy i projektowania, ale jest malo
przydatna dla implementacji. Twierdzenie to
wynika z nieprzystosowania zastosowanych narzedzi
implementacyjnych (np. relacyjnych baz danych,
baz dokumentów typu Lotus Notes, itp.) do pojec i
technik obiektowych. Obiektowosc jest
drugorzedna cecha niektórych jezyków
programowania. Tak od dawna nie jest. Obiektowosc
stala sie uniwersalna idea, przerastajaca caly
system myslenia i technologie realizacji systemów
informacyjnych. Obiektowe systemy baz danych nie
zapewniaja skalowalnosci. Twierdzenie dowolne.
Bazuje na nastepujacej regule wnioskowania
jezeli jakis obiektowy system X nie ma cechy Y,
to wszystkie obiektowe systemy nie maja cechy
Y. Nikt nie uzywa systemów obiektowych dla
rzeczywistych zastosowan. Dawno przestalo byc
prawda. Obiektowe bazy danych nie zapewniaja
(nie moga zapewnic) wlasciwych srodków
przetwarzania transakcji. Nieprawda. Wszystkie
liczace sie systemy obiektowe zapewniaja
przetwarzanie transakcji.
32
Obiektowosc - potencjalne ryzyko
Nieopracowane mechanizmy zarzadzania duza baza
obiektów, sterowania wersjami, rejestrowania
zmian, zapewnienia stabilnosci interfejsów
Technologie obiektowe sa jak dotad stosowane
przez male i srednie organizacje. Nie jest do
konca pewne jak przeskaluja sie dla wielkich
organizacji. Duza liczba tematów znajduje sie
ciagle w fazie laboratoryjnej. Szereg technologii
jest malo stabilnych (np. metodyki projektowania).
Przejscie na technologie obiektowe moze zagrozic
funkcjonowaniu obecnie dzialajacych i sprawnych
systemów, które sa krytyczne dla misji
organizacji.
Zbyt mala liczba ekspertów jest wyszkolona w
zakresie technologii obiektowych.
Nie jest jasne, jakie koszty pociagnie za soba
przejscie na technologie obiektowe.
Standardy w zakresie obiektowosci sa
niedopracowane i niestabilne. Nie wiadomo w jakim
zakresie beda one pelnic swoja funkcje.