Проектирование базы данных для автоматизации работы отдела кадров

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Постановка задачи

2. Системный проект

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

2.2 Описание данных

2.3 Проектирование логической структуры базы данных методом нормальных форм

2.4 Проектирование логической структуры базы данных методом «сущность-связь»

2.5 Сравнительный анализ спроектированной базы данных и базы данных существующих информационных систем

3. Технический проект

3.1 Выбор состава технических и программных средств

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

3.3 Экспорт физической структуры в СУБД

Заключение

Список использованной литературы

Приложение

Введение

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

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

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

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

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

Многие люди даже не догадываются, насколько сложен и трудоемок кадровый учет. Чаще всего выделяют 3 основные современные сложности:

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

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

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

1. Постановка задачи

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

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

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

Таким образом, создание автоматизированной системы, преследовало следующие цели:

- автоматизация работы отдела кадров;

- повышения производительности труда отдела кадров;

- уменьшения затрат на содержание отдела кадров.

2. Системный проект

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

Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.

На этом этапе определяются:

· архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;

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

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

· состав людей и работ, имеющих отношение к системе;

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

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

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

2.2 Описание данных

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

Личная карточка сотрудника

Код сотрудника ___________

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

Имя_____________________

Отчество_________________

Фамилия_________________

Должность_______________

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

Контактная информация

Код сотрудника ___________

Имя_____________________

Отчество_________________

Фамилия_________________

Должность________________

Адрес____________________

Домашний телефон________

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

Личная информация

Код сотрудника ___________

Имя_____________________

Отчество_________________

Фамилия_________________

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

Имя супруга______________

В карточке «образование» указываются: личный код сотрудника, фамилия, имя, отчество, наличие образования (высшее/среднее), номер аттестата, номер диплома. Все поля, кроме поля «№ диплома» заполняются обязательно. Поле «№ диплома» заполняется при наличии у сотрудника высшего образования. Дана форма выглядит следующим образом:

Образование

Код сотрудника ___________

Имя_____________________

Отчество_________________

Фамилия_________________

Образование______________

№ аттестата_______________

№ диплома_______________

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

Заработная плата

Код сотрудника ___________

Имя_____________________

Отчество_________________

Фамилия_________________

Зарплата_________________

Документ «рабочее время» является табелем учета рабочего времени сотрудников. Заполняется работником отдела кадров один раз в неделю. Здесь указываются: код сотрудника, фамилия, имя, отчество, неделя, количество отработанных часов в неделю. Поле «неделя» заполняется цифрами (1,2,3,4).

Рабочее время

Код сотрудника ___________

Имя_____________________

Отчество_________________

Фамилия_________________

Неделя___________________

Количество часов_________

2.3 Проектирование логической структуры базы данных методом нормальных форм

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

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

Кодом выведено три нормальные формы и предложен механизм, позволяющий любое отношение преобразовать к третей нормальной форме. Приведем наши отношения к третей нормальной форме.

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

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

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

2.4 Проектирование логической структуры базы данных методом «сущность-связь»

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

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

Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель "сущность--связь", предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена "сущность--связь", или "Entity Relationship", стала фактическим стандартом при инфологическом моделировании баз данных.

Модель «сущность-связь» называют также «ER-моделью» (essence-сущность, relation-связь).

Основными понятиями метода сущность-связь являются следующие:

* сущность,

* атрибут сущности,

* ключ сущности,

* связь между сущностями,

* степень связи,

* класс принадлежности экземпляров сущности,

* диаграммы ER-экземпляров,

* диаграммы ER-типа.

Сущность представляет собой объект, информация о котором хранится в БД. Экземпляры сущности отличаются друг от друга и однозначно идентифицируются. Названиями сущностей являются, как правило, существительные, например: ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА, ГРУППА.

Атрибут представляет собой свойство сущности. Это понятие аналогично понятию атрибута в отношении. Так, атрибутами сущности ПРЕПОДАВАТЕЛЬ может быть его Фамилия, Должность, Стаж (преподавательский) и т. д.

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

Связь двух или более сущностей - предполагает зависимость между атрибутами этих сущностей. Название связи обычно представляется глаголом. Примерами связей между сущностями являются следующие: ПРЕПОДАВАТЕЛЬ ВЕДЕТ ДИСЦИПЛИНУ (Иванов ВЕДЕТ «Базы данных»), ПРЕПОДАВАТЕЛЬ ПРЕПОДАЕТ В ГРУППЕ (Иванов ПРЕПОДАЕТ В 256 группе), ПРЕПОДАВАТЕЛЬ РАБОТАЕТ НА КАФЕДРЕ (Иванов РАБОТАЕТ-НА 25 кафедре).

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

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

* диаграммы ER-экземпляров,

* диаграммы ER-muna, или ER-диаграммы.

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

Класс принадлежности (КП) сущности может быть: обязательным и не-обязателъным.

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

Этапы проектирования. Процесс проектирования базы данных является итерационным - допускающим возврат к предыдущим этапам для пересмотра ранее принятых решений и включает следующие этапы:

1. Выделение сущностей и связей между ними.

