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

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

Yes, 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).
• as a logical collection/container, for example, where one record (say, order part) is assigned a parent record (an order) considered 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 

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.

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)

How? Any example?

--
http://conceptoriented.com