The data model format that is the subject of this book is very similar to a spreadsheet. (Although the definition of ‘data model’ is broader, going forward, when I use the term ‘data model’, I am referring to the format which is the subject of this book.) Unlike a spreadsheet, however, a data model:

·         Contains only types. Data models don’t usually display actual values such as ‘Chocolate’ and ‘3 Scoops’. Data models display concepts or types. So, a data model would display the type Ice Cream Flavor, instead of showing the actual values ‘Chocolate’ or ‘Vanilla’. A data model would display the type Ice Cream Size, instead of showing the actual values ‘1 Scoop’ or ‘2 Scoops’.

·         Contains interactions. Data models capture how concepts interact with each other. For example, what is the interaction between Ice Cream Flavor and Ice Cream Size? If one orders three scoops, for example, must they all be the same flavor or could you have three different flavors? Interactions such as those between Ice Cream Flavor and Ice Cream Size are represented on a data model.

·         Provides a concise communication medium. A single sheet of paper containing a data model communicates much more than a single piece of paper containing a spreadsheet. Data models display types, not actual values, and they use simple yet powerful symbols to communicate interactions. We can capture all of the types and interactions within the ice cream example in a much more concise format using a data model rather than in a spreadsheet.

Fun with Business Cards

Business cards contain a wealth of data about people and the companies for which they work. In this book, I illustrate many data modeling concepts by using business cards as the basis for a model. By building a business card data model, we see first-hand how much knowledge we gain from the actual values on a business card or, in a broader sense, the contact management area.

I opened the drawer in my nightstand (a scary proposition, as it had not been cleaned since the mid-1980s) and grabbed a handful of business cards. I laid them out and picked four that I thought would be the most fun to model. I chose my current business card, a business card from an internet business that my wife and I tried to start years ago when dot-com was hot, a business card from a magician who performed at one of our parties, and a business card from one of our favorite restaurants. I changed the names and contact information to protect the innocent, and reproduced them here, in Figure 1.2.

Figure 1.2 Four business cards from my nightstand

What information do you see on these business cards?

Assuming our objective with this exercise is to understand the information on the business cards, with an end goal of building a successful contact management application, let’s begin by listing some of this information:

We quickly realize that even though we are dealing with only four business cards, listing all the data would do little to aid our understanding. Now, imagine that instead of limiting ourselves to just these four cards, we looked through all the cards in my nightstand—or worse yet, every business card that has ever been received! We would become overloaded with data quickly.

A data model groups data together to make them easier to understand. For example, we would examine the following set of data and realize that they fit in a group (or spreadsheet column heading) called Company Name:

Steve Hoberman & Associates, LLC

The Amazing Rolando

findsonline.com

Raritan River Club

Another spreadsheet column heading could be Phone Number. Table 1.3 captures this subset of the business card information in the form of a spreadsheet.

Table 1.3 Subset of business card information in a spreadsheet format

Taking this exercise a step further, we can organize the data on the cards into the following groups:

Person name

Person title

Company name

Email address

Web address

Mailing address

Phone number             

Logo (the image on the card)

Specialties (such as “MAGIC FOR ALL OCCASIONS”)

So, are we finished? Is this listing of groups a data model? Not yet. We are still missing a key ingredient: the interactions or relationships between these groups. For example, what is the interaction between Company Name and Phone Number? Can a Company have more than one Phone Number? Can a Phone Number belong to more than one Company? If so, is that a problem? Can a Company exist without a Phone Number? These questions, and others, need to be asked and answered during the process of building the data model.

In order to build any wayfinding tool, one must get lost enough times to know the right path. For example, the first person who builds a map of a region must have taken quite a bit of time and made quite a few wrong turns before completing the map. The process of building a map is both challenging and time-consuming.