Data modeling: A journal
John Carlis and Joseph Maguire
Data Modeling, the featured topic on SearchDataWarehousing.com this week, is a very abstract topic. Data modeling involves working with users to build out a Logical Data Structure (LDS) that can be the ground work for the creation of a database, a data warehouse, or any type of application. Data models, as defined in Carlis and Maguire's book Mastering Data Modeling (Addison-Wesley), are "diagrammic or textual expressions of the kinds of data that an organization, a business, or a culture considers worth remembering." Following are short stories from Carlis and Maguire's book that illustrate some of the tenets of good data modeling.
Short, Frequent, Few
This story has three parts
Long meetings do not work well. Data modeling is hard intellectual work and people get tired. At company X, a four-day modeling blitz was not very productive. After a few hours people faded out. After a few days people got punchy.
Long intervals between meetings do not work well. At company Y, users who came back after several weeks either had forgotten a lot or had done a lot of hard thinking that put them out of sync with other users.
Large meetings do not work well. At company Z, a big meeting with two dozen users caused problems.
Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning editorial writers on the latest customer relationship management (CRM)and call center technology issues today. Our goal is to keep you informed on the hottest issues facing this fast-changing industry.
Hannah Smalltree, Editorial Director
A few users did most of the talking. A number of users listened at the beginning, but,
because they were not participants, their attention faded. The users who did most of the talking
were frustrated because, even though they dominated the meeting, they still had lots more to
contribute.
Moral: Have short, frequent meetings with a few users.
Slower and Louder
At agency X, partway through a three-day modeling meeting, I was locked in a room with about a score of scientists plus a few others. (Yes, I know, too many users and too long a meeting, but I was a novice then and did not frame the meeting well.) We had about 70 entities on an in-process LDS. Things were going very well when I made a mistake. After listening to the scientists for a bit, I wrote down an entity and asked them to name it. However, they said nothing. Wanting to make progress and knowing what they meant, I said, let's use this name for now and we'll change it later if need be. I was in charge so I wrote down my perfect name and moved on.
Thirty minutes later, the positive feeling in the room was gone. People had become tense and were fidgeting and speaking slower and louder (a sure sign that the speaker thinks the listener is dense). Disaster was imminent when I got lucky and realized that they did not understand my perfect entity name and, therefore, might accordingly misunderstand anything closely connected to it. I pointed to this entity and again sought a user name for it. We examined and discarded several possibilities until a previously silent user contributed a name. That word was really perfect because the users understood it. It pricked the bubble of tension and rescued the meeting and me, a misbehaving modeler.
Moral: Use user words, or else!
Thin LDS, Lost Users
At company X, I was observing a meeting run by a novice modeler, Mario. Although Mario did nothing overtly wrong, within 30 minutes the users were lost. During a break, Mario and I determined that the model was too thin. That is, many entities had just identifying descriptors. While this is syntactically okay, when he revisited whose entities asking, What else is memorable here? the users had lots to say. When there was flesh on the bones, the uncertainty abated and the session took a positive course.
Moral: Adding descriptors deepens users' understanding of an entity.
Data Modelers Must Understand Identifiers Deeply
In a university class I gave and in-class exercise to build an LDS for the local movie guide. A few teams put their models on the board. I said, Fred, your identifier for the entity named show means that a movie could be shown at only one time of the day and that cannot be right. Fred's reply was, So what? It was not a surly answer. Despite knowing the definition of "identifier," Fred did not see the consequences of his decision.
Here is another story with the same moral.
At company X, I was observing Liz, a novice modeler but an experienced programmer, model with users. At one point when she wrote down an entity plus its identifier, a user said, Whoa, that identifier prevents us from remembering ... Liz looked puzzled. She did not see the user's point.
Moral: Novice modelers have trouble with the notion of identifier, but users do not.
Click on the title to learn more about Mastering Data Modeling.
What did you think of this tip? Was it informative, or at least entertaining? E-mail and let us know.
This was first published in August 2001
Join the conversationComment
Share
Comments
Results
Contribute to the conversation