83065

Разработка АИС «Работа отдела кадров»

Курсовая

Информатика, кибернетика и программирование

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

Русский

2015-03-07

6.6 MB

35 чел.

ГОУ ВПО

РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИННОВАЦИОННЫХ  ТЕХНОЛОГИЙ И ПРЕДПРИНИМАТЕЛЬСТВА

Кафедра информационных систем

Курсовой проект

Дисциплина: «Проектирование информационных систем»

Тема: «Разработка АИС «Работа отдела кадров»

Выполнила: студентка гр.09И

Шкоткина В.А.

Проверила: старший  преподаватель

Голобокова Е.М.

Пенза, 2013


Изм.

Лист

№ докум.

Подпись

Дата

Лист

Курсовой проект

Разраб.

Шкоткина В.А

Провер.

Голобокова ЕМ

Реценз.

Н. Контр.

Утверд.

Разработка автоматизированной системы «Работа отдела кадров»

Пояснительная записка

Лит.

Листов

54

Гр.09И

Реферат

Пояснительная записка содержит 54 листа, 9 рисунков, 10 таблиц,             8 источников, 3 приложения.

АВТОМАТИЗИРОВАННАЯ информационная СИСТЕМА, CASE – средствА, база данных

Объектом исследования является работа отдела кадров.

Цель разработки – облегчить работу сотрудникам отдела кадров, уменьшить время затрачиваемое на составление различных отчётов.

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

Автоматизированная система формирует отчёты в виде таблиц; хранит личные данные и приказы на каждого сотрудника.


Содержание:

Введение 5

1. Анализ предметной области 7

2. Техническое задание 9

3.   Функциональное проектирование информационной системы 11

3.1 Общие сведения о AllFusion Process Modeler 7 11

        Методология DFD 14

3.2 Описание функциональной модели системы 15

4.    Инфологическое проектирование информационной системы 17

     4.1 Общие сведения о AllFusion Data  Modeller 7 17

     4.2 Построение логической модели данных 19

     4.3 Построение физической модели данных 21

     4.4 Нормализация. 24

5. Описание программы 26

5.1 Общие сведения 26

5.2 Общие понятия и определения 27

5.3 Описание логической структуры 29

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

5.3.3 SQL запросы 36

5.3.4 Создание форм 37

6.   Программа и методика испытаний 40

6.1 Объект и цель испытаний 40

6.2 Методы испытания 40

Заключение 41

Список литературы: 42

Приложение А. 43

Приложение Б. 47

Приложение В. 49


Введение

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

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

Одной из наиболее распространенных СУБД является MS Access. Широкое применение именно этой СУБД для небольших офисных программ связано с тем, что она интегрирована в пакет прикладных программ MS Office, не требует большого объема памяти и достаточно проста в использовании.

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

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

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


  1.  Анализ предметной области

Предметной областью является деятельность отдела кадров.

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

При приеме на работу сотрудники отдела кадров должны принять документы у соискателя: трудовую книжку, документ об образовании, паспорт.  На основе этих документов создаётся личная карточка сотрудника по форме №Т-2, которая содержит в себе табельный номер сотрудника, фамилия, имя, отчество, дата рождения, пол, семейное положение, адрес проживания, телефон, паспортные данные (серия, номер, кем и когда выдан, дата выдачи, место рождения), национальность и образование. Далее сотрудники составляют приказ о приеме на работу по форме №Т-1 и оформляют трудовой договор - соглашение между работником и работодателем, в соответствии с которым работник обязуется лично выполнять работу по определённой должности, соответствующей его квалификации.

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

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

После увольнения сотрудника, ему возвращается трудовая книжка с определенной отметкой. Задержка выдачи трудовой книжки - это нарушение, за которое может грозить штраф (ч.1 ст.5.27 КоАП РФ).

