Розмірність (сховище даних)

Розмірність (англ. dimension table) — це структура сховища даних з класифікацією фактів та мірок, яка дозволяє користувачам виконувати бізнес-завдання. Часто використовуються такі розмірності як люди, вироби, місце та час.[1][2]

У сховищі даних розмірність надає структуровану інформацію маркування на противагу невпорядкованим числовим вимірюванням. Розмірність є набором даних, який складається з окремих елементів даних, які не перекриваються. Є три основні функції розмірності: забезпечення фільтрації, групування та маркування.

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

Елемент даних розмірності схожий на категорійну змінну в статистиці.

Зазвичай розмірність в сховищах даних організовані всередині однієї або декількох ієрархічних структур. Наприклад, «календарна дата» — загальна розмірність, що складається з дня, місяця та року, може мати декілька можливих ієрархій:

  • «Дні (згруповані в) місяці (які згруповані в) роки»,
  • «Дні (згруповані в) тижні (які згруповані в) роки»
  • «Дні (згруповані в) місяці (які згруповані в) квартали (які згруповані в) роки»
  • та численні комбінації.

Підсумовуючи, можна сказати, що атрибути подій з таблиці фактів сховища даних являють собою текстові або інші описи, логічно об'єднанні в єдине ціле. Наприклад, ім'я покупця може бути атрибутом в таблиці розмірностей покупців, а ім'я товару — в таблиці розмірностей товарів. В той час як сума транзакції є величиною адитивною і її значення повинно зберігатися в таблиці фактів.

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

Типи

Узгоджена розмірність

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

Розмірності узгоджуються, коли вони є абсолютно однаковими (включаючи ключі), або один є в точності підмножиною іншого. Найбільш важливим є те, що заголовки рядків, створені у двох різних наборах відповідей з однієї й тієї ж узгодженої розмірності (або розмірностей), повинні точно відповідати одне одному.

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

Небажана розмірність

Небажана розмірність слугує для зручного групування прапорців (англ. flags) і індикаторів що, як правило рідко використовуються. Створюючи абстрактну розмірність, ці прапорці та індикатори видаляються з таблиці фактів, розміщуючи їх у зручній таблиці розмірностей.[5] Небажана розмірність — це таблиця така розмірності, що складається з атрибутів, які не належать до таблиці фактів або до будь-якої з існуючих таблиць розмірностей. Характер цих атрибутів зазвичай є текстовими або іншими прапорами, наприклад коментарі, які не є загальними, або просто звичайні так/ні (англ. yes / no) чи правда/брехня (англ. true / false) індикатори. Ці типи атрибутів, як правило, залишаються, коли всі очевидні розмірності в бізнес-процесі були ідентифіковані, і тому проектувальник зіштовхується з проблемою того, де розмістити ці атрибути, які не належать до інших розмірностей.

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

Рішення цього завдання полягає в тому, щоб ідентифікувати всі атрибути, а потім помістити їх в один або кілька небажаних розмірностей. Одна небажана розмірність може містити декілька індикаторів так/ні (англ. yes / no) чи правда/брехня (англ. true / false), які не мають кореляції одне з одним, тому було б зручно конвертувати індикатори в більш описовий атрибут. Прикладом може бути індикатор того, чи прийшов пакет: замість того, щоб вказувати це як «так» або «ні», він буде перетворений у «надійшовший» або «в очікувані» у небажаній розмірності. Проектувальник може вирішити побудувати таблицю розмірностей, що буде містити всі індикатори, що відбуваються з будь-яким іншим індикатором, щоб покрити всі комбінації. Це встановлює фіксований розмір для самої таблиці, яка буде містити 2х рядків, де x — кількість індикаторів. Це рішення є прийнятним у ситуаціях, коли проектувальник очікує отримати багато різних комбінацій і де можливо, обмежити комбінації до прийнятного рівня. У ситуації, коли кількість індикаторів є великою, створюючи, таким чином, дуже велику таблицю або де проектувальник очікує отримати тільки кілька можливих комбінацій, більш доцільно будувати кожен рядок у розмірності небажаних об'єктів, оскільки можливо зустрінуться й нові комбінації. Щоб обмежити розмір таблиць, декілька небажаних розмірностей можуть бути придатними в інших ситуаціях залежно від співвідношення різних показників.

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

