Re: Composite attributes

"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. Received on Tue Dec 10 2002 - 04:00:21 CET