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加工を行う |
Sankaでは、1つのアソシエーションに、複数のオブジェクトを設定できます。・例えば顧客というラベルに、企業オブジェクトと連絡先オブジェクトを設定できます。
CSVインポートなどで重複された場合は企業オブジェクトが優先されます。
また、オブジェクト間に複数のアソシエーションを定義できます。 例えば、連絡先 と 受注 の間に「担当者」「請求先」「配送先」など、異なる意味を持つ関係をそれぞれ別に作成可能です。
これにより、同じオブジェクトペアでも文脈に応じた関係を柔軟に表現できます。
Q. プロパティにIDを直接入れないといけないの？ アソシエーションなら、レコードを追加するだけで新しい関係を作れます。一方RDBでは外部キーを追加するとスキーマ改修とマイグレーションが必須になり、顧客ごとのカスタム関係をすばやく提供できません。
Q. アソシエーションラベルって何？ ラベルは「この関係は何を意味し、どのオブジェクト間で許可するか」を定義するラベル情報です。UIに表示される名称、選択可能な対象、1対多の制約などをまとめて管理します。
Q. 整合性はどう保っているの？ RDBのFKのようなハード制約ではなく、アプリ層ロジックにより制御します。特定ラベルのリセットや一意制約も行えます。
Sankaのアソシエーションは「関係そのものを拡張・アップグレード」した仕組みです。
ラベルで意味と制約を宣言し、レコードで具体的なペアを保存します。
スキーマ変更なしで柔軟な関係を組み替えられるため、カスタムオブジェクトや外部連携が多いERPに適しています。
