オブジェクト指向のデータベース継承。オブジェクト指向データベースモデル。限られたパフォーマンスチューニングオプション

上記のMDに基づくデータベーステクノロジは、データモデリングに重点を置いた、情報ストレージの静的な概念に基づいています。ただし、次のような複雑で相互接続されたデータベースオブジェクトを使用したテクノロジーアプリケーションの新しい領域。

コンピューター支援設計;

自動生産;

自動化されたソフトウェア開発;

オフィス情報システム;

マルチメディアシステム;

地理情報システム;

パブリッシングシステムなどは、実世界でのオブジェクトのモデリングに関して、静的な概念の限られた機能を実証しています。

新しいタイプの複雑な特殊データベースアプリケーションの場合、情報ストレージの動的な概念が効果的です。これにより、データと、このデータに作用するプロセスを並行してシミュレートできます。これにより、サブジェクト領域のセマンティクスを考慮に入れることができるため、これらのアプリケーションを最も適切に説明できます。この概念は、ソフトウェア開発で広く使用されているオブジェクト指向のアプローチに基づいています。この概念を実装し、オブジェクト指向パラダイム（OOP）に基づくMDは、オブジェクト指向データモデル（OOMD）と呼ばれます。

OOMDの構築は、サブジェクト領域がオブジェクトのセットによって記述できるという仮定から始まります。各オブジェクトは、「実世界」のオブジェクトの状態とそれに関連するアクションを説明する属性を含む、一意に識別可能なエンティティです。オブジェクトの現在の状態は、単純または複雑な1つ以上の属性によって記述されます。単純な属性は、プリミティブ型（整数、文字列など）であり、リテラル値をとることができます。複合属性には、コレクションやリンクを含めることができます。参照属性は、オブジェクト間の関係を表します。

オブジェクトの重要なプロパティは、そのIDの一意性です。したがって、オブジェクト指向システムのすべてのオブジェクトには、独自の識別子が必要です。

オブジェクト識別子（OID）は、個々のオブジェクトにタグを付けるデータベース内部の方法です。クエリを設定したり情報を表示したりするためにダイアログプログラムを使用するユーザーには、原則として、これらの識別子は表示されません。これらは、DBMS自体によって割り当てられて使用されます。各DBMSの識別子のセマンティクスは異なります。ランダムな値にすることも、データベースファイル内のオブジェクトを見つけるために必要な情報（ファイル内のページ番号やオブジェクトの最初からのオフセットなど）を含めることもできます。これは、オブジェクトへの参照を整理するために使用する必要がある識別子です。

すべてのオブジェクトはカプセル化されます。つまり、オブジェクトの表現または内部構造はユーザーから隠されたままになります。代わりに、ユーザーはこのオブジェクトがいくつかの機能を実行できることだけを知っています。たとえば、WAREHOUSEオブジェクトの場合、ACCEPT_PRODUCT、EXIT_TOBAPなどのメソッドを適用できます。カプセル化の利点は、これらのオブジェクトを使用するアプリケーションを作り直すことなく、オブジェクトの内部表現を変更できることです。言い換えれば、カプセル化はデータの独立性を意味します。

オブジェクトは、データと関数（OOPによるとメソッド）をカプセル化します。メソッドは、オブジェクトの動作を定義します。これらを使用して、属性の値を変更することでオブジェクトの状態を変更したり、選択した属性の値を照会したりできます。たとえば、新しい賃貸物件に関する情報を追加したり、従業員の給与情報を更新したり、特定のアイテムに関する情報を印刷したりする方法がある場合があります。

同じ属性のセットを持ち、同じメッセージに応答するオブジェクトは、次のようにグループ化できます。 クラス（文献では、「クラス」と「タイプ」という用語はしばしば同じ意味で使用されます）。このような各クラスには、データ要素であるオブジェクトという独自の代表があります。特定のクラスのオブジェクトはそれと呼ばれます コピー.

一部のオブジェクト指向システムでは、クラスもオブジェクトであり、呼び出される独自の属性とメソッドを持っています クラス属性とクラスメソッド。

重要なOOPの概念は クラス階層とコンテナ階層.

クラス階層この場合はスーパークラスと呼ばれる各クラスが独自のサブクラスを持っている可能性を意味します。例として、次のチェーンを与えることができます。企業のすべてのプログラマーはその従業員であるため、OOMD内のPROGRAMMERSクラスのオブジェクトであるすべてのプログラマーは、EMPLOYEEのオブジェクトでもある従業員でもあります。クラス。したがって、PROGRAMMERSはサブクラスになり、EMPLOYEESはスーパークラスになります。しかし、プログラマーはシステムとアプリケーションに分けることもできます。したがって、PROGRAMMERSは、サブクラスSIS_PROGRAMMERSおよびAPPLICATION_PROGRAMMERSのスーパークラスになります。このチェーンをさらに続けると、サブクラスの各オブジェクトが対応するスーパークラスの変数とメソッドのインスタンスを継承するクラス階層が得られます。

継承にはいくつかのタイプがあります-単一、複数、および選択的です。単一継承は、サブクラスが最大で1つのスーパークラスから継承する場合です。多重継承-複数のスーパークラスからの継承。選択的継承により、サブクラスはそのスーパークラスから限られた数のプロパティを継承できます。

変数インスタンスの継承は呼び出されます 構造的継承、メソッドの継承- 行動の継承、および異なるクラスに同じメソッドを使用する機能、またはむしろ、異なるクラスに同じ名前の異なるメソッドを適用する機能が呼び出されます ポリモーフィズム.

オブジェクト指向アーキテクチャには、別のタイプの階層もあります- コンテナ階層..。これは、一部のオブジェクトを概念的に他のオブジェクトに含めることができるという事実にあります。したがって、DEPARTMENTクラスのオブジェクトには、部門の長に対応するEMPLOYEESクラスのオブジェクトへのリンクであるパブリック変数HEADが含まれている必要があります。また、この部門で働く従業員。

一部のオブジェクト指向システムでは、クラスもオブジェクトであり、独自の属性とメソッドを持っています。クラスの一般的な特性は、その属性によって記述されます。オブジェクトクラスのメソッドは、実世界のオブジェクトのプロパティに似ています。特定のクラスに属するすべてのオブジェクトには、これらのプロパティがあります。したがって、オブジェクトを作成するときは、その固有のプロパティを定義するために、オブジェクトが属するクラスを宣言する必要があります。

ユーザーとオブジェクトはメッセージを介して対話します。各メッセージに応答して、システムは適切なメソッドを実行します。

オブジェクトモデル内のすべてのリンクは、通常OIDとして実装される参照属性を使用して作成されます。

リレーショナルデータベースの関係は、主キーと外部キーのマッピングによって表されます。ベース自体には、テーブル間の関連付けを形成するための構造はなく、テーブルを結合するときに必要に応じてリンクが使用されます。対照的に、各オブジェクトには関連付けられているオブジェクトの識別子が含まれているため、関係はオブジェクト指向データベースのバックボーンを形成します。

