Разработка базы данных для отдела кадров в программе «Erwin 4.0», «IB Expert»



В данной статье рассматривается пример построения базы данных в программах «Erwin 4.0»., «IBExpert» для отдела кадров и её дальнейшая практическая реализация.Для создания базы данных «Кадры» автором были определены и описаны основные сущности и атрибуты, заданы первичные и альтернативные ключи, построены связи между ними, описаны логическая и физическая модели базы данных, её генерация, создание и регистрация базы данных.

Ключевые слова: база данных, сущность, атрибут,отдел кадров, первичный ключ, внешний ключ

В качестве предметной области будем рассматривать деятельность отдела кадров. Определяем сущности и их атрибутный состав на интуитивном уровне, т. е. определяем, какими типами данных характеризуется наш объект исследований.

Сущность (рис.1) — объект любой природы данные, о котором хранятся в отношении (таблице, в которой содержатся данные). Каждая сущность в ER-модели изображается в виде прямоугольника с наименованием:

Рис. 1. Сущность — «Состав семьи сотрудника»

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

Рис. 2. Атрибуты — сущности «Состав семьи сотрудника»

Каждый экземпляр сущности должен быть уникален и отличаться о других экземпляров. Для выделения экземпляров, поиска их в базе данных, связи с другими таблицами используются атрибуты, однозначно определяющие тот или иной объект. Такие атрибуты называют ключами. Различают первичные ключи и внешние: первичный ключ (primary key) — это атрибут или группа атрибутов, однозначно идентифицирующие экземпляр сущности, атрибуты первичного ключа на диаграмме не требуют специального обозначения — это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии; внешние ключи (Foreign Key) создаются автоматически, когда связь соединяет сущности: связи образуют ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа). Атрибуты внешнего ключа обозначаются символом (FK) после своего имени [1].

Состав атрибутов и их описание, первичные и альтернативные ключи для разработки базы данных отдела кадров представлены в таблицах ниже:

Таблица 1

Атрибуты сущности «Состав семьи сотрудника» (FAMILY_COMPOSITION_WORKER)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
КОД ЧЛЕНА СЕМЬИ	FAMILY_CODE	Порядковый номер родственника	Числовой	Ключевое	Поле
ФАМИЛИЯ	SURNAME	Фамилия родственника	Текстовой		Поле
ИМЯ	NAME	Имя родственника	Текстовой		Поле
ОТЧЕСТВО	PATRON	Отчество родственника	Текстовой		Поле
ТАБЕЛЬНЫЙ НОМЕР	OFFICER_CODE	Табельный номер сотрудника	Числовой	Внешний ключ, FK	Поле
КОД ВИДА РОДСТВА	RELATION_CODE	Код вида родства	Числовой	Внешний ключ, FK	Поле

Таблица 2

Атрибутысущности «Видродства» (KIND_OF_RELATIONSHIP)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
КОД ВИДА РОДСТВА	RELATION_CODE	Код вида родства	Числовой	Ключевое	Поле
СТЕПЕНЬ РОДСТВА	RELATION	Кем приходится данный человек сотруднику	Текстовой		Поле

Таблица 3

Атрибуты сущности «Семейное положение» (MAR_STATUS)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
КОД СЕМЕЙНОГО ПОЛОЖЕНИЯ	MAR_STATUS_CODE	Код семейного положения сотрудника	Числовой	Ключевое	Поле
СЕМЕЙНОЕ ПОЛОЖЕНИЕ	MAR_STATUS	Семейное положение сотрудника	Текстовой		Поле

Таблица 4

