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.
More
Computerworld
QuickStudies
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.