ИНФОВИЗОР OLAP-ДИЗАЙНЕР (ПРИЛОЖЕНИЯ)

ИНФОВИЗОР OLAP-ДИЗАЙНЕР (ПРИЛОЖЕНИЯ)

Содержание

Приложение 1. Концепция и реализация метаданных для инструмента аналитической обработки

Приложение 2. Использование аналитических метаданных для информационного наполнения и редактирования баз данных

Приложение 3. Описание демонстрационной базы данных

Приложение 1. Концепция и реализация метаданных для инструмента аналитической обработки

Концепция метаданных

За основу метаданных OLAP взято понятие многомерного гиперкуба. Измерениями (осями) гиперкуба могут быть любые способы консолидации данных, представляемые справочниками экземпляров некоторых объектов (множеством точек оси). Одним из измерений гиперкуба может являться время, что позволяет анализировать динамические процессы. Совокупность выбранных экземпляров от каждой оси однозначно характеризует ячейку гиперкуба в пространстве объявленных измерений. Каждая ячейка гиперкуба может содержать численное значение - показатель, - смысл которого определяется координатами ячейки - набором экземпляров, по одному от каждого измерения.

Получение значений показателей производится по результатам SQL запросов к Хранилищу Данных. Формальное описание автоматического процесса составления конкретных запросов для получения показателей заложено в таблицах метаданных OLAP. При этом сами показатели в терминах исходного Хранилища Данных могут являться функциями агрегирования или конкретными числовыми полями определенных таблиц.

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

Для обеспечения возможности рассматривать показатели с разными степенями агрегации реализация измерения, в общем случае, может быть выполнена с помощью различных конкретных справочников экземпляров - различных уровней измерения. Так, измерению "местоположение" можно поставить в соответствие несколько реализаций - уровень детализированного справочника СОАТО, уровень городов и районов, уровень субъектов Российской Федерации.

Для некоторых измерений методы получения значений определяемых ими слоев ячеек гиперкуба могут варьироваться в зависимости от выбора для рассмотрения конкретных экземпляров справочников этих измерений. Такие справочники (равно как и соответствующие им уровни измерения) будем называть группируемыми. В соответствии с этим любая ось может быть разделена на группы однородности. Крайними являются случаи совпадения всего множества экземпляров измерения с одной группой и соответствия каждого экземпляра измерения собственной единичной группе. Описание методов получения значений ячеек, принадлежащих слою гиперкуба, определенному группой однородности измерения, задается соответствующим этой группе отрезком однородности.

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

Для всех ячеек одного вектора однородности значения могут быть извлечены с помощью одного SQL запроса, который однозначно определяется правилом извлечения целевого значения для вектора и дополнительными условиями, заданными для отрезков однородности, соответствующих входящим в вектор группам однородности.
ПРИМЕЧАНИЕ. Диалоговый запрос пользователя к информационной модели, приводящий к формированию одного SQL запроса к базе данных, будем называть элементарным диалоговым запросом.

Результаты серии SQL запросов, сформированной по каждому конкретному оперативному заказу аналитика (диалоговому запросу), имеют совершенно идентичный формат, поэтому могут быть составлены в одну временную таблицу, которая в совокупности со справочниками измерений (уровней реализации измерений) может рассматриваться как самостоятельная база данных, имеющая схему звезды (Star Scheme). Тот факт, что центральная таблица этой БД является временной, то есть создается и заполняется по требованию аналитика в ответ на его нерегламентированный запрос, является основанием наименования описанного метода - "Концепция виртуальной звезды". Таким образом, предлагаемая концепция является целостным законченным оригинальным способом реализации гибких информационно-аналитических систем класса OLAP. Комплекс ИнфорВизор основывается именно на этой концепции.

Реализация

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

Для поддержания возможности поликубического представления информации метаданные OLAP содержат обобщающую таблицу IVSTARS, включающую список всех информационных моделей, созданных для рассматриваемой базы данных.
ПРИМЕЧАНИЕ. Термины "информационная модель" и "виртуальная звезда" используются в программном комплексе ИнфоВизор как синонимы.

Описание каждой виртуальной звезды в метаданных OLAP выполняется в группе реляционных таблиц, добавляемых в базу данных. Имя каждой из этих таблиц заканчивается числом n, равным значению поля id записи, соответствующей этой виртуальной звезде в таблице IVSTARS.

Структура таблицы IVSTARS
ПРИМЕЧАНИЕ. Здесь уникальный идентификатор (первичный ключ) таблицы выделен жирным шрифтом.

