Часть 1. Знакомство с интерфейсом ERwin

Практическое занятие №4

«Проектирование базы данных с использованием CASE-средств»

Часть 1. Знакомство с интерфейсом ERwin

Цель работы: дать студентам навык работы с интерфейсом ERwin 4.0.

Общие сведения

Базы данных, как и другие информационные системы (ИС), проходят разные этапы своего жизненного цикла, начиная от замысла системы, предпроектного обследования, включая этапы проектирования, эксплуатации, а далее - модернизации системы.

Создание крупных проектов практически невозможно без использования средств автоматизации проектирования (CASE-систем). Их использование позволяет не только ускорить работы и повысить качество их выполнения, но и дает инструменты для организации коллективного труда группы проектировщиков. Использование инструментальных средств при проектировании баз данных затрагивает разные этапы жизненного цикла АИС. Оно в определенной мере предопределяет процесс обследования и дает инструмент для отображения его результатов.

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

Использование CASE-систем такого типа объединяет не только проектировщиков АИС, но и заказчиков системы, и поэтому отдельные механизмы, а именно нотации, используемые на этапе концептуального моделирования системы, должны грамотно восприниматься всеми ими. Различают прямое проектирование (forward-engineering) - процесс получения структуры базы данных для выбранной целевой СУБД на основе построенной ER- модели, и обратное проектирование (reverse-engineering - реверс-инжиниринг) - когда ER-модель получается на основе существующей базы данных. CASE-средства обычно поддерживают оба эти процесса.

В качестве CASE-средств можно представить ткие продукты как Power Designer, ER/Studio, AllFusion ERwin Data Modeler (ранее эта компонента AllFusion выпускалась в виде отдельного продукта и называлась ERwin) и другие. Многие из этих систем имеют сходную функциональность и даже базируются на одних и тех же стандартах изображения ER-моделей.

В данной практической работе рассматриваются вопросы проектирование баз данных с использованием инструментального средства автоматизации проектирования AllFusion ERwin Data Modeler 4.0. В дальнейшем по тексту данного учебного пособия для краткости будем использовать название ERWin, имея в виду AllFusion ERwin Data Modeler 4.0.

ERwin - CASE-средство проектирования баз данных от фирмы Computer Associates. ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД.

ERwin не привязан к технологии какой-либо конкретной фирмы, поставляющей СУБД или средства разработки. Он поддерживает различные серверы баз данных и настольные СУБД, а также может обращаться к базе данных через интерфейс ODBC. Так, в текущей версии ERwin встроена поддержка 23 СУБД, среди которых: Oracle; Microsoft SQL Server и т.п. Заметим лишь, что речь идет только о реляционных СУБД. ERwin можно использовать совместно с некоторыми популярными средствами разработки клиентских частей приложений: PowerBuilder, Visual Basic, Delphi.

Процесс моделирования в ERwin базируется на методологии проектирования реляционных баз данных IDEF1X.

ERwin имеет два уровня представления модели - логический и физический.

Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Постоянный клиент», «Отдел» или «Фамилия сотрудника». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами (подробнее о сущностях и атрибутах будет рассказано ниже). Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов (см. BPwin). Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.

Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логические и физические позволяет решить несколько важных задач.

Таблица 1.7 – Содержание меню Window

Таблица 1.8 – Содержание меню ModelMart

Таблица 1.9 – Содержание меню Tools

Таблица 1.10 – Содержание меню Help

Ø Интерфейс ERWin включает восемь перемещаемых панелей инструментов, список которых доступен из меню View/Toolbars (рис. 4).

Рис. 4.Список панелей инструментов

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

Содержание элементов панели инструментов

Таблица 1.11 – Стандартная панель инструментов (Standart)

Таблица 1.12 – Инструментарий (палитра инструментов - Toolbox)

Таблица 1.13 – Панель инструментов шрифт и цвет (Font and Color)

Таблица 1.14 – Панель инструментов базы данных (Database)

Подготовительный этап

Запустите визуальную среду проектирования информационных систем ERwin. В ходе лабораторной работы вы должны приобрести навыки настройки инструментальной панели и переключения между различными представлениями модели. Чтобы приступить к работе, вам потребуется открыть учебную модель, но прежде закройте все открытые ранее модели, использовав команду Close из меню File.

