Databases, SPSU, okaram

Recursive Relationships

1 of 5

Recursive Relationships
Recursive relationships are those that relate two or more entities of the same type. Normally, we use the entity type to distinguish among the sides of a relationship, but with recursive relationships there are at least two sides that are the same, so we need to introduce the concept of role to distinguish among them. A role is just a name given to one of the sides of a relationship. Notice that the book calls this kind of relationships unary, but this idea does not generalize. If we actually used the book's terminology, a relationship that relates three entity instances of two different entity types would be considered binary (and so, normal an easy :). Although I accept the book's definitions as answers to exams, I prefer to define degree as the number of entity instances that participate in a relationship instance. Recursive relationships are not terribly uncommon, since, besides other uses, they are useful to represent hierarchies. One of the best examples is the supervises relationship. In many companies, people supervise other people. So, if we want to show that relationship we could start thinking about having two kinds of entities, say Boss and Peon, with the supervising relationship as follows.

Figure 1: Conceptual idea of Supervises. WRONG And we would say a boss supervises zero or more peons, and a peon is supervised by zero or one bosses. Of course, we would realize this is not exactly right, since this reflects only a two-level hierarchy, and what we want is one with unlimited levels. In order to do that, we need to introduce recursion (just like in programming), so we need to fold this diagram so the two entities become one. So, our diagram would look like this:

Figure 2: Supervises, roles missing, INCOMPLETE Now the problem would be how to distinguish among the two sides; that is whether you can have more than one peon or more than one boss. We do that by including the role each entity instance plays in the
Licensed under Creative Commons, Attribution, Share-Alike

specifying that each employee has zero or one bosses (assuming the CEO doesn't have any boss).Databases. but we need to remember this cardinality constraint applies to all Employees. final and right version Notice that the cardinality constraints apply to the full entity type. So. It may look funny to allow for a boss with no subordinates. in a hierarchy. This involves representing the fact that an item is made from other items. the full diagram. Basically. these sub-items may in turn be made from other items. WRONG And then fold them into one recursive relationship as follows: Licensed under Creative Commons. and that each employee may supervise zero or more other employees would look like this: Figure 3: Supervises. conceptual idea. From a diagram that considers them to be two separate items: Figure 4: Bill of material. Share-Alike http://creativecommons.0/ . we can follow the same kind of reasoning. and use that to distinguish among the sides. Bill of Materials Another example is the part-of relationship. we assign a name to each side. okaram Recursive Relationships 2 of 5 relationship instance. Attribution. also called the bill of materials problem. not just to the roles. SPSU.

we actually name the relationships. Associative entities are entities. Attribution.Databases. okaram Recursive Relationships 3 of 5 Figure 5: Bill of materials. SPSU. Licensed under Creative Commons. we could want to improve this diagram by adding how many of each part each item uses. which are used to represent relationships. The diagram would look like this: Figure 7: Bill of Materials. with associative Each instance of an associative entity represents a relationship instance.0/ . Each of the lines from BOM Structure to Item now represents a relationship. so they might want to model the has_components relationship as an associative entity. some people don't like having relationships with attributes attached to them. attribute on relationship (my preference) Now. Notice how instead of roles. right version. The diagram would look as follows: Figure 6: Bill of materials. no attributes Now. Share-Alike http://creativecommons.

and those constraints should be added as annotations outside the diagram. Since each marriage is between two people. okaram Recursive Relationships 4 of 5 Notice how now in place of the has_components relationship. One example that is easy to understand and is NOT used to represent a the associative entity is now an entity that may have other relationships. is that of marriages. Notice that there may be constraints other than cardinalities (such as gender requirements for each role). sometimes. Although in this case it is not happening. it is oneto-one and does not form a hierarchy. We can express this situation as two different recursive relationships among courses. those are the relationships has_components and used_in. Licensed under Creative Commons. so it needs a link to one Item as a part and to another as a whole. common in the academic domain. Notice that to distinguish the special relationships the associative entity has with the entities it associates. so I just wen with the book's :).0/ . that does not form a hierarchy. Figure 8: Marriage is a one-to-one recursive relationship. so I normally would keep it as a relationship. Another example. those relationships do NOT have a diamond. The diagram would look like this. you are allowed to take the courses concurrently (co-requisites). I would normally model as in Illustration 6 rather than 7. associative entities are more complex than relationships with attributes. we now have an associative entity called BOM_Structure (the name is not great.Databases. Share-Alike http://creativecommons. but I couldn't think of a better one. is that of course prerequisites and co-requisites. Each instance of BOM_Structure represents an instance of the old has_components association. Additional Examples There are a few other examples that always come to my mind when talking about recursive relationships. In my opinion. SPSU. with the roles identified as husband and wife. In many academic programs you are required to take certain courses before others (prerequisites). this would be a recursive relationship. however. Attribution.

Share-Alike http://creativecommons.Databases. The diagram would look like this: Figure 10: Course prerequisites and corequisites as one combined relationship Licensed under Creative Commons. with the kind of requisite (either pre or co) as an attribute. okaram Recursive Relationships 5 of 5 Figure 9: Course prerequisites and correquisites as two separate relationships Another way to model this would be to represent this as a single relationship. Attribution.0/ .