
- •Московский технический университет связи и информатики
- •1.2. Общая задача практикума
- •1.3. Индивидуальные задания на выполнение практикума
- •1.4. Этапы выполнения практикума
- •Работа 1 Описание существующей технологии
- •Работа 2
- •2.2. Варианты заданий на курсовой проект
- •3. Методические указания по практикуму и курсовому проектированию
- •3.1. Общие положения
- •3.2. Методика проектирования арм
- •3.2.1. Организационный аспект
- •3.2.2. Разработка технического задания
- •Выходной материальный поток
- •3.2.3. Техническое проектирование
- •3.2.3.1. Общие сведения о реляционной модели данных
- •3.2.3.2. Разработка диаграммы «сущность-связь». Концептуальное проектирование
- •Восходящая методология создания er-модели
- •Нисходящая методология создания er-модели
- •Моделирование проектных представлений
- •Шаг 1. Идентификация локальных представлений
- •Шаг 2. Формулирование сущностей
- •Шаг 3. Выбор первичного ключа для каждой сущности
- •Шаг 4. Спецификация связей
- •Шаг 5. Добавление описательных атрибутов к сущностям
- •Объединение представлений
- •3.2.3.3. Разработка диаграммы «сущность-связь». Физическое проектирование.
- •3.2.4. Рабочее проектирование
- •Организация диалога пользователя с базой данных
- •Рекомендуемая литература
- •Основная:
- •Дополнительная:
Объединение представлений
Процесс объединения представлений заключается в интеграции различных представлений, полученных на предыдущей стадии, в единое для всей организации концептуальное представление информации и требований обработки данных. Концептуальное представление отображается высокоуровневой диаграммой в виде информационной структуры. Интегрированное представление и диаграмма информационной структуры составляют основу подхода к управлению базами данных. Поэтому на практике разработка концептуального представления является существенной, если не самой важной частью процесса проектирования.
Основная цель объединения представлений заключается в идентификации и выделении общих аспектов различных представлений, а также в обнаружении и разрешении их основных противоречий. Этот процесс включает анализ и принятие решений на нескольких уровнях:
Несогласованность наименований. Идентификация синонимов и омонимов среди элементов данных.
Несогласованность идентификации. Различная идентификация одних и тех же типов сущностей (например, служащие могут однозначно идентифицироваться номером страхового полиса в одном приложении и номером служащего — в другом).
Несогласованность агрегации. Ограничение различных групп элементов на структурном уровне или операций над значениями элементов на уровне экземпляров (например, означает ли «Суммарные закупки» суммарные для организации, отрасли, страны и т.д.).
Дополняющие подмножества. Распознавание взаимодополняющих друг друга подмножеств данных, таких, как «служащие, работающие неполный рабочий день», «служащие, работающие полный рабочий день» и «уволенные служащие».
Противоречивость требований обновления. Обнаружение несогласованных правил добавления/исключения среди различных представлений пользователей.
Противоречивость ограничений целостности. Идентификация различий в правилах поддержания целостности данных. Например, каждый новый проект создает новый экземпляр сущности «Служащий», вызывая тем самым дублирование.
Желательно создать такую информационную структуру, которая вобрала бы в себя представления пользователей и руководства относительно производственной и коммерческой деятельности, а также ограничений политики организации.
Основной результат процесса объединения представлений — глобальная информационная структура. Насколько это возможно, она является интеграцией обобщенного, прикладного, информационного представлений и представления событий.
На рис. 3.2.3.3 показан пример концептуальной ER-диаграммы, не учитывающей особенностей конкретной СУБД, с именами сущностей и их атрибутов на естественном языке.
Рис.
3.2.3.3.
Общим требованием для разработки ER-диаграмм в практикуме и дипломном проектировании является использование методологий и стандартов IDEF1Х.
3.2.3.3. Разработка диаграммы «сущность-связь». Физическое проектирование.
После получения концептуальной диаграммы целесообразно преобразовать ее в физическую ER-диаграмму.Это означает трансформироватьмодель в СУБД-зависимое представление,которое будет учитывать такие особенности СУБД, как допустимые типы и наименования9, ограничения целостности и т.п.
Сущности, определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц. В этом варианте ER-диаграммы могут появиться новые атрибуты, которых не было в концептуальной модели — ключевые атрибуты родительских таблиц, мигрировавшие в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.
В процессе физического проектирования продолжается анализ требований с целью выявления семантики данных, идентификации источников их выборки или обновления, а также конкретных данных, подлежащих выборке или обновлению. Если представляется возможным, то полезно представить себе работу каждого будущего приложения, такого, как формирование отчета, специальный запрос или программа обновления, и локализовать для него соответствующее подмножество исходной информационной структуры (фрагмент диаграммы).
После того как будет проанализировано каждое приложение, исходная концептуальная ER-диаграмма может подвергнуться существенным изменениям. В некоторых случаях может возникнуть необходимость определения новых сущностей и связей. Таким образом, пересмотренная структура может существенно отличаться от исходной.
Отметим, что в реальном проектировании этот этап включает в себя решение значительно более широкого круга вопросов, например, таких как оценка производительности будущей системы.
Перечень действий, составляющий стадию технического проектирования базы данных, выглядит примерно следующим образом:
1. Определить сущности и перечни их атрибутов, для каждого объекта выделить первичные ключи и провести нормализацию.
2. Установить все структурные и иерархические связи между сущностями, обеспечивающие обработку всех запросов пользователей.
3. Начертить ER-диаграмму проекта со всеми объектами и связями.
4. Выработать технологию обслуживания базы данных, т. е. определить порядок сбора, хранения данных в базе данных, частоту и форматы ввода/вывода данных, правила работы всех групп пользователей. Проект должен обеспечивать простоту и удобство будущей эксплуатации банка данных, защиту данных от некорректных обновлений пользователями и от разрушений при сбоях компьютера.
5. Проверить корректность проекта. Проект должен адекватно, на требуемом уровне детальности, отображать предметную область. При этом должны быть выявлены и ликвидированы противоречивые и избыточные данные.