OBJECT-ORIENTED DATABASE MANAGEMENT - Fundamentals of Database Management Systems - page 256

In generalization, lower-level classes are kinds of upper-level classes (e.g. POWER
TOOLs and NON-POWER TOOLs are both kinds of TOOLs). In aggregation, a
class is shown to be composed of other classes. FRAMEs and BULBS are not kinds
of LIGHT FIXTUREs; rather, each is a part of a LIGHT FIXTURE. As shown in
Figure 9.4, the component classes can each have their own special attributes and
conceivably, operations, too.
The General Hardware Co. Class Diagram
Figure 9.5 shows the complete General Hardware Co. UML Class Diagram. The
upper portion of the diagram is largely the same as the entity-relationship diagram of
Figure 9.1. In converting the entity boxes to class boxes we added some operations
and changed some of the notation. In terms of one-to-one, one-to-many, and many-
to-many relationships, in this notation ''1'' means exactly one, ''0..1'' means zero
or one, ''0..*'' means zero-to-many, and ''1..*'' means one-to-many. Also note that
the many-to-many relationship between SALESPERSON and PRODUCT requires
an additional class (similar in concept to an associative entity) to show the nature
of the many-to-many relationship, including any intersection data. This SALE class
is attached to the connective line between the SALESPERSON and PRODUCT
classes with a dashed line.
It is important to stop here for a moment and ask whether an ordinary relational
database together with application programming could be used to implement all the
various kinds of relationships in Figure 9.5. The answer is yes, it could. But the
point is that it would be up to the database designer and especially the application
programmer to manage the various kinds of relationships in the database with the
application code. This is different from an OODBMS, which is designed to handle
all of these relationships among its natural features. To stretch a term a bit, in
the OODBMS concept, the database management system ''understands'' all these
kinds of relationships and is capable of directly managing the data involved in them.
The Good Reading Bookstores Class Diagram
Good Reading Bookstores has decided to expand its product line to include
periodicals (newspapers and magazines), music CDs, and movie videos/DVDs. The
upper portion of Figure 9.6 is the class-diagram version of the entity-relationship
diagram of Figure 2.10, except that several changes have been made to reflect
the change in product line. The BOOK entity type has become the PRODUCT
class since there can now be several kinds of products, not just books. Similarly,
PUBLISHER has become PRODUCING COMPANY to reflect that we are now
dealing with publishers, music studios, and movie studios, and AUTHOR has
become CREATOR to reflect that we are now dealing with authors, singers, and
movie producers and directors.
A generalization hierarchy has been created under PRODUCT indicating that
there are four kinds of products: BOOK, PERIODICAL, CD, and VIDEO/DVD.
The three attributes in the PRODUCT class, Product Number, Product Name, and
Year Created, are inherited downwards to all four of the subordinate classes. In
addition , a book has a number of pages, a periodical has a volume, a number, and
a number of pages, a CD has a number of tracks, a total length in minutes, and a
chart rating (the current popularity of the CD), and a video/DVD has a length in
minutes. The BOOK class has a constructor-type operation, Add Book, that adds