Clarification re local relvar and KEY

#1 · June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:

VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]

Andl - A New Database Language - andl.org

#2 · June 3, 2020, 10:25 am

Quote from dandl on June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:

VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]

In Rel, two tuples with the same key throws an error. Given:

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};

It will emit:

ERROR: RS0232: Assigning tuple would violate uniqueness constraint of KEY {X}

PRIVATE specifies that var is a non-catalog or local relvar, though I suppose it could as easily be an optional keyword with the same semantics in its absence. Per DTATRM Chapter 4, RM Pre 14: "A private relvar shall be an application relvar that is completely private to the application in question and is not part of any database. Defining a private relvar V shall have the effect of initializing V to some value -- either a value specified explicitly as part of the operation that defines V or an empty relation if no such explicit value is specified."

I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org

#3 · June 3, 2020, 11:01 am

Quote from Erwin on June 3, 2020, 11:01 am
Quote from Dave Voorhis on June 3, 2020, 10:25 am
Quote from dandl on June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:
VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]
In Rel, two tuples with the same key throws an error. Given:

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
It will emit:

ERROR: RS0232: Assigning tuple would violate uniqueness constraint of KEY {X}

PRIVATE specifies that var is a non-catalog or local relvar, though I suppose it could as easily be an optional keyword with the same semantics in its absence. Per DTATRM Chapter 4, RM Pre 14: "A private relvar shall be an application relvar that is completely private to the application in question and is not part of any database. Defining a private relvar V shall have the effect of initializing V to some value -- either a value specified explicitly as part of the operation that defines V or an empty relation if no such explicit value is specified."
As a side thought : what about other constraints that are single-relvar (e.g. a referential constraint that references the self) but not keys ?

Can those constraints be declared too (via CONSTRAINT) ? (That would then behave a little bit like assertions for the purpose of debugging.) (PS the question is Tutorial D not Rel.)

It certainly makes no sense to include any local relvar in a ***database*** constraint because by definition the constraint would then no longer be a ***database*** constraint. Ditto for transition constraints because the term itself says it's a constraint scoped on (pre and post) ***database*** states.

Quote from Dave Voorhis on June 3, 2020, 10:25 am
Quote from dandl on June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:
VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]
In Rel, two tuples with the same key throws an error. Given:

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
It will emit:

ERROR: RS0232: Assigning tuple would violate uniqueness constraint of KEY {X}

PRIVATE specifies that var is a non-catalog or local relvar, though I suppose it could as easily be an optional keyword with the same semantics in its absence. Per DTATRM Chapter 4, RM Pre 14: "A private relvar shall be an application relvar that is completely private to the application in question and is not part of any database. Defining a private relvar V shall have the effect of initializing V to some value -- either a value specified explicitly as part of the operation that defines V or an empty relation if no such explicit value is specified."

As a side thought : what about other constraints that are single-relvar (e.g. a referential constraint that references the self) but not keys ?

Can those constraints be declared too (via CONSTRAINT) ? (That would then behave a little bit like assertions for the purpose of debugging.) (PS the question is Tutorial D not Rel.)

It certainly makes no sense to include any local relvar in a ***database*** constraint because by definition the constraint would then no longer be a ***database*** constraint. Ditto for transition constraints because the term itself says it's a constraint scoped on (pre and post) ***database*** states.

Author of SIRA_PRISE

#4 · June 3, 2020, 11:36 am

Quote from dandl on June 3, 2020, 11:36 am
Quote from Dave Voorhis on June 3, 2020, 10:25 am
Quote from dandl on June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:
VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]
In Rel, two tuples with the same key throws an error. Given:

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
It will emit:

ERROR: RS0232: Assigning tuple would violate uniqueness constraint of KEY {X}

PRIVATE specifies that var is a non-catalog or local relvar, though I suppose it could as easily be an optional keyword with the same semantics in its absence. Per DTATRM Chapter 4, RM Pre 14: "A private relvar shall be an application relvar that is completely private to the application in question and is not part of any database. Defining a private relvar V shall have the effect of initializing V to some value -- either a value specified explicitly as part of the operation that defines V or an empty relation if no such explicit value is specified."
Yes, I read all that. It just never says what is supposed to happen.

