Quote from p c on October 25, 2019, 1:56 pm

Quote from Dave Voorhis on October 25, 2019, 1:26 pm

Quote from p c on October 25, 2019, 1:19 pm

Quote from Dave Voorhis on October 25, 2019, 12:44 pm

Quote from p c on October 25, 2019, 12:14 pm

“...d is... What?” d is a logical device only needed by some arguments. It introduces deliberate ambiguity, the ambiguity of union. Logically it is a relation, outside the argument  it is nothing more than synthetic syntax. So are x and y. Logically d is a projection of d&x union d&y. Since the argument only expresses deletions from from d&y, d&x simulates the preservation of the original a relation value because the argument deletes from d&y not d&x union d&y.  in other words the argument doesn’t reflect any deletions from a. It might reflect insertions but I haven’t gone so far as to check that.

“ If so, what am I (or any database developer, or DBMS implementor) expected to do with that expression?

“In other words, how does it impact the schema I gave in post #20?

“How, and where, do I turn it into Tutorial D?...”

These are amazing questions, assuming you’ve absorbed the post they are extremely imaginary. The replies in order are 1) understand it, 2) read the post, a, b and c correspond to your schemas given relations, the arguments reflect logically valid replacements of them or if you prefer changes to their relvars. 3) whatever makes you think a logical argument needs to be turned into Tutorial D? For the topic at hand, the question should be does TD reflect/respect this logical argument or that logical argument?

There seem to be three kinds of posters here. I’d guess there are many more kinds of readers. There are posters who have fixed, ossified approaches, posters who want to be told what to do and how to do it and posters who are neither.. 

Without intending any criticism of TTM, it does seem to attract people of the second kind who often also think implementing TD is equivalent to dbms implementation. As if implementing one aspect of relational theory is equivalent to complete dbms development. One needs to know which kind one is and if necessary face the facts of life.

Codd ended the 1970 paper with this: “ … the material should be adequate for experienced systems programmers to visualize several approaches”.

Not everybody is suited to be a system programmer. That’s not a bad thing, actually it’s probably a good thing because there’s more demand for other talents.

A system programmer will think about dbms aspects far beyond TD. An industrial TD might have different modes of operation, for example an isolated mode for regression tests or a compatibility mode for comparing different schemas or different dbms’es. These might be candidates for physical implementation of logical update arguments.

Quote from p c on October 25, 2019, 12:38 pm

Forgot to say that to me the last argument is much more interesting than the simpler ones. That's because the first ones amount to abstractions that parallel dbms behaviour. But fundamentally the last one is more than abstraction, it's also a synthesis. Most of us can abstract but its a  fairly small minority than can synthesize with ease. Usually mental synthesis applied to practical problems treated as a kind of direct translation as if it amount to "making it bigger" but that's not its purpose at all. I find that talent hard which is why it interests me. As they say, sometimes you have to make an equation bigger before you can make it smaller.

Although it's logically valid and so could form part of the definition of a deletion operator, I'm not 100% sure when going into questions beyond such a definition whether it contains all the premises it ought to for complete understanding. That's why I offered only hints about its difference and assumed that anybody with true interest would think about it for themselves.  I mean think about the argument, not assume translation for implementation!

Sorry, as usual I find your responses baffling. I am a systems programmer, or at least that's what I've been called on a few occasions.

Does anyone here understand @p-c's replies?

I'm left wondering if you're the database equivalent to Irwin Corey.

Don't apologize. You are letting comments intended for perspective prevent you from discerning the meat. Jumping to implementation even when implementation doesn't mean code doesn't exhibit any attempt to understand the meat. More productive would be trying to show the meat is wrong.

How can I attempt to show it wrong when "the meat" is incomprehensible?

I'm "jumping to implementation" because update-through-views et al. is something that we would implement. This isn't a philosophy class where we converse to gain nowt but enlightenment; the goal here is to build software that does useful things. I'm also "jumping to implementation" because of your criticism of post #20, which is an implementation, not an abstraction. You hint at a better way -- and often wax insulting when we don't see it. What is that better way?

If it can't be implemented -- or the implementation can't be explained -- it's not a better way.

Try to focus on the meat which is half a dozen one-liners that are formal arguments. They are very brief which means succinct precisely because they are formal. Understand them with truth tables or better still with proofs of logical validity, say by using truth tableau to show the detailed logical steps that obey established logical rules for reasoning.

Try to work out how they can or cannot apply to your scenarios. If you think they cannot, show why.

I know formal logic frightens most people, just like many people are frightened in grade 5 when they are taught how to complete the square of an equation, another example of synthesis. But it is just the most elementary parts of logic that are needed. Codd's target was compatibility with more logic than is needed for understanding view updates. You don't need to read a book although Philip K offered one here years ago but practically speaking it's enough just to dabble in the subject, like me you don't need to be as practised as he is for the problem at hand. There are several half-hour or less Youtube videos by people such as Bill Shillito and some others I forget which are enough to understand the meat just in terms of basic sets and propositions.

It's clear that you are letting your experience distract you into not focussing  your thinking on the minimum needed to focus on for your specific scenarios.

 

Quote from Dave Voorhis on October 25, 2019, 2:03 pm

Quote from p c on October 25, 2019, 1:56 pm

Quote from Dave Voorhis on October 25, 2019, 1:26 pm

Quote from p c on October 25, 2019, 1:19 pm

Quote from Dave Voorhis on October 25, 2019, 12:44 pm

Quote from p c on October 25, 2019, 12:14 pm

“...d is... What?” d is a logical device only needed by some arguments. It introduces deliberate ambiguity, the ambiguity of union. Logically it is a relation, outside the argument  it is nothing more than synthetic syntax. So are x and y. Logically d is a projection of d&x union d&y. Since the argument only expresses deletions from from d&y, d&x simulates the preservation of the original a relation value because the argument deletes from d&y not d&x union d&y.  in other words the argument doesn’t reflect any deletions from a. It might reflect insertions but I haven’t gone so far as to check that.

“ If so, what am I (or any database developer, or DBMS implementor) expected to do with that expression?

“In other words, how does it impact the schema I gave in post #20?

“How, and where, do I turn it into Tutorial D?...”

These are amazing questions, assuming you’ve absorbed the post they are extremely imaginary. The replies in order are 1) understand it, 2) read the post, a, b and c correspond to your schemas given relations, the arguments reflect logically valid replacements of them or if you prefer changes to their relvars. 3) whatever makes you think a logical argument needs to be turned into Tutorial D? For the topic at hand, the question should be does TD reflect/respect this logical argument or that logical argument?

There seem to be three kinds of posters here. I’d guess there are many more kinds of readers. There are posters who have fixed, ossified approaches, posters who want to be told what to do and how to do it and posters who are neither.. 

