МЕТОДИЧЕСКИЕ УКАЗАНИЯ

к выполнению курсовой работы

по дисциплине
"Администрирование систем управления базами данных"
для студентов специальностей
«Программная инженерия», «Прикладная информатика»

Форма обучения очная и заочная

Луганск 2019
 ВВЕДЕНИЕ

Методические указания предназначены для студентов четвертого курса специальностей

«Прикладная Информатика» и «Программная инженерия» всех форм обучения. Они помогают
выполнить и оформить документацию к курсовой работе.
Курсовая работа имеет целью научить студентов самостоятельно применять полученные
знания для комплексного решения конкретных теоретических и практических задач, привить
навыки самостоятельного проведения научных исследований.
Курсовая работа по дисциплине «Администрирование СУБД» предназначена для обуче-
ния студентов разработке законченных модулей информационных систем, начиная с описания
предметной области выбранного объекта и заканчивая реализованными базой данных и необ-
ходимыми пользовательскими интерфейсами.
За время работы над курсовым проектом студент получает практические навыки ведения
проекта разработки и оформления сопутствующей документации, умения создавать и анали-
зировать модели баз данных, использования структурного метода проектирования, работы в
специализированном CASE-средстве ERwin.
Темы курсовых работ разрабатываются преподавателями в соответствии с основным со-
держанием учебной дисциплины и согласовываются со студентом по его желанию, рассмат-
риваются и утверждаются на заседании кафедры.
Для выбора темы курсовой работы по дисциплине «Администрирование СУБД» необ-
ходимо определить область деятельности, которая наиболее хорошо знакома и интересна сту-
денту. Выбранная тема является индивидуальной, т.е. если несколько студентов выбирают
одну и ту же область деятельности, то для каждого из них должны быть указаны разные функ-
ции этой области деятельности. Примеры тем курсового проекта приведены в Приложении 1.
Курсовая работа выполняется студентами в часы самостоятельной работы. Поясни-
тельная записка должна отражать ход выполнения курсового проекта. К пояснительной
записке прилагаются распечатка программного текста, тексты реализованных запросов
и скриншоты с результатами, инструкции по использованию. Объем основного текста по-
яснительной записки (без приложений) 20-40 страниц. В структуре базы данных должно при-
сутствовать не менее 7 таблиц, если разработан Web-клиент - минимум 3.
Проект считается выполненным, если
 создана база данных в соответствии с требованиями (на электронном носителе);
 спроектированы и реализованы пользовательские интерфейсы, в том числе и
Web-интерфейсы (на электронном носителе);
 подготовлена и оформлена в виде пояснительной записки вся необходимая до-
кументация.
Курсовая работа выносится на открытую защиту перед преподавателем (комиссией). В
ходе защиты студент демонстрирует и доказывает работоспособность проекта и его экономи-
ческую привлекательность. По результатам его защиты студенту выставляется оценка.
При получении неудовлетворительной оценки они выполняют работу по новой теме или
перерабатывают прежнюю в сроки, устанавливаемые деканатом факультета.
 СОДЕРЖАНИЕ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ
К КУРСОВОМУ ПРОЕКТУ.

Введение.
1. Описание предметной области.
2. Проектирование базы данных.
2.1. Этап инфологического проектирования.
2.2. Этап даталогического проектирования.
2.2 Этап физического проектирования.
3. Реализация средствами MS SQL Server.
4. Заключение.
 КОММЕНТАРИИ К СОДЕРЖАНИЮ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ.

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

1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

В данном разделе необходимо:

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

2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

Для проектирования базы данных в курсовой работе предлагается использовать стандарт

IDEF1X и CASE –средство Erwin для поддержки самого процесса проектирования.
Методология IDEF1X определяет стандарты терминологии, используемой при инфор-
мационном моделировании, и графического изображения типовых элементов на диаграммах.
IDEF1X является методом разработки реляционных БД основанном на применении
условного синтаксиса, специально разработанного для построения концептуальных схем.
КОНЦЕПТУАЛЬНАЯ СХЕМА - универсальное представление структуры данных, незави-
симое от конечной реализации БД и аппаратной платформы.
IDEF1X использует понятия сущностей, атрибутов, отношений и ключей. Языки гра-
фического изображения моделей, используемые этими методологиями, также во многом
схожи. Однако, IDEF1X не рассматривает объекты реального мира, а лишь их информацион-
ное отображение, так как к моменту разработки базы данных все информационные ресурсы
организации должны быть изучены, необходимый набор данных для отражения её деятельно-
сти определен и проверен на полноту.
 Основным преимуществом IDEF1X, по сравнению с другими многочисленными ме-
тодами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и
строгая стандартизация моделирования. Установленные стандарты позволяют избежать раз-
личной трактовки построенной модели, которая, несомненно, является значительным недо-
статком ER.
По сравнению с обычным (неупорядоченным) способом проектирования БД преиму-
щества IDEF1X моделей заключается в том, что система сама отслеживает переносимость
ключевых признаков к зависимым сущностям. Другой немаловажный момент- структура БД
может быть экспортирована в формат внешних (« коммерческих» ) СУБД с архитектурой кли-
ент-сервер без каких-либо доработок.
Программное средство ERWin позволяет проектировать, документировать и сопро-
вождать базы данных, хранилища данных. Визуальное моделирование повышает качество со-
здаваемой базы данных, продуктивность и скорость её разработки.
Основные особенности IDEF1X/ERWin:
1. Поддерживается прямое (создание БД на основе модели) и обратное (генерация мо-
дели по имеющейся базе данных) проектирование для 20 типов СУБД.
2. Увеличивает производительность труда благодаря удобному интерфейсу и автома-
тизации рутинных процедур.
3. Поддерживает методологию структурного моделирования SADT и следующие нота-
ции: IDEF1Х.
4. Поддерживает 20 различных СУБД: настольные, реляционные и специализирован-
ные СУБД, предназначенные для создания хранилищ данных.
5. Позволяет повторно использовать компоненты созданных ранее моделей, а также ис-
пользовать наработки других разработчиков.
6. Возможна совместная работа группы проектировщиков с одними и теми же моде-
лями (с помощью AllFusion Model Manager 4.1).
7. Позволяет переносить структуру БД из одной СУБД в другую.
8. Позволяет документировать структуру БД.
9. Продукт можно использовать на всех стадиях жизненного цикла БД: проектирова-
нии, разработке, тестировании и поддержке.
Итак, рассмотрим процесс построения модели.
В базе данных отражается информация об определенной предметной области. При про-
ектировании баз данных предметная область отображается моделями данных нескольких
уровней абстракций. В целом все модели данных можно разделить на три категории:
- инфологическая модель – описание предметной области, выполненное с использова-
нием специальных языковых средств, без ориентации на используемые в дальнейшем про-
граммные и технические средства. Данная модель содержит исходную информацию о пред-
метной области, необходимую для проектирования структуры базы данных (эта информация
не зависит от особенностей СУБД);
- даталогическая модель – описание предметной области, выполненное в рамках целе-
вой СУБД;
- физическая модель – определяет используемые запоминающие устройства и способы
физической организации данных на них [2].
В соответствии с этой концепцией построение модели в IDEF1X проходит ряд после-
довательных стадий, которые и должны быть отражены в данном разделе пояснительной за-
писки курсовой работы.
Стандарт моделирования данных IDEF1X использует три уровня логических моделей,
используемых для охвата требований бизнес-информации: диаграмму зависимостей сущно-
стей (ERD); модель, основанную на ключах (Key Based, KB) и полная атрибутивная модель
(Fully Attributed Diagram, FA). ERD и KB модели также называются «моделями данных обла-
сти» потому, что охватывают обширные области бизнеса. Полной противоположностью явля-
ется модель FA – «модель данных проекта» потому, что она, как правило, описывает только
часть всей структуры информации [1–5].
 Модель уровня сущностей является моделью верхнего уровня и применяется для ра-
