No I mean the example with data that I posted in original thread titled
"Data Model" on Mar 30, then reposted earlier in this segment of the
thread on Apr 18. I am reposting it again below:


The script [much later below] populates [the] exp db with the following

persons: Judge Judy (phone# 333-5555, email j... (AT) aol (DOT) com &
judgeJ... (AT) law (DOT) com) who has following staff members: Clerk Clark (who
has Assistant Ashley), Coordinator Colby, Bailiff Brandy and
Court-Reporter Courtney each with various properties. Building
CourtHouse1 has two floors. The first floor has room1. The second floor

has room1 and room2. Various persons are placed in different parts of
CourtHouse1. The sample query (near end of script, [bottom of this
post]) finds a staff member of a judge whose assistant has a certain
phone#. Data can be easily navigated when viewed in a tree just by
clicking nodes (even though the underlying data doesn't necessarily
have a tree structure); where as in RM, it will require one to join
multiple tables. If requested, I can email the populated db/exe (188 kb

zip file) so one can see for themselves. Note, it is a prototype so
other features may not work. Note, I did not make bi-directional
relationships (ie j... (AT) aol (DOT) com emailOf judy) to keep the example
simple. One effect of creating bi-directional relationships would have
been to allow user to effectively "walk up" any [heirarchy] while
expanding tree nodes [in down direction]. Note, script expressions
become more elaborate when dealing with multiple things with the same
name.

Unlike RMDBs, where one must first design a schema/structure to hold
anticipated data, no schema is required before entering data in the
experimental db. The reason is, it already starts with a very general
schema that is capable of modelling most anything in a normalized
manner. This is partially why unanticipated types of data can be added
on the fly during execution without a design/compile phase. Db
automatically normalizes data and maintains referential integrity.
Other constraints, such as each person must have a phone number or 6
staff members, need to be implemented at code level [currently and for
a while] where as RMDBs can implement such basic constriants at db
level.


Because the script [much later below is foreign looking], I will
[first] show how [some of] the data appears when viewed in the db's
grid and tree views. The grid view below only shows instances of
person. The tree view below, on the other hand, shows most of the
relevant things... In essence, the tree nodes display sentences in
Subject-verb-Object format. In order to describe the tree view [in
Google vs the actual db exe], I have adopted some conventions. Tree
nodes representing subjects and objects are capitalized where as verbs
are not. [Verbs are prefixed and suffixed by a dash]. Also the object
of the initial sentence becomes the subject of the subsequent sentence
and so on. For example, the sentences "Building instance CourtHouse1"
and "CourtHouse1 has Floor1" is displayed as the following sequence of
nodes: Building, -instance-, CourtHouse1, -has-, Floor1, etc. Also a
"+" symbol after a node indicates that it can be expanded to that shown

else where in the tree. [While the tree view displays thing
redundantly, the underlying data is not, and one way of verifying this
is by displaying each nodes ID]. Thus the user (even a child) can
easily navigate to all the details of various things no matter what
tree path is taken, without anybody having to join tables (and there
will eventually be many). All this is much easier to see, just by
clicking around in the small db/exe which fits on a floppy.


[Below is the] Grid View of Person Instances. Note, grid only shows
first value of an attribute. [Switch to fixed fonts for columns to line

up]


ID name phone# email staffMember
-- --------- -------- ------------- -----------
# judy 333-5555 j... (AT) aol (DOT) com clark
# clark 737-5588
# ashley 737-5588
# colby c... (AT) msn (DOT) com
# brandy 919-9945
# courtney 203-9898 c... (AT) gov (DOT) org


[Below is the] Tree View of Relevant Things: Notice that the tree can
show multiple values of an attribute. Notice that a person can be
located in a building, on a floor or in a room. Ask the RMDB experts
how they would achieve this in a normalized, NULL-less manner.

Dir

// **** START OF LISP-LIKE SCRIPT TO CREATE DB ****
// Create a type named building.
(create type instance (new))
(create (it) name (findElseAdd name instance 'building'))
(create dir item (it))

