Проектирование сетевой базы данных "Страховая компания"

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

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

Министерство образования и науки Российской Федерации

Северо-Кавказский государственный технический университет

Кафедра информационных систем и технологий

ПРОЕКТИРОВАНИЕ СЕТЕВОЙ БАЗЫ ДАННЫХ

«СТРАХОВАЯ КОМПАНИЯ»

Пояснительная записка к курсовому проекту

По дисциплине «Программирование в компьютерных сетях»

Специальность 071900 (230201) «Информационные системы и технологии»

Группа ИС - 071

Студент Щелкунова Д.В

Руководитель Крахоткина Е.В

Ставрополь 2011г.

ВВЕДЕНИЕ

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

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

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

База данных, описанная в этой пояснительной записке, разработана для предприятия «МАКС». Предметная область - страхование. Перед разработкой были поставлены следующие задачи: получить возможность просматривать, редактировать, добавлять данные, получать результаты запросов. Так же необходимо обеспечить удобную работу для персонала организации. Основное назначение спроектированной базы данных - представление, а так же модификация информации о клиентах, агентах, видах страхования, страховых случаях и о заключенных договорах. Следует отметить что:

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

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

- среда разработки - MS Microsoft SQL Server 2005.

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

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

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

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

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

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

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

- Таблица «Агент»;

- Таблица «Клиент»;

- Таблица «Вид страхования»;

- Таблица «Страховой случай»;

- Таблица «Договор».

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

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

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

- Закрытый доступ: только для сотрудников пункта проката.

- Просмотр интересующей информации в специальных формах.

- Изменение информации, добавление новой.

- Поиск информации по заданным критериям.

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

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

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

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

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

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

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

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

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

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

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

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

- Сущность «Агент» (код страхующего сотрудника и контактная информация);

- Сущность «Вид страхования» (перечень наименований, стоимостей услуг в год);

- Сущность «Страховой случай» (информация о видах страховых случаев);

- Сущность «Договор» (информация о заключенных сделках).

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

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

1. Сущность «Клиент»:

- id клиента;

- Наименование;

- Адрес;

- Телефон;

- ИНН.

2. Сущность «Агент»:

- id агента;

- id вида страхования;

- ФИО;

- Дата приема на работу;

- Адрес;

- Серия/номер паспорта.

3. Сущность «Вид страхования»:

- id вида страхования;

- Наименование;

4. Сущность «Страховой случай»:

- id страхового случая;

- id вида страхования;

- Наименование;

- Стоимость в год.

5. Сущность «Договор»:

- id договора;

- id агента;

- id клиента;

- id страхового случая;

- Дата заключения;

- Срок (лет).

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

Между сущностями спроектированной БД можно установить пять связей типа «Один-ко-многим».

Таблица 2.1 - Классификация связей в БД «Страховая компания»

№ связи	Родительская таблица	Дочерняя таблица	Тип связи
1	Клиент	Договор	1:М
2	Агент	Договор	1:М
3	Вид страхования	Агент	1:М
4	Вид страхования	Страховой случай	1:М
5	Страховой случай	Договор	1:М

Идея реализации данных связей заключается в следующем. В таблице «Клиент» есть ключевое поле (id_клиента), которое в данной таблице является первичным ключом. Этой записи может соответствовать много записей в таблице «Договор», в которой так же есть первичный ключ (id_договора) и внешний ключ (id_клиента), через который будет осуществляться взаимосвязь между таблицами. Таким образом, один клиент может заключить много договоров. По такому же принципу основаны связи и других таблиц.

Первичными ключами в спроектированной БД будут являться:

- id клиента (сущность «Клиент»);

- id агента (сущность «Агент»);

- id договора (сущность «Договор»);

- id вида страхования (сущность «Вид страхования»);

- id страхового случая (сущность «Страховой случай»)

2.1.3 ER-диаграмма

Модель “сущность - связь” (МСС) (entity-relation diagram) является неформальной моделью предметной области и используется на этапе инфологического проектирования БД. Моделируются объекты предметной области и их взаимоотношения. В данном курсовом проекте представлена модель «сущность - связь» для сетевой базы данных «Страховая компания».

