A picture is worth a thousand words, as they say, and it is important that the layout and formatting of your high-level data model is intuitive and easy to understand. Remember – the main audience for a high-level data model is the business, so keep it approachable and easy to understand. Here are some simple tips:
Don’t Be Afraid to Use Non-Traditional Formats
In building a high-level data model it’s OK to bend the rules of traditional logical and physical data modeling. As long as the core concepts are correct, you can be creative in using different methods of getting the point across to the business audience. For example:
- Use pictures in your model instead of the traditional entity-relationship (ER) boxes (e.g. picture of a customer, product, etc.)
- Translate business rules into ‘English-friendly’ sentences and put them in a document or spreadsheet format
- Publish business definitions on the company’s intranet site
Is Notation Important?
The important thing about the choice of notation is whether it easily conveys the correct information to its intended audience. Thus, an entity-relationship (ER) model is an ideal choice for data architects with the intention of eventually translating their models into a physical database, for example. This is a common choice for data modeling – so common, in fact, that many of us assume that a data model is the equivalent of an ER model. But there are other valid choices for data models. UML, for example, is used for application developers who are focusing on classes, not databases. And a business user might want to see his or her data constraints in an Excel spreadsheet, not a formal model at all. The good news is that most good modeling tools have translation capabilities to convert, for example, an ER model into a UML class diagram. And there are many third-party translation software vendors and metadata repository vendors who offer similar services.
Translating the business rules from a data model into English sentences, e.g., “An employee can belong to only one department” is a helpful way to communicate with a business user. Excel and Word can be valid models, too, as long as their source is from a more robust data modeling tool or metadata repository so that common definitions can be rationalized and reused across the organization.
Use Effective Model Layout
If you choose to use an ER-style diagram for your business audience, remember that formatting and layout are as important as the business rules and definitions embedded in the model. You only get once chance to make a first impression, and the initial readability and layout of your model can either turn your readers away immediately or pique their interest to learn more. Here are some rules of thumb to remember when building an ER model for a business audience.
Show definitions where possible. Object definitions are critical to the high-level data model. Where it doesn’t make the model too difficult to read, they should be included inside of the object boxes. Some rules of thumb:
- If the number of objects is small, it is a good idea to show the definitions inside of the object boxes on the model. If the number of objects gets too large, this may be distracting.
- If the focus of the model is on the definitions of the objects, definitely show them. If you are trying to highlight the relationships/rules, it might make sense to hide them so they are not distracting to the main purpose.
- In all cases, the definitions of the objects should be created and analyzed – whether they are shown inside of the boxes and/or in a textual, document-based format.
Show verb phrases for relationships. Remember, the relationship lines in your high-level data model are the verbs in your sentence. Just as if you said “My friend _____ the wall,” no one would understand you. They’d wonder if your friend had climbed the wall, walked into the wall, or what? In a similar vein, the sentence rules in your data model will not be easily understood if verb phrases are not shown on the diagram.
Use color, font, and white space effectively. The presentation of your model is important for clarity and to keep the reader’s interest. Here are some tips:
- Choose a model background with a different color than the boxes (e.g., gray background with white boxes).
- Use color, font and entity size to emphasize things like entity importance, model issues, integration issues, definition issues, etc. Include a few examples.
- You can make the key concepts larger to stand out more on the model.
- Don’t be afraid to have empty space on your model where there are no boxes.
Note that color should not be the only method used to convey meaning. Remember, some people are color-blind. I once worked with a color-blind coworker who consistently created presentations and models in shades of beige, or who would create models with a bright green background and florescent yellow objects. To him, it was the contrast that was important, not the colors, and to the audience the result was often painful! Also, not everyone you will be sharing the soft copy of the model with has a color printer.
Keep the high-level data model to one page whenever possible. Simplicity and brevity are the keys to success here. If your model spans more than one page, ask yourself:
- Did I define my subject area, business area or application too broadly? Should I focus the information in this model on a smaller subset of the business?
- Do any of the concepts express the same idea? Am I using redundant terms for the same thing?
- Should I just use smaller font so that I can fit more stuff onto one page? (I’m kidding! Never do this!)
Remember, the ultimate goal of a data model is communication. While precision of language and notation is important, it’s also important to loosen up and cater your language and approach to your audience to make sure that information is communicated effectively. It’s the yin and yang of high-level data modeling – being precise where it’s important for the ultimate goal of the project, but being flexible enough to bend the rules when it helps the audience understand the meaning of the model. If you win the favor your business audience or sponsor with your high-level model, you always delve into the details when you define your logical and physical data models. But if you lose their interest at the outset, you may never get that chance.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access