79
Рис. 14. Сценарий диалога сайта технической поддержки инспекции
Дерево функций изображенное на Рисунке 15 наглядно демонстрирует
функционал программы. Как в любой программе функционал делится на две цели:
основную (задачи, для которых и выполнялся данный проект) и дополнительные (то,
что можно настроить, изменить и прояснить)
80
Рис. 15. Дерево функций
2.3.2 Характеристика базы данных
База данных (БД) – это совокупность специальным образом организованных
данных, хранимых в памяти вычислительной системы и отображающих состояние
объектов и их взаимосвязей в рассматриваемой предметной области.
Для проектирования концептуальной схемы базы данных на этапе построения
информационной модели используется методология IDEF1X. Концептуальной
схемой называют универсальное представление структуры данных, не имеющую
ориентацию на конкретную СУБД и аппаратную платформу. Стандарт методологии
IDEF1X базируется на модели типа «Сущность-связь». При построении
концептуальной модели выделяются следующие этапы проектирования[6]:
1. Определение сущностей и построение диаграммы сущность-связь.
81
2. Построение модели данных, основанной на ключах.
3. Построение полноатрибутной модели.
Основным преимуществом IDEF1X, по сравнению с другими
многочисленными методами разработки реляционных баз данных, такими как ER и
ENALIM является жесткая и строгая стандартизация моделирования.
Установленные стандарты позволяют избежать различной трактовки построенной
модели, которая, несомненно, является значительным недостатком ER -
моделирования.
Диаграмма сущность-связь (модель уровня сущностей) представляет собой
модель данных нижнего уровня. Она включает сущности и взаимосвязи,
отражающие основные бизнес-правила предметной области и допускает
присутствие всех типов связей (определенных, неопределенных, типа категория).
Графическое представление этой модели называется ER-диаграммой (Entity
Relationship Diagram).
В ходе анализа предметной области были выявлены следующие сущности:
Сотрудник (таблица содержит информацию о сотрудниках организации);
Специалист (таблица содержит информацию о специалистах отдела ИТ);
Заявка (таблица содержит информацию о заявках в отдел ИТ);
Сообщение (таблица содержит информацию о переписке по конкретной
заявке);
Софт (таблица содержит информацию о банковских приложениях).
Также были выявлены справочные сущности:
Должность (справочник содержит информацию о должностях организации);
Комната (справочник содержит информацию о помещениях, где работают
сотрудники);
Отдел (справочник содержит информацию об отделах, в которых работают
сотрудники);
Специализация (справочник содержит информацию о специализации работы
сотрудника отдела ИТ);
Тип сообщения (справочник содержит информацию о типах сообщения,
например, вопрос, ответ, дополнение);
82
Тип софта (справочник содержит информацию о типах банковского
приложения, например, макрос АБС, отчетность ЦБ);
Тип проблемы (справочник содержит информацию о типах возникающих
проблем);
Происхождение (справочник содержит информацию о вариантах заведения
заявки в системе);
Приоритет (справочник содержит информацию о приоритетах для заявок);
Состояние (справочник содержит информацию о состояниях заявки).
Модель уровня сущностей представлена на Рисунке 16.
Рис. 16. Модель уровня сущностей
Построение модели уровня ключей
Модель данных, основанная на ключах, — более подробное представление
данных. Она включает описание всех сущностей и первичных ключей,
предназначена для представления структуры данных и ключей, которые
соответствуют предметной области. Эта модель не допускает наличия
неопределенных связей и требует их предварительного преобразования в
определенные связи. Модель является переходным звеном от модели уровня
сущностей к полному логическому описанию предметной области. Графическое
представление этой модели называется KB-диаграммой (Key Based Diagram) [8].
В модели уровня сущностей присутствуют 2 связи «многие-ко-многим», для
разрешения такой ситуации вводятся дополнительные сущности:
83
1. «Сотрудник-Софт» содержит информацию о том, какие приложения
используются конкретными сотрудниками, указано н Рисунке 17. В этой
сущности необходимо использовать составной идентификатор из внешних
ключей, так как одно приложение может быть установлено сотруднику
только один раз.
Рис.17. Сущность «Сотрудник-Софт»
2. «Спец» содержит информацию о том, какие специализации относятся к
конкретным специалистам смотреть Рисунок 18. В этой сущности
необходимо использовать составной идентификатор из внешних ключей,
так как одна специальность может относиться к специалисту только один
раз.
Рис. 18 « Сущность «Спец»
Модель уровня ключей представлена на Рисунке 19.
84
Рис. 19. Модель уровня ключей
Полная атрибутивная модель — наиболее детальное представление структуры
данных: представляет данные в третьей нормальной форме и включает все
сущности, атрибуты и связи. Графическое представление этой модели называется
FA-диаграммой (Fully Attributed Diagram).
Полноатрибутная модель представлена на Рисунке 20.
85
Рис
. 20.
Полноатрибутная модель
86
Цель физического проектирования – преобразование логической модели с
учетом синтаксиса, семантики и возможностей выбранной целевой СУБД.
Соответственно физическая модель обладает всеми ограничениями, которые
накладывает конкретная СУБД.
Физическая модель включает в себя следующие основные компоненты:
набор базовых структурных элементов для представления данных и схем
данных (атрибуты, домены, схемы отношений);
правила порождения ограничений на допустимые состояния данных
(ограничения целостности).
В реляционной базе данных сущность, представленная в полноатрибутной
схеме, эквивалентна отношению реляционной модели данных. Каждой сущности
ставится в соответствие одно отношение. Этому отношению присваивается имя
соответствующей сущности. Каждое отношение наследует от сущности все ее
атрибуты с их именами и доменами. В связи с тем, что в инфологической модели все
связи между сущностями, допустимые в моделях реляционного типа, уже
реализованы посредством внешних ключей, в общем случае в результате этого
преобразования получается система связанных отношений.
На этапе физического проектирования связи задаются с помощью ограничений.
Ограничения базы данных - это правила, которые определяют взаимосвязи между
таблицами и могут проверять и изменять данные в базе данных. Реализованы эти
правила в виде особых объектов базы данных. Каждому полю таблицы
присваивается тип данных в соответствии с доменом атрибута сущности, от которой
произошло отношение.
Для реализации схемы базы данных используются операторы языка описания
данных (ЯОД) соответствующей СУБД. В современных реляционных СУБД
наиболее распространенным ЯОД является язык SQL (Structured Query Language -
язык структурированных запросов). В СУБД MS SQL Server реализован диалект
языка SQL, называемый Transact SQL, который помимо стандартных средств SQL
включает в себя большое число расширений, в их числе команды управления ходом
выполнения, функции работы с датой и временем, строковые функции и т.д.
Использование расширений языка SQL дает возможность разработчикам баз данных
87
реализовать логику обращения и обработки данных на уровне сервера БД,
посредством набора хранимых процедур.
Последовательность создания базы данных на сервера состоит из нескольких
шагов:
создание базы данных с указанным именем и установка прав доступа;
создание таблиц в порядке, не нарушающем использование внешних
ключей.
Физическая модель базы данных представлена на Рисунке 21. Текст SQL-
скрипта для создания базы приведен в Приложении 1.
88
Рис.
21. Физическая модель базы данных