Ø В меню File выберите опцию Open. Появится диалоговое окно открытия модели (рисунок 7). Укажите путь и имя модели c:\Program Files\Computer Associates\Erwin 4.0\Sampliesl\Standard\Emovies и нажмите OK.

Рисунок 7 – Диалоговое окно для открытия файла примера

Ø Повторно нажмите ОК, когда появится диалоговое окно с сообщением о том, что этот файл имеет атрибут “read-only” (только для чтения).

Ø В окне редактирования должна открыться модель Emovies.er1. Убедитесь в том, что переключатель типа модели на панели инструментов поставлен в положение Logical (см. таблицу 1.11). Сохраните модель под новым именем (рисунок 8).

Рисунок 8 – Окно сохранения файла примера под новым именем Model_1

Ø Выберите команды главного меню View → Toolbars. Обратите внимание на то, как реагирует на это действие инструментальная панель (должно появиться ниспадающее меню). Убедитесь в том, что некоторые опции в этом меню отмечеы галочками (являются активными). Измените перечень активных опций в рассматриваемом меню, убрав отдельные галочки и посмотрите, как это повлияет на интерфейс среды ERwin. Для того чтобы закрыть ниспадающее меню, кликните в любом месте на инструментальной панели. Потренируйтесь в этих действиях перед продолжением работы.

Ø Потренируйтесь в переключении вида модели Physical и Logical. Переключитесь на физическую модель (выберите опцию Physical списка в инструментальной панели ERwin). Переключитесь на логическую модель (выберите опцию Logical списка в инструментальной панели ERwin). Обратите внимание, как влияют такие переключения на вид модели в окне редактирования. Например, логические названия (имена) заменяются физическими названиями (именами) и браузер независимых атрибутов переключается на браузер независимых столбцов (если браузер невидим, нажмите Ctrl+B.)

Ø Измените нотацию модели, перейдя от нотации IDEF1X к нотации IE. Измените нотацию модели, перейдя от нотации IE к нотации IDEF1X.

Ø Если вы выполнили предыдущие шаги и сделали все правильно, то должны получить диаграмму, совпадающую с контрольной диаграммой (рисунок 9).

Рисунок 9 – Контрольная диаграмма

Если построенная диаграмма отличается от контрольной, то вам необходимо повторить действия (шаги 1- 5).

Ø Закройте инструментальную среду создания модели процессов. Для этого, используя главное меню ERwin, последовательно выполните следующие команды: File→ Exit. Для закрытия ERwin без сохранения результатов моделирования воспользуйтесь опцией Close without saving и нажмите OK (рисунок 10).

Рисунок 10 – Диалоговое окно Close

Содержание отчета

1. Краткие теоретические сведения о назначении и интерфейсе ERwin.

Контрольные вопросы:

1. Что такое ERwin и зачем его используют?

2. Что такое физическая и логическая модель данных?

3. Каковы свойства и общая характеристика системы меню ERwin?

4. Дайте характеристику меню: File, Edit, View, Format, Model, Model Mart,

Tools, Window, Help. Каков порядок настройки IDE PLATINUM ERwin?

5. Каково назначение кнопок стандартной панели инструментов?

6. Каковы функции палитры инструментов?

7. Каковы нотации представления ERwin модели?

Создание шаблона

Ø Загрузите программу Erwin.

Ø В появившемся диалоговом окне установите переключатель Crеаte а New Model.На экране появится диалог Create Model – Select Template,гденеобходимо выбрать уровень моделирования.

Ø Установите переключательLogical/Physicalдля создания модели с логическим и физическим уровнями.

Ø В полях DataBase и Version указывается тип и версия сервера, для которого создается модель. Выберите в списке Access, 2000. Нажмите кнопку ОК.

Внесение в модель сущностей

На данном этапе необходимо внести в модель следующие сущности, выявленные в результате анализа предметной области (поставка товара в соответствии с договорами): покупатель, договор, накладная, товар, склад.

