Об'єктно-реляційна база даних

Основна потреба об'єктно-реляційної бази даних виникає через те, що обидві реляційна і об'єктна бази даних мають свої індивідуальні переваги і недоліки. Ізоморфізм реляційної бази даних системи з математичним зв'язком дозволяє використовувати безліч корисних методів і теорем з теорії множин. Але ці типи баз даних не є корисними, коли мова йде про складності даних і неузгодженість між додатком і СУБД. Об'єктно-орієнтована модель бази даних враховує контейнери, такі як набори та списки, довільно визначених користувачем типів даних, а також вкладених об'єктів. Це дає спільність між системами типу додатків і системами типу бази даних, яка усуває будь-які проблеми невідповідності. Але об'єктні бази даних, на відміну від реляційних не забезпечують математичну основу для їх глибокого аналізу.[1][2]

Основна мета для об'єктно-реляційної бази даних є подолання розриву між реляційними базами даних і методів моделювання об'єктно-орієнтованих використовуваних в мовах програмування, таких як: Java, C++, Visual Basic .NET або C#. Проте, більш популярною альтернативою для досягнення такого моста є використання стандартних реляційних систем управління базами даних з деякою формою об'єктно-реляційного відображення (ORM) програмного забезпечення. У той час як традиційні RDBMS або SQL-СУБД, орієнтовані на ефективне управління даними, отриманих з обмеженого набору типів даних (визначається відповідними стандартами мови), об'єктно-реляційної СУБД дозволяє розробникам інтегрувати свої власні типи і методи, що застосовуються до них у СУБД.

ОРСУБД (такі як ODBMS або OODBMS) інтегровано з об'єктно-орієнтованою мовою програмування. Характерними властивостями ОРСУБД є:

1) складні дані;

2) спадкування типу;

3) поведінка об'єкта.

Створення комплексних даних в більшості SQL ОРСУБД засноване на попередньому визначенні схеми за допомогою визначеного користувачем типу (UDT). Ієрархія в структурованих комплексних даних пропонує додаткову властивість, тип спадкування. Тобто, структурований тип може мати підтипи, які використовують всі його атрибути і містять додаткові атрибути, специфічні для підтипу. Ще одна перевага, поведінка об'єкта, пов'язана з доступом до програмних об'єктів. Такі програмні об'єкти повинні зберігатися і переноситись для обробки баз даних, тому вони, як правило, називані як постійні об'єкти. Всередині бази даних всі відносини з постійним програмним об'єктом є відносини з його ідентифікатором об'єкта (OID). Всі ці моменти можуть бути вирішені у власне реляційній системі, хоча стандарт SQL і його реалізації накладають довільні обмеження і додаткові складності[3].

В об'єктно-орієнтоване програмування (ООП), Поведінка об'єкта описується за допомогою методів (функцій) об'єктів. Методи, позначені одним ім'ям, відрізняються за типом їх параметрів і типів об'єктів, для яких вони прикріпленими (метод підпису). ООП мови називають це поліморфізний принцип, який коротко визначається як «один інтерфейс, багато реалізацій». Інші принципи ООП, успадкування та інкапсуляція, пов'язані як з методами так і з атрибутами. Метод наслідування входить в успадкування типумодифікатори доступу. Інкапсуляція в ООП є ступінь видимості оголошена, наприклад, через public, private і protected.

Об'єктно-реляційні системи управління базами даних виросли з досліджень, які мали місце на початку 1990-х років. Це дослідження розширило існуючі реляційні бази даних шляхом додавання концепції об'єкта. Дослідники прагнули зберегти декларативні запити мови, засновані на численні предикатів як центральний компонент архітектури. Ймовірно, найвідомішим науково-дослідний проект, Postgres (UC Berkeley), породив два продукти простежуючи їх походження від цього дослідження: Illustra і PostgreSQL.

В середині 1990-х років з'явилися перші комерційні продукти. До них належить Illustra (Illustra Information Systems, придбаний Informix Software, який в свою чергу був придбаний IBM), Omniscience (Omniscience Corporation, придбаний Oracle Corporation і стала своєрідним Oracle Lite), також UniSQL (UniSQL, Inc., придбані KCOMS). Український розробник Руслан Засухин, засновник Paradigma Software, Inc., розробив і відвантажив першу версію Valentina database в середині 1990-х років як C++ SDK. До наступного десятиріччя, PostgreSQL стала комерційно життєздатною базою даних, і є основою для декількох існуючих продуктів, які підтримують його ORDBMS функції.

Комп'ютерні вчені стали посилатися на ці продукти, як «системи управління базами даних об'єктно-реляційна» або ОРСУБД[4].

Багато з ідей ранніх об'єктно-реляційних баз даних багато в чому стали включені в SQL:1999 через структуровані типи. Насправді, будь-який продукт, який дотримується об'єктно-орієнтованих аспектів SQL: 1999 можна було б описати як продукт управління базами даних об'єктно-реляційна. Наприклад, IBM's DB2, Oracle database, та Microsoft SQL Server, пред'являли вимоги, щоб підтримати цю технологію і зробити це з різним ступенем успіху.

СУБД може звичайно містити в собі SQL вирази, такі як ці:

   CREATE TABLE Customers  (
       Id          CHAR(12)    NOT NULL PRIMARY KEY,
       Surname     VARCHAR(32) NOT NULL,
       FirstName   VARCHAR(32) NOT NULL,
       DOB         DATE        NOT NULL
    );
    SELECT InitCap(Surname) || ', ' || InitCap(FirstName)
      FROM Customers
     WHERE Month(DOB) = Month(getdate())
       AND Day(DOB) = Day(getdate())

Більшість сучасних баз даних SQL дозволяють крафт призначених для користувача функцій, які дозволили б запит, щоб виглядати наступним чином:

    SELECT Formal(Id)
      FROM Customers
     WHERE Birthday(DOB) = Today()

В об'єктно-реляційної базі даних, можна було б побачити щось на зразок цього, з певним користувачем типами даних і виразами, такими як 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;

Об'єктно-реляційна модель може запропонувати ще одну перевагу в тому, що база даних може використовувати відносини між даними щоб легко збирати пов'язані записи. У додатку адресна книга, додаткова таблиця буде додана в вищі, щоб тримати нуль або більше адрес для кожного клієнта. Використовуючи традиційну СУБД, збираючи інформацію як для користувачів, так і їх адресу вимагає «приєднатися»:

     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"

Той же самий запит в об'єктно-реляційній базі даних виглядає простіше:

    SELECT Formal( C.Name )
      FROM Customers C
     WHERE C.address.city="New York" -- the linkage is 'understood' by the ORDB

• SQL
• Comparison of object-relational database management systems
• Structured Type
• Об'єктно-орієнтована база даних
• Об'єктно-реляційне відображення
• Реляційна модель даних
• LINQ
• ADO.NET

• Savushkin, Sergey (2003). A Point of View on ORDBMS. Архів оригіналу за 1 березня 2012. Процитовано 21 липня 2012.
• JPA Performance Benchmark. — comparison of Java JPA ORM Products (Hibernate, EclipseLink, OpenJPA, DataNucleus).
• PolePosition Benchmark. — shows the performance trade-offs for solutions in the object-relational impedance mismatch context.