Is it also true that the following are identical in effect?

VAR SS PRIVATE REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER}

VAR SS PRIVATE INIT ( REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER} { } )

The point is that AFAICT this is the only situation where a heading is declared with a type: either declaring a non-scalar variable or creating an empty relation (value). Everywhere else headings are defined by name and the type is inferred from a value. [In the example I gave earlier, the type of STATUS is inferred, not stated.]

Quote from Dave Voorhis on June 3, 2020, 10:25 am
Quote from dandl on June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:
VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]
In Rel, two tuples with the same key throws an error. Given:

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
It will emit:

ERROR: RS0232: Assigning tuple would violate uniqueness constraint of KEY {X}

PRIVATE specifies that var is a non-catalog or local relvar, though I suppose it could as easily be an optional keyword with the same semantics in its absence. Per DTATRM Chapter 4, RM Pre 14: "A private relvar shall be an application relvar that is completely private to the application in question and is not part of any database. Defining a private relvar V shall have the effect of initializing V to some value -- either a value specified explicitly as part of the operation that defines V or an empty relation if no such explicit value is specified."

Yes, I read all that. It just never says what is supposed to happen.

Is it also true that the following are identical in effect?

VAR SS PRIVATE REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER}

VAR SS PRIVATE INIT ( REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER} { } )

The point is that AFAICT this is the only situation where a heading is declared with a type: either declaring a non-scalar variable or creating an empty relation (value). Everywhere else headings are defined by name and the type is inferred from a value. [In the example I gave earlier, the type of STATUS is inferred, not stated.]

Andl - A New Database Language - andl.org

#5 · June 3, 2020, 1:21 pm

Quote from Dave Voorhis on June 3, 2020, 1:21 pm
Quote from dandl on June 3, 2020, 11:36 am
Quote from Dave Voorhis on June 3, 2020, 10:25 am
Quote from dandl on June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:
VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]
In Rel, two tuples with the same key throws an error. Given:

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
It will emit:

ERROR: RS0232: Assigning tuple would violate uniqueness constraint of KEY {X}

PRIVATE specifies that var is a non-catalog or local relvar, though I suppose it could as easily be an optional keyword with the same semantics in its absence. Per DTATRM Chapter 4, RM Pre 14: "A private relvar shall be an application relvar that is completely private to the application in question and is not part of any database. Defining a private relvar V shall have the effect of initializing V to some value -- either a value specified explicitly as part of the operation that defines V or an empty relation if no such explicit value is specified."
Yes, I read all that. It just never says what is supposed to happen.
Like much of Tutorial D, it's intended for illustration, so if behaviour isn't obvious by illustration or otherwise explicitly specified, it's up to the implementer.

...Noting of course, that there was never really expected to be an implementer -- it was intended for written illustration -- so anything that isn't obvious by illustration or otherwise explicitly specified... Isn't.

Is it also true that the following are identical in effect?

VAR SS PRIVATE REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER}

VAR SS PRIVATE INIT ( REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER} { } )

They're both missing the mandatory KEY specification -- e.g., KEY {S#} -- but otherwise identical.

The point is that AFAICT this is the only situation where a heading is declared with a type: either declaring a non-scalar variable or creating an empty relation (value). Everywhere else headings are defined by name and the type is inferred from a value. [In the example I gave earlier, the type of STATUS is inferred, not stated.]

Everywhere a type declaration is expected -- except parameter declarations, I think -- in Tutorial D, it may be manifest (e.g., STATUS INTEGER) or inferred (STATUS 20).

Quote from dandl on June 3, 2020, 11:36 am
Quote from Dave Voorhis on June 3, 2020, 10:25 am
Quote from dandl on June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:
VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]
In Rel, two tuples with the same key throws an error. Given:

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
It will emit:

ERROR: RS0232: Assigning tuple would violate uniqueness constraint of KEY {X}

