37479

МЕТОДОЛОГИЯ МОДЕЛИРОВАНИЯ ДАННЫХ В СРЕДЕ ERWIN

Книга

Информатика, кибернетика и программирование

2] Зависимые и независимые сущности.9] Избыточные сущности [9. На стадии проектирования создаются логические модели трех уровней: Entity Reltion Digrm Диаграмма сущностьсвязь и KeyBsed model Модель данных основанная на ключах и Полная атрибутивная модель Диаграмма сущностьсвязь ERD – Entity Reltionship Digrm определяет сущности и их отношения. Модель данных основанная на ключах описывает структуру данных системы в которую включены все сущности и атрибуты в том числе ключевые.

Русский

2013-09-24

993 KB

85 чел.

Министерство образования и науки Российской Федерации

Федеральное агентство по образованию

Южно-Уральский государственный университет

Кафедра «Информационные системы»

681.3.06(07)

М749

В.В. Мокеев

МЕТОДОЛОГИЯ МОДЕЛИРОВАНИЯ ДАННЫХ 

В СРЕДЕ ERWIN

Учебное пособие для лабораторных работ

Челябинск

Издательство ЮУрГУ

2011

УДК [681.3.06: 519.6](075.8)

Мокеев В.В. Методология моделирования данных в среде ERWin: Учебное пособие для лабораторных работ. – Челябинск: Изд. ЮУрГУ, 2005. – 88 с.

Пособие посвящено изучению средства структурного анализа данных ERWin 3.5.2 и направлено на обучение студентов технологии моделирования данных по стандарту IDEF1X. Систематическая подача материалов в виде последовательных уроков позволяет изучить теоретические основы методологии IDEF1X и приобрести практические навыки проектирования логической и физической моделей данных.

Учебное пособие предлагается использовать студентам при проведении лабораторных работ по курсу «Информационные системы» специальностей  080801 – «Прикладная информатика (управление)», 080700 – «Бизнес-информатика».

Ил. 33, табл. 7.

Одобрено учебно-методической комиссией факультета «Экономика и предпринимательство».

Рецензенты: Давыдов А.С., Мищенко Е.Ю.

                                                                               © Мокеев В.В., 2005-2011.

                                                                               © Издательство ЮУрГУ, 2005.


ОГЛАВЛЕНИЕ

[1] В.В. Мокеев

[2]
ОГЛАВЛЕНИЕ

[3]
Введение

[4]
Тема 1. Создание диаграммы сущность-связь

[4.1] Основные цели

[4.2] Теоретическая часть

[4.3] Учебное задание

[4.4] Технология выполнения учебного задания

[4.4.0.1] Рекомендации при выборе первичного ключа.

[4.5] Контрольные вопросы

[4.6] Самостоятельное задание

[5]
Тема 2. Разработка  модели данных, основанной на ключах

[5.1] Основные цели

[5.2] Теоретическая часть

[5.3] Учебное задание

[5.4] Технология выполнения учебного задания

[5.5] Контрольные вопросы

[5.6] Самостоятельное задание

[6]
Тема 3. Создание полной атрибутивной модели базы данных

[6.1] Основные цели

[6.2] Теоретическая часть

[6.2.0.1] Нормализация

[6.3] Учебное задание

[6.4] Технология выполнения учебного задания

[6.5] Контрольные вопросы

[6.6] Самостоятельное задание

[7]
Тема 4. Создание физического уровня модели

[7.1] Основные цели

[7.2] Теоретическая часть

[7.3] Учебное задание

[7.4] Технология выполнения учебного задания

[7.5] Контрольные вопросы

[7.6] Самостоятельное задание

[8]
Тема 5. Отчеты в ERWin

[8.1] Основные цели

[8.2] Теоретическая часть

[8.3] Учебное задание

[8.4] Технология выполнения учебного задания

[8.5] Контрольные вопросы

[8.6] Самостоятельное задание

[9]
Приложение 1. Методология моделирования данных IDEF1X

[9.1] Диаграмма сущность-связь

[9.1.0.1] Сущность

[9.1.0.2] Именование сущностей

[9.1.0.3] Описание сущностей

[9.1.0.4] Атрибут

[9.1.0.5] Связь

[9.1.0.6] Тип связи

[9.1.0.7] Идентифицирующая и неидентифицирующая связи

[9.1.0.8] Связи типа «один-ко-одному», «один-ко-многим», «многие ко-многим»

[9.1.0.9] Имя связи

[9.1.0.10] Мощность связи

[9.1.0.11] Правила ссылочной целостности

[9.2] Модель данных, основанная на ключах  

[9.2.0.1] Правила ссылочной целостности

[9.2.0.2] Зависимые и независимые сущности.

[9.2.0.3] Идентифицирующие и неидентифицирующие связи.

[9.2.0.4] Роль

[9.2.0.5] Связь «многие ко многим»

[9.2.0.6] Распространенные ошибки при моделировании сущностей и выборе ключей

[9.2.0.7] Моделирование ролей

[9.2.0.8] Перегрузка сущностей

[9.2.0.9] Избыточные сущности

[9.2.0.10] Выбор неправильного первичного ключа

[9.2.0.11] Использование неудачных имен сущностей

[9.2.0.12] Использование неудачных описаний сущностей

[9.3] Полная атрибутивная модель

[9.3.0.1] Нормализация

[9.3.0.2] Денормализация

[9.4] Создание физического уровня модели

[10]
Приложение 2. Наиболее часто задаваемые вопросы


Введение

Учебное пособие предназначено для лабораторных работ по курсу «Информационные системы» специальностей  351400 – «Прикладная информатика в управлении», 080700 – «Бизнес-информатика».

В учебном пособии изучается программный продукт ERWin 3.5.2, представляющий среду моделирования данных и генерации баз данных на основе стандартной методологи IDEF1X. в наиболее удобной для пользователя графической форме. ERWin дает возможность с двумя уровнями представления модели: логическим и физическим. Причем модель данных может содержать как один, так и оба этих уровня.

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

Основная цель пособия – помочь студенту быстро и эффективно освоить основные приемы разработки логической и физической модели данных, генерации баз данных  и получить навыки работы в среде ERWin.

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

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

Методическая последовательность изложения материала дает студентам схему организации самостоятельной работы в области проектирования баз данных. Для успешного освоения материала каждого урока необходимо внимательно прочитать теоретическую справку, затем выполнить учебное задание, для которого имеется подробная технология выполнения, далее ответить на контрольные вопросы. Если студент успешно ответил на контрольные вопросы и разобрался с учебным заданием, то он может переходить к выполнению самостоятельного задания.


Тема 1. Создание диаграммы сущность-связь

Основные цели

  •  Ознакомиться с технологией построения диаграммы сущность-связь.
  •  Изучить типы связей между сущностями.
  •  Освоить инструментарий ERWin.

Теоретическая часть

На стадии проектирования создаются  логические модели данных, которые могут быть построены с использованием методологии методологию IDEF1X. Case-средство ERWin поддерживает методологию IDEF1X и стандарт IE (Information Engineering). Методология IDEF1X подразделяется на уровни, соответствующие проектируемой модели данных системы. Каждый такой уровень соответствует определенной фазе проекта. Такой подход полезен при создании систем по принципу «сверху вниз».

На стадии проектирования создаются логические модели трех уровней: Entity Relation Diagram (Диаграмма сущность-связь) и Key-Based model (Модель данных, основанная на ключах) и Полная атрибутивная модель

Диаграмма сущность-связь (ERDEntity Relationship Diagram) определяет сущности и их отношения. Модель данных, основанная на ключах, дает более подробное представление данных. Она включает описание всех сущностей и первичных ключей, которые соответствуют предметной области. Диаграмма сущность-связь является самым высоким уровнем в модели данных и определяет набор сущностей и атрибутов проектируемой системы. Целью этой диаграммы является формирование общего взгляда на систему для ее дальнейшей детализации.

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

Полная атрибутивная модель – это логическая модель, наиболее детально представляющая структуру данных, представленных в третьей нормальной форме.

Первым шагом при создании логической модели БД является построение диаграммы ERD, которая состоит из трех частей: сущностей, атрибутов и взаимосвязей. ERD-диаграмма позволяет рассмотреть систему целиком и выяснить требования, необходимые для ее разработки, касающиеся хранения информации. ERD-диаграммы можно подразделить на отдельные куски, соответствующие отдельным задачам, решаемым проектируемой системой. Это позволяет рассматривать систему с точки зрения функциональных возможностей, делая процесс проектирования управляемым.

Сущность – это субъект, место, вещь, событие или понятие, содержащие информацию. Точнее, сущность – это набор (объединение) объектов, называемых экземплярами. В диаграммах ER-модели сущность представляет в виде прямоугольника, содержащего имя сущности. При этом имя сущности – это имя типа, а не конкретного объекта-экземпляра этого типа. Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности.

Связь – это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). В любой связи выделяются два конца (в соответствии с парой связываемых сущностей), на каждом из которых указывается имя конца связи, степень конца связи (сколько экземпляров данной сущности связывается), обязательность связи (т.е. любой ли экземпляр данной сущности должен участвовать в данной связи).

В ERwin связи представлены пятью основными элементами информации:

  •  тип связи;
  •  имя связи;
  •  мощность связи;
  •  допустимость пустых (null) значений;
  •  требования по обеспечению ссылочной целостности.

ERwin поддерживает следующие основные типы связей: идентифицирующая/неидентифицирующая, полная категория, неполная категория, многие-ко-многим.

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

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

Идентифицирующая связь изображается сплошной линией; неидентифицирующая – пунктирной линией. Линии заканчиваются точкой со стороны дочерней сущности.

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

Имя связи (Verb Phrase) – фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи «один ко многим» идентифицирующей или неидентифицирующей достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи «многие ко многим» следует указывать имя как Parent-to-Child, так и Child-to-Parent.

Мощность связи (Cardinality) служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

Различают 4 типа мощности:

  •  общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности не помечается каким-либо символом;
  •  символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
  •  символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);
  •  цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.

Правила ссылочной целостности (referential integrity (RI)) – логические конструкции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления.

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

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

Типы сущностей и иерархия наследования

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

Характеристическая зависимая дочерняя сущность – это сущность, связанная только с одной родительской и хранящая информацию о характеристиках родительской сущности. Например, связь Агент – Телефон.

Ассоциативная сущность – это сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей и позволяет реализовать связь «многие-ко-многим».

Именующая сущность – это частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа).

Категориальная сущность – это дочерняя сущность в иерархии наследования.

Иерархия наследования (или иерархия категорий) представляет собой особый тип объединения сущностей, которые разделяют общие характеристики.

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

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

Рис. 1.1. Иерархия наследования. Полная категория

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

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

Для создания категориальной связи следует:

  •  установить курсор на кнопке «Категория» в палитре инструментов и нажать левую кнопку мыши;
  •   щелкнуть сначала по родовому предку, а затем по потомку;
  •  для установления второй связи в иерархии категории следует сначала щелкнуть по символу категории, затем по второму потомку.

Для редактирования категорий нужно щелкнуть правой кнопкой мыши по символу категории и выбрать в контекстном меню пункт Subtype Relationship Editor. В диалоге Subtype Relationship можно указать атрибут-дискриминатор категории (список Discriminator Attribute Choice) и тип категории – полная/неполная (радио-кнопки Complete/Incomplete).

Учебное задание

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

Технология выполнения учебного задания

1. Запустите программу ERWin. Открывается рабочее окно программы ERWin для создания модели и основная панель инструментов (табл. 1.1).

Таблица 1.1

Основная панель инструментов ERWin

Кнопки

Назначение кнопок

Создание, открытие, сохранение и печать модели

Вызов диалогового окна Report Browser для генерации отчетов

Изменение уровня просмотра модели: уровень сущностей, уровень атрибутов и уровень определений

Изменение масштаба просмотра модели

Генерация схемы БД, выравнивание схемы с моделью и выбор сервера (доступны только на уровне физической модели)

Вызов дополнительной панели инструментов для работы с репозитарием Model Mart

Переключение между областями модели

Палитра инструментов выглядит различно на разных уровнях отображения модели.

На логическом уровне панель инструментов выглядит как в табл. 1.2.

2. Внесем  сущности АГЕНТ, КЛИЕНТ, СТРАХОВОЙ ДОГОВОР, ИМУЩЕСТВО, УСЛУГА, ЛЬГОТА в диаграмму. Для этого нажмите  кнопку «Entity», установите указатель мыши в то место на диаграмме, где бы хотели расположить  сущность, и один раз нажмите левую клавишу мыши.


Таблица 1.2.

Палитра инструментов на логическом уровне

Кнопка

Описание

Кнопка указателя (режим мыши) – в этом режиме можно установить фокус на каком-либо объекте модели.

Кнопка внесения сущности – для внесения сущности нужно щелкнуть левой кнопкой мыши по кнопке внесения сущности и один и один  раз по свободному пространству на модели. Для редактирования сущностей или других объектов модели необходимо перейти в режим указателя.

Кнопка категории. Категория или категориальная связь – это специальный тип связи между сущностями. Для установления категориальной связи нужно щелкнуть левой кнопкой мыши по кнопке категории, затем один раз щелкнуть по сущности-родовому предку, затем по сущности-потомку.

Кнопка внесения текстового блока. С ее помощью можно внести текстовый комментарий в любую часть графической модели.

Кнопка перенесения атрибутов внутри сущностей и между ними. Атрибуты могут быть перемещены способом drag & drop.

