プログラムプロパティを持つデータ構造

ご存じのとおり、データベースは構造化された情報のリポジトリであり、本質的に受動的です。 アプリケーションのビジネスロジックは、「望ましい結果を達成するための一連のアクション」の形式で、データベースの外部のどこかに実装されます。 格納されたデータセットに変更が加えられた場合、結果はデー​​タベースの新しい状態になります。 短い形式では、イベント→{アクション}→結果のように書くことができます。 この表現を「イベント」→「ルール」→「結果」に変更し、何が起こるかを確認します。



自動化ドメインが相互作用する値のシステムである場合、ERモデルで記述できます。ERモデルは、データ クラス 、 クラス属性、クラス リレーション 、および属性リレーションシップの 4つの抽象エンティティのみのインスタンスによって形成されます。 このようなモデルは、データベースの論理構造を形成するだけでなく、本質的には前述の抽象エンティティのメソッドによって形成されるコンピューティング環境にあるプログラムのすべてのプロパティを備えています。



最も一般的な定義から始めて、この大胆な声明をより詳細に検討しましょう。 （少なくとも、使用されている用語の意味を示すために、以下のよく知られた繰り返しが必要です。他の理論的な資料のように、乾いていて退屈です。少し復活させるために、テキストに例を挿入します。）



情報の観点からは、 相互に作用する値のシステムとして、ほとんど客観的に存在するサブジェクトエリアが考えられます 。 すぐに、単一の値がデータオブジェクトの特定の特性として存在するため、単一の値が独立または自給自足になることはありません。 したがって、特定の状態のサブジェクト領域を正確に説明するには、値を持つデータオブジェクトの完全なセットが必要です。 同時に、同じタイプのオブジェクトはデータクラスによって記述され、このクラスの派生インスタンスとして存在します— クラスオブジェクト 。

クラスと属性

データクラスは、検討中のサブジェクトエリアの個別の概念的本質を表し、このエンティティのカスタム名によって特徴付けられます。 また、概念エンティティには、独自の特性/プロパティの一意のセットがあります。 クラス属性は、エンティティの個別の特性を表し、この特性のユーザー名によって命名され、許容値のセット（ドメイン）を定義するタイプを持ち、クラスオブジェクトの特定の特性値のファクトリとして機能します。



したがって、データクラスは属性セット（クラス）を所有し、タプル形式で保存します。 オブジェクトのファクトリとして機能するクラスは、 値の タプルの形式でオブジェクトのコンテンツを形成します 。 値のタプルは、属性のタプルから派生したインスタンスです 。 さらに、 クラスオブジェクトの値のタプル内の各値は、対応するクラス属性から派生したインスタンスです。



したがって、値を持つオブジェクトのセットとして存在する非常に特定のサブジェクト領域は、属性を持つクラスシステムによって抽象化レベルで記述されます。 また、データとメタデータはオブジェクトデータベースに格納される永続的なデータ構造です。

クラス関係

データオブジェクトの通信の実装の基礎は、対称性の原則です。 この原則に従って、リンクされたオブジェクトは相互に識別子を交換します。 オブジェクト識別子（ IDO記述子）は、物理データベース内でグローバルであり、単純な整数です。



抽象化のレベルでは、オブジェクトの関係はクラスの関係によって記述されます 。 リレーションシップ宣言は、リレーションシップによって接続された2つのクラスのそれぞれに属性を作成することで実装され、相互にアドレス指定します。 リレーションの各属性は、リレーションの反対側のクラスによってタイプされます （各クラスは独立したユーザーデータ型と見なされます）。その結果、参照属性の値のドメインは反対側のクラスのオブジェクトの記述子のセットになります。



クラス関係は、これらのクラスの派生オブジェクトの定量的相互作用の尺度を確立します。 この定義の単純さのために、関係には非常に多様な機能的振る舞いと相互の論理的依存性があるため、この広範なトピックは個別に検討されます。



それまでの間、一対一に関しては、両方の参照属性が完全に等しく、データオブジェクトの値が通信パートナーの唯一の記述子になることに言及する価値があります。 多対1の関係では、属性は明らかに等しくありません。保存された値の形式でも、値が生成される順序でもありません。 多側で属性[ direct link ]の値がまだ唯一の記述子である場合、側-oneでは、リンク対称性を厳密に観察した結果、属性[ back link ]の値は記述子のセットになります。これはキーと値のタイプのリストです。 この場合、バックリンク属性の値は、直接リンク属性の値から導出されます。 このプロダクションを実装するメカニズムについては、以下で詳しく説明します。

属性の関係

意味の相互作用は、それらの因果的な機能的関係を指します。 この接続は、概念レベルの抽象化でのみ存在し、2つの属性の仮想コネクタの形式を取ります。 クラス関係との類推により、属性関連付け宣言は、それぞれ独自の属性に属し、 ソケットtupleに配置される2つのソケット（TCPソケットと並列が非常に適切です）を作成することによって実装されます 。



属性の側から接続プロパティを記述する別個のソケットは、クラスおよび属性と同じ抽象化レベルの永続データ構造です。 関係属性と同様に、コネクタを構成するソケットは相互にアドレス指定しています。 これらの目的のために、ソケット宣言には、コネクタの反対側のソケットの複雑な識別子（ クラス+属性+ソケット ）が含まれます。 また、ソケット宣言には、コネクタを介した値の送受信を制御する一連のフラグが含まれています。

タプル

論理的には、タプルは、一定数のデータバイトを含む同種の（タプルの観点から）要素の単純な列挙です。 内容の知識とその形成方法はタプルの外側にあります。 車列は、配置と長期保管のための場所を提供するだけです。 タプルの内部実装の機能は、 ここで考慮されました 。



タプル要素は、タプル内のその場所（シリアル番号）によって一意に識別され、変更されることはありません。 タプルに追加されると、新しい要素がその場所を完全に引き継ぎます。



タプル要素の内容は、単一値または別のタプルのいずれかです。 これにより、タプルがオブジェクト表現の主要な（そして唯一の）構造形成コンポーネントになります。 たとえば、クラス宣言は、要素がクラスプロパティであるタプルであり、その1つはクラス属性のタプルです。



タプルには独自のインスタンスを作成する機能があります。インスタンスは、要素にコンテンツがない空のタプルです。 この機能は、たとえば、後続クラスを作成するとき、および派生オブジェクトを作成するときの両方で、クラスによって使用されます。派生オブジェクトでは、対応するタプルの要素番号の一致によって属性と派生値の相互識別が保証されます。

識別システム

タプル内の要素が占める場所の不変性は、オブジェクトエンティティの内部識別システムの中心にあり、その最も一般的な形式は次のようになります。









