• 5

4.5.2. СОСТАВ ИНФОРМАЦИИ В ХРАНИЛИЩЕ ДАННЫХ

Основная цель создания хранилища данных налоговой инспекции

заключается в обеспечении целостного, объективного

образа существующей реальности в сфере налогообложения. Для

получения такого объективного представления в электронном

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

всех возможных источников (рис. 4.3).

Всю поступающую информацию можно разбить по категориям.

1. Регистрационные данные юридических и физических лиц

включают сведения:

• идентификационный номер налогоплательщика (ИНН);

• местонахождение налогоплательщика;

• расчетные счета;

• учредители;

• виды деятельности;

• уставный капитал и т.д.

Информация поступает от юридических и физических лиц

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

палат.

Деятельность налоговой инспекции

Результаты камеральных проверок

Результаты ревизий

Результаты документальных проверок

Оперативно-бухгалтерский учет

Юридические лица

Уставные данные

Квартальные и годовые отчеты

Сведения о доходах физических лиц

Расчеты по формам

Физические лица

Декларация о доходах

Лицензия на виды деятельности

Расчеты по налогам

Банки

Банковские выписки

Платежные документы

Сведения о вновь открываемых счетах

Сведения о финансовых операциях

Органы статистики

Общеэкономическая информация

ГБДД,

инспекции по маломерным судам

Сведения о владельцах водно-воздушных

и автотранспортных средств

Директивные органы

(Президент России, Государственная

Дума, МНС России, Минфин,

Центральный банк, органы

исполнительной и законодательной

власти субъектов РФ и др.)

Нормативно-инструктивные материалы

БТИ, регистрационная палата

Сведения об имуществе физических

лиц

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

таможенный комитет

Таможенные декларации

Казначейство

Сведения о поступлении налогов

в бюджет

Рис. 4.3. Источники данных для информационного хранилища налоговой инспекции

2. Информация об имущественном состояния налогоплательщиков,

включающая в себя следующие сведения;

• о владении недвижимостью;

• о землепользовании;

• об аренде объектов недвижимости и о предоставлении их в

аренду;

• об основных производственных фондах предприятий;

• о владении транспортными средствами;

• о приобретенной собственности за рубежом и т.д.

Информация поступает в налоговую службу от юридических

и физических лиц, регистрационной палаты, БТИ, ГБДД и т.д.

3. Информация о финансово-хозяйственной деятельности

юридических и физических лиц, включающая сведения:

• о ведении внешнеэкономической деятельности;

• о налоговой отчетности налогоплательщиков;

• об акционировании (приватизации) и ведении операций с ценными

бумагами;

• о доходах граждан;

• о нарушениях налогового законодательства и т.д.

Эти сведения поступают от юридических и физических лиц,

Государственного таможенного комитета, Министерства внутренних

дел и т.д.

4. Информация о расчетно-платежной деятельности налогоплательщиков,

включающая в себя сведения:

• о всех видах счетов налогоплательщиков в банках и иных кредитных

учреждениях;

• об использовании счетов для ведения безналичных расчетов;

• о нарушениях наличноденежного обращения;

• об операциях граждан свыше 10 тыс. долл. США;

• об отчетности налогоплательщиков.

Сведения поступают от банков России в соответствии с существующим

законодательством, от юридических и физических лиц.

5. Результаты деятельности налоговой инспекции, включающие

в себя сведения:

• акты завершенных документальных проверок;

• о нарушениях налогового законодательства;

• о контрагентах нарушений налогового законодательства;

• об административных нарушениях.

Сведения поступают из соответствующих подразделений налоговой

инспекции.

6. Нормативно-справочная информация, включающая сведения:

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

времени;

• классификаторы, справочники;

• общеэкономические показатели и т.д.

Информация поступает от органов государственного управления,

Госкомстата. Информация такого рода необходима для

учета особенностей налогообложения при аналитической обработке

данных за длительный интервал времени.

