Концептуальное проектирование базы данных - это процесс создания модели используемой на предприятии информации, не зависящей от любых физических аспектов ее представления.

Логическое проектирование базы данных – это процесс создания модели используемой на предприятии информации на основе выбранной модели организации данных, но без учета типа целевой СУБД и других физических аспектов реализации.

Физическое проектирование базы данных - это процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах.

Одним из наиболее известных и получивших широкое распространение методов семантического моделирования является метод построения модели " сущность—связь" (или ER-модели, используемая на концептуальном уровне). Этот подход основан на использовании модели " сущность—связь" [40].

На рисунке ниже (рисунок 11) представлена ER–модель, семь сущностей и атрибуты, описывающие данные сущности.

Рисунок 11 - ER–модель

Сущность Справочник «Подразделения организации» описывается атрибутами:

1) Код подразделения;

2) Наименование.

Сущность Справочник «Причина проведения внепланового инструктажа» описывается атрибутами:

1) Код;

2) Наименование.

Сущность Справочник «Сотрудники организации» описывается атрибутами:

1) Наименование;

2) Подразделение;

3) Должность;

4) Вид договора;

5) Дата принятия на работу;

6) Аванс.

Сущность Справочник «Должности» описывается атрибутами:

3) Код;

4) Наименование.

Сущность Документ «Учет инструктажей» описывается атрибутами:

1) Номер документа

2) Вид инструктажа;

3) Инструктирующий;

4) Подразделение;

5) Дата следующего инструктажа;

6) Причина проведения инструктажа;

7) Организация;

8) Сотрудник.

Сущность Документ «Регистрация допусков сотрудников» описывается атрибутами:

1) Номер документа

2) Организация;

3) Сотрудник;

4) Должность;

5) Срок действия.

Сущность Регистр сведений «Инструктаж» описывается атрибутами:

1) Регистратор;

2) Вид инструктажа;

3) Подразделение организации;

4) Сотрудник;

5) Инструктирующий;

6) Дата прохождения инструктажа;

7) Дата следующего инструктажа.

Сущность Регистр сведений «Не прошедшие инструктаж» описывается атрибутами:

8) Регистратор;

9) Подразделение;

10) Организация;

11) Сотрудник;

12) Причина.

Сущность Регистр сведений «Допуски сотрудников» описывается атрибутами:

13) Регистратор;

14) Организация;

15) Сотрудник;

16) Дата получения допуска;

17) Срок действия.

Связь между сущностью Справочник «Подразделения организации» и сущностью Документ «Учет инструктажей» на рисунке представлена в виде: один ко многим. Связь между сущностью Справочник «Причина проведения внепланового инструктажа» и сущностью Документ «Учет инструктажей» также один ко многим, т.е. одной причине проведения инструктажа соответствует много документ. Связь между сущностью Справочник «Сотрудники Организации» и сущностью Документ «Учет инструктажей», связь между сущностью Справочник «Должности» и сущностью Документ «Учет инструктажей» как и в предыдущих случаях один ко многим, также и для документа «Регистрация допусков сотрудников» со справочниками «Должности» и «Сотрудники организации» связь один ко многим.

Связь между сущностью Документ «Учет инструктажей» и сущностью Регистр сведений «Инструктаж» один к одному, также и для Регистра сведений «Не прошедшие инструктаж». Связь между сущностью Документ «Регистрация допусков сотрудников» и сущностью Регистр сведений «Допуски сотрудников» один к одному. Описание таблиц реляционной базы данных в терминах системы приведено в таблицах 5-13.

Таблица 5 – Справочник «Подразделения организации»

Таблица 6 – Справочник «Причина проведения внепланового инструктажа»

Таблица 7 – Справочник «Сотрудники организации»

Таблица 8 – Справочник «Должности»

Таблица 9 – Документ «Учет инструктажей»

Таблица 10 – Док умент «Регистрация допусков сотрудников»

Таблица 11 – Регистр сведений «Инструктаж»

Таблица 12 – Регистр сведений «Не прошедшие инструктаж»

Таблица 13 – Регистр сведений «Допуски сотрудников»

2.3 Технологическая архитектура комплекса задач