(repost) cdt glossary 0.1.1
mAsterdam
Glossary 0.1.1: "You keep using that word.
I do not think it means what
february 2006 you think it means"
--------------- -- Inigo Montoya
Maintainer: mAsterdam
Preamble:
---------------
This glossary seeks to limit lengthy misunderstandings
in comp.database.theory. This newsgroup uses terms from
database modeling, design, implementation, operations,
change management, cost sharing, productivity research,
and /or basic database research.
People tend to assume that words mean what they are
accustomed to, and take for granted that the other
posters have about the same connotations.
They don't always.
It consists of signposts: watch out! You may think the OP
means A but she might mean B. Alternative names and views
of the same concept are introduced when the danger
of mutual misunderstandings is appearant.
When context matters, it is provided. The glossary
is a highly biased list of problematic concepts.
Some words are particularly suspect:
data (!), database, object, normalisation.
Some just cause minor annoyances, the misunderstanding
is cleared and the discussion goes on:
domain, type, transaction.
We don't know well-accepted, formal or comprehensive
definitions for everything. If you do have a useful
reference, please provide it.
If an informal description is all we have, so be it.
What the glossay is not:
---------------
The glossary is not a dictionary or encyclopedia, such as
FOLDOC, Wikipedia (http://www.wikipedia.org), and the Web
Dictionary of Cybernetics and Systems.
Specific links to serve the glossary's purpose are welcome,
of course. Also, it does not try to be a FAQ for "all
things database".
Credits:
---------------
The glossary is built from contributions.
Contributions from within this group are
not credited, quotes from elsewhere are.
If you want your name stated please say so.
If you want to contribute, see the notes at the end.
==============
[Address]
A value, used to identify a location.
What is to be found there is up to the rest of the system.
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.
[Change management]
Many organizations have a CM process in place in
order to make their evolution more manageable.
The organization of data within a database can
and will change with these changing circumstances.
A DBMS should provide facilities to support this.
Changing the underlying structure should be
possible without affecting what is already stored.
For example, you can add a column to a table without
losing what is already there.
Related adjectives: maintainable, agile, flexible, adaptive.
[Class]
A class is what provides a name and a place for
the abstract behavior of a set of objects
said to belong to the class. (Larry Wall, Apocalypse 12)
note:
Other definitons welcome, this goes for the rest as well,
of course.
Some use 'class' as having exposed data.
Please be explicit about this if you do so.
[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/Information#Information_is_not_data
(currently) says "information has meaning (i.e.: can inform),
while data does not. ".
Somehow this "data has no meaning" idea has caught on.
1a. facts
1b. a record on a medium of some fact in the real world.
2. encoded information
3. a combination of sign and meaning
Warning: tongue in cheek definition
Information is what you want. Data is what you are given.
[Database]
"A logically coherent collection of related real-world data
assembled for a specific purpose." -- rephrased from
"Fundamentals of Database Systems", Elmasri & Navathe.
1. Deluxe filesystem
2. Shared databank (E. Codd)
[Data model]
"an abstract, self-contained, logical definition
of the objects, operators, and so forth, that
together constitute the abstract machine with
which users interact. The objects allow us to
model the structure of data. The operators allow
us to model its behavior."
(C. J. Date, An Introduction to Database Systems,
8e, 2003, p 15-16)
Data models are artificial constructs and may not
completely represent the true nature of information
and categorization. These categories already
exist, to some degree, in the way information
is handled outside the database.
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.
[Dimension]:
1) A synonym for degree.
A relation R is of degree n if each tuple in R is an n-tuple.
2) An n-dimensional data structure, S, is one where each
element of S can be uniquely addressed as S[i1][i2]...[in]
Note: Because a table in a SQL-DBMS can be seen as a
conventional visualization of a mathematical relation
where the dimension is as in 1) above, and can also be
manipulated using a general purpose programming language
with the dimension using 2) above being equal to 2, there
can be confusion when using this term.
In this forum, use definition 1) freely and try to either
avoid 2) or be very clear, such as "2D array," when employing
definition 2).
[Domain]
1. Given a relation R, a domain is a set Sn such that
for each tuple (A1, A2, ...An, ...Am) in R,
An is an element of Sn.
2. A domain is a set of values: for example
"integers between 0 and 255",
"character strings less than 10 characters long",
"dates".
Sometimes used synonymously with type.
[Entity]
Thing of interest. (ISO)
"An entity is a 'thing' which can be distinctly identified. A specific
person, company, or event is an example of an entity. "
("The Entity-Relationship Model-Toward a Unified View of Data", 1976, P.
Chen., http://www2.cis.gsu.edu/dmcdonald/cis8140/Chen.pdf )
Edward Yourdon, who describes E/R in his work Modern Structured
Analysis, (Prentice Hall 1989) defines the concept of Entity
as having three properties:
1. Each representation of an entity can uniquely be identified
2. Each representation of an entity is playing an important role in
the system it lives in. (it has to have a reason to be there)
3. Each representation of an entity can be described by one or more
attributes (data-elements, like name, age, quantity)
This term is often used when doing conceptual data modeling.
When it is used with a particular product, technique, or technology,
such as XML, refer to the use of the term within that "namespace" using
an adjective, such as "XML entity" to distinquish it from the more
generic use of the term.
For subtleties (e.g. strong and weak entity) -
please search the web.
[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.
[Flat]
1) An object which by any definition could be considered as 2
dimensional might informally be called flat.
2) (controversial:)
The absence of hierarchy (multiple levels of details).
Note: Any use of the term flat tends to be seen as inflammatory by
someone, so take care to use it only when intending to inflame ;-)
[Function]
For now we have to live with different meanings
of _function_ when talking about databases:
"The function of this function is to get the tuples from B
that are functionally dependant on A."
Three different contexts, but just about the same meaning:
General
A purpose or use.
Math
A binary mathematical relation with at most
one b for each a in (a,b).
Software
A subroutine, procedure, or method.
notes:
every operator is a function
every function is a relation
Please be specific.
[Information]
0. data in context, data with meaning.
(This 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] (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.
[Key]
A value, used to identify something.
See also primary key, and (TODO:) foreign key.
[Meaning]
(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.
[MultiValue, MV]
1. One name for the industry surrounding the Nelson-Pick data model.
In this context:
FILE: a real-world collective noun.
RECORD: a real-world object.
FIELD: is a real-world adjective.n.
2. A data field (or attribute) defined to permit a variable number of
values as a list (array).
[NULL]
Roughly: a special marker that can be put in a place
inside a data structure where an actual value is expected.
Precisely what that marker means varies and there are at
least three possibilities that are sometimes assumed:
(1) "Unknown value" This means that on the place of the marker
there should actually be a value but this value is not known
at the present time. For example, if a 'name' field in a tuple
describing a person is 'null' then this person will have a
name but we don't know it.
(2) "Absent value" This means that the property that is
described by the value in question is simply not defined.
For example, if the 'shipping-date' field in a tuple
describing an order is 'null' then the order was
not shipped yet.
(3) "Whatever SQL says it means" The exact meaning is hard to
summarize briefly, but is a mixture of the previous two
interpretations and involves a value with three truth-values
('true', 'false' and 'unknown').
Common usage:
- Confusion arises when people use terms like "null value",
a paradox to some, a contradictio in terminis to others.
- Confusion arises due to the fact that nullness (the absence
of value) is often represented on computers by the number 0.
(Obviously, 0 is not null.)
- In some contexts, 'null' and 'nil' mean the same thing;
in others, they do not.
In databases traditionally NULL is used and and opposed.
If you want to go into this, please first search for
mu NIL void NULL undef, 2VL 3VL.
"It isn't the things we don't know that give us trouble.
It's the things we know that ain't so." - Will Rogers
Note: Several better proposals have been made for this
entry. Unfortunately they all led to huge threads where
the maintainer couldn't decide which texts to quote here.
[Object]
1. Model of an entity, characterised by behaviour and state. (ISO)
2. Something intelligible or perceptible by the mind.
[Table/Row/Column] (SQL-DBMS)
Table: A collection of columns (the table header) and rows (the body).
Row: A collection of values, conforming to the table header columns.
One table may contain data about one entity,
about several entities, about one or several
relationships or any combination.
A column can be seen as the attribute of the
entity/one of the entities/relationships
about which the table is concerned.
[Primary key] (SQL, not RM)
A key of a table, composed of one or more
named columns, uniquely identifies a row in a table.
A table can have only one primary key.
[Type]
" TYPES are sets of things we can talk about;
RELATIONS are (true) statements bout those things."
-- Chris Date, feb 2004
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).
This is highly misunderstanding-prone area, so please
take some care to be specific.
[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]
See address(*).
[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.
[References, pointers, keys]
While references may be implemented as pointers,
the programmer prefers not to know (if he prefers
to know he should have used pointers).
In some programming languages one can declare
variables of a pointer type - these variables
can have pointer values.
m.m. (mutatis mutandis) reference.
Two operations are supported:
referencing and dereferencing.
On references only these operations are possible.
On pointers other operations are possible.
The dereferencing operation takes a pointer
*value* and returns a pointer *variable* of
the type the pointer refers to.
The referencing operation is the inverse operation.
It takes a *variable* and returns a pointer *value*.
m.m. reference.
In Java the term pointer was avoided
because pointer is often used to mean
physical memory addresses.
Relational keys are not pointers.
[Relation]
1. A relation is a subset of the set of ordered
tuples (A1, A2, ... Am) formed by the Cartesian
cross-product of sets S1 x ... x Sm where each
An is an element of Sn.
Note: A set, Sx, is not restricted from participating
as a member of a relation more than once.
Distinction between identical sets in math is possible
through ordinal numbering such that given sets Sx and Sy,
x <> y AND Sx is a subset of Sy and Sy is a subset of Sx;
in relational theory, in contrast, it is by attribute name.
2. ...
[Transaction]
A set of database operations constituting a logical 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
represented vs. described
RELATION(SHIP)s vs RELATION(SHIP)s SET
fact vs. thing (ENTITY).
First Order Logic vs. Higher Order Logic.
What, if there is, is the equivalent of an ENTITY(SET) in the RM ?
Does it make sense to talk about attributes of a fact ?
How are those different from ATTRIBUTES of an ENTITY ?
Traditionally there can be Multivalued ATTRIBUTES
in ER, RM has atomic ATTRIBUTES.
So: RM.ATTRIBUTE and ER.ATRRIBUTE ?
In ER modeling, a RELATIONSHIP is defined over ENTITIES:
"A relationship is an association between several entities."
In RM, a RELATION is defined over VALUEs.
What is the difference between ENTITIES and VALUEs ?
=============
[[ToDo]]:
(please feel invited to write entries for these)
Application
Attribute
Concept
Dynamic vs static
Hierarchy
Identity
Normalize
Location
Persistence
Operator
Orthogonal
Scalar
Feel free to post suggestions to add or remove.
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 longwinding 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 subjectline like this:
subject: cdt glossary [Identity]
Please also check spelling and grammar mistaeks.
Thank you for contributing.
----
Milestones? For the glossary I prefer inch-pebbles.
mAsterdam
Glossary 0.1.1: "You keep using that word.
I do not think it means what
--------------- -- Inigo Montoya
Maintainer: mAsterdam
What the glossary is not:
note:
Other definitions welcome, this goes for the rest as well,
of course.
an adjective, such as "XML entity" to distinguish it from the more
generic use of the term.
For subtleties (e.g. strong and weak entity) -
please search the web.
[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.
[Flat]
1) An object which by any definition could be considered as 2
dimensional might informally be called flat.
2) (controversial:)
The absence of hierarchy (multiple levels of details).
Note: Any use of the term flat tends to be seen as inflammatory by
someone, so take care to use it only when intending to inflame ;-)
[Function]
For now we have to live with different meanings
of _function_ when talking about databases:
"The function of this function is to get the tuples from B
that are functionally dependent on A."
Three different contexts, but just about the same meaning:
General
A purpose or use.
Math
A binary mathematical relation with at most
one b for each a in (a,b).
Software
A subroutine, procedure, or method.
notes:
every operator is a function
every function is a relation
Please be specific.
[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.
[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.
[Key]
A value, used to identify something.
See also primary key, and (TO DO:) foreign key.
[Meaning]
(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 usefulness will
probably have gone.
Common usage:
[Pointer]
See address(*).
2. ...
=============
[[Issues]]
represented vs. described
RELATION(SHIP)s vs RELATION(SHIP)s SET
fact vs. thing (ENTITY).
So: RM.ATTRIBUTE and ER.ATTRIBUTE ?
In ER modeling, a RELATIONSHIP is defined over ENTITIES:
"A relationship is an association between several entities."
In RM, a RELATION is defined over VALUEs.
What is the difference between ENTITIES and VALUEs ?
=============
[[TO DO]]:
How to contribute
-----------------
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:
paul c
Okay, don't want to risk a premature definition but here's a stab at an
analogy/comparison for "persistence", a word that gets under my skin
most of the time I see it used here:
If nothing changes but the time of day, what was true yesterday is still
true today.
I may be wrong to see it this way, but this is why I don't associate the
acronym "rdms" with persistence, necessarily.
p
paul c
p
mAsterdam
> paul c wrote:
>
>> mAsterdam wrote:
>>> Milestones? For the glossary I prefer inch-pebbles.
>>
>> Okay, don't want to risk a premature definition but here's a stab at
>> an analogy/comparison for "persistence", a word that gets under my
>> skin most of the time I see it used here:
>>
>> If nothing changes but the time of day, what was true yesterday is
>> still true today.
>>
>> I may be wrong to see it this way, but this is why I don't associate
>> the acronym "rdms" with persistence, necessarily.
>>
>>
It appears there is a /real/ misunderstanding regarding
the term persistence when discussing databases -
so it is an appropriate candidate entry.
The first time I saw the term persistence described was
(somewhere around p. 374) in a book I very much enjoyed by Charles
Rumbaugh http://www-306.ibm.com/software/rational/bios/rumbaugh.html
I think it was
http://www.amazon.com/gp/product/0136298419/002-3586986-4592833?v=glance&n=283155
but mine is red and I can't find it.
I'll crosspost to comp.object, they may help.
(Please read the cdt glossary first).
BTW did you really have to quote the whole glossary?
Just scrolling up and down might cause RSI :-)
Proposals welcome!
paul c
> paul c wrote:
> ...
> BTW did you really have to quote the whole glossary?
> Just scrolling up and down might cause RSI :-)
Sorry, I get a little mixed-up sometimes, usually in the physical
discourse, by using a mac kb on a pc, plus other reasons which are OT.
btw, while i don't object to a glossary, i do like to see examples in
dic's, because English and the other languages are so open to
misinterpretation. i'll try to think of an example that illustrates
persistence or not.
p
ps: i doubt if posting to the oo group would help, likely to cause more
smoke than fire, dragging in the usual red herrings, plus misreadings of
western law. i wish the fanatics there (go ahead, sue me) would get
back to their natural topic, namely programming technique and stay out
of here, no offence meant to you.
Bob Badour
> mAsterdam wrote:
>
>> ---------------
>> Glossary 0.1.1: "You keep using that word.
>> I do not think it means what
>> February 2006 you think it means"
>> --------------- -- Inigo Montoya
>>
>> Maintainer: mAsterdam
>>
>> Preamble:
>> ---------------
>> This glossary seeks to limit lengthy misunderstandings
>> in comp.database.theory. This newsgroup uses terms from
>> database modeling, design, implementation, operations,
>> change management, cost sharing, productivity research,
>> and /or basic database research.
>>
>> People tend to assume that words mean what they are
>> accustomed to, and take for granted that the other
>> posters have about the same connotations.
>> They don't always.
>>
[snip]
I don't really know who created this glossary or who contributed what.
However, I note that we already have a recognized standard for the bulk
of the terms we use, ISO/IEC 2382 Standard Vocabularies for Information
Technology, and I note that some of the most fundamental definitions of
our field in this glossary are just plain wrong. One might think a
self-aggrandizing ignorant like Dawn wrote them. And I suppose it should
come as no surprise the maintainer has proved he lacks intellectual honesty.
paul c
i'll stick my neck out and say that committee definitions are usually crap.
p
mAsterdam
I have no desire whatsoever to engage in this stupid game.
Bob Badour wrote:
> I don't really know who created this glossary or who contributed what.
> However, I note that we already have a recognized standard for the bulk
> of the terms we use, ISO/IEC 2382 Standard Vocabularies for Information
The glossary has no ambition to compete with
ISO/IEC 2382. It focuses on /real/ misunderstandings in c.d.t.
In his overzealousness to expose "VI" and what have you
the stalker did not notice that.
> Technology, and I note that some of the most fundamental definitions of
> our field in this glossary are just plain wrong. One might think a
> self-aggrandizing ignorant like Dawn wrote them.
> And I suppose it should
> come as no surprise the maintainer has proved he lacks intellectual
> honesty.
I resent that. It hurts. I have no direct defense because
I am in the stalkers twit-filter.
I can't even ask Bob to say what caused him to think that.
The sharpness of his observation of intellectual
dishonesty with other people makes it even more embarrassing.
Bob Badour
Committee or no, the ISO/IEC vocabularies are very good, reflect well
what educated people mean when they use various terms, and are very
illuminating.
Creating a misleading and incorrect glossary through the volunteer
contributions of vociferous ignorami is counter-productive and just
plain dumb.
paul c
sure, but the same argument applies to acknowledging idiots.
[
mAsterdam
Good to see that according to Bob Badour the ISO/IEC illuminatingly
addresses the misunderstandings we have here.
> Creating a misleading and incorrect glossary through the volunteer
> contributions of vociferous ignorami is counter-productive and just
> plain dumb.
Please, Bob Badour-fans (as Bob twit-filtered me),
point out the misleading entries.
Also, please explain how addressing real misunderstandings
in a group is counter-productive and just plain dumb.
mAsterdam
> Bob Badour wrote:
> i'll stick my neck out and say that committee definitions are usually crap.
Yes, and thank you.
Yet - I trust Bob well enough to check out ISO/IEC 2382 tomorrow -
even if he decided to twit-filter me for intellectual dishonesty.
My belief is he made a mistake in that - probably triggered by
one of the mistakes I made.
But he twit-filtered me - so no dialogue.
mAsterdam
Could you be a bit more verbose?
paul c
i could, but i hope i can restrain myself as it would be pointless.
there's not much, since you ask me, that can be usefully said on this
subject and this medium doesn't enable a meeting of minds in other ways
much, such as boxing matches or drinks together. can't comment about
academic discussion since i'm not an academic. i'll try to stop my
outbursts and i hope the cross-posters can stop their self-publicity
too. i think the oo group is the proper place for most of this silliness.
there are so many more challenging topics to explore that have nothing
to do with OO. just my two cents.
p
Marshall
> mAsterdam wrote:
>
> Okay, don't want to risk a premature definition but here's a stab at an
> analogy/comparison for "persistence", a word that gets under my skin
> most of the time I see it used here:
>
> If nothing changes but the time of day, what was true yesterday is still
> true today.
>
> I may be wrong to see it this way, but this is why I don't associate the
> acronym "rdms" with persistence, necessarily.
Paul,
A small request: please snip a bit more. If the quoted context
exceeds the new content by a factor of more than say 3,
there's going to be difficulty finding the new content.
Thanks,
Marshall
paul c
"real misunderstandings" don't go away. in diplomatic circles the way
treaties are achieved is by changing the subject to one that the
misunderstanding parties don't consider crucial. all that does is leave
it for the next generation but i'm not interested in peace with the oo
progagandists, i just want them to keep their mischief elsewhere, as i
think they would prefer since there's little money here. the only value
in language, such as English is in prompting thought. agreement is not
inevitable in any human discourse and i wish more people would stop
dreaming it is. the only misunderstandings i want to discuss here are
my own as far as db is concerned, not various opinions about a
completely different field.
p
paul c
yes, i already apologized for that.
p
Marshall
> Marshall wrote:
> > Paul,
> >
> > A small request:
>
> yes, i already apologized for that.
Yeah, I hadn't read the whole thread when I posted.
So now it is my turn to apologize.
Sorry. :-(
Marshall
Marshall
> ... we already have a recognized standard for the bulk
> of the terms we use, ISO/IEC 2382 Standard Vocabularies for Information
Bob,
Is this document available online anywhere? I have searched but
not found.
Marshall
Bob Badour
Sadly, one must purchase the documents individually from ISO. They are
copyrighted and not available without cost; although, one can purchase
them online. However, I suggest any academic or private technical
library should have a bound copy. If one encounters an academic library
that doesn't have a copy, I suggest one point out the importance of the
document to the librarian.
One of these days, I will have to unpack from my move. When I do, I
should find my copy of the pdf files on one of the desktop computers I
am not currently using.
David Cressey
"paul c" <toledob...@oohay.ac> wrote in message
news:TKKgg.239768$P01.172192@pd7tw3no...
>
> Okay, don't want to risk a premature definition but here's a stab at an
> analogy/comparison for "persistence", a word that gets under my skin
> most of the time I see it used here:
>
> If nothing changes but the time of day, what was true yesterday is still
> true today.
>
> I may be wrong to see it this way, but this is why I don't associate the
> acronym "rdms" with persistence, necessarily.
I don't think you should take the acronyms RDMS and RDBMS to be synonyms.
Anith Sen
http://www.imprimaatur.ee/standard/01.htm ( fundamentals )
( Change 01.htm to 02.htm, 03.htm, ... )
17.htm should have the basic definitions of various levels of data
representations
You can find some related std docs at:
http://standards.iso.org/ittf/PubliclyAvailableStandards/
--
Anith
Bob Badour
Awesome Anith!
http://www.imprimaatur.ee/standard/17.htm does indeed have the
vocabulary relevant to databases, and
http://www.imprimaatur.ee/standard/01.htm does indeed have the
***fundamental*** definitions.
Chapter 02 has at least a few important definitions. (Operator being a
very important definition:
http://www.imprimaatur.ee/standard/02.htm#02.10.06)
Chapter 04 has some very important definitions.
(http://www.imprimaatur.ee/standard/04.htm#04.09.04 and
http://www.imprimaatur.ee/standard/04.htm#04.09.05)
Chapter 05 has some very basic terms that pop up from time to time but
seldom cause confusion.
Chapter 06 has a lot of terminology for the physical level of discourse.
Chapter 07 has some terminology one sees a lot around here. (eg.
http://www.imprimaatur.ee/standard/07.htm#07.01.21 and
http://www.imprimaatur.ee/standard/07.htm#07.01.22)
Chapter 08 has some security and integrity related terminology.
Chapter 14 has some terminology related to important functions of a dbms.
Chapter 15 is full of very important terms that pop up here frequently.
(eg. http://www.imprimaatur.ee/standard/15.htm#15.03.03
http://www.imprimaatur.ee/standard/15.htm#15.03.20
http://www.imprimaatur.ee/standard/15.htm#15.04.22)
Chapter 16 covers the one area where the term "information" seems at
times to have a very precise (often quantifiable) definition somewhat at
odds with the rest of information technology.
Chapter 18 has terminology at the physical level of discourse related to
distribution.
Chapter 20 has terminology related to system development, project
management etc.
Other chapters might hold special interest to particular people here,
but I think the chapters above cover the most important terms. I might
have missed one or two, though.
mAsterdam
Glossary 0.1.1: "You keep using that word.
I do not think it means what
February 2006 you think it means"
--------------- -- Inigo Montoya
Maintainer: mAsterdam
Preamble:
---------------
This glossary seeks to limit lengthy misunderstandings
in comp.database.theory. This newsgroup uses terms from
database modeling, design, implementation, operations,
change management, cost sharing, productivity research,
and /or basic database research.
People tend to assume that words mean what they are
accustomed to, and take for granted that the other
posters have about the same connotations.
They don't always.
It consists of signposts: watch out! You may think the OP
means A but she might mean B. Alternative names and views
of the same concept are introduced when the danger
of mutual misunderstandings is apparent.