関係機能

従来のリレーショナルデータベースでは、タプルのバイナリ接続はキーの使用に基づいています：プライマリおよび外部。 さらに、この関係の解釈は、データベースの論理構造の外部で実行されます。データベースの論理構造（解釈）は、本質的に非常にarbitrary意的です。 当然、リレーショナルモデルで規定された制限内です。



オブジェクトのパラダイムでは、それらの識別子はオブジェクトの接続を実現するために使用されます。 さらに、オブジェクトの接続に厳密な対称形状が与えられている場合：ペアの形で、直線| 後方リンクでは、これにより、Selectをリンク上の自然なナビゲーションにほぼ完全に置き換えることができます。 しかし、それほど重要ではないが、対称形式はオブジェクトの接続をデータベースの論理構造の完全かつ独立した要素にし、独自の動作と他の既存の接続への機能依存性を持ちます。



この記事では、オブジェクト間の通信のさまざまな動作の側面を検討します。その実装により、アプリケーションのビジネスロジックの大部分をデータベースの論理構造に直接統合できるため、開発者はコーディングルーチンから解放されます。



（著者は、プレゼンテーションにもう少しイメージを与えたいと思って、一般的に受け入れられている用語の規範から逸脱することを許可しました）。



情報の観点から、2つのオブジェクトの関係は、「私はあなたを見ます」という原則に従って、識別子の相互交換としてのみ理解されるべきです。 同時に、オブジェクト自体はデータクラスのインスタンスであり、クラスオブジェクトの接続は、クラスの関係の宣言によって確立されたルールの実用的な実装です-サブジェクトエリアのモデル化に使用される4つの基本的な抽象エンティティの1つのインスタンス。



リレーションによって接続された各クラスは、リレーションの反対のクラスによって型指定された参照属性を所有します。クラスオブジェクトの値は、反対のクラスのオブジェクトの識別子になります。 クラスリレーションは、オブジェクトの接続のルールを確立するだけでなく、異なるクラスにローカライズされた属性の相互作用を整理するための自然なコンテキスト（トランスポートおよび条件）としても機能します。

関係タイプ

関係タイプは、関係によって接続されたクラスから派生したオブジェクトの定量的相互作用の尺度を確立します。 ご存知のように、この測定には3つのオプション（ 1対1 、 多対1 、および多対多）しかありません。



多対1の リレーションシップ （ 複数リレーションシップと呼ばれる）は、明示的な因果ベクトルを持ちます。値（リンク）のプライマリ受信者は常に多側のリンク属性であり、 一方の属性値は派生値リスト（リンク）です。 ） したがって、この関係の属性の用語上の区分は、しばしば以下で使用されますが、 直接リンク 属性とバックリンク 属性になります 。



完全に対称的な1対1の関係（ ユニタリ関係でもある）では、ピアが参照する属性のそれぞれが、オブジェクトの接続を作成するイニシエーターとして機能し、値のプライマリ受信者になることができます。 この点での直接リンクおよび逆リンクの属性への分割は、本質的に純粋に状況に応じたものです。 そして、それらの1つが反対の属性に値を割り当てた結果としてその値を受け取るという事実にもかかわらず。



多対多の関係の概念的な意味は非常に曖昧であるため、別の考慮事項の対象となります。



図でさらに使用される複数および単一の関係のグラフィック表現は、次のようになります。







矢印のグラフィック画像は、依存関係ベクトルの画像とバックリンクのリスト属性の画像の両方に直感的に関連付けられているため、この表記が使用されます。 タイプと名前で参照属性をマークすることは、画像の必須要素ではありません。 参照属性は、反対のリレーションクラスによって入力され、それに応じてこのクラスの名前を取ります。

基準コネクタ

オブジェクトの接続の対称性は、接続されているオブジェクトのリンク属性の値の因果依存性によるものです。 他の依存関係と同様に、これはコネクタによって実装されます 。これを参照コネクタと呼びます 。 参照コネクタは先験的にアクティブであり、参照値の永続的な論理的一貫性と整合性を保証します。 その作業では、参照コネクタは、実際の参照属性に加えて、 サービス属性 OwnおよびDelも使用します 。 多重関係コネクターの宣言は次のようになります。





サービス属性Ownは 、独自のクラスによって入力され、オブジェクトの独自の識別子（ IDO ）をクラスオブジェクトに格納します。 この属性は、関係のコネクタがバックリンクの同じ属性に渡す値のソースとして、すべてのタイプの関係で使用されます。



Delサービス属性は、関係コネクタによってロックコンテキストとして使用されます 。 クラスAのオブジェクトを論理的に削除すると 、そのDel属性が初期化され、 Unsetメソッドが呼び出されてコネクタのベースソケットのアドレスが呼び出されます。これにより、属性Bが呼び出されます。 「空の」値とキーを持つSetメソッドの{A}その結果、対応するエントリがバックリンクBのリストから削除されます。 {A}。



Key属性（コネクタのキーコンテキスト ）は、デフォルトではクラスの基本属性です。 この属性の値はコネクターによってキーとして使用され、送信された値と対になって所有属性のIDOです。 このペアを受信する後方リンク属性B. {A}には、バックリンクリスト自体を直接形成する単純なリスト機能があります。



実際、直接リンク属性A. [B]は、コネクタにターゲットオブジェクトのIDOを提供する単なる参照コンテキストです。 属性A. [B]は、リンクの実装中に格納された値を受け取ると、コネクタのベースソケットでResetメソッドを呼び出します。これにより、属性Bのアドレスが呼び出されます。オブジェクトIDOとキーを使用したSetメソッドの{A}その結果、バックリンクのリストに新しいエントリが追加されますB. {A}。 さらに、 キーおよびダイレクトリンクA属性の値のその後の変更[B]に続いて、バックリンクのリストの対応する変更を伴うUnsetおよびResetへの連続した呼び出しが行われます。



単一の観点では、 キーコンテキストは明らかに使用されませんが、実装のミラー対称性を提供する2つのリンクコネクタがあります。





提示された宣言をよく見ると、参照値を割り当てるループ処理のすべての前提条件があるように見えるかもしれませんが、そうではありません。 Setメソッドは、外部から受け取った値が既存の値と等しい場合、派生再帰呼び出しを生成しません。

関係創造

2つの参照属性に加えて、少なくとも1つのコネクタが関係の形成に関与し、ソケットのセットを適切に設定されたフラグと組み合わせます。 宣言のこのボリュームはすべて、インスタンスを作成するために事前定義された方法と抽象的なメタ関係を表す形式を使用して、データモデルのビジュアルデザイナーのファサードの後ろに隠れていることを強調したいと思います。 コンストラクターがリレーションのインスタンスを作成するために必要なのは、バインドされるクラスのタイプと記述子だけです。



