4D アーキテクチャ設計: 完全ガイド

4D アーキテクチャ設計は、4D データベース (そのテーブル、フィールド、リレーションシップ、インデックス、アクセス レベル) を構造化し、アプリケーションが成長しても高速性、保守性、安全性を維持できるようにするプロセスです。綿密に計画された 4D スキーマには、通常、テーブルの粒度、リレーション戦略、主キーの種類、インデックスの場所、インターフェイス ロジックからのデータの分離という 5 つの重要な決定が含まれます。これを最初から正しく行うと、将来的にコストのかかる移行を回避できます。

重要なポイント

• 4D アーキテクチャ設計では、データ モデル (テーブル、フィールド、リレーション)、ビジネス ロジック レイヤー (メソッド、クラス、トリガー)、プレゼンテーション レイヤー (フォーム、リスト ボックス、ダイアログ) という 3 つの関心事が分離されます。
• リレーション タイプはテーブル数よりも重要です。多対多リンクにはジャンクション テーブルが必要ですが、1 対多リンクでは外部キー フィールドとリレーションが使用されます。
• インデックスは読み取り速度は速くなりますが、書き込み速度は遅くなります。すべてのフィールドではなく、外部キーとクエリの WHERE 句で使用されるすべてのフィールドにインデックスを付けます。
• 4D の ORDA (Object Relational Data Access) レイヤーは、スキーマについての考え方を変えます。適切な名前のテーブルとフィールドは、コード内で読みやすいデータクラス名と属性名になります。
• クライアント/サーバー展開かシングルユーザー展開かは、後から考えて展開するのではなく、アーキテクチャ上の決定です。これは、ロック、キャッシュ、クエリの記述方法に影響します。
• 初日から一貫して適用される命名規則により、他の単一の習慣よりもリファクタリング時間が節約されます。

データベースのコンテキストにおける「4D アーキテクチャ」の意味

4D アーキテクチャ設計とは、1984 年にローラン リバルディエールのチームによって最初にリリースされ、現在は 4D SAS によって維持されているリレーショナル データベースおよびローコード開発環境である 4D プラットフォーム (4th Dimension) 上に構築されたアプリケーションの構造設計を指します。純粋な SQL データベースとは異なり、4D はデータ エンジン、プログラミング言語、フォーム デザイナ、Web/REST サーバーを 1 つの製品にバンドルしています。したがって、ここでの「アーキテクチャ」は、スキーマ層とその上にあるアプリケーション層の両方に及びます。

この用語は、建築ビジュアライゼーション (4D BIM、建築設計における 4 番目の次元としての時間) と混同されることがあります。このガイドでは、ソフトウェアの観点、つまり 4D データベースとそのアプリケーション層をレイアウトする方法について説明します。建築設計を求めて到着した場合、以下の概念は当てはまりません。

4D アプリケーションの 3 つの層

4D アーキテクチャ設計プロジェクトは、明示的な階層化モデルの恩恵を受けます。責任を分割することで、成長するアプリがフォーム スクリプトのもつれに陥るのを防ぎます。

レイヤ 1 — データ モデル

データ モデルは、4D 構造ファイルに保存されているテーブル、フィールド、リレーション、インデックスのセットです。この層には、他の場所に存在する可能性のあるユーザー インターフェイス コードやビジネス ルールを含めてはいけません。フィールドの種類 (テキスト、整数、実数、日付、時刻、ブール値、ブロブ、オブジェクト、ピクチャ) とフィールドの長さはここで固定されており、後でライブ データベースで変更する場合は注意が必要です。

レイヤ 2 — ビジネス ロジック

ビジネス ロジックは、プロジェクト メソッド、クラス、テーブル トリガーに存在します。最新の 4D では、クラス (4D v18 R3 で導入され、それ以降拡張されました) を使用すると、フォームメソッド全体にロジックを分散させるのではなく、再利用可能でテスト可能なコードを作成できます。テーブルのトリガーは作成、保存、削除時に起動されます。これは監査証跡に役立ちますが、ユーザー インターフェイスを呼び出すトリガーはヘッドレス サーバー コンテキストで中断されます。

