Download Supporting Object Models with Relational Databases

Supporting Object Models with Relational Databases
So, what’s the best way to support a UML model with a Physical data model of a relational
database design? The trick is to establish a set of ground rules or patterns for transforming your
UML Class model. By establishing a set of basic patterns, you then have a default transformation
mechanism that the team can use to follow the translation of your model, class by class and
association by association.
General Transformation Rules
Our suggested steps of default transformations are as follows:
1. Set the model’s scope.
o Segregate the persistent objects; your business classes will most likely be the ones
you need to persist (store) in your database.
2. Transform UML classes to relational tables.
o Every UML class becomes a table.
o Every UML attribute becomes a column.
o Every UML attribute type maps to a default data type, size, and precision
controlled by the specific relational database management system (RDBMS)
you’re targeting (Oracle, SQL Server, DB2).
o All nullability defined in the UML attribute is maintained in the column specs
(NULL, NOT NULL).
o Every UML attribute “initializer” becomes a DEFAULT clause.
o Every UML class with no “generalization” or “implicit identity” defined will have
a primary key.
o Consider using surrogate keys for objects with no obvious primary key.
3. Transform UML associations to relationships.
o Every table will define primary key to foreign key constraints for data integrity
and connections for each role in an association (between parent-child or
independent-dependent relationships).
o Every associative class will be deployed as a cross-reference or intersection table.
It will have a multipart candidate key made up of (at least) the primary keys of the
parent tables.
o Every composite aggregation will have a foreign key to the aggregating tables.
o Every many-to-many association that wasn’t resolved with an association class
will be deployed as a cross-reference or intersection table.
4. Transform UML class hierarchies to relational category implementations.
o Choose the default method of handling classes defined as a “generalization” with
subclasses. Use rolled-up categories, rolled-down categories, or expansive
categories for your physical deployment method. Your choice will depend on the
similarity the structure and use of your subclasses.
Information support for control systems Lesson 14 / Student
Page 1/11
o
o
Every different role-named relationship should be considered as a candidate for
an independent list–type table.
For complex class definitions used for attributes, duplicate the complex class’s
basic attributes and data types everywhere that class is used.
Later you’ll follow this process in a small example to show how you can use these
transformations to create relational data models. However, it’s important to note that following
this process will result only in the creation of a draft Physical data model. You may still need to
examine denormalization opportunities or add extra indexes for performance tuning. You can work
out these details of deploy-ment, or tune the physical design, later with the help of the database
administrators (DBAs) after you use a formulaic method for transforming the model.
Transforming UML Classes into Entities
Next, let’s look at some case-by-case examples of how certain partial UML diagrams can
be represented in logical IDEF1X formats. These mini-examples will provide a blueprint for
performing larger transformations.
General Class
This is the simplest set of transformations. Make sure every persistent class is represented
by a table or entity, depending on whether you’re creating a Logical or Physical relational data
model. Also, make sure all data attributes shown in the UML diagram are represented as columns
or attributes in your relational model. A persistent class is any class where the data contained in
that class needs to be stored in the database. Most, if not all, of the classes on your businessoriented class diagram will be persistent (see Figure 5-15).
Figure 5-15: Transforming UML classes to IDEF1X
Association Class
Information support for control systems Lesson 14 / Student
Page 2/11
An association class denotes that for a given association of two classes, there can be only
one resultant association class. This is transformed similarly to a many-to-many association (see
Figure 5-16).
Figure 5-16: Transforming UML association classes to IDEF1X
Note the added subtlety here that, unlike a simple many-to-many relationship, the Book’s
primary key and the Author’s primary key have migrated to be the primary key of the BookAuthor
table, ensuring that only one combination of the two is permitted.
Transforming UML Associations into Relationships
Now that you’ve transformed the UML classes into relational entities, let’s look at how to
represent the UML associations in a relational model.
Associations: One to Many
General associations indicate two objects are associated but that no dependence exists
between the connected objects. As noted earlier, this doesn’t translate perfectly into relational
modeling syntax, but it can be represented effectively as a foreign key constraint linking two tables
(see Figure 5-17).
Information support for control systems Lesson 14 / Student
Page 3/11
Figure 5-17: Transforming UML associations to IDEF1X with one-to-many cardinality
In Figure 5-17, each class is represented by a table, and each association is represented by
one foreign key constraint.
Associations: Many to Many
Many-to-many relationships, as shown in UML, are transformed into Physical data models
in the same way as many-to-many relationships that are part of relational Logical models. In either
case, many-to-many relationships require an intersection entity when physically deployed (see
Figure 5-18).
Information support for control systems Lesson 14 / Student
Page 4/11
Figure 5-18: Transforming UML associations with many-to-many cardinality
To resolve the many-to-many relationship, we’ve created an intersection table to store the
existence of the many-to-many relationship between Book and Author.
Compositions
Composition associations are the most straightforward of UML associations to transform,
since they closely mirror the available relationships in IDEF1X (see Figure 5-19).
Information support for control systems Lesson 14 / Student
Page 5/11
Figure 5-19: Transforming UML composition associations to IDEF1X
The composition association is translated into a one-to-many relationship in the relational
model.
Aggregations
Aggregation associations imply that the members of the aggregation are independent of the
aggregation itself. For example, a high-school chess club is an aggregation whose aggregation
members are the people in the club. However, if the club disbands, the members still exist (see
Figure 5-20).
Figure 5-20: Transforming UML aggregations to IDEF1X
Information support for control systems Lesson 14 / Student
Page 6/11
The aggregation association is represented by a many-to-many relationship. Any specific
control on the cardinality of the relationship will need trigger code or check constraints to perform
the verifications.
Class Hierarchies
Now that we’ve addressed how to transform UML classes and associations into relational
structures, we’ll cover categories, or UML generalizations.
UML generalizations are equivalent to relational categories. There are several ways to
physically implement relational categories (rolled-up, rolled-down, and expanded solutions). The
development team needs to evaluate the physical implementation options and choose a preferred
category of physical design. These same options exist when creating a physical design for UML
class hierarchies. Figure 5-21 shows an example of a UML class diagram, a Logical IDEF1X
relational model, and a Physical IDEF1X relational model.
Information support for control systems Lesson 14 / Student
Page 7/11
Figure 5-21: Transforming UML generalizations to IDEF1X (rolled-up categories)
In Figure 5-21, you first see a UML representation of a project team member, implemented
as a hierarchy. A project teammate can be an Author, a Reviewer, or an Editor, and the grouping
isn’t mutually exclusive (a teammate can be a Reviewer and an Author). However, the italics in
the supertype ProjectTeamMate indicates that it’s abstract, meaning that each team member must
be at least one of the subtypes.
Information support for control systems Lesson 14 / Student
Page 8/11
Next, you can see how the UML supertypes and subtypes have been transformed into an
IDEF1X Logical model. The UML generalization and the IDEF1X Logical model are similar when
it comes to representing this kind of structure.
Lastly, Figure 5-21 shows the UML and IDEF1X Logical model represented in a Physical
model. The three subtypes have been “rolled up” into the ProjectTeamMate table, and the attribute
of TeamMateTypeCd indicates which of the three subtypes apply to a given team member. In this
case, we’ve chosen a rolled-up category structure for the physical implementation, but other
options are also available.
Figure 5-22 shows a slightly more complex example so you can actually see the UML
notations being translated into the IDEF1X physical design.
Information support for control systems Lesson 14 / Student
Page 9/11
Figure 5-22: Transforming UML generalizations with associations to IDEF1X
In Figure 5-22, you can see a similar example to Figure 5-21. In this case, we’ve
complicated the model somewhat by creating an Address class that applies to all team members,
Information support for control systems Lesson 14 / Student
Page 10/11
including a Book class that’s related to the Author subtype and an ApprovalLevel class that’s
related to the Editor subtype.
In this example, we skipped transforming the UML class diagram to an IDEF1X Logical
model, and instead we went straight to a Physical model. We again chose a “rolled-up” physical
solution for our categories and combined the subtypes and supertype into one physical table called
ProjectTeamMate. Note that in this case, we’ve added an Address table that’s mandatory for each
team member and an optional ApprovalLevel table that will represent the approval level given by
the Editor.
Information support for control systems Lesson 14 / Student
Page 11/11