2. Построение диаграмм ER-типа с учетом всех сущностей и их связей.

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

4. Добавление неключевых атрибутов в отношения.

5. Приведение предварительных отношений к нормальной форме Бойса - Кодда, например, с помощью метода нормальных форм.

6. Пересмотр ER-диаграмм в следующих случаях:

* некоторые отношения не приводятся к нормальной форме Бойса - Кодда;

* некоторым атрибутам не находится логически обоснованных мест в предварительных отношениях.

После преобразования ER-диаграмм осуществляется повторное выполнение предыдущих этапов проектирования (возврат к этапу 1).

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

2.5 Сравнительный анализ спроектированной базы данных и базы данных существующих информационных систем

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

Сравнение некоторых широко используемых в Web баз данных
Базы данных	Платформа	Рекомендуемое использование
Oracle	Windows NT и UNIX	Крупные предприятия
Sybase	Windows NT и UNIX	Крупные предприятия
Microsoft SQL	Windows NT	Крупные и средние предприятия
Microsoft Access	Windows NT	Личное использование, мелкие и средние предприятия

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

3. Технический проект

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

Результат - разработка:

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

· проектов заявок на разработку новых технических средств,

· документации специального математического и информационного обеспечения.

Все данные вносятся в единый документ.

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

Технический проект автоматизированной системы подробно описывает:

· рабочие места,

· выполняемые на них бизнес-операции,

· соответствующие им документы,

· структуры обрабатываемых баз данных,

· взаимосвязи данных

· алгоритмы их обработки.

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

При разработке технического проекта оформляются:

· Ведомость технического проекта. Общая информация по проекту.

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

· Описание систем классификации и кодирования.

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

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

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

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

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

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

· Задания на разработку строительных, электротехнических, санитарно-технических и других разделов проекта.

3.1 Выбор состава технических и программных средств

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



Функционирование комплекса технических средств подсистемы в целом, в том числе в пусковом и аварийном режимах, не предполагает наличия моментов отличных, от стандартного функционирования Web-сервера, сервера БД и Web-клиентов.

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

Структура КТС состоит из:

· сервера приложений;

· сервера баз данных;

· АРМ обслуживающего персонала;

· АРМ пользователей;

Сервера приложений

Сервер приложений обрабатывает запросы от пользователей по протоколу HTTP/HTTPS, а так же обращается к сервисам, предоставляемым сервером базы данных.

Сервера баз данных

На сервере базы данных расположена база данных.

АРМ обслуживающего персонала

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

АРМ пользователей

АРМ пользователей используются гражданами и организациями для доступа к сервисам пилота.

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

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

Основными средствами физического моделирования в БД являются:

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

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

3. язык описания данных.

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

- линейный список;

- цепной список;

- инвертированные файлы;

- индексные файлы.

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

Достоинства: по критерию «min-памяти» он наиболее экономичный.

Недостаток: по быстродействию проигрывает остальным способам.

Цепной список представляет собой файл, записи которого имеют ссылки на другие записи. Ссылками элементов являются указатели, которые встраиваются в записи как дополнительные поля. Поле, которое выделяется под указатель - называется адресом связи. Чтобы войти в список надо указать адрес начала списка (АНС).

3.3 Экспорт физической структуры в СУБД

Режим экспорта всей базы данных используется для экспорта всех объектов базы данных, за исключением объектов, которые обычно создаются и поддерживаются учетной записью SYS. Эту опцию могут применять только пользователи, которым назначена роль EXP_FULL_DATABASE. Здесь можно упомянуть несколько других интересных возможностей. По умолчанию Oracle выполняет полный экспорт при указании режима экспорта всей базы данных (INCTYPE= COMPLETE). Если указана опция INCTYPE= INCREMENTAL, Oracle будет экспортировать только таблицы, содержащие какие-либо изменившиеся строки, начиная с последнего полного экспорта любого типа. Если указана опция INCTYPE=CUMULATIVE, Oracle будет экспортировать только таблицы, содержащие какие-либо измененные строки, начиная с последнего полного или кумулятивного экспорта.

Типы экспорта:

· Полный экспорт

· Инкрементный экспорт

· Кумулятивный экспорт

Заключение

access база автоматизированный учет

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

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

Список использованной литературы

1. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. -- М.: Вильямс, 2000. -- 1120 с.

2. Хансен Г., Хансен Дж. Базы данных: разработка и управление. -- М.: БИНОМ, 1999. -- 704 с.

3. Дейт К. Дж. Введение в системы баз данных. -- К.; М.; СПб.: Издательский дом «Вильямс», 1999. -- 848 с.

4. Праг К. Н., Ирвин М. Р. Access 2000. Библия пользователя. -- М.: Вильямс, 2000. -- 1040 с.

5. Microsoft Access 2003. Русская версия. Шаг за шагом. - М.: ЭКОМ, 2006

6. Симонович С.В., Евсеев Г.А., Алексеев А.Г. Специальная информатика. Учебное пособие. - М.: АСТ-Пресс, 1998.- 480 с.

7. Гончаров А.Ю. - Access 2003. Самоучитель с примерами. www.natahaus.ru

Приложение

Размещено на Allbest.ru