Re: foundations of relational theory?

"tonyd0806" <member45701_at_dbforums.com> wrote in message news:3523667.1067138885_at_dbforums.com...
>
> Responding to Mike's post ...
>
> >There is often no good reason for both to exist in the first place.
> >This is comp.databases.theory.
> >Databases exist to record and retrieve data.
>
> There's the small matter of ensuring the consistency of that data.
> Everything else lags a long way behind. I don't really care how quickly
> things happen if I can't trust the answers I get from my queries.
>
> >Relational theory is the theory that some data is related to
> >other data.
>
> Isn't it a theory in which it is postulated that all data can be
> represented using entities, attributes and relations, and describes
> operations that can be performed on those relations ?

No, it isn't. Entities have no part to play in the relational model. The relational model requires a dbms to represent all data as typed data values in relations.

> >I think some extremely brilliant mathemetician came up
> >with that startling concept.
>
> Actually, compared to what was available and in use beforehand, it was
> quite startling. Much like the Pascal language, an improvement on what
> was before and much of what came after.
>
> >If it didn't make sense to store related
> >data together then every datum would be held seperately.
> >There'd be more pointers than data.
>
> There are no pointers in the relational model. It's a specific aim.
>
> >Just because the surface of the screen you're
> >looking at can be plotted using 2 coordinates - like columns and rows
> >- doesn't mean databases must be similarly limited.
>
> Relational databases aren't limited in such a way. Perhaps you're
> confusing a "picture of a thing" with "the thing in itself" ?

Pickies do that a lot.

> >The Pick database allows you to store related data together.
> >The reason for storing related data in a seperate file on a Pick
> >database
> >is not for some ridiculous reason like an inability to be able to
> >plot it in
> >2 dimensional column and row terms.
>
> What's with this 2 dimensional thing ? We'll come back to that.

Willful ignorance. I cannot count how many times he's had it explained to him that an n-ary tuple is a point in an n-dimensional space.

> >Don't you really mean that the pointers between the *often
> >unnecessary* tables must be maintained or the whole crock of s**t
> >falls apart and makes big brown smelly stains all over your two
> >dimensional world?
>
> Now this is just silly. Pointers and the 2-dimensional illusion recur.
> Just to recap :
>
> 1. There are no pointers in the relational model. Full stop.
>
> 2. Relations are not 2-dimensional. You can draw pictures of relations
> in a 2-dimensional format, but that doesn't mean relations are 2-d.
> To illustrate the point (sorry), you can draw a 2-d map of the world,
> but that doesn't mean the world is flat, does it ?
>
> >In the Pick database as described, there is one file. No pointers to
> >related data. All of the related data is in a single item.
>
> You do realise you could do all this with a relation-valued attribute,
> don't you ? (That's not being sarcastic, truly.) For any given attribute
> of a tuple in a relation (a.k.a. column in a row of a table), there must
> be one and only one value. Now that value can be as simple or as
> complicated as you like; it could be *an* integer, *a* string, *an*
> array, *a* tuple, *a* relation, whatever you like, so long as there is
> only *one* of them. That whole business about what "atomic" really meant
> has caused so much trouble !
Received on Sun Oct 26 2003 - 06:51:13 CET