Ø Выберите на панели инструментов (ERwin Toolbox) кнопку Сущность ,щелкнув по ней указателем мыши. Затем щелкните мышкой по тому месту на диаграмме, где необходимо расположить новую сущность. На поле диаграммы появится прямоугольник, изображающий новую сущность, с автоматически сгенерированным именем «Е/1».

Ø Введите с клавиатуры имя сущности «Покупатель» и нажмите Enter.

Ø Точно таким же образом вставьте в диаграмму еще четыре сущности: договор, накладная, товар, склад.

Ø Щелкнув правой кнопкой мыши по сущности и выбрав из контекстного меню пункт Entity Properties, можно вызвать редактор сущностей Entities(рис. 2.4), который позволяет изменять свойства выбранной сущности. Редактор сущностей также можно вызвать через главное меню: Model | Entities.

Рис. 2.4. Редактор сущности

В верхней части окна редактора находится список всех сущностей, имеющихся на диаграмме. С его помощью можно выбрать сущность, свойства которой необходимо посмотреть или изменить. По умолчанию, выбранной является выделенная на диаграмме сущность, по которой щелкнули мышью. Далее имеется поле Name, в котором высвечивается имя сущности. Имя можно редактировать.

Ниже в окне редактора находится ряд закладок:

Definition(определение) – на этой странице вводится определение сущности.

Note, Note2, Note3(примечание) – используются для ввода произвольного текста, связанного с сущностью, например, образцы данных и запросы.

UDP– определяемые пользователем свойства.

Icon(иконка) – для наглядности каждой сущности может быть присвоена иконка, которая выводится рядом с ее названием.

Ø Для каждой сущности введите определение Definition.

Ключевые группы

Сущность	Атрибуты ключевой группы	Имя ключевой группы	Тип ключевой группы
Покупатель	ИНН	ИНН	Альтернативный ключ
Покупатель	НАИМ_ПОК	НАИМ_ПОК	Инверсный вход
Товар	НАИМ_ТОВ	НАИМ_ТОВ	Инверсный вход
Склад	НАИМ_СК	НАИМ_СК	Инверсный вход

Ø Вызовите редактор ключевых групп Key Groups,щелкнув правой кнопкой мыши по сущности Покупатель и выбрав из контекстного меню пункт Key Groups. Редактор ключевых групп также можно вызвать через главное меню: Model | Key Groups.

Редактор ключевых групп содержит элементы управления:

Entity – поле с выпадающим списком, в котором следует выбрать сущность для редактирования.

Окно с перечнем ключевых групп. Каждая группа представлена отдельной строкой, включающей в себя имя (Key Group), тип (Type) и определение (Definition).

Кроме того, диалоговое окно редактора ключевых групп содержит следующие закладки:

r Members (члены). Задаются члены ключевых групп и их порядок следования в группе.

r General (общие установки). Переключатели, позволяющие задавать тип ключевой группы. Для первичного и внешнего ключа эти группы недоступны.

r Definition (определение). Произвольная текстовая информация, относящаяся к выбранной ключевой группе.

r Note (примечание). Примечание к выбранной группе.

r UDP (пользовательские свойства).

Ø Нажмите кнопку New

Ø В окне New Key Group в поле Key Group введите имя ключевой группы – ИНН. В поле Index выводится генерируемое программой Erwin имя индекса. Оставьте его без изменений.

Ø Переключатель Key Group Type задает тип создаваемого ключа. Это может быть альтернативный ключ (Alternate Key) или инверсный вход (Inversion Entry). Выберите Alternate Key и нажмите ОК. Вновь введенный альтернативный ключ появится в перечне ключей.

Ø Перейдите на закладку Members. Новый ключ пока не содержит никаких атрибутов, поэтому правый список Key Group Members (члены ключевой группы) пуст. Выберите в левом списке атрибут ИНН и переместите его в правый список при помощи кнопки со стрелкой (см. рис. 2.7).

Рис. 2.7. Редактор ключевых групп

Ø Таким же образом создайте ключевые группы для инверсных входов, приведенных в табл. 2.2.

Теоретические сведения

Правила ссылочной целостности – это логические конструкции, которые выражают бизнес-правила использования данных. Они определяют, какие действия должна выполнить СУБД при удалении, вставке или изменении строки таблицы (экземпляра сущности). Заданные таким образом действия используются впоследствии при автоматической генерации триггеров, поддерживающих целостность данных.