OOMDでは、従来のリンクだけでなく、継承によって条件付けられたリンクも実装できます。

1対1のコミュニケーション（1：1）オブジェクトAとBの間は、オブジェクトBの参照属性をオブジェクトAに追加し、（参照整合性を維持するために）オブジェクトAの参照属性をオブジェクトBに追加することで実装されます。

1対多の関係（1：M）オブジェクトAとBの間は、オブジェクトAにオブジェクトBへの参照属性を追加することによって実装され、オブジェクトAからオブジェクトBへの参照のセットを含む属性（たとえば、参照属性B（OID2、OID3 ...）が追加されます。オブジェクトA、およびOID2、OID3、...を持つオブジェクトインスタンスBに、参照属性A：OID1が追加されます。

多対多の関係（M：N）オブジェクトAとBの間は、リンクのセットを含む属性を各オブジェクトに追加することによって実装されます。

OOMDでは、あるクラスのオブジェクトに他のクラスのオブジェクトがそのパーツとして含まれることを表す、全体からパーツへの関係を使用できます。本番データベースの場合、PRODUCTクラスとPARTクラスおよびASSEMBLYクラスの間には全体的な関係があります。この関係は、特別なセマンティクスを持つ多対多の関係の変形です。全体から部分への関係は、関連するオブジェクト識別子のセットを使用して、他の多対多の関係と同様に実装されます。ただし、通常の多対多の関係とは対照的に、意味的な意味は異なります。

オブジェクト指向パラダイムは継承をサポートしているため、OOMDは「is」タイプの関係と「extends」タイプの関係を使用できます。 is関係は、一般化と特殊化の関係とも呼ばれ、サブクラスがスーパークラスの特殊なケースである継承階層を生成します。これにより、再継承された特性を記述する必要がなくなります。「extends」関係を使用する場合、サブクラスは特定のケースに限定されるのではなく、スーパークラスの機能を開発します。

整合性制約やデータ操作などのコンポーネントがOOMDでどのように実装されているかを検討してください。

これらのコンポーネントの機能は、モデルの詳細によって決定されます。 OOMDのこの特異性は、主に、オブジェクトカプセル化、つまり内部構造の非表示構造、事前定義されたメソッドを介したデータへのアクセス、クラス階層、コンテナ階層などの独自の内部概念によって決定されます。

OOMDの特異性は、オブジェクトの特異性によっても決定されます。それは、オブジェクトをクラスにグループ化する必要性に現れます。各オブジェクトは、タスクに応じて1つまたは別のクラスに属し、1つのオブジェクトは一度に複数のクラスに属することができます（たとえば、PROGRAMMERSおよびHIGHLY PAIDファミリー）。オブジェクトのもう1つの特殊性は、あるクラス（サブクラス）から別のクラス（サブクラス）に「オーバーオーバー」する可能性があることです。したがって、システム・プログラマーは時間の経過とともに適用される可能性があります。したがって、クラス階層は、以前のように階層モデルに類似していませんが、システムがクラス階層内の各オブジェクトの場所を変更できる必要があります。たとえば、内で「上」または「下」に移動します。この階層。ただし、より複雑なプロセスも可能です。システムは、オブジェクトを階層の任意の最上位にいつでもアタッチ（デタッチ）できるようにする必要があります。

整合性制約は、OOMDで重要な役割を果たします。オブジェクト指向MDのリンクが機能するには、リンクの両側のオブジェクト識別子が一致している必要があります。たとえば、従業員とその子供との間に関係がある場合、子供を表すオブジェクトが従業員を表すオブジェクトに挿入されると、後者の識別子が対応するオブジェクトに追加されるという保証が必要です。この種のリンク整合性は、リレーショナルデータモデルの参照整合性にいくぶん類似しており、フィードバックを使用して確立されます。リンクの整合性を確保するために、デザイナには、逆オブジェクト識別子の場所を指定するために必要な特別な構文が提供されます。リンクの整合性（およびリレーショナルデータベースの参照整合性）に制約を設定する責任は、設計者にあります。

OOMDでは、データの記述と操作の両方が、同じオブジェクト指向の手続き型言語を使用して行われます。

ODMG（Object Database Management Groop）グループは、オブジェクトデータベーステクノロジの標準化の問題を扱います。彼女は、データベースオブジェクトのセマンティクスの標準モデルを定義するオブジェクトモデル（ODMG 2.0は1997年9月に採用されました）を開発しました。このモデルは、オブジェクト指向DBMS（OODBMS）が理解して実装できる組み込みのセマンティクスを定義するため、重要です。このセマンティクスを使用するライブラリとアプリケーションの構造は、特定のオブジェクトMDをサポートするさまざまなOODBMS間で移植可能である必要があります。 ODMGアーキテクチャの主なコンポーネントは、オブジェクトモデル（OM）、オブジェクト定義言語（ODL）、オブジェクトクエリ言語（OQL）、およびC ++、Java、およびSmalltalkにリンクする機能です。

ODMG 2.0標準に準拠したオブジェクトデータモデルは、次のプロパティによって特徴付けられます。

基本的な構成要素は、オブジェクトとリテラルです。各オブジェクトには一意の識別子があります。リテラルには独自の識別子がなく、オブジェクトとして個別に存在することはできません。リテラルは常にオブジェクトに埋め込まれており、個別に参照することはできません。

オブジェクトとリテラルはタイプが異なります。各タイプには独自のドメインがあり、そのタイプのすべてのオブジェクトとリテラルによって共有されます。タイプにも動作があります。型に何らかの動作がある場合、その型のすべてのオブジェクトは同じ動作をします。実際には、型は、オブジェクトの作成元のクラス、インターフェイス、または単純なデータ型（整数など）にすることができます。オブジェクトは、型のインスタンスと考えることができます。

オブジェクトの状態は、一連のプロパティによって実装された一連の現在の値によって決定されます。これらのプロパティは、オブジェクトの属性、またはオブジェクトと1つ以上の他のオブジェクト間の関係にすることができます。

オブジェクトの動作は、オブジェクトまたはオブジェクト自体に対して実行できる一連の操作によって決定されます。操作には、厳密に定義されたタイプの入力パラメーターと出力パラメーターのリストを含めることができます。各操作は、型指定された結果を返すこともできます。

データベース定義は、オブジェクト定義言語（ODL）で記述されたスキーマに格納されます。データベースにはオブジェクトが格納されているため、さまざまなユーザーやアプリケーションで共有できます。

