Моделирование бизнес-процессов / Моделирование бизнес-процессов / ERwin_Insider

Entity VS Class

On the surface, an entity and a class are similar. Each is the corner stone of their respective paradigm. Both are containers for the lowest level element of the models, the attribute. In fact, entities can be called a simple type of class. A class is “ the descriptor for a set of objects with similar structure, behavior, and relationships.”2 A class is the structure to which all attributes and operations are attached. Object modelings merging of process with data is where lies the greatest difference, from the perspective of the data modeler. An operation, or method, is the service that can be requested from any object of the class to affect behavior” 3. Encapsulated within the class may be procedural code sets which perform operations on the attributes contained therein and there by affect the behavior of the class. For the purposes of this discussion an entity could be called a class without any operations.

At first glance the inclusion of operations into the class may seem like a hugh and dramatic difference to the relational entity. However, as will be discussed later in this article, the relational world has the stored procedure, a close equivalent to the operation, although it is not actually encapsulated within the entity itself.

The presence of behavioral operators in a class, can result in creating issues which the entity may not be faced with. The combination of attributes and operations into the same structure could create situations where certain operation require certain attributes also required by operations in other classes. There may then be a tendency to duplicate the attribute in more than one class. This creates redundancy, and hence a denormalization which can cloud business rules. It is for this very reason, along with the relational models simplicity, that many believe it is essential to create a purely relational model prior to creating an object relations or purely object model.

Graphically the IDEF1X entity table and the UML class are almost identical.

Relationships VS Associations

