Логическое проектирование базы данных

Создание и проверка локальной логической модели данных для отдельных пользовательских представлений

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

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

Исключение особенностей, несовместимых с реляционной моделью (необязательный этап)

1. Удаление двухсторонних связей "многие ко многим" (*:*)

2. Если в концептуальной модели данных присутствует связь "многие ко многим" (*:*), может быть выполнена декомпозиция этой связи для выявления промежуточной сущности. Связь *:* заменяется двумя связями "один ко многим" (1:*), в которых участвует вновь выявленная сущность.

3. Удаление рекурсивных связей "многие ко многим" (*:*)

4. Рекурсивная связь представляет собой особый тип связи, в которой определенный тип сущности соединен связью сам с собой. Ниже перечислены три типа рекурсивных связей:

   • Рекурсивная связь "один к одному" (1:1);

   • Рекурсивная связь "один ко многим" (1:*);

   • Рекурсивная связь "многие ко многим" (*:*).

5. Первые две связи могут быть преобразованы в одно отношение реляционной модели без какой-либо структуризации, но если рекурсивная связь 1:* допускает необязательное участие со стороны связи "многие", то для уменьшения количества пустых значений, хранимых в базе данных, целесообразнее создать второе отношение. Способы преобразования рекурсивных связей 1:1 и 1:* рассматриваются на этапе 2.2. А если в концептуальной модели данных присутствует рекурсивная связь *:*, то следует выполнить декомпозицию этой связи для выявления промежуточной сущности.

6. Удаление сложных связей

7. Сложной называется связь, в которой участвуют три или более типов сущностей. Если в концептуальной модели данных присутствует сложная связь, можно выполнить ее декомпозицию для выявления промежуточной сущности. А сложная связь заменяется необходимым количеством (двухсторонних) связей 1:* со вновь выявленной сущностью. Например, трехсторонняя связь Registers в представлении Branch соответствует той ситуации, когда сотрудник компании регистрирует нового клиента в отделении (рис. а). Эту связь можно упростить, введя новую сущность и определив (двухсторонние) связи между каждой из первоначальных сущностей и новой сущностью.