OOMDに基づくDBMSは、オブジェクト指向DBMS（OODBMS）と呼ばれます。これらのDBMSは第3世代DBMSと呼ばれます* （*データストレージモデルの開発の歴史は、多くの場合、3つの段階（世代）に分けられます。第1世代（1960年代後半から70年代前半）-階層モデルとネットワークモデル、第2世代（1970〜1980年代頃）-リレーショナルモデル;第3世代（1980年代-2000年代初頭）-オブジェクト指向モデル。）.

今日、オブジェクト指向データベースは、さまざまな組織でさまざまなタスクを解決するために使用されています。情報技術データの分野で蓄積された経験の分析と一般化により、オブジェクト指向データベースの使用が正当化されるアプリケーションを特定することが可能になりました。

このアプリケーションは、相互作用する多数のパーツで構成されています。それらのそれぞれには、他の人の行動に依存する独自の行動があります。

システムは、大量の非構造化データまたは複雑なデータを処理する必要があります。

アプリケーションはデータへの予測可能なアクセスを提供するため、オブジェクト指向データベースのナビゲーションの性質は重大な欠点にはなりません。

アドホックリクエストの必要性は限られています。

保存されたデータの構造は、本質的に階層的または類似しています。

現在、ソフトウェア市場には多くのオブジェクト指向DBMSがあります。テーブル 10.6は、このクラスの商用システムの一部を示しています。

表10.6

現代の商用OODBMS、

彼らの製造会社と応用分野

オブジェクトデータベースとリレーショナルデータベースの根本的な違いの1つは、新しいデータ型を作成して使用する機能です。 OODBMSの重要な機能は、新しいタイプの作成がベースコアの変更を必要とせず、オブジェクト指向プログラミングの原則に基づいていることです。

OODBMSのコアは、オブジェクト操作用に最適化されています。そのための自然な操作は、オブジェクトのキャッシュ、オブジェクトのバージョン管理、特定のオブジェクトへのアクセス権の分離です。 OODBMSは、接続されたデータをフェッチする必要があるために追加の内部操作が発生するリレーショナルDBMSと比較して、オブジェクトにパックされたデータへのアクセスと取得を必要とする操作のパフォーマンスが高いという特徴があります。

OODBMSにとって非常に重要なのは、あるデータベースから別のデータベースにオブジェクトを移動する機能です。

OODBMSに基づいてさまざまなアプリケーションを作成する場合、特定のDBMSのクラスの組み込み構造が重要です。クラスライブラリは、原則として、すべての標準データタイプだけでなく、マルチメディアの拡張セットや、ビデオ、サウンド、アニメーションフレームのシーケンスなどの他の複雑なデータタイプもサポートします。一部のOODBMSでは、ドキュメンタリー情報の保存と全文検索を可能にするクラスライブラリが作成されています（たとえば、Jasmine、ODB-Jupiter）。基本的なクラス構造の例を図1に示します。 10.17。

その中の主要な位置は、データベースへのアクセスを制御し、インデックスを作成するために必要なすべてのプロパティとメソッドを含むTOdbObjectクラスによって占められています。他のすべてのクラスは、実装するタイプと特定のインデクサーの検証チェックを追加することにより、そのメソッドをオーバーライドします。

図からわかるように。 10.17では、ドキュメンタリー情報の処理に焦点を当てた構造内に、TOdbText、TOdbDocument、TODBTextDocumentなどのさまざまなクラスがあります。各ドキュメントは個別のオブジェクトで表されます。したがって、ドキュメントの保存の自然さが保証されます。最も重要な操作の1つは、要求によるドキュメントの検索です。ほとんどのクラスでは、特定のキーの値でオブジェクトを検索する機能が実装されています。 TOdbTextクラスには、自然言語で書かれたフレーズの検索クエリを作成する機能が実装されています。

TOdbDocumentクラスは特別で、さまざまなタイプのオブジェクトを含めることができます。これはフィールドで構成され、各フィールドには名前があり、特定のタイプのオブジェクトに関連付けられています。このクラスの存在により、ユーザーはタイプのセットを拡張する機会が得られます。コンテナオブジェクト（ドキュメント）を変更することで、特定のフィールドセットを指定して、新しいタイプのドキュメントを取得できます。

OODBMS開発者は、ODB-Jupiterに基づいて、保存されたデータの普遍的な構造と強力な検索エンジンを備えた、フル機能の情報検索システムODB-Textを作成しました。 ODB-テキストシステムは、集合的なドキュメント処理と企業アーカイブのためのツールです。考えられるアプリケーションの中で、現代のオフィスでのドキュメント管理の自動化、参照および情報システムの構築（よく知られている法務データベースと同様）、ネットワークデータベースの保守、人事記録、書誌などを挙げます。

41.適用されたISの設計の特徴。 IP開発のフェーズ。（トピック11、100〜103ページ）。

11.1.3。応用ICシステム設計の特徴

情報システムを構築（選択、適応）する場合、2つの主要な概念、2つの主要なアプローチを使用できます（3番目の概念はそれらの組み合わせです）。

1.この情報システムの助けを借りて解決する必要がある問題へのオリエンテーション。問題志向型アプローチ（または帰納的アプローチ）;

2.特定のシステム、環境で利用可能な（更新された）テクノロジーへの方向付け。テクノロジー指向のアプローチ（または演繹的アプローチ）。

概念の選択は、戦略的（戦術的）および（または）長期的（短期的）な基準、問題、リソースに依存します。

最初に利用可能な技術の可能性を研究し、次に彼らの助けを借りて解決できる実際の問題を決定する場合、技術指向のアプローチに依存する必要があります。

まず、実際の問題を特定し、次にこれらの問題を解決するのに十分な技術を導入する場合、問題志向型のアプローチに依存する必要があります。

同時に、情報システムを構築するという両方の概念は相互に依存しています。新しいテクノロジーの導入は解決される問題を変え、解決される問題の変化は新しいテクノロジーを導入する必要性につながります。どちらも下された決定に影響を与えます。

システムの設計（開発）および適用される（企業の）情報システムの使用は、情報システムの次のライフサイクルを経る必要があります。

-設計前の分析（他の同様のシステム、プロトタイプ、開発中のシステムの違いや機能などの作成経験）、システムの外部症状の分析。

-システム内分析、内部分析（システムサブシステムの分析）;

-システムの体系的（形態的）記述（提示）（体系的目標、体系的関係および環境との接続、他のシステムおよび体系的リソースの記述-材料、エネルギー、情報、組織、人間、空間および時間）;

-妥当性、効率性、持続可能性（信頼性）の基準の決定。

-システムのサブシステムの機能説明（モデルの説明、サブシステムの機能のためのアルゴリズム）;

-システムのプロトタイピング（レイアウトの説明）、システムのサブシステムの相互作用の評価（レイアウトの開発-システムを満たすための簡略化された機能の説明、手順、およびこれらのレイアウトの相互作用の承認を伴うサブシステムの実装目標）、妥当性、安定性、効率性の基準の「レイアウト」を使用することは可能ですが、

