Гранульованість
Першим кроком у створенні таблиці фактів є визначення рівня деталізації таблиці фактів. Під деталізацією ми розуміємо найнижчий рівень інформації, яка буде зберігатися в таблиці фактів. Це складається з двох кроків:
- Визначте, які виміри будуть включені.
- Визначте, де в ієрархії кожного виміру буде зберігатися інформація.
Визначальними факторами, як правило, є вимоги.
Які розміри включати
Визначення того, які виміри включити, зазвичай є простим процесом, оскільки бізнес-процеси часто чітко диктують, які саме виміри є релевантними.
Наприклад, у світі офлайн-ритейлу вимірами для таблиці фактів продажів зазвичай є час, географія та продукт. Цей список, однак, далеко не повний для всіх офлайн-ритейлерів. Супермаркет з програмою Rewards Card, де покупці надають певну особисту інформацію в обмін на картку винагороди, і супермаркет пропонує нижчі ціни на певні товари покупцям, які пред’являють картку винагороди на касі, також матиме можливість відслідковувати вимір клієнта. Рішення про те, чи буде система зберігання даних включати клієнтський вимір, буде залежати від того, яке рішення буде прийнято.
Який рівень у кожному вимірі включити
Визначення того, в якій частині ієрархії зберігається інформація за кожним виміром, не є точною наукою. Тут головну роль відіграють вимоги користувача (як заявлені, так і, можливо, майбутні).
У наведеному вище прикладі, чи захоче супермаркет проводити аналіз на погодинному рівні? (Тобто, проаналізувати, як певні продукти можуть продаватися в різні години дня). Якщо так, то має сенс використовувати “годину” як найнижчий рівень деталізації у часовому вимірі. Якщо достатньо щоденного аналізу, то найнижчим рівнем деталізації може бути “день”. Оскільки чим нижчий рівень деталізації, тим більший обсяг даних у таблиці фактів, вправа з деталізацією, по суті, полягає у знаходженні золотої середини в компромісі між детальним рівнем аналізу і зберіганням даних.
Зауважте, що іноді користувачі не вказують певних вимог, але, спираючись на знання галузі, команда зі зберігання даних може передбачити, що з’являться певні вимоги, які можуть призвести до необхідності додаткової деталізації. У таких випадках команді зі зберігання даних доцільно розробити таблицю фактів таким чином, щоб до неї була включена інформація нижчого рівня. Це дозволить уникнути можливої необхідності перепроектування таблиці фактів у майбутньому. З іншого боку, спроба передбачити всі майбутні вимоги є неможливою, а отже, марною справою, і команда зі сховища даних повинна боротися з бажанням “скинути найнижчий рівень деталізації у сховище даних”, і включати лише те, що є практично необхідним. Іноді це може бути більше мистецтвом, ніж наукою, і попередній досвід тут стане безцінним.
ОРИГІНАЛ СТАТТІ:Fact Table Granularity
🚀Долучайтесь до нашої спільноти Telegram:
🚀Долучайтесь до нашої спільноти FaceBook:
