Re: Proposal: 6NF
From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 04 Oct 2006 01:25:55 GMT
Message-ID: <D4EUg.87145$1T2.3907_at_pd7urf2no>
>
> I think you're confusing tuples with things. In the relational model,
> properly understood, a tuple represents a fact, not a thing. What you
> are saying is that sometimes there are two facts about the same subject,
> and that you can find out one, and then later perhaps find out another.
> If you think of tuples as representing things, then you'd logically
> expect that all the simple attributes of that thing would be in one
> relation schema; and if some are unknown, you'd look for a way to
> represent that. If you understand tuples as facts, though, you are no
> longer forced into the presumption that all the basic facts about a
> thing need to be expressed in the same relation schema, and that allows
> you to consider designs where you can store each fact as you discover
> it.
>
> This confusion -- that tuples in relations represent things, not facts
> -- is very common. There are, in fact, numerous database design
> tutorials, references, etc. that adopt it. I could make the case that,
> in fact, SQL is designed for it and that this thing-oriented pseudo-
> relational database design is more common in practice than relational
> database deasign. It is, however, not relational design.
>
Date: Wed, 04 Oct 2006 01:25:55 GMT
Message-ID: <D4EUg.87145$1T2.3907_at_pd7urf2no>
Chris Smith wrote:
> Brian Selzer <brian_at_selzer-software.com> wrote:
>> I think you're making the assumption that an attribute doesn't apply if its >> value isn't known. That is not always true. It is often the case that not >> all of the information about something is received at the same time. The >> interval during which the first bit of information is received and the final >> bit may be sufficiently long that it makes sense to record parts of that >> information at different times rather than wait until all of the relevant >> information is available and then recording it en mass.
>
> I think you're confusing tuples with things. In the relational model,
> properly understood, a tuple represents a fact, not a thing. What you
> are saying is that sometimes there are two facts about the same subject,
> and that you can find out one, and then later perhaps find out another.
> If you think of tuples as representing things, then you'd logically
> expect that all the simple attributes of that thing would be in one
> relation schema; and if some are unknown, you'd look for a way to
> represent that. If you understand tuples as facts, though, you are no
> longer forced into the presumption that all the basic facts about a
> thing need to be expressed in the same relation schema, and that allows
> you to consider designs where you can store each fact as you discover
> it.
>
> This confusion -- that tuples in relations represent things, not facts
> -- is very common. There are, in fact, numerous database design
> tutorials, references, etc. that adopt it. I could make the case that,
> in fact, SQL is designed for it and that this thing-oriented pseudo-
> relational database design is more common in practice than relational
> database deasign. It is, however, not relational design.
>
I second that. I've seen nothing in relational theory that requires rows or tuples to stand for things (or entities). Saying it does strikes me as nothing more than close-minded willfullness.
p Received on Wed Oct 04 2006 - 03:25:55 CEST