20 May 1996 updated
This diagram shows how data models may exist in at least three dimensions:
Regardless of the capabilities of any tool for data modeling per se, the resulting models must be managed in these dimensions. Thus multiple copies of each model will exist. These need to be tracked, reconciled, protected, and reused from time to time. Furthermore, many modled objects may cross the boundaries from one subject area to another, as when entities are reused.
Click on the yellow "Engineering/Production/Ver 3" box to examine issues of any single data model locus.
Various enterprise use enhancements:
Since several analysts could not work on the same CDM/PDM file simultaneously, each analyst developed their own models, adding common entities as required.
Entities which already existed in the global model were added to the analyst models to show relationships, with most of the data attributes omitted. New entities which were common to several analyst modules were added to each model as required, with a core set of data attributes. For additional or modified attributes changes were made by individual analysts in their own models.
We used the method of colour coding entities suggested during training to indicate which entities were existing entities taken from the global model and which were "owned" by another analyst.
As each analyst's model was finished, it was merged manually (by re-entry) with the global model. The presence of many existing entities in the new models meant that consolidation was ruled out.
The end result was that a lot of effort went into creating the final merged model, and even then it contained many errors.
A pre-requisite to multi-user model access would be that individual users must be identified to the PowerDesigner modelling tool itself.
An approach to multi-user model access might be one of the following:
The second approach has the advantage that if implemented in an open fashion, it should be possible to integrate with an existing Version Control system (including ours).
If the PowerDesigner database is relational and as robust as advertised, then the Enterprise model could be installed in a networked environment with the ability of multiple team members adding and changing objects in the sub-model which they have authority to access.
Other CASE tools provide the ability for team access to the models. For example, Sterling's KEY products offer this capability. An encyclopedia contains a team's view of the enterprise, including data, process, and the interaction of the two. (It appears PowerDesigner's defintion of a sub-model is the same as the KEY definition of an encyclopedia.) This is consolidated in and out of the enterprise model. Opportunities are provided to resolve differences between each team's understanding of an object that is shared between teams. Resolution of some changes, like deletion of an entity at the enterprise level, requires that action to be performed at the enterprise model level. Some of this capability is similar to what is currently offered by PowerDesigner.
The additional piece offered by Sterling is the opportunity for multiple users to access the same encyclopedia (or submodel) at the same time with a communications piece that informs each user when another user is updating an object that they both are accessing. If two users are in separate process views of the ERD which includes the same objects, and one updates an entity or it's associated objects, or even changes the placement of an object within the diagram, the other user is notified of the change so he may refresh his screen to see the changes.
Security is handled in many ways in the Sterling product. Each workstation that accesses the product on the network, has security installed at the workstation level. Individuals must be added to the workstation and individuals must be given access to each encyclopedia or team model. The team models may be stored at the workstation level if they are stand-alone, or stored on the KEY server where they may be accessed by multiple users at the same time. At the time the team is ready to check in their encyclopedia to the enterprise model, conflicts between the objects are identified and resolved.
(Methodologies promoting the concept of determining business areas would benefit anyone trying to determine how to divide corporate data into models that are workable between teams. If an IE approach is used and the data is identified at a high level and then broken down and normalized by business area there is usually some overlap, but less than an unorganized approach. )
How to improve the product to properly support Enterprise modelling?
A real "versioning" capability:
The current dictionary does a good job of supporting a group of developers working on one model. However, it does not support the number of models required to maintain multiple systems using differing databases from different vendors through all the phases of development (development, test, integration, production, and history).
What is needed?
We would like to see more versioning control in the product. We have two major subject area models that are not in the same database. They each have their own set of versions. Some objects are overlapping on the two models. (I understand that in the past there were a lot of problems encountered when trying to incorporate the two models into one, so they remain separate. )