Таблица фактов
Таблица фактов — является основной таблицей хранилища данных[1][2][3][4]. Как правило, она содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. Обычно говорят о четырёх наиболее часто встречающихся типах фактов. К ним относятся:
- факты, связанные с транзакциями (англ. Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счёта с помощью банкомата);
- факты, связанные с «моментальными снимками» (англ. Snapshot facts). Основаны на состоянии объекта (например, банковского счёта) в определённые моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объём продаж за день или дневная выручка;
- факты, связанные с элементами документа (англ. Line-item facts). Основаны на том или ином документе (например, счёте за товар или услугу) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);
- факты, связанные с событиями или состоянием объекта (англ. Event or state facts). Представляют возникновение события без подробностей о нём (например, просто факт продажи или факт отсутствия таковой без иных подробностей).
Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа «дата/время» в целочисленном формате — ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно — лучше поместить их в меньшие по объёму таблицы измерений. При этом как ключевые, так и некоторые неключевые поля должны соответствовать будущим измерениям OLAP-куба. Помимо этого, таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут получены агрегатные данные.
Для многомерного анализа пригодны таблицы фактов, содержащие как можно более подробные данные (то есть соответствующие членам нижних уровней иерархии соответствующих измерений). В данном случае предпочтительнее взять за основу факты продажи товаров отдельным заказчикам, а не суммы продаж для разных стран — последние все равно будут вычислены OLAP-средством, в случае использования такового. Исключение можно сделать, пожалуй, только для клиентских OLAP-средств, поскольку в силу ряда ограничений они не могут манипулировать большими объёмами данных.
В таблице фактов нет никаких сведений о том, как группировать записи при вычислении агрегатных данных. Например, в ней есть идентификаторы продуктов или клиентов, но отсутствует информация о том, к какой категории относится данный продукт или в каком городе находится данный клиент. Эти сведения, в дальнейшем используемые для построения иерархий в измерениях куба, содержатся в таблицах измерений. В случае построения отчетов напрямую из хранилища данных, минуя промежуточный шаг создания OLAP-кубов, также могут использоваться так называемые агрегатные таблицы фактов, содержащие крупнозернистую информацию, например суммарные траты покупателя в выбранном магазине за месяц, вместо или в дополнение к детальной таблице фактов с подробной информацией о каждой покупке.
Примечания
- Kimball, Ralph (2008). The Data Warehouse Lifecycle Toolkit, 2. edition. Wiley. ISBN 978-0-470-14977-5.
- orspod. Таблицы фактов и измерений — Azure обозреватель данных (рус.) ?. docs.microsoft.com. Дата обращения: 1 июля 2021.
- Михайлов Михаил Вячеславович, Коломеец Максим Вадимович, Булгаков Михаил Вадимович, Чечулин Андрей Алексеевич. Исследование и определение основных достоинств и недостатков существующих типов хранилищ данных и анализ их применения // Технические науки – от теории к практике. — 2016. — Вып. 11 (59). — С. 22–27. — ISSN 2308-5991.
- Горбань Г. В. Применение b*-деревьев для создания и вычисления OLAP-кубов с использованием комбинаторного алгоритма // Технологический аудит и резервы производства. — 2013. — Т. 5, вып. 4 (13). — С. 10–12. — ISSN 2226-3780.