Создание логической модели данных
Моделирование информационного обеспечения средствами ERwin
Отображение модели данных в инструментальном средстве ERwin
ERwin имеет два уровня представления модели – логический и физический.
Логический уровень — это абстрактный взгляд на данные, когда данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных разрабатывается на основе существующих моделей данных (например, реляционной), но никак не связана с конкретной реализацией системы управления базы данных (СУБД) и прочих физических условий реализации. Она может быть построена на основе другой логической модели, например, на основе модели потоков данных или процессов/
Логическая модель данных является источником информации для фазы физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет исключительное значение для выбора действительно эффективного проектного решения.
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей.
|
|
|
На физическом уровне объекты БД должны называться так, как того требуют ограничения СУБД.
После описания логической модели проектировщик может выбрать необходимую СУБД, и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость — создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем создать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах — таблицах, колонках, индексах, процедурах и т.д.
|
|
|
Интерфейс ERwin выполнен в стиле Windows-приложений, достаточно прост и интуитивно понятен - рис.1
 |
Рис. 1. Окно отображение логической модели
Рассмотрим кратко значения кнопок панели инструментов (табл. 1).
Таблица 1. Основная панель инструментов
| Кнопки | Назначение кнопок |
| Создание, открытие, сохранение и печать модели |
| Вызов диалога Report Browser для генерации отчетов |
| Изменение уровня просмотра модели: уровень сущностей, уровень атрибутов и уровень определений |
| Изменение масштаба просмотра модели |
| Генерация схемы БД, обратное проектирование, выравнивание схемы с моделью и выбор сервера |
| Переключение между областями модели - Subject Area |
ERwin имеет несколько уровней отображения диаграммы: уровень сущностей, уровень атрибутов, уровень определений, уровень первичных ключей.
Таблица 2. Уровни отображения модели
| Уровень отображения | Представление модели |
| Сущности (Entity) | 
|
| Атрибуты (Attribute) | 
|
| Первичный ключ (Primary Key) | 
|
| Определение (Definition) | 
|
| Сущности с отображением малых иконок | 
|
| Иконки (Icon) с отображением малых иконок | 
|
 |
