ObiektowoϾ w bazach danych koncepcje, nadzieje I fakty



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

Warstwa teorii

Podstawową wadą w zasadzie wszystkich teorii zbudowanych dla potrzeb modelu relacyjnego jest ich dekoracyjny, fasadowy charakter. Teorie te miały wprawdzie pewne znaczenie metodologiczne, próbowały wyjaśnić zjawiska semantyczne zachodzące w danych i w językach zapytań na gruncie matematycznym; w konsekwencji jednak okazały się dla praktyki bezużyteczne. W szczególności dotyczy to tzw. teorii zależności funkcjonalnych, wielowartościowych i innych, której zastosowanie jest znikome i sprowadza się do definicji kilku pojęć (takich jak druga, trzecia i czwarta forma normalna) o znaczeniu marginalnym dla praktyki projektowania baz danych. Oparcie semantyki języków zapytań takich jak SQL o algebrę relacji lub rachunek relacyjny okazało się pomysłem nieudanym. Jak wspomnieliśmy, jednym z powodów jest to, że systemy relacyjne w istocie odchodzą od pojęcia relacji. „Relacje” przechowywane w systemach relacyjnych są strukturami bogatszymi niż relacje matematyczne; m.in. mogą zawierać powtórzenia krotek, zaś istotną rolę odgrywają w nich klucze oraz nazwy atrybutów. Ponadto, algebra relacji lub rachunek relacyjny są niedostatecznie uniwersalne dla języków takich jak SQL; np. nie uwzględniają operacji aktualizacyjnych, funkcji zagregowanych, grupowania, uporządkowania, operatorów arytmetycznych i innych.

Mitem są częste twierdzenia, że metody optymalizacji zapytań są konsekwencją odkrytych własności algebry relacji. Historycznie, metody optymalizacyjne (np. przesuwanie selekcji i projekcji przed złączenie) zostały zaimplementowane na kilka lat przed odkryciem podobnych praw algebry relacji. Ponieważ algebra ta nie przykrywa i nie pasuje do wielu aspektów języka SQL, jakakolwiek własność odkryta w tej algebrze niekoniecznie musi obowiązywać w SQL; i odwrotnie. Bardziej zawansowane metody optymalizacyjne (np. wyznaczanie optymalnej ścieżki dostępu) są rezultatem głębokich praktycznych dociekań, heurystyk i eksperymentów i nie są podbudowane jakąkolwiek istotną teorią.

Całkowitym fiaskiem zakończył się duży nurt teoretyczny określany jako „badania nad niekompletną informacja”. Nie są znane jakiekolwiek próby zastosowania tych rezultatów, nawet w prototypach, natomiast rozwiązania w tym zakresie w języku SQL są pozbawione elementarnej logiki (patrz artykuły C. Date). Podobnie, całkowitym fiaskiem zakończyły się rozszerzenia teoretyczne modelu relacyjnego takie jak uniwersalne relacje i dedukcyjne bazy danych (setki publikacji, dziesiątki doktoratów). Negatywnym skutkiem tych „badań” było wykształcenie armii pseudo-teoretyków baz danych, która i dzisiaj wpływa hamująco na postęp poprzez zamulanie literatury i konferencji mnóstwem poronionych „teorii”. Nieliczne pożyteczne teorie, takie jak np. teoria szeregowalności transakcji (serializability), są w gruncie rzeczy neutralne w stosunku do modelu danych i równie dobrze nadają się do modeli obiektowych.

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. Jest dość wątpliwe, czy dla tych pomysłów (w istocie, generowanych przez praktyków) ktokolwiek będzie budować teorie.

Reasumując, twierdzenia, że model relacyjny posiada „solidne podstawy matematyczne” zaś obiektowość ich nie posiada są fałszywymi stereotypami. Obie ideologie cechuje dokładnie ten sam status względem zmatematyzowanych teorii, tj. brak istotnych podstaw teoretycznych. Różnica polega wyłącznie na tym, że teoretyczne dekoracje ideologii relacyjnej funkcjonują jako czynnik propagandowy, zaś teorie dotyczące obiektowości nie pełnią tej roli, gdyż model obiektowy jest koncepcyjnie zbyt złożony, aby pasował do prostoty i elegancji wymaganej przez matematykę. Wskutek zbytnich uproszczeń i obciążenia pomysłami z epoki relacyjnej teorie dotyczące obiektowych baz danych są jak dotąd wadliwe, nieskuteczne i niepopularne (patrz np. obiektowe algebry lub logiki, koncepcje „dedukcyjno-obiektowe”, itd.). Tworzą one jednak już tło, z którego może wyłonić się autentyczna, nie dekoracyjna teoria obiektowych baz danych. Przykładem może służyć intensywnie rozwijana teoria typów polimorficznych w zastosowaniu do obiektowości.



