Re: Multiple-Attribute Keys and 1NF
- From: Bob Badour <bbadour@xxxxxxxxxxxxxxxx>
- Date: Thu, 30 Aug 2007 14:33:07 -0300
JOG wrote:
On Aug 30, 5:00 pm, Bob Badour <bbad...@xxxxxxxxxxxxxxxx> wrote:
JOG wrote:
On Aug 30, 2:55 pm, Bob Badour <bbad...@xxxxxxxxxxxxxxxx> wrote:
JOG wrote:
On Aug 30, 1:44 pm, Bob Badour <bbad...@xxxxxxxxxxxxxxxx> wrote:
JOG wrote:
On Aug 30, 1:42 am, Bob Badour <bbad...@xxxxxxxxxxxxxxxx> wrote:
JOG wrote:
Write a predicate for the relation schema that when extentially quantified
and extended yields a set of atomic formulae that implies all three of the
propositions above. I think you'll find that the colour-code concept is in
that predicate.
I agree. I hold little stock with set based values so in RM I would go
for the addition of colour-code foreign key.
But what if we weren't tied to a traditional relational schema and
tweaked the system so it could allow propositions with more than one
role of the same name without decomposing them. As Jan pointed out
'tuples' are no longer functions - they would be unrestricted binary
relations (subsets of attribute x values). We could produce a
comparatively simpler and less cluttered schema, predicate in a very
similar manner as before, and with a few simple alterations could have
an equally effective WHERE mechanism. My concern however would be the
consequences to JOIN.
What would you offer in place of the RM's logical identity.
Nothing. I am utterly convinced by Date et al's arguments in favour of
logical identity. (Why would I need to replace it?) I just wanna model
propositions, and they are always identified by their contents.
In: {{(Color: green), (Color: yellow), (Type: earth)}}
What provides logical identity?
I may be misunderstanding you, but let me take a stab. The identity of
any set of course lies in its elements (i.e. in this of a single
propositions, the ordered pairs). Given we know Colors are the
antecedents in the proposition we are modelling, this has to be been
defined in the collectivizing predicate for the whole collection of
rows. We also know therefore there may not exist another set of pairs
containing the same Colors, so we can identify the whole proposition
through examination of just those roles. All works just as per normal
in RM. Is this what you meant?
I haven't got a clue what you said.
I just regurgitated leibniz identity.
In the RM, every value is uniquely
identifiable by the combination of relation name, attribute name and any
candidate key value. That's logical identity as it was originally
spelled out.
Two values above have the same attribute name.
Now you've lost me. A "value" is not identifiable by its relation name
and attribute name. This makes no sense to me. Where in predicate
logic does that come from? A value is just a value. It is identifiable
in its own right as being an individual from a domain.
I mispoke. "Any value represented in a relvar"
Well it is still just a value whether its in a relvar or not - it
needs no extra identity. A database table is just a set of
propositions. A proposition is encoded as a set of attribute-value
pairs. That's it surely?
Any notion of identity is as defined by set theory.
An individual piece of /data/ however (which is perhaps what you mean
by a value) has an identity made up of a combination of an attribute
name and a corresponding value. One needs both to identify the data
item. A proposition in turn is identifiable by its contents, which is
a set of those data items. Regards, J.
I repeat: two pieces of data have the same name, Color.
Well no - a piece of data doesn't have a 'name' does it? It's just a
combination of attribute and value. The number-7. name-Fred. color-
red. A datum's identity is defined by the /combination/ of these two
parts, and that alone - not by a label, or an alias, or an OID (as I'm
sure you'd agree).
No, I don't agree. I suggest you see the definition of Logical Identity in Codd's 12 rules.
.
- Follow-Ups:
- Re: Multiple-Attribute Keys and 1NF
- From: JOG
- Re: Multiple-Attribute Keys and 1NF
- References:
- Re: Multiple-Attribute Keys and 1NF
- From: JOG
- Re: Multiple-Attribute Keys and 1NF
- From: Bob Badour
- Re: Multiple-Attribute Keys and 1NF
- From: JOG
- Re: Multiple-Attribute Keys and 1NF
- From: Bob Badour
- Re: Multiple-Attribute Keys and 1NF
- From: JOG
- Re: Multiple-Attribute Keys and 1NF
- From: David Cressey
- Re: Multiple-Attribute Keys and 1NF
- From: JOG
- Re: Multiple-Attribute Keys and 1NF
- From: Bob Badour
- Re: Multiple-Attribute Keys and 1NF
- From: JOG
- Re: Multiple-Attribute Keys and 1NF
- From: Brian Selzer
- Re: Multiple-Attribute Keys and 1NF
- From: JOG
- Re: Multiple-Attribute Keys and 1NF
- From: Bob Badour
- Re: Multiple-Attribute Keys and 1NF
- From: JOG
- Re: Multiple-Attribute Keys and 1NF
- From: Bob Badour
- Re: Multiple-Attribute Keys and 1NF
- From: JOG
- Re: Multiple-Attribute Keys and 1NF
- From: Bob Badour
- Re: Multiple-Attribute Keys and 1NF
- From: JOG
- Re: Multiple-Attribute Keys and 1NF
- From: Bob Badour
- Re: Multiple-Attribute Keys and 1NF
- From: JOG
- Re: Multiple-Attribute Keys and 1NF
- Prev by Date: Re: normalization review
- Next by Date: Re: Multiple-Attribute Keys and 1NF
- Previous by thread: Re: Multiple-Attribute Keys and 1NF
- Next by thread: Re: Multiple-Attribute Keys and 1NF
- Index(es):
Relevant Pages
|
|