Re: foundations of relational theory?

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:<B6nmb.22188$e01.46207_at_attbi_s02>...

> "Mike Preece" <michael_at_preece.net> wrote in message
> news:1b0b566c.0310240556.3bf271e6_at_posting.google.com...

> > >

> > > BS. Or do you mean you don't write to log files ?

> >

> > No - we don't usually. It's not usually wanted or needed. We can if

> > you want. It's very easily done - centrally, with a trigger
> > fired when

> > the file is updated if you'd like.

>

> So, what happens if you have a power failure or an OS or application

> crash when you've written the first page of a two-page update?

> Does Pick have transactions?

>

Yes. If you like you can download the manual. It's got ACID in it ;-)

http://www.rainingdata.com/support/documentation/d3server2.html

[snip]

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

>

> Well, it never seems that difficult to me, but I've been taught

> how to do it.

>

> BTW, normalization is the process of removing redundancy

> from a schema. A fully-normalized schema is said to have

> no redundancy, not be fully two dimensional.

>

Could you please take a look at the example I gave in repsonse to Costins post a while back and tell me how you would normalise that related data? Could you also tell me in what form the Pick model's represetation of the related data is (I'm sorry if I'm not using the correct terms here). There's no redundancy in it afaik. Also - I've heard it said that it's not strictly correct to have a foreign key (pointer?) in a parent and then have that same data as the key in the child table. What's that about? Does it all mean that Pick is in some ways *more* normalised (or relational?) than in SQL-relational?

> Actually, calling relations "two dimensional" is a common

> misconception. Relations are not two dimensional; they

> are n dimensional, where n is the number of attributes.

<smiles/> Every time I see the word "attribute" I can't help thinking of the word in Pick terms.

> You can print out points in an n-dimensional space on

> a piece of paper by listing the value in each of the n

> dimensions one after the other, one per line; that

> doesn't make the data two dimensional.

>

> Here's some different examples of colors from the

> three dimensional eight bit RGB color space:

>

> R G B

> ---------

> 255 0 0 // red

> 127 127 127 // gray

> 255 255 // cyan

> 255 0 // green

>

> Is this data three-dimensional or two dimensional?

> Answer: the data is three dimensional, but the

> presentation of the data is two dimensional

> if you view it on a monitor. If you view it

> on a punch tape, the presentation would

> be one-dimensional.)

>

>

> Marshall

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? 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)? 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. Personally, although it might be taken to be heresy hereabouts, I've always viewed it more as Codd's wallop. 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.

Regards,

Mike.

--
Posted via http://dbforums.com