Атрибуты сущности «Трудовой договор» (LABOR_CONTRACT)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
ТАБЕЛЬНЫЙ НОМЕР	OFFICER_CODE	Табельный номер сотрудника	Числовой	Внешний ключ, FK	Поле
КОД ДОГОВОРА	CONTRACT_CODE	номер трудового договора	Числовой	Ключевое	Поле
ДАТА СОСТАВЛЕНИЯ	DATE_CONTRACT	дата составления договора	дата		Поле
ДАТА ПРИЕМА	DATE_APPOINTMENT	дата приёма сотрудника	дата		Поле
ДАТА УВОЛЬНЕНИЯ	TERMINATION_DATE	дата увольнения сотрудника	дата		Поле
КОД РАБОТЫ	CODE_OF_WORK	Код вида работы	Числовой	Внешний ключ, FK	Поле

Таблица 5

Атрибуты сущности «Вид работы» (TYPE_ WORK)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
КОД РАБОТЫ	CODE_OF_WORK	Код вида работы	Числовой	Ключевое	Поле
ВИД РАБОТЫ	TYPE_OF_WORK	Наименование вида работы	Текстовой		Поле

Таблица 6

Атрибуты сущности «Анкетные данные сотрудника» (DETAILS_ WORKER)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
ТАБЕЛЬНЫЙ НОМЕР	OFFICER_CODE	Табельный номер сотрудника	Числовой	Ключевое	Поле
ФАМИЛИЯ	SURNAME	Фамилия сотрудника	Текстовый		Поле
ИМЯ	NAME	Имя сотрудника	Текстовый		Поле
ОТЧЕСТВО	PATRON	Отчество сотрудника	Текстовый		Поле
ПОЛ	SEX	Пол сотрудника	Текстовый		Поле
ДАТА РОЖДЕНИЯ	BIRTH_DATE	Дата рождения сотрудника	Дата/ Время		Поле
НАЦИОНАЛЬНОСТЬ	NATIONALITY	Национальность сотрудника	Текстовый		Поле
СТАЖ	EXPERIENCE	Стаж работы в организации сотрудника	Числовой		Поле
АДРЕС	ADDRESS	Домашний адрес сотрудника	Текстовый		Поле
ТЕЛЕФОН	TELEPHONE	Домашний телефон сотрудника	Числовой		Поле
КОД СЕМЕЙНОГО ПОЛОЖЕНИЯ	MAR_STATUS_CODE	Код семейного положения сотрудника	Числовой	Внешний ключ, FK	Поле
КОД ШТАТНОГО РАСПИСАНИЯ	MANNING_TABLE_CODE	Порядковый номер записи	Числовой	Внешний ключ, FK	Поле

Таблица 7

Атрибуты сущности «Штатное расписание» (MANNING_TABLE)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
ОКЛАД	SALARY	Оклад сотрудника	Числовой		Поле
СТАВКА	RATE	Количество ставок, занимаемых сотрудниками	Числовой		Поле
КОД ОТДЕЛА	DEPART_CODE	Код отдела	Числовой	Внешний ключ, FK	Поле
КОД ДОЛЖНОСТИ	CUR_POST_CODE	Код должности	Числовой	Внешний ключ, FK	Поле
КОД ШТАТНОГО РАСПИСАНИЯ	MANNING_TABLE_CODE	Порядковый номер записи	Числовой	Ключевое	Поле

Таблица 8

Атрибуты сущности «Структурное подразделение» (STRUCTURA_SUBDIVISION)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
КОД ОТДЕЛА	DEPART_CODE	Код отдела	Числовой	ключевое	Поле
ОТДЕЛ	DEPART	Отдел в котором работает сотрудник	Текстовой		Поле
ТЕЛЕФОН ОТДЕЛА	TEL_DEPART	Телефон отдела	Числовой		Поле

Таблица 9

Атрибуты сущности «Должность» (POST)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
КОД ДОЛЖНОСТИ	CUR_POST_CODE	Код должности	Числовой	ключевое	Поле
ДОЛЖНОСТЬ	CUR_POST	Занимаемая должность сотрудника	Текстовой		Поле

Таблица 10

