Re: Use of the term "hierarchy"

Kenneth Downs wrote:
> 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.

There are hierarchies and there are ways to represent them. When you observe a hierarchy, is it always clear whether the hierarchy is in the subject matter, in the observation or somewhere in between?
Even if the hierarchy is given, it is possible to represent it in data in many ways, some of which you just mentioned.

> ...Consider the canonical example of employees and their supervisors.
> This is usually presented as a hierarchy of like items.

1. This makes one employee part of a hierarchy. Another way (you described it but I'll do it in my own words here) is to
2. have employees and a hierarchy, and give an employee a place in the hierarchy as an attribute.
3. Stresses the submission of the employee to the hierarchy.
4. Stresses the human individuality of the employee and the hierarchy's existence independent of the current employees.

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

Why 'would' and 'could'? There are a lot of databases designed this way.

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

Not sure if I get this the way you mean it. Let's try: The level is not a fixed thing in a BOM. Parts of identical type may have a level depending on the structure they are contained in. (e.g. knobs in a modular hifi set vs. the same kind of knobs in an integrated set). Received on Sat Aug 27 2005 - 00:32:31 CEST