Database Applications

Simplified Model for Inheritance.
Another main characteristic of ODBs is that they allow type hierarchies and inheritance. We use a simple OO model in this section—a model in which attributes and operations are treated uniformly—since both attributes and operations can be inherited. In Section 12.3, we will discuss the inheritance model of the ODMG standard, which differs from the model discussed here because it distinguishes between two types of inheritance. Inheritance allows the definition of new types based on other predefined types, leading to a type (or class) hierarchy.

A type is defined by assigning it a type name and then defining a number of attributes (instance variables) and operations (methods) for the type.¹² In the simplified model we use in this section, the attributes and operations are together called functions, since attributes resemble functions with zero arguments. A function name can be used to refer to the value of an attribute or to refer to the resulting value of an operation (method). We use the term function to refer to both attributes and operations, since they are treated similarly in a basic introduction to inheritance.¹³

A type in its simplest form has a type name and a list of visible (public) functions. When specifying a type in this section, we use the following format, which does not specify arguments of functions, to simplify the discussion:

TYPE_NAME: function, function, ... , function

For example, a type that describes characteristics of a PERSON may be defined as follows:

PERSON: Name, Address, Birth_date, Age, Ssn

In the PERSON type, the Name, Address, Ssn, and Birth_date functions can be implemented as stored attributes, whereas the Age function can be implemented as an operation that calculates the Age from the value of the Birth_date attribute and the current date.

The concept of subtype is useful when the designer or user must create a new type that is similar but not identical to an already defined type. The subtype then inherits all the functions of the predefined type, which is referred to as the supertype. For example, suppose that we want to define two new types EMPLOYEE and STUDENT as follows:

EMPLOYEE: Name, Address, Birth_date, Age, Ssn, Salary, Hire_date, Seniority
STUDENT: Name, Address, Birth_date, Age, Ssn, Major, Gpa

Since both STUDENT and EMPLOYEE include all the functions defined for PERSON plus some additional functions of their own, we can declare them to be subtypes of PERSON. Each will inherit the previously defined functions of PERSON—namely, Name, Address, Birth_date, Age, and Ssn. For STUDENT, it is only necessary to define the new (local) functions Major and Gpa, which are not inherited. Presumably, Major can be defined as a stored attribute, whereas Gpa may be implemented as an operation that calculates the student's grade point average by accessing the Grade values that are internally stored (hidden) within each STUDENT object as hidden attributes. For EMPLOYEE, the Salary and Hire_date functions may be stored attributes, whereas Seniority may be an operation that calculates Seniority from the value of Hire_date.

Therefore, we can declare EMPLOYEE and STUDENT as follows:

EMPLOYEE subtype-of PERSON: Salary, Hire_date, Seniority
STUDENT subtype-of PERSON: Major, Gpa

In general, a subtype includes all of the functions that are defined for its supertype plus some additional functions that are specific only to the subtype. Hence, it is possible to generate a type hierarchy to show the supertype/subtype relationships among all the types declared in the system.

As another example, consider a type that describes objects in plane geometry, which may be defined as follows:

GEOMETRY_OBJECT: Shape, Area, Reference_point

For the GEOMETRY_OBJECT type, Shape is implemented as an attribute (its domain can be an enumerated type with values 'triangle', 'rectangle', 'circle', and so on), and Area is a method that is applied to calculate the area. Reference_point specifies the coordinates of a point that determines the object location. Now suppose that we want to define a number of subtypes for the GEOMETRY_OBJECT type, as follows:

RECTANGLE subtype-of GEOMETRY_OBJECT: Width, Height
TRIANGLE S subtype-of GEOMETRY_OBJECT: Side1, Side2, Angle
CIRCLE subtype-of GEOMETRY_OBJECT: Radius

Notice that the Area operation may be implemented by a different method for each subtype, since the procedure for area calculation is different for rectangles, triangles, and circles. Similarly, the attribute Reference_point may have a different meaning for each subtype; it might be the center point for RECTANGLE and CIRCLE objects, and the vertex point between the two given sides for a TRIANGLE object.

