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

Alexandr Savinov wrote:
> 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.

You did not yet answer the question about the class/table mix-up. As this is an area whith many misunderstandings I would ask you to please reconsider answering it. Maybe it's just a side-issue to you and you are only interested in the program/statement class/instance variable/value file/record word/character sentence/word group/member set/element construct/component team/player type/ocurrance table/row collection/item etc... dichotomies in the abstract but to me they are not all the same.

> but the problem is that there is two fundamentally different ways
> to represent a set:
>
> - as a physical collection/container, for example, where records are
> placed in a table (considered a set).

Strange example. I am aware that you below you state that "*any* element in the model has a physical part and a logical part simultaniously*", but /table/ is a concept (and I do have criticisms towards it, but I'll sidestep those for now) specifically introduced to *not* oblige everybody to consider the physical aspects of data.

> - as a logical collection/container, for example, where one record (say,
> order part) is assigned a parent record (an order) considered a set.

ISTM these "fundamentally different ways to represent a set" are really different ways to look at the same things. You can look at and study the landscape architecture or the construction or the chemical structure of the composing materials of one bridge. When building a bridge, all of those aspects are considered at different times, by different people. When it is finished, it's all there at the same time in one thing. http://www.hsba.go.jp/bridge/e-akasi.htm

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

You can do both (or at least appear to do both) at the same time.

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

How does this all affect the problem "when to represent a thing by normal record/row/object or by table/class"? (BTW still not clear what you mean here, maybe due to the table/class mix-up).

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

Assuming table in the SQL / cdt sense, a table must have some (or several) physical representation at any time, for sure. Its logical representation, though, is *not* its /also/ representation. It is its primary representation, its raison d'etre. Why do you want to change that?
Or are you using the word 'table' to mean something else?

> which is a position among other elements.

The position of rows in a table is abstracted away. /There is no such thing/ is the implied common illusion at the logical level.

> 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).
> 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).

The physical location of bytes may change without affecting the data represented by them (in any DBMS, not just RDBMS).

> Here is another analogy. We can position our elements by placing them
> into their physical containers like tables

What is physical about tables?
Where did you get the idea that tables are physical containers?

> (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.

The chemical bonding forces of materials put limits on the size of constructions. To stay within the databases realm: a filesize limits the number of rows of tables. Received on Sat Aug 27 2005 - 17:52:09 CEST