Without intending any criticism of TTM, it does seem to attract people of the second kind who often also think implementing TD is equivalent to dbms implementation. As if implementing one aspect of relational theory is equivalent to complete dbms development. One needs to know which kind one is and if necessary face the facts of life.

Codd ended the 1970 paper with this: “ … the material should be adequate for experienced systems programmers to visualize several approaches”.

Not everybody is suited to be a system programmer. That’s not a bad thing, actually it’s probably a good thing because there’s more demand for other talents.

A system programmer will think about dbms aspects far beyond TD. An industrial TD might have different modes of operation, for example an isolated mode for regression tests or a compatibility mode for comparing different schemas or different dbms’es. These might be candidates for physical implementation of logical update arguments.

Quote from p c on October 25, 2019, 12:38 pm

Forgot to say that to me the last argument is much more interesting than the simpler ones. That's because the first ones amount to abstractions that parallel dbms behaviour. But fundamentally the last one is more than abstraction, it's also a synthesis. Most of us can abstract but its a  fairly small minority than can synthesize with ease. Usually mental synthesis applied to practical problems treated as a kind of direct translation as if it amount to "making it bigger" but that's not its purpose at all. I find that talent hard which is why it interests me. As they say, sometimes you have to make an equation bigger before you can make it smaller.

Although it's logically valid and so could form part of the definition of a deletion operator, I'm not 100% sure when going into questions beyond such a definition whether it contains all the premises it ought to for complete understanding. That's why I offered only hints about its difference and assumed that anybody with true interest would think about it for themselves.  I mean think about the argument, not assume translation for implementation!

Sorry, as usual I find your responses baffling. I am a systems programmer, or at least that's what I've been called on a few occasions.

Does anyone here understand @p-c's replies?

I'm left wondering if you're the database equivalent to Irwin Corey.

Don't apologize. You are letting comments intended for perspective prevent you from discerning the meat. Jumping to implementation even when implementation doesn't mean code doesn't exhibit any attempt to understand the meat. More productive would be trying to show the meat is wrong.

How can I attempt to show it wrong when "the meat" is incomprehensible?

I'm "jumping to implementation" because update-through-views et al. is something that we would implement. This isn't a philosophy class where we converse to gain nowt but enlightenment; the goal here is to build software that does useful things. I'm also "jumping to implementation" because of your criticism of post #20, which is an implementation, not an abstraction. You hint at a better way -- and often wax insulting when we don't see it. What is that better way?

If it can't be implemented -- or the implementation can't be explained -- it's not a better way.

Try to focus on the meat which is half a dozen one-liners that are formal arguments. They are very brief which means succinct precisely because they are formal. Understand them with truth tables or better still with proofs of logical validity, say by using truth tableau to show the detailed logical steps that obey established logical rules for reasoning.

I know formal logic frightens most people, just like many people are frightened in grade 5 when they are taught how to complete the square of an equation, another example of synthesis. But it is just the most elementary parts of logic that are needed. Codd's target was compatibility with more logic than is needed for understanding view updates. You don't need to read a book although Philip K offered one here years ago but practically speaking it's enough just to dabble in the subject, like me you don't need to be as practised as he is for the problem at hand. There are several half-hour or less Youtube videos by people such as Bill Shillito and some others I forget which are enough to understand the meat just in terms of basic sets and propositions.

It's clear that you are letting your experience distract you into not focussing  your thinking on the minimum needed to focus on for these specific problems.

I've spent a good part of a professional career, and an academic career, and a university education in mathematics and computer science -- with classes in formal logic -- reading and (where necessary) writing formal arguments. The only content that even resembles a formal argument in your text is so disconnected from the topic here -- or any topic, as far as I can tell -- as to be completely meaningless.

Quote from p c on October 25, 2019, 2:12 pm

Quote from Dave Voorhis on October 25, 2019, 2:03 pm

Quote from p c on October 25, 2019, 1:56 pm

Quote from Dave Voorhis on October 25, 2019, 1:26 pm

Quote from p c on October 25, 2019, 1:19 pm

Quote from Dave Voorhis on October 25, 2019, 12:44 pm

Quote from p c on October 25, 2019, 12:14 pm

“...d is... What?” d is a logical device only needed by some arguments. It introduces deliberate ambiguity, the ambiguity of union. Logically it is a relation, outside the argument  it is nothing more than synthetic syntax. So are x and y. Logically d is a projection of d&x union d&y. Since the argument only expresses deletions from from d&y, d&x simulates the preservation of the original a relation value because the argument deletes from d&y not d&x union d&y.  in other words the argument doesn’t reflect any deletions from a. It might reflect insertions but I haven’t gone so far as to check that.

“ If so, what am I (or any database developer, or DBMS implementor) expected to do with that expression?

“In other words, how does it impact the schema I gave in post #20?

“How, and where, do I turn it into Tutorial D?...”

These are amazing questions, assuming you’ve absorbed the post they are extremely imaginary. The replies in order are 1) understand it, 2) read the post, a, b and c correspond to your schemas given relations, the arguments reflect logically valid replacements of them or if you prefer changes to their relvars. 3) whatever makes you think a logical argument needs to be turned into Tutorial D? For the topic at hand, the question should be does TD reflect/respect this logical argument or that logical argument?

There seem to be three kinds of posters here. I’d guess there are many more kinds of readers. There are posters who have fixed, ossified approaches, posters who want to be told what to do and how to do it and posters who are neither.. 

Without intending any criticism of TTM, it does seem to attract people of the second kind who often also think implementing TD is equivalent to dbms implementation. As if implementing one aspect of relational theory is equivalent to complete dbms development. One needs to know which kind one is and if necessary face the facts of life.

Codd ended the 1970 paper with this: “ … the material should be adequate for experienced systems programmers to visualize several approaches”.

Not everybody is suited to be a system programmer. That’s not a bad thing, actually it’s probably a good thing because there’s more demand for other talents.

A system programmer will think about dbms aspects far beyond TD. An industrial TD might have different modes of operation, for example an isolated mode for regression tests or a compatibility mode for comparing different schemas or different dbms’es. These might be candidates for physical implementation of logical update arguments.

Quote from p c on October 25, 2019, 12:38 pm

Forgot to say that to me the last argument is much more interesting than the simpler ones. That's because the first ones amount to abstractions that parallel dbms behaviour. But fundamentally the last one is more than abstraction, it's also a synthesis. Most of us can abstract but its a  fairly small minority than can synthesize with ease. Usually mental synthesis applied to practical problems treated as a kind of direct translation as if it amount to "making it bigger" but that's not its purpose at all. I find that talent hard which is why it interests me. As they say, sometimes you have to make an equation bigger before you can make it smaller.

