Как составить базу данных по персоналу

База данных Access Сотрудники

1. Создать файл базы данных (БД) Сотрудники;
2. создать структуру таблицы «Штат», «Сотрудники» и «Список»;
3. установить связь между таблицами;
4. создать формы;
5. создать запросы:
• Вывести список сотрудников, имеющих льготы;
• Сформировать запрос, содержащий информацию о сотрудниках с высшим образованием;
• Сформировать запрос, содержащий информацию об адресе, телефоне и ФИО генерального директора фирмы;
• Сформировать запрос, содержащий информацию о сотрудниках, принятых на работу в 2006-2007 гг;
• Сформировать запрос, содержащий информацию о сотрудниках, не проживающих в г. Новосибирске;
• Определить, есть ли в фирме вакансии в штатном расписании;
• Используя итоговый запрос, вывести средний оклад сотрудников с высшим образованием;
• Используя запрос на создание таблицы, сформировать новую таблицу, включив в нее поля ФИО, Образование, Дата принятия на работу, Телефон, Должность и Оклад;
• Сформировать запрос, содержащий информацию об окладах сотрудников, и всем сотрудникам, имеющим оклад меньше 20000, начислить премию в размере 30% от оклада;
6. создать отчеты;
7. создать главную кнопочную форму.

База данных Access Сотрудники содержит 3 таблицы, 9 запросов, 4 формы + главная кнопочная форма, 3 отчета. Данная база данных Access является учебной, подходит для дальнейшей оптимизации и доработки под собственные нужды.
Пояснительной записки WORD нет!

Цель практических заданий – приобретение навыков анализа предметной области, проектирования базы данных, ее физической реализации в СУБД Access.
Результат выполнения работы представляется в виде базы Access, который должен содержать:
• структуру спроектированных таблиц,
• схему данных со связями между таблицами,
• формы, обеспечивающих интерфейс пользователя,
• запросы,
• отчеты,
• главную кнопочную форму.

Таблица «Штат» — База данных Access Сотрудники

Запрос «Сотрудники не из Новосиба» — База данных Access Сотрудники

Форма «Полная информация сотрудника» — База данных Access Сотрудники

Форма «Сотрудник» — База данных Access Сотрудники

Отчет «Сотрудники по должности» — База данных Access Сотрудники

Отчет «Сотрудники по образованию» — База данных Access Сотрудники

Главная кнопочная форма

Скачать базу данных (БД) MS Access; БД Access Сотрудники; база данных access; бд access; субд access; базы данных access; access пример; программирование access; готовая база данных; создание база данных; база данных СУБД; access курсовая; база данных пример; программа access; access описание; access реферат; access запросы; access примеры; скачать бд access; объекты access; бд в access; скачать субд access; база данных ms access; субд access реферат; субд ms access; преимущества access; базу данных; скачать базу данных на access; базы данных; реляционная база данных; системы управления базами данных; курсовая база данных; скачать базу данных; база данных access скачать; базы данных access скачать;

Тип урока: комбинированный урок

Цели урока:

• Формирование умений самостоятельного
  применения знаний;
• Формирование умений работы в среде СУБД;
• Формирование целостного представления по
  работе с БД;
• Стимулирование интереса учащихся к данной теме
  и предмету в целом;
• Обучение системному подходу к анализу и
  исследованию структуры и взаимосвязей объектов;
• Воспитание самостоятельности у учащихся;
• Развитие логического мышления, творческого и
  познавательного потенциала учащегося.

Методические задачи:

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

Оборудование: компьютеры, проектор, экран,
программные средства: пакет Microsoft Office.

Ход урока

Преподаватель

Создадим спроектированную на прошлом уроке
базу данных “Отдел кадров предприятия”, она
состоит из четырех таблиц – СОТРУДНИКИ, ЗАДАНИЕ,
ОТДЕЛ и ДОЛЖНОСТЬ.

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

Определим типы полей и назначим ключевое поле в
каждой таблице.

В таблице “ЗАДАНИЕ”:

Имя поля	Тип данных
Код задания	Числовой
Название отдела	Текстовый
Код отдела	Числовой

Ключевое поле — Код задания.

В таблице “ОТДЕЛ”:

Имя поля	Тип данных
Код отдела	Числовой
Название отдела	Текстовый

Ключевое поле — Код отдела.

В таблице “ДОЛЖНОСТЬ”:

Имя поля	Тип данных
Код должности	Числовой
Название должности	Текстовый
Оклад	Числовой

Ключевое поле — Код должности.

В таблице “СОТРУДНИКИ”:

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

Ключевое поле – Номер сотрудника.

Установим связи между таблицами:

1. Для связывания таблиц необходимо:

• выполнить команду Сервис/Схема данных;
• в диалоговом окне Добавление таблицы выделить
  название таблицы СОТРУДНИКИ и выполнить
  команду Добавить;
• выделить название таблицы ЗАДАНИЕ;
  выполнить команду Добавить;
• выделить название таблицы ДОЛЖНОСТЬ;
  выполнить команду Добавить;
• выделить название таблицы ОТДЕЛ; выполнить
  команду Добавить, затем команду Закрыть.

2. В результате на поле окна Схема данных появятся
образы четырех таблиц.

Нажав левую кнопку мыши, следует перетащить
ключевое поле Код должности из таблицы ДОЛЖНОСТЬ
к одноименному полю внешнего ключа таблицы СОТРУДНИКИ.

3. Откроется окно Изменение связей. Тип
связи “один-ко-многим” будет выбран
автоматически.

4. Последовательно активизируйте флажки “Обеспечить
целостность данных”, “Каскадное обновление
связанных полей” и “Каскадное удаление
связанных записей”.

Целостность базы данных обозначает то, что БД
содержит непротиворечивую информацию (пример:
если в таблице “СОТРУДНИКИ” появиться
запись с кодом задания, которого нет в таблице “ЗАДАНИЕ”,
то будет нарушена целостность, и система
информирует об этом факте пользователя).

Каскадное обновление и удаление поддерживает
целостность данных в случае их изменения (пример:
если из таблицы “ДОЛЖНОСТЬ” удалить запись,
например, о директоре, то из таблицы “СОТРУДНИКИ”
исчезнут все записи о директорах).

5. Выполните команду Создать.

