Previous | Table of Contents | Next

Page 368

FIG. 15.9
The Repository
Administration Utility.


Table 15.3 Controlling Specifications Held in the Repository

Commands Description
File, Unload Allows the creation of an ASCII file that stores in a proprietary format the definitions of selected primary access control (PAC) objects, the PAC's secondary access control objects, and stub objects associated with the selected objects.
File, Load Opposite of File, Unload. Enables the loading of information unloaded from another repository or application system.
File, CheckOut/ CheckIn/Lock Set/ UnlockSet Like Load and Unload, CheckOut and CheckIn allow the moving of selected elements between application systems in the same or different repository. CheckOut also locks the objects in the source application system, thereby preventing accidental change to the object while it is checked out. CheckIn unlocks the objects.
Application, Archive Extracts repository application versions to a special set of temporary archive tables.
Application, Export Exports the contents of the temporary archive tables into an operating system file.
Application, Restore Used to load .DMP files into temporary archive tables and then into the repository.
Application, Reset Flushes the temporary archive tables. The application version in the repository is unchanged.

Referential Integrity Using the Repository

Designer/2000 R 1.3.2 provides a script, ckazanal.sql, while R 2.0 has a utility that can be used to check the referential integrity of data held in the repository. The repository analyzer in the

Page 369

RAU (Utilities menu) removes redundant or invalid data, ensuring data integrity. To run the repository analyzer, the repository owner must be granted the Create Table and Create Index privileges.

Execute the following SQL statement to check the state of the repository. If no rows are returned, the repository is referentially correct:

SQL> select count (*)
           from ckaz_actions
           where check_no is not null
           group by check_no, elmt_type, refd_elmt_type, action;

To use the cost-based optimizer, compute the statistics for the repository table by using

SQL> analyze table <repository table> compute statistics;

The Oracle server can then use the most efficient path by using the statistics for SQL statements that access the analyzed objects.

Version and Change Control

A user with Admin access to the application and Manager type can create a new version of an application. To create a new version of an application, connect to DES2K and select Repository Administration Utility, Application, New Version.

This will result in two versions: one that is frozen and cannot be modified but can be viewed and one that can be modified.

If an application system shares elements with other application systems, a stub application will be created for the other application.

For example, if you have two application systems—Inventory (INV) and Items (ITM)—that share objects and if you create a new version of the inventory, a stub application of ITM (01ITM) will be created. Version 1 of INV will be compatible with 01ITM and version 2 of INV will be compatible with ITM. 01ITM is frozen.

To drop a version of an application, you must make sure that its elements are not used by other applications. If there are used elements, you can do one of the following to drop the application:

Things to consider are the following:

Page 370

Migrating Applications

The following sections describe methods that can be used to move your software design between applications.

Export/Import of Complete RepositoryThis method involves moving the entire repository from the source to the destination database. Unit of migration is the Oracle account. The needed packages must be created at the destination database.

Complete the following steps:

  1. Using the RAU, choose Export Repository User from the backup group.
  2. Transfer the export file in binary mode to the destination machine.
  3. Create an Oracle user (refer to the installation guide for details).
  4. Using the RAU utility, import the user into the destination database.
  5. Create the packages in the destination database.
  6. Re-create the synonyms.

This method is not recommended when you:

Unload/Load an Application SystemThis method involves moving one or more application systems between repositories. Unit of migration is the application system. It is generally used to move applications between the same versions of DES2K.

Complete the following steps:

  1. Access RON as a user with Manager ranking and Admin privileges to the application.
  2. Clear the extract tables by using Application, Reset.
  3. Load the application into the extract tables by using Application, Archive.
  4. Export the extract tables to a *.DMP file by using Application, Export.
  5. Transfer the export file in binary to the destination machine.

Page 371

  1. At the destination database, load the *.DMP file into the extract table by using Application, Import.
  2. Load the extract table into the base table by using Application, Restore.

This method is not recommended when you want to:

Moving Primary Access Controlled (PAC) Elements

Two methods are commonly used to control the movement of PAC elements between CASE repositories: unload/load and check-out/check-in.

Unload/Load ProcessThis method is designed for fast transfer without many restrictions. The elements are unloaded into an ASCII file with extension .DAT. It also unloads secondary access controlled (SAC) elements while preserving association between elements. If one element in the association is not part of the unloaded set, it creates a skeleton with the name of the element to complete the association. The elements are then loaded from the .DAT file into an application system.

Two modes of loading are used for conflict resolution:

Check-Out/Check-In ProcessA user-defined set (UDS) is a non-shareable PAC element and it has associations with other PAC elements in the application system. An element can be associated with more than one UDS. A UDS can be locked and unlocked as desired. Operations that can be performed on a locked UDS are copying the element, sharing the element, or updating associations between the element and unlocked elements. Operations that cannot be performed on a locked UDS are transferring ownership of the element, updating the element's properties, or locking another UDS that contains this element.

The process of check-out and check-in is performed on a UDS. When checked out, a UDS is automatically locked in the source application system and automatically unlocked on check-in. An .RCO file is created if a UDS is checked out of a source application system, while an .RCI file is created if a UDS is checked out of a working application system. These two file formats contain the UDS and its associations.

Table 15.4 compares and contrasts different scenarios where load/unload can be used instead of check-out/check-in:

Previous | Table of Contents | Next