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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

Вот то, что я придумал по существу. Thx NXC

Факт События

EventID TimeKey CaseID

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

EventID EventDesc

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

TimeKey

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

RegionID RegionDesc

Случаи

CaseID RegionID