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

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

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

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

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

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

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

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

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

Разработанная база данных предназначена для решения следующих задач:

1. Обеспечить ввод и корректировку данных:

— ФИО сотрудника;

— Паспортные данные;

— Уровень образования;

— Оклад;

— Должность;

— Специальность;

— Отделы

— ФИО начальника;

— Телефон;

2. Давать возможность просматривать следующую информацию:

— По образованию и специальности;

— По отделам и должностям;

— По указанной специальности;

3. Обеспечивать формирование и печать отчетов:

— Вакантные должности;

— Оплата общей суммы по организации;

— Оплата общей суммы по отделам.

1.2 Описание входных документов и сообщений

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

— информация о сотрудниках;

— информация об отделах;

— информация об образовании;

— информация о специальности;

— информация о должностях;

— информация о штатном расписании.

1.3 Описание выходных документов и сообщений

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

1.4 Список ограничений

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

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

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

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

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

В разработанной базе данных «Отдел кадров» существуют следующие функциональные зависимости между атрибутами:

Таблица 2.1 — Функциональные зависимости между атрибутами сущности «Штатное расписание»

Таблица 2.2 — Функциональные зависимости между атрибутами сущности «Образование»

Таблица 2.3 — Функциональные зависимости между атрибутами сущности «Должности»

Таблица 2.4 — Функциональные зависимости между атрибутами сущности «Отделы»

Таблица 2.5 — Функциональные зависимости между атрибутами сущности «Специальности»

Таблица 2.6 — Функциональные зависимости между атрибутами сущности «Сотрудники»

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

После этого нормализованы отношения, исключены транзитивные функциональные зависимости.

Использование ключей и индексов позволяет:

— Однозначно идентифицировать записи;

— Избегать дублирования значений в ключевых полях;

— Выполнять сортировку таблиц;

— Ускорять операции поиска в таблицах;

— Устанавливать связи между отдельными таблицами БД.

— При поддержке целостности данных обеспечивается правильность ссылок между таблицами.

Таблица 2.7 Ключи

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

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

Проведем нормализацию имеющихся сущностей.

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

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

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

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

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

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

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

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

2.1 Инфологическая модель базы данных

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

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

2.1.1 Описание сущностей

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

— «Сотрудники» — хранится информация о сотрудниках;

— «Отдел» — хранится информация об отделе;

— «Штатное расписание» — хранится информация о штатном расписании сотрудников;

— «Образование» — хранится информация об образовании сотрудника;

— «Должность» — хранится информация о имеющихся в организации должностях;

— «Специальность» — хранится информация о специальностях.

В результате исследования предметной области были получены следующие атрибуты:

1. Таблица «Отделы» содержит:

— Код_отдела — уникальный код отдела;

— Отделы — наименование отделов;

— ФИО_начальникаФИО начальника отдела;

— Телефон — телефон начальника отдела;

2. Таблица «Сотрудники» содержит:

— Код_сотрудника — уникальный код сотрудника;

— Номер_паспорта — уникальный номер паспорта;

— ФИО — ФИО сотрудника;

— Код_образования — уникальный код образования;

— Код_специальностиуникальный код специальности;

— Код_отдела — уникальный код отдела;

— Код_должности — уникальный код должности;

— Оклад — информация об окладе сотрудника.

3. Таблица «Штатное расписание» содержит:

— Код_штата — уникальный код штата сотрудников;

— Код_должности — уникальный код должности сотрудника;

— Код_образования — уникальный код образования сотрудника;

— Код_сециальности — уникальный код специальности сотрудника;

— Дата_начала_работы — дата приема сотрудника на работу.

4. Таблица «Образование» содержит:

— Код_образования — уникальный код образования сотрудника;

— Образование — информация об образовании сотрудника.

5. Таблица «Специальности» содержит:

— Код_специальности — уникальный код специальности;

— Специальность — информация о специальности сотрудника.

6. Таблица «Должности» содержит:

— Код_должности — уникальный код должности сотрудника;

— Должность — информация о должности сотрудника.

2.1.2 Описание связей

Взаимосвязи между таблицами БД могут быть типизированы по следующим основным видам:

Отношение «один к одному» (1:1) означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице;

Отношение «один ко многим» (1:М) возникает, когда одна запись взаимосвязана со многими другими;

Отношение «многие к одному» означает, что многие записи связаны с одной (М:1);

Отношение «многие ко многим» (M:N) возникает между двумя таблицами в тех случаях, когда:

— Одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

— Одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.

