Файл: Технология клиент-сервер (Описание клиент-серверной технологии).pdf
Добавлен: 28.06.2023
Просмотров: 142
Скачиваний: 3
Компонент TADOConnection вобрал возможности перечислителя, источника данных и сессии с возможностями обслуживания транзакций.
Четыре компонента наборов данных (ADODataSet, ADOTable, ADOQuery и ADOStoredProc) фактически полностью реализованы общим для них базовым классом TCustomADODataSet. Этот компонент несет ответственность за выполнение большинства функций, присущих набору данных. Производные компоненты являются тонкими оболочками, которые делают доступными для внешнего мира те или иные возможности базового компонента. Таким образом, компоненты обладают множеством общих черт.
Компоненты доступа к данным ADO могут использовать два варианта подключения к хранилищу данных. Это стандартный метод ADO и стандартный метод Delphi.
Каждый компонент, обращающийся к хранилищу данных ADO самостоятельно, задавая параметры соединения в свойстве Connectionstring, открывает собственное соединение. Чем больше приложение содержит компонентов ADO, тем больше соединений может быть открыто одновременно.
Поэтому целесообразно реализовать механизм соединения ADO через специальный компонент – TADOConnection. Этот компонент открывает соединение, также заданное свойством Connectionstring, и предоставляет разработчику дополнительные средства управления соединением.
Проектирование ИС учёта штрафов ГИБДД
Предметной областью данной разработки является учёт штрафов ГИБДД. От системы учёта штрафов потребуются следующие функции:
- учёт автотранспорта;
- учёт владельцев;
- ведение ПТС;
- учёт полицейских;
- ведение штрафов.
Потребуется хранить следующие данные:
- информацию о автотранспорте;
- информацию о владельце;
- информацию о ПТС;
- информацию о полицейских;
- информацию о выписанных штрафах.
К информации об автомобилях относится:
- номер;
- модель;
- марка;
- тип кузова;
- категория ТС;
- цвет;
- год выпуска.
Информация о владельце:
- Ф.И.О.;
- дата рождения;
- пол;
- паспортные данные;
- права;
- адрес;
- отметка о попадании в «чёрный список».
Информация о полицейском:
- Ф.И.О.;
- дата рождения;
- пол;
- личный номер;
- звание;
- должность;
- подразделение.
ПТС:
- владелец;
- транспортное средство;
- дата регистрации;
- отметка о снятии с учёта.
Штраф:
- информация о владельце и автотранспорте;
- информация о нарушении;
- дата выписки;
- информация о полицейском, выписавшим штраф;
- сумма штрафа;
- отметка об оплате;
- отметка об аннулировании штрафа.
Требуется учесть, что после двух месяцев неоплаты штрафа, владелец транспортного средства попадает в чёрный список. Штраф, аннулируется через 3 года после его выписки.
Требуется ввести следующие справочники для ускорения работы в системе:
- марка;
- модель;
- категория транспортного средства;
- цвет транспортного средства;
- тип кузова;
- звание;
- должность;
- подразделение;
- нарушение.
Система должна позволять составлять списки штрафов:
- штрафы по владельцу;
- штрафы по номеру транспортного средства;
- все неоплаченные штрафы на данный момент.
Модель работы ИС учёта штрафов ГИБДД
На рисунке 2.1 представлена контекстная диаграмма верхнего уровня, в которой показаны входные, выходные, управляющие потоки и ресурсы.
Рис.2.1. Контекстная модель верхнего уровня
Входящие потоки:
- информация об участниках;
- информация о ТС;
- информация о нарушениях.
Выходящие потоки:
- карта ТС;
- карта владельца;
- карта полицейского;
- ПТС;
- список всех неоплаченных штрафов;
- список неоплаченных штрафов по владельцу;
- список неоплаченных штрафов по номеру транспортного средства.
Управляющие потоки:
- ПДД;
- суммы штрафов.
Ресурсы:
- ИС учёта штрафов ГИБДД;
- инспектор.
На рисунке 2.2 представлена декомпозиция контекстной диаграммы верхнего уровня. Включает в себя следующие процессы:
- учёт ТС и владельцев;
- учёт полицейских;
- ведение штрафов;
- формирование списков.
Рис 2.2. Декомпозиция контекстной диаграммы верхнего уровня
Рассмотрим подробнее процесс учёта ТС и владельцев, он включает в себя:
- учёт ТС;
- учёт владельцев;
- формирование ПТС.
Рис. 2.3. Декомпозиция процесса учёта ТС и владельцев
База данных ИС учёта штрафов ГИББ включает следующие таблицы:
- владелец;
- автомобиль;
- ПТС;
- полицейский;
- штраф;
- марка;
- модель;
- категорияТС;
- кузов;
- цвет;
- звание;
- должность;
- подразделение;
- нарушение;
- пользователь.
В таблицах 2.1 – 2.15 представлено описание таблиц БД.
Таблица 2.1
Владелец
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
ФИО |
varchar |
50, not null |
|
ДР |
Datetime |
|
|
Пол |
char |
1 |
|
Паспорт |
Varchar |
70, not null |
|
Права |
Varchar |
50 |
|
Адрес |
Varchar |
100 |
|
ЧС |
bit |
Таблица 2.2
Автомобиль
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
Номер |
Varchar |
10, not null |
|
Марка |
Int |
FK |
|
Модель |
Int |
FK |
|
КатегорияТС |
Int |
FK |
|
Кузов |
Int |
FK |
|
Цвет |
Int |
FK |
|
ГодВыпуска |
Int |
Таблица 2.3
ПТС
|
Поле |
Тип |
Ограничение |
|
Код |
Int |
PK |
|
Автомобиль |
Int |
FK, not nulle |
|
Владелец |
Int |
FK, not null |
|
Зарегистрирован |
Datetime |
|
|
Снят |
bit |
Таблица 2.4
Полицейский
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
ФИО |
Varchar |
50, not null |
|
ДР |
Datetime |
|
|
Пол |
Char |
1 |
|
Номер |
Varchar |
10, not null |
|
Звание |
Int |
FK |
|
Должность |
Int |
FK |
|
Подразделение |
Int |
FK |
Таблица 2.5
Штраф
|
Поле |
Тип |
Ограничение |
|
Код |
Int |
PK |
|
ПТС |
Int |
FK, not null |
|
Полицейский |
Int |
FK |
|
Выписан |
Datetime |
Not null |
|
Нарушение |
Int |
FK, not null |
|
Сумма |
Money |
Not null |
|
Оплачен |
bit |
|
|
Аннулирован |
bit |
Таблица 2.6
Нарушение
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
Название |
varchar |
50, not null |
|
Сумма |
money |
Таблица 2.7
Марка
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
Название |
varchar |
50, not null |
Таблица 2.8
Модель
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
Название |
varchar |
50, not null |
|
Марка |
int |
FK, not null |
Таблица 2.9
Кузов
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
Название |
varchar |
50, not null |
Таблица 2.10
КатегорияТС
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
Название |
varchar |
50, not null |
Таблица 2.11
Цвет
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
Название |
varchar |
50, not null |
Таблица 2.12
Звание
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
Название |
varchar |
50, not null |
Таблица 2.13
Должность
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
Название |
varchar |
50, not null |
Таблица 2.14
Подразделение
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
Название |
varchar |
50, not null |
Таблица 2.15
Владелец
|
Поле |
Тип |
Ограничение |
|
Код |
int |
PK |
|
Имя |
Varchar |
20 |
|
Пароль |
Varchar |
15 |
|
Инспектор |
Bit |
|
|
Администратор |
bit |
На рисунке 2.4 представлена схема данных.
Рис. 2.4. Схема данных
Разработка ИС учёта штрафов ГИБДД
Общие сведения (сценарий диалога и дерево функций)
Рассмотрим сценарий диалога проектируемой ИС учёта штрафов ГИБДД – рисунок 3.1.
Рис. 3.1. Сценарий диалога ИС учёта штрафов
Главное меню содержит следующие пункты:
Основное:
- Автотранспорт;
- Владельцы;
- Полицейские;
- Проверка штрафов.
Справочники:
- Марка и модель;
- Цвет;
- Категория ТС;
- Тип кузова;
- Звание;
- Должность;
- Подразделение.
Настройка:
- Подключение к БД;
- Пользователи.
Построим дерево функций ИС учёта штрафов ГИБДД – рисунок 3.2.
Рис. 3.2. Дерево функций ИС учёта штрафов ГИБДД
Основные функции:
- учёт автотранспорта;
- учёт владельцев;
- учёт полицейских;
- ведение ПТС;
- ведение штрафов.
Служебные функции:
- ведение справочников;
- настройка подключения к БД;
- проверка штрафов;
- проверка прав пользователя.
Разработка запросов к базе данных
Для формирования списков:
- список неоплаченных штрафов по владельцу;
- список неоплаченных штрафов по номеру автотранспорта;
- список всех неоплаченных штрафов.
Для формирования списка неоплаченных штрафов по владельцу разработан следующий запрос:
«Select
Штраф.Код
,Владелец.ФИО AS [Владелец]
,Автомобиль.Номер+' '+Марка.Название+' '+Модель.Название AS [Автомобиль]
,Полицейский.ФИО AS [Выписал]
,Нарушение.Название AS [Нарушение]
,Штраф.Выписан AS [Дата выписки]
,Штраф.Сумма AS [Сумма]
FROM Штраф
INNER JOIN ПТС ON ПТС.Код=Штраф.ПТС
INNER JOIN Владелец ON Владелец.Код=ПТС.Владелец
INNER JOIN Автомобиль ON Автомобиль.Код=ПТС.Автомобиль
INNER JOIN Марка ON Марка.Код=Автомобиль.Марка
INNER JOIN Модель ON Модель.Код=Автомобиль.Модель
INNER JOIN Полицейский ON Полицейский.Код=Штраф.Полицейский
INNER JOIN Нарушение ON Нарушение.Код=Штраф.Нарушение
WHERE (ISNULL(Штраф.Аннулирован,0)=0) AND (ISNULL(Штраф.Оплачен,0)=0) AND (Владелец.ФИО LIKE '')».
Для формирования списка неоплаченных штрафов по номеру автотранспорта разработан следующий запрос:
«Select
Штраф.Код
,Владелец.ФИО AS [Владелец]
,Автомобиль.Номер+' '+Марка.Название+' '+Модель.Название AS [Автомобиль]