Prelim Draft

Gourmet's Guide to Data Models

by J. W. Rider

Information merely doesn't lay there in a data base waiting to be scooped out and plopped onto some consumer's plate. Information varies in consistency and richness. Different parts of information go better together than others. A number of data model archetypes have been proposed for organizing information. These archetypes are much like culinary techniques in a couple of important ways.

Data models are a matter of taste. Some people prefer spice. Some prefer salt. Others want a little sweet. People are different. Information problems are different. Information arrangements are different. While it is true that all data models are able to store the same information, different models can emphasize the different parts of information that the data modeler finds important.

Variety remains important. No matter how much you like broiled lobster, you don't eat it every single day. An occasional newburg, or even a scampi, can fill in the nutritional gaps. In data models, it's remarkable how many practitioners only try to understand a single approach. It's like calling someone a "cook" when their favorite culinary implement is a microwave oven.

Data file

The notion of being able to collect information into a single container is a prerequisite for all of the rest of the data models. The remaining data models can add structure by specifying a format, but the data file model can handle all the formats.

As a container, a data file is like a shopping cart, a grocery bag, a picnic basket, or a lunch bucket. Some data files provide for different segments like a TV dinner. Some data files can contain more uniform contents like tin cans or bread boxes.

Flat file

If a text file is like a whole loaf of bread, then flat files slice up the loaf. You might also slice up the salami, but you're talking about a separate flat file.

Loosely, flat files view information as an ordered collection of "records." Well-defined subsets of each record are known as "fields." Each data field encapsulates a well defined data type (TEXT, NUMBERS, DATES) and contains a single value.

Carving something into smaller pieces makes both food and information easier to manipulate.

There's no best way to divide up something into parts. Consider potatoes. The data file approach is like serving a whole baked potato. The flat file breaks the potato up in more or less uniform pieces: sliced thin chips, julienne-sliced fries, or diced for hash browns.


If flat files look at information in slices, hierarchical data bases look at information as a ordered collection of different kinds of slices, like a club sandwich. You start with a slice of bread. Butter it. Add a slice of bologna. Hmmmm. Better make that two slices. Cheese? Yes. Lettuce? OK. Onion? Better skip that. Mustard or mayo? Lay on the top bread slice. Cut diagonally.

The hierachical data model provides a mechanism to associate related, but not identical, records together. In data processing, this eliminates a lot of redundancy.

The sequential approach of the hierarchical model makes the solution ideal for mass production engineering. This is good for making a large number of the same sandwich, or passing a sandwich from one station to another before delivering the result to a customer.

A good example of this is when you follow a recipe's step-by-step instructions.


If hierarchical data bases look at information like an assembly-line sandwich, network data bases look at information as a food service table in a delicatessen where sandwiches may be ordered custom-made and substitutions are welcomed. There's more than one way to make a sandwich.

In comparison to the hierarchical model, the network data model provides additional ways to associate records of different types. In fact, a network model could incorporate multiple hierarchical models simultaneously.

You could compare this with pizza home delivery. It doesn't much matter what route the delivery driver takes, or how many other stops the driver makes before delivering your pizza in a timely manner. Or consider how you might fix a single meal. Several recipes could be followed freely and simultaneously.


No matter how you slice it, bologna is still bologna.

In a way, the relational data model is just like a collection of flat files. Before relational purists get into an uproar, a number of subtle differences do exist. As a model, relational model is more abstract. It ignores any ordering of records in a file. Also gone are the strong connections that characterize the network model. Connections are permitted by a much weaker form of "logical" association. It doesn't mean the connections are not there, but the connections are not important to what the model characterizes.

Among the delicatessens of data management, relational data models represent an open buffet with trays of breads, meats and cheeses ready for customers to make their own sandwich.

The relational model has superior storage qualities. You see the similar storage mechanism at play in grocery stores, farmer's markets, apple barrels, pantries. and walk-in freezers.

Entity-Relationship (E-R)

If the relational model is like a buffet of different sandwich ingredients, the ER model is like a picture of a sandwich on the wall over the buffet that reminds consumers how the sandwich is supposed to look. Or, like the mouth-watering image on packaged products labelled "serving suggestion."

Put the grilled frankfurters next to the buns and mustard.

Object-Oriented (O-O)

The flat file model took a loaf of bread and sliced it up in order to make the bread useful for sandwiches. The OO approach would be to start with bread-like objects (e.g., biscuits, rolls, crackers, tortillas, buns, bagels, wafers, muffins, pita, macaroni).

The flat file approach cuts things up into simpler bite-sized pieces of almost constant consistency. OO considers objects to be almost a complicated as the original. They are just on a smaller scale. OO sees the process of preparing a banquet as multiple instances of preparing a meal for one person.

The flat file slices just kind of lie there and need to be processed by something external. OO includes a notion of making objects self-responsive. It's kind of like the self-service lines in fast food restaurants.

Multi-dimensional (M-D)

Unplanned transformations.

Most other data models are going to look at a fruitcake as a sweetbread with fruit and nut mixture. The multi-dimensional approach says that sometimes that makes sense, but sometimes you want to be able to look at fruitcake as a piece of fruit surrounded by sweetbread.

Separating wheat from chaff. Grinding ingredients to create flour or hamburger. Could make meat loaf, beef pot pie, or turkey stuffing.


Of course, we have no idea what it might be called. Someone will always be able to create a new kind of sandwich.

Bon appetite!

Copyright 2003, J. W. Rider
Webcrafted by J. W. Rider
JWR 030501