Проектирование модели данных для информационной системы help desk
Методология IDEF1X [12]- один из подходов к семантическому моделированию данных, основанный на концепции "сущность-связь" (Entity-Relationship). Это инструмент для анализа информационной структуры систем различной природы. Информационная модель, построенная с помощью IDEF1X-методологии, отображает логическую структуру информации об объектах системы
Таким образом, концептуальная модель, представленная в соответствии со стандартом IDEF1X, является логической схемой базы данных для проектируемой системы
Основными объектами концептуальной модели являются сущности и связи.
Сущность - некоторый обособленный объект или событие моделируемой системы, имеющий определенный набор свойств - атрибутов. Отдельный элемент этого множества называется "экземпляром сущности". Сущность может обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый образец сущности, и может обладать любым количеством связей с другими сущностями.
Правила для атрибутов сущности:
Каждый атрибут должен иметь уникальное имя.
Сущность может обладать любым количеством атрибутов.
Сущность может обладать любым количеством наследуемых атрибутов, но наследуемый атрибут должен быть частью первичного ключа сущности-родителя.
Для каждого экземпляра сущности должно существовать значение каждого его атрибута (правило необращения в нуль - Not Null).
Ни один из экземпляров сущности не может обладать более чем одним значением для ее атрибута.
Сущность изображается на 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 – Физическая модель данных
Для устранения связей многие-ко-многим была введена дополнительная сущность: ремонтная бригада, которая соединяет исполнителей и заявку.