// Create a type named floor.
(create type instance (new))
(create (it) name (findElseAdd name instance 'floor'))
(create dir item (it))

// Create a type named room.
(create type instance (new))
(create (it) name (findElseAdd name instance 'room'))
(create dir item (it))

// Create a type named person.
(create type instance (new))
(create (it) name (findElseAdd name instance 'person'))
(create dir item (it))

// Create a type named judge.
(create type instance (new))
(create (it) name (findElseAdd name instance 'judge'))
(create dir item (it))

// Create a type named staffMember.
(create type instance (new))
(create (it) name (findElseAdd name instance 'staffMember'))
(create dir item (it))

// Create a type named clerk.
(create type instance (new))
(create (it) name (findElseAdd name instance 'clerk'))
(create dir item (it))

// Create a type named assistant.
(create type instance (new))
(create (it) name (findElseAdd name instance 'assistant'))
(create dir item (it))

// Create a type named coordinator.
(create type instance (new))
(create (it) name (findElseAdd name instance 'coordinator'))
(create dir item (it))

// Create a type named bailiff.
(create type instance (new))
(create (it) name (findElseAdd name instance 'bailiff'))
(create dir item (it))

// Create a type named courtReporter.
(create type instance (new))
(create (it) name (findElseAdd name instance 'courtReporter'))
(create dir item (it))

// Create a type named phone#.
(create type instance (new))
(create (it) name (findElseAdd name instance 'phone#'))
(create dir item (it))

// Create a type named email.
(create type instance (new))
(create (it) name (findElseAdd name instance 'email'))
(create dir item (it))

// Create a verb instance named has.
(create verb instance (new))
(create (it) name (findElseAdd name instance 'has'))

