Re: Use of the term "hierarchy"
- From: "David Cressey" <david.cressey@xxxxxxxxxxxxx>
- Date: Fri, 26 Aug 2005 21:36:10 GMT
"Kenneth Downs" <knode.wants.this@xxxxxxxxxxxx> wrote in message
news:l132u2-jg1.ln1@xxxxxxxxxxxxxxxxxxxxx
> 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@(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.
.
- Follow-Ups:
- Re: Use of the term "hierarchy"
- From: Alexandr Savinov
- Re: Use of the term "hierarchy"
- References:
- Use of the term "hierarchy"
- From: Kenneth Downs
- Use of the term "hierarchy"
- Prev by Date: Re: dbdebunk 'Quote of Week' comment
- Next by Date: Re: dbdebunk 'Quote of Week' comment
- Previous by thread: Tables - Physical??? Was: Use of the term "hierarchy" (and table/class)
- Next by thread: Re: Use of the term "hierarchy"
- Index(es):
Relevant Pages
|
|
