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