Які існують способи впровадження відносин "багато на багато" у сховищі даних?


25

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

Які існують способи втілення взаємозв'язку між величинами або між таблицею фактів та розмірністю в сховищі даних та які компроміси вони можуть спричинити стосовно необхідної деталізації та виконання запитів?


Вам потрібно викласти своє питання чіткіше. Можливо, тому ніхто не відповів на нього з 4-го. Те, що ви заявляєте у відповідь на мою відповідь, не те саме, що ваше первісне запитання.
IamIC

@IanC Відредаговано. Чи краще?
Брайан Балсун-Стентон

ідеально :)
IamIC

Відповіді:


17

На мій досвід, рекурсивна ієрархія є найбільш практичним способом вирішення цього питання. Він пропонує наступні переваги:

  1. Необмежена глибина.
  2. Компактність.
  3. Гнучкість.
  4. Швидкість.

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

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

Я багато років намагаюся вирішити цю проблему. Останнім часом це те, що я придумав.


1
Ви запитали "Які існують способи моделювання цих багатьох-до-багатьох і які наслідки їх продуктивності та деталізації?". Я відповів на моделювання. Не потрібно проводити голосування.
IamIC

4
Вам потрібно надати більше даних про те, що вам потрібно. Я подолав точну проблему, яку ви заявили за допомогою рекурсивної ієрархії. Але, не знаючи чогось про ваші дані та його зв’язки, відповісти дуже важко.
IamIC

2
Так, вони споконвічно не моделюють це. Що було б неправильно, якщо додати ще одну таблицю та об'єднати, досягнувши таким чином багато-до-багатьох? У RDBMS, незалежно від того, як ви структуруєте таблиці, у вас буде 2 приєднання для багатьох-до-багатьох. Немає ярлика. Єдиним можливим винятком є ​​масиви в PostgreSQL або Caché / M.
IamIC

1
(Рекурсивна ієрархія насправді є хорошою ідеєю.) Один із способів вирішення проблеми - попередньо обчислити список можливих множинних відносин у межах виміру, посилаючи його на звичайну таблицю вимірів, а потім приєднавши таблицю фактів до цієї підсумована таблиця розмірів. Ваша відповідь "рекурсивна ієрархія" - це ще одна корисна відповідь дизайну. Мені цікаво, чи було проведено якесь дослідження щодо наслідків для цих різних хакерів?
Брайан Балсун-Стентон

3
@Brian не забудь голоси за корисні відповіді. Це допомагає створити спільноту. Щоб відповісти на ваше запитання, я не стикався з жодними дослідженнями цих хаків, окрім "що швидше: рекурсивний CTE або побудова дерева вручну?". Попередньо заявлене рішення має сенс. Я б поєднав це з індексованим видом, що, звичайно, запевняє, що у вас завжди є правильна попередньо заповнена карта відносин.
IamIC

6

Деякі сценарії відносин M: M у моделі сховища даних

Більшість серверів OLAP та ROLAP мають засоби для вирішення структур M: M зараз, але є деякі застереження щодо цього, на які потрібно звернути увагу. Якщо ви реалізуєте відносини M: M, вам потрібно буде стежити за рівнем звітування та інструментами, які ви хочете підтримувати.

Сценарій 1: Вимір M: M на таблиці фактів

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

Варіант 1 - Таблиця мостів з фактом драйвера M: M У цьому буде досить великий об'єм даних, оскільки він містить драйвери x рядки транзакцій для заданої політики. SSAS може споживати цю структуру даних безпосередньо, але повільніше проводити запит через інструмент ROLAP.

Якщо ваші стосунки M: M засновані на сутностях, специфічних для рядів фактів (наприклад, водіїв на автомобілі), це може бути доречним і для інструмента ROLAP, якщо ваш інструмент ROLAP підтримує зв'язки M: M (наприклад, використовуючи контексти в бізнесі Об'єкти).

Варіант 2 - Таблиця вимірів "комбінації" манекенів Якщо ви зіставляєте список загальних кодів у таблиці фактів (тобто пов'язані об'єкти не властиві рядку фактів), тоді ви можете скористатися іншим підходом, який зменшить обсяги даних. Прикладом такого типу сценаріїв є коди МКБ під час стаціонарного відвідування. Кожен стаціонарний візит матиме один або декілька діагнозів МКБ та / або перерахованих проти нього процедур. Коди ICD є глобальними.

У цьому випадку ви можете скласти чіткий список комбінацій кодів для кожного випадку. Створіть таблицю розмірів з одним рядком для кожної окремої комбінації та створіть таблицю зв’язків між комбінаціями та еталонними таблицями для самих кодів МКБ.

