Designer 2000 - Sharing tables across applications

From: Justin Whitehead <jwhitehe_at_ksi.co.za>
Date: 1996/02/07
Message-ID: <4fa885$fc8_at_hermes.is.co.za>


The following is an overview of a part of our Designer 2000 environment:

DATABASE ON DEV1 Development Oracle Database containing about twenty applications originally loaded onto Oracle Case V 5. These were converted to Designer 2000. This Repository contains production versions of all the converted applications as well as holding new applications that are currently being developed.

DATABASE ON SERVERB This database consists of two Repositories. The first contains twenty large applications that were loaded into the Repository via a Reverse Engineering exercise. This base represents our Production environment and is updated when emergency changes are required or bugs need to be urgently fixed to the Production environment. This base is not 100% correct as the ERD is not logical and not all relationships are shown on the Data Diagram or the Entity Relationship Diagram etc.

The second repository on this database is being used for the extensive documentation of the SCMB Systems. A copy of the DEV1 applications and a copy of one application off the SERVERB Repository 1 environment have been loaded onto Repository 2 on SERVERB. This base is being developed to show the applications more accurately starting from the Reverse Engineered Repository. Redundant tables have been deleted even though they are still on the Production Database. Extra relationships have been loaded etc.

PROBLEM SCENARIO Tables are shared across applications in the following manner. Application A may share tables from a common application B. B also shares tables from application A. Application C shares tables from application D and B. etc. In doing the copy of application E for example from Repository 1 on SERVERB to Repository 2 on SERVERB all the shared applications are also copied across in a frozen state. If I now need to copy application F to Repository 2 from Repository 1 and it also requires B I now get another copy of B in a frozen state. If I now need to update B in such a way that all applications that use the common application B receive the updates I have to make these changes to each and every copy of B!! The applications are changed extensively on Repository 2 on SERVERB so it is not possible to update Repository 1 and copy it to Repository 2. This copying of applications that are shared when copying one application means that we can only ever copy the Repository as a whole to a second Repository. This in turn means that all changes made to one application need to be made manually to all copies of that application.

In order to overcome this scenario we need to unshare all shared objects on Repository 2 for application A, delete all shared applications for application A, copy common application B to Repository 2 plus all the other applications shared by A and re-share all objects that need to be shared. In bringing application B across a frozen version of application A will be brought across. This also has to be unshared and deleted. A very longwinded exercise as I need to write my own reports to identify shared objects. Supplied Designer 2000 reports are not working. The exercise is open to error.

How else do we manage a Production / Development / Documentation environment where all three environments have to be kept in sync with the Production environment? Is there a way of comparing Repositories and automating updates made to production to the other repositories?

I need to explaine that to book an application out, change it and book it back in again is not suitable for us. Changes are made to the production base that need to go live immediatly while enhancements are being developed for the same application at the same time that may not be ready to go live for a considerable period. These changes to Production will have to be made manually to the development Repository when they are made to the Production Repository.

What about knowledge co-ordination within the Designer 2000 environment? Does Designer 2000 cater for this? We need some guidelines.

Are any other companies facing the same challenge and if so who are they and can we go and see them? How are they making Designer 2000 work for them while in the phase where systems have been reverse engineered and have not been cleaned up to look like a top down design?

Thank you in advance! Received on Wed Feb 07 1996 - 00:00:00 CET

Original text of this message