各エンティティは、その記述子（対応するタプル内のシリアル番号）によって識別されます： IDC-クラス、 IDA-属性、 IDS-ソケット、 IDO-オブジェクト（論理的には、オブジェクトのDATもタプルと見なされる必要があります）。 また、ロジックは、クラスがタプルの要素であり、その特定の所有者がクラス関係に関する記事で検討されていることを示唆しています。

モデルとメタエンティティ

注目すべきこと-抽象化のレベルでは、このレベルのさまざまなエンティティによってすぐに2つのモデルが形成されます。



格納されたクラス宣言、 属性、およびソケットのコレクションは、データモデルを形成します 。 データモデルは、それを形成するエンティティがデータレベルに関連してオブジェクトのファクトリ（クラス）および値のファクトリ（属性）の機能を実行するため、 エグゼクティブと見なされます。



アプリケーションモデルは仮想であり、データモデルの表現として存在します。 アプリケーションモデルは、 ビジュアルコンストラクターによって動的に作成されます。 ビジュアルコンストラクターは 、それを使用して既存のデータモデルを表示し、アプリケーションモデルの新しいエンティティを作成することで新しい宣言を作成します。 アプリケーションモデルの形成では 、実際のクラスおよび属性とともに、 関係やコネクタなどの仮想エンティティが参加します。 仮想エンティティは、保存された宣言を形成しませんが、属性とソケットの宣言から動的に作成され、それらの存在の事実を部分的にカプセル化します。 アプリケーションモデルの仮想的な性質はそれをプライマリドメインモデルとして考えることを妨げません。



同様に、抽象化レベルの上記のマテリアルおよび仮想エンティティはすべて、さらに高い抽象化レベル（ メタ定義のレベル）のオブジェクトエンティティのインスタンスです。 meta-tuple 、 meta-class 、 meta-attribute 、 meta-relation 、 meta-socketおよびmeta-connectorなどのエンティティは 、このレベルで構造的およびプログラム的に実装されます。



両方のモデル（データとアプリケーション）を作成および変更するすべての構築メソッド、およびオブジェクトとデータレベルの値に適用されるデータモデルで使用されるすべての実行メソッドは、メタ定義レベルのエンティティに属していることを再度強調する価値があります。 アプリケーションのビジネスロジック全体の作成と実行を保証するモデルのレベルは、メタエンティティの宣言的なインスタンスによってのみ形成され、実行可能なコードは含まれません。

実行方法

メタエンティティのインスタンスが作成され、それらのプロパティの1つまたは別の値が再定義される構築方法は、かなり明白であり、コメントを必要としません。 これは、悪名高いコンピューティング環境を構成する実行方法については言えません。外部の影響により、データモデルの形式で宣言されたルールに従ってデータの状態が変化します。 実際、実行メソッドの呼び出しは、このような外部の影響です。 そのようなメソッドには、 Create 、 Set 、 GetおよびUpdateの 4つがあります 。



Createメソッドはメタクラスに属し、派生クラスオブジェクトを作成するために使用されます。 メソッドパラメータは、ターゲットクラスのIDCハンドルです。 Createメソッドは、指定されたクラスの属性タプルのインスタンスとしてオブジェクトを作成し、次の空きIDO記述子のDAT割り当てテーブルに登録します。



属性メソッド： Set 、 Get、およびUpdateは、メタ属性に属し、データオブジェクトの値を操作できます。 Setメソッドは値の割り当てを担当し、 Getメソッドは値のフェッチを担当し、 Updateメソッドは属性をトリガーして、格納された派生値を再形成するイベントです（このアクションの意味は、後ほど明らかになります）。



属性メソッドの場合、ターゲットオブジェクトはIDO記述子によって識別され、ターゲット値自体は、クラス属性（データモデルのIDC + IDA記述子で示されるパス）を介して排他的に使用可能です。 つまり、値に対するすべてのアクションは、クラス属性に代わって実行されます。 属性メソッドを実行するプロセスの特徴は、同じ名前のフラグがソケットに設定されている場合、その過程で各メソッドが属性タプル内のソケットに頼り、コネクタによってアドレス指定されたターゲット属性に対して同様のメソッドを呼び出すことです。



Create 、 Set、またはUpdateの3つのメソッドのいずれかを実行するとデータの状態が変わるため、それらの呼び出しはトランザクションセッションのコンテキストでのみ可能です。 これらの3つのメソッドのいずれかを呼び出すと、データベースへの原子的な外部の影響が生じます。これは、トランザクションフォーマットに簡単に形式化され、その後のジャーナルへの保存が行われます。



属性メソッドの実行のロジックをもう少し詳しく検討してください。

値の割り当て

そのため、アドレスパラメーターが渡されたSetメソッドと、割り当てられた値（ * value ）へのポインターが呼び出されました。 このメソッドの本体では、属性は新しい値を形成し、オブジェクトのタプルの対応する要素に割り当ててから、タプルからソケットの順次検索を開始します。 Set [ S ]フラグが設定されている各ソケットについて、ソース属性は、ソケット宣言でパスが指定されている属性のSetメソッドを呼び出します。 メソッドの実行は、新しい値が保存されている値と等しい場合、ソケットタプルをバイパスせずに、スケジュールより早く完了できることに注意してください。









Setの派生呼び出しを行うことにより、属性は分離の原則に従います-結果を心配することなく、「ショットと忘れ」。 イベントのさらなるコースは、他のアクター属性によって既に決定されています。 同時に、重要なことは、実行のトランザクションの性質により、変更の量や「範囲」に関係なく、すべての変数値の永続的な一貫性が保証されることです。



アカウントと請求書の寿命の例を使用して、派生値の形成を検討してみましょう。









この図では、等高線矢印は値のユーザー入力を示しており、これはSetへの外部呼び出しでもあります。 数量属性または価格属性の値の変更はすべてSum属性にアクティブに転送されます。Sum属性は、 機能を使用して派生値（この場合は乗法的値）を生成します。



機能は（値のタイプごとに）事前定義されたメタ属性メソッドであり、1つ以上のソース属性からコネクターを介して受け取った引数値を変換することで結果値を生成できます。 属性には、その記述子（ IDF ）を割り当てることで機能が割り当てられます。これは、機能の一般的なリストのシリアル番号です。



関数が属性に割り当てられている場合、属性アドレスへのSetおよびGetへのすべての呼び出しは、必要に応じて、ソースの追加ポーリング（ Get ）とともにこの機能によって処理されます。 注：呼び出しのソースをポーリングから除外するために、呼び出しのアドレス部分（ IDC + IDA ）には、宛先ソケット（ + IDS ）へのハンドルも永続的に含まれます。

