Я изо всех сил пытаюсь понять, как лучше всего смоделировать конкретный сценарий для хранилища данных.
У меня есть измерение "Личность" и измерение "Аренда". Человек может иметь 0, 1 или (редко) несколько арендованных помещений одновременно, и часто со временем будет иметь смену арендованных помещений. С арендой может быть связано одно или несколько человек. Люди, связанные с арендой, могут меняться с течением времени, и аренда обычно длится много лет.
Один из вариантов - добавить ссылку на аренду, даты начала и окончания в измерение «Персонал» в виде столбцов SCD типа 2. Это работало бы хорошо, если бы я игнорировал возможность одновременного использования нескольких объектов для одного человека. Однако у меня есть другие области хранилища данных, где я сталкиваюсь с аналогичной проблемой дизайна, и игнорирование множественных взаимосвязей невозможно.
Другой вариант - смоделировать взаимосвязь как накопительную таблицу фактов моментального снимка. Я не уверен, насколько хорошо это будет работать на практике, поскольку я мог бы связать его только с одной версией Person и Tenancy (оба из которых будут иметь столбцы SCD типа 2), и это, казалось бы, сделало невозможным создание текущего или исторические отчеты, связывающие людей и арендованные квартиры.
Есть ли какие-либо рекомендуемые способы моделирования такого типа отношений?
Редактировать на основе ответа пациента и комментариев, предоставленных SQL.Injection
Я создал базовую модель, показывающую модель, описанную в SQL.Injection.
Я переместил даты начала и окончания аренды в измерение «мусор» (Dim.Tenancy) и добавил даты начала и окончания аренды для лиц в таблицу фактов, так как я чувствовал, что это более точный способ описания взаимосвязи.
Однако теперь, когда я вижу это визуально, я не думаю, что это принципиально отличается от модели, с которой я начал, за исключением того, что таблица фактов представляет собой периодический снимок, а не накапливающийся снимок. Он определенно страдает от того же недостатка, что всякий раз, когда я обновляю медленно изменяющийся атрибут типа 2 в любом из измерений, это не отражается на факте.
Чтобы эта работа отражала текущие изменения, а также позволяла историческую отчетность, мне кажется, что мне придется добавлять строку в таблицу фактов каждый раз, когда происходит изменение SCD2 в любом из измерений. Затем, чтобы предотвратить чрезмерный подсчет путем присоединения к нескольким версиям одного и того же объекта, мне также нужно будет добавить новые версии других связанных измерений, чтобы у меня были новые ключи для присоединения.
Мне нужно подумать об этом еще немного. Я начинаю думать, что модель базы данных верна и что мое понимание того, как эта модель будет использоваться, неверно.
А пока любые комментарии и предложения приветствуются!
move out
транзакцию, связанную со старой версией, за которой следует немедленнаяmove in
привязка к новой версии. - person Marek Grzenkowicz   schedule 28.01.2015