A Taxonomy of Recursive Relationships and Their ... - CiteSeerX

A Taxonomy of Recursive Relationships and Their Structural Validity in ER Modeling James Dullea 1 and Il-Yeol Song2 1

Boeing Phantom Works, The Boeing Company, Philadelphia, PA 19142 Email: [email protected] 2 College of Info. Science and Technology, Drexel University, Philadelphia, PA 19104 Email: [email protected]

Abstract. In this paper, we present the complete classification of recursive relationships and the criteria that contribute to the structural validity of modeling recursive relationships within the entity-relationship (ER) diagram. Unlike typical other analyses that use only maximum cardinality constraints, we have used both maximum and minimum cardinality constraints in defining the properties and their structural validity criteria. We used the notions of role uniqueness, path connectivity, and cardinality constraints to derive a complete and comprehensive set of decision rules. Five rules and three corollaries were established to determine structural validity of recursive relationships. The contribution of this paper is to present a complete taxonomy of recursive relationships with their properties as well as the decision rules for their structural validity. These decision rules can be readily applied to real world data models regardless of their complexity. The rules can easily be incorporated into the database modeling and designing process, or extended into case tool implementations.

1.

Introduction

Entity-relationship (ER) modeling [4] is the foundation of various analysis and design methodologies for the development of information systems and relational databases. A key measure of success in the design of these models is the level that they accurately reflect the real world environment. A model can be a very complex abstract structure, and designers are highly prone to making many mistakes that incorporate inconsistencies into the structure. There is various supporting empirical evidence [2, 5, 9] that concludes errors, mistakes, or inconsistencies made in the early stages of the software development life cycle are very expensive to correct. Boehm [3] states that the cost difference to correct an error in the early phases as opposed to the post-implementation phase is on the order of a ratio of one to one hundred. Left undetected these inconsistencies become very costly to correct, so early discovery of an error is highly desirable. The structural validity of an ER diagram is concerned whether or not a given ER diagram contains any constructs that are contradictory each other. An ER diagram with at least one inconsistent cardinality constraint is structurally invalid. Deciding whether a particular ERD is valid or not is sometimes a difficult issue to many database designers. For example, how do we know whether the diagram shown in Figure 1 is valid? In this

1

paper, we present decision rules whether a particular recursive relationship, also referred to as a recursive relationship, is valid or not. We explain why Figure 1 is invalid in Section 4 using our decision rules. 1 PARTNER_OF

1 EMPLOYEE

1

MANAGE

M M WORKS_ON

1 1 SUBSTITUTE

PRODUCT

M

Figure 1: An ERD with Invalid Recursive Relationships Direct treatment of structural validity as a concept is rare in the literature. Some structural validity rules are partly discussed in other publications, such as [15, 1, 8, and 14], but they don’t exhaustively cover all the combinations of maximum and minimum cardinality. Indirect treatment of the subject materials are usually confined to making buttress points concerning other issues. Structural validity in the literature has almost always been treated as a property of a study; in this paper we treat it as the object of our study. In our study we evaluate each relationship type as part of the overall diagram and address how they coexist with other relationship types within the model. The structural validity of ternary relationships has been addressed in [11, 7]. In this paper we focus on recursive relationships. In the literature, only two types of recursive relationships - symmetric and asymmetric [15, 6] and their validity [6] are discussed. In this paper, we discuss five different types of recursive relationships by further defining the concept of an asymmetric association into hierarchical, circular, and mirrored relationships. We also introduce the concept of a hybrid relationship by combining the concepts of a circular and hierarchical association. By expanding the work of [6], we present a complete taxonomy of recursive relationships and decision rules for checking the validity of those various recursive relationships. Figure 2 shows a simple entity-relationship diagram containing several recursive relationship types of different semantics. The correct interpretation and validity of these recursive relationships are only possible with both minimum and maximum cardinality. The work presented in our paper will show generalized decision rules for this diagram and any other ER diagrams, and will show what cardinality constraints are allowed and disallowed for all recursive relationships.

2

Circular Relationship

BACKS-UP

MARRIED _TO

EMPLOYEE

Reflexive Relationship

MANAGES

Hierarchial Relationship

SELFMANAGES

Mirrored Relationship

Figure 2: A plausible ER diagram containing various recursive relationships. Unlike typical other analyses that use only maximum cardinality constraints, we have used both maximum and minimum cardinality constraints in defining the properties and validity criteria. Our analysis yields a complete and comprehensive set of decision rules to determine the structural validity of any recursive relationships. The decision rules use the notions of role uniqueness, path connectivity, and cardinality constraints. These decision rules can be readily applied to real world data models regardless of their complexity. The rules can easily be incorporated into the database modeling and designing process, or extended into case tool implementations. This paper is organized into five sections. In Section 2 the concepts of semantic and structural validity are discussed and defined. Section 3 presents the taxonomy of recursive relationships and discusses the details of decision rules for checking the structural validity of recursive relationships. Section 4 summarizes all the decision rules and corollaries with examples. Section 5 concludes our paper.

2.

Validity

An entity-relationship model is composed of entities, the relationships between entities, and constraints on those relationships. Entities may be chained together in a series of alternating entities and relationships, or may participate singularly with one or more relationships. The connectivity of entities and relationships is called a path. Paths are the building blocks of our study in structural validity analysis, and visually define the semantic and structural association that each entity has simultaneously with all other entities or with itself within the path. The terms, structural and semantic validity, are defined as follows:

3

Definitions: An Entity Relationship Diagram is structurally valid only when simultaneous consideration of all structural constraints imposed on the model does not imply a logical inconsistency in any of the possible states. An Entity Relationship Diagram is semantically valid only when each and every relationship exactly represents the modeler’s concept of the application domain. In data modeling, validity can be classified into two types: semantic and structural validity. A semantically valid ERD shows the correct representation of the application domain being modeled. The diagram must communicate exactly the intended concept of the environment as viewed by the modeler. Since the semantic validity is application-dependent, we cannot define generalized validity criteria. Therefore, we do not consider semantic validity in this paper. The structural validity of an ER diagram is concerned whether or not a given ER diagram contains any constructs that are contradictory each other. An ER diagram with at least one inconsistent cardinality constraint is structurally invalid. A structurally valid ERD represents the application semantics in terms of maximum and minimum cardinality constraints. The driving force behind cardinality constraint placement is the semantics of the model. The values and placement of these constraints must be robust enough to convey the business rules exactly intended by the modeler while being consistent with respect to the whole model in order to reflect the real world environment. The model is not just a set of individually constrained relationships pieced together between sets of entities, but a holistic view of the representation domain. Each set of cardinality constraints on a single relationship must be consistent with all the remaining constraints in the model and over all possible states. In a recursive relationship the association between role groups within a single entity is semantically invalid when the diagram does not reflect the business rules as defined by the user community. A recursive relationship is structurally invalid when the cardinality and participation constraints do not support the existence of data instances as required by the user. A structurally invalid diagram reflects semantically inconsistent business rules. In order for a model to be valid all the paths in the model must also be valid. Our analysis will investigate those types of structural paths in an entity-relationship diagram that are critical to validity of the entire diagram. Our study will focus primarily on the structural validity of the recursive relationships represented in an ER diagram.

3.

Recursive Relationships

Section 3.1 presents our taxonomy of recursive relationships and Section 3.2 presents the complete decision rules for checking the validity of recursive relationships.

4

3.1. The Taxonomy of Recursive Relationships A recursive (or unary) relationship is defined as an association between instances as they take on roles within the same entity. Roles play an important part in the examination of structural validity, especially for recursive relationships. A role is the action or function that the instances of an entity play in a relationship [12]. In a recursive relationship, a set of instances may take on a single role or multiple roles within the same relationship. Examining these roles allows us to classify all recursive relationships into symmetric or asymmetric associations while further classifying asymmetric relationship types into hierarchical, circular, and mirrored associations. The complete classification of recursive relationships we consider in this paper is shown in Figure 3 as follows:

