ObiektowoϾ w bazach danych koncepcje, nadzieje I fakty



Pobieranie 146.68 Kb.
Strona1/2
Data29.10.2017
Rozmiar146.68 Kb.
  1   2

Obiektowość w bazach danych - koncepcje, nadzieje i fakty

Część 3. Obiektowość kontra model relacyjny

Kazimierz Subieta


Pojawienie się obiektowych baz danych jako konkurencji dla baz relacyjnych zburzyło spokój zarówno dostawców systemów, jak i ich klientów. Dla dostawców rynek baz danych, szacowany na 5-7 mld.$ rocznie, może być źródłem zarówno ogromnego sukcesu finansowego, jak i klęski. Z punktu widzenia klientów inwestycje w bazy danych są kosztowne, zaś dzisiejsze decyzje mogą mieć konsekwencje w horyzoncie kilkudziesięciu lat. Gorąca debata dotycząca tego, jakie systemy będą lepsze w bliższej i dalszej przyszłości – relacyjne, obiektowe, czy też obiektowo-relacyjne – ma charakter sporu ideologicznego, w którym argumenty dotyczące użytkowych i technicznych własności oferowanych systemów są przemieszane z argumentami ideologicznymi i „naukowymi”. W każdej z tych płaszczyzn uczestnicy debaty generują zarówno argumenty racjonalne, jak i mnogość mitów, demagogii i przekrętów.

Niewiele osób obserwujących komputerową scenę z pewnego dystansu zdaje sobie sprawę, że „nauki komputerowe” (computer science) nie są „nauką” w tradycyjnym rozumieniu tego terminu. Rozwój w dziedzinach związanych z komputerami oznacza przede wszystkim wynalazczość i nowe zastosowania. Działalność ściśle naukowa, zmierzająca do wypracowania obiektywnych zasad, teorii, metodologii i klasyfikacji, jest nieskuteczna, zwykle spóźniona w stosunku do aktualnych potrzeb i zbytnio obciążona zastanymi paradygmatami i kryteriami naukowymi. Przykładem mogą służyć matematyczne teorie w dziedzinie inżynierii oprogramowania, które od lat dryfują w kierunku scholastycznych mielizn pozostawiając po sobie wrakowisko pseudo-wiedzy, pseudo-podstaw i pseudo-autorytetów. Wynalazczość nie podlega kryteriom naukowym, jest spontanicznym błyskiem intelektu wynikającym z wiedzy, doświadczenia, wyczucia potrzeby rynkowej, wyczucia szansy zarobienia pieniędzy. Bill Gates, uważany za jednego z największych wynalazców komputerowych naszych czasów, człowiek, który w ogromnym stopniu przesądził o charakterze współczesnej informatyki, nie ukończył nawet studiów.

Model relacyjny i obiektowość można również uważać za wynalazki, chociaż o szczególnym charakterze. Są one ideologiami, czyli wynalazkami określającymi generalne ramy, cele i kierunki rozwoju. Ideologiczny aspekt oprogramowania można porównać ze stylem w budownictwie lub z ideologiami społecznymi. Ideologia wyznacza ogólne założenia co do celów, zasad i ograniczeń projektowanych systemów, określa oczekiwania użytkowników i potencjalne własności użytkowe. Nawet jeżeli system został zbudowany spontanicznie w reakcji na kolejne potrzeby (co w informatyce często ma miejsce), okazuje się, że pod powierzchnią inżynierskich działań tkwiła jakaś ideologia, chociaż nie nazwana i nieuświadomiona. Koncepcje hierarchicznych i sieciowych baz danych były właśnie tego rodzaju nieuświadomionymi ideologiami, które zostały nazwane kilka lat po ich zaistnieniu w informatycznej rzeczywistości.

W bazach danych ideologie, zwane modelami danych, okazały zasadniczy wpływ na charakter tej dziedziny. Nie pojawiły się przypadkiem, tkwił w nich pierwiastek obiektywizmu, wyrosły one bowiem z zaobserwowanych wad istniejącej rzeczywistości. Niemniej arbitralność, subiektywność ideologicznych ustaleń jest oczywista. Argumenty na ich rzecz mają charakter werbalny, skutków ich wprowadzenia nie da się precyzyjnie zmierzyć, jak również (patrz ideologie społeczne) skutki te mogą być sprzeczne z obietnicami. Racji ideologicznych nie da się udowodnić a priori: stanowią one przedmiot wiary lub niewiary, są bliższe religii niż nauce. Nauka, teorie są wtórne w stosunku do ideologii: są im podporządkowane, wyrastają w ich granicach i mogą nie mieć sensu poza ich obrębem.

