|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Современные подходы и методы построения аналитических информационных системАвтор: Ольга ЗаратуйченкоИздание: Семинар НТЦ АРБ
Тезисы выступления на семинаре НТЦ АРБ Современные подходы
к построению информационных систем; Транзакционные и Аналитические системыПри обработке финансовой информации традиционным является разделение существующих задач на два широких класса:
Они принципиально различны, требуют разных подходов к своему решению, но при этом взаимно дополняют друг друга. Решения этих задач могут быть осуществлены как в рамках единой Информационной системы, так и в нескольких относительно автономных системах, в зависимости от целей и требований, которые предъявляются к ним. Будем называть
Опишем основные
функции и особенности
Заметим, что с точки зрения информационных процессов, Транзакционная Система первична по отношению к Аналитической Системе, так как все данные, используемые для анализа, необходимо сначала накопить и, по возможности, частично обработать, чем и занимаются различные Транзакционные Системы. Хранилища данныхЭффективность работы предприятия и сложность анализа его деятельности напрямую зависит от того, как организована обработка информации и поддержка информационных процессов. В банке может функционировать несколько информационных систем, которые выполняют различные задачи (например, одна для кредитов, другая для ценных бумаг и т.д.). В процессе эксплуатации эти системы накапливают большое количество информации, использовать которую для анализа достаточно сложно, так как необходимые данные могут находиться в разных источниках. Работающие информационные системы также могут порождать множество электронных архивов, содержащих устаревшие данные, которые не влияют на текущее состояние, но могут помочь выявить долговременные закономерности и тенденции в работе банка. Как правило, эти архивы имеют различные источники и структуру, содержат различные по содержанию и формату данные. Поэтому поиск в них зачастую жизненно важной для организации информации превращается в трудновыполнимую задачу, которая требует большого количества времени. К тому же вся найденная (и очень подробная) информация не может быть непосредственно использована для анализа без предварительной обработки и согласования с данными более поздних временных периодов. Для разрешения проблемы хранения разнородных данных за большие периоды времени из различных источников, а также быстрого доступа и поиска релевантной запросу информации и была придумана концепция Хранилищ данных (Data Warehouse). Хранилище Данных (Data Warehouse) - это специальная база данных организации, содержащая предметно-ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, назначение которых - служить основой для получения справочной, аналитической и обобщающей информации (в отличие от транзакционной базы с данными для текущей оперативной работы). В основе понятия Хранилищ Данных лежат две основополагающие идеи:
Основные требования к данным, находящимся в Хранилище Данных:
Предметом концепции Хранилища служат сами данные. Целью являются не способы описания и отображения объектов предметной области, а собственно данные как самостоятельный продукт, получаемый в процессе функционирования различных информационных систем. С этой точки зрения Хранилище данных оправдывает свое название, так как является всего лишь складом разнообразной и разнородной информации. Теперь легко определить основные операции, которые необходимо проводить для поддержания эффективности объекта подобного рода:
Сбор данных Пополнение Хранилища Данных - очень важная и не очень простая операция, так как данные в базу должны поступать в требуемом виде, а также с определенной регулярностью. Источники данных могут быть весьма разнообразными, от Транзакционных Систем, до материалов прессы. Информация от них может поступать в различных форматах, с разными условными обозначениями и наименованиями для одних и тех же понятий, к тому же она может дублироваться в различных источниках. Поэтому на этапе помещения данных в Хранилище должна проводиться первичная переработка данных, имеющая целью привести поступающую разнородную информацию к определенному ее характером виду, а также устранить возможные ошибочные и избыточные значения. Из-за постоянно меняющихся источников и типов поступающей информации процесс закачки данных в Хранилище нельзя сделать полностью автоматическим, но для ряда информационных систем, таких как уже рассматриваемые Транзакционные Системы, которые являются основными источниками поступающих данных, необходимо использовать специально разработанные программные интерфейсы передачи данных. То есть должны существовать программы, выполняющие процедуры передачи данных на склад и их первичной обработки по задаваемому графику или в связи с возникающими событиями. Поддержка логической целостности данных Для того, чтобы обеспечить согласованность работы с различными источниками и получателями данных, необходимо иметь описание структуры хранимых данных. Обычно такое описание содержится в словаре-справочнике, который часто называют репозитарием. В нем собираются сведения о форматах, структурах, каналах и источниках поступления данных и другая необходимая информация. Всякая операция с хранимыми данными не должна приводить к появлению записей, не удовлетворяющих их описанию. Помимо проверки данных на соответствие их структуре и назначению, желательна проверка на непротиворечивость различных, но каким-либо образом связанных между собой данных. Доступ к данным Чаще всего доступ к данным определяется возможностями Аналитической Системы, которая базируется на Хранилище данных (или имеет возможность обращаться к нему) и предоставляет пользователю инструментальные средства для извлечения и обработки данных, а также для проведения различных форм анализа. Чаще всего именно Аналитическая Система осуществляет исследование данных (Data Mining), то есть поиск необходимой информации в море хранящихся фактов, а также выявление взаимозависимостей между данными . Поскольку основным назначением Хранилищ Данных является хранение больших объемов информации по многим направлениям деятельности организации и предоставление быстрого доступа к необходимым данным, то Хранилище Данных может быть как составляющей (и основополагающей) частью Аналитической Системы, так и независимой базой данных, к которой Аналитическая Система может время от времени обращаться и извлекать из нее исходные данные для анализа. В последнем варианте полученные в процессе анализа агрегированные показатели, характеристики и заключения могут помещаться в единый склад данных, наравне со всеми другими данными. Взаимное сочетание Транзакционной Системы, Аналитической Системы и Хранилища Данных зависит от специфики деятельности организации, количества и характера хранимой информации, источников ее поступления и характеристик всех используемых информационных систем. Если для работы используется несколько абсолютно независимых Транзакционных систем, каждая из которых выполняет отдельную задачу, то в этой ситуации Хранилище Данных примет свой классический вид большой Базы Данных, которая хранит всю информацию по всем объектам организации и на которой базируется Аналитическая Система. В противоположной ситуации, когда организация пусть даже имеет различные направления в своей работе, но имеет один источник данных, Хранилище Данных может быть интегрировано в саму Транзакционную Систему, либо принимать форму набора архивных баз, к которым организован прямой доступ со стороны Аналитической Системы. Сама Аналитическая система в этом случае может быть как отдельным программным продуктом, так и одним из модулей работающей Транзакционной Системы. Витрины (киоски) данныхНекоторым сужением понятия Хранилищ Данных является понятие Витрин данных. (Возможно использование названий Секций или Киосков данных). Витрина данных (Data Mart) - это тематическая База Данных, содержащая информацию, относящуюся к отдельным аспектам деятельности организации. По сути, Витрина данных - это небольшой склад данных, в котором находится информация по одному какому-либо предмету, или же часть более общего склада данных, специфицированная для использования конкретным подразделением или определенной группой пользователей. Аргументы "За" и
"Против" использования Витрин Данных,
Основные принципы многомерной организации данныхРеляционный подход к проектированию баз данных не очень удобен для использования в задачах, требующих синтеза, анализа и консолидации данных. Для решения этих проблем больше подходит многомерный способ представления данных. Область, где он наиболее эффективен - это хранение и обработка высоко агрегированной и стабильной во времени информации. Работа с многомерными структурами данных получила название OLAP (on-line analytical processing). Определением этого понятия служат 12 основных требований к средствам реализации OLAP, которые были сформулированы Э.Коддом:
Эти требования служат основой для определения OLAP-систем, но некоторые из них могут быть сознательно нарушены, для лучшего соответствия аналитических приложений предметной области и конкретным задачам. Определим основные понятия многомерного представления данных. На логическом уровне структура данных представляют собой сложный гиперкуб, который характеризуется следующими элементами:
Существует два варианта организации данных: Поликубическая модель и Гиперкубическая модель. Поликубическая модель предполагает, что в многомерной структуре данных может быть определено несколько гиперкубов с различной размерностью и различными измерениями в качестве их граней. В случае Гиперкубической модели предполагается, что все показатели должны определяться одним и тем же набором измерений. При конструировании и разработке аналитического модуля в составе банковской системы БИСКВИТ, был использован оригинальный подход, который базируется на вышеизложенных теоретических положениях. Наша модель объединяет лучшие черты Поликубического и Гиперкубического подхода. Ее можно назвать моделью Вложенных Гиперкубов: жестко определен один внешний гиперкуб с иерархическими измерениями "Подразделение" и "Время" (фиксированными в силу предметной области), в каждой же его ячейке может существовать неограниченное количество гиперкубов с любыми иными измерениями, самостоятельно определяющимися пользователем в словаре данных (репозитарии). Так как поступающая на анализ информация имеет не только разную форму, но и различный экономический смысл, каждый внутренний гиперкуб характеризуется своими собственными измерениями, определяющими структуру хранимых данных, а также имеет собственный набор показателей. Совокупность конкретных значений всех измерений однозначно определяет значения показателей данного гиперкуба. Данный подход выводит нас за рамки классического определения OLAP – систем. В классической модели из-за равноправия абсолютно всех измерений и показателей возникает проблема большого количества неопределенных значений. Нарушение этого условия дает нам значительные преимущества при хранении данных. В нашей логической схеме мы не стали настаивать на равноправии измерений и показателей и, как следствие, избавились от пустых элементов, однозначно привязав какое-либо количество показателей к каждому внутреннему гиперкубу. Данная схема является лишь частным случаем многомерной организации структуры данных, и ни коим образом не противоречит самому подходу к многомерным способам представления информации. В настоящее время существует два способа реализации сложной логической структуры гиперкубов:
В Многомерных Базах данные хранятся в упорядоченных Многомерных массивах. Системы управления такими базами позволяют быстро производить поиск и выборку данных из моря информации, содержащегося в базе. Но такое решение требует большей суммарной памяти для хранения данных, больших затрат времени при их загрузке и является недостаточно гибким при необходимости модификации структур данных. Весьма существенный недостаток многомерной организации данных, заложен в самой концепции многомерности. Предполагается, что внутри гиперкуба нет пустот, что все ячейки куба заполнены. Но большое количество элементов просто не может соответствовать этим значениям внутри гиперкуба по своим экономическим или физическим характеристикам. И на практике сложно добиться того, чтобы многомерные массивы не содержали бы пустых значений, которые затрудняют эффективную работу с используемыми в запросе данными. При создании OLAP-приложения на основе Реляционной Базы данных, информация хранится в обычных Реляционных таблицах, которые должны быть специфическим образом организованы. В простейшем случае, это так называемая "радиальная" схема, или схема типа "звезда" (star schema), где имеется одна большая главная таблица и много частных, связанных с ней. Главная аккумулирует данные о наиболее часто запрашиваемом объекте, и/или служит отправной точкой для запросов к таблицам со специальной частной информацией (справочным или содержательным). Радиальная схема оптимизирована под наиболее часто встречающиеся запросы и обычно оказывается реляционно ненормализованной . Усложнением этой схемы можно считать структуру типа "снежных хлопьев" (snowflake) с несколькими основными таблицами. Совокупность всех
средств и методов для организации аналитической
работы с данными, хранящимися в такой структуре,
часто определяется термином Общий вывод, которой можно сделать, рассматривая многомерный и реляционный способы организации хранения данных следующий: Производительность хорошо настроенных реляционных систем анализа вполне сравнима с производительностью систем, реализованных на основе многомерных баз данных. Особенности логической
организации ROLAP-систем, Логическая организация системы, предназначенной для анализа разнородной информации и основанная на реляционной схеме, базируется на трех типах иерархических объектов :
Основные операции манипулирования данными Рассмотрим основные операции манипулирования данными, доступные Аналитической Банковской Системе:
Совокупность вышеописанных свойств Системы Анализа делает ее гибким и мощным инструментом, позволяющим решать широкий круг сложных информационно-аналитических задач банка. В заключение хотелось бы сформулировать основные результаты, полученные в работе:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
© 2009-2024 Акционерное общество
“Банковские Информационные Системы” |
115114, Москва, Шлюзовая набережная 6 стр 4, т.: +7(495) 780 3773, факс: (495) 780 3771, www.bis.ru, info@bis.ru.
191119, Санкт-Петербург, ул. Звенигородская, 22, литера А, т./ф: (812) 448 1879, info@spb.bis.ru. 440052, Пенза, ул. Бурмистрова 6а, офис 2. т.: (927) 365 3123, info@bis.ru. |