Автоматизированная система должна обеспечивать информационную совместимость с известными приложениями операционной системы Windows (MS Word, MS Excel, MS Access). Программная совместимость обеспечивается автоматически в связи с использованием программных средств, совместимость которых обеспечена конструктивно (на этапе их создания) - Delphi, Delphi Together Architect и т.д. Система реализуется на платформах MS Windows XP и СУБД MS SQL Server 2005.

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

Конфигурация компьютера:

процессор Pentium 4 - 1,8 GHz или более мощный;

рекомендуемый объем оперативной памяти 128 мегабайт (МБ) или более больший;

100 МБ свободного места на жестком диске;

монитор VGA;

клавиатура, мышь или совместимое указывающее устройство;

дисковод компакт-дисков, DVD-дисков или дисковод гибких дисков.

Программные требования:

Windows XP.

Глава 2. Проектирование автоматизированного рабочего места оператора валютно-обменных операций в режиме off-line

2.1 Выбор технологии и средств проектирования.

2.1.1 Изучение существующих технологий и выбор технологии проектирования

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

соответствие стандарту ISO12207;

гарантированное достижение целей разработки ИС в рамках бюджета с заданным качеством и в установленное время;

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

минимальное время получения работоспособного ПО;

независимость получаемых проектных решений от средств реализации ИС (под средствами понимаем СУБД, ОС и системы языков и систем программирования);

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

На сегодняшний день практически все ведущие компании-разработчики располагают развитыми технологиями создания программного обеспечения. Одна из технологий, претендующей на роль фактического стандарта, является технология RUP (компания Rational Soft Ware). RUP представляет собой программный продукт, разработанный компанией Rational и в значительной степени соответствующий стандартам и нормативным документам, связанными с процессами жизненного цикла ПО, и оценкой технологической зрелости организации разработчиков. Основные принципы RUP: итерационный и инкрементный подход к созданию ПО, планирование и управление проектом на основе функциональных требований к системе - вариантов использования. В соответствии с первым принципом разработка системы выполняется в виде нескольких краткосрочных мини-проектов фиксированной деятельности от 2 до 6 недель, соответственно называемых итерациями. Каждая итерация включает свои собственные этапы анализа требований, проектирования, реализации, тестирования, интеграции и завершается созданием рабочей системы. Итерационный цикл основывается на постоянном расширении и дополнении системы с периодической обратной связью и адаптации дополняемых модулей к ядру системы. Согласно RUP жизненный цикл ПО разбивается на отдельные циклы, в каждом из которых создаётся новое поколение продуктов. Каждый цикл в свою очередь разбивается на 4 стадии:

начальная стадия - inception;

стадия разработки - elaboration;

конструирования - construction;

ввод в действие - transition.

Рис 2.1 диаграмма процесса разработки системы.

Каждая стадия завершается в чётко определённой точке milestone. В этот момент времени должны достигаться важные результаты и приниматься критически важные решения для дальнейшей разработки. Во время начальной стадии вырабатывается бизнес-план проекта. Определяется приблизительная его стоимость, и какой доход принесет. Определяются границы проекта. На стадии разработки выявляются более детальные требования. Выполняется высокоуровневый анализ предметной области и проектирование для построения базовой архитектуры системы. создается бланк конструирования и устанавливаются наиболее рискованные элементы проекта. Результатом стадии конструирования является продукт. Готовый к передаче конечным пользователям. Как минимум он содержит следующее:

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

Назначением стадии ввода в действие является передача готового продукта в распоряжение пользователя.

Microsoft Solution Framework (MSF) представляет общую методологию разработки и внедрения решений в сфере информационных технологий. Последняя версия модели включает пять фаз: анализ, проектирование, разработка, стабилизация и внедрение, является итерационной, предполагает использование объектно-ориентированного моделирования. Принципы разработки приложений MSF - это набор моделей, принципов и методов, которые помогают организации более эффективно создавать и использовать информационные технологии для решения проблем бизнеса. Ядро этой системы составляют шесть основных моделей: модель производственной архитектуры; модель проектной группы; модель процесса разработки ПО; модель управления рисками; модель процесса проектирования; модель приложения. Модель процесса проектирования описывает трехфазный, ориентированный на конечного пользователя, непрерывный процесс разработки. Три фазы разработки - концептуальное, логическое и физическое проектирование. Компания «Microsoft» http://www.microsoft.com

