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

UptoLike

ВУЗ: 

ТГТУ | Тамбов

Составители: 

Рубрика: 

− первичные ключи;
− альтернативные ключи;
− ограничения целостности.
Концептуальная модель данных дополняется документацией, создаваемой в процессе разработки
этой модели, включая словарь данных. Подробные сведения о сопроводительной документации, кото-
рая может быть подготовлена на различных этапах, приведены при описании этих этапов. На первом
этапе разработки должно быть выполнено следующее.
1. Определение типов сущностей.
2. Определение типов связей.
3. Определение атрибутов и связывание их с типами сущностей и связей.
4. Определение доменов атрибутов.
5. Определение атрибутов, являющихся потенциальными и первичными ключами.
6. Обоснование необходимости использования понятий расширенного моделирования (необяза-
тельный этап).
7. Проверка модели на отсутствие избыточности.
8. Проверка соответствия локальной концептуальной модели конкретным пользовательским тран-
закциям.
9. Обсуждение локальных концептуальных моделей данных с конечными пользователями.
Этап 1.1.
Определение типов сущностей.
Цель.
Определение основных типов сущностей, которые требуются для конкретного представления.
Первый этап создания локальной концептуальной модели данных состоит в определении основных
объектов, которые могут интересовать пользователя. Эти объекты являются типами сущностей, входя-
щих в модель. Один из методов идентификации сущностей состоит в изучении спецификаций по вы-
полнению конкретных функций пользователя на данном предприятии. Из этих спецификаций следует
извлечь все используемые в них существительные или сочетания существительного и прилагательного.
Затем среди них выбираются самые значимые объекты или важные концепции и исключаются все су-
ществительные, которые просто определяют другие объекты.
Альтернативный способ идентификации сущностей состоит в поиске объектов, которые существу-
ют независимо от других. В этой работе существенную помощь могут оказать пользователи создаваемо-
го приложения. В некоторых случаях выделение сущностей бывает затруднено из-за неудовлетвори-
тельного способа их представления в спецификациях. Пользователи, излагая свои мысли, часто исполь-
зуют не однозначные определения, а примеры или аналогии.
Процесс проектирования ещё больше усложняется в связи с тем, что пользователи часто употреб-
ляют синонимы или омонимы. Синонимами называются слова, сходные по смыслу, но различные по
звучанию и написанию, например «отделение» и «филиал». Омонимы – это слова, одинаковые по напи-
санию и звучанию, но имеющие различные смысловые значения, причём реальное значение в каждом
конкретном случае можно установить только по контексту. Так, слово «программа» может обозначать
курс обучения, предстоящую серию последовательных событий, план будущей работы и даже расписа-
ние телепередач.
Далеко не всегда очевидно то, чем является определённый объект – сущностью, связью или атрибу-
том. Однако серия итеративных процедур анализа всего комплекса спецификаций проекта, безусловно,
позволит определить весь набор сущностей, необходимых для удовлетворения требований к системе.
Документирование типов сущностей.
После выделения каждой сущности ей следует присвоить
определённое осмысленное имя, которое обязательно должно быть понятно пользователям. Выбранное
имя и описание сущности помещается в словарь данных. Если это возможно, следует установить и вне-
сти в документацию данные об ожидаемом количестве экземпляров каждой сущности. Если сущность
известна пользователям под разными именами, все дополнительные имена рекомендуется определить
как синонимы или псевдонимы и также занести в словарь данных.
Этап 1.2.
Определение типов связей.
Цель.
Определение важнейших типов связей, существующих между сущностями, выделенными на
предыдущем этапе.

Страницы