morozov_lektsiyi

- у межах бази даних. Об’єкти з таким часом життя породжуються під час виконання ООСУБД.

Тема 7. Перспективні технології бази даних

7.1. Бази даних з інтегрованим часом

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

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

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

Крім цього в часових базах даних важливе місце відводиться конструюванню мов (таких, як, наприклад, деякі розширення SQL), які б дозволяли специфікувати асоційовані з часом запити, а насправді навіть і виконувати достатньо рідкісні операції оновлення, які обговорювалися вище.

7.2. Основні принципи часових баз даних

Зіставимо тепер таке тривимірне відношення (див. мал. 7.1) з додатковими таблицями, які необхідні в традиційній реляційній базі даних для представлення часу, як було показано в попередньому розділі. У часовій базі даних для моделювання часу не вимагається жодних додаткових стосунків. Часове вимірювання вбудовується в саме задане відношення.

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

Було запропоновано два терміни для визначення часу ефективний час (час вступу чого-

небудь в силу) і час реєстрації.

-Ефективний час визначався як час, коли деякий факт насправді набуває чинності (тепер його називають „дійсним часом”).

-час реєстрації (зване тепер „часом трансакції”) - цей час, коли нове значення поміщається в базу даних.

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

Мал. 7.1. Тривимірне відношення з часом

7.3. Моделі даних з часом

Один з дослідницьких підходів до тимчасових баз даних був пов’язаний з так званими періодами життя (lifespan), асоційованими з об’єктами баз даних різної гранулярності - від повної бази даних до окремих рядків або кортежів. Періоди життя є відрізками часу, коли мають силу конкретні стани деякого об’єкту. Тому вони можуть служити також параметрами для вибірки інформації.

Концепцію періодів життя можна було б також асоціювати з рівнем атрибутів (стовпець в рядку), як показано на мал. 7.1. І тут знов можна провести аналогію між періодами життя на рівні кортежів і на рівні атрибутів з варіантами блокування на рівні рядків і рівні елементів для управління паралельним доступом.

В рамках часової моделі даних такого роду, як HRDM, операції тимчасового зрізу можуть застосовуватися до деякого відношення як обмежуючий критерій пошуку, що задається у фразі WHEN (коли), значною мірою таким же чином (мал. 7.1), яким при операції SELECT використовуються подібні обмеження у фразі WHERE (де).

Іншим архітектурним підходом до тимчасових баз даних, також заснованим на розширенні реляційної моделі, є тимчасова реляційна модель (Temporal Relational Model, TRM). В TRM тимчасова база даних визначається як „об’єднання двох множин відносин Rs і Rt, де Rs - безліч всіх статичних відносин, а Rt - безліч всіх відносин, що змінюються у времени”. Часові інтервали, концептуально подібні періодам життя в HRDM, включають два

обов’язкові атрибути - відмітки часу, що представляють початковий час (start time) Ts і кінцевий час (end time) Te, тобто нижню і верхню межі тимчасового інтервалу відповідно.

У зв’язку з тим, що тимчасові моделі даних, такі, як TRM, мають реляційні основи, представляється цілком природним, що в них значну роль гратиме нормалізація. В моделі TRM використовується концепція тимчасової нормальної форми TNF (Time Normal Form).

Інша корисна можливість, яку може забезпечити часове вимірювання, - це управління майбутнім часом, як, наприклад, це робиться в моделі HDBMS. У HDBMS підтримуються наступні правила для тимчасових операцій:

-Розділення історичних даних, поточних даних і даних майбутнього на різні сегменти так, щоб воно було прозорим для користувача.

-Підтримка всіх типів трансакцій над станами і єствами майбутнього.

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

7.4.Часові розширення мов баз даних

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

Варіант розширення SQL - TSQL - був використаний як інтерфейс в реалізації моделі тимчасових відносин TRM (Temporal Relation Model). Мова TSQL використовує фразу WHEN (коли), аналогічну фразі WHILE в TempSQL, і включає, крім того, наступні возможности19:

-вибірку відміток часу;

-вибірку інформації, впорядкованої в часі;

-використовування фрази TIME-SLICE (часовий зріз) для специфікації часового домену;

-використовування фрази GROUP (групувати за) для модифікованих агрегатних функцій.

У фразах WHEN може бути використаний ряд часових операторів порівняння, у тому числі.

BEFORE (перед); AFTER (після); DURING (в час); EQUIVALENT (рівно); ADJACENT

(суміжний); OVERLAP (перекриває); FOLLOWS (слідує за); PRECEDES (передує).

