WAGBY11 MANUAL / 04
複合キーのモデルで複数の相手を選択する
会社コードとプロジェクトコードで特定するモデルに複数の社員を関連付け、通常の対照表との違いを説明します。
最終更新日:
1. このページで伝える機能
複数の項目を組み合わせた主キー(複合キー)を持つモデルでも、チェックボックスで複数の相手を選択できます。ここでは「会社コード+プロジェクトコード」で特定するプロジェクトに、参加社員を関連付けます。同じ社員が複数のプロジェクトに参加することもできます。
基本の操作は複数選択チェックボックスを使うと同じです。このページでは、親のキーが複数の項目で構成される場合の対応付けを説明します。
2. Wagby11で実現できること
2.1 通常の対照表との違い
対照表は「どの親が、どの相手を選んだか」を1行ずつ保存するモデルです。単一キーの見積では見積IDを保存します。複合キーのプロジェクトでは、親を一意に特定するために会社コードとプロジェクトコードの両方を保存します。
| 比較する点 | 単一キーの例:見積と部門 | 複合キーの例:プロジェクトと社員 |
|---|---|---|
| 親を特定する項目 | 見積ID | 会社コード+プロジェクトコード |
| 相手を特定する項目 | 部門ID | 社員コード |
| 対照表で重複させない組 | 見積ID+部門ID | 会社コード+プロジェクトコード+社員コード |
| 利用者の操作 | 部門をチェックして保存 | 社員をチェックして保存 |
| 定義するもの | 対照表モデルとキーの対応付け | 対照表モデルと、複合キーの全項目を含む対応付け |
例えば、次の3行で二つのプロジェクトの参加社員を表せます。プロジェクトコードがどちらもP001でも、会社コードが異なるので別の関連です。
| 会社コード | プロジェクトコード | 社員コード | 参加社員 |
|---|---|---|---|
| A001 | P001 | E001 | 佐藤 花子 |
| A001 | P001 | E002 | 鈴木 太郎 |
| B001 | P001 | E003 | 高橋 美咲 |
2.2 プロジェクトの参加社員を選ぶ
会社別プロジェクトの登録画面で、会社コードA001、プロジェクトコードP001を指定し、参加社員として佐藤 花子と鈴木 太郎をチェックします。社員コードと社員名は、あらかじめ参加社員マスタに登録しておきます。

保存後に編集画面を開くと、同じ二人が選択されています。選び直して保存すると、そのプロジェクトの参加社員を今回チェックした集合で置き換えます。

2.3 同じコードでも会社ごとに選択を保存する
会社コードB001、プロジェクトコードP001には高橋 美咲を登録しています。A001と同じP001でも、別のプロジェクトとして選択状態を保持します。A001側の参加社員を変更しても、B001側の選択は変わりません。

