Data modeling is a complex topic. Becoming a professional data modeler takes months or years of education plus practical experience. It is not my intent to teach data modeling in this brief post, but to show how it is related to requirements elicitation.
I introduced some of the concepts of data modeling in Part 4 of this series, “Business Rules Analysis”. The relationships between entities are the business rules and they are fixed in the structure of the data. Examples of these rules are “A Customer lives at one or more Addresses” and “An Address may contain one or more Customers”.
Entities can be found in the nouns in your requirements. They are people, places and things about which the organization wishes to store data. In the example above, “Customer” and “Address” are entities and are therefore capitalized in the rules statements.
Attributes are the elemental pieces of data that are associated with each Entity. In the logical data model, each attribute must be stored with one and only one Entity. The logical data model represents the business Entities, Attributes and Relationships without regard to physical implementation.
The physical data model represents how the logical data model will be implemented in a relational database. Here are two examples of the differences between the logical and physical data models:
- In the logical model, you can have “many to many” relationships as in the Customer / Address example above. In the physical model you cannot implement many-to-many relationships, so there would need to be an additional table to store each Customer / Address combination.
- In the logical model, Attributes belong to one and only one entity. In the physical model, attributes can be included in multiple entities due to inclusion on table keys or for performance reasons.
The data is an important part of requirements gathering. It is an important tool in Event Discovery, as you will ask data related questions such as “What does having this data allow you to do?” and “If I took this data away, what would it prevent you from doing?” Other Event Discovery questions are “What events cause this attribute to be added (or changed, or deleted)?”
I would recommend all Project Managers at least be able to read and understand an Entity-Relationship diagram.
A reminder that my Kindle book “Project Management For The Real World” is available at
Practical Project Management Tips and Tools 