W przypadku modelu relacyjnego ideologia została sklejona z teorią, ponieważ zasadniczym ideologicznym założeniem było oparcie koncepcji baz danych na matematycznej teorii relacji. Brak oddzielenia ideologii od teorii wielu zmylił. Od końca lat 70-tych do dzisiaj pokutuje stereotyp, zgodnie z którym model relacyjny jest uniwersalną teorię baz danych, która zmieniła charakter tej dziedziny z empirycznej na naukową. Nic bardziej błędnego: koncepcje obiektowe pokazały naocznie, że ci, którzy nie wierzą w relacyjną ideologię mogą ją w całości wyrzucić do śmieci, łącznie ze wszystkimi „naukowymi” ustaleniami, które w jej ramach zostały poczynione. (Tak jak ideologię socjalizmu, tak przecież „naukową” w opinii niegdysiejszych jej wyznawców i propagatorów.)

Jakkolwiek relacyjne bazy danych stały się komercyjnym sukcesem, ich filozofia bardzo odbiegła od początkowych ideologicznych ustaleń. Te wątpliwości doprowadziły E.Codd’a do sformułowania słynnych 12-tu reguł „prawdziwego” systemu relacyjnego, zaś C.Date do ostrych napaści na SQL jako źródła ideologicznych wypaczeń. Utyskiwania i gromy purystycznych ideologów na niewiele się zdały. Rzeczywistość relacyjnych baz danych ustabilizowała się w stanie, który jest kombinacja założeń ideologicznych, potrzeb użytkowników, aktualnych możliwości technologii komputerowych, szans zarobienia pieniędzy. „Prawdziwego” systemu relacyjnego prawdopodobnie już nigdy nie będzie.

Jak wynika z tych obserwacji, porównanie relacyjnych i obiektowych baz danych wymaga wyróżnienia warstwy ideologii, która wyznacza generalne założenia dla przyszłych działań, warstwy teorii, które wyrosły lub mają szanse wyrosnąć w obrębie danej ideologii, oraz warstwy technologii, która powstała lub powstanie w efekcie realizacji przyjętej ideologii.



Warstwa ideologii

Podstawową doktryną modelu relacyjnego jest traktowanie bazy danych jako zestawu matematycznych relacji. Niedozwolone jest używanie wewnętrznych identyfikatorów krotek (wierszy relacji) i wskaźników prowadzących do krotek. Niedozwolone jest, aby element krotki był złożony z dwóch lub więcej wartości. Niedozwolone jest uporządkowanie lub powtórzenia krotek. Środki manipulacji relacjami (czyli środki budowy aplikacji) zakładają przetwarzanie makroskopowe przy pomocy operatorów algebry relacji lub innego tego rodzaju języka. Sekwencyjne przetwarzanie “krotka po krotce” jest niedopuszczalne.

Praktyka pokazała, że opisane wyżej założenia ideologiczne są utopijne, w związku z czym (jak w „realnym socjaliźmie”) zostały one wykoślawione na wiele sposobów. Niemniej odstępstwa ideologiczne nie są głównym powodem krytyki modelu relacyjnego. Można nawet zgodzić się, że ustabilizował sie on w rozsądnym stanie, który wprawdzie nie pasuje do teorii relacji, ale pasuje do popularnych wyobrażeń o organizacji baz danych. Główną wadą modelu relacyjnego jest to, co miało być jego zaletą, mianowicie prostota struktur danych. W modelu relacyjnym informacje o pojęciach wyróżnialnych w rzeczywistości modelowanej przez dane 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. Skojarzenie tych informacji musi nastąpić explicite w programach aplikacyjnych (np. w zapytaniach SQL), przez co wzrasta ich koncepcyjna złożoność.

Brak środków hermetyzacji i modularyzacji oraz nie oddzielenie implementacji od specyfikacji są wykroczeniami przeciwko zasadom abstrakcji i dekompozycji, podstawą pojęciowego modelowania programów i danych. Brak złożonych obiektów, ograniczenie konstruktorów typów danych do jednego (relacji), brak wyspecjalizowanych środków do realizacji związków asocjacyjnych pomiędzy danymi, brak klas i dziedziczenia, brak możliwości ortogonalnej kombinacji różnych cech modelu są poważnymi ograniczeniami mechanizmów modelowania pojęciowego i potencjału ponownego użycia.


Co to jest niezgodność pomiędzy schematem pojęciowym i relacyjnym?
Poniżej znajduje się obiektowy schemat pojęciowy w notacji OMT. Klasa Pracownik jest specjalizacją klasy Osoba, pracownik może pracować w wielu firmach, firmy są powiązane z pracownikami poprzez obiekty Zatrudnienie. Gwiazdką zaznaczyliśmy atrybuty powtarzalne, np. pracownik może mieć wiele zawodów. Taki schemat może być bez zmian zaimplementowany w systemach obiektowych opartych o standard ODMG i może być bezpośrednio użyty do formułowania zapytań w OQL i pisania programów np. w C++.

