トピック

概要 ページの先頭へ

データ モデルは、システムが使用する永続的データ ストアの構造を設計するために使用します。データベース設計用の統一モデリング言語 (UML) プロファイルにより、データベース設計者に、データベースのテーブルの詳細設計を開発するときと、データベースの物理的な記憶領域のレイアウトをモデリングするときに使用できるモデリング要素が提供されます。UML データベース プロファイルでは、参照整合性 (制約とトリガ) をモデルリングするための構成要素や、データベースへのアクセスを管理するためのストアド プロシージャが提供されます。

データ モデルは、企業レベル、部署レベル、個々のアプリケーション レベルのいずれかで作成されます。企業レベルと部署レベルのデータ モデルを使用すると、ビジネスまたはビジネス ユニットのすべてのアプリケーションで使用される、主要なビジネス エンティティ (顧客や従業員) の標準的な定義が提供されます。これらのタイプのデータ モデルを使用して、企業のどのシステムが特定のビジネス エンティティのデータの「所有者」であるか、ほかのどのようなシステムがデータの (加入者の) ユーザーであるかを定義することもできます。

このガイドラインでは、リレーショナル データベースのデータ モデルを作成する際に使用する、データベース モデリング用 UML プロファイルのモデル要素を説明します。一般的なデータベース理論については多くの書籍で解説されているので、ここでは説明しません。リレーショナル データ モデルおよびオブジェクト モデルについての背景情報は、「概念: リレーショナル データベースとオブジェクト指向」を参照してください。

メモ: このガイドラインで説明しているデータ モデリングの表現は、UML 1.3 に基づいています。このガイドラインを作成した時点では、UML 1.4 データ モデリング プロファイルは利用できませんでした。

データ モデリングの段階 ページの先頭へ

参考資料 [NBG01] で説明しているように、データ モデルの開発には、概念、論理、物理の 3 つの段階があります。データ モデリングのこれらの段階は、アプリケーションの永続的データ記憶領域と取得メカニズムの設計に関する詳細レベルを反映します。概念データ モデリングに関する説明は、「概念: 概念的なデータ モデリング」を参照してください。論理データ モデリングと物理データ モデリングの概要は、この後の 2 セクションで説明します。

論理データ モデリングページの先頭へ

論理データ モデリングにおいて、データベース設計者は、アプリケーションがデータベースに保持する必要のある重要な情報を把握する、主要なエンティティと関係を識別します。ユース ケース分析ユース ケース設計クラス設計の作業では、データベース設計者設計者は共同で作業して、進行中の分析の設計やアプリケーションの設計クラスが、データベースの開発を適切にサポートしていることを確認する必要があります。クラス設計作業では、データベース設計者と設計者は、データベースにデータを保持すべき設計モデルのクラスを識別する必要があります。

設計モデルのこの永続クラスのセットでは、多くの同じニーズを満たす設計モデル ビューが提供されます。従来の論理データ モデルとは異なります。設計モデルで使用される永続クラスは、従来の論理データ モデルのエンティティと同じ手法で機能します。これらの設計クラスは、保持が必要なデータを正確に反映し、すべての保持が必要なデータ列 (属性) とキー関係が含まれます。したがって、これらの設計クラスは、物理データベース設計の最適な開始点となります。

個別の論理データ モデルの作成はオプションです。ただし、最もよい場合で、最終的に同じ情報が異なる形式で把握されます。最も悪い場合では、情報を把握できず、アプリケーションのビジネス ニーズに応えられないこともあります。特に、データベースが単一のアプリケーションをサービスするように意図されている場合、データに関するアプリケーションのビューは最適な開始点となります。データベース設計者は、この永続設計クラスのセットからテーブルを作成し、最初の物理データ モデルを形成します。

データベース設計者が、アプリケーションの設計から独立した、理想的なデータベース設計を作成する必要がある場合も、依然として存在します。この場合、論理データベース設計は、成果物: データ モデル全体の一部である、独立した論理データ モデルに表現されます。この論理データ モデルは、データをアプリケーション全体のアーキテクチャに矛盾しないように保持するためのシステム要件を満たすのに必要な、主要な論理エンティティと、その関係を表します。論理データ モデルは、後に示すデータベース設計用の UML プロファイルのモデリング要素を使用して作成されます。このアプローチを使用するプロジェクトでデータベース設計の開発を成功させるには、アプリケーション設計者とデータベース設計者の綿密なコラボレーションが絶対的に必要です。