Для создания типов сущностей модели и связывания их между собой используются палитра инструментов, показанная на рис. 2. Палитра инструментов выглядит различно на разных уровнях отображения модели. На логическом уровне палитра инструментов имеет следующие значения кнопок (табл. 2).
|
|
|
Рис. 2. Палитра инструментов
Таблица 2. Палитра инструментов
| Кнопки | Назначение кнопок | Описание | |||||
| Указатель | кнопка указателя (режим мыши) - в этом режиме можно установит фокус на каком-либо объекте модели | |||||
| Сущность | кнопка внесения сущности - для внесения сущности нужно щелкнуть левой кнопкой мыши по кнопке внесения сущности и один раз по свободному пространству на модели. Для редактирования сущностей или других объектов модели необходимо перейти в режим указателя | |||||
| Категория | категория, или категориальная связь, - специальный тип связи между сущностями, которая будет рассмотрена ниже. Для установления категориальной связи нужно щелкнуть левой кнопкой мыши по кнопке категории, затем один раз щелкнуть по сущности - родовому предку, затем - по сущности-потомку | |||||
| Идентифицирующая связь | связь между независимой и зависимой сущностями | |||||
| Связь “Многие-ко-многим” | экземпляр одной сущности может быть связан со многими экземплярами другой сущности и наоборот (возможна только на уровне логической модели) | |||||
| Неидентифицирующая связь | связь между независимыми сущностями |
На физическом уровне палитра инструментов имеет:
• вместо кнопки категорий — кнопку внесения представлений (view);
• вместо кнопки связи "многие-ко-многим" — кнопку связей представлений.
• Запустите Computer Associates ERwin. Если появится окно ModelMart Connection Manager, закройте его нажатием на кнопку Cancel.
• Если появляется диалог Computer Associates ERwin, выберите пункт Create a new model и нажмите OK.
• В появившемся диалоговом окне Create Model – Select Template выберите пункт Logical/Physical.
§ Выберите в качестве базы данных (Target Database) – Access и нажмите OK.
Создание логической модели данных
Уровни логической модели
Различают три уровня логической модели, отличающихся по глубине представления информации о данных]:
• диаграмма сущность-связь (Entity Relationship Diagram, ERD);
• модель данных, основанная на ключах (Key Based model, KB);
• полная атрибутивная модель (Fully Attributed model, FA).
Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи "многие-ко-многим" и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.
Модель данных, основанная на ключах — более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.
Полная атрибутивная модель — наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
ERwin имеет несколько уровней отображения диаграммы: уровень сущностей, уровень атрибутов, уровень определений, уровень первичных ключей и уровень иконок. Переключиться между первыми тремя уровнями можно с использованием кнопок панели инструментов. Переключиться на другие уровни отображения можно при помощи контекстного меню, которое появляется, если нажать правую кнопку мыши на любом месте диаграммы, не занятой объектами модели. В контекстном меню следует выбрать пункт Display Level и затем необходимый уровень отображения .
Сущности и атрибуты
Основные компоненты диаграммы ERwin – это сущности, атрибуты и связи. Сущность можно определить как объект, событие или концепцию, информация о которой должна сохраняться. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности — строка в таблице, а атрибуту — колонка таблицы .
Entity Editor в контекстном меню для сущности позволяет определить имя, описание, комментарии, иконку. Для описания атрибутов сущности выбирается пункт Attribute Editor. Здесь можно указать имя нового атрибута и домен, который будет использоваться при определении типа колонки на уровне физической модели. Атрибуты должны именоваться в единственном числе, иметь четкое смысловое значение и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели.Каждый атрибут должен быть определен (закладка Definition), при этом следует избегать циклических определений и производных атрибутов. Для внесения дополнительных комментариев и определений к сущности служат свойства, определенные пользователем (UDP). Соблюдение этого правила позволяет частично решить проблему нормализации данных уже на этапе определения атрибутов.
Каждый атрибут хранит информацию об определенном свойстве сущности, а каждый экземпляр сущности должен быть уникальным. Атрибут или группа атрибутов, которые однозначно идентифицируют экземпляр сущность, называется первичным ключом. Атрибуты первичного ключа на диаграмме не требуют специального обозначения — это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии.
Продолжим рассмотрение практического моделирования на примере деятельности вымышленной компании, которая занимается в основном сборкой карманных персональных компьютеров (КПК) и установкой на них программного обеспечения (ПО). Компания не производит компоненты и программы самостоятельно, а только собирает КПК и устанавливает ПО.
Основные процедуры компании, следующие:
• продавцы принимают заказы клиентов;
• операторы группируют заказы по типу работ;
• операторы собирают КПК;
• операторы устанавливают ПО на КПК;
• операторы упаковывают КПК согласно заказам;
• кладовщик отгружает клиентам заказы.
Для начала представим модель базы данных компании. Модель должна содержать 8 сущностей: Заказ, Заказчик, Оператор, КПК, ПО, Кладовщик, Готовый товар, Продавец. Каждая из представленных сущностей имеет свой набор атрибутов.
 |
1. Щелкните по кнопке
на рабочем поле программы. Появится окошко сущности с названием Е/1. Окошко сущности разделено на две части. В верхнюю часть входят атрибуты, которые являются ключами сущности, а в нижнюю – не ключевые атрибуты (см. рис. 2).
Рис. 2. Сущность
2. Двойной щелчок по сущности открывает диалоговое окно Attributes. В верхнем правом углу окна расположена кнопка, которая открывает диалоговое окно Entities, где в поле Name имеется возможность изменить имя сущности. Измените имя сущности E1 на «Заказ». После завершения ввода нажмите кнопку OK.
Нажатием на кнопку New... в левом нижнем углу окна открывается диалоговое окно New Attribute создания нового атрибута сущности
3. В поле Attribute Name:* введите название атрибута «Код_заказа», в окошке Domain выберите тип вводимых данных. Для завершения процедуры ввода нажмите OK. Для задания первичного ключа в окне Attributes для выделенного атрибута «Код_заказа» установите галочку Primary Key.
4. Возможен так же и другой способ ввода атрибутов в поля сущности. Чтобы заполнить окошко сущности атрибутами, нужно выбрать сущность левой кнопкой мыши и нажать клавишу «Tab». После ввода названия атрибута надо нажать «Enter», если необходимо остаться в верхней части и продолжить заполнять ключевые атрибуты, или «Tab» если необходимо приступить к заполнению других атрибутов. Клавиша «Tab» перемещает курсор между тремя полями ввода: названием сущности, ключевыми атрибутами и не ключевыми атрибутами. Задайте еще три атрибута в сущности Заказ: «Стоимость», «Дата_заказа» и «Дата_выдачи».
Одним из предложенных способов создайте и заполните все необходимые сущности компании, описанные в таблице3.
Таблица .3. Сущности и атрибуты компании
| Сущности | Атрибуты |
| Клиент | - Код_клиента (PK) - Фамилия - Имя - Отчество - Адрес - Номер_счета |
| Заказ | - Код заказа (PK) - Дата_заказа - Дата_выдачи - Стоимость |
| Сотрудник | Код_сотрудника (PK) - Фамилия - Имя - Отчество - Дата_рождения - Должность - Зарплата |
| КПК | - Код_КПК (РК) - Процессор - Память - Дисплей - Модем - Интерфейс |
| ПО | - Код_ПО (РК) - ОС - Мультимедиа - Интернет - Антивирус - Игры |
| Товар | - Код_товара (РК) |
| Продавец | - Код_продавца (РК) |
| Кладовщик | - Код_кладовщика (РК) |
| Оператор сборки | - Код_оператора_сборки (РК) |
| Оператор установки | - Код_оператора_установки (РК) |
Связи
Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases). Имя связи облегчает чтение диаграммы, например (рис. 3):
 |
