The two parts of this I find really attractive are: > What is also irritating about the result table is the fact that the notion of a ‘key’ is not defined anym

The two parts of this I find really attractive are: > What is also irritating about the result table is the fact that the notion of a ‘key’ is not defined anymore, that notion is simply dropped when processing data in SQL or relational algebra (→Problem 5: key information loss). > Back to the result table, SQL discards even more information from the underlying relations: where did a specific attribute in the result table come from in the first place? Does that attribute value correspond to an attribute in one of the base relations? Or was it computed? (→Problem 6: schema information loss) I've definitely had cases in ETL where being able to track where data came from (e.g `columnA` is derived from a window function over `a.columnB` and `b.columnC). This doesn't quite get to that (what if `a.columnB` is derived!) but its a neat idea