以下では、サブジェクトエリアのアーキテクチャのオプションの1つについて説明します。 この記事は、 ADVでの実務経験に基づいています。ADVは 、Webプロジェクトの開発で同様の方法を使用しています。 提示された資料の複雑さにより、ソフトウェア開発者だけでなく、既存のWebプロジェクトに定期的に変更を加えて新しいデータを追加する必要があるWebマスターも理解できます。
最も単純なシステムでは、ストレージを整理することしかできません。その後、開発者はストレージを処理し、データ処理に必要なすべての作業を自分で行います。 このようなリポジトリには、オブジェクト、フィールド、およびデータのみがあります。 より高度なシステムでは、オブジェクト間に関係が表示されます。 次のレベルの開発は、オブジェクト（トリガー、メソッドなど）の相互作用と、データ処理に関する心配の一部を開発者から取り除くソフトウェアサブシステムの存在です。
すべてがデバッグされたサブジェクト領域に構築される完璧なアプリケーションを想像してください。 そのアーキテクト（通常、一部のストレージシステムの専門家）は、将来のアプリケーションを事前に知っており、ストレージレベルとアルゴリズムレベルの3つのアプリケーション開発レベルのうちの2つをカバーするようにリポジトリを作成します。 Web開発者による機能のさらなる開発は、ビジネスタスク（すべてのブログ投稿の表示、現在のブログ投稿のすべてのコメントの選択など）の問題にすぎません。
開発者にとって、SQLレベルのデータストレージ構造がどのように構成されているかを正確に知ることはそれほど重要ではありません（データストレージ構造は、データ自体の形式で実装されるか、標準DBMSツールを使用して実装されるか、混合されます）。 オブジェクト属性の概念で動作します。 この場合のサブジェクト領域は、グラフで表すことができます。 オブジェクトの標準特性（属性（情報）、通信）に加えて、用語フィールドには次のものがあります。
- コミュニケーションだけでなく、インタラクション（トリガー）も整理できます。
- グラフルート（クローズ、オープン、頻繁に変更）;
- SQLテーブルが実際にどのように見えるかを知ることを拒否。
- メソッド（ユーザーを追加し、メールで手紙を送り、別のオブジェクトに何かを追加します）。
オブジェクトモデル
オブジェクトモデルでは、B：A（B）の既知のパラメーターに従ってセットAを選択できる必要があります。 実用的な例を次に示します。
- 年齢が20歳以上のユーザーのリスト：user（user.age> 20）;
- 20歳以上のユーザーへのギフトのリスト：ギフト（user.age> 20）。
このモデルの特徴は何ですか？ 開発者は、UserオブジェクトとGiftオブジェクトがどのように関連しているかを知る必要はありません。 必要なビジネスロジックを何らかの形式（システムによって提供されるAPI）で記述するだけで十分であり、サーバー自体が必要な接続を構築し、望ましい結果をもたらします。
データベースアーキテクトにとって、システムはすべてのオブジェクト、通信などを記述することができるメカニズムを表します。 理想的には、システムは、設計者が作成したデータウェアハウスの構造を視覚的に確認できるインターフェイスも提供できます。
このようなモデルを実装するために、いわゆるオブジェクトサーバーが作成されます。 これは、それ自体がアプリケーションであり、他のアプリケーションと対話するためのいくつかのインターフェースを備えています。 オブジェクトサーバーは、そのコンポーネントを認識し、要求された情報を判別します。 開発者がデータベースへのクエリを記述するクライアントアプリケーションは、データベースの構造を認識しませんが、オブジェクトサーバーから必要な情報を要求できるメカニズムを備えています。
例を考えてみましょう。対象領域はグラフとして描かれています。
グラフは、セルラー通信の状況を示しています。オペレーター-地域-料金-SIMカード（番号）-契約-電話-ブランド-人-登録場所。 リクエストの例：
- 地域（個人、年齢> 20、ブランド= Nokia）;
- 地域（人々。年齢> 20）。
コミュニケーション
クライアントアプリケーションは、「Person」および「Brand」オブジェクトのパラメータをオブジェクトサーバーに送信します。オブジェクトサーバーは、それらとの接続を構築し、そのような人々が住んでいる地域のリストを提供します。 グラフからわかるように、接続を明らかにするためにそれを回避するためのいくつかのオプションがあります。 計算するために、ツリーが順番に構築され、そのルートは目的のオブジェクト（領域）であり、ブランチはすべて順番に接続されたオブジェクトです。 構築は、グラフの奥深くにある目的のオブジェクトから数回繰り返されます。 この例では、このようなレベルのツリー4です。ツリーでは、各オブジェクトは一度だけ参加します。 必要なノードを構築した後、開発者が設定したパラメーターにマークが付けられ、余分なノードが切断されます。 リージョンサンプリングの例では、Contract-Operatorブランチは必要ないため、考慮されません。 また、公開された「ブランド」と「男性」によると、オブジェクトサーバーは間違いなくリージョンを決定できます。
そこで、関数A（B）を計算するために、オブジェクト間の可能なパスがどのように構築されるかを見つけました。 どのルートがオブジェクトサーバーによって選択されるかを理解する必要があります。 ここではすべてが非常に単純です。ルートは、参加しているオブジェクトの重みに基づいて最短で選択されます。 独立したオブジェクトの最大重みが1であるというのは論理的です。バインディングオブジェクトの重みは1/2です。 他のストレージエンティティにも同様の重みがあります。
オブジェクトタイプ
システムを設計するとき、特に機能を増やして徐々に開発するシステムを設計するとき、ベースを複雑にし、散らかす危険が常にあります。 サブジェクト領域では、中間接続が頻繁に変更されますが、時間とともに変化しない基本的な用語フィールドがあります。 靭帯と補助オブジェクトは変化しています。 新しいモジュールを追加する場合、同じ物理データストアに基づいて構築するのが最も効果的ですが、システム全体に共通するベースオブジェクト（たとえば、ユーザー、市など）として、それら自体ではなくエイリアスオブジェクトを使用します。 これはオブジェクトサーバー内の独立したオブジェクトであり、その親の構造とデータを完全にコピーします。 ただし、グラフ構造では、これらは独立した頂点です。
この例では、エイリアスを使用しませんでした。 ただし、オブジェクトサーバーを呼び出して一度に複数のルートに沿って接続を確立する、いわゆるリングがあります。 たとえば、開発者がリクエストRegion（Person.Age> 20）を実現したい場合、オブジェクトサーバーは一度に2つのルートに沿って移動するように強制されます。
これにより、操作を実行するための時間とリソースが増加します。 データベースアーキテクトは、設計プロセス中にリングの形成をできるだけ避ける必要があります。 この場合、彼はエイリアスオブジェクトや、有限であり、自分でエンドツーエンドの関係を構築することを許可しないオブジェクトをマークする特別なパラメーターによって助けられます。 このアーキテクチャは、多対多の関係を排除するのに役立つオブジェクトバンドルも提供します。
もちろん、オブジェクトサーバーアルゴリズムが常に最も効果的に通信を構築できるとは限りません。また、アーキテクトが意図した方法でまったく構築されないこともあります。 通信からオブジェクトを強制的に包含または除外するために、特別なパラメーターもあります。 さらに、接続ツリー内のオブジェクトの存在を示すだけでなく、接続の本質をより深く説明することが必要になることがよくあります。 この場合、ツールを使用すると、DBMS構文の特別な条件をツリー構築アルゴリズムに入力できます。
アーキテクチャのタイプに応じて、データの保存と表示が異なる場合に変形が可能です。 つまり データベース内の一部のオブジェクトの正確な投影ではない仮想オブジェクトがあり、データベース内に独自のテーブルさえない場合があります。 これは、単なるエイリアスオブジェクトよりも多少幅があります。 たとえば、計算可能なオブジェクト。同じストレージ内の他のオブジェクトのフィールドに基づいてコンテンツが動的に計算されるフィールドを含むDBMSのVIEWエンティティに類似しています。
結論
この記事の目的は、制御システムを開発する際に、データベースに含まれるテーブルとそれらがどのように接続されるかだけでなく、それらを操作するためのツールも提供されることを考える方がよいことを示すことでした。 これと同様に、Webアプリケーション開発者は時間を節約できます。 このアプローチにより、他のオブジェクトとは独立して各オブジェクトの個別の設定を使用して、大規模で拡張性の高いデータ構造を構築できます。 そして、ここでのポイントは、データを美しくラップする方法だけでなく、データへのアピールを単純化する方法でもあります。
エピローグ
説明されているスキームは、Webプロジェクトの開発のために1年以上ADVによって使用されている1つの閉じたMozartフレームワークに実装されています。 一般的に、このツールはその存在を完全に正当化します。なぜなら、ウェブサイトを作成するときこそ、最も重要なルーチンが単純化されるからです。 さらに、新しい人がその本質を理解し、トレーニングからプロジェクトの直接開発にすぐに着手することは非常に簡単です。
近い将来、Mozartは無料ライセンスの1つでオープンソースコードとともに公開される可能性があります。