// Create a person/judge named Judy.
(create person instance (new))
(create judge instance (it))
(create (it) name (findElseAdd name instance 'judy'))
(create (it) phone# (findElseAdd phone# instance '333-5555'))
(create (it) phone# (findElseAdd phone# instance 'JDG-JUDY'))
(create (it) email (findElseAdd email instance '... (AT) aol (DOT) com'))
(create (it) email (findElseAdd email instance '... (AT) law (DOT) com'))

// Create a person/staffMember/clerk named Clark.
(create person instance (new))
(create staffMember instance (it))
(create clerk instance (it))
(create (it) name (findElseAdd name instance 'clark'))
(create (it) phone# (findElseAdd phone# instance '737-5588'))

// Create a person/staffMember/clerk/assistant named Ashley.
(create person instance (new))
(create staffMember instance (it))
(create clerk instance (it))
(create assistant instance (it))
(create (it) name (findElseAdd name instance 'ashley'))
(create (it) phone# (findElseAdd phone# instance '737-5588'))

// Create a person/staffMember/coordinator named Colby.
(create person instance (new))
(create staffMember instance (it))
(create coordinator instance (it))
(create (it) name (findElseAdd name instance 'colby'))
(create (it) email (findElseAdd email instance 'co... (AT) msn (DOT) com'))

// Create a person/staffMember/bailiff named Brandy.
(create person instance (new))
(create staffMember instance (it))
(create bailiff instance (it))
(create (it) name (findElseAdd name instance 'brandy'))
(create (it) phone# (findElseAdd phone# instance '919-9945'))

// Create a person/staffMember/courtReporter named Courtney.
(create person instance (new))
(create staffMember instance (it))
(create courtReporter instance (it))
(create (it) name (findElseAdd name instance 'courtney'))
(create (it) phone# (findElseAdd phone# instance '203-9898'))
(create (it) email (findElseAdd email instance '... (AT) gov (DOT) org'))

// Create judge judy's staffMembers.
(create judy staffMember clark)
(create judy staffMember ashley)
(create judy staffMember colby)
(create judy staffMember brandy)
(create judy staffMember courtney)

// Create Clark's assistant Ashley
(create clark assistant ashley)

// Create a building instance named CourtHouse1.
(create building instance (new))
(create (it) name (findElseAdd name instance 'courtHouse1'))

// Create a floor instance named floor1
// and make it part of courtHouse1.
(create floor instance (new))
(create (it) name (findElseAdd name instance 'floor1'))
(create courtHouse1 has (it))

// Create room instances named room1
// and make it part of floor1.
(create room instance (new))
(create (it) name (findElseAdd name instance 'room1'))
(create floor1 has (it))

// Create a floor instance named floor2.
// and make it part of courtHouse1.
(create floor instance (new))
(create (it) name (findElseAdd name instance 'floor2'))
(create courtHouse1 has (it))

// Create room instances named room1
// and make it part of floor2.
(create room instance (new))
(create (it) name (findElseAdd name instance 'room1'))
(create floor2 has (it))

// Create room instances named room2
// and make it part of floor2.
(create room instance (new))
(create (it) name (findElseAdd name instance 'room2'))
(create floor2 has (it))

// Create CourtHouse1's has reporter Courtney.
(create courtHouse1 has courtney)

// Create CourtHouse1's floor1's has Ashley.
(create (relElem (select courtHouse1 has floor1))
has
ashley)

// Create CourtHouse1's floor1's room1 has Clark.
(create (relElem (select (relElem (select courtHouse1 has floor1))
has
room1))
has
clark)

// Create CourtHouse1's floor2's room2's has Judge Judy.
(create (relElem (select (relElem (select courtHouse1 has floor2))
has
room2))
has
judy)

// Find a staff member of a judge
// whose assistant has phone# 737-5588.
// Displays clerk Clark.
(msgbox (and (select (select judge instance *) staffMember *)
(select * assistant (select * phone# 737-5588))))

Something seems wrong with the above. Either there are two distinct
doctor subtypes which would lead to problems associated with redundant
representation. Or there is only one doctor subtype but it has to very
different superTypes: human and alien. Thus john, bob and mary are all
humans and aliens ???

PS. Nick may have exited the thread, so posts from other Prologers
would be welcomed.

Okay, but where does relational allegedly trip up or get difficult?

I would say mostly in the has hierarchy whose root is CourtHouse1. This
is because the has hierarchy contains things of various types
(buildings, floors, rooms and persons at various levels).

Dir

Neo wrote:

I would agree that your approach makes it easier to get a report of all
the varied stuff in or belonging to the courthouse. But in my
observation these are not the most frequent kind of queries. Usually
report requests are more narrow in scope. For example, "What are all
the fixed assets in courthouse X that have not expired?" from the
accounting department. They are not concerned with personell in there
also.

Your approach seems optimized for a newbie to gain *general*
familiarization of the area or a physical simulation, such as The Sims.
But it does not appear well optimized for business-oriented queries,
which are usually more focused in purpose. If this means that RM is
optimzed for the biz world but not other domains, perhaps you have a
point. But I have not really explored such outside of biz much, so
cannot really comment. (It does remind me of DOM though, which I am
not very fond of.)


Judge Judy? Isn't that a TV show?

-T-

Your correct in that some queries are more common in a particular
application. RM is more efficient in some scopes (more structured
data). Dbd may do better in other scopes (highly unstructured data).

I'm gonna market it to dummies, someday

There is a tendency (am I guilty of it too) for one to only recognize
nails when one has been using a hammer for some time

accounting department. They are not concerned with personel in there
also.

If you'd like, I can add a second court house, some fixed assets
(desks, chairs and computers) that belong to two departments occupying
room(s) in courtHouse1 and room(s) in courtHouse2. To keep the example
simple, I'll only add a name, serial# and a boolean expired attribute
for each equipment. While dbd's queries cannot find sums or totals
without the assistance of code at this time, the queries will be able
to find the desired equipment. When such a query is executed from the
GUI, dbd highlights the appropriate tree node in steps.