-システムの「組み立て」とテスト-本格的な機能サブシステムと基準の実装、定式化された基準に従ったモデルの評価。

-システムの機能;

-システムとそのアプリケーションのさらなる開発のための目標の決定。

-システムのメンテナンス-機能のモードでのシステムの機能の明確化、変更、拡張（進化を目的とした）。

これらの段階は、情報システムのリエンジニアリングの基本です。

企業情報システムの開発は、原則として、非常に特定の企業のために実行されます。企業の主題活動の詳細は、間違いなく情報システムの構造に影響を与えます。しかし同時に、異なる企業の構造は一般的に互いに類似しています。各組織は、その活動の種類に関係なく、1つまたは別の種類の企業活動を直接実行するいくつかの部門で構成されています。そして、この状況は、どのような種類の活動に従事していても、ほとんどすべての組織に当てはまります。

したがって、どの組織も相互作用する要素（サブディビジョン）のセットと見なすことができ、それぞれが独自のかなり複雑な構造を持つことができます。部門間の関係も非常に複雑です。一般に、企業の部門間には3つのタイプのリンクがあります。

機能的な接続-各部門は、単一のビジネスプロセス内で特定の種類の作業を実行します。

情報通信-部門は情報（文書、ファックス、書面および口頭での注文など）を交換します。

外部関係-一部のユニットは外部システムと相互作用し、それらの相互作用は情報と機能の両方である可能性もあります。

さまざまな企業の構造の一般性により、企業情報システムを構築するためのいくつかの共通の原則を策定することができます。

一般に、情報システムを開発するプロセスは、次の2つの観点から考えることができます。

時間ごと、または開発中のシステムのライフサイクルの段階ごと。この場合、開発プロセスの動的な編成が考慮され、サイクル、ステージ、反復、およびステージの観点から説明されます。

一種のプロジェクトとして企業情報システムが開発されています。プロジェクト管理およびプロジェクト開発フェーズ（ライフサイクルフェーズ）の多くの機能は一般的であり、主題分野だけでなく、プロジェクトの性質にも依存します（エンジニアリングプロジェクトであるか経済プロジェクトであるかは関係ありません）。。したがって、最初にいくつかの一般的なプロジェクト管理の問題を検討することは理にかなっています。

プロジェクトは、当初明確に定義された目標を持ち、その達成がプロジェクトの完了を決定し、時間枠、結果、リスク、資金およびリソースの支出範囲に関する確立された要件を備えた、期限付きの意図的な別のシステムの変更です。、および組織構造用。

通常、複雑な概念（特にプロジェクトの概念）の場合、導入される概念のすべての機能を完全にカバーする明確な定式化を行うことは困難です。したがって、与えられた定義は、一意で完全であるとは主張していません。

管理オブジェクトとしてのプロジェクトの次の主な特徴は、次のとおりです。

変動性とは、システムを既存のシステムから特定のシステムに意図的に移行することです。

プロジェクトの目標の観点から説明された望ましい状態。

究極の目標の限界。

限られた期間;

限られた予算;

必要なリソースは限られています。

プロジェクトが実施されている企業にとっての目新しさ。

複雑さ-プロジェクトの進捗と結果に直接的または間接的に影響を与える多数の要因の存在。

法的および組織的サポート-プロジェクト期間中の特定の組織構造の作成。

作業効率は、プロジェクトの実装プロセスを管理することによって達成されます。これにより、リソースの割り当て、実行する作業シーケンスの調整、および内部および外部の障害の補償が保証されます。

制御システム理論の観点から、制御対象としてのプロジェクトは、観察可能かつ管理可能でなければなりません。つまり、プロジェクトの進行状況（観察可能性の特性）を常に監視できるいくつかの特性が識別されます。。さらに、プロジェクトの実施過程にタイムリーに影響を与えるメカニズムが必要です（可制御性の特性）。

可制御性の特性は、情報システムの開発プロジェクトに伴うことが多い対象領域の不確実性と変動性の条件で特に重要です。

各プロジェクトは、その実装に必要な複雑さと作業量に関係なく、開発において特定の状態を経ます。「プロジェクトがまだない」状態から「プロジェクトがもうない」状態までです。アイデアの出現からプロジェクトの完全な完了までの一連の開発段階は、通常、段階（段階、段階）に分けられます。

フェーズの数とその内容の決定にはいくつかの違いがあります。これらの特性は、特定のプロジェクトの実施条件と主要な参加者の経験に大きく依存するためです。それにもかかわらず、情報システム開発プロセスの論理と主な内容は、ほとんどすべての場合同じです。

情報システム開発の次のフェーズを区別できます。

コンセプト形成;

技術仕様の開発;

設計;

製造;

システムを稼働させる。

それぞれについて詳しく見ていきましょう。 2番目と部分的に3番目のフェーズは通常、システム設計のフェーズと呼ばれ、最後の2つ（これには設計フェーズが含まれる場合もあります）-実装のフェーズと呼ばれます。

概念段階

アイデアの形成、目標設定;

主要なプロジェクトチームの編成。

顧客や他の参加者の動機と要件を研究する。

ベースラインデータの収集と既存の状態の分析。

基本的な要件と制限、必要な材料、財源、労働力の決定。

代替案の比較評価;

提案の提出、それらの審査および承認。

技術提案の作成

プロジェクトの主な内容、プロジェクトの基本構造の開発。

技術仕様の開発と承認。

プロジェクトの基本構造モデルの計画、分解。

プロジェクトの見積もりと予算編成、リソースの必要性の判断。

スケジュールの作成と作業スケジュールの拡大。

顧客との契約に署名する。

プロジェクト参加者のコミュニケーション手段を運用し、作業の進捗を管理します。

設計

このフェーズでは、サブシステム、それらの相互関係が決定され、プロジェクトの実行とリソースの使用の最も効果的な方法が選択されます。このフェーズの典型的な作品：

基本設計作業;

民間の技術仕様の開発;

コンセプチュアルデザイン;

技術仕様と指示を作成します。

デザインの提出、専門知識、承認。

開発

このフェーズでは、プロジェクト作業の調整と運用管理が実行され、サブシステムが製造され、結合され、テストされます。メインコンテンツ：

ソフトウェア開発作業の実施。

システムの実装の準備;

プロジェクトの主な指標の管理と規制。

システムの試運転

このフェーズでは、テストが実行され、実際の状態でシステムが試運転され、プロジェクトの結果と可能な新規契約について交渉が進行中です。主な仕事の種類：

複雑なテスト;

42.IPのライフサイクルの概念。（トピック11、103-105ページ）。

オブジェクト指向モデル

オブジェクト指向モデルでは、データを提示するときに、個々のデータベースレコードを識別することができます。オブジェクト指向プログラミング言語と同様のメカニズムを使用して、レコードとその処理機能の間に関係が確立されます。

