Проектирование структуры баз данных

Методология IDEF 1.x. IDEF1X [12] является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу "AS IS", тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем с помощью метода IDEF1) и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.

Преимущества IDEF1X Основным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая несомненно является значительным недостатком.

Информационная система хранит промежуточные данные в виде заявки в своей БД. Согласно данной методологии, [4], процесс построения информационной модели состоит из следующих шагов:

· определение сущностей; определение зависимостей между сущностями;

· задание первичных и альтернативных ключей;

· определение атрибутов сущностей;

· приведение модели к требуемому уровню нормальной формы;

· переход к физическому описанию модели: назначение соответствий имя сущности – имя таблицы, атрибут сущности – атрибут таблицы;

· задание триггеров, процедур и ограничений;

· генерация базы данных.

Логическая структура базы показана на рисунке 3.5.

Рисунок 3.3 – Логическая структура БД

Структура базы данных состоит из следующих сущностей:

Работник. Сущность, характеризующая работника, зарегистрированного на информационной системе. В ней будет храниться полный набор полей, которые необходимы работникам профсоюза.:

· Id работника – первичный ключ;

· Фамилия;

· Имя;

· Отчество;

· Дата рождения;

· Пол;

· Семейное положение;

· Количество детей;

· Место работы – внешний ключ в справочник подразделений;

· Должность.

Справочник подразделений. Сущность, описывающая всевозможные подразделения профсоюза строителей г. Геленджик:

· id (первичный ключ);

· Название;

· Подчинение – в чьем ведомстве находится;

· Тип – производственное, обслуживающее и т.д.;

· Начальник подразделения;

· Контактная информация.

Заявление. Сущность, экземпляры которой привязываются к конкретном работникам:

· № заявления (первичный ключ);

· Работник – внешний ключ в таблицу;

· Дата подачи;

· Тип;

· Содержание;

· Состояние обслуживания – внешний ключ в таблицу.

Профиль пользователя. Сущность описывающая работника на информационной системе:

· ID (первичный ключ);

· Логин;

· Пароль;

· Работник – внешний ключ в таблицу;

· Настройки кабинета – конфигурационный файл;

Статус обслуживания. Сущность, описывающая состояния заявок:

· Номер заявления (внешний ключ);

· Регистрационный номер;

· Местонахождение;

· Вердикт председателя профсоюза;

· Результат исполнения заявления.

Следующим шагом в разработке БД является переход от логической модели данных к физической. Используемая методология IDEF1x предполагает разработку реляционной БД, в которой физическая модель идентична логической. Заметим, что при переходе от логического уровня к физическому необходимо устранить связи «многие-ко-многим» посредством введения дополнительной сущности.

В проектируемой БД связи многие-ко-многим нет, поэтому физический уровень будет выглядеть следующим образом (рисунок 3.4).

Рисунок 3.4 – Физическая модель БД

На физической модели БД добавлены типы данных, которые изображены в левом столбце каждой сущности. Логика связей и структура таблиц осталась нетронутой. Таким образом, мною разработана структура БД, которая позволяет хранить всю необходимую для работы информационной системы профсоюза информацию.