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