На основе этих сведений возможно выявление нарушителей

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

информации, накапливаемой в хранилище данных (как

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

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

РФ, Государственного таможенного комитета, ГБДД, лицензионной

и регистрационной палат и т. д.); планирование контрольной

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

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

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

по исполнению запросов, поступающих от региональных, территориальных

подразделений налоговой инспекции, а также от

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

От того, как спроектировано хранилище данных налоговой

инспекции, от того, насколько гибкой является СУБД, во многом

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

систему. Словарь данных должен содержать полное

описание всех элементов данных, входящих в систему, а сама

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

помощью средств моделирования связей между сущностями или

объектами. При использовании CASE-средств рекомендуется

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

через соответствующее CASE-средство.

4.6. АРХИТЕКТУРА АИС

АИС налоговой инспекции можно представить в виде совокупности

программных подсистем, решающих определенный

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

(рис. 4.4).

АИС

Подсистема 1

Хранилище

данных

Рис. 4.4. Архитектура программных компонентов АИС

Архитектурой АИС называется распределение функций по

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

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

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

по различным ЭВМ, объединенным в локальную или

глобальную вычислительную сеть.

Опыт показывает, что только изменение архитектуры АИС

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

затраты на разработку. Поэтому правильный выбор архитектуры

АИС - наиболее эффективный способ снижения стоимости

разработки и эксплуатации всей системы в целом.

С целью эффективного управления информационно-вычислительными

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

АИС налоговой инспекции положена трехуровневая

модель «клиент - сервер» (рис. 4.5).

Здесь компонент представления (клиент третьего уровня)

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

отображения данных; прикладной компонент (сервер второго

уровня) - функциональную логику, характерную для налоговой

инспекции; компонент доступа к ресурсам (сервер первого

уровня) - фундаментальные функции хранения и управления

данными (базами данных, файловыми системами и т.п.).

Компьютер - клиент

Комяанент ^ 'Щ

Компьютер - сервер

• Прикладной

. /icownoHeHf <\

Компьютер - сервер

Рис. 4.5. Модель "клиент - сервер"

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

как на одном компьютере, так и на разных компьютерах,

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

Компонент представления часто располагается на персональном

компьютере или терминале, прикладной компонент

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

системы UNIX или Windows NT, а компонент доступа

к данным и сами данные располагаются либо на мощных UNIX-

серверах, либо на больших или мини-ЭВМ.

Основная цель выбора такой модели - отделение компонентов,

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

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

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

логику соответствующих компонентов и не затрагивать пользовательский

интерфейс. Такой принцип построения архитектуры

АИС существенно экономит ресурсы на модификацию и упрощает

администрирование и сопровождение.

Функционирующие в настоящий момент информационные

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

сетях с неоднородным техническим и системным программным

обеспечением. Для интеграции таких информационных систем

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

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

платформах.

Одна из таких связующих технологий основана на спецификациях

ОМА (Object Management Architecture) - фактических

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

объектных систем в гетерогенных средах, которые разработаны

консорциумом OMG (Object Management Group) [3]. Архитектура

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

систем базируется на концепции программного обеспечения промежуточного

слоя (middleware), содержащего инспекции и сред-

ства поддержки глобального пространства объектов (программных

компонентов).

ОМА состоит из четырех основных компонентов, представляющих

собой спецификации различных уровней поддержки

приложений:

• архитектура брокера запросов объектов (CORBA - Common

Object Request Broker Architecture) устанавливает базовые механизмы

взаимодействия объектов в гетерогенной сети;

• сервисы объектов (Object services) являются основными системными

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

приложений;

• универсальные средства (Common Facilities) ориентированы

на поддержку пользовательских приложений, таких, как электронная

почта, средства печати и т.п.;

• объекты приложений (Application Objects) предназначены для

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

Спецификация CORBA определяет механизм, обеспечивающий

взаимодействие приложений в распределенной среде. Концептуально

