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: 11 Aug 2005 10:38:47 -0700
Message-ID: <1123781927.538919.310930@g44g2000cwa.googlegroups.com>

dawn wrote:
> VC wrote:
> > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > news:1123732114.308246.150230_at_g49g2000cwa.googlegroups.com...
> > > VC wrote:
> > ....
> > >
> > >> You are kidding, right ? If the modellers chose the name/label "source"
> > >> and
> > >> did not define what entity the name refers to, then the name is just
> > >> meaningless, like say "fshsalkfd". Apparently, your hypothetical
> > >> modellers
> > >> are not modellers but some kind of impostors.
> > >
> > > It is usually much more subtle than that. Everyone agrees that we need
> > > to know whether or not someone is a fullTimeStudent. Ignore the fact
> > > that this would likely be a derived attribute -- it illustrates the
> > > problem. After some sessions with folks from many departments, the
> > > analyst works to get more precision and sits down with someone who
> > > knows all of the tuition rules, along with another person ('cause the
> > > analyst is no rookie) and they nail down this attribute with the
> > > precision of a surgeon.
> > >
> > > The system goes live and the financial aid people are irate! Federal
> > > aid has just been removed from students because they were no longer
> > > flagged as being a fullTimeStudent when by the standards for this
> > > financial aid, they clearly ARE a fullTimeStudent.
> > >
> > > Then you find out that these two departments use the very same term and
> > > might even both have external reasons to use the very same term, and
> > > they use it with just slightly different meanings.
> > >
> >
> > Apparently, the analysts made a mistake in assuming that the set of
> > fullTimeStudents is equal to the set of studentsEligibleForFinancialAid.

>

> In this case, yes, but it also happens frequently where such a term is
> used the same when the analysis is done, but something changes
> (government regulation or something more subtle) that changes the
> meaning slightly for one group and not another, so that these
> differences creep in.

That's life. If the analyst was unable to anticipate some changes, then they can be introduced later. It's called schema evolution.

>

> > I
> > did not claim that one can correctly analyze a complex system at one go,
> > it's an iterative process of trial end error.
>

> and needs to be attended to for the life of the attribute name
>

> > Besides, your example is
> > *not* about naming issues (as you understand yourself)
>
> I thought it was about the name and def of an attribute.

It most certainly was not. It was about an incorrectly specified predicate defining set of students eligible for financial aid. What attribute (and its name) did you have in mind ?

>

> > -- presumably there
> > was no ambiguity about the "student" entity .
>

> There are always differences of opinion about what constitutes a
> student on a campus. Finance people often use the term as if the
> student were the same as a corporate customer. Student = Customer. If
> someone has received some approval to audit a course for zero dollars,
> the instructor might consider them a student.

In this case, during the analysis stage, one could have identified a more generic entity, say, Person with entity subtypes of Student and Customer.

> That is just an example,
> but the point is that entity names are also just words and are
> interpreted by humans, each of whom brings a different context to the
> meaning of the word.

You are quite right that names are just words without any specific meaning [in the modelling context]. That's why it's necessary to identify the actual entities (attributes, relations, etc) first and then give them names. That's what, among other things, modelling is about, no ?

>

> I've been reading and writing too fast lately and might have missed the
> point, so I'll re-read the thread before posting again.
> cheers! --dawn
Received on Thu Aug 11 2005 - 12:38:47 CDT

Original text of this message

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