Одним из уже сложившихся направлений деятельности фирмы ORACLE стала разработка методологических основ и производство инструментальных средств для автоматизации процессов разработки сложных прикладных систем, ориентированных на интенсивное использование баз данных. Методика Oracle COM является развитием давно разработанной версии Oracle CASE-Method, применяемой в CASE-средстве Oracle CASE. Основу CASE-технологии и инструментальной среды фирмы ORACLE составляют:

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

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

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

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

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

Жизненный цикл формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов. Методика Oracle CDM определяет следующие фазы жизненного цикла информационной системы:

стратегия;

анализ (формулирование детальных требований к прикладной системе); Q проектирование (преобразование требований в детальные спецификации системы);

реализация (написание и тестирование приложений);

внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);

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

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

Основные требования к выбираемой технологии проектирования:

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

выбранная технология должна отражать все этапы жизненного цикла проекта;

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

технология проектирования должна способствовать росту производительности труда проектировщика;

обеспечение надежности процесса проектирования и эксплуатации проекта.

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

Для выбора технологии проектирования будем использовать метод «бальных оценок». Самыми значимыми критериями отбора выбраны доступность; гибкость (отсутствие жестко навязываемых процедур); наличие объектно-ориентированного подхода; модульность (возможность использовать не всю технологию, а только отдельные его компоненты); удобство в применении. Рассмотрев технологии, были проставлены баллы по критериям отбора. Также для каждого критерия были определены их важности по пятибалльной шкале. Перемножив важность на значимость критерия в и суммировав их для каждой технологии, получаем итоговую оценку. Описание и результаты отбора технологии для проектирования ЭИС методом бальных оценок представлены в таблице 2.1:

Таблица 2.1 Выбор технологии проектирования.

Параметр Технология	Объектный подход 1	Гибкость 2	Модульность 3	Удобство в применении 4
RUP	5	5	5	5
MSF	4	4	3	4
Oracle	4	3	4	3
ЗНАЧИМОСТЬ в	5	3	4	2
* в
RUP	25	15	20	10
MSF	20	12	12	8
Oracle	20	9	16	6
?* в
RUP	70
MSF	52
Oracle	51

Таким образом, методом бальных оценок установлено, что наиболее подходящей технологией является RUP (Rational Unified Process).

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

2.1.2 Выбор средства проектирования

Для выбора средства проектирования будем использовать метод «бальных оценок». Основными критериями отбора выбраны: объектный подход, простота в обучении, поддержка UML, быстрота создания и изменения программ. Описание и результаты отбора средства для проектирования ЭИС методом бальных оценок представлены в таблице 2.1:

Таблица 2.2 Выбор средства проектирования.

Параметр

технология

Объектный подход 1

Простота в обучении 2

Поддержка UML 3

Быстрота создания и изменения диаграмм 4

Microsoft Visio

3

4

4

5

Borland Together Architect

5

5

5

4

ЗНАЧИМОСТЬ в

4

3

5

2

* в

Microsoft Visio

12

12

20

10

Borland Together Architect

20

15

25

8

?* в

Microsoft Visio

52

Borland Together

68

Методом бальных оценок установлено, что наиболее подходящее инструментальное средство разработки проекта - Borland Together Architect.

Borland Together - CASE-средство, предназначенное для визуального моделирования и проектирования программных систем на основе стандарта UML, позволяющее моделировать как компоненты программного обеспечения, так и бизнес-процессы. Borland Together обладает открытой архитектурой. Использование технологий Borland Together 2006 для проектирования и реализации IT - архитектуры значительно ускоряет процесс разработки приложений, начиная от определения требований и заканчивая написанием кода. Возможности Together обеспечивают синхронную работу разработчиков архитектур, аналитиков и программистов при создании новых приложений или в процессе извлечения проектной информации из существующих приложений, и обеспечивают общее визуальное представление об архитектуре модели. http://www.borland.com