Notice that type definitions describe objects but do not generate objects on their own. When an object is created, typically it belongs to one or more of these types that have been declared. For example, a circle object is of type CIRCLE and GEOMETRY_OBJECT (by inheritance). Each object also becomes a member of one or more persistent collections of objects (or extents), which are used to group together collections of objects that are persistently stored in the database.

Constraints on Extents Corresponding to a Type Hierarchy.
In most ODBs, an extent is defined to store the collection of persistent objects for each type or subtype. In this case, the constraint is that every object in an extent that corresponds to a subtype must also be a member of the extent that corresponds to its supertype. Some OO database systems have a predefined system type (called the ROOT class or the OBJECT class) whose extent contains all the objects in the system.¹⁴

Classification then proceeds by assigning objects into additional subtypes that are meaningful to the application, creating a type hierarchy (or class hierarchy) for the system. All extents for system- and user-defined classes are subsets of the extent corresponding to the class OBJECT, directly or indirectly. In the ODMG model (see Section 12.3), the user may or may not specify an extent for each class (type), depending on the application.

An extent is a named persistent object whose value is a persistent collection that holds a collection of objects of the same type that are stored permanently in the database. The objects can be accessed and shared by multiple programs. It is also possible to create a transient collection, which exists temporarily during the execution of a program but is not kept when the program terminates. For example, a transient collection may be created in a program to hold the result of a query that selects some objects from a persistent collection and copies those objects into the transient collection. The program can then manipulate the objects in the transient collection, and once the program terminates, the transient collection ceases to exist. In general, numerous collections—transient or persistent—may contain objects of the same type.

The inheritance model discussed in this section is very simple. As we will see in Section 12.3, the ODMG model distinguishes between type inheritance—called interface inheritance and denoted by a colon (:)—and the extent inheritance constraint—denoted by the keyword EXTEND.

define class EMPLOYEE
type tuple ( Fname: string;
Minit: char;
Lname: string;
Ssn: string;
Birth_date: DATE;
Address: string;
Sex: char;
Salary: float;
Supervisor: EMPLOYEE;
Dept: DEPARTMENT; );
operations age: integer;
create_emp: EMPLOYEE;
destroy_emp: boolean;
end EMPLOYEE;
define class DEPARTMENT
type tuple ( Dname: string;
Dnumber: integer;
Mgr: tuple ( Manager: EMPLOYEE;
Start_date: DATE; );
Locations: set (string);
Employees: set (EMPLOYEE);
Projects set(PROJECT); );
operations no_of_emps: integer;
create_dept: DEPARTMENT;
destroy_dept: boolean;
assign_emp(e: EMPLOYEE): boolean;
(* adds an employee to the department *)
remove_emp(e: EMPLOYEE): boolean;
(* removes an employee from the department *)
end DEPARTMENT;

Figure 12.2: Adding operations to the definitions of EMPLOYEE and DEPARTMENT.

Figure 5.6

