ここでは、次の4つのクラスを例にします。

JournalEntry は1件以上の JournalLine を持ちます。
JournalLine は繰り返し可能な TaxDetail を持つことができ、1つの Account を参照します。
各クラスには、それぞれ entry_id、line_id、tax_id、account_id というunique identifierがあります。

意味の正本はこのセマンティックモデルです。
クラス、属性、カーディナリティ、関連をここで定義します。
問題は、このモデルから得られるデータを、どのように保存・交換するかです。

通常のRDBでは、このモデルを複数のリレーションに分解します。

これは業務システムのデータベースとして自然な設計です。

過去の JournalLine に、次の情報しか保存されていないとします。

何年か後にこのデータを正しく解釈するには、1100 がその当時何を意味していたかを示す Account マスターも必要です。

同じ問題は次のようなデータにもあります。

Header と Line も、整合した一式として保存されていなければなりません。
片方だけ復元しても、参照切れや不完全な取引記録になる可能性があります。

データベースのバックアップを保存すれば、その状態自体を残すことはできます。
しかし将来再利用するためには、正しい

まで復元しなければならないことがあります。

これは障害復旧には適しています。
しかし、持ち運び可能な長期保存形式として常に最適とは限りません。

別の方法として、JournalEntry の属性をすべて JournalLine の各行にコピーしたCSVを作ることができます。

しかし、今度は別の問題が生じます。

entry_date や description が明細行ごとに繰り返されます。
TaxDetail が複数あれば、重複はさらに増えます。

矩形の表としては読みやすくなりますが、どの属性がどのクラスに属するのかが曖昧になります。
本来 JournalEntry に属する値が、物理的には JournalLine の各行にコピーされてしまいます。

構造化Tidyデータは、この二つの極端な方法を避けます。

構造化Tidyデータ は、複数のセマンティッククラスのoccurrenceを、1つの疎な表に格納する、モデル管理された表形式です。

基本原則は単純です。

簡略化した例を示します。

RDB設計者には、この表は見慣れない形に見えます。
複数のセマンティッククラスが1つの物理表の中に共存しているからです。

しかし、これは意図した設計です。

この表は業務DBを置き換えるためのものではありません。
セマンティックなデータセットを持ち運ぶための表現です。

この見慣れない形によって、次の3つを同時に実現できます。

RDB設計者にとって重要なのは、目的が違うという点です。

構造化Tidyデータは、取引を理解するために必要な情報を、1つのモデル管理されたデータセットとして保存できるため、AIによる分析にも適しています。

通常の正規化RDBでは、AIが過去の取引を正しく理解するために、取引行だけでなく、

まで必要になることがあります。

account_id = 1100 という値だけでは意味は十分ではありません。
その歴史時点で 1100 が Cash を意味し、Asset に分類されていたことも分からなければなりません。

構造化Tidyデータでは、JournalEntry、JournalLine、TaxDetail、Account などの関連クラスを同じデータセットに含めることができます。
各値は、その値を所有するクラスの行にだけ記録され、階層occurrence情報によって行同士の関係を保持します。

したがって AI にとっての利点は、単に「表の方がデータベースより読みやすい」ということではありません。

AIは、元の業務データベースとそのJOINを完全に再構築しなくても、過去の取引を調べることができます。

構造化Tidyデータは、RDBを否定する考え方ではありません。

リアルタイムの業務処理には、RDBが引き続き適しています。

構造化Tidyデータの目的は異なります。
長期保存、交換、検証、分析、AIによる歴史データの解釈のために、持ち運び可能で、自己完結性が高く、セマンティックモデルによって管理された表現を提供します。

RDB設計者から見ると、この表の形は一見不自然です。

しかし、それは正規化を捨てるためではありません。
セマンティックな分離を保ちながら、過去の業務記録全体を一緒に保存・移送できるようにするための設計です。