Многомерность в OLAP-приложениях I уровень Многомерное представление данных -- средство конечного пользователя, обеспечивающее многомерную визуализацию и манипулирование данными. Слой многомерного представления абстрагирован от физической структуры данных и воспринимает данные как многомерные. II уровень Многомерная обработка -- язык формулирования многомерных запросов и процессор, умеющий обрабатывать такой запрос. III уровень Многомерное хранение -- средство физической организации данных, обеспечивающее выполнение многомерных запросов. Первые два уровня обязательно присутствуют во всех OLAP-средствах, третий необязателен, т. к. данные для многомерного представления могут извлекаться непосредственно из реляционной базы данных, при этом процессор многомерных запросов транслирует их в обычные SQL-запросы. Многомерный куб Куб OLAP -- это структура, в которой хранятся совокупности данных, полученных из базы данных OLAP путём всевозможных сочетаний, измерений и фактов. Многомерное пространство может иметь любое число измерений, такое пространство дискретно и содержит дискретное количество значений на каждом измерении. Размерность пространства определяется перемножением размеров всех измерений. Т. к. каждое измерение дискретно, пространство куба является ограниченным (конечным). Измерения представлены осями куба, по которым откладывают значения (например, названия товаров или месяца года), такие значения называют членами или метками (members). В отличие от одномерных пространств, многомерные модели, как правило, не предусматривают функции упорядочивания и расстояния между значениями. Единственное упорядочивание состоит в том, что значения более высокого уровня содержат значения более низкого уровня. В многомерных СУБД могут использоваться два варианта организации данных: поликубическая и гиперкубическая модель. В гиперкубической модели предполагается, что все показатели должны определяться одним и тем же набором измерений. В поликубической модели может быть определено несколько гиперкубов с различным набором измерений и разной размерностью. Измерения Измерения организуются в иерархию, состоящую, соответственно, из нескольких уровней, каждый из которых представляет уровень детализации, необходимый для соответствующего анализа. Например, "Производитель" -- "Марка автомобиля". Иерархия Существует три типа иерархии: сбалансированная, несбалансированная и неровная. Сбалансированная: количество уровней определено структурой и неизменно и каждая ветвь иерархического дерева содержит объекты каждого из уровней. Необходимо наличие связей "один ко многим" между объектами менее детального уровня по отношению к объектам более детального уровня. Категория | v Товар Все тов +----+-----+ [быт. техн.] [Хлеб. изд.] +-----+-------+ ++------+ [Хол.] [Пыл.] [] [Батон] [Булочка] Несбалансированная иерархия: иерархия, в которой количество уровней может быть изменено и каждая ветвь может содержать объекты, принадлежащие не всем уровням, а только нескольким первым. Все объекты несбалансированной иерархии должны принадлежать одному типу. Пример: "Начальник" -- "Подчинённый". Неровная иерархия: число уровней определено структурой и неизменно, но некоторые ветви могут не содержать объекты какого-то промежуточного уровня: у некоторых членов таких иерархий логические родители находятся не на вышестоящем уровне, а ранее. [Магазины] +--------+------------+ [США] [Укр.] [Молд.] +--+------+ +---+---+ | [Аризона][] [Од.] [Киев] | +--+--+ +--+--+ +---+ [М1] [М2] [М1] [М2] [М1] [М2] Для одного измерения может быть определено несколько иерархий. Факты На пересечении осей куба в ячейках (cells) располагаются данные, количественно характеризующие анализируемые факты. Ячейки могут быть пустыми или заполенными. Если значительное количество ячеек не содержит данных, то говорят, что куб разрежен. Каждый факт -- это совокупность одной или нескольких мер (measure). Например, факт изготовления детали включает в себя как минимум три меры: стоимость заготовки, стоимость изготовления и различные начисления. Наиболее часто встречаются 4 типа фактов: 1) факты, связанные с транзакциями (Transaction facts) (основаны на отдельных событиях, например, снятие денег со счёта с помощью банкомата); 2) факты, связанные с моментальными снимками (Snapshot-факты): основаны на состоянии объекта в определённый момент времени, например, на конец дня или на конец месяца: объём продаж за день; 3) факты, связанные с элементами документа (Line-item): основаны на некотором документе и содержат подробную информацию об элементах этого документа; 4) факты, связанные с событием или состоянием объекта (Event and State): представляют возникновение события без подробностей о нём. Таблица фактов является основной в хранилище данных. Она, как правило, содержит уникальный составной ключ, состоящий из ключей таблиц-измерений. Обычно это целочисленные значения или значения типа data. Как ключевые, так и некоторые неключевые поля должны соответствовать измерениям куба. Кроме ключа, таблица фактов содержит одно или несколько числовых полей, на основе которых и будут потом получены агрегатные данные. Мера может состоять из двух компонентов: собственно числовая характеристика факта; формула (как правило, обычная агрегатная функция), которая позволяет объединять несколько значений меры в одну. С т. з. вычислений факты можно поделить на три класса: 1) аддитивные (могут содержательным образом комбинироваться в любом измерении, например, имеет смысл суммировать объём продаж и для продукта, и для месторасположения, и для времени; 2) полуаддитивные (не могут комбинироваться в одном или нескольких измерениях, например, количество товара на складе есть смысл суммировать в разрезе складов, но бессмысленно в разрезе времени; 3) неаддитивные (не комбинируются в любом измерении). Аддитивными и неаддитивными могут быть факты любого рода, а полуаддитивные -- это, как правило, моментальные снимки. Агрегация -- это любая процедура формирования меньшего количества значений на основании большего количества исходных значений. Формирование заранее и сохранение агрегатов для уменьшения времени отклика на пользовательский запрос и является основным свойство OLAP-систем. Одно измерение куба может содержаться как в одной таблице, так и в нескольких связанных таблицах, соответствующих разным уровням иерархии в измерении. Если каждое измерение хранится в одной таблице, то такая схема хранилища данных называется "звезда". Если хотя бы одно измерение хранится в нескольких таблицах, то такая схема называется "снежинка". Схема "звезда" Особенности: 1) таблица фактов сильно денормализована, может состоять из миллионов строк и содержит просуммированные или фактические данные, с помощью которых можно ответить на разные вопросы; 2) несколько денормализованных таблиц измерений имеют меньше строк, чем таблица фактов, и содержат описательную информацию; 3) количество уровней в иерархии соответствует количеству столбцов в таблице измерений; 4) таблицы фактов и таблицы измерений связаны с помощью внешних ключей; 5) первичный ключ таблицы фактов полностью состоит из первичных ключей таблиц измерений; 6) агрегированные данные хранятся вместе с исходными данными. Пример: +--------------+ +------------+ +--------------+ | Магазин | | facts | | Продавец | +--------------+ +------------+ +--------------+ |idмаг |<+ |idпериода | +>|idПрод | |НазвМаг | +------------------>->|idмагазина |<<---------+ |Имя | |idгорода | |idпродавца | |idФил | |НазвГор | |idтовара | |НазвФил | |idСр | +- - - - - - + |АдрФил | |НазвСтр | |КолПродТов | +--------------+ +--------------+ |ЦенаПрод | |СтоимПрод | +------------+ Преимущества: упрощается восприятие пользователем и формулировка запросов, уменьшается количество соединений между таблицами, проще пополнять измерения. Недостатки: возрастает избыточность (требуется больше памяти), если агрегированные данные хранятся вместе с фактическими данными, то в измерениях нужно добавлять дополнительные параметры. Схема "снежинка" Особенности: 1) денормализованная таблица фактов; 2) может содержать агрегированные фактические данные; 3) несколько таблиц измерений, которые нормализованы, в отличие от "звезды"; 4) агрегированные данные могут храниться отдельно от фактических. +-------+ +------------+ +-----------+ |Магазин| |Строка | |Город | +-------+ +------------+ +-----------+ |idМаг | |idСтр |<-------->>|idГор |<------->>|НазвМаг| |Назв | |Назв | |idГор | +------------+ |idСтр | +-------+ +-----------+ Преимущества: меньше избыточность данных. Недостатки: увеличивается время выполнения запросов, усложняется процедура добавления нового измерения, структура данных сложнее для понимания