Атрибуты сущности «Сотрудник вприказе» (WORKER_PRIKAZ)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
НОМЕР ПРИКАЗА	PRIKAZ _NUMBER	Номер приказа	Числовой	Внешний ключ, FK	Поле
ТАБЕЛЬНЫЙ НОМЕР	OFFICER_CODE	Табельный номер сотрудника	Числовой	Внешний ключ, FK	Поле

Таблица 11

Атрибутысущности «Сотрудник вотпуске» (WORKER_HOLIDAY)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
ТАБЕЛЬНЫЙ НОМЕР	OFFICER_CODE	Табельный номер сотрудника	Числовой	Внешний ключ, FK	Поле
НОМЕР ПРИКАЗА	PRIKAZ _NUMBER	Номер приказа	Числовой	Внешний ключ, FK	Поле
КОД БОЛЬНИЧНОГО	HOSPITAL_CODE	Серия и номер больничного	Числовой	Внешний ключ, FK	Поле
КОД ОТПУСКА	HOLIDAY_CODE	Код вида отпуска	Числовой	Внешний ключ, FK	Поле
ДАТА НАЧАЛА	DATE_STARTED _HOLIDAY	Дата начала отпуска	Дата		Поле
ДАТА ОКОНЧАНИЯ	DATE_CLOSED_HOLIDAY	Дата окончания отпуска	Дата		Поле
КОЛИЧЕСТВО ДНЕЙ	AMOUNT_DAYS_HOLIDAY	Количество дней отпуска	Числовой		Поле

Таблица 12

Атрибуты сущности «Виды отпуска» (KIND_HOLIDAY)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
КОД ОТПУСКА	HOLIDAY_CODE	Код вида отпуска	Числовой	ключевое	Поле
ВИД ОТПУСКА	KIND_HOLIDAY	Наименование вида отпуска	Текстовой

Таблица 13

Атрибуты сущности «Больничный» (HOSPITAL)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
КОД БОЛЬНИЧНОГО	HOSPITAL_CODE	Серия и номер больничного листа	Числовой	ключевое	Поле
КОЛИЧЕСТВО ДНЕЙ	AMOUNT_DAYS	Количество дней освобождения от работы	Числовой		Поле
ДАТА ВЫДАЧИ	DATE_HOSPITAL	Дата выдачи больничного листа	Дата/Время		Поле
ТАБЕЛЬНЫЙ НОМЕР	OFFICER_CODE	Табельный номер сотрудника	Числовой	Внешний ключ, FK	Поле

Таблица 14

Атрибуты сущности «Приказ» (PRIKAZ)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
КОД ВИДА ПРИКАЗА	PRIKAZ _CODE	Код вида приказа	Числовой	Внешний ключ, FK	Поле
ДАТА ПРИКАЗА	DATE_PRIKAZ	Дата составления приказа	Дата		Поле
НОМЕР ПРИКАЗА	PRIKAZ _NUMBER	Номер приказа	Числовой	Ключевое	Поле

Таблица 15

Атрибуты сущности «Вид приказа» (VIEW_PRIKAZ)

Название на логическом уровне	Название на физическом уровне	Описание	Тип данных	Тип поля	Вид объекта
КОД ВИДА ПРИКАЗА	PRIKAZ _CODE	Код вида приказа	Числовой	Ключевое	Поле
ВИД ПРИКАЗА	NAME_ORDER	Наименование приказа	Текстовой		Поле

Для создания базы данных «Кадры» были взяты только некоторые самые основные сущности в количестве достаточном для прослеживания основных закономерностей, конечно, этих данных намного меньше, чем может содержаться в реальной базе данных, посвящённой деятельности кадровой службы, вот некоторые из тех, что не рассмотрели: учёт личного состава (личные дела, личные карточки, анкеты); выданные справки; трудовые книжки (приём, заполнение, хранение и выдача трудовых книжек); график отпусков; командировки (оформление и учёт командировок); табельный учёт; повышение квалификации;воинский учёт и др. Приведенный пример базы данных «Кадры», легко дополняется при необходимости разработки профессиональной базы данных.