6. Следует перетащить ключевое поле Код
задания из таблицы ЗАДАНИЕ к одноименному
полю внешнего ключа таблицы СОТРУДНИКИ, и
ключевое поле Код отдела из таблицы ОТДЕЛ
к одноименному полю внешнего ключа таблицы ЗАДАНИЕ.

7. Схема готова. Осталось сохранить схему и
закрыть окно.

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

Пример практического задания, выполненного
учащимися, представлен в Приложении 1.

Чтобы СУБД контролировала целостность при
вводе данных, при заполнении таблиц порядок
должен быть следующий (подчиненная таблица
заполняется в последнюю очередь):

Так как данная тема рассматривалась при
изучении базового курса информатики, учащиеся
самостоятельно создают базу данных “Отдел
кадров предприятия” в MS Access, используя
результаты домашнего задания (см. урок
“Нормализация баз данных”).

Пример практического задания, выполненного
учащимися, представлен в Приложении
2.

Преподаватель

В базовом курсе информатики мы уже создавали
различные объекты в СУБД. Рассмотрим создание
некоторых объектов – запросов и отчетов к
многотабличной базе данных.

Создание запросов

1. Требуется составить список сотрудниц (Ф., И.,
О.), стаж которых не менее 25 лет и работающих в
должности директора.

При формировании запроса выбираются таблицы “ДОЛЖНОСТЬ”
и “СОТРУДНИКИ”.

Запрос, реализованный в конструкторе Access:

Результат выполнения запроса представлен в Приложении 3.

2. Требуется составить список сотрудниц (Ф., И.,
О., поля Имя и Отчество – в алфавитном порядке) из
первого отдела, имя которых начинается на букву
“А”, и мужчин сотрудников из второго отдела в
фамилии которых втора буква “О”.

При формировании запроса выбираются таблицы “ОТДЕЛ”,
“ЗАДАНИЕ” и “СОТРУДНИКИ”.

Запрос, реализованный в конструкторе Access:

Результат выполнения запроса представлен в Приложении 4.

3. Подсчитать сотрудников, работающих в
должности технический редактор с 5 стажем работы
в каждом отделе.

При формировании запроса выбираются все
созданные таблицы – “ДОЛЖНОСТЬ”, “ОТДЕЛ”,
“ЗАДАНИЕ” и “СОТРУДНИКИ”.

Запрос, реализованный в конструкторе Access:

Результат выполнения запроса представлен в Приложении 5.

4. Создайте запрос, который по введенному стажу
выдает сведения о сотрудниках (Ф., И., О.,
Должность) и отражает начисление премии (Стаж
работы в организации/10*Оклад).

При формировании запроса выбираются таблицы “ДОЛЖНОСТЬ”
и “СОТРУДНИКИ”.

Запрос, реализованный в конструкторе Access:

Результат выполнения запроса представлен в Приложении 6.

Создание отчетов

Создайте отчет “Премия”, который по
введенному стажу выдает сведения о сотрудниках
(Ф., И., О., Должность) и отражает начисление премии
(Стаж работы в организации/10*Оклад).

Воспользуемся мастером отчетов. Результат
выполнения отчета представлен в Приложении 7.

Практическое задание

1. Создайте запросы №№1 – 4.

2. Создайте собственные запросы (не менее 5).

3. Создайте отчет “Премия”.

4. Создайте собственные отчеты (не менее 3).

Дополнительное задание

5. Создайте форму для ввода данных, используя
мастер форм (самостоятельно выбрать поля
для формы).

Подведение итогов

Литература.

1. Гончаров А. Ю. Acceess 2007. Справочник с примерами. –
   М.: КУДИЦ-ПРЕСС, 2008.
2. Кузин А. В., Левонисова С. В. Базы данных. Учебное
   пособие для студ. высш. учеб. заведений. – М.:
   Издательский центр “Академия”, 2008.
3. Перевозчикова М. С., Петухова М. В. Практикум по
   программному обеспечению ЭВМ. Реляционные базы
   данных. Система управления базами данных Acceess: ч.
   V. – Киров: Изд-во ВГГУ, 2005.
4. Семакин И. Г., Хеннер Е. К. Информационные системы
   и модели. Практикум по элективному курсу. – М.:
   БИНОМ. Лаборатория знаний, 2006.
5. Семакин И. Г., Хеннер Е. К. Информационные системы
   и модели. Учебное пособие по элективному курсу. –
   М.: БИНОМ. Лаборатория знаний, 2007.
6. Угринович Н. Д. Информатика и информационные
   технологии. Учебник для 10–11 классов. – М.: БИНОМ.
   Лаборатория знаний, 2007.

Разработка базы данных ‘Отдела кадров (института)’

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

ФГБОУ ВО РОСТОВСКИЙ ГОСУДАРСТВЕННЫЙ
ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ (РИНХ)

Факультет «Компьютерных технологий и
информационной безопасности»

Кафедра «Информационных систем и
прикладной информатики»

КУРСОВОЙ ПРОЕКТ

По дисциплине «Базы данных»

Автор курсового проекта: Бишлеев Владимир Михайлович

Группа: 321-БИН

Направление: Бизнес-информатика

Руководитель
проекта: Л.Ф. Панферова

Ростов — на — Дону

2015

Оглавление

Введение

Глава 1. Постановка задачи
разработки информационной системы

.1 Задание на разработку базы
данных «Отдел кадров» института

.2 Описание предметной
области

.3 Обоснование необходимости
создания БД

Глава 2. Проектирование БД

.1 Этапы проектирования БД

.2 Концептуальная модель базы
данных

.3 Логическая модель базы
данных. Нормализация.

.4 Физическая структура базы
данных.

Глава 3. Разработка
программного обеспечения для ЭВМ

.1 Запросы к БД

.2 Экранные формы для ввода и
редактирования данных в БД

.3 Отчеты в БД

.4 Главная кнопочная форма

Заключение

Список использованных
источников

Приложения

Введение

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

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

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

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

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

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

Глава 1. Постановка задачи разработки информационной системы

 

.1 Задание
на разработку базы данных «Отдел кадров» института

Задача — информационная поддержка деятельности отдела кадров.

Различают три группы сотрудников:

а) администрация;

б) преподавательский и инженерно-технический состав (по кафедрам);

в) технический персонал.

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

БД должна предоставлять возможность составления должностных (штатных)
расписаний по кафедрам и отделам и следующих списков:

1
вакансий (с
учётом сотрудников, находящихся в отпуске по уходу за ребенком, т.е. с
указанием даты, до которой ставка свободна);

2
пенсионеров;

3
людей
предпенсионного возраста (не более 2-х лет до пенсии);

4
бездетных
сотрудников;

5
юбиляров текущего
года;

6
многодетных
сотрудников (трое и более детей);

7
ветеранов
(работающих в институте не менее тридцати лет);

8
сотрудников,
работающих более чем на одной ставке.

 

.2
Описание предметной области

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

Учет персонала, работающего в институте осуществляет отдел кадров
института. Сотрудники при поступлении на работу предоставляют сведения о себе
(при этом заполняются анкета и заявление), в конечном итоге составляется
трудовой договор с Институтом, подписываемый администрацией.

На основание заключенного трудового договора каждый сотрудник имеет
определенную должность, работает в подразделении института (отделе/кафедре).

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

Эта база данных должна содержать сведения о сотрудниках института: личных
данных сотрудников (ФИО, Дата рождения. Адрес и т.п.),, их трудовой
деятельности (должности, подразделения, начале трудовой деятельности стаже
работы и т п.).

Выходными данными данной БД являются различного рода сведения
сотрудниках, штатное расписание.

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

 

1.3
Обоснование необходимости создания БД

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

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

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

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

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

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

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

Глава 2. Проектирование БД

 

.1 Этапы
проектирования БД

Современные информационные системы характеризуются огромными объемами
хранимых данных, большой скоростью их обработки и актуализации, высокой
эффективностью обработки запросов пользователей. В широком смысле слова база
данных — это совокупность сведений о конкретных объектах реального мира в
какой-то предметной области.

Проектирование базы данных состоит в построении комплекса взаимосвязанных
данных. На рисунке 1 условно отображены этапы процесса проектирования базы
данных.

Рис.1 — Этапы процесса проектирования базы данных

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

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

Концептуальное проектирование — сбор, анализ и редактирование
требований к данным. Для этого осуществляются следующие мероприятия:

обследование предметной области, изучение ее информационной структуры;

выявление всех фрагментов, каждый из которых характеризуется
пользовательским представлением, информационными объектами, связями между ними
и процессами;

·- моделирование и интеграция всех представлений.

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

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

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

Построение логической и физической моделей данных является основной
частью проектирования Базы данных.

2.2.
Концептуальная модель базы данных

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

Главными элементами концептуальной модели данных являются объекты и
отношения.

Объекты представляют собой любой конкретный (реальный) объект в
рассматриваемой области.

Исходя из спецификации требования, определим основные типы сущностей.

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

Объекты в каждый момент времени характеризуются определенным состоянием,
которое описывается набором свойств и отношений (или связей) с другими
объектами.

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

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

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

В рассматриваемой предметной области можно выделить следующие сущности:

. Сотрудники — содержит информацию о дате рождения, месте
проживания, семейном положении, составе семьи сотрудника, трудовой деятельности
(стаже работы, дате начала трудовой деятельности) и т.д.

. Должности — содержит информацию о должностях;

. Отделы/кафедры содержит информацию об отделах/кафедрах
института;

. Вакансии содержит информацию о вакансиях в отделах/кафедрах;

. Штатное расписание- содержит информацию о штатном расписании по
отделам/кафедрам с указанием количества ставок по должностям.

Между сущностями возможны четыре типа связей: один — к одному (1 ↔1),
один — ко многим (1↔∞), многие к одному (∞↔1), многие
ко многим (∞ ↔ ∞ ) .

Связь 1 ↔ 1 означает, что в любой момент времени каждому экземпляру
первого информационного объекта (ИО) соответствует 1 экземпляр другого ИО.

Связь 1↔ ∞ означает: одному экземпляру ИО соответствует 1,2,
… экземпляров другого и, наоборот, каждому экземпляру второго ИО соответствует
1 экземпляр первого ИО. Аналогично определяется тип связи ∞ ↔ 1.

Связь ∞ ↔ ∞ означает, что одному экземпляру первого ИО
соответствует 1,2,… экземпляров другого ИО и наоборот.

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

Концептуальная модель, соответствующая БД в виде EAR- диаграмм
«сущность»- «атрибут» — «связь», представлена в Приложении 1.

В результата анализа предметной области выделено пять ИО (Сотрудники,
Должности, Отделы/Кафедры, Вакансии, Штатное расписании), их свойства и связи.

Определим связи между сущностями.

Таблица 1. Связи между сущностями

Название связи	Тип	Связи между сущностями
Выбор должности	1↔ ∞	Должность, Сотрудники
Выбор отдела/кафедры	1↔ ∞	Отдел/кафедра, Сотрудники
Выбор вакансии	1↔ ∞	Вакансия, Отдел
Выбор штатного расписания	1↔ ∞	Штатное расписании, Отдел

2.3
Логическая модель базы данных. Нормализация

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

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

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

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

В целом, разработка базы данных включает следующие этапы:

·        определить цель создания базы данных;

·        определить какие исходные данные (таблицы) она будет
содержать;

·        определить наборов полей, включаемых в таблицы, ключевые
поля;

·        спроектировать связи между таблицами и анализ полученной
структуры;

·        создать таблицы и связи между ними;

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

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

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

Реляционная таблица представляется двумерным массивом и обладает
следующими свойствами:

каждая ячейка таблицы содержит один элемент данных;

все ячейки одного столбца содержат одинаковый тип данных определенной
длины;

каждый столбец имеет уникальное имя;

каждая строка таблицы хранит сведения, относящиеся к одному объекту;

одинаковые строки в таблице отсутствуют.

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

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

Приведем наши отношения к третьей нормальной форме.

Первая НФ: Отношение называется нормализованным или приведенным к
первой нормальной форме тогда и только тогда, когда все его атрибуты простые
(неделимые). Таблица находится в первой нормальной форме тогда и только тогда,
когда ни одна из ее строк не содержит в любом ее поле более одного значения, и
не одно из ее ключевых полей не пусто. Для того чтобы привести наши отношения к
первой нормальной форме надо сущность «ФИО» разбить на три
отдельные (Фамилия, Имя, Отчество). Так же следует вынести в отдельную таблицу
«Отделы/Кафедры», «Должности», чтобы не допустить избыточности данных. Таблицу
«Сотрудники» разобьем на две таблицы: Сотрудники (личн_данные) и Сотрудники
(труд_деят).

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

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

