Integrated Data Model.
Integrated Data Model
Integrated data model can be used as a tool to quickly develop quality database designs by reusing commonly available data models which are applicable to the enterprise’s requirements and customising the details for the application at hand. However, there is another purpose for many of these models – they provide practical designs and insights for integrating data, thus providing enterprises with powerful enterprise-wide information.
Integrating Data
Universal data models seem valuable for building a new database, but why would we need them? As a matter of fact, why would we need any type of data models if our packages already have a database design?
Aside from the usage of data models to define the data requirements of possible application packages, universal data models can be used to synchronise and integrate information across various applications within an enterprise. Without an enterprise-wide integrated picture of how data relates to applications, it is very difficult to build integrated architectures that provide accurate, consistent and integrated information.
Flexible Structure
Enterprise resource planning application packages claim to offer complete enterprise-wide, integrated, customizable solutions. However, organisations that select an ERP package generally also have numerous other application packages in order to obtain best-of-breed solutions. Therefore, enterprises will often have overlapping, redundant and incomplete data sources.
Universal data models offer flexible structures that can accommodate almost any data format from any application package, allowing the data from multiple packages to be synchronised and integrated within a single data construct.
For example, many enterprises select a specialised contact management application package; an ERP package to handle their mainline order, shipment and invoicing processing; a product configuration and/or quoting software package; and an accounting software package. Customer, supplier and employee information may, therefore, be recorded redundantly in these systems.
How can information from these packages be synchronised and integrated? Consider the standard party, party role and party relationship universal data model that is shown in Figure 2.1. Note that this is just one example of a universal data model. There are many other universal data models for other common constructs.
This model illustrates that a Party may be either a Person or an Organization, that each Party may be acting in one or more Party Roles over time and that each combination of Party Roles forms various types of Party Relationships. The Party entity facilitates a consistent place to store data such as contact data or demographics, regardless of their role, thus avoiding redundant, inconsistent data. The Party Role entity maintains information that is relevant to a specific role that a party may play such as payroll data related to the role of Employee or credit-check data related to the role Customer. The Party Relationship entity provides a place to maintain information relevant to the relationship between parties such as the relationship status, the relationship priority or meetings, phone conversations and other communication events that occurred within the context of each relationship.
The Whole Party
The “party” universal data model in Figure 2.1 can offer the capability to view consolidated, integrated information for each party only if there is a mechanism to cross-reference the party’s enterprise key with each of the application keys.
For example, suppose there are several records for the same person, John Smith – one in the contact management system and another record in the ERP application. The information from both systems could be different; for instance, the name could be spelled differently or there could be a different postal address, inconsistent phone number or inconsistent value for the demographic data.
Cross-referencing the Data from Multiple Applications
Sometimes, manufacturers maintain their own stock coding known as OEM (Original Equipment Manufacturer), distributors maintain their own codes and customer maintain their own coding. In such a case cross-referencing of the data from multiple applicants is to be done.
The key to providing an integrated profile is to set up an enterprise-wide key for each Party (in the universal data model) and to cross-reference it against each of the application systems – in this case, the contact management system and the ERP application.
There are three general strategies for cross-referencing this information:
Create a foreign key, party_id, from each application that cross-references each application key with the enterprise key. Create a cross-reference table that cross-references each application key with the enterprise key.
Use a combination of these two strategies.
Cross-reference Applications
If the system could relate and cross-reference all occurrences of any given party, it would be easy to obtain all the information about that party. This is significant because the ability to have complete information on each person or organization in an enterprise is a major advantage to most aspects of business, including selling and servicing.