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