боты проектировщика информационной системы с экспертами моделируемой системы. Мо-
дель включает сущности и связи между ними, которые отражают основные бизнес-правила
предметной области, и допускает присутствие всех типов связей (определенных, неопределен-
ных, типа «Категория»). Графическое представление этой модели называется ER-диаграммой.
Модель уровня ключей является дальнейшим развитием ER модели и содержит более
подробное представление данных. Она содержит описание всех сущностей, связей между
ними, первичных и внешних ключей. Эта модель не допускает наличия неопределенных свя-
зей и требует их предварительного преобразования в определенные связи. Модель является
переходным звеном от модели уровня сущностей к полному логическому описанию предмет-
ной области. Графическое представление этой модели называется KB-диаграммой (Key Based
Diagram).
Полноатрибутивная модель является дальнейшим развитием модели уровня ключей и
представляет собой законченное (в рамках конкретного проекта) описание предметной обла-
сти. Модель содержит описание всех сущностей, связей и атрибутов, выделенных при анализе
предметной области. В дальнейшем эта модель может быть использована при построении фи-
зической модели базы данных реляционного типа. Графическое представление этой модели
называется FA-диаграммой (рис. 1).

Рис. 1. Уровни проектирования базы данных IDEF1X

В соответствии с методологией стандарта IDEF1X построение модели осуществляется
поэтапно путем последовательного выполнения следующих фаз проектирования:
1. Определение сущностей.
2. Построение модели уровня сущностей.
3. Построение модели уровня ключей.
4. Построение полноатрибутивной модели.

Стадия 1 - определение сущностей

Целью стадии 1 является выявление и определение сущностей, находящихся в пределах

моделируемой проблемной области. Первым шагом в этом процессе является идентификация
сущностей.
"Сущность" представляет в контексте IDEFlX-модели множество "предметов", облада-
ющих связанными с ними данными. Здесь "предмет" может быть отдельной физической суб-
станцией, событием, состоянием, действием, идеей, понятием, точкой, местом и т.д. Элементы
представляемого сущностью множества обладают общим набором атрибутов или характери-
стик. Сущности всегда именуются общими существительными в единственном числе. Они
должны иметь атрибут (ключ), однозначно идентифицирующий каждый из их экземпляров.
 Большинство сущностей могут быть прямо или косвенно определены на основе исход-
ного материала, собранного на стадии предпроектного исследования. Если при моделирова-
нии расширяется или детализируется предшествующая модель данных, то соответствующие
сущности должны быть выделены из прежней модели.
Для облегчения отделения сущностей от «несущностей» разработчик модели должен
задать себе следующие вопросы, касающиеся каждой возможной сущности:
 Может ли она быть описана? (Обладает ли она характерными особенностями?)
 Существует ли более одного экземпляра этой сущности?
 Может ли один экземпляр быть отделен от другого (идентифицирован)?
 Называет или описывает это что-либо? (Из положительного ответа следует, что это ско-
рее атрибут, чем сущность.)
В конце такого анализа разработчик определяет начальный пул (накопитель) сущно-
стей. Данный пул содержит все известные на данный момент имена сущностей в контексте
модели.
При построении пула сущностей разработчик присваивает каждой записи свой иденти-
фицирующий номер и записывает ссылку на ее источник, если такой имеется в проекте. Таким
образом, поддерживается возможность отслеживания информации. Целостность пула оста-
ется ненарушенной, а управление пула - сравнительно легким. Пример пула сущностей пока-
зан на рис.2.

Номер Имя сущности Номер источника

Е-1 Платежное требование 2
Е-2 Расходный ордер 2
Е-3 Приходный ордер 2
Е-4 Реестр платежных поручений 3
Е-5 Смета 6
Е-6 Личная карточка сотрудника 4
Е-7 Ведомость на выдачу зарплаты 8
Е-8 Журнал учета больничных листов 8
Е-9 Сотрудник 10
Е-10 Квалификация сотрудника 10
Е-11 Отдел 6
Е-12 Филиал 6
Е-13 Журнал дежурного 12
Е-14 Счет 11
Е-15 Рабочая карта 12
Е-16 График мастера 14
Е-17 Материалы 15
Е-18 Доступность материалов 15
Е-19 Оборудование для обработки материалов 15
Е-20 Требования к материалам 15
Рис. 2. Пул сущностей
По всей вероятности, не все имена в списке останутся сущностями к концу стадии 4.
Кроме того, к этому списку добавится ряд новых сущностей, которые станут частью инфор-
мационной модели по мере ее развития и улучшения понимания информации.
Обнаруженные на последующих стадиях имена сущностей должны добавляться в пул
сущностей и приобретать уникальные идентифицирующие номера. Одним из результатов де-
ятельности на стадии 1 является пул сущностей. Он должен обновляться, чтобы оставаться
жизнеспособным.
 Еще одним результатом стадии 1 является начало работы над глоссарием сущностей.
На протяжении этой стадии глоссарий представляет собой просто набор определений сущно-
стей.
Определение сущности включает следующие компоненты:
1. ИМЯ СУЩНОСТИ
Имя сущности является уникальным именем, с помощью которого сущность будет рас-
познаваться в IDEFlX-модели. Оно должно быть описательным. Хотя допускаются аббревиа-
туры и акронимы, имя сущности должно быть осмысленным.
2. ОПРЕДЕЛЕНИЕ СУЩНОСТИ
Это то определение сущности, которое обычно используется на предприятии. Оно не
задумано как часть словаря. Поскольку смысл отражаемой в модели информации зависит от
точки зрения модели и от определенного на стадии 0 (предпроектного исследования) контек-
ста модели, то бессмысленно (а может быть, и вредно) включать сюда определения, не входя-
щие в область действия на стадии 0. Однако могут быть небольшие различия смысловых от-
тенков в способе определения сущности, зависящие, главным образом, от контекстуального
использования. В этих случаях или при наличии альтернативных определений (которые могут
не быть наиболее общеупотребительными с точки зрения модели) они должны быть также
записаны. Рецензенты по своему усмотрению устанавливают, какое определение должно быть
связано с термином, употребляемым для определения сущности. Процесс определения на ста-
дии 1 является средством ускорения формирования общепринятого определения.
3. СИНОНИМЫ СУЩНОСТИ
Это список других имен, под которыми сущность может быть известна. Единственным
относящимся к этому правилом является то, что определение, связанное с именем сущности,
должно в точности применяться к каждому из синонимов в списке.
Определения сущностей формулировать легче, если начинать с сущностей, требующих
наименьшего количества исследований. Таким образом, объем глоссария увеличится за крат-
чайшее время. Затем разработчик сможет проводить исследования для полного определения
оставшихся имен в пуле. Четкое планирование времени и усилий на сбор и определение ин-
формации обеспечит разумный темп процесса моделирования.

