Разработка базы данных экономической информационной системы для автоматизации отдела кадров (учет перемещений работников)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2 Использование методологии IDEF1X для разработки концептуальной модели данных

 

Методология IDEF1X – язык для семантического моделирования  данных, основанных на концепции «сущность-связь».

Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы и решение о внедрении реляционной базы данных, как части экономической информационной системы, было принято.

Сущность в IDEF1X представляет собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.

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

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

Отношения – связь  между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола.

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

Состав атрибутов и их описание для всех сущностей представлены в таблицах 1, 2, 3.

Таблица 1 –Атрибуты сущности «Сотрудники»

Имя атрибута	Описание
Табельный номер	Первичный ключ
Фамилия	Фамилия сотрудника
Имя	Имя сотрудника
Отчество	Отчество сотрудника
Адрес	Адрес сотрудника
Телефон	Контактный телефон
Дата рождения	Дата рождения сотрудника
Семейное положение	Женат или холост
Номер паспорта	Номер паспорта
Подразделение	Подразделение, в котором  работает
Должность	Должность сотрудника
Дата приема	Дата приема на работу
Приказ о приеме	Номер приказа о приеме на работу сотрудника

 

Таблица 2 – Атрибуты сущности «Отпуска»

Имя атрибута	Описание
Табельный номер	Первичный ключ
Вид отпуска	Вид отпуска, по которому сотрудника отпустили
Дата отпуска	Дата выхода в отпуск
Дата окончания отпуска	Дата окончания отпуска
Основание	На основании чего назначен отпуск

 

Таблица 3 –Атрибуты сущности «Увольнения»

Имя атрибута	Описание
Табельный номер	Первичный ключ
Фамилия	Фамилия сотрудника
Имя	Имя сотрудника
Отчество	Отчество сотрудника
Должность	Должность сотрудника, которую  он занимал
Дата увольнения	Дата увольнения с  рабочего места
Приказ об увольнении	Номер приказа об увольнении сотрудника

 

Методология IDEF1X подразделяется на уровни, соответствующие проектируемой модели данных системы. Каждый такой уровень соответствует определенной фазе проекта. Такой подход полезен при создании систем по принципу «сверху вниз».

Верхний уровень состоит  из Entity Relation Diagram (Диаграмма сущность-связь) и Key-Based model (Модель данных, основанная на ключах). Диаграмма сущность-связь определяет сущности и их отношения. Модель данных, основанная на ключах, дает более подробное представление данных. Она включает описание всех сущностей и первичных ключей, которые соответствуют предметной области.

Нижний уровень состоит  из Transforination Model (Трансформационная модель) и Fully Attributed (Полная атрибутивная модель). Трансформационная модель содержит всю информацию для реализации проекта, который может быть частью общей информационной системы и описывать предметную область. Трансформационная модель позволяет проектировщикам и администраторам БД представлять, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель данных удовлетворяет требованиям информационной системы. Фактически из трансформационной модели автоматически можно получить модель СУБД, которая является точным отображением системного каталога СУБД.

Первым шагом при  создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи  -  глаголами.

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

На рисунке 1 представлена ERD-диаграмма логической модели базы данных «Учет перемещений работников предприятия».

 

 Рисунок 1 – Логическая  модель БД «Учет перемещений работников предприятия»

 

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

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

Следующим этапом при  построении логической модели является определение типов атрибутов и размера поля. Типы атрибутов представлены в таблицах 4,5, 6.

 

 

 

 

 

 

 

 

 

Таблица 4 –Типы и размер атрибутов сущности «Сотрудники»

Имя атрибута	Тип атрибута	Размер
Табельный номер	Numeric	5
Фамилия	Character	20
Имя	Character	10
Отчество	Character	15
Адрес	Character	25
Телефон	Character	15
Дата рождения	Date	8
Семейное положение	Character	6
Номер паспорта	Character	11
Подразделение	Character	30
Должность	Character	15
Дата приема	Date	8
Приказ о приеме	Character	20

 

Таблица 5 – Типы и размер атрибутов сущности «Отпуска»

Имя атрибута	Тип атрибута	Размер
Табельный номер	Numeric	5
Вид отпуска	Character	15
Дата отпуска	Date	8
Дата окончания отпуска	Date	8
Основание	Character	20

 

Таблица 6 – Типы и размер атрибутов сущности «Увольнения»

Имя атрибута	Описание	Размер
Табельный номер	Numeric	5
Фамилия	Character	20
Имя	Character	10
Отчество	Character	15
Должность	Character	15
Дата увольнения	Date	8
Приказ об увольнении	Character	20

 

 

 

 

 

 

3 Физическая модель проектируемой базы данных

 

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

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

Модель трансформации:

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

Эта модель может также предоставить возможность для сравнения проекта физической базы данных и изначальных требований к коммерческой информации, а также для оценки и корректировки расширяемости и ограничений базы данных.

DBMS модель:

Модель трансформации  напрямую переводится в DBMS модель, которая, в свою очередь, получает определения объектов физической базы данных в схеме RDBMS или каталоге базы данных. ERwin напрямую поддерживает эту модель с функцией генерации схемы. Первичные ключи становятся уникальными индексами. Альтернативные ключи и инверсные вхождения (Inversion Entries, IE) также могут стать индексами.

Автоматическая генерация  физической модели данных для конкретной СУБД происходит за счет трансформации логической модели в физическую.

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

 

Рисунок 2 – Физическая модель БД «Учет перемещений работников предприятия»

 

Модель БД готова для помещения в СУБД.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4 Создание  форм, запросов и отчетов в среде СУБД Visual FoxPro

 

В Visual FoxPro вся информация хранится в базе данных, которая  состоит из таблиц, отношений между  таблицами, индексов, триггеров и  хранимых процедур. Каждая таблица  имеет уникальное имя и хранится в отдельном файле, наименование которого совпадает с именем таблицы. Структура таблиц и связи между ними в Visual FoxPro представлена на рисунке 3.

 

 

Рисунок 3- Структура базы данных и связи между таблицами

 

 

Для редактирования, добавления или удаления записей удобно использовать формы, которые позволяют рационально расположить данные на экране, используя разнообразные элементы оформления и возможности.

Формы используются для просмотра или ввода данных в таблицы. Данные можно вводить непосредственно в таблицы, но использование формы является более быстрым и более эффективным способом ввода.

База данных содержит две формы (приложение А и Б), которые называются «Сотрудники» и «Уволенные сотрудники». Созданные формы предназначены для более удобного просмотра информации о сотрудниках, для добавления информации о новых сотрудниках и просмотра информации об уволенных сотрудниках.

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