Re: Composite attributes

"Greg Boland" <gregb_at_snet.net> wrote in message news:9NcJ9.3291$uo2.871127202_at_newssvr10.news.prodigy.com...
>
> "Jan Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message
> news:3dda0a9f$1_at_news.uia.ac.be...
> > In article <6278687.0211181426.3480b5a4_at_posting.google.com>,
> > Juan Pardillos <sicotom_at_eresmas.com> wrote:
> > >Hi,
> > >
> > >I'd like to know if a composite attribute (e.g., a subject code like
> > >'CS2323', where 'CS' denotes the department and so on) can be in a
> > >relation or whether this is prohibited by the definition of relation.
> > >In other words, does the definition of relation prohibit composite
> > >attributes or only multivalued attributes?.
> > >
> > >I've got the same doubt regarding the first normal form. Depending on
> > >the text, I get a different opinion about the answer to this question.
> >
> > The relevant question is if as far as the database is concerned it is
> > treated as an atomic value. So you have to envision all the queries that
> are
> > going to be asked and wonder if some of them will have to split 'CS2323'
> > into 'CS' and '2323'. So as usual the answer is: it depends on what you
> want
> > to do with the data.
> >
> > -- Jan Hidders
> >
> >
> >
> I think we may be talking about two different things. First is an
> "intelligent" key. Where, if you parse the key you may derive some
instance
> from it. EX. P12443123. Where the key means P12>product number, 443 >
model
> number 123> color. I think in most cases this is BAD, becuase the rule
will
> almost certainly change. But in the case of a true composite key
> (EMPLOYEE_NUM-->PROJECT_NUM) the semantics of the key makes sense. That is
> employee 123 works on project 234. Your question--it is not prohibited by
> definition, just screws up your database (and your life) big time.
>
I know you were talking about attributes, not keys. But my answer still applies.

Regards,

Greg Received on Tue Dec 10 2002 - 04:10:45 CET