Стадия 2 - определение отношений

Целью стадии 2 является выявление и определение основных отношений между сущ-

ностями. На этой стадии моделирования некоторые отношения могут быть неспецифическими
и потребуют дополнительной детализации на последующих стадиях. Главными результатами
стадии 2 являются:
 матрица отношений;
 определения отношений;
 диаграммы уровней сущностей.
Отношение может быть определено просто как ассоциация или связь между двумя сущ-
ностями. Экземпляр отношения - это имеющая смысл ассоциация или связь между двумя эк-
земплярами сущностей. IDEFlX-отношение представляет множество однотипных образцов
отношений между двумя специфическими сущностями. При этом одна и та же пара сущностей
может обладать отношениями нескольких типов.
Целью IDEF1X является не изображение всех возможных отношений, а определение
взаимосвязей между сущностями в терминах отношений зависимости существования (от-
ношений родитель-потомок). Такое отношение - это ассоциация между типом родительской
сущности и типом сущности-потомка, при которой каждый экземпляр родительской сущности
ассоциирован с произвольным (в том числе нулевым) количеством экземпляров сущности-по-
томка, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром
родительской сущности. Это означает, что существование сущности-потомка зависит от су-
ществования родительской сущности.
 Если сущность-родитель и сущность-потомок представляют один и тот же объект ре-
ального мира, то родительская сущность является общей сущностью, а сущность-потомок яв-
ляется сущностью-категорией. Для каждого экземпляра сущности-категории всегда имеется
один экземпляр общей сущности. Для каждого экземпляра общей сущности может существо-
вать ноль или один экземпляр сущности-категории.
В начале разработки модели часто невозможно представить все отношения как отно-
шения родитель-потомок или отношения категоризации. Поэтому неспецифические отноше-
ния «Many-to-Many» на стадии 2 должны быть преобразованы в специфические. «Zero, One or
More».
Итак, первым шагом на стадии 2 является выявление отношений между элементами
различных сущностей. Эта задача может потребовать разработки матрицы отношений, пример
которой приведен на рис. 3. Матрица отношений - это двумерный массив, обладающий гори-
зонтальной и вертикальной осями. Множество предопределенных факторов (в данном случае
- все сущности) записывается вдоль одной из осей, а другое множество факторов (в данном
случае - также все сущности) - записывается вдоль другой оси. Для указания на возможное
отношение между двумя сущностями в точке пересечения соответствующих осей помещается
знак "+". В этот момент суть отношения не важна: достаточно того, что отношение может су-
ществовать.
Матрица "сущность-отношение" отражает только сам факт существования отношения
некоторого типа (рис.3).
Студент Дисциплины Преподаватель Группа Контакт
Студент + +
Дисциплины + +
Преподаватель + +
Группа + +
Контакт +
Рис. 3. Матрица Сущность-Отношение (БД «Учебная»)
Разработчики-новички обычно устанавливают, чрезмерное количество отношений
между сущностями. Помните, что целью в конечном итоге является определение модели в
терминах отношении родитель-потомок. Избегайте косвенных отношений.
Более опытные разработчики предпочитают наброски диаграммы уровней сущ-
ностей, а не составление матрицы отношений. Однако важно определять отношения в про-
цессе их выявления.
Следующим шагом является определение выявленных отношений. Эти определения
включают:
 указание зависимостей;
 имя отношения;
 комментарии к отношениям.
В ходе определения отношений некоторые из них могут отбрасываться, а новые добав-
ляться.
Для установления зависимости отношение между двумя сущностями должно быть про-
верено в обоих направлениях. Это делается посредством определения мощности на каждом
конце отношения. Для определения мощности предположите существование экземпляра од-
ной из сущностей. Затем определите, сколько различных экземпляров второй сущности может
быть связано с первой. Повторите анализ, поменяв сущности ролями.
Установив зависимость отношения, разработчик должен выбрать имя и начать описа-
ние отношения. Имя отношения является кратким выражением, обычно глаголом с союзом,
присоединяющим вторую упомянутую сущность. Это выражение отражает смысл представ-
ляемого отношения. Часто имя отношения состоит из одного глагола, хотя наречия и предлоги
также появляются в именах отношений. После выбора имени отношения разработчик должен
иметь возможность, читая отношения, получать осмысленное предложение, определяющее
или описывающее отношение между двумя сущностями.
 При специфической форме отношения всегда имеются сущность-родитель и сущность-
потомок; имя отношения интерпретируется сначала со стороны сущности-родителя, а затем
от сущности-потомка к сущности-родителю.
При неспецифической форме отношения существует два имени отношения, по одному
для каждой сущности, разделенные знаком "/". В этом случае имена сущностей интерпрети-
руются сверху вниз или слева направо (в зависимости от относительных положений сущно-
стей на диаграмме), а затем в обратном направлении.
Имена отношений должны быть осмысленными. Под их именами должна быть реаль-
ная основа. Полное значение, т.е. причина выбора разработчиком данного имени отношения,
может быть отражено в определении отношения. Определение отношения - это текст, объяс-
няющий смысл отношения. Правила для определения сущностей применяются и к определе-
ниям отношений.
Определения отношений должны быть:
 специфическими,
 краткими,
 осмысленными.
После определения отношений можно начать строить диаграммы уровней сущностей,
изображая графически эти отношения. Пример диаграммы уровней сущностей приведен на
рис. 4.

Рис. 4. Диаграмма уровней сущностей (БД «Учебная»)

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

Стадия 3 - определения ключей

Целями стадии 3 являются:

 Детализация неспецифических отношений из стадии 2.
 Определение ключевых атрибутов для каждой сущности.
 Перемещение первичных ключей для установления внешних ключей.
 Проверка правильности отношений и ключей.
