Tom’s top 10 ERD peeves

An outsider’s view of data modeling is the Entity Relationship Diagram (ERD). It is the data architect’s deliverable that finds itself on team member walls. This graphical presentation is the snapshot of our data modeling.

I am amazed at how poorly architected some data models are that come across my desk. I don’t expect data architects to be Rembrandts. I do expect the ERD to be easily readable so that the intended audience understands the story that the data is telling. Here are my top 10 peeves on ERDs gone bad.

  1. Missing title – Hello! What is the name of this data model? Is it a logical or physical model? What is its purpose? All data modeling tools allow you to add a text box that will answer these questions. Make it large enough to see and position it in a prominent spot.
  2. No legend – I appreciate that you color coded your entities. However, could you please add a legend to let me know what the colors mean? While you are at it, can you make sure you are consistent across your models? That makes all our lives easier.
  3. Bad color choices – Why do data modeling tool vendors default to the most unappealing colors? Avoid their color schemes! Choose colors that are pleasing to the eye. If your ERD is often printed in black and white, make sure the printed grey tones are distinguishable.
  4. Too big a picture – Sometimes the big picture gives the audience no picture. Subset your data model into ERDs of 30 or less entities. If your ERD looks like your grade school string art project, go back to the drawing board. Rethink how to best display the data.
  5. Right audience, wrong display – I admire your beautifully diagrammed ERD. Unfortunately, what you gave me is not what your audience can understand and need. Know your audience. Today’s data modeling tools give you great control on the display of data model objects. Put yourself in their shoes when you create your ERD. Better yet, ask them for their expectations.
  6. Verbless relationships – Did you realize that a relationship line with no text has no meaning? Relationships show the business rules that ties the data together. Why did you omit such a valuable piece of information from your ERD? When you add it, make it a verb that can form a sentence between the subject and object entities.
  7. Convoluted relationship lines – I agree that we have a standard to not cross relationship lines. However, use some common sense. Our model users should not have to be Sherlock Holmes to trace the path of a relationship that spans three sides of the ERD. Your directive is to make the relationship readable. Allow it to take the most understandable path.
  8. Too small, too large – Yes, size matters. Did you scale that model to letter size so that you receive little feedback or are you just conserving paper? Pay attention to your scaling recognizing when the text becomes too small to read. On the other hand, be conscious of making the model too large to easily fit on a cubicle wall.
  9. Unreadable entities – Thank you for including the details of the entity attributes. Unfortunately, they run together and make it impossible to find the attribute name. Try omitting some characteristics and display the attribute characteristics in a grid format.
  10. What are the keys – Why did you not show me the keys? I expected to see them on this ERD that is used by the folks who must understand keys. Primary and foreign keys should be easily identifiable. For surrogate keys, I want to see the natural keys as an alternate key, preferably right under the primary key.

Tom Bilcze

2 Comments
  1. Interesting post, some of these are major annoyances of my own… when I’m not committing them myself.

    Interested in point 9 – Unreadable Entities. I’ve recently had feedback on some LDMs that I’ve put out for review that attributes would preferably be removed from the data model altogether and displayed separately in a table. This isn’t something I would ever consider but interested in your take on whether to maybe do this for derived attributes perhaps?!?

  2. Removing attributes from a LDM display would serve no purpose. Doesn’t that make it somewhat of a conceptual data model? I have at times only presented the attribute names in LDM entities without the datatype displayed. I have done this when the project is early on and typing data too early would just lead to confusion and unnecessary discussions. I always deliver a LDM data dictionary with the entities and attributes fully attributed.

Leave a Reply

Your email address will not be published. Required fields are marked *