Проектирование информационной системы по работе с клиентами на предприятии

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

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

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

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

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

  • Содержание
  • Введение

1. Расчетно - теоретическая часть

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

1.2 Разработка технического задания

1.3 Анализ технического задания

1.4 Выбор средств решения выполнения технического задания

2. Технологическая часть

2.1 Разработка структуры БД

2.2 Индексирование

2.3 Архитектура базы данных

2.4 Описание созданных отчетов

3. Руководство пользователя информационной системы

4. Организационно - экономическая часть

4.1 Задание к организационно - экономической части дипломного проекта

4.2 Актуальность разработки

4.3 Затраты на проектирование информационной системы

4.4 Расчет трудоемкости проекта

4.5 Альтернативные пути решения поставленной задачи

4.6 Эффективность внедрения системы

5. Безопасность и экологичность проекта

5.1 Оценка безопасности и экологичности проекта

5.2 Микроклимат

5.3 Производственное освещение

5.4 Шум и вибрация

5.5 Электромагнитное излучение

5.6 Безопасность технологических процессов и оборудования

5.7 Электробезопасность

5.8 Пожарная безопасность

5.9 Организация рабочего места

5.10 Расчетная часть

  • Список литературы
  • Приложения
  • Введение

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

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

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

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

1. Расчетно - теоретическая часть

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

Проектируемая информационная система предназначена для ЗАО «ННВП» - предприятия, занимающегося розничной торговлей нефтепродуктами. На предприятии существуют специализированные формы оплаты - это бензиновые карты и талоны.

Топливная карта - техническое средство отпуска продукции, представляющее собой пластиковый (с микропроцессором) носитель информации, подтверждающий его право на получение продукции на АЗС. Информация о количестве оплаченного бензина хранится в литрах (раздельно по каждому виду топлива) на самой карте и в общей базе данных компании. Количество оплаченных литров фиксируется на момент оплаты и не меняется при изменении розничных цен. Карты защищены от копирования, подделки и несанкционированного доступа. Талон на бензин - это уникальная (для нашего региона) форма оплаты за ГСМ. Талоны специального образца различаются по виду бензина и номиналу: бензин А-76, Аи-92, Аи-95 по 20 литров, дизельное топливо по 40 литров каждый.

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

Основные требования, предъявляемые к системе:

1) Система должна обеспечивать пользователя следующей информацией:

- реквизиты клиента;

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

- количество карт у клиента;

- тип бензина и лимит, установленный на карте;

- текущее состояние топлива на карте;

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

- о датах и местах реализации топлива по каждой карте;

- номера проданных талонов;

- дата и место погашения талонов.

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

- выдачу новых и изъятие неисправных карт;

- установку и изменение типа обслуживания и лимита на карту;

- производить пополнение карты (т.е. произвести запись на карту оплаченного бензина в литрах);

- производить распределение платежей клиента, в соответствии с проведенными платежами в базе «1С:Предприятие»;

- отслеживать текущее состояние счета клиента;

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

3) Система должна обеспечить организацию работы по талонам:

- отслеживание движения талонов внутри организации;

- обеспечить выдачу талонов клиенту;

- обеспечить внесение в базу данных номеров погашенных талонов;

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

4) Система должна представлять отчеты в печатной форме:

- баланс денежных средств;

- отчет по реализации топлива за выбранный период;

- отчет по состоянию стоп - листа;

- отчет по реализации топлива по пластиковым картам на АЗС;

- отчет по кредитованию - дебетованию пластиковых карт в офисе;

- отчет по распределению денежных средств;

- отчет по поступлению денежных средств на счет клиента;

- отчет по пополнению пластиковых карт на АЗС;

- размер кредита для корпоративных клиентов по состоянию на заданный период;

- отчет по погашенным талонам (итоги по клиентам);

- отчет по выданным талонам (итоги);

- отчет по реализации топлива по талонам на АЗС (сменные итоги);

- отчет по погашенным талонам за определенный период по клиенту.

1.2 Разработка технического задания

Наименование и область применения информационной системы

Информационная система по работе с клиентами на предприятии по реализации нефтепродуктов «VP_Office».

Область применения - ЗАО «ННВП» - предприятие, занимающееся розничной торговлей нефтепродуктов.

Цель и назначение разработки

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

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

Требования к срокам разработки ИС

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

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

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

