Re: cdt glossary 0.1.3

mAsterdam wrote:

>---------------
>Glossary 0.1.3 "You keep using that word.
> I do not think it means
>january 2008 what you think it means"
>--------------- -- Inigo Montoya
>
>Maintainer: mAsterdam

[...]

I like it.
Some remarks.

>[Address]
>A value, used to identify a location.
>What is to be found there is up to the rest of the system.

You don't define "value" yet.

>An address is a value used to locate ...
>A reference is a value used to refer ...
>
>The difference between *locate* and *refer* is crucial here.

Yes, but perhaps it should be explained? Attempt: an address is a position in some address space: unlike references, on which the only meaningful operations are comparison for equality and dereferencing, operations such as ordering and subtraction are meaningful on addresses.

[...]

>[Data]
>"Known facts that can be recorded and have implicit meaning."
>-- Fundamentals of Database Systems, Elmasri & Navathe.

Not so good: the same data can have different interpretations.

[...]

>Warning: tongue in cheek definition
>Information is what you want. Data is what you are given.

Makes sense. What is more, this is the literal meaning of "data".

>[Entity]

and
>[Graph]

(I like what you have here.)

>[Information]
>0. data in context, data with meaning.
>(This implies a definition of data as being without context,
>without meaning - see data)
>1. new data to the receptor.
>2. available data, relevant to some decision or action.
>Also see [Data].

I don't think this correct: information is not data with meaning, it is meaning of data. Attempt: a bit of knowledge about the world, being transmitted, that will update the total knowledge about the world the receiver already has.

>[Information principle] (RM)
>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.

I understand the need for principles to be short, but without context this borders on the trivial.

>[Key]
>A value, used to identify something.
>See also primary key, and (TODO:) foreign key.

Not a value, but an attribute or set of attributes. (Or 'column(s)' if you prefer.)

The concept of key does not apply to individual objects or facts, but to classes of them; not to rows, but to tables.

>[NULL]
>Roughly: a special marker that can be put in a place
>inside a data structure where an actual value is expected.

Isn't this *exactly* what NULL is?

>Precisely what that marker means varies and there are at
>least three possibilities that are sometimes assumed:

[...]

Yes, but strictly speaking, none of that is part of what NULL is.

>[Object]
>1. Model of an entity, characterised by behaviour and state. (ISO)

That's pretty lame if you ask me.

>[Primary key] (SQL, not RM)
>A key of a table, composed of one or more
>named columns, uniquely identifies a row in a table.

Only if you mean: such that every row's values for its key columns uniquely identify that row in the table.

>A table can have only one primary key.

In other words: one such key, picked by the schema designer. (How? I don't think there is a single universal criterion.)

>[Pointer]
>See address(*).

Yes.

>[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.

I think you're right.

>[Relation]

[...]
>[Table/Column/Row] (SQL-DBMS)

[...]

A frequent distinction between relations with attributes and tuples on one hand and tables with columns and rows on the other is that rows and columns are usually assumed to be ordered, while attributes and tuples are not. Another is that tables are considered to be some visual or textual representation of relations. But neither of those distinctions are universal in this newsgroup.

>[Theory]
>"Database management is a practical matter.
>Any so-called theory of database management that
>doesn't facilitate the practice would be nothing
>but self-indulgent conjecture.
>Theorists (should) want to know about what goes
>on in practice just as much as practitioners should
>want to know what theory has to say."
> -- Roy Hann, cdt dec 11, 2007

All this quote tells us is that the opposition of theory and practice is easily misunderstood to mean that theory and practice contradict each other, are at odds with each other. (Compare: design and evolution.)

>[Type]
>" TYPES are sets of things we can talk about;
>RELATIONS are (true) statements bout those things."
>-- Chris Date, Feb 2004

This is just wrong. A type is *not* a set. It is a description of what certain individuals look like. Often, types and sets are used together, e.g. we often speak of the set of all individuals of a particular type, or we assume that all members of a sets have the same type. But they are complementary notions.

>1. Set of possible values (i.e. IT equivalent of math 'domain').
>2. Set of possible values plus
>all possible operators defined on them. (i.e. synonymous to Class
>if 'class' is meant to include a possible set of values).

In the object-oriented world, a type is not a set; a class may be. Often, type and class are both used, with connected, but different meanings (e.g. in .NET, every class is of a certain type, but not every type is the type of a class).

>[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")

Does the Third Manifesto use the term 'class'?

>[Transaction]
>A set of database operations constituting a logical unit of work.

Rather: an explicit construct that imposes the treatment of a sequence of database operations as a single unit of work.

>Most DBMS include the ability to rollback complete transactions
>when an error is detected.

>[[Issues]]
>
>RELATIONs vs. RELATIONSHIPs
>Can namespaces help to make some distance? In this case:
>RM.RELATION vs. ER.RELATIONSHIP

Good idea.

-- 
Reinier