Логічні системи управління базами даних

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

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

Ця глава має наступну структуру За даними вступним розділом знаходиться розділ 242, що містить короткий огляд по цій темі і невелику історичну довідку У розділах 243 і 244 наведена елементарна (І значною мірою спрощена) трактування, відповідно, числення висловів і числення предикатів Потім у розділі 245 міститься вступне опис такзваного доказательнотеоретического поданнябази даних, а в розділі 246 на основі понять, представлених в розділі 245, наведений опис того, що мається на увазі під терміном дедуктивна СУБД Після цього в розділі 247 обговорюються деякі підходи до вирішення проблеми рекурсивної обробки запитів Нарешті, в розділі 248 приведено резюме і дано декілька заключних зауважень

КОРОТКИЙ ОГЛЯД

Дослідження звязків між теорією баз даних і логікою почалися ще наприкінці 1970-х років або навіть раніше (див, наприклад, [243], [244] і [248]) Але, мабуть, найважливішим стимулом до пробудження в Останнім часом значного інтересу до цієї теми стала публікація в 1984 році надзвичайно важливої ​​статті Рейтера (Reiter) [2410] У цій статті Рейтер охарактеризував традиційне сприйняття систем баз даних як модельно-теоретичне Під цим в його статті малися на увазі наведені нижче особливості (у неформальному викладі)

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

б) Виконання запиту може розглядатися як обчислення деякої заданої формули (тобто логічного виразу) з цими явно заданими відносинами і кортежами

Примітка Термін модельно-теоретичний буде визначений більш точно в розділі 245

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

а) База даних в будь-який конкретний момент часу розглядається як безліч аксіом (що складається з основних аксіом, що відповідають значенням в доменах1

1 Для узгодження з іншими роботами в цій області, у цій главі автор використовує термін домен, а не більш кращий (сеготочкізренія) термінтип

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

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

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

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

SPX  WHERE   SPXQTY   &gt   250

Тут SPX – мінлива області значень, приймаюча свої значення відносно поставок У традиційній (тобто модельно-теоретичної) інтерпретації кожен кортеж з даними про постачання розглядається послідовно, при цьому формула QTY> 250 обчислюється для кожного з цих кортежів по черзі, тому результат запиту складається тільки з тих кортежів відносини поставок, для яких ця формула приймає значення TRUE На відміну від цього, в доказово-теоретичної інтерпретації кортежі поставок (поряд з деякими іншими елементами) розглядаються як аксіоми деякої логічної теорії після цього застосовуються певні методи доведення теорем для зясування того, для яких можливих значень змінної області значень SPX формула SPX QTY> 250 є логічним наслідком цих аксіом в теорії Таким чином, результат запиту складається тільки з цих конкретних значень SPX

Безумовно, цей приклад надзвичайно простий Він фактично є настільки простим, що можуть виникати труднощі при спробі зрозуміти, в чому дійсно полягає відмінність між цими двома інтерпретаціями Але суть цієї проблеми в тому, що механізм проведення міркувань, використовуваний в ході здійснення спроб доведення теореми (в доказово-теоретичної інтерпретації) може бути набагато складніше, ніж здатний продемонструвати цей простий приклад Насправді, доказово-теоретичний підхід, як буде показано нижче, дозволяє впоратися з деякими проблемами, які виходять за рамки можливостей класичних реляційних систем Більш того, доказово-теоретична інтерпретація володіє описаним нижче привабливим набором додаткових можливостей [2410]

■ Единбурзі вистави Ця властивість дозволяє визначити мову бази да них, в якому всі значення в доменах, кортежі в базових відносинах, дедуктів ві аксіоми, запити та обмеження цілісності по суті представлені оди наково, однаковим способом

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

■&nbsp&nbsp&nbsp&nbsp Семантичне моделювання Завдяки цій властивості створюється міцна осно ва, на якій можуть формуватися різні семантичні доповнення до базо вої моделі

■&nbsp&nbsp&nbsp&nbsp Розширення області застосування Нарешті, формується основа для вирішення певних завдань, які зазвичай створювали значні складнощі при використанні класичних підходів, наприклад, уявлення дізюнктівной інформації (припустимо, Постачальник S5 поставляє або деталь Р1, або деталь Р2, але не відомо, яку саме з них)

Дедуктивні аксіоми

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

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

IF MOTHER_OF (X, у) AND MOTHER_OF (у, z) THEN GRANDMOTHER_OF (X, z) END IF

Тепер система може застосувати правило, виражене у вигляді дедуктивної аксіоми, до даних, представленим за допомогою основних аксіом, тим способом, який буде описаний в розділі 244, щоб дедуктивним шляхом отримати результат GRANDMOTHER_OF (Anne, Celia) Таким чином, користувачі можуть задавати системі приблизно такі питання: Хто є бабусею Селії” або Хто є онукою Анни (Або, більш точно, Чиєю бабусею є Ганна”)

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

VAR GRANDMOTHER_OF VIEW

{ MXMOTHER AS GRANDMOTHER, MYDAUGHTER AS GRANDDAUGHTER } WHERE MXDAUGHTER = MYMOTHER

Тут навмисно використаний стиль реляційного числення мх і MY – змінні області значень, які беруть свої значення відносно MOTHER_OF Запити, подібні наведеним вище, тепер можуть оформлятися в термінах зазначеного подання, таким чином

GXGRANDMOTHER WHERE GXGRANDDAUGHTER = NAME (Celia) GX GRANDDAUGHTER WHERE GXGRANDMOTHER = NAME ( Anne )

Тут GX – мінлива області значень, приймаюча свої значення в відношенні

GRANDMOTHER_OF

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

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*