Модели данных информационного хранилища

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

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

Многомерные данные могут быть отображены в моделях посредством инструментов в виде СУБД на основе реляционных моделей данных, а также и специальными многомерными инструментальными средствами, называемыми объектными надстройками, многомерными и/или объектно-ориентированными СУБД.

Элементы моделей данных информационного хранилища

Содержание и назначение таблицы фактов

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

Рассматривают четыре вида фактов:

– транзакционные факты (transaction facts), отражающие происходящие в системе события, например финансовые и другие операции;

– «моментальные снимки» (Snapshot facts), фиксирующие состояния объекта в заданные моменты времени — наличие товаров на складах, состояния счетов в банке и так далее;

– элементы документов (Line-item facts), содержащие сведения о реквизитах документов — таких как количество отправленных, полученных товаров, ценах, дате и времени отправки;

– событие или состояние объекта (Event or state facts), отражающие акт совершения того или иного действия — отправку или прибытие товара, перечисление денежных сумм без описания их.

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

Таблицы размерности (измерений), другие компоненты модели

Таблицы, наполняющие факт-таблицы содержанием называют таблицы размерности или измерений (dimensional table).

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

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

Схемы представления многомерных данных

Представление многомерных данных, в том числе и на основе реляционных моделей может выполняться в виде трех вариантов схем:

— «звезда»;

— «снежинка»;

— «созвездие».

Линейное представление на плоскости отображено на рисунках 3.8 — 3.10

Схема «звезда» состоит только из таблиц размерности и таблицы факта. Она представлена на рис. 3.8. и 3.11. Если каждое измерение содержится в одной таблице, такая схема хранилища данных носит название «звезда» (star schema).

Развитием схемы «звезда» является схема «снежинка» (snowflake schema). Ее отличает от первой схемы большое количество консольных таблиц, они имеются практически на каждой таблице размерности и могут иметь несколько уровней иерархии, как показано на рис. 3.9. и 3.12.

Говоря об измерениях, следует упомянуть о том, что значения, могут иметь различные уровни детализации. Например, нас может интересовать суммарная стоимость заказов, сделанных клиентами в разных странах, либо суммарная стоимость заказов, сделанных иногородними клиентами или даже отдельными клиентами. Естественно, результирующий набор агрегатных данных во втором и третьем случаях будет более детальным, чем в первом. Заметим, что возможность получения агрегатных данных с различной степенью детализации соответствует одному из требований, предъявляемых к хранилищам данных, — требованию доступности различных срезов данных для сравнения и анализа.

Схема "созвездие" ( fact constellation schema ) получается из нескольких таблиц фактов. В этом варианте многомерной модели через консольные или таблицы размерности сообщаются несколько таблиц фактов, отображающих несколько объектов с общими атрибутами.

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

Рис. 3.8. Модель данных по схеме «звезда»

Рис. 3.9. Модель данных по схеме «снежинка»

Рис. 3.10. Модель данных по схеме «созвездие»

Далее на рисунках 3.11 — 3.15 приведены примеры реализации названных моделей в среде СУБД MS SQL Server.

Рис. 3.11. Система таблиц по схеме «звезда»

Рис. 3.12. Система таблиц по схеме «Снежинка»

Рис. 3.13. Система таблиц по схеме «созвездие»

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

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

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

OLAP-анализ может быть реализован в системе клиент-сервер. Клиентские средства реализуют небольшое число измерений. Возможны различные варианты распределения функций между серверной и клиентской частями ИАС в OLAP-анализе.

Дата добавления: 2014-02-26; просмотров: 1390; Нарушение авторских прав

Мы поможем в написании ваших работ!