依存コネクタ

上記の例の両方のコネクタは、単純な無条件の形式で使用されました。



一方、コネクタの機能的な動作は、元のコネクタの一種の「 実行コンテキスト 」を形成するサードパーティの属性の有効な値に依存するようにできます。 属性コンテキストとの通信を実装するために、ソケット宣言は、3つの追加のいわゆる「 コンテキスト 」ソケットに対処する可能性を提供します。 各コンテキストソケットには、 ブロッキング （ lock ）、 参照 （ ref ）、およびキー （ key ）の、厳密に固定された独自の目的アスペクトがありますが、同時にこれらは「 基本 」コネクタソケットとまったく同じメタソケットインスタンスです。 各コンテキストソケットをベースにアドレスするには、 IDA + IDSの 2つの記述子で十分です。









ブロッキングロックソケットを使用すると、返される値が関連する場合は値をコネクタ経由で送信でき、そうでない場合はブロックします。 実際には、ソケット所有者属性（ ロックコンテキスト ）の初期化された値を参照します。これは、そのタイプの観点でも評価されます ：論理ではtrue 、数値ではゼロではなく、文字列には少なくとも1つのリテラル（スペースに加えて）が存在します。



参照refソケットは、異なるクラスの属性を接続する外部コネクターで使用されます。 クラス内の対応する関係属性（ ref context ）を値ソースとして使用して、別のクラスのデータオブジェクトにIDO記述子記述子を提供します。



「 key 」 キーソケットはコネクタにキー値を提供し、リストの操作を実装するために必要です。 デフォルトでは、クラスのベース属性がキー値のソースとして使用されます（ キーコンテキスト ）。



参照の詳細と重要な側面を考慮することなく、コンテキストソケットとベースとの相互作用のロジックは、3つのコンテキストすべてで同じです。 そのため、コネクタの両側のベースソケットは、現在のSet |の実行をすぐに中断します。 現在の（つまり、実際に宣言され、関連性を保持している）コンテキストの少なくとも1つに関連性のない値が含まれている場合、 Get 。 つまり、 refコンテキストとキーコンテキストは、 ロックコンテキストプロパティも永続的に所有します。 任意の型の値を論理型に変換できることを思い出せば、これは驚くことではありません。

ソケットメソッド

条件付きコネクタは 、メタソケットに属する2つの内部実行メソッドResetおよびUnsetのいずれかを呼び出すことにより、そのコンテキストから開始されます。 これらのメソッドは、次の規則に従って、コネクタのベースソケットのアドレスへのSetメソッドの実行中にコンテキスト属性によって呼び出されます。 属性の現在の値が関連する場合、属性が変更される前に、属性はUnset [ U ]フラグが設定されているすべてのソケットに対してUnsetメソッドを呼び出します。 次に、新しい値を割り当てた後、派生Setメソッドを呼び出すタプルの走査の繰り返しサイクルで、属性はReset [ R ]フラグが設定されているソケットに対してResetメソッドを呼び出します。 言い換えると、属性は、実際の値の初期化解除を最初に模倣し、その後の属性の外部環境へのすべての結果を模倣してから、新しい値で初期化します。



次に、 Unset |を実行するときのベースソケット 。 Resetは、独自の属性所有者の値の初期化解除（Unset）または外部値での初期化（Reset）をシミュレートする一連のパラメーター（現在のコンテキストの現在の値を含む）を使用して、コネクターの反対の属性のアドレスにSetメソッドを呼び出します。 Setメソッドのパラメータ部分で、値へのポインタを1つではなく、2つ（変更前の値と新しい値）に渡す場合、このような模倣を実装することは難しくありません。 次に、 Unset |から派生したSetのパラメーターで Reset 、ポインターの1つは常にNULになります。



より明確にするために、例で述べたことを説明します。

実行例

次の例の参照refアスペクトの使用を検討してください。Total属性の請求書は、すべてのレコードのSum属性の値を一般化します。 以下、同様のスキームでは、垂直線はクラスの関係によって接続された空間を分割し、その上の突起はクラスの量的相互作用の尺度を多対1で示します。 この例では、 多くがRecordです。









[H]属性は、 レコードと請求書の関係の直接リンク属性です。 関係が実装されている場合、この属性はInvoiceオブジェクトのIDO記述子を値として受け取ります。



変更があると、 Amount値はTotal属性にアクティブに転送されますが、コネクタのベースソケットはref refソケットの宣言を使用して[H]属性にアクセスします。 抽出されたref値は、 Total属性のアドレスに呼び出されるSetメソッドのアドレスパラメーターとして（ターゲットオブジェクトへのポインターとして）使用されます。 リレーションが実装されていない場合、派生セットは呼び出されません。



値が[H]属性で受信されると、 Resetメソッドによる後者は、 Setメソッドを呼び出すためにベースソケットを開始します。その重要なパラメーターは、NUL→[ Amountの現在の値]です。 その後、値[]の初期化を解除する（リレーションを解除する）場合、 Unsetメソッドを使用する属性は、パラメーター[現在の値]→NULでSetメソッドを呼び出すベースソケットを開始します。 その結果、 Amountの現在の値は、 Total属性の現在の値から「撤回」されます。



注： 加算属性の機能的Totalは、結果の値を正しく変更し、attribute-argumentの値の入力変更を受け取ります。 いわゆる「遅延」計算の特徴であるこの動作は、すべての自然な関数の実装の中心にあります。 特定の例に関連して、 Total属性は、いずれかを変更するときにすべての部分的な金額の Getポーリングに頼る必要はありません。変更のサイズと方向を考慮するだけで十分です。



例に戻ると、以前に参照された属性[H]が新しい値を受け取った場合（ レコードが1つの請求書から削除され、別の請求書に含まれる）、この属性は変更前にUnsetを呼び出し、変更後にResetを呼び出します。 これにより、最初の請求書の 合計から記録金額が削除され、 2番目の請求書の合計に追加されます。 外部の影響の任意の組み合わせにより、システムは値の論理的一貫性を永続的に保持します。



ブロックの側面の動作を説明するために、前の例を補足します。各商品アイテムに固定割引を提供し、手動でオフにすることができます。









ブロッキングサブコネクタの作成がコンストラクターで手動で行われる場合、異なるクラスの属性が外部コネクタによって接続されると、すべての参照サブコネクタの宣言が自動的に作成されることに注意してください。 さらに、すべての例で、参照サブコネクタは示されていません。 また、どのタイプの値も自動的に論理値に縮小されるため、どの属性もブロッキングコンテキストとして使用できることに注意してください。



