We don't say "aboot", they say "abowat".. easiest way to speak 'Merkin
is to put an Elvis-sneer at a random place in any multisyllabic word.

rpl

Isn't that "peals of laughter"?

No realli! She was Karving her initials on the moose with the
sharpened end
of an interspace toothbrush given her by Svenge - her brother-in-law -
an
Oslo dentist and star of many Norwegian movies: "The Hot Hands of an
Oslo
Dentist", "Fillings of Passion", "The Huge Molars of Horst
Nordfink"...

;-)

-- Jan Hidders

No realli! She was Karving her initials on the moose with the
sharpened end of an interspace toothbrush given her by Svenge - her
brother-in-law - an Oslo dentist and star of many Norwegian movies:
"The Hot Hands of an Oslo Dentist", "Fillings of Passion", "The Huge
Molars of Horst Nordfink"...

;-)

-- Jan Hidders

God I miss Carson.

Marshall

You are 100% correct. I totally agree, the model I proposed would not
stand up. I said essentially the same thing in

http://groups.google.com/group/comp.databases.theory/browse_frm/thread/1394e3efa
972255c/5653fd52e5be57ca#5653fd52e5be57ca

(and was called to task for saying that 'there is no "clean,
efficient way to store this information" in the relational
model that satisfies all constraints').

However, the issue for me was not the model per se, only the use of a
predicate construction that would allow mapping to the Aggregate-Link
representation of relationships discussed here:

http://www.sfdbs.com/toplevel/fasttrack/fasttrack.shtml

I should note also that nowhere in www.sfdbs.com do I advocate the use
of the A-L representation for conventional relational databases.
Rather, I argue that the best indicated use for A-L is in the use of
RDBs and RDBMSs as analytic tools. For example, to ask/answer
questions /about/ other RDBs, like:

  Is a given key a candidate key?
  Is a relationship represented by a Junction Table actually 1-to-M?

And the biggie:

  Are these two database A and B the same? (whatever "same" means)

To use A-L for analytic purposes on other RDBs, it is important to
know how A-L differs from the more traditional representations. That
was the objective in setting forth my primitive model.

Although Marshall says: "I *still* don't know what you find
interesting about it", I would argue that in addition to being the
first, new relationship representation in 35 years (nested sets
notwithstanding), it also demonstrates considerable analytic utility.

Rob

I've always assumed you were expressing your honest opinions.

If you are going to quote me, please be accurate. I have never used
the word "revolutionary". That adjective can only be applied
retrospectively (like "the RM was revolutionary"). Also, I only claim
it is the "first, new relationship REPRESENTATION to be discovered in
33 years," not the "first new relationship". There is definitely
utility. Whether it can be translated into value is as yet unknown. As
I said in fasttrack, "With the passage of more than 30 years,
conventional PKFK and JT representations may constitute a legacy that
renders A-L superfluous."

For 2 weeks, you and I have had a dialog with each of us operating at
a different level of abstraction within the universe of relational
data models. As Codd says in his 1980 paper, "DATA MODELS in DATABASE
MANAGEMENT":

<quote>
Many people fail to separate in their minds different levels of
abstraction. A specific example of this is the failure to realize that
tuples are at a higher level of abstraction than records (one is not
allowed to use the contiguity of components of tuyples, whereas one
can use the contiguity of fields in a record).
</quote>

So when (for example) CELKO says (#239 in "Newbie question about db
normalization theory: redundant keys OK?"): 'I need to add that
[''Links point, foreign keys constrain''] to my "columns are not
field, rows are not records, files are not tables!" rant', he is
demonstrating his intolerance to the lower level abstractions (fields,
records, files) that programmers must face as they cross the seam
between a data model implemented in an SQL DBMS and the external
representation of a query response. (Which you must admit looks alot
like a file of ordered, fixed-field records.)

My whole purpose was getting past your claim: "Your AL structure
corresponds to no statement of fact that I can think of." I worked up
my example so we could have one simple point of agreement from which
we could proceed: That there are "statements of fact" (propositions)
that map to the A-L data structure. Your data model (RM) must be
mapped to an RDM engine to actually define and use relational
databases. Your data model /seems/ to employ 2 "design patterns" (I
also dislike that term) that conveniently map to the two data
structures that I call "PKFK" and "JT". All I did in my example
(above) was to show how propositions can also map to A-L. And you are
absolutely correct, A-L is made up of a pair of these data structures,
one PKFK and one JT. (Everything "new" is made up of components that
are "old" -- just check the patent literature.)

I work at different abstraction levels than you. My main concern has
been relational systems development, so naturally I have also had to
pay attention to the SQL paradigm level as defined by ANSI SQL
standards. You have disparagingly used the terms "hocus pocus" and
"hand wavy stuff" to refer to the fasttrack contents of my website,
but I suspect your biggest objections are to my use of NULLs,
relationships and the terms "parent" and "child". I can't banish NULLs
just because practioners at your level of abstraction don't use them,
and I can't escape relationships, parent- and child tuples because
that's what has to be implemented. (If you ignore NULLs at the SQL
level, you will see that instead of 4 relationship types for PKFK, 4
for JT and 20 for A-L, you actually end up with 2, 2 and 10. What a
surprise.)

My biggest gripe about SQL is not data models, but how it tolerates
denormalized multisets as query responses. Why do we work so hard to
get a normalized database and then put up with query responses which
destroy that normalization? The SQL standard could easily admit
responses to SPJ queries that are recursive lists. A recursive list
can be denormalized to produce a report if needed, but a recursive
list is a far superior form for data delivery to an application than a
denormalized multiset.

And finally, I have investigated all the design patterns that employ 3
or fewer foreign keys. There's only one that hasn't been mentioned,
and it is of interest for transaction processing environments, not
distributed OLAP. I had an excellent research mentor and I think the
website reflects a fairly thorough examination of all important
aspects of the new, A-L database data structure. Once upon a time, I
worried about getting the kind of "credit" you speak of (above) for my
research results. Now I'm more interested in 1) making database
technology more widely available, 2) analytics, 3) using lattice
relationships to solve problems not previously considered solvable
within the SQL paradigm and 4) integrating databases across networks

Let's move on. This thread has been exhausted. I started a new thread
"Data Models and Levels of Abstraction". Let's continue the
conversation there.

Rob