The ORM Foundation

Currently, I'm using ORM to model the vast structure used for the US medicaid system. The number of diagram tabs I have is rather large.

This model represents data that will be stored using about two dozen different physical database models

It would be helpful if there were some way to select only a subset of the diagrams, and create a new ORM file with only the elements that appear in the selected diagrams. With that, I could select only the diagrams pertinent to one 'business area' and use that to map to a psecific logical data model, (e.g Drug Rebate diagrams migrated out to a seperate .orm file to facilitate the creation of the logical data model specifically for the Drug Rebate database.)

The whole notion of grouping is one that we need to address, and I've put some thought into this area. However, the 'diagram' notion is the display of a random collection of elements. Elements can be included multiple times in the same diagram and/or multiple diagrams. Diagram was not designed for formal grouping, and is probably not the best mechanism for formal subgroups going forward.

If the goal is to formally group elements, then we need significantly more structure than the completely unstructured many-to-many current working plan is as follows: 

1. Allow the modeler to create as many named groups as they like
2. Allow the modeler to associate one or more 'GroupTypes' with each named group
3. Allow each extension metamodel (not that the NORMA archtiecture treats all metamodels, including ORMCore and ORMShape, as extension models) to define 'GroupTypes'
4. Add type and overlap restrictions to each GroupType. Some GroupType examples could be:
• GT1 must be associated with at least one Group. Every ObjectType must be included in some Group with a GT1 type, or some group with GT1 must be marked as the default group for GT1. No ObjectType may be included in more than one Group that is associated with GT1.
• GT2 does not have to be associated with any Group. Any ObjectType, FactType, or Constraint can be added to a Group with type GT2. Items can be placed in more than one Group with type GT2.
• GT3 can be associated with any number of groups. Any type of object may be associated with a Group of GT3 type, and items cannot overlap with other groups of the same type.
5. Each item in a group must be recognized by at least one of the associated group types. Items in a group that are not of the type considered by a GroupType will be ignored for that type.
6. A subgrouping mechanism would be provided [this part needs work]

Given this mechanism, the relational mapping layer could define GroupTypes for 'Database' and 'Schema'. 'Schema' would be a subset of DB. Each ObjectType could be in multiple DB's but only one Schema per DB could contain any ObjectType (note that the Schema GroupType with a single Database assumed is similar to GT1 type above). Another GroupType would support grouping elements for reports (elements can overlap, similar to GT2). Another GroupType would indicate workitems (similar to GT3, a group could be created for 'Matt's workItems' with a GroupType of 'WorkItem' and item's requiring work could be added to it). Clearly, a general grouping notion could be extremely useful for managing a large model.

As far as when we could get this done: I'd like to do it relatively soon (within the next two to three months). The main issues are with the relational pieces, which currently assume that a single schema is generated from the model. Clearly this 1-1 assumption would need to change.

Once grouping is in place, there are two approaches we could take on the relational side to allow you to get multiple schemas and/or databases out of the same model.

1. Consider the groupings before we do absorption on the model (think of absorption as determining which ObjectTypes get tables). This is very difficult because we would have to run multiple absorption algorithms across the model.
2. Consider the groupings after absorption has been determine, ignoring groupings for ObjectTypes that do not map to tables. This is definitely something we could do, and does not preclude switching to 1 in the future.

Other future features would allow a model/submodel relationship with external model references (etc), but we need grouping within a single model with or without externals, and would like to be very solid on a single-model setup before moving into submodels/externals. 

Please comment. -Matt

You clearly have a challenging set of problems and I'd like to understand more about your needs so hence my questions:

1: What is the business need that is driving the solution of "about two dozen physical databases" ?

 2: Which ORM tool are you using?

Ken

It's important to establish a proper metamodel for this model partitioning before considering the tool support for the selected metamodel. Please consider my proposal of using multiple "vocabularies" and a vocabulary "import" operation with "correspondences" as I briefly outlined in another thread in this forum. The proposal is somewhat incomplete still, but offers a useful facility.

I also want to be able to use partitioning and imports to define security domains - in this case any concept may exist in more than one security domain, with a different status in each (modifiable or not, in the systems I've built).