本文へ移動
Wagby11
マニュアルのグループを選ぶ

WAGBY11 MANUAL / 05

親子関係を定義する

伝票と明細を親子として関連付け、一つの伝票に複数の明細を持たせる方法を説明します。

最終更新日:

親子関係の小目次へ

1. このページで伝える機能

「親」と「子」とは?

親子関係は、一つのまとまりを表すデータ(親)と、その中に属する複数のデータ(子)の関係です。例えば、受注伝票が親、その伝票に並ぶ商品の明細が子です。伝票全体に共通する件名は親へ、商品ごとに異なる品名や数量は子へ保存します。

この章で扱うWagby11の親子関係は、親の主キーを参照する項目と、親の中で明細を区別する枝番を、子の複合主キーにする構成です。この例では、親の「受注ID」と、子の「明細番号(枝番)」を組み合わせます。

親:受注伝票受注ID:1001件名:事務用品の注文

この伝票に属する明細

子:受注明細

受注ID 1001の明細
受注ID
(親ID)
明細番号
(枝番)
品名
10011デスクライト
10012ブックスタンド
親:受注伝票受注ID:1002件名:備品の追加注文

この伝票に属する明細

子:受注明細

受注ID 1002の明細
受注ID
(親ID)
明細番号
(枝番)
品名
10021ファイルボックス
10022ペンスタンド

子の主キー = 親ID(受注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から始まります。
別の受注伝票では明細番号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