Although the Entity-Relationship model is generally considered the de facto stan- dard for data modeling, an alternative option is offered by the Unified Modeling Language (UML), an object-oriented design notation emerged from the fusion of the three most popular design methods for object-oriented applications analysis and design, namely OMT, OOSE, and the Booch’s method (see the Bibliographic Notes for references about UML and the three mentioned object-oriented methods).
UML includes primitives for data modeling, which although originally con- ceived for representing the structure of the classes of an object-oriented applica- tion, can be used also for specifying the data model of an application domain. In particular, UML class diagramscan be used in alternative to Entity-Relationship diagrams.
The most prominent difference between a UML class diagram and an Entity- Relationship diagram is the difference between a class and an entity: a class is a generalization of the notion of entity, which permits the designer to specify not only the attributes, but also the functions (called methods) applicable to the in- stances of the class. However, this difference makes UML more general than the Entity-Relationship model, and thus the designer can exploit UML class diagrams to achieve the same specification as with the Entity-Relationship model.
UML class diagrams have more features than Entity-Relationship diagrams, like the already mentioned possibility of specifying derivation rules for attributes and re- lationships using the OCL language. Table 2.2 reviews the essential similarities and differences between the two notations. Since the Entity-Relationship nota- tion used in this book is a strict subset of UML, designers already familiar with UML can continue using their favorite language for data modeling.
74 Chapter Two: Data Model
Artist FirstName LastName Biography Photo BirthDate BirthPlace DeathDate DeathPlace PopArtist JazzArtist Instrument Review Author Title Date Text Support Type ListPrice Discount /CurrentPrice{ListPrice * Discount} Album Title Year Cover Track Number Title Duration Evaluation 0:N 1:1 Version 1:N 1:1 Composition 1:N 1:1 Author 1:1 0:N
Summary
Data-intensive Web applications publish and manage information, typically stored within one or more data repositories. This chapter has presented the features
Summary 75
ER construct Equivalent UML construct Comments
UML classes can also include the specification of the methods applicable to their objects. UML attribute specification includes features not supported in ER: derived attributes, static attributes, visibility, multi-valued attributes, default values, and attribute constraints. Class
Entity
Generalization hierarchy
Relationship and role
Relationship cardinality
Generalization hierarchy
Association and role
Association multiplicity
Generalization hierarchies have the same semantics. UML special notations (calledstereotypes) can be used todeclare that the IS-A relationshipis overlapping, disjoint, complete,or incomplete.
UML relationship specification includes features not supported in ER, like constraints, ordering, visibility, modifiability, and navigability.
In UML relationships can be declared as part-of relationships, expressing a physical or logical containment.
In ER, the cardinality represents the minimum and maximum number of relationship instances an object may have.
In UML, the multiplicity (either 1 or *) denotes the maximum number of objects connected to a source object; note that the multiplicity label * is placed at the opposite side with respect to the ER notation for "many" cardinality (N).
Artist FirstName: String LastName: String Biography: Text Photo: BLOB Artist
FirstName: String {unique} LastName: String {unique} Biography: Text Photo: BLOB BioUpdate() Artist PopArtist JazzArtist Artist PopArtist JazzArtist Album Artist Publication Published_By Publishes Album Artist Publication Published_By Publishes Album Artist Publication Published_By Publishes 1:1 0:N Album Artist Publication Published_By Publishes * 1
of the Entity-Relationship model, used to represent the structure of information at the conceptual level.
The Entity-Relationship model exploits simple and expressive concepts, like entities, attributes, relationships, and IS-A hierarchies, and adopts a visual nota- tion for expressing the specifications. The objects of the application domain are represented by entities, which abstract the common properties of similar in- stances. These properties are expressed as entity attributes, some of which can be specified as keys, meaning that they unambiguously identify entity instances. The semantic associations between objects are instead represented as relation- ships, characterized by cardinality constraints. A special kind of semantic associ- ation, the specialization of a general concept into a more specific one, is expressed using generalization hierarchies, which permit the designer to factor out the com- mon aspects of entities and organize them in a taxonomy.
Although the primitives of the Entity-Relationship model can be used freely, we have suggested a few practices, which make an Entity-Relationship diagram simpler to implement using conventional relational technology.
Finally, we have briefly contrasted the Entity-Relationship notation to UML class diagrams, which can be used by designers already familiar with that nota- tion, without any loss of expressive power.
Bibliographic Notes
The data model proposed in this book builds on the notation of the Entity- Relationship model introduced by Peter Chen [Chen76]. The original proposal did not include generalizations, which were added later [NFS79, SSW80]. Con- ceptual modeling is the core topic addressed by Batini et al. [BCN92]; further valu- able sources are [ACPT99, Date95, EN94, MR92, Ullman88].
The proposed notation is also compatible with object-oriented models. A good introduction to the basic concepts of object-orientation is given by Bertrand Meyer, who illustrates the basic principles of object-oriented design in the context of the Eiffel programming language [Meyer88]. A presentation of object orientation from a databases perspective is provided in [KL88, Loomis95], while an in-depth view of this technology is given in [BM93]. All the books presenting object-oriented software engineering methods (including OMT [RBPEL91], Booch [Booch94], and OOSE [Jacobson94]) include an overview of the object-oriented paradigm and of the graphic formalisms adopted to represent it. In particular, Booch, Jacobson, and Rumbaugh provide an excellent guide to the Unified Modeling Language (UML), by means of an easy-to-understand example-driven approach [BJR98]. The Object Constraint Language is treated extensively in [CW02].
76 Chapter Two: Data Model