Baza obiektów - Object database

Przykład modelu obiektowego

Bazie przedmiotem jest system zarządzania bazami danych , w których informacje są reprezentowane w postaci obiektów używane w programowaniu obiektowym . Obiektowe bazy danych różnią się od relacyjnych baz danych zorientowanych na tabele. Obiektowo-relacyjne bazy danych są hybrydą obu podejść.

Obiektowe bazy danych są rozważane od wczesnych lat 80-tych.

Przegląd

Obiektowe systemy zarządzania bazami danych (OODBMS), zwane również ODBMS (Object Database Management System), łączą możliwości baz danych z możliwościami języka programowania zorientowanego obiektowo . OODBMS umożliwiają programistom zorientowanym obiektowo opracowywanie produktów, przechowywanie ich jako obiektów oraz replikowanie lub modyfikowanie istniejących obiektów w celu tworzenia nowych obiektów w ramach OODBMS. Ponieważ baza danych jest zintegrowana z językiem programowania, programista może zachować spójność w ramach jednego środowiska, dzięki czemu zarówno OODBMS, jak i język programowania będą używać tego samego modelu reprezentacji. Dla kontrastu projekty relacyjnych DBMS zachowują wyraźniejszy podział między modelem bazy danych a aplikacją.

Ponieważ wykorzystanie technologii internetowych wzrasta wraz z wdrażaniem intranetów i ekstranetów, firmy są żywotnie zainteresowane systemami OODBMS do wyświetlania złożonych danych. Korzystanie z DBMS, który został specjalnie zaprojektowany do przechowywania danych jako obiektów, daje przewagę firmom, które są nastawione na prezentacje multimedialne lub organizacjom, które wykorzystują projektowanie wspomagane komputerowo (CAD).

Niektóre zorientowane obiektowo bazy danych są zaprojektowane do pracy z obiektowymi językami programowania, takimi jak Delphi , Ruby , Python , JavaScript , Perl , Java , C# , Visual Basic .NET , C++ , Objective-C i Smalltalk ; inne, takie jak JADE, mają własne języki programowania. OODBMS wykorzystują dokładnie ten sam model, co języki programowania obiektowego.

Historia

Systemy zarządzania obiektowymi bazami danych wyrosły z badań przeprowadzonych od początku do połowy lat 70. XX wieku i zaczęły mieć nieodłączną obsługę zarządzania bazami danych dla obiektów o strukturze grafowej. Termin „system baz danych zorientowany obiektowo” pojawił się po raz pierwszy około 1985 roku. Ważnymi projektami badawczymi były: Encore-Ob/Server ( Brown University ), EXODUS ( Uniwersytet Wisconsin–Madison ), IRIS (Hewlett-Packard), ODE ( Bell Labs ), ORION ( Microelectronics and Computer Technology Corporation lub MCC), Vodak (GMD-IPSI) i Zeitgeist (Texas Instruments). Projekt ORION miał więcej opublikowanych artykułów niż jakiekolwiek inne wysiłki. Won Kim z MCC zebrał najlepsze z tych artykułów w książce opublikowanej przez The MIT Press.

Wczesne produkty komercyjne obejmowały Gemstone (Servio Logic, nazwa zmieniona na GemStone Systems), Gbase (Graphael) i Vbase (Ontologic). Dodatkowe produkty komercyjne weszły na rynek od końca lat 80. do połowy lat 90. XX wieku. Należą do nich ITASCA (Itasca Systems), Jasmine (Fujitsu, sprzedawany przez Computer Associates), Matisse (Matisse Software), Objectivity/DB (Objectivity, Inc.), ObjectStore ( Progress Software , przejęty od eXcelon, który pierwotnie był Object Design, Incorporated ) , ONTOS (Ontos, Inc., nazwa zmieniona z Ontologic), O 2 (O 2 Technology, połączona z kilkoma firmami przejętymi przez Informix , który z kolei został przejęty przez IBM ), POET (obecnie FastObjects od Versant, który przejął Poet Software) , Versant Object Database ( Versant Corporation), VOSS (Logic Arts) i JADE (Jade Software Corporation). Niektóre z tych produktów pozostają na rynku i dołączyły do ​​nich nowe produkty open source i komercyjne, takie jak InterSystems Caché .