Although it's logically valid and so could form part of the definition of a deletion operator, I'm not 100% sure when going into questions beyond such a definition whether it contains all the premises it ought to for complete understanding. That's why I offered only hints about its difference and assumed that anybody with true interest would think about it for themselves.  I mean think about the argument, not assume translation for implementation!

Sorry, as usual I find your responses baffling. I am a systems programmer, or at least that's what I've been called on a few occasions.

Does anyone here understand @p-c's replies?

I'm left wondering if you're the database equivalent to Irwin Corey.

Don't apologize. You are letting comments intended for perspective prevent you from discerning the meat. Jumping to implementation even when implementation doesn't mean code doesn't exhibit any attempt to understand the meat. More productive would be trying to show the meat is wrong.

How can I attempt to show it wrong when "the meat" is incomprehensible?

I'm "jumping to implementation" because update-through-views et al. is something that we would implement. This isn't a philosophy class where we converse to gain nowt but enlightenment; the goal here is to build software that does useful things. I'm also "jumping to implementation" because of your criticism of post #20, which is an implementation, not an abstraction. You hint at a better way -- and often wax insulting when we don't see it. What is that better way?

If it can't be implemented -- or the implementation can't be explained -- it's not a better way.

Try to focus on the meat which is half a dozen one-liners that are formal arguments. They are very brief which means succinct precisely because they are formal. Understand them with truth tables or better still with proofs of logical validity, say by using truth tableau to show the detailed logical steps that obey established logical rules for reasoning.

I know formal logic frightens most people, just like many people are frightened in grade 5 when they are taught how to complete the square of an equation, another example of synthesis. But it is just the most elementary parts of logic that are needed. Codd's target was compatibility with more logic than is needed for understanding view updates. You don't need to read a book although Philip K offered one here years ago but practically speaking it's enough just to dabble in the subject, like me you don't need to be as practised as he is for the problem at hand. There are several half-hour or less Youtube videos by people such as Bill Shillito and some others I forget which are enough to understand the meat just in terms of basic sets and propositions.

It's clear that you are letting your experience distract you into not focussing  your thinking on the minimum needed to focus on for these specific problems.

I've spent a good part of a professional career, and an academic career, and a university education in mathematics and computer science -- with classes in formal logic -- reading and (where necessary) writing formal arguments. The only content that even resembles a formal argument in your text is so disconnected from the topic here -- or any topic, as far as I can tell -- as to be completely meaningless.

A resume is not an answer to your original questions.

Pick any of the one-liner arguments and explain how it is meaningless because it doesn't parallel any part of one of your questions.

Quote from Dave Voorhis on October 25, 2019, 2:23 pm

Quote from p c on October 25, 2019, 2:12 pm

Quote from Dave Voorhis on October 25, 2019, 2:03 pm

Quote from p c on October 25, 2019, 1:56 pm

Quote from Dave Voorhis on October 25, 2019, 1:26 pm

Quote from p c on October 25, 2019, 1:19 pm

Quote from Dave Voorhis on October 25, 2019, 12:44 pm

Quote from p c on October 25, 2019, 12:14 pm

“...d is... What?” d is a logical device only needed by some arguments. It introduces deliberate ambiguity, the ambiguity of union. Logically it is a relation, outside the argument  it is nothing more than synthetic syntax. So are x and y. Logically d is a projection of d&x union d&y. Since the argument only expresses deletions from from d&y, d&x simulates the preservation of the original a relation value because the argument deletes from d&y not d&x union d&y.  in other words the argument doesn’t reflect any deletions from a. It might reflect insertions but I haven’t gone so far as to check that.

“ If so, what am I (or any database developer, or DBMS implementor) expected to do with that expression?

“In other words, how does it impact the schema I gave in post #20?

“How, and where, do I turn it into Tutorial D?...”

These are amazing questions, assuming you’ve absorbed the post they are extremely imaginary. The replies in order are 1) understand it, 2) read the post, a, b and c correspond to your schemas given relations, the arguments reflect logically valid replacements of them or if you prefer changes to their relvars. 3) whatever makes you think a logical argument needs to be turned into Tutorial D? For the topic at hand, the question should be does TD reflect/respect this logical argument or that logical argument?

There seem to be three kinds of posters here. I’d guess there are many more kinds of readers. There are posters who have fixed, ossified approaches, posters who want to be told what to do and how to do it and posters who are neither.. 

Without intending any criticism of TTM, it does seem to attract people of the second kind who often also think implementing TD is equivalent to dbms implementation. As if implementing one aspect of relational theory is equivalent to complete dbms development. One needs to know which kind one is and if necessary face the facts of life.

Codd ended the 1970 paper with this: “ … the material should be adequate for experienced systems programmers to visualize several approaches”.

Not everybody is suited to be a system programmer. That’s not a bad thing, actually it’s probably a good thing because there’s more demand for other talents.

A system programmer will think about dbms aspects far beyond TD. An industrial TD might have different modes of operation, for example an isolated mode for regression tests or a compatibility mode for comparing different schemas or different dbms’es. These might be candidates for physical implementation of logical update arguments.

Quote from p c on October 25, 2019, 12:38 pm

Forgot to say that to me the last argument is much more interesting than the simpler ones. That's because the first ones amount to abstractions that parallel dbms behaviour. But fundamentally the last one is more than abstraction, it's also a synthesis. Most of us can abstract but its a  fairly small minority than can synthesize with ease. Usually mental synthesis applied to practical problems treated as a kind of direct translation as if it amount to "making it bigger" but that's not its purpose at all. I find that talent hard which is why it interests me. As they say, sometimes you have to make an equation bigger before you can make it smaller.

Although it's logically valid and so could form part of the definition of a deletion operator, I'm not 100% sure when going into questions beyond such a definition whether it contains all the premises it ought to for complete understanding. That's why I offered only hints about its difference and assumed that anybody with true interest would think about it for themselves.  I mean think about the argument, not assume translation for implementation!

Sorry, as usual I find your responses baffling. I am a systems programmer, or at least that's what I've been called on a few occasions.

Does anyone here understand @p-c's replies?

I'm left wondering if you're the database equivalent to Irwin Corey.

Don't apologize. You are letting comments intended for perspective prevent you from discerning the meat. Jumping to implementation even when implementation doesn't mean code doesn't exhibit any attempt to understand the meat. More productive would be trying to show the meat is wrong.

How can I attempt to show it wrong when "the meat" is incomprehensible?

