23.6. Дедуктивные субд

Дедуктивная СУБД — это СУБД, в которой поддерживается доказательно-теоретичес­кий подход к базам данных и которая, в частности, позволяет вывести дополнительные факты из экстенсиональной базы данных с помощью специализированных дедуктивных аксиом, или правил вывода, примененных к известным фактам⁴. Дедуктивные аксиомы вместе с ог­раничениями целостности (они будут описаны ниже) образуют интенсиональную базу данных (intensional database). Экстенсиональная и интенсиональная базы данных вместе со­ставляют дедуктивную базу данных (это не совсем удачное название, поскольку на самом де­ле выводы делает именно СУБД, а не база данных).

⁴ В этой связи стоит заметить, что еще в 1974 году Кодд утверждал, что одной из задач реляционной модели является, несомненно, "поглощение фактов выборки и управления файловы­ми полями для пополнения в дальнейшем логического сервиса в коммерческом мире " [11.2], [25.8].

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

Рассмотрим, как будет выглядеть база данных поставщиков и деталей, преде влен-ная на рис. 3.8, в форме "дедуктивной СУБД". Прежде всего следует определить набор основных аксиом, которые задают допустимые значения домена.

Замечание. Далее для лучшей читабельности будут использоваться по существу те же со­глашения относительно представления значений, которые применялись, например, на рис. 3.8, и поэтому в качестве сокращения для записи QTY( 300) будет использоваться просто 300 и т.д.