また、クラスの関係も属性のコネクタもデータモデルのエンティティではなく、それによって解釈されることもありません。 データモデルは、クラス、属性、およびソケットでのみ動作します。 リレーションとコネクタはアプリケーションモデルのエンティティであり、アプリケーションモデルはデータモデルの表現 （ 表現形式）です。

力関係

倉庫から倉庫への商品の転送などの操作を検討してください。 請求書転送オブジェクトでは、2つの倉庫オブジェクトを一度に処理する必要があります。 このような必要性は、参照属性Aの派生値の格納のアトミック形式を列挙可能な （配列）に置き換えることで、関係のパワーを単純に増加させることで実現されます。





多重リレーション（リンクの多重度）の能力を高めると、モデルコンストラクターは直接リンク属性の追加要素を作成し、既存のものと同様の別のリレーションコネクターが存在し、アドレスポインターのソースとして新しいエレメントを使用します（ refコンテキスト） 電力の増加は、別の着信ソケットを追加することを除いて、逆方向リンク属性B. {A}の宣言に影響しなかったことに注意してください。 （これ以降の図は、意味で必要なコンテキストのみを示しています）。



同様に、単一関係の力の増加が実現されます。





このタイプの関係には追加の内部対称性があるため、関係の両側の参照属性の要素の数は常に同じです。



同様に、複数リンクのバックリンク属性は複数のリストを提供できます。 デフォルトでは、最初の（メイン）リストはクラスのベース属性をキーとして使用します（ 請求書の場合、これはDate属性になります）。 何らかの目的で、たとえば合計請求書の金額など、ソート順が異なる別のリストが必要だとします。 新しいリスト宣言を作成することにより、関係コンストラクターは、backlink属性の追加要素（A2）と追加の参照コネクターを作成します。 新しいコネクタはプライマリコネクタと似ていますが、キーソースとして日付ではなく日付属性を使用します。



注意と強調：新しいリストを追加しても、関係の力は変わりません。



リストプロパティで追加の論理コンテキストが指定されている場合、コンテキスト値がtrueであるエントリのみがそれに含まれます。 このオプションは、たとえば「白灰色」アカウンティングを実行する場合に役立ちます。 また、ベース参照コネクタの3つのコンテキストはすべて既に使用されているため、コンテキストソケットの1つのフリーロックコンテキストを使用できます。 たとえば、次のように：





ご覧のとおり、 refコンテキストやキーコンテキストとは異なり、 ロックコンテキストをカスケードして、既存のコンテキストに追加の論理コンテキスト（条件）を作成できます。

参照整合性管理

参照されているオブジェクトを任意に削除できないことは明らかです。 したがって、参照整合性を維持するには、オブジェクトへの関連する外部リンクの可用性を制御する必要があります。



覚えているように、 Delサービス属性の値が初期化されると、オブジェクトは論理的に削除されます。 外部リンクを制御する機能を提供するために、各バックリンク属性は、作成されると、 Del属性への個別のパッシブコネクタを自動的に作成します。





Setメソッドでは、 Del属性の特殊なユーティリティ関数がすべての着信コネクタをチェックし、そのうちの1つがtrueを返す（バックリンクのリストが空でない）とすぐに、関数はトランザクションを中止する例外を発生させます。 しかし、あなたは例外に持ち込むことはできません。 Del属性にアドレス指定されたGetメソッドは、競合なしでオブジェクトを削除できる場合、コネクタをポーリングし、 falseを返します 。



概念的な観点から、「 親 」とみなされる関係があります。 たとえば、 Waybillとその条件付き「 子 」 レコードは、Waybillのコンテキストでのみ存在する場合があります。 ここでは逆の動作が予想されます。Recordオブジェクトからのバックリンクがある場合にのみInvoiceオブジェクトを削除できるだけでなく、独自の削除のプロセスで、すべてのRecordsを削除する必要があります。 リレーションシッププロパティでOwner仮想フラグを設定すると、必要な反応を実現できます。その後、データモデルに次の変更が加えられます。









最初に、 InvoiceクラスとRecordクラスのDel属性を接続するアクティブなコネクタが追加されます。次に、 Getフラグをリセットすることにより、 Delを対応するバックリンクリストに接続するコネクタが非アクティブになります。

相互関係

多重リレーションによって接続された3つのクラスのシステムを考えます。









クラスCのオブジェクトにはオブジェクトBとAへの直接ポインターがあり、オブジェクトBには Aへのポインターがあります。 追加の規則や制限はないため、最も一般的なケースでは相互参照によって接続されたオブジェクトCとBは、クラスAの 異なるオブジェクトを含めて一貫して対処できます。



サンプルを少し変更して、特定のセマンティックロードを導入します。



Cを Studentクラス、 Bを 教職員 、 Aを 大学とします。 学生が専任の教育機関で専攻されていることは明らかなようです。 言い換えれば、 学生の場合 、 大学へのポインタは、 教員へのポインタによって決定されます。 この規則は、関係C → Bを介してクラスBおよびCのクラスAへの直接参照の属性をバインドするコネクターを作成することによって確立されます。 関連する属性は同じタイプ-クラスAであることに注意してください。









標準コネクタによる参照属性のアクティブなリンク宣言は、外部の影響下で、参照値C. [A] = B. [A]の必要な一貫性を自動的に提供します。 実際には：

• C. [B]の値を受信/変更すると、コネクタは（ Unset / Resetメソッドによって）開始され、属性B. [A]の値を属性C. [A]に転送します。
• 属性B. [A]の値が変更されると、新しい値がバックリンクB. {C}のリストからすべてのオブジェクトCに転送されます。

直接リンク属性のアクティブな依存関係の宣言C. [A] = B. [A]は、直接的な論理的結果をもたらします。

• オブジェクトCの実際の値がCの場合。 [A]（たとえば、 学生がトレーニングのために大学をすでに選択している場合）、属性Cの有効な値を決定するためのドメイン。 [B]は属性Aのバックリンクのリストです。 {B}（この大学の学部のリスト） この帰結は、その最初の近似では、 データモデルで明示的に表現される制限の形式を取ります。コネクタCの自動作成です。 [B] = A. {B}。以下、 直接コネクタ Cの宣言から派生したバックコネクタと呼びます 。 = B .. [A]。

派生バックコネクタは完全に受動的であり、属性Cを変更しても開始されません。 [A]、コンテキストソケットの対応するUnset / Resetフラグがオフになり、外部の影響の処理プロセスに参加しないため。 このコネクタは、参照属性Cへの値の割り当てを整理するプロセスで使用されます。 [A]。これについては後で詳しく説明します。 それまでの間、データソースと見なされる場合、 バックコネクタによってアドレス指定されたバックリンクのリストは、それらから1つだけを自動的に選択する機能なしで、多くの同種の値を提供します。