論理データ モデルは、論理データ モデルの要素を発展させてデータベースの物理設計を作成する前に、「概念: 正規化」で定義した正規化の標準ルールを適用することで洗練されます。

次の図は、最初の物理データ モデルの作成に対して、設計モデル クラスを論理データベース設計の情報源として使用する主なアプローチを示しています。また、独立した論理データ モデルを使用する別のアプローチも示しています。

 

論理データ モデリングのアプローチ

物理データ モデリングページの先頭へ

物理データ モデリングは、データベース設計開発の最終段階です。物理データ モデルは、詳細なデータベース テーブルの設計と、永続設計クラスとその関係から最初に作成された関係で構成されます。設計モデル クラスをテーブルに変換するメカニズムについては「ガイドライン: リレーショナル データベースのフォワード エンジニアリング」を参照してください。物理データ モデルは、データ モデルの一部であり、独立した成果物ではありません。

物理データ モデルのテーブルには、明確に定義された列と、必要に応じてキーと索引が含まれます。テーブルには、必要に応じて定義されたトリガが含まれ、データベース機能とシステムの参照整合性をサポートします。テーブルのほかに、ストアド プロシージャが作成、記述され、ストアド プロシージャが存在するデータベースと関連付けられます。

次のダイアグラムは、物理データ モデルの要素の一部を示しています。このモデル例は、架空のオンライン オークション アプリケーションの物理データ モデルの一部です。ダイアグラムには、4 つのテーブル (Auction、Bid、Item、AuctionCategory) と、1 つのストアド プロシージャ (sp_Auction) とそのコンテナ クラス (AuctionManagement) が示されています。また、各テーブルの列、主キーと外部キー制約、テーブルに対して定義された索引も示されています。

 

(物理) データ モデル要素の例

物理データ モデルには、データベースの物理的な記憶領域ユニット (テーブルスペース) に対するテーブルのマッピングも含まれます。次の図は、このマッピングの例を示しています。この例では、テーブル「Auction」と「OrderStatus」は、「PRIMARY」 というテーブルスペースにマッピングされています。ダイアグラムは、テーブルの実現のデータベースへのモデリングも表しています (この例では、「PearlCircle」)。

 

データ記憶領域モデル要素の例

データベースが既に存在しているプロジェクトでは、データベース設計者は既存のデータベースをリバース エンジニアリングして、物理データ モデルを作成できます。詳しくは「ガイドライン: リレーショナル データベースからのリバース エンジニアリング」を参照してください。

データ モデル要素 ページの先頭へ

ここでは、データ モデルの主要な要素に関する一般的なモデリングのガイドラインを、データベース モデリングの UML プロファイルに基づいて説明します。各モデル要素の簡単な説明の後に、UML モデル要素の例を図で示しています。「関係」では、モデル要素の使用についても説明しています。

パッケージ ページの先頭へ

標準的な UML パッケージは、データ モデル要素のグループ化と整理に使用されます。たとえば、データ モデルを個別の論理データ モデルと物理データ モデルに整理するために、パッケージが定義されます。パッケージは、開発しているアプリケーションのビジネス ドメインで重要な、主要データ「主観的な領域」を構成する、データ モデルの論理的に関連付けられたテーブル グループを識別するためにも使用されます。次の図は、データ モデルのビューとテーブルを整理するために使用される、2 つの主観的な領域のパッケージ例 (Auction Management と UserAccount Management) を示しています。

主観的な領域のパッケージ例

テーブル ページの先頭へ

データベース モデリングの UML プロファイルでは、テーブルは ≪Table≫ というステレオタイプを持つクラスとしてモデル化されます。テーブルの列は、≪column≫ というステレオタイプを持つ属性としてモデル化されます。1 つまたは複数の列が主キーとして指定され、テーブルでの行の入力が一意となります。列は外部キーとして指定される場合もあります。主キーと外部キーには、ステレオタイプ化された操作 (それぞれ、≪Primary Key≫ と ≪Foreign Key≫) としてモデル化される制約が関連付けられます。次の図は、架空のオンライン オークション システムのオークションで売れた Item に関する情報を管理するテーブルの構造を表しています。