St { 'SI' )	NAME {	'Smith' )	STATUS	5 )	CITY {	'London'
St ( 'S2' )	NAME (	'Jones' )	STATUS	10 )	CITY (	'Paris'
St ( 'S3' )	NAME (	'Blake' )	STATUS	15 )	CITY (	'Rome' )
Si ( 'S4' )	NAME (	'Clark' )	и т.д.		CITY (	'Athens'
Si ( 'S5' )	NAME (	'Adams' )			и т.д.
Si ( 'S6' )	NAME (	'White' )
St ( 'S7' }	NAME {	'Nut' )
и т.д.	NAME ( NAME ( и Т.Д.	'Bolt' ) 'Screw' )

и т.д.

Затем следует задать основные аксиомы для кортежей базовых отношений.

S ( 'SI', 'Smith', 20, 'London' ) S ( 'S2', 'Jones', 10, 'Paris' ) и т.д.

P { 'PI', 'Nut', 'Red', 12, 'London' ) и т.д.

SP ( 'SI', 'PI', 300 ) и т.д.

Замечание. Конечно, здесь всерьез не предполагается, что экстенсиональная база данных будет построена на основе всего лишь явного перечисления всех основных аксиом, как пока­зано выше. Для этого, скорее всего, будет использовано традиционное определение и тради­ционные методы ввода данных. Иначе говоря, дедуктивные СУБД применяют свои выводы для традиционных баз данных, которые уже существуют и построены самым обычным спо­собом. Однако следует обратить внимание на чрезвычайно важный факт: экстенсиональная база данных не нарушает заданных ограничений целостности, поскольку база данных, нару­шающая эти ограничения, представляет (на языке логических терминов) несовместимый на­бор аксиом. Таким образом может быть доказана "истинность" абсолютно любого утвер­ждения, каким бы оно ни было (другими словами, могут быть выведены противоречия). По той же причине очень важно, чтобы набор ограничений целостности был совместимым.

Теперь перейдем к описанию интенсиональной базы данных. Для нее существует следующий набор ограничений домена.

S ( s, sn, st, sc ) => Si ( s ) AND

NAME { sn ) AND STATUS ( st ) AND CITY ( sc )

Р ( р, рп, pi, pw, рс ) => Р| ( р ) AND

NAME { рп ) AND COLOR ( pi ) AND WEIGHT ( pw ) AND CITY ( pc )

и т.д.

Для интенсиональной базы данных существует также следующий набор ограничений потенциальных ключей.

S ( s, snl, stl, scl ) AND S ( s, sn2, st2, sc2 )

=> snl = sn2 AND \

stl = st2 AND scl = sc2

и т.д.

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

SP { s, р, q ) => S ( s, sn, st, sc ) AND P ( p, pn, pt, pw, pc )

И т.д.

Замечание. Для удобства представления здесь предполагается, что переменные, расположенные справа от символа импликации (sn, st и т.д.), связаны с квантором су­ществования. (Все остальные, как отмечалось выше, в разделе 23.3, связаны с квантором всеобщности.) С технической точки зрения мы нуждаемся в некоторой функции Сколе­ма. Например, переменная sn в действительности должна быть заменена, скажем, функ­цией SN( s), где SN является функцией Сколема.

Кстати, обратите внимание, что в данном случае многие ограничения нельзя считать чистыми предложениями в смысле, определенном в разделе 23.5, поскольку их правая сторона не является дизъюнкцией простых термов.

Теперь следует добавить несколько дедуктивных аксиом.

S ( s, sn, st, sc ) AND st > 15

G00D_SUPPLIER ( S, St, sc )

(Сравните с определением представления G00D_SDPPLIER, данным в разделе 9.1 главы 9.)

S ( sx, sxn, sxt, sc ) AND S { sy, syn, syt, sc )

SS_C0L0CATED { sx, sy ) S ( s, sn, st, с ) AND P ( p, pn, pi, pw, с )

=> SP_C0L0CATED ( s, p )

И т.д.

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

PART_STRUCTURE ( px, py ) => P { px, xn, xl, xw, xc ) AND

P ( РУ, У", yl, yw, yc )

Затем необходимо определить некоторые значения ее данных.

PART_STRUCTURE ( 'РГ, 'Р2' ) PART_STRUCTURE { 'РГ, 'РЗ' ) PART_STRUCTURE ( 'Р2', 'РЗ' ) PART_STRUCTURE { 'Р2', 'Р4' ) и т.д.

(На практике определение PART STRUCTURE должно было бы также иметь аргумент "количество", который указывал бы количество деталей ру, входящих в состав детали рх, но в данном случае он опускается из соображений простоты.)

Теперь можно добавить пару дедуктивных аксиом для объяснения, каким образом де­таль рх содержит деталь ру в качестве компонента любого уровня.

PART STRUCTURE ( рх, ру ) => C0MP0NENT_0F ( рх, ру ) PART~STRUCTURE ( рх, pz ) AND C0MP0NENT_0F ( pz, ру )

=> C0MP0NENT_0F ( px, py )

Иначе говоря, деталь py является компонентом детали рх на определенном уровне, если она является непосредственным компонентом либо детали рх, либо детали pz, кото­рая, в свою очередь, является компонентом детали рх на определенном уровне. Обратите внимание, что вторая аксиома рекурсивна, поскольку предикат C0MP0NENT_0F определя­ется в ней на основе самого этого предиката⁵. В классических реляционных системах, наоборот, не допускается использование подобных рекурсивных определений представ­лений (а также запросов, ограничений целостности и т.п.). Эта способность поддержи­вать рекурсивные определения — одно из самых очевидных различий между дедуктив­ными СУБД и их классическими аналогами. Хотя, как уже упоминалось в разделе 23.5 и как было показано в главе 6, не существует фундаментального ограничения, из-за кото­рого классическую реляционную алгебру нельзя было бы расширить для поддержки со­ответствующего набора рекурсивных операторов.

В разделе 23.7 возможность поддержки рекурсии обсуждается несколько подробнее.

Язык Datalog

Из сказанного можно сделать вывод, что наиболее ясно выраженной частью дедук­тивной СУБД может быть язык, на котором будут формулироваться дедуктивные аксио­мы (или правила). Самым известным языком такого типа является Datalog [23.9], на­званный так по аналогии с языком Prolog. Ниже приведено его краткое описание.

Замечание. Основное внимание при создании этого языка уделялось не его вычисли­тельным (как это обычно бывает с традиционными реляционными моделями [5.1]), а описательным качествам. При этом основной целью было создание языка, гораздо более

^J Фактически было определено транзитивное замыкание — в любой момент отношение, со­ответствующее предикату C0MP0NENT_0F, является транзитивным замыканием отношения, соответствующего предикату PART_STRUCTURE (см. главу 6).

выразительного, чем традиционные реляционные языки [23.9]. В результате в языке DataSog, как и во всех логических СУБД, был сделан акцент на операциях выполнения запросов, а не обновления данных, хотя можно и нужно расширить этот язык также для поддержки операций обновления (подробнее об этом будет сказано ниже).

В простейшей форме язык Datalog поддерживает формулировку правил в виде про­стых предложений Хорна без функций. В разделе 23.4 предложение Хорна было опреде­лено как WFF-формула одного из двух видов.

Al AND А2 AND ... AND An

Al AND A2 AND ... AND Ал =» В

В этих конструкциях все А и В являются неотрицаемыми экземплярами предикатов, которые содержат только константы и переменные. Однако в языке Datalog вторая из приведенных конструкций записывается в обратном порядке.

В <= Al AND А2 AND ... AND An

Для полного соответствия с другими публикациями на эту тему далее будет использовать­ся именно такая запись. В данном предложении В является заголовком правила, или заклю­чением, а терм А— телом правила, или предпосылкой либо целью, в которой отдельные термы являются подчиненными целями (или подцелями). Для краткости связки AND часто заменяют запятыми. Следовательно, программа на языке Datalog представляет собой набор таких предложений, разделенных обычным образом, т.е. точкой с запятой (в этой книге, одна­ко, вместо точки с запятой используется перенос на отдельную строку). При этом в такой про­грамме порядок расположения предложений не имеет никакого значения.

Заметим, что вся дедуктивная база данных может рассматриваться как программа Datalog в указанном выше смысле. Можно, например, все аксиомы, заданные для по­ставщиков и деталей (основные аксиомы, ограничения целостности и дедуктивные ак­сиомы), записать в стиле программы Datalog, разделив их точкой с запятой или размес­тив в отдельных строках, и в результате получить программу на языке Datalog. Однако, как уже указывалось, экстенсиональная часть базы данных обычно не определяется та­ким способом; она определяется так, как принято в традиционных базах данных. Основ­ная функция языка Datalog заключается в формулировании дедуктивных аксиом. Как от­мечалось выше, эту функцию следует рассматривать в качестве расширения механизма определений представлений, существующего в современных реляционных СУБД.

Язык Datalog может также использоваться в качестве языка запроса (точно так, как и язык Prolog). Для примера предположим, что на языке Datalog дано следующее опреде­ление "хороших" поставщиков G00D_SUPPLIER.

GOOD_SUPPLIER { s, st, sc ) <=■ S { s, sn, st, sc )

AND st > 15

Ниже приведены примеры запросов на основе этого определения.

1. Найти всех хороших поставщиков.

? <= G00D_SUPPLIER ( s, st, sc )

2. Найти хороших поставщиков в Париже.

? <= GOOD_SUPPLIER ( s, st, 'Paris' )

3. Является ли поставщик с номером 'S1' хорошим? ? ф= G00D_SUPPLIER ( 'SI', st, sc )

И так далее. Иначе говоря, запрос на языке Datalog состоит из специального правила с заголовком типа "?" и телом, состоящим из одного терма, который обозначает резуль­тат запроса. Заголовок "?" означает (по соглашению) "Показать".

Следует отметить, что несмотря на поддержку рекурсии существует достаточное ко­личество стандартных операций для традиционных реляционных систем, которые не поддерживаются в языке Datalog, например скалярные операции ("+", "-" и т.д.), опера­ции обобщения (COUNT, SUM и др.), группирования и т.д. В этом языке также не поддер­живается именование атрибутов (значение аргументов предиката зависит от его относи­тельного расположения), не обеспечивается полная поддержка доменов (т.е. типов дан­ных, определенных пользователем в смысле, изложенном в главе 5). Как уже отмечалось, в языке не предусмотрены операции обновления, а также не поддерживается деклара­тивная спецификация удаления и обновления внешних ключей (DELETE CASCADE и т.д.).

Для преодоления всех этих недостатков было предложено несколько расширений языка Datalog. Предполагается, что, помимо всего прочего, эти расширения обладают следующими дополнительными возможностями.

■ Отрицаемые предпосылки, например такие, как показано ниже.

SS_C0L0CATED ( sx, sy ) «= S ( sx, sxn, sxt, sc ) AND

S ( sy, syn, syt, sc ) AND NOT ( sx = sy )

■ Скалярные операторы (встроенные и определенные пользователем), например та­кие, как показано ниже.

P_WT_IN_GRAMS { р, рп, pi, рд, рс ) <=

^р ( Pi P"i pli P^wi P^c ) ^AND pg = pw * 454 В данном примере предполагается, что встроенная функция "*" (умножение) может быть записана в обычном инфиксном представлении. Более ортодоксальное представ­ление терма, следующего за оператором AND, выглядело бы как = (рд, * (pw, 4 5 4)).

• Операторы обобщения и группирования (в некотором смысле эта тема касается отдельных особенностей оператора SUMMARIZE, что подробнее описано в главе 6). Эти операторы необходимы для того, чтобы разрешить проблему так называемых требований обобщения. Она заключается не только в поиске деталей ру, которые являются компонентами деталей рх на любом уровне, но также в выяснении, сколько деталей ру (на всех уровнях) требуется для изготовления детали рх (при этом, естественно, предполагается, что переменная-отношение PART_STRUCTURE содержит атрибут QTY).

• Операторы обновления. Один из подходов в реализации этих операций, и не толь­ко их, основан на том наблюдении, что в языке Datalog любой предикат в заголов­ке правила должен быть неотрицаемым и каждый кортеж, генерируемый этим правилом, может рассматриваться как "вставленный" в результирующее отноше­ние. Возможное расширение, таким образом, должно допускать использование отрицаемых предикатов в заголовке правила и рассматривать отрицание как за­прос на удаление (соответствующих кортежей).

■ Предложения "не-хорнвеского" типа в теле правила. Иначе говоря, в определе­нии правил допускается использование WFF-формул самого общего вида.

Обзор этих расширений вместе с примерами и обсуждением приложений языка Datalog можно найти в книге [23.10], где также обсуждается множество методов реали­зации языка Datalog.