Something new for the New Year (2008).

Rob

unread,

Jan 1, 2008, 5:45:48 PM1/1/08

to

If you have a chance, please take a look on my website at this page:

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

You will see a completely new way to use foreign keys
to represent relationships in relational databases.

Working with this new representation has forever changed the way I
look
at and think about relational databases.

Rob

Bob Badour

unread,

Jan 1, 2008, 7:46:56 PM1/1/08

to

Rob wrote:

There is no stopping the invincibly ignorant. - DT

JOG

unread,

Jan 1, 2008, 8:01:23 PM1/1/08

to

Well, I gave it a good effort but when I got to: "Compare this to
PKFK: Where allowed, an orphan is represented by a NULL
Child_Parent_fk foreign key value. Childless parents are always
allowed and are represented implicitly by the absence of reference in
Child_Parent_fk among all Child tuples" I was fighting the urge to
jump ship.

Tuples in databases represent facts stated in the real world (they are
not entities or objects), and yet here you are adding link tables,
pointers, agregate tables, orphans, etc. And yet I don't see anything
added that a well designed schema wouldn't achieve. Imho, I hope you
didn't spend too much on patents.

Marshall

unread,

Jan 2, 2008, 10:19:14 PM1/2/08

to

On Jan 1, 2:45 pm, Rob <rmpsf...@gmail.com> wrote:
> If you have a chance, please take a look on my website at this page:
>
> http://www.sfdbs.com/toplevel/fasttrack/fasttrack.shtml
>
> You will see a completely new way to use foreign keys
> to represent relationships in relational databases.

What is wrong with the existing way?

Looking at your webpage, I didn't see any problem statement.
What problem is this technique intended to solve? What makes
it better than existing techniques?

> Working with this new representation has forever changed the way I
> look at and think about relational databases.

That's a dramatic statement, but not a very motivating one.
Is the new way you look and think about relational databases
better or worse than the way you used to look at them?
How can we tell?

Marshall

TroyK

unread,

Jan 3, 2008, 1:18:22 PM1/3/08

to

Seconded....

From the paper:
"There doesn't seem to be any commonly accepted name for the Figure 1
representation. "

Sure there is. It's called a subset requirement constraint.

Many more gems like the above where the author betrays his lack of
understanding of the subject matter.

Good luck with the patent, anyway, I guess. I think I'm going to
patent FK declarations -- according to your paper, they're much more
ubiquitous, so I can better reap the benefits when I charge royalties
for their use.

TroyK

Rob

unread,

Jan 3, 2008, 1:52:14 PM1/3/08

to

On Jan 2, 8:19 pm, Marshall <marshall.spi...@gmail.com> wrote:
> On Jan 1, 2:45 pm, Rob <rmpsf...@gmail.com> wrote:
>
> > If you have a chance, please take a look on my website at this page:
>
> >http://www.sfdbs.com/toplevel/fasttrack/fasttrack.shtml
>
> > You will see a completely new way to use foreign keys
> > to represent relationships in relational databases.
>
> What is wrong with the existing way?
>

When it comes to information technology, "right" and "wrong" are
dangerously loaded terms. (Unless one technology fails to produce the
"right" result.) A more appropriate axis for comparison is
productivity, sometimes measured in net revenue per employee. The
downside of "the existing way(s)" is that knowledge workers and
application programmers of ordinary computer skills cannot seem to
master database design, querying and response interpretation without
expensive SQL/database experts. If we could makes database usage
second nature to these individuals, the total cost of database
ownership would be lower, and therefore, productivity higher. This
representation is a first step in that direction, but the whole SQL
database paradigm needs to be rethought if we are going to both
preserve investments in current databases and database practices, and,
open the benefits of database usage directly to a wider, less trained
(and therefore less expensive) workforce.

>
>
> Looking at your webpage, I didn't see any problem statement.
> What problem is this technique intended to solve? What makes
> it better than existing techniques?
>

For now, just think of it as a new, interesting technology. I've
worked with it since 1997: I could provide a long list here of its
advantages, and I will add material to the website as fast as I can.
cdt is a powerful group. It was (is) my intent to present the basic
technology here and see where cdt people may choose to take it. I
don't want to impose my high-level interpretations on it without
giving people the chance to see it and think about it in its most
basic form.

>
> > Working with this new representation has forever changed the way I
> > look at and think about relational databases.
>
> That's a dramatic statement, but not a very motivating one.
> Is the new way you look and think about relational databases
> better or worse than the way you used to look at them?
> How can we tell?
>
> Marshall
>

I did not want to go that far in the initial presentation, but since
you asked, here's my abbreviated answer.

