Связь «многие ко многим» и службы анализа MS SQL Server Этот пост я хочу посвятить такой, как оказалось, простой проблеме, как обработка связей «многие ко многим» с OLAP-кубом с помощью MS SQL Server Analysis Services. Сначала немного о том, как я к этому подошел.
Начальство сказало, что было бы неплохо развернуть какую-то аналитику по существующей базе.
После небольшого поиска в Google выяснилось, что технология OLAP подойдет идеально.
А поскольку на сервере компании развернут MS SQL Server, то компонент Analysis Services там подходит еще больше.
Счастливо потирая руки, я схватил учебник Microsoft, прилагаемый к SQL Server. И уже через два дня я был уверен, что со всем справлюсь.
Но не тут-то было.
В существующей базе данных большая часть связей между таблицами оказалась связью «многие-ко-многим», что поначалу не предвещало никаких осложнений.
Но на практике оказывается, что без дополнительных весьма осмысленных взмахов руками не обойтись, потому что в противном случае куб просто выдает неверную информацию.
Найти информацию по этой теме в Рунете оказалось непростой задачей.
Либо это все воспринимают как должное, либо лыжи не работают. Тем не менее, я нашел очень классное большое руководство на английском языке по этой теме.
Собственно, тем, кто прекрасно понимает английский или хочет очень хорошо разобраться в теме, предлагается не читать дальше, а перейти по ссылке: http://www.sqlbi.com/articles/many2many/ Те, у кого, как и я ранее, нет времени читать учебники английского языка, читайте дальше.
Пост не представляет собой перевод данного руководства: скорее некое обобщение его первых примеров + некоторые основы из упомянутого учебника Microsoft. На самом деле это проблема.
Если читатель прочитал этот пост: http://habrahabr.ru/post/67272/ , то он знает, что стандартными схемами для Олапа являются схемы «Звезда» и «Снежинка».
Что, если мы окружены связями «многие ко многим»? Самый простой вариант: уйти от связей «многие ко многим» с помощью представлений — это положительно скажется на скорости обработки запросов.
Не можешь уйти? Давайте разберемся.
Постановка задачи.
Интернет-магазин.
MS SQL Server, он содержит базу данных с пресловутыми M2M-соединениями, которая выглядит так: К ней привязаны таблица идентификаторов покупок, таблица категорий (еда, спорт, прочее) и таблица аккаунтов.
Усложним задачу: пусть теперь одним аккаунтом могут пользоваться сразу несколько человек (например, муж и жена совершают покупку на дом), соответственно, через М2М подключена таблица персон.
А чтобы совсем не сладко: пусть таблица категорий персон будет привязана к таблице персон через М2М.
И нас интересует: какие категории людей какие покупки совершают чаще и когда они это делают. 
Пример надуманный, но проблема все же видна: как связать будущее измерение с таблицей фактов через целых два M2M-соединения? Все просто: мы сообщим SSAS, где искать.
Выполнив предварительные действия по созданию измерений (Виды, Даты, Категории, Персоны, Счета) (см.
http://habrahabr.ru/post/67272/ ), мы пытаемся создать куб, используя показатель «Продажи» (количество строк).
По умолчанию Visual Studio предложит нам только три меры (Типы, Счета, Даты) — потому что только они напрямую связаны с нашей мерой.
Создав куб, складываем руками оставшиеся две меры.
Плюс создадим внутри куба еще две вспомогательные меры, которые будут отвечать за обработку M2M-соединения: Bridge Accounts Persons и Bridge Persons Category (обе — количество строк, в которых таблицы чисты).
Таким образом, у нас будет следующая картина: 
Мы видим множество серых прямоугольников и тот факт, что Visual Studio уже обработала одно отношение M2M: между вспомогательной мерой «Категории мостовых лиц» и измерением «Счета».
И это хорошо, но недостаточно.
Если мы прямо сейчас попросим наш куб что-нибудь выплюнуть, мы не получим ничего хорошего.
Нет, измерения «Даты» и «Счета» будут работать правильно, но, к сожалению, с «Лицами» и «Категориями».
Чтобы исправить это недоразумение, мы сообщим SSAS, где искать информацию для обработки наших запросов.
Для этого заполните эти серые поля на вкладке «Использование измерений» следующим образом: нажмите на серые поля -> эллипсы -> тип связи, выберите «Многие ко многим» -> выберите промежуточную группу мер, как написано на картинке: 
Вуаля! Все работает. Вы можете увидеть это на следующей картинке: 
В чем волшебство? Мы рассказали SSAS, где и как искать информацию о взаимоотношениях.
Обратите внимание: невозможно, например, правильно заполнить пересечение измерения «Категории» и показателя «Продажи» до тех пор, пока вы правильно не заполните измерение «Категории» и показатель «Лица промежуточного счета».
В опциях отображаются только категории Bridge Persons, потому что.
Visual Studio просто не знает другого способа.
Но вспомогательные меры – это тоже меры.
И пути для них должны быть указаны так же, как и для обычных (целевых) мер.
По мере заполнения таблицы Visual Studio получает больше знаний и предлагает больше возможностей.
Теперь сформулируем мнемоническое правило заполнения таблицы связей: «Между целевой мерой и целевым измерением выберите таблицу мер, наиболее близкую к целевой мере».
Таким образом, получилось, что для измерений «Тип» и «Дата» во втором столбце будет полноценный интересный показатель «Продажи», а в третьем — вспомогательный показатель «Bridge Accounts Persons».
То же самое справедливо и для измерения «Категории».
Должен ли я всегда полностью заполнять таблицу ссылок? Нет. Не нужно обрабатывать неинтересную информацию.
M2M-подключения отрицательно влияют на производительность куба, поэтому по возможности лучше от них избавиться.
Вот и все для этого.
Надеюсь, у меня был полезный пост. Как минимум могу сказать, что в свое время я искал именно что-то подобное, но так и не нашел.
Могу выслать вам исходный код базы данных и куба из примера.
Теги: #olap #olap Cubes #ms sql-сервер #ssas #many-to-many #sql #Microsoft SQL Server
-
Научимся Надежно Управлять Kubernetes
19 Oct, 24 -
Полномасштабная Разработка Проекта
19 Oct, 24 -
Как Sfp, Sfp+ И Xfp Делают Нашу Жизнь Проще
19 Oct, 24 -
Основатель Digg Выступает Против Тегов
19 Oct, 24 -
Июльский Конкурс От Asus
19 Oct, 24
