Инфраструктура информационной системы мониторинга экономических процессов Текст научной статьи по специальности «Компьютерные и информационные науки»

№3(21)2009

Н. Н. Прокимнов

Инфраструктура информационной системы мониторинга экономических процессов

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

Основным условием достижения эффективности принимаемых решений является достаточная обеспеченность управленческих процедур необходимыми исходными данными [1]. Задача информационной поддержки требует к себе тем большего внимания, чем выше уровень и важность принимаемых решений. Стратегический уровень анализа основан на использовании не только данных систем автоматической регистрации и автоматизированных систем, но и представляющих собой результат специальных обследований объекта принятия решения. Типичным подходом к организации получения этих данных является ориентация на их специфику (на вход), что затрудняет последующие агрегирование и совместное использование данных разных источников. К прочим издержкам такого подхода относятся большие затраты на подготовку инструментария процесса наблюдения и реализацию его процедур.

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

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

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

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

• Enterprise Manager, Transact SQL и Query Analyzer пакета MS SQL Server [2] (база данных и метаданных наблюдений, программные средства доступа, обработки и администрирования базы);

• Analysis Services MS SQL Server [3] (база многомерных данных);

• Microsoft Access и язык VBA [4] (графический интерфейс);

• ADO и OLE DB [5] (работа с базой данных в среде графического приложения и интерфейсов);

• Microsoft Excel [6] (файлы с микроданными наблюдения).

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

Инфраструктура информационной системы

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

65

№3(21)2009

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

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

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

• конечные пользователи;

• прикладные программы;

• внешние информационные системы;

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

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

Жизненный цикл системы наблюдения

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

Рис. 1. Жизненный цикл наблюдения

66

№3(21)2009

На этапе планирования:

• формулируются основные цели и задачи наблюдения;

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

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

• формируется реестр респондентов (репортеров, наблюдателей), ответственных за сбор и представление данных;

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

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

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

Собственно процесс наблюдения состоит из нескольких шагов.

Измерение обеспечивает получение значений переменных наблюдения относительно наблюдаемых объектов. Значения получаются прямо или косвенно от репортеров, для их получения используется различный инструментарий, например, вопросник (анкета), рассылаемый на места или заполняемый интервьюером. Данные наблюдения представляют собой интервальные временные ряды [7], [8], поэтому далее будем считать, что записи файлов, в которых хранятся их значения, имеют в своей структуре поля, специфицирующие промежуток времени протекания контролируемых процессов.

подготовка данных может включать такие *

§

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

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

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

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

Информационные ресурсы системы наблюдения

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

Метаданные. Описывают различные качественные аспекты данных наблюдения и организационную среду процесса их получения, в частности:

• наблюдаемые объекты;

67

№3(21)2009

• переменные наблюдения (показатели);

• характеристики точности: отклонения между наблюдаемыми величинами;

• репортеров: юридических или физических лиц, ответственных за сбор и представление данных;

• принятый регламент выполнения основных этапов процесса наблюдения;

• применяемый в системе инструментарий сбора и передачи.

Регистр переменных (каталог переменных, словарь данных) содержит список используемых переменных наблюдения. Регистр содержит (в типичном случае) определения переменных, связи с массивами первичных и итоговых данных наблюдения и стандартные форматы для отображения величин, хранимых в электронном виде. Определение переменной содержит набор ее допустимых значений и/или кодов (множество значений), включая логические взаимосвязи между отдельными значениями, и, возможно, сведения о содержательной сущности. Множество значений 2 может использоваться более чем одной пере-

О

менной (например, место рождения и место ^ проживания могут использовать одну и ту же | совокупность значений— адрес). Множества §; значений могут объединяться в супермноже-| ства.

0

§ К метаданным будем относить также неко-2 торые классификаторы (например, страны | и группы стран). Группы могут образовывать

супергруппы (иерархии). а Микроданные. Характеризуют отдельный

1 объект наблюдения (люди, компании, собы-| тия). Объект имеет свойства, выражаемые зна-§ чениями отдельных его показателей (перемен-53 ных объекта). Например, объект «человек» может описываться переменными «имя», «адрес»,

§ «возраст», «доход». Микроданные представляла ют собой наблюдаемые или полученные из других источников величины для определен-

% ных объектов. а

« Макроданные (статистика). Представляют Е? собой оценки статистических характеристик, относящиеся к совокупностям объектов, мно-

| жествам. Статистическая характеристика яв-

■Ц: ляется мерой, обобщающей значения пере-

^ менной по объектам множества. Оцениваемая

величина отличается от истинной вследствие погрешностей (ошибок и неопределенностей), вносимых процессами наблюдения (измерения) и вычисления.

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

Функции

информационной системы наблюдения

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

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

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

68

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

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

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

Проведение аналитических работ в настоящее время может обеспечиваться специальными программными средствами типа оперативной аналитической обработки (OnLine Analytical Processing, OLAP), которые позволяют эффективно работать с массивами данных больших размерности и объема.

Таким образом, можно выделить следующие основные функции информационной системы мониторинга:

• проведение отдельных наблюдений;

• интеграция данных различных наблюдений;

• ведение регистров наблюдений;

• обеспечение анализа данных наблюдений.

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

№ 3(21) 2009

использующих в качестве основных источни- * ков базы данных наблюдения. g

Многомерная база данных

а:

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

Многомерная модель оперирует следующими понятиями (рис. 2).

• Показатель (measure) — величина (обычно числового типа), которая, собственно, и является предметом анализа, например, объем перевозок груза определенного вида, или затраты на строительство автомобильных дорог в конкретном регионе. Один OLAP-куб может обладать единственным или несколькими показателями.

Так, куб ПЕРЕВОЗКИ на рис. 2 имеет в качестве показателей величины: всего, экспорт, импорт, каботаж.

• Измерение (dimension) — множество объектов одного или нескольких типов, организованных в виде иерархической структуры и обеспечивающих информационный контекст числового показателя. Измерение принято визуализировать в виде ребра многомерного куба.

Измерениями куба ПЕРЕВОЗКИ являются Стивидоры, Груз, Время (как интервал).

• Объекты, совокупность которых образует измерение, называются членами измерений (members). Члены измерений визуализируют как точки или участки, откладываемые на осях гиперкуба.