Many fields that possess a mathematical underpinning exhibit the
principle of duality. (See http://en.wikipedia.org/wiki/Duality .) For
example, in graph theory, every theorem about vertices has a
corresponding and equivalent dual theorem about edges. In Linear
Programming, for every minimization problem, there is a equivalent
dual maximization problem in which the min of the first equals the max
of the dual. (The minimization problem is the dual of the maximization
problem: They are duals of one another.)

For 35+ years, the conversation about relational database technology
seems to have been exclusively about "things" or "entities" or
"objects": Relationships and relationship representation are virtually
invisible. (For example, casting Junction Tables as "association
entities".) Is there a dual, relationship-oriented approach?

What the "new representation" does is simplify (and unify)
relationship representation, making it possible to partition every
relational database into two constituent parts, a data part and a
disjoint "structure" part. (See
http://www.sfdbs.com/toplevel/fasttrack/fasttrack.shtml .) This makes
it possible to "think about" database design and querying in terms of
data AND structure. (This is very similar to graph theory duality.)

Here's a real simple example of the difference. In the FROM clause in
a conventional SQL SELECT, the list of relations specifies a search
space consisting a product of relations. That product space is
restricted by predicates in the JOIN clauses and/or the WHERE clause.
In the dual, relationship approach, the FROM clause equivalent would
specify a list of relationships: Each relationship implies the parent-
and child relations plus the attribute-data-free structure relations.
Implicitly, these relationships "compose" to define a search space
that accounts for the join predicates. The WHERE clause equivalent
contains no joins because the join operations are implicit in the
relationship structures and their composition. The search space is
smaller. Without joins and (if you follow the notion of structure
independence) with no foreign keys in entity relations, relational
modeling and query formulation is conceptually simpler. Perhaps simple
enough to lower the bar to entry!

Some (like JOG) interpret the data structures (relations) of a
relational database as sets of "true" logical statements. I personally
don't see how that benefits the database designer/user, but if they
prefer that approach, they certainly should use it. However, I do not
see an obvious "dual" in this interpretation that corresponds to the
"structure" dual in the data + structure formulation.

Rob

P.S. I don't want to start a religious war here, but NULL values for
foreign keys (where allowed) are unambiguous. If you automatically
reject any approach that utilizes NULL values, at least take the time
to differentiate the interpretation of NULL values in the structure
representation and NULL values for non-key attributes.

Rob

unread,

Jan 3, 2008, 3:47:42 PM1/3/08

to

On Jan 3, 11:18 am, TroyK <cs_tr...@juno.com> wrote:
> On Jan 1, 6:01 pm, JOG <j...@cs.nott.ac.uk> wrote:
>

<<snip>>
>
> Seconded....
>
I don't normally respond to ad hominem attacks, but let's clear the
record here:

>
> From the paper:
> "There doesn't seem to be any commonly accepted name for the Figure 1
> representation. "
>
> Sure there is. It's called a subset requirement constraint.
>

I checked the 2005, 2006 and 2007 SIGMOD and PODS Proceedings. The
phrase "subset requirement constraint" never occurs. I then checked
E.F.Codd's "The Relational Model for Database Management" (1990) and
it wasn't there either. Then I used my ACM subscription to check the
Digital Library, and you know, it wasn't there either. As a last
resort, I google'd the term and lo and behold, there is a book
"Applied Mathematics for Database Professionals" by de Haan and
Koppelaars and they use that term.

So much for "commonly accepted", at least insofar as the community of
database experts and academics is concerned.

>
> Many more gems like the above where the author betrays his lack of
> understanding of the subject matter.
>
> Good luck with the patent, anyway, I guess. I think I'm going to
> patent FK declarations -- according to your paper, they're much more
> ubiquitous, so I can better reap the benefits when I charge royalties
> for their use.
>

> TroyK- Hide quoted text -
>
According to

http://www.patentlawportal.com/information/patentability/what-are-the-equirements-for-patentability.html
,

"In order for the PTO to consider an invention eligible for a patent,
it must be novel, nonobvious and possess a utility."

Since foreign keys aren't exactly novel, your admittedly tongue-in-
cheek "gem" (that you are "going to patent FK declarations") "betrays"
that you are no better informed about patents than database.

Enough said. I have nothing against you and I gladly welcome any
constructive, critical input you choose to provide. But please don't
attack me. My cdt posting was about a novel, non-obvious technology
that has significant utility. It was not about me and certainly not
about you.

Rob

Jan Hidders

unread,

Jan 3, 2008, 4:57:01 PM1/3/08

to

On 3 jan, 21:47, Rob <rmpsf...@gmail.com> wrote:
> On Jan 3, 11:18 am, TroyK <cs_tr...@juno.com> wrote:> On Jan 1, 6:01 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> <<snip>>
>
> > Seconded....
>
> I don't normally respond to ad hominem attacks, but let's clear the
> record here:
>
> > From the paper:
> > "There doesn't seem to be any commonly accepted name for the Figure 1
> > representation. "
>
> > Sure there is. It's called a subset requirement constraint.
>
> I checked the 2005, 2006 and 2007 SIGMOD and PODS Proceedings.

In that case you'd better look for the term "inclusion dependency".
But that is just the name of a general type of database constraint, of
which foreign keys are usually assumed to be the special case where
the destination is a candidate and/or a primary key. What you seem to
be talking about here is the use of a foreign key to represent a
binary relationship. I'm not sure why you think there should be
another name for this "construct" then simply "foreign key" is not
clear to me.

-- Jan Hidders

Bob Badour

I'm sure all that you have written is well-intended but all I see is
buzzwords and hocus-pocus. If you can't respond to Marhsall's
questions directly in a paragraph or so, well it sets alarm bells off
somewhat. I am honestly not saying any of this to be nasty, its just
that if your web page "fasttrack" looks like gobbledegook to me, well
it sure will to a lot of other people too.

Perhaps you will be able to take something useful from my comments,
but I worry that you are so committed to this now that any
reassessment would be extremely difficult.

>
> Rob
>

Marshall

unread,

Jan 3, 2008, 8:28:00 PM1/3/08

to

On Jan 3, 10:52 am, Rob <rmpsf...@gmail.com> wrote:
> On Jan 2, 8:19 pm, Marshall <marshall.spi...@gmail.com> wrote:> On Jan 1, 2:45 pm, Rob <rmpsf...@gmail.com> wrote:
>
> > > If you have a chance, please take a look on my website at this page:
>
> > >http://www.sfdbs.com/toplevel/fasttrack/fasttrack.shtml
>
> > > You will see a completely new way to use foreign keys
> > > to represent relationships in relational databases.
>
> > What is wrong with the existing way?
>
> When it comes to information technology, "right" and "wrong" are
> dangerously loaded terms. (Unless one technology fails to produce the
> "right" result.) A more appropriate axis for comparison is
> productivity, sometimes measured in net revenue per employee.

Wow. Okay. What about the existing way does not produce
as much revenue per employee as your new way? Of course
by raising this issue you now need to include measured
revenue-per-employee numbers in your response.

> The
> downside of "the existing way(s)" is that knowledge workers and
> application programmers of ordinary computer skills cannot seem to
> master database design, querying and response interpretation without
> expensive SQL/database experts.

An interesting assertion. Can you back this up with any evidence?
It is not what I have observed. If anything SQL seems to be easier
to master than, say, C++, or concurrent programming, and hence
available to a larger class of people. For a long time I had a lot of
SQL questions in my standard interview, and lots of people did
quite well on them.

> If we could makes database usage
> second nature to these individuals, the total cost of database
> ownership would be lower, and therefore, productivity higher. This
> representation is a first step in that direction, but the whole SQL
> database paradigm needs to be rethought if we are going to both
> preserve investments in current databases and database practices, and,
> open the benefits of database usage directly to a wider, less trained
> (and therefore less expensive) workforce.
>
> > Looking at your webpage, I didn't see any problem statement.
> > What problem is this technique intended to solve? What makes
> > it better than existing techniques?
>
> For now, just think of it as a new, interesting technology. I've
> worked with it since 1997: I could provide a long list here of its
> advantages, and I will add material to the website as fast as I can.
> cdt is a powerful group. It was (is) my intent to present the basic
> technology here and see where cdt people may choose to take it. I
> don't want to impose my high-level interpretations on it without
> giving people the chance to see it and think about it in its most
> basic form.

That's nice and all, but having been around for as long as I have
been I tend to distrust any claims for new technologies that don't
have any descriptions of benefits. There's a lot of stuff out there
competing for my attention; I necessarily can only look closely at
a few things. So I'm interested in seeing the bottom line as quickly
as possible, and the bottom line is: how does this benefit me?

> > > Working with this new representation has forever changed the way I
> > > look at and think about relational databases.
>
> > That's a dramatic statement, but not a very motivating one.
> > Is the new way you look and think about relational databases
> > better or worse than the way you used to look at them?
> > How can we tell?
>

> I did not want to go that far in the initial presentation, but since
> you asked, here's my abbreviated answer.
>
> Many fields that possess a mathematical underpinning exhibit the

> principle of duality. (Seehttp://en.wikipedia.org/wiki/Duality.) For

> example, in graph theory, every theorem about vertices has a
> corresponding and equivalent dual theorem about edges. In Linear
> Programming, for every minimization problem, there is a equivalent
> dual maximization problem in which the min of the first equals the max
> of the dual. (The minimization problem is the dual of the maximization
> problem: They are duals of one another.)

I'm immensely attracted to the duality principle on aesthetic grounds.
But I try to be realistic. Gratzer's "General Lattice Theory" says
this
on page 3:

"It is hard to imagine that anything as trivial as the Duality
Principle
could yield anything profound, and it does not; but it can save
a lot of work."

> For 35+ years, the conversation about relational database technology
> seems to have been exclusively about "things" or "entities" or
> "objects": Relationships and relationship representation are virtually
> invisible. (For example, casting Junction Tables as "association
> entities".) Is there a dual, relationship-oriented approach?

The relational model treats relationships in a first class way.
I suppose what you are saying above applies to some E/R or
other modeling approach? I haven't myself studied any modeling
disciplines per se, but as far as the RM goes, it models our
ideas about real-world entities and our ideas about real-world
relationships in exactly the same way: as mathematical relations.
I don't see anything about a many-to-many table that is any
more "invisible" than a customers table.

> What the "new representation" does is simplify (and unify)
> relationship representation, making it possible to partition every
> relational database into two constituent parts, a data part and a

> disjoint "structure" part. (Seehttp://www.sfdbs.com/toplevel/fasttrack/fasttrack.shtml.) This makes

> it possible to "think about" database design and querying in terms of
> data AND structure. (This is very similar to graph theory duality.)

Hmmm. You say "simplify", but it seems to me your schema in figures
4 and 5 are more complicated than they need to be.

> Here's a real simple example of the difference. In the FROM clause in
> a conventional SQL SELECT, the list of relations specifies a search
> space consisting a product of relations. That product space is
> restricted by predicates in the JOIN clauses and/or the WHERE clause.
> In the dual, relationship approach, the FROM clause equivalent would
> specify a list of relationships: Each relationship implies the parent-
> and child relations plus the attribute-data-free structure relations.
> Implicitly, these relationships "compose" to define a search space
> that accounts for the join predicates. The WHERE clause equivalent
> contains no joins because the join operations are implicit in the
> relationship structures and their composition. The search space is
> smaller. Without joins and (if you follow the notion of structure
> independence) with no foreign keys in entity relations, relational
> modeling and query formulation is conceptually simpler. Perhaps simple
> enough to lower the bar to entry!

I really don't see how this is simpler. I *can* see some ways in
which it is more complicated, however. Your schema is more
complicated for one thing. I am skeptical whether your approach
will yield the simpler queries you claim. Would you care to write
some queries both ways and we could compare them?

Marshall

Rob

unread,

Jan 3, 2008, 10:49:46 PM1/3/08

to

Wow, I sure stirred up a hornets nest.

Let me see if I can make a few observations and then back away from
this. The USPTO delivered a particularly inspiring Office Action and
my first responsibility must be to respond to them, not to cdt.

1. Rob said the following:

> Some (like JOG) interpret the data structures (relations) of a
> relational database as sets of "true" logical statements.

In reply, JOG said:

>>I'm sorry Rob, but that's not an interpretation. Thats /what it is/.
>>The relations of a relational database encode true facts about the
>>world.

But according to Marshall:

>as far as the RM goes, it models our
>ideas about real-world entities and our ideas about real-world
>relationships in exactly the same way: as mathematical relations.

So as long as there is no universal consensus about how
relational databases and the relational model allow us to represent
"true facts" and "entities and ... relationships", I think I should be
allowed to have my primitive view of a relational database as a
set of sets of vectors. (Please, hold your applause until the end.)

2. Marshall asked me a number of questions which I tried to
answer. And although I told Marshall that I just wanted to show
cdt folk something that I thought was new and interesting, Marshall
insists he needs much, much more.

But, JOG tells me that "If [I] can't respond to Marhsall's [sp]
questions directly in a paragraph or so, then alarm bells go off."

Rome wasn't built in a day.

3. Curiously, the only indisputable comment came from Jan Hidders:

"I'd prepare myself for a tidal wave of negativity, if I were you. "

4. Here are two Q&As from a July 28, 2007 interview of Scott
Berkun by Guy Kawasaki. See if they remind you of anything:

"Question: Why do innovators face such rejection and negativity?
Answer: It's human nature -- we protect ourselves from change. We like
to think we're progressive, but every wave of innovation has been much
slower than we're told. The telegraph, the telephone, the PC, and the
internet all took decades to develop from ideas into things ordinary
people used. As a species we're threatened by change and it takes a
long time to convince people to change their behavior, or part with
their money."

Question: What are the primary determinants of the speed of adoption
of innovation?
Answer: The classic research on the topic is Diffusion of Innovation
by Rogers, which defines factors that hold up well today. The surprise
to us is that they're all sociological: based on people's perception
of value and their fear of risks -- which often has little to do with
our view of how amazing a particular technology is.

For the full interview, see

http://blog.guykawasaki.com/2007/06/ten-questions-w.html

I would also commend you to Geoffrey A. Moore's classic "Crossing
the Chasm" and Malcolm Gladwell's "The Tipping Point". These aren't
database texts, but treatises on how some innovations and inventions
lead to sucessful products.

Marshall

unread,

Jan 4, 2008, 12:03:46 AM1/4/08

to

On Jan 3, 7:49 pm, Rob <rmpsf...@gmail.com> wrote:
>
> 1. Rob said the following:
>
> > Some (like JOG) interpret the data structures (relations) of a
> > relational database as sets of "true" logical statements.
>
> In reply, JOG said:
>
> >>I'm sorry Rob, but that's not an interpretation. Thats /what it is/.
> >>The relations of a relational database encode true facts about the
> >>world.
>
> But according to Marshall:
>
> >as far as the RM goes, it models our
> >ideas about real-world entities and our ideas about real-world
> >relationships in exactly the same way: as mathematical relations.

Your implication seems to be that there is some inconsistency
or disagreement between what JOG and I said. I don't see any
disagreement there.

> So as long as there is no universal consensus about how
> relational databases and the relational model allow us to represent
> "true facts" and "entities and ... relationships", I think I should be
> allowed to have my primitive view of a relational database as a
> set of sets of vectors. (Please, hold your applause until the end.)

It seems to me that JOG's "facts about the world" and my "ideas
about real-world entities and ... relationships" refer to the same
thing.

> 2. Marshall asked me a number of questions which I tried to
> answer. And although I told Marshall that I just wanted to show
> cdt folk something that I thought was new and interesting, Marshall
> insists he needs much, much more.
>
> But, JOG tells me that "If [I] can't respond to Marhsall's [sp]
> questions directly in a paragraph or so, then alarm bells go off."
>
> Rome wasn't built in a day.

I don't think I asked for "much, much" more. All I asked for was
some modest indication of why your way was "better" in the
most generic sense of "better." It wasn't I who introduced
revenue-per-employee! And in fact I am pretty clear you left
the "interesting" part out of your intended new-and-interesting
thing: I *still* don't know what you find interesting about it.

I mean, how hard would is it to take two hand-picked schemas
and show how a query gets shorter or easier to understand
or whatever under the new approach?

> 3. Curiously, the only indisputable comment came from Jan Hidders:

This is not an unusual circumstance.

> 4. Here are two Q&As from a July 28, 2007 interview of Scott
> Berkun by Guy Kawasaki. See if they remind you of anything:
>
> "Question: Why do innovators face such rejection and negativity?
> Answer: It's human nature -- we protect ourselves from change. We like
> to think we're progressive, but every wave of innovation has been much
> slower than we're told. The telegraph, the telephone, the PC, and the
> internet all took decades to develop from ideas into things ordinary
> people used. As a species we're threatened by change and it takes a
> long time to convince people to change their behavior, or part with
> their money."
>
> Question: What are the primary determinants of the speed of adoption
> of innovation?
> Answer: The classic research on the topic is Diffusion of Innovation
> by Rogers, which defines factors that hold up well today. The surprise
> to us is that they're all sociological: based on people's perception
> of value and their fear of risks -- which often has little to do with
> our view of how amazing a particular technology is.
>
> For the full interview, see
>
> http://blog.guykawasaki.com/2007/06/ten-questions-w.html
>
> I would also commend you to Geoffrey A. Moore's classic "Crossing
> the Chasm" and Malcolm Gladwell's "The Tipping Point". These aren't
> database texts, but treatises on how some innovations and inventions
> lead to sucessful products.

Harumph. I think you're starting to condescend here. The fact
that everyone scoffed at Einstein for a year doesn't mean that
everyone who gets scoffed at for a year is the next Einstein.
Most good ideas get scoffed at; most bad ideas get scoffed
at too. Let's not forget Sturgeon's Law either.

Berkun isn't the source of any particular innovation that I'm aware
of. He's someone who studied others' innovations. And if he only
studied the ones that were ultimately successful, he's in no position
to say anything intelligent about what the right response to new
ideas is; his sample is hopelessly biased. If he really wanted to
understand the world's ratio of good ideas to bad, he should
read sci.math.

Marshall

Bob Badour

unread,

Jan 4, 2008, 7:57:18 AM1/4/08

to

Marshall wrote:

While not Guy Kawasaki, I think it would be much more relevant and
illuminating to quote something else:

http://www.ncbi.nlm.nih.gov/pubmed/10626367

"their incompetence robs them of the metacognitive ability to realize it"

Rob

unread,

Jan 4, 2008, 12:08:12 PM1/4/08

to

On Jan 3, 10:03 pm, Marshall <marshall.spi...@gmail.com> wrote:
>
> Harumph. I think you're starting to condescend here.
>

Absolutely not!!

I have the utmost respect for cdt and the individuals who post here,
even if they occasionally get off-message and attack the messenger.

It is out of this respect that I chose cdt as the first place to make
this material available:

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

And, I keyed the presentation to the high level of expertise and
experience I've come to expect here. Don't forget, there are also a
lot of sharp database types who follow cdt but seldom (or never) post
to it. Perhaps a few of them will find something interesting in this
material.

Every piece of original research starts out known only to the
researcher(s). At some point, it must be exposed to a wider audience.
If it is a good idea, it may take root. If not, well, I guess I am
prepared for that. You will note however that nowhere in this thread
(to date) has anyone addressed any technical questions surrounding
structure independence, precision, lattice relationships, etc.

I am a database practioner, not a theorist. The website page I
directed you to does not claim that the Aggregate-Link representation
should replace conventional relationship representations or be used in
conventional relational databases. Instead, it shows how one can use
the technology to integrate two or more remote relational databases
into non-updatable relational views, and it lays the groundwork for
future exploration/exposition of relationship-oriented data models. (I
bet you can hardly wait!)

Rob

JOG

unread,

Jan 4, 2008, 1:23:27 PM1/4/08

to

On Jan 4, 3:49 am, Rob <rmpsf...@gmail.com> wrote:
> Wow, I sure stirred up a hornets nest.
>
> Let me see if I can make a few observations and then back away from
> this. The USPTO delivered a particularly inspiring Office Action and
> my first responsibility must be to respond to them, not to cdt.
>
> 1. Rob said the following:
>
> > Some (like JOG) interpret the data structures (relations) of a
> > relational database as sets of "true" logical statements.
>
> In reply, JOG said:
>
> >>I'm sorry Rob, but that's not an interpretation. Thats /what it is/.
> >>The relations of a relational database encode true facts about the
> >>world.
>
> But according to Marshall:
>
> >as far as the RM goes, it models our
> >ideas about real-world entities and our ideas about real-world
> >relationships in exactly the same way: as mathematical relations.
>

There is no difference between my and Marshall's views, because they
are just a repetition of what Codd defined the relational model to
be.

> So as long as there is no universal consensus about how
> relational databases and the relational model allow us to represent

But there /is/ universal consensus from people who have read the RM
paper. A tuple represents a fact as an instantiation of a predicate.
There is much discussion concerning other factors of the RM, but how
it represent facts is certainly not a point of contention.

> "true facts" and "entities and ... relationships", I think I should be
> allowed to have my primitive view of a relational database as a
> set of sets of vectors. (Please, hold your applause until the end.)

>[snip]

I wonder if you are perhaps you trying to implement a different data
model inside of the RM mechanism (as people do with EAV)? The PKFK and
JT "structures" you describe correspond directly to propositions that
are stated in the real world, but I am at a loss as to what facts your
more complex A-L "structure" correspond to.

Rob

unread,

Jan 5, 2008, 2:59:53 PM1/5/08

to

Now I know how Charlie Brown would feel when Lucy volunteers yet again
to hold the football for him to kick. (My apologies if you are too
young to remember Peanuts.)

Nevertheless, I believe that the path to teaching includes tolerance
and patience, so I will try to address your questions. (With some
quibbles about your logic and some questions for you about the
interpretation of foreign keys in predicates.)

>
>There is no difference between my and Marshall's views, because they
>are just a repetition of what Codd defined the relational model to
>be.

On January 1, JOG said:
"Tuples in databases represent facts stated in the real world (they

are not entities or objects)".

On January 3, Marshall said:
"but as far as the RM goes, it models our ideas about real-world

entities and our ideas about real-world relationships in exactly the
same way: as mathematical relations".

And on January 3, JOG said:
"A tuple represents a fact as an instantiation of a predicate."

Is see a big difference here, particularly because mathematical
relations theory says nothing about predicates. I can accept that a
tuple of a mathematical relation or a vector can be /interpreted/ as
an existence predicate, but that still leaves the question (see below)
of how a foreign key is (or is part of) a fact or proposition or
predicate.

>> So as long as there is no universal consensus about how
>> relational databases and the relational model allow us to represent
>
>But there /is/ universal consensus from people who have read the RM
>paper.
>

If you are speaking of Codd's 1970 paper, I've read it many times and
I /don't/ share your beliefs. In logic, "universal" has a precise
meaning. Unless you have some reason to exclude me from the set of
"people who have read the RM paper", your statement is just rhetoric.
(You could say "most" or "the majority", but you didn't.)

>
>I wonder if you are perhaps you trying to implement a different data
>model inside of the RM mechanism (as people do with EAV)? The PKFK and
>JT "structures" you describe correspond directly to propositions that
>are stated in the real world, but I am at a loss as to what facts your
>more complex A-L "structure" correspond to.
>

I don't know what you mean when you say that 'The PKFK and JT

"structures" you describe correspond directly to propositions that are

stated in the real world'. I'm going to take a stab at it (next), but
I would appreciate some enlightment from you on what fact or
proposition the one foreign key in a PKFK representation child tuple
stands for and what fact(s) or proposition(s) the two foreign keys in
a JT representation stand for.

IF I ASSUME THAT:

a.) a value X in the foreign key in a PKFK child tuple is the fact:
"this child tuple is related to [or included in the set of child
tuples related to] the parent tuple whose primary key value is X";
b.) a value pair (Y,Z) in the foreign keys in a JT tuple is the fact:
"the parent tuple with primary key Y is related to the child tuple
with primary key Z".

THEN FOR THE A-L REPRESENTATION:

c.) a value U in the parent foreign key of an aggregate tuple (in the
Aggregate-Link representation) is the fact: "there exists an
aggregation for which the parent tuple with primary key X has a
distinguished role", and
d.) a value pair (V,W) in the aggregate- and child foreign keys
(resp.) of a link tuple (in the Aggregate-Link representation,
associated only with the aggregate relation containing the aggregate
tuple in c) is the fact: "the child tuple with primary key W belongs
to the aggregation specified by the aggregate tuple with primary key
V".

This is my best guess as the answer to your (implied) question 'what
facts [do] your more complex A-L "structure" correspond to?'. If I
have misinterpreted the meaning of the foreign keys that you say
'correspond directly to propositions that are stated in the real
world', I apologize. Explain what you mean and I'll try (yet) again.

Rob

JOG

unread,

Jan 7, 2008, 8:29:16 PM1/7/08

to

On Jan 5, 7:59 pm, Rob <rmpsf...@gmail.com> wrote:
> Now I know how Charlie Brown would feel when Lucy volunteers yet again
> to hold the football for him to kick. (My apologies if you are too
> young to remember Peanuts.)
>
> Nevertheless, I believe that the path to teaching includes tolerance
> and patience, so I will try to address your questions. (With some
> quibbles about your logic and some questions for you about the
> interpretation of foreign keys in predicates.)
>
>
>
> >There is no difference between my and Marshall's views, because they
> >are just a repetition of what Codd defined the relational model to
> >be.
>
> On January 1, JOG said:
> "Tuples in databases represent facts stated in the real world (they
> are not entities or objects)".
>
> On January 3, Marshall said:
> "but as far as the RM goes, it models our ideas about real-world
> entities and our ideas about real-world relationships in exactly the
> same way: as mathematical relations".
>
> And on January 3, JOG said:
> "A tuple represents a fact as an instantiation of a predicate."
>
> Is see a big difference here, particularly because mathematical
> relations theory says nothing about predicates.

