Data Modelerの概要および使用方法

Data Modelerチュートリアル: 小規模データベースのモデリング

1.2.1 Data Modelerのメニュー

ここでは、Data Modelerで特に重要なメニュー項目について説明します。

「ファイル」メニュー

開く: 保存またはエクスポートされているData Modelerの設計を開きます。詳細は、「設計の保存、オープン、エクスポートおよびインポート」を参照してください。

閉じる: Data Modelerを終了せずに、現在の設計を閉じます。

すべて閉じる: Data Modelerを終了せずに、開いているすべての設計を閉じます。

インポート: 様々なソースからモデルをインポートできます。詳細は、「設計の保存、オープン、エクスポートおよびインポート」を参照してください。

エクスポート: 様々なデータ・モデル・ツールにインポートできるファイルにモデルをエクスポートできます。詳細は、「設計の保存、オープン、エクスポートおよびインポート」を参照してください。

レポート: データ・モデラー・レポートを生成します。

ページ設定: ダイアログ・ボックスが表示され、次のダイアグラム印刷オプションを指定できます。メディアの「サイズ」(「レター」、「リーガル」、その他の既定サイズ)、「ソース」(「自動選択」または指定した給紙)、「向き」(「縦」、「横」、逆方向縦、逆方向横)、「余白」(「左」、「右」、「上」、「下」)。

印刷: 現在選択されているダイアグラムを印刷します。

ダイアグラムの印刷: 現在選択されているダイアグラムを保存します。その形式は、指定したファイル拡張子に関連付けられたタイプのイメージ・ファイル(.pngまたは.jpg)、PDFファイル、scalable vector graphics(.svg)ファイルまたはHTML/SVG (.html)ファイルです。

最新の設計: 最近作業したData Modeler設計を開くことができます。

終了: 開いているすべての設計を閉じ、Data Modelerを終了します。

「編集」メニュー

オブジェクトの切取り、コピー、貼付け、削除、整列、検索に関連した標準的な編集メニュー・オプションが含まれます。

「表示」メニュー

Data Modelerインタフェースに表示される内容を指定するオプションが含まれます。

ステータス・バーを表示: 「Data Modeler」ウィンドウの下部にステータス・バーを表示するかどうかを設定します。

ブラウザ: データ・モデリング・オブジェクトを階層ツリー形式で表示する、オブジェクト・ブラウザを表示します。

ナビゲータ: 現在選択されているビューをグラフィカルなサムネイル表現で表示します。ナビゲータは、デフォルトではウィンドウの右側に表示されます。

ログ: 「メッセージ」-「ログ」ペインに、現在の起動中におけるData Modelerのアクションの記録を表示します。

外部ログ: 現在の完全なリリース番号について、Data Modelerのすべての起動の記録が示される別ウィンドウを表示します。

外部ログ: Data Modelerウィンドウ内のペインではなく外部ビューアで、Data Modelerのアクションの記録を表示します。

ファイル: ローカル・ファイル・システムをナビゲートするための「ファイル」ペインを表示します。

論理ダイアグラム表記法: 論理モデルの表示にBarkerまたはBachmanのどちらの表記法を使用するのかを制御します。

詳細の表示: 表示について、その詳細レベルを制御します。論理モデル(エンティティおよび属性)とリレーショナル・モデル(表および列)では、「コメント」を含めると、RDBMSテキストのすべての「コメント」がダイアグラム表示されます。

DDLプレビュー(リレーショナル・ダイアグラム・オブジェクト): オブジェクトを作成するために生成されるDDL文を表示します。(「DDLプレビュー」ウィンドウが表示されている場合は、リレーショナル・ダイアグラムで他のオブジェクトをクリックすると、そのオブジェクトを作成するために生成されるDDL文が表示されます。)

DDLファイル・エディタ: 選択した物理モデルに対してDDL文を生成します。「DDLファイル・エディタ」ダイアログ・ボックスが表示されます。(このコマンドは、「DDLの生成」アイコンをクリックするか、「ファイル」→「エクスポート」→「DDLファイル」の順にクリックすることと同等です。)

ズーム・イン(および対応するアイコン): 現在選択されているダイアグラムを詳細に表示します。表示されるオブジェクトは少なくなります。

ズーム・アウト(および対応するアイコン): 現在選択されているダイアグラムを概略的に表示します。表示されるオブジェクトは多くなります。

画面に合わせる(および対応するアイコン): 関連するすべてのオブジェクトを現在選択されているダイアグラムのウィンドウに合わせ、必要な場合は輪郭およびテキスト・ラベルの大きさを調節します。

デフォルト・サイズ (および対応するアイコン): 現在選択されているダイアグラムの形とテキスト・ラベルをデフォルト・サイズに調整します。

検索(サーチ): 現在選択されているダイアグラム内のオブジェクトを検索するためのダイアログ・ボックスを表示します。大きく複雑なダイアグラムでオブジェクトを検索するのに役立ちます。(「オブジェクトの検索(検索)」を参照。)

ノート:

開いているすべてのモデルに対してグローバル検索を実行するには、ウィンドウの右上領域にある検索(双眼鏡アイコン)ボックスを使用します。

リフレッシュ: 「Data Modeler」ウィンドウの内容を更新して現在の情報を反映します。

全画面: Data Modelerウィンドウの全画面表示と、全画面ではない現在または直前の表示とを切り替えます。

「チーム」メニュー

Subversionバージョン管理およびソース制御システムのサポートに関連するオプションをが含まれます。詳細は、「バージョニングの使用」を参照してください。

バージョン: バージョン・ナビゲータと「保留中の変更」ウィンドウを表示できます。

「チーム」メニューの他のコマンドは、Data Modelerで使用できるバージョン管理およびソース制御システムによって異なります。

「ツール」メニュー

Data Modelerツールを起動し、特定のオプション(ユーザー・プリファレンス)を設定できます。

ドメイン管理: ドメインを表示、変更、追加および消去できます。「ドメイン管理」ダイアログ・ボックスが表示されます。

型の管理: 論理型を表示、変更、追加および消去できます。「型の管理」ダイアログ・ボックスが表示されます。

RDBMSサイト管理: RDBMSサイト(データベースのサポートされるタイプと関連付けられる名前)を表示して、物理モデルの作成に役立つ独自の名前(別名)を追加します。「RDBMSサイト・エディタ」ダイアログ・ボックスを表示します。

マスク・テンプレート管理: 1つまたは複数のテンプレートを作成し、それをリレーショナル・モデルの表の適切な列に関連付けることができます。「マスク・テンプレート管理」ダイアログ・ボックスが表示されます。

表からビュー・ウィザード: 選択されたリレーショナル・モデルに表に基づいたビューを作成できます。「表からビュー」ウィザードを表示します。

ビューから表ウィザード: 選択したリレーショナル・モデルでビューに基づいて表を作成します。ビューから表ウィザードを表示します。

名前略語: (たとえば、標準的な略語やスペルを確実に使用させるために)リレーショナル・モデル・オブジェクトの名前で変更される文字列が示された.csvファイルを指定します。「名前略語」ダイアログ・ボックスが表示されます。

用語集エディタ: 新しい用語集ファイルの作成(存在しないファイル名を指定した場合)および既存の用語集ファイルの編集が可能です。ファイルを選択するためのダイアログ・ボックスが表示された後に、「用語集エディタ」ダイアログ・ボックスが表示されます。

オブジェクト名管理: オブジェクトのプロパティのダイアログ・ボックスで、指定したオブジェクトの名前を固定(変更不能)または変更可能にできます。「オブジェクト名管理」ダイアログ・ボックスが表示されます。

設計ルール: 現在の設計がData Modelerの設計ルールに違反していないかを確認できます。「設計ルール」ダイアログ・ボックスが表示されます。

エンジニアリング・ステータス: 「エンジニアリング」ダイアログ・ボックスが表示されます。

モデルの比較/マージ: 設計ファイルを開き、そのファイルのリレーショナル・モデルと現在の設計のリレーショナル・モデルを比較し、一方のモデルのオブジェクトを他方のモデルにマージすることができます。設計ファイルを選択すると、「リレーショナル・モデル」ダイアログ・ボックスが表示されます。

一般オプション: Data Modelerの動作をカスタマイズできます。「Data Modeler」ダイアログ・ボックスを表示します。

「ヘルプ」メニュー

Data Modelerに関するヘルプを表示します。「ヘルプ・センター」ウィンドウでは次のアイコンが各タブに含まれています。

常に手前に表示: 「データ・モデラー」ウィンドウの手前に「ヘルプ・センター」ウィンドウを表示するかどうかを設定します。
ナビゲータ: 「コンテンツ」ナビゲータまたは「お気に入り」ナビゲータを選択します。
印刷: トピックを印刷します。
フォント・サイズの変更: 現在のヘルプ・トピックの表示のフォント・サイズを拡大または縮小できます。
お気に入りに追加: トピックをお気に入りナビゲータのリストに追加します。
検索: 現在のヘルプ・トピックの文字列を検索できます。

検索: 「検索」(双眼鏡アイコン)ボックスが強調表示された、「ヘルプ・センター」ウィンドウが表示されます。オンライン・ヘルプで検索する1つ以上の文字列を入力できます。

目次: 「コンテンツ」タブが選択状態になっている「ヘルプ・センター」ウィンドウが表示されます。

開始ページ: Data Modelerについて理解するためのオプションのリンクを含むページを表示します。このオプションには、モデルとスクリプトのサンプルがあるページへのリンクが含まれています。

リリース・ノート: 要件およびいくつかの使用上の注意を含む、Data Modelerの今回のリリースに関する重要な情報を表示します。

情報: バージョン関連情報およびData Modeler、そのプロパティおよびインストール済拡張機能に関するその他の情報を表示します。

1.2.2 コンテキスト・メニュー

オブジェクト・ブラウザおよびダイアグラムのコンテキスト・メニュー(右クリック・メニュー)には、選択されたオブジェクトに関連するコマンドが含まれます。

オブジェクト・ブラウザで論理モデルまたはリレーショナル・モデルを右クリックした場合、コンテキスト・メニューには一般的に次の項目が含まれます。

SubViewオブジェクト名接頭辞の変更: 選択したオブジェクト・タイプに対して指定した現在の接頭辞が置き換えられる、新しい接頭辞を指定します。「SubViewオブジェクト名接頭辞の変更」ダイアログ・ボックスが表示されます。
カスタム変換スクリプトの適用: 「カスタム変換スクリプト」ダイアログ・ボックスを表示し、適用するスクリプトを選択できます。(カスタム変換スクリプトの詳細は、「変換」を参照してください。)
外部キーの検出: リレーショナル・モデルの表間の外部キー・リレーションシップを検出して、外部キーを作成します。(「検出された外部キーの作成」を参照してください。)
リレーショナル・モデルに対するエンジニアリング(論理モデルを選択): フォワード・エンジニアリングを実行して、論理モデルからリレーショナル・モデルを生成または更新します。また、サブビューを作成するかどうかを指定することもできます。
論理モデルに対するエンジニアリング(リレーショナル・モデルを選択): リバース・エンジニアリングを実行します。選択されたリレーショナル・モデルから論理モデルを更新します。

ダイアグラム内で、表示されているオブジェクトの外で右クリックした場合、コンテキスト・メニューには一般的に次の項目が含まれます。

検出された外部キーの作成(リレーショナル・モデル): リレーショナル・モデルで検出された非表示の外部キー・リレーションシップを表示します。(「検出された外部キーの作成」を参照してください。)
検出された外部キーの削除(リレーショナル・モデル): 検出された外部キーをリレーショナル・モデル図から削除します。
SubViewの作成: Subviewを作成します。(「論理ダイアグラムおよびサブビュー」と「リレーショナル・ダイアグラムおよびサブビュー」も参照してください)
表示の作成: ビューまたはサブビューの別々の表示ペインを作成します。表示によって同じオブジェクトのセットを異なる方法で表すことができます。たとえば、表示を作成して、その表示を選択してから「詳細の表示」、「表示」(「グリッド」、「ページのグリッド」、「ラベル」、「凡例」)および「ダイアグラムの色」のコンテキスト・メニューの変更を試します。表示は、関連するメイン・ダイアグラムまたはサブビューと同じウィンドウですが、そのウィンドウの下部に表示のタブがあります。表示を削除するには、表示を右クリックして、「表示の削除」を選択します。
自動ルート: 「行自動ルート」(「Data Modeler」の「ダイアグラム」を参照)の設定を切り替えます。端または角(頂点)をクリック・アンド・ドラッグして移動させたり、[Ctrl]キーを押しながら端をクリック・アンド・ドラッグして新しい角を作成するなど、ダイアグラムで線を調節する前に「自動ルート」を無効にする必要があります。ノート: 調節後に「自動ルート」を有効にすると、手動での調節は失われます。
直線にする(「自動ルート」が無効の場合にのみ使用可能): すべての角を削除し、線には始点と終点のみをつなぐようにします。
自動レイアウト(リレーショナルおよびデータ・フロー・ダイアグラム): ダイアグラム内のオブジェクトを、より意味があり体裁が良いと考えられるレイアウトに再配置します。再配置に不満がある場合は、「編集」→「自動レイアウトを元に戻す」をクリックすると、以前のレイアウトに戻すことができます。
詳細の表示: オブジェクトについての使用可能なすべての詳細か、または選択した詳細のみを表示できます。
表示: 「グリッド」では、バックグラウンドにグリッドが表示され、これはダイアグラムでオブジェクトを垂直方向および水平方向に調節するのに役立ちます。ページのグリッドでは、ページ・マージンが印刷済PDF出力のどこにくるかが表示されます。「ラベル」では、リレーションシップの矢印に外部キーの名前が表示され、データ・フロー・ダイアグラムのフロー線にフロー名が表示されます。「凡例」には、ダイアグラム名、作成者、作成日およびその他の情報が含まれる凡例ボックス(ドラッグして移動可能)が表示されます。
表示可能なようにオブジェクトをサイズ変更: 表示領域ですべて表示できるように図のオブジェクトをサイズ変更します。
ダイアグラムの色: ダイアグラムのバックグラウンドのカラー・スキームを選択するダイアログ・ボックスを表示します。
プロパティ: モデルのプロパティを表示および編集するダイアログ・ボックスを表示します。

ダイアグラム内で、2つのオブジェクトを接続する線を右クリックした場合、コンテキスト・メニューには一般的に次の項目が含まれます。

削除: 線を削除し、その線で表されたリレーションシップを削除します。
直線にする(「自動ルート」が無効の場合にのみ使用可能): すべての角を削除し、線には始点と終点のみをつなぐようにします。
フォーマット: 線の色と太さを変更できます。
角の追加(「自動ルート」が無効の場合にのみ使用可能): 選択した点に角(頂点)を追加します。
角の削除(自動ルートが無効の場合にのみ使用可能): 選択した角(頂点)を削除します。
プロパティ: 線で表されたリレーションシップのプロパティを表示および編集するダイアログ・ボックスを表示します。

論理ダイアグラムおよびリレーショナル・ダイアグラム内で1つ以上のエンティティまたは表を選択し、その中の1つを右クリックした場合、コンテキスト・メニューには少なくとも次の項目が含まれます。

シノニムの作成: シノニム・オブジェクトを表示領域内に作成します。
選択した項目からサブビューを作成: 選択したオブジェクトを含むサブビューを作成します。(「論理ダイアグラムおよびサブビュー」と「リレーショナル・ダイアグラムおよびサブビュー」も参照してください)
同胞の選択: 選択したオブジェクトに関連するオブジェクトを選択します。選択の方向(「すべて」(上位および下位レベルのゾーン)、「親」または「子」)を指定できます。選択項目からサブビューを作成する前に、同胞を選択することができます。
DDLプレビュー(リレーショナル・ダイアグラム): オブジェクトを作成するために生成されるDDL文を表示します。(「DDLプレビュー」ウィンドウが表示されている場合は、リレーショナル・ダイアグラムで他のオブジェクトをクリックすると、そのオブジェクトを作成するために生成されるDDL文が表示されます。)
フォーマット: 選択したオブジェクトの色およびフォントを指定できます。
要素の表示/非表示: 指定した要素を非表示にできます。
最背面へ移動: 選択したオブジェクトを、表示しているダイアグラムの背面に移動します。この結果、オブジェクトは部分的または完全に他のオブジェクトによって覆われてしまう場合があります。
選択済の表を検証: マテリアライズド・ビュー問合せ表としてマークされた選択済の表に対するSQL問合せを検証します。「表のプロパティ」ダイアログの「一般」タブに「マテリアライズド問合せ表」プロパティが表示されます。Oracleデータベースの場合、これは、その表がマテリアライズド・ビューとして実装されているかどうかを示しています。
暗黙外部キー:リレーショナル・モデルの表またはビュー間に暗黙外部キー関係を作成できます。「暗黙外部キー」ダイアログを参照してください。
プロパティ: オブジェクトのプロパティを表示および編集するダイアログ・ボックスを表示します。

データ・フロー・ダイアグラム内で1つ以上のオブジェクトを選択し、その中の1つを右クリックした場合、コンテキスト・メニューには少なくとも次の項目が含まれます。

削除: 選択したオブジェクトを削除します。
フォーマット: 選択したオブジェクトの色およびフォントを指定できます。
最背面へ移動(線で表されていないオブジェクトが対象): 選択したオブジェクトを、表示しているダイアグラムの背面に移動します。この結果、オブジェクトは部分的または完全に他のオブジェクトによって覆われてしまう場合があります。
プロパティ: オブジェクトのプロパティを表示および編集するダイアログ・ボックスを表示します。

1.3 Data Modelerの使用

Data Modelerを使用して、様々な種類のモデルの様々な階層レベルのオブジェクトを作成、編集および削除することができます。多くのオブジェクトのプロパティは類似しており、操作の実行方法は基本的に共通していて直感的です。オブジェクトに対して操作(作成、編集、削除)を実行する場合は、オブジェクト・ブラウザまたはツールバーのコンテキスト・メニューか、またはダイアグラムを選択した後の「オブジェクト」メニューを使用できることがあります。

オブジェクト・ブラウザを使用してオブジェクトに対する操作の実行するには、階層内で適切なノードを右クリックし(またはノードをクリックして、[Shift]キーを押しながら[F10]キーを押し)、希望する操作のコマンドを選択します。

たとえば、エンティティを編集するには、「論理」表示を展開します。これによって、すべてのエンティティが表示されます。編集するエンティティの名前を右クリックして「プロパティ」を選択します。
ダイアグラムを使用して操作を実行するには、ダイアグラムのタブを選択し、ツールバー・アイコンを選択します。

たとえば、エンティティを作成するには、「論理」タブを選択して、「新規エンティティ」ツールバー・アイコンをクリックし、「エンティティのプロパティ」ボックスでエンティティを定義します。エンティティを編集するには、ダイアグラムでボックスをダブルクリックするか、またはボックスを右クリックして、「プロパティ」を選択します。

ダイアグラム内のコンテキスト・メニュー(右クリック・メニュー)には、ダイアグラムに一般的に関連するコマンドか、または現在選択されているオブジェクトに関連するコマンドが含まれます。

特定の種類のオブジェクトの概要および使用方法の情報については、次のトピックを参照してください。

1.3.1 データベース設計

Data Modelerは、1つのオープン・データベース設計ともに動作し、これには、1つの論理モデル、論理モデルに基づく1つ以上のリレーショナル・モデル(オプション)および各リレーショナル・モデルに基づく1つ以上の物理モデル(オプション)が含まれます。また、データベース設計には、データ型モデルとビジネス情報を含めることもできます。別のデータベース設計で作業を行うには、現在の設計を閉じてから(「ファイル」→「閉じる」をクリック)、他のデータベース設計のオブジェクトを作成またはインポートします。

データベース設計を保存すると、構造情報が、指定したフォルダまたはディレクトリにXMLファイル(拡張子.dmd)で格納され、必要に応じて、その下にサブフォルダまたはサブディレクトリが作成されます。.dmdファイルには、これらのサブフォルダまたはサブディレクトリにある情報へのポインタが含まれます。たとえば、my_db_designという非常に基本的な設計の場合は、作成したフォルダまたはディレクトリを起点に次のような階層が作成されます。