Например, временное измерение месяцы, кварталы, годы (наиболее часто используемое в анализе) может содержать следующие члены: май 2007 года, 2-й квартал 2008 года или 2005 год.

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

69

§ §■

I € I

S

>а о

£

0 а

г €

Si %

а а

1

<з

■I: =1

№3(21)2009

Южный округ

Краснодарский край

Стивидоры

•-Новороссийск

-Геленджик

-Сочи -Астрахань

Груз

Нефть

Наливные Химические

Нефтепродукты

Черные металлы

Генеральные

Цветные металлы

Минеральные удобрения

Сухогрузы Навалочные Руда

Уголь

Зерно

Насыпные

Сахар

Лесные

Контейнеры

/

/

04 05 Об 07 08 09 10 11 12 01 02 03 04 05 Об 07

12007

Время

Рис. 2. Многомерная модель данных по грузоперевозкам

• Ячейка {cell) — атомарная структура куба, соответствующая конкретному значению некоторого показателя. Ячейки при визуализации располагаются внутри куба и здесь же принято отображать соответствующее значение показателя.

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

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

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

Так, измерение Стивидор может определяться направлением консолидации,состоящим из уровней обобщения Округ-Регион — Город-Стивидор. Измерение Время может определяться направлением консолидации, состоящим из уровней обобщения год — квартал — месяц {рис. 3).

Операция углубления, или спуска {drilling down), соответствует движению от высших ступеней консолидации к низшим; напротив, операция обобщения, или подъема {rolling up), означает движение от низшихуровней к высшим.

Ниже показан пример, поясняющий возможности работы со сведениями о грузоперевозках морским транспортом1, представленными в виде куба Analysis Services [3] пакета MS SQL Server [2].

70

№3(21)2009

Стивидоры

Округ !

Регион

1

Город

1

Стивидор

Время

Год

Квартал

Месяц

Рис. 3. Консолидация и углубление

С помощью браузера компонента Analysis Manager, который можно вызвать переходом на вкладку Данные (Data) в редакторе куба или указанием опции Browse Data в контекстном меню для куба Объемы, в окне браузера отображается двумерная таблица с измерением ГРУЗ по строкам, которая включает единственный столбец показателей ОБЪЕМ (рис.4).

Измерение ГРУЗ не раскрыто (показана строка Всего грузов, соответствующая корневому значению множества измерений). Для всех остальных измерений (ПЕРИОДЫ, ПЛАВАНИЕ,

СТИВИДОРЫ) на панели измерений выбраны опции получения итогов.

В случае, когда по одному или нескольким (в примере — по всем) измерениям будет произведена установка значений путем раскрытия иерархического (в общем случае) множества значений, данные в панели таблицы значений будут автоматически пересчитаны для выбранного пользователем набора значений измерений. Так, указывая в выпадающих списках значения Апрель 2004 года для измерения ПЕРИОД, значение Экспорт для измерения ПЛАВАНИЕ, Нефтяной порт для измерения СТИВИДОРЫ (рис. 5) получим отображение данных для установленных значений (рис. 6), состоящее из одной величины.

Рис. 6. Экран с итоговым значением показателя

E)-(jfj Форма_МП В С] Data Sources

FvC3-r>Jbss

