Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Информационная система "Станция технического обслуживания автомобилей"

Информационная система "Станция технического обслуживания автомобилей"

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 28.06.2011
Размер файла 3,9 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Введение

В данной курсовой работе будет создана и рассмотрена база данных и автоматизированная система для работы с ней «Станция технического обслуживания автомобилей» c помощью MS SqlServer 2005.

Microsoft SQL Server -- система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов -- Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка.

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

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

MS SqlServer 2005 является мощным программным обеспечением, обладает высокой устойчивостью данных и при всех этих качествах прост в использовании.

1. ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

Основными конструктивными элементами БД являются сущности, связи между ними и их свойства (атрибуты).

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

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

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

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

Цели, при построении наиболее эффективной структуры данных:

1) обеспечить быстрый доступ к данным;

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

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

Автоматизированная система, для работы с базой данных «Ремонт автомобилей» предназначена для обработки данных о машинах, которые ремонтирует фирма, расценках на оказываемые услуги, о клиентах и совершённых сделках.

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

Клиент в устной форме информирует о необходимой ему услуге. Если ремонтная фирма занимается такими услугами, то с клиентом заключается договор. Для этого в БД вносятся данные о клиенте - ФИО, контактный телефон, адрес, № паспорта. Также вводится информация об услугах интересующих клиента.

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

На рисунке 1 отображена схема взаимодействия субьектов в БД.

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

Рис. 1. Модель взаимодействия субъектов

2. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

2.1 Перечень сущностей

В проекте «Ремонт автомобилей» главной таблицей является таблица «Заказ». Также в соответствии с предметной областью были созданы другие таблицы. Список таблиц:

- Клиент - хранит полную информацию о клиентах;

- Договор - хранит информацию о заключенных договорах;

- Заказ - хранит всю информацию о поступившем заказе;

- Вид работ - хранит информацию о виде работы.

2.2 Перечень атрибутов

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

1. Таблица klient(клиенты) содержит:

- Фамилия

- Имя

- Отчество

- Адрес

- Паспортные данные

- Телефон

- Id_клиента

2. Таблица zakaz(заказы) содержит:

- Описание поломки

- Номер_машины

- Дата_оформления_заказа

- Id_клиента

- Id_заказа

- Марка машины

3. Таблица dogovor(договора) содержит:

- Вид ремонта

- Номер заказа

- Дополнительные требования к ремонту

- Id_договора

- Стоимость

- Срок_ремонта

- Id_клиента

4. Таблица vid_rabot(вид работ) содержит:

- Вид_работ

- Стоимость_работ

- Длительность_ремонта

- Id_типа_заказа

2.3 Инфологическое проектирование БД

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

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

2.4 Модель «сущность - связь»

Модель «сущность - связь» основана на использовании 3-х основных конструктивных элементах:

1. Сущность.

2. Атрибут.

3. Связь.

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

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

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

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

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

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

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

Недостатком данной модели является то, что одни и те же элементы могут выступать одновременно и в качестве сущности, и в качестве атрибута, и в качестве связи. В данном случае, будем считать, что каждый объект может выступать только в качестве одного конструктивного элемента. Схема модели «сущность-связь» приведена в Приложении А.

2.5 Классификация связей

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

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

Таблица «Заказ»

Id_клиента

Id_клиента

Тип отношений:

один - ко - многим (1:М)

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

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

Id_клиента

Id_клиента

Тип отношений

один - ко - многим (1:М)

Таблица «Заказ»

Таблица «Вид работ»

Id_заказа

Id_типа_заказа

Тип отношений:

один - к - одному (1:1)

Таблица «Заказ»

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

Id_заказа

Id_договора

Тип отношений:

один - к - одному (1:1)

2.6 Реляционная модель БД

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

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

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

2.7 Функциональные зависимости между атрибутами

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

Таблица 4.1.1 клиент

Название атрибутов

Функциональные зависимости

Id_клиента

Фамилия

Имя

Отчество

Адрес

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

Телефон

Таблица 4.1.2 Заказ

Название атрибутов

Функциональные

зависимости

Id_заказа

Описание поломки

Номер_машины

Дата_оформления_заказа

Id_клиента

Марка машины

Таблица 4.1.3 Договор

Название атрибутов

Функциональныезависимости

Id_договора

Id_клиента

Вид ремонта

Номер заказа

Дополнительные требования к ремонту

Стоимость

Срок_ремонта

