Re: Relation or attribute and why
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 23 May 2006 21:27:02 GMT
Message-ID: <G6Lcg.12085$A26.287886_at_ursa-nb00s0.nbnet.nb.ca>
>
>
> 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.
>
>
>
>
> 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.
>
> 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.
Date: Tue, 23 May 2006 21:27:02 GMT
Message-ID: <G6Lcg.12085$A26.287886_at_ursa-nb00s0.nbnet.nb.ca>
erk wrote:
> 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.
And frankly, on the application too, which is why logical independence is so important. Received on Tue May 23 2006 - 23:27:02 CEST