Вопросы о том, как смоделировать множество полу-логических атрибутов в звездообразной схеме

Как лучше всего смоделировать 37 различных атрибутов / "контрольных точек" (которые могут быть оценены как "пройден / не пройден / неприменимо") в измерении для звездообразной схемы, где каждая строка в таблице фактов представляет собой сообщение, которое оценивается по контрольным точкам в вопрос?

TL;DR:

Я разработал модель звездообразной схемы, в которой каждая строка в таблице фактов представляет собой отдельное сообщение. Эти сообщения проходят серию оцененных «проверок» (например, «Время публикации», «Верная тема электронного письма», «Содержимое XYZ скопировано правильно» и т. Д.), И каждая проверка может быть оценена как «Пройден», «Пропущен», или «Не применимо».

Различные типы сообщений оцениваются по разным наборам проверок (например, один тип сообщения может быть оценен только по трем проверкам, остальные - «неприменимо», тогда как другой тип сообщения оценивается по 19 проверкам). Всего 37 уникальных проверок.

Я создал медленно меняющееся измерение «CommunicationGrading» типа 2, чтобы облегчить составление отчетов о том, какие «проверки» коммуникации получают наиболее низкую оценку. Измерение имеет 37 столбцов, по одному для каждого атрибута, и каждая строка представляет собой перестановку атрибутов и оценку, которую они могут получить (прошел / не прошел / нет данных). Новая строка добавляется, когда становится доступной новая перестановка - заполнение всех возможных перестановок, к сожалению, возвращает миллионы строк, тогда как в этом случае получается ‹100 строк, намного меньше накладных расходов. Я создал 37 отдельных показателей, которые суммируют количество сообщений, не прошедших каждую из 37 отдельных «проверок».

Я могу быстро построить древовидную карту в PBI, перетащить туда 37 показателей, увидеть общее количество сообщений, которые пропустили каждую "проверку", и определить, что X # сообщений пропустили контрольную точку Y в этом месяце. Проблема возникает, когда я хочу использовать визуал в качестве среза (например, выбирая галочку / плитку на древовидной карте, чтобы увидеть, какие отдельные сообщения пропустили эту проверку в таблице под древовидной картой) или определяя верхние N «проверок» с учетом среза данных.

Насколько я могу судить, проблема в том, что я использую 37 различных атрибутов и мер, а не один атрибут и одну меру (где я мог бы перетащить единственную меру в Значения, а единственный атрибут / столбец, содержащий все проверки, в поле Группа в поле «Группа»). Визуальная карта дерева). Проблема в том, что я не понимаю, как лучше всего смоделировать это измерение / измерение. Будет ли это включать сокращение размера до двух столбцов, один для проверок, а другой для возможных оценок проверок, а затем создание таблицы мостов для обработки отношения M: M? Другие идеи?


person Ryan H    schedule 20.04.2017    source источник


Ответы (1)


Ваше измерение (реализованное как измерение мусора - что-то для Google) - это один из способов сделать это, хотя, если идти по этому пути, я бы разбил его на несколько измерений связанных контрольных точек, чтобы значительно уменьшить перестановки в каждой. Также неясно, почему это должен быть Тип 2 - есть ли история этого измерения, которую вам нужно отслеживать?

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

person Rich    schedule 21.04.2017
comment
Спасибо за ответ Rich! Что касается SCD типа 2, я имел в виду, что добавляю строки по мере необходимости, а не заполняю измерение всеми возможными перестановками. Я все еще немного новичок во всей терминологии, поэтому приношу свои извинения за путаницу! Если я правильно вас понял, вы предлагаете снизить зернистость таблицы фактов связи с нового факта для каждого сообщения до нового факта для каждой контрольной точки для каждого сообщения, верно? Я не думал об этом раньше, но думаю, что это должно сработать. Спасибо! - person Ryan H; 23.04.2017
comment
Ах да, SCD 2-го типа - это метод отслеживания истории, а не метод «строки по мере поступления». Не беспокойтесь, терминология не так важна, важны идеи. Да, я предлагал более низкую / более подробную зернистость для каждого результата для каждой контрольной точки в сообщении. Возможно, это не идеально, но одно дело попробовать. - person Rich; 23.04.2017