Inheritance of table behavior in a table hierarchy
- All columns of the supertable
- Constraint definitions
- Storage options
- Indexes
- Referential integrity
- Triggers
- The access method
CREATE TABLE person OF TYPE person_t
(PRIMARY KEY (name))
FRAGMENT BY EXPRESSION
name < 'n' IN dbspace1,
name >= 'n' IN dbspace2;
CREATE TABLE employee OF TYPE employee_t
(CHECK(salary > 34000))
UNDER person;
CREATE TABLE sales_rep OF TYPE sales_rep_t
LOCK MODE ROW
UNDER employee;
In this table hierarchy, the employee and sales_rep tables inherit the primary key name and fragmentation strategy of the person table. The sales_rep table inherits the check constraint of the employee table and adds a LOCK MODE. The following table shows the behavior for each table in the hierarchy.
- Table
- Table Behavior
- person
- PRIMARY KEY, FRAGMENT BY EXPRESSION
- employee
- PRIMARY KEY, FRAGMENT BY EXPRESSION, CHECK constraint
- sales_rep
- PRIMARY KEY, FRAGMENT BY EXPRESSION, CHECK constraint, LOCK MODE ROW
CREATE TABLE person OF TYPE person_t
(PRIMARY KEY (name))
FRAGMENT BY EXPRESSION
name < 'n' IN person1,
name >= 'n' IN person2;
CREATE TABLE employee OF TYPE employee_t
(CHECK(salary > 34000))
FRAGMENT BY EXPRESSION
name < 'n' IN employ1,
name >= 'n' IN employ2
UNDER person;
CREATE TABLE sales_rep OF TYPE sales_rep_t
LOCK MODE ROW
UNDER employee;
Again, the employee and sales_rep tables inherit the primary key name of the person table. However, the fragmentation strategy of the employee table overrides the fragmentation strategy of the person table. Consequently, both the employee and sales_rep tables store data in dbspaces employ1 and employ2, whereas the person table stores data in dbspaces person1 and person2.