Re: Use of the term "hierarchy"

David Cressey schrieb:
> Like some others, I don't tend to think of Job --> Order --> Order Item as
> a hierarchy, because they are unlike items. At a higher level of
> abstraction, you might think of them as a "hierarchy of entities", but
> somehow that doesn't wash with me.

I think hierarchy is independent of whether items are like or unlike. All Jobs, Orders and Order Lines are not necessarily stored in different tables and might well be stored in one table where their type is represented by some property. In this case they are already like items. However, the hierarchial relationship between them (Jobs -> Orders -> Order Lines) retains. In this sense the physical location of data items is not important. It is important only how data items reference one another:

If item A references item A (in one of its properties) then B is a group/set/category/container for A. (Value is a group/category for all objects that take it.)

Note that this concept-oriented principle relates to all types of elements including tables and records and it allows us to naturally order all elements of the model. As a consequence an item can reference items from its own table or from another table but all those referenced items will be qualified as its parent logical categories or groups. The table where data items live are physical sets/containers.

--
http://conceptoriented.com