Отношения, представленные в данной БД приведены к третьей нормальной
форме.

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

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

·        Связь один к одному (1:1) между таблицами предполагает, что в каждый момент
времени одной записи в первой таблице соответствует единственная запись во
второй таблице, и наоборот. Например, каждая запись в таблице «Сотрудники»
может соответствовать единственной записи во второй таблице, включающей поля
«Код сотрудника»;

·        Связь один ко многим (1:М) между таблицами предполагает, что в каждый момент
времени одной записи в первой таблице соответствует несколько записей во второй
таблице. Например, одна запись в таблице «Сотрудники(личн_данные)»
может соответствовать несколько записей в таблице «Сотрудники(труд_деят)».

·        Связь многие ко многим (М:М). Такая связь между таблицами предполагает, что в
каждый момент времени одной записи в первой таблице соответствует несколько
записей во второй таблице, и одной записи во второй таблице соответствует
несколько записей в первой таблице. Связь реализуется посредством создания
третьей таблицы, в которой одно поле совпадает с ключевым полем первой таблицы,
а второе — с ключевым полем второй таблицы.

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

Для атрибута «Вакансии» ключом будет являться три сущности,
«Код вакансии», «Код отдела/кафедры», «Код должности», то есть
ключ будет составным.

Для атрибута «Штатное расписание» ключом будет являться три
сущности, «Код шт.ед.», «Код отдела/кафедры», «Код должности», то
есть ключ будет составным.

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

Таким образом, получим информационно-логическую схему данных,
представленную в Приложении 2.:

2.4
Физическая структура базы данных

Логическая структура базы данных — структура для пользователя, физическая
— структура базы данных для ЭВМ. Физическая структура определяет, тип и
свойства данных, которые будут записаны в память компьютера.

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

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

В процессе физического проектирования БД необходимо присвоить имена
таблицам, а также присвоить имена полям таблиц.

Так как первичный ключ — это некое поле (столбец) или группа полей
таблицы базы данных, значение которого (или комбинация значений которых), используется
в качестве однозначного уникального идентификатора записи (строки) этой
таблицы, например, в таблице «Отделы/Кафедры в качестве
первичного ключа целесообразно определить «Код отдела/кафедры», в
таблице «Должности» — поле «Код должности», в таблице
«Сотрудники» — поле «Код сотрудника», в таблице «Кафедры»
— поле «Код кафедры»

Структура необходимых таблиц представлена наглядно в таблицах:

Таблица 2 — Структура таблицы Отделы/Кафедры

Поле	Тип данных	Комментарий
Код отдела/кафедры	Числовой	Ключ
Название отдела/кафедры	Текстовый	60

Таблица 3 — Структура таблицы Должности

ПолеТип данныхКомментарий
Код должности	Счетчик	Ключ
Наименование должности	Текстовый	25

Таблица 4 — Структура таблицы Сотрудники(личн_данные)

Поле	Тип данных	Комментарий
Код сотрудника	Числовой	Ключ
Фамилия	Текстовый	17
Имя	Текстовый	15
Отчество	Текстовый	15
Пол	Текстовый	5
Дата рождения	Дата/время	Краткий формат даты
Домашний адрес	Текстовый	35
Семейное положение	Текстовый	Мастер подстановок	Числовой	Длинное целое
Паспортные данные	Текстовый	11
Телефон	Текстовый	11

Таблица 4 — Структура таблицы Сотрудники(труд_деят)

ПолеТип данныхКомментарий
Код сотрудника	Числовой	Ключ
Код должности	Числовой	Поле со списком таблица «Должность»
Код отдела/кафедры	Числовой	Поле со списком таблица «Отделы/Кафедры»
Дата приема	Дата/время	Краткий формат даты
Дата увольнения	Дата/время	Краткий формат даты
Начало труд_деят	Дата/время	Краткий формат даты
Временно не работает	Логический	Да/Нет
Дата врем_нетрудоспособн	Дата/время	Краткий формат даты
Ставка	Текстовый	Мастер подстановок

Таблица 5. Структура таблицы Вакансии

Поле	Тип данных	Комментарий
Код вакансии	Счетчик	Ключ
Код отдела/кафедры	Числовой	Поле со списком таблица «Отделы/Кафедры»
Код должности	Числовой	Поле со списком таблица «Должность»
Кол-во вакансий	Числовой
Тип вакансии	Текстовый	Мастер подстановок
Дата объявл_вакансии	Дата/время	Краткий формат даты
Дата окончан_вакансии	Дата/время	Краткий формат даты

Таблица 6. Структура таблицы Штатное расписание

ПолеТип данныхКомментарий
Код шт_ед	Числовой	Ключ
Код отдела/кафедры	Числовой	Поле со списком таблица «Отделы/Кафедры»
Код должности	Поле со списком таблица «Должность»
Кол-во шт ед	Числовой

Глава 3. Разработка программного обеспечения для ЭВМ

база данные запрос

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

СУБД Microsoft Office Access предоставляет эффективный набор средств,
которые позволяют быстро организовать учет данных, отчетность и совместный
доступ к данным. Не обладая специализированными знаниями баз данных,
пользователи могут быстро создавать удобные приложения учета данных посредством
настройки одного из нескольких готовых шаблонов, преобразования существующих
баз данных или создания новой базы данных.

Access
— это прежде всего система управления базами данных. Она предназначена для
хранения и получения данных, представления их в удобном виде и автоматизации
часто выполняемых операций, а также разрабатывать удобные формы ввода данных и
составлять сложные отчёты.

Любая база данных содержит следующие элементы: таблицы, запросы, формы,
отчёты и макросы.

 

.1 Запросы
к БД

Запросы — это объект базы данных, который служит для извлечения данных из
таблиц и предоставления их пользователю в удобном виде. Особенность запросов
состоит в том, что они черпают данные из базовых таблиц и создают на их основе
временную таблицу.

.        Запрос по вакансиям, в котором отображены сведения о
вакансиях сотрудниках по отделам/кафедрам:

