For a web project to be successful, we must ensure that the right solution is being delivered, one that is in line with organizational goals and stakeholders’ priorities.
My role as a Business Analyst is to elicit and analyze project stakeholder requirements and to convey what the desired solution will do both at a high level and at a detailed level. One task to accomplish this goal is to communicate how an organization’s business processes are conducted and how these processes relate to one another. This is expressed by a functional decomposition diagram, which is a work product that formalizes the processes, or “verbs,” of a proposed system.
However, this provides an incomplete picture. We must also capture and describe the “nouns” of the system; that is, we need to formalize what data entities the system will manage and how they interrelate.
An entity relationship diagram (ERD) is the work product that achieves this aim. The ERD is used to build a data model, which is a visual representation of the data needed for the solution. Often an organization’s data is stored in a legacy database that needs to be migrated to a new one, and often critical data isn’t being properly stored at all.
Who Benefits from an ERD?
The ERD is useful to both developers and stakeholders. For developers, it provides a data specification from which to construct a database schema. Further, it serves as a decision aid when choosing between platforms to migrate to; a particular schema may fit in better with one platform over another. For stakeholders, it formally describes their information needs in clear, unambiguous terms, confirming that the stakeholders’ needs are understood correctly and completely.
How to Interpret an ERD
Here's a small example Entity Relationship Diagram:
This compact notation represents data entities (the rectangles), their relationships (the connecting lines), and their attributes (the list of fields per entity). Think of it as an abstract database schema and an excellent framework on which to create an actual, more detailed data schema. The ERD serves as a bridge between the stakeholders and the database designer, translating their verbally-expressed data requirements into a specification.
Let’s take a closer look at what the above notation means. Each of the three rectangles is a data entity - Customer, Email, and Address. Each entity has its own attributes’ for example, Customer has the attributes ID, Name, and Phone. Relationships are more complex to convey. When one object references another, a foreign key needs to be an attribute of the object. In our example, Email has a field called Customer ID, which is a reference to a particular Customer data entity with that same ID. In an ERD, when any two entities are related, they are connected with a line with “crow’s foot” symbols on them that define cardinality thusly:
If any two related entities are viewed as subject and object, then the cardinal relationship between them is expressed at the far end of the connecting line. So, in our example, for any Customer entity, there must be one to many associated Email entities, and for any Email entity, there must be a reference to one and only one customer. Likewise, for any Customer entity, there must be zero to many Address entities associated with it, and for any Address entity, it must reference one and only one Customer entity.
So, although an ERD doesn’t get into the level of detail of a database schema, it bridges the gap between a stakeholder’s expressed data requirements and the developer’s data schema in a format that both parties can understand and find useful.
We at Mediacurrent provide many other deliverables that clarify and formalize your requirements. Reach out to us to learn more!