7.5.Об’єктно-орієнтовані часові бази даних

Часові розширення відбуватимуться, ймовірно, й у світі об’єктно-орієнтованих СУБД. Концепція багатоверсійності (підтримка низки версій) об’єктів, критична для систем автоматизованого проектування (Computer Aided Design, CAD), засобів автоматизованої розробки систем (Computer Assisted System Engineering, CASE) і багатьох інших додатків,

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

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

При рішенні багатьох обговорюваних в цій книзі проблем, пов’язаних з сховищами даних, репозиторіями і т.д., так само як і при визначенні загальної архітектури додатків,

можна отримати користь з властивостей активних баз даних Властивості активних баз даних полягають в тому, що процедурні елементи загального середовища вбудовуються в систему бази даних і управляються декларативним чином Розвиток технології активних баз даних розглядається в даний час як одна з головних тенденцій, яка революціонізує розробку додатків Філософія, на якій була заснована ця технологія, - зберігання операцій над даними і процедур разом з самими даними, - широко використовується в інших областях, наприклад в об’єктно-орієнтованих базах даних

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

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

7.7.Принципи активних систем баз даних

Здругого боку, активні системи баз даних передбачають можливості, що дозволяють:

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

-забезпечувати деяку форму моніторингу подій і умов, які впливають на дані і можуть ініціювати обробку, керовану базою даних;

-включати в систему бази даних також деякий засіб, за допомогою якого ці події і умови могли б запускати логіку усередині бази даних.

Мал. 16.2. Активна система бази даних

7.7.1. Обмеження і твердження

Обмеження є відносно простими конструкціями, що мають вигляд від специфікації зв’язків первинного і зовнішнього ключів, що використовуються в обмеженнях цілісності за посиланням (Referential Integrity), до SQL-подібних обмежень CHECK, що використовуються для перевірки приналежності значення заданому діапазону або списку значений. Обмеження

могли б розглядатися як перший засіб для вбудовування бізнес-правил в базу даних замість використовування для цієї мети логіки додатку.

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

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

7.7.2.Збережувані процедури

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

Збережувана процедура є просто модулем прикладної програми з тією лише різницею, що він „відноситься” до бази даних, а не до зовнішньої програмної системи, що використовує цю базу даних. Збережувані процедури можуть визначатися щодо однієї або більш таблиць бази даних, точно так, як і обмеження і твердження.

7.7.3.Тригери

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

Тригери є ключовими компонентами, що забезпечують перетворення бази даних в активне середовище. Після операцій вставки, оновлення і/або видалення може бути запущений тригер, асоційований з деяким об’єктом, який приведе в результаті до обчислення бізнес-правил або до виконання певних дій.

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

7.8. Розширення моделей активних баз даних

Активна база даних може бути охарактеризований як система, наступна правилам Подія-Умова-Дія. Ключ до майбутніх активних систем баз даних полягає в тому, щоб мати нагоду виражати ці правила більш перспективним декларативним чином, який допускає розширення в конструкціях штучного інтелекту, наприклад в механізмах висновку „від фактів до мети” (Forward Chaining) (тобто шляхом проходження множини дій, заснованих на правилах, і висновку деякого типу результату з ланцюжка дій).

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

7.9. Моделі трансакцій і активні бази даних

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

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

Призначена для користувача трансакція виконується як коренева (трансакція верхнього рівня) з безліччю класів правил, виконуваних у вкладених трансакціях. Ці класи правил включають:

-безпосередні, в яких що запускається тригером трансакція Т припиняється, а правило R активізується і виконується як дочірня трансакція Т;

-відкладені, в яких безпосередньо перед фіксацією трансакції Т створюється правило R

івоно виконується як дочірня трансакція Т;

-роз’єднані, в яких стартує нова трансакція верхнього рівня;

-причинні, коли що запускається тригером трансакція верхнього рівня Т2 стає в чергу за трансакцією Т1; якщо аварійно завершується Т то аварійно завершується і Т2.

7.10. Штучний інтелект і технологія баз даних

Протягом багатьох літ мова йде про бази знань і системах управління базами знань (Knowledge Base Management System, KBMS), які включають в середовище СУБД не тільки дані, але і інтелектуальні можливості. До числа тих областей ШІ, в яких представляла б цінність більш тісна інтеграція з технологією баз даних, относятся:

-сумісне використовування знань, або загальна база знань, що розділяється множиною додатків і користувачів;

-незалежність представлення знань, або обмеження того негативного ефекту, який був пов’язаний із змінами в системах;

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

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