Таблица фактов периодического снимка — вопрос дизайна

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

CLAIM_ID    TIME_KEY   AMOUNT_OWED     PAID
123        31.1.2000          1000     0
123        28.2.2000           900     100
123        31.3.2000           800     200
123        30.4.2000             0     1000
123        31.5.2000             0     1000
123        30.6.2000             0     1000
123        31.7.2000             0     1000
123        31.8.2000             0     1000
...

Как видите, после 30.04.2000 нет смысла вставлять новые данные для Claim_id 123, так как он больше не меняется (есть разумная степень уверенности, что этого не произойдет). Это хорошая идея, чтобы прекратить вставлять данные для этой претензии, или я должен сделать это до скончания века :)?

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

Спасибо за любой ответ!


database data-warehouse fact fact-table
person xcelm    schedule 04.01.2021    source источник

Ответы (2)


arrow_upward
0
arrow_downward

просто несколько мыслей...

  1. Если у вас не может быть нескольких платежей в день по требованию (и, возможно, других транзакций, например, процентов, которые увеличивают причитающуюся сумму), то то, что вы показали, на самом деле не моментальный факт, а транзакционный факт. Обычный приведенный пример — это банковский счет, на котором у вас есть несколько входных/исходных транзакций в день, а затем снимок позиции на конец дня (или на конец месяца). Очевидно, я не знаю вашей бизнес-модели, но маловероятно, что будет несколько транзакций в день по одному иску.
  2. Если с момента создания последней записи о фактах в претензии не было никаких изменений, создание новой записи о фактах кажется малоцелесообразным.
person NickW    schedule 04.01.2021
comment
Я понимаю вашу точку зрения - я забыл сказать, что использую формат дд.мм.гггг :). Так что на самом деле это ежемесячные снимки. Я отредактировал свой пост, чтобы было понятнее - person xcelm; 04.01.2021
comment
Хорошо, это имеет больше смысла. Я предполагаю, что сумма, выплаченная в апреле, должна быть 800, а не 1000? Ваши данные также выглядят неверными для последующих месяцев, поскольку они не платят 1000 каждый месяц. Если сумма задолженности и уплаченная сумма равны нулю за конкретный месяц, я не вижу смысла в создании ежемесячной записи моментального снимка для этого требования. - person NickW; 04.01.2021

arrow_upward
0
arrow_downward

Обычно вы выбираете периодический снимок, если у вас есть

а) большое количество сделок и

б) вам нужен эффективный доступ к данным в какой-то момент времени (конец месяца в вашем случае)

Если у вас, скажем, 50 транзакций по претензиям в месяц, и претензия активна в среднем один год, вы получите прибыль от этой схемы, даже если вы будете удерживать неактивные претензии в течение 50 лет (чего вы, вероятно, не будете делать;)

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

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

Напротив, периодический моментальный снимок обычно разбивается по времени моментального снимка, поэтому доступ к нему очень эффективен. не получите бесплатный обед с экономией места и эффективным доступом.

person Marmite Bomber    schedule 04.01.2021