Systemy zarządzania obiektowymi bazami danych dodały koncepcję trwałości do języków programowania obiektów. Wczesne produkty komercyjne były integrowane z różnymi językami: GemStone ( Smalltalk ), Gbase ( LISP ), Vbase ( COP ) i VOSS (Virtual Object Storage System for Smalltalk ). Przez większość lat 90. C++ dominował na rynku zarządzania bazami danych obiektów komercyjnych. Sprzedawcy dodali Javę pod koniec lat 90., a ostatnio C# .

Począwszy od 2004 r., obiektowe bazy danych przeżyły drugi okres wzrostu, kiedy pojawiły się bazy danych obiektów typu open source , które były powszechnie przystępne i łatwe w użyciu, ponieważ są w całości napisane w językach OOP , takich jak Smalltalk, Java lub C#, takich jak db4o firmy Versant (db4objects) DTS / S1 z Obsidian Dynamics i Prest (McObject), dostępnej pod podwójną open source i licencji komercyjnej.

Oś czasu

Przyjęcie obiektowych baz danych

Obiektowe bazy danych oparte na trwałym programowaniu zdobyły niszę w obszarach zastosowań, takich jak inżynieria i bazy danych przestrzenne , telekomunikacja oraz w obszarach naukowych, takich jak fizyka wysokich energii i biologia molekularna .

Inna grupa baz danych obiektowych koncentruje się na wbudowanym użyciu w urządzeniach, pakietach oprogramowania i systemach czasu rzeczywistego.

Właściwości techniczne

Większość baz danych obiektów oferuje również pewien rodzaj języka zapytań , który umożliwia znajdowanie obiektów przy użyciu deklaratywnego podejścia programowania . To właśnie w obszarze języków zapytań obiektowych oraz integracji interfejsów zapytań i nawigacji można znaleźć największe różnice między produktami. Próbę standaryzacji podjął ODMG z Object Query Language , OQL.

Dostęp do danych może być szybszy, ponieważ obiekt można pobrać bezpośrednio bez wyszukiwania, kierując się wskaźnikami .

Innym obszarem zmienności między produktami jest sposób definiowania schematu bazy danych. Ogólną cechą jest jednak to, że język programowania i schemat bazy danych używają tych samych definicji typów.

Aplikacje multimedialne są ułatwione, ponieważ metody klasowe związane z danymi odpowiadają za ich prawidłową interpretację.

Wiele baz danych obiektów, na przykład Gemstone czy VOSS, oferuje obsługę wersjonowania . Obiekt można postrzegać jako zbiór wszystkich jego wersji. Ponadto wersje obiektów mogą być traktowane jako samodzielne obiekty. Niektóre bazy obiektowe zapewniają również systematyczną obsługę wyzwalaczy i ograniczeń, które są podstawą aktywnych baz danych .

Wydajność takiej bazy danych ulega również znacznej poprawie w obszarach wymagających ogromnych ilości danych o jednym przedmiocie. Na przykład instytucja bankowa może uzyskać informacje o koncie użytkownika i wydajnie dostarczyć mu obszernych informacji, takich jak transakcje, wpisy informacji o koncie itp.

Normy

Object Database Management Group było konsorcjum z bazy danych obiektów i sprzedawców mapowanie obiektowo-relacyjne, członkowie społeczności akademickiej i zainteresowanych stron. Jego celem było stworzenie zestawu specyfikacji, który umożliwiłby tworzenie przenośnych aplikacji przechowujących obiekty w systemach zarządzania bazami danych. Opublikował kilka wersji swojej specyfikacji. Ostatnią wersją był ODMG 3.0. Do roku 2001 większość głównych dostawców baz danych obiektów i mapowania obiektowo-relacyjnego twierdziła, że ​​są zgodne z Wiązaniem języka Java ODMG. Zgodność z innymi składnikami specyfikacji była mieszana. W 2001 roku powiązanie języka Java ODMG zostało przesłane do Java Community Process jako podstawa specyfikacji Java Data Objects . Firmy członkowskie ODMG zdecydowały się skoncentrować swoje wysiłki na specyfikacji Java Data Objects. W rezultacie ODMG rozwiązało się w 2001 roku.