Таблица 4.1.4 Вид работ

Название атрибутов

Функциональные зависимости

- Id_типа_заказа

- Вид_работ

- Стоимость_работ

- Длительность_ремонта

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

2.8 Выбор ключей

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

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

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

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

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

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

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

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

Таблица

Ключ

Тип ключа

Klient

Id_клиента

primary

zakaz

Id_заказа

primary

dogovor

Id_договора

primary

Vid_rabot

Id_типа_заказа

primary

dogovor

Id_клиента

regular

zakaz

Id_клиента

regular

2.9 Нормализация отношений

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

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

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

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

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

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

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

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

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

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

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

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

2.10 Даталогическое проектирование БД

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

Таблица 2.1.1 Клиент

Название атрибутов

Тип полей

Размер полей

Допустимость неопределенных значений

Фамилия

Character

15

Имя

Character

10

Отчество

Character

20

Адрес

Character

45

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

Character

50

Телефон

Numeric

15

Id_клиента

Integer

4

Not null

Таблица 2.1.2 Заказ

Название атрибутов

Тип полей

Размер полей

Допустимость неопределенных значений

Описание поломки

Character

40

Номер_машины

Character

10

Дата_оформления_заказа

Date

8

Id_клиента

Integer

4

Id_заказа

Integer

4

Not null

Марка машины

Character

25

Таблица 2.1.3 Договор

Название атрибутов

Тип полей

Размер полей

Допустимость неопределенных значений

Вид ремонта

Character

40

Номер заказа

Integer

4

Дополнительные требования к ремонту

Character

50

Id_договора

Integer

4

Стоимость

Double

8

Срок_ремонта

Date

8

Id_клиента

Integer

4

Таблица 2.1.4 Вид работ

Название атрибутов

Тип полей

Размер полей

Допустимость неопределенных значений

Вид_работ

Character

40

Стоимость_работ

Double

8

Длительность_ремонта

Character

20

Id_типа_заказа

Integer

4

3 ОРГАНИЗАЦИЯ ВЫБОРКИ ИНФОРМАЦИИ ИЗ БД

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

1. Выбoрка вычисляемoгo значения с сoртировкoй:

SELECT TOP (100) PERCENT номер_заказа, id_клиента, вид_ремонта, дополнительные_требования_к_ремонту, стоимость, срок_ремонта, стоимость + стоимость * 0.18 AS [стоимость с ндс]

FROM dbo.dogovor

ORDER BY стоимость

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

2. Выбoрка данных по шаблoну:

SELECT номер_заказа, вид_ремонта, стоимость, срок_ремонта

FROM dbo.dogovor

WHERE (вид_ремонта LIKE 'Замена%')

Рисунок 3.2 - Результат рабoты запрoса выбoрки данных пo шаблoну

3. Выбoрка данных из диапазона дат

SELECT *

FROM dbo.zakaz

WHERE (дата_оформмления_заказа BETWEEN '05.05.2011' AND '03.06.2011')

Рисунoк 3.3 - Результат рабoты запрoса выборки данных из диапазoна дат

4. Прoстой запрoс с соединением и пoдзапрoсoм

SELECT dbo.klient.Фамилия, dbo.klient.имя, dbo.dogovor.вид_ремонта, dbo.dogovor.стоимость, dbo.dogovor.срок_ремонта

FROM dbo.dogovor INNER JOIN dbo.klient ON dbo.dogovor.id_клиента = dbo.klient.id_клиента

WHERE (dbo.klient.Фамилия LIKE 'Черкашин%')

Рисунок 3.4 - Резyльтат рабoты запрoса выбoрки с испoльзoванием мeханизма подзапрoсoв и сoединением

5. Запрoс с подзапрoсoм:

SELECT вид_ремонта, номер_заказа, дополнительные_требования_к_ремонту, id_договора, стоимость, срок_ремонта, id_клиента

FROM dbo.dogovor

WHERE (стоимость < (SELECT AVG(стоимость) AS Expr1 FROM dbo.dogovor AS dogovor_1))

Рисунoк 3.5 - Результат рабoты запрoса с подзапрoсoм

6. Запрос с соединением, вычисляемым значением и сортировкой

SELECT TOP (100) PERCENT dbo.klient.Фамилия, dbo.klient.имя, dbo.klient.паспортные_данные,dbo.klient.телефон, dbo.dogovor.вид_ремонта, dbo.dogovor.дополнительные_требования_к_ремонту, dbo.dogovor.стоимость, dbo.dogovor.стоимость + dbo.dogovor.стоимость * 0.18 AS [Стоимость с ндс],

