• одно или несколько соединений таблицы фактов с таблицами измерений;

• несколько фильтров (SQL-оператор WHERE), применяемых к таблице фактов или таблицам измерений;

• группировку и агрегирование по требуемым элементам иерархии измерений (dimension elements).

• Схема снежинки получила свое название за свою форму, в виде которой отображается логическая схема таблиц в многомерной базе данных. Так же как и в схеме звезды, схема снежинки представлена централизованной таблицей фактов, соединенной с таблицами измерений. Отличием является то, что здесь таблицы измерений нормализованы с рядом других связанных измерительных таблиц, — в то время как в схеме звезды таблицы измерений полностью денормализованы, с каждым измерением представленным в виде единой таблицы, без соединений на связанные таблицы в схеме снежинки. Чем больше степень нормализации таблиц измерений, тем сложнее выглядит структура схемы снежинки. Создаваемый «эффект снежинки» затрагивает только таблицы измерений, и не применим к таблицам фактов.

• [Править]Использование

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

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

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

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

• факты, связанные с транзакциями (англ. Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата);

• факты, связанные с «моментальными снимками» (англ. Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка;

• факты, связанные с элементами документа (англ. Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);

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

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

Пример таблицы фактов, которая может быть построена на основе базы данных Northwind приведен на рис. 1.

Файл:Olap i2 2a.gif	Файл:Olap i2 2b.gif
Рис. 1

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

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

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