Результаты стадии 3 изображаются на одной или нескольких диаграммах (диаграммах
ключевого уровня). Помимо определения ключевых атрибутов на стадии 3 расширяются и де-
тализируются определения сущностей и отношений.
Первым шагом на этой стадии является детализация всех неспецифических отношений,
выявленных на стадии 2. На стадии 3 требуется использовать только специфическую форму
отношений: либо специфическое отношение связи (родитель-потомок), либо отношение кате-
горизации. Чтобы выполнить это требование, разработчик предлагает варианты детализации.
Процесс детализации отношений приводит, или конвертирует, каждое неспецифиче-
ское отношение в два специфических отношения. В этом процессе возникают новые сущно-
сти. Если на более ранних стадиях мы имели дело с сущностями, которые могли бы нефор-
мально назвать естественными, то на стадии 3 начинают появляться ассоциативные сущности,
которые могут быть неформально названы сущностями пересечения. Сущности пересечения
используются для разрешения неспецифических отношений и обычно представляют упорядо-
ченные пары предметов с теми же основными характеристиками (уникальный идентификатор,
атрибуты и т.д.), что и естественные сущности.
Сущности пересечения являются по своей природе более абстрактными и обычно по-
являются в результате впервые примененных на стадии 3 правил определения правильности
сущностей. Первым из этих правил является правило, требующее детализации всех неспеци-
фических отношений. Этот процесс детализации является первым главным этапом детализа-
ции объединенной структуры данных.
Процесс детализации включает:
1. Разработку для каждого неспецифического отношения одного или нескольких вари-
антов детализации.
2. Выбор разработчиком предпочтительного варианта, который и будет отражен в мо-
дели на стадии 3.
3. Обновление информации стадии 1 с целью включения возникших при детализации
новых сущностей.
4. Обновление информации стадии 2 с целью определения отношений, связанных с но-
выми сущностями.

Рис. 5. Разрешение неспецифических отношений (БД «Учебная»)

Определение ключевых атрибутов

На стадии 3 методологии IDEF1X идентифицируются и определяются элементы дан-
ных об экземплярах сущностей, называемых возможными ключами, первичными ключами,
альтернативными ключами и внешними ключами. Цель этого этапа - установить значения ат-
рибутов, однозначно определяющих каждый экземпляр сущности.
Важно подчеркнуть определение и смысл терминов "экземпляр атрибута" и "атрибут".
Экземпляр атрибута является свойством или характеристикой экземпляра сущности. Экзем-
пляры атрибутов составляются из имени и значения. Другими словами, экземпляр атрибута
является элементом информации, известной об отдельном экземпляре сущности. Экземпляры
атрибутов являются описателями, т.е. они по сути скорее подобны прилагательным.
Атрибут представляет использование экземпляра атрибута для описания отдельного
специфического свойства отдельного экземпляра сущности. Кроме того, некоторые атрибуты
представляют использование экземпляра атрибута для однозначного установления специфи-
ческого экземпляра сущности. Эти атрибуты неформально называются ключевыми атрибу-
тами.
На стадии 3 производится идентификация ключевых атрибутов в контексте нашей мо-
дели. На стадии 4 устанавливаются и определяются неключевые атрибуты.
Один или несколько атрибутов образуют возможный ключ сущности. Возможный
ключ определяется как один или несколько ключевых атрибутов для однозначной идентифи-
кации каждого экземпляра сущности.
 Для сущности выбирается один возможный ключ для использования в миграции клю-
чей. Этот ключ называется первичным ключом, а остальные возможные ключи - альтернатив-
ными ключами. Если сущность обладает только одним возможным ключом, то он автомати-
чески является первичным ключом. Таким образом, каждая сущность обладает первичным
ключом, а некоторые сущности обладают также альтернативными ключами. Каждый тип воз-
можных ключей может применяться для идентификации экземпляров сущностей, но только
первичный ключ используется в миграции ключей.
Процесс идентификации ключей включает:
1. Идентификацию возможных ключей сущности.
2. Выбор одного из них в качестве первичного ключа сущности.
Поскольку некоторые возможные ключи могут возникнуть в результате миграции,
идентификация ключей - итеративный процесс. Начинайте с тех сущностей, которые не явля-
ются ни в каких отношениях сущностями-потомками или сущностями-категориями.
Это обычно те сущности, чьи возможные ключи наиболее очевидны. Они являются
также начальными точками для миграции ключей, поскольку не содержат внешних ключей.

Миграция ключей
Миграция ключей - это процесс копирования первичного ключа одной сущности в дру-
гую, связанную с ней сущность. Эта копия называется внешним ключом. Значение внешнего
ключа в каждом экземпляре второй сущности совпадает со значением связанного экземпляра
первой сущности. Таким образом атрибут, принадлежащий одной сущности, разделяется с
другой сущностью. Миграция ключей подчиняется следующим трем правилам:
1. Миграция всегда происходит в отношении от родительской или общей сущно-
сти к сущности-потомку или сущности-категории.
2. Весь первичный ключ (т.е. все атрибуты, являющиеся элементами первичного
ключа) должен мигрировать по одному разу для каждого отношения, разделяемого парой сущ-
ностей.
3. Альтернативный ключ и неключевые атрибуты никогда не мигрируют.
Каждый атрибут внешнего ключа соответствует атрибуту первичного ключа родитель-
ской или общей сущности. Первичный ключ сущности-категории в категориальном отноше-
нии должен совпадать с первичным ключом общей сущности. В других отношениях атрибут
внешнего ключа может, но не обязан быть частью первичного ключа сущности-потомка. Ат-
рибуты внешних ключей не считаются принадлежащими сущностям, в которых они появля-
ются, поскольку они отражают атрибуты родительских сущностей. Таким образом, каждый
атрибут в сущности либо принадлежит этой сущности, либо принадлежит внешнему ключу
этой сущности.
В диаграммах модели внешние ключи обозначаются примерно так же, как альтернатив-
ные ключи, т.е. после каждого атрибута, принадлежащего внешнему ключу, следует (FK).
Если атрибут принадлежит также первичному ключу, то он располагается выше горизонталь-
ной линии, а если нет, то - ниже. Если первичный ключ сущности-потомка содержит все атри-
буты внешнего ключа, то сущность-потомок называется зависимой от идентификатора отно-
сительно родительской сущности, а отношение называется идентифицирующим отношением.
Если какие-либо атрибуты внешнего ключа не принадлежат первичному ключу сущности-по-
томка, то сущность-потомок не является независимой от идентификатора относительно роди-
тельской сущности, а отношение называется неидентифицирующим.

Проверка правильности ключей и отношений

Идентификация и миграция ключей подчиняется следующим основным правилам:
1. Нельзя использовать синтаксис неспецифических отношений.
2. Миграция ключей от родительских (или общих) сущностей к сущностям-потом-
кам (или сущностям-категориям) является обязательной.
 3. Запрещается использовать атрибуты, которые могут принимать более одного