I'm "jumping to implementation" because update-through-views et al. is something that we would implement. This isn't a philosophy class where we converse to gain nowt but enlightenment; the goal here is to build software that does useful things. I'm also "jumping to implementation" because of your criticism of post #20, which is an implementation, not an abstraction. You hint at a better way -- and often wax insulting when we don't see it. What is that better way?

If it can't be implemented -- or the implementation can't be explained -- it's not a better way.

Try to focus on the meat which is half a dozen one-liners that are formal arguments. They are very brief which means succinct precisely because they are formal. Understand them with truth tables or better still with proofs of logical validity, say by using truth tableau to show the detailed logical steps that obey established logical rules for reasoning.

I know formal logic frightens most people, just like many people are frightened in grade 5 when they are taught how to complete the square of an equation, another example of synthesis. But it is just the most elementary parts of logic that are needed. Codd's target was compatibility with more logic than is needed for understanding view updates. You don't need to read a book although Philip K offered one here years ago but practically speaking it's enough just to dabble in the subject, like me you don't need to be as practised as he is for the problem at hand. There are several half-hour or less Youtube videos by people such as Bill Shillito and some others I forget which are enough to understand the meat just in terms of basic sets and propositions.

It's clear that you are letting your experience distract you into not focussing  your thinking on the minimum needed to focus on for these specific problems.

I've spent a good part of a professional career, and an academic career, and a university education in mathematics and computer science -- with classes in formal logic -- reading and (where necessary) writing formal arguments. The only content that even resembles a formal argument in your text is so disconnected from the topic here -- or any topic, as far as I can tell -- as to be completely meaningless.

A resume is not an answer to your original questions.

Pick any of the one-liner arguments and explain how it is meaningless because it doesn't parallel any part of one of your questions.

Picked at random, this:

For the everyday join deletions, an argument that introduces union in the form of ‘+’ such as the following argument could serve as the common join deletion proof and would prevent deletions from relation a: 

(b>a) & (a=c) & (d=a&x + a&y) & (c = b&d&y) & (x > y) & (d>y)  & -(d&x = d&y ) / -(c & b&y) > a&x & -b & -c &-(-a).

Even with some attempt to force it into a relevant context, and with every effort to at least find some superficial veneer of meaning, it's just gibberish.

I think you've seen plenty of formulae here and in TTM and textbooks and online, and you're trying to imitate them but have no idea what they mean. You're picking bits and pieces of content from things you've read and from memory, and using them to construct sentences and expressions that seem glancingly coherent -- in an Irwin Corey comedy fashion, whether comedy is intended or not -- but are meaningless. I think you're the human equivalent to this: https://en.wikipedia.org/wiki/SCIgen

In short, I think you're faking it.

Quote from p c on October 25, 2019, 2:41 pm

Quote from Dave Voorhis on October 25, 2019, 2:23 pm

Quote from p c on October 25, 2019, 2:12 pm

Quote from Dave Voorhis on October 25, 2019, 2:03 pm

Quote from p c on October 25, 2019, 1:56 pm

Quote from Dave Voorhis on October 25, 2019, 1:26 pm

Quote from p c on October 25, 2019, 1:19 pm

Quote from Dave Voorhis on October 25, 2019, 12:44 pm

Quote from p c on October 25, 2019, 12:14 pm

“...d is... What?” d is a logical device only needed by some arguments. It introduces deliberate ambiguity, the ambiguity of union. Logically it is a relation, outside the argument  it is nothing more than synthetic syntax. So are x and y. Logically d is a projection of d&x union d&y. Since the argument only expresses deletions from from d&y, d&x simulates the preservation of the original a relation value because the argument deletes from d&y not d&x union d&y.  in other words the argument doesn’t reflect any deletions from a. It might reflect insertions but I haven’t gone so far as to check that.

“ If so, what am I (or any database developer, or DBMS implementor) expected to do with that expression?

“In other words, how does it impact the schema I gave in post #20?

“How, and where, do I turn it into Tutorial D?...”

These are amazing questions, assuming you’ve absorbed the post they are extremely imaginary. The replies in order are 1) understand it, 2) read the post, a, b and c correspond to your schemas given relations, the arguments reflect logically valid replacements of them or if you prefer changes to their relvars. 3) whatever makes you think a logical argument needs to be turned into Tutorial D? For the topic at hand, the question should be does TD reflect/respect this logical argument or that logical argument?

There seem to be three kinds of posters here. I’d guess there are many more kinds of readers. There are posters who have fixed, ossified approaches, posters who want to be told what to do and how to do it and posters who are neither.. 

Without intending any criticism of TTM, it does seem to attract people of the second kind who often also think implementing TD is equivalent to dbms implementation. As if implementing one aspect of relational theory is equivalent to complete dbms development. One needs to know which kind one is and if necessary face the facts of life.

Codd ended the 1970 paper with this: “ … the material should be adequate for experienced systems programmers to visualize several approaches”.

Not everybody is suited to be a system programmer. That’s not a bad thing, actually it’s probably a good thing because there’s more demand for other talents.

A system programmer will think about dbms aspects far beyond TD. An industrial TD might have different modes of operation, for example an isolated mode for regression tests or a compatibility mode for comparing different schemas or different dbms’es. These might be candidates for physical implementation of logical update arguments.

Quote from p c on October 25, 2019, 12:38 pm

Forgot to say that to me the last argument is much more interesting than the simpler ones. That's because the first ones amount to abstractions that parallel dbms behaviour. But fundamentally the last one is more than abstraction, it's also a synthesis. Most of us can abstract but its a  fairly small minority than can synthesize with ease. Usually mental synthesis applied to practical problems treated as a kind of direct translation as if it amount to "making it bigger" but that's not its purpose at all. I find that talent hard which is why it interests me. As they say, sometimes you have to make an equation bigger before you can make it smaller.

Although it's logically valid and so could form part of the definition of a deletion operator, I'm not 100% sure when going into questions beyond such a definition whether it contains all the premises it ought to for complete understanding. That's why I offered only hints about its difference and assumed that anybody with true interest would think about it for themselves.  I mean think about the argument, not assume translation for implementation!

Sorry, as usual I find your responses baffling. I am a systems programmer, or at least that's what I've been called on a few occasions.

Does anyone here understand @p-c's replies?

I'm left wondering if you're the database equivalent to Irwin Corey.

Don't apologize. You are letting comments intended for perspective prevent you from discerning the meat. Jumping to implementation even when implementation doesn't mean code doesn't exhibit any attempt to understand the meat. More productive would be trying to show the meat is wrong.

How can I attempt to show it wrong when "the meat" is incomprehensible?

I'm "jumping to implementation" because update-through-views et al. is something that we would implement. This isn't a philosophy class where we converse to gain nowt but enlightenment; the goal here is to build software that does useful things. I'm also "jumping to implementation" because of your criticism of post #20, which is an implementation, not an abstraction. You hint at a better way -- and often wax insulting when we don't see it. What is that better way?