テーブルの例

テーブルは、次のタイプの関係を通じて、ほかのテーブルと関連付けられます。

  • 依存 (コンポジット集約)
  • 非依存 (関連)

このガイドラインの「関係」では、これらの関係の使用例を示しています。これらの関係を設計モデル要素にマッピングする方法については、「ガイドライン: リレーショナル データベースからのリバース エンジニアリング」を参照してください。

トリガ ページの先頭へ

トリガは、そのトリガが存在しているテーブルの特定のアクションの結果として実行されるように設計された手続き的な関数です。トリガは、テーブルの行の挿入、更新、削除が行われたときに実行されるように定義されます。さらに、テーブル コマンドが実行される前または後のいずれかで実行されるように指定します。トリガは、テーブルの操作として定義されます。操作は、≪Trigger≫ にステレオタイプ化されます。

トリガの例

索引 ページの先頭へ

索引は、特定の列を使用してテーブルを検索するときに、情報に高速にアクセスできるようにするメカニズムです。≪index≫ のステレオタイプを持つ、テーブルの操作としてモデル化されます。索引は一意に指定される場合や、クラスタ化または非クラスタ化として指定される場合があります。クラスタ化された索引を使用すると、テーブルのデータ行は索引値の順に整列されます。次の図に、索引操作の例 (IX_auctioncategory) を示します。

 

索引の例

ビュー ページの先頭へ

ビューは、独立した永続的な記憶領域を持たない仮想のテーブルです。ビューはテーブルの特性と振る舞いを持ち、ビューが関係を定義しているテーブルの列のデータにアクセスします。ビューは、1 つまたは複数のテーブルの情報に効果的にアクセスするために使用されます。また、ビジネス ルールを適用して、テーブルのデータへのアクセスを制限するためにも使用できます。次の例では、「Auction」ビューが、物理データ モデリングで取り上げた「Auction」テーブルの情報のビューとして定義されています。

ビューは、≪view≫ のステレオタイプを持つクラスとしてモデル化されます。ビュー クラスの属性は、ビューが参照するテーブルの列です。ビューの列のデータ タイプは、ビューとの依存関係が定義されたテーブルから継承されます。

 

 

ビューの例

ドメイン ページの先頭へ

ドメインは、複数のテーブルの列に適用可能なユーザー定義のデータ タイプを作成するためのメカニズムです。ドメインは、ステレオタイプ ≪Domain≫ を持つクラスとしてモデル化されます。次の例では、ドメインは「zip + 4」の郵便番号に対して定義されています。

ドメインの例

ストアド プロシージャ コンテナ ページの先頭へ

ストアド プロシージャ コンテナは、データ モデル内のストアド プロシージャをグループ化したものです。ストアド プロシージャ コンテナは、≪SP Container≫ でステレオタイプ化された UML クラスとして作成されます。1 つのデータベース設計に、複数のストアド プロシージャ コンテナを作成できます。各ストアド プロシージャ コンテナには、少なくとも 1 つのストアド プロシージャが必要です。

ストアド プロシージャ

ストアド プロシージャは、一般的にデータベース サーバーに存在する独立したプロシージャです。ストアド プロシージャは、≪SP Container≫ としてステレオタイプ化されたクラスにグループ化された操作として記述されます。操作は、≪SP≫ にステレオタイプ化されます。次の例は、「AuctionManagement」というコンテナ クラスの、1 つのストアド プロシージャ操作 (SP_Auction) を示しています。ストアド プロシージャを設計する場合、データベース設計者は特定の RDBMS で使用される命名規則を理解している必要があります。

ストアド プロシージャ コンテナとストアド プロシージャの例

テーブルスペース ページの先頭へ

テーブルスペースは、テーブル、ストアド プロシージャ、索引などに割り当てられる記憶領域の大きさを表現します。テーブルスペースは、依存関係を通じて特定のデータベースにリンクされます。テーブルスペースの数や、各テーブルがテーブルスペースにどのようにマッピングされるかは、データ モデルの複雑さに応じて決まります。頻繁にアクセスされるテーブルは、複数のテーブルスペースへの分割が必要になる場合があります。頻繁にアクセスされる大量のデータを含まないテーブルは、1 つのテーブルスペースにグループ化されます。