Nope no difference I'm afraid. A proposition that satisfies a
predicate P(a,b,...z) is encoded as a tuple of values. All the tuples
(rows) satisfying P, are collected as a set, which we call a relation
(table). This is sort of database 101 really.

> I can accept that a
> tuple of a mathematical relation or a vector can be /interpreted/ as
> an existence predicate, but that still leaves the question (see below)
> of how a foreign key is (or is part of) a fact or proposition or
> predicate.
>
> >> So as long as there is no universal consensus about how
> >> relational databases and the relational model allow us to represent
>
> >But there /is/ universal consensus from people who have read the RM
> >paper.
>
> If you are speaking of Codd's 1970 paper, I've read it many times and
> I /don't/ share your beliefs. In logic, "universal" has a precise
> meaning. Unless you have some reason to exclude me from the set of
> "people who have read the RM paper", your statement is just rhetoric.
> (You could say "most" or "the majority", but you didn't.)

Then you honestly need to reread the paper Rob. Or get "Introduction
to Databases" by Codd, which is more thorough and more up to data. Any
database theory primer should do really.

You're way overcomplicating Rob - you sound like an OO programmer who
came to databases later? Am I right? You have to forget children and
parents mate, they are OO concepts and make no sense in predicate
logic where there is just inference (It was a wrench for me when I had
to make that leap). Anyhow, here is an example for you:

1) UK is in Europe => (country:UK, continent:Europe)
2) Canada is in N. America => (country:Canada, continent:N.America)
3) Bob is 30 and lives in the UK => (name:Bob, age:30, country:UK)
4) Sarah is 28 and lives in Canada => (name:Bob, age:30, country:UK)
5) Bob is Married to Sarah => (husband:Bob, bride:Sarah)

