What is the purpose of relations containing tuples/relations?
Quote from johnwcowan on June 13, 2019, 7:44 pmQuote from Erwin on June 13, 2019, 9:50 amAnd last but not least, outside the realm of base relvars : having (pun intended) GROUP and RVA's to one's avail, facilitates writing SQL stuff like "HAVING COUNT(*) > 1" as a regular WHERE. Hugh feels strongly about how this simplifies the language per se.
I don't understand this case; can you give a concrete example? Thanks.
Concrete example : ( SP GROUP ( {P#, QTY} as PARTS ) ) WHERE COUNT(PARTS) > 1
Try to find Hugh's paper "HAVING a blunderful time, or wish you were WHERE". Well, no, I've found it for you : https://www.dcs.warwick.ac.uk/~hugh/TTM/HAVING-A-Blunderful-Time.html .
Management summary : HAVING is semantically the very same thing as WHERE, but in practice ends up with a massively different set of rules attached compared to WHERE. Try teaching that to newcomers. And after they've been "taught" how it works, the epsilons get accustomed to it and even start arguing it's a good thing "because it works", or they try to come up with post-hoc justifications and explanations such as "WHERE filters input rows, HAVING filters produced rows". ( https://news.ycombinator.com/item?id=17390814 )
Quote from Dave Voorhis on June 15, 2019, 8:06 amNot just well-ploughed ground... We've worn a trench several feet deep.
In fact so many feet that it popped out again on the other side of earth and we failed hitting Anthony by no more than an inch :-)
Quote from johnwcowan on June 13, 2019, 7:44 pmQuote from Erwin on June 13, 2019, 9:50 amThe canonical example of where RVA's are "needed"/"inevitable" is a catalog relvar that records which keys each relvar has.
It gives propositions like "{A C} is a key to relvar X" and "{C H} is a key to relvar X".
The standard process of "flattening out" (replacing the set-level value with an identifier and listing the set contents in another relvar) can be applied, but unless you can find an identifier that caries business meaning, you are introducing surrogates in the design, which are then subsequently very likely to get exposed to the user
In this particular case, I think giving a key a user-visible name is a Good Thing so that it can be manipulated.
A second example I once came up with is recording the methods of a java class in a database. Note that a java method is identified (within a given class) by its "signature" which is the combination of its invocation name and the ordered list of parameter type declarations. The latter, when relationally modeled, becomes a relation with attributes "ordinal position" and "type name", and note that this relation is part of the identifier for a method.
I think that's a more compelling case, though modeling it as an array makes sense too, since the essence of arrays is that they are ordinally indexed and their size is not part of their type.
As for the relvar keys : In fact there ***is*** an identifier that carries "business" meaning, because if and when the system starts processing updates on the relvar that are subject to the defined keys, it is potentially going to have to report things like "violation of constraint XYZ detected" to the user. There you have your "name". Which is why SIRA_PRISE doesn't use RVA's after all for recording which keys apply.
The "java methods" example, otoh, parallels "D operators" (because after all a method is just an operator by another name), and SIRA_PRISE effectively uses RVA's in the structures that define which operators are available (though I no longer remember whether this was already so in the currently published version).
("array vs relation" is rather a non-argument, because an array ***is*** a function (and therefore a relation) from ordinal positions to whatever is in the array.)
Quote from Erwin on June 15, 2019, 12:28 pmQuote from AntC on June 14, 2019, 5:48 amNo you're not going to have your users directly updating the catalog using D statements. Because updating the catalog does not of itself create a relvar or alter its keys. There will be a CLI front-end that will build/update the relvar and generate the update statements to the catalog (under transaction control).
Funny. That's exactly what I do/did, and at some point in time when the forum was still on mail I learned that that's exactly what Hugh did in BS12 too. At least that's how I understood it.
Thanks Erwin. Um what's the referent of your "that's exactly"; and of Hugh/BS12's "that's exactly"? Are you saying SIRA_PRISE users do directly update the catalog, and that from observing the update, the DBMS infers what relvar/keys to create/amend/delete?
Or are you saying that SIRA_PRISE is like Tutorial D (and SQL) in using a CLI CREATE/ALTER TABLE ... KEY ... that generates the catalog updates as well creating/amending the relvar?
Why would Tutorial D use a different approach vs BS12 (if that's what you're saying)?
Quote from Dave Voorhis on June 15, 2019, 8:06 amQuote from AntC on June 15, 2019, 2:05 amQuote from johnwcowan on June 14, 2019, 6:39 pmQuote from AntC on June 14, 2019, 5:25 amA good candidate for multiple possreps ...
.... What if your database is getting readings from different sensors calibrated in different units? Rel, it appears, uses multiple possreps to record not only the value but whatever units it was captured in. Furthermore if you use the default table browser, it'll display the recorded value and units as entered (i.e. differently), even if a comparison says they're equal. This seems to me in clear violation of RM Pre 8 (Leibniz equality)
I appreciate the opposition to Rel's approach. I've mentioned before that as a user of the facility, I like it. It eases development and debugging. This is a case of pragmatics (and pedagogically-helpful transparent casing so you can see inside) over purity. (I know, "BUT, BUT PURITY!" But pragmatics & pedagogy! Etc.)
In the part of my message you elided, I suggested a way (tagged unions) to accommodate purity as well as pragmatics and pedagogy. In fact it would greatly assist pedagogy to demonstrate tagged unions, which learners will encounter in nearly every modern language. There is a certain data recording purity and pragmatics in capturing a sensor's units-of-record alongside the reading's value; that objective is not the part I'm opposing.
Whereas confronting learners with 'multiple possreps' is of negative pedagogical value: no other language/DBMS does that. A few languages provide a moderately seamless way to convert from/to some base representation; but they clearly say on the tin one of the representations is base, the others derived; and to not expect injectivity/total functions/that a round trip is identity.
Quote from Erwin on June 15, 2019, 1:23 pmQuote from Dave Voorhis on June 15, 2019, 8:06 amNot just well-ploughed ground... We've worn a trench several feet deep.
In fact so many feet that it popped out again on the other side of earth and we failed hitting Anthony by no more than an inch
? We're all thoroughly metric down here. A miss is as good as a kilometre. And if you're approximating your inches as 0.0254 metres, you'd be missing by a great deal more than that.
Quote from AntC on June 15, 2019, 1:47 pmQuote from Erwin on June 15, 2019, 12:28 pmQuote from AntC on June 14, 2019, 5:48 amNo you're not going to have your users directly updating the catalog using D statements. Because updating the catalog does not of itself create a relvar or alter its keys. There will be a CLI front-end that will build/update the relvar and generate the update statements to the catalog (under transaction control).
Funny. That's exactly what I do/did, and at some point in time when the forum was still on mail I learned that that's exactly what Hugh did in BS12 too. At least that's how I understood it.
Thanks Erwin. Um what's the referent of your "that's exactly"; and of Hugh/BS12's "that's exactly"? Are you saying SIRA_PRISE users do directly update the catalog, and that from observing the update, the DBMS infers what relvar/keys to create/amend/delete?
Or are you saying that SIRA_PRISE is like Tutorial D (and SQL) in using a CLI
CREATE/ALTER TABLE ... KEY ...that generates the catalog updates as well creating/amending the relvar?Why would Tutorial D use a different approach vs BS12 (if that's what you're saying)?
The referent is "updating the catalog using D statements [i.e. regular plain DML]". See my Newcastle presentation on "dispensing with DDL" ( http://computing.unn.ac.uk/raqueldbsystem/content/RAQUEL%20the%20Language/The%20Third%20Manifesto/Implementers%27%20Workshop/e_smout1.pdf ).
Some examples :
ADD RELVAR,RELVAR(TUP(...)) /* RELVAR() is a shorthand for a RELATION selector with an implicit heading specification akin to TD "SAME_AS(RELVAR)" */
add the specified relvar to the system. The relvar still has no attributes and no keys. It also has no physical design specs attached, so it is still non-updatable. It is queryable though and will yield an empty relation.
ADD RELVARATTRIBUTE,RELVARATTRIBUTE(TUP(...)TUP(...)TUP(...)) /*adds three attributes to a relvar. If the relvar is already recorded (has a physical design attached) extra stuff is needed for initializing the new attributes */
CMD(ADD KEY,KEY(TUP(...)))CMD(ADD KEYATTRIBUTE,KEYATTRIBUTE(TUP(...)TUP(...))) /* multiple assignment adding one key and two keyattributes */
There is a web client that generates these DMLs from the user's input, but the user can also type these commands in a console-like facility and it will work.
As for your final question (well, final in this post at least :-) ) : I can only guess that TTM and Tutorial D were/are primarily/exclusively targeted at how to improve on the DML part of SQL. And when that was done they figured they didn't have enough time left in their lives to write the second book on how to improve on the DDL part :-) Or bridge was more pressing at that point :-)
Quote from AntC on June 15, 2019, 2:08 pmQuote from Dave Voorhis on June 15, 2019, 8:06 amI appreciate the opposition to Rel's approach. I've mentioned before that as a user of the facility, I like it. It eases development and debugging. This is a case of pragmatics (and pedagogically-helpful transparent casing so you can see inside) over purity. (I know, "BUT, BUT PURITY!" But pragmatics & pedagogy! Etc.)
In the part of my message you elided, I suggested a way (tagged unions) to accommodate purity as well as pragmatics and pedagogy. In fact it would greatly assist pedagogy to demonstrate tagged unions, which learners will encounter in nearly every modern language. There is a certain data recording purity and pragmatics in capturing a sensor's units-of-record alongside the reading's value; that objective is not the part I'm opposing.
Whereas confronting learners with 'multiple possreps' is of negative pedagogical value: no other language/DBMS does that. A few languages provide a moderately seamless way to convert from/to some base representation; but they clearly say on the tin one of the representations is base, the others derived; and to not expect injectivity/total functions/that a round trip is identity.
This really has been discussed at length on this forum. I think the consensus is that TTM was ahead of its time but now lags in this area; that tagged unions are a better thing and that Rel does a surprisingly good job of making it all work (including something very close to tagged unions via the IM). As I recall most of us have agreed that we would implement RM Pre 4 only to the extent of keeping the physical and logical representations distinct, without permitting multiple possreps. I have proposed various minor changes that I think would make it more useful, but on balance a definition consistent with tagged unions but not dependent on the IM would be the preference.
Any implementor is of course perfectly at liberty to do exactly that: act first, ask forgiveness later.
Quote from dandl on June 15, 2019, 2:46 pmQuote from AntC on June 15, 2019, 2:08 pmQuote from Dave Voorhis on June 15, 2019, 8:06 amI appreciate the opposition to Rel's approach. I've mentioned before that as a user of the facility, I like it. It eases development and debugging. This is a case of pragmatics (and pedagogically-helpful transparent casing so you can see inside) over purity. (I know, "BUT, BUT PURITY!" But pragmatics & pedagogy! Etc.)
In the part of my message you elided, I suggested a way (tagged unions) to accommodate purity as well as pragmatics and pedagogy. In fact it would greatly assist pedagogy to demonstrate tagged unions, which learners will encounter in nearly every modern language. There is a certain data recording purity and pragmatics in capturing a sensor's units-of-record alongside the reading's value; that objective is not the part I'm opposing.
Whereas confronting learners with 'multiple possreps' is of negative pedagogical value: no other language/DBMS does that. A few languages provide a moderately seamless way to convert from/to some base representation; but they clearly say on the tin one of the representations is base, the others derived; and to not expect injectivity/total functions/that a round trip is identity.
This really has been discussed at length on this forum. I think the consensus is that TTM was ahead of its time but now lags in this area; that tagged unions are a better thing and that Rel does a surprisingly good job of making it all work (including something very close to tagged unions via the IM). As I recall most of us have agreed that we would implement RM Pre 4 only to the extent of keeping the physical and logical representations distinct, without permitting multiple possreps. I have proposed various minor changes that I think would make it more useful, but on balance a definition consistent with tagged unions but not dependent on the IM would be the preference.
Any implementor is of course perfectly at liberty to do exactly that: act first, ask forgiveness later.
That's a good summary, and an excellent way to -- if I may suggest -- end this round (which would be roughly the 17th by my estimation, give or take) of the otherwise-interminable multiple-possrep debate before it gets started. Again.
Quote from AntC on June 15, 2019, 2:13 pm
We're all thoroughly metric down here. A miss is as good as a kilometre. And if you're approximating your inches as 0.0254 metres, you'd be missing by a great deal more than that.
"A gramme of prevention is worth a kilogramme of cure." —Old Aussie proverb
"Ay, every centimetre a king!" —King Lear, government schools edition
But 0.0254m is no approximation: it is the definition of an inch, by the international agreement of 1959 by which the national standards bodies of Australia, Canada, New Zealand, South Africa, the UK, and the U.S. agreed that the yard (36 inches) would thenceforth be exactly 0.9144m and the avoirdupois pound (16 ounces) exactly 0.45359237 kg.