В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
Лариса Меньшикова
экономический советник
департамента информационных систем
Банка России, к.ф.-м.н., доцент МИРЭА
В нормализованных хранилищах данные находятся в предметно-ориентированных таблицах третьей или более нормальной формы.
Нормальная форма Бойса – Кодда определяется тем, что отношение находится в третьей нормальной форме и в нем отсутствуют функциональные зависимости атрибутов первичного ключа от неключевых атрибутов.
Отношение находится в четвертой нормальной форме, если оно находится в нормальной форме Бойса – Кодда и не содержит нетривиальных многозначных зависимостей, равно как и нефункциональных многозначных зависимостей.
Многозначная зависимость не всегда является функциональной. Наличие в отношении многозначных зависимостей, не являющихся функциональными зависимостями от возможного ключа, приводит к аномалиям обновления таких отношений. Поэтому лучше всего использовать пятую нормальную форму.
Таблица находится в пятой нормальной форме, если она находится в четвертой нормальной форме и любая многозначная зависимость соединения в ней является тривиальной.
Пятая нормальная форма в большей степени является теоретическим исследованием и практически не применяется при реальном проектировании баз данных. Это связано со сложностью определения самого наличия зависимостей "проекции – соединения", поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.
Нормализованные хранилища характеризуются как простые в создании и управлении. Недостатком таких ХД является большое количество таблиц как следствие нормализации, из-за чего для получения какой-либо информации нужно делать выборку из многих таблиц одновременно, что приводит к ухудшению производительности системы.
Такой тип хранилищ представляет собой уже не плоские таблицы, а кубы, учитывающие не только размерностные характеристики модели, но и ее внутреннюю структуру в виде так называемого графа расслоения и связности.
Основным достоинством размерностных ХД является более эффективное хранение данных, а также простота организации доступа к данным при анализе. Основные недостатки – более сложные процедуры подготовки и загрузки данных, а также управление при изменении размерностей данных.
Размерностные ХД используют схему "звезда" или "снежинка".
Такая схема состоит из двух типов таблиц: одной таблицы фактов – центр "звезды" и нескольких таблиц измерений по числу измерений в модели данных – лучи "звезды".
Таблица фактов является основной таблицей ХД и содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться, а также содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений.
Четыре наиболее часто встречающихся типа фактов:
Данная таблица расположена в структуре многомерной БД, которая содержит атрибуты событий, сохраненных в таблице фактов. Атрибуты представляют собой текстовые или иные описания, логически объединенные в одно целое. Записи в таблице фактов связаны с записями в таблицах измерений по вторичному ключу.
Таблица фактов может содержать сотни тысяч или даже миллионы записей, при этом как ключевые, так и некоторые неключевые поля должны соответствовать будущим измерениям OLAP-куба. Помимо этого, таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут агрегированы данные. Для многомерного анализа используются таблицы фактов, содержащие как можно более подробные данные (то есть соответствующие членам нижних уровней иерархии соответствующих измерений). В таблице фактов нет никаких сведений о том, как группировать записи при вычислении агрегатных данных. Эти сведения, в дальнейшем используемые для построения иерархий в измерениях куба, содержатся в таблицах измерений.
Различные таблицы фактов совместно используют таблицы размерностей, что значительно облегчает операции объединения данных из нескольких предметных таблиц фактов.
Обычно данные в таблицах-измерениях денормализованы, что позволяет уменьшить число таблиц и сократить время исполнения запроса за счет неэффективного использования дискового пространства.
В случае если требуется произвести нормализацию таблиц-измерений, то используют схему "снежинка".
Данная схема получила свое название за форму отображения логической схемы таблиц в многомерной БД. Так же как и в схеме "звезда", схема "снежинка" представлена централизованной таблицей фактов, связанной с таблицами измерений. Отличием является то, что в ней таблицы измерений нормализованы с рядом других связанных измерительных таблиц, в то время как в схеме "звезда" таблицы измерений полностью денормализованы с каждым измерением, представленным в виде единой таблицы, без соединений на связанные таблицы в схеме "снежинка". Чем больше степень нормализации таблиц измерений, тем сложнее выглядит структура схемы "снежинка". Создаваемый "эффект снежинки" затрагивает только таблицы измерений и не применим к таблицам фактов.
Схема "снежинка", так же как и схема "звезда", наиболее часто встречается в таких ХД, для которых скорость получения данных более важна, чем эффективность их манипуляции.
Схема "снежинка" более подходит для случаев применения более сложного инструментария для реализации запросов, который в большей степени изолирует пользователей от детальной структуры таблиц, а также для среды с множеством запросов сложной структуры.
Существует множество типовых вариантов концептуальных моделей КХД, которые, как правило, нельзя четко отнести к нормализованным (модель Инмона) и размерностным ХД (модель Кимбалла):
Остановимся подробнее на каждом из вышеперечисленных типов ХД, прорисовав их архитектуру как проекцию на типовую архитектуру ИАС (см. рис. 1).
Это одна из моделей ХД, в котором данные хранятся в разных БД под управлением различных СУБД, объединенных посредством метаданных с единой логической моделью данных.
Основой виртуального ХД является репозиторий метаданных, который описывает источники информации, запросы СУБД на чтение данных и процедуры обработки и предоставления информации. В случае если в информационно-аналитической системе, работающей с таким ХД, не используются витрины данных, конечные пользователи фактически работают с источниками данных напрямую (см. рис. 2).
Виртуальные ХД можно разделить на две категории, отличающиеся друг от друга сложностью реализации – с централизованным ведением метаданных и с децентрализованным ведением метаданных.
В случае слабой зависимости данных из разных источников этот вариант наиболее приемлемый, так как обладает целым рядом явных преимуществ: минимальные затраты и работа с данными источников без промежуточных слоев. Но есть и два очевидных недостатка виртуальных ХД:
Витрина данных – это набор тематически связанных БД, содержащий тематически ориентированные итоговые данные, в качестве расчетных величин для которых используются данные из всех БД.
Если на основе одних и тех же БД проектируется несколько витрин данных, то возможны два случая реализации данной архитектуры – зависимые витрины данных и независимые витрины данных.
В случае если это зависимые витрины данных, то есть витрины данных, в которых одни и те же итоговые параметры получаются в разных витринах и используют конечные и промежуточные расчетные величины из других витрин данных, то целесообразно использование такого варианта при матрице связи ранга не более 3, так как в противном случае практика создания ХД приводит к некорректно поставленным обратным задачам восстановления источника данных по итогам.
Независимые витрины данных – это витрины данных, в каждой из которых либо расчетные алгоритмы не связаны между собой, либо одни и те же алгоритмы применяются к данным, разделенным по географическому, временному или какому-либо другому признаку полностью (см. рис. 3). Данный вариант имеет место только в случае, если данные в разных витринах связаны только по первичному ключу, и, кроме того, транзакционная и аналитическая обработка данных разнесены на разные аппаратно-программные комплексы.
Создание независимых витрин было первой реакцией на необходимость разделения аналитической и транзак-ционной обработки данных для нужд различных систем.
Использование данного варианта архитектуры – независимых витрин данных – упрощает проектирование, но усложняет эксплуатацию программно-аппаратных комплексов, так как в этом случае необходимо удовлетворить взаимоисключающим требованиям аналитических и транзакционных систем при проектировании физических БД.
В данном случае система извлечения, преобразования и загрузки данных является центром, вокруг которого строится вся архитектура КХД. Информация из разнородных источников поступает в ETL, которая загружает очищенные и согласованные данные в ЦХД, в оперативный склад данных (ОСД), если он есть (см. рис. 4). Но загрузка данных в витрины данных происходит из ETL напрямую.
На практике такая архитектура возникает из-за требований скорейшего, без временных задержек, доступа к аналитическим данным. Использование оперативного склада данных не решает задачи, так как пользователи могут находиться в другом регионе, и им требуется территориальная витрина данных. Другой причиной может стать запрет на размещение разнотипной информации в ОСД по соображениям безопасности.
По тем или иным причинам подобные архитектуры встречаются, и одной из проблем их эксплуатации являются сложности с восстановлением данных после краха витрин, напрямую снабжающихся из ETL. Дело в том, что средства ETL не предназначены для долговременного хранения извлеченных и очищенных данных. Транзакционные системы, как правило, ориентированы на выполнение текущих операций. Поэтому при потере данных в витринах, связанных с ETL, приходится либо поднимать информацию из средств резервного копирования транзакционных систем, либо организовывать исторические архивы систем – источников данных.
Еще одним решением является двойное подключение подобных витрин – напрямую к средствам ETL и к ХД, что приводит к недоразумениям и несогласованности результатов аналитических работ. Причина кроется в том, что данные, поступающие в хранилище, как правило, проходят дополнительные проверки на непротиворечивость с уже загруженными данными. Например, может прийти финансовый документ с реквизитами, почти совпадающими с документом, поступившим в ЦХД ранее. Система ETL, не обладая памятью обо всех загруженных данных, не может выявить, является новый документ законным исправлением существующего или это ошибка.
Средства верификации данных могут выявить подобные ситуации, действуя внутри ХД. В случае выявления ошибки новые данные будут отброшены. Если же это регламентированное исправление, то изменения коснутся не только данных цифр, но и агрегированных показателей, составленных при участии исправляемых данных.
Таким образом, информация, попавшая в витрину данных напрямую из ETL, может противоречить данным, поступившим из ЦХД. В качестве решения иногда в витрине реализуют те же алгоритмы верификации данных, что и в ЦХД. Недостатком является необходимость поддержки и синхронизации одних и тех же алгоритмов в ЦХД и в витринах, питающихся непосредственно от ETL.
Таким образом, параллельные витрины данных приводят к повторной обработке данных, к созданию избыточных операционных архивов, к поддержке дублирующих приложений и децентрализации обработки данных, что, как правило, является причиной несогласованности информации.
Тем не менее параллельные витрины имеют право на существование в тех случаях, когда оперативность доступа к аналитической информации важнее недостатков этой архитектуры.
Опубликовано: Журнал "Технологии и средства связи" #4, 2011
Посещений: 26973
Статьи по теме
Автор
| |||
В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
