Таблиця фактів

Якщо бізнес-процес — це продажі, то відповідна таблиця фактів буде, як правило, містити стовпчики, що представляють як сирі факти, так і агреговані у рядках. Наприклад:

• $12,000, складають «продажі Нью-Йорксього магазину за 15 січня 2005 року».
• $34,000, складають «продажі магазину у Лос-Анджелесі за 15 січня 2005 року».
• $22,000, складають «продажі Нью-Йорксього магазину за 16 січня 2005 року».
• $21,000, складають «середньодобові продажі магазину у Лос-Анджелесі за січень 2005 року».
• $65,000, складають «середньодобові продажі магазину у Лос-Анджелесі за лютий 2005 року».
• $33,000, складають «середньодобові продажі магазину у Лос-Анджелесі за 2005 рік загалом».

«Середньодобові продажі» — це вимірювання, яке зберігається у таблиці фактів. Таблиця фактів також містить зовнішній ключ із таблицями розмірностей, де зберігаються часовий ряд (наприклад, дата) та розмірності іншого параметру (наприклад, місце розташування магазину, продавець, товар).

Усі зовнішні ключі між таблицею фактів та таблицею розмірностей повинні бути сурогатними ключами, а не похідними від операційних даних.

• Аддитивні — вимірювання, які можуть бути додані для будь-якої розмірності.
• Неаддитивні — вимірювання, які не можуть бути додані для жодної розмірності.
• Напіваддитивні — вимірювання, які можуть бути додані для певних розмірностей.

Таблиця фактів може містити у собі або деталі на рівні фактів, або факти, які були об'єднані (таблиці фактів, що містять сукупні факти, часто називаються підсумковими таблицями).

Особливу увагу слід приділяти при обробці пропорцій та відсотків. Одне добре правило при розробці[1] полягає в тому, щоб ніколи не зберігати відсотки або пропорції у таблицях фактів, а лише обчислювати їх у інструменті доступу до даних. Таким чином, у таблицях фактів зберігається лише чисельник і знаменник, які потім можуть бути агрегованими, а збережені агреговані значення можуть потім використовуватися для обчислення пропорцій або відсотків вже в інструменті доступу до даних.

У реальному світі можна мати таблицю фактів, яка не містить жодних розмірностей чи фактів. Ці таблиці називаються «таблицями фактів без фактів» або «таблицею з'єднань».

«Таблиці фактів без фактів» можуть, наприклад, використовуватися для моделювання відносин «багато-до-багатьох» або створення відміток часу подій.[1]

Існує чотири основних типів вимірювальних подій, які описують всі таблиці фактів.[2]

Транзакційний

Таблиця транзакцій є основним та фундаментальним типом. Ступінь деталізації таблиці фактів транзакцій, як правило, визначається як «один рядок на транзакцію», наприклад, це може бути кожен рядок у чеку. Як правило, таблиця фактів транзакції містить дані найбільш деталізованого рівня, що спричиняє велику кількість розмірностей пов'язаних з ними.

Періодичні знімки

Періодичний знімок, як зрозуміло з назви, забезпечує знімок часу, де це може бути проміжок часу, наприклад, підсумок роботи продавця за попередній місяць. Періодичний знімок таблиці залежить від таблиці транзакцій, оскільки для його створення необхідна детальна інформація, яка зберігається у таблиці фактів, і дозволяє отримати потрібний результат.

Накопичення знімків

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

Хронологічні знімки

Застосування теорії хронологічних баз даних та методів моделювання таблиць фактів хронологічних знімків[3] дозволяє мати еквівалент повсякденних знімків уникаючи створення реальних щоденних знімків. Такий підхід запроваджує концепцію інтервалів часу в таблиці фактів, що дозволяє заощадити багато місця, оптимізувати швидкодію та дозволяє кінцевому користувачу мати логічний еквівалент «знімку часу», який його цікавить.

• Визначити бізнес-процес, який аналізується (наприклад, продажі).
• Визначити вимірювання фактів (продажі у доларах), ставлячи питання типу «Яка кількість X важлива для бізнес-процесу?», замінивши X на різні варіанти, що мають сенс у контексті бізнесу.
• Визначити міри фактів (міра товару, просторова розмірність, часовий вимір, організаційна розмірність), за допомогою питань, які мають сенс у контексті бізнесу, наприклад, «Аналізуємо по X», де X замінюється в залежності від предмета, який необхідно перевірити.
• Перерахувати стовпці, що описують кожен параметр (назва регіону, назва філії, назва бізнес-підрозділу).
• Визначити найнижчий ступінь деталізації (гранулярність) звіту в таблиці фактів (наприклад, продажів у доларах).

Альтернативний підхід до розробки, описаний Кімбаллом:[1] 1) Вибрати бізнес-процес; 2) Визначити ступінь деталізації; 3) Визначити розмірності; 4) Визначити факти.