Re: CASE Survey

From: Richard D Holowczak <holowcza_at_andromeda.rutgers.edu>
Date: 31 Jan 94 19:57:35 GMT
Message-ID: <Jan.31.14.57.34.1994.7822_at_andromeda.rutgers.edu>


deboer_at_wsl34 (Gert de Boer) writes:

>Richard D Holowczak (holowcza_at_andromeda.rutgers.edu) wrote:
>: dagmar_at_indian.mitre.org (Dagmar A. Bogan) writes:

[stuff deleted]

>Can you explain why this happens?

  This is a known behavior of Oracle CASE. When you make the   move from analysis to implementation, CASE looks at your   analysis information and then it looks at your existing   implementation (i.e. tables). From a clean slate, with no   tables implemented, all design and analysis information is   conisdered and all relationships are implemented as you have   seen. In this case, the implementation follows directly from   the analysis.

  However, if you delete portions of the implementation (such as the   table def. you deleted), this is not reflected in the analysis.   When you go forward again to implement the new tables, some   existing table definitions are found so they are left alone.   Often this is done at the expense of leaving out foreign   keys.

  The reason for this is as follows. Lets say I define a table, and   then use this table in modules, etc. Then, someone else comes   along and adds a table with a relationship to my table which   will cause a FK to be added to my table. CASE will not do   this. If you look at the impact analysis reports, they will tell you   the consequences of these actions.

  So, what is the solution ? When deleting a table, all other   related tables must also be deleted all the way down to   "source" entities, those with no FKs. Then these can all be   recreated properly in one step.

  Note that if analysis is done properly, this should   only be required in extreme situations.

Rich Holowczak
Rutgers University
holowcza_at_andromeda.rutgers.edu

>_______________________________________________________
>Gert de Boer
>Swiss federal institute for forest, snow and
>landscape research (WSL)
Received on Mon Jan 31 1994 - 20:57:35 CET

Original text of this message