Рис. 3. Логическая модель

Логический уровень представления модели данных — это уровень абстрактного, понятийного отображения информационных массивов, при котором подчёркивается предметная сторона рассматриваемой реальности.При высокоуровневом проектировании баз данных используется ER- модель. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями,модель представляется в виде диаграммы. На рис.3 отображена логическая модель данных описываемой системы. Линии между ними определяют наличие связей, а значки на концах — вид связи (рис.4).

Рис. 4. Виды связей

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

Неидентифицирующие связи, являющиеся уникальными, также связывают родительскую сущность с дочерней. Неидентифицирующие связи используются для отображения другого типа передачи атрибутов внешних ключей — передача в область данных дочерней сущности (под линией). Неидентифицирующие связи отображаются пунктирной линией между объектами. Так как переданные ключи в неидентифицирующей связи не являются составной частью первичного ключа дочерней сущности, то этот вид связи не проявляется ни в одной идентифицирующей зависимости.

Последний этап моделирования базы данных — переход к физическому уровню модели, на котором модель также представлена в виде диаграммы (рис.5).

Рис. 5. Физическая модель

Основной целью процесса проектирования является генерация физической схемы базы данных отдела кадров. Полученный SQL-скрипт:

CREATE TABLE DETAILS__WORKER (

MAR_STATUS_CODE INTEGER NOT NULL,

OFFICER_CODE INTEGER NOT NULL,

MANNING_TABLE_CODE INTEGER NOT NULL,

SEX VARCHAR(20),

SURNAME VARCHAR(20),

NAME VARCHAR(20),

PATRON VARCHAR(20),

BIRTH_DATE DATE,

NATIONALITY VARCHAR(20),

EXPERIENCE INTEGER,

ADDRESS VARCHAR(20),

TELEPHONE INTEGER

);

ALTER TABLE DETAILS__WORKER

ADD PRIMARY KEY (OFFICER_CODE);

CREATE TABLE FAMILY_COMPOSITION (

OFFICER_CODE INTEGER NOT NULL,

FAMILY_CODE INTEGER NOT NULL,

RELATION_CODE INTEGER NOT NULL,

SURNAME VARCHAR(20),

NAME VARCHAR(20),

PATRON VARCHAR(20)

);

ALTER TABLE FAMILY_COMPOSITION

ADD PRIMARY KEY (FAMILY_CODE);

CREATE TABLE HOSPITAL (

AMOUNT_DAYS INTEGER,

HOSPITAL_CODE INTEGER NOT NULL,

DATE_HOSPITAL DATE,

OFFICER_CODE INTEGER NOT NULL

);

ALTER TABLE HOSPITAL

ADD PRIMARY KEY (HOSPITAL_CODE);

CREATE TABLE KIND_HOLIDAY (

KIND_HOLIDAY VARCHAR(20),

HOLIDAY_CODE INTEGER NOT NULL

);

ALTER TABLE KIND_HOLIDAY

ADD PRIMARY KEY (HOLIDAY_CODE);

CREATE TABLE KIND_OF_RELATIONSH (

RELATION VARCHAR(20),

RELATION_CODE INTEGER NOT NULL

);

ALTER TABLE KIND_OF_RELATIONSH

ADD PRIMARY KEY (RELATION_CODE);

CREATE TABLE LABOR_CONTRACT (

OFFICER_CODE INTEGER NOT NULL,

CONTRACT_CODE VARCHAR(20) NOT NULL,

CODE_OF_WORK INTEGER NOT NULL,

DATE_CONTRACT DATE,

DATE_APPOINTMENT DATE,

TERMINATION_DATE DATE

);

ALTER TABLE LABOR_CONTRACT

ADD PRIMARY KEY (CONTRACT_CODE);

