Re: foundations of relational theory?

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 ?

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

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

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

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

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

<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. That whole business about what "atomic" really meant has caused so much trouble !

>And I'm guessing there was a lot of that was there?

You wouldn't believe the mess that happens when people gaily type away on keyboards ;)

<snip snip snippety snip-snip-snip>

>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 also misses the point in that you're comparing a piece of software interacting with pieces of hardware to 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.

>Cheers mate,

>Mike.

Have fun and keep well everyone,

• Tony

--
Posted via http://dbforums.com