Программа должна обеспечивать:

1) Организацию работы предприятия с клиентами по топливным картам;

2) Организацию работы предприятия с клиентами по талонам;

3) Предоставление всей отчетной документации по реализации топлива.

Требования к пользовательскому интерфейсу программы

1) Программа должна иметь русскоязычный интуитивно-понятный интерфейс;

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

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

1) ознакомленный с техникой безопасности и правилами работы с персональным компьютером;

2) обладающий навыками работы на компьютере IBM PC в операционной системе Windows;

3) прошедший инструктаж по работе с данной программой.

1.3 Анализ технического задания

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

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

1.4 Выбор средств решения выполнения технического задания

Проанализировав поставленную задачу, было принято решение использования языка SQL - структурированного языка запросов (Structured Query Language), язык программирования, который применяется для организации взаимодействия пользователя с базой данных. SQL используется для реализации всех функциональных возможностей, которые СУБД предоставляет пользователю. К ним относятся:

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

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

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

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

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

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

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

Язык SQL является фундаментом системы безопасности реляционной СУБД: требования, предъявляемые к системе защиты информации в базе данных, формулируются с помощью инструкций SQL. С защитой данных в SQL связаны три основные концепции:

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

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

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

СУБД Microsoft SQL Server удерживает первую позицию по производительности среди других СУБД.

Microsoft SQL Server поддерживает язык Transact SQL, являющийся расширением стандарта ANSI-92, что позволяет создавать приложения, части которых функционируют целиком на сервере. Эти серверные компоненты реализуются в виде хранимых процедур и триггеров, которые могут обеспечить выполнение как специфических правил целостности данных, так и бизнес-логики. Применение серверных компонент, в частности, снижает расходы на сопровождение системы, так как все изменения производятся только на сервере.

Microsoft SQL Server будет оптимальным по следующим причинам:

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

- самое низкое соотношение цена/производительность;

- удобный и понятный графический интерфейс сокращает затраты на обучение;

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

- масштабируемость обеспечивает поэтапность инвестиций.

2. Технологическая часть

2.1 Разработка структуры БД

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

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

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

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

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

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

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

Модель типа "сущность - связь" (entity-relationship model) - это неформальная модель предметной области, которая используется на этапе инфологического проектирования базы данных. Эта модель позволяет моделировать объекты ПО, взаимоотношения объектов. Относительная простота, применение естественного языка и легкость понимания позволяют использовать модель как инструмент для общения с будущими пользователями для сбора информации о предметной области для проектирования базы данных.

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

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

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

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

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

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

Эта модель основывается на некоторой важной семантической информации о реальном мире. Вводится специальный диаграммный метод (ER - диаграммы) как средство проектирования баз данных. ER-диаграмма разрабатываемой информационной системы представлена на рисунке 2.1.

Рис. 2.1 «ER-диаграмма информационной системы».

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

- в таблице COUPONS хранятся данные о каждом талоне, такие как его номер; идентификатор его статуса; идентификатор вида топлива и его номинала; идентификатор склада, которому он принадлежит; идентификатор АЗС, на которой талон реализован; идентификатор служащего, который произвел операцию.

- в таблице CUSTOMER хранятся данные о каждом клиенте, такие, как название компании, ИНН, адреса и телефоны, идентификатор типа обслуживания, размер возможного кредита.

- в таблице SERVICE хранится информация о типе работы с клиентом (работа в кредит или по предоплате).

- в таблице STATUS хранится информация о возможных статусах талонов (не выдан/выдан/погашен/в стоп-листе).

- в таблице SKLAD хранится информация обо всех складах ЗАО «ННВП», на которых могут храниться талоны.

- в таблице GAS_COUPON хранится информация о типах талонов, т. е. о том, к какому типу бензина он относится и какой у него номинал (бензин А-76, Аи-92, Аи-95 по 20 литров и дизельное топливо по 40 литров).

- в таблице AZS хранится информация о всех АЗС ЗАО «ННВП».

- в таблице CARD хранятся данные о топливных картах: номер карты, идентификатор покупателя, которому она принадлежит, идентификатор текущего состояния карты.

- в таблице GAS_CARD хранятся данные о типах топлива, находящихся на карте, и количестве литров каждого типа, идентификатор типа лимита и его величина.

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

