TopMind, it seems we are slipping back to an endless answer/question
mode which spawns even more... Since I have asked serveral times, how
you want to handle the shortcommings in the current RM schema to
represent that in court judge example (which gets more difficult for
various types of things in the has hierarchy) and not gotten a
response, I suggest we put this one side and focus on the simpler food
judge example which is well within RM's scope; however at least we can
actually compare methodologies and I can extend that example to
highlight some features and answer your questions. In addition, Nick
has posted a Prolog based solution and this would be an excellent
opportunity to compare three methodologies!
>> 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).
..
> How does one objectively measure "general"? They are all potentially
representionally equivalent.
While it is theoretically possible for different data models to
represent the same thing, one has to consider the practicality of doing
so. Thus theoretically, the Hierarchal Model can represent the the same
things as the Relational Model, however the further beyond Hierarchal
Model's scope we get, the more impractical it becomes. Simlarly, it is
theoretically possible for RM to represent court-judge-type examples,
however they starts to become impractical. Factors that may be involved
in measuring generalness are 1) when does the data model start to
incur redundancies 2) when does the data model start to incur NULLs
3) when do the modelling methods change 4) constriants due to the
model itself.
For example, the exp db's model has no schema constraints as required
by RM. Just on this alone, it is probably IMPOSSIBLE for RM to ever be
as general/flexible. In addition, RMDB implementations have additional
hardware related constraints such as data types, where as the exp db
does not. Exp db's generalness/flexibility and better abstraction of
the hardware layer comes at the cost of resources such as memory,
processing time, etc. (Note: even though the exp db's data model has no
constraints and user does not specify a schema, this does not prevent
the db from representing things in a non-redundant manner, which allows
for efficient data mgmt - ie queries, updates, etc)
Because I know both the exp and RM data models, it is easy for me to
see why exp data model is more general/flexible; however I don't not
want to discuss it's details currently. An alternate way to measure the
generalness/flexibility/scope of a tool is by verifying what range of
problems/applications the tool is practical for.
For example, the scope/generalness/flexibility of a size 5mm socket,
might be nuts from 4.95 to 5.05 mm. If we use a hammer, the socket
might work from 4.9 to 5.1 mm but it is slightly impractical. Notice
the method has changed, we now need to hammer. If we now use a
sledgehammer and safety glasses, the socket might work for 4.8 to 5.2
mm. Notice the method has changed again.
With respect to a data models, generalness/scope/flexibility is the
range of things that can be represented in a practical manner. For
example, thus far the exp db examples have shown it can represent
tables, hierarchies, matrixes and some variable structures. But I
haven't yet seen anyone successfully represent data in exp db's court
judge example.
> > 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.
>
> Example?
:) Allow user/app to enter data without specifying a schema yet the
data is normalized which means it allows for efficient data management
(ie queries, update, etc).
> > 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.
>
> Please clarify. Dynamic relational is possible, as already pointed out.
Would you be willing to demonstrate it? Can it accept data without
first entering/modifying a schema and yet the data is normalized?
> > 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.
>
> I would characterize it as a graph of nodes (records or maps), although
in practice it does tend to have a mix of trees and tables tendencies,
perhaps because people relate to tables and trees better than random
graphs.
Unless one is able to relate data in any cell in any table to another
data, including itself (as the exp db can), the "Network Data Model"
falls quite short of being a graph of nodes (in my book).
> I like tables because they offer a consistency of design that the other
approaches don't. Tables are easy to visualize and relational math is
based on set theory.
And does this preference for tables, admiration for its consistency,
ease of visualization in tables and relational math based on set theory
allow one to model the data in the court judge example? If so, please
post schema and populate data so we can continue with other aspects.
While exp db's methodology involves more steps (due to its
generalness), the methods are consistent for describing trees, tables,
multi-headed matrixes, etc. Notice in RM, methods changes for these
situations. While table views are nice and exp db also has them, they
are not very useful for tree and matrix like data. Even the tree is
limited for complex matrixes and I hope to add an additional view to
display them as nodes and links later.
> Similar debates came up when Go To was challenged.
I have no idea what goto's have to do with exp db. It seems I will have
to go through another cycle of posts to tell you that whatever
characteristics you are observing have nothing to do with goto; similar
to earlier contentions that because the exp db displays data in a tree
view (table views also available), it must be based on the hierarchal
data model.
> By the way, what would a query language look like for your suggestion?
Lisp?
Each example that I have posted has some at the end of the scripts,
especially the food judge example. A simple query might be: (select
thing1 attrib1 *).
Don't let it's simplicity fool you :)
|
