WAGBY11 MANUAL / 05
親子関係を定義する
伝票と明細を親子として関連付け、一つの伝票に複数の明細を持たせる方法を説明します。
最終更新日:
1. このページで伝える機能
「親」と「子」とは?
親子関係は、一つのまとまりを表すデータ(親)と、その中に属する複数のデータ(子)の関係です。例えば、受注伝票が親、その伝票に並ぶ商品の明細が子です。伝票全体に共通する件名は親へ、商品ごとに異なる品名や数量は子へ保存します。
この章で扱うWagby11の親子関係は、親の主キーを参照する項目と、親の中で明細を区別する枝番を、子の複合主キーにする構成です。この例では、親の「受注ID」と、子の「明細番号(枝番)」を組み合わせます。
この伝票に属する明細
子:受注明細
| 受注ID (親ID) | 明細番号 (枝番) | 品名 |
|---|---|---|
| 1001 | 1 | デスクライト |
| 1001 | 2 | ブックスタンド |
この伝票に属する明細
子:受注明細
| 受注ID (親ID) | 明細番号 (枝番) | 品名 |
|---|---|---|
| 1002 | 1 | ファイルボックス |
| 1002 | 2 | ペンスタンド |
子の主キー = 親ID(受注ID)+ 枝番(明細番号)
親IDと枝番を組み合わせた「複合キー」
主キーは、一つのデータを間違いなく特定するための目印です。親の受注伝票は「受注ID」一つで特定できます。子の受注明細は、どの伝票かを表す「受注ID」と、その伝票の何番の明細かを表す「明細番号」の二つで特定します。複数の項目を組み合わせた主キーを複合主キー(複合キー)と呼びます。
図の「受注ID 1001・明細番号1」と「受注ID 1002・明細番号1」は、別の明細です。枝番は親ごとの番号なので、別の親では同じ番号を使えます。同じ受注IDの中に同じ明細番号を重複して保存することはできません。親IDだけでは複数の明細のどれかが決まらず、枝番だけではどの伝票の明細かが決まらないため、この二つを組にします。
AppSchemaでは、親の受注IDへの参照項目と、type: branchidの明細番号の両方をpk: trueにします。この構造にすると、親の詳細画面に、その親に属する子の一覧が「関連データ」として表示されます。枝番は明細を登録するときにサーバーが自動で割り当てるため、利用者が手入力する必要はありません。
2. Wagby11で実現できること
この例では受注伝票を親、受注明細を子にしています。受注伝票の詳細に、その伝票に属する明細だけが「関連データ」として表示されます。

明細は「受注伝票を識別するキー」と「伝票内の明細番号」の組で識別します。この例では採番結果を表示するため、保存しない読み取り専用の「明細番号」表示項目を追加しています。
明細番号を親ごとに自動で割り当てる
上の受注伝票に明細を追加すると、明細番号1・2が割り当てられます。別の受注伝票の最初の明細には、次のように明細番号1が割り当てられます。枝番はすべての受注伝票をまたいだ通し番号ではなく、親ごとの番号です。

枝番は同じ親の現在の最大値に1を加えて採番します。削除による欠番を埋めることや、削除した番号を永久に再利用しないことは保証しません。表示順を自由に変えるための項目が必要な場合は、枝番とは別に用意します。
3. AIへの指示例
最小限の指示例
受注伝票に複数の明細を持たせ、品名と数量を管理できるようにしてください。明細番号は伝票ごとに自動で付けてください。親と子に分ける項目、画面での入力方法、採番結果の表示方法などをAIが類推して補います。親と子を別々に登録するか、一緒に編集するかなど、操作の希望があれば伝えます。
より詳細な指示例
受注伝票(SalesOrder)を親、受注明細(order_line)を子にしてください。親は自動採番のorderIdと件名subjectを持ち、子は親への参照orderIdと枝番lineNoを複合主キーにしてください。lineNoはbranchidで親ごとに自動採番し、利用者には入力させません。子に品名itemNameと数量quantityを用意します。親の詳細で、その親に属する明細だけを確認できるようにしてください。親と子を別々に登録・確認する操作も使えるようにします。
受注伝票Aに2件の明細を登録して明細番号が1・2、別の受注伝票Bに1件を登録して1となることを確認してください。番号の詰め直しや永久的な不再利用は要件にしません。
採番結果は、lineNoを表示時計算で取得する保存しない読み取り専用項目lineNoDを用意し、一覧と詳細で確認できるようにしてください。
既存のモデル・主キー・データ・権限を保持し、guide・referenceで必要な仕様を確認してください。新規モデルにはG_ADMINの必要な登録・参照・更新・削除権限と予約属性versionを用意します。メニューと一般利用者向け操作マニュアルを更新し、設計情報の検証・コード生成・起動を行って保存後の内容を確認してください。4. 編集されるAppSchemaの例
以下は関連する定義の抜粋です。構文を覚えなくても、実現したい動作をAIへ伝えられます。
# SalesOrder.yaml の属性の抜粋
entity:
attributes:
- { name: 受注ID, name_en: orderId, type: autoid, pk: true }
- { name: 件名, name_en: subject, type: string, length: 100 }
# order_line.yaml の属性の抜粋
entity:
attributes:
- name: 受注伝票
name_en: orderId
type: reference
pk: true
fk: { entity: SalesOrder, field: orderId }
- name: 明細番号
name_en: lineNo
type: branchid
pk: true
- { name: 品名, name_en: itemName, type: string, length: 100 }
- { name: 数量, name_en: quantity, type: integer }
採番された明細番号を表示する
この例では、次の表示用項目を受注明細の属性に追加しています。明細番号そのものはlineNoで保持し、表示用のlineNoDには保存しません。
# order_line.yaml の attributes に追加する表示用項目
- name: 明細番号
name_en: lineNoD
type: long
readonly: true
transient: true
calc:
on: [display]
expression: "lineNo"branchidは親キーと組み合わせて使う自動採番であり、autoidのような全体の一意番号とは用途が異なります。親のキーと枝番を子の主キーにすることで、枝番付きの親子関係として扱います。ここでのtype: referenceは論理的な関係を表し、DBの外部キー制約は生成しません。削除時の扱いやDB制約が必要な場合は、それもAIへ伝えます。
5. 参考資料
- guide:エンティティ属性タイプ・枝番
designer/docs/appschema/html/guide/03-model/02-fields.html- guide:エンティティ間の関係
designer/docs/appschema/html/guide/03-model/03-relations.html- reference:entity
designer/docs/appschema/html/reference/06-entity.html- guide:保存しない項目
designer/docs/appschema/html/guide/08-rules/07-transient-fields.html