アソシエーションの設定
Sankaのアソシエーションについて：RDBリレーションの違い
Sankaでは、オブジェクト同士の関連付けを「アソシエーション」で表現します。
従来のRDBのようにレコードに直接外部キーを埋め込むのではなく、関係そのものを独立したオブジェクトとして扱います。
ここでは、アソシエーションとはなんのか、従来のPK/FKによる設計と何が違うのか、そしてアソシエーションラベルが果たす役割を整理します。
・同じオブジェクト間でも、用途ごとにラベルを分けると運用が明確になります。
・関係が一意か複数かを先に決めると、後からの修正が減ります。
アソシエーションなら、レコードを追加するだけで新しい関係を作れます。一方RDBでは外部キーを追加するとスキーマ改修とマイグレーションが必須になり、顧客ごとのカスタム関係をはやく提供できません。 Q. アソシエーションラベルって何？
ラベルは「この関係は何を意味し、どのオブジェクト間で許可するか」を定義するラベル情報です。UIに表示される名称、選択可能な対象、1対多の制約などをまとめて管理します。 Q. 整合性はどう保っているの？
RDBのFKのようなハード制約ではなく、アプリ層ロジックにより制御します。特定ラベルのリセットや一意制約も行えます。
従来のRDBのようにレコードに直接外部キーを埋め込むのではなく、関係そのものを独立したオブジェクトとして扱います。
ここでは、アソシエーションとはなんのか、従来のPK/FKによる設計と何が違うのか、そしてアソシエーションラベルが果たす役割を整理します。
Sankaのアソシエーションモデル
Sankaでは「アソシエーション」を以下の2段構成で管理します。アソシエーション (関係の設計図)
- フィールド:
ラベル,ソースオブジェクト,ターゲットオブジェクト,タイプ,作成者,作成日時など。 - 役割: 「どのオブジェクト同士を、どんな名前・制約で結ぶか」を表現するメタデータ。
ソースオブジェクト/ターゲットオブジェクトには受注や連絡先のようなオブジェクトを保持し、UIでの候補制御に使います。
タイプ で One-to-One / Many-to-Many を切り替え、UIやサービス層が選択制限をかけます。
- 仕組：任意のオブジェクトレコード同士をユニーク（一意）なIDで接続します。 １：１、１：多のような設計選択が可能。
従来のDBの考え方
- テーブルスキーマに
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加工を行う |
１つのラベルで複数のアソシエーション
Sankaでは、1つのアソシエーションに、複数のオブジェクトを設定できます。例えば顧客というラベルに、企業オブジェクトと連絡先オブジェクトを設定できます。
CSVインポートなどで重複された場合は企業オブジェクトが優先されます。
同じオブジェクト間に複数のアソシエーション
また、オブジェクト間に複数のアソシエーションを定義できます。 例えば、連絡先 と 受注 の間に「担当者」「請求先」「配送先」など、異なる意味を持つ関係をそれぞれ別に作成可能です。
これにより、同じオブジェクトペアでも文脈に応じた関係を柔軟に表現できます。
アソシエーションを確認する
- 設定画面のアソシエーション管理を開きます。
- 一覧で ラベル / ソースオブジェクト / ターゲットオブジェクト / タイプ を確認します。
- 詳細を確認したいラベルを選択し、対象オブジェクトや制約の内容を確認します。
カスタムアソシエーションを追加する
- アソシエーション管理で新しいアソシエーションを作成します。
- ラベル（表示名）を入力し、ソースオブジェクト と ターゲットオブジェクト を選択します。
- タイプ（One-to-One / Many-to-Many）を選び、必要な制約を設定します。
- 保存して反映します。
作成時のポイント
・ラベルは業務で使う呼び名を優先します（例：担当者、請求先、配送先）。・同じオブジェクト間でも、用途ごとにラベルを分けると運用が明確になります。
・関係が一意か複数かを先に決めると、後からの修正が減ります。
よくある質問と補足
Q. プロパティにIDを直接入れないといけないの？アソシエーションなら、レコードを追加するだけで新しい関係を作れます。一方RDBでは外部キーを追加するとスキーマ改修とマイグレーションが必須になり、顧客ごとのカスタム関係をはやく提供できません。 Q. アソシエーションラベルって何？
ラベルは「この関係は何を意味し、どのオブジェクト間で許可するか」を定義するラベル情報です。UIに表示される名称、選択可能な対象、1対多の制約などをまとめて管理します。 Q. 整合性はどう保っているの？
RDBのFKのようなハード制約ではなく、アプリ層ロジックにより制御します。特定ラベルのリセットや一意制約も行えます。
まとめ
- Sankaのアソシエーションは「関係そのものを拡張・アップグレード」した仕組みです。
- ラベルで意味と制約を宣言し、レコードで具体的なペアを保存します。
- スキーマ変更なしで柔軟な関係を組み替えられるため、カスタムオブジェクトや外部連携が多いERPに適しています。
