Obiektowe Bazy Danych kontra Relacyjne Bazy Danych

Obiektowe Bazy Danych
kontra
Relacyjne Bazy Danych
Kazimierz Subieta
Instytut Podstaw Informatyki PAN
Warszawa
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 1
Model relacyjny -rys historyczny
1970 Najbardziej znany, najczęściej cytowany artykuł E.F.Codd’a z IBM proponujący oparcie się na
teorii relacji jako podstawie ideologicznej i teoretycznej architektury, języków i interfejsów systemów
zarządzania bazami danych. Koncepcja została określona jako “relacyjny model danych”, RDM.
1971 - 1975 Zażarta walka ideologiczna pomiędzy zwolennikami RDM a zwolennikami koncepcji
sieciowych baz danych opartych o propozycję grupy DBTG komitetu CODASYL. Walka toczy się o
pieniądze rzędu 100 miliardów $ w skali 20 lat.
1971 - 1985 Intensywny rozwój teorii związanych z RDM. RDM stał się ulubionym konikiem grup
teoretycznych na całym świecie (kilka tysięcy publikacji).
1975-1989 Intensywny rozwój technologii opartych o RDM. Kariera wielu systemów zarzadzania
relacyjnymi bazami danych, takich jak: DB2, Oracle, Ingres, dBase; następnie Informix, Progress,
Sybase, i wiele innych. Szerokie zastosowania na skalę przemysłową, ogromna popularność i pieniądze.
1975 Pierwsze publikacje na temat języka Sequel, poprzednika SQL, autorów z IBM (Chamberlin).
1986 Pierwszy standard języka SQL zaaprobowany przez ANSI. Wykazuje liczne odstępstwa od RDM.
1989, 1992 Następne standardy SQL.
1987 E.F.Codd, sfrustrowany odstępstwami od RDM, publikuje słynne 12 reguł “prawdziwego” systemu
relacyjnego. Żaden z istniejących systemów nie jest “prawdziwym” systemem relacyjnym. Ma rację, ale
nikt tym się nie przejmuje. “Prawdziwego” systemu relacyjnego chyba już nigdy nie będzie.
1985-1997 Intensywna krytyka wad RDM. Świat naukowy zredukował swoje zainteresowanie RDM
praktycznie do zera. Świat komercyjny rozbudowuje systemy bez jakiejkolwiek troski o ideologię RDM.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 2
Model relacyjny - podstawowe założenia
Baza danych składa się z prostokątnych tablic, każda o określonej liczbie kolumn i dowolnej
liczbie wierszy. Takie tablice sa okreslane jako relacje. Wiersz relacji jest nazywany krotką.
Elementy krotek są atomowe (niepodzielne) i są bezpośrednio wartościami. Niedozwolone
jest tworzenie wskaźników prowadzących do innych krotek. Niedozwolone jest, aby element
krotki był zbiorem wartości. Jest to tzw pierwsza forma normalna (1NF).
Porządek krotek nie ma znaczenia. Porządek kolumn również nie ma znaczenia.
Jakiekolwiek cechy odnoszące się do reprezentacji relacji lub usprawnienia dostępu do relacji
są ukryte przed użytkownikiem.
Relacje i ich kolumny posiadają nazwy. Nazwy kolumn są określane jako atrybuty.
Każda relacja posiada wyróżniony atrybut lub grupę atrybutów określną jako klucz. Wartość
klucza w unikalny sposób identyfikuje krotkę relacji. Jakakolwiek inna identyfikacja krotki
(np. wewnętrzny identyfikator) jest niewidoczna dla użytkownika.
Manipulacja relacjami odbywa się w sposób makroskopowy przy pomocy operatorów algebry
relacji lub innego tego rodzaju języka. Przetwarzanie “krotka po krotce” jest niedozwolone.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 3
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 być bardzo złożone.
Semantyka jest dość często niejasna (“SQL puzzles”).
Oprócz zdania select SQL wprowadza:
• zdania definicji danych
• zdania manipulacji danymi (update, insert, delete )
Mimo to, SQL nie jest pełnym językiem programowania, w związku z czym wymaga:
• Zanurzenia zdań SQL w uniwersalny język programowania
• Zdań pośredniczących, które umożliwiają takie zanurzenie
Konsekwencją połączenia dwóch róznych języków jest niekorzystny efekt określany jako
niezgodność impedancji.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 4
SQL: proste zdania select
Zakładamy tablice: PRACOWNIK( NR, NAZWISKO, ZAROBEK, NRDZ)
DZIAŁ( NRDZ, NAZWA, LOKALIZACJA )
Podaj nazwiska pracowników zarabiających mniej niż 1000:
select NAZWISKO from PRACOWNIK where ZAROBEK > 1000
Podaj nazwiska i nazwy działów pracowników pracujących w Radomiu:
select P.NAZWISKO, D.NAZWA from PRACOWNIK P, DZIAŁ D
where P.NRDZ = D.NRDZ and D.LOKALIZACJA = ‘Radom’
Semantyka
Zaczynamy od from: Specyfikujemy tablice do przeszukania oraz ew. ich lokalne
synonimy (ściślej: zmienne krotkowe). Tworzymy iloczyn kartezjański tablic.
Następnie where: Usuwamy z tablicy lub iloczyny kartezjańskiego takie krotki, które nie
spełniają warunku.
Na końcu select: Bierzemy z każdej wynikowej krotki to, co jest potrzebne.
SQL
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 5
Na bazie tego prostego pomysłu utworzono gigantyczną
odwróconą piramidę (setki stron specyfikacji)
Co to jest “niezgodność impedancji”? (1)
Zespół niekorzystnych zjawisk towarzyszących formalnemu połączeniu języka zapytań
(np. SQL) z uniwersalnym językiem programowania (np. C, Cobol lub PL/I) .
Objawia się niezgodnościami w zakresie:
Składni: Programista musi w jednym tekście programu używać dwóch stylów językowych i przestrzegać
reguł dwóch różnych gramatyk.
Systemu typów: Język zapytań operuje na typach zdefiniowanych w schemacie bazy danych, m.in.
relacjach, natomiast język programowania posiada zwykle odmienny system typów, w którym nie
występuje typ relacja. Większość języków programowania ma wbudowaną statycznej kontrolę typów,
podczas gdy SQL takiej kontroli nie przewiduje.
Semantyki i paradygmatów języków: Koncepcja semantyki jezyków jest zasadniczo różna. Język zapytań
bazuje na stylu deklaracyjnym (co wyszukać, a nie jak) podczas gdy języki programowania bazują na stylu
imperatywnym (jak zrobić, a nie co).
Pragmatyki użycia: Język zapytań uwalnia programistę od wielu szczegółów organizacji i implementacji
danych (np. organizacji zbiorów, obecności lub nieobecności indeksów, itd.), podczas gdy w języku
programowania te szczegóły muszą być oprogramowane explicite.
Faz i mechanizmów wiązania: Języki zapytań są oparte o późne wiązanie (są interpretowane) podczas gdy
języki programowania zakładają wczesne wiązanie (podczas kompilacji i konsolidacji). Stwarza to
problemy m.in. dla programów odpluskwiających (debugger).
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 6
Co to jest “niezgodność impedancji”? (2)
Dodatkowo objawia się niezgodnościami w zakresie:
Przestrzeni nazw i reguł zakresu: Język zapytań i język programowania posiadają własne przestrzenie
nazw, które mogą zawierać identyczne nazwy o różnych znaczeniach. Odwzorowania pomiędzy
przestrzeniami nazw wymagają dodatkowych środków syntaktycznych i semantycznych. Przestrzeń nazw
języka programowania jest zbudowana hierarchicznie i podlega regułom zakresu opartym o zasadę stosu.
Te reguły są ignorowane przez język zapytań powodując wiele trudności.
Schematów iteracyjnych: W języku zapytań iteracje są wtopione w semantykę operatorów takich jak
selekcja, projekcja i złączenie. W języku programowania iteracje muszą być organizowane explicite przy
pomocy pętli for, while, repeat lub innych. Przetwarzanie wyników zapytań przy pomocy języka
programowania wymaga specjalnych udogodnień takich jak kursory i iteratory.
Traktowania cechy trwałości danych: Języki zapytań przetwarzają wyłącznie trwałe dane (znajdujące się
na dysku), podczas gdy języki zapytań przetwarzają wyłącznie dane nietrwałe znajdujące się w pamięci
operacyjnej. Połączenie języków wymaga od programisty użycia specjalnych środków językowych do
parametryzacji zapytań przez zmienne języka programowania oraz środków językowych i
architektonicznych służących do transmisji danych z dysku do pamięci operacyjnej i odwrotnie.
Środków programowania ogólnego (generic): Środki te w języku zapytań są oparte o refleksję (patrz np.
dynamiczny SQL). Użycie podobnego środka w języku programowania jest zazwyczaj niemożliwe z
powodu wczesnego wiazania. Stosowane są inne środki, takie jak funkcje wyższego rzędu, casting,
przejście na niższy poziom językowy, polimorfizm lub szablony.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 7
Co to jest niezgodność pomiędzy modelem
pojęciowym i modelem implementacyjnym?
Celem jest uzyskanie jak najmniejszej luki pomiędzy myśleniem o rzeczywistości
a myśleniem o danych i procesach, które zachodzą na danych.
Mentalna percepcja
świata rzeczywistego
Model
pojęciowy
Schemat relacyjnej
struktury danych
W modelu relacyjnym model pojęciowy jest budowany w oparciu o model encja-związek.
Model encja-związek stara się odwzorować świat rzeczywisty, lecz nie może być bezpośrednio
zaimplementowany, gdyż relacyjna baza danych na to nie pozwala. W rezultacie,
- schemat struktury danych gubi znaczną część semantyki danych,
- użytkownik musi kojarzyć dane explicite w zdaniach SQL, co zwiększa ich złożoność
i powoduje wzrost czasów wykonania.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 8
Niezgodność modelu pojęciowego i relacyjnego(1)
Departament
NrD
NazwaD
Lokacja *
Zatrudnia
Pracownik
Pracuje_w NrPrac
Zawód *
Wypłaty *
Szef
Osoba
Nazwisko
Adres *
RokUrodz
Mama
Dziecko
Dziecko
Tata
Ile schematów relacyjnych potrzeba, aby zaimplementować tę strukturę?
Departament( NrD, NazwaD )
Lokacja( NrLokacji, NazwaLok, NrD )
Szef( NrD, NrPrac)
Pracownik( NrPrac, NrOsoby)
PracDept( NrPrac, NrD)
Zawód( IdZawodu, NazwaZawodu, NrPrac )
Wypłata ( IdWypłaty,Wysokość, NrPrac )
Osoba( NrOsoby, Nazwisko, RokUrodz )
Adres( NrAdresu, Miejsce, NrOsoby )
Mama( NrOsoby, NrOsoby )
Tata( NrOsoby, NrOsoby )
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 9
Czytelna pojęciowa struktura zamieniła się
na 11 nieczytelnych schematów relacji
Pojawiły się nowe atrybuty - klucze
Semantyka wyrażona poprzez liczności
została częściowo zgubiona
Semantyka dziedziczenia została zgubiona
Odtworzenie semantyki - użytkownik musi
zrobić explicite poprzez zapytania SQL
Niezgodność modelu pojęciowego i relacyjnego(2)
Firma
Nazwa
Miejsce *
FZ
Zatrudnienie
Wypłata *
Ocena *
PZ
Osoba
Nazwisko
Imię *
Adres *
Pracownik
Zawód *
Firma( NrF, Nazwa)
Lokal( NrF, Miejsce)
Zatrudnienie( NrF, NrP)
Pracownik( NrP, NrOs)
Oceny( NrOceny, Ocena, NrF, NrP)
Dochód( NrDochodu, Wypłata, NrF, NrP)
Osoba( NrOs, Nazwisko)
Wyszkolenie( Zawód, NrP)
Imiona( NrOs, Imię)
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 10
Adresy( NrOs, Adres)
Zapytania w OQL i SQL
Podaj adresy pracowników zatrudnionych w firmach zlokalizowanych w Radomiu:
OQL:
select z.Adres
from Firma as x, x.FZ as y, y.PZ as z
where “Radom” in x.Miejsce
(26 jednostek leksykalnych)
SBQL:
(Firma where “Radom” in Miejsce).FZ.Zatrudnienie.PZ.Pracownik.Adres
(17 jednostek leksykalnych)
SQL:
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
(62 jednostki leksykalne)
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 11
Garby modelu relacyjnego
Z góry ustalony konstruktor typu danych (relacja), rozszerzany ad hoc przez wytwórców
systemów relacyjnych. Brak złożonych obiektów. Informacje o pojęciach wyróżnialnych
i manipulowalnych w rzeczywistości są rozproszone w krotkach wielu tablic.
Skojarzenie tych informacji następuje w zapytaniach SQL, przez co wzrasta ich
złożoność oraz czas wykonania (optymalizacja zapytań tylko częściowo to rozwiązuje).
Brak wyspecjalizowanych środków do realizacji powiązań pomiędzy danymi.
Brak środków do przechowywania danych proceduralnych. Wszelkie informacje
wykraczające poza strukturę relacyjną (perspektywy, procedury bazy danych, BLOBy,
aktywne reguły,...) są implementowane ad hoc.
Brak środków hermetyzacji i modularyzacji: wykroczenie przeciwko zasadom
abstrakcji i oddzielenia implementacji od specyfikacji.
Brak uniwersalności środków dostępu do danych, powodujący konieczność zanurzenia ich
w uniwersalne języki programowania, znacznie niższego poziomu; niezgodność impedancji
(impedance mismatch). Niespełnione obietnice przetwarzania makroskopowego
(wiele-w-tym-samym-czasie); powrót do niewygodnej techniki jeden-w-tym-samym-czasie.
Niespójne mechanizmy wartości zerowych, brak wariantów, brak porządku w relacjach.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 12
Obiektowe bazy danych
Teza: bazy danych zawsze były obiektowe, chociaż nie realizowały wszystkich
pojęć obiektowości, takich jak klasy, metody i dziedziczenie.
Podstawowy wyróżnik: trwałe
obiekty + identyfikatory obiektów
Zmniejszenie dystansu pomiędzy fazami analizy, projektowania i implementacji
Zwiększenie poziomu abstrakcji w myśleniu programistów i użytkowników
Uwzględnienie informacji proceduralnej (metody)
Stworzenie nowego potencjału dla ponownego użycia
Docelowa tendencja - ortogonalna trwałość:
Programista podczas programowania nie musi nic wiedzieć o bazie danych,
operując na jej obiektach tak jak na obiektach/zmiennych programu.
Baza danych powinna być niewidoczna (przezroczysta).
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 13
Co zdarzyło się w systemach po przejściu na
technologie obiektowe?
Część informacji semantycznej, która tradycyjnie tkwiła w bibliotekach, typach,
aplikacjach, modułach została umieszczona i usystematyzowana w ramach klas.
Relacyjna
struktura aplikacji
Obiektowa
struktura aplikacji
Powiązane obiekty
Pasywne dane
(relacje)
... ...
... ...
... ... ...
... ... ...
Klasy i typy
...
...
...
...
...
...
... ... ...
... ... ...
...
...
...
...
...
...
...
...
...
Biblioteki
procedur i funkcji
Słowniki,
katalogi
Typy
Moduły
aplikacyjne
Procedury bazy danych,
perspektywy, reguły
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 14
Biblioteki
procedur i funkcji
Słowniki,
katalogi
...
...
...
Moduły
aplikacyjne
Procedury bazy danych,
perspektywy, reguły
Obiektowy SZBD jest to SZBD
Klasyczne funkcje SZBD:
 Zarządzanie pamięcią zewnętrzną
 Zarządzanie schematem
 Sterowanie współbieżnością
 Zarządzanie transakcjami
 Odtwarzalność
 Przetwarzanie zapytań
 Kontrola dostępu