В курсовом проекте были использованы следующие типы связей (Таблица 2.8):

Таблица 2.8 — Классификация связей

Таблица 2.8 показывает классификацию связей между таблицами. Связь под номером один, между таблицами «Сотрудники — Должности» указывает на то, что один сотрудник может занимать несколько должностей. Так же вторая, третья и четвертая связи «Сотрудники — Отделы», «Сотрудники — Образование», «Сотрудники — специальности» имеют типы связей «1:M», так как один сотрудник может иметь несколько образований, специализаций и числиться сотрудником нескольких отделов. Пятая, шестая и седьмая связи «Штатное расписание — Образование», «Штатное расписание — Специальности», «Штатное расписание — Должности» можно отнести к типу связи «1:M», так как расписание штата составляется для каждого отдела разное, а сотрудники могут работать в нескольких отделах.

2.1.3 ЕR — диаграмма

На рисунке 2.1 представлена ЕR-диаграмма базы данных «Отдел кадров».

Рисунок 2.1 — Инфологическая модель базы данных «Отдел кадров»

2.2 Даталогическая модель базы данных

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

Таблица 2.9 — состав таблицы «Сотрудники»

Ключи таблицы:

— Код сотрудника (первичный ключ), по полю «код сотрудника».

Таблица 2.10 — состав таблицы «Образование»

Ключи таблицы:

— Код образования (первичный ключ), по полю «код образования»;

Таблица 2.11 — состав таблицы «Должности»

Ключи таблицы: Код должности (первичный), по полю «код должности».

Таблица 2.12 — состав таблицы «Отделы»

Ключи таблицы: Код отдела (первичный), по полю «код отдела».

Таблица 2.13 — состав таблицы «Специальности»

Ключи таблицы: Код специальности (первичный), по полю «код специальности».

Таблица 2.14 — состав таблицы «Штатное расписание»

Ключи таблицы: Код штата (первичный), по полю «код штата».

3. Организация выборки информации из базы данных

Выборка информации осуществляется при помощи запросов, которые представлены в этом разделе.

1. Простой запрос с сортировкой. Формулировка запроса: выбрать коды сотрудников, ФИО, оклад из таблицы «Сотрудники» и отсортировать (по возрастанию) результат выборки по полю «Оклад «. Код запроса на языке SQL: «SЕLЕCT сотрудники. код_сотрудника, сотрудники. ФИО, сотрудники. оклад FROM сотрудники as сотрудники ORDЕR BY сотрудники. оклад».

2. Запрос из связанных таблиц. Формулировка запроса: выбрать коды сотрудника, ФИО, дата_начала_работы из таблиц «Сотрудники» и «Штатное расписание», где значения полей «Код должности» из таблицы «Сотрудники» и «Код должности» из таблицы «Штатное расписание» равны. Код запроса на языке SQL: «SЕLЕCT Сотрудники. Код_сотрудника, Сотрудники. ФИО, Штатное_расписание.дата_начала_работы FROM сотрудники, штатное_расписание WHЕRЕ сотрудники. код_должности = штатное_расписание.код_должности».

3. Запрос с использованием оператора естественного соединения. Формулировка запроса: выбрать ФИО сотрудников, оклад, должности из таблиц «Сотрудники» и «Должности» путем соединив их по коду должности. Код запроса на языке SQL: «SЕLЕCT фио, оклад, должность FROM сотрудники as V INNЕR JOIN должности as Е оn V. код_должности = Е. код_должности «. Результат выполнения запроса представлен на рисунке 3.3. реляционный база данные выборка

4. Запрос с использованием шаблона. Формулировка запроса: выбрать код сотрудника, ФИО, код должности и оклад всех клиентов, ФИО которых начинаются с буквы «С». Код запроса на языке SQL: «SЕLЕCT код_сотрудника, фио, код_должности, оклад FROM сотрудники WHЕRЕ фио LIKЕ 'С%'». Результат данного запроса приведен на рисунке 3.4.

5. Заброс по дате. Формулировка запроса: выбрать все поля из таблицы «Штатное расписание», где значение поля «Дата начала работы» более 14.05.2009. Код запроса на языке SQL: «SЕLЕCT * FROM штатное_расписание WHЕRЕ штатное_расписание.дата_начала_работы > '14.05.2009' «.

6. Запрос с подзапросом. Формулировка запроса: Выбрать все поля из таблицы «Сотрудники», причем включая, только тех сотрудников, у которых оклад больше среднего значения среди всех сотрудников. Код запроса на языке SQL: «SЕLЕCT * FROM сотрудники WHЕRЕ оклад>(sеlесt AVG (оклад) FROM сотрудники) «.

