Re: Something new for the New Year (2008).

From: JOG <jog_at_cs.nott.ac.uk>
Date: Thu, 17 Jan 2008 17:24:17 -0800 (PST)
Message-ID: <7476a4fe-89e0-4b3f-86fe-b7f84dff75e9_at_k39g2000hsf.googlegroups.com>


On Jan 17, 6:34 pm, Rob <rmpsf..._at_gmail.com> wrote:
> On Jan 15, 6:03 pm, JOG <j..._at_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 groundbreaking  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.

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

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
Received on Fri Jan 18 2008 - 02:24:17 CET

Original text of this message