If it can't be implemented -- or the implementation can't be explained -- it's not a better way.

Try to focus on the meat which is half a dozen one-liners that are formal arguments. They are very brief which means succinct precisely because they are formal. Understand them with truth tables or better still with proofs of logical validity, say by using truth tableau to show the detailed logical steps that obey established logical rules for reasoning.

I know formal logic frightens most people, just like many people are frightened in grade 5 when they are taught how to complete the square of an equation, another example of synthesis. But it is just the most elementary parts of logic that are needed. Codd's target was compatibility with more logic than is needed for understanding view updates. You don't need to read a book although Philip K offered one here years ago but practically speaking it's enough just to dabble in the subject, like me you don't need to be as practised as he is for the problem at hand. There are several half-hour or less Youtube videos by people such as Bill Shillito and some others I forget which are enough to understand the meat just in terms of basic sets and propositions.

It's clear that you are letting your experience distract you into not focussing  your thinking on the minimum needed to focus on for these specific problems.

I've spent a good part of a professional career, and an academic career, and a university education in mathematics and computer science -- with classes in formal logic -- reading and (where necessary) writing formal arguments. The only content that even resembles a formal argument in your text is so disconnected from the topic here -- or any topic, as far as I can tell -- as to be completely meaningless.

A resume is not an answer to your original questions.

Pick any of the one-liner arguments and explain how it is meaningless because it doesn't parallel any part of one of your questions.

Picked at random, this:

For the everyday join deletions, an argument that introduces union in the form of ‘+’ such as the following argument could serve as the common join deletion proof and would prevent deletions from relation a: 

(b>a) & (a=c) & (d=a&x + a&y) & (c = b&d&y) & (x > y) & (d>y)  & -(d&x = d&y ) / -(c & b&y) > a&x & -b & -c &-(-a).

Even with some attempt to force it into a relevant context, and with every effort to at least find some superficial veneer of meaning, it's just gibberish.

I think you've seen plenty of formulae here and in TTM and textbooks and online, and you're trying to imitate them but have no idea what they mean. You're picking bits and pieces of content from things you've read and from memory, and using them to construct sentences and expressions that seem glancingly coherent -- in an Irwin Corey comedy fashion, whether comedy is intended or not -- but are meaningless. I think you're the human equivalent to this: https://en.wikipedia.org/wiki/SCIgen

In short, I think you're faking it.

I didn't expect you'd pick the hardest one! So start with the first wff  of the premise side of the argument surrounded by parentheses, (b>a). Does it express the meaning of your subset constaint?

Quote from Dave Voorhis on October 25, 2019, 2:49 pm

Quote from p c on October 25, 2019, 2:41 pm

Quote from Dave Voorhis on October 25, 2019, 2:23 pm

Quote from p c on October 25, 2019, 2:12 pm

Quote from Dave Voorhis on October 25, 2019, 2:03 pm

Quote from p c on October 25, 2019, 1:56 pm

Quote from Dave Voorhis on October 25, 2019, 1:26 pm

Quote from p c on October 25, 2019, 1:19 pm

Quote from Dave Voorhis on October 25, 2019, 12:44 pm

Quote from p c on October 25, 2019, 12:14 pm

“...d is... What?” d is a logical device only needed by some arguments. It introduces deliberate ambiguity, the ambiguity of union. Logically it is a relation, outside the argument  it is nothing more than synthetic syntax. So are x and y. Logically d is a projection of d&x union d&y. Since the argument only expresses deletions from from d&y, d&x simulates the preservation of the original a relation value because the argument deletes from d&y not d&x union d&y.  in other words the argument doesn’t reflect any deletions from a. It might reflect insertions but I haven’t gone so far as to check that.

“ If so, what am I (or any database developer, or DBMS implementor) expected to do with that expression?

“In other words, how does it impact the schema I gave in post #20?

“How, and where, do I turn it into Tutorial D?...”

These are amazing questions, assuming you’ve absorbed the post they are extremely imaginary. The replies in order are 1) understand it, 2) read the post, a, b and c correspond to your schemas given relations, the arguments reflect logically valid replacements of them or if you prefer changes to their relvars. 3) whatever makes you think a logical argument needs to be turned into Tutorial D? For the topic at hand, the question should be does TD reflect/respect this logical argument or that logical argument?

There seem to be three kinds of posters here. I’d guess there are many more kinds of readers. There are posters who have fixed, ossified approaches, posters who want to be told what to do and how to do it and posters who are neither.. 

Without intending any criticism of TTM, it does seem to attract people of the second kind who often also think implementing TD is equivalent to dbms implementation. As if implementing one aspect of relational theory is equivalent to complete dbms development. One needs to know which kind one is and if necessary face the facts of life.

Codd ended the 1970 paper with this: “ … the material should be adequate for experienced systems programmers to visualize several approaches”.

Not everybody is suited to be a system programmer. That’s not a bad thing, actually it’s probably a good thing because there’s more demand for other talents.

A system programmer will think about dbms aspects far beyond TD. An industrial TD might have different modes of operation, for example an isolated mode for regression tests or a compatibility mode for comparing different schemas or different dbms’es. These might be candidates for physical implementation of logical update arguments.

Quote from p c on October 25, 2019, 12:38 pm

Forgot to say that to me the last argument is much more interesting than the simpler ones. That's because the first ones amount to abstractions that parallel dbms behaviour. But fundamentally the last one is more than abstraction, it's also a synthesis. Most of us can abstract but its a  fairly small minority than can synthesize with ease. Usually mental synthesis applied to practical problems treated as a kind of direct translation as if it amount to "making it bigger" but that's not its purpose at all. I find that talent hard which is why it interests me. As they say, sometimes you have to make an equation bigger before you can make it smaller.

Although it's logically valid and so could form part of the definition of a deletion operator, I'm not 100% sure when going into questions beyond such a definition whether it contains all the premises it ought to for complete understanding. That's why I offered only hints about its difference and assumed that anybody with true interest would think about it for themselves.  I mean think about the argument, not assume translation for implementation!

Sorry, as usual I find your responses baffling. I am a systems programmer, or at least that's what I've been called on a few occasions.

Does anyone here understand @p-c's replies?

I'm left wondering if you're the database equivalent to Irwin Corey.

Don't apologize. You are letting comments intended for perspective prevent you from discerning the meat. Jumping to implementation even when implementation doesn't mean code doesn't exhibit any attempt to understand the meat. More productive would be trying to show the meat is wrong.

How can I attempt to show it wrong when "the meat" is incomprehensible?

I'm "jumping to implementation" because update-through-views et al. is something that we would implement. This isn't a philosophy class where we converse to gain nowt but enlightenment; the goal here is to build software that does useful things. I'm also "jumping to implementation" because of your criticism of post #20, which is an implementation, not an abstraction. You hint at a better way -- and often wax insulting when we don't see it. What is that better way?

If it can't be implemented -- or the implementation can't be explained -- it's not a better way.

Try to focus on the meat which is half a dozen one-liners that are formal arguments. They are very brief which means succinct precisely because they are formal. Understand them with truth tables or better still with proofs of logical validity, say by using truth tableau to show the detailed logical steps that obey established logical rules for reasoning.

I know formal logic frightens most people, just like many people are frightened in grade 5 when they are taught how to complete the square of an equation, another example of synthesis. But it is just the most elementary parts of logic that are needed. Codd's target was compatibility with more logic than is needed for understanding view updates. You don't need to read a book although Philip K offered one here years ago but practically speaking it's enough just to dabble in the subject, like me you don't need to be as practised as he is for the problem at hand. There are several half-hour or less Youtube videos by people such as Bill Shillito and some others I forget which are enough to understand the meat just in terms of basic sets and propositions.

It's clear that you are letting your experience distract you into not focussing  your thinking on the minimum needed to focus on for these specific problems.

I've spent a good part of a professional career, and an academic career, and a university education in mathematics and computer science -- with classes in formal logic -- reading and (where necessary) writing formal arguments. The only content that even resembles a formal argument in your text is so disconnected from the topic here -- or any topic, as far as I can tell -- as to be completely meaningless.

A resume is not an answer to your original questions.

Pick any of the one-liner arguments and explain how it is meaningless because it doesn't parallel any part of one of your questions.

Picked at random, this:

For the everyday join deletions, an argument that introduces union in the form of ‘+’ such as the following argument could serve as the common join deletion proof and would prevent deletions from relation a: 

(b>a) & (a=c) & (d=a&x + a&y) & (c = b&d&y) & (x > y) & (d>y)  & -(d&x = d&y ) / -(c & b&y) > a&x & -b & -c &-(-a).

Even with some attempt to force it into a relevant context, and with every effort to at least find some superficial veneer of meaning, it's just gibberish.

I think you've seen plenty of formulae here and in TTM and textbooks and online, and you're trying to imitate them but have no idea what they mean. You're picking bits and pieces of content from things you've read and from memory, and using them to construct sentences and expressions that seem glancingly coherent -- in an Irwin Corey comedy fashion, whether comedy is intended or not -- but are meaningless. I think you're the human equivalent to this: https://en.wikipedia.org/wiki/SCIgen

In short, I think you're faking it.

I didn't expect you'd pick the hardest one! So start with the first wff  of the premise side of the argument surrounded by parentheses, (b>a). Does it express the meaning of your subset constaint?

No, why would it?

All I see are two letters of the alphabet surrounded by parentheses with a '>' symbol between them. There's no connection between it and my "subset constaint [sic]".

Do you mean constant?  Or constraint?

Maybe -- at the very least -- your "one-liner arguments" need to be more than one line, so that they clearly show how the terms of your expression relate to components of the scenario?

 

Quote from johnwcowan on October 25, 2019, 3:05 pm

Quote from Dave Voorhis on October 25, 2019, 2:49 pm

All I see are two letters of the alphabet surrounded by parentheses with a '>' symbol between them. There's no connection between it and my "subset constaint [sic]".

Do you mean constant?  Or constraint?

Maybe -- at the very least -- your "one-liner arguments" need to be more than one line, so that they clearly show how the terms of your expression relate to components of the scenario?

"If you can't dazzle 'em with brilliance, baffle 'em with bullshit."  —W. C. Fields

"Monsieur, (a + bⁿ)/n = x, donc Dieu existe; répondez!"  —Euler to Diderot

"Don't feed the troll." —Anon.

See also RationalWiki.

 

Quote from p c on October 25, 2019, 3:19 pm

Quote from Dave Voorhis on October 25, 2019, 2:49 pm

Quote from p c on October 25, 2019, 2:41 pm

Quote from Dave Voorhis on October 25, 2019, 2:23 pm

Quote from p c on October 25, 2019, 2:12 pm

Quote from Dave Voorhis on October 25, 2019, 2:03 pm

Quote from p c on October 25, 2019, 1:56 pm

Quote from Dave Voorhis on October 25, 2019, 1:26 pm

Quote from p c on October 25, 2019, 1:19 pm

Quote from Dave Voorhis on October 25, 2019, 12:44 pm

Quote from p c on October 25, 2019, 12:14 pm

“...d is... What?” d is a logical device only needed by some arguments. It introduces deliberate ambiguity, the ambiguity of union. Logically it is a relation, outside the argument  it is nothing more than synthetic syntax. So are x and y. Logically d is a projection of d&x union d&y. Since the argument only expresses deletions from from d&y, d&x simulates the preservation of the original a relation value because the argument deletes from d&y not d&x union d&y.  in other words the argument doesn’t reflect any deletions from a. It might reflect insertions but I haven’t gone so far as to check that.

“ If so, what am I (or any database developer, or DBMS implementor) expected to do with that expression?

“In other words, how does it impact the schema I gave in post #20?

“How, and where, do I turn it into Tutorial D?...”

These are amazing questions, assuming you’ve absorbed the post they are extremely imaginary. The replies in order are 1) understand it, 2) read the post, a, b and c correspond to your schemas given relations, the arguments reflect logically valid replacements of them or if you prefer changes to their relvars. 3) whatever makes you think a logical argument needs to be turned into Tutorial D? For the topic at hand, the question should be does TD reflect/respect this logical argument or that logical argument?

There seem to be three kinds of posters here. I’d guess there are many more kinds of readers. There are posters who have fixed, ossified approaches, posters who want to be told what to do and how to do it and posters who are neither.. 

Without intending any criticism of TTM, it does seem to attract people of the second kind who often also think implementing TD is equivalent to dbms implementation. As if implementing one aspect of relational theory is equivalent to complete dbms development. One needs to know which kind one is and if necessary face the facts of life.

Codd ended the 1970 paper with this: “ … the material should be adequate for experienced systems programmers to visualize several approaches”.

Not everybody is suited to be a system programmer. That’s not a bad thing, actually it’s probably a good thing because there’s more demand for other talents.

A system programmer will think about dbms aspects far beyond TD. An industrial TD might have different modes of operation, for example an isolated mode for regression tests or a compatibility mode for comparing different schemas or different dbms’es. These might be candidates for physical implementation of logical update arguments.

Quote from p c on October 25, 2019, 12:38 pm

Forgot to say that to me the last argument is much more interesting than the simpler ones. That's because the first ones amount to abstractions that parallel dbms behaviour. But fundamentally the last one is more than abstraction, it's also a synthesis. Most of us can abstract but its a  fairly small minority than can synthesize with ease. Usually mental synthesis applied to practical problems treated as a kind of direct translation as if it amount to "making it bigger" but that's not its purpose at all. I find that talent hard which is why it interests me. As they say, sometimes you have to make an equation bigger before you can make it smaller.

Although it's logically valid and so could form part of the definition of a deletion operator, I'm not 100% sure when going into questions beyond such a definition whether it contains all the premises it ought to for complete understanding. That's why I offered only hints about its difference and assumed that anybody with true interest would think about it for themselves.  I mean think about the argument, not assume translation for implementation!

Sorry, as usual I find your responses baffling. I am a systems programmer, or at least that's what I've been called on a few occasions.

Does anyone here understand @p-c's replies?

I'm left wondering if you're the database equivalent to Irwin Corey.

Don't apologize. You are letting comments intended for perspective prevent you from discerning the meat. Jumping to implementation even when implementation doesn't mean code doesn't exhibit any attempt to understand the meat. More productive would be trying to show the meat is wrong.

How can I attempt to show it wrong when "the meat" is incomprehensible?

I'm "jumping to implementation" because update-through-views et al. is something that we would implement. This isn't a philosophy class where we converse to gain nowt but enlightenment; the goal here is to build software that does useful things. I'm also "jumping to implementation" because of your criticism of post #20, which is an implementation, not an abstraction. You hint at a better way -- and often wax insulting when we don't see it. What is that better way?

If it can't be implemented -- or the implementation can't be explained -- it's not a better way.

Try to focus on the meat which is half a dozen one-liners that are formal arguments. They are very brief which means succinct precisely because they are formal. Understand them with truth tables or better still with proofs of logical validity, say by using truth tableau to show the detailed logical steps that obey established logical rules for reasoning.

I know formal logic frightens most people, just like many people are frightened in grade 5 when they are taught how to complete the square of an equation, another example of synthesis. But it is just the most elementary parts of logic that are needed. Codd's target was compatibility with more logic than is needed for understanding view updates. You don't need to read a book although Philip K offered one here years ago but practically speaking it's enough just to dabble in the subject, like me you don't need to be as practised as he is for the problem at hand. There are several half-hour or less Youtube videos by people such as Bill Shillito and some others I forget which are enough to understand the meat just in terms of basic sets and propositions.

It's clear that you are letting your experience distract you into not focussing  your thinking on the minimum needed to focus on for these specific problems.

I've spent a good part of a professional career, and an academic career, and a university education in mathematics and computer science -- with classes in formal logic -- reading and (where necessary) writing formal arguments. The only content that even resembles a formal argument in your text is so disconnected from the topic here -- or any topic, as far as I can tell -- as to be completely meaningless.

A resume is not an answer to your original questions.

Pick any of the one-liner arguments and explain how it is meaningless because it doesn't parallel any part of one of your questions.

Picked at random, this:

For the everyday join deletions, an argument that introduces union in the form of ‘+’ such as the following argument could serve as the common join deletion proof and would prevent deletions from relation a: 

(b>a) & (a=c) & (d=a&x + a&y) & (c = b&d&y) & (x > y) & (d>y)  & -(d&x = d&y ) / -(c & b&y) > a&x & -b & -c &-(-a).

Even with some attempt to force it into a relevant context, and with every effort to at least find some superficial veneer of meaning, it's just gibberish.

I think you've seen plenty of formulae here and in TTM and textbooks and online, and you're trying to imitate them but have no idea what they mean. You're picking bits and pieces of content from things you've read and from memory, and using them to construct sentences and expressions that seem glancingly coherent -- in an Irwin Corey comedy fashion, whether comedy is intended or not -- but are meaningless. I think you're the human equivalent to this: https://en.wikipedia.org/wiki/SCIgen

In short, I think you're faking it.

I didn't expect you'd pick the hardest one! So start with the first wff  of the premise side of the argument surrounded by parentheses, (b>a). Does it express the meaning of your subset constaint?

No, why would it?

All I see are two letters of the alphabet surrounded by parentheses with a '>' symbol between them. There's no connection between it and my "subset constaint [sic]".

Do you mean constant?  Or constraint?

Maybe -- at the very least -- your "one-liner arguments" need to be more than one line, so that they clearly show how the terms of your expression relate to components of the scenario?

 

Sometimes I miss typos because I don't always recognize some print, whether small or large.

I meant constraint.

Do you remember this paragraph from my latest long post?:

"A simulation or argument using this particular generator assumes that x>y is a logical implication akin to x->y or x implies y and in set terms it means that x represents a subset of y in the sense that if t is a member of x, then t is a member of y. Depending on other wffs in an argument it may also mean that x is an empty subset of y."

Given that quote and the five simplifications I also gave, can you now answer with certainty, not 'maybe', whether the wff expresses the meaning of your constraint? Stick to the question.

 

 

Quote from Dave Voorhis on October 25, 2019, 3:32 pm

Quote from p c on October 25, 2019, 3:19 pm

Quote from Dave Voorhis on October 25, 2019, 2:49 pm

Quote from p c on October 25, 2019, 2:41 pm

Quote from Dave Voorhis on October 25, 2019, 2:23 pm

Quote from p c on October 25, 2019, 2:12 pm

Quote from Dave Voorhis on October 25, 2019, 2:03 pm

Quote from p c on October 25, 2019, 1:56 pm

Quote from Dave Voorhis on October 25, 2019, 1:26 pm

Quote from p c on October 25, 2019, 1:19 pm

Quote from Dave Voorhis on October 25, 2019, 12:44 pm

Quote from p c on October 25, 2019, 12:14 pm

“...d is... What?” d is a logical device only needed by some arguments. It introduces deliberate ambiguity, the ambiguity of union. Logically it is a relation, outside the argument  it is nothing more than synthetic syntax. So are x and y. Logically d is a projection of d&x union d&y. Since the argument only expresses deletions from from d&y, d&x simulates the preservation of the original a relation value because the argument deletes from d&y not d&x union d&y.  in other words the argument doesn’t reflect any deletions from a. It might reflect insertions but I haven’t gone so far as to check that.

“ If so, what am I (or any database developer, or DBMS implementor) expected to do with that expression?

“In other words, how does it impact the schema I gave in post #20?

“How, and where, do I turn it into Tutorial D?...”

These are amazing questions, assuming you’ve absorbed the post they are extremely imaginary. The replies in order are 1) understand it, 2) read the post, a, b and c correspond to your schemas given relations, the arguments reflect logically valid replacements of them or if you prefer changes to their relvars. 3) whatever makes you think a logical argument needs to be turned into Tutorial D? For the topic at hand, the question should be does TD reflect/respect this logical argument or that logical argument?

There seem to be three kinds of posters here. I’d guess there are many more kinds of readers. There are posters who have fixed, ossified approaches, posters who want to be told what to do and how to do it and posters who are neither.. 

Without intending any criticism of TTM, it does seem to attract people of the second kind who often also think implementing TD is equivalent to dbms implementation. As if implementing one aspect of relational theory is equivalent to complete dbms development. One needs to know which kind one is and if necessary face the facts of life.

Codd ended the 1970 paper with this: “ … the material should be adequate for experienced systems programmers to visualize several approaches”.

Not everybody is suited to be a system programmer. That’s not a bad thing, actually it’s probably a good thing because there’s more demand for other talents.

A system programmer will think about dbms aspects far beyond TD. An industrial TD might have different modes of operation, for example an isolated mode for regression tests or a compatibility mode for comparing different schemas or different dbms’es. These might be candidates for physical implementation of logical update arguments.

Quote from p c on October 25, 2019, 12:38 pm

Forgot to say that to me the last argument is much more interesting than the simpler ones. That's because the first ones amount to abstractions that parallel dbms behaviour. But fundamentally the last one is more than abstraction, it's also a synthesis. Most of us can abstract but its a  fairly small minority than can synthesize with ease. Usually mental synthesis applied to practical problems treated as a kind of direct translation as if it amount to "making it bigger" but that's not its purpose at all. I find that talent hard which is why it interests me. As they say, sometimes you have to make an equation bigger before you can make it smaller.

Although it's logically valid and so could form part of the definition of a deletion operator, I'm not 100% sure when going into questions beyond such a definition whether it contains all the premises it ought to for complete understanding. That's why I offered only hints about its difference and assumed that anybody with true interest would think about it for themselves.  I mean think about the argument, not assume translation for implementation!

Sorry, as usual I find your responses baffling. I am a systems programmer, or at least that's what I've been called on a few occasions.

Does anyone here understand @p-c's replies?

I'm left wondering if you're the database equivalent to Irwin Corey.

Don't apologize. You are letting comments intended for perspective prevent you from discerning the meat. Jumping to implementation even when implementation doesn't mean code doesn't exhibit any attempt to understand the meat. More productive would be trying to show the meat is wrong.

How can I attempt to show it wrong when "the meat" is incomprehensible?

I'm "jumping to implementation" because update-through-views et al. is something that we would implement. This isn't a philosophy class where we converse to gain nowt but enlightenment; the goal here is to build software that does useful things. I'm also "jumping to implementation" because of your criticism of post #20, which is an implementation, not an abstraction. You hint at a better way -- and often wax insulting when we don't see it. What is that better way?

If it can't be implemented -- or the implementation can't be explained -- it's not a better way.

Try to focus on the meat which is half a dozen one-liners that are formal arguments. They are very brief which means succinct precisely because they are formal. Understand them with truth tables or better still with proofs of logical validity, say by using truth tableau to show the detailed logical steps that obey established logical rules for reasoning.

I know formal logic frightens most people, just like many people are frightened in grade 5 when they are taught how to complete the square of an equation, another example of synthesis. But it is just the most elementary parts of logic that are needed. Codd's target was compatibility with more logic than is needed for understanding view updates. You don't need to read a book although Philip K offered one here years ago but practically speaking it's enough just to dabble in the subject, like me you don't need to be as practised as he is for the problem at hand. There are several half-hour or less Youtube videos by people such as Bill Shillito and some others I forget which are enough to understand the meat just in terms of basic sets and propositions.

It's clear that you are letting your experience distract you into not focussing  your thinking on the minimum needed to focus on for these specific problems.

I've spent a good part of a professional career, and an academic career, and a university education in mathematics and computer science -- with classes in formal logic -- reading and (where necessary) writing formal arguments. The only content that even resembles a formal argument in your text is so disconnected from the topic here -- or any topic, as far as I can tell -- as to be completely meaningless.

A resume is not an answer to your original questions.

Pick any of the one-liner arguments and explain how it is meaningless because it doesn't parallel any part of one of your questions.

Picked at random, this:

For the everyday join deletions, an argument that introduces union in the form of ‘+’ such as the following argument could serve as the common join deletion proof and would prevent deletions from relation a: 

(b>a) & (a=c) & (d=a&x + a&y) & (c = b&d&y) & (x > y) & (d>y)  & -(d&x = d&y ) / -(c & b&y) > a&x & -b & -c &-(-a).

Even with some attempt to force it into a relevant context, and with every effort to at least find some superficial veneer of meaning, it's just gibberish.

I think you've seen plenty of formulae here and in TTM and textbooks and online, and you're trying to imitate them but have no idea what they mean. You're picking bits and pieces of content from things you've read and from memory, and using them to construct sentences and expressions that seem glancingly coherent -- in an Irwin Corey comedy fashion, whether comedy is intended or not -- but are meaningless. I think you're the human equivalent to this: https://en.wikipedia.org/wiki/SCIgen

In short, I think you're faking it.

I didn't expect you'd pick the hardest one! So start with the first wff  of the premise side of the argument surrounded by parentheses, (b>a). Does it express the meaning of your subset constaint?

No, why would it?

All I see are two letters of the alphabet surrounded by parentheses with a '>' symbol between them. There's no connection between it and my "subset constaint [sic]".

Do you mean constant?  Or constraint?

Maybe -- at the very least -- your "one-liner arguments" need to be more than one line, so that they clearly show how the terms of your expression relate to components of the scenario?

 

Sometimes I miss typos because I don't always recognize some print, whether small or large.

I meant constraint.

Do you remember this paragraph from my latest long post?:

"A simulation or argument using this particular generator assumes that x>y is a logical implication akin to x->y or x implies y and in set terms it means that x represents a subset of y in the sense that if t is a member of x, then t is a member of y. Depending on other wffs in an argument it may also mean that x is an empty subset of y."

Given that quote and the five simplifications I also gave, can you now answer with certainty, not 'maybe', whether the wff expresses the meaning of your constraint? Stick to the question.

I can answer with absolute certainty that I have no idea what it has to do with my constraint -- and by "my constraint", I can only presume you mean the "foreign key" constraint CONSTRAINT InvoiceDetail_FK1 InvoiceDetail {InvoiceNumber} ⊆ InvoiceHeading {InvoiceNumber} in the post #20 scenario -- because you've made no attempt to explain it.

I think @johnwcowan's assessment is right.