次の例は、コネクタの主要なコンテキストの操作を示しています。Recordクラスのオブジェクトは、 通貨レートのリストを形成し、この通貨を使用してExchange オペレーションを実行するために使用されます。







RecordクラスとOperationクラスのDate属性はキーソースであり、対応するコネクタのキーコンテキストです。



CurrencyクラスのCourse属性は、 Dateペアによって形成されたリストを格納します： Courseは、 Recordクラスからコネクタを介してアクティブに（ Setメソッドを使用して）渡される値から属性に割り当てられたリスト機能によって形成されます。 SetメソッドとGetメソッドのパラメーター部分では、キー値へのポインターの下に別の場所が永続的に割り当てられることに注意してください。



Operationクラスでは、 DateメソッドをGetメソッドのキーとして使用するCourse属性が、リストから対応する値を抽出します。 この場合、 Get自体は、値の変更によって生成されたアクティブなResetメソッドによって開始されます。Date属性または参照属性、 Currencyオブジェクトへのポインター（対応する参照属性は図に示されていません）。

コネクタアクティビティ

注意：前の例では、コネクタ通貨[通貨]→通貨[操作]は、ソース属性側で[ S ]フラグが設定されていないため、アクティブではありません。 したがって、コースのリストへの変更は、既存のOperationsに積極的に変換されません。 ただし、いずれかのコネクタコンテキストの値を変更すると、条件付きで「アクティブ化」されます。これは、アクティブメソッドReset | 設定解除 Get自体はパッシブですが、それによって返される値は、 日付または通貨参照を変更するための元のトランザクションの実行中にCourse属性に割り当てられます。



[ S ]フラグを保持するコネクタは断然アクティブなコネクタです。自身のアクティビティを奪われているが、アクティブなコンテキスト（コンテキストソケットの[ R ]および[ U ] フラグで示される）を持っているコネクタは、以下セミアクティブコネクタと呼ばれます。Get



フラグのみを持つコネクタは、パッシブコネクタと見なされます。コネクタがすべてのフラグをリセットする場合、これはモデルからの完全な削除に相当します。そして、注意してください：前述の、ただし値転送のベクトルなどのコネクタの重要なプロパティを決定するのはGetフラグです。

論理的一貫性

実行のトランザクションの性質により、アクティブなコネクタは、関連付けられた属性の値の永続的な論理的一貫性を提供することが保証されています。



ただし、アクティブなコネクタは常に適用できるとは限りません。ただ、上記の例の中に値が為替レートに与えられたコース。[操作]は、最後トリップコンテキストの時にソースと合意されます。また、特定の日にコースのリスト内のコースの値（Course。[Currency]）が変更された場合、この変更自体はトランザクションのコースの保存値に影響を与えません。



さらに、緊急事態についても忘れないでください。たとえば、attribute-argumentsの値が生成された後に機能的に依存する属性が作成される場合。この場合、更新を使用して強制的にのみデータの整合性を復元できます。

更新イベント

meta属性に属するExecutive Updateメソッドは、値の一貫性を強制的に復元することを目的としています。指定されたデータオブジェクトの属性アドレスに対してこのメ​​ソッドを呼び出すと、現在の属性引数の値から保存された値を属性が強制的に再形成されます。実際には、値の不一致が適用された問題の実装のための条件とルールの結果である非常に特定の状況があることに注意する価値があります。これらの状況では、Updateメソッドをリアルタイムイベントツールとして使用する必要があります。



適用されたタスク。たとえば、選択された瞬間の外部イベントによって何らかの派生値を形成し、この状態でそれを修正する必要があります。

逆の値

数量と価格が積極的に合計を形成する最初の例では、次の事実に注意します。数量と価格とは異なり、Sum属性は外部入力によって外部から値を取得できません。この明示的な禁止は、データの一貫性と一貫性の要件によるものであり、現在の引数に対応しない一般的に任意の値を入力すると明らかに違反します。したがって、アクティブな外部コネクタが存在する場合、属性は編集可能な派生値をインターフェイスする機能を自動的に失います。



一方、この機能は、属性が入力された値を引数属性の1つに反転できるようにすることで復元できます。言い換えると、補正値の受信者、つまり、逆方向が実行されるコネクタを選択する必要があります。この例では、図に示すように、Getソケットで対応する[ S ] フラグを設定することにより、Sum側からSetメソッドを呼び出すことができるコネクタに対して、価格属性が修正の受信者によって選択されている場合は論理的です。









値の逆方向の送信の実際のエグゼキューターは、常に補正値を計算するための適切なアルゴリズムを持つ属性関数です。 [ S ]および[ G ] フラグが同時に設定されているソケットを介した送信のターゲット属性を定義します。



値の逆は、外部から値を受け入れる機能を持つ属性のアドレスに実装できます。これには、逆を有効にすることでこの機能を受け取った属性も含まれます。







外部から入力を受け取ると、Total属性は、バックリンクのリストを使用して、すべてのオブジェクトWorkの属性Sumへの変更をバックリンクのリスト（refコンテキスト）に逆分配します。上記の例には実用的な意味がないとは思わないでください。ここでは、作業コストは顧客が発表した最大額に調整されます。ただし、値の分布の別の例を、また逆のメカニズムに基づいて与える価値があります。









各クラスで、Clock属性はリバーシブルコネクタのキーコンテキストとして使用されるため、Sum値の比例配分の基本値が提供されます。

ソケット反転

ソケットには逆プロパティがあり、これはInverseフラグを設定することで有効になります。このプロパティのセマンティックの目的と用途は、コネクタの異なる側のソケットによって異なります。



したがって、逆フラグが発信ベースソケットまたはコンテキストソケットに設定されている場合、このソケットを介して送信される値は反転します。正の数は負になり、論理値は逆になります。









受信（Get-）コネクタソケットに逆フラグを設定すると、属性機能の動作が変わります。したがって、逆ソケットを介して取得された値、数値の乗法関数は、因子ではなく除数と見なされます。同様に、逆ソケットを介して受け取った値は、加法関数によって減算されたと見なされます。

関係の実装

最も注目に値するのは、コネクタモデルもデータモデル自体の内部ニーズを満たすために完全に活用されていることです。特に- クラスの派生オブジェクトの識別子の相互交換を実装するには、これらのクラス間の関係の宣言のフレームワーク内で、参照対称の要件に従います。クラス関係を構成する参照属性は、明らかに直接因果関係にあり、データモデルではコネクタ宣言によって表されます。



コネクターに加えて、いわゆるサービス属性も関係の実装に使用されます。特定の実用的な機能を実行するこれらの属性は、メタクラスのタプルで直接宣言されるため、各ユーザークラスのタプルに存在します。参照コネクタ