- в таблице GAS_TYPE хранится информация о типах топлива (бензин А-76, Аи-92, Аи-95 и дизельное топливо).

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

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

- в таблице EVENT_TYPE хранится информация о всевозможных типах событий. Схема данных представлена на рисунке 2.2.

Рис. 2.2 «Схема данных»

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

1) Блок, отвечающий за работу с клиентами по талонам на бензин.

2) Блок, отвечающий за работу с клиентами по топливным картам.

Первый функциональный блок представлен на рисунке 2.3.

Рис. 2.3 «Блок, отвечающий за работу с клиентами по талонам на бензин»

Второй блок представлен на рисунке 2.4.

Рис. 2.4 «Блок, отвечающий за работу с клиентами по топливным картам»

Рассмотрим каждую таблицу подробнее:

Таблица 2.1 - COUPONS

Поле

Тип данных

Описание

id_coup

int

ключевое поле

coupon_num

char(10)

номер талона

stutus_id

int

идентификатор статуса талона

gas_coupon_id

int

идентификатор типа топлива

sklad_id

int

идентификатор склада

date_operation

datetime

дата операции

cust_id

int

идентификатор покупателя

azs_id

int

идентификатор АЗС

date_realiz

datetime

дата погашения талона

Таблица 2.2 - STATUS

Поле

Тип данных

Описание

id_status

int

ключевое поле

status_name

text

наименование статуса талона

Таблица 2.3 - GAS_COUPON

Поле

Тип данных

Описание

id_gas_coupon

int

ключевое поле

gas_name

text

наименование бензина

nominal

int

номинал талона

Таблица 2.4 - SKLAD

Поле

Тип данных

Описание

id_sklad

int

ключевое поле

sklad_name

text

наименование склада

properties

text

дополнительные свойства

Таблица 2.5 - AZS

Поле

Тип данных

Описание

id_azs

int

ключевое поле

azs_name

text

наименование АЗС

descriptions

text

описание

Таблица 2.7 - CUSTOMERS

Поле

Тип данных

Описание

id_cust

int

ключевое поле

cust_name

text

название организации

inn

int

ИНН

address

text

адрес

service_id

int

идентификатор типа обслуживания

credit

int

величина возможного кредита

Таблица 2.8 - CARD

Поле

Тип данных

Описание

id_card

int

ключевое поле

card_num

char(10)

номер карты

card_property_id

int

идентификатор текущего состояния карты

cust_id

int

идентификатор покупателя

Таблица 2.9 - CARD_PROPERTY

Поле

Тип данных

Описание

id_card_property

int

ключевое поле

card_property

text

наименование состояния карты

Таблица 2.10 - GAS_CARD

Поле

Тип данных

Описание

id_gas_card

int

ключевое поле

card_id

int

идентификатор карты

gas_type_id

int

идентификатор типа бензина

gas_qty

int

количество бензина

type_limit_id

int

идентификатор типа лимита

limit_qty

int

величина лимита

Таблица 2.11 - TYPE_LIMIT

Поле

Тип данных

Описание

id_type_limit

int

ключевое поле

limit_name

text

наименование лимита

Таблица 2.12 - GAS_TYPE

Поле

Тип данных

Описание

id_gas_type

int

ключевое поле

gas_name

text

наименование бензина

Таблица 2.13 - SERVICE

Поле

Тип данных

Описание

id_service

int

ключевое поле

service_name

text

наименование типа бслуживания

Таблица 2.14 - EVENT

Поле

Тип данных

Описание

id_event

int

ключевое поле

cust_id

int

идентификатор клиента

card_id

int

идентификатор карты

date

datetime

дата события

event_type_id

int

идентификатор события

gas_type_id

int

идентификатор типа топлива

gas_count

int

количество литров

gas_price

int

цена за литр

azs_id

int

идентификатор АЗС

Таблица 2.15 - EVENT_TYPE

Поле

Тип данных

Описание

id_event_type

int

ключевое поле

event_type_name

text

описание типа события

2.2 Индексирование

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

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

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

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

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

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

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

- CUST_NAME таблицы CUSTOMERS, т.к данные о покупках часто извлекаются по названию организации.

- COUPON_NUM таблицы COUPONS, т.к данные о текущем состоянии талона часто извлекаются по его номеру.