Recursive Relationships Symmetric (Reflexive)

Asymmetric (Non-reflexive) Hierarchical

Circular

Mirrored

Hierarchical-Circular Figure 3: Taxonomy of Recursive relationships

A recursive relationship is symmetric or reflexive when all the instances participating in the relationship take on a single role and the semantic meaning of the relationship is exactly the same for all the instances participating in the relationship independent of the direction in which it is viewed. These relationship types are called bidirectional. For example, if instance I 1 is associated with another instance I 2 in the same entity through relationship R and the I 2 is associated with I 1 using exactly the same semantics of relationship R then the relationship is symmetric. Relationships such as “dance partner of”, “spouse of”, and “sibling of” are symmetric relationships. A recursive relationship is asymmetric or non-reflexive when there is an association between two different role groups within the same entity and the semantic meaning of the relationship is different depending on the direction in which the associations between the role groups are viewed. These relationship types are called unidirectional. For example, the instances of an entity EMPLOYEE associated though a relationship called SUPERVISES contain two roles groups. The role groups are “supervisor employees” and “supervised employees”. In one direction the relationship is viewed as ‘supervisor employees supervise supervised employees’ while in the other direction the relationship is viewed as ‘supervised employees are supervised by supervisor employees’. Previous studies [6, 15] of what here is described as a symmetric or reflexive relationship implicitly suggested that the only other relationship type to be investigated

5

would be an asymmetrical relationship. In this study we further classify the concept of an asymmetric relationship type into three non-reflexive recursive relationship types: hierarchical, circular, and mirrored relationships. A recursive relationship is hierarchical when a group of instances within the same entity are ranked in grades, orders, or classes, one above another. It implies a beginning (or top) and an end (or bottom) to the ranking scheme of instances. An example of a hierarchical recursive relationship is the entity EMPLOYEE and the relationship SUPERVISES. In this relationship some employees supervise other employees. There is usually an employee at the top who is not supervised by any other employee and employees at the bottom who do not supervise any employees. A recursive relationship is circular when an asymmetrical recursive relationship has at least one instance that does not comply with the ranking hierarchy. The relationship is unidirectional in that it can be viewed from two directions with different semantic meaning. An example of this occurrence is an entity representing lifeguards positioned around a lake where each lifeguard backs-up the lifeguard to their right when an emergency occurs. For example, lifeguard L backs-up lifeguard R while lifeguard R isbacked-up by lifeguard L. The relationship in this example is completely circular because no hierarchy was established between lifeguards. We can also develop a hybrid by introducing a hierarchy to the lifeguard instances. If the business rules were changed to allow only senior lifeguards to backup many other lifeguards, then we would have a hierarchical-circular relationship. This type of relationship is common among decision-makers where a management employee of a lower rank assumes the responsibilities of a more senior manager during their absence. Another question that arises in the modeling of recursive relationships is whether an instance can be associated with itself. This event is impossible in relationships above degree one but could happen in special cases of a recursive relationship and we call this special event a mirrored relationship. A mirrored relationship exists when the semantics of a relationship allow an instance of an entity to associate with itself through the relationship. For example certain individual contributors in an organization could be self-managed while other individuals report up the management chain. Two relationships would be required to model the supervisory concept. Figure 4 shows the diagram that addresses this issue. 1 1 EMPLOYEE

SELF MANAGES

MANAGES

1 M

Figure 4: An entity with two asymmetrical recursive relationships addressing selfmanagement issues. Table 1 summarizes each recursive relationship by its directional properties, the combination of minimum and maximum cardinality constraints, and examples. In our diagrams throughout this paper, we use ‘One (1) and Many (M)’notation for maximum cardinality and the symbols “#” and “)” to indicate mandatory and optional cardinal-

6

