そのような状況では、抽象化レベルを上げることで問題を部分的にしか解決できません。これは、詳細から抽象モデルに移行すると、主題領域の特異性が失われるためです。 したがって、論理的に接続された2つの抽象化レイヤーを同じデータベースに保存する必要があります。 論理接続詞はメタレイヤーである必要があります。メタレイヤーは、モデルのある抽象レイヤーから別の抽象レイヤーへの1対1マッピングのパラメーターを定義します。
（図1）
説明を簡単にするために、誰もが理解できる主題領域を取り上げます（図1を参照）。 エンティティは黄色でマークされ、それらの間のクロスリンク（多対多）は緑色で示されます。 組織、会社、部門、部門の2つの階層があります（将来、新しい階層を導入して拡張できます）。 また、2番目の階層は、アクティビティを分類します：産業、方向、専門化（拡張することもできます）。 ただし、簡単にするために、各階層の3つのリンクに制限し、そのような限られた情報モデルであっても、抽象化レベルを上げる必要性を特定します。
理想的なドメインモデルを図に示します。 ただし、実際には、専門分野は部門だけでなく、部門または企業にさえも結び付けられる必要があることが判明する場合があります（異なる組織ではこれは異なり、構造は非常に動的であり、最初の見かけの単純さでは安定していません）。 したがって、数十社の企業の構造を分析して一般化すると、次の図に到達できます（図2を参照）。 1つの階層内の3つのエンティティは、ほぼ任意に（すべての組み合わせの9つ）別の3つのエンティティに関連付けることができます。この場合、1つの関係は適用されません。8種類の多対多関係を受け取ることで除外できます。 各リンクに職位数、従業員の要件、認定基準、および給与のパラメーターを決定するいくつかの属性グループが必要な場合、状況は複雑になります（実際には、情報モデルははるかに複雑です）。
（図2）
図2では、このようなモデルのERダイアグラムでさえ理解が難しくなり、各リンクが3-5グループのパラメーターを受け取ると、クロスタブは約2から4ダースになり、一般的にダイアグラムに表示するのが難しくなります。 さらに、このような複雑なデータベースを操作するためのプログラムコードとユーザーインターフェイスを作成することは非常に難しくなり、必要に応じてそれらに絶えず変更を加えると、このようなソフトウェア製品は維持に多大な所有コストと組織上の困難を伴います。
高度な抽象化を行うことで、高次のエンティティ「構造単位」または「組織階層」を区別できます。これらは、再帰リンク（それ自体へのフィールド。通常、ParentIdなどと呼ばれます）を持つテーブルのデータベース構造に表示されます。 このようなテーブルから、階層を拡張して、無制限にネストできます。 2番目の階層でも同じことが起こります。高次の「アクティビティの分類」の本質を選び出します（図3を参照）。 したがって、接続の畳み込みを行い、8つの「多対多」関係を1つのそのような関係に変えました。 ただし、この場合、一般化するとセマンティクスが失われます。つまり、企業と専門分野の関係は必要ありません（この例では）。企業は「組織階層」の構造単位であり、専門分野は「活動の分類」に含まれます。次に、図3の図によれば、このような接続が可能です。 ただし、情報システムは、ユーザーが論理レベルでこのタイプの通信を作成することを禁止する必要があります。これは、情報の整合性の側面であり、DBMSの必須機能です。
（図3）
論理レベルはドメインメタモデルによって提供され、アプリケーションレベルで動的に解釈され、プログラムコードを変更せずにドメインロジックを変更できるため、システムの柔軟性が向上します。 論理レベルで特定のタイプの通信を有効または無効にするには、これをメタモデルの正式な用語で設定するだけで十分です。
（図4）
リンクパラメーター（パラメーターのいくつかのグループを含む）を導入する場合、リンクを3つに分割して図3の構造を変更する必要があります。 さらに、メタデータは、サブジェクトエリアのセマンティクスを表示するために、関係の確立に関する論理的な制限を定義します。各企業は産業と方向性に携わっています。 部門と部門は、産業、指示、専門分野に従事している場合があります。 部門および部門（ただし、企業は除く）には特定のポジションがあります。 企業や部門（部門ではなく）は、業界や方向に属する（専門分野ではない）他の市場エンティティの需要を満たすことを目的としています。 したがって、たとえば、会社と専門分野との間の「ポジション」の属性グループとの通信は論理的に禁止されています。 図に示すように、データベースクロスタブには、いくつかのタイプの関係に対して1つのグループのパラメーターのみが含まれます。 4。
（図5）
しかし、問題は、エンティティの属性をどこに保存するかです。 実際、表「組織階層」には、抽象化の最も低い順序のすべてのエンティティに共通する属性のグループ（会社、部門、部門）のみを含めることができます。 また、多数の「空の」セルを持つ異常な構造を作成しないように、すべての非交差属性を別々のテーブルに配置する必要があります。 したがって、階層テーブルと同じデータベース内に、抽象化レベルの低いいくつかのテーブルが必要になります。 そして、それらは、「組織階層」テーブルとの1対1の関係によって結合された、テーブルグループ全体の共通（より正確には同じ）主キーに関連付けられます。 このような関係（図5を参照）は、4つのテーブルのうちの1つだけに「組織階層」からの対応する主キーを持つレコードの存在を提供します。 1対1の関係または「スーパータイプとシブタイプ識別子」のグラフィックイメージは、データベース情報モデル（ErWin、Logic Works、Rational Rose、ER /）を開発するための多数のCASEツールで使用されるIDEF1表記から取得されます。スタジオなど）。
（図6）
メタモデル要素の説明（図6）：
プロファイル -エンティティまたはプロファイルは、オブジェクトドメインの2次の表示です。 プロファイルには、情報システム全体でそれを参照するために使用されるパススルー識別子がありますが、外部リンクにはURIが使用されます。
テンプレート -テンプレート。多重継承と間接継承をサポートするオブジェクトモデルのクラスの類似物。 多くのことは、各プロファイルは複数のテンプレートから継承でき、間接的な継承は「タブ」を関連付ける可能性で表現されます-テンプレートはプロパティのグループであり、テンプレートは互いにタブを継承できませんが、別の分類ブランチから任意のテンプレートからタブを受け取ります。
URIは、ドメインオブジェクト、オブジェクトプロパティ、関係、およびメソッドへの外部参照に使用される一意のプロファイル識別子です。 URIを使用すると、メタモデルのすべての要素と、サブジェクト領域の情報モデルのすべての要素に対処できます。
関係タイプ -接続プロファイルのタイプ。
関係-2つ以上のプロファイル（抽象化の第2レベル）または2つ以上のエンティティ（関係モデルのレベル）間の関係。
リンク -接続に複数のプロファイルを含めることができるプロファイル（エンティティ）へのリンク。
タブ -プロファイルプロパティのグループは、データベーステーブルの形式でリレーショナルモデルにマップされます。
プロパティ -プロファイルプロパティは、ほとんどの場合データベースフィールドの形式でリレーショナルモデルに表示されますが、ディレクトリおよび分類子の場合、プロパティは「外部キー」またはルックアップテーブルおよびプロファイルタブとの多対多の関係で表示できます。
タイプ -プロファイル（エンティティ）属性に割り当てられたデータタイプ。
メソッド -プロファイルのビジネスロジックを実装するメソッドまたは関数。
モデルの抽象化の第2レベルでは、ベースの関係構造をさらに一般化するたたみ込みになります（図6を参照）。 図では、メタモデル要素が表示されています。黄色と緑の色がそれぞれエンティティと関係を担当し、灰色のテーブルのグループがエンティティ属性を担当しています。 このような構造は、応用情報システムの分野の大部分の主題分野に適しています。 これは、より一般化されたカテゴリのテーブルの構造を記述するメタデータ構造です。これにより、ソフトウェアは、データベース構造やメタデータではなく、メタモデルの構造、つまり2次抽象化に依存できます。 ただし、メタモデルには、適用された問題を解決するための十分な特異性がなく、詳細化する必要があります。これは、最初の抽象レベルで行われます（図4を参照）。 したがって、抽象化のレベルが異なる2つの基本構造が、同じデータベースに並列に格納されています。 プロファイルは1対1の関係（または「スーパータイプとシブタイプの差別化要因」）ですべての1次エンティティに関連付けられた抽象的な2次エンティティであるため、それらの間の接続は一意の識別子を介して行われます。図5および上記の説明を参照してください）。
第二部に続く。
説明のために、別のスキームを追加します。これについては、第2部で説明します。
ご清聴ありがとうございました。