Warstwa technologii

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. W dziedzinie baz danych obowiązuje model nisz ekologicznych. Jeżeli jakaś koncepcja technologiczna opanowała pewną dziedzinę zastosowań (np. bankowość) i/lub teren geograficzny, wówczas bardzo trudno zastąpić ją inną koncepcją, nawet jeżeli jest ona obiektywnie lepsza. Klient baz danych nie tylko nie lubi kosztownych zmian; musi mieć także pewność, że nie pozostanie sam w swojej dziedzinie działalności lub rejonie geograficznym i może liczyć na zarówno ś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ąć jako pewnik, ż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. Wielu specjalistów wskazuje, że 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łno-tekstowe, hurtownie danych, zastosowania biurowe. Prace standardyzacyjne prowadzone m.in. przez OMG i ODMG wzmacniają ten rynek poprzez usystematyzowanie i ukierunkowanie rozwoju, tworzeniem powszechnie akceptowanej terminologii, pojęć i kultury technicznej, oraz poprzez wytworzenia wśród potencjalnych klientów poczucia dojrzałości technologicznej i niezależności od jednego dostawcy.

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 standardów obiektowych OMG CORBA i COM/DCOM. Zwolennicy modelu relacyjnego bronią tej koncepcji poprzez tworzenie systemów relacyjno-obiektowych. Spontaniczność i niesystematyczność tego rozwoju powoduje bardzo niską kompatybilność systemów. Ponad 95% 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: ogrom tego standardu prawdopodobnie spowoduje, że będzie on implementowany w (różnej) części na różnych platformach, co może podważyć sens standardyzacji. W istocie więc, następuje kryzys koncepcji w systemach relacyjnych oraz ich ewolucja w kierunku obiektowości; trudno przewidzieć, gdzie ta ewolucja się zatrzyma.

Dość często porównanie obiektowości i relacyjności schodzi na grunt własności technicznych. Technologiczna przewaga systemów relacyjnych nad obiektowymi jest jednak prawie na pewno kwestią czasu i odpowiednich inwestycji.
Nie istnieje użytkowa własność systemów relacyjnych, która nie mogłaby być równie dobrze zrealizowana w systemach obiektowych.
Nie widać istotnego argumentu na korzyść tezy przeciwnej. Np. zwolennicy systemów relacyjnych zarzucają systemom obiektowym, że nie są one wyposażone w odpowiednie funkcje, np. zintegrowane środowiska do tworzenia aplikacji, ale są to argumenty doraźne, ponieważ być może za miesiąc lub rok te funkcje będą już obecne. Wiele zarzutów technicznych pod adresem systemów obiektowych ma charakter dowolnych twierdzeń powtarzanych przez tendencyjną konkurencję lub ludzi niezbyt kompetentnych w przedmiocie.

Koronnym zarzutem informatycznych wszechczasów jest wydajność (performance); np. kiedyś był on argumentem zwolenników CODASYLu przeciwko modelowi relacyjnemu, poźniej (po wynalezieniu automatycznej optymalizacji zapytań) stał się argumentem odwrotnym. Dzisiaj również argument ten jest odbijany jak piłeczka pinpongowa. Zwolennicy relacyjności zarzucają systemom obiektowym brak dopracowanych metod optymalizacji zapytań, zaś zwolennicy obiektowości podkreślają zredukowanie potrzeby tej optymalizacji po zaimplementowaniu związków asocjacyjnych jako wskaźników. Tymczasem obiektowość sprzyja wydajności również 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. Niektóre testy wydajnościowe wykazują, że systemy obiektowe są sprawniejsze od relacyjnych tysiące razy.



Częste mity, demagogie, fałszywe stereotypy i przekręty