При увольнении работник должен расписаться в следующих документах:

  1.  в приказе об увольнении (форма №Т-8);
  2.  в трудовой книжке после записи об увольнении (п.35 Правил, утв. Постановлением Правительства от 16.04.2003 №225)
  3.  в личной карточке по форме №Т-2

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


  1.  Техническое задание

2.1 Основание для разработки

Разработка ведется на основе задания на курсовое проектирование по курсу

«Проектирование информационных систем». Задание выдано______

2.2  Назначение разработки

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

2.3 Требования к программе

2.3.1 Требования к функциональным характеристикам

Автоматизированная информационная система «Работа отдела кадров» должна обеспечить:

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

б) изменение и хранение штатного расписания (ID-штатной единицы, подразделение, должность, количество ставок, оклад, надбавка);

в) ввод и хранение приказов о приеме на работу, о переводе на другую должность и об увольнении;

д) должно допускаться редактирование введённой ранее информации;

Входными данными для системы являются: паспортные данные сотрудника и документ об образовании.

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

2.3.2 Требования к надежности

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

в рамках предоставляемых пользователю возможностей.

2.3.3 Требования к составу и параметрам технических средств

Информационная система предназначена для использования на IBM-

совместимых персональных компьютерах с минимальной конфигурацией: PentiumII

600 MHz, 128 Mb ОЗУ. Дополнительно необходимо наличие принтера.

2.3.4 Требования к информационной и программной совместимости

База данных должна быть создана с использованием Microsoft Access.

Программа должна работать в операционных системах Windows XP/Windows 7/Vista/Windows 8.

72.4 Требования к программной документации

Комплект разрабатываемых документов должен включать:

− текст программы (листинг);

− описание программы;

− программу и методику испытаний;

− описание применения.

2.6 Порядок контроля и приемки

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

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

3. Функциональное проектирование информационной системы

3.1 Общие сведения о AllFusion Process Modeler 7

Описание, анализ и моделирование бизнес-процессов без применения специальных инструментов возможно только в самых простейших случаях. Для решения этих задач создана программа AllFusion Process Modeler 7, которая включает следующие методологии: IDEF0, DFD и IDEF3.

Пакет AllFusion Process Modeler 7 предназначен для создания функциональной модели существующей или проектируемой информационной системы.

Функциональная модель включает в себя:

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

AllFusion Process Modeler 7 с использованием IDEF0 методология позволяет наглядно представить выбранную систему как совокупность взаимодействующих функций и задач. Функции и задачи системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

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

AllFusion Process Modeler 7 автоматически синхронизирует изменения объектов диаграмм на всех уровнях детализации, тем самым, освобождая пользователя от ручного ведения словаря объектов модели. Так если мы исправим на верхнем уровне название объекта, то получим изменение на всех уровнях, где данный объект встречается. Также невозможным является случайное дублирование наименований работ. При появлении такой ситуации AllFusion Process Modeler 7 генерирует предупреждающее сообщение.

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

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

Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов, хранение объектов, поставка и распространение объектов.

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

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

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

Различают пять типов стрелок:

  1.  Вход (Input) - материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы.
  2.  Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы.
  3.  Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы.
  4.  Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы.
  5.  Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка механизма рисуется как исходящая из нижней грани работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В AllFusion Process Modeler 7 стрелки вызова используются в механизме слияния и разделения моделей.

Методология DFD

Целью методологии является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram – DFD).  Диаграммы потоков данных предназначены прежде всего для описания документооборота и обработки информации, хотя допускают и представление других объектов.

При создании диаграммы потоков данных используются четыре основных понятия: 

– потоки данных,

– процессы (работы) преобразования входных потоков данных в выходные,

– внешние сущности,

– накопители данных (хранилища).

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

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

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

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

 Для детализации процесса используется декомпозиция.

3.2 Описание функциональной модели системы