Co się stanie po przekształceniu tego schematu na postać wymaganą przez system relacyjny? Zamiast 4-ch klas, 2-ch związków i jednej generalizacji otrzymamy 10 schematów relacyjnych i 11 koncepcyjnych (nieformalnych) związków. Atrybuty powtarzalne muszą być zaimplementowane jako nowe tablice, konieczne są nowe atrybuty zawierające klucze. Informacja o pracowniku Kowalskim, która na poprzednim schemacie była skupiona w jednym obiekcie, została rozproszona w krotkach pięciu tablic.

Zapytanie „Podaj adresy pracowników pracujących w firmach zlokalizowanych w Radomiu”:
OQL: select p.Adres from Firma as f, f.FZ.PZ as p where ”Radom” in f.Miejsce
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
Zapytanie w SQL jest znacznie dłuższe od zapytania w OQL głównie wskutek tego, że pojawiły się w nim „złączeniowe” predykaty (takie jak k.NrF=z.NrF i następne), które kojarzą informację semantyczną zgubioną podczas odwzorowania schematu obiektowego na schemat relacyjny. To skojarzenie, oprócz wymienionej porcji dodatkowego kodu, wymaga od programisty dokładnego rozumienia nieformalnej semantyki schematu.
Model relacyjny nie zajmuje się informacją proceduralną, która dość często jest istotną składową pojęciowego obrazu danych. Wobec braku systematycznych środków, wszelkie informacje wykraczające poza strukturę relacyjną (perspektywy, procedury bazy danych, dane multimedialne, reguły, i inne) są implementowane ad hoc przy pomocy protez zwanych BLOB, CLOB, itp. 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 dla prawie wszystkich zastosowań. Duża część tego przetwarzania musiała być oddelegowana do uniwersalnych języków programowania, co doprowadziło do niekorzystnego efektu niezgodności impedancji (impedance mismatch); w konsekwencji postulowane przez model relacyjny przetwarzanie makroskopowe wróciło częściowo do krytykowanego niegdyś przetwarzania niskiego poziomu, np. poprzez kursory w zagnieżdżonym SQL.
Co to jest niezgodność impedancji (impedance mismatch)?
Zespół niekorzystnych zjawisk towarzyszących formalnemu połączeniu języka zapytań (w szczególności SQL) z uniwersalnym językiem programowania takim jak 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ą statyczną 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.

  • 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.

  • Traktowania wartości zerowych. Bazy danych i języki zapytań posiadają wyspecjalizowane środki dla przechowywania i przetwarzania wartości zerowych. Środki te nie występują w językach programowania.

  • 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.

Co zmieniła obiektowość? Przede wszystkim, odrzuciła sztuczne ograniczenia związane z matematycznym rodowodem ideologii relacyjnej. Podstawowym postulatem jest możliwość tworzenia, przechowywania i przetwarzania dowolnie złożonych obiektów, które mają bezpośrednie konotacje z obiektami dziedziny przedmiotowej budowanego systemu. Informacja o pracowniku Kowalskim jest skupiona w jednym obiekcie, niezależnie od tego jak ona jest obszerna; może tam być seria zdjęć Kowalskiego i cała historia jego zatrudnienia. Obiekty są wyposażone w wewnętrzny identyfikator, co umożliwia tworzenie bezpośrednich powiązań wskaźnikowych pomiędzy obiektami. Nawigacja wzdłuż tych wskaźników znacznie upraszcza programowanie; sprzyja też wydajności. Wszelkie informacje wspólne dla pewnego zestawu podobnych obiektów są gromadzone w ramach klas; w szczególności, dotyczy to typu obiektów oraz operacji, które na tych obiektach można wykonać. Obiekty są dostępne wyłącznie poprzez interfejs, co umożliwia ukrycie informacji zbędnej na danym etapie programowania, na tej samej zasadzie jak w koncepcji modułów. Przesłanianie, przeciążanie, późne wiązanie i polimorfizm są cechami sprzyjającymi czytelności, modyfikowalności i ponownemu użyciu oprogramowania. Systemy obiektowe zakładają pełną kompletność obliczeniową i pragmatyczną środków programistycznych, co eliminuje niezgodność impedancji.

Podsumowując, model relacyjny przegrał konfrontację z obiektowością w warstwie ideologicznej. Poczynając od ok.1985 roku nastąpiła coraz bardziej intensywna krytyka, w wyniku której świat naukowy zredukował swoje zainteresowanie tym modelem praktycznie do zera. Dzisiaj nie jest widoczny ośrodek, który aktywnie rozwijałby model relacyjny od strony ideologiczno-naukowej. Obiektowość jest natomiast przedmiotem bardzo intensywnego rozwoju w setkach ośrodków. Wbrew poglądom głoszonym przez zwolenników łączenia ideologii relacyjnej z obiektową, model relacyjny w warstwie ideologicznej nie oferuje obiektowości niczego istotnego, głównie z tego powodu, że obiektowe struktury danych zawierają struktury relacyjne jako szczególny przypadek1.



Pobieranie 146.68 Kb.

Share with your friends:
  1   2




©operacji.org 2020
wyślij wiadomość

    Strona główna