Tuple visibility through a view
Quote from p c on October 20, 2019, 3:22 pm[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.
It's pretty obvious you know that's not true. Why, instead of explaining your point(s) of view, do you resort to repetition and insinuations? Why are you unwilling to explain your views?
Quote from p c on October 20, 2019, 3:22 pmA 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.
Sorry, I find this completely baffling. I know what a truth table is. Please explain what it has to do with my example in post #20.
Quote from p c on October 20, 2019, 1:42 pm[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"?
[...]
[end quote]
Yes, yes and yes to the three questions.
Ah hah!
That clarifies so much!
All along, we've been debating how many angels can dance on the head of a pin. It turns out you've been arguing from the assumption that there are no angels and no pin.
Only... You forget to tell us.
So it turns out this doesn't really have anything to do with whether my post #20 schema is right or wrong or how it could be changed, or whether my Invoices view can or can't be updated through. Those all presume the TTM model, which is very similar to the SQL model but deviates from it in fundamental ways, which are precisely the motivation for TTM.
In fact, you advocate a completely different model. You may casually make suggestions like letting the application programmers do all updates through the Invoices view, but they apparently presume a model that must be so different from the TTM model (no variables, for example) that it is almost certainly a meaningless suggestion, at least in the context of TTM. It may be meaningful to you, but not to us. We've been assuming the TTM model.
The real problem here is that you haven't explained your model. Thus, we have no idea what you have in mind. Presumably you've got it all spelled out somewhere -- either in a private document or in your own mind -- but we don't, and so your insistences are lost on us.
You really need to explain what you have in mind, ideally in at least as much detail -- and clarity, if possible -- as Date & Darwen's original TTM paper and Codd's A Relational Model for Large Shared Data Banks.
Otherwise, we get nowhere.
In preparing the latest answer I noticed some typos in the truth table I previously typed up.
They are not significant to the argument, but I've corrected them here. The typos were in the b and d columns for lines 9 through 16.
| line | a | c | b | d | -(a=c)&-(b=d)&-((a&-c&b&-d)=(-a&-b)) |
| 1 | 1 | 1 | 1 | 1 | 0 |
| 2 | 1 | 1 | 1 | 0 | 0 |
| 3 | 1 | 1 | 0 | 1 | 0 |
| 4 | 1 | 1 | 0 | 0 | 0 |
| 5 | 1 | 0 | 1 | 1 | 0 |
| 6 | 1 | 0 | 1 | 0 | 1 |
| 7 | 1 | 0 | 0 | 1 | 0 |
| 8 | 1 | 0 | 0 | 0 | 0 |
| 9 | 0 | 1 | 1 | 1 | 0 |
| 10 | 0 | 1 | 1 | 0 | 0 |
| 11 | 0 | 1 | 0 | 1 | 1 |
| 12 | 0 | 1 | 0 | 0 | 0 |
| 13 | 0 | 0 | 1 | 1 | 0 |
| 14 | 0 | 0 | 1 | 0 | 0 |
| 15 | 0 | 0 | 0 | 1 | 0 |
| 16 | 0 | 0 | 0 | 0 | 0 |
As before, the conclusion remains that joinable relations must be assumed. They are represented in the table by the only line in which a and b are true aka not empty and c and d are false aka empty. In case I didn't say it before, it is quite stunning how Codd anticipated this with his natural join definition which enables data independence.
You could also say that the Appendix A definition prevents data independence.
Quote from Dave Voorhis on October 20, 2019, 5:56 pm
It's pretty obvious you know that's not true. Why, instead of explaining your point(s) of view, do you resort to repetition and insinuations? Why are you unwilling to explain your views?
Because he's a troll. He has, perhaps, more knowledge than the average troll, but the outward and visible signs, at least, of the same motivations.
And you know what they say about feeding the troll.
Quote from p c on October 21, 2019, 12:05 am[...]
As before, the conclusion remains that joinable relations must be assumed. They are represented in the table by the only line in which a and b are true aka not empty and c and d are false aka empty. In case I didn't say it before, it is quite stunning how Codd anticipated this with his natural join definition which enables data independence.
You could also say that the Appendix A definition prevents data independence.
What does your table have to do with my example in post #20?
How did Codd anticipate your table... (this?)?
How does Appendix A prevent data independence?
What is it about Codd's definition that enables data independence whilst Appendix A's definition prevents it?
Quote from johnwcowan on October 21, 2019, 2:53 amQuote from Dave Voorhis on October 20, 2019, 5:56 pmIt's pretty obvious you know that's not true. Why, instead of explaining your point(s) of view, do you resort to repetition and insinuations? Why are you unwilling to explain your views?
Because he's a troll. He has, perhaps, more knowledge than the average troll, but the outward and visible signs, at least, of the same motivations.
And you know what they say about feeding the troll.
Well, yes. There's certainly an element of Ferrous Cranus (and others) going on there, but I like to give folks the benefit of the doubt. "p c" sometimes seems tantalisingly close to making sense, and if I could just tease out meaning, maybe there'd be some insight.
Then again, having been at this for 14 years -- and apparently he goes further back on alt.database.theory -- with no luck, maybe seeming "tantalisingly close" without ever getting there is the whole of his schtick.
On another forum a few years back, there was a fellow who used to ask pseudo-techno-managerial fully-buzzword-compliant questions. Things like (making one up) "How does service oriented architecture represent business opportunity leverage of data-science AI in an era of advanced microservices when deploying Kubernetes?"
After a while of trying to badger sense out of the questions -- and occasionally wasting time on an answer that only dislodged similar rubble -- it became apparent (and I don't recall how; maybe there was some candid admission and/or perhaps a hint from one of his co-workers) that the fellow was using his weird Q&A to demonstrate to his bosses and peers that he was fruitfully engaged in discussing work-relevant topics with global colleagues, when it was otherwise clear that he was useless at work and doing nothing.
Please ignore that truth table, sorry for the bother. I can see now that it is too confused even for my style. I have thought of what I think is a more applicable but longer way to justify my claims but it may take a day or two to spell it out in formal steps.
Quote from p c on October 21, 2019, 1:25 pmPlease ignore that truth table, sorry for the bother. I can see now that it is too confused even for my style. I have thought of what I think is a more direct but longer way to justify my claims but it may take a day or two to spell it out in formal steps.
Don't worry about formal steps, at least to begin with. Just explain it in plain English.
Please understand that we have no idea what you have in mind because you have never explained it, but you sometimes write as if it should be obvious.
It's not.
Quote from p c on October 14, 2019, 6:35 pmThe latest repeat mention of Datalog confuses me just as much as it has for years. It seems silly because I've never read that it embodies Codd's theory so a dbms implementation must need a lot of backward integration.
There are numerous papers about the equivalence of Datalog and the RA + transitive closure. It's straightforward to map Datalog into SQL with recursive CTEs as well: facts become inserts into existing tables, rules with a common predicate are a special case of a view, using UNION to deal with disjunctive multiple rules. Within a rule, the head maps to a SELECT, the body predicates to FROM, logic variables to equijoins, negated terms to NOT IN, literals in predicate arguments to WHERE-clauses joined by AND, and so on. Conversion to D semantics mostly involves renames so that natural joins can be used, plus some way to map position-based Datalog predicates to name-based D relvars.
In order for Datalog with negated terms to be sound and logically complete, all predicates must be placeable into strata such that rules in stratum n can contained negative terms only if they are defined by rules in a stratum less than n. All facts are in stratum 0. That's all.
Quote from johnwcowan on October 23, 2019, 1:43 amQuote from p c on October 14, 2019, 6:35 pmThe latest repeat mention of Datalog confuses me just as much as it has for years. It seems silly because I've never read that it embodies Codd's theory so a dbms implementation must need a lot of backward integration.
There are numerous papers about the equivalence of Datalog and the RA + transitive closure. It's straightforward to map Datalog into SQL with recursive CTEs as well: facts become inserts into existing tables, rules with a common predicate are a special case of a view, using UNION to deal with disjunctive multiple rules. Within a rule, the head maps to a SELECT, the body predicates to FROM, logic variables to equijoins, negated terms to NOT IN, literals in predicate arguments to WHERE-clauses joined by AND, and so on. Conversion to D semantics mostly involves renames so that natural joins can be used, plus some way to map position-based Datalog predicates to name-based D relvars.
In order for Datalog with negated terms to be sound and logically complete, all predicates must be placeable into strata such that rules in stratum n can contained negative terms only if they are defined by rules in a stratum less than n. All facts are in stratum 0. That's all.
It's worth mentioning that is pretty well all spelled out in Alice.