Кнопка создания идентифицирующей связи.

Кнопка создания связи «многие-ко-многим».

Кнопка создания неидентифицирующей связи.

3. Отредактируйте названия сущностей на диаграмме, как это показано на рис. 1.2. Для этого нажмите правую клавиши мыши  и выберите из всплывающего меню команду «Entity Editors».

Каждая сущность должна быть полностью определена с помощью текстового описания во вкладке Definition. Вкладки Note, Note 2, Note 3, UDP (User Defined Properties – свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущности. В ранних версиях ERwin вкладкам Note2 и Note3 соответствовали окна Query и Sample.

Рис. 1.2. Внесение новых сущностей в диаграмму

Вкладка Definition используется для ввода определения сущности. Эти определения полезны как на логическом уровне, поскольку позволяют понять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы и использовать в реальной базе данных (CREATE COMMENT on entity_name).

Вкладка Note позволяет добавлять дополнительные замечания о сущности, которые не были отражены в определении, введенном во вкладке Definition. Здесь можно ввести полезное замечание, описывающее какое-либо бизнес-правило или соглашение по организации диаграммы.

Во вкладке Note 2 можно задокументировать некоторые возможные запросы, которые, как ожидается, будут использоваться по отношению к сущности в базе данных

Вкладка Note 3 позволяет вводить примеры данных для сущности (в произвольной форме).

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

Рис. 1.3. Панель диалога редактора сущностей

4. Для этого выделите сущность, щелкните по ней правой кнопкой и выберите команду  Аttribute Editor…

Рис. 1.4. Панель диалога редактора атрибутов сущностей

Далее щелкните по кнопке New, и в появившемся диалоге New Attribute (рис. 1.4)  укажите имя атрибута (Attribute Name), имя соответствующей ему в физической модели колонки (Column Name) и домен (Domain). Домен атрибута будет использоваться при определении типа колонки на уровне физической модели. Имя атрибута можно задавать на русском, а имя колонки на английском.

Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Соблюдение этого правила позволяет частично решить проблему нормализации данных уже на этапе определения атрибутов. Например, создание в сущности КЛИЕНТ атрибута ФИО противоречит требованиям нормализации, поскольку атрибут должен быть атомарным, т.е. не содержать множественных значений.

Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключом. Для атрибутов первичного ключа во вкладке General диалога Attributes необходимо сделать пометку в окне выбора Primary Key.

Рекомендации при выборе первичного ключа.

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

Никакой из атрибутов первичного ключа не должен иметь нулевое значение.

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

Рис. 1.5. Диалог New Attribute

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

5. Задайте для сущностей следующие атрибуты

КЛИЕНТ: Фамилия (LastName, String), Имя (FirstName, String), Отчество (Patron, String), Паспорт (NumPasport, String), Учетный номер (NumC, Number), Телефон (Phone, String).

АГЕНТ: Фамилия (LastName, String), Имя (FirstName, String), Отчество (Patron, String), Учетный номер (NumC, Number), Телефон (Phone, String).

ИМУЩЕСТВО: Описание (Decription, String)., Город (City, String), Улица (Street, String), Дом (House, String), Квартира (Appat, String).

СТРАХОВОЙ ДОГОВОР: Дата страхования (DatStrax, DateTime), Страховая сумма (StraxSum, Number).

СТРАХОВАЯ УСЛУГА: Описание (Decription, String), Страховой процент

СТРАХОВОЙ ФАКТОР: Описание (Decription, String), Процент скидки.

Результаты работы показаны на рис. 1.6. Если атрибуты не отображаются в рабочем окне измените уровень просмотра модели (смотри табл. 1.1)

Рис. 1.6. Внесение атрибутов в диаграмму

5. Определите связи между сущностями. Напомним, что для задания связи между двумя сущностями необходимо указать имя связи, тип связи, направление связи (родительская и дочерняя сущности), мощность связи, допустимость пустых (null) значений, требования по обеспечению ссылочной целостности, а в некоторых случаях и роль.

Неидентифицирующая связь служит для связывания независимых сущностей.

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

  •  Клиент заключает Страховой договор.
  •  Агент обслуживает Страховой договор.
  •  Имущество страхуется в Страховом договоре.
  •  Страховая услуга указывается в Страховом договоре
  •  Страховой фактор учитывается в Страховом договоре.

Все пять связи являются связями «один-ко-многим». Во всех случаях сущность СТРАХОВОЙ ДОГОВОР является дочерней.

Все связи неидентифицирующие, т.к. любой экземпляр сущности СТРАХОВОЙ ДОГОВОР может быть однозначно идентифицирован по коду сделки, то есть вне зависимости от экземпляров других сущностей.

Все связи, кроме первой, могут иметь мощность 0, 1 или более. Первая и третья связи не могут иметь мощность 0, (любой человек становится КЛИЕНТОМ только тогда, когда он совершает хотя бы один раз страхует свое имущество, аналогично, любая мебель, бытовая техника становится ИМУЩЕСТВОМ только тогда, когда она фигурирует хотя бы в одном страховом договоре).

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

6. Задайте связи между сущностями. Для этого следует:

  •  установить курсор на нужной кнопке (идентифицирующая или неидентифицирующая связь) в палитре инструментов (смотри табл.1.2) и нажать левую кнопку мыши;
  •  щелкнуть сначала по родительской, а затем по дочерней сущности.

Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по связи и выбрать в контекстном меню пункт Relationship Properties (рис.1.7).

Рис. 1.7. Меню вызова редактора связи.

Во вкладке General появившегося диалога можно задать мощность, имя и тип связи (рис.1.8).

Рис. 1.8. Панель диалога редактора связей

Имя связи (Verb Phrase) – это фраза, характеризующая отношение между родительской и дочерней сущностями. Эти фразы (т.е. имена связей) можно взять непосредственно из связей, которые были получены при концептуальном проектировании.

Для всех связей кроме СТРАХОВОЙ ФАКТОР-СТРАХОВОЙ ДОГОВОР необходимо указать тип – неиндентифицирующая с указанием опции No Nulls.

Для связи СТРАХОВОЙ ФАКТОР-СТРАХОВОЙ ДОГОВОР необходимо указать тип связи – неиндентифицирующая с указанием опции  Nulls Allowed.

Мощность связи (Cardinality) для всех связей кроме СТРАХОВОЙ ФАКТОР-СТРАХОВОЙ ДОГОВОР выбирается один или многие (One or More). Для связи СТРАХОВОЙ ФАКТОР-СТРАХОВОЙ ДОГОВОР указывается мощность 0, 1 или многие.

Задание ограничений ссылочной целостности, а также указание ролей производится на закладке Rolename/RI Action панели диалога редактора связей (смотри рис.1.8).

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

Введем следующие имена ролей для связей:

  •  КЛИЕНТ-СТРАХОВОЙ ДОГОВОР – кто страхуется.
  •  АГЕНТ-СТРАХОВОЙ ДОГОВОР – кто предоставляет услуги страхования.
  •  ИМУЩЕСТВО-СТРАХОВОЙ ДОГОВОР – что страхуется.
  •  СТРАХОВАЯ УСЛУГА-СТРАХОВОЙ ДОГОВОР – от чего страхуется.
  •  СТРАХОВОЙ ФАКТОР-СТРАХОВОЙ ДОГОВОР – что снижает страховой риск.

Ограничения ссылочной целостности, задаваемые по умолчанию ERwin, в данном случае можно оставить без изменений.

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

Рис.1.9. Внесение связей в диаграмму

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

1. Сколько уровней имеет логическая модель данных в соответствии с нотацией IDEF1X?

2. Сколько уровней имеет физическая модель данных в соответствии с нотацией IDEF1X?

3. Какие работы выполняются на стадии «Проектирование» жизненного цикла базы данных?

4. Что такое диаграмма сущность-связь?

5. В чем цель диаграммы сущность-связь?

6. Какая связь называется идентифицирующей?

7. Какая связь называется неидентифицирующей?

8. Что включает в себя диаграмма сущность-связь?

9. Какие кнопки панели инструментов позволяют изменить уровень просмотра модели?

10. Как добавить сущность на диаграмму?

11. Что называется сущностью?

12. Сформулируйте принцип именования сущностей.

13. Что показывает взаимосвязь между сущностями?

14. Что такое мощность связи?

15. Что такое имя роли (функциональное имя)?

16. Опишите механизм проверки адекватности логической модели.

Самостоятельное задание

Добавьте в разработанную модель новые сущности: ФИЛИАЛ, СОТРУДНИК, АДМИНИСТРАТОР.  Сущности СОТРУДНИК, АДМИНИСТРАТОР, АГЕНТ образуют иерархию наследования. Сотрудник является обобщенной сущностью, а АДМИНИСТРАТОР и АГЕНТ – категориальными сущностями.


Тема 2. Разработка  модели данных, основанной на ключах

Основные цели

  •  Изучить методы определения ключевых атрибутов сущностей.
  •  Освоить инструментарий ERWin.

Теоретическая часть

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

Целью этой модели является дальнейшая детализация модели сущность-связь и идентификация сущностей путем выбора ключевых атрибутов (ключей).

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

В качестве первичных ключей могут быть использовано несколько атрибутов или групп атрибутов. Атрибуты, которые могут быть выбраны первичными ключами, называются кандидатами в ключевые атрибуты (потенциальные атрибуты).

Правила выбора первичного ключа:

  •  Уникальным образом идентифицировать экземпляр сущности.
  •  Не использовать NULL значений.
  •  Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.
  •  Быть как можно более короткими для использования индексирования и получения данных.

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

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

Суррогатный ключ – это произвольный номер, который уникальным образом определяет запись в сущности. Атрибут «Номер сотрудника» является примером суррогатного ключа.

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

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

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

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

Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления (INSERT, UPDATE или DELETE).

Например, между сущностями Агент и Филиал существует идентифициующая связь. Что будет, если удалить филиал? Экземпляр сущности Агент не может существовать без филиала (атрибут первичного ключа «В каком филиале работает/Номер филиала» не может принимать значение NULL); следовательно, нужно либо запретить удаление филиала, пока в ней числится хотя бы один агент.

Возможна установка следующих правил удаления (если таковые поддерживаются СУБД).

SET DEFAULT – при удалении записи атрибуту внешнего ключа присваивается значение по умолчанию. Например, при удалении филиала фирмы все агенты могут быть переведены в другой филиал.

NONE – при удалении записи значение атрибута внешнего ключа не меняется. Запись об агенте «повисает в воздухе», т. е. ссылается на несуществующий филиал. Такая ситуация характерна для «плоских» таблиц. Например, если информация об агентах и филиалах фирмы хранится в dbf-файлах, можно удалить запись о филиале, при этом файл агентов «ничего не будет знать» о том, что соответствующего филиала не существует. Поэтому в настольных или файл-серверных системах функциональность, обеспечивающая правила ссылочной целостности, реализуется в клиентском приложении.

RESTRICT – для удаления записи необходимо удалить все дочерние записи с внешним ключом, равным первичному ключу удаляемой записи. Например, для удаления филиала сначала нужно удалить всех агентов этого филиала.

CASCADE. – при удалении опорного экземпляра сущности (соответствующего концу связи «один») нужно удалить и все экземпляры сущности, соответствующие концу связи «многие». Например,  вместе с филиалом фирмы будут удаляться  все агенты данного филиала.

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

Учебное задание

Создайте модель данных, основанной на ключах, филиала страховой фирмы, используя диаграмму сущность-связь, разработанную на предыдущем уроке.

Технология выполнения учебного задания

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

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

1.1. Сведения об агенте должны включать фамилию, инициалы и учетный номер агента – они и будут атрибутами сущности АГЕНТ. Будем считать, что учетный номер личного дела агента  содержит только цифры, т.е. он не будет слишком большим  и его можно использовать в качестве первичного ключа.

1.2. Сведения о клиенте должны состоять из его фамилии, имени, отчества и номера его паспорта. Очевидно, что они и будут атрибутами сущности КЛИЕНТ. Первичным ключом можно было бы выбрать номер паспорта, поскольку он однозначно идентифицирует любой из экземпляров этой сущности. Однако номер паспорта не является числом, т. к., кроме цифр, содержит и буквы, и, следовательно, для его хранения будет использоваться строка минимум из 13 символов, что не совсем удобно. Поэтому введет для каждого КЛИЕНТА уникальный номер: Код Клиента(CodClient, Number), который и будет первичным ключом. Атрибут Паспорт (номер паспорта клиента) можно сделать альтернативным ключом, чтобы обеспечить возможность быстрого поиска информации о договорах по его значениям, согласно заданию.

1.3. По тем же соображениям сущность ИМУЩЕСТВО будет содержать дополнительный атрибут – Код имущества (CodProp, Number),,  который и будет первичным ключом.

1.4. Что касается сущности СТРАХОВОЙ ДОГОВОР, то часть атрибутов она унаследует от родительских сущностей и остается лишь добавить следующие: «Дата страхования»,  «Страховая сумма». Очевидно, что первичным ключом следует выбрать уникальный атрибут «Код договора» (Cod Number). Поскольку в задании сказано, что создаваемая система должна позволять вычислить денежный оборот за один или несколько дней, то полезно было бы сделать атрибут «дата сделки» инверсным входом, т. к. он довольно часто будет использоваться для доступа к данным.

1.5. Для сущностей СТРАХОВОЙ ФАКТОР, СТРАХОВАЯ УСЛУГА  необходимо также добавить дополнительные атрибуты, Код фактора (CodFact, Number), Код услуги (CodServ, Number), которые и будут играть роль первичных ключей.

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

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

Для задания альтернативных ключей следует воспользоваться редактором ключей. Переход в него осуществляется так же, как и в редактор атрибутов, но с помощью команды Key Group Editor. Общий вид этого редактора показан на рис. 2.1.

Рис. 2.1. Панель диалога редактора ключей

2. Для задания первичного ключа выделите строку Primary Key  и с помощью стрелок переместите в окно Key Group Member  соответствующий атрибут.

3. Для задания альтернативных ключей требуется добавить строки альтернативного ключей в окне Key Group. Для этого нажмите на кнопку New и выберите в открывшемся окне альтернативный ключ.

На этом процесс создания второго уровня логической модели завершается, а сама модель приобретает вид, представленный на рис 2.2.

Рис.2.2. Логическая модель с атрибутами

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

1. Что называется первичным ключом?

2. Назовите принципы, согласно которым формируется первичный ключ.

3. Что называется альтернативным ключом?

4. Что называется инверсионным входом?

5. В каком случае образуются внешние ключи?

6. Что такое модель данных, основанная на ключах?

7. В чем цель модели данных, основанной на ключах?

8. Назовите правила ссылочной целостности?

9. Что такое триггеры?

Самостоятельное задание

Создайте ключевые атрибуты для новых сущностей: ФИЛИАЛ, СОТРУДНИК, АДМИНИСТРАТОР.


Тема 3. Создание полной атрибутивной модели базы данных

Основные цели

  •  Ознакомиться с технологией построения атрибутивной модели.
  •  Изучить способы перевода БД в первую, вторую и третью нормальную форму.

Теоретическая часть

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

Нормализация

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

  •  первая нормальная форма (1NF);
  •  вторая нормальная форма (2NF);
  •  третья нормальная форма (3NF);
  •  нормальная форма Бойса-Кодда (усиленная 3NF);
  •  четвертая нормальная форма (4NF);
  •  пятая нормальная форма (5NF).

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

Функциональная зависимость (FD). Атрибут В сущности Е функционально зависит от атрибута А сущности Е тогда и только тогда, когда каждое значение атрибута А сущности Е связало с ним точно одно значение атрибута В сущности Е, т. е. А однозначно определяет В.

Полная функциональная зависимость. Атрибут В сущности Е полностью функционально зависит от ряда атрибутов А сущности Е тогда и только тогда, когда В функционально зависит от А и не зависит ни от какого подряда А.

Рассмотрим нормальные формы.

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

Для приведения сущности к первой нормальной форме следует:

  •  разделить сложные атрибуты на атомарные;
  •  создать новую сущность;
  •  перенести в нее все «повторяющиеся» атрибуты;
  •  выбрать возможный ключ для нового РК (или создать новый РК);
  •  установить идентифицирующую связь от прежней сущности к новой, РК прежней сущности станет внешним ключом (FK) для новой сущности.

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

Для приведения сущности ко второй нормальной форме следует:

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

Третья нормальная форма (3NF). Сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть взаимозависимости между неключевыми атрибутами).

