Note: "Then & Now" (t&n) is a new version of what used to be the "Oldies but Goodies" (obg) series. To demonstrate the superiority of a sound theoretical foundation relative to the industry's fad-driven "cookbook" practices, as well as the evolution/progress of RDM, I am re-visiting my 2000-06 debunkings, bringing them up to my with my knowledge and understanding of today. This will enable you to judge how well my arguments have held up and appreciate the increasing gap between scientific progress and the industry’s stagnation, if not outright regress.
This is a re-published series of several DBDebunk 2001 exchanges on Simon Wlliams' so-called "Associative Model of Data" (AMD), academic claims of its superiority over RDM ("The Associative Data Model Versus the Relational model") and predictions of the demise of the latter ("The decline and eventual demise of the Relational Model of Data").
Part 1 was the email exchange among myself (FP), Chris Date (CJD) and Lee Fesperman (LF) in reaction to Simon Williams' claims that started the series. Part 2 is my response to a reader's email questioning our dismissal of Williams's claims. (The reader's comments are in quotes.)
------------------------------------------------------------------------------------------------------------------
SUPPORT THIS SITE
DBDebunk was maintained and kept free with the proceeds from my @AllAnalitics
column. The site was discontinued in 2018. The content here is not available
anywhere else, so if you deem it useful, particularly if you are a regular
reader, please help upkeep it by purchasing publications, or donating. On-site
seminars and consulting are available.Thank you.
LATEST POSTS
10/08 NOBODY UNDERSTANDS NORMALIZATION 1 (sms)
09/17 NEW "DATA MODELS" PART 1 (t&n)
09/12 DATABASE DESIGN: THE STATE OF KNOWLEDGE IN THE INDUSTRY
UPDATES
08/20 Added Logic and databases course to LINKS page.
LATEST PUBLICATIONS
(order from PAPERS and
BOOKS pages)
- 08/19 Logical
Symmetric Access, Data Sub-language, Kinds of Relations, Database Redundancy
and Consistency, paper #2 in the new UNDERSTANDING THE REAL RDM series.
- 02/18 The Key to Relational Keys: A New Understanding, a new edition
of paper #4 in the PRACTICAL DATABASE FOUNDATIONS series.
- 04/17 Interpretation and Representation of Database Relations, paper
#1 in the new UNDERSTANDING THE REAL RDM series.
- 10/16 THE DBDEBUNK GUIDE TO MISCONCEPTIONS ABOUT DATA FUNDAMENTALS, my
latest book (reviewed by Craig Mullins, Todd Everett, Toon Koppelaars, Davide
Mauri).
USING THIS SITE
- To work around Blogger limitations, the labels are mostly abbreviations or
acronyms of the terms listed on the FUNDAMENTALS page.
For detailed instructions on how to understand and use the labels in
conjunction with that page, see the ABOUT page.
The 2017 and 2016 posts, including earlier posts rewritten in 2017 were
relabeled accordingly. As other older posts are rewritten, they will also be
relabeled. For all other older posts use Blogger search.
- The links to my AllAnalytics columns no longer work. I re-published only the
2017 columns @dbdebunk, and within them links to sources external to
AllAnalytics may or may not work.
I deleted my Facebook account. You can follow me @DBDdebunk on Twitter: will link to new posts to this site, as well as To Laugh or Cry? and What's Wrong with This Picture? posts, and my exchanges on LinkedIn.
------------------------------------------------------------------------------------------------------------------
Then: ON THE SO-CALLED "ASSOCIATIVE MODEL OF DATA"
(originally published 08/25/2001)
“To whom it may concern (hopefully Fabian). I sent a question out on the newsgroups after you pointed me towards the "article" here on AMD. As I have not received a response, I target it here. Whether or not AMD is practicable and even delivers on half of its promises, the point is you slated it without reading the guy's book as such. You were coming from a position of pure ignorance. If you take the time to read the book, I would appreciate your comments on it from a relational side (I have my own but...).I do not participate in newsgroups. Lee Fesperman occasionally sends me some stuff that he deems pertinent to my interests and I occasionally respond thru him. I only received one email from him on AMD -- don't recall if it referred to your comments -- and I have not decided whether it's worth responding yet. If I do respond, it'll be on this website.
As for the circle/ellipse article, I'm not surprised that Dr. Sroustrup had problems with it. I had assumed Chris Date to be a learned man, yet he makes two fundamental errors with this article, these stopped me reading less than half the way through. As a quick point, a class is a programming level realization of a type. If in oo you specify the classification type and some of its properties, this could be modeled in any number of ways in any number of languages (of course also non-oops). A class in most oops refers to the code itself that is a template for instantiation of behavior. (As a follow on an object is most often an instantiation of a class, oop language terms vary of course).
1) In basing your criticism on the C++ paragraph, you miss the context. This is talking about implementation issues not about pure theory. Yes, people recognize that circles are special kinds of ellipses, the point is within a programming context how do you model this, not whether outside of this context it is correct.
The issue with invariants is the major problem with such generalizations. The comments on the main key aspect of circles for most programs were ridiculous and appeared nothing more than "I'm bored, who can I troll today". Not something I expected from someone at the forefront of their technical area. The point is that if a program is relying on these invariants with a circle, but uses the ellipse class' interface, its behavior may vary. As such, it would end up checking for the type of the object before expecting behavior, which is against the point of polymorphism in the first place (look up LSP). So you may use inheritance just to provide implementation inheritance. Depending on your applications needs, however, the invariants for a circle may be violated if you operate through an ellipse.
2) This notion of variables and values is outside of OOP concerns. Bear in mind that if your OOP uses class semantics, it is the class itself that governs behavior, not the "data" that may or may not be underneath it (i.e. it may be in other classes and this class assembles behavioral abstractions against them). My point is that after taking things out of context, the paragraph is then twisted beyond what it really means. An example (excuse bad copy and pasting):
"If those focal points coincide, the ellipse looks like a circle, but it is not a circle because its operations do not preserve the circle invariant.
Allow me to expand, rephrase, and -- with respect -- correct this sentence "If the focal points of an ellipse value coincide, then that ellipse value is a circle value. If an ellipse variable contains such an ellipse value, then in fact it contains a circle value. However, that variable can of course be updated. If, after such an update, the focal points of the ellipse value that is now the current value in that ellipse variable don't coincide, then the ellipse variable now contains an ellipse value that isn't a circle value. On the other hand, if, after such an update, the focal points of the value that is now the current value in that ellipse variable do coincide, then the ellipse variable now contains an ellipse value that is a circle value."
Aside from obviously taking liberties (it, with respect, doesn't really cut it), this is not "correcting" the statement. It was fine to begin with. If you take it out of an implementation context then yes this may be true. Further, the main point of this, again, is that the paragraph is concerned with LSP and invariants. I can't believe that Chris Date doesn't know what an invariant is, nor a class invariant. This again only leaves the article as a trolling.
I've only looked at this site for a week since Fabian's reply to me (as, unlike him, I followed up on reading before I commented). I have to say its content seems like dogma, doctrine and zealotry. Like all good dogma, is based on truths, but spun out to its own ends. If the very point of the site is to be a station for dogma, then I apologize for wasting your time. If not, why post such unbalanced articles?”
Please reread the exchange I posted titled "Respected technical analysts" [see Part 1]. I do not need to read his book to know that it's a waste of time -- there is enough information on some of the stuff published on Williams's site and in his public pronouncements that demonstrates very clearly that he understands neither the relational model, nor what a data model is (both Chris and I tried to read his material and dropped it very quickly; as Chris said, "life is too short".) I also issued a challenge for Williams to DEFINE a data model and then show how his AMD satisfies that definition. I am still waiting. The point is it's Williams who is ignorant, not I. And the fact that he quotes Butler and Bloor, who are equally ignorant, is also telling.
I don't want to get into an OOP discussion, because OO thinking is fuzzy and not grounded in theory; [at best it is a programming, not data management paradigm, and for critical reasons Codd explicitly kept the two distinct]. I find it neither interesting, nor productive. Most OO proponents are programmers who know very little about database management and see a DBMS as just another application program. That is why ODBMSs are not DBMSs, but essentially DBMS-building kits. There is no formally defined "OO data model", let alone one soundly grounded in theory. The rest is commentary. I will pass your comments to Chris Date and let him respond if he chooses to. If he does respond, I will post it on this site. [Ed. Note: Chris Date has decided not to respond.]
Sorry, but you got it backwards: the dogma, bigotry and zealotry are in the OO court. We have thousands of years old science behind us -- predicate logic and simple set theory. What exactly does OO have?
Reading is only part of the equation. It requires understanding and appreciation too.
“I wouldn't bother forming a response as you've already given it here. That's cool for me. I just wanted to know. I read it twice before, I wondered if I missed something the first time round.Claims such as Williams's seem interesting only to somebody who does not know and/or understand what a data model and the relational data model are.
As I say I had problems with Williams's book. The claims he made provided sufficient interest for me to see how he could justify them, hence my interest in a more informed review. Again, mostly to see if I missed something.
I can understand it if you simply have way too much to do, fair enough. As I posted, I'm not really interested in justifying/supporting his work, merely in assessing its worth to me personally. There was some worth in there, unfortunately it spent more time criticizing other systems then explaining his system.
A shame. However from what I understood of the work, it is likely impossible to do, given that its more a web of attributes than a set of relations between tuples.
Based on your responses I can see why you form the opinion. As I said I read your review twice to see if there was something I was missing. I also find the "rdbms' can't handle multimedia" etc quite bizarre as even a flat file can handle them, it only depends on the app.
Fair enough. I personally was not looking for one anyway.
That seems a very sweeping set of statements. oo is not oodbms. I, for one, have been ooing for 7 odd years and never used an oodbms nor wanted to. Couldn't see the utility of it. However to generalize like that is what I was talking about on your site.
Again I'm not particularly fussed if you do. I just don't like to see unbalanced articles that slate something unnecessarily.
That's assuming we need to have that. I find it very helpful in the general sense. I've done lots of procedural, lots of sp's etc. I keep coming back to oo as I find it expressive. Would I use this as a paradigm for db access? No but it was never aimed to be that. [Ed. Note: I have no opinion on OO for programming/application development. My only interest and criticism are explicitly from a purely database management perspective.]
Again, being backed in truth does not make something un-dogmatic. Obviously you seem not to see why your site shows this. Fine, it is after all your site.
Yet you choose not to even try any of that regarding AMD. A shame, regardless of your views following reading it.”
It is not clear what that worth is, but my dismissal of any work by Williams is certainly validated.
This is exactly why I claimed Williams does not know what a data model is, and that what he proposes is nonsense. This alone disqualifies his claims.
Well, that piece makes it pretty clear where the ignorance lies and why. If Williams just wants to sell a product, which I quickly -- and, obviously, correctly -- discerned from his pronouncements, he should do it on merit, not as a replacement of the "relational model", which he makes clear he does not understand. Claims of simple set theory expressible in first order predicate logic of which he seems unaware, let alone understands, does not motivate to read his book.
The objective of my work is a bit more than your narrow perspective. To criticize something you first need to know and understand it. He does not.
I thought you deem my work dogma and bigotry. Anyway, I did not review his "model", [because there isn't one -- that's why I asked for his definition thereof]. I only criticized his ignorance of fundamentals and some of his public comments on the relational model.
The real issue is what is meant by "handling". That's where the fuzzy OO thinking pops its ugly head. I suggest you read Chapter 1 in my book -- it tackles the issue of complex types.
Is Sroustrup more learned than Date, you think?
I am very careful with my statements and when I make a sweeping one, it's not casually. I stand behind that statement. Note that it says "most", which means that there are exceptions. But that's exactly what they are -- exceptions. I stated the rule [with which they should not be confused].
You have yet to demonstrate anything was "unbalanced". Let's see if Chris thinks different. Do you deem Williams's stuff "balanced"? Did you write him to criticize his ill-informed arguments?
That's a very strange argument. If database management is not backed in truth, then what the hell is it backed in????? And if truth and science are dogma, then what do we call dogma?
Of course I do. If somebody makes ignorant and stupid arguments, which are so incoherent that it's impossible to rebut coherently, why should I try? I used to read a lot of stuff, (e.g. by Celko and Inmon and other "luminaries") and I've learned to ignore all that. It's not arbitrary, but informed choice. What is a shame is what all those people publish, not that I do not read them. You are riding the wrong logic (that is, you are not backed in truth).
“Get you now. Given that, I can see your reluctance to read further.Which, by the way, is not, in principle, different than your reluctance to continue reading Date, ain't it? I say in principle, because there is a non-trivial difference between Date's knowledge of OO and Williams' knowledge of RDM.
I'm not sure he does not "understand", what I believe is that his understanding is somewhat warped. He's looking for a solution to a problem that doesn't really exist. I've not spent that much time sorting out the impedance mismatch between OO and relational theory/implementations, so it's difficult for me to see the basis for his work/product.
That presupposes however that forming data models is the only way to do things. It may be that his system has applications, which can benefit from its loose fit approach. I do think, however, he oversells this.
As I said, the best dogma is based in truth. There is much truth to what you publish, the style of authoritarianism is what I object to. I may well do so, I'm always interested in furthering my ability to develop. Whatever can help me, I'll learn.
That's not for me to decide. I disliked the approach and content of that article for its poor foundations. I am sure there are dodgy pieces of work from Sroustrup. However, I don't try to read much of his work anyway. My ideal for content vs. commentary is Dr Doug Schmidt's old site on corba etc, where the style of information presentation is balanced.
Is it your personal experience that yields this rule for you, or that of others? I ask for interest's sake, a work-mate asked me earlier of oo programmers whether many in my opinion only used oo syntax and objects as structures with functions, rather than using its more useful features. In my experience, most oo programmers claiming to do oo know very little about it (usually down to poor education/urge to self-education). Again, I'm not particularly fussed if you do. I just don't like to see unbalanced articles that slate something unnecessarily.
I have to admit I never got round to it. I did keep notes on it however. If you'd like, I'm happy to submit them to you for your site. They are complete with page number references. The book was definitely not balanced though. It was also slightly badly written, preferring marketing to useful information. Maybe the only real aim for giving it away. If I had bought it I'd have been quite disappointed, as I read it for detailed information of his model/technique and came away with little of it. [Ed. Note: See what I mean? I am criticized for knowing enough to not waste my time on this; is this what I am supposed to be "balanced" about?]
I didn't say database management was dogmatic. I said the site was. IMO, if a database management expert preached that his system was the only way, as it works, then I'd find that dogmatic. [Ed. Note: Curiously, Williams preaches his own system is the best and is dogmatic about it without any basis, but this escapes CT].
As I said, it may be that you've read enough not to be interested in reading anything that contains much of the above. I've only seriously been on the endless journey to perfection for a year or so. I've only consumed around 40 odd books on development and a hundred or so articles. I'm still hungry, maybe you've read enough to feel happy about your current level of knowledge. If so, I'm not about to tell you that you haven't. I would hope however that, if you run a site as such, you would want to know more about other avenues. [Ed. Note: CT's own assessment of Williams' book makes it quite obvious that I do know--enough not to bother with them!]
I agree that it's a shame they can't publish something worthwhile, but on some of the postings to your site aren't you guilty of the same thing? I use worthwhile on purpose, as I don't believe either all in at least Williams book is rubbish (neither your site), there is worth in both. It's just down to sifting out what seems/is useful. I realize that you have probably got better things to do than indulge in this dialogue but I thank you for your time/responses.”
We have to agree to disagree. Williams does not understand, period. And I don't recommend spending time on impedance mismatch nonsense that is itself based on ignorance.
My guess is that your data model concept is different than what the relational model is. I suggest you read Date's "Models, Models Everywhere, Nor Any Time to Think".
So catholicism, or any other religion is based on truth? How about soviet "communism"? Are they in the same category with predicate logic and set theory?
Which is another exception to the rule.
We're not into politics here -- the notion that everything must be "balanced" is nonsense. There seems to be an American notion that everything is just a matter of opinion, between which one can choose at will, based on personal preferences. Knowledge, evidence and reason play no part. Under this notion of balance, for example, claims about the holocaust by survivors are "unbalanced" without the counter-argument by deniers.
That may well be true and consistent with the way industry and business work -- which produces practitioners like that -- but it does not negate that OO has serious fundamental problems and is simply not a data management paradigm.
So you get around to criticize something that is balanced as not balanced, but not something that is not balanced. Strange, wouldn't you say? You go out of your way to find some usefulness in Williams's nonsense, but you stop reading Date because he is "not balanced". What can I say?
Don't try to squeeze out of this one that easy.
Another strange statement. First, I don't have nothing to "preach". 2nd, to accept that a system is "not the only way", I have to compare it to other systems that do at least what it does, or more/better. Come up with that [formally defined] system and I'll accept it. Without that you're grinding water. To repeat: your notion of dogma is incorrect.
Good for you, but until you spend 15 years plus in the field, I recommend to be a little more modest with arguments backed up by knowledge and reason.
If you don't see the difference, I'm afraid I can't help you. Read some more.
Ditto.
And Now
My response stands perfectly as is -- nothing to add.
No comments:
Post a Comment