Okay. Let's explain where I'm coming from. You've seen me going on about
"evidence" and "science" etc etc. So I'm going to drag science into
this, Newtonian Mechanics, to be precise (of course).
Newton came up with these philosophical concepts called "mass",
"energy", "space" and "time". On these, he built his (fairly) simple
consistent model. And then Einstein came along and said he'd got his
fundamentals wrong - mass and energy were the same thing, and space and
time were the same thing. And because Newton didn't take the fact that
these things were interchangeable, his model didn't work when compared
to reality.
Okay. So what is "data". Because if we can't anchor that in the real
world, we have no way of knowing if, or how strongly, relational theory
is relevant (and usable) in the real world.
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
> Newton came up with these philosophical concepts called "mass",
> "energy", "space" and "time". On these, he built his (fairly) simple
> consistent model. And then Einstein came along and said he'd got his
> fundamentals wrong - mass and energy were the same thing, and space
> and time were the same thing. And because Newton didn't take the
> fact that these things were interchangeable, his model didn't work
> when compared to reality.
Nice story. But irrelevant.
> Okay. So what is "data". Because if we can't anchor that in the real
> world, we have no way of knowing if, or how strongly, relational
> theory is relevant (and usable) in the real world.
So you are suggesting Newton wasn't (and isn't) relevant in
the real world? Or are you just trying to be smart?
Now, it is a nice thing to be smart. But remember it is not
everyday we face situations where Relativity is relevant and usable in
the real world... in everyday life Newtonian physics are quite useful,
and unless you are in some limit situation relevant -- and much
simpler than The Real Thing.
--
Leandro Guimarães Faria Corsetti Dutra +55 (11) 5685 2219
Av Sgto Geraldo Santana, 1100 6/71 +55 (11) 5686 9607
04.674-000 São Paulo, SP BRASIL
http://br.geocities.com./lgcdutra/
"Anthony W. Youngman" <w...@thewolery.demon.co.uk> wrote in message
news:o6Qd1REv...@thewolery.demon.co.uk...
> Okay. So what is "data". Because if we can't anchor that in the real
> world, we have no way of knowing if, or how strongly, relational theory
> is relevant (and usable) in the real world.
Data:
----------
1. facts
2. encoded information
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.usenet.com
Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Leandro Guimaraes Faria Corsetti Dutra" <lea...@dutra.fastmail.fm> wrote
in message news:pan.2004.05.14....@dutra.fastmail.fm...
> Em Fri, 14 May 2004 00:44:47 +0100, Anthony W. Youngman escreveu:
>
> > Newton came up with these philosophical concepts called "mass",
> > "energy", "space" and "time". On these, he built his (fairly) simple
> > consistent model. And then Einstein came along and said he'd got his
> > fundamentals wrong - mass and energy were the same thing, and space
> > and time were the same thing. And because Newton didn't take the
> > fact that these things were interchangeable, his model didn't work
> > when compared to reality.
>
> Nice story. But irrelevant.
>
>
> > Okay. So what is "data". Because if we can't anchor that in the real
> > world, we have no way of knowing if, or how strongly, relational
> > theory is relevant (and usable) in the real world.
>
> So you are suggesting Newton wasn't (and isn't) relevant in
> the real world? Or are you just trying to be smart?
>
> Now, it is a nice thing to be smart. But remember it is not
> everyday we face situations where Relativity is relevant and usable in
> the real world... in everyday life Newtonian physics are quite useful,
> and unless you are in some limit situation relevant -- and much
> simpler than The Real Thing.
Anthony said because we work with data, we should know what data is.
He would want an answer to his question: "But what the heck IS data ?"
Of course this is a trivial question for you :-)
I remember Fabian Pascal started one of his seminars with several such
"trivial" questions.
Why you have not answered the question ?
I'd vote for adding this nice short, crisp definition of data to our
glossary. --dawn
"Dawn M. Wolthuis" <dw...@tincat-group.com> wrote in message
news:c82g2d$8ib$1...@news.netins.net...
Oops. I forgot one archaic meaning: FATE :-)
My 2.5 cents. :-)
--
Mike Nicewarner [TeamSybase]
http://www.datamodel.org
mike@nospam!datamodel.org
Sybase product enhancement requests:
http://www.isug.com/cgi-bin/ISUG2/submit_enhancement
"Anthony W. Youngman" <w...@thewolery.demon.co.uk> wrote in message
news:o6Qd1REv...@thewolery.demon.co.uk...
Data: Known facts that can be recorded and have implicit meaning. [direct
quote]
Database: A logically coherent collection of related real-world data
assembled for a specific purpose. [rephrased]
See? It's not all that complicated. You are applying way too much GRAVITY to
your question.
"Anthony W. Youngman" <w...@thewolery.demon.co.uk> wrote in message
news:o6Qd1REv...@thewolery.demon.co.uk...
Given a minimum of third normal form:
An instantiated database contains stored information about a miniworld
(domain, if you like).
Information is represented by one or more tuples in one or more tables that
may or may not be joined to one or more other tables, or itself (a table).
Tables consist of tuples (rows). A tuple represents a piece of complete,
bounded, and finite information about the primary key.
The primarty key is a piece of discrete data, as is each attribute (column)
in the tuple (row).
Under ideal circumstances, the primary key is a piece of meaningful data
from the miniworld (sometimes it is necessary to create an artificial key,
but this is still a piece of discrete data. Sometimes the primary key is
made up of several attributes (composite key), but this is consistent for
each tuple. Although each attribute represents a discrete piece of data,
when combined into a composite key, the composite key is also a discrete
piece of data, but now contains more information. In chemistry, this would
be a "compound" made from several "elements".
Because the Primary Key is unique, and all attributes in a tuple are about
that key and nothing but the key, each tuple is complete, bounded, and
finite. If the tuple is complete, bounded, and finite, then each element of
the tuple (the attributes) must also be complete, bounded, and finite. The
attributes themselves do not contain "information" until the tuple is
realized.
Knowledge is realized by the examination of all of the information.
So, we have
data is contained in attributes
information is contained in tuples (which are made of attributes)
information is also contained in tables, which are really just many tuples
knowledge is contained in a database
It's not confusing at all if you don't want it to be.
"Relation" is a term from logical modeling and can be thought of as a
"superclass" term that encompasses "entities" and "relationships" and has no
place in this argument.
BTW, Time is not the 4th dimension of space. Space is expressed in three
dimensions. Time is another dimension for sure, but of something larger that
we can't yet identify. For now, we can say that space and time are
dimensions of the universe. Space is measured by three dimensions. The
universe is measured by the three dimesions of space plus the dimension of
time. Of course, there may be more dimensions.
"Anthony W. Youngman" <w...@thewolery.demon.co.uk> wrote in message
news:JrNFhKFb...@thewolery.demon.co.uk...
> In message <2gkdtnF...@uni-berlin.de>, Alan <al...@erols.com> writes
> >From "Fundamentals of Database Systems", Elmasri & Navathe [some direct
> >quote, some rephrased for brevity] :
> >
> >Data: Known facts that can be recorded and have implicit meaning. [direct
> >quote]
>
> Nice quote. But I'm being philosophical here. Mass, Energy, and Time are
> all (from Newton's standpoint) simple, immutable things. Space is as
> well, although it's slightly different, because it's three orthogonal
> instances of length.
>
> By these standards, "data" is woefully vague and undefined. And it's not
> even atomic! Within the theory it's chopped up into tuples, which are
> themselves chopped up into (I'm not into terminology here) keys,
> attributes, relations, and probably other stuff besides.
> >
> >Database: A logically coherent collection of related real-world data
> >assembled for a specific purpose. [rephrased]
>
> Given that "data" is so vague, how do we know it's related to the real
> world?
> >
> >See? It's not all that complicated. You are applying way too much GRAVITY
to
> >your question.
> >
> :-) But I'm looking for the TOE of data.
>
> We know Newton got it wrong. Energy and mass are the same thing. Time is
> merely a fourth dimension of space. But at least Newton had his
> philosophical anchors to the real world firmly in place, even if he knew
> something was wrong.
>
> "data" is not an anchor. It's a formless cloud. One fact may be "object
> X exists". Another may be "Person A is the mother of Person B". And
> again, "object Z is blue". Each of those is a different *type* of fact,
> a different "immutable object". And RDBMS theory lumps them all together
> in the amorphous philosophical concept of data, and then dismantles them
> inside the theory, despite the fact that they can't be dismantled in the
> real world.
>
> Just as we couldn't combine mass and energy and move them inside the
> theory until we realised that they were interchangeable - e=mc^2 - so we
> can't move "data" inside relational theory and deal with it there unless
> we have a rule that can transform one type of data into another. And
> until we have that rule, we need to treat the different types of data as
> external to the theory, and have a one-2-one mapping of those with
> reality.
> >
> Cheers,
> Wol
Tycho Brahe made years worth of very careful meticulous observations as to
the positions of the planets, at observed points in time. That's data.
Johannes Kepler studied Brahe's observations for years, and discovered that
the orbits of the planets were elliptical, with one focus at the sun. He
also discovered the "equal areas in equal times" rule for how fast they are
moving. That's analysis.
What Newton added were the laws of motion, and the law of gravitation.
That's physics.
All this talk about how "Newton got it wrong, and Einstein got it right"
is a bunch of claptrap. The people in this forum, for the most part, don't
know what they are talking about.
There are internal problems, at the cosmological level, with Newton's view
of the universe. But that's not what led Einstein to push the envelope
further. Physics was in crisis in the 19th century, due to results like
the Michelson-Morley experiment. That's more data.
It's data that Einstein had and Newton did not.
>>>Data:
>>>----------
>>>1. facts
>>>2. encoded information
>>
>>I'd vote for adding this nice short, crisp definition of data to our
>>glossary. --dawn
>
> Oops. I forgot one archaic meaning: FATE :-)
And the plural of datum (eng: date)?
So it should be:
[Data]
0. fate
1. facts
2. encoded information
3. dates
- except I think it doesn't help at all.
Maybe this is how the metadata modellers got to 900.
:-)
> In message <2gkdtnF...@uni-berlin.de>, Alan <al...@erols.com> writes
>
>> From "Fundamentals of Database Systems", Elmasri & Navathe [some direct
>> quote, some rephrased for brevity] :
>>
>> Data: Known facts that can be recorded and have implicit meaning. [direct
>> quote]
>
> Nice quote. But I'm being philosophical here. Mass, Energy, and Time are
> all (from Newton's standpoint) simple, immutable things. Space is as
> well, although it's slightly different, because it's three orthogonal
> instances of length.
>
> By these standards, "data" is woefully vague and undefined.
The recording of a mass, or of the energy of an object, or the time at
which an event was perceived to occur, or any of a myriad other
things, could be data. So, data encompasses all of the things you
mention and many other things too.
> And it's not
> even atomic! Within the theory it's chopped up into tuples, which are
> themselves chopped up into (I'm not into terminology here) keys,
> attributes, relations, and probably other stuff besides.
Hmmm - that's an odd set of comments. Data generally are atomic
facts. The way I'd view it is that a tuple is composed of individual
pieces of data. And tuples are certainly not chopped up into
relations. Attributes within a tuple contain 'atomic facts' (though
when you get into sub-structures such as relation-valued attributes,
the definition of atomic is more complex). Keys are properties of
relations, etc. My goodness me, that paragraph is so confused as to
be close to meaningless - and what meaning there is is almost all
completely antithetical to the theory behind a RDBMS, which is what
the subject of the thread is discussing.
--
Jonathan Leffler #include <disclaimer.h>
Email: jlef...@earthlink.net, jlef...@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
True. For the most point our expertise, if any, is in databases not
physics. But some people just can't help bringing their secondary
school-level knowledge of physics into every topic for some reason
(not that I'm claiming to have any more than that myself). It is very
tiresome.
...[trim sci.physics thread] ...
> Okay. So what is "data". Because if we can't anchor that in the real
> world, we have no way of knowing if, or how strongly, relational theory
> is relevant (and usable) in the real world.
Relational theory is useful and relevant. For the people
who are database academics, database technical, indeed
anything database-centric, the theory is generally all they
need and require to do what they do (within E2 below)
There are 3 software environments:
E1 = Operating system and network os layer
E2 = RDBMS layer
E3 = application layer
The "data" is bound within E2, and although is operated
on within E2 (hopefully in accordance with the RM), the
ultimate control for these operations are from the end user
within an organisation, via the app layer (E3). (GIGO)
However in the real world the data within the RDBMS is
in fact owned by an organisation, not by the RDBMS vendor,
nor the application vendor/developer, nor the RM, and
in reality only has meaningful context for that organisation,
at that instant in space & time. (production data backup)
[An aside: now I can see where the physics thread may
have become self-emergent ;-]
The RM does not reflect the actuality of the above, nor
make any provision for the management of the E3 layer
because it is not yet completely evolved.
The catch-cry "the RM is just as applicable to database
systems today, as it was in the early 1980's" should be
taken as an indication that something is wrong with it as
a pedagogic device for 2004.
The reason for this is that E2 and E3 have changed alot
since 1980, particularly E2, the RDBMS software. Due
to the emergence of addressable stored procedures in
the RDBMS, there has been an effective "migration" of
intelligence (code) from E3 to E2.
The boundaries between E2 and E3 are now probably
best described as fractal, whereas in the past they were
heavily demarked.
Back to your question on the "data". It is physically
anchored by a backup, and theoretically anchored by
the database schema, constraints, etc. from the perspective
of the (incomplete) RM.
However in practice, it is a dynamic fluid element that
must be managed, with the assistance of, but also outside
the realm of the present applicability of the RM.
Change management is the name given to the bag that holds
together everything that falls through the cracks of theory
and out into the world of practice.
Pete Brown
Falls Creek
Oz
"Anthony W. Youngman" <w...@thewolery.demon.co.uk> wrote in message
> Okay. So what is "data". Because if we can't anchor that in the real
> world, we have no way of knowing if, or how strongly, relational theory
> is relevant (and usable) in the real world.
Anything that can be reduced to an electrical impulse? :-)
Bill
Thanks, X.
I take it Leandro is parading his ignorance, rather than seeking
enlightenment.
But I'll try to enlighten him, anyway. We now know that mass as it
really is, and mass as it is defined in Newton's model, aren't quite the
same thing. Therefore, as Leandro says, we know that Newtonian
Mechanics, for the most part, works, and we also know where it doesn't
work.
But *I* don't know what "data" is "as it really is", and from the
answers I've got so far I don't think anybody else does. The best
definition so far is for data as it is defined in the relational model
(and that's pretty much the only proper definition anybody's tried to
give).
And if we haven't got a philosophical definition, we can't compare the
philosophical and theoretical definitions, and therefore we haven't got
a clue as to whether either "the relational model mostly works", or (and
this is important) where its limitations are and where it breaks down.
Well, I would say Newton got it wrong, and I do know what I'm talking
about, and I know I'm right :-)
>
>There are internal problems, at the cosmological level, with Newton's view
>of the universe. But that's not what led Einstein to push the envelope
>further. Physics was in crisis in the 19th century, due to results like
>the Michelson-Morley experiment. That's more data.
>
>It's data that Einstein had and Newton did not.
Except Newton DID have data that told him he was wrong. And he spent
pretty much the rest of his life trying to work out why his theory
didn't work completely.
Fundamental to Newtonian Mechanics is the conservation of mass - it
cannot be created or destroyed. To Newton, this seemed obvious. To us,
well, we know he got it wrong - we know the rule is that mass-energy is
conserved, and that mass CAN be created and destroyed.
Mercury's orbit is relativistic, not classical. Try as he might, Newton
just could not get his calculations and Tycho's data to agree.
Einstein just had a couple of insights that Newton didn't, due quite
likely as you say to Michelson-Morley amongst other things. More data
always does make life easier :-) and the data he had led him to suspect
that the law of conservation of mass might actually be wrong ... the
rest as they say is history ... (there's a nice story of the same sort
of thing happening to Dick Feynman :-)
And some of us like bringing our 3rd-year undergrad Physics knowledge
(from a top-5 Uni) into it, too :-)
It's just that I find Newtonian mechanics an excellent analogy. To
express it in computerese, both Newtonian Mechanics and Relational
Theory are instances of the class Mathematical_Theory. BOTH are
mathematically perfect (well, I know Newtonian Mechanics is).
I just find it fascinating that, while we know that Newtonian Mechanics
doesn't belong in the set Accurately_Matches_The_Real_World, so many
people here (on the grounds of it's mathematical correctness) seem to
believe that relational theory does. That argument just doesn't make
sense to me.
> x writes:
...
>> Why you have not answered the question ?
...
> But *I* don't know what "data" is "as it really is", and from the
> answers I've got so far I don't think anybody else does. The best
> definition so far is for data as it is defined in the relational model
> (and that's pretty much the only proper definition anybody's tried to
> give).
>
> And if we haven't got a philosophical definition, we can't compare the
> philosophical and theoretical definitions, and therefore we haven't got
> a clue as to whether either "the relational model mostly works", or (and
> this is important) where its limitations are and where it breaks down.
I won't answer the original question either (I'll just rephrase it),
but I will share some thoughts about just what "data" means.
Just a few associated concepts I have used to have some
grasp of this - a semantical network, if you will.
I have no sources or proofs, no famous
philosofer to refer you to.
The network roughly consists of: sign, media, shape and meaning.
We have signs. They serve to communicate.
Signs: A handshake, a hieroglyph, an ideogram (e.g. a chinese
character), a sonogram (roman, arab character), a facial expression,
a traffic light on red, an alarm - these are elementary, but
I would also include: the collected works
of <your favorite moviestar>
In order to (just) exist all of these signs have media and shape,
their pure existence does *not* require human (or just active)
interpretation to assign meaning to them. Their function (purpose, ie
communication), however *does* require some interpretation activity.
This combination of sign and meaning we call data.
To illustrate that this is not trivial:
Data (but not signs by themselves) can represent
other signs: I can write "The traffic light was red",
but they can also represent other data: "We stopped
because of the traffic light".
Aside: From here (sign and meaning) on "up" there is actually
a lot of philosofical work and practical research. Disciplines:
Semiotics, semiology and linguistics.
(Note: no computer needed)
Now, when we assign same or similar meanings to bitpatterns,
most of the time conviniently represented by the same shape
but evidently on another medium, we have computerdata,
data for short.
Finally, the rephrase of your question:
How does the type of DBMS affect what we consider data?
> x writes:
...
>> Why you have not answered the question ?
...
> But *I* don't know what "data" is "as it really is", and from the
> answers I've got so far I don't think anybody else does. The best
> definition so far is for data as it is defined in the relational model
> (and that's pretty much the only proper definition anybody's tried to
> give).
>
> And if we haven't got a philosophical definition, we can't compare the
> philosophical and theoretical definitions, and therefore we haven't got
> a clue as to whether either "the relational model mostly works", or (and
> this is important) where its limitations are and where it breaks down.
I won't answer the original question either (I'll just rephrase it),
but I will share some thoughts about just what "data" means.
Just a few associated concepts I have used to have some
grasp of this - a semantical network, if you will.
I have no sources or proofs, no famous
philosofer to refer you to.
The network roughly consists of: sign, media, shape and meaning.
We have signs. They serve to communicate.
Signs: A handshake, a hieroglyph, an ideogram (e.g. a chinese
character), a sonogram (roman, arab character), a facial expression,
a traffic light on red, an alarm - these are elementary, but
I would also include: the collected works
of <your favorite moviestar>
In order to (just) exist all of these signs have media and shape,
their pure existence does *not* require human (or just active)
interpretation. Their function (purpose, ie
communication), however *does* require some
interpretation activity to assign meaning to them.
This combination of sign and meaning we call data.
To illustrate that this is not trivial:
Data (but not signs by themselves) can represent
other signs: I can write "The traffic light was red",
but they can also represent other data: "We stopped
because of the traffic light".
Aside: From here (sign and meaning) on "up" (towards
information, knowledge, insight, wisdom, action, ...)
Keep in mind that the vast majority of mercury's precession is explainable,
in classical Newtonian mechanics, by the gravitational attraction of the
other planets.
In the timelines I've seen, the observation of 35 arcseconds per century of
excess precession of Mercury was attributed to an observation in 1845 by
Leverrier. It was further corrected to an excess of 43 arcseconds per
century by Newcomb in 1882.
Before Einstein, the excess precession of Mercury was attributed to a
hitherto unknown (and, it turns out nonexistent) planet inside the orbit of
mercury, to which they gave the name "Vulcan". (Live long and prosper).
But the descriptions of the amount of time for which you need observations
of Mercury to obtain these findings are very long. So long that I find it
doubtful that Tycho could have observed for long enough for his data to
detect the Einsteinian precession.
As far as Newton refining and cross checking his work, and seeking to verify
or falsify it down to the last epsilon (so to speak), I find that very easy
to believe. In fact, his own assessment of his work is that he felt like a
little child, playing with the shells on the seashore, while the vast ocean
of truth lay undiscovered before him. And Einstein, when asked to comment
on Newton's work, said that his own work would have been impossible without
Newton's earlier work.
Those people in this forum who seem to have every human gift except
humility might do well to learn from such people as Newton and Einstein.
>It's just that I find Newtonian mechanics an excellent analogy. To
>express it in computerese, both Newtonian Mechanics and Relational
>Theory are instances of the class Mathematical_Theory.
You never learn. Newtonian Mechanics are not mathematical theory, they
are physics. They are derived from the observation of the physical
world phenomenons.
>I just find it fascinating that, while we know that Newtonian Mechanics
>doesn't belong in the set Accurately_Matches_The_Real_World
False. Newtonian Mechanics matches the physical world very accurately
in many circumstances and in almost every practical circumstance. They
are extremely useful.
If we compare The Relational Model with Newtonian Mechanics, then the
Pick approach should be compared with troglodite superstition.
>There are 3 software environments:
>E1 = Operating system and network os layer
>E2 = RDBMS layer
>E3 = application layer
>The RM does not reflect the actuality of the above, nor
>make any provision for the management of the E3 layer
>because it is not yet completely evolved.
No, the application layer is what must be adapted to the RM and not
the contrary. What is not evolved is the application layer.
>The catch-cry "the RM is just as applicable to database
>systems today, as it was in the early 1980's" should be
>taken as an indication that something is wrong with it as
>a pedagogic device for 2004.
There are many things wrong in the application layer. For instance the
application programming languages.
>The reason for this is that E2 and E3 have changed alot
>since 1980, particularly E2, the RDBMS software. Due
>to the emergence of addressable stored procedures in
>the RDBMS
But complete RDBMS's still don't exist.
>, there has been an effective "migration" of
>intelligence (code) from E3 to E2.
But not enough, and in the last years we are seeing a regression. A
migration of business logic from SQL DBMS's to the crappy "Application
Servers".
Regards
Alfredo
While I have no knowledge related to Newtonian Mechanics, I can agree with
your comparison when it comes to applying Mathematical theories. There are
folks who think that Mathematics, like science, is a discipline of
discovery. Others, like me, believe it to be a creative act -- our use of
the logic in our brains to propose axioms and then draw logical conclusions
from those. We create Mathematics, sometimes in order to address the real
world (counting sheep, for example) and sometimes without such a trigger in
nature. Mathematical errors can be found by proving new theorems or showing
where previous proofs were incorrect. There is no need to talk about
anything in the real world in order to talk about such Mathematics. Folks
on this list who want to discuss "relational theory" as strictly a
Mathematical theory are correct in suggesting that my questions, pretty much
all of them, are outside of the scope of such a theory and would, therefore,
we unwelcoming of such in this forum.
If we have such a mathematical theory we can "apply it". That act is a
scientific one and one that can easily be done poorly. The application of
Mathematics is like the application of a metaphor (I know, I know, I've said
that many times before) where the Mathematics will fit some aspects of our
target domain and possibly not fit others. While it might lay down
perfectly on top of its target application, it is likely there will be many
areas physically related to the domain for which the Mathematical theory is
irrelevant. For example, with the counting of sheep, we can apply the set
of Integers with some basic arithimetic functions and we can get the
counting right. But that will not tell us what to do if one sheep is
missing. Such a question would be orthogonal to the "Counting Theory" that
so many shepards are into. A shepherd who is immersed only in such a theory
could lose their entire flock while sticking to the truth of their theory,
convinced that if they only study it more and learn more about it, they will
solve this problem too. That is why "sheep herding theory" is not the same
as "counting theory".
My interest is in helping Little Bo Peep as well as the owner of those
sheep. I'm curious about why when she took a course in college about
shepherding, most of the time was spent talking about counting them, which
didn't actually help her much when she got to the "real world". That is why
I do not feel guilty about bringing up issues about databases in a database
theory newsgroup. If this were a "relational theory" newsgroup where the
goal were to push the edges of a Mathematical theory without interest in
whether this theory were useful to databases or in what way it might be
useful or not, that would be a different discussion.
Cheers! --dawn
I am suitably impressed and humbled... ;-)
> It's just that I find Newtonian mechanics an excellent analogy. To
> express it in computerese, both Newtonian Mechanics and Relational
> Theory are instances of the class Mathematical_Theory. BOTH are
> mathematically perfect (well, I know Newtonian Mechanics is).
>
> I just find it fascinating that, while we know that Newtonian Mechanics
> doesn't belong in the set Accurately_Matches_The_Real_World, so many
> people here (on the grounds of it's mathematical correctness) seem to
> believe that relational theory does. That argument just doesn't make
> sense to me.
You keep saying that (on and on, tediously...) but it just doesn't
work, does it? After all, didn't NASA put a man on the moon using
Newtonian Mechanics? Expensive and complex successful experiments
have been done to observe the effects of relativity, but it hardly
impacts on the real world as lived in by us humans does it? If your
analogy holds any water at all (to give you the benefit of very large
doubt), it suggests that relational theory will do just fine for
pretty much anything we ever want to do "in the real world".
> ...Newtonian Mechanics matches the physical world very accurately
> in many circumstances and in almost every practical circumstance. They
> are extremely useful.
>
> If we compare The Relational Model with Newtonian Mechanics, then the
> Pick approach should be compared with troglodite superstition.
I'm surprised at seeing such a miscomparison. Maybe I shouldn't be. :-)
Bill
Perhaps more to the point, Newtonian Mechanics is an attempt (accurate
or not) to model "how the world works". By contrast, database theory
(any database theory) is merely trying to come up with the best way to
computerize book-keeping. The two are hardly comparable endeavours,
are they?
Demonstrated here is the entire application layer contained
in the RDBMS software. Zero apps on clients:
http://www.mountainman.com.au/software/southwind
This uses stored procedures, which are DBMS objects.
These objects have functional relationships to the data
structures and the data structures have an evolving
structure via the objects. All is heavily inter-related
and unified within the database system.
But the RM in its present state cannot reference this
other-side-of-the-coin object data. It should be able to
in the future, perhaps.
> >The catch-cry "the RM is just as applicable to database
> >systems today, as it was in the early 1980's" should be
> >taken as an indication that something is wrong with it as
> >a pedagogic device for 2004.
>
> There are many things wrong in the application layer. For instance the
> application programming languages.
>
> >The reason for this is that E2 and E3 have changed alot
> >since 1980, particularly E2, the RDBMS software. Due
> >to the emergence of addressable stored procedures in
> >the RDBMS
>
> But complete RDBMS's still don't exist.
Machines using the basic "un-blessed" principles of the RM
have only been around for 25 years. These are good enough
for me, because they (especially the more recent ones) do
actually incorporate *much* of the basics of the RM.
> >, there has been an effective "migration" of
> >intelligence (code) from E3 to E2.
>
> But not enough,
Then you do agree that there exists (object) "data"
within the SQL DBMS's that is unable to be referenced
by the relational model of "data"?
> and in the last years we are seeing a regression. A
> migration of business logic from SQL DBMS's to the crappy "Application
> Servers".
What do you think are the major elements behind this
migration to these (I actually agree with your here) crappy
"Apps boxes"? I used to suspect they were "caused by bad
apps".
> I take it Leandro is parading his ignorance, rather than seeking
> enlightenment.
If you had any to offer...
> But *I* don't know what "data" is "as it really is", and from the
> answers I've got so far I don't think anybody else does.
As far as I remember my Philosophy, that's where English
Objectivists -- that's not their real name, I forget it -- went wrong.
They wanted to start from data, and couldn't define that.
That's the other reason for my not answering the original
question -- there is no answer, other than the trivial -- and useless --
ones already given. The other reason, it's irrelevant to our discussions
here.
> The best definition so far is for data as it is defined in the
> relational model (and that's pretty much the only proper definition
> anybody's tried to give).
Which definition, in which version of whose version of it?
> And if we haven't got a philosophical definition, we can't compare the
> philosophical and theoretical definitions, and therefore we haven't got
> a clue as to whether either "the relational model mostly works", or (and
> this is important) where its limitations are and where it breaks down.
It would be more interesting to compare not to a non-existing,
non-achievable philosophical definition, but to misunderstanding. Like the
differentiation of data and metadata.
--
Leandro Guimarães Faria Corsetti Dutra +55 (11) 5685 2219
Av Sgto Geraldo Santana, 1100 6/71 +55 (11) 5686 9607
04.674-000 São Paulo, SP BRASIL
http://br.geocities.com./lgcdutra/
I think you need to read up - and fast!
If NASA had used Newtonian Mechanics, from what I know, the astronauts
would never have come back.
Even under such "near earth" conditions as that, the discrepancy between
Newtonian Mechanics and Relativity would have been enough to ensure the
rockets ran out of fuel, stranding the astronauts in space.
We're talking velocities of 7 miles a second here, more than fast enough
for relativity to make itself felt. That's roughly c*10^-5 - not small
beer. Actually - it looks like we probably need relativity even with the
Shuttle!
But both are attempts to apply a mathematical model to a real world
problem. Viewed from a dispassionate oversight, both are instances of
the SAME problem, and the same techniques can be applied to solving
them. Namely "how well does my mathematical model work in the real
world?".
Now let's go back to "The Philosophy of Science" :-) and Newton :-) For
my first attempt at a Masters, practically the first thing we did was
"The philosophy of Science". And, helped by both students and a lecturer
who didn't have a clue (the student extrapolated a line from the origin,
through an asymptote, to a random position in number-space, and then
used this to ridicule the theory he didn't like. And the lecturer said
"good argument" !?!?!? )
I'm going to start saying "metaphysics" instead of philosophy here - I
think it's a subset of philosophy, and a better word to use, but as you
can see, I'm really getting into territory I don't understand ...
Anyway. Newtonian Mechanics is a self-contained, consistent,
mathematical theory. It relies on the concepts (call them "axioms") of
mass, energy, space, and time (and maybe more). We can define mass in
mathematical terms as "F=ma, where mass m is the constant property
describing the resistance of an object to a change in its velocity".
Likewise, space "is a co-ordinate system with distance measured in
metres along three mutually perpendicular axes". I won't attempt to
define energy or time ...
But just as those four concepts have neat, clean, mathematical
definitions they also have messy real world definitions. Mass can be
defined as "my god it's heavy", or "come on! PUSH!". Space is "where are
you?" or "I'm here, you're there".
Metaphysics is, I believe, the attempt to clarify both the real-world
definitions and the mathematical definitions, and to try to make sure
that they are describing the same thing. This is why, despite knowing
that Newtonian Mechanics is wrong, we find it so useful. We know the two
definitions don't match, we know WHERE they don't match, and we can
predict with certainty that where the discrepancy is minimal, Newtonian
Mechanics will give us a suitably accurate answer.
Now I'm going to get into the difference between "relational theory" and
"relational database theory" :-) Another analogy coming up - Linux and
microkernels :-) Linus realised that all this research into "Microkernel
Operating Systems" was actually just as applicable to "Operating
Systems". I'm putting peoples' noses out of joint because, whether they
realise it or not, they believe in "relational database theory" (think
Tanenbaum saying he'd give Linus an F :-) And yet, I keep on saying Pick
data should be normalised! So I'm actually very pro relational theory
(just leave relational databases out of it! :-)
Now here comes the crunch. As I see it, in relational *database* theory,
the concept of "data" lies on this metaphysical boundary. And this is
why I view every relational database I've ever seen as a tangled mess of
spaghetti. What the hell is "data"! What's the real world equivalent?
Like any true mathematician :-) the relational database theorists seem
to be saying "metaphysics? that's not our problem. That's just an
implementation detail!". Except that, going back to Newton, the fact
that energy and mass are interchangeable and, as such, the equation
"F=ma where m is a constant" isn't true, isn't an "implementation
detail". Well, to God it may be, but it certainly isn't to us!
Going to another thread, where Lauri asked what were the advantages of
Pick, I'd say that one of them is a very clear metaphysical interface.
To compare Pick and Relational Database Theory ...
A Pick FILE is a real-world collective noun. What's a relational table?
A Pick RECORD is a real-world object. What's a relational row? A noun?
An adjective? A gerund? (relation, for those who don't know their
grammar)
A Pick FIELD is a real-world adjective. What's a relational column? An
adjective? A gerund?
Because Pick's metaphysical layer is at a higher level than Relational
Database Theory, we can then implement relational theory WITHIN our
model without having the nasty spaghetti of a vague and undefined
real-world interface. And I can righteously and reasonably throw my
hands up in horror and tear my hair out when presented with a Pick
database that hasn't been normalised :-)
So. Can anyone come up with a clear, simple, and NON-VAGUE definition of
what "data" means when specified in a real-world, not a mathematical,
context. Or come up with a perfectly good reason of why you don't have
to! (Basically, because you've done it somewhere else, because you've
got to do it somewhere!)
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
The society which scorns excellence in plumbing because plumbing is a humble
activity, and tolerates shoddiness in philosophy because it is an exalted
activity, will have neither good plumbing nor good philosophy. Neither its
pipes nor its theories will hold water. John W Gardner
This wasn't the crux of your post, Wol, but just a minor point that
relational theorist take all of the functional dependency normal forms and
state at the front of each that the data must FIRST be in FIRST NORMAL FORM
and some would state that the definition of normalization requires that the
data be in 1NF. So, while I accept normal forms that are based on
functional dependeny logic, I'm fine with keeping a list of valid e-mail
addresses together during this process. I don't want to put words in your
mouth, but when you are pro normalization, are you including 1NF in
hat? --dawn
"Anthony W. Youngman" <w...@thewolery.demon.co.uk> wrote in message
news:m24e2vGD...@thewolery.demon.co.uk...
I have read somewhere that in addition to mass, energy, space, and time
there is also information.
I'm not an expert, but I've heard the ADN is an example of this.
I've read that "information" show up in systems with cycles.
By accident, I've found this http://www.bkent.net/Doc/darxrp.htm
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.usenet.com
Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I will indeed read up - though don't worry, there is no real urgency:
I am not personally involved in putting men on the Moon.
> If NASA had used Newtonian Mechanics, from what I know, the astronauts
> would never have come back.
>
> Even under such "near earth" conditions as that, the discrepancy between
> Newtonian Mechanics and Relativity would have been enough to ensure the
> rockets ran out of fuel, stranding the astronauts in space.
>
> We're talking velocities of 7 miles a second here, more than fast enough
> for relativity to make itself felt. That's roughly c*10^-5 - not small
> beer. Actually - it looks like we probably need relativity even with the
> Shuttle!
Despite being no expert, I am pretty confident that you are completely
wrong here. 0.0000376 * c sounds pretty small to me. How much
discrepancy in fuel usage could that lead to - a millilitre even? I
bet whatever difference it makes is insignificant compared to other
more mundane factors such as the accuracy of measuring the rate of
fuel use, quality of fuel, etc.
But yes, I will do a little Googling to see if you are right. If I
had a hat, I'd be prepared to eat it if it turned out you were
correct.
>Machines using the basic "un-blessed" principles of the RM
>have only been around for 25 years. These are good enough
>for me, because they (especially the more recent ones) do
>actually incorporate *much* of the basics of the RM.
A truly RDBMS would be a lot better. Most of the everyday problems of
the database programmers are due to the flaws of the current DBMSs.
>> >, there has been an effective "migration" of
>> >intelligence (code) from E3 to E2.
>>
>> But not enough,
>
>Then you do agree that there exists (object) "data"
>within the SQL DBMS's that is unable to be referenced
>by the relational model of "data"?
No, I mean that most people does not know how to take advantage on the
few that SQL DBMS's offer.
> and in the last years we are seeing a regression. A
>> migration of business logic from SQL DBMS's to the crappy "Application
>> Servers".
>
>What do you think are the major elements behind this
>migration to these (I actually agree with your here) crappy
>"Apps boxes"? I used to suspect they were "caused by bad
>apps".
The key elements are ignorance and the flaws of SQL DBMS's
Regards
Alfredo
You are right, Tony. Your hat, if you had a hat, would be safe. The
divergence between Newtonian mechanics and Einsteinian mechanics for the
entire Apollo mission is less than the margin of error in the instruments on
board.
OTOH, the Apollo missions did carry a fair number of instruments to the
moon whose purpose was to capture data that would confirm or contradict
Einstein's predictions. AFAIK, Einstein is batting a thousand.
You actually don't have to go so far afield to find a connection between
Einstein's theories and everyday life. Some percentage (I don't know how
much) of Europe's electric energy is generated by nuclear plants. Inside
those plants, nuclear fission is the source of energy. And that energy
corresponds to the reduction of mass that results from the splitting of
certain kinds of nuclei.
The modeling of *what* of reality? Surely not all of it.
> There are many realities, but let me mention two; the reality of the
> current IT with implemented infrastructure and the worldview of a modern
> intellectual. Our interpretation of what's implemented in our (heads) is
> what we try to model in our toys. And by what we learnt this is nothing
> like mechanical wheels of a watch nor computer's random access memory
> and not even the relational database. The problem is in compressing the
> representation of data and easing the recall of that data.
Here you are speaking of data allready gathered, right?
> Here it
> becomes useful to know what data is, but for the current
> state of the art that has unfortunately already been settled.
Settled? I don't think the understanding of what we now call data
we has grown beyond the metaphore level yet (unlike for instance
our understanding of 'number' or 'motion').
>> In order to (just) exist all of these signs have media and shape,
>> their pure existence does *not* require human (or just active)
>> interpretation. Their function (purpose, ie
>> communication), however *does* require some
>> interpretation activity to assign meaning to them.
>
> That's what you think and if I'm ever your customer, you won't model it
> that way :) Seriously, I don't believe in _pure_ shits or that anything
> exists without being observed/interpreted, but I'll not go deeper as it
> may look like off-topic religion bashing.
Watch out, cats! :-)
>> This combination of sign and meaning we call data.
>
> I'd say fixation of this on a media is called data, couse otherwise you
> can't recall it later. And there is a very important thing that folks
> miss: if you vanish and nobody knows the way you fixed that data there's
> just (series of ones and zeros) without meaning. Thus a fixation can't
> be generally called data without known way to interpret it.
Although this suggests you have a way around Shroedingers cat
whithout reverting to 'purity' or 'essence' etc...
(and I don't) we do agree on that. Do you have an idea
*why* folks miss this?
> mAsterdam writes:
<major chomp>
1. A contradictio in terminis.
2. A collection of similarly shaped utterances.
> A Pick RECORD is a real-world object. What's a relational row? A noun?
> An adjective? A gerund? (relation, for those who don't know their grammar)
1. A contradictio in terminis.
2. One utterance.
> A Pick FIELD is a real-world adjective. What's a relational column? An
> adjective? A gerund?
Mu.
You compare
P.FILE to S.TABLE,
P.RECORD to S.ROW and
P.FIELD to S.COLUMN.
What do we learn from this comparison? Nothing.
These terms are all taken out of the context where
they have meaning. One may just as well choose to
compare
P.FILE to S.SCHEMA,
P.RECORD to S.VIEW and
P.FIELD to S.TABLE
- it doesn't mean anything.
It is out of context.
> Because Pick's metaphysical layer is at a higher level
That depends on which terms you compare from one realm to which other
terms from the other. It's your pick. (sorry :-)
> than Relational
> Database Theory, we can then implement relational theory WITHIN our
> model without having the nasty spaghetti of a vague and undefined
> real-world interface. And I can righteously and reasonably throw my
> hands up in horror and tear my hair out when presented with a Pick
> database that hasn't been normalised :-)
Yup. That even goes for very old fixed record batch processing.
> So. Can anyone come up with a clear, simple, and NON-VAGUE definition of
> what "data" means when specified in a real-world, not a mathematical,
> context. Or come up with a perfectly good reason of why you don't have
> to! (Basically, because you've done it somewhere else, because you've
> got to do it somewhere!)
Yup. It seems most people prefer to have that done
implicitely or at least by someone else.
As little as possible to solve the case, I don't see the problem here.
>> Here it becomes useful to know what data is, but for the current state
>> of the art that has unfortunately already been settled.
>
> Settled? I don't think the understanding of what we now call data
> we has grown beyond the metaphore level yet (unlike for instance
> our understanding of 'number' or 'motion').
Computers can mostly only work with data that's captured as a sequence
of bits. 17th century philosophers made the model, 20th century computer
scientist implemented it and I don't see how you could escape that now.
And most people here have clients with limited resources and strong
competition and there's very, very little margin for experimentation.
>>> This combination of sign and meaning we call data.
>>
>> I'd say fixation of this on a media is called data, couse otherwise
>> you can't recall it later. And there is a very important thing that
>> folks miss: if you vanish and nobody knows the way you fixed that data
>> there's just (series of ones and zeros) without meaning. Thus a
>> fixation can't be generally called data without known way to interpret
>> it.
>
> Although this suggests you have a way around Shroedingers cat
> whithout reverting to 'purity' or 'essence' etc...
> (and I don't) we do agree on that. Do you have an idea
> *why* folks miss this?
We were learnt that way, now we're trying to adapt to the world as we
see it.
Regards,
Karel Miklav
But you're missing an important point, namely, Newtownian mechanics
incorporates into it distinct physical concepts such as mass, distance, and
time. Relational theory does not. This is why we can't set up some
experiment to test "relational theory" as such against the real world and
see what happens: only by creating a specific schema which links together
machine-readable definitions of relations and constraints and the semantic
import of those relations can we try and test relational theory, or any
other general theory of data modelling, against the real world.
To put it another way, relational theory is analogous to the equation for a
Gaussian distribution, f(x) = ae^(-bx^2). Were I to assert that Gaussian
distributions are useful in describing scientific phenomena, you might ask
me for a test; and what are f, a, b, and x? And when I tell you that it
depends on the phenomenon we are trying to describe, and that f, a, b, and x
can be many different things, you might mistake it to be of no practical
value, as it makes no verifiable predictions. But if I were to substitute
for f C, the concentration, for a C0/sqrt(4piDt), for b 1/4Dt, and
proclaimed x to be distance, I would have made use of a Gaussian
distribution to describe the process of diffusion, and it could be checked
experimentally and the predictions of the equation (Fick's Second Law)
verified. Only by giving a physical interpretation to the variables of the
Gaussian distribution does it become a scientifically verifiable theory; and
only by creating a schema which we associate with semantics are we able to
test the application of the relational model to our problems.
Having established that the relational model is an underlying mathematical
framework bound to reality by the "glue" of the schemas we create, we're on
better grounds to discuss the applicability of the model without premature
calls for "experiment". We know that data in the relational model is
formulated as logical propositions whose validity is evaluated by
first-order logic. Hence my tenative suggestion in a post here about a month
ago for examining alternatives to the relational model: are logical
propositions the best way to formulate data, and do we need more power than
first-order logic can bring us (and what trade-offs does that present)?
(Incidentally, can we agree that while consistency is not sufficient to
prove the correctness of a data model, it is necessary?)
--
Chris Hoess
I probably don't do the book justice just from a quick skim of the extract,
but I felt compelled to comment on one point of the extract. The author
claims, quite reasonably, that data models are artificial constructs and can
never completely represent the true nature of information, and goes on to
provide various philosophical examples of recategorization. While this will
doubtless stimulate discussion from many here, I think it may be a red
herring from a purely database perspective, in that these categories already
exist, to some degree, in the way information is handled. Databases don't
exist in vacuo; they're fed (and consulted) by users who would have some
system of mental categorization even if they were shuffling everything
around with paper and pencil. So while it may be philosophically
interesting, the questions raised may not impinge directly on
databases--except that we must recognize that the organization of data
within a database can and will change with circumstances, and the database
should provide facilities for changing this structure with minimum
inconvenience.
--
Chris Hoess
Well where is it?
> Most of the everyday problems of
> the database programmers are due to the flaws of the current DBMSs.
Not if you program in SQL from within the RDBMS.
> >> >, there has been an effective "migration" of
> >> >intelligence (code) from E3 to E2.
> >>
> >> But not enough,
> >
> >Then you do agree that there exists (object) "data"
> >within the SQL DBMS's that is unable to be referenced
> >by the relational model of "data"?
>
> No, I mean that most people does not know how to take advantage on the
> few that SQL DBMS's offer.
Well, that may certainly be true, but does not relate
to the applicability, or in this instance, the ineffectiveness
of the current RM to address this (object) data.
> > and in the last years we are seeing a regression. A
> >> migration of business logic from SQL DBMS's to the crappy "Application
> >> Servers".
> >
> >What do you think are the major elements behind this
> >migration to these (I actually agree with your here) crappy
> >"Apps boxes"? I used to suspect they were "caused by bad
> >apps".
>
> The key elements are ignorance and the flaws of SQL DBMS's
Either way, application servers are (usually) a step backwards.
My focus is building suites of application system components
as SQL stored procedures within the (R)DBMS to the extent
that there exists zero components external to the (R)DBMS.
The modern (R)DBMS environment is capable of
"internalising" the entire applications environment.
>> A truly RDBMS would be a lot better.
>
>Well where is it?
I hope it is in the near future.
>> Most of the everyday problems of
>> the database programmers are due to the flaws of the current DBMSs.
>
>Not if you program in SQL from within the RDBMS.
You suffer the problems specially if you program in SQL from within
the SQL DBMS.
See Date's writings about the SQL flaws.
>Well, that may certainly be true, but does not relate
>to the applicability, or in this instance, the ineffectiveness
>of the current RM to address this (object) data.
The RM supports objects. See The Third Manifesto.
>> The key elements are ignorance and the flaws of SQL DBMS's
>
>Either way, application servers are (usually) a step backwards.
Agreed. They are network DBMS's without an storage engine.
>My focus is building suites of application system components
>as SQL stored procedures within the (R)DBMS to the extent
>that there exists zero components external to the (R)DBMS.
And what is the problem with The Relational Model?
>The modern (R)DBMS environment is capable of
>"internalising" the entire applications environment.
And the future TRDBMS's will do it a lot better.
Regards
Alfredo
...[trim]...
> >My focus is building suites of application system components
> >as SQL stored procedures within the (R)DBMS to the extent
> >that there exists zero components external to the (R)DBMS.
>
> And what is the problem with The Relational Model?
It has a Godel-like incompleteness:
http://www.mountainman.com.au/software/history/relational_model_incomplete.htm
I disagree, although your use of the term "management" is questionable. E1
provides services for E2; E2 does an analogous thing for E3. E2 provides E3
with data (whatever it means) and inferences about that data; that's its
job.
> The catch-cry "the RM is just as applicable to database
> systems today, as it was in the early 1980's" should be
> taken as an indication that something is wrong with it as
> a pedagogic device for 2004.
It's more than a pedagogic device, but it's at least that.
> The reason for this is that E2 and E3 have changed alot
> since 1980, particularly E2, the RDBMS software. Due
> to the emergence of addressable stored procedures in
> the RDBMS, there has been an effective "migration" of
> intelligence (code) from E3 to E2.
You contradict yourself here, as the migration doesn't mean that the
previous services supplied by E2 are any more or less different. The code is
running in a different place. Date's Intro to DB Systems book discusses
various "levels" of the DB schemata - I forget the exact terms he uses, and
I don't have the book here. So yes, there is a distinction between "shared"
and "app-specific" components, whether they're running in the DBMS or not.
But that doesn't alter the fact that the code "objects" (E2b) in the DBMS
are different from the relational "objects" (E2a) in the DBMS. There's still
a logical separation, with E2b relying on E2a just like E2 relies on E1, and
E3 on E2. Capiche?
I'm still curious what sorts of concepts (other than the vacuous term
"management") you think the relational model should include for such things.
> The boundaries between E2 and E3 are now probably
> best described as fractal, whereas in the past they were
> heavily demarked.
They're hardly fractal, and I would say that the layering is more severe in
the E2b category. E2a remains solidly relational.
> However in practice, it is a dynamic fluid element that
> must be managed, with the assistance of, but also outside
> the realm of the present applicability of the RM.
>
> Change management is the name given to the bag that holds
> together everything that falls through the cracks of theory
> and out into the world of practice.
I think I'm starting to agree with you on this, but still don't think that's
the province of relational - at least not yet. I would like to see
discussions on a standard system catalog - in essence, relational statements
about relvars! Since the catalog is a set of relvars like the others, yet
describes those others, we now have true relational metadata, an interesting
topic...
- erk
Why first normal? If data is normalised, there is no redundancy. Like so
many things relational, First Normal Form seems to be case of carrying
things to unnecessary and not-required extremes.
It's incredibly easy to transform other normal forms to first normal.
It's not easy to go the other way (assuming you wish to reconstruct a
real-world object, that is). So NFNF is functionally equivalent to FNF,
but the reverse is not true.
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
I'm no mathematician, but didn't Godel prove that 'any' formal system
is incomplete?
Also, the interpretation in the 'real' world of the symbols of any
formal system seems to be pretty much up in the air.
Todd
If we can't set up an experiment (even a Gedanken thought experiment),
then relational theory is not provable, therefor it is not scientific,
therefor it is irrelevant to the real world, therefor why the hell are
we using it :-)
As a scientist/engineer type, not a mathematician, I want some
experimental proof at least. Unfortunately, all the (anecdotal) evidence
I have says that other models work better ...
>
>To put it another way, relational theory is analogous to the equation for a
>Gaussian distribution, f(x) = ae^(-bx^2). Were I to assert that Gaussian
>distributions are useful in describing scientific phenomena, you might ask
>me for a test; and what are f, a, b, and x? And when I tell you that it
>depends on the phenomenon we are trying to describe, and that f, a, b, and x
>can be many different things, you might mistake it to be of no practical
>value, as it makes no verifiable predictions. But if I were to substitute
>for f C, the concentration, for a C0/sqrt(4piDt), for b 1/4Dt, and
>proclaimed x to be distance, I would have made use of a Gaussian
>distribution to describe the process of diffusion, and it could be checked
>experimentally and the predictions of the equation (Fick's Second Law)
>verified. Only by giving a physical interpretation to the variables of the
>Gaussian distribution does it become a scientifically verifiable theory; and
>only by creating a schema which we associate with semantics are we able to
>test the application of the relational model to our problems.
Yup! We have an experiment!
>
>Having established that the relational model is an underlying mathematical
>framework bound to reality by the "glue" of the schemas we create, we're on
>better grounds to discuss the applicability of the model without premature
>calls for "experiment". We know that data in the relational model is
>formulated as logical propositions whose validity is evaluated by
>first-order logic. Hence my tenative suggestion in a post here about a month
>ago for examining alternatives to the relational model: are logical
>propositions the best way to formulate data, and do we need more power than
>first-order logic can bring us (and what trade-offs does that present)?
If we accept that data is an abstract proposition INSIDE relational
theory, then I might well agree that logical propositions, first-order
logic etc may well be the best way to formulate data. But that implies
that data is fundamental to database theory in the same way as mass and
energy individually are fundamental to Special Relativity - ie they are
NOT - there is a supra-concept called mass-energy, and the
transformation between mass and energy is part of the theory and nothing
to do with the metaphysical interface to reality ...
>
>(Incidentally, can we agree that while consistency is not sufficient to
>prove the correctness of a data model, it is necessary?)
>
Of course. I'd actually rephrase that. While (internal) consistency may
prove the model to be correct (mathematically), we need external
consistency to prove the model accurate (here we go - arguing over the
meaning of words again :-)
I did a "google" on "mercury orbit newton relativity", and it gave me a
load of good pages. About the first one I looked at (the third or so it
found) gave me rather bigger figures than yours for precession (although
it did have a few problems...)
>Before Einstein, the excess precession of Mercury was attributed to a
>hitherto unknown (and, it turns out nonexistent) planet inside the orbit of
>mercury, to which they gave the name "Vulcan". (Live long and prosper).
And apparently half the excess precession found by Newton was due to
relativity ...
>
>But the descriptions of the amount of time for which you need observations
>of Mercury to obtain these findings are very long. So long that I find it
>doubtful that Tycho could have observed for long enough for his data to
>detect the Einsteinian precession.
How long? Don't forget. Tycho STARTED these observations in about 1550.
Newton was around about 1750. So he actually had about 200 years worth
of data to play with.
>
>As far as Newton refining and cross checking his work, and seeking to verify
>or falsify it down to the last epsilon (so to speak), I find that very easy
>to believe. In fact, his own assessment of his work is that he felt like a
>little child, playing with the shells on the seashore, while the vast ocean
>of truth lay undiscovered before him. And Einstein, when asked to comment
>on Newton's work, said that his own work would have been impossible without
>Newton's earlier work.
>
>Those people in this forum who seem to have every human gift except
>humility might do well to learn from such people as Newton and Einstein.
>
And modern man would do well to learn humility from the ancients. 1
arcsecond is easily detected today, I would think. And it wouldn't
surprise me if Newton had access to some pretty accurate instruments too
- why shouldn't he be able to resolve with that sort of accuracy too?
With two centuries of data, that makes well over an arcminute due to
relativity alone. We know he could detect that sort of accuracy, because
he was trying to explain it!
(The website I looked at said the precession was more like 540
arcseconds a year, but it also said there were 360 arcseconds in a
degree, so I think it has mislaid a few powers of ten somewhere :-)
I think we agree on the problem being a rather narrow definition of
databases or a vertical partitioning of the software development problem
that isn't necessarily the best. Your solution to place everything "in the
database" (if I understand you correctly) is fine from my perspective, but
not the one I lean toward naturally -- I'd prefer an OO language to a
declarative one, particularly a vendor-specific declarative language that is
difficult to convert from one db to another.
> I think I'm starting to agree with you on this, but still don't think
that's
> the province of relational - at least not yet. I would like to see
> discussions on a standard system catalog - in essence, relational
statements
> about relvars! Since the catalog is a set of relvars like the others, yet
> describes those others, we now have true relational metadata, an
interesting
> topic...
>
Agreed that the system catalog would be a good place to make some industry
gains. For metadata such as "keywords" I'd think that employing those
nested relations might give SQL-DBMS's or RDBMS's a place to start getting
their operators shaped up for relation-valued attributes (or whatever one
wants to call them) -- just a thought. --dawn
The term management reflects the mandatory overview of all
components in the system, and their coordination. As I have
outlined, I have constructed an arrangment whereby all of E3
has been subsumed in the form of stored procedures, within the
E2 environment.
The Relational Model and theory cannot distinguish this specific
arrangment from any other, because it disregards E3 (application
layer) because of its traditional frame of reference, which in
historical terms is understandable, but is not so important in
today's world.
This specific arrangement developed however is complete,
and requires no other support to function. So you see, we
may have a large number of stored procedures which act
as E3 components, each written is SQL, each syntactically
as per Date's exemplary treatment, each relating precisely
and specifically to known data structures defined in the RM.
Yet the model can say nothing in its present state. This is an
absurd state of affairs for database systems managment.
> > The catch-cry "the RM is just as applicable to database
> > systems today, as it was in the early 1980's" should be
> > taken as an indication that something is wrong with it as
> > a pedagogic device for 2004.
>
> It's more than a pedagogic device, but it's at least that.
It is an incomplete device.
> > The reason for this is that E2 and E3 have changed alot
> > since 1980, particularly E2, the RDBMS software. Due
> > to the emergence of addressable stored procedures in
> > the RDBMS, there has been an effective "migration" of
> > intelligence (code) from E3 to E2.
>
> You contradict yourself here, as the migration doesn't mean that the
> previous services supplied by E2 are any more or less different. The code
is
> running in a different place. Date's Intro to DB Systems book discusses
> various "levels" of the DB schemata - I forget the exact terms he uses,
and
> I don't have the book here. So yes, there is a distinction between
"shared"
> and "app-specific" components, whether they're running in the DBMS or not.
Date has one diagram and a few words to say about the apps environment.
Sure, in my argument, as you note, the code is running in a different place.
But which place? Inside the RDBMS software environment?
Date and the RM are not capable of uttering anything sensible about
this state of affairs. The RM cannot address stored procedure object
data, end of story.
> But that doesn't alter the fact that the code "objects" (E2b) in the DBMS
> are different from the relational "objects" (E2a) in the DBMS. There's
still
> a logical separation, with E2b relying on E2a just like E2 relies on E1,
and
> E3 on E2. Capiche?
>
> I'm still curious what sorts of concepts (other than the vacuous term
> "management") you think the relational model should include for such
things.
I understand the inter-dependencies, but you seem not to understand
the term management. This term means the ability, or lack thereof, to
properly look after everything in that environment.
> > The boundaries between E2 and E3 are now probably
> > best described as fractal, whereas in the past they were
> > heavily demarked.
>
> They're hardly fractal, and I would say that the layering is more severe
in
> the E2b category. E2a remains solidly relational.
Lookup the term fractal basisn boundary.
> > However in practice, it is a dynamic fluid element that
> > must be managed, with the assistance of, but also outside
> > the realm of the present applicability of the RM.
> >
> > Change management is the name given to the bag that holds
> > together everything that falls through the cracks of theory
> > and out into the world of practice.
>
> I think I'm starting to agree with you on this, but still don't think
that's
> the province of relational - at least not yet. I would like to see
> discussions on a standard system catalog - in essence, relational
statements
> about relvars! Since the catalog is a set of relvars like the others, yet
> describes those others, we now have true relational metadata, an
interesting
> topic...
The relational model was an ideal of Codd and the pioneers that
has been promulgated by Date et al. It is at least 30 y/o and is
not consistent with technological reality.
It has a Godel-like incompleteness:
http://www.mountainman.com.au/software/history/relational_model_incomplete.htm
Pete Brown
Falls Creek
Oz
Yes, he did. But I am being specific about provision of one specific
instance
in which the incompleness of the RM is comprehendable.
> Also, the interpretation in the 'real' world of the symbols of any
> formal system seems to be pretty much up in the air.
In a database, relational or otherwise, the interpretations are usually
sorted out in advance with respect to the data elements. They are
interpretted with respect to the organisation (IMO)
> the
>> Pick approach should be compared with troglodite superstition.
>
> I'm surprised at seeing such a miscomparison.
Why do you consider it a miscomparision?
Newtonian mechanics is more like a particular instance of a database in
the relational model, rather than the model itself.
The relational model is really just an implementation of first-order
predicate logic that is suitable for computers.
Logic is more like a "meta-theory": it's kind of how we reason *about
how we reason*, so it's a bit self-referential.
For a particular database we can test it experimentally: we add data,
query it and check that the answers correspond with reality.
For first-order predicate logic itself, it's almost axiomatic that it
corresponds to reality, because we are saying this is how we argue
logically by definition. Godel proved that first order logic is
"complete" in some sense (see here for example:
http://www.sm.luth.se/~torkel/eget/godel/completeness.html), though the
whole area of Godel is guaranteed to cause confusion and
misunderstanding, and will possibly explode your brain.
>> (Incidentally, can we agree that while consistency is not sufficient to
>> prove the correctness of a data model, it is necessary?)
>>
> Of course. I'd actually rephrase that. While (internal) consistency may
> prove the model to be correct (mathematically), we need external
> consistency to prove the model accurate (here we go - arguing over the
> meaning of words again :-)
But in order to prove the model is accurate externally we'd have to use
logic. So we've got a chicken and egg situation here. What logic is
external to logic itself?
Paul.
I don't quite understand what you mean here. Even if you think that
relational theory is missing something, I don't think it is a
"Godel-like" incompleteness.
>>I'm no mathematician, but didn't Godel prove that 'any' formal system
>>is incomplete?
>
> Yes, he did. But I am being specific about provision of one specific
> instance in which the incompleness of the RM is comprehendable.
Well, Godel acually proved that first-order predicate logic (upon which
the relational model is based) is complete in some sense. The
Incompleteness theorem only applies to theories that are above a certain
complexity. To add to the confusion, there are slightly different
meanings of "complete" here. See this page for more details:
http://www.sm.luth.se/~torkel/eget/godel/completeness.html
I think essentially the difference is that you need to use logic to show
that some other theories are incomplete, but to show the completeness of
logic itself you've got a bit of a self-referential paradox. I could
be completely wrong here though. Very interesting though.
Paul.
Random truths (Chaitin) and unprovable truths (Godel).
See http://www.mountainman.com.au/GIF/logic_space_1.jpg
You may consider that the RM is incomplete, but it is NOT a
"Godel-like" incompleteness: you are just attaching a fancy-sounding
but irrelevant label to your claim. It is like describing any kind of
uncertainty as "Heisenberg-like" or any kind of cat as
"Schrodinger-like"!
> If we can't set up an experiment (even a Gedanken thought experiment),
> then relational theory is not provable, therefor it is not scientific,
> therefor it is irrelevant to the real world, therefor why the hell are
> we using it :-)
>
> As a scientist/engineer type, not a mathematician, I want some
> experimental proof at least. Unfortunately, all the (anecdotal) evidence
> I have says that other models work better ...
You make an interesting point here. I would add that the same arguments
that would render relational theory
not provable would equally well render the theory non falsifiable. In that
case, the question for the engineer becomes moot.
The question "why the hell are we using it" can be countered by "why the
hell not".
I would suggest that the disciplined practices of engineers are based on
several sources. One is prior experience, either the personal experience
of an individual engineer, or the distilled experience of other engineers.
Another is the accumulated results of science, and of other specialties
within engineering. A third is the results of mathematics. A fourth is the
study of how people carry out certain data management and data manipulation
tasks in the absence of automation. A fifth is the study of the strengths
and defects of "legacy systems".
Sorry the list got so long.
My personal experience tells me that the relational data model can be, in
certain circumstances, an enormous aid in managing the complexity of
defining the data itself, and in clarifying certain issues in the
development of application software.
This is a far cry from saying that "all data should be in 1NF".
> I did a "google" on "mercury orbit newton relativity", and it gave me a
> load of good pages. About the first one I looked at (the third or so it
> found) gave me rather bigger figures than yours for precession (although
> it did have a few problems...)
Yes. The figure are considerably bigger because the precession of Mercury
is for the most part, due to
attraction from the other planents. The only figures I quoted were the
"excess" (that is, non Newtonian)
observed precession of Mercury.
> (The website I looked at said the precession was more like 540
> arcseconds a year, but it also said there were 360 arcseconds in a
> degree, so I think it has mislaid a few powers of ten somewhere :-)
There are 3600 arcseconds in a degree.
As far as the connection to this forum goes, I think the discussion in here
reminds me more of the discussions between
Simplicio, Salviati, and Sagredo in Galileo's writings.
I can just hear Simplicio saying something like:
<quote>
Aristotle's axioms are self evident, and his logic is irrefutable.
Therefore his conclusions are correct.
Therefore, if you report experimental observations that contradict his
conclusions, then you are either lying or you have been misled by your
infatuation with experimental observation.
If you had the proper respect for your betters you would restrain yourself
from making such rash claims, in contradiction of the wisdom of the
ancients. And if you had proper training in philosophical thinking, you
would be able to confirm Aritstotle's work for yourself, instead of all
this nonsense about taking cannonball up to the top of a tower and dropping
them.
</quote>
Actually, you and me both have just said exactly the same thing.
"provable" and "falsifiable" both mean exactly the same thing as far as
science goes - to take that widely misquoted saying "the exception
proves the rule (is wrong)". The bit in parentheses is ignored or
unknown to most people who quote the saying ... Look in a dictionary.
"to prove" can mean "to test".
As for "why the hell not" - well we should be looking for theories that
ARE provable/falsifiable. Because if relational theory is not
falsifiable, then equally we can't show that it works in practice (for
any suitable value of "works"). Would you trust an engineer using
Newtonian Mechanics if you had no way of knowing whether relativistic
effects were likely in that particular application?
>
>I would suggest that the disciplined practices of engineers are based on
>several sources. One is prior experience, either the personal experience
>of an individual engineer, or the distilled experience of other engineers.
>Another is the accumulated results of science, and of other specialties
>within engineering. A third is the results of mathematics. A fourth is the
>study of how people carry out certain data management and data manipulation
>tasks in the absence of automation. A fifth is the study of the strengths
>and defects of "legacy systems".
>
>Sorry the list got so long.
Well, when I was talking about Newtonian Mechanics metaphysics my list
was about that long :-) but if things have to be complete and
comprehensive, then sometimes they do get long ...
>
>My personal experience tells me that the relational data model can be, in
>certain circumstances, an enormous aid in managing the complexity of
>defining the data itself, and in clarifying certain issues in the
>development of application software.
I would very much agree ... indeed I would say it almost invariably is a
great help, if used as your TOOL and not as your MASTER!
>
>This is a far cry from saying that "all data should be in 1NF".
>
And the same here. As far as I am concerned, the job of the "database
analyst designer" is to take real-world information, and convert it to a
data schema for the database. If that includes conversion to 1NF, this
involves a massive loss of metadata, meaning that the conversion is
one-way and cannot be reversed, and therefore the act of conversion
renders the whole thing unprovable / unfalsifiable / unscientific.
Yup :-) 60 seconds times 60 minutes = 3600 seconds in a degree :-) I
knew that.
>
>As far as the connection to this forum goes, I think the discussion in here
>reminds me more of the discussions between
>Simplicio, Salviati, and Sagredo in Galileo's writings.
>
>I can just hear Simplicio saying something like:
>
><quote>
>Aristotle's axioms are self evident, and his logic is irrefutable.
>Therefore his conclusions are correct.
>
>Therefore, if you report experimental observations that contradict his
>conclusions, then you are either lying or you have been misled by your
>infatuation with experimental observation.
>
>If you had the proper respect for your betters you would restrain yourself
>from making such rash claims, in contradiction of the wisdom of the
>ancients. And if you had proper training in philosophical thinking, you
>would be able to confirm Aritstotle's work for yourself, instead of all
>this nonsense about taking cannonball up to the top of a tower and dropping
>them.
>
></quote>
>
PERFECT! That's a quote I would have loved to have had available to me
earlier :-)
Thanks.
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
The society which scorns excellence in plumbing because plumbing is a humble
activity, and tolerates shoddiness in philosophy because it is an exalted
activity, will have neither good plumbing nor good philosophy. Neither its
pipes nor its theories will hold water. John W Gardner
And isn't there something about if they are complete, then they also
have to be simplistic (and therefore cannot be real-world accurate)?
>
>I think essentially the difference is that you need to use logic to
>show that some other theories are incomplete, but to show the
>completeness of logic itself you've got a bit of a self-referential
>paradox. I could be completely wrong here though. Very interesting though.
>
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
I'm not entirely certain, but it seems to me that any logic model that
is consistent (i.e. theorems derived from the axioms do not contradict
the axioms or other theorems so derived) will be unable to find
certain truths within the system. And that seems to be Godel's sword
in the stone (you know, he's actually not the first to come up with
the idea, but the first to apply it to number theory). In other
words, pretty much everything is Godel-like, unless you adapt an
informal system, but then when you do that, you lose the power of
logic altogether.
> >>I'm no mathematician, but didn't Godel prove that 'any' formal system
> >>is incomplete?
> >
> > Yes, he did. But I am being specific about provision of one specific
> > instance in which the incompleness of the RM is comprehendable.
>
> Well, Godel acually proved that first-order predicate logic (upon which
> the relational model is based) is complete in some sense. The
> Incompleteness theorem only applies to theories that are above a certain
> complexity. To add to the confusion, there are slightly different
> meanings of "complete" here. See this page for more details:
> http://www.sm.luth.se/~torkel/eget/godel/completeness.html
Good short article that touches on some key points of the theorem and
its implications. But seriously, I'm a bit over my head here, since
my only source on Godel is the book "Godel, Escher, Bach: a Golden
Braid". I haven't read the actual Incompleteness proof.
Todd
No, there isn't. You're just making that up because it would be
convenient to your position.
--
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://cbbrowne.com/info/finances.html
Rules of the Evil Overlord #22. "No matter how tempted I am with the
prospect of unlimited power, I will not consume any energy field
bigger than my head. <http://www.eviloverlord.com/>
> I would very much agree ... indeed I would say it almost invariably is a
> great help, if used as your TOOL and not as your MASTER!
Agreed. The old saying is, "A fool with a tool is still a fool".
Or perhaps the pragma is better expressed as:
"If you can dream, and not make dreams your master,
If you can think, and not make thoughts your aim,
If you can meet with triumph and disaster,
And treat those two impostors just the same,"
On this subthread, I think the difference between you and me is more how we
choose to express things than on the substance of the matter.
> PERFECT! That's a quote I would have loved to have had available to me
> earlier :-)
The thing is, I'm not satisfied with the arguments of either the pro
relational camp or their challengers in this forum.
There's clearly a lot of intelligence and erudition in here, but it seems
to be savagely misused, on both sides of the argument.
I've used the power of relational joins, ever since I was first exposed to
the concept. And my first use involved nothing more sophisticated than
Datatrieve and indexed files on a VAX. And the theorists in this forum who
dismiss that as "not relational" have a fundamental synapse missing with
regard to the connection between theory and pragma.
I've never used PICK, but from what I've read in here, if one were to
study the reason why certain PICK applications were
(and possibly still are) successful, and do the same for Datatrieve, one
would find a surprising overlap. And I think data models would play a minor
role in both studies. I'd love to see some rational discussion of that.
But we'd have to get away from some of the cultural norms of this forum.
For me, the migration from Datatrieve to VAX Rdb/VMS, and later from that
to Oracle were pretty natural. While I find much to criticize about SQL,
it's far, far better than the access languages that grew up around CODASYL
databases! If a better language can be designed, implemented and adopted,
I'm all for that! But don't expect me to wait!
Yes, I think so - my preference is to push things that have to work together
from a single source, via a template-driven code generation approach (in
lieu of higher-level languages, though code generation amounts to the same).
> Your solution to place everything "in the
> database" (if I understand you correctly) is fine from my perspective, but
> not the one I lean toward naturally -- I'd prefer an OO language to a
> declarative one,
Why not both? Something like Tutorial D, which offers both OO capabilities
for domains, plus relations? In any even, we'll have to agree to disagree on
the value of declarative... I'll simply point to the explosion of Java
frameworks (Struts, Avalon, blah blah blah) and even language extensions
(e.g. AspectJ). The "config files" are in most cases declarative statements
of system structure, and in the case of aspects, are "cross-cutting"
concerns which indicate the failings of the OO language (and I'd argue the
OO paradigm itself). Languages like Lisp and Haskell don't require such
"cross-cutting" because the languages themselves support abstractions
orthogonal to objects. More than OO is needed, I think.
> particularly a vendor-specific declarative language that is
> difficult to convert from one db to another.
Couldn't agree more - a vendor-specific language is worthless. Witness even
the various proprietary "extensions" to SQL...
> Agreed that the system catalog would be a good place to make some industry
> gains. For metadata such as "keywords" I'd think that employing those
> nested relations might give SQL-DBMS's or RDBMS's a place to start getting
> their operators shaped up for relation-valued attributes (or whatever one
> wants to call them) -- just a thought. --dawn
Interesting - certainly relation-valued attributes would require decent
relational operations. Or at least one would think. Industry might always,
in its infinite wisdom, decide it knows better.
- erk
The term "management" has at least the same "Goedel-like" incompleteness
that you refer to elsewhere, unless you really believe "overview" and
"coordination" are precise. My point is simply that I don't know which
aspects of "management" you're referring to - it has many definitions,
components, and dimensions. Be precise.
However, I do have your papers printed out, and will be reading them
shortly - so far I'm only judging by what you've written in these posts.
> As I have
> outlined, I have constructed an arrangment whereby all of E3
> has been subsumed in the form of stored procedures, within the
> E2 environment.
The fact that they're executing in E2 doesn't imply "subsumption." They are
still "objects" of a very different sort than those E2 traditionally
"manages." For instance, those stored procedured could be written in
arbitrary languages, and executed anywhere. It seems you see their value in
their genericity, rather than in where they happen to execute.
> The Relational Model and theory cannot distinguish this specific
> arrangment from any other, because it disregards E3 (application
> layer) because of its traditional frame of reference, which in
> historical terms is understandable, but is not so important in
> today's world.
So why does E1 disregard E2? Don't you think that's short-sighted and
incomplete? How would you rectify that? Shouldn't they all be subsumed into
E* ("*" as in transitive closure) ?
> This specific arrangement developed however is complete,
In a Goedelian sense? Doubtful.
> and requires no other support to function.
Not even E1?
> So you see, we
> may have a large number of stored procedures which act
> as E3 components, each written is SQL, each syntactically
> as per Date's exemplary treatment, each relating precisely
> and specifically to known data structures defined in the RM.
That's no different than any other E3 component, is it? Like a Java program
doing JDBC and issuing SQL Strings in exchange for ResultSets?
> Yet the model can say nothing in its present state. This is an
> absurd state of affairs for database systems managment.
So once E3 components are "subsumed" in E2, what more can be said about
them? Specifically, what special properties or powers or whatever do they
derived from executing in E2 rather than regarded as part of E3?
> Date has one diagram and a few words to say about the apps environment.
> Sure, in my argument, as you note, the code is running in a different
place.
> But which place? Inside the RDBMS software environment?
Could be - why does it matter? They're still code components, not relvars.
What difference does it make where they run? I agree with it, don't get me
wrong - but I think then you just happen to have E3 components running in
E2, which indicates to me that your operational levels are perhaps
orthogonal to the real issue of what "types" of components are being
"managed".
> Date and the RM are not capable of uttering anything sensible about
> this state of affairs.
What should they say? In contrast to their muteness, say something -
anything. I have no idea what you're looking to be said.
> The RM cannot address stored procedure object data, end of story.
So say something, even informally, that should be part of some "RM++"
theory. I have no idea what you're hinting at - this argument reminds me of
internal auditors at a former company, who could point out things done
incorrectly but were not allowed to say a word about what SHOULD be done
instead.
> > I'm still curious what sorts of concepts (other than the vacuous term
> > "management") you think the relational model should include for such
> things.
>
> I understand the inter-dependencies, but you seem not to understand
> the term management.
Perhaps, but you're not helping. If you understand it thoroughly, then your
words aren't helping the rest of us... granted that this isn't a
"management" class, but some clarification would help.
> This term means the ability, or lack thereof, to
> properly look after everything in that environment.
"Properly look after"? That's clarification?
> > > However in practice, it is a dynamic fluid element that
> > > must be managed, with the assistance of, but also outside
> > > the realm of the present applicability of the RM.
> > >
> > > Change management is the name given to the bag that holds
> > > together everything that falls through the cracks of theory
> > > and out into the world of practice.
> >
> > I think I'm starting to agree with you on this, but still don't think
> that's
> > the province of relational - at least not yet. I would like to see
> > discussions on a standard system catalog - in essence, relational
> statements
> > about relvars! Since the catalog is a set of relvars like the others,
yet
> > describes those others, we now have true relational metadata, an
> interesting
> > topic...
>
> The relational model was an ideal of Codd and the pioneers that
> has been promulgated by Date et al. It is at least 30 y/o and is
> not consistent with technological reality.
> It has a Godel-like incompleteness:
>
http://www.mountainman.com.au/software/history/relational_model_incomplete.htm
And your theory is Goedel-complete? Doubtful. Let's agree to stop waving
Goedel and Occam about, and concentrate on specific areas of incompleteness
that matter in both theory and practice...
- erk
> And your theory is Goedel-complete? Doubtful. Let's agree to stop waving
> Goedel and Occam about, and concentrate on specific areas of incompleteness
> that matter in both theory and practice...
>
> - erk
Well said.
In a way, however, Godel's theorem is pertinent because it touches on
the fact that a database, no matter what it's design is or underlaying
structure is, will 'definitely' not be able to answer every question
we want to ask it. Not that I'm being doomsday about logic :) I just
think there can be a source of frustration in being able to answer a
corporation's questions, and the culprit may not always be the
database choice or database design, but may be that the question is
simply unanswerable (although I have to admit, this has never actually
happened to me, so take me with a grain of salt). It's something to
think about, though.
Todd
Are you certain this is true?
As I understand it:
1) Godel's Incompleteness theorem only applies to system that are
powerful enough to model arithmetic.
2) It's impossible to model arithmetic using only first-order logic.
3) Relational theory (which basically *is* first-order logic) is
actually both complete and consistent.
I'm not a professional logician though, and I know Godel's results are
very open to misinterpretation, so I could well be wrong. I guess it
depends on the exact definitions of "model", "theory", "system", "logic"
etc., and what exactly we mean by "complete" and "consistent".
Also, does it actually matter? Because for example suppose I'm right and
relational theory is complete, there are still questions like the
transitive closure which can't be answered. That's because these
questions can't even be written down in first order logic so they are
meaningless within the system (so the system is still complete). But
they are meaningful in a "real-world" sense, because we are thinking in
a larger system which includes second-order logic.
I suppose at least we would know that in theory, every query that it is
possible to formulate in some given relational query language can be
answered.
Paul.
In Pick, that join wouldn't be necessary, the linked table would
logically and physically be part of the master table ...
And if you haven't got a cascading delete, chances are you either have a
code lookup; or you're only interested in viewing fields in one table,
but need the other table for certain SELECT fields. In the former case
you declare a virtual field in Pick, and in the latter it may require
(slightly) more effort on the part of the programmer, but a lot less
effort on the part of the database...
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
...[trim]...
> > As I have
> > outlined, I have constructed an arrangment whereby all of E3
> > has been subsumed in the form of stored procedures, within the
> > E2 environment.
>
> The fact that they're executing in E2 doesn't imply "subsumption." They
are
> still "objects" of a very different sort than those E2 traditionally
> "manages." For instance, those stored procedured could be written in
> arbitrary languages, and executed anywhere. It seems you see their value
in
> their genericity, rather than in where they happen to execute.
I see value in avoiding redundancies. All application code that relates
to database I/O that is external to the RDBMS environment requires
redundancy of definition of the database schema. This is so because
the entire system spans two software environments (E2 and E3).
Current technology looks at this as the status quo. The world
is used to defining things in a union and conjunction of two
separate software systems. However it is very inefficient.
When things can be defined using one software layer alone,
the redefinitions referred to above no longer exist.
...[trim]...
It's clear you love this analogy, but it doesn't work.
What we put in the database is data, not the real world. Neither do
we attempt to say anything about the real world with our databases.
Consider a payroll database. Does it contain one single fact about
the natural world? It does not. It has names, social security numbers,
addresses, salaries, phone numbers, etc. These are all 100% human
constructs; none of them are found anywhere in the real world; they
are exclusively in our heads.
I suppose you will counter with some NASA database or something.
But what will it have in it? Let's say it's full of the positions of rocks.
But how do we record those positions? With a GPS machine that tells
us lattitude and longitude. Note that we don't have *actual* rocks
in the database; we only have data for the lat/lon pairs. You could comb
all over the surface of Mars or Earth and never find a lattitude line.
The internal predicate is in the database; the external predicate is in
our heads. Humans convert from one to the other; machines can't.
It's imperative that that the humans be able to tell the difference.
Marshall
Correct, relational theory is not scientific.
> therefor it is irrelevant to the real world, therefor why the hell are
> we using it :-)
Because it is *mathematical.*
I can imagine giving you a four function calculator, and you saying,
how can I devise a real-world, scientific experiment to verify the
validity of this thing, and then throwing it out because you couldn't.
Four function calculators are not scientific, but they are still useful, mathematically.
> As a scientist/engineer type, not a mathematician, I want some
> experimental proof at least.
I am a computer scientist, which is a kind of mathematician.
I have no illusion that what I do relates to the physical world.
> Unfortunately, all the (anecdotal) evidence
> I have says that other models work better ...
I have this gedanken experiment that says, what if I have two apples
and I try to take away three. In the real world, I get an error, because
once I have taken away two, I no longer have any apples that I can
take away. Therefor, only positive integers are scientific. I have no
use for negative numbers because they are not scientific, either, since
there are no negative numbers I can observe in the natural world.
Marshall
How might one falsify arithmetic? If arithmetic was falsified, would
that mean it wasn't useful anymore?
Marshall
It depends what you mean by "falsify arithmetic". There's a result by
Tarski ( http://plato.stanford.edu/entries/tarski-truth/ ) that says
essentially that no language can talk about the truth of sentences
contained within itself without leading to things like the liar paradox.
You need to have a "meta-language" for arithmetic in order to talk about
whether statements in arithmetic are true or not.
I guess the problem is where do you start? Set theory I suppose but then
how do you talk rigorously about set theory?
All this stuff is very subtle but I think it is useful to know a bit
about this kind of thing if you're interested in relational database theory.
If you mean that arithmetic is inconsistent i.e. there is a statement
where you can prove both it and its negation, then that means
*everything* in arithetic is both true and false.
Check out this though:
http://plato.stanford.edu/entries/mathematics-inconsistent/
Inconsistent Mathematics, where you have theories that use non-classical
logic and can deal with inconsistencies without collapsing in on themselves.
Paul.
Well, if they're not facts about the real world, then I presume they are
imaginary musings? In which case they are no better than fantasy. So why
bother with them?
Names, Social Security Numbers, etc etc are all ways of describing real
things (in these cases a person). An address describes a real thing - a
building. Etcetera.
But the point is, if you do not have some way of FORMALLY converting
between a person (you, me, whoever) or a phone (a physical thing you can
hold) or a building (something you can look at), and the data that
describes those things, then your theory of data MUST be unscientific.
Bearing in mind that this is the study of philosophy ("does the tree,
continue to be, if no-one's there to see") I'm quite happy with a
scrappy attempt to explain things. But the conversion has to be both
ways - with "mass" we know exactly what Newton meant in his mathematical
theory, and we know exactly what we mean in the real world when we pick
up a heavy object. And we (now, thanks to Einstein) know that those two
definitions (the real and the mathematical) don't quite tie up.
But if you can't give me a way of converting between "data" and the
real-world objects it describes - in both directions! - then by
definition any theory of data must be unfalsifiable, therefor it is
unscientific, therefor it lives very firmly in the realms of mathematics
and religion. I'm sorry, but I'm a scientist by training and I most
definitely don't believe in that religion.
Arithmetic is part of mathematics. Therefor, it is NOT falsifiable. We
merely prove it correct or incorrect. The best example is "reductio ad
absurdam" - if from our starting point we end up with two mutually
exclusive results then either our starting point or our logic must be
wrong. Now what's this got to do with science?
Let's go from arithmetic to geometry. In three dimensions we have
Euclidean geometry. We can prove it correct (or self-consistent - same
thing). In four dimensions, we have special relativity, and again we can
prove it correct. In two dimensions, we have planar, spherical, and
toroidal geometry, and yet again, we can prove them correct.
NOW! Let's apply all three of our two-dimensional geometries to the
surface of the earth. THIS is the "falsifiable" bit.
Let's use planar geometry to describe the little bit of the world we can
see. I know a little bit of American geography, as do many others, so
I'll use that. Let's say we're in Kansas. We know New York is 1500 miles
east, and Dallas is 2000 miles south. So we predict the distance and
direction from New York to Dallas. The reality is we are going to be
well wrong - we've just falsified the assumption that the world is flat.
Or, to put it another way, "planar geometry does not describe the
world". Toroidal geometry will come up with a similar mess.
Spherical geometry, on the other hand will be pretty close. So either
we've cocked up on our geometry or, as is actually the case, the earth
is an approximate sphere not a perfect one. Newton mapped his
mathematical "mass", "energy", "space" and "time" to the real-world
equivalents, and came up with a load of predictions that mostly worked.
So he concluded that his maths was wrong. If he'd concluded that reality
wasn't quite as he envisaged it, he might well have beaten Einstein to
the theory of relativity!
So no. Your question "how do we falsify arithmetic" is meaningless. But
science is about falsifying theories *based* *on* arithmetic (and other
branches of mathematics). Use the maths to make a prediction about the
real world, and then prove (as in test) the theory by seeing if the
prediction is true or false. And if the prediction is falsified by an
exception, then you've just got an example of "the exception proves the
theory is wrong".
And that's why I say Newtonian Mechanics is scientific - it is a
mathematical theory that can be proved/falsified, while Relational
Theory is unscientific because I can see no way - not even with a
Gedanken thought experiment - of trying to falsify it.
Good. We agree :-)
>
>> therefor it is irrelevant to the real world, therefor why the hell are
>> we using it :-)
>
>Because it is *mathematical.*
So I can use any theory I like, so long as it's mathematical, then?
You'd be quite happy for me to calculate your aeroplane's route from A
to B using whatever geometrical theory I cared for, and you wouldn't
object if I used a theory who's practical effect was to destroy your
aircraft in a huge fireball as it underwent a "controlled flight into
terrain", just as long as I could prove the maths I was using was
perfectly sound. The fact that it was the wrong theory for the
real-world task in hand wouldn't bother you in the slightest?
>
>I can imagine giving you a four function calculator, and you saying,
>how can I devise a real-world, scientific experiment to verify the
>validity of this thing, and then throwing it out because you couldn't.
>
>Four function calculators are not scientific, but they are still
>useful, mathematically.
>
Well, actually, I could think of an experiment. "If I type '4' '+' '4'
'*' '4' '=' into this thing, then it should come up '20' but might come
up '32' ". And either way, I will be happy at using it because I can
predict (ie "do science") that it will come up with a "correct" answer,
and I can verify that answer.
Actually, I've just done exactly that with the calculator in my copy of
Windows, and guess which answer it came up with ...
To be honest, I don't know. I'll do some reading and certainly
revisit this topic in this group (regardless of whether it bothers the
other readers or not) after some good research.
> Also, does it actually matter? Because for example suppose I'm right and
> relational theory is complete, there are still questions like the
> transitive closure which can't be answered. That's because these
> questions can't even be written down in first order logic so they are
> meaningless within the system (so the system is still complete). But
> they are meaningful in a "real-world" sense, because we are thinking in
> a larger system which includes second-order logic.
Good point.
> I suppose at least we would know that in theory, every query that it is
> possible to formulate in some given relational query language can be
> answered.
Can you give me an example of where there is proof of first order
logic being complete? Keep in mind I'm sticking to the definition of
complete as 'things that we prove true within the system are also true
in the reality which we use the system to describe'. Is first order
logic 'consistent'? Well, of course it is; it's kind of a
requirement. Is it 'complete', though? I don't think so, but please
prove me wrong or point me to some articles that do.
So, in summary, this last thing you say about every query being
answerable is, IMO, 'incompletely' untrue :)
Perhaps there is a query that one could conjure in their head, but
would be impossible to write down absolutely? I hate to do this, but
I'm going to drop back into a classic example of unproveability
because I'm lazy. Prove to me, without brute force methods, that the
number 2481997 is prime. (Don't try, because it's not). The point
is, for me anyway, is that - okay maybe from a more optimistic
perspective - we have the ability to come up with questions, that any
logic system will fall short in answering.
Todd
[snip]
>>Four function calculators are not scientific, but they are still
>>useful, mathematically.
>>
>Well, actually, I could think of an experiment. "If I type '4' '+' '4'
>'*' '4' '=' into this thing, then it should come up '20' but might come
>up '32' ". And either way, I will be happy at using it because I can
>predict (ie "do science") that it will come up with a "correct" answer,
>and I can verify that answer.
>
>Actually, I've just done exactly that with the calculator in my copy of
>Windows, and guess which answer it came up with ...
I would have to guess since it could come up with either!
In Standard view, the answer is 32.
In Scientific view, the answer is 20. (In this view, parentheses
are available for grouping operations.)
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
"Anthony W. Youngman" <w...@thewolery.demon.co.uk> wrote in message
news:1vLKA7AJ...@thewolery.demon.co.uk...
> In message <7Lzrc.20286$zw.10403@attbi_s01>, Marshall Spight
> <msp...@dnai.com> writes
> >"Anthony W. Youngman" <w...@thewolery.demon.co.uk> wrote in message
news:uMz8IRDs...@thewolery.demon.co.uk...
> >>
> >> But both are attempts to apply a mathematical model to a real world
> >> problem. Viewed from a dispassionate oversight, both are instances of
> >> the SAME problem, and the same techniques can be applied to solving
> >> them. Namely "how well does my mathematical model work in the real
> >> world?".
> >
> >It's clear you love this analogy, but it doesn't work.
> >
> >What we put in the database is data, not the real world. Neither do
> >we attempt to say anything about the real world with our databases.
> >Consider a payroll database. Does it contain one single fact about
> >the natural world? It does not. It has names, social security numbers,
> >addresses, salaries, phone numbers, etc. These are all 100% human
> >constructs; none of them are found anywhere in the real world; they
> >are exclusively in our heads.
>
> Well, if they're not facts ABOUT the real world, then I presume they are
> imaginary musings? In which case they are no better than fantasy. So why
> bother with them?
But they could be fantasy :-)
> Names, Social Security Numbers, etc etc are all ways of describing real
> things (in these cases a person). An address describes a real thing - a
> building. Etcetera.
Or an imaginary thing :-)
The question is: How do you test if some "fact" is real or imaginary ?
> But the point is, if you do not have some way of FORMALLY converting
> between a person (you, me, whoever) or a phone (a physical thing you can
> hold) or a building (something you can look at), and the data that
> describes those things, then your theory of data MUST be unscientific.
Well, we can have data about many kinds of "things": physical, chemical,
imaginary, etc.:-)
Why are you interested only in "physical" ones ? :-)
> Bearing in mind that this is the study of philosophy ("does the tree,
> continue to be, if no-one's there to see") I'm quite happy with a
> scrappy attempt to explain things. But the conversion has to be both
> ways - with "mass" we know exactly what Newton meant in his mathematical
> theory, and we know exactly what we mean in the real world when we pick
> up a heavy object. And we (now, thanks to Einstein) know that those two
> definitions (the real and the mathematical) don't quite tie up.
Many of us gave up asking WHY long time ago.
Instead, we ask HOW MANY/MUCH :-)
> But if you can't give me a way of converting between "data" and the
> real-world objects it describes - in both directions! - then by
> definition any theory of data must be unfalsifiable, therefor it is
> unscientific, therefor it lives very firmly in the realms of mathematics
> and religion. I'm sorry, but I'm a scientist by training and I most
> definitely don't believe in that religion.
We have NOTARIES, ACCOUNTANTS, LAWYERS,... :-)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.usenet.com
Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I agree, though using some fairly simple techniques definitions can exist in
one place, and be propagated to others. If an "object" could be defined in
E2, for example, and automatically generate the appropriate changes on E3,
how would that fit?
I'm also curious why you suggest moving objects from E3 to E2 for reasons of
efficiency and duplicate elimination, but don't include E1 in the mix.
Certainly services in E1 are relevant to applications?
- Eric
Does this pass the "reasonableness" test? The thought that: ...there are
questions that can't be answered so they're meaningless and, thus, ignored
(so the system is still complete) doesn't say much for consistency (i.e.
anything that shows inconsistency is ignored so we still have consistency).
With postulates like these, I'm depressed about getting A's in college logic
and statistics classes, as they were obviously worthless. :-)
Bill
"Todd B" <toddkenn...@yahoo.com> wrote in message
[snipped]
"Anthony W. Youngman" <w...@thewolery.demon.co.uk> wrote in message
[snipped]
> ... As far as I am concerned, the job of the "database
> analyst designer" is to take real-world information, and convert it to a
> data schema for the database. If that includes conversion to 1NF, this
> involves a massive loss of metadata, meaning that the conversion is
> one-way and cannot be reversed, and therefore the act of conversion
> renders the whole thing unprovable / unfalsifiable / unscientific.
But it still might be useful under the circumstances. :-)
Bill
The point is that these questions can't even be *asked* in the system.
The system can still be internally complete and consistent though.
To talk about statements in a language we always need a meta-language.
It can be that questions can be posed in the meta-language that can't in
the language itself.
Suppose you have a "theory", e.g. field theory, with its various axioms.
Then you can have various "models" that are kind of examples of this
theory, for example the real numbers, complex numbers, etc.
Now what the Completeness Theorem says is that is something is true in
every model of a given theory, it will be possible to prove it in the
theory itself (using first order logic). So in other words if you start
from your axioms and apply first order logic to them, it's possible for
you to extract every possible true statement of your theory.
So I guess the applicability of databases here is that your relations
are the axioms of your "theory". Your real-world interpretations of
those relations are your "models" of the theory. And the Completeness
Theorem assures you that everything you expect to be true in the real
world will in fact be provable by the DBMS.
For example suppose I have a database containing the tuple:
(1, 2, 'blue')
There could be many interpretations of what this means: for example
"customer #1 bought 2 blue widgets"
"on day 1 of the study we saw 2 blue cars"
But in any of these models if I look for distinct values of the third
argument of my predicate (i.e. project on the "third" column) I expect
to get the answer ('blue').
So my query language (which is really just first order logic) is
guaranteed to give the right answer when I do:
"SELECT DISTINCT colour FROM r"
And this same argument holds even for more complicated queries.
The interesting thing is that if you go up into second-order logic,
there is no corresponding completeness theorem. So you may either have
things that are true in all interpretations of a theory but you can't
prove them in the theory itself, or you'd have things you can prove in
the theory but which aren't true in some model of the theory.
So maybe Codd was wise to stick with first-order logic!
Paul.
Yes, in a formal system, everything that fails to show consistency
becomes invalid (and is ultimately ignored or denied due to the fact
that it lacks basic logic - like: A proves B, and B proves C, but C
contradicts A - that would be a very simple example of an informal
system). At least that's the way I understand it.
> With postulates like these, I'm depressed about getting A's in college logic
> and statistics classes, as they were obviously worthless. :-)
>
> Bill
I wouldn't suggest that logic is 'worthless', or comment that any
questions that cannot be answered are 'meaningless'; just that logic
is not as complete as most logicians or mathematicians would like it
to be.
Now Paul has a point about first order logic - and its completeness -
that I would like to look into. I'm still betting that my
interpretation of Godel's theorem is correct in the sense that 'Any
formal system that is consistent is definitely _not_ complete'.
Is any formal system useful? That's a whole different argument to me,
because any formal or informal system can be put to use. So, in a
way, there is still hope for us logical (and illogical) people :)
I guess I'm ranting about this topic and I'm sure everyone in this
group is hoping I'll shut up. So, before they tell me that, and
before I step out of line (too late), since I don't have the
impressive logic and math background that some of you have, I sum up
Godel's Incompleteness theorem like so: "Within a formal system, there
are things that are true within that system that you cannot
prove/derive within that system". Whew.
Todd
It would still imply replication of existent data, or if you prefer,
redundant I/O in that updates would need to be pushed up from
the database (E2) into E3.
However I reckon this would be a better "practice" to engineer
as its operation relies on maintainance of the database, and
avoids duplicate maintainance at the code level. It is a step
closer to optimum running, for sure.
> I'm also curious why you suggest moving objects from E3 to E2 for reasons
of
> efficiency and duplicate elimination, but don't include E1 in the mix.
> Certainly services in E1 are relevant to applications?
First steps first. ;-)
Services in E1 and wheel-in wheel-out redundant services.
An organisation uses these much the same way as the next.
Their physical network may be different and their user base
however, IMO, the elements of code resident at E2 and E3
are the uniquely specifying elements for that "organization's
intelligence".
The first step in moving objects from E3 to E2 will obviate
the (database application's) client environment of code.
This is the big mixmaster in complexity with the reality of
the management of RDBMS production sites, the most
expensive, the least responsive, the change-management
headache, the cause of the bulk of many problems.
Binding the results into E1 should fall out of the consolidation
effort (E3 to E2) and represents the logical next step in the
theory of database systems, imo.
And secondly, the following article might be of interest
to those who have been thinking about the implications
of the work of Godel, Turing and Chaitin in logic:
The article is a transcript of an address given by Chaitin:
http://www.cs.auckland.ac.nz/CDMTCS/chaitin/cmu.html
Best wishes,
Pete Brown
Falls Creek
Oz
"Bill H" <wpha...@THISISMUNGEDatt.net> wrote in message
news:g7psc.36419$zw.14141@attbi_s01...
But that definition of "complete" only works if we can prove,
scientifically, that the system accurately describes the reality.
If we cannot show that "the system" and "the reality" match up with each
other (which we can't if we don't have a philosophical definition of
"data" in "the reality") then it's impossible for "the system" to be
complete ...
And if they turn out to be false in the real world and provable in the
DBMS, then the DBMS theory is wrong ... (or the DBMS predicts something
is false when it turns out to be true ...)
Or if you can't prove it in the DBMS, then the theory is incomplete ...
Well, the Completeness Theorem has a converse called the Soundness
Theorem (http://en.wikipedia.org/wiki/Soundness_theorem), which assures
us that first order logic is consistent. i.e. everything that you can
prove in the DBMS is true in real life. This was known long before the
Completeness Theorem I think, and is easier to prove.
> Or if you can't prove it in the DBMS, then the theory is incomplete ...
The Completeness Theorem proves the "complete" part. i.e. everything
that is true in all models or interpretations of the database will be
provable by the DBMS.
Note that Godel's Incompleteness Theorem is something slightly
different. That's really talking about the completeness of theories that
just happen to be manipulated with first order logic. The Completeness
Theorem is talking about the completeness of first-order logic itself.
So in the first instance you could say first order logic is being a
meta-language, but in the second instance it is just being a language.
Paul.
"Paul" <pa...@test.com> wrote in message
news:JMZsc.8405$NK4.1...@stones.force9.net...
> Anthony W. Youngman wrote:
> >> So I guess the applicability of databases here is that your relations
> >> are the axioms of your "theory". Your real-world interpretations of
> >> those relations are your "models" of the theory. And the Completeness
> >> Theorem assures you that everything you expect to be true in the real
> >> world will in fact be provable by the DBMS.
> >
> > And if they turn out to be false in the real world and provable in the
> > DBMS, then the DBMS theory is wrong ... (or the DBMS predicts something
> > is false when it turns out to be true ...)
>
> Well, the Completeness Theorem has a converse called the Soundness
> Theorem (http://en.wikipedia.org/wiki/Soundness_theorem), which assures
> us that first order logic is consistent. i.e. everything that you can
> prove in the DBMS is true in real life. This was known long before the
> Completeness Theorem I think, and is easier to prove.
>
> > Or if you can't prove it in the DBMS, then the theory is incomplete ...
>
> The Completeness Theorem proves the "complete" part. i.e. everything
> that is true in all models or interpretations of the database will be
> provable by the DBMS.
Is something that is true in only one model provable by the DBMS ?
What this "all models" thing has to do with databases ?
Just one model wouldn't be enough ?
No, it'd have to be all models, because the DBMS can only prove things
that are true under all circumstances, or in the most general case.
Suppose for example I have the following tuples in a relation:
('Alan', 'Bill')
('Bill', 'Chas')
Now in one model, this might mean:
Alan is an ancestor of Bill.
Bill is an ancestor of Chas.
So in this model, the tuple ('Alan', 'Chas') could also be legitimately
added to this relation. i.e the proposition 'Alan is an ancestor of
Chas' is true.
Similarly if it means "is a brother of'.
But consider the model where it means:
Alan is a friend of Bill.
Bill is a friend of Chas.
Then it doesn't follow that Alan is a friend of Chas. It could easily be
that Alan hates Chas.
So the DBMS shouldn't be able to prove that ('Alan', 'Chas') is a
legitimate tuple for that relation, because the DBMS has no idea what
model is being used to interpret the database. And there's no way it
could have an idea either.
I guess what it is really saying is that the model is larger than the
theory, in the sense that it has concepts external to the theory. The
theory can only prove things that are common to all models based on the
theory (and the Completeness Theorem says it can *always* do this).
I'm not an expert though, so it's quite possible I've either
misunderstood the theorem or misapplied it - please correct me if you
think this is the case.
Paul.
"Paul" <pa...@test.com> wrote in message
news:I91tc.8436$NK4.1...@stones.force9.net...
> x wrote:
> >>The Completeness Theorem proves the "complete" part. i.e. everything
> >>that is true in all models or interpretations of the database will be
> >>provable by the DBMS.
> >
> > Is something that is true in only one model provable by the DBMS ?
> > What this "all models" thing has to do with databases ?
> > Just one model wouldn't be enough ?
>
> No, it'd have to be all models, because the DBMS can only prove things
> that are true under all circumstances, or in the most general case.
>
> Suppose for example I have the following tuples in a relation:
>
> ('Alan', 'Bill')
> ('Bill', 'Chas')
>
> Now in one model, this might mean:
> Alan is an ancestor of Bill.
> Bill is an ancestor of Chas.
>
> So in this model, the tuple ('Alan', 'Chas') could also be legitimately
> added to this relation. i.e the proposition 'Alan is an ancestor of
> Chas' is true.
>
> Similarly if it means "is a brother of'.
>
> But consider the model where it means:
> Alan is a friend of Bill.
> Bill is a friend of Chas.
>
> Then it doesn't follow that Alan is a friend of Chas. It could easily be
> that Alan hates Chas.
>
> So the DBMS shouldn't be able to prove that ('Alan', 'Chas') is a
> legitimate tuple for that relation, because the DBMS has no idea what
> model is being used to interpret the database. And there's no way it
> could have an idea either.
It could have an idea if there is only one model.
> I guess what it is really saying is that the model is larger than the
> theory, in the sense that it has concepts external to the theory. The
> theory can only prove things that are common to all models based on the
> theory (and the Completeness Theorem says it can *always* do this).
Model is about "truth".
Theory is about provability.
> I'm not an expert though, so it's quite possible I've either
> misunderstood the theorem or misapplied it - please correct me if you
> think this is the case.
I'm not an expert either.
But it seems this Completeness and Soundness stuff deals with theorems, not
with individual facts.
"x" <x-f...@yahoo.com> wrote in message news:40b4b372$1...@post.usenet.com...
> **** Post for FREE via your newsreader at post.usenet.com ****
>
>
> "Paul" <pa...@test.com> wrote in message
> news:I91tc.8436$NK4.1...@stones.force9.net...
> > x wrote:
> > >>The Completeness Theorem proves the "complete" part. i.e. everything
> > >>that is true in all models or interpretations of the database will be
> > >>provable by the DBMS.
> > >
> > > Is something that is true in only one model provable by the DBMS ?
> > > What this "all models" thing has to do with databases ?
> > > Just one model wouldn't be enough ?
> >
For example one could build a model in such a way that:
Friend(Alan,Bill) means ancestor(bill,alan)
Ancestor(Alan,Bill) means friend(bill,alan)