Для этого с помощью Мастер запросов, создадим Простой запрос.
Выберем поля из таблицы «Вакансии» — Код вакансии, Код
отдела/кафедры, Код должности, Кол-во вакансий, Тип вакансии, Дата_объявл_вакансии,
Дата_оконч_вакансии, из таблицы — «Отделы/кафедры»
поле Наименование отдела/кафедры, из таблицы «Должности» —
поле Наименование должности.

Рис.2 — Запрос по вакансиям в режиме конструктора

. Создадим запрос с параметром и вычисляемым полем, в котором выводятся данные
о сотрудниках пенсионерах.

Для этого с помощью Мастер запросов, создадим Простой запрос.
Выберем поля из таблицы «Сотрудники (личн_данные)» — Фамилия,
Имя, Отчество, Пол, Дата рождения, из таблицы «Отделы/кафедры»
поле Наименование отдела/кафедры, из таблицы «Должности» —
поле Наименование должности. Сохраним запрос под именем «Список
пенсионеров».

Далее создадим вычисляемое поле «Возраст», в котором с помощью Построителя
выражений зададим формулу для расчета возраста сотрудников:

(Date()-[Дата рождения])/365

Откроем запрос в режиме конструктора, в строке Условия отбора для
поля «Пол» введем условия: для женщин — возраст больше или равно 55, для мужчин
— возраст более или равно 60.

Рис.3 — Запрос «Список пенсионеров» в режиме конструктора.

3. Создадим запрос по сотрудникам предпенсионного возраста
(не более 2-х лет до пенсии):

Рис. 4 — Результат запроса «Список предпенсионеров»

. Разработаем запрос на выборку сотрудников, не имеющих детей.

Для этого с помощью Мастера запросов создадим Простой запрос.
Выберем поля из таблицы «Сотрудники (личн_данные)» — Фамилия,
Имя, Отчество, Пол, Количество детей, из таблицы «Отделы/кафедры»
поле Наименование отдела/кафедры, из таблицы «Должности» —
поле Наименование должности. Сохраним запрос под именем «Сотрудники
без детей».

Откроем запрос в режиме конструктора, в строке Условия отбора для
поля Количество детей введем: Is Null.

Рис.5 — Запрос «Сотрудники без детей» в режиме конструктора

. Разработаем запрос на выборку по юбилярам текущего года.

Для этого с помощью Мастер запросов, создадим Простой запрос.
Выберем поля из таблицы «Сотрудники (личн_данные)» — Фамилия,
Имя, Отчество, Пол, Дата рождения, из таблицы «Отделы/кафедры»
поле Наименование отдела/кафедры, из таблицы «Должности» —
поле Наименование должности. Сохраним запрос под именем «Список
пенсионеров».

Далее создадим вычисляемое поле «Возраст», в котором с помощью Построителя
выражений зададим формулу для расчета возраста сотрудников:

(Date()-[Дата рождения])/365

Откроем запрос в режиме конструктора, в строке Условия отбора для
поля «Возраст» введем условия.

6. Разработаем запрос на выборку многодетных сотрудников

Для этого с помощью Мастера запросов создадим Простой запрос.
Выберем поля из таблицы «Сотрудники (личн_данные)» — Фамилия,
Имя, Отчество, Пол, Количество детей, из таблицы «Отделы/кафедры»
поле Наименование отдела/кафедры, из таблицы «Должности» —
поле Наименование должности. Сохраним запрос под именем «Сотрудники
без детей».

Рис. 6 -Запрос «Юбиляры» в режиме конструктора

Откроем запрос в режиме конструктора, в строке Условия отбора для поля
Количество детей введем: >=3

Рис.7 — Запрос «Многодетные сотрудники» в режиме конструктора

. Разработаем запрос на выборку сотрудников ветеранов (работающих
в институте более 30 лет)

Для этого с помощью Мастер запросов, создадим Простой запрос.
Выберем поля из таблицы «Сотрудники (личн_данные)» — Фамилия,
Имя, Отчество, Пол, Дата рождения, из таблицы Сотрудники
(труд_деят)» — поля: Начало труд_деят, Дата приема, из
таблицы «Отделы/кафедры» —поле Наименование отдела/кафедры,
из таблицы «Должности» — поле Наименование должности.
Сохраним запрос под именем «Запрос по ветеранам».

Далее создадим вычисляемое поле «Стаж работы», в котором с помощью
Построителя выражений зададим формулу для расчета стажа работы
сотрудников:

Стаж работы: Int((Date()-[Начало труд_деят])/365)

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

Стаж в институте: [Начало труд_деят]-[Дата приема]

Откроем запрос в режиме конструктора, в строке Условия отбора для
поля Стаж работы и Стаж в институте введем условия:

Рис.7 — Запрос по ветеранам в режиме конструктора

. Разработаем запрос на выборку сотрудников, работающих боле чем на
одной ставке.

Для этого с помощью Мастер запросов, создадим Простой запрос.
Выберем поля из таблицы «Сотрудники (личн_данные)» — Фамилия,
Имя, Отчество, Пол, Дата рождения, из таблицы Сотрудники
(труд_деят)» — поля: Начало труд_деят, Дата приема, из
таблицы «Отделы/кафедры» —поле Наименование отдела/кафедры,
из таблицы «Сотрудник (труд_деят)» — поле Ставка. Сохраним
запрос под именем «Сотрудники ставка».

Рис.8 — Запрос «Сотрудники ставка» в режиме конструктора

. Разработаем запрос на выборку по штатному расписанию.

Для этого с помощью Мастер запросов, создадим Простой запрос.
Выберем поля из таблицы «Штатное расписание» — Код_шт_ед, Код
отдела/кафедры, Код должности, Код шт_ед, из таблицы «Отделы/кафедры»
—поле Наименование отдела/кафедры. Сохраним запрос под именем «Запрос
по штатному расписанию».

Рис.9 — Запрос по штатному расписанию в режиме конструктора

 

.2
Экранные формы для ввода и редактирования данных в БД

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

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

Форма предоставляет возможности для ввода и просмотра информации базы
данных, изменения данных, печати, создания сообщений.

В данной БД представлены следующие формы: формы «Вакансии»,
«Отделы/кафедры», «Должности», «Штатное расписание», сложная форма
«Сотрудники»., сложная форма «Списки по должностям».

Все формы созданы с помощью Мастера форм. Виды форм представлены в
Приложении 3.

 

.3 Отчеты
в БД

