Афонин П.Н. Информационные таможенные технологии

Подождите немного. Документ загружается.

различных фирм, файлы операционной системы, аппаратура (промышленные

контроллеры, кассовые аппараты). Инструментарий Oracle позволяет

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

обработки данных. Постепенно реляционная СУБД Oracle преобразуется в

объектно-ориентированную систему на основе языка SQL++, хранящую

данные в виде объектов вместо таблиц.

Для упорядочивания информации в таможенных БД используются

языки высокого уровня, для тонких запросов – Assembler. П ри это м в

качестве операци онной системы в ГНИВЦ ФТС используется Open VMS, а

для управления БД используются разработки Oracle.

5.1.2. Особенности баз данных, используемых в ФТС России

Объем центральной базы данных ФТС России составляет сотни

терабайт: это архивы оформляемых там оженн ых деклараций (более 2,5

млн документов в год, по несколько десятков килобайт каждый ) плюс

специализированные базы данных документов контроля доставки товаров

и транспортных средств, таможенных приходных ордеров, сертификатов и

нормативно-справочной информации, а также БД по участникам ВЭД.

Приказ ФТС России от 12 мая 2003 года №499 «О порядке сбора,

проведения форматно-логического контроля и передачи электронных

копий грузовых таможенных деклараций» утвердил:

1. Порядок сбора, проведения форматно-логического контроля и

передачи электронных копий грузовых таможенных деклараций на

всех уровнях системы таможенных органов в рамках Единой

автоматизированной информац ионн ой системы (ЕАИС ) ФТС России

2. Регламент сбора, форматно-логического контроля и передачи

электронных копий грузовых таможенных деклараций

3. План мероприятий по повышению достоверности информации в

центральной базе данных ЕАИС ФТС России

В табл. 5.1 приведен ряд новых терминов и определений, впервые

введенных Приказом №499 от 12 мая 2003 года.

Центральный элемент комплексной системы таможенного

оформления – база данных ГТД. Каж дый товар, при ходящий на грани цу,

имеет множество сопроводительных до кум ентов – накладные, контракт,

паспорт сделки, которая предваряет поставку, книжки перевозчиков и т. п.

Вся информация из этих документов сводится в один – грузовую

таможенную декларацию ; этот документ в настоящее время наиболее

важен в работе таможенных служб. В ГТД описывается сам товар, его

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

доставки и т. п. Форма этого документа вписана в структуру БД , и каждое

его поле имеет под собой информационну ю поддержку.

Формирование ГТД и ее использование включает несколько этапов.

При поступлении груза на границу таможенник проверяет

товаросопроводительные документы и формирует на их осн ове

электронный документ контроля доставки, который по электронной почте

направляется в таможню назначения этого груза, а точнее, в ее

вычислительный центр. Одно временно информация идет в центральную

базу данных ФТС, где проверяются сведения о юридическом или

физическом лице, которому предназначен данный груз.

Таможня назначения, получив груз, помещает его на склад временного

хранения и проверяет соответствие заявленных кодов, наименования,

объема и стоимости фактически поступившему товару, после чего

формирует ГТД и направляет ее в центральную БД, а товар вы пускает в

свободное обращение.

ГТД, появившись на таможне назначения, становится тем

документом, вокруг которого в дальнейшем проводятся все проверки, а

сведения, осевшие в БД грузовых таможенных деклараций, подвергаются

различной обработке (рис. 5.1). Помимо проверки правильности

оформления ГТД и при необходимости ее корректировки, центральная БД

ФТС России предусматривает возможности перекрестной проверки

данных ГТД и других специализированных документов, проведения

статистической обработки информации о поступивших в Россию товарах и

их объемах (для предоставления сведений экономическим и финансовым

ведомствам), а также функции "зеркальной статистики" – сопоставления

экспортных данных Евросоюза с информацией о реально поступивших в

Россию грузах.

Центральная база данных многократно продублирована: в

частности каждая региональная Б Д хранит всю информац ию, накопленную

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

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

