Re: cdt

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40c32861$0$559$e4fe514c_at_news.xs4all.nl...
> Alan wrote:
>
> > Laconic2 wrote:
> >>Perhaps the problem lies in the word "implicit", in the term "implicit
> >>meaning". Perhaps what is implicit is subject to misinterpratation.
> >
> > Not if you know the difference between implicit and explicit, which you
have
> > provided by example, below. Implicit is implied, explicit is expressed.
> > Implicit is correct in this case. I'm fairly sure Drs. Elmasri and
Navathe
> > carefully considered which word to use, and that their editor reviewed
it
> > somewhere during the process of creating three editions of the book.
Try,
> >
> > Known facts that can be recorded and have _an implied_ meaning.
> >
> > They're not explicit until after they've been recorded (or stated, i.e.,
> > expressed).
> >
> >>Back in the days before databases, when COBOL programmers stored data
in
> >>records in files, the records had an "implicit" record definition. The
> >>COBOL programmer needed to include the correct record definition in the
> >>program in order to read the data. By including the data definitions in
> >>By including the data definitions in the
> >>schema, and putting the schema in the database, the definitions were
made
> >>"explicit" rather than "implicit".
>
> Column names, table names hint at meaning, they do not really define.
>
> It does not help rephrasing this in relational terms:
> The names of attributes and relational variables don't do
> a better job at defining. The meaning of the propositions
> conveyed by the tuples is supposed to be explained by
> the *external* predicate (3rd manifesto, 1st edition).
> "external" suggests that the authors do not think
> of the predicate as being part of the database
> - but I can't check this as I don't have the book here.
> The "definitions" in the schema only serve to associate
> the structure of the relation body with the relation header.

They are talking about "facts", not "attributes" (yet). An attribute is a classification description. A fact is an instance (to borrow an OO term) of that classification. For example, in a table EMPLOYEE, we have attributes ssn, last_name, first_name, etc.

last_name is an attribute; "Jones" is an instance of that attribute. We know from experience that Jones is often a last name, so "Jones" has implicit meaning to us even outside this table. It has explicit meaning as part of the row inside this table. It is a(n explicit) fact that Jones is the last name of an employee who is further described by other attributes and is uniquely identfied and associated with the other attribute instances on that row by his/her ssn. Received on Sun Jun 06 2004 - 18:52:54 CEST