Курсовая работа
Проектирование
базы данных отдела кадров
Содержание
Введение
. Постановка задачи
. Системный проект
.1 Описание предметной области
.2 Описание данных
.3 Проектирование логической структуры базы данных методом нормальных форм
.4 Проектирование логической структуры базы данных методом сущность связь
.5 Сравнительный анализ спроектированной базы данных и базы данных существующих информационных систем
. Технический проект
.1 Выбор состава технических и программных средств
.2 Физическая структура базы данных
.3 Экспорт физической структуры в СУБД
Заключение
Список использованной литературы
Приложение
Введение
Базы данных - это совокупность структур, предназначенных для хранения больших объемов информации и программных модулей, осуществляющих управление данными, их выборку, сортировку и другие подобные действия. Информация базы данных хранится в одной или нескольких таблицах. Любая таблица с данными состоит из набора однотипных записей, расположенных друг за другом. Они представляют собой строки таблицы, которые можно добавлять, удалять или изменять. Каждая запись является набором именованных полей, или ячеек, которые могут хранить самую разнообразную информацию, начиная от даты рождения и заканчивая подробным описанием кулинарного рецепта. Однотипные поля разных записей образуют столбец таблицы.
Создав одну таблицу, вы уже получаете полноценную базу данных. Однако в реальной жизни структуры баз данных, а соответственно и способы их создания, намного сложнее.
Возникло большое число избыточной информации, в которой иногда трудно сориентироваться и выбрать нужные сведения.
Для решения подобных проблем применяются автоматизированные базы данных. Они стали неотъемлемой частью практически всех компьютерных систем - от отрасли до отдельного предприятия. За последние несколько лет вырос уровень потребительских качеств систем управления базами данных (СУБД): разнообразие поддерживаемых функций, удобный для пользователя интерфейс, сопряжение с программными продуктами, в частности с другими СУБД, возможности для работы в сети и т.д. СУБД позволяет сводить воедино информацию из самых разных источников (электронные таблицы, другие базы данных) и помогает быстро найти необходимую информацию, донести ее до окружающих с помощью отчетов, графиков или таблиц.
К настоящему времени накоплен значительный опыт проектирования БД, предназначенных для управления производством, это позволяет сделать процесс создания БД более эффективным.
Многие люди даже не догадываются, насколько сложен и трудоемок кадровый учет. Чаще всего выделяют 3 основные современные сложности:
. Четкое понимание и реализация стратегических и тактических целей своей фирмы. К сожалению, в сегодняшней практике это слабое место. Оторванность отделов кадров от постановки перспективных целей приводит к тому, что имеющийся кадровый потенциал зачастую не дает возможности реализовать новые идеи и технологии, а на его перестройку уходит слишком много времени, что особенно непозволительно в условиях рыночной экономики.
. Прогнозирование ситуации на рынке труда и в собственном коллективе для принятия упреждающих мер. Без серьезного изучения стоимости рабочей силы, спроса и предложения высококвалифицированных работников нужного профиля, изменений в мотивации труда и других факторов движения трудовых ресурсов можно быстро потерять уже имеющийся кадровый потенциал. А для его постоянного наращивания в борьбе с конкурентами необходимо еще иметь источники кадрового пополнения, знать положение в области обучения кадров, предвидеть неблагоприятные обстоятельства.
. Анализ имеющегося кадрового потенциала и
планирование его развития с учетом перспективы. Планирование развития кадров
вытекает из реализации указанных выше функций. Прежде всего, это планирование
естественного движения кадров выхода на пенсию, увольнения по болезни, в связи
с учебой, службой в армии и т.п. Это сделать несложно, но необходимо, чтобы
своевременно подготавливать равноценную замену. Сложнее другое - как усилить
потенциал коллектива, повысить его конкурентоспособность.
1. Постановка задачи
Для того чтобы создать базу необходимы документы и данные, проходящие через начальника отдела кадров. База данных должна иметь наглядный интерфейс, возможность поиска, добавления новых и редактирования уже имеющихся данных. Результатом работы является разработанная и запрограммированная база данных.
При использовании же старых методов хранения данных практически невозможно производить поиск по заданным критериям, а тем более сортировку данных (ввиду большого количества самих данных) и оперативно выдать результат. Так же необходимо держать довольно-таки большой штат служащих, которые занимались бы поиском нужной информации.
При старом способе хранения данных была бы проблема централизации данных и доступа к ним. Также, благодаря дружественному интерфейсу программы, повысится удобство работы и, соответственно, производительность труда оператора ЭВМ.
Таким образом, создание автоматизированной системы, преследовало следующие цели:
автоматизация работы отдела кадров;
повышения производительности труда отдела кадров;
уменьшения затрат на содержание отдела кадров.
2. Системный проект
Создание системного проекта (по-другому, модели требований к будущей системе) является первой фазой разработки собственно системы автоматизации (именно, фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются, так как если требования нигде не зафиксированы, то их вроде-бы и не существует. Системный проект строится на основе модели "как должно быть" и результатов обследования предприятия в части выявления требований к будущей системе.
Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.
На этом этапе определяются:
· архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;
· интерфейсы и распределение функций между человеком и системой;
· требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;
· состав людей и работ, имеющих отношение к системе;
· ограничения в процессе разработки
(директивные сроки завершения отдельных этапов, имеющиеся ресурсы,
организационные процедуры и мероприятия, обеспечивающие защиту информации).
2.1 Описание предметной области
В отделе кадров хранится, и обрабатывается информация обо всех сотрудниках организации.
Информация по каждому сотруднику заносится в
базу данных. При оформлении на работу каждый сотрудник получает свой
индивидуальный код. В базе данных регистрируется следующая информация: фамилия,
имя, отчество, дата рождения, место проживания, номер паспорта, информация об
образовании (включая номер аттестата и/или номер диплома), должность, размер
заработной платы, контактный телефон, имя супруга, количество отработанных
часов.
.2 Описание данных
При оформлении нового сотрудника в карточку "сотрудник" вносится следующая информация: фамилия, имя, отчество сотрудника, номер паспорта, должность. Все поля карточки являются обязательными к заполнению. Форма данного документа изображена ниже:
Личная карточка сотрудника
Код сотрудника ___________
Номер паспорта___________
Имя_____________________
Отчество_________________
Фамилия_________________
Должность_______________
В карточку "контактная информация" вносятся следующие данные: личный код сотрудника, фамилия, имя, отчество, адрес, домашний телефон. Поля код сотрудника, фамилия, имя, отчество и адрес являются обязательными.
Поле домашний телефон заполняется по желанию сотрудника. Документальное оформление карточки "контактна информация" представлено следующим образом:
Контактная информация
Код сотрудника ___________
Имя_____________________
Отчество_________________
Фамилия_________________
Должность________________
Адрес____________________
Домашний телефон________
В карточку "личная информация" вносятся следующие данные: личный код сотрудника, фамилия, имя, отчество, дата рождения, имя супруга. Все поля, кроме поля "имя супруга" являются обязательными к заполнению. Данная карточка имеет следующий вид:
Личная информация
Код сотрудника ___________
Отчество_________________
Фамилия_________________
Дата рождения____________
Имя супруга______________
В карточке "образование" указываются: личный код сотрудника, фамилия, имя, отчество, наличие образования (высшее/среднее), номер аттестата, номер диплома. Все поля, кроме поля "№ диплома" заполняются обязательно. Поле "№ диплома" заполняется при наличии у сотрудника высшего образования. Дана форма выглядит следующим образом:
Образование
Код сотрудника ___________
Имя_____________________
Отчество_________________
Фамилия_________________
Образование______________
№ аттестата_______________
№ диплома_______________
Карточка "заработная плата" заполняется сотрудником отдела кадров по следующим параметрам: код сотрудника, фамилия, имя, отчество, размер заработной платы (указывается цифрами) и имеет следующее документальное оформление:
Заработная плата
Код сотрудника ___________
Имя_____________________
Отчество_________________
Фамилия_________________
Зарплата_________________
Документ "рабочее время" является табелем учета рабочего времени сотрудников.
Заполняется работником отдела кадров один раз в неделю. Здесь указываются: код сотрудника, фамилия, имя, отчество, неделя, количество отработанных часов в неделю. Поле "неделя" заполняется цифрами (1, 2, 3, 4).
Рабочее время
Код сотрудника ___________
Имя_____________________
Отчество_________________
Фамилия_________________
Неделя___________________
Количество часов_________
2.3 Проектирование логической структуры базы
данных методом нормальных форм
Нормализация - разбиение таблицы на две или более, обладающие лучшими свойствами включения, изменения или удаления данных. Окончательная цель нормализации сводится к получению такого проекта БД, в котором каждый факт появляется лишь в одном месте, то есть, исключена избыточность информации.
Нормализация отношений - формальный аппарат ограничений, на формирование отношений которого позволяет устранить дублирование, обеспечить непротиворечивость данных хранимых в базе, уменьшить трудозатраты на ведение БД.
Кодом выведено три нормальные формы и предложен механизм, позволяющий любое отношение преобразовать к третей нормальной форме. Приведем наши отношения к третей нормальной форме.
Первая НФ: Отношение называется нормализованным или приведенным к первой нормальной форме тогда и только тогда, когда все его атрибуты простые (неделимые). Таблица находится в первой нормальной форме тогда и только тогда, когда ни одна из ее строк не содержит в любом ее поле более одного значения, и не одно из ее ключевых полей не пусто. Для того чтобы привести наши отношения к первой нормальной форме надо сущность ФИО разбить на три отдельные (Фамилия, Имя, Отчество). Так же следует вынести в отдельную таблицу структурное подразделение, должности и наименование фирмы, чтобы не допустить избыточности данных. В отдельную таблицу выносятся приказы по личному составу и производственные приказы, так как нумерация у приказов общая. Атрибуты место проживания по паспорту и фактическое место проживания не требуют разбиения так как используются один раз.
Вторая НФ: Таблица находится во второй нормальной форме, если она удовлетворяет определению первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Для того чтобы наши отношения привести во вторую нормальную форму, надо вынести всех начальников отдела в отдельную таблицу.
Третья НФ: Таблица находится в третей нормальной
форме, если она удовлетворяет определению второй нормальной формы и ни одно из
ее не ключевых полей не зависит функционально от любого другого не ключевого
поля. Отношения, представленные в данной БД приведены к третей нормальной
форме.
.4 Проектирование логической структуры базы
данных методом сущность связь
Инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет "читаться" не только специалистами по базам данных.
Инфологическое проектирование, прежде всего, связано с попыткой представления семантики предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области.
Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель "сущность-связь", предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена "сущность-связь", или "Entity Relationship", стала фактическим стандартом при инфологическом моделировании баз данных.
Модель "сущность-связь" называют также "ER-моделью" (essence-сущность, relation-связь).
Основными понятиями метода сущность-связь являются следующие:
• сущность,
• атрибут сущности,
• ключ сущности,
• связь между сущностями,
• степень связи,
• класс принадлежности экземпляров сущности,
• диаграммы ER-экземпляров,
• диаграммы ER-типа.
Сущность представляет собой объект, информация о котором хранится в БД. Экземпляры сущности отличаются друг от друга и однозначно идентифицируются. Названиями сущностей являются, как правило, существительные, например: ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА, ГРУППА.
Атрибут представляет собой свойство сущности. Это понятие аналогично понятию атрибута в отношении. Так, атрибутами сущности ПРЕПОДАВАТЕЛЬ может быть его Фамилия, Должность, Стаж (преподавательский) и т. д.
Ключ сущности - атрибут или набор атрибутов, используемый для идентификации экземпляра сущности. Как видно из определения, понятие ключа-сущности аналогично понятию ключа-отношения.
Связь двух или более сущностей - предполагает зависимость между атрибутами этих сущностей. Название связи обычно представляется глаголом. Примерами связей между сущностями являются следующие: ПРЕПОДАВАТЕЛЬ ВЕДЕТ ДИСЦИПЛИНУ (Иванов ВЕДЕТ "Базы данных"), ПРЕПОДАВАТЕЛЬ ПРЕПОДАЕТ В ГРУППЕ (Иванов ПРЕПОДАЕТ В 256 группе), ПРЕПОДАВАТЕЛЬ РАБОТАЕТ-НА КАФЕДРЕ (Иванов РАБОТАЕТ-НА 25 кафедре).
Приведенные определения сущности и связи не полностью формализованы, но приемлемы для практики. Следует иметь в виду, что в результате проектирования могут быть получены несколько вариантов одной БД. Так, два разных проектировщика, рассматривая одну и ту же проблему с разных точек зрения, могут получить различные наборы сущностей и связей. При этом оба варианта могут быть рабочими, а выбор лучшего из них будет результатом личных предпочтений.