При разработке функциональной модели данной автоматизированной информационной системы, использовалась методология DFD. Контекстная диаграмма «Работа отдела кадров» представлена на рисунке А1 приложение А. На вход поступают сведения от внешних объектов – от объекта Бухгалтерия отдел кадров получает штатное расписание, от объекта Сотрудник –паспортные данные, трудовую книжку и документ об образовании. На выходе к внешнему объекту Бухгалтерия возвращается изменённое штатное расписание, списки уволенных и переведённых на другую должность, в Каталог приказов поступают приказы о приеме на работу, об увольнении и о переводе на другую должность, во внешние объекты Личные карточки и Трудовые договоры передаются личная карточка каждого сотрудника и трудовой договор соответственно. Состоит из нескольких процессов, поэтому необходимо декомпозировать (рисунок А2 приложение А):

  1.  Процесс «Прием на работу». На вход – документ об образовании, паспорт, трудовая книжка, информация о штатной единице, на выходе –личная карточка, трудовой, а также приказ о приеме на работу необходимый для дальнейшего использования в АИС. Состоит из нескольких процессов, поэтому необходимо декомпозировать (рисунок А3 приложение А).
  2.  Занесение информации о сотруднике и составление приказа о приеме на работу (вход: информация о штатной единице, документ об образовании, паспорт, трудовая книжка; выход: сведения из приказа, сведения о сотруднике(помещаются в хранилище Сотрудник), приказ о приеме на работу, который помещается в хранилище Приказ о приеме на работу)
  3.  Оформление трудового договора (вход: номер приказа о приеме на работу(берется из хранилища Приказ о приеме на работу); выход: трудовой договор)
  4.  Создание личной карточки (вход: сведения из приказа, личные данные (из хранилища Сотрудник); выход – личная карточка)

2.    Процесс «Формирование штатного расписания». На вход – штатное расписание, на выходе – информация о штатной единице. Состоит из нескольких процессов, поэтому необходимо декомпозировать (рисунок А4 приложение А).

  1.  Создание штатной единицы (Вход: штатное расписание, наименование подразделения(из хранилища Подразделение), название должности(из хранилища Должность); выход: сведения о штатной единице)
  2.  Утверждение штатного расписания (Вход: сведения о штатной единице; выход: сформированное штатное расписание, которое помещается в хранилище Штатное расписание)

3.   Процесс «Увольнение». На вход – информация о штатной единице, на выходе – списки уволенных и приказ об увольнении(помещается в хранилище Приказ об увольнении).

4.   Процесс «Перевод на другую должность». На вход -  информация о штатной единице, на выходе – приказ о переводе на другую должность(помещается в хранилище Приказ о переводе на другую должность), списки переведенных на другую должность.

5.  Процесс «Фиксирование изменений штатного расписания». На вход – списки переведенных на другую должность и списки уволенных, на выходе – измененное штатное расписание.


4. Инфологическое проектирование информационной системы

4.1 Общие сведения о AllFusion Data  Modeller 7

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

AllFusion Data  Modeller 7 имеет два уровня представления модели - логический и физический.

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

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

Основные компоненты диаграммы AllFusion Data  Modeller 7 - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту - колонка таблицы.

Стержневая сущность – это независимая сущность.

Ассоциативная сущность – это связь вида "многие-ко-многим"  между двумя или более сущностями или экземплярами сущности. Такие сущности рассматриваются как полноправные: они могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности; могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь.

Связь является логическим соотношением между сущностями. Различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, AllFusion Data  Modeller 7 автоматически преобразует дочернюю сущность в зависимую. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK). При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности. Неидентифицирующая связь служит для связывания независимых сущностей.

Мощность связи служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Различают четыре типа мощности: общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности не помечается каким-либо символом; символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности;  символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности; цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.

  1.   Построение логической модели данных

4.2.1 Выделение сущностей.

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

Таблица 1 - Сущности и их атрибуты

Сущность

Атрибут

Ключи

Подразделение

ID-подразделения

PK

Название подразделения

Должность

ID-должности

PK

Название_должности

Штатное расписание

ID-штатной_единицы