According to your definitions (1) and (2) are normal propositions (3)
and (4) are PKFK and (5) is a JT. Your AL structure corresponds to no
statement of fact that I can think of. Regards, J.

>
> Rob

Bob Badour

unread,

Jan 7, 2008, 8:53:01 PM1/7/08

to

JOG wrote:

To be fair, Codd didn't establish the equivalence of expression of the
algebra and the calculus until his 1972 paper.

unread,

Jan 8, 2008, 12:21:00 PM1/8/08

to

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

unread,

Jan 8, 2008, 4:57:25 PM1/8/08

to

Jan Hidders wrote:

> On 8 jan, 16:24, Bob Badour <bbad...@pei.sympatico.ca> wrote:
>

> 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"...
>
> ;-)

Oh! I get it! It's like a Henway!

Jan Hidders

unread,

Jan 8, 2008, 5:23:20 PM1/8/08

to

What's a Henway?

-- Jan - one good turn deserves another - Hidders

JOG

unread,

Jan 8, 2008, 5:42:46 PM1/8/08

to

and why would one good turn deserve another Hidders.... surely one
Hidders is enough? ;)

Bob Badour

unread,

Jan 8, 2008, 7:02:18 PM1/8/08

to

Jan Hidders wrote:

> On 8 jan, 22:57, Bob Badour <bbad...@pei.sympatico.ca> wrote:
>
>>Jan Hidders wrote:
>>
>>>On 8 jan, 16:24, Bob Badour <bbad...@pei.sympatico.ca> wrote:
>>
>>>>Marshall wrote:
>>
>>>>>On Jan 7, 6:40 pm, JOG <j...@cs.nott.ac.uk> wrote:
>>
>>>>>>I know nothing about Canada apart from there are a lot of moose
>>
>>>>>A moose once bit my sister.
>>
>>>>Really??? They are not all that well-known for biting. Derailing trains.
>>>>Yes. Decapitating drivers. Yes.
>>
>>>>But I have never heard of a moose biting before.
>>
>>>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"...
>>
>>>;-)
>>
>>Oh! I get it! It's like a Henway!
>
> What's a Henway?