In IDEF1X, relationships are represented by solid or broken lines with a filled circle (“the meatball”), the solid line represents an identifying relationship, and a broken line represents a non identifying relationship. The difference being in where the contributing key in the relationship is placed. If the contributed key, or foreign key, becomes part of the key of the child (becomes part of a multiple part key) the relationship is “identifying”. This means the key migrating from the parent to the child becomes part of the identity (the key) of the child. If the contributing key, or foreign key becomes a non key attribute in the child entity, then the relationship is considered to be “non identifying”. (Identifying and non identifying relationships are discussed further in the section entitled DIAMONDS VS NULLS. Key migration is a concept that does not exist in UML, as the object paradigm does not use natural primary keys to identify classes. UML relys solely object id’s (OID’s) a.k.a. surrogate keys. Hence, UML, only has the solid line to represent class to class relationships, or associations as they are called in UML. (Note that there are

2p. 42 The Unified Modeling Language Reference Guide by Rumbaugh et. al. 1999 Addison Wesley

3p. 49 The Unified Modeling Language User Guide by Grady Booch et. al 1999 Addison Wesely

other types of relationships in UML, a few are mentioned in later sections of this document, most of the others are beyond the scope this discussion.)

They ability to provide the option for identifying and non identifying relationships is an advantage IDEF1X and the relational paradigm have over UML and the object paradigm. The relational database designer has the choice whether to use natural or surrogate keys. Natural keys offer an alternative that provides key contribution which makes relationships with other entities immediately identifiable and provides a hierarchical road map, which can make life easier for programmers. When natural keys are migrated down through a hierarchy fewer joins may be required when creating SQL queries. Natural keys also help reduce the chance of rows containing duplicate information. Identifying relationships have been referred to (in the non IDEF1X world) as transferable relationships.

Figure 4

Keys vs OIDS

The use of OID’s in the object paradigm restricts keys to surrogates only and also creates other critical differences between IDEF1X and UML. These will be discuss in later sections. The natural VS surrogate key debate has been given much attention on technical publications and web forums. The object paradigms use of OIDs can have a serious implication with regard to data redundancy, and highlights a significant difference versus the relational paradigm. One the other hand OID’s offer an easier path to achieve greater levels of normalization and make for an easier transformation from OLTP to data warehouse. Further discussion is beyond the scope of this study.

As you will notice in many of the figures below, OID’s are not visible in an object class. The attributes person id, committee id, have been added to these classes so that the user can identify the particular instance of the class. These are not the keys used internally by the database to uniquely identify the instance of the class. This creates a situation that is, as C. .J. Date calls, “specious”4. This can occur because “two distinct objects can be identical in all user respects - i.e. be duplicates of one another – and yet be distinguished via their OID’s….how can the user distinguish between two such objects, externally?”5

Cardinality VS Multiplicity

Cardinality and multiplicity are terms which are used inter-changeably to mean the number of instances that appear at each end of a relationship. Cardinality is the term used in the relational world and multiplicity is the term used in much of the object world.

4p. 638 An Introduction to Database Systems (6th Edition) by C.J. Date 1995 Addison Wesely

5ibid

Thomas Bruce, the author of the definitive text on IDEF1X defines cardinality as “A statement of the number of entity instances that may or must participate at each end of a relationship”6.

According to Rumbaugh cardinality is a misnomer. Cardinality means size whereas multiplicity means a set of numbers. Rumbaugh states that “ The term cardinality is misused by many authors to mean what we call multiplicity, but cardinality has long standing mathematical definition as a number, not a range of numbers.”7 8

For the most part, relational authors use the term cardinality, object authors use the term multiplicity.9 For the purposes of the transitional layer, relational, object, and object relational developers just have to know that they are essentially referring to the same thing. For clarity sake, we will use the term cardinality

when referring to relationships in IDEF1X, and multiplicity when referring to relationships (associations) in UML.

IDEF1X Cardinality

Cardinality in relational/IDEF1X is simple. Cardinality is one sided in that relationships are always one to “something” relationship. One to many, one to one or more etc. Figure 5 shows how IDEF1X graphically represents cardinality.

Figure 5

On one side of the relationship there is no notation which indicates a cardinality of 1. On the other side of the relationship line is the filled circle which indicates a cardinality of many. An accompanying number or letter refines the many to a more specific value.

The letter “P” indicates cardinality of one or more. The second relationship line shown above, therefore, is a one to one or more relationship. The letter Z indicates zero or more. Hence, the third relationship in figure 5 is a one to zero or more relationship. A number indicates a fixed value. The fourth relationship in figure 4 is the graphic representation of a one to five relationship.

I found IDEF1X’s alpha representations for numeric values to be a bit awkward, and easy to mix up or forget what they mean. This is especially the case if these cardinality values are not used often. As indicated in the next section UML’s notation is much clearer in this regard and does not have to rely on alpha characters to represent numeric values.

Each of these representations will be discussed in greater detail and in comparison to UML in the ensuing sections.

6p. 528 Designing Quality Databases with IDEF1X Information Models by Thomas Bruce 1992 Dorset House

7p. 183 The Unified Modeling Language Reference Guide by Rumbaugh et. al. 1999 Addison Wesley

8For a comprehensive review of the books in the UML series, two of which are quoted in this discussion, see a

column by Scott Ambler in the June 1999 edition of Software Development Magazine. (www.sdmagazine.com)

9 It is interesting to note some examples. In the Oracle Press’ Oracle 8 Design Using UML Object Modeling by Dr. Paul Dorsey and Joseph R. Hudicka, 1999 McGraw-Hill, an object-relational book, the term cardinality is used exclusively. The word multiplicity does not appear in the book.

In Object Oriented System Development by de Champeaux et al 1993 Addison Wesley, the term cardinality is used as well.

I suspect that the object realtional word will become eclectic, freely interchanging both terms.

UML Multiplicity

Multiplicity can be extremely precise and hence can become extremely complex. The data base designer has the ability to indicate a set number of instances, ranges of instances and intervals, a specific number set of instances where the number monotonically increases. As shown in figure 5, a fixed set of instances of a class is show by one value representing the number of instances in that set.

Ranges are graphically display by showing the beginning and ending numbers with an ellipses between the two numbers as shown in the last example in figure 6.

UML multiplicity also offers that ability to show a combination of interval and range of numbers.

Figure 6.

A dramatic advantage offered by UML is the ability to represent multiplicity sets on both sides of an association, as show in Figure 7. This allows for the display of very complex business rules as discussed in the section entitled Complex Relationships.

Figure 7

Multiplicity values on both sides of an association can, at first, be confusing. A device I found useful to keep a straight head on the double edge sword is as follows: When looking at the multiplicity value on one side of the association think of the expression, “for each one of the other guy I can have this many of me”.

Taking Figure 8 as an example;

Figure 8.

For every one occurrence of PERSON, I can have many occurrences of SECURITY PROFILE. (An asterisk indicates the multiplicity of many.

Ranges in IDEF1X

The Federal Information Processing Standards Document 184, (a.k.a. FIPS 184), is the government standard in which IDEF1X rules are defined. According to FIPS 184 representation of ranges in an IDEF1X diagram is valid for the language. Figure 9 is part of FIPS 184 section 3.5.2 and indicates how ranges are to be graphically shown in an IDEF1X diagram.

For some reason the ability to represent ranges was not picked up by Thomas Bruce in his book on IDEF1X, nor was it included in by Logic Works10 in ERwin, the premier IDEF1X modeling tool.

Figure 9.

Relationships VS Associations

According to Bruce, an IDEF1X relationship is “a connection between two entities in which each primary key attribute of the parent entity becomes a foreign key attribute of the child entity.”11

The UML Reference Manual states that a UML association is “The semantic relationship between two or more classifiers that involves connections among their instances.” 12 Except for the migratory key issue, relationship and an association are essentially the same thing. They connect entities/classes and are the bearers of cardinality/multiplicity rules.

10Logic Works was bought out by Platinum Technology in 1998 which was purchased by Computer Associates in early 1999.

11P. 536 Designing Quality Databases with IDEF1X Information Models by T. Bruce 1992, Dorset House

12p. 152 The Unified Modeling Language Reference Manual by J. Rumbaugh, 1999 Addison Wesley

One to One VS Many to Many

There can be a bit of confusion with regard to the cardinality/mu ltiplicity of the unadorned solid line when traversing from IDEF1X to UML. FIPS 184 represents a one to one relationship (identifying) as a solid line with out any cardinality notation at either end (see figure10).13 On the other hand a UML association with out any multiplicity notation is defined as a many to many association.

The solid line referring to a many to many association is the correct representation as defined in the UML series. However, we found that not all object tools are in agreement with that representation. Similar to the IDEF1X representation, Paradigm Plus accepts the unadorned association to mean a one to one object relationship. Care must be taken when transferring back and for between paradigms to assure that the cardinality/multiplicity of the unadorned solid line is not confused.

Figure 10

One to One Relationship

Figure 11 displays how one would represent a one to one relationship in both paradigms. The upper portion of the panel shows it in IDEF1X with ERwin graphical extensions (The box indicates an entity and the key indicates that the attribute is a key.), as compared to the a UML one to one relationship in the lower portion of the panel. (figure 11 follows UML rules as defined in the UML Guide.14)

13The one to one relationship represented as a solid line is no longer supported as of ERwin release 3.5. However, it is a valid IDEF1X representation as defined in FIPS 184.

14P. 347 The Unified Modeling Language Reference Guide by Rumbaugh et. al. 1999 Addison Wesley

Figure 11

Simple Relationships

Figure 12 through Figure 15 show comparative representations of uncomplicated cardinality / multiplicity in IDEF1X VS UML. Note the UML allows for the multiplicity of zero one or more to be represented by either the zero followed by an ellipses, followed by an asterisk, or the asterisk alone. (Refer to Figure 16 later in this document.)

Figure 12

Figure 13

Figure 14 and Figure 15 show how UML’s more robust multiplicity notation can make “reading” somewhat easier.

Figure 14 contains a comparison of the zero or one to zero or one relationship. UML’s ability to show ranges on both sides of the relationship make this very clear. All that is needed is the ‘0..1” on both sides of the relationship.

IDEF1X however, requires three elements to represent the same thing. The unfilled diamond shows that the left

side of the relationship can have no value, the Z on the other side of this relationship adds the “or one” constraint to the left side of the relationship, and the zero or one cardinality to the right side. In addition, the relationship must be non identifying.

Figure 14

Figure 15 compares the relationship of one to zero one or more. Figure 16 shows two valid UML notations for the expression zero, one or more.

Figure 15

Figure 16

Figure 17 demonstrates how UML’s use of multiplicity on both sides of an association can be much more expressive than IDEF1X, especially when it comes to use of the alpha characters to represent cardinality. Shown below is a one to one or more relationship.

Figure 17

Succinct Relationships

The dual sided multiplicity values provide the ability to present certain more succinct relationships which cannot be expressed in IDEF1X. Figure 18 shows two relationships which fall into this category. The one or many to one or many relationship and the many to one or many relationship.

Figure 18

The explicit multiplicity on the left side of each association shown here can only be shown in IDEF1X in a more generic notation expressing the cardinality of zero, one or more.

Many to Many Relationships

A many-to-many relationship is a relationship between two entities when each instance of the first entity can be related to many instances in the second entity, and vice versa. In IDEF1X notation, a many-to-many relationship as a solid line with a solid dot on both the child end and the parent end. A many to many relationship can also be defined more descriptively as a zero, one or more to zero one or more relationship. Figure 19 compares the graphic representations of a zero one or more to zero one or more relationship in both IDEF1X and UML.

Figure 19

The relational database uses flat tables as it’s basic structure and therefore relationships can only be physically expressed as binary relationships (relationships between exactly two occurrences). A many to many relationship is