BiTemporal Data Modelを活用して、変更履歴画面を作成してみた

Toshiki Nishikawa

2022年9月25日 18:40

こんにちは。株式会社justInCaseTechnologiesのToshiki Nishikawaです。

SaaS型保険システム"joinsure"のPdMをしています。

BiTemporal Data Modelを活用するようになった背景

金融機関は、業として顧客の契約情報を正しく管理する必要があります。

保険において、契約に関する履歴の管理は非常に重要で、
保険金を支払う際にも必須情報となります。

今回の要件で履歴画面に表示させたいイメージは、以下のようなものです。

上記の図の通り、
変更履歴画面では有効日時と登録日時の2つの時間軸を持っています。

なぜ、履歴管理する上で有効日時と登録日時の
2つの時間軸を持つ必要があるのでしょうか。

それは、以下のユースケースが存在するからです。

・契約中になるタイミングを顧客が指定することができる
・契約終了するタイミング（解約日）を顧客が指定することができる

契約中になるタイミングを顧客が指定することができる

この場合、例えば保険会社が”2021/03/05”に契約を承諾する登録日時と、
その処理が”2021/04/01”に有効化される有効日時の2つの時間軸が生まれます。

契約終了するタイミング（解約日）を顧客が指定することができる

この場合も同様に、保険会社が解約手続きを行う登録日時と、
その処理が12月末に有効化される有効日時の2つの時間軸が生まれます。

BiTemporal Date Modelとは

一言でいうと、2つの時間軸を1レコードで管理するデータモデルです。

2つの時間軸って何？と思われるかもしれませんがここでの2つの時間軸とは
有効時間と現実時間です。

例えば、僕が部活動でメンバーからスタメンになり、最終的に部長になる履歴レコードは以下のように作成されます。
1.2002年04月01日に入部

2.2008年12月01日にコーチからお前は来年の春（2009/04/01）からスタメンだ！と言い渡されます

3.2009/06/01にコーチから秋（2009/09/01）からお前が部長だと言い渡されます

レコードを見ただけではよくわからないと思うので順を追って解説します。

まず1.のデータ作成日時（現実時間）では僕はまだメンバーという状態です。
この時点でその状態に終わりがないので終了日（有効時間）は無限になっています。
また、この時点でレコードのデータは削除されていないのでデータ削除日（現実時間）も無限になっています。（①）

グラフで表現するとこんな感じ↓

そしていよいよスタメンを言い渡されるタイミングで新たな2つのレコードが生成されます。

1つは履歴として、2008/04/01から2009/04/01の1年間は僕はメンバーという状態が有効であったというレコード。（②）

2つ目は、2009/04/01からスタメンという状態が有効になるというレコードが生成されます。（③）

この際最後に有効であったデータ、つまり①のデータは論理削除されるためデータ削除日（現実時間）は無限からスタメンを言い渡された2008/12/01に切り替わります。

グラフで表現するとこんな感じ↓

最後に、部長になると言い渡されたタイミングで新たに3つのレコードが生成されます。

1つは、2008/04/01から2009/04/01の1年間は僕はメンバーという状態が有効であったというレコード。（④）

2つ目は、2009/04/01から2009/09/01の5ヶ月間はスタメンという状態が有効であったというレコード。（⑤）

3つ目は、2009年から部長という状態が有効であるレコード。（⑥）

この際同様に、②、③で作成された最後に有効で僕がスタメンであったレコードは論理削除されるのでデータ削除日（現実時間）は無限から部長になると言い渡されたタイミングである2009/06/01となります。

実際のユースケースに落とし込む

では実際にこのBiTemporal Data Modelを、今回のユースケースに当てはめていきます。

ユースケース

1. 顧客が2021/03/03 15:00に契約申込
2. 保険会社が2021/03/05 13:00に契約の承諾を実施。
その際、有効日時を2021/04/01 00:00に設定
3. 保険会社が2021/12/01 11:00に解約処理を実施。
　その際、有効日時を2021/12/31 16:00に設定