Oh, about 2 lbs.

> -- Jan - one good turn deserves another - Hidders

Thanks for being such a sport!

Marshall

unread,

Jan 8, 2008, 7:32:02 PM1/8/08

to

On Jan 8, 1:04 pm, Jan Hidders <hidd...@gmail.com> wrote:
>
> 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"...

We apologise for the fault in the subtitles. Those responsible have
been sacked.

Marshall

unread,

Jan 8, 2008, 7:33:00 PM1/8/08

to

On Jan 8, 10:03 am, "David Cressey" <cresse...@verizon.net> wrote:
>
> Sounds like a curse Johnny Carson might have pronounced, as Karnak the
> magnificent.

God I miss Carson.

Marshall

Rob

unread,

Jan 10, 2008, 11:52:09 AM1/10/08

to

On Jan 7, 6:29 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> Anyhow, here is an example for you:
>
> 1) UK is in Europe => (country:UK, continent:Europe)
> 2) Canada is in N. America => (country:Canada, continent:N.America)
> 3) Bob is 30 and lives in the UK => (name:Bob, age:30, country:UK)
> 4) Sarah is 28 and lives in Canada => (name:Bob, age:30, country:UK)
> 5) Bob is Married to Sarah => (husband:Bob, bride:Sarah)
>
> According to your definitions (1) and (2) are normal propositions (3)
> and (4) are PKFK and (5) is a JT. Your AL structure corresponds to no
> statement of fact that I can think of. Regards, J.
>

1. Statement of Facts, Example 1:

2 sets if propositions (i.e., 2 tables: Adult, Child)
------------
Al is a male adult, age 45 => (adultname:A,sex:male,age:45)