ity [13], respectively. Also, the notation |E| represents the number of instances in entity E. Type of Relationship Symmetrical (Reflexive)

Hierarchial

Direction of Relationship

Participation Constraints

Bi-Directional

Uni-Directional

Cardinality Constraints 1

1

M

N

1

M

1

1

M N Circular

Uni-Directional

Asymmetrical (Non-Reflexive) Hierarchial Circular

Person

Supervises Is Supervised By

Manager Employee

Supervises Is Supervised By

Manager Employee

1

Backs Up Is Backed Up By

Lifeguard

1 1

1 M

Backs Up Is Backed Up By

DecisionMaker

Supervises

Manager Employee

Uni-Directional

1

Uni-Directional

Spouse of

1

M N Mirrored

Example Relationship Role(s)

1

Is Supervised By Self Manages Manages Self

CEO

Table 1: Valid Recursive Relationship Types as they relate to the cardinality constraints

3.2 Decision Rules for Validity Checking In this section, we analyze recursive relationships from the point of view of cardinality and participation constraints. Table 1 pairs each valid set of constraints with the different recursive relationship types. For example, symmetrical relationships are supported by ‘One-to-One’ or ‘Many-to-Many’ cardinality constraints coupled with either ‘Optional-Optional’ or ‘Mandatory-Mandatory’ participation constraints. Only these constraint combinations are valid for a symmetrical relationship. These constraints along with others also are valid in hierarchical and hierarchical-circular relationships, as shown in the table. We review all combinations of constraints and identify the valid recursive relationship types discussed in Section 3.1, and shown in Table 1, through examples and discussion. Those minimum and maximum cardinality constraints that yield invalid structures are demonstrated though formal proofs. 3.2.1 One-to-One Recursive Relationships There are three cases that require investigation in one-to-one recursive relationships. They are ‘mandatory-mandatory’, ‘optional-optional’, and ‘optional-mandatory’. The ‘mandatory-optional’ case is a reverse image of the ‘optional-mandatory’ case and does not require further analysis. 1:1 Mandatory-Mandatory This type of relationship is valid for a symmetrical relationship. In a ‘mandatorymandatory’ relationship each instance of the role group must participate fully in the relationship. When the relationship is 1:1, each instance must be paired with one and

7

only one other instance. An example of this symmetrical pairing of instances is shown in Figure 5 representing of a group of married persons with the relationship MARRIED_TO. Every person in the group is married to one and only one other person in the group. TAXED JOINTLY WITH

1

1 MARRIED TO

PERSON 1

1

Figure 5: Valid Recursive Relationships.

1:1 Optional-Optional In an ‘optional-optional’ relationship each instance of the role groups can optionally participate in the relationship. This case makes no restrictions on the number of roles that is contained in the entity, so both symmetrical and asymmetrical relationships are supported. In a ‘one-to-one’ symmetrical relationship, instances of the role group are paired with one and only one other instance in the same role group. If the mandatory constraint is removed from the relationship then additional non-participating instances can be included in the entity without effecting the validity. In Figure 4 married individual have the option of being taxed either jointly or separately. This is an example of a symmetric relationship where the entity is PERSON and the relationship is TAXED_JOINTLY_WITH can take on a minimum cardinality constraint of ‘mandatory-mandatory’ or ‘optional-optional’ when the maximum cardinality is ‘one-to-one’. For the ‘mandatory-mandatory’ case all of the instances in PERSON must file their taxes jointly with their spouse while in the ‘optional-optional’ case, shown in Figure 5 at least one pair of married persons decided to file their taxes separately. 1:1 Mandatory-Optional or Optional-Mandatory In a ‘mandatory-optional’ relationship each instance of one role group must participate in the relationship while the instances of the other role group can optionally participate in the relationship. This implies the existence of two different role groups in the entity and therefore the relationship must be asymmetric. Symmetric relationships of any type cannot support ‘mandatory-optional’ relationships because an instance participating in a symmetric relationship is mapped to another instance in the same role group. By the definition of a symmetrical relationship the instance being ‘mapped to’ must also have the reflexive property of being able to map back to its paired instance. This would be impossible if the participation is optional. Asymmetrical relationships also have a similar instance-mapping problem, as we will demonstrate. Theorem 1: A 1:1 recursive relationship structure with a minimum cardinality constraint of ‘mandatory-optional’is an invalid structure. Proof: Role group 1 (rg1) contains Ij instances (where j = 1, 2, 3, … , n) and represents all the instances in entity E, therefore, |rg1| = |E| = n (1) Because of the mandatory participation, each instance in rg1 is mapped totally to role group 2 (rg2) and |rg2| is at least equal to n, therefore,