Вироджена розмірність

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

Розмірність рольових ігор

Розмірності часто переробляються для декількох додатків в межах однієї бази даних. Наприклад, розмірність «Дата» може бути використаний для «Дата продажу», а також «Дата доставлення» або «Дата прокату». Це часто називають «рольовою розмірністю».

Використання термінів подання ISO

При посиланні на дані з реєстру метаданих, таких як ISO/IEC 11179, терміни подання, такі як «Індикатор» (булеве значення правда/брехня (англ. true / false)), «Код» (набір перерахованих значень, що не перетинаються) зазвичай використовуються як розмірності. Наприклад, використовуючи національну модель обміну інформацією (NIEM), ім'я елемента даних буде «Person Gender Code», а перераховані значення можуть бути «чоловік», «жінка» і «невідомо».

Таблиця розмірностей

У сховищах даних таблиця розмірностей є однією з набору таблиць-супутників для таблиці фактів.

Таблиця фактів містить ділові факти (або мірки), і зовнішні ключі, які посилаються на потенційні ключі (зазвичай первинні ключі) в таблицях розмірностей.

На відміну від таблиць фактів, таблиці розмірностей містять описові атрибути (або поля), які зазвичай є текстовими полями (або дискретними числами, які поводяться як текст). Ці атрибути призначені для виконання двох важливих цілей: обмеження запитів і / або фільтрації, а також маркування набору результатів запиту.

Атрибути розмірності мають бути:

  • Мовними (етикетки, що складаються з повних слів)
  • Описовими
  • Закінченими (без відсутніх значень)
  • Дискретно оцінюваними (має лише одне значення таблиці в рядку розмірностей)
  • Забезпечені якістю (без правопису або неможливих значень)

Рядки таблиці розмірності однозначно ідентифікуються одним ключовим полем. Рекомендується, щоб поле ключа було простим цілим числом, оскільки значення ключа не має сенсу, крім використання для об'єднання полів між таблицями фактів та розмірностей. Таблиці розмірностей часто використовують первинні ключі, які також є сурогатними ключами. Сурогатні ключі як правило генеруються автоматично (наприклад, стовпець ідентифікаторів Sybase або SQL Server, PostgreSQL або Informix serial, послідовність в Oracle або стовпець, визначений за допомогою AUTO_INCREMENT в MySQL).

Використання ключів сурогатних розмірностей має ряд переваг, включаючи:

  • Продуктивність. Виконання приєднання набагато ефективніша за допомогою одного поля (сурогатного ключа)
  • Буферизація з використанням оперативних методів управління. Це запобігає ситуаціям, коли видалені рядки даних можуть з'явитися знову, коли їхні природні ключі повторно використовуються або перепризначені після тривалого періоду коли вони не були використані
  • Картування для інтеграції різнорідних джерел
  • Обробка невідомих або непридатних з'єднань
  • Відстеження змін у значеннях атрибутів розмірностей

Хоча використання сурогатного ключа покладається на систему ETL, можна покращити обробку комунікаційної лінії, а інструменти ETL мають вбудовану обробку сурогатних ключів.

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

Відповідні розмірності дуже важливі для корпоративного характеру систем DW / BI, оскільки вони сприяють:

  • Послідовності. Кожна таблиця фактів фільтрується послідовно, так що відповіді на запит позначаються послідовно.
  • Інтеграції. Запити можуть обробляти різні таблиці факторів процесу окремо для кожної окремої таблиці фактів, а потім приєднувати результати до атрибутів загальної розмірності.
  • Зменшення часу розробки магазину. Загальні розмірності доступні без їх відтворення.

