この新しいグラフ・コンポーネントのために、適切なデータと密接に結合されたコンポーネントを作成する必要があります。 ビュー・オブジェクトを作成してデータ・コントロールとして追加するには、以下の手順に従います。
-
メイン・メニューから、「File」→「New」の順に選択してNew Galleryを開きます。
-
New Galleryダイアログで、「General」→「Projects」→「Database Project」の順に選択します。
「OK」をクリックします。
-
New Projectウィンドウで、名前にReverseLogicalModelを入力します。
「OK」をクリックします。
-
新しいプロジェクトがアプリケーション・ナビゲータに表示されます。 「ReverseLogicalModel」プロジェクトをダブルクリックしてプロジェクトのプロパティを開きます。
-
Project Propertiesダイアログで「Dependencies」ノードを選択し、Editボタン「
」をクリックして、新規の依存性を作成します。
-
Edit Dependenciesダイアログで、「PhysicalModel」プロジェクトを展開して「Build Output」チェック・ボックスをチェックします。
「OK」をクリックします。 再度「OK」をクリックします。
-
Save Allボタン「
」をクリックして作業内容を保存します。 -
アプリケーション・ナビゲータで「ReverseLogicalModel」ノードを右クリックし、コンテキスト・メニューから「New」を選択します。
-
New Galleryのカテゴリで「General」→「Diagrams」を選択し、Database Diagramを選択します。
「OK」をクリックします。
-
Create Database Diagramダイアログで、NameにDatabase Diagramを入力します。
「OK」をクリックします。
-
編集ペインに新しい空のダイアグラムが開きます。
-
アプリケーション・ナビゲータで、ノードを「PhysicalModel」→「Database1」→「SCOTT」の順に展開し、「department_locations」、「Departments」、「Emp」、および「Locations」を同時に選択して、ダイアグラム上に定義をドラッグします。
-
データベース・ダイアグラムのデフォルト・レイアウトを再編成します。 ダイアグラムの中を右クリックして、「Layout Shapes」→「Row」を選択します。

-
次の図のようになるように、モデルの位置を調整します。
-
Save All「
」をクリックして作業内容を保存します。
-
データベース・ダイアグラムに戻り、右クリックして「Select All」をクリックします。
-
任意の表内を右クリックして、「Transform」→「Model Only」を選択します。
-
Transformダイアログで「OK」をクリックします。
-
Save All「
」をクリックして作業内容を保存します。 -
アプリケーション・ナビゲータで、「scott」ノードを展開します。 アプリケーション・ナビゲータは次のように表示されます。
-
アプリケーション・ナビゲータで「ReverseLogicalModel」ノードを右クリックし、「New」を選択します。
-
New Galleryダイアログでカテゴリとして「Diagrams」を選択し、「Class Diagram」を選択します。
「OK」をクリックします。
-
Create Class Diagramダイアログで、NameにReverse Class Diagramを入力します。
「OK」をクリックします。
-
アプリケーション・ナビゲータで、scottというパッケージ名の下にある、package.uml_pck以外のすべてのコンポーネントを選択します。 選択したコンポーネントを新しいダイアグラムにドラッグします。
-
ダイアグラムを右クリックし、「Lay Out Shapes」→「Row」の順に選択してダイアグラムのレイアウトを再編成します。
-
次の図のようになるように、レイアウトを調整します。
-
「Reverse Class Diagram」タブを選択してダイアグラム上にドラッグし、エディタを2つのビューに分割します。

-
エディタ・ペインが水平方向に分割されました。 「LogicalDatabase.class_diagram」タブをクリックし、分割されたビューにダイアグラムを開き、両方のスキーマを観察します。

-
両方のダイアグラムが見えるように、必要に応じてレイアウトを調整します。
元のクラス図の設計とリバース変換した設計との間には相違点があることが分かります。
リバース変換したクラス図はデータベース・ダイアグラムのクラス表現にすぎません。 そのため、元のクラス図にあったセマンティクスの一部が失われています。
リバース変換できない概念の例は次のとおりです。
- DepartmentLocations表から多対多の関係がリバース変換できない
- empType属性からサブクラスがリバース変換できない
- 主キー属性がクラス属性としてリバース・バックされる
- 外部キー属性がクラス属性としてリバース・バックされる
- 関連の意味が失われる(emps in dept)
これらは、リバース・エンジニアリング操作によってクラス図から再作成することができないセマンティクス情報の一部です。 このクラス図を再利用して再度変換を実行すると整合性が失われるので、実行しないでください。
これで、このチュートリアルは完了です。
- 論理UMLクラス・モデルの作成
- 論理モデルから物理データベース・モデルへの変換
- データベース・ダイアグラムの作成とクラス図へのリバース・バック
- データベース表の設計と構築
- 『Oracle® Fusion Middleware User's Guide for Oracle JDeveloper』の"Getting Started With Application Modeling"
- 『Oracle® Fusion Middleware User's Guide for Oracle JDeveloper』の"Getting Started with Working with Databases"
パート1: 論理UMLクラス・モデルの作成