Название колонки Тип данных Разрешены значения NULL Описание id INTEGER нет уникальный автоинкрементный идентификатор виртуальной звезды (генерируется автоматически) name CHAR нет уникальный название виртуальной звезды alias CHAR нет уникальный псевдоним виртуальной звезды remark CHAR да примечание

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

• IVATTRS<n> - список всех возможных измерений максимально полного гиперкуба.
• IVLEVELS<n> - список всех возможных уровней обобщения атрибутов, перечисленных в IVATTRS<n>.
• IVLOCS<n> - список отрезков групп однородности справочников измерений (уровней реализации измерений).
• IVAREAS<n> - список областей однородности получения значений ячеек гиперкуба, методы извлечения показателей для которых определены.
• IVCORRS<n> - таблица достаточных условий построения запросов.
• IVLEGALS<n> - таблица необходимых условий построения запросов.

Приложение 2. Использование аналитических метаданных для информационного наполнения и редактирования баз данных

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

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

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

Способы наполнения баз данных средствами комплекса ИнфоВизор

Комплекс ИнфоВизор предлагает три способа наполнения баз данных.

1. Из существующих БД с помощью системы ИнфоВизор Интегратор по подготовленным сценариям загрузки данных. Этот способ является основным и предусматривает наличие баз данных - источников, сведения из которых однократно или периодически пополняют центральное хранилище данных.
2. Оперативная загрузка и редактирование данных из системы ИнфоВизор Навигатор. Этот способ возможен при наличии в БД навигационных метаданных и удобен для управления детализированными данными.
3. Табличная загрузка численной информации через формы ввода. Этот способ возможен при наличии в БД аналитических метаданных, допускающих редактирование информации. Форма ввода может быть сохранена в формате таблицы Excel (*.xls) из системы ИнфоВизор Аналитик и передана для заполнения на любую рабочую станцию, где имеется установленный продукт Excel. Заполненная форма ввода может загружаться в БД с помощью системы ИнфоВизор Комбайнер (см. руководство по этой системе).

Табличный ввод численной информации в базу данных с использованием формы ввода Excel

Это один из способов наполнения БД, используемых в комплексе ИнфоВизор. Он возможен при наличии в БД аналитических метаданных, допускающих редактирование информации.

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

1. В системе ИнфоВизор Аналитик строится запрос, в ответ на который должны быть получены искомые данные. На момент выполнения запроса самих этих данных в базе может не быть, или они могут иметься не полностью, поэтому отчет может оказаться пустым. Чтобы пустые ячейки не были автоматически исключены из отчета, рекомендуется снять индикаторы состояния "Скрывать отсеянные терминальные узлы" для обеих осей в окне оформления отчета. Следует помнить, что загрузка данных может производиться только в те области многомерной информационной модели, для которых разрешено редактирование.
2. Полученная кросс-таблица сохраняется в виде формы ввода Excel.
3. Сохраненный файл передается для заполнения тому, кто владеет соответствующей информацией. После заполнения в среде Excel этот же файл возвращается администратору информационной системы на то рабочее место, где была сохранена форма ввода (шаг 1). Примечание: Если загрузка заполненной формы в базу данных должна быть выполнена с другого рабочего места, на нем должен быть создан псевдоним (alias) БД с точно таким же именем, как и тот, к которому была подключена система ИнфоВизор Аналитик во время построения формы ввода.
4. Заполненная форма открывается в системе ИнфоВизор Комбайнер (см. руководство по этой системе) и загружается в базу данных. О возможных ошибках во время загрузки можно узнать по системному журналу этой программы.

Приложение 3. Описание демонстрационной базы данных

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

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

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

• значения полей базы данных численного типа (предварительно агрегированные значения);
функции агрегирования SQL (avg, count, max, min, sum, а также другие функции агрегирования, поддерживаемые SQL-сервером);
любые SQL-выражения, имеющие на выходе одно численное значение.

Исходная информация

Информация в демонстрационной базе IVREESTR хранится в следующих таблицах.

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

Имя поля Тип поля Ссылка Допустимость NULL Примечание sved_arc _id integer   нет Уникальный идентификатор исторической записи sved_id integer нет Уникальный идентификатор юридического лица soato char(10) soato. soato_code нет Код территории okonh char(5) okonh. okonh_code нет Код вида деятельности kfs char(2) kfs_olap.code нет Код формы собственности kopf char(2) kopf_olap.code нет Код организационно-правовой формы sved_ins date нет Дата начала действия записи sved_del date нет Дата окончания действия записи

