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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку

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

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

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

Огляд[ред. | ред. код]

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

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

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

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

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

Примітки[ред. | ред. код]

  1. Frank Stajano (1995). A Gentle Introduction to Relational and Object Oriented Databases. 
  2. Naman Sogani (2015). Technical Paper Review. 
  3. Date, Christopher ‘Chris’ J; Darwen, Hugh. The Third Manifesto. 
  4. There was, at the time, a dispute whether the term was coined by Michael Stonebraker of Illustra or Won Kim of UniSQL.

Посилання[ред. | ред. код]