Этап 3.4. Создание окончательного варианта диаграммы „сущность-связь" Цель Создание окончательного варианта диаграммы "сущность-связь", ото­бражающей глобальную логическую модель данных предприятия.

Завершив все проверки созданной глобальной логической модели, можно присту­пить к подготовке окончательного варианта ER-диаграммы. Эта диаграмма должна представлять глобальную логическую модель данных той части предприятия, кото­рая моделируется в данном приложении. Описывающая эту модель документация (включая схему отношений и словарь данных) должна быть обновлена и подготовле­на в полном объеме.

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

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

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

Резюме

• Методология проектирования баз данных предусматривает три основные фазы разработки: концептуальное, логическое и физическое проектирование.

• Логическое проектирование базы данных представляет собой процесс конст­руирования модели информационной структуры предприятия, выполняемый в Соответствии с требованиями выбранной схемы, организации информации (например, реляционной). Однако создаваемая логическая модель не зависит от особенностей конкретных СУБД и других физических условий реализации.

• Согласно предлагаемой методологии основными этапами логического проекти­рования баз данных реляционного типа являются: создание и проверка ло­кальных логических моделей данных для представлений отдельных пользова­телей (этап 2); построение и проверка глобальной логической модели данных предприятия (этап 3).

• Действия, необходимые для преобразования концептуальной модели данных в логическую модель данных, включают: удаление связей типа M:N, удаление сложных связей, удаление рекурсивных связей, удаление связей с атрибутами, удаление множественных атрибутов, перепроверка связей типа 1:1 и удаление избыточных связей.

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

• Существует два подхода к проверке логической модели на возможность выпол­нения всех требуемых транзакций.

  1. Исходя из описания каждой транзакций убедиться, что логическая модель позволяет получить всю информацию (сущности, связи и их атрибуты), не­обходимую для выполнения любой из них.

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

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

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

• Существует несколько стратегий обработки попыток удаления строки роди­тельского отношения, на которую ссылаются одна или несколько строк дочер­него отношения: NO ACTION, CASCADE, SET NULL, SET DEFAULT и NO CHECK.

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

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

Вопросы

8.1. Назовите три основные фазы процесса разработки баз данных и опишите на­значение логического проектирования.

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

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

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

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

8.6. • Поясните назначение ограничений целостности и назовите пять основных ти­пов подобных ограничений.

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

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

25