Я пытаюсь смоделировать бизнес-процесс, который по своей сути измеряется несколькими зернами. Обычно для этого требуется одна таблица фактов на зерно. Поскольку это один бизнес-процесс, и только одно из измерений находится на смешанном уровне (для некоторых записей), я не уверен, что отдельная таблица фактов имеет больше смысла.
Сам процесс основан на измерении исследовательского приложения. Каждое приложение может иметь кандидатов, спонсоров, соавторов и так далее. Кроме того, каждое приложение может управляться организацией. Для отношений M: N я использую таблицы мостов и весовые коэффициенты. Проблема заключается в измерении организации, которое моделирует слегка неровную иерархию как атрибуты фиксированной глубины.
dim_organisation
id, organisation, faculty, school, division, unit
Каждая запись факта имеет одинаковую размерность, за исключением этого измерения. Иногда приложение управляется преподавателями (уровень 2 в иерархии), а иногда школой (уровень 3 в иерархии). Кроме того, сама запись факта будет содержать бизнес-ключ только для одного из этих уровней, например школьный код или код факультета.
Вот как я полагаю, что проблема может и должна быть решена, но я хотел бы получить некоторую оценку этого подхода и / или несколько лучших предложений, если это необходимо:
Исходная таблица dim_organisation заполняется через внешний источник основных данных. Данные всегда сбалансированы, то есть в данных нет пропущенных уровней, но они неровные, поэтому некоторые записи заканчиваются в школе, а другие переходят прямо на уровень единицы:
id, organisation, faculty, school, division, unit
1, org A, faculty A, school A, NULL, NULL
2. org A, faculty B, school B, division B, unit B
3. org A, faculty C, NULL, NULL, NULL
Поскольку эти записи находятся на разных уровнях, я скопировал последний ненулевой уровень, чтобы завершить иерархию:
id, organisation, faculty, school, division, unit
1, org A, faculty A, school A, school A, school A
2. org A, faculty B, school B, division B, unit B
3. org A, faculty C, faculty C, faculty C, faculty C
Это гарантирует, что каждая запись в org_dimension находится на одном уровне и является стандартным подходом для обработки слегка неровных иерархий. Кроме того, каждый из этих уровней имеет свой собственный код, например L456 для подразделения уровня 4 или L521 для подразделения уровня 5. Это бизнес-ключи, полученные из исходной системы.
Поэтому я могу ссылаться только на одну запись в измерении, комбинируя все коды уровней соответственно. В настоящее время я создаю хэш-ключ для этих кодов уровня и сохраняю значение в столбце поиска в измерении.
Предполагая, что этот подход верен, у меня есть записи фактов, поступающие следующим образом:
application_id, organisation_id, applicant_id, ...
1, L456, 99
2, L321, 50
3, L549, 20
Как вы можете видеть, факт применения связан с измерением моей организации на разных уровнях, например Уровень 4, Уровень 3, Уровень 5 и так далее. Из-за изменений, которые я внес в измерение, я считаю, что теперь мне нужно сделать следующее:
1. Lookup the level code from dim_organisation.
2. Return the parent levels.
3. Copy down the level value associated with the fact to level 5.
4. Hash the keys and lookup the corresponding dimensional record.
Например:
1. Lookup L456 to return Division e.g. "Research and Engineering".
2. Return parents: "UoM" -> "Faculty of R&D" -> "School of Engineering".
3. Copy levels: L1 -> L2 -> L3 -> "Research and Engineering" (L4) -> "Research Engineering" (L5).
4. Now we have all the levels (parents + cascaded) to give us a unique record to look up in dim_organisation.
Я хотел бы знать, имеет ли этот подход смысл или есть лучший и более интуитивный способ сделать это? Это немного грязно из-за исходных данных, с которыми я имею дело, но это реальность данных, с которой мне приходится работать.