The Rel Forum

Hello,

[TTM] TTM and the Information Principle (was Re: [TTM] Definition of Relational Completeness)
Dave Voorhis <dave@armchair.mb.ca> JULY 25 wrote:
TYPE TypeInfo UNION;
TYPE Scalar IS {TypeInfo POSSREP {TypeName CHAR}};
TYPE TupleHeading IS {TypeInfo
POSSREP {Attributes RELATION {AttrName CHAR, AttrType TypeInfo}}};
TYPE RelationHeading IS {TypeInfo
POSSREP {Attributes RELATION {AttrName CHAR, AttrType TypeInfo}}};
Barring any significant objection, I will add the above to Rel, along with:
- A new built-in operator TYPE_OF(p) RETURNS TypeInfo, which returns a
TypeInfo for any expression p.
- A revised sys.Catalog catalog relvar, with the Attributes attribute changed from
type RELATION {Name CHAR, TypeName CHAR} to type RelationHeading.

Re: [TTM] Definition of Relational Completeness...
Dave Voorhis <dave@armchair.mb.ca>Jun 26 wrote:
A new type MATRIX that consists of n columns and an arbitrary number of rows.
A MATRIX type is declared as MATRIX [Type1 .. Typen], where each Type identifies
the column's type. E.g., MATRIX [INT, INT, CHAR] declares a matrix with an arbitrary
number of rows and three columns. The first two columns are of type INT, the last column
is of type CHAR.
My working hypothesis is that compared to relations, a MATRIX structure would
provide a more intuitive (and easier to make generic) basis for implementing
statistical and other analytical operators, like a generic 1-way ANOVA operator
or a generic autoregressive moving average, etc.
I'm very open to being convinced otherwise.

I look forward to using the former and sincerely hope you saw the need to facilitate
statistical computations with the latter. Such facilitation in the sql world is a "feature"
and helps sell the software. After price and performance comes "features". My working
hypothesis is the more constructs like MATRIX the better it is for Rel. I believe Rel needs
more actively involved users. Not those who are curious enough to download but are then
lost when DBrowser opens. A demo of MATRIX will make a greater impact on a ttm challenged
user than an example of the relational algebra. This is classical bait and switch. Bait with facilitation and then hope for the users switch to the algebra. And besides, as for statistics per se if I'm not mistaken Microsoft is trying to bake R into Sql Server obviating a users need to use t-sql or go to SAS or other statistical dedicated software.
On my use of italics. Apart from the other few ttm software developers I see very little interest in ttm project software on the ttm mailing list. An occasional acknowledgment or bug report but no real interest. Given the level of knowledge, sophistication and skill of the developer of Rel it is at least amusing that he shows such courtesy to his like-minded peers. There is a certain grace to that approach.
Question on the much anticipated Rel update: I'm assuming I can create a Rel relvar and
store it in, for example, sqlite. I would then have the opportunity for a mini ttm ecosystem.
I could have the option, if I so desired, of accessing that sqlite table in David Bennett's Andl,
modifying it (possibly) and then reacquiring the table in Rel. Is something like this going to be
possible?

thanks,
steve dassin

The forthcoming update now implements a TYPE_OF(e) operator that returns a TypeInfo value about any expression e, where a TypeInfo is a supertype of either a Scalar or NonScalar type. The sys.Catalog relvar now has an Attribute attribute that returns a NonScalar value. The types are defined as follows: A MATRIX type will almost certainly have to wait for a future update, though I may try adding a facility to define custom aggregate operators in the forthcoming update, if time permits.

Being able to integrate Rel with sqlite is theoretically possible even in the current release, as the mechanisms for linking relvars to external data sources lack documentation more than they lack facility. However, I can imagine there would be challenges reading one TTM project's data in another TTM project, because TTM projects tend to be quite focused on types, type systems and typeful programming, and converting anything more sophisticated than canonical primitives (strings, ints, etc.) is complex.

TTM projects tend to be quite focused on types, type systems and typeful programming, and converting anything more sophisticated than canonical primitives (strings, ints, etc.) is complex.

Excellent point. Can you tell us at this point if storing a Rel relvar in another dbms will depend on whether or not it contains any user-defined types? Obviously storing a relvar with just Rel system types should be much easier than if it contains user-defined types. I'd gladly settle for the ability to store just system types (at least as a start:-). Any light you can shed on this matter will be greatly appreciated.

thanks,
steve

I'm not clear what "storing a Rel relvar in another dbms" means. A Rel relvar can represent data in a native Rel database, or it can represent data in an external data source (like a table in a PostgreSQL or SQLite database, for example), but it can only be accessed in a Rel database.

Do you mean exporting data from a Rel relvar to a table in another DBMS?

Do you mean exporting data from a Rel relvar to a table in another DBMS?

hello,

That is exactly what I had in mind but unfortunately didn't express clearly. It would be awesome if not only we could "pull" data put "push" it as well. Your thoughts?

thanks,
steve

A relvar defined as a connection to a table in an external DBMS can (in principle) allow tuples to be inserted. So, defining a relvar on a table in an external DBMS is a way to export data to that DBMS.

The forthcoming Rel update has an all-new user interface, which includes the ability to view and update relvars in a spreadsheet-like manner, with a possible option to export data to Excel spreadsheet files. If the Excel export turns out to work well (I'm still working on it), I'll include it in the forthcoming update. Otherwise, it should be available in the update after that.

If the Excel export turns out to work well (I'm still working on it), I'll include it in the orthcoming update.

Here's really hoping it works well and can be included in the forthcoming update. Please give all this new material your best shot

steve