PK

ID-подразделения

FK

ID-должности

FK

Количество_ставок

Оклад

Надбавка

Приказ о приеме на работу

Номер_приказа

PK

Дата_утверждения

ID-сотрудника

FK

ID-штатной_единицы

FK

Количество_ставок

Приказ об увольнении

Номер_приказа

PK

Дата_утверждения

ID-сотрудника

FK

Основание

Приказ о переводе на другую должность

Номер_приказа

PK

Дата_утверждения

ID-сотрудника

FK

ID-штатной единицы

FK

Сотрудник

ID-сотрудника

PK

Фамилия

Имя

Отчество

Дата_рождения

Пол

Семейное_положение

Адрес_проживания

Телефон

Серия_паспорта

Номер_паспорта

Где_и_кем_выдан

Дата_выдачи

Место_рождения

Национальность

Образование

4.2.2 Установка связей.

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

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

Родительская сущность

Дочерняя сущность

Тип связи

Мощность связи

Внешний ключ

Сотрудник

Приказ о приеме на работу

Неидентифицирующая

1:М

ID-сотрудника

Приказ о переводе на другую должность

Неидентифицирующая

1:М

ID-сотрудника

Приказ об увольнении

Неидентифицирующая

1:М

ID-сотрудника

Подразделение

Штатное расписание

Неидентифицирующая

1:М

ID-подразделения

Должность

Штатное расписание

Неидентифицирующая

1:М

ID-должности

Штатное расписание

Приказ о приеме на работу

Неидентифицирующая

1:М

ID-штатной_единицы

Приказ о переводе на другую должность

Неидентифицирующая

1:М

ID-штатной_единицы

  1.  Стержневые сущности.

Стержневые сущности – это независимые сущности. Выделены следующие стержневые сущности: «Сотрудник», «Подразделение», «Должность».

Разработанная логическая модель представлена на рисунке Б1 приложение Б.

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

Физическая модель – это отображение логической модели на модели данных конкретной СУБД. Физическая модель создана для СУБД Access.

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

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

Таблица 3 – Описание физической модели

Название поля

Тип данных

Ограничение

Модификаторы

Сущность «Сотрудник»

Код_читателя

Integer

NOT NULL PRIMARY KEY

Фамилия

Text

15

NOT NULL

Имя

Text

15

NOT NULL

Отчество

Text

15

NOT NULL

Дата_рождения

Date/Time

15

NOT NULL

Пол

Text

3

NOT NULL

Семейное_положение

Text

10

NOT NULL

Адрес_проживания

Text

30

NOT NULL

Телефон

Text

12

NULL

Серия_паспорта

Text

4

NOT NULL

Номер_паспорта

Text

6

NOT NULL

Где_и_кем_выдан

Text

100

NOT NULL

Дата_выдачи

Date/Time

NOT NULL

Место_рождения

Text

50

NOT NULL

Национальность

Text

20

NOT NULL

Образование

Text

25

NOT NULL

Сущность «Должность»

ID-должности

Integer

NOT NULL PRIMARY KEY

Название_должности

Text

20

NOT NULL

Сущность «Подразделение»

ID-подразделения

Integer

NOT NULL

PRIMARY KEY

Название_подразделения

Text

20

NOT NULL

Сущность «Приказ о приеме на работу»

Номер_приказа

Integer

NOT NULL

PRIMARY KEY

Дата_утверждения

Date/Time

NOT NULL

ID-сотрудника

Integer

NOT NULL

ID-штатной_единицы

Integer

NOT NULL

Количество_ставок

Double

Сущность «Приказ о переводе на другую должность»

Номер_приказа

Integer

NOT NULL PRIMARY KEY

Дата_утверждения

Date/Time

NOT NULL

ID-сотрудника

Integer

NOT NULL

ID-штатной единицы

Integer

NOT NULL

Сущность «Приказ на увольнение»

Номер_приказа

Integer

NOT NULL PRIMARY KEY