значения для данного экземпляра сущности в одно и то же время (правило неповторяемости).
4. Нельзя использовать атрибуты, обращающиеся в ноль (т.е. не принимающие ни-
какого значения) для некоторого экземпляра сущности (правило необращения в ноль).
5. Сущности с составными ключами не могут быть разбиты на несколько сущно-
стей с более простыми ключами (правило наименьшего ключа).
6. Необходимо объявлять об имеющихся между двумя сущностями двойных путях
отношений.
Каждый составной ключ должен проверяться на соответствие правилу наименьшего
ключа. Это правило требует, чтобы любая сущность с составным ключом не могла разделяться
на несколько сущностей с более простыми ключами (на меньшие компоненты) без потери не-
которой информации. Это правило является комбинацией и расширением четвертой и пятой
нормальных форм в реляционной теории. Другие правила нормализации, такие, как правило
полной функциональной зависимости или правило отсутствия транзитивной зависимости, не
могут применяться до тех пор, пока на стадии 4 неключевые атрибуты не будут отражены в
модели.
В процессе проектирования еще на стадии 2 может быть поставлена задача выявления
избыточных отношений, однако, в основном, решение этой задачи проводится разработчиком
по его усмотрению. На стадии 3, после установки ключей, разработчик может быть более точ-
ным в анализе. Двойной путь отношений существует тогда, когда существует сущность-пото-
мок с двумя отношениями, ведущими, в конечном итоге, обратно (через одно или несколько
отношений) к общей "корневой" сущности-родителю. В случае существования двойных путей
требуется утверждение пути, чтобы определить, являются ли пути равными, неравными или
неопределенными. Пути равны, если для каждого экземпляра сущности-потомка оба пути от-
ношений всегда ведут к одному и тому же экземпляру корневой родительской сущности. Пути
являются неравными, если для каждого экземпляра сущности-потомка оба пути отношений
всегда ведут к различным экземплярам корневой родительской сущности. Пути являются не-
определенными, если они равны для некоторых экземпляров сущности-потомка и не равны
для остальных экземпляров. Если один из путей состоит только из одного отношения и пути
равны, то путь из одного отношения является излишним и должен быть удален.
Простейшим случаем отношения, имеющего двойственные пути, является отношение,
в котором оба пути состоят из единственного отношения. Если один из путей содержит не-
сколько отношений, а другой путь содержит одно отношение, то такая структура называется
триадой. На рис. 6 приведен пример триады. В этом случае СЛУЖАЩИЙ связан с ОТДЕЛЕ-
НИЯМИ как прямо, так и косвенно, через ОТДЕЛ. Если утверждение пути состоит в том, что
ОТДЕЛЕНИЕ, которому принадлежит СЛУЖАЩИЙ, содержит ОТДЕЛ, которому принадле-
жит СЛУЖАЩИЙ, то отношение между сущностями ОТДЕЛЕНИЯ и СЛУЖАЩИЙ является
избыточным и должно быть удалено. Заметим, что если некоторые, но не все, СЛУЖАЩИЕ
могут в действительности принадлежать двум различным отделениям, то должна быть добав-
лена еще одна сущность; такая, как ВРЕМЕННЫЙ_СЛУЖАЩИЙ, чтобы НОМЕР_ОТДЕЛЕ-
НИЯ удовлетворял правилу необращения в ноль в качестве внешнего ключа сущности СЛУ-
ЖАЩИЙ.
 Рис. 6. Пример триады
Утверждения могут также применяться к отношениям двойственных путей, когда оба
пути раскрывают более одного отношения. В приведенном на рис. 7 примере между сущно-
стями ОТДЕЛ и ИСПОЛНИТЕЛЬ_ЗАДАНИЯ существуют два пути отношений. Если СЛУ-
ЖАЩИЙ может быть приписан только к тому ПРОЕКТУ, которым руководит его ОТДЕЛ, то
пути равны. Если СЛУЖАЩИЙ может быть приписан только к тому ПРОЕКТУ, которым ру-
ководит не его отдел, то пути не равны. Если СЛУЖАЩИЙ может быть приписан к ПРОЕКТУ
независимо от того, руководит его ОТДЕЛ ПРОЕКТОМ или нет, то пути являются неопреде-
ленными. Обычно, пути предполагаются неопределенными, если только утверждения точно
не определены. Утверждения должны быть добавлены в качестве примечаний к диаграммам
стадии 3 и включены в определение сущности-потомка.

Рис. 7. Утверждения пути

После идентификации элементов первичного ключа производятся записи в пул атрибу-
тов. Для идентификации распределения и использования атрибутов в модели может приме-
няться матрица сущность/атрибут. Эта матрица обладает следующими свойствами:
1. Все имена сущностей изображаются с краю.
2. Все имена атрибутов изображаются наверху.
3. Использование атрибутов сущностями изображается в соответствующей строке с по-
мощью следующей кодировки: "О" = владелец, "К" = первичный ключ, "I" = насле-
дуемый.
 Пример матрицы сущность/атрибут приведен на рис.8. Эта матрица является основным
средством поддержки целостности модели.
СУЩНОСТИ * Имена соответствующих атрибутов приведены в таблице 1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Условия по- 1 OK I
купки
Покупатель 2 OK
Продавец 3 OK
Заказ 4 I I OK
Оформитель 6 OK
Деталь 9
Пункт заказа 10 IK
Строка заказа 12 IK
Администра- 21 IK
тор
Поставщик 22
* Таблица №1
№ АТРИБУТЫ № АТРИБУТЫ
1 Номер условий покупки 12 Имя оформителя
2 Код покупателя 13 Код отдела
3 Код продавца 14 Послать через …
4 Код заказа 15 Имя покупателя
5 Номер изменения 16 Номер заказа
6 Пункт назначения 17 Дата пункта заказа
7 Имя продавца 18 Код получателя
8 Адрес продавца 19 Код налога
9 Код подтверждения 20 Код дилера
10 Имя подтверждающего лица 21 Номер бланка
11 Код дополнительных копий 22 Условия платежа
Рис. 8. Матрица "Сущности/Атрибуты"
После установления ключей наступает момент для определения атрибутов, которые
были использованы в качестве ключей (на стадии 3 определения разрабатывались только для
ключевых атрибутов). Для этих определений будут использоваться те же основные принципы:
определения должны быть точными, специфическими, полными и универсально понимае-
мыми.
Определения атрибутов всегда ассоциированы с сущностями, владеющими этими ат-
рибутам, т.е. они всегда являются элементами набора документов сущностей-владельцев. По-
этому достаточно просто определить атрибуты, которые принадлежат каждой сущности и ис-
пользуются в этом первичном или альтернативном ключе сущности. В примере из рис. 7 эти
атрибуты кодируются ОК в матрице сущность/атрибут.
Определение атрибута включает:
 имя атрибута;
 определение атрибута;
 синонимы атрибута.

Изображение результатов стадии 3

Далее представления могут теперь быть обновлены для отражения и детализации отно-
шений. Диаграммы, построенные на стадии 3, должны изображать:
 атрибуты первичных, альтернативных и внешних ключей;
 независимые (с прямыми углами) и зависимые (с закругленными углами) сущности;
 идентифицирующие (сплошная линия) и неидентифицирующие (штриховая линия) от-
