Re: foundations of relational theory?

Originally posted by tonyd0806

> Responding to Mike's post ...

>

> [snip]

> >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.

>

> OK. The point stands though? I wanted to emphasise that we do actually
> want to physically do something with the data.

>

> >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 ?

>

> If that's the definition you prefer I'm not going to argue. I prefer
> my simpler statement though.

>

> >I think some extremely brilliant mathematician 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 separately.

> >There'd be more pointers than data.

>

> There are no pointers in the relational model. It's a specific aim.

>

> How would you suggest we *hold* every related datum separately with
> relations intact without pointers?

>

> >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" ?

>

> Actually, I was confusing my previously held notion that relational
> theory did not allow more than one value in a 'cell' or 'tuple' with
> my more recent awareness that multiple values *are* allowed. I am
> learning as I go - and much of what I learn seems perfectly acceptable
> to me. I still, have the impression - correct me if I'm wrong - that
> the so-called 'relational' databases out there in the real world
> reference data by means of 'tables' comprising columns and rows.

>

> >The Pick database allows you to store related data together.

> >The reason for storing related data in a separate 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.

>

> >What do you really mean by 'integrity'?

>

> That nothing has been allowed to happen to the data in the database
> that would make it inconsistent. Consistency has been defined by the
> constraints I have placed on the database. Consistency is managed for
> me by my DBMS. Once I have described to the DBMS what consistency is,
> I expect that the database will be consistent forever more, with no
> further effort on my part (or indeed the part of application
> developers).

>

> I see this differently now to the way I did when I entered this
> discussion - and when I posed that question. I also see it differently
> to the way you do it seems.

>

> "Forever more"? You do allow for changes to your imposed constraints
> don't you?

>

> We do see "application developers" differently but that's OK. I'm used
> to a scenario in which application developers operate *within* the
> DBMS. I'm also familiar with alternatives - like when web designers
> want to interact with the Pick DBMS, don't know or want to know
> anything about what goes on within the DBMS, so long as they get
> consistent valid data in and out, and rely on people with an intimate
> involvement with the Pick DBMS to change the rules for them. In this
> light I guess the "web designers" are more like what you might call
> "application developers", and the Pick "application developers" are
> more akin to "DBA"s on RDBMSes.

>

> >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.

>

> Maybe a foreign key referencing a child table isn't a pointer and it
> all comes down to my poor grasp of the definitions of the word
> pointer in the context of relational theory? Maybe I'll understand
> this from reading your answer to my previous question about keeping
> relations intact.

>

> 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 ?

>

> Correct me if I'm wrong here but I don't *think* I ever said relations
> were two-dimensional. I certainly didn't mean to. I was referring to
> tables two 'coordinates' - column and row.

>

> >Well here's a startling concept: What if you didn't need those
> >pointers >between the unnecessary tables because they don't
> >actually exist?

>

> Well, the pointers don't exist, so...

>

> >And 'normalisation'? You have to fit your data into a 2 dimensional

> >structure although you get the sneaking suspicion sometimes that it's

> >actually a lot more difficult to do so than it should be somehow?

> >That's because you're insisting on making life difficult for
> >yourself.

> >Well go on if that's what rocks your boat. Knock yourself out!

>

> Normalisation isn't *that* difficult. It's pretty easy, at least up to
> 3NF. It's not that much more difficult beyond that. It really is
> mostly applied common sense. Like most good ideas. And it's not about
> fitting data into a 2-dimensional structure, it's about removing
> redundancy as far as possible, and ensuring that your data can be kept
> consistent.

>

> I was thinking it said something about 'atomicity' meaning you
> couldn't have multi- or sub- values. I'm interested in learning more
> about the exact nature of "relation valued attributes".

>

> <snip snip snip snip>

>

> >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.

>

> Well this seems a bit suss to me. There can be only one, which can be
> a collection (array) of more than one. Hmmm... I wonder if and/or how
> an array of multivalues fails to qualify as an array. In actual fact
> it's more a string with delimiters. An array by definition has
> multiple values. A string can surely have delimiters - more than a
> single character at least. I'm afraid I'm having difficulty with
> understanding the rules about oneness here.

>

> I presume there is actually some rule or definition in relational
> theory that specifically says a tuple in a relation can only ever be
> expressed in terms of a column/row in a table?

>

> That whole business about what "atomic" really meant has caused so
> much trouble !

>

> >It'll be interesting to to some benchmarks when you've got
> >your system

> >ready. The CEO is an impatient man though! How long do you
> >think it'll

> >take?

>

> Now, this benchmark thing bugs me too. I have never seen a requirement
> to "run that machine 'til the CPUs melt and the disks are squealing".
> I don't know anyone who still counts CPU T-states. I can't believe
> anyone still really counts head movements any more. (I don't even
> believe you *could* count head movements anyway, with the effects of
> pre-reads, group reads, caches and so on nowadays.) So why all this
> counting of mythic head movements ?

>

> It's more about illustrating the simplicity of the implementation of
> the model at the physical level. You want the DBMS to do something -
> it does it perfectly with an absolute minimum of fuss. Performance was
> more important than it is now. Faster still is better usually -
> everything else being equal.

>

> It also misses the point in that you're comparing a piece of software
> interacting with pieces of hardware to a logical model.

>

> ...the physical implementation of a logical model...

>

> Not really like-with-like, is it ? And if you start comparing Pick
> systems to SQL systems, then you're not comparing Pick to anything to
> do with the relational model of data. (If you've got some time to
> while away, try finding the word "relational" in the SQL standard.)
> SQL tables aren't relations.

>

> That's as maybe - but you'll get a *lot* of hits of you do a google
> search of this newsgroup for "SQL", possibly more than for the any of
> the strings "comp", "databases" or "theory".

>

> >Cheers mate,

> >Mike.

>

> Have fun and keep well everyone,

>

> - Tony

Cheers to you too Tony,

Mike.

PS. The CEO is waiting...

--
Posted via http://dbforums.com