Дата_утверждения

Date/Time

NOT NULL

ID-сотрудника

Integer

Основание

Text

18

NULL

Сущность «Штатное расписание»

ID-штатной_единицы

Integer

NOT NULL

PRIMARY KEY

ID-подразделения

Integer

NOT NULL

ID-должности

Integer

NOT NULL

Количество_ставок

Integer

NOT NULL

Оклад

Currency

NOT NULL

Надбавка

Currency

NOT NULL

В качестве модификаторов использованы следующие значения:

  1.  NOT NULL - поле не может содержать неопределенного значения (NULL), то есть поле должно быть явно инициализировано;
  2.  PRIMARY KEY - поле будет первичным ключом (идентификатором записи), по которому можно однозначно идентифицировать запись;

Разработанная физическая модель представлена на рисунке Б2 приложение Б.

4.4 Нормализация.

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

Первая нормальная форма (1НФ) – в сущности должен быть выделен первичный ключ, атрибуты должны быть неделимыми и неповторяющимися. Пример приведения сущности «Сотрудник» к 1НФ (рисунок 1).

Рисунок 1 - Сущность «Сотрудник», приведённая к 1НФ

В данной сущности выделен первичный ключ – «ID-сотрудника», поля неповторяющиеся и неделимы.

Вторая нормальная форма (2НФ) - сущность находится во 2НФ, если она находится в 1НФ и каждый неключевой атрибут полностью зависит от первичного ключа. Пример приведения сущности «Авторы_и_книги» ко 2НФ (рисунок 2).

Рисунок 2 - Сущность «Штатное расписание», приведённая ко 2НФ

Третья нормальная форма (3НФ) - сущность находится в 3НФ, если она находится во 2НФ и никакой неключевой атрибут не зависит от другого неключевого атрибута.

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


  1.  Описание программы

5.1 Общие сведения

Информационная система «Работа отдела кадров» разработана в среде  MS Office Access 2003.

Приложение Microsoft Access – это настольная система управления реляционными базами данных (СУБД), предназначенная для работы на автономном персональном компьютере (ПК) или локальной вычислительной сети под управлением семейства операционных систем Microsoft Windows (Windows 2000, Windows XP, Windows 7, Windows 8, Vista.

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

  1.  Проектирование базовых объектов – двумерные таблицы с полями разных типов данных.
  2.  Создание связей между таблицами, с поддержкой целостности данных, каскадного обновления полей и каскадного удаления записей.
  3.  Ввод, хранение, просмотр, сортировка, изменение и выборка данных из таблиц с использованием различных средств контроля информации, индексирования таблиц и аппарата алгебры логики.
  4.  Создание, модификация и использование производных объектов (запросов, форм и отчетов).

Основные компоненты MS Access:

  1.  построитель таблиц;
  2.  построитель экранных форм;
  3.  построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);
  4.  построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически «с нуля» или написать оболочку для внешней БД.

5.2 Общие понятия и определения

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

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

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

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

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

Таблица (table) - множество ячеек с данными, образующих строки и столбцы прямоугольной таблицы. Таблица реализует сущность в понятии реляционной модели данных. Строки таблицы представляют экземпляры сущности и называются записями (records). Столбцы таблицы представляют атрибуты сущности и называются полями (fields).

Атрибут* (attribute) представляет собой определенное свойство (характеристику) данной сущности. Рекомендуется в качестве атрибутов выделять атомарные свойства сущности.

Поле таблицы (table field) - столбец в прямоугольной таблице. Поле таблицы реализует атрибут в понятии реляционной модели, при этом данные, хранятся в ячейках одного столбца, должны принадлежать одному домену. Домен определяет набор допустимых значений и операций над данными. То есть данные в ячейках одного столбца должны быть одного типа.

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

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

Ключевое поле (key field) — поле, представляющее первичный ключ или являющееся частью составного первичного ключа.

