|
The Data Architecture Reference Model consists of the following contained major models:
- Data Element Models
- Concepts Data Model
- Database Logical Model
- Database Physical Model
Data Element Model. Data elements are the definition and stated semantics for enterprise business facts employed as the semantic foundations for attributes of entities within data models of concepts, columns of tables within database logical models that support business requirements, and ultimately the DBMS columns within database physical models that support the actual business operations. An example of a data element is Invoice Number.
Data elements are not just miraculously discovered. Rather they are derived from enterprise concepts represented through value-based expressions. The value-based expressions are founded on conceptual value domains, and are finally detailed through actual value domain value-sets.
In the case of the data element Invoice Number, the highest level concept might be Finance, and within that might be Instrument and within that might be Liability. As to the type of data, that is, Number, the Conceptual Value Domain would be Numeric with a Value Domain of positive integers, and a set of value domain values from 0001 through 2 billion.
Because of the Data Element Model work, all business fact representations in the concepts data model, and the database logical and physical models can be standardized. 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.
Concepts Data Model. Concept Data Models are data models based containers of concepts. Examples are students, schools, organizations, addresses, finances, inventory, locations, and the like. These concept containers are deployed as multi-business fact semantic templates within one or more tables within one or more Database Logical Models.
Every concept data model entity attribute should map to its data element semantic parent. Concept data model entity attributes can also have assigned semantic and data use modifiers that further restrict the meaning and value domains of an attribute that may exist within the scope of the attribute's parent data element. Finally, Relationships can interrelate entities within and across multiple subjects.
An example of a concept model is Invoices. In this example, the subject is Invoice, and of its contained entities two are Invoice Header and Invoice Detail. The attributes for each of these entities would be picked from the list of available data elements. Once a data element is picked, its properties are automatically copied and transformed into the appropriate properties of the entity's attribute. The primary key for each is InvoiceHeaderPKey and InvoiceDetailelPkey. Because of the previously created attributes, the appropriate ones for each entity are picked. A foreign key, that is, the backward relationship from Invoice Detail to Invoice Header would be established by replicating the Invoice Header's primary key attribute as an attribute within the Invoice Detail entity.
Because of the Concepts Data Model, the construction of all business fact representations in the concepts data model entities, that is, the concept data model entity attributes are all mapped back to their data semantic source, the data element.
This enables, the standardization of semantics even when the names of the data elements and the concept data model entity attributes are different. After all, "a rose by any other name is still a rose." This standardization dramatically affects even more of the "data harmony" bullets above.
Database Logical Model. Database Logical Models, are the data models of databases that are independent of database management systems (DBMS) such as Oracle, DB2, MS/SQL and Sybase. A database is bounded by a schema which, in turn, contains tables. Within tables are columns, primary keys, foreign keys, and unique keys. Relationships are restricted to tables within a single schema.
The point of having a database logical model is to specify database tables within the scope of a single schema that are completely independent of any consideration of performance.
Each Database Logical Model can import multiple collections of concept data model entities from multiple subjects to satisfy the overall requirements of the Database Logical Model schema. It can also be appropriate to import Concept Data Model entities for use in multiple Database Logical Model tables.
Every Database Logical Model table column should map to a parent Attribute from an entity of a Concept Data Model. Semantic and data use modifiers can be assigned to every column that can further restrict the meaning and value domains of a column that may exist within the scope of the column's parent attribute.
An example of a Database Logical Model is Financial Management. Here, the schema is Finance. Its table collections might include vendors, customers, accounts, cost centers, bank accounts, budgets, exchange rates, assets, depreciations, and the various transaction specifications for each table collection, including for example, InvoiceHeader and InvoiceDetail. The columns within each of these tables are automatically generated through the selection of the Concept Data Model. Created including column names, data types and the automatic mapping back to attributes from the appropriate Concept Data Model entity attributes.
The primary key for Database Logical Model table is created and because of previously created columns, the one appropriate set for each table is picked. A foreign key, that is, the backward relationship from InvoiceDetail to InvoiceHeader is established by replicating the InvoiceHeader's primary key column as a column within the Invoice Detail table.
Because of the previous work on the Concepts Data Model and the Data Element Models, the effort required to create a Database Logical Model is dramatically reduced. Further, this process enables the standardization of semantics even when the Database Logical Model table column names are different. This standardization is the culmination of positive effects on the "data harmony" bullets above.
Database Physical Model. Database Physical Models, are the data models of databases that are dependent of database management systems (DBMS) such as Oracle, DB2, MS/SQL and Sybase. A database is bounded by a DBMS schema which, in turn contains DBMS tables. Within DBMS tables are DBMS columns, DBMS primary keys, DBMS foreign keys, DBMS unique keys and DBMS secondary keys (non-unique values). Relationships are restricted to DBMS tables within a single DBMS schema.
The point of having a Database Physical Model is to specify DBMS tables within the scope of a single DBMS schema that are either tuned to efficient update or are tuned for efficient reporting. When tables are tuned for update they are commonly in third-normal form. When tables are tuned for reporting, they are commonly denormalized.
Each Database Physical Model can import multiple collections of Database Logical Model tables from multiple Database Logical Models to fulfill the overall requirements of the Database Physical Model schema. It can also be appropriate to import Database Logical Model tables for use in multiple Database Physical Model DBMS tables.
Every Database Physical Model table column should map to a parent column from a table of a Database Logical Model.
One example of a Database Physical Model is Invoicing. This database might be a subset of the Database Logical Model, Finance that has been created to specially serve the needs of a Invoicing business information system. Within this special database there could be the InvoiceHeader and InvoiceDetail DBMS tables. The DBMS columns within each of these DBMS tables are automatically generated through the selection of the Database Logical Model. Created are the DBMS column names, DBMS data types and the automatic mapping back to columns from the appropriate Database Logical Model table columns.
An opposite sized database example would be a very large, multiple-functional-area Database Physical Model with thousands of DBMS tables that are brought together from multiple Database Logical Models. In such a database there can be multiple collections of highly connected tables and intersection tables that relate tables from the different Database Logical Models to each other.
The first alternative, the subset database approach, 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. This second alterative, a database of thousands of tables could be such that much of the two shared data problems are designed out of existence. This elimination would occur if the Data Architecture Reference Model is followed 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.
|