一方、厳密に定義されていると同時にリストから選択できる要素は1つだけであるという条件があります。 このためには、リストにはキーの値による一意性のプロパティが必要です。まあ、キー自体が必要です。

値でグループ化

同じ3つのクラスの例を考えてみましょう。ただし、より明確にするために、少し異なる解釈で説明します。クラスAは、 レコード （クラスC ）を暦日（クラスB ）でグループ化するジャーナルです。 ジャーナルの各日は、 日付 （ D ）カレンダー日付の値によって一意です。 この一意性は、属性に割り当てられたバックリンク属性Aによって提供されます{B}リスト内の既存のキー値を持つリストにエントリを追加しようとすると、トランザクション例外をスローするわずかに近代化されたリスト機能 。



バックコネクターにもいくつかの変更が加えられました。 キーコンテキストとして日付（D）属性を使用し、 セミアクティブになりました ：ベースソケットのSetフラグがオフになっている場合、そのコンテキストはアクティブです（すべてのコンテキストソケットソケットに対してUnset / Resetフラグが設定されます）。









アクティブなコンテキストソケットでは、属性C. [A]またはC .Dの値を変更すると、 バックコネクタがアクティブになり、 C .Dの値が抽出され、リストAにアクセスするときにキーとして使用されます。オブジェクトID B）は、ターゲット属性に割り当てられます。 これにより、クラスCのオブジェクトをクラスBのオブジェクトに自動的に配置（グループ化）します。



しかし、対応するDayオブジェクトが存在しないC .Dの値に日付を入力するとどうなりますか？ この場合、 バックコネクタは自然にNULを返し、 Dayへのリンクは初期化解除されます。



この動作が必要になることもありますが、多くの場合、入力された日付に対応する必要なDayオブジェクトを自動的に作成する必要があることに注意してください。 この動作を実装するために、 Autoset機能がC. [B] 属性に割り当てられます 。 この機能（後述）は、 バックコネクタによって開始されると、クラスBの新しいオブジェクトを自動的に作成し、その後、作成されたオブジェクトの識別子を直接リンク属性の値として割り当てます。



しかし、これでは十分ではありません。 参照整合性を保持するには、新しいオブジェクトBの属性Dおよび{ A }は、厳密に定義された値、つまりオブジェクトCの類似の属性の現在の値と一致する値を自動的に受け取る必要があります。 これらの目的のために、コネクターB .D→ C .DおよびB. [A]→ C. [A] で、値の逆伝送が有効になります。つまり、属性C .DおよびCに属するコネクターの着信Get-ソケットで[A] 、 Setフラグが追加で設定されます。 次に、属性C. [B]に値を割り当てると、コネクタBのトランスポートコンテキストB .D→ C .DおよびB. [A]→ C. [A]、これらのコネクタは、オブジェクトBに値を転送するために開始されます。 図に示されている依存関係宣言は、値のいずれかが変更されたときに論理的整合性と参照整合性を自動的に保持します。



属性値によるオブジェクトのグループ化を実装する上記の一連の宣言は、2つのステップでモデルの内部コンストラクターによって作成されます。 特定の一般クラスのbacklink属性のプロパティで一意性オプションが有効になっている場合、この属性が属する関係は一意になります。 さらに、ターゲットリンククラス自体が、ベース属性の値によってリンクをグループ化するクラスとして機能できるようになりました。 3番目のクラスのそのようなクラスとの関係（共通クラスとも関係がある）は、グループ化が実装される値によって3番目のクラスのタプル内の属性を選択できるオプション（プロパティダイアログ内）を取得します。

リンクのグループ化

前の例を少し現代化します：クラスAとCの絶対属性Dの場所をクラスDへの直接リンクの属性にしましょう（一般に、バックリンクのリストは、値のキーと同じです：カレンダーの日付またはIDOのID）。 さらに明確にするために、クラスの意味を変更します。クラスAは製品 、クラスDは倉庫 、クラスCは勘定/請求書レコード （在庫移動）です。 次に、クラスBのセマンティックロードが一意に導出されます。これは製品在庫です。 WarehouseをSupplierまたはBuyerに置き換えると、クラスBはProduct-at-Supplier / Buyerになります。



行われた変更に対応する宣言は次のようになります。









WarehouseおよびGoodsオブジェクトへの特定のポインターを受け取ると、すべてのRecordは自動的にGood-in-Warehouseオブジェクトへのポインターを受け取り、ない場合は自動的に作成します。 注：3番目のクラス（ Product-in-Warehouse ）を介した2つのクラスProductおよびWarehouseの接続は、 多対多リレーションシップの実装であり、2つのバックリンク属性の値の直接交換に代わるものです。 さらに、このオプションには一意性のプロパティもあります。 言い換えると、オブジェクトのペアごとに、 商品と倉庫 、それらを接続する倉庫内オブジェクトが単一のコピーに存在します。 この動作は、バックリンクのリストの一意性プロパティが原因であり、反対のクラスへの属性ポインタがキーソースとして使用されます。 また、2つのクラス（ ProductまたはWarehouse ）のどちらでリストの一意性が宣言されているかは関係ありません。反対側のクラスの同じバックリンクのリスト（通常のリスト機能を使用）には実際に一意のキーのセットが含まれます

多対多の関係

直接の多対多の関係は、リンクされたクラスのそれぞれで相互作用する2つのバックリンクリストのように見えます。 このような実装には、一般に、意味のない実用的な意味があります。オブジェクトの接続の事実のステートメントのみであり、この関係を通じてこれらのクラスの属性の一貫した相互作用を実現する可能性はありません。 したがって、実際には、属性の目的の相互作用は、ターゲットクラスとの関係に関連付けられた3番目のクラスの属性を通じて実装されます。 実際のアプリケーションモデルでは、このような構造は常に見られ、独立したタイプの関係を装うことなく、最もarbitrary意的な方法で作成されます。



上記の例の在庫品のように、 3番目のクラスを介した関係に一意性のプロパティがある場合は、まったく別の問題です。 ここで、3番目のクラス（通信クラス）の詳細は、キーのソースとしてのリレーションシップ属性の使用ではなく、クラスリレーションの概念的な「派生性」です。 したがって、このような一意の （識別子による）クラスの3番目のクラスを介した接続は、 多対多の関係としてさらに考慮されます。 このようなタイプは、 一意のリレーションまたはrelation-projectionとして名前を付けることができます。



プロジェクションリレーションは、ダイアログの実行の結果として作成され、リレーションによって接続されたクラスが選択されます。その後、対応するコンストラクターメソッドが3番目のプロジェクションクラス自体を作成し、それに対応する複合名と、リレーションの属性およびそれらを接続するコネクターの他のすべての必要な宣言の両方を割り当てます。同時に、投影関係の3つのクラスとの関係を形成するクラスは、上記の例からコネクタの完全なセットを自動的に受け取ります。これにより、オブジェクトは投影オブジェクトへのポインタを自動的に受け取ります。視覚的に明確にするために、すべてのスキームの投影クラスと投影クラスの比率は二重矢印のように見えます。









