Jakob,
Simple reference scheme patterns are short hand notations for what you show here in the first, second, and fourth graphic lines, with two exceptions:
-
The PersonName role is not explicitly marked as mandatory (it is implicitly mandatory because PersonName plays no mandatory non-existential roles).
-
The right uniqueness constraints are preferred (double lines).
(Tool-specific comment) NORMA records reference mode patterns in the object model, but the reference modes themselves are implied by the constraint patterns and value type names. The notion of 'reference mode' is not used in any mapping algorithms, verbalization, etc. If you manually enter the correct pattern, you will automatically have a reference mode value. The notion of reference mode collapsing belongs to the shape meta model, not the ORM core object model. Popular reference mode value type names always include the entity type name, whereas unit-based and general modes never include the name. Eventually we will add formal units to the meta model, which will further distinguish the unit-based and general reference mode patterns. (End of tool-specific comment)
I am not comfortable with the subtyping extensions you represent here. At the instance level, you're subtype relationships are indicating subset relationships between identifiers. This makes sense if you strip the conceptual meaning from the identifiers, but ORM is a conceptual modeling language, and subtyping represents an is a relationship. It makes conceptual sense to say 'a Dog is an Animal' or 'a MalePerson is a Person', but it does not make sense to say 'a Price is a Money'. If the 'is a' verbalization does not make sense, then you do not have a good candidate for an ORM subtype. We do not consider an entity to be a subtype of its identifier because, for example, 'a PersonName is a Person' is conceptual nonsense.
Unit-based reference schemes are admittedly confusing because the value has double meaning (the value, and the dimension). The idea behind units is that they can be automatically transformed based on either static (mass, distance, temperature, etc) or dynamic (monetary exchange rate) dimension conversion information. So, theoretically, you can automatically convert values that share units. For example, a model could record height in inches and weight in pounds, and still automatically produce an accurate BMI value given these inputs (BMI is kg/m2). Of course, this is non-trivial in practice due to round off errors and other concerns (recording inches in integers makes sense for the BMI problem, but inferring from this that meters should be rounded to integer units would be disastrous). I think the issue with your model is that you have the unit (Money) and the value ($) turned around. Price is recorded in dollars, which is a unit of money. If you want to do this subtyping (which is not a strong enough relationship to indicate the dimension conversions), you get 'Price is specified in DollarAmount, DollarAmount is a subtype of MoneyAmount'. This is a different meaning than is indicated by your diagram.
As for the PageURL->URL subtype, this breakdown makes more sense to me than Price->Money, but I'm not sure what this breakdown adds. A general reference scheme does not limit the value type be used as an identifier for more than one item. So, you can have an instance of Page(URL) and Site(URL) that share a URL identifier. Certainly you can consider PageURL and SiteURL as subtypes of URL with a disjunctive mandatory constraint across the subtypes. However, if you expect an exclusion across the subtypes as well, then you've moved beyond the meaning of the general reference mode pattern.
-Matt