З часом атрибути заданого рядка в таблиці розмірностей можуть змінюватися. Наприклад, адреса доставлення для компанії може змінюватися. Кімбол посилається на це явище як на Повільно змінювані розмірності. Стратегії вирішення такого роду змін поділяються на три категорії:

  • Перший тип. Просто перезапишіть старі значення.
  • Другий тип. Додайте новий рядок, що містить нове значення, і розрізняйте рядки за допомогою методів Tuple-versioning.
  • Третій тип. Додайте новий атрибут до наявного рядка.

Загальні моделі
Дата і час[8]

Оскільки багато таблиць фактів у сховищі даних є часовими рядами спостережень, часто потрібні один або більше розмірностей дати. Однією з причин для того, щоб мати розмірність дати є розміщення знань календаря в сховищі даних замість жорсткого кодування в додатку. Попри те, що проста дата або дата-час SQL є корисною для надання точної інформації про час запису факту, вона не може надати інформацію про свята, фіскальні періоди, тощо. Мітку дати / часу SQL все ще може бути корисно зберігати у таблиці фактів, оскільки це дозволяє проводити точні розрахунки.

Наявність як дати, так і часу дня в одній і тій же розмірності, може призвести до величезного об'єму з мільйонами рядків. Якщо потрібна велика кількість деталей, то варто розбити дату і час на дві або більше окремих розмірностей. Розмірність часу з кількома секундами у день буде мати лише 86400 рядків. Степінь деталізації для розмірностей дати / часу можна вибрати в залежності від потреб. Наприклад, розмірності дати можуть мати точність до року, кварталу, місяця або дня, а розмірності часу можуть мати точність до годин, хвилин або секунд.

Як правило, розмірність часу має бути створена тільки тоді, коли потрібні ієрархічні угруповання або, якщо існують змістовні текстові описи для періодів часу протягом дня (наприклад, «вечірня затримка» або «перша зміна»).

Якщо рядки в таблиці фактів надходять з декількох різних часових поясів, може бути корисно зберігати дату і час як за місцевим часом, так і за стандартним часом (наприклад, Гринвіч). Це можна зробити, маючи дві розмірності для кожного необхідного вимірювання дати / часу — один для місцевого часу, а один для стандартного часу. Збереження дати / часу як у місцевому, так і в стандартному часі дозволить проаналізувати, коли факти створюються в локальній ситуації і в глобальній ситуації. Вибраний стандартний час може бути загальним стандартним часом (наприклад, UTC), це може бути місцевий час штаб-квартири підприємства або будь-який інший часовий пояс, який доречно було б використовувати в певній ситуації.

Див. також

Література
  • Барсегян А., Технологии анализа данных: Data Mining, Text Mining, Visual Mining, OLAP. 2 изд.
  • Душан Петкович, «Microsoft SQL Server 2012. Руководство для начинающих», с. 597


Посилання
  1. «Oracle Data Warehousing Guide», Oracle Corporation, retrieved 9 June 2014
  2. Definition: Dimension" Search Data Management, TechTarget, retrieved 9 June 2014
  3. slice and dice. www.urbandictionary.com.
  4. Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Second Edition, Wiley Computer Publishing, 2002. ISBN 0471-20024-7, Pages 82-87, 394
  5. Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Second Edition, Wiley Computer Publishing, 2002. ISBN 0471-20024-7, Pages 202, 405
  6. Kimball, Ralph, et al. (2008): The Data Warehouse Lifecycle Toolkit, Second Edition, Wiley Publishing Inc., Indianapolis, IN. Pages 263—265
  7. Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Second Edition, Wiley Computer Publishing, 2002. ISBN 0471-20024-7, Pages 50, 398
  8. Ralph Kimball, The Data Warehouse Toolkit, Second Edition, Wiley Publishing, Inc., 2008. ISBN 978-0-470-14977-5, Pages 253—256
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.