Постреляційні системи

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

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

Активні бази даних

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

Дедуктивні бази даних

Дедуктивна БД складається з двох частин: екстенціональної, що містить факти, та інтенціональної, що містить правила для логічного висновку нових фактів на основі екстенціональної частини і запиту користувача.

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

Мови запитів і визначення інтенціональної частини БД є логічними (тому дедуктивні БД часто називають логічними). Існує прямий зв’язок дедуктивних БД із базами знань (інтенціональну частину БД можна розглядати як БЗ).

При звичайному застосуванні реляційної СУБД запити звичайно надходять на обробку по одному, тому немає приводу для їхній глобальної (міжзапитової) оптимізації. Дедуктивна ж СУБД при виконанні одного запиту користувача в загальному випадку генерує пакет запитів до реляційної СУБД, що можуть оптимізуватися спільно.

Темпоральні бази даних

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

Існує окремий напрямок досліджень і розробок в області темпоральних БД. У цій області досліджуються питання моделювання даних, мови запитів, організація даних у зовнішній пам’яті і т.д. Основна теза темпоральних систем полягає в тому, що для будь-якого об’єкта даних, створеного в момент часу і знищеного в момент часу , у БД зберігаються (і доступні користувачам) усі його стани в часовому інтервалі .

Дослідження і побудови прототипів темпоральних СУБД звичайно виконуються на основі деякої реляційної СУБД. Як і у випадку дедуктивних БД темпоральна СУБД – це надбудова над реляційною системою. Прикладом кардинального рішення проблеми темпоральних БД може служити СУБД Postgres. Ця система є новим інструментом М.Стоунбрекера для досліджень і навчання студентів в університеті м. Берклі.

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

Інтегровані чи федеративні системи і мультибази даних

Напрямок інтегрованих чи федеративних систем неоднорідних БД і мульти-БД з’явився в зв’язку з необхідністю комплексування систем БД, заснованих на різних моделях даних і керованих різними СУБД.

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

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

СУБД наступного покоління

Термін “системи наступного (чи третього) покоління” ввійшов у життя після опублікування групою відомих фахівців в області БД “Маніфесту систем баз даних третього покоління”. Прихильники цього напрямку дотримують принципу еволюційного розвитку можливостей СУБД без корінного ламання попередніх підходів і зі збереженням наступності із системами попереднього покоління.

Частково вимога до систем наступного покоління означає просто необхідність реалізації давно відомих властивостей, відсутніх у більшості поточних реляційних СУБД (обмежень цілісності, тригери, модифікація БД через представлення і т.д.). У число нових вимог входить повнота системи типів, підтримуваних у СУБД; підтримка ієрархії і спадкування типів; можливість керування складними об’єктами тощо.

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

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Поняття системи управління базами даних, банку даних, системи баз даних	\|	Об’єктно-орієнтовані бази даних

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.005 сек.