Wiele pomysłów na obiektowe bazy danych zostało również wchłoniętych do SQL:1999 i zostało zaimplementowanych w różnym stopniu w obiektowo-relacyjnych produktach bazodanowych .

W 2005 roku Cook, Rai i Rosenberger zaproponowali porzucenie wszelkich wysiłków standaryzacyjnych na rzecz wprowadzenia dodatkowych zorientowanych obiektowo interfejsów API zapytań, ale raczej wykorzystanie samego języka programowania OO, tj. Java i .NET, do wyrażania zapytań. W rezultacie pojawiły się zapytania natywne . Podobnie firma Microsoft ogłosiła Language Integrated Query (LINQ) i DLINQ, implementację LINQ, we wrześniu 2005 r., aby zapewnić bliskie, zintegrowane językowo możliwości zapytań do bazy danych z językami programowania C# i VB.NET 9.

W lutym 2006 roku Object Management Group (OMG) ogłosiła, że ​​przyznano jej prawo do opracowywania nowych specyfikacji w oparciu o specyfikację ODMG 3.0 oraz powołanie Object Database Technology Working Group (ODBT WG). Grupa Robocza ODBT planowała stworzyć zestaw standardów, który obejmowałby postępy w technologii baz danych obiektów (np. replikacja), zarządzanie danymi (np. indeksowanie przestrzenne) i formaty danych (np. XML) oraz włączyć do tych standardów nowe funkcje, które obsługuje domeny, w których adaptowane są obiektowe bazy danych (np. systemy czasu rzeczywistego). Praca WG ODBT została zawieszona w marcu 2009 r., kiedy po zawirowaniach gospodarczych pod koniec 2008 r. dostawcy ODB zaangażowani w ten wysiłek postanowili skoncentrować swoje zasoby gdzie indziej.

W styczniu 2007 roku World Wide Web Consortium nadało ostateczny status rekomendacji językowi XQuery . XQuery używa XML jako swojego modelu danych. Niektóre z pomysłów opracowanych pierwotnie dla obiektowych baz danych trafiły do ​​XQuery, ale XQuery nie jest wewnętrznie zorientowane obiektowo. Ze względu na popularność XML silniki XQuery konkurują z obiektowymi bazami danych jako narzędzie do przechowywania danych, które są zbyt złożone lub zmienne, aby wygodnie przechowywać je w relacyjnej bazie danych. XQuery umożliwia również pisanie modułów w celu zapewnienia funkcji enkapsulacji, które zostały dostarczone przez systemy zorientowane obiektowo.

XQuery v1 i XPath v2 są niezwykle złożone (żadne oprogramowanie FOSS nie implementuje tych standardów ponad 10 lat po ich opublikowaniu) w porównaniu z XPath v1 i XSLT v1 , a XML jako otwarty format nie spełniał wszystkich wymagań społeczności . Od początku XXI wieku JSON zyskał popularność i popularność w aplikacjach, przewyższając XML w 2010 roku. JSONiq , analog zapytania XQuery dla JSON (udostępniający podstawowe wyrażenia i operacje XQuery), zademonstrował funkcjonalną równoważność formatów JSON i XML. W tym kontekście główną strategią opiekunów OODBMS była modernizacja JSON w ich bazach danych (używając go jako wewnętrznego typu danych).

W styczniu 2016 r. wraz z wydaniem PostgreSQL 9.5 był pierwszym FOSS OODBMS oferującym wydajny wewnętrzny typ danych JSON (JSONB) z kompletnym zestawem funkcji i operacji dla wszystkich podstawowych manipulacji relacyjnych i nierelacyjnych.

Porównanie z RDBMS

Obiektowa baza danych przechowuje złożone dane i relacje między danymi bezpośrednio, bez mapowania na relacyjne wiersze i kolumny, co czyni je odpowiednimi dla aplikacji zajmujących się bardzo złożonymi danymi. Obiekty mają relację wiele-do-wielu i są dostępne za pomocą wskaźników. Wskaźniki są połączone z obiektami w celu ustanowienia relacji. Kolejną zaletą OODBMS jest to, że można go zaprogramować z niewielkimi różnicami proceduralnymi bez wpływu na cały system.

Zobacz też

Bibliografia

Zewnętrzne linki