8

(2) |rg2| ≥ n If the instances of rg2 are only partially mapped to the instances of rg1 then the instances in rg2 may contain at least one additional instance that is not mapped to instances of rg1. Therefore, in the strictest form |rg2| > n (3) Rg2 also represents all the instances in entity E, therefore from (3) we can derive (4) |E| > n Equations (1) and (4) are inconsistent because |E| can not be equal to n and greater than n, therefore the structure is invalid. ¨ The proof of Theorem 1 demonstrates that a 1:1 recursive relationship with a minimum cardinality of constraint of ‘mandatory-optional’ or ‘optional-mandatory’ is invalid for both symmetrical and asymmetrical relationships. Rule 1: Only 1:1 recursive relationships with mandatorymandatory or optional-optional cardinality constraints are structurally valid. Corollary 1: All 1:1 recursive relationships with mandatoryoptional or optional-mandatory cardinality constraints are structurally invalid. 3.2.2 One-to-Many Recursive Relationships There are four cases requiring investigation in one-to-many recursive relationships. The minimum cardinality constraints are mandatory-mandatory, mandatory-optional, optional-mandatory, and optional-optional. ‘One-to-many’ recursive relationships are always asymmetrical relationships because the non-reflexive relationship requires two role groups. One-to-Many Mandatory-Mandatory In a ‘one-to-many’ recursive relationship the ‘mandatory-mandatory’ case is invalid as stated in the following rule and demonstrated in the following proof. Theorem 2: A ‘One-to-Many’ recursive relationship where the both minimum cardinality constraints are mandatory is an invalid structure. Proof: Given that role group 1 and 2 are both contained in entity E and participate fully in the relationship R. Because of the 1:M constraint placed on R, the relationship R must support the case of rg1 containing fewer instances than rg2, therefore, in the strictest form |rg1| < |rg2| (1) Because of the mandatory constraint on R the instances of rg1 represent all the instances in E, therefore, |rg1| = |E| (2) Also because of the mandatory constraint on R the instances of rg2 represent all the instances in E, therefore,

9

|rg2| = |E| (3) If |rg1| = |E| and |rg2| = |E| Then |rg1| = |rg2| (4) Equations (1) and (4) are inconsistent therefore the structural representation is invalid. ¨ One-to-Many Mandatory-Optional Also in the ‘one-to-many’ recursive relationship, the ‘mandatory-optional’ case is invalid as stated in the following rule and demonstrated in the following proof. Theorem 3: Any ‘One-to-Many’ recursive relationship where the minimum cardinality constraint is mandatory on the ‘One’side and optional on the ‘Many’ side is an invalid structure. Proof: Consider role groups 1 and 2 that are contained in entity E and that participate in a 1:M relationship R. If rg1 on the ‘One’ side of a ‘One-to-Many’ relationship is mapped with optional participation to rg2 on the ‘Many’ side, then the relationship R must support the case of rg1 containing fewer instances then rg2. Therefore, in the strictest form |rg1| < |rg2| (1) Because of the mandatory cardinality constraint on the role group 1 the number of instances in rg1 must equal the number of instances in entity E. Therefore, |rg1| = |E| (2) Combining equations (1) and (2) implies that |E| < |rg2| but this is inconsistent because the number of instances in a role group can not exceed the total number of instances in the entity containing that role group. ¨ One-to-Many Optional-Mandatory A hierarchical-circular recursive relationship type supports the occurrence of the ‘optional-mandatory’ case in a ‘One-to-Many’ recursive relationship. An example would be where there are two roles being played by the instances of the entity. First, every instance participates as an employee and employees are expected to be able to make decisions about the area of their expertise. Some employees have more than one area of expertise and are required to backup other employees during their absence. The relationship is hierarchical because all employees participate in the relationships of being backed-up at the bottom of hierarchy but only some employees at the top of the hierarchy backup all other employees. The relationship is circular because some one in the tree structure circles back to backup the instance at the top. Figure 6 is an example of this type of relationship. This relationship is similar to the lifeguard example but allowing an instance to backup more than one other instance.

