Принцип единства информационного пространства

Следующей особенностью ИБС является единая информаци­онная база. В современных условиях для ведения единой инфор­мационной базы используются различного рода системы управле­ния базами данных (СУБД).

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

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

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

Отличительной особенностью баз данных ИБТ является сов­местное хранение данных с их описаниями. Эти описания называ­ются метаданными (данные о данных). Они необходимы для кон­троля и управления данными как ресурсом.

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

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

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

мационного пространства, но позволяет его реализовать и исполь­зовать с максимально возможной эффективностью.

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

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

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

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

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

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

Особенностью информационной системы банка является необходимость обработки двух типов данных, а именно оператив­ных и аналитических. Поэтому в процессе функционирования ИБС приходится решать два класса задач: обеспечение повседневной работы банка по вводу и обработке информации и организация информационного хранилища в целях анализа данных для выявле­ния тенденций развития, прогнозирования состояний, оценки и управления рисками и т. д. Задачи первого класса полностью ре­шаются OLTP-системами (OnLine Transactional Processing - опера­тивная обработка транзакции). Для работы с аналитическими дан­ными предназначены OLAP-системы (OnLine Analytical Processing - оперативная аналитическая обработка), которые построены по технологии хранилища данных и служат для агрегированного ана­лиза больших объемов данных. Эти системы являются составной частью систем принятия решений или управленческих систем класса middle и top management, т. е. систем, предназначенных для пользователей среднего и высшего уровня управления банка.

Таким образом, возможности ИБС могут быть расширены пу­тем совместного использования транзакционных OLTP-систем и хранилищ данных (Data Warehouse).

Отличительными чертами хранилища данных являются:

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

• защищенность - в хранилище можно добавлять информа­цию, но ее нельзя изменять, модифицировать и корректировать;

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

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

• агрегация - одновременное хранение в базе агрегирован­ных и первичных данных, чтобы запросы на определение суммар­ных величин выполнялись достаточно быстро.

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

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

Хранилища данных принято изображать в виде многомерного куба. Величины, хранящиеся в ячейках этого куба и называемые фактами, являются количественными показателями, характеризу­ющими деятельность кредитного учреждения. Это могут быть данные об оборотах и остатках по счетам, структуре расходов и доходов, состоянии и движении денежных средств и т. д. Измере­ния куба, образующие одну из его граней, - это множество одно­типных данных, предназначенных для описания фактов (напри­мер, филиалы банка, операционные дни, клиенты и валюты). Аг­регация данных выполняется по измерениям куба, поэтому эле­менты измерений принято объединять в иерархические структуры. Так, филиалы часто группируются по территориальному признаку, клиенты - по отраслевому признаку, даты группируются в недели, месяцы, кварталы и годы. Каждая ячейка данного куба «отвечает» за конкретный набор значений по его отдельным измерениям, например, оборотов балансовых счетов за день, квартал, год в раз­резе филиалов.

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

Хранилище данных ориентировано на высшее и среднее ру­ководство банка, ответственное за принятие решений и развитие бизнеса. Это руководители структурных, финансовых и клиент­ских подразделений, а также подразделений маркетинга, управле­ния анализа и планирования.

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

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

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

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

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

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

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

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

Рис. 5.2. Схема взаимосвязи витрин данных и хранилища данных

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

тимальна для больших объемов данных. Данные в такой витрине снабжены большим количеством индексов.

Структура витрин данных также ориентирована на многомер­ную организацию данных в виде куба. Однако их построение в силу ограниченности информационного диапазона, обеспечиваю­щего потребности одной функциональной области, значительно проще и выгоднее, чем создание хранилища данных. Физическая структура базы данных в витрине данных создается по модели «звез­да» (star schema), являющейся оптимальной при решении группы за­дач, для которой построена витрина, поскольку обеспечивает высо­кую скорость выполнения запросов посредством разделения данных. Звездообразная схема предполагает наличие одной центральной таб­лицы фактов (fact table), в которой содержатся суммирующие или фактические данные, и окружающих ее таблиц измерений (dimensional table), отражающих описательную информацию. Табли­ца фактов и таблицы измерений связаны между собой идентифици­рующими связями, при этом ключевое поле таблицы фактов целиком состоит из всех первичных ключей таблиц измерений.

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

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

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

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

5.3.