Как можно реализовать отношение «многие ко многим» в хранилище данных?

Доминирующие топологии моделирования хранилищ данных (Star, Snowflake) разработаны с учетом отношений «один ко многим». Читаемость запросов, производительность и структура сильно ухудшаются, когда сталкиваются с отношением «многие ко многим» в этих схемах моделирования.

Каковы некоторые способы реализации отношения «многие ко многим» между измерениями или между таблицей фактов и измерением в хранилище данных и какие компромиссы они создают в отношении необходимой детализации и производительности запросов?

По моему опыту, рекурсивная иерархия является наиболее практичным способом решения этой проблемы. Он предлагает следующие преимущества:

1. Неограниченная глубина.
2. Компактность.
3. Гибкость.
4. Скорость.

В отличие от этого, требуется дополнительная таблица для каждого уровня "-ко-многим" соединениям. Это жестко запрограммировано и трудно поддерживать в отношении обновлений схемы.

Используя отфильтрованные индексы, большая таблица иерархических объединений может работать быстрее, чем выделенные таблицы. Причина в том, что каждое соединение является только «родитель-потомок» по сравнению с «соединением таблицы с таблицей данных». Последний имеет больше индексов для обработки и хранения.

Я пытался решить эту проблему в течение многих лет. В последнее время это то, что я придумал.

Некоторые сценарии для отношений M: M в модели хранилища данных

Большинство OLAP-серверов и систем ROLAP имеют средства для работы со структурами данных M: M, но есть некоторые предостережения, на которые вам следует обратить внимание. Если вы реализуете отношения M: M, вам нужно будет следить за уровнем отчетности и теми инструментами, которые вы хотите поддерживать.

Сценарий 1: измерение M: M на таблицу фактов

Примером этого может быть несколько водителей на моторную политику. Если вы добавляете или удаляете драйвер, транзакция корректировки политики может иметь отношение к списку драйверов, который изменяется вместе с настройкой.

Вариант 1 - M: M таблица моста фактов драйвера. Это будет довольно большой объем данных, так как он содержит драйверы x строки транзакций для данной политики. SSAS может напрямую использовать эту структуру данных, но выполнять запросы через инструмент ROLAP медленнее.

Если ваши отношения M: M основаны на объектах, которые являются специфическими для ряда фактов (например, водители на автомобиле), это также может быть подходящим для инструмента ROLAP, при условии, что ваш инструмент ROLAP поддерживает отношения M: M (например, с использованием контекстов в Business Объекты).

Вариант 2 - фиктивная таблица измерений «комбинаций» Если вы отображаете список общих кодов в таблицу фактов (т. Е. Связанные сущности не свойственны строке фактов), то вы можете использовать другой подход, который сократит объемы данных. Примером сценария этого типа являются коды МКБ во время стационарного посещения. Каждое стационарное посещение будет иметь один или несколько диагнозов ICD и / или процедуры, перечисленные против него. Коды ICD являются глобальными.

В этом случае вы можете составить отдельный список комбинаций кодов для каждого случая. Создайте таблицу измерений с одной строкой для каждой отдельной комбинации и создайте таблицу связей между комбинациями и справочными таблицами для самих кодов ICD.

Таблица фактов может иметь ключ измерения к измерению «комбинации», а строка измерения содержит список ссылок на фактические коды ICD. Большинство инструментов ROLAP могут использовать эту структуру данных. Если ваш инструмент будет работать только с фактическим отношением M: M, то вы можете создать представление, которое имитирует отношение M: M между фактом и справочной таблицей кодирования. Это был бы предпочтительный подход с SSAS.

Преимущества варианта 1: - При соответствующей индексации запросы, основанные на выборе строк таблицы фактов с определенным отношением в таблице M: M, могут быть достаточно эффективными.

• Чуть проще концептуальная модель

Преимущества варианта 2: - Хранение данных более компактно

• Вы можете эмулировать прямое отношение 1: M, представляя комбинации в удобочитаемом формате в виде кода в измерении «комбинации». Это может быть более полезным для инструментов создания отчетов, которые не поддерживают отношения M: M.

Сценарий 2: отношение M: M между измерениями:

Труднее придумать вариант использования, но можно было бы снова предусмотреть что-то из здравоохранения с помощью кодов ICD. В системе анализа затрат посещение в стационаре может стать измерением, и оно будет иметь отношения M: M между посещением (или эпизодом консультанта в NHS-говорить) и кодировками.

В этом случае вы можете установить отношения M: M и, возможно, систематизировать удобочитаемую визуализацию их в базовом измерении. Отношения могут быть сделаны через прямые таблицы связей M: M или через таблицу «комбинаций» мостов, как и раньше. Эта структура данных может быть правильно запрошена через Business Objects или инструменты ROLAP лучшего качества.

Вдобавок ко всему, я не могу видеть, как SSAS может потреблять это, не сводя отношения прямо к таблице фактов, поэтому вам необходимо представить представление о соотношении M: M между кодированием и таблицей фактов. строки для использования SSAS с этими данными.

Я хотел бы точно знать, какое отношение многие ко многим вы имеете в виду в своей модели, как в транзакционной системе, так и в любой модели данных, в которой она находится в настоящее время.

Как правило, отношения «многие ко многим» между измерениями являются фактами об измерениях. Дело в том, что заказчик заказывает в нескольких филиалах, которые обслуживают много клиентов, или что-то в этом роде. Каждый из них является фактом. У него будет дата вступления в силу или что-то в этом роде, но отношения могут быть «без фактов». У самих отношений могут быть и другие аспекты, помимо клиента и филиала. Таким образом, это типичная схема типа «звезда» с (потенциально без фактов) таблицей фактов в центре. Как эта звезда может относиться к звездам других измерений на складе, очевидно, будет зависеть. Каждый раз, когда вы объединяете разные звезды, вы делаете это с помощью бизнес-ключей и должны быть уверены, что не выполняете случайные перекрестные соединения.

Обычно такие таблицы взаимосвязей измерений не сообщаются в той же степени, что и большие таблицы фактов, и когда они это делают, это не всегда так много данных, поэтому они не имеют тенденцию влиять на производительность. В приведенном выше случае вы можете посмотреть на использование клиента / филиала с течением времени, но более точные данные о фактических объемах заказа будут доступны в таблице фактов заказа, которая, вероятно, также будет иметь измерения для клиента, филиала и т. Д. Это не то, что большинство людей считают, что многие ко многим (хотя можно было бы считать, что порядок определяет отношение многие ко многим от клиента к филиалу), поэтому они более типичны для сред хранилищ данных. Вы будете делать числовые агрегаты только для моделей «многие ко многим», если вы свернули сводную информацию до этого уровня отношений - например, клиент, филиал, месяц,

Вот некоторые соответствующие статьи от Кимбалла и других, которые могут применяться для моделирования заданного предлагаемого отношения «многие ко многим». Обратите внимание, что отношение «многие ко многим» является концепцией только в проблемной области / логической модели. В нормализованной модели OLTP он по-прежнему обрабатывается с помощью таблицы ссылок, которая, конечно, от одного к многим в каждом случае. В ненормализованной модели хранилища данных Kimball есть несколько способов сделать это, один из которых в основном рассматривает эту таблицу ссылок как факт в центре звезды. Другой как массив столбцов флагов.

В конечном счете, выбор будет зависеть от того, что именно вы моделируете, как оно меняется и как вы хотите сообщить об этом. Вот где моделирование размеров и хранилище данных в целом резко расходятся с нормализованной моделью. Нормализованная модель концентрируется на логических и теоретических отношениях в данных, которые хранилище данных всегда следит за реалистичными вариантами использования и денормализует их выполнение.

Моделирование альтернативных иерархий с использованием таблицы мостов:

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/

К сожалению, во многих статьях Magazine Kimball Information Week больше нет хороших ссылок ...

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