Таблица фактов, связанная с медленно изменяющимся размером

Question

Я стараюсь понять, как лучше всего смоделировать конкретный сценарий для хранилища данных.

У меня есть измерение Person и измерение аренды. Человек может быть на 0, 1 или (редко) многократным арендным договором в любой момент времени, и с течением времени часто будет иметь место с арендаторами. У арендатора может быть один или несколько человек, связанных с ним. Люди, связанные с арендой, могут со временем меняться, и арендация обычно длится много лет.

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

Другим вариантом является моделирование отношения как таблицы фактов аккумулирующего моментального снимка. Я не уверен, насколько хорошо это будет работать на практике, хотя я мог бы связать его только с одной версией Person and Tenancy (оба из которых будут иметь столбцы SCD типа 2), и это, по-видимому, делает невозможным создание текущих или исторические отчеты, связывающие людей и арендаторы вместе.

Есть ли какие-либо рекомендуемые способы моделирования такого рода отношений?

Редактировать на основе ответа пациента и комментарии по данному SQL.Injection

Я подготовил базовую модель, показывающую модель, как описано SQL.Injection.

Я переместил аренды жилья начала/окончания даты в «мусорной» размерности (Dim.Tenancy) и добавил аренды жилья начала/окончания даты Person к таблице фактов, как я чувствовал, что был более точным способом описания отношения.

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

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

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

Тем временем любые комментарии или предложения приветствуются!

Answer 1

Ваша проблема аналогична sale transactions with multiple item. Разница заключается в том, что транзакция обычно имеет несколько элементов, а ваш факт аренды обычно имеет одного человека (арендатора).

Ваша гидра родилась потому, что вы пытаетесь моделировать арену как измерение, когда вы должны моделировать ее как факт.

Причина, по которой я думаю, что у вас есть измерение арендной платы, связано с тем, что у вас есть факт аренды. Чтобы смоделировать факт аренды, рассмотрим использование того же подхода, о котором я говорил выше, если два человека являются жильцами одного и того же имущества, каждый месяц должны вставляться две записи фактов: 1) И теперь приходит какая-то магия (это совсем не волшебство), split стоимость аренды по количеству арендаторов и хранить ее фактом 2) хранить также полную стоимость аренды (вы не знаете, как данные ученого будут использовать данные) 3) check 1) с бизнес-пользователем (я имею в виду людей, которые строят модели риска); может возникнуть какое-то расширенное правило о том, как сделать расщепление (аналогичная ситуация случается, когда стоимость доставки должна быть разделена на несколько строк товара того же порядка - она ​​может быть не распределена равномерно)