tag:blogger.com,1999:blog-6411920579549337139.post8075022053198867617..comments2023-12-31T05:26:17.608-08:00Comments on DATABASE DEBUNKINGS: The Principle of Orthogonal Database Design Part IIFabian Pascalhttp://www.blogger.com/profile/01346669716885494092noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-6411920579549337139.post-82238474428262238112016-11-12T15:11:55.974-08:002016-11-12T15:11:55.974-08:00And your point is? That systems not fomally define...And your point is? That systems not fomally defined are better, or at least as reliable as formal ones?<br /><br />One of the points of a well-designed formal system is limit as much as possible "blind and stupid interaction" without affecting the meaningful functionality.Fabian Pascalhttps://www.blogger.com/profile/01346669716885494092noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-82598299913108228872016-11-12T14:52:26.691-08:002016-11-12T14:52:26.691-08:00hmm... all attempts at defining formal systems are...hmm... all attempts at defining formal systems are doomed to be incomplete. Doesn't mean we try to define all the rules and boundaries, etc., but it doesn't take too many user interactions in said system for holes, inconsistencies and outright breaks in said system can get found out by simply blind and stupid user interaction.<br /><br />"you're not holding it right"...coremansterhttps://www.blogger.com/profile/10473679664419498704noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-4730015788698237582016-11-10T14:20:20.638-08:002016-11-10T14:20:20.638-08:00I suggest you re-read the article because you appa...I suggest you re-read the article because you apparently did not understand it. See also my last reply to Erwin. <br /><br />As to how to handle updates of relational databases given that SET THEORY HAS NO CONCEPT OF VARIABLES (whether you like it or not), you'll have to have patience for David's book. That work is much more profound and difficult than what passes for relational theory these days. What I am offering is just some basic ideas here and there that will be fully developed in the book.<br /><br />In the meantime, why don't you refresh your knowledge -- assuming you have some -- of set theory and predicate logic, to verify that my claim is correct.<br /><br />That you dk or understand something does not mean it does not hold.<br /><br />FYI: Principle of axiomatic independence is basic in axiomatic theory, of which set theory is one. Designing independent base relations such the facts they represent are not derivable is a clear design principle and it was even alluded to by Codd's first 1969 paper when he discussed weak and strong redundancy. I suggest you re-read that too.<br /><br />SO please, we're not gonna spoon-feed you on fundamentals -- go educate yourself and spare me.Fabian Pascalhttps://www.blogger.com/profile/01346669716885494092noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-65814710847134945222016-11-10T12:57:48.390-08:002016-11-10T12:57:48.390-08:00No I'm not asking for syntax. But you have esc...No I'm not asking for syntax. But you have eschewed relvar (names) and attribute names as a means to express updates. We can't express tuple content as merely a bunch of values, because a given tuple type might have more than one String attribute or more than one Int, etc.<br /><br />Both you [Pascal] and McGoveran expend considerable verbiage telling us what update is <i>not</i>. I've seen nothing saying what it is. Not in enough detail to design a database that is updatable (orthogonally or otherwise).<br /><br />I have by now (after a long time of waiting) come to the conclusion the reason so little is forthcoming is because the quest for POOD is like trying to square the circle.Anonymoushttps://www.blogger.com/profile/07650838248924415585noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-26243338956479671612016-11-09T15:15:36.106-08:002016-11-09T15:15:36.106-08:00I hope you are not asking for syntax -- we are not...I hope you are not asking for syntax -- we are not designing a data language. We are talking formulation of constraints such that the set of values that comprise a candidate tuple will satisfy only one RP (conjunction of constraints). Then the name is just a reference to the RP and if there is only one that is satisfied, then using the wrong name won't insert the tuple in the wrong relation. Duplicate RPs can't prevent it.<br /><br />Orthogonality is a design discipline, same as full normalization (excepting normalization to 1NF which can be enforced), as I explained in a previous article.<br /><br />I also mentioned a McGoveran (unproven) conjecture that the POFN implies the other 3 principles, not the other way around.<br /><br /><br /><br /><br /><br />The semanticsFabian Pascalhttps://www.blogger.com/profile/01346669716885494092noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-22686342718867040502016-11-09T14:05:57.075-08:002016-11-09T14:05:57.075-08:00Toon's : https://nocoug.files.wordpress.com/20...Toon's : https://nocoug.files.wordpress.com/2014/08/nocoug_journal_201308.pdf<br /><br />Mine : https://nocoug.files.wordpress.com/2014/08/nocoug_journal_201311.pdfErwin Smouthttps://www.blogger.com/profile/17463579744642559811noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-34439294529651299912016-11-09T14:01:54.968-08:002016-11-09T14:01:54.968-08:00Because I still have no idea what alternatives are...Because I still have no idea what alternatives are available in your proposed data language for identifying the target relation(s) of a given update.<br /><br />Or rather, because I have no idea how "adherence to the POOD" can be enforced unless by relying on ... attribute names.Erwin Smouthttps://www.blogger.com/profile/17463579744642559811noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-29599969793788043022016-11-09T10:44:55.516-08:002016-11-09T10:44:55.516-08:00Are they online? If so, can you provide the links?...Are they online? If so, can you provide the links?Fabian Pascalhttps://www.blogger.com/profile/01346669716885494092noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-62592653272337078532016-11-09T10:44:11.159-08:002016-11-09T10:44:11.159-08:00Insofar as a tuple insertion is concerned, name un...Insofar as a tuple insertion is concerned, name uniqueness ***means nothing*** to the DBMS -- it's just 2 distinct names x,y. Uniqueness of RP (conjunction of constraints on relation), OTOH, makes a single relation the recipient of the tuple without the DBMS having to understand meaning -- it "just computes" (somebody used this term).Fabian Pascalhttps://www.blogger.com/profile/01346669716885494092noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-39920159120397973952016-11-09T10:38:36.991-08:002016-11-09T10:38:36.991-08:00Then why do you insist that decisions should be ba...Then why do you insist that decisions should be based on names such that users must "help the DBMS" when adherence to the POOD would obviate the need for such help?<br /><br />Fabian Pascalhttps://www.blogger.com/profile/01346669716885494092noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-14546279450259861512016-11-09T10:33:36.424-08:002016-11-09T10:33:36.424-08:00Absolutely. Which is why update decisions should n...Absolutely. Which is why update decisions should not be made based on attribute names either. Names are only references to the integrity constraints. An attribute name is a reference to the attribute constraint.<br /><br />Fabian Pascalhttps://www.blogger.com/profile/01346669716885494092noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-37833403561920943392016-11-09T10:29:55.744-08:002016-11-09T10:29:55.744-08:00I was as ironic as you were. Note my comment in th...I was as ironic as you were. Note my comment in the article "I am not worried about Erwin". As to pondering, it's up to you.<br /><br />As you will see, a true RDBMS according to our RDM interpretation should document semantics and provide it on demand to users. However, this does not mean that reliance on the DBMS should not preferred to human intervention, as you say you agree.Fabian Pascalhttps://www.blogger.com/profile/01346669716885494092noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-7189137071991036792016-11-09T05:26:19.328-08:002016-11-09T05:26:19.328-08:00"Of course, declarative constraints are only ..."Of course, declarative constraints are only as good as how efficient CPU-wise and concurrency-wise the underlying implementation code that actually validates the constraint during transactions is, which should be the purview of the DBMS designer. This is why the real solution are shorthands like the ones for key and referential constraints, which are more reliable and relieve developers from the drudgery. They would also help vendors: they can develop shorthand-specific validation code, which is much easier to do than accept developer formulated ASSERTIONs, parse and deep-analyze them."<br /><br />In this context, maybe I should once more point to my article in the NOCOUG journal on this very subject (NOV 2013 issue). And the one by Toon published in the preceding issue (AUG 2013) to which mine was a response.Erwin Smouthttps://www.blogger.com/profile/17463579744642559811noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-66989335807340245682016-11-09T05:18:56.476-08:002016-11-09T05:18:56.476-08:00"In order for this to work, however, every RP..."In order for this to work, however, every RP must be unique -- another way of saying that the database design adheres to the POOD. Erwin's claim -- assumed by many -- is that RPs are unique even if only relation (and attribute) names are distinct".<br /><br />I have no idea what could possibly be meant by "every RP must be unique". Perhaps this problem could be resolved once and for all if you could exemplify two RP's that are "not unique".<br /><br />If relvar/relation names are used as the identifier for all update and query operations, then uniqueness is indeed guaranteed by virtue of the name having to be able to act as the identifier. I don't see the problem. (You could theoretically have two distinct relvars/relations/tables in a db, or in distinct db's, representing the very same business meaning. That is more a cultural/organizational problem than it is one that is intrinsic to RM, imo.)Erwin Smouthttps://www.blogger.com/profile/17463579744642559811noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-83997961245902782112016-11-09T04:57:29.051-08:002016-11-09T04:57:29.051-08:00"However, the meaning -- captured by the busi..."However, the meaning -- captured by the business rules -- is represented in the database by the formal relation predicate (RP) -- a set of integrity constraints that the DBMS can enforce -- which is the criterion that the DBMS uses to decide whether the tuple belongs in the relation or not. And we should rely as much as possible on the DBMS, not the user, to make that decision."<br /><br />If this is your way of saying that all applicable constraints should be definable to the DBMS in such a way that the DBMS, and the DBMS alone, will be able to derive/determine how to actually enforce them, and effectively do that, I agree wholeheartedly, and I'm aware of LOTS of participants on various db discussion fora who feel EXACTLY the same.<br /><br />That all those people, when using SQL, have no other option than to hand-code lots of enforcement strategies (in SPROCS, in the business app itself, wherever) is not their fault. Ref. the remark you quoted from Toon&Lex book.Erwin Smouthttps://www.blogger.com/profile/17463579744642559811noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-7814469414653272972016-11-09T04:43:39.430-08:002016-11-09T04:43:39.430-08:00(I'm going over this finish to start this time...(I'm going over this finish to start this time)<br /><br />"any error in the name specification will result in the tuple being inserted in the wrong relation. But if the design adheres to the POOD the DBMS can decide on its own, based on which RP the tuple satisfies,"<br /><br />If a user can make a mistake when trying to pick the right relvar/relation name, he can also make a mistake when trying to pick the right attribute name. The effect stays just the same.Erwin Smouthttps://www.blogger.com/profile/17463579744642559811noreply@blogger.comtag:blogger.com,1999:blog-6411920579549337139.post-6664484862964142942016-11-09T03:39:27.071-08:002016-11-09T03:39:27.071-08:00Maybe that's just semantics and I'm not ve...Maybe that's just semantics and I'm not very good at those.<br /><br />That was in reply to someone not making the imo proper distinction between an application programmer and a db designer, claiming the db designer "is also a programmer, namely of what the DBMS is to do". And it was mostly ironical.<br /><br />"My DBMS is sufficiently expressive, thank you."<br /><br />That was in reply to a remark that if one's DBMS cannot express the predicates, one should switch DBMS. My DBMS has structural built-in support for expressing all relevant predicates. That is, it has support for keeping a record of what the precise business meaning is of the tuples recorded in [a relvar in] the db. And it has support for expressing (AND enforcing !!!) all applicable constraints. That which Toon in his book claimed no one knew how to do.<br /><br />In that light, I don't feel I have any pondering to do let alone any revisiting and what I said remains what I said.<br /><br />Also in that light, and regarding<br /><br />"What happens when users are not sophisticated enough to "read the mind" of the designer and have either incompatible interpretations or -- just as common -- interpretations that vary by day, mood, focus, etc.? What if two applications have incompatible interpretations?"<br /><br />With my DBMS, users are not required to read any designer's mind, they only need to query the catalog. The risk of "Incompatible interpretations" can never be entirely eliminated when the predicate is expressed in NL (typical for external predicates defining business meaning) but can indeed be eliminated if the predicate is expressed as a mathematical formula (typical for definitions of constraints), which in my DBMS it is.Erwin Smouthttps://www.blogger.com/profile/17463579744642559811noreply@blogger.com