Tuple visibility through a view
Alright, I’ll start to take up your three scenarios even though you still haven’t given relation values. Quoting you:
“... deleting a row may...
- “... Sometimes mean the user wants to delete only from the "many" side (delete a line item from InvoiceDetail) even if it leaves an invoice with no line items (we'll add them later);
- “... Sometimes mean the user wants to delete a whole invoice (delete an invoice from InvoiceHeading and all its line items in InvoiceDetail); and
- “... Sometimes mean the user wants to delete the last line item in InvoiceDetail and automatically delete the associated InvoiceHeading row because there are no associated line items.
“... And the user will want to do be able to do all three in the same session.
“...In the scenario as I described it in my last post, it's easy. Appropriate buttons are available in the user interface and the user can click them. They issue appropriate DELETEs to the base tables. No update-through-views is needed nor would it work, it appears.
“...How would you handle it?”
First, regarding “... nor would it work …”, do you even understand what a joinable relation is?
Note that what Appendix A calls “natural join” (the join definition that TTM assumes) means that your Invoiceheader and Invoicedetail relvars are not necessarily ‘joinable’ as Codd defined the word. That’s why I keep asking for relation values.
Suppose Invoiceheader has a tuple that matches no tuples on Invoicenumber in Invoicedetail. If you really believe what you say above ie., “... nor would it work …”, you couldn’t even use the Invoices join in a query. If your present implementation is showing that join in a query then it's logically incomplete and potentially capable of contradictions.
The reason is that the two ‘real’ relvars by definition are not joinable when they don’t match on Invoicenumber.
A second way of putting this is that when the two relvars aren’t joinable, the join view is incapable of addressing, that is, of deciding the truth of any Invoiceheader’s proposition whatsoever. Even by Appendix A’s join definition, the projections on Invoicenumber must be equal, just as they are when all tuples match on an {Invoicenumber} projection. Codd’s definition was more careful.
In other words, it’s guaranteed that the two projections always match. This means it’s guaranteed that the relations that are addressable in the above sense, whose truth is decideable by reference only to the join relation value, must always be subsets of your two real relvars and sometimes one or both must be a proper subset.
A logical join delete argument that embodies the two subset conditions explicitly will show that Not(A Join B) is equivalent to Not A And Not B.
Your past posts over the years where you have repeatedly wrongly claimed that several commercial dbms’es can delete join views have always made me suspect you don’t understand Codd 1970 because every time I look those products up, they always say the update must mention at least one base relation in addition to the join relation.
It is only the relations that are addressable via projections on common attributes that can be used to decide the base values that are logically implied by a given join value. Strictly speaking, they don’t even need to be attributes of a key.
For the join updates that are possible, a user should never need to mention base relations. What’s more, all three of your scenarios are logically possible and guaranteed unambiguous with a single join view definition.
I won’t go in just yet to the important scenario you left out, nor the advantages of the dbms guaranteeing logically valid results instead of relying on the junior programmer to guarantee them.
If you ever manage to understand the above I will show a logical simplification that proves the results you want.
Quote from p c on October 18, 2019, 10:13 pmAlright, I’ll start to take up your three scenarios even though you still haven’t given relation values. Quoting you:
“... deleting a row may...
- “... Sometimes mean the user wants to delete only from the "many" side (delete a line item from InvoiceDetail) even if it leaves an invoice with no line items (we'll add them later);
- “... Sometimes mean the user wants to delete a whole invoice (delete an invoice from InvoiceHeading and all its line items in InvoiceDetail); and
- “... Sometimes mean the user wants to delete the last line item in InvoiceDetail and automatically delete the associated InvoiceHeading row because there are no associated line items.
“... And the user will want to do be able to do all three in the same session.
“...In the scenario as I described it in my last post, it's easy. Appropriate buttons are available in the user interface and the user can click them. They issue appropriate DELETEs to the base tables. No update-through-views is needed nor would it work, it appears.
“...How would you handle it?”
First, regarding “... nor would it work …”, do you even understand what a joinable relation is?
Note that what Appendix A calls “natural join” (the join definition that TTM assumes) means that your Invoiceheader and Invoicedetail relvars are not necessarily ‘joinable’ as Codd defined the word. That’s why I keep asking for relation values.
Suppose Invoiceheader has a tuple that matches no tuples on Invoicenumber in Invoicedetail. If you really believe what you say above ie., “... nor would it work …”, you couldn’t even use the Invoices join in a query. If your present implementation is showing that join in a query then it's logically incomplete and potentially capable of contradictions.
The reason is that the two ‘real’ relvars by definition are not joinable when they don’t match on Invoicenumber.
A second way of putting this is that when the two relvars aren’t joinable, the join view is incapable of addressing, that is, of deciding the truth of any Invoiceheader’s proposition whatsoever. Even by Appendix A’s join definition, the projections on Invoicenumber must be equal, just as they are when all tuples match on an {Invoicenumber} projection. Codd’s definition was more careful.
In other words, it’s guaranteed that the two projections always match. This means it’s guaranteed that the relations that are addressable in the above sense, whose truth is decideable by reference only to the join relation value, must always be subsets of your two real relvars and sometimes one or both must be a proper subset.
A logical join delete argument that embodies the two subset conditions explicitly will show that Not(A Join B) is equivalent to Not A And Not B.
Your past posts over the years where you have repeatedly wrongly claimed that several commercial dbms’es can delete join views have always made me suspect you don’t understand Codd 1970 because every time I look those products up, they always say the update must mention at least one base relation in addition to the join relation.
It is only the relations that are addressable via projections on common attributes that can be used to decide the base values that are logically implied by a given join value. Strictly speaking, they don’t even need to be attributes of a key.
For the join updates that are possible, a user should never need to mention base relations. What’s more, all three of your scenarios are logically possible and guaranteed unambiguous with a single join view definition.
I won’t go in just yet to the important scenario you left out, nor the advantages of the dbms guaranteeing logically valid results instead of relying on the junior programmer to guarantee them.
If you ever manage to understand the above I will show a logical simplification that proves the results you want.
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. Besides, where did he ever actually ***elaborate*** the concept ? Nowhere ? Might that mean he saw early on that his concept of relation values being "joinable" in the sense he defined in the first paper was entirely useless and simply not worth elaborating ?
Your transposing the concept to relation ***variables*** being "joinable" or not shows you haven't gotten the point about the value/variable distinction and why it is important. Ironically thereby perpetuating Codd's own mistake of overlooking (if not outright dismissing) that important distinction. Mistake that may even be orders of magnitude worse than his calamities re. 'missing' and 'inapplicable'.
Quote from p c on October 18, 2019, 10:13 pmAlright, I’ll start to take up your three scenarios even though you still haven’t given relation values. Quoting you:
“... deleting a row may...
- “... Sometimes mean the user wants to delete only from the "many" side (delete a line item from InvoiceDetail) even if it leaves an invoice with no line items (we'll add them later);
- “... Sometimes mean the user wants to delete a whole invoice (delete an invoice from InvoiceHeading and all its line items in InvoiceDetail); and
- “... Sometimes mean the user wants to delete the last line item in InvoiceDetail and automatically delete the associated InvoiceHeading row because there are no associated line items.
“... And the user will want to do be able to do all three in the same session.
“...In the scenario as I described it in my last post, it's easy. Appropriate buttons are available in the user interface and the user can click them. They issue appropriate DELETEs to the base tables. No update-through-views is needed nor would it work, it appears.
“...How would you handle it?”
First, regarding “... nor would it work …”, do you even understand what a joinable relation is?
Note that what Appendix A calls “natural join” (the join definition that TTM assumes) means that your Invoiceheader and Invoicedetail relvars are not necessarily ‘joinable’ as Codd defined the word. That’s why I keep asking for relation values.
Suppose Invoiceheader has a tuple that matches no tuples on Invoicenumber in Invoicedetail. If you really believe what you say above ie., “... nor would it work …”, you couldn’t even use the Invoices join in a query. If your present implementation is showing that join in a query then it's logically incomplete and potentially capable of contradictions.
The reason is that the two ‘real’ relvars by definition are not joinable when they don’t match on Invoicenumber.
A second way of putting this is that when the two relvars aren’t joinable, the join view is incapable of addressing, that is, of deciding the truth of any Invoiceheader’s proposition whatsoever. Even by Appendix A’s join definition, the projections on Invoicenumber must be equal, just as they are when all tuples match on an {Invoicenumber} projection. Codd’s definition was more careful.
In other words, it’s guaranteed that the two projections always match. This means it’s guaranteed that the relations that are addressable in the above sense, whose truth is decideable by reference only to the join relation value, must always be subsets of your two real relvars and sometimes one or both must be a proper subset.
A logical join delete argument that embodies the two subset conditions explicitly will show that Not(A Join B) is equivalent to Not A And Not B.
Your past posts over the years where you have repeatedly wrongly claimed that several commercial dbms’es can delete join views have always made me suspect you don’t understand Codd 1970 because every time I look those products up, they always say the update must mention at least one base relation in addition to the join relation.
It is only the relations that are addressable via projections on common attributes that can be used to decide the base values that are logically implied by a given join value. Strictly speaking, they don’t even need to be attributes of a key.
For the join updates that are possible, a user should never need to mention base relations. What’s more, all three of your scenarios are logically possible and guaranteed unambiguous with a single join view definition.
I won’t go in just yet to the important scenario you left out, nor the advantages of the dbms guaranteeing logically valid results instead of relying on the junior programmer to guarantee them.
If you ever manage to understand the above I will show a logical simplification that proves the results you want.
I'll try to address your points in order in one block of text here, rather than interject responses.
Re "joinable relation" and relation values: My database schema in post #20 is based on production code (in a few dozen billing systems I've written, which are no doubt pretty similar to a few hundred thousand working billing systems) where InvoiceHeading and InvoiceDetail can be successfully joined. The schema is not just hypothetical Tutorial D; I've tested it in Rel.
Why would I need to provide relation values?
We presume the database schema I described in post #20 will be used to create a database that will underpin some end-user billing application, such that the relation values will be provided by users. Whatever mechanisms are defined, they will not change on a relation-by-relation basis. So, the relation values shouldn't matter. Please note that there is a constraint defined in my schema in post #20, which ensures that tuples in InvoiceDetail always have an InvoiceNumber matching an InvoiceNumber in InvoiceHeading. I.e., every invoice line item must belong to an invoice.
Re: "Your past posts over the years where you have repeatedly wrongly claimed that several commercial dbms’es can delete join views have always made me suspect you don’t understand Codd 1970 because every time I look those products up, they always say the update must mention at least one base relation in addition to the join relation."
Are you sure?
Take a look at https://docs.microsoft.com/en-us/sql/t-sql/statements/create-view-transact-sql?view=sql-server-ver15#updatable-views from the Microsoft SQL Server manual. It states that a key requirement for updatable views (aside from obvious ones, like not being able to update through aggregate operators and the like) is that all referenced columns must originate in only one base table -- i.e., if the view involves multiple tables, you can only mention columns that come from one of them. In general, any query attempting to update through a view must unambiguously reference rows/tuples in only one base table of the view. Is that what you mean by "the update must mention at least one base relation in addition to the join relation?"
Or do you mean a syntactic requirement to explicitly name one base table in addition to the join (view)?
If so, I don't see any requirement in the SQL Server manual to -- if I understand you correctly -- use a different syntax for updating views (compared to updating base tables?) that requires you to mention "at least one base relation in addition to the join relation"?
Finally, I'm not clear what you think I'm "relying on the junior programmer to guarantee", and I'm curious how "all three of [my] scenarios are logically possible ... with a single join view definition."
Okay, I'm bending over backwards now. You don't get why values matter and you don't understand or don't want to understand a couple of important paragraphs. You want to know why values matter even after I've given the crucial reason and told you what to read to verify for yourself that TTM natural join is not Codd's natural join.
So I've done some of the work to show from another angle how de Morgan is usually misapplied here. I used two different truth table generators and their outputs agree. I can't figure out how to copy and post their graphical output, I can only cut and paste the input.
This started out as the converse of de Morgan: (¬(A∧B) ⇔¬A∧¬B) simulating the A Join B with the conjuncion operator and testing whether its negation equals the conjunction of the negations of A and B. Of course, by itself it can't be proved.
So I simulated tuples of A that don't match tuples of the join by adding a boolean C that is not equal to A and a boolean D that is not equal to B. in effect replacing A Join B with (A minus C) Join (B minus D). This simulates a join where A and B both contain tuples that don't match the join.
In both truth tables there is exactly one line where A and B are true and the overall expression is true. That line occurs when A and B are both true and B and D are both false. That line simulates joinable A and B, both non-empty. They must be non-empty otherwise the join is empty and there is nothing to delete.
As you might expect, there is a second true line where the situation is reversed so that A and B are both empty and B and D are both not empty.
I manually typed in the output of the first generator (which also tests logical validity) which gave a more compact output, making it easier for me to be fairly sure I didn't make a typing mistake:
| 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 | 0 | 0 |
| 10 | 0 | 1 | 0 | 0 | 0 |
| 11 | 0 | 1 | 1 | 1 | 1 |
| 12 | 0 | 1 | 0 | 0 | 0 |
| 13 | 0 | 0 | 1 | 0 | 0 |
| 14 | 0 | 0 | 0 | 0 | 0 |
| 15 | 0 | 0 | 1 | 0 | 0 |
| 16 | 0 | 0 | 0 | 0 | 0 |
This shows the general case of natural join which allows for input relations that are not joinable as well as ones that are joinable.
Given experience so far, I don't expect you will examine it, but perhaps somebody else will.
Quote from Erwin on October 18, 2019, 11:26 pmQuote from p c on October 18, 2019, 10:13 pmAlright, I’ll start to take up your three scenarios even though you still haven’t given relation values. Quoting you:
“... deleting a row may...
- “... Sometimes mean the user wants to delete only from the "many" side (delete a line item from InvoiceDetail) even if it leaves an invoice with no line items (we'll add them later);
- “... Sometimes mean the user wants to delete a whole invoice (delete an invoice from InvoiceHeading and all its line items in InvoiceDetail); and
- “... Sometimes mean the user wants to delete the last line item in InvoiceDetail and automatically delete the associated InvoiceHeading row because there are no associated line items.
“... And the user will want to do be able to do all three in the same session.
“...In the scenario as I described it in my last post, it's easy. Appropriate buttons are available in the user interface and the user can click them. They issue appropriate DELETEs to the base tables. No update-through-views is needed nor would it work, it appears.
“...How would you handle it?”
First, regarding “... nor would it work …”, do you even understand what a joinable relation is?
Note that what Appendix A calls “natural join” (the join definition that TTM assumes) means that your Invoiceheader and Invoicedetail relvars are not necessarily ‘joinable’ as Codd defined the word. That’s why I keep asking for relation values.
Suppose Invoiceheader has a tuple that matches no tuples on Invoicenumber in Invoicedetail. If you really believe what you say above ie., “... nor would it work …”, you couldn’t even use the Invoices join in a query. If your present implementation is showing that join in a query then it's logically incomplete and potentially capable of contradictions.
The reason is that the two ‘real’ relvars by definition are not joinable when they don’t match on Invoicenumber.
A second way of putting this is that when the two relvars aren’t joinable, the join view is incapable of addressing, that is, of deciding the truth of any Invoiceheader’s proposition whatsoever. Even by Appendix A’s join definition, the projections on Invoicenumber must be equal, just as they are when all tuples match on an {Invoicenumber} projection. Codd’s definition was more careful.
In other words, it’s guaranteed that the two projections always match. This means it’s guaranteed that the relations that are addressable in the above sense, whose truth is decideable by reference only to the join relation value, must always be subsets of your two real relvars and sometimes one or both must be a proper subset.
A logical join delete argument that embodies the two subset conditions explicitly will show that Not(A Join B) is equivalent to Not A And Not B.
Your past posts over the years where you have repeatedly wrongly claimed that several commercial dbms’es can delete join views have always made me suspect you don’t understand Codd 1970 because every time I look those products up, they always say the update must mention at least one base relation in addition to the join relation.
It is only the relations that are addressable via projections on common attributes that can be used to decide the base values that are logically implied by a given join value. Strictly speaking, they don’t even need to be attributes of a key.
For the join updates that are possible, a user should never need to mention base relations. What’s more, all three of your scenarios are logically possible and guaranteed unambiguous with a single join view definition.
I won’t go in just yet to the important scenario you left out, nor the advantages of the dbms guaranteeing logically valid results instead of relying on the junior programmer to guarantee them.
If you ever manage to understand the above I will show a logical simplification that proves the results you want.
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. Besides, where did he ever actually ***elaborate*** the concept ? Nowhere ? Might that mean he saw early on that his concept of relation values being "joinable" in the sense he defined in the first paper was entirely useless and simply not worth elaborating ?
Your transposing the concept to relation ***variables*** being "joinable" or not shows you haven't gotten the point about the value/variable distinction and why it is important. Ironically thereby perpetuating Codd's own mistake of overlooking (if not outright dismissing) that important distinction. Mistake that may even be orders of magnitude worse than his calamities re. 'missing' and 'inapplicable'.
Or maybe you've drunk too much type theory KoolAid.
Variables are irrelevant to the logic of updating. Note that basic set theory doesn't have variables.
Quote from p c on October 19, 2019, 6:25 amOkay, I'm bending over backwards now. You don't get why values matter and you don't understand or don't want to understand a couple of important paragraphs. You want to know why values matter even after I've given the crucial reason and told you what to read to verify for yourself that TTM natural join is not Codd's natural join.
So I've done some of the work to show from another angle how de Morgan is usually misapplied here. I used two different truth table generators and their outputs agree. I can't figure out how to copy and post their graphical output, I can only cut and paste the input.
This started out as the converse of de Morgan: (¬(A∧B) ⇔¬A∧¬B) simulating the A Join B with the conjuncion operator and testing whether its negation equals the conjunction of the negations of A and B. Of course, by itself it can't be proved.
So I simulated tuples of A that don't match tuples of the join by adding a boolean C that is not equal to A and a boolean D that is not equal to B. in effect replacing A Join B with (A minus C) Join (B minus D). This simulates a join where A and B both contain tuples that don't match the join.
In both truth tables there is exactly one line where A and B are true and the overall expression is true. That line occurs when A and B are both true and B and D are both false. That line simulates joinable A and B, both non-empty. They must be non-empty otherwise the join is empty and there is nothing to delete.
As you might expect, there is a second true line where the situation is reversed so that A and B are both empty and B and D are both not empty.
I manually typed in the output of the first generator (which also tests logical validity) which gave a more compact output, making it easier for me to be fairly sure I didn't make a typing mistake:
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 0 0 10 0 1 0 0 0 11 0 1 1 1 1 12 0 1 0 0 0 13 0 0 1 0 0 14 0 0 0 0 0 15 0 0 1 0 0 16 0 0 0 0 0 This shows the general case of natural join which allows for input relations that are not joinable as well as ones that are joinable.
Given experience so far, I don't expect you will examine it, but perhaps somebody else will.
It's actually very important -- vital, in fact -- that specific values not matter, because the database schema needs to be valid -- i.e., needs to maintain the integrity of the data in the database -- no matter what data is provided by the associated application(s), which in turn are driven by users who can enter whatever they see fit.
The structure, types and constraints of the database should be sufficient to ensure that the data in it is always valid, and thus the specific values should be irrelevant, as we should only need to talk about the database structure, types, and constraints.
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?
Quote from p c on October 19, 2019, 6:37 amQuote from Erwin on October 18, 2019, 11:26 pmQuote from p c on October 18, 2019, 10:13 pmAlright, I’ll start to take up your three scenarios even though you still haven’t given relation values. Quoting you:
“... deleting a row may...
- “... Sometimes mean the user wants to delete only from the "many" side (delete a line item from InvoiceDetail) even if it leaves an invoice with no line items (we'll add them later);
- “... Sometimes mean the user wants to delete a whole invoice (delete an invoice from InvoiceHeading and all its line items in InvoiceDetail); and
- “... Sometimes mean the user wants to delete the last line item in InvoiceDetail and automatically delete the associated InvoiceHeading row because there are no associated line items.
“... And the user will want to do be able to do all three in the same session.
“...In the scenario as I described it in my last post, it's easy. Appropriate buttons are available in the user interface and the user can click them. They issue appropriate DELETEs to the base tables. No update-through-views is needed nor would it work, it appears.
“...How would you handle it?”
First, regarding “... nor would it work …”, do you even understand what a joinable relation is?
Note that what Appendix A calls “natural join” (the join definition that TTM assumes) means that your Invoiceheader and Invoicedetail relvars are not necessarily ‘joinable’ as Codd defined the word. That’s why I keep asking for relation values.
Suppose Invoiceheader has a tuple that matches no tuples on Invoicenumber in Invoicedetail. If you really believe what you say above ie., “... nor would it work …”, you couldn’t even use the Invoices join in a query. If your present implementation is showing that join in a query then it's logically incomplete and potentially capable of contradictions.
The reason is that the two ‘real’ relvars by definition are not joinable when they don’t match on Invoicenumber.
A second way of putting this is that when the two relvars aren’t joinable, the join view is incapable of addressing, that is, of deciding the truth of any Invoiceheader’s proposition whatsoever. Even by Appendix A’s join definition, the projections on Invoicenumber must be equal, just as they are when all tuples match on an {Invoicenumber} projection. Codd’s definition was more careful.
In other words, it’s guaranteed that the two projections always match. This means it’s guaranteed that the relations that are addressable in the above sense, whose truth is decideable by reference only to the join relation value, must always be subsets of your two real relvars and sometimes one or both must be a proper subset.
A logical join delete argument that embodies the two subset conditions explicitly will show that Not(A Join B) is equivalent to Not A And Not B.
Your past posts over the years where you have repeatedly wrongly claimed that several commercial dbms’es can delete join views have always made me suspect you don’t understand Codd 1970 because every time I look those products up, they always say the update must mention at least one base relation in addition to the join relation.
It is only the relations that are addressable via projections on common attributes that can be used to decide the base values that are logically implied by a given join value. Strictly speaking, they don’t even need to be attributes of a key.
For the join updates that are possible, a user should never need to mention base relations. What’s more, all three of your scenarios are logically possible and guaranteed unambiguous with a single join view definition.
I won’t go in just yet to the important scenario you left out, nor the advantages of the dbms guaranteeing logically valid results instead of relying on the junior programmer to guarantee them.
If you ever manage to understand the above I will show a logical simplification that proves the results you want.
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. Besides, where did he ever actually ***elaborate*** the concept ? Nowhere ? Might that mean he saw early on that his concept of relation values being "joinable" in the sense he defined in the first paper was entirely useless and simply not worth elaborating ?
Your transposing the concept to relation ***variables*** being "joinable" or not shows you haven't gotten the point about the value/variable distinction and why it is important. Ironically thereby perpetuating Codd's own mistake of overlooking (if not outright dismissing) that important distinction. Mistake that may even be orders of magnitude worse than his calamities re. 'missing' and 'inapplicable'.
Or maybe you've drunk too much type theory KoolAid.
Variables are irrelevant to the logic of updating. Note that basic set theory doesn't have variables.
Be that as it may, the basis for this part of the thread, the example in post #20 -- which is illustrative of a typical real-world problem using a real-world database language (which is trivially translatable to the real world's most popular database language) -- has variables. I'm not sure it's helpful to try to ignore them.
Quote from p c on October 19, 2019, 6:37 amWhat 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. Besides, where did he ever actually ***elaborate*** the concept ? Nowhere ? Might that mean he saw early on that his concept of relation values being "joinable" in the sense he defined in the first paper was entirely useless and simply not worth elaborating ?
Your transposing the concept to relation ***variables*** being "joinable" or not shows you haven't gotten the point about the value/variable distinction and why it is important. Ironically thereby perpetuating Codd's own mistake of overlooking (if not outright dismissing) that important distinction. Mistake that may even be orders of magnitude worse than his calamities re. 'missing' and 'inapplicable'.
Or maybe you've drunk too much type theory KoolAid.
Variables are irrelevant to the logic of updating. Note that basic set theory doesn't have variables.
Which is the very reason why logic (/basic set theory) alone just isn't enough to build data manipulation languages on.
"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.
There is a big difference between a system and a language. What you say certainly describes a file system language. Note the parallel with physical files and Dave's presumption that "relation values will be provided by users". But in a relational system most values are calculated by the system.
So there is less work and chance for errors by users and the system doesn't need to depend on Dave's presumption that "junior programmers ... generally get it right".
The '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.
When you say that today data language relvars mean we have gone beyond Codd, you are actually talking about a regression to pre-Codd times.
In those days and for many years after, the acronym IBM was often equated with It's Better Manually. In those days IBM was incapable of providing one monthly invoice for even the smallest of systems. Instead customers had to reconcile dozens of isolated invoices. This was because IBM's account database could not integrate changes to the invoice database!
Your preferred dbms is more accurately described as an SRAFS, a Sub-Relational Advanced File System.
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.
There is a big difference between a system and a language. What you say certainly describes a file system language. Note the parallel with physical files and Dave's presumption that "relation values will be provided by users". But in a relational system most values are calculated by the system.
So there is less work and chance for errors by users and the system doesn't need to depend on Dave's presumption that "junior programmers ... generally get it right".
The '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.
When you say that today data language relvars mean we have gone beyond Codd, you are actually talking about a regression to pre-Codd times.
In those days and for many years after, the acronym IBM was often equated with It's Better Manually. In those days IBM was incapable of providing one monthly invoice for even the smallest of systems. Instead customers had to reconcile dozens of isolated invoices. This was because IBM's account database could not integrate changes to the invoice database!
Your preferred dbms is more accurately described as an SRAFS, a Sub-Relational Advanced File System.
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. As an example, in a system where my billing snippet might be used, the customers referenced in the invoice headings are almost certainly manually entered via a form on a customer-facing Web site. The inventory items, referenced by the invoice line items, are almost certainly entered via a form on an internal administrative Web site or desktop administration client. The invoices themselves are often human-audited (this depends on the business) and are very often automatically generated from customer orders, which were again probably manually entered via a form on a customer-facing Web site.
And so on. The data that drives the information system always ultimately comes from human activity and human data recording. Machines don't make this stuff up; it comes from people.
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.