| Oracle® SQL Developer Data Modelerユーザーズ・ガイド リリース3.1 B66840-01 |
|
 前 |
 次 |
SQL Developer Data Modeler(Data Modelerとも呼ばれる)は、メタデータの取得、モデリング、管理および利用のための環境を提供するデータ・モデリングおよびデータベース設計のツールです。
この章の内容は次のとおりです。
1.1「SQL Developer Data Modelerのインストールおよび起動」
1.2「Data Modelerのユーザー・インタフェース」
1.5「Data Modelerのユーザー・プリファレンス」
1.6「設計の保存、オープン、エクスポートおよびインポート」
1.7「プリファレンスおよびその他の設定のエクスポートおよびインポート」
SQL Developer Data Modelerをインストールして起動するには、SQL Developerの手順と同様に、.zipファイルをダウンロードして任意の親ディレクトリまたは親フォルダに解凍し、コマンドを入力するか、またはファイル名をダブルクリックします。次の手順を実行する前に、Data Modelerのリリース・ノートまたは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章「Data Modelerチュートリアル: 小規模データベースのモデリング」の簡単なチュートリアルを実行します。(高度なチュートリアルなど、他の資料については1.11「データ・モデリングの追加のリソース」を参照してください。)
Data Modelerウィンドウでは、基本的に、左側はオブジェクトを検索して選択するためのナビゲーション、右側は選択したオブジェクトに関する情報の表示に使用されます。
図1-1に、メイン・ウィンドウを示します。
次の図に示すとおり、上部のメニューには、標準的なエントリと、Data Modeler固有の機能のエントリが表示されます(1.2.1「Data Modelerのメニュー」を参照)。
ショートカット・キーを使用して、メニューおよびメニュー項目にアクセスできます。たとえば、[Alt]キーを押しながら[F]キーを押すと「ファイル」メニュー、[Alt]キーを押しながら[E]キーを押すと「編集」メニュー、[Alt]キーを押しながら[H]キーを押し、次に[Alt]キーを押しながら[S]キーを押すと、「ヘルプ」の「検索」にアクセスできます。[F10]キーを押して「ファイル」メニューを表示することもできます。
メニューの下にあるアイコンでは、現在選択されウィンドウ右側に表示されているもの(論理モデル、リレーショナル・モデル、データ・フロー・ダイアグラムなど)に関連するアクションを実行します。たとえば、リレーショナル・モデルの場合のアイコンには、「新規の表」、「新規ビュー」、「表の分割」、「表のマージ」、「新規FK関連」および「DDLの生成」があります。アイコンの名前を参照するには、アイコンの上にポインタを置きます。また、アイコンに対応するアクションは、 「オブジェクト」メニューからも実行できます。
次の図に示すとおり、Data Modelerウィンドウの左側には、データ・モデリング・オブジェクトを階層ツリーで表示するオブジェクト・ブラウザがあります。
オブジェクト・ブラウザでオブジェクトを選択するには、適切なツリー・ノードを開いてオブジェクトをクリックします。
次の図に示すとおり、Data Modelerウィンドウの右側には、ユーザーが選択したり開いたオブジェクトのためのタブとペインがあります。ここには、ライブラリ関連データについて、意図的に簡略化したリレーショナル・モデル(第2章「Data Modelerチュートリアル: 小規模データベースのモデリング」で生成されたモデル)の情報が表示されます。
他のオブジェクトに切り替えるには、該当するタブをクリックし、タブを閉じるには、該当するタブのXをクリックします。オブジェクトを変更してから「X」をクリックすると、変更を保存するかどうかを尋ねられます。
ここでは、Data Modelerで特に重要なメニュー項目について説明します。
「ファイル」メニュー
開く: 保存またはエクスポートされているData Modelerの設計を開きます。詳細は、1.6「設計の保存、オープン、エクスポートおよびインポート」を参照してください。
閉じる: Data Modelerを終了せずに、現在の設計を閉じます。
インポート: 様々なソースからモデルをインポートできます。詳細は、1.6「設計の保存、オープン、エクスポートおよびインポート」を参照してください。
エクスポート: 様々なデータ・モデル・ツールにインポートできるファイルにモデルをエクスポートできます。詳細は、1.6「設計の保存、オープン、エクスポートおよびインポート」を参照してください。
印刷: 現在選択されているダイアグラムを印刷します。
ダイアグラムの出力: 現在選択されているダイアグラムを保存します。その形式は、指定したファイル拡張子に関連付けられたタイプのイメージ・ファイル(.pngまたは.jpg)、PDFファイルまたはscalable vector graphics(.svg)ファイルです。
最新の設計: 最近作業したData Modeler設計を開くことができます。
「編集」メニュー
非表示の外部キー・リレーションシップに関連するオプションが含まれます。
検出された外部キーの作成: リレーショナル・モデルで検出された非表示の外部キー・リレーションシップを表示します。(3.16「検出された外部キーの作成」を参照してください。)
検出された外部キーの削除: 検出された外部キーをリレーショナル・モデル図から削除します。
「表示」メニュー
Data Modelerインタフェースに表示される内容を指定するオプションが含まれます。
ブラウザ: データ・モデリング・オブジェクトを階層ツリー形式で表示する、オブジェクト・ブラウザを表示します。
ナビゲータ: 現在ウィンドウの右側で選択されているビューをグラフィカルなサムネイル表現で表示します。
ログ: 「ログ」ペインにData Modelerのアクションの記録を表示します。
詳細の表示: 表示について、その詳細レベルを制御します。
論理ダイアグラム表記法: 論理モデルの表示にBarkerまたはBachmanのどちらの表記法を使用するのかを制御します。
DDLファイル・エディタ: 選択した物理モデルに対してDDL文を生成します。「DDLファイル・エディタ」ダイアログ・ボックスが表示されます。(このコマンドは、リレーショナル・モデルが選択されているときに「DDLの生成」アイコンをクリックするか、「オブジェクト」、「リレーショナル」、「DDLの生成」の順にクリックすることと同等です)
ズーム・イン(および対応するアイコン): 現在選択されているダイアグラムを詳細に表示します。表示されるオブジェクトは少なくなります。
ズーム・アウト(および対応するアイコン): 現在選択されているダイアグラムを概略的に表示します。表示されるオブジェクトは多くなります。
画面に合わせる(および対応するアイコン): 関連するすべてのオブジェクトを現在選択されているダイアグラムのウィンドウに合わせ、必要な場合は輪郭およびテキスト・ラベルの大きさを調節します。
検索: 現在選択されているダイアグラム内のオブジェクトを検索するためのダイアログ・ボックスを表示します。大きく複雑なダイアグラムでオブジェクトを検索するのに役立ちます。
「バージョニング」メニュー
Subversionバージョン管理およびソース制御システムのサポートに関連するオプションをが含まれます。詳細は、1.9項「バージョニングの使用」を参照してください。
「バージョニング」メニューのコマンドは、Data Modelerで使用できるバージョン管理およびソース制御システムによって異なります。
「ツール」メニュー
Data Modelerツールを起動し、特定のオプション(ユーザー・プリファレンス)を設定できます。
ドメイン管理: ドメインを表示、変更、追加および消去できます。「ドメイン管理」ダイアログ・ボックスが表示されます。
型の管理: 論理型を表示、変更、追加および消去できます。「型の管理」ダイアログ・ボックスが表示されます。
RDBMSサイト管理: RDBMSサイト(データベースのサポートされるタイプと関連付けられる名前)を表示して、物理モデルの作成に役立つ独自の名前(別名)を追加します。「RDBMSサイト・エディタ」ダイアログ・ボックスを表示します。
表からビュー・ウィザード: 選択されたリレーショナル・モデルに表に基づいたビューを作成できます。「表からビュー」ウィザードを表示します。
ビューから表ウィザード: 選択したリレーショナル・モデルでビューに基づいて表を作成します。ビューから表ウィザードを表示します。
名前略語: (たとえば、標準的な略語やスペルを確実に使用させるために)リレーショナル・モデル・オブジェクトの名前で変更される文字列が示された.csvファイルを指定します。「名前略語」ダイアログ・ボックスが表示されます。
用語集エディタ: 新しい用語集ファイルの作成(存在しないファイル名を指定した場合)および既存の用語集ファイルの編集が可能です。ファイルを選択するためのダイアログ・ボックスが表示された後に、「用語集エディタ」ダイアログ・ボックスが表示されます。
設計ルール: 現在の設計がData Modelerの設計ルールに違反していないかを確認できます。「設計ルール」ダイアログ・ボックスが表示されます。
エンジニアリング・ステータス: 「エンジニアリング」ダイアログ・ボックスが表示されます。
モデルの比較/マージ: 設計ファイルを開き、そのファイルのリレーショナル・モデルと現在の設計のリレーショナル・モデルを比較し、一方のモデルのオブジェクトを他方のモデルにマージすることができます。設計ファイルを選択すると、「リレーショナル・モデル」ダイアログ・ボックスが表示されます。
一般オプション: Data Modelerの動作をカスタマイズできます。「Data Modeler」ダイアログ・ボックスを表示します。
「ヘルプ」メニュー
Data Modelerに関するヘルプを表示します。
コンテンツ: 「ヘルプ・センター」ウィンドウを表示します。このウィンドウで使用可能なアイコンは次のとおりです。
常に手前に表示: 「データ・モデラー」ウィンドウの手前に「ヘルプ・センター」ウィンドウを表示するかどうかを設定します。
ナビゲータ: 「コンテンツ」ナビゲータまたは「お気に入り」ナビゲータを選択します。
印刷: トピックを印刷します。
フォント・サイズの変更: 現在のヘルプ・トピックの表示のフォント・サイズを拡大または縮小できます。
お気に入りに追加: トピックをお気に入りナビゲータのリストに追加します。
検索: 現在のヘルプ・トピックの文字列を検索できます。
情報: バージョン関連情報およびData Modeler、そのプロパティおよびインストール済拡張機能に関するその他の情報を表示します。
オブジェクト・ブラウザおよびダイアグラムのコンテキスト・メニュー(右クリック・メニュー)には、選択されたオブジェクトに関連するコマンドが含まれます。
オブジェクト・ブラウザで論理モデルまたはリレーショナル・モデルを右クリックした場合、コンテキスト・メニューには一般的に次の項目が含まれます。
分類タイプの設定: 多次元モデル内のエンティティまたは表に分類タイプ(「ファクト」、「ディメンション」、「ロギング」、「サマリー」または「一時」)を設定できます。(「ダイアグラム: 分類タイプ」ユーザー・プリファレンスでは、ダイアグラム内で使用される各分類タイプの色を指定することもできます。)
キーと制約へのネーミング標準の適用(リレーショナル・モデル): 選択したリレーショナル・モデル内のキーおよび制約に、「ネーミング標準」プリファレンスの「ネーミング標準: テンプレート」で指定したネーミング標準ルールを適用します。
オブジェクト名の接頭辞の変更: 選択されたオブジェクト・タイプについて、現在指定されている接頭辞と置き換える新しい接頭辞を指定します。「オブジェクト名の接頭辞の変更」ダイアログ・ボックスが表示されます。
カスタム変換スクリプトの適用: 「カスタム変換スクリプト」ダイアログ・ボックスを表示し、適用するスクリプトを選択できます。(カスタム変換スクリプトの詳細は、3.23.4「変換」を参照してください。)
外部キーの検出: リレーショナル・モデルの表間の外部キー・リレーションシップを検出して、外部キーを作成します。(3.16「検出された外部キーの作成」を参照してください。)
リレーショナル・モデルに対するエンジニアリング(論理モデルを選択): フォワード・エンジニアリングを実行して、論理モデルからリレーショナル・モデルを生成または更新します。また、サブビューを作成するかどうかを指定することもできます。
論理モデルに対するエンジニアリング(リレーショナル・モデルを選択): リバース・エンジニアリングを実行します。選択されたリレーショナル・モデルから論理モデルを更新します。
ダイアグラム内で、表示されているオブジェクトの外で右クリックした場合、コンテキスト・メニューには一般的に次の項目が含まれます。
検出された外部キーの作成(リレーショナル・モデル): リレーショナル・モデルで検出された非表示の外部キー・リレーションシップを表示します。(3.16「検出された外部キーの作成」を参照してください。)
検出された外部キーの削除(リレーショナル・モデル): 検出された外部キーをリレーショナル・モデル図から削除します。
SubViewの作成: Subviewを作成します。(1.3.4.1「論理ダイアグラムおよびサブビュー」と1.3.5.1「リレーショナル・ダイアグラムおよびサブビュー」も参照してください)
表示の作成: ビューまたはサブビューの別々の表示ペインを作成します。表示によって同じオブジェクトのセットを異なる方法で表すことができます。たとえば、表示を作成して、その表示を選択してから「詳細の表示」、「表示」(「グリッド」、「ラベル」、「凡例」)および「ダイアグラムの色」のコンテキスト・メニューの変更を試します。表示は、関連するメイン・ダイアグラムまたはサブビューと同じウィンドウですが、そのウィンドウの下部に表示のタブがあります。表示を削除するには、表示を右クリックして、「表示の削除」を選択します。
自動ルート: 「行自動ルート」(「Data Modeler」の「ダイアグラム」を参照)の設定を切り替えます。端または角(頂点)をクリック・アンド・ドラッグして移動させたり、[Ctrl]キーを押しながら端をクリック・アンド・ドラッグして新しい角を作成するなど、ダイアグラムで線を調節する前に「自動ルート」を無効にする必要があります。注意: 調節後に「自動ルート」を有効にすると、手動での調節は失われます。
直線にする(「自動ルート」が無効の場合にのみ使用可能): すべての角を削除し、線には始点と終点のみをつなぐようにします。
自動レイアウト(リレーショナルおよびデータ・フロー・ダイアグラム): ダイアグラム内のオブジェクトを、より意味があり体裁が良いと考えられるレイアウトに再配置します。再配置に不満がある場合は、「編集」→「自動レイアウトを元に戻す」をクリックすると、以前のレイアウトに戻すことができます。
詳細の表示: オブジェクトについての使用可能なすべての詳細か、または選択した詳細のみを表示できます。
表示: 「グリッド」では、バックグラウンドにグリッドが表示され、これはダイアグラムでオブジェクトを垂直方向および水平方向に調節するのに役立ちます。「ラベル」では、リレーションシップの矢印に外部キーの名前が表示され、データ・フロー・ダイアグラムのフロー線にフロー名が表示されます。「凡例」には、ダイアグラム名、作成者、作成日およびその他の情報が含まれる凡例ボックス(ドラッグして移動可能)が表示されます。
表示可能なようにオブジェクトをサイズ変更: 表示領域ですべて表示できるように図のオブジェクトをサイズ変更します。
プロパティ: モデルのプロパティを表示および編集するダイアログ・ボックスを表示します。
ダイアグラム内で、2つのオブジェクトを接続する線を右クリックした場合、コンテキスト・メニューには一般的に次の項目が含まれます。
削除: 線を削除し、その線で表されたリレーションシップを削除します。
直線にする(「自動ルート」が無効の場合にのみ使用可能): すべての角を削除し、線には始点と終点のみをつなぐようにします。
フォーマット: 線の色と太さを変更できます。
プロパティ: 線で表されたリレーションシップのプロパティを表示および編集するダイアログ・ボックスを表示します。
論理ダイアグラムおよびリレーショナル・ダイアグラム内で1つ以上のエンティティまたは表を選択し、その中の1つを右クリックした場合、コンテキスト・メニューには少なくとも次の項目が含まれます。
選択した項目からサブビューを作成: 選択したオブジェクトを含むサブビューを作成します。(1.3.4.1「論理ダイアグラムおよびサブビュー」と1.3.5.1「リレーショナル・ダイアグラムおよびサブビュー」も参照してください)
同胞の選択: 選択したオブジェクトに関連するオブジェクトを選択します。選択の方向(「すべて」(上位および下位レベルのゾーン)、「親」または「子」)を指定できます。選択項目からサブビューを作成する前に、同胞を選択することができます。
DDLプレビュー(リレーショナル・ダイアグラム): オブジェクトを作成するために生成されるDDL文を表示します。
フォーマット: 選択したオブジェクトの色およびフォントを指定できます。
最背面へ移動: 選択したオブジェクトを、表示しているダイアグラムの背面に移動します。この結果、オブジェクトは部分的または完全に他のオブジェクトによって覆われてしまう場合があります。
プロパティ: オブジェクトのプロパティを表示および編集するダイアログ・ボックスを表示します。
データ・フロー・ダイアグラム内で1つ以上のオブジェクトを選択し、その中の1つを右クリックした場合、コンテキスト・メニューには少なくとも次の項目が含まれます。
削除: 選択したオブジェクトを削除します。
フォーマット: 選択したオブジェクトの色およびフォントを指定できます。
最背面へ移動(線で表されていないオブジェクトが対象): 選択したオブジェクトを、表示しているダイアグラムの背面に移動します。この結果、オブジェクトは部分的または完全に他のオブジェクトによって覆われてしまう場合があります。
プロパティ: オブジェクトのプロパティを表示および編集するダイアログ・ボックスを表示します。
Data Modelerを使用して、様々な種類のモデルの様々な階層レベルのオブジェクトを作成、編集および削除することができます。多くのオブジェクトのプロパティは類似しており、操作の実行方法は基本的に共通していて直感的です。オブジェクトに対して操作(作成、編集、削除)を実行する場合は、オブジェクト・ブラウザまたはツールバーのコンテキスト・メニューか、またはダイアグラムを選択した後の「オブジェクト」メニューを使用できることがあります。
オブジェクト・ブラウザを使用してオブジェクトに対する操作の実行するには、階層内で適切なノードを右クリックし(またはノードをクリックして、[Shift]キーを押しながら[F10]キーを押し)、希望する操作のコマンドを選択します。
たとえば、エンティティを編集するには、「論理」表示を展開します。これによって、すべてのエンティティが表示されます。編集するエンティティの名前を右クリックして「プロパティ」を選択します。
ダイアグラムを使用して操作を実行するには、ダイアグラムのタブを選択し、ツールバー・アイコンを選択します。
たとえば、エンティティを作成するには、「論理」タブを選択して、「新規エンティティ」ツールバー・アイコンをクリックし、「エンティティのプロパティ」ボックスでエンティティを定義します。エンティティを編集するには、ダイアグラムでボックスをダブルクリックするか、またはボックスを右クリックして、「プロパティ」を選択します。
ダイアグラム内のコンテキスト・メニュー(右クリック・メニュー)には、ダイアグラムに一般的に関連するコマンドか、または現在選択されているオブジェクトに関連するコマンドが含まれます。
特定の種類のオブジェクトの概要および使用方法の情報については、次のトピックを参照してください。
Data Modelerは、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が作成されます。
Data Modelerは、その論理モデル内のスーパータイプおよびサブタイプをサポートするだけでなく、データ型モデルも提供します。これによって、CWM(Common Warehouse Metamodel)準拠になり、SQL99構造型のモデリングが可能になります。データ型モデルは、データ型として論理モデルおよびリレーショナル・モデル内で使用できます。
構造型は、スーパータイプおよびサブタイプの継承階層を構築できるユーザー定義の名前付きコンポジット型としてサポートされています。固有型およびコレクション(配列)型を定義して、構造型と、構造型の継承階層を作成および可視化することができます。
論理モデルおよびリレーショナル・モデルでは、両方ともデータ型モデルからの定義を使用して、属性および列のデータ型を指定したり、表(エンティティ)が特定の構造型であることを定義できます。
データ型モデルは、次のような1つ以上の方法で構築できます。
Data Modelerで手動で構築する
Oracle Designerリポジトリからインポートして構築する。1.6.6「Oracle Designerモデルのインポート」を参照してください。
Data Modelerのデータ型モデルは、2種類のデータを結合します。
1つのデータ型ダイアグラム(さらに、オプションでサブビューおよび補助表示のセット。それぞれは適切なダイアグラム/サブビューに関連付けられます)
データ型オブジェクト定義
サブビューは、様々なサブジェクト領域を表すために作成される、データ型モデルの独立したダイアグラムとみなされます。
データ型モデルを使用すると、固有型、構造型、コレクション型および論理型のオブジェクト定義を作成および管理できます。
(論理型を除く)すべてのデータ型モデル・オブジェクトは、オブジェクト・ブラウザ・ツリーに表示されますが、データ型ダイアグラム上にグラフィカルに表示されるのは、構造型オブジェクトとその相互関係のみです。
次の図に示すとおり、データ型ダイアグラムでは、構造データ型とそれらのリンクがグラフィカルに表現されています。
構造型のボックスには、オブジェクトの名前、定義された属性およびメソッド(存在する場合)が含まれます。ダイアグラムのリンクは、構造データ型とともに様々な属性を表します。
複雑なデータ型モデルで作業を行う場合は、サブビューを作成し、それぞれのサブビューでそのモデルの中のあるセクションのみを表すことができます。1つのデータ型モデルに複数のデータ型サブビューを定義し、その複数のサブビューに１つの構造型を割り当てることができます。ただし、2つの構造型間のリンク(参照)が表示されるのは、全体のデータ型モデル上と、両方の型が割り当てられたサブビュー上のみです。
サブビュー内での変更の実行と、全体のデータ型モデル内での変更の実行に違いはありません。実行した変更は、全体モデルおよび関連サブビューに即座に反映されます。ただし、構造型は、データ型モデルから削除することなく、サブビューから削除できます。
ユーザー定義の固有型は、「型の管理」ダイアログ・ボックスで定義された既存の論理型から導出されたデータ型です。固有型は、その表現を既存の型(ソース型)と共有しますが、個別で互換性のない型とみなされます。
固有型オブジェクトにアクセスできるのは、それがデータ型フォルダの固有型サブフォルダにある場合のみです。
ユーザーは新しい固有型を作成したり、既存の固有型のプロパティを編集できます。
構造型は、属性およびメソッドを持つユーザー定義データ型です。これは、スーパータイプおよびサブタイプの継承階層の一部になることもできます。構造型は、基本データ型、固有型、別の構造型または構造型への参照をベースにして定義できますが、コレクション型として定義することもできます。
表またはエンティティは、構造型をベースにして定義できます。型置換を使用すると、表(エンティティ)が収容できるサブタイプのインスタンスを(ダイアグラム上でグラフィカルに)表現できます。
表の列またはエンティティの属性は、構造型、構造型への参照、コレクション型、固有型および基本データ型をベースに定義できます。型置換は構造型に基づく列に対して定義でき、範囲表は構造型への参照に基づく列に対して定義できます。
構造型には、一連のメソッド仕様も含まれます。メソッドを使用すると、構造型の動作の定義できます。ユーザー定義ファンクション(UDF)のように、メソッドはSQLを拡張するルーチンです。ただし、メソッドの場合、動作と特定の構造型との統合は単独で行われます。
拡張構造型サブフォルダには、属性の階層とそれぞれのメソッドとともに、すべての構造型オブジェクトが示されます。
Oracle SpatialのSDO_GEOMETRY型は、構造型として事前定義されています。また、ユーザーは新しい構造型を作成したり、既存の構造型のプロパティを編集できます。
コレクション型は、要素(基本型、固有型、構造型または別のコレクション)の配列またはコレクションを表現し、Oracle VARRAYおよびネストした表タイプにマップされます。
ユーザーは新しいコレクション型を作成したり、既存のコレクション型のプロパティを編集できます。
論理型は実際のデータ型ではなく、ネイティブ型またはドメインと関連付けられる名前です。事前に用意されている論理型には、Oracle Multimediaからのもの(ORDで始まる名前のもの)がいくつか含まれますが、ORDIMAGE_SIGNATUREは非推奨であるため、新しい定義には使用しないでください。
論理型を作成し、ネイティブな型とのマッピングを編集することができます(3.134「型の管理」を参照)。また、ドメインを論理型に関連付けることができます(3.29「ドメイン管理」を参照)。
プロセス・モデルは、情報構造システムの機能領域を表します。1つ以上のデータ・フロー・ダイアグラムでグラフィカルに表現されるプロセス・モデルは分析技術であり、入力がシステム(プロセスのグループ)を通って結果としての出力に至るフローをとらえるために使用されます。モデルは、システム(既存のシステムや提案されたシステム)を通る情報のフローを表します。
データ・フロー・ダイアグラミングに必要なすべての要素が、Data Modelerプロセス・モデルでサポートされています。この要素には、プリミティブ・プロセス、分解レベルに制限がないコンポジット・プロセス、再使用可能な変換タスク、トリガー・イベント、情報ストア、外部エージェント、外部データ要素を説明するレコード構造、データ要素のソースとターゲットのマッピング、およびプリミティブ・プロセスとデータ要素の間のCRUD(作成、読取り、更新、削除)の依存性があります。
プロセス・モデルにおける概念で重要なものを次に示します。
プロセスは、ある特定の理由で実行されるアクティビティまたは機能です。各プロセスが実行するアクティビティは、最終的に1つのみである必要があります。
プリミティブ・プロセスはスタンドアロン・プロセスです。
コンポジット・プロセスは複数の外部プロセスで構成されます。データ・フロー・モデルにより、コンポジット・プロセスを介して子プロセスへドリルダウンできます。これは、最上位レベルのプロセスが他のデータ・フロー・モデル全体にドリルダウンできることを意味します。
トリガーは何らかの出来事であり、これが発生するとプロセスの実行が開始されます。
データ・フローは、1つのデータまたは情報の論理コレクションの動きを反映したものです。フローはデータ・フロー・ダイアグラムの順序を表現します。(詳細は、1.3.3.1「データ・フロー・ダイアグラム」を参照してください。)
外部エージェントは、システムの外部にありながらシステムと相互に作用する個人、組織またはシステムです。外部エージェントは、プロセスに対して情報の送受信を行います。
情報ストアは、データ・モデルのエンティティおよび属性として情報を受信または保存する受動オブジェクトです。最終的に、1つの情報ストアは、データ・モデルの1つ以上のエンティティに対応します。
入力および出力パラメータを含む変換タスクは、これを実行する周囲の環境と通信する実行ユニットです。入力パラメータとして、処理を行う必要がある日付が考えられます。出力パラメータとして、操作が成功したかどうかを示すコードが考えられます。変換自体には、情報の読取り、変換および保存が含まれますが、この中には、入力および出力パラメータと直接結びついていないものがある場合があります。(詳細は、1.3.3.2「変換プロセスおよびパッケージ」を参照してください。)
ロールは、定義された権限およびアクセス権のセットです。情報ストアに接続されたプリミティブ・プロセス(データ要素を作成、読取り、更新および削除するプロセス)は、定義済ロールにアタッチできます。その結果、ロールとデータ要素との間のコラボレーションが定義されます。後で、定義済のSelect、InsertおよびUpdate権限を持つ適切なデータベース・ロールが作成されるように、ロール定義を特定の物理モデルに送ることができます。
正式な構造分析アプローチでは、機能分解プロセスを容易にするために、データ・フロー・ダイアグラム(DFD)を使用します。データ・フロー・ダイアグラムは、次のコンポーネントで構成されます。
外部インタラクタ: 矩形で表現されます。
データ・ストア: (二辺または三辺の)開矩形で表現されます。
プロセス: 丸みのあるオブジェクト(円、楕円または角が丸められた四角形)で表現されます。
プロセスは、アトミック・レベルから集計レベルに至る様々なレベルのいずれかでシステム機能を表現できます。
データ・フロー: 矢印で表現され、オプションでその内容を示すラベルが付けられます。
一般的なデータ・フロー・ダイアグラムでは、外部ソースからデータを抽出し、ターゲット・ストアまたはデータベースにロードする前にデータを変換します。変換プロセスで使用する変換パッケージを作成できます。
変換プロセスでは、変換パッケージに1つ以上の変換タスクを作成する必要があります。変換タスクを作成したら、その変換タスクをメイン変換プロセスに含めることができます。
変換パッケージは、Object Management Group(OMG)のCommon Warehouse Metamodel(tm) (CWM(tm)) Specification、V1.1に定義されているパッケージです。この仕様では、次のように変換パッケージが紹介されています。
データ・ウェアハウスの主要な側面は、操作リソースからデータ・ウェアハウスまたは分析用のデータ・マートへデータを抽出、変換およびロードすることです。抽出、変換およびロードは、すべて変換とみなすことができます。実際に、データ・ウェアハウス内である形式から別の形式にデータを変換する必要がある場合は、その目的が格納、取得、表示のいずれであっても変換が常に含まれます。そのため、変換はデータ・ウェアハウスの中心になります。
「変換パッケージには、データ・ウェアハウスで使用される変換の共通メタデータを表すクラスおよび関連付けが含まれます。サポートされる変換は、オブジェクト指向、リレーショナル、レコード、多次元、XML、OLAP(On-Line Analytical Processing)およびデータ・マイニングなど、すべてのタイプのデータソースとターゲットにわたる基本的な変換です。
「変換パッケージは、変換ツールとアクティビティについての共通メタデータをやりとりできるように設計されています。」
Data Modelerのコアは、論理モデル(エンティティ関連ダイアグラムとも呼ばれる)です。これは、実装には依存しない企業情報のビューを提供し、多次元モデルとプロセス・モデルの定義を様々な物理的実装にマップするメディエータとして機能します。論理モデルまたはその一部(サブジェクト・エリア、サブビュー)は、1つ以上のリレーショナル・モデルに変換できます。
論理モデルは、次のいずれの方法でも構築できます。
Data Modelerで手動で構築する
VARファイルからモデルをインポートして構築する。モデルには、Sterling COOL:DBA V2.1、Sterling Bsnteam V7.2、Cayenne Bsnteam V7.2、Rational Rose、TogetherJ、JDeveloper、MEGA、PowerDesigner v.12などによって作成されたものがあります。
Data Modelerで作成された既存のモデルをインポートして構築する。
インポートされたリレーショナル・モデルからリバース・エンジニアリングして構築する。
論理モデルは、次の2種類のデータを結合します。
1つの論理ダイアグラム(さらに、オプションでサブビューおよび補助表示のセット。それぞれは適切なダイアグラム/サブビューに関連付けられます)
論理モデル・オブジェクト定義
サブビューは、様々なサブジェクト領域を表すために作成される、論理モデルの独立したダイアグラムとみなされます。
論理モデルを使用すると、エンティティ、論理ビュー、属性、一意識別子、継承、リレーションおよびarcに対するオブジェクト定義を作成および管理できます。
すべての論理モデル・オブジェクトは、オブジェクト・ブラウザ・ツリーに表示されます。
論理モデル・ダイアグラムには、エンティティ、ビュー、およびそれらのリンク(リレーションおよび継承)のグラフィカルな表現が含まれます。
複雑な論理モデルで作業を行う場合は、サブビューを作成し、そのモデルの中のあるセクションのみを表すことができます。1つの論理モデルに複数の論理サブビューを定義し、その複数のサブビューにエンティティとビューを割り当てることができます。2つのエンティティ間のリンク(リレーション)が表示されるのは、全体の論理モデル上と、参照される両方のエンティティが割り当てられた論理サブビュー上のみです。
1つのサブビュー内での変更の実行と、全体の論理モデル内での変更の実行に違いはありません。実行した変更は、全体の論理モデルおよび関連サブビューに即座に反映されます。ただし、エンティティおよびビューは、全体の論理モデルから削除することなく、サブビューから削除できます。
特定のエンティティを含むサブビューを作成するには、論理モデル・ダイアグラムで目的のエンティティを選択して右クリックし、「選択した項目からサブビューを作成」を選択します。
Data Modelerでは、論理モデル・ダイアグラム表記として次の代替表記法をサポートしています。
Bachman表記法
Barker表記法
それぞれの表記法について、そのスタイルの詳細な説明および例は、書籍およびWebで広く入手できます。「Data Modeler」(「一般オプション」、「ダイアグラム」、「論理」)では、新しい論理ダイアグラムのデフォルトの表記法タイプを設定できます。
1つの表記法タイプから他に切り替えるには(また、ダイアグラムの違いを参照するには)、論理モデル・ダイアグラムを選択し、「ビュー」→「論理モデル表記法」をクリックしてから、現行とは異なる表記法をクリックします。
エンティティは、ユーザーが情報を格納しようと考えているオブジェクトまたは概念です。エンティティの構造は、属性のコレクションとして定義したり、データ型モデルからの構造型をベースにして定義できます。エンティティに候補となる一意識別子が複数あっても、プライマリ一意識別子として定義できるのは、そのうちの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]を押したまま各線をクリック)、ツールバーの「新規の円弧」ボタンをクリックします。
リレーショナル・モデルは、SQL表、列および表間の結合という観点からデータベースを表します。論理モデルから選択する各エンティティは、リレーショナル・モデル内の表として表されます。各行は表であり、対応するエンティティの特定(個別)の出現を表します。エンティティの各属性は、表の列によって表されます。
リレーショナル・モデルは、次のいずれの方法でも構築できます。
Data Modelerで手動で構築する
論理モデルまたは論理モデルのサブビューからフォワード・エンジニアリングして構築する。
VARファイルからモデルをインポートして構築する。モデルには、Sterling COOL:DBA V2.1、Sterling Bsnteam V7.2、Cayenne Bsnteam V7.2、Rational Rose、TogetherJ、JDeveloper、MEGA、PowerDesigner v.12などによって作成されたものがあります。
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]を押したまま各線をクリック)、ツールバーの「新規の円弧」ボタンをクリックします。
物理モデルは、リレーショナル・モデルに基づいた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つ以上の表からのデータを含むスキーマ・オブジェクトです。
索引クラスタには複数のクラスタが含まれる必要があり、クラスタ内のすべての表が1つ以上の共通する列を持ちます。Oracle Databaseは、同じクラスタ・キーを共有するすべての表のすべての行をまとめて格納します。
1つ以上の表を含めることができるハッシュ・クラスタの場合、Oracle Databaseは同じハッシュ・キー値を持つ行をまとめて格納します。
ディメンションは、列セットのペア間の親子関係を定義するもので、この列セットに含まれるすべての列は、同じ表の列である必要があります。ただし、1つの列集合(レベル)の列は、別の集合の列とは異なる表から得ることができます。オプティマイザでは、これらの関係をマテリアライズド・ビューとともに使用して、クエリー・リライトを実行します。SQLアクセス・アドバイザは、この関係に基づいて、特定のマテリアライズド・ビューの作成を推奨します。
ディレクトリは、外部バイナリ・ファイルLOB(BFILE)および外部表データが存在するサーバー・ファイル・システムのディレクトリ(Windowsシステムではフォルダと呼ばれる)の別名です。
PL/SQLコードおよびOCI(Oracle Call Interface)コールで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(tm)(CWM(tm)) Specification、V1.1に、次のように説明されています。「ビジネス情報メタモデルは、モデル要素についてのビジネス指向情報を定義するために、すべてのCWMパッケージで使用可能な汎用サービスを提供します。ここで説明されるビジネス指向サービスは、データ・ウェアハウスおよびビジネス・インテリジェンス・システムのニーズをサポートするように設計されており、汎用ビジネス・インテリジェンス・メタモデルを完全に表現するようには意図されていません。ビジネス情報メタモデル・サービスは、責任者とその連絡方法、オフライン・ドキュメントの識別および汎用的な記述情報のサポートについて、その概念をサポートします。」
このトピックの残りの部分では、ビジネス情報オブジェクトについて簡単に説明します。説明するオブジェクトの順序は、ビジネス情報のオブジェクト・ブラウザにおける表示順ではありません。
連絡先オブジェクトは、関連する様々なタイプの連絡先情報をグループ化します。各連絡先オブジェクトは、複数の電子メール、ロケーション、URLおよび電話オブジェクトに関連付けることができます。反対に、各電子メール、ロケーション、URLおよび電話オブジェクトは、多数の連絡先オブジェクトに関連付けることができます。(3.14「連絡先のプロパティ」も参照してください。)
ドキュメント・オブジェクトは、モデル化されたシステムのいくつかの側面について、外部に格納された記述情報を表します。ドキュメント・オブジェクトは、1つ以上のモデル・オブジェクトに関連付けることができます。(3.27「ドキュメントのプロパティ」も参照してください。)
電子メール・オブジェクトは、1つの電子メール・アドレスを識別します。連絡先オブジェクトを使用すると、電子メール・アドレスを1人以上の責任者と関連付けることができます。連絡先の電子メール・オブジェクトの順序は、連絡先との通信に使用を試みる電子メール・アドレスの順番で表される場合があります。(3.30「電子メールのプロパティ」も参照してください。)
ロケーション・オブジェクトは、1つの物理的な場所を識別します。連絡先オブジェクトを使用すると、ロケーションを1人以上の責任者と関連付けることができます。ロケーションの連絡先オブジェクトの順序は、ロケーションに関連付けられた個人またはグループへの連絡を試みる際の順番で表される場合があります。(3.58「ロケーションのプロパティ」も参照してください。)
リソース・ロケータ・オブジェクトは、従来のメール・アドレスでロケーションが定義されていないリソースを表すための一般的な手段を提供します。たとえば、リソース・ロケータは、ウェブアドレス(www.example.comなど)から、建物内の場所(317号室、3番目のファイル・キャビネット、2番目の引出しなど)に至るまで、どのよう場所でも参照することができます。(3.79「リソース・ロケータのプロパティ」も参照してください。)
責任者オブジェクトは、1つ以上のモデル・オブジェクトについての情報に責任を持っていたり、その情報を受け取る必要がある個人、ロールまたは組織を表します。責任オブジェクトにおける責任の正確な意味は、実装されている特定のシステムに応じて異なります。(3.80「責任者のプロパティ」も参照してください。)
データをモデル化する場合は、実行する作業の特質に最も適したアプローチを選択できます。データ・モデリングへのアプローチには、新しいデータベースの設計、既存のデータベースに向けた設計の開発、または既存のデータベース設計でのメンテナンスの実行が含まれます。
トップダウン・モデリング: 新しいデータベースを設計する場合
ボトムアップ・モデリング: 既存のデータベースからメタデータを抽出してデータベースを作成する場合、または既存のデータベースの実装から取得したDDLコードを使用してデータベースを作成する場合
ターゲット・モデリング: データベースを新しい要件に適応させる場合
トップダウン・モデリングでは、業務要件および内部環境についての情報を収集しから、プロセス、データの論理モデル、１つ以上のリレーショナル・モデル、および各リレーショナル・モデルの1つ以上の物理モデルを定義します。ニーズによっては、手順と情報要件は簡単なものから詳細なものに及ぶことがあります。トップダウン・モデリングには次の手順が含まれますが、ニーズに合わせて手順を短縮したり、省略することができます。
ビジネス情報を作成します。
ドキュメントを作成します。オブジェクト・ブラウザで、「論理」を右クリックして、「プロパティ」を選択して、次に「ドキュメント」をクリックして適切な項目を追加します。
連絡先、電子メール・アドレス、ロケーションおよび電話番号を使用して、責任者を作成します。オブジェクト・ブラウザで、「論理」を右クリックして、「プロパティ」を選択し、次に「責任者」をクリックして、適切な項目を追加します。
他の情報を追加します。オブジェクト・ブラウザで、「論理」を右クリックして、「プロパティ」を選択し、次に必要に応じて他のプロパティ(「命名オプション」、「コメント」、「注意」)を変更します。
データ・フロー・ダイアグラムを使用して、プロセス・モデルを開発します。プロセス・モデルのオブジェクト・ブラウザで「データ・フロー・ダイアグラム」を右クリックして、「新規データ・フロー・ダイアグラム」を選択します。
プロセスを作成します。プロセスごとに、「新規プロセス」アイコンをクリックしてデータ・フロー・ダイアグラム・ウィンドウの中をクリックし、「情報ストアのプロパティ」ダイアログ・ボックスに情報を入力します。
外部エージェントを作成します。外部エージェントごとに、「新規外部エージェント」アイコンをクリックしてデータ・フロー・ダイアグラム・ウィンドウの中をクリックし、「外部エージェントのプロパティ」ダイアログ・ボックスに情報を入力します。
情報ストアを作成します。プロセスごとに、「新規情報ストア」アイコンをクリックしてデータ・フロー・ダイアグラム・ウィンドウの中をクリックし、「情報ストアのプロパティ」ダイアログ・ボックスに情報を入力します。
情報構造を使用してフローを作成します。フローごとに、「新規フロー」アイコンをクリックし、データ・フロー・ダイアグラム・ウィンドウで始点オブジェクト(プロセスなど)をクリックして、フローの終点オブジェクトをクリックし、次にフローの矢印をダブルクリックして、「フローのプロパティ」ダイアログ・ボックスの情報を(必要に応じて)変更します。
論理モデルを作成します。
エンティティを作成し、各エンティティの属性および一意識別子を作成します。最初にすべてのエンティティを作成してから、それぞれの属性および一意識別子を作成するか、1番目のエンティティとその属性および識別子を作成し、次に2番目以降も同じように順次作成していくこともできます。
エンティティを作成するには、「論理」タブをクリックして「新規エンティティ」アイコンをクリックし、論理モデル・ウィンドウの中をクリックして、「エンティティのプロパティ」ダイアログ・ボックスに情報を入力します。また、このダイアログ・ボックスの該当するペインを使用して、属性および一意識別子を入力することもできます。
エンティティ間のリレーションを作成します。リレーションごとに、目的のアイコン(「新規のM:Nリレーション」(1対多)、「新規の1:N識別リレーション」(1対多、識別)または「新規の1:1リレーション」(1対1))をクリックします。リレーションの始点のエンティティをクリックして、リレーションの終点をクリックし、次に、リレーションの線をダブルクリックして、「リレーションのプロパティ」ダイアログ・ボックスの情報を必要に応じて変更します。
論理モデルに設計ルールを適用します。「ツール」→「設計ルール」をクリックし、「設計ルール」ダイアログ・ボックスを使用して、デザイン・ルールの違反を確認して修正します。
論理モデルをリレーショナル・モデルにフォワード・エンジニアします。ナビゲータで論理モデルを右クリックして、「リレーショナル・モデルに対するエンジニアリング」を選択して、「エンジニアリング」ダイアログ・ボックスを使用して、論理モデルのすべてのオブジェクトまたは指定されたオブジェクトのサブセットを反映するリレーショナル・モデルを生成します。
必要に応じて、多次元モデルを作成します。
キューブを作成します。
レベルを作成します。
ディメンションを作成します。
リンクを作成します。
多次元モデルに設計ルールを適用します。
必要に応じて、多次元モデルをエクスポートします。
必要に応じて、1つ以上のリレーショナル・モデルを作成します。作成するには、各リレーショナル・モデルで次の手順を実行します。
表を分割します。1つの表を2つに分割するには、リレーショナル・モデル・ダイアグラムで表を選択して、「表の分割」ボタンをクリックします。
表をマージします。別の表に表をマージ(マージされる表は削除)するには、「表のマージ」ボタンをクリックします。次にリレーショナル・モデル・ダイアグラムでまずほかの表からの列のマージ先となる表を選択してからマージ元の列を持つ他の表を選択します。(マージ後、2番目の表は削除されます。)
リレーショナル・モデル用の設計ルールを確認します。「ツール」→「設計ルール」をクリックします。
リレーショナル・モデルごとに、1つ以上の物理モデルを作成します。作成するには、各リレーショナル・モデルで次の手順を実行します。
物理モデルを開きます。
物理モデル用の設計ルールを確認します。「ツール」→「設計ルール」をクリックします。
実際のデータベース・オブジェクトの生成に使用できるDDLコードを生成します。「表示」→「DDLファイル・エディタ」をクリックして、次に「DDLファイル・エディタ」ダイアログ・ボックスを使用して、物理モデルの選択、DDLコードのスクリプト・ファイルへの保存を行います。
ボトムアップ・モデリングは、既存のデータベースから抽出されたメタデータに基づいてデータベース設計を構築するか、または既存のデータベースを実装するDDLコードのファイルに基づいてデータベース設計を構築します。作成されるデータベースは、リレーショナル・モデルおよび物理モデルとして表され、リレーショナル・モデルから論理モデルをリバース・エンジニアします。ボトムアップ・モデリングには次の手順が含まれますが、ニーズに合わせていくつかの手順を短縮したり、省略することができます。
次のいずれかの方法で、リレーショナル・モデルを生成します。
既存のデータベースから直接メタデータを抽出します。「ファイル」→「インポート」→「データ・ディクショナリ」をクリックし、ウィザードの指示に従います(「データ・ディクショナリ・インポート(メタデータ抽出)」を参照してください)。
既存のデータベース実装を反映するDDLコードをインポートします。「ファイル」→「インポート」→「DDLファイル」をクリックします。
必要に応じて、リレーショナル・モデルを変更して、追加のリレーショナル・モデルを作成します。
必要に応じて、リレーショナル・モデルを非正規化します。必要に応じて、各モデルに対して次の手順を繰返し実行します。
表の分割またはマージ、あるいはその両方を実行します。
1つの表を2つに分割するには、リレーショナル・モデル・ダイアグラムで表を選択して、「表の分割」ボタンをクリックします。「表の分割」ウィザードを使用して、ソースの外部キーおよび列をターゲット表(作成された新しい表)にコピーまたは移動します。
別の表に表をマージ(マージされる表は削除)するには、「表のマージ」ボタンをクリックします。次に、リレーショナル・モデル・ダイアグラムで、列を他の表にマージする表をクリックして、次に最初にクリックした表の列のマージ先となる表をクリックします。(マージ後、最初にクリックした表が削除され、残りの表には、その元の列と最初の表にあった列が含まれます。.)
モデル用の設計ルールを確認します。設計ルールを表示するには、「ツール」→「設計ルール」をクリックし、目的のリレーショナル・モデルを選択して、「設計ルール」ダイアログ・ボックスを使用します。
リレーショナル・モデルから論理モデルにリバース・エンジニアします。「論理モデルに対するエンジニアリング」アイコンをクリックするか、リレーショナル・モデルを右クリックして「論理モデルに対するエンジニアリング」を選択します。
必要に応じて、論理モデルを変更します。
論理モデル用の設計ルールを確認します。「ツール」→「設計ルール」をクリックします。
設計を保存します。
DDLコードを作成し、それを使用してデータベース実装を作成します。「ビュー」→「DDLファイル・エディタ」をクリックします。「DDLファイル・エディタ」ダイアログ・ボックスで、物理モデルを選択して「生成」をクリックします。目的の「DDL生成オプション」を指定して、「OK」をクリックします。
ターゲット・モデリングには、既存のデータベースのメンテナンスが含まれますが、これは新しい要件に適応させて行います。
|
注意: Data Modelerでデータベースをメンテナンスするには、設計と実際のデータベース実装が完全に同期する必要があります。これに該当するかどうか不明な場合は、設計を古いものとみなして、1.4.2「ボトムアップ・モデリング」の手順を実行する必要があります。 |
必要な変更の種類に応じて、論理モデル、1つ以上のリレーショナル・モデルまたは1つ以上の物理モデルから開始し、必要に応じて、フォワード・エンジニアまたはリバース・エンジニアを行うことができます。
論理モデルの変更から開始する方法
変更する論理的モデル・オブジェクト(エンティティ、属性、リレーションなど)ごとに、そのプロパティを変更します。たとえば、エンティティに属性を追加するには、次の手順を実行します。
論理ダイアグラムでエンティティのアイコンをダブルクリックします(または、オブジェクト・ブラウザでエンティティ名を右クリックして、「プロパティ」を選択します)。
「エンティティのプロパティ」ダイアログ・ボックスで、「属性」をクリックします。
「追加」(+)アイコンをクリックして、属性プロパティを指定します。
論理モデルの変更が完了したら、「リレーショナル・モデルに対するエンジニアリング」アイコンをクリックするか、ナビゲータで論理モデルを右クリックしてから「リレーショナル・モデルに対するエンジニアリング」を選択して、変更点をリレーショナル・モデルにフォワード・エンジニアします。
「エンジニアリング」ダイアログ・ボックスで、必要なフィルタリングを指定して「エンジニア」をクリックします。
リレーショナル・モデルの変更から開始する方法
変更するリレーショナル・モデル・オブジェクト(表、列など)ごとに、そのプロパティを変更します。たとえば、リレーショナル・モデルの表に列を追加するには、次の手順を実行します。
リレーショナル・モデルのダイアグラムで表のアイコンをダブルクリックします(または、オブジェクト・ブラウザで表名を右クリックして、「プロパティ」を選択します)。
「表のプロパティ」ダイアログ・ボックスで、「列」をクリックします。
「追加」(+)アイコンをクリックして、列プロパティを指定します。
リレーショナル・モデルの変更が完了したら、「論理モデルに対するエンジニアリング」をクリックするか、ナビゲータでリレーショナル・モデル名を右クリックしてから「論理モデルに対するエンジニアリング」を選択して、変更点を論理モデルにリバース・エンジニアします。
「エンジニアリング」ダイアログ・ボックスで、必要なフィルタリングを指定して「エンジニア」をクリックします。
ユーザー自身の好みとニーズに合わせてユーザー・プリファレンスを変更することで、Data Modelerの環境とインタフェースの多くの設定をカスタマイズできます。ユーザー・プリファレンスを変更するには、「ツール」→「プリファレンス」を選択します。
ほとんどのプリファレンスはわかりやすいものであるため、ここでは、意味と意図が明確でないプリファレンスについてのみ説明します。プリファレンスによっては、パフォーマンスまたはシステム・リソースに影響するものや(機能の有効化による実行時間の増加など)、単に個人の好みによるものがあります。プリファレンスは、次のカテゴリにグループ化されています。
「環境」ペインには、Data Modelerの起動、動作全体および外観に影響するオプションが含まれます。指定したタイミングで特定の操作が自動的に実行されるように指定できます。通常、操作に余分な時間がかかりますが、操作を自動的に実行しない場合に問題が発生する可能性(必要な操作の実行を忘れてしまう、など)を考慮して、指定するかどうかを判断します。
UNDOレベル(元に戻せる実行済操作の数)とナビゲーション・レベル(開いているファイルの数)の値への変更によって、システム・リソースの使用率がわずかに増減します。
外部で変更されたファイルを自動的にリロード: このオプションを選択した場合、Data Modelerで開いているファイルが外部アプリケーションによって変更されると、Data Modelerに再び切り替えたときにそのファイルは更新され、Data Modelerで行われた変更が上書きされます。このオプションを選択しない場合、Data Modelerで行った変更が適用され、外部アプリケーションで行われた変更が上書きされます。
未修正ファイルの場合、警告なしでリロード: このオプションを選択した場合、外部で変更されたがData Modelerでは変更されていないファイルについては、リロードするかどうかの確認が行われません。このオプションを選択しない場合、Data Modelerで変更されたかどうかに関係なく、外部で変更された各ファイルをリロードするかどうかが確認されます。
環境: ドッキング可能なウィンドウ
「ドッキング可能なウィンドウ」ペインでは、ドッキング可能なウィンドウの動作と、Data Modelerの4つのドッキング領域(上下左右)の形を構成します。
ドッキング可能なウィンドウを常に上に表示: このオプションを選択した場合、ドッキング可能なウィンドウは、常に他のウィンドウの手前に表示されます。
ウィンドウ・レイアウト: 角の矢印をクリックして、各ドッキング領域の形を拡大または縮小します。
環境: ログ
「ログ」ペインでは、特定のタイプのログ・メッセージの色およびログ・メッセージのログ・ファイルへの保存を構成します。
ファイルにログを保存: このオプションを選択した場合、「メッセージ - ログ」ウィンドウへのすべての出力は、ログ・ファイルに保存されます。ファイル名には、操作およびタイムスタンプが反映されます。また、「ログ・ディレクトリ」を指定するように求められます。指定したディレクトリが存在しない場合は作成されます。ログ情報をファイルに保存する場合、ファイル数が非常に多くなる可能性があることに注意してください。
最大ログ行数: 各ログ・ファイルに格納する行の最大数。
「Data Modeler」ペインには、Data Modelerの起動、動作全体および外観に影響するオプションが含まれます。
デフォルト設計ディレクトリ: 設計を開く場所または設計を作成する場所になるデフォルトのディレクトリまたはフォルダです。
デフォルト・インポート・ディレクトリ: 設計のインポート元になるデフォルトのディレクトリまたはフォルダです。
インポート後にログの表示: インポート操作の後に、「ログ」ウィンドウを表示するかどうかを制御します。ウィンドウには、情報メッセージと、警告またはエラー・メッセージが含まれます。
デフォルトの保存ディレクトリ: ファイルの保存先となるデフォルトのディレクトリまたはフォルダです。
デフォルトのシステム・タイプ・ディレクトリ: タイプ定義ファイルの格納先となるデフォルトのディレクトリまたはフォルダです。
デフォルトのレポート・ディレクトリ: 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プロセッサの詳細およびダウンロードは、http://saxon.sourceforge.net/に移動してください。)
「リレーショナル・モデルの選択」ダイアログの表示: Data Modeler設計を開くときに、含めるリレーショナル・モデルを選択するためのダイアログ・ボックスを表示するかどうかを制御します。このオプションを無効にすると、Data Modeler設計を開くときに、すべてのリレーショナル・モデルがデフォルトで含まれます。
「設計を開く」の設計レベルの設定をロード: 設計を開くときにその設計に固有の設定をロードするかどうかを制御します。このオプションを無効にすると、設計固有の設定はすべて無視され、Data Modelerのグローバル設定が使用されます。
「新規オブジェクトの「プロパティ」ダイアログの表示」: 新しいモデル・オブジェクトを作成するときに、そのタイプのオブジェクトの「プロパティ」ダイアログ・ボックスを表示するかどうかを制御します。
「設計を閉じる」の後に前の設計レベルの設定をリストア: 現在の設計を閉じた後に、現在の設計に固有のすべての前の設定をリストアするかどうかを制御します。このオプションを無効にすると、Data Modelerのグローバル設定がリストアされます。
インポート: 1.7で説明するように、事前にエクスポートしたData Modelerのプリファレンスおよびその他の設定をインポートできます。
エクスポート: Data Modelerのプリファレンスおよびその他の設定をXMLファイルに保存して、1.7で説明するように、後で情報をインポートできるようにします。
Data Modelerのその他のプリファレンスは、次のカテゴリにグループ化されています。
「マッピングの比較」ペインには、ソース・オブジェクトとターゲット・オブジェクトを比較するためのオプションが含まれています。この情報は、列のプロパティ(名前、データ型、表内の位置など)を変更して、モデルを同じモデルの以前のバージョンと比較するといった特別な場合に適用されます(マッピングによって、変更された列と同じかどうか判断できます)。
「DDL」ペインには、生成されるコードのデータ定義言語(DDL)文に対する一般的なオプションが含まれます。
DB2およびUDBの文終了文字: IBM DB2およびUDBデータベース用のDDLの終了文字です。
OracleおよびUDBの型置換トリガーの作成: OracleおよびIBM UDB物理モデルで、型置換用にトリガーを作成するかどうかを制御します。
外部キーarc制約用トリガーの作成: 生成されたDDLコードに、外部キーarc制約を実装するトリガーを作成するかどうかを制御します。
転送不可FKのトリガーの作成: 移動不可能な外部キー・リレーションシップ用にトリガーを作成するかどうかを制御します。(外部キー・リレーションシップが移動可能かどうかは、「外部キーのプロパティ」ダイアログ・ボックスの「移動可能」(更新可能)オプションで制御されます。)
Oracle Varchar2およびChar型の文字/バイト単位の表示: OracleのCHAR型またはVARCHAR2型の属性について、その属性の長さに関連付けられた単位(文字またはバイト)が属性に関する列として、リレーショナル・モデル・ダイアグラムおよび生成されたCREATE TABLE文に含まれるかどうかを制御します。
比較機能に「データ型の種類」プロパティを使用: 異なる種類の型が同じネイティブ・データ型を生成しないように(たとえば、ドメインおよび論理型がNumber(7,2)にならないように)、データ型の種類(ドメイン、論理型、固有型など)を考慮する必要があるかどうかを制御します。
DDL: DDL/移行
DDL文の生成時に置換する1組以上の文字列置換を指定できます。それぞれのペアでは、古い文字列と、その古い文字列を置換する新しい文字列を指定します。
選択済: 指定された置換が有効か無効かを制御します。
大/小文字の区別: DDLの古い文字列の大/小文字が、古い文字列として指定した大/小文字と正確に一致する場合にのみ、置換を実行するかどうかを制御します。
「ダイアグラム」ペインには、モデル・ダイアグラムの外観に影響を及ぼす一般的なオプションが含まれます。
一般: ツリーとの同期: オブジェクト・ブラウザのモデルにおけるオブジェクトの選択を反映するように、アクティブなダイアグラムへのフォーカスを自動的に移動させるかどうかを制御します。
多次元モデルで様々な分類タイプを表示するための色およびオプションで接頭辞を指定します。また、ユーザー定義の分類タイプを追加(+または「追加」アイコン)および削除(Xまたは「削除」アイコン)することもできます。
ダイアグラム: フォーマット
様々なタイプの設計オブジェクトの表示のデフォルトのフォントと色、および線のデフォルトの幅と色を指定します。
ダイアグラム: 論理モデル
論理モデルのダイアグラムに適用するオプションが含まれます。
表記法タイプ: 表記法タイプとして、Barker(烏の足とも呼ばれる)またはBachmanを指定します。
ボックス内のボックスにエンティティ継承を表示: スーパータイプのボックス内にあるボックスに、サブタイプを表示します。
ドメインの表示: ドメインに基づく属性のデータ型として何を表示するかを指定します。「ドメイン名」はドメイン名を表示します。「使用されたドメイン・タイプ」はドメイン定義に使用された論理型を表示します。
ダイアグラム: リレーショナル・モデル
リレーショナル・モデルのダイアグラムに適用するオプションが含まれます。
外部キーの矢印方向: 外部キー・リレーションシップの矢印で、その先端が主キーまたは外部キーのいずれを指すかを制御します。
外部キー名の表示: 外部キー名を含むテキスト・ボックスを、外部キー・リレーションシップの矢印に表示するかどうかを制御します。
「モデル」ペインには、数種類のモデルに適用されるオプションが含まれます。
デフォルトRDBMSタイプ: デフォルトのデータベース・タイプです。
デフォルトRDBMSサイト: デフォルトのデータベース・タイプ内のデフォルトのサイトです。
列および属性のデフォルト: NULLの許可: 新しい列と属性がNULL値を持つことができるかどうかを制御します。このオプションを無効にすると、新しい列と属性はデフォルトで必須になります(値が必要になります)。
優先ドメインと論理型: ドメインおよび論理型のドロップダウン・リストに表示される値を限定します。(この機能を使用すると、指定することのないようなドメインおよび論理型がリストに散乱しないようにできます。)ドメインまたは論理型をドロップダウン・リストに表示するには、「優先」側から「すべて」側へ移動します。
モデル: 論理
論理モデルに適用するオプションが含まれます。
リレーション・カーディナリティ: オプションのソース: リレーションシップのソース・エンティティにデフォルトで1つ以上のインスタンスを含める必要があるかどうかを制御します。このオプションが有効である場合、すべてのリレーションシップ・タイプにソース・インスタンスは必要なく、このオプションが無効である場合、すべてのリレーションシップ・タイプに1つ以上のソース・インスタンスが必要になります。
リレーション・カーディナリティ: オプションのターゲット: リレーションシップのターゲット・エンティティにデフォルトで1つ以上のインスタンスを含める必要があるかどうかを制御します。このオプションが有効である場合、すべてのリレーションシップ・タイプにターゲット・インスタンスは必要なく、このオプションが無効である場合、すべてのリレーションシップ・タイプに1つ以上のターゲット・インスタンスが必要になります。
主キーとして最初の一意識別子を使用して設定: エンティティを作成するときに、最初の一意識別子の属性をデフォルトでプライマリ一意識別子にするかどうかを制御します。
FK属性名の同期: 元の属性の名前として維持する: スーパータイプまたは参照される属性が、一意識別子(外部キー)のネーミングに使用される必要があるかどうかを制御します。その他の名前を指定する場合は、このオプションを選択解除してください。
モデル: 物理
物理モデルに適用するオプションが含まれます。様々なオプションが、サポートされている各データベース・タイプに適用されます。
DB2に対して、いくつかのオプションにネーミング・ルールを指定し、入力したネーミング・ルール文字列に変数を追加できます。たとえば、 「表ごとに表領域を作成」に、TBLS_と入力してから「変数の追加」をクリックして、{model}を選択すると、表の作成および名前の変更を行うたびに、対応する表領域がTBLS_+表名として作成または名前変更されます。
モデル: リレーショナル
リレーショナル・モデルに適用するオプションが含まれます。
外部キー列の削除方針: ユーザーがある表を削除しようとしたときに、その表を指す1つ以上の生成済外部キー列(他の表の列)が削除対象の表に含まれている場合、Data Modelerがどのような動作を行う必要があるかを指定します。指定する動作としては、外部キー列を削除する、外部キー列を削除しない、または外部キー列の削除について確認を求める、といった動作があります。
例として、第2章「Data Modelerチュートリアル: 小規模データベースのモデリング」のリレーショナル・モデルを使用すると、Books表を削除する場合、Transactions表にはBooks表の主キーを参照するbook_id外部キー列が含まれています。このオプションの選択は、Books表を削除する場合に、Transactions.book_id列に対して何が行われるかを決定します。
デフォルトの外部キー削除ルール: 外部キー・リレーションシップに関与するデータが含まれる列を削除しようとしたときに何が行われるかを指定します。
アクションなし: 削除が許可されないことを示すエラー・メッセージが表示されます。削除はロールバックされます。
カスケード: 外部キー・リレーションシップに関与するデータが含まれるすべての列が削除されます。
NULLを設定: 表のすべての外部キー列がNULL値を受け入れることができる場合は、値をNULLに設定します。
「ネーミング標準」ペインを使用すると、ネーミングの標準化を実装でき、論理およびリレーショナル・モデル・オブジェクト用およびドメイン用のネーミング標準を表示、追加および変更できます。「設計ルール」を適用するときに、これらの標準が確認され、標準違反があればすべれエラーまたは警告として報告されます。また、オブジェクト・ブラウザのモデル名を右クリックし、「キーと制約へのネーミング標準の適用」を選択すると、ネーミング標準をリレーショナル・モデルの主キーと外部キー、制約および索引にも適用することができます。
ネーミングの標準化を「名前略語」ダイアログ・ボックスの使用と混同しないでください。このダイアログ・ボックスでは、スペルおよび略語に一貫性を確保して、名前の変更が即座に行われます。また、リレーショナル・モデル名の文字列のみが対象になります。
論理、リレーショナル、ドメイン
論理モデルのエンティティと属性、リレーショナル・モデルの表と列、およびドメインに対して、オブジェクト名の構成要素(主要語、類語、修飾子および限定子)を追加または再配置したり、それらをオプションまたは必須にすることができます。これらの構成要素の許容値は、「用語集」ペインで指定する用語集ファイルに明記されます。
タイトルの大文字小文字(「セパレータ」オプション): 各単語の先頭が大文字になり、空白が含まれないことを意味します。例: GovernmentAccounts(タイトルの大文字/小文字は、CamelCaseと呼ばれる場合があります。)
省略語のみ: このオプションを有効にすると、省略されていない単語はリレーショナル・モデル・オブジェクト名で使用できません(つまり、使用できるのは、省略された単語のみです)。
他の用語の説明については、3.43「用語集エディタ」を参照してください。ネーミング標準の詳細は、『United States Coast Guard Data Element Naming Standards Guidebook』を参照してください。
用語集
ネーミングの標準化に使用する1つ以上の用語集ファイルを追加できます。(用語集についての詳細な説明は、3.43「用語集エディタ」を参照してください。)
ネーミング標準: テンプレート
表およびエンティティの様々な制約について、その書式文字列を編集したり、変数文字列要素を追加することができます。
例: 現在指定されている書式のサンプル名を参照するには、目的の制約タイプ(外部キーなど)を選択します。
「サード・パーティ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)の場合: http://www-01.ibm.com/software/data/db2/express/additional-downloads.html
追加するドライバごとに、「追加」(+)アイコンをクリックして、ドライバのパスを選択します。
「拡張機能」ペインでは、Data Modelerの起動時に使用されるオプションの拡張機能を決定します。(Data Modelerでは、必須の拡張機能も使用されます。この拡張機能は、削除したり、無効にすることはできません。)設定を変更する場合、新しい設定を有効にするには、Data Modelerを終了して再起動する必要があります。
「バージョニング・サポート」の設定(選択されているかどうかと、選択した場合は構成オプション)は、「バージョニング」メニューが表示されるかどうかとそのメニュー項目に影響します。
構成: 「拡張機能の構成」ダイアログ・ボックスを表示します。
「無視するファイルのリスト」ペインでは、あらゆる処理で使用しないファイルおよびファイル・タイプを決定するフィルタを指定します。
新規フィルタ: (フィルタが有効になっている場合や選択されている場合に)Data Modelerがすべての処理で無視する、(「フィルタ」ボックスの)ファイルおよびファイル・タイプのリストに追加するファイル名またはファイル・タイプ。mumble.txtなど、完全なファイル名を入力して特定のファイルを除外するか、または*.txtなど、ファイル・タイプを示す構成要素を入力して同じタイプのすべてのファイルを除外することもできます。
追加: 新しいフィルタを「フィルタ」ボックスのリストに追加します。
削除: 選択したフィルタを「フィルタ」ボックスのリストから削除します。
デフォルトに戻す: 「フィルタ」ボックスの内容をData Modelerのデフォルトに戻します。
フィルタ: ファイルおよびファイル・タイプのリストを含みます。各項目が有効な(選択されている)場合は、フィルタが適用され、ファイルまたはファイル・タイプはData Modelerによって無視されますが、無効な(選択解除されている)場合は、フィルタは適用されません。
「マウスオーバー・ポップアップ」ペインでは、関連するオブジェクト名にマウスが置かれたときに表示するテキストを指定します。
ポップアップ名: 表示する情報のタイプで、「データ値」(変数の値など、マウス・ポインタの下のアイテムの値)、「ドキュメント」(メソッド・コールに関するJavadocなど、マウス・ポインタの下のアイテムに関するドキュメント)または「ソース」(メソッドのソース・コードなど、マウス・ポインタの下のアイテムのソース・コード)があります。
次の方法でアクティブ化: マウス・カーソルによる処理(ホバーまたは指定した1つまたは2つの修飾キーを押しながらのホバー)を使用して表示をアクティブ化します。
説明: 関連する「ポップアップ名」エントリの説明。
スマート対応: このオプションを選択すると、「スマート・ポップアップ」も選択されている場合、関連するタイプの情報のテキストが表示されます。
スマート・ポップアップ: このオプションを選択すると、マウスが置かれた項目に対する最初のスマート対応ポップアップに関連するテキストが表示されます。
「ショートカット・キー」ペインを使用すると、ショートカット・キー(アクセラレータ・キーとも呼ぶ)・マッピングをData Modeler用に表示およびカスタマイズできます。
アンマップ・コマンドの非表示: このオプションを選択すると、マッピングのあるショートカット・キーのみが表示されます。
その他のアクション:
エクスポート: ショートカット・キー定義をXMLファイルにエクスポートします。
インポート: 以前にエクスポートしたXMLファイルからショートカット・キー定義をインポートします。
キーボード・スキームのロード: 現在のすべてのショートカット・キー・マッピングを削除し、指定したスキームでマッピングを設定します。(このオプションは、以前のリリースでは「初期設定のロード」と呼ばれていました。)マッピングを変更し、デフォルトの設定をリストアする場合は、 「デフォルト」を選択します。
カテゴリ: 特定のカテゴリ(「コード・エディタ」、「比較」など)にグループ化されたコマンドおよびショートカットをリストし、表示するアクションを制御します。
コマンド: 指定されたカテゴリに関連するアクションです。アクションを選択すると、既存のショートカット・キー・マッピングが表示されます。
ショートカット: 選択したアクションの既存のキー・マッピング。既存のキー・マッピングを削除するには、削除するキー・マッピングを選択して「削除」をクリックします。
新しいショートカット: アクションに関連付ける新しいショートカット・キー。目的の修飾子キーを押しながら、もう一方のキーを押します。たとえば、[Ctrl]キーと[J]キーをアクションに関連付けるには、[Ctrl]キーを押しながら[J]キーを押します。そのショートカット・キーになんらかのアクションが現在関連付けられている場合、「現在の割当て」ボックスに表示されます。
競合: 「新しいショートカット」ボックスで指定したショートカット・キーにマップされている現在のアクション(ある場合)の読取り専用表示。
「バージョニング」プリファレンスは、Data Modelerで使用できるバージョン制御および管理システムの動作に影響します。Data Modelerによるバージョニングの使用の詳細は、1.9「バージョニングの使用」を参照してください。
「Subversion」ペインでは、Data Modelerで使用するSubversionクライアントを指定します。
バージョニング: Subversion: コメント・テンプレート
「Subversion: コメント・テンプレート」ペインでは、コミット操作で使用するコメントのテンプレートを指定します。たとえば、テンプレートには、次のようなテキストが含まれる場合があります。
Problem Description (with bug ID if any): Fix Description:
コメント・テンプレートは、追加、編集および削除することができ、テンプレートをXMLファイルにエクスポートしたり、以前にエクスポートしたテンプレートをインポートすることもできます。
バージョニング: Subversion: 一般
「Subversion: 一般」ペインでは、環境設定および操作タイムアウトを指定します。
ナビゲータで状態オーバーレイ・アイコンを使用: このオプションを有効にすると、状態オーバーレイ・アイコンが使用されます。状態オーバーレイ・アイコンは、ナビゲータのオブジェクト名に関連付けられた小さいシンボルです。バージョン制御されたファイルの状態(最新など)を示します。
ナビゲータで状態オーバーレイ・ラベルを使用: このオプションを有効にすると、状態オーバーレイ・ラベルが使用されます。状態オーバーレイ・ラベルは、ナビゲータのオブジェクト名に関連付けられたツールチップです。
自動的にファイルを編集可能にする: このファイルを有効にすると、データ・ファイルの変更を開始するときにエディタが自動的に使用されます。(誤ってファイルを編集した場合は、すぐに「バージョニング」→「編集解除」を使用して元に戻します。)
操作タイムアウト: Subversion操作の完了までに許容される最大時間。
Subversion構成ファイルの編集: 直接Subversionファイルを変更するには、「"server"の編集」をクリックします。
バージョニング: Subversion: バージョン・ツール
「Subversion: バージョン・ツール」では、保留中の変更ウィンドウおよびマージ・エディタのオプションを指定します。
変更のコミット送信時にダイアログを使用: 「保留中の変更」ウィンドウが開いているときに、制限のある画面領域を最適に使用できます。「保留中の変更」ウィンドウの「コメント」領域を表示させないことで画面領域を節約できますが、それでもコミット・アクションの前にコメントを追加する必要がある場合もあります。「コミット」ダイアログの開き方(常に開くのか、「保留中の変更」ウィンドウの「コメント」領域が非表示の場合のみ開くのか、開かないのか)を選択できます。
受信変更タイマー・インターバル: ファイルの変更ステータスがチェックされる頻度。
エディタのマージ: ローカルまたはサーバーでファイルをマージするかどうかを指定します。
「Webブラウザとプロキシ」ペインの設定は、Data ModelerがWorld Wide Webへのアクセスを必要とし、システムがファイアウォールで保護されている場合にのみ関係します。
ブラウザのコマンド・ライン: デフォルト・ブラウザ以外のWebブラウザを指定する場合、そのブラウザを起動するための実行可能ファイルを指定します。デフォルト・ブラウザを使用する場合、このフィールドは空白のままにします。
HTTPプロキシ・サーバーの使用: このフィールドに適切な値を指定するには、Webブラウザのオプションまたはプリファレンスを確認します。
作業中の設計(または設計の一部)を格納する場合は、保存またはエクスポートを実行できます。
設計を保存すると、設計のすべての要素(論理モデル、リレーショナル・モデル、物理モデル、プロセス・モデルおよびビジネス情報)を保存できます。XMLファイルおよびディレクトリ構造(1.3.1「データベース設計」を参照)は、新しい設計では作成され、既存の設計では更新され、設計は、Data Modeler形式で格納されています。
設計を保存するには、「ファイル」→「保存」をクリックします。事前に設計が保存されていない場合は、場所およびXMLファイル名を指定します。別のファイルおよびディレクトリ構造で設計を保存するには、「ファイル」→「別名保存」をクリックします。
設計をエクスポートすると、設計の一部(論理モデル、物理モデル以外のリレーショナル・モデル、およびデータ型モデル)をファイルに保存できます。エクスポートは、Oracle以外およびOracleの様々な形式で行うことができます。このように、エクスポートすることで、出力形式に柔軟性がもたらされますが、Data Modelerの出力のみが必要な場合は、保存することで、より多くの設計オブジェクトを保存できます。
設計をエクスポートするには、「ファイル」→「エクスポート」→「出力形式」をクリックします。
保存された設計を使用するには、「ファイル」→「開く」をクリックすると開くことができます。設計を開くと、保存された設計のすべてのモデルおよびオブジェクトが使用できるようになります。保存された物理モデルは、最初はオブジェクト・ブラウザには表示されませんが、目的のリレーショナル・モデルで物理モデルを右クリックして「開く」を選択し、データベース・タイプ(Oracle 11gなど)を指定すると、物理モデルを表示できます。
Data Modelerで保存された設計、または別のデータ・モデリング・ツールでエクスポートまたは保存された設計を使用する場合は、「ファイル」→「インポート」をクリックし、インポートする設計のタイプを指定すると、インポートできます。通常、ファイルを指定してから、インポートの対象を制御できるウィザードを使用します。
開いたり、インポートするテキスト・ファイルは、オペレーティング・システムのロケール設定でサポートされている形式でエンコードされている必要があります。文字のエンコーディングおよびロケールの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。
この項の残りの部分では、特定のタイプのファイルおよび他のソースからのインポートについて説明します。
DDLファイルをインポートすると、既存のデータベース実装に基づいたリレーショナル・モデルを作成できます。元になるDDLファイルとして、サポートされているすべてのデータベース・タイプおよびバージョンのものが可能です。インポートされるファイルには、通常、.ddlまたは.sqlの拡張子があります。
インポート・プロセスでは、インポートされるDDLファイルの名前で新しいリレーショナル・モデルが作成され、ソース・サイトを反映した物理モデルが開きます。
キューブ・ビュー・メタデータをインポートすると、指定されたXMLファイルに反映されるように、既存の実装に基づいた多次元モデル作成できます。
Microsoft XMLAからインポートすると、Microsoft XMLAファイル形式で格納される多次元モデルを作成できます。
ERwinファイルをインポートすると、ERwinモデリング・ツールからモデルを取得できます。インポートするモデルの定義が含まれるXMLファイルを指定します。
データ・ディクショナリからのインポートを行うと、既存のデータベース実装に基づいたリレーショナル・モデルおよび物理モデルを作成できます。元になるデータ・ディクショナリとして、サポートされているすべてのデータベース・タイプおよびバージョンのものが可能です。
データ・ディクショナリからインポートするウィザードでは、既存のデータベース接続を選択するか、新しいデータベース接続を作成(追加)する必要があります。その後で、指示に従って、スキーマまたはデータベースを選択し、さらにインポートするオブジェクトを選択します。
データ・ディクショナリからインポートした後、必要に応じてリレーショナル・モデルおよび物理モデルを編集できます。また、リレーショナル・モデルから論理モデルをリバース・エンジニアすることができます。
Oracle Designerモデルをインポートすると、既存のOracle Designerモデルに基づいたリレーショナル・モデルおよび物理モデルを作成できます。Oracle Designerリポジトリへの接続を作成し、エンティティ、表およびドメインをDesignerのワークスペースからインポートできます。
Oracle Designerモデルのインポートウィザードでは、既存のデータベース接続を選択するか、新しいデータベース接続を作成(追加)する必要があり、その後で、指示に従って、作業領域、アプリケーション・システムおよびインポートするオブジェクトを選択します。(Oracle Designer dataflowダイアグラムをインポートすることはできません。)
Oracle Designerモデルをインポートした後、必要に応じてリレーショナル・モデルおよび物理モデルを編集できます。また、リレーショナル・モデルから論理モデルをリバース・エンジニアすることができます。
Data Modeler設計をインポートすると、以前にData Modelerからエクスポートした設計から、論理モデル、リレーショナル・モデルおよびデータ型モデルを取得できます。
ドメインをインポートすると、既存のドメイン定義を変更および拡張できます。「ドメインのインポート」ダイアログ・ボックスで、インポートするドメインを選択したり、インポートしないドメインを選択解除(クリア)します。
次のData Modeler情報をエクスポートおよびインポートできます。
ユーザー・プリファレンス(1.5「Data Modelerのユーザー・プリファレンス」を参照)
データ・ディクショナリからのインポート用に作成した接続などの接続(3.18「データ・ディクショナリ・インポート(メタデータ抽出)」を参照)
最新の設計(「ファイル」→「最新の設計」をクリックすると表示されます)
この情報をエクスポートするには、「ツール」→「プリファレンス」→「Data Modeler」をクリックしてから「エクスポート」をクリックします。後で現在のインストールを削除した場合にファイルが失われる可能性があるため、Data Modelerをインストールした場所の下のディレクトリまたはフォルダ指定しないでください。
前にエクスポートされた情報をインポートするには、「ツール」→「プリファレンス」→「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のインストール時と同じ内容で作成されます。
ショートカット・キー(アクセラレータ・キー)のマッピングに変更を加えた場合は、「ツール」、「プリファレンス」、「ショートカット・キー」、「その他のアクション」、「キーボード・スキームのロード」の順にクリックした後で「デフォルト」を選択すると、マッピングをシステムのデフォルトに戻すことができます。
次の方法でData Modelerオブジェクトにレポートを表示できます。
ローカル・ドライブにRTF、HTMLまたはPDFファイルとしてレポートを生成してからファイルを開きます。詳細は、1.8.1「RTF、HTMLまたはPDFファイルとしてのレポートの生成」を参照してください。
SQL Developerを使用して、Data Modelerレポート・リポジトリの情報に基づいたレポートを表示します。詳細は、1.8.2「SQL Developerを使用したエクスポートされたレポート・スキーマ・データの表示」を参照してください。
個々のレポートをRTF(Microsoft Word形式)、HTMLまたはPDFファイルとして保存してから、個々のレポートを表示できます。HTMLでは、いくつかの個別のファイルが生成されます。ファイルは「Data Modeler」プリファレンスの下の「デフォルトのレポート・ディレクトリ」で指定された場所またはデフォルトの場所に格納されます。
Data Modelerは、各ファイルに一意の名前を確保します(たとえば、すべての表でレポートを生成した場合にAllTablesDetails_1.rtfがすでに存在すると、AllTablesDetails_2.rtfが作成されます)。(レポート・スキーマのレポート・リポジトリからレポート・ファイルを生成する場合、ファイル名には、_rsが含まれます(たとえば、AllTablesDetails_1_rs.rtf)。)
次のいずれかのアプローチを使用してレポート・ファイルを生成できます。
現在ロードされている設計に基づいてレポートを生成します。(この方法には、レポート・スキーマおよびレポート・リポジトリの作成または使用は含まれていません。)
レポート・スキーマのレポート・リポジトリ(1.8.3「レポート・リポジトリおよびレポート・スキーマ」で説明されています)の情報に基づいてレポートを生成します。
RTF、HTMLまたはPDF形式で格納されているレポートを生成および表示するには、次の手順に従います。
「ファイル」→「レポート」をクリックします。
「使用可能なレポート」で、表、エンティティ、ドメイン、語彙解説などの情報をレポートするオブジェクトのいずれかのタイプを選択します。
オプションで、「全オブジェクトを含む」を選択してレポートに選択したタイプのすべてのオブジェクトのついての情報を含めます。
「全オブジェクトを含む」を選択しない場合、「ロードされた設計」タブの「選択したオブジェクト」の横の「選択」をクリックして、オブジェクトを名前で選択します。
「テンプレート」の下で、オプションとして使用するレポート・テンプレートを選択します。レポート・テンプレートを使用して、レポートに含めるオブジェクトのタイプをカスタマイズできます。
レポート・テンプレートを作成および管理するには、「管理」をクリックして、「レポート・テンプレート管理」ダイアログ・ボックスを表示します。
(必要なタブがまだ選択されていない場合)次のいずれかのタブをクリックします。
ロードされた設計: 1つ以上の現在ロードされたData Modeler設計に基づいてレポートを生成します
レポート・スキーマ: レポート・スキーマのレポート・リポジトリの設計に基づいてレポートを生成します
使用可能な設計で、必要なData Modeler設計を選択します。
「使用可能なモデル」で、必要なモデルを選択します。(モデルのリストは、レポートのオブジェクトのタイプを反映しています。)
「選択したサブビュー」(使用可能なものがある場合)で、レポートを生成するサブビューを選択します。
「選択したオブジェクト」(「全オブジェクトを含む」を指定していない場合のみ)で、「選択」をクリックしてレポートするオブジェクトを指定します。
「レポートの生成」をクリックします。
レポートの場所およびファイル名付きのメッセージが表示されます。
ファイルに移動し、開きます。
Oracle SQL Developerのレポート機能を使用して、Data Modelerレポート・リポジトリにエクスポートされた情報を表示できます。設計に関する情報をレポート・リポジトリにエクスポートするには、1.8.3「レポート・リポジトリおよびレポート・スキーマ」の指示に従います。
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のレポート・リポジトリは、Data Modelerの設計に関するメタデータおよびデータを格納するデータベース・スキーマ・オブジェクトのコレクションです。レポート・リポジトリが格納されているスキーマは、レポート・スキーマと呼ばれます。
Data Modelerのレポート・リポジトリ用に個別のデータベース・ユーザーを作成し、そのスキーマをレポート・リポジトリにのみ使用することをお薦めします。たとえば、DM_REPORT_REPOSという名前のユーザーを作成し、そのユーザーに少なくともCONNECTおよびRESOURCE権限を付与します。(別の目的で使用されている既存のスキーマにレポート・リポジトリを作成することもできますが、それを把握し続けることが困難になる場合があります。)
|
注意: Data Modelerの旧バージョンからのレポート・リポジトリを使用し続ける場合は、datamodeler/reportsディレクトリのReporting_Schema_Upgrade_readme.txtファイルを参照してください。データベース接続およびスキーマを保持したまま新しいレポート・リポジトリの作成から開始する場合は、既存のリポジトリを削除してから(このトピックで後述)、レポート・リポジトリを作成します。 |
レポート・リポジトリを作成するには、次の手順に従います:
「ファイル」→「エクスポート」→「レポート・スキーマへ」をクリックします。
「レポート・スキーマにエクスポート」ダイアログ・ボックスで、「接続の追加」(+)アイコンをクリックします。
データベース接続の新規作成/更新ダイアログ・ボックスで、接続の名前(たとえば、dm_reporting_repos_conn)および接続のその他の情報(レポート・スキーマに関連付けられているデータベース・ユーザーのユーザー名とパスワードを含む)を入力します。
オプションで、「テスト」をクリックして、接続をテストします。(テストに成功しなかった場合は、エラーを修正します。)
「OK」をクリックし、接続を作成して、データベース接続の新規作成/更新ダイアログ・ボックスを閉じます。
ダイアログ・ボックスの上部の接続のリストで、接続名を選択(クリック)します。
「OK」をクリックして、選択した接続に関連付けられているスキーマにレポート・リポジトリを作成して、選択したモデルに関する情報をそのリポジトリにエクスポートします。
既存のレポート・リポジトリを削除するには、次の手順に従います:
「ファイル」→「エクスポート」→「レポート・スキーマへ」をクリックします。
レポート・リポジトリに関連付けられているスキーマの削除対象の接続を選択します。
「レポート・スキーマにエクスポート」ダイアログ・ボックスで、「メンテナンス」タブをクリックします。
「リポジトリの削除」をクリックして、レポート・リポジトリを削除することを確認します。
リポジトリ全体ではなく、リポジトリ内の選択した設計のみを削除する場合、「設計の削除」をクリックして、削除対象の設計を選択します。
「レポート・スキーマにエクスポート」ダイアログの「用語集」タブを使用して、用語集に対して次の操作を実行できます。
用語集のエクスポート: Data Modelerの用語集ファイルを指定して、その情報をレポート・リポジトリにエクスポートします。
用語集の削除: レポート・リポジトリで用語集を選択して、リポジトリからその情報を削除します。
Data Modelerでは、Data Modeler設計でのSubversionのバージョニングおよびソース制御システムの使用を統合的にサポートしています。設計をSubversionリポジトリに格納して、次のような通常のバージョン制御を実現します。
正式版の設計を、様々なフォルダやディレクトリではなく中央リポジトリに格納します。
複数の開発者が同じ設計で作業できるようにします(従来のSubversionのチェックアウトおよびコミット・プロセスを使用して、変更を調整します)。
Data Modelerのドキュメントでは、SVN概念および操作について理解しているか、確認できることを前提としているため、その詳細を説明しません。Subversionの詳細は、http://subversion.tigris.org/を参照してください。Subversionのドキュメントについては、http://svnbook.red-bean.com/を参照してください。
Data Modelerのバージョニング機能にアクセスするには、「バージョニング」メニューを使用します。
バージョニング・リポジトリを作成するか、既存のリポジトリに接続する場合は、バージョニング・ナビゲータのリポジトリの階層表示およびその内容を使用できます。(ナビゲータが表示されない場合は、「表示」→「バージョニング」をクリックします。)
Data Modelerを介してSubversionリポジトリを使用するには、Subversionリポジトリへの接続を作成する必要があります。ローカルのSubversionリポジトリを作成すると、そのリポジトリへの接続が自動的に作成されて、「Subversionナビゲータ」に表示されます。これによって、接続の詳細を編集できるようになります。
既存のファイルをバージョン管理の対象にするには、「Subversion」リポジトリにそれらのファイルをインポートする必要があります。その後、ファイルは「Subversion」リポジトリからローカル・フォルダ(「Subversion作業用コピー」と呼ぶ)にチェックアウトされます。Data Modelerに作成されたファイルは、Subversion作業用コピーに格納する必要があります。
Data Modeler内に新しく作成されたファイルは、バージョン制御に追加する必要があります。変更されたファイルおよび新しいファイルは、Subversionリポジトリに対してコミットされると、他のユーザーも利用できるようになります。Subversion作業用コピーは、Subversionリポジトリの内容を反映して更新し、他のユーザーによる変更を取り込むことができます。
「保留中の変更」ウィンドウは、「バージョニング」→「保留中の変更」をクリックするか、ローカル・ソース・ファイルの制御状態が変更される操作を開始した場合に表示されます。このウィンドウには、(ローカルまたはリモートで)追加、変更または削除されたファイル、他バージョンの同じファイルと内容が競合するファイル、監視対象のソース制御ファイルに追加されていないファイル、およびエディタを取得したファイルが表示されます。この情報を使用して競合を検出し、可能であれば解決できます。
「送信の変更」ペインにはローカルで行われた変更が、「受信の変更」ペインにはリモートで行われた変更が、「候補」ペインにはローカルで作成され、ソース制御に追加されていないファイルが表示されます。ファイル名をダブルクリックすると、ファイルを編集できます。コンテキスト・メニューを使用すると、使用可能な操作を実行できます。
Data Modelerの設計でSubversionを使用するには、次のものが必要です。
設計の作業ディレクトリとして機能するローカル・システム上のフォルダまたはディレクトリ。この作業ディレクトリで設計を作成して、この作業ディレクトリに設計を保存して、この作業ディレクトリから設計を開きます。
接続が可能で、初回バージョンの設計(と後続のあらゆるバージョン)のブランチであるbranchesの下に作成できるSubversionリポジトリ。
推奨の基本手順は次のとおりです。これらは、特定のプロジェクトに対して実行できる唯一の手順ではなく、必ずしも最適な手順ではない場合もあります。これらの手順では、多数のアクションを実行するためにData Modelerでのバージョン管理ナビゲータおよびインポート・ウィザードの使用が反映されていますが、これらのアクションは、個別のSVNリポジトリ・ブラウザ(TortoiseSVNブラウザなど)を使用しても、ローカル・システムでSVNコマンドを使用しても実行できます。
ローカル・システムで、設計固有の作業ディレクトリの親として機能するディレクトリまたはフォルダを作成します。たとえば、Windowsコンピュータで次を作成します。
C:\designs
ローカル・システムで、前述の手順で作成したディレクトリまたはファイルの下に、作成する設計の作業ディレクトリとして機能するディレクトリまたはファイルを作成します。たとえば、libraryという名前の設計用に、次を作成します。
C:\designs\library
Data Modelerで、設計を作成して(たとえば、第2章「Data Modeler チュートリアル: 小規模データベースのモデリング」の図書館の設計)、その設計を作成した作業ディレクトリに保存します。たとえば、次の場所に設計を保存します。
C:\designs\library
設計を保存すると、作業ディレクトリに.dmdファイルおよび関連するディレクトリ構成が作成されます。.(.dmdファイルおよびディレクトリ構造は、1.3.1「データベース設計」で説明されています。)
設計を閉じます。(Data Modelerを終了しないでください。)
使用するリポジトリにSVN接続を作成します。
バージョニング・ナビゲータで、最上位ノード(Subversion)を右クリックして、「新規リポジトリ接続」を選択します。
Subversion: Subversion接続の作成/編集ダイアログ・ボックスに情報を入力します。リポジトリURLの例: https://example.com/svn/designs/
リポジトリ・パスの下にbranchesディレクトリを作成します。
バージョニング・ナビゲータで、リポジトリ・パスを右クリックして、「新規リモート・ディレクトリ」を選択します。
「Subversion: リモート・ディレクトリの作成」ダイアログ・ボックスで、情報を入力して、「ディレクトリ名」としてbranchesを指定します。
branchesディレクトリの下にプロジェクト固有のブランチを作成します。
バージョニング・ナビゲータで、branchesディレクトリを右クリックして、「新規リモート・ディレクトリ」を選択します。
「Subversion: リモート・ディレクトリの作成」ダイアログ・ボックスに情報を入力します。ディレクトリ名の例: library
たとえば、第2章「Data Modelerチュートリアル: 小規模データベースのモデリング」でライブラリ・デザインの作成を予定している場合、このブランチのリポジトリのURLは次のようになります。
https://example.com/svn/designs/branches/library
「Subversion: Subversionへのインポート」ウィザードを使用して、設計ファイルをリポジトリへインポートします。「バージョニング」→「ファイルのインポート」をクリックして、ウィザード・ページを次のように入力します。
宛先: SVN接続およびファイルをインポートするリポジトリ・パスを指定します。例: root/branches/library
ソース: ファイルをインポートするソース・ディレクトリ(つまり.dmdファイルおよび設計固有のフォルダ階層を含むディレクトリ)を指定します。例: C:\designs\library
フィルタ: デフォルトを受け入れて「次へ」をクリックします。
オプション: デフォルトを受け入れて「次へ」をクリックします。
サマリー: 情報を表示して、「終了」をクリックします。
SVNコンソール・ログには、ファイルの追加時の進行状況が表示されます。ファイルを追加すると、「新規ファイルの処理」ダイアログ・ボックスが表示されます。
「新規ファイルの処理」ダイアログ・ボックスで、「ファイルを開かない」を選択して、「OK」をクリックします。
追加されたファイルを表示するには、「バージョニング・ナビゲータ」タブの「リフレッシュ」アイコンをクリックします。
設計の後続の作業では、Subversionベースのプロジェクト(SVNの更新、SVNのロック、ファイルの変更、SVNのコミット)の通常のワークフローに従います。
特に指定がないかぎり、Data Modelerの使用に関するアクセシビリティ情報は、SQL Developerの使用と同じです。SQL Developerのアクセシビリティ情報の詳細は、SQL Developerのオンライン・ヘルプまたは『Oracle SQL Developerユーザーズ・ガイド』を参照してください。
データ・モデリングの詳細(高度な資料など)は、次の情報を参照してください。
ホワイト・ペーパー、ビューレット(画面デモンストレーション)、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、http://www.omg.org/spec/CWM/)仕様)
『United States Coast Guard Data Element Naming Standards Guidebook』(http://www.tpub.com/content/USCGCI/CI_5230_42A/)(特にネーミング標準に関連する概念および推奨事項)
