Управление данными. Громов Ю.Ю - 37 стр.

UptoLike

Очень часто подобные атрибуты вообще не отображаются в концептуальной модели данных. Но в
некоторых случаях производный атрибут, применяемый в модели данных, может не отражать измене-
ния значений одного или нескольких атрибутов, на которых он основан, при их удалении или модифи-
кации. В этом случае производный атрибут должен быть явно представлен в модели данных, что позво-
лит предупредить нежелательную потерю информации. Однако, если производный атрибут показан в
модели данных, следует непременно указать, что он является производным. Способ представления про-
изводных атрибутов устанавливается на этапе физического проектирования базы данных. В зависимо-
сти от того, как применяется данный атрибут, новое значение производного атрибута может вычислять-
ся либо при каждом обращении к нему, либо только при изменении значений атрибутов, используемых
для его расчёта. Однако данные вопросы на этапе концептуального проектирования не принимаются во
внимание.
Потенциальные проблемы.
При определении используемых в некотором представлении сущно-
стей, связей и атрибутов очень часто оказывается, что на предыдущих этапах одна или несколько сущ-
ностей, связей и атрибутов были пропущены. В этом случае следует вернуться к уже выполненным эта-
пам и документально оформить вновь обнаруженные сущности, связи и атрибуты, после чего ещё раз
проанализировать связи, в которых они принимают участие.
Поскольку обычно количество атрибутов намного превышает количество сущностей и связей, мо-
жет оказаться полезным сначала подготовить список всех атрибутов, используемых в спецификациях
требований пользователей. По мере связывания очередного атрибута с некоторой сущностью или свя-
зью он вычёркивается из списка. Подобный метод позволяет гарантировать, что каждый из атрибутов
будет связан с сущностью или связью только одного типа. Когда из списка будет вычеркнут последний
атрибут, все идентифицированные в модели атрибуты окажутся связанными с некоторой сущностью
или связью.
Следует помнить, что в определённых случаях создаётся впечатление, что некоторые атрибуты
должны относиться к сущностям или связям нескольких различных типов. Подобная ситуация возника-
ет в следующих случаях.
1. Выявлено несколько сущностей, которые могут быть представлены в виде одной сущности. В по-
добных случаях необходимо решить, следует ли обобщить эти сущности и представить в виде одной
сущности или сохранить их как специализированные сущности. Эта тема рассматривается более подроб-
но при описании этапа 1.6.
2. Обнаружена новая связь между типами сущностей. В таком случае необходимо установить при-
надлежность атрибута только к одной сущности (которая называется родительской) и убедиться в том,
что такая связь была уже выявлена на этапе 1.2. Если эти условия не соблюдаются, то необходимо об-
новить проектную документацию и внести в неё сведения о вновь обнаруженной связи.
Документирование атрибутов
Каждому выявленному атрибуту следует присвоить осмысленное имя, понятное пользователям. О
каждом атрибуте в документацию помещаются следующие сведения:
имя атрибута и его описание;
тип данных и размерность значения;
все псевдонимы, под которыми упоминается атрибут;
информация о том, является ли атрибут составным и, если это так, из каких простых атрибутов
он состоит;
информация о том, является ли атрибут многозначным;
информация о том, является ли данный атрибут производным и, если это так, какой метод ис-
пользуется для вычисления его значения;
значение, принимаемое для атрибута по умолчанию (если таковое имеется).
Этап 1.4.
Определение доменов атрибутов.
Цель.
Определение доменов для всех атрибутов, присутствующих в локальной концептуальной мо-
дели данных.
Задача этого этапа создания локальной концептуальной модели данных состоит в определении до-
менов атрибутов для всех атрибутов, присутствующих в модели. Доменом называется некоторое мно-