注目すべきは、投影関係の組み合わせにより、あらゆる多次元データ分析を実装できることです。実際、すでに利用可能な投影クラスを含め、どの投影クラスも投影関係に接続できます。その後、すべての投影クラスの属性で数値の一般化を整理できます。

対応

増加多数の我々は、このように順番で先に論じた通信の論理的なアナログとしても見ることができる別のクラスの2つの以上のオブジェクトのアドレスに一つのクラスのオブジェクトを許容する関係多対多の。









これに基づいて、複数形式のリレーションシップには独自のプロジェクションが必要であると想定する必要があります。これは、複数のリレーションシップの一意のフォームであり、オブジェクトへのポインタは自動的に取得できます。



そして、リレーションシップとプロジェクションのダイアログを作成するプロセスで、同じクラスがターゲットクラスとして選択された場合、そのようなユニークなリレーションシップが実際に作成されます。そして、単純クラスと投影クラスの関係が作成された後、属性とコネクターの宣言は次の形式を取ります。







その外観のすべての奇妙さのために、それは、例えば会計で実際に使用される論理的で完全に機能する宣言です-残高勘定の相互通信のオブジェクトを受け取るために。厳密に言えば、ここから借りた名前- 通信、これは投影クラスによって実現される複数のユニークな関係を示すために以下で使用されます。



上記の宣言に注意を何を払う必要があります：彼の1インスタンスを持つオブジェクトの任意のペアを接続する従来の投影とは対照的に、に対応このような関係は、直接リンク要素のポインターの組み合わせごとに1つずつ、2つのインスタンスで実装されます。これらの目的のために、バックリンクのリストの形成を含むすべての相互作用において、値とキーの両方として機能する参照ポインターは、それらが配置される要素のインデックスによって補完されます。さらに、意味のない二重アドレス指定をブロックするために、投影クラスの参照属性に、両方の要素に同じ値が割り当てられないようにする特別な関数を割り当てることができます。

関係の実装

クラスオブジェクトにリレーションシップを実装する方法は1つだけです。つまり、Setメソッドを使用して、ターゲットIDOのIDOに直接リンク属性を割り当てます。さらに、対応する呼び出しは、外部とデータモデル自体の両方で開始できます。たとえば、属性は、同じ参照属性をバインドするコネクタを介して、別のクラスからオブジェクトへのポインタを取得できます。また、Createメソッドがターゲットクラスではなく、このクラスで入力されたリレーションの属性（直接リンクと後方リンクの両方の属性）にアドレス指定されている場合、オブジェクトの作成時にリレーションを直接実装できます。この方法では、別のオブジェクトに関連する新しいオブジェクトを作成すると便利です（たとえば、請求書に関する新しいレコード）属性は、Autoset機能を使用してターゲット関係オブジェクトを作成することにより、IDOを受け取ることもできます。



外部ユーザーは、単に参照値を取得して属性に割り当てることはできません。内部識別システムへの直接アクセスを開くことの悲しい結果は、コメントなしで明白です。さらに、オブジェクトの空間の外側では、「意味を失う」と呼ばれる別のIDO記述子が素数になります。



したがって、外部ユーザーは、各オブジェクトがその絶対（非参照）値で表されるリストから要素を選択することにより、ダイアログの形で間接的にのみリンクを実装できます。必要なリストは、データカーソルレイヤーのコンポーネントによって提供され（オブジェクトDBMSのインターフェイスリソースのサーバー部分は後で考慮されます）、IDO割り当てを開始します行われた選択に応じて。選択ダイアログは、直接またはカスケードで、既存の背面コネクタに基づいて設定できます。ダイアログリストの形成のソースは、対応するバックリンクのリストです。

機能オートセット

この機能は、ターゲットリレーションシップクラスの派生オブジェクトを自動的に作成してリレーションシップを実装するために、直接リンク属性に割り当てられます。自動設定



機能は、インバウンドコネクタまたは外部のUpdateイベントによってトリガーできます。この場合、ターゲットリレーションシップオブジェクトは、ソースオブジェクトの参照属性に値が格納されていない場合にのみ、機能によって作成されます。

セットの複製

値の論理的相互作用には強固な規則があり、特定のドメインに属する値は、そのドメインがソースに含まれる値またはソースが含まれる値にのみ関連付けることができます。この場合、同等以上のドメインを持つ値のみが初期値を取ることができます。最大のドメイン（Undefined Typeの後）にはタイプLogicalの属性があり、これは他のタイプの値を取ることができます。簡単に言えば、コネクターは同じタイプの属性のみをバインドできます。これは、以前に検討したすべての例で観察されました。ただし、次の宣言では、バックリンク属性をリンクするパッシブコネクタ（A. {B}→ C {D}）は明らかに異なるタイプであり、この規則に明示的に違反しており、それにもかかわらず、生命に対する完全な権利を持っています。









問題は、この場合、相互作用の主題は意味そのものではなく、逆方向リンクリストの形をとった関連セットの量的側面であるということです。何が起こっているかのロジックをより詳細に考えてみましょう。



静的属性は、要求でアクセスしたときに初期化されていない派生値であるにもかかわらず、着信接続がある場合はそれを形成することで値を返すことができます。同時に、リクエストにはトランザクションに属しているという明示的な指示が含まれていないため、属性自体は保存された値を作成しません。つまり、データベースはその状態を保持する必要があります。変わらない。効果のトランザクションの性質が明らかな場合、それは別の問題です。この場合、以前に初期化されなかった静的属性は、データベースの状態の一般的な変更のフレームワーク内で、格納された値を形成できます。宣言からわかるように、問題のコネクタとそのターゲット属性C. {D}は、属性Cに値を割り当てることによってトリガーされます。 [A]、つまりトランザクション的に。そして、現時点で派生値が存在しない場合、属性C. {D}は、コネクターによって提供される元のパターンに従って形成を開始します。



意味として、バックリンクのリストは直接リンクから派生しています。つまり、属性C{D}元のリストのサイズで独自のリストを作成する唯一の方法は、必要な数のクラスDのオブジェクトを作成し、作成された各オブジェクトに独自のオブジェクトへのポインターを割り当てることです。このような割り当てを伴う作成は、独自のアドレスへの単一の作成コマンドで実行できます。ソースリストの各要素の属性（および完全に正確な場合-属性に割り当てられたリスト機能）が行うこと。また、この要素の値は型が既知の参照ポインターであるため、作成されたオブジェクトのクラスタプルを分析することにより、必要な型の直接リンク属性が決定され、要素から抽出されたポインター値が割り当てられます。