любой момент восстановить информацию, если что случится с

центральной базой.

Доступ к центральной БД опосредован промежуточными Intel-

серверами. Сов ременн ые операционные системы позволяют

непосредственно работать с массивами информ ации , что предопределяет

возможность несанкционированного доступа к хранящейся информации.

Поэтому в ФТС прежде всего формализована специфика работы каждого

таможенного подразделени я, и сотрудники могут работать только с

определенными полями таможенных деклараций в соответствии со своими

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

работает с п олями "Стоимость", "Вес нетто", "Вес брутто", а также с

количеством наименований товаров. При этом сведения которые

запрашивает пользователь, выграж аются на промежуточный сервер, и

обратного хода нет. Таким образом, исходная и нфо рмаци я центральной БД

развязана с теми данными, которы е обрабатываются в повседневной

деятельности.

Таблица 5.1.

Термины, введенные Приказом ФТС от 12 мая 2003 года №499

Термин

Определение

"Зарегистрирован-

ные ГТД"

ГТД, принятые таможенным органом к таможенному

оформлению

"Оформленные ГТД"

ГТД, для которых в отношении товаров и транспортных средств

таможенным органом принято решение, регламентированное

нормативными актами ФТС России, о выпуске (условном

выпуске) в соответствии с условиями заявленного таможенного

режима или о запрете выпуска товаров.

"Протокол

завершения контроля

ГТД"

совокупность данных, содержащая разъяснение причин

завершения контроля электронной копии ГТД в случае

обнаружения расхождений между алгоритмами работы

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

форматно-логический контроль электронных копий ГТД, и

решениями, принятыми уполномоченным должностным лицом

таможенного органа, оформившего ГТД. Протокол завершения

контроля ГТД передается вместе с ГТД

"Тракт оперативного

мониторинга ГТД"

логическая совокупность:

а) работников и подразделений ГНИВЦ ФТС России,

должностных лиц таможенных органов и их подразделений;

б) программных и технических средств ЕАИС ФТС России и

ВИТС ФТС России, обеспечивающих обработку электронных

копий оформленных ГТД.

"Тракт оформленных

ГТД"

логическая совокупность:

а) работников и подразделений ГНИВЦ ФТС России,

должностных лиц таможенных органов и их подразделений;

б) программных и технических средств ЕАИС ФТС России и

ВИТС ФТС России, обеспечивающих обработку электронных

копий оформленных ГТД.

"Файл пакета

передачи данных

(ФППД)"

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

передачи средствами ВИТС ФТС России. Порядок формирования

и обработки ФППД определяется иными нормативными

правовыми актами ФТС России.

"Центральная база

данных ГТД (ЦБД

ГТД)"

раздел ЦБД ЕАИС ФТС России, предназначенный для хранения

электронных копий оформленных ГТД на уровне ФТС России.

"Центральная база

данных "Оператив-

ный мониторинг"