Для приведения сущности к третьей нормальной форме следует:

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

Поддержка нормализации в ERwin. ERwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных имен атрибутов в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила «один факт – в одном месте». Имена ролей атрибутов внешних ключей и унификация атрибутов также облегчают построение нормализованной модели.

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

В результате нормализации все взаимосвязи данных становятся правильно определенными, исключаются аномалии при оперировании данными, модель данных становится легче поддерживать. Однако часто нормализация данных не ведет к повышению производительности ИС в целом. Например, для получения полной информации, о сотруднике из ненормализованной структуры данных достаточно обратиться к одной таблице. После приведения структуры данных к третьей нормальной форме информация о сотруднике может содержаться уже в четырех таблицах. Хотя общее количество строк в этих таблицах может быть меньше, чем в исходной (до нормализации), теперь для получения полной информации о сотруднике серверу базы данных необходимо обращаться одновременно к четырем таблицам (объединение таблиц, join). Время выполнения запроса с объединением может во много  раз превосходить время выполнения запроса к одной таблице; другими словами, в приведенном примере общая производительность ИС в результате нормализации, скорее всего, упадет. В целях повышения производительности при переходе на физический уровень приходится сознательно отходить от нормальных форм для того, чтобы использовать возможности конкретного сервера или ИС в целом.

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

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

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

Учебное задание

Создайте полную атрибутивную модель филиала страховой фирмы на основе диаграммы сущность-связь и модели данных, основанная на ключах, разработанных ранее.

Технология выполнения учебного задания

1. На рис. 3.2 атрибут Телефон может содержать несколько рабочих телефонов, что является нарушением ограничения первой нормальной формы. Запись значения колонки через разделитель, например «92-61-98, 92-16-79, 25-55-66» приводит к ряду проблем. Размера поля может не хватить для хранения данных (нельзя увеличивать список телефонов до бесконечности), по такой колонке невозможно построить индекс и т. д. и т. п. Для приведения сущности к первой нормальной форме выполним следующие действия.

2. Разделим сложный атрибут Телефон сущности КЛИЕНТ на атомарные Телефон Клиента, а атрибут Телефон сущности АГЕНТ – на Телефон Агента.

3. Создадим две новых сущности ТЕЛЕФОН КЛИЕНТА и ТЕЛЕФОН АГЕНТА.

4. В каждую из них перенесем атомарные атрибуты Телефон Клиента (PhoneCl, String) и Телефон агента (PhoneAgent, String), соответственно. Сделаем данные атрибуты первичным ключом вновь созданных сущностей.

5. Установим связи:

  •  АГЕНТ-ТЕЛЕФОН АГЕНТА – идентифицирующая, 0,1 or More,
  •  КЛИЕНТ-ТЕЛЕФОН КЛИЕНТА – идентифицирующая, 0,1 or More.

На рис. 3.1 логическая модель, приведенная к первой нормальной форме.

Рис. 3.1. Полная атрибутивная модель базы данных

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

1. Что называется процессом нормализации?

2. Что называется функциональной зависимостью?

3. Что называется полной функциональной зависимостью?

4. Первая нормальная форма.

5. Вторая нормальная форма.

6. Третья нормальная форма.

7. Что называется процессом денормализации?

8. В чем смысл денормализации?

9. Что такое полная атрибутивная модель?

10. Что называется транзитивной зависимостью?

11. Как перевести сущность из первой нормальной формы во вторую?

12. Как перевести сущность из второй нормальной формы в третью?

Самостоятельное задание

Создайте полную атрибутивную модель филиала страховой фирмы на основе диаграммы сущность-связь и модели данных, основанная на ключах, разработанных в самостоятельном задании темы 2.


Тема 4. Создание физического уровня модели

Основные цели

  •  Освоить процедуру создания трансформационной модели.
  •  Научиться генерировать из трансформационной модели модель СУБД.

Теоретическая часть

На стадии реализации создаются физическая модель. Существует два уровня физических моделей: трансформационная модель (Transformation Model) и модель СУБД.

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

Целью трансформационной модели является предоставление информации администратору БД для создания эффективной структуры хранения, включающей в себя записи, формирующие БД. Трансформационная модель должна помочь разработчикам выбрать структуру хранения данных и реализовать систему доступа к ним.

Перед началом проектирования БД необходимо убедиться в обеспечении следующих требований:

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

Модель СУБД напрямую транслируется из трансформационной модели, являясь отображением системного каталога. ERWin напрямую поддерживает эту модель через функцию генерации схемы БД. При составлении схемы БД в качестве индексов могут использоваться как ключевой атрибут, так и остальные поля БД.

Физический уровень модели зависит от выбранного сервера. Для выбора СУБД служит редактор Target Server (меню Server/ Target Server доступно только на физическом уровне).

Рис. 4.1. Панель выбора сервера СУБД

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

Диалог Target Server позволяет задать тип данных и опцию NULL для новых колонок, а также правила ссылочной целостности, принимаемые по умолчанию. Тип данных можно выбрать в раскрывающемся списке Default Access Datatype, который автоматически заполняется типами данных, поддерживаемых выбранным сервером.

Группа кнопок Default Non-Key Null Option позволяет разрешить или запретить значения NULL для неключевых колонок.

При смене СУБД ERwin предлагает автоматически преобразовать тип данных каждой колонки на доступный тип новой СУБД. Правила соответствия типов могут быть заданы предварительно (см. 4.1). Для автоматического преобразования следует в ответ на запрос нажать Yes.

Таблицы, колонки и представления (view)

ERwin автоматически создает имена таблиц и колонок на основе имен соответствующих сущностей и атрибутов, учитывая максимальную длину имени и другие синтаксические ограничения, накладываемые СУБД. При генерации имени таблицы или колонки по умолчанию все пробелы автоматически преобразуются в символы подчеркивания, а длина имени обрезается до максимальной длины, допустимой для выбранной СУБД. Все изменения, сделанные в редакторах Tables или Columns, не отражаются на именах сущностей и атрибутов, поскольку информация на логическом и физическом уровнях в ERwin хранится отдельно.

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

Рис.4.2. Диалог Tables

Окно Name служит для задания имени текущей таблицы. Окно Owner позволяет внести имя владельца таблицы, отличное от имени пользователя, производящего генерацию схемы базы данных. Окно выбора Physical Only служит для создания объектов только на физическом уровне. Если выбрана опция Generate, при генерации схемы базы данных будет выполняться команда CREATE TABLE. Кнопка DB Sync служит для немедленной синхронизации модели с системным каталогом базы данных. Диалог Tables содержит следующие закладки:

  •  Comment. Внесение комментария к таблице.
  •  Volumetrics. Служит для оценки размера базы данных.
  •  UDP. Задание свойств, определяемых пользователем.
  •  Validation. Задание правил валидации.

Для задания свойств колонок, отличных от значения по умолчанию, служит редактор Columns (рис. 4.3). Чтобы вызвать его, нужно щелкнуть правой кнопкой мыши по таблице и выбрать во всплывающем меню пункт Columns.

По умолчанию ERwin присваивает режимы нулевых значений всем неключевым колонкам, исходя из значений по умолчанию, устанавливаемых редакторе Target Server. Для колонок первичного ключа и альтернативных ключей устанавливается режим NOT NULL. Режим NOT NULL не присваивается автоматически инверсионным входам (Inversion Entry).

Рис. 4.3. Диалог Columns

Внешне диалог Columns напоминает диалог Attributes. В правой части диалога находятся закладки:

  •  General. Позволяет поставить в соответствие колонке определенный домен, создать колонку только на физическом уровне и включить ее в состав первичного ключа.
  •  Закладка, соответствующая выбранной СУБД. Имя закладки устанавливается автоматически соответствующей выбранной СУБД. Позволяет задать тип данных, опцию NULL, правила валидации и значение по умолчанию. Правила валидации и значение по умолчанию должны быть описаны и именованы предварительно соответственно в диалогах Valid и Default.
  •  Comment. Служит для внесения комментария к каждой колонке.
  •  UDP. Задание свойств, определяемых пользователем.
  •  Index. Служит для включения колонки в состав индексов.

В левой части диалога содержится упорядоченный список колонок таблицы. Навигационные кнопки предназначены для перемещения колонки в списке на позицию вверх и вниз. Кнопки New, Rename и Delete служат соответственно для создания, переименования и удаления колонки. При помощи кнопки Reset можно переустановить свойства колонки, заданные вручную, на значения по умолчанию. Кнопка PB Sync позволяет запустить процесс синхронизации модели с системным каталогом базы данных.

Прямое и обратное проектирование

Процесс генерации схемы базы данных из модели данных называетеся прямым проектированием (Forward Engineering). При генерации схемы ERwin включает триггеры ссылочной целостности, хранимые процедуры индексы, ограничения и другие возможности, доступные при определении таблиц в выбранной СУБД. Процесс генерации модели из схемы базы данных называется обратным проектированием (Reverse Engineering). ERwin позволяет создать модель данных путем обратного проектирования имеющейся базы данных. После того как модель создана, можно переключиться на другой сервер (модель будет конвертирована) и произвести прямое проектирование структуры базы данных для другой СУБД. Кроме режима прямого и обратного проектирования ERwin поддерживает синхронизацию между моделью и системным каталогом СУБД на протяжении всего жизненного цикла создания ИС.

Для генерации системного каталога базы данных следует выбрать пункт меню Tools/Forward Engineer/Schema Generation или нажать кнопку  на панели инструментов. Появляется диалог Schema Generation (рис. 4.4). Диалог Schema Generation имеет 3 закладки:

  •  Options. Служит для задания опций генерации объектов базы данных – триггеров, таблиц, представлений, колонок, индексов и т. д. Для задания опций генерации какого-либо объекта следует выбрать объект в левом списке закладки, после чего включить соответствующую опцию в правом списке.
  •  Summary. Служит для отображения всех опций, заданных во вкладке Options. Список опций в Summary можно редактировать так же, как и в Options.
  •  Comment. Позволяет внести комментарий для каждого набора опций.

Каждый набор опций может быть именован (окно Option Set, New, Rename и Delete) и использован многократно.

Кнопка Preview вызывает диалог Schema Generation Preview (рис. 4.4) в котором отображается SQL-скрипт, создаваемый ERwin для генерации системного каталога СУБД. Нажатие на кнопку Generate приведет к запуску процесса генерации схемы.