これらすべてのアクションの結果として、既存のサンプル（ソースクラスの派生オブジェクトのセット）によると、ターゲットクラスの派生オブジェクトの同様のセットが作成され、モデルとペアワイズ接続されます。

内部関係

同じタイプのオブジェクト（同じクラスのオブジェクト）をリンクするには、データクラス内で直接作成されるリレーションが使用されます。同時に、リレーションシップ自体を実装する方法は変更されません。2つの参照属性がクラスに作成され、参照コネクタで接続され、独自のクラスで入力されます。



注目すべきことは、前の段落で説明した対応は、一部ではあるが内部関係に起因することもあります。これは、1つのクラスから派生したオブジェクトを接続するためです。真実は、サードパーティのオブジェクトを介してこれを行います。



接続されたクラスが順番に選択されるビジュアルダイアログによって作成される通常のリレーションとは対照的に、内部リレーションはターゲットクラスのビジュアルスペースの属性の例によって作成されます。



内部関係を通じて、属性はそれ自体にコネクタを作成できます。これは非常に効果的な手法であり、「累積合計」による一般化を含む、さまざまな種類の意味の一般化を実装できます。



内部関係の機能的な意味は、そのタイプによって決まります。

チェーン関係

内部の1対1の関係により、クラスオブジェクトのシーケンシャルチェーンを形成できます。これがchainと呼ばれる理由です。



チェーン関係はさまざまな方法で実装できます。共通所有者からのバックリンクのリストから前のオブジェクトへのコネクタを取得するか、前のオブジェクトに関連する後続のオブジェクトを作成して関係を実装するオートセット機能を使用します。後者の場合、Updateイベントメソッドを使用して機能を開始すると便利です。



使用例としては、一連の操作として整理された処理サイクルの一部の通過、または1年の決済期間（四半期または月間）があり、期間の始めと終わりに累積合計があります。チェーン比のパワーが3に増加すると、クラスのオブジェクトは3次元結晶格子と論理的に類似するようになります。この設計は、物理環境を含む、さまざまなモデリング動作に使用できます。

再帰的な態度

recursiveと呼ばれる内部の多対1の関係により、オブジェクト（ファイルシステム内のフォルダーのようなオブジェクト階層）によって形成される可変ネスト深さのツリー型データ構造を作成できます。再帰の使用の典型的な例は、建設現場での作業のカレンダースケジュールです。このスケジュールでは、再帰的なスケジュールとともに、チェーンリレーションも使用されます。再帰リレーションを実装する最も便利で自然な方法は、既存の親オブジェクトに関連するクラスオブジェクトを作成することです。



再帰関係によって形成されるオブジェクトのツリー状の階層に関して、これらのオブジェクトと他のクラスのオブジェクトとの複数の関係を実装する場合、2つの論理的に明白な制限ルールが適用されます。

再帰と対話するためのルール

グラフィカルに、サードパーティクラスと再帰クラスとの相互作用のルールを次のように説明できます。







1. オブジェクト階層との複数のリレーションシップの場合、サードパーティクラスのオブジェクトは、この階層の最下位レベルに属するオブジェクト、つまり再帰リレーションのバックリンク属性の値が空のオブジェクトにのみ直接リンクを実装できます。



2.オブジェクト階層の最高レベル（直接再帰リンクの属性の初期化されていない値を持つ）に属するオブジェクトのみが、サードパーティクラスのオブジェクトへの直接リンクを実装できます。



これらの制限は、他のクラスとの内部再帰関係を持つクラスの複数の関係の実装にのみ適用され、同様の単一関係には適用されないことに注意してください。一般的な階層の特徴であるこれらのルールは厳密ではありませんが、本質的に助言的なものです。オブジェクトモデルのレベルでのこれらのルールへの準拠は、いかなる方法でも制御されず、アプリケーションのインターフェイス部分に完全に帰属します。

フラクタル投影

一意の投影関係で接続された一方または両方のクラスも内部再帰を持っている場合、これらのクラスの派生オブジェクトは、オブジェクト階層の最下位レベルだけでなく、以降のすべてのレベルでも投影オブジェクトによって相互接続されると仮定するのが論理的です。おおよそ次の図に示すとおりです。









このような関係を実装するには、投影クラスに再帰関係の宣言も必要です。



したがって、プロジェクションクラスで再帰リレーションが作成されると、このリレーションシップの2つの参照属性とコネクタに加えて、モデルコンストラクターはさらに2つの追加の属性と、追加の属性の値によってオブジェクト階層の次のレベルへのプロジェクションを提供するコネクタのセットを作成します：









コンストラクターは、接続されているクラスへの投影の直接リンクの属性と同じタイプに追加の属性（図では[*]でマーク）を割り当て、それらを関係属性のカテゴリーに転送します。ただし、違いがあります。追加の属性のバックリンクはありません。



追加の属性は、図の記号（=）でマークされたアクティブなコネクタを介して、同じタイプの再帰ダイレクトリンク属性から格納された値（オブジェクトへのポインター）を受け取ります。プロジェクションで接続されたオブジェクトのいずれかで再帰が実装されていない場合（番号1および3の通信スキーム）、対応する追加属性には値が格納されませんが、アクセスされると戻ります再帰なしのオブジェクトへのポインタ。この動作は静的属性の典型的なものであり、前述したとおり、Getメソッドが値が初期化されていない属性にアクセスする場合でも、着信コネクタをポーリングして戻り値を生成できます。図では、モデルコンストラクターによって作成された対応するパッシブコネクタ、点線。



上で考慮されたCorrespondenceのような投影バリアントで内部再帰関係が宣言されるとき、モデルコンストラクターによって完全に同様の追加属性とコネクタのセットが作成されることに言及する価値があります。

構造的インターフェース

構造的なインターフェースの必要性は、さまざまなエンティティへの統合されたアクセスを取得するために関係を通じて必要とされる場合に必ず発生します。言い換えれば、異なる詳細のセットを持つエンティティは、（詳細の観点から）同種のセットに縮小する必要があります。まあ、少なくともそのとき、それらを一般的なリストとして提示します。



この問題の最初の解決策は、クラス継承のメカニズムによって提供されます。子孫クラスは、祖先クラスの属性のタプルを継承します。これは、たとえば、豊富な種類の金融ドキュメントをすべてDate型、Number型、Document Name / Transaction型、Amount型の1つのリストにまとめるのに十分です。



このソリューションは、インターフェイスを「上から」と任意に呼ぶことができます。うまく機能しますが、残念ながらすべてのエンティティが共通の祖先を共有しているわけではありません。典型的な例は、私たちに建設中で会計の詳細を与える：一部の顧客は、主要な資金調達されている構造の数で構成され、建設オブジェクト、作品によって構成されている作品の種を、そして異なるに含まれている協定（と顧客）。ガントチャートの全体像を縮小するには、作業の進行状況（資金調達、発生した費用、工数など）が必要です。。多重継承はお勧めできません。さらに、多重エンティティの効果は、異種エンティティを1対1の関係と組み合わせることによって得られます。これは、明らかに、単一の関係の哲学的な意味です。この例では、ユニタリリレーションと再帰を組み合わせることで結果が得られ、宣言では次のようになります。







