Sankaでは、オブジェクト同士の関連付けを「アソシエーション」で表現します。
従来のRDBのようにレコードに直接外部キーを埋め込むのではなく、関係そのものを独立したオブジェクトとして扱います。
ここでは、アソシエーションとはなんのか、従来のPK/FKによる設計と何が違うのか、そしてアソシエーションラベルが果たす役割を整理します。
Sankaでは「アソシエーション」を以下の2段構成で管理します。
フィールド: ラベル, ソースオブジェクト, ターゲットオブジェクト, タイプ, 作成者, 作成日時など。
役割: 「どのオブジェクト同士を、どんな名前・制約で結ぶか」を表現するメタデータ。
ソースオブジェクト / ターゲットオブジェクト には 受注 や 連絡先 のようなオブジェクトを保持し、UIでの候補制御に使います。
タイプ で One-to-One / Many-to-Many を切り替え、UIやサービス層が選択制限をかけます。
仕組：任意のオブジェクトレコード同士をユニーク（一意）なIDで接続します。
１：１、１：多のような設計選択が可能。
アソシエーションラベルにより、連絡先から見たら受注、受注から見たら顧客といったような呼称を調整することも可能。
つまり「どのオブジェクトのどのレコード同士が結び付いているか」という事実を、このアソシエーションで管理することができます。
テーブルスキーマに customer_id のような外部キー (FK) カラムを追加し、参照整合性をDBが保証する。
テーブル同士の関係はスキーマ時点で固定されるため、関係を追加・変更するにはマイグレーションが必要。
Joinや制約は強力だが、異なるモジュールやカスタムオブジェクトを後付けでつなぐには柔軟性に乏しい。
観点 | RDBのPK/FK | Sankaアソシエーション |
設計単位 | テーブル定義とIDカラム | 中間テーブルを拡張したレコード同士の関連付け管理機能 |
関係の追加 | マイグレーションが必要 | UI/APIからラベルを作成すれば即時反映 |
接続できる対象 | 固定の2テーブル | 任意の標準オブジェクト/カスタムオブジェクト、複数テーブル連携、制御機能 |
整合性担保 | DBがFK制約で保証 | アプリ・UI層でロジック制御 |
関係の意味付け | カラム名に依存 (例: order_contact_id) | ラベルで多言語・文脈ごとの名称を提供 |
検索・集計 | SQL JOINが基本 | ラベル単位で抽出し、必要に応じてRDB JOINやAPI加工を行う |
Q. プロパティにIDを直接入れないといけないの？
アソシエーションなら、レコードを追加するだけで新しい関係を作れます。一方RDBでは外部キーを追加するとスキーマ改修とマイグレーションが必須になり、顧客ごとのカスタム関係をすばやく提供できません。
Q. アソシエーションラベルって何？
ラベルは「この関係は何を意味し、どのオブジェクト間で許可するか」を定義するラベル情報です。UIに表示される名称、選択可能な対象、1対多の制約などをまとめて管理します。
Q. 整合性はどう保っているの？
RDBのFKのようなハード制約ではなく、アプリ層ロジックにより制御します。特定ラベルのリセットや一意制約も行えます。
Sankaのアソシエーションは「関係そのものを拡張・アップグレード」した仕組みです。
ラベルで意味と制約を宣言し、レコードで具体的なペアを保存します。
スキーマ変更なしで柔軟な関係を組み替えられるため、カスタムオブジェクトや外部連携が多いERPに適しています。