Существуют следующие виды действий или правил, определяемых в логической модели:

ü RESTRICT – запрет удаления, вставки или изменения экземпляра сущности.

ü CASCADE – при удалении экземпляра родительской сущности удаление всех экземпляров дочерней сущности, ссылающихся на удаляемый родительский экземпляр.

ü SET NULL – при удалении экземпляра родительской сущности атрибутам внешнего ключа всех экземпляров дочерней сущности присваивается значение NULL.

ü SET DEFAULT – то же самое, что и в предыдущем случае, только вместо значения NULL присваивается значение по умолчанию.

ü NONE – никаких действий не предпринимается.

Эти правила задаются на вставку, удаление и изменение экземпляра как родительской, так и дочерней сущности. Таким образом, каждая связь должна обладать набором из шести правил, которые вводятся в поля, объединенные общим заголовком «RI Actions». При добавлении связи в диаграмму Erwin по умолчанию устанавливает для нее набор правил, которые можно редактировать.

Завершающим этапом подготовки логической модели является проведение нормализации данных. Erwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных:

ü Erwin отмечает повторное использование имени сущности и атрибута;

ü запрещает присвоение неуникальных имен атрибутов внутри одной модели (при соответствующей установке опции Unique Name), соблюдая правило «в одном месте – один факт».

На физическом уровне возможно проведение денормализации данных – процесса, обратного нормализации. Erwin позволяет сохранить на уровне логической модели нормализованную структуру, при этом построить на уровне физической модели структуру (возможно, денормализованную), которая обеспечивает лучшую производительность, используя особенности конкретной СУБД и бизнес-правила предметной области. Erwin имеет следующие возможности по поддержке процесса денормализации:

ü Сущности, атрибуты, ключи и домены можно создавать только на уровне логической модели, включив в соответствующих редакторах опцию Logical Only. Такие объекты не будут отображаться на уровне физической модели и не будут создаваться при генерации базы данных.

ü Таблицы, колонки, домены и индексы можно создавать только на уровне физической модели (опция Physical Only).

ü При разрешении связи многие-ко-многим в физической модели создается новая таблица и структура данных может быть дополнена только на уровне физической модели.

Erwin позволяет создавать на физическом уровне представления, которые представляют собой объекты базы данных, данные в которых не хранятся постоянно, как в таблице, а формируются динамически при обращении к представлению. Представление не может существовать само по себе, а определяется только в терминах одной или нескольких таблиц.

Задание правил декларативной ссылочной целостности

Ø Находясь на логическом уровне модели данных, выделите связь «заключает» между сущностями Покупатель и Договор, щелкнув по ней указателем мыши. Затем нажмите правую кнопку мыши и в контекстном меню выберите пункт Relationship Properties(редактор связей).

Ø В окне редактора связей Relationship перейдите на вкладку RI Actions. Ознакомьтесь с правилами ссылочной целостности для связи «Покупатель – Договор», присвоенными по умолчанию. Данные установки запрещают вставку и изменение экземпляра дочерней сущности, а также удаление и изменение родительской сущности. Это означает, что не допускается удаление или изменение покупателя, если в базе данных имеются заключенные с ним договоры, а также ввод договора без указания покупателя или со ссылкой на несуществующего покупателя. Тем самым мы выполнили условие, по которому договор может существовать только для конкретного покупателя.

Ø Проанализируйте установленные правила ссылочной целостности для всех остальных связей.

Правила, присваиваемые связи по умолчанию, можно изменить, выбрав нужное значение из выпадающего списка.

Нормализация данных

Из модели видно, что в сущности Покупатель присутствует множественный атрибут ТЕЛ. Покупатель может иметь несколько телефонных номеров, что является нарушением первой нормальной формы, согласно которой все значения атрибутов должны быть атомарными. Поэтому необходимо выделить атрибут ТЕЛ в отдельную сущность.

Ø Создайте сущность Телефон, содержащую следующие атрибуты: КОД_ТЕЛ (первичный ключ, тип – number) и ТЕЛ (тип – string).

