Об’єктно-реляційна система управління базами даних PostgreSQL

Реляційні бази даних страждають від відмінностей у реалізації мови SQL, хоча це і не проблема реляційної моделі. Кожна реляційна СУБД реалізує якусь частину стандарту SQL і набір унікальних команд, що ускладнює завдання програмістам, які намагаються перейти від однієї СУБД на іншу. Доводиться робити нелегкий вибір між максимальною експортністю і максимальною продуктивністю. У першому випадку потрібно дотримуватися мінімального загального набору команд, підтримуються у кожній СУБД. У другому випадку програміст просто зосереджується на роботі в даній конкретній СУБД, використовуючи переваги її унікальних команд і функцій СУБД [1].

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

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

З допомогою ООСУБД вирішуються дві проблеми. По-перше, складні інформаційні структури виражаються у них краще, ніж у реляційних базах даних, а по-друге, усувається необхідність транслювати дані з формату, який підтримується в СУБД. Наприклад, в реляційній СУБД розмірність цілих чисел може становити 11 цифр, а у використовуваній мові програмування – 16. Програмісту доведеться враховувати цю ситуацію[4].

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

В об'єктній моделі даних підтримуються нерегламентовані запити, але мовою їх складання не обов'язково є SQL. Логічне представлення даних може не відповідати реляційній моделі, тому застосування мови SQL стане безглуздим. Часто зручніше обробляти об'єкти в пам'яті, виконуючи відповідні види пошуку.

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

Об’єктно-реляційні поєднують у собі риси реляційної та об'єктної моделей. Їх виникнення пояснюється тим, що реляційні бази даних добре працюють з вбудованими типами даних і набагато гірше – з користувацькими, нестандартними. Коли з'являється новий важливий тип даних, доводиться або включати його підтримку в СУБД, або змушувати програміста самостійно управляти даними в додатку. Не всяку інформацію має сенс інтерпретувати у вигляді ланцюжків символів або цифр. Уявімо собі музичну базу даних. Пісню, закодовану у вигляді аудіофайлу, можна помістити в текстовому полі великого розміру, але як в такому разі буде здійснюватися текстовий пошук?

Перебудова архітектури СУБД з метою включення в неї підтримки нового типу даних – не кращий вихід з положення. Замість цього об'єктно-реляційна СУБД дозволяє завантажувати код, призначений для обробки "нетипових" даних. Таким чином, база даних зберігає свою табличну структуру, але спосіб обробки деяких полів таблиць визначається ззовні, тобто програмістом[6].

 

2. За ступенем роздрібненості

За ступенем роздрібненості СУБД поділяються на:

• локальні СУБД (всі частини локальної СУБД розміщуються на одному комп'ютері);
• розподілені СУБД (частини СУБД можуть розміщуватися на двох та більше комп'ютерах).

 

3. За способом доступу до БД

За способом доступу до БД СУБД поділяються на:

• файл-серверні;
• клієнт-серверні;
• вбудовані.

У файл-серверних СУБД файли даних розташовуються централізовано на файл-сервері. СУБД розташовується на кожному клієнтському комп'ютері (робочої станції). Доступ до СУБД даними здійснюється через локальну мережу. Синхронізація читань і оновлень здійснюється за допомогою файлових блокувань. Перевагою цієї архітектури є низька навантаження на ЦП сервера. Недоліки: потенційно висока завантаження локальної мережі; утрудненість централізованого управління; утрудненість забезпечення таких важливих характеристик як висока надійність, висока доступність і висока безпека. Застосовуються найчастіше в локальних додатках, які використовують функції управління БД. На даний момент файл-серверна технологія вважається застарілою. Приклади: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

Клієнт-серверна СУБД розташовується на сервері разом з БД і здійснює доступ до БД безпосередньо, у монопольному режимі. Всі клієнтські запити на обробку даних обробляються клієнт-серверної СУБД централізовано. Недолік клієнт-серверних СУБД полягає в підвищених вимогах до сервера. Переваги: потенційно більш низьке завантаження локальної мережі; зручність централізованого управління; зручність забезпечення таких важливих характеристик як висока надійність, висока доступність і висока безпека. Приклади: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛІНТЕР.

Вбудована СУБД – СУБД, яка може поставлятися як складова частина деякого програмного продукту, не вимагаючи процедури самостійної установки. Вбудована СУБД призначена для локального зберігання даних програми і не розрахована на колективне використання в мережі. Фізично вбудована СУБД найчастіше реалізована у вигляді підключається бібліотеки. Доступ до даних з боку програми може відбуватися через SQL або через спеціальні програмні інтерфейси. Приклади: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Sav Zigzag, Microsoft SQL Server Compact, ЛІНТЕР.

Основні ідеї сучасної інформаційної технології базуються на концепції баз даних (БД). Відповідно до даної концепції основою інформаційної технології є дані, організовані в БД, адекватно відбивають реалії дійсності в тій або іншій предметній області і забезпечують користувача актуальною інформацією у відповідній предметній області. Перші БД з'явилися вже на початку 1-го покоління ЕОМ, представляючи собою окремі файли даних або їх прості сукупності. По мірі збільшення об'єму і структурної складності збереженої інформації, а також розширення кола споживачів; інформації визначилася необхідність створення зручних ефективних систем інтеграції збережених даних і управління ними. В кінці 60-х років це призвело до створення перших комерційних систем управління базами даних (СУБД), які підтримують організацію і ведення БД. Перед обговоренням подальшого матеріалу, нам буде потрібно ряд основних понять, які використовуються в інформаційних системах різного призначення.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2  ОБ’ЄКТНО-РЕЛЯЦІЙНА СИСТЕМА УПРАВЛІННЯ БАЗАМИ ДАНИХ POSTGRESQL

 

2.1 Історія  розвитку

Об'єктно-реляційна СУБД (ОРСУБД) – реляційна СУБД (РСУБД), підтримуюча деякі технології, які реалізують об'єктно-орієнтований підхід: об'єкти, класи і спадкування реалізовані в структурі баз даних і мовою запитів.

PostgreSQL – це вільно розповсюджувана ОРСУБД та найбільш розвинута з відкритих баз даних у світі і є реальною альтернативою комерційним базам даних.

Спочатку була некомерційна СУБД Postgres, розроблена, як і багато open-source проектів, в Каліфорнійському університеті в Берклі. До розробки Postgres, що почалася в 1986 році, мав безпосереднє відношення Майкл Стоунбрейкера, керівник більш раннього проекту Ingres, на той момент вже придбаного компанією Computer Associates. Сама назва «Postgres» розшифровується як «Post Ingres», відповідно, при створенні Postgres були застосовані раніше зроблені напрацювання.

Стоунбрейкер і його студенти розробляли нову СУБД протягом восьми років, з 1986 по 1994 рік. За цей період в синтаксис були введені процедури, правила, користувацькі типи й багато інших компонентів. Робота не пройшла марно – в 1995 році розробка знову розділилася: Стоунбрейкер використовував отриманий досвід у створенні комерційної СУБД Illustra, а його студенти розробили нову версію Postgres – Postgres95, в якій мова запитів POSTQUEL – спадщина Ingres – була замінена на SQL.

У цей момент розробка Postgres95 була виведена за межі університету і передана команді ентузіастів. З цього моменту СУБД отримала ім'я, під яким вона відома і розвивається в поточний момент - PostgreSQL.

 

 

2.2 Основні  можливості ОРСУБД PostgreSQL

1. Функції

Функції є блоками коду, що виконуються на сервері, а не на клієнті БД. Хоча вони можуть бути написані на чистому SQL, реалізація додаткової логіки, наприклад, умовних переходів і циклів, виходить за рамки власне SQL і вимагає використання деяких мовних розширень. Функції можуть писатися з використанням однієї з наступних мов:

• вбудованої процедурної мови PL/pgSQL, яка багато в чому аналогічна мові PL/SQL, що використовується в СУБД Oracle;
• скриптової мови – PL/Lua, PL/LOLCODE, PL/Perl, plPHP, PL/Python, PL/Ruby, PL/sh, PL/Tcl і PL/Scheme;
• класичної мови – C, C++, Java (через модуль PL/Java);
• статистичної мови R (через модуль PL/R).

PostgreSQL допускає використання функцій, які повертають набір записів, який можна використовувати так само, як і результат виконання звичайного запиту.

Функції можуть виконуватися як з правами їх творця, так і з правами поточного користувача.

Іноді функції ототожнюються з збереженими процедурами, однак між цими поняттями є різниця.

 

2.2.2 Тригери

Тригери визначаються як функції, ініційовані DML-операціями. Наприклад, операція INSERT може запускати тригер, який перевіряє доданий запис на відповідності певним умовам. При написанні функцій для тригерів можуть використовуватися різні мови програмування.

Тригери асоціюються з таблицями. Множинні тригери виконуються в алфавітному порядку.

 

 

2.2.3 Правила та  представлення

Механізм правил (англ. rules) являє собою механізм створення користувацьких обробників не тільки DML-операцій, але і операції вибірки. Основна відмінність від механізму тригерів полягає в тому, що правила спрацьовують на етапі розбору запиту, до вибору оптимального плану виконання і самого процесу виконання. Правила дозволяють змінити поведінку системи при виконанні SQL-операції до таблиці.

Хорошим прикладом є реалізація механізму представлень (англ. views): при створенні представлення створюється правило, яке визначає, що замість виконання операції вибірки до представлення система повинна виконувати операцію вибірки до базової таблиці/таблиці з урахуванням умов вибірки, що лежать в основі визначення уявлення. Для створення уявлень, які підтримують операції оновлення правила для операцій вставки, зміни і видалення рядків повинні бути визначені користувачем.

 

4. Індекси

В PostgreSQL є підтримка індексів наступних типів: B-дерево, хеш, R-дерево, GiST, GIN(4). При необхідності можна створювати нові типи індексів, хоча це далеко не тривіальний процес. Індекси в PostgreSQL володіють наступними властивостями:

• можливий перегляд індексу не тільки в прямому, але й у зворотному порядку – створення окремого індексу для роботи конструкції ORDER BY ... DESC не потрібно;
• можливе створення індексу над кількома стовпцями таблиці, в тому числі над стовпцями різних типів даних;
• індекси можуть бути функціональними, тобто будуватися не на базі набору значень певного стовпця/стовпців, а на базі набору значень функції від набору значень;
• індекси можуть бути частковими, тобто будуватися тільки по частині таблиці за деякою її проекції); у деяких випадках це допомагає створювати більш компактні індекси або досягати покращення продуктивності за рахунок використання різних типів індексів для різних (наприклад, з точки зору частоти оновлення) частин таблиці;
• планувальник запитів може використовувати кілька індексів одночасно для виконання складних запитів.

 

2.2.5 Механізм «Multiversion Concurrency Control»

PostgreSQL підтримує одночасну модифікацію БД багатьма користувачами з допомогою механізму Multiversion Concurrency Control (MVCC). Завдяки цьому дотримуються вимоги ACID, і практично відпадає потреба у блокуванні читання [8].