Bob is a male child, age 15 => (childname:Bob,sex:male,age:15)
Carol is a female child, age 13 => (childname:Carol,sex:female,age:
13)
Dee is a female child, age 8 => (childname:Dee,sex:female,age:8)

what I referred to as JT's:
----
Al is father of Bob => (father:Al,child:Bob)
Al is father of Carol => (father:Al,child:Carol)
Al is father of Dee => (father:Al,child:Dee)

2. Now, although Al is father of Bob, Carol and Dee, only Bob and
Carol are siblings. Dee is a child of a 2nd marriage. We want
to capture the fact that Bob and Carol are siblings, but Bob
and Dee (and Carol and Dee) are half-siblings. So, instead of
the JT (i don't know what you call it), I propose the following
Aggregate and Link:

Aggregate:
--
Al is the father in family unit 1 => (familyunit:1,familyfather:Al)
Al is the father in family unit 2 => (familyunit:2,familyfather:Al)

Link:
--
Bob is a child in family unit 1 => (familychild:Bob,familyunit:1)
Carol is a child in family unit 1 => (familychild:Carol,familyunit:1)
Dee is a child in family unit 2 => (familychild:Dee,familyunit:2)

You don't explain how you formulate queries, but the sense of the
following should be clear:

Who are the siblings of B?
The siblings of Bob are the childs of the family unit
in which Bob is a child, not including Bob.
Who are the half-siblings of Bob?
The half-siblings of Bob are the childs of any family
unit with the same father as the familyfather of the
family unit in which B is a child, not including
the family unit in which B is a child.
Who is the father of B?
The father of B is the familyfather of the familyunit in
which B is a child.

OK?

Gene Wirchenko

unread,

Jan 10, 2008, 1:14:37 PM1/10/08

to

Rob <rmps...@gmail.com> wrote:

[snip]

>1. Statement of Facts, Example 1:
>
>2 sets if propositions (i.e., 2 tables: Adult, Child)
>------------
>Al is a male adult, age 45 => (adultname:A,sex:male,age:45)
>
>Bob is a male child, age 15 => (childname:Bob,sex:male,age:15)
>Carol is a female child, age 13 => (childname:Carol,sex:female,age:
>13)
>Dee is a female child, age 8 => (childname:Dee,sex:female,age:8)
>
>what I referred to as JT's:
>----
>Al is father of Bob => (father:Al,child:Bob)
>Al is father of Carol => (father:Al,child:Carol)
>Al is father of Dee => (father:Al,child:Dee)
>
>2. Now, although Al is father of Bob, Carol and Dee, only Bob and
> Carol are siblings. Dee is a child of a 2nd marriage. We want
> to capture the fact that Bob and Carol are siblings, but Bob
> and Dee (and Carol and Dee) are half-siblings. So, instead of
> the JT (i don't know what you call it), I propose the following
> Aggregate and Link:
>
>Aggregate:
>--
>Al is the father in family unit 1 => (familyunit:1,familyfather:Al)
>Al is the father in family unit 2 => (familyunit:2,familyfather:Al)

Not workable. They can all be the same family unit. What you
are missing is maternity. Add Susan and Vicki who are Al's first and
second wives and, more importantly, the mothers. You can then express
that Bob and Carol are siblings (because they have the same father and
the same mother) and that Carol and Dee are half-siblings (because
they only have one parent in common).

Since motherhood has been brought into the picture, maybe add a
predicate for "likes apple pie". <BEG with ice cream>

Rob

unread,

Jan 12, 2008, 3:01:16 PM1/12/08

to

On Jan 10, 11:14 am, Gene Wirchenko <ge...@ocis.net> wrote:

I don't know what you mean by "unworkable". Does that mean it is not
well-formed, or just that you have a different model?

According to Codd, a data model must have generalized integrity rules.
Tell me if my "aggregates" and "links" above violate the rules of your
data model.

Here's another stab that introduces mothers (though I know nothing
more than their names, hence no propositions about these mothers):

Propositions (2 sets, 2 relations, Adult and Child)
------------
Al is a male adult, age 45 => (adultname:Al,sex:male,age:45)

Bob is a male child, age 15 => (childname:Bob,sex:male,age:15)
Carol is a female child, age 13 => (childname:Carol,sex:female,age:
13)
Dee is a female child, age 8 => (childname:Dee,sex:female,age:8)

Aggregate:
---------
In one marriage, Susan is the mother, Al is the father =>
(mother:Susan,father:Al)
In another marriage, Vicki is the mother, Al is the father =>
(mother:Vicki,father:Al)

Link:
----
Bob's mother is Susan => (child:Bob,mother:Susan)
Carol's mother is Susan => (child:Carol,mother:Susan)
Dee's mother is Vicki => (child:Dee,mother:Vicki)

I'm not arguing that this is the best database design.
JOG said: "Your AL structure corresponds to no statement of
fact that I can think of." I'm trying to address his claim.

Rob

Gene Wirchenko

unread,

Jan 12, 2008, 8:54:26 PM1/12/08

to

Rob <rmps...@gmail.com> wrote:

[snip]

>I don't know what you mean by "unworkable". Does that mean it is not
>well-formed, or just that you have a different model?

Practically everyone would have a different model. Consider
"family unit". Most would consider that it means something like
household. You are using a different definition. That would cuase
problems.

Now, consider some sticky stuff.

Three years from now, Bob has graduated from school and and is no
longer living with his father. What family unit is he a member of
then?

A few years later, he marries Allison, and they have two
children, Samantha and Michael. What family unit is Bob a member of
then?

A few years after that, he and Allison divorce, and Allison gets
custody of Samantha, and Bob gets custody of Michael. What family
unit is Bob a member of then? What family unit is Samantha a member
of? What family unit is Michael a member of?

A few years later, Bob marries Lynn and they have a son Derek.
About the same time, Allison marries Charles and they have a daughter
Karen.

Question: Derek and Karen are not related biologically and have
never lived together. They might never have met. Are they siblings?
Are they members of the same family unit?

Allison and Charles die in a road accident. Bob get custody of
Samantha. Due to other concerns, he also gets custody of Karen. What
is the family unit setup then?

I have not even added examples about adoptees.

[snip]

Rob

unread,

Jan 15, 2008, 12:06:12 PM1/15/08

to

On Jan 12, 6:54 pm, Gene Wirchenko <ge...@ocis.net> wrote:

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/1394e3efa972255c/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

Marshall

unread,

Jan 15, 2008, 3:54:50 PM1/15/08

to

On Jan 15, 9:06 am, Rob <rmpsf...@gmail.com> wrote:
>
> 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.

I don't think you're taking point-of-view into consideration
very well.

Let me ask you: looking out my window, I see a lot of
fog. I claim it is the kind of fog that is just going to burn
off, and not the kind that will turn into rain. Do you agree?

See the problem?

I cannot disprove your "considerable analytic utility" claim.
Neither can I confirm it.

Maybe I could take a picture of the fog and send it to you.
Maybe you could show some of this analytic utility in action.
Then we might be on more solid footing with regards to
each others claims.

Marshall

JOG

unread,

Jan 15, 2008, 8:03:49 PM1/15/08

to

Fine, simple propositions.

>
> Aggregate:
> ---------
> In one marriage, Susan is the mother, Al is the father =>
> (mother:Susan,father:Al)
> In another marriage, Vicki is the mother, Al is the father =>
> (mother:Vicki,father:Al)

Aggregates? These are just propositions with two foreign keys - surely
this is just an associative entity/junction table/intersection table.

>
> Link:
> ----
> Bob's mother is Susan => (child:Bob,mother:Susan)
> Carol's mother is Susan => (child:Carol,mother:Susan)
> Dee's mother is Vicki => (child:Dee,mother:Vicki)

Links? These are just propositions with a single foreign key (PKFK I
think you called them). I don't understand why you have renamed these
things...

>
> I'm not arguing that this is the best database design.
> JOG said: "Your AL structure corresponds to no statement of
> fact that I can think of." I'm trying to address his claim.
>
> Rob

Honest opinions here Rob. First, while there are issues with this
example of course, it is still far better than your web page imo,
which was very convoluted (and set my crank alarm bells ringing I'm
afraid - best to know that though right?)

Second, I certainly don't think what you have observed is
revolutionary and claiming it as "first new relationship to be
discovered for 33 years" comes across as a bit silly to my ears. /
However/, that is not to say there is not value in there somewhere, so
please don't think I'm just doing you down...

I think you have in fact identified a common database design pattern,
and awareness of it (though I dislike the nomenclature that you have
conjured) is a very useful thing for database designers considering
their schemas. And as such, I think you should continue to investigate
database schemas, identifying other design patterns, and then collate
them all together - that could be useful stuff and ultimately get you
a lot more credit for it than any hand wavy stuff.

If you don't agree fair enough, but that is my honest analysis. All
best, Jim.

Gene Wirchenko

unread,

Jan 15, 2008, 9:03:46 PM1/15/08

to

Rob <rmps...@gmail.com> wrote:

[snip]

>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/1394e3efa972255c/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').

No wonder. For example, the deficiency of an SQL DBMS does not
speak against the RM.

Rob

unread,

Jan 17, 2008, 1:23:15 PM1/17/08

to

On Jan 15, 7:03 pm, Gene Wirchenko <ge...@ocis.net> wrote:

> Rob <rmpsf...@gmail.com> wrote:
>
> [snip]
>
> >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/threa...

>
> >(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').
>
> No wonder. For example, the deficiency of an SQL DBMS does not
> speak against the RM.
>

> Sincerely,
> Gene Wirchenko
>
Again, I agree 100%. The SQL paradigm is a horror, and the
implementations of SQL DBMSs encourage practices that are not just
bad, they are dangerous. Personally, I believe that the SQL paradigm
is the single biggest obstacle to wider use of relational databases.

I believe that from your perspective, an SQL DBMS is a necessary evil:
The only available engine that allows you to map your RM model
abstractions to operational relational DBs. Not dissimilarly, I see an
SQL DBMS as a component. However, because the A-L representation can
replace both the PKFK and JT representations, it makes it possible to
derive a simpler, relationship-oriented data model at the same level
of abstraction as SQL. My objective is a graphical data model defined
at a higher level of abstraction that makes relationship joins
transparent and therefore usable by less-trained knowledge workers.
This will be described in the "next installment" of my website.

I refer you to Codd's 1980 paper, "DATA MODELS IN DATABASE MANAGEMENT"
in which he wrote:

<quote>
A data model may be used in any of the following:
1) as a tool for specifying the kinds of data and data organization
that are permissable in a specific database;
2) as a basis for developing a general design methodology for
databases;
3) as a basis for coping with evolution of databases so as to have
minimal logical impact on existing applications programs and terminal
activities;
4) as a basis for the development of families of very high level
languages for query and data manipulation;
5) as a focus for DBMS architecture;
6) as a vehicle for research into the behavioral properties of
alternative organizations of data.
</quote>

