Тип 2 Изменения размеров, относящиеся к другому измерению

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

У меня два измерения: Dim_Person и Dim_Client.

Эти два измерения объединены с помощью не имеющей фактов таблицы фактов Fact_PersonEmployer, которая содержит FK для обоих измерений, а также действительную дату и дату.

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

Это кажется довольно простым, однако, поскольку этот человек теперь перешел к новому работодателю, я бы подумал, что это гарантирует изменение типа 2 в измерении личности, поскольку теперь этот человек принципиально отличается от пользователя (рекрутер / менеджер по набору персонала).

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

Нужно ли мне:

а) Сохраните идентификатор компании, в которой они работают, в качестве атрибута в измерении личности, чтобы он мог генерировать изменения типа 2.

or

б) Продолжать использовать таблицу фактов для связывания двух измерений друг с другом?

Надеюсь, это имеет смысл ...

Заранее спасибо!


person MattB    schedule 12.07.2017    source источник


Ответы (2)


Пара очков:

  1. Сохраните даты от и до в самой таблице измерений, нет необходимости хранить их в таблице Factless Fact.

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

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

    1. Do you want to track that person after he has left the organizaton?
    2. Следует ли полностью закрыть запись?

Если вы хотите сохранить историю и записи о человеке, тогда будет уместным сохранение идентификатора.

person Ravi    schedule 12.07.2017

Если ваш факт демонстрирует отношения найма между DimPerson и DimClient, у вас не должно быть никакой информации о клиенте в DimPerson. Запись DimPerson изменять не нужно, потому что связь содержится в факте (и она должна иметь дату / время события).

Однако, если вы считаете работодателя атрибутом сотрудника, вам не нужна таблица фактов, потому что связь содержится в Dim. В этой ситуации вам следует денормализовать информацию о клиенте в DimPerson. Дата и время будет использоваться как дата вступления в силу записи измерения и дата истечения срока действия ранее активной записи измерения.

Отдельно следует отметить, что согласно лучшим практикам ваша таблица фактов должна описывать событие. Я считаю, что имя Fact_PersonEmployer сбивает с толку. Какое событие он фиксирует? Это событие приема на работу?

person Wes H    schedule 29.09.2017