【Web エンジニア向け PB 入門】第 3 回：データウィンドウの基礎。SQL がそのまま UI と State になる開発体験

テクニカルブログ

2026.08.03

第 1 回、第 2 回を通して、PowerBuilder (PB) の設計思想やプロジェクト構造を Web 開発のコンテキストに置き換えて理解してきました。
第 3 回となる今回は、PowerBuilder を語る上で欠かすことのできない、そして Web エンジニアが最も衝撃を覚えるであろう機能、「データウィンドウ (DataWindow)」に焦点を当てます。

Web 開発における「API の実装、状態管理、バリデーション、DOM レンダリング」という一連の苦労が、PowerBuilder ではどのように統合されているのか。その技術の裏側を解き明かします。

1. Web 開発者が直面する「CRUD の儀式」からの解放

モダンな Web システムで、データベースの 1 テーブルを編集する画面を作るシーンを想像してください。

– API 構築 : DB からデータを取得するエンドポイントを作成 (SQL / ORM)。
– データモデル定義 : フロントエンドに渡す型 (TypeScript 等) を定義。
– データ取得 : fetch や Axios でデータを取得。
– 状態管理 : useState や Store にデータを格納。
– レンダリング : map() 関数でループ回してフォーム要素を生成。
– データ更新 : 変更された差分を抽出し、再び API 経由で DB へ書き戻す。

この一連の「儀式」を、PowerBuilder はデータウィンドウという単一のオブジェクトで完結させます。

2. データウィンドウの 3 層構造

データウィンドウを理解する近道は、それを「SQL」と「UI レイアウト」と「データ管理エンジン」がパッケージ化されたものだと捉えることです。

コンポーネント	役割	Web 開発でのイメージ
データソース (Data Source)	どのデータを、どう取得するか。	SQL クエリ / API リソース定義
提示様式	どう見せるか (一覧、単票など)。	HTML テンプレート / CSS コンポーネント
データウィンドウコントロール	画面に配置し、実行時にデータを保持する器。	State 管理 / DOM コンテナ

データソース : SQL がそのまま仕様になる

データウィンドウを作成する際、最初に行うのは SQL の定義です。グラフィカルなクエリビルダー、または直接 SQL (SELECT 文) を記述します。

ここでのポイントは、「SELECT で取得したカラムが、そのままプロパティ (列) として定義される」点です。型定義を別途書く必要はありません。DB のメタデータから、データ型や桁数も自動的に引き継がれます。

提示様式 : ノンコードでのレイアウト構築

取得したデータをどう並べるかを選択します。以下はよく利用される提示様式です。

グリッド
Excel のような表形式。列の入れ替えやリサイズが標準で可能。
フリーフォーム

自由なレイアウト。マスタ登録画面などの単票形式。
タブラ

自由度の高い一覧形式。

取得する各項目をマウス操作でドラッグ＆ドロップして配置します。Web エンジニアが CSS の flex や grid で苦労する配置調整が、ビジュアルエディタ (PowerBuilder では「ペインタ」と呼びます) で完結します。

「Update」関数 : 差分管理の自動化

Web エンジニアがデータウィンドウを最も「賢い」と感じる瞬間は、データの更新処理でしょう。

データウィンドウには内部的に「バッファ (Buffer)」という概念があります。

Primary バッファ
- 現在画面に表示されているデータ。
Filter / Delete バッファ
- フィルタリングされたデータや、削除マークがついたデータ。画面には表示されませんが、データは保持されています。

ユーザーが画面上の値 (DB から検索された値) を書き換えると、データウィンドウはその行に「変更フラグ (Dirty チェック)」を立て、「元の値」と「現在の値」の両方を保持します。

そして、コードで dw_1.Update() という関数を 1 行呼ぶだけで、PowerBuilder は内部で「元の値」と「現在の値」を比較して以下の処理を自動生成・実行します。

追加された行に対しては INSERT 文を発行。
変更された行に対しては、変更箇所のみを抽出した UPDATE 文を発行。
削除された行に対しては DELETE 文を発行。