の値のソースは、Ownユーティリティ属性です。この属性は、独自のクラスへのハンドルによって入力されます。クラスが派生オブジェクトを作成すると、このオブジェクトのIDOハンドルがOwn属性の値として保存されます。別のユーティリティ属性はDelであり、これはデフォルトでロックとして使用されます。



例外なく、異なるクラスの属性をバインドする発信外部コネクタのすべてのコンテキスト。この宣言は、削除されたオブジェクトの適切な動作、つまり、他のクラスにローカライズされた属性受信者の値から属性引数の値を削除（Unset）することを保証します。



実際、リンク属性自体はアクティブなリンクコネクタのrefコンテキストとして機能し、ターゲットオブジェクトのIDOを提供します。



バックリンクのリストの値は、キーと値のペアから機能するリストによって形成されます。値は、直接リンクのオブジェクト所有者のIDOであり、キー（key-context）デフォルトでは、クラスのベース属性が使用されます。したがって、バックリンクのリストの形成は、ロックコンテキストDelおよびrefコンテキスト[B]も存在するが、図には示されていない上記の例のコースのリストの形成と本質的に違いはありません。









サービス属性とリンクコネクタを含むこの構造全体が、関係コンストラクターによって自動的に作成されることをもう一度強調する価値があります。

コネクタ機能

コネクターのソケットにはUnset / Resetメソッドがありますが、コネクターには独自の機能はありません。属性を論理的にリンクするコネクタは、派生値の因果関係の存在と性質の単なる宣言です。この非常に依存性の実装は、属性メソッドによってのみ実行されます。したがって、コネクタの機能は、コネクタによって記述された依存関係の複雑な宣言プロパティとして理解される必要があります。



純粋な仮想エンティティであるコネクタは、メタソケットインスタンスで構成されています相互アドレス指定によって論理的に相互接続されています。したがって、宣言された属性の依存関係の性質は、コネクタを構成するソケットの組み合わせと、単一インスタンスのフラグの設定の両方によって決定されます。個別のソケットを4つの他のソケットに接続できます。各ソケットは、基本（反対）（ベース -）、ブロッキング（ロック -）、参照（ref-）および追加（キー -）という厳密に明確な機能的側面を持っています。従って、メタソケットの特性のアドレス部分は、の点で3つのルートを含むIDA + IDE + IDS（記述子意味IDEをそのポインタに後で明らかになる）、塩基ソケットにはIDC記述子が追加されます。：プロパティメタは、その伝達関数を定義する5つのフラグ含むソケットSら、Gら、R ESET、U NSETを、I nverse。



前に言及していませんが、メタソケット宣言にはIDF機能記述子も含まれています。この属性により、唯一の方法で値を形成できるため、着信ソケット（Get-）このプロパティは使用されません。ただし、出力ソケットは、複雑なコネクタのコンテキストソケットと同様に、属性の保存された値だけでなく、機能を通じて受け取った変換値も使用できます。

値の選択

前述のすべての例で、クラス属性は、クラスオブジェクトのタプルでデータベースに格納されている永続的な値で動作することがデフォルトで想定されていました。派生値の長期保存の事実により、そのような属性をstaticとして特徴付けることができます。静的属性の場合、属性に着信コネクタがあるかどうかなど、他のすべての条件に関係なく、Getメソッドの実行によって実装されるデータサンプリングは、格納された値を取得して返すだけになります。



この規則には小さな例外が1つあります。この例外は、保存された値が何らかの理由で初期化されていない静的属性に適用されます（たとえば、「バックデート」と呼ばれる属性が作成された場合）。この場合、この方法は、取得由来ポーリング受信コネクタによって返された値を生成する試みを取得します。さらに、そのような値が取得されても、定義による選択ではデータベースの状態を変更できないため、値は保存されません。上記とは少し異なる状況が考慮されました。セミアクティブなGetコネクタでは、アクティブなUnset / Resetが生成され、それによって返される値は自然に保存されます。

動的属性

特定の条件下で、例外が予期せずルールになる場合があります。引数属性への着信コネクタに基づいて動的に生成できる場合、保存された値を使用することは完全にオプションです。このような動作を属性に与えるには、プロパティで対応するフラグを設定するだけで十分です。



サンプリング時、動的属性は、データオブジェクトに存在する場合でも、保存された値を無視し、値を形成するために専用にコネクターによって表現された関数および因果関係を使用します。ポーリング時に、Get [ G ] フラグが設定されているタプルからのソケットに対してのみ、派生Get呼び出しが行われます。









受信コネクタを使用しても、すべての属性を動的な形式に変換できるわけではないことに注意してください。エンティティの基本的な特性、参照値、およびすべてのリストは、静的にのみ存在できます。そして、それを直接または間接的に忘れないでください。しかし、動的属性の値は保存された値から形成されます。



動的属性は保存された値を形成しないため、Set |をリセットすることにより、すべての着信コネクタは強制的に非アクティブなフォームになります。設定解除 | リセットするすべてのソケットで。これにより、動的属性のアドレスに対するアクティブなメソッドの不必要な呼び出しを自動的に排除できます。他のすべての点で、動的属性の動作は前述のすべてのルールと例に対応し、基本的に重要であり、データの無条件の論理的一貫性を保証します。

パフォーマンスバランス

動的属性を使用すると、当然、保存されるデータの量が減りますが、アプリケーションのポイントはこれではありません。ディスク操作を考慮から除外する場合、静的属性のみで形成されたデータモデルでは、サンプル値の実行時間はアトミックトランザクションの実行時間よりも桁違いに短く、その期間は後続の依存関係のボリュームにも依存します。この不均衡は、サンプルとトランザクションの定量的比率によって部分的に補償されます。通常、サンプルは1桁大きくなります。



動的属性を使用すると、アプリケーション開発者は、トランザクション期間を短縮することにより、実行時間のバランスをサンプル期間の延長にシフトできます。実際、特定の属性が他の属性の特定の値セットの値を一般化する場合、このセットを変更するすべてのトランザクションでそれを行います。また、この属性が非常にまれなレポートで使用される場合、それを動的な形式に変換するすべての理由があります。

値の配列

派生属性値は、単一（アトミック）値またはタプル形式の類似した値のセットのいずれかで、単純配列（列挙）と見なされます。概念エンティティの特性の値としての値の配列の概念が最初に存在したことに注意してください。これは、その使用がターゲットドメインのデータモデルのより正確な対応にすぎないことを意味します。



