Subject | Re: [firebird-support] (term 'relation') |
---|---|
Author | Geoff Worboys |
Post date | 2005-06-18T12:38:13Z |
...
"sound mathematical theory" is not necessarily practical in
the world we currently operate.
Most SQL client/server systems try to claim themselves to
be "Relational databases", but in fact rarely meet the rather
stringent requirement of the mathematics - as is so often the
case, pure theory has trouble when it meets the real world.
To see why most existing SQL systems fail to meet the
requirements of "Relational databases" take a look at the
writings of the self-proclaimed experts Pascal and Date at:
www.dbdebunk.com (and then take my advice and forget most of
it. :-)
Perhaps when the starship Enterprise is sailing the heavens we
will have the computer resources to handle relational databases
in their pure mathematical form. (Basically what we have done
so far: create huge computing resources and then waste them by
trying to run Windows. In the future we can have even larger
resources and waste them by trying to implement data models as
mathematical sets.)
Note also that the term "relation", even in the mathematical
sense, is first and foremost about relationships between data.
In maths the term derives from the subset of the product of
two sets - effectively the relationship between the sets. The
fact that various theorists have stretched this basic and
perfectly understandable use of the term into areas where no
person with any sense would try to take it... what can I say?
The basic concept (relationships between data) is enough to
allow practical implementations to be created without strict
adherence to the maths. Most SQL implementations are an
attempt at such compromises - and other implementations have
achieved results (databases expressing relationships) without
touching on set theory. Often such compromises are denigrated
by people such as mentioned above as not being "relational" in
the mathematical sense. The fact that they actually work for
real applications seems to be missing the point!
My apologies for a slightly off topic post. The explanation
for the terminology is well placed and this is not a criticism
of that post. Rather it is a warning that acceptance of the
history of the terminology should not be taken as acceptance
that everything from that history constitutes ideal database
design.
--
Geoff Worboys
Telesis Computing
> So, why use those terms? They're more correct, they remind us...
> that relational databases (unlike certain other types) are
> grounded in sound mathematical theory (set, predicate theory)
"sound mathematical theory" is not necessarily practical in
the world we currently operate.
Most SQL client/server systems try to claim themselves to
be "Relational databases", but in fact rarely meet the rather
stringent requirement of the mathematics - as is so often the
case, pure theory has trouble when it meets the real world.
To see why most existing SQL systems fail to meet the
requirements of "Relational databases" take a look at the
writings of the self-proclaimed experts Pascal and Date at:
www.dbdebunk.com (and then take my advice and forget most of
it. :-)
Perhaps when the starship Enterprise is sailing the heavens we
will have the computer resources to handle relational databases
in their pure mathematical form. (Basically what we have done
so far: create huge computing resources and then waste them by
trying to run Windows. In the future we can have even larger
resources and waste them by trying to implement data models as
mathematical sets.)
Note also that the term "relation", even in the mathematical
sense, is first and foremost about relationships between data.
In maths the term derives from the subset of the product of
two sets - effectively the relationship between the sets. The
fact that various theorists have stretched this basic and
perfectly understandable use of the term into areas where no
person with any sense would try to take it... what can I say?
The basic concept (relationships between data) is enough to
allow practical implementations to be created without strict
adherence to the maths. Most SQL implementations are an
attempt at such compromises - and other implementations have
achieved results (databases expressing relationships) without
touching on set theory. Often such compromises are denigrated
by people such as mentioned above as not being "relational" in
the mathematical sense. The fact that they actually work for
real applications seems to be missing the point!
My apologies for a slightly off topic post. The explanation
for the terminology is well placed and this is not a criticism
of that post. Rather it is a warning that acceptance of the
history of the terminology should not be taken as acceptance
that everything from that history constitutes ideal database
design.
--
Geoff Worboys
Telesis Computing