oops: column_oriented_bag ::= <<field_type_map,field_values…|>…|>
or something like that :) > On 16 Feb 2015, at 22:50, Robbert van Dalen <[email protected]> wrote: > > Let’s model a pure relation as a set of Avail objects. > Here is the canonical Avail type: > > relation ::= {object|}; > > Let’s also model the (abstract) definition of the cartesian product: > > Abstract method "_×_" is [relation,relation]→relation; > Semantic restriction "_×_" is > [ > r1 : relation's type, > r2 : relation's type > | > {(r1's element type) ∩ (r2's element type) | ⎣r1⎦×⎣r2⎦ .. ⎡r1⎤×⎡r2⎤} > ]; > > The above semantic restriction is fine when two relations don’t share any > fields. > But what should happen when two relations share 1 or more fields? > > My hunch is that such cartesian product should collapse into a relational > join! > And in such case, the semantic restriction can be further tightened with more > precise lower and upper bounds. > (to be done). > > Here is another thought: > > Relational databases don’t implement a strict relational algebra, because > they allow duplicate rows. Oracle relations are actually bags. > In Avail we can easily model bags via tuples: > > bag ::= <object…|>; > > And consequently, the cartesian product of bags: > > Abstract method "_×_" is [bag,bag]→bag; > > Now it happens to be that - next to row oriented relational databases - there > are also column oriented relational databases. > How would one model a column oriented bag in Avail? > > Here is an idea: > > field_type_map ::= <<atom,type…|2>…|>; > field_values ::= <any…|> > > column_oriented_bag ::= <field_type_map,field_values…|> > > That way, we can always reconstruct every object (record) based on its > field_type_map and its corresponding field_values. > I welcome any other ideas on how to model column oriented bags in Avail! > > cheers, > Robbert.
signature.asc
Description: Message signed with OpenPGP using GPGMail