ношения.
На рис. 9 приведен пример диаграммы, формируемой на стадии 3.
 Рис. 9. Пример диаграммы, сформированной
на стадии 3 (БД «Учебная»)
Большую часть информации, полученной в результате анализа на этой стадии, содер-
жат сами сущности. Каждый набор документов сущности содержит:
 определение сущности;
 список атрибутов первичных, альтернативных и внешних ключей;
 определения принадлежащих сущности ключевых атрибутов;
 список отношений, в которых сущность является общей;
 список отношений, в которых сущность является сущностью-категорией;
 список идентифицирующих отношений, в которых сущность является сущностью-ро-
дителем;
 список идентифицирующих отношений, в которых сущность является сущностью-по-
томком;
 утверждения двойных путей (в случае необходимости).
Если нужно, разработчик может построить для сущности отдельную диаграмму, следуя
тому же подходу, что и при построении необязательной диаграммы сущности
на стадии 2.
Помимо табличных списков определений отношений, полезны перекрестные обратные
ссылки на ассоциированные сущности. В документах, разработанных на стадии 3, необходимо
перекрестно ссылаться на те атрибуты, которыми сущности обладают, и на те, которые они
разделяют.

Стадия 4 - определение атрибутов

Стадия 4 является завершающей стадией разработки модели. Она включает:

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

Идентификация неключевых атрибутов

Построение пула атрибутов было начато при идентификации ключей на стадии 3. Пер-
вым шагом на стадии 4 является расширение пула атрибутов для включения неключевых ат-
рибутов. Пул атрибутов - это набор потенциально жизнеспособных имен атрибутов. Каждое
имя в пуле атрибутов встречается только один раз. Каждому имени присваивается единствен-
ный идентифицирующий номер.
Процесс построения пула атрибутов похож по сути на построение пула сущностей
(рис.10). На стадии 1 мы выбирали из списка исходных данных стадии 0 имена, появлявшиеся
в качестве существительных-объектов. Теперь мы вернемся к списку исходных данных и вы-
берем имена, появляющиеся в качестве описательных существительных. Описательные суще-
ствительные (существительные для описания объектов) обычно представляют атрибуты.
На стадии 1 в пул сущностей в качестве потенциальных сущностей было введено много
имен из списка исходных данных стадии 0. Некоторые из этих имен, однако, могли не быть
признаны на стадии 3 в качестве сущностей. По всей вероятности они являются атрибутами.
Кроме того, многие из имен, не выбранные из списка исходных данных сначала, являются,
возможно, атрибутами. Этот список, в сочетании со сведениями, полученными на стадиях 1 и
2, является основой для установления пула атрибутов. Пул атрибутов является списком потен-
циально жизнеспособных атрибутов, замеченных в контексте модели. Этот список будет, по
всей вероятности, заметно больше пула сущностей.
Номер Имя атрибута Номер исх. данных
1 Номер заказа на покупку 1
2 Код покупателя 2
3 Имя продавца 3
4 Код заказа 4
5 Номер замены 5
6 Куда отгружен 6
7 Имя продавца 8
8 Адрес продавца 8
9 Код упаковщика 9
10 Имя упаковщика 9
11 Имя заказчика 11,42
... ... ...
Рис. 10. Пример пула атрибутов
Пул атрибутов является источником имен, используемых в модели. Атрибуты, появив-
шиеся на более поздних стадиях моделирования, добавляются в пул атрибутов и им приписы-
ваются уникальные идентифицирующие номера. Затем они развиваются для дальнейшего ис-
пользования в модели.

Определение владельцев атрибутов

На следующем этапе каждый неключевой атрибут должен быть приписан к одной сущ-
ности-владельцу. Для многих атрибутов сущности-владельцы очевидны. Например, разработ-
чик без заминки свяжет атрибут ИМЯ-ПРОДАВЦА с сущностью ПРОДАВЕЦ. Однако неко-
торые атрибуты могут вызвать у разработчика трудности при определении их сущностей-вла-
дельцев.
Если разработчик не уверен в сущности-владельце для атрибута, он может обратиться
к исходному материалу, откуда был выбран атрибут. Это поможет в определении владельца.
На стадии 0 был сформирован список исходных данных, ставший основой пула атрибутов.
Этот список указывает разработчику места, где значения представленных атрибутов исполь-
зовались в исходном материале. Анализ примеров использования атрибута в исходном мате-
риале упрощает поиск сущности-владельца в модели. Он должен иметь в виду, что главен-
ствующим фактором в определении владельцев атрибутов является вхождение экземпляров
атрибутов, представленных отражаемыми в исходном материале значениями атрибутов. По-
сле того, как каждому атрибуту будет назначена сущность-владелец, это назначение должно
быть зафиксировано.
 Определение атрибутов
Для всех выявленных на стадии 4 атрибутов должны быть разработаны определения.
Здесь также применимы основные принципы построения определений, уже используемых в
модели данных (в особенности из стадии 3). Разработанные определения должны быть точ-
ными, специфическими, полными и универсально понимаемыми. Эти определения атрибутов
записываются в том же формате, что и определения атрибутов из стадии 3.
Определение атрибута включает:
 имя атрибута;
 определение атрибута;
 синонимы/псевдонимы атрибута.
Каждому атрибуту должно быть присвоено уникальное имя, поскольку в IDEFlX-мо-
дели и к сущностям, и к атрибутам применяется правило "одно и то же имя - один и тот же
смысл". Поэтому разработчик может воспользоваться стандартным подходом к именам атри-
бутов. Однако для облегчения чтения при проверке правильности лучше использовать при-
вычные для пользователя естественные названия. Если встречаются имена атрибутов, которые
должны удовлетворять строгим правилам языка программирования (например, ограничен-
ность имен переменных в фортране семью символами), то они должны всегда идентифициро-
ваться как псевдонимы или не включаться вовсе.
В определении атрибута разработчик может пожелать установить формат атрибута,
например, буквенно-цифровой код, текст, денежные единицы, дату и т.д. В определении мо-
жет быть также установлена область допустимых значений в формате списка (например, по-
недельник, вторник, среда, четверг, пятница) или диапазона (например, больше нуля, но
меньше десяти).

