В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
Лариса Меньшикова
экономический советник
департамента информационных систем
Банка России, к.ф.-м.н., доцент МИРЭА
Для определения основных моделей хранилищ данных необходимо четко сформулировать все необходимые термины и разобраться в их специфике.
Хранилище данных – очень большая предметно-ориентированная информационная корпоративная БД, специально разработанная и предназначенная для подготовки отчетов, анализа бизнес-процессов с целью поддержки принятия решений в организации.
Корпоративное хранилище данных (КХД) преобразует данные, метаданные и НСИ из разнородных источников и предоставляет их пользователям аналитических систем как единую версию правды. КХД строится на базе клиент-серверной архитектуры, реляционной СУБД и утилит поддержки принятия решений.
СУБД – это программная система, поддерживающая и управляющая логической базой или базами данных. СУБД для ХД, помимо поддержки реляционной модели данных (расширенной для поддержки новых структур и типов данных, таких как XML), обеспечивают доступ к информации со стороны независимых приложений, а также включают механизмы выявления требований к нагрузке и контроля различных параметров доступа пользователей к отдельной сущности данных.
Данные из промышленной OLTP-системы копируются в ХД таким образом, чтобы построение отчетов и OLTP-анализ не использовали ресурсы промышленной системы и не нарушали ее стабильность. Данные загружаются в хранилище с определенной периодичностью, поэтому актуальность данных несколько отстает от OLTP-системы. Данные объединяются в категории и хранятся в соответствии с областями, которые они описывают, а не с приложениями, которые они используют.
В зависимости от приоритетов в исполнении вышеуказанных основных функций необходимо выбирать архитектуру КХД.
Уильям Инмон, основатель нового направления развития технологии БД/ХД, в 1990 г. определил информационное хранилище как специальным образом администрируемую БД, содержимое которой имеет следующие свойства:
В части предметной ориентации в отличие от БД в традиционных OLTP-системах, где данные подобраны в соответствии с конкретными приложениями, информация в ХД ориентирована на задачи поддержки принятия решений. Для системы поддержки принятия решений требуются "исторические" данные, которые отражают развитие всех направлений деятельности компании во времени.
Интегрированность данных заключается в том, что данные информационного хранилища, поступающие из различных источников, где они могут иметь разные имена, атрибуты, единицы измерения и способы кодировки, после загрузки в ХД очищаются и объединяются, с этого момента они представляются пользователю в виде единого информационного пространства не только в части имен и форматов, но и в части кодирования.
Инвариантность во времени данных в ХД достигается за счет введения полей с атрибутом "время" (день, неделя, месяц) в ключи таблиц. В результате записи в таблицах ХД никогда не изменяются, представляя собой снимки данных, сделанные в определенные отрезки времени. В ХД содержатся "моментальные снимки данных". Каждый элемент в своем ключе явно или косвенно хранит временной параметр, например день, месяц или год.
В отличие от OLTP-систем, где записи могут регулярно добавляться, удаляться и редактироваться, в ХД однажды загруженные данные теоретически никогда не меняются. По отношению к ним возможны только две операции: начальная загрузка и чтение (доступ). Это и определяет специфику проектирования структуры БД для ХД. Если при создании OLTP-систем разработчики должны учитывать такие моменты, как откаты транзакций после сбоя сервера, борьба с взаимными блокировками процессов, сохранение целостности данных, то для DW данные проблемы не столь актуальны. Перед разработчиками стоят другие задачи, связанные, например, с обеспечением высокой скорости доступа к данным.
Минимизация избыточности информации обусловлена рядом процессов:
Все вышеперечисленные свойства классического ХД на практике учитываются в качестве состояния, к которому нужно стремиться.
Необходимость в репозитории данных стала бесспорной после ряда неудачных попыток создать виртуальные ХД. В этой архитектуре клиентская программа напрямую получала данные из источников, преобразуя их на лету. Время ожидания исполнения запроса и преобразования данных компенсировалось простотой архитектуры. Поскольку результат выполнения запроса не сохранялся, повторный запрос с теми же или подобными параметрами требовал повторного преобразования данных, что и привело к отказу от виртуальных хранилищ и к созданию репозиториев данных.
В репозиторий метаданных автоматически включаются словари источников данных. Здесь же хранятся форматы данных для их последующего согласования, периодичность пополнения данных, согласованность во времени.
Витрина данных представляет собой массив тематической, узконаправленной информации, ориентированный, например, на пользователей одной рабочей группы или департамента.
Концепция витрин данных была предложена исследовательской компанией Forrester Research еще в 1991 г. По мысли авторов, витрины данных – это множество тематических БД, содержащих информацию, относящуюся к отдельным аспектам деятельности организации.
Концепция витрин данных имеет ряд несомненных достоинств:
Но концепция витрин данных имеет ряд существенных недостатков в части обеспечения целостности и непротиворечивости хранимых в ней данных.
Идея соединить две концепции хранилищ данных и витрин данных, по-видимому, принадлежит М. Демаресту, который в 1994 г. предложил объединить две концепции и использовать ХД в качестве единого интегрированного источника данных для витрин данных.
И сегодня часто используется именно такое решение:
Данное решение позволяет наиболее полно реализовать и использовать достоинства каждого из подходов, а это прежде всего компактное хранение детализированных данных и поддержка очень больших БД, реализованных как реляционные СУБД. Кроме того, к достоинствам можно отнести простоту настройки и хорошее время отклика при работе с агрегированными данными, обеспечиваемые многомерными СУБД.
Реляционная форма представления данных, используемая в ЦХД КХД, обеспечивает наиболее компактный способ хранения данных. Современные реляционные СУБД уже умеют работать с БД, имеющими размер порядка нескольких терабайт. Хотя такая система обычно не сможет обеспечить оперативный режим обработки аналитических запросов, при использовании новых способов индексации и хранения данных, а также частичной денормализации таблиц время обработки заранее регламентированных запросов оказывается вполне приемлемым.
В свою очередь, использование многомерных СУБД в узлах нижнего уровня обеспечивает минимальное время обработки и ответа на нерегламентированные запросы пользователя. Кроме того, в некоторых многомерных СУБД имеется возможность хранить данные как на постоянной основе (непосредственно в многомерной БД), так и динамически (на время сеанса) загрузить данные из реляционных БД (на основе регламентированных запросов).
Таким образом, можно хранить на постоянной основе только те данные, которые наиболее часто запрашиваются в данном узле. Для всех остальных хранятся только описания их структуры и программы их выгрузки из центральной БД. И хотя при первичном обращении к таким виртуальным данным время отклика может оказаться достаточно продолжительным, такое решение обеспечивает высокую гибкость и позволяет использовать более дешевые аппаратные средства.
Все ХД можно разделить на две большие категории:
Следует отметить, что на практике не бывает ХД, в точности соответствующих той или иной идеальной модели.
В нормализованных хранилищах данные находятся в предметно-ориентированных таблицах третьей или более нормальных формах.
На практике существует 6 нормальных форм, в которых могут находиться кортежи отношения БД: при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.
Опубликовано: Журнал "Технологии и средства связи" #3, 2011
Посещений: 19384
Статьи по теме
Автор
| |||
В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