Dyskusje, opinie i zestawienia porównujące systemy relacyjne z obiektowymi zawierają bardzo wiele tez nieprawdziwych lub kontrowersyjnych. Niżej zamieszczamy komentarze na ich temat.




  • 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 zasadniczo odbiega od ram formalnych takich jak algebra relacji, rachunek relacyjny i logika matematyczna. SQL posiada wiele operatorów nie rozpatrywanych przez relacyjne teorie, np. operatory aktualizacyjne, uporządkowanie, grupowanie, eliminacja duplikatów, operatory arytmetyczne, funkcje zagregowane, itd.

  • Można skonstruować kompletny język zapytań/programowania oparty wyłącznie o algebrę relacji. Być może, ale po co? Pomysł nadaje się wyłącznie dla teoretyków o skłonnościach masochistycznych.

  • 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, znacznie odbiegających od operatorów algebry relacji.

  • Nie można zagnieżdżać obiektowych zapytań, ponieważ nie są one oparte na własności domkniętości (closure property). Niezrozumienie tematu. Zapytania w OQL można zagnieżdżać pomimo (pozornego) nie spełnienia własności domkniętości.

  • 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 musi podjąć ś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 języki 4GL.)

  • Systemy relacyjne umożliwiają realizację dowolnego zastosowania. Nieprawda. Dla wielu zastosowań struktury relacyjne okazują się zbyt sztywne. Odwzorowanie struktur pojęciowych na struktury relacyjne wiąże się ze znacznym wzrostem złożoności, która może podważyć osiągalność celów projektu.

  • Obecność wskaźników w strukturach obiektowych cofa rozwój do lat 70-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, upraszczają zapytania, programy i 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 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, perspektywy, itd. Pojawienie się standardów i pakietów takich CORBA, DCOM i JavaBeans sugeruje, że dalszy rozwój rozproszonych baz danych będzie odbywał się w oparciu o technologie obiektowe.

  • Systemy obiektowe nie mogą być wyposażone w języki zapytań. Nieprawda. Patrz np. OQL.

  • Hermetyzacja jest nieakceptowalna, bo bezsensownie ogranicza bezpośredni dostęp do danych i uniemożliwia realizację języka zapytań. Nieporozumienie wynikające ze zbyt wąskiego rozumienia pojęcia hermetyzacji. Hermetyzacja, polegająca na oddzieleniu specyfikacji (interfejsu) 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ń.

  • 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 eksponowane w literaturze; (3) Nie można wskazać powodów, dla których metod sprawnych w systemach relacyjnych nie można zastosować w systemach obiektowych; (4) Ortogonalność i bardziej precyzyjna semantyka OQL (w stosunku do SQL) stwarza większy potencjał dla metod optymalizacyjnych.

  • Obiektowe bazy danych mają małą wydajność. Twierdzenie dowolne. Systemy obiektowe są o kilkanaście lat młodsze od relacyjnych, a mimo tego są często znacznie od nich sprawniejsze.

  • 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ść przerasta cały cykl analizy, projektowania i realizacji systemów informacyjnych.

  • Obiektowe systemy baz danych nie zapewniają skalowalności. Twierdzenie dowolne. Wiele systemów obiektowych takich jak ObjectStore, Objectivity/DB lub O2 nie posiada istotnych ograniczeń co do rozmiaru bazy danych lub liczby użytkowników.

  • Obiektowe bazy danych nie zapewniają właściwych środków przetwarzania transakcji. Nieprawda. Wszystkie liczące się systemy obiektowe zapewniają przetwarzanie transakcji.

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



Obiektowość - potencjalne ryzyko

Jak każda ideologia, obiektowość nie jest pozbawiona wad lub zagrożeń. Ich listę (prawdopodobnie niekompletną) podajemy niżej.




  • Niedopracowane 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 analizy i 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 takie jak CORBA, ODMG i COM są niedopracowane i niestabilne. Nie wiadomo w jakim zakresie będą one pełnić swoją funkcję. Standardy te zakładają zbytni eklektyzm (wiązania do wielu języków programowania) co powoduje silne ograniczenie funkcjonalności.

  • Oczekiwania związane z opanowaniem problemu rozproszonych baz danych przez obiektowe oprogramowanie komponentowe (takie jak pakiety pośredniczące wg CORBA, OpenDoc, JavaBeans lub DCOM) są przesadzone. Rozproszenie, heterogeniczność baz danych generuje szereg trudnych tematów (takich np. jak optymalizacja rozproszonych zapytań) znacznie wykraczających poza możliwości przewidziane przez to oprogramowanie.

*****
Czy spór dotyczący tego, czy systemy mają być relacyjne, obiektowe, czy też obiektowo-relacyjne może mieć jednoznaczne rozstrzygnięcie? Z punktu widzenia tego, co dzisiaj wiemy o systemach informacyjnych, biorąc pod uwagę ideologię, konsekwencję i estetykę produktów informatycznych, koncepcje obiektowe mają absolutną przewagę nad relacyjnymi. Świat jednak bardzo dużo zainwestował w model relacyjny, wyprodukowano dziesiątki systemów, działa tysiące zastosowań, napisano setki podręczników, wykształcono niezliczoną liczbę specjalistów. Czasu i inwestycji nie da się cofnąć i dlatego przyjdzie nam żyć z systemami relacyjnymi przez wiele następnych lat. W tym pejzażu znajdą się również obiektowe i obiektowo-relacyjne bazy danych. Nigdy nie uda się ustalić precyzyjnej granicy, gdzie kończy się „relacyjność”, a zaczyna „obiektowość”. Określenie „relacyjny” od dawna jest dowolnie rozciągane i zmieniane, dawno utraciło związek z matematycznym rodowodem i nie bardzo wiadomo, co dzisiaj znaczy. Pozostała z niego tylko konwencja językowa, niejasny komercyjny stereotyp, który jest coraz bardziej anachroniczny - na korzyść koncepcji i terminów obiektowych.



Kazimierz Subieta jest kierownikiem zespołu inżynierii oprogramowania w Instytucie Podstaw Informatyki PAN oraz wykładowcą w Polsko-Japońskiej Wyższej Szkole Technik Komputerowych.

e-mail: subieta@ipipan.waw.pl



WWW: http://www.ipipan.waw.pl/~subieta


1 Wskutek tego każdy system obiektowy jest jednocześnie systemem obiektowo-relacyjnym; ten galimatias komercyjnej retoryki powoduje mnóstwo nieporozumień.


Pobieranie 146.68 Kb.

Share with your friends:
1   2




©operacji.org 2020
wyślij wiadomość

    Strona główna