From: EG
To: Editor
Your site is great. Lots of logic and no technology it's very
rare today. Usual situation is quite the contrary.
I am a program developer and independent author from Russia.
I'm sorry for my English. I'll try to be brief. I would ask a question
concerning THE THIRD MANIFESTO. Speaking about values that can belong to
a domain, Chris Date says, that "...there's absolutely nothing in the
relational model that requires them to be limited to simple forms"
In other words, object being encapsulated attribute of a
tuple can have arbitrary structure [sic]. But how such a complex object itself
should be stored in a system? Does it mean that object storage, being
non-relational system, must exist anyway? How does this proposition agree with
the fundamental principle of the relational model "All information in the
database must be cast explicitly in terms of values in relations and in no
other way" (from Persistence Not Orthogonal to Type)?
Editor Comment: My
advice is to stay away from object terminology and concepts- they are fuzzy and
problematic when it comes to database management. They confuse the logical and
physical levels--a characteristic of object thinking. The relational model is
purely logical and has absolutely nothing to do with storage! What Date means
is that any values can be represented by a RDBMS, no matter how
complex the representation (e.g. domains can be relation-based). A
relational domain is a data type of arbitrary complexity (see Chapter 1
in my PRACTICAL
ISSUES IN DATABASE MANAGEMENT].
Chris Date Responds: In his response Fabian Pascal
said in part: "[You are confusing] the logical and physical levels ... The
relational model is purely logical and has absolutely nothing to do with
storage!" These remarks of Fabian's are 100 percent correct, of
course. Unfortunately, Fabian went on to say this: "What Date means is
that any atomic values can be represented by a RDBMS, no matter how
complex the representation (e.g., domains can be relation-based)."
Please delete the word atomic here! It has no precise
definition. What I claim (and have claimed ever since about 1992, when I first
realized that to talk in terms of this fuzzy "atomicity" concept was
misleading and counterproductive) is that if A is some attribute of some
relation R, then A can be defined in terms of absolutely any
type (or domain, if you prefer) whatsoever. So you can have attributes
whose values are integers, attributes whose values are strings, attributes
whose values are polygons, attributes whose values are arrays, attributes whose
values are relations, ... and on and on. Of course, it's crucial (as Fabian
suggests) that we make a distinction between values of any given type, on the
one hand, and the representation of those values under the covers, on
the other -- but the idea that these two concepts should be kept rigidly apart
isn't one that's peculiar to the relational world.
Editor Comment:
Chris is correct that atomicity is not a precisely definable property.
Nevertheless, I find it useful in conveying informally the notion that
values can have an arbitrarily complex internal structure, as long as the DBMS--not
the user!--can (and is made to) understand what valid values are and has
applicable operators for them.
Posted
05/03/02
[ABOUT]
[QUOTES]
[LINKS]