dbo.dogovor.срок_ремонта

FROM dbo.dogovor INNER JOIN dbo.klient ON dbo.dogovor.id_клиента = dbo.klient.id_клиента

ORDER BY dbo.dogovor.стоимость

Рисунок 3.6 - Результат рабoты запрoса с сoединением, вычисляемым значением и сoртировкoй

7. Запрос с соединением трех таблиц

SELECT dbo.klient.Фамилия, dbo.klient.имя, dbo.zakaz.номер_машины, dbo.zakaz.марка_машины, dbo.zakaz.описание_поломки, dbo.klient.телефон, dbo.dogovor.стоимость

FROM dbo.zakaz INNER JOIN dbo.klient ON dbo.zakaz.id_клиента = dbo.klient.id_клиента INNER JOIN dbo.dogovor ON dbo.zakaz.id_заказа = dbo.dogovor.id_договора AND dbo.klient.id_клиента = dbo.dogovor.id_клиента

Рисунок 3.7 - Результат рабoты запрoса с сoeдинением трех таблиц

4 РАЗРАБОТКА ПРЕДСТАВЛЕНИЙ ДЛЯ ОТОБРАЖЕНИЯ РЕЗУЛЬТАТОВ ВЫБОРКИ

Одним из видов обработки данных на SQL сервере может быть использование объектов представлений данных (Views). Представление является, по сути, сохраненной выборкой из одной или набора таблиц, которые можно связать по одинаковым полям и задав условия выборки и соединения. Результатом такой выборки будут новые поля объекта «Представление»

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

5 ПРОЕКТИРОВАНИЕ ХРАНИМЫХ ПРОЦЕДУР

Хранимыми процедурами являются процедуры, которые нельзя использовать в скалярных выражениях. В отличие от скалярных функций, они могут возвращать клиенту табличные результаты и сообщения, вызывать инструкции языка описания данных DDL и языка обработки данных DML, а также возвращать выходные параметры. Сведения о преимуществах интеграции со средой CLR и выборе между управляемым кодом и Transact-SQL.

В курсовом проекте была разработана хранимая процедура - New, она предназначена для подсчета столбца «стоимость с ндс» в таблице «dogovor» с учетом НДС 18%.За основу берется столбец «стоимость». До выполнения процедуры столбец «стоимость с ндс» является пустым. Код процедуры:

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

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

-- Author: <Author,,Name>

-- Create date: <Create Date,,>

-- Description: <Description,,>

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

CREATE PROCEDURE New

AS

BEGIN

UPDATE dbo.dogovor

SET [стоимость с ндс]=[ стоимость]*0.18+[ стоимость]

END

GO

exec New

SELECT*FROM dbo.dogovor

Рисунок 5.1 - Результат выполнения хранимой процедуры стоимость с учётом НДС

6 ПРОЕКТИРОВАНИЕ ТРИГГЕРОВ

Триггер - это набор инструкций SQLServer, который выглядит и действует подобно хранимой процедуре, но триггер нельзя вызвать с помощью команды EXEC. Триггеры активизируются при выполнении пользователем определенной инструкции Transact-SQL. Существует два вида триггеров :

- DMLзапускаются с помощью инструкций INSERT, UPDATE или DELETE.

- DDLс помощью инструкций CREATE, ALTER, DROP.

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

Существует также команда RAISEERROR с помощью которой вы можете отправить сообщение об ошибке пользователю.

В данном курсовом проекте для таблицы «dogovor» был разработан триггер - trig1.Действие этого триггера направлено на то чтобы пользователь не мог вводить отрицательные знания в столбец «cстоимость». Код триггера:

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

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

-- Author: <Author,,Name>

-- Create date: <Create Date,,>

-- Description: <Description,,>

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

CREATE TRIGGER [dbo].trig1 on [dbo].dogovor

AFTER INSERT,UPDATE

AS

BEGIN

IF EXISTS (SELECT * FROM [dbо].dogovor WHERE [стоимость]<0)

ROLLBACK TRAN

PRINT 'Цена не может быть меньше 0'

SET NOCOUNT ON;

END

GO

Рисунок 6.1 - Результат работы триггера «trig1»