上記の「構築」アカウンティングの各サブジェクトは、自動的に（Autosetを使用して）ガントクラスにペアのオブジェクトを作成し、その後、そのオブジェクトに（直接再帰リンクの属性の値として）論理的な「所有者」へのポインターと、他の値を渡します。 「所有者」へのポインタは、再帰投影スキームと同じ補助属性を介して送信され、シンボル[*]で示されます。ガントオブジェクトの作成と属性への値の転送は、「2つの部分を論理的に接続する全体「



このような実施形態は、名前解決策（従来のような）とすることができるインターフェース」側- 「実体の均一な表現の別の方法があるので非常に適した名前である、（我々は修正する用語の専門家）のインタフェース」の下に。彼のアイデアは、値として正しい値で属性に統一されたデータ構造を格納していることである、」インターフェイスのタイプ、これは、「会計値と統一されたビューを必要としますので、特定の「仕事」で送信配線という事実にもかかわらず、P、まったく同じ外観は比較的鈍感です」単一コピーの文書や、多くの場合ではないの異なるクラスでzmescheny。



部分的な構造統一のためのこのような異なるオプションの存在は、普遍的なインターフェースソリューションが自然界に存在しないことを示唆していることは、おそらく注目に値します。

インターフェースの種類

オブジェクトデータモデルでは、構造タイプはユーザークラスとして最も自然に存在し、その識別子（ IDC ）はこのデータタイプのハンドルです。 したがって、インターフェイスデータ構造はクラスとして定義でき、属性値としてのその使用は、 ユニタリリレーションの一種の変更と見なされる必要があります。インターフェイスクラスへの直接リンクの属性には、インターフェイスクラスオブジェクト識別子（IDO）ではなく、オブジェクト自体が格納されます。 値として「含まれる」オブジェクトは独立性を失うため、それとともに、独自の記述子を持つこともなくなります。 現在、その識別子は、所有者オブジェクトのIDO +それが配置されている属性のIDAに関して複合値になっています。 このソリューションにより、インクルードされたオブジェクトを作成し、それとの関係を実装する方法を心配する必要がなくなります。これはすべて、属性の初期化中に所有者オブジェクトを作成すると自動的に行われます。



最初は「インターフェース」オブジェクトがさまざまなクラスのオブジェクトの構成に含まれると想定されているため、リンクされたクラスのそれぞれに参照属性を作成して関係の対称性を確保する従来の方法は最適ではなくなります。 実際、このメソッドを使用すると、一定数の参照属性が「インターフェイス」クラスのタプルで宣言されます。このクラスでは、リレーションシップが実際に実装されるとき、常に1つの値しかありません。 したがって、別のオプションが選択されました。宣言では非対称ですが、それでも実装中に参照対称を保持します。



インターフェイスクラスでは、作成されたすべてのインターフェイス関係の後方リンク属性の役割は、同じ属性-Ownによって実行されます。これは、任意の参照タイプの値を受け入れるために、 ユーザー定義タイプtypeが割り当てられます 。 実際、 Own属性へのこのタイプの割り当ては、クラスを「 インターフェース 」としてマークするフラグの役割を果たします 。

「 interface 」リレーションの最終宣言（右側）は、通常の単一リレーションの宣言（左側）と比較すると、次のようになります。







インターフェイスタイプを決定するためのロジックは、その使用順序も確立します。インターフェイスとして宣言されたクラスは、独立したデータタイプ（構造タイプ）を形成し、属性入力ダイアログを選択するためのメニューの形成に含まれるタイプの標準セットを補完します。 このタイプを選択して属性に割り当てると、モデルコンストラクターは図に示されているすべての宣言を作成します。

サービスクラス

実際、ユーティリティクラスは、内部のユーティリティタスクを解決するためにデータ管理システムによって使用される通常のデータクラスです。 サービスクラスと他のクラスの違いは、新しいデータベースが生成されるときに制御システムによって自動的に作成されるため、システムにアプリオリに既知の固定記述子があることだけです。

スーパークラス

相互リンクによって対称的に接続されたデータオブジェクトのセットは、自然なオブジェクト間のナビゲーションが何によっても制限されない閉じたシステムです。 しかし、信頼性とセキュリティの理由から、オブジェクトへの直接アクセスが禁止されているため、そのようなシステムに入る問題が発生します。 IDCおよびIDO記述子の固定値を使用して、 スーパー クラスと呼ばれるこのユーティリティクラスとその派生スーパーオブジェクトを使用すると、この問題を克服するのに役立ちます。



デザイナーが新しいカスタムクラスごとにアプリケーションを作成すると、このクラスに対してスーパークラスとの複数の関係が自動的に作成されます。 したがって、前述のクラスのサービス属性のセット（ Type 、 OwnおよびDel ）は、4番目のメンバー（スーパークラスへの直接参照の属性）によって補完されます。 スーパークラスは、新しく作成されたクラスのIDC記述子によって入力されたbacklink属性を取得します。 したがって、カスタムクラスの作成時に、 スーパークラスは完全なセットの一種の所有者になります。これにより、現在のデータモデルへのエントリポイントとして固定記述子を持つスーパークラスを使用できます。 注目すべきは、スーパークラスのバックリンクの属性識別子（ IDA ）の値がクラス識別子（ IDC ）と奇妙に一致することです。



クラスが派生オブジェクトを作成 （ Create ）すると、スーパーオブジェクトの固定IDOを受け取るスーパークラスへの直接リンクの属性など、サービス属性が自動的に初期化されます 。 同時に、結果として、新しいオブジェクトへのポインターは、 スーパーオブジェクトのバックリンクの対応するリストでそれ自身を補充します 。 したがって、リレーションを実装するための標準ルールに準拠している場合にのみ、 スーパーオブジェクトは各クラスのオブジェクトのリスト、つまりオブジェクトのフルセットの所有者になります。 この状況により、 スーパーオブジェクトをデータベースへの自然なエントリポイントとして使用でき、クラスオブジェクトのリストにアクセスできます。



重要な点に注意しましょう-宣言のようなデータクラスには、自身のオブジェクトのリストへの物理的なポインタがありません。 論理的な関係を除き、データとメタデータの間に他の関係はありません。



もう1つの詳細：オブジェクト選択ダイアログを整理するとき、特に指定されない限り、デフォルトのデータカーソルはスーパーオブジェクトからのターゲットクラスのバックリンクのリストを使用します 。

クラスグローバル