my_db_design.dmd
my_db_design
   businessinfo
   datatypes
      subviews
   logical
      entity
      subviews
   mapping
   pm
   rdbms
   rel
      1
         subviews
         table

追加のサブフォルダまたはサブディレクトリが後で自動的に作成される場合があります。たとえば、プロセス・モデル内にデータ・フロー・ダイアグラムを作成すると、pmの下にdataflowsが作成されます。

関連項目

1.3.2 データ型モデル

Data Modelerは、その論理モデル内のスーパータイプおよびサブタイプをサポートするだけでなく、データ型モデルも提供します。これによって、CWM(Common Warehouse Metamodel)準拠になり、SQL99構造型のモデリングが可能になります。データ型モデルは、データ型として論理モデルおよびリレーショナル・モデル内で使用できます。

構造型は、スーパータイプおよびサブタイプの継承階層を構築できるユーザー定義の名前付きコンポジット型としてサポートされています。固有型およびコレクション(配列)型を定義して、構造型と、構造型の継承階層を作成および可視化することができます。

論理モデルおよびリレーショナル・モデルでは、両方ともデータ型モデルからの定義を使用して、属性および列のデータ型を指定したり、表(エンティティ)が特定の構造型であることを定義できます。

データ型モデルは、次のような1つ以上の方法で構築できます。

Data Modelerで手動で構築する
Oracle Designerリポジトリからインポートして構築する。「Oracle Designerモデルのインポート」を参照してください。

Data Modelerのデータ型モデルは、2種類のデータを結合します。

1つのデータ型ダイアグラム(さらに、オプションでサブビューおよび補助表示のセット。それぞれは適切なダイアグラム/サブビューに関連付けられます)
データ型オブジェクト定義

サブビューは、様々なサブジェクト領域を表すために作成される、データ型モデルの独立したダイアグラムとみなされます。

データ型モデルを使用すると、固有型、構造型、コレクション型および論理型のオブジェクト定義を作成および管理できます。

(論理型を除く)すべてのデータ型モデル・オブジェクトは、オブジェクト・ブラウザ・ツリーに表示されますが、データ型ダイアグラム上にグラフィカルに表示されるのは、構造型オブジェクトとその相互関係のみです。

1.3.2.1 データ型ダイアグラムおよびサビブュー

次の図に示すとおり、データ型ダイアグラムでは、構造データ型とそれらのリンクがグラフィカルに表現されています。

図dt_modediagram.gifの説明

構造型のボックスには、オブジェクトの名前、定義された属性およびメソッド(存在する場合)が含まれます。ダイアグラムのリンクは、構造データ型とともに様々な属性を表します。

複雑なデータ型モデルで作業を行う場合は、サブビューを作成し、それぞれのサブビューでそのモデルの中のあるセクションのみを表すことができます。1つのデータ型モデルに複数のデータ型サブビューを定義し、その複数のサブビューに1つの構造型を割り当てることができます。ただし、2つの構造型間のリンク(参照)が表示されるのは、全体のデータ型モデル上と、両方の型が割り当てられたサブビュー上のみです。

サブビュー内での変更の実行と、全体のデータ型モデル内での変更の実行に違いはありません。実行した変更は、全体モデルおよび関連サブビューに即座に反映されます。ただし、構造型は、データ型モデルから削除することなく、サブビューから削除できます。

1.3.2.2 固有型

ユーザー定義の固有型は、「型の管理」ダイアログ・ボックスで定義された既存の論理型から導出されたデータ型です。固有型は、その表現を既存の型(ソース型)と共有しますが、個別で互換性のない型とみなされます。

固有型オブジェクトにアクセスできるのは、それがデータ型フォルダの固有型サブフォルダにある場合のみです。

ユーザーは新しい固有型を作成したり、既存の固有型のプロパティを編集できます。

1.3.2.3 構造型

構造型は、属性およびメソッドを持つユーザー定義データ型です。これは、スーパータイプおよびサブタイプの継承階層の一部になることもできます。構造型は、基本データ型、固有型、別の構造型または構造型への参照をベースにして定義できますが、コレクション型として定義することもできます。

表またはエンティティは、構造型をベースにして定義できます。型置換を使用すると、表(エンティティ)が収容できるサブタイプのインスタンスを(ダイアグラム上でグラフィカルに)表現できます。

表の列またはエンティティの属性は、構造型、構造型への参照、コレクション型、固有型および基本データ型をベースに定義できます。型置換は構造型に基づく列に対して定義でき、範囲表は構造型への参照に基づく列に対して定義できます。

構造型には、一連のメソッド仕様も含まれます。メソッドを使用すると、構造型の動作の定義できます。ユーザー定義ファンクション(UDF)のように、メソッドはSQLを拡張するルーチンです。ただし、メソッドの場合、動作と特定の構造型との統合は単独で行われます。

拡張構造型サブフォルダには、属性の階層とそれぞれのメソッドとともに、すべての構造型オブジェクトが示されます。

Oracle Spatial and GraphのSDO_GEOMETRY型は、構造型として事前定義されています。また、ユーザーは新しい構造型を作成したり、既存の構造型のプロパティを編集できます。

1.3.2.4 コレクション型

コレクション型は、要素(基本型、固有型、構造型または別のコレクション)の配列またはコレクションを表現し、Oracle VARRAYおよびネストした表タイプにマップされます。

ユーザーは新しいコレクション型を作成したり、既存のコレクション型のプロパティを編集できます。

1.3.2.5 論理型

論理型は実際のデータ型ではなく、ネイティブ型またはドメインと関連付けられる名前です。事前に用意されている論理型には、Oracle Multimediaからのもの(ORDで始まる名前のもの)がいくつか含まれますが、ORDIMAGE_SIGNATUREは非推奨であるため、新しい定義には使用しないでください。

論理型を作成し、ネイティブな型とのマッピングを編集することができます(「型の管理」を参照)。また、ドメインを論理型に関連付けることができます(「ドメイン管理」を参照)。

関連項目

1.3.3 プロセス・モデル

プロセス・モデルは、情報構造システムの機能領域を表します。1つ以上のデータ・フロー・ダイアグラムでグラフィカルに表現されるプロセス・モデルは分析技術であり、入力がシステム(プロセスのグループ)を通って結果としての出力に至るフローをとらえるために使用されます。モデルは、システム(既存のシステムや提案されたシステム)を通る情報のフローを表します。

データ・フロー・ダイアグラミングに必要なすべての要素が、Data Modelerプロセス・モデルでサポートされています。この要素には、プリミティブ・プロセス、分解レベルに制限がないコンポジット・プロセス、再使用可能な変換タスク、トリガー・イベント、情報ストア、外部エージェント、外部データ要素を説明するレコード構造、データ要素のソースとターゲットのマッピング、およびプリミティブ・プロセスとデータ要素の間のCRUD(作成、読取り、更新、削除)の依存性があります。

プロセス・モデルにおける概念で重要なものを次に示します。

プロセスは、ある特定の理由で実行されるアクティビティまたは機能です。各プロセスが実行するアクティビティは、最終的に1つのみである必要があります。

プリミティブ・プロセスはスタンドアロン・プロセスです。

コンポジット・プロセスは複数の外部プロセスで構成されます。データ・フロー・モデルにより、コンポジット・プロセスを介して子プロセスへドリルダウンできます。これは、最上位レベルのプロセスが他のデータ・フロー・モデル全体にドリルダウンできることを意味します。
トリガーは何らかの出来事であり、これが発生するとプロセスの実行が開始されます。
データ・フローは、1つのデータまたは情報の論理コレクションの動きを反映したものです。フローはデータ・フロー・ダイアグラムの順序を表現します。(詳細は、「データ・フロー・ダイアグラム」を参照してください。)
データ・ストアは、永続的に格納されるデータのコレクションです。
外部エージェントは、システムの外部にありながらシステムと相互に作用する個人、組織またはシステムです。外部エージェントは、プロセスに対して情報の送受信を行います。
情報ストアは、データ・モデルのエンティティおよび属性として情報を受信または保存する受動オブジェクトです。最終的に、1つの情報ストアは、データ・モデルの1つ以上のエンティティに対応します。
入力および出力パラメータを含む変換タスクは、これを実行する周囲の環境と通信する実行ユニットです。入力パラメータとして、処理を行う必要がある日付が考えられます。出力パラメータとして、操作が成功したかどうかを示すコードが考えられます。変換自体には、情報の読取り、変換および保存が含まれますが、この中には、入力および出力パラメータと直接結びついていないものがある場合があります。(詳細は、「変換プロセスおよびパッケージ」を参照してください。)
ロールは、定義された権限およびアクセス権のセットです。情報ストアに接続されたプリミティブ・プロセス(データ要素を作成、読取り、更新および削除するプロセス)は、定義済ロールにアタッチできます。その結果、ロールとデータ要素との間のコラボレーションが定義されます。後で、定義済のSelect、InsertおよびUpdate権限を持つ適切なデータベース・ロールが作成されるように、ロール定義を特定の物理モデルに送ることができます。

1.3.3.1 データ・フロー・ダイアグラム

正式な構造分析アプローチでは、機能分解プロセスを容易にするために、データ・フロー・ダイアグラム(DFD)を使用します。データ・フロー・ダイアグラムは、次のコンポーネントで構成されます。

外部インタラクタ: 矩形で表現されます。
データ・ストア: (二辺または三辺の)開矩形で表現されます。
プロセス: 丸みのあるオブジェクト(円、楕円または角が丸められた四角形)で表現されます。

プロセスは、アトミック・レベルから集計レベルに至る様々なレベルのいずれかでシステム機能を表現できます。
データ・フロー: 矢印で表現され、オプションでその内容を示すラベルが付けられます。

1.3.3.2 変換プロセスおよびパッケージ

一般的なデータ・フロー・ダイアグラムでは、外部ソースからデータを抽出し、ターゲット・ストアまたはデータベースにロードする前にデータを変換します。変換プロセスで使用する変換パッケージを作成できます。

変換プロセスでは、変換パッケージに1つ以上の変換タスクを作成する必要があります。変換タスクを作成したら、その変換タスクをメイン変換プロセスに含めることができます。

変換パッケージは、Object Management Group(OMG)のCommon Warehouse Metamodel(tm) (CWM(tm)) Specification、V1.1に定義されているパッケージです。この仕様では、次のように変換パッケージが紹介されています。

データ・ウェアハウスの主要な側面は、操作リソースからデータ・ウェアハウスまたは分析用のデータ・マートへデータを抽出、変換およびロードすることです。抽出、変換およびロードは、すべて変換とみなすことができます。実際に、データ・ウェアハウス内である形式から別の形式にデータを変換する必要がある場合は、その目的が格納、取得、表示のいずれであっても変換が常に含まれます。そのため、変換はデータ・ウェアハウスの中心になります。

「変換パッケージには、データ・ウェアハウスで使用される変換の共通メタデータを表すクラスおよび関連付けが含まれます。サポートされる変換は、オブジェクト指向、リレーショナル、レコード、多次元、XML、OLAP(On-Line Analytical Processing)およびデータ・マイニングなど、すべてのタイプのデータソースとターゲットにわたる基本的な変換です。

「変換パッケージは、変換ツールとアクティビティについての共通メタデータをやりとりできるように設計されています。」

1.3.4 論理モデル

Data Modelerのコアは、論理モデル(エンティティ関連ダイアグラムとも呼ばれる)です。これは、実装には依存しない企業情報のビューを提供し、多次元モデルとプロセス・モデルの定義を様々な物理的実装にマップするメディエータとして機能します。論理モデルまたはその一部(サブジェクト・エリア、サブビュー)は、1つ以上のリレーショナル・モデルに変換できます。

論理モデルは、次のいずれの方法でも構築できます。

Data Modelerで手動で構築する
VARファイルからモデルをインポートして構築する。これらのモデルを作成する製品およびその最小バージョンは、Sterling COOL:DBA V2.1またはSterling Bsnteam V7.2、Cayenne Bsnteam V7.2です。
Data Modelerで作成された既存のモデルをインポートして構築する。
インポートされたリレーショナル・モデルからリバース・エンジニアリングして構築する。

論理モデルは、次の2種類のデータを結合します。

1つの論理ダイアグラム(さらに、オプションでサブビューおよび補助表示のセット。それぞれは適切なダイアグラム/サブビューに関連付けられます)
論理モデル・オブジェクト定義

サブビューは、様々なサブジェクト領域を表すために作成される、論理モデルの独立したダイアグラムとみなされます。

論理モデルを使用すると、エンティティ、論理ビュー、属性、一意識別子、継承、リレーションおよびarcに対するオブジェクト定義を作成および管理できます。

すべての論理モデル・オブジェクトは、オブジェクト・ブラウザ・ツリーに表示されます。

1.3.4.1 論理ダイアグラムおよびサブビュー

論理モデル・ダイアグラムには、エンティティ、ビュー、およびそれらのリンク(リレーションおよび継承)のグラフィカルな表現が含まれます。

複雑な論理モデルで作業を行う場合は、サブビューを作成し、そのモデルの中のあるセクションのみを表すことができます。1つの論理モデルに複数の論理サブビューを定義し、その複数のサブビューにエンティティとビューを割り当てることができます。2つのエンティティ間のリンク(リレーション)が表示されるのは、全体の論理モデル上と、参照される両方のエンティティが割り当てられた論理サブビュー上のみです。

1つのサブビュー内での変更の実行と、全体の論理モデル内での変更の実行に違いはありません。実行した変更は、全体の論理モデルおよび関連サブビューに即座に反映されます。ただし、エンティティおよびビューは、全体の論理モデルから削除することなく、サブビューから削除できます。

特定のエンティティを含むサブビューを作成するには、論理モデル・ダイアグラムで目的のエンティティを選択して右クリックし、「選択した項目からサブビューを作成」を選択します。SubViewで右クリックして要素の追加/削除を選択しても、SubViewにオブジェクトを追加、またはSubViewからオブジェクトを削除することができます(「オブジェクトの追加/削除」ダイアログ・ボックスを使用)。

ダイアグラム表記法

Data Modelerでは、論理モデル・ダイアグラム表記として次の代替表記法をサポートしています。

Bachman表記法
Barker表記法

それぞれの表記法について、そのスタイルの詳細な説明および例は、書籍およびWebで広く入手できます。「Data Modeler」(「一般オプション」、「ダイアグラム」、「論理」)では、新しい論理ダイアグラムのデフォルトの表記法タイプを設定できます。

1つの表記法タイプから他に切り替えるには(また、ダイアグラムの違いを参照するには)、論理モデル・ダイアグラムを選択し、「ビュー」→「論理モデル表記法」をクリックしてから、現行とは異なる表記法をクリックします。

1.3.4.2 エンティティ

エンティティは、ユーザーが情報を格納しようと考えているオブジェクトまたは概念です。エンティティの構造は、属性のコレクションとして定義したり、データ型モデルからの構造型をベースにして定義できます。エンティティに候補となる一意識別子が複数あっても、プライマリ一意識別子として定義できるのは、そのうちの1つです。通常、エンティティはリレーショナル・モデルの表にマップされます。

1.3.4.3 属性

データ属性(プロパティ、データ要素、フィールド)は、特定のエンティティに共通している特徴です。属性のデータ型は、論理データ型、ドメイン、固有型、コレクション型または構造型をベースにすることができますが、構造型への参照にすることもできます。構造型への参照である場合は、範囲エンティティを定義できます。属性はリレーショナル・モデルの列にマップされます。

1.3.4.4 一意の識別子(UID)

エンティティの一意の識別子は1つ以上の属性から構成されています。各エンティティの出現を一意に識別する主一意識別子を各エンティティに対して1つ定義できます。また、1つ以上の外部一意識別子を指定することもでき、この識別子は、それぞれが別のエンティティの一意識別子を指します(つまり、この識別子には、別のエンティティの一意識別子にある値を含める必要があります)。

1.3.4.5 継承

継承は、スーパータイプおよびサブタイプに基づくエンティティの階層を定義します。スーパータイプおよびサブタイプのエンティティはシステムの一部に相当し、そこには、既存エンティティ・タイプの出現の認識可能なサブセットがあります。サブセットはエンティティのサブタイプと呼ばれ、元のエンティティ・タイプがスーパータイプになります。

スーパータイプのすべての属性とリレーションシップは、そのすべてのサブタイプに属している必要があります。ただし、サブタイプの一部の属性とリレーションシップは、スーパータイプの属性とリレーションシップに追加されます。サブタイプの定義が有効に行われるのは、スーパータイプの属性に加え、エンティティの出現の識別可能なグループに属性がある場合です。

1.3.4.6 リレーション

リレーション(データ・リレーションシップ)は、2つ以上のエンティティの間に存在する自然な関連です。カーディナリティは、関連エンティティの1回の出現に対する1つのエンティティの出現回数を定義します。

リレーションシップは識別または非識別にすることができ、カーディナリティとして1:1(1対1)、1:N(1対多)またはN:M(多対多)が可能です。N:Mのカーディナリティを持つリレーションは、リレーショナル・モデルの参照表にマップされます。識別リレーションシップは、そのリレーションシップが、ターゲット・エンティティのプライマリ識別子の構成要素であることを示します。

1.3.4.7 arc

arcは排他的なリレーションシップ・グループであり、エンティティのいずれのインスタンスでも、存在できるリレーションシップは1つだけであると定義されています。たとえば、セミナーではスタッフ・メンバーか外部コンサルタントのいずれかが教えることができますが、両方が同時に教えることはできません。例として、新入社員のためのセミナーは企業のスタッフ・メンバーだけで教えることができますが、製品XYXを使用するセミナーは特別な資格を持つ外部コンサルタントだけが教えることができる場合があります。

arcに含まれるすべてのリレーションは同じエンティてに属し、同じカーディナリティを持つ必要があります。arcのリレーションシップに属しているすべての外部一意識別子(外部UID)属性は、フォワード・エンジニアリング時に「NULLの許可」として転送される必要があります。arcにおける必須リレーションシップの意味は、エンティティの特定のインスタンスに対して、1つのリレーションシップのみが存在する必要があるということです。

arcの作成は、そこに含めるすべてのリレーションシップを作成した後に行います。エンティティ・ボックスを選択し、含めるすべてのリレーションシップの線を選択して([Shift]を押したまま各線をクリック)、ツールバーの「新規の円弧」ボタンをクリックします。

1.3.4.8 型置換

型置換は、継承を補完するサブクラス化メカニズムです。次が定義されている場合にのみ、エンティティ・レベルで型置換が行われます。

2つの構造型間のスーパータイプ/サブタイプの継承
データ型の継承階層(スーパータイプ/サブタイプの継承)を作成する構造型に基づくエンティティ

1.3.4.9 ビュー

ビューは、SQL問合せの名前付きの結果セットです。ビューは、1つ以上のエンティティから単一の仮想セットに対して、必要なデータを選択します。ビューを使用すると、同じデータベースを様々な側面から表示できます。

関連項目

1.3.5 リレーショナル・モデル

リレーショナル・モデルは、SQL表、列および表間の結合という観点からデータベースを表します。論理モデルから選択する各エンティティは、リレーショナル・モデル内の表として表されます。各行は表であり、対応するエンティティの特定(個別)の出現を表します。エンティティの各属性は、表の列によって表されます。

リレーショナル・モデルは、次のいずれの方法でも構築できます。

Data Modelerで手動で構築する
論理モデルまたは論理モデルのサブビューからフォワード・エンジニアリングして構築する。
VARファイルからモデルをインポートして構築する。これらのモデルを作成する製品およびその最小バージョンは、Sterling COOL:DBA V2.1またはSterling Bsnteam V7.2、Cayenne Bsnteam V7.2です。
Data Modelerで作成された既存のモデルをインポートして構築する。
Oracle Designerモデルをインポートして構築する。
既存のデータベース実装に基づくDDLファイルをインポートして構築する。
サポートされているデータベース・タイプおよびバージョンのデータ・ディクショナリからインポートして構築する。

リレーショナル・デルは、次の2種類のデータを結合します。

1つのリレーショナル・ダイアグラム(さらに、オプションでサブビューおよび補助表示のセット。それぞれは適切なダイアグラム/サブビューに関連付けられます)
リレーショナル・モデル・オブジェクト定義

サブビューは、様々なサブジェクト領域を表すために作成される、リレーショナル・モデルの独立したダイアグラムとみなされます。