(ЦБД "Оперативный

мониторинг")

раздел ЦБД ЕАИС ФТС России, предназначенный для хранения

электронных копий ГТД, зарегистрированных в таможенных

органах.

"Центральная база

данных

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

загрузки"

раздел ЦБД ЕАИС ФТС России, содержащий электронные копии

оформленных ГТД, поступившие на уровень ФТС России,

подлежащие форматно-логическому контролю (далее - ФЛК) для

принятия решения о дальнейшей загрузке в ЦБД ГТД.

"Центральная база

данных Журналов

учета и регистрации

ГТД"

раздел ЦБД ЕАИС ФТС России, содержащая записи Журналов

учета и регистрации ГТД. Данная база формируется на уровне

ФТС России.

Рис. 5.1. Информационная система сбора и обработки информации

5.1.3. Распределенные технологии обработки и хранения данных

При использовании информационных сетевых технологий становится

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

информации.

Распределенная обработка данных позволила повысить эффектив ность

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

таможенного органа и тем самым обеспечить гибкость прин и маемых им

решений. Преимущества распределенной обработки данных: большое число

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

сбора, регистрации, хранен ия, передачи и выдачи информации; снятие

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

и хранения ло кальн ых баз данных на разных ЭВМ для обеспечение доступа

информационного работника к вычислительным ресурсам сети ЭВМ;

обеспечение симметричного обмена данными между удаленными

пользователями.

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

иерархические, сетевые и реляционные отразилось на архитектуре систем

управления базами данн ых (СУБД) и технологии их обрабо тки. Архитектура

РТУ, ГНИВЦ

ОБРАБОТКА

ИНФОРМАЦИИ

Принятие

решения

Иные

источники

Государственные

контрольны е

организации

Аналитика

ФТС России

Ориентировки

правоохранительных

структур

Перевозчик

декларант

ДКД (МДП), ГТД

Сотрудник

таможенного

органа

Рекомендации

Анализ

информации

Выбор формы

таможенного

контроля

Информация

Intranet

СУБД описывает ее функционирование как взаимодействие

информационных процессов двух типов: клиента и сервера.

Распределенная обработка и распределенная база данных не синонимы.

Если при распределенной обработке производится работа с базой, то

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

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

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

сервере. В случае использования распределенной базы данных последняя

размещается на нескольких серверах. Работа с ней осуществляется на тех же

персональных компьютерах или на других, и для доступа к удаленным

данным надо использовать сетевую СУБД.

В системе распределенной обработки клиент может послать запрос к

собственной локальной базе или удал енно й. Удаленный запрос – единичный

запрос к одному серверу. Неско лько удаленных запросов к одному серверу

объединяются в удаленную транзакцию. Если отдельные запросы

транзакции обрабатываются различными серверами, то транзакция

называется распределенной. При этом один запрос транзакции

обрабатывается одним сервером. Распределенная СУБ Д позволяет

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

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

концепцию распределенной базы данных.

Созданы распределенные базы данных по всем направлениям

человеческой деятельности: финансовой, экономической, научно-

технической, электронной документации, кредитной, статистической,

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

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

информационные технологии опираются на базы нормативно-справочной

информации.

ТЕМА 5.2. ИСПОЛЬЗОВАНИЕ В ФТС РОССИИ СИСТЕМ

ОРИЕНТИРОВАННЫХ НА АНАЛИЗ ДАННЫХ

При построении 1-й очереди ЕАИС акцент делался на классические

методы проектирования базы данных, то есть на системы, ориентированные

на обработку транзакций в реальном времени (On-Line Transaction Processing

– OLTP).

OLTP системы ориентиров аны на выполнение транзакций, и нфо рмация

в них носит оперативный характер. Записи в OLTP системах могут регулярно

добавляться, удаляться и редактироваться.

OLTP си стема выдает о тветы н а просты е воп росы типа "каков был

уровень импорта товара N в регионе M в январе 2004 года?). Т радицион ны е

системы OLTP оперируют такими понятиями, как сущность, связь,

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

В системах OLTP информация хранится в виде, пригодном для

детальной ревизии данных. Если пользователя ин тересует кредитный счет

экспортера, он должен получить подробную информацию о каждой

операции. С этим прекрасно справляется система OLTP, которая

обеспечивает строжайшую секретность и максимальную закрытость.

Неудивительно по этом у, что с помощью таких систем невозможно получить

ответ на аналитические вопросы типа "Будет ли получена от этого

прибыль?", "Какие клиенты наиболее выгодны с позиции таможенных

платежей и п очему?" или "Какие возможности в технологии валютного

контроля упускаются?".

В реляционных моделях связи отображаются явно. Понятие "сущность-

связь" составляет основу реляционной модели. Например, явное описание

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

реляционной БД.

К сожалению, размещаемая в базах данных OLTP-систем инфор маци я

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

Поэтому данные с разных информационных конвейеров отправляются (в

смысле, копиру ются) на "склады данны х", называемые "информационными

хранилищами данных".