テーブルスペース コンテナは、各テーブルスペースに対して定義されます。テーブルスペース コンテナは、テーブルスペースの物理的な記憶デバイスです。1 つのテーブルスペースには複数のテーブルスペース コンテナが存在できますが、1 つのテーブルスペースに 1 つのテーブルスペース コンテナを割り当てることを推奨します。テーブルスペース コンテナは、テーブルスペースの属性として定義され、明示的にはモデル化されません。

テーブルスペースの例

スキーマ ページの先頭へ

スキーマは、データベースの構成または構造を記述します。スキーマは、≪Schema≫ にステレオタイプ化されたパッケージとして表現されます。スキーマがパッケージとして定義される場合、パッケージを構成するテーブルはスキーマ内に含まれます。データベースとスキーマの依存関係が、データベースとスキーマ間の関係を記述するために作成されます。

スキーマの例

データベース ページの先頭へ

データベースはデータのコレクションで、これらのデータはアクセスや管理が可能なように整理されています。データベースの情報に対する管理とアクセスは、商用のデータベース管理システム (DBMS) を利用して実行されます。データ モデルでは、データベースは ≪Database≫ にステレオタイプ化されたコンポーネントして表現されます。

データベースの例

関係 ページの先頭へ

データベース モデリングの UML プロファイルでは、データ モデルの主要な要素間で有効な関係が定義されています。次に、関係タイプの例を示します。

非依存

非依存リレーションシップは、データベース内に独立して存在している 2 つのテーブル間の関係です。非依存リレーションシップは、テーブル間の関連を使用して記述されます。関連は、≪Non-Identifying≫ でステレオタイプ化されます。次の例は、「Item」テーブルと「AuctionCategory」テーブル間の非依存リレーションシップを表しています。

非依存リレーションシップ

依存

依存リレーションシップは、子テーブルが親テーブルと共存する必要のある 2 つのテーブル間の関係です。依存リレーションシップは、2 つのテーブル間のコンポジット集約を使用して記述されます。コンポジット集約は、≪Identifying≫ としてステレオタイプ化されます。次の図は、依存リレーションシップの例を示しています。この例では、子テーブル (CreditCard) のインスタンスは、親テーブル (UserAccount) において関連付けられた入力が必要であることを示しています。

依存リレーションシップの例

 

関連とコンポジット集約のどちらの場合も、多重度を定義して、関係にある行の数を記述します。この例では、「UserAccount」テーブルの各行に対して、「CreditCard」テーブルの「CreditCard」行は 0 以上に指定できます。「UserAccount」テーブルの行は、「CreditCard」テーブルの各行に対して 1 つだけです。多重度は、基数とも呼ばれます。

データベース ビュー

データベース ビューとテーブルとの関係を定義するときに、依存関係が使用され、ビューからテーブルに導き出されます。依存関係のステレオタイプは ≪Derive≫ です。一般的に、ビューの依存関係には名前が付けられます。依存関係の名前は、データベース ビューとの依存関係で定義されるテーブルと同じ名前になります。

 

ビューとテーブルの依存関係の例

テーブルスペース

テーブルスペースと特定のデータベースをリンクするには、依存関係が使用されます。次の図では、データベースにテーブルスペースの依存関係があることが示されています。複数のテーブルスペースを、モデルの単一のデータベースに関連付けることができます。

テーブルスペースとデータベース依存関係の例

テーブルスペースと、テーブルスペース内のテーブルとの関係を記述するには、依存関係が使用されます。1 つまたは複数のテーブルを、1 つのテーブルスペースに関連付けたり、1 つのテーブルを複数のテーブルスペースに関連付けることができます。次の例では、テーブル「Auction」が「PRIMARY」という名前の単一のテーブルスペースに割り当てられています。

テーブルとテーブルスペースの依存関係の例

実現

実現は、データベースと、データベース内に存在するテーブルとの関係を確立するために使用されます。1 つのテーブルを、データ モデルの複数のデータベースを使用して実現できます。

テーブルとデータベースの実現関係の例

ストアド プロシージャ

ストアド プロシージャ コンテナと、ストアド プロシージャ コンテナ内のストアド プロシージャが動作するテーブルとの関係を記述するには、依存関係を使用します。次の例では、ストアド プロシージャ「SP_Auction」を使用して「Auction」テーブルの情報にアクセスすることで、この関係を示しています。

