Re: Use of the term "hierarchy" (and table/class)

From: Alexandr Savinov <>
Date: Sat, 27 Aug 2005 13:26:25 +0000
Message-ID: <>

mAsterdam schrieb:
> Alexandr Savinov wrote:

>> ... One aspect of this problem could be formulated as follows:
>> - when to represent a thing by normal record/row/object or by table/class

> Why lump data-only things (record, rows) and a mixture
> of data and behaviour (object) together?
> The table/class mix-up even more error-prone: earlier
> mistakes lead to bigger messes.
> Even struts users are starting to realise that.
> The question wether to represent a thing in data at
> member or set level depends on our information needs
> regarding those things, not on preconceived structures.

Yes, but the problem is that there is two fundamentally different ways to represent a set:

If we recognize this as an important alternative the following questions arise (mostly open and only a small subset):

- what is the semantics of our data in the case of two types of sets?
- how can we manipulate data from different types of containers?
- how can we transform sets between these two types so that the data 
semantics does not change. For example, if I decided that I do not want to keep records in a table as a set but instead want to keep those records in a parent record as a set.

Of course, we can answer these questions by simply providing an implementation, say, in C++ or SQL. But here I mean if we can provide some fundamental treatment of data.

>> This has several consequences:
>> - we can consider concepts and items in one space (within one physical 
>> structure) so they are not isolated elements of the model
>> - with more levels in the physical structure we can introduce a 
>> physical hierarchy with more level, for example, tables consist of 
>> partitions which consist of records. Another application is a mark-up 
>> language.

> Sure there are more levels in the physical structure - but tables are
> not physical. A table is one way of representing data.

An important distinguishing feature of this approach (a principle) is that *any* element in the model has a physical part and a logical part simultaniously and we can separate them (but can consider only one part). In particular, a table and a record have some physical representation (a physical reference, name or whatever permanent and normally hidden identifier is used). However, any table and any record have also a logical representation which is a position among other elements. Using the logical representation elements can be accessed via other elements. In contrast to physical position, the logical position may change (reflecting the changes in our model).

Here is another analogy. We can position our elements by placing them into their physical containers like tables (or database, or object container or whatever parent element that cannot be then changed easily and is responsible for references and physical access). And we can position our elments logically by specifying their coordinates w.r.t. to other elments. This position may change and reflects the model semantics. It is precisely what we do when specify object field values or set this object as a value for some other objects.

>> - hierarchy between physical elements of higher level (say, tables) 
>> impose constraints on its child elements (say, records)

> Lower level constraints may also propagate to
> constraints on higher levels.

How? Any example?

Received on Sat Aug 27 2005 - 15:26:25 CEST

Original text of this message