5.2.1. Хранилища данных

Для получения интересующей их информации лица, принимающие

решение (ЛПР), или аналитики обращаются к СП ПР с запросами. Эти

запросы в большинстве случаев бо лее сложные, чем те, которые

применяются в системах операционной обработки данных, например, "Найти

среднее значение промежутка времени между выставлением счета и оплатой

его участником ВЭД в текущем и прошедшем году отдельно для разных

групп участников ВЭД".

В большинстве случаев сложный аналитический запрос невозможно

сформулировать в терминах языка SQL, по э то м у д л я получения и н ф о р мации

применяют специальные языки, ориентированные на аналитическую

обработку данных. К их числу можно, например, отнести язык Express 4GL

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

приложения, написанные специально для решения тех или иных задач.

Для того чтобы можно было извлекать полезную информацию из

данных, они должны быть организованы особы м образом. Связано это со

следующими факторами.

Во-первых, для выполнения аналитических запросов необходима

обработка больших информационных массивов. Чем выше степень

нормализации базы данных, и чем больше в ней таблиц, тем медленнее

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

увеличивается число операций соединения отношений. Н ормализация таблиц

БД позволяет уст ранить избыточность данных, уменьшив тем самым объем

действий, необходимых при обновлении информации. Поэтому в них нет

необходимости менять одни и те же значения в различных отношениях. В

аналитических системах данные практ ически не обновляются – в системе

производится лишь их накопление и чтение. Поэтому проблема

нормализации БД в них не столь актуальна.

Во-вторых, выполнение некоторых аналитических запросов, например,

анализ тенденций и прогнозирование, требует хроноло гической

упорядоченности данных. Ре ля ц и онная модель не предполагает

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

В третьих, при обслуживании аналитических запросов чаще

используются не детальные, а обобщенн ые (агрегированные данные). Так,

например, для прогнозирования объема импорта в некотором регионе будет

излишним иметь информацию о каждом пересекающим таможенную

границу контейнере, достаточно знать значение прогнозируемой величины за

несколько предыдущих лет.

Перечисленные особенности СППР привели к тому, что данные,

используемые для анализа, стали выделять в отдельные базы данных,

получивших название хранилищ данных (ХД).

Концепция информационных хранилищ данных (первоначально она так

и называлась Information WareHouse) зародилась в 80-х годах XX века в

недрах корпорации IBM. но все же "отцо м " технологии сч и та етс я Б и л л

Инмон, технический директор компании Prism.

5.2.2. Модели данных, используемые для хранилищ

Существует два основных подхода к построению хранилищ данных:

подход, основанный на многомерной модели БД, и подход, использующий

реляционную модель БД.

При использовании многомерной модели данные хранятся не в виде

плоских таблиц, как в реляционных БД, а в виде гиперкубов –

упорядоченных многомерных массивов. Такое представление является

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

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

Основные понятия многомерной модели – измерение и значение

(ячейка). Измерение – это множество, образую щее одну из граней гиперкуба

(аналог дом ена в реля цио нно й модели). Измерения играют роль индексов,

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

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

качественные данные, которые находятся в ячейках гиперкуба (рис. 5.2).

В многомерной модели вводятся следующие основные операции

манипулирования измерениями: 1) сечение; 2) вращение; 3) детализация; 4)

свертка.

При выполнении операции сечения формируется подмножество

гиперкуба, в котором значение одного или более измерений ф иксировано.

Например, если на рис. 37. зафиксировать значение измерения "Время"

равным "январь 1993 года", то получится двухмерная таблицу с информацией

о значениях всех параметров для всех субъектов РФ в январе 1993 года.

Операция вращения изменяет порядок представления измерений. Она

обычно применяется к двухмерным таблицам, обеспечивая представление их

в более удобной для восприятия форме. Если в исходной таблице по

горизонтали были расположены субъекты РФ, а по вертикали параметры

внешнеэкономической деятельности, то после операции вращения параметры

