Так, банковскими аналитиками используются СППР в областях стратегического планирования и формирования портфелей привлечения и размещения кредитно-инвестиционных ресурсов, в инвестиционном анализе и расчете лимитов и рисков кредитования. Неотъемлемым компонентом СППР этого уровня являются правила принятия решений, получаемые на основе применения специальных аналитических технологий и архитектур организации и хранения данных. Современные архитектуры средств хранения данных получили название хранилище данных (ХД) (DataWarehouse)
Хранилище данных (ХД)
Термин «создание Хранилищ Данных» (datawarehousing) описывает процесс сбора, очистки и просеивания данных из различных рабочих систем, а также предоставление широкой аудитории бизнес-пользователей непосредственного доступа к полученной информации.
Хранилище Данных (ХД) выполняет функции предварительной подготовки и хранения данных для лиц, принимающих решения (ЛПР) на основе информации из базы данных предприятия, а также информации из сторонних источников, которые в достаточном количестве стали доступны на рынке информации.
Концепция ХД предполагает не просто единый логический взгляд на данные организации, а действительную реализацию единого многоаспектного информационного зсурса.
В ХД поддерживается хронология: наравне с текущими хранятся исторические данные с указанием времени, к которому они относятся. В результате необходимые доступные данные об объекте управления собираются одном месте, приводятся к единому формату, согласовываются, агрегируются до минимально требуемого уровня обобщения.
ХД использует схемы данных, получившие названия «звезда», «созвездие» «снежинка». Суть технологии этих схем в выделении из общего объема информации собственно анализируемых данных (или фактов) и вспомогательных данных (называемых измерениями). Однако это приводит к дублированию данных в Хранилище, снижению гибкости структуры и увеличению времени загрузки. В процессе подготовки того или иного решения пользователь анализирует срез фактов по одному или нескольким измерениям.
Идея схемы звезды(starschema) в том, что имеются таблицы для каждого измерения, а все факты помещаются в одну таблицу, индексируемую множественным ключом, составленным из ключей отдельных измерений. Каждый лучсхемы звезды задает (в терминологии Кодда) направление консолидации данных по соответствующему измерению (например, Магазин – Город/район – Регион). Рекомендуется создавать таблицы фактов не для всех возможных сочетаний измерений, а только для наиболее полных (тех, значения ячеек которых не могут быть получены с помощью последующей агрегации ячеек других таблиц фактов базы данных).
В сложных задачах с многоуровневыми измерениями используется схема созвездия(factconstellationschema) и схема снежинки (snowflakeschema) В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения различных измерений. Это позволяет добиться наилучшей производительности, но часто приводит к избыточности данных.
Витрины данных (рынки данных)
Витриной Данных (иногда говорят рынок данных) – это специализированное Хранилище, обслуживающее одно из направлений деятельности компании, например учет запасов или маркетинг.
Важно, что происходящие здесь бизнес-процессы относительно однородны, круг пользователей ограничен сотрудниками одного подразделения или департамента. Количество сотрудников, вовлеченных в конкретную деятельность, невелико (рекомендуется, чтобы Витрина обслуживала не более 10–15 чел.). При этих условиях удается с использованием современных технологий развернуть Витрину подразделения за 3–4 месяца. Успех небольшого проекта (стоимость которого невелика по сравнению со стоимостью разработки корпоративного Хранилища) способствует продвижению новой технологии и приводит к быстрой окупаемости затрат.
При построении схемы взаимодействия корпоративного Хранилища и Витрин Данных в рамках создания СППР рекомендуется определить некоторую специальную структуру для хранения исторических данных и дополнительно развернуть Витрины, заполняемые данными из этой структуры. Тем самым удается разделить два процесса: накопление исторических данных и к анализ.
Современные витрины данных должны:
- хранить сотни гигабайт данных и обеспечивать сложные разновидностианалитической обработки, например, из области добычи данных (datamining);
- обеспечивать удаленный доступ к витрине данных для сотен пользователей с использованием технологии Internet и Intranet;
- централизованно администрировать и управлять многими витринам данных, которые могут содержать несогласованные и конфликтующие данные.
Оперативная аналитическая обработка данных (OLAP)
С многомерными данными сталкиваются организации, работающие в любой области бизнеса, и сложность данных не обязательно напрямую зависит от размера компании. Даже самой маленькой компании хотелось бы отслеживать продажи в зависимости от продукта, торгового представителя, географии, клиента и времени. Каждая из этих описательных категорий – сдельное измерение в модели OLAP.
Организации давно искали средства, позволяющие легко и естественно получать, просматривать и анализировать многомерные данные. OLAP предоставляет организациям наиболее гибкие и производительные средства доступа, просмотра и анализа данных, связанных с бизнесом с помощью естественной интуитивной модели данных. Благодаря легкости перемещения по данным бизнес-пользователи могут более эффективно просматривать и анализировать информацию из своих хранилищ данных, что позволяет организациям лучше осознать ценность этих данных. OLAP ускоряет доставку информации пользователям, просматривающим такие многомерные структуры. С этой целью подготовка некоторых вычисляемых значений в массиве данных осуществляется заранее, а не во время выполнения. Сочетание легкости перемещения и высокой производительности помогает пользователям просматривать и анализировать данные быстрее и эффективнее, чем это было бы возможно только на основе технологии реляционных баз данных. В результате они посвящают больше времени анализу данных и меньше – анализу баз данных.
В основе OLAP лежит многомерное концептуальное представление (multi-dimensionalconceptualview) – наиболее естественный взгляд управляющего персонала на объект управления; множественная перспектива из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям данных определяется как многомерный анализ.
Каждое измерение включает направления консолидации данных из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения «предприятие – подразделение – отдел – служащий». Измерение Время может даже включать два направления консолидации – «год – квартал – месяц – день» и «неделя – день», поскольку счет времени по месяцам и по неделям несовместим. В этом случае возможен произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция раскрытия или спуска (drillingdown) соответствует движению от высших ступеней консолидации к низшим; напротив, операция свертки или подъема (rollingup) означает движение от низших уровней к высшим.
Концептуальное представление модели данных в продукте OLAP должно быть многомерным по своей природе, то есть позволять аналитикам выполнять интуитивные операции сечения «анализа вдоль и поперек» («sliceanddice»), вращения (rotate) и размещения (pivot) направлений консолидации. Пользователь не должен знать, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся. Аналитик должен иметь возможность выполнять анализ в рамках общей концептуальной схемы. Преобразования, требующие произвольного определения, должны задаваться на функционально полном формальном языке. Переориентация направлений консолидации, детализация данных в колонках и строках, агрегация и другие манипуляции, свойственные структуре иерархии направлений консолидации, должны выполняться в максимально удобном, естественном и комфортном пользовательском интерфейсе. Настоятельно рекомендуется допущение в каждом серьезном OLAP‑инструменте как минимум пятнадцати, а лучше двадцати измерений в аналитической модели. Каждое из этих измерений должно допускать практически неограниченное количество определенных пользователем уровней агрегации по любому направлению консолидации.
Доступ к данным должен происходить на языке пользователя, в большинстве случаев не владеющего языками программирования. Можно разработать множество специализированных приложений, каждое из которых будет отвечать на какой-то один тип запросов, но заранее трудно предположить, какие еще запросы будут нужны пользователю. Поэтому универсальное средство должно либо позволять писать такие приложения очень быстро, либо давать возможность пользователю составлять его непредсказуемые запросы самостоятельно, а значит должно использовать язык бизнес-терминов вместо языка программирования.
Если принимается второй вариант, сразу появляется следствие – система должна скрывать от конечного пользователя физическую структуру и способы хранения данных. Знать такие подробности пользователю совсем не нужно. Такая задача решается введением семантического слоя, который ставит каждому бизнес-термину в соответствие способ получения данных.