Рисунок 2.1 - ER-диаграмма для базы данных «Страховая компания»

2.2 Даталогическая модель

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

Таблица 2.2 - состав таблицы «Агент»

Наименование атрибутов	Тип полей	NULL
id_агента Ф.И.О. Дата_приема_на_работу id_вида_страхования Серия/номер_паспорта Адрес	int nchar(50) Date int int nchar(30)	Нет Нет Нет Нет Нет Нет

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

- id агента - первичный ключ;

- id вида страхования - внешний ключ.

Таблица 2.3 - состав таблицы «Договор»

Наименование атрибутов	Тип полей	NULL
id_договора id_агента id_клиента id страхового случая Дата_заключения Срок_(лет)	int int int int Date int	Нет Нет Нет Нет Нет Нет

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

- id договора - первичный ключ;

- id агента - внешний ключ;

- id клиента - внешний ключ;

- id страхового случая - внешний ключ.

Таблица 2.4 - состав таблицы «Клиент»

Наименование атрибутов	Тип полей	NULL
id_клиента Наименование Адрес ИНН Телефон	int nchar(40) nchar(30) int int	Нет Нет Да Нет Нет

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

- id клиента - первичный ключ.

Таблица 2.5 - состав таблицы «Вид страхования»

Наименование атрибутов	Тип полей	NULL
id_вида_страхования Наименование	int nchar(40)	Нет Нет

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

- id вида страхования - первичный ключ.

Таблица 2.6 - состав таблицы «Страховой случай»

Наименование атрибутов	Тип полей	NULL
id_страхового_случая Наименование id_вида_страхования Стоимость_в_год	int nchar(40) int money	Нет Нет Нет Нет

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

- id страхового случая - первичный ключ;

- id вида страхования - внешний ключ.

2.2.1 Диаграмма связи по полям

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

Таблица 2.7 - Функциональные зависимости в таблице «Договор»

Наименование атрибутов	Функциональные зависимости
id_договора
id_агента
id_клиента
id страхового случая
Дата_заключения
Срок_(лет)

Таблица 2.8 - Функциональные зависимости в таблице «Агент»

Наименование атрибутов	Функциональные зависимости
id_агента
Ф.И.О.
Дата_приема_на_работу
id_вида_страхования
Серия/номер_паспорта
Адрес

Таблица 2.9 - Функциональные зависимости в таблице «Клиент»

Наименование атрибутов	Функциональные зависимости
id_клиента
Наименование
Адрес
ИНН
Телефон

Таблица 2.10 - Функциональные зависимости в таблице «Страховой случай»

Наименование атрибутов	Функциональные зависимости
id_страхового_случая
Наименование
id_вида_страхования
Стоимость_в_год

Таблица 2.11 - Функциональные зависимости в таблице «Вид страхования»

Наименование атрибутов	Функциональные зависимости
id_вида_страхования
Наименование

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

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

Были сформулированы запросы всех типов, реализуемых средствами выбранного программного средства.

1. Простой запрос с сортировкой

Формулировка запроса: выбрать коды агентов, фамилии, даты приема на работу из таблицы «Агент» и отсортировать (по возрастанию) результат выборки по полю «Дата приема на работу».

Код запроса на языке SQL: «SELECT id_агента, ФИО, Дата_приема_на_работу FROM Агент ORDER BY Дата_приема_на_работу».

Результат запроса представлен на рисунке 3.1.

Рисунок 3.1 - Результат выполнения запроса

2. Запрос с использованием оператора естественного соединения

Формулировка запроса: выбрать фамилии агентов, наименования клиентов, даты заключения договоров из таблиц «Агент», «Клиент» и «Договор» путем соединения их по кодам агентов и по кодам клиентов.

Код запроса на языке SQL: «SELECT ФИО, Наименование, Дата_заключения FROM Договор INNER JOIN Агент on Договор.id_агента = Агент.id_агента INNER JOIN Клиент on Договор.id_клиента = Клиент.id_клиента».

Результат запроса представлен на рисунке 3.2.

Рисунок 3.2 - Результат выполнения запроса

3. Выборка с использованием шаблона

Формулировка запроса: выбрать наименования, стоимость в год всех страховых случаев, наименования которых начинаются с буквы «С».

