Making the Transition from ERD’s to UML and Oracle’s Object Database
Designer
Overview
UML is not simply a replacement for Entity Relationship Diagramming. It is a complete, integrated object-modeling environment with “n” parts. The class diagrams included in the UML alone are contenders for replacing entity relationship models. Make no mistake – UML is the emerging standard. We no longer operate in a development environment where there will be many competing modeling standards. Many of the leading names in the object-oriented software community, including Oracle combined their talents to form a consortium and developed a unified modeling standard. The other companies that participated were HP, I-Logix, ICON Computing IBM, MCI Systemhouse, ObjecTime, IntelliCorp and James Martin & Co., Platinum Technology, Rational Software, Taskon, Sterling Software, and Unisys.
Despite its advantages over ER diagramming, UML is not without its weaknesses. In some ways, UML diagrams have more symbols making them more cluttered and therefore less easily understood by users. This may be due to the fact that UML was not explicitly created to support database design. However, class diagrams in UML are a superset of entity relationship modeling. There is nothing that can be expressed with ERD’s that cannot be expressed in UML notation; and there are many more structures and relationships possible to express in UML that are not possible with ERD notation.
A major strength of UML is that it is explicitly extendable. If there are things we need UML to do that are not inherent within UML standard, vendors such as Oracle are free to create additional objects to support the specific needs of their environments. This openness of UML architecture raises the specter of deviation from the standard. However, UML is rich enough that such deviation should be minimal and easily controlled.
UML is here to stay. One could argue that it is already the standard for all object-oriented development. UML can and should be used now for both logical and physical relational database modeling. The only reason not to make the shift now is that we do not currently have the products to support this shift. As the relational environment migrates to an object-relational environment, UML will also become the standard for database development.
Shifting from ERD to UML
It is not difficult to shift from basic ERD to UML terminology as shown in Table 1.
|
ERD Term |
UML Term |
|
entity |
class |
|
instance of an entity |
object |
|
relationship |
association |
|
supertype/subtype |
generalization |
|
relationship dependency (UID bar) |
composition (usually, but not always) |
|
attributes |
attributes |
Table 1: ERD – UML Terminology
Any ER diagram can be easily mapped to a UML diagram. For example, arcs (exclusive ORs) are represented by a dotted line in UML diagrams. In addition, many structures that cannot be represented in an ERD can be represented in UML as shown in Figure 1.
Figure 1: ERD relationships translated into UML notation
Classes also have operations. You can declare what sort of behavior can be associated with a particular class.
UML Naming Conventions
In ERDs, there were two sides of a relationship to name. In UML, there are not only object role names attached to each side of the relationship, but we also have the option of placing a name and a direction on the relationship itself. The ends of the relationship are called “Association roles.” This concept of a role works very well in many cases. For example, between Department and Person, for the employment relationship between the two using the full UML notation would be as shown in Figure 2.
Figure 2: Roles in UML
This diagram reads as follows: “The department acting as employer may employ any number of persons as employees.” Linguistically, the UML notation includes the role that each object in the class is assuming in the relationship expressed with a noun on each side. The relationship itself is expressed with a verb and preposition. This notational scheme holds up fairly well. However, sometimes it is difficult to determine the appropriate word to describe the roles of the objects. Also, if you are creating abstract models where the same relationship might represent more than one type of association, the naming becomes somewhat more complex.
There are times when the same ERD verb phrases that we used on relationships still work well with UML models. We always use a “relationship phrase” consisting of a noun or verb followed by a preposition. Additionally, if required to enhance the clarity of the diagram, we will use roles on the relationship ends. Note that in using this “relationship phrase” in the case of a 1:many relationship, it is usually more descriptive to name the relationship going from the child (many) side to the parent (one) side of the relationship. For example, to describe the Dept/Emp example, “works for” usually seems easier to understand than “employer for.”
Extensibility of UML
The UML designers allowed for the possibility that UML might not be able to satisfy the modeling needs of everyone. Because UML was designed to support object-oriented programmers, it sometimes falls short in supporting object-relational database modeling. Using UML, you can either extend the existing functionality or create new types. UML provides three mechanisms to extend the UML notation: Stereotypes, Constraints and Comments. Stereotypes and constraints are keywords that can be attached to any UML element to alternate meaning or functionality.
For example, this is very useful if you have a many-to-many association between two classes. This can be drawn with an association diagram as shown in Figure 3.
Figure 3: “ERD” – style representation of many-to-many relationship
In this UML diagram, an association means that a student can only take a class one time. This may be satisfactory for this example. However, this would not be true for the relationship between a Department and an Employee. The Employment History of an Employee may include his/her being employed by the same Department more than once. In this case, the stated UML conventions are too restrictive.
Stereotypes
It is often difficult to determine whether a keyword should be designated as a stereotype or a constraint. Keep in mind that if you are limiting existing behavior or functions, a constraint should be used. If you are redefining or extending behavior, then a stereotype is appropriate.
Stereotypes designated by «guillemets» extend or redefine an element. There are pre-defined stereotypes such as “Abstract” for class. However, users can also create their own stereotypes to alter or extend the semantics of UML.
We need to extend the functionality of the relationship between Department and Employee. This can be done with the stereotype <<duplicates allowed>> as shown in Figure 4.
Figure 4: UML diagram showing stereotype
Constraints
UML can also be extended through the notion of constraints. This is one of the great strengths of UML in comparison to ER diagramming. Constraints designated with curly set brackets { } limit the functionality of the UML object. There are native constraints defined by UML such as the “Or” constraint on an association between relationships. However, additional constraints may be defined by the user.
For
example, a recursive relationship on an entity provides no indication whether
the real situation being modeled is a regular tree structure, tree of finite
height, linked list or other similar structure, which would all be modeled in
the same way using entity relationship constructs. In UML, you can explicitly
constrain the relationship in a very precise way. For example, a recursive
relationship on the class Employee can be indicated by the constraint {tree} as
shown in Figure 5.
Figure 5: Comparison of ERD and UML diagram of recursive tree relationship
Comments
Another useful example of the extensibility of UML is that we can create a syntax for attaching comments to a diagram. In the class diagram, comments are graphically represented text objects that can be attached to any UML object. Comments are useful for declaring data-related business rules that could not be represented otherwise.
We can create a new type of comment called “Business Rule,” which can be placed as appropriate in our UML diagrams in order to make them cleaner, as shown in Figure 6.
Figure 6: Example of diagram with comment attached
Associations
Naming associations is done differently in UML than in entity relationship diagramming. Rather than naming both sides with verb phrases as in ERD’s. In UML, the relationship is named once and a directionality arrow is added, usually pointing from the “many” side to the “one” side of the relationship. In addition, in UML notation, you can also declare the role that the objects in each class play in the relationship as shown in Figure 7.
Figure 7: Comparison of naming associations in ERD and UML
In Figure 7, the Employee, acting in the role of worker “works for” the Department, which acts in the role of employer. This ability to declare what role the object plays in the relationship provides greater flexibility in accurately naming associations.
Generalizations
Generalizations in UML are somewhat more flexible than Supertype/Subtype relationships in ERDs. There need not be only one generalization structure from a given class. We are able to have multiple generalizations operating on the same classes, as shown in Figure 8, an example of a consulting contract, which can be Time and Materials or Fixed Cost and independently classified as Government or Private.
Figure 8: Examples of multiple generalization relationships
Eventually, we hope that UML will evolve so that fewer relationships remain untyped. This notion of “Typing” a relationship will be somewhat difficult for most ER modelers since the types of relationships in ER modeling are quite limited. ER modelers should be very careful not to fall into the trap of using UML to simply draw their ERDs with a different notation.
Using Oracle’s Object Database Designer (ODD)
Oracle8 is not the first Oracle product to include object-oriented thinking. In Forms 4.5 we had our first taste of object orientation through property classes. We could set and enforce standard sets of properties for any object in our applications. PL/SQL used with libraries and object groups was a rich enough set of features to provide us with some ability to create reusable program components. A few of us even went so far as to encapsulate whole parts of our applications into reusable structures. Now the products are starting to better support this evolution to object-oriented thinking. The introduction of UML as a data modeling language significantly improved upon our ability to capture complex business rules in a data model.
Oracle has now released a new modeling tool, the Object Database Designer (ODD). ODD has been integrated into Oracle Designer so that both modeling techniques are based on the same set of tables and views. UML provides far more flexibility in the definition of our data models. Oracle’s ODD allows us to develop detailed data models that serve us throughout the system development life cycle, as well as the ability to generate DDL from them.
However, in Oracle Designer’s ODD, many of the important features of UML have not yet been implemented. This does not mean that object-relational databases are a bad idea, just that they are still evolving. In the next few years, object-relational databases will completely supplant traditional relational databases as the standard for new systems. In Oracle Designer we need a full implementation of the UML class diagrams in the Object Database Designer, and we need to see some other parts of UML make their way into the product. We also need to be able to generate modules to the object structures.
Conclusions
It is clear that object-relational databases are the wave of the future. However, we are not ready to build production object-relational systems. First, the Oracle8 object extensions need to go through another iteration. At a minimum, we need inheritance to be able to say we have an object-oriented system. We waited for ten years to get our relational databases to support objects let us hope we can get inheritance more quickly. We also need improved performance and some improved ability to modify object structures once they are built.
About the Author
Dr. Paul Dorsey is the President of Dulcian, Inc., an Oracle consulting firm that specializes in data warehousing, systems development and products that support the Oracle environment. Paul is co-author with Peter Koletzke of Oracle Press’ Oracle Designer Handbook and with Joseph Hudicka of Oracle Press’ Oracle8 Design Using UML Object Modeling. Paul is an Associate Editor of SELECT Magazine. Paul is also collaborating on a book about Oracle Developer. He is President of the NY Oracle Users’ Group and very active in the Oracle user community. Paul has won best presentation for both ECO and IOUW and was a finalist for best presentation at ODTUG. He and Peter Koletzke shared the Pinnacle Publishing Technical Achievement Award at ECO for their work on an Oracle Forms template. Paul can be contacted at pdorsey@dulcian.com or through Dulcian’s Website at http://www.dulcian.com/.