Jcm part 10

UML data models from an ORM perspective:
Part 10
by Dr. Terry Halpin
Director of Database Strategy, Visio Corporation
This paper first appeared in the August 1999 issue of the Journal of Conceptual Modeling, published byInConcept. This paper is the tenth in a series of articles examining data modeling in the Unified Modeling Language (UML) from the perspective of Object Role Modeling (ORM). Part 1discussed historical background, language design criteria, object reference and single-valued attributes. Part 2 covered multi-valued attributes, basic constraints, and instantiation using UML object diagrams or ORM fact tables. Part 3 compared UMLassociations and related multiplicity constraints with ORM relationship types and related uniqueness, mandatory role and frequency constraints, as well as how associations may beinstantiated. Part 4 contrasted ORM nesting, co-referencing and exclusion constraints with UML association classes, qualified associations, and xor-constraints respectively.
Part 5 discussed subset and equality constraints. Part 6 discussed subtyping. Part 7 discussed value, ring and join constraints. Part 8 listed some recent updates to the UMLstandard, then discussed aggregation. Part 9 examined initial values and derived data in ORM and UML. Part 10 discusses changeability and collection types in UML and ORM. Changeability properties
In UML, restrictions may be placed on the changeability of attributes, as well as the roles(ends) of binary associations. It is unclear whether changeability may be applied to theends of n-ary associations, but my guess is that this is currently forbidden. The followingthree values for changeability are recognized, only one of which can apply at a given time: The value “changeable” was previously called “none”. Although the new term“changeable” was approved for UML 1.3, some instances of “none” still occur in thestandard; this oversight should be remedied in a later version. The default changeability is“changeable” (any change is permitted). Although the UML stan2-25] and UML data models from an ORM perspective (part 10) 1 some authorsndicate that “changeable” is a value, the standard also says“there is no symbol for whether an attribute is changeable”, so it appears that this defaultcannot be explicitly declared. However it makes sense to allow explicit declaration of thisdefault, and it would not be surprising to see the standard revised to permit it. The othersettings (frozen and addOnly) may be explicitly declared in braces. For an attribute, thebraces are placed at the end of the attribute declaration. For an association, the braces areplaced at the opposite end of the association from the object instance to which theconstraint applies.
Recall that a “link” is an instance of an association. The term “frozen” means that once an attribute value or link has been inserted, it cannot be updated or deleted, and noadditional values/links may be added to the attribute/association (for the constrainedobject instance). The term “addOnly” means that although the original value/link cannotbe deleted or updated, others values/links may be added to the attribute/association (forthe constrained object instance). Clearly, addOnly is only meaningful if the maximummultiplicity of the attribute/association-role exceeds its minimum multiplicity.
As a simple if unrealistic example, sere empNr, birthDate and country of birth are frozen for Employee, so they cannot be changed from their original value. Forinstance, if we assign an employee the empNr 007, and enter his/her birthdate as02/15/1946 and birth country as ‘Australia’, then we can never make any changes oradditions to that.
Notice also that for a given employee, the set of languages and the set of countries visited are addOnly. Suppose that when facts about employee 007 are initially entered, weset his/her languages to {Latin, Japanese} and countries visited to {Japan}. So long asemployee 007 is referenced in the database, these facts may never be deleted. However wemay add to these (e.g. later we might add the facts that employee 007 speaks German andvisited India).
Employee
birthDate {frozen}languages [*] {addOnly} Changeability of attributes and association roles may be specified in UML By default, the other properties are changeable. For example, employee 007 might change his name by deed poll from ‘Terry Hagar’ to ‘Hari Seldon’, and the set of countrieshe wants to visit might change, after some traveling, from {Ireland, Italy, USA} to {Greece,Ireland,}.
UML data models from an ORM perspective (part 10) 2 Some traditional data modeling approaches also note some restrictions on changeability. For example, Oracle’s ER notation includes a diamond to mark arelationship as non-transferable (once an instance of an entity type plays a role with anobject, it cannot ever play this role with another object). Although changeabilityrestrictions may at first appear very useful, in practice their application in databasesettings is limited. One reason for this is that we almost always want to allow factsentered into a database to be changed. With snapshot data, this is the norm, but even withhistorical data, changes can occur. The most common occurrence of this is to allow forcorrections of mistakes, which might be because we were told the wrong informationoriginally or because we carelessly made a misspelling or typo when entering the data.
In exceptional cases, we might require that mistakes of a certain kind be retained in the database (e.g. for auditing purposes) but be corrected by entering later facts tocompensate for the error. This kind of approach makes sense for bank transactions (seer example, if a deposit transaction for $100 was mistakenly entered as $1000,the record of this error is kept, but once the error is detected it can be compensated for bya bank withdrawal of $900. As a minor point, the balance is both derived and stored, andits frozen status is typically implied by the frozen settings on the base attributes, togetherwith a rule for deriving balance.
Transaction
tranNr {P} {frozen}accountNr {P} {frozen}tranDate {frozen}tranType {frozen}tranAmount {frozen}/balance {frozen} All attributes of Transaction are frozen Although not stated in UML 1.3, some authors allow changeability to be specified for a class, as an abbreviation for declaring this for all its attributes and oppositeassociation ends p. 184]. For instance, all the {frozen} constraints inight bereplaced by a single {frozen} constraint below the name “Transaction”. While thisnotation is neater, it would be rarely used. Even in this example, we would probably wantto allow for the possibility of adding non-frozen information later (e.g. a transaction mightbe audited by zero or more auditors).
Changeability settings may have more use in the design of program code than in conceptual modeling (e.g. {frozen} corresponds to const in C++). Although changeabilitysettings are not supported in ORM, which focuses on static constraints, such featurescould easily be added as role properties if desired. In the wider picture, being able tocompletely model security issues (e.g. who has the authority to change what) wouldprovide greater value. This view is nicely captured by the following comment of JohnHarris, in a recent thread on the InConcept website: “Rather than talk of "immutable" dataI think it is better to talk of a privilege requirement. For instance, you can't change yourrecorded salary but your boss can, whether it's because you've had a pay rise or because UML data models from an ORM perspective (part 10) 3 there's been a typing error. Privileges can be as complicated or as simple as they need tobe, whereas "immutable" can only be on or off. Also, privileges can be applied to theinsertion of new data and removal of old data, not just to updates”.
Collection types
Though collection types (e.g. sets, bags, sequences and arrays) are commonly used inprogramming, their use as record components in database schemas largely disappearedwith the widespread acceptance of relational databases, where each table column is basedon an atomic domain. However, the recent emergence of object-relational and objectdatabases has once again allowed collection types to be embedded as database fields.
Although a number of collection types were slated for inclusion in the object-relationaldatabase standard SQL3, the only one that made it was array (a one dimensional arraywith a maximum number of elements). It is anticipated that three further collection typeswill be added in SQL4: set (unordered collection with no duplicates); multiset (bag, i.e.
unordered collection that allows duplicates); and list (sequence, i.e. an ordered bag). Somecommercial systems already support these. Experience with these systems indicates thatlittle performance gain is actually achieved by use of collection types; but this may changeas the technology matures. Array, set, bag and list are also included as collection types inthe object database standard ODMG UML includes none of these as standard notations, but does include the {ordered} constraint to indicate mapping to an ordered set (i.e. a sequence with no duplicates); andits associated textual language OCL (Object Constraint Language) includes set, bag andsequence types as well as collection as their abstract supertyp]. While UMLallows collection types to be specified as stereotypes of classes, and realized asimplementation classes pp. 485-6], this usage seems geared toward code design so willnot be elaborated here.
Different approaches have arisen as to how collection types should be specified within the conceptual analysis and logical design of data. Some proposals use collectionsdirectly within the conceptual schema, some introduce them only at the logical schemalevel, while some specify them as annotations to the conceptual schema to guide themapping to the logical level. As a simple example, consid The ORM schema (a)and UML schema (b) depict driving as a many-to-many association. The employee nameinformation is modeled as a functional fact type in ORM and as an attribute in UML. Ifthis is mapped to a relational database system, then by default the m:n association mapsto a separate table, resulting in a 2-table schema (c).
UML data models from an ORM perspective (part 10) 4 Employee
Employee
ORM schema (a) and UML schema (b) map by default to relational schema (c) Now suppose that for some reason we wish to map both fact types into the same table, as shown ind). Some object-relational databases support this option.
Clearly this mapping decision is an implementation, not a conceptual, issue, but how dowe specify it? Visio Enterprise 5 lets you do this at the logical level (d), and VisioModelerlets you specify it either at the logical level or as an annotation to the ORM schema. Theannotation shown a) differs from that of VisioModeler (which uses a boxbetween the role and its object type), but the idea is the same (indicating that this rolemaps to a set field of the co-role’s table). The display of such annotations should behidden during conceptual analysis, and toggled on only when we wish to discussoverrides to the default logical mapping. In UML we could invent a similar annotation, asb), or instead use a multi-valued attribute, asc), with this displaybeing used only for discussing the logical mapping. As discussed in an earlier article,multi-valued attributes should never be used in conceptual analysis.
Employee
Employee
Employee
Some possible ways of indicating that driving should map to a set-valued column UML data models from an ORM perspective (part 10) 5 Some extensions of ORallow collection types (e.g. set, bag, sequence and schema) to be modeled as first class object types, using constructors often shown as ashape around the member object type. A sequence is an ordered bag, and in extendedORM its collection type may be marked “seq”. If the sequence cannot have duplicates, it isa “unique sequence” (or ordered set) and is marked “seq”. As an example of the uniquesequence (or ordered set) constructor, a). Here an author list is a sequence ofauthors, each of whom may appear at most once on the list. This may be modeled in flatORM by introducing a Position object type to store the sequential position of any authoron the list, as shown inb).
{for each Paper: Position values are sequential from 1} Unique sequence modeled in ORM with a constructor (a) or by introducing Position (b) The uniqueness constraint on the first two roles declares that for each paper an author occupies at most one position; the constraint covering the first and third rolesindicates that for any paper, each position is occupied by at most one author. The textualconstraint below the graphic indicates that the positions in any list are numberedsequentially from 1. Although this ternary representation may appear awkward, it is easyto populate and it facilitates any discussion involving position (e.g. who is the secondauthor for paper 21?). From an implementation perspective, a sequence structure couldstill be chosen: this can simplify updates by localizing their impact. However the updateoverhead of the positional structure is not onerous anyway, given set-at-a-time processing(e.g. to delete author n, simply set position to position–1 for position > n).
Though not shown here, the ternary solution can also be modeled in UML. If the ternary model is chosen as the base model, it would be useful to support the annotatedbinary shown ina)b) as a view of the base model. In ORM we haveshown a unique sequence annotation connected to the relevant role. This representation isequivalent to the {ordered} constraint in UML, as shownb), indicating that theauthors are to be stored as a unique sequence. The unique sequence annotation is not yetsupported by Visio. UML does include “{ordered}” as a standard notation, but it does notyet include notations for other collections, although obvious ones suggest themselves (e.g.
{sequence}).
UML data models from an ORM perspective (part 10) 6 Unique sequence modeled with an annotation in ORM (a) and UML (b) Flat models (no constructors) substantially simplify the declaration of constraints (which typically apply to members, not collections), derivation rules (and hence queries),and avoid arbitrary or non-conceptual decisions about how to store (and possiblyduplicate) fact types and constraints. For example, inhe ORM exclusionconstraint may be verbalized: no Person wrote and reviewed the same Book. Althoughone could use collection types here (e.g. sets of books for an author, or sets of authors of abook) this would be extremely unwise, since it would complicate verbalization,validation, fact expression (possibly duplicated) and constraint expression (possiblyduplicated). In conceptual modeling, we should not have to concern ourselves about howindividual fact types might be stored in structures, or where the constraint code willreside. Such concerns are implementation details, and should be delayed until a clearconceptual picture of the world is obtained.
Pair-exclusion constraint in ORM (a) needs to be captured textually in UML Since UML does not provide a graphical notation for such an exclusion constraint, it should be specified either informally as a note, or formally using a language of choice.
Since OCL includes collection types with predefined operations, and the population of theassociation roles author and reviewer are sets, this constraint can be expressed in OCL asfollows: Bookself.author -> intersection(self.reviewer) -> isEmpty Although this constraint expression is clear enough to somebody with a formalbackground, it is of little use for validating the rule with the subject matter expert UML data models from an ORM perspective (part 10) 7 (typically a business person with little formal training). For such purposes, ORM’sConQuer language is far more suitable.
Next issue
The ten articles in this series have covered UML data modeling issues from an ORMperspective. My next couple of articles will consider other data modeling notations(flavors of ER, as well as IDEF1X) from an ORM viewpoint. Later on, I may return to UMLto discuss its behavioral side.
References
Booch, G., Rumbaugh, J. & Jacobson, I. 1999, The Unified Modeling Language User Guide, Cattell, R.G.G. (ed.) 1997, The Object Database Standard: ODMG 2.0, Morgan Kaufmann Halpin, T. 1995, Conceptual Schema and Relational Database Design, 2nd edn (revised 1999), ter Hofstede, A.H.M., Proper, H.A. & Weide, th.P. van der 1993, ‘Formal definition of a conceptual language for the description and manipulation of information models’,Information Systems, vol. 18, no. 7, pp. 489-523.
Martin, J. & Odell, J. 1998, Object-Oriented Methods: a Foundation, UML edn, Prentice Hall, Upper OMG, UML Specification v. 1.3 final draft, OMG UML Revision Task Force website, http://uml.systemhouse.mci.com/artifacts.htm.
OMG, UML 1.3 Revisions and Recommendations, Appendix A, issues 35-6, document ad/99-06- 11, http://uml.systemhouse.mci.com/artifacts.htm.
Rumbaugh, J., Jacobson, I. & Booch, G. 1999, The Unified Modeling Language Reference Manual, Warmer, J. & Kleppe, A. 1999, The Object Constraint Language: precise modeling with UML, This paper is made available by Dr. Terry Halpin and is downloadable from www.orm.net. UML data models from an ORM perspective (part 10) 8

Source: http://www.orm.net/pdf/JCM10.pdf