Oracle Designer for Windows移行に関するガイര줰 …otndnld.oracle.co.jp/document/products/itools/designer/6...Oracle Designer 2.1.2 および6.0 からの移行 Oracle Designer

1

Oracle Designer for Windows

移行に関するガイドライン

リリース 6i

2000年 11月

部品番号部品番号部品番号部品番号: J02574-01

2 Oracle Designer for Windows移行に関するガイドライン

Oracle Designer for Windows移行に関するガイドライン, リリース 6i

2000年 11月

著者: Frank Brink, Lucas Jellema

協力: Martin Wykes

Copyright © 2000 Oracle Corporation. All rights reserved.

制限付権利の説明

プログラムの使用、複製、または開示は、オラクル社との契約に記された制約条件に従うものとします。著作権、特許権およびその他の知的財産権に関する法律により保護されています。

当ソフトウェア（プログラム）のリバース・エンジニアリングは禁止されております。

このドキュメントの情報は、予告なしに変更されることがあります。オラクル社は、本ドキュメントの無謬性を保証しません。

* オラクル社とは、Oracle Corporation（米国オラクル）または日本オラクル株式会社（日本オラクル）を指します。

危険な用途への使用について

オラクル社製品は、原子力、航空産業、大量輸送、医療あるいはその他の危険が伴うアプリケーションを用途として開発されておりません。オラクル社製品を上述のようなアプリケーションに使用することについての安全確保は、顧客各位の責任と費用により行ってください。万一かかる用途での使用によりクレームや損害が発生いたしましても、日本オラクル株式会社と開発元である Oracle Corporation（米国オラクル）およびその関連会社は一切責任を負いかねます。当プログラムを米国国防総省の米国政府機関に提供する際には、『Restricted Rights』と共に提供してください。この場合次の Legendが適用されます。

Restricted Rights Legend

