Repository への変更済み項目の保存(チェックイン)

提供: ER/Studio Data Architect
移動先: 案内検索

Repository 内のオブジェクトの操作 への移動

チェックイン処理を行うと、ローカルのチェックアウト項目に加えた変更点が Repository の項目に反映され、両者がシンクロします。

作業の完了後に、エンティティなどのオブジェクトやダイアグラム全体をチェックインできます。すべての変更箇所は Repository にマージされます。マージ処理中に矛盾点が検出された場合は、矛盾を解決するよう求められます。すべての矛盾を解決してマージが完了すると、マージの結果が Repository およびローカルのダイアグラムに追加されます。マージの結果はローカルのダイアグラムにも追加されるため、Repository 内のダイアグラムとのシンクロ状態が保持されます。

オブジェクトのチェックイン

オブジェクトをチェックインすると、そのオブジェクトと構造上の依存関係があるオブジェクト、および参照整合性による依存関係があるオブジェクトもすべてチェックインされます。新規作成したオブジェクト(たとえば、チェックアウト中のダイアグラムに追加したエンティティなど)をチェックインしたり、複数のオブジェクトを選択して一度にチェックインすることもできます。

個々のオブジェクトを Repository にチェックインする際には、ダイアグラム全体の整合性を維持するため、いくつかのルールが適用されます。

  • あるオブジェクトと、依存関係がある 1 つ以上のオブジェクトを別々にチェックアウトした後に、メインのオブジェクトをチェックインすると、依存関係があるオブジェクトもすべてチェックインされます。
  • 任意のオブジェクトを削除した後に、変更済みのオブジェクトをチェックインすると、削除したすべてのオブジェクトも Repository にチェックインされます。削除したオブジェクトが変更済みオブジェクトに関連付けられているかどうかは関係ありません。
  • 属性にバインドされたデータ ディクショナリ オブジェクトをチェックインする際に、データ ディクショナリ オブジェクトの変更が属性に影響する場合は、その属性が遅延チェックアウト対象としてマークされます。

データ ディクショナリのチェックイン

データ ディクショナリをチェックインすると、データ ディクショナリ オブジェクトがバインドされていたオブジェクトは、Repository Server によって新しいバージョンが作成される場合があります。たとえば、あるユーザー定義データ型を削除してからデータ ディクショナリをチェックインしたとします。削除されたデータ型が属性にバインドされていた場合、バインド設定がない新しいバージョンの属性が作成されます。これは、データ ディクショナリ オブジェクトを削除すると、そのオブジェクトに関連したバインド設定がすべて除去されるためです。属性の[バージョン履歴]には新しいバージョンが表示され、自動生成されたコメントが付きます。この属性に対して[最新バージョンの取得]を実行すると、バインド設定のない新しいバージョンがダイアグラムのローカル コピーに配置されます。データ ディクショナリをチェックインする前に、この属性を変更または削除すると、ローカル バージョンの属性と Repository Server によって作成された属性との間で、マージの矛盾が発生します。変更を保持するには、ローカル バージョンの属性を選択してください。

このような動作は、チェックインするデータ ディクショナリに、変更済みのデータ ディクショナリ オブジェクトが含まれる場合に発生することもあります。たとえば、アタッチメントのデータ型を変更してから、そのアタッチメントが含まれるデータ ディクショナリをチェックインしたとします。そのアタッチメントにバインドされたオブジェクトに上書き値が設定されている場合、上書き値はアタッチメントの特定のデータ型に対してのみ有効なので、除去する必要があります。つまり、アタッチメントにバインドされた(データ ディクショナリまたはダイアグラム内の)オブジェクトは、上書き値が除去された新しいバージョンとして Repository 内に作成されます。

データ ディクショナリを変更した場合、ダイアグラムをチェックインする前に、データ ディクショナリをチェックインする必要があります。たとえば、データ ディクショナリにドメインを作成して、そのドメインをダイアグラムで使用した場合、ダイアグラムを先にチェックインするとエラーとなります。

  • 複数のユーザーが同じダイアグラムに変更を加えたことで、変更点の競合が検出された場合、[変更の確認および矛盾の解決]ダイアログ ボックスが開きます。作業を続行する前に、ローカルとリモートのダイアグラム間の矛盾点を解決する必要があります。

Repository へのチェックイン

オブジェクトを Repository にチェックインする基本的な手順は、すべてのオブジェクト タイプで同じです。

  1. [ファイル|上書き保存]をクリックして、ダイアグラムに加えた変更を保存します。
  2. チェックインするオブジェクトをクリックするか、または Ctrl キーを押しながら、チェックインする複数のオブジェクトをクリックします。
  3. 選択したオブジェクトを右クリックし、[チェックイン]をクリックします。
    ショートカット メニューのチェックイン オプションは、選択したオブジェクトのタイプによって変わります。[ダイアグラムのチェックイン]、[モデルのチェックイン]、[サブモデルのチェックイン]、[オブジェクトのチェックイン]、[データ ディクショナリのチェックイン]、[データ ディクショナリ オブジェクトのチェックイン]、[ソース/ターゲットのチェックイン]、または[データ フローのチェックイン]のいずれかになります。
    メモ: データ ディクショナリをチェックインすると、[データ リネージ]タブで定義されたすべてのデータ移動ルールもチェックインされます。
  4. [Repository チェックイン]ダイアログ ボックスで必要なオプションを指定したら、[OK]をクリックしてチェックイン処理を開始します。

[チェックインの前に変更箇所を確認]チェック ボックスをオンにするか、または矛盾点が検出された場合、ローカル バージョンと Repository バージョンの間の相違点を解決するよう求めるメッセージが表示されます。

変更と矛盾のカテゴリ

[変更の確認および矛盾の解決]ダイアログ ボックスで使用されるアイコンの情報を次に示します。これらのアイコンは、検出された相違点とデフォルトの解決方法を表すものです。

カテゴリ アイコン

説明

DB REPO Resolve RRvLVAC.gif

ローカル ダイアグラムの変更と、他のユーザーによる Repository 内のリモート ダイアグラムの変更が矛盾しています。この矛盾が発生するのは、ローカル ダイアグラムで変更した項目が、他のユーザーによって変更されており、既に Repository にチェックイン済みである場合です。矛盾点についての詳細は、「チェックインおよびマージの矛盾点の解決」を参照。

DB REPO Resolve RRvLVA.gif

ローカル ダイアグラムの項目に追加した内容は、他のユーザーによって Repository バージョン内で変更されていません。これらの追加操作がローカル ダイアグラムに行われましたが、他のリモート ダイアグラムに行われた変更とは矛盾しません。

DB REPO Resolve RRvLVD.gif

ローカル ダイアグラムの項目で削除した内容は、他のユーザーによって Repository バージョン内で変更されていません。これらの削除操作がローカル ダイアグラムに行われましたが、他のリモート ダイアグラムに行われた変更とは矛盾しません。

DB REPO Resolve RRvLVU.gif

ローカル ダイアグラムの項目で更新した内容は、他のユーザーによって Repository バージョン内で変更されていません。これらの更新操作がローカル ダイアグラムに行われましたが、他のリモート ダイアグラムに行われた変更とは矛盾しません。

  • 通常、[変更の確認および矛盾の解決]ダイアログ ボックスで不明な変更点を最も効果的および安全に処理する方法は、それらの変更点の Repository へのチェックインを許可することです。いったん変更したものの、最終的に変更を取り消すことに決定した項目のみ、チェック ボックスをオフにします。

チェックインおよびマージの矛盾点の解決

矛盾点の検出と解決方法についてのロジックを次に説明します。

Repository バージョンとユーザーがチェックアウトしたローカル バージョンの間に相違点がある場合、矛盾が発生します。このような場合、ローカル バージョン、Repository バージョン、または両方を組み合わせて選択することで、データの矛盾点を解決できます。よくあるケースは、1 つのモデルに複数のユーザーが同時に変更を加えた場合です。Repository で発生する一般的な矛盾には、次の 3 つのタイプがあります。

  • 項目がローカル コピーで更新され、Repository バージョンで削除された場合
  • 項目がローカル コピーで削除され、Repository バージョンで更新された場合
  • 項目がローカル コピーで更新され、他のユーザーによって Repository バージョンでも更新された場合

タイプ 1 および 2 の矛盾: チェック ボックスをオンにすると、ローカル バージョンの内容が適用されます (ユーザーは項目を展開して、ローカル ダイアグラムで更新された項目またはテーブルのプロパティを確認できます。更新されたプロパティのみが表示されます)。

タイプ 1 の場合、矛盾が発生した項目のチェック ボックスをオンにすると、テーブルに加えた変更がローカル バージョンと Repository バージョンのダイアグラムに適用され、テーブルは削除されません。ただし、チェック ボックスをオフにすると、リモート バージョンのダイアグラムがローカル バージョンに適用されるため、テーブルはローカル バージョンのダイアグラムから削除されます。

逆にローカルで項目が削除され、Repository では更新されたとします。つまりタイプ 2 の状態です。項目を展開すると、プロパティと新しいテーブル値を表示できます(つまり、他のユーザーがテーブルをどのように更新したかを確認できます)。値が変更されたプロパティのみが表示されます。矛盾が発生した項目のチェック ボックスをオンにすると、ローカル バージョンの内容が適用され、テーブルはローカル バージョンと Repository バージョンのダイアグラムから削除されます。チェック ボックスをオフにすると、ローカル バージョンのダイアグラムでテーブルが更新されます。