標準化されたオブジェクト指向モデルは、ODMG-93標準（Object Database Management Group）の推奨事項に記載されています。

オブジェクト指向データベースの単純化されたモデルを考えてみましょう。オブジェクト指向データベースの構造は、ノードがオブジェクトであるツリーの形式でグラフィカルに表されます。オブジェクトのプロパティは、標準またはユーザーが作成した型（クラスとして定義）によって記述されます。クラス型のプロパティの値は、対応するクラスのインスタンスであるオブジェクトです。クラスの各インスタンスは、プロパティとして定義されているオブジェクトの子孫と見なされます。クラスのインスタンスオブジェクトはそのクラスに属し、単一の親を持ちます。データベース内の一般的な関係は、オブジェクトの一貫した階層を形成します。オブジェクト指向の図書館学データベースの論理構造の例を図1に示します。 2.9。ここで、タイプLibraryのオブジェクトは、Subscriber、Directory、およびIssuanceクラスのインスタンスオブジェクトの親です。異なるBookオブジェクトは、同じまたは異なる親を持つことができます。同じ親を持つタイプBookのオブジェクトは、少なくとも在庫番号（本のコピーごとに一意）が異なる必要がありますが、プロパティ値は同じですisbn、udc、title、author。

オブジェクト指向データベースの論理構造は、階層型データベースの構造と外見上は似ています。 2つの主な違いは、データ操作方法です。

検討対象のデータベースモデルのデータに対してアクションを実行するために、カプセル化、継承、およびポリモーフィズムのオブジェクト指向メカニズムによって強化された論理演算が使用されます。

カプセル化は、プロパティ名のスコープを、それが定義されているオブジェクトのスコープに制限します。したがって、本の著者の電話番号を指定し、名前がphoneのプロパティをCatalogタイプのオブジェクトに追加すると、SubscriberオブジェクトとCatalogオブジェクトに同じ名前のプロパティが取得されます。このようなプロパティの意味は、カプセル化されているオブジェクトによって決まります。

一方、継承は、プロパティのスコープをオブジェクトのすべての子孫に拡張します。したがって、カタログタイプのオブジェクトの子孫であるブックタイプのすべてのオブジェクトには、親オブジェクトのプロパティ（isbn、udk、title、およびauthor）を割り当てることができます。継承メカニズムの効果を直接の親族ではないオブジェクトに拡張する必要がある場合（たとえば、同じ親の2つの子孫間）、abs型の抽象プロパティが共通の祖先で定義されます。したがって、Libraryオブジェクトでの抽象プロパティのチケットと番号の定義により、Subscriber、Book、Issueのすべての子オブジェクトがこれらのプロパティを継承します。したがって、図に示されているサブスクライバークラスと発行クラスのチケットプロパティの値が一致することはありません。 2.9は同じです-00015。

オブジェクト指向プログラミング言語のポリモーフィズムとは、同じプログラムコードがさまざまなタイプのデータを処理できることを意味します。つまり、異なるタイプのオブジェクトに同じ名前のメソッド（プロシージャまたは関数）を含めることができるということです。オブジェクトプログラムの実行中、引数のタイプに応じて、同じメソッドが異なるオブジェクトを操作します。この例では、ポリモーフィズムとは、Catalogクラスとは異なる親を持つBookクラスのオブジェクトが、異なるプロパティのセットを持つことができることを意味します。したがって、Bookクラスのオブジェクトを操作するためのプログラムには、ポリモーフィックコードを含めることができます。

オブジェクト指向データベースでの検索は、ユーザーが指定したオブジェクトとデータベースに格納されているオブジェクトとの類似性を見つけることで構成されます。

図。 2.9 図書館学データベースの論理構造

リレーショナルモデルと比較したオブジェクト指向データモデルの主な利点は、オブジェクト間の複雑な関係に関する情報を表示できることです。オブジェクト指向データモデルを使用すると、単一のデータベースレコードを識別し、それらの処理の機能を定義できます。

オブジェクト指向モデルの欠点は、概念が非常に複雑で、データ処理が不便で、クエリ速度が遅いことです。

オブジェクト指向DBMSには、POET、Jasmine、Versant、O2、ODB-Jupiter、Iris、Orion、Postgresが含まれます。

データバンクは全体として、通常、経済的および法的特性に従って分類されます。

サービス提供の条件によれば、無料銀行と有料銀行は区別され、商業銀行と非営利銀行（科学、図書館、社会的に重要）に分けられます。

所有形態に応じて、BNDは国家と非国家に分けられます。アクセシビリティの程度に応じて、パブリックと限られた数のユーザーを区別します。

他のタイプの分類は、BnDの個々のコンポーネントに関連付けられています。

1.データバンクの開発は、次の4つの段階で構成されます。

ステージ1。システム要件の形成と分析：

BNDによって解決されるタスクのリストを含むシステム仕様が作成されます。

エンドユーザーとその機能のリスト。

データベースの要件のリスト。

組織内のドキュメントフロー図が作成されます。

ステージ2。概念設計：システムの情報モデルは、コンピューターのタイプやシステムソフトウェアのタイプを参照せずに作成されます。情報データベースモデルが構築されます。これは、ユーザーの観点からサブジェクト領域を最も完全に記述します。

ステージ3。実装設計：コンピューティングシステム、システムソフトウェア、およびDBMSが選択されます。データ構造が設計され、データベースデータ論理モデル（データベーススキーマ）が構築されます。これは、特定の選択されたDBMSの言語でのデータベースの論理構造の記述です。

ステージ4。データの作成とデータベースへのロード、データベースを操作するためのアプリケーションプログラムの開発とデバッグ、ドキュメントの作成を含む物理的な実装。この段階で、データベースの物理モデルが構築されます。このモデルには、使用されるストレージデバイス、データの物理的な編成方法が記述されています。データベースの物理構造の記述は、ストレージスキームと呼ばれます。現在、この種の作業を減らす傾向があります。

2.データバンクの担当者が解決する主なタスク

BNDのスタッフには、BND管理者、システムアナリスト、システムおよびアプリケーションプログラマー、オペレーター、技術的手段のスペシャリスト、マーケティングなど、さまざまなスペシャリストが含まれます。

データベースの開発および運用中に担当者が解決した主な機能とタスクをリストしてみましょう。

1）サブジェクトエリアの分析（エンドユーザーのニーズの決定、サブジェクトエリアの情報モデルの構築、整合性制約の特定）。

2）データベース構造の設計（データベースファイルの構成と構造を決定し、そのスキーマをデータ記述言語で記述します）。

3）データベースの整合性制約を設定します。

4）データベースのロードと保守（データベースの保守には、レコードの変更、削除、追加が含まれます）。ローディングおよびメンテナンス技術の開発。データ入力フォームの開発。データの入力と制御。

5）データ保護（ユーザーの差別化、保護手段の選択と検証、不正アクセスの試みの記録）。