CREATE TABLE MANNING_TABLE (

DEPART_CODE INTEGER NOT NULL,

MANNING_TABLE_CODE INTEGER NOT NULL,

CUR_POST_CODE INTEGER NOT NULL,

SALARY INTEGER,

RATE INTEGER

);

ALTER TABLE MANNING_TABLE

ADD PRIMARY KEY (MANNING_TABLE_CODE);

CREATE TABLE MAR_STATUS (

MAR_STATUS VARCHAR(20),

MAR_STATUS_CODE INTEGER NOT NULL

);

ALTER TABLE MAR_STATUS

ADD PRIMARY KEY (MAR_STATUS_CODE);

CREATE TABLE POST (

CUR_POST VARCHAR(20),

CUR_POST_CODE INTEGER NOT NULL

);

ALTER TABLE POST

ADD PRIMARY KEY (CUR_POST_CODE);

CREATE TABLE PRIKAZ (

PRIKAZ_CODE INTEGER NOT NULL,

PRIKAZ_NUMBER INTEGER NOT NULL,

DATE_PRIKAZ DATE

);

ALTER TABLE PRIKAZ

ADD PRIMARY KEY (PRIKAZ_NUMBER);

CREATE TABLE STRUCTURA_SUBDIVIS (

DEPART VARCHAR(20),

DEPART_CODE INTEGER NOT NULL,

TEL_DEPART INTEGER

);

ALTER TABLE STRUCTURA_SUBDIVIS

ADD PRIMARY KEY (DEPART_CODE);

CREATE TABLE TYPE__WORK (

TYPE_OF_WORK VARCHAR(20) NOT NULL,

CODE_OF_WORK INTEGER NOT NULL

);

ALTER TABLE TYPE__WORK

ADD PRIMARY KEY (CODE_OF_WORK);

CREATE TABLE VIEW_PRIKAZ (

NAME_PRIKAZ VARCHAR(20),

PRIKAZ_CODE INTEGER NOT NULL

);

ALTER TABLE VIEW_PRIKAZ

ADD PRIMARY KEY (PRIKAZ_CODE);

CREATE TABLE WORKER_HOLIDAY (

HOSPITAL_CODE INTEGER,

OFFICER_CODE INTEGER NOT NULL,

PRIKAZ_NUMBER INTEGER NOT NULL,

HOLIDAY_CODE INTEGER NOT NULL,

DATE_CLOSED_HOLIDA DATE,

DATE_STARTED__HOLI DATE,

AMOUNT_DAYS_HOLIDA INTEGER

);

ALTER TABLE WORKER_HOLIDAY

ADD PRIMARY KEY (OFFICER_CODE);

CREATE TABLE WORKER_PRIKAZ (

PRIKAZ_NUMBER INTEGER NOT NULL,

OFFICER_CODE INTEGER NOT NULL

);

ALTER TABLE WORKER_PRIKAZ

ADD PRIMARY KEY (PRIKAZ_NUMBER, OFFICER_CODE);

ALTER TABLE DETAILS__WORKER

ADD FOREIGN KEY (MANNING_TABLE_CODE)

REFERENCES MANNING_TABLE;

ALTER TABLE DETAILS__WORKER

ADD FOREIGN KEY (MAR_STATUS_CODE)

REFERENCES MAR_STATUS;

ALTER TABLE FAMILY_COMPOSITION

ADD FOREIGN KEY (OFFICER_CODE)

REFERENCES DETAILS__WORKER;

ALTER TABLE FAMILY_COMPOSITION

ADD FOREIGN KEY (RELATION_CODE)

REFERENCES KIND_OF_RELATIONSH;

ALTER TABLE HOSPITAL

ADD FOREIGN KEY (OFFICER_CODE)

REFERENCES DETAILS__WORKER;

ALTER TABLE LABOR_CONTRACT

ADD FOREIGN KEY (CODE_OF_WORK)

