Формализация многомерного представления данных

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

Определим пространство, которое содержит характеристики объектов или бизнес-понятия. Оно состоит из объектов вида «понятие»(характеристика), которое определяется своими атрибутами.

Rep = {mes{attr}}.

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

Технические: тип данных, формат вывода, область значений (список), источник данных, объект в базе, алгоритм вычисления, иерархия, ограничения (min и max значения), права пользователя на просмотр или редактирование.

Концептуальные: правила представления, смысл, заложенный в это понятие, правила использования, зависимые понятия,.объекты, к которым применимы эти понятия.

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

Elem = elem{dim}. То есть динамическое понятие есть функция от множества статических.

Поэтому разделим все множество (пространство) понятий на множество статических, которые мы будем называть Измерениями (DIM), и сножество динамических, называемых Показателями (ELEM).

Далее. Любое понятие может принимать определенные значения, то есть определено на какой-то области значений, которая может задаваться различным образом (списком, типом и min – max значением или правилом). При создании аналитической системы мы используем все понятия и придаем им определенные значения. Назовом Выборкой – совокупность значений понятий из области допустимых значений (это множество, вектор). Выборка – это результат операции select над множеством значений понятия, определяемой каким-либо критерием. (select (mes,criteria))

Назовем Мощностью выборки количество полученных значений.

Пример: Понятие = номер балансового счета, област доп. Значений – план счетов (список), bal-acct = {10204,20202} – выборка, p(bal-acct) = 2.

Далее определяем пространство Гиперкубов как пространство объектов, определенных на множествах измерений и показателей: GIP = {Gip(DIM,ELEM)}.

То есть конкретный гиперкуб определен на конкретных измерениях и показателях: Gip = Gip(dim,elem}.

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

Размерность гиперкуба – произведение мощностей его измерений. P(Gip) = p(dim1)* p(dim2)..

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

Вес гиперкуба – произведение его размерности на количество показателей (кол-во значений в гиперкубе)

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

//Пользовательское представление – это толкование значений, содержащихся в гиперкубе исходя из их бизнес-содержания.

Операции над гиперкубом:

1) Выборка по измерению – изменение списка значений какого-либо измерения. (Например, балансовые счета. Мы можем выбрать все счета, прописанные в плане счетов, можем выбрать только действующие в данной кредитной организации, а можем просто указать список счетов.). Она изменяет размерность гиперкуба.

2) Поворот – изменение порядка представления измерений, то есть turn(Gip(dim1,dim2, elem) = Gip’(dim2,dim1,elem). То есть Поворот не изменяет размерности гиперкуба, не меняет его структуры и значений, а изменяет его пользовательское представление.

3) Срез – это комбинация операций поворота и выборки. Slice&dice = turn * select. Получаемый в результате этой операции срез данных представляет собой подмножество гиперкуба Gip’ C Gip. Но чаще срезом называют гиперкуб, у которого ряд измерений имеет размерность = 1 (То есть фиксированы). Количество возможных срезов определяется формулой размещений: K = Ank = n!/(n-k)!, где n – количество измерений, k – мерность среза.

4) Детализация и свертка. Эти операции можно производить над гиперкубом, который определен на иерархическом измерении. То есть для значений измерения определены соотношения вложенности: dim1,dim2 C dim0. Тогда над показателями, определенными на этих измерениях, могут производить операции агрегирования (и обратная ей - детализации).

Т.е. elem(dim0) = Agrr(elem1(dim1),elem2(dim2)).

Оператор агрегирования в общем случае представляет собой метрику оценки значений и может быть 1) естественным: Min,Max,Sum,Count,Avrg,Div…и выражаться математической фрпмулой, или 2) аналитическим: определяться сложным образом и представлять собой пользовательскую оценку (пропорции, градация по определяемым пользователям критериям).

Причем, Метрика задается обязательно на пару измерение-показатель Aggr(dim,elem) и говорит, кокую операцию совершать с данным показателем при всертке по данному измерению. Вырожденным случаем является подсчет итогов и подитогов (уровень иерархии = 0). Для примера с балансом в разрезе валют, мы можем просуммировать остатки по счетам в одной валюте, но не можем это сделать для значений в разных валютах, то есть Aggr(bal-acct, balance) = Sum, а Aggr(currency, balance) = “”. Для показателя дата последнего движения оператор агрегирования не зависит от измерения и его модно установить как Max.

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

На пространстве гиперкубов мы можем задать

1) 1 гиперкуб, определенный на всех измерениях и показателях Gip = Gip(DIM,ELEM)– поликубическая модель

2) множество гиперкубов {Gip} = {Gip({dim},{elem})}, причем каждый показатель гиперкуба должен зависеть ото всех его измерений: elem = elem({dim}) – гиперкубическая модель.

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

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

Выход – в модели вложенных гиперкубов. Попробуем ее определить.

Определим операцию разбиения (деления) гиперкуба как представление его в виде совокупности нескольких гиперкубов меньшего веса. То есть мы не меняем их размерности, а уменьшаем вес за счет разнесения показателей по разным гиперкубам. Этот механизм применяется, когда технические возможности не позволяют строить гиперкуб с большим числом измерений. При этом не происходит потери значений (Сумма весов новых гиперкубов = весу старого), возникает лишь некоторая избыточность. Gip = Gip1 + Gip2,где dim = dim1 = dim2, а elem = {elem1, elem2}.

И вторая операция – разложение гиперкуба – представление его в виде комбинации (произведения) нескльких гиперкубов меньших размерностей. То есть Gip({dim1,dim2},elem) = Gip1(dim1,elem)*Gip2(dim2,elem).

