Obiektowo-relacyjna baza danych - Object–relational database
Baza danych obiektowo-relacyjnego ( ORD ), czy system zarządzania bazami danych obiektowo-relacyjnego ( Ordbms ), to system zarządzania bazą danych (DBMS) podobny do relacyjnej bazy danych , ale z modelu bazy danych obiektowego : Przedmioty, klas i dziedziczenia są bezpośrednio obsługiwane w schematach baz danych oraz w języku zapytań . Ponadto, podobnie jak w przypadku czystych systemów relacyjnych, obsługuje rozszerzenie modelu danych o niestandardowe typy danych i metody .
Można powiedzieć, że obiektowo-relacyjna baza danych stanowi środek pośredni między relacyjnymi bazami danych a bazami zorientowanymi obiektowo . W obiektowo-relacyjnych bazach danych podejście jest zasadniczo takie, jak w relacyjnych bazach danych: dane znajdują się w bazie danych i są wspólnie przetwarzane za pomocą zapytań w języku zapytań; na drugim biegunie znajdują się systemy OODBMS, w których baza danych jest zasadniczo trwałą składnicą obiektów dla oprogramowania napisanego w zorientowanym obiektowo języku programowania , z programistycznym interfejsem API do przechowywania i pobierania obiektów oraz niewielką lub żadną obsługą zapytań.
Przegląd
Podstawowa potrzeba obiektowo-relacyjnej bazy danych wynika z faktu, że zarówno relacyjna, jak i obiektowa baza danych mają swoje indywidualne zalety i wady. Izomorfizm systemu relacyjnych baz danych z matematyczną relacją pozwala na wykorzystanie wielu przydatnych technik i twierdzeń z teorii mnogości. Jednak te typy baz danych nie są optymalne dla niektórych rodzajów aplikacji. Zorientowany obiektowo model bazy danych umożliwia stosowanie kontenerów, takich jak zbiory i listy, dowolne typy danych zdefiniowane przez użytkownika, a także obiekty zagnieżdżone. Zapewnia to podobieństwo między systemami typów aplikacji i systemami typów baz danych, co eliminuje wszelkie problemy z niedopasowaniem impedancji. Ale obiektowe bazy danych, w przeciwieństwie do relacyjnych, nie zapewniają matematycznej podstawy do ich dogłębnej analizy.
Podstawowym celem obiektowo-relacyjnej bazy danych jest wypełnienie luki między relacyjnymi bazami danych a obiektowymi technikami modelowania używanymi w językach programowania, takich jak Java , C ++ , Visual Basic .NET lub C # . Jednak bardziej popularną alternatywą dla uzyskania takiego mostu jest użycie standardowych systemów relacyjnych baz danych z pewną formą oprogramowania do mapowania obiektowo-relacyjnego (ORM). Podczas gdy tradycyjne produkty RDBMS lub SQL-DBMS koncentrowały się na efektywnym zarządzaniu danymi pochodzącymi z ograniczonego zestawu typów danych (zdefiniowanych przez odpowiednie standardy językowe), obiektowo-relacyjny DBMS umożliwia programistom integrację własnych typów i metod, które zastosuj się do nich w DBMS.
ORDBMS (podobnie jak ODBMS lub OODBMS ) jest zintegrowany z językiem programowania zorientowanym obiektowo . Charakterystyczne właściwości ORDBMS to 1) złożone dane, 2) dziedziczenie typów i 3) zachowanie obiektów. Złożone tworzenie danych w większości SQL ORDBMS opiera się na wstępnej definicji schematu poprzez typ zdefiniowany przez użytkownika (UDT). Hierarchia w uporządkowanych złożonych danych oferuje dodatkową właściwość - dziedziczenie typów . Oznacza to, że typ strukturalny może mieć podtypy, które ponownie wykorzystują wszystkie jego atrybuty i zawierają dodatkowe atrybuty specyficzne dla podtypu. Kolejna zaleta, zachowanie obiektów , wiąże się z dostępem do obiektów programu. Takie obiekty programu muszą być przechowywane i przenośne do przetwarzania w bazie danych, dlatego zwykle nazywane są obiektami trwałymi . W bazie danych wszystkie relacje z trwałym obiektem programu są relacjami z jego identyfikatorem obiektu (OID) . Wszystkie te punkty można rozwiązać w odpowiednim systemie relacyjnym, chociaż standard SQL i jego implementacje narzucają arbitralne ograniczenia i dodatkową złożoność
W programowaniu obiektowym (OOP) zachowanie obiektów jest opisywane za pomocą metod (funkcji obiektowych). Metody oznaczone jedną nazwą wyróżnia typ ich parametrów oraz typ obiektów, do których zostały dołączone ( sygnatura metody ). Języki OOP nazywają to zasadą polimorfizmu , którą w skrócie definiuje się jako „jeden interfejs, wiele implementacji”. Inne zasady OOP, dziedziczenie i hermetyzacja , są związane zarówno z metodami, jak i atrybutami. Dziedziczenie metod jest uwzględnione w dziedziczeniu typów. Enkapsulacja w OOP jest stopień widoczności zadeklarował, na przykład, poprzez public
, private
i protected
modyfikatory dostępu .
Historia
Systemy zarządzania obiektowo-relacyjnymi bazami danych wyrosły z badań przeprowadzonych na początku lat 90. Badania te rozszerzyły istniejące koncepcje relacyjnych baz danych poprzez dodanie koncepcji obiektów . Badacze zamierzali zachować deklaratywny język zapytań oparty na rachunku predykatów jako centralny element architektury. Prawdopodobnie najbardziej znaczący projekt badawczy, Postgres (UC Berkeley), zaowocował dwoma produktami, które wywodzą się z tego badania: Illustra i PostgreSQL .
W połowie lat 90. pojawiły się wczesne produkty komercyjne. Obejmowały one Illustra (Illustra Information Systems, przejęty przez Informix Software , który z kolei został przejęty przez IBM ), Omniscience (Omniscience Corporation, przejęty przez Oracle Corporation i stał się oryginalnym Oracle Lite) oraz UniSQL (UniSQL, Inc., przejęty przez KCOMS ). Ukraiński programista Ruslan Zasukhin, założyciel Paradigma Software, Inc. , opracował i dostarczył pierwszą wersję bazy danych Valentina w połowie lat 90. jako C ++ SDK . Przez następną dekadę PostgreSQL stał się komercyjnie opłacalną bazą danych i jest podstawą kilku obecnych produktów, które zachowują funkcje ORDBMS.
Informatycy zaczęli nazywać te produkty „obiektowo-relacyjnymi systemami zarządzania bazami danych” lub systemami ORDBMS.
Wiele pomysłów z wczesnych prac nad relacyjnymi bazami danych zostało w dużej mierze uwzględnionych w SQL: 1999 poprzez typy strukturalne . W rzeczywistości każdy produkt, który jest zgodny z obiektowymi aspektami SQL: 1999, można opisać jako produkt do zarządzania obiektowo-relacyjną bazą danych. Na przykład IBM DB2 , baza danych Oracle i Microsoft SQL Server twierdzą, że wspierają tę technologię i robią to z różnym powodzeniem.
Porównanie z RDBMS
RDBMS może zwykle obejmować instrukcje SQL , takie jak te:
CREATE TABLE Customers (
Id CHAR(12) NOT NULL PRIMARY KEY,
Surname VARCHAR(32) NOT NULL,
FirstName VARCHAR(32) NOT NULL,
DOB DATE NOT NULL # DOB: Date of Birth
);
SELECT InitCap(Surname) || ', ' || InitCap(FirstName)
FROM Customers
WHERE Month(DOB) = Month(getdate())
AND Day(DOB) = Day(getdate())
Większość obecnych baz danych SQL pozwala na tworzenie niestandardowych funkcji , które pozwoliłyby zapytać wyglądać jak:
SELECT Formal(Id)
FROM Customers
WHERE Birthday(DOB) = Today()
W obiektowo-relacyjnej bazie danych można zobaczyć coś takiego, ze zdefiniowanymi przez użytkownika typami danych i wyrażeniami, takimi jak BirthDay()
:
CREATE TABLE Customers (
Id Cust_Id NOT NULL PRIMARY KEY,
Name PersonName NOT NULL,
DOB DATE NOT NULL
);
SELECT Formal( C.Id )
FROM Customers C
WHERE BirthDay ( C.DOB ) = TODAY;
Model obiektowo-relacyjny może oferować kolejną zaletę polegającą na tym, że baza danych może wykorzystywać relacje między danymi do łatwego gromadzenia powiązanych rekordów. W aplikacji książki adresowej do tabel powyżej zostanie dodana dodatkowa tabela zawierająca zero lub więcej adresów dla każdego klienta. Korzystając z tradycyjnego systemu RDBMS, zbieranie informacji zarówno o użytkowniku, jak i jego adresie wymaga „dołączenia”:
SELECT InitCap(C.Surname) || ', ' || InitCap(C.FirstName), A.city
FROM Customers C join Addresses A ON A.Cust_Id=C.Id -- the join
WHERE A.city="New York"
To samo zapytanie w obiektowo-relacyjnej bazie danych wygląda prościej:
SELECT Formal( C.Name )
FROM Customers C
WHERE C.address.city="New York" -- the linkage is 'understood' by the ORDB
Zobacz też
- Baza danych zorientowana na dokumenty
- SQL
- Porównanie obiektowo-relacyjnych systemów zarządzania bazami danych
- Typ strukturalny
- Baza danych obiektów
- Mapowanie obiektowo-relacyjne
- Model relacyjny
- LINQ
- ADO.NET Entity Framework
Bibliografia
Linki zewnętrzne
- Savushkin, Sergey (2003), A Point of View on ORDBMS , zarchiwizowane od oryginału w dniu 2012-03-01 , pobrane 2012-07-21 .
- Benchmark wydajności JPA - porównanie produktów Java JPA ORM (Hibernate, EclipseLink, OpenJPA, DataNucleus).
- Benchmark PolePosition - pokazuje kompromisy wydajnościowe dla rozwiązań w kontekście niedopasowania impedancji obiektowo-relacyjnej .