ベスト プラクティス
ER/Studio Data Architect の使用 への移動
このページには次のトピックが含まれています。
- ER/Studio Data Architect のベスト プラクティス
- 説明的なオブジェクト名の使用
- データベース オブジェクトへのコメントの追加
- オブジェクトの色での塗り分け
- 繰り返し作業へのマクロの使用
ER/Studio Data Architect のベスト プラクティス
説明的なオブジェクト名の使用
データ モデルのすべてのオブジェクト、たとえばエンティティ、属性、アタッチメント、名前付け標準テンプレート、およびドメインなどには名前が付いており、モデル エクスプローラ、モデル ウィンドウ（データ モデルの作業領域）、ログ、およびレポートでオブジェクトの識別に使用されます。
データの流れを分かりやすくするには、オブジェクトの役割を説明する名前を付けてください。たとえば、「エンティティN」のようなデフォルト名のままにせずに、「顧客」などの名前を付けます。
- 1 つのモデルに、同じ名前で複数のエンティティを配置できます。ただし、エンティティ名とその所有者の組み合わせは一意である必要があります。エンティティ/テーブルの［所有者］プロパティは、エンティティ/テーブル エディタで編集できます。
オブジェクトの名前には、英字（大文字、小文字、またはその両方）および日本語を使用できます。英字を使用する場合、一般的に読みやすく理解しやすいのは、大文字と小文字を併用して各単語の先頭を大文字にする形式（たとえば、CustomerAddress）です。
- 名前付け標準を作成してテーブルやエンティティにバインドすると、命名ルールを適用できます。また、ドメインを作成することもできます。詳細は、「名前付け標準テンプレートを使用した名前付け標準の適用」を参照してください。
データベース オブジェクトへのコメントの追加
データ モデル内のすべてのオブジェクトには説明または定義があり、それらはレポートを作成したときに含まれます。すべてのオブジェクトに説明や定義を入力しておくと、データ モデルを文書化する際に役立ちます。オブジェクトの目的や、他のモデル作成者がオブジェクトの役割を理解するのに必要な情報を記述します。また、ほとんどのデータベース オブジェクトにコメントを追加することもできます。詳細は、「オブジェクト コメントの追加と編集」を参照してください。
対象データベースがテーブル コメントをサポートする場合、物理データベースの生成時にエクスポートされた SQL コードに、エンティティ定義がテーブル コメントとして追加されます。
リレーションシップに説明を追加すると、データ モデルを分かりやすくすることができます。リレーションシップには、リレーションシップを説明する動詞句を作成できます。たとえば、「会社」は「従業員」を監督する「マネージャ」を雇用します（下図を参照）。リレーションシップの動詞句を作成するには、リレーションシップをダブルクリックして、リレーションシップ エディタの［動詞句］タブに動詞句（親から子/子から親）を入力します。動詞句（子から親）は、子の視点からリレーションシップを説明します。
オブジェクトの色での塗り分け
オブジェクトに色を付けると、ダイアグラムの外観が良くなり、分かりやすくなります。詳細は、「ダイアグラムのデフォルトの色とフォントの設定」および「特定オブジェクトの色およびフォント設定のオーバーライド」を参照してください。
繰り返し作業へのマクロの使用
ER/Studio Data Architect には、Sax Basic で書かれた多数のサンプル マクロが含まれています。そのまま使用したり、必要に応じてユーザーがカスタマイズできます。このガイドのチュートリアルでは、マクロを使用して作業時間を節約する例を説明しています。サンプル マクロのヘッダーには使用法が記述されていますが、コード全体に目を通すことで、そのマクロがどのように役立つのか理解できるでしょう。サンプル マクロがすべてのユーザー環境で正しく動作することは保証されていませんが、必要に応じて、オンライン コミュニティで他のユーザーと意見交換したり、Embarcadero サポートに問い合わせることができます。
マクロ エディタで使用される Sax Basic Engine は、Microsoft Visual Basic for Applications と互換性があります。このガイドには、Sax Basic の構文や使用法についての詳しい説明は記載されていませんが、初心者は、多数出版されている Visual Basic 関連の入門書で学習することができます。チュートリアルでは、マクロを使用して作業時間を節約する例を説明しています。
ER/Studio Repository のベスト プラクティス
アクティブ ファイル ディレクトリと Repository からのダイアグラムの取得
アクティブ ファイル ディレクトリとは、［Repository から取得...］操作でダイアグラムを取得したときに、Repository のローカル ファイルが保存される場所です。この操作を実行したときに得られる結果は 2 種類あります。
- Repository のマージ： アクティブ ファイル ディレクトリにダイアグラム（dm1 ファイル）のローカル コピーが存在する場合、Repository によって Repository のモデルとローカル モデルがマージされます。ローカルの dm1 ファイルと Repository の dm1 ファイルの間で変更が矛盾している場合、［変更の確認および矛盾の解決］ダイアログ ボックスが表示され、矛盾を解決することができます。ダイアグラムのローカル コピーがチェックインされている場合（すべてのオブジェクトに青い鍵アイコンが付いた状態）、そのローカル コピーが開き、［最新ダイアグラムの取得］操作が実行されます。
- 完全な取得： アクティブ ファイル ディレクトリにローカル コピーが存在しない場合、Repository によってモデルの新規コピーが作成されます。解決が必要な矛盾は存在しません。通常、この操作は、取得処理中に Repository の dm1 ファイルとローカルの dm1 ファイルの間で変更をマージしなければならない場合よりも高速です。
ダイアグラム全体か 1 つのサブモデルだけを取得することができます。dm1 ファイルの一部または全体のどちらを取得しても、ローカルのファイル名は同じになります。このため、Repository からモデル全体を取得しているのでなければ、サブモデル間の切り替えは困難です。1 つのサブモデルしか変更しない予定であれば dm1 ファイルの一部だけを取得してもかまいませんが、それ以外の場合にはダイアグラム全体を取得した方が賢明です。dm1 ファイル全体を取得すると、複数のサブモデル間や論理/物理モデル間を簡単に切り替えることができます。また、dm1 ファイルの一部のみを取得した場合、［論物関連］タブは利用できません。dm1 ファイル全体を取得して作業されることをお勧めします。
アクティブ ファイル ディレクトリは、ローカル マシン上の場所でなければなりません。他のユーザーと共有しているネットワーク上の場所は指定しないでください。Repository を使用して作業する際には、いつもと同じように［ファイル｜上書き保存］を選択して、ローカルのアクティブ ファイル ディレクトリの dm1 ファイルに変更を保存することができます。オフラインでも作業できるため、生産性が最大限に向上します。作業環境をオフラインにする前に、作業対象をすべてチェックアウトしておけば、変更点をローカル ファイルに保存しておき、後でまとめて Repository にチェックインすることができます。詳細は、この後の「オブジェクトのチェックイン/チェックアウト」を参照してください。
ヒント： 効率を上げるために、アクティブ ファイル ディレクトリからモデルを直接開くこともできます。ファイルを保存して閉じた時点でのオブジェクトのチェックアウト状態が保持されているため、直ちに作業を開始できます。
複数の Repository を使用している場合は、同じ名前の dm1 ファイル間でファイル名や共有の違反が起こらないように、Repository ごとに別のアクティブ ファイル ディレクトリを使用してください。メインのアクティブ ディレクトリを 1 つ作成し、そのサブディレクトリとして各 Repository 用のアクティブ ファイル ディレクトリを区別しやすい名前で作成することをお勧めします。
メモ： 通常、2 つ目の Repository は、ER/Studio をアップグレードする際のテスト環境として使用します。単にモデルを別々に保存するために複数の Repository を作成することはお勧めしません。
オブジェクトのチェックイン/チェックアウト
Repository からダイアグラムを取得したら、ダイアグラム全体またはその一部をチェックアウトすることができます。推奨されるチェック アウトのレベルは、どのような変更を加えるかによって変わります。［ダイアグラムのチェックアウト］操作が推奨されるのは、dm1 ファイル全体に変更を加える場合です。たとえば、モデルのマージ、サブモデルの作成/編集、論理/物理モデルのいずれかでの作業などです。［ダイアグラムのチェックイン］操作は、多数の変更点を Repository にチェックインするために最適化されており、通常は、オブジェクト レベルでチェックイン/チェックアウトするよりも高速です。モデルで通常の作業を行う場合、ダイアグラム レベルでチェックイン/チェックアウトすることをお勧めします。特定のオブジェクトに追加の変更を 1 つだけ行うような場合には、個々のオブジェクトをチェックイン/チェックアウトします。
チェックアウト操作には、次の 2 種類があります。
- 排他的なチェックアウト： 排他的なチェックアウトを実行すると、チェックアウトしたオブジェクトがロックされます。そのオブジェクトに対して作業できるのはチェックアウトしたユーザーのみです。あるオブジェクトを排他的にチェックアウトすると、その上位および下位の依存オブジェクトも排他的にチェックアウトされます。オブジェクトが既にチェックアウトされていることを知らないまま、排他的にチェックアウトして、他のユーザーからそのオブジェクトをロックしてしまうこともあり得ます。
- 非排他的なチェックアウト（デフォルト）： 非排他的なチェックアウトの場合は、他のユーザーも同時に同じダイアグラムで作業することができます。矛盾はチェックイン時に解決します。他のユーザーが確実にモデルにアクセスしていない状態が必要な場合を除き、通常は、デフォルトの非排他的なチェックアウトをお勧めします。そうすれば、他のユーザーが必要としているオブジェクトを意図せずロックすることがありません。
オブジェクトを Repository にチェックインする際の［Repository チェックイン］ダイアログ ボックスには、オブジェクトをチェックアウトした状態のままで残すオプションがあります。モデルの作業は続ける必要があるけれども、一部の変更を Repository に反映して他のユーザーが見たり使用できるようにしたい場合には、この［チェックアウト状態を保持］オプションをオンにしてください。ファイルが既にチェックアウト済みなので、次回にローカル ファイルを開いてすぐに作業を再開できるという利点もあります。
モデルに加えた変更点を他のユーザーが確認できるように、少なくとも 1 日に 1 回はチェックインすることをお勧めします。ただし、チェックイン操作は、他の Repository 操作（ダイアグラムの取得、最新バージョンの取得、ログインなど）と一緒に FIFO（先入れ先出し）法で順番にキューに入るため、他のユーザーと競合しないタイミングで Repository 操作を実行するのが良いでしょう。
Repository のマージ操作/変更の確認
モデルの一部または全体を Repository にチェックインすると、アクティブ ファイル ディレクトリにあるローカルの dm1 ファイルと Repository の dm1 ファイルとの間でマージ操作が実行されます。Repository のマージでは、ローカル ファイルの変更点と Repository のモデルを比較します。
変更点を確認するには、［Repository チェックイン］ダイアログ ボックスで［チェックインの前に変更箇所を確認］オプションをオンにします。すると、［変更の確認および矛盾の解決］ダイアログ ボックスが開き、矛盾が分類されて表示されます。
- チェックイン操作が完了するのは、［変更の確認および矛盾の解決］ダイアログ ボックスを閉じ、ER/Studio Data Architect によって dm1 ファイルが更新された後です。［変更の確認および矛盾の解決］ダイアログ ボックスを開いたままで、同僚に変更点を確認したり自身が席を外すと、他のユーザーの操作が保留されることがあります。変更点を詳しく確認する必要があるなら、レポートを生成して変更を分析するようにしてください。
まとめ
- アクティブ ファイル ディレクトリ内のローカル ファイルにアクセスすると、すばやく作業を開始できます。
- 項目はチェックアウト状態にしておきます。
- 項目は 1 日に 1 回チェックインします。
- Repository ファイルとローカル ファイルを比較して変更点を確認します。ただし、［変更の確認および矛盾の解決］ダイアログ ボックスを長い間開いたままにしないでください。
- ダイアグラム レベルでチェックイン/チェックアウトすると、Repository への接続を最小限に抑えつつ、dm1 ファイル全体の作業効率を最大限に高めることができます。
- 特定のオブジェクトに簡単な変更を加える場合のみ、より詳細なレベルでチェックイン/チェックアウトを行います。