Настройка таблиц Dim и Fact для хранилища данных

Question

Мне поручено создать хранилище данных для клиента.Используемые таблицы на самом деле не соответствуют традиционным примерам (продукт/заказы), поэтому для начала мне нужна помощь.Клиент по сути является процессинговым центром по делам (аналогично судебному делу).Каждый день новые случаи вводятся в БД в таблицу «случаи».Каждый столбец содержит некоторую информацию, связанную с делом.По мере обработки обращения дополнительные таблицы типа «один-ко-многим» заполняются событиями, связанными с обращением.Таких таблиц событий довольно много, примерами таблиц могут быть:(кейс-открыт, кейс-отдел1, кейс-отдел2, кейс-отдел3 и т. д.).Каждая из этих таблиц имеет идентификатор случая, который соответствует таблице «случаи».Также задействовано несколько справочных таблиц.

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

Возможно, я прошу здесь слишком многого, но я ищу указания о том, как мне настроить таблицы Dim и Fact, или любые другие предложения, которые могут у вас возникнуть.

Answer 1

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

В любом случае вам нужно решить, подходит ли даже размерная модель. Вполне возможно обработать базу данных 3NF «хранилище корпоративных данных» с помощью различных индексов или сводок, или чего угодно.

Не видя вашей текущей схемы, ДЕЙСТВИТЕЛЬНО трудно сказать. Похоже, у вас получится несколько звездных моделей с некоторыми согласованными измерениями, связывающими их вместе. Таким образом, у вас может быть размер кейса как одно из ваших соответствующих измерений. Факты из каждой другой таблицы будут в действительности таблицами, которые связаны как с согласованным измерением, так и с любыми другими измерениями, соответствующими фактам, так, например, если есть идентификатор сотрудника в открытом случае, это будет ссылаться на измерение, согласованное с сотрудником. из таблицы фактов. Это согласованное измерение может быть связано несколько раз из нескольких ваших вспомогательных таблиц фактов.

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

Answer 2

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

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

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

Если вы хотите сравнить определенные этапы в ходе жизненного цикла, у вас будет таблица с типом случая, типом события 1, типом события 2, временем тестирования.

Немного помассируя, вы можете использовать инструментарий интеллектуального анализа данных или даже простой регрессионный анализ, чтобы определить корреляции между атрибутами случая и временем события-события (YMMV).

Answer 3

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

Answer 4

Вот что у меня получилось по сути.Спасибо, NXC

Факт События

Eventid Timekey Caseid

Тусклые события

EventId EventDesc

Тусклое время

ТаймКей

Тусклые регионы

RegionId RegionDesc

Случаи

Казеид регионал

Answer 5

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

Глядя на то, что я вижу до сих пор, я думаю, что центральный объект в этой базе данных должен иметь место. Попытка вставить событие в середине не кажется правильной. Попробуйте посмотреть на это по-другому. Возможно, case, events и case case для начала.