Do tych funkcji dołożone są:
 Złożone obiekty
 Typy definiowane przez użytkownika
 Tożsamość obiektów
 Powiązania pomiędzy obiektami
 Hermetyzacja, interfejsy do obiektów
 Typy i/lub klasy oraz hierarchia dziedziczenia
 Przełanianie/przeciążanie/późne wiązanie
 Kompletność obliczeniowa (pragmatyczna)
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 15
Manifest obiektowych baz danych
połowa 1989
M.Atkinson, F.Bancilhon, D.DeWitt, K.Dittrich, D.Maier, S. Zdonik
Cechy obowiązkowe
 złożone obiekty
 przesłanianie z dynamicznym wiązaniem
 tożsamość obiektów
 rozszerzalność
 hermetyzacja
 kompletność obliczeniowa
 dziedziczenie
 zarządzanie pamięcią pomocniczą
 typy lub klasy
 współbieżność, odtwarzanie
 trwałość
 udogodnienia dla zapytań ad hoc
Cechy opcyjne
Cechy otwarte
wielokrotne dziedziczenie, kontrola typów,
rozproszenie, transakcje projektowe, wersje
paradygmat programowania, metody reprezentacji obiektów,
system typów, jednolitość (kompatybilność)
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 16
Manifest baz danych “trzeciej generacji” (3GBD)
początek 1990
Doktryny:
M.Stonebraker, L.Rowe, B.Lindsay, J.Gray, M.Carey, M.Brodie, P.Bernstein, D.Beach
 3GBD mają wspomagać bogatsze struktury danych i reguły
 3GBD muszą posiadać wszystkie pozytywne cechy 2GBD
 3GBD muszą być otwarte dla innych systemów
