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

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

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

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

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

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

Редактировать на основе ответа пациента и комментариев, предоставленных SQL.Injection

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

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

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

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

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

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


person paulH    schedule 27.01.2015    source источник
comment
Что вам нужно представить в отчете позже? Вы можете использовать детализированную таблицу фактов транзакций - каждый раз, когда человека назначают в аренду или удаляют из нее, это транзакция; это будет хорошо работать с отношениями "многие ко многим". Когда меняется лицо или арендатор, вы делаете move out транзакцию, связанную со старой версией, за которой следует немедленная move in привязка к новой версии.   -  person Marek Grzenkowicz    schedule 28.01.2015
comment
Что ж, я кратко подумал о чем-то подобном, но отказался от этой идеи, потому что чувствовал, что пользователям будет сложно создавать отчеты. Что касается того, что мне нужно представить в отчете - я не знаю. Я не создаю хранилище данных для размещения одного отчета, я создаю его, чтобы бизнес-пользователи могли запрашивать сами себя (возможно, с помощью куба) и создавать любой отчет, который они хотят создать. Я думал, что это лучший способ делать что-то, хотя для меня это, наверное, сложнее!   -  person paulH    schedule 28.01.2015


Ответы (1)


Ваша проблема похожа на транзакции продажи нескольких товаров. Разница в том, что транзакция обычно состоит из нескольких элементов, а ваш факт аренды обычно связан с одним человеком (арендатором).

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

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

person SQL.injection    schedule 29.01.2015
comment
Я не уверен, что согласен с вашей оценкой. Существует множество атрибутов аренды, которые необходимо сохранить - дата начала, дата окончания, тип аренды и т. Д., Которые не зависят от людей, составляющих аренду. Есть также много таблиц фактов, которые должны быть связаны с арендой, а не с человеком - одна из них является таблицей фактов арендных транзакций - и поэтому мне нужно измерение аренды, чтобы связать их. - person paulH; 29.01.2015
comment
дата начала, дата окончания ‹- стандартные атрибуты размерности даты. Моделирование размеров скважин - это не то же самое, что моделирование E-R. Что касается фактов, которые должны быть связаны с упорством, я привел вам пример того, как это сделать для фактической ренты. Кстати, я добавил ссылку, чтобы помочь вам лучше понять. - person SQL.injection; 29.01.2015
comment
Считаете ли вы, что одна и та же продажа не появляется в нескольких таблицах фактов в корпоративном хранилище данных? Если вы не принимаете избыточность и денационализацию, значит, вы делаете размерное моделирование неправильно. - person SQL.injection; 29.01.2015
comment
Я вполне согласен с тем, что я, вероятно, делаю это неправильно, мне просто нужно понять, как я делаю это неправильно. Если я воспользуюсь вашим подходом, что я буду делать с датами начала / окончания аренды и атрибутом типа аренды? Добавляются ли они в измерение «Человек»? - person paulH; 29.01.2015
comment
Также мне нужно рассмотреть другие подобные сценарии. Например, у меня есть измерение «Свойство» с множеством атрибутов свойства. Перечитайте мой первоначальный вопрос и замените каждое слово «Аренда» на «Собственность», и вы увидите, что это точно такая же проблема - многие люди связывались с множеством свойств в течение длительного периода времени. Могу ли я также отказаться от измерения «Свойство»? - person paulH; 29.01.2015
comment
no, fact_tenency (key_tenency [surogate key], key_person, key_property, key_date_start, key_date_end, tenency_type [размерный атрибут, вероятно, вам следует создать мини- или нежелательное измерение для этих атрибутов, связанных с арендой, rent_value_year [полная сумма годовой арендной платы за год], rent_value_value rent_value_year / # tenants], contract_number [номер контракта или любой другой эквивалентный документ или идентификатор в операционной системе]). - person SQL.injection; 29.01.2015
comment
При выполнении многомерного моделирования вы должны стремиться к простоте использования для конечных пользователей и производительности запросов. - person SQL.injection; 29.01.2015
comment
Я отредактировал свой вопрос на основе ваших полезных ответов. Спасибо. - person paulH; 29.01.2015