1 ВВЕДЕНИЕ


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

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

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


2 ПРОЕКТИРОВАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ БАЗЫ  ДАННЫХ

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

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

представляем каждую связь вида "M
-
M" или "1 - M" и т.д. между сущностями, как таблицу;

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

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

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

Процесс построения концептуальной модели базы данных "Отдел кадров фирмы" изображен на рис. 1.


Рисунок 1 - Модель «Сущность-связь» базы данных «Отдел кадров фирмы»
В результате получаем:

           Каждая таблица состоит из однотипных строк и имеет уникальное имя.

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

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

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

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

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


3 ПРОЕКТИРОВАНИЕ ЛОГИЧЕСКОЙ МОДЕЛИ БАЗЫ ДАННЫХ

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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

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

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


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

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

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

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

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


4 ТИПЫ ДАННЫХ

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

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

Числовой – тип данных для хранения действительных чисел.

Поле Мемо – специальный тип данных для хранения больших объемов текста (до 65 535 символов). Физически текст не хранится в поле. Он храниться в другом месте базы данных, а в поле храниться указатель на него, но для пользователя такое разделение заметно не всегда.

Дата/время – тип данных для хранения календарных дат и текущего времени.

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

Счетчик – специальный тип данных для уникальных (не повторяющихся в поле) натуральных чисел с автоматическим наращиванием. Естественное использование – для порядковой нумерации записей.

Логический - тип для хранения логических данных (могут принимать только два значения, например Да или Нет).

Гиперссылка – специальное поле для хранения адресов URL Web-объектов Интернета. При щелчке на ссылке автоматически происходит запуск броузера и воспроизведение объекта в его окне.

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

        В нашем случае применяются следующие типы данных (таблица 1):




Таблица 1 – Типы данных базы данных «Отдел кадров фирмы»


5 РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ В СУБД
MS
Access

            Для реализации базы данных «Отдел кадров фирмы» в СУБД MS

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


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

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

Access, где в качестве источников данных выбирались соответствующие таблицы.

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

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

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

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

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

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





         Рисунок 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 сотрудники.[ФИО Сотрудника]=[Введите ФИО сотрудника];

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

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

FROM сотрудники

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

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

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

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

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

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

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

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

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

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

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

FROM сотрудники

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

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

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

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

ORDER BY отдел.[Название Отдела] DESC;
             Запрос на поиск сотрудников, работающих на одном этаже (этаж):

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

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

WHERE отдел.Этаж Like [введите этаж];

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

           Для просмотра результатов созданных  запросов созданы формы (кроме запроса на удаление и на обновление).

Форму можно создать тремя различными способами:

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

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

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

 


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


6 ЗАКЛЮЧЕНИЕ

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

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

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

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


7 СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1.     Литвинская О.С.Проектирование базы данных в среде Microsoft Access . – Пенза: Издательство Пенз. гос. технол. акад., 2004.

2.     Диго С.М. Базы данных: проектирование и использование. – М.: Финансы и статистика, 2005.

3.     Робинсон С. MicrosoftAccess 2000 учебный курс. - СПб.: Питер, 2000.