Альтернативный ключ (alternative key) — обычные поля или комбинации атрибутов, отличающиеся от первичного ключа сущности, но также претендующие на эту роль.

Связь (relationship) - это логическое отношение между сущностями, выражающее некоторое ограничение или правило. В реляционной модели вводится понятие реляционной связи (relation) — это связь между записями, основанная на совпадении (или ином предикате) значений атрибутов, по которым устанавливается связь.

Основные объекты Access - таблицы, формы, запросы, отчеты, макросы, модули.

Таблица является основой БД, в ней хранится вся информация.

Процесс создания отдельной таблицы в составе БД состоит из следующих этапов:

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

2) Ввод данных в таблицу. Установить связи по общим полям методом ДД перетаскивая их от главной таблицы к связанной

3) Сохранить схему данных, закрыть окно.

5.3 Описание логической структуры

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

  1.  Создание таблиц базы данных

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

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

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

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

Таблица 4 - Описание полей таблицы «Сотрудник»

Имя поля

Тип данных

Свойства поля

ID-сотрудника

Числовой

Целое, совпадения не допускаются, обязательное поле

Фамилия

Тестовый

Размер поля:15, обязательное поле

Имя

Текстовый

Размер поля:15, обязательное поле

Отчество

Текстовый

Размер поля:15, обязательное поле

Дата_рождения

Дата/время

Краткий формат даты, обязательное поле

Пол

Текстовый

Размер поля:3, обязательное поле

Семейное_положение

Текстовый

Размер поля:10, обязательное поле

Адрес_проживания

Текстовый

Размер поля:30, обязательное поле

Телефон

Текстовый

Размер поля:12, обязательное поле

Серия_паспорта

Текстовый

Размер поля:4, обязательное поле

Номер_паспорта

Текстовый

Размер поля:6, обязательное поле

Где_и_кем_выдан

Текстовый

Размер поля:100, обязательное поле

Дата_выдачи

Дата/время

Краткий формат даты, обязательное поле

Место_рождения

Текстовый

Размер поля:50, обязательное поле

Национальность

Текстовый

Размер поля:20, обязательное поле

Образование

Текстовый

Размер поля:25, обязательное поле

Таблица 5 - Описание полей таблицы «Приказ о переводе на другую должность»

Имя поля

Тип данных

Свойства поля

Номер_приказа

Числовой

Целое, совпадения не допускаются, обязательное поле

Дата_утверждения

Дата/время

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

ID-сотрудника

Числовой

Целое, совпадения допускаются, обязательное поле

ID-штатной единицы

Числовой

Целое, совпадения допускаются, обязательное поле

Таблица 6 - Описание полей таблицы «Приказ о приеме на работу»

Имя поля

Тип данных

Свойства поля

Номер_приказа

Числовой

Целое, совпадения не допускаются, обязательное поле

Дата_утверждения

Дата\время

Краткий формат даты, обязательное поле

ID-сотрудника

Числовой

Целое, совпадения не допускаются, обязательное поле

ID-штатной_единицы

Числовой

Целое, совпадения допускаются, обязательное поле

Количество_ставок

Числовой

Дествительное, точность:2, совпадения допускаются, обязательное поле

Таблица 7 - Описание полей таблицы «Приказ об увольнении»

Имя поля

Тип данных

Свойства поля

Номер_приказа

Числовой

Целое, совпадения  не допускаются, обязательное поле

Дата_утверждения

Дата/время

Краткий формат даты, обязательное поле

ID-сотрудника

Числовой

Целое, совпадения не допускаются, обязательное поле

Основание

Текстовый

Размер поля:50, обязательное поле

Таблица 8 - Описание полей таблицы «Штатное расписание»

Имя поля

Тип данных

Свойства поля

ID-штатной_единицы

Числовой

Целое, совпадения не допускаются, обязательное поле

ID-подразделения

Числовой

Целое, обязательное поле

ID-должности

Числовой

Целое, обязательное поле

Количество_ставок

Числовой

