Re: Latest version of glossary

From: dawn <dawnwolthuis_at_gmail.com>
Date: 24 Feb 2006 09:07:50 -0800
Message-ID: <1140800870.414865.30090_at_e56g2000cwe.googlegroups.com>


JOG wrote:

> dawn wrote:
> > entity: a thing of interest
> >
> > 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)
>
> I agree with Alexandr that this is currently far too general.

I sortof do too, but can't see how to further restrict it. I have used this one before:

entity: a person, place, thing, or event

Since person, place, and event are all things, this doesn't mean more than "thing of interest" but gives some possible ideas to those participating in conceptual modeling.

The "of interest" is only there because it has been defined that way for long enough, so I figured it was worth keeping it for tradition, at least. It doesn't add much and surely we can have somone pipe up with an entity that is of interest to no one else and perhaps not of much interest to person stating it -- just something that piped to mind. So, it is an entity for a second on some ERD, perhaps, but isn't really of interest at all, even if it spent some time as an entity.

> This is
> an incredibly tough term to define (I'm not even completely convinced
> that the entity/relationship split is actually a useful one, and it is
> not preferable to model everything as relationships). However if forced
> I would probably refer to however the term "entity" is defined in E-R
> modelling.

What would that definition be?

> > 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]
>
> Another incredibly tough term as it has so many different uses -
> multidimensional databases/OLAP for instance.

Yes, I thought of adding a third specifically for that, but it seemed to me that the reason it is called multidimensional is related to 2) above, so I didn't add more. It would be fine to do so if it clarifies something.

> > 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
>
> This first line of this requires iteration imo - a table in an
> SQL-DBMS is not modelled as a mathematical relation (only information
> is modelled).

Everything is modeled. I'm using the meaning of the term "model." Whenever mathematics is applied to anything, it is as a model.

> Rather tables are a conventional visualization (I think
> you convinced me that representation is an incorrect word) for those
> underlying relations.

I'm good with saying that tables are a conventional visualization, but they are also used in an implementation of the RM. Relations are in the mathematical model of this implementation, but we define tables to a dbms. I would definitely say that we represent relations as tables. "Tables" is a very overloaded term, however.

> > 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).
>
> When one talks about 2-dimensions and arrays in respect to RM, one is
> talking about the visualization, not the underlying model.

Not just the visualization, but the representation in some data structure, for example. So, it is a bit more confusing than that because one person might be thinking about the underlying model of the data structure they are using.

If you are using a language where you can represent a relation in an associative array (while trying to do something in JavaScript, I found that it has no such thing as a multidimensional associative array, bummer), then you could write something like MyArray['12345','Name'] to access the value for the Name of a person whose ID is 12345. This did not require the ordering required of some other structures (such as XML or Arrays). The relation represented by MyArray might have a dimension of 15, and be handled by this 2D data structure (as confusing as it might sound).

> I believe
> that this could be a useful distinction, and probably the root of most
> miscommunication on the matter.
>
> all best, Jim

I'm not sure this nails the distinction. I think it has more to do with whether you are doing mathematics or writing code. Cheers! --dawn Received on Fri Feb 24 2006 - 18:07:50 CET

Original text of this message