In the 1970s major database management system vendors began offering products based on three different primary models of data – network/hierarchical, relational, and entity set. These models of data all had strengths and weaknesses. In 1976 Peter Chen published a paper that proposed a unified view of data that adopted many of the characteristics of these earlier models of data and incorporated additional semantic information about the real world…entities…into what he called the Entity-Relationship Model of data. Because this model of data provides a view of data in the context of real world entities, we think of it as one of the first business focused data architecture styles.
The entity relationship model of data can be shown in a visual presentation that makes the essential data entities, elements and relationships present in data clear and easy to understand by non-programmers or data engineers. It was the first time a data blueprint could be produced in order to communicate the needs and requirements of the customer to the data and software engineers who would implement the design.
The primary benefit of designing and implementing this data architecture style is to constrain the implementation of the technology solution to a common structure that can be defined with consistent terminology and definitions about entities, data elements and their relationships. Applied in the wrong context or environment, this data architecture style can be brittle, difficult to load, difficult to extend or modify as the needs or requirements of the business change and difficult for end users to consume directly.
As with any architectural style, it is important to identify the right context or situation to apply the Entity-Relationship style and to articulate the appropriate guidelines and constraints on its use. In a future post we will discuss appropriate roles for each data architecture style in the modern enterprise data architecture.