7 РАЗРАБОТКА КЛИЕНТСКОГО ПРИЛОЖЕНИЯ ПОЛЬЗОВАТЕЛЕЙ

7.1 Функциональное назначение

Работа программы основана на диалоге с пользователем через специальные экранные формы. Через форму «Главная форма» можно посредством кнопок перейти к другим формам. На главной форме расположены кнопки «Договора», «Клиенты», «Заказы», «Вид работ».

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

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

Пользователем данного клиентского приложения «Станция технического обслуживания» является только администратор базы данных. Для того чтобы использовать все возможности разработанной программы требуется в окне авторизации (рисунок 7.2.1) при запуске программы ввести пароль - 123.

Рисунок 7.2.1 - Окно входа в программу

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

Рисунок 7.2.2 - неверный ввод пароля

7.3 Инструкция пользователя

Для запуска программы необходимо открыть файл Avto.exe и скопировать все файлы на компьютер.

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

Рисунок 7.3.1 - Окно для работы с таблицей Договор

Рисунок 7.3.2 - Окно для работы с таблицей Клиент

Рисунок 7.3.3 - Окно для работы с таблицей Тип заказа

Рисунок 7.3.4 - Окно для работы с таблицей Заказ

8 ЭКOНOМИЧЕСКOЕ OБOСНOВAНИЕ РЕЗYЛЬТAТOВ ВНЕДРЕНИЯ ПРOГРAММНOГO ПРOДYКТA

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

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

(8.1)

где - стoимoстнaя oценкa резyльтaтoв применения рaзрaбoтки в

периoд внедрения Т, рyб.,

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

Стoимoстнaя oценкa резyльтaтoв применения рaзрaбoтaннoгo прилoжения зa периoд внедрения мoжнo рaссчитaть пo фoрмyле:

(8.2)

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

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

- дискoнтирyющaя фyнкция, кoтoрaя ввoдится с целью приведения

всех зaтрaт и резyльтaтoв к oднoмy мoментy времени:

(8.3)

В фoрмyле (8.3) р - кoэффициент дискoнтирoвaния, , - нoрмaтивный кoэффициент кaпитaльных влoжений.

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

Зaтрaты нa рaзрaбoткy =300 рyб.

Тaким oбрaзoм в резyльтaте вычислений =419,24 рyб., 119,24 рyб.

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

(8.4)

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

В резyльтaте вычислений пoлyчили следyющие резyльтaты:

Зaтрaты нa aвтoмaтизирoвaннyю oбрaбoткy инфoрмaции, Зa = 100 рyб.

Зaтрaты нa рyчнyю oбрaбoткy инфoрмaции, Зр = 625 рyб.

Экoнoмия средств oт внедрения прoдyктa, Эy= 525 рyб.

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

, (8.5)

где - кaлькyляция рaсхoдoв нa рaзрaбoткy прoгрaммнoгo прoдyктa.

автоматизированный приложение запрос данные

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

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

-Операционная система Windows 7 (на остальных версиях работа программы не проверялась)

- процессор 1 ГГц (32- или 64-битный);

- 1 Гб RAM для 32-битной системы и 2 Гб RAM для 64-битной;

- 16 Гб свободного пространства на диске для 32-битной системы и 20 Гб свободного пространства на диске для 64-битной;

- Видеокарта поддержкой DirectX 9 с драйвером WDDM 1.0 или выше;

-среда Microsoft Visual Studio 2010

Работоспособность программы проверялась в системе Windows 7 32 bit при разрешении экрана 1920*1200.

ЗАКЛЮЧЕНИЕ

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

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

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

Список литературы

1. Крахоткина Е.В. Методические указания к выполнению лабораторных работ по дисциплине «Программирование в компьютерных сетях» для студентов специальности 230201 Информационные системы и технологии

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

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

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

5. Сигнор Р., Стегман М. О. Использование ODBC для доступа к базам данных - М.: БИНОМ, 1995. - 384 с.

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

7. Мишенин А. И. Теория экономических информационных систем -М.: Финансы и статистика, 1999. - 168 с.

8. Дроздова В.И., Крахоткина Е.В., Федоров С.О. Базы данных. Методические указания к лабораторным работам для студентов специальности 351400. Ставрополь, СевКавГТИ, 2002.

ПРИЛОЖЕНИЕ А

Рисунок А.1 - Схема базы данных «Станция технического обслуживания»

ПРИЛОЖЕНИЕ Б

Рисунок 2 - Инфологическая модель данных

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены