Что такое витрина данных. Хранилища и витрины данных в банковском деле

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

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

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

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

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

Конец работы -

Эта тема принадлежит разделу:

Учебное пособие учебной Дисциплины Информационные технологии в профессиональной деятельности

Учебное пособие учебной ДИСЦИПЛИНЫ Информационные технологии в.. Разработчик к э н доцент Ярошенко Е В..

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

Корпоративная информационная система
Решение управленческих задач на основе оперативной и достоверной информации при постоянном увеличении количества факторов, влияющих на работу предприятия и, одновременно, сокращении времени на прин

Методология планирования материальных потребностей предприятия. MRP системы
MRP (Material Requirement Planning)- Планирование потребности в материалах. Методология планирования потребности в материальных ресурсах (MRP) заключается

Системы планирования производственных ресурсов. MRP II системы
MRP II (Manufacturing Resource Planning) – Планирование производственных ресурсов. Основными целями MRP систем являются: удовлетворение потребности в материалах, компонент

Система планирования ресурсов предприятий. ERP система
ERP система (Enterprise Resource Planning System) – система планирования ресурсов предприятий. Новым этапом в развитии и внедрении систем управления предприятием, основанн

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

CRM системы
CRM система (Customer Relationship Management System)– система управления взаимоотношениями с клиентами. Это современная стратегия, основанная на и

Цели, процессы, структура
Функциональность CRM охватывает маркетинг, продажи и сервис, что соответствуют стадиям привлечения клиента, самого акта совершения сделки (транзакция) и послепродажного обслуживания, то есть все те

Обзор CRM-решений в России
Если на западном рынке количество CRM-систем измеряется сотнями, то в России представлен довольно узкий спектр решений, в основном крупных поставщиков, давно предлагающих свои ERP-системы. В то же

SRM системы
SRM система (Supplier Relationship Management) – это системы управления отношениями с поставщиками. SRM система - инструмент укрепления отношений с поставщиками. Многие предприятия стараются повыси

Базы данных и хранилища данных
Часто в речи мы подменяет слово «информация» словом «данные». Между данными и информацией действительно существует тесная связь. Существование одного без другого невозможно. Преобр

Расхождения в требованиях к хранению данных в БД и ХД
В базе данных хранятся только последние значения какой-либо информации (например, текущее значение счета клиента, текущее значение имени и параметров клиента). В хранилище данных будет содержаться

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

Business Intelligence (BI)
Внедрение BI-технологий в различные программные продукты является новым и перспективным подходом к управлению данными и знаниями компании. Впервые о таком понятии, как «bus

Многомерный анализ данных на основе OLAP
Для решения аналитических задач, связанных со сложными расчетами, прогнозированием, моделированием сценариев «Что, если…» применяется технология многомерного анализа данных - Технол

Технология Data Mining
По данным компании Gartner, неструктурированные документы составляют более 80% корпоративных данных, а количество внешних источников (интернет-ресурсов, блогов, форумов, СМИ) исчисл

Типы закономерностей, которые позволяют выявлять методы Data Mining
Выделяют пять стандартных типов закономерностей, которые позволяют выявлять методы Data Mining: ассоциация, последовательность, классификация, кластеризация и прогн

Процесс принятия решений
Как принять правильное решение? Этот вечный вопрос мы задаём себе на протяжении всей жизни. И как часто принимаем решения в лучшем случае на основе интуиции. Методами рационального

Задачи принятия решения
Задача принятия решения имеет две главные разновидности: 1. задача выбора (выбрать или отвергнуть несколько вариантов из группы возможных) 2. задача распр

Технология принятия решения
При принятии решения все решения можно разделить на четыре большие группы: 1. решения, основанные на теории управления 2. решения, основанные на модели Карнеги (модель ограниченно

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

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

Системы поддержки принятия решений (СППР)
Система поддержки принятия решений (СППР) - это автоматизированная информационная система, помогающая лицам, принимающим решение (ЛПР) сделать мотивированный выбор лучшего варианта

Структура сппр
Основными компонентами СППР являются: оборудование (рабочие станции), программное обеспечение (СППР-генераторы), базы данных, базы моделей. В СППР используются аналитические модели, специализирован

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

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

Реализация
Практическая разработка ЭС с использованием выбранных инструментальных средств: традиционных языков программирования, языков обработки списков и процедурных языков, языка логического программирован

Финансовый риск
Финансовый риск связан с возможностью невыполнения фирмой своих финансовых обязательств. Это опасность денежных потерь в результате наступления ущерба из-за проведения каких-либо операций в финансо

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

Управление рисками ИТ-проекта
Управление рисками ИТ-проекта, в целом, включает следующие процессы: выявление и идентификацию предполагаемых рисков; анализ и оценку рисков; выбо

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

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

· OLTP (Online Transaction Processing) - онлайновая обработка транзакций, использующая такой способ организации СУБД, при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа;

· OLAP (Online Аnalytical Processing) - аналитическая обработка информации в реальном времени, включающая составление и динамическую публикацию отчётов и документов и реализующая принципы построения систем поддержки принятия решений – Decision Support System (DSS) и систем интеллектуального анализа данных – Data Mining .

При реализации технологий OLAP и OLTP используется новая форма организации внутримашинной информационной базы, представляющей совокупность взаимосвязанных компонентов: Операционной Базы Данных (ОБД), Хранилищ данных (ХД) - Data Warehouse (DW) и Витрин Данных (рис. 5.6).

Рис. 5.6 - Организация внутримашинной информационной базы ИС

Операционные БД систем OLTP (Online Transaction Processing) - онлайновая обработка транзакций, являются основным источником информации. Их дополняют внешние данные , представленные обычно в текстовом формате.

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

Свойства хранилищ данных:

· предметная ориентация – данные представляют предмет, а не процессы;

· интеграция;

· строгая и однотипная хронология – обязательная привязка данных по времени;

· неизменяемость – данные не изменяются, а пополняются за счет ОБД и внешних данных.

Структура данных в хранилище данных:

· мета данные (данные об данных) – информация об источнике и произведенных над исходными данными операциях;

· исходные (детальные) данные – обычно денормализованные данные, обладающие переизбыточностью, что позволяет повысить скорость доступа к необходимым данным, хотя и требует большей емкости носителей информации;

· агрегированные данные.

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

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

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

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

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

Архитектура информационной базы ИС имеет шесть уровней (рис.5.7) (несмотря на то, что сами компоненты могут отсутствовать, уровни в том или ином виде сохраняются):

Рис. 5.7 – Шесть уровней архитектуры хранилища данных

Первый уровень представлен источниками данных , в качестве которых выступают транзакционные и унаследованные системы, архивы, разрозненные файлы известных форматов, документы MS Office, а также любые иные источники структурированных данных.

На втором уровне размещается система извлечения, преобразования и загрузки данных (ETL - Extract, Transformation and Load). Основная задача ETL – извлечь данные из разных систем, привести их к согласованному виду и загрузить в хранилище.

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

Системы уровня распределения данных выполняют задачи, значительно отличающиеся от задач ETL, а именно, выборку реструктуризацию и доставку данных (SRD – Sample, Restructure, Deliver). ETL извлекает данные из множества внешних систем. SRD выполняет выборку из единого хранилища данных. ETL получает несогласованные данные, которые надо преобразовать к единому формату. SRD имеет дело с очищенными данными, структуры которых должны быть приведены в соответствие с требованиями различных приложений. ETL загружает данные в центральное хранилище. SRD должно доставить данные в различные витрины в соответствии с правами доступа, графиком доставки и требованиями к составу информации.

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

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

Как исходные, так и агрегированные данные могут храниться либо в реляционных, либо в многомерных БД. Поэтому в настоящее применяются три способа хранения данных :

· MOLAP (Multidimensional OLAP) или OLAP со многими измерениями – исходные и агрегированные данные хранятся в многомерной БД;

· ROLAP (Relational OLAP) или реляционный OLAP – исходные данные находятся в своей реляционной БД, агрегированные данные помещают в специально созданные служебный таблицы в той же БД;

HOLAP (Hybred OLAP) или гибридный OLAP – исходные данные находятся в своей реляционной БД, агрегированные данные хранятся в многомерной БД.

Технологии Big Data создавались в качестве ответа на вопрос «как обработать много данных». А что делать, если объем информации не является единственной проблемой? В промышленности и прочих серьезных применениях часто приходится иметь дело с большими данными сложной и переменной структуры, разрозненными массивами информации. Встречаются задачи, способ решения которых наперед не известен, и аналитику необходимы средства исследования исходных данных или результатов вычислений на их основе без привлечения программиста. Нужны инструменты, сочетающие функциональную мощь систем BI (а лучше – превосходящие ее) со способностью к обработке огромных объемов информации.

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

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

Кроме конкретных показаний датчиков, для анализа необходимо иметь список сенсоров и устройств, на которых они установлены. Оценим порядок числа информационных сущностей, с которыми мы имели бы дело на реальном предприятии:

Способы хранения для данных разных типов зависят от их объема, структуры и требуемого режима доступа. В данном случае мы выбрали именно такие средства для создания «разнобоя», но и на реальных предприятиях чаще всего нет возможности свободно их выбирать – все зависит от сложившегося ИТ-ландшафта. Аналитической же системе нужно собрать весь «зоопарк» под одной крышей.

Пусть мы хотим предоставить аналитику возможность делать запросы такого типа:

Какие единицы маслонаполненного оборудования работали при температуре выше 300 градусов за последнюю неделю?
Какое оборудование находится в состоянии, выходящем за пределы рабочего диапазона?

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

Итак, наш аналитик будет формулировать запросы в привычных ему терминах, и получать в ответ наборы данных – независимо от того, из какого источника эти данные извлечены. Рассмотрим пример простого запроса, на который можно найти ответ в нашем наборе информации. Пусть аналитик интересуется оборудованием , установленные на котором сенсоры одновременно измерили температуру больше 400 0 и давление больше 5 мПа в течение заданного периода времени. В этой фразе мы выделили жирным слова, соответствующие сущностям информационной модели: оборудование, сенсор, измерение. Курсивом выделены атрибуты и связи этих сущностей. Наш запрос можно представить в виде такого графа (под каждым типом данных мы указали хранилище, в котором они находятся):

При взгляде на этот граф становится понятной схема выполнения запроса. Сначала нужно отфильтровать измерения температуры за заданный период со значением больше 400 0 C, и измерения давления со значением больше 5 мПа; затем нужно найти среди них те, которые выполнены сенсорами, установленные на одной и той же единице оборудования, и при этом выполнены одновременно. Именно так и будет действовать витрина данных.
Схема нашей системы будет такой:

Порядок работы системы таков:

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

Вся «магия», конечно, происходит внутри витрины. Перечислим принципиальные моменты.

1. В хранилище триплетов Apache Jena (можно использовать и любое другое) у нас хранится как сама модель предметной области, так и настройки мэппинга на источники данных. Таким образом, через редактор информационной модели мы задаем и набор терминов, в которых строятся запросы (устройство, сенсор и т.д.), и служебные сведения о том, откуда брать соответствующую им фактическую информацию. На следующем рисунке показано, как в нашем редакторе онтологий выглядит дерево классов модели демонстрационного примера (слева), и одна из форм настройки мэппинга данных с источником (справа).

2. В нашем примере данные одного и того же типа (измерения температуры) хранятся одновременно в двух разных источниках – HBase и текстовом файле HDFS. Однако для выполнения приведенного запроса обращаться к файлу не нужно, т.к. в нем заведомо нет полезной информации: ведь в файле хранятся измерения температуры резервуара, а давление в резервуарах не измеряется. Этот момент дает представление о том, как должен работать оптимизатор выполнения запросов.

3. Витрина данных не только компонует и связывает информацию из различных источников, но и делает логические выводы на ней в соответствии с заданными правилами. Автоматизация получения логических выводов – одно из главных практических преимуществ семантики. В нашем примере с помощью правил решена проблема получения выводов о состоянии устройства на основе данных измерений . Температура и давление содержатся в двух разных сущностях типа «Измерение», а для описания состояния устройства необходимо их объединить. Логические правила применяются к содержимому временного графа результатов, и порождают в нем новую информацию, которая отсутствовала в источниках.

4. В качестве источников данных могут выступать не только хранилища, но и сервисы. В нашем примере мы спрятали за сервисом расчет предпосылок к возникновению аварийного состояния при помощи одного из алгоритмов Spark MLlib. Этот сервис получает на вход информацию о состоянии устройства, и оценивает его с точки зрения наличия предпосылок к аварии (для обучения использованы ретроспективные данные о том, какие условия предшествовали реально случившимся авариям; в качестве исходных данных нужно рассматривать не только мгновенные значения физических характеристик устройства, но и элементы основных данных – например, степень его износа).
Эта возможность очень важна, так как позволяет аналитику самому выполнять запуск расчетных модулей, подготовленных программистами, передавая им на вход различные массивы данных. В этом случае аналитик будет работать уже не с исходными данными, а с результатами вычислений на их основе.

5. Аналитик строит запросы при помощи интерфейсов нашей Системы управления знаниями, среди которых – как несколько вариантов формального конструктора запросов, так и интерфейс поиска на контролируемом естественном языке. На следующем рисунке слева показана форма построения запроса на контролируемом языке, а справа – пример результатов другого запроса.

Конечно, в любой бочке меда найдется ложка дегтя. В данном случае она состоит в том, что на действительно больших данных приведенная архитектура будет работать не так уж быстро. С другой стороны, при работе аналитика в режиме «свободного поиска» решения проблем быстродействие для него обычно не принципиально; в любом случае, витрина будет выдавать результаты куда быстрее, чем программист, к которому при ее отсутствии аналитику придется обращаться за ручным выполнением каждого своего запроса.

За рамками нашего рассказа осталось немало интересных моментов:

как организован сбор данных сенсоров в HBase с помощью Flume;
запросы к источникам данных могут выполняться не просто асинхронно, но даже при отсутствии онлайн-связи с ними – на этот случай предусмотрен специальный механизм передачи запроса и получения ответа;
результаты выполнения запроса могут не просто выдаваться пользователю в виде таблицы или выгружаться в Excel, но и попадать напрямую в BI-систему в виде набора данных для дальнейшего анализа;
способы конвертации идентификаторов и ссылок на объекты в разных источниках, вопросы транспорта сообщений между компонентами системы, и многое другое.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Data Mart ; другие варианты перевода: хранилище данных специализированное, киоск данных, рынок данных) - срез хранилища данных , представляющий собой массив тематической, узконаправленной информации, ориентированный, например, на пользователей одной рабочей группы или департамента.

Концепция витрин данных

Концепция витрин данных была предложена Forrester Research ещё в 1991 году . По мысли авторов, витрины данных - множество тематических баз данных (БД), содержащих информацию, относящуюся к отдельным аспектам деятельности организации.

Концепция имеет ряд несомненных достоинств:

Аналитики видят и работают только с теми данными, которые им реально нужны.
Целевая БД максимально приближена к конечному пользователю.
Витрины данных обычно содержат тематические подмножества заранее агрегированных данных, их проще проектировать и настраивать.
Для реализации витрин данных не требуется высокомощная вычислительная техника.

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

Смешанная концепция витрин данных и хранилищ данных

Идея соединить две концепции - хранилищ данных и витрин данных, по-видимому, принадлежит М. Демаресту (M. Demarest), который в 1994 году предложил объединить две концепции и использовать хранилище данных в качестве единого интегрированного источника данных для витрин данных.

И сегодня именно такое многоуровневое решение:

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

постепенно становится стандартом де-факто, позволяя наиболее полно реализовать и использовать достоинства каждого из подходов:

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

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

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

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