Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The naive test for equality

Re: The naive test for equality

From: VC <boston103_at_hotmail.com>
Date: Thu, 11 Aug 2005 22:19:08 -0400
Message-ID: <4padnfk-d5CFmmHfRVn-qQ@comcast.com>

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:42fbac55$0$11073$e4fe514c_at_news.xs4all.nl...
> vc wrote:
>> mAsterdam wrote:
>>>VC wrote:
>>>
>>>>Presumably the team has meetings at which they discuss the
>>>>stuff they interested in and come to some agreement as to what
>>>>terminology they want to use and what the terms are
>>>>supposed to mean.
>>>
>>>Let me get this straight. In your methodology the terminology
>>>is ready (agreed upon) before the modelling starts?
>>
>> That's not what I said. I wrote 'they discuss the stuff they are
>> intersted in and come to an agreement as to what terminology they want
>> to use'. It can be rephrased as:
>>
>> Step one: discover the items/entities of interest;
>> Step two: give the entities names (or use the existing names if it
>> makes sense)
>
> And they wouldn't make sense if they where syn/homonyms?

Of course not. Why would one want to use the same name for two different entities [self-inflicted pain] ? If imagination is lacking, and one prefers to call an entity a Thing, one can use at least Thing1, Thing2,,, ad infinitum., if needed., in order to avoid the homonym problem. Synonyms are even easier, just use one, not two or more, names for the same entity and you should be all set.

>>>How do you propose to identify data objects and
>>>relationships from a requirement "It should be
>>>possible to find out where a piece
>>>of information came from."?
>>
>> Presumably 'a piece of information' can come from a newspaper article,
>> gossip, bank statement, or any other entity capable of producing such
>> piece of information. What's the problem with identifying the
>> information source ? If the requirement is literally as general as you
>> wrote, then it needs to be made more specific in order to be
>> realistically implemented.
>
> Of course - so what are the questions to ask to
> get the specifics of the requirement?
> Extrapolating from your assumption (newspaper article, etc)
> you'ld ask about /which/ pieces of information you want
> to know where it came from.
> Another one would be: what is it you want to know about
> where it came from?

Well, the attributes one wants to model surely depend on what the customer wants to do with them, sort of obvious, no ? Why not ask the customer directly about that ? E.g. with respect to a newpaper source something like the publisher, circulation, font, whatever, it really depends on what the customer wants to know. .

> Relevant, no doubt - but not adressing syn/homonym problem.
> But that makes sense, since you also stated that it
> shouldn't occur (I take it that 'self-induced'
> implies 'mistake' here - please correct me if I
> misinterpreted).

Right. I consider mistakes in trying to identify entities and their set of attributes (as well as relationships between entities), a more serious problem than largely overblown issues with synonyms and homonyms which are easy to avoid.

> In modelling sessions I recognize that
> people spend a lot of time to get the meaning of terms
> right for use in their model (IMO this is time well spent,
> especially for large systems).

The term meaning is the entity/attribute it names. When divorced from the object it names, the term is just a meaningless string of characters. No doubt, naming conventions are very important to make the understanding of a data model easier for humans (by analogy, association, etc), however, terminology is secondary in importance to entity/attribute/relationship discovery process.

> Some of the effort revolves
> around homonyms and synonyms. From what I read you explain
> this effort as (just) correcting mistakes. I think there
> is more about this that can be delt with in a systemic way - but
> only (this is just a hunch) if we appreciate that this is
> inherent to team modelling.

See above. Received on Thu Aug 11 2005 - 21:19:08 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US