Для предоставления конечного документа по работе с БД данные таблиц и
запросов могут быть оформлены в виде отчета.

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

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

Создания отчета, выполним В данной БД отчеты созданы на базе созданных
запросов с помощью Мастера отчетов. Формы отчетов представлены в Приложении 4.

3.4
Главная кнопочная форма

Для удобства пользования созданной базой данных создана кнопочная форма.

При запуске программы автоматически открывается главная форма «База
данных «Отдел кадров «Институт».

В главной форме предусмотрены пункты-кнопки: Таблицы, Запросы, Формы,
Отчеты, которые далее подразделяются по названиям.

Рис.10 — Главная кнопочная форма

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

Заключение

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

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

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

Разработанная база данных отвечает всем требованиям предметной области,
таблицы созданной базы данных отвечают требованиям нормализации, что позволяет
обеспечить целостность и непротиворечивость информации.

Список
использованных источников

1.     «Информатика»
под ред. проф. Н.В. Макаровой — М: Финансы и статистика, 1999

2.      Кузнецов
A. Microsoft Access 2003: учебный курс. — СПб.: 2006. -363с.

.        Голицына
О.Л. Базы данных. — М.: Форум. 2005. — 351с.

.        Хоменко
А.Д. Базы данных. Учебник для ВУЗОВ. — М.: Технология, 2000. — 325 с..

.        Кренке
Д. Теория и практика построения баз данных. — СПб.: Питер, 2005. — 859с.

.        Толкунова
В.Н. Информатика. Курс лекций. — М:ООО «ТК Велби», 2002. — 320 с.

.        Гусева
Т.И., Башин Ю.Б. Проектирование баз данных в примерах и задачах.-М.: «Радио и
связь», 2005.

.        Фуллер
Л.У., Кук К., Кауфельд Д. — Microsoft Office Access 2007 для чайников.
Электронный учебник

9.      Кошелев
В.Е. — Access 2007. Эффективное использование —
изд. Бином-Пресс, 2009 г. — 590 с.

.        Широков
Л.А. База данных и Знания: Учебное пособие. Ч.1. — М.: МГИУ, 2000 — 86 с.

.        Хаббард
Дж. Автоматизированное проектирование баз данных. — М.: Мир, 1984.

.        Хомоненко
А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных
заведений/ Под ред. проф. А. Д. Хомоненко. — 4-е издание, доп. и перераб.-
СПб.: КОРОНА принт, 2004.-736 с.

.        Широков
Л.А., Рабинович А.Е., Широкова О.Л.. Информационное обеспечение систем
управления. СУБД «AССESS».-М.: МГИУ 2001-234с.

14.    Microsoft Access
[Электронный ресурс]. — Режим доступа: <#»867683.files/image012.gif»>

Приложение 2

Схема данных

Приложение 3

Формы БД

.        Форма «Вакансии»

2.      Форма «Должности»

.        Сложная форма «Отделы/кафедры»

4.      Сложная форма «Сотрудники»

.        Форма «Штатное расписание»

Приложение 4. Отчеты БД

.        Отчет « Список вакансий»

2.      Отчет «Список пенсионеров»

3.      Отчет «Список сотрудников предпенсионного возраста»

.        Отчет «Список бездетных сотрудников»

5.      Отчет «Список юбиляров»

6.      Отчет «Список многодетных сотрудников»

7.      Отчет «Список ветеранов»

8.      Отчет «Список сотрудников со ставкой больше одной»

9.      Отчет «Штатное расписание»

Библиографическое описание:

Горшков, Е. А. Разработка реляционной базы данных для автоматизации деятельности кадровой службы предприятия / Е. А. Горшков, Н. А. Симанов. — Текст : непосредственный // Молодой ученый. — 2017. — № 22 (156). — С. 34-37. — URL: https://moluch.ru/archive/156/44242/ (дата обращения: 30.05.2023).



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

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

Разработку базы данных для автоматизации основных процессов и операций деятельности кадровой службы конкретного предприятия необходимо производить с учетом всех особенностей кадрового делопроизводства предприятия:

‒ масштаба предприятия;

‒ количества работающих;

‒ количества кадровых работников и уровня их компьютерной грамотности;

‒ объема обрабатываемых организационно-документационных массивов;

‒ оснащенности предприятия аппаратно-программными средствами.

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

База данных «Кадровик» предназначена для хранения данных о сотрудниках предприятия ЗАО «ЗЭМК ГЭМ» в электронном виде, а также автоматизации поиска и корректировки данных и автоматической генерации необходимой отчетности, поэтому предметной областью проектируемой базы данных является деятельность кадровой службы предприятия ЗАО «ЗЭМК ГЭМ».

Процесс проектирования базы данных для кадровой деятельности предприятия ЗАО «ЗЭМК ГЭМ» включает в себя выбор системы управления базой, инфологическое, логическое и физическое проектирование базы данных.

При разработке инфологического моделирования БД «Кадровик», было выделено три стержневые сущности: «Сотрудники», «Отдел», «Должность», ассоциативная сущность «Штатное расписание» и характеристические сущности: «Сведения о профессии», «Сведения о медицинском обследовании», «Сведения о повышении квалификации», «Паспортные данные», «Социальные льготы», «Увольнения», «Сведения о поощрениях», «Отпуска», «Сведения о командировках».

Для проектируемой БД «Кадровик», разработанная ER-диаграмма в нотации IDEF1X (рис. 1).

Рис. 1ER-диаграмма для БД «Кадровик»

В качестве инструментального средства разработки реляционной базы данных «Кадровик» выбрано MS Access, как наиболее полно удовлетворяющее требованиям Заказчика. СУБД Microsoft Аccess относится к СУБД реляционного типа, работающая в среде Windows. Этот программный продукт является составной частью интегрированного пакета для офиса Microsoft Office Professional.

Преобразование ER–диаграммы в схему БД выполняется путем сопоставления каждой сущности и каждой связи, имеющей атрибуты, отношения (таблицы БД). В режиме конструктора было создано тринадцать таблиц: Сотрудники, Паспортные данные сотрудников, Отдел, Штатное расписание, Должность, Социальные льготы, Отпуск, Увольнения, Сведения о повышении квалификации, Сведения о поощрениях, Сведения о профессии, Сведения о медицинском обследовании, Сведения о командировках. Полям таблицы были заданы определённые типы данных, что способствует контролю целостности данных.

