Databases Reference
In-Depth Information
the rest. (As for that “and so forth” in the definition, it covers such matters as keys, foreign keys, and various related
concepts.)
The second meaning of the term
data model
is as follows:
Definition:
A
data model
(second sense) is a model of the data—especially the persistent data—of some
particular enterprise.
In other words, a data model in the second sense is just a (logical, and possibly somewhat abstract) database design.
For example, we might speak of the data model for some bank, or some hospital, or some government department.
Having explained these two different meanings, I'd like to draw your attention to an analogy that I think
nicely illuminates the relationship between them:
A data model in the first sense is like a programming language, whose constructs can be used to solve many
specific problems but in and of themselves have no direct connection with any such specific problem.
A data model in the second sense is like a specific program written in that language—it uses the facilities
provided by the model, in the first sense of that term, to solve some specific problem.
It follows from all of the above that if we're talking about data models in the second sense, then we might
reasonably speak of “relational models” in the plural, or “a” relational model (with an indefinite article). But if
we're talking about data models in the first sense, then
there's only one relational model
, and it's
the
relational
model (with the definite article).
Now, as you probably know, most writings on database design, especially if their focus is on pragma rather
than the underlying theory, use the term “model,” or “data model,” exclusively in the second sense. But—
please
note carefully!
—I don't follow this practice in the present topic; in fact, I don't use the term “model” at all, except
occasionally to refer to the relational model as such.
THE RUNNING EXAMPLE
Now let me introduce the example I'll be using as a basis for most of the discussions in the rest of the topic: the
familiar—not to say hackneyed—suppliers-and-parts database. (I apologize for dragging out this old warhorse yet
one more time, but I believe that using essentially the same example in a variety of different topics and publications
can help, not hinder, learning.) Sample values are shown in Fig. 1.1.
3
To elaborate:
Suppliers:
Relvar
S denotes suppliers.
4
Each supplier has one supplier number (SNO), unique to that
supplier; one name (SNAME), not necessarily unique (though the SNAME values in Fig. 1.1 do happen to be
unique); one status value (STATUS), representing some kind of ranking or preference level among suppliers;
and one location (CITY).
3
For reasons that will become clear later, the values shown in Fig. 1.1 differ in two small respects from those in other topics of mine: The status
for supplier S2 is shown as 30 instead of 10, and the city for part P3 is shown as Paris instead of Oslo.
4
If you don't know what a relvar is, for now you can just take it to be a table in the usual database sense. See Chapter 2 for further explanation.