PRIVATE specifies that var is a non-catalog or local relvar, though I suppose it could as easily be an optional keyword with the same semantics in its absence. Per DTATRM Chapter 4, RM Pre 14: "A private relvar shall be an application relvar that is completely private to the application in question and is not part of any database. Defining a private relvar V shall have the effect of initializing V to some value -- either a value specified explicitly as part of the operation that defines V or an empty relation if no such explicit value is specified."
Yes, I read all that. It just never says what is supposed to happen.

Like much of Tutorial D, it's intended for illustration, so if behaviour isn't obvious by illustration or otherwise explicitly specified, it's up to the implementer.

...Noting of course, that there was never really expected to be an implementer -- it was intended for written illustration -- so anything that isn't obvious by illustration or otherwise explicitly specified... Isn't.

Is it also true that the following are identical in effect?

VAR SS PRIVATE REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER}

VAR SS PRIVATE INIT ( REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER} { } )

They're both missing the mandatory KEY specification -- e.g., KEY {S#} -- but otherwise identical.

The point is that AFAICT this is the only situation where a heading is declared with a type: either declaring a non-scalar variable or creating an empty relation (value). Everywhere else headings are defined by name and the type is inferred from a value. [In the example I gave earlier, the type of STATUS is inferred, not stated.]

Everywhere a type declaration is expected -- except parameter declarations, I think -- in Tutorial D, it may be manifest (e.g., STATUS INTEGER) or inferred (STATUS 20).

I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org

#6 · June 3, 2020, 2:25 pm

Quote from dandl on June 3, 2020, 2:25 pm
Quote from Dave Voorhis on June 3, 2020, 1:21 pm
Quote from dandl on June 3, 2020, 11:36 am
Quote from Dave Voorhis on June 3, 2020, 10:25 am
Quote from dandl on June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:
VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]
In Rel, two tuples with the same key throws an error. Given:

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
It will emit:

ERROR: RS0232: Assigning tuple would violate uniqueness constraint of KEY {X}

PRIVATE specifies that var is a non-catalog or local relvar, though I suppose it could as easily be an optional keyword with the same semantics in its absence. Per DTATRM Chapter 4, RM Pre 14: "A private relvar shall be an application relvar that is completely private to the application in question and is not part of any database. Defining a private relvar V shall have the effect of initializing V to some value -- either a value specified explicitly as part of the operation that defines V or an empty relation if no such explicit value is specified."
Yes, I read all that. It just never says what is supposed to happen.
Like much of Tutorial D, it's intended for illustration, so if behaviour isn't obvious by illustration or otherwise explicitly specified, it's up to the implementer.
I get that, but surely somewhere there was room for a hint? In any case, it seems a rather unuseful thing. And...

...Noting of course, that there was never really expected to be an implementer -- it was intended for written illustration -- so anything that isn't obvious by illustration or otherwise explicitly specified... Isn't.

Is it also true that the following are identical in effect?

VAR SS PRIVATE REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER}

VAR SS PRIVATE INIT ( REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER} { } )

They're both missing the mandatory KEY specification -- e.g., KEY {S#} -- but otherwise identical.

The spec says:

The syntactic category <xyz list> denotes a sequence of zero or more <xyz>s in which adjacent <xyz>s
are separated by one or more “white space” characters.

An empty <key def list> is equivalent to a <key def list> of the form KEY {ALL BUT}.

I read that as allowing an empty list, ie not mandatory.

The point is that AFAICT this is the only situation where a heading is declared with a type: either declaring a non-scalar variable or creating an empty relation (value). Everywhere else headings are defined by name and the type is inferred from a value. [In the example I gave earlier, the type of STATUS is inferred, not stated.]

Everywhere a type declaration is expected -- except parameter declarations, I think -- in Tutorial D, it may be manifest (e.g., STATUS INTEGER) or inferred (STATUS 20).

I'm only concerned with headings and the implications of MR Pre 18. AFAICT, headings are mostly constructed from names and values, not types. Although RM Pre 9 (and other places) mentions declared attribute type, the types in question are mostly not declared, they are inferred from values as supplied. Two exceptions I can see: empty relations and as part of an operator declaration.

Headings turn up a lot in the RA, but as (attribute) names, not types. Think rename, project, join, union, etc. But again, where a new attribute is added (extend, summarize), the type is inferred from the value, not set by a declaration.

