#ssas #data-warehouse
#ssas #хранилище данных
Вопрос:
Я работаю с реляционной базой данных SQL Server и пытаюсь перейти к многомерной модели в службах Analysis Services.
Я пытаюсь решить следующую проблему, которая была бы невероятно простой в мире отношений.
У меня есть 3 таблицы — инцидент, инцидент-правонарушитель и инцидент-потеря. В инциденте может не быть ни одного, одного или нескольких инцидентов-нарушителей и инцидентов-потерь:
Как я могу спроектировать свое хранилище данных таким образом, чтобы я мог спросить куб, например: «сколько времени мы потратили на рассмотрение инцидентов, в которых лысый преступник украл печеные бобы?», А также «какова была ценность этих бобов?»?
Прошу прощения, если это звучит просто, но я просматривал веб-страницы и просматривал различные книги, но все же не могу найти реальный пример чего-либо подобного, что кажется мне повседневной ситуацией.
Комментарии:
1. Для меня это выглядит нормально, но я полагаю, что я бы смоделировал IncidentLoss как таблицу фактов, а Incident и IncidentOffender — как измерения.
2. Спасибо — будет ли FactIncidentLoss содержать IncidentLossID , IncidentID и IncidentOffenderID? Это последнее из тех, что вызывает проблему, потому что в инциденте может быть более одного правонарушителя.
3. С учетом этого требования я бы выбрал таблицу сопоставления m: n и тщательно протестировал проблемы с производительностью.
4. Спасибо — это то, что вы бы назвали «таблицей мостов»?
5. Я думаю, что это именно таблица мостов после Кимбалла.
Ответ №1:
В вашем сценарии все три таблицы должны быть загружены в SSAS как в качестве измерений, так и в качестве групп измерений. Тогда измерения Нарушителя инцидента и потерь инцидента могут быть измерениями «многие ко многим» для группы показателей инцидента. На вкладке Использование измерения это будет выглядеть следующим образом.
Комментарии:
1. Большое спасибо за это — на самом деле это решение, на котором я остановился с первым кубом, который я построил, но я никогда не чувствовал себя с ним полностью комфортно. Будет ли «наилучшей практикой» здесь создание 2 кубов (или больше, если необходимо), каждый с одной таблицей фактов с максимально возможной степенью детализации?
2. Нет. Одна таблица фактов на куб определенно не является лучшей практикой. Анализ показателей из разных таблиц фактов в одном отчете дает много возможностей. Это немного не по теме, поскольку в вашем случае две другие таблицы фактов являются просто связующими таблицами для измерений «многие ко многим».
3. Нет проблем @GregGalloway. Я все еще обдумываю ситуацию, но обязательно отмечу это как принятый ответ, как только буду счастлив.
4. Еще один вопрос — меня учили, что лучше всего стремиться к схеме «звезда», но эти таблицы мостов, похоже, нарушают этот шаблон и приводят к появлению снежинки. Это правда? Стоит ли об этом беспокоиться?
5. @Nugsson снежинка была бы, когда внешние ключи таблицы фактов к измерению клиента, которые являются внешними ключами к измерению географии. Здесь это не сценарий. Я рассматриваю это как допустимую модель, поскольку каждый инцидент имеет несколько категорий потерь и несколько нарушителей. Кроме разделения модели на явные таблицы фактов и измерений в SQL, я бы ничего не менял.