データウィンドウによる更新処理では、Web 開発のような「どの行が変更されたかをループで回して確認し、差分更新の API を叩く」といったコードを書く必要は一切ありません。

3. 多様なバリデーション手段

PowerBuilder (PB) のデータウィンドウは、画面表示・データ処理・バリデーションが強力に一体化した、独自にして最高峰のコンポーネントです。現代の Web 開発 (React、Vue、Angular など) における「UI ライブラリ」、「状態管理」、「バリデーションライブラリ」、「ORM」の役割を、1 つで全て兼ね備えています。

Web 開発の概念に置き換えて、その多彩なバリデーション・表現手法を解説します。

3-1. 入力値そのものを弾く : データ型とカラム検証

データウィンドウは、データベースのスキーマ (データ型) を最初から認識しています。

データ型チェック (自動)
- 数値型のカラムにアルファベットを入力しても、文字の入力が拒否されます。また、日付型の項目には、日付と判断できるテキスト以外は拒否されます。Web では input タグの type="number" や、TypeScript によるプリミティブな型縛りに近いです。
入力条件則
- 項目ごとに「long(gettext()) > 0」「match(gettext(), '^[A-Z]...')」といった条件式を設定できます (gettext() は入力値)。エラー時は独自のポップアップメッセージを表示し、不正な値をサーバー (バッファ) に送らせません。
  Web では Zod や yup、JSON Schema などによるスキーマバリデーションにあたります。フロントエンドの変更通知 (onChange など) のタイミングで即座に検証をかける処理を、ノーコードに近い UI 設定だけで実現しています。

3-2. UI 表現で視覚的に伝える : 「式」による動的変更

Excel の「条件付き書式」のように、「入力値が一定以下なら赤字にする」といった動的なスタイル制御も、スクリプトでロジックを書く必要はありません。データウィンドウの各項目のプロパティには「式」を設定できます。

プロパティの動的制御
- 「文字の色 (Color)」プロパティに if(balance < 0, 255, 0) (負数なら赤、それ以外は黒) のような「式」を仕込みます。
- Web では、状態 (State) に応じた動的なクラス結合やインラインスタイル (CSS-in-JS) です。
  
  Web でのイメージ : <span className={value < 0 ? 'text-red' : 'text-black'}>{value}</span>
Web との違い (PowerBuilder の強み)
- Web では、行ごとにループを回して状態を監視するか、コンポーネントを細かく分ける必要がありますが、データウィンドウは「1 つのプロパティ式」を書くだけで、10 万行あっても描画エンジンが各行のデータを評価して自動で見た目を切り替えます (パフォーマンスが非常に高いです)。

3-3. イベント駆動で複雑な業務ロジックを捌く : スクリプト検証

画面全体の整合性や、他の API / DB の値を参照するような高度な検証は、イベントハンドラ (スクリプト) に記述します。

ItemChanged イベント
- ユーザーが 1 つのセルの入力を終えて確定 (フォーカスアウト) した瞬間にトリガーされます。ここで拒否 (return 1) すると、元の値に戻されて次のセルへ移動させません。
- Web では onBlur イベントでのカスタムバリデーションにあたります。
AcceptText / Update 前検証
- 保存ボタンが押された際、画面全体の未確定データを確定させ (AcceptText)、すべての行の整合性をチェックします。
- Web ではフォーム送信時の onSubmit 全体バリデーションです。

Web 開発者から見た「データウィンドウ」の凄さと割り切り

これら「型チェック」、「個別バリデーション」、「動的装飾」、「全体検証」が、すべてデータウィンドウという「1 つのオブジェクト」に内包されている点は驚きでしょう。画面とロジック、DB スキーマが密結合しているため、業務アプリケーションをすばやく開発できます。

その反面、UI と SQL が直結しているため、Web の「クリーンアーキテクチャ」に慣れていると不安になるでしょう。しかし、PowerBuilder ではこれが正義です。無理に分離しようとせず、データウィンドウを「リッチな ViewModel」として扱うのが PowerBuilder 流だと考えましょう。