Технологии Borland Together 2006 помогают:

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

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

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

2.2 Проектирование функциональной структуры

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

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

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

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

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

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

Рис 2.2 Диаграмма вариантов использования.

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

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

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

Рис. 2.3 Прием на экспертизу.

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

Рис. 2.4 Покупка валюты.

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

Рис. 2.5 Продажа валюты.

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

Рис. 2.6 Конверсия.

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

Рис. 2.7 Размен денежного знака.

Замена денежного знака - оператор принимает поврежденный денежный знак на инкассо. Для этого оператор проверяет документы клиента. Далее формирует квитанцию о приеме на инкассо и один экземпляр выдает клиенту.

Рис.2.8 Замена денежного знака.

2.3 Проектирование логической модели (построение диаграммы классов)

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

Рис 2.10 Диаграмма классов.

Описание:

Класс сотрудники:

Содержит следующие необходимые атрибуты: № трудового договора, ФИО, № и серия паспорта. В его полномочия входят следующие операции: сохранение записи в реестре валютно-обменных операций, то есть при совершении валютно-обменной операции ему каждый раз необходимо сохранять в реестре данные о совершаемой операции; формирование справки о проведении операции с наличной валютой и чеками; составление справки о приеме на экспертизу денежного знака; создание мемориального ордера, необходимо для обоснование бухгалтерской проводки; формирование квитанции о приеме на инкассо, в случае если денежный знак поврежден.

Класс реестр:

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

Класс общероссийский классификатор валют:

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

Класс мемориальный ордер:

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

Класс справка о проведенной операции с валютой и чеками:

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

Класс курсы (кросс-курсы):

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

Класс операции:

Атрибуты: код операции, наименование. Операции: добавить, сохранить, удалить.

Класс документы:

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

Класс клиент:

Его атрибуты: код, страна Гражданство, ФИО, документ, серия, номер, выдан, дата выдачи. С данным классом можно совершать следующие операции: добавить, изменить, сохранить.

Класс квитанция о приеме на инкассо:

Данный класс имеет следующие атрибуты: №, дата, ФИО, документ, удостоверяющий личность, №, серия, каким органом выдан, дата выдачи, адрес, дополнительные реквизиты (наименование, серия, номер, год эмиссии, для чеков: наименование, № дата, сумма, наименование эмитента, лицо, выдавшее чек), кассир. Его операциями являются: сохранить, печать.

Класс справка о приеме на экспертизу:

Атрибуты: №, дата, ФИО, адрес, документ, серия, номер, наименование валюты, страна эмитент, номинал, год образца (выпуска), серийный номер, дополнительные реквизиты, кассир. Операции: сохранить, печать.

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

Рис. 2.11 Диаграмма последовательности - прием денежного знака на экспертизу.

Рис. 2.12 Диаграмма последовательности - покупка/продажа валюты (а так же конверсия валюты).

Рис. 2.13 Диаграмма последовательности - замена денежного знака.

Рис. 2.14 Диаграмма последовательности - размен денежного знака.

2.4 Проектирование структуры базы данных

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

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

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

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

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

Первая нормальная форма требует, чтобы каждое поле таблицы БД было не делимым, не содержало повторяющихся групп. Не делимость поля означает, что каждое поле не должно делится на несколько полей. А повторяющиеся группы указывают на то, чтобы поля не содержали одинаковые по смыслу значения. Гофман В.Э., Хомоненко А.Д. - «Работа с базами данных в Delphi» - второе издание, СПб.: БХВ-Петербург, 2003 год Наш список полей удовлетворяет этому нормальному закону, кроме поля ФИО. Их можно разделить на три поля соответственного Фамилия, Имя и Отчество, но для задачи, которая поставлена перед нами, это не требуется, поэтому мы считаем эти поля не делимыми.