1 DECISION MAKER

BACKS UP M

Figure 6: An example of a One-to-Many Optional-Mandatory Recursive Relationship

10

One-to-Many Optional-Optional Howe [10, p. 137] implies that “the most senior employee is regarded as selfsupervised” and allows the ‘many’ side to be mandatory. Using this method only implies that an employee can be self-managed and may lead to a different interpretation. We feel the concept of role uniqueness should be explicitly stated in the diagram and the more appropriate way to model the example would be with two relationships, both being ‘optional-optional’. One relationship specifically addressing the self-management issue. Figure 6 shows a suggested diagram.

1 1 EMPLOYEE

SELF MANAGES

MANAGES

1 M

Figure 7: An entity with two asymmetrical recursive relationships addressing the self-management issue. Figure 7 demonstrates the validity of the ‘optional-optional’ case of a 1:M relationship. It is optional for the manager role group because only some instances are managers while others are not. It is optional for the employee role group because as previously stated at least one manager at the higher level is an employee that is not managed by other instances in the entity. From Theorems 2 and 3 proofs and the accompanying discussion the following rule and corollary can be stated about 1:M relationships. Rule 2: For 1:M or M:1 recursive relationships optional-optional cardinality is structurally valid. Rule 3: For 1:M recursive relationships of the hierarchicalcircular type, optional-mandatory cardinality are structurally valid. Corollary 2: All 1:M recursive relationships with mandatorymandatory cardinality constraints are structurally invalid. Corollary 3: All 1:M recursive relationships with mandatoryoptional cardinality constraints are structurally invalid. 3.2.3 Many-to-Many Recursive Relationships There are three cases requiring investigation in many-to-many recursive relationships. The minimum cardinality constraints are mandatory-mandatory, mandatory-optional, and optional-optional. Many-to-Many Mandatory-Mandatory A ‘mandatory-mandatory’ many-to-many relationship is valid for a symmetrical relationship while as stated before the asymmetrical recursive relationship can not be totally mandatory. In a ‘mandatory-mandatory’ relationship each instance of a role group must participate fully in the relationship. When the relationship is a ‘many-tomany’ relationship then each instance must be paired with one or more instances in the

11

relationship then each instance must be paired with one or more instances in the role group. Because they are symmetric, each pairing is reflexive meeting the requirement of a ‘mandatory-mandatory’ relationship. A valid example would be an entity of PERSON composed of groups of brothers and sisters with the SIBLING_OF as the relationship. Many-to-Many Mandatory-Optional In the example of a hierarchical tree for a ‘many-to-one’ relationship using the entity EMPLOYEE with different levels of management, we showed that the minimum cardinality constraint is ‘optional’ on both sides of the relationship. This occurred because some employees were at the bottom of the management chain and did not manage anyone, and one employee, the highest manager, was at the top of the chain not managed by any one. If we change this example to a company that is completely employeeowned and some of these employees form the board of directors that manage the senior manager, then this is an example of a ‘Many-to-Many’, Mandatory-Optional recursive relationship. In this modify example some employees (but not all) take on the role of manager satisfying the optional side of the relationship. The mandatory side of the relationship is satisfied because all employees are managed even the most senior manager and the owner-employees. This is an example of a ‘Many-to-Many’ relationship because the senior manager is managed by more than one owner-employee and manages more than one employee in the hierarchy. This type of relationship with these constraints is valid. Many-to-Many Optional-Optional Our earlier example of an entity PERSON composed of groups of only brothers and sisters with the SIBLING_OF as the relationship is a valid ‘Mandatory-Mandatory’ ‘Many-to-Many’ recursive relationship and can serve a model for the totally optional case. If we add individuals to the entity PERSON that have no brothers or sisters then these individuals can not participate in the relationship SIBLING_OF. Of more importance is that they do not participate on both sides of the relationship because they have no brothers or sisters, and no other instance has them as brothers or sister. The relationship is optional on both sides. This is an example of a valid symmetric relationship. Rule 4: All recursive relationships with many-to-many maximum cardinality are structurally valid regardless of minimum cardinality constraints. Rule 5: All recursive relationships with optional-optional cardinality are structurally valid.

