Re: Very simple question to relational theorists.

On Saturday, September 8, 2012 12:07:32 PM UTC-7, Evgeniy Grigoriev wrote:
> My question again :) Is this system relational?

hi Gregoriev,

Here is more cut and paste until I can send my more specific draft. It is an edited message from another forum in reply to someone promoting support for string aggregation and pivot tables. But these are not relational. They are inadequately abstracted representations of formatted output types. You too are essentially using relations to represent a relation-plus-labels type that would likely best merely contain rather than be relations. (The relations are from Date's suppliers & parts database. http://c2.com/cgi/wiki?SupplierPartsDatabase)

philip

I'm all for allowing a language to have parameters and results of all relevant semantic types, like attributes, headings and relations of any heading. But you don't seem to understand enough about working relationally. Also you are failing to abstract, shoehorning things inappropriately into relations.

1. String aggregation.

    s# s# list_of_parts char

    s1      Nut,Bolt,Screw,Cam,Cog
    s2      Nut,Bolt
    s3      Bolt
    s4      Bolt,Screw,Cam

This is a query/relation in name only. It's formatted output. To use this info for further calculation you should use (sp join p){s# pname}:

s# s# pname char

s1      Nut
s1      Bolt
s1      Screw
s1      Cam
s1      Cog
s2      Nut
s2      Bolt
s3      Bolt
s4      Bolt
s4      Screw
s4      Cam

If your relation is effectively a value of some graphic-table type, it should accept this as input. Such a type might be implemented using operators mapping from relations to lists and punctuating lists. But it could also do lots of processing relationally, eg extend adding pname concatenated to comma and summarize to concatenate those, or summarize concatenating pnames with commas between.

   2. Pivot Tables

    s# s# has_p1 has_p2 has_p3 has_p4 has_p5 has_p6

    s1      Y      Y      Y      Y      Y      Y
    s2      Y      Y      N      N      N      N
    s3      N      Y      N      N      N      N
    s4      N      Y      N      Y      Y      N   

This is also just formatted output. (And again suppliers without parts and parts without suppliers are missing.) The complex predicate for this relation (its label qua graphic-table) is highly structured and requires for understanding undoing much of the mapping that went into generating it: removing "has_" to find out what part is referred to, and converting Y/N to whether a part is possessed. The information a user really wants is:

    \p#|  p1     p2     p3     p4     p5     p6
     \ |
    s#\|
    ---+---------------------------------------
    s1 |  yes    yes    yes    yes    yes    yes
    s2 |  yes    yes    no     no     no     no
    s3 |  no     yes    no     no     no     no
    s4 |  no     yes    no     yes    yes    no

    Does supplier s# that supplies at least one part supply part p#?

Now we see that we really have two dimensions/axes/attributes (s# and p#) forming a key with further dimension/axis/attribute (the table entries) extending their cross product. The only asymmetry is just which key attribute is displayed horizontally and which vertically. The graphic-table is formatting that is understood by convention to be presenting the info in sp{s# p#}. Ie in (where attribute b fills the graphic-table body):   extend sp{s#} join sp{p#}
    add (if tuple{s# s#, p# p#} in sp then 'Y' else 'N') as b  or if you prefer:

    extend sp{s# p#} add 'Y' as b
  union extend (sp{s#} join sp{p#}) notmatching sp add 'N' as b

s# s# p# p# b ?

s1      p1       Y
s1      p2       Y
s1      p3       Y
s1      p4       Y
s1      p5       Y
s2      p1       Y
s2      p2       N
s2      p3       N

But beyond that it is not helpful to characterize/abstract this graphic-table as a relation. You need a notion of graphic-table format type/library. Your hundreds of lines should probably be many fewer consisting of simple queries each passed to one of a limited number of formatting functions at the end. It's unlikely you should manipulate such tables rather than further manipulating the underlying displayed data relationally and then formatting that. And the interface for such a graphic-table value should not involve a contorted relation like yours; it should involve the raw info plus ordering attributes and attribute names for ordering and horizontal/vertical placement, etc.

Otherwise what benefit is there to having the info in this format rather than (sp join p){s# p#} or for that matter just sp and p? Moreover by converting (arbitrary numbers of) values into (fixed numbers of) attribute names you have prevented yourself from using basic relation operators to further iterate. Then you think you need to iterate by a separate repetition notation submitting a string to an eval facility!

To implement/call a graphic-table type/library or relations like yours you should be given operators extracting attribute names and headings; equivalently, metadata. But you don't need special pivot operators per se. You could write such operators using ordinary relation operators manipulating relations plus heading/meta data values, tuples and relations, mapping from straightforward simply-predicated manipulation-oriented relations to complexly- and data-dependently- though conventionally- predicated output-oriented graphic-tables or relations.

philip Received on Mon Sep 10 2012 - 21:53:36 CEST