Integrated Metadata for Business Information Systems
Published in TDAN.com in June 2010
Published: January 1, 2011
In this article, Michael Gorman sets out an overall contextual diagram for an environment as it relates to a large scale data-centric business information system project, briefly defines each of the data model components of this environment and briefly describes how business information systems architecture, engineering, and deployment components are interrelated one with the other through data models.
In a large scale data-centric environment for business information systems, there are a number of factors in the determination of an overall success. Among these are:
Data Management Contextual EnvironmentThere are two major classes of components in the data-centric business information system environment:
Data Elements: A model of the data elements employed throughout the environment independent of any deployment context. The data elements defined in this model are the basis of the semantics employed by contextual facts. That is, facts specified in, for example, containers such as entities, tables, DBMS tables, screens, or reports. Data Elements are thus defined-once and its semantics are deployed many times across all these different containers.
Concept Data Models: A concept data model is a data model of a specific concept, represented as a container such as student, school, organization, or address. These containers (e.g., student or school) must be specified before they can be implemented in one or more different database collections of tables that ultimately become operational through a DBMS such as Oracle. Concept data models are not data models of databases. Rather, they are business specification data models of concepts within and across functional areas. Concept data models are independent of database engineering. Attributes of the entities from within these specified concept data models are deployments of the semantics of data elements from within the Data Element data models.
Logical Database Models: A logical database model is a data model of a database that is independent of any given database management system (DBMS) such as Oracle. In this state, that is, independent of any particular DBMS, this database models is called “logical.” Most commonly these database models are precisely defined in third-normal-form. Columns of the tables from within these “to-be-implemented” database models are deployments of a single attribute of an entity from a concepts data model.
Physical Database Models: A physical database model is a data model of a database that is bound to a specific database management system (DBMS) such as Oracle. In this state, that is, dependent both upon a particular DBMS and upon the performance requirements of a particular software application, this database model is termed “physical.” These database models are the “to-be-operational” database models that are bound to business information systems through view data models. These physical database models are often not in third normal form as a way to meet needed performance requirements. DBMS Columns from the DBMS tables from within these operational data models are deployments of a single column of a table from a logical database model.
View Data Models: A view data model is a data model of the interface between a physical database model and one or more business information systems. View data models are bound to the particular DBMS through which they are defined. View data models enable application systems to select, employ, and update databases according to their physical database models without having to include physical database model details within the application systems.
XML Data Models: An XML data model is a data model of data that is both DBMS and business information system independent. The structure of XML data is expressed through an XML schema that is employed to then understand the contents of XML data records. XML schemas are created through special software applications. XML data streams are created by source business information systems and are subsequently read and processed by target business information systems.
Figure 1 presents the six data models, the interrelationships among these data models, and the business information system components that are involved in a myriad of ways within the data models.
The six data models within Figure 1 contain two sets of relationships. The left-side set of the one-to-many relationships go “down.” This relationship supports two meanings. The first is the mapping of an individual component of a model, and the second is the mapping of a whole collection components from within a data model. In the Data Element model there can be individual data elements such as Person First Name, and there can be collections of data elements within a specific data element concept collection, for example, Person Related Information such as Person Identifier, Person Birth Date, Person First Name, Person Middle Name, and Person Last Name.
In the first type of the left-side one-to-many relationship, the individual data element, Persons First Name, would be semantically mapped to zero, one, or more attributes within different entities. For example, to Employee First Name, to Customer Contact First Name, or to Causality Insurance Contract First Name.
In the second type of left-side relationship, that is, a whole collection of data elements, can be mapped to a whole collection of attributes across one or more entities. For example, all the Data Elements within a Data Element Concept collection called Biographic Data Elements might be mapped to the entity, Person Information, or to the entity, Customer Contact Information. In this case, the mapping of the data elements, Person Identifier, Person First Name, etc., is mapped to a corresponding set of attributes within one or more entities.
On the right-side of Figure 1, there is also a set of one-to-many relationships. These go “up.” This set, like the left-side one-to-many relationships has two meanings: individual component, and whole collections. The meanings of the right-side one-to-many relationships are different from the left-side one-to-many relationships. The first type of right-side relationship, the mapping of an individual component is not one-to-many, but one-to-one. Thus, an individual DBMS Column, for example, EmpFrstNam can be inherited from only one higher level component, for example, the single column, EmployeeFirstName.
The second type of right-side relationship, the mapping of collections can be one-to-many. That is, one collection can map to one set of columns within one table of a single logical database model while another collection from the same physical database model can be mapped to a different collection within a different logical database model. Hence, the collections can be seen as “from” one physical database model to zero, one, or more logical database models.
The business information system component, for example, Business Requirements are also shown in Figure 1 have a one-to-many relationship between each business information system component and zero, one or more of the components within data models. When two or more business information system components are interrelated with one or more of the data models, there is an inferred relationship between those two business information system components. For example, there is a business requirement to capture student addresses. Additionally, there is a use case through which a Student’s Address is captured. Apart from the obviousness of the interrelationship, that there is a common data structure, Student Address, which serves to interrelate these two business information system components
Business Information System ComponentsBusiness information system components include:
The data models from Figure 1 are not accomplished in isolation. They result from an initial and then on-going analysis of a number of these different business information systems components. That is, Business Requirements, Business Rules, and the like. These business information system components are graphically depicted around the data model environment core of Figure 1. As each of these business information system components are required, specified, developed, reviewed, and evolved, the effect of those involvements must be reflected in one or more of the six data models.
Figure 1: Data Management IVV Environment
Data Management Component InterrelationshipsTable 1 provides a cross reference between individual data models (e.g., Logical Data Model) and specific business information system components (e.g., Business Rules). As an example from Table 1, each Data Element “should know about” or must take into account zero, one or more Business Rules.
Table 2 provides a cross reference between one business information system component and other business information system components. As an example from Table 2, a Business Rule “should know about” or must take into account zero, one or more work breakdown structure elements, external interfaces, on-line interfaces, software system components, and user acceptance tests.
The implication of the interrelationships is that when a given business information system component (e.g., Business Rules) is specified, developed, evolved, and reviewed, what needs to be concurrently assessed, reviewed and likely evolved are the interrelated data models (e.g., Data Elements), and also all interrelated business information system components (e.g., work breakdown structure elements).
As a business information system component is being required, engineered, developed, and/or maintained, the effect on its interrelated data models and other business information system components must be determined. For example, it is not uncommon that during the walk through of a use-case that a large quantity of data evaluation and value setting discussions surface. If the data model steward is present at these sessions, the implication of the data impact issues can be quickly identified, researched, and discussed. Once a use-case walk-thru is concluded, the write-up of the walk-thru would naturally have a set of data and process impact statements.
Table 1: Interrelationship between Data Models and Business Information System Components
Table 2: Interrelationship between Involved Components and Involved Components
Summary and Way AheadAnyone who’s attended a DAMA International Conference or who has listened to John Zachman speak about the frameworks has heard the following:
“Someday, you are going to wish you had all those models, enterprise wide, horizontally and vertically integrated at an excruciating level of detail.”
Everybody knows that day has long come and gone, yet everybody keeps talk about it in the future with longing and great hope. However, there are many, many multi-hundred million dollar projects that have crashed and burned because John’s words spoken in the late 1980s have not turned into a “here and now” set of work steps, artifacts that are created, stored, reported and evolved in a metadata management system.
A comprehensive metadata management system enables the metadata from both the six data models and also all the business information system components to be comprehensively represented through a set of requirements, attendant architectures, engineering artifacts, specifications, design documents, and implementation aspects that are created, stored, reported, evolved, and thoroughly interrelated.
When comprehensive metadata management exists, database designs can be quickly manufactured with thoroughly integrated semantics, and business information system prototypes be quickly generated from these metadata collections, that, in turn, can be demonstrated, cost-effectively evolved and, once completed, can be turned into production class business information systems that are right the first time they are deployed.
The time and cost of accomplishing comprehensive metadata management is exceeded only by the time and costs of not doing it. This simple fact has been proven over and over. The consequences from comprehensive metadata management are: increased productivity, increased quality, decreased cost, and decreased risk.
Recent articles by Michael M. Gorman
Michael M. Gorman -
Michael, the President of Whitemarsh Information Systems Corporation, has been involved in database and DBMS for more than 40 years. Michael has been the Secretary of the ANSI Database Languages
Committee for more than 30 years. This committee standardizes SQL. A full list of Whitemarsh's clients and products can be found on the website. Whitemarsh has developed a very comprehensive Metadata CASE/Repository tool, Metabase, that supports enterprise architectures, information systems planning,
comprehensive data model creation and management, and interfaces with the finest code generator on the market, Clarion ( www.SoftVelocity.com). The Whitemarsh website makes available data management books, courses, workshops, methodologies, software, and metrics. Whitemarsh prices
are very reasonable and are designed for the individual, the information technology organization and professional training organizations. Whitemarsh provides free use of its materials for
universities/colleges. Please contact Whitemarsh for assistance in data modeling, data architecture, enterprise architecture, metadata management, and for on-site delivery of data management
workshops, courses, and seminars. Our phone number is (301) 249-1142. Our email address is: firstname.lastname@example.org.