Разработка
информационной системы АЗС с использованием клиент-серверной технологии
План
Введение
. Проектирование информационной системы
.1 Проектирование информационного обеспечения
.1.1 Выбор СУБД
.1.2 Системный анализ предметной области
.1.3 Инфологическое проектирование БД
.1.4 Даталогическое проектирование БД
.2 Проектирование программного обеспечения
.2.1 Выбор инструментальных средств для создания ПО
.2.2 Определение задач решаемых информационной системой
. Разработка информационной системы
.1 Разработка информационного обеспечения
.1.1 Физическое проектирование БД
.1.2 Программирование на стороне SQL-сервера
.2 Разработка программного обеспечения
.2.1 Создание Win-приложения
. Тестирование информационной системы
.1 Пользовательский интерфейс
.1.1 Интерфейс Win-приложения
Заключение
Список использованных источников
Приложение
Введение
Целью выполнения курсовой работы является разработка информационной системы АЗС с использованием клиент-серверной технологии. Для выполнения поставленной цели были определены следующие задачи:
· проектирование физической и логической моделей удаленной базы данных;
· разработка базы данных в СУБД Firebird с помощью утилиты IBExpert;
· создание клиентского приложения для Windows с использованием клиент-серверной технологии в инструментальной среде разработки C++ Builder;
Курсовая работа состоит из следующих глав:
Первая глава посвящена выбору программного обеспечения и системному анализу предметной области.
Во второй главе описана разработка программного обеспечения, в которой будут представлены фрагменты создания приложения.
В третьей главе показан пользовательский интерфейс при работе с win-приложением, а так же и само тестирование разработанного клиент-серверного приложения.
Данная курсовая работа состоит из 41 страницы, 50 рисунков, 2 таблиц, 4 литературных источников и 8 приложений.
1. Проектирование информационной системы
.1 Проектирование информационного обеспечения
база данные клиент серверный
1.1.1 Выбор СУБД
Выбор системы управления баз данных (СУБД) представляет собой сложную многопараметрическую задачу и является одним из важных этапов при разработке приложений баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия. Сама система управления баз данных(СУБД) является программным обеспечением, с помощью которого пользователи могут определять, создавать, поддерживать БД, получать к ней контролируемый доступ.
Для разработки информационной системы Автозаправочной станции (АЗС) с использованием клиент-серверной технологии выбрана СУБД - FireBird. Данная система управления баз данных достаточно компактная реляционная система с архитектурой клиент-сервер. Она может выполняться на разнообразных серверных и клиентских платформах, таких как Windows, Linux и на некоторых других платформах UNIX, включая Mac OS X.
Для управления базой данных сервер FireВird
использует домены, просмотры, хранимые процедуры, триггеры, генераторы,
транзакции, а также пользовательские функции. Для работы с FireBird была выбрана
утилита IBExpert, которая позволяет не только полностью управлять структурами
баз данных, но также создавать механизмы управления базой данных и отлаживать
их.
.1.2 Системный анализ предметной области
В рамках выполнения курсовой работы спроектирована и создана автоматизированная система с базой данных автозаправочной станции. С помощью готовой системы можно будет:
· осуществлять добавление, изменение и удаление данных из созданных таблиц;
· просматривать данные о клиентах, дисконтных карт клиентов, заправщиках, покупке топлива клиентами, типе топлива;
· осуществлять поиск, фильтрацию и сортировку данных для более удобного представления их пользователю.
Таким образом, система будет обеспечивать
возможность добавления, изменения и удаления данных в базе и иметь удобный
интерфейс для работы пользователей.
.1.3 Инфологическое проектирование БД и Даталогическое проектирование БД
Цель инфологического этапа проектирования состоит в получении семантических моделей, отражающих предметную область и информационные потребности пользователей. В качестве инструмента для построения семантических моделей данных на этапе инфологического проектирования является неформальная модель "Сущность-Связь" (Entity-Relationship). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов.
В процессе системного анализа предметной области определено пять сущностей, каждая из которых содержит непосредственно собственные характеристики, то есть атрибуты сущности. У каждой сущности выделен ключевой атрибут.
Таким образом, на этапе инфологического проектирования была создана модель «сущность - связь» («Entity-Relationship») будущей базы данных, представленная на рисунке 1.
Рисунок 1 - Логическая ER-модель
АЗС
Даталогическое проектирование является проектированием логической структуры БД, что означает определение всех информационных единиц и связей между ними, задание их имен и типов, а также некоторых количественных характеристик (например, длины поля).
При проектировании логической структуры БД, осуществляется преобразование исходной инфологической модели в модель данных, поддерживаемую конкретной СУБД, и проверка адекватности полученной даталогической модели отображаемой предметной области.
Даталогическая модель - это набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние (вторичные) ключи.
В реляционных БД даталогическое или логическое
проектирование приводит к разработке схемы БД, то есть совокупности схем
отношений, которые адекватно моделируют абстрактные объекты предметной области
и семантические связи между этими объектами. Основой анализа корректности схемы
являются так называемые функциональные зависимости между атрибутами БД.
Некоторые зависимости между атрибутами отношений являются нежелательными из-за
побочных эффектов и аномалий, которые они вызывают при модификации БД. При этом
под процессом модификации БД мы понимаем внесение новых данных в БД или удаление
некоторых данных из БД, а также обновление значений некоторых атрибутов.
1.2 Проектирование программного обеспечения
.2.1 Выбор инструментальных средств для создания ПО
Для создания удаленной базы данных была
использована утилита IBExpert. Она обладает множеством облегчающих работу
компонентов: визуальный редактор для всех объектов базы данных, редактор SQL и
исполнитель скриптов, отладчик для хранимых процедур и триггеров, построитель
области, инструмент для импорта данных из различных источников, собственный
скриптовый язык, а также дизайнер баз данных и т. д. Так же IBExpert является
инструментом для администрирования баз данных InterBase и Firebird. В качестве
сервера базы данных был выбран Firebird. Он может обрабатывать несколько сотен
независимых баз данных, каждую с множеством пользовательских соединений. Он
является полностью свободным от лицензионных отчислений даже для коммерческого
использования. Таким образом, с помощью вышеперечисленных программных продуктов
было разработано приложение в системе Borland C++ Builder 6.0. Данная система
используется программистами для разработки программного обеспечения на языке
C++, так же она поддерживает работу с базами данных под управлением Firebird.
Разработанное приложение будет позволять производить пользователю
администрирование удаленной базы данных «Автозаправочная станция».
.2.2 Определение задач, решаемых информационной системой
В соответствии с темой курсовой работы, разработанные приложения должны обеспечивать администрирование удаленной базы данных и управление данными этой базы с помощью клиент-серверной технологии.
Используя созданные приложения, пользователю
можно будет просматривать данные о клиентах, заправщиках, типе топлива и его
цене, покупке топлива тем или иным клиентом, дисконтных картах клиентов. А так
же будет возможность добавлять, изменять и удалять данные, осуществлять
сортировку, фильтрацию и поиск информации по всей удаленной базе данных.
2. Разработка информационной системы
2.1 Разработка информационного обеспечения
2.1.1 Физическое проектирование БД
Физическое проектирование базы данных - процесс
подготовки описания реализации базы данных на вторичных запоминающих
устройствах; на этом этапе рассматриваются основные отношения, организация
файлов и индексов, предназначенных для обеспечения эффективного доступа к
данным, а также все связанные с этим ограничения целостности и средства защиты.
Физическое проектирование является третьим и последним этапом создания проекта
базы данных, при выполнении которого проектировщик принимает решения о способах
реализации разрабатываемой базы данных. Приступая к физическому проектированию
базы данных, прежде всего необходимо выбрать конкретную целевую СУБД. Поэтому
физическое проектирование неразрывно связано с конкретной СУБД. Как правило,
основной целью физического проектирования базы данных является описание способа
физической реализации логического проекта базы данных.
Рисунок 2 - Физическая ER-модель
Программирование на стороне SQL-сервера
Рисунок 3 - Создание базы данных
Следующим этапом осуществлялась регистрация БД, с использованием FireBird версии 2.1, процесс регистрации показан на рисунке 4.
Таким образом, после создания и регистрации базы
данных, была построена таблица доменов, которые в будущем будут использоваться
в качестве типов данных. В таблице 1 представлены домены , которые
предварительно были записаны, с их типом данных , длиной и именем домена.
Рисунок 4 - Регистрация базы данных
Таблица 1 - Домены
|
Имя таблицы |
Имя поля |
Тип |
Длина |
Десятичная часть |
Имя домена |
|
|
FUEL |
TYPE_FUEL |
VARCHAR |
30 |
|
D_NAME |
|
|
|
PRICE |
NUMERIC |
6 |
|
D_PRICE |
|
|
CARD_CLIENTS |
NAME_CARD |
VARCHAR |
30 |
|
D_NAME |
|
|
|
DISCOUNT |
INTEGER |
|
|
D_INT |
|
|
CLIENTS |
ID_CLIENTS |
SMALLINT |
|
|
D_INDEXTYPE |
|
|
|
NAME |
VARCHAR |
30 |
|
D_NAME |
|
|
|
SURNAME |
VARCHAR |
30 |
|
D_NAME |
|
|
|
MIDDLE_NAME |
VARCHAR |
30 |
|
D_NAME |
|
|
|
PHONE |
INTEGER |
|
|
D_INT |
|
|
|
NAME_CARD |
VARCHAR |
30 |
|
D_NAME |
|
|
REFILL |
ID_REFILL |
SMALLINT |
|
|
D_INDEXTYPE |
|
|
|
DATE |
DATE |
|
|
D_DATE |
|
|
|
FUELED_LITERS |
FLOAT |
|
|
D_FLOAT |
|
|
|
CLIENTS_ID |
SMALLINT |
|
|
D_INDEXTYPE |
|
|
|
PERSONNEL_ID |
SMALLINT |
|
|
D_INDEXTYPE |
|
|
|
TYPE_FUEL |
30 |
|
D_NAME |
||
|
PERSONNEL |
ID_PERSONNEL |
SMALLINT |
|
|
D_INDEXTYPE |
|
|
|
NAME |
VARCHAR |
30 |
|
D_NAME |
|
|
|
SURNAME |
VARCHAR |
30 |
|
D_NAME |
|
|
|
MIDDLE_NAME |
VARCHAR |
30 |
|
D_NAME |
|
|
|
ADRESS |
VARCHAR |
30 |
|
D_NAME |
|
Для создания домена D_INDEXTYPE,
который будет использоваться для всех полей которые содержат уникальные номера.
На рисунке 5 представлен фрагмент создания домена D_INDEXTYPE
написанный в SQL Редакторе.
Рисунок 5 - Создание домена
Создание остальных доменов описанных выше в таблице 1 осуществлены аналогичным способом. Таким образом , на рисунке 6 приведен список всех созданных доменов.
Рисунок 6 - Список созданных доменов
Первоначальным этапом создания таблиц БД, был
определен порядок создания таблиц, так как в БД существуют как первичные так и
вторичные ключи. Первыми созданными таблицами являлись «Fuel»
- Топливо, «Personnel»
- Заправщики и «Card_clients»
- Дисконтные карты клиентов, так как в этих таблицах отсутствуют вторичные
ключи. Далее после выполненных операций перечисленных выше, осуществлялось
создание самих таблиц. Для создания таблицs
в БД , был открыт SQL
редактор, на рисунке 8 показан фрагмент написания запроса на создание таблицы
Топливо(FUEL).
Рисунок 7 - Создание таблицы
На рисунке 8 представлен результат создания
таблицы «FUEL».
Рисунок 8 - Результат создания таблицы «FUEL»
Остальные две таблицы создавались аналогичным образом. Следующей по порядку таблицей , для реализации, являлась таблица «Personnel». На рисунке 9 приведен результат создания таблицы «Personnel».
Рисунок 9 - Результат создания таблицы «Personnel»
Результат создания таблицы «Card_clients»
показан на рисунке 10.
Рисунок 10 - Результат создания таблицы «Card_clients»
Далее было осуществлено создание таблиц , в
которых имеются вторичные ключи. Такими таблицами являются «Clients»
- Клиенты и «Refill» - Покупка
топлива. Создание таблицы Клиенты, в котором используется внешний ключ, взятый
из таблицы Карты клиентов, а именно поле - «Название карты»(NAME_CARD),
рис 11.
Рисунок 11 - SQL
запрос
Результат создания таблицы «Clients»
приведен на рисунке 12.
Рисунок 12 - Результат создания таблицы «Card_clients»
Аналогичным образом создавалась таблица «Refill».
в которой использовались 3 внешних ключа с разных таблиц. Результат создания
таблицы «Refill» приведен
на рисунке 13.
Рисунок 13 - Результат создания таблицы «Refill»
На рисунке 14, представлен список созданных
таблиц.
Рисунок 14 - Список созданных таблиц