I see this work on A-L as relating directly to items 4-6.

I thank you for your insightful comments. I think it's time we wrapped
up this thread and moved on.

See "Data Models and Levels of Abstraction".

Rob

unread,

Jan 17, 2008, 1:28:14 PM1/17/08

to

On Jan 15, 1:54 pm, Marshall <marshall.spi...@gmail.com> wrote:
> On Jan 15, 9:06 am, Rob <rmpsf...@gmail.com> wrote:
>
>
>
> > 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.
>
> I don't think you're taking point-of-view into consideration
> very well.
>
> Let me ask you: looking out my window, I see a lot of
> fog. I claim it is the kind of fog that is just going to burn
> off, and not the kind that will turn into rain. Do you agree?
>
> See the problem?
>

I see one problem. Your "analogy" is between a non-reproducible,
observable weather state that exists outside your window, and a
technology that can be reproduced on any SQL DBMS.

>
> I cannot disprove your "considerable analytic utility" claim.
> Neither can I confirm it.
>
> Maybe I could take a picture of the fog and send it to you.
> Maybe you could show some of this analytic utility in action.
> Then we might be on more solid footing with regards to
> each others claims.
>
> Marshall
>

According to Geoffrey A. Moore in Crossing the Chasm, the people who
will actually adopt a new technology (he uses the term to mean a
product) can be divided into Innovators, Early Adopters, The Early
Majority, The Late Majority and the Laggards. (The "chasm" of the book
title is between the Early Adopters and the Early Majority.) I would
not presume to categorize you Marshall, but you are certainly not
among the first two groups. I could spend time working up example
applications and spoonfeed them to you, but in the end, you'll say "I
could do that in SQL without your invention" or "I could write a
program to do that". And you would miss the point entirely: That the A-
L representation doesn't solve any problem you could not already
solve, it just makes it easier.

Here's a simple problem you can work out yourself: Suppose I have two
relationships between a pair of relations, R and S. One relationship
is represented using the PKFK data structure, the other using the JT
data structure. Are they identical?

Hints:
You can copy the PKFK relationship using the technique described here:

http://localhost/solopages/copypkfktoal.shtml

You can copy the JT relationship to A-L using the technique described
here:

http://localhost/solopages/copyjttoal.shtml

The webpage (shameless plug)

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