Действительное, совпадения  допускаются, обязательное поле

Оклад

Денежный

Денежный, обязательное поле

Надбавка

Денежный

Денежный, обязательное поле

Таблица 9 - Описание полей таблицы «Должность»

Имя поля

Тип данных

Свойства поля

ID-должности

Числовой

Целое, совпадения не допускаются, обязательное поле

Название_должности

Текстовый

Размер поля:40, обязательное поле

Таблица 10 - Описание полей таблицы «Подразделение»

Имя поля

Тип данных

Свойства поля

ID-подразделения

Числовой

Целое, совпадения не допускаются, обязательное поле

Название подразделения

Текстовый

Размер поля:20, обязательное поле

 

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

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

Рисунок 3 - Схема данных

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

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

Для подготовки запросов в различных СУБД чаще всего используются два основных языка:

  1.  Язык QBE (Query By Example) – язык запросов по образцу,
  2.  Язык SQL (Structured Query Language) – структурированный язык запросов.

По возможностям манипулирования данными в запросах указанные языки практически эквивалентны. Главное отличие заключается в способе формирования запросов: язык QBE предполагает ручное или визуальное формирование запроса, а SQL использует программирование запроса.

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

 Запросы предназначены для отбора данных, удовлетворяющих заданным критериям. В Access запросы делятся на QBE запросы, параметры которых устанавливаются в окне «Конструктор запросов», и SQL запросы, при создании которых используются операторы и функции языка SQL.

Для создания QBE запроса в окне «новый запрос» выберем Мастер «Простой запрос», в появившемся диалоговом окне «Создание простых запросов» выберем путем переноса из «Доступные поля» в окно «Выбранные поля» необходимые для запроса поля

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

Рисунок 4 - Запрос на поиск всех приказов о приеме на работу

Для сложных запросов используют «Конструктор запросов». Окно «Конструктор запросов» разделено на две части. В верхней половине находятся окна таблиц со списками полей.

Нижняя половина представляет собой бланк запроса, в котором производится его построение - добавляют поля в запрос, устанавливают критерии отбора записей и сортировку.

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

Рисунок 5 - Конструктор запросов

Рисунок 6 - Результаты выполнения запроса

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

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

Рисунок 7 - Конструктор запроса с параметром

При запуске данного запроса пользователь увидит следующее окно:

Рисунок 8 – Окно для ввода значения параметра

После ввода нужной фамилии, появятся соответствующий результат:

Рисунок 9 - Результаты выполнения запроса с параметром

5.3.3 SQL запросы

Язык SQL предназначен для выполнения операций над таблицами (создание, удаление, изменение структуры) и над данными таблиц (выборка, изменение, добавление, удаление), и некоторых сопутствующих операций. SQL является непроцедурным языком и не содержит операторов управления, организации подпрограмм, ввода-вывода и т.п. В связи с этим SQL обычно встраивается в СУБД (например, СУБД ACCESS, FoxPro СУБД.).

В современных СУБД с интерактивным интерфейсом можно создавать запросы, как было сказано, например, с помощью языка QBE. Однако применение SQL часто позволяет повысить эффективность обработки данных. Так, при подготовке запроса в ACCESS можно перейти из окна Конструктора запросов (формулирование запроса по образцу на языке QBE) в окно с эквивалентным оператором SQL. Новый запрос можно создать путем редактирования уже имеющегося запроса или программированием нового.

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

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

При построении запроса в окне конструктора система Access работает в фоновом режиме, записывая эквивалентные инструкции SQL.

5.3.4 Создание форм

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

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

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

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

  1.  Автоформа, организованная "в столбец". В такой форме поля каждой записи отображаются в виде набора элементов управления, расположенных в один или несколько столбцов. Это компактное и, пожалуй, самое удачное представление для быстрого создания формы.
  2.  Табличная. Форма будет выглядеть так же, как обычная таблица Access.
  3.  Ленточная. В такой форме поля каждой записи располагаются в отдельной строке. Это очень удобно для работы с большими массивами данных, поскольку данные располагаются в таком же порядке, как в простой таблице.
  4.  Автоформа в виде сводной таблицы или сводной диаграммы.

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

