Previous | Table of Contents | Next
Page 372
Table 15.4Scenarios for Using Unload/Load Versus Check-Out/Check-In
Scenario
|
Unload/Load
|
Check-Out/Check-In
|
Single-user
environment
|
Yes. You don't need to
track elements that have
been unloaded from an
application system.
|
No.
|
Multiuser
environment
|
No.
|
Yes. You need to keep track of
migrated elements. Check-out
elements will be locked, prevent-
ing accidental updates.
|
Building application
system from elements
in other application
systems
|
Yes. It is simpler and
the process is done
only once, so you don't
need to define a UDS.
|
No.
|
Backing up of
an element
|
Yes. It is simpler.
|
No. You don't need to define a
UDS or back up the entire
application system.
|
Require tight control
over elements
|
No. It is very flexible.
|
Yes. Tight control can be achieved
over checked out elements.
|
Distributed
development
|
No.
|
Yes.
|
Source control
required
|
No.
|
Yes. Elements checked out from
the source application system are
locked against updates.
|
Designer/2000 allows a variety of output methods and provides the ability to capture the
output from the different diagrammers into destinations such as word processors and
HTML-based tools such as Netscape and Mosaic.
Loading Diagrams into Microsoft Word 6.0This task
can be achieved by using three different methods: Object Linking and Embedding (OLE), screen capture, and print file.
These methods are described in greater detail in the following list.
- Using Object Linking and Embedding
(OLE). Designer/2000 is V2.0 OLE compliant and can serve as both an OLE container and an OLE server. To load an ERD into
Word, complete the following steps:
- Start MS Word and open a new document.
- Choose Insert, Object from the menu and select Entity Relationship Diagrammer.
Page 373
To load a Word document into an ERD, complete the following steps:
- Start Designer/2000.
- From an ERD, choose Edit, Insert New Object and include a word document.
- Using screen capture. Several techniques are used to get screen captures, including
using Alt+Print Screen, editing and pasting the picture using Paintbrush, and using a
third-party tool such as PaintShop Pro to capture the screen.
- Using print file. The Designer/2000 tools print to the default printer unless
another printer is chosen. By using the Print Manager, you can change the printer setup
such that the printer destination is a file. This file can then be loaded in the document. If
the default printer is a fax machine, one can send a fax directly from Designer/2000.
Putting Designer/2000 Repository Data on the World Wide
WebPutting Designer/2000 repository data on the World Wide Web can be done by using a third-party driver such
as Adobe Exchange, which supports the .PDF file format. By using this driver as the
default driver, save the file in .PDF format. The file can then be downloaded on the WebServer and
an HTML link established so that the file can be read through the Web, using any Web
browser such as Netscape or Oracle PowerBrowser.
Most organizations have many existing applications that they would like to load into
Designer/2000. A variety of methods are available to perform this task. The following methods are
popular:
- Reverse-engineer DDL. This method can be used to take data objects from an
existing Oracle database and document the elements in the repository. It cannot,
however, deduce the constraints that are implemented through the program code. It can
reverse- engineer data objects from a local or remote Oracle database. Using this
method requires that the repository user have select privileges on tables, views, and
snapshots and also have execute privileges on functions, procedures, and packages.
- Reverse-engineer forms and reports. The Forms reverse-engineering utility extracts
the information from a Forms V4.5 program and puts it in the DES2K module definition
and secondary access elements. The Reports reverse-engineering utility works very
similarly to the Forms reverse-engineering utility and can reverse-engineer reports in
several languages, including SQL*PLUS reports, Oracle pre-compiler
reports, SQL*ReportWriter 1.1 reports, and so on.
Follow these steps to reverse-engineer forms and reports:
- Define the database in the repository.
- Define primary and foreign-key constraints in the repository.
- Load the forms into the Oracle database and reverse-engineer them one batch at
a time or one at a time.
- Manually insert any logic that did not get reverse-engineered.
Page 374
NOTE
|
Note that triggers, library attachments, procedures, and procedure calls are not
reverse engineered.
|
Utilities, Table Entity Retrofit. This utility transforms the physical data model into
a logical data model. The efficiency and usage of this method depend on how closely
the physical model and the logical model match each other. The most important
precaution you can take while using this utility is to make sure that primary and
foreign-key constraint definitions are defined in the physical database design. It should be noted
that this method does not convert a bad physical design into a good logical design. In fact,
it just converts it as is; therefore, if you want to save a lot of work after the
transformation is complete, you must match the physical model as closely as possible to the
desired logical model. This method has the following restrictions:
Constraint definitions should exist; otherwise, all columns will become
attributes instead of relationships.
Shared table definitions are not retrofitted.
The table should not be already mapped to an entity. If it is mapped, you must
delete the association or the entity definition.
To run the retrofit utility, you can choose Utilities, Table Entity Retrofit from the RON,
data diagrammer, or the entity relationship diagrammer.
Usually after the retrofitting has been performed, you will have to clean up the logical
design that is generated. To do this, complete the following steps:
- Change the relationship names to be more meaningful, because the names
generated due to retrofitting are derived from the foreign-key constraint names and are usually
not very intuitive.
- Check the type of relationships and make sure that they are what you really want
them to be; for example, mandatory foreign keys become optional/mandatory
relationships, whereas optional foreign keys become optional/optional relationships.
- Rename the attributes to be more meaningful to the users, because in the
physical design they might have been abbreviated.
- Do a sanity check of the resulting logical design to make sure that the entities
and relationships are really what they are supposed to be, because the physical design
might have implemented them differently.
Data administration involves the monitoring and control of a project's data. Different
configurations can be used for this purpose, each having advantages and disadvantages.
Designer/2000 provides features in the RON and the RAU to simplify this function.
Data administration configuration consists of knowing the application configuration that
best fits your organization structure, the number of repositories that works well with this
structure, and the number of users that need to be supported.
Previous | Table of Contents | Next
|