13 postulatów:
 3GBD muszą posiadać bogaty system typów
 Dziedziczenie jest dobrym pomysłem
 Funkcje (włączając zapamiętane procedury i metody) + hermetyzacja są dobrymi pomysłami.
 Unikalne identyfikatory powinny być stosowane wtedy, gdy nie są dostępne klucze pierw.
 Reguły (wyzwalacze, więzy) staną sie główną cechą przyszłych systemów
 Cały dostęp do bazy danych powinien odbywać się poprzez nieproceduralny język wys.poz.
 Kolekcje powinny być specyfikowane zarówno przez ich wyliczenie jak i poprzez zapytanie
 Aktualizowanle perspektywy są istotne
 Własności fizyczne nie mają związku z modelem danych i powinny być z niego usuniete
 3GBD muszą być dostępne z wielu języków wysokiego poziomu
 Języki te powinny być wyposazone w cechę trwałości i możliwości języków zapytań
 Na lepsze i gorsze, SQL jest intergalaktycznym językiem danych
 Zapytania i odpowiedzi na zap. powinny być dolnym poziomem komunikacji klient-serwer
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 17
Systemy obiektowo-relacyjne
Powstają w wyniku ostrożnej ewolucji systemów relacyjnych w kierunku obiektowości,
liczą na pozycję systemów relacyjnych na rynku i odwołują się do ich wiernej klienteli.
Nacisk dwóch tendencji:
Rynek domaga się cech pozwalających zniwelować niedostatki relacyjnej technologii,
szczególnie w zakresie danych multimedialnych, związania z danymi informacji
behawioralnej (reguł, metod), modelowania pojęciowego i środków programowania
aplikacji.
Pokusa wprowadzenia wielu cech obiektowości, takich jak klasy, metody, dziedziczenie,
abstrakcyjne typy danych, pozwalających na twierdzenia o „częściowej obiektowości”
systemów relacyjnych.
Podejście jest określane jako „hybrydowe” lub „obiektowo-relacyjne”.
Ostatnio karierę robi także termin „uniwersalny serwer” (universal server)
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 18
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 (duże obiekty BLOB, CLOB i pliki binarne),
Dane przestrzenne (spatial),
Abstrakcyjne typy danych (ADT),
Metody (funkcje i procedury) definiowane przez użytkownika w różnych językach (C++, VisualBasic, Java)
Kolekcje (zbiory, wielozbiory, sekwencje, zagnieżdżone tablice, tablice o zmiennej długości),
Typy referencyjne,
Przeciążanie funkcji,
Późne wiązanie
....
Zachowują wiele technologii, które sprawdziły się w systemach relacyjnych, takie jak:
architektura klient/serwer,
mechanizmy buforowania i indeksowania,
przetwarzanie transakcji,
optymalizacja zapytań
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 19
Po co systemy obiektowo-relacyjne?
Szybki i pewny zysk
Komercyjny sukces nie jest jednak sprawą pewną:
Informix osiągnął w 1997 r. wynik finansowy o 100 mln.$ niższy niż zakładał plan,
Dobre wyniki osiąga Oracle8,
prawdopodobnie wskutek zintegrowania produktu z ogromnym pakietem usług i udogodnień.
Ideologiczne zalety obiektowo-relacyjnych baz danych są nieprzekonywujące:
z koncepcyjnego punktu widzenia obiektowe bazy danych włączają struktury relacyjne jako
przypadek szczególny.
Galimatias komercyjnej retoryki powodujący mnóstwo nieporozumień.
Mnożenie bytów ponad potrzebę wskutek relacyjnej „spuścizny”
Brak bazy intelektualnej, a raczej jej rozmydlenie i rozbełtanie
Totalnie niekompatybilne: muszą odejść od standardu SQL-92 (nowe struktury danych)
Powołują się na standard SQL3, który będzie gotowy (?) za 3-5 lat
Systemy obiektowo-relacyjne mają wyraźny posmak dekadencji,
eklektyzmu i kryzysu koncepcji - cech swoistych dla granicy epok.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 20
SQL 3
Nowy standard języka SQL, opracowywany przez ANSI oraz ISO,
następca i rozszerzenie SQL-92.
W założeniu, uniwersalny język programowania dla relacyjnych baz danych z obiektowością.
Kompatybilność „w dół” ze standardem SQL-92.
Abstrakcyjne typy danych (ADT),
Metody pisane w SQL3 lub w innych językach.
Identyfikatory obiektów
Podtypy
Dziedziczenie,
Polimorfizm,
Integracja z językami zewnętrznymi
Usprawnienia konstrukcji definiujących tablice
typy wierszy,
identyfikatory wierszy
mechanizm dziedziczenia.
Struktury sterujące
Typy parametryczne
Tablica ma kolumnę IDENTITY, która zawiera TID.
Atrybuty obliczane (metody funkcyjne)
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 21
Dla dowolnej zadeklarowanej
tablicy można zadeklarować
podtablicę, która zawiera
wszystkie kolumny macierzystej
tablicy plus niektóre nowe
kolumny.
SQL3 -charakterystyka
Jak dotąd, rozszerzenia w SQL3 są redundantne i niezbyt spójne.
Standard znajduje się w fazie opracowywania i będzie gotowy przypuszczalnie w
latach 2000-2002.
Kontrowersje wzbudza ogromna objętość tego standardu, powodowana przez
nagromadzenie różnych pomysłów bez klarownie wyartykułowanego modelu
danych i podstawy ideologiczno-teoretycznej. Mówi się, ze już ma 1200 - 1500
stron, a ciągle rośnie
Kontrowersyjne jest podjęcie prac badawczo-rozwojowych w zakresie konstrukcji
języka programowania baz danych przez ciało standaryzacyjne, statutowo
powołane do innych celów i posiadające inne kompetencje.
Istnieje koncepcja integracji języków SQL3 i OQL wg standardu ODMG, chociaż
wobec zupełnie innych założeń hasła integracji chyba nikt nie traktuje poważnie.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 22
Obiektowość kontra model relacyjny
Warstwa technologii (1)
Sprzymierzeńcem wszystkich wdrożonych technologii baz danych, w tym relacyjnych,
jest ogromna bezwładność rynku zastosowań, który niechętnie zmienia swoje
preferencje, szczególnie jeżeli zostały zainwestowane duże pieniądze i czas.
Jeżeli jakaś koncepcja technologiczna opanowała pewną dziedzinę zastosowań i/lub teren
geograficzny, wówczas trudno zastąpić ją inną koncepcją, nawet jeżeli jest ona lepsza.
Klient baz danych nie lubi kosztownych zmian i musi mieć pewność, że nie pozostanie sam
i może liczyć na środowisko specjalistów jak i ogólną kulturę techniczną wytworzoną w
związku z daną technologią.
Systemy relacyjne opanowały dużą grupę „nisz ekologicznych” i można przyjąć, że
pozostaną w nich przez kilka, kilkanaście, lub nawet kilkadziesiąt lat.
Systemy obiektowe muszą poszukiwać innych nisz, które nie są zagospodarowane przez
wcześniejsze technologie. Potencjalnym polem zastosowań obiektowych baz danych są
multimedia, dziedziny wymagające bardziej rozbudowanych struktur danych, takie jak CAD
(Computer Aided Design), CAM (Computer Aided Manufacturing), CASE, lub dziedziny
implikujące nieregularne, niesformatowane struktury danych, takie jak zastosowania pełnotekstowe, hurtownie danych, zastosowania biurowe.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 23
Obiektowość kontra model relacyjny
Warstwa technologii (2)
Prawie wszystkie systemy relacyjne przechodzą etap radykalnych modernizacji (m.in., a
może przede wszystkim) w związku z wyzwaniem jakie stawiają technologie obiektowe.
Następuje wzmocnienie struktur danych przechowywanych w systemach relacyjnych o
nowe możliwości. Rozszerzenia te wprowadzają wiele elementów obiektowości.
Wiele systemów relacyjnych jest wyposażane w możliwość współdziałania z innymi
systemami (w tym nie-relacyjnymi) według standardu obiektowego OMG CORBA.
Ponad 90% programów rzekomo „zgodnych” ze standardem SQL-92 nie daje się przenieść
na inne platformy SZBD, głównie ze względu na niepełność tych standardów oraz
niekompatybilne rozszerzenia implementowane w poszczególnych systemach.
Specjaliści powątpiewają co do implementowalności SQL3
Nie istnieje własność systemów relacyjnych, która nie mogłaby być równie dobrze
zrealizowana w systemach obiektowych
Wbrew rozpowszechnianym mitom, obiektowość sprzyja wydajności m.in. poprzez
technikę przemiany wskaźników (pointer swizzling), indeksy ścieżkowe (path indices),
oraz poprzez nowe mechanizmy indeksacji i buforowania umożliwiającymi istotne
przesunięcie przetwarzania na stronę klienta w architekturze klient-serwer.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 24
Obiektowość kontra model relacyjny
Warstwa ideologii
Model relacyjny przegrał konfrontację z obiektowością w warstwie ideologicznej.
Dzisiaj nie jest widoczny liczący się ośrodek naukowy, który aktywnie rozwijałby
model relacyjny od strony ideologiczno-naukowej.
Główną wadą koncepcyjną modelu relacyjnego jest to, co miało być jego zaletą, mianowicie
prostota struktur danych. Informacje o pojęciach wyróżnialnych w rzeczywistości są
rozproszone w krotkach wielu tablic, co burzy związek pomiędzy pojęciowym obrazem
świata, a pojęciowym obrazem struktur danych modelujących ten świat.
Model relacyjny nie zajmuje się informacją proceduralną, która często jest istotną składową
obrazu pojęciowego danych. Wobec braku systematycznych środków, wszelkie informacje
wykraczające poza strukturę relacyjną są implementowane ad hoc.
Ideologia relacyjna jest oparta na naiwnych poglądach co do środków przetwarzania
informacji. Trzonem tych środków miały być operatory algebry relacji lub rachunku
relacyjnego; niestety, okazały się one zbyt mało uniwersalne. Duża część tego
przetwarzania musiała być oddelegowana do uniwersalnych języków programowania, co
doprowadziło do niekorzystnego efektu niezgodności impedancji. W konsekwencji
postulowane przez model relacyjny przetwarzanie makroskopowe wróciło do niesławnego
przetwarzania niskiego poziomu, np. poprzez kursory w zagnieżdżonym SQL.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 25
Obiektowość kontra model relacyjny
Warstwa teorii
Nieautentyczny, dekoracyjny charakter relacyjnych teorii. Są pseudo-naukowymi fasadami.
Zastosowanie teorii zależności funkcjonalnych, wielowartościowych i innych, sprowadza się
do definicji kilku pojęć (2NF, 3NF,...) o znaczeniu marginalnym dla praktyki projektowania.
Oparcie semantyki języków zapytań takich jak SQL o algebrę relacji lub rachunek relacyjny
jest pomysłem całkowicie nieudanym. Teorie te są niedostatecznie uniwersalne dla SQL.
Mitem są twierdzenia, że metody optymalizacji zapytań są konsekwencją odkrytych własności
algebry relacji.
Całkowite fiasko badań nad niekompletną informacją (setki publikacji!) . Rozwiązania w tym
zakresie są pozbawione logiki i konsekwencji. Całkowite fiasko rozszerzeń teoretycznych
takich jak uniwersalne relacje i dedukcyjne bazy danych (setki publikacji!).
W systemach „post-relacyjnych” lub „obiektowo-relacyjnych” termin „relacyjny” ma
wyłącznie znaczenie tradycyjno-dekoracyjne. Systemy te, poprzez rozbudowę własności
struktur danych i języków przetwarzania danych, nie są w stanie skorzystać z własności
matematycznego pojęcia relacji w duchu relacyjnego modelu danych.
Twierdzenia, że model relacyjny posiada „solidne podstawy matematyczne” zaś
obiektowość ich nie posiada są fałszywymi stereotypami i popisami demagogów.
Zarówno systemy relacyjne, jak SQL, jak i systemy obiektowe nie mają istotnej teorii.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 26
Częste mity przy porównaniach (1)
W odróżnieniu od systemów obiektowych, systemy relacyjne i SQL posiadają solidne podstawy
matematyczne. Nieprawda. Struktury danych implementowane w systemach relacyjnych (tablice)
odbiegają od matematycznych relacji. Jakakolwiek teoria słuszna dla relacji nie musi obowiązywać 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,
uporządkowanie, grupowanie, eliminacja duplikatów, operatory arytmetyczne, funkcje zagregowane, itd.
SQL jest oparty na logice matematycznej. Przekręt w wykonaniu J. Ullmana.
Nie można zagnieżdżać obiektowych zapytań, ponieważ nie są one oparte na własności domkniętości
(closure property). Argument dowodzi kompletnego niezrozumienia tematu. Zapytania w OQL można
zagnieżdżać pomimo (pozornego) nie spełnienia własności domkniętości.
Można skonstruować kompletny język zapytań/programowania oparty wyłącznie o algebrę relacji.
Tę demagogię propaguje utwór „The Third Manifesto” H.Darwena i C.J.Date.
Operatory algebry relacji spełniają tę samą rolę dla systemów baz danych jak operatory
arytmetyczne dla komputera. Demagogia. Operatory algebry relacji są daleko nie wystarczające do
realizacji nawet najprostszych aplikacji w systemach relacyjnych. Wewnętrzny mechanizm baz danych jest
oparty o bardzo szeroki zestaw operatorów, z reguły znacznie odbiegających od operatorów algebry relacji.
Systemy obiektowe nie mogą być (nie są) wyposażone w języki zapytań. Nieprawda. Mogą być i są
wyposażane np. w OQL.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 27
Częste mity przy porównaniach (2)
Systemy relacyjne umożliwiającą matematyczną weryfikację poprawności zaprojektowanej bazy
danych. Nie umożliwiają. Projektowanie relacyjnych baz danych jest z reguły oparte o całkowicie
nieformalny model encja-związek. Pojęcia takie jak 2NF, 3NF, 4NF, BCNF oraz związane z nimi teorie
zależności funkcjonalnych i wielowartościowych mają dla praktyki znaczenie marginalne i służą prawie
wyłącznie jako pseudo-naukowy muł zapychający programy nauczania i podręczniki dla studentów.
Projektant instynktownie unika sytuacji, które nie są zgodne z 3NF, 4NF, itd.. Są sytuacje, kiedy projektant
podejmuje świadomą decyzję prowadzącą do niezgodności z 3NF i 4NF; nie przewiduje ich teoria.
Standard SQL-92 zapewnia pełną przenaszalność oprogramowania pomiędzy różnymi systemami
relacyjnych baz danych. Nie zapewnia. Są opinie, że 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 dostępu do katalogów; (2) SQL musi być zanurzony w język
programowania (np. C), którego standaryzacja jest zwykle wątpliwa; (3) Dostawcy systemów nie traktują
poważnie kwestii zgodności ze standardem, czyniąc dość dowolne odstępstwa i rozszerzenia; (4) Wiele
oprogramowania bazuje na mutacjach SQL (np. ODBC, JDBC, PL/SQL systemu Oracle lub OpenRoad
systemu Ingres).
Systemy relacyjne umożliwiają realizację dowolnego zastosowania. Nieprawda. Dla wielu zastosowań
struktury relacyjne okazują się zbyt sztywne. Odwzorowanie struktur pojęciowych (np. struktury klas i
asocjacji) na struktury relacyjne wiąże się ze znacznym wzrostem złożoności, która może podważyć
osiągalność celów projektu.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 28
Częste mity przy porównaniach (3)
Obecność wskaźników w strukturach obiektowych cofa rozwój do czasów CODASYLu (lat 70siątych). Demagogia. W starych systemach sieciowych programista posługiwał się wskaźnikami
fizycznymi explicite, co miało liczne wady. W systemach obiektowych wskaźniki mają charakter
pojęciowych asocjacji, które poprawiają percepcję schematów baz danych, znacznie upraszczają zapytania i
programy, upraszczają pielęgnację oprogramowania, redukują zapotrzebowanie na pamięć i umożliwiają
znaczną poprawę czasów wykonania poprzez bezpośrednią nawigację wzdłuż wskaźników lub np. poprzez
technikę przemiany wskaźników (pointer swizzling).
Model relacyjny i systemy relacyjne w unikalny sposób sprzyjają implementacji rozproszonych baz
danych. Mit uzasadniany powierzchownymi cechami, takimi jak możliwość „łatwej” dekompozycji
relacyjnej bazy danych na składowe lub dekompozycji relacji na pod-relacje. Te cechy nie są w stanie
uprościć zasadniczych problemów rozproszenia danych, takich jak przezroczystość rozproszenia,
rozproszone transakcje, przetwarzanie zapytań w sytuacji rozproszenia, replikacje, autonomia lokalnych
baz danych, osłony, mediatory i perspektywy do spadkowych baz danych, itd. Nie widać powodów, dla
których w obiektowych bazach danych te problemy miałyby być cięższe. Pojawienie się standardów takich
CORBA, DCOM i JavaBeans sugeruje, że dalszy rozwój rozproszonych baz danych będzie odbywał się w
oparciu o technologie obiektowe.
Obiektowe bazy danych sprowadzają się do dodania cechy trwałości do obiektowych języków
programowania. Nieprawda. Obiektowe bazy danych są wyposażane we wszystkie niezbędne
mechanizmy baz danych takie jak: zarządzanie pamięcią zewnętrzną, schematem, współbieżnością,
odtwarzaniem i transakcjami, środki bezpieczeństwa i prywatności, przetwarzanie zapytań, interfejsy do
szybkiego tworzenia aplikacji, środki wspomagające rozproszone bazy danych, i inne.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 29
Częste mity przy porównaniach (4)
Hermetyzacja jest zła, bo bezsensownie ogranicza bezpośredni dostęp do danych i uniemożliwia
realizację języka zapytań. Nieporozumienie wynikające ze złej definicji hermetyzacji. Hermetyzacja,
polegająca na oddzieleniu specyfikacji od implementacji i ukryciu nieistotnych szczegółów
implementacyjnych, jest podstawową zasadą nie tylko obiektowości, ale całej inżynierii oprogramowania.
Hermetyzacja w duchu języków Modula-2, C++, Java i Eiffel nie stwarza jakichkolwiek trudności
koncepcyjnych z językami zapytań lub konieczności naruszenia reguł hermetyzacji.
Obiektowe języki zapytań nie posiadają sprawnych metod optymalizacyjnych. Demagogia, z kilku
powodów: (1) Podstawowym celem metod optymalizacyjnych w systemach relacyjnych jest kosztowna
operacja złączenia. Ponieważ w systemach obiektowych złączenie jest najczęściej zmaterializowane w
postaci wskaźników (asocjacji), zapotrzebowanie na tę operację jest znacznie zredukowane; (2) Jak
wykazują testy, optymalizacja relacyjnych języków zapytań nie zawsze jest tak sprawna, jak to jest
podkreślane w literaturze; (3) Metody oparte na przepisywaniu (rewriting), np. przesuwanie selekcji i
projekcji przed złączenie, działają tak samo dla języków relacyjnych jak i obiektowych; (4) Nie można
wskazać powodów, dla których metod sprawnych w systemach relacyjnych nie można zastosować w
systemach obiektowych; (5) Ortogonalność i bardziej precyzyjna semantyka OQL (w stosunku do SQL)
stwarza większy potencjał dla metod optymalizacyjnych; (6) Systemy obiektowe są o ok. 15 lat młodsze od
relacyjnych, a mimo to wiele testów pokazuje, że są znacznie od nich sprawniejsze (niekiedy tysiące razy).
Obiektowe bazy danych mają małą wydajność. Twierdzenie dowolne. Patrz wyżej.
Obiektowe bazy danych uniemożliwiają implementację perspektyw, aktywnych
zapamiętanych procedur. Twierdzenie dowolne. Ustala stan dzisiejszy jako niezmienialny.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 30
reguł
i
Częste mity przy porównaniach (5)
Obiektowość jest teorią, która jak dotąd nie wyszła poza mury uniwersytetów. Odwrotnie,
obiektowość wynikła z praktyki, zaś uniwersytety dość często nastawiły się wrogo do tej idei, m.in. ze
względu na brak „podstaw matematycznych” (t.j. osłabionych możliwości budowy „teorii”, których
jedynym praktycznym celem są szybkie akademickie kariery).
Obiektowość jest dobra na etapie analizy i projektowania, ale jest mało przydatna dla implementacji.
Twierdzenie to wynika z nieprzystosowania zastosowanych narzędzi implementacyjnych (np. relacyjnych
baz danych, baz dokumentów typu Lotus Notes, itp.) do pojęć i technik obiektowych.
Obiektowość jest drugorzędną cechą niektórych języków programowania. Tak od dawna nie jest.
Obiektowość stała się uniwersalną ideą, przerastającą cały system myślenia i technologie realizacji
systemów informacyjnych.
Obiektowe systemy baz danych nie zapewniają skalowalności. Twierdzenie dowolne. Bazuje na
następującej „regule wnioskowania”: jeżeli jakiś obiektowy system X nie ma cechy Y, to wszystkie
obiektowe systemy nie mają cechy Y.
Nikt nie używa systemów obiektowych dla rzeczywistych zastosowań. Dawno przestało być prawdą.
Obiektowe bazy danych nie zapewniają (nie mogą zapewnić) właściwych środków przetwarzania
transakcji. Nieprawda. Wszystkie liczące się systemy obiektowe zapewniają przetwarzanie transakcji.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 31
Obiektowość - potencjalne ryzyko
Nieopracowane mechanizmy zarządzania dużą bazą obiektów, sterowania
wersjami, rejestrowania zmian, zapewnienia stabilności interfejsów
Technologie obiektowe są jak dotąd stosowane przez małe i średnie organizacje.
Nie jest do końca pewne jak przeskalują się dla wielkich organizacji.
Duża liczba tematów znajduje się ciągle w fazie laboratoryjnej.
Szereg technologii jest mało stabilnych (np. metodyki projektowania).
Przejście na technologie obiektowe może zagrozić funkcjonowaniu obecnie
działających i sprawnych systemów, które są krytyczne dla misji organizacji.
Zbyt mała liczba ekspertów jest wyszkolona w zakresie technologii obiektowych.
Nie jest jasne, jakie koszty pociągnie za sobą przejście na technologie obiektowe.
Standardy w zakresie obiektowości są niedopracowane i niestabilne.
Nie wiadomo w jakim zakresie będą one pełnić swoją funkcję.
K.Subieta. Obiektowe BD kontra Relacyjne BD, Folia 32