ストアド プロシージャ コンテナとテーブルの依存関係の例

データ モデルの発展 ページの先頭へ

方向づけフェーズ ページの先頭へ

方向づけフェーズでは、最初のデータ モデリング作業は、「アーキテクチャ統合の実施ワークフローの詳細」作業の一部として、概念の検証のプロトタイプ開発と共に実行します。データベースが既に存在しているプロジェクトでは、データベース設計者は既存のデータベースをリバース エンジニアリングして、既存のデータベース構造に基づく最初の物理データ モデルを開発できます。詳しくは「ガイドライン: リレーショナル データベースからのリバース エンジニアリング」を参照してください。物理データ モデルの要素は、必要に応じて設計モデルの要素に変換され、概念の検証のプロトタイプ化作業をサポートします。

推敲フェーズ ページの先頭へ

推敲フェーズの目標は、技術面でのリスクを排除し、システムの安定した (ベースライン化された) アーキテクチャを作成することです。大規模なシステムでは、適切に設計されていないデータ モデルが原因で起こる低性能が、アーキテクチャ上の主な問題になります。結果的に、アーキテクチャを安定させるには、データ モデリングと、データベースの性能を評価可能にするアーキテクチャ プロトタイプの開発の両方が必要となります。アーキテクチャ上重要なユース ケースは、各反復において詳細化および分析されます。データ モデル要素は、これらのユース ケースの永続クラスの設計に基づいて定義されます。クラス設計が安定すると、データベース設計者はクラス設計を定期的にデータ モデルのテーブルに変換し、適切なデータ記憶領域モデル要素を定義します。

推敲フェーズの終わりまでに、主要なデータベース構造 (テーブル、索引、主キーと外部キー列) を適切に作成して、アプリケーションのアーキテクチャ上重要となる定義済みシナリオの実行をサポートする必要があります。さらに、典型的なデータ量をデータベースにロードして、アーキテクチャ上の性能テストをサポートするようにします。性能テストの結果に基づき、最適化の手法 (非正規化、物理的な記憶領域属性や分散の最適化、索引付けなど) を用いてデータ モデルを調整する必要があります。

作成フェーズ ページの先頭へ

データ モデルの大規模な再構成が、作成フェーズで発生しないようにする必要があります。追加のテーブルやデータ記憶領域要素は、ユース ケース セットの詳細な設計と、反復に割り当てられた承認済みの変更依頼に基づいて、作成フェーズの反復において定義されます。作成フェーズにおけるデータベース設計の主な目的は、データベースの性能を継続的に監視し、非正規化、索引の定義、データベース ビューの作成などの最適化手法を使用して、必要に応じてデータベース設計を最適化することです。

物理データ モデルは、データベース設計者が作成フェーズで管理する設計成果物です。物理データ モデルは、モデルで直接更新するか、データベースで直接行われた更新を読み取るツールを使用して維持します。

移行フェーズ ページの先頭へ

データ モデルは、設計モデルと同様に、移行フェーズで承認済みの変更依頼に応じて維持されます。データベース設計者は、アプリケーションが最終的な受け入れテストに進み、稼働へ導入されるように、データ モデルとデータベースの同期を維持する必要があります。

ラウンド トリップ エンジニアリングに関する注意 ページの先頭へ

開発チームが、クラスをテーブルに (またはその逆に) 変換する機能や、データベースをリバース エンジニアリングまたはフォワード エンジニアリングする機能を備えた最近のビジュアル モデリング ツールを使用している場合、チームでは変換とエンジニアリング プロセスを管理するためのガイドラインを確立する必要があります。ガイドラインは、データベース設計やアプリケーション設計で、チームが並行に作業しているような大規模なプロジェクトで主に必要になります。開発チームは、クラスとテーブル間の変換や、データベースのフォワード エンジニアリングを実行するのに適した、アプリケーション開発のポイント (ビルド / リリース サイクル) を定義する必要があります。最初のデータベースが作成されると、開発チームは、システムの設計とコードがプロジェクトを通して発展するのに対応するため、データ モデルとデータベースの同期を管理するためのチームのガイドラインを定義する必要があります。




この内容は、Applied Information Sciences により作成、または部分的に作成されました。

Rational Unified Process   2003.06.15