CORBA относится к уровням приложений и представлений

семиуровневой модели сетевого взаимодействия. Она

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

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

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

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

характеристик информационных систем.

Главными компонентами стандарта CORBA служат:

обработчик объектных заявок (Object Request Broker - ORB);

язык определения интерфейсов (Interface Definition Language -

IDL), с помощью которого могут быть определены операции

для обращения клиентов к серверным объектам;

• объектный адаптер (Object adapter), который предоставляет

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

низкоуровневые средства для связи объекта с его клиентами;

• репозиторий интерфейсов (Interface Repository), представляющий

собой средство для хранения и обработки информации,

необходимой для описания интерфейсов CORBA-объектов.

CORBA определяет среду для различных реализаций ORB,

поддерживающих общие сервисы и интерфейсы (рис. 4.6). Это

обеспечивает переносимость клиентов и реализаций объектов

между различными ORB.

Результат

исполнения

заявки

Интерфейс

динамического

вызова

Локальная

процедура

вызова IDL

Статический

интерфейс ORB

Компонент передачи 1

| заявок |

Объектный

J адаптер

Ядро ORB

Рис. 4 . 6 . Структура интерфейсов

Интерфейсы объектов могут быть определены и помещены

в репозиторий интерфейсов двумя способами: статически - описанием

на языке определения интерфейсов IDL или динамически.

Репозиторий интерфейсов представляет компоненты интерфейса

как объекты и обеспечивает доступ к ним во время выполнения.

При формировании заявки клиент может использовать интерфейс

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

IDL локальную процедуру вызова.

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

ORB. ORB ищет соответствующий код, пересылает параметры

заявки и передает управление Реализации объекта (Object

Implementation). Реализация объекта принимает заявку через сгенерированные

компилятором IDL процедуры и при этом может

обращаться к объектному адаптеру и ORB. Когда обработка заявки

завершена, управление и выходные значения возвращаются

клиенту.

Различные ORB могут иметь разную реализацию и поддерживать

различные объектные механизмы. В структуре ORB выделяются

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

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

которых маскируют различия в реализации ORB.

Клиенты максимально мобильны и должны работать без изменения

исходного кода в среде любого ORB, который поддерживает

отображение IDL в соответствующем языке программирования.

Мобильны также и реализации объектов для разных ORB при

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

и имеют требуемые объектные адаптеры.

Языковое отображение включает определение характерных

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

к объектам при помощи ORB. Отображение определяет

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

интерфейса динамического вызова, объектных адаптеров и прямых

интерфейсов ORB.

Объектный адаптер является основным средством доступа к

услугам ORB со стороны объектной реализации. Эти услуги

обычно включают: генерацию и интерпретацию объектных ссылок,

вызов методов, активизацию (деактивизацию) реализации

и объекта, регистрацию реализаций. Предполагается наличие

нескольких широко доступных объектных адаптеров с интерфейсами,

соответствующими определенным видам объектов.

Характерные особенности разработки приложений по технологии

CORBA заключаются в следующем:

• язык описания интерфейсов OMGIDL позволяет определить

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

для реализации;

• высокий уровень абстракции CORBA в семиуровневой модели

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

протоколами;

• программисту не требуется информация о реальном месте расположения

сервера и способе его активации;

• разработка клиентской программы не зависит от серверной

операционной системы и аппаратной платформы;

• после модификации возможно использовать ранее разработанные

приложения.

Рассмотренные в этой главе архитектурные и технологические

решения обеспечивают: распределенную обработку данных

в разнородной среде (при этом достигается высокий уровень открытости

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

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

и отказоустойчивости); расширяемость системы, т.е. простоту

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

старых функционирующих прикладных систем с новыми; документируемое^

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

их жизнеспособность и эволюционное развитие. Все

это существенно снижает суммарные затраты на создание АИС

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

систем.

Авторы: 1379 А Б В Г Д Е З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я

Книги: 1908 А Б В Г Д Е З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я