Вторая нормальная форма, требует: все поля таблицы зависели от первичного ключа, то есть первичный ключ однозначно определен и является не избыточным; те поля, которые зависят от части первичного ключа, должны быть выделены в отдельные таблицы. Гофман В.Э., Хомоненко А.Д. - «Работа с базами данных в Delphi» - второе издание, СПб.: БХВ-Петербург, 2003 год Определим поля, входящие в первичный ключ: № мемориального ордера, № операции, № справки, № трудового договора, идентификатор валюты, код операции, код, № квитанции, № справки на экспертизу, ID комиссии. Установим, какие поля зависят только от части ключа и поместим их в отдельную таблицу.

Третья нормальная форма требует, чтобы значение любого поля таблицы, не входящего в первичный ключ, не зависело от значения другого поля, не входящего в первичный ключ. Гофман В.Э., Хомоненко А.Д. - «Работа с базами данных в Delphi» - второе издание, СПб.: БХВ-Петербург, 2003 год

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

Таблица «operator» содержит данные о сотрудниках банка, то есть об операторе валютно-обменных операций. Ключевое поле: nomer_tr_dog, содержит информацию о номере трудового договора.

Таблица 2.3

Имя поля	Тип и размер поля	Описание поля
nomer_tr_dog	INTEGER	информация о номере трудового договора
FIO	VARCHAR(255)	фамилия, имя, отчество сотрудника банка.
Nomer_pas	INTEGER	номер паспорта

Таблица «reestr», содержит данные реестра валютно-обменных операций. Первичным ключом в данной таблице является nomer_oper. Это поле содержит информацию о номере операции.

Таблица 2.4

Имя поля	Тип и размер поля	Описание поля
nomer_oper	INTEGER	информация о номере операции
date	DATE	дата совершенной операции
Kod_vid_oper	INTEGER	код вида операции
ID_kyrs	INTEGER	Код курса
Kod_val_pr	INTEGER	код валюты принятой
Cymma_val_pr	MONEY	сумма валюты принятой
ID	INTEGER	код комиссии, взимаемая с клиента за совершение операции, обычно она входит в отклонение от курса
Doxod	MONEY	подоходный налог с совершенной операции
Kod_val_v	INTEGER	код валюты выданной
Cymma_val_v	MONEY	сумма валюты выданной
nomer_tr_dog	INTEGER	информация о номере трудового договора

Таблица «mem_or» содержит данные необходимые для обоснования бухгалтерской проводки. Ключевым полем является: nom_mem_or.

Таблица 2.5

Имя поля	Тип и размер поля	Описание поля
nom_mem_or	INTEGER	Номер мемориального ордера.
Vid_oper	VARCHAR(100)	Вид операции.
nomer_oper	INTEGER	информация о номере операции
Dt_sch	INTEGER	Дебет счета.
Kt_sch	INTEGER	Кредит счета.
Kod_val	INTEGER	Код валюты.
Cymma	MONEY	Сумма.
Country	VARCHAR(50)	Шифр страны.
Crok_val	DATE	Срок валютирования.
Ocnovanie	VARCHAR(255)	Содержание и основание записи.

Таблица «spr_oper», содержит данные выданных клиентам справок о проведении операции с наличной валютой и чеками. Ключевым полем таблицы является поле nom_spr.

Таблица 2.6

Имя поля	Тип и размер поля	Описание поля
nom_spr	INTEGER	Номер справки о проведении операции с наличной валютой и чеками.
Date	DATE	Дата проведения.
Time	DATE	Время проведения операции.
ID_kl	INTEGER	Идентификатор клиента.
Nomer_oper	INTEGER	Код вида операции.
Kyrs	INTEGER	Курс покупки продажи валюты (кросс-курс).
Kod_val_pr	INTEGER	Код валюты принятой.
Cymma_pr	MONEY	Сумма валюты принятой.
Name_val	VARCHAR(100)	Наименование валюты.
Kod_val_v	INTEGER	Код валюты выданной.
Cymma_val_v	MONEY	Сумма валюты выданной.
Name_val	VARCHAR(100)	Наименование валюты.
nomer_tr_dog	INTEGER	Информация о номере трудового договора.

Страницы: 1, 2, 3