どのアプリケーションでも、アプリケーションのすべての部分で永続的に使用可能なグローバル値が必要です。 そのような値を宣言するために、 グローバルサービスクラスが使用され、それらが派生オブジェクトに格納されます。 Globalクラスの特異性は、他のすべてのクラスのような多重リレーションではなく、 単一の 1対1のリレーションによってスーパークラスに関連付けられているという事実です。 言い換えると、 スーパーオブジェクトに関連して、 グローバルオブジェクトは単一のコピーに存在し、 スーパーオブジェクトのタプル内での位置がわかっているため、その値へのアクセスは1ステップで実行されます。



使用する機能に応じて、グローバル値のセット全体を条件付きでグループに分割できます。 最初のグループには、通常は組織の名前 （所有者）などのインターフェイス形式で単独で使用される分離された値が含まれます。 これらの値にアクセスするには、 スーパークラス → グローバル → 属性というルートで十分です。



2番目のグループは、 VAT税率などのいわゆる借用価値によって形成されます。 借用した値を利用するためには、クラスはGlobalクラスとの関係を持ち、明らかに-multipleである必要があります。 このような関係が宣言されると、モデルコンストラクターはそれに加えて、作成されたオブジェクトがグローバルオブジェクトへのポインターを自動的に受け取ることを可能にするコネクターを作成します。







絶対値に加えて、 参照値もグローバルにすることができます。 このような値は、アプリケーションのセットアップ時に指定されるデフォルト値として最もよく使用されます。たとえば、ルーブルとドルのペアを形成する通貨オブジェクトへのリンクです。 タイプ多 （グローバル）から1 （通貨）への関係は常識に負担をかけるため、グローバル参照値は少し異なる方法を作成します：最初に、 未定義タイプ属性がアトミック （単一参照の場合）または列挙（複数リンクの場合）形式で作成され、その後、そのタイプは、ターゲットクラスのユーザー定義タイプ = IDCに再定義されます 。 つまり、直接リンク属性は、リレーションシップ自体を宣言せずに作成されます。 この手法は、リレーションシップの宣言に実用的な意味がない場合に使用され、必要なタイプの属性が必要です（たとえば、上記の再帰的投影を実装する場合など）。



さらに、 グローバルオブジェクトによって格納されるすべての値は、 一般とユーザーに分けられます 。 組織の名前やVAT率などの一般は、データベースのすべてのユーザーで同じです。 レポート期間やデフォルトでのウェアハウスへのポインター（特定のストアキーパーなど）とは異なり、ユーザーごとに個別にする必要があります。 ユーザー値を作成して保存するには、 Userクラスのオブジェクトを使用します。

ユーザークラス

Userクラスの主な目的は、エンドユーザーデータベースユーザーの認証システムを構築するために使用されることです。 承認中にユーザーが入力したユーザー名とパスワードがUserオブジェクトのいずれかの対応する属性の値と一致する場合、承認は成功したと見なされ、その後、このオブジェクトの他のすべての属性の値は、このユーザー（および彼のみ）がグローバル値として利用可能になります。



次のように実装されます。 GlobalクラスとUserクラスは、 複数の関係によって関連付けられています 。 Userクラスで新しい静的属性を作成すると、 Globalクラスは同じタイプと同じ名前の動的属性（ user ）のペアを自動的に作成し、作成後、 Userのペア属性からパッシブ着信コネクタを受け取ります 。 Globalのユーザー属性にアクセスすると、この属性はコネクターを介してその値を取得しようとしますが、この時点では、 ユーザーオブジェクトへのバックリンクのリストの代わりにランタイムが、ユーザー認証中に取得したオブジェクトのみへのポインターを置き換えます。



属性は、複数のソースからのバックリンクのリストを介して、またはこれらの値を単一の値に変換することによって（合計など）、または値のセットから1つだけを選択できる条件（コンテキスト）がある場合、コネクタを介して値を取得できることに注意してください。 適切な条件または変換（機能）がない場合、属性は、backlink属性を介してインバウンドコネクタを作成できません。 Globalクラスのユーザー属性の場合、この制限は人為的に克服されます。

ローカルデータベース

テキストの少し前に、リレーションによって接続された多くのオブジェクトが閉じたシステムを形成することについて既に言及しました。唯一のエントリポイントはスーパーオブジェクトです。 このようなクローズドシステムの任意のセットは、単一の物理データベース内に存在できます。 そのような各システムは、他のそのような論理データベースから完全に分離された論理データベースと見なすことができます。 各論理ベースには、独自のエントリポイント、独自のスーパーオブジェクトがあります 。 つまり、新しい論理ベースを生成するには、 スーパークラスから派生した別のオブジェクトを作成する必要があります。



この問題は、 ユーザー → グローバル ： スーパークラスの3つのユーティリティクラスの助けを借りて解決され、 グローバルクラスがこの接続のリーダーになります。 論理データベースに関連付けられているのはGlobalクラスであり、「its」ベースのユーザー名を含む、対応する属性ストア内のこのクラスの各派生オブジェクトです。 1対1の関係を使用すると、 グローバル オブジェクトを作成するときに新しいスーパーオブジェクトを自動的に作成して関連付けることができます。 グローバルオブジェクト（ 論理ローカルデータベースのインスタンスと見なされる）に関連して、 ユーザークラスのオブジェクト（ローカルデータベースのこのインスタンスのユーザーという名前）が作成されます。 このユーザーの認証手順を通過した後、 ユーザーオブジェクトだけでなく、それに関連付けられたグローバルオブジェクトとスーパーオブジェクトの記述子（ IDO ）が彼のクライアントテーブルに保存されます。 この特定のユーザーの主導でこのオブジェクトを作成するときに、任意のクラスのオブジェクトの対応するサービス属性に自動的に割り当てられる値として制御システムによって使用されるのは、 スーパーオブジェクト （ローカルデータベースのルート要素）へのユーザーポインターです。



重要なのは、すべての相互に分離された論理データベースは、それらに共通のデータモデルのルールの対象であり、物理データベースのスペース全体に適用されるということです。

関係の継承

子クラスが作成されると、子孫クラスは祖先クラスの属性の完全なタプルを受け取り、子孫クラスはリレーションの属性とともに、祖先クラスのリレーションの完全なセットを受け取ります。 同時に、興味深い詳細が表示されます。



新しいクラスは、その作成方法に関係なく、オブジェクトの完全なリストを明示的な形式で保持するために、 スーパークラスと独自の関係を形成する必要があります。 ただし、後継クラスは、先祖のタプル全体内でスーパークラスへの直接参照の属性を既に継承しているため、このような関係を直接作成することはできません。 さらに、祖先クラスは独自のオブジェクトを作成しませんが、スーパーオブジェクト内のバックリンクのリストには、すべての子クラスから派生したオブジェクトの完全なリストが含まれている必要があります。 （例：一般にすべてのドキュメントのセットがあり、 委託ノートのみのプライベートセットがあります 。）

