{AREAt, PRODI} соответствует только одно значение номера торгового агента (атрибут REPI). Исходя из этого, можно ввести следующую переменную-отнощение,

APR { AREA!, PRODI, REPI }

KEY { AREAI, PRODI } Здесь явным образом реализована следующая функциональная зависимость. { AREAI, PRODI } -> REPI

Безусловно, определение комбинации атрибутов {AREAI, PRODI} в качестве потенциального ключа переменной-отнощения APR является достаточным условием для выражения этой функциональной зависимости. Однако теперь переменные-отнощения RA, RP и АР оказались избыточными, поскольку они являются проекциями переменной-отнощения APR, а потому могут быть опущены. Вместо ограничения С теперь необходимо ввести следующее ограничение С1.

APR { AREAI, PRODI } = AREA { AREAI } TIMES PRODUCT { PRODi }

Oho также должно быть задано отдельно и явным образом (поскольку оно не предполагается существующими потенциальными ключами).

Кроме того, поскольку каждый торговый агент продает весь свой набор товаров в каждом из обслуживаемых им регионов, для переменной-отнощения APR необходимо установить дополнительное ограничение С2 (оно представляет нетривиальную МЗЗ, следовательно, переменная-отнощение APR не находится в 4НФ).

REPI AREAI I PRODI

Таким образом, в окончательном виде проект базы данных состоит из переменных-отнощений REPS, AREAS, PRODUCTS и APR вместе с заданными явным образом ограничениями С1 и С2. I

Это упражнение хорошо иллюстрирует тот факт, что в общем случае порядок нормализации адекватно представляет некоторые семантические аспекты заданной проблемы (в основном, зависимости, которые подразумеваются потенциальными ключами, где под зависимостями имеются в виду функциональные и многозначные зависимости, а также зависимости соединения). Однако может также потребоваться явное указание дополнительных зависимостей для некоторых особых аспектов, а отдельные аспекты могут быть и вовсе непредставимы с помощью подобных типов зависимостей. Это упражнение демонстрирует, что не всегда желательно полностью нормализовать некоторую переменную-отношение (в нашем примере переменная-отношение APR находится в НФБК, но не в 4НФ).

12.4. Все вносимые изменения достаточно просты - стоит лишь заменить упоминания функциональных зависимостей и НФБК понятиями многозначной зависимости и 4НФ. Тогда алгоритм декомпозиции будет следующим.

1. Зададим переменную-отношение R в качестве начального значения для декомпозиции D.

2. Для каждой переменной-отношения Т (которая не находится в 4НФ), входящей в состав декомпозиции D, выполним действия, которые перечислены в пп. 2 и 3.

3. Пусть зависимость X -)-> Y является многозначной зависимостью в переменной-отношении Т, которая не удовлетворяет требованиям 4НФ.

4. Заменим переменную-отношение Т в декомпозиции D двумя ее проекциями, а я-л.пг и>- именнр; одной по атрибутам X и Y, а другой - по всем атрибутам, за исключением атрибута Y.

12.5. Это пример циклического ограничения , которому соответствует приведенная ниже реляционная структура.

REP { НЕР#, ... }

KEY { REP# } AREA { AREAjf, ... }

KEY { AREA* }

PRODUCT { REPI, ... } KEY { PROD* }

RA { REP#, AREA* } KEY { REP#, AREAI }

AP { AREAI, PRODI } KEY { AREAI, PRODI }

PR { PRODI, REPI }

KEY { PRODI, REPI }

Кроме того, пользователя следует информировать о том, что соединение переменных-отношений RA, RP и АР не содержит никаких ловушек соединения.

( RA JOIN АР JOIN PR ) { REPI, AREA! } = RA AND ( RA JOIN AP JOIN PR ) { AREAI, PRODI } = AP AND ( RA JOIN AP JOIN PR ) { PRODI, REPt } = PR

Глава 13

Семантическое моделирование

13.1. Введение

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

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

Следует отметить, что, с нашей точки зрения, система с поддержкой предикатов переменных-отношений и базы данных (обсуждавшихся в главе 8) должна была бы понимать немного больше . Иначе говоря, можно было бы возразить, что описанная поддержка предикатов может пониматься, как удобное и эффективное основание для семантического моделирования. Однако, как это ни печально, большинство схем семантического моделирования не имеет никакого строгого обоснования, поскольку все они в той или иной степени являются произвольными (предложения в [13.17, 13.19] являются исключениями). Возможно, такое состояние дел в будущем изменится, особенно благодаря растущему пониманию в мире коммерции важности бизнес-правил [8.18, 8.19]. Описанные в главе 8 предикаты, по сути, как раз и являются такими бизнес-правилами .