Programs delivered subject to the DOD FAR Supplement are "commercial computer software" and use, duplication and disclosure of the Programs shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement. Otherwise, Programs delivered subject to the Federal Acquisition Regulations are "restricted computer software" and use, duplication and disclosure of the Programs shall be subject to the restrictions in FAR 52.227-14, Rights in Data -- General, including Alternate III (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.

このドキュメントに記載されているその他の会社名および製品名は、あくまでその製品および会社を識別する目的にのみ使用されており、それぞれの所有者の商標または登録商標です。

3

目次目次目次目次

はじめに ................................................................................................................................ 7

このドキュメントの目的 ............................................................................................... 7

対象読者......................................................................................................................... 7

旧リリースからの移行に関して .................................................................................... 7

このドキュメントで使用されている規則 ...................................................................... 8

第１部概要、拡張、新機能.................................................................................................. 9

第 1章概要 ....................................................................................................................... 11

Oracle Deisgner 6i新機能の利点................................................................................. 11

移行と更新 ................................................................................................................... 12

試験的移行の検討について.......................................................................................... 12

第 2章 Oracle Designer 6iの新機能 ................................................................................. 13

構造化要素の格納 ........................................................................................................ 13

非構造化要素（ファイル）の格納............................................................................... 13

ワークエリア ............................................................................................................... 14

コンテナ....................................................................................................................... 15

バージョン管理............................................................................................................ 16

概要 16

バージョン履歴 .................................................................................................... 16

チェックインおよびチェックアウト ................................................................... 17

ブランチ............................................................................................................... 18

ロック、比較およびマージ.................................................................................. 18

バージョン管理ツール ......................................................................................... 19

コンフィグレーション ......................................................................................... 19


フォルダおよびファイルの同期化............................................................................... 21

システム権限 ............................................................................................................... 22

アクセス権 ................................................................................................................... 22

リポジトリ・ポリシー ................................................................................................. 23

バージョン制御に関するポリシー ....................................................................... 23

ファイル命名に関するポリシー .......................................................................... 24

依存性に関するポリシー ..................................................................................... 24

ショート・カットと共有 ............................................................................................. 25

第 3章リポジトリに対するバージョン管理機能の有効化............................................... 27

バージョン管理を利用せずに構造化要素だけを管理 .................................................. 27

バージョン管理を利用せずにすべてを管理 ................................................................ 28

バージョン管理を利用したフォルダ/ファイルの管理 ................................................. 29

第 2部リポジトリの移行 ................................................................................................... 31

第 1章概要 ....................................................................................................................... 33

第 2章移行作業前の準備 ................................................................................................. 35

サンプル・データについて.......................................................................................... 35

旧リポジトリ・データのクリーン・アップ ................................................................ 36

第 3章構造化要素の移行 ................................................................................................. 37

構造化要素の移行計画 ................................................................................................. 37

リポジトリ・データ全体の移行 .......................................................................... 38

アプリケーション・システムの部分的な移行..................................................... 38

Oracle Designer 1.3.2/1.4、2.1.1から 6.0への移行ステップ..................................... 39

旧リリースのリポジトリに対する移行作業 ........................................................ 41

Oracle Designer 6.0リポジトリの構築 ............................................................... 41

Oracle Designer 6.0リポジトリでの移行作業 .................................................... 42

Oracle Designer 6iの移行準備 .................................................................................... 42

クライアント側およびサーバー側のインストールと検証................................... 42

5

バージョン管理機能の利用の選択 ....................................................................... 44

パブリック・シノニムまたはプライベート・シノニムの選択 ........................... 44

Oracle Designer 2.1.2/6.0から 6iへの移行ステップ .................................................. 45

旧リリースのリポジトリからユーザー拡張性のアンロード（オプション）...... 46

ユーザー拡張性を Oracle Designer 6iへロード（オプション） ......................... 46

移行ウィザードの開始 ......................................................................................... 46

構造化要素の移行後のステップ .................................................................................. 50

旧リリースにおけるアプリケーション・システムの親子関係について ............. 50

構造化要素のチェックイン.................................................................................. 51

構造化要素に対するバージョン・ツリーの構築 ................................................. 54

段階的移行アプローチにおける構造化要素に対する移行後のステップ ............. 56

移行された構造化要素の検証 .............................................................................. 58

統計の計算 ........................................................................................................... 59

第 4章ファイル・システムに格納されているファイルの移行............................................ 61

移行するファイルの集合の作成 .................................................................................. 61

ファイル・システムの再構築 .............................................................................. 61

Oracle Designer 6iリポジトリへの移入 ...................................................................... 62

（ルート）フォルダ・マッピングの適用 ............................................................ 63

ファイルのアップロード ..................................................................................... 65

ファイルのチェックイン ..................................................................................... 65

ソース/実行可能プログラムのアップロードとチェックインの検討 ................... 66

ファイル・システムに格納されたファイルに対する移行後のステップ ..................... 66

ファイルに対するバージョン・ツリーの構築..................................................... 66

移行されたファイルの検証.................................................................................. 70

統計の計算 ........................................................................................................... 71

第 5章移行後の Oracle Designer 6iリポジトリの再編成................................................. 73

ワークエリアおよびコンフィグレーションの定義 ..................................................... 73

開発ワークエリアに対する各開発者ごとの異なるフォルダのマッピング ................. 77


廃止されたコンテナおよびオブジェクトの削除 ......................................................... 77

統計の計算 ................................................................................................................... 78

第 6章ユーザーの移行およびアクセス権限の割当て ...................................................... 79

ユーザー・グループの分類.......................................................................................... 79

QA構成マネージャ［QACM］ ............................................................................ 79

リポジトリ・マネージャ［RM］......................................................................... 80

開発者［DVR］.................................................................................................... 80

プロジェクト構成マネージャ［PCM］ ............................................................... 80

サポート・オペレータ［SO］............................................................................. 80

データベース管理者［DBA］ .............................................................................. 81

システム・リポジトリ・アクセス権 ........................................................................... 81

一般的な要素に対するアクセス権............................................................................... 82

ユーザー・グループごとのアクセス権........................................................................ 83

第 7章リポジトリ APIスクリプトの移行........................................................................ 87

リポジトリ APIの概要................................................................................................. 87

リポジトリ・ビューの概要.................................................................................. 87

リポジトリ APIパッケージの概要....................................................................... 89

移行に伴うリポジトリ APIの変更点 ........................................................................... 90

Appendix A: リポジトリ APIパッケージ・スクリプトの基本パターン ............................. 95

Appendix B: リポジトリ APIスクリプトの移行例 ............................................................. 99

リポジトリ･ビューの検索スクリプトの場合 .............................................................. 99

例 1 ..................................................................................................................... 99

例 2 ................................................................................................................... 100

リポジトリ APIパッケージ･スクリプトの場合......................................................... 101

7

はじめにはじめにはじめにはじめに

このドキュメントの目的このドキュメントの目的このドキュメントの目的このドキュメントの目的

このドキュメントでは、これまでの Oracle Designerのリリース（リリース 1.3.2/1.4、2.xま

たは 6.0）から Oracle Designer 6iへ移行する際に必要となる情報を提供します。このドキュ

メントに掲載される情報は、次のとおりです。

Oracle Designer 6iの新機能

これまでのリリースの機能がどのように Oracle Designer 6iに組み込まれたのか

用語の変更

既存の Oracle Designerから Oracle Designer 6iへの移行を行うにあたって、知っておく

べき事柄

対象読者対象読者対象読者対象読者

Oracle Designer 6iへの移行を考慮している、Oracle Designer（リリース 1.3.2/1.4、2.xまたは

6.0）のユーザーが対象となります。

このドキュメントでは、Oracle Designer 6iの新機能および拡張のすべてを詳細に取り上げて

いるわけではありません。主な変更点や新機能に焦点を絞り、リリース間の移行をできる

限りスムーズに行う方法を説明しています。

旧リリースからの移行に関して旧リリースからの移行に関して旧リリースからの移行に関して旧リリースからの移行に関して

Oracle Designer 6iへの移行手順は、現行使用中のリリース・バージョンによって異なります。

このため、Oracle Designer 6iでは、移行に関する情報を提供する複数のドキュメントが提供

されています。

『Upgrade from Oracle Designer 1.3.2/1.4 to 6.0 インストレーション・ガイド』（HTML

版、印刷版で提供）

Oracle Designer 1.3.2/1.4/2.1.1のユーザーが 6.0へアップグレードするための情報および

手順が記載されています。


『Oracle Designer for Windows インストレーション・ガイド』（HTML版、印刷版で提

供）

Oracle Designer 2.1.2および 6.0のユーザーが 6iへアップグレードするための情報およ

び手順が記載されています。

『Oracle Designer for Windows 移行に関するガイドライン』（本書：印刷版のみで提供）

移行に関して考慮すべきことや注意点などの全般的なガイドラインが示してあります。

これらは以下のようにご利用ください。

Oracle Designerリリース 1.3.2/1.4/2.1.1からの移行

Oracle Designer 6iへの直接の移行はサポートされていません。この対象ユーザーは、

Oracle Designer 6iに移行する前に、1.3.2/1.4のデータを 6.0にアップグレードする必要

があります。Oracle Designer 6iで提供されている『Upgrade from Oracle Designer 1.3.2/1.4

to 6.0』CDを使用して、いったんリリース 6.0にアップグレードしてください。リリー

ス 6.0へのアップグレードに関しては、『Upgrade from Oracle Designer 1.3.2/1.4 to 6.0 イ

ンストレーション・ガイド』と『Oracle Designer for Windows 移行に関するガイドライ

ン』の両方を参照することをお勧めします。リリース 6.0へアップグレードした後は、

次のようにしてリリース 6iへ移行できます。

Oracle Designer 2.1.2および 6.0からの移行

Oracle Designer 6iがインストールされ、移行プロセスの実行が完了するまで、既存の

Oracle Designer（クライアントとリポジトリの両方）を保存しておく必要があります。

この移行プロセスでは、既存のリポジトリからオブジェクト情報が読み込まれ、新規

の Oracle Designer 6iリポジトリにオブジェクトが再作成されます。この移行手順に関

しては、『Oracle Designer for Windows インストレーション・ガイド』と『Oracle Designer

for Windows 移行に関するガイドライン』の両方を参照することをお勧めします。

このドキュメントで使用されている規則このドキュメントで使用されている規則このドキュメントで使用されている規則このドキュメントで使用されている規則

メニュー選択を表す場合、メニュー名とオプション名の間に矢印を使用します。たとえば、

「ファイル」メニューから「新規」オプションを選択することを表す場合、以下のように

記述されます。

「ファイル」→「新規」をクリック

入力する文字はモノタイプのフォントで表示します。以下に例を示します。

Order Requestと入力してください。

9

第１部第１部第１部第１部概要、拡張、新機能概要、拡張、新機能概要、拡張、新機能概要、拡張、新機能


11

第第第第 1章章章章概要概要概要概要

第 1部では、Oracle Designer 6iの概要や、リポジトリ・オブジェクトのバージョン管理、新

規の管理要素やグループ化要素（ワークエリア、コンフィグレーションおよびコンテナな

ど）といった新しい概念を説明します。また、ここではバージョン管理への対応の選択に

ついても紹介します。これによる Oracle Designer 6iの利用方法の違い、バージョン管理へ

の対応の選択によって行うべき移行手順の違いに関する概要などを説明します。

Oracle Deisgner 6i新機能の利点新機能の利点新機能の利点新機能の利点

Oracle Designer 6iの新機能は、次のとおりです。

リポジトリ・オブジェクトのバージョン管理

作業領域管理（ワークエリア）

テキスト・ファイルおよびバイナリ・ファイルの格納

リリース管理のサポート（コンフィグレーション）

影響分析ツール（Dependency Analyzer）

Oracle 8i、Oracle Developer 6i Formsおよび Reportsのサポート

リポジトリ管理操作に関する APIの拡張

コマンド・ライン・ツールによるリポジトリ管理のバッチ操作

特に、リポジトリ・オブジェクトのバージョン管理、および関連のある機能（ワークエリ

ア、コンフィグレーションおよびファイル・システムの格納など）を使用することによっ

て、次のような利点があります。

クライアント・ジェネレータおよびサーバー・ジェネレータの機能の向上

サード・パーティ製のソース制御ツールではなく、オラクル標準のツール・セットを

使って構成管理のすべての機能を実現可能

ライフ・サイクル全体で構造化要素およびファイルを一つのリポジトリに格納するこ

とが可能

単一のリポジトリで、モデルベース開発および配布のすべてがサポートされ、その結

果、開発プロセスおよび配布プロセスの質が向上します。


構造化要素（旧リリースの Oracle Designerのアプリケーション・システム内に格納されて

いたもの）またはファイル（サード・パーティ製のソース・ツールやファイル・システム

内に格納されていたもの）の両方が Oracle Designer 6iに移行されることにより、前述の新

機能による利点を得ることができます。

移行と更新移行と更新移行と更新移行と更新

このドキュメントでは、移行という用語は、クライアントにあるソフトウェアおよびサー

バー側にあるソフトウェアの更新を意味するだけでなく、リポジトリ・データの移行、フ

ァイルのリポジトリへの移入、および移行したデータの再構成も意味しています。

試験的移行の検討について試験的移行の検討について試験的移行の検討について試験的移行の検討について

Oracle Designer 6iのリポジトリを導入し使用すると、Oracle Designerリポジトリ・ユーザー

の作業方法および作成方法に大きな影響を与える可能性があります。これは構成管理の役

割が大幅に変更されたためです。したがって、次の点から Oracle Designer 6iの試験的移行

を検討する必要があります。

Oracle Designer 6iのリポジトリへの移行に関する移行計画の決定および検証

新しく導入された構成管理の概念の把握

構成管理標準およびガイドラインの作成

データベース要件の決定

13

第第第第 2章章章章 Oracle Designer 6iの新機能の新機能の新機能の新機能

この章では、Oracle Designer 6iの機能の変更点および新機能について取り上げます。

構造化要素の格納構造化要素の格納構造化要素の格納構造化要素の格納

構造化要素とは、そのデータの内部構造（その要素が持つプロパティ構造など）が完全に

把握されてリポジトリに格納される要素です。構造化要素タイプの代表的な例は、Oracle

Designer要素タイプ（エンティティ, 業務機能, 表定義など）です。さらに、Oracle Repository

では、フォルダやコンフィグレーションなど Oracle Repository独自の要素タイプが用意され

ています。

各要素にはプロパティが備わっています。プロパティには、必須入力のもの、または任意

のもの、自動的に導出されるもの、または更新可能なもの、フリーテキストで指定するも

の、またはリスト等から値を選択するものなどがあります。プロパティは、次の 3種類に

分類できます。

最大長が決められている NUMBER、DATEまたは VARCHAR2のデータ型による値

固定長が設定されていない複数行のテキスト・フィールド

他のオブジェクトへの参照

ほとんどのプロパティは要素タイプに特有のものですが、名前、タイプ、バージョン・ラ

ベル、監査データ（作成日、作成者、更新日、更新者）および IRIDなどはすべての要素に

共通して存在する一般的なプロパティです。IRIDは、これまでのリリースでは IDと呼ばれ

ていました。IRIDにより、グローバルにオブジェクトが識別されます。IRIDを導出するア

ルゴリズム（Oracle 8より提供されている SYS_GUID関数）によって、任意のリポジトリで

再度生成されないような一意の値が戻されます。リポジトリ間でデータを移行する上で、

これは大きな利点です。

非構造化要素（ファイル）の格納非構造化要素（ファイル）の格納非構造化要素（ファイル）の格納非構造化要素（ファイル）の格納

リポジトリで構造を把握することが難しい要素は、非構造化要素と呼ばれます。この「非

構造化要素」は、この要素に内部構造がないというわけではなく、リポジトリが構造を認

識することが難しいために要素がまとめて一つの塊として扱われることを表しています。

Oracle Designerが FMB、RDF、OLB、PL/SQLまたは Javaなどのファイル構造を十分に熟知


し依存性の詳細を抽出したとしても、リポジトリ内部ではこれらのファイルは非構造化要

素として管理されます。

非構造化要素としてファイルがリポジトリ内に格納できるようになったことは、リポジト

リ・アーキテクチャの主な変更点の 1つです。ランタイム・オブジェクト（実行可能ファ

イル）、ソースファイル、メタ・ソース（テンプレート、設計、モデル、ワークショップ・

ノート、ユーザー・インタビュー）、サポート・オブジェクト（テスト・プラン、プロジ

ェクト・プラン、標準およびガイダンス）はすべて、構造化でも非構造化でも、リポジト

リ内に格納できます。これらすべてをリポジトリに格納し、管理することを強くお薦めし

ます。

ファイルは、LOB（Large Objects）として表 I$SDD_FILESに格納されています。ファイル

は任意のファイル・システムからのアップロードで作成および更新され、ダウンロードで

任意のファイル・システムに抽出できます。

ファイルは圧縮形式で格納できます。圧縮および解凍は自動的に、アップロードやダウン

ロード時にそれぞれリポジトリにより処理されます。圧縮アルゴリズムはかなり高速で、

またファイルに必要な記憶領域を 2～10%に削減します。リポジトリ・ファイル・レジスト

リでは、どのファイル・タイプ（拡張子）がテキスト、バイナリ形式または圧縮形式とし

て格納されるのかが記録されています。また、テキスト・ファイルと Oracle Developerによ

り作成された FMB形式のバイナリ・ファイルに対しては、2つのファイル内容の比較をす

ることが可能です。

アップロード/ダウンロードは、Repository Object Navigator（RON）またはコマンドライン・

ツールによって、ファイル単位で、複数のファイルを一括で、またはネストされたディレ

クトリ構造全体で実行できます。このツールはWindowsエクスプローラで定義されている

ファイルの関連付け（表示、オプション、登録されているファイル・タイプ）に基づいて

おり、このツールから直接ファイルをオープン（表示、編集または実行）することができ

ます。ユーザーは好みに合ったエディタを使用して、ファイルをリポジトリからオープン

できます。RONを使用してリポジトリ内のファイルをオープンするには、ファイルを選択

して右クリック・メニューから「開く」を選択します。

ワークエリアワークエリアワークエリアワークエリア

ワークエリアとは、ユーザーが作業中のリポジトリ・オブジェクトを表示しているビュー

です。ワークエリア内では、互いに関連性のあるリポジトリ・オブジェクトをアプリケー

ション・システムおよびフォルダへグループ分けできます。このアプリケーション・シス

テムやフォルダは、コンテナと呼ばれています。

15

これまでのリリースでは、システム・モデリング・ツールは、ひとつのアプリケーション・

システム内のリポジトリ・データだけを表示していましたが、Oracle Designer 6iでは、ワー

クエリア内のリポジトリ・データをすべて表示するようになったため、各ツールは、ワー

クエリアに属している複数のアプリケーション・システムおよびフォルダにアクセスする

ことができます。

ワークエリアを作成したユーザーはこのワークエリアの所有者となり、他のユーザーにア

クセス権を割り当てることができます。少なくとも 1つのワークエリアへのアクセス権を

得て初めて、リポジトリでの作業が可能となります。

開発者は個々にワークエリアを作成できます。これによって、異なる開発者が同じオブジ

ェクトをそれぞれのワークエリアから変更する可能性があります。Oracle Designer 6iでは、

他のユーザーが行った変更が自分のワークエリア内で影響を受けないように、他のユーザ

ーの変更をすぐには反映しないように設定されています。この変更をすぐにナビゲータ・

ウィンドウ上に反映したい場合には、ワークエリア・リフレッシュという機能を使用する

ことができます。特定のワークエリアをリフレッシュすることによってうける影響を、ナ

ビゲータ・ウィンドウに表示してプレビューすることができます。プレビュー時には、ワ

ークエリアに表示されているオブジェクトで、前回のリフレッシュ以降に作成、変更また

は削除されたオブジェクトのリストが表示されます。ワークエリアのリフレッシュは、右

クリック・メニューから実行できます。

ワークエリアのコンテンツは、最初、規則にしたがって自動的に定義されます。当然なが

ら、規則を手動で書き換えたり、ワークエリアの任意のリポジトリ・オブジェクトを明示

的に組み入れたり、すでに存在する任意のオブジェクトを除外したりすることができます。

コンテナコンテナコンテナコンテナ

旧リリースでのアプリケーション・システムの考え方がコンテナとして拡張されました。

コンテナは、ワークエリア内のリポジトリ・オブジェクトをいくつかのまとまりに編成す

るための論理的な区画です。このリリースでは 2種類のコンテナがサポートされています。

1つはアプリケーション・システム（旧リリースで使用できたものに類似）、もう 1つはフ

ォルダ（ディスクベースのファイル・システム内のディレクトリに類似）です。


バージョン管理バージョン管理バージョン管理バージョン管理

概要概要概要概要

これまでのリリースでは、アプリケーション・システム・レベルでバージョン管理を行っ

て来ましたが、Oracle Designer 6iでは個々のリポジトリ・オブジェクト単位でのバージョン

管理がサポートされ、変更制御、複数ユーザーによるアクセスの制御が向上しました。

リポジトリ・オブジェクトのバージョン管理にはチェックイン/チェックアウトという操作

を行います。オブジェクトはすべて、システムで生成されたバージョン・ナンバーにより

識別されます。重要なバージョンには開発のマイルストーンであることを示すために、手

動でラベルを割り当てることが可能です。各オブジェクトのバージョンの履歴、バージョ

ンの詳細、オブジェクトに対して発生する様々なバージョン制御イベントの詳細はグラフ

ィカル・ツールを使用して表示することができます。

また、ブランチの考え方が取り入れられています。このブランチによって、1つのオブジェ

クトに対し複数のバージョンを同時に開発することが可能になりました。ブランチには、

開発プロセスで容易にそのブランチの役割が識別できるようにラベルを付けることができ

ます。

構造化要素、非構造化要素両方とも共通のリポジトリでバージョン管理できます。リポジ

トリ・オブジェクトはもちろんファイル・システムおよびディレクトリもすべてリポジト

リで管理でき、個別ファイルの内容変更を追跡するだけではなく、ソース・ファイルの編

成変更も追跡できます。

バージョン履歴バージョン履歴バージョン履歴バージョン履歴

リポジトリの各オブジェクトは、それぞれが単に格納されるだけではなく、さまざまなタ

イミングにおけるオブジェクトの状態（つまり、過去のオブジェクト・バージョン）のセ

ットとして格納されます。各オブジェクト・バージョンが前のバージョンからどのように

生成されたかを記録したつながりによって、オブジェクト・バージョンは互いにリンクさ

れています（このつながりをバージョン・ツリーと呼びます）。バージョン・ツリーで表

現されているバージョン間の関連性はバージョン履歴と呼ばれ、それによってバージョン

の進行状況や分岐、マージを確認することができます。

バージョン履歴には、次のような多数のバージョン制御属性も備わっています。

バージョンを一意に表現する識別子

17

オブジェクトを作成したユーザーの識別子

オブジェクト作成日時

オブジェクトを変更したユーザーの識別子

オブジェクト変更日時

オブジェクトのステータス（チェックアウト済、チェックイン済など）

コメント（チェックインまたはチェックアウトにおける注記）

チェックインおよびチェックアウトチェックインおよびチェックアウトチェックインおよびチェックアウトチェックインおよびチェックアウト

バージョン管理は、オブジェクトをチェックインすることによって開始されます。チェッ

クインと同時に、オブジェクトのバージョンが確定し、チェックインされたオブジェクト

は書込み禁止となります。オブジェクトを修正するにはチェックアウトする必要がありま

す。チェックアウトし、変更を加えたオブジェクトを再びチェックインすると、オブジェ

クトのバージョン・ナンバーが上がります。

チェックイン/チェックアウトを繰り返すことによって、各オブジェクトは複数のバージョ

ンを持つ可能性があります。ワークエリアは、これらのうちの開発対象のバージョンだけ

を表示します。つまり、ワークエリアから参照可能なオブジェクトのバージョンは 1バー

ジョンのみとなります。しかし、オブジェクトの完全な履歴や、オブジェクトに発生した

イベントはすべてリポジトリで提供されているツールを介して参照することができます。

構造化要素だけではなく、ファイル・システム内のファイルまたはフォルダもすべて、バ

ージョン管理の対象となります。ファイル/フォルダをリポジトリにコピーしたり、またフ

ァイル・システムにこのファイル/フォルダをコピーすることができます。ファイル・シス

テムとリポジトリとの整合性を確保するため、両者の同期化を任意で行うことも可能です。

いったんオブジェクトがチェックアウトされると、そのコピーがユーザーのワークエリア

に表示されるようになります。つまり、新しくオブジェクトをチェックアウトすると、ワ

ークエリアがリフレッシュされて、新しいオブジェクト・バージョン（チェックアウトさ

れることによって作成されたコピー・バージョン）が表示され、編集できるようになりま

す。チェックアウトは取り消すことができ、その場合、チェックアウト後にオブジェクト

に加えた変更は失われます。

このチェックイン/チェックアウトの処理は Repository Object Navigator、Version History

Viewerユーティリティまたはコマンドライン・インタフェースから操作できます。この際

に、アクションの理由についての簡単な注記を追加できます。


ブランチブランチブランチブランチ

ブランチは分岐した開発ラインのことで、オブジェクトを開発のある段階から分岐させて

並行開発したい場合に利用します。たとえば、システム開発において、バグ修正、テスト

開発、別プラットフォーム用開発といったように、同じソース・ファイルに対して複数の

バージョンで開発を行う場合に、それぞれの目的ごとにブランチを作成することができま

す。オブジェクトに変更を加えてチェックインする際、それをチェックアウトされたとき

と同じブランチ上に行うのか、それとも新規のブランチ上に行うかを選択でき、新規ブラ

ンチを選択した場合、そこから並行開発が可能になります。このブランチには、例えば‘バ

グ修正に関係する一連の変更’などといったラベルをつけることができます。

ワークエリアに対して、デフォルトのブランチを指定することができます。これによって、

（ユーザーが特に変更しない限り）指定されたブランチ上へチェックインされるようにな

ります。

ロック、比較およびマージロック、比較およびマージロック、比較およびマージロック、比較およびマージ

チェックアウト操作時に、他のユーザーが同じオブジェクトをチェックアウトして編集し

ないようにロックすることができます。これによって、特定のブランチ上への次のチェッ

クインを予約できます。この場合でも、他のユーザーが同じバージョンのコピーを（ロッ

クせずに）チェックアウトすることは可能ですが、ロックしたバージョンがチェックイン

される（ロックが解除される）までは、他のユーザーは同じブランチへのチェックインは

できません。

ロックをかけずにオブジェクトをチェックアウトすることもできます。この場合、他のユ

ーザーはこのオブジェクトの任意のバージョンをチェックアウト/チェックインできます。

このような状況では最初にオブジェクトをチェックインしようとユーザーは実行できます

が、このオブジェクトに続いて行われるチェックインでは、このブランチ上での最新のバ

ージョンとマージさせる必要があります。このような状況を解決するために、比較および

マージ・ツールを使用することができます。

リポジトリでは、現在次の 3種類のオブジェクト・タイプの比較およびマージをサポート

しています。

構造化要素（標準リポジトリ・オブジェクト）

Oracle Developer Forms FMBファイル

テキスト・ファイル

19

バージョン管理ツールバージョン管理ツールバージョン管理ツールバージョン管理ツール

Oracle Designer 6iでは、次のようなバージョン管理ツールが提供されています。

ツールツールツールツール説明説明説明説明

Version History Viewer 選択したリポジトリ・オブジェクトのバージョン履歴をグラフィカ

ルに表示し、比較やマージなどのバージョン操作を実行できます。

Version Event Viewer 選択したリポジトリ・オブジェクトに実行されたチェックインおよ

びチェックアウトといったバージョン操作の詳細な情報を提供し

ます。この情報はダイアログ・ボックス形式で表示されます。

バージョン管理ツールによって、数多くのタスクを構造化要素およびファイル・オブジェ

クトの両方に対して実行できます。実行可能なタスクを以下に示します。

オブジェクト・バージョンを新しく作成するための、オブジェクトのチェックインお

よびチェックアウト

オブジェクトのバージョン履歴の表示

オブジェクトに発生したバージョン・イベントの表示

新規バージョン・ブランチの作成

オブジェクト・バージョンの比較

オブジェクト・バージョンのマージ

オブジェクト・バージョンの詳細情報の表示

Version History Viewerおよび Version Event Viewerは Repository Object Navigatorから使用可

能ですが、スタンドアロン・ツールとしても使用可能です。

コンフィグレーションコンフィグレーションコンフィグレーションコンフィグレーション

個々のオブジェクトの開発が、特定のアプリケーションをビルドできる段階に達したら、

各オブジェクトの、どのバージョンをビルドに使用するかを正確に指定する必要がありま

す。同じように、テストに使用するオブジェクトの組み合わせや、パッチ・リリースに含

めるオブジェクトの組み合わせを作成する場合も、正確に指定することが必要になります。

このような場合に、コンフィグレーションを作成します。コンフィグレーションとは、グ


ループ化されたリポジトリ・オブジェクト・バージョンのセットです。コンフィグレーシ

ョンでは、どのオブジェクトのどのバージョンが使用されるのかを定義します。

コンフィグレーションに含まれるオブジェクト・バージョンは、このコンフィグレーショ

ンの構成要素とも呼ばれます。構成要素を必要に応じて追加または削除することができま

すが、コンフィグレーションに含めることのできるオブジェクトはチェックイン済のバー

ジョンのみです。またコンフィグレーションはリポジトリ・オブジェクトですので、それ

自身もバージョン管理もできます。

Oracle Designer 6iでは、コンフィグレーション・ウィザードを提供していますので、ウィザ

ードに従って簡単にコンフィグレーションを作成することができます。コンフィグレーシ

ョン・ウィザードでは、コンフィグレーションの新規作成や既存コンフィグレーションの

新規バージョンの作成が可能で、この際に、たとえば、そのコンフィグレーションの構成

要素をすべてのオブジェクトの最新バージョンにするように指定することができます。

以下に示す条件をベースとして、コンフィグレーションを作成することができます。

既存のコンフィグレーションやオブジェクトの選択規則を組み合わせることによって

識別されるオブジェクト・バージョン

現行のワークエリアに表示されているオブジェクト・バージョン

特定のブランチ上にあるオブジェクトの最新バージョン

さらに、カスタム・コンフィグレーションを作成することもできます。つまり、必要な構

成要素のバージョンを特定して、追加、削除または変更することができます。

前述した 3つの条件のいずれかをベースとしてコンフィグレーションを新規作成した場合、

これに構成要素の追加や変更を行ったり、構成要素のバージョンの変更を行うことで、構

成要素のカスタマイズをすることができます。もちろん、条件として選択した規則および

コンフィグレーションをあとから追加または削除することもできます。

既存のコンフィグレーションの新規バージョンを作成する場合も同様です。これに加えて、

最新バージョンで既存の構成要素をすべてリフレッシュしたり、必要に応じて既存のコン

フィグレーションにさらに手を加えることが簡単にできます。

コンフィグレーションの構成要素として選択されたオブジェクトが、構成要素として選択

されていない他のオブジェクトを参照している場合（たとえば、モジュールだけが選択さ

れていて、それがアクセスする表が選択されていない場合）、外部参照ユーティリティを

使用して、対象となるオブジェクト・バージョンを表示できます。その後、それらをコン

フィグレーションに含めることができます。

21

新規コンフィグレーションまたは新規バージョンのコンフィグレーションの作成が完了す

ると、コンフィグレーションの保存だけを行うか、それともチェックインまでを行うか、

いずれかを選択して実行できます。保存してチェックインする場合は、チェックイン・ノ

ートの追記およびチェックイン・ブランチの指定ができます。コンフィグレーションの保

存のみを選択した場合は、バージョンの確定が行われずに、引き続き編集を行うことがで

きます。

フォルダおよびファイルの同期化フォルダおよびファイルの同期化フォルダおよびファイルの同期化フォルダおよびファイルの同期化

ファイルをアップロードすると、ファイルがファイル・システムからリポジトリにコピー

されます。両方のコピーともそれぞれ別にオープンし編集できるため、同一ファイルの 2

つのコピーが同一ではなくなる可能性があります。

この 2つのコピーが互いに更新されるように同期化する機能が提供されています。同期化

は、リポジトリ・コピーをファイル・システム・コピーに対して、またはその逆にファイ

ル・システム・コピーをリポジトリ・コピーに対して上書きするメカニズムです。

同期化を実行すると、リポジトリ・コピー、ファイル・システム・コピーまたは両者に変

更が行われているかどうかがチェックされます。

結果アクションは次のとおりです。

リポジトリ・コピーリポジトリ・コピーリポジトリ・コピーリポジトリ・コピーファイル・ファイル・ファイル・ファイル・

システム・コピーシステム・コピーシステム・コピーシステム・コピーシステム・アクションシステム・アクションシステム・アクションシステム・アクション

変更なし変更なしアクションなし

変更なしチェックイン済変更ありユーザー操作用のダイアログを表示

変更なしチェックアウト済変更ありファイル・システムからファイルをア

ップロード

変更あり変更なしファイル・システムにファイルをダウ

ンロード

変更ありチェックイン済変更ありユーザー操作用のダイアログを表示

変更ありチェックアウト済変更ありユーザー操作用のダイアログを表示

リポジトリ・コピーがチェックインされた状態でファイル・システム・コピーが変更され

たファイルはハイジャックされたファイルと呼ばれます。このような場合に、ユーザー操


作用のダイアログが表示され、ファイル・システム・コピーのアップロード、リポジトリ・

コピーのダウンロード、リポジトリ・コピーのチェックインもしくはチェックアウトおよ

び再同期化、あるいは 2つのコピーのマージを選択することによって差異を 1つずつ解決

していきます。

特別なケースを次に挙げておきます。

リポジトリ・コピーとファイル・システム・コピーの両方が異なる形で変更され、そ

れを解決する前にファイル・システム・コピーを削除した場合、ファイル・システム・

コピーに対して行われた変更はすべて失われます。

同期化を行う前にリポジトリ・コピーを削除してしまっても、ファイル・システム・

コピーを削除していなければ、リポジトリ・コピーは同期化によって復元されます。

この場合、リポジトリ・コピーが新規ファイルとして扱われてアップロードされるか

らです。ワークエリアの表示規則を変更してリポジトリ・コピーをワークエリアから

取り除いた場合にも同じことが発生します。

同期化を行った後にリポジトリ・コピーを削除して、ファイル・システム・コピーを

削除していない場合、次回の同期化操作ではファイル・システム・コピーを削除する

か保持するかを選択できます。ワークエリアの表示規則を変更してリポジトリ・コピ

ーをワークエリアから取り除いた場合にも同じことが発生します。

システム権限システム権限システム権限システム権限

リポジトリ所有者および従属ユーザーは、リポジトリを使用するシステム権限が必要とな

ります。たとえば、次のような権限が必要です。

リポジトリ所有者は、新しくリポジトリをインストールするシステム権限

従属ユーザーは、データベース・オブジェクトを作成するシステム権限

システム権限の割り当てをチェックするには、Repository Administration Utility上のチェック

要件ツールを使用します。

注意: Oracleデータベース管理者（DBA）のみがシステム権限を付与できます。

アクセス権アクセス権アクセス権アクセス権

リポジトリ・ユーザー・メンテナンスの機能はかなり拡張されました。リポジトリ所有者

は、特定の従属ユーザーがワークエリアの作成や削除、またはリポジトリ・オブジェクト

上での強制削除やバージョンの除去操作などの特定のリポジトリ管理操作を実行できるか

23

どうかを指定できるようになりました。さらに、リポジトリ所有者は、Repository Object

Navigatorまたはコマンドライン・インタフェースなどの個別リポジトリ・ツールへの従属

ユーザーのアクセスを制御できます。

リポジトリ・ポリシーリポジトリ・ポリシーリポジトリ・ポリシーリポジトリ・ポリシー

以下を制御するような、リポジトリ全体に関係するオプションを設定できます。

バージョン制御

ファイル命名（大文字/小文字の区別）

依存性

バージョン制御に関するポリシーバージョン制御に関するポリシーバージョン制御に関するポリシーバージョン制御に関するポリシー

「ポリシーの設定」システム権限によって以下の 3つのバージョン機能の使用をユーザー

に制限することができます。

ブランチ方法

バージョンのラベル付け

ロック方法

以下、それぞれ詳細を説明します。

自動ブランチ化自動ブランチ化自動ブランチ化自動ブランチ化

自動ブランチ化・ポリシーが設定されると、オブジェクトのチェックイン時に、各ワーク

エリアに設定されたデフォルトのチェックイン・ブランチがターゲット・ブランチとして

自動的に選択されます。デフォルトのチェックイン・ブランチがワークエリアに設定され

ていない場合は、オブジェクトがチェックアウトされたブランチがチェックイン・ブラン

チとして選択されます。

ただし、このポリシーで指定された設定はデフォルト値にすぎず、実際のチェックイン操

作時に選択することは可能です。


自動バージョン・ラベル付け自動バージョン・ラベル付け自動バージョン・ラベル付け自動バージョン・ラベル付け

自動バージョン・ラベル付けが設定されると、チェックイン時にオブジェクトのラベルを

指定することを許可しません。リポジトリにより、自動的にラベルが割り当てられます。

厳密なロック制御厳密なロック制御厳密なロック制御厳密なロック制御

厳密なロック制御ポリシーが設定されると、ユーザーがチェックアウトした時にオブジェ

クトが必ずロックされます。複数のユーザーが同一ブランチ上でオブジェクト・バージョ

ンをロックできないため、厳密なロック制御ポリシーにより同一ブランチ上でオブジェク

ト・バージョンの同時開発を避けることができます。

厳密なロック制御ポリシーが設定されない場合、チェックアウト時にオブジェクトをロッ

クする、またはロックしないかを選択できます。ただし、この場合は、ロックしても他の

ユーザーが同じバージョンのコピーをロックせずにチェックアウトすることは可能です。

ただ、ロックされたバージョンがチェックインするまで、同一ブランチにチェックインす

ることはできなくなります。

ファイル命名に関するポリシーファイル命名に関するポリシーファイル命名に関するポリシーファイル命名に関するポリシー

ファイル・システム・ファイルおよびそのコンテナの作成時に大文字/小文字の区別を行う

かどうかを制御します。このポリシーが設定されると、たとえば、"MyFile"という名前のフ

ァイルと"myfile"という名前の異なるファイルを作成できます。このポリシーが無効の場合、

前述した 2つのファイルは同一ファイルとして扱われ、2番目のファイルを作成することは

できません。

このポリシーは特に、大文字/小文字の区別がファイル名およびディレクトリ名の特徴であ

る UNIXサーバーからアップロードされたファイル用に使用されます。

依存性に関するポリシー依存性に関するポリシー依存性に関するポリシー依存性に関するポリシー

オブジェクトのバージョンが更新されるか、またはオブジェクトのコピーが実行される時

に、そのオブジェクトの依存性データ（そのオブジェクトが依存する、または依存されて

いる他のオブジェクトのリスト）もコピーするかどうかを制御します。ただし、このポリ

シーで指定された設定はデフォルト値にすぎず、実際のチェックインやコピー操作時に選

択することは可能です。依存性データは、Dependency Managerツールで作成/参照されます。

25

ショート・カットと共有ショート・カットと共有ショート・カットと共有ショート・カットと共有

Oracle Designer 6.0まで存在していた共有はなくなりました。選択権限が付与されているフ

ォルダに格納されている要素であれば、リポジトリの任意の場所からその要素への参照を

作成できるようになったので、現行のフォルダに共有を作成する必要はありません。次の

図では、フォルダ HRM¥Designの表定義 EMPLOYEESの列 JOBに、フォルダ CORPORATE

に格納されているドメイン JOB_TITLESへの参照が指定されています。この参照は、

HRM¥Designフォルダのドメインを共有せずに作成されました。

Oracle Designer 6iでは、共有に類似した、ショート・カットと呼ばれる新しい機能が提供さ

れています。これはWindowsファイル・システムのショート・カットに似ています。

ショート・カットはフォルダと要素のリンクです。ショート・カットを作成するには、要

素をフォルダにドラッグ・アンド・ドロップ（または「編集」→「コピー」の後、「編集」

→「参照の張り付け」）します。要素を所有しているフォルダに対して選択権限が、ショ

ートカットのターゲットとなるフォルダに対して更新権限が、それぞれ必要となります。

ショート・カットはフォルダに対しては作成できず、個々の要素のみに作成されることに

注意してください。また、元となる要素のバージョンの更新とともに、そのショート・カ

ットも更新されます。例えばフォルダ HRM¥PUBLICから表定義 DEPARTMENTSにショー

ト・カットを作成すると、DEPARTMENTSのバージョンの更新にしたがって適切なバージ

ョンが HRM¥PUBLICにリンクされることになります。

これによって、現行のフォルダには、実際にフォルダに格納されている要素と、そこに作

成されたショート・カットが存在することになります。つまり、リポジトリ全体を検索お

よびナビゲートすることなく要素を表示し、参照できます。さらにアイコンをクリックす

るか、[F12]を押すことによって、ショート・カットのソースに直接ナビゲートできます。

この新しい機能は Oracle Designer 6.0の共有と比べた場合、ショート・カットはその場所で

編集を行えるようになっている点で優れています。要素が格納されているフォルダに対し

て更新権限が付与されている場合、そのフォルダにナビゲートすることなくショート・カ

ット要素を直接更新できます。


27

第第第第 3章章章章リポジトリに対するバージョン管理機能の有効化リポジトリに対するバージョン管理機能の有効化リポジトリに対するバージョン管理機能の有効化リポジトリに対するバージョン管理機能の有効化

Oracle Designer 6iの利用にあたって、これまでのリリースのようにバージョン管理を行わず

に構造化要素を管理するリポジトリとして使用することも可能ですし、バージョン管理に

対応したリポジトリとして使用することも可能です。この章では、Oracle Designer 6iの使用

方法を考察し、Oracle Designer 6iの各モード(バージョン管理対応/バージョン管理非対応)

の選択によるリポジトリ移行の概要を説明します。

バージョン管理を利用せずに構造化要素だけを管理バージョン管理を利用せずに構造化要素だけを管理バージョン管理を利用せずに構造化要素だけを管理バージョン管理を利用せずに構造化要素だけを管理

要素をバージョン管理しない場合（この決定の基となる理由は後で説明します）、Oracle

Designer 6iリポジトリのインストール後に Repository Administration Utilityのバージョン・サ

ポート・オプションを無効のままにします（インストール直後はデフォルトで無効です）。

バージョン・オプションが無効である限り、旧リリースの Oracle Designerと同じように、

各要素の一つのバージョンのみを格納します。実際には、オブジェクトをチェックインす

ることができないため、各要素のバージョン・プロパティは移入されません。各開発者は

共有ワークエリア GLOBAL_SHARED_WORKAREAを使用します。

通常、バージョン管理しないモードで Oracle Designer 6iを使用することが考えられるのは

次のようなケースです。

プロジェクトのサイズがきわめて小さい場合（参加者が数名程度の場合など）。

テスト・フェーズに達していない場合。計画、分析、設計または構築のフェーズにい

る場合。ある種の並行性が必要ない場合。

管理対象のファイル数が制限されている場合（30未満など）。

サード・パーティ製ソース・ツールでファイルを管理する場合。

この場合に、「第 2部リポジトリ移行」に記載されている章で関係のある個所は次のとお

りです。

「第 1章概要」

「第 2章移行作業前の準備」

「第 3章構造化要素の移行」

「第 6章ユーザーの移行およびアクセス権限の割当て」


「第 7章リポジトリ APIスクリプトの移行」

上述の章のうち、データのバージョン管理を取り扱う項は省いてかまいません。

バージョン管理を利用せずにすべてを管理バージョン管理を利用せずにすべてを管理バージョン管理を利用せずにすべてを管理バージョン管理を利用せずにすべてを管理

バージョン管理せずに、構造化要素の他にファイルもリポジトリに格納したい場合は、

Repository Administration Utilityのバージョン・サポート・オプションを無効のままにします。

これに加えて、ファイルおよびフォルダのリポジトリへの格納方法に関するガイドライン

を開発者に提供する必要があります。具体的には、適切なアクセス権のあるフォルダ階層

を設定する必要があります。第 2部の第 6章「第 6章ユーザーの移行およびアクセス権

限の割当て」も参照してください。

通常、このようなモードで Oracle Designer 6iを使用することが考えられるのは次のような

ケースです。

プロジェクトのサイズがきわめて小さい場合（参加者が数名程度の場合など）

テスト・フェーズに達していない場合。計画、分析、設計または構築のフェーズにい

る場合。ある種の並行性が必要ない場合

管理対象のファイル数が多い場合（30を上回る場合など）

単一のリポジトリですべてのオブジェクトを管理するアプローチを採用した場合

この場合、ファイルを管理するためのサード・パーティ製ソース管理ツールを使用す

る必要がなくなります。

この場合に、「第 2部リポジトリ移行」に記載されている章で関係のある個所は次のとお

りです。






上述の章のうち、データのバージョン管理を取り扱う項は省いてかまいません。

29

バージョン管理を利用したフォルダバージョン管理を利用したフォルダバージョン管理を利用したフォルダバージョン管理を利用したフォルダ/ファイルの管理ファイルの管理ファイルの管理ファイルの管理

バージョン管理を使用する場合は、Oracle Designer 6iリポジトリのインストール後に

Repository Administration Utilityのバージョン・サポート・オプションを有効にし、少なくと

も何人かのユーザーに対してコンテナの「バージョン」アクセス権限を付与します。第 2

部の第 6章「第 6章ユーザーの移行およびアクセス権限の割当て」も参照してください。

バージョン管理を使用する理由は、次のとおりです。

アプリケーションがすでに本番であり、このアプリケーションをメンテナンスし同時

に新たに機能を追加したり、既存の機能を変更したりするため

多数の影響分析ツールを使用し、配布プロセスの品質を向上させるため

複数の顧客に対し複数のリリースを開発およびサポートする必要があるため

複数の言語でアプリケーションを開発する必要があるため

いくつかの並行開発をサポートする必要があるため

開発者がお互いのソースを頻繁に上書きしてしまい、作業が失われがちになるので、

個々の作業領域を管理する必要があるため

前述の 2つに比べると、移行の労力は大きくなる可能性があります。この場合に、「第 2

部リポジトリ移行」に記載されている章で関係のある個所は次のとおりです。




「第 5章移行後の Oracle Designer 6iリポジトリの再編成」




31

第第第第 2部部部部リポジトリの移行リポジトリの移行リポジトリの移行リポジトリの移行


33

第第第第 1章章章章概要概要概要概要

第 2部では、旧リリースの Oracle Designerからの構造化要素の移行、およびファイル・シ

ステムからのファイル/フォルダの移行に関して説明します。移行のステップは、次の通り

です。

a. 準備

b. 構造化要素の移行

Oracle Designer 1.3.2/1.4/2.1.1から 6.0への移行（*）

Oracle Designer 6.0から 6iへの移行

c. ファイルの移行（*）

d. リポジトリの再編成（*）

e. ユーザーの移行およびアクセス権の設定

f. リポジトリ APIスクリプトの移行

（*）....これらの手順は、選択された移行形態によっては省くことができます。

「準備」ステップでは、旧リリースにおいて不必要な（移行対象とはならない）要素のク

リーン・アップを行います。

その後、定められた移行手順に従って「構造化要素の移行」を行います。

Oracle Designer 6iリポジトリへの構造化要素の移行は、Oracle Designer 6.0（または 2.1.2）

リポジトリからのみサポートされます。Oracle Designerの現行リリースが 1.3.2/1.4/2.1.1

である場合は、一度 Oracle Designer 6.0に移行する必要があります。したがって、それ

に該当する場合は、上記の 2つの手順（準備および構造化要素の移行）を 2度実行す

ることが必要です。

Oracle Designer 6iリポジトリへの構造化要素の移行後、それらをチェックインすることで、

バージョン管理が開始されます。

構造化要素の移行後に「ファイルの移行」を行い、ファイルと構造化要素を統合できます。

これによって、両タイプの要素とも、同一環境で管理することが可能になります。


両タイプの要素の移行の後に、ワークエリアやコンフィグレーションを定義することによ

って、主な開発工程の環境を再現することができます。この「再編成」ステップは必要に

応じて行います。

再編成されたリポジトリは従属ユーザーに対しアクセス可能である必要があります。「従

属ユーザーの作成および適切なアクセス権の付与」に関するガイドラインを提供します。

また、旧リリースでリポジトリ APIによるアクセスを行っていた場合、そのスクリプトを

変更する必要があります。「リポジトリ APIの移行」では、変更すべき個所について取り

上げます。

35

第第第第 2章章章章移行作業前の準備移行作業前の準備移行作業前の準備移行作業前の準備

この章では、実際の移行作業の前に検討すべき準備についてふれます。ここで説明する項

目は、次のとおりです。

移行手順の説明で使用するサンプル・データについて

クリーン・アップ

サンプル・データについてサンプル・データについてサンプル・データについてサンプル・データについて

以後の移行手順に関する説明の中で、サンプル・データとして 2つのアプリケーション・

システム CUSTOMERおよび PRODUCTを使用します。アプリケーション・システム

PRODUCTは CUSTOMERのドメイン CUST_TYPEを共有しており、表定義 CUSTOMERS

の列 CUSTOMER_TYPEのベースとして参照しています。

Oracle Designer 6.0でこのサンプル・データを参照すると以下のようになります。


旧リポジトリ・データのクリーン・アップ旧リポジトリ・データのクリーン・アップ旧リポジトリ・データのクリーン・アップ旧リポジトリ・データのクリーン・アップ

旧リリースの Oracle Designerリポジトリのクリーン・アップを移行前に行います。これは

移行に要する時間を節約するだけではなく、今後のリポジトリ・メンテナンスの労力を抑

えます。

構造化要素に適用すべきクリーン・アップ・チェックリストは次のとおりです。

廃止したユーザーの削除

使用していないアプリケーション・システムの削除

廃止したオブジェクトの削除および使用していないオブジェクトの共有化解除

使用していないダイアグラム（旧バージョンのものなど）およびリポジトリ・データ

から完全に導出できるダイアグラム（モジュール・ダイアグラムなど）の削除

他のすべてのダイアグラムの整理統合

ダイアグラムの情報は構造化要素およびそのプロパティとは別に格納されているので、

常に同期がとられているとは限りません。整理統合オプションにより、ダイアグラム

情報が構造化要素およびこのプロパティの情報と同期化することができます（Oracle

Designer 2.x/6.0でダイアグラムの統合を行うには、メニューから「編集」→「整理統

合」→「すべて」を選択します）。

37

第第第第 3章章章章構造化要素の移行構造化要素の移行構造化要素の移行構造化要素の移行

構造化要素の移行を行います。構造化要素の移行に関して説明する項目は、次のとおりで

す。

構造化要素の移行計画の概要

Oracle Designer 6.0リポジトリへの移行（該当する場合）

Oracle Designer 2.1.2/6.0リポジトリから Oracle Designer 6iへの移行

構造化要素の移行後のステップ

移行された構造化要素の検証

バージョン管理を使用しない場合でも、構造化要素の移行で発生するアクティビティの大

部分が適用されます。バージョン管理しないリポジトリに適用されない項については、イ

タリック体で記述しています。

構造化要素の移行計画構造化要素の移行計画構造化要素の移行計画構造化要素の移行計画

Oracle Designer 6iでは移行方法が大幅に変更されています。この移行では Oracle Designer

2.1.2/6.0リポジトリを Oracle Designer 6iリポジトリにアップグレードするのではなく、

Oracle Designer 2.1.2/6.0リポジトリのデータだけを、新規 Oracle Designer 6iリポジトリに変

換してコピーします。Oracle Designer 6iへの移行は Oracle Designer 2.1.2または Oracle

Designer 6.0リポジトリからのみサポートされていることに注意してください。

つまり、ユーザーによっては、Oracle Designer 1.3.2/1.4/2.1.1から 6.0への移行を行い、さら

に 6iへの移行を実行する必要があります。どちらの場合にも以下で説明する移行計画を立

てることが重要です。

リポジトリ・データの移行計画には、次の 2種類が考えられます。

リポジトリ・データ全体を一度に移行

リポジトリ内の特定のアプリケーション・システムを部分的に移行

前者の移行計画では、すべてのアプリケーション・システムのデータが一度に新規 Oracle

Designerリポジトリにロードされ、移行されます。


後者の移行計画では、相互関係のあるいくつかのアプリケーション・システムのセットに

分割して、ロード、移行を行います。ロード、移行の際に選択されなかったアプリケーシ

ョン・システムは次の移行の対象となります。

リポジトリ・データ全体の移行リポジトリ・データ全体の移行リポジトリ・データ全体の移行リポジトリ・データ全体の移行

旧リリースから構造化要素を移行するために、いくつかのシナリオが考えられます。この

項では、リポジトリ全体の移行について説明します。

リポジトリ・データ全体の移行アプローチが該当する環境は次のとおりです。

アプリケーション・システムの構造化要素が相互に密接に関係している場合

アプリケーション・システム間のデータの共有によって多数の相互依存性が存在する

ため、アプリケーション・システムの部分的な移行が難しい（次の図を参照）。

旧リリースのOracle Designerリポジトリ

移行後のOracle Designerリポジトリ

アプリケーション・システム

共有

リポジトリのボリュームが小さい場合

アプリケーション・システムの部分的な移行アプリケーション・システムの部分的な移行アプリケーション・システムの部分的な移行アプリケーション・システムの部分的な移行

この移行シナリオが適用される環境は、次のとおりです。

旧リリースからの移行において、試験的な移行が計画されている場合

試験的な移行や移行シナリオを評価する場合は、すべてのアプリケーション・システ

ムとファイルを移行しなくてもかまいません。

一部のアプリケーション・システムのまとまったセットを移行して、新しいリポジト

リでのみ設計を再開し、旧リリースの Oracle Designerリポジトリに残されたアプリケ

39

ーション・システムで、移行されたセットとの関連性を持つデータには何も変更が加

えられない場合（次の図を参照）

旧リリースのOracle Designerリポジトリ

移行後のOracle Designerリポジトリ

移行ごとに相互に独立したアプリケーション・システムをセットとして選択していれ

ば、この移行方法は複雑ではありません。相互に排他的ならば、簡単にアプリケーシ

ョン・システムの新規セットを Oracle Designer 6iリポジトリに追加できます。もし、

移行元のリポジトリに残されたデータが変更される（つまり、新旧 2つのリリースの

リポジトリに同時に変更が加えられる）可能性がある場合は、移行シナリオはより複

雑になります（次のケースを参照してください）。高度に相互依存したアプリケーシ

ョン・システムを分割して移行することは避ける必要があります。

構造化要素およびファイルの移行が行われている途中でも、移行元のリポジトリでシ

ステムのサポートやメンテナンスをするために、データに変更が必要となる場合

このような暫定的な変更は移行先のリポジトリにも伝える必要があります。

つまり、後から移行元リポジトリに加えられた変更だけを移行する（小規模な）第二

の移行サイクルが必要となります。この移行のためには、

− 移行元リポジトリに対する変更個所の判別

− 移行先リポジトリの該当する要素への変更点のマージ

を行わなくてはなりません。

最後に説明した段階的アプローチで必要な移行ステップは、後ほどこの章で説明されます。

第 3章「段階的移行アプローチにおける構造化要素に対する移行後のステップ」を参照し

てください。

Oracle Designer 1.3.2/1.4、、、、2.1.1からからからから 6.0への移行ステップへの移行ステップへの移行ステップへの移行ステップ

Oracle Designer 2.1.2/6.0にすでに移行している場合は、このステップを省くことができます。


Oracle Designer 6iリポジトリへの構造化要素の移行は、Oracle Designer 2.1.2/6.0リポジトリ

からのみサポートされます。Oracle Designerの現行リリースが 1.3.2/1.4/2.1.1である場合は、

一度 Oracle Designer 6.0に移行する必要があります。Oracle Designer 6i製品には、

1.3.2/1.4/2.1.1ユーザーが 6iへ移行するために必要となる 6.0への移行用の CD（Upgrade from

Oracle Designer 1.3.2/1.4 to 6.0）が付属されています。この移行に関する詳細情報は、

『Upgrade from Oracle Designer 1.3.2/1.4 to 6.0インストレーション・ガイド』の第 2章「サー

バー側のインストールおよびアップグレード」に記載されています。また、OTN-Jのホー

ムページ（http://otn.oracle.co.jp）より『R1.xから R2.x/R6.0への移行ガイド』がダウンロー

ド可能です。

以下の表および図は、リリース 6.0への移行において必要な手順（どちらのリポジトリに対

してどのタイミングで何の作業をすべきか）を表現しています。

移行計画移行計画移行計画移行計画旧リリースのリポジトリに対して旧リリースのリポジトリに対して旧リリースのリポジトリに対して旧リリースのリポジトリに対して必要な手順必要な手順必要な手順必要な手順

移行されたリポジトリに対して移行されたリポジトリに対して移行されたリポジトリに対して移行されたリポジトリに対して必要な手順必要な手順必要な手順必要な手順

全体の

移行

- ユーザー拡張性のアンロード（*） - Oracle Designer 6.0 Repository Administration Utilityによる

アップグレード

- ユーザー拡張性のロード（*）

部分的な

移行

- ユーザー拡張性のアンロード（*）

- アプリケーション・システムの

エクスポート

- リポジトリの新規インストール

- ユーザー拡張性のロード（*）

- アプリケーション・システムの

インポート

（*）....これらの手順は、ユーザー拡張性を使用していない場合は省くことができます。

新規リポジトリのインストール

アプリケーション・システムのインポート

アプリケーション・アプリケーション・アプリケーション・アプリケーション・システムのシステムのシステムのシステムの部分的な移行部分的な移行部分的な移行部分的な移行

アップグレードリポジトリ・データリポジトリ・データリポジトリ・データリポジトリ・データ全体の移行全体の移行全体の移行全体の移行

時系列

ユーザー拡張性のアンロード

ユーザー拡張性のロード

アプリケーション・システムのエクスポート

41

以下では、主な作業に関して取り上げて説明しています。実際の手順や注意事項について

は、『Upgrade from Oracle Designer 1.3.2/1.4 to 6.0インストレーション・ガイド』の第 2章「サ

ーバー側のインストールおよびアップグレード」を参照してください。

旧リリースのリポジトリに対する移行作業旧リリースのリポジトリに対する移行作業旧リリースのリポジトリに対する移行作業旧リリースのリポジトリに対する移行作業

ユーザー拡張性のアンロード（オプション）ユーザー拡張性のアンロード（オプション）ユーザー拡張性のアンロード（オプション）ユーザー拡張性のアンロード（オプション）

ユーザー拡張性を定義していない場合、または Oracle Designer 6iリポジトリにユーザー拡

張性を引き渡さない場合は、このアクティビティを省くことができます。

ユーザー拡張性を維持するためには、Oracle Designer 1.3.2/1.4/2.1.1ユーザー拡張性をアンロ

ードする必要があります。アンロード・オプションは、旧リリースの Oracle Designer

Repository Administration Utilityから使用します。

アプリケーション・システムのエクスポート（部分的な移行の場合）アプリケーション・システムのエクスポート（部分的な移行の場合）アプリケーション・システムのエクスポート（部分的な移行の場合）アプリケーション・システムのエクスポート（部分的な移行の場合）

前述した「アプリケーション・システムの部分的な移行」計画を選択した場合、アプリケ

ーションのエクスポート・オプションを使用します（Repository Object Navigatorで使用可能）。

Oracle Designer 6.0リポジトリの構築リポジトリの構築リポジトリの構築リポジトリの構築

Repository Administration Utilityアップグレード・ウィザードの実アップグレード・ウィザードの実アップグレード・ウィザードの実アップグレード・ウィザードの実行（全体の移行の場合）行（全体の移行の場合）行（全体の移行の場合）行（全体の移行の場合）

前述した「リポジトリ・データ全体の移行」計画を選択した場合、Oracle Designer 6.0クラ

イアント・ソフトウェアをインストールし、Oracle Designer 6.0 Repository Administration

Utilityからアップグレード・ユーティリティを開始してリポジトリ・データ全体を Oracle

Designer 6.0に更新します。

Oracle Designer 6.0リポジトリのインストール（部分的な移行の場合）リポジトリのインストール（部分的な移行の場合）リポジトリのインストール（部分的な移行の場合）リポジトリのインストール（部分的な移行の場合）

前述した「アプリケーション・システムの部分的な移行」計画を選択した場合、新規に Oracle

Designer 6.0リポジトリをインストールする必要があります。


Oracle Designer 6.0リポジトリでの移行作業リポジトリでの移行作業リポジトリでの移行作業リポジトリでの移行作業

ユーザー拡張性のロード（オプション）ユーザー拡張性のロード（オプション）ユーザー拡張性のロード（オプション）ユーザー拡張性のロード（オプション）

Oracle Designer 6.0リポジトリにユーザー拡張性を引き渡すためには、ユーザー拡張性の情

報を新規 Oracle Designer 6.0リポジトリにロードする必要があります。抽出したアプリケー

ション・システムを介して移行計画を適用する場合は、Oracle Designer 1.3.2/1.4/2.1.1ユーザ

ー拡張性を Oracle Designer 6.0リポジトリにロードします。

抽出されたアプリケーション・システムのインポート（部分的な移行の場合）抽出されたアプリケーション・システムのインポート（部分的な移行の場合）抽出されたアプリケーション・システムのインポート（部分的な移行の場合）抽出されたアプリケーション・システムのインポート（部分的な移行の場合）

前述した「アプリケーション・システムの部分的な移行」計画を選択した場合、アプリケ

ーションの復元オプションを使用します（Repository Object Navigatorから使用可能）。

骨組みだけのアプリケーション・システムを避けるために、アプリケーション・システム

のまとまったセットを選択する必要があることに注意してください。移行後に Oracle

Designer 1.3.2/1.4/2.1.1リポジトリ内の選択したアプリケーション・システムに変更が適用さ

れる場合、移行に関する作業が追加して必要になります。移行後に Oracle Designer

1.3.2/1.4/2.1.1リポジトリが変更されるのを防ぐために、（堅強な方法として）アプリケー

ションの凍結オプションを使用することができます。

Oracle Designer 6iの移行準備の移行準備の移行準備の移行準備

構造化要素およびファイルの移行は、クライアント側に Oracle Designer 6iがインストール

され、サーバー側の Oracle 8iデータベース・インスタンス内に新しくリポジトリがインス

トールされた後で行います。実際のクライアント側およびサーバー側のインストール手順

に関しては、『Oracle Designer for Windows インストレーション・ガイド』を参照してくだ

さい。ここには、クライアント側およびサーバー側のハードウェアについての推奨事項も

記載されています。

この項では、クライアント側およびサーバー側のインストールの検証、移行に関する Oracle

Designer 6iの準備について説明します。

クライアント側およびサーバー側のインストールと検証クライアント側およびサーバー側のインストールと検証クライアント側およびサーバー側のインストールと検証クライアント側およびサーバー側のインストールと検証

新規 Oracle Designer 6iインストールの検証は、クライアント側およびサーバー側でそれぞ

れの検証手順があります。

43

クライアント側の検証クライアント側の検証クライアント側の検証クライアント側の検証

Oracle Designer 6iツールのクライアント側インストールを検証するために、Oracle Installer

を使用します。

Oracle Installerでは、右側のウィンドウ（Oracle Homeディレクトリにインストールされた製

品）に少なくとも次のエントリが表示されます。

Oracle Designer 6i Product（6.5.x）

Oracle Designer Tools（7.2.x）

Oracle Repository 6i Product（6.5.x）

Oracle Repository Tools and API（6.5.x）

さらに、次のエントリが表示される場合もあります。

Oracle Modeling and Repository Online Documentation（7.2.x）

Oracle Modeling and Repository Help Product（7.2.x）

Oracle Designer 6iのリポジトリは、Oracle 8.1.6以降のデータベースのみサポートされていま

す。Oracle 8.1.6固有のエントリで、必要となるものは次のとおりです。

Oracle Designer 6i Import and Export Tools 1.x

サーバー側の検証サーバー側の検証サーバー側の検証サーバー側の検証

Oracle Designer 6iリポジトリ・インストールが成功したかどうかを検証するために 2種類の

方法が用意されています。

インストール・ログ・ファイルの検証

インストール後に ORACLE_HOME¥repadm61¥logsディレクトリに書き込まれた Oracle

Designer 6iインストール・ログ・ファイルの内容を検証し、エラーがないことを確認

してください。

Oracle Designer 6i Repository Administration Utilityの「オブジェクトの表示」オプション

Oracle Designer 6i Repository Administration Utilityを起動し、リポジトリ所有者で接続し

ます。サーバー側インストールを検証するには「オブジェクトの表示」オプションを


開始します。Oracle Designer 6iインストールが成功していれば、ステータス・プロパテ

ィに以下の値をもつオブジェクトは存在しません。

− DISABLE（使用禁止）

− MISSING（欠落）

− INVALID（無効）

ダイアログのリスト・ボックスから上記の値を選択します。これらの値をもつオブジ

ェクトが存在する場合のみ、ダイアログ内にオブジェクト名がリストされます。

バージョン管理機能の利用の選択バージョン管理機能の利用の選択バージョン管理機能の利用の選択バージョン管理機能の利用の選択

Oracle Designer 6iリポジトリをバージョン管理対応モードまたはバージョン管理を行わな

いモードのどちらか一方で実行できます。バージョン管理を使用するかどうかについては、

第 1部の第 3章「リポジトリに対するバージョン管理機能の有効化」を参照して

ください。

バージョン管理を使用しない場合は、次のアクティビティを省いてください。

バージョン管理を使用する場合、新規リポジトリのインストール後にリポジトリ所有者で

接続し、Repository Administration Utilityのメニュー「オプション」→「バージョン・サポー

トの有効化」を選択します。これによって、バージョン管理が行えるようになります。

一度バージョン管理を有効にするとバージョン管理サポート・オプションを無効にするこ

とはできません。つまり、バージョン管理機能が有効でないことが望まれる場合は、新規

Oracle Designer 6iリポジトリを再作成しなければなりません。

パブリック・シノニムまたはプライベート・シノニムの選択パブリック・シノニムまたはプライベート・シノニムの選択パブリック・シノニムまたはプライベート・シノニムの選択パブリック・シノニムまたはプライベート・シノニムの選択

Oracle Designer 6iリポジトリを構成するデータベース・テーブルに対して、パブリック・シ

ノニムまたはプライベート・シノニムのどちらかの使用を選択できます。次に示されてい

るように、プライベート・シノニムの有効化/無効化は、Repository Administration Utilityで

実行できます。

45

パブリック・シノニムを使用すると、ユーザーごとの調整が不要になるため、より生産的

になり、システム表領域に占める領域も少なくてすみます（ユーザーごとに 1500を越える

プライベート・シノニムを作成する必要がなくなります）。しかし、パブリック・シノニ

ムを使用する場合、データベース・インスタンスごとに 1つの Oracle Designer 6iリポジト

リ・インスタンスしか作成できないことに注意してください。

Oracle Designer 2.1.2/6.0からからからから 6iへの移行ステップへの移行ステップへの移行ステップへの移行ステップ

現行リリースが Oracle Designer 2.1.2/6.0である場合、次の移行ステップを行います。

Oracle Designer 2.1.2/6.0リポジトリのクリーン・アップおよびパフォーマンスの最適化

リポジトリのバックアップ

リポジトリ上にロールバック・セグメントを作成

ユーザー拡張性のアンロード/ロード

リポジトリ・ユーザーの権限チェック

従属ユーザーの移行

TNSNAMES.ORAの指定

移行ウィザードの開始


構造化要素のチェックイン

以下では、主な作業に関して取り上げて説明しています。実際の手順や注意事項について

は、『Oracle Designer for Windows インストレーション・ガイド』の第 2章「サーバー側の

インストールおよび移行」を参照してください。

旧リリースのリポジトリからユーザー拡張性のアンロード（オプション）旧リリースのリポジトリからユーザー拡張性のアンロード（オプション）旧リリースのリポジトリからユーザー拡張性のアンロード（オプション）旧リリースのリポジトリからユーザー拡張性のアンロード（オプション）

ユーザー拡張性を定義していない場合、または Oracle Designer 6iリポジトリにユーザー拡

張性を移行しない場合は、このアクティビティは省いてかまいません。

ユーザー拡張性を維持するために、Oracle Designer 6.0ユーザー拡張性をアンロードする必

要があります。アンロード・オプションは、Oracle Designer 6.0 Repository Administration Utility

から利用できます。

ユーザー拡張性をユーザー拡張性をユーザー拡張性をユーザー拡張性を Oracle Designer 6iへロード（オプション）へロード（オプション）へロード（オプション）へロード（オプション）

Oracle Designer 6iリポジトリにユーザー拡張性を引き渡す場合は、アプリケーション・シス

テムを移行する前にユーザー拡張性を新規 Oracle Designer 6iリポジトリにロードする必要

があります。いずれの移行計画を使用する場合も、Oracle Designer 6.0ユーザー拡張性を新

規 Oracle Designer 6iリポジトリにロードしてください。ロード・オプションは、Oracle

Designer 6i Repository Administration Utilityから利用できます。

移行ウィザードの開始移行ウィザードの開始移行ウィザードの開始移行ウィザードの開始

移行ウィザードを開始する前に、Oracle Designer 6iがインストールされたマシンおよび

Oracle Designer 6iリポジトリがインストールされたマシンの両方の TNSNAMES.ORAファ

イルに、Oracle Designer 6.0リポジトリへの接続文字列が同じ値で設定されていることを確

認してください。

47

移行ウィザードにより、Oracle Designer 6.0リポジトリが実際にクリーン・アップされます。

たとえば、無効な参照の修正、不足しているプロパティの移入、無効なプロパティの更新

または、重複値の強制削除が行われます。

この移行ウィザードで Oracle Designer 6.0リポジトリに接続し、1つ以上のアプリケーショ

ン・システムを選択できます。ウィザードでは、選択されていない他のアプリケーション・

システムから共有を受け取っているかどうか検証します。もし受け取っている場合には、

その（共有を提供している）アプリケーション・システムも移行するアプリケーション・

システムとして選択に追加されます。例えば、アプリケーション・システム PRODUCTは

CUSTOMERのドメインを参照しているので、共有を受け取る側です。PRODUCTのみを移

行するアプリケーション・システムとして選択すると、PRODUCTに対して共有を提供して

いる CUSTOMERも移行アプリケーション・システムとして選択に追加され、CUSTOMER

内のすべてのオブジェクトが移行されます。

移行するアプリケーション・システムのまとまりの選択はとても重要になります。このま

とまりは共有の受け取りだけでなく、共有の提供にも関係します。たとえば、最初にアプ

リケーション・システム CUSTOMERを移行し、次に PRODUCTを移行する場合、PRODUCT

はCUSTOMERのから共有を受け取っているのでCUSTOMERが再度選択されます。しかし、

すでに CUSTOMERはすでに移行されているので再選択する必要はありません。つまり、こ

のサンプルでは、CUSTOMERと PRODUCTをセットとして移行する必要があります。

移行ウィザードでは、リポジトリがバージョン管理に対応していない場合、ワークエリア

GLOBAL_SHARED_WORKAREAに移行データが移入されます。

リポジトリがバージョン管理に対応している場合、ウィザードにより移行されたデータは

新規に生成されたワークエリアに移入されます。ワークエリア名はユーザー名、接続文字

列を使った名前（例：WA_des60_ds）で作成されます。この生成されたワークエリアの規則

を確認してください。デフォルトの規則としては、

INCLUDE_FOLDER（SYSTEM FOLDER{MAIN;LATEST}）

だけが含まれていますので、この後で構造化要素をチェックインする予定の場合は、ユー

ザーの仕様に合うようにこの規則を変更する必要があります。ワークエリアに指定されて

いる規則がこれだけの場合、最初に構造化要素をチェックインした後でワークエリアをリ

フレッシュすると、チェックインした構造化要素が表示されなくなります。ワークエリア

およびワークエリア規則の詳細は、第 5章「移行後の Oracle Designer 6iリポジト

リの再編成」を参照してください。

Oracle Designer 2.1.2/6.0と同様に、移行処理の進行時には移行操作を制御できます。移行操

作は複数のステージに分割されます。現行のステージを中断して再開したり、失敗したス

テージを再試行またはスキップしたり、操作全体を中止したりすることができます。


このような移行処理操作の制御を行うために、アップグレード中に制御ボタンを含む「コ

ントロール・ステータス」ダイアログ・ボックスが表示されます。

49

制御ボタンの種類と制御内容は次の通りです。

ボタンボタンボタンボタン名前名前名前名前制御内容制御内容制御内容制御内容

開始現在中断している操作を再開

再試行現行ステージの操作を再試行

スキップ失敗した操作を無視し、次ステージの操作を開始

中断操作を中断、または現在中断している操作を再開

中止操作を中止

たとえば、アップグレード時にロールバック・セグメントのエクステントが不足した場合、

現行のステージでアップグレードを中断し、より大きいロールバック・セグメントを割り

当て、失敗が発生したステージからアップグレードを再開できます。

移行中または移行後に、ORACLE_HOME¥repadm61¥logsディレクトリに書き込まれた移行

ログ・ファイルの内容を検証し、エラーが起こっていないか確認してください。

アプリケーション・システムは、バージョン・ナンバーを接尾辞としたアプリケーション・

システム名で移行されます（CUSTOMER（3）または PRODUCT（1）など）。

Oracle Designer 6iリポジトリ・データは、構造化要素の移行後では次のようになります。


構造化要素の移行後のステップ構造化要素の移行後のステップ構造化要素の移行後のステップ構造化要素の移行後のステップ

この項では、構造化要素に対して移行ウィザードでは処理されないアクティビティを取り

上げます。

旧リリースにおけるアプリケーション・システムの親子関係について旧リリースにおけるアプリケーション・システムの親子関係について旧リリースにおけるアプリケーション・システムの親子関係について旧リリースにおけるアプリケーション・システムの親子関係について

Oracle Designerの旧リリースにアプリケーション・システム階層（アプリケーション・シス

テムの親子関係）を定義していない場合は、このアクティビティは省いてかまいません。

51

Oracle Designer 6iでのアプリケーション・システム階層の実装は、旧リリースの Oracle

Designerでのアプリケーション・システム階層の実装とはかなり異なっていることに注意し

てください。Oracle Designer 6iにより、完全なコンテナの階層を定義できます（アプリケー

ション・システムが他のアプリケーション・システムやフォルダを含んだり、フォルダが

他のフォルダやアプリケーション・システムを含むことができます）。旧リリースの Oracle

Designerとは異なり、Oracle Designer 6iでは、すべてのコンテナは階層での位置にかかわら

ず、下位オブジェクト（エンティティ、表など）を含むことができます。

そのため、移行前と移行後においてアプリケーション・システム階層を再検討してくださ

い。親アプリケーションの移行の際、自動的に子アプリケーションは移行されません。し

かし、子を移行すると自動的に親が移行されます。子の移行の際に親を移行したくない場

合は、子アプリケーション・システムから親への参照を削除してください。

構造化構造化構造化構造化要素のチェックイン要素のチェックイン要素のチェックイン要素のチェックイン

バージョン管理をまだ使用していない場合は、このアクティビティは省いてかまいません。

バージョン管理を使用する場合、次のステップを実行します。

ワークエリアおよびコンテナに対するリポジトリ・ユーザーのアクセス権の検証

「チェックアウトのリスト」オプションを使用して全構造化要素のチェックイン

アクセス権の検証アクセス権の検証アクセス権の検証アクセス権の検証

ワークエリアおよび移行されたアプリケーション・システムに対して Oracle Designer 6iリ

ポジトリ・ユーザーのアクセス権を検証します。ワークエリア内でオブジェクトをチェッ

クインするために、Oracle Designer 6iリポジトリ・ユーザーはワークエリア、アプリケーシ

ョン・システムの両方のオブジェクトに対してバージョン権限が付与されている必要があ

ります。Repository Object Navigatorで右クリック・メニュー「アクセス権の付与」を選択し、

ワークエリアおよびアプリケーション・システムに対するアクセス権を示します。


リポジトリ・ユーザーのアクセス権を検討、定義するために、複数のワークエリアおよび

アプリケーション・システムを同時に選択できます。

構造化要素構造化要素構造化要素構造化要素のチェックインのチェックインのチェックインのチェックイン

移行ウィザードによってリポジトリに構造化要素がロードされましたが、オブジェクトの

チェックインは行われていません。Repository Object Navigatorには、バージョン管理下にな

いオブジェクトすべてを同時にチェックインするオプションが用意されています。各コン

テナで右クリック・メニュー「チェックアウトのリスト...」を選択すると、「チェックアウ

トのリスト基準」ダイアログが表示されます。

53

指定したコンテナ内にある、バージョン管理下にないオブジェクトすべてを一覧するため

に、｢バージョンのないオブジェクト｣をチェックします。

「OK」ボタンをクリックすると、指定したコンテナ内にある、バージョン管理下にないオ

ブジェクトすべてが表示されます。

チェックインできるのは指定されたコンテナに格納されているオブジェクトのみで、実体

が別のコンテナにあるショート・カットはチェックインされるべきではありません。した

がって、そのようなオブジェクトはリスト内に選択されません。

チェックインするオブジェクトが選択された状態で「チェックイン」をクリックすると、

「チェックイン」ダイアログが表示されます。

次に示すように、「チェックイン」ダイアログでチェックインしようとしているすべての

オブジェクトに対して一度に同じ記述を適用しておくと大変便利です（例では、「初期の

チェックイン」と入力しています）。


「チェックアウトのリスト」オプションによってバージョン管理下にないオブジェクトを

まとめてチェックインする際には、自動的にそのオブジェクトを格納しているアプリケー

ション・システムも選択され、チェックイン対象となります。

構造化要素に対するバージョン・ツリーの構築構造化要素に対するバージョン・ツリーの構築構造化要素に対するバージョン・ツリーの構築構造化要素に対するバージョン・ツリーの構築

バージョン管理をまだ使用していない場合、または複数のオブジェクト・バージョンをま

だ使用しない場合は、このアクティビティは省いてかまいません。

旧リリースの Oracle Designerでは、バージョン管理はアプリケーション・システム・レベ

ルでしか行うことができませんでした。複数のオブジェクト・バージョンを格納するには、

アプリケーション・システムのコピーを作成するか、またはアプリケーション・システム

単位のバージョン管理をしていました。どちらの場合も、同じタイプで同じ名前の、実体

は異なるオブジェクトを作成することによって異なるバージョンを表現したに過ぎません。

移行ウィザードでは、これらの異なるオブジェクト・バージョンはバージョン・ツリーと

して移行されず、完全に異なるオブジェクトとして処理します。このような異なるオブジ

ェクトから、リリース 6iのバージョン・ツリーを構築するには、次に挙げる方法をとりま

す。

55

エクスポートエクスポートエクスポートエクスポート/インポート・ユーティリティを使ったバージョン・ツリーの構築インポート・ユーティリティを使ったバージョン・ツリーの構築インポート・ユーティリティを使ったバージョン・ツリーの構築インポート・ユーティリティを使ったバージョン・ツリーの構築

バージョン・ツリーを構築するために、エクスポート/インポート・ユーティリティ（旧リ

リースでのアンロード/ロード）を使用します。下図を参照してください。

CUSTOMER(1)CUSTOMER(1)CUSTOMER(1)CUSTOMER(1)

表定義表定義表定義表定義

1.01.01.01.0

1.0CO(1)1.0CO(1)1.0CO(1)1.0CO(1)

PRT_MESSAGE_TXTPRT_MESSAGE_TXTPRT_MESSAGE_TXTPRT_MESSAGE_TXT

リポジトリリポジトリリポジトリリポジトリ

…

…

CUSTOMER(2)CUSTOMER(2)CUSTOMER(2)CUSTOMER(2)

…

1.0 (1.1)1.0 (1.1)1.0 (1.1)1.0 (1.1)

PRT_MESSAGE_TXTPRT_MESSAGE_TXTPRT_MESSAGE_TXTPRT_MESSAGE_TXT

表定義表定義表定義表定義

WA_des60...WA_des60...WA_des60...WA_des60...

…

インポートインポートインポートインポートエクスポートエクスポートエクスポートエクスポート

C:C:C:C:\\\\WORKWORKWORKWORK\\\\PRT_MESSAGE_TXT.DATPRT_MESSAGE_TXT.DATPRT_MESSAGE_TXT.DATPRT_MESSAGE_TXT.DAT

バージョン・ツリーを構築するには、次のステップを実行します

1. （最も古いバージョンを表す）要素を移行ワークエリアからチェックアウトします

（例：ワークエリアWA_des60_dsのアプリケーション・システム CUSTOMER（1）の

表定義 PRT_MESSAGE_TXT[1.0]など）。これによって、チェックアウト・バージョン

1.0CO（１）が作成されます。

2. 次のバージョンとなるべきオブジェクト（CUSTOMER（2）¥PRT_MESSAGE_TXT[1.1]

など）を他のコンテナからテキスト・ファイルにエクスポートします。

右クリック・メニューから｢エクスポート｣を選択すると、エクスポート・ウィザード

が起動します。

3. エクスポートしたテキスト・ファイル（C:¥work¥prt_message_txt.datなど）をチェック

アウトしたオブジェクトに対しインポートします。

インポートもエクスポート同様に、右クリック・メニューからインポート・ウィザー

ドを起動することができます。


4. インポートされたことによって修正が加えられたチェックアウト・バージョン

（CUSTOMER（1）¥PRT_MESSAGE_TXT[1.0（1）]）と、エクスポート元のバージョ

ン（CUSTOMER（2）¥PRT_MESSAGE_TXT[1.1]）を比較ユーティリティを使用して比

較し、その結果を確認します。

バージョン比較ユーティリティは、チェックアウト・オブジェクトを選択した状態か

ら、メニューの「ユーティリティ」→「比較」を選ぶことで起動できます。

5. インポートされたオブジェクトをチェックインします（PRT_MESSAGE_TXT[1.1]とな

ります）。

必要なバージョンを構築するまで、1から 5のステップを繰り返します。

エクスポート/インポート方法でのバージョン・ツリー構築でもれた情報がないかどうかを

確認するためにも、ステップ 4で説明されているように比較ツールを使用して結果を検証

することが必要です。満足な結果を得られなかった場合、チェックインするかわりにチェ

ックアウトを取り消します。

段階的移行アプローチにおける構造化要素に対する移行後のステップ段階的移行アプローチにおける構造化要素に対する移行後のステップ段階的移行アプローチにおける構造化要素に対する移行後のステップ段階的移行アプローチにおける構造化要素に対する移行後のステップ

「アプリケーション・システムの部分的な移行」の頁で説明したように、プロジェクトに

よっては、リポジトリ・データの移行が行われている途中でも（移行元の）旧リリースの

リポジトリでシステムをメンテナンスする必要があることがあります。このような場合に

は、旧リリースのリポジトリに対して変更が加えられる場合が考えられ、その変更を移行

先にも反映させなければなりません。つまり、

− 移行元リポジトリに対する変更個所の判別

− 移行先リポジトリの該当する要素への変更点のマージ

を考える必要があります。

構造化要素の暫定的変更のマージ構造化要素の暫定的変更のマージ構造化要素の暫定的変更のマージ構造化要素の暫定的変更のマージ

旧リリースで起こった暫定的変更を Oracle Designer 6iに移行するためには、構造化要素に

次のステップを使用します。

1. 移行されて最初にチェックインされた日付を用いて、LATEST_BEFORE規則でワーク

エリアを作成します。たとえば、最初のチェックインが 2000年 11月 27日に行われた

場合、LATEST_BEFORE（MAIN;00-11-27）の規則だけにします。こうすることによ

って、このワークエリアは、暫定的な変更が適用される前のオリジナルのリポジトリ・

57

データを表すことになります。このワークエリアを介して他のユーザーによる変更は

許可しないでください。

2. 旧リリースのリポジトリで、変更された可能性のある構造化要素を判別します。これ

には、たとえば、各構造化要素の「変更日」プロパティなどを利用できます。

3. 変更された可能性のある構造化要素を含むアプリケーション・システムすべてを、移

行ウィザードで Oracle Designer 6iに移行します。

4. 1.で作成されたワークエリアから、2.で識別されたオブジェクトをすべてチェックアウ

トします。

5. 3.で移行されたオブジェクトを 4.のチェックアウト・バージョンに反映させます。こ

のとき、「エクスポート/インポート・ユーティリティを使ったバージョン・ツリーの

構築」で用いた方法を応用できます。つまり、移行されたオブジェクトをエクスポー

トして、チェックアウト・バージョンに対してインポートします。

6. 5.のステップによってワークエリア内のオブジェクトに変更が加えられたかどうかを

チェックします（比較ユーティリティを利用できます）。

− 変更が加えられていないオブジェクトは「チェックアウトを元に戻す」を実行し

てもかまいません。

− 変更が加えられているオブジェクトは、それをチェックインする必要があります。

7. 変更が加えられているオブジェクトのチェックインを行います。

− これらのオブジェクトのうち、1.で作成したワークエリア内のバージョンよりも

上位のバージョンが既に存在するものは、5.で変更されたチェックアウト・バー

ジョンとのマージを行う必要があります。次の図では、ワークエリアに選択され

たバージョン（1.1）よりも上位バージョン（1.2）が既に存在するため、1.1COと

1.2とをマージさせる必要があります。


1.01.01.01.01.01.01.01.0

1.11.11.11.11.11.11.11.1

1.21.21.21.21.21.21.21.2

表表表表DEPARTMENTDEPARTMENTDEPARTMENTDEPARTMENT

1.11.11.11.11.11.11.11.1

LATEST_BEFOREによるワークエリア

1.11.11.11.11.11.11.11.1（（（（（（（（COCOCOCOCOCOCOCO））））））））

移行されたデータの変更を反映

− 1.で作成したワークエリア内のバージョンが最新であるオブジェクトの場合、す

ぐにチェックインを実行することができます。

移行されたすべてのオブジェクトでこのようなチェックをする必要があります。上記ステ

ップ 7でのマージのために、マージ・ユーティリティが用意されています。これは、Repository

Object Navigatorおよび Version History Viewerから起動することができます。

移行された構造化要素の検証移行された構造化要素の検証移行された構造化要素の検証移行された構造化要素の検証

移行された構造化要素を検証する際に、以下の項目をチェックします。

Oracle Designer 6.0リポジトリで選択されたアプリケーション・システムはすべて、

Oracle Designer 6iリポジトリで使用できる必要があります。

共有はすべて、ショート・カットとして解釈される必要があります。

バージョン・ツリーを構築した場合、旧リリースの Oracle Designerで別々のアプリケ

ーション・システムに格納されていたオブジェクト・バージョンからの移行もれがな

いかどうか確認しておくことをお勧めします。

59

統計の計算統計の計算統計の計算統計の計算

リポジトリのパフォーマンスを低下させないために、「統計情報の算出」ユーティリティ

を定期的に、また特にリポジトリのサイズに大きく影響する操作の後に実行することをお

薦めします。

移行では、自動的に統計の計算ステージが開始されます。したがって、統計の計算を移行

直後に実行する必要はありません。

Oracle Designer 6i Repository Administration Utilityから「統計情報の算出」ボタンをクリック

し、ユーティリティを実行します。

多くの場合、デフォルト（50%など）より高い数値を使用することをお薦めします。しかし、

リポジトリに規模の大きい表がある場合、高い数値では計算操作が完了するまでの時間が

長くなるので、それを避けるためにはサンプル・サイズより低い数値を使用することが特

に重要となります。


61

第第第第 4章章章章ファイル・シファイル・シファイル・シファイル・システステステステムに格納されているムに格納されているムに格納されているムに格納されているファイファイファイファイルの移行ルの移行ルの移行ルの移行

Oracle Designer 6iでは、ファイル・システムに格納されているファイルをリポジトリ上に格

納することができます。これにより、ファイルも構造化要素と同様にバージョン管理や依

存性分析といった、リポジトリの様々な機能を活用することができます。また、リポジト

リに格納されたファイルは構造化要素と共に一元管理できるので、メンテナンスの効率も

向上します。ここで紹介するファイルのリポジトリへの移行は必須作業ではありませんが、

推奨されます。

通常、ファイル・システムに格納されているファイルの移行は、構造化要素の移行後に開

始します。これによって、両タイプの要素とも、同一環境で管理することが可能になりま

す。

Oracle Designer 6iでは、ファイルの移行はファイル・アップロード機能を利用します。

ファイルの移行ステップは、次のとおりです。

移行するファイル集合の作成

Oracle Designer 6iリポジトリへ移入

移行するファイルの集合の作成移行するファイルの集合の作成移行するファイルの集合の作成移行するファイルの集合の作成

移行するファイルの集合を作成する際、以下の作業を行います。

ファイル・システム・コンテンツの再構築

移行対象となるファイルを含んだファイル構造はローカル・ドライブ、ネットワーク・ド

ライブ、または UNIXファイル・システム上のものでも格納可能です。UNIXファイル・シ

ステムの場合、Windows環境上で UNIXファイル・システムを透過的にする（ネットワー

ク・ドライブとして表示される）ために特定のソフトウェア（Sambaなど）がインストー

ルされている必要があります。

ファイル・システムの再構築ファイル・システムの再構築ファイル・システムの再構築ファイル・システムの再構築

アップロードは、ファイル・システムを再構築するよい機会です。進行中の開発、テスト、

本番の環境を妨害しないように、それぞれに対してステージング領域（別個のディレクト

リ構造）を用意することをお薦めします。


ファイル・システムの再構築は、次の作業を行います。

全般的なディレクトリ構造の決定

ファイル・システムのクリーン・アップ

全般的なディレクトリ構造の決定全般的なディレクトリ構造の決定全般的なディレクトリ構造の決定全般的なディレクトリ構造の決定

リポジトリへのアップロードにより、ファイルだけでなくファイルを所有しているディレ

クトリ構造も取り込まれます。したがって、（サブ）フォルダやファイル・タイプについ

て、ディレクトリごとにファイル・システムの内容を調べる必要があります。次に、この

調査に基づいてディレクトリ構造を決定し、ステージング領域にその構造を作成します。

クリーン・アップのチェックリストクリーン・アップのチェックリストクリーン・アップのチェックリストクリーン・アップのチェックリスト

アップロードを行うファイル数を制限するため、次のチェックリストを参照してください。

廃止されたオブジェクト

一時ファイル

前述のチェックリストを適用して効率的なファイル集合を作成することで、Oracle Designer

6iへのアップロードおよびチェックインを最適化できます。

Oracle Designer 6iリポジトリへの移入リポジトリへの移入リポジトリへの移入リポジトリへの移入

ファイル・システムを再構築したら、再構築の際に作成したファイル集合を Oracle Designer

6iリポジトリに移入します。この移入操作は、2つのステップから構成されます。

（ルート）フォルダ・マッピングの適用

ファイルのアップロード、可能な場合はチェックイン

リポジトリ上でバージョン管理をまだ使用していない場合は、デフォルトの移行ワークエ

リア GLOBAL_SHARED_WORKAREAを使用する必要があります。

リポジトリ上でバージョン管理を使用している場合は、ファイル・オブジェクトのチェッ

クインを行うために、ファイルの移行用に任意のワークエリアを使用できます。最終的に

は、チェックインされたオブジェクトはすべて任意のワークエリアからアクセス可能とな

ります（ただし、ワークエリアに適用される規則に準じます）。

63

（ルート）フォルダ・マッピングの適用（ルート）フォルダ・マッピングの適用（ルート）フォルダ・マッピングの適用（ルート）フォルダ・マッピングの適用

アップロード（および可能であればファイルのチェックイン）の前に、フォルダ・マッピ

ングを実行します。ルート・コンテナでマウスの右ボタンをクリックし、「フォルダをフ

ァイル・システムにマップ」オプションを選択します。

このフォルダ・マッピング・オプションにより、ファイル・システム・コンテンツ（ディ

レクトリおよびファイル）をリポジトリにアップロードできます。次を参照してください。

リポジトリリポジトリリポジトリリポジトリ

[CUST_FOLDER]

…upg503.sqlupg503.sqlupg503.sqlupg503.sql

scripts

…

fndappf60

............

…

…qfd0014f.fmbqfd0014f.fmbqfd0014f.fmbqfd0014f.fmb…

WA_des60...WA_des60...WA_des60...WA_des60...

ファイル・システムファイル・システムファイル・システムファイル・システム

...\stage\prd\

…upg503.sqlupg503.sqlupg503.sqlupg503.sql

scripts

…

fndappf60

............

…

…qfd0014f.fmbqfd0014f.fmbqfd0014f.fmbqfd0014f.fmb…

フォルダ・マッピングフォルダ・マッピングフォルダ・マッピングフォルダ・マッピング


フォルダフォルダフォルダフォルダマッピングマッピングマッピングマッピング

たとえば、ディレクトリ F:¥customer以下を CUST_FOLDERコンテナに、ディレクトリ

F:¥product以下を PROD_FOLDERコンテナにマッピングします。コンテナを選択し、右ク

リック・メニューから「フォルダをファイル・システムにマップ...」を選択します。表示さ

れた「フォルダのマップ」ダイアログでマッピングの設定を行います。次を参照してくだ

さい。

65

ファイルのアップロードファイルのアップロードファイルのアップロードファイルのアップロード

アップロードにより、実際にリポジトリ内にファイルが格納されます。右クリック・メニ

ューから「ファイルとフォルダのアップロード...」を選択し、ダイアログ上でアップロード

の設定を行います（次の図を参照）。「サブフォルダも探す」オプションにチェックする

と、すべてのディレクトリおよびサブディレクトリがアップロードされます。つまり、デ

ィレクトリ構造がリポジトリにもロードされるため、全般的なディレクトリ構造を適用す

ることが重要になります。

ファイルのチェックインファイルのチェックインファイルのチェックインファイルのチェックイン

バージョン管理を使用していない場合、この項は省いてかまいません。

ファイルをチェックインする場合、アップロード時にチェックインを同時に実行したり、

構造化要素と同様に「チェックアウトのリスト...」オプションを使用することができます。

ファイルのチェックインにより、実際に格納されているファイルにバージョン・ナンバー

が適用されます。

ルート・コンテナごとに「チェックアウトのリスト..」オプションを使用して（フォルダを

含む）ファイル要素すべての"チェックイン"ステータスを検証できます。

アップロードおよびチェックイン後は、フォルダ CUST_FOLDERに対するコンテナおよび

サブコンテナ構造は次のようになります。


ソースソースソースソース/実行可能プログラムのアップロードとチェックインの検実行可能プログラムのアップロードとチェックインの検実行可能プログラムのアップロードとチェックインの検実行可能プログラムのアップロードとチェックインの検討討討討

構造化要素から自動生成されるソースや実行プログラムのアップロードおよびチェックイ

ンについても検討した方がよい場合があります。たとえば、Oracle Designerによって定義さ

れた構造化 Formモジュール定義から、FMBおよび FMXファイルが生成されます。このよ

うな導出ファイルを、同時にリポジトリへアップロードしておくことによって、モジュー

ル定義のバージョンと同期したファイルの管理が可能になります。

ファイル・システムに格納されたファイルに対する移行後のステップファイル・システムに格納されたファイルに対する移行後のステップファイル・システムに格納されたファイルに対する移行後のステップファイル・システムに格納されたファイルに対する移行後のステップ

ファイルに対する移行後のステップは、次のとおりです。

ファイルに対するバージョン・ツリーの構築

移行されたファイルの検証

統計の計算

ファイルに対するバージョン・ツリーの構築ファイルに対するバージョン・ツリーの構築ファイルに対するバージョン・ツリーの構築ファイルに対するバージョン・ツリーの構築

バージョン管理をまだ使用していない場合、またはファイルの複数のオブジェクト・バー

ジョンをまだ使用しない場合は、このアクティビティは省いてかまいません。

67

多くのプロジェクトでは、ファイル・システムでファイルのバージョンを管理するために、

異なる名前で、または異なる場所にファイルを格納しています。したがって、まずはじめ

に、ファイル・システム上のどこに、どのバージョンのファイルが格納されているのかを

調査する必要があります。

ここでは以下のような例を用いて、実際の構築手順を紹介します。

Dir ファイル名バージョン

… CUSTOMER announcement.txt CUSTOMER ¥customer¥prd¥doc¥ announcement.txt 1.0 CUSTOMER ¥customer¥acc¥doc¥ announcement.txt 1.0 CUSTOMER ¥customer¥tst¥doc¥ announcement11.txt 1.1 CUSTOMER ¥customer¥dev¥doc¥ announcement12.txt 1.2 … PRODUCT prtolb50.olb PRODUCT ¥product¥prd¥demof60¥ prtolb50.olb 1.6 PRODUCT ¥product¥acc¥demof60¥ prtolb50.olb 1.6 PRODUCT ¥product¥tst¥demof60¥ prtolb5016.olb 1.6 PRODUCT ¥product¥dev¥demof60¥ prtolb5017.olb 1.7 …

バージョン・ツリーは、この状況にそって構築していきます。

なお、通常、ファイルに対するバージョン・ツリーの構築は開発者が実行します。したが

って、移行後のアクティビティに責任がある開発者に対して、アクセスを認める必要があ

ります。リポジトリ、ワークエリアおよびコンテナへのリポジトリ・アクセス権のガイド

ラインについては、第 6章「ユーザーの移行およびアクセス権限の割当て」を参

照してください。

バージョン・ツリーを構築する際に、存在するファイル・バージョンのうち、移行する必

要のないものもあるかもしれません。例えば、存在するファイル・バージョンが少ない場

合にはすべてを移行してもそれほど問題ではありませんが、ファイル・バージョン間の差

異がわずかしかない場合や、ファイル・バージョン数が多すぎてすべてを移行するには膨

大な労力がかかる場合などは、いくつかのファイル・バージョンをスキップして移行する

こともあります。

バージョン・ツリーの構築バージョン・ツリーの構築バージョン・ツリーの構築バージョン・ツリーの構築

このアクティビティでは、ファイル・システムから Oracle Designer 6iに 1つ以上のファイ

ル・バージョンを移行します。バージョン・ツリーの構築は、一番古いバージョンから開

始します。


バージョン・ツリーを構築する手順は、次のとおりです。

1. Oracle Designer 6i内の関連するファイルを（ロックをかけて）チェックアウトします。

Repository Object Navigator上でオブジェクトを選択し、右クリック・メニューから｢チ

ェックアウト｣を選択します。｢チェックアウト｣ダイアログが起動しますので、｢ロッ

ク｣オプションにチェックしてチェックアウトします。

2. 次のバージョンをファイル・システム上の作業ディレクトリにコピーします。別のバ

ージョンが異なる名前で収集されている場合、名前を変更する必要があります。

3. Oracle Designer 6iにファイルをアップロードし、チェックインします。Repository Object

Navigatorで右クリック・メニューから「ファイルとフォルダのアップロード...」を選

択します。アップロード・ダイアログで、「変更されたファイルを上書き」オプショ

ンと「アップロード後チェックイン」オプションにチェックしてアップロードを開始

します。

ファイル Announcement.txtを使用してこのステップを説明します。

69

リポジトリリポジトリリポジトリリポジトリ[CUST_FOLDER]

…

Announcement.txtAnnouncement.txtAnnouncement.txtAnnouncement.txt

doc

ファイル・システムファイル・システムファイル・システムファイル・システム

Announcement11.txtAnnouncement11.txtAnnouncement11.txtAnnouncement11.txt

...\stage\tst\

doc

1.01.01.01.0

1.0CO(1)1.0CO(1)1.0CO(1)1.0CO(1)1.11.11.11.1

コピーコピーコピーコピー

C:C:C:C:\\\\workworkworkwork\\\\announcement.txtannouncement.txtannouncement.txtannouncement.txt

アップロードアップロードアップロードアップロード

チェック・アウトチェック・アウトチェック・アウトチェック・アウト

…

…

アップロードアップロードアップロードアップロード

コピーおよびコピーおよびコピーおよびコピーおよび名称変更名称変更名称変更名称変更

必要なバージョンを構築するまでこのステップを繰り返します。たとえば、ファイル

Announcement.txtは 3つのバージョン（1.0、1.1および 1.2）があるので、このアクティビテ

ィを 2回繰り返す必要があります。


多くのファイル・バージョンを備えた数多くのファイルを所有している場合、この方法は

時間がかかります。したがって、使用されていないバージョンのファイルのアップロード

は省くことを検討した方がいいかもしれません。たとえば、Announcement.txtバージョン 1.1

がどこにも使用されておらず、Announcement.txtのバージョン 1.0およびバージョン 1.2は

使用されている場合、Announcement.txtのバージョン 1.2をチェックインするアクティビテ

ィのみでよいことになります。

移行されたファイルの検証移行されたファイルの検証移行されたファイルの検証移行されたファイルの検証

ファイルの移行にかかる労力を次の角度から検証できます。

適切な数の追加バージョン（バージョン・ツリー）の存在

適切な数の追加バージョン（バージョン・ツリー）の存在適切な数の追加バージョン（バージョン・ツリー）の存在適切な数の追加バージョン（バージョン・ツリー）の存在適切な数の追加バージョン（バージョン・ツリー）の存在

ファイル・バージョンの正確な数は、ファイルのバージョン・ツリー構築に使用した移行

計画によって、ファイル・バージョンのオリジナルの数と異なる場合があります。

自動バージョン・ラベル付けポリシーを選択していて、いくつかのファイル・バージョン

の移行をスキップした場合、バージョン・ナンバー自体もファイル・バージョン・ナンバ

ーと異なる場合があることに注意してください。

バージョン・ツリーを表示するために、Version History Viewer（次を参照）を使用します。

Version History Viewerを起動するには、Repository Object Navigatorで、オブジェクトを選択

し右クリックメニューから「バージョン履歴の表示...」を選択するか、もしくはツールバー

の VHVボタンをクリックします。ここでは、「ファイルに対するバージョン・ツリー

の構築」の項で例に揚げた Announcement.txtの Version History Viewerを示します。

71


リポジトリ・データがファイル・オブジェクト（および追加ファイル・バージョン）によ

り拡張されたため、ここで「統計情報の算出」の再実行を検討してください。「統計情報

の算出」を実行することで、リポジトリのパフォーマンスが低下することが防げます。




73

第第第第 5章章章章移行後の移行後の移行後の移行後の Oracle Designer 6iリポジトリポジトリポジトリポジトリの再編成リの再編成リの再編成リの再編成

構造化要素またはファイルの移行に続いて、リポジトリの再編成を行うことができます。

次の事項について詳しく説明します。

ワークエリアおよびコンフィグレーションの定義

廃止要素の削除

統計の計算

バージョン管理をまだ使用していない場合、可能な再編成オプションは限定されます。た

とえば、デフォルトの GLOBAL_SHARED_WORKAREAの他にワークエリアを追加作成で

きません。また、チェックインを利用しないため、コンフィグレーションを作成できませ

ん（コンフィグレーションのメンバーとなりうるオブジェクトは、チェックインされてい

なければなりません）。つまり、バージョン管理をまだ使用していない場合に考慮すべき

再編成の作業は、第 3章で説明したコンテナの階層化の作業だけになります。

ワークエリアワークエリアワークエリアワークエリアおよびコンフィグレーションの定義およびコンフィグレーションの定義およびコンフィグレーションの定義およびコンフィグレーションの定義

開発工程では、いくつかの重要なフェーズがあります（たとえば、部分テスト、統合テス

ト、本番稼動などのタイミングです）。これらのフェーズで使用された環境は、再現する

ことが必要になる場合があります。構造化要素やファイルは、それぞれに異なるバージョ

ン履歴を持ちますが、環境を再現するためには、各フェーズに使用されたバージョンによ

る正確な組み合わせを作り上げなければなりません。これらのためにコンフィグレーショ

ンを定義します。

この項では、以下のように進行したシステム開発をモデルとして話を進めます。

開発 ───────────────────→ （開発中...）

└→ システム・テスト

└→ システム統合

└→ 本番稼動

└→ バグ修正 ─→ （修正中...）


各フェーズそれぞれに対応したワークエリアを構成しておくことによって、正確なシステ

ム環境をすぐに再現できるようになります。これらのワークエリアは、以下の 2つに分類

できます。

開発ワークエリア

開発進行中のワークエリアです。前述の例では「開発」および「バグ修正」が該当し

ます。このタイプのワークエリア内のオブジェクトは常にバージョンが更新される可

能性があります。例でもわかるように、これらは、それぞれの開発ライン上で並行開

発されている状態にあります。また、プロジェクトによっては、いくつかのサブシス

テムごとの開発ワークエリアとして分割されている場合があります。

言い換えると、このタイプのワークエリアには、それぞれのブランチ･ライン上（さら

にプロジェクトが分割されている場合は、そのサブシステムに対応したコンテナ）で、

現在開発中のオブジェクト（つまり、最新のバージョン）が含まれていることになり

ます。

非開発ワークエリア

環境再現のためのワークエリアです。確定されたバージョンのセットで構成され、変

更されることはありません（あるとしても、それらに”パッチ”セットを適用する程度

です）。前述の例では「システム・テスト」、「システム統合」および「本番稼動」

が該当します。

言い換えると、このタイプのワークエリアは、確定されたバージョンのセットや適用

される”パッチ”セットを表現するコンフィグレーション内のオブジェクトで構成され

ていることになります。

上記のことをワークエリア規則で表現すると次のようになります。

タイプタイプタイプタイプ適用すべき適用すべき適用すべき適用すべきワワワワークエリアの構成規則ークエリアの構成規則ークエリアの構成規則ークエリアの構成規則

規則の意味規則の意味規則の意味規則の意味

LATEST

または

指定されたブランチ･ライン上のすべ

てのオブジェクトの最新バージョン

開発

ワークエリア

FOLDER_LATEST_CONTENTS 指定されたコンテナに含まれるすべ

てのオブジェクトの最新バージョン

非開発

ワークエリア

INCLUDE_CONFIG 指定されたコンフィグレーションを

構成するオブジェクトのセット

75

このことから、非開発ワークエリアを構成するためには、まず、コンフィグレーションを

定義しておくほうがよいといえます。前述の説明にもあるように、非開発ワークエリアの

ベースとなるコンフィグレーションには 2種類あります。

すべてのオブジェクトの特定のバージョンによる完全なセットで構成されるコンフィ

グレーション。これをペースライン・コンフィグレーションと呼びます。

いくつかのオブジェクトの修正されたバージョンだけで構成されるコンフィグレーシ

ョン。これをパッチ・コンフィグレーションと呼びます。

コンフィグレーションは、コンフィグレーション・ウィザードを使って作成することがで

きます。

コンフィグレーションを構成するオブジェクトおよびそのバージョンを選択する際に、一

つ一つのオブジェクトを指定する方法をとることもできますが、ワークエリアと似たよう

な規則を使うこともできます。たとえば、あるコンテナに含まれるオブジェクトの最新バ

ージョンで構成したい場合には、FOLDER_LATEST_CONTENTSの規則を使用することがで

きます。ただし、ワークエリアと異なり、この規則に対する評価が行われるタイミングは

コンフィグレーションの作成時点だけです（コンフィグレーションの作成時点で、あるオ

ブジェクトの最新バージョンが 1.5だった場合、そのバージョンがコンフィグレーションの

構成メンバーになります。以後、そのオブジェクトのバージョンが更新されても、コンフ

ィグレーションのメンバーが 1.5から変更されることはありません。一方、ワークエリアで

は、リフレッシュのたびに規則が評価されますので、含まれるオブジェクトのバージョン


は変動する可能性があります）。また、現行の開発ワークエリアをベースとしてコンフィ

グレーションを作成することもできます。

ベース・コンフィグレーションにはすべてのオブジェクトが含まれる必要があるため、作

成する際には規則を用いるか、開発ワークエリアをベースとする方がよいといえます。パ

ッチ・コンフィグレーションは、含まれるオブジェクトが限定されますので、オブジェク

トごとに指定する作成方法をとることができます。

このようにして定義されたコンフィグレーションに基づいて、非開発ワークエリアを作成

できます。

ワークエリアの作成において、適用する規則の指定順序は、とても重要です。ワークエリ

ア規則は最上位から最下位に向けて評価されます。上位にあるワークエリア規則によりオ

ブジェクト・バージョンがすでに移入されている場合は、別のオブジェクト・バージョン

は評価されません。

たとえば、非開発ワークエリアの場合、実際の環境におけるパッチ適用の順番と同じよう

に規則を並べる必要があります。本番環境で、ベースのオブジェクト･セットに、最初にパ

ッチ 1、次にパッチ 2を適用しているような場合、それに対応した非開発ワークエリアを作

成するためには、

INCLUDE_CONFIG(＜パッチ 2に対応したパッチ・コンフィグレーション＞)

INCLUDE_CONFIG(＜パッチ 1に対応したパッチ・コンフィグレーション＞)

INCLUDE_CONFIG(＜ベース・コンフィグレーション＞)

という順番で規則を並べることが必要になります。

77

開発ワークエリアは LATESTや FOLDER_LATEST_CONTENTSといった規則に基づき、動的

な特性を備えています。オブジェクトがチェックインされると、開発ワークエリアに含ま

れるオブジェクトのバージョンは変更されます。一方、非開発ワークエリアの構成が変更

されるのは、コンフィグレーションの追加（新しいパッチの適用）やワークエリア定義の

変更（不要になったコンテナの削除など）のときのみです。

システムが稼動している限り、コンフィグレーションの数は増加していく可能性がありま

す。したがって、コンフィグレーションに対して命名規則を用意し、名前だけでそのコン

フィグレーションの意味を識別できるようにした方がよいでしょう。命名規則の例として、

＜システム名＞_＜ベースライン・リリース番号＞_（＜パッチ・リリース＞）などがあげら

れます。これを用いると、たとえば、顧客管理システムのバージョン 5.05に対するパッチ

12を意味するコンフィグレーションは、顧客管理システムを識別する名前「CUSTOMER」

を使って、CUSTOMER_505_12のように表現されます。

開発ワークエリアに対する各開発者ごと開発ワークエリアに対する各開発者ごと開発ワークエリアに対する各開発者ごと開発ワークエリアに対する各開発者ごとの異なるフォルダのマッピングの異なるフォルダのマッピングの異なるフォルダのマッピングの異なるフォルダのマッピング

バージョン管理をまだ使用していない場合は、この項は省いてかまいません。

開発者は、開発ワークエリア内のコンテナに定義されているファイルに対して、開発を進

めるためにフォルダ・マッピングを実行するでしょう。この場合に、開発者は、各コンテ

ナに対してそれぞれが専有する（ファイル・システム上の）作業空間をマップすることに

よって、互いを干渉することのない開発が可能になります。

Oracle Designer 6iのフォルダ・マッピングは、ワークエリア、コンテナおよび PCごとに一

意に定義できるため、たとえば、同じワークエリア内の同じコンテナに対して、異なる PC

のフォルダをマッピングできます。

廃止されたコンテナおよびオブジェクトの削除廃止されたコンテナおよびオブジェクトの削除廃止されたコンテナおよびオブジェクトの削除廃止されたコンテナおよびオブジェクトの削除

バージョン管理をまだ使用していない場合は、このアクティビティは省いてかまいません。

これまでのタスクで、次のような廃止の候補となるようなオブジェクトが存在している可

能性があります。

オブジェクト・バージョンの追加のために用意されたアプリケーション・システム

（CUSTOMER（2）、CUSTOMER（3）など）

移行プロセスのために作成されたワークエリア（WA_des60_dsなど）


第 3章で説明した構造化要素のバージョン・ツリーの構築が完了していれば、このときに

一時的に作成した追加アプリケーション・システムは、もはや必要ありません。

アプリケーション・システムの削除はマウスの右クリック・メニューから実行可能です。

しかし、効果的にアプリケーション・システムを削除するためには、削除する順番を考慮

する必要があります。たとえば、アプリケーション・システム内に他のオブジェクトから

の参照元となっているようなオブジェクトが含まれる場合、参照先のオブジェクトよりも

先に削除することはできません。

初期段階で作成したワークエリアは、前述の開発ワークエリアおよび非開発ワークエリア

を作成することによって必要なくなります。また、移行プロセスのために作成されたワー

クエリアも削除できます。ただし、ワークエリアを正しく削除するには、すべてのオブジ

ェクトがチェックインされているか、または削除されている必要があります。

Oracle Designer 6iリポジトリでは、ごみ箱の概念が提供されています。つまり、削除された

オブジェクトは、すぐには消えずにごみ箱内に移動されます（したがって、あやまって削

除してしまった場合でも元に戻すことができます）。リポジトリからオブジェクトを完全

に削除するためには、ごみ箱を空にします。


リポジトリ・データが再編成（およびクリーン・アップ）されたので、「統計情報の算出」

を行ってください。「統計情報の算出」を実行することで、リポジトリのパフォーマンス

の低下を避けられます。



79

第第第第 6章章章章ユーユーユーユーザーの移行およびアクセス権限の割当てザーの移行およびアクセス権限の割当てザーの移行およびアクセス権限の割当てザーの移行およびアクセス権限の割当て

この段階で Oracle Designer 6iリポジトリには、異なるワークエリア、コンテナとサブコン

テナ、コンフィグレーション、および構造化要素とファイルが含まれています。しかし、

従属ユーザーはまだこれらのオブジェクトにアクセスすることはできません。この項では、

従属ユーザーの作成、およびこれらのオブジェクトへの適切なアクセス権の配分について

のガイドラインを説明します。

ワークエリア、コンテナ、コンフィグレーションという概念は、Oracle Designer 6iの新しい

概念です。さらに、従属リポジトリ・ユーザーへの新しいシステム・リポジトリ・アクセ

ス権が提供されています。従属ユーザーは Repository Administration Utilityでメンテナンス

されます。

次の事項について説明します。

ユーザー・グループの分類

Oracle Designer 6iリポジトリ・システム・アクセス権の説明

一般的なアクセス権の説明

リポジトリ、ワークエリア、コンテナおよびコンフィグレーション別の各ユーザー・

グループごとのアクセス権

システム・リポジトリ・アクセス権、GLOBAL_SHARED_WORKAREAへの特定のアクセス

権、コンテナ・アクセス権は、バージョン管理しない場合でも有効です。コンフィグレー

ション・アクセス権は、バージョン管理でのみ意義があります。

ユーザー・グループの分類ユーザー・グループの分類ユーザー・グループの分類ユーザー・グループの分類

プロジェクトにおいて、それぞれ異なる役割を持ついくつかのユーザー・グループを考え

る必要があります（もちろん、プロジェクトによっては必要のないものもあります）。こ

の項では、それについて取り上げます。1ユーザーを 1つ以上のユーザー・グループに関連

付けることができます。

QA構成マネージャ［構成マネージャ［構成マネージャ［構成マネージャ［QACM］］］］

QA構成マネージャは職務として、構成管理に関する処理、標準化規定やガイドラインのメ

ンテナンスおよび配布、Oracle Designer 6iへの移行シナリオの作成を行います。この QA構


成マネージャは、IT組織に構成管理タスク配分についてアドバイスを行い、構成管理およ

びツール・セットの技術知識を提供する責任があります。

リポジトリ・マネージャ［リポジトリ・マネージャ［リポジトリ・マネージャ［リポジトリ・マネージャ［RM］］］］

リポジトリ・マネージャは職務として、Oracle Designer 6iリポジトリ内でユーザーの設定お

よび削除、続いて各ユーザーへのシステム・リポジトリ・アクセス権の付与を行います。

前述した各開発工程モデルを再現する場合は、その開発ワークエリアおよび非開発ワーク

エリアも作成する必要があります。

開発者［開発者［開発者［開発者［DVR］］］］

開発者は職務として、構造化要素とファイルの開発およびメンテナンス、またこれらのオ

ブジェクトの（サブ）フォルダでのグループ化を行います。したがって、開発者は前述の

オブジェクトのチェックインおよびチェックアウトができる必要があります。

プロジェクト構成マネージャ［プロジェクト構成マネージャ［プロジェクト構成マネージャ［プロジェクト構成マネージャ［PCM］］］］

プロジェクト構成マネージャは、特に、本番環境用のワークエリアから実際にアプリケー

ションを移行する計画に密接に関係します。プロジェクト構成マネージャは、必要な準備

アクティビティすべての責任を担います。

このため、プロジェクト構成マネージャはワークエリア規則の設定、およびワークエリア

のリフレッシュ、（ルート）コンテナのメンテナンス、コンフィグレーション（ベースラ

インおよびパッチ）の定義と移入、およびワークエリア、コンフィグレーションおよびコ

ンテナに対するアクセス権の設定を実行できる必要があります。

サポート・オペレータ［サポート・オペレータ［サポート・オペレータ［サポート・オペレータ［SO］］］］

サポート・オペレータ・アプリケーション・マネージャの職務として、本番環境でのアプ

リケーション可用性を最大化する責任があります。その職務において、本番変更に十分に

対応するため、テスト環境に対しても責任があります。このサポート・オペレータ・アプ

リケーション・マネージャは、本番環境（およびテスト）用の Oracle Designer 6iリポジト

リに対し、データベースおよびファイル・システムにおける同期化および検証アクティビ

ティを行います。

81

データベース管理者［データベース管理者［データベース管理者［データベース管理者［DBA］］］］

DBAは職務として、アプリケーション・システムの開発および配布をサポートするデータ

ベースのインストール、構成およびメンテナンスを行います。DBAは、最大限データベー

スを活用できるように、データベース・スキーマへの適切なデータベース・システム権限

が付与されたアクセスを提供します。また、DBAはバックアップおよびリカバリ処理に責

任を持ち、十分なデータベース・パフォーマンスのメンテナンスを行います。したがって、

Oracle Designer 6iリポジトリで、DBAはデータベース・ユーザーの作成、適切なデータベ

ース・アクセス権の割当て、データベース・ユーザーの削除、Oracle Designer 6iリポジトリ

の調整（統計の計算など）を行います。

システム・リポジトリ・アクセス権システム・リポジトリ・アクセス権システム・リポジトリ・アクセス権システム・リポジトリ・アクセス権

システム・リポジトリ・アクセス権は大幅に変更されました。特定のユーザーごとに、次

のシステム・リポジトリ・アクセス権を定義できます。

略称略称略称略称 Oracle Designer 6iのシステム割当てのシステム割当てのシステム割当てのシステム割当て

管理権限管理権限管理権限管理権限

WA ワークエリアの管理

CFG コンフィグレーションの管理

CTR コンテナ（フォルダまたはアプリケーション・システム）の管理

USR ユーザーの管理

BRL ブランチ・ラベルの管理

DPD 依存性の管理

実行権限実行権限実行権限実行権限

SPY リポジトリ・ポリシー設定

FRC 強制削除

PRG 除去

GPR グローバル除去


接続権限接続権限接続権限接続権限

RON Repository Object Navigatorによる接続の許可

RAU Repository Administration Utilityによる接続の許可

MTX Matrix Diagrammerによる接続の許可

RPTL Repository Reportsによる接続の許可

CLI Command Line Toolによる接続の許可

VHV Version History Viewerによる接続の許可

VEV Version Event Viewerによる接続の許可

ただし、以下にあげるアクセス権は、バージョン管理を利用している環境でのみ適用でき

ます。

管理権限：ワークエリア、ブランチ・ラベル、コンフィグレーション

実行権限：ポリシーの設定、除去、グローバル除去

接続権限：Version History Viewer、Version Event Viewer

一般的な要素に対するアクセス権一般的な要素に対するアクセス権一般的な要素に対するアクセス権一般的な要素に対するアクセス権

次のアクセス権をワークエリア、コンテナおよびコンフィグレーションに設定できます。

しかし、すべてのアクセス権がこれらの各（管理）要素に適用されるわけではありません。

たとえば、「コンパイル」および「仕様の更新」は、ワークエリアに対してのみ適用でき

ます。

83

アクセス権アクセス権アクセス権アクセス権内容内容内容内容

選択要素の選択

管理他のユーザーのアクセス権の決定

挿入要素の挿入

更新要素およびオブジェクト・プロパティの更新

削除要素の削除

バージョン要素のバージョン管理

コンパイルワークエリアのリフレッシュ（ワークエリア規則の再評価）

仕様の更新ワークエリア規則の変更

ユーザー・グループごとのアクユーザー・グループごとのアクユーザー・グループごとのアクユーザー・グループごとのアクセス権セス権セス権セス権

Oracle Designer 6iリポジトリに対するアクセス権およびワークエリア、コンテナおよびコン

フィグレーションに対するアクセス権を定義する際には、次のガイドラインが適用されま

す。このガイドラインは、ユーザー・グループの分類および一般的な要素に対するアクセ

ス権限に基づいています。


ユーザーユーザーユーザーユーザーグループグループグループグループ

リポジトリリポジトリリポジトリリポジトリシステムシステムシステムシステムアクセスアクセスアクセスアクセス

ワークエリアワークエリアワークエリアワークエリアアクセスアクセスアクセスアクセス

コンテナコンテナコンテナコンテナアクセスアクセスアクセスアクセス

コンフィグコンフィグコンフィグコンフィグレーションレーションレーションレーションアクセスアクセスアクセスアクセス

QA構成

マネージャ

RON、MTX、RPTL、

VHV、VEV

選択選択選択

リポジトリ・

マネージャ

WA、USR、SPY、

RON、RAU、CLI

選択、挿入、削除

選択選択

開発者 BRL、DPD、FRC、

RON、MTX、RPTL、

CLI、VHV、VEV

選択、挿入、更新、削除、バージョン、コンパイル

選択、挿入、更新、削除、バージョン

選択

プロジェクト

構成

マネージャ

WA、CFG、CTR、

BRL、DPD、FRC、

PRG、GPR、RON、

MTX、RPTL、CLI、

VHV、VEV

選択、管理、挿入、更新、削除、バージョン、コンパイル、仕様の更新

選択、管理、挿入、更新、削除、バージョン

選択、管理、挿入、更新、削除、バージョン

サポート・

オペレータ

RON、MTX、RPTL、

VHV、VEV

選択、管理、コンパイル、仕様の更新

選択選択

データベース

管理者

RON、RAU 選択選択選択

複数のワークエリア、コンテナおよびコンフィグレーションに対して、アクセス権を同時

に定義することができます。権限を定義したいワークエリア、コンテナ、コンフィグレー

ション等を複数選択し、右クリック・メニューから「アクセス権の付与...」を選択します。

次に示す「アクセス権の付与」ダイアログ上でアクセス権の定義を行います。

85

上図のように、1人以上のユーザーに同時にアクセス権を定義することも出来ます。

アクセス権は、各ルート・コンテナおよびそのサブコンテナごとに設定する必要があることに注意してください。コンテナへのアクセス権の付与には、「サブコンテナを繰り返す」

オプションが用意されてあり、すべてのサブコンテナに同一のアクセス権の設定を行うこ

とができます。

特定のオブジェクトへの最終的なアクセス権（エンティティ、表またはモジュールの挿入、

選択、削除または更新など）は、ワークエリアおよびワークエリア内のコンテナに対する

アクセス権限の両方を評価して決定されます。たとえば Oracle Designer 6iリポジトリ・ユ

ーザーに、WA_DEVワークエリアに対して選択、挿入、更新、削除およびバージョン権限、

WA_DEVワークエリア内のコンテナ CUSTOMERに対して選択権限が付与されている場合、

最終的には（ワークエリアに対し拡張された権限を付与されていても）リポジトリ・ユー

ザーはコンテナ CUSTOMER内のすべてのオブジェクトに対して選択することしかできま

せん。


87

第第第第 7章章章章リポジトリリポジトリリポジトリリポジトリ APIスクリプトの移行スクリプトの移行スクリプトの移行スクリプトの移行

旧リリースのリポジトリに対して、Oracle Designerツール・セットからではなく、リポジト

リ APIを利用したスクリプトでのアクセスを実施していた場合、そのスクリプトの修正を

行う必要があります。

この章では、リポジトリ APIの概要と移行に関する情報を説明します。

概要

リポジトリ APIの変更点

また、Appendixとして、いくつかのスクリプトの移行例を紹介しています。そちらも参照

ください。

リポジトリリポジトリリポジトリリポジトリ APIの概要の概要の概要の概要

Oracle Designerリポジトリおよび Oracle Repositoryには、外部からの汎用的なアクセスを実

現するためのインターフェースが用意されています。これはリポジトリ APIと呼ばれてい

ます。

リポジトリ APIには、大きく以下の 2つに分類されます。

リポジトリ・ビュー

リポジトリ APIパッケージ

以下では、これらの役割について説明しています。

リポジトリ・ビューの概要リポジトリ・ビューの概要リポジトリ・ビューの概要リポジトリ・ビューの概要

リポジトリ・ビューは、リポジトリに定義された構造化要素を SQLクライアントから簡単

に検索できるように用意されたビューです。これを利用することによって、各構造化要素

のプロパティに対する高度な条件検索が可能になります。リポジトリ・ビューは、通常

ci_＜構造化要素の複数名＞

のネーミング・ルールで用意されています。たとえば、表定義に対して ci_table_definitions、

列定義に対して ci_columnsといったビューが用意されています。また、構造化要素のプロ

パティがそのまま列として用意されています。


SQL*Plusによる descの実行例

SQL> desc ci_table_definitions

名前 NULL? 型

--------------------------- -------- ---- ALIAS VARCHAR2(10) CHANGED_BY VARCHAR2(30) CLUSTER_REFERENCE NUMBER(38) COLUMN_PREFIX VARCHAR2(4) : DISPLAY_TITLE VARCHAR2(132) ELEMENT_TYPE_NAME NOT NULL VARCHAR2(10) ID NOT NULL NUMBER INDEX_ONLY_FLAG VARCHAR2(1) INITIAL_NUMBER_OF_ROWS NUMBER(38) : JOURNAL_LOCATION VARCHAR2(14) MAXIMUM_NUMBER_OF_ROWS NUMBER(38) NAME NOT NULL VARCHAR2(30) NUMBER_OF_TIMES_MODIFIED NOT NULL NUMBER(38) ORACLE_OBJECT_TYPE_REFERENCE NUMBER(38) REMARK VARCHAR2(2000) :

Repository Object Navigatorでのプロパティ表示との比較

ci_table_definitionsの対応する列名

- NAME - ALIAS - COLUMN_PREFIX - DISPLAY_TITLE - JOURNAL_LOCATION - ORACLE_OBJECT_TYPE_REFERENCE - INITIAL_NUMBER_OF_ROWS - MAXIMUM_NUMBER_OF_ROWS

- INDEX_ONLY_FLAG

89

リポジトリ・ビューによる検索例リポジトリ・ビューによる検索例リポジトリ・ビューによる検索例リポジトリ・ビューによる検索例

SQL*Plusからリポジトリへリポジトリ・ユーザーとして接続した場合、以下のような SQL

を実行することで、そのユーザーがアクセス可能なアプリケーション・システム名が一覧

されます。

SELECT a.NAME FROM ci_application_systems;

このリポジトリ・ビューに対するアクセスは検索のみが許されます。リポジトリに対する

データの挿入/更新/削除は、次で説明するリポジトリ APIパッケージを利用しなければなり

ません。

リポジトリリポジトリリポジトリリポジトリ APIパッケージの概要パッケージの概要パッケージの概要パッケージの概要

リポジトリ APIパッケージは、リポジトリにデータを登録（挿入/更新/削除）するために用

意された PL/SQLパッケージです。

リポジトリ APIパッケージは、通常

cio＜構造化要素名＞

のネーミング・ルールで用意されています。たとえば、表定義に対して ciotable_definition、

列定義に対して ciocolumnといったビューが用意されています。

CIO＜構造化要素名＞パッケージの基本構成は次のとおりです。

仕様仕様仕様仕様目的目的目的目的

構造化データ

DATA

対応するリポジトリ・ビューの列に対応したデータを持つ構造体。 DATA.v.＜ビューの列名＞：列と同じデータ型

DATA.i.＜ビューの列名＞：フラグ（true or false）

プロシージャ

SEL(number,data)

numberで指定された IDの構造化要素のプロパティ値を dataへ

移入する。

プロシージャ

INS(number,data)

numberで指定された IDの構造化要素として、dataで指定した

プロパティ値を挿入する。

プロシージャ

UPD(number,data)

numberで指定された IDの構造化要素へ、dataで指定したプロ

パティ値で更新する。

プロシージャ

DEL(number)

numberで指定された IDの構造化要素を削除する。


リポジトリリポジトリリポジトリリポジトリ APIパッケージによるデータの登録例パッケージによるデータの登録例パッケージによるデータの登録例パッケージによるデータの登録例

SQL*Plusからリポジトリへリポジトリ・ユーザーとして接続した場合、「Appendix A」で

示しているスクリプトの基本型の網掛け部分に以下のような SQLを埋め込むことで完成す

るスクリプトを実行すると、アプリケーション・システム APPSYSにエンティティ ENT0

を新規作成できます。

-- アプリケーション・システムの指定

cdapi.set_context_appsys('APPSYS'); DECLARE -- エンティティに対するデータを宣言

entdata cioentity.data; BEGIN entdata.v.NAME := 'ENT0'; -- エンティティ名を設定

wntdata.i.NAME := true; -- このデータを処理対象にする

-- trueに指定されたデータを使って新規エンティティを登録

-- ID値に nullを指定しておくと、自動的に値が導出される

cioentity.ins( null, entdata ); END;

移行に伴うリポジトリ移行に伴うリポジトリ移行に伴うリポジトリ移行に伴うリポジトリ APIの変更点の変更点の変更点の変更点

Oracle Designer 6iでの機能拡張（バージョン管理など）に伴い、既存のリポジトリ APIスク

リプトには、以下の 4点に注意した変更を行う必要があります。

1. ワークエリアの指定

バージョン管理機能の拡張によって、Oracle Repositoryへのすべてのアクセスはワーク

エリアを通して行われるようになりました。したがって、既存のリポジトリ APIスク

リプトに、最初にワークエリアを指定するコードを追加しなくてはなりません。これ

を行うために、以下のプロシージャを実行します。

-- ワークエリアの指定

-- ワークエリア名は大文字/小文字は区別されます

jr_context.set_workarea( 'WA_TEST' );

91

2. コンテナの指定に関する条件部分の書き換え（リポジトリ・ビューに対する SQL検索

を行っている場合）

旧リリースでのリポジトリ・ビューの構成

旧リリースのリポジトリでは、アプリケーション・システムを表すビュー

（ci_application_systems）と、そこに含まれる構造化要素を表すビューとの間は単

純なリレーションで結合可能でした。

ci_application_systems APP

# id* name...

ci_table_definitions TAB

# id* name* application_systems_owned_by...

ci_columns COL

# id* name* table_reference...

TAB.application_systems_owned_by = APP.id

COL.table_reference = TAB.id

Oracle Designer 6iのリポジトリ・ビューの構成

バージョン管理機能の拡張によって、アプリケーション・システムを表すビュー

（ci_application_systems）と構造化要素のビューとの間に、バージョン履歴情報を

管理する中間テーブル（ci_folder_members）が追加されています。

ci_folder_members FM

* folder_reference* member_object...

ci_table_definitions TAB

# id* irid* ivid* name...

ci_columns COL

# id* irid* ivid* name* table_reference...

TAB.id = FM.member_object

COL.table_reference = TAB.id

ci_application_systems APP

# id* irid* ivid* name...

FM.folder_reference = APP.id


この変更によって、SQLでの結合条件部分を書き換えることが必要になります。この

変更に関しての詳細は、このマニュアルの Appendix Bを参照してください。

3. アプリケーション・システム名の大文字/小文字の区別

旧リリースではアプリケーション・システム名はすべて大文字で解釈されていました。

これをリポジトリ APIスクリプト内で施行するために、スクリプトによっては UPPER

関数で大文字化している可能性があります。旧リリースから移行されたアプリケーシ

ョン・システムの名前はすべて大文字になりますので、これらに関しては問題ありま

せんが、新しくリリース 6iで作成したアプリケーション・システムに対して同じスク

リプトを実行する場合、この UPPER関数のために検索条件からもれてしまう場合があ

ります。これを避けるために、UPPER関数の記述を除去します。

4. チェックイン･チェックアウトに関するコードの追加（構造化要素の挿入/更新/削除を

行っている場合）

バージョン管理機能の拡張によって、構造化要素の挿入/更新/削除を行う場合は、実際

に処理の前にオブジェクトをチェックアウトしなければなりません。これを行うため

に、以下の SQLコールを実行します。

DECLARE i_irid number; --チェックアウトするオブジェクトの IRIDを格納する変数

dummy number; --チェックアウト用のダミー変数

BEGIN -- チェックアウトしたいオブジェクトの IRIDを取得する

SELECT IRID INTO i_irid FROM ci_＜構造化要素の複数名＞

WHERE ...; -- 対象のオブジェクトがチェックインされている場合のみチェックアウトを実行

if jr_version.is_checked_in( i_irid, null ) then dummy := jr_version.check_out( i_irid, null, false ); -- チェックアウト時にロックをかけたい場合は最後を trueにする

end if; : END;

チェックアウトは、以下の場合にコールする必要があります。

バージョン管理されているアプリケーション・システムに対して

93

− アプリケーション・システム自身のプロパティを変更する場合

− その中に新規で構造化要素を追加する場合

− その中に含まれる構造化要素を削除する場合

その中に含まれる構造化要素のプロパティ変更だけの場合には、アプリケーション・システムはチェックアウトしなくてもかまいません。

バージョン管理されている構造化要素に対して

− その構造化要素のプロパティを更新する場合

− その構造化要素を削除する場合

また、処理が終了したら、必要に応じて、チェックインを実行します（この作業は必

須ではありません）。チェックインに関する記述の詳細は、製品付属の『API and Model

Reference Guide』を参照してください。


95

Appendix A: リポジトリリポジトリリポジトリリポジトリ APIパッケージ・スクリプトの基本パターンパッケージ・スクリプトの基本パターンパッケージ・スクリプトの基本パターンパッケージ・スクリプトの基本パターン

以下に示すスクリプトの基本型は、旧リリースにも、リリース 6iにも利用可能です。実際

に使用する際には、網掛けの部分に必要な処理を追加してください。

DECLARE -- API処理用のプライベート・プロシージャ

-- これは、APIの決められた手続きの後で呼び出される

procedure execute_APIaction is begin

-- この部分で、実際の処理を記述する

-- 1.コンテナ（アプリケーションシステム）の指定

-- 2.処理対象のオブジェクトのデータを宣言

-- 3.データに値を設定

-- 4.選択/挿入/更新/削除に対応したプロシージャをコール

-- 5.必要に応じて、2～4を繰り返し

end; -- エラーメッセージ処理用のプライベート・プロシージャ

procedure instantiate_messages is m_facility VARCHAR2 (3); m_code NUMBER; arg1 VARCHAR2 (240); arg2 VARCHAR2 (64); arg3 VARCHAR2 (64); arg4 VARCHAR2 (64); arg5 VARCHAR2 (20); arg6 VARCHAR2 (20); arg7 VARCHAR2 (20); arg8 VARCHAR2 (20); begin -- すべての警告を表示

for viol in (select * from CI_VIOLATIONS) loop dbms_output.put_line (cdapi.instantiate_message ( viol.facility, viol.code, viol.p0, viol.p1, viol.p2, viol.p3,


viol.p4, viol.p5, viol.p6, viol.p7)); end loop; -- メッセージを単一の文字列にフォーマット

while cdapi.stacksize > 0 loop rmmes.pop ( m_facility, m_code, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8); dbms_output.put_line (cdapi.instantiate_message ( m_facility, m_code, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8)); end loop; end; BEGIN -- APIの初期化

if cdapi.initialized = false then cdapi.initialize(); end if; -- 新しいアクティビティの開始

o ('新しいアクティビティを開きます');

cdapi.open_activity; -- 処理の実行

-- ここで、網掛け部分のコードが呼び出される

execute_APIaction; DECLARE act_status varchar2(1); -- アクティビティの状態

act_warnings varchar2(1); -- アクティビティの警告フラグ

BEGIN -- アクティビティの妥当性をチェック

cdapi.validate_activity(act_status,act_warnings); -- 処理によるメッセージを表示

instantiate_messages; -- アクティビティの終了

cdapi.close_activity(act_status); -- 正しく終了されない場合、ロールバックしておく

if act_status != 'Y' then cdapi.abort_activity; dbms_output.put_line ('制約違反でアクティビティが終了しました');

-- 上記以外の場合は正常終了

97

else dbms_output.put_line ('アクティビティは正常に終了しました');

end if; END; EXCEPTION WHEN OTHERS THEN -- エラーメッセージの処理

if cdapi.stacksize > 0 then -- APIスタック上にメッセージがあればそれを表示

while cdapi.stacksize > 0 loop dbms_output.put_line (cdapi.pop_instantiated_message); end loop; if cdapi.activity is not NULL then cdapi.abort_activity; dbms_output.put_line ('APIエラー:アクティビティを終了します');

else dbms_output.put_line ('APIエラー:APIセッションを終了します');

end if; -- APIスタック上にメッセージがなければ API以外のエラー

else if cdapi.activity is not NULL then cdapi.abort_activity; dbms_output.put_line ('内部エラー:アクティビティを終了します');

else dbms_output.put_line ('内部エラー:APIセッションを終了します');

end if; raise; end if; END; /


99

Appendix B: リポジトリリポジトリリポジトリリポジトリ APIスクリプトの移行例スクリプトの移行例スクリプトの移行例スクリプトの移行例

リポジトリリポジトリリポジトリリポジトリ･ビューの検索スクリプトの場合･ビューの検索スクリプトの場合･ビューの検索スクリプトの場合･ビューの検索スクリプトの場合

旧リリースの Oracle Designerリポジトリに対する検索スクリプトとその移行例を紹介しま

す。

旧リリースでの検索スクリプト例 - 2種類

移行後のスクリプト

例例例例 1

この例では、指定されたアプリケーション・システム APPSYS内の表定義およびその列の

情報を検索できます。

旧リリースでの検索スクリプト

SELECT t.NAME, c,NAME, c.DATATYPE, c.MAXMUM_LENGTH FROM ci_table_definitions t, ci_columns c, ci_application_systems a WHERE t.ID = c.TABLE_REFERENCE AND t.APPLICATION_SYSTEM_OWNED_BY = a.ID AND a.NAME = upper('APPSYS');


-- ワークエリアの指定ワークエリアの指定ワークエリアの指定ワークエリアの指定

EXECUTE jr_contest.set_workarea( 'WA_TEST' ); SELECT t.NAME, c,NAME, c.DATATYPE, c.MAXMUM_LENGTH FROM ci_table_definitions t, ci_columns c, ci_application_systems a WHERE t.ID = c.TABLE_REFERENCE -- コンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えここからここからここからここから

AND EXIST ( SELECT NULL FROM ci_folder_members fm WHERE fm.MEMBER_OBJECT = t.ID


AND fm.FOLDER_REFERENCE = a.ID ) -- コンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えここまでここまでここまでここまで

AND a.NAME = 'APPSYS'; -- アプリケーション・システムに対するアプリケーション・システムに対するアプリケーション・システムに対するアプリケーション・システムに対する UPPER指定を除去指定を除去指定を除去指定を除去

例例例例 2

次の例では、例 1と同じ検索結果を得られますが、少し異なる結合の方法を取っています。

旧リリースでの検索スクリプト

SELECT t.NAME, c,NAME, c.DATATYPE, c.MAXMUM_LENGTH FROM ci_table_definitions t, ci_columns c WHERE t.ID = c.TABLE_REFERENCE AND t.APPLICATION_SYSTEM_OWNED_BY in ( SELECT a.ID FROM ci_application_systems a WHERE a.NAME = upper('APPSYS') );



EXECUTE jr_contest.set_workarea( 'WA_TEST' ); SELECT t.NAME, c,NAME, c.DATATYPE, c.MAXMUM_LENGTH FROM ci_table_definitions t, ci_columns c WHERE t.ID = c.TABLE_REFERENCE -- コンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えここからここからここからここから

AND EXIST ( SELECT NULL FROM ci_folder_members fm WHERE fm.MEMBER_OBJECT = t.ID AND fm.FOLDER_REFERENCE in -- コンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えここまでここまでここまでここまで

( SELECT a.ID FROM ci_application_systems a WHERE a.NAME = 'APPSYS' ) ); -- アプリケーション・システムに対するアプリケーション・システムに対するアプリケーション・システムに対するアプリケーション・システムに対する UPPER指定を除去指定を除去指定を除去指定を除去

101

リポジトリリポジトリリポジトリリポジトリ APIパッケージパッケージパッケージパッケージ･スクリプトの場合･スクリプトの場合･スクリプトの場合･スクリプトの場合

以下の 2つのスクリプトは、共に「Appendix A」で紹介したスクリプトの基本型の網掛け部

分に適用するスクリプトの例です。このスクリプトでは、指定されたアプリケーション・

システム APPSYS内にエンティティ ENT1を新規作成し、既存の ENT0の短縮名を変更し

ています。

旧リリースでのスクリプト

-- アプリケーションシステムの指定

cdapi.set_context_appsys(upper('APPSYS')); DECLARE ent cioentity.data; -- エンティティのプロパティのデータ

e_id number; -- IDを格納するための変数

BEGIN -- エンティティのデータの設定

ent.v.NAME := 'ENT1'; ent.i.NAME := true; -- エンティティの新規登録

cioentity.ins(null,ent); -- エンティティ・データを更新するためにエンティティの検索を行う

SELECT e.ID INTO e_id FROM ci_entities e WHERE e.NAME = 'ENT0' AND e.APPLICATION_SYSTEM_OWNED_BY in ( SELECT a.ID FROM ci_application_systems a WHERE a.NAME = upper('APPSYS') ); -- エンティティの検索

cioentity.sel(e_id,ent); -- 更新するエンティティのデータの設定

ent.v.SHORT_NAME := 'E0'; ent.i.SHORT_NAME := true; -- エンティティの更新

cioentity.upd(e_id,ent); END;



-- チェックアウトを行うためのプライベート・プロシージャをチェックアウトを行うためのプライベート・プロシージャをチェックアウトを行うためのプライベート・プロシージャをチェックアウトを行うためのプライベート・プロシージャを

-- 宣言するために、宣言するために、宣言するために、宣言するために、DECLARE~BEGIN~ENDで囲むで囲むで囲むで囲む

DECLARE

-- チェックアウトを実行するプライベートプロシージャの追加チェックアウトを実行するプライベートプロシージャの追加チェックアウトを実行するプライベートプロシージャの追加チェックアウトを実行するプライベートプロシージャの追加

procedure checkout( i_irid ) is dummy number; begin if jr_version.is_checked_in( i_irid, null ) then dummy := jr_version.check_out( i_irid, null, false ); end if; end;

BEGIN


jr_context.set_workarea( 'WA_TEST' );

-- アプリケーションシステムの指定

cdapi.set_context_appsys('APPSYS'); -- アプリケーション・システムに対するアプリケーション・システムに対するアプリケーション・システムに対するアプリケーション・システムに対する UPPER指定を除去指定を除去指定を除去指定を除去

-- バージョン管理を使用していて、アプリケーションシスバージョン管理を使用していて、アプリケーションシスバージョン管理を使用していて、アプリケーションシスバージョン管理を使用していて、アプリケーションシステムへのテムへのテムへのテムへの

-- オブジェクトの追加および削除を行いたい場合、オブジェクトの追加および削除を行いたい場合、オブジェクトの追加および削除を行いたい場合、オブジェクトの追加および削除を行いたい場合、

-- アプリケーションシステムをチェックアウトする必要があるアプリケーションシステムをチェックアウトする必要があるアプリケーションシステムをチェックアウトする必要があるアプリケーションシステムをチェックアウトする必要がある

DECLARE i_irid number; BEGIN SELECT a.irid INTO i_irid FROM ci_application_systems a WHERE a.name = 'APPSYS'; checkout( i_irid ); END; -- アプリケーションシステムのチェックアウトアプリケーションシステムのチェックアウトアプリケーションシステムのチェックアウトアプリケーションシステムのチェックアウトここまでここまでここまでここまで

DECLARE ent cioentity.data; -- エンティティのプロパティのデータ

e_id number; -- IDを格納するための変数

BEGIN -- エンティティのデータの設定

103

ent.v.NAME := 'ENT1'; ent.i.NAME := true; -- エンティティの新規登録

cioentity.ins(null,ent); -- エンティティ・データを更新するためにエンティティの検索を行う

SELECT e.IRID INTO e_id FROM ci_entities e WHERE e.NAME = 'ENT0' -- コンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えここからここからここからここから

AND EXISTS ( SELECT NULL FROM ci_folder_members fm WHERE fm.MEMBER_OBJECT = e.ID AND fm.FOLDER_REFERENCE in -- コンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えコンテナ指定に関する条件部分の書き換えここまでここまでここまでここまで

( SELECT a.ID FROM ci_application_systems a WHERE a.NAME = 'APPSYS' )); -- アプリケーション・システムに対するアプリケーション・システムに対するアプリケーション・システムに対するアプリケーション・システムに対する UPPER指定を除去指定を除去指定を除去指定を除去

-- エンティティの検索

cioentity.sel(e_id,ent); -- 更新するエンティティのデータの設定

ent.v.SHORT_NAME := 'E0'; ent.i.SHORT_NAME := true; -- チェックアウトの実行チェックアウトの実行チェックアウトの実行チェックアウトの実行

checkout( e_id ); -- エンティティの更新

cioentity.upd(e_id,ent); END;

END;


Documents

Oracle Designer for Windows移行に関するガイര줰 …otndnld.oracle.co.jp/document/products/itools/designer/6...Oracle Designer 2.1.2 および6.0 からの移行 Oracle Designer