Деякі сценарії відносин 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 з цими даними.