- CARD_NUM из таблицы CARD, т.к данные по карте часто извлекаются по номеру карты.

Ниже приведена инструкция CREATE INDEX, которая создает индекс для таблицы COUPONS:

CREATE NONCLUSTERED INDEX [COUPON_NUM_IDX] ON [dbo].[COUPONS]

([COUPON_NUM] ASC)

WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF)

ON [PRIMARY]

2.3 Архитектура базы данных

Разработанная информационная система реализована на основе клиент-серверной архитектуры.

Клиент-серверная информационная система состоит в простейшем случае из трех основных компонентов:

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

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

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

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

Все это повышает быстродействие системы и снижает время ожидания результата запроса.

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

- посылка к серверу запросов;

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

- реализация интерфейса пользователя.

SQL-сервер - это программа, расположенная на компьютере сетевого сервера. SQL-сервер должен быть загружен на момент принятия запроса от клиента. Функциями сервера БД являются:

- прием запросов от приложений-клиентов, интерпретация запросов, выполнение запросов в БД, отправка результата выполнения запроса приложению-клиенту;

- управление целостностью БД, обеспечение системы безопасности, блокировка неверных действий приложений-клиентов;

- хранение бизнес-правил, часто используемых запросов в уже интерпретированном виде;

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

Использование архитектуры "клиент-сервер":

- резко уменьшает сетевой трафик;

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

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

- повышает надежность БД, ее целостность, безопасность и секретность.

Описание созданных запросов

Язык SQL предназначен в первую очередь для выполнения запросов.

SQL Server 2005 позволяет в одном запросе обращаться сразу к множеству разнообразных источников данных, возможно расположенных на разных серверах сети За счет использования технологии OLE DB пользователи могут получить доступ не только к реляционным источникам данных, как это было бы во время применения ODBC, но и к нереляционным, таким как текстовые файлы и электронные таблицы.
Для выборки данных в Transact-SQL существует команда SELECT, которая позволяет как делать простую выборку всех данных из одной таблицы текущей базы данных, так и выполнять сложные запросы одновременно к множеству таблиц различных баз данных, расположенных на нескольких серверах сети

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

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

INSERT INTO #TempTable( coupon_num, date, status, gas_name, cust_name )

SELECT DISTINCT coupons.id_coupon, coupons.date, coupons.status,

coupons.gas_name,

(SELECT cust_name FROM customers WHERE ID1C = (SELECT ClientID1C FROM [dbo].[1CBill]))

FROM [dbo].[Coupon] coupon

2.4 Описание созданных отчетов

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

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

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

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

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

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

- Информация, содержащаяся в XML-документах, может изменяться, передаваться на машину клиента и обновляться по частям.

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

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

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

После создания XML документа и убеждения, что набор используемых при этом тэгов позволяет осуществлять любые манипуляции с информацией. Необходимо создать DTD - определения, для того, чтобы утвердить правила языка, т.е. список допустимых элементов, их возможное содержимое и атрибуты. Определение типа документа (Document Type Definition, DTD) является тем фундаментом, на котором создаются XML-документы.

DTD определяет части документа и указывает, каким образом они могут использоваться, что может быть в них размещено, и требуются ли им фрагменты документа. DTD представляет собой набор правил, определяющий инструкции, которые могут быть переданы анализатору (parser) для обработки им этого документа. DTD может включать в себя набор объявлений элементов и атрибутов, а также сущности (entities), условные обозначения (notations) и комментарии. Различные объявления компонентов определяют, как документ будет структурирован, и эта информация (в виде инструкций) передается анализатору (parser). Анализатор, в свою очередь, отправляет результаты в приложение, обеспечивающее просмотр данных.

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

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

1) Активные талоны. Итоги. (рисунок 2.5)

2) Баланс (пластиковые карты). (рисунок 2.6)

3) Выданные пластиковые карты.

4) Выданные пластиковые карты, подробно.

5) Выданные талоны. Итоги.

6) Движение талонов. Итоги. (рисунок 2.7)

7) Погашенные талоны. Итоги

8) Размер кредита.

9) Суммарный отчет по реализации топлива на АЗС.

10) Текущее состояние счета корпоративных клиентов.

11) Отчет по дебетованию-кредитованию пластиковых карт.

12) Список клиентов

13) Текущее состояние стоп-листа пластиковых карт

