logo for information-management-architect.com
Home
Strategy
Framework
Business Case Analysis
Project Planning
Requirements Analysis
Architecture & Design
Build Phase
Quality Assurance
Transition to Production
Management Information
Business Intelligence
Data Warehouse
Tools
Jobs
Contact David Bowman
leftimage for information-management-architect.com

Entity Relationship Diagram

Need an entity relationship diagram for an information management requirements specification and want practical timesaving suggestions?

Data model objectivesEntity Relationship Diagram

The objective of an entity relationship diagram is to show the business rules that apply to an organizations data. It contains entities, which are things of interest to a company, and relationships, which are relationships between entities. It also documents volumetric data so that we know what the initial data storage requirements will be together with the anticipated growth

Some examples

A customer, product and order might be considered something of interest to an organization. A simple relationship between these entities might read:
  • Customer places one or many orders;
  • An order must be placed by one, and only one, customer
  • An order must be for one or many products;
  • A product may be ordered by one or many orders.
An attribute is something that further describes an entity, e.g. customer first name, customer last name, or product name.

A fully attributed data model contains:
  • all entities of interest to a project;
  • all attributes for each entity; and
  • a definition of each entity and attribute together with an example.
Why is a model important?

An entity relationship diagram is an excellent communications tool, which can be used to confirm business requirements and provide direction to the architecture and design team as they move forward with physical database design.

If we are building a data warehouse, it provides the business rules that are needed to ensure data integrity e.g. if an order is received from a source system and is not related to a customer, then we have a data quality issue—We should not load this data into the warehouse because it fails the business rules.

What is a quick way to create an entity relationship diagram?

An information management project should use the enterprise data model as a starting point.

In a perfect world, the enterprise data model is a fully attributed model but in reality, it may only include key entities and relationships.

A data modeler should involve the business team in data modeling sessions. There are data model resource books, which can also be used as reference or as a starting point, if there is no enterprise data model.

What else does the model provide?
  • Confirms business rules;
  • Is used as the “target” for data movement mapping and helps ensure no data is overlooked;
  • Provides direction to the architecture and design team to start physical database design; and
  • Helps make important decisions about facts and dimensions required for business intelligence purposes.
Do we always need a logical model?
  • If the project is building a data warehouse, than a model is required;
  • If the project is extracting data from a source system and loading it directly to a data mart (without using a data warehouse) then it is desirable, but can be omitted; and
  • If the project involves extracting data from source systems and consolidating it into a data feed to a target system (without storing it a data warehouse or data mart), then it may not be required.
Summary…

An entity relationship diagram is a mandatory requirement for most information management projects. The enterprise model should serve as the starting model and a data modeler needs to work with the business team to finalize the model. A data model is not required for all projects and may require an exception to the project management methodology.


footer for Information management page