タイプ 3 の矛盾: [変更の確認および矛盾の解決]ダイアログ ボックスには、矛盾が発生したテーブル項目の下にそれぞれの内容が表示されます。たとえば、ローカル バージョンと Repository バージョンでテーブル名に関して矛盾が発生している場合、それぞれの名前が表示されます。1 つ目の名前のプロパティ項目(新しい名前項目)には、ローカル ユーザーが決定したテーブル名が表示されます。2 つ目の項目には、Repository バージョンのダイアグラムに含まれる新しいテーブル名が表示されます。それぞれの項目にはオプション ボタンがあります。ローカル バージョンのテーブル名に対応するオプション ボタンをオンにすると、ローカル バージョンの名前が Repository バージョンとローカル バージョンに適用されます。Repository バージョンを選択すると、その名前がローカル バージョンのダイアグラムに適用されます(Repository バージョンでも有効なままです)。

一般的なチェックイン時の矛盾とその解決方法を次の表に示します。

矛盾

解決方法

ER/Studio Data Architect

Repository

変更なし

変更あり

(重大度: 低)ダイアログ ボックスには表示されません。Repository バージョンが選択されます。

変更なし

削除済み

(重大度: 低)ダイアログ ボックスには表示されません。Repository バージョンが選択されます。

変更なし

変更なし

(重大度: 矛盾なし)ダイアログ ボックスには表示されません。

変更あり

変更なし

(重大度: 低)[チェックインの前に変更箇所を確認]オプションが有効であれば、ダイアログ ボックスに表示されます。デフォルトでは ER/Studio Data Architect バージョンが選択されます。

削除済み

変更なし

(重大度: 低)[チェックインの前に変更箇所を確認]オプションが有効であれば、ダイアログ ボックスに表示されます。デフォルトでは ER/Studio Data Architect バージョンが選択されます。

変更あり

変更あり

(重大度: 高)ダイアログ ボックスに表示されます。デフォルトでは Repository バージョンが選択されます。

変更あり

削除済み

(重大度: 高)ダイアログ ボックスに表示されます。デフォルトでは Repository バージョンが選択されます。

削除済み

変更あり

(重大度: 矛盾なし)[チェックインの前に変更箇所を確認]オプションが有効であれば、ダイアログ ボックスに表示されます。デフォルトでは ER/Studio Data Architect バージョンが選択されます。

存在しない

新規

(重大度: 矛盾なし)ダイアログ ボックスには表示されません。デフォルトでは Repository バージョンが選択されます。

新規

新規

(重大度: 矛盾なし)ダイアログでは矛盾として検出されません。オブジェクトの名前が重複している場合、ER/Studio Data Architect バージョンで一方の名前を変更するか、一方のオブジェクト/プロパティを削除することで解決されます。

メモ

  • 重大度が「低」の矛盾は、[チェックインの前に変更箇所を確認]オプションが有効になっていると、[変更の確認および矛盾の解決]ダイアログ ボックスに表示されます。
  • 重大度が「高」の矛盾は、[チェックインの前に変更箇所を確認]オプションの設定に関係なく表示されます。

シーケンス番号の変更とその他の自動解決される相違点

大規模で複雑なモデルの場合、データの表示に関するわずかな不整合が存在する場合があります。このような整合性は、モデル内のデータに大きな影響を与えることはありませんが、[変更の確認および矛盾の解決]ダイアログ ボックスに変更点として表示されることがあります。たとえば、あるテーブルに 2 つの外部キー カラムが存在しており、それらが同じ名前であるのにロール名が付いてないと、ER/Studio Data Architect によって一意化されます。

そのテーブルに伝播される各リレーションシップの内部データには、それぞれ 1 つのカラムが存在しますが、その特定の名前が付いたカラムは 1 つしか表示されません。どちらが表示されるかは問題ではありません。これらはデータベース内の同じカラムを参照すると想定されます。ER/Studio Data Architect では、より下位の内部 ID を持つカラムに基づいて、表示されるカラムが変更される場合があります。2 つのカラムが異なる時間に追加され、しかもテーブル内で異なるシーケンス番号を付けられた場合、ER/Studio Data Architect が表示するカラムを切り替えた時点で、テーブル内でのカラムの順序が変更される可能性があります。これが原因で、他のカラムのシーケンス番号も変更されることがあります。このようなシーケンス番号の変更は、[変更の確認および矛盾の解決]ダイアログ ボックスに表示されることがあります。

ER/Studio Data Architect は、こうした余分な変更を選択解除できるように設計されていますが、通常は、自動で更新されるままにしておくことをお勧めします。そうすることで、整合性を保つようにデータが更新されます。ダイアログ ボックスで変更を選択解除すると、ER/Studio Data Architect による変更の一部が元に戻る可能性があります。さらに、一部の不整合は、ER/Studio Data Architect や Repository のマージ機能で処理できないデータ破損を引き起こす可能性があります。

ほとんどの場合、重大なデータ破損が発生する前に、ER/Studio Data Architect はこれらの不整合を特定および修正できます。ただし、変更を選択解除した場合、それらはチェックインされないため、不整合が修正されないまま Repository に保存されます。

関連項目