14) Пополнение пластиковых карт. Итоги

15) Пополнение пластиковых карт. Сменные итоги.

16) Продажа пластиковых карт.

17) Реализация топлива по пластиковым картам.

18) Реализация топлива по талонам. Сменные итоги по всем АЗС.

В качестве примера в приложении А приведен программный код формирования итогового отчет по активным талонам, т.е еще не погашенным талонам, находящимся у покупателя.

Рисунок 2.5 «Отчет по активным талонам.Итоги»

Рисунок 2.6 «Баланс пластиковые карты»

Рисунок 2.7 «Отчет о движении талонов»

3. Руководство пользователя информационной системы

Данное приложение предназначено для работы с БД. Запускается программа из операционной системы Windows, и имеет стандартный интерфейс windows - приложений.

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

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

Форма «АЗС», представленная на рисунке 3.1, содержит все данные, сгруппированные по наименованию АЗС.

Рисунок 3.1 «Форма АЗС»

Эта форма предназначена для:

- отражения информации об автозаправочных станциях, принадлежащих ЗАО «ННВП», о месте их расположения, о реализуемых типах топлива;

- отражения информации о реализации топлива на конкретной АЗС по топливным картам за заданный период времени;

- отражения информации о зачислениях топлива на карты, производимых на АЗС;

- отражения информации о погашенных талонах в заданный промежуток времени;

- формирования необходимых отчетов за заданный промежуток времени.

При вызове вкладки Отчеты - Прочие пользователь, задав интересующий его промежуток времени на форме «Общие отчеты по АЗС» (рисунок 3.2), может сформировать интересующие его отчеты.

Рисунок 3.2 «Общие отчеты по АЗС»

Форма «контрагенты» (рисунок 3.3) отражает данные, сгруппированные по наименованию покупателя топлива. На этой форме отражаются такие данные, как реквизиты клиента, номера карт клиента, состояние его счета, платежи, реализация топлива.

Рисунок 3.3 «Форма контрагенты»

Эта форма содержит следующие вкладки:

1) Вкладка контрагент, вызывающая форму «Условия обслуживания», на которой задаются такие параметры базы данных, как тип обслуживания карт клиента (кредитные или предоплатные) и размер кредита в рублях (рисунок 3.4)

Рисунок 3.4 «Форма Условия обслуживания»

2) Вкладка пластиковые карты позволяет просмотреть историю стоп-листа пластиковой карты, остатки топлива на каждой карте (рисунок 3.5), кредитовать-дебетовать топливо на карте, изъять карту, поставить карту в стоп-лист и изъять из него, аннулировать карту. При выборе любого из действий, появляется окно с просьбой подтвердить действие.

Рисунок 3.5 «Остатки топлива на карте»

3) Вкладка талоны, вызывающая формы для организации работы предприятия по талонам:

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

Рисунок 3.6 «Погашение талонов»

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

Рисунок 3.7 «Форма поиск талонов»

Так же на этой форме есть кнопка «Коррекция», вызывающая форму «Коррекция ошибки погашения» (рисунок 3.8), вызывая которую можно изменить характеристики погашения или отменить его совсем.

Рисунок 3.8 «Форма коррекция ошибки погашения»

- форма «Движение талонов» (рисунок 3.9) позволяет производить движение талонов внутри организации ЗАО «ННВП», вносить талоны, прибывшие в организацию.

Рисунок 3.9 «Форма движение талонов»

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

Рисунок 3.10 «Форма список складов талонов»

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

Рисунок 3.11 «Форма поиск операций по движении. талонов внутри организации»

Работа пользователя по картам, начинается с синхронизации данных с 1С. При проведении платежей от клиентов в 1С, они отражаются в VP_Office (рисунок 3.12).

Рисунок 3.12 «Форма синхронизация данных с 1С»

При установке флажка напротив каждого из платежей вызывается форма «Распределение денег» (рисунок 3.13), в которой распределяются, в соответствии с выписанным счетом, оплаченное клиентом топливо по типам и по количеству литров.

Рисунок 3.13 «Форма распределение денег»

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

Рисунок 3.14 «Форма для работы с клиентами»

При вызове вкладки Отчеты - прочие, появляется форма «Общие отчеты по клиентам» (рисунок 3.15). Пользователь, задав временной диапазон, может сформировать необходимые для работы отчеты.

