Neo wrote:
> >> Partial Grid View of Person Instances:
> >> ID name phone# email staffMember
> >> -- --------- -------- ------------- -----------
> >> # judy 333-5555 j...@[EMAIL PROTECTED]
clark
> >> # clark 737-5588
> >>
> >> Partial Tree View of Person Instances:
> >> -Person
> >> |-instance-
> >> |-Judy
> >> | |-phone#-
> >> | | |-333-5555
> >> | | |-JDG-JUDY
> >> | |
> >> | |-email-
> >> | | |-J...@[EMAIL PROTECTED]
> >> | | |-J...@[EMAIL PROTECTED]
> >> | |
> >> | |-staffMember-
> >> | |-Clark+
> >> | |-Ashley+
> >> | |-Colby+
> >> | |-Brandy+
> >> | |-Courtney+
> >> |
> >> |-Clark
> >> | |-phone#-
> >> | | |-737-5588
> >> | |
> >> | |-assistant-
> >> | |-Ashley+
> >
> > This is a typical structure of a "navigational" or "hierarchical"
database. They are fine for particular specific uses, but over time people
found they grew into messes and are hard to query for unforseen questiones.
Dr. Codd was working with stuff like this when he felt there should be a
better way.
>
> Dr. Codd was right. The Relation Data Model is more general/flexible
> than the Hierarchal Data Model.
"Navigational" is a superset of hierarchical. Generally there is the
Network model and Hierarchical model. Yours is a kind of hybrid, but so
were most (originally) hierarchical DB's in the 60's and 70's. IBM's
hierarchical IMS had cross-links, and some file systems also have cross
links, for example. Charles Bachman's databases were more
network-based.
-T-
> The advantage of a more
> general/flexible method (RM) is that its scope it larger. The advantage
> of a more specialized/limited method (HM) is that it is more efficient
> within its smaller scope. (This might sound familiar as I have been
> repeating this for several years now :)
>
> However, to assume the underlying data model based on a particular view
> is unreliable. In hierarchal model, it is impossible to represent a
> thing with more than one parent without redundancy. If you were to
> click around in exp db's tree view, with option to display each thing's
> ID enabled, you would see that while a thing is a child in multiple
> hierarchies, it still has the same ID. For example, most of the persons
> in the example have multiple classifications, yet when one drills down
> Person, StaffMember or Clerk instances, Clark has the same ID! The same
> can be verified with this thread's original example where Adam is in
> the parent/child and boss/employee hierarchy. If you change Clark's or
> Adam's attributes or atribute values in one hierarchy, it shows up in
> the other hierarchies as well, without the db engine having
> synchronized data in multiple places. (Note that tree nodes in GUI may
> need to be refreshed by closing/opening its parent tree node)
|