リレーショナル・モデルを使用すると、表、ビュー、列、索引および外部キーに対するオブジェクト定義を作成および管理でき、オプションで特定のリレーショナル・モデル・オブジェクトをデータベース・スキーマに関連付けます。リレーショナル・モデルには、1つ以上の物理モデルを含めることができます。

すべてのリレーショナル・モデル・オブジェクトは、オブジェクト・ブラウザ・ツリーに表示されます。

1.3.5.1 リレーショナル・ダイアグラムおよびサブビュー

リレーショナル・ダイアグラムには、表、ビュー、およびそれらのリンクのグラフィカルな表現が含まれます。

複雑なリレーショナル・モデルで作業を行う場合は、サブビューを作成し、そのモデルの中のあるセクションのみを表すことができます。1つのリレーショナル・モデルに複数のリレーショナル・サブビューを定義し、その複数のサブビューに表とビューを割り当てることができます。2つの表間のリンク(リレーション)が表示されるのは、全体のリレーショナル・モデル上と、参照される両方の表が割り当てられたリレーショナル・サブビュー上のみです。

特定の表を含むサブビューを作成するには、論理モデル・ダイアグラムで目的のエンティティを選択して右クリックし、「選択項目からSubViewを作成」を選択します。SubViewで右クリックして要素の追加/削除を選択しても、SubViewにオブジェクトを追加、またはSubViewからオブジェクトを削除することができます(「オブジェクトの追加/削除」ダイアログ・ボックスを使用)。

データ・ディクショナリからインポートを行う場合に、インポートするスキーマを複数選択すると、すべてのスキーマを対象にしたリレーショナル・モデルが1つ作成され、サブビューはスキーマごとに1つ作成されます。

1つのサブビュー内での変更の実行と、全体のリレーショナル・モデル内での変更の実行に違いはありません。実行した変更は、全体のリレーショナル・モデルおよび関連サブビューに即座に反映されます。ただし、表およびビューは、全体のリレーショナル・モデルから削除することなく、サブビューから削除できます。

1.3.5.2 表

表は、情報を格納するオブジェクトです。表の構造は、列のグループとして定義したり、データ型モデルからの構造型をベースにして定義できます。表に候補となるキーが複数あっても、主キーとして定義できるのは、そのうちの1つです。通常、表は論理モデルからエンティティにマップされます。

1.3.5.3 列

表の列は、特定の表に共通している特徴です。列のデータ型は、論理データ型、ドメイン、固有型、コレクション型または構造型をベースにすることができますが、構造型への参照にすることもできます。構造型への参照である場合は、範囲表を定義できます。通常、表の列は、論理モデルから対応するエンティティの属性にマップされます。

1.3.5.4 索引

索引は、実表の列に対するポインタの順序付けされたセットで構成されるオブジェクトです。各索引は、1つ以上の表列のデータの値に基づきます。頻繁に検索される列に索引を定義することで、データベース・アプリケーションのパフォーマンスを向上させることができます。

1.3.5.5 リレーション

リレーション(データ・リレーションシップ)は、2つ以上の表の間に存在する自然な関連です。リレーションシップは、主キーおよび外部キーのデータ値で表されます。カーディナリティは、関連表での1回の出現に対する1つの表での出現回数を定義します。

識別リレーションシップは、そのリレーションシップが、ターゲット表のプライマリ識別子の構成要素であることを示します。

排他的なリレーションシップ(arc)は、表内の特定のインスタンスに対して、存在できるリレーションシップは1つだけであることを指定します。たとえば、セミナーではスタッフ・メンバーか外部コンサルタントのいずれかが教えることができますが、両方が同時に教えることはできません。例として、新入社員のためのセミナーは企業のスタッフ・メンバーだけで教えることができますが、製品XYXを使用するセミナーは特別な資格を持つ外部コンサルタントだけが教えることができる場合があります。

arcのすべてのリレーションシップは、同じ表に属し、同じカーディナリティを持つ必要があります。arcのリレーションシップに属しているすべての外部キー(FK)属性は、フォワード・エンジニアリング時に「NULLの許可」として転送される必要があります。arcにおける必須リレーションシップの意味は、表の特定のインスタンスに対して、1つのリレーションシップのみが存在する必要があるということです。

arcの作成は、そこに含めるすべてのリレーションシップを作成した後に行います。表ボックスを選択し、含めるすべてのリレーションシップの線を選択して([Shift]を押したまま各線をクリック)、ツールバーの「新規の円弧」ボタンをクリックします。

1.3.5.6 リレーショナル・ビュー

リレーショナル・ビューは、SQL問合せの名前付きの結果セットです。ビューは、1つ以上の表から単一の仮想セットに対して、必要なデータを選択します。ビューを使用すると、同じデータベースを様々な側面から表示できます。

関連項目

1.3.6 物理モデル

物理モデルは、リレーショナル・モデルに基づいたOracle Databaseオブジェクト(表、ビュー、トリガーなど)の観点からデータベースを表します。各リレーショナル・モデルには、1つ以上の物理モデルを含めることができます。次に、複数のリレーショナル・モデルおよび物理モデルを持つデータベース設計階層を示します。

Database design
   Logical model
      Relational model 1
         Physical model 1a
         Physical model 1b
         . . . (other physical models)
      Relational model 2
         Physical model 2a
         Physical model 2b
         . . . (other physical models)
      . . . (other relational models)

各物理モデルはRDBMSサイト・オブジェクトに基づいています。RDBMSサイトはData Modelerがサポートするデータベースのタイプに関連付けられる名前です。複数のRDBMSサイトが事前定義されます(たとえば、Oracle 11gおよびMicrosoft SQL Server 2005用)。また、「RDBMSサイト・エディタ」ダイアログ・ボックスを使用して、サポートされているデータベース・タイプの別名としてユーザー定義のRDBMSサイトを作成することもできます。たとえば、異なる物理モデルを生成してから変更できるように、TestおよびProductionという名前のサイトを作成する場合があります。

DDLファイルにエクスポートするときに物理モデルを適用するように指定します。生成されたDDL文には、その物理モデルに指定された機能に適切な句およびキーワードが含まれています(たとえば、1つ以上の表に対するパーティション化)。

作業領域には物理モデルのグラフィカルな表現はありませんが、かわりに、オブジェクト・ブラウザ階層に表示されます。物理モデルでオブジェクトを作成および管理するには、オブジェクト・ブラウザで「物理」メニューまたはコンテキスト・メニュー(右クリック)を使用します。

このトピックの残りの部分では、様々なOracle Databaseオブジェクトについて簡単に説明します。説明するオブジェクトの順序は、Oracle物理モデルにおける表示順ではありません。

1.3.6.1 クラスタ

クラスタとは、1つ以上の表のデータが含まれているスキーマ・オブジェクトのことです。

索引クラスタには複数のクラスタが含まれる必要があり、クラスタ内のすべての表が1つ以上の共通する列を持ちます。Oracle Databaseでは、同一のクラスタ・キーを共有するすべての表からすべての行がまとめて格納されます。
1つ以上の表を含めることができるハッシュ・クラスタの場合、Oracle Databaseは同じハッシュ・キー値を持つ行をまとめて格納します。

1.3.6.2 コンテキスト

コンテキストは、アプリケーションを検証および保護するアプリケーション定義属性のセットです。

1.3.6.3 ディメンション

ディメンションは、列セットのペア間の親子関係を定義するもので、この列セットに含まれるすべての列は、同じ表の列である必要があります。ただし、1つの列集合(レベル)の列は、別の集合の列とは異なる表から得ることができます。オプティマイザでは、これらの関係をマテリアライズド・ビューとともに使用して、クエリー・リライトを実行します。SQLアクセス・アドバイザは、この関係に基づいて、特定のマテリアライズド・ビューの作成を推奨します。

1.3.6.4 ディレクトリ

ディレクトリは、外部バイナリ・ファイルLOB(BFILE)および外部表データが存在するサーバー・ファイル・システムのディレクトリ(Windowsシステムではフォルダと呼ばれる)の別名です。

PL/SQLコードおよびOCI(Oracle Call Interface)コールでBFILEを参照する際に、オペレーティング・システムのパス名をハードコードするかわりにディレクトリ名を使用して、管理の柔軟性を向上できます。すべてのディレクトリは1つのネームスペースに作成され、個別のスキーマでは所有されません。ディレクトリ構造内に格納されたBFILEへのセキュアなアクセスを確保するには、ディレクトリのオブジェクト権限を特定のユーザーに付与します。

1.3.6.5 ディスク・グループ

ディスク・グループは、Oracle Databaseが論理ユニットとして管理するディスクのグループであり、各ファイルは、I/Oのバランスをとるために、すべてのディスクに均一に分散されます。また、Oracle Databaseでは、ディスク・グループで使用可能なすべてのディスクにデータベース・ファイルが自動的に分散され、記憶域構成が変わると常に、記憶域が自動的にリバランスされます。

1.3.6.6 外部表

外部表は、外部ソースのデータがデータベースの表に存在するかのように、外部ソースのデータにアクセスできるようにします。外部表を使用するには、使用しているプラットフォーム上のデータファイルについて、ファイル形式およびレコード形式の知識がいくらか必要です。

1.3.6.7 索引

索引は、表またはクラスタの索引列の各値に対するエントリが含まれるデータベース・オブジェクトです。行に対して、直接的な高速アクセスが可能です。索引は、主キー列で自動的に作成されます。ただし、索引を有効に利用するには、他の列で索引を作成する必要があります。

1.3.6.8 ロール

ロールは、ユーザーまたは他のロールに付与することができる権限のセットです。ロールを使用して、データベース権限を管理できます。ロールに権限を追加し、そのロールをユーザーに付与することができます。その後、ユーザーはロールを有効にして、そのロールによって付与された権限を行使することができます。

1.3.6.9 ロールバック・セグメント

ロールバック・セグメントは、Oracle Databaseが使用するオブジェクトであり、トランザクションによって行われた変更をリバースする(元に戻す)ために必要となるデータが格納されます。ただし、ロールバック・セグメントを使用するかわりに、自動UNDO管理モードでデータベースを実行することをお薦めします。ロールバック・セグメントは、以前のバージョンのOracle Databaseとの互換性に必要な場合以外は使用しないでください。自動UNDO管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

1.3.6.10 セグメント(セグメント・テンプレート)

セグメントは、表領域内の論理記憶域構造のすべてのデータが含まれるエクステントのセットです。たとえば、Oracle Databaseでは、1つ以上のエクステントを割り当てることによって、表のデータ・セグメントを形成します。また、データベースは、表の索引セグメントを作成するためにも、1つ以上のエクステントを割り当てます。

1.3.6.11 順序

順序は、一意の整数を生成するために使用されるオブジェクトです。順序を使用すると、主キー値を自動的に生成できます。

1.3.6.12 スナップショット

スナップショットは、自動データベース診断モニター(ADDM)がパフォーマンス比較のために使用する、特定期間の一連の履歴データです。デフォルトでは、Oracle Databaseは自動的にパフォーマンス・データのスナップショットを生成し、ワークロード・リポジトリに統計を保持します。スナップショットは手動でも作成できますが、通常は必要ありません。スナップショット間隔でのデータは、ADDMによって分析されます。ADDMの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

1.3.6.13 ストアド・プロシージャ

ストアド・プロシージャは、一連のSQL文と他のPL/SQL構文で構成されるスキーマ・オブジェクトです。これらは、まとめてグループ化されてデータベースに格納され、特定の問題を解決したり、一連の関連タスクを実行するために1つの単位として実行されます。

1.3.6.14 シノニム

シノニムは、表、ビュー、順序、プロシージャ、ストアド・ファンクション、パッケージ、ユーザー定義のオブジェクト・タイプまたは他のシノニムの代替名です。シノニムはパブリック(すべてのデータベース・ユーザーが使用可能)、またはプライベート(シノニムを所有するデータベース・ユーザーのみが使用可能)にできます。

1.3.6.15 構造型

構造型は、プロパティの固定されたセットを表の列で使用できる値に関連付ける複雑なデータ型です。このプロパティによって、Oracle Databaseでは、あるデータ型の値と別のデータ型の値が異なる方法で処理されます。ほとんどのデータ型は、Oracleによって提供されています。ただし、ユーザーがデータ型を作成することもできます。

1.3.6.16 表

表は、データの保持に使用されます。通常、それぞれの表には、その表に関連付けられたデータベース・エンティティの属性を表す複数の列が存在し、それぞれの列には、データ型が関連付けられます。企業の様々なニーズに対応するために、多くの表作成オプションと表構成(パーティション表、索引構成表、外部表など)を使用できます。

1.3.6.17 表領域

表領域は、データベースにおける領域の割当てであり、そこにはスキーマ・オブジェクトが含まれます。

永続表領域には、永続スキーマ・オブジェクトが含まれます。永続表領域内のオブジェクトはデータファイル内に格納されます。
UNDO表領域は、データベースを自動UNDO管理モードで実行している場合に、Oracle DatabaseがUNDOデータを管理するために使用する、一種の永続表領域です。元に戻す場合は、ロールバック・セグメントではなく、自動UNDO管理モードを使用することをお薦めします。
一時表領域には、セッション期間のみのスキーマ・オブジェクトが含まれます。一時表領域のオブジェクトは、一時ファイルに格納されます。

1.3.6.18 ユーザー

データベース・ユーザーはデータベースにログインするアカウントです。(データベース・ユーザーはデータベース・オブジェクトであり、データベース、またはデータベースにアクセスするアプリケーションのユーザー(人間に相当するユーザー)とは異なります。)各データベース・ユーザーは、ユーザーと同じ名前を持つデータベース・スキーマを持ちます。

1.3.6.19 ビュー

ビューは、1つ以上の基礎となる表からデータを選択する仮想表です(一部のデータベース製品での問合せに相当します)。Oracle Databaseには、多数のビュー作成オプションと特殊なビューが用意されています。

関連項目

1.3.7 ビジネス情報

ビジネス情報オブジェクトは、モデル・オブジェクトについてビジネス志向の情報を定義します。この情報には、責任者とその連絡方法や、関連するオフライン・ドキュメントの識別などがあります。

モデル・オブジェクトは、自身に関連付けられたビジネス情報オブジェクトをゼロまたは1つ以上持つことができ、ビジネス情報オブジェクトは、ゼロまたは1つ以上のモデル・オブジェクトに関連付けることができます。たとえば、1つのドキュメントは数多くの異なるエンティティおよび属性を説明するために使用で、1人のユーザーは複数のイベントの責任者になることができます。

ビジネス・オブジェクト間には、多対多のリレーションシップが存在できます。たとえば、責任者は連絡先情報(連絡先オブジェクト)を複数セット持つことができ、連絡先オブジェクトは複数の責任者に関連付けることができます。同様に、1つ以上の電話、電子メール、ロケーションおよびURLオブジェクトを複数の連絡先オブジェクトに関連付けることができます。

Data Modelerビジネス情報モデルは、Object Management Group(OMG)ビジネス情報パッケージに基づいており、これはOMGのCommon Warehouse Metamodel(tm)(CWM(tm)) Specification、V1.1に、次のように説明されています。「ビジネス情報メタモデルは、モデル要素についてのビジネス指向情報を定義するために、すべてのCWMパッケージで使用可能な汎用サービスを提供します。ここで説明されるビジネス指向サービスは、データ・ウェアハウスおよびビジネス・インテリジェンス・システムのニーズをサポートするように設計されており、汎用ビジネス・インテリジェンス・メタモデルを完全に表現するようには意図されていません。ビジネス情報メタモデル・サービスは、責任者とその連絡方法、オフライン・ドキュメントの識別および汎用的な記述情報のサポートについて、その概念をサポートします。」

このトピックの残りの部分では、ビジネス情報オブジェクトについて簡単に説明します。説明するオブジェクトの順序は、ビジネス情報のオブジェクト・ブラウザにおける表示順ではありません。

1.3.7.1 連絡先

連絡先オブジェクトは、関連する様々なタイプの連絡先情報をグループ化します。各連絡先オブジェクトは、複数の電子メール、ロケーション、URLおよび電話オブジェクトに関連付けることができます。反対に、各電子メール、ロケーション、URLおよび電話オブジェクトは、多数の連絡先オブジェクトに関連付けることができます。(「連絡先のプロパティ」も参照してください。)

1.3.7.2 ドキュメント

ドキュメント・オブジェクトは、モデル化されたシステムのいくつかの側面について、外部に格納された記述情報を表します。ドキュメント・オブジェクトは、1つ以上のモデル・オブジェクトに関連付けることができます。(「ドキュメントのプロパティ」も参照してください。)

1.3.7.3 電子メール

電子メール・オブジェクトは、1つの電子メール・アドレスを識別します。連絡先オブジェクトを使用すると、電子メール・アドレスを1人以上の責任者と関連付けることができます。連絡先の電子メール・オブジェクトの順序は、連絡先との通信に使用を試みる電子メール・アドレスの順番で表される場合があります。(「電子メールのプロパティ」も参照してください。)

1.3.7.4 ロケーション

ロケーション・オブジェクトは、1つの物理的な場所を識別します。連絡先オブジェクトを使用すると、ロケーションを1人以上の責任者と関連付けることができます。ロケーションの連絡先オブジェクトの順序は、ロケーションに関連付けられた個人またはグループへの連絡を試みる際の順番で表される場合があります。(「ロケーションのプロパティ」も参照してください。)

1.3.7.5 リソース・ロケータ

リソース・ロケータ・オブジェクトは、従来のメール・アドレスでロケーションが定義されていないリソースを表すための一般的な手段を提供します。たとえば、リソース・ロケータは、Webアドレス(「www.example.com」など)から、建物内の場所(「317号室、3番目のファイル・キャビネット、2番目の引出し」など)に至るまで、どのよう場所でも参照することができます。(「リソース・ロケータのプロパティ」も参照してください。)

1.3.7.6 責任者

責任者オブジェクトは、1つ以上のモデル・オブジェクトについての情報に責任を持っていたり、その情報を受け取る必要がある個人、ロールまたは組織を表します。責任オブジェクトにおける責任の正確な意味は、実装されている特定のシステムに応じて異なります。(「責任者のプロパティ」も参照してください。)

1.3.7.7 電話

電話オブジェクトは、電話での連絡先情報を表します。電話オブジェクトは、1つ以上の連絡先に関連付けることができます。(「電話のプロパティ」も参照してください。)

関連項目

1.4 データ・モデリングへのアプローチ

データをモデル化する場合は、実行する作業の特質に最も適したアプローチを選択できます。データ・モデリングへのアプローチには、新しいデータベースの設計、既存のデータベースに向けた設計の開発、または既存のデータベース設計でのメンテナンスの実行が含まれます。

トップダウン・モデリング: 新しいデータベースを設計する場合
ボトムアップ・モデリング: 既存のデータベースからメタデータを抽出してデータベースを作成する場合、または既存のデータベースの実装から取得したDDLコードを使用してデータベースを作成する場合
ターゲット・モデリング: データベースを新しい要件に適応させる場合

1.4.1 トップダウン・モデリング

トップダウン・モデリングでは、業務要件および内部環境についての情報を収集しから、プロセス、データの論理モデル、1つ以上のリレーショナル・モデル、および各リレーショナル・モデルの1つ以上の物理モデルを定義します。ニーズによっては、ステップと情報要件は簡単なものから詳細なものに及ぶことがあります。トップダウン・モデリングには次のステップが含まれますが、ニーズに合わせてステップを短縮したり、省略することができます。