Рис. 3. Пример связей
По умолчанию имя связи на диаграмме не показывается. Для отображения имени следует в контекстном меню для свободного места диаграммы выбрать пункт Display Option/relationship и включить опцию Verb Phrase .
На логическом уровне можно установить идентифицирующую связь один-ко-многим, связь многие-ко-многим и неидентифицирующую связь один-ко-многим. Тип сущности определяется ее связью с другими сущностями. Различают зависимые и независимые сущности. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERWin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами.
Различают несколько типов зависимыхсущностей .
Характеристическая— зависимая дочерняя сущность, которая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности.
Ассоциативная— сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей.
Именующая— частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа).
Категориальная— дочерняя сущность в иерархии наследования.
При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности и помечается в дочерней сущности как внешний ключ (FK). Эта операция называется миграцией атрибутов. В дальнейшем, при генерации схемы БД, атрибуты первичного ключа получат признак NOT NULL, что означает невозможность внесения записи в таблицу заказов без информации о номере клиента.
При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности. Неидентифицирующая связь служит для связывания независимых сущностей.
Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи, неидентифицирующая – пунктирной.
Во вкладке General меню Relationship Editor можно задать мощность, имя и тип связи.
Мощность связей (Cardinality) — служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Различают четыре типа сущности:
− общий случай, когда одному экземпляру родительской сущности соответствует 0, 1 или много экземпляров дочерней сущности (не помечается каким-либо символом);
− одному экземпляру родительской сущности соответствует 1 или много экземпляров дочерней сущности (помечается символом Р);
− одному экземпляру родительской сущности соответствует 0 или 1 экземпляр дочерней сущности (помечается символом Z);
− одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности (помечается цифрой точного соответствия).
По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для отображения имени следует в контекстном меню для диаграммы (в месте не занятом объектами модели) выбрать пункт Display Options/Relationship и затем включить опцию Cardinality.
Имя связи (Verb Phrase) — фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи "один-ко-многим", идентифицирующей или неидентифицирующей, достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указывать имена как Parent-to-Child, так и Child-to-Parent [8].
Связь многие-ко-многим возможна только на логическом уровне. При переходе к физическому уровню Erwin автоматически преобразует связь многие-ко-многим, добавляя новую таблицу и устанавливая две новые связи один-ко-многим от старых к новой таблице.
Иерархия наследования представляет собой особый тип объединения сущностей, которые разделяют общие характеристики. Обычно иерархию наследования создают, когда несколько сущностей имеют общие по смыслу атрибуты, либо когда сущности имеют общие по смыслу связи, либо когда это диктуется бизнес-правилами.
Для каждой категории можно указать дискриминатор — атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой.
Иерархии категорий делятся на два типа — полные и неполные. В полной категории одному экземпляру родового предка обязательно соответствует экземпляр в каком-либо потомке. Если категория еще не выстроена полностью и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках, то такая категория будет неполной.
В нашем примере, один клиент может сделать несколько заказов, но один и тот же заказ у двух разных клиентов быть не может, т.е. следует применить связь один ко многим (жирная точка на конце связи означает «многие»). Аналогично рассуждая, расставьте связи между всеми сущностями модели.
1. Выберите кнопку 
, обозначающую связь «один ко многим» и соедините две необходимые сущности. Чтобы соединить, необходимо один раз кликнуть на сущности «один», а затем на сущности «многие».
2. Выберите кнопку 
, обозначающую связь «многие ко многим» и соедините необходимые две сущности.
3. Выберите кнопку 
, обозначающую неидентифицирующую связь, и соедините две необходимые сущности.
4. Аналогично соедините все необходимые сущности, отобразив взаимодействие между ними. Если во время установки связи у вас выскочило диалоговое окно ERwin (рис. 4), это означает, что название атрибута, который мигрирует из родительской сущности, уже существует. Выберите соответствующую опцию миграции и нажмите ОК.
Рис. 4. Диалоговое окно Erwin при установке связи
5. В итоге получим логическую модель базы данных компании 5.
Рис. 5. Логическая модель базы данных компании
Ключи
Как было сказано выше, каждый экземпляр сущности должен быть уникален и должен отличаться от других атрибутов.
Первичный ключ (primary key) — это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения — это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии .
В одной сущности могут оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidate key).
Ключи могут быть сложными (составными) , т. е. содержащими несколько атрибутов. Сложные первичные ключи не требуют специального обозначения — это список атрибутов, расположенных выше горизонтальной линии.
Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду требований:
• Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа.
• Компактность. При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т.е. ключам, содержащим меньшее количество атрибутов. Атрибуты ключа не должны содержать нулевых значений. Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности.
Каждая сущность должна иметь по крайней мере один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные —альтернативными ключами. Альтернативный ключ (Alternate Key) — это потенциальный ключ, не ставший первичным.
Нормализация данных
Нормализация данных— процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. Нормализация позволяет быть уверенным, что каждый атрибут определен для своей сущности, а также значительно сократить объем памяти для хранения информации и устранить аномалии в организации хранения данных. В результате проведения нормализации должна быть создана структура данных, при которой информация о каждом факте хранится только в одном месте. Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам — формализованным требованиям к организации данных. Известны шесть нормальных форм.
Ø Первая нормальная форма (1FN). Сущность находится в первой нормальной форме в том случае, если все атрибуты содержат атомарные значения.
Для приведения сущности к первой нормальной форме следует разделить сложные атрибуты на атомарные. Для этого необходимо:
• создать новую сущность;
• перенести в нее все «повторяющиеся» атрибуты;
• выбрать возможный атрибут для нового PK (или создать новый PK);
• установить идентифицирующую связь от прежней сущности к новой.
Ø Вторая нормальная форма (2NF). Сущность находится во второй нормальной форме, если она находится в первой нормальной форме и каждый неключевой атрибут полностью зависит от первичного ключа. Вторая нормальная форма имеет смысл только для сущностей, имеющих сложный первичный ключ.
Для приведения сущности ко второй нормальной форме следует выделить атрибуты, которые зависят только от части первичного ключа в новую сущность и установить идентифицирующую связь.
Вторая нормальная форма позволяет избежать аномалий при операциях обновления, вставки и удаления записей.
Ø Третья нормальная форма (3NF). Сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой неключевой атрибут не зависит от другого неключевого атрибута.
Для приведения сущности к третьей нормальной форме следует создать новую сущность и перенести в нее атрибуты с одной и той же зависимостью от неключевого атрибута и установить связь.
К сожалению, ERwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных.
В результате нормализации все взаимосвязи данных становятся правильно определенными, исключаются аномалии при операциях с данными, модель данных легче поддерживать. Однако часто нормализация данных не ведет к повышению производительности ИС в целом. Поэтому в целях повышения производительности при переходе на физический уровень приходится сознательно отходить от нормальных форм (проводить операцию денормализации) для того, чтобы использовать возможности конкретного сервера или ИС в целом.
Домены
Домен можно определить как совокупность значений, из которых берутся значения атрибутов. Каждый атрибут может быть определен только на одном домене, но на каждом домене может быть определено множество атрибутов. В понятие домена входит не только тип данных, но и область значений данных.
В ERwin домен может быть определен только один раз и использоваться как в логической, так и в физической модели.
Домены позволяют облегчить работу с данными как разработчикам на этапе проектирования, так и администраторам БД на этапе эксплуатации системы. На логическом уровне домены можно описать без конкретных физических свойств. На физическом уровне они автоматически получают специфические свойства, которые можно изменить вручную.
Для создания домена в логической модели служит диалог Domain Dictionary Editor. Его можно вызвать из меню Edit/Domain Dictionary по кнопке, расположенной в верхней левой части закладки General диалога Attribute Editor. Каждый домен может быть описан, снабжен комментарием или свойством, определенным пользователем (UDP).
ERwin имеет специальный инструмент, который значительно облегчает создание новых атрибутов в модели, используя описание доменов Independent Attribute Browser. Этот диалог вызывается с помощью CTRL+B.
Дата добавления: 2018-05-13; просмотров: 1519; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!