4. Summary of Decision Rules with Examples From Section 3.2 we have developed five decision rules for determining the validity of a recursive relationship and three corollaries that quickly identifies invalid recursive relationships. Table 2 summarizes each validity rule and corollary for recursive relationships with an example. The relationship types that are addressed by each rule are also included.

12

1.

2.

3.

4.

5.

1.

2.

3.

Validity Rules for Recursive Relationships Only 1:1 recursive relationships with mandatory-mandatory or optionaloptional cardinality constraints are structurally valid. Valid for symmetrical and completely circular relationships. For 1:M or M:1 recursive relationships optional-optional cardinality are structurally valid. Valid for asymmetrical relationships only. For 1:M recursive relationships of the hierarchical-circular type, optionalmandatory cardinality are structurally valid. Valid for hierarchical-circular relationships only. All recursive relationships with many-tomany maximum cardinality are structurally valid regardless of minimum cardinality constraints. Valid for symmetrical, hierarchical, and hierarchical-circular relationships. All recursive relationships with optionaloptional cardinality are structurally valid. Valid for symmetrical and asymmetrical relationships. Validity Corollaries for Recursive Relationships All 1:1 recursive relationships with mandatory-optional or optional-mandatory cardinality constraints are structurally invalid. All 1:M or M:1 recursive relationships with mandatory-mandatory, cardinality constraints are structurally invalid. All 1:M or M:1 recursive relationships with mandatory participation constraint on the ‘One’ side and an optional participation constraint on the ‘Many’ constraints are structurally invalid.

Valid Example

TAXED JOINTLY WITH

1

1 MARRIED TO

PERSON 1

1

1 TUTORS

STUDENT M

1 DECISION MAKER

BACKS UP M

M SIBLING

PERSON M

ARE FRIENDS WITH

PERSON

Invalid Example

1 DANCES WITH

DANCER 1

1 SUBSTITUTE

PRODUCT

M

1 SUPERVISE

EMPLOYEE

M

Table 2: Summary of Validity Rules for Recursive Relationships with Examples

13

1 PARTNER_OF

1 EMPLOYEE

1

MANAGE

M M WORKS_ON

1 1 SUBSTITUTE

PRODUCT

M

Figure 1: An ERD with Invalid Recursive Relationships (Reproduced here for the convenience of the reader) In Figure 1 of this paper the entity-relationship diagram contained three recursive relationships: PARTNER_OF, MANAGE, and SUBSTITUTE. PARTNER_OF is invalid because it violates Corollary 1. It was shown in this paper by formal proof presented for Theorem 1 that a ‘One-to One’ recursive relationship with a ‘MandatoryOptional’ participation constraint is invalid. SUBSTITUTE is invalid because it violates Corollary 2. The proof of Theorem 2 states that a ‘One-to-Many’ recursive relationship with a ‘Mandatory-Mandatory’ participation constraint is invalid. MANAGE is invalid because it violates Corollary 3. The proof of Theorem 3 states that a ‘One-to-Many’ recursive relationship with a ‘Mandatory-Optional’ participation constraint is invalid. ERDs containing these recursive relationships are invalid.