Кнопка Print диалога Schema Generation предназначена для вывода на печать создаваемого ERwin SQL-скрипта.

Кнопка Report сохраняет тот же скрипт в ERS- или SQL-текстовом файле. Эти команды можно в дальнейшем редактировать любым текстовым редактором и выполнять при помощи соответствующей утилиты сервера.

Кнопка Generate запускает процесс генерации схемы. Возникает диалог связи с базой данных, устанавливается сеанс связи с сервером-базы данных, и начинает выполняться SQL-скрипт. При этом возникает диалог Generate Database Schema.

Рис. 4.4. Диалог Schema Generation Preview

По умолчанию в диалоге Generate Database Schema включена опция Stop If Failure. Это означает, что при первой же ошибке выполнение скрипта прекращается. Щелкнув по кнопке Continue, можно продолжить выполнение. Кнопка Abort прерывает выполнение. При выключенной опции Stop If Failure скрипт будет выполняться, несмотря на встречающиеся ошибки.

Для выполнения обратного проектирования следует выбрать пункт меню Tools/Reverse Engineer.

Возникает диалог Reverse Engineer – Select Template, в котором нужно выбрать шаблон диаграммы, затем диалог выбора СУБД и, наконец, диалог задания опций обратного проектирования Reverse Engineer – Set Options.

Учебное задание

Создайте физическую модель базы данных филиала страховой фирмы на основе логической модели, разработанную ранее.

Технология выполнения учебного задания

1. Перед тем как приступить к созданию физической модели, необходимо выбрать сервер СУБД. Для этого нужно перейти к уровню физической модели. Затем выполнить команду Server/Target Server либо нажать соответствующую кнопку на панели инструментов. Вид панели диалога, позволяющей выбрать сервер СУБД., приведен на рис. 4.1.

Выберите на панели тип сервера ACCESS 97 и нажмите кнопку ОК. ERwin предлагает автоматически преобразовать тип данных каждой колонки на доступный для новой СУБД. Для автоматического преобразования следует в ответ на запрос нажать Yes.

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

Для задания английских имен таблиц необходимо воспользоваться редактором таблиц, для остальных манипуляций – редактором колонок. Вызов любого их них можно осуществить при помощи всплывающего меню. Диалоговое окно редактора колонок показано на рис. 4.3.

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

Последним шагом является генерация схемы БД. Все необходимые параметры можно задать на предназначенной для этого панели диалога (рис. 4.5). Нажатие кнопки Preview позволяет просмотреть код, который будет автоматически создан ERWin. Генерация схемы БД запускается с помощью кнопки Generate. В процессе генерации ERWin связывается с БД, выполняя SQL-скрипт. Если в процессе генерации возникают какие-либо ошибки, то она прекращается, открывается окно с сообщениями об ошибках.

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

1. Для чего нужна трансформационная модель?

2. От чего зависит физический уровень модели БД?

3. Как называется процесс генерация схемы базы данных из модели данных?

4. Как называется процесс генерации модели  данных из схемы базы данных?

Рис. 4.5. Физическая модель

Самостоятельное задание

Создайте физическую модель базы данных филиала страховой фирмы на основе логической модели, разработанную в самостоятельном задании темы 3.


Тема 5. Отчеты в ERWin

Основные цели

  •  Изучить виды отчетов.
  •  Освоить процедуру создания отчетов.
  •  Изучить экспортирование, сохранение и печать отчетов.

Теоретическая часть

Для генерации отчетов в ERwin имеется простой в использовании инструмент – Report Browser. Он позволяет выполнять предопределенные отчеты (объединенные по типам), сохранять результаты их выполнения, создавать собственные отчеты, печатать и экспортировать их в распространенные форматы.

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

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

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

Диалоговое окно имеет собственное меню и панели инструментов (табл. 5.1, табл. 5.2).

Таким образом, в левой части Report Browser содержатся предварительно определенные отчеты, позволяющие наглядно представить информацию об основных объектах модели данных, как логической, так и физической. Для выполнения отчета достаточно дважды щелкнуть по нему в дереве отчетов или щелкнуть по соответствующей кнопке на панели инструментов. Результат выполнения отчета будет отображен в правом окне диалога Report Browser. Иконка результирующего набора будет также добавлена в дерево отчетов. В левом нижнем окне Report Browser отображается комментарий к отчету (вносится в диалоге ERwin Report Editor).

 


Таблица 5.1

Кнопки панели инструментов диалогового окна Report Browser

Кнопка

Назначение

Создание нового отчета или папки

Печать отчета

Просмотр результата выполнения отчета

Выполнение отчета

Фиксация изменений (для редактируемого отчета)

Поиск элементов отчета: задание условий поиска, поиск следующей строки и поиск другого отчета, соответствующего строке

Включение и выключение дерева отчетов

Показывает список отчетов в том порядке, в котором они создавались

Переход к следующему отчету

Выбор колонок и сортировка полученного отчета

Связь отчета с иконкой

Сохранение отчета в виде представления

Таблица 5.2

Кнопки нижней панели инструментов

Кнопка

Назначение кнопки

Редактировать выделенный отчет

Удалить отчет

Показать только верхний уровень дерева

Сделать выбранную папку корнем дерева (показать только выбранную ветвь дерева)

Сделать корнем дерева родительскую папку (по отношению к выбранной)

Учебное задание

Создайте встроенным средством Report Browser:

  •  стандартные (предварительно-определенные) отчеты;
  •  отчеты, проверяющие правильность построения модели;
  •  нестандартный отчет.

Технология выполнения учебного задания

1. Вызовите диалоговое окно Report Browser (рис. 5.1) командой Task, Generate Report или нажав кнопку Report Browser () на панели инструментов.  

Рис. 5.1. Диалоговое окно Report Browser

2. Создайте предварительно определенный отчет. Для этого щелкните по папке ERwin Reports. Далее откройте папку Entity reports и выберите в ней отчет Entity/Definition/Table/Attribute/Column/PK/FK/Relationships. Дважды щелкните по строке. В результате получите стандартный предварительно определенный отчет, содержащий сущности, определения, таблицы, атрибуты и т.п.

3. Отредактируем полученный отчет. Для этого щелкнем правой кнопкой мыши по строке Entity/Definition/Table/Attribute/Column/PK/FK/Relationships в левой части окна Report Browser. В открывшемся меню выберем Edit report format.

В открывшемся окне (рис. 5.2) уберем метки с позиций:

  •  Entity Type,  
  •  Entity Attribute Is PK,
  •  Entity Attribute Is FK,
  •  Entity Attribute Column Is PK,
  •  Entity Attribute Column Is FK,
  •  Entity Child Relationship Child to Parent Phrase,  
  •  Entity Parent Relationship Child to Parent Phrase,
  •  Entity Table Owner.

Рис. 5.2. Диалоговое окно Report Format

4. После этого мы можем посмотреть (Preview result set) либо распечатать  либо сохранить отчет в формате CSV (текстовый файл), HTML, DDE (экспорт в MS Word или MS Exel) и т.п.

5. Рассмотрим группу отчетов, проверяющих правильность построения модели. Эти отчеты в диалоговом окне Report Browser носят название Model Validation Reports, исполнение которых может быть полезным для нахождения ошибок в моделях. Выполним некоторые из них и рассмотрим полученные результаты, сведя их в табл. 5.3.

Скорректируем модель согласно найденным ошибкам.

6. Для создания нового отчета (т.е. нестандартного) необходимо выбрать в меню панели Report Browser пункт File, New или щелкнуть на кнопке , панели  инструментов.

7. В появившемся диалоговом окне Report Editor (рис. 5.3) в поле Name ввести имя отчета. Поле Category предназначено для указания категории отчета, т.е. типа объектов, по которым будет создаваться отчет (атрибуты, диаграммы, сущности, домены, связи и т.д.).

Таблица 5.3

Отчеты, проверяющие правильность построения модели

Отчет

Результат

Отчет «Сущности без атрибутов» (Entities without attributes)

Пустой отчет, т. е. сущности без атрибутов в модели нет

Отчет «Таблицы без первичного ключа» (Tables without PK)

Пустой отчет, т. е. все таблицы в физической модели имеют первичный ключ

Отчет «Сущности без первичного ключа» (Entities without PK)

То же

Отчет «Колонки с различным типом внешнего ключа» (Columns with different FK datatype)

То же

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

9. Щелкнуть по кнопке ОК, после чего отчет будет добавлен в диалоговое окно Report Browser.

10. Выполнить отчет, нажав на кнопку на панели инструментов.

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

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

Рис. 5.3. Диалоговое окно Report Editor

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

1. Каково назначение инструмента Report Browser?

2. Назовите основные элементы окна Report Browser.

3. Как создать новый отчет?

4. Как связать отчет с иконкой?

5. Как выполнить существующий отчет?

6. Что такое представление отчета и для чего оно предназначено?

7. Как сохранить отчет в виде представления?

8. Какие категории отчетов присутствуют в Report Browser по умолчанию?

9. В какие форматы можно экспортировать отчет?

10. Как отредактировать отчет?

11. Какой тип отчета позволяет проверить отсутствие ошибок в модели?

12. Опишите механизм поиска ошибок в модели при помощи отчетов?

Самостоятельное задание

Создайте встроенным средством Report Browser для модели, полученной в самостоятельном задании темы 4:

  •  отчет по всем сущностям и их атрибутам,
  •  отчет о таблицах физической модели.


Приложение 1. Методология моделирования данных IDEF1X

Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу AS IS.

Основным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая, несомненно, является значительным недостатком ER.

На стадии проектирования создаются логические модели трех уровней:

  •  Entity Relation Diagram (Диаграмма сущность-связь).
  •  Key-Based model (Модель данных, основанная на ключах).
  •  Полная атрибутивная модель.  

Диаграмма сущность-связь

Диаграмма сущность-связь определяет сущности и их отношения. Диаграмма сущность-связь (ERDEntity Relationship Diagram) является самым высоким уровнем в модели данных. Она определяет набор сущностей и атрибутов проектируемой системы. Целью этой диаграммы является формирование общего взгляда на систему для ее дальнейшей детализации.

ERD-диаграммы можно подразделить на отдельные куски, соответствующие отдельным задачам, решаемым проектируемой системой. Это позволяет рассматривать систему с точки зрения функциональных возможностей, делая процесс проектирования управляемым.

Сущность

Сущность – это физическое представление логической группировки объектов, называемых экземплярами.

Сущность – это субъект, место, вещь, событие или понятие, содержащие информацию. Сущности могут быть вещественными, реальными объектами, такими как КЛИЕНТ или ШКАФ, или неосязаемыми концептуальными абстракциями как ЦЕНТР ЗАТРАТ или МЫСЛЬ. Сущности не предназначены для представления единичного объекта, они представляют набор экземпляров, содержащих информацию, представляющую интерес с точки зрения их уникальности. Например, сущность КЛИЕНТ представляет собой экземпляр объектов типа Клиент. Иван Иванов и Савелий Краморов – конкретные примеры экземпляров сущности КЛИЕНТ. Конкретный экземпляр сущности представляется строкой таблицы и идентифицируется первичным ключом.

Сущность имеет следующие признаки:

  •  Она имеет имя и описание.
  •  Она представляет класс, а не единичный экземпляр абстракции.
  •  Ее конкретные представители (экземпляры) могут быть уникально идентифицированы.
  •  Она содержит логическую группировку атрибутов, представляющих информацию, интересную с точки зрения корпорации

В диаграммах ER-модели сущность представляет в виде прямоугольника, содержащего имя сущности. При этом имя сущности — это имя типа, а не конкретного объекта. Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности.

Сущность необходимо именовать существительным в единственном лице и записывать заглавными буквами.

Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира. Примером сущности IDEF1X может быть сущность «СОТРУДНИК», которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущности.

И зависимые, и независимые сущности можно разделить на следующие типы:

  •  Стержневые сущности – их иногда называют основными или первичными сущностями. Они представляют важные объекты, информацию о которых следует хранить.
  •  Коды/ссылки/классификаторы – эти сущности содержат строки, определяющие набор значений или область определения для атрибута.
  •  Ассоциативные сущности – эти сущности используются для разрешения отношений многие-ко-многим.
  •  Характеристические сущности – эти сущности бывают двух типов: исключающие и включающие.

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

Стержневые сущности могут быть как независимыми, так и зависимыми. Например, для корпорации, торгующей телевизорами, сущность ТЕЛЕВИЗОР представляет базовый продукт корпорации. Сущность МАГАЗИН является примером канала сбыта или посредника при продаже товара. Хотя пример может показаться несколько прямолинейным, он иллюстрирует всю мощь концепции, лежащей в основе моделирования стержневых сущностей.

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

Кодовые сущности всегда являются независимыми. Их часто называют ссылками, классификаторами или сущностями типов, в зависимости от используемой методологии. Уникальные экземпляры, представляемые кодовыми сущностями, определяют область определения для значений атрибутов, принадлежащих другим сущностям. Отношения между кодовыми сущностями и другими сущностями будут рассмотрены в одной из следующих публикаций на эту тему. У вас может возникнуть искушение использовать единственный атрибут в кодовой таблице. Гораздо лучше включать, по меньшей мере, три атрибута в кодовую сущность: идентификатор, имя (иногда его называют кратким именем) и определение.

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

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

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

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

Именующая сущность — это частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа).

