概念: 概念的なデータ モデリング
トピック
概論
参考資料 [NBG01] で定義されているように、概念的なデータ モデリングは、システムの永続的データや永続的データ記憶領域の開発の初期段階を表します。多くの場合、システムの永続的データは、リレーショナル データベース管理システム (RDBMS) によって管理されます。ビジネス モデルやシステム要求から概念レベルで割り出されたビジネス エンティティやシステム エンティティは、ユース ケース分析、ユース ケース設計、データベース設計の各作業を経て、RDBMS に実装される詳細な物理テーブル設計へと発展します。ここで説明する概念的なデータ モデルは、独立した成果物ではないことに注意してください。概念的なデータ モデルは、既存のビジネス モデリング、要求、分析、設計の作業分野の成果物に含まれる情報のうち、データ モデルの開発に関連する情報を組み合わせたビューです。
通常データ モデルは、次の 3 つの一般的な段階を経て発展します。
- 概念段階 この段階では、高レベルの主要ビジネス エンティティとシステム エンティティとそれらの関係を特定します。これらは、システムが取り組む問題の範囲を定義します。これらの主要ビジネス エンティティとシステム エンティティの定義では、ビジネス分析モデルに含まれるビジネス モデリング用 UML プロファイルのモデリング要素と、分析モデルの分析クラス モデル要素を使用します。
- 論理段階 この段階では、概念的な高レベルのビジネス エンティティとシステム エンティティを、より詳細な論理エンティティへと洗練させます。これらの論理エンティティとその関係は、データベース設計用 UML プロファイルのモデリング要素を使用して、論理データ モデルで定義することもできます。詳しくは、「ガイドライン: データ モデル」を参照してください。この省略可能な論理データ モデルは、「成果物: データ モデルの一部であり、独立した RUP 成果物ではありません。
- 物理段階 この段階では、論理クラス設計を、詳細かつ最適化された物理データベース テーブル設計へと変換します。物理段階には、このほかに、データベース テーブル設計と、テーブルスペースやデータベース記憶領域設計のデータベース コンポーネントとのマッピングも含まれます。
データベース設計に関連する作業はソフトウェア開発ライフサイクルの全体に及び、初期データベース設計作業は方向づけフェーズの間に始まる場合もあります。ビジネス モデリングを使用してアプリケーションのビジネス状況を記述するプロジェクトでは、ビジネス ユース ケース モデルのビジネス アクターやビジネス ユース ケース、ビジネス分析モデルのビジネス ワーカーやビジネス エンティティの特定と共に、概念レベルのデータベース設計が始まります。ビジネス モデリングを使用しないプロジェクトでは、ユース ケース モデルのシステム アクターやシステム ユース ケース、ユース ケースの実現の分析モデルの分析クラスの特定と共に、概念レベルのデータベース設計が始まります。
次のダイアグラムは、ビジネス モデル、要求モデル、分析モデルに含まれる概念的なデータ モデルの要素を表しています。

以降では、システムの永続的データに対する初期の概念的なデータ モデルの定義に使用できる、ビジネス モデル、ユース ケース モデル、分析モデルの要素について説明します。
概念的なデータ モデリングの要素
ビジネス モデル
ビジネス ユース ケース モデル
ビジネス ユース ケース モデルは、ビジネス アクターとビジネス ユース ケースから構成されます。ビジネス ユース ケースは、システム開発のコンテキストの定義に使用される主要なビジネス プロセスを表します。ビジネス アクターは、ビジネス ユース ケースを通じてビジネスと相互作用する主要な外部エンティティを表します。次のダイアグラムは、オンライン オークション アプリケーションの非常に単純なビジネス ユース ケース モデルの例です。

ビジネス アクターは、システムのスペースの問題にとって重要なエンティティであるため、概念的なデータ モデルのエンティティの候補になります。たとえば上の例では、ビジネス アクターの「買い手」と「売り手」が、オンライン オークション アプリケーションで情報を格納しなければならないエンティティの候補になります。
ビジネス分析モデル
ビジネス分析モデルには、ビジネス ユース ケースのワークフローの分析によって特定されたビジネス ワーカーとビジネス エンティティをモデル化するクラスが含まれています。ビジネス ワーカーは、ワークフローの実行に必要な作業を行うワーカーを表します。ビジネス エンティティは、ワークフローの間にビジネス ワーカーによって使用または作成される「もの」です。多くの場合、ビジネス エンティティは、システムで永続的に格納する必要がある情報の種類を表します。
次のダイアグラムは、「オンライン オークションを提供する」というタイトルの、オークションを管理するためのビジネス ユース ケースのシナリオに含まれるビジネス ワーカーとビジネス エンティティを示すシーケンス図です。

この単純な例では、「オークション管理者」オブジェクトが、オンライン オークション管理システム自体が実行すると考えられるビジネス ワーカーの役割を表しています。「オークション」オブジェクトと「オークション アイテム」オブジェクトは、ビジネス アクター「売り手」と「買い手」の代理人として働く「オークション 管理者」ワーカーによって使用または作成されるビジネス エンティティです。データベース設計の観点からは、「オークション」と「オークション アイテム」の 2 つのビジネス エンティティが、概念的なデータ モデルのエンティティの候補になります。
要求モデルと分析モデル
ビジネス モデリングを行わないプロジェクトでは、要求 (システム ユース ケース) モデルと分析モデルに含まれるモデル要素を、初期の概念的なデータ モデルの開発に使用できます。ビジネス モデリングを使用するプロジェクトでは、ビジネス分析モデルで特定されたビジネス エンティティと関係を、分析モデルでエンティティ クラスとして洗練、詳細化します。
システム ユース ケース モデル
システム ユース ケース モデルには、ユーザーとシステムの主な相互作用を定義するシステム アクターとシステム ユース ケースが含まれています。システム ユース ケースは、システムの機能的な要求を定義します。
概念的なデータ モデリングの観点から見ると、システム アクターは、システムで永続的な情報を格納する必要があるシステム外部のエンティティを表しています。このことは、システム アクターが、開発対象のシステムとの間でデータを送受信する外部システムである場合、特に重要になります。システム アクターは、ビジネス ユース ケース モデルのビジネス アクターやビジネス分析モデルのビジネス ワーカーから派生させることができます。
下のダイアグラムは、オンライン オークション システムのビジネス ユース ケース モデルを表しています。このモデルでは、ビジネス アクター「買い手」と「売り手」が汎用のビジネス アクター「ユーザー」から派生しています。さらに、支払いを外部エンティティで処理する必要性を反映して、「クレジット サービス事務所」という名前の新しいシステム アクターが追加されています。この新しいシステム アクターもまた、概念的なデータ モデルのエンティティの候補になります。

分析モデル
分析モデルには、システム ユース ケースのユース ケースの実現で特定された分析クラスが含まれています。概念的なデータ モデリングの観点から見て特に重要な分析クラスは、エンティティ分析クラスです。「ガイドライン: 分析クラス」で定義されているように、エンティティ分析クラスは、システムで永続的に格納しなければならない情報を表します。エンティティ分析クラスとその関係は、アプリケーションの初期データ モデルの基盤になります。
分析モデルの概念的なエンティティ分析クラスは、設計モデルの論理的な永続的設計クラスに洗練、詳細化することもできます。これらの設計クラスは、データ モデルのテーブルの候補を表します。クラスの属性は、テーブルの列の候補になり、そのキーの候補にもなります。設計モデルの要素をデータ モデルの要素にマッピングする方法については、「ガイドライン: リレーショナル データベースのフォワード エンジニアリング」を参照してください。
|