Код запроса на языке SQL: «SELECT Наименование,Стоимость_в_год FROM Страховой_случай WHERE Наименование LIKE 'С%'»

Результат запроса представлен на рисунке 3.3.

Рисунок 3.3 - Результат выполнения запроса

4. Выборка информации в заданном диапазоне

Формулировка запроса: выбрать все поля из таблицы «Страховой случай», где «Стоимость в год» одного вида страхования варьируется в диапазоне от 1400 до 3000.

Код запроса на языке SQL: «SELECT * FROM Страховой_случай WHERE Страховой_случай.Стоимость_в_год BETWEEN '1400' AND '3000'»

Результат запроса представлен на рисунке 3.4.

Рисунок 3.4 - Результат выполнения запроса

5. Выборка информации по дате

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

Код запроса на языке SQL: «SELECT * FROM Договор WHERE Договор.Дата_заключения > '26.06.2005'».

Результат запроса представлен на рисунке 3.5.

Рисунок 3.5 - Результат выполнения запроса

6. Выборка исчисляемых значений

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

Код запроса на языке SQL: «SELECT Клиент.Наименование, Агент.ФИО, Страховой_случай.Стоимость_в_год*Договор.Срок_лет AS Сумма_выплат, Договор.Срок_лет FROM Агент INNER JOIN Договор ON Агент.id_агента = Договор.id_агента INNER JOIN Клиент ON Договор.id_клиента = Клиент.id_клиента INNER JOIN Страховой_случай ON Договор.id_страхового_случая =Страховой_случай.id_страхового_случая».

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

Рисунок 3.6 - Результат выполнения запроса

7. Запрос с объединением множеств

Формулировка запроса: выбрать все поля из таблицы «Страховой случай», где Наименование страхового случая начинается с буквы «С» или стоимость в год более 2000 рублей.

Код запроса на языке SQL:

«SELECT * FROM Страховой_случай WHERE (Наименование LIKE 'С%')

UNION

SELECT * FROM Страховой_случай AS Страховой_случай_1

WHERE (Стоимость_в_год > 2000)».

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

Рисунок 3.7 - Результат выполнения запроса

8. Запрос с использованием оператора естесственного соединения

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

Код запроса на языке SQL:

«SELECT Вид_страхования.Наименование AS Вид_страхования, Страховой_случай.Наименование AS Страховой_случай

FROM Вид_страхования INNER JOIN Страховой_случай ON Вид_страхования.id_вида_страхования=Страховой_случай.id_вида_страхования»

Результат выполнения запроса представлен на рисунке 3.8

Рисунок 3.8 - Результат выполнения запроса

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

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

В базе данных разработано представление «Заключенный договор». В данном представлении вынесены поля - ФИО агента, наименование клиента, название вида страхования, дата заключения договора. Поля взяты из таблиц «Агент», «Клиент», «Вид страхования» и «Договор» соответственно.

Рисунок 4.1 - Результат выполнения представления «Заключенный договор»

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

Хранимые процедуры - представляют собой процессы, выполняемые непосредственно на сервере баз данных.

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

В базе данных представлена хранимая процедура«Vleader». Хранимая процедура «Vleader» предназначена для выборки информации о договорах, заключенных до указанной даты. Единственным параметром данной процедуры как раз и является эта дата.

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

-- ================================================

-- Template generated from Template Explorer using:

-- Create Procedure (New Menu).SQL

--

-- Use the Specify Values for Template Parameters

-- command (Ctrl-Shift-M) to fill in the parameter

-- values below.

--

-- This block of comments will not be included in

-- the definition of the procedure.

-- ================================================

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

-- =============================================

-- Author: <Author,,Name>

-- Create date: <Create Date,,>

-- Description: <Description,,>

-- =============================================

CREATE PROCEDURE [dbo].[Vleader]

-- Add the parameters for the stored procedure here

@Pdate datetime

AS

BEGIN

-- SET NOCOUNT ON added to prevent extra result sets from

-- interfering with SELECT statements.

SET NOCOUNT ON;

-- Insert statements for procedure here

SELECT * FROM Договор WHERE Договор.Дата_заключения < @Pdate

END

