|Now available for download is the free sample chapter “The Unified Modeling Language” from the forthcoming Database Modeling and Design, 5th Edition by Toby J. Teorey, Sam S. Lightstone, Tom Nadeau and H.V. Jagadish. Here’s an excerpt from the chapter:
A class is a descriptor for a set of objects that share some attributes and/or operations. We conceptualize classes of objects in our everyday lives. For example, a car has attributes, such as a vehicle identification number (VIN) and= mileage. A car also has operations, such as accelerate and brake. All cars have these attributes and operations. Individual cars differ in the details. A given car has a value for the VIN and mileage. For example, a given car might have a VIN of 1NXBR32ES3Z126369 with a mileage of 22,137 miles. Individual cars are objects that are instances of the Car class.
Classes and objects are a natural way of conceptualizing the world around us. The concepts of classes and objects are also the paradigms that form the foundation of objectoriented programming. The development of object-oriented programming led to the need for a language to describe object-oriented design, giving rise to UML.
There is a close correspondence between class diagrams in UML and ER diagrams. Classes are analogous to entities. Database schemas can be diagrammed using UML. It is possible to conceptualize a database table as a class. The columns in the table are the attributes, and the rows are objects of that class. For example, we could have a table named Car with columns named “vin” and “mileage” (note that we put table names in boldface throughout the book for readability). Each row in the table would have values for these columns, representing an individual car. A given car might be represented by a row with the value 1NXBR32ES3Z126369 in the vin column, and 22,137 in the mileage column.
The major difference between classes and entities is the lack of operations in entities. Note that the term operation is used here in the UML sense of the word. Stored procedures, functions, triggers, and constraints are forms of named behavior that can be defined in databases; however, these are not associated with the behavior of individual rows. The term operations in UML refers to the methods inherent in classes of objects. These behaviors are not stored in the definition of rows within the database. There are no operations named “accelerate” or “brake” associated with rows in our Car table in Figure 3.1. Classes can be shown with attributes and no operations in UML, which is the typical usage for database schemas.
View in bookstore
(powered by Elsevier)