енням БД називається активною, якщо СУБД по відношенню до неї виконує не тільки ті дії, які явно вказує користувач, але й додаткові дії відповідно до правил, закладеними в саму БД. Легко бачити, що основа цієї ідеї містилася в мові SQL часу System R. Насправді, що є визначення тригера або умовного впливу як не введення в БД правила, відповідно до якого СУБД повинна виробляти додаткові дії? Погано лише те, що насправді тригери не були повністю реалізовані ні в одній з відомих систем, навіть і в System R. І це не випадково, тому що реалізація такого апарату в СУБД дуже складна, накладна і не повністю зрозуміла.
Дедуктивні бази даних
За визначенням, дедуктивна БД складається з двох частин: екстенсіональной, що містить факти, і інтенсіональні, що містить правила для логічного висновку нових фактів на основі екстенсіональной частини та запиту користувача.
Легко бачити, що при такому загальному визначенні SQL-орієнтовану реляционную СУБД можна віднести до дедуктивним системам. Дійсно, що є певні в схемі реляційної БД уявлення що не інтенсиональная частина БД.
Основною відмінністю реальної дедуктивної СУБД від реляційної є те, що і правила інтенсіональні частини БД, і запити користувачів можуть містити рекурсію. Саме можливість рекурсії робить реалізацію дедуктивної СУБД дуже складною і в багатьох випадках ефективно нерозв'язною проблемою. Зазвичай мови запитів і визначення інтенсіональні частини БД є логічними (тому дедуктивні БД часто називають логічними). Є прямий зв'язок дедуктивних БД з базами знань (интенсиональное частина БД можна розглядати як БЗ). Більш того, важко провести грань між цими двома сутностями; принаймні, загальної думки з цього приводу не існує. Яка ж зв'язок дедуктивних БД з реляційними СУБД, крім того, що реляційна БД є виродженим окремим випадком дедуктивної? Основним є те, що для реалізації дедуктивної СУБД зазвичай застосовується реляційна система. Така система виступає в ролі хранителя фактів і виконавця запитів, що надходять з рівня дедуктивної СУБД. Між іншим, таке використання реляційних СУБД різко актуалізує завдання глобальної оптимізації запитів.
При звичайному застосуванні реляційної СУБД запити зазвичай надходять на обробку по одному, тому немає приводу для їх глобальної (межзапросной) оптимізації. Дедуктивна ж СУБД при виконанні одного запиту користувача в загальному випадку генерує пакет запитів до реляційної СУБД, які можуть оптимізуватися спільно. Звичайно, у випадку, коли набір правил дедуктивної БД стає великий, і їх неможливо розмістити в оперативній пам'яті, виникає проблема управління їх зберіганням і доступом до них у зовнішній пам'яті. Тут знову ж таки може бути застосована реляційна система, але вже не надто ефективно. Потрібні більш складні структури даних та інші умови вибірки. Відомі приватні спроби вирішити цю проблему, але спільного рішення поки немає.
Темпоральні бази даних
Звичайні БД зберігають миттєвий знімок моделі предметної області. Будь-яка зміна в момент часу t деякого об'єкта призводить до недоступності стану цього об'єкта в попередній момент часу. Найцікавіше, що насправді в більшості розвинених СУБД попередній стан об'єкту зберігається в журналі змін, але можливості доступу з боку користувача немає.
Розподілені СУБД
У теоретичном...
