CC BY
64
8. Schirmer, N. Verification of Sequential Imperative Programs in Isabelle/HOL [TeKCT]/N. Schirmer//PhD thesis. -Technische Universität München, 2006.
9. Norrish, M. A formal Semantics for C++ [TeKCT]/M. Norrish//Technical report, NICTA.-2008. -P. 1-125.
10. Cohen, E. A Precise Yet Efficient Memory Model For C [TeKCT]/E. Cohen, M. Moskal, W. Schulte [et al.]//4th International Workshop on Systems Software Verification (SSV2009)-2009.-P. 20-29.
11. Hoare, C. Procedures and parameters: An axiomatic approach [Текст]/С. Hoare//Lecture Notes in Mathematics-1971.-Vol. 188.-P. 102-116,
12. Непомнящий, В.А. На пути к верификации С-программ. Язык С-Light и его трансформационная семантика [Текст]/В.А. Непомнящий, И.С. Ануреев, А.В. Промский//УкрПРОГ-2006.-С. 23-25.
13. Mechta, F. Proving pointer programs in higherorder logic [Текст]^. Mechta, T. Nipkow.-2003.-Vol. 2741.-P. 121-135.
УДК 004.658.6
И.В. Бутенко, С.М. Устинов
методика построения репозитория метаданных
для существующей информационной системы
В современных информационных системах накоплено большое количество данных, и извлечение нужной информации из таких систем часто связано с недопустимыми затратами времени и средств. Для того чтобы добыть информацию, необходимо знать, какие именно данные уже есть, где они находятся и как могут быть получены.
В связи с этим при создании новых информационных систем разработчики используют аппарат, базирующийся на метаданных (МД). Он предоставляет возможности описания и манипулирования метаданными в рамках либо общей модели CWM (Common Warehouse Metamodel), сформированной группой OMG (Object Management Group), либо модели конкретной метасистемы (МС).
Этим вопросам посвящены многочисленные работы ученых как в нашей стране, так и за рубежом (Д. Марко, А. Танненбаум, Р. Кимбалл, Б. Инмон), а также такие программные продукты, как Oracle Data Integrator , IBM Information Server, SAP BusinessObjects Metadata Manager, CA ERwin Saphir Option, SAS® Metadata Server.
Однако в настоящее время существует большое количество информационных систем, в которых отсутствует описание МД, используемых в системе, либо такие данные не являются полными. Такие системы или развиваются с большим трудом (очень большие вложения при минимальных результатах) или не развиваются вовсе, поскольку отсутствует информация не только о том,
что, где и как хранится, но и по каким алгоритмам работает. Часто судьба таких систем - это медленное умирание. Рядом с ними строятся хранилища данных, которые не достраиваются в силу той же проблемы.
Особую потребность в МД испытывают быстро меняющиеся информационные системы. Например, такими системами являются банковские, бухгалтерского учета и аналитические.
Выход из создавшегося положения - построение МС на основе уже существующих информационных систем. Она должна позволять сформировать общее информационное пространство и обеспечивать дальнейшее развитие системы. Это, в свою очередь, требует разработки сопутствующих методов, алгоритмов и программного обеспечения. Решению указанных вопросов и посвящена данная статья.
Формализация задачи
Остановимся более подробно на логической архитектуре системы и возможностях, которые она должна предоставлять. Предлагаемая МС, по сути, является расширенным репозиторием метаданных (рис. 1). В ней хранится информация о бизнес-процессах, бизнес-логика, описания структур и полей существующей базы данных (БД).
Из внешних источников метаданные загружаются в МС. Наиболее эффективна данная система именно для разнородных информационных си-
Рис. 1. Схема взаимодействия в рамках метасистем
стем, где данные лежат в различных источниках как связанных друг с другом, так и автономных. В МС попадают не только описания структур источников, но и комментарии к ним, которые могут подхватываться из скриптов создания самих структур, загружаться из документации и вводиться пользователем вручную. В процессе работы с МС разработчики или пользователи формируют запросы и получают отчеты. В качестве разработчика может выступать как непосредственно программист, так и бизнес-аналитик, которому для осознания того, что и как необходимо сделать, нужна информация о том, что уже сделано. На основе ответов разработчик может вносить изменение в описание уже существующих бизнес-процессов. При этом информация о внесении изменений тут же попадает в саму МС. Таким образом. данные в ней обновляются не периодически, а постоянно, как только произошли изменения во внешнем источнике. Такой механизм дает пользователям уверенность в том, что они работают с актуальной информацией, и им не нужно тратить дополнительные время и средства на проверку актуальности данных.
Основным пользователем такой МС будет Разработчик, человек, которому необходимо внести изменение в бизнес-логику. Метасистема призвана облегчить разработку новых возможностей описываемых систем, что, в свою очередь, позволит сократить трудоемкость, и, соответственно, стоимость самой разработки. Таким образом, программный продукт, который использует МС, становится более конкурентоспособным на рынке.
Другой вид использования такой системы -ответы на вопросы о том, где именно и как в системе можно выполнить те или иные действия. Также эта система выполняет функцию поддержки процесса документирования проекта. Необходимую информацию пользователь может вывести в качестве печатной версии отчета.
Разрабатываемая МС должна обеспечить решение следующих задач:
построение единого хранилища и описание всех объектов существующей Системы;
возможность классификации и поиска необходимой информации;
обеспечение отслеживания версий объектов БД на сервере;
повышение уровня языка доступа к данным -возможность строить запросы из МС;
создание базиса для построения Федеративных систем или Хранилища данных (ХД).
Метасистема строится при следующих ограничениях на область дальнейшего применения.
1. Ориентация на SQL-ориентированные Системы. В качестве стандарта для таких систем есть язык написания запросов: Ansi SQL. В данной статье применяется расширение стандарта Ansi SQL, используемое в Microsoft SQL Server. При этом, в силу специфики МС, алгоритмы наполнения информацией МС могут быть приведены к любому расширению языка T-SQL без больших затрат (для некоторых расширений без доработок).
2. Автоматическое наполнение МС производится только за счет информации, содержа-
щейся в БД Системы. Такое ограничение позволяет не сужать область применения МС. Так как создается продукт, который не ориентирован на конкретную СУБД, необходимо сделать его независимым от конкретной реализации клиентского приложения. К сожалению, не существует общего стандарта на написание такого рода приложений. Поэтому в предлагаемую МС загружается только серверная часть логики приложения.
Таким образом, в статье предлагается строить репозиторий МД, в качестве исходных данных для которого являются МД, загружаемые из уже существующих информационных систем. Следовательно, загружаться будут только актуальные данные - то, чего нет в системе, не может попасть в репозиторий.
Реализация данного подхода может быть формализована в виде методики, включающей следующие этапы.
Разработка структуры БД МС. Необходимо разработать структуру самой базы данных МС, что, в свою очередь, требует построить модель объектов, хранящихся в системе.
Разработка модели классификатора как элемента структуры базы данных МС.
Загрузка метаданных. Необходимо разработать алгоритм загрузки данных в структуру данных, предложенную на предыдущем этапе. С этой целью предлагается модель загрузки объектов в МС.
Построение дерева классификатора. Для качественного функционирования репозитория МД необходима подсистема настройки классификаторов. Это требует построения модели, опирающейся на модель данных из следующего раздела.
Дальнейшее использование (организационные мероприятия). Максимально эффективное использование МС подразумевает выполнение целого ряда организационных мероприятий.
Выбор средств реализации МС. Для реализации МС необходимо выбрать следующие программные средства: СУБД, средства загрузки данных, средства реализации клиентского приложения.
Рассмотрим последовательно каждый из этапов построения МС.
Разработка базы данных метасистемы
Разработка модели объектов и классификаторов. Из требований к разрабатываемой МС следует, что в качестве объектов рассматривают-
ся основные сущности БД: таблицы, хранимые процедуры (ХП), колонки таблиц, параметры процедур, типы данных и их описания.
Любой объект может быть описан в следующем виде:
0=<п,и{0}Р,С>, где п - имя объекта (в терминах БД); t - тип объекта (таблица, ХП, колонка, параметр ХП); Р -параметры объекта, необходимые (и, может быть, достаточные) для построения объекта 0 на базе; С — описание объекта.
Описание объекта может включать описание других объектов (таблица описывается через колонки).
Р - вектор четко заданной последовательности параметров.
Р={р}, где р. - значение параметра г из вектора типов параметров П={п1}.
С - вектор четко заданной последовательности описаний.
С={с.}, где с. - значение параметра г из вектора типов описаний К={к.}.
Пример. Опишем таблицу кодов валют ссу-codes, у которой есть три колонки ссу (символьный код валюты), ссп (числовой код валюты), ссу_пате (наименование валюты).
Occycodes=<ccycodes, таблица, Occycodes. ссу, 0ccycodes.ccn, 0ссусойв$.ссу_пате, Pccycodes, Cccycodes>
Occycodes.ccy=<ccy, колонка, Рссу, Сссу>
Occycodes.ccn=<ccn, колонка, Рссп, Сссп>
Occycodes.ccy_name=<ccy_name, колонка, Рссупате, Сссу_пате>
Параметры объекта. Количество элементов вектора Р может изменяться в зависимости от прикладной области, текущей задачи, требований к системе, среды окружения. Но при этом множество расширяется без больших затрат, поскольку все данные, которые хранятся в Р, четко определимы. Данные выбираются из БД или среды окружения.
Все элементы множества Р определяются автоматически, т. е. для загрузки объекта в МС не нужно дополнительно в исходной системе доопи-сывать какие-то параметры.
Для одного и того же типа объекта набор элементов векторов П и Р будет одинаков.
На основе Р строятся четко заданные классификаторы. Условие на попадание объектов в классификатор задается в виде обычного фильтра, в котором указывается параметр, операнд (жестко ограниченное количество) и значение.
По мере развития МС количество описанных параметров будет увеличиваться, а необходимость в расширении этого множества сокращаться. Таким образом, получаем, что для каждого проекта К+1 — К, где г - порядковый номер проекта.
Если в каком-либо из проектов не нужно обрабатывать все описанные в МС параметры объектов, то пользователь отключает в настройке наполнения МС ненужные параметры. При этом структура МС остается неизменной, поля для значений отключенного параметра остаются. Затраты на пополнение МС сокращаются, но пользователю предоставляется возможность в любой момет воспользоваться любыми (даже отключенными пока) параметрами МС. Если в какой-то момент они ему понадобятся, нужный параметр включается при настройке.
Задавая вектор Р для таблицы и колонок таблицы, возможно:
однозначно идентифицировать каждую таблицу и колонку в ней;
построить на любой базе таблицу аналогичной структуры;
строить запросы к исходной таблице, основываясь только на ее описании.
Описание объекта. Значения компонент вектора С - это всевозможные описания объекта О на языке пользователя. Таким образом, С - это основа МС, именно он служит для перевода пользователю описания системы с языка БД на язык пользователя. Количество элементов С условно постоянно. Изначально следует стремиться к тому, чтобы элементы С могли полностью описать объект О. Количество элементов С зависит от многих факторов: предметная область, полнота описания уже существующей БД, требования к системе и др. Но при этом, по мере развития МС и появления новых элементов С, которые ранее не использовались в предыдущих проектах, пользователю предоставляется возможность настраивать их при необходимости. В процессе эволюции МС появится возможность развивать исходные системы в плане расширения описаний их объектов. Таким образом, так же как и для множества П, получаем, что для каждого проекта К — К, где г - порядковый номер проекта.
В отличие от алгоритма добавления нового параметра в вектор Р, где не требуется никаких доработок исходной системы, при добавлении нового параметра в С, они могут потребоваться.
На основе вектора C строятся пользовательские классификаторы. Количество их четко не определено. Критерии отбора объектов под определенный классификатор пользователь вводит сам, руководствуясь набором правил задания классификатора. По этим правилам с использованием значений из C выбираются необходимые объекты. Язык задания классификаторов объектов можно сравнить с заданием расширенного поиска в Internet: указываются ключевые слова, конструкции, маски на строки.
Описание классификаторов. Определим классификатор системы следующим образом:
Q = {ю} ^ 0mc О, где ю - множество ограничений на множестве всех объектов O, позволяющее однозначно идентифицировать подмножество Ою.
Поскольку любой объект множества O может быть записан в виде О = <n,t,{O},P,C>, то описание ограничений должно состоять из пяти подмножеств Ю = (&n , Qt, {©}Юр , ©с) .
Из этого описания может быть исключено первое ограничение на наименование объекта. Оно может быть перенесено в юр, поскольку наименование объекта является подмножеством P.
Теперь рассмотрим более подробно рекурсивное описание объектов, а, соответственно, и ограничений. Для объектов рекурсия получается из условия, что объект описывается через другие объекты МС, при этом важно, что эти объекты всегда другого типа. Для задания ограничения на объект достаточно задать тип объекта, на который накладывается ограничение и само ограничение. В системе все описания объектов хранятся в двух множествах: P и C. Поэтому описание ю сводится к следующему ю = {ю^ юр, юс}.
В итоге получаем общую формулу описания классификатора Q = {ю^ юр, юс}.
Построение базы метаданных. Первым шагом построения МС является определение тех целей и задач, для которых будет строиться данная МС. Результатом формирования задач МС должен стать набор характеристик объектов, который будет храниться в репозитории. Предложенная модель говорит только о том, как представляются объекты системы, но не о том, какие именно данные мы будем хранить. Есть жесткие ограничения модели на хранимые данные. Так, описания объекта, содержащиеся в векторе P, должны быть предметнонезависимыми. То есть
Объекты 1 класса
РК Объект
Тип Свойства Р1 Свойства С1
Объекты 2 класса
РК РК,РК1 Объект Родитель
РК2 Свойства Р2 Свойства С2 Тип данных
Объекты 3 класса
РК Объект
Свойства РЗ Свойства СЗ
Рис. 2. Связи объектов
там содержатся описания самого объекта как физического файла на диске и объекта БД, но нет привязки непосредственно к предметной области. Таким образом, свойства Р должны быть заполнены всегда, причем заполняться они должны в автоматическом режиме. Свойства, описываемые через С, наоборот, полностью зависимы от предметной области. Здесь основная нагрузка ложится на пользователя. Именно он должен сформулировать, откуда получать то или иное значение. Если же данных пока нет, то пользователю придется их вносить вручную.
Поскольку одна из важных особенностей разрабатываемой МС - ее расширяемость, то первые реализации МС выявили набор атрибутов, которые в большинстве своем покрывают основные необходимые свойства элементов системы. Приведем некоторые из них.
Элементы Птабл: дата создания; дата последнего изменения; пользователь, создавший объект; пользователь, изменивший объект.
Элементы Пкол: тип параметра объекта; длина параметра объекта; длина дробной части; возврат значения из процедуры; значение по умолчанию.
Также приведем рекомендуемые элементы К: пользовательское имя объекта; краткое описание объекта; полное автоматизированное описание объекта; пользовательский комментарий к объекту.
Поскольку МС разрабатывается на основе
данных реляционных СУБД и предполается, что в качестве ядра для МС будет выступать тоже реляционная СУБД, то проектирование БД МС производится с использованием аппарата реляционной алгебры.
Рассмотрим описание объекта МС: О = <п,^{0},Р,С>. Как уже отмечалось выше, вектор П является функцией типа t. Выделим следующие классы:
1. процедуры, функции, таблицы и представления;
2. параметры процедур и столбцы таблиц;
3. типы данных.
В результате анализа свойств объектов, входящих в каждый из классов, получается следующий вид связи объектов в БД (рис. 2).
Именно для такой архитектуры реализуется база данных МС.
Загрузка метаданных
Для обеспечения универсальности механизма загрузки предлагается специализированный формат, который является промежуточным звеном между МС и исходными данными (рис. 3).
При таком подходе можно разделить логику выгрузки данных из внешних источников и логику загрузки данных в МС. Несмотря на то, что количество шагов загрузки данных при этом увеличивается, логика упрощается. Так, требуется написать только один загрузчик данных в МС Е.
Рис. 3. Загрузка метаданных
Поскольку он будет получать данные в универсальном формате, его можно использовать при загрузке данных из любой системы. Более того, для загрузчика F нет различия в СУБД, на которой построена система-источник. Он «умеет» работать только с данными, представленными в универсальном формате.
Для построения подсистемы загрузки данных в МС, не зависящую от СУБД источника, на основе анализа предметной области и особенностей загружаемых МД предлагается следующий механизм работы.
Для реализации требований данные извлекаются не непосредственно из БД, а загружаются из внешних файлов на диске. Эти файлы - скрипты создания объектов БД. Получить такие файлы можно с помощью служб автоматического скрип-тования объектов в любой промышленной СУБД. Таким образом, обеспечиваются минимальные затраты на получение данных в универсальном формате.
Данные из внешних файлов загружаются в МС. При этом сама МС реализуется на некоторой конкретной СУБД. Для того чтобы минимизировать привязку к логике конкретной СУБД загрузка разобивается на два этапа:
1) синтаксический разбор внешних файлов и запись необходимых данных в интерфейсные таблицы;
2) загрузка данных из интерфейсных таблиц в таблицы МС.
При таком подходе реализация первого пункта не привязана ни к СУБД источника, ни к СУБД приемника. Единственное условие -сам синтаксический анализатор должен уметь «читать» скрипты конкретного языка SQL. Но в данном случае, поскольку представляет интерес не внутренняя логика скриптов, а только их описание, реализуется универсальный анализатор на основе синтаксиса стандарта SQL ANSI. Второй этап реализации привязан только к структуре МС и не взаимодействует с источником данных.
Дальнейшее использование
Отметим основные моменты, которые могут упростить построение и дальнейшее использование МС. Их можно назвать организационными мероприятиями, поскольку эти требования долж-
ны быть приняты в рамках всей организации, использующей МС.
Так, при подготовке исходной информации для загрузки необходимо максимально полно описать значения вектора C для выбранных типов описаний ветора K. Алгоритм работы с МС в таком случае следующий:
описание значений C для всех объектов системы;
загрузка данных в МС; первичная классификация данных; доописание объектов, если это необходимо в самой МС.
При этом, если в организации принят стандарт на оформление текстов с обязательным требованием писать комментарии, то необходимость в дополнительном описании просто отпадет.
В рамках этой статьи рекомендуется максимально полно использовать механизм пользовательских типов, встроенный в стандартные поставки большинства промышленных СУБД. С этой целью в исходной системе нужно выделить основные часто используемые домены. Для каждого такого домена следует завести свой пользовательский тип. Выделение доменов может производится в рамках самой МС. После первоначальной загрузки данных начинается выделение и классификация основных типов, которые в дальнейшем переносятся в сами объекты БД.
Практическое применение
В данной статье мы не будем подробно останавливаться на особенностях использования МС для конкретных прикладных задач. Отметим, что представленные решения были реализованы в рамках МС на основе СУБД MS SQL Server 2005. Загрузка объектов в МС выполнена с применением механизмов vbs-скриптов и хранимых процедур. Интерфейс системы выполнен на базе ядра учетной системы СКАУТ фирмы «Деловые консультации, Санкт-Петербург».
Построенная МС была включена в коммерческие программные продукты:
«СКАУТ-Навигатор» в качестве средства настройки и построения аналитической отчетности по выполняемым работам уборочной техникой в Санкт-Петербурге;
«СКАУТ-РБД» в качестве средства построения многомерных OLAP-отчетов для анализа деятельности торгового предприятия.
СПИСОК ЛИТЕРАТУРЫ
1. Бутенко, И.В. Реализация механизма загрузки метаданных в Microsoft Analysis Services [Текст]/ И.В. Бутенко, В.Э. Ковалевский/Технология Microsoft в теории и практике программирования.-СПб., 2010.
2. Бутенко, И.В. Метасистема, как основа доступа в неоднородной распределенной базе данных [Текст]/ И.В. Бутенко, А.А. Зотов, С.М. Устинов/Научно-технические ведомости СПбГПУ-2007.
3. Шовкун, А. Как повысить прозрачность аналитических систем и снизить их TCO [Текст]/А. Шовкун// Директор ИС.-2005.-№ 05.
4. Inmon, W.H. Metadata in the Data Warehouse [TeKCT]/W.H. Inmon.-White Paper, 2000.
5. Барсегян, А.А. Технологии анализа данных: Data Mining, Visual Mining, Text Mining, OLAP [Текст]/ А.А. Барсегян, М.С. Куприянов, В.В. Степаненко [и др.].-СПб.: БХВ-Петербург, 2007.
6. Черняк, Л. От данных к информации [Текст]/Л. Черняк//Открытые системы.-2006.-№ 02.
7. Спецификация «Общая метамодель Хранилища данных» [Электронный ресурс] http://www.getinfo.ru/ article198.html
