Database Reference
In-Depth Information
You learned about entity subtypes and how to represent them in E-R diagrams. In UML, these entity sub-
types are called subclasses. In addition, when one class is a subclass of a second class, you call the second
class a superclass of the first class. The relationship between a superclass and a subclass is called a generali-
zation, which is shown in Figure 9-26. This class diagram represents the relationship between the class of
students and the subclass of students who live in dorms.
Student
Super
Superclass
#StudentNum : char(9)
#LastName : char(15)
#FirstName : char(15)
#Status : char(1)
+AddStudent( )
+DeleteStudent( )
+ChangeStudent( )
307
Generalization
Constraint
StudentDorm
#DormNum : char(2)
+AddDorm( )
+RemoveDorm( )
Subclass
(Only students living in dorms
have StudentDorm record)
FIGURE 9-26
Class diagram with a generalization and a constraint
Rules for OODBMSs
Just as rules specify desired characteristics for DDBMSs and OLAP, OODBMSs also have a set of rules. These
rules serve as a benchmark against which you can measure object-oriented systems. The rules are as follows:
1. Complex objects. An OODBMS must support the creation of complex objects from simple
objects such as integers and characters.
2. Object identity. An OODBMS must provide a way to identify objects; that is, the OODBMS must
provide a way to distinguish between one object and another.
3. Encapsulation. An OODBMS must encapsulate data and associated methods together in the
database.
4. Information hiding. An OODBMS must hide from the users of the database the details concern-
ing the way data is stored and the actual implementation of the methods.
5. Types or classes. You are already familiar with the idea of a class. Types are very similar to
classes and correspond to abstract types in programming languages. The differences between the
two are subtle and will not be explored here. It is important to know, however, that an OODBMS
supports either abstract types or classes (it doesn
t matter which).
6. Inheritance. An OODBMS must support inheritance.
7. Late binding. In this case, binding refers to the association of operations to actual program
code. With late binding, this association does not happen until runtime, that is, until some user
actually invokes the operation. Late binding lets you use the same name for different operations,
which is called polymorphism in object-oriented systems. For example, an operation to display
an object on the screen requires different program code when the object is a picture than when
it is text. With late binding, you can use the same name for both operations. At the time a user
invokes this
'
operation, the system determines the object being displayed and then
binds the operation to the appropriate program code.
8. Computational completeness. You can use functions in the language of the OODBMS to per-
form various computations.
9. Extensibility. Any DBMS, object-oriented or not, comes with a set of predefined data types, such
as numeric and character. An OODBMS should be extensible, meaning that it is possible to
define new data types. Furthermore, the OODBMS should make no distinction between the data
types provided by the system and the new data types.
“
display
”