Таблиця фактів може містити розмірний ключ до виміру "комбінації", а рядок розмірів містить список посилань на фактичні коди ICD. Більшість інструментів ROLAP можуть використовувати цю структуру даних. Якщо ваш інструмент буде працювати лише з фактичним співвідношенням M: M, тоді ви можете створити представлення, яке імітує співвідношення M: M між фактом і довідковою таблицею кодування. Це був би кращий підхід із SSAS.

Переваги варіанту 1: - Відповідно індексовані запити, засновані на виборі рядків таблиці фактів з певним співвідношенням через таблицю M: M, можуть бути досить ефективними.

  • Трохи простіша концептуальна модель

Переваги варіанту 2: - Зберігання даних є більш компактним

  • Ви можете імітувати прямий взаємозв'язок 1: M, представляючи комбінації у читаному для людини форматі як код у вимірі "комбінації". Це може бути більш корисним у інструментах звітної інформації, які не підтримують відносини M: M

Сценарій 2: співвідношення M: M між розмірами:

Важко придумати випадок використання, але можна знову передбачити щось із охорони здоров’я з кодами МКБ. У системі аналізу витрат стаціонарний візит може набути розміру, і він матиме взаємозв'язки M: M між візитом (або епізодом консультанта в NHS-говорі) та кодировкою.

У цьому випадку ви можете встановити взаємозв'язки M: M і, можливо, кодифікувати людиночитане відображення їх на базовому вимірі. Взаємозв'язки можна здійснювати через прямі таблиці зв’язків M: M або через з'єднувальну таблицю "комбінацій", як раніше. Цю структуру даних можна правильно запитати за допомогою бізнес-об’єктів або більш якісних інструментів ROLAP.

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


5

Мені хотілося б точно знати, які стосунки «багато-до-багатьох» мають на увазі у вашій моделі, як у трансакційній системі, так і в будь-якій моделі даних, в якій вона знаходиться.

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

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


Гарна відповідь. Тут я вивчаю два випадки. N: M між фактом і виміром, а 1: N: M між фактом, виміром і розмірністю.
Брайан Балсун-Стентон

3
@Brian Ballsun-Stanton Коли ви говорите N: M між фактом і розмірністю, ви маєте на увазі, що даний факт має кілька нерозрізнених і різних розмірів, пов'язаних з кардинальністю, які всі застосовуються, як теги на питання? Отож, одне питання (факт) позначається sql-сервером, сховищем даних, а інше позначається сховищем даних, sql-сервером, бізнес-аналітикою. Я б все-таки вивів це в окрему зірку для факту присвоєння тегів (який має трохи інше зерно, ніж факт питання). Це матиме великі можливості індексації, і ви зможете більш чітко фіксувати зміни розмірів.
Кейд Ру

@Brian Ballsun-Stanton Що стосується 1: N: M, я думаю, це сніжинка, і я схильна цього уникати. Якщо ви хочете визначити інші зірки (або мости) для зв’язків між розмірами, це добре. Пам’ятайте, що розмірний сховище даних не нормалізується, і, перш за все, це практична конструкція, призначена для підтримки конкретних типів операцій, а не для конкретного представлення взаємозв'язків у реальному світі та усунення надмірності.
Кейд Ру

1
@Brian Ballsun-Stanton Погляньте на Форум Кімбола та те, що він називає мостами та перемичками у своїх інструментальних книгах: forum.kimballgroup.com/…
Кейд Ру

@Cade Чи можете ви дати відповідь, описуючи це? :)
Брайан Балсун-Стентон

5

Ось деякі відповідні статті Кімбола та інші, які можуть стосуватися моделювання заданих пропонованих відносин «багато-багато». Зауважте, що взаємозв'язок «багато-багато» - це концепція лише в проблемній області / логічній моделі. У нормалізованій моделі OLTP вона все ще оброблятиметься таблицею посилань, яка, звичайно, є одним до багатьох у кожному напрямку. У ненормованій моделі сховищ даних Кімбала є кілька способів зробити це, один з яких в основному трактує цю таблицю посилань як факт у центрі зірки. Інша - це масив стовпців прапорів.

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

Моделювання альтернативних ієрархій за допомогою мостової таблиці:

http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf

Три варіанти відносин "багато-багато" (пов'язані з числовим розподілом частки - дивіться коментарі щодо цікавих "вперед" і "назад"

http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

На жаль, багато інформаційних статей Кімболу / Тижнів СУБД більше не мають хороших посилань ...


Посилання на статтю "альтернативної ієрархії" порушено. Можливо, ви посилаєтесь на це: kimballgroup.com/html/designtipsPDF/DesignTips2004/…
Endy Tjahjono

Дякуємо за посилання на багато до багатьох статей . Отримав моє "Ага!" мить від неї.
Endy Tjahjono

Друга ланка мертва. Ось нове посилання на ту саму статтю. Однак він дещо здивований і в якийсь момент втратив всю свою графіку. blog.pythian.com/…
posfan12

1

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


1
Як це вирішує питання?
Брайан Балсун-Стентон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.