Ø Свяжите сущности Покупатель и Телефон идентифицирующей связью. Установите мощность связи – One or More (P)и введите имя связи – имеет.

Выбор сервера

Ø Выполните команду Database | Choose Database.

Ø В диалоговом окне Erwin/ERX – Target Server необходимо задать тип сервера – Access и его версию – 2000. Кроме того, здесь указывается используемый по умолчанию тип данных и условие NULL для вновь созданных колонок. Некоторые опции данного диалогового окна зависят от выбранного типа сервера.

Ø После выбора сервера нажмите кнопку ОК.

Денормализация данных

На модели имеются две связи типа «многие-ко-многим»: Товар – Договор и Товар – Накладная, которые должны быть разрешены на физическом уровне. Результат разрешения данных связей представлен в табл. 3.1.

Таблица 3.1.

Результат разрешения связей «многие-ко-многим»

Связь многие-ко многим	Имя ассоциативной таблицы	Новые колонки ассоциативной таблицы	Тип данных
Товар-Договор	Поставка_План	СРОК_ПОСТ	Datetime
КОЛ_ПОСТ	Number
СУММА_ПОСТ	Number
Товар-Накладная	Отгрузка	КОЛ_ОТГР	Number
СУММА_ОТГР	Number

Разрешение связей «многие-ко-многим» осуществляется автоматически при переходе на физический уровень, либо с помощью специального мастера Many Relationship Transform Wizard.

Ø Для вызова данного мастера выделите связь «Товар – Договор», щелкнув по ней указателем мыши. Затем нажмите правую кнопку мыши и в контекстном меню выберите пункт Create Association Table (создать ассоциативную таблицу). На экране появится первый диалог мастера, содержащий текст о его назначении.

Ø Нажмите кнопку Далее. На экране появится второй диалог мастера, в котором задается им ассоциативной таблицы.

Ø Введите в поле Table Name (имя таблицы) – Поставка_План. В поле Table Comment (комментарии к таблице) введите текст: Сведения о поставках товара по договору.

Ø Нажмите кнопку Далее. На экране появится следующий диалог мастера, в котором указывается Transform Name (имя преобразования) и Transform Definition (определение преобразования).

Ø Нажмите кнопку Далее и затем Готово.

Ø На модели появилась новая таблица Поставка_План, связанная идентифицирующей связью с таблицами Товар и Договор.

Ø Новую таблицу необходимо дополнить тремя колонками (см. табл. 2.1). Для этого выделите таблицу Поставка_План, щелкнув по ней указателем мыши. Затем нажмите правую кнопку мыши и в контекстном меню выберите пункт Columns (редактор колонок).Работа с данным редактором аналогична работе с редактором атрибутов.

Ø Самостоятельно введите три новых колонки в соответствии с табл. 3.1.

Ø Рассмотренным выше способом (с использованием мастера) преобразуйте связь «Товар – Накладная» и дополните полученную ассоциативную таблицу Отгрузка двумя колонками согласно табл. 3.1.

Задание правил валидации

Задание списка допустимых значений

В соответствии с рассматриваемой предметной областью для поля СТАВКА_НДС таблицы Товар зададим список допустимых значений: 0, 10 и 18 %.

Ø Вызовите контекстное меню таблицы Товар и выберите пункт Columns.

Ø В окне редактора в поле Columnвыберите колонку, для которой будет задаваться правило– СТАВКА_НДС.

Ø Перейдите на закладку выбранной СУБД – Access.

Ø Щелкните по кнопке, расположенной справа от раскрывающегося списка Valid.

Ø В диалоге Validation Rulesщелкните по кнопке New.

Ø В диалоге New Validation Ruleвполе Logical введите имя правила – Проверка ставки НДС. Нажмите кнопку ОК.

Ø Перейдите на закладку General. В группе Type установите опцию Valid Value List.

Ø В поле Valid Value в первой строке введите 0. Во вторую и третью строки введите значения: 10 и 18.

Ø Проверьте, чтобы в верхней части окна редактора Validation Rules появилась строчка: Проверка ставки НДС (Validation Name) IN (0, 10, 18) (Validation Rule).

