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