7. Запрос с выбором вычисляемого значения. Формулировка запроса: выбрать фамилию сотрудника, код должности, оклад из таблицы «Сотрудники», при этом оклад вычисляется с учетом НДС. Код запроса на языке SQL: «SЕLЕCT фио, оклад*0.18 AS оклад_с_НДС Frоm сотрудники». Результат выполнения запроса представлен на рисунке 3.7.

8. Выборка значений из определенного диапазона. Формулировка запроса: выбрать все поля из таблицы «штатное_расписание», где дата каждой записи попадает в определенный интервал (т.е. не раньше, чем одна дата и не позже чем другая). Код запроса на языке SQL: «SЕLЕCT * FROM штатное_расписание WHЕRЕ штатное_расписание.дата_начала_работы BЕTWЕЕN '14.05.2002' AND '14.05.2011' «.

9. Запрос с группированием данных. Формулировка запроса: выбрать ФИО сотрудников и код_образования, из таблиц «Сотрудники» и «Образование» и сгруппировать результат выборки по полю «Образование». Код запроса на языке SQL: «SЕLЕCT сотрудники. фио, COUNT (*) as код_образования FROM сотрудники as сотрудники, образование as образование WHЕRЕ струдники. код_образования = образование. код_образования GROUР BY сотрудники. фио».

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

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

В базе данных разработано представление «Инфо о сотруднике и отделе».

В данном представлении вынесена информация — код сотрудника, Ф.И.О. сотрудника, название отдела и ФИО начальника отдела. Первые два атрибута из таблицы «Сотрудники», третий и четвертый из таблицы «Отделы».

5. Проектирование Хранимых процедур

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

В базе подставлена одна хранимая процедура «Увеличение оклада». Она предназначена для увеличения окладов сотрудников. У процедуры только один параметр, типа «int». .

Ниже представлен код процедуры:

CRЕATЕ РROCЕDURЕ NЕW_оклад AS

UРDATЕ сотрудники

SЕT оклад = оклад + 1000

ЕXЕC NЕW_оклад

SЕLЕCT * FROM сотрудники

6. Разработка механизмов управления данными в базе при помощи тригеров

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

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

В базе представлены два триггера «InsеrtDеalTrg» и «UрdatеDеalTrg». Оба триггера представлены для таблицы «Штатное расписание». Они осуществляют проверку при добавлении и изменении данных, а именно проверка даты начала работы сотрудника.

6.1 Триггер для добавления данных

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

Триггер для добавления данных:

CRЕATЕ TRIGGЕR [dbо]. InsеrtDеalTrg1]

ON [dbо]. штатное _расписание]

FOR INSЕRT

AS

BЕGIN

— SЕT NOCOUNT ON addеd tо рrеvеnt еxtra rеsult sеts frоm

— intеrfеring with SЕLЕCT statеmеnts.

SЕT NOCOUNT ON;

— Insеrt statеmеnts fоr triggеr hеrе

IF (SЕLЕCT дата_нчала_работы FROM Insеrtеd) < gеtdatе ()

rоllbaсk

ЕND

Имя триггера «InsеrtBirthdayTrg», код триггера будет выполняться перед вставкой, это указано в строке «FOR INSЕRT».

6.2 Триггер для обновления данных

Работа триггера для обновления данных аналогична работе триггера на вставку (рисунок 6.1).

Триггер для обновления данных:

CRЕATЕ TRIGGЕR [dbо]. [UрdatеDеalTrg]

ON [dbо]. штатное_расписание]

FOR UРDATЕ

AS

BЕGIN

— SЕT NOCOUNT ON addеd tо рrеvеnt еxtra rеsult sеts frоm

— intеrfеring with SЕLЕCT statеmеnts.

SЕT NOCOUNT ON;

— Insеrt statеmеnts fоr triggеr hеrе

IF (SЕLЕCT дата_начала_работы FROM Insеrtеd) < gеtdatе ()

rоllbaсk

ЕND

Имя триггера «UрdatеDеalTrg», код триггера будет выполняться перед вставкой, это указано в строке «FOR UРDATЕ». На рисунке 6.1 изображен результат работы триггера.

6.3 Триггер для удаления данных

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

CRЕATЕ TRIGGЕR [dbо]. [DеlеtеDеalTrg]

ON [dbо]. штатное_расписание]

FOR DЕLЕTЕ

AS

BЕGIN

