Re: Relation or attribute and why

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1147990242.573989.100810_at_g10g2000cwb.googlegroups.com...
> x wrote:
> > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > news:1147826073.046909.174590_at_u72g2000cwu.googlegroups.com...
> > > Let's say that we have a noun present in a conceptual data model, but
> > > not identified as a strong entitiy (recognizing not all conceptual
> > > modeling techniques use such distinctions). What are the conditions
> > > under which this noun will/should translate into an attribute in a
> > > logical data model? What are the conditions under which this noun
> > > will/should translate into a relation in the logical data model?
> >
> > It will always translate to an attribute or a set of attributes.

> Hey, thanks x ;-) but are you sure? It might be dropped entirely when
> going from the CDM to the LDM, although less likely if the LDM includes
> derived sets and attributes too.

I just told you my opinion. I'm not Codd, you know...

> We could take the noun "name" from our CDM and model it as a derived
> attribute or user-defined function, perhaps associating it with a
> derived set so we have something like

> select function('fullName') as name from Person;
> perhaps placing this in a create view statement so we can then do
> select name from PersonView;
>
> If we have a noun A that has-a B in our CDM, then we often model A as a
> relation and if B doesn't have-a C, then we might model it as an
> attribute in set A. In the case of "A:name has-a B:firstName" we often
> model "name" as a derived attribute, perhaps leaving it out of the LDM
> altogether so that each application can paste together the parts to
> form a name.

Sorry, but it's hard for me to follow you above.

> Is there a guideline for this that we could state in terms of
> functional dependencies or otherwise that would lead us to a noun such
> as "name" becoming a derived attribute rather than a set?

Have you studied abstract algebra ?

> I'm trying to gain clarity in how one goes from a conceptual data model
> to a logical data model (when employing the RDM) and why.

When employing RDM one must use relations for all data. I encountered several opinions regarding SQL-DBMSs. 1) one should be able to work with relations as described by the RDM at the level of an SQL-DBMS
2) the schema in an SQL-DBMS is just an implementation and one should work with RDM in a layer above the DBMS
3) SQL is a language that must enable one to use a DBMS regardless of the data model of the DBMS
What a mess.

>What is the
> technique (is it a normalization technique, is it based on FDs?) that
> might eliminate "name" in going from the conceptual to the logical data
> model?

I don't understand your example (I don't have the patience to decode it right now), but I'll say that if you need "name" why do you want to remove it ?

> What rules or rules of thumb might make either A or B a
> relation or an attribute? For example, Marshall mentioned the
> technique once known as 1NF in the case where B is multivalued. In
> that case, B becomes a set instead of an attribute. Are there other
> instances when B which has no C would become a set instead of an
> attribute? What rule are we employing when we drop B from the LDM or
> make it derived (A:date has-a B:month would be an example)?

What operators would you use if the relations are not in 1NF ?

> Has-a is just one type of relationship in a conceptual data model, but
> maybe it is worth zeroing in on. Thanks. --dawn

Has-a is a relation like any other. Received on Mon May 22 2006 - 11:57:37 CEST