Моделирование баз данных в стандарте IDEF 1 x

Моделирование баз данных в стандарте IDEF 1 x Бессарабов Н. В. bes@fpm. kubsu. ru 2007 г.

Анализ • Определяются цели создания информационной системы. Выбирается стратегия разработки. Исследуются риски. Определяются особенности управления проектом. • Подробно исследуют бизнес-процессы и выявляют информацию, необходимую для их выполнения. Эту работу можно вести в рамках диаграмм “сущность-связь”. Выделяют сущности, их атрибуты и связи между ними. Создают информационную модель. На следующем этапе проектирования будет разработана модель данных. • Особое внимание следует уделить полноте информации, анализу возможных противоречий, поиску неиспользуемых и дублирующихся данных. Помните, что заказчику легче формулировать спецификации отдельных компонентов системы, а не всей системы. Два взаимосвязанных аспекта спецификации: • функциональный - описание бизнес-процессов; • информационный - описание данных, необходимых для управления бизнес-процессами.

Проектирование На этапе проектирования используя результаты анализа разрабатывают: 1. схему базы данных (описания таблиц, представлений, столбцов, ограничений целостности, индексов, последовательностей, кластеров, процедур, функций курсоров и т. д. ); 2. набор спецификаций модулей приложения. Схема базы и спецификации модулей приложения должны быть согласованы с результатами этапа анализа и между собой. Важнейшая задача этапа проектирования инфор- мационной системы – обеспечение производительности. Рекомендуется результаты проектирования оформлять в виде единого документа, который называется технической спецификацией (ТС).

Реализация Разработка это написание кодов приложения, в том числе: 1. Скриптов создающих базу и, может быть, заполняющих ее (серверная часть приложения); 2. Текстов хранимых процедур, функций, триггеров, курсоров (серверная часть приложения); 3. Текстов интерфейсов пользователя (клиентская часть приложения); 4. Коммуникационная часть системы. Важнейшие компоненты реализации: • Продуманное всестороннее тестирование; • Периодическое возвращение к этапам анализа и проектирования. Всегда помните совет классика: “Кодированию программы следует сопротивляться до последней возможности. ”

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

Последовательная модель ЖЦ Анализ Проектирование Разработка и тестирование Внедрение Эксплуатация и сопровождение Замечание: Этап внедрения требует в основном организационных усилий. Сопровождение это постоянные доработки информационной системы; составляет порядка 2/3 общей стоимости владения.

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

Инкрементная модель ЖЦ Анализ Проектирование Разработка и тестирование Внедрение Эксплуатация и сопровождение В один момент времени могут прорабатываться несколько этапов, обычно для разных подсистем. Возможен возврат на всю глубину последовательности этапов.

Понятие о спиральной модели ЖЦ Определение целей, альтернатив и ограничений НАЧАЛО Идентификация и разрешение рисков, оценка альтернатив Принципы функционирования Анализ требований Проектирование Планирование следующей итерации Кодирование и тестирование ПРОДУКТ Заимствовано из [] Кодирование и тестирование Разработка продукта на очередной стадии

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

Семантическая модель “Сущность. Связь” (Entity-Relationship) Наиболее известна семантическая модель “сущность – связь” (“entity – relationship”) предложенная Питером Пин Шен Ченом (Peter Chen) в 1976 г. Три основных понятия ER-модели: сущность, связь и атрибут.

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

Тип “Связь” Связи в рассматриваемом варианте ER-диаграмм бинарные, то есть устанавливаются между двумя типами сущностей. Можно использовать связи с большей арностью. Связь – это тЍповое понятие, устанавливающее правила связывания. Каждый экземпляр типа связи, устанавливается между экземплярами типа сущности. Может существовать рекурсивная связь между типом сущности и им же самим (его дубликатом). Концы бинарной связи характеризуется: • именем роли (имя конца связи), • степенью конца связи (сколько экземпляров данного типа сущности должно присутствовать в каждом экземпляре данного типа связи), • обязательность связи (т. е. любой ли экземпляр данного типа сущности должен участвовать в некотором экземпляре данного типа связи).

Обозначения

