Re: cdt glossary 0.1.0
Date: Fri, 24 Feb 2006 16:39:25 -0800
Message-ID: <f04vv11km7u3ud7dtljc5mevvmg6habhkn_at_4ax.com>
mAsterdam <mAsterdam_at_vrijdag.org> wrote:
>MAINTAINER: mAsterdam
>Preamble:
>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.
What you might have to do is characterize some context, and then list the jargon. Another context, other jargon. And then establish some degree of correspondence, perhaps characterized as strong, weak and exact. You have things like General, Math, Software.
If you used that dreaded word, entity, in an ER context, and matched it to, relation, in the context of the RM, you might omit, entity, in such a correspondence chart for the RM. Yet the RM might refer to entities, otherwise. You might use, instance, in an object structure and yet also wish to use it synonymously in the context of the RM. And so on.
>[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.
And which might be aided by enforcing manipulation of the database by one avenue, and one only, such as through the use of SQL.
>[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 may have no meaning".
>Somehow this "data has no meaning" idea has caught on.
>1a. facts
Including scale, domain, dimension. A quart is not the same as a British pound.
>1b. a record on a medium of some fact in the real world.
Which begs the question, when is data, fact, and fact, data. Or should they simply be used interchangeably?
>2. encoded information
Or instead of limiting to scalars, just call it a character string.
>3. a 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.
>1. Deluxe filesystem
>2. Shared databank (E. Codd)
By logically coherent, they mean - ordered. By order comes both insertion and retrieval. And organized collection, if one prefers.
It need not be anything from the "real-world". A database of some fantasy skid, or the meanderings of Alice in the woods, would still be an organized collection, just of otherwise meaningless phrases.
>[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.
From one dimension, such as distance, mass, etc. One scale, for scalars, in a particular attribute.
>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.
A date is still dimensional data. Scalars or character strings, in other words.
>[Entity]
>Thing of interest. (ISO)
>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.
I still think it's a rather vague term, with many applications in various context.
>[Fact]
>1. A piece of information about circumstances that exist or
>events that have occurred
Semantically so, but not necessary for data. Perhaps this is where the confusion comes in asserting that data is unfettered from structure or meaning. The data may be of something that could exist in a probabalistic state, or similarly in some future state, in the future, or was said to have been by some, and not by others of another view or faction, etc. In the eye of the beholder, to a degree. But the string or scalar remain.
>2. A concept whose truth can be proved.
But by who, faction A, or faction B? Faction A excises and censors it from their webpage. Faction B makes a minor mistake and faction A says, see - there.
>3. A statement or assertion of verified information.
>4. An event known to have happened or something known to have existed.
You would think everyone could agree. But this is precisely where they don't. I think the data is a datum. It's stored, retrieved and manipulated. It need mean nothing at all, or at least not to one faction. But it is organized, structured and manipulated in that way according to rules and contraints. And that structure is its truth. The order is what makes it information, or 'fact', or what have you, at least to someone. Change that order, and something else is represented, quite simply.
>[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
Saying anything at any time is going to enrage some, no doubt. That can never be the test for inclusion in some glossary, unless again, factions rule. And factional definitions give way to those more balanced, even if sometimes by poor reading light or the back room of the bar, etc, wherever the 'resistance' can gather.
>[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.
function - tasks, implying occupation, office, etc. function - (un)intended use, hammer for nails, for demolition, heart pumping blood, etc. functional - able to perform, within some limit function - loose synonym for a formal gatheringdomain yielding a single dependent variable result on some range for a given predicate, with the independent variable having a one to one or many to one relationship with the result
>Math
> A binary mathematical relation with at most
> one b for each a in (a,b).
function - equation for a given independent variable on some
function - the relation mapping the independent domain to the dependent domain, as one to one or many to one.
>Software
> A subroutine, procedure, or method.
function - a callable procedure which returns some result function - method of a class procedure, implicit call
>notes:
> every operator is a function
> every function is a relation
Yes.
>[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.
But typically found stated as:
Codd's #1 of 12 Rules: All information in a relational database is represented explicitly at the logical level and in exactly one way - by values in tables.
>[Key]
>A value, used to identify something.
>See also TODO: primary key, foreign key.
Codd's #2 of 12 Rules: Each and every datum (atomic value) in a relational database is guaranteed to be logically accessible by resorting to a combination of table name, primary key value, and column name.
The primary key (PK), composed of one or more named columns, uniquely identifies the record in that named table.
>[Object]
>1. Model of an entity, characterised by behaviour and state. (ISO)
>2. Something intelligible or perceptible by the mind.
In the programmer's interface to an object model: a class with properties and/or methods, whether principally a table/data or a procedure.
Object - you know it when you see it.
>[Table/Row/Column] (SQL-DBMS)
>Table: A collection of columns (the table header) and rows (the body).
Table - a tabular grid, not necessarily surrounded by chairs
>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.
Depends on the sense for the term, entity.
>[Pointer]
>See address(*).
Pointer - redirection vector Pointer - link Pointer - data type/format Pointer - dog's name (but not applicable in this context) And:
>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.
Well, if a table is said to correspond to a "relation", then obviously a relation is just an collection, or better set, of n-tuples, more than simply ordered pairs, or 2-tuples.
>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.
>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 ?
Multi-valued as in more than one scalar or string/attribute?
>(please feel invited to write entries for these)
>Application
An aspect, a component
>Concept
See entity
>Dynamic vs static
Static meaning unchanging, dynamic subject to change
>Hierarchy
Organization by category and sub-category
>Scalar
A real or integer, with or without dimension Received on Sat Feb 25 2006 - 01:39:25 CET