Re: Use of the term "hierarchy"

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:l132u2-jg1.ln1_at_pluto.downsfam.net...
> 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.
>
>
> --
> Kenneth Downs
> Secure Data Software, Inc.
> (Ken)nneth_at_(Sec)ure(Dat)a(.com)

I got this out of the dictionary...

hi·er·ar·chy (hº".-rär"k¶, hº"rär"-) n., pl. hi·er·ar·chies. 1. A body of persons having authority. 2.a. Categorization of a group of people according to ability or status. b. The group so categorized. 3. A series in which each element is graded or ranked. 4.a. A body of clergy organized into successive ranks or grades with each level subordinate to the one above. b. Religious rule by a group of ranked clergy. 5. One of the divisions of angels.

admittedly, this is a poor source for the definition of the word in our world. But I was surprised to see that the notion of "one-to-many relationship" isn't even hinted at in the common parlance definition.

It doesn't say that the subrdinate clergy will even outnumber the higher ranking clergy.

Here's my take on it:

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.

So, a "hierarchy of folders" is I think, carrying the implication that a folder can contain another folder.

Next, I don't think the word "hierarchy" and the word "tree" are exactly the same concept. A tree is a data structure, one that's peculiarly well suited to expressing a hierarchy. But I don't think every tree expresses a hierarchy, necessarily.

Next, the org chart situation. I happened to look at an org chart, today. And, looking at it, it seemed to me that it did not really look like a hierarchy of employees. It really looked like a hierarchy of job functions, with employees assigned to job functions. (Each box had a job function on one line, and a persons' name below it, except for one box that had no name in it, because the person in that slot left, and has yet to be replaced).

Next, the word "hierarchy" as a presumed pejorative comparison with "relational". When I first started reading this newsgroup, Dawn Wolthuis was bemoaning the fact that college texts seemed to set up the "hierarchical data model" as a straw man, in order to knock it down with the superior "relational data model". There's some truth to that objection. It smacks of language police, a particular noxious form of suppression at a university.

But "hieararchy" itself is a far more enduring concept than the data model behind products like IMS. I would venture to suggest that hierarchy is one of the pervasive organizing principles for managing complexity.

Finally, back to table design. In most cases, I would throw in a reflexive foreign key, called "supervisor_id" into the table that has "employee_id" as a primary key. However, there are a few cases, like the org chart with the empty slot in it referred to above, where I would resort to the following:

org_hiearachy: (slot_id_l, slot_id_r, slot_name, employee_id)

Where the first two columns iimplement the nested set model, on the job slots. slot_name is just text. And employee_id is an optional foreign key, identifying the holde rof the slot.

In cases where the slot is empty, a NULL in the employee_id could indicate this. Note that you don't have to recalculate the L and R values every time there's a transfer within the organization. Only when the slots are reorganized do we have to do that.

All of this is kinda off-topic, but I thought I'd toss it in. Received on Fri Aug 26 2005 - 23:36:10 CEST