Re: Latest version of glossary

dawn schrieb:
I tried to find the latest draft of the cdt glossary, but wasn't sure
if I found the most recent one, so mAsterdam or anyone -- could you
repost the glossary so we can perhaps add in some terms to help with
some of these discussions? We could maybe add dimension, entity, flat,
and a few others.

For example (just off the top of my head -- these should be improved
upon):

entity: a thing of interest

Although it is an official definition it has the following problems:
- it is too general and hence useless
- it is equivalent to the term "thing", which is used to refer to anything
- entity != dimension, entity != attribute, entity != reference

So entity is much more concrete term than simply a thing of interest. I would define it as follows:

entity is a thing of interest which has properties, that is, can be characterized by one or more other (primitive or non-primitive) entities, and has an associated identifier.

In other words, without an identifier a thing is NOT an entity. Without properties it is also NOT an entity.

I do not insist on this definition of course but I simply think that having too general definitions is not very useful. It will be simply misleading in discussions.

Note: 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.

(we could possibly add in strong and weak entity)

dimension:
1) A relation R is of dimension 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]

The second requirement is not necessary in general and to define dimension in particular. How tuples are accessed is a separate issue that has nothing to do with the dimensionality. Uniqueness is a property of the representation mechanism - it is not a dimensionality issue. In other words, I find it very important to separate these two concerns: how dimensions are defined and how tuples are represented/accessed.

Another note. You defined the term "dimensionality" rather than "dimension". What is one separate dimension has to be defined separately.

Note: Because a table in a SQL-DBMS can be modeled as 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
def 2).

flat: an object which by any definition could be considered as 2
dimensional might informally be called flat.

I would give the following short definition:

flat = 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 ;-)

Cheers! --dawn

--
http://conceptoriented.com
.

Relevant Pages

  • Re: Simple question
    ... but it's sufficiently flat for me to ignore the variations. ... As for the variations along the Y dimension, ...
    (sci.stat.math)
  • Re: Database design
    ... I don't know your "definition of being flat". ... Actually we can continue to different depth along different dimension - any dimension may have its own depth. ... can continue this space hierarchy in the opposite direction. ... A relation is not equivalent to a n-dimensional space. ...
    (comp.databases.theory)
  • Latest version of glossary
    ... We could maybe add dimension, entity, flat, ... such as "XML entity" to distinquish it from the more ... any use of the term flat tends to be seen as inflammatory by ...
    (comp.databases.theory)
  • Re: table structure for olap
    ... You can either use star schema (every dimension links to the fact) or ... Which one you would state as flat I' not sure.... ... helper" tables to make a hierachy of parents with the same children - and to ... OLAP performs best with hierachies - not so good with large flat dimensions. ...
    (microsoft.public.sqlserver.olap)
  • Re: large dimension with many member properties
    ... of time the properties are loaded in separate hierarchies. ... > usage for a member property. ... >> If I am not mistaken AS will load the entire dimension into memory. ...
    (microsoft.public.sqlserver.olap)