Детализация модели
Теперь разработчик готов начать детализацию отношений на стадии 4. Здесь использу-
ются те же основные правила, что и на стадии 3. Правила необращения в ноль и неповторяе-
мости теперь применяются и к ключевым, и к неключевым атрибутам. В результате могут воз-
никнуть некоторые новые сущности. После идентификации этих сущностей должно приме-
няться правило миграции ключей точно так же, как на стадии 3.
После выявления новых сущностей они должны быть введены в пул сущностей, опре-
делены, отражены в матрице отношений и т.д. Короче говоря, новые сущности должны удо-
влетворять всем требованиям к документации, созданной на более ранних стадиях, с тем,
чтобы их можно было включить в материал стадии 4.
Должна быть также определена принадлежность каждого атрибута в соответствии с
правилом полной функциональной зависимости. Это правило утверждает, что ни одно значе-
ние неключевого атрибута, принадлежащего экземпляру сущности, не может быть идентифи-
цировано лишь частью значения ключа данного экземпляра сущности. Это правило приме-
нимо только к сущностям с составными ключами и эквивалентно второй нормальной форме
(2НФ) в реляционной теории.
Все атрибуты модели на стадии 4 должны также удовлетворять правилу отсутствия
транзитивной зависимости. Это правило требует, чтобы значение принадлежащего экзем-
пляру сущности неключевого атрибута не могло идентифицироваться значением другого при-
надлежащего экземпляру сущности или наследуемого ею неключевого атрибута. Это правило
эквивалентно третьей нормальной форме (3НФ) в реляционной теории.
 Рис. 11. База данных «Учебная» в 3НФ
Таким образом, студент проверяет соответствие отношений требованиям 3НФ, а на сле-
дующем этапе выполняет анализ транзакций.

Анализ транзакций на этапе логического проектирования

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

Представление результатов стадии 4

После определения атрибутов диаграммы функционального представления могут быть
теперь обновлены так, чтобы отразить детали модели, и расширены с тем, чтобы показать
неключевые атрибуты. Неключевые атрибуты перечисляются ниже линии внутри каждого
блока сущности. Для того чтобы внутри блока сущности хватило места, размеры блока могут
быть увеличены.
Соответствующие определения и информация для модели должны быть обновлены,
чтобы отразить определение неключевых атрибутов и их принадлежности. Эта дополнитель-
ная информация может быть представлена сущностью вместе с ранее определенной информа-
цией. Теперь каждый набор документов сущности будет содержать:
 определение каждой сущности;
 список первичных, альтернативных и внешних ключевых атрибутов;
 список принадлежащих сущности неключевых атрибутов;
 определение каждого принадлежащего сущности атрибута (как ключевого, так и
неключевого);
 список отношений, в которых данная сущность является родительской:
o - отношение категоризации;
o - идентифицирующие отношения указанного выше типа;
o - неидентифицирующие отношения указанного выше типа;
 список отношений, в которых данная сущность является сущностью-потомком:
o - отношение категоризации;
o - идентифицирующие отношения указанного выше типа;
 o - неидентифицирующие отношения указанного выше типа;
o утверждения всех двойных путей.
Необязательные диаграммы сущностей также могут быть расширены для указания
неключевых атрибутов.
Определения отношений могут быть повторены в комплекте документов для каждой
сущности или перечислены отдельно с перекрестными ссылками на эти сущности. Ключевые
и неключевые атрибуты должны быть также перечислены и снабжены перекрестными ссыл-
ками на эти сущности.

Стадия 5. Создание физической модели данных

Целью создания физической модели является обеспечение администратора соответ-

ствующей информацией для переноса логической модели данных в СУБД.
Напомним, что согласно IDEF1X различают два уровня физической модели:
трансформационная модель (Transformation Model);
модель СУБД (DBMS Model).
Целью трансформационной модели является предоставление информации администра-
тору БД для создания эффективной структуры хранения, включающей в себя записи, форми-
рующие БД. Трансформационная модель должна помочь-разработчикам выбрать структуру
хранения данных и реализовать систему доступа к ним.
Модель СУБД напрямую транслируется из трансформационной модели, являясь отоб-
ражением системного каталога. ERWin напрямую поддерживает эту модель через функцию
генерации схемы БД. При составлении схемы БД в качестве индексов могут использоваться
как ключевой атрибут, так и остальные поля БД.
Модель СУБД автоматически генерируется из трансформационной модели и является
точным отображением системного каталога СУБД. ERWin непосредственно поддерживает эту
модель путем генерации системного каталога.
ERWin поддерживает автоматическую генерацию физической модели данных для кон-
кретной СУБД. При этом логическая модель трансформируется в физическую по следующему
принципу: сущности становятся таблицами, атрибуты становятся столбцами, а ключи стано-
вятся индексами.
Сопоставление компонентов логической и физической модели
Логическая модель Физическая модель
Сущность Таблица
Атрибут Столбец
Логический тип (текст, число, дата, Физический тип (корректный тип, зависящий от вы-
blob) бранной СУБД)
Первичный ключ Первичный ключ, индекс РК
Внешний ключ Внешний ключ, индекс FK
Альтернативный ключ АК-индекс - уникальный, непервичный индекс
Правило бизнес- логики Триггер или сохраненная процедура
Взаимосвязи Взаимосвязи, определяемые использованием FK-ат-
рибутов

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

СУБД служит редактор Target Server (меню Server/Target Server доступно только на физиче-
ском уровне) (рис. 12).
 Рис.12. Выбор целевой СУБД
Перед построением физической модели необходимо выбрать тип СУБД в меню при со-
здании физической модели (для выполнения курсовой работы в качестве DataBase выбирают
Microsoft SQL Server).
В полученной модели необходимо скорректировать типы и размеры полей. Кроме того,
на этапе создания физической модели данных вводятся правила валидации колонок, опреде-
ляющие списки допустимых значений и значения по умолчанию.
Колонка Тип Размер Правило валидации
Номер BIGINT
Группа VARCHAR 7
Ф.И.О. VARCHAR 64
Возраст SMALLINT >10 и <100
Пол VARCHAR 1 M или Ж
E-mail VARCHAR 40
Форма обучения VARCHAR 1 Б или К
Дисциплина VARCHAR 30
Вид занятий VARCHAR 20 Лекции, практиче-
ские или лаборатор-
ные
Форма контроля VARCHAR 1 З или Э
Оценка SMALLINT >2и <5
Ф.И.О. преподавателя VARCHAR 64
… … … …
Рис.13. Свойства колонок таблиц физической модели
БД студентов
После установки правил валидации (для этого сначала надо дать имя Validation Name,
а затем отредактировать Validation Rule) в диалоговом окне Validation Rule Editor должны по-
лучиться следующие правила:
 Рис. 14. Правила валидации
Далее в диалоговом окне Column Editor необходимо присвоить соответствующим ко-
лонкам таблиц установленные для них правила (рис. 15).

Рис. 15. Физическая модель БД студентов

Анализ транзакций на этапе физического проектирования.

На этапе физического проектирования решаются вопросы, связанные с производитель-
ностью системы, определяются структуры хранения данных и методы доступа.
 Целью анализа транзакций на данном этапе является определение функциональных
характеристик транзакций, которые будут выполняться в базе данных, и выделение наиболее
важных из них.
Для того чтобы разрабатываемый физический проект базы данных обладал требуемым
уровнем эффективности, необходимо получить максимум сведений о тех транзакциях, кото-
рые будут выполняться в проектируемой базе данных. Нам потребуются как качественные,
так и количественные характеристики. Для каждой транзакции необходимо знать следующее:
 ожидаемая частота выполнения транзакций;
 отношения и атрибуты, к которым потребуется иметь доступ при выполнении транзак-
