> > > 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 Relational Data Model is more general/flexible
than the Hierarchal Data Model.
..
> "Navigational" is a superset of hierarchical.
It appears you are stating the above as a negative. Before I can
counter it, I need to determine if the exp db is guilty of. Please
precisely define what is "navigational" (with respect to representing
things in a non-redundant manner in computers) and what is its
disadvantage/limitation which the exp db should exhibit?
> Generally there is the Network model and Hierarchical model. Yours is a
kind of hybrid,
Again, this is incorrect. It is not a hybrid (it's not the elephant's
trunk + ears + tail, its the entire elephant). The exp's data model is
more general than all the data representation
methodogies/implementations including Hierarchal, Network, Relational,
etc that can be used to create a db (ie runs on computers where the
data is non-redundant, thus allowing for efficient data mgmt). This
allows the exp db to accomplish what each of the less general
methodologies/implementation can however not as efficiently within
their practical scope. It can also do that which is outside the total
combined scope of Hierarchal, Network and Relational Data Models.
The Hierarchal Data Model's significant limitation is, its inability to
model things in multiple hierarchies without redundancy, which I have
stated is not case in the exp db, since it can represent a thing in
multiple hierarchies without reduncancy and have offered several ways
to verify this including viewing a thing's ID in various hierarchies,
etc.
Some limitations of the Relational Model are it forces constriants that
are not always desirable for some apps (ie AI-ish). Believe it or not
but requiring a schema and relation header prior to entering data are
hardware-driven, data model-driven, user, app, etc constriants. Notice
with exp db, not having these constraints does not prevent it from
normalizing data (at run-time!) and from performing high level queries
similar to SELECT statements found in SQL. In the exp db, constriants
such as schemas and relation headers, if desired, can be stored in db
like any other data, and can be enforced by the app (dbms will probably
implement some basic/common constraints later).
Now the Network Data Model is a hybrid. Hybrid models ultimately suffer
from complexity of implementation, usage, etc. Personally, the Network
Data Model is a misnamed. It is more accurately named
Hierarchal/Relational Hybrid Data Model.
One can hypothesize until end of eternity, but I prefer to
prove/disprove things with actual implemetations. If one asserts that
the exp db is a hybrid, please also try to specify a method that would
verify such an assertion. I don't believe one is in a good position, to
even make such assertions, until first demonstrating how to just model
data (ie judge example) that can stored in the exp db with current
methodogies which they feel are more general/flexible. Or have you
already conceded this for RM? If the original data is too complex for
RM to model practically, we can simplified it and continue with other
considerations.
> 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. (It should be pointed out that the DB's back then were not
as dynamic as the newer incarnations, such as DOM.
If you believe DOM is more general/flexible than exp db, would you be
able to verify this by actually representing/querying things (ie judge
example).
|