I'm not sure whether this leads anywhere, just thinking out loud.

Quote from Dave Voorhis on June 3, 2020, 1:21 pm
Quote from dandl on June 3, 2020, 11:36 am
Quote from Dave Voorhis on June 3, 2020, 10:25 am
Quote from dandl on June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:
VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]
In Rel, two tuples with the same key throws an error. Given:

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
It will emit:

ERROR: RS0232: Assigning tuple would violate uniqueness constraint of KEY {X}

PRIVATE specifies that var is a non-catalog or local relvar, though I suppose it could as easily be an optional keyword with the same semantics in its absence. Per DTATRM Chapter 4, RM Pre 14: "A private relvar shall be an application relvar that is completely private to the application in question and is not part of any database. Defining a private relvar V shall have the effect of initializing V to some value -- either a value specified explicitly as part of the operation that defines V or an empty relation if no such explicit value is specified."
Yes, I read all that. It just never says what is supposed to happen.
Like much of Tutorial D, it's intended for illustration, so if behaviour isn't obvious by illustration or otherwise explicitly specified, it's up to the implementer.

I get that, but surely somewhere there was room for a hint? In any case, it seems a rather unuseful thing. And...

...Noting of course, that there was never really expected to be an implementer -- it was intended for written illustration -- so anything that isn't obvious by illustration or otherwise explicitly specified... Isn't.

Is it also true that the following are identical in effect?

VAR SS PRIVATE REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER}

VAR SS PRIVATE INIT ( REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER} { } )

They're both missing the mandatory KEY specification -- e.g., KEY {S#} -- but otherwise identical.

The spec says:

The syntactic category <xyz list> denotes a sequence of zero or more <xyz>s in which adjacent <xyz>s
are separated by one or more “white space” characters.

An empty <key def list> is equivalent to a <key def list> of the form KEY {ALL BUT}.

I read that as allowing an empty list, ie not mandatory.

The point is that AFAICT this is the only situation where a heading is declared with a type: either declaring a non-scalar variable or creating an empty relation (value). Everywhere else headings are defined by name and the type is inferred from a value. [In the example I gave earlier, the type of STATUS is inferred, not stated.]

Everywhere a type declaration is expected -- except parameter declarations, I think -- in Tutorial D, it may be manifest (e.g., STATUS INTEGER) or inferred (STATUS 20).

I'm only concerned with headings and the implications of MR Pre 18. AFAICT, headings are mostly constructed from names and values, not types. Although RM Pre 9 (and other places) mentions declared attribute type, the types in question are mostly not declared, they are inferred from values as supplied. Two exceptions I can see: empty relations and as part of an operator declaration.

Headings turn up a lot in the RA, but as (attribute) names, not types. Think rename, project, join, union, etc. But again, where a new attribute is added (extend, summarize), the type is inferred from the value, not set by a declaration.

I'm not sure whether this leads anywhere, just thinking out loud.

Andl - A New Database Language - andl.org

#7 · June 3, 2020, 2:39 pm

Clearly a database constraint can't reference a private relvar but a question arises in my mind as to whether a constraint declared on a private relvar can reference a database relvar. I'm thinking of inclusion dependencies (e.g., foreign keys), for example.

I agree with dandl that such matters can be regarded as "implementation defined" (thank goodness!)

Hugh

Coauthor of The Third Manifesto and related books.

#8 · June 3, 2020, 3:38 pm

Quote from Dave Voorhis on June 3, 2020, 3:38 pm
Quote from dandl on June 3, 2020, 2:25 pm
Quote from Dave Voorhis on June 3, 2020, 1:21 pm
Quote from dandl on June 3, 2020, 11:36 am
Quote from Dave Voorhis on June 3, 2020, 10:25 am
Quote from dandl on June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:
VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]
In Rel, two tuples with the same key throws an error. Given:

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
It will emit:

ERROR: RS0232: Assigning tuple would violate uniqueness constraint of KEY {X}

