The ORM Foundation

Andy Carver:

Hi, Yes you are correct, there should be a way to do it and there isn't. ORM's Rmap algorithm stipulates that in relational-mapping a 1:1 fact type like yours with mandatory constraints either on both roles or on neither roles (as in your case), the user needs a way to input his / her preference as to which table that 1:1 should be mapped to. Unfortunately, as far as I know no such facility for user input has been incorporated into NORMA's Rmapping as yet. So it's not so much a bug, as an interaction-feature that's yet to be added in. As for when it will be added, perhaps Matt or Terry could comment on that.

Ken Evans:

Looopy:

. the thing i am try to accomplish is that both a employee and customer can share the same login and its not mandatory that they should be able to login and its not mandatory for a person to do a login either.

 

Please refer to my example.
If you:
1: remove the mandatory requirement in the fact type "Person has WebLogin"
2: remove the exclusion constraint between the employee and customer subtypes

Then:

* an employee and a customer can share the same login (i.e. one person can be both a customer and an employee)
* it is not mandatory that a person has a login
* it is not mandatory for a customer or employee to login (since both subtypes share the non-mandatory nature of the "Person has WebLogin" fact type.)

And

If you want to add "contacts" that are neither customers nor employees
Then then you could add a unary "Person is contact"
or add "Contact" as a new subtype of person and then add a fact type about "Contact" that is not true of Customer or Employee.

Ken

Sorry I didn't jump in here earlier.

This is a good idea, but in practice is harder to implement than it sounds because if there are multiple 1-1 fact types attached to the same object type the user settings can be contradictory and cause some horrific issues with the mapping algorithm.

There are a number of tie-breakers that are looked at to determine absorption direction. However, if the mandatory constraints are balanced (no mandatories, or mandatory on both sides), both role players are entity types, and tables exist for both role players, then you're basically in a tie.

With a tie in place, the first role in the fact type wins. Unfortunately, there is no way to change the role order in the tool. Fact type shapes and readings maintain their own orders, but the role order itself is rarely used and cannot be changed after the fact type has been created.

To change the role order in these cases:

1. Save a backup copy of the .orm file.
2. Open the .orm file with the Visual Studio .xml editor. You can do this by clicking the down arrow on the right edge of the Open button in the VS Open File dialog and choosing 'Open With...' and choosing the 'XML (text) Editor'. Alternately, I always turn on the 'Show Miscellaneous files in Solution Explorer' option (on the Environment/Documents page of the Tools/Options dialog). If you close an .orm file that is not in a project, it will appear in this list and you can right click to 'Open With...'. You cannot view the .orm file simultaneously in the XML and NORMA designers.
3. With the .orm file open in the .xml editor, find your fact type  (search for the the condensed name shown in the model browser). You should see this in the _Name attribute of an orm:Fact tag.
4. You'll see orm:Role elements inside the orm:FactRoles block immediately inside the orm:Fact element. The order of the orm:Role nodes provides the primary fact type order.
5. Change the role order by switching the order of the orm:Role elements.
6. Save the file and reopen in the designer.
7. The fact type shapes may display with the lines crossed for the modified fact type. Just drag one role on the other to get the correct display order.
8. To force the relational model to regenerate:
• Add a new entity type to the design surface and sets its refmode to an intrinsic ref mode (like .id), or add a value type and set its data type.
• Delete the new type (do not Undo)
• (Advanced alternative to force regeneration on load: You can change the number of the ormtooial:AbstractionModelGenerationSetting@AlgorithmVersion attribute to force regeneration on load, or just delete the full orm:GenerationState block)
9. At this point you should see the 1-1 going the other direction, but only if there really was a tie in the system.

-Matt