The UMLmap procedure in Table 3.3 provides basic guidelines for mapping ORM schemas to UML class diagrams. Selected entity types and value types map to object classes and data types, including attribute domains when associations are replaced by attributes. We now illustrate this procedure. As a preparatory move, step 1 binarizes any sets of exclusive binaries, as shown in Figure 3.55 .
Table 3.3 UMLmap Procedure Step Action
1 Binarize any sets of exclusive unaries.
2 Model selected object types as classes, and map a selection of their n : 1 and 1 : 1 associations as attributes. To store facts about a value type, make it a class.
3 Map remaining unary fact types to Boolean attributes or subclasses.
4 Map m : n and n -ary fact types to associations or association classes. Map objectifi ed associations to association classes.
5 Map ORM constraints to UML graphic constraints, textual constraints, or notes.
6 Map subtypes to subclasses, and if needed, subtype defi nitions to textual constraints.
7 Map derived fact types to derived attributes/associations, and map semi-derived fact types to attributes/associations plus rules.
FIGURE 3.55
Step 1: replace any set of exclusive binaries by a binary fact type.
(a) (b)
In step 2, we decide which object types to model as classes and which n : 1 and 1 : 1 ORM associations to remodel as attributes. Typically, entity types that play functional fact roles become classes. Functional binary ( n : l and 1 : 1) asso- ciations from an entity type A to a value type B , or to an entity type B about which you never want to record details, usually map to an attribute of A. If you have specifi ed role names, these can usually be used as attribute names, with the object type name becoming the attribute ’ s domain name.
The mapping in Figure 3.56 illustrates several of these step 2 considerations, as well as step 6 (map ORM constraints to UML graphic constraints, textual con- straints, or notes). The {P} and {Ul} annotations for preferred identifi er and unique- ness are not standard UML. The value constraint on gender codes is captured using an enumeration type.
In rare cases, value types that are independent, play an explicit mandatory role, or play a functional fact role in an 1 : n fact type map to classes. The example in Figure 3.57(a) deals with cases where we store title – gender restrictions (e.g., the title “ Mr. ” is restricted to the male gender). The example in Figure 3.57(b) uses a
FIGURE 3.56
Step 2: map selected n : 1 and 1 : 1 associations to attributes.
(a) (b)
FIGURE 3.57
Step 2: rare cases of value types mapping to classes.
(a) (b)
multivalued attribute to store all the genders applicable to a title (e.g., the title “ Dr. ” applies to both male and female genders). The Title class gives fast access from title to applicable gender, but slow access from gender to title. As discussed earlier, multivalued attributes should be used sparingly.
In step 3 we map unaries to Boolean attributes or to subclasses. The example in Figure 3.58 assumes a closed-world interpretation for the unary. With an open- world approach, the isSmoker attribute is assigned a multiplicity of [ 0..1 ] and the
{complete} constraint is removed from the subclassing.
In step 4, the remaining fact types are mapped to associations. Any m : n asso- ciations should normally remain that way. In the example in Figure 3.59 , the n : 1 fact type is retained as an association because it relates two entity types that become classes in the mapping. Even if the m : n association did not apply, we would normally retain Country as a class, since now or later we are likely to record details for it (e.g., country name).
If an m : n association involves a value type (e.g., Employee has PhoneNr ) instead of using a multivalued attribute, see if it is possible to transform the m : n association into multiple n : 1 associations (e.g. Employee has PhoneNr1 ; Employee has PhoneNr2 ; etc.).
If each object type in an n -ary fact type should map to a class (e.g., it plays other functional roles), then map the n -ary fact type to an n -ary association.
Figure 3.60 provides an example.
FIGURE 3.58
Step 3: map unaries to Boolean attributes or subclasses.
(a) (b) (c)
FIGURE 3.59
Step 4: map remaining fact types to associations.
(a) (b)
If an object type in a ternary fact type should not map to a class (typically an m : n : 1 uniqueness pattern with it outside the uniqueness constraint), then objec- tify the rest of the association as an association class and map its role as an attri- bute. Figure 3.61 shows an example.
Objectifi ed associations map to association classes, as shown earlier in Figure 3.18 . Some cases of coreference could be mapped into qualifi ed associations, but FIGURE 3.60
Step 4: map some n -ary fact types to n -ary associations.
(b) (a)
FIGURE 3.61
Step 4: map some n -ary fact types to association classes.
(b) (a)
Table 3.4 Mapping Main ORM Graphic Constraints to UML (for step 5)
ORM Constraint UML
Internal UC Maximum multiplicity of 1, or {U n } External UC Qualifi ed association or textual constraint Simple mandatory Minimum multiplicity of 1, or textual constraint Inclusive-OR Textual constraint (unless within exclusive-OR)
Frequency Multiplicity or textual constraint
Value Enumeration or textual constraint
Subset and Equality Subset(s) or textual constraint
Exclusion Textual constraint (unless within exclusive-OR) Ring constraints Textual constraint
Join constraints Textual constraint Object cardinality Class multiplicity
mapping to separate attributes or associations supplemented by a textual compos- ite uniqueness constraint offers a more general solution.
In step 5, the simplest constraints in ORM usually map in an obvious way to multiplicity constraints, as illustrated earlier. The more complex ORM constraints have no graphic counterpart in UML, so you need to record these separately in textual form. Table 3.4 summarizes the main correspondences.
In step 6, subtypes are mapped to subclasses, adding relevant subclassing constraints. Subtype defi nitions are handled with discriminators and/or textual constraints. For example, the ORM schema considered earlier in Figure 3.38 maps to the UML schema in Figure 3.37 .
In step 7, we map derived and semi-derived fact types. The schemas in Figures 3.53 and 3.54 provide simple examples.
With these hints, and the examples discussed earlier, you should now have enough background to do the mapping manually for yourself.