???(Размерность старого = произведению размерностей новых).

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

Утверждение 2: Вложенные гиперкубы переставимы. Критерий – полнота.

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

Утверждение 4: Количество вложенностей и вес гиперкубов часто определяется технич. характеристиками системы. Нужно сравнить избыточность данных и % пустых значений для идеального разложения гиперкуба и гиперкуба, с определенным уровнем вложенности. Должна получиться формула.

MOLAP & ROLAP

В зависимости от ответа на вопрос, существует ли гиперкуб как отдельная физическая структура или лишь как виртуальная модель данных, различают две архитектуры: MOLAP (Multidimensional OLAP) и ROLAP (Relational OLAP).

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

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

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

MOLAP это 2-звенная клиент-серверная архитектура. В ней многомерная база данных служит одновременно как базой данных, так и приложением логического представления данных. Как база данных, MDDB ответственна за хранение всех данных, процессы доступа, загрузки и восстановительные процессы. На уровне приложений логического представления данных, MDDB отвечает за выполнение всех OLAP запросов. Сервис презентаций объединяется с логическим и обеспечивает интерфейс, через который конечный пользователь просматривает и запрашивает данные, осуществляя их анализ. Клиент-серверная архитектура позволяет множеству пользователям иметь доступ к одной и той же многомерной базе данных.

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

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

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

ROLAP - 3-звенная клиент-серверная архитектура. Уровень Базы данных использует реляционную базу данных для хранения данных, для процессов доступа и восстановления. Уровень Логического приложнения представляет собой ROLAP-анализатор который выполняет многомерные запросы, требуемые пользователям. Этот механизм интегрирован со многими средствами презентаций, через которые пользрователь получает результат анализа.

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

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

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

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

1. Специализированные Аналитические системы. Имея в основе системы Многомерную базу данных и набор инструментальных средств для работы с ней, разрабатываются модели предметной области, методики анализа и программные средства для пополнения базы данных. Эти системы используют встроенные средства для OLAP. (Системы на основе Реляционных Баз Данных (ROLAP-системы), занимающиеся только Аналитическими задачами, тоже можно отнести к типу Специализированных Аналитических систем).

2. Интегрированные Аналитические системы. Такие системы возникли на основе одного из модулей какой-либо Автоматизированной Банковской Системы (часто это Модуль Получения Финансовой Отчетности) путем добавления к нему новых возможностей и функций. В них осуществлено конструирование ROLAP-технологии, так как основой для системы анализа послужила реляционная структура базы данных родительской Транзакционной Системы. Одним из достоинств Аналитической Системы этого типа является встроенный интерфейс общения с породившей ее Банковской Системой. Она может являться частью АБС, работая вместе с ней (и вместе образуя классический склад данных, если Банковская Система достаточно функционально наполнена), либо функционировать независимо, но легко извлекать из нее необходимую для анализа информацию.

Разные пути создания определили и особенности каждого типа систем:

	Специализированные АС	Интегрированные АС
Способ представления данных	Многомерный (или Реляционный)	Реляционный
Методы доступа к данным	OLAP (ROLAP)	ROLAP
Связи	Отдельный и независимый продукт	Может быть как отдельным программным продуктом, так и функционировать совместно с родительской Транзакционной Системой (в составе АБС)
Основные источники данных	Чаще несколько различных	Основной источник - сама Транзакционная Система, но могут быть и дополнительные
Способ загрузки данных	Импорт из файлов различного формата и электронных таблиц, подсоединение к некоторым РСУБД через ODBC-драйвера, доступ к данным АБС через специально написанные пользовательские приложения	То же, что и для Специализированных АС, но, что самое главное, полная совместимость с родительской Транзакционной Системой (и ее архивами) не только на уровне Базы Данных, но и на уровне объектов системы: операций, документов и частично агрегированных и обработанных показателей

Литература:

1. «Банковское дело» под ред. Ю.А.Бабичевой.

2. К. Садвакасов "Коммерческие банки. Управленческий анализ деятельности. Анализ и контроль"

3. А.Е. Екушов "Модели учета и анализа в коммерческом банке"

4. А.А. Солянкин "Компьютеризация финансового анализа и прогнозирования в банке"

5. Журнал «Банковские технологии»

6. Н.Е.Ефимов, Э.Р.Розендорн, «Линейная алгебра и многомерная геометрия».

6. В. Львов "Создание систем поддержки принятия решений на основе хранилищ данных" журнал "Системы Управления Базами Данных " # 3/97

7. М. Шапот, В. Рощупкина - Интеллектуальный анализ данных и управление процессами журнал "Открытые системы" #04/98

8. В. Пржиялковский "Сложный анализ данных большого объема " журнал "Системы Управления Базами Данных " # 4/96

9. Н.Соколов "Хранилища, которые мы выбираем" Компьютеруик-Москва № 6 1997 год.

10. К.Буров "Обнаружение знаний в хранилищах данных" - Открытые системы №4 1999 год

11. Центральный Банк Российской Федерации "Правила ведения бухгалтерского учета в кредитных организациях, расположенных на территории Российской Федерации."

12. А.А.Сахаров - Концепции построения и реализации информационных систем, ориентированных на анализ данных, «СУБД»-4/96;

1) А.А.Сахаров - Принципы проектирования и использования многомерных баз данных
(на примере Oracle Express Server), «СУБД»-3/96;

4) О.В.Заратуйченко - Филиалы, данные, анализ; "Банковские технологии"-1/98;

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

[2]E.F.Codd, S.B.Codd, C.T.Salley. «Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate». - E.F.Codd & Associates,1993.