6）データベースの回復を確実にする。

7）BnDの効率とシステム開発の分析。

8）ユーザーと協力する（回答の収集、トレーニング）。

9）システムソフトウェアのメンテナンス（取得、インストール、開発）。

10）組織的および方法論的作業（設計および近代化方法の選択、BNDの開発の計画、文書の開発）。

3.データバンクのユーザー

他のソフトウェア-組織-技術の複合体と同様に、データバンクは時間と空間に存在します。特定の開発段階があります。

設計、

実装、

サポート、

更新と開発、

完全な再編成。

存在の各段階で、さまざまなカテゴリの消費者がデータバンクに接続されます。

利用者

これは、関心がデータバンクに関連しているユーザーの主なカテゴリです。作成されたデータバンクの詳細に応じて、エンドユーザーのサークル内で本質的に異なる場合があります。これらは、いくつかの情報を受け取った後にデータベースに時々データベースをアドレス指定するランダムな消費者である可能性があり、通常のユーザーである可能性があります。カジュアルな顧客は、一般的または詳細な説明とともにパフォーマンスまたはサービスのカタログを閲覧して、会社の潜在的な顧客と見なすことができます。機能の実行におけるアクションの自動化を提供する、彼らのために特別に設計されたプログラムで作業する従業員は、通常のユーザーである可能性があります。たとえば、コンピュータ会社の補助部門の作業を計画している管理者は、指示に従って現在の注文を計画および整理し、生産性の進捗状況を監視し、倉庫での新規注文に必要なアクセサリを整理するのに役立つプログラムを持っています。言語およびコンピューター技術の分野でエンドユーザーに要求されるべきではない主な特別な知識。

データバンク管理者

これはユーザーのグループであり、データバンクの開発の初期段階で、一連のエンドユーザーの同時操作の観点から最適な設計を担当し、サポートでは、ステージが正しい責任を負います。マルチユーザーモードでのこの情報スタックの操作。設計および再編成フェーズでは、このグループは、進行中のメンテナンスを変更または完了せずにスタックを正しく再編成できるようにする責任があります。

アプリケーション開発者と管理者

これは、データバンクの設計、作成、および再編成中に機能するユーザーのグループです。アプリケーション管理者は、機能サブシステムに統合された特定のアプリケーションまたはアプリケーションのグループを開発することにより、開発者の作業を調整します。特定のアプリケーションの開発者は、特定のアプリケーションに必要なデータベースの情報を処理します。

すべてのデータバンクですべてのタイプのユーザーが選択されているわけではありません。表形式のDBMS、データバンク管理者、アプリケーション管理者、開発者を使用した情報システムの開発は、多くの場合、1人の人間で行われることが知られています。ただし、大企業または企業のビジネスプロセスのすべてまたは大部分を自動化するために使用される、最新の複雑な企業データベースを作成する場合、アプリケーション管理者と開発部門のグループが存在する場合があります。最も難しい操作モードは、データベース管理者のグループに割り当てられます。

それらをさらに詳しく考えてみましょう。

BnD管理者グループの一部は次のとおりです。

システムコメンテーター;

情報サポートデータバンクに関連するデータ構造と外観の開発者。

技術データ処理プロセスの開発者。

システムおよびアプリケーションプログラマー。

修理サービスの運営会社と専門家。

専門家を販売する際には、商用データバンクの問題が重要な役割を果たします。

DB管理者グループの主な機能

1.データ領域の調査：データ領域の説明、整合性制約のテキストのパッキング、情報の状態（可用性、機密性）の決定、消費者のニーズの決定、「データ消費者」の対応の決定、時間的データ処理特性の量。

2.データベースの構造の開発：データベースファイルと中間接続の構成と構造の定義、データを最適化する方法の選択と情報のアクセス方法、データベースをデータ記述言語（DL）で記述する。

3.データベース構造とデータベース処理手順の説明に整合性制約を設定します。

データ領域に固有の宣言型整合性制約を設定します。

データベースに格納されている情報を変更する過程で、データ領域に固有の動的整合性制約を決定する。

整合性制約の定義は、データベースの構造によって引き起こされます。

データを入力および修正するときにデータベースの整合性を維持するための手順の開発。

マルチユーザーモードでのコンシューマーの並列操作による整合性制約の決定。

4.ダウンロードを開始し、データベースをガイドします

データベースのロードを開始するための手法の開発。これは、データベースを定期的に使用してデータを変更および追加する手順とは異なります。

入力されたデータ、データ領域の実際の状態をチェックするための技術の開発。一部のデータ領域のデータベースモデルの実際のオブジェクトと相関関係は中間的であり、現在の修復の開始時に、このモデルは現在のデータ領域オブジェクトの状態に完全に対応している必要があります。

システムの設計のロードを開始する開発された技術によれば、データ入力の開始が必要になる場合があります。

5.データ保護

パスワードシステムの定義、消費者を対象とする原則、同一のデータアクセス権を持つ消費者グループの作成。

特定のデータおよび開発オブジェクトを保護するための原則の開発。ローカルおよびグローバルな情報ネットワークでの情報の流通中に情報をコーディングするための特殊な方法の開発。

データへのアクセスを修正し、セキュリティシステムに違反しようとする手段の開発。

保護システムのテスト。

保護システム違反の事例の調査とデータベース内の情報を保護するための動的な方法の開発。

6.データベースリカバリのサポート

組織の発展とは、アーカイブとデータベース回復の原則を意味します。

障害後のデータベース回復のための追加のソフトウェアおよび技術プロセスの開発。

7.データベースコンシューマーへの呼び出しの調査：必要な出力ドキュメントに従って、要求のシンボル、パフォーマンスをオンにする時間に関する一連の統計

8. BnD機能の効率の調査：

BnD機能の指標の調査

データベースの再構築（構造変更）とBNDの再編成を計画します。

9.エンドユーザーとの連携：

データ領域の変更に関する情報の収集。

BnD作業の評価に関する情報の収集。

消費者トレーニング、消費者相談;

エンドユーザーの作業に関して必要な体系的かつ教育的な文書の作成。

10.システムツールの準備とメンテナンス：

市場に存在するソフトウェアの調査、およびBNDのフレームワーク内でのそれらの使用の可能性と必要性の調査。

BNDの開発に必要な運動の組織的および技術的プログラムの開発。

BNDに接続する前に、引き換えられたソフトウェアの機能を確認します。

新しいソフトウェアのBNDへの接続の制御。

11. BNDの開発における組織的および体系的な作業：

データベース開発方法の選択または作成。

システム全体の開発の目標と方向性の決定。

BnD開発の段階を計画する。

BNDプロジェクトの一般的な辞書と概念モデルの参考書の開発。

開発されたアプリケーションの外部モデルのインストール。

新しいアプリケーションのBnDの作業への接続の制御。