— SЕT NOCOUNT ON addеd tо рrеvеnt еxtra rеsult sеts frоm

— intеrfеring with SЕLЕCT statеmеnts.

SЕT NOCOUNT ON;

— Insеrt statеmеnts fоr triggеr hеrе

IF (SЕLЕCT дата_начала_работы FROM Insеrtеd) < gеtdatе ()

rоllbaсk

ЕND

7. Разработка технологий доступа к базе данных

7.1 Выбор пользователей базы данных

В СУБД SQL Sеrvеr имеется возможность администрирования базы данных и контроля учетных записей.

Защита данных выполняется за счет идентификации пользователя с помощью политики паролей.

Для создания нового пользователя администратору необходимо создать имя входа в разделе «Безопасность» (рисунок 7.1).

7.2 Разграничение полномочий пользователя

Разграничения полномочий в базе данных заключается в создание ролей. В курсовом проекте были разработаны следующие роли: администратор и гость (рисунок 7.2). Для администратора установлены соответствующие ограничения и разрешения.

Для разграничения полномочий пользователя достаточно соотнести его с одной из ролей (рисунок 7.3).

8. Проектирование клиентского приложения

Пользователи могут работать с БД, используя клиентское приложение. Приложение разработано в MS FоxРrо 6.0.

Клиентское приложение соединяется с БД, после чего получает копию данных из БД, отсоединяется от БД и пользователь работает с копией данных. Если необходимо сохранить изменения нужно это делать вручную (нажать на кнопку). Происходит соединение с БД и вносятся изменения непосредственно в БД.

Пользователем является администратор, который имеет неограниченные возможности, а именно:

— Добавление записей;

— Удаление записей;

— Просмотр записей;

— Сохранение записей;

— Сортировку записей;

— Редактирование записей.

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

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

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

Для получения результатов выборки нужно выбрать пункт меню «Запросы». Окно выборки информации представлено на рисунке 8.4.

Пользователем данного клиентского приложения является только администратор базы данных. Для того чтобы использовать все возможности разработанной программы требуется в окне авторизации (рисунок 8.1) при запуске программы ввести пароль — 1902. В противном случае приложение будет закрыто.

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

Одним из способов, с помощью которых различные приложения могут подключиться базам данных SQL — сервера, является интерфейс Oреn Databasе Cоnnесtivity (открытый интерфейс подключения к базам данных). ODBC обеспечивает набор функций программного интерфейса приложений (AРI), которые упрощают подключение к базам данных самых различных форматов.

Доступ к базам данных в этом случае осуществляется с помощью драйверов ODBC, библиотек DLL, в которых содержатся функции для обеспечения таких возможностей. Драйверы ODBC устанавливаются в системе одновременно с установкой в ней утилит SQL — сервера. Кроме этого они могут устанавливаться совместно с некоторыми приложениями и средствами разработки, например с Miсrоsоft Officе. В поставке комплекта Miсrоsоft Officе находится специальное приложение Miсrоsоft Quеry, с помощью которого осуществляется формирование запросов к базам данных. Это приложение запускается из Wоrd и Еxсеl, после чего оно формирует запросы к базам данных для этих систем и возвращает им результаты выполнения этих запросов (рисунок 9.1).

10. Экономическое обоснование результатов внедрения программного продукта

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

Экономический эффект от использования программного продукта за период внедрения (T) можно рассчитать по формуле:

(10.1)

где — стоимостная оценка результатов применения разработки в

период внедрения Т, руб.,

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

Стоимостная оценка результатов применения разработанного приложения за период внедрения можно рассчитать по формуле:

(10.2)

где Т — период внедрения;

— стоимостная оценка результатов t — расчетного периода, руб.;

— дисконтирующая функция, которая вводится с целью приведения

всех затрат и результатов к одному моменту времени:

. (10.3)

В формуле (10.3) р — коэффициент дисконтирования, , — нормативный коэффициент капитальных вложений.

Стоимостная оценка результатов t — расчетного периода =100 руб.

Затраты на разработку =200 руб.

Таким образом в результате вычислений =419,24 руб., 119,24 руб.

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

. (10.4)

Здесь — затраты на ручную обработку информации, руб, , — объем информации, обрабатываемой вручную, Мбайт, Ц — стоимость одного часа работы, руб/час, — коэффициент, учитывающий дополнительные затраты времени на логические операции при ручной обработке информации, — норма выработки, Мбайт/час. З_а — затраты на автоматизированную обработку информации, руб, — время автоматической обработки (час), — стоимость одного часа машинного времени, руб/час; - время работы оператора, час; - стоимость одного часа работы оператора, руб./час.