親側の対応付けには、主キーを構成する全項目を指定します。この例では会社コードとプロジェクトコードの2項目です。参照先側にも、そのモデルの主キー全体を対応付けます。この例の社員は社員コードだけで特定します。
2.4 関連に数量や順序を持たせる場合
チェックボックスは、相手を選ぶ・外すという用途に向いています。選択順や同じ相手の重複には意味を持たせません。「社員ごとの担当順」「プロジェクトごとの参加時間」などを関連に持たせたい場合は、対照表自体を子モデルとして編集する構成にします。
例えば子の1行に社員・担当順・参加時間を入力する形です。チェックした集合で置き換えるだけでは、これらの追加情報を保持できません。複合キーかどうかにかかわらず、関連に業務情報を持たせるかを先に決めます。子モデルの基本は親子関係のページを参照してください。
3. AIへの指示例
最小限の指示例
会社コードとプロジェクトコードの組み合わせで管理するプロジェクトに、参加社員をチェックボックスで複数選べるようにしてください。AIは既存のモデルを確認し、社員の参照先、対照表、キーの対応付け、画面の表示名などを類推して補います。会社コードの違いを含めて関連を区別することや、担当順・参加時間が必要かを伝えると、設計の意図が明確になります。この短い指示だけで、次の詳細例と同じ定義になるとは限りません。
より詳細な指示例
Wagby11のguideと必要なreferenceを確認し、会社別プロジェクトの参加社員管理を追加してください。
・CompositeProjectは会社コードcompanyCodeとプロジェクトコードprojectCodeの複合主キーとし、プロジェクト名projectNameを持たせてください。コードは各20文字、名称は100文字とします。
・ProjectEmployeeは社員コードemployeeId(20文字)を主キーとし、社員名employeeName(100文字)を持たせてください。
・プロジェクトのemployeeIdsをreference_multiとし、社員名をチェックボックスで複数選択してください。
・CompositeProjectMemberを対照表として明示的に定義してください。自動採番の対照表IDを用意し、会社コード・プロジェクトコード・社員コードの3項目の組を重複させないようにします。
・association.owner.mappingsにcompanyCodeとprojectCodeの両方を、target.mappingsにemployeeIdを対応付けてください。対照表からプロジェクトへの参照も複合キー全体で定義してください。
・関連ごとの担当順や参加時間は不要です。選択集合を置き換える方式としてください。
・G_ADMINに必要な操作を許可し、「プロジェクト参加管理」のメニューと一般利用者向け操作マニュアルを追加してください。
・既存の定義とデータを保持し、設計情報の検証・生成・ビルド・起動を行ってください。
A001/P001に社員E001とE002、B001/P001に社員E003を登録し、保存後の再編集で選択が残ることを確認してください。A001側の選択変更がB001側に影響しないことも確認してください。変更したファイルと確認結果を説明してください。4. 編集されるAppSchemaの例
利用者はキーの構文を覚えず、親を特定する組み合わせと、複数選びたい相手をAIへ伝えられます。以下は今回の定義の抜粋です。固定ID、バージョン、権限、検索・一覧、メニューなどは省略しています。
親の複合キーと対照表への対応付け
entity:
name: 会社別プロジェクト
name_en: CompositeProject
type: T
attributes:
- { name: 会社コード, name_en: companyCode, type: string, length: 20, pk: true }
- { name: プロジェクトコード, name_en: projectCode, type: string, length: 20, pk: true }
- { name: プロジェクト名, name_en: projectName, type: string, length: 100 }
- name: 参加社員
name_en: employeeIds
type: reference_multi
fk: { entity: ProjectEmployee, field: employeeId }
association:
entity: CompositeProjectMember
owner:
mappings:
- { local: companyCode, association: companyCode }
- { local: projectCode, association: projectCode }
target:
mappings:
- { remote: employeeId, association: employeeId }
ui:
enabled: true
fields:
- name_en: employeeIds
reference: { control: checkbox, source: entity, entity: ProjectEmployee, code_field: employeeId, label_field: employeeName }
owner.mappingsは親の項目(local)と対照表の項目(association)を結びます。target.mappingsは参照先の項目(remote)と対照表の項目を結びます。社員マスタではemployeeIdを主キーとして定義します。
対照表の保存項目と親への参照
entity:
name: プロジェクト社員対照表
name_en: CompositeProjectMember
type: T
attributes:
- { name: 対照表ID, name_en: memberId, type: autoid, pk: true }
- { name: 会社コード, name_en: companyCode, type: string, length: 20, not_null: true, unique: uq_project_employee, fk: { entity: CompositeProject, field: companyCode } }
- { name: プロジェクトコード, name_en: projectCode, type: string, length: 20, not_null: true, unique: uq_project_employee, fk: { entity: CompositeProject, field: projectCode } }
- name: プロジェクト
name_en: project
type: fk
not_null: true
fk:
entity: CompositeProject
on_delete: cascade
mappings:
- { local: companyCode, target: companyCode }
- { local: projectCode, target: projectCode }
- { name: 社員コード, name_en: employeeId, type: fk, not_null: true, unique: uq_project_employee, fk: { entity: ProjectEmployee, field: employeeId } }
三つの保存項目に同じunique名を指定し、その組の重複を防ぎます。projectは二つの保存項目をまとめる論理的な参照です。DBの参照制約は会社コードとプロジェクトコードの組で設定します。
対照表の各保存項目のfk.entityとfk.fieldは、associationで対応する項目を示します。複合参照のfk.mappingsは参照先の主キー順に並べます。画面で複数選択する設定と、対照表を子モデルとして編集する設定は用途に合わせて選びます。
5. 参考資料
- guide:エンティティ間の関係
designer/docs/appschema/html/guide/03-model/03-relations.html- reference:entity
designer/docs/appschema/html/reference/06-entity.html- reference:ui
designer/docs/appschema/html/reference/10-ui.html