Смекни!
smekni.com

Автоматизированный учет работы кадрового агентства Бизнес трэвел (стр. 5 из 7)

Цель логического проектирования – применение принципов модели разработки приложения к конкретной задаче. Результат этого этапа – структура решения и связи между его элементами. Как правило, в результате логического проектирования определяется набор необходимых объектов, атрибутов и связей, принципы проектирования пользовательского интерфейса и логическая модель данных. (43, с. 290–294) Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных. Каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной. Фактически, ненормализованные таблицы, т.е. таблицы, содержащие повторяющиеся группы, даже не допускаются в реляционной БД. Интерфейс определяет переход от представления данных в БД к представлению, принятому среди пользователей, и обратно. В общем случае пользователи представляют данные в виде документов различных видов, от произвольных текстов до справок и таблиц фиксированного формата.

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

2. Автоматизация учета работы кадрового агентства «Бизнес трэвел»

2.1 Проектирование АИС: создание баз данных, определение языка программирования

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

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

На этапе инфологического проектирования мною были составлены:

· Список исходных документов клиентов, с которыми работает менеджер по персоналу;

· Порядок обработки данных работников и работодателей;

· Список выходных данных, которые необходимы агентству для управления структурой своего предприятия;

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

- Работа начинается с составления генерального списка полей;

- В соответствии с типом данных, размещаемых в каждом поле, определяется наиболее подходящий тип для каждого поля;

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

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

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

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

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

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

1) Работники – в таблицу занесены основные анкетные данные клиента. Таблица имеет следующие поля:

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

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

Номер анкеты, военнообязанный, знание ПК, знание программ ПК, категория водителя, дети, семейное положение, прочие данные (Приложение 3).

3) Направления – таблица заполняется при выписке вакансии для работника. Связана с таблицей Работники и имеет следующие поля:

Номер анкеты, вакансия, дата направления, оплата, результат собеседования (Приложение 3).

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

1) Работодатели – реквизиты работодателей, таблица формируется на основании карточки работодателя. Таблица имеет следующие поля:

Номер анкеты, название организации, сфера деятельности, условия договора, адрес, телефон, Ф.И.О. ответственного лица, должность, прочие сведения (Приложение 4).

2) Вакансии – содержит сведения о требуемой вакансии. Связана с таблицей Работодатели и имеет следующие поля:

Номер анкеты, должность, оперативность вакансии, пол, возраст, опыт, образование, зарплата, прочие требования (Приложение 4).

3) Трудоустроенные – таблица служит для хранения данных о трудоустроенных клиентах. Информация в таблицу записывается путем копирования записи из таблицы Работники. Содержит те же поля что и таблица Работники.

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

В данной задаче существует следующая взаимосвязь таблиц: 1) Связь таблицы «Работники» с таблицей «Прочие сведения» осуществляется по полю «Номер анкеты»; 2) Связь таблицы «Работники» с таблицей «Направления» осуществляется по полю «Номер анкеты»; 3) Связь таблицы «Трудоустроенные» с таблицей «Направления» осуществляется по полю «Номер анкеты»; 4) Связь таблицы «Работодатели» с таблицей «Вакансии» осуществляется по полю «Номер анкеты». На рис. 1 представлена схема.

Рис. 1. Схема взаимосвязи таблиц


Поскольку задача «Автоматизация учета работы кадрового агентства «Бизнес трэвел» подразумевает ведение анкетных данных работников и карточек работодателей, отслеживание и поиск клиентов, то выходная информация выдается в виде списков вакансий и работников:

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

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