関連: Airtable — 自動化、ビュー、共有可能なインターフェイスを備えた、実際のリレーショナル データベースの上にあるスプレッドシートのようなシンプルなインターフェイス。.

レイヤ 3 — プレゼンテーション

プレゼンテーションには、フォーム、リスト ボックス、入力ダイアログ、およびあらゆる Web または REST 出力が含まれます。 4D フォーム はフィールドと変数に直接バインドします。これは便利ですが、フォームにロジックを組み込むことを奨励します。フォームメソッドを薄く保つこと、つまりクラスメソッドを呼び出して結果を表示することは、ほとんどの 4D プロジェクトにおいて最大の保守性の向上です。

データ モデルの設計: テーブル、リレーション、キー

4D アーキテクチャ設計におけるデータ モデリングの決定は、4D 固有のメカニズムを重ねたリレーショナル原則に従います。

テーブルの粒度の選択

テーブルは 1 つのエンティティ タイプを表す必要があります。顧客が複数のアドレスを持つことができる場合、「customer」テーブルを「customer」と「customer_address」に分割することは理にかなっています。顧客ごとにアドレスが 1 つだけ存在し、再利用できない場合、それらを統合することは理にかなっています。多数の小さなテーブルに過度に正規化すると、リレーションと結合の数が増加し、リスト ビューのパフォーマンスが低下します。

ショッピングの場合: Zoho Creator — より広範なZohoスイートにプラグインするローコードアプリビルダーで、アプリごとではなくユーザーごとに価格が設定されます。.

リレーションタイプ

4D は、構造エディターで定義された自動リレーションとコードで作成された手動リレーションをサポートしています。よくあるパターン:

関係	4D実装	一般的な使用法
1対多	「多」側の外部キー フィールドとリレーション	請求書 → 請求書明細
多対多	2 つの外部キーを持つジャンクション テーブル	製品 ↔ サプライヤー
1対1	共有主キーまたは一意の外部キー	ユーザー → ユーザープロフィール
自己参照	同じテーブルを指す外部キー	従業員 → マネージャー

主キー戦略

4D は、自動インクリメントする倍長整数主キーと UUID (テキスト) 主キーを提供します。倍長整数キーはコンパクトで、インデックス付けが高速です。 UUID はグローバルに一意であるため、複数のサイトからのデータを結合したり、外部システムと同期したりするときに重要になります。よくある妥協策は、倍長整数の内部キーに加えて、別個の一意の「外部参照」テキスト フィールドを追加することです。

インデックス作成とクエリのパフォーマンス

インデックスは、4D アーキテクチャ設計において最も活用度の高いパフォーマンス レバーであり、また最も過剰適用しやすいものでもあります。

何をインデックスするか

リレーションの外部キーとして使用されるフィールド、クエリの検索条件で頻繁に使用されるフィールド、および大きなリスト ボックスでの並べ替えに使用されるフィールドにインデックスを付けます。 4D は、標準的な B ツリー インデックス、単語ベースのテキスト検索用のキーワード インデックス、および複数のフィールドをカバーする複合インデックスをサポートしています。

インデックスに登録しないもの

インデックスごとに書き込みコストとストレージが追加されます。 2 つの可能な値を使用してブール型フィールドにインデックスを作成しても、ほとんど役に立ちません。全レコード表示の一部としてのみ読み取られるフィールドにインデックスを付けると、何のメリットもなくオーバーヘッドが追加されます。事前に推測するのではなく、アプリケーションが実際の使用パターンを把握してからインデックスを確認してください。

クエリ戦略

ORDA クエリ (ds.Invoice.query("Status = :1"; "Open")) は、再クエリを行わずに並べ替え、フィルター処理し、メソッド間で受け渡すことができるエンティティ選択を返すため、通常、新しいコードの場合は従来の QUERY コマンドよりも推奨されます。非常に大きなテーブルの場合、インデックスなしのフィルターを適用する前にインデックス付きの条件でクエリを制限すると、応答時間が予測可能になります。

関連: Knack — ポータル、ディレクトリ、内部ツールを対象としたコード不要のデータベース ビルダーで、ユーザーごとの料金ではなく定額料金が適用されます。.

ORDA と最新の 4D アーキテクチャ

