3.9.6. Нормализация лмд.

В нормализованной ЛМД объекты рассматриваются как отношения, которые должны быть приведены к виду не ниже третьей нормальной формы (3NF). Квалифицированный аналитик получает модель такого вида инстинктивно, путем неформального применения правил реляционного анализа данных по мере развития модели от этапа 140 к этапу 320. Ниже рассматриваются возможности применения правил реляционного анализа при логическом моделировании данных.

Первая нормальная форма.

Атрибут должен иметь только одно значение, соответствующее одному экземпляру объекта в настоящее время. Допускается присутствие повторяющихся групп. Аналитик должен создать новый объект, имеющий связь степени 1:m с исходным объектом для того, чтобы сохранить эти группы данных.

Имя атрибута должно быть сингулярным. Повторяемость имен атрибутов в большинстве случаев свидетельствует о наличии в модели ошибочных объектов.

Вторая нормальная форма.

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

Третья нормальная форма.

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

3.9.7. Проверка правильности лмд.

Каждая логическая модель данных должна полностью соответствовать своей модели потоков данных.

Проверка соответствия процессов и объектов.

Эта задача решается на этапах 140, 150 и 320. Для каждого объекта из ЛМД в соответствующей модели потоков данных должен существовать, по крайней мере, один процесс, который способен откликаться на события, создающие и удаляющие объект. При необходимости может быть заполнена "Матрица Процесс/Объект", в которой используются такие типы доступа к данным как создание, редактирование и удаление. Модель потоков данных, если это необходимо, должна быть преобразована.

Сравнение объектов и хранилищ данных.

Эта задача решается на этапе 150 и при завершении этапов 310 и 320, выполнение которых осуществляется параллельно. Полностью эта задача рассмотрена в предыдущей главе.

Каждый объект должен иметь логическое объяснение в одном и только одном хранилище из всего" множества хранилищ данных модели потоков данных, так как он является неделимым между двумя хранилищами. Если это условие не соблюдается, то обе модели и ЛМД и МПД необходимо исправить. Связи между хранилищами данных и объектами отражены в "Таблице перекрестных ссылок Логическое хранилище данных/Объект". Исключение из этого правила составляет случай декомпозиции хранилищ данных, результатом которой являются супер -и субтипы, где супертипам соответствует более одного хранилища данных (см. 2.7.2.2.).

Неформальная проверка путей доступа к данным.

Эта задача решается на шагах 140, 150 и 320, ЛМД должна обеспечивать пути доступа к данным для каждого из описанных элементарных процессов, содержащихся в соответствующей МПД, т.е. поддерживать все процессы преобразования и формирования запросов, которые входят в модель. Проверка того, что требуемые данные могут быть получены, достигается использованием следующих типов операции чтения:

• чтение объекта прямым использованием ключа;

• чтение вспомогательного объекта через главный;

• чтение главного объекта через вспомогательный.

Если требуемые данные не могут быть получены путем использования таких операций, то ЛМД и описания элементарных процессов неправильны. Тогда аналитик обязан найти ошибку и исправить ее. Такие исправления могут повлечь за собой необходимость добавления новых объектов и связей. После устранения всех ошибок все доступные объекты должны иметь полные наборы атрибутов, а все изменения должны быть внесены в ЛМД и формы " Описание элементарного процесса". На этапе 360 используется более высокий уровень формализации путей доступа к данным.

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

Рис. 3.15. Пример структуры связей, содержащей замкнутый цикл