Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Вопросы к экзамену БД SQL.doc
Скачиваний:
2
Добавлен:
01.07.2025
Размер:
349.7 Кб
Скачать
  1. Предварительные отношения для бинарных связей типа m:n. Преобразование составных объектов. Преобразование тернарных связей. Преобразование рекурсивных связей.

Предварительные отношения для бинарных связей типа M:N

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

  1. Проверка модели с помощью концепций последовательной нормализации. Проверка модели в отношении транзакций пользователей. Проверка поддержки целостности данных.

Целью применения этой процедуры является получение гарантий того, что каждое из отношений, полученных на основе концептуальной модели, находится, по крайней мере, в НФБК.

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

Правильно выполненные действия по проектированию модели предметной области должны обязательно привести к созданию набора отношений в НФБК. Функциональные зависимости, определенные для реляционной модели, являются атрибутами связей с показателями кардинальности «один к одному» или «один ко многим». Описанный процесс преобразования каждой из этих конструкций в атрибуты реляционных отношений гарантирует, что они будут зависеть только от ключевых атрибутов. Таким образом, каждая полученная реляционная таблица будет иметь НФБК.

Проверка модели в отношении транзакций пользователей

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

Наиболее действенный метод осуществления указанной проверки заключается в нанесении непосредственно на ER-диаграммы всех путей, которые потребуются для выполнения каждой из транзакций. Такой подход позволяет выделить в модели ценные с точки зрения транзакций ее области, и наоборот, выявить области, бесполезные для транзакций. По отношению к бесполезным для транзакций областям концептуальной модели можно вполне справедливо поставить вопрос о целесообразности их присутствия в модели. В то же время, если в модели присутствует область, не позволяющая выполнить некоторую необходимую пользователю транзакцию, то это может свидетельствовать о том, что в данной области не достает какого-то объекта или связи, а, следовательно, модель нуждается в доработке.

Проверка поддержки целостности данных

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

 возможность для атрибутов иметь пустые значения;

 ограничения для доменов атрибутов;

 категорная целостность;

 ссылочная целостность;

 бизнес-правила в данной предметной области.