Ø Нажмите ОК.В окне редактора Columns на закладке Access в поле Valid появилось наименование созданного правила – «Проверка ставки НДС».

Задание значений, присваиваемых по умолчанию

Создадим правило, согласно которому в поле ДАТА_ДОГ таблицы Договор будет по умолчанию подставляться значение текущей даты.

Ø Вызовите контекстное меню таблицы Договор и выберите пункт Columns.

Ø В окне редактора в поле Columnвыберите колонку, для которой будет задаваться правило– ДАТА_ДОГ.

Ø На закладке Access щелкните по кнопке, расположенной справа от раскрывающегося списка Default.

Ø В диалоговом окне Default/Initial Valuesщелкните по кнопке New.

Ø В диалоге New Default Valueвполе Logical введите имя правила – Текущая дата. Нажмите кнопку ОК.

Ø На закладке Access в поле Server Value – Access Default введите Date() (функцию, получающую значение текущей даты).

Ø Нажмите ОК.В окне редактора Columns на закладке Access в поле Default появилось наименование созданного правила – «Текущая дата».

Ø Установите это же правило для поля ДАТА_ОТГР таблицы Накладная. Для этого в окне редактора колонок Columnвыделите поле ДАТА_ОТГР и на закладке Access в поле Defaultиз раскрывающегося списка выберитеправилоТекущая дата.

Задание правил проверки вводимых значений

Создадим правило проверки вводимых значений для поля ЦЕНА таблицы Товар, согласно которому данное поле не может иметь значения, меньшие 0.

Ø Вызовите контекстное меню таблицы Товар и выберите пункт Columns.

Ø В окне редактора в поле Columnвыберите колонку, для которой будет задаваться правило– ЦЕНА.

Ø На закладке Access щелкните по кнопке, расположенной справа от раскрывающегося списка Valid.

Ø В диалоге Validation Rulesщелкните по кнопке New.

Ø В диалоге New Validation Ruleвполе Logical введите имя правила – Проверка цены. Нажмите кнопку ОК.

Ø Перейдите на закладку General. В группе Type установите опцию Min/Max.

Ø В поле Min введите 1. Кроме нижней границы диапазона значений здесь также можно задать и верхнюю границу (Max).

Ø В верхней части окна редактора Validation Rules в списке правил валидации добавилось вновь созданное: Проверка цены >=1.

Ø Нажмите кнопку ОК.

Задание параметров вычисления размера БД

Ø Переключитесь на физическую модель БД (Physical).

Ø Выполните команду меню Tools | Volumetrics. В окне Volumetricsзадаются параметры, на основе которых вычисляется размер БД.

Ø Выделите в списке Table таблицу, задайте начальное количество строк (Initial), максимальное количество строк (Max) и прирост количества строк в месяц (Grow By). Если параметры Max и Grow By используются одновременно, рост размера таблицы прекращается при достижении максимального размера.

Ø В таблице Column Properties задайте следующие свойства колонок таблицы: ширину поля Avg Width для тех типов данных, для которых это допускается, и средний ожидаемый процент строк Pct Null, в которых текущее поле принимает значение NULL.

Ø В группе Include Indexes укажите индексы, создаваемые для первичных(PK), внешних (FK), альтернативных (AK)ключей или инверсных входов (IE).

Ø В группе Storage для СУБД, которые поддерживают объекты физической памяти, задаются эти объекты.

Ø На закладке Parameters возможно задание дополнительных параметров, используемых для расчета размера БД:

TableFactor показывает накладные расходы на хранение таблицы в БД.

IndexFactorпоказывает накладные расходы на хранение индекса в БД.

RowOverhead используется для дополнительного перерасчета количества байт каждой строки.

BlobFactor и BlobBlockSizeиспользуется для перерасчета Blob-колонок, хранящихся физически вне таблицы.

BytesPerChar используется для задания количества байт, необходимых для хранения одного символа строкового типа. Для ASCII – это 1 байт, для UNICODE – 2 байта.

LogPercentиспользуется для вычисления размеров log-файлов БД.

Создание отчета

Ø Для создания результирующего отчета на закладке Report в группе Options выберите тип объектов, по которым проводится расчет.

