46692 (Автоматизированное рабочее место оператора валютно-обменных операций в режиме off-line), страница 6
Описание файла
Документ из архива "Автоматизированное рабочее место оператора валютно-обменных операций в режиме off-line", который расположен в категории "". Всё это находится в предмете "информатика" из , которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "остальное", в предмете "информатика, программирование" в общих файлах.
Онлайн просмотр документа "46692"
Текст 6 страницы из документа "46692"
Таблица 2.7
| Имя поля | Тип и размер поля | Описание поля |
| ID_kl | INTEGER | Идентификатор клиента. |
| FIO | VARCHAR(100) | Фамилия, имя, отчество клиента. |
| Country_Gr | VARCHAR(100) | Страна Гражданство |
| ID_doc | INTEGER | Идентификатор типа документа. |
| Ceria_doc | INTEGER | Серия документа. |
| Nomer_doc | INTEGER | Номер документа. |
| Kem_v | VARCHAR(255) | Кем выдан документ. |
| Date_v | INTEGER | Дата выдачи. |
| Adres | VARCHAR(255) | Адрес клиента. |
Таблица «oper», содержит информацию о видах и кодах видов операций, является справочником. Ключевое поле: Kod_vid_oper.
Таблица 2.8
| Имя поля | Тип и размер поля | Описание поля |
| Kod_vid_oper | INTEGER | Код вида операции. |
| Name_oper | VARCHAR(100) | Наименование операции. |
Таблица «Doc», содержит информацию о видах документов удостоверяющих личность, то есть является справочником. Ключевым полем является: ID_doc.
Таблица 2.9
| Имя поля | Тип и размер поля | Описание поля |
| ID_doc | INTEGER | Идентификатор типа документа. |
| Doc | VARCHAR(100) | Документ удостоверяющий личность (тип документа). |
Таблица «kl_val» - общероссийский классификатор валюты. Ключевое поле: Kod_val.
Таблица 2.10
| Имя поля | Тип и размер поля | Описание поля |
| Kod_val | INTEGER | Код валюты. |
| Kod_val_b | VARCHAR(10) | Код валюты буквенный. |
| Name_val | VARCHAR(100) | Наименование валюты. |
| Country_v | VARCHAR(100) | Краткое наименование стран и территорий. |
Таблица «kyrs», содердит информацию о курсах покупки, продажи валюты (кросс-курсы). Ключевым полем таблицы является: Kod_val.
Таблица 2.11
| Имя поля | Тип и размер поля | Описание поля |
| ID_kyrs | INTEGER | Код курса |
| Kod_val | INTEGER | Код валюты. |
| Kod_val_b | VARCHAR(10) | Код валюты буквенный. |
| Status_Kyrs | INTEGER | Данный статус показывает курс покупки или курс продажи,определяется по коду операции. |
| Kyrs_prod | INTEGER | Курс продажи валюты. |
| Za_ed | INTEGER | За единицу. |
| Time | DATE | Время установки. |
| Date | DATE | Дата установки. |
| Status_naz | INTEGER | Статус принадлежности курса. Если равен 0 – то курс ЦБ, 1 – то банку, которому принадлежит обменный пункт. |
Таблица «spr_exsp», содержит данные выданных клиентам справок о приеме на экспертизу. Ключевое поле: nomer_spr.
Таблица 2.12
| Имя поля | Тип и размер поля | Описание поля |
| nomer_spr_ex | INTEGER | Номер справки о приеме на экспертизу. |
| Date | DATE | Дата выдачи справки о приеме на экспертизу. |
| ID_kl | INTEGER | Идентификатор клиента. |
| Name_val | VARCHAR(100) | Наименование валюты. |
| Country_v | VARCHAR(100) | Краткое наименование стран и территорий эмитентов. |
| nominal | INTEGER | Номинал денежного знака. |
| Year_v | DATE | Год образца (выпуска). |
| Ser_nomer | INTEGER | Серийный номер. |
| Dop_rec | VARCHAR(255) | Дополнительные реквизиты. |
| nomer_tr_dog | INTEGER | Информация о номере трудового договора. |
Таблица «kvit», содержит данные выданных клиентам квитанций о приеме на инкассо. Ключевое поле: nomer_kv.
Таблица 2.13
| Имя поля | Тип и размер поля | Описание поля |
| nomer_kv | INTEGER | Номер квитанции. |
| Date | DATE | Дата выдачи справки о приеме на экспертизу. |
| ID_kl | INTEGER | Идентификатор клиента. |
| Dop_rec | VARCHAR(255) | Дополнительные реквизиты. |
| nomer_tr_dog | INTEGER | Информация о номере трудового договора. |
Таблицы связаны между собой типом связи один-ко-многим через ключевые поля. Общий вид базы данных представлен на схеме:
Рис. 2.15 Схема базы данных.
2.5 Проектирование экранных форм
При создании экранных форм необходимо реализовывать доступность и простоту использования приложения. Одной из поставленных задач проектирования является задача: уменьшение времени обслуживания клиентов. Поэтому экранные формы должны отвечать следующим требованиям: простота, доступность. На основании поставленных задач реализована следующая иерархия форм:
Рис. 3.5 Иерархия экранных форм.
Глава 3. Реализация АРМ оператора валютно-обменных операций в режиме off-line
3.1 Выбор архитектуры
Существует четыре разновидности архитектур баз данных (БД): локальные, файл-серверные, клиент/сервер, многоярусные. Использование той или иной архитектуры накладывает сильный отпечаток на общую идеологию работы приложения, на программный код в приложении, на состав компонентов для работы с БД, используемых в приложении (прежде всего это касается не визуальных компонентов). Прежде, чем переходить к рассмотрению архитектур БД, отметим, что работа с данными в Delphi осуществляется с помощью утилиты администрирование источников данных ODBC, где осуществляется связь с источником, т.е выбирается провайдер данных и осуществляется связь с базой данных. Провайдером данных будет драйвер SQL Server. Подключение будет осуществляться к установленному серверу PENTIUM\SQLEXPRESS. При ходе настройки необходимо указать наименование базы, логин и пароль для аутентификации. В ходе установки сервера PENTIUM\SQLEXPRESS задается логин и пароль.
При работе с локальными базами данных сами БД расположены на том же компьютере, что и приложения, осуществляющие доступ к ним. Работа с БД происходит в однопользовательском режиме. ВDЕ распложена на компьютере пользователя. Приложение ответственно за поддержание целостности БД и за выполнение запросов к БД. При работе в архитектуре "файл-сервер" БД и приложение расположены на файловом сервере сети. Возможна многопользовательская работа с одной и той же БД. Каждый пользователь имеет на своем компьютере локальную копию данных, время от времени обновляемых из реальной БД, расположенной на сетевом сервере. При этом изменения, которые каждый пользователь вносит в БД, могут быть до определенного момента неизвестны другим пользователям, что делает актуальной задачу систематического обновления данных на компьютере пользователя из реальной БД. Другой актуальной задачей является блокирование записей, которые изменяются одним из пользователей; это необходимо для того, чтобы в это время другой пользователь не внес изменений в те же данные. Архитектура ''клиент-сервер'' разделяет функции приложения пользователя (называемого клиентом) и сервера. В многоярусной архитектуре наборы данных, бывшие ранее ''собственностью'' клиентских приложений, выделяются в отдельное звено, называемое сервером приложений. Модули данных в трехзвенной архитектуре "клиент-сервер" выделяются в отдельный "сервер приложении".
Данные, полученные на этапе проектирования, были проанализированы, в результате чего была составлена предварительная схема архитектуры будущей системы. В системе четко выделились две части: Клиент и Сервер. Данный вид архитектуры имеет название клиент-сервер. Клиент – это приложение пользователя. Для получения данных клиент формирует запрос и отсылает его удаленному серверу, на котором размещена БД. Запрос формулируется на языке SQL (Structured Query Language). Поэтому часто серверы БД называют SQL серверами. Таким образом, клиент посылает запрос на предоставление данных и получает только те данные, которые действительно были затребованы. Достоинства такой архитектуры:
снижение нагрузки сети,
повышение безопасности информации,
уменьшение сложности клиентских приложений.
Рис. 3.1 Архитектура клиент-сервер – двухзвенная.
В традиционных архитектурах клиент/сервер (двухзвенных архитектурах) взаимодействие клиентской программы и сервера баз данных происходит напрямую. При этом вся логика обработки данных делится между клиентскими программами и серверами баз данных. На серверах баз данных в основном производится первичная обработка данных с помощью механизма хранимых процедур, а вторичная (окончательная) обработка данных производится на клиентском рабочем месте, где также производится выдача данных и обработка запросов пользователя. При этом подходе при изменении структуры базы данных, сервера базы данных, порядка выполнения определенных операций над данными необходимо менять либо хранимые процедуры сервера, либо программы клиента.
3.2 Выбор средства реализации
При создании программного продукта одной из наиболее важных задач является выбор средств реализации проекта. Принятые на данном этапе решения могут повлиять на принцип работы создаваемого продукта в целом.
