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 から残りのレコードやフィールドが送信されます。この最適化により、レコードやフィールドは必要な場合にだけ送られ、ネットワーク使用量が削減されます。