トピック

概論ページの先頭へ

このガイドラインでは、設計モデルの永続的設計クラスデータ モデルのテーブルにマッピングする方法を説明します。

設計モデル要素のデータ モデル要素への変換ページの先頭

設計モデルの永続的クラスは、データ モデル内のテーブルに変換できます。次の表では、設計モデル要素とデータ モデル要素のマッピングを示します。

設計モデル要素

対応するデータ モデル要素

クラス テーブル
属性

関連

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

関連クラス

共通テーブル

コンポジット集約

依存リレーションシップ

多対多関連

共通テーブル

多重度

基数

限定子付き関連

共通テーブル

汎化 (継承) 独立したテーブル

永続的クラスのテーブルへのマッピングページの先頭へ

設計モデルの永続的クラスは、システムに格納する必要のある情報を表しています。概念的に言って、これらのクラスはリレーショナル設計と類似しています (設計モデル内のクラスが、リレーショナル スキーマにおけるエンティティと同様に反映されている場合など)。ただし、プロジェクトが推敲フェーズから作成フェーズに移行するにつれて、設計モデルとリレーショナル データ モデルの目標も分岐していきます。これは、リレーショナル データベースを作成する目的はデータを正規化することにある一方で、設計モデルの目的は非常に複雑な振る舞いをカプセル化することにあるためです。これらの 2 つの観点 (データと振る舞い) の分岐により、2 つのモデル内の関連する要素をマッピングすることが必要になります。

第 3 正規形で記述されたリレーショナル データベースでは、テーブルの各行 (各組) がオブジェクトとみなされます。テーブルの列は、クラスの永続属性に相当します (永続的クラスには、一時的な属性が存在する場合があることに注意してください)。つまり、ほかのクラスへの関連がまったくないシンプルなケースでは、2 つのモデル間のマッピングも簡単になります。属性のデータタイプが、列で許容されるデータタイプの 1 つと対応します。

例:

「顧客」クラス

「顧客」クラス

RDBMS でモデル化すると、「顧客」という名前のテーブルに変換され、「名前」、「住所」、「顧客 ID」という列が作成されます。

このテーブルは次のようになります。

永続属性とキー ページの先頭へ

各永続属性に対して、リレーショナル データ モデルで永続オブジェクトを適切にモデル化するための追加情報を導き出すために、いくつかの問題を解決する必要があります。次に例を示します。

  • この永続属性が、キーまたはキーの一部として機能できるか。たとえば、「属性 X と属性 Z によってオブジェクトが一意に識別されるか」など。「顧客」テーブルで、「顧客 ID」は主キーを表します。
  • 属性の最小値と最大値はいくらか。
  • この属性をキーとして使用して検索が可能か。たとえば、「Y > 1000 のインスタンスすべてを検索する」のように、属性 Y を Select 文のフィルタの一部にすることもできます。
  • 属性に、「属性 X は、送信された 100,000 文字あたりの再送信数を表す」などの説明があるか。
  • 属性に有効な数値が設定されているか。また、異なる数値間で必要な変換があるか。
  • 属性を誰が更新できるか。たとえば、「T は、権限を持つクラス nn のユーザーしか変更できない」など。
  • 誰が属性を読み取ることができるか。たとえば、「P は権限を持つクラス yy と zz のユーザーしか読み取ることができない」、「P はビュー Vi や Vj に含まれる」など。
  • 量と頻度に関する適切な情報があるか。たとえば、「A が最大で 50,000 回発生する」、「平均して 1 日あたり 2000 の A が変更される」など。
  • 属性は固有であるか。たとえば、運転免許証の番号は個人によって異なります。

永続オブジェクトとデータ モデル間の関連のマッピング ページの先頭へ

2 つの永続オブジェクト間の関連は、関連付けられたオブジェクトへの外部キーとして実現されます。外部キーは、関連するオブジェクトの主キーの値を含むテーブル内の列です。

例:

「注文」と「顧客」の間に次のような関係があると仮定します。

これをリレーショナル テーブルにマッピングすると、「注文」テーブルと「顧客」テーブルになります。「注文」テーブルには、リストに示されている属性の列に加えて「顧客 ID」列が含まれ、「顧客」テーブル内の関連付けられた行の主キーに対する外部キー参照が含まれます。各「注文」に対して、「顧客 ID」列には、その「注文」に関連付けられている「顧客」の ID が含まれます。外部キーを使用すると、RDBMS で関連する情報を結合することができます。

データ モデルへの集約関連のマッピング ページの先頭へ

集約も、外部キーの関係を使ってモデル化されます。

例:

「注文」と「明細」の間に次のような関係があると仮定します。

「注文」クラスと「明細」クラス

これをリレーショナル テーブルにマップすると、「注文」テーブルと「明細」テーブルになります。「明細」テーブルにはリストに示されている属性の列に加え、「注文」テーブル内の関連付けられた列への外部キー参照を含む、「注文 ID」列があります。各「明細」に対し、「注文 ID」の列には「明細」が関連付けられている「注文」の「注文 ID」が含まれます。外部キーを使用すると、RDBMS で結合操作を最適化できます。

また、データ モデルで参照の整合性を維持するために、カスケード削除の条件を実装することが重要です。この場合、「注文」を削除すると、関連するすべての「明細」が削除されます。

データ モデルにおける汎化関係のモデル化 ページの先頭へ

標準のリレーショナル データ モデルでは、継承の直接的なモデル化はサポートされていません。継承をモデル化するさまざまな方策があります。これらは、次のようにまとめることができます。

  • スーパークラスとサブクラスを、独立したテーブルを使用して表します。サブクラス テーブルには、スーパークラス テーブルへの外部キー参照が含まれている必要があります。サブクラス オブジェクトをインスタンス化するには、2 つのテーブルを結合しなければなりません。このアプローチは概念的に簡単で、モデルへの変更も容易ですが、多くの場合、余分な作業のために性能は低くなります。
  • すべての継承した属性と関連を、サブクラス テーブルの独立した列にコピーします。これは、標準リレーショナル データ モデルにおける非正規化と同様です。

データ モデルにおける多対多関連のモデル化 ページの先頭へ

リレーショナル モデルにおける標準的なテクニックでは、多対多の関連を表すために共通エンティティを使用します。ここでも同じ手法を採用します。関連を表すために共通テーブルを使用します。

例:

サプライヤが多数の製品を供給し、1 つの製品が多くのサプライヤから供給される場合、「サプライヤ / 製品」テーブルを作成します。このテーブルには、「サプライヤ」テーブルと「製品」テーブルの主キーのみが含まれ、サプライヤと関連する製品のリンクとして機能します。オブジェクト モデルには、このテーブルに類するものはありません。リレーショナル データ モデルにおける関連を表すためにだけ使用されます。

データ モデルの洗練ページの先頭へ

設計クラスをデータ モデルのテーブルと適切なリレーションシップに変換した後で、必要に応じてモデルを改良します。これにより、参照の整合性が実装され、ビューやストアド プロシージャによるデータ アクセスが最適化されます。詳細は、「ガイドライン: データ モデル」を参照してください。

データ モデルのフォワード エンジニアリングページの先頭へ

ほとんどのアプリケーション設計ツールは、データ モデルからの DDL (Data Definition Language) スクリプトの生成や、データ モデルからのデータベースの生成をサポートします。データベースのフォワード エンジニアリングは、アプリケーションの開発、統合作業の一部として計画する必要があります。データ モデルからデータベースをフォワード エンジニアリングするタイミングと頻度は、各プロジェクトの状況に応じて異なります。新しいデータベースを作成する新しいアプリケーション開発プロジェクトでは、最初のフォワード エンジニアリングは、推敲フェーズの終わりまでに、アプリケーションのアーキテクチャが安定したバージョンを実装する作業の一部として実行する必要があります。その他の場合、最初のフォワード エンジニアリングは作成フェーズの初期の繰り返しで行われます。

フォワード エンジニアリング可能なデータ モデルのデータ要素のタイプは、プロジェクトで使用する設計ツールや RDBMS に応じて変化します。一般的には、データ モデルの主要な構造的要素 (テーブル、ビュー、ストアド プロシージャ、トリガ、索引など) はデータベースにフォワード エンジニアリングできます。




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

Rational Unified Process   2003.06.15