Re: Multiple-Attribute Keys and 1NF
- From: JOG <jog@xxxxxxxxxxxxx>
- Date: Thu, 30 Aug 2007 13:27:45 -0000
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?
.
- Follow-Ups:
- Re: Multiple-Attribute Keys and 1NF
- From: Bob Badour
- Re: Multiple-Attribute Keys and 1NF
- References:
- 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: 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
- 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
|
|