属性プロパティでの配列の宣言とその実装もタプルの形式を取り、その要素には配列の要素のカスタム名が含まれます。名前のタプルが初期化されていない場合、これは属性が単一の値で動作し、アトミックと見なされることを意味します。それ以外の場合、属性は列挙型と見なされます。属性を作成するとき、最初に選択され設定されるのは、派生プロパティの存在の形式を決定するこのプロパティです。列挙されたフォームを選択すると、2つの要素がすぐに作成され、デフォルトでは単純かつ単純に「1」と「2」という名前が付けられていると仮定するのは論理的です。



属性宣言と値の配列の両方で配列の単一の要素を識別するために、要素のシリアル番号（IDE記述子）が使用されます。この記述子では、統一するために、完全なルートの形式で別の場所が予約されています。これにより、この形式はIDC + IDA + IDE + IDSになります。ルートがアトミックに適用される場合属性の場合、IDE値は単に無視されます。IDEの値が0であるが、ルートが列挙された属性によってアドレス指定されている場合、配列の各値はそのスコープに連続して分類されます。



アプリケーションモデルを作成するとき、属性の列挙形式を使用すると特定の利点があります。そのため、新しい属性を作成する手順は、配列に要素を追加するよりも多少複雑です。しかし、さらに重要なことは、コネクタテクノロジーにより、アレイを使用したいわゆるグループ操作が可能になることです。IDE記述子が配列属性のタプルのソケットプロパティで設定されていない場合 、それを配列の特定の要素に「バインド」すると、このソケットのアクションは配列のすべての要素に等しく適用されます。このルールにより、特に、1つのコネクタで配列から配列に値を転送できます。

値のリスト

リストはキーと値のペアで構成されますが、キー値のタイプと値自体はリストのすべての要素で同じです。これは、backlinksリストとCurrencyの例でその形成のメカニズムを思い出すと驚くことではありません。名目上、キーまたは値自体としての値型の使用に直接的な制限はありません。そのため、バックリンク属性の場合、値はクラスオブジェクトのIDOハンドルです。論理的な表現の観点では、リストは線形で同種であり、キー値が増加する順に並べられています。



すべてのリストは別のインスタンスであり、前述のメタ定義レベルのメンバーではありません-meta-list。メタリストには、リストを管理するためのメソッドの完全なセットがあり、リストの作成、要素の挿入と削除、データの選択、リストの数値特性の取得を提供します。物理的には、リストはBツリーの形式で実装され、そのルート、ノード、およびリーフはメタタプルのインスタンスであり、これらはデータオブジェクトに格納されます。



データモデルレベルでは、メタリストは派生インスタンスを作成しません。代わりに、クラス属性には、リスト機能のファミリーからさまざまな機能が割り当てられます。実際には、メタリストメソッドを使用してリストを直接処理します。。リストの機能は、キーのタイプと値のペアごとに個別に定義されます。これにより、タイプの詳細を考慮するだけでなく、リスト内の値を管理するメソッドのパレットを拡張できます。

値を入力する

値型システムは、祖先型ドメインにそのすべての子孫の値ドメインが含まれる自然な階層を形成します。言い換えると、祖先によって型指定された属性は、必要に応じて後続型の任意の値を取り、その型を表す内部形式に導くことができます。









普遍的な祖先は不定型[ U ]です。実際、これは一時的な型であり、値の存在の形式としてのみ属性を作成できます：アトミックまたは列挙型、遅延型の割り当て。型の不確実性は、任意の長い時間持続する可能性がありますが、そのような属性への着信コネクタを作成すると、モデルコンストラクターはUndefined Typeを自動的に属性引数の型に変更します。次の観点から考えると、どの値も



論理型[ L ]に変換できます。値は実際に存在する-true、または初期化されていない-false。 2番目のケースには、数字のゼロ、文字列のスペースを除く他のリテラルの欠如などの詳細も含まれます。



タイプString [ S ]の場合、値は任意の長さのリテラルのシーケンスです。この場合、エンコードのタイプ（ASCIIまたはUTF）はデータベース全体で同じであり、生成時に設定されます。ただし、必要に応じて、異なるエンコーディングのサブドメイン（サブタイプ）を作成できます。これは、文字列値の格納順序には影響しません。



タイプ数値 [ N ]は小数点計算浮動または固定小数点から見た、全ての実数値を組み合わせます。タイプInteger [ そこから選択されますI ]-正の整数のセット全体。Date [ D ] タイプは、カレンダーシステムの整数です。