будут размещены по горизонтали, а названия субъектов РФ – по вертикали.

Рис. 5.2. Представление данн ы х в в ид е г и пе р ку ба :

1 – значение "Параметра М" для "Субъекта РФ 1" в январе 1993 г

Для выполнения операций свертки и детализац ии должна существовать

иерархия значений измерения, то есть некоторая подчиненность одних

значений другим. Например, 12 месяцев образуют год, субъекты РФ

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

измерения заменяется значением более высокого уровня иерархии.

Например, аналитик, узнав значения параметров для января 2004 года,

желает получить их значения за весь 2004 год. Чтобы это сделать,

необходимо выполнить операцию свертки. Операция детализации – это

операция, обратная свертке. Она обеспечивает переход от обобщенных к

детализированным данным.

Основой при построении хранилища данных может служить

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

эмулируется СУБД на логическом уровне. В отличие от многомерных

реляционные СУБД способны хранить огромны е объемы данных, однако они

проигрывают по скорости выполнения аналитических запросов.

При использовании реляционных СУБД для организации ХД данные

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

называемая радиальная схема. Другое ее название – "звезда". В этой схеме

используются два типа таблиц: таблица ф актов (фактологическая таблица) и

несколько справочных таблиц (таблицы измерений).

В таблице фактов обычно содержатся данные, наиболее интенсивно

используемые для анализа. Если проводить аналогию с многомерной

моделью, то запись фактологической таблицы соответствует ячейке

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

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

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

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

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

атрибутами.

На базе реляционных СУБД строятся системы аналитической обработки

данных ROLAP (Ralation On-Line Analytical Processing), служащие для связи

с системами принятия решен ий. В таких системах доставкой информации

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

данных в реальном врем ени (On-Line Analytical Processing), которые

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

средств генерации запросов и анализа результатов.

В OLAP системах ценность информации увеличив ается благодаря

применению разнообразных методов анализа и статистической обработки.

Кроме того, эти системы оптимизированы с точки зрения скорости

извлечения данных, сбора обобщенной информации и ориентированы на

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

Многомерный анализ данных, часто называемый системой

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

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

В настоящее время средства анализа данных использу ют базы данных ,

составляющие о снову OLAP-систем, позволяющ ие обслуживать сотни и

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

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

OLAP из системы Web или корпоративной сети Intranet.

Ситуация, когда для анализа необходима вся информация, находящаяся

в хранилище, возникает довольно редко. Обычно каждый аналитик или

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

организации, поэтому в первую очередь ему необходимы данные,

характеризующие именно это направление. Реальный объем этих данных не

превосходит ограничений, присущих многомерным СУБД. Возникает идея

выделить данные, которые реально нужны конкретным аналитическим

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

многомерной БД. Источником данных для него должно быть центральное

хранилище организации.

Если проводить аналогии с производством и реализацией продукции, то

многомерные БД выполняют роль мелких складов. В концепции ХД их

принято именовать витринами данных. Витрина данных – это

100

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

направлений деятельности организации. Логическая схема СППР,

использующей центральное ХД организации и киоски данн ых ан алити ческих

отделов, представлена на рис. 5.3.

Рис. 5.3. Логическая схема СП ПР, использую щей ХД и вит р ин ы д ан н ых

Такая схема позволяет эффективно использовать возможности

реляционных СУБД по хранению огромных объемов информации и

способность многомерных СУБД обеспечивать высокую скорость

выполнения аналитических запросов.

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

основе архитектуры клиент-сервер. Хранилище данных разм ещается н а

специальном сервере (сервере хранил ища данных). Для его реализации

используется мощные многопроцессорные вычислительные системы таких

производителей, как IBM, Hewlett-Packard, DEC, NCR. и др. В качестве

СУБД применяется одна из СУБД, поддерживающих параллельную

обработку запросов: Teradata (фирма NCR), DB/2 (фирма IBM), Oracle,

Informix и др. Витрины данных реали зую тс я с испол ьзов ани ем серве ров