The second line uses S as a monadic (1-place) predicate on tuples. It should be S( S#,P#,QTY ). (You could *define* monadic S to mean the ternary S. You could use only monadic S. But you seem to be undecided between tuple-calculus and domain-calculus styles of FOPL.)
> (< S#,P#,QTY1 > | SUPPLIES)
You mean S( S#,P#,QTY1 ) or (< S#,P#,QTY1 > IN SUPPLIES).
> "the predicate can be added as a conjunct to the S() predicate"
What you mean here, as shown by the expressions you give, is that a first predicate is combined with or expressed in terms of the S predicate. Not "conjoined". (When the first predicates are constraints, they are just true statements, so conjoining with S gives another predicate expression that means exactly what S means.)
This uses a shorthand that quantifies over expressions other than symbols, OK. But there's no need to do that, because you could just write FORALL S#,P#,QTY1,QTY2 [ ... ].
Your OR NOT can be written via IMPLIES: FORALL ... [ S( S#,P#,QTY1 ) AND S ( S#,P#,QTY2 ) IMPLIES (...) ] or FORALL ... [ < S#,P#,QTY1 > IN SUPPLIES AND < S#,P#,QTY2 > IN SUPPLIES IMPLIES (...) ] which is closer to one intuitive phrasing, "if two tuples < S#,P#,QTY1 > AND < S#,P#,QTY2 > are in SUPPLIES then ... . Notice that tuples-IN-SUPPLIES is expressed by forming a tuple from the attributes in the expression part of the FORALL (in your version and mine). Not in the list preceding it.
It would be more helpful if your expositions more clearly and explicitly distinguished between different notions of "meaning"/"semantics"--that for base (and query) predicates; that for constraints; and that for relation propositions--and between them and the business rules. Eg *some* business rules are database constraints. Eg some aren't--like that each supplier has a unique identifying supplier#, or that SUPPLIERS has predicate S(...). Eg constraints describe in terms of the base predicates what database states can arise given the business rules (including those that say what the base predicates are).
> tertiary (3-place) FOPL predicate: S( S#,P#,QTY )
ReplyDelete> S( < S#,P#,QTY1 > ) AND ...
The second line uses S as a monadic (1-place) predicate on tuples. It should be S( S#,P#,QTY ). (You could *define* monadic S to mean the ternary S. You could use only monadic S. But you seem to be undecided between tuple-calculus and domain-calculus styles of FOPL.)
> (< S#,P#,QTY1 > | SUPPLIES)
You mean S( S#,P#,QTY1 ) or (< S#,P#,QTY1 > IN SUPPLIES).
> "the predicate can be added as a conjunct to the S() predicate"
What you mean here, as shown by the expressions you give, is that a first predicate is combined with or expressed in terms of the S predicate. Not "conjoined". (When the first predicates are constraints, they are just true statements, so conjoining with S gives another predicate expression that means exactly what S means.)
> FORALL ( < S#,P#,QTY1 > ), ( < S#,P#,QTY2 > ) [ ... ]
This uses a shorthand that quantifies over expressions other than symbols, OK. But there's no need to do that, because you could just write FORALL S#,P#,QTY1,QTY2 [ ... ].
Your OR NOT can be written via IMPLIES:
FORALL ... [
S( S#,P#,QTY1 ) AND S ( S#,P#,QTY2 ) IMPLIES (...)
]
or
FORALL ... [
< S#,P#,QTY1 > IN SUPPLIES
AND < S#,P#,QTY2 > IN SUPPLIES
IMPLIES (...)
]
which is closer to one intuitive phrasing, "if two tuples < S#,P#,QTY1 > AND < S#,P#,QTY2 > are in SUPPLIES then ... . Notice that tuples-IN-SUPPLIES is expressed by forming a tuple from the attributes in the expression part of the FORALL (in your version and mine). Not in the list preceding it.
It would be more helpful if your expositions more clearly and explicitly distinguished between different notions of "meaning"/"semantics"--that for base (and query) predicates; that for constraints; and that for relation propositions--and between them and the business rules. Eg *some* business rules are database constraints. Eg some aren't--like that each supplier has a unique identifying supplier#, or that SUPPLIERS has predicate S(...). Eg constraints describe in terms of the base predicates what database states can arise given the business rules (including those that say what the base predicates are).
ReplyDelete