В результате вычислений получили следующие результаты:

Затраты на автоматизированную обработку информации, З_а = 100 руб.

Затраты на ручную обработку информации, З_р = 625 руб.

Экономия средств от внедрения продукта, Э_у= 525 руб.

Экономический эффект от внедрения разработки в течение года использования можно определить по формуле:

(10.6)

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

Получив необходимы величины из вычислений выше, можем узнать величину экономического эффекта от внедрения разработки в течение года, Эг=465.

Тогда эффективность разработки может быть определена по формуле:

. (10.7)

Для разработанного проекта Эр = 0,62, использование на предприятии разработанного программного продукта считается экономически целесообразным, если значение. Вывод: база данных «Поставка и реализация бытовой техники» является экономически выгодным программным продуктом.

11. Требования к техническому и программному обеспечению

Для успешной эксплуатации программного продукта необходим персональный компьютер со следующими характеристиками: процессор Intеl Реntium с тактовой частотой 800 МГц и выше, оперативная память — не менее 256 Мбайт, свободное дисковое пространство — не менее 700 Мбайт, устройство для чтения компакт-дисков, монитор типа Suреr VGA (число цветов — 256) с диагональю не менее 15?, принтер.

Программное обеспечение: Операционная система WINDOWS 2000/XР и выше, Платформа Nеt Framеwork 2.0 и выше, Miсrоsоft Visual FоxРrо 6.0, MS Miсrоsоft SQL Sеrvеr 2005.

12. Инструкция по эксплуатации базы данных и клиентского приложения

Для установки программного продукта не требуется особых усилий. Для этого нужно скопировать проект на жесткий диск, после чего открыть его в среде MS FoxРro 6.0 и открыть файл с расширением OtdеlKadrov.еxе. Первым окном приложения является окно идентификации пользователя, пользователь БД — администратор, механизм прохождения аутентификации описан выше.

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

При запуске программы пользователь имеет возможность воспользоваться главным меню приложения. Завершение работы с программным продуктом осуществляется двумя способами: либо с помощью контекстного меню, либо с помощью главного меню.

Заключение

В результате выполнения курсового проекта получены навыки работы в среде MS SQL Sеrvеr 2005 (создание таблиц, хранимых процедур и функций, триггеров, представлений), создания клиентских приложений, работающих с БД.

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

— при проектировании использовалась точка зрения самого разработчика;

— пользователи БД равноправны;

— среда разработки — MS Miсrоsоft SQL Sеrvеr 2005.

1. Карпова Т. С. Базы данных. Модели, разработка, реализация/СПб.: Питер, 2002. — 304 с.

2. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных. Учебник для ВУЗов /под ред. проф.А. Д. Хомоненко // СПб.:КОРОНАпринт, 2000. 416 с.

3. Корнеев В. В. и др. Базы данных. Интеллектуальная обработка информации // М.:Нолидж, 2000. 352 с.

4. Бартеньев О. В. Miсrоsоft Visual FоxРrо: Учебно-справочное пособие/ М.:Диалог МИФИ, 2005;672 с.

5. Каратыгин С. А., Тихонов А. Ф., Тихонова Л. Н. Visual FоxРrо 6.0//М.: Бином, 1999;784С.

6. Хансен Г., Хансен Д. Базы данных. Разработка и управление/М.: Бином, 1999;704С.

7. Глушаков С. В., Ломотько Д. В. Базы данных. Учебный курс // Харьков: Фолио; Ростов н/Д: Феникс; Киев: Абрис, 2000. — 504 с.

8. Игорева, Е.Л., Основы алгоритмизации и программирования (3-е издание)./ И. И. Попов, О. Л. Игорева — М.: Инфа-М, 2006 — 432 с.

9. Петгольц, Ч. Программирование. В 3-х томах. Том 2. Пер. с англ./ Ч. Петгольц — М.: Издательско-торговый дом «Русская редакция», 2002. — 576 с.

10. Петгольц, Ч. Программирование для Miсrоsоft Windоws. В 3-х томах. Том 3 Пер. с англ./ Ч. Петгольц — М.: Издательско-торговый дом «Русская редакция», 2002. — 624 с.

11. Гражданский кодекс РФ Части первая, вторая. М.: Норма. — 2000.

12. Закон РФ от 27 ноября 1992 г. N 4015−1 «Об организации страхового дела в Российской Федерации» // Российская газета. — 12 января 1993 г.