5.

Conclusion

In this paper, we have presented the complete classification of recursive relationships and the criteria that contribute to the validity of modeling recursive relationships within the entity-relationship (ER) diagram. We have first classified all recursive relationships into symmetric and asymmetric. Asymmetric recursive relationships are further classified into hierarchical, circular, and mirrored. We have identified their directional properties and their validity in terms of maximum and minimum cardinality constraints. Unlike typical other analyses that use only maximum cardinality constraints, we have used both maximum and minimum cardinality constraints in defining the properties and validity criteria. Our analysis has yielded a complete and comprehensive set of decision rules to determine the structural validity of any ER diagram containing recursive relationships. Our decision rules used notions of role uniqueness, path connectivity, and cardinality constraints. Five rules and three corollaries were established to determine structural validity of recursive relationships. Section 4 summarized each rule and corollary with valid and invalid examples.

14

The contribution of this paper is the presentation of a complete taxonomy of recursive relationships with their properties as well as the decision rules for their validity. We believe that these decision rules can be readily applied to real world data models regardless of their complexity. The rules can easily be incorporated into the database modeling and designing process, or extended into case tool implementations.

References ®

[1] Barker, R. CASE*METHOD : Entity Relationship Modeling. Addison-Wesley, New York 1990. [2] Boehm, Barry W., Software Engineering, IEEE Transactions on Computers, 25(12)12261241, December 1976. [3] Boehm, Barry W., Software Engineering Economics, Prentice-Hall, Inc. Englewood Cliffs, NJ, 1981. [4] Chen, Peter, “The Entity-Relationship Model -- Toward a Unified View of Data”, ACM Transactions on Database Systems, 1(1)9-36, March 1976. [5] Daly, E. B., Management of Software Engineering, IEEE Transactions on Software Engineering, 3(3)229-242, May, 1977 [6] Dullea, James and Il-Yeol Song, “An Analysis of Structural Validity in Recursive and Binary Relationships in Entity Relationship Modeling”, The Proceedings of the Fourth International Conference on Computer Science and Informatics, Volume 3, pp 329-334, Research Triangle Park, NC, October 23-28, 1998. [7] Dullea, James and Il-Yeol Song, "An Analysis of Structural Validity of Ternary Relationships in Entity-Relationship Modeling," Proceedings of Seventh International Conference on Information and Knowledge Management (CIKM ‘98), Nov. 3-7, 1998, Washington, D.C., pp. 331-339. [8] Elmasri, Ramez and Shamkant B. Navathe. Fundamentals of Database Systems, 2nd Ed., The Benjamin/Cummings Publishing Co, Inc., Redwood City, CA, 1994. [9] Fagan, M. Design and Code Inspections and Process Control in the Development of Programs, IBM Report IBM-SDD-TR-21-572, December 1974. [10] Howe, D. R., Data Analysis for Data Base Design, 2nd Ed., Edward Arnold, London, GB, 1989. [11] Trevor H. Jones and Il-Yeol Song, "Analysis of Binary/ternary Cardinality Combinations in Entity-Relationship Modeling," Data & Knowledge Engineering, Vol 19, No. 1(1996), pp. 39-64. [12] Korth, Henry F., and Abraham Silberschatz, 1997. Database System Concepts, 3rd Ed., McGraw-Hill, Inc., New York. [13] Song, Il-Yeol, Mary Evans, and E. K. Park, “A Comparative Analysis of Entity-Relationship Diagrams”, Journal of Computer & Software Engineering, 3(4)427-459, 1995. rd [14] Teorey, Toby J., Database Modeling and Design - The Entity-Relationship Approach, 3 ed., Morgan Kaufmann Publishers, Inc., San Mateo, CA, 1998. [15] Tillman, George, A Practical Guide to Logical Data Modeling, McGraw-Hill, Inc., New York, 1993.

15