Re: foundations of relational theory?

Replying to Mike's post ...

<snippage>

>Isn't that just an interesting diversion though? or can all four
>(or more) ?

>values share the same column & row (tupple?) without needing to

>be 'referenced' or 'pointed to' in a single SQL-relational table?

SQL tables aren't relations; careful now :) SQL tables permit duplicate rows and nulls; relations permit neither.

>I mean - if a tuple (I hope I'm using the correct terms here)
>referenced

>by column and row can only have one value isn't that two-dimensional

>(even though the value might be a pointer to another table)?

Not really; I like to think of a Rubik's Cube as a counter example to the 2-dimensional thing. If you look at a Rubik's Cube square on, it looks like, well, a square. Now rotate the planes of the Cube to show the different axes that are actually present; how many dimensions are there now ? You might consider each individual row/column co-ordinate to be 2-dimensional; but how many columns are there ?

>I've always been under the impression that the reason Pick
>didn't qualify

>as relational was because it allows more than one value in a "tupple"

>(column/row intersection) - and that that was a big bad NO NO according

>to Codd.

Well, terminology aside, it *was* considered a no-no for a long time, due to the question over what "atomic" was supposed to mean. Things are now coming round to the view that "atomic" means a single value, but not a restriction on what that value can be; it could be anything - including a relation.

Now, terminology. In SQL, and informally, we talk about tables, which have rows and columns, and for each row/column intersection there is one value. In relationland, and formally, we talk about relations which have tuples and attributes, and for each tuple/attribute intersection there is one value. In SQL-land, the columns are said to have names and types, and the types are usually fairly primitive (e.g. integers, strings) with some interesting types usually added (e.g. dates, money). In relationland,  the attributes have names and domains, and the domains can be anything you like. So, informally, you could say ..

Informal -> Formal (or "Posh")

Table -> Relation

Row -> Tuple

Column -> Attribute

Type -> Domain

These are *not* exact equivalences (e.g. the difference between tables and relations noted above), but it'll get you started.

>Personally, although it might be taken to be heresy hereabouts, I've

>always viewed it more as Codd's wallop.

Coddswallop comes from Codd bottles, not Codd relations :)

>I've also heard it said that a multivalue - even a subvalue - can be

>considered to be a (atomic?) value and that that does qualify Pick as

>relational after all.

Maybe; I doubt that Pick is doing anything that couldn't be described and done with more rigour and predictability with relation-valued attributes, but without more exposure to Pick, I can't say for sure. Sadly, a whole pile of other things require my attention ahead of Pick, but one of these days...

>Regards,

>Mike.

• Tony

--
Posted via http://dbforums.com