cdt glossary [several items]
Date: Sat, 02 Feb 2008 18:46:16 +0100
Message-ID: <47a4ab3c$0$85791$e4fe514c_at_news.xs4all.nl>
rpost wrote:
>> [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.
I'll take this as a suggestion to add [Value] to the to-do list. "Value" can indeed be problematic as we see whith NULL and Key.
>> 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 ares/meaningful //
> comparison for equality and dereferencing, operations such as > ordering and subtraction are meaningful on addresses. s/meaningful/possible/
Ok?
> [...] >
>> [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.
Only when you adhere to the idea that data may have no meaning. As explained under [Information], this idea has caught on /outside/ the database realm.
> [...] >
>> 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".
:-) , but I am not going to explain the joke in the glossary.
...
>> [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.
That is a new one to me. Do you have a soure?
> Attempt: a bit of knowledge about the world, > being transmitted, that will update the total knowledge about the > world the receiver already has.
Media, Sign, Symbol, Data, Information, News, Meme, Knowledge, Wisdom; borderlines between these shift even within discussions. Is it feasible or even sensible to fixate these lines (yet)?
A short explanation of how you use terms in this area will be necessary to prevent or end misunderstandings anyway.
I like these communication layers (bottom to top): Fatic, Syntactic, Semantic and Pragmatic - but I mostly take care to explain when using them, sometimes even dropping the term itself.
>> [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.)
Not just a value, but not just a set of attributes either. The key as a set of attributes forms a constraint on which values to use for identification.
Improvements welcome.
> 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?
Arrgggh! (just search for 'NULL' in the archives for why). Any objections to s/Roughly: a/A/ ?
>> 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.
Strictness is only an issue for the glossary in so far as it helps
preventing misunderstandings.
Believe me, there were misunderstandings in this area.
>> [Object]
>> 1. Model of an entity, characterised by behaviour and state. (ISO)
>
> That's pretty lame if you ask me.
Good. Yes, I'm asking you :-)
Coming up with an agreeable definition of 'Object' in cdt
will earn you real beer (in Amsterdam).
>> [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.
Yes. Now how to rephrase this with only adding the necessary complexity?
>> 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.)
It is a trade-off. I like the list Bob Badour uses, e.g. in thread "Separate PK in Jxn Tbl?" he wrote:
> The design criteria for keys are: > uniqueness, irreducibility, simplicity, stability and familiarity > (in no particular order.)
...
>> [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.
Columns may be ordered or named.
There are corresponding formalisms: the unnamed (why not 'ordered'? I really need to read the Alice book) perspective and the named perspective. I just learned that.
> 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.
Yes. The qualification (SQL-DBMS) is explicit nevertheless.
>> [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.
It is meant as an educational step, not a formal definition.
He really said it. I was there.
I even asked him if it was ok to quote it.
If you don't agree you'll have to ask him.
> A type is *not* a set.
http://en.wikipedia.org/wiki/Type_system says "A type indicates a set of values that have the same sort of generic meaning or intended purpose"
indicate, is .. It depends on what your definition of is is. Why am I suddenly thinking of cigars?
> 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.
Do you have a reference? The object-oriented 'world' is quite diverse, often vague, and sometimes off-beat in its use of terms (The scarequotes are because I see object orientation as just a collection of ways to organize program-code, not a paradigm, let alone a world).
> 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'?
First edition, P 15:
In discussing "What concept is it in the relational world that is the
counterpart to the concept /object class/ in the object world",
(yes, the same megalomania here, twice) they argue that the answer to
this question should be "domain".
>> [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.
For the sake of consistency, we want a logical unit of work to be carried out or not.
Wether the unit is implicit or explicit matters in the ease of its discovery, nothing more.
A sequence implies order of the elements and would require serial execution. Wether the elements are executed serially or in parallel is not relevant.
>> 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.
Thank you, and thank you for contributing.
Bonus exercise: Pinpoint the fatic, syntactic, semantic and pragmatic aspects of the content of these instructions.
<unsnip>
>> How to contribute
>> -----------------
>>
>> Content:
>> Please keep in mind that the focus of the glossary
>> is on /real/ c.d.t. misunderstandings.
>>
>> Some discussions, after many sidetracks, are reducible
>> to /just/ different meanings and connotations of a word.
>> The differences could be resolved with just:
>> "Ah, now I see what you meant by that; next time I'll
>> be a little more careful in my choice of words".
>> Such words are nice glossary candidates.
>>
>> Examples from the past: Address, Domain.
>>
>> Sometimes, though, It's not just different connotation
>> or meaning which leads to the long winding talks
>> without communication. These differences go down to
>> deeply held strong opinions.
>> Some differences in the use of words run much deeper than
>> we can hope to clear up with just some definitions and
>> warning signposts. They might help a little anyway, so
>> these nastier entries are welcome, to.
>>
>> Examples from the past: NULL, Flat.
>>
>>
>> Form:
>> Please post your proposal as copy & pastable text,
>> with a subject line like this:
>>
>> subject: cdt glossary [Identity]
>>
>> Please also check spelling and grammar mistaeks.
>>
>> Thank you for contributing.
</unsnip>
Fatics: "How to contribute" and "Thank you for contributing" Syntax: Form: etc... Praxis: Please keep in mind ...
Semantics: The remainder. Received on Sat Feb 02 2008 - 18:46:16 CET