Re: cdt

Looks good, though I propose some very minor changes (in line) marked with =====>>>>>

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40c30358$0$568$e4fe514c_at_news.xs4all.nl...
> [address]
> A value, used to identify a location.
>
> [change management]
> The organization of data within a database can and will
> change with circumstances, and the database should provide
> facilities for changing this structure with minimum
> inconvenience.

=====>>>>> "minimum inconvenience" is kind of vague. This definition sort of restates one of the basic conditions needed for an RDBMS: the notion that the underlying structure can be changed without affecting what is already stored. IOW, for example, you can add a column to a table without losing what is already there. Don't know how I'd rephrase it...

>
> [data]
> "Known facts that can be recorded and have implicit meaning."
> -- Fundamentals of Database Systems, Elmasri & Navathe :
>
> When people discuss data in the context of database,
> they are usually talking of something with meaning.
> There are people who think that data doesn't need
> to mean anything. http://en.wikipedia.org/wiki/Data
> (currently) says "data on its own has no meaning".
> Somehow this "data has no meaning" idea has caught on.
>
> 1.a.. facts
> 1.b. a record on a medium of some fact in the 'real world'.
> 2. encoded information
> 3. combination of sign and meaning.
>
> [database]
> "A logically coherent collection of related real-world data
> assembled for a specific purpose." -- rephrased from
> "Fundamentals of Database Systems", Elmasri & Navathe.
>
> [data model]
> data models are artificial constructs and can

=====>>>>> I would change "can never" to "may not". Sometimes they do represent completely.

> never completely represent the true nature of information, and goes on
> to provide various philosophical examples of recategorization.
> ... these categories already
> exist, to some degree, in the way information is handled. Databases
> don't exist in vacuo; they're fed (and consulted) by users who would
> have some system of mental categorization even if they were shuffling
> everything around with paper and pencil.
>
> [fact]
> 1. A piece of information about circumstances that exist or
> events that have occurred
> 2. A concept whose truth can be proved.
> 3. A statement or assertion of verified information.
> 4. An event known to have happened or something known to have existed.
>
> [information]
> 0.a. synonymous to data

=====>>>>> The term is sometimes used this way, but in our theoretical world, I believe it is important to make the destinction as you have below in 0.b. I would leave out 0.a for clarity's sake.

> 0.b. data in context, data with meaning.
> (Implies a definition of data as being without context,
> whithout meaning - see data)
> 1. new data to the receptor.
> 2. available data, relevant to some decision or action.
>
> [information principle]
> Date/Codd:
> Chris Date in "EDGAR F. CODD 08/23/1923 – 04/18/2003 A TRIBUTE":
> The entire information content of a relational database
> is represented in one and only one way: namely, as
> attribute values within tuples within relations.
>
>
> [key]
> A value, used to identify something.

=====>>>>> "uniquely (as in PK, CK) identify or relate (as in FK)"

>
>
> [MV]
>
> Anthony W. Youngman (PICK File, record, field)
> FILE: a real-world collective noun.
> RECORD: a real-world object.
> FIELD: is a real-world adjective.n.
>
>
> [type - 3rdM]
>
> In The Third Manifesto a type is:
> - a pattern (possible representation)
> - a domain for some operators (THE_xxx operators)
> - a codomain for some operators (the "constructors")
>
> There is a requirement for the 'domain' and the 'codomain'
> to be the same set.
>
> [pointer]
> A pointer is an address(*) used to locate something.
> What is to be found there is up to the rest of the system.
>
> [reference]
> A reference is a value, used to refer to something.
> A program can get the current value of that something
> (without ever knowing where it resides) by dereferencing,
> even if that something has been relocated between
> the time of first reference and the dereferencing.
>
>
>
>
> (ISSUES)
>
> [meaning vs use]
> Say we currently have a validated statement
> about the exchange rate of some stock at some
> recent time.
>
> 1. It does not matter to the meaning
> where/how this statement is represented. We have it.
> 2. To the use of it it is important where/how
> it is represented, and available to relevant actors.
> 3. Twenty years later the meaning of this statement
> is still the same.
> 4. Twenty years later most of its usefullness will
> probably have gone.
>
> It may be --- in some instances -- not appropriate to make this
> distinction. The meaning of data is always contextual.
> The same bit of data means different things to different
> structured viewpoints within the organization, for example,
> and at different times (epochs). One grain of sand does not
> form a beach. One bit of data itself has little meaning.
> It is rather the collective of all data that possesses greater
> notion of meaning.
>
>
> [pointers, references and keys]
>
> While references may be implemented as pointers,
> the programmer prefers not to know (if he prefers
> to know he should have used pointers.
>
> A pointer is a special kind of type. One can declare variables of a
> pointer type, and these variables can have pointer values.
>
> A pointer type is a type for which two operations are supported:
> referencing and dereferencing.
>
> The dereferencing operation takes a pointer *value* and returns a
> *variable* of the type the pointer refers to.
>
> The referencing operation is the inverse operation. It takes a
> *variable* and returns a pointer *value*.
>
> Java references are pointers in the above sense. The term pointer was
> avoided in Java because the term pointer is often used in a more
> restricted sense, meaning physical memory addresses.
>
> Relational keys are definitely not pointers.
>
> (logical pointer)
> logical pointers as in navigational information from a foreign
> key in one relation to a primary key in another (effectively
> a mapping).
>
>
> [table, row, column]
> table: A sentence that has not yet been uttered,
> because it relates unknown values.
> row: A statement of fact, as an utterance of the "meta" sentence
> described above.
> column: any piece of utterable information.

=====>>>>> I see where you're going, but unless the following is understood, it could be confusing. Okay, this one isn't minor Trying to keep it general irrespective of normal form, but still giving it context:

Table: A collection of rows and columns. Row: A collection of attributes.
Column: An attribute of an entity.
Entity: The subject about which the table is concerned.

I know this is slightly reflexive, but as you have already indirectly specified, these terms are best understood as they relate to each other. You could probably combine the two different takes on this.

>
Received on Sun Jun 06 2004 - 14:20:52 CEST