Ш {~| Грузоперевозки

в-Q s-Q s-D Sh ш-Сз мн

Ос

JBtSWfPfPWI

NawCuhe New Virtual Cube,.. New Linked Cube,.. New Mining Model...

Edit...

' Cube Browser - Объемы

+ Всего грузов

MeasuresLevel

76! 389,20

О

1 a: a:

Рис. 4. Доступ к многомерным данным с помощью браузера: а — выбор куба; б — выбор значений членов измерений

Рис.5. Задание значений измерений: а — период; б — плавание; в — стивидоры

R

1 Пример является гипотетическим и не связан с конкретными объектами и показателями.

71

№ 3(21) 2009 ^

Если теперь в панели данных последовательными щелчками по символу + , стоящему слева от названий групп грузов, раскрыть измерение ГРУЗ по нескольким уровням {Всего грузов ^ Сухогрузы ^ Навалочные), увидим детализацию для указанной группы с итогами в строках с суффиксами Total в своем названии {рис. 7).

£

| Такой вид интерфейса предоставляет ана-

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

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

& дений. Не устраняя необходимости решения

g задачи в традиционной постановке — получе-

§ ние регулярных отчетов и справок по накоп-

| ленным данным — преимущества OLAP делают

| очевидной желательность внедрения этой тех-

5 нологии.

•з |

з Архитектура системы

«s §

Учитывая основные цели мониторинга экономических процессов, требования к конечно-« му продукту функционирования системы, пе-ît речень задач, решение которых необходимо обеспечить в процессе жизненного цикла, и ха-| рактер реализующих решение этих задач процессов, можно определить архитектурный об-5= лик системы (рис. 8).

Хранилище данных на рис. 8 образуют:

• регистры наблюдения;

• итоговые данные наблюдения;

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

• метаданные, описывающие данные в хранилище данных, а также связанные с ними про-

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

С точки зрения использования хранимых массивов и определяемой этим программной среды можно выделить два основных раздела:

• технологический, включающий основные и служебные данные наблюдений {находится под управлением реляционной СУБД);

• аналитический, включающий многомерные данные, обновляемый на регулярной основе данными технологической базы {находится под управлением OLAP-сервера).

Основной формой представления и передачи данных наблюдения для ввода в систему являются электронные файлы. Файлы формируются на локальных компьютерах репортеров с помощью электронных форм ввода и/или средств импортирования из автоматизированных систем. Форматы файлов выбираются из наиболее известных и распространенных {например, книга Excel [6]). Мерой, улучшаю-

Периоды 4 -"I

Н Плавание Экспорт _m

Стивидоры Нефтяной порт

MeasuresLevel

- Level 01 - Level 02 - Level 03 1 Level 04 Объем

Всего грузов Total 4 556,40

Прочие 1 164,70

+ Наливные грузы Наливные грузы Total 394,60

Сухогрузы Total 2 997,10

в ДФЭ 317,00

+ Генеральные Генеральные Total 1 238,20

Контейнеры в тн 4,50

- Всего грузов Лесные 219,40

Навалочные Total 250,60

- Сухогрузы Мин. удобрения 6,70

- Навалочные Прочие 124,40

11,80

Руда 11,50

Уголь^окс 96,20

+ Насыпные Насыпные Total

Прочие 967,40

Double-dick a member to drill up or down. Close

Рис. 7. Экран с детализированным значением показателя

72

№3(21)2009

«о

0

1

I

Рис. 8. Основные архитектурные компоненты системы

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

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

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

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

• вводить значения переменных, зависящих от места наблюдения, выбором из меню (например, из списка закрепленных за репортером объектов наблюдения);

• выводить контекстно-зависимые подсказки.

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

Архивация наблюдений

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

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

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

• образовано,

• ликвидировано,

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

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

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

Имена

Повышение уровня организации всех компонентов инфраструктуры и автоматизации

73

№ 3(21) 2009 ^ -

ALTER FUNCTION [dbo]. [fn_tblid] (gllaiae varchar(9)) RETHENS smallint AS

/*************************************************************************************************

Значение части "Учетный нонер" стандартного имени таблицы QName.

Длины каждого фрагмента формата задаются системными константани mon_constants

В случае незаконного ииени возвращается NULL

*************************************************************************************************I

BEGIN

DECLARE SintValue smallint, STblActLen int, SPrtActLen int, QVerActLen int IF dbo.fn_tblnmvalid (@Name)=0 BEGIN

SELECT @PrtActLen=PrtActLen, 0TblActLen=TblActLen, @VerActLen=VeEActLen FROH mon_constants SET SintValue=cas t(Sub s tring (ßNaiae, @ P rtActLen+l+@Ver Ac tLen+1+1, @TblActLen) AS smallint) ЕГО ELSE

SET @intValue=HULL RETURN i QintValue j ЕГО

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

для заданного имени таблицы

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

0

Для данной реализации правила по форма-^ там и семантике имен объектов документиру-| ются в виде пользовательских функций (User * Defined Function — UDF) MS SQL Server и значе-

1 ний констант, сохраняемых в таблице констант § системы. Это позволяет автоматически форми-

2 ровать имена объектов по значениям параметре ров (осуществлять композицию имен) и наоборот — выделять из имени объекта значения па-

3 раметров (осуществлять декомпозицию имен). 1 Для примера на рис. 9 показана функция опре-| деления учетного номера наблюдения (локаль-! ного регистра) по заданному имени таблицы.

Э Для разрабатываемых объектов отдельного наблюдения, кроме того, используются ти-§ повые шаблоны, что позволяет именовать объ-

§" екты автоматически. s

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

« • ключевого и некоторых других столбцов Е? таблиц глобального регистра;

• индексов, триггеров, хранимых проце-| дур, локальных регистров. ■Ц: Несколько основных правил именования

¡В

s приводятся по ходу изложения.

74 V

Глобальный регистр

Все регистры хранятся в виде таблиц реляционной базы данных.

Выделяются глобальный и локальные регистры отдельных наблюдений.

Глобальный регистр (рис. 10) содержит общие сведения о среде протекания наблюдаемых процессов, объектах наблюдения и проводимых наблюдениях.

Рис. 10. Состав глобального регистра

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

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

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

Раздел Объекты хранит сведения относительно объектов наблюдения.

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

В разделе Управление хранятся сведения нормативно-организационного характера для

№ 3(21) 2009

«о

надлежащего выполнения отдельных работ *

€

и этапов технологии. §

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

Различные концептуальные разделы регистра могут использовать в своих схемах одни и те же таблицы или представления базы данных. Так, разделы Репортеры и Объекты построены на одном наборе таблиц (рис.11).

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

Рис. 11. Таблицы разделов Репортеры и Объекты регистра

75

№3(21)2009

^=86

ЮрЛ ицаДеятел ьность

Щ Юрлицо 1 Деятельность

Н_Виды Деятельности

о<

0 &

и

О!

з

1

I

п\

о £

3 &

»3

I

о

3 3

<3 §

&

3 3 в

«3

а

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

Таблица включает также сведения относительно органов власти всех уровней, что обеспечивается и непосредственно сведениями таблиц (рис. 12).

ЮрЛица

Ключ

Образовано Ликвидировано НазваниеПолное НазваниеКраткое НазваниеСтарое ИНН

КодОКПО КодОКОНХ КодСООГУ КодСОАТО Код Речной Код Морской КодРТИ Код ФЦП ВходИТВ

КурирующийМАП ОбслуживающийБанк РегионОтветсвенности БассейнРечной БассейнМорской ПравоваяФорма ФормаСобственности ПочтовыйИндекс Город Адрес Телефон_1 Телефон_2 Телефон_3 Телефакс_1

Телефакс_2 Email

Ключ

НазваниеПолное

Образовано

Ликвидировано

Н_ПравовыеФормы

9 Ключ

НазваниеПолное

НазваниеКраткое

Коммерческая

Образовано

Ликвидировано

Н_Формы Собст венност и

Ключ

НазваниеПолное НазваниеКраткое Образовано Ликвидировано

Рис.12. Информационная модель административно-территориального деления

Модель описывает административное устройство Российской Федерации и других стран мира с числом уровней территориального деления до трех включительно. Сквозное прохождение лишнего уровня для стран с числом уровней, меньшим трех, обозначается записями-перемычками (со значением ЫиИ в поле Название), помещаемыми в таблицу отсутствующего уровня.

Локальные регистры хранят:

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

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

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

Данные и метаданные наблюдения

На рис. 13 показан пример экранной формы спецификации локального регистра технологической базы.

Форма используется для задания организационно-управленческой информации — учетного номера, шифра, объектов и периодичности наблюдения — вкладка Общие, регламента проведения сбора данных— вкладка Технология. Вкладка Вид — используется для указания способа, с помощью которого будут обозначаться объекты и субъекты наблюдения в различных обращающихся в системе документах. Выбор обеспечивается сведениями, хранящимися в глобальном регистре. Например, в случае, когда для субъекта или объекта в таблице ЮрЛица хранятся коды ОКПО и ИНН (рис. 13), администратор (технолог) может произвести выбор варианта идентификации объектов или субъектов на первичных формах сбора.

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

Таблицы базы данных содержат:

• допустимые диапазоны значений показателей;

• регистры (справочники) значений показателей или указания на глобальные справочники;

• тип значения каждого показателя: накоплено с начала данного периода наблюдения или с начала текущего года (нарастающий итог);

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

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

• перечень обязательных для заполнения клеток формы;

• перечень закрытых для ввода значения клеток формы (обычно содержащих символ X в образцах форм).

Описания, не охватываемые этим стандартом, включаются в другие объекты базы дан-

76

№3(21)2009

«о

0

1

I

а

Рис. 13. Вкладки метаданных наблюдения: а — общие; б — вид; в — технология;

77

б

в

№3(21)2009

Рис.14. Локальные регистры

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

0

цедуры в соответствии с принятыми правила-^ ми именования процедур и обращений к про-| цедурам (интерфейса).

§; Таблицы локального регистра используют-

1 ся на всех предусмотренных технологией эта-§ пах жизненного цикла. Унификация их состава

2 и структуры позволяет, в частности:

| • повысить уровень управляемости процессами;

а • исключить необходимость разработки 1 технологических программ для каждого от-| дельного наблюдения;

! • автоматизировать (принципиально, пол-53 ностью) процесс взаимодействия с поставщиками данных на этапе сбора; § • упростить процедуры администрировала ния базы данных наблюдений.

Для имен таблиц локальных регистров при-% нят формат:

| < AAA > # < ББ >< В >< ГГ >,

I

где AAA — цифровой учетный номер наблюде-| ния (раздела);

■Ц: ББ — цифровой номер версии наблюдения; s В — буквенный индекс типа таблицы;

ГГ — цифровой идентификационный номер таблицы.

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

й — таблица с загруженными данными первичной формы;

А — определитель свойств клеток первичной формы;

6 — описатель строковых групп первичной формы;

Р — описатель столбцовых групп первичной формы;

Б — параметры категорий наблюдения (справочники значений);

С — дополнительные свойства столбцов таблицы данных наблюдения.

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

Год — год наблюдения;

Период — период наблюдения;

Источник — объект наблюдения.

Эти и (возможно) непосредственно следующие за ними по порядку столбцы со ссылками на таблицы-классификаторы образуют первичный ключ таблицы.

78

»3(21)2009

003#0Ю01

? Год 1 Период 1? Источник | Груз Всего Экспорт Импорт Транзит Каботаж

003#01S01

f Ключ Код

НазваниеПолное Группа Уровень COI

НазваниеСтарое

003#01А01

! Груз $ Colld

Накопление

Наличие

Формат

ДоменТаблица

ДомгнКлюч

ДомгнКод

003#01G01

f Ключ Название Вычисляемая Отношение Вершина

003#01С01

f Ключ Группа Уровень Коды

003#01F01

f Ключ Название Вычисляемая Отношение Вершина

003#01D02

? Год f Период f Источник 1 Груз f Транспорт ПрибытиеВсего ПрибытиеЭкспорт ПрибытиеТранзит ПрибытиеКаботаж ОтправлениеВсего ОтправлениеИмпорт ОтправлениеТранзит ОтправлениеКаботаж

Л 003#01S02 f Ключ Код

НазваниеПолное

оо Группа

Уровень С01 НазваниеСтарое

003#01G02

ц=©» f Ключ

Название

Вычисляемая

Отношение

Вершина

003#01А02

? Груз

f Транспорт

—сс f ColId

Накопление

Наличие

Формат

ДоменТаблица

ДоменКпюч

ДоменКод

003#01С02

1 Ключ

ОС Группа

Уровень

Коды

003#01Р02

1 Ключ

Название

Вычисляемая

Отношение

Вершина

%

i о

а: а:

Рис. 15. Пример локального регистра сданными и метаданными наблюдения

Структура таблиц с метаданными включает один и тот же набор столбцов, возможно, дополненный столбцами со служебными сведениями для обеспечения удобства выборок и обработки (например, данные столбца С01 на рис. 15 задают сортировку данных в выходных отчетах).

В разделе с учетным номером 003 хранятся метаданные и данные наблюдения за перевозочными процессами. Данные заносятся в таблицы 003#01D01 и 003#01D02 из двух файлов: в первом содержится детализация по видам перевозимых грузов (первая часть первичной формы), во втором — по видам грузов и видам транспорта (вторая часть первичной формы).

Таблицы с описанием группировок (G и F) имеют одинаковую структуру с точностью до ссылки (на строку или столбец соответственно). Поля в таблицах имеют следующий смысл: вычисляемая — указывает на то, осуществляется ли группирование на этапе обработки (Истина), или в первичной форме (Ложь);

отношение — определяет, является ли групповое значение полной (=) или частичной (< =) суммой значений членов группы (обычно помечается в первичной форме словами из них или в том числе);

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

Информационную модель локального регистра можно считать надстройкой реляционной модели для прикладной области. В зависимости от конкретной СУБД используются те или иные ее средства для реализации надстройки. Данный вариант реализации применяет сведения из системных таблиц MS SQL Server. В частности, смысл и имя столбца с именем ColId таблиц 003#01A01 и 003#01A02 соответствует смыслу и имени столбца ColId в системных таблицах.

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

79

№ 3(21) 2009 ^

показанной на рис. 16 (графа «Стр» содержит номер строки для ссылок). Этот раздел первичной формы обновляет таблицу данных с учетным номером 01 (003#01й01) на рис.15.

Группы по строкам заданы записями таблиц 003#01Б01 (виды груза) и 003#01601 (группы по видам груза) представлены на рис. 17.

Группирование по столбцам первичной формы (значение в столбце Всего есть сумма значений, стоящих в остальных столбцах) описывается, как показано на рис. 18.

Столбец Всего таблицы данных 003#01D01 присутствует в системных таблицах SQL Server со значением ColId = 5, другие столбцы — 6,7,8,9. На рис. 19 приведен текст триггера обновления служебной таблицы 003#S01.

Текст триггера создается настройкой стандартного шаблона простой замены вхождений строки-заместителя на имя таблицы (в данном случае на 003#S01). Триггер либо блокирует обновление записи служебной таблицы при нарушениях отношений строгой подчиненности между записями таблицы, выявляемых храни-

Груз Стр Всего грузов Импорт Экспорт Транзит Каботаж

0 Всего грузов 1

1 Сухогрузы 2

1.1 Навалочные 3

1.1.1 Руда 4

1.1.2 Уголь, кокс 5

1.1.3 Мин. удобрения 6

1.1.4 Прочие 7

1.2 Насыпные 8

1.2.1 Зерно 9

1.2.2 Сахар 10

1.2.3 Прочие 11

1.3 Лесные 12

1.4 Генеральные 13

1.4.1 Черные металлы 14

1.4.2 Цветные металлы 15

1.4.3 Металлолом 16

1.4.4 Тарно-штучное 17

1.4.5 Рефгрузы 18

1.4.6 Прочие 19

1.5 Контейнеры, 20

1.5.а в том числе, вДФЭ 21

2 Наливные грузы 22

2.1 Нефть 23

2.2 Нефтепродукты 24

2.3 Пищевые 25

2.4 Химические 26

Рис. 16. Пример первичной формы наблюдения

80

№3(21)2009

003#01Б01

Ключ Код НазваниеПолное Группа Уровень С01 Анкета

1 1 Всего грузов 0 1 0.

2 2 Сухогрузы 4 1 2 1.

3 3 Навалочные 5 2 3 1.1.

4 4 Руда 7 3 4 1.1.1.

5 5 Уголь,кокс 7 3 5 1.1.2.

6 6 Мин. удобрения 7 3 6 1.1.3.

7 7 Прочие 7 3 7 1.1.4.

8 8 Насыпные 5 2 8 1.2.

9 9 Зерно 8 3 9 1.2.1.

10 10 Сахар 8 3 10 1.2.2.

11 11 Прочие 8 3 11 1.2.3.

12 12 Лесные 5 2 12 1.3..

13 13 Генеральные 5 2 13 1.4.

14 14 Черные металлы 9 3 14 1.4.1.

15 15 Цветные металлы 9 3 15 1.4.2.

16 16 Металлолом 9 3 16 1.4.3.

17 17 Тарно-штучное 9 3 17 1.4.4.

18 18 Рефгрузы 9 3 18 1.4.5.

19 19 Прочие 9 3 19 1.4.6.

20 20 Контейнеры, 5 2 20 1.5.

21 21 в том числе, в ДФЭ 5 2 21 1.5.а

22 22 Наливные грузы 4 1 22 2.

23 23 Нефть 6 2 23 2.1.

24 24 Нефтепродукты 6 2 24 2.2.

25 25 Пищевые 6 2 25 2.3.

26 26 Химические 6 2 26 2.4.

003#01601

Ключ Название Вычисляемая Отношение Вершина

4 ВсегоГрузов Ложь = 1

5 Сухогрузы Ложь = 2

6 Наливные Ложь = 22

7 Навалочные Ложь = 3

8 Насыпные Ложь = 8

9 Генеральные Ложь = 13

Рис. 17. Представление в локальном регистре иерархии строк первичной формы

81

№3(21)2009

003#01C01

Ключ Группа Уровень

5 0

6 1 1

7 1 1

8 1 1

9 1 1

003#01F01

Ключ Название Вычисляемая Отношение Вершина

1 ВсегоПеревозка Ложь = 5

Рис. 18. Представление в локальном регистре иерархии столбцов первичной формы

гг

0 &

1

QJ »

3

I

I в

IS &

I

0 € 3

1 £

ALTER TRIGGER [dbo]. [chkInsUpd_003j|l01S01] ON [dbo].[003#01S01] FOR INSERT, UPDATE

DECLARE @TblName varchar(9)

y*****************************************************^

SET 0TblName=1003#01S011 /ж****************************************************/

DECLARE| @Nod int, @RC IHT

DECLARE nod_keys CURSOR LOCAL FAST_FORWARD FOR SELECT Ключ FROM inserted OPEN nod_keys

FETCH NEXT FROM nod_keys IHTO GNod SET 0RC=O

WHILE @RC=0 AND 0@FETCH_STATUS =0 BEGIN

EXEC 0RC =mn_chkcycles 0TblName, 0Nod

IF 0ROO RAISERROR ('Введенное значение порождает циклическую группу1,15,1) ELSE FETCH NEXT FROM nod_keys INTO 0Nod

END

CLOSE nod_keys DEALLOCATE nod_keys

»a

0

1

0 a гг

C3

1

S

C3

e £

IF 0RC=O EXEC mn_setnestlevels 0TblName — обновление поля УРОВЕНЬ Рис. 19. Триггер обновления таблицы метаданных наблюдения

мой процедурой тп_сИксус!еБ (рис.20), либо (в отсутствие нарушений) заносит в столбец Уровень таблицы для всех вершин значение, вычисленное хранимой процедурой тп_$е:пе$:!еуе!5 (рис. 21).

В таблице 003#01А01 специфицируются значения в клетках формы. Например, запись на рис. 22 означает, что в клетку на пересечении строки 21 «Контейнеры в ДФЭ»1 (Груз = 21) и столбца «Всего грузов» (Со!1с1 = 5) обязатель-

ДФЭ—двадцатифутовый эквивалент.

82

№3(21)2009

ALTER PROCEDURE [dbo]. [mn_chli cycles] BTblName varchar(9), BNod int AS

y******************************************************************************************************************************

Тест наличия цикла e деревообразной структуре, описываемой таблицами GGroupsTable (родительские вершины)и BHodsTable ¡подчиненные вершины) для вершины Gnod| подчиненной вершине Sgroup

DECLARE BtbllnfDat char(1),BtbllnECol char(l), BtbllnEColGrp char(l), BtblIn£Rora char(l), BtbllnERoraGrp char(l)

SELECT BtblInfDat=tblInfDat,BtblInfCol=tblInfCol, BtblInfColGrp=tblInfColGrp, BtblInfRora=tblInfRow,BtblInfRoraGrp=tblInfRoraGrp

IF dbo. fn_tbltype (BTblHame) =BtblInfRow SET BTblGrpHame=RTRIM (REPLACE (BTblName,BtbllnfRow, BtbllnfRowGrp )) —rows ELSE SET BTblGrpHame=RTRIH (REPLACE (BTblName, Btbllnf Col, BtbllnfColGrp )) —columns

IF (SELECT COUNT(-) FROM tempdto. dbo. SYS OBJECTS WHERE name= ' ¡(¡»TblHods ' )>0 DROP TABLE »ITblHods

EXEC ( 1 INSERT INTO ijfTblNods SELECT А.Ключ, Вершина FROM monitor.dbo. [' + ВТЫНате+'] A IHHER JOIH ['+BTblGrpHame+

WHILE 6CycleErr=0 AND (SELECT PrntHod FROM »»TbUIods WHERE Hod= 0CrntHod) IS HOT HULL IF BCrntNod» (SELECT PrntHod FROM MTblNods WHERE Nod= BCrntNod)

SET BCrntHod=(SELECT PrntHod FROM »¡¡¡TblHods WHERE Hod= BCrntNod)

CO

0 %

1 §

Рис. 20. Хранимая процедура проверки корректности описания иерархий

ALTER PROCEDURE [dbo]. [mn_setnestlevels] BTblName varchar (9) AS /±*±±±±±*±±*±±±±±*±±*±±±±±*±**1:±±±±*±±*±±±±±*±**1:±±±±±±**±±±±±*±**±±±±±±±**±±±±±±±**±±±±±±±*±±±±±±±±**±*±±±±±*1:**±±±±±*±±*±±±±±*± Обновляет значение столбца УРОВЕНЬ в служебной таблице BTblName Код возврата

0 - нормальное завершение

1 - неверный формат имени таблицы

2 - неверный тип таблицы

3 - таблица BTblName в базе отсутствует

DECLARE OCrntHod bigint, @Nod int, BLevel int, BTblGrpHame varchar(40), BSQLstr varchar (1000)

DECLARE BValue int, GtbllnfDat char(l), BtbllnfCol char(l), BtbllnfColGrp cbar(l), BtbllnfRorc char(l), BtbllnfRowGrp char(l) SELECT BtblInfDat=tblInfDat, BtblInfCol=tblInfCol, BtbllnfColGrp=tblInfColGrp, 8tblIn£RoB=tblIn£Roo, 6tblInfRo4iGrp=tblIn£RowGrp FROH mon_constants

/*ПР0ВЕРКИ* ************************************************************************************************************ ********** / IF NOT dbo. fn_tblnmvalid (BTblName) = 0 RETURN (1)

IF dbo.fn_tbltype (BTblHame) NOT IN (BtbllnfRow, BtblIn£Col ) RETURN (2)

IF (SELECT С0ШЩ*) FROH sysobjects WHERE xtype='u' AND Name=BTblName) =0 RETURN (3)

IF dbo.£n_tbltype (BTblHame)=BtblInfRow SET BTblGrpHame=RTRIM(REPLACE(BTblHame,BtbllnfRow,BtbllnfRowGrp) ) —rows ELSE SET GTblGrpHame=RTRIH (REPLACE (BTblHame, BtbllnfCol,BtbllnfColGrp) ) —columns

IF (SELECT C0UNT(*) FR0H tempdb. dbo. SYS0BJECTS WHERE name= ' ¡¡»TblNods 1 )>0 DROP TABLE »»TblNods CREATE TABLE »(TblHods (Hod int, PrntHod int)

EXEC (1IHSERT IHTO t»TblHods SELECT А.Ключ,Вершина FR0H ['+BTblHame+1 ] A IHNER JOIN ['+вTblGEpHame+, ] В ОН А. Группа=В.Ключ1) DECLARE Hods CURSOR LOCAL FAST_F0RWARD FOR SELECT Nod FR0H iWTblNods OPEN Nods

FETCH NEXT FROM Nods IHTO BHod

WHILE B@FETCH_STATUS=0 —по каждой вершине (записи таблиш-описателя) BEGIH

SET BLevel=0 SET BCrntNod=BNod

WHILE exists (SELECT * FROM ¡MTblHods WHERE Hod- BCrntNod) BEGIH

SET BCrntNod= (SELECT PrntNod FR0H ¡»»TblHods WHERE Hod= BCrntNod) SET @Level=GLevel+l

EHD

SET BSQlstr-'UPDATE [' +STblHame+' ] SET Уровень»'+cast(BLevel as varchar) +' WHERE Krac4='+cast(BNod as varchar) EXEC (BSQLstr )

FETCH HEXT FR0H Nods IHTO BNod

END

EXEC ('UPDATE ['+BTblName+' ] SET Уровень=0 IHERE Группа IS HULL') RETURN (0)

Рис. 21. Хранимая процедура вычисления номера уровня иерархии

83

№3(21)2009

Груз ColId Накопление Наличие Формат ДоменТаблица ДоменКлюч ДоменКод

21 5 True True 56 NULL NULL NULL

Рис. 22. Пример описания отдельного значения формы наблюдения

»

0

1 »

а € о

х §

3 §■

§

€

S s

>а

0

1

о а

€ &

%

а а

!

<3 =1

ное значение (Наличие=Тгие) вносится нарастающим итогом с начала года (Накопление = True) в формате целого числа (Формат = 56, код типа «int» столбца xtype системной таблицы systypes).

Если значения выбираются из домена, то для указания домена (таблицы) предусмотрены столбцы ДоменТаблица (имя таблицы), Домен-Код (имя столбца со значениями), ДоменКлюч (имя ключевого столбца).

Организационно-управленческая информация

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

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

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

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

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

Каждый пакет содержит три информационных раздела.

Реквизиты пакета идентифицируют:

• канал и тип пакета;

• отправителя согласно соответствующему регистру системы;

Канал

Пакет

Среда информационного обмена

1 г

Канал

Пакет

Канал

Пакет

Учетные реквизиты

л

Опции оформления

Данные наблюдения

Л

Рис. 23. Структура донесения с результатами наблюдения

84

№3(21)2009

jn_impfiles

9 [Key] ActNo Pack

ExecOrder

FileFormat

TargetDB

TargetTable

ObjectGroup

ObjectRef

PagedData

AllObjects

AIIMeasures

ObjMaxErrLev

AllowErrRecs

ReplaceAIIRecs

IgnoreNullRecs

Description

jn_reporters

f Pack f Reporter Email Source

jn

_reportersobjects

Pack Reporter ObjectGroup ObjectKey

jn_packparms

f Pack y Parm Description

jn_parmregistry

1 [Key] Name xtype SeqNo Exp VwExp Imp Vwlmp MonTableCol Length Mask

Description

jn_expfiles

V [Key] Pack ActNo ExecOrder FileFormat DataSrc DataPrc Description

jn_objectgroups

% [Key] Object DB ObjectTabie ObjectKeyFid ObjectVwFld_l ObjectVwFid_2

ce

Se

I £ a: =c

jn packs

? [Key]

PackID

Channel

InOut

ExtRefCode

Span

FileActLen

WildSmb

AutoExec

SendReply

SendPack

FilMaxErrLev

FullPack

Description

Enabled

SysReady

jn_packspartitions

\1 Pack \1 MonPart

jn_fileformats

f [Key] Format Exp Imp

jn_packflags

PackKey 9 Year f Period Opened Closed

jn_channels

4! [Key] Acronym ActNo PacklDlen SeparatorSmb WildSmb Default olAddressLists mlArch ollmp olExp olUsed olSpam wnlmp wnExp wnUsed wnSpam wnDirTemp flPrtLogDir flPrtLogPfx flPrtLogExt flPrtLogSep Создана Изменена Description

Рис. 24. Модель информационного взаимодействия

85

№3(21)2009

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

• дату формирования (отправки);

• цифровую подпись отправителя (возможно).

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

• формат файла из установленного стандартами перечня (xls, mdb, dbf);

• представления данных наблюдения в книге Excel в виде одного листа со стандартными структурой и именем или в виде нескольких листов, по одному листу на каждый объект наблюдения (порт, стивидор, автодорога) согласно регистру объектов, закрепленных за репортером, и задавать другие режимы.

Для указания реквизитов и опций могут использоваться различные свойства используемой модели объектов. В описываемом варианте они заносятся в структурированном g виде в поле ТЕМА (Subject) почтового сооб-

VJ

щения.

0

^ Первичные данные содержатся в файлах, со-| вокупность, организация и форматы специфи-§; цируются для каждого пакета выбором из воз-

1 можного для данного пакета перечня. Файл мо-§ жет представлять собой:

2 • раздел получаемого от репортера отчета | с данными наблюдения;

• записи обновления для одного из систем-

3 ных регистров пакета, получаемого от постав-1 щика информации для регистров;

| • итог выполнения каталогизированного ! запроса к базе статистических данных пакета, 53 предназначенного для пересылки/передачи пользователю (информационного продукта § системы).

5? Вся информация по информационному взаимодействию хранится в таблицах, специ-% фицирующих: « • каналы; Е? • пакеты;

• параметры учетного раздела пакета (для | всех пакетов);

■Ц: • закрепление репортеров за пакетом (для s всех пакетов);

• типы объектов наблюдения, осуществляемого отправителем пакета (для всех пакетов);

• файлы данных для каждого пакета;

• закрепление объектов наблюдения, осуществляемого репортером, за каждым файлом данных пакета (для всех пакетов).

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

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

На рис. 25 показан пример формы описания канала информационного взаимодействия.

На вкладке Общие (а) указываются учетные сведения о канале, вкладка Формат (б) используется для определения структуры имен основных относящихся к работе канала объектов, вкладки Почта (в) и Диск (г) позволяют определить параметры местоположения основных системных объектов.

На рис. 26 показан пример графического интерфейса описания пакета.

После выбора (форма а) из списка пакетов, определенных для данного канала (004) конкретного пакета (рис. 26 — список входящих пакетов включает один пакет) и выбора опции свойства задаются значения параметров пакета. На вкладке Общие (б) устанавливаются периодичность, состав и форматы параметров учетной строки, режимы автоматической обработки данных наблюдения. На вкладке Отчеты (в) специфицируются состав, организация и форматы файлов с отчетными данными с указанием объектов наблюдения и обновляемые ими таблицы базы данных. На вкладках Наблюдатели и Закрепления (на рис. 26 не показаны) формируются реестры репортеров и перечней закрепляемых за каждым репортером объектов наблюдения.

86

№3(21)2009

«о

0 х

1

о ■§■

а: а:

Рис. 25. Форма описания канала информационного взаимодействия: а — Общие; 6 — Формат; в — Почта; г —Диск

87

а

6

в

г

№3(21)2009

Новый Удалить ^ Свойства

а

5

I

I

3

I

I

I

I §

Рис. 26. Экранная форма описания пакета информационного взаимодействия: а — Выбор из списка пакетов; б — Общие; в — Отчеты

88

б

№3(21)2009

Системные таблицы

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

топ_еуеп:!од — журнал событий; топ_еуепНуре5 — словарь событий; топ_тв55адв5 — сообщения программ обработки и диалога;

топ_соп5:ап:5 — константы; топ_5вШпд5 — установки параметров;

топ_реор1е — реестр администраторов и пользователей системы;

топ_го!в5 — виды взаимодействия с системой.

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

Аналогичным образом в журнал помещаются записи о каждом событии из перечня, хранящегося в словаре системных событий (рис. 27).

Ключ Код Описание

3 41 Регистрация поступления отчета

4 51 Ввод/корректировка данных

5 43 Удаление отчета

6 52 Логическое тестирование данных

21 201 Начата обработка сообщения из папки ждущих сообщений

22 202 Закончена обработка сообщения из папки ждущих сообщений

Рис. 27. Фрагмент таблицы топ_еуепНуре$

Бг^ БггТуре БггМБд

«о

0

1

I

а: а:

200 N111.1- Ошибки подготовки файла с записями-предписаниями *****************************

201 Б Неверный учетный номер обновляемой таблицы

202 Б Неверный учетный номер раздела базы данных

204 Б Неверный формат отчетного года

205 Б Неверный формат отчетного периода

206 Б Неверный учетный номер базы данных

212 Б Таблица данных в файле обновления (файле базы данных) не обнаружена

215 Б Отчетный год вне допустимого диапазона

216 Б Отчетный период вне допустимого диапазона

217 Б Не указан период

218 Б Неверный формат отправителя

219 Б Отправитель отсутствует в системном реестре

220 I Файл отчета уже обработан перед прерыванием программы обновления

(протокол прилагается)

221 Б Обработка отчетов за указанный период в настоящее время невозможна

222 W Производится повторное обновление БД данным файлом, возможно появление непре-

дусмотренных сообщений

Рис. 28. Фрагмент таблицы топ_те$$аде$

89

№ 3(21) 2009 ^

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

Таблица 5у5те55аде5 хранит тексты выводимых сообщений. Сообщения таблицы для удобства разбиты на группы, идентифицируемые одинаковыми цифрами числа сотен в поле БггЫитЬег. Заголовками групп служат записи со значением ШИ в поле ЕггТуре. Например, на рис. 28 показана группа 2ХХ сообщений.

Таблицы 5у5реор!е и 5у5го!е5 нужны для управления работой пользователей со средствами системы на прикладном уровне (в частности, задания прав доступа пользователей к локальным регистрам).

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

с Автоматизированная технология

§; Ограниченные размеры статьи не позволя-| ют провести рассмотрение решений для всех § подсистем поддержки (см. рис. 8). Кратко рас-2 смотрим один из наиболее затратных по врезе мени и усилиям этапов — обновление базы

данными поступившего пакета.

а На рис. 29 показана логическая последова-

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

| дого периода наблюдений.

г>

Е; В промежутке между сеансами взаимодей-53 ствия (отчетными кампаниями) метаданные системы корректируются в соответствии с про-§ исшедшими изменениями в составе переменна ных наблюдения, первичных формах, закреплении определенных объектов за наблюдате-% лями и т. п. Регламент может предусматривать « обновление как на регулярной основе, так Е? ив зависимости от потребностей конкретного

наблюдения. | В контрольных точках, определяемых гра-■Ц: фиком наблюдения в соответствии сустанов-ленной дисциплиной, проводится проверка

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

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

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

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

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

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

На рис. 30 показана блок-схема обновления базы данными отдельного отчета за очередной период наблюдения (затененный блок на рис.29).

Выполнение всей последовательности шагов можно полностью автоматизировать. В разработанном опытном образце этап реализует-

90

№3(21)2009

91

№3(21)2009

Отчет

гг

0

1 »

а € о

х §

§ §■

I €

I £

>а о

ас

0 а

г

€ &

%

а а

1

<з =1

Рис. 30. Обработка отчета с данными наблюдения

92

ся группой из нескольких довольно большого размера хранимых процедур MS SQL Server с нетривиальной логикой. В частности, обработка включает проведение проверок:

• корректности задания учетных реквизитов пакета (сообщения),

• соблюдения регламента (в частности, регистр наблюдения должен быть открыт на прием донесений);

• корректности задания учетных реквизитов файлов;

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

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

• отсутствия повторяющихся записей (строк) первичной формы;

• присутствия всех записей (строк) первичной формы;

• присутствие объектов наблюдения, указанных в файле, в реестре наблюдения;

• отсутствия в файле наблюдения обязательных записей об объектах реестра;

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

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

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

• соблюдения отношений в группах внутри записи файла (строковый контроль);

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

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

Опытная реализация

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

№ 3(21) 2009

«о

ных данных. Для исследований были загруже- * ны записями таблицы юридических лиц (около g 1500 записей), административно-территори- Jj. ального деления (записи по всем странам ми- а£ ра, округам и регионам РФ, около 700 записей =с для населенных пунктов), около 30 таблиц нормативной информации и классификаторов глобального регистра и созданы локальные регистры для десятка форм статистического наблюдения за работой транспорта. В таблицы нескольких регистров были внесены записи по нескольким периодам наблюдений.

Одним из основных объектов интереса являлся вопрос о степени общности предлагаемой концепции, т. е. возможности применения стандартов без существенных «подгонки» (или ослабления) специфических требований относительно результатов и регламента проведения наблюдений в «прокрустовом ложе» построенной инфраструктуры. Несмотря на то что реализационные принципы позволяют в соответствующих случаях добавить нестандартные компоненты (но по стандартным правилам), которые могут обеспечить учет любой специфики, такой необходимости практически для всех наблюдений выбранной совокупности не возникало.

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

93

№ 3(21) 2009 ^

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

Общеизвестно, что даже хорошо зарекомендовавшие себя методы анализа и принятия решений могут быть бесполезны, если не выполняется основное условие ихуспешной применимости — наличие достоверных и точных исходных данных. Не менее важно при этом учитывать и чисто практические вопросы ре-2 шения задачи получения необходимых сведе-

0

ний. К таковым, в первую очередь, следует от-

^ нести построение эффективной структуры

| управления процессами сбора, организацию

§; сбора и хранения данных в виде, позволяющем

| пользователям получить удобный доступ

§ кданным, атакже минимизацию суммарныхза-

2 трат на создание и эксплуатацию системы на-

| блюдения.

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

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

5? Разумеется, наибольший эффект применения результатов, который характеризуется,

% в частности, высоким уровнем автоматизации

« работы системы, достигается при внедрении Е? всего комплекса архитектурных, методологических и проектных решений. Вместе с тем, ис-

| пользование полученных результатов не пред-

■Ц: полагает обязательного принятия радикаль-

^ ных решений по отношению к реально рабо-

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Анфилатов В. С., Емельянов А. А., Кукушкин А. А. Системный анализ в управлении. М.: Финансы и статистика, 2005.

2. Гарсиа М. Ф., Рединг Дж., Уолен Э., Де Люк С. А. MS SQL Server 2000: справочник администратора. М.: Эком, 2004.

3. Chris Graves et al. Professional SQL Server 2000 Data Warehousing with Analysis Services, Peer Information Inc., 2001.

4. ПрагК.Н., Ирвин М. Р. Access 2002. Библия пользователя / пер. с англ. М.: Вильямс, 2003.

5. Гандэрлой М. ADO и ADO. NET: полное руководство / пер. с англ. М.: Корона, 2003.

6. УокенбахДж., Андердал Б. Excel 2002. Библия пользователя / пер. с англ. М.: Вильямс, 2003.

7. Общая теоретическая статистика / под ред. А.А.Спирина, О. Э. Башиной. М.: Финансы и статистика, 1996.

8. СизоваТ. М. Статистика: учеб. пособие. СПб.: ГУИТМО, 2005.

9. ReddyS. M, Khan V. Comparative Analysis of OnLine Analytical Processing Tools. Master Thesis in Applied Information Technology. IT-University of Gote-borg, Goteborg, Sweden, 2007.

10. Providing OLAP (OnLine Analytical Processing) to User-Analysts: An ITMandate.E. F. Codd& Associates, 1993.

94