祖先クラスのオブジェクトのリストは、既存の宣言に干渉することなく形成されます。これは、彼のすべての相続人がスーパークラスとの親関係を受け取っているためです。 後継クラスの場合、クラスコンストラクターは新しいリレーションシップの部分的な作成を実装します-既存の直接リンク属性が使用され（新しいものは作成されません）、逆方向リンク属性がスーパークラスで作成され、両方の属性がリンクコネクタによって接続されます 。







したがって、継承中、スーパークラスとの関係の左右対称性は部分的に違反されます。スーパークラス内の2つ以上（継承の深さによる）バックリンクポインターは、スーパークラスへの1つの直接ポインターに対応します。 しかし、このような規則の例外は本質的にプライベートであり、論理的に正当化されているようです。

ドメインの絞り込み

参照属性の値のドメインは、リレーションの反対のクラスとそのすべての後継クラスから派生したオブジェクトの識別子によって形成されます。 アプリケーションでは、参照属性の値のドメインを強制的に狭めて、単一のクラスに制限する必要があることがよくあります。



次の例を考えてみましょう。







抽象カウンターパーティには、 法的または個人 （ カウンターパーティクラスの後継者）の2つの組織フォームのいずれかがあります。 取引所取引では、取引相手は特定の役割を果たします。同時に、 サプライヤ 、 バイヤー、またはその両方になることができます。 明らかに、 カウンターパーティと役割の間には非常に具体的な関係がありますが、これについては後ほど別途検討します。 Invoiceクラスは、取引先およびロールとの自然な複数の関係が宣言されている抽象交換トランザクションです。 具体的な操作の例では、 領収書と費用 、 請求書とその関係の相続人の2つがあります。



請求書の相続人は、それが継承された形式で相手方との関係を使用します。 領収書と支出請求書の両方は、 法務と個人の両方が存在するカウンターパーティの一般リストからターゲットを選択することにより、この関係を実装します。



ロールとの継承された関係には、 再定義が必要です。これは、 受信請求書の参照対象はサプライヤのみであり、 費用についてはバイヤーのみであるためです。 継承された関係の再定義（ ドメインの絞り込み ）は、参照プロパティがモデルコンストラクターに適切なダイアログを提供する属性プロパティで、祖先クラスの識別子を継承クラスの識別子に置き換えることで実現されます。 Incoming and Expenditure Invoicesの直接リンクの関係を明確にした後、その役割に対応するInvoiceオブジェクトのみが自動的にSupplierおよびBuyerのバックリンクのリストに分類されることに注意してください。 ただし、これらのクラスの参照属性に対するリレーションの対称的な再定義は、適切な形式と見なされます。



前の例では、 請求書はCounterpartyをそのRoleに論理的に接続します。 同じクラスのセットを使用してこの接続をより詳細に検討しますが、少し異なる視点で提示します。









カウンターパーティは、 サプライヤとバイヤーの両方にすることができます。 この事実は、 Roleとの共通の関係を作成せずに、これらのクラスとCounterpartyの2つの個別の単一関係を作成することによって宣言されます。 同時に、 委託先との関係だけでなく、たとえばさまざまな決済を整理するために必要な、 サプライヤとバイヤーに共通の追加の属性セットも保持するため、共通の祖先ロールが必要です。 取引先と ロールとの論理的な関係は次のとおりです（ サプライヤと 領収書の委託ペアの例を使用）： 取引先は、少なくとも1つの請求書がある場合、 サプライヤのステータスを取得します（ サプライヤクラスのオブジェクトを形成し、このオブジェクトとの関係を実装します）。 この接続が物理的な実装を受け取り、データモデルの内部ルールとして機能するには、図に示すように、 オートセット機能を使用する必要があります。









図の左側の部分は、 カウンターパーティとサプライヤの間に単一の関係が存在することにより、別のダイレクトリンク属性にポインターを割り当てるときに、 着信請求書がダイレクトリンク属性の値を取得できる可能性があることを示しています。ただし、サプライヤは論理的にセカンダリであるため、オートセット機能はサプライヤへの直接リンクの属性に割り当てられます。この目的のために、追加の双方向バックタイプコネクタが自動的に作成されます。これらの宣言が利用可能な場合、実行中に納品書で契約者オブジェクトを選択した後、次の2つのいずれかが発生します。場合は相手方へのポインタサプライヤーだ関連、コネクタは、適切な属性に送信されます表面。それ以外の場合、バックコネクタはAutoset機能を初期化します。、それを所有する参照属性をバインドし、ターゲットクラスのオブジェクトを作成することにより、この場合は関係を無条件に実装します。Supplierオブジェクトが作成され、そのポインターがダイレクトリンク属性に割り当てられた後、同じバックコネクタがこのポインターをCounterpartyオブジェクトに逆に渡します。



次の図に、関係の改良に関する別の例を示します。









タイプRecordのオブジェクトは、常にレコードバックリンク属性に対応するCreateイベントを使用して、Invoiceオブジェクトのコンテキストで作成されます。したがって、目的のクラスのオブジェクトを作成するには、後方リンクのターゲットクラスを明確にする必要があります。子クラスの直接リンク属性プロパティでクラスをオーバーライドするレコードは推奨されますが、必須ではありません。

選択的価値移転

クラスBのS属性の値は、祖先クラスAのS属性に共通の1つのコネクタと、その子孫A1およびA2の属性DおよびKに 2つのプライベートなコネクタによって分散されます。相続人A1またはA2のオブジェクトへのポインタがオブジェクトBによって受信されるかどうかに応じて、アドレス指定されたオブジェクトでは、2つの属性DまたはKの一方のみがその値を受信します。とにかく属性Sはその値を取得します。









この動作は、コネクタrefコンテキストの選択的なプロパティによって保証されます。つまり、refソケット宣言にコネクタのIDCターゲットクラスが存在するためです。外部コネクタは、refコンテキストがターゲットのIDOを提供する場合にのみ、転送機能を実行します。そしてこれは、参照属性の値- オブジェクトのIDOがrefソケットのプロパティで宣言された型の値のドメインに含まれる場合にのみ発生します。



さて、アクションを実行する前に型の一致をチェックするifステートメントとの関連付けを要求します。

まとめ

識別子の相互交換に基づくオブジェクト通信の対称形式の実装により、参照整合性とデータベース自体の制御との論理的整合性を自動的に維持できます。さらに、通信の対称性により、データオブジェクトの多次元空間での自然な（Selectなしの）ナビゲーションが可能になります。実際、アプリケーションのビジネスロジックをデータベースの論理構造に直接統合する方法は、これと以前の出版物で説明されているように、アプリケーションの作成速度を大幅に向上させることができます。同意して、視覚的なデザインは、プログラムコードを記述およびデバッグするよりもはるかに簡単です。