勤続年数が 10 年以上の社員の社員番号と氏名を検索する SQL は，次のように記述できます。
3.5.2 サブタイプと継承
基本給 INTEGER, …
FUNCTION 勤続年数 ( p t_従業員 ) RETURNS INTEGER
BEGIN
DECLARE working_years INTERVAL YEAR TO DAY;
SET working_years = CURRENT_DATE - p..入社年月日;
RETURN YEAR(working_years);
END, … )
このように，抽象データ型で定義したルーチンをその抽象データ型の値に対して使用できます。例えば，
図 3‒40 実世界の情報と抽象データ型による概念モデル（営業部員の場合）
HiRDB では，あるデータ型を基にその型を特化した抽象データ型をサブタイプとして定義できます。
例えば，定義系 SQL 文 CREATE TYPEのサブタイプ句を使用して，t_従業員を基に，t_営業部員を次に 示すように定義できます。
CREATE TYPE t_営業部員 UNDER t_従業員(
担当顧客 VARCHAR(3000), FUNCTION 顧客総数 ( … ) RETURNS INTEGER
… )
なお，t_従業員のような，サブタイプに対する上位の抽象データ型をスーパタイプといいます。
3. データベースの論理構造
(2) 代替可能性（substitutability）
「営業部員」は「従業員」でもあります。HiRDB では，サブタイプで特化した（下位の）抽象データ型の 値をその上位の抽象データ型の値としても扱えます。例えば，社員表では次に示す SQL で，t_営業部員の 値を
t_従業員の値として列の値にできます。
注意事項
t_営業部員の値も t_従業員の値と同様に扱えるようにするために，この SQL を実行する前に，ALTER ROUTINE を実行し，SQL オブジェクトを再作成しておく必要があります。
INSERT INTO 社員表 VALUES ( 51, t_営業部員(:name AS CHAR(16),…) )
このように，下位の抽象データ型の値が上位の抽象データ型の値としてみなされることを代替可能性
（substitutability）といいます。
(3) 継承（inheritance）
「営業部員」は「従業員」でもあるので，「従業員」と同様に「氏名」や「性別」の属性を持ち，「勤続年 数」算出の操作が適用できると考えられます。
図「実世界の情報と抽象データ型による概念モデル（営業部員の場合）」のように，HiRDB ではサブタイ プで特化した（下位の）抽象データ型にその上位の抽象データ型に定義された属性とルーチンが引き継が れます。
このように，下位の抽象データ型が，上位の抽象データ型の属性及びルーチンを引き継ぐことを継承
（inheritance）といいます。
例えば，継承によって
t_営業部員の値に対して属性「氏名」と操作「勤続年数」が利用できるようになる
ため，t_営業部員の値を列値に挿入した社員表について，次に示す SQL のように，先に示した SQL を変 更することなく実行できます。注意事項
この SQL を実行する前に，ALTER ROUTINE を実行し，SQL オブジェクトを再作成しておく必要が あります。
SELECT 社員番号, 従業員..氏名, 勤続年数(従業員) FROM 社員表
WHERE 勤続年数(従業員) >= 10
サブタイプと継承で，次に示す効果が期待できます。
•「営業部員」が「従業員」であるという代替可能性の概念を簡潔に表現できます。
• 属性及びルーチンの定義を共有し，既存の定義を基に新しい定義を追加できます。そのため，データ ベース及びアプリケーション開発のオーバヘッドを削減でき，拡張性のあるシステムを構築できます。
3. データベースの論理構造
(4) 多重定義（override）
「従業員」に対して「報酬」を査定する操作を考えます。報酬の査定は，例えば，「基本給」，「勤続年数」，
「勤続年数に基づく報酬率」によって設定された情報を基に，作業状況を評価して査定することが考えられ ます。
一方で，継承によって「従業員」に定義される操作「報酬」は自動的に「営業部員」に引き継がれます。
しかし，特に営業部員については，一般的な従業員の査定方法とは異なり，営業活動で注文を受けた「顧 客総数」などを基に，営業部員特有の査定をすることが考えられます。
実世界での従業員，営業部員についての操作を次の図に示します。
図 3‒41 実世界での従業員，営業部員についての操作
例えば，「従業員報酬」や「営業部員報酬」のような，それぞれの抽象データ型ごとに異なる名称のルーチ ンを定義するとします。その場合，代替可能性で「従業員」の値と「営業部員」の値を統一的に扱えるの にもかかわらず，それぞれの値の型によって呼び出すルーチンの名称を変更しなければならなくなります。
そのため，アプリケーションでは次に示す操作系 SQL を実行できなくなります。
× SELECT 社員番号, 従業員..氏名, 従業員報酬(従業員) FROM 社員表
…「営業部員」に対して，営業部員特有の報酬査定を実行できません。
× SELECT 社員番号, 従業員..氏名, 営業部員報酬(従業員) FROM 社員表
…「営業部員」でない「従業員」に対しても，営業部員特有の報酬査定を実行してしまいます。
3. データベースの論理構造
HiRDB では，上位の抽象データ型で定義されたルーチンと同じ名前のルーチンを下位の抽象データ型を定 義するときに上書きして定義できます。このように上書きして定義することを多重定義（override）とい います。
多重定義を次の図に示します。
図 3‒42 多重定義
また，多重定義されたルーチンの実行では，その引数となる値の型に応じて，HiRDB が自動的に適切な定 義に従って実行します。多重定義によって，呼び出すルーチンの名称を値の型によって変更する必要がな くなります。そのため，次に示す操作系 SQL を実行できます。
注意事項
この SQL を実行する前に，ALTER ROUTINE を実行し，SQL オブジェクトを再作成しておく必要が あります。
SELECT 社員番号, 従業員..氏名, 報酬(従業員) FROM 社員表
…多重定義したルーチン「報酬」によって，実行時にそれぞれの引数の値に応じたルーチンが実行されます。
3. データベースの論理構造
この SQL の実行では，t_従業員型の値に対しては，t_従業員型に定義されたルーチン「報酬」が実行さ れ，t_営業部員型の値に対しては，t_営業部員型に定義されたルーチン「報酬」が実行されます。
なお，上記の SQL のように，アプリケーションではルーチンが多重定義されているかどうかを意識しない でルーチンを呼び出せます。また，多重定義によってルーチンを追加した場合でも，アプリケーションを 変更しないで SQL を実行できるようになります。