First some background...
We've been playing with DBBuilder and, so far so good. We have a specific way we model databases. We reverse engineer the actual DB into the Implementation model in the repository. We then clone the Implementation into the Development Model (for forward engineering - and eventually "compare and contrast" with the Implementation). Both are physical models - that is, the columns hold physical datatypes.
Finally we flip the Implementation into the Conceptual model. This is a non-physical model where the datatypes are conceptual datatypes. For example, a SurrogateKey column datatype in the physical model might be Int IDENTITY (1,1) whereas the equivalent column in the conceptual model will have a datatype of SurrogateKey.
So far so good. In addition, we have a special property/tag LogicalDatatype which is the intersection between the physical and conceptual datatypes (in this example MaxInteger).
Naturally, we map the Implementation and the Development to the Conceptual and the Development to the Implementation.
We do all this "magic" via an MS Access application that manipulates the repository DB directly.
Normally, this is initially done in a local .eapx repository so that we don't risk any rogue processes creaming the Enterprise repository. When we have completed our "machinations" we export the whole model structure (Conceptaul, Development, Implementation - C-D-I) and import into our Enterprise Repository.
We then attach other items to the DB items as required.
The problem arises when the actual implementation of the real DB evovles.
We have shown that the DBBuilder will indicate the differences (to our satisfaction). So we know that our Enterprise model has deviated from reality. The question is what is the best process to restore consistency?
Given that we prefer to run our "machinations" off-line, our current thinking is to re-export the existing C-D-I model and import into the original local repository, update the Implementation contents then re-run our machinations then re-export and re-import into the Enterprise repository. This process hinges on when the re-import into the Enterprise repository occurs, we lose none of the existing linkages from outside the C-D-I structure.
Will this work? is there any special things we need to watch out for in this process?
It may seem obvious that it should work, but a decade or so ago, we spent a good few months "helping" Sparx fix it's export/import function so that what was exported and then re-imported DID NOT CHANGE! Apparently, our testing regime was better.
TIA,
Paolo
