Tuple visibility through a view
[quote] The "file system language" you're talking about here is Tutorial D. The example I gave in post #20 is written in Tutorial D, and as far as I can tell both the language and my example are entirely faithful to TTM. Are you claiming Tutorial D is a "file system language" that is a "regression to pre-Codd times"?
Is Tutorial D a "Sub-Relational Advanced File System"?
Or are you suggesting that TTM itself is arguing for a "regression to pre-Codd times"?
You wrote that "in a relational system most values are calculated by the system".
That's ultimately not true. Certainly it's true that in any given information system, many values come from systems that come from systems that come from systems -- and produce results that go to other systems -- but the ultimate input comes from human data entry. ...
[end quote]
Yes, yes and yes to the three questions. (Tutorial D being a language that depends on relvar variables, implies a non-relational dbms.) You are talking about adhoc physical systems based on familiar practices but are not logical, don't guarantee logical validity and therefore leave confidence in database consistency up to human consistency. Automation is all about avoiding the effects of natural human inconsistencies.
You are confused by the many trees in your forest. A relational system being based on logic produces values that are based on logic. It is logically fundamental that P->P. If P1 and P2 are different ways of expressing the same user meaning, then P1->P2 applies.
There is no logical significance to your relvars, to a logical system they don't even signify physical organization, of which there are many arrangements for your Invoices scenarios.
The logical significance lies not in the relvar keyword but in the modifiers you use. The only significance of the 'real' keyword is that it can be used to apply a dbms policy that certain relations are to be treated as premises or axioms by all logical arguments, for example such a policy makes P1->P2 a premise for all dbms arguments. This is a requirement of data independence.
'base' is a more accurate modifier for describing premises or axioms.
[quote] Re my quip that "junior programmers ... generally get it right", I meant only that my scenario is so simple, easy-to-understand, and generally trivial that junior programmers do get it right. In other words, they implement working and workable billing systems. My company implemented dozens of them in the 1980's and 1990's. Some of them are still in use today. [end quote]
You have a strange idea of "simple". Rather than the juniors needing to know about real relvars, it is far simpler to tell them to delete a certain invoice from the Invoices join view. Less chance for error and less they need to know.
You can even tell them to delete a certain product from the same view which amounts to saying a certain projection is empty. You can even tell a user to press a button as you have said. Implementing the button is fine work for your juniors who still don't need to know about the real relvars.
Deleting from the join view doesn't necessarily mean that the dbms must eliminate all mention of a given invoice number elsewhere in the database, that's a matter of data design, not programming manoeuvers.
Quote from p c on October 20, 2019, 11:54 am"What Codd said about relations being "joinable" applies exclusively to what we know today as relation ***values***. Read Codd and if you don't see it, repeat until you do. ..."
"...Which is the very reason why logic (/basic set theory) alone just isn't enough to build data manipulation languages on."
Not exactly, what you mean is your data manipulation sub language.
And a sublanguage is not a language ? Like subsets are sets ?
[quote]
I'm not clear what your truth table has to do with anything, let alone the current discussion and my Tutorial D example in post #20.
Perhaps you could clarify? [end quote]
If it's not clear then either you don't know relational basics or choose to ignore them.
A truth table is a logical argument that tells you under what conditions something is considered true.
This particular one proves that there are two conditions for Not(A And B) to imply Not A And Not B when it's noted in the form of a premise aka condition that a join may not represent all subsets of relations A and B. In terms of deletion there are only two logical possibilities, not the three that the usual misapplication of de Morgan's tautology here suggests.
Only one of the two logical possibilities applies to most join deletions because one of them, line 11 as I recall, involves empty A and B relations. All this means is that logically you can delete an empty join from itself. If you really thought it necessary, you could write a much wider truth table to add the premise that the union/disjunction of both possibilities is reflected by a logically valid argument.
Quote from p c on October 20, 2019, 11:54 amThe 'real' variables aka relvars Dave's scenarios declare are actually an insidious way to pretend that some unstated logical structure applies even though at the same time he does not see how a logical non-ambiguity argument applies.
Are you saying that all those idiots using their variables are, by their "pretending", deluding the world/their users into believing that there is some logic underneath their variables or are you saying that a variable is isomorphic to some "unstated logical structure" and that the "pretending" is in calling it a variable ?
Oh yes, and if you think that some "logical non-ambiguity argument" is relevant to the discussion, the mature grown-up thing to do over here is ***EXPLAIN WHAT THAT ARGUMENT IS***.
Quote from Erwin on October 20, 2019, 3:12 pmQuote from p c on October 20, 2019, 11:54 am"What Codd said about relations being "joinable" applies exclusively to what we know today as relation ***values***. Read Codd and if you don't see it, repeat until you do. ..."
"...Which is the very reason why logic (/basic set theory) alone just isn't enough to build data manipulation languages on."
Not exactly, what you mean is your data manipulation sub language.
And a sublanguage is not a language ? Like subsets are sets ?
It appears that all of your language is non-relational.
Quote from Erwin on October 20, 2019, 3:27 pmQuote from p c on October 20, 2019, 11:54 amThe 'real' variables aka relvars Dave's scenarios declare are actually an insidious way to pretend that some unstated logical structure applies even though at the same time he does not see how a logical non-ambiguity argument applies.
Are you saying that all those idiots using their variables are, by their "pretending", deluding the world/their users into believing that there is some logic underneath their variables or are you saying that a variable is isomorphic to some "unstated logical structure" and that the "pretending" is in calling it a variable ?
Oh yes, and if you think that some "logical non-ambiguity argument" is relevant to the discussion, the mature grown-up thing to do over here is ***EXPLAIN WHAT THAT ARGUMENT IS***.
I did, several times. No need to shout, just think harder about your assumptions.
Quote from p c on October 20, 2019, 3:37 pmQuote from Erwin on October 20, 2019, 3:12 pmQuote from p c on October 20, 2019, 11:54 am"What Codd said about relations being "joinable" applies exclusively to what we know today as relation ***values***. Read Codd and if you don't see it, repeat until you do. ..."
"...Which is the very reason why logic (/basic set theory) alone just isn't enough to build data manipulation languages on."
Not exactly, what you mean is your data manipulation sub language.
And a sublanguage is not a language ? Like subsets are sets ?
It appears that all of your language is non-relational.
That's not an answer to the question asked. You might try do to so, even if it would be the very first time in your life you do that.
[quote] That's not an answer to the question asked. You might try do to so, even if it would be the very first time in your life you do that. [end quote]
Okay, your sublanguage is not a subset of a logical language. A bonus(!) second answer is that your language does not have a logically complete sublanguage (which implies the first answer).
Quote from p c on October 20, 2019, 3:39 pmQuote from Erwin on October 20, 2019, 3:27 pmQuote from p c on October 20, 2019, 11:54 amThe 'real' variables aka relvars Dave's scenarios declare are actually an insidious way to pretend that some unstated logical structure applies even though at the same time he does not see how a logical non-ambiguity argument applies.
Are you saying that all those idiots using their variables are, by their "pretending", deluding the world/their users into believing that there is some logic underneath their variables or are you saying that a variable is isomorphic to some "unstated logical structure" and that the "pretending" is in calling it a variable ?
Oh yes, and if you think that some "logical non-ambiguity argument" is relevant to the discussion, the mature grown-up thing to do over here is ***EXPLAIN WHAT THAT ARGUMENT IS***.
I did, several times. No need to shout, just think harder about your assumptions.
I think you'd accomplish far more, and draw much less frustration and ire, if you were to use our comments and queries as a teaching opportunity -- i.e., explain why you disagree, or explain what alternatives you prefer and why you prefer them, etc. -- rather than (as you've done here) turning them into a slightly mocking "I know something you don't know!" puzzle.