
- •Введение
- •1 Описание предметной области и выявление требований, предъявляемых к разрабатываемой информационной системе
- •1.1 Описание предметной области
- •1.2 Выявление требований, предъявляемых к информационной системе
- •1.3 Описание инструментальных средств разработки
- •2 Анализ предметной области. Разработка и описание функциональной модели
- •2.1 Построение контекстной диаграммы
- •2.2 Декомпозиция моделируемой системы
- •3 Создание локальных концептуальных моделей
- •3.1 Выявление и определение сущностей на основе анализа dfd-диаграммы
- •3.2 Определение связей между сущностями
- •3.3 Определение атрибутов сущностей и первичных ключей
- •3.4 Создание диаграммы «сущность-связь»
- •4 Построение и проверка локальных логических моделей данных
- •5 Создание и проверка глобальной логической модели данных
- •6 Разработка физической модели данных.Прямое проектирование
- •6.1 Создание физической модели данных
- •6.2 Описание структуры базы данных
- •6.2.1 Описание доменов
- •6.3 Прямое проектирование
- •7 Проектирование приложения
- •8 Результаты тестирования
- •Поле «Стоимость работы» оставили пустым для обеих строк. Обновим таблицу. Получим следующий результат:
- •9 Управление проектом
- •Заключение
- •Список используемых источников
- •Лист регистрации изменений
3 Создание локальных концептуальных моделей
Известны две точки зрения на информационную модель и, соответственно, два уровня представления модели:
Логический уровень (точка зрения пользователя). Это абстрактный взгляд на данные. На нем используются данные в таком виде, в каком они известны в реальном мире. Объектам модели (сущностям и атрибутам) даются имена, понятные широкому кругу специалистов. Логическая модель данных является универсальной и никак не связана с особенностями реализации конкретной системы управления базой данных (СУБД).
Физический уровень – определяет представление информации в базе данных (БД). На физическом уровне объекты модели должны обозначаться так, как того требуют ограничения выбранной СУБД. Если в логической модели не имеет принципиального значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о таблицах, колонках, индексах, процедурах и т.п. Такую модель создают специалисты по СУБД.
Основными компонентами диаграммы в ERwin являются сущности, атрибуты и связи. Каждая сущность является множеством подобных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта.
Разработка информационной модели начинается с создания логической модели. После этого проектировщик выбирает необходимую СУБД и с помощью специальных средств создает соответствующую физическую модель. На основе физической модели генерируется специальный каталог СУБД или соответствующий SQL-скрипт.
Концептуальное проектирование – процедура конструирования информационной модели предприятия, не зависящей от каких-либо условий реализации. Фаза концептуального проектирования начинается с создания концептуальной модели данных, полностью независимой от типа СУБД, приложения, языка программирования, типа компьютера и т.п.
3.1 Выявление и определение сущностей на основе анализа dfd-диаграммы
Сущность – представляет собой множество реальных или абстрактных предметов, обладающих общими атрибутами или характеристиками.
На DFD-диаграмме информация, которую необходимо хранить в БД, изображается с помощью «хранилищ». Таким образом, выявляя на диаграммах потоков данных хранилища информации, мы определяем перечень сущностей, которые в дальнейшем потребуется создать при построении локальных концептуальных и логических моделей данных.
Рассмотрим DFD-диаграммы блоков. Из хранилищ данных выделим сущности и дадим им имена. Проанализируем DFD – диаграмму блока «Принять заказ на строительство», показанную на рисунке 3. Данная DFD – диаграмма содержит следующие хранилища: «Список клиентов», «Список мест строительства», «Список сотрудников строительной фирмы», «Список стоимостей строительства», «Список дат оформления договоров», «Список сроков сдачи строительства», «Список проектов зданий» и «Список заказов». В локальной концептуальной модели на логическом уровне должны быть представлены сущности, соответствующие этим хранилищам. Назовем их соответственно «КЛИЕНТ», «СОТРУДНИК», «ЗАКАЗ_НА_СТРОИТЕЛЬСТВО», «АДРЕС». Создавать сущности для хранилищ «Список стоимостей строительства», «Список сроков сдачи строительства», «Список дат оформления договоров» нет смысла. Лучше сделать эти хранилища атрибутами сущности «ЗАКАЗ_НА_СТРОИТЕЛЬСТВО». Аналогично, анализируем остальные три DFD – диаграммы.
На диаграмме «Провести подготовительные работы», представленную на рисунке 4, имеются хранилища данных: «Список работ», «Список сотрудников строительной фирмы», «Список документов, необходимых для получения разрешения на строительство», «Список требований от экологов», «Список заказов, готовых к строительству», «Список купленных мест, готовых к строительству». Выделяем четыре сущности: «СОТРУДНИК», «АДРЕС», «ЗАКАЗ_НА_ СТРОИТЕЛЬСТВО», «РАБОТА». Хранилище «Список заказов, готовых к строительству» будет атрибутом сущности «ЗАКАЗ_НА_СТРОИТЕЛЬСТВО». Хранилища данных «Список документов, необходимых для получения разрешения на строительство» и «Список требований от экологов» в электронной базе данных храниться не будут, так как их хранение в базе нецелесообразно.
На диаграмме «Выполнить строительные работы», представленную на рисунке 5, имеются хранилища данных: «Список работ», «Список сотрудников строительной фирмы», «Список строительных материалов», «Список количества материалов, расходуемых на работу», «Список коттеджей, готовых к проверке». Исходя их этих хранилищ, выделяем сущности: «СОТРУДНИК», «МАТЕРИАЛ», «ЗАКАЗ_НА_ СТРОИТЕЛЬСТВО», «РАБОТА». Хранилище «Список количества материалов, расходуемых на работу» будет атрибутом сущности «РАБОТА».
На диаграмме «Пройти обследование на соответствие стандарту качества», представленную на рисунке 6, имеются следующие хранилища данных: «Список работ», «Список сотрудников строительной фирмы», «Список сотрудников жилищной комиссии» и «Список построенных коттеджей». Выделяем четыре сущности: «СОТРУДНИК», «ЗАКАЗ_НА_СТРОИТЕЛЬСТВО» и «РАБОТА». Для хранилища данных «Список сотрудников жилищной комиссии» сущность создаваться не будет, так как его хранение в электронной базе строительной фирмы нецелесообразно.