is full of detail about structure independence, richness/precision of
relationship representation and even performance. I'm sorry you cannot
find anything interesting there. I believe a better use of my energies
would be to prepare material for use by (Moore's) Innovators and Early
Adopters.

No offense is intended here. My resources a very limited. I have to
spend them where I can hope for the best return.

Rob

unread,

Jan 17, 2008, 1:34:12 PM1/17/08

to

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

>
> Second, I certainly don't think what you have observed is
> revolutionary and claiming it as "first new relationship to be
> discovered for 33 years" comes across as a bit silly to my ears. /
> However/, that is not to say there is not value in there somewhere, so
> please don't think I'm just doing you down...
>

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."

>
> I think you have in fact identified a common database design pattern,
> and awareness of it (though I dislike the nomenclature that you have
> conjured) is a very useful thing for database designers considering
> their schemas. And as such, I think you should continue to investigate
> database schemas, identifying other design patterns, and then collate
> them all together - that could be useful stuff and ultimately get you
> a lot more credit for it than any hand wavy stuff.
>
> If you don't agree fair enough, but that is my honest analysis. All
> best, Jim.
>

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

Marshall

unread,

Jan 17, 2008, 3:01:22 PM1/17/08

to

On Jan 17, 10:28 am, Rob <rmpsf...@gmail.com> wrote:
> On Jan 15, 1:54 pm, Marshall <marshall.spi...@gmail.com> wrote:
> > On Jan 15, 9:06 am, Rob <rmpsf...@gmail.com> wrote:
>
> > > 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.
>
> > I don't think you're taking point-of-view into consideration
> > very well.
>
> > Let me ask you: looking out my window, I see a lot of
> > fog. I claim it is the kind of fog that is just going to burn
> > off, and not the kind that will turn into rain. Do you agree?
>
> > See the problem?
>
> I see one problem. Your "analogy" is between a non-reproducible,
> observable weather state that exists outside your window, and a
> technology that can be reproduced on any SQL DBMS.

Way to completely miss the point, dude.

> > I cannot disprove your "considerable analytic utility" claim.
> > Neither can I confirm it.
>
> > Maybe I could take a picture of the fog and send it to you.
> > Maybe you could show some of this analytic utility in action.
> > Then we might be on more solid footing with regards to
> > each others claims.
>

Okay I have just totally lost patience with this. You have yet to
present even a single example, show a single benefit, give
even a hint of the supposed advantages you're claiming. You
have time to type in reams of crap from feel-good New Age
Business books, you have time to psychoanalyze my responses,
but then you turn around and hide behind "my time is precious"
and tell me to work it out myself. Apparently you have time for
everything except writing an example query.

I wouldn't presume to categorize you, Rob, but leading industry
pundit Alberto Biggerstaff, writing in Business 3.1 magazine,
(64 bit edition) says you're a pompous lackwit, the sort of person
who posts http links to localhost, ha, while complaining about
others' use of non-reproducible state. I say, with the utmost
respect, that in chapter 3 of The Innovator's Dilemma: The
Revolutionary Book that Will Change the Way You Do Business
(Collins Business Essentials edition) by Clayton M. Christensen,
it points out that someone who complains that their time is limited
so they can't write a single goddamn example query, but who
simultaneously posts reams of irrelevant claptrap, is the sort
of hypocrite that is probably destined for marketing greatness.

The conversation *starts* when you write a query under two
schemas, the usual one and one using your technique. Then
you ***show*** an actual benefit. No offense is intended here,
Rob, but quoting "Crossing the Chasm" repeatedly isn't having
a conversation; that's you being an asshole.

Marshall

PS. Once again I must give kudos to Bob Badour who
with uncanny accuracy summed up the whole thing
in only the second post of the thread.

Rob

unread,

Jan 17, 2008, 3:59:21 PM1/17/08

to

Ops:

On Jan 17, 11:28 am, Rob <rmpsf...@gmail.com> wrote:

> Here's a simple problem you can work out yourself: Suppose I have two
> relationships between a pair of relations, R and S. One relationship
> is represented using the PKFK data structure, the other using the JT
> data structure. Are they identical?
>
> Hints:
> You can copy the PKFK relationship using the technique described here:
>
> http://localhost/solopages/copypkfktoal.shtml
>

This should have been: http://www.sfdbs.com/solopages/copypkfktoal.shtml

>
> You can copy the JT relationship to A-L using the technique described
> here:
>
> http://localhost/solopages/copyjttoal.shtml
>

This should have been: http://www.sfdbs.com/solopages/copyjttoal.shtml

Thanks to Alberto Biggerstaff.

David Cressey

unread,

Jan 17, 2008, 4:09:05 PM1/17/08

to

"Marshall" <marshal...@gmail.com> wrote in message

news:504de8fd-536a-457c...@q39g2000hsf.googlegroups.com...

> > No offense is intended here. My resources a very limited. I have to

> > spend them where I can hope for the best return.
>
> Okay I have just totally lost patience with this.

I wouldn't presume to characterize either Rob or you Marshall, but I do
have the benefit of much prior discussion with you in this newsgroup, and
apparently Rob does not have the same benefit. Much of the tone of Rob's
communication does seem to be as if it were between a salesman and a
prospective client rather than between two colleagues discussing a technical
matter on a public newsgroup.

What I do want to take exception to is Rob's characterization of Diffusion
of Innovation as relating to a product rather than to an entire technology.
That may be true in the book "Crossing the Chasm", but it isn't true in the
original concept of DofI. DofI predates "Chasm" by several years. I was
first exposed to DofI and the five stages while still working at Digital.

Here's a link to a wikipedia article about the concept.

http://en.wikipedia.org/wiki/Diffusion_of_innovations

I believe that Rob's transformation of a technology oriented concept into a
product oriented concept is related to Rod particular intended use for his
valuable time. I certainly hope that Rob will feel motivated to spend less
of his valuable time writing posts to comp.databases.theory, even though
the return on investment might be quite high, over the long run.

Then again, in the long run, we are all dead, according to Keynes.

Marshall

unread,

Jan 17, 2008, 4:56:12 PM1/17/08

to

On Jan 17, 1:09 pm, "David Cressey" <cresse...@verizon.net> wrote:
> "Marshall" <marshall.spi...@gmail.com> wrote in message

>
> Here's a link to a wikipedia article about the concept.
>
> http://en.wikipedia.org/wiki/Diffusion_of_innovations

Interesting; thanks.

Reading that lead me to reading again about "disruptive technology."

Completely OT:

The future of entertainment is on my mind a lot lately. The
multiplexes are dying, and we have YouTube and NetFlix
and iTunes movie rentals. There is massive disintermediation
going on, but it hasn't really resulted in big changes in how
movies get made. Yet.

The big question in my mind is whether the current stranglehold
on distribution will be broken, and what that will mean. And
how will movie producers of tomorrow reach an audience?

Marshall

JOG

unread,

Jan 17, 2008, 8:24:17 PM1/17/08

to

On Jan 17, 6:34 pm, Rob <rmpsf...@gmail.com> wrote:
> On Jan 15, 6:03 pm, JOG <j...@cs.nott.ac.uk> wrote:

> > [snip]

> > Second, I certainly don't think what you have observed is
> > revolutionary and claiming it as "first new relationship to be
> > discovered for 33 years" comes across as a bit silly to my ears. /
> > However/, that is not to say there is not value in there somewhere, so
> > please don't think I'm just doing you down...
>
> If you are going to quote me, please be accurate. I have never used
> the word "revolutionary".

Who said you had? It was I who stated that what you have produced
isn't revolutionary, and simply a schema pattern that has no doubt
been noted in the past. Renaming intersection tables as "aggregates"
and propositions with weak entities as "links" does not a ground-
breaking idea make.

> 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."

As a native english speaker, I find that sentence pretty obtuse, if
not unintelligible, and I'm afraid that's representative of most of
your "fasttrack" page. I was hoping you would take my comments
constructively, but nope, head down and full steam ahead eh! And best
of luck to you.

> [snip]

> > If you don't agree fair enough, but that is my honest analysis. All
> > best, Jim.
>
> 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>

I'm pretttty sure Codd was referring to differentiations between
logical and physical layers, and not in fact distinguishing between
propositions and fluffy pink elephants doing somersaults on the moon.

Yes, lets ;) After reading the rest of your post, I am starting to
wonder if I in fact have some bizarre form of dsylexia, that occludes
important words at crucial points in sentences, but yet is _only_
activated by posts on google groups.

Does anyone else suffer from this strange affliction?

>
> Rob