Схема данных БД «Кадровик» представлена на рис. 2.

Рис. 2 Схема данных БД «Кадровик»

В качестве примера реализации интерфейса ввода/вывода данных в данной БД приведены: «Главная кнопочная форма БД «Кадровик», которая представляет собой навигационную форму, которая позволяет свободно перемещаться между своими вкладками (рис.3); «Сведения о сотрудниках ЗАО «ЗЭМК ГЭМ» (рис.4); форма «Поиск сотрудников ЗАО «ЗЭМК ГЭМ» по различным критериям» (рис. 5).

Главной задачей данной базы является предоставление информации об автоматической генерации свободных вакансий в ЗАО «ЗЭМК ГЭМ» в зависимости от количества сотрудников по штату и количества фактически работающих сотрудников по должностям и отделам. Для этого в базе разработаны запросы в режиме SQL –«Количество сотрудников по штату», запрос «Вакансии» (Рис. 6).

Запросы являются основным инструментов поиска, обновления и выборки данных из таблиц. Access в соответствии с концепцией реляционных баз данных для выполнения запросов использует язык структурированных запросов SQL (Structured Query Language). С помощью инструкций языка SQL реализуется любой запрос в Access.

Рис. 3. Главная кнопочная форма БД «Кадровик»

Рис. 4 Форма «Сведения о сотрудниках ЗАО «ЗЭМК ГЭМ»

Рис. 5 Форма «Поиск сотрудников ЗАО «ЗЭМК ГЭМ» по различным критериям»

Рис. 6. Запросы «Количество сотрудников по штату», «Вакансии» в режиме SQL

Таким образом, в базе данных «Кадровик» было разработано 12 различных запросов, 17 форм и отчет.

Разработанные средства извлечения и преобразования данных, формы вывода и предоставления информации позволят автоматизировать основные операции деятельности кадровой службы ЗАО «ЗЭМК ГЭМ» и будут способствовать повышению эффективность деятельности предприятия в целом.

Таким образом, создание и использование реляционной базы данных в кадровой деятельности ЗАО «ЗЭМК ГЭМ» будет способствовать автоматизации основных операций кадровой деятельности данного предприятия, автоматическому формированию необходимой отчетности по движению кадрового состава предприятия.

Литература:

1. Токарев А. Н. К вопросу использования информационных технологий в автоматизации управленческой деятельности: статья//Проблемы развития устойчивых отношений между государством, гражданским обществом и бизнесом: вызовы времени. Сборник статей по материалам конференции, посвящённой Дню российской науки (8 февраля 2016 г.). Научный сборник — Балаково: Балаковский филиал ФГБОУ ВПО РАНХиГС. — 2016. С. 47–51.
2. Королева, О. Н. Базы данных [Электронный ресурс]: курс лекций / О. Н. Королева, А. В. Мажукин, Т. В. Королева— Электрон. текстовые данные.— М.: Московский гуманитарный университет, 2012.— 66 c. — Режим доступа: http://www.iprbookshop.ru/14515.

Некоторые компании разрабатывают программную систему специально для своих рекрутеров. Это технологически непростая задача.

Я знаю, как ее решать в деталях и какие нюансы нужно учесть, поскольку руководил разработкой «с нуля» успешной облачной и корпоративной системы для найма.

Прочитав эту статью, вы узнаете:

• Функциональные требования к современному ПО для подбора персонала;
• Требования к безопасности;
• Некоторые технические рекомендации;
• Нюансы поддержки и дальнейшего развития;
• Рекомендации о том, что нужно сделать перед началом разработки;
• Как можно облажаться.

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

Что такое система для рекрутинга?

Рекрутеры — это люди, подбирающие персонал.

Система для автоматизации рекрутинга — это программное решение, в котором рекрутеры могут:

• Удобно вести рабочую базу кандидатов и вакансий;
• Работать совместно, разделять ответственность и устанавливать напоминания;
• Упростить и автоматизировать ведение базы данных и подбор персонала.

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

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

Какой должна быть система? Требования.

I. Минимальные функциональные требования

Требования, без которых систему не стоит запускать:

1. Добавление в базу и редактирование данных по вакансиям, кандидатам, заказчикам. Возможность написания комментариев по ним.

2. Поиск вакансий и кандидатов по нескольким параметрам.

3. Лёгкость ведения базы данных. Эта важнейшая функция сводится в основном к простоте и скорости добавления кандидатов в систему: рекрутеры добавляют в базу сотни резюме в месяц.

Кандидатов можно добавить в систему из:

• файлов резюме в электронном виде;
• онлайн-профиля в LinkedIn;
• онлайн-резюме на сайтах поиска работы.

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

А что, если рекрутеры получили 30-200 откликов по вакансии на сайте поиска работы? Переносить их в систему вручную — трудоемко, даже если требуется перенести лишь часть из них. Если же переносить в базу не всю информацию, это отразится на дальнейшей эффективности работы.

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

Я специально привел аргументы и примеры, т. к. выполнение или не выполнение этого пункта определяет успех или провал системы. Сейчас есть много облачных программ для рекрутинга, а также решений, разработанных специально под конкретную компанию. Многие потерпели крах именно из-за пренебрежения парсингом резюме (автоматический перенос данных системой из загруженных файлов) и интеграцией с LinkedIn, сайтами поиска работы, электронной почтой.

4. Защита от дублирования кандидатов (их резюме) в базе.Не стоит недооценивать важность и сложность этой задачи. Ниже расскажу почему.

5. Совместная работа команды нанимателей с общей базой вакансий и кандидатов. Это включает возможность назначать ответственных рекрутеров по конкретным вакансиям и кандидатам.

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

7. Фиксирование истории каждого действия пользователями в системе.Это позволяет формировать отчеты о проделанной работе, статистику по работе рекрутеров и закрытию вакансий, а также точно знать, кто, что и когда именно сделал.

II. Обязательные функциональные требования

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

1. Полнотекстовый поиск по файлам резюме.

2. Уведомления о важных действиях и событиях на почту и в интерфейсе.

3. Интеграция с онлайн-календарем (Google Calendar, Outlook, и т.д.).

4. Удобные и настраиваемые этапы для кандидатов по вакансии (workflow вакансии) и причины отказов кандидатов.

5. Интеграция с email:

• перенос в базу данных резюме, которые пришли рекрутеру на email;
• сохранение истории email-переписки с кандидатами на их страницах в системе;
• возможность автоматически отправить кандидату напоминание о собеседовании с адресом и картой проезда.

6. Отчеты о проделанной работе по вакансии.

7. Отчет по результатам работы каждого рекрутера за конкретный период.

8. Поиск по ФИО кандидата с транслитерацией, как умеет Facebook.

9. Понятное, «интуитивное» взаимодействие с программой (и весь UX интерфейса в целом).

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

III. Продвинутые требования

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

1. Отчет по источникам появления кандидатов.

2. Расчет средней зарплаты по кандидатам, отобранным на вакансию.

3. Возможность опубликовать вакансию в соцсетях в один клик. Также отдельная страница вакансии, с которой кандидаты отправляют резюме напрямую в систему.

4. Страница со всеми вакансиями компании, которую можно удобно внедрить на корпоративном сайте.

5. Возможность дать заказчику доступ к вакансиям в программе, чтобы он мог просматривать все отобранные резюме и отмечать по ним решения без общения с рекрутером.

6. Матчинг (автоматические рекомендации) подходящих кандидатов: система определяет в базе наиболее подходящих под заданные требования вакансии кандидатов по их резюме и предлагает рекрутеру.

7. Массовая загрузка новых резюме в базу в виде архива с файлами резюме.

8. Ведение задач по кандидатам и вакансиям с напоминаниями.

9. Мобильное приложение или удобная мобильная версия сайта.

10. Рассылка кандидатам вакансий на почту.

11. API для интеграции с сайтом или внутренними программами компании.

IV. Требования к безопасности

1. Шифрование паролей. С солью.

Для многих программистов и архитекторов ПО это само собой разумеется. При этом шифрование паролей многие игнорируют.

Не так давно была утечка части базы Яндекса с логинами и паролями от почты. Еще раньше у ведущих сайтов поиска работы функция «Забыли пароль?» просто присылала на почту пароль в открытом виде. Выходит, он так и хранится в базе в открытом виде. Некоторые сайты перестали так делать и выдают ссылку для смены пароля. Правда, это не значит, что пароли зашифрованы.

Зачем это делать?

Пароли в открытом виде может тайно кому-то передать или «слить» в сеть кто-то из администраторов. Руководство даже ничего не узнает о махинациях. Третьи лица могут скопировать себе данные из системы, потому что они заходят в нее по известным логинам и паролям, и им все доступно.

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

Зашифрованные пароли — это профессиональный подход. Лучше не брать на себя риски утечки паролей. Если кто-то получит хорошо зашифрованные пароли, расшифровать и воспользоваться ими будет практически нереально.

2. Шифрованное SSL-соединение.

Шифрование защищает данные от перехвата. Если в адресе сайта есть «https», это значит, что данные от браузера к серверу передаются зашифрованными и их перехват будет бесполезен. Логин и пароль не смогут перехватить. Это легко и дешево сделать для любого сайта.

3. Бекапы (откаты изменений системы). Само собой.

V. Важные технические требования

1. Вечные пользовательские сессии, которые не занимают оперативную память.

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

2. Для полнотекстового поиска по резюме нужно использовать специальный «движок».

Например, Apache Solr. Он вряд ли будет эффективно работать сразу после внедрения. Его необходимо донастраивать, проводить много тестов. Это творческая и интеллектуальная работа.

3. База данных быстро увеличивается.

Нужно строить эффективные индексы и писать эффективные SQL-запросы.

4. Программисты должны уметь находить и устранять утечки памяти.

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

VI. Нюансы поддержки и развития ПО

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

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

2. Выход новых версий браузеров вносит изменения в интерфейс пользователей. У них может что-то «поехать», перестать работать или начать выглядеть хуже.

3. Большое разнообразие вариантов резюме или вакансий приводит к тому, что периодически находятся варианты, которые имеют недостатки во внешнем виде, парсинге, рекомендациях. Приходится постоянно искать новые решения, учитывать разные нюансы, совершенствовать алгоритмы.

4. Мир не стоит на месте. Все развивается. Рекрутерам постоянно нужны новые функции. Если их не предоставлять, возможности нанимателей начинают отставать от возможностей их коллег из других компаний.

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

5. Обычные вопросы пользователей и их проблемы, которые иногда непонятно как воспроизвести. Запросы скриншотов, пояснения — все это требует вовлечения программистов.

VII. Рекомендации перед началом разработки

Для разработки «с нуля» системы для рекрутинга, которая соответствует минимальным и обязательным требованиям, может потребоваться 35-50 человеко-месяцев работы.

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

Что нужно сделать перед началом разработки, некоторые рекомендации:

1. Детально расписать, какие функции ПО предпочтительны и достаточны для рекрутеров. Можно отталкиваться от списка, приведенного выше.

2. Вместе с архитектором ПО рассчитать бюджет, необходимый на всю разработку, а также состав команды и срок реализации проекта.

3. Определить, чем пользоваться, пока система в разработке.

4. Запросить коммерческие предложения от узкопрофильных поставщиков систем для рекрутинга.

Возможно, вы получите выгодные предложения за хорошую готовую систему, не вовлекая трудовые и финансовые ресурсы своей компании.

VIII. Как можно облажаться

1. Потратить неприемлемо много денег.

При средней стоимости человеко-месяца для компании на уровне 1 500 USD (экономно), стоимость всей разработки составит от 52 500 до 75 000 USD. Напомню, это из расчета 35-50 человеко-месяцев работы.

Для примера: такие гиганты, как SoftServe и GlobalLogic разрабатывают свои системы для найма уже несколько лет (!).

Тут есть еще такой неприятный фактор: жалко бросать проект после того, как его долго делали и много денег вложили.

Подобные терзания испытывают неопытные игроки в покер, когда уже поставили много и продолжают повышать ставки, даже когда игра складывается не в их пользу.

2. Разрабатывать слишком долго, вынуждая рекрутинг страдать быть неэффективным все это время.

3. Делать-делать и недоделать. Или отдать рекрутерам софт в таком плачевном состоянии, что они не захотят им пользоваться.

Так бывает, когда сменяется руководство или HR-директор, которые участвовали в принятии решения о разработке.

Желаю вам успехов в этом затягивающем и увлекательном деле!

Источник :

«