REFERENCES TYPE__WORK;

ALTER TABLE LABOR_CONTRACT

ADD FOREIGN KEY (OFFICER_CODE)

REFERENCES DETAILS__WORKER;

ALTER TABLE MANNING_TABLE

ADD FOREIGN KEY (DEPART_CODE)

REFERENCES STRUCTURA_SUBDIVIS;

ALTER TABLE MANNING_TABLE

ADD FOREIGN KEY (CUR_POST_CODE)

REFERENCES POST;

ALTER TABLE PRIKAZ

ADD FOREIGN KEY (PRIKAZ_CODE)

REFERENCES VIEW_PRIKAZ;

ALTER TABLE WORKER_HOLIDAY

ADD FOREIGN KEY (HOLIDAY_CODE)

REFERENCES KIND_HOLIDAY;

ALTER TABLE WORKER_HOLIDAY

ADD FOREIGN KEY (HOSPITAL_CODE)

REFERENCES HOSPITAL;

ALTER TABLE WORKER_HOLIDAY

ADD FOREIGN KEY (OFFICER_CODE)

REFERENCES DETAILS__WORKER;

ALTER TABLE WORKER_HOLIDAY

ADD FOREIGN KEY (PRIKAZ_NUMBER)

REFERENCES PRIKAZ;

ALTER TABLE WORKER_PRIKAZ

ADD FOREIGN KEY (OFFICER_CODE)

REFERENCES DETAILS__WORKER;

ALTER TABLE WORKER_PRIKAZ

ADD FOREIGN KEY (PRIKAZ_NUMBER)

REFERENCESPRIKAZ;

Для каждой таблицы, входящей в модель, генерируются запросы, заданные в опциях объекта Table. В данном случае это:

CREATE TABLE — создание таблицы;

ALTER TABLE... ADD PRIMARY KEY — добавление первичного ключа;

ALTER TABLE... ADD FOREIGN KEY — добавлениевнешнегоключа.

После генерации SQL-скрипта переходим к созданию базы данных Interbase (IBExpert) и заполнению таблиц данными.

1. Создаём и регистрируем пустую базу данных, путь имя файла базы данных— С\КАДРЫ. gdb
2. При помощи буфера обмена копируем сгенерированный SQL-скрипт из окна просмотра генератора схем ERwin в окно редактора скриптов IBExpert, запускаем скрипт, чтобы создать объекты базы данных (таблицы, первичные и внешние ключи). Скрипт выполнился успешно, создалось 15 таблиц:

‒ FAMILY_COMPOSITION (Состав семьи сотрудника)

‒ KIND_OF_RELATIONSHIP (Видродства)

‒ MAR_STATUS (Семейное положение)

‒ LABOR_CONTRACT (Трудовой договор)

‒ TYPE_ WORK (Вид работы)

‒ DETAILS_ WORKER (Анкетные данные сотрудника)

‒ MANNING_TABLE (Штатное расписание)

‒ STRUCTURA_SUBDIVISION (Структурное подразделение)

‒ POST (Должность)

‒ WORKER_PRIKAZ (Сотрудник в приказе)

‒ WORKER_HOLIDAY(Сотрудник в отпуске)

‒ KIND_HOLIDAY(Виды отпуска)

‒ HOSPITAL (Больничный)

‒ VIEW_PRIKAZ (Вид приказа)

‒ PRIKAZ (Приказ)

3. Заполняем созданные таблицы данными.

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

Литература:

1. BPwin и Erwin. CASE-средства для разработки информационных систем: Сергей Маклаков [Электронный ресурс] — [URL:http://programming-lang.com/ru/comp_db/maklakov/0/j92.html] (дата обращения 12.05.2016).
2. Информационное обеспечение систем управления. Построение запросов при работе с базой данных: учебное пособие/И. А. Шмидт. — Пермь, Изд-во Пермского государственного технического университета, 2008–59 с.