入力錯体 [ Cとしても知られる]、タイプユーザー定義 [ UDTは、これらのクラス-ユーザのタイプによって生成された複素値を複数組み合わせ、抽象ドメインのプロトタイプです。クラス値ドメインには、このクラスからの継承によって生成されたすべてのクラスの値ドメインが含まれます。クラスによって形成されるドメインの値は、クラス自体から派生したデータオブジェクトとして、またはそのポインター（IDO記述子）として同等に考えることができます。このオブジェクト。



入力外部 [ EXは全て複数の値ではなく、解釈オブジェクトデータモデル、および既知の長さのバイトの連続配列として格納され、従って、従来考えられて不定型の値を含みます。外部タイプの属性は、トランザクションによる割り当て、長期保存、およびそのような値の選択を実装します。これらの値は、コネクタを介した変換および送信の可能性がありません。Externalドメインの不可欠な部分はImageドメインであり、その値はモデルコンストラクターのビジュアルインターフェイスやアプリケーションインターフェイスで使用されます。

タイプメトリック

タイプNumeric [ N ]およびDate [ D ]の場合、メトリックは値の存在（ストレージ/プレゼンテーション）の精度を決定します。 数値型の場合、精度は小数点以下の桁数です。 日付タイプの場合、精度は、結果の値が整列される結果の属性テンプレートを構成するCYMDhmsテンプレートの文字数です。

プリミティブ関数

既に述べたように、機能はIDF記述子によって識別される事前定義されたメソッドです。 機能の初期セットには、最も基本的ですが、最も頻繁に使用される値の形成方法が含まれていますが、新しい機能を追加することでこのセットを簡単に拡張できます。 値の各タイプには、固有の機能のセットがあります。

- 論理 -加法（論理OR）および乗法（論理AND）。

- 文字列の場合 -加算（連結）;

- 数値の場合 -加算、乗算、最小、最大。

- 整数の場合 -加算、乗算、最小、最大。

- 日付の場合 -加算（シフト）、最小、最大。

- 複雑な -加算（割り当て）、オートセット。



これらのすべての機能により、さまざまなソース（コネクタ）から値を取得できます。 単一のソースからの値割り当て機能の役割は、デフォルトで追加機能によって果たされます。 LogicalおよびExternalを除くすべてのタイプに対して、 リスト関数があります 。 それとは別に、間隔値の形成を保証し、それによって間隔を形成する値の内部依存性と間隔値の操作の両方が実現される間隔汎関数についても簡単に言及する価値があります。 間隔値が複雑で、列挙可能な形式であると想定するのは論理的です。

リスト機能

各リスト機能は、 メタリストをカプセル化し、 メタリストメソッドを使用するラッパー関数です。 メタリストメソッドの一部は、機能が独自の目標と目的のために再定義します。 リスト機能のファミリー全体には、いくつかのグループが含まれています。



リストを作成および変更する機能は、リスト自体、より正確には機能タイプで識別されます。 「 単純な 」リストに加えて、このグループには「 一意の 」リスト（重複キー値を持つことは禁止されています）、および数値で動作する2つの論理変更：「合計」リスト（同じキーを持つ値が合計されます）とその後の変更- 「 整数 」（同じキーを持つ値は、前の要素の値を加算して合計されます）。 これらの機能は、着信機能として属性に直接割り当てられるため、属性はリスト単位で作成されます。 このグループの機能が実際のリストを形成するためには、少なくとも1つの着信アクティブコネクタが必要です-キーと値のソース。



リストから値を返すフェッチ関数は、常にコネクタの発信ソケットに割り当てられ、リスト属性のタプルでローカライズされます。 同時に、受信者属性に対するこのような機能の「添え字」がシミュレートされます。 実際、 キーコンテキスト自体（キーソース）は、このコネクタのベースソケットのいずれかに対して宣言できます。



キーによって値を選択する機能は、配置条件に関して異なります：「 等しい 」（正確な配置）、「 少ない 」（論理的な先行要素に配置）、「 より多く 」（同様に、後続のもののみ）、「 等しいかより小さい 」、および「 等しい 」 以上 （正確でない場合は、前または次）。 条件を満たす要素が存在しない場合、関数は「 空の 」値に相当するものを返します。 値の代わりに、それらに類似した機能のサブグループは、要素の位置-リスト内のシリアル番号を返します。 機能の別のサブグループ（ " first / last / N "-" key / value "）は、リストの最初、最後、または指定された（N）要素からクエリを返します。

ソフトウェア挿入

プリミティブな機能を組み合わせてすべてのタスクを解決できるわけではありません。 属性プロパティに複雑なアルゴリズムを実装するために、属性の特定のインスタンスのプライベート関数として任意のスクリプト（Pythonなど）を配置できるスクリプトコンテナが提供されます。 さまざまなアプリケーションを作成することで、このツールを使用する必要はほとんどないことが予想外に示されました。 静的属性スクリプトの本文で、クラス（ Create ）またはクラス属性（ SetまたはUpdate ）に対応するアクティブなメソッドを使用できることに注意してください。 動的属性スクリプトの場合、 Getメソッドの呼び出しのみが許可されます。

属性機能

クラス属性は、 メタ属性のインスタンスです 。 この属性は、独自のクラス内で一意のカスタム名（ Name ）、値タイプ（ Type ）、メトリックタイプ（ Metric ）、および動的フラグによって特徴付けられます。 さらに、この属性はIDF機能記述子、 スクリプトコンテナー、および2つのタプル（配列要素（ Item list ）とソケット（ Socket list ））を所有しています。 独自のクラスのタプルでは、​​属性はIDA記述子によって識別されます。



データモデルでは 、属性は値のファクトリの機能を実行し、この観点から、オブジェクトデータ管理のコンピューティング環境の中心的なアクターです。 値で操作を実行するために、属性はSet 、 Get、およびUpdateメソッドと、タイプに依存する機能のセットを使用します。



コネクタで接続された属性は、ニューラルネットワークトポロジに似たトポロジを形成します。 出発点を思い出してください-サブジェクト領域は、相互作用する値のシステムと見なされます。 したがって、このようなネットワークの理想的なハードウェアプラットフォームは、シリアルチャネルで相互接続された多くの独立したプリミティブプロセッサのように見えます。 このようなハードウェア環境では、さまざまなプロセスをシミュレートできます。

サービス属性

サービス属性は、クラスのタプルに永続的に存在し、厳密に固定された位置を占めます。 これらの属性は、データモデルが独自の問題を解決するために使用されます。 したがって、前述の属性DelおよびOwnは 、クラスオブジェクトの対称接続の実装を提供します。 前述されていない別のサービス属性はTypeで、オブジェクトの構造タイプをクラスオブジェクトに格納します。これは、ファクトリクラスのIDCハンドルです。

クラス機能

データクラスは、このインスタンスの受信方法に関係なく、 メタクラスのインスタンスです 。 クラスは、クラスの完全なセットで一意のカスタム名（ Name ）、視覚イメージ（ Image ）、および属性のタプル（ Attribute list ）によって特徴付けられます。 クラスの完全なセットでは、 IDC記述子によって単一のクラスが識別されます。 クラスが別の祖先クラスから継承することによって作成された場合、クラスはParentプロパティに祖先クラスのIDCを格納します。



オブジェクト管理のコンピューティング環境では、クラスは、このためのメタクラスの作成メソッドを使用して、オブジェクトのファクトリの機能を実行します。 クラスオブジェクトは、クラス属性のタプルのインスタンスとして作成されます。



オブジェクトの削除は、クラスのドメインではありません。 オブジェクトは、 Delサービス属性の値を初期化することにより論理的に削除されます。これは、論理的な整合性を確保するために、すべての外部コネクタにロックコンテキストとして自動的に存在します。 Delの初期化では、オブジェクトの既存のすべての関係の初期化を解除し、オブジェクトを分離状態にします。 その後、論理的に分離されたオブジェクトは、ガベージコレクターによって物理的に削除されます。

クラス継承

データクラスは、メタクラスのインスタンスとしてだけでなく、別のクラスから継承することによっても作成できます。 継承の対象は、先祖クラスの属性の完全なタプルです。これは、継承クラスの属性のタプルに永続的に存在します。 これにより、祖先クラスは、継承の深さに関係なく、直接および間接の両方の子孫によって生成されたオブジェクトを例外なくすべてそのドメインに含めることができます。 継承されたタプルは、先祖クラスのドメイン内のすべてのオブジェクトへの自然なインターフェースです。



属性タプルの継承を実装するメカニズムは非常に単純です。先祖属性タプルのインスタンス（！）が後続クラスに作成されます。 定義によってこのインスタンスには値が含まれません。属性宣言を複製する必要がないためです。必要な宣言は、先祖クラスのタプルを参照することで取得できます。 後続クラスは、独自のプライベート変更を行った場合、または独自の新しい属性を作成した場合にのみ、完全な属性宣言を生成します。 祖先クラスで新しい属性が作成されると、その子孫の完全なセットで事前に属性タプルの最大サイズが決定され、その後、作成された属性にはこのサイズ以外の祖先タプルの要素が割り当てられます。 したがって、祖先の新しい属性は、すべての継承者が自動的に使用可能になります。 この場合、タプルで形成された初期化されていない要素は、実際には場所を占有しないため、無視できます。



相続人のポリモーフィズムは、継承された属性の値を取得するためのルールを再定義し、そのタイプを保持することによって実装されます。 継承されたコネクタを変更することは禁じられており、必要に応じて非アクティブ化し、新しいコネクタを作成する必要があります。



将来を考えると、複雑なエンティティであるユーザーデータクラスには、さまざまな形式のインターフェイス（視覚的表現を含む）が含まれていることに注意してください。 下位クラスは、祖先の表現形式を完全に継承し、それらをオーバーライドする可能性があります。 多型と多型の自然な組み合わせは、強力なアプリケーション開発ツールです。

基本属性とクラスのプロトタイプ

クラス属性の総質量では、クラスCounterpartyの Name属性など、このクラスの特定のオブジェクトのユーザー識別に使用される値を持つものをいつでも選択できます。 このような属性は、クラスの基本属性として機能します 。



バックリンクリストを含む機能を一覧表示するためのコネクタのキーコンテキストとして自動的に使用されるのは基本属性であると想定するのは論理的です。 これを行うには、ベース属性のクラスのタプル内の位置が固定されている必要があります。つまり、サービス属性の直後に配置されている必要があります。



既存のすべての値タイプのうち、作成時にベース属性に有意に割り当てることができるのは、 文字列と日付の 2つのタイプのみです。 これらの2つのタイプの型は、2つのプロトタイプクラスの存在を事前に決定します： NamedクラスとEvent クラス 、および対応する基本的な属性。



開発者がカスタムクラスを作成する際に、プロトタイプクラスをテンプレートとして使用すると便利です。これは論理的に見えるだけでなく、少しのメリットもあります。作成されたクラスには、必要な名前の目的のタイプのベース属性がすぐに含まれます。

モデルコンストラクター

既に繰り返しテストされています-マウスで通常のプログラムを作成することはできません。 アプリケーション/データモデルを使用する場合、逆のことが言えます。テキスト表記は、単調で、ほとんど情報のない宣言のリストのように見えます。 しかし、視覚環境では、同じ宣言は自然で非常に明白に見えます：リレーションによって接続されたクラスの全体または部分的に表示された共通スペースがあり、クラスの視覚スペースへの移行は、その接続で多くの属性を開きます。 ただし、インターフェイス表現の原則とその実装のメカニズムは、別の記事のトピックでもあります。



エグゼクティブデータモデルは、そのプレゼンテーションフォーム（アプリケーションモデル）を介して作成および変更されます。 このモデルのエディターは、モデルエンティティの画像を操作するビジュアルデザイナーです。 アプリケーションのユーザーインターフェイスからデザイナーのビジュアル環境に切り替えて、インターフェイスの現在の状態を維持しながらアプリケーションランタイムに戻ることは、ホットキーと同時に実行されます。 さらに、デザイナーが行ったすべての変更はすぐに有効になります。 何かが間違っていると、すぐに明らかになります。アプリケーションを中断することなく、誤った結果やインターフェイスイベントへの反応がないという形で。



コンストラクターは、派生したインスタンスの実際の記述子を完全に隠しながら、メタエンティティの宣言的なインスタンスとして新しいモデルコンポーネントを作成します。 基本的なメタエンティティの初期セットは小さく、競合するエディターツールまたは構築コンポーネントをアクセスから除外するだけで、モデルに既に存在する新しく作成された宣言の論理的な一貫性を簡単に制御できます。



現在のデータモデルは、エンティティプロパティの形式の単純な宣言です。つまり、テキスト形式（XML、JSON、またはコンポーネントを作成するための一連のトランザクションの形式）にエクスポートできます。 内部記述子はテキスト表現にエクスポートされず、代わりにカスタムクラスと属性名が使用されます。

応用分野

データモデルは状態がある情報 システムを説明します 。 したがって、たとえば、ドライバの実装には使用できません。



また、その助けを借りて、別個のアルゴリズムまたはサブルーチンを実装することはできません。データモデルは、サブジェクトエリア全体を記述するだけです。



（適切なハードウェアがないため）パフォーマンス上の理由により、データモデルを使用して物理プロセスをリアルタイムで直接シミュレートすることはできません。 そのような可能性はありますが。



「世界のすべて」の普遍的なモデルを作成する試みは無意味であるようです。 アプリケーションプログラムは、厳密に定義された観点から、特定の境界内でのみ常にサブジェクトエリアを反映します。 また、別の観点では、同じサブジェクト領域が異なって見える場合があります。



他のすべての点で、データモデルに基づくコンピューティング環境は、他のすべてのデータベースに基づいて解決される同じ問題を解決するように設計されています。 ただし、いくつかの便利なプロパティが異なります。



同意します。アプリケーションの視覚モデルは、ビジネスロジックをより視覚的に認識します。



リンク対称性により、データとメタデータの両方で、自然なナビゲーション方法のすべての機能を使用できます。



アプリケーションを形成するエグゼクティブデータモデルは、データベースに格納された単なる宣言であり、プロセッサアーキテクチャまたはオペレーティングシステムのいずれからも完全に独立しています。



開発速度、アルゴリズムの信頼性、厳格な参照整合性、永続的な一貫性-これらはすべて、ビジネスロジックをデータベースの論理構造に直接統合した直接的な結果です。 同時に、アプリケーションインターフェイスの実装へのアプローチは根本的に変化しており、個別の詳細な検討が必要です。

まとめ

自然は、一般的に非常に小さな基本セット（DNAに向かってうなずく）の要素の無限の組み合わせによって得られる無限の多様性を私たちに示しています。 これは彼女の好きなテクニックです。



4つの抽象エンティティのみが基礎を形成します。これは、サブジェクトエリアを非公式に記述するのに十分です。 この記述をデータモデルの形式で形式化するには、3つのメタエンティティのみの宣言的なインスタンスで十分です。 また、メタエンティティの6つの実行方法によって形成されるオブジェクト表現のコンピューティング環境では、モデルはプログラムのように動作し、望ましい結果をもたらします。



上記はすべて、 E.F。Coddのリレーショナルモデルと、 K。Dataのリレーショナルテクノロジーとオブジェクトテクノロジーの統合に関するアイデアをさらに発展させたものです。 リレーショナルモデルの本質は変わりません。テーブル、列、テーブルの関係です。 とても自然な4番目の要素を追加しただけですが、何らかの理由でCoddが言及していない、つまりテーブル内の列の接続です。