ガイドライン:
|
設計モデル要素 |
対応するデータ モデル要素 |
クラス | テーブル |
属性 | 列 |
関連 |
非依存リレーションシップ |
関連クラス |
共通テーブル |
コンポジット集約 |
依存リレーションシップ |
多対多関連 |
共通テーブル |
多重度 |
基数 |
限定子付き関連 |
共通テーブル |
汎化 (継承) | 独立したテーブル |
設計モデルの永続的クラスは、システムに格納する必要のある情報を表しています。概念的に言って、これらのクラスはリレーショナル設計と類似しています (設計モデル内のクラスが、リレーショナル スキーマにおけるエンティティと同様に反映されている場合など)。ただし、プロジェクトが推敲フェーズから作成フェーズに移行するにつれて、設計モデルとリレーショナル データ モデルの目標も分岐していきます。これは、リレーショナル データベースを作成する目的はデータを正規化することにある一方で、設計モデルの目的は非常に複雑な振る舞いをカプセル化することにあるためです。これらの 2 つの観点 (データと振る舞い) の分岐により、2 つのモデル内の関連する要素をマッピングすることが必要になります。
第 3 正規形で記述されたリレーショナル データベースでは、テーブルの各行 (各組) がオブジェクトとみなされます。テーブルの列は、クラスの永続属性に相当します (永続的クラスには、一時的な属性が存在する場合があることに注意してください)。つまり、ほかのクラスへの関連がまったくないシンプルなケースでは、2 つのモデル間のマッピングも簡単になります。属性のデータタイプが、列で許容されるデータタイプの 1 つと対応します。
例:
「顧客」クラス
RDBMS でモデル化すると、「顧客」という名前のテーブルに変換され、「名前」、「住所」、「顧客 ID」という列が作成されます。
このテーブルは次のようになります。
各永続属性に対して、リレーショナル データ モデルで永続オブジェクトを適切にモデル化するための追加情報を導き出すために、いくつかの問題を解決する必要があります。次に例を示します。
2 つの永続オブジェクト間の関連は、関連付けられたオブジェクトへの外部キーとして実現されます。外部キーは、関連するオブジェクトの主キーの値を含むテーブル内の列です。
例:
「注文」と「顧客」の間に次のような関係があると仮定します。
これをリレーショナル テーブルにマッピングすると、「注文」テーブルと「顧客」テーブルになります。「注文」テーブルには、リストに示されている属性の列に加えて「顧客 ID」列が含まれ、「顧客」テーブル内の関連付けられた行の主キーに対する外部キー参照が含まれます。各「注文」に対して、「顧客 ID」列には、その「注文」に関連付けられている「顧客」の ID が含まれます。外部キーを使用すると、RDBMS で関連する情報を結合することができます。
集約も、外部キーの関係を使ってモデル化されます。
例:
「注文」と「明細」の間に次のような関係があると仮定します。
これをリレーショナル テーブルにマップすると、「注文」テーブルと「明細」テーブルになります。「明細」テーブルにはリストに示されている属性の列に加え、「注文」テーブル内の関連付けられた列への外部キー参照を含む、「注文 ID」列があります。各「明細」に対し、「注文 ID」の列には「明細」が関連付けられている「注文」の「注文 ID」が含まれます。外部キーを使用すると、RDBMS で結合操作を最適化できます。
また、データ モデルで参照の整合性を維持するために、カスケード削除の条件を実装することが重要です。この場合、「注文」を削除すると、関連するすべての「明細」が削除されます。
標準のリレーショナル データ モデルでは、継承の直接的なモデル化はサポートされていません。継承をモデル化するさまざまな方策があります。これらは、次のようにまとめることができます。
リレーショナル モデルにおける標準的なテクニックでは、多対多の関連を表すために共通エンティティを使用します。ここでも同じ手法を採用します。関連を表すために共通テーブルを使用します。
例:
サプライヤが多数の製品を供給し、1 つの製品が多くのサプライヤから供給される場合、「サプライヤ / 製品」テーブルを作成します。このテーブルには、「サプライヤ」テーブルと「製品」テーブルの主キーのみが含まれ、サプライヤと関連する製品のリンクとして機能します。オブジェクト モデルには、このテーブルに類するものはありません。リレーショナル データ モデルにおける関連を表すためにだけ使用されます。
設計クラスをデータ モデルのテーブルと適切なリレーションシップに変換した後で、必要に応じてモデルを改良します。これにより、参照の整合性が実装され、ビューやストアド プロシージャによるデータ アクセスが最適化されます。詳細は、「ガイドライン: データ モデル」を参照してください。
ほとんどのアプリケーション設計ツールは、データ モデルからの DDL (Data Definition Language) スクリプトの生成や、データ モデルからのデータベースの生成をサポートします。データベースのフォワード エンジニアリングは、アプリケーションの開発、統合作業の一部として計画する必要があります。データ モデルからデータベースをフォワード エンジニアリングするタイミングと頻度は、各プロジェクトの状況に応じて異なります。新しいデータベースを作成する新しいアプリケーション開発プロジェクトでは、最初のフォワード エンジニアリングは、推敲フェーズの終わりまでに、アプリケーションのアーキテクチャが安定したバージョンを実装する作業の一部として実行する必要があります。その他の場合、最初のフォワード エンジニアリングは作成フェーズの初期の繰り返しで行われます。
フォワード エンジニアリング可能なデータ モデルのデータ要素のタイプは、プロジェクトで使用する設計ツールや RDBMS に応じて変化します。一般的には、データ モデルの主要な構造的要素 (テーブル、ビュー、ストアド プロシージャ、トリガ、索引など) はデータベースにフォワード エンジニアリングできます。
![]() |
この内容は、Applied Information Sciences により作成、または部分的に作成されました。 |
Rational Unified Process
|