Data models

In the real world, we think of data as facts, figures and other bits of knowledge. Put a lot of data items together in a useful form, and you get information -- maybe even intelligence.

Often, people can intuitively understand a given piece of data in isolation, but a computer can never do so without help. In computers, we store data in a database -- a highly structured, carefully defined and rigidly formatted collection of records -- so that we can retrieve it, use it, analyze it and work with it to run our businesses.

In fact, it is only the organization of a database that gives meaning and utility to the data inside it. Without that organization, all we have are undifferentiated ones and zeroes -- not numbers, not letters and certainly not knowledge.

Thus a critical step in data processing is the creation of a plan for the database that's simple enough for the end user to understand, yet detailed enough to let the database designer create the actual structure using database software. We call this conceptual plan a data model, though we use this term to describe two related but different ideas.

One, which we can also call a database model, is somewhat abstract in nature and refers to a database's overall structure, or type. The best-known example is the relational model used by Oracle, DB2 and SQL Server. Others include flat-file, hierarchical, network, object, semantic and dimensional models.

The second type of data model, or schema, takes the overall structure of one of the standard database models and tailors it to a specific application, company, project or task. This type of data model gets down to specific data items, including their names, values, granularity and how they relate to one another.

We can compare these data models to the plans for a new building. An architect designs different types of buildings -- a sports arena vs. a four-bedroom house, for example -- using quite different materials and techniques (steel girders vs. wood framing, cranes vs. ladders). So, too, do we implement the various types of database models (say, relational vs. object-oriented) quite differently on a computer.

When we build a schema, however, we're working at a detailed, nitty-gritty level; it's more like consulting an interior designer than an architect. The architect plans for a kitchen's space, wiring and plumbing, but the designer helps decide which appliances to buy, how to group lights, where to put the table and chairs, and how many cabinets are needed.

What's in a Model?

To illustrate what goes into a data model, let's assume we're creating a very simple inventory database for a widget-building assembly line. We need to know the following:

-- What data do we include? Parts numbers for our widget models, the subcomponents they're made from, raw materials and parts suppliers, costs and delivery times, inventory on hand and assembly time.

-- How do data elements relate to one another? Some suppliers deliver faster than others but charge more.

-- What processes, operations and transformations might we need to do? Calculate total cost per widget.

-- What kinds of questions will we need to answer? How much are we paying for parts? How many widgets can we produce next week?

-- What other business processes or activities might use this data? Accounts payable, product planning and sales.

While building this database, our data model proceeds from conceptual model to logical design to physical implementation:

1. Interview business users.

2. Define the data elements and their relationships.

3. Create a data model.

4. Select the database type and specific database management software (DBMS); often, it will be whatever you're already using.

5. Map data-model elements to tables, and normalize them.

6. Create data type definitions and a database structure.

7. Design the application.

Creating a data model takes a different mind-set than application development does. In Steps 1 through 3, at the conceptual level, we must think about what we're dealing with. In Steps 4 through 6, the focus shifts to how we implement the model. Step 5 marks the transition to logical design and Step 6 to physical design, both of which needed to meet our DBMS's specific requirements. In Step 7, programmers implement the procedures that use and manipulate the data.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark