Quote from AntC on March 4, 2020, 12:05 am

Quote from dandl on March 3, 2020, 11:06 pm

Quote from Dave Voorhis on March 3, 2020, 2:13 pm

Quote from dandl on March 3, 2020, 1:08 pm

Quote from Erwin on March 3, 2020, 7:39 am

Quote from dandl on March 3, 2020, 12:27 am

IS_EMPTY (CAR_ASSGN_EMP JOIN CAR_ASSGN_DEPT).

I agree, this is thematic for TTM. But please note, this is an expression written in a programming language, a D, and it's part of the database schema. See RM Pre 23.

Well, it's an expression written in ***some*** language.  I'm not sure how you determined it's a "programming" language.  It's a declaration of something that's as you say, "part of the database schema", and therefore it might be much clearer and appropriate to call it the "schema" language.

It's a programming language, by any definition. It has a lexical structure, a syntactic structure, a semantics based on the meanings of symbols. It is defined by BNF, and it conforms to some Chomsky level.

Eh? Predicate logic has all that structure. Nobody would claim it's a programming language, PROLOG notwithstanding. Indeed Klingon has all that structure. Possibly natural languages have that structure -- research question.

Popular usage holds that a programming language is a computer language that is Turing Complete. That's what makes C a programming language, and HTML and CSS not programming languages. We usually use the term "database language" or "query language" to distinguish certain languages that are often not Turing Complete -- or that are Turing Complete but not in a remotely general-purpose way -- from programming languages.

Tutorial D is a programming language.

You might want to read this before making the statement with such certainty. There is some disagreement about what constitutes a 'programming language' versus a 'computer language' vs a 'data language'. It's not central to my point.

In order to define fully general database constraints (as per RM Pre 23), they have to be expressed in some kind of programming/computer/query/database sub-language that specifies the evaluation of an expression that returns a boolean value.

Oh, dear we seem to having another one of David's over-heated nit-picks about something "not central to my point".

It's usual (at least in procedural languages) to distinguish the syntax for expressions vs for flow-of-control. Database constraints are (Boolean) expressions. There's no flow-of-control I can see. (Possibly TCLOSE, but would a practical language want to include those in constraints? And non-general closure typically doesn't include flow-of-control.)

That sub-language has at least to be able to specify an arbitrary query on database relvars and invoke operators on values of all the types found in those relvars. Those queries should likely include second order features (aggregation and computed values) and possibly fixed point recursion (transitive closure). They might not include features that would allow non-terminating queries, so would likely fall just short of being Turing Complete. A full D would be overkill, but a D-like subset expression language with no assignment, loops or recursion would perhaps suffice.

Writing code in such a language still looks like programming to me, no matter what name you give to the language. It most certainly is not "just a schema language".

That looks like a statement from somebody who knows only how to program, not how to express logic. (lightbulb moment). Constraint expressions look like logic to me. There's no need to consider flow-of-control; no assignment to variables; no nasty side-effects. I would trust an Excel-competent user to write constraints for me; but not to program.

Quote from Erwin on March 4, 2020, 11:21 am

Quote from dandl on March 3, 2020, 11:06 pm

Quote from Dave Voorhis on March 3, 2020, 2:13 pm

Popular usage holds that a programming language is a computer language that is Turing Complete. That's what makes C a programming language, and HTML and CSS not programming languages. We usually use the term "database language" or "query language" to distinguish certain languages that are often not Turing Complete -- or that are Turing Complete but not in a remotely general-purpose way -- from programming languages.

Tutorial D is a programming language.

You might want to read this before making the statement with such certainty. There is some disagreement about what constitutes a 'programming language' versus a 'computer language' vs a 'data language'. It's not central to my point.

I'm [not really] sorry, but you might want to read "this" yourself before using it as an argument.

I'll just quote two parts here (emphasis mine where you see ***********) :

"A programming language is a formal language, which comprises a set of instructions **********that produce various kinds of output**********. Programming languages are used in computer programming to implement algorithms."

"A programming language is a notation for writing programs, **********which are specifications of a computation or algorithm**********."

What "various kinds of output" are produced by, or which "algorithms are implemented" by, say, the text snippet "IS_EMPTY(R1 JOIN R2)" ?

What "computation or algorithm" is specified by "IS_EMPTY(R1 JOIN R2)" ?

Hint 1 : While the text snippet "ADD DATABASECONSTRAINT,RELATION(TUPLE(CONSTRAINTLABEL(...)CONSTRAINTEXPRESSIONTEXT(...)ERRORCODE(...)))" is arguably a reasonable textual representation of something that can be seen as "an instruction that produces output" (a newly defined constraint in the catalog), that text snippet is manifestly not the same thing as the text snippet that is just the logical definition of the constraint.  Throwing all those things all on one big pile is exactly the misinterpretation of Reeves 1992 of which he later wrote that "that one made him particularly angry".  And in blatant denial of what I suppose McGoveran was writing about in those 5 published draft introductory chapters of the forthcoming book, where he went to agonizing lengths to make it clear that "there are different distinct languages in play here".

Hint 2 : The suggested algorithm "compute the join and see if it is empty or not" is manifestly not the algorithm carried out by the constraint enforcement machinery of you-know-which-system.

Quote from AntC on March 5, 2020, 3:59 am

Quote from Erwin on March 4, 2020, 11:21 am

Quote from dandl on March 3, 2020, 11:06 pm

Quote from Dave Voorhis on March 3, 2020, 2:13 pm

...

You might want to read this before making the statement with such certainty. There is some disagreement about what constitutes a 'programming language' versus a 'computer language' vs a 'data language'. It's not central to my point.

I'm [not really] sorry, but you might want to read "this" yourself before using it as an argument.

I'll just quote two parts here (emphasis mine where you see ***********) :

"A programming language is a formal language, which comprises a set of instructions **********that produce various kinds of output**********. Programming languages are used in computer programming to implement algorithms."

"A programming language is a notation for writing programs, **********which are specifications of a computation or algorithm**********."

What "various kinds of output" are produced by, or which "algorithms are implemented" by, say, the text snippet "IS_EMPTY(R1 JOIN R2)" ?

What "computation or algorithm" is specified by "IS_EMPTY(R1 JOIN R2)" ?

Hint 1 : While the text snippet "ADD DATABASECONSTRAINT,RELATION(TUPLE(CONSTRAINTLABEL(...)CONSTRAINTEXPRESSIONTEXT(...)ERRORCODE(...)))" is arguably a reasonable textual representation of something that can be seen as "an instruction that produces output" (a newly defined constraint in the catalog), that text snippet is manifestly not the same thing as the text snippet that is just the logical definition of the constraint.  Throwing all those things all on one big pile is exactly the misinterpretation of Reeves 1992 of which he later wrote that "that one made him particularly angry". ...

[going off topic a bit. I'd not seen the Reeves pieces before. Food for thought. The "angry" is here after para B, or top of page 14 in the .pdf combined 3 docos.]

Hint 2 : The suggested algorithm "compute the join and see if it is empty or not" is manifestly not the algorithm carried out by the constraint enforcement machinery of you-know-which-system.

Reeves is saying that the resulting program code represents the final design; even if other artefacts/documentation are produced during/alongside in the design process.

In case of designing Relational schema, I want to say there is code that does represent design; but it's the Predicate-logic code, not the programming language code. In particular, SQL is so limited in what you can encode about the logic in your schema, it's impossible to represent the design in SQL (even if we yeuch put extra stuff in triggers and stored procedures).

So something like "IS_EMPTY(R1 JOIN R2)" I want to say is for more Predicate than programming language. Especially because that JOIN is an SQL NATURAL JOIN and many vendors don't support NatJoin; and anyway you'll have a hard time trying to encode a NatJoin into a constraint.

Multiply that up for a schema of many hundreds of base relvars; and many thousands of virtuals; and many tens of thousands of contraints, probably half of which can't/don't get encoded anywhere visible. Then I want to say the program code is almost certainly wrong. By "wrong" I mean doesn't conform to the design. By "design" I mean the Predicates required to hold in the schema.

Except of course designers never write down the schema as Predicates/never encode it in a logic tool. Because SQL.

Quote from p c on March 13, 2020, 3:20 pm

Talk of what algorithm syntax such as IS-EMPTY(...) expressees is as off-target as most mentions of constraints here.  From a logical viewpoint database constraints are merely premises of arguments. Yet it is rare to ever see universal quantification which Codd gave a simple algebra for, used in the most obvious way, to express such a premise.

Likewise confused is “...Obviously all constraints can be converted to Boolean expressions which constrain a database as a whole, and these in turn can be converted to a single constraint per database. Nothing else is logically necessary….”

Well, nothing else is logically necessary except for the rest of the logical argument of course.

One of my all-time favourite posts was in response to this comment: “In this group, a requirement for such a different use might likely be sloppily expressed as 'deleting only one side of a join'. What has never been understood by the posters here is how their approach is sabotaged by the simplistic view definitions, and therefore predicates, they choose such as S JOIN SP so the predicate reflected can never be accurate for their purpose. They are unable to synthesize the predicates they need and therfore the view defnitions they need so as to overcome the twin obstacles of relvars and normalized storage structures. They duplicate the same error the SQL world makes, assuming physical artifacts such as tables and relvars accurately reflect predicates as opposed to merely reflecting extensions. They must be physical because there are no such things as tables and relvars that set operators and their equivalent logical connectives can operate on.”

A college instructor replies:

“Here's a simplified part of a billing system, written in Tutorial D:

1. VAR InvoiceHeading REAL RELATION {InvoiceNumber INT, InvoiceDate Date, CustomerID CHAR} KEY {InvoiceNumber};
2. VAR InvoiceDetail REAL RELATION {InvoiceNumber INT, ProductCode CHAR, Qty INT} KEY {InvoiceNumber, ProductCode};
4. CONSTRAINT InvoiceDetail_FK1 InvoiceDetail {InvoiceNumber} ⊆ InvoiceHeading {InvoiceNumber};
6. VAR Invoices VIEW InvoiceHeading JOIN InvoiceDetail

“We can assume there would also be, at least, relvars and corresponding constraints for customers and products, which for simplicity's sake are not shown here.

“Suppose the view Invoices is used to present invoices on some user interface. If the user deletes a tuple from Invoices, what should happen?

“Alternatively, if this schema is undesirable, how should it be changed?

“In other words, if there are issues that have "never been understood by the posters here", what do we need to understand?

“Please be specific and as clear and logical as possible, and use examples.”

To be blunt, this college instructor needs to understand that a relational database language need only  express nothing but logical arguments and that to be logically valid a logical argument requires both premise(s) and conclusion{s). In this example, a premise is given, so-called negation of a tuple, without a conclusion. Students should recognize this as a silly question, just as Codd would have.

in other words, no matter whether query or update, illogical arguments have no useful results.

Logical validity does not require true premises, a valid argument is true by definition. Obviously, a database management system needs some mechanism for making a premise permanently true. One traditional mechanism is a file system recording, such as TTM assignment.

Five minutes with pencil and paper will show that it is not logically valid to assume some unknown conclusion by specifying only the foreign key constraint unless a D language allows the specification of a conclusion there is no point in wondering about undesirable schemas.

Assume the sets of things you want to relate are called C, D and E and they have a common property x,, parameter, attribute value, or license number if you like, so that if D or E has the property C must have it too but no more than  one of D or E may have the property.

So assume that C may or may not have the property and quantify it, as in Forall x (C has the property x and no more than one of D and E have it ) ie:

(C & - (C&-(E  & D)))

That's a premise.

Maybe you want to express the argument (E)  > (-D ), meaning that when E has the property, D does not. That's a conclusion.

(C & - (C&-(E  & D))) > (E) > (-D ) happens to be a logically  valid argument.

Whatever mechanism a system might use to assert that E has the property that same system if it is relational should be able to assert the negation of D having the property without needing any other user instruction.

A valid argument to assert that a car is unassigned would be 

(C & - (C&-(E  & D))) > (-D&-E) > C.

Note that it is just as valid to negate C in this almost identical argument:

(C & - (C&-(E  & D))) > (-D&-E) > -C.

(corrected typo in the above line to show conclusion that negates C)

 

 

 

 

 

Quote from Dave Voorhis on March 13, 2020, 3:43 pm

Quote from p c on March 13, 2020, 3:20 pm

Talk of what algorithm syntax such as IS-EMPTY(...) expressees is as off-target as most mentions of constraints here.  From a logical viewpoint database constraints are merely premises of arguments. Yet it is rare to ever see universal quantification which Codd gave a simple algebra for, used in the most obvious way, to express such a premise.

Likewise confused is “...Obviously all constraints can be converted to Boolean expressions which constrain a database as a whole, and these in turn can be converted to a single constraint per database. Nothing else is logically necessary….”

Well, nothing else is logically necessary except for the rest of the logical argument of course.

One of my all-time favourite posts was in response to this comment: “In this group, a requirement for such a different use might likely be sloppily expressed as 'deleting only one side of a join'. What has never been understood by the posters here is how their approach is sabotaged by the simplistic view definitions, and therefore predicates, they choose such as S JOIN SP so the predicate reflected can never be accurate for their purpose. They are unable to synthesize the predicates they need and therfore the view defnitions they need so as to overcome the twin obstacles of relvars and normalized storage structures. They duplicate the same error the SQL world makes, assuming physical artifacts such as tables and relvars accurately reflect predicates as opposed to merely reflecting extensions. They must be physical because there are no such things as tables and relvars that set operators and their equivalent logical connectives can operate on.”

A college instructor replies:

“Here's a simplified part of a billing system, written in Tutorial D:

1. VAR InvoiceHeading REAL RELATION {InvoiceNumber INT, InvoiceDate Date, CustomerID CHAR} KEY {InvoiceNumber};
2. VAR InvoiceDetail REAL RELATION {InvoiceNumber INT, ProductCode CHAR, Qty INT} KEY {InvoiceNumber, ProductCode};
4. CONSTRAINT InvoiceDetail_FK1 InvoiceDetail {InvoiceNumber} ⊆ InvoiceHeading {InvoiceNumber};
6. VAR Invoices VIEW InvoiceHeading JOIN InvoiceDetail

“We can assume there would also be, at least, relvars and corresponding constraints for customers and products, which for simplicity's sake are not shown here.

“Suppose the view Invoices is used to present invoices on some user interface. If the user deletes a tuple from Invoices, what should happen?

“Alternatively, if this schema is undesirable, how should it be changed?

“In other words, if there are issues that have "never been understood by the posters here", what do we need to understand?

“Please be specific and as clear and logical as possible, and use examples.”

To be blunt, this college instructor needs to understand that a relational database language need only  express nothing but logical arguments and that to be logically valid a logical argument requires both premise(s) and conclusion{s). In this example, a premise is given, so-called negation of a tuple, without a conclusion. Students should recognize this as a silly question, just as Codd would have.

in other words, no matter whether query or update, illogical arguments have no useful results.

Logical validity does not require true premises, a valid argument is true by definition. Obviously, a database management system needs some mechanism for making a premise permanently true. One traditional mechanism is a file system recording, such as TTM assignment.

Five minutes with pencil and paper will show that it is not logically valid to assume some unknown conclusion by specifying only the foreign key constraint unless a D language allows the specification of a conclusion there is no point in wondering about undesirable schemas.

Assume the sets of things you want to relate are called C, D and E and they have a common property x,, parameter, attribute value, or license number if you like, so that if D or E has the property C must have it too but no more than  one of D or E may have the property.

So assume that C may or may not have the property and quantify it, as in Forall x (C has the property x and no more than one of D and E have it ) ie:

(C & - (C&-(E  & D)))

That's a premise.

Maybe you want to express the argument (E)  > (-D ), meaning that when E has the property, D does not. That's a conclusion.

(C & - (C&-(E  & D))) > (E) > (-D ) happens to be a logically  valid argument.

Whatever mechanism a system might use to assert that E has the property that same system if it is relational should be able to assert the negation of D having the property without needing any other user instruction.

A valid argument to assert that a car is unassigned would be 

(C & - (C&-(E  & D))) > (-D&-E) > C.

Note that it is just as valid to negate C in this almost identical argument:

(C & - (C&-(E  & D))) > (-D&-E) > C.

If there's a point in there somewhere, I can't find it.

I can't find anything remotely like an answer to the questions I raised in the post of mine you quoted, either.

Quote from AntC on March 14, 2020, 7:43 am

Quote from Dave Voorhis on March 13, 2020, 3:43 pm

Quote from p c on March 13, 2020, 3:20 pm

... From a logical viewpoint database constraints are merely premises of arguments. ...

If there's a point in there somewhere, I can't find it.

...

+1.

Quote from Erwin on March 14, 2020, 7:17 pm

Quote from Dave Voorhis on March 13, 2020, 3:43 pm

Quote from p c on March 13, 2020, 3:20 pm

Talk of what algorithm syntax such as IS-EMPTY(...) expressees is as off-target as most mentions of constraints here.  From a logical viewpoint database constraints are merely premises of arguments. Yet it is rare to ever see universal quantification which Codd gave a simple algebra for, used in the most obvious way, to express such a premise.

Likewise confused is “...Obviously all constraints can be converted to Boolean expressions which constrain a database as a whole, and these in turn can be converted to a single constraint per database. Nothing else is logically necessary….”

Well, nothing else is logically necessary except for the rest of the logical argument of course.

One of my all-time favourite posts was in response to this comment: “In this group, a requirement for such a different use might likely be sloppily expressed as 'deleting only one side of a join'. What has never been understood by the posters here is how their approach is sabotaged by the simplistic view definitions, and therefore predicates, they choose such as S JOIN SP so the predicate reflected can never be accurate for their purpose. They are unable to synthesize the predicates they need and therfore the view defnitions they need so as to overcome the twin obstacles of relvars and normalized storage structures. They duplicate the same error the SQL world makes, assuming physical artifacts such as tables and relvars accurately reflect predicates as opposed to merely reflecting extensions. They must be physical because there are no such things as tables and relvars that set operators and their equivalent logical connectives can operate on.”

A college instructor replies:

“Here's a simplified part of a billing system, written in Tutorial D:

1. VAR InvoiceHeading REAL RELATION {InvoiceNumber INT, InvoiceDate Date, CustomerID CHAR} KEY {InvoiceNumber};
2. VAR InvoiceDetail REAL RELATION {InvoiceNumber INT, ProductCode CHAR, Qty INT} KEY {InvoiceNumber, ProductCode};
4. CONSTRAINT InvoiceDetail_FK1 InvoiceDetail {InvoiceNumber} ⊆ InvoiceHeading {InvoiceNumber};
6. VAR Invoices VIEW InvoiceHeading JOIN InvoiceDetail

“We can assume there would also be, at least, relvars and corresponding constraints for customers and products, which for simplicity's sake are not shown here.

“Suppose the view Invoices is used to present invoices on some user interface. If the user deletes a tuple from Invoices, what should happen?

“Alternatively, if this schema is undesirable, how should it be changed?

“In other words, if there are issues that have "never been understood by the posters here", what do we need to understand?

“Please be specific and as clear and logical as possible, and use examples.”

To be blunt, this college instructor needs to understand that a relational database language need only  express nothing but logical arguments and that to be logically valid a logical argument requires both premise(s) and conclusion{s). In this example, a premise is given, so-called negation of a tuple, without a conclusion. Students should recognize this as a silly question, just as Codd would have.

in other words, no matter whether query or update, illogical arguments have no useful results.

Logical validity does not require true premises, a valid argument is true by definition. Obviously, a database management system needs some mechanism for making a premise permanently true. One traditional mechanism is a file system recording, such as TTM assignment.

Five minutes with pencil and paper will show that it is not logically valid to assume some unknown conclusion by specifying only the foreign key constraint unless a D language allows the specification of a conclusion there is no point in wondering about undesirable schemas.

Assume the sets of things you want to relate are called C, D and E and they have a common property x,, parameter, attribute value, or license number if you like, so that if D or E has the property C must have it too but no more than  one of D or E may have the property.

So assume that C may or may not have the property and quantify it, as in Forall x (C has the property x and no more than one of D and E have it ) ie:

(C & - (C&-(E  & D)))

That's a premise.

Maybe you want to express the argument (E)  > (-D ), meaning that when E has the property, D does not. That's a conclusion.

(C & - (C&-(E  & D))) > (E) > (-D ) happens to be a logically  valid argument.

Whatever mechanism a system might use to assert that E has the property that same system if it is relational should be able to assert the negation of D having the property without needing any other user instruction.

A valid argument to assert that a car is unassigned would be 

(C & - (C&-(E  & D))) > (-D&-E) > C.

Note that it is just as valid to negate C in this almost identical argument:

(C & - (C&-(E  & D))) > (-D&-E) > C.

If there's a point in there somewhere, I can't find it.

I can't find anything remotely like an answer to the questions I raised in the post of mine you quoted, either.

We're all completely confused, we're all completely ignorant and complete fools, the only one(s) who truly understands the RM were Codd and the trained logicians who have been lucky enough to cooperate closely with him for some time (Date is not such a "trained logician") and the first thing we need to do is clear our heads from everything we thought we knew and only then will complete imbeciles like all of us stand any chance of ever "getting the point, which is that the rules are made by logic".

Where have I seen such talk before ?

BTW "getting the point" also means we can grasp the idea of C, D and E being "sets of things we want to relate" and then see formulae such as "D & E" and "-(D&E)" and then have the aha erlebnis of our lives.  Or see it declared that 'x' is some arbitrary property where it is not even made explicitly clear whether x is a property of the things in those sets or of those sets themselves and then see universal quantifications such as "forall x" and we're not allowed to wonder something like, wait, what, universal quantification over all possible properties, what is that even going to mean, no it should all be readily obvious.

Thanks but no thanks.