Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







Inheritance Data Structures and Methods

Oracle Database Tips by Donald Burleson

Inheritance is defined as the ability of a lower-level object to inherit or access the data structures and behaviors associated with all classes which are above it in the class hierarchy. Multiple inheritance refers to the ability of an object to inherit data structures and behaviors from more than one superclass.

To illustrate, let's look at an application of this system for a vehicle dealership. Occurrences of ITEMs to a dealership are VEHICLES; beneath the vehicle class, we may find subclasses for cars and for boats (see Figure 2.9). Within cars, the classes may be further partitioned into classes for TRUCK, VAN, and SEDAN. The VEHICLE class would contain the data items which are unique to vehicles, including the vehicle ID and the year of manufacture. The CAR class, because it IS-A VEHICLE, would inherit the data items of the VEHICLE class. The CAR class might contain data items such as the number of axles and the gross weight of the vehicle. Because the VAN class IS-A CAR, which in turn IS-A VEHICLE, objects of the VAN class will inherit all data structures and behaviors relating to CARS and VEHICLES.

NOTE: It is critical to the understanding of inheritance to note that inheritance happens at different times during the life of an object.

Inheritance of Data Structures--At object creation time, inheritance is the mechanism whereby the initial data structure for the object is created. It is critical to note that only data structures are inherited, never data. It is a common misconception that data is inherited, such that an order may inherit the data items for the customer that placed the order. We must understand that inheritance is only used to create the initial, empty data structures for the object. In our example, all vehicles would inherit data definitions in the VEHICLE class, while an object of a lower-level class (say, SAILBOAT) would inherit data structures that only apply to sailboats--as in sail_size.

Inheritance of Methods--Inheritance also happens at runtime when a call to a method (stored procedure) is made. For example, assume that the following call is made to sailboat object:


The database will first search for the compute_rental_charges in the sailboat class; if it is not found, the database will search up the class hierarchy until compute_rental_charges is located.

Not all classes within a generalization hierarchy will have objects associated with them. The object-oriented paradigm allows for abstraction, which means that a class may exist only for the purpose of passing inherited data and behaviors. The classes VEHICLE and CAR would probably not have any concrete objects, while objects within the VAN class would inherit from the abstract VEHICLE and CAR classes. Multiple inheritance is also demonstrated by the AMPHIBIAN_CAR class. Any instances of this class will inherit data and behaviors from both the CAR and the BOAT classes.

It is important to note the tremendous difference between one-to-many relationships and IS-A relationships. In the above example, this entire class hierarchy describes vehicles which are associated with the ITEM entity in the overall database. Class hierarchies do not imply any data relationships between the classes. While one CUSTOMER may place many ORDERS, it is not true that one CAR may have many SEDANS.

Inheritance example

Let's now take a look at how inheritance might work within a database object.  As we recall, inheritance happens at two times during the life of an object.  When the object is created, data structures are inherited, and at runtime, methods may be inherited from the class hierarchy.

In a University database, we have several types of students.  The main question when designing classes is to ask whether the different types of students will have different data or different behaviors.  Your analysis of the data has derived the following data definitions for students:

CREATE CLASS student (
   student_ID    number (5);
       first_name             varchar(20),
       MI                     char(1),
       last_name              varchar(20)

CREATE CLASS graduate_student
        WITHIN CLASS student
    undergraduate_degree      char(3)
       CONSTRAINT undergraduate_degree in ('BA','BS'),
    undergraduate_major       varchar(20,
    undergraduate_school_name varchar(30);
      street_address          varchar(20), 
      city_name               varchar(20),
      zip_code                number(9),
    mentor_name               varchar(20),
    thesis_review_date        date);

CREATE CLASS non_resident_student WITHIN CLASS student
    state_of_origin           char(2),
    region_of_origin          char(5)
       CONSTRAINT region_of_origin in ('NORTH', 'SOUTH','EAST','WEST'));

CREATE CLASS foreign_student WITHIN CLASS non_resident_student (
   country_of_origin          varchar(20),
   visa_expiration_date       date);

Note: This University does not allow foreign or non-resident students into their graduate school, and this is why we see that the the graduate_school is only a sub-class of the student class

Now let's examine how these data structures will be used by the database at object creation time.  When a foreign_student object is created, a data structure will be created that contains all of the data structures from each higher level object.  For example, this is what the data structure would look like for a foreign_student:

   student_ID             number (5);
       first_name         varchar(20),
       MI                 char(1),
       last_name          varchar(20)
   state_of_origin        char(2),
   region_of_origin       char(5)
       CONSTRAINT region_of_origin in ('NORTH', 'SOUTH','EAST','WEST'));
   country_of_origin      varchar(20),
   visa_expiration_date   date);

Here we can see that a foreign_student would inherit the data structures contained in both the student as well as the non_resident_student classes in addition to it's own class data structures.  When a foreign_student is created, it is treated as a student object, but the database is aware that it is a foreign_student and will always check the foreign_student object first before looking inside other student class definitions.

Also note that the constraint for valid valid values is also inherited into the data definition.  Whenever a foreign_student object is created, the region_of_origin column must have one of the specified values.

2. Class hierarchy Diagram

The class hierarchy diagram is used to describe all of the data structures and methods that can be inherited by a database object.

  1. Data type list - These are all of the data structures that are inherited by lower-level objects when they are instianted. Note that some properties such as value constraints can also be inherited.  For example, the vehicle_color data structure will also contain validation rules, to insure that the colors are either RED, BLUE GREEN or YELLOW.  Here is a sample data structure:

  2. Method list - This section describes all of he methods associated with a class.  The information here includes the method name, the required input parameters, and the return value.  In the following example, the compute_charge method accepts the vehicle ID and the return data.  This method then performs the computation (the details of which are hidden from the application), and returns a number for the charge.




Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.