Характеристические сущности всегда являются зависимыми. Вы должны использовать характеристические сущности там, где для экземпляров сущностей имеет смысл хранить различные наборы атрибутов. Финклештейн называет характеристические сущности вторичными сущностями. Характеристические сущности всегда имеют одну или более «равноправных» сущностей. Равноправные характеристические сущности связаны с родительской сущностью особым типом отношений, которые могут быть исключающими или включающими.

Равноправные характеристические сущности, которые находятся в исключающем отношении к родительской сущности, указывают на то, что только одна из равноправных сущностей содержит экземпляр для любого из экземпляров родительской сущности. Исключающая характеристическая сущность представляет отношение "является" (is a).

Например, в страховой фирме работают служащие, работающие в офисе полный рабочий день (администраторы) и агенты, у которых график работы и оплаты организуются более гибко. Из их общих свойств можно сформировать обобщенную сущность (родовой предок) Сотрудник, чтобы представить информацию, общую для всех типов служащих. Специфическая для каждого типа информация может быть расположена в категориальных сущностях (потомках) «Постоянный сотрудник» и «Агент».

Обратите внимание, что экземпляр СОТРУДНИК должен быть АДМИНИСТРАТОРОМ или АГЕНТОМ. СОТРУДНИК не может быть одновременно и АДМИНИСТРАТОРОМ и АГЕНТОМ. Это исключающие характеристические сущности.

Заметьте, что исключающие характеристические сущности не позволят одному экземпляру СОТРУДНИК содержать факты, общие для АДМИНИСТРАТОРА и АГЕНТА. Это может противоречить реальной практике. АДМИНИСТРАТОР тоже может выступать в качестве АГЕНТА. Это пример включающих характеристических сущностей.

Разновидность характеристической сущности – это категориальная сущность. Категориальная сущность – это дочерняя сущность в иерархии наследования характеристической сущности. Иерархия наследования (или иерархия категорий) представляет собой особый тип объединения сущностей, которые разделяют общие характеристики.

Обычно иерархию наследования создают, когда несколько сущностей имеют общие по смыслу атрибуты, либо когда сущности имеют общие по смыслу связи (например, если бы «ПОСТОЯННЫЙ СОТРУДНИК» и «СОВМЕСТИТЕЛЬ» имели сходную по смыслу связь «работает в» с сущностью ФИРМА), либо когда это диктуется бизнес-правилами.

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

Рис. П1. Иерархия наследования: полная категория

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

Рис. П2. Иерархия наследования: неполная категория

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

Для создания категориальной связи следует:

  •  установить курсор на кнопке «Категория» в палитре инструментов и нажать левую кнопку мыши;
  •   щелкнуть сначала по родовому предку, а затем по потомку;
  •  для установления второй связи в иерархии категории следует сначала щелкнуть по символу категории, затем по второму потомку.

Для редактирования категорий нужно щелкнуть правой кнопкой мыши по символу категории и выбрать в контекстном меню пункт Subtype Relationship Editor. В диалоге Subtype Relationship можно указать атрибут-дискриминатор категории (список Discriminator Attribute Choice) и тип категории – полная/неполная (радио-кнопки Complete/Incomplete).

Структурная сущность. Иногда экземпляры одной и той же сущности связаны. В К. Финклештейн своей книге «Strategic Systems Development» предложил использовать структурные сущности для представления отношений между экземплярами одной и той же сущности. Связи между экземплярами одной и той же сущности называются рекурсивными отношениями. Рекурсивные отношения будут рассмотрены в статье «Понятие отношения». Рекурсивные отношения – это логическая концепция, а концепции не легко воспринимаются пользователями.

На рис. П3 показана дополнительная структурная сущность, описывающая отношение между экземплярами сущности СОТРУДНИК.

Диаграмма  моделирует отношения субординации между сотрудниками любой сложности. Поскольку отношение субординации связывает всегда двух людей, от сущности Сотрудник к сущности отношения субординации установлены две идентифицирующие связи с именами ролей «Руководитель» и «Подчиненный». Каждый сотрудник может быть в отношениях «руководит/подчиняется» с любым другим сотрудником, но одну и ту же пару сотрудников может связывать один тип отношений субординации. Сущность Отношение субординации представляет отношение между экземплярами сущности СОТРУДНИК.

Рис. П3. Структурная сущность.

Именование сущностей

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

Вероятно, у вас в корпорации есть набор соглашений об именовании, используемых в ходе разработки или при формировании корпоративной модели данных, которыми вы руководствуетесь. Использование соглашений гарантирует, что имена конструируются единообразно в рамках корпорации, вне зависимости от того, кто конструирует имя

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

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

  •  Имя сущности должно быть достаточно описательным. Используйте имена из одного слова, только когда они являются названием широко распространенных концепций. Подумайте об использовании словосочетаний на основе существительных.
  •  Имя сущности должно быть существительным или словосочетанием на основе существительного в единственном числе. Используйте ПЕРСОНА вместо ПЕРСОНЫ или ЛЮДИ, и КОНТЕЙНЕР – вместо КОНТЕЙНЕРЫ.
  •  Имя сущности должно быть уникальным. Использование одинаковых имен для сущностей, содержащих различные данные, или разных имен для сущностей, содержащих одинаковые данные, будет без необходимости вводить в заблуждение разработчиков и конечных пользователей.
  •  Имя сущности должно указывать на данные, которые будут храниться в каждом из экземпляров.
  •  Имя сущности не должно содержать специальных символов (таких как !, @, #, $, %, &, * и тому подобных) или указывать на принадлежность (МОРОЖЕНОЕ ПЕРСОНЫ).
  •  Имя сущности не должно содержать акронимов или аббревиатур, если только они не являются частью принятых соглашений об именовании.

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

Таблица П1

Примеры имен сущностей с объяснениями

Хорошее имя

Неудачное имя

Пояснение

МАТЕМАТИЧЕСКАЯ ФОРМУЛА

ФОРМУЛА

ФОРМУЛА – слишком расплывчато, добавление прилагательного МАТЕМАТИЧЕСКАЯ значительно проясняет смысл.

КНИГА

КНИГИ

КНИГА – существительное в единственном числе.

СОФА

КУШЕТКА

СОФА

.

СОФА и КУШЕТКА имеют одинаковый смысл. Выберите что-то одно

МОРОЖЕНОЕ

КАКОЕ-ТО МОРОЖЕНОЕ

Местоимение КАКОЕ-ТО не привносит дополнительного значения или смысла к термину. Избегайте излишних дополнений.

ФОТОСНИМОК

ИЗОБРАЖЕНИЕ

ФОТОСНИМОК – достаточно определенно. ИЗОБРАЖЕНИЕ – несколько расплывчато.

ОЖИДАЕМОЕ ВРЕМЯ ПРИБЫТИЯ

ОВП

Аббревиатура ОВП может оказаться непонятной для пользователей.

КОМПАНИЯ

КОМПАНИЯ XYZ

XYZ – конкретный экземпляр компании и должен быть строкой в сущности КОМПАНИЯ.

Описание сущностей

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

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

Описание сущности должно объяснять ее смысл, а не то, как будет использоваться информация этой сущности. Вы должны собирать описания сущностей во время идентификации сущностей. Будьте осторожны при включении информации об использовании: подобная информация должна использоваться только в качестве примера или для пояснения. Способ использования информации изменяется более часто, чем информация сама по себе, поэтому информация об использовании непостоянна.

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

В табл. П2 содержится примеры плохих описаний сущности ПЕРСРНА.

Таблица П2

Описания сущностей с пояснениями

Неудачное описание

Пояснение

Клиент или сотрудник.

Хорошее описание включает определение сущности и ее значение для корпорации.

Включает имя, дату рождения и т.п. для персоны.

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

Информация о клиентах
и сотрудниках.

Клиент и сотрудник являются примерами ролей, в которых может выступать ПЕРСОНА. Использование одних только примеров не объясняет, что сущность собой представляет и почему она важна для корпорации.

Сущность содержит символы и числовые данные, извлеченные  

из POS (Point Of Sale – торговый терминал), хранящиеся с использованием стандартного сжатия и упакованных десятичных чисел.

Данный искусственный пример призван проиллюстрировать, что технические описания и аббревиатуры с трудом понимаются бизнес-пользователями.

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

Атрибут

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

Атрибут является логическим представлением фактов, данные о которых корпорация заинтересована хранить.

В ERwin сущности служат для визуального представления логической группировки атрибутов. С другой стороны, атрибуты представляют факты, накапливаемые о сущностях в логической модели. Атрибуты представляют собой факты, которые служат для идентификации, характеристики отнесения к категории, числового представления или другого вида описания состояния экземпляра сущности.

Атрибут должен представлять единственную концепцию. Атрибуты формируют логические группы, описывающие каждый экземпляр сущности. Конкретным экземпляром атрибута является значение. Например, атрибут с названием Имя определяет область определения для фактов о сущности с названием КЛИЕНТ. Гаврилов, Р.Д., Петр и Ваня – примеры конкретных значений Имени для конкретных экземпляров ПЕРСОНЫ. Конкретные значения для каждого из атрибутов сущности представляют единственный экземпляр.

Корректная модель атрибута обладает следующими признаками.

  •  Значение атрибута представляет интерес для корпорации.
  •  В логической модели присутствует единственный экземпляр атрибута.
  •  Атрибут имеет логический тип данных и область определения.
  •  Значение атрибута определяется как требуемое или необязательное.
  •  Атрибут имеет имя и описание.

Для каждого экземпляра сущности может использоваться только одно значение.

С чего начинать процесс выявления атрибутов? Большинство атрибутов выявляются в ходе рабочих сессий и интервью во время определения сущностей. Анализ требований к информации, полученных от экспертов в предметной области и конечных пользователей – наилучший источник информации для идентификации атрибутов.

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

Вам следует проанализировать каждый из атрибутов для определения его взаимосвязей со всеми остальными атрибутами модели. Корректно выполненный анализ гарантирует, что каждый из атрибутов присутствует в модели в единственном экземпляре и размещается в сущности в соответствии с третьей нормальной формой.

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

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

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

Атрибут должен присутствовать в логической модели в единственном экземпляре. «Один факт в одном месте». Для гарантии того, что каждый факт представлен единственным атрибутом, проверьте атрибуты со сходными именами или описаниями. Кроме того, вы должны определить, являются ли атрибуты реальными экземплярами или конкретными значениями, которые ошибочно представлены в модели разными атрибутами.

Атрибуты со сходными именами и описаниями могут в действительности представлять одну и ту же концепцию и должны быть представлены одним атрибутом. В естественном языке одно и то же слово может представлять несколько концепций. Но что еще хуже, в английском языке для представления одной и той же концепции может существовать несколько разных слов.

Атрибуты, имеющие в составе своего имени слова «индикатор» или «флаг», скорее всего, представляют конкретное значение из области определения атрибута. Конкретное значение является экземпляром атрибута. Использование в модели экземпляров атрибутов – распространенная ошибка. Например, «Индикатор черных волос» имеет значение «да» если присутствуют черные волосы, и значение «нет» если черные волосы отсутствуют. Более предпочтительным будет использование в модели атрибута «Цвет волос», который может иметь конкретное значение «Черный».

Атрибут должен представлять только одну концепцию бизнеса. Он не должен иметь несколько значений для одного экземпляра сущности.

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

Связь

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

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

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

Фактор риска <снижает риск>  Страхования

Отдел <состоит из> нескольких Сотрудников

Самолет <перевозит> нескольких Пассажиров. 

Сотрудник <пишет> разные Отчеты.

Рис. П4

В приведенных примерах глаголы заключены в угловые скобки. Связи отображаются в виде линии между двумя сущностями с точкой на одном конце и глагольной фразой, отображаемой над линией. На рис. П4 приводится диаграмма связи между сущностями СТРАХОВАНИЕ и ФАКТОР РИСКА.

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

В ERwin связи представлены пятью основными элементами информации:

  •  тип связи;
  •  имя связи;
  •  мощность связи;
  •  допустимость пустых (null) значений;
  •  требования по обеспечению ссылочной целостности.

Тип связи

 ERwin поддерживает следующие основные типы связей:

  •  идентифицирующая/неидентифицирующая,
  •  полная категория, неполная категория,
  •  многие-ко-многим.

Идентифицирующая и неидентифицирующая связи

Связь называется идентифицирующей, если экземпляр дочерней сущности идентифицируется через ее связь с родительской сущностью. Дочерняя сущность при идентифицирующей связи всегда является зависимой.

Связь называется неидентифицирующей, если экземпляр дочерней сущности идентифицируется иначе, чем через связь с родительской сущностью. Дочерняя сущность при неидентифицирующей связи обычно является относительно независимой от родительской.

Идентифицирующая связь изображается сплошной линией; неидентифицирующая – пунктирной линией. Линии заканчиваются точкой со стороны дочерней сущности.

Таким образом, связи определяют, является ли сущность независимой или зависимой.

Связи типа «один-ко-одному», «один-ко-многим», «многие ко-многим»

Связи между сущностями могут быть типа

  •   один-ко-одному;
  •  один-ко-многим;
  •  многие ко-многим.

Связь один-ко-одному означает, что один экземпляр первой сущности связан с одним экземпляром второй сущности и, наоборот, один экземпляр второй сущности связан с одним экземпляром первой сущности. Обычно такая связь возникает, когда одна сущность искусственно делится на две сущности.

Связь один-ко-многим означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности и один экземпляр второй сущности связан с одним экземпляром первой сущности. Причем первая сущность называется главной, а вторая – подчиненной.

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

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

Имя связи

Имя связи (Verb Phrase) – фраза, характеризующая отношение между родительской и дочерней сущностями.

Для связи «один ко многим» достаточно указать имя, характеризующее отношение между родительской и дочерней сущности (Parent-to-Child).

Для связи «многие ко многим» следует указывать имя как Parent-to-Child, так и Child-to-Parent.

Мощность связи

Мощность связи (Cardinality) служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

Различают 4 типа мощности, показанные на рис П5:

  •  общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности не помечается каким-либо символом;
  •  символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
  •  символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);
  •  цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.

