Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
все лекции.doc
Скачиваний:
10
Добавлен:
22.09.2019
Размер:
358.4 Кб
Скачать
  1. Порядок сбора, проведения форматно-логического контроля и пере­дачи электронных копий грузовых таможенных деклараций на всех уровнях системы таможенных органов в рамках Единой автоматизи­рованной информационной системы (ЕАИС) ГТК России

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

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

В таблице приведен ряд новых терминов и определений, впервые введенных Приказом №499 от 12 мая 2003 года.

Центральный элемент комплексной системы таможенного оформ­ления - база данных ГТД. Каждый товар, приходящий на границу, имеет множество сопроводительных документов - накладные, контракт, паспорт сделки, которая предваряет поставку, книжки перевозчиков и т. п. Вся ин­формация из этих документов сводится в один - грузовую таможенную декларацию; этот документ в настоящее время наиболее важен в работе таможенных служб. В ГТД описывается сам товар, его отправитель, полу­чатель, указывается таможенная стоимость, вес, способ доставки и т. п. Форма этого документа вписана в структуру БД, и каждое его поле имеет под собой информационную поддержку.

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

Таможня назначения, получив груз, помещает его на склад временно­го хранения и проверяет соответствие заявленных кодов, наименования, объема и стоимости фактически поступившему товару, после чего форми­рует ГТД и направляет ее в центральную БД, а товар выпускает в свобод­ное обращение.

ГТД, появившись на таможне назначения, становится тем докумен­том, вокруг которого в дальнейшем проводятся все проверки, а сведения, осевшие в БД грузовых таможенных деклараций, подвергаются различной обработке. Помимо проверки правильности оформления ГТД и при необходимости ее корректировки, центральная БД ФТС России преду­сматривает возможности перекрестной проверки данных ГТД и других специализированных документов, проведения статистической обработки информации о поступивших в Россию товарах и их объемах (для предос­тавления сведений экономическим и финансовым ведомствам), а также функции "зеркальной статистики" - сопоставления экспортных данных Евросоюза с информацией о реально поступивших в Россию грузах.

Центральная база данных многократно продублирована: в частно­сти каждая региональная БД хранит всю информацию, накопленную РТУ за все время работы, и каждая таможня имеет полную информацию о своей деятельности. Такое многоуровневое резервирование позволяет в любой момент восстановить информацию, если что случится с центральной ба­зой.

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

Термины, введенные приказом ГТК России от 12 мая 2003 года №499

Распределенная обработка и распределенная база данных не синони­мы. Если при распределенной обработке производится работа с базой, то подразумевается, что представление данных, их содержательная обработ­ка, работа с базой на логическом уровне выполняются на персональном компьютере клиента, а поддержание базы в актуальном состоянии на сер­вере. В случае использования распределенной базы данных последняя раз­мещается на нескольких серверах. Работа с ней осуществляется на тех же персональных компьютерах или на других, и для доступа к удаленным данным надо использовать сетевую СУБД.

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

Удаленный запрос - единич­ный запрос к одному серверу. Несколько удаленных запросов к одному серверу объединяются в удаленную транзакцию. Если отдельные запросы транзакции обрабатываются различными серверами, то транзакция называ­ется распределенной. При этом один запрос транзакции обрабатывается одним сервером. Распределенная СУБД позволяет обрабатывать один за­прос несколькими серверами. Такой запрос называется распределенным. Только обработка распределенного запроса поддерживает концепцию рас­пределенной базы данных.

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

ИСПОЛЬЗОВАНИЕ В ФТС РОССИИ СИСТЕМ ОРИЕНТИРОВАННЫХ НА АНАЛИЗ ДАННЫХ

При построении 1-й очереди ЕАИС акцент делался на классические методы проектирования базы данных, то есть на системы, ориентирован­ные на обработку транзакций в реальном времени (On-Line Transaction Processing- OLTP)

Система выдает ответы на простые вопросы типа "каков был уровень импорта товара N в регионе М в январе 2004 года?). Традицион­ные системы OLTP оперируют такими понятиями, как сущность, связь, функциональная декомпозиция и анализ изменения состояний.

В системах OLTP информация хранится в виде, пригодном для де­тальной ревизии данных. Если пользователя интересует кредитный счет экспортера, он должен получить подробную информацию о каждой опера­ции. С этим прекрасно справляется система OLTP, которая обеспечивает строжайшую секретность и максимальную закрытость. Неудивительно по­этому, что с помощью таких систем невозможно получить ответ на анали тические вопросы типа "Будет ли получена от этого прибыль?", "Какие клиенты наиболее выгодны с позиции таможенных платежей и почему?" или "Какие возможности в технологии валютного контроля упускаются?".

В реляционных моделях связи отображаются явно. Понятие "сущ­ность-связь" составляет основу реляционной модели. Например, явное описание связи между потребителями и заказами закладывается в саму конструкцию реляционной БД.

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

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

Для получения интересующей их информации лица, принимающие решение (ЛПР), или аналитики обращаются к СППР с запросами. Эти за­просы в большинстве случаев более сложные, чем те, которые применяют­ся в системах операционной обработки данных, например, "Найти среднее значение промежутка времени между выставлением счета и оплатой его участником ВЭД в текущем и прошедшем году отдельно для разных групп участников ВЭД".

В большинстве случаев сложный аналитический запрос невозможно сформулировать в терминах языка SQL, поэтому для получения информа­ции применяют специальные языки, ориентированные на аналитическую обработку данных. К их числу можно, например, отнести язык Ехрress 4GL фирмы Огас1е. Также для выполнения запросов могут быть использованы приложения, написанные специально для решения тех или иных задач.

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

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

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

Данные, ис­пользуемые для анализа, стали выделять в отдельные базы данных, полу­чивших название хранилищ данных (ХД).