figure 13.5

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation xml:lang="en">Company Schema (Element Approach) – Prepared by Babak
Hojabri</xsd:documentation>
</xsd:annotation>
<xsd:element name="company">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="department" type="Department" minOccurs="0" maxOccurs="unbounded" />
<xsd:element name="employee" type="Employee" minOccurs="0" maxOccurs="unbounded">
<xsd:unique name="dependentNameUnique">
<xsd:selector xpath="employeeDependent" />
<xsd:field xpath="dependentName" />
</xsd:unique>
</xsd:element>
<xsd:element name="project" type="Project" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
<xsd:unique name="departmentNameUnique">
<xsd:selector xpath="department" />
<xsd:field xpath="departmentName" />
</xsd:unique>
<xsd:unique name="projectNameUnique">
<xsd:selector xpath="project" />
<xsd:field xpath="projectName" />
</xsd:unique>
<xsd:key name="projectNumberKey">
<xsd:selector xpath="project" />
<xsd:field xpath="projectNumber" />
</xsd:key>
<xsd:key name="departmentNumberKey">
<xsd:selector xpath="department" />
<xsd:field xpath="departmentNumber" />
</xsd:key>
<xsd:key name="employeeSSNKey">
<xsd:selector xpath="employee" />
<xsd:field xpath="employeeSSN" />
</xsd:key>
<xsd:keyref name="departmentManagerSSNKeyRef" refer="employeeSSNKey">
<xsd:selector xpath="department" />
<xsd:field xpath="departmentManagerSSN" />
</xsd:keyref>
<xsd:keyref name="employeeDepartmentNumberKeyRef"
refer="departmentNumberKey">
<xsd:selector xpath="employee" />
<xsd:field xpath="employeeDepartmentNumber" />
</xsd:keyref>
<xsd:keyref name="employeeSupervisorSSNKeyRef" refer="employeeSSNKey">
<xsd:selector xpath="employee" />
<xsd:field xpath="employeeSupervisorSSN" />
</xsd:keyref>
<xsd:keyref name="projectDepartmentNumberKeyRef" refer="departmentNumberKey">
<xsd:selector xpath="project" />
<xsd:field xpath="projectDepartmentNumber" />
</xsd:keyref>
<xsd:keyref name="projectWorkerSSNKeyRef" refer="employeeSSNKey">
<xsd:selector xpath="project/projectWorker" />
<xsd:field xpath="SSN" />
</xsd:keyref>
<xsd:keyref name="employeeWorksOnProjectNumberKeyRef"
refer="projectNumberKey">
<xsd:selector xpath="employee/employeeWorksOn" />
<xsd:field xpath="projectNumber" />
</xsd:keyref>
</xsd:element>
<xsd:complexType name="Department">
<xsd:sequence>
<xsd:element name="departmentName" type="xsd:string" />
<xsd:element name="departmentNumber" type="xsd:string" />
<xsd:element name="departmentManagerSSN" type="xsd:string" />
<xsd:element name="departmentManagerStartDate" type="xsd:date" />
<xsd:element name="departmentLocation" type="xsd:string" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Employee">
<xsd:sequence>
<xsd:element name="employeeName" type="Name" />
<xsd:element name="employeeSSN" type="xsd:string" />
<xsd:element name="employeeSex" type="xsd:string" />
<xsd:element name="employeeSalary" type="xsd:unsignedInt" />
<xsd:element name="employeeBirthDate" type="xsd:date" />
<xsd:element name="employeeDepartmentNumber" type="xsd:string" />
<xsd:element name="employeeSupervisorSSN" type="xsd:string" />
<xsd:element name="employeeAddress" type="Address" />
<xsd:element name="employeeWorksOn" type="WorksOn" minOccurs="1" maxOccurs="unbounded" />
<xsd:element name="employeeDependent" type="Dependent" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Project">
<xsd:sequence>
<xsd:element name="projectName" type="xsd:string" />
<xsd:element name="projectNumber" type="xsd:string" />
<xsd:element name="projectLocation" type="xsd:string" />
<xsd:element name="projectDepartmentNumber" type="xsd:string" />
<xsd:element name="projectWorker" type="Worker" minOccurs="1" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Dependent">
<xsd:sequence>
<xsd:element name="dependentName" type="xsd:string" />
<xsd:element name="dependentSex" type="xsd:string" />
<xsd:element name="dependentBirthDate" type="xsd:date" />
<xsd:element name="dependentRelationship" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Address">
<xsd:sequence>
<xsd:element name="number" type="xsd:string" />
<xsd:element name="street" type="xsd:string" />
<xsd:element name="city" type="xsd:string" />
<xsd:element name="state" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Name">
<xsd:sequence>
<xsd:element name="firstName" type="xsd:string" />
<xsd:element name="middleName" type="xsd:string" />
<xsd:element name="lastName" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Worker">
<xsd:sequence>
<xsd:element name="SSN" type="xsd:string" />
<xsd:element name="hours" type="xsd:float" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="WorksOn">
<xsd:sequence>
<xsd:element name="projectNumber" type="xsd:string" />
<xsd:element name="hours" type="xsd:float" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

Figure 13.5: An XML schema file called company.