Рисунок 3.15 «Форма общие отчеты по клиентам»

4. Организационно - экономическая часть

4.1 Задание к организационно - экономической части дипломного проекта

Темой дипломного проекта является проектирование информационной системы по работе с клиентами на предприятии по реализации нефтепродуктов. Все работы по выполнению данного дипломного проекта происходили в помещении ЗАО «ННВП».

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

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

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

Талон на бензин - это уникальная (для нашего региона) форма оплаты за ГСМ. Талоны специального образца различаются по виду бензина и номиналу: А-76, Аи-92, Аи-95 по 20 литров, Дт по 40 литров каждый. Эта система имеет неоспоримые преимущества, что привлекает покупателей: цена бензина по талонам значительно ниже розничной цены на АЗС, цена фиксируется на момент оплаты, наличие талонов позволяет обходиться без наличных денег, дополнительная экономия за счет НДС, включенного в стоимость бензина в счетах-фактурах.

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

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

1) Ведение базы данных клиентов с банковскими реквизитами, юридическим и почтовым адресами для юридических лиц и Ф.И.О., паспортными данными для физических лиц:

ввод новой записи о покупателе;

редактирование записи;

удаление записи;

2) Ведение базы данных проданных бензиновых карт:

ввод новой записи в базу при продаже;

удаление записи при изъятии карты;

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

3) Ведение базы данных талонов:

- организация движения талонов внутри организации;

- организация выдачи талонов покупателю;

- учет погашенных талонов;

4) Получение информации:

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

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

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

В данном проекте широко используются последние разработки в области программирования.

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

Требования заказчика к законченному программному продукту:

- реализация клиент-серверной архитектуры;

- обеспечение взаимодействия;

- обеспечение взаимодействия с базой данных;

- интуитивно-понятный интерфейс;

- возможность генерации отчетов.

4.2 Актуальность разработки

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

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

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

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

4.3 Затраты на проектирование информационной системы

Затраты на основную заработную плату

Разработку ведет один постоянный инженер-программист ЗАО «ННВП», затраты по заработной плате указаны в таблице 4.1.

Таблица 4.1 - Затраты на заработную плату

Затраты на осн. заработную плату:

Значение

Единица измерения

Затраты на доп.зар.плату (15%)

3 000

руб

Инженер-программист

20 000

руб/мес

Срок выполнения

2

мес

Итого фонд осн. зар.платы

40 000

руб

Итого фонд доп. зар. платы

6 000

руб

ИТОГО

46 000

руб

Затраты на ЕСН

Ставка ЕСН составляет 26% от фонда основной заработной платы, из которых:

20% - отчисления в Федеральный бюджет;

2,9% - отчисления в Фонд социального страхования РФ;

1,1% - отчисления в Федеральный фонд обязательного медицинского страхования;

2,0% - отчисления в Территориальные фонды обязательного медицинского страхования.

Т.е. ЕСН составляет 10 400 руб.

Затраты на расходные материалы

Таблица 4.2 - Затраты на расходные материалы

№ п/п

Наименование материала

Расход,

шт.

Цена, руб./шт.

Сумма,

руб.

1

Бумага SvetoCopy 500л

2

210

420

2

Картридж для лазерного принтера

1

2 000

2 000

3

Вспомогательная литература

-

-

3000

Итого

5 420

Затраты на технологические и хозяйственные нужды

Затраты на технологические и хозяйственные нужды складываются из затрат:

- электроэнергия на технологические нужды;

- арендная плата за помещения;

- плата за телефон;

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

- амортизация мебели.

Затраты по электроэнергии на технологические нужды рассчитываются по формуле:

где М - мощность прибора, кВт;

k - коэффициент использования мощности;

- эффективное время работы (за 0,6 месяца), час;

C - стоимость 1 кВт*час энергии (С = 1,5 руб/ кВт*час).

Затраты на электроэнергию на технологические нужды сведены в таблицу 4.3.

Таблица 4.3 - Затраты на электроэнергию.

Наименование оборудования

М, кВТ

k

, час

, руб

Рабочая станция инженера программиста (вместе с монитором)

0,46

1

1 440

993,6

Сервер разработки (без монитора)

0,76

1

1 440

1 641,6

Итого

2 635,2

Итого затраты на электроэнергию составляют 2 635 рубле...


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

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