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

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

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

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

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

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

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

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

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

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

Вот что я по сути придумал. Спасибо NXC

Факты События

EventID TimeKey Идентификатор дела

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

EventID EventDesc

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

TimeKey

Темные регионы

RegionID RegionDesc

Случаи

Идентификатор дела RegionID

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

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

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