Re: Use of the term "hierarchy"

Kenneth Downs schrieb:
> Generally speaking, we seem to use the word hierarchy to mean a situation
> where a table has a foreign key to itself (or a child table has two foreign
> keys to the same table that are non-transitive), with the usual assumption
> that nesting could go to any level and that the levels are
> indistinguishable from each other.
>
> We don't tend to say hierarchy when referring to the structure of related
> tables, such as Jobs -> Orders -> Order Lines. This always looked like a
> hierarchy to me though. It is a hierarchy of unlike items, in which the
> allowed relationships of parent/child are determined by table structure.
>
> So if we have hierarchies of unlike items and then those of like items, it
> seems we may mistake one for the other.
>
> Consider the canonical example of employees and their supervisors. This is
> usually presented as a hierarchy of like items. It seems however that we
> do this only because it is far too much bother to store and keep up-to-date
> the actual structure of a corporation in tables. But in fact, if it were
> possible to change tables as often as corps change org structures, we would
> most accurately keep records by having a table of vp's, a table of
> directors, table of managers, and so forth. Positions would be defined
> independently of personnel, and one (or more) people could be put into any
> particular position. Positions have salary ranges or potential legal
> differences, plus being salaried vs. hourly, union vs. non-union and so
> forth.
>
> The common storage of email into nested folders is I believe another example
> of where a fixed structure of threads and cross-references would likely be
> far more helpful than the very limited nested folders.
>
> OTOH, a bill of materials appears AFAICT to be a true hierarchy of like
> items, where there are no discernible properties that would give value to
> different tables for "level 1" "level 2" and so forth.

You touch here rather general and subtle problem (which is actual not only for data modeling). One aspect of this problem could be formulated as follows:

• when to represent a thing by normal record/row/object or by table/class

Some my thoughts about this problem are here (mostly problem formulation): http://conceptoriented.com/papers/TablesAsEntities.pdf

One possible solution is proposed within the concept-oriented model. See, for example, a recent article published in the Journal of Conceptual Modeling (equivalent references in different formats):

http://www.inconcept.com/jcm/August2005/Savinov.html (not very good HTML formatting)
http://conceptoriented.com/savinov/publicat/jcm_05.html (better HTML) http://conceptoriented.com/savinov/publicat/jcm_05.pdf (original PDF)

First of all we distinguish two types of structures in the model: - physical structure which is purely hierarchical (tree-like) with one root, which consists of concepts, which in turn consist of data items, and - logical structure where each element (concept or item) may have a number of parents and a number of children

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. - hierarchy between physical elements of higher level (say, tables) impose constraints on its child elements (say, records) - this allows us to clearly separate two concerns: physical structure and logical structure. It is a consequence of more general (theoretical) principle that any element consists of two parts: a collection of other elements, and a combination of other elements.

-- 
http://conceptoriented.com