1つのデータベースから相互作用する一連のアプリケーションの複雑なトラブルシューティングの可能性。

オブジェクト指向モデル（OOM）では、データを表示するときに、個々のデータベースレコードを識別することができます。オブジェクト指向プログラミング言語と同様のメカニズムを使用して、データベースレコードとその処理機能の間に関係が確立されます。

標準OOMは、ODMG-93（Object Database Management Group）標準の推奨事項に記載されています。 ODMG-93の推奨事項はまだ完全には実装されていません。重要なアイデアを説明するために、オブジェクト指向データベースのやや単純化されたモデルを考えてみましょう。

オブジェクト指向データベースの構造は、ノードがオブジェクトであるツリーの形式でグラフィカルに表されます。オブジェクトのプロパティは、いくつかの標準型（たとえば、文字列型）またはユーザーが作成した型（クラスとして定義）によって記述されます。

string型のプロパティの値は文字列です。クラス型のプロパティの値は、対応するクラスのインスタンスであるオブジェクトです。クラスの各インスタンスは、プロパティとして定義されているオブジェクトの子孫と見なされます。クラスのインスタンスオブジェクトはそのクラスに属し、単一の親を持ちます。データベース内の一般的な関係は、関連するオブジェクトの階層を形成します。

図書館学のOODBの論理構造の例を図1に示します。 3.14。ここで、タイプLIBRARYのオブジェクトは、SUBSCRIBER、DIRECTORY、およびREFERENCEクラスのインスタンスオブジェクトの親です。親が同じである異なるBOOKオブジェクトは、少なくとも在庫番号が異なる必要があります（本のコピーごとに一意です）が、プロパティ値は同じです。 isbn、udk、名前そして著者.

図3.14。図書館データベースの論理構造

OOデータベースの論理構造は、階層型データベースの構造と外見上は似ています。それらの主な違いは、データ操作の方法にあります。 OOMデータベース内のデータに対してアクションを実行するために、カプセル化、継承、およびポリモーフィズムのオブジェクト指向メカニズムによって強化された論理演算が使用されます。 SQLコマンドと同様の操作は、限られた範囲で使用できます（たとえば、データベースを作成するため）。

データベースの作成と変更には、高速データ検索のための情報を含むインデックス（インデックステーブル）の自動形成とその後の調整が伴います。

OOMデータベースに関連して、カプセル化、継承、およびポリモーフィズムの概念について簡単に考えてみましょう。

カプセル化プロパティ名のスコープを、それが定義されているオブジェクトの制限に制限します。したがって、本の著者の電話番号を設定し、名前を持つDIRECTORYタイプのオブジェクトにプロパティを追加すると、 電話、次に、SUBSCRIBERオブジェクトとDIRECTORYオブジェクトに同じ名前のプロパティを取得します。このようなプロパティの意味は、カプセル化されているオブジェクトによって決まります。

継承、それどころか、プロパティのスコープをオブジェクトのすべての子孫に拡張します。したがって、DIRECTORYタイプのオブジェクトの子孫であるBOOKタイプのすべてのオブジェクトには、親オブジェクトのプロパティを割り当てることができます。 isbn、udk、名前そして 著者。継承メカニズムの効果を直接の親族ではないオブジェクトに拡張する必要がある場合（たとえば、同じ親の2つの子孫間）、abs型の抽象プロパティが共通の祖先で定義されます。したがって、抽象プロパティの定義 チケットそして数 LIBRARYオブジェクトでは、これらのプロパティがすべての子オブジェクトSUBSCRIBER、BOOK、およびREFERENCEに継承されます。プロパティの値が偶然ではありません チケット図に示されているSUBSCRIBERクラスとDISTRIBUTIONクラスの数は同じになります-00015。

ポリモーフィズムオブジェクト指向プログラミング言語では、同じプログラムコードが異なるタイプのデータを処理できることを意味します。つまり、異なるタイプのオブジェクトに同じ名前のメソッド（プロシージャまたは関数）を含めることができるということです。オブジェクトプログラムの実行中、引数のタイプに応じて、同じメソッドが異なるオブジェクトを操作します。オブジェクト指向DBに適用されるように、ポリモーフィズムとは、DIRECTORYクラスとは異なる親を持つBOOKクラスのオブジェクトが、異なるプロパティのセットを持つことができることを意味します。したがって、BOOKクラスのオブジェクトを操作するためのプログラムには、ポリモーフィックコードを含めることができます。

オブジェクト指向データベースでの検索は、ユーザーが指定したオブジェクトとデータベースに格納されているオブジェクトとの類似性を見つけることで構成されます。ゴールオブジェクト（オブジェクトプロパティはゴールタイプ）と呼ばれるユーザー定義オブジェクトは、一般的な場合、データベースに格納されているオブジェクトの階層全体のサブセットを表すことができます。ターゲットオブジェクト、およびクエリ実行の結果は、データベース自体に格納できます。図書館カードの枚数と、図書館で少なくとも1冊の本を受け取った加入者の名前のリクエストの例を図1に示します。 3.15。

メイン尊厳 OOMとリレーショナルデータは、複雑なオブジェクトの関係に関する情報を表示する機能です。 OOMデータを使用すると、単一のデータベースレコードを識別し、それらの処理の機能を定義できます。

不利益 OOMは概念が非常に複雑で、データ処理が不便で、クエリ速度が遅いです。

図3.15。ターゲットオブジェクトを含むデータベースのフラグメント

図にリレーショナルデータモデルの形式で示されている注文タスクに戻りましょう。 3.8、そしてそれをオブジェクト指向データベースの観点から考えてください。全部で3つのクラスがあります。 クライアント», « 注文"そして" 製品"。クラスのオブジェクト " クライアント»特定のクライアントです。クラスのプロパティ-顧客番号、顧客名都市、ステータスなど。クラスメソッド-" 注文を作成する», « 請求書を支払う"など。メソッドは、オブジェクトに適用できるある種の操作です。メソッドは、オブジェクトが実行することになっていることです。テーブルに対応するクラス " 注文詳細"、必須ではありません。テーブルデータはクラスの一部にすることができます " 注文"。クラスでの存在感」 クライアント"方法" 注文を作成する「クラスのオブジェクトとの相互作用につながる」注文"そして" 製品"。この場合、ユーザーはこのオブジェクトの相互作用について知る必要はありません。ユーザーはオブジェクト "のみを参照します注文「そしてその方法を使う」 注文を作成する"。他のデータベースへの影響は、ユーザーから隠すことができます。方法が「 注文を作成する「、順番に、メソッドを指します」 顧客の信用度を確認する」、この事実はユーザーから隠すこともできます。リレーショナルデータベースでは、同じ機能を実行するには、Visual Basic for Application（VBA）でプロシージャを作成する必要があります。

