For what it's worth, the relational composition (mapper) of ActiveFacts takes a different approach from NORMA in regard to one-to-ones, by the sounds of Matt's descriptions.
In particular, it doesn't try to perform an exhaustive search and optimisation of the possible options, which is a O(2**N) problem. Instead, it takes an initial guess as to which way around to map each one, taking into account things like whether the one-to-one is used in identification, and creates a directed Reference from one to the other. Then, it iteratively passes over the objects for which a firm decision (table or not) has not yet been made, and applies a number of rules to see if it can make a firm decision one way or the other. In some of these rules, a Reference may be flipped to point in the reverse direction. If, after taking one complete pass, no new firm decisions can be made, the process finishes, even though some decisions that could have gone either way have no strong reason to go a particular way. Finally, if a Reference points to an object that is a table, a foreign key is generated. Otherwise, the object is absorbed into this object.
This algorithm is O(N*log(N)), which means it scales much better.
In addition, it seems to make the right decisions in a number of cases where NORMA gets it wrong. For example, I have a Blog model where an Author is identified by AuthorID (an Autocounter field), but also has a one-to-one Name (VariableLengthText). NORMA creates a table called "Name" instead of the obvious Author table.
Another error NORMA makes sometimes is to sometimes absorb two AutoCounter fields that identify two objects into a single table. This creates SQL which doesn't work. ActiveFacts has a rudimentary mechanism which usually prevents this, but I plan to extend that to allow more kinds of auto-allocated identifiers, such as Ordinal values inside a multi-part PK, and even maybe define a generic method for allowing user-defined data types to provide their own auto-allocation algorithms.