Проектирование модели данных для информационной системы help desk

Методология IDEF1X [12] - один из подходов к семантическому моделированию данных, основанный на концепции «сущность-связь» (Entity-Relationship). Это инструмент для анализа информационной структуры систем различной природы. Информационная модель, построенная с помощью IDEF1X-методологии, отображает логическую структуру информации об объектах системы Таким образом, концептуальная модель, представленная в соответствии со стандартом IDEF1X, является логической схемой базы данных для проектируемой системы Основными объектами концептуальной модели являются сущности и связи.

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

Правила для атрибутов сущности:

• 1. Каждый атрибут должен иметь уникальное имя.
• 2. Сущность может обладать любым количеством атрибутов.
• 3. Сущность может обладать любым количеством наследуемых атрибутов, но наследуемый атрибут должен быть частью первичного ключа сущности-родителя.
• 4. Для каждого экземпляра сущности должно существовать значение каждого его атрибута (правило необращения в нуль — Not Null).
• 5. Ни один из экземпляров сущности не может обладать более чем одним значением для ее атрибута.

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

Стандарт IDEF1X описывает способы изображения двух типов сущностей — независимой и зависимой, и связей — идентифицирующих и неидентифицирующих.

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

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

Таблица 3.3 — Сущность заявка.

продолжение таблицы 3.3.

Диспетчеры. Список пользователей, сопоставленных с ролью «диспетчеры» .

Таблица 3.4 — Сущность диспетчер

Исполнители. Список пользователей, сопоставленных с ролью «исполнители» .

Таблица 3.5 — Сущность исполнитель.

Категории заявок. Список, служащий для категоризации заявок Таблица 3.6 — Сущность категории заявок.

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

Таблица 3.7 — Сущность службы (отделы).

Мы определили концептуальную модель, теперь можно перейти к созданию логической и физической модели с помощью программы ER Win Data Modeller (рисунки 3.12 и 3.13 соответственно).

Рисунок 3.12 — Логическая модель данных Логическая модель данных показывает основные объекты, данные о которых необходимо хранить в процессе работы информационной системы help desk отдела технической поддержки ООО Трейд. Для перехода на физический уровень следует исключить связи «многие ко многим», такая связь одна — «заявка — исполнители» (рисунок 3.13).

Рисунок 3.12 — Физическая модель данных Для устранения связей многие-ко-многим была введена дополнительная сущность: ремонтная бригада, которая соединяет исполнителей и заявку.