90年代には、オブジェクト指向データベース管理システムの実験的なプロトタイプがありました。現在、このようなシステムが広く使用されています。特に、これらには次のDBMSが含まれます：POET（POET Software）、Jasmine（Computer Associates）、Versant（Versant Technologies）、O2（Ardent Software）、ODB-Jupiter（Inteltek Plus Research and Production Center）、およびIris、Orion、 Postgres。

基本概念

定義1

オブジェクト指向モデルデータの提示により、データベースの個々のレコードを識別することができます。

データベースレコードとその処理機能は、オブジェクト指向プログラミング言語で実装されている対応するツールと同様のメカニズムによってリンクされています。

定義2

グラフ表示オブジェクト指向データベース構造は、ノードがオブジェクトを表すツリーです。

標準タイプ（たとえば、文字列- ストリング）またはユーザーが作成したタイプ（ クラス）、説明 オブジェクトのプロパティ.

図1では、LIBRARYオブジェクトは、DIRECT、SUBSCRIBER、およびREFERENCEインスタンスオブジェクトの親です。 BOOKタイプの異なるオブジェクトは、同じまたは異なる親を持つことができます。同じ親を持つタイプBOOKのオブジェクトは、少なくとも異なる在庫番号（本のコピーごとに一意）を持っている必要がありますが、プロパティ値は同じです。著者, 名前, udkそして isbn.

オブジェクト指向データベースと階層型データベースの論理構造は、表面的には似ています。それらは主にデータ操作方法が異なります。

オブジェクト指向モデルのデータに対してアクションを実行する場合、論理演算が使用されます。論理演算は、カプセル化、継承、およびポリモーフィズムによって強化されます。いくつかの制限はありますが、SQLコマンドと同様の操作を使用できます（たとえば、データベースを作成する場合）。

データベースを作成および変更する場合、高速データ検索用の情報を含むインデックス（インデックステーブル）の自動形成とその後の調整が実行されます。

定義3

目的 カプセル化-プロパティ名のスコープを、それが定義されているオブジェクトの境界に制限します。

たとえば、作成者の電話番号を設定し、名前を持つDIRECTORYオブジェクトにプロパティが追加された場合電話、DIRECTORYオブジェクトとSUBSCRIBERオブジェクトに対して同じ名前のプロパティが取得されます。プロパティの意味は、プロパティがカプセル化されているオブジェクトによって決まります。

定義4

継承は、逆にカプセル化して、オブジェクトのすべての子孫に関連してプロパティのスコープを広げる役割を果たします。

たとえば、DIRECTORYオブジェクトの子孫であるすべてのBOOKオブジェクトには、親オブジェクトのプロパティを割り当てることができます。著者, 名前, udkそして isbn.

継承メカニズムのアクションを直接の親戚ではないオブジェクト（たとえば、同じ親の2つの子孫）に拡張する必要がある場合、抽象型プロパティはそれらの共通の祖先で定義されます腹筋.

だからプロパティ数そして チケット LIBRARYオブジェクトは、すべての子オブジェクトREFERENCE、BOOK、およびSUBSCRIBERに継承されます。そのため、SUBSCRIBERクラスとOUTPUTクラスのこのプロパティの値は同じです-00015（図1）。

定義5

ポリモーフィズム同じプログラムコードが異なるタイプのデータを処理できるようにします。

つまり、異なるタイプのオブジェクトが同じ名前のメソッド（関数またはプロシージャ）を持つことができます。

探すオブジェクト指向データベースでは、ユーザーが指定したオブジェクトとデータベースに格納されているオブジェクトとの類似性を判断することです。

オブジェクト指向モデルの長所と短所

メイン利点オブジェクト指向データモデルは、リレーショナルモデルとは対照的に、オブジェクトの複雑な関係に関する情報を表示する機能で構成されています。考慮されるデータモデルを使用すると、個別のデータベースレコードとその処理の機能を定義できます。

に短所オブジェクト指向モデルは、概念が非常に複雑で、データ処理が不便で、クエリ速度が遅いという特徴があります。

今日、そのようなシステムは非常に普及しています。これらにはDBMSが含まれます。

Postgres、
オリオン、
虹彩、
ODBJupiter、
Versant、
客観性/ DB、
ObjectStore、
スターチス、
GemStone
Gベース。

前書き

オブジェクト指向データベース（OODB）の方向性の出現は、まず、実践の必要性、つまり、以前のデータベースシステムの技術では完全に満足のいくものではなかった複雑な情報アプリケーションシステムを開発する必要性によって決定されました。もちろん、OODBはどこからともなく現れたわけではありません。対応する基礎は、データベースの分野での以前の研究と、抽象データ型とオブジェクト指向プログラミング言語を備えたプログラミング言語の長く発展している分野の両方によって提供されました。

データベースの分野での以前の作業との関係に関して、OODBの分野での作業に最も強力な影響を与えたのは、DBMSの開発と、複雑なオブジェクトの管理がサポートされた次の時系列のデータベースファミリでした。これらの活動は、OOBD組織の構造的基盤を提供しました。この要約では、OOMDとOODBMSが考慮されます。

オブジェクト指向データモデル

オブジェクト指向データモデル（OOMD）を使用して、データベースを構築するためのアプローチの1つを検討してください。 OOMDのデータモデリングは、オブジェクトの概念に基づいています。 ODMは通常、モデリング用のリレーショナルモデルの機能が不足している複雑なサブジェクト領域で使用されます（たとえば、設計自動化システム（CAD）、パブリッシングシステムなど）。

オブジェクト指向データモデルODMGは、まず第一に、1つの基本的な側面で他のモデルとは異なります。 SQLデータモデルと真のリレーショナルデータモデルでは、データベースは、それぞれテーブルまたはリレーションという同じ汎用タイプの名前付きデータコンテナのコレクションです。オブジェクト指向データモデルでは、データベースは任意のタイプのオブジェクト（データコンテナ）のコレクションです。

オブジェクト指向DBMS（OODBMS）を作成する場合、さまざまな方法が使用されます。

データベースと連携するように設計されたツールのオブジェクト指向言語への埋め込み。

オブジェクト指向関数を使用してデータベースを操作するための既存の言語の拡張。

データベースを操作するための関数のオブジェクト指向ライブラリの作成。

新しい言語と新しいオブジェクト指向データモデルの作成。

OOMDの利点には、ドメインをモデル化するための十分な機会、表現力豊かなクエリ言語、および高性能が含まれます。 OOMD内の各オブジェクトには、一意の識別子（OID-オブジェクト識別子）があります。 OIDの取得は、リレーショナルテーブルのルックアップよりも大幅に高速です。

OOMDの欠点の中には、一般的に受け入れられているモデルの欠如、OODBの作成と操作の経験の欠如、使用の複雑さ、不十分なデータ保護手段に注意する必要があります。

次に、実際のデータベース管理システムでデータモデルのサポートがどのように実装されているかを見てみましょう。

印刷