| Oracle SQL Developer Data Modelerユーザーズ・ガイド リリース2.0 B56060-01 |
|
 戻る |
 次へ |
SQL Developer Data Modelerはメタデータの取得、モデリング、管理および利用のための環境を提供する、データ・モデリングおよびデータベース設計のツールです。 SQL Developer Data ModelerはZachman frameworkおよびObject Management Group（OMG）のMetaObject Facility（MOF）およびCommon Warehouse Metamodel（CMW）の規格に基づいています
SQL Developer Data ModelerはSQL Developerの有料オプションであり、個別のライセンスが必要です。 ただし、無償版のビューア（読取り専用）も使用できます（1.8を参照）。
この章の内容は次のとおりです。
1.1「SQL Developer Data Modelerのインストールおよび起動」
1.2「Data Modelerのユーザー・インタフェース」
1.3「SQL Developer Data Modelerの使用」
1.5「Data Modelerオプション(ユーザー・プリファレンス)」
1.6「設計の保存、オープン、エクスポートおよびインポート」
SQL Developer Data Modelerをインストールして起動するプロセスは、SQL Developerの場合と似ています。.zipファイルをダウンロードして任意の親ディレクトリまたは親フォルダに解凍し、コマンドを入力するか、またはファイル名をダブルクリックします。 次の手順を実行する前に、リリース・ノートまたはreadmeファイルを参照してください。
Data Modelerキットを任意のディレクトリ（フォルダ）に解凍します。 このディレクトリの場所を、<datamodeling_install>と表します。 たとえば、Windowsシステムの場合は、この場所としてC:\Program Filesを選択できます。
Data Modelerキットを解凍すると、<datamodeling_install>ディレクトリの下にdatamodelingというディレクトリが作成されます。 また、多くのファイルおよびフォルダが、このディレクトリに配置されます。
Data Modelerを起動するには、<datamodeling_install>ディレクトリの下のdatamodelingディレクトリに移動し、次のいずれかを実行します。
LinuxおよびMac OS Xシステムの場合は、sh datamodeling.shを実行します。
Windowsシステムの場合は、datamodeling.exeをダブルクリックします。
java.exeのフルパス名の入力を求められたら、「参照」をクリックしてjava.exeを検索します。たとえば、Windowsシステムでは、C:\Program Files\Java\jdk1.6.0_06\bin\java.exeのようなパス名になる場合があります。
このインタフェースを使用する前にデータ・モデリングの概要を理解しておきたい場合は、次の手順に進む前に、この章の残りの部分をお読みください。
第2章「チュートリアル: 小規模データベースのデータ・モデリング」の簡単なチュートリアルを実行します。 （高度なチュートリアルなど、他の資料については1.9「データ・モデリングの追加のリソース」を参照してください。）
SQL Developer Data Modelerウィンドウでは、基本的に、左側はオブジェクトを検索して選択するためのナビゲーション、右側は選択したオブジェクトに関する情報の表示に使用されます。
図1-1に、メイン・ウィンドウを示します。
次の図に示すとおり、上部のメニューには、標準的なエントリと、SQL Developer Data Modeler固有の機能のエントリが表示されます（1.2.1「Data Modelerのメニュー」を参照）。
ショートカット・キーを使用して、メニューおよびメニュー項目にアクセスできます。たとえば、[Alt]キーを押しながら[F]キーを押すと「ファイル」メニュー、[Alt]キーを押しながら[E]キーを押すと「編集」メニュー、[Alt]キーを押しながら[H]キーを押し、次に[Alt]キーを押しながら[C]キーを押すと、「ヘルプ」の「目次」にアクセスできます。 [F10]キーを押して「ファイル」メニューを表示することもできます。
メニューの下にあるアイコンでは、現在選択されウィンドウ右側に表示されているもの（論理モデル、リレーショナル・モデル、データ・フロー・ダイアグラムなど）に関連するアクションを実行します。 たとえば、リレーショナル・モデルの場合のアイコンには、「新規の表」、「新規ビュー」、「表の分割」、「表のマージ」、「新規外部キー・リレーション」および「DDLの生成」が含まれます。 アイコンの名前を参照するには、アイコンの上にポインタを置きます。 また、アイコンに対応するアクションは、「オブジェクト」メニューからも実行できます。
次の図に示すとおり、Data Modelerウィンドウの左側には、データ・モデリング・オブジェクトを階層ツリーで表示するオブジェクト・ブラウザがあります。
オブジェクト・ブラウザでオブジェクトを選択するには、適切なツリー・ノードを開いてオブジェクトをクリックします。
次の図に示すとおり、Data Modelerウィンドウの右側には、ユーザーが選択したり開いたオブジェクトのためのタブとペインがあります。ここには、ライブラリ関連データについて、意図的に簡略化したリレーショナル・モデル（第2章「チュートリアル: 小規模データベースのデータ・モデリング」で生成されたモデル）の情報が表示されます。
オブジェクトを切り替えるには、目的のタブをクリックします。タブを閉じるには、タブの「X」をクリックします。 オブジェクトを変更してから「X」をクリックすると、変更を保存するかどうかを尋ねられます。
ここでは、Data Modelerで特に重要なメニュー項目について説明します。
「ファイル」メニュー
開く: 保存またはエクスポートされているSQL Developer Data Modelerの設計を開きます。 詳細は、1.6「設計の保存、オープン、エクスポートおよびインポート」を参照してください。
閉じる: SQL Developer Data Modelerを終了せずに、現在の設計を閉じます。
インポート: 様々なソースからモデルをインポートできます。 詳細は、1.6「設計の保存、オープン、エクスポートおよびインポート」を参照してください。
エクスポート: ファイルにモデルをエクスポートできます。エクスポート後は、様々なデータ・モデリング・ツールにインポートできます。 詳細は、1.6「設計の保存、オープン、エクスポートおよびインポート」を参照してください。
印刷: 現在選択されているダイアグラムを印刷します。
ダイアグラムの出力: 現在選択されているダイアグラムを保存します。その形式は、指定したファイル拡張子に関連付けられたタイプのイメージ・ファイル（.pngまたは.jpg）、PDFファイルまたはscalable vector graphics（.svg）ファイルです。
最近の設計: 最近作業したSQL Developer Data Modeler設計を開くことができます。
「表示」メニュー
SQL Developer Data Modelerインタフェースに表示される内容を指定するオプションが含まれます。
ブラウザ: データ・モデリング・オブジェクトを階層ツリー形式で表示する、オブジェクト・ブラウザを表示します。
ナビゲータ: 現在ウィンドウの右側で選択されているビューをグラフィカルなサムネイル表現で表示します。
ログ: 「ログ」ペインにSQL Developer Data Modelerのアクションの記録を表示します。
詳細の表示: 表示について、その詳細レベルを制御します。
論理ダイアグラム表記法: 論理モデルの表示にBarkerまたはBachmanのどちらの表記法を使用するのかを制御します。
DDLファイル・エディタ: 選択した物理モデルのDDL文を生成できます。 「DDLファイル・エディタ」ダイアログ・ボックスが表示されます。 （このコマンドは、リレーショナル・モデルが選択されているときに「DDLの生成」アイコンをクリックした場合や、「オブジェクト」→「リレーショナル」→「DDLの生成」をクリックした場合と同等です。）
ズーム・イン（および対応するアイコン）: 現在選択されているダイアグラムを詳細に表示します。表示されるオブジェクトは少なくなります。
ズーム・アウト（および対応するアイコン）: 現在選択されているダイアグラムを概略的に表示します。表示されるオブジェクトは多くなります。
画面に合わせる（および対応するアイコン）: 関連するすべてのオブジェクトを現在選択されているダイアグラムのウィンドウに合わせ、必要な場合は輪郭およびテキスト・ラベルの大きさを調節します。
検索: 現在選択されているダイアグラム内のオブジェクトを検索するためのダイアログ・ボックスを表示します。 大きく複雑なダイアグラムでオブジェクトを検索するのに役立ちます。
「設計」メニュー
モデルを生成するためのオプションが含まれます。
リレーショナル・モデルのエンジニア: フォワード・エンジニアリングを実行します。論理モデルからリレーショナル・モデルを生成または更新します。 また、サブビューを作成するかどうかを指定することもできます。
論理モデルのエンジニア: リバース・エンジニアリングを実行します。選択されたリレーショナル・モデルから論理モデルを更新します。
「オブジェクト」メニュー
現在選択されているダイアグラム（論理モデル、リレーショナル・モデル、データ・フロー・ダイアグラムなど）で使用可能なアクションを実行するためのコマンドが含まれます。 アイコンが表示される場所は、メニューの下、かつ表示するダイアグラムを選択するためのタブの上です。
「物理」メニュー
論理モデルを開いたり閉じたり、また保存するためのコマンドが含まれます。
「ツール」メニュー
SQL Developer Data Modelerツールを起動し、特定のオプション（ユーザー・プリファレンス）を設定できます。
ドメイン管理: ドメインを表示、変更、追加および消去できます。 「ドメイン管理」ダイアログ・ボックスが表示されます。
型の管理: 論理型を表示、変更、追加および消去できます。 「型の管理」ダイアログ・ボックスが表示されます。
RDBMSサイト管理: RDBMSサイト（サポートされているタイプのデータベースに関連付けられた名前）を表示できます。また、物理モデルを作成するときに便利なように、ユーザー独自の名前（別名）を追加できます。 「RDBMSサイト・エディタ」ダイアログ・ボックスが表示されます。
表からビュー・ウィザード: 選択されたリレーショナル・モデルに表に基づいたビューを作成できます。 「表からビュー」ウィザードを表示します。
名前略語: （たとえば、標準的な略語やスペルを確実に使用させるために）リレーショナル・モデル・オブジェクトの名前で変更される文字列が示された.csvファイルを指定します。 「名前略語」ダイアログ・ボックスが表示されます。
用語集エディタ: 新しい用語集ファイルの作成（存在しないファイル名を指定した場合）および既存の用語集ファイルの編集が可能です。 ファイルを選択するためのダイアログ・ボックスが表示された後に、「用語集エディタ」ダイアログ・ボックスが表示されます。
設計ルール: 現在の設計がData Modelerの設計ルールに違反していないかを確認できます。 「設計ルール」ダイアログ・ボックスが表示されます。
エンジニアリング・ステータス: 「エンジニアリング」ダイアログ・ボックスが表示されます。
モデルの比較/マージ: 設計ファイルを開き、そのファイルのリレーショナル・モデルと現在の設計のリレーショナル・モデルを比較し、一方のモデルのオブジェクトを他方のモデルにマージすることができます。 設計ファイルを選択すると、「リレーショナル・モデル」ダイアログ・ボックスが表示されます。
一般オプション: SQL Developer Data Modelerの動作をカスタマイズできます。 「Data Modelerオプション(ユーザー・プリファレンス)」ダイアログ・ボックスが表示されます。
「ヘルプ」メニュー
SQL Developer Data Modelerについてのヘルプが表示されます。
コンテンツ:「ヘルプ」ウィンドウを表示します。
バージョン情報: SQL Developer Data Modelerのバージョン関連情報を表示します。
オブジェクト・ブラウザおよびダイアグラムのコンテキスト・メニュー（右クリック・メニュー）には、選択されたオブジェクトに関連するコマンドが含まれます。
オブジェクト・ブラウザで論理モデルまたはリレーショナル・モデルを右クリックした場合、コンテキスト・メニューには一般的に次の項目が含まれます。
分類タイプの設定: 多次元モデル内のエンティティまたは表に分類タイプ（「ファクト」、「ディメンション」、「ロギング」、「サマリー」または「一時」）を設定できます。 （「ダイアグラム: 分類タイプ」ユーザー・プリファレンスでは、ダイアグラム内で使用される各分類タイプの色を指定することもできます。）
キーと制約へのネーミング標準の適用（リレーショナル・モデル）: 選択したリレーショナル・モデル内のキーおよび制約に、「ネーミング標準」プリファレンスの「リレーショナル - その他」で指定したネーミング標準ルールを適用します。
オブジェクト名の接頭辞の変更: 選択されたオブジェクト・タイプについて、現在指定されている接頭辞と置き換える新しい接頭辞を指定します。 「オブジェクト名の接頭辞の変更」ダイアログ・ボックスが表示されます。
ダイアグラム内で、表示されているオブジェクトの外で右クリックした場合、コンテキスト・メニューには一般的に次の項目が含まれます。
自動レイアウト（リレーショナルおよびデータ・フロー・ダイアグラム）: ダイアグラム内のオブジェクトを、より意味があり体裁が良いと考えられるレイアウトに再配置します。 再配置に不満がある場合は、「編集」→「自動レイアウトを元に戻す」をクリックすると、以前のレイアウトに戻すことができます。
自動ルート: 「自動ルートを引く」（「Data Modelerオプション(ユーザー・プリファレンス)」の「ダイアグラム」を参照）の設定を切り替えます。 端または角（頂点）をクリック・アンド・ドラッグして移動させたり、[Ctrl]キーを押しながら端をクリック・アンド・ドラッグして新しい角を作成するなど、ダイアグラムで線を調節する前に「自動ルート」を無効にする必要があります。
注意: 調節後に「自動ルート」を有効にすると、手動での調節は失われます。
詳細の表示: オブジェクトについての使用可能なすべての詳細か、または選択した詳細のみを表示できます。
モデルのプロパティ: モデルのプロパティを表示および編集するダイアログ・ボックスを表示します。
ダイアグラム内で、2つのオブジェクトを接続する線を右クリックした場合、コンテキスト・メニューには一般的に次の項目が含まれます。
削除: 線を削除し、その線で表されたリレーションシップを削除します。
直線にする（「自動ルート」が無効の場合にのみ使用可能）: すべての角を削除し、線には始点と終点のみが含まれるようにします。
フォーマット: 線の色と太さを変更できます。
プロパティ: 線で表されたリレーションシップのプロパティを表示および編集するダイアログ・ボックスを表示します。
論理ダイアグラムおよびリレーショナル・ダイアグラム内で1つ以上のエンティティまたは表を選択し、その中の1つを右クリックした場合、コンテキスト・メニューには少なくとも次の項目が含まれます。
選択した項目からサブビューを作成: 選択したオブジェクトを含むサブビューを作成します。 （1.3.4.1「論理ダイアグラムおよびサブビュー」と1.3.5.1「リレーショナル・ダイアグラムおよびサブビュー」も参照してください）
同胞の選択: 選択したオブジェクトに関連するオブジェクトを選択します。 選択の方向（「すべて」（上位および下位レベルのゾーン）、「親」または「子」）を指定できます。 選択項目からサブビューを作成する前に、同胞を選択することができます。
DDLプレビュー（リレーショナル・ダイアグラム）: オブジェクトを作成するために生成されるDDL文を表示します。
フォーマット: 選択したオブジェクトの色およびフォントを指定できます。
最背面へ移動: 選択したオブジェクトを、表示しているダイアグラムの背面に移動します。この結果、オブジェクトは部分的または完全に他のオブジェクトによって覆われてしまう場合があります。
プロパティ: オブジェクトのプロパティを表示および編集するダイアログ・ボックスを表示します。
データ・フロー・ダイアグラム内で1つ以上のオブジェクトを選択し、その中の1つを右クリックした場合、コンテキスト・メニューには少なくとも次の項目が含まれます。
削除: 選択したオブジェクトを削除します。
フォーマット: 選択したオブジェクトの色およびフォントを指定できます。
最背面へ移動（線で表されていないオブジェクトが対象）: 選択したオブジェクトを、表示しているダイアグラムの背面に移動します。この結果、オブジェクトは部分的または完全に他のオブジェクトによって覆われてしまう場合があります。
プロパティ: オブジェクトのプロパティを表示および編集するダイアログ・ボックスを表示します。
SQL Developer Data Modelerを使用して、様々な種類のモデルの様々な階層レベルのオブジェクトを作成、編集および削除することができます。 多くのオブジェクトのプロパティは類似しており、操作の実行方法は基本的に共通していて直感的です。 オブジェクトに対して操作（作成、編集、削除）を実行する場合は、オブジェクト・ブラウザまたはツールバーのコンテキスト・メニューか、またはダイアグラムを選択した後の「オブジェクト」メニューを使用できることがあります。
オブジェクト・ブラウザを使用してオブジェクトに対する操作の実行するには、階層内で適切なノードを右クリックし（またはノードをクリックして、[Shift]キーを押しながら[F10]キーを押し）、希望する操作のコマンドを選択します。
たとえば、エンティティを編集するには、「論理」表示を展開します。これによって、すべてのエンティティが表示されます。編集するエンティティの名前を右クリックして「プロパティ」を選択します。
ダイアグラムを使用して操作を実行するには、ダイアグラムのタブを選択し、ツールバー・アイコンまたは「オブジェクト」メニュー・コマンドを選択します。
たとえば、エンティティを作成するには、「論理」タブを選択し、「新規エンティティ」ツールバー・アイコンをクリックするか、「オブジェクト」→「論理」→「新規エンティティ」をクリックして、「エンティティのプロパティ」ボックスにエンティティを定義します。 エンティティを編集するには、ダイアグラム内でそのボックスをダブルクリックするか、またはボックスを右クリックして「プロパティ」を選択します。
ダイアグラム内のコンテキスト・メニュー（右クリック・メニュー）には、ダイアグラムに一般的に関連するコマンドか、または現在選択されているオブジェクトに関連するコマンドが含まれます。
特定の種類のオブジェクトの概要および使用方法の情報については、次のトピックを参照してください。
SQL Developer Data Modelerは、1つのオープン・データベース設計ともに動作します。これには、1つの論理モデル、論理モデルに基づく１つ以上のリレーショナル・モデル（オプション）および各リレーショナル・モデルに基づく1つ以上の物理モデル（オプション）が含まれます。 また、データベース設計には、データ型モデルとビジネス情報を含めることもできます。 別のデータベース設計で作業を行うには、現在の設計を閉じてから（「ファイル」→「閉じる」をクリック）、他のデータベース設計のオブジェクトを作成またはインポートします。
データベース設計を保存すると、構造情報が、指定したフォルダまたはディレクトリにXMLファイルで格納され、必要に応じて、その下にサブフォルダまたはサブディレクトリが作成されます。 XMLファイルには、これらのサブフォルダまたはサブディレクトリにある情報へのポインタが含まれます。 たとえば、my_db_modelという非常に基本的な設計の場合は、作成したフォルダまたはディレクトリを起点に次のような階層が作成されます。
my_db_model.xml
my_db_model
businessinfo
datatypes
subviews
logical
entity
subviews
mapping
pm
rdbms
rel
1
subviews
table
追加のサブフォルダまたはサブディレクトリが後で作成される場合があります。たとえば、プロセス・モデル内にデータ・フロー・ダイアグラムを作成すると、pmの下にdataflowsが作成されます。
SQL Developer Data Modelerは、その論理モデル内のスーパータイプおよびサブタイプをサポートするだけでなく、データ型モデルも提供します。これによって、CWM準拠になり、SQL99構造型のモデリングが可能になります。データ型モデルは、データ型として論理モデルおよびリレーショナル・モデル内で使用できます。
構造型は、スーパータイプおよびサブタイプの継承階層を構築できるユーザー定義の名前付きコンポジット型としてサポートされています。 固有型およびコレクション（配列）型を定義して、構造型と、構造型の継承階層を作成および可視化することができます。
論理モデルおよびリレーショナル・モデルでは、両方ともデータ型モデルからの定義を使用して、属性および列のデータ型を指定したり、表（エンティティ）が特定の構造型であることを定義できます。
データ型モデルは、次のような1つ以上の方法で構築できます。
SQL Developer Data Modelerで手動で構築する。
Oracle Designerリポジトリからインポートして構築する。 1.6.6「Oracle Designerモデルのインポート」を参照してください。
SQL Developer Data Modelerのデータ型モデルは、2種類のデータを結合します。
1つのデータ型ダイアグラム（さらに、オプションでサブビューおよび補助表示のセット。それぞれは適切なダイアグラム/サブビューに関連付けられます）
データ型オブジェクト定義
サブビューは、様々なサブジェクト領域を表すために作成される、データ型モデルの独立したダイアグラムとみなされます。
データ型モデルを使用すると、固有型、構造型、コレクション型および論理型のオブジェクト定義を作成および管理できます。
（論理型を除く）すべてのデータ型モデル・オブジェクトは、オブジェクト・ブラウザ・ツリーに表示されますが、データ型ダイアグラム上にグラフィカルに表示されるのは、構造型オブジェクトとその相互関係のみです。
次の図に示すとおり、データ型ダイアグラムでは、構造データ型とそれらのリンクがグラフィカルに表現されています。
構造型のボックスには、オブジェクトの名前、定義された属性およびメソッド（存在する場合）が含まれます。 ダイアグラムのリンクは、構造データ型とともに様々な属性を表します。
複雑なデータ型モデルで作業を行う場合は、サブビューを作成し、それぞれのサブビューでそのモデルの中のあるセクションのみを表すことができます。 1つのデータ型モデルに複数のデータ型サブビューを定義し、その複数のサブビューに１つの構造型を割り当てることができます。 ただし、2つの構造型間のリンク（参照）が表示されるのは、全体のデータ型モデル上と、両方の型が割り当てられたサブビュー上のみです。
サブビュー内での変更の実行と、全体のデータ型モデル内での変更の実行に違いはありません。 実行した変更は、全体モデルおよび関連サブビューに即座に反映されます。 ただし、構造型は、データ型モデルから削除することなく、サブビューから削除できます。
ユーザー定義の固有型は、「型の管理」ダイアログ・ボックスで定義された既存の論理型から導出されたデータ型です。 固有型は、その表現を既存の型（ソース型）と共有しますが、個別で互換性のない型とみなされます。
固有型オブジェクトにアクセスできるのは、それがデータ型フォルダの固有型サブフォルダにある場合のみです。
ユーザーは新しい固有型を作成したり、既存の固有型のプロパティを編集できます。
構造型は、属性およびメソッドを持つユーザー定義データ型です。 これは、スーパータイプおよびサブタイプの継承階層の一部になることもできます。 構造型は、基本データ型、固有型、別の構造型または構造型への参照をベースにして定義できますが、コレクション型として定義することもできます。
表またはエンティティは、構造型をベースにして定義できます。 型置換を使用すると、表（エンティティ）が収容できるサブタイプのインスタンスを（ダイアグラム上でグラフィカルに）表現できます。
表の列またはエンティティの属性は、構造型、構造型への参照、コレクション型、固有型および基本データ型をベースに定義できます。 型置換は構造型に基づく列に対して定義でき、範囲表は構造型への参照に基づく列に対して定義できます。
構造型には、一連のメソッド仕様も含まれます。 メソッドを使用すると、構造型の動作の定義できます。 ユーザー定義ファンクション（UDF）のように、メソッドはSQLを拡張するルーチンです。 ただし、メソッドの場合、動作と特定の構造型との統合は単独で行われます。
拡張構造型サブフォルダには、属性の階層とそれぞれのメソッドとともに、すべての構造型オブジェクトが示されます。
Oracle SpatialのSDO_GEOMETRY型は、構造型として事前定義されています。 また、ユーザーは新しい構造型を作成したり、既存の構造型のプロパティを編集できます。
コレクション型は、要素（基本型、固有型、構造型または別のコレクション）の配列またはコレクションを表現し、Oracle VARRAYおよびネストした表タイプにマップされます。
ユーザーは新しいコレクション型を作成したり、既存のコレクション型のプロパティを編集できます。
論理型は実際のデータ型ではなく、ネイティブの型またはドメインと関連付けることができる名前です。 事前に用意されている論理型には、Oracle Multimediaからのもの（ORDで始まる名前のもの）がいくつか含まれます。ただし、ORDIMAGE_SIGNATUREは非推奨であるため、新しい定義には使用しないでください。
論理型を作成し、ネイティブな型とのマッピングを編集することができます（3.94「型の管理」を参照）。また、ドメインを論理型に関連付けることができます（3.25「ドメイン管理」を参照）。
プロセス・モデルは、情報構造システムの機能領域を表します。 1つ以上のデータ・フロー・ダイアグラムでグラフィカルに表現されるプロセス・モデルは分析技術であり、入力がシステム（プロセスのグループ）を通って結果としての出力に至るフローをとらえるために使用されます。 モデルは、システム（既存のシステムや提案されたシステム）を通る情報のフローを表します。
データ・フロー・ダイアグラミングに必要なすべての要素が、Data Modelerプロセス・モデルでサポートされています。この要素には、プリミティブ・プロセス、分解レベルに制限がないコンポジット・プロセス、再使用可能な変換タスク、トリガー・イベント、情報ストア、外部エージェント、外部データ要素を説明するレコード構造、データ要素のソースとターゲットのマッピング、およびプリミティブ・プロセスとデータ要素の間のCRUD（作成、読取り、更新、削除）の依存性があります。
プロセス・モデルにおける概念で重要なものを次に示します。
プロセスは、ある特定の理由で実行されるアクティビティまたは機能です。 各プロセスが実行するアクティビティは、最終的に1つのみである必要があります。 プリミティブ・プロセスはスタンドアロン・プロセスです。 コンポジット・プロセスは複数の外部プロセスで構成されます。
トリガーは何らかの出来事であり、これが発生するとプロセスの実行が開始されます。
データ・フローは、1つのデータまたは情報の論理コレクションの動きを反映したものです。 フローはデータ・フロー・ダイアグラムの順序を表現します。 （詳細は、1.3.3.1「データ・フロー・ダイアグラム」を参照してください。）
外部エージェントは、システムの外部にありながらシステムと相互に作用する個人、組織またはシステムです。 外部エージェントは、プロセスに対して情報の送受信を行います。
情報ストアは、データ・モデルのエンティティおよび属性として情報を受信または保存する受動オブジェクトです。 最終的に、1つの情報ストアは、データ・モデルの1つ以上のエンティティに対応します。
入力および出力パラメータを含む変換タスクは、これを実行する周囲の環境と通信する実行ユニットです。 入力パラメータとして、処理を行う必要がある日付が考えられます。 出力パラメータとして、操作が成功したかどうかを示すコードが考えられます。 変換自体には、情報の読取り、変換および保存が含まれますが、この中には、入力および出力パラメータと直接結びついていないものがある場合があります。 （詳細は、1.3.3.2「変換パッケージ」を参照してください。）
ロールは、定義された権限およびアクセス権のセットです 情報ストアに接続されたプリミティブ・プロセス（データ要素を作成、読取り、更新および削除するプロセス）は、定義済ロールにアタッチできます。その結果、ロールとデータ要素との間のコラボレーションが定義されます。 後で、定義済のSelect、InsertおよびUpdate権限を持つ適切なデータベース・ロールが作成されるように、ロール定義を特定の物理モデルに送ることができます。
正式な構造分析アプローチでは、機能分解プロセスを容易にするために、データ・フロー・ダイアグラム（DFD）を使用します。 データ・フロー・ダイアグラムは、次のコンポーネントで構成されます。
外部インタラクタ: 矩形で表現されます。
データ・ストア: （二辺または三辺の）開矩形で表現されます。
プロセス: 丸みのあるオブジェクト（円、楕円または角が丸められた四角形）で表現されます。
プロセスは、アトミック・レベルから集計レベルに至る様々なレベルのいずれかでシステム機能を表現できます。
データ・フロー: 矢印で表現され、オプションでその内容を示すラベルが付けられます。
変換パッケージは、Object Management Group（OMG）のCommon Warehouse Metamodel（CWM）Specification、V1.1に定義されているパッケージです。 この仕様では、次のように変換パッケージが紹介されています。
「データ・ウェアハウスの主要な側面は、分析のために、業務リソースからデータを抽出し、それを変換して、データ・ウェアハウスまたはデータ・マートにロードすることです。 抽出、変換およびロードは、すべて変換とみなすことができます。 実際に、データ・ウェアハウス内である形式から別の形式にデータを変換する必要がある場合は、その目的が格納、取得、表示のいずれであっても変換が常に含まれます。 そのため、変換はデータ・ウェアハウスの中心となります。」
「変換パッケージには、データ・ウェアハウスで使用される変換の共通メタデータを表すクラスおよび関連付けが含まれます。 サポートされる変換は、オブジェクト指向、リレーショナル、レコード、多次元、XML、OLAP、データ・マイニングなど、すべてのタイプのデータソースとターゲットにわたる基本的な変換です。」
「変換パッケージは、変換ツールとアクティビティについての共通メタデータをやりとりできるように設計されています。」
SQL Developer Data Modelerの中心となるものは論理モデルです。これは、エンティティ関連ダイアグラムとも呼ばれます。 これは、実装には依存しない企業情報のビューを提供し、多次元モデルとプロセス・モデルの定義を様々な物理的実装にマップするメディエータとして機能します。 論理モデルまたはその構成要素（サブジェクト領域、サブビュー）は、1つ以上のリレーショナル・モデルに変換できます。
論理モデルは、次のいずれの方法でも構築できます。
SQL Developer Data Modelerで手動で構築する。
VARファイルにモデルをインポートして構築する。モデルには、Sterling COOL:DBA V2.1、Sterling Bsnteam V7.2、Cayenne Bsnteam V7.2、Rational Rose、TogetherJ、JDeveloper、MEGA、PowerDesigner v.12などによって作成されたものがあります。
SQL Developer Data Modelerで作成された既存のモデルをインポートして構築する。
インポートされたリレーショナル・モデルからリバース・エンジニアリングして構築する。
論理モデルは、次の2種類のデータを結合します。
1つの論理ダイアグラム（さらに、オプションでサブビューおよび補助表示のセット。それぞれは適切なダイアグラム/サブビューに関連付けられます）
論理モデル・オブジェクト定義
サブビューは、様々なサブジェクト領域を表すために作成される、論理モデルの独立したダイアグラムとみなされます。
論理モデルを使用すると、エンティティ、論理ビュー、属性、一意識別子、継承、リレーションおよびarcに対するオブジェクト定義を作成および管理できます。
すべての論理モデル・オブジェクトは、オブジェクト・ブラウザ・ツリーに表示されます。
論理モデル・ダイアグラムには、エンティティ、ビュー、およびそれらのリンク（リレーションおよび継承）のグラフィカルな表現が含まれます。
複雑な論理モデルで作業を行う場合は、サブビューを作成し、そのモデルの中のあるセクションのみを表すことができます。 1つの論理モデルに複数の論理サブビューを定義し、その複数のサブビューにエンティティとビューを割り当てることができます。 2つのエンティティ間のリンク（リレーション）が表示されるのは、全体の論理モデル上と、参照される両方のエンティティが割り当てられた論理サブビュー上のみです。
1つのサブビュー内での変更の実行と、全体の論理モデル内での変更の実行に違いはありません。 実行した変更は、全体の論理モデルおよび関連サブビューに即座に反映されます。 ただし、エンティティおよびビューは、全体の論理モデルから削除することなく、サブビューから削除できます。
特定のエンティティを含むサブビューを作成するには、論理モデル・ダイアグラムで目的のエンティティを選択して右クリックし、「選択した項目からサブビューを作成」を選択します。
Data Modelerでは、論理モデル・ダイアグラム表記として次の代替表記法をサポートしています。
Bachman表記法
Barker表記法
それぞれの表記法について、そのスタイルの詳細な説明および例は、書籍およびWebで広く入手できます。 「Data Modelerオプション(ユーザー・プリファレンス)」（「一般オプション」、「ダイアグラム」、「論理」）では、新しい論理ダイアグラムのデフォルトの表記法タイプを設定できます。
1つの表記法タイプから他に切り替えるには（また、ダイアグラムの違いを参照するには）、論理モデル・ダイアグラムを選択し、「ビュー」→「論理モデル表記法」をクリックしてから、現行とは異なる表記法をクリックします。
エンティティは、ユーザーが情報を格納しようと考えているオブジェクトまたは概念です。 エンティティの構造は、属性のコレクションとして定義したり、データ型モデルからの構造型をベースにして定義できます。 エンティティに候補となる一意識別子が複数あっても、プライマリ一意識別子として定義できるのは、そのうちの1つです。 通常、エンティティはリレーショナル・モデルの表にマップされます。
データ属性（プロパティ、データ要素、フィールド）は、特定のエンティティに共通している特徴です。 属性のデータ型は、論理データ型、ドメイン、固有型、コレクション型または構造型をベースにすることができますが、構造型への参照にすることもできます。 構造型への参照である場合は、範囲エンティティを定義できます。 属性はリレーショナル・モデルの列にマップされます。
エンティティの一意識別子は、1つ以上の属性で構成できます。 エンティティごとに、それぞれのエンティティの出現を一意に識別するプライマリ一意識別子を定義できます。 また、1つ以上の外部一意識別子を指定することもできます。この識別子は、それぞれが別のエンティティの一意識別子を指します。つまり、この識別子には、別のエンティティの一意識別子にある値を含める必要があります。
継承は、スーパータイプおよびサブタイプに基づくエンティティの階層を定義します。 スーパータイプおよびサブタイプのエンティティはシステムの一部に相当し、そこには、既存エンティティ・タイプの出現の認識可能なサブセットがあります。 サブセットはエンティティのサブタイプと呼ばれ、元のエンティティ・タイプがスーパータイプになります。
スーパータイプのすべての属性とリレーションシップは、そのすべてのサブタイプに属している必要があります。 ただし、サブタイプの一部の属性とリレーションシップは、スーパータイプの属性とリレーションシップに追加されます。 サブタイプの定義が有効に行われるのは、スーパータイプの属性に加え、エンティティの出現の識別可能なグループに属性がある場合です。
リレーション（データ・リレーションシップ）は、2つ以上のエンティティの間に存在する自然な関連です。 カーディナリティは、関連エンティティの1回の出現に対する1つのエンティティの出現回数を定義します。
リレーションシップは識別または非識別にすることができます。また、カーディナリティとして1:1（1対1）、1:N（1対多）またはN:M（多対多）が可能です。 N:Mのカーディナリティを持つリレーションは、リレーショナル・モデルの参照表にマップされます。 識別リレーションシップは、そのリレーションシップが、ターゲット・エンティティのプライマリ識別子の構成要素であることを示します。
arcは排他的なリレーションシップ・グループであり、エンティティのいずれのインスタンスでも、存在できるリレーションシップは1つだけであると定義されています。 たとえば、セミナーではスタッフ・メンバーか外部コンサルタントのいずれかが教えることができますが、両方が同時に教えることはできません。 例として、新入社員のためのセミナーは企業のスタッフ・メンバーだけで教えることができますが、製品XYXを使用するセミナーは特別な資格を持つ外部コンサルタントだけが教えることができる場合があります。
arcに含まれるすべてのリレーションは同じエンティティに属している必要があり、同じカーディナリティを持つ必要があります。arcのリレーションシップに属している外部一意識別子（外部UID）属性は、フォワード・エンジニアリング時に「NULLの許可」として転送される必要があります。 arcにおける必須リレーションシップの意味は、エンティティの特定のインスタンスに対して、1つのリレーションシップのみが存在する必要があるということです。
arcの作成は、そこに含めるすべてのリレーションシップを作成した後に行います。 エンティティ・ボックスを選択し、含めるすべてのリレーションシップの線を選択します（[Shift]キーを押したまま各行をクリックします）。ツールバーの「新規arc」ボタンをクリックするか、「オブジェクト」→「論理」→「新規arc」をクリックします。
リレーショナル・モデルは、SQL表、列および表間の結合という観点からデータベースを表します。 論理モデルから選択する各エンティティは、リレーショナル・モデル内の表として表されます。 各行は表であり、対応するエンティティの特定（個別）の出現を表します。 エンティティの各属性は、表の列によって表されます。
リレーショナル・モデルは、次のいずれの方法でも構築できます。
SQL Developer Data Modelerで手動で構築する。
論理モデルまたは論理モデルのサブビューからフォワード・エンジニアリングして構築する。
VARファイルにモデルをインポートして構築する。モデルには、Sterling COOL:DBA V2.1、Sterling Bsnteam V7.2、Cayenne Bsnteam V7.2、Rational Rose、TogetherJ、JDeveloper、MEGA、PowerDesigner v.12などによって作成されたものがあります。
SQL Developer Data Modelerで作成された既存のモデルをインポートして構築する。
Oracle Designerモデルをインポートして構築する。
既存のデータベース実装に基づくDDLファイルをインポートして構築する。
サポートされているデータベース・タイプおよびバージョンのデータ・ディクショナリからインポートして構築する。
リレーショナル・デルは、次の2種類のデータを結合します。
1つのリレーショナル・ダイアグラム（さらに、オプションでサブビューおよび補助表示のセット。それぞれは適切なダイアグラム/サブビューに関連付けられます）
リレーショナル・モデル・オブジェクト定義
サブビューは、様々なサブジェクト領域を表すために作成される、リレーショナル・モデルの独立したダイアグラムとみなされます。
リレーショナル・モデルを使用すると、表、ビュー、列、索引および外部キーに対するオブジェクト定義を作成および管理できます。 リレーショナル・モデルには、1つ以上の物理モデルを含めることができます。
すべてのリレーショナル・モデル・オブジェクトは、オブジェクト・ブラウザ・ツリーに表示されます。
リレーショナル・ダイアグラムには、表、ビュー、およびそれらのリンクのグラフィカルな表現が含まれます。
複雑なリレーショナル・モデルで作業を行う場合は、サブビューを作成し、そのモデルの中のあるセクションのみを表すことができます。 1つのリレーショナル・モデルに複数のリレーショナル・サブビューを定義し、その複数のサブビューに表とビューを割り当てることができます。 2つの表間のリンク（リレーション）が表示されるのは、全体のリレーショナル・モデル上と、参照される両方の表が割り当てられたリレーショナル・サブビュー上のみです。
データ・ディクショナリからインポートを行う場合に、インポートするスキーマを複数選択すると、すべてのスキーマを対象にしたリレーショナル・モデルが1つ作成され、サブビューはスキーマごとに1つ作成されます。
1つのサブビュー内での変更の実行と、全体のリレーショナル・モデル内での変更の実行に違いはありません。 実行した変更は、全体のリレーショナル・モデルおよび関連サブビューに即座に反映されます。 ただし、表およびビューは、全体のリレーショナル・モデルから削除することなく、サブビューから削除できます。
表は、情報を格納するオブジェクトです。 表の構造は、列のグループとして定義したり、データ型モデルからの構造型をベースにして定義できます。 表に候補となるキーが複数あっても、主キーとして定義できるのは、そのうちの1つです。 通常、表は論理モデルからエンティティにマップされます。
表の列は、特定の表に共通している特徴です。 列のデータ型は、論理データ型、ドメイン、固有型、コレクション型または構造型をベースにすることができますが、構造型への参照にすることもできます。 構造型への参照である場合は、範囲表を定義できます。 通常、表の列は、論理モデルから対応するエンティティの属性にマップされます。
索引は、実表の列に対するポインタの順序付けされたセットで構成されるオブジェクトです。 各索引は、1つ以上の表列のデータの値に基づきます。 頻繁に検索される列に索引を定義することで、データベース・アプリケーションのパフォーマンスを向上させることができます。
リレーション（データ・リレーションシップ）は、2つ以上の表の間に存在する自然な関連です。 リレーションシップは、プライマリ・キーおよび外部キーのデータ値で表されます。 カーディナリティは、関連表での1回の出現に対する1つの表での出現回数を定義します。
識別リレーションシップは、そのリレーションシップが、ターゲット表のプライマリ識別子の構成要素であることを示します。
排他的なリレーションシップ（arc）は、表内の特定のインスタンスに対して、存在できるリレーションシップは1つだけであることを指定します。 たとえば、セミナーではスタッフ・メンバーか外部コンサルタントのいずれかが教えることができますが、両方が同時に教えることはできません。 例として、新入社員のためのセミナーは企業のスタッフ・メンバーだけで教えることができますが、製品XYXを使用するセミナーは特別な資格を持つ外部コンサルタントだけが教えることができる場合があります。
arcのすべてのリレーションシップは、同じ表に属し、同じカーディナリティを持つ必要があります。 arcのリレーションシップに属しているすべての外部キー（FK）属性は、フォワード・エンジニアリング時に「NULLの許可」として転送される必要があります。 arcにおける必須リレーションシップの意味は、表の特定のインスタンスに対して、1つのリレーションシップのみが存在する必要があるということです。
arcの作成は、そこに含めるすべてのリレーションシップを作成した後に行います。 表ボックスを選択し、含めるすべてのリレーションシップの線を選択します（[Shift]キーを押したまま各行をクリックします）。ツールバーの「新規arc」ボタンをクリックするか、「オブジェクト」→「リレーショナル」→「新規arc」をクリックします。
物理モデルは、リレーショナル・モデルに基づいたOracle Databaseオブジェクト（表、ビュー、トリガーなど）の観点からデータベースを表します。 各リレーショナル・モデルには、1つ以上の物理モデルを含めることができます。 次に、複数のリレーショナル・モデルおよび物理モデルを持つデータベース設計階層を示します。
データベース設計
論理モデル
リレーショナル・モデル1
物理モデル1a
物理モデル1b
. . . （他の物理モデル）
リレーショナル・モデル2
物理モデル2a
物理モデル2b
. . . （他の物理モデル）
. . . （他のリレーショナル・モデル）
各物理モデルは、RDBMSサイト・オブジェクトに基づきます。 RDBMSサイトは、Data Modelerでサポートされるデータベースのタイプに関連付けられた名前です。 事前に定義されているRDBMSサイトもあります（Oracle 11g、Microsoft SQL Server 2005用など）。 また、「RDBMSサイト・エディタ」ダイアログ・ボックスを使用して、サポートされているデータベース・タイプの別名としてユーザー定義のRDBMSサイトを作成することもできます。たとえば、異なる物理モデルを生成してから変更できるように、TestおよびProductionという名前のサイトを作成する場合があります。
作業領域には物理モデルのグラフィカルな表現はありませんが、かわりに、オブジェクト・ブラウザ階層に表示されます。 物理モデルでオブジェクトを作成および管理するには、オブジェクト・ブラウザで「物理」メニューまたはコンテキスト・メニュー（右クリック）を使用します。
このトピックの残りの部分では、様々なOracle Databaseオブジェクトについて簡単に説明します。説明するオブジェクトの順序は、Oracle物理モデルにおける表示順ではありません。
クラスタは、1つ以上の表からのデータを含むスキーマ・オブジェクトです。
索引クラスタには複数のクラスタが含まれる必要があり、クラスタ内のすべての表が1つ以上の共通する列を持ちます。 Oracle Databaseは、同じクラスタ・キーを共有するすべての表のすべての行をまとめて格納します。
1つ以上の表を含めることができるハッシュ・クラスタの場合、Oracle Databaseは同じハッシュ・キー値を持つ行をまとめて格納します。
ディメンションは、列セットのペア間の親子関係を定義します。1つの列セットのすべての列は、同じ表からのものである必要があります。 ただし、一方の列セット（1つのレベル）の列と、もう一方のセットの列は、異なる表からのものでも可能です。 オプティマイザは、マテリアライズド・ビューとこれらのリレーションシップを使用して、クエリー・リライトを実行します。 SQLアクセス・アドバイザは、これらのリレーションシップを使用して、特定のマテリアライズド・ビューの作成を推奨します。
ディレクトリは、外部バイナリ・ファイルLOB（BFILE）および外部表データが存在するサーバー・ファイル・システムのディレクトリ（Windowsシステムではフォルダと呼ばれる）の別名です。
PL/SQLコードおよびOCIコールでBFILEを参照する際に、オペレーティング・システムのパス名をハードコードするかわりにディレクトリ名を使用して、管理の柔軟性を向上できます。 すべてのディレクトリは1つのネームスペースに作成され、個別のスキーマでは所有されません。 ディレクトリ構造内に格納されたBFILEへのセキュアなアクセスを確保するには、ディレクトリのオブジェクト権限を特定のユーザーに付与します。
ディスク・グループは、Oracle Databaseが論理ユニットとして管理するディスクのグループであり、各ファイルは、I/Oのバランスをとるために、すべてのディスクに均一に分散されます。また、Oracle Databaseでは、ディスク・グループで使用可能なすべてのディスクにデータベース・ファイルが自動的に分散され、記憶域構成が変わると常に、記憶域が自動的にリバランスされます。
外部表は、外部ソースのデータがデータベースの表に存在するかのように、外部ソースのデータにアクセスできるようにします。 外部表を使用するには、使用しているプラットフォーム上のデータファイルについて、ファイル形式およびレコード形式の知識がいくらか必要です。
索引は、表またはクラスタの索引列の各値に対するエントリが含まれるデータベース・オブジェクトです。行に対して、直接的な高速アクセスが可能です。 索引は、主キー列で自動的に作成されます。ただし、索引を有効に利用するには、他の列で索引を作成する必要があります。
ロールは、ユーザーまたは他のロールに付与することができる権限のセットです。 ロールを使用して、データベース権限を管理できます。 ロールに権限を追加し、そのロールをユーザーに付与することができます。 その後、ユーザーはロールを有効にして、そのロールによって付与された権限を行使することができます。
ロールバック・セグメントは、Oracle Databaseが使用するオブジェクトであり、トランザクションによって行われた変更をリバースする（元に戻す）ために必要となるデータが格納されます。 ただし、ロールバック・セグメントを使用するかわりに、自動UNDO管理モードでデータベースを実行することをお薦めします。 ロールバック・セグメントは、旧バージョンのOracle Databaseとの互換性のために必要となる場合を除き、使用しないでください。 自動UNDO管理の詳細は、『Oracle Database管理者ガイド』を参照してください。
セグメントは、表領域内の論理記憶域構造のすべてのデータが含まれるエクステントのセットです。 たとえば、Oracle Databaseは、1つの表のデータ・セグメントを作成するために1つ以上のエクステントを割り当てます。 また、データベースは、表の索引セグメントを作成するためにも、1つ以上のエクステントを割り当てます。
スナップショットは、自動データベース診断モニター（ADDM）がパフォーマンス比較のために使用する、特定期間の一連の履歴データです。 デフォルトでは、Oracle Databaseは自動的にパフォーマンス・データのスナップショットを生成し、ワークロード・リポジトリに統計を保持します。 スナップショットは手動でも作成できますが、通常は必要ありません。 スナップショット間隔でのデータは、ADDMによって分析されます。 ADDMの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
ストアド・プロシージャは、一連のSQL文と他のPL/SQL構文で構成されるスキーマ・オブジェクトです。これらは、まとめてグループ化されてデータベースに格納され、特定の問題を解決したり、一連の関連タスクを実行するために1つの単位として実行されます。
シノニムは、表、ビュー、順序、プロシージャ、ストアド・ファンクション、パッケージ、ユーザー定義のオブジェクト・タイプまたは他のシノニムの代替名です。 シノニムはパブリック（すべてのデータベース・ユーザーが使用可能）、またはプライベート（シノニムを所有するデータベース・ユーザーのみが使用可能）にできます。
構造型は、プロパティの固定されたセットを、表の列で使用できる値に関連付ける複雑なデータ型です。 このプロパティによって、Oracle Databaseでは、あるデータ型の値と別のデータ型の値が異なる方法で処理されます。 ほとんどのデータ型は、Oracleによって提供されています。ただし、ユーザーがデータ型を作成することもできます。
表は、データの保持に使用されます。 通常、それぞれの表には、その表に関連付けられたデータベース・エンティティの属性を表す複数の列が存在し、それぞれの列には、データ型が関連付けられます。 企業の様々なニーズに対応するために、多くの表作成オプションと表構成（パーティション表、索引構成表、外部表など）を使用できます。
表領域は、データベースにおける領域の割当てであり、そこにはスキーマ・オブジェクトが含まれます。
永続表領域には、永続スキーマ・オブジェクトが含まれます。 永続表領域のオブジェクトは、データファイルに格納されます。
UNDO表領域は、データベースを自動UNDO管理モードで実行している場合に、Oracle DatabaseがUNDOデータを管理するために使用する、一種の永続表領域です。 元に戻す場合は、ロールバック・セグメントではなく、自動UNDO管理モードを使用することをお薦めします。
一時表領域には、セッション期間のみのスキーマ・オブジェクトが含まれます。 一時表領域のオブジェクトは、一時ファイルに格納されます。
データベース・ユーザーは、データベースにログインするためのアカウントです。 （データベース・ユーザーはデータベース・オブジェクトであり、データベース、またはデータベースにアクセスするアプリケーションのユーザー（人間に相当するユーザー）とは異なります） 各データベース・ユーザーには、ユーザーと同じ名前を持つデータベース・スキーマがあります。
ビジネス情報オブジェクトは、モデル・オブジェクトについてビジネス志向の情報を定義します。この情報には、責任者とその連絡方法や、関連するオフライン・ドキュメントの識別などがあります。
モデル・オブジェクトは、自身に関連付けられたビジネス情報オブジェクトを、ゼロまたは1つ以上持つことができます。また、ビジネス情報オブジェクトは、ゼロまたは1つ以上のモデル・オブジェクトに関連付けることができます。 たとえば、1つのドキュメントは数多くの異なるエンティティおよび属性を説明するために使用できます。また、1人の人間は複数のイベントの責任者になることができます。
ビジネス・オブジェクト間には、多対多のリレーションシップが存在していてもかまいません。 たとえば、責任者はコンタクト先情報（コンタクト先オブジェクト）を複数セット持つことができます。また、コンタクト先オブジェクトは複数の責任者に関連付けることができます。 同様に、1つ以上の電話、電子メール、ロケーションおよびURLオブジェクトを、複数のコンタクト先オブジェクトに関連付けることができます。
Data Modelerビジネス情報モデルは、Object Management Group（OMG）ビジネス情報パッケージに基づいています。これは、OMGのCommon Warehouse Metamodel（CWM）Specification、V1.1に、次のように説明されています。「ビジネス情報メタモデルは、モデル要素についてのビジネス指向情報を定義するために、すべてのCWMパッケージで使用可能な汎用サービスを提供します。 ここで説明されるビジネス指向サービスは、データ・ウェアハウスおよびビジネス・インテリジェンス・システムのニーズをサポートするように設計されています。汎用ビジネス・インテリジェンス・メタモデルを完全に表現するようには意図されていません。 ビジネス情報メタモデル・サービスは、責任者とその連絡方法、オフライン・ドキュメントの識別および汎用的な記述情報のサポートについて、その概念をサポートします。」
このトピックの残りの部分では、ビジネス情報オブジェクトについて簡単に説明します。説明するオブジェクトの順序は、ビジネス情報のオブジェクト・ブラウザにおける表示順ではありません。
コンタクト先オブジェクトは、関連する様々なタイプのコンタクト先情報をグループ化します。 各コンタクト先オブジェクトは、複数の電子メール、ロケーション、URLおよび電話オブジェクトに関連付けることができます。 反対に、各電子メール、ロケーション、URLおよび電話オブジェクトは、多数のコンタクト先オブジェクトに関連付けることができます。 （3.12「コンタクト先のプロパティ」も参照してください。）
ドキュメント・オブジェクトは、モデル化されたシステムのいくつかの側面について、外部に格納された記述情報を表します。 ドキュメント・オブジェクトは、1つ以上のモデル・オブジェクトに関連付けることができます。 （3.23「ドキュメントのプロパティ」も参照してください。）
電子メール・オブジェクトは、1つの電子メール・アドレスを識別します。 コンタクト先オブジェクトを使用すると、電子メール・アドレスを1人以上の責任者と関連付けることができます。 コンタクト先の電子メール・オブジェクトの順序は、コンタクト先との通信に使用を試みる電子メール・アドレスの順番で表される場合があります。 （3.26「電子メールのプロパティ」も参照してください。）
ロケーション・オブジェクトは、1つの物理的な場所を識別します。 コンタクト先オブジェクトを使用すると、ロケーションを1人以上の責任者と関連付けることができます。 ロケーションのコンタクト先オブジェクトの順序は、ロケーションに関連付けられた個人またはグループへの連絡を試みる際の順番で表される場合があります。 （3.54「ロケーションのプロパティ」も参照してください。）
リソース・ロケータ・オブジェクトは、従来のメール・アドレスでロケーションが定義されていないリソースを表すための一般的な手段を提供します。 たとえば、リソース・ロケータは、ウェブアドレス（www.example.comなど）から、建物内の場所（317号室、3番目のファイル・キャビネット、2番目の引出しなど）に至るまで、どのよう場所でも参照することができます。 （3.74「リソース・ロケータのプロパティ」も参照してください。）
責任者オブジェクトは、1つ以上のモデル・オブジェクトについての情報に責任を持っていたり、その情報を受け取る必要がある個人、ロールまたは組織を表します。 責任オブジェクトにおける責任の正確な意味は、実装されている特定のシステムに応じて異なります。 （3.75「責任者のプロパティ」も参照してください。）
電話オブジェクトは、電話でのコンタクト先情報を表します。 電話オブジェクトは、1つ以上のコンタクト先に関連付けることができます。 （3.89「電話のプロパティ」も参照してください。）
データをモデル化する場合は、実行する作業の特質に最も適したアプローチを選択できます。 データ・モデリングへのアプローチには、新しいデータベースの設計、既存のデータベースに向けた設計の開発、または既存のデータベース設計でのメンテナンスの実行が含まれます。
トップダウン・モデリング: 新しいデータベースを設計する場合
ボトムアップ・モデリング: 既存のデータベースからメタデータを抽出してデータベースを作成する場合、または既存のデータベースの実装から取得したDDLコードを使用してデータベースを作成する場合
ターゲット・モデリング: データベースを新しい要件に適応させる場合
トップダウン・モデリングでは、業務要件および内部環境についての情報を収集しから、プロセス、データの論理モデル、１つ以上のリレーショナル・モデル、および各リレーショナル・モデルの1つ以上の物理モデルを定義します。 ニーズによっては、手順と情報要件は簡単なものから詳細なものに及ぶことがあります。 トップダウン・モデリングには次の手順が含まれますが、ニーズに合わせて手順を短縮したり、省略することができます。
ビジネス情報を作成します。
ドキュメントを作成します。オブジェクト・ブラウザで「論理」を右クリックして、「プロパティ」を選択します。次に、「ドキュメント」をクリックして、適切な項目を追加します。
コンタクト先、電子メール・アドレス、ロケーションおよび電話番号を使用して、責任者を作成します。 オブジェクト・ブラウザで「論理」を右クリックして、「プロパティ」を選択します。次に、「責任者」をクリックして、適切な項目を追加します。
他の情報を定義します。オブジェクト・ブラウザで「論理」を右クリックして、「プロパティ」を選択します。次に、必要に応じて他のプロパティ（「ネーミング・オプション」、「コメント」、「注意」）を変更します。
データ・フロー・ダイアグラムを使用して、プロセス・モデルを開発します。 プロセス・モデルのオブジェクト・ブラウザで「データ・フロー・ダイアグラム」を右クリックして、「新規データ・フロー・ダイアグラム」を選択します。
プロセスを作成します。プロセスごとに、「新規プロセス」アイコンをクリックしてデータ・フロー・ダイアグラム・ウィンドウの中をクリックし、「プロセスのプロパティ」ダイアログ・ボックスに情報を入力します。
外部エージェントを作成します。外部エージェントごとに、「新規外部エージェント」アイコンをクリックしてデータ・フロー・ダイアグラム・ウィンドウの中をクリックし、「外部エージェントのプロパティ」ダイアログ・ボックスに情報を入力します。
情報ストアを作成します。プロセスごとに、「新規情報ストア」アイコンをクリックしてデータ・フロー・ダイアグラム・ウィンドウの中をクリックし、「情報ストアのプロパティ」ダイアログ・ボックスに情報を入力します。
情報構造を使用してフローを作成します。 フローごとに、「新しいフロー」アイコンをクリックし、データ・フロー・ダイアグラム・ウィンドウで始点オブジェクト（プロセスなど）をクリックして、フローの終点オブジェクトをクリックします。次に、フローの矢印をダブルクリックして、「フローのプロパティ」ダイアログ・ボックスの情報を（必要に応じて）変更します。
論理モデルを作成します。
エンティティを作成し、各エンティティの属性および一意識別子を作成します。 最初にすべてのエンティティを作成しから、それぞれの属性および一意識別子を作成できます。また、1番目のエンティティとその属性および一意識別子を作成し、次に2番目以降も同じように順次作成していくこともできます。
エンティティを作成するには、「論理」タブをクリックして「新規エンティティ」アイコンをクリックし、論理モデル・ウィンドウの中をクリックして、「エンティティのプロパティ」ダイアログ・ボックスに情報を入力します。 また、このダイアログ・ボックスの該当するペインを使用して、属性および一意識別子を入力することもできます。
エンティティ間のリレーションを作成します。リレーションごとに、目的のアイコンをクリックします。アイコンには、「新規M:Nリレーション」（多対多）、「新規1:Nリレーション」（1対多）、「新規1:N識別リレーション」（１対多、識別）または「新規1:1リレーション」（1対1）があります。 リレーションの始点のエンティティをクリックし、次にリレーションの終点のエンティティをクリックします。次に、リレーションの線をダブルクリックして、「リレーションのプロパティ」ダイアログ・ボックスの情報を（必要に応じて）変更します。
論理モデルに設計ルールを適用します。 「ツール」→「設計ルール」をクリックし、「設計ルール」ダイアログ・ボックスを使用して、デザイン・ルールの違反を確認して修正します。
論理モデルをリレーショナル・モデルにフォワード・エンジニアします。「設計」→「リレーショナル・モデルのエンジニア」をクリックし、「エンジニアリング」ダイアログ・ボックスを使用して、論理モデルのすべてのオブジェクトまたは指定されたオブジェクトのサブセットを反映するリレーショナル・モデルを生成します。
必要に応じて、多次元モデルを作成します。
キューブを作成します。
レベルを作成します。
ディメンションを作成します。
リンクを作成します。
多次元モデルに設計ルールを適用します。
必要に応じて、多次元モデルをエクスポートします。
必要に応じて、1つ以上のリレーショナル・モデルを作成します。作成するには、各リレーショナル・モデルで次の手順を実行します。
表を分割します。 1つの表を2つに分割するには、リレーショナル・モデル・ダイアグラムで表を選択して、「表の分割」ボタンをクリックするか、「オブジェクト」→「リレーショナル」→「表の分割」をクリックします。
表をマージします。 別の表に表をマージ（マージされる表は削除）するには、「表のマージ」ボタンをクリックするか、「オブジェクト」→「リレーショナル」→「表のマージ」をクリックします。 次に、リレーショナル・モデル・ダイアグラムで、まず他の表からの列のマージ先となる表を選択してから、マージ元の列を持つ他の表を選択します。 （マージ後、2番目の表は削除されます。）
リレーショナル・モデル用の設計ルールを確認します。 「ツール」→「設計ルール」をクリックします。
リレーショナル・モデルごとに、1つ以上の物理モデルを作成します。作成するには、各リレーショナル・モデルで次の手順を実行します。
物理モデルを開きます。
物理モデル用の設計ルールを確認します。 「ツール」→「設計ルール」をクリックします。
実際のデータベース・オブジェクトの生成に使用できるDDLコードを生成します。 「ビュー」→「DDLファイル・エディタ」をクリックします。次に、「DDLファイル・エディタ」ダイアログ・ボックスを使用して、物理モデルの選択、DDLコードの生成およびコードのスクリプト・ファイルへの保存を行います。
ボトムアップ・モデリングは、既存のデータベースから抽出されたメタデータに基づいてデータベース設計を構築するか、または既存のデータベースを実装するDDLコードのファイルに基づいてデータベース設計を構築します。 作成されるデータベースは、リレーショナル・モデルおよび物理モデルとして表され、リレーショナル・モデルから論理モデルをリバース・エンジニアします。 ボトムアップ・モデリングには次の手順が含まれますが、ニーズに合わせていくつかの手順を短縮したり、省略することができます。
次のいずれかの方法で、リレーショナル・モデルを生成します。
既存のデータベースから直接メタデータを抽出します。「ファイル」→「インポート」→「データ・ディクショナリ」をクリックし、ウィザードの指示に従います（「データ・ディクショナリ・インポート(メタデータ抽出)」を参照してください）。
既存のデータベース実装を反映するDDLコードをインポートします。 「ファイル」→「インポート」→「DDLファイル」をクリックします。
必要に応じて、リレーショナル・モデルを変更して、追加のリレーショナル・モデルを作成します。
必要に応じて、リレーショナル・モデルを非正規化します。必要に応じて、各モデルに対して次の手順を繰返し実行します。
表の分割またはマージ、あるいはその両方を実行します。
1つの表を2つに分割するには、リレーショナル・モデル・ダイアグラムで表を選択して、「表の分割」ボタンをクリックするか、「オブジェクト」→「リレーショナル」→「表の分割」をクリックします。
別の表に表をマージ（マージされる表は削除）するには、「表のマージ」ボタンをクリックするか、「オブジェクト」→「リレーショナル」→「表のマージ」をクリックします。 次に、リレーショナル・モデル・ダイアグラムで、まず他の表からの列のマージ先となる表を選択してから、マージ元の列を持つ他の表を選択します。 （マージ後、2番目の表は削除されます。）
モデル用の設計ルールを確認します。設計ルールを表示するには、「ツール」→「設計ルール」をクリックし、目的のリレーショナル・モデルを選択して、「設計ルール」ダイアログ・ボックスを使用します。
リレーショナル・モデルから論理モデルにリバース・エンジニアします。「論理モデルのエンジニア」アイコンをクリックするか、または「設計」→「論理モデルのエンジニア」をクリックします。
必要に応じて、論理モデルを変更します。
論理モデル用の設計ルールを確認します。「ツール」→「設計ルール」をクリックします。
設計を保存します。
DDLコードを作成し、それを使用してデータベース実装を作成します。 「ビュー」→「DDLファイル・エディタ」をクリックします。 「DDLファイル・エディタ」ダイアログ・ボックスで、物理モデルを選択して「生成」をクリックします。 目的の「DDL生成オプション」を指定して、「OK」をクリックします。
ターゲット・モデリングには、既存のデータベースのメンテナンスが含まれますが、これは新しい要件に適応させて行います。
|
注意: SQL Developer Data Modelerでデータベースをメンテナンスするには、設計と実際のデータベース実装が完全に同期する必要があります。 これに該当するかどうか不明な場合は、設計を古いものとみなして、1.4.2「ボトムアップ・モデリング」の手順を実行する必要があります。 |
必要な変更の種類に応じて、論理モデル、1つ以上のリレーショナル・モデルまたは1つ以上の物理モデルから開始し、必要に応じて、フォワード・エンジニアまたはリバース・エンジニアを行うことができます。
論理モデルの変更から開始する方法
変更する論理的モデル・オブジェクト（エンティティ、属性、リレーションなど）ごとに、そのプロパティを変更します。 たとえば、エンティティに属性を追加するには、次の手順を実行します。
論理ダイアグラムでエンティティのアイコンをダブルクリックします（または、オブジェクト・ブラウザでエンティティ名を右クリックして、「プロパティ」を選択します）。
「エンティティのプロパティ」ダイアログ・ボックスで、「属性」をクリックします。
「追加」（+）アイコンをクリックして、属性プロパティを指定します。
論理モデルの変更が完了したら、「論理」ペインをクリックし、「設計」→「リレーショナル・モデルのエンジニア」をクリックして、変更点をリレーショナル・モデルにフォワード・エンジニアします。
「エンジニアリング」ダイアログ・ボックスで、必要なフィルタリングを指定して「エンジニア」をクリックします。
リレーショナル・モデルの変更から開始する方法
変更するリレーショナル・モデル・オブジェクト（表、列など）ごとに、そのプロパティを変更します。 たとえば、リレーショナル・モデルの表に列を追加するには、次の手順を実行します。
リレーショナル・モデルのダイアグラムで表のアイコンをダブルクリックします（または、オブジェクト・ブラウザで表名を右クリックして、「プロパティ」を選択します）。
「表のプロパティ」ダイアログ・ボックスで、「列」をクリックします。
「追加」（+）アイコンをクリックして、列プロパティを指定します。
リレーショナル・モデルの変更が完了したら、リレーショナル・モデルのペインをクリックし、「設計」→「論理モデルのエンジニア」をクリックし、変更点を論理モデルにリバース・エンジニアします。
「エンジニアリング」ダイアログ・ボックスで、必要なフィルタリングを指定して「エンジニア」をクリックします。
「ツール」→「一般オプション」をクリックして、SQL Developer Data Modelerの数ある側面をカスタマイズできます。
多くのプリファレンスはわかりやすいものであるため、ここでは、意味と意図が明確でないプリファレンスについてのみ説明します。 プリファレンスは、次のカテゴリにグループ化されています。
「一般」ペインには、SQL Developerの起動、動作全体および外観に影響するオプションが含まれます。
デフォルト設計ディレクトリ: 設計を開く場所または設計を作成する場所になるデフォルトのディレクトリまたはフォルダです。
デフォルト・インポート・ディレクトリ: 設計のインポート元になるデフォルトのディレクトリまたはフォルダです。
インポート後にログの表示: インポート操作の後に、「ログ」ウィンドウを表示するかどうかを制御します。 ウィンドウには、情報メッセージと、警告またはエラー・メッセージが含まれます。
「リレーショナル・モデルの選択」ダイアログの表示: Data Modeler設計を開くときに、含めるリレーショナル・モデルを選択するためのダイアログ・ボックスを表示するかどうかを制御します。 このオプションを無効にすると、Data Modeler設計を開くときに、すべてのリレーショナル・モデルがデフォルトで含まれます。
「新規オブジェクトの「プロパティ」ダイアログの表示」: 新しいモデル・オブジェクトを作成するときに、そのタイプのオブジェクトの「プロパティ」ダイアログ・ボックスを表示するかどうかを制御します。
「モデル」ペインには、数種類のモデルに適用されるオプションが含まれます。
デフォルトRDBMSタイプ: デフォルトのデータベース・タイプです。
デフォルトRDBMSサイト: デフォルトのデータベース・タイプ内のデフォルトのサイトです。
列および属性のデフォルト: NULLの許可: 新しい列と属性がNULL値を持つことができるかどうかを制御します。 このオプションを無効にすると、新しい列と属性はデフォルトで必須になります（値が必要になります）。
モデル: 論理
論理モデルに適用するオプションが含まれます。
リレーション・カーディナリティ: ソースは任意: リレーションシップ内のソース・エンティティにデフォルトで1つ以上のインスタンスを含める必要があるかどうかを制御します。 このオプションを有効にすると、すべてのリレーションシップ・タイプでソース・インスタンスが不要になります。このオプションを無効にすると、すべてのリレーションシップ・タイプで1つ以上のソース・インスタンスが必要になります。
リレーション・カーディナリティ: ターゲットは任意: リレーションシップ内のターゲット・エンティティにデフォルトで1つ以上のインスタンスを含める必要があるかどうかを制御します。 このオプションを有効にすると、すべてのリレーションシップ・タイプでターゲット・インスタンスが不要になります。このオプションを無効にすると、すべてのリレーションシップ・タイプで1つ以上のターゲット・インスタンスが必要になります。
主キーとして最初の一意識別子を使用して設定: エンティティを作成するときに、最初の一意識別子の属性をデフォルトでプライマリ一意識別子にするかどうかを制御します。
外部UID属性名の同期: 導出元属性の名前として保持: スーパータイプまたは参照される属性が、外部一意識別子のネーミングに使用される必要があるかどうかを制御します。 その他の名前を指定する場合は、このオプションを選択解除してください。
モデル: リレーショナル
リレーショナル・モデルに適用するオプションが含まれます。
外部キー列の削除方針: ユーザーがある表を削除しようとしたときに、その表を指す1つ以上の生成済外部キー列（他の表の列）が削除対象の表に含まれている場合、Data Modelerがどのような動作を行う必要があるかを指定します。指定する動作としては、外部キー列を削除する、外部キー列を削除しない、または外部キー列の削除について確認を求める、といった動作があります。
例として、第2章「チュートリアル: 小規模データベースのデータ・モデリング」のリレーショナル・モデルを使用すると、Books表を削除する場合、Transactions表にはBooks表の主キーを参照するbook_id外部キー列が含まれています。 このオプションの選択は、Books表を削除する場合に、Transactions.book_id列に対して何が行われるかを決定します。
デフォルトの外部キー削除ルール: 外部キー・リレーションシップに関与するデータが含まれる列を削除しようとしたときに何が行われるかを指定します。
アクションなし: 削除が許可されないことを示すエラー・メッセージが表示されます。削除はロールバックされます。
カスケード: 外部キー・リレーションシップに関与するデータが含まれるすべての列が削除されます。
NULLを設定: 表のすべての外部キー列がNULL値を受け入れることができる場合は、値をNULLに設定します。
モデル: 物理
物理モデルに適用するオプションが含まれます。 様々なオプションが、サポートされている各データベース・タイプに適用されます。
「ダイアグラム」ペインには、モデル・ダイアグラムの外観に影響を及ぼす一般的なオプションが含まれます。
一般: グリッドの表示: ダイアグラムのバックグラウンドにグリッドを表示するかどうかを制御します。 グリッドを表示させると、ダイアグラムでオブジェクトを垂直方向および水平方向に調整するのに役立ちます。
一般: ツリーとの同期: オブジェクト・ブラウザのモデルにおけるオブジェクトの選択を反映するように、アクティブなダイアグラムへのフォーカスを自動的に移動させるかどうかを制御します。
一般: ダイアログの色: ダイアグラムのバックグラウンドのカラー・スキームを選択するダイアログを表示します。
一般: 自動ルートを引く: リレーション、外部キー・リレーション、継承、フローおよびその他のリレーションシップを表す線を、自動的にダイアグラムに描くかどうかを制御します。 このオプションを選択解除すると、これらの線がどのように描かれるかをユーザーが決定します。たとえば、モデルをより明確にするために、手動でブレーク・ポイントを追加または移動することができます。 オート・ルートと線の描画の詳細は、1.2.2「コンテキスト・メニュー」の自動ルート・コマンドについての説明を参照してください。
プロセス・モデル: フロー名の表示: データ・フロー・ダイアグラムの各フロー線で、フロー名をボックスに表示するかどうかを制御します。
ダイアグラム: 論理モデル
論理モデルのダイアグラムに適用するオプションが含まれます。
表記法タイプ: 表記法タイプとして、Barker（烏の足とも呼ばれる）またはBachmanを指定します。
ソース/ターゲット名の表示: （「レコード構造のプロパティ」ダイアログ・ボックスの「カーディナリティ」ペインで）ソース値の名前およびターゲット値の名前を表示するかどうかを制御します。 表示する場合は、テキストを書式設定し、ボックスを移動できます。
ボックス内のボックスにエンティティ継承を表示: スーパータイプのボックス内にあるボックスに、サブタイプを表示します。
ドメインの表示: ドメインに基づく属性のデータ型として何を表示するかを指定します。「ドメイン名」はドメイン名を表示します。「使用されたドメイン・タイプ」はドメイン定義に使用された論理型を表示します。
ダイアグラム: リレーショナル・モデル
リレーショナル・モデルのダイアグラムに適用するオプションが含まれます。
外部キー矢印の方向: 外部キー・リレーションシップの矢印で、その先端が主キーまたは外部キーのいずれを指すかを制御します。
外部キー名の表示: 外部キー名を含むテキスト・ボックスを、外部キー・リレーションシップの矢印に表示するかどうかを制御します。
多次元モデルで様々な分類タイプを表示するための色を指定します。
ダイアグラム: フォーマット
オブジェクトのデフォルトのフォントと色、および線のデフォルトの幅と色についてオプションを指定します。
「ネーミング標準」ペインを使用すると、ネーミングの標準化を実装できます。論理およびリレーショナル・モデル・オブジェクト用およびドメイン用のネーミング標準を表示、追加および変更できます。 「設計ルール」を適用するときに、これらの標準が確認されます。標準違反があればすべて、エラーまたは警告として報告されます。
ネーミングの標準化を「名前略語」ダイアログ・ボックスの使用と混同しないでください。このダイアログ・ボックスでは、スペルおよび略語に一貫性を確保して、名前の変更が即座に行われます。また、リレーショナル・モデル名の文字列のみが対象になります。
論理、リレーショナル、ドメイン
論理モデルのエンティティと属性、リレーショナル・モデルの表と列、およびドメインに対して、オブジェクト名の構成要素（主要語、類語、修飾子および限定子）を追加または再配置したり、それらをオプションまたは必須にすることができます。 これらの構成要素の許容値は、「用語集」ペインで指定する用語集ファイルに明記されます。
タイトルの大文字/小文字（「セパレータ」オプション）: 各単語の先頭が大文字になり、空白が含まれないことを意味します。例: GovernmentAccounts。 （タイトルの大文字/小文字は、CamelCaseと呼ばれる場合があります。）
省略語のみ: このオプションを有効にすると、省略されていない単語はリレーショナル・モデル・オブジェクト名で使用できません（つまり、使用できるのは、省略された単語のみです）。
他の用語の説明については、3.39「用語集エディタ」を参照してください。 ネーミング標準の詳細は、『United States Coast Guard Data Naming Element Standards Guidebook』を参照してください。
リレーショナル - その他
リレーショナル・モデルの様々な制約について、その書式文字列を編集したり、変数文字列要素を追加することができます。
例: 現在指定されている書式のサンプル名を参照するには、目的の制約タイプ（外部キーなど）を選択します。
用語集
ネーミングの標準化に使用する1つ以上の用語集ファイルを追加できます。 （用語集についての詳細な説明は、3.39「用語集エディタ」を参照してください。）
「DDL」ペインには、生成されるコードのデータ定義言語（DDL）文に対する一般的なオプションが含まれます。
DB2およびUDBの文終了文字: IBM DB2およびUDBデータベース用のDDLの終了文字です。
OracleおよびUDBの型置換トリガーの作成: OracleおよびIBM UDB物理モデルで、型置換用にトリガーを作成するかどうかを制御します。
外部キーarc制約用トリガーの作成: 生成されたDDLコードに、外部キーarc制約を実装するトリガーを作成するかどうかを制御します。
移動不可能な外部キー用トリガーの作成: 移動不可能な外部キー・リレーションシップ用にトリガーを作成するかどうかを制御します。 （外部キー・リレーションシップが移動可能かどうかは、「外部キーのプロパティ」ダイアログ・ボックスの「移動可能(更新可能)」オプションで制御されます。）
Oracle Varchar2およびChar型の文字/バイト単位の表示: OracleのCHAR型またはVARCHAR2型の属性について、その属性の長さに関連付けられた単位（文字またはバイト）が属性に関する列として、リレーショナル・モデル・ダイアグラムおよび生成されたCREATE TABLE文に含まれるかどうかを制御します。
比較機能に「データ型の種類」プロパティを使用: 異なる種類の型が同じネイティブ・データ型を生成しないように（たとえば、ドメインおよび論理型がNumber(7,2)にならないように）、データ型の種類（ドメイン、論理型、固有型など）を考慮する必要があるかどうかを制御します。
DDL: DDL/移行
DDL文の生成時に置換する1組以上の文字列置換を指定できます。 それぞれのペアでは、古い文字列と、その古い文字列を置換する新しい文字列を指定します。
選択済: 指定された置換が有効か無効かを制御します。
大/小文字の区別: DDLの古い文字列の大/小文字が、古い文字列として指定した大/小文字と正確に一致する場合にのみ、置換を実行するかどうかを制御します。
「サード・パーティJDBCドライバ」ペインでは、サード・パーティ（Oracle以外）のデータベースへの接続に使用されるドライバを指定します。 SQL Developer Data Modelerでは、サード・パーティ・データベースからメタデータを獲得する場合など、一部の操作でJDBCドライバを使用する必要があります。
Oracleでは、Oracle以外のドライバを提供していません。 （Javaに含まれている）ODBC/JDBC以外のドライバを使用する必要があるOracle以外のデータベースにアクセスするには、必要なドライバのファイルをダウンロードしてから、このペインを使用して追加する必要があります。 ドライバをダウンロードする場合は、サード・パーティのサイトの適切なリンクを使用します。 次に例を示します。
Microsoft SQL Server 2000の場合: http://www.microsoft.com/downloads/details.aspx?familyid=07287B11-0502-461A-B138-2AA54BFDC03A&displaylang=en（msbase.jar、mssqlserver.jarおよびmsutil.jarの3つの.jarファイルをすべて確実にインストールしてください。）
Microsoft SQL Server 2005の場合: http://www.microsoft.com/downloads/details.aspx?familyid=C47053EB-3B64-4794-950D-81E1EC91C1BA&displaylang=en
IBM DB2/LUW（IBM Data Server Driver for JDBC and SQLJ）の場合: http://www-01.ibm.com/software/data/db2/express/additional-downloads.html
追加するドライバごとに、「追加」（+）アイコンをクリックして、ドライバのパスを選択します。 サード・パーティ・データベースおよびその必須ドライバには、次のものがあります。
Microsoft SQL Server 2000: msbase.jar、mssqlserver.jarおよびmsutil.jar
Microsoft SQL Server 2005: sqljdbc.jar
IBM DB2/UDB: db2jcc.jar
作業中の設計（または設計の一部）を格納する場合は、保存またはエクスポートを実行できます。
設計を保存すると、その設計のすべての要素（論理モデル、リレーショナル・モデル、物理モデル、プロセス・モデルおよびビジネス情報）を保存できます。 XMLファイルおよびディレクトリ構造（1.3.1「データベース設計」を参照）は、新しい設計では作成され、既存の設計では更新されます。設計は、SQL Developer Data Modeler形式で格納されています。
設計を保存するには、「ファイル」→「保存」をクリックします。 事前に設計が保存されていない場合は、場所およびXMLファイル名を指定します。 別のファイルおよびディレクトリ構造で設計を保存するには、「ファイル」→「別名保存」をクリックします。
設計をエクスポートすると、設計の一部（論理モデル、物理モデル以外のリレーショナル・モデル、およびデータ型モデル）をファイルに保存できます。 エクスポートは、Oracle以外およびOracleの様々な形式で行うことができます。 このように、エクスポートすることで、出力形式に柔軟性がもたらされますが、SQL Developer Data Modelerの出力のみが必要な場合は、保存することで、より多くの設計オブジェクトを保存できます。
設計をエクスポートするには、「ファイル」→「エクスポート」→「出力形式」をクリックします。
保存済の設計を使用するには、「ファイル」→「開く」をクリックして開きます。 設計を開くと、保存された設計のすべてのモデルおよびオブジェクトを作業で使用できるようになります。 保存された物理モデルは、最初はオブジェクト・ブラウザには表示されません。ただし、目的のリレーショナル・モデルで物理モデルを右クリックして「開く」を選択し、データベース・タイプ（Oracle 11gなど）を指定すると、物理モデルを表示できます。
SQL Developer Data Modelerで保存された設計、または別のデータ・モデリング・ツールでエクスポートまたは保存された設計を使用する場合は、「ファイル」→「インポート」をクリックし、インポートする設計のタイプを指定すると、インポートできます。 通常、ファイルを指定してから、インポートの対象を制御できるウィザードを使用します。
開いたり、インポートするテキスト・ファイルは、オペレーティング・システムのロケール設定でサポートされている形式でエンコードされている必要があります。 文字のエンコーディングおよびロケールの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。
この項の残りの部分では、特定のタイプのファイルおよび他のソースからのインポートについて説明します。
DDLファイルをインポートすると、既存のデータベース実装に基づいたリレーショナル・モデルを作成できます。 元になるDDLファイルとして、サポートされているすべてのデータベース・タイプおよびバージョンのものが可能です。 インポートされるファイルには、通常、.ddlまたは.sqlの拡張子があります。
インポート・プロセスでは、インポートされるDDLファイルの名前で新しいリレーショナル・モデルが作成され、ソース・サイトを反映した物理モデルが開きます。
キューブ・ビュー・メタデータをインポートすると、指定されたXMLファイルに反映されるように、既存の実装に基づいた多次元モデル作成できます。
Microsoft XMLAからインポートすると、Microsoft XMLAファイル形式で格納される多次元モデルを作成できます。
ERwinファイルをインポートすると、ERwinモデリング・ツールからモデルを取得できます。 インポートするモデルの定義が含まれるXMLファイルを指定します。
データ・ディクショナリからのインポートを行うと、既存のデータベース実装に基づいたリレーショナル・モデルおよび物理モデルを作成できます。 元になるデータ・ディクショナリとして、サポートされているすべてのデータベース・タイプおよびバージョンのものが可能です。
データ・ディクショナリからインポートするウィザードでは、既存のデータベース接続を選択するか、新しいデータベース接続を作成（追加）する必要があります。その後で、指示に従って、スキーマまたはデータベースを選択し、さらにインポートするオブジェクトを選択します。
データ・ディクショナリからインポートした後、必要に応じてリレーショナル・モデルおよび物理モデルを編集できます。また、リレーショナル・モデルから論理モデルをリバース・エンジニアすることができます。
Oracle Designerモデルをインポートすると、既存のOracle Designerモデルに基づいたリレーショナル・モデルおよび物理モデルを作成できます。
Oracle Designerモデルをインポートするウィザードでは、既存のデータベース接続を選択するか、新しいデータベース接続を作成（追加）する必要があります。その後で、指示に従って、作業領域、アプリケーション・システムを選択し、さらにインポートするオブジェクトを選択します。 （Oracle Designerデータフロー・ダイアグラムはインポートできないことに注意してください。）
Oracle Designerモデルをインポートした後、必要に応じてリレーショナル・モデルおよび物理モデルを編集できます。また、リレーショナル・モデルから論理モデルをリバース・エンジニアすることができます。
SQL Developer Data Modeler設計をインポートすると、以前にSQL Developer Data Modelerからエクスポートした設計から、論理モデル、リレーショナル・モデルおよびデータ型モデルを取得できます。
ドメインをインポートすると、既存のドメイン定義を変更および拡張できます。 「ドメインのインポート」ダイアログ・ボックスで、インポートするドメインを選択したり、インポートしないドメインを選択解除（クリア）します。
Data Modeler設計の情報をデータベース・スキーマ（レポート・リポジトリと呼ばれる）にエクスポートしてから、SQL Developerのレポート機能を使用して、そのData Modeler設計についてのレポートを表示できます。
レポート・リポジトリは、Data Modeler設計についてのメタデータおよびデータを格納するためのスキーマ・オブジェクトのコレクションです。 Data Modelerのレポート・リポジトリ用に個別のデータベース・ユーザーを作成し、そのスキーマをレポート・リポジトリに対してのみ使用することをお薦めします。 たとえば、DM_REPORT_REPOSというユーザーを作成し、そのユーザーに少なくともCONNECT権限およびRESOURCE権限を付与します。 （別の目的で使用されている既存のスキーマにレポート・リポジトリを作成することもできますが、それを把握し続けることが困難になる場合があります。）
設計についての情報をレポート・リポジトリにエクスポートするには、「ファイル」→「エクスポート」→「レポート・スキーマへ」をクリックします。
SQL Developerでレポートを表示するには、次の手順を実行する必要があります。
SQL Developerで、レポート・ナビゲータに「データ・モデラー・レポート」という子ノードがすでに含まれているかどうかを確認します。 そのノードが含まれている場合は、次の手順に進みます。そのノードが含まれていない場合は、次の手順を実行して、データ・モデラー・レポートの拡張機能をインストールします。
「ヘルプ」→「更新のチェック」をクリックします。 「更新のチェック」ウィザードで、「ローカル・ファイルからインストール」を指定し、ローカル・ファイルを指定します。このローカル・ファイルはData Modelerをインストールした場所にあります。（Windowsシステムの場合）datamodeler\reports\oracle.sqldeveloper.datamodeler_reports.nn.nn.zipまたは（Linuxシステムの場合）datamodeler/reports/oracle.sqldeveloper.datamodeler_reports.nn.nn.zip。nn.nnは、ビルド番号です。
SQL Developerで「レポート」ナビゲータを開き、「データ・モデラー・レポート」ノードを展開します。必要に応じて、そのノードの下のノードをさらに展開します。
表示するレポートごとに、次の手順を実行します。
レポート名に対応するノードをダブルクリックします。
レポート・リポジトリに使用したデータベース接続を選択します。
「バインド変数」ダイアログ・ボックスに情報を入力して、「OK」をクリックします。 バインド変数の場合、そのデフォルト値では最も一般的なケースが示されます。つまり、最新バージョンの設計に使用可能なすべての情報が表示されます。
バインド変数を使用すると、出力を制限できます。 ほとんどのバインド変数のデフォルト値はNULLで、これは、追加の制限を設定しないことを意味します。 バインド変数を指定するには、変数名を選択して、「値」フィールドにエントリを入力します。 入力するバインド変数値は、大/小文字が区別されます。 バインド変数値には、特殊文字として、任意の文字列を意味する%（パーセント記号）および任意の文字を意味する_（アンダースコア）を含めることができます。
「設計内容」レポートは、設計内容（設計内のオブジェクト）に関する情報をリストします。
データ型モデル: データ型モデルに関連するレポートが含まれます。
論理モデル: 論理モデルに関連するレポートが含まれます。
リレーショナル・モデル: リレーショナル・モデルに関連するレポートが含まれます。
「設計ルール」レポートは、論理モデルおよびリレーショナル・モデルに適用される場合の設計ルールに関する情報をリストします。 （「設計ルール」ダイアログ・ボックスに関する情報を参照してください。）
論理モデル: 論理モデルに関連するレポートが含まれます。
リレーショナル・モデル: リレーショナル・モデルに関連するレポートが含まれます。
SQL Developer Data Modelerビューアは、SQL Developer Data Modelerの無償の読取り専用バージョンです。このビューアでは、データベース設計をオープン、インポートおよび表示し、元の設計とは別に保存することができます。 ただし、オブジェクトを作成、変更または削除することはできません。
SQL Developer Data Modelerおよび無償のビューアの両方とも、そのオンライン・ヘルプは同じです。このため、ビューアではサポートされていない機能についての説明もヘルプに含まれています。
データ・モデリングの詳細（高度な資料など）は、次の情報を参照してください。
ホワイト・ペーパー、ビューレット（画面デモンストレーション）、Oracle by Example（OBE）チュートリアルおよびその他の資料へのリンクが含まれるSQL Developerホーム・ページ（OTN）: http://www.oracle.com/technology/products/database/sql_developer/
Object Management Group（OMG）のサイト（http://www.omg.org/）（特に、MetaObject Facility（MOF）およびCommon Warehouse Metamodel（CMW）仕様）
『United States Coast Guard Data Naming Element Standards Guidebook』（http://www.uscg.mil/directives/ci/5000-5999/CI_5230_42A.pdf）（特にネーミング標準に関連する概念および推奨事項）
