In response to Clifford, in great haste because I'm about to be away and out of communication until next Tuesday:
(a) At the physical layer anything goes. If some kind of "sparse matrix" gives desired performance while a more direct representation of the logical schema doesn't, then go for it. (I have often made this point.) But the things representing the gaps wouldn't be called NULL because that has semantics in the language (SQL) in which it is defined. Nor would the storage and retrieval mechanism have to deal with 3-valued logic etc.
(b) Well, standard SQL has had NATURAL JOIN since 1992--what's more I was the one that put it there! (It also has JOIN ... USING ..., which ought to be natural join with protection from inadvertently joining on the wrong attributes but alas it isn't, quite.)
In Business System 12 and Tutorial D, when you're confident that the attribute names are as you want them, you can write JOIN{r1, r2, ... rn} (though in BS12 the braces were parens) in place of r1 JOIN r2 JOIN ... JOIN rn. (This thanks to JOIN's commutativity and associativity, of course.)
Regards,
Hugh