PRIVATE specifies that var is a non-catalog or local relvar, though I suppose it could as easily be an optional keyword with the same semantics in its absence. Per DTATRM Chapter 4, RM Pre 14: "A private relvar shall be an application relvar that is completely private to the application in question and is not part of any database. Defining a private relvar V shall have the effect of initializing V to some value -- either a value specified explicitly as part of the operation that defines V or an empty relation if no such explicit value is specified."
Yes, I read all that. It just never says what is supposed to happen.
Like much of Tutorial D, it's intended for illustration, so if behaviour isn't obvious by illustration or otherwise explicitly specified, it's up to the implementer.
I get that, but surely somewhere there was room for a hint? In any case, it seems a rather unuseful thing. And...
It serves the usual purpose of a KEY constraint, doesn't it?

And thus should exhibit the usual behaviour, no?

...Noting of course, that there was never really expected to be an implementer -- it was intended for written illustration -- so anything that isn't obvious by illustration or otherwise explicitly specified... Isn't.

Is it also true that the following are identical in effect?

VAR SS PRIVATE REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER}

VAR SS PRIVATE INIT ( REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER} { } )

They're both missing the mandatory KEY specification -- e.g., KEY {S#} -- but otherwise identical.

The spec says:

The syntactic category <xyz list> denotes a sequence of zero or more <xyz>s in which adjacent <xyz>s
are separated by one or more “white space” characters.

An empty <key def list> is equivalent to a <key def list> of the form KEY {ALL BUT}.

I read that as allowing an empty list, ie not mandatory.

Now that you mention it, I dimly recall that at some point in the evolution of Tutorial D it changed from a mandatory KEY to an optional KEY where its absence is equivalent to KEY {ALL BUT}. I'm sure I had some good reason for not implementing it in Rel at the time but I don't recall what that might be.

The point is that AFAICT this is the only situation where a heading is declared with a type: either declaring a non-scalar variable or creating an empty relation (value). Everywhere else headings are defined by name and the type is inferred from a value. [In the example I gave earlier, the type of STATUS is inferred, not stated.]

Everywhere a type declaration is expected -- except parameter declarations, I think -- in Tutorial D, it may be manifest (e.g., STATUS INTEGER) or inferred (STATUS 20).

I'm only concerned with headings and the implications of MR Pre 18. AFAICT, headings are mostly constructed from names and values, not types. Although RM Pre 9 (and other places) mentions declared attribute type, the types in question are mostly not declared, they are inferred from values as supplied. Two exceptions I can see: empty relations and as part of an operator declaration.

Headings turn up a lot in the RA, but as (attribute) names, not types. Think rename, project, join, union, etc. But again, where a new attribute is added (extend, summarize), the type is inferred from the value, not set by a declaration.

I'm not sure whether this leads anywhere, just thinking out loud.

Types appear to be inferred where possible; types are manifest where not.

Quote from dandl on June 3, 2020, 2:25 pm
Quote from Dave Voorhis on June 3, 2020, 1:21 pm
Quote from dandl on June 3, 2020, 11:36 am
Quote from Dave Voorhis on June 3, 2020, 10:25 am
Quote from dandl on June 3, 2020, 8:48 am