ции, а также тип этого доступа ( R – выборка, I – вставка, U – обновление, D – удаление
);
 ограничения, устанавливаемые на время выполнения транзакций.
Во многих случаях проанализировать все транзакции просто невозможно, поэтому
необходимо выбрать из них самые «важные». В схеме, на которой проводился анализ транзак-
ций на этапе логического проектирования, надо установить, какие из отношений наиболее ин-
тенсивно используются при выполнении транзакций.
Обычно 2-3 сущности имеют значительно большее количество, чем все остальные, а
для анализа на физическом этапе проектирования остается около 80% всех транзакций.
После определения наиболее важных транзакций подробно анализируется каждая из
них. Для каждой транзакции необходимое выяснить следующее.
 Отношения и атрибуты, к которым осуществляется доступ в процессе выполнения
транзакции, а также тип доступа; это означает определение того, выполняется ли в этой
транзакции вставка, обновление, удаление или выборка данных.
 При изучении транзакции обновления необходимо определить, какие атрибуты обнов-
ляются в данной транзакции, поскольку эти атрибуты могут потребовать применения
вспомогательных структур доступа.
 Атрибуты, которые используются в любых предикатах (в языке SQL предикатами яв-
ляются условия, указанные в конструкции WHERE). Проверка того, предусматривают
ли эти предикаты следующее:
o сопоставление с шаблоном, например name LIKE '%Smith%';
o поиск в диапазоне, например salary BETWEEN 10000 AND 20000;
o выборка по точному значению ключа, например salary = 30000.
 Следует учитывать, что такие атрибуты могут потребовать создания вспомогательных
структур доступа.
Далее необходимо указать ожидаемое количество строк в отношениях, а также сред-
нюю и максимальную кратности каждой связи. Например, ожидается, что персонал компании
составит 50 человек, 4 из которых менеджеры, 40 операторов. Компания владеет 500 объек-
тами жилья, на которые заключается 1000 договоров.
При анализе каждой из транзакций очень важно знать не только среднее и максималь-
ное количество ее вызовов в час, но и иметь сведения о тех днях недели и часах суток, когда
она обычно выполняется, включая и данные о времени пиковой нагрузки. Например, частота
вызова некоторых транзакций может удерживаться на некотором уровне постоянно, но все же
она имеет четко выраженный пик нагрузки в последний четверг месяца с 14-00 до 16-00, вы-
званный подготовкой отчетов. Другие транзакции вообще могут выполняться только в опре-
деленные моменты времени, например - по понедельникам с 9-00 до 10-00, что также является
пиком нагрузки.
Когда выполнение потока транзакций требует частого доступа к определенным отно-
шениям, очень большое значение приобретают выбранные для них схемы выполнения. Если
выполнение этих транзакций не зависит друг от друга, риск возникновения проблем с произ-
водительностью уменьшается. Однако если схемы их выполнения конфликтуют, возможные
проблемы могут быть частично устранены посредством тщательного изучения транзакций,
что позволит найти способ их модификации с целью повышения их производительности.
 Таким образом, составив описание транзакций, проектировщик базы данных готов, в
зависимости от полноты и достоверности собранной информации, принимать или отклады-
вать решение об изменении внутренней схемы базы данных с целью достижения требований
по производительности базы данных.
Проделав все вышеописанные стадии, разработчик получает модель БД, готовую для
помещения в СУБД.

3. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ СРЕДСТВАМИ MS SQL SERVER

Реализация базы данных выполняется с помощью выбранной СУБД (например, MS

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

Генерация базы данных

Для генерации таблиц и схемы данных в выбранной СУБД необходимо выполнить сле-
дующие действия:
 создать пустой файл базы данных;
 выполнить команду “DataBase” – “DataBaseConnection” и в появившемся диалоговом
окне в строке “DataBase” выбрать полный путь к созданному пустому файлу;
 выполнить команду “Tools” – “Forward Engineer” - «OK», после чего откроется окно
установки свойств генерируемой схемы данных.

Рис. 16. Установка свойств генерируемой схемы данных

Для предварительного просмотра SQL-скрипта служит кнопка Preview, для генерации
схемы - Generate. В процессе генерации ERWin связывается с БД, выполняя SQL-скрипт. Если
в процессе генерации возникают какие-либо ошибки, то она прекращается, открывается окно
с сообщениями об ошибках.
 Реализация транзакций средствами выбранной СУБД.
В специализацию транзакций необходимо добавить все транзакции, поддерживающие
пользовательские запросы, если они еще не включены. Часть этих транзакций можно реали-
зовать внутренними средствами СУБД.
В курсовую работу включается описание минимум 10 реализованных средствами
СУБД транзакций. В пояснительной записке необходимо привести их полное описание, вклю-
чающее код на Т –SQL, а также скриншоты с результатами выполнения .

ЗАКЛЮЧЕНИЕ.

В заключении пояснительной записки к курсовой работе необходимо в краткой форме

подвести выводы по проделанной работе, которые могут включать:
 Мнение студента о проделанной им работе;
 Отношение к изученному материалу;
 Оценку средств и методов проектирования.
 Оценку результатов проектирования и реализации индивидуального проекта.
 Приложение 1
Список возможных тем курсового проекта.
1. Разработка подсистемы организации продаж новых автомобилей в автосалоне.
2. Разработка подсистемы организации продаж подержанных автомобилей в автосалоне.
3. Разработка подсистемы организации проката автомобилей.
4. Разработка подсистемы организации проката видео-, аудио- и т.п. продукции.
5. Разработка подсистемы организации автоперевозок грузов.
6. Разработка подсистемы организации авиаперевозок грузов.
7. Разработка подсистемы организации авиаперевозок пассажиров.
8. Разработка подсистемы учета поселения гостей в гостинице.
9. Разработка подсистемы учета свободных номеров в гостинице.
10. Разработка подсистемы обслуживания посетителей в ресторане.
11. Разработка подсистемы обслуживания посетителей в баре.
12. Разработка подсистемы учета посетителей в поликлинике.
13. Разработка подсистемы учета записей на прием к врачам в поликлинике.
14. Разработка подсистемы работы с клиентами в фирме страхования.
15. Разработка подсистемы организации работы с клиентами в фирме страхования.
16. Разработка подсистемы учета выдачи книг в библиотеке.
17. Разработка подсистемы учета поступлений и списаний книг в библиотеке.
18. Разработка подсистемы организации денежных переводов.
19. Разработка подсистемы организации розничной торговли.
20. Разработка подсистемы организации оптовой торговли.
21. Разработка подсистемы организации складского хозяйства.
22. Разработка подсистемы организации торговли на заказ.
23. Разработка подсистемы организации торговли через Интернет.
24. Разработка подсистемы организации продажи театральных билетов.