4D Serverアーキテクチャ

クライアント/サーバアーキテクチャを使用して、4D Serverはデータベースを格納したり保存したりするだけでなく、クライアントへのサービスも提供します。これらのサービスはリクエスト/レスポンスのシステムを使用してネットーワーク経由で管理されます。

例えばレコードを検索するために、クライアントマシンはクエリリクエストをサーバに送信します。リクエストを受信するとサーバはクエリ処理をサーバマシン上でローカルに実行し、クエリが完了すると、結果(検索されたレコード) を返します。

4D Serverのアーキテクチャはクライアント/サーバモデルに基づきます。現在ではクライアント/サーバアーキテクチャはより古いファイル共有アーキテクチャをしのぎ、マルチユーザデータベースにおいて最も効率の良いモデルとなりました。

4D Serverのクライアント/サーバ実装はミニコンピュータの世界で使用されているものと同じです。しかし、4D Serverは2つの重大な新しい手法を提供します:

• データベースのすべてのレベルにおけるユーザフレンドリなグラフィカルインタフェース
• 効率と速度を向上させる統合アーキテクチャ

クライアント/サーバアーキテクチャが導入される以前、マルチユーザシステムには、ネットワークアーキテクチャのファイル共有モデルが使用されていました。このモデルでは、すべてのユーザは同一のデータを共有しますが、データ管理は中央のデータベースエンジンによって制御されていません。各クライアントマシンにはデータベースストラクチャとエンジンのコピーを格納する必要があり、一方でサーバにはネットワーク上でファイルを共有するために必要なソフトウェアしかありません。

ファイル共有モデルのもとでは、各ワークステーションがすべてのデータ変更をローカル上で行います。処理ごとに多量の更新を必要とし、ネットワーク付加の増大につながりました。以下の図は、名前が"Smith"である人をデータベースで検索するときにネットワーク上で作成されるトラフィックを例示したものです。

ファイル共有モデルのもう1 つの欠点は、メモリキャッシュを利用してメモリ上にレコードを保持できないということです。ファイル共有モデルでレコードがメモリ内に保持されると、各ユーザが同じレコードを異なるバージョンでキャッシュに格納する可能性があり、データに矛盾が生じてしまうためです。したがって、ユーザはレコードにアクセスするたび、ファイルサーバからレコードをダウンロードする必要があります。これはネットワーク負荷を増大させ、レコードアクセス時間の増加につながります。

クライアント/サーバアーキテクチャは効率が良く高速なので、ミニコンピュータの世界では大規模データベースシステムで広範囲に使用されています。このアーキテクチャでは、パフォーマンスを向上させるために、サーバマシンとクライアントマシンが作業を分担します。

サーバには中心となるデータベースエンジンがあり、データを格納し、管理します。データベースエンジンは、ディスク上に格納されたデータにアクセスする唯一のソフトウェアです。クライアントがサーバに要求を送ると、サーバは結果を返します。結果はクライアントが変更する特定のレコードであったり、ソートした一連のレコードの場合もあります。

一般に、ほとんどのクライアント/サーバアーキテクチャは、異種混合アーキテクチャと呼ばれていますが、これはクライアントマシン上で実行しているフロントエンドアプリケーションとサーバマシン上で実行しているデータベースエンジンに別々の製品が使用されるためです。このような場合には、クライアントとサーバの間に入って翻訳を行うデータベースドライバが必要です。

例えば、レコードを検索する場合、クライアントはサーバに検索要求を送ります。データベースはサーバ上に格納されているので、サーバはサーバマシン上でローカルにコマンドを実行し、結果をクライアントに返します。次の図は名前が“Smith”であるすべての人をデータベースから検索し、見つかった最初のレコードを表示するようにサーバに要求した場合にネットワーク上で作成されるトラフィックを示しています。

この例により、クライアント/サーバアーキテクチャとファイル共有アーキテクチャでは2 つの点で大きく異なることがわかります:

• クライアント/サーバアーキテクチャではキャッシュを使用できる: データに物理的なアクセスを行うのはエンジンだけのため、サーバはディスクに書き込まれるまで、変更レコードを保持するためのキャッシュをメモリ上に持つことができます。データは1 カ所から送出されるので、クライアントは必ず最新版レコードを受け取ることができます。中央のキャッシュメカニズムを使用することにより、データの整合性を保証すると共に、ディスクにアクセスするのではなく、メモリにアクセスするため、データベース処理速度の向上にもつながります。ファイル共有モデルでは、アクセスはすべてディスクアクセスです。
• 低レベルのデータベース処理はサーバ上で実行される: クライアント/サーバアーキテクチャでは、インデックスやアドレステーブルのブラウジング等、低レベルのデータベース処理はサーバマシンのスピードに合わせてサーバマシン上でローカルに実行されるので、処理速度が大幅に速くなります。ファイル共有アーキテクチャでは、同じ処理を行っても、ネットワークの通信速度とクライアントマシンの制約のため遅くなります。

ほとんどのクライアント/サーバアーキテクチャでは、クライアントソフトウェアとサーバソフトウェアは2 つの異なる製品であり、互いに“通信”するためにはコミニュケーションレイヤが必要です。4D Server では、クライアント/サーバアーキテクチャは完全に統合されています。4D Server と4Dは同一の構造を共有し、直接通信を行うアプリケーションです。

4D Server と4Dは同じ言語を使用するので、問い合わせ言語を翻訳する必要がありません。クライアントとサーバの作業の分担は、透過的であり、4D Server が自動的に管理します。

作業の分担は、1 つの要求が1 つの応答を返す形で構成されています。図に示すように、クライアントには次の役割があります:

• リクエスト: 4Dクライアントマシンは4D Server にリクエストを送ります。これらのリクエストはクエリエディタや並べ替えエディタ等の組み込みエディタ、統合4Dランゲージ、あるいはSQLを使用して行います。4Dには、メソッドを作成し、変更できるエディタが用意されています。また変数や配列等のメソッド要素も管理されます。
• レスポンスの受信: 4Dクライアントマシンは4D Server からの応答を受け取り、ユーザインタフェース（フォームに様々なレコードが表示する等）を介してユーザに情報を示します。例えば名前が“Smith”であるすべてのレコードをクライアントが要求した場合に、4Dは4D Server から結果のレコードを受け取り、それをフォームに表示します。

サーバには次の役割があります:

• スケジューリング: 4D Server は、同時接続およびクライアントが作成した同時プロセスをすべてスケジュールするためのマルチタスキングアーキテクチャを使用します。
• ストラクチャとデータオブジェクト: 4D Serverはフィールド、レコード、フォーム、メソッド、メニュー、リスト等、すべてのデータオブジェクトとストラクチャオブジェクトを格納し、管理します。
• キャッシュ: 4D Server は、レコードの他にセレクションやセット等の特定のクライアントに固有のデータオブジェクトを納めるキャッシュを維持します。
• 低レベルデータベース処理: 4D Server は、クエリやソート等、インデックステーブルやアドレステーブルを使用する低レベルのデータベース処理を実行します。

この作業の分担は、4D Server と4Dが独自の形式で統合されているので、非常に効率良く行われます。4D Server のアーキテクチャの統合は、すべてのレベルに及んでいます:

• リクエストレベル: 4Dが4D Server にクエリやソート等のリクエストを送信するとき、4Dは4D Server と同じ内部構造を使用してクエリ処理やソート処理の記述を送信します。
• ストラクチャまたはデータレベル: 4Dと4D Serverがデータやストラクチャのオブジェクトをやり取りする場合、どちらのアプリケーションも同じ内部形式を使用します。例えば4Dでレコードが必要な場合、4D Serverはディスクやメモリキャッシュに入っていた形のままでデータを送信します。同様に、4Dがレコードを更新する場合には、4Dが4D Server へデータを送信し、4D Server は受信したそのままのデータをキャッシュに格納します。
• ユーザインタフェースレベル: 4Dがレコードのリストを表示する場合、レコードを表示するために使用されるフォームは、クライアント/サーバアーキテクチャの役割を果たしています。例えば、次の図は[Customers]テーブルを検索した結果を示しています。

上記のウインドウは、一度に5フィールドずつ12レコードしか表示できないため、4D Server は12レコードだけを送信します。レコード全体を送る代わりに、4D Server はウィンドウに表示できるだけの数のレコードとフィールドを送ります。ユーザがフォームをスクロールした場合には、必要に応じて4D Server から残りのレコードやフィールドが送信されます。この最適化により、レコードやフィールドは必要な場合にだけ送られ、ネットワーク使用量が削減されます。