soato. Иерархическая таблица административно-территориальных образований Российской Федерации.

Имя поля Тип поля Ссылка Допустимость NULL Примечание soato_code integer нет Уникальный идентификатор (административно-территориального объекта) naim char(50) нет Наименование территории node integer soato. soato_code да Код родительского объекта

okonh. Таблица видов деятельности. Организована в виде иерархического справочника.

Имя поля Тип поля Ссылка Допустимость NULL Примечание okonh_code integer нет Уникальный идентификатор (код вида деятельности) naim char(200) нет Наименование вида деятельности inform char(255) да Дополнительная информация о виде деятельности node integer okonh. okonh_code да Код родительского объекта

kfs_olap. Таблица форм собственности. Организована в виде иерархического справочника.

Имя поля Тип поля Ссылка Допустимость NULL Примечание code char(2) нет Уникальный идентификатор name char(90) нет Название формы собственности node char(2) да Код родительского объекта grnum integer да Поле группы sortnum integer да Поле сортировки

kopf_olap. Таблица организационно-правовых форм. Организована в виде иерархического справочника.

Имя поля Тип поля Ссылка Допустимость NULL Примечание code char(2) нет Уникальный идентификатор name char(160) нет Название организационно-правовой формы node char(2) да Код родительского объекта grnum integer да Поле группы sortnum integer да Поле сортировки

Аналитические метаданные

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

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

Дополнительные справочники

Для нормального функционирования любой виртуальной звезды в базе данных должна в явном виде существовать таблица для каждого уровня обобщения каждого атрибута, предназначенного для классификации показателей. Будем называть такие таблицы справочниками измерений. Проблема состоит в том, что в ряде случаев классификационные признаки в реляционных базах данных не вынесены в отдельные таблицы, а выведены скалярно - в полной форме (в отличие от ссылки на запись в справочнике). В демонстрационном примере таким атрибутом является время, поэтому полная запись даты в полях sved_arc.sved_ins и sved_arc.sved_del должна быть продублирована явными справочниками временных точек (или интервалов). В простом случае в рассматриваемых информационных моделях базы IVREESTR подразумевается, что все показатели имеют признак периодичности "год", поэтому можно обойтись одним уровнем обобщения этого атрибута - годовым. Однако, для извлечения из базы информации с другой пришлось бы вводить несколько уровней обобщения, и, соответственно, несколько новых таблиц - для кварталов, месяцев и так далее.

Таблица years в базе данных IVREESTR является именно такой дополнительной таблицей-справочником, введенным в базу данных при создании аналитических метаданных (информационной модели).

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

• districts - таблица районов и городов, по маске ссылается на поле soato_code таблицы soato;
• branches - таблица названий рубрик таблицы okonh ;
• kfsuse - таблица для извлечения суммарных значений показателей для обобщающих записей иерархической таблицы kfs_olap ;
• kopfuse - таблица для извлечения суммарных значений показателей для обобщающих записей иерархической таблицы kopf_olap

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

years. Таблица годов.

Имя поля Тип поля Ссылка Допустимость NULL Примечание year_id integer нет Уникальный идентификатор (номер года) name char(4) да Имя года

districts. Таблица районов и городов.

Имя поля Тип поля Ссылка Допустимость NULL Примечание code integer нет Уникальный идентификатор name char(30) нет Название района/города mask char(10) да Маска grnum integer да Поле группы sortnum integer да Поле сортировки

branches. Таблица названий рубрик таблицы okonh.

Имя поля Тип поля Ссылка Допустимость NULL Примечание code integer нет Уникальный идентификатор name char(100) нет Название рубрики mask char(5) да Маска grnum integer да Поле группы sortnum integer да Поле сортировки

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

Имя поля Тип поля Ссылка Допустимость NULL Примечание kfs_id1 char(2) kfs.code нет Код родительской записи в таблице kfs_olap kfs_id2 char(2) kfs.code нет Код подчиненной записи в таблице kfs_olap

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

Имя поля Тип поля Ссылка Допустимость NULL Примечание kopf _id1 char(2) kopf.code нет Код родительской записи в таблице kopf _olap kopf _id2 char(2) kopf.code нет Код подчиненной записи в таблице kopf _olap

Специальные таблицы

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

Для каждой виртуальной звезды в базе данных имеется 6 системных таблиц: ivattrs<n>, ivlevels<n>, ivlocs<n>, ivareas<n>, ivcorrs<n>, ivlegals<n>, где <n> - номер виртуальной звезды в таблице ivstars.

Вверх