Информационные технологии получения отчетности
Прежде всего, отчет – это выборка ограниченного набора данных из базы данных системы автоматизации банковской деятельности. Причем сама выборка первичных данных в процессе формирования отчета зачастую подвергается дополнительной обработке. Необходимость дополнительной обработки объясняется тем, что модель данных большинства современных банковских систем в большей степени ориентирована на оперативный ввод и обработку, нежели чем на эффективную выборку с целью получения отчетов.
Эффективность выборок данных из любой БД в немалой степени зависит от способа организации данных. Конечно, эффективность простой выборки всех строк одной из таблиц сервера БД полностью определяется производительностью системы управления базами данных (СУБД), мощностью сервера БД и пропускной способностью вычислительной сети банка.
Рассмотрим один из простейших примеров банковской отчетности, с которым приходится ежедневно сталкиваться любому из банков - выборку оборотно-сальдовой информации по синтетическим счетам банка. Для простоты – без округлений и консолидации по валютам.
Для того, чтобы выборка оборотно-сальдовой информации по синтетическим счетам осуществлялась быстро и эффективно – желательно, одним запросом – необходимо иметь максимально простую схему организации данных. В идеале, остатки и обороты должны храниться в БД непосредственно на том уровне синтетических счетов, по которому производится построение требуемого отчета. Причем хранить остатки необходимо за каждый день работы банка – вне зависимости от того, были или нет в этом дне обороты по данному синтетическому счету. В этом случае, требуемый отчет будет представлять из себя обычное форматирование результата SQL-запроса по одной таблице БД, содержащей и атрибуты синтетического счета, и оборотно-сальдовую информацию по нему. Такого рода кажущаяся "простота" обладает очевидными последствиями, например:
· При переходе к хранению остатков на синтетических счетах произойдет неизбежное и весьма существенное снижение эффективности проведения учетных операций по изменению оборотно-сальдовой информации на аналитических (лицевых) счетах
Связано это с тем, что в момент проведения операции по аналитическому счету, кроме изменения его собственного остатка, возникнет необходимость изменения остатков и по тем синтетическим счетам, в состав которых входит данный аналитический счет, а это:
▪ Дополнительные затраты на модификацию данных. Даже если иерархия синтетических счетов банка состоит всего из одного уровня или только для одного уровня синтетики требуется явное хранение остатков (например, для синтетических счетов второго порядка), это все равно одна "лишняя" операция на каждое изменение остатка по каждому аналитическому счету.
▪ Дополнительные запросы на поиск информации. Алгоритмы поиска данных по произвольным иерархическим структурам "вверх" (в нашем примере, от счета аналитического учета, как нижнего уровня иерархии плана счетов, к счетам синтетического учета) часто вынуждены носить рекурсивный характер. Это приводит к тому, что поиск счетов синтетического учета от счетов аналитического учета не может быть выполнен за один запрос.
▪ Дополнительная конкуренция за ресурсы сервера БД. Большинство клиентских счетов и счетов банка открываются на ограниченном наборе счетов синтетического учета плана счетов банка, что неизбежно приведет к высокой конкуренции на модификацию одних и тех же данных (строк таблиц сервера БД) в условиях многопользовательской работы в банке.
· Возрастет объем хранимой и обрабатываемой информации в БД
Совершенно очевидно, что хранимая в БД оборотно-сальдовая информация по счетам синтетического учета – это избыточная информация, являющаяся производной (агрегатом) от оборотно-сальдовой информации по счетам аналитического учета. Как и любой другой пример "денормализации" структуры данных, такой подход приведет к росту объемов данных.
Поэтому технология редко использует такого рода организацию данных. Чаще используется в рамках одной модели данных найти "разумный" компромисс между OLTP-характером технологии и потребностью в последующих эффективных выборках данных. Один из типовых примеров организации данных синтетического и аналитического учета на счетах плана счетов банка приведен на Рис. 3.152.
Рис. 3.152. Примерная схема данных синтетического и аналитического учета в банковской информационной системе
Представленная выше схема предполагает, что оборотно-сальдовая информация ведется в БД только на уровне счетов аналитического учета. На уровнях счетов синтетического учета, которых может быть произвольное число в каждой из областей учета каждого из планов счетов банка, оборотно-сальдовая информация может быть получена как агрегат от оборотно-сальдовой информации по счетам аналитического учета. Но и в этом примере степень оптимизации сущности "Оборотно-сальдовая информация" может быть различной в различных банковских системах, например:
· Остатки и обороты по счету могут храниться только в тех днях, в которых по нему были операции.
Такого рода схема применяется, обычно, в банковских системах реального времени, в которых оборотно-сальдовая информация по счетам аналитического учета и позициям банка изменяется непосредственно в момент выполнения финансовых операций, а не откладывается до процедуры "завершения операционного дня". Результат очевиден: остаток по счету всегда актуален – вне зависимости от того, "открыт" или "закрыт" операционный день, но с другой стороны, его нельзя получить простым запросом, потому что в дне, за который требуется остаток, могло и не быть финансовых операций и, следовательно, не будет соответствующей строки в таблице БД – необходимо строить достаточно сложный запрос.
· Остатки по счетам аналитического учета могут не храниться в БД. Хранению при этом подлежат только суммарные обороты по счету за операционный день или другой интервал времени, с точностью до которого банковская система позволяет запрашивать оборотно-сальдовую информацию. Остатки же вычисляются как агрегат от оборотов по счету от даты его открытия до даты запроса остатка по счету непосредственно в момент запроса остатка.
Данный подход призван минимизировать объем модифицируемой оборотно-сальдовой информации в момент проведения операции по счету. В случае проведения операции по счету "задним числом", когда в последующих днях уже накоплена история движения средств по данному счету, предыдущий подход приводит к необходимости пересчета остатков и изменения оборотно-сальдововой информации во всех днях вперед, в которых уже были совершены операции по счету. Текущий подход не требует изменения оборотно-сальдововой информации в последующих днях, потому что достаточно просто изменить оборот в том дне, где проводится операция по счету и проверить, не изменяя, остатки по счету в последующих днях – например, с целью контроля их бухгалтерской корректности. Но с другой стороны, сложность последующих запросов об остатке на счете возрастет еще больше.
· Ни остатки, ни обороты по счетам аналитического учета могут не храниться в БД вообще. Оборотно-сальдовая информация определяется в момент запроса на основе анализа проведенных по счету аналитического учета бухгалтерских проводок.
Этот подход известен своей "крайностью". Предыдущий, с хранением суммарных оборотов, отличается от текущего подхода тем, что:
▪ Минимизирует объем агрегируемой информации - один суммарный оборот за день против произвольного числа формировавших его проводок
▪ Выборка с целью получения остатка не затрагивает таблицы проводок и документов, что очень важно для уменьшения конкуренции за ресурсы сервера БД при многопользовательской работе.
Как видно из приведенных рассуждений, разработчики банковских OLTP-систем в большинстве случаев готовы идти на снижение эффективности выборок данных при условии роста производительности ON-LINE операций модификации этих данных. На каком бы варианте организации схемы хранения оборотно-сальдовой информации в итоге не остановились бы разработчики, отчет по оборотно-сальдовой информации по счетам синтетического учета будет строиться на основе нескольких последовательных логических выборок данных:
· Первый шаг - построение списка аналитических счетов, открытых на каждом из счетов синтетического учета, вошедших в отчет
Большинство современных банковских систем декларируют "поддержку учета по всем типам банковских операций в режиме единого информационного пространства". А значит, такие системы должны предоставлять технологу банка возможность настроить для каждой из областей учета плана счетов банка произвольную, необходимую банку длину иерархии синтетического учета. Как уже отмечалось выше, это делает невозможным простую выборку данных из разных уровней плана счетов за один запрос. Приходится выбирать: или гибко настраивать учет, или просто выбирать данные. Точнее, существуют известные реляционные алгоритмы, которые поддерживают обработку развитых иерархических структур – в частности, запросы типа "вернуть всех детей (в нашем примере, аналитические счета) для родителей такого-то уровня вложенности (синтетические счета заданного порядка)", - но они накладывают серьезные ограничения на модель данных системы и способы ее обработки, а потому практически не используются на практике в оперативных учетных системах.
· Второй шаг - запрос оборотно-сальдовой информации по аналитическим счетам из сформированного списка
Даже если остановиться на самом "простом" из приведенных выше, первом варианте схемы хранения остатков и оборотов, необходимо выполнить запрос вида: "Вернуть остаток и обороты по счету за дату, ближайшую меньшую или равную дате формирования отчета". Те, кто знаком с возможностями синтаксиса современных диалектов языка SQL и оптимизаторов запросов современных СУБД, надеемся, по достоинству оценят "простоту" такого рода запроса.
· Третий шаг - свертка результатов предыдущего запроса по счетам синтетического учета, вошедшим в отчет
Если же отчет по счетам синтетического учета необходимо построить "с округлением", что чаще всего и требуется, то вслед за этим шагом последуют еще несколько шагов – причем с возрастанием степени сложности.
Обработка отчетных данных
Данные для большинства банковских отчетов неэффективно, а иногда просто невозможно получить простой выборкой из БД банковской системы. Оперативные, первичные данные необходимо предварительно очистить, агрегировать, проверить на корректность и уже только затем подать финансисту или управленцу в виде отчета. У процесса такого рода есть несколько сторон:
· Любая статистическая обработка данных требует значительных вычислительных ресурсов от банковской системы
Это особенно заметно в банковских системах использующих "двухзвенную" "клиент/серверную" технологию, где большая часть бизнес-процедур сосредоточена на сервере БД. Технология работы большинства планировщиков запросов SQL-серверов устроена таким образом, что в случае нехватки вычислительных ресурсов сервера БД предпочтение отдается тем процессам на сервере БД, которые к этому моменту имеют более продолжительную и успешную "историю" работы. Таким образом, один единственный банковский отчет, осуществляющий значительную по объему или сложную по составу выборку данных из БД, в состоянии в многопользовательском режиме работы заблокировать работу большого числа пользователей системы – даже тех, кто по характеру своей работы напрямую с этим запросом не конфликтуют.
Один из наиболее очевидных путей выхода из такого рода ситуаций – это использование технологии разделения задач формирования банковской отчетности и оперативной обработки. Для решения задач формирования отчетности используется выделенный SQL-сервер. При этом на основном, оперативном сервере банковской системы, по-прежнему, выполняется ввод и обработка первичных продуктовых и учетных данных, а отчеты – и в первую очередь, статистические и аналитические – строятся на вспомогательном, аналитическом сервере банка. Чтобы не решать при этом на уровне банковской системы задачу синхронизации оперативных и отчетных данных между двумя серверами БД, компании-разработчики предлагают банку воспользоваться штатными средствами репликации данных от поставщиков SQL- Получается достаточно дорогостоящее, но в целом - эффективное решение. Его в состоянии самостоятельно построить любой банк, готовый приобрести соответствующую лицензию на использование средств репликации данных и выделить дополнительный сервер БД.
· Необходимо иметь возможность при повторном получении однотипных банковских отчетов использовать единожды обработанные, синтетические отчетные данные
Вынесение задач формирования отчетности на дополнительный сервер БД отчасти решает задачу снижения степени влияния сложности получаемых отчетных форм на производительность процессов оперативной обработки первичных данных. И это очень важно для средних и крупных банков, с информационными системами которых одновременно работает большое число пользователей. Но сама по себе эффективность выборок отчетных данных при этом не может существенно повыситься, потому что они осуществляются все по той же физической схеме данных банковской системы, изначально спроектированной для эффективного оперативного ввода и обработки данных, а не для формирования отчетов. Если эта схема данных не предусматривает возможности хранения промежуточных результатов обработки отчета с целью их повторного использования, то сложные статистические расчеты будут повторяться каждый раз, как только пользователь запросит формирование отчета. Хотя для целого ряда банковских отчетных форм синтетические данные, получаемые в процессе формирования отчета, могут быть с успехом использованы не только при повторном вызове на выполнение этого же отчета, но и в целом ряде других отчетных форм.
Отсюда возникает второе направление в работе со сложными банковскими отчетными формами: отдельные данные банковской отчетности представляются как значения соответствующих показателей во внутреннем "Хранилище данных" оперативной банковской системы. Причем иерархия этих показателей настраивается компанией-разработчиком или технологом банка таким образом, чтобы возможно большее число разнообразных отчетных форм в банке могло базироваться на различных уровнях одной и той же иерархии показателей - как подсказывает опыт, практически вся отчетность банка, связанная с обработкой данных по синтетическим счетам плана счетов банка (как точная, так и округленная, как по отдельным валютам и филиалам многофилиального банка, так и консолидированная) может быть получена на единой структуре показателей "Хранилища данных".
Для небольших и средних банков "Хранилище данных" физически может располагаться на том же сервере БД, где и оперативная часть банковской системы. Для средних и крупных банков может быть рекомендована схема, сочетающая в себе использование репликации первичных данных на выделенный сервер с последующей обработкой их на этом сервере во встроенном в систему "Хранилище данных".
· Многомерный анализ данных для принятия управленческих решений должен быть основан на соответствующих возможностях полноценной OLAP-системы
Рассмотрим в качестве примера проведение финансового анализа деятельности банка. Как известно, финансовый анализ является частью общего, полного анализа хозяйственной деятельности банка, который состоит из двух тесно взаимосвязанных разделов: собственно, финансового анализа и производственного управленческого анализа.
Анализ финансовой деятельности в современной банковской системе может производиться как во встроенном в банковскую систему "Хранилище данных", с использованием внешней OLAP-системы.
Цель финансового анализа - более подробная, всесторонняя оценка финансового состояния банка как за рассматриваемый период, так и на перспективу.
Современные банковские OLAP-пакеты обычно поддерживает следующие известные методики анализа:
▪ горизонтальный (временной) анализ - сравнение каждой позиции отчетности с предыдущим периодом
▪ вертикальный (структурный) анализ - определение структуры итоговых финансовых показателей с выявлением влияния каждой позиции отчетности на результат в целом
▪ трендовый анализ - сравнение каждой позиции отчетности с рядом предшествующих периодов и определение тренда, т.е. основной тенденции динамики показателя, очищенной от случайных влияний и индивидуальных особенностей отдельных периодов. С помощью тренда формируют возможные значения показателей в будущем, а следовательно, ведется перспективный, прогнозный анализ
▪ анализ относительных показателей (коэффициентов) - расчет отношений между отдельными позициями отчета или позициями разных форм отчетности, определение взаимосвязей показателей
▪ факторный анализ - анализ влияния отдельных факторов (причин) на результативный показатель с помощью детерминированных или стохастических приемов исследования. Причем факторный анализ может быть как прямым (собственно анализ), когда анализ дробят на составные части, так и обратным, когда составляют баланс отклонений и на стадии обобщения суммируют все выявленные отклонения, фактического показателя от базисного за счет отдельных факторов.
Очевидно, что такого рода методики неэффективно реализовывать на основе инструментальных средств, не поддерживающих аппарат многомерного анализа – например, при помощи обычной реляционной СУБД и ее языка SQL. Для этого созданы специализированные инструменты анализа. Поэтому говорить о качественном детализированном анализе следует только применительно к банковским OLAP-пакетам.
Тем не менее, достоверность результатов любого анализа определяется качеством и достоверностью исходных данных. OLAP-система не может решить задачу их подготовки вместо банковской оперативной системы. Качество интеграции оперативной банковской и хранилища, на котором базируется OLAP-система, приобретает важную роль. В том случае, если часть финансовой информации по той или иной причине на момент проведения анализа все же окажется недоступной для OLAP-системы, то она должна предложит возможности ее импорта или ручного ввода непосредственно в виде значений соответствующих показателей.
Отдельно необходимо затронуть проблему актуальности синтетических отчетных данных относительно соответствующих им первичных данных в случае использования решений типа "Хранилище данных" с использованием OLAP-системы. Как только отчеты начинают формироваться не на основе первичных данных, возникает потенциальная опасность того, что к моменту формирования отчета синтетические данные перестанут соответствовать актуальным оперативным данным. Соответственно, система управления отчетностью должна предусматривать несколько вариантов контроля актуальности данных при их использовании в отчетах или выгрузке в хранилище.
· Если при построении отчета не обнаружено требуемое синтетическое значение (показатель), то в большинстве случаев оно должно быть автоматически рассчитано и записано в хранилище. Исключение составляют случаи, когда расчет значений показателя является чрезвычайно трудоемким для системы и не может быть инициирован по несанкционированному запросу пользователей.
· В ряде случаев, необходимо иметь возможность принудительно перерассчитывать значения синтетических данных при каждом обращении к отчету, в котором они используются - вне зависимости от того, были они уже ранее рассчитаны с заданными пользователем параметрами или нет. Это самый простой, но и самый неэффективный способ обеспечения актуальности данных. Очевидно, что он может использоваться только в решениях типа встроенного "Хранилища данных", где возможен ON-LINE доступ к оперативной части базы данных банковской системы. Преимущества использования в отчетах такого рода "одноразовых" показателей по сравнению с непосредственной выборкой и последующей обработкой первичных данных состоят в следующем:
▪ Технолог банка в явном виде в "Хранилище данных" настраивает технологию расчета показателей, а следовательно может визуально ее контролировать
▪ Логика расчета показателей, входящих в отчет, отделена от самого образца отчета, а следовательно: во-первых, может быть видоизменена отдельно от образца отчета и, во-вторых, напрямую - без копирования и видоизменений – применена в других образцах отчетов
▪ Рассчитанные перед получением отчета значения показателей могут многократно использоваться при формировании данного отчета, если, например, они выводятся несколько раз в различных частях отчета или являются базой для расчета нескольких других показателей в отчете.
· Актуальность некоторых синтетических данных может отслеживаться с точностью до "операционного дня". Данный вариант контроля опирается на известное предположение о том, что в "закрытом дне все учетные данные актуальны". Поэтому, если значения этих показателей рассчитываются в "закрытом" операционном дне, то им автоматически присваивается признак "Актуальный в закрытом дне". Помимо этого, система должна фиксировать физические дату и время совершения операций "открытия/закрытия" каждого операционного дня и запоминать момент расчета значений такого рода показателей. Если при следующем обращении из отчета к значению показателя, имеющего признак "Актуальный в закрытом дне", выяснится, что с момента последнего расчета производились "открытия/закрытия" операционного дня, из которого берутся оперативные данные для расчета значения показателя, то система должна сбросить признак "актуальности" у значения такого показателя и перерассчитать его.
Актуальность еще одной группы показателей должна отслеживаться с точностью до "объекта банковской системы". Данный вариант является более общим случаем по сравнению с предыдущим вариантом – до "операционного дня". В этом случае, расчет и запись новых значений показателя производится не тогда, когда актуальность данных могла быть потенциально потеряна из-за возможных действий в системе в интервале времени между "откатом" и новым "закрытием" операционного дня, а только тогда, когда, например, действительно совершались реальные финансовые операции с участием объектов банковской системы, на которые опирается данный показатель. Это позволяет существенно выиграть в производительности получения целого ряда отчетов, потому что сложные арифметические расчеты в сочетании с операциями модификации данных в БД в сумме значительно более трудоемкие для любой банковской системы и сервера БД, чем операции простого чтения данных. Соответственно, система управления синтетическими данными должна получить время предыдущего расчета значения показателя и сравнить его со временем последней модификации объектов оперативной части банковской системы, которые используются при его расчете. Иногда такого рода сравнение выгоднее производить в момент формирования отчета или расчета значения показателя, иногда – в момент модификации первичных учетных данных.