Условность разделения на сущности, связи и атрибуты Разделение на сущности, связи и атрибуты условно. Пример: То, что студент должен относиться к какой-нибудь учебной группе можно выразить: 1. Как связь Группа Входит в состав Студент группы 2. Как пара атрибутов Студент 3. Состав Группа Как сущность Состав группы Группа Атрибут “Состав” многозначный Замечание: Не следует делать вывод о том, что выбор сущностей произволен и нет предпочтительного варианта.

Нормализация в ER-диаграммах Сущности соответствует отношение в реляционной модели данных. Из наличия такого отображения вытекает возможность переноса нормализации в ER-диаграммы. Простой способ получения отношений сразу в третьей нормальной форме и уточнения до НФБК: 1. Выделите простые сущности, не содержащие в себе другие сущности. 2. Уточните ключевые атрибуты, выделив все альтернативные ключи. Чтобы окончательно убедиться в простоте сущностей проверьте наличие ФЗ кроме зависимостей от ключа. Если они обнаружены, декомпозируйте такие сущность по Хису. 3. Если есть пересекающиеся ключи, проверьте сущест- вование зависимостей между ключами и при их обнаружении получите НФБК

Примеры ER-диаграмм Диаграммы рисуются на доске

Моделирование данных в ERWin 1. В ERWin используется три вида нотации: По стандарту IDEF 1 X По стандарту IE (Information Engineering) По стандарту DM (Dimensional Model) и всего пять уровней представления данных: Уровень сущности Уровень атрибутов Уровень описаний Уровень ключей Уровень иконок

Локализация ER-диаграммы в ERWin Установка шрифтов для обозначения имен сущностей, атрибутов и отношений

Создание сущности в ERWin (1/2) Создание сущности Название сущности Ключевые атрибуты Неключевые атрибуты

Создание сущности в ERWin (2/2) Запись определений (Definition), примечаний (Note и Note 2) и свойств, определенных пользователем (User Definied Properties --UDP)

ER-диаграммы в ERWin Три уровня представления сущности Entity level Attribute level Definition level Задание определения

Еще два уровня представления сущности вызываемые только из меню Уровень Primary Key Вызов уровня представления из меню Уровень Icon

Определения атрибутов должны иметь такую же базовую структуру как и определения сущностей. Определения также должны, где только возможно, содержать правила, определяющие возможные значения атрибутов. Пример: атрибут «статус покупателя» Статус-покупателя: Код, описывающий взаимосвязь между ПОКУПАТЕЛЕМ и нашим бизнесом. Допустимые значения: A, P, F, N

Сильные и слабые сущности (1/2) Может оказаться, что в первичный ключ сущности обязательно необходимо включить внешний ключ. Такая сущность называется слабой или зависимой. Сущность ИГРОК зависима потому, что без указания команды его не выделишь однозначно. В ERWin’е зависимые cущности изображаются прямоугольниками со скругленными краями. До установления связи И после

Сильные и слабые сущности (2/2) Сильная сущность существует “сама по себе”. Первичные ключи у нее тоже свои, то есть определяются только своими полями (свойствами). На ER-диаграммах в ERWin сильные сущности представляются прямоугольниками. Слабая сущность для идентификации своих экземпляров требует привязки к экземпляру связанной с ней, обычно сильной, сущности. С этой целью первичный ключ слабой сущности использует поля этой связанной с ней сущности, что дает повод говорить о миграции ключей. На ER- диаграмме в ERWin слабая сущность представляется прямоугольником с закругленными углами. Примеры сильных и слабых сущностей приведены ниже в слайдах о нормализации

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

Разрешение связей вида “многие-ко-многим” 1 2 3 1 b 1 a a 3 b b 4 5 5 b 4 b c Значения элементов ассоциативной сущности: 1 a, 1 b, 3 b, 4 b, 5 b

Пример связи вида “многие-ко-многим” и начало ее разрешения

Созданная ассоциативная сущность (в обозначениях IDEF 1 X и IE)

Изменение нотации (запись в IE) • Переход к нотации IE в логической модели (путь “Model” - “Model Properties”)

Шаблоны связей