ORDA (Object Relational Data Access) は、4D v17 で導入された 4D のオブジェクト指向データ アクセス層です。テーブルをデータクラスとして公開し、レコードをエンティティとして公開するため、「Invoice」という名前のテーブルは「ds.Invoice」になり、「TotalNet」という名前のフィールドは「$invoice.TotalNet」になります。

これは 4D アーキテクチャ設計にアーキテクチャ上の影響を及ぼします。テーブル名とフィールド名はパブリック API の一部になりました。フィールドの名前を変更すると、コンパイル時に表示されるようにコードが壊れますが、名前に一貫性がないため、ORDA コードが読みにくくなります。単一のテーブル名、PascalCase フィールド、省略形を使用しないという規則を採用すると、すぐに効果が得られます。

ORDA は、部分的にのみロードされるクライアント側のエンティティ選択もサポートしています。これにより、リスト画面のパフォーマンス プロファイルが変更されます。エンティティ選択にバインドされたリスト ボックスは、その背後にあるクエリにインデックスが作成されていると仮定すると、すべてのレコードをロードしなくても数千行を表示できます。

私たちの選択: Claris FileMaker Pro — デスクトップ、Web、モバイル上で 1 つのファイルからカスタム アプリを必要とするチーム向けの、長期にわたって実行されているリレーショナル データベース プラットフォームです。.

クライアント/サーバー、シングルユーザー、および Web デプロイメント

デプロイメント トポロジは、多くの開発者の期待以上に 4D アーキテクチャ設計を形成します。

シングルユーザー アプリケーションは、データ エンジンとインターフェイスを 1 つのプロセスで実行します。ロックは簡単です。パフォーマンスのチューニングは主にローカル ディスクの速度に関するものです。

クライアントサーバー は、4D サーバー (データエンジン) を 4D クライアント (インターフェース) から分割します。レコードはサーバー上でロックされ、各クエリのネットワーク往復コストが膨大になります。画面ごとに多数の小さなクエリを発行するアーキテクチャは、ここではパフォーマンスが低下します。クエリをバッチ処理し、エンティティ選択を使用すると、ラウンド トリップが削減されます。

Web および REST のデプロイメントでは、4D の REST サーバーまたはコンパイルされた Web メソッドを通じて同じデータ モデルが公開されます。セキュリティが最前線に移行します。テーブルとフィールドのアクセスは、ロールと特権によって制限する必要があり、フォーム メソッドでのみ適用されるビジネス ルールは、Web クライアントには事実上適用されません。

命名規則とドキュメント

一貫した命名は地味ですが、4D アーキテクチャ設計にとっては決定的です。 4D で実行可能な規則:

• テーブル: 単数名詞、PascalCase (「Customer」、「InvoiceLine」)。
• フィールド: PascalCase、型プレフィックスなし (「dInvDate」ではなく「InvoiceDate」)。
• リレーション: 宛先テーブル (「Customer_Invoices」) に従って名前が付けられます。
• メソッド: 動詞が最初 (「CreateInvoice」、「RecalculateTotals」)。
• クラス: 名詞が最初 (「InvoiceService」、「TaxCalculator」)。

各テーブル、その目的、主要な関係をリストした単一のマークダウン ファイルとしてスキーマを文書化すると、オンボーディングと将来の移行がはるかに簡単になります。 4D の構造エディターは関係をグラフィカルに表示しますが、テーブルが「なぜ」存在するのかについては説明しません。

4D アーキテクチャ設計でよくある間違い

ビジネス ロジックをフォーム メソッドに配置する フォーム メソッドは Web コンテキストまたはスケジュールされたタスクから呼び出すことができないため、そこにトラップされたロジックを複製する必要があります。

新しいコード全体で選択ベースのクラシック コマンドを使用します。 クラシック選択はプロセスに限定されており、プロセス間をうまく移動できません。 ORDA エンティティの選択がより柔軟になりました。

ジャンクション テーブルをスキップすること。 単一のテキスト フィールド (カンマ区切り ID) に複数の値を格納すると、インデックス作成が無効になり、レポート作成が困難になります。

すべてにインデックスを作成すること。 書き込みパフォーマンスが低下し、その利点がほとんど実現されません。

デプロイメントまで権限を無視すること。 完成したアプリケーションにセキュリティ モデルを後付けすることは、スキーマに沿って設計するよりもはるかに困難です。

決定方法: 実践的なチェックリスト

4D アーキテクチャ設計を構築する前に、次の質問に答えてください。

1. 同時ユーザーの数は何人ですか? 彼らは LAN、WAN、または Web 経由で接続しますか?
2. どのエンティティに自然な 1 対多の関係があり、どのエンティティにジャンクション テーブルが必要ですか?
3. 大きなテーブルの検索条件または並べ替え順序にはどのフィールドが表示されますか?
4. エントリ ポイント (フォーム、Web、インポート) に関係なく保持する必要があるビジネス ルールはどれですか?
5. データが別のシステムとマージされ、UUID キーが必要になることはありますか?
6. 2 年間でこれを維持するのは誰ですか? その命名は彼らにとって意味のあるものでしょうか?

これら 6 つの質問への答えによって、4D プロジェクトの構造上の決定のほとんどが決まります。

さらに読む

公式 4D ドキュメント (developer.4d.com) では、ORDA、クラス、権限、デプロイメントについて詳しく説明しています。プラットフォームに関係なく適用されるリレーショナル モデリングの基礎については、データベースの正規化に関する Wikipedia の記事を参照してください。ローコードおよび迅速なアプリケーション開発プラットフォームのより広範なコンテキストについては、ローコード開発プラットフォームに関する Wikipedia のエントリが適切な出発点となります。 4D SAS は、ORDA、クラス、その他の 4D アーキテクチャ設計機能がいつ導入されたかを説明するリリースノートと移行ガイドも発行しています。

よくある質問

4D アーキテクチャ設計とは何ですか?

4D アーキテクチャ設計は、4D (4th Dimension) アプリケーションの構造 (テーブル、フィールド、リレーション、インデックス、ビジネス ロジック層、プレゼンテーション層) を計画するプロセスです。これにより、アプリケーションの実行方法、変更の容易さ、デスクトップ、クライアントサーバー、または Web クライアントへの展開の安全性が決まります。

4D アーキテクチャは 4D BIM と同じですか?

いいえ、4D BIM は、建設スケジュールのための建物情報モデリングに 4 番目の次元として時間を追加します。ソフトウェアの意味での 4D アーキテクチャは、4D データベース プラットフォーム上でアプリケーションを設計することを指します。 2 つのフィールドは略語を共有しますが、それ以外は何も共有しません。

ORDA またはクラシック 4D コマンドを使用する必要がありますか?

ORDA は新規開発に最適なオプションです。再度クエリする必要なく、メソッド間で受け渡し、並べ替え、フィルター処理できるエンティティ選択を返し、テーブルとフィールドを読み取り可能なオブジェクトのプロパティとして公開します。従来の選択ベースのコマンドは、従来のコードや一部の特殊なケースでは依然として役立ちます。

4D テーブルにはインデックスがいくつ必要ですか?

固定の番号はありません。外部キー、一般的な検索条件で使用されるフィールド、および大きなリストの並べ替えに使用されるフィールドにインデックスを付けます。通常、書き込みコストが読み取りメリットを上回るため、ブール値や 2 つまたは 3 つの値を持つステータス フィールドなど、カーディナリティの低いフィールドのインデックス作成は避けてください。

4D ではどの主キーのタイプを選択すればよいですか?

自動インクリメント型の倍長整数キーはコンパクトかつ高速であり、単一サイトのアプリケーションに適しています。 UUID テキスト キーは大きくなりますが、グローバルに一意であるため、複数のサイトからのデータを結合したり、外部システムと統合したりするときに重要になります。多くのプロジェクトでは、内部的に倍長整数キーと一意の外部参照フィールドを使用します。

デプロイ後に 4D データ モデルを変更できますか?

はい、ただし注意してください。テーブル、フィールド、インデックスの追加は通常は簡単です。フィールド タイプの変更、ORDA コードで使用されるフィールドの名前変更、またはライブ データベース上のリレーションシップの再構築には、計画的な移行が必要です。最初に運用データのコピーでテストするのが理想的です。