履歴管理データモデル
はじめに
この記事は、今回、noteを始めるにあたり、これだけは、絶対に世の中に出そう、と思っていたものです。
逆に言うと、これで満足して、他の記事が書けるのか、という不安もありますが、一旦、出してみようと思います。
内容は、2014年の10月末に、突然、点と点が繋がって、そうか！となったもので（セレンディピティですね）、確か、帰りの電車で閃き、家に帰ってから、数時間でパワーポイントに書き出したものが基になっています。
なので、やや、文章的には説明が不足している部分もありますが、今後、補足して行ければと思います。
尚、事例としては、「商品」と「商品管理」という商品の分類を管理するエンティティの関係を、履歴付きで、どう管理するか、というものとなります。
従来のデータモデルの利点と問題点（１）
～直接関係モデル～
商品に直接商品管理の情報を持ち込み
最終レコード数：7
更新/新規作成コスト：16 ※新規作成:1、更新：3とした場合
利点
管理対象エンティティ数が他のモデルと比較し、少ない。
問題点
商品管理名や商品名が変更される場合、コードの関係は変わっていないにも関わらず、関係先のエンティティ側も同時に更新されなければならない。
商品管理名が変更される場合、商品管理の開始日が変更となる為、商品に持っている商品管理の開始日も同時に更新しなければならない。
商品名が変更された場合、開始日が違う新しいレコードが作成される為、変更前の商品管理コード、開始日を設定する必要がある。
⇒片方の変更なのに、単独の更新だけでは完結できない（独立性がない）
⇒例では2つのエンティティ間だけの関係を取り上げているが、実際には、複数のエンティティとの関係を持つ為、より煩雑な手続きが必要となる
商品側から見れば、商品管理側に合わせてレコードが作成される為、商品名が変わっていないにも関わらず、開始日の違う複数のレコードを作成する事となり、1つの事実が細切れ、輪切りで管理される事となる。
従来のデータモデルの利点と問題点（２）
～履歴対履歴モデル～
商品と商品管理の関係を外出し
最終レコード数：9
更新/新規作成コスト：20 ※新規作成:1、更新：3とした場合
利点
商品管理（履歴）の内容が変更されても、商品（履歴）には影響を及ぼさない。
また、その逆も同様の為、それぞれが独立した状態になる。
⇒商品と商品管理の関係を外出しする事で、それぞれのエンティティは必要時に必要な更新だけがされる。
問題点
商品管理、もしくは、商品の変更がされた場合、関係テーブルのレコードを新規作成する必要がある。（細切れ、輪切りになる）
開始日がKEY項目となっている為、誤りがあった場合、更新できず、削除＆新規作成となる。
従来のデータモデルの利点と問題点（３）
～履歴ID対履歴IDモデル～
履歴対履歴モデルのKEY項目をID化
最終レコード数：9
更新/新規作成コスト：20 ※新規作成:1、更新：3とした場合
利点
履歴対履歴モデルと同様。
加えて、開始日がKEY項目となっていない為、誤りがあった場合、削除＆新規作成でなく、更新で対処可能。
問題点
履歴対履歴モデルと同様。
ID化されている為、トランザクション日付から直接関係を取得する事ができない。
検討後のデータモデル
～親対親モデル～
履歴テーブルの親（本来あるはず）を設定し、関係は親同士で紐付ける
最終レコード数：12（親を実装しない場合は、7）
更新/新規作成コスト：13 ※新規作成:1、更新：3とした場合
利点
商品の変更、商品管理の変更は独立して更新され、関係テーブルに影響しない。
⇒関係テーブルの開始日は、商品の変更があった日でも、商品管理の変更があった日でもなく、商品と商品管理の関係の開始日。
更新/新規作成コストが最少。
問題点
管理対象エンティティ数が他のモデルと比較し、多い。
⇒実際には、親エンティティは実装しないと想定される為、それを除くと、直接関係モデルに関係エンティティを加えるだけ
まとめ
通常、以下の手順でモデルが導出される。
①コード管理が必要（エンティティとコードを定義）
②名称が必要（名称を追加）
③名称が変わった場合の対処が必要（開始日、終了日を追加）
その結果、親は定義せず、最初から履歴エンティティを想定して定義しているのが従来のデータモデル。
（結果、形は同じだが、関係の取り方が違っている）
「③名称が変わった場合の対処が必要」の対応として、「開始日」「終了日」を追加して対応するのではなく、別エンティティとして定義する、という部分がポイントとなります。
おわりに
このモデルの考え方に至るにあたり、「T字形 ER手法」（現在は、”TM”に進化）との出会い、がありました。
この手法を使っている方々の会に参加させて頂き、2014年の10月末に閃いた最初のモデルを発表したところ、いろいろ議論が巻き起こり、最終的に、以下の不足点のご指摘を頂き、みんなで納得する形にする事が出来ました。
ご協力頂いた方々に、感謝したいと思います。
最終的に完成したのが、2019年3月末。
その間、4年半も掛ってしまいましたが、実は、この問題に悩んでいたのは、もっと前で、1995年ぐらいだったと思います。
この問題解決だけに取り組んでいたわけではないですが、本質的な問題解決には、大変な時間が掛かる、という事を実感しました。
そして、これは、論理的には理解できたものの、実装はされていない．．．
当時は、上記で紹介した、履歴ID対履歴IDモデルが正解！と誤解していた為、それで実装してしまい、今日も、そのまま動いています。
誤った設計で、後世に誤った実装物を残し、苦労させてしまう、という事は色々なところで起きていると思います。（技術負債）
そういう反省も込め、発信を続けていければと思っています。
この記事が気に入ったらサポートをしてみませんか？