従来のRDBのようにレコードに直接外部キーを埋め込むのではなく、関係そのものを独立したオブジェクトとして扱います。
ここでは、アソシエーションとはなんのか、従来のPK/FKによる設計と何が違うのか、そしてアソシエーションラベルが果たす役割を整理します。
Sankaのアソシエーションモデル
Sankaでは「アソシエーション」を以下の2段構成で管理します。アソシエーション (関係の設計図)
- フィールド:
ラベル,ソースオブジェクト,ターゲットオブジェクト,タイプ,作成者,作成日時など。 - 役割: 「どのオブジェクト同士を、どんな名前・制約で結ぶか」を表現するメタデータ。
ソースオブジェクト/ターゲットオブジェクトには受注や連絡先のようなオブジェクトを保持し、UIでの候補制御に使います。
タイプ で One-to-One / Many-to-Many を切り替え、UIやサービス層が選択制限をかけます。
- 仕組：任意のオブジェクトレコード同士をユニーク（一意）なIDで接続します。 １：１、１：多のような設計選択が可能。
従来のRDB (PK/FK) の考え方
- テーブルスキーマに
customer_idのような外部キー (FK) カラムを追加し、参照整合性をDBが保証する。 - テーブル同士の関係はスキーマ時点で固定されるため、関係を追加・変更するにはマイグレーションが必要。
- Joinや制約は強力だが、異なるモジュールやカスタムオブジェクトを後付けでつなぐには柔軟性に乏しい。
アソシエーションとRDBPK/FKの比較
観点 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に適しています。