Установка видимости первичных, внешних и альтернативных ключей • На логическом уровне выберите в меню Format – Entity Display Затем установите галочки в позициях Primary Key Designator, Foreign Key Designator, Alternative Key Designator • На физическом уровне выберите в меню Format – Table Display Затем установите галочки в позициях Primary Key Designator, Foreign Key Designator, Alternative Key Designator

Альтернативные ключи Потенциальные ключи, не использующиеся как первичные, могут быть определены как альтернативные ключи и записаны в секции данных модели с символом (AKn. m), где n. m – номер альтернативного ключа в формате “номер_сущности”. “номер_ключа”.

Инверсные входы • Атрибуты, не являющиеся уникальными, но использующиеся для поиска информации в таблице, называются инверсными входами. По ним может быть построен неуникальный индекс. • Атрибуты назначенные инверсными входом помечаются справа символом IEn. m, где n. m – номер альтернативного ключа в формате “номер_сущности”. “номер_ключа”.

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

Альтернативные и инверсные ключи

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

Виды ключей на физическом уровне

Альтернативный ключ и созданный скрипт CREATE TABLE Customer ( Cast_name VARCHAR 2(20) NOT NULL, Cast_addr VARCHAR 2(20) NULL, Cust_nomb INTEGER NOT NULL); CREATE UNIQUE INDEX XAK 1 Customer ON Customer (Cast_name); ALTER TABLE Customer ADD ( PRIMARY KEY (Cust_nomb) ) ;

Сущность с инверсным ключом CREATE TABLE Customer ( Cast_name VARCHAR 2(20) NOT NULL, Cast_addr VARCHAR 2(20) NULL, Cust_nomb INTEGER NOT NULL); CREATE UNIQUE INDEX XAK 1 Customer ON Customer (Cast_name); CREATE INDEX XIE 1 Customer ON Customer (Cast_addr); ALTER TABLE Customer ADD ( PRIMARY KEY (Cust_nomb) ) ;

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

Установка для передачи ролей

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

Пример первой нормальной формы (1 НФ) Неатомарный столбец На самом деле здесь непервая нормальная форма Бессарабов Н. В. 2011 Приведенный способ получения 1 НФ называется “выравнивание таблицы” 45

Определения 1 НФ Определение 1 НФа (через атрибуты): Отношение находится в 1 НФ, если значения всех его атрибутов атомарны. Определение 1 НФк (через ключи): Отношение находится в 1 НФ, если оно имеет ключ. Утверждение: 1 НФа 1 НФк. В самом деле, по определению реляционного отношения кортежи в отношении не повторяются. Если еще атрибуты атомарны, то есть удовлетворяют требованию предъявляемому в реляционной теории, то ключ в крайнем случае образуют все атрибуты, то есть ключ всегда существует. 46 Замечание: Обратное утверждение не верно. Бессарабов Н. В. 2011

Правила приведения к 1 НФ (выделение в отдельное отношение) • Разделить составные атрибуты (в примере это “Дата зачисления и увольнения”) на простые (атомарные) (“Дата зачисления” и “Дата увольнения ”) • Выделить “повторяющиеся” (однотипные, близкие) атрибуты (в примере это “Хобби” и “Тлф”) • Для каждой такой группы атрибутов создать новую справочную сущность с одним атрибутом для повторяющейся группы • Перенести в нее все значения повторяющихся атрибутов • Установить идентифицирующую связь типа 1: N от исходной сущности к каждой созданной справочной Почему связь должна быть идентифицирующей? сущности Бессарабов Н. В. 2011 Потому, что выделенные справочные сущности только уточняют свойства основной сущности и без привязки к экземпляру основной сущности их смысл теряется. Например, на следующем слайде справочная сущность “хобби” имеет смысл “хобби данного сотрудника”, а без 47 привязки её смысл “хобби вообще”, что не соответствует смыслу исходного отношения.

Пример приведения к 1 НФ (выделение в отдельное отношение) Ненормализованное отношение Отношения в 1 НФ Сотрудник Табельн. номер Фамилия Имя Отчество Должность Хобби_1 Хобби_2 Оклад Тлф_1 Тлф_2 Тлф_3 Дата зачисления или увольнения Бессарабов Н. В. 2011 Сотрудник Табельн. номер Фамилия Имя Отчество Должность Оклад Дата зачисления Дата увольнения Хобби Табельн. номер (FK) Хобби Телефон Табельн. номер (FK) Телефон 48

