Re: Relation or attribute and why

dawn wrote:
> In response to Tony, I agree that other than collecting multiple names,
> there is nothing to be gained. So we derive the name and store the
> parts (first, last, middle), whereas with the date, we store the date
> and derive the parts (month, day, year).
>
> What is practice that we used to decide to produce a logical data model
> in this way, sometimes dumping nouns that are collectives from the CDM,
> sometimes dumping the parts, when preparing the LDM?

Every data model is relative to the business domain and requirements. In the case of entities and attributes, it depends on what your domain predicates are. If you have nothing to say about a name other than that it is Joe X. Blow for some entity, then it's an attribute. If there are further useful things to be said about the name (e.g. attributes like "date acquired"), then it's an entity.

> If the rule of thumb has to do with "the simplest" then is there a
> logical distinction for why deriving the name is simplest in the one
> case and deriving the date parts is simplest in the other or is this
> based on the tools used (having date as a built-in type, but not name,
> for example)? --dawn

It depends on what you mean by simple. In the case of a date, the parts are relative to a Calendar; for us in the U.S., a calendar date is the application of a Gregorian function to a point in time (measured as nanoseconds since 1900, for example), and of course moderated by timezone.

>From that point of view, the point in time is the "simplest." The date
displayed is more complex derived data. Thus extracting the parts is a set of functions, complex but thankfully usually implemented already in a library.

A useful example is marriage. For some apps, a boolean attribute on a Person relation is enough (meaning: "X is currently married"). For some apps, a relation with foreign keys to both spouses might be in order (relation predicate: "X is married to Y", commutative). For some apps, a date might be attached to that relation ("X married Y on date D"). For tracking church events, you'll have data about the church, minister, etc. If you're tracking polygamists, you'll have something different. Etc.

One person's attribute is another person's entity. It depends on the business case.

• Eric