Параметр процедуры имеет имя «@Pdate» и тип «Datetime».

Рисунок 5.1 - Результат выполнения хранимой процедуры «Vleader»

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

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

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

В базе представлены три триггера «InsertDealTrg», «UpdateDealTrg» и «DeleteDealTrg». Все три триггера представлены для таблицы «Договор». Они осуществляют проверку при добавлении, изменении и удалении данных, а именно проверку даты заключения сделки.

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

Триггеры этого типа запускаются при попытке вставки данных с помощью команды INSERT:

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TRIGGER [dbo].[InsertDealTrg]

ON [dbo].[Договор]

FOR INSERT

AS

BEGIN

SET NOCOUNT ON;

IF (SELECT Дата_заключения FROM Inserted) < getdate()

rollback

END

GO

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

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

Триггеры этого типа запускаются при попытке удаления данных с помощью команды DELETE:

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TRIGGER [dbo]. [DeleteDealTrg]

ON [dbo].[Договор]

FOR DELETE

AS

BEGIN

SET NOCOUNT ON;

IF (SELECT Дата_заключения FROM Inserted) < getdate()

rollback

END

GO

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

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

Триггеры этого типа запускаются при попытке изменения данных с помощью команды UPDATE:

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TRIGGER [dbo]. [UpdateDealTrg]

ON [dbo].[Договор]

FOR UPDATE

AS

BEGIN

SET NOCOUNT ON;

IF (SELECT Дата_заключения FROM Inserted) < getdate()

rollback

END

GO

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

страховая база приложение инфологический

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

Система безопасности MS SQL Server базируется на пользователях и учетных записях. Пользователи проходят следующие два этана проверки системой безопасности. На первом этапе пользователь идентифицируется по имени учетной записи и паролю, то есть проходит аутентификацию. Если данные введены правильно, пользователь подключается к MS SQL Server. Подключение к MS SQL Server, или регистрация, не дает автоматического доступа к базам данных. Для каждой базы данных сервера регистрационное имя (или учетная запись -- login) должно отображаться в имя пользователя базы данных (user). На втором этапе, на основе прав, выданных пользователю как пользователю базы данных (user), его регистрационное имя (login) получает доступ к соответствующей базе данных.

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

В данном курсовом проекте была реализована задача создания новой учетной записи (Рисунок 7.1) и пользователя (Рисунок 7.2) по имени Agent, которому были предоставлены определенные права доступа и возможности модификации данных, и учетная запись.

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



Рисунок 7.1 - Диалоговое окно «Создание новой учетной записи»

Рисунок 7.2 - Диалоговое окно «Создание нового пользователя»

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

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

Рисунок 7.3 - Диалоговое окно «Разграничение полномочий пользователя»

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

В рамках данного курсового проекта, было разработано клиентское приложение, организующее обмен данными с серверной частью MS SQL Server 2005. В базе данных содержится информация об агентах страхования, клиентах, видах страхования и соответствующим им страховым случаям, а также о заключенных договорах. Для автоматизации, наглядности и простоты управления рабочим процессом все данные отображаются на формах. Сотрудник, т.е. агент страховой компании, имеет возможность просмотра информации о клиентах, которая уже содержится в базе данных, а также возможность ее редактирования, обновления и удаления ненужных записей. Также имеется краткая информация о сотрудниках организации, на тот случай если понадобится быстрый поиск ИНН, телефона или адреса сотрудника. Благодаря обеспеченной целостности данных вся информация сохраняется на сервере. В базе данных также хранится вся информация о заключенных договорах, страховых случаях, видах страхования.

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

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

Одним из способов, с помощью которых различные приложения могут подключиться базам данных SQL - сервера, является интерфейс Open Database Connectivity (открытый интерфейс подключения к базам данных). ODBC обеспечивает набор функций программного интерфейса приложений (API), которые упрощают подключение к базам данных самых различных форматов.

Доступ к базам данных в этом случае осуществляется с помощью драйверов ODBC, библиотек DLL, в которых содержатся функции для обеспечения таких возможностей. Драйверы ODBC устанавливаются в системе одновременно с установкой в ней утилит SQL - сервера. Кроме этого они могут устанавливаться совместно с некоторыми приложениями и средствами разработки, например с Microsoft Office. В поставке комплекта Microsoft Office находится специальное приложение Microsoft Query, с помощью которого осуществляется формирование запросов к базам данных. Это приложение запускается из Word и Excel, после чего оно формирует запросы к базам данных для этих систем и возвращает им результаты выполнения этих запросов (рисунок 8.1).

Рисунок 9.1 - Результат выполнения запроса в Excel

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

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

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

(10.1)

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

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

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

(10.2)

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

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

- дисконтирующая функция, которая вводится с целью приведения всех затрат и результатов к одному моменту времени:

(10.3)

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

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

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

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

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

(10.4)

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

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

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

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

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

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

(10.6)

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

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

Эг=465

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

(10.7)

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

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

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

Программное обеспечение: Операционная система WINDOWS 2000/XP и выше, Borland Delphi 7, MS Microsoft SQL Server 2005.

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

Работа с базой данных может быть также организована и через клиентское приложение. Программа разработана на Borland Delphi 7.

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

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

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

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

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

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

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

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

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

При хранении информации в СУБД одной из основных задач остается обеспечение безопасности данных.

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

На рисунке 12.1 представлено окно запроса пароля. На рисунке 12.2 представлена главная форма приложения.

Рисунок 12.1 - Окно авторизации

Рисунок 12.2 - Главная форма приложения

На главной форме расположена таблица, отображающая все заключенные договора на сегодняшний день. Помимо этого на форме находятся три кнопки - «Клиенты», «Заключить сделку», «Суммы выплат». При нажатии на кнопку «Клиенты» происходит переход на следующую форму приложения (Рисунок 12.3), на которой пользователь может осуществлять управление записями этой таблицы посредством кнопок удаления, добавления, перехода от одной записи к другой, редактирования, сохранения, отмены редактирования.

Рисунок 12.3 - Форма приложения

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

Рисунок 12.4 - Форма приложения

При нажатии кнопки «Суммы выплат», происходит выполнение запроса, результат которого будет выведен на форму в виде таблицы (Рисунок 12.5)

Рисунок 12.5 - Форма приложения с выполненным запросом

ЗАКЛЮЧЕНИЕ

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

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

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

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

- среда разработки - MS Microsoft SQL Server 2005 и Borland Delphi

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

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

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

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

4. Бартеньев О.В. Microsoft Visual FoxPro:Учебно-справочное пособие/ М.: Диалог МИФИ, 2005-672 с.

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

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

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

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

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

10. Закон РФ от 27 ноября 1992 г. N 4015-1 "Об организации страхового дела в Российской Федерации" Российская газета. - 12 января 1993 г.

ПРИЛОЖЕНИЕ А

Листинг программы

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Grids, DBGrids, DB, ADODB, ExtCtrls, DBCtrls, StdCtrls;

type

TForm1 = class(TForm)

ADOConnection1: TADOConnection;

DataSource1: TDataSource;

DBGrid1: TDBGrid;

ADOTable1: TADOTable;

Button1: TButton;

Button2: TButton;

Label1: TLabel;

Button3: TButton;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

procedure Button3Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

uses Unit2, Unit3, Unit4, PASSWORD;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);

begin

form2.show;

end;

procedure TForm1.Button2Click(Sender: TObject);

begin

form3.show;

end;

procedure TForm1.Button3Click(Sender: TObject);

begin

form4.show;

end;

procedure TForm1.FormShow(Sender: TObject);

begin

PasswordDlg.ShowModal;

end

end.

unit Unit5;

interface

uses Windows, SysUtils, Classes, Graphics, Forms, Controls, StdCtrls,

Buttons;

type

TPasswordDlg1 = class(TForm)

Label1: TLabel;

Password: TEdit;

OKBtn: TButton;

CancelBtn: TButton;

private

{ Private declarations }

public

{ Public declarations }

end;

var

PasswordDlg1: TPasswordDlg1;

implementation

{$R *.dfm}

procedure TPasswordDlg.FormCloseQuery(Sender: TObject;

var CanClose: Boolean);

const pass='ghbdtn';

begin

if Password.Text = pass then CanClose:=true

else Application.Terminate;

end;

end.

Размещено на Allbes