Приведение к 1 НФ 49

Правило приведения к 2 НФ • Выделить неключевые атрибуты, зависящие от части первичного ключа. Иначе говоря, найти функциональную зависимость группы неключевых атрибутов от части атрибутов ключа. • Создать новую сущность. В соответствии с теоремой Хиса все ее атрибуты входят в найденную выше функциональную зависимость. • Вычеркнуть атрибуты-значения найденной функции в исходной сущности. • Установить идентифицирующую связь 1: N или N: 1 от исходной сущности к созданной сущности.

Пример приведения к 2 НФ (в ERWin) Ненормализованное отношение Проект Наименование проекта Таб_номер_ рук Дата начала Дата завершения Фамилия Имя Отчество Должность Отношение в 2 НФ Проект Наименование проекта Рук. , Табельный номер (FK) Дата начала Дата завершения Сотрудник Табельный номер Фамилия Имя Отчество Должность

Правило приведения к 3 НФ • Найти функциональную зависимость неключевых атрибутов от других неключевых атрибутов. • Создать новую сущность. В соответствии с теоремой Хиса все ее атрибуты входят в найденную функциональную зависимость. • Вычеркнуть атрибуты-значения найденной функции в исходной сущности. • Установить неидентифицирующую связь от созданной сущности к исходной сущности

Пример приведения к 3 НФ (в ERWin) Пример: Функция f: Должность Оклад Ненормализованное отношение Сотрудник Табельный номер Фамилия Имя Отчество Должность Оклад Нормализованное отношение Сотрудник Табельный номер Фамилия Имя Отчество Должность (FK) Должность Оклад

Отношения в 3 НФ, имеющие несколько ключей Пример 1: Отношение с тремя не пересекающимися ключами. Атрибут Табельный_Номер уникальный. Пример 2: Отношение с двумя пересекающимися ключами Бессарабов Н. В. 2011 54

Нормальная форма Бойса-Кодда (Boyce-Codd) Исходное определение 3 НФ основывается на предположении о том, что первичный ключ единственный. Может оказаться, что: • отношение имеет два или более ключа-кандидата (альтернативных ключа); • по крайней мере два из них конкатенированы; • некоторые из конкатенированных ключей перекрываются (имеют общие атрибуты). В этом случае после получения 3 НФ необходимо привести отношения к нормальной форме Бойса-Кодда, сокращённо, НФБК. Ещё её называли исправленной третьей нормальной формой. Бессарабов Н. В. 2011 55

Какие функциональные зависимости исследуют приведении к НФБК? Ответ: Только функции, действующие из одного ключа в не принадлежащие этому первому ключу атрибуты второго пересекающегося с ним ключа PK 1 PK 2 Бессарабов Н. В. 2011 PK 1, PK 2 56

Правила преобразования в НФБК Совпадают с правилами для 3 НФ. Отличия только в анализируемых функциях

Мнемоника преобразования для НФБК (зависимость f: A C) f

Пример преобразования в НФБК • Заменим отношение двумя проекциями: ”Бригада - Стажёр” и “Стажер - Наставник”. Обратите внимание на переименование Иванова из 2 -й бригады Бессарабов Н. В. 2011 59

Заключение За прошедшие четыре часа бегло (и отрывочно) рассмотрена технология создания информационных систем. Стало понятно, что на начальной стадии анализа необходимо использовать семантические модели, такие как ER-диаграммы. Это позволяет зафиксировать массу неформализуемой, но важной для проекта информации. Подробно рассмотрена технология ERWin (локализация, создание сущностей, атрибутов и связей, использование ролей, разрешение связей типа “многие-ко-многим”). Описана нормализация в ERWin’е до НФБК. Осталось изучить денормализацию и такие частные, но важные особенности как наследование, сегментирование таблиц и т. п. После этого можно будет переходить к стыковке диаграмм описывающих бизнес-процессы и данные.