1. Пример преобразования связи: а) сложная связь Registers; б) декомпозиция сложной связи на три двухсторонние связи ('Registers, Processes и Agrees) и новую (слабую) сущность Registration.

2. В этом примере в результате декомпозиции связи Registers выявлена новая (слабая) сущность Registration (Регистрация). Новая сущность связывается с первоначальными сущностями с помощью трех новых двухсторонних связей: Branch Registers Registration (В отделении проводится регистрация), Staff Processes Registration (Сотрудник компании проводит регистрацию) и Client Agrees Registration (Клиент соглашается на регистрацию), как показано на рис. б.

3. Удаление многозначных атрибутов

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

Определение набора отношений исходя из структуры локальной логической модели данных

Связь между двумя сущностями отображается с использованием механизма "первичный ключ/внешний ключ". При определении того, в каком отношении должен находиться атрибут (атрибуты) внешнего ключа, необходимо вначале выяснить, какая из сущностей, участвующих в связи, является родительской, а какая дочерней. Родительской называется сущность, которая передает копию своего первичного ключа в отношение, представляющее дочернюю сущность, для использования в качестве внешнего ключа.

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

1. Сильные типы сущностей

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

3. Слабые типы сущностей

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

5. Двухсторонние связи типа "один ко многим" (1:*)

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

7. Двухсторонние связи типа "один к одному" (1:1)

   • Обязательное участие обеих сторон в связи типа 1:1

8. В этом случае необходимо объединить в одно отношение сущности, участвующие в связи, и выбрать один из первичных ключей первоначальных сущностей для использования в качестве первичного ключа нового отношения, а другой первичный ключ (если он существует) - для использования в качестве альтернативного ключа. В том случае, если связь 1:1 с обязательным участием обеих сторон имеет один или несколько атрибутов, эти атрибуты должны быть также включены в создаваемое отношение. Следует отметить, что две сущности могут быть объединены в одно отношение только в том случае, если между ними нет других прямых связей, исключающих возможность выполнения такой операции объединения (например, связи 1:*).

9. Задача определения родительской и дочерней сущностей для связи 1:1 с использованием ограничения степени участия решается просто. Сущность, которая характеризуется необязательным участием в связи, обозначается как родительская, а сущность, которая должна обязательно участвовать в связи, определяется как дочерняя.

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

    • Необязательное участие обеих сторон в связи типа 1:1

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

12. Рекурсивные связи "один к одному" (1:1)

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

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

15. Связи типа суперкласс/подкласс

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

17. Двухсторонние связи "многие ко многим" (*:*)

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

19. Сложные типы связей

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

21. Все внешние ключи, соответствующие стороне связи "многие" (например, 1..*, 0..*), как правило, образуют также первичный ключ этого нового отношения, возможно, в сочетании с некоторыми другими атрибутами связи.

22. Многозначные атрибуты

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

24. По завершении этапа 2.2 необходимо формально описать на языке DBDL состав отношений, полученных на основе логической модели данных.

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

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

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

• приведение к первой нормальной форме (1НФ), позволяющее удалить из отношений повторяющиеся группы атрибутов;

• приведение ко второй нормальной форме (2НФ), позволяющее устранить частичную зависимость атрибутов от первичного ключа;

• приведение к третьей нормальной форме (ЗНФ), позволяющее устранить транзитивную зависимость атрибутов от первичного ключа;

• приведение к нормальной форме Бойса-Кодда (НФБК), позволяющее удалить из функциональных зависимостей оставшиеся аномалии.

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

Проверка соответствия отношений требованиям пользовательских транзакций

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

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

Ограничения целостности данных вводятся с целью предотвратить появление в базе противоречивых данных. Ниже рассматриваются пять типов ограничений целостности данных.

Обязательные данные

Некоторые атрибуты всегда должны содержать одно из допустимых значений. Другими словами, эти атрибуты не могут иметь пустого значения. Эти ограничения должны фиксироваться при занесении сведений об атрибуте в словарь данных.

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

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

Целостность сущностей

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

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

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

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

Рассмотрим следующие случаи, которые могут возникнуть при обработке данных, моделируемых связью типа 1:*:

• Вставка новой строки в дочернее отношение

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

• Удаление строки из дочернего отношения

При удалении строки из дочернего отношения никаких нарушений ссылочной целостности не происходит.

• Обновление внешнего ключа в строке дочернего отношения

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

• Вставка строки в родительское отношение

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

• Удаление строки из родительского отношения

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

• NO ACTION. Удаление строки из родительского отношения запрещается, если в дочернем отношении существует хотя бы одна ссылающаяся на нее строка.

• CASCADE.Удаление строки родительского отношения автоматически распространяется на все дочерние отношения.

• SET NULL.При удалении строки из родительского отношения во всех ссылающихся на нее строках дочернего отношения в атрибут внешнего ключа автоматически записывается пустое значение.

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

• NO CHECK. При удалении строки из родительского отношения никаких действий по поддержанию ссылочной целостности данных не предпринимается.

Обновление первичного ключа в строке родительского отношения

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

Ограничения предметной области

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

Обсуждение разработанных локальных логических моделей данных с конечными пользователями

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

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

Создание и проверка глобальной логической модели данных

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

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

Слияние локальных логических моделей данных в единую глобальную модель данных

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

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

1. Анализ имен и содержимого сущностей/отношений и их потенциальных ключей

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

   • если две или несколько сущностей/отношений имеют одно и то же имя, но на самом деле отличаются друг от друга (проблема омонимов);

   • если две или несколько сущностей/отношений являются одинаковыми, но имеют разные имена (проблема синонимов).

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

4. Анализ имен и содержимого связей/внешних ключей

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

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

7. Слияние сущностей/отношений, соответствующих локальным моделям данных

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

   • Объединение сущностей/отношений с одинаковыми именами и первичными ключам

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

   • Объединение сущностей/отношений с одинаковыми именами, но разными первичными ключами

   • В некоторых ситуациях могут обнаружиться две сущности/отношения с одинаковыми именами и аналогичными потенциальными ключами, но с разными первичными ключами. В таких случаях сущности/отношения также должны быть объединены, как описано выше. Но необходимо также выбрать для использования в качестве первичного ключа только один ключ, а другой первичный ключ преобразовать в альтернативный. Например, на рисунке перечислены атрибуты, принадлежащие двум отношениям BusinessOwner, которые определены в двух представлениях. Первичным ключом отношения BusinessOwner в представлении Branch является bName, а первичным ключом в отношении BusinessOwner представления Staff - ownerNo.

1. Но альтернативным ключом отношения BusinessOwner в представлении Staff служит bName. Итак, в этих двух отношениях применяются разные первичные ключи, а первичный ключ отношения BusinessOwner в представлении Branch является альтернативным ключом отношения BusinessOwner в представлении Staff. Поэтому можно объединить эти два отношения, как показано на рисунке, и включить в полученное отношение атрибут bName в качестве альтернативного ключа.

2. Объединение сущностей/отношений с разными именами с использованием одинаковых или разных первичных ключей

3. В некоторых случаях могут обнаружиться сущности/отношения, имеющие разные имена, но, по-видимому, выполняющие аналогичную роль. Подобные сущности/отношения могут быть выявлены следующим образом:

   • по их именам, которые указывают на аналогичное назначение;

   • по их содержанию и особенно по их первичному ключу;

   • на основании того, что они принимают участие в определенных связях.

4. Включение (без слияния) сущностей/отношений, характерных только для отдельных локальных моделей данных

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

6. Слияние связей/внешних ключей из отдельных локальных моделей данных

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

   • объединение связей/внешних ключей с одинаковыми именами и назначениями;

   • объединение связей/внешних ключей с разными именами, но с одинаковыми назначениями.

8. Включение (без слияния) связей/внешних ключей, характерных только для отдельных локальных моделей данных

9. Итак, в результате выполнения предыдущей задачи должны быть выявлены одинаковые связи/внешние ключи. Все остальные связи/внешние ключи переносятся в глобальную модель без изменения.

10. Проверка того, нет ли пропущенных сущностей/отношений и связей/внешних ключей

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

12. Проверка внешних ключей

13. На этом этапе могут быть объединены сущности/отношения и связи/внешние ключи, изменены первичные ключи и выявлены новые связи. Следует проверить, что внешние ключи в дочерних отношениях все еще остаются правильными, и внести все необходимые изменения.

14. Проверка ограничений целостности

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

16. Формирование глобальной ER-диаграммы/схемы отношений

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

18. Обновление документации

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

Проверка глобальной логической модели данных

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

Проверка возможностей расширения модели в будущем

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

Обсуждение глобальной логической модели данных с пользователями

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