Методические указания по выполнению лабораторных занятий
жүктеу/скачать 3,94 Mb.
|
Технология проектирования программных систем
- Бұл бет үшін навигация:
- 7.3. Пример построения концептуальной модели 7.4. Логическое проектирование с использованием методологии IDEF1X 7.5. Пример построения логической модели
- 7.6. Физическое проектирование с использованием методологии IDEF1X 7.7. Пример построения физической модели 7.1. Основы проектирования баз данных
- 7.2. Концептуальное проектирование с использованием методологии IDEF1X
| Лекция № 7. Моделирование бизнес-процессов
7.1. Основы проектирования баз данных 7.2. Концептуальное проектирование с использованием методологии IDEF1X 7.3. Пример построения концептуальной модели 7.4. Логическое проектирование с использованием методологии IDEF1X 7.5. Пример построения логической модели 7.6. Физическое проектирование с использованием методологии IDEF1X 7.7. Пример построения физической модели 7.1. Основы проектирования баз данных Разработанная функциональная модель системы отвечает на вопросы «Что должна делать система?» и «За счет каких действий может быть достигнут требуемый результат?». Эта модель также позволяет концептуально определить наборы данных, используемых в системе. В то же время она не отвечает на вопрос «Каким образом организованы данные в системе?». Для ответа на него необходимо построить информационную модель (запроектировать БД). Традиционно процедуру проектирования базы данных разбивают на три этапа, каждый из которых завершается созданием соответствующей информационной модели [1, 20, 21]. Этап 1-й. Концептуальное проектирование – создание представления (схемы, модели) БД, включающего определение важнейших сущностей (таблиц) и связей между ними, но не зависящего от модели БД (иерархической, сетевой, реляционной и т. д.) и физической реализации (целевой СУБД). Этап 2-й. Логическое проектирование – развитие концептуального представления БД с учетом принимаемой модели (иерархической, сетевой, реляционной и т.д.). Этап 3-й. Физическое проектирование – развитие логической модели БД с учетом выбранной целевой СУБД. Концептуальное и логическое проектирование вместе называют также инфологическим или семантическим проектированием. В настоящее время для проектирования БД активно используются CASE-средства, в основном ориентированные на использование ERD (Entity – Relationship Diagrams, диаграммы «сущность–связь»). С их помощью определяются важные для предметной области объекты (сущности), отношения друг с другом (связи) и их свойства (атрибуты). Следует отметить, что средства проектирования ERD в основном ориентированы на реляционные базы данных (РБД), и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы проектирования. ERD были впервые предложены П. Ченом в 1976 г. Основные элементы ERD перечислены ниже [1, 18–21]. Сущность (таблица, в РБД – отношение) – реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению. Если выражаться точнее, то это не объект, а набор объектов (класс) с одинаковыми свойствами. Примеры сущностей: работник, деталь, ведомость, результаты сдачи экзамена и т. д. Экземпляр сущности (запись, строка, в РБД – кортеж) – уникально идентифицируемый объект. Связь – некоторая ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Примерами связей могут являться родственные отношения «отец–сын», производственные – «начальник-подчиненный» или произвольные – «иметь в собственности», «обладать свойством». Атрибут (столбец, поле) – свойство сущности или связи. Большинство современных CASE-средств моделирования данных, как правило, поддерживает несколько графических нотаций построения информационных моделей. В частности система ERwin фирмы Computer Associates поддерживает две нотации: IDEF1X и IE (англ. Information Engineering – информационное проектирование). Данные нотации являются взаимно-однозначными, т. е. переход от одной нотации к другой и обратно выполняется без потери качества модели. Отличие между ними заключается лишь в форме отображения элементов модели. При использовании любого CASE-средства вначале строится логическая модель БД в виде диаграммы с указанием сущностей и связей между ними. Логической моделью называется универсальное представление структуры данных, независимое от конечной реализации базы данных и аппаратной платформы. На основании полученной логической модели переходят к физической модели данных. Физическая модель представляет собой диаграмму, содержащую всю необходимую информацию для генерации БД для конкретной СУБД или даже конкретной версии СУБД. Если в логической модели не имеет значения, какие идентификаторы носят таблицы и атрибуты, тип данных атрибутов и т. д., то в физической модели должно быть полное описание БД в соответствии с принятым в ней синтаксисом, с указанием типов атрибутов, триггеров, хранимых процедур и т. д. По одной и той же логической модели можно создать несколько физических. Например, ERwin 4.0 позволяет на основании логической модели сформировать физические более, чем для 20 популярных СУБД (ORACLE, Informix, DB2, MS SQL Server, Access, Foxpro, Paradox и т. д.). На основании физической модели можно сгенерировать либо саму БД или DDL-скрипт1, который, в свою очередь, может быть использован для генерации БД. Перечисленный выше порядок действий называется прямое проектирование БД (Forward Engineering DB). CASE-средства позволяют выполнять также обратное проектирование БД (Reverse Engineering DB), т.е. на основании системного каталога БД или DDL-скрипта построить физическую и, далее, логическую модель данных. Кроме режимов прямого и обратного проектирования, CASE-средства обычно поддерживают синхронизацию между моделью и системным каталогом БД, т. е. при изменении модели они могут автоматически внести все необходимые изменения в существующую БД и наоборот. Развитые CASE-средства обладают также встроенной подсистемой поиска и исправления ошибок в модели. Особенно полезна эта функция при проектировании больших БД, содержащих десятки или сотни таблиц, а также при обратном проектировании. Следует отметить, что современные СУБД обладают своими встроенными средствами визуального моделирования данных. Некоторые из них даже поддерживают классические нотации ERD. Недостатками такого моделирования является построение только физической модели данных и невозможность быстрого перехода на другую СУБД, если такое решение принято. Достоинством этого подхода является более полное использование потенциала СУБД, ведь разработчики СУБД лучше других знают ее особенности и возможности. Далее рассматривается процедура прямого проектирования с использованием методологии IDEF1X. Методология IDEF1 была разработана Т. Рэмеем. В настоящее время на основе IDEF1 создана ее новая версия – методология IDEF1X, которая в 1981 г. принята ICAM в качестве федерального стандарта США. 1Data Definition Language – язык определения данных, подмножество языка SQL. 7.2. Концептуальное проектирование с использованием методологии IDEF1X жүктеу/скачать 3,94 Mb. Достарыңызбен бөлісу:
|