Организация информационного обеспечения управления персоналом

Рисунок 3 – Таблица  «Отдел» в режиме конструктора

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

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

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

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

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

 

 

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

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

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

-   Исключить дублирование  информации в таблицах.

-   Обеспечить возможность изменений в структуре таблиц.

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

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

 

Ненормализованные данные

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

Первая нормальная форма

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

Вторая нормальная форма

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

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

 

 

Третья  нормальная форма

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

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

Четвёртая нормальна форма

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

Пятая нормальная форма и комбинированные  элементы 

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

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

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

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

 

 

            Для реализации базы данных «Отдел кадров фирмы» в СУБД MS Access первоначально требуется создать таблицы для соответствующих отношений, полученных в ходе процедуры нормализации на предыдущем этапе проектирования базы данных. В режиме конструктора было создано  четыре таблицы: совещание, отдел, сотрудники, оклад. Полям таблицы были заданы определённые форматы, что способствует контролю целостности данных. Далее в схеме данных было проведено связывание этих таблиц, схема данных представлена на рис. 2

 

Рисунок 2 – Схема данных базы данных «Отдел кадров фирмы»

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

     Создание таблицы в режиме конструктора.

     Для перехода в окно базы данных нажмите клавишу F11. Выберите Таблицы в списке Объекты и нажмите кнопку Создать на панели инструментов окна базы данных. Дважды щелкните строку Режим конструктора. Определите все нужные поля в таблице. Откройте таблицу в режиме конструктора.

 

 

Рисунок 3 – Создание таблицы в режиме конструктора

 

          Чтобы вставить в таблицу поле, щелкните строку, над которой его нужно поместить, и нажмите кнопку Добавить строки на панели инструментов.

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

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

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

 

 

 

Рисунок 4 – Таблица  «совещание»

 

 

 

 

Рисунок 5 – Таблица  «отдел»

Рисунок 6 – Таблица  «сотрудники»

Рисунок 7 – Таблица  «оклад»

Рисунок 4 – Таблицы базы данных «Отдел кадров фирмы»

 

         Следующим шагом реализации базы данных в MS Access явилось создание запросов, требуемых в техническом задании на курсовое проектирование. При создании запросов использовался язык SQL. Этот язык является декларативным: с его помощью можно указать результат, который требуется получить в результате запроса, написанного на SQL, но не указывается процедура достижения этого результата. SQL является общепризнанным стандартом и поддерживается большинством систем управления реляционных баз данных. Далее приводятся коды запросов к базе данных «Отдел кадров фирмы» на языке SQL.

        Запрос, используемый для  удаления из базы данных информации об уволенном сотруднике (удаление):

DELETE сотрудники.[ФИО Сотрудника]

FROM сотрудники

WHERE сотрудники.[ФИО Сотрудника]=[Кого  уволить?];

        Запрос, используемый для перевода  сотрудника из отдела в отдел  (обновление):

UPDATE отдел INNER JOIN сотрудники ON отдел.[Код  Отдела]=сотрудники.[Код Отдела] SET сотрудники.[Код  Отдела] = [Введите новый отдел]

WHERE сотрудники.[ФИО Сотрудника]=[Введите  ФИО];

      Запрос на получение сведений о сотруднике (общие данные о сотруднике):

SELECT сотрудники.[Табельный Номер], сотрудники.[ФИО Сотрудника], сотрудники.[Домашний  Адрес], сотрудники.[Номер Телефона], сотрудники.[Дата Приёма], сотрудники.Должность,  оклад.Оклад, отдел.[Название Отдела], отдел.[Начальник Отдела], отдел.Этаж, отдел.[Номер Кабинета]

FROM отдел INNER JOIN (оклад INNER JOIN сотрудники ON оклад.Должность=сотрудники.Должность) ON отдел.[Код Отдела]=сотрудники.[Код  Отдела]

WHERE сотрудники.[ФИО Сотрудника]=[Введите  ФИО сотрудника];

Рисунок 8 – Запрос на получение сведений о сотруднике

          Запрос, используемый для  получения сведений о номере телефона сотрудника (номер телефона):

SELECT сотрудники.[ФИО Сотрудника], сотрудники.[Номер  Телефона]

FROM сотрудники

WHERE сотрудники.[ФИО Сотрудника]=[Введите  ФИО сотрудника:];

          Запрос на получение сведений о кол-ве сотрудников в каждом отделе (количество сотрудников отделе):

SELECT отдел.[Название Отдела], Count(сотрудники.[ФИО  Сотрудника]) AS [Кол-во Сотрудников]

FROM отдел INNER JOIN сотрудники ON отдел.[Код  Отдела]=сотрудники.[Код Отдела]

GROUP BY отдел.[Название Отдела];

 Рисунок 9 – Запрос  на получение сведений о количестве  сотрудников в каждом отделе    

Запрос на получение сведений о фонде заработной платы (сумма):

SELECT отдел.[Название Отдела], Sum(оклад.Оклад) AS [фонд заработной платы]

FROM отдел INNER JOIN (оклад INNER JOIN сотрудники ON оклад.Должность=сотрудники.Должность) ON отдел.[Код Отдела]=сотрудники.[Код  Отдела]

GROUP BY отдел.[Название Отдела];

Рисунок 10 – Запрос на получение сведений о заработной плате

             

                Запрос, используемый для  упорядочивания сотрудников по ФИО (упорядочение по ФИО сотрудников):

SELECT сотрудники.*

FROM сотрудники

ORDER BY сотрудники.[ФИО Сотрудника];

Рисунок 11 – Запрос, используемый для упорядочивания сотрудников фирмы по ФИО

          Запрос, используемый для  упорядочивания сотрудников по отделам (упорядочивание по отделам):

SELECT сотрудники.*, отдел.[Название Отдела]

FROM отдел INNER JOIN сотрудники ON отдел.[Код  Отдела]=сотрудники.[Код Отдела]

ORDER BY отдел.[Название Отдела] DESC;