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

mAsterdam schrieb:
> 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.

The issue being discussed has nothing to do with the "class/table mix-up".

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

So what is the problem? Terminological? If so, then the term concept is taken from concept lattices and formal concept analysis (if explanation of term origin is an important issue at all).

Or you do not aggree that placing a record into an Order table reflects the fact that it belongs to a set of orders just like setting a field recordType="orders" says that this record belongs to a class of Orders?

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

Yes, if you like this way you can use it. But for data modeling I find it more convenient to view things as follows:

any element belongs to one parent element physically, and to a number of other elments logically.

I actually do not invent anything new when say that membership can be modeled (i) pby utting records into a table, or (ii) by setting its column value. Do not you agree?

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

We always do both (if I correctly understand what do you mean by "both"). It is a trade off or a design alternative: either to represent different departments by different tables (and then place persons in them), or to represent them by records (and then assign them as column value for persons). Or, if you meant physical/logical membership then, as I mentioned, any element belongs to one parent element physically and to a number of elements logically, so we cannot aovid that.

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

Here is a couple of examples clarifying what we were talking about.

Assume we have different types of figures (circle, square, etc.) Design alternatives:
- create one class (in OOP) or one table (in data modeling) for each type of figure. After that each figure (instance) will belong to one class or exist in one table.
- define one field/column with values of figure type.

Assume we have different departments. Design alternatives: - create a table for each department and place employees in it as records, - define a column with department type as a value

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

What? Sorry but I do not understand what you do not understand.

> Or are you using the word 'table' to mean something else?
>

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

Please, define concretely what do you mean by "physical" (position) and "logical" position. In the concept-oriented model these are formally defined terms. I suppose that you use these terms mostly informally.

> 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 

I do not know. It is too general question and everything depends on context. In COM table (concept) like any other element has a physical parent and representation in it (reference, identity).

> Where did you get the idea that tables are physical containers?

We define so in the model so it is an assumption. But actually what are tables if not a physical container for records? Probably it is term conflict but I think I defined concretely what I mean by physical and logical parts of the model: all tables physically belong to one root of the model, and records belong to their records, while logical structure is defined column values. All other (with bridges etc.) associations are not desirable.

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

Please, in terms of data modeling with the minimal set of main constructs. In this anything can be confirmed or refuted. It is interesting but very time consuming. I think I tried to be very concrete. Namely, the only I said is that

• an attribute value is a set for all objects that have it
• in the concept-oriented data model any element is (i) a collection of other elements, and (ii) a combination of other elements. Or, equivalently, any element has one physical parent set, and a number of logical parent sets.

This can be shown to be useful for modeling hierarchies discussed in this thread because the model defined in this way is intrinsically hierarchical.

--
http://conceptoriented.com