В ходе выполнения курсового проекта были созданы следующие формы:

  1.  «Главная» (рисунок В1 приложение В)
  2.  «Приказы» (рисунок В3 приложение В)
  3.  «Личные дела» (рисунок В2 приложение В)
  4.  «Сотрудники» (рисунок В4 приложение В)
  5.  «Занимаемая должность» (рисунок В5 приложение В)
  6.  «Приказ о приеме на работу» (рисунок В6 приложение В)
  7.   «Приказ об увольнении» (рисунок В7 приложение В)

Форма «Главная» появляется при запуске системы, и позволяет

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


6. Программа и методика испытаний

6.1 Объект и цель испытаний

Объектом испытаний является программа «Автоматизированная информационная система «Работа отдела кадров».

Цель испытания любой программы и в частности данной состоит в том,

чтобы убедиться, что она удовлетворяет всем требованиям технического задания и

действительно решает поставленную задачу при любых условиях.

6.2 Методы испытания

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

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

обработки данных.

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

Если все данные введены верно, то запись о новом сотруднике будет добавлена в таблицу.

Все испытания показали, что система работает корректно.


Заключение

В данной работе была разработана система «Автоматизированная информационная система «Работа отдела кадров».

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

В ходе проделанной работы были решены следующие задачи:

1)  Изучена предметная область, итогом которой является словесное описание и формализованное описание предметной области в виде схем BPWIN (AS IS и TO BE);

2)  Выполнено проектирование структуры базы данных в среде case-средства ERWIN в виде инфологической и даталогической моделей;

3)  Создана база данных в СУБД Microsoft Access;

В итоге проделанной работы был создан готовый программный продукт и достигнуты основные цели разработки:

а)  уменьшение времени выполнения каждой функции;

б)  автоматическое создание документации и отчетов;

в)  простой и быстрый поиск;

г)  автоматическое проставление табельных номеров.

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

Список литературы:

  1.  Иванова Г. С. Технология программирования: Учебник для вузов. – М.: Изд-во МГТУ им. Баумана, 2003
  2.  Боровиков В. В. MS ACCESS 2002. программирование и разработка баз данных и приложений. - СОЛОН-Р, 2002.
  3.  http://ru.wikipedia.org/wiki/Трудовой_договор
  4.  http://ru.wikipedia.org/wiki/Штатное_расписание
  5.  Голицына О. Л., Максимов Н. В., Попов И. И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2004
  6.  Боровиков В. В. MS ACCESS 2002. программирование и разработка баз данных и приложений. - СОЛОН-Р, 2002.
  7.  Элисон Батлер. Microsoft Office Access 2007. Профессиональное программирование – М.: «Вильямс», 2009 г. – 1296.
  8.  Вирджиния Андерсен «Базы данных Microsoft Access. Проблемы и решения» 2006 г.

  1.  


Приложение А.

Рисунок А1 - Контекстная диаграмма


Рисунок А2 - Декомпозиция контекстной диаграммы


Рисунок А3 - Декомпозиция процесса "Прием на работу"

Рисунок А4 - Декомпозиция процесса "Формирование штатного расписания"

Приложение Б.

Рисунок Б1 - Логическая модель информационной системы «Работа отдела кадров»


Рисунок Б2 - Физическая модель информационной системы «Работа отдела кадров»


Приложение В.

Рисунок В1 - Форма "Главная"

Рисунок В2 - Форма "Личные дела"


Рисунок В3 - Форма "Приказы"


Рисунок В4 - Форма "Сотрудники"


Рисунок В5 - Форма "Занимаемая должность"

Рисунок В6 - Форма "Приказ о приеме на работу"


Рисунок В7 - Форма "Приказ об увольнении"