Ø В группе Time укажите временной интервал (начальное состояние или определенное время после начала эксплуатации).

Ø Нажмите кнопку Send to Data Browser.

Ø В верхней части диалогового окна Data Browser из списка выберите Erwin Volume Reports: Table Calculations.

Ø В правой части окна можно просмотреть содержимое отчета. Поскольку СУБД Access не поддерживает объекты физической памяти, удалим из отчета столбец Physical Objects. Для этого выберите команду Edit | Report Format и в появившемся окне снимите галочку Physical Objects. Нажмите кнопку ОК.

Ø Сохраним отчет в формате HTML. Для этого выберите команду File | Export. В диалоговом окне Export from Data Browser в поле Export Format из списка выберите HTML и нажмите кнопку Export.

Задания

· Создайте следующие отчеты: отчет по всем сущностям и их атрибутам, отчет по связям. Сохраните полученные отчеты в формате HTML.

· Сформируйте новый отчет из категории Model Validation, задав в нем все опции проверки корректности модели. Сохраните отчет в виде представления.

Практическое занятие №4

«Проектирование базы данных с использованием CASE-средств»

Часть 1. Знакомство с интерфейсом ERwin

Цель работы: дать студентам навык работы с интерфейсом ERwin 4.0.

Общие сведения

Базы данных, как и другие информационные системы (ИС), проходят разные этапы своего жизненного цикла, начиная от замысла системы, предпроектного обследования, включая этапы проектирования, эксплуатации, а далее - модернизации системы.

Создание крупных проектов практически невозможно без использования средств автоматизации проектирования (CASE-систем). Их использование позволяет не только ускорить работы и повысить качество их выполнения, но и дает инструменты для организации коллективного труда группы проектировщиков. Использование инструментальных средств при проектировании баз данных затрагивает разные этапы жизненного цикла АИС. Оно в определенной мере предопределяет процесс обследования и дает инструмент для отображения его результатов.

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

Использование CASE-систем такого типа объединяет не только проектировщиков АИС, но и заказчиков системы, и поэтому отдельные механизмы, а именно нотации, используемые на этапе концептуального моделирования системы, должны грамотно восприниматься всеми ими. Различают прямое проектирование (forward-engineering) - процесс получения структуры базы данных для выбранной целевой СУБД на основе построенной ER- модели, и обратное проектирование (reverse-engineering - реверс-инжиниринг) - когда ER-модель получается на основе существующей базы данных. CASE-средства обычно поддерживают оба эти процесса.

В качестве CASE-средств можно представить ткие продукты как Power Designer, ER/Studio, AllFusion ERwin Data Modeler (ранее эта компонента AllFusion выпускалась в виде отдельного продукта и называлась ERwin) и другие. Многие из этих систем имеют сходную функциональность и даже базируются на одних и тех же стандартах изображения ER-моделей.

В данной практической работе рассматриваются вопросы проектирование баз данных с использованием инструментального средства автоматизации проектирования AllFusion ERwin Data Modeler 4.0. В дальнейшем по тексту данного учебного пособия для краткости будем использовать название ERWin, имея в виду AllFusion ERwin Data Modeler 4.0.

ERwin - CASE-средство проектирования баз данных от фирмы Computer Associates. ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД.

ERwin не привязан к технологии какой-либо конкретной фирмы, поставляющей СУБД или средства разработки. Он поддерживает различные серверы баз данных и настольные СУБД, а также может обращаться к базе данных через интерфейс ODBC. Так, в текущей версии ERwin встроена поддержка 23 СУБД, среди которых: Oracle; Microsoft SQL Server и т.п. Заметим лишь, что речь идет только о реляционных СУБД. ERwin можно использовать совместно с некоторыми популярными средствами разработки клиентских частей приложений: PowerBuilder, Visual Basic, Delphi.

Процесс моделирования в ERwin базируется на методологии проектирования реляционных баз данных IDEF1X.

ERwin имеет два уровня представления модели - логический и физический.

Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Постоянный клиент», «Отдел» или «Фамилия сотрудника». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами (подробнее о сущностях и атрибутах будет рассказано ниже). Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов (см. BPwin). Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.

Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логические и физические позволяет решить несколько важных з