Я пытаюсь добавить таблицы фактов без фактов и/или таблицы размера мусора в хранилище данных в стиле Кимбалла, но я чтобы понять, как сообщать из таких таблиц, как только они добавляются в кубы и когда кубы запрашиваются из Excel, например (сводные таблицы).Отчеты из фактов без фактов и/или параметров мусора - плоская отчетность, без агрегатов - Kimball
Вот сценарий:
Компания услуги отеля предлагает ипотечные услуги. Когда потенциальный клиент заинтересован в получении ипотечного кредита, открывается Дело, и различные процессы происходят до того, как клиенту предложена закладная (и другие потенциальные продукты).
(для каждого конкретного случая, может быть несколько бизнес-процессов, которые моделируются с помощью отдельных, транзакционных таблиц фактов (содержащих аддитивных мер), но мы не будем сосредотачиваться на тех, здесь, поскольку они легко моделировать)
То, с чем я борюсь, - это моделирование самого процесса Case (который является зонтичным термином для всего, что происходит, с деловой точки зрения, когда дело продвигается ипотечным брокером). Случаи содержат различные флаги (и текстовые поля), которые устанавливаются пользователем в системе OLTP. Пользователи хотят иметь возможность сообщать о случаях и перечислять значения для всех этих флагов, текстовых полей и т. Д. Без каких-либо мер/агрегаций как таковых. Так что, если я использую факт менее таблицу фактов и измерение нежелательной для флагов, мы бы некоторые, как это:
DimDate
DateKey Date Year Month etc.
20150101 01/01/2015 2015 1
20150102 02/01/2015 2015 1
20150103 03/01/2015 2015 1
etc.
DimCustomer
CustomerKey CustomerName
1 J Smith
2 B Edwards
3 A Davies
etc.
DimCaseIndicator
IndicatorKey HasWillFlag HasHomeInsuranceFlag
1 True True
2 True False
3 False True
etc.
FactCase
CaseOpenedDateKey CaseSubmittedDateKey IdCase(BusinessKey) CustomerKey IndicatorKey
20150101 20150102 ABC1234 1 2
20150101 20150101 ABC1235 2 3
Теперь, чтобы отобразить сплюснутый отчет (1 строка на случай) мы могли бы выполнить следующий SQL против приведенных выше таблиц непосредственно в хранилище данных следующим образом:
SELECT FactCase.IdCase,
DimCustomer.CustomerName,
DimIndicator.HasWillFlag,
DimIndicator.HasHomeInsuranceFlag
etc.
FROM FactCase
JOIN DimCustomer on FactCase.CustomerKey = DimCustomer.CustomerKey
JOIN DimIndicator ON FactCase.IndicatorKey = DimIndicator.IndicatorKey
etc.
Это дало бы нам:
IdCase CustomerName HasWillFlag HasHomeInsuranceFlag
ABC1234 J Smith True False
ABC1235 B Edwards False True
Однако, как бы мы достигли того же результата, если бы приведенные выше таблицы были включены в куб, и если бы мы использовали Excel для запроса куба? Когда я пытаюсь это сделать, сводная таблица в Excel хочет объединить (и это правильно!), Но я хочу, чтобы это был плоский отчет, как указано выше.
Проще говоря: не используйте кубы для транзакционной отчетности. Лучшее, что вы можете сделать, это положить фиктивную меру и нуль подавить ее, чтобы отображать только строки, которые вы хотите, но это классическая ошибка. Почему вы считаете, что вам нужно использовать куб для этого? –
Спасибо за ваш комментарий.Причина, по которой я чувствовал, что мне нужно использовать куб, заключается в том, что если мы хотим, чтобы вся отчетность была сделана из хранилища данных (хранилище данных в стиле Кимбалла, чтобы было понятно), и пользователи почти все сообщения из кубов, построенных поверх данных Data Склад, тогда как бы вы реализовали отчетность, подобную приведенной выше? Будут ли пользователи переходить на агрегаты в кубы и для оперативной (транзакционной) отчетности для SSRS, например (где кто-то мог бы написать SQL, как тот, который был выше, для создания плоских отчетов)? – RobW
В идеале это прозрачно. У вас есть один отчет под названием «Статусы случаев» или что-то, что является реляционным отчетом. Отчеты сводного типа выводятся из других отчетов, которые имеют доступ к кубу. Пользователь не знает разницы, если их точкой доступа является отчет. Если вы хотите, чтобы интерактивные кубы анализа были великолепны, но вы описываете фактический отчет здесь –