Although I can't find a specific example, my reading of the grammar says that this should be valid:
VAR SS PRIVATE INIT ( REL { TUP { S# S#('S1'), SNAME NAME('Smith'), STATUS 20, CITY 'London' } } KEY { S# } ;
VAR RR PRIVATE INIT (<any relational expression with a K attribute>) KEY { K } ;

What effect does the KEY declaration have, in case two tuples have the same key?

[In passing, the word PRIVATE seems unnecessary -- other variable declarations do not have it, it could easily be the default for consistency.]
In Rel, two tuples with the same key throws an error. Given:

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};

VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
VAR SS PRIVATE INIT(REL {TUP {X 1, Y 1}, TUP {X 1, Y 2}}) KEY {X};
It will emit:

ERROR: RS0232: Assigning tuple would violate uniqueness constraint of KEY {X}

PRIVATE specifies that var is a non-catalog or local relvar, though I suppose it could as easily be an optional keyword with the same semantics in its absence. Per DTATRM Chapter 4, RM Pre 14: "A private relvar shall be an application relvar that is completely private to the application in question and is not part of any database. Defining a private relvar V shall have the effect of initializing V to some value -- either a value specified explicitly as part of the operation that defines V or an empty relation if no such explicit value is specified."
Yes, I read all that. It just never says what is supposed to happen.
Like much of Tutorial D, it's intended for illustration, so if behaviour isn't obvious by illustration or otherwise explicitly specified, it's up to the implementer.
I get that, but surely somewhere there was room for a hint? In any case, it seems a rather unuseful thing. And...

It serves the usual purpose of a KEY constraint, doesn't it?

And thus should exhibit the usual behaviour, no?

...Noting of course, that there was never really expected to be an implementer -- it was intended for written illustration -- so anything that isn't obvious by illustration or otherwise explicitly specified... Isn't.

Is it also true that the following are identical in effect?

VAR SS PRIVATE REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER}

VAR SS PRIVATE INIT ( REL { S# S#, SNAME NAME, STATUS INTEGER, CITY CHARACTER} { } )

They're both missing the mandatory KEY specification -- e.g., KEY {S#} -- but otherwise identical.

The spec says:

The syntactic category <xyz list> denotes a sequence of zero or more <xyz>s in which adjacent <xyz>s
are separated by one or more “white space” characters.

An empty <key def list> is equivalent to a <key def list> of the form KEY {ALL BUT}.

I read that as allowing an empty list, ie not mandatory.

Now that you mention it, I dimly recall that at some point in the evolution of Tutorial D it changed from a mandatory KEY to an optional KEY where its absence is equivalent to KEY {ALL BUT}. I'm sure I had some good reason for not implementing it in Rel at the time but I don't recall what that might be.

The point is that AFAICT this is the only situation where a heading is declared with a type: either declaring a non-scalar variable or creating an empty relation (value). Everywhere else headings are defined by name and the type is inferred from a value. [In the example I gave earlier, the type of STATUS is inferred, not stated.]

Everywhere a type declaration is expected -- except parameter declarations, I think -- in Tutorial D, it may be manifest (e.g., STATUS INTEGER) or inferred (STATUS 20).

I'm only concerned with headings and the implications of MR Pre 18. AFAICT, headings are mostly constructed from names and values, not types. Although RM Pre 9 (and other places) mentions declared attribute type, the types in question are mostly not declared, they are inferred from values as supplied. Two exceptions I can see: empty relations and as part of an operator declaration.

Headings turn up a lot in the RA, but as (attribute) names, not types. Think rename, project, join, union, etc. But again, where a new attribute is added (extend, summarize), the type is inferred from the value, not set by a declaration.

I'm not sure whether this leads anywhere, just thinking out loud.

Types appear to be inferred where possible; types are manifest where not.

I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org

#9 · June 3, 2020, 9:20 pm

Quote from Dave Voorhis on June 3, 2020, 3:38 pm

... changed from a mandatory KEY to an optional KEY where its absence is equivalent to KEY {ALL BUT}. I'm sure I had some good reason for not implementing it in Rel at the time but I don't recall what that might be.

Count of available hands vs. perceived immediately materialisable benefits, no doubt.

Author of SIRA_PRISE

#10 · June 3, 2020, 9:28 pm

Quote from Hugh on June 3, 2020, 2:39 pm

Clearly a database constraint can't reference a private relvar but a question arises in my mind as to whether a constraint declared on a private relvar can reference a database relvar. I'm thinking of inclusion dependencies (e.g., foreign keys), for example.

I agree with dandl that such matters can be regarded as "implementation defined" (thank goodness!)

Hugh

If it can [reference a database relvar] then it must clearly be categorized as what I have come to call "assignment constraint", ***only and exclusively*** to be checked upon assignments to the private relvar, not upon assignments to the database relvar (which should be made impossible for ***database*** constraints because allowing to "override" such behaviour is like DOMAIN CHECK OVERRIDE (or what was it) ). TTM goes nowhere near far enough to make the distinction clear to its readers. imo. But at any rate it moves such constraints into realms that I believe are even beyond the VSS re. transition constraints.

Author of SIRA_PRISE

The Forum for Discussion about The Third Manifesto and Related Matters

Clarification re local relvar and KEY