集計テーブルの概要

本章では以下の内容を扱います。

• 集計テーブルの概要
• 集計テーブルの作成
• 関連関係
• 集計検証

​

機能概要

YiDAの集計テーブルは、複数のフォームを集約して構成される計算テーブルです。リアルタイム計算とリアルタイム検証をサポートし、アプリの他の機能モジュール（フォーム、レポート、ポータルのデータカードリストなど）で利用できます。

​

ユースケース

集計テーブルは、在庫管理、予約獲得、CRMウォレット管理、プロジェクトコスト管理と歩合計算、休暇日数計算などの業務シナリオに適しています。 業務ロジックに流入（入庫、チャージ、休暇日数の付与など）、流出（出庫、消費、休暇取得など）、または残高（残在庫、ウォレット残高、残休暇日数など）が関わる場合には、集計テーブルが最適です。

• 在庫管理シナリオ

製造、小売、建設など、物理的な在庫管理を伴うあらゆる業界では、出庫・入庫・移動・棚卸のライフサイクル全体を管理する在庫管理システムが必要です。これにより、組織は在庫データを正確に把握し、それに基づいて販売・調達・生産を計画できます。集計テーブルを使用すると、入庫と出庫の業務フォームから商品のリアルタイム在庫を算出でき、これらのフォームの送信時や承認時にリアルタイム検証を実行できます。出庫数量が残在庫を超える場合、検証が過剰販売をブロックします。

• CRMウォレット管理

会員アカウントのウォレット残高は、通常チャージと消費のレコードで構成されます。集計テーブルを使用してリアルタイム残高を計算し、利用可能な支出額を検証します。消費金額がウォレット残高を超える場合、消費注文は送信できません。

• 予約獲得シナリオ

イベントチケット販売、レストラン予約、会場予約、フラッシュセールなどのシナリオでは、高い同時実行数により過剰販売が発生する可能性があります。集計テーブルで検証条件を「予約（購入）件数 ≤ 1」に設定することで、この問題を解決できます。

​

利用制限

• 集計テーブル単位
• アプリ単位

​

注意事項

• 集計テーブルのフィルターと検証：集計テーブルにフィルターが設定されている場合、送信時検証はフィルター条件に一致するデータにのみ適用されます。フィルター条件に一致しないデータの追加、削除、変更は送信時検証をトリガーしません。
• 集計テーブルの公開：集計テーブルを公開した後、その列タイトルや指標がフォーム、レポート、その他のコンテキストで使用されている状態で集計テーブルを変更・再公開する（関連関係、指標などの変更や削除）と、集計テーブルが使用されているフォームやレポートでエラーが発生する可能性があります。集計テーブルを参照している構築設定は、あわせて更新することを忘れないでください。
• データソースフォームへの操作方法：一括インポート、一括更新、一括削除、自動化フロー、業務ルール、Open APIなどのメカニズムを使用してデータソースフォームのデータを追加・削除・変更する場合、いずれの場合も集計テーブルの計算結果の更新がトリガーされます。
• 指標での非表示フィールドの使用：非表示の数値コンポーネントを指標の計算に使用する場合、そのコンポーネントは「常に送信」をオンにする必要があります。
• 日付コンポーネントの精度：日付コンポーネントを一致条件として使用する際は、フォーム送信時に使用される日付の精度に注意してください。システムは異なる精度の日付を異なるフィールド値として扱います。例えば、2024年9月9日と2024年9月9日00:00:00は等しくない値として扱われます。
• 選択肢型コンポーネント：関連済みフィールドが選択肢フィールドを使用する場合、関連済みフィールドは選択肢の値（表示値ではなく）に基づいて一致・表示します。
• 非推奨：フォームがすでに集計テーブルのデータソースとして機能している場合、そのフォームにデータを更新する統合と自動化フローを併せて設定することは推奨されません。循環更新の失敗を引き起こしやすいためです（例：フォームが変更または新規作成された後に現在のインスタンスを更新するケース）。