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

Об'єктно-реляційна база даних (англ. object-relational database, ORD), чи Об'єктно-реляційна СКБД, це система керування базами даних подібна до реляційної, але з об'єктно-орієнтованою моделлю бази: об'єкти, класи та наслідування підтримуються в схемі даних та мові запитів. На додачу, як і в реляційних БД, вона підтримує розширення моделі даних новими типами даних та методами.

Приклад об'єктно-орієнтованої моделі бази даних

Об'єктно-реляційна база даних знаходиться в проміжному положенні між реляційними базами даних і об'єктно-орієнтованими базами даних (об'єктними базами даних). В об'єктно-реляційних баз даних, підхід, по суті, як у реляційних баз даних: дані зберігаються в базі даних і маніпулюють всі разом із запитами мовою запитів; на іншому полюсі знаходиться OODBMSes, в якій база даних є ніби стійким об'єктом, сховищем для програмного забезпечення, написаного об'єктно-орієнтованою мовою програмування, з програмуванням API для зберігання та вилучення об'єктів, і мало або взагалі не має конкретної підтримки запитів.

Огляд ред.

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

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

Багато з ідей ранніх об'єктно-реляційних баз даних багато в чому стали включені в 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

Див. також ред.

Примітки ред.

  1. Frank Stajano (1995), A Gentle Introduction to Relational and Object Oriented Databases (PDF)
  2. Naman Sogani (2015), Technical Paper Review (PDF), архів оригіналу (PDF) за 4 березня 2016, процитовано 12 червня 2017
  3. Date, Christopher ‘Chris’ J; Darwen, Hugh, The Third Manifesto

Посилання ред.