|
The solution approach is summarized as follows:
Data Element Model. The Data Element Model with all business fact representations represents the foundation for data semantics management of the attributes in the Concepts Data Model, the Columns in the Database Logical and Physical models.
Additionally, because data elements are set within their encapsulating concepts and conceptual value domains, the data elements can be seen to be semantically similar even when their names are different. These standardizations dramatically affect–in a positive way--the "data harmony" bullets above. The relationship between data elements and attributes is one-to-many.
Concept Data Models. The Concepts Data Model enables the construction of containers of multi-business-fact data structure templates that both map backwards to parent Data Elements from the Data Element Model and forward to one or more tables within one or more Database Logical Models. The relationship between Concepts Data Model and Database Logical Model is many-to-many.
Because of the backwards mapping from attribute to data element, the names of data elements and those of attributes can be different. Additionally, attributes can be constructed such that their semantic and data use modifiers can be more restrictive subsets from those specified for data elements.
Database Logical Models. The Database Logical Models are quickly and easily constructed by imports from the Concepts Data Models. The process is not one of invention. Rather, it is one of maximum reuse.
The Database Logical Model manufacturing process enables the standardization of semantics even when the Database Logical Model table column names are different. Additionally, columns can be constructed such that their semantic and data use modifiers can be more restrictive subsets from those specified for attributes. This standardization is the culmination of positive effects on the "data harmony" bullets above.
Database Physical Models. Database Physical Models, like Database Logical Models are quickly manufactured through imports from the Database Logical Models. Again, because of the backwards mapping process, DBMS Column names can be different from column names even though their other semantics are the same.
Database Physical Models can be of two extremes or a mixture of both. The first extreme is the subset database approach which closely tracks with the application centric database approach that are highly cohesive but very loosely coupled. Such a collection of databases would ultimately give rise to the need for the two data sharing problems described at the start of this ROI.
The other extreme is the expansive database that contains thousands of tables that enable elimination of much of the two shared data problems described at the start of this ROI. Elimination, however, requires following the Data Architecture Reference Model from Data Element to Concepts Data Models to Database Logical Models to Database Physical Models. It will be through these levels that maximum "data harmonization" can be accomplished.
|
