Chen introduced the idea of weak relationship to describe the relatively common situation where the foreign key is part of the primary key [Chen 1976]. That is, a weak entity is an entity whose primary key includes the primary key of a related entity. IDEF1X, for example, automatically shows the elements of the primary key from the many side as part of the primary key in the upper section of the entity box if you link the entities with an identifying relationship. The relationship itself (Figure 6-14) is a solid line rather than the nonidentifying (strong) relationship's dashed line. Chen's notation just shows the relationship as a double-line diamond and the corresponding weak entity as a double-line rectangle.
In Chen diagrams, weak entities are rare because there are few existence constraints between real entities. Chen's original example was to have a Dependent entity related to an Employee entity with a weak relationship. The Dependent's primary key combined the employee's EmployeeID and the name of the dependent. Making this a weak relationship asserted that the dependent person was of no interest other than as a dependent of the employee. If you think a bit about this, however, and think about the real-world situations that might confront the hapless human resource clerk (multiple
addresses for divorced dependents of ex-employees with ongoing COBRA coverage and on and on), you realize that the real world does not often present opportunities to use weak relationships with real entities.
Almost all associative entities, however, are weak entities because their existence depends essentially on the existence of the entities they associate. They are relationships, not freestanding entities. So the weak or identifying relationship is much more important in ER diagramming techniques that use associative entities, such as IDEF1X.
Weak entities depend on the existence of their related entities. If you delete the related entity, you must cascade that deletion to the weak entities that contain the primary key you've deleted.
Note
The implications of the weak entity are much more interesting in the object world. The
equivalent situation in object design is when an object creates and owns another object rather than just having a reference to the object. If you delete the main object, it must delete all the dependent objects that it owns. If the objects are independent, one object simply refers to the other object. When you delete the referring object, the relationship disappears, but the other
object still exists.
Domains
A domain is a set of values to which an attribute maps an object. That is, each value for an attribute in an entity set must come from the domain of the attribute. This is a very simple form of integrity
constraint. It puts restrictions on the values in a very direct way.
Note The value domain is completely unrelated to the Microsoft Windows NT domain, a network naming concept.
ER diagrams do not directly represent domains, but all CASE tools that I've used let you put the domain information into the repository for each attribute. Since a critical feature of a CASE tool is the generation of the data definition language or the schema itself, you have to have a way of specifying the required domain constraints. Often you can specify a separate set of domain requirements for each target DBMS, as they all have different features relating to domains.
Summary
Entites, relationships, and the ER diagrams they populate are the meat and potatoes of the database design world. Entities are rectangles connected to other entities by relationship lines, with many variations in different modeling techniques ranging from Chen notation to NIAM to data modeling to IDEFIX.
Most ER diagramming notations support these concepts:
Entity: A set of objects
Attribute: A property of an entity
Relationships(both strong and weak): A link between two or more entities, corresponding to foreign keys in relational databases
Role: One side of a relationship
Multiplicity: The number of objects that participate in a role (one-to-one,one-to-many,many- to-many)
Primary and candidate keys: Attributes that uniquely identify objects
Domains: A set of values to which an attribute maps an object
You've new seen all the different elements of standard data modeling using ER diagrams. The next chapter turns this on its head introduces you to the concepts of modeling objects.
Chapter 7: Building Class Models in UML
There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy. Shakespeare, Hamlet I:v
Overview
The ER modeling techniques in Chapter 6 are a good start at the methods you need for effective data modeling. This chapter expands on these basic techniques by extending them into the world of object orientation. Instead of
modeling entities, now you are going to learn how to model objects. Hamlet was right: there are more things in heaven and earth than you can conceive—but at least you can model more effectively what you can conceive. The Unified Modeling Language (UML) is a notation that combines elements from the three major strands of OO design: Rumbaugh's OMT modeling [Rumbaugh et al. 1992], Booch's OO Analysis and Design [Booch 1994], and Jacobson's Objectory [Jacobson et al. 1992]. The UML shows every sign of becoming a standard. OMG has adopted the UML as the standard notation for object methods. The UML is ubiquitous in trade show presentations. Several professional books now cover the UML in greater or lesser detail in presenting their analysis and design methods [Douglass 1998; Eriksson and Penker 1997; Fowler, Jacobson, and Kendall 1997; Harmon and Watson 1998; Larman 1997; Muller, Nygard, and Crnkovic 1997; Quatrani 1997; Texel and Williams 1997].
Note
There are thus many ways to learn UML. Rather than tutoring you in UML, this chapter focuses on teaching you the elements of UML you need to model data. By no means does this exhaust the language. As an designer, you should become familiar with all the different parts of the UML. The most direct way to do this is to download the UML specification documents from the Rational or OMG Web sites [Rational Software 1997a, 1997b, 1997c]. Reading these documents and using one of the many tutorials the above paragraph references will introduce you to all the OO features of the UML. All of the following material draws on the three UML documents for details; please consult those documents for more
information on any individual elements of the class diagrams. You can acquire additional understanding through the readings in the preceding paragraph and their examples. Fowler is a good introduction [Fowler, Jacobson, and Kendall 1997], Larman and Harmon are good intermediate texts [Larman 1997; Harmon and Watson 1998], and Eriksson is a particularly good advanced text [Eriksson and Penker 1997].
Chapter 4 covered one type of UML diagram, the use case. This chapter covers the class diagram, which models object classes. Object-oriented analysis and design using class diagrams can get quite complex; this chapter's objective is to cover just those elements of class diagrams that you use to model information. The first section covers object structure: packages, classes, and attributes. The second section covers the structure of object behavior: operations and methods. The third section covers relationships and their representation of referential business rules. The final section expands the coverage of business rules to object identity and uniqueness, domain constraints, and more general constraints.