- •Лекция 3 Принципы построения еаис. Требования к еаис
- •Программное обеспечение еаис. Взаимодействие между программными компонентами еаис фтс России
- •Лингвистическое обеспечение еаис
- •Лекция 4 базы информационных данных еаис.
- •Регламент сбора, форматно-логического контроля и передачи электронных копий грузовых таможенных деклараций
- •План мероприятий по повышению достоверности информации в центральной базе данных еаис гтк России
- •Модели данных, используемые для хранилищ
- •"Аист м"
- •АрМы участников вэд
- •Понятие и структура информационной безопасности
- •Формы обеспечения информационной безопасности еаис
Порядок сбора, проведения форматно-логического контроля и передачи электронных копий грузовых таможенных деклараций на всех уровнях системы таможенных органов в рамках Единой автоматизированной информационной системы (ЕАИС) ГТК России
Регламент сбора, форматно-логического контроля и передачи электронных копий грузовых таможенных деклараций
План мероприятий по повышению достоверности информации в центральной базе данных еаис гтк России
В таблице приведен ряд новых терминов и определений, впервые введенных Приказом №499 от 12 мая 2003 года.
Центральный элемент комплексной системы таможенного оформления - база данных ГТД. Каждый товар, приходящий на границу, имеет множество сопроводительных документов - накладные, контракт, паспорт сделки, которая предваряет поставку, книжки перевозчиков и т. п. Вся информация из этих документов сводится в один - грузовую таможенную декларацию; этот документ в настоящее время наиболее важен в работе таможенных служб. В ГТД описывается сам товар, его отправитель, получатель, указывается таможенная стоимость, вес, способ доставки и т. п. Форма этого документа вписана в структуру БД, и каждое его поле имеет под собой информационную поддержку.
Формирование ГТД и ее использование включает несколько этапов. При поступлении груза на границу таможенник проверяет товаросопроводительные документы и формирует на их основе электронный документ контроля доставки, который по электронной почте направляется в таможню назначения этого груза, а точнее, в ее вычислительный центр. Одновременно информация идет в центральную базу данных ФТС, где проверяются сведения о юридическом или физическом лице, которому предназначен данный груз.
Таможня назначения, получив груз, помещает его на склад временного хранения и проверяет соответствие заявленных кодов, наименования, объема и стоимости фактически поступившему товару, после чего формирует ГТД и направляет ее в центральную БД, а товар выпускает в свободное обращение.
ГТД, появившись на таможне назначения, становится тем документом, вокруг которого в дальнейшем проводятся все проверки, а сведения, осевшие в БД грузовых таможенных деклараций, подвергаются различной обработке. Помимо проверки правильности оформления ГТД и при необходимости ее корректировки, центральная БД ФТС России предусматривает возможности перекрестной проверки данных ГТД и других специализированных документов, проведения статистической обработки информации о поступивших в Россию товарах и их объемах (для предоставления сведений экономическим и финансовым ведомствам), а также функции "зеркальной статистики" - сопоставления экспортных данных Евросоюза с информацией о реально поступивших в Россию грузах.
Центральная база данных многократно продублирована: в частности каждая региональная БД хранит всю информацию, накопленную РТУ за все время работы, и каждая таможня имеет полную информацию о своей деятельности. Такое многоуровневое резервирование позволяет в любой момент восстановить информацию, если что случится с центральной базой.
Доступ к центральной БД опосредован промежуточными Intel-серверами. Современные операционные системы позволяют непосредственно работать с массивами информации, что предопределяет возможность несанкционированного доступа к хранящейся информации. Поэтому в ФТС прежде всего формализована специфика работы каждого таможенного подразделения, и сотрудники могут работать только с определенными полями таможенных деклараций в соответствии со своими задачами. Например, управление контроля таможенной стоимости работает с полями "Стоимость", "Вес нетто", "Вес брутто", а также с количеством наименований товаров. При этом сведения которые запрашивает пользователь, вы-гражаются на промежуточный сервер, и обратного хода нет. Таким образом, исходная информация центральной БД развязана с теми данными, которые обрабатываются в повседневной деятельности.
Термины, введенные приказом ГТК России от 12 мая 2003 года №499
Распределенная обработка и распределенная база данных не синонимы. Если при распределенной обработке производится работа с базой, то подразумевается, что представление данных, их содержательная обработка, работа с базой на логическом уровне выполняются на персональном компьютере клиента, а поддержание базы в актуальном состоянии на сервере. В случае использования распределенной базы данных последняя размещается на нескольких серверах. Работа с ней осуществляется на тех же персональных компьютерах или на других, и для доступа к удаленным данным надо использовать сетевую СУБД.
В системе распределенной обработки клиент может послать запрос к собственной локальной базе или удаленной.
Удаленный запрос - единичный запрос к одному серверу. Несколько удаленных запросов к одному серверу объединяются в удаленную транзакцию. Если отдельные запросы транзакции обрабатываются различными серверами, то транзакция называется распределенной. При этом один запрос транзакции обрабатывается одним сервером. Распределенная СУБД позволяет обрабатывать один запрос несколькими серверами. Такой запрос называется распределенным. Только обработка распределенного запроса поддерживает концепцию распределенной базы данных.
Таможенные информационные технологии опираются на базы нормативно-справочной информации.
ИСПОЛЬЗОВАНИЕ В ФТС РОССИИ СИСТЕМ ОРИЕНТИРОВАННЫХ НА АНАЛИЗ ДАННЫХ
При построении 1-й очереди ЕАИС акцент делался на классические методы проектирования базы данных, то есть на системы, ориентированные на обработку транзакций в реальном времени (On-Line Transaction Processing- OLTP)
Система выдает ответы на простые вопросы типа "каков был уровень импорта товара N в регионе М в январе 2004 года?). Традиционные системы OLTP оперируют такими понятиями, как сущность, связь, функциональная декомпозиция и анализ изменения состояний.
В системах OLTP информация хранится в виде, пригодном для детальной ревизии данных. Если пользователя интересует кредитный счет экспортера, он должен получить подробную информацию о каждой операции. С этим прекрасно справляется система OLTP, которая обеспечивает строжайшую секретность и максимальную закрытость. Неудивительно поэтому, что с помощью таких систем невозможно получить ответ на анали тические вопросы типа "Будет ли получена от этого прибыль?", "Какие клиенты наиболее выгодны с позиции таможенных платежей и почему?" или "Какие возможности в технологии валютного контроля упускаются?".
В реляционных моделях связи отображаются явно. Понятие "сущность-связь" составляет основу реляционной модели. Например, явное описание связи между потребителями и заказами закладывается в саму конструкцию реляционной БД.
К сожалению, размещаемая в базах данных OLTP - систем информация мало пригодна для глобального прогнозирования состояния системы. Поэтому данные с разных информационных конвейеров отправляются (в смысле, копируются) па "склады данных", называемые "информационными хранилищами данных".
Хранилища данных
Для получения интересующей их информации лица, принимающие решение (ЛПР), или аналитики обращаются к СППР с запросами. Эти запросы в большинстве случаев более сложные, чем те, которые применяются в системах операционной обработки данных, например, "Найти среднее значение промежутка времени между выставлением счета и оплатой его участником ВЭД в текущем и прошедшем году отдельно для разных групп участников ВЭД".
В большинстве случаев сложный аналитический запрос невозможно сформулировать в терминах языка SQL, поэтому для получения информации применяют специальные языки, ориентированные на аналитическую обработку данных. К их числу можно, например, отнести язык Ехрress 4GL фирмы Огас1е. Также для выполнения запросов могут быть использованы приложения, написанные специально для решения тех или иных задач.
Для того чтобы можно было извлекать полезную информацию из данных, они должны быть организованы особым образом. Связано это со следующими факторами.
Во-первых, для выполнения аналитических запросов необходима обработка больших информационных массивов. Чем выше степень нормализации базы данных, и чем больше в ней таблиц, тем медленнее выполняется анализ. Происходит это прежде всего потому, что увеличивается число операций соединения отношений. Нормализация таблиц БД позволяет устранить избыточность данных, уменьшив тем самым объем действий, необходимых при обновлении информации. Поэтому в них нет необходимости менять одни и те же значения в различных отношениях. В аналитических системах данные практически не обновляются - в системе производится лишь их накопление и чтение. Поэтому проблема нормализации БД в них не столь актуальна.
Во-вторых, выполнение некоторых аналитических запросов, требует хронологической упорядоченности данных. В третьих, при обслуживании аналитических запросов чаще используются не детальные, а обобщенные (агрегированные данные). Так, например, для прогнозирования объема импорта в некотором регионе будет излишним иметь информацию о каждом пересекающим таможенную границу контейнере, достаточно знать значение прогнозируемой величины за несколько предыдущих лет.
Данные, используемые для анализа, стали выделять в отдельные базы данных, получивших название хранилищ данных (ХД).