Рис. П5. Типы мощности

Правила ссылочной целостности

Правила ссылочной целостности (referential integrity (RI)) - логические конструкции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления.

Модель данных, основанная на ключах  

Модель данных, основанная на ключах — это  логическая модель, включающая описание всех сущностей и ключевых атрибутов, которые соответствуют предметной области.

Целью этой модели является дальнейшая детализация модели сущность-связь и идентификация сущностей путем выбора ключевых атрибутов (ключей).

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

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

Первичный ключ должен быть статическим (static) и неразрушаемым (non-volatile). Под статичностью и неразрушаемостью подразумевается, что первичный ключ не должен подвергаться изменениям. Изменения первичного ключа трудно сопровождать, что часто приводит к весьма дорогостоящим переделкам, поэтому лучшим считается вариант, когда первичный ключ абсолютно не зависит от экземпляров сущности.

Для нахождения первичного ключа требуется проанализировать данные, определяющие сущность. Как правило, первичные ключи для стержневых сущностей определяются во время рабочих сессий и обсуждений. Эксперты предметной области и пользователи – хорошие источники информации для выбора потенциальных первичных ключей. Примеры данных тоже обеспечивают ценный вклад при выборе первичного ключа.

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

  •  Кандидат в ключи. Кандидатом в ключи является атрибут или набор атрибутов, идентифицирующих единичный экземпляр сущности. Иногда единичный экземпляр сущности идентифицируется несколькими атрибутами или их комбинацией.
  •  Составной ключ. Ключ, который состоит более чем из одного атрибута, называется составным, сложным или компонентным. Для составных ключей каждая составляющая ключа должна иметь значение для каждого экземпляра. Ни одна часть ключа не должна быть неопределенной (NULL). Все части ключа являются обязательными и не могут быть опущены.
  •  Искусственный первичный или суррогатный ключ. Иногда ни единичный атрибут, ни комбинация атрибутов, не определяют экземпляр. В этих случаях вы используете искусственный уникальный идентификатор. Искусственные первичные ключи часто просто нумеруют каждый экземпляр или код.
  •  Внешние ключи. Когда первичный ключ одной сущности мигрирует в другую таблицу, он называется внешним ключом. Внешние ключи «связывают» сущности, представляя отношения между ними. Внешние ключи будут обсуждаться более подробно в дальнейших статьях по этой тематике.

На диаграмме сущность-связь каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены неключевые поля. Верхняя часть называется ключевой областью, а нижняя часть областью данных (рис. П6.). Ключевая область содержит первичный ключ для сущности.

Ключевая область объекта СТРАХОВАНИЕ содержит поле уникальный идентификатор Код договора, в области данных находятся поля «Страховая сумма», «Дата страхования» и т.д.

Рис. П6. Ключевые поля

Выбор первичного ключа для сущности является очень важным шагом, и требует большого внимания. В качестве первичного ключа может быть использован атрибут или группа атрибутов. Атрибуты, которые могут быть выбраны первичными ключами, называются кандидатами в ключевые атрибуты (потенциальные атрибуты). Кандидаты в ключи должны уникально идентифицировать каждую запись сущности. В соответствии с этим, ни одна из частей ключа не может быть NULL, не заполненной или отсутствующей.

Например, для того, чтобы корректно использовать сущность СТРАХОВАНИЕ в IDEF1X модели данных (а позже в базе данных), необходимо иметь возможность уникально идентифицировать записи.

Правила выбора первичного ключа:

  •  Уникальным образом идентифицировать экземпляр сущности.
  •  Не использовать NULL значений.
  •  Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.
  •  Быть как можно более короткими для использования индексирования и получения данных.

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

Для наглядного представления о том, как целесообразно выбирать первичные ключи, приведем следующий пример – выберем первичный ключ для знакомой нам сущности «СОТРУДНИК»:

  •  Атрибут «ID сотрудника» является потенциальным ключом, так как он уникален для всех экземпляров сущности СОТРУДНИК.
  •  Атрибут «Имя сотрудника» не очень хорош для потенциального ключа, так как среди служащих на предприятии может быть, к примеру, двое Иванов Петровых.
  •  Атрибут «Номер страхового полиса сотрудника» является уникальным, но проблема в том, что СОТРУДНИК может не иметь такового.
  •  Комбинация атрибутов «имя сотрудника» и «дата рождения сотрудника» может оказаться удачной для наших целей и стать искомым потенциальным ключом.

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

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

Суррогатный ключ — это произвольный номер, который уникальным образом определяет запись в сущности. Атрибут «Номер сотрудника» является примером суррогатного ключа.

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

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

Если сущности в IDEF1X диаграмме связаны неидентифицирующей  связью, то эта связь для дочерней сущности реализуется через внешние ключи.

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

Правила ссылочной целостности

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

Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления (INSERT, UPDATE или DELETE).

Например, между сущностями АГЕНТ и ФИЛИАЛ существует идентифициующая связь. Что будет, если удалить филиал? Экземпляр сущности АГЕНТ не может существовать без филиала (атрибут первичного ключа «В каком филиале работает/Номер филиала» не может принимать значение NULL); следовательно, нужно либо запретить удаление филиала, пока в ней числится хотя бы один агент.

Возможна установка следующих правил удаления (если таковые поддерживаются СУБД):

SET DEFAULT — при удалении атрибуту внешнего ключа присваивается значение по умолчанию. Например, при удалении филиала фирмы все агенты могут быть переведены в другой филиал.

NONE — при удалении значение атрибута внешнего ключа не меняется. Запись об агенте «повисает в воздухе», т. е. ссылается на несуществующий филиал. Такая ситуация характерна для «плоских» таблиц. Например, если информация об агентах и филиалах фирмы хранится в dbf-файлах, можно удалить запись о филиале, при этом файл агентов «ничего не будет знать» о том, что соответствующего филиала не существует. Поэтому в настольных или файл-серверных системах функциональность, обеспечивающая правила ссылочной целостности, реализуется в клиентском приложении.

RESTRICT — для удаления записи необходимо удалить все дочерние записи с внешним ключом, равным первичному ключу удаляемой записи. Например, для удаления филиала сначала нужно удалить всех агентов этого филиала.

CASCADE. — при удалении опорного экземпляра сущности (соответствующего концу связи «один») нужно удалить и все экземпляры сущности, соответствующие концу связи «многие». Например,  вместе с филиалом фирмы будут удаляться  все агенты данного филиала.

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

Зависимые и независимые сущности.

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

Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью.

Рис. П7. Пример зависимых сущностей

В примере на рис. П7 сущность «СЕАНС» является зависимой сущностью потому, что его идентификация зависит от сущностей «ЗРИТЕЛЬ» и «ФИЛЬМ». В обозначениях IDEF1X зависимые сущности представлены в виде закругленных прямоугольников.

Зависимые сущности далее классифицируются на

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

Сущность Сеанс принадлежит к первому типу зависимых сущностей, так как сеанс не может существовать без фильма.

Рассмотрим две сущности: «СТРАХОВАНИЕ», в процессе которого могут учитываться «Страховые факторы», снижающие страховые риски. Связь между этими двумя сущностями может быть выражена в виде «ФАКТОР РИСКА» <снижает риск> в одном или нескольких «СТРАХОВАНИЯХ». Но существуют такие страхования (страховки), для которых нет факторов, снижающих страховой риск. В этом случае, «СТРАХОВАНИЕ» может быть идентифицировано с использованием нулевого ключа родителя («ФАКТОР РИСКА»), но без экземпляра родительской сущности.

Сущности, независящие при идентификации от других объектов в модели, называются независимыми сущностями. В вышеописанном примере сущности Зритель и Фильм можно считать независимыми. В IDEF1X независимые сущности представлены в виде прямоугольников.

Идентифицирующие и неидентифицирующие связи.

В IDEF1X концепция зависимых и независимых сущностей усиливается типом взаимосвязей между двумя сущностями. Если вы хотите, чтобы внешний ключ передавался в дочернюю сущность (и, в результате, создавал зависимую сущность), то можете создать идентифицирующую связь между родительской и дочерней сущностями.

Идентифицирующие взаимосвязи обозначаются сплошной линией между сущностями.

Неидентифицирующие связи, являющиеся уникальными для IDEF1X, также связывают родительскую сущность с дочерней

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

Так как переданные ключи в неидентифицирующей связи не являются составной частью первичного ключа дочерней сущности, то этот вид связи не проявляется ни в одной идентифицирующей зависимости. В этом случае и ОТДЕЛ, и СОТРУДНИК рассматриваются как независимые сущности.

Тем не менее, взаимосвязь может отражать зависимость существования, если бизнес правило для взаимосвязи определяет то, что внешний ключ не может принимать значение NULL. Если внешний ключ должен существовать, то это означает, что запись в дочерней сущности может существовать только при наличии ассоциированной с ним родительской записи.

Роль

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

В примере, приведенном на рис. П8, в сущности «СТРАХОВАНИЕ» внешний ключ «Код клиента» имеет функциональное имя «Кто страхуется», которое показывает, какую роль играет этот атрибут в сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полного имени атрибута (как функционального имени, так и имени роли) следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Entitiy Display и затем включить опцию Rolename/Attribute. Полное имя показывается как функциональное имя и базовое имя, разделенные точкой (смотри рис. П8).

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

Рис. П8. Имена ролей внешних ключей

На рис. П9 сущность АЭРОПОРТ содержит данные обо всех аэропортах, между которыми организованы рейсы самолетов. Информация о полете, которая содержится в сущности ПОЛЕТ, включает пункт назначения и пункт отправления самолетов. Следовательно, сущности ПОЛЕТ и АЭРОПОРТ должны быть связаны дважды и первичный ключ – Код аэропорта должен дважды мигрировать в сущность ПОЛЕТ в качестве внешнего ключа. Необходимо различать эти атрибуты, которые содержат информацию об аэропорте, из которого вылетает самолет, и аэропорте, в который прилетает самолет. Они имеют разный смысл, но ссылаются на одну и ту же сущность АЭРОПОРТ (имеют общую область значений). В примере на рис. П9 атрибуты получили имена ролей «Пункт оправления» и «Пункт назначения».

Другим примером обязательности присвоения имен ролей являются рекурсивные связи (иногда их называют «рыболовным крючком» – fish hook), когда одна и та же сущность является и родительской и дочерней одновременно.

Рис. П9. Случай обязательности имен ролей

При задании рекурсивной связи атрибут должен мигрировать в качестве внешнего ключа в состав неключевых атрибутов той же сущности. Атрибут не может появиться дважды в одной сущности под одним именем, поэтому обязательно должен получить имя роли. На рис. П10 сущность Сотрудник содержит атрибут первичного ключа Код сотрудника. Информация о руководителе сотрудника содержится в той же сущности, поскольку руководитель работает в той же организации. Чтобы сослаться на руководителя сотрудника, следует создать рекурсивную связь (на рис. 9 связь руководит) и присвоить имя роли (Руководитель). Заметим, что рекурсивная связь может быть только неидентифицирующей. В противном случае внешний ключ должен был бы войти в состав первичного ключа и получить при генерации схемы признак NOT NULL. Это сделало бы невозможным построение иерархии, – у дерева подчиненности должен быть корень, – сотрудник, который никому не подчиняется в рамках данной организации.

Связь «руководит/подчиняется» на рис. П10 позволяет хранить древовидную иерархию подчиненности сотрудников. Такой вид рекурсивной связи называется иерархической рекурсией (hierarchical recursion) и задает связь, когда руководитель (экземпляр родительской сущности) может иметь множество подчиненных (экземпляров дочерней сущности), но подчиненный имеет только одного руководителя (смотри рис. П10).

Другим видом рекурсии является сетевая рекурсия (network recursion), когда руководитель может иметь множество подчиненных и, наоборот, подчиненный может иметь множество руководителей. Сетевая рекурсия задает паутину отношений между экземплярами родительской и дочерней сущностей. Это случай, когда сущность находится сама с собой в связи «многие ко многим». Для разрешения связи «многие ко многим» необходимо создать новую сущность (подробно связь «многие ко многим» будет рассмотрена ниже).

Рис. П10. Подчиненность экземпляров сущности в иерархической рекурсии

На рис. П3 рассмотрен пример реализации сетевой рекурсии. Структура моделирует отношения субординации между сотрудниками любой сложности. Поскольку отношение субординации связывает всегда двух людей, от сущности Сотрудник к сущности отношения субординации установлены две идентифицирующие связи с именами ролей «Руководитель» и «Подчиненный». Каждый сотрудник может быть в отношениях «руководит/подчиняется» с любым другим сотрудником, но одну и ту же пару сотрудников может связывать один тип отношений субординации.

Связь «многие ко многим»

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

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

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

Автоматическое преобразование может быть выполнено при переходе на физический уровень. Для автоматического преобразования связи следует во вкладку General диалога Model, Model Property включить опцию Many-To-Many Relationships with Association Table. Преобразование связи включает создание новой таблицы и двух новых связей «один ко многим» от старых к новой таблице. При этом имя новой таблице присваивается автоматически как Имя1_Имя2. Автоматического решения проблемы связи многие-ко-многим не всегда оказывается достаточно.

Для принудительного преобразования связи «многие ко многим» на логическом уровне необходимо щелкнуть по связи правой кнопкой мыши и выбрать пункт меню Create Association Table. Many-To-Many Relationship Transform Wizard. Диалог Many-To-Many Relationship Transform Wizard предлагает 4 шага для преобразования связи. Для перехода к следующему шагу надо щелкнуть по кнопке Next (Далее). На втором и третьем шаге следует задать имя вновь создаваемой таблицы и имя преобразования.

На рис. П11 показан пример связи «многие ко многим». Преподаватель может преподать разные дисциплины, дисциплина может преподаваться  разными преподавателями.

Рис. П11. Пример связи «многие ко многим»

В примере таблица Преподават_Предмет имеет смысл учебного занятия, поэтому ее следует переименовать согласно бизнес-логике в «УЧЕБНОЕ ЗАНЯТИЕ». Один и тот же предмет может много раз читаться преподавателем, например в разное время, поэтому для того, чтобы идентифицировать учебное занятие, необходимо в состав первичного ключа сущности «УЧЕБНОЕ ЗАНЯТИЕ» добавить дополнительный атрибут, например дату проведения занятия (рис. П12).

Рис. П12. Сущность УЧЕБНОЕ ЗАНЯТИЕ

Распространенные ошибки при моделировании сущностей и выборе ключей

Этот раздел, посвященный распространенным ошибкам при моделировании, не претендует на полноту. Его цель – указать на наиболее распространенные ошибки, которые возникают у разработчиков моделей.

Моделирование ролей

Что подразумевается под моделированием ролей? Во время рабочих сессий пользователи могут сказать вам, что им необходимо хранить информацию о сотрудниках. Возникает искушение создать сущность СОТРУДНИК. Более тщательный анализ информации, представляющей интерес для корпорации, например, такой как имя, адрес и номер социального страхования показывает, что эти значения не зависят от сущности СОТРУДНИК. Для конкретного СОТРУДНИКА значение атрибута ИМЯ не зависит от сущности СОТРУДНИК. Это легко понять, если задуматься о том, что ваше имя остается вашим именем вне зависимости от того, являетесь ли вы СОТРУДНИКОМ или нет.

Перегрузка сущностей

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

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

Например, сущность ОБОРУДОВАНИЕ может иметь совершенно разное значение для подразделений информационных технологий и для отдела средств массовой информации и коммуникаций.

Избыточные сущности

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

Например, сущности УПРАВЛЕНЕЦ и СОТРУДНИК могут содержать сходную информацию, поскольку обе являются ролями, которые может играть экземпляр сущности ПЕРСОНА.

Выбор неправильного первичного ключа

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

  •  Не уникальность: первичный ключ не является уникальным для каждого из экземпляров. Например, разработчик модели может считать, что номер социального страхования является уникальным для каждой ПЕРСОНЫ. Однако номер социального страхования может повторно использоваться в том случае, если первоначальный его владелец скончался.
  •  Требуемое значение/неопределенность: первичный ключ не имеет значения для некоторых из экземпляров. Например, не каждый экземпляр сущности ПЕРСОНА будет иметь номер социального страхования. Иностранцы и маленькие дети – вот две категории людей, у которых он будет отсутствовать.

Использование неудачных имен сущностей

Непонятные, неоднозначные или неточные имена затрудняют для новых пользователей и команд разработчиков повторное использование или расширение существующей модели.

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

Не включайте месторасположение в качестве части имени. Как правило, вам неизбежно потребуется и другое месторасположение. Имя с указанием расположения является признаком того, что вы моделируете конкретный экземпляр вместо класса сущностей.

Использование неудачных описаний сущностей

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

Не пытайтесь перефразировать имя сущности. Не используйте имя сущности в ее описании.

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

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

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

Полная атрибутивная модель

Полная атрибутивная модель — это логическая модель, наиболее детально представляющая структуру данных, представленных в третьей нормальной форме.  

Нормализация

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

  •  первая нормальная форма (1NF);
  •  вторая нормальная форма (2NF);
  •  третья нормальная форма (3NF);
  •  нормальная форма Бойса-Кодда (усиленная 3NF);
  •  четвертая нормальная форма (4NF);
  •  пятая нормальная форма (5NF).

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

Функциональная зависимость (FD). Атрибут В сущности Е функционально зависит от атрибута А сущности Е тогда и только тогда, когда каждое значение атрибута А сущности Е связало с ним точно одно значение атрибута В сущности Е, т. е. А однозначно определяет В.

Полная функциональная зависимость. Атрибут В сущности Е полностью функционально зависит от ряда атрибутов А сущности Е тогда и только тогда, когда В функционально зависит от А и не зависит ни от какого подряда А.

Рассмотрим нормальные формы.

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

Для приведения сущности к первой нормальной форме следует разделить сложные атрибуты на атомарные.

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

Для приведения сущности ко второй нормальной форме следует:

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

Третья нормальная форма (3NF). Сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть взаимозависимости между неключевыми атрибутами).

Для приведения сущности к третьей нормальной форме следует:

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

Поддержка нормализации в ERwin. ERwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных имен атрибутов в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила «один факт — в одном месте». Имена ролей атрибутов внешних ключей и унификация атрибутов также облегчают построение нормализованной модели.

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

В результате нормализации все взаимосвязи данных становятся правильно определенными, исключаются аномалии при оперировании данными, модель данных становится легче поддерживать. Однако часто нормализация данных не ведет к повышению производительности ИС в целом. Например, для получения полной информации, о сотруднике из ненормализованной структуры данных достаточно обратиться к одной таблице. После приведения структуры данных к третьей нормальной форме информация о сотруднике может содержаться уже в четырех таблицах. Хотя общее количество строк в этих таблицах может быть меньше, чем в исходной (до нормализации), теперь для получения полной информации о сотруднике серверу базы данных необходимо обращаться одновременно к четырем таблицам (объединение таблиц, join). Время выполнения запроса с объединением может во много  раз превосходить время выполнения запроса к одной таблице; другими словами, в приведенном примере общая производительность ИС в результате нормализации скорее всего упадет. В целях повышения производительности при переходе на физический уровень приходится сознательно отходить от нормальных форм для того, чтобы использовать возможности конкретного сервера или ИС в целом.

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

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

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

Создание физического уровня модели

На стадии реализации создаются физическая модель. Существует два уровня физических моделей: трансформационная модель (Transformation Model) и модель СУБД.

Процесс генерации схемы базы данных из модели данных называется прямым проектированием (Forward Engineering). При генерации схемы ERwin включает триггеры ссылочной целостности, хранимые процедуры индексы, ограничения и другие возможности, доступные при определении таблиц в выбранной СУБД.

Процесс генерации модели из схемы базы данных называется обратным проектированием (Reverse Engineering). ERwin позволяет создать модель данных путем обратного проектирования имеющейся базы данных. После того как модель создана, можно переключиться на другой сервер (модель будет конвертирована) и произвести прямое проектирование структуры базы данных для другой СУБД. Кроме режима прямого и обратного проектирования ERwin поддерживает синхронизацию между моделью и системным каталогом СУБД на протяжении всего жизненного цикла создания ИС.

Трансформационная модель — это физическая модель, полученная путем преобразования логической модели по следующему принципу: сущности становятся таблицами, атрибуты становятся столбцами, а ключевые атрибуты становятся первичными ключами.

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

Целью трансформационной модели является предоставление информации администратору БД для создания эффективной структуры хранения, включающей в себя записи, формирующие БД. Трансформационная модель должна помочь разработчикам выбрать структуру хранения данных и реализовать систему доступа к ним.

Перед началом проектирования БД необходимо убедиться в обеспечении следующих требований:

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

Модель СУБД напрямую транслируется из трансформационной модели, являясь отображением системного каталога. Средство ERWin напрямую поддерживает эту модель через функцию генерации схемы БД. При составлении схемы БД в качестве индексов могут использоваться как ключевой атрибут, так и остальные поля БД.

Физический уровень модели зависит от выбранного сервера. Для выбора СУБД служит редактор Target Server (меню Database/Choose Database доступно только на физическом уровне).

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

Диалог Target Server позволяет задать тип данных и опцию NULL для новых колонок, а также правила ссылочной целостности, принимаемые по умолчанию. Тип данных можно выбрать в раскрывающемся списке Default Datatype, который автоматически заполняется типами данных, поддерживаемых выбранным сервером.

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


Приложение 2. Наиболее часто задаваемые вопросы

  1.  При формировании атрибутов (на уровне атрибутов) их кириллица в изображениях сущностей превращается в каракули. Не могли бы Вы детально пояснить, как сделать нормальный текст.

Перейдите в меню Option / Default Font/Color. В закладке All Fonts

1. Внизу слева выберите радио-кнопку All Objects

2. Выберите установленный кириллический шрифт (например, который используется для имени сущности).

  1.  Er Win 4.0 не понимает русский шрифт. Вообще списка шрифтов нет в ERWin. И все что я пишу на русском – это абракадабра. Почему?

Способы русификации:

1. Утилита fixfonts.exe от Интерфейса, которая делает необходимую замену названий шрифтов в реестре. Ее можно скачать из раздела Downloads (необходима регистрация). В этом разделе, чтобы найти утилиту необходимо выбрать: CASE средства, продукты CA и т.д.

2. Скрипт для замены шрифтов в реестре Windows:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]

"Arial,0"="Arial,204"

"Arial Cyr,0"="Arial,204"

"Courier,0"="Courier New,204"

"Courier New,0"="Courier New,204"

"Courier New CYR,204"="Courier New,204"

"System,0"="System,204"

"Fixedsys,0"="Fixedsys,204"

"Small Fonts,0"="Small Fonts,204"

MS Serif,0"="MS Serif,204"

"MS Sans Serif,0"="MS Sans Serif,204"

"Times New Roman,0"="Times New Roman,204"

"Times New Roman Cyr,0"="Times New Roman,204"

"Helv,0"="MS Sans Serif,204"

"Tms Rmn,0"="MS Serif,204"

"Verdana,0"="Verdana,204"

"Tahoma,0"="Tahoma,204"

"Trebuchet MS,0"="Trebuchet MS,204"

а. Сохраните в файл с расширением .reg и сделайте его Merge;

б. Перезагрузитесь.

  1.  Можно ли в логической модели работать с View? Куда нажать, чтобы их показало? В проекте представления играют не менее важную роль, чем таблицы. Хочется задать им нормальные логические имена, а то те, которые генерируются, имеют вид типа "V/xx".

На физическом уровне создать View нельзя, поскольку этот объект зависит от СУБД (многие СУБД, которые поддерживает ERwin, не имеют View) Для переименования View необходимо кликнуть по View правой кнопкой, выбрать View Editor и в поле Name набрать имя.

  1.  Как организовать автоматический счетчик ключевого поля в таблице? В DBA STUDIO, например, для автоматического увеличения счетчика ключевого поля надо создавать SEQUENCE и триггер на INSERT. А как это сделать в ERwin? SEQUENCE в ERWin отсутствует как таковой. Не создавать же его отдельно, должно же что-то быть стандартное для такой ситуации.

Да SEQUENCE в ERWin отсутствует, но Вы можете создать триггер на INSERT вручную как на уровне связи, так и на уровне таблицы (правой кнопкой кликните по таблице и выбирайте Oracle Trigger). Триггер можно описать на глобальном уровне и использовать во всех таблицах (на уровне связи). Для генерации имени таблицы нужно использовать макрос.

  1.  Что такое источник модели?

Источник модели – это логическая связь, которую ERwin устанавливает между родственными моделями. Цель этой связи – отслеживать объекты (например, сущности и таблицы), которые из одной модели перешли в другую.

Эта связь позволяет ERwin управлять синхронизацией родственных моделей, когда необходимы изменения. Например, когда физическую модель получают из логической, создается источник модели, в котором записано, какие сущности использовались для генерации таблиц в физической модели. Позже изменения в каждой из моделей могут быть синхронизированы с помощью мастера Synch Model Source.

  1.  Когда загружается старая модель, как можно разбить ее на логическую и физическую модели?

Прежде, чем изменять текущую модель, сохраните ее под другим именем или в другом каталоге. Откройте «Logical» в ниспадающем меню на панели инструментов. Используя «Tools, Split L/P Model», генерируйте отдельные модели. При этом ERwin запросит имена для логической и физической моделей, которые вы создаете.

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

  1.   Не могу понять, почему не проходит импорт сущностей и атрибутов из BPwin в ERwin? ERwin при загрузке сущностей и атрибутов пишет ошибку  enable to find entity by id (1)и т д?

Обычно такая ошибка возникает из-за несоответствия версий BPwin и ERwin. Версии должны совпадать, включая номер SP, например BPwin 2.5 SP3 и ERwin 3.5.2 SP3.

  1.  У нас возникли проблемы с подключением ERwin к MS SQL Server

Одна из возможных причин такой проблемы – использование разных версий Model Mart и ERwin. Должны быть версии Model Mart 3.0.2 и ERwin 3.5.2 или Model Mart 3.0.2 SP2 и ERwin 3.5.2 SP2.

  1.  Существуют ли какие-либо plug-in для генерации БД в MySQL и вообще для связи с MySQL?

Erwin не поддерживает напрямую сервер MySQL, однако если у Вас есть ODBC драйвер к MySQL, то можно работать с сервером через ODBC (ErWin версии не ниже 3.5.2, trial версия работу через ODBC не поддерживает).

  1.  Как заставить Report Browser не только показывать отчеты по-русски, но так же их и печатать?

Необходимо в Report Browser установить соответствующий шрифт. Для этого войдите в пункт меню File / Print. Далее в диалоге Print result Set выберите: кнопка Page Setup, закладка Fonts.

  1.   При открытии БД Access в ERwin возникает ошибка 340.

Установите дистрибутив DAO из директории DAO диска дистрибутива ERwin 3.5.2

  1.   При работе Erwin3.X под NT в модели «расплываются» надписи – названия сущностей, атрибутов и комментариев.

Ошибка связана с некорректной работой NT с кириллическими шрифтами. Имеются два способа борьбы с расплывающимися надписями при работе с Erwin3.X под NT.

1. При Reverse Engineering использовать заранее подготовленный шаблон. Для этого следует создать новый проект (НЕ ВКЛЮЧАЯ В НЕГО НОВЫЕ СУЩНОСТИ), установить шрифты, работающие корректно при прямом внесении сущностей (подбираются экспериментально) Option/ default font/color/ All Fonts /All Objects и сохранить модель как шаблон – File / SaveAs /Files of Type / ERwin Template. При Reverse Engineering в качестве шаблона необходимо выбрать не стандартный шаблон, а Ваш собственный.

2. Второй способ предполагает редактирование регистров NT.

В разделе 

HKEY_LOCAL_MACHINE

SOFTWARE

Microsoft

WindowsNT

CurrentWersion

FontMapper

Следует установить 204 таблицу: DEFAULT 0X000000cc (204).

В разделе 

HKEY_LOCAL_MACHINE

SOFTWARE

Microsoft

WindowsNT

CurrentWersion

FontSubstitutes

Следует для всех стандартных фонтов установить ссылку на 204 таблицу, например Arial,0 "Arial,204"

  1.   Как связать модель процессов в BPwin и модель данных в ERwin.

Существует три типа связывания данных

1. Через импорт из ERwin в BPwin dbf – файла (актуально для устаревших версий, однако возможность сохранена и в последних версиях).

2. При помощи ModelMart Synchronizer – для моделей, хранящихся в ModelMart.

3. Через импорт и экспорт при помощи файлов формата bpx-eax. Эта техника описана ниже.

Стрелки в модели процессов означают некоторую информацию, использующуюся в моделируемой системе. ERWin поддерживает два уровня представления модели данных – логический и физический.

Логический уровень не зависит от конкретной реализации БД и позволяет наглядно представить данные для обсуждения с экспертами предметной области.

Физический уровень является отображением системного каталога БД и зависит от конкретной реализации БД.

На логическом уровне модели данных информация отображается в виде сущностей (соответствуют таблицам на физическом уровне), состоящих из атрибутов сущностей (соответствуют колонкам таблицы). Сущности состоят из совокупности отдельных записей – экземпляров сущностей (соответствуют записям в таблице). К модели данных предъявляются определенные требования (т.н. нормализация данных), которые призваны обеспечить компактность и непротиворечивость хранения данных. Основная идея нормализации данных – каждый факт должен храниться в одном месте. Это приводит к тому, что информация, которая моделируется в виде одной стрелки в модели процессов, может содержаться в нескольких сущностях и атрибутах в модели данных.

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

Стрелке в модели процессов может соответствовать отдельная сущность в модели данных. Информация о стрелке может содержаться только в нескольких атрибутах сущности. Разным атрибутам одной и той же сущности могут соответствовать разные стрелки.

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

BPWin позволяет связывать элементы модели данных, созданной с помощью ERWin, документировать влияние работ на данные и, тем самым, позволяет создать спецификации на права доступа к данным для каждого процесса.

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

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

Для экспорта модели данных из ERwin в BPwin необходимо в ERwin открыть модель, войти в меню File, выбрать опцию Bpwin/Export, выбрать имя файла *.eax и нажать OK. Появится сообщение «Export Successful».

Затем в BPwin'е нужно открыть желаемую модель процесса, выбрать из меню File/Import/Erwin (EAX)..., выбрать имя файла и нажать OK. Появится протокол импорта. Нужно закрыть диалог протокола и в следующем диалоге кликнуть по кнопке Accept Changes.

Теперь можно связать сущности и атрибуты со стрелками. Правой кнопкой нужно кликнуть по стрелке и выбрать в контекстном меню Arrow Data. Появляется диалог Arrow Data Editor. В нем необходимо указать сущности и атрибут(ы), связанные со стрелкой и кликнуть по кнопке OK, чтобы сохранить изменения.

Если в процессе связывания стрелок с объектами модели данных окажется, что каких либо сущностей или атрибутов не хватает, их можно добавить (меню Edit/Entity/Attribute Dictionary), а затем экспортировать в ERwin (в BPwin меню File/Export/ERwin(BPX), в ERwin меню BPwin/Import) .

Как было указано выше, работы могут воздействовать на данные. Для документирования такого воздействия необходимо кликнуть правой кнопкой мыши по желаемой работе и выбрать Data Usage Editor. В появившемся диалоге Data Usage Editor нужно в верхнем списке кликнуть по имени стрелки, с которой были связаны сущности и атрибуты. В нижнем левом окне появится список связанных сущностей. Если выбрать сущность, то, во-первых, в правом окне появится список соответствующих атрибутов, во-вторых, в центре открываются окна выбора CRUD (Create, Retrieve, Update, Delete). Если кликнуть по атрибуту, то значение окон выбора меняется на IRUN (Insert, Retrieve, Update, Nullify). Ассоциации CRUD и IRUN – это правила использования сущностей и атрибутов работами. Данные не могут использоваться работами произвольно.

Стрелки входа представляют данные, которые работа преобразовывает в выход или потребляет. Такие данные могут быть восстановлены (Retrieve), обновлены (Update), удалены (Delete), но не могут быть созданы (Create). Стрелки контроля могут быть только восстановлены (Retrieve) и не могут быть изменены. Стрелки выхода могут быть обновлены (если им соответствуют данные стрелок входа) или созданы (Create).

Результат связывания объектов модели процессов можно отобразить в отчете Data Usage Report (меню Report / Data Usage Report).

  1.   Почему при работе VB с Access во время запуска формы я получаю сообщение «ошибка времени выполнения ' 3075 ' (ошибка синтаксиса в выражении запроса)».

Эта ошибка может быть вызвана наличием пробела в названиях таблиц или колонок. Все пробелы должны быть заменены на символ подчеркивания ‘_’. Синтаксис с пробелами приемлем для Access, но недопустим для VB.

  1.   Включает ли ERwin программное обеспечение для соединения с базами данных?

ERwin, подобно большинству аналогичных программных продуктов, полагается на внешнее программное обеспечение среднего звена («middleware»), чтобы соединиться с вашей DBMS. Сам ERwin не содержит программное обеспечение для связи с поддерживаемыми базами данных.

  1.   Какое программное обеспечение для связи с базами данных надо устанавливать 16 или 32-разрядное?

ERwin 3.5.2 поставляется только в 32-разрядном исполнении и требует соответствующего 32-разрядного программного обеспечения для связи с базами данных.

  1.   Чем Platinum ERwin лучше CSA – Silverrun ?

А) Генерация схемы БД

ERwin:

  •  Прямая связь с популярными СУБД
  •  Коннект через ODBC
  •  Генерация полных DDL-скриптов (с расширением стандарта)

Silverrun:

  •  Коннект к Oracle и Sybase через native-драйвер, остальные СУБД поддерживаются посредством генерации DDL-скриптов
  •  Генерируется только стандартный DDL-скрипт (без процедур и триггеров)
  •  Генерацию скрипта поддерживает отдельно продаваемый модуль.

Б) Сравнение баз данных

ERwin: Мощный инструмент создания и сравнения моделей позволяет сравнивать модель и БД, модель и другую модель, модель и DDL- скрипт.

Silverrun: Не имеет такой функциональности.

В) Синхронизация баз данных

ERwin: Генерирует alter- скрипт и позволяет выгружать и перегружать данные, когда это необходимо.

Silverrun : Не имеет такой функциональности

Г) Групповое моделирование

Platinum ModelMart обеспечивает:

  •  Контроль версий
  •  Разрешение конфликтов при многопользовательской работе
  •  Разграничение прав доступа
  •  Работа с подмоделями
  •  Разделяемые объекты моделирования (domains, validation rules и т.д.)
  •  Сравнение и отказ от изменений при записи модели
  •  Обновление без записи
  •  Отчет о безопасности данных
  •  Проводник моделей

Silverrun Enterprise не обеспечивает безопасность и контроль версий. Все изменения заносятся в режиме on-line, что создает большие проблемы производительности.

  1.   Erwin не подключается к базе Access,  выдает ошибку 340.

Существует 2 способа решения проблемы:

1. Работайте через ODBC.

2. Установите программу DAO, содержащую необходимые файлы для корректной связи с Access. Дистрибутив находится в директории DAO на ERwin 3.5.2 CD. Обратите внимание на то, что при инсталляции индикатор может показывать только 25%, а потом останавливается. Ничего страшного. Инсталляция прошла успешно.

  1.   Можно ли в ERwin осуществить копирование атрибута из таблицы в таблицу. Не путём создания связи, а через буфер обмена в Access?

Это возможно через инструмент независимых атрибутов (вызывается клавишами Ctrl-B).

  1.   При проведении полного сравнения модели ERwin с базой данных ERwin «не узнает» собственных триггеров, не видит собственных индексов и ограничений целостности. Это сделано с определенными целями, или они не сделали каких-то настроек?

ERwin не проводит обратного проектирования триггеров. Что касается индексов, то он должен их видеть. Проверьте настройки обратного проектирования в диалоге Complete Compare.

  1.   При обратном проектировании из FoxPro никакими настройками не удалось восстановить связи из индексов.

В диалоге Reverse Engineer необходимо установить опции Infer: Primary Kes-on, Relations-on; From: Indexes.

  1.   Как найти выход из следующей ситуации: в ERwin 4.1 создаются две сущности E1 и E2, в сущность E1 добавляем атрибут и устанавливаем связь между сущностями. Присваиваем связи значение logical only, в результате атрибут в дочерней сущности тоже становится logical only. Как этого избежать?

Для решения данной проблемы необходимо проделать следующее: в меню Format-Preferences в появившемся окне во вкладке Display установить флажок в FK options. В этом случае атрибут в дочерней сущности не становится logical only


 

А также другие работы, которые могут Вас заинтересовать

61847. Урок как основная форма организации правового обучения в общеобразовательном учреждении 224.5 KB
  Подготовка учителя к проведению урока. Анализ урока. Сущность и назначение урока в процессе обучения как целостной динамической системы сводится к коллективно индивидуальному взаимодействию учителя и учащихся в результате которого происходит усвоение учащимися знаний умений и навыков развитие их способностей опыта деятельности общения и отношений а также совершенствование педагогического мастерства педагога. Эффективность урока – степень достижения заданной цели педагогической деятельности с учетом оптимальности необходимости и...
61848. Великие географические открытия. Открытия европейцев и создание новых колониальных государств 1.89 MB
  В ходе раскрытия темы урока учитель используя как традиционные активные и интерактивные методы обучения дает возможность осмыслить учащимся причины и предпосылки великих географических открытий пройти путь первооткрывателей новых континентов и земель вместе...
61849. Узагальнення і закріплення вивченого матеріалу. Обчислення значень виразів. Розв’язування задач 72 KB
  Мета: удосконалювати навички швидкої лічби в межах 10, закріпити уміння та навички складати та розвязувати приклади, задачі, розвивати обчислювальні вміння, логічне мислення, творчі здібності, виховувати цілеспрямованість, наполегливість.
61850. Разработка стратегии расширения сети стейк хаусов GOODMAN в интересах полного и опережающего охвата Московского рынка 4.74 MB
  Основные усилия сетевых проектов буду направлены на удержание доли рынка в виде постоянных гостей с попытками увеличить частоту посещений за счёт постоянных спецпредложений и использования современных средств коммуникации. Возможно, средний чек сегмента casual dining начнёт стремиться вниз...
61851. Океани Землі 34 KB
  Океани Землі. Де проходить межа між Європою та Азією Показати найбільший острів на Землі. Картка 2 Показати найбільший материк Землі. Більшу територію Землі займає вода.
61852. Орієнтація на вулиці. Treasure Hunt 60 KB
  Dear children, today we’ll go to the treasure. Our task is to find the treasure. You can see a large box on the chair. We have to do a lot of exercises for finding the treasure. After each exercises the way to the treasure well be shorter.
61853. Подорож довжиною у тисячоліття 636 KB
  Розвивати вміння самостійно шукати потрібну інформацію в Інтернеті вибирати основне удосконалювати навики роботи в програмі Power Point. Готуючтсь до уроку на компютері зберігаю в соціальних закладках Бобродобр соціальних сервісів...
61855. Тарас Шевченко – великий Кобзар. Урок позакласного читання 791.5 KB
  Мета: Продовжити ознайомлення учнів з красоюнеповторністю чарівністю Шевченкового слова його бібліографічними даними значенням творчості Т. Шевченко великий український поет. Тоді темної ночі перед світанком у селі Моринцях на Звенигородщині у хаті Григорія Шевченка...