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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