ビジネス情報を作成します。
1. ドキュメントを作成します。オブジェクト・ブラウザで、「論理」を右クリックして、「プロパティ」を選択して、次に「ドキュメント」をクリックして適切な項目を追加します。
2. 連絡先、電子メール・アドレス、ロケーションおよび電話番号を使用して、責任者を作成します。オブジェクト・ブラウザで、「論理」を右クリックして、「プロパティ」を選択し、次に「責任者」をクリックして、適切な項目を追加します。
3. 他の情報を追加します。オブジェクト・ブラウザで、「論理」を右クリックして、「プロパティ」を選択し、次に必要に応じて他のプロパティ(「命名オプション」、「コメント」、「ノート」)を変更します。
データ・フロー・ダイアグラムを使用して、プロセス・モデルを開発します。プロセス・モデルのオブジェクト・ブラウザで「データ・フロー・ダイアグラム」を右クリックして、「新規データ・フロー・ダイアグラム」を選択します。
1. プロセスを作成します。プロセスごとに、「新規プロセス」アイコンをクリックしてデータ・フロー・ダイアグラム・ウィンドウの中をクリックし、「情報ストアのプロパティ」ダイアログ・ボックスに情報を入力します。
2. 外部エージェントを作成します。外部エージェントごとに、「新規外部エージェント」アイコンをクリックしてデータ・フロー・ダイアグラム・ウィンドウの中をクリックし、「外部エージェントのプロパティ」ダイアログ・ボックスに情報を入力します。
3. 情報ストアを作成します。プロセスごとに、「新規情報ストア」アイコンをクリックしてデータ・フロー・ダイアグラム・ウィンドウの中をクリックし、「情報ストアのプロパティ」ダイアログ・ボックスに情報を入力します。
4. 情報構造を使用してフローを作成します。フローごとに、「新規フロー」アイコンをクリックし、データ・フロー・ダイアグラム・ウィンドウで始点オブジェクト(プロセスなど)をクリックして、フローの終点オブジェクトをクリックし、次にフローの矢印をダブルクリックして、「フローのプロパティ」ダイアログ・ボックスの情報を(必要に応じて)変更します。
論理モデルを作成します。
1. エンティティを作成し、各エンティティの属性および一意識別子を作成します。最初にすべてのエンティティを作成してから、それぞれの属性および一意識別子を作成するか、1番目のエンティティとその属性および識別子を作成し、次に2番目以降も同じように順次作成していくこともできます。
  
  エンティティを作成するには、「論理」タブをクリックして「新規エンティティ」アイコンをクリックし、論理モデル・ウィンドウの中をクリックして、「エンティティのプロパティ」ダイアログ・ボックスに情報を入力します。また、このダイアログ・ボックスの該当するペインを使用して、属性および一意識別子を入力することもできます。
2. エンティティ間のリレーションを作成します。リレーションごとに、目的のアイコン(「新規のM:Nリレーション」(1対多)、「新規の1:N識別リレーション」(1対多、識別)または「新規の1:1リレーション」(1対1))をクリックします。リレーションの始点のエンティティをクリックして、リレーションの終点をクリックし、次に、リレーションの線をダブルクリックして、「リレーションのプロパティ」ダイアログ・ボックスの情報を必要に応じて変更します。
3. 論理モデルに設計ルールを適用します。「ツール」→「設計ルール」をクリックし、「設計ルール」ダイアログ・ボックスを使用して、デザイン・ルールの違反を確認して修正します。
4. 論理モデルをリレーショナル・モデルにフォワード・エンジニアします。ナビゲータで論理モデルを右クリックして、「リレーショナル・モデルに対するエンジニアリング」を選択して、「エンジニアリング」ダイアログ・ボックスを使用して、論理モデルのすべてのオブジェクトまたは指定されたオブジェクトのサブセットを反映するリレーショナル・モデルを生成します。
必要に応じて、多次元モデルを作成します。
1. キューブを作成します。
2. レベルを作成します。
3. ディメンションを作成します。
4. リンクを作成します。
5. 多次元モデルに設計ルールを適用します。
6. 必要に応じて、多次元モデルをエクスポートします。
必要に応じて、1つ以上のリレーショナル・モデルを作成します。作成するには、各リレーショナル・モデルで次の手順を実行します。
1. 表を分割します。1つの表を2つに分割するには、リレーショナル・モデル・ダイアグラムで表を選択して、「表の分割」ボタンをクリックします。
2. 表をマージします。別の表に表をマージ(マージされる表は削除)するには、「表のマージ」ボタンをクリックします。次にリレーショナル・モデル・ダイアグラムでまずほかの表からの列のマージ先となる表を選択してからマージ元の列を持つ他の表を選択します。(マージ後、2番目の表は削除されます。)
3. リレーショナル・モデル用の設計ルールを確認します。「ツール」→「設計ルール」をクリックします。
リレーショナル・モデルごとに、1つ以上の物理モデルを作成します。作成するには、各リレーショナル・モデルで次の手順を実行します。
1. 物理モデルを開きます。
2. 物理モデル用の設計ルールを確認します。「ツール」→「設計ルール」をクリックします。
3. 実際のデータベース・オブジェクトの生成に使用できるDDLコードを生成します。「表示」→「DDLファイル・エディタ」をクリックして、次に「DDLファイル・エディタ」ダイアログ・ボックスを使用して、物理モデルの選択、DDLコードのスクリプト・ファイルへの保存を行います。

1.4.2 ボトムアップ・モデリング

ボトムアップ・モデリングは、既存のデータベースから抽出されたメタデータに基づいてデータベース設計を構築するか、または既存のデータベースを実装するDDLコードのファイルに基づいてデータベース設計を構築します。作成されるデータベースは、リレーショナル・モデルおよび物理モデルとして表され、リレーショナル・モデルから論理モデルをリバース・エンジニアします。ボトムアップ・モデリングには次のステップが含まれますが、ニーズに合わせていくつかのステップを短縮したり、省略することができます。

次のいずれかの方法で、リレーショナル・モデルを生成します。
- 既存のデータベースから直接メタデータを抽出します。「ファイル」→「インポート」→「データ・ディクショナリ」をクリックし、ウィザードの指示に従います(「データ・ディクショナリ・インポート(メタデータ抽出)」を参照してください)。
- 既存のデータベース実装を反映するDDLコードをインポートします。「ファイル」→「インポート」→「DDLファイル」をクリックします。
必要に応じて、リレーショナル・モデルを変更して、追加のリレーショナル・モデルを作成します。
必要に応じて、リレーショナル・モデルを非正規化します。必要に応じて、各モデルに対して次のステップを繰返し実行します。
1. 表の分割またはマージ、あるいはその両方を実行します。
  
  1つの表を2つに分割するには、リレーショナル・モデル・ダイアグラムで表を選択して、「表の分割」ボタンをクリックします。「表の分割」ウィザードを使用して、ソースの外部キーおよび列をターゲット表(作成された新しい表)にコピーまたは移動します。
  
  別の表に表をマージ(マージされる表は削除)するには、「表のマージ」ボタンをクリックします。次に、リレーショナル・モデル・ダイアグラムで、列を他の表にマージする表をクリックして、次に最初にクリックした表の列のマージ先となる表をクリックします。(マージ後、最初にクリックした表が削除され、残りの表には、その元の列と最初の表にあった列が含まれます。.)
2. モデル用の設計ルールを確認します。設計ルールを表示するには、「ツール」→「設計ルール」をクリックし、目的のリレーショナル・モデルを選択して、「設計ルール」ダイアログ・ボックスを使用します。
リレーショナル・モデルから論理モデルにリバース・エンジニアします。「論理モデルに対するエンジニアリング」アイコンをクリックするか、リレーショナル・モデルを右クリックして「論理モデルに対するエンジニアリング」を選択します。
必要に応じて、論理モデルを変更します。
論理モデル用の設計ルールを確認します。「ツール」→「設計ルール」をクリックします。
設計を保存します。
DDLコードを作成し、それを使用してデータベース実装を作成します。「ビュー」→「DDLファイル・エディタ」をクリックします。「DDLファイル・エディタ」ダイアログ・ボックスで、物理モデルを選択して「生成」をクリックします。目的の「DDL生成オプション」を指定して、「OK」をクリックします。

1.4.3 ターゲット・モデリング

ターゲット・モデリングには、既存のデータベースのメンテナンスが含まれますが、これは新しい要件に適応させて行います。

ノート:

Data Modelerでデータベースをメンテナンスするには、設計と実際のデータベース実装が完全に同期する必要があります。これに該当するかどうか不明な場合は、設計を古いものとみなして、「ボトムアップ・モデリング」の手順を実行する必要があります。

必要な変更の種類に応じて、論理モデル、1つ以上のリレーショナル・モデルまたは1つ以上の物理モデルから開始し、必要に応じて、フォワード・エンジニアまたはリバース・エンジニアを行うことができます。

論理モデルの変更から開始するには:

変更する論理的モデル・オブジェクト(エンティティ、属性、リレーションなど)ごとに、そのプロパティを変更します。たとえば、エンティティに属性を追加するには、次の手順を実行します。
1. 論理ダイアグラムでエンティティのアイコンをダブルクリックします(または、オブジェクト・ブラウザでエンティティ名を右クリックして、「プロパティ」を選択します)。
2. 「エンティティのプロパティ」ダイアログ・ボックスで、「属性」をクリックします。
3. 「追加」(+)アイコンをクリックして、属性プロパティを指定します。
論理モデルの変更が完了したら、「リレーショナル・モデルに対するエンジニアリング」アイコンをクリックするか、ナビゲータで論理モデルを右クリックしてから「リレーショナル・モデルに対するエンジニアリング」を選択して、変更点をリレーショナル・モデルにフォワード・エンジニアします。
「エンジニアリング」ダイアログ・ボックスで、必要なフィルタリングを指定して「エンジニア」をクリックします。

リレーショナル・モデルの変更から開始するには:

変更するリレーショナル・モデル・オブジェクト(表、列など)ごとに、そのプロパティを変更します。たとえば、リレーショナル・モデルの表に列を追加するには、次の手順を実行します。
1. リレーショナル・モデルのダイアグラムで表のアイコンをダブルクリックします(または、オブジェクト・ブラウザで表名を右クリックして、「プロパティ」を選択します)。
2. 「表のプロパティ」ダイアログ・ボックスで、「列」をクリックします。
3. 「追加」(+)アイコンをクリックして、列プロパティを指定します。
リレーショナル・モデルの変更が完了したら、「論理モデルに対するエンジニアリング」をクリックするか、ナビゲータでリレーショナル・モデル名を右クリックしてから「論理モデルに対するエンジニアリング」を選択して、変更点を論理モデルにリバース・エンジニアします。
「エンジニアリング」ダイアログ・ボックスで、必要なフィルタリングを指定して「エンジニア」をクリックします。

1.5 Data Modelerのユーザー・プリファレンス

ユーザー自身の好みとニーズに合わせてユーザー・プリファレンスを変更することで、Data Modelerの環境とインタフェースの多くの設定をカスタマイズできます。ユーザー・プリファレンスを変更するには、「ツール」→「プリファレンス」を選択します。

「検索」ボックス: 文字列を入力して、関連するプリファレンス・グループが一致するようツリー表示を制限します。

ほとんどのプリファレンスはわかりやすいものであるため、ここでは、意味と意図が明確でないプリファレンスについてのみ説明します。プリファレンスによっては、パフォーマンスまたはシステム・リソースに影響するものや(機能の有効化による実行時間の増加など)、単に個人の好みによるものがあります。プリファレンスは、次のカテゴリにグループ化されています。

1.5.1 環境

「環境」ペインには、Data Modelerの起動、動作全体および外観に影響するオプションが含まれます。指定したタイミングで特定の操作が自動的に実行されるように指定できます。通常、操作に余分な時間がかかりますが、操作を自動的に実行しない場合に問題が発生する可能性(必要な操作の実行を忘れてしまう、など)を考慮して、指定するかどうかを判断します。

UNDOレベル(元に戻せる実行済操作の数)とナビゲーション・レベル(開いているファイルの数)の値への変更によって、システム・リソースの使用率がわずかに増減します。

外部で変更されたファイルを自動的にリロード: このオプションを選択した場合、Data Modelerで開いているファイルが外部アプリケーションによって変更されると、Data Modelerに再び切り替えたときにそのファイルは更新され、Data Modelerで行われた変更が上書きされます。このオプションを選択しない場合、Data Modelerで行った変更が適用され、外部アプリケーションで行われた変更が上書きされます。

未修正ファイルの場合、警告なしでリロード: このオプションを選択した場合、外部で変更されたがData Modelerでは変更されていないファイルについては、リロードするかどうかの確認が行われません。このオプションを選択しない場合、Data Modelerで変更されたかどうかに関係なく、外部で変更された各ファイルをリロードするかどうかが確認されます。

環境: ドッキング可能なウィンドウ

「ドッキング可能なウィンドウ」ペインでは、ドッキング可能なウィンドウの動作と、Data Modelerの4つのドッキング領域(上下左右)の形を構成します。

ドッキング可能なウィンドウを常に上に表示: このオプションを選択した場合、ドッキング可能なウィンドウは、常に他のウィンドウの手前に表示されます。

ウィンドウ・レイアウト: 角の矢印をクリックして、各ドッキング領域の形を拡大または縮小します。

環境: ログ

「ログ」ペインでは、特定のタイプのログ・メッセージの色およびログ・メッセージのログ・ファイルへの保存を構成します。

ファイルにログを保存: このオプションを選択した場合、「メッセージ - ログ」ウィンドウへのすべての出力は、ログ・ファイルに保存されます。ファイル名には、操作およびタイムスタンプが反映されます。また、「ログ・ディレクトリ」を指定するように求められます。指定したディレクトリが存在しない場合は作成されます。ログ情報をファイルに保存する場合、ファイル数が非常に多くなる可能性があることに注意してください。

最大ログ行数: 各ログ・ファイルに格納する行の最大数。

関連項目

1.5.2 Data Modeler

「Data Modeler」ペインには、Data Modelerの起動、動作全体および外観に影響するオプションが含まれます。

デフォルト設計ディレクトリ: 設計を開く場所または設計を作成する場所になるデフォルトのディレクトリまたはフォルダです。

デフォルト・インポート・ディレクトリ: ファイルのインポート元になるデフォルトのディレクトリまたはフォルダ。

インポート後にログの表示: インポート操作の後に、「ログ」ウィンドウを表示するかどうかを制御します。ウィンドウには、情報メッセージと、警告またはエラー・メッセージが含まれます。

デフォルトの保存ディレクトリ: ファイルの保存先となるデフォルトのディレクトリまたはフォルダです。

デフォルトのシステム・タイプ・ディレクトリ: タイプ定義ファイルの格納先となるデフォルトのディレクトリまたはフォルダです。

「リレーショナル・モデルの選択」ダイアログの表示: Data Modeler設計を開くときに、含めるリレーショナル・モデルを選択するためのダイアログ・ボックスを表示するかどうかを制御します。このオプションを無効にすると、Data Modeler設計を開くときに、すべてのリレーショナル・モデルがデフォルトで含まれます。

「新規オブジェクトの「プロパティ」ダイアログの表示」: 新しいモデル・オブジェクトを作成するときに、そのタイプのオブジェクトの「プロパティ」ダイアログ・ボックスを表示するかどうかを制御します。

OCI/Thickドライバの使用: Oracle Database接続の際、JDBC (Thin)ドライバのかわりに、使用可能な場合にデフォルトでoci8 (Thick)ドライバを使用するかどうかを制御します。

最新の状態のリロード: Data Modelerを再起動したとき、前回開いていた設計を再ロードするかどうかを制御します。(このオプションの設定にかかわらず、最近開いた設計は「ファイル」 > 「最新の設計」をクリックすれば表示できます。)

インポート: 「プリファレンスおよびその他の設定のエクスポートおよびインポート」で説明するように、事前にエクスポートしたData Modelerのプリファレンスおよびその他の設定をインポートできます。

エクスポート: Data Modelerのプリファレンスおよびその他の設定をXMLファイルに保存して、「プリファレンスおよびその他の設定のエクスポートおよびインポート」で説明するように、後で情報をインポートできるようにします。

スクリプトの終了時に確認を表示: このオプションを有効にすると、スクリプトが正常に実行された後に確認ダイアログが表示されます。

Data Modelerのその他のプリファレンスは、次のカテゴリにグループ化されています。

1.5.2.1 DDL

「DDL」ペインには、生成されるコードのデータ定義言語(DDL)文に対する一般的なオプションが含まれます。

DB2およびUDBの文終了文字: IBM DB2およびUDBデータベース用のDDLの終了文字です。

OracleおよびUDBの型置換トリガーの作成: OracleおよびIBM UDB物理モデルで、型置換用にトリガーを作成するかどうかを制御します。

円弧制約の作成: 生成されたDDLコードに、外部キー円弧制約を実装するトリガーを作成するかどうかを制御します。

転送不可FKのトリガーの作成: 移動不可能な外部キー・リレーションシップ用にトリガーを作成するかどうかを制御します。(外部キー・リレーションシップが移動可能かどうかは、「外部キーのプロパティ」ダイアログ・ボックスの「移動可能」(更新可能)オプションで制御されます。)

Oracle Varchar2およびChar型の文字/バイト単位の表示: OracleのCHAR型またはVARCHAR2型の属性について、その属性の長さに関連付けられた単位(文字またはバイト)が属性に関する列として、リレーショナル・モデル・ダイアグラムおよび生成されたCREATE TABLE文に含まれるかどうかを制御します。

Oracle用文字の拡張サイズ: DDLを生成するとき、MAX_STRING_SIZE = EXTENDED初期化パラメータの動作を使用できる、つまりVARCHAR2、NVARCHAR2およびRAWデータ型でサイズ制限を32767バイトにするかどうかを制御します。4,000バイト以上のサイズを宣言したVARCHAR2データ型またはNVARCHAR2データ型、または2,000バイト以上のサイズを宣言したRAWデータ型は、拡張データ型になります。拡張データ型の列は、OracleのLOBテクノロジを利用して表外に格納されます。詳細は、『Oracle Database SQL言語リファレンス』のデータ型に関する章で、拡張データ型に関する項を参照してください。

NOT NULL制約の短縮形の生成: 列定義(CREATE TABLE文)で、NOT NULL制約名を使用するかどうかを制御します。

引用符付き識別子の使用: 生成されるDDL文でオブジェクト名を二重引用符で囲むかどうかを制御します。

インポート中にシステム名を置換: Oracle Databaseによって割り当てられた元々の制約名(SYS_で始まる名前など)を、インポート操作中に維持するか、それともData Modelerによって割り当てられる名前(主キーの場合、T_PKで始まる名前など)に置き換えるかを制御します。

インポート時にドメインを作成: インポート操作時に、データ・タイプからドメインを作成するかどうかを制御します。

RDBMSでのコメントの生成: 生成されるDDL文にRDBMSテキストのコメントを含めるかどうかを制御します。

インライン列CHECK制約の生成: 列チェック制約の句をインライン(CREATE TABLE文)に含めか、または別の制約定義(ALTER TABLE文)とするかを制御します。

DDLにデフォルト設定を含める: キーワードの設定を指定しなかった場合に、生成されるDDL文にデフォルトのキーワードを含めるかどうかを制御します。このオプションは、生成される文で使用されるすべてのキーワードを表示する場合に役立ちます。

DDLにロギングを含める: 生成されるDDL文にロギング情報を含めるかどうかを制御します。

DDLにスキーマを含める: 生成されるDDL文で、オブジェクト名にスキーマ名の接頭辞を付けるかどうかを制御します(たとえば、SCOTT.EMPに対してEMPのみ)。

DDLに記憶域を含める: 生成されるDDL文に記憶域情報を含めるかどうかを制御します。

DDLに表領域を含める: 生成されるDDL文に表領域を含めるかどうかを制御します。

DDLにリダクションを含める: 生成されるDDL文にデータ・リダクション情報を含めるかどうかを制御します。(『Oracle Databaseセキュリティ・ガイド』の透過的機密データ保護の使用に関する章の説明に従って、リダクションの概念および技術を理解する必要があります。)

DDLに機密データ保護を含める: 生成されるDDL文に機密に関する情報を含めるかどうかを制御します。(『Oracle Databaseセキュリティ・ガイド』の透過的機密データ保護の使用に関する章の説明に従って、リダクションと透過的データ保護の概念および技術を理解する必要があります。)

PROMPTコマンドを含める(Oracleのみ): Oracle Databaseで生成されるDDL文において、各DDL文の前にPROMPTコマンドを含めるかどうかを制御します。各PROMPTコマンドによって、次の文に関する情報メッセージが表示され、スクリプト実行の出力を確認しているユーザーは、進行状況を追跡できます。

SQLフォーマット: SQL Developerフォーマッタを使用: SQLフォーマットでSQL Developerのデフォルトを使用するか、従来のData Modelerのデフォルトを使用するかを制御します。(このオプションをオンおよびオフにしてDDL生成を試行し、どちらのDDL出力が個人的な好みにより合っているかを調べることができます。)

デフォルトのDDLファイル・エクスポート・ディレクトリ: 生成されたDDLを、エクスポート操作のために配置するデフォルトのディレクトリ。

DDL: DDL/比較

比較で考慮すべき事項と無視すべき事項を指定できます。

比較機能に「データ型の種類」プロパティを使用: 異なる種類の型が同じネイティブ・データ型を生成しないように(たとえば、ドメインおよび論理型がNumber(7,2)にならないように)、データ型の種類(ドメイン、論理型、固有型など)を考慮する必要があるかどうかを制御します。

比較機能で「スキーマ」プロパティを使用: 2つのオブジェクトを比較するときに、オブジェクトと関連付けられているスキーマ名を考慮する必要があるかどうかを制御します。

比較機能で「列の順序」プロパティを使用: 2つの表を比較するときに列の順序を考慮する必要があるかどうかを制御します。

比較機能での大/小文字区別名: 2つのオブジェクトを比較するときに、オブジェクト名の大文字小文字を区別するかどうかを制御します。

比較機能にシステム名を含める: 2つの制約オブジェクトを比較するとき、システム生成の制約名(CREATE文やALTER文で制約名を指定しなかった場合に生成される)を考慮するかどうかを制御します。(特定の制約定義に対して2種類のシステムで生成される制約名は、ほぼ必ず異なります。)

DDL: DDL/記憶域

インポートおよびエクスポート操作で、DDLに含める記憶域オプションを指定できます。これらのオプションは、どの句およびキーワードが含まれるかに影響します。

記憶域オプションを含めると、より詳細なDDL文が作成されます。これにより、どのオプションが有効であるかが正確にわかり、必要な場合にそれをDDLで編集できます。記憶域オプションを含めないと、より簡潔なDDL文が作成されます(読みやすくなる可能性があります)。

関連項目

1.5.2.2 ダイアグラム

「ダイアグラム」ペインには、モデル・ダイアグラムの外観に影響を及ぼす一般的なオプションが含まれます。

一般: ツリーとの同期: オブジェクト・ブラウザのモデルにおけるオブジェクトの選択を反映するように、アクティブなダイアグラムへのフォーカスを自動的に移動させるかどうかを制御します。

一般: グリッド・サイズ:: グリッドを表示するとき、グリッドの点と点の間の相対距離を制御します。(点の単位は、Data Modelerが使用する内部的な座標系によって異なります。)

ダイアグラム: 論理モデル

論理モデルのダイアグラムに適用するオプションが含まれます。

表記法タイプ: 表記法タイプとして、Barker(烏の足とも呼ばれる)またはBachmanを指定します。

ボックス内のボックスにエンティティ継承を表示: スーパータイプのボックス内にあるボックスに、サブタイプを表示します。

ダイアグラム: リレーショナル・モデル

リレーショナル・モデルのダイアグラムに適用するオプションが含まれます。

外部キーの矢印方向: 外部キー・リレーションシップの矢印で、その先端が主キーまたは外部キーのいずれを指すかを制御します。

関連項目

1.5.2.3 モデル

「モデル」ペインには、数種類のモデルに適用されるオプションが含まれます。

デフォルトRDBMSタイプ: デフォルトのデータベース・タイプです。

デフォルトRDBMSサイト: デフォルトのデータベース・タイプ内のデフォルトのサイトです。

列および属性のデフォルト: NULLの許可: 新しい列と属性がNULL値を持つことができるかどうかを制御します。このオプションを無効にすると、新しい列と属性はデフォルトで必須になります(値が必要になります)。

外部キーのデータ型の互換性: 外部キーに類似のデータ型を許可する: 外部キー・リンクで、2つの列のデータ型が同じ(完全一致)である必要があるか、または単に互換性があればよいのかを制御します。このオプションが有効な場合、データ型は同じでも互換性ありのどちらでもよく、無効な場合は、データ型は同じである必要があります。たとえば、片方の列がNumberでもう片方がIntegerの場合、これらの列には互換性があります。文字データ列で最大長が異なる場合、これらの列には互換性があります。

優先ドメインと論理型: ドメインおよび論理型のドロップダウン・リストに表示される値を限定します。(この機能を使用すると、指定することのないようなドメインおよび論理型がリストに散乱しないようにできます。)ドメインまたは論理型をドロップダウン・リストに表示するには、「優先」側から「すべて」側へ移動します。

モデル: 論理

論理モデルに適用するオプションが含まれます。

リレーション・カーディナリティ: オプションのソース: リレーションシップのソース・エンティティにデフォルトで1つ以上のインスタンスを含める必要があるかどうかを制御します。このオプションが有効である場合、すべてのリレーションシップ・タイプにソース・インスタンスは必要なく、このオプションが無効である場合、すべてのリレーションシップ・タイプに1つ以上のソース・インスタンスが必要になります。

リレーション・カーディナリティ: オプションのターゲット: リレーションシップのターゲット・エンティティにデフォルトで1つ以上のインスタンスを含める必要があるかどうかを制御します。このオプションが有効である場合、すべてのリレーションシップ・タイプにターゲット・インスタンスは必要なく、このオプションが無効である場合、すべてのリレーションシップ・タイプに1つ以上のターゲット・インスタンスが必要になります。

リレーションシップを識別するための主キー・オプション: 最初の一意キーを主キーとして使用して設定: エンティティを作成するときに、最初の一意識別子の属性をデフォルトでプライマリ一意識別子にするかどうかを制御します。

FK属性名の同期: 元の属性の名前として維持する: スーパータイプまたは参照される属性が、一意識別子(外部キー)のネーミングに使用される必要があるかどうかを制御します。その他の名前を指定する場合は、このオプションを選択解除してください。

FK属性名の同期: コメント、ノート - PK属性から自動的に伝播する: 外部キー属性の定義で、参照されている主キー属性からコメントとノートを継承するかどうかを制御します。

デフォルトのサロゲート・キー設定: エンティティでサロゲート・キーを作成: エンティティに対してサロゲート主キーを作成するかどうかを制御します。関連付けられるエンティティに設定されている場合、サロゲート・キーを使用するリレーションシップに設定されている場合、あるいはエンティティに主キーがなくリレーションシップがそのエンティティを参照している場合、このオプションを有効にすると、新しいエンティティを作成する際のデフォルトで表がサロゲート主キーを取得します。

デフォルトのサロゲート・キー設定: リレーションシップでサロゲート・キーを使用: このオプションを有効にすると、新しいリレーションシップを作成する際のデフォルトで、特定の一意識別子に結び付くのではなく、サロゲート・キーを使用する(また、外部キー属性は維持しない)ように設定されます。

モデル: 物理

物理モデルに適用するオプションが含まれます。様々なオプションが、サポートされている各データベース・タイプに適用されます。

Oracleに対して、次の点を指定できます。

表のユーザーと表領域のデフォルト
表テンプレートまたは索引テンプレート(あるいはその両方)を使用するかどうか、使用する場合には表と索引を生成する際に使用するテンプレートのプロパティを設定します。
「自動増分列テンプレート」のオプション: トリガーおよび順序の名前(およびオプションで名前に追加する変数)と、自動増分とIDENTITYのDDL実装方法。

Oracle Databaseの表と索引のプロパティについては、『Oracle Database SQL言語リファレンス』でCREATE TABLE文とCREATE INDEX文を参照してください。

DB2に対して、いくつかのオプションにネーミング・ルールを指定し、入力したネーミング・ルール文字列に変数を追加できます。たとえば、「表ごとに表領域を作成」に、TBLS_と入力してから「変数の追加」をクリックして、{model}を選択すると、表の作成および名前の変更を行うたびに、対応する表領域がTBLS_+表名として作成または名前変更されます。

モデル: リレーショナル

リレーショナル・モデルに適用するオプションが含まれます。

外部キー列の削除方針: ユーザーがある表を削除しようとしたときに、その表を指す1つ以上の生成済外部キー列(他の表の列)が削除対象の表に含まれている場合、Data Modelerがどのような動作を行う必要があるかを指定します。指定する動作としては、外部キー列を削除する、外部キー列を削除しない、または外部キー列の削除について確認を求める、といった動作があります。

たとえば、「Data Modelerチュートリアル: 小規模データベースのモデリング」のリレーショナル・モデルを使用すると、Books表を削除する場合、Transactions表にはBooks表の主キーを参照するbook_id外部キー列が含まれています。このオプションの選択は、Books表を削除する場合に、Transactions.book_id列に対して何が行われるかを決定します。

デフォルトの外部キー削除ルール: 外部キー・リレーションシップに関与するデータが含まれる列を削除しようとしたときに何が行われるかを指定します。

アクションなし: 削除が許可されないことを示すエラー・メッセージが表示されます。削除はロールバックされます。
カスケード: 外部キー・リレーションシップに関与するデータが含まれるすべての列が削除されます。
NULLを設定: 表のすべての外部キー列がNULL値を受け入れることができる場合は、値をNULLに設定します。

エンジニアリング中の列の並替えを許可: このオプションを有効にした場合、表がリレーショナル・モデルにエンジニアリングされるときにData Modelerは関連付けられたエンティティの属性を並び替えることができます(たとえば、より重要だとみなされる属性を先頭に配置するなど)。(この動作は、多くの列が含まれる表の場合に特に役立ちます。)このオプションを有効にしない場合、エンティティの属性は関連付けられた列の表定義での順序と同じ順序で配置されます。

モデルがロードされるときにリモート・オブジェクトを同期: このオプションを有効にした場合、リモート・オブジェクト(別のモデルのオブジェクト)を現在のモデルのダイアグラムにドロップすると、リモート・オブジェクトに行われた可能性のある変更を反映するためモデルがロードされるたびに、リモート・オブジェクトの表示が変更(同期)されます。このオプションを有効にしない場合、ダイアグラム内のリモート・オブジェクトの表示は変更されません。

サロゲート列データ型: 表にサロゲート・キーが存在する場合、サロゲート列のデータ型(主キーでない一意キー)。

データベースの同期: ソース接続の使用: このオプションを有効にすると、ソース接続と宛先接続の名前が異なる場合に、同期にオブジェクトを含めるときのフィルタとしてデフォルトでソース接続が使用されます。(特定の同期操作ごとに個別に指定できます。)

データベースの同期: ソース・スキーマの使用: このオプションを有効にすると、ソース・スキーマと宛先スキーマの名前が異なる場合に、同期にオブジェクトを含めるときのフィルタとしてデフォルトでソース・スキーマが使用されます。(特定の同期操作ごとに個別に指定できます。)

データベースの同期: ソース・オブジェクトの使用: このオプションを有効にすると、ソース・オブジェクトと宛先オブジェクトの名前が異なる場合に、同期にオブジェクトを含めるときのフィルタとしてデフォルトでソース・オブジェクトが使用されます。(特定の同期操作ごとに個別に指定できます。)

データベースの同期: 全体スキーマの同期: このオプションを有効にすると、データベースに存在するがモデルに存在しないオブジェクトが、モデルをデータベースと同期する際には新しいオブジェクトとして表示され、データベースをモデルと同期する際にはデータベースから削除する候補として表示されます。このオプションを有効にしない場合は、モデルに存在するオブジェクトのみがデータベースと同期されます。

モデル: 物理同期

指定したデータベース・タイプの物理モデルを、それに関連付けられているリレーショナル・モデルと同期する際に適用されるオプションを含みます。

指定したオブジェクトのタイプごとに、変更を同期するかどうか(つまり、リレーショナル・モデルにおける指定したタイプのオブジェクトへの変更を、関連付けられた物理モデルに自動的に適用するかどうか)を指定できます。

関連項目

1.5.2.4 レポート

「レポート」ペインでは、レポートの生成時に適用されるオプションが含まれます。

会社名: レポートに表示する会社の名前。

オブジェクト間に改ページの挿入: レポートのオブジェクト間に改ページを挿入します。

ダイアグラムの埋込み(HTML): レポートにすべてのダイアグラムを埋め込みます。ダイアグラム内のオブジェクトをクリックすると、レポートにその詳細が表示されます。

メイン・ダイアグラムの埋込み(HTML): メイン・ダイアグラムのみをレポートに埋め込みます。

HTMLレポートの目次を別のファイルに生成: 目次を別ファイルにするように複数のファイルを生成します。このオプションはHTML形式のレポートのみに使用できます。

select文をビュー・レポートに含める: 問合せに使用したSQL文を含めて、ビューに基づいたレポートを生成します。

オブジェクトをスキーマ別にグループ化: 左側のペインにスキーマに基づいたグループでオブジェクトを表示します。このオプションを有効にしない場合、オブジェクトはアルファベット順で表示されます。

デフォルトのレポート・ディレクトリ: Data Modelerレポートを生成するデフォルトのディレクトリまたはフォルダです。ディレクトリを指定しない場合、デフォルトは、Data Modelerをインストールした場所の下のdatamodeler/reportsまたはdatamodeler\reportsです。たとえば、Windowsシステムでは、これはC:\Program Files\datamodeler\datamodeler\reportsとなります。

Saxon XSLT 2.0 JARファイルのパス: ファイルをダウンロード済で、レポートの生成にData Modelerでそのファイルを使用する場合のSaxon 2.0 XSLTプロセッサへのパスです(たとえば: C:\saxon9.3\saxon9he.jar)。このオプションを指定しない場合は、Data Modelerはレポートの生成にXSLT 1.0を使用します。一般的に、SaxonはXSLT 1.0よりサイズの大きいレポートの生成を処理できます。(Saxon XSLTプロセッサの詳細およびダウンロードは、http://saxon.sourceforge.net/に移動してください。)

1.5.2.5 検索

「検索」ペインには、オブジェクトの検索(検索)機能を使用するときの動作に影響を与えるオプションが含まれています。

[Enter]を押して検索: [Enter]を押したときに一致を返します(それまでに入力した検索文字列を反映)。

入力時に検索: 指定した最初の文字数の文字(記号)を入力した後に、一致を返します。入力を続けた場合、追加文字を入力するたびに一致が自動的に更新されます。

無視する初期記号の数: 入力時に検索について、一致候補が表示されるまでに入力できる文字数を指定します。(値が大きいほど、検索の初期一致候補のリストは短くなります。この機能は入力時に役立ちます。)

検索プロファイル: 検索プロファイルを追加および編集して、オブジェクトの検索時に考慮するリレーショナルおよび論理モデル・オブジェクトのプロパティ・セットを制限すると、少数のより有意義な一致が返される可能性があります。「追加」アイコンをクリックするか既存のプロファイル名をダブルクリックすると、「検索プロファイル」ダイアログ・ボックスが表示されます。

関連項目

オブジェクトの検索(検索)

1.5.2.6 サード・パーティJDBCドライバ

「サード・パーティJDBCドライバ」ペインでは、サード・パーティ(Oracle以外)のデータベースへの接続に使用されるドライバを指定します。Data Modelerでは、サード・パーティ・データベースからメタデータを獲得する場合など、一部の操作でJDBCドライバを使用する必要があります。

Oracleでは、Oracle以外のドライバを提供していません。(Javaに含まれている)ODBC/JDBC以外のドライバを使用する必要があるOracle以外のデータベースにアクセスするには、必要なドライバのファイルをダウンロードしてから、このペインを使用して追加する必要があります。ドライバをダウンロードする場合は、サード・パーティのサイトの適切なリンクを使用します。たとえば:

Microsoft SQLサーバーの場合: http://msdn.microsoft.com/en-us/data/aa937724.aspx
IBM DB2/LUW(IBM Data Server Driver for JDBC and SQLJ)の場合: https://www-01.ibm.com/software/data/db2/linux-unix-windows/downloads.html

追加するドライバごとに、「追加」(+)アイコンをクリックして、ドライバのパスを選択します。

関連項目

1.5.3 フォーマット

「フォーマット」ペインは、生成されるSQLスクリプトで文がフォーマットされる方法を制御します。オプションでは、[Tab]キーを押したときに空白文字とタブ文字のどちらを挿入するか(および挿入する文字数)、キーワードおよび識別子の大/小文字、空白行を保持するか削除するか、および比較する項目を同じ行と別の行のどちらに配置するかを指定できます。

「拡張書式設定」サブペインを使用すると、より詳細な書式設定オプションを指定できます。また、次のオプションも含まれます。

現在の設定でプレビュー: 左側で変更を指定すると、右側のプレビュー領域で変更が反映されます。
自動検出フォーマッタの設定: 必要な書式設定を含むコードを右側のプレビュー・ペインに貼り付けると、SQL Developerでは貼り付けた内容を反映するように左側で設定を調整します。(自動的に設定プリファレンスが検出されます。)

これらの設定はコード・スタイル・プロファイルのXMLファイルにエクスポートしたり、エクスポートしたコード・スタイル・プロファイル・ファイルから設定をインポートできます。

「カスタム・フォーマット」サブペインでは、書式設定をさらにカスタマイズできます。これらの設定はカスタム・フォーマッタ・プログラムのXMLファイルにエクスポートしたり、エクスポートしたカスタム・フォーマッタ・プログラム・ファイルから設定をインポートすることもできます。

関連項目

1.5.4 無視するファイルのリスト

「無視するファイルのリスト」ペインでは、あらゆる処理で使用しないファイルおよびファイル・タイプを決定するフィルタを指定します。

新規フィルタ: (フィルタが有効になっている場合や選択されている場合に)Data Modelerがすべての処理で無視する、(「フィルタ」ボックスの)ファイルおよびファイル・タイプのリストに追加するファイル名またはファイル・タイプ。mumble.txtなど、完全なファイル名を入力して特定のファイルを除外するか、または*.txtなど、ファイル・タイプを示す構成要素を入力して同じタイプのすべてのファイルを除外することもできます。

追加: 新しいフィルタを「フィルタ」ボックスのリストに追加します。

削除: 選択したフィルタを「フィルタ」ボックスのリストから削除します。

デフォルトに戻す: 「フィルタ」ボックスの内容をData Modelerのデフォルトに戻します。

フィルタ: ファイルおよびファイル・タイプのリストを含みます。各項目が有効な(選択されている)場合は、フィルタが適用され、ファイルまたはファイル・タイプはData Modelerによって無視されますが、無効な(選択解除されている)場合は、フィルタは適用されません。

関連項目

1.5.5 マウス・アクション

「マウス・アクション」ペインでは、関連するオブジェクト名にマウスが置かれたときに表示するテキストを指定します。

ポップアップ名: 表示する情報のタイプで、「データ値」(変数の値など、マウス・ポインタの下のアイテムの値)、「ドキュメント」(メソッド・コールに関するJavadocなど、マウス・ポインタの下のアイテムに関するドキュメント)または「ソース」(メソッドのソース・コードなど、マウス・ポインタの下のアイテムのソース・コード)があります。

次の方法でアクティブ化: マウス・カーソルによる処理(ホバーまたは指定した1つまたは2つの修飾キーを押しながらのホバー)を使用して表示をアクティブ化します。

説明: 関連する「ポップアップ名」エントリの説明。

スマート対応: このオプションを選択すると、「スマート・ポップアップ」も選択されている場合、関連するタイプの情報のテキストが表示されます。

スマート・ポップアップ: このオプションを選択すると、マウスが置かれた項目に対する最初のスマート対応ポップアップに関連するテキストが表示されます。

関連項目

Data Modeler

1.5.6 ショートカット・キー(アクセラレータ・キー)

「ショートカット・キー」ペインを使用すると、ショートカット・キー(アクセラレータ・キーとも呼ぶ)・マッピングをData Modeler用に表示およびカスタマイズできます。

アンマップ・コマンドの非表示: このオプションを選択すると、マッピングのあるショートカット・キーのみが表示されます。

その他のアクション:

エクスポート: ショートカット・キー定義をXMLファイルにエクスポートします。
インポート: 以前にエクスポートしたXMLファイルからショートカット・キー定義をインポートします。
キーボード・スキームのロード: 現在のすべてのショートカット・キー・マッピングを削除し、指定したスキームでマッピングを設定します。(このオプションは、以前のリリースでは「初期設定のロード」と呼ばれていました。)マッピングを変更し、デフォルトの設定をリストアする場合は、「デフォルト」を選択します。

カテゴリ: 特定のカテゴリ(「コード・エディタ」、「比較」など)にグループ化されたコマンドおよびショートカットをリストし、表示するアクションを制御します。

コマンド: 指定されたカテゴリに関連するアクションです。アクションを選択すると、既存のショートカット・キー・マッピングが表示されます。

ショートカット: 選択したアクションの既存のキー・マッピング。既存のキー・マッピングを削除するには、削除するキー・マッピングを選択して「削除」をクリックします。

新しいショートカット: アクションに関連付ける新しいショートカット・キー。目的の修飾子キーを押しながら、もう一方のキーを押します。たとえば、[Ctrl]キーと[J]キーをアクションに関連付けるには、[Ctrl]キーを押しながら[J]キーを押します。そのショートカット・キーになんらかのアクションが現在関連付けられている場合、「現在の割当て」ボックスに表示されます。

競合: 「新しいショートカット」ボックスで指定したショートカット・キーにマップされている現在のアクション(ある場合)の読取り専用表示。

関連項目

1.5.7 SSH (セキュア・シェル)

SSHプリファレンスはSSH (セキュア・シェル)接続の作成に関連します。

既知のホスト・ファイルの使用: このオプションを選択した場合は、使用する既知のホスト・ファイルを指定します。

関連項目

1.5.8 使用状況レポート

SQL Developer、Data Modeler、その他一部のアプリケーションでは、「使用状況レポート」のユーザー・プリファレンスおよび関連ダイアログ・ボックスで、Oracle使用状況に同意するかどうかを確認されます。同意すると、使用中の製品機能を記述した自動レポートが時折オラクル社に送られます。個人情報が送信されることはなく、レポートによって性能が左右されることはありません。プライバシ・ポリシーのリンクをクリックすると、オラクル社のプライバシー・ポリシーが表示されます。

Oracleへの自動使用状況レポートの許可: 使用状況レポートに同意するかどうかを決定します。

関連項目

1.5.9 バージョニング

「バージョニング」プリファレンスは、Data Modelerで使用できるバージョン制御および管理システムの動作に影響します。Data Modelerによるバージョニングの使用の詳細は、「バージョニングの使用」を参照してください。

「バージョニング: Git」ペインでは、Gitバージョン・コントロール・システムで使用するオプションが導入されます。

バージョニング: Git: コメント・テンプレート

「Git: コメント・テンプレート」ペインでは、コミット操作で使用するコメントのテンプレートを指定します。コメント・テンプレートは、追加、編集および削除することができ、テンプレートをXMLファイルにエクスポートしたり、以前にエクスポートしたテンプレートをインポートすることもできます。

バージョニング: Git: 一般

「Git: 一般」ペインでは、環境設定を指定します。

ナビゲータで状態オーバーレイ・アイコンを使用: このオプションを有効にすると、状態オーバーレイ・アイコンが使用されます。状態オーバーレイ・アイコンは、ナビゲータのオブジェクト名に関連付けられた小さいシンボルです。バージョン制御されたファイルの状態(最新など)を示します。

ナビゲータで状態オーバーレイ・ラベルを使用: このオプションを有効にすると、状態オーバーレイ・ラベルが使用されます。状態オーバーレイ・ラベルは、ナビゲータのオブジェクト名に関連付けられたツールチップです。

作業用コピーのコミット時に自動的に新規ファイルを追加: このオプションを有効にすると、個々のファイルをコミットするたびに、作業用コピーで作成した新規ファイルはすべてGitリポジトリに自動的に追加されるようになります。それ以外の場合は、変更をコミットしたときに新規ファイルが追加されないので、引き続き新規ファイルを明示的にGitに追加する必要があります。

ログ・ウィンドウにメッセージを書込み: このオプションが有効化された場合、Gitのメッセージは「メッセージ-ログ」ウィンドウに書き込まれます。(ウィンドウが表示されない場合は、「表示」→「ログ」をクリックして表示します。)

バージョニング: Git: バージョン・ツール

「Git: バージョン・ツール」ペインで、「変更のコミットおよび追加送信」ダイアログ・ボックスのオプションを指定します。

変更のコミットおよび追加送信時にダイアログを使用: 「保留中の変更」ウィンドウが開いているときに、制限のある画面領域を最適に使用できます。「保留中の変更」ウィンドウの「コメント」領域を表示させないことで画面領域を節約できますが、それでもコミット・アクションの前にコメントを追加する必要がある場合もあります。「変更のコミットおよび追加送信」ダイアログの開き方(常に開くのか、「保留中の変更」ウィンドウの「コメント」領域が非表示の場合のみ開くのか、開かないのか)を選択できます。

バージョニング: Subversion

「Subversion」ペインでは、Data Modelerで使用するSubversionクライアントを指定します。

バージョニング: Subversion: コメント・テンプレート

「Subversion: コメント・テンプレート」ペインでは、コミット操作で使用するコメントのテンプレートを指定します。たとえば、テンプレートには、次のようなテキストが含まれる場合があります。

Problem Description (with bug ID if any):
Fix Description:

コメント・テンプレートは、追加、編集および削除することができ、テンプレートをXMLファイルにエクスポートしたり、以前にエクスポートしたテンプレートをインポートすることもできます。

バージョニング: Subversion: 一般

「Subversion: 一般」ペインでは、環境設定および操作タイムアウトを指定します。

作業用コピーのコミット時に自動的に新規ファイルを追加: このオプションを有効にすると、個々のファイルをコミットするたびに、作業用コピーで作成した新規ファイルはすべてSubversionリポジトリに自動的に追加されるようになります。それ以外の場合は、変更をコミットしたときに新規ファイルが追加されないので、引き続き新規ファイルを明示的にSubversionに追加する必要があります。

svn:needs-lockプロパティを持つファイルをチェックアウト後に自動的にロック: このオプションを有効にした場合、リポジトリからチェックアウトしたファイルは自動的にロックされ、ファイルがリリースされるまで他のメンバーがそのファイルをチェックアウトできないようにします。

Subversionのマージにマージ・ウィザードを使用: このオプションを有効にした場合、マージ・リクエストに対してマージ・ダイアログではなく、マージ・ウィザードが呼び出されます。

操作タイムアウト: Subversion操作の完了までに許容される最大秒数、最大分数または最大時間数。

Subversion構成ファイルの編集: 直接Subversionファイルを変更するには、「"server"の編集」をクリックします。プロキシ・ホスト、プロキシ・ポート、タイムアウト、圧縮など、サーバー固有のプロトコル・パラメータや他の値を変更できます。#で始まる行は、コメントとして解釈されます。

バージョニング: Subversion: バージョン・ツール

「Subversion: バージョン・ツール」ペインでは、保留中の変更ウィンドウおよびマージ・エディタのオプションを指定します。

変更のコミット送信時にダイアログを使用: 「保留中の変更」ウィンドウが開いているときに、制限のある画面領域を最適に使用できます。「保留中の変更」ウィンドウの「コメント」領域を表示させないことで画面領域を節約できますが、それでもコミット・アクションの前にコメントを追加する必要がある場合もあります。「コミット」ダイアログの開き方(常に開くのか、「保留中の変更」ウィンドウの「コメント」領域が非表示の場合のみ開くのか、開かないのか)を選択できます。

受信変更タイマー・インターバル: ファイルの変更ステータスがチェックされる頻度。

エディタのマージ: ローカルまたはサーバーでファイルをマージするかどうかを指定します。

関連項目

バージョニングの使用

Data Modeler

1.5.10 Webブラウザとプロキシ

「Webブラウザとプロキシ」の設定は、更新の確認機能(「ヘルプ」→「更新の確認」をクリック)を使用する際に、システムがファイアウォールで保護されている場合にのみ関係します。

Webブラウザ

更新の確認操作で使用可能なWebブラウザおよびデフォルトのブラウザを表示します。「デフォルト」の下をクリックしてデフォルトのブラウザを変更できます。

それぞれのブラウザについて、デフォルトにするかどうかを決定でき、名前を表示して、オプションで名前、そのブラウザの実行可能ファイルへのパス、アプリケーション・コマンド・パラメータおよびアイコンを変更できます。

プロキシ設定

更新の確認操作用に、プロキシなし、システムのデフォルト・プロキシ設定または手動で指定するプロキシ設定を選択できます。手動で指定する設定の場合は、Webブラウザのオプションまたはプリファレンスの該当するフィールドに適切な値が設定されているかどうかをチェックします。

インターネット・ファイル

更新の確認操作でインターネットのCookieを有効にするかどうか選択します。

すべてのCookieのクリア: 既存のクッキーをすべて削除します。

関連項目

1.6 設計の保存、オープン、エクスポートおよびインポート

作業中の設計(または設計の一部)を格納する場合は、保存またはエクスポートを実行できます。

設計を保存すると、設計のすべての要素(論理モデル、リレーショナル・モデル、物理モデル、プロセス・モデルおよびビジネス情報)を保存できます。XMLファイルおよびディレクトリ構造(「データベース設計」を参照)は、新しい設計では作成され、既存の設計では更新され、設計は、Data Modeler形式で格納されています。

設計を保存するには、「ファイル」→「保存」をクリックします。事前に設計が保存されていない場合は、場所およびXMLファイル名を指定します。別のファイルおよびディレクトリ構造で設計を保存するには、「ファイル」→「別名保存」をクリックします。
設計をエクスポートすると、設計の一部(論理モデル、物理モデル以外のリレーショナル・モデル、およびデータ型モデル)をファイルに保存できます。エクスポートは、Oracle以外およびOracleの様々な形式で行うことができます。このように、エクスポートすることで、出力形式に柔軟性がもたらされますが、Data Modelerの出力のみが必要な場合は、保存することで、より多くの設計オブジェクトを保存できます。

設計をエクスポートするには、「ファイル」→「エクスポート」→「出力形式」をクリックします。

保存された設計を使用するには、「ファイル」→「開く」をクリックすると開くことができます。設計を開くと、保存された設計のすべてのモデルおよびオブジェクトが使用できるようになります。保存された物理モデルは、最初はオブジェクト・ブラウザには表示されませんが、目的のリレーショナル・モデルで物理モデルを右クリックして「開く」を選択し、データベース・タイプ(Oracle 11gなど)を指定すると、物理モデルを表示できます。

Data Modelerで保存された設計、または別のデータ・モデリング・ツールでエクスポートまたは保存された設計を使用する場合は、「ファイル」→「インポート」をクリックし、インポートする設計のタイプを指定すると、インポートできます。通常、ファイルを指定してから、インポートの対象を制御できるウィザードを使用します。

開いたり、インポートするテキスト・ファイルは、オペレーティング・システムのロケール設定でサポートされている形式でエンコードされている必要があります。文字のエンコーディングおよびロケールの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

次の各項では、特定のタイプのファイルおよび他のソースからのインポートについて説明します。

関連項目

DDLファイルのインポート

Microsoft XMLAからのインポート

ERwinファイルのインポート

データ・ディクショナリからのインポート

Oracle Designerモデルのインポート

Data Modeler設計のインポート

ドメインのインポート

エクスポートするモデル/サブビューの選択 (「エクスポート」>「Data Modeler設計へ」を選択した場合)

1.6.1 DDLファイルのインポート

DDLファイルをインポートすると、既存のデータベース実装に基づいたリレーショナル・モデルを作成できます。元になるDDLファイルとして、サポートされているすべてのデータベース・タイプおよびバージョンのものが可能です。インポートされるファイルには、通常、.ddlまたは.sqlの拡張子があります。

インポート・プロセスでは、インポートされるDDLファイルの名前で新しいリレーショナル・モデルが作成され、ソース・サイトを反映した物理モデルが開きます。

1.6.2 Microsoft XMLAからのインポート

Microsoft XMLAからインポートすると、Microsoft XMLAファイル形式で格納される多次元モデルを作成できます。

1.6.3 ERwinファイルのインポート

ERwinファイルをインポートすると、ERwinモデリング・ツールからモデルを取得できます。インポートするモデルの定義が含まれるXMLファイルを指定します。

1.6.4 データ・ディクショナリからのインポート

データ・ディクショナリからのインポートを行うと、既存のデータベース実装に基づいたリレーショナル・モデルおよび物理モデルを作成できます。元になるデータ・ディクショナリとして、サポートされているすべてのデータベース・タイプおよびバージョンのものが可能です。

データ・ディクショナリからインポートするウィザードでは、既存のデータベース接続を選択するか、新しいデータベース接続を作成(追加)する必要があります。その後で、指示に従って、スキーマまたはデータベースを選択し、さらにインポートするオブジェクトを選択します。

データ・ディクショナリからインポートした後、必要に応じてリレーショナル・モデルおよび物理モデルを編集できます。また、リレーショナル・モデルから論理モデルをリバース・エンジニアすることができます。

1.6.5 Oracle Designerモデルのインポート

Oracle Designerモデルをインポートすると、既存のOracle Designerモデルに基づいたリレーショナル・モデルおよび物理モデルを作成できます。Oracle Designerリポジトリへの接続を作成し、エンティティ、表およびドメインをDesignerのワークスペースからインポートできます。

Oracle Designerモデルのインポートウィザードでは、既存のデータベース接続を選択するか、新しいデータベース接続を作成(追加)する必要があり、その後で、指示に従って、作業領域、アプリケーション・システムおよびインポートするオブジェクトを選択します。(Oracle Designer dataflowダイアグラムをインポートすることはできません。)

Oracle Designerモデルをインポートした後、必要に応じてリレーショナル・モデルおよび物理モデルを編集できます。また、リレーショナル・モデルから論理モデルをリバース・エンジニアすることができます。

1.6.6 Data Modeler設計のインポート

Data Modeler設計をインポートすると、以前にData Modelerからエクスポートした設計から、論理モデル、リレーショナル・モデルおよびデータ型モデルを取得できます。

1.6.7 ドメインのインポート

ドメインをインポートすると、既存のドメイン定義を変更および拡張できます。「ドメインのインポート」ダイアログ・ボックスで、インポートするドメインを選択したり、インポートしないドメインを選択解除(クリア)します。

1.7 プリファレンスおよびその他の設定のエクスポートおよびインポート

次のData Modeler情報をエクスポートおよびインポートできます。

ユーザー・プリファレンス(「Data Modelerのユーザー・プリファレンス」を参照)
データ・ディクショナリからのインポート用に作成した接続などの接続(「データ・ディクショナリ・インポート(メタデータ抽出)」を参照)
最新の設計(「ファイル」→「最新の設計」をクリックすると表示されます)

この情報をエクスポートするには、「ツール」→「プリファレンス」→「Data Modeler」をクリックしてから「エクスポート」をクリックします。後で現在のインストールを削除した場合にファイルが失われる可能性があるため、Data Modelerをインストールした場所の下のディレクトリまたはフォルダ指定しないでください。

前にエクスポートされた情報をインポートするには、「ツール」→「プリファレンス」→「Data Modeler」をクリックしてから「インポート」をクリックします。

1.7.1 元のData Modelerプリファレンスのリストア

Data Modelerのプリファレンスに行った変更をすべて元のデフォルト値にリストアする場合は、次のステップに従います。

Data Modelerが実行中の場合は、終了します。
Data Modelerのユーザー情報が格納されているフォルダまたはディレクトリを削除します。デフォルトの場所は、ビルド固有のディレクトリまたは次の下のフォルダです。
- Windowsの場合: C:\Documents and Settings\<user-name>\Application Data\Oracle SQL Developer Data Modeler
- LinuxまたはMac OSの場合 X: ~/.datamodeler
たとえば、現在のビルド固有フォルダの名前がsystem3.1.0.678の場合、C:\Documents and Settings\<user-name>\Application Data\Oracle SQL Developer Data Modeler\system3.1.0.678を削除します。
Data Modelerを起動します。

これによって、ユーザー情報が格納されるフォルダまたはディレクトリ(ステップ2で説明済)が、Data Modelerのインストール時と同じ内容で作成されます。

ショートカット・キー(アクセラレータ・キー)のマッピングに変更を加えた場合は、「ツール」、「プリファレンス」、「ショートカット・キー」、「その他のアクション」、「キーボード・スキームのロード」の順にクリックした後で「デフォルト」を選択すると、マッピングをシステムのデフォルトに戻すことができます。

1.8SQL Developer Webを使用したダイアグラムの共有

SQL Developer Webで作成されたData Modelerダイアグラムは、表OSDDMW_DIAGRAMSに格納されます。「保存」を初めてクリックするのは、この表が接続スキーマに作成されるときです。

接続が提供されている場合、Data Modelerデスクトップ・バージョンはOSDDMW_DIAGRAMS表からインポートまたはエクスポートできます。エクスポート時に表が接続スキーマに存在しない場合、表が作成されます。インポートおよびエクスポート機能は、リレーショナル・ダイアグラムのコンテキスト・メニューから使用できます。

インポート時にダイアグラムのスタイルは影響を受けません。

空のリレーショナル・モデル・ダイアグラム・ウィンドウで右クリックし、コンテキスト・メニューから「データベースからダイアグラムをインポート」を選択します。
「データベースからダイアグラムをインポート」ダイアログで、「JDBC接続」に対してドロップダウン・リストからデータベース接続を選択し、ダイアグラムの取得をクリックします。指定した接続に関連付けられたダイアグラムが、下のグリッドに表示されます。特定のダイアグラムをフィルタ処理して検索できます。

チェックが実行され、ダイアグラム内のオブジェクトがモデルに存在するかどうかが検証されます。それ以外の場合、ダイアグラム・レコードにカーソルを置くと、欠落しているオブジェクトのリストがポップアップ・テキストに表示されます。欠落した表およびビューがモデルにインポートされます。

図1-2 SQL Developer Webからのダイアグラムのインポート

「図1-2 SQL Developer Webからのダイアグラムのインポート」の説明
ダイアグラムを1つ以上選択し、「OK」をクリックしてダイアグラムとオブジェクトをインポートします。

同様に、SQL DeveloperからSQL Developer Webにダイアグラムをエクスポートできます。リレーショナル・モデル・ダイアグラム・ウィンドウで、右クリックしてダイアグラムをデータベースにエクスポートを選択します。「JDBC接続」で、ドロップダウン・リストからデータベース接続を選択し、ダイアグラムの取得をクリックします。エクスポートするダイアグラムを選択して「OK」をクリックします。1つ以上のダイアグラムをアップロードした後、SQL Developer Webのダイアグラム・ナビゲータをリフレッシュします。

ノート:

スキーマに存在しない1つ以上の表を含むダイアグラムをアップロードすると、SQL Developer Webに空のボックスとして表示されます。

1.9 PDFへのダイアグラムの印刷

ダイアグラムをPDF形式で印刷するには、次の2つの方法があります。

「ファイル」メニューから「印刷」を選択します。「印刷」ダイアログで、「PDFに出力」チェック・ボックスを選択します。

または
「ファイル」メニューから「ダイアグラムの印刷」を選択し、「PDFファイルへ」を選択します。「ダイアグラムの印刷」サブメニューは、論理モデルおよびリレーショナル・モデルのダイアグラムのコンテキスト・メニューでも使用できます。

オペレーティング・システムに応じて、データ・モデラーは次のTrueTypeフォントを探して使用します。

Windows: C:/Windows/Fonts/Arial.ttf
Mac OS: /Library/Fonts/Arial Unicode.ttf
Linux: /usr/share/fonts/dejavu/DejaVuSans.ttfまたは/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf

Data Modelerインストールのdatamodeler\datamodeler\binディレクトリにあるdatamodeler.confファイル(またはSQL Developerインストールのsqldeveloper\sqldeveloper\binディレクトリにあるsqldeveloper.confファイル)にカスタムtruetypeフォントを設定できます。

たとえば:

AddVMOption -Ddatamodeler.pdf.font=/usr/share/fonts/unifont.ttf

1.10 Data Modelerレポート

次の方法でData Modelerオブジェクトにレポートを表示できます。

ローカル・ドライブにHTMLファイルとしてレポートを生成し、自動的に開くこともできます。詳細は、レポートの生成を参照してください。
Data Modelerレポート・リポジトリを使用して、SQL Developerを使用してエクスポートしたレポートを表示します。詳細は、「レポート・リポジトリおよびレポート・スキーマの使用」および「SQL Developerを使用したエクスポートされたレポート・スキーマ・データの表示」を参照してください。

1.10.1 レポートの生成

個々のレポートをHTMLファイルとして保存でき、各レポートは作成時に自動的に開いたときに表示できるほか、後で表示するためにファイルを開くこともできます。HTMLでは、いくつかの個別のファイルが生成されます。ファイルは「Data Modeler」プリファレンスの下の「デフォルトのレポート・ディレクトリ」で指定された場所またはデフォルトの場所に格納されます。

Data Modelerは、各ファイルに一意の名前を確保します(たとえば、すべての表でレポートを生成した場合にAllTablesDetails_1.htmlがすでに存在すると、AllTablesDetails_2.htmlが作成されます)。(レポート・スキーマのレポート・リポジトリからレポート・ファイルを生成する場合、ファイル名には、_rsが含まれます(たとえば、AllTablesDetails_1_rs.html)。)

次のいずれかのアプローチを使用してレポート・ファイルを生成できます。

現在ロードされている設計に基づいてレポートを生成します。(この方法には、レポート・スキーマおよびレポート・リポジトリの作成または使用は含まれていません。)
レポート・スキーマのレポート・リポジトリ(「レポート・リポジトリおよびレポート・スキーマの使用」で説明されています)の情報に基づいてレポートを生成します。

HTML、XLSまたはXLSX形式で格納されているレポートを生成および表示するには、次のステップに従います。

「ファイル」→「レポート」をクリックします。
「一般」タブの「使用可能なレポート」で、表、エンティティ、ドメイン、用語集などの情報をレポートするオブジェクトのいずれかのタイプを選択します。
「出力形式」で、標準テンプレートの場合はHTMLのみがサポートされます。カスタム・テンプレートの場合はHTML、XLSまたはXLSXを選択します。
「レポート・タイトル」にレポートの名前を入力します。
レポート・ファイル名にレポート・ファイルの名前を入力します。
「オプション」については、「レポート」を参照してください。
「テンプレート」の下で、オプションとして使用するレポート・テンプレートを選択します。レポート・テンプレートを使用して、レポートに含めるオブジェクトのタイプをカスタマイズできます。以下のタブを使用することができます。
- 標準: デフォルトの標準レポート形式を使用する場合は空白のままにし、標準を変更した形式が存在し使用できる場合にはそれを選択します。標準のレポート・タイプを作成および管理するには、「管理」をクリックして、「レポート・テンプレート管理」ダイアログ・ボックスを表示します。
- カスタム: 高度にカスタマイズしたレポート形式を指定できます。カスタマイズした新しい形式を作成する、または選択した既存の形式を編集するには、「管理」をクリックして「レポート・テンプレート管理」ダイアログ・ボックスを表示します。
  
  カスタム・レポートの場合は、「ブール値の置換」でデフォルト以外の真偽値を選択できます。
「オブジェクト」タブをクリックします。
(必要なタブがまだ選択されていない場合)次のいずれかのタブをクリックします。
- ロードされた設計: 1つ以上の現在ロードされたData Modeler設計に基づいてレポートを生成します
- レポート・スキーマ: レポート・スキーマのレポート・リポジトリの設計に基づいてレポートを生成します
使用可能な設計で、必要なData Modeler設計を選択します。
「使用可能なモデル」で、必要なモデルを選択します。(モデルのリストは、レポートのオブジェクトのタイプを反映しています。)
「レポート構成」で、選択した「使用可能なレポート」タイプの特定のサブビューまたは特定のオブジェクトにレポートを制限する構成を選択するか、または空白のままにして、「使用可能なレポート」タイプのすべてのサブビュー(ある場合)とすべてのオブジェクトを選択することができます。

「管理」をクリックして「標準レポート構成」ダイアログ・ボックスを表示することにより、構成を追加、削除または変更できます。
「レポートの生成」をクリックします。

レポートの場所およびファイル名付きのメッセージが表示されます。
ファイルに移動し、開きます。

関連項目

1.10.2 レポート・リポジトリおよびレポート・スキーマの使用

Data Modelerのレポート・リポジトリは、Data Modelerの設計に関するメタデータおよびデータを格納するデータベース・スキーマ・オブジェクトのコレクションです。レポート・リポジトリが格納されているスキーマは、レポート・スキーマと呼ばれます。

Data Modelerレポート・スキーマを設定するには、Data Modelerインタフェース以外で次のステップを実行します。

レポート・リポジトリを保持するデータベース・スキーマを作成または指定します。

Data Modelerのレポート・リポジトリ用に個別のデータベース・ユーザーを作成し、そのスキーマをレポート・リポジトリにのみ使用することをお薦めします。たとえば、DM_REPORT_REPOSという名前のユーザーを作成し、そのユーザーに少なくともCONNECTおよびRESOURCE権限を付与します。(別の目的で使用されている既存のスキーマにレポート・リポジトリを作成することもできますが、それを把握し続けることが困難になる場合があります。)

Data Modelerの旧バージョンからのレポート・リポジトリを使用し続ける場合は、datamodeler\datamodeler\reportsフォルダのReporting_Schema_Upgrade_readme.txtファイルを参照してください。
Reporting_Schema_Permissions.sqlスクリプト・ファイルを編集および実行します(datamodeler\datamodeler\reportsフォルダにあります)。

スクリプトの実行前にファイルを編集し、<USER>および<OS DIRECTORY>を必要な値で置き換えます。
- <USER>は、レポート・リポジトリを保持するスキーマです。
- <OS DIRECTORY>は、データベースを実行しているコンピュータ上の一時ファイル・システム・フォルダ(ディレクトリ)です。定義はスクリプトによりデータベースに作成されますが、スクリプトの実行後にこのフォルダを作成する必要があります。

Data Modelerを起動して、次のステップを実行します。

「ファイル」→「エクスポート」→「レポート・スキーマへ」をクリックします。
「レポート・スキーマにエクスポート」ダイアログ・ボックスで、「接続の追加」(+)アイコンをクリックします。
データベース接続の新規作成/更新ダイアログ・ボックスで、接続の名前(たとえば、dm_reporting_repos_conn)および接続のその他の情報(レポート・スキーマに関連付けられているデータベース・ユーザーのユーザー名とパスワードを含む)を入力します。
オプションで、「テスト」をクリックして、接続をテストします。(テストに成功しなかった場合は、エラーを修正します。)
「OK」をクリックし、接続を作成して、データベース接続の新規作成/更新ダイアログ・ボックスを閉じます。
ダイアログ・ボックスの上部の接続のリストで、接続名を選択(クリック)します。
「OK」をクリックして、選択した接続に関連付けられているスキーマにレポート・リポジトリを作成して、選択したモデルに関する情報をそのリポジトリにエクスポートします。

Data Modelerレポートを表示するには、「SQL Developerを使用したエクスポートされたレポート・スキーマ・データの表示」の説明に従ってSQL Developerを使用します。

既存のレポート・リポジトリを削除するには、Data Modelerで次のステップに従います。

「ファイル」→「エクスポート」→「レポート・スキーマへ」をクリックします。
レポート・リポジトリに関連付けられているスキーマの削除対象の接続を選択します。
「レポート・スキーマにエクスポート」ダイアログ・ボックスで、「メンテナンス」タブをクリックします。
「リポジトリの削除」をクリックして、レポート・リポジトリを削除することを確認します。

リポジトリ全体ではなく、リポジトリ内の選択した設計のみを削除する場合、「設計の削除」をクリックして、削除対象の設計を選択します。

「レポート・スキーマにエクスポート」ダイアログの「用語集」タブを使用して、用語集に対して次の操作を実行できます。

用語集のエクスポート: Data Modelerの用語集ファイルを指定して、その情報をレポート・リポジトリにエクスポートします。
用語集の削除: レポート・リポジトリで用語集を選択して、リポジトリからその情報を削除します。

ノート:

Data Modelerレポートに関するその他の詳細な技術情報は、datamodeler\datamodeler\reports\Reports_Info.txtを参照してください。

関連項目

1.10.3 SQL Developerを使用したエクスポートされたレポート・スキーマ・データの表示

Oracle SQL Developerのレポート機能を使用して、Data Modelerレポート・リポジトリにエクスポートされた情報を表示できます。設計に関する情報をレポート・リポジトリにエクスポートするには、「レポート・リポジトリおよびレポート・スキーマの使用」の指示に従います。

SQL Developerでレポートを表示するには、次の手順を実行する必要があります。

SQL Developerで、レポート・ナビゲータに「データ・モデラー・レポート」という子ノードがすでに含まれているかを確認します。そのノードが含まれている場合、次のステップに進み、そのノードが含まれていない場合は、次のステップに従ってData Modelerレポートの拡張機能をインストールします。

「ヘルプ」→「更新の確認」をクリックします。「更新の確認」ウィザードで、「ローカル・ファイルからインストール」を指定して、次のData Modelerをインストールした場所datamodeler\reports\oracle.sqldeveloper.datamodeler_reports.nn.nn.zip (Windowsシステムの場合)またはdatamodeler/reports/oracle.sqldeveloper.datamodeler_reports.nn.nn.zip (Linuxシステムの場合)(nn.nnはビルド番号を示します)のローカル・ファイルを指定します。
SQL Developerで「レポート」ナビゲータを開き、「データ・モデラー・レポート」ノードを展開します。必要に応じて、そのノードの下のノードをさらに展開します。

表示するレポートごとに、次の手順を実行します。

レポート名に対応するノードをダブルクリックします。
レポート・リポジトリに使用したデータベース接続を選択します。
「バインド変数」ダイアログ情報を入力して、「OK」をクリックします。バインド変数の場合、そのデフォルト値では最も一般的なケースが示され、最新のバージョンの設計に使用可能なすべての情報が表示されます。

バインド変数を使用すると、出力を制限できます。ほとんどのバインド変数のデフォルト値はNULLで、これは、追加の制限を設定しないことを意味します。バインド変数を指定するには、変数名を選択して、「値」フィールドにエントリを入力します。入力するバインド変数値は、大/小文字が区別されます。バインド変数値には、特殊文字として、任意の文字列を意味する%(パーセント記号)および任意の文字を意味する_(アンダースコア)を含めることができます。

Data Modelerレポートは、次のカテゴリにグループ化されています。

「設計内容」レポートは、設計内容(設計内のオブジェクト)に関する情報をリストします。

「設計ルール」レポートは、論理モデルおよびリレーショナル・モデルに適用される場合の設計ルールに関する情報をリストします。

1.10.3.1 「設計内容」レポート

「設計内容」レポートは、設計内容(設計内のオブジェクト)に関する情報をリストします。

データ型モデル: データ型モデルに関連するレポートが含まれます。

論理モデル: 論理モデルに関連するレポートが含まれます。

リレーショナル・モデル: リレーショナル・モデルに関連するレポートが含まれます。

関連項目

1.10.3.2 「設計ルール」レポート

「設計ルール」レポートは、論理モデルおよびリレーショナル・モデルに適用される場合の設計ルールに関する情報をリストします。(「設計ルール」ダイアログ・ボックスに関する情報を参照してください。)

論理モデル: 論理モデルに関連するレポートが含まれます。

リレーショナル・モデル: リレーショナル・モデルに関連するレポートが含まれます。

関連項目

SubversionおよびData Modelerについて

1.11 バージョニングの使用

Data Modelerでは、Data Modeler設計でのSubversionのバージョニングおよびソース制御システムの使用を統合的にサポートしています。設計をSubversionリポジトリに格納して、次のような通常のバージョン制御を実現します。

正式版の設計を、様々なフォルダやディレクトリではなく中央リポジトリに格納します。
複数の開発者が同じ設計で作業できるようにします(従来のSubversionのチェックアウトおよびコミット・プロセスを使用して、変更を調整します)。

Data Modelerのドキュメントでは、SVN概念および操作について理解しているか、確認できることを前提としているため、その詳細を説明しません。Subversionのドキュメントについては、http://svnbook.red-bean.com/を参照してください。

Data Modelerリリース19.2以降では、Data ModelerはData Modeler設計でGitバージョニングを使用するGitクライアントを提供しています。Gitの詳細は、http://git-scm.com/を参照してください。

Data Modelerのバージョニング機能にアクセスするには、「チーム」メニューを使用します。

バージョニング・リポジトリを作成するか、既存のリポジトリに接続する場合は、「バージョン」ナビゲータのリポジトリの階層表示およびその内容を使用できます。(ナビゲータが表示されない場合は、「チーム」→「バージョン」をクリックします。)

関連項目

基本的なワークフロー: 設計でのSubversionの使用

図global_ignore_list.gifの説明

Data ModelerでのGitの使用

1.11.1 SubversionおよびData Modelerの概要

Data Modelerを介してSubversionリポジトリを使用するには、Subversionリポジトリへの接続を作成する必要があります。ローカルのSubversionリポジトリを作成すると、そのリポジトリへの接続が自動的に作成されて、「バージョン」ナビゲータに表示できます。これによって、接続の詳細を編集できるようになります。

既存のファイルをバージョン管理の対象にするには、「Subversion」リポジトリにそれらのファイルをインポートする必要があります。その後、ファイルは「Subversion」リポジトリからローカル・フォルダ(「Subversion作業用コピー」と呼ぶ)にチェックアウトされます。Data Modelerに作成されたファイルは、Subversion作業用コピーに格納する必要があります。

Data Modeler内に新しく作成されたファイルは、バージョン制御に追加する必要があります。変更されたファイルおよび新しいファイルは、Subversionリポジトリに対してコミットされると、他のユーザーも利用できるようになります。Subversion作業用コピーは、Subversionリポジトリの内容を反映して更新し、他のユーザーによる変更を取り込むことができます。

1.11.1.1 保留中の変更

「保留中の変更」ウィンドウは、「表示」→「保留中の変更」をクリックするか、ローカル・ソース・ファイルの制御状態が変更される操作を開始した場合に表示されます。このウィンドウには、(ローカルまたはリモートで)追加、変更または削除されたファイル、他バージョンの同じファイルと内容が競合するファイル、監視対象のソース制御ファイルに追加されていないファイル、およびエディタを取得したファイルが表示されます。この情報を使用して競合を検出し、可能であれば解決できます。

「送信の変更」ペインにはローカルで行われた変更が、「受信の変更」ペインにはリモートで行われた変更が、「候補」ペインにはローカルで作成され、ソース制御に追加されていないファイルが表示されます。ファイル名をダブルクリックすると、ファイルを編集できます。コンテキスト・メニューを使用すると、使用可能な操作を実行できます。

1.11.2 基本的なワークフロー: 設計でのSubversionの使用

Data Modelerの設計でSubversionを使用するには、次のものが必要です。

設計の作業ディレクトリとして機能するローカル・システム上のフォルダまたはディレクトリ。この作業ディレクトリで設計を作成して、この作業ディレクトリに設計を保存して、この作業ディレクトリから設計を開きます。
接続が可能で、初回バージョンの設計(と後続のあらゆるバージョン)のブランチであるbranchesの下に作成できるSubversionリポジトリ。

推奨の基本ステップは次のとおりです。これらは、特定のプロジェクトに対して実行できる唯一のステップではなく、必ずしも最適なステップではない場合もあります。これらのステップでは、多数のアクションを実行するためにData Modelerでのバージョン・ナビゲータおよびインポート・ウィザードの使用が反映されていますが、これらのアクションは、個別のSVNリポジトリ・ブラウザ(TortoiseSVNブラウザなど)を使用しても、ローカル・システムでSVNコマンドを使用しても実行できます。

ローカル・システムで、設計固有の作業ディレクトリの親として機能するディレクトリまたはフォルダを作成します。たとえば、Windowsコンピュータで次を作成します。
```
C:\designs
```
ローカル・システムで、前述のステップで作成したディレクトリまたはファイルの下に、作成する設計の作業ディレクトリとして機能するディレクトリまたはファイルを作成します。たとえば、libraryという名前の設計用に、次を作成します。
```
C:\designs\library
```
Data Modelerで、設計を作成して(たとえば、「Data Modeler チュートリアル: 小規模データベースのモデリング」のライブラリの設計)、その設計を作成した作業ディレクトリに保存します。たとえば、次の場所に設計を保存します。
```
C:\designs\library
```
設計を保存すると、作業ディレクトリに.dmdファイルおよび関連するディレクトリ構成が作成されます。.(.dmdファイルおよびディレクトリ構造は、「データベース設計」で説明されています。)
設計を閉じます。(Data Modelerを終了しないでください。)
使用するリポジトリにSVN接続を作成します。
1. バージョン・ナビゲータで、最上位ノード(Subversion)を右クリックして、「新規リポジトリ接続」を選択します。
2. Subversion: Subversion接続の作成/編集ダイアログ・ボックスに情報を入力します。リポジトリURLの例: https://example.com/svn/designs/
リポジトリ・パスの下にbranchesディレクトリを作成します。
1. バージョン・ナビゲータで、リポジトリ・パスを右クリックして、「新規リモート・ディレクトリ」を選択します。
2. 「Subversion: リモート・ディレクトリの作成」ダイアログ・ボックスで、情報を入力して、「ディレクトリ名」としてbranchesを指定します。
branchesディレクトリの下にプロジェクト固有のブランチを作成します。
1. バージョン・ナビゲータで、branchesディレクトリを右クリックして、「新規リモート・ディレクトリ」を選択します。
2. 「Subversion: リモート・ディレクトリの作成」ダイアログ・ボックスに情報を入力します。ディレクトリ名の例: library
  
  たとえば、「Data Modelerチュートリアル: 小規模データベースのモデリング」でライブラリ・デザインの作成を予定している場合、このブランチのリポジトリのURLは次のようになります。
```
https://example.com/svn/designs/branches/library
```
「Subversion: Subversionへのインポート」ウィザードを使用して、設計ファイルをリポジトリへインポートします。「チーム」→「ファイルのインポート」をクリックして、ウィザード・ページを次のように入力します。
1. 宛先: SVN接続およびファイルをインポートするリポジトリ・パスを指定します。例: root/branches/library
2. ソース: ファイルをインポートするソース・ディレクトリ(つまり.dmdファイルおよび設計固有のフォルダ階層を含むディレクトリ)を指定します。例: C:\designs\library
3. フィルタ: デフォルトを受け入れて「次へ」をクリックします。
4. オプション: デフォルトを受け入れて「次へ」をクリックします。
5. サマリー: 情報を表示して、「終了」をクリックします。
  
  SVNコンソール・ログには、ファイルの追加時の進行状況が表示されます。ファイルを追加すると、「新規ファイルの処理」ダイアログ・ボックスが表示されます。
6. 「新規ファイルの処理」ダイアログ・ボックスで、「ファイルを開かない」を選択して、「OK」をクリックします。
7. 追加されたファイルを表示するには、「バージョン・ナビゲータ」タブの「リフレッシュ」アイコンをクリックします。

設計の後続の作業では、Subversionベースのプロジェクト(SVNの更新、SVNのロック、ファイルの変更、SVNのコミット)の通常のワークフローに従います。

1.11.3 Data ModelerでのGitの使用

Gitを初めて使用する場合は、「チーム」メニューから「Gitに接続」を選択します。Gitからのクローニング・ウィザードが表示され、Gitリポジトリを新しく作成されたローカル・ディレクトリにクローニングできます。このウィザードの詳細は、Git: Gitからのクローニングを参照してください。

Gitリポジトリをクローニングしても、「バージョン」ナビゲータ(「バージョン」ナビゲータを表示するには、「チーム」→「バージョン」を選択します)には自動的に表示されません。「表示」をクリックしてから「ファイル」を選択し、「ファイル」ナビゲータを開く必要があります。ローカル・リポジトリのパスを参照して選択します。ローカル・ディレクトリを選択すると、「バージョン」ナビゲータのGitノードにリモート・リポジトリの構造が表示されます。

または、Gitでバージョニングされた設計が開いている場合、Gitリポジトリは「バージョン」ナビゲータに表示されます。

リモート・ファイルが変更されたときにローカル・リポジトリとリモート・リポジトリの間で変更を同期するには、「チーム」→「Git」メニューから「フェッチ」を選択して、現在のブランチを変更せずにリモート・リポジトリからローカル・システムに変更をコピーします。変更を表示するには、「チーム」→「Git」メニューから「ブランチ比較」を選択します。変更内容を表示したり、ローカル・リポジトリに変更をマージするには、「マージ」オプションを使用します。

ローカル・システムでファイルが変更されると、そのファイルは「保留中の変更」ウィンドウ(「チーム」→「Git」)に表示されます。「保留中の変更」ウィンドウには、ステージング領域へのファイルの追加、以前のバージョンとのファイルの比較、ローカル・リポジトリでのファイルへの変更のコミットなどのオプションがあります。ローカル・リポジトリとリモート・リポジトリを同期するには、「プッシュ」オプションを使用して変更をリモート・リポジトリにプッシュします。

関連項目

Git: 保留中の変更

1.11.3.1 Gitワークフロー

Gitワークフローは、少なくとも1つのリモート・リポジトリおよび1つのローカル・リポジトリに基づいています。

ローカル・リポジトリには、3つの異なる仮想領域があります。

作業領域: これは、新しいファイルが作成される場所、古いファイルが削除される場所、または既存のファイルに変更が加えられる場所です。その後、作業領域でのこれらの変更がステージング領域に追加されます。
ステージング領域(索引とも呼ばれます): ステージング領域には、コミットする必要がある1つ以上のファイルが含まれています。ステージング領域は、すべてのファイルのコンテンツのスナップショットです。ファイルがステージング領域に追加された後に変更された場合、変更はコミットに含まれません。そのファイルはステージング領域に再度追加する必要があります。コミット時に、Gitは変更されたソースをステージング領域から取得してコミットします。
コミット領域: ステージング領域でコミットが実行されると、ファイルはコミット領域に移動します。コミットはリモート・リポジトリにプッシュでき、他のコントリビュータによって導入されたリモート・リポジトリ内の変更はローカル・リポジトリにプルできます。

作業領域に新しいファイルが作成された場合、それは追跡されていないファイルであり、バージョニングの候補です。そのファイルはステージング領域に追加する必要があります。このようなファイルにRevertコマンドが適用されると、そのファイルは再び追跡されない(バージョニングされていない)状態になります。

ノート:

Data Modelerは、常に新規および変更されたオブジェクトをステージング領域に追加します。オブジェクトの一部の変更をステージングし、他の変更をステージングしないということはできません。ステージング領域に追加された新しいオブジェクトにRevertコマンドを使用すると、デザインおよびファイル・システムからそのオブジェクトが削除されます。

1.11.3.2 計画

単一のリポジトリに配置する設計の数を決定する必要があります。ここでは、設計の依存性(ある設計のオブジェクトが他の設計で使用されること)、設計内のオブジェクトの数、設計が変更される頻度、およびコントリビュータの数など、様々な要因が考慮されます。

設計がバージョン管理の対象になっている場合、システム・データ型ディレクトリもバージョン管理の対象に追加する必要があります。デフォルトの場所は、インストール時のdatamodeler\datamodeler\typesです。

次の例では、設計とシステム・データ型ディレクトリが1つのリポジトリに置かれています。

1.11.3.2.1 リポジトリの設定

次に、Windows 7オペレーティング・システムでリポジトリを設定する例を示します。

次のステップを開始する前に、最初にGitをインストールして構成する必要があります。

Git Bashウィンドウで、プッシュとプルをサポートするリモート・リポジトリとして使用するリポジトリを作成します。

$ git init --bare local_des.git

D:/git-tests/bare_repo/local_des.Git/内の空のGitリポジトリが初期化されます。
リモート・リポジトリのクローンを作成します。
- 「チーム」メニューから「Git」を選択し、次に「クローン」を選択します。「Gitからのクローニング」ウィザードが表示されます。
- リモート・リポジトリ・ページで、リモート名およびリポジトリの場所(D:/git-tests/bare_repo/local_des.git/)を入力します。実際のリモート・リポジトリには、認証情報を入力します。
- リモート・ブランチ・ページで、クローンを作成するブランチを指定します。この例では、リポジトリは空です。Gitハブを使用してリモート・リポジトリをホストする場合、クローン操作の前に、リポジトリに少なくとも1つのファイルが必要です。
- 宛先ページで、ローカル・ファイル・システムの場所を入力します。
ノート:
クローン・ウィザードの最後に「新規ギャラリ(データベース接続)」ダイアログが表示された場合は、無視します。

1.11.3.2.2 Git管理下へのシステム・データ型ディレクトリの追加

システム・データ型ディレクトリをGit管理下に追加する方法は2つあります。

「プリファレンス」で設定を変更することにより事前に変更したり、設計がGit管理下に置かれたときに変更することもできます。後者の場合、システム・データ型ディレクトリがバージョニングされたディレクトリの下にあるかチェックされ、そうでない場合は、Git管理下に追加するオプションが提供されます。

ローカル・リポジトリの作業領域にディレクトリを作成する必要があります。

「プリファレンス」ダイアログでディレクトリを設定するには、左ペインでData Modeler」を選択します。Data Modelerペインで、「デフォルトのシステム・タイプ・ディレクトリ」フィールドにディレクトリを選択するか入力します。「OK」をクリックします。

「初期コミット・コメント」で、コメントが指定されていない場合、Data ModelerはディレクトリがGit管理下に追加されたというコメントを追加します。

現在のシステム・データ型ディレクトリから必要なファイルが、ディレクトリの場所(この例では、local_des)にコピーされ、ステージング領域に追加され、コミットされます。

1.11.3.3 Git管理下への設計の追加

単純なモデルを作成してGit管理下に追加するには、次の操作を実行する必要があります。

まず、作業領域にモデルを保存します。続いて、設計をバージョン管理の対象にするように求めるプロンプトが表示されます。受け入れられた場合、ダイアログが表示されて初期コメントを設定でき、設計はGit管理下に追加されます。設計構造には、バージョン管理の対象への追加が禁止されているファイル(拡張子がlocal、-、*、.localのファイル)があります。これが、.gitignoreファイルが設定されている理由です。これは存在しない場合に作成され、「無視するファイルのリスト」の内容が追加されます。

.gitignoreファイルを設定すると、design.dmdファイルおよび設計ディレクトリがステージング領域に追加されてコミットされます。

ノート:

設計は、別のツールまたはコマンドライン・インタフェースを使用してバージョン管理の対象に追加できますが、最初に.gitignoreファイルを設定する必要があります。ファイル内に次の行が存在している必要があります。

**/*.local

次の図に、ファイル・システム(作業領域)を示します。

図working_area_file_system.gifの説明

現時点でファイルが存在しないため、ディレクトリfilesはバージョン管理の対象になっていません。ユーザー定義のプロパティを使用してダイアグラムやライブラリに追加された画像は、filesに格納されます。また、任意のコンテンツ(ディレクトリに編成)を配置でき、バージョン管理の対象にされます。

1.11.3.4 Gitツール

このセクションには次のトピックが含まれます:

1.11.3.4.1 Gitコマンドへのアクセス

Gitコマンドにアクセスするには、「チーム」メニューから「Git」を選択します。コマンドは、現在のコンテキスト、選択されているオブジェクトまたはファイル、およびそのステータスに基づいて使用できます。

コマンドが使用できない場合もあります。たとえば、コミット後に「保留中の変更」にリストされている変更がない場合、プッシュ・コマンドは使用できません。このような場合は、Gitでバージョニングされた設計のダイアグラムをクリックすると、ほとんどすべてのコマンドが使用可能になります。

1.11.3.4.2 保留中の変更

保留中の変更リスト

「保留中の変更」ペインの下部にある2つのタブは次のとおりです。

候補: 作業領域に追加されているが、追跡されていない(ステージング領域に追加されていない)ファイルを表示します。
送信: 変更されたオブジェクトのステータス(「変更済」、「削除済」、競合)、およびステージング領域に対する関係(「ステージングされて変更済」またはステージングされて変更済およびインスタンスに対して変更済)を表示します。

開いている設計に属しているオブジェクトについては、次の内容が表示されます。

名前: オブジェクトの名前とアイコン。名前の上にカーソルを置くと、ファイル・パスが表示されます。
場所:オブジェクトが属するモデルがシンプルに表されたものです。場所の上にカーソルを置くと、ディレクトリ・パスが表示されます。
ステータス: オブジェクトのGitステータス。

次の項目でソートできます。

場所: オブジェクトは、それらが属するモデルでソートされます。
名前: オブジェクトが変更されたモデルを確認します。

「有効範囲」コンボ・ボックス

「有効範囲」コンボ・ボックスには、「保留中の変更」リストに表示される内容を決定するオプションがリストされます。

システム・データ型ディレクトリまたは特定の設計: 選択した設計の変更のみを表示します。

<すべてのアプリケーション>: バージョン・ナビゲータに表示されるすべてのリポジトリの変更内容を表示します。

<アクティブ・アプリケーション>: 現在の設計の変更内容を表示します。

オブジェクトとして比較

「XMLメタデータ・コンパレータ」ダイアログを使用すると、「前のバージョンと比較機能が使用されている場合にオブジェクトを表示できます。設計またはファイル内のオブジェクトをドメインで比較するときに機能します。「保留中の変更」および「コミット履歴」のコンテキスト・メニューから使用できます。

ノート:

SQL Developerでは、オブジェクトとして比較機能は使用できません

設計が開いている場合、設計はアクティブになり、その設計の変更が表示されます。複数の設計が開いている場合は、ダイアグラムをクリックすると設計がアクティブになり、その設計の変更が表示されます。

ノート:

「有効範囲」コンボ・ボックスはSQL Developerに表示されず、「保留中の変更」はモード<すべてのアプリケーション>でのみ機能します。

1.11.3.4.3 ファイル機能

ファイル機能を使用してローカル・ファイル・システムを参照し、バージョニング済のディレクトリに対してバージョニング操作を実行できます。この機能にアクセスするには、「表示」メニューから「ファイル」を選択します。参照中に検出されたGitリポジトリは、バージョン・ナビゲータにも表示され、「有効範囲」コンボ・ボックスの設定に応じて、「保留中の変更」リストに変更が表示されます。

次の図では、設計gtest1が開かれておらず、「保留中の変更」の「名前」と「場所」がローカル・ファイル・システムのファイルのような表を表示しています。

図files_versioning.gifの説明

1.11.3.4.4 バージョン・ナビゲータ

バージョン・ナビゲータはGitリポジトリを表示し、ブランチの作成および削除、ブランチのチェックアウト、マージ、フェッチ、および退避された変更の作業領域への適用を可能にします。バージョン・ナビゲータにアクセスするには、「チーム」メニューから「バージョン」を選択します。

設計が開かれると、バージョン・ナビゲータにそのリポジトリが表示されます。設計が閉じられた後も、リポジトリはナビゲータ内にあります。その後、別のブランチをチェックアウトして、設計を再度開くことができます。

図versions_navigator.gifの説明

1.11.3.5 設計の変更 - ブランチとマージ

このセクションには次のトピックが含まれます:

1.11.3.5.1 変更とコミット

gtest1では、設計は作成済で、設計とシステム・データ型ディレクトリが1つのリポジトリにあるため、リポジトリはData Modelerの起動時にバージョン・ナビゲータに表示されます。そのため、設計を開いて閉じる必要はありません。新しいブランチを作成して(demoという名前を付けて)チェックアウトできます。今度は、ブランチ・デモで設計を開きます。

次の変更が導入されます。

table_1に列を追加しました
table_2を削除しました
table_3の列にコメントを追加しました

設計を保存します。変更は「送信の変更」に表示されます。変更をコミットします。

図git_commit_1.gifの説明

設計を閉じてブランチ・マスターをチェックアウトし、設計を再度開きます。次の変更が追加されます。

table_1に列を追加しました
table_2に列を追加し、PKにしました
table_3にコメントを追加しました(表レベルです。ブランチのデモでは、マージの競合が発生しないように列レベルでコメントが追加されました)。

設計を保存して変更をコミットします。「コミット」ダイアログでは、コミットの一部の変更を除外できます。

1.11.3.5.2 変更を元に戻す

コミット前

変更がコミットされる前に、Revertコマンドを使用して変更を元に戻すことができます。

コマンドにアクセスするには、次の操作を実行します。

「チーム」メニューから「Git」を選択し、次に「元に戻す」を選択します。
「保留中の変更」のオブジェクト行のコンテキスト・メニューからコマンドを選択します。

「元に戻す」ダイアログが表示され、元に戻されるオブジェクトが表示されます。

操作の結果、オブジェクトは以前の状態に戻ります。つまり、新しい変更はすべて破棄されます。

ノート:

Data Modelerの実装は、ステージング領域に追加された新しいファイルに対する標準のGit Revertコマンドの動作方法と異なります。標準のGit Revertコマンドは、ステージング領域からファイルを削除し、そのファイルを追跡されていないとしてファイル・システムに残します。Data Modeler実装のRevertは、設計からオブジェクトを削除し、関連するファイルをファイル・システムから削除します。

コミット後

変更がコミットされた後、Revert Commitコマンドを使用して変更を元に戻すことができます。コマンドにアクセスするには、「チーム」メニューから「Git」」を選択し、次に「コミットの回復」を選択します。このコマンドが使用できない場合(「送信の変更」にオブジェクトがない場合)は、Gitでバージョニングされた設計のダイアグラムをクリックして使用可能にします。

1.11.3.5.3 ブランチ

設計はブランチ・マスター内にあるため、バージョン・ナビゲータでブランチ・デモを右クリックし、コンテキスト・メニューから「マージ」を選択します。「マージ」ダイアログが表示され、ブランチ・デモが選択されています。

このダイアログでは、ブランチ、タグまたは単一のコミットを選択できます(後者の場合はチェリーピック)。「OK」をクリックしてマージを続行します。2つの表にマージの競合があることを示す通知が表示され、「保留中の変更」ペインに変更とマージの競合が表示されます。

図after_merging.gifの説明

メイン・ダイアグラムは、table_2がブランチのデモで削除されたため、変更されました。table_2がマスターに存在し、これも変更されたため、競合が発生しています。table_1も競合します。これは、両方のブランチに同じ変更(列の追加)が適用されたためです。

1.11.3.6 競合の解決

Data Modelerでの処理

Data Modelerには、競合に対する特別な処理があります。

次の図は、別のツールでマージが行われた場合、またはGitコマンドのMergeを使用した場合のTable_1のXMLファイルの外観を示しています。

図merge_conflict_1.gifの説明

これにより、ファイルはXMLの観点から無効になります。この結果、競合しているファイルで提供されたオブジェクトはロードされず、依存性がある場合、他のオブジェクトで問題が発生する可能性があります。これを防ぐために、Data Modelerは、マージ前のファイルのコンテンツを保持します。

また、設計が開いているときは、まず壊れたファイルがないかをチェックされ、有効なコンテンツで修正します。設計がロードされた後、既存の競合が存在する場合には、競合を解決するオプションを提供するダイアログが表示されます。

「はい」をクリックした後、「マージ競合」ダイアログが、オブジェクト、ステータス(競合の理由)、およびそれを解決するための可能な方法とともに表示されます。

図merge_conflicts_dialog.gifの説明

ステータス(競合の理由)は次のいずれかである可能性があります: 両方とも「追加済」、両方とも「削除済」、両方とも「変更済」、「彼らによって削除済」(自分側によって変更済 - Table_2の場合のように)、「私たちによって削除済」(相手側によって変更済)。「両方とも削除済」タイプの競合は自動的に解決されます。

競合の解決

競合の編集: ファイルがオブジェクトとして認識される場合、(両方のブランチの)コンテンツはオブジェクトとして表示され、変更のマージが向上します。

図edit_conflict_object.gifの説明

ファイルのコンテンツがオブジェクトとして認識されない場合は、「競合をテキストとして編集」機能が使用されます。

競合をテキストとして編集: ファイルの2つのバージョンが、右側が編集可能なプレーン・テキストとして比較されます選択したコンテンツを右側から削除でき、必要に応じて左から右のペインにコンテンツを追加できます。

図edit_conflict_text.gifの説明

次の図では、適切な処理は、コンテンツを左から右のペインにコピーすることです。

図edit_conflict_text_2.gifの説明

競合は「マージ」(オブジェクトとして編集する場合)または「OK」(テキストとして編集する場合)をクリックすることで解決され、オブジェクトの行はダイアログから削除されます。ただし、設計は更新されません。更新は、「マージ競合」ダイアログで「OK」をクリックすると完了します。その後、すべての変更が、影響を受けるすべての開いている設計に正しい順序で適用されます。たとえば、最初に新しいドメインが作成され、そのドメインを使用する新しい列が後で作成されます。

「ローカル・バージョンの使用」または「リモート・バージョンの使用」を使用して競合を解決する場合は、いずれかのブランチのコンテンツ全体が取得されます。

Git機能は、どの設計にも属さないファイルであっても、Data Modeler拡張機能がロードされた後、SQL Developerで同じように機能します

競合の解決後のコミット

競合がある場合、リポジトリは特別なステータスになります。すべての競合を解決した後、すべての変更をコミットする必要があります。

図commit_after_resolve.gifの説明

「コミット」ダイアログの形式は異なります。オブジェクトのリストはなく、リポジトリ全体がコミットされます。この例では、Table_2はすでにコミットされているため、「保留中の変更」にリストされていません。

1.11.3.7 コミット履歴

「コミット履歴」ウィンドウを使用して、変更の履歴を追跡できます。「チーム」メニューから、「Git」を選択し、「送信の変更」の中のオブジェクトまたはファイルにフォーカスがある場合、またはGitでバージョニングされた設計のダイアグラムにフォーカスがある場合、「コミット履歴」を選択します。

「...のコミット履歴の表示中」チェック・ボックスがクリアされている場合、リポジトリ全体の「コミット履歴」が表示されます。Git設計のダイアグラムにフォーカスを置くと、設計ディレクトリのコミット履歴が表示されます。

図commit_history_1.gifの説明

また、ブランチおよびタグのコミット履歴も追跡できます。

オブジェクト・プレゼンテーションが、設計のオブジェクトを前のバージョンと比較する場合に使用されます。これはSQL Developerでは機能しません。

図commit_history_2.gifの説明

1.11.3.8 リモート・リポジトリへの変更のプッシュ

「プッシュ」コマンドの場合、「チーム」メニューから「Git」を選択し、次に「プッシュ」を選択します。最後のコミット後、「送信の変更」には何も表示されず、「プッシュ」コマンドは「チーム」→「Git」メニューでは使用できません。これを修正するには、バージョニングされた設計のダイアグラムをクリックすると、コマンドを使用できるようになります。

1.11.3.9 ドメインの変更

デフォルト・ドメインまたは設計レベル・ドメインが追加または変更されて設計に使用されると、すべての開いている設計が更新されます。これは特に、システム・データ型ディレクトリが設計と同じリポジトリに存在する場合に当てはまります。別個のリポジトリに存在する場合、まずそのリポジトリでプルまたはマージを実行し、プルまたはマージの操作後に設計を再度開く必要があります。

1.11.3.10 ロギング

Git操作はすべて「メッセージ・ログ」ペインに記録されます。追加、削除、変更されたオブジェクトおよび競合しているオブジェクトの詳細も、プル、マージおよびチェリーピックの操作について記録されます。

図logging_1.gifの説明

1.12 データ・モデリングについての詳細な情報

データ・モデリングの詳細(高度な資料など)は、次の情報を参照してください。

Data Modelerの「開始」ページには、チュートリアル、オンライン・デモ、ドキュメントおよびその他のリソースのリンクが含まれます。このページには2つのタブ「はじめに」および「コミュニティ」があります。(「開始ページ」タブが表示されない場合は、「ヘルプ」から「開始ページ」をクリックしてください)。
ホワイト・ペーパー、ビューレット(画面デモンストレーション)、Oracle by Example(OBE)チュートリアルおよびその他の資料へのリンクが含まれるSQL Developerのホームページ(OTN): http://www.oracle.com/technetwork/developer-tools/sql-developer/
Object Management Group (OMG)のサイト(http://www.omg.org/)(特に、MetaObject Facility(MOF、http://www.omg.org/mof/)およびCommon Warehouse Metamodel(CWM、https://www.omg.org/spec/CWM/)仕様)
『United States Coast Guard Data Element Naming Standards Guidebook』 (http://coastguardinstructions.tpub.com/CI_5230_42A/)(特にネーミング標準に関連する概念および推奨事項)

関連項目