テーブルの継承について［ServiceNow］

※この記事はServiceNow初心者が学習用のために記載した記事です。内容について誤っている場合がございます。不足点などございましたらコメントいただけますと幸いです。

# ServiceNowにおけるテーブルの継承とは？
- ServiceNowでは、テーブルの継承（Table Inheritance）を利用することで、共通のフィールドや機能を持つテーブルを効率的に管理できる
- オブジェクト指向プログラミングの継承概念と似た仕組みである


# テーブルの継承の仕組み  
- ServiceNowのテーブルは、他のテーブルを継承（Extends）することができる
- 継承には 「ベーステーブル」 と 「子テーブル」 の関係がある

### ベーステーブル（Base Table）  
- 他のテーブルが継承する「親テーブル」となる
- 例えば task テーブルは、多くのワークフロー管理テーブルの親テーブルになっている

### 子テーブル（Child Table）  
- ベーステーブルを継承して作成されたテーブル
- 親テーブルのフィールドや機能をそのまま受け継ぐ  
- 例えば incident（インシデント）テーブルは task テーブルを継承している。task の基本的なフィールド（short_description, assigned_to, state など）をそのまま利用できる

# テーブルの継承の種類  
ServiceNowでは、テーブルの継承方法として 「拡張（Extension）」 の概念がある

| 継承の種類 | 説明 |
|-----------|--------------------------------|
| 拡張（Extension） | 子テーブルが親テーブルの全てのフィールドを引き継ぐ |
| 同一テーブル（Same Table） | テーブルは継承せず、独自のフィールドのみを持つ |

# task テーブルの継承例  
ServiceNowで最も代表的なベーステーブルの1つが task テーブル  
task テーブルを継承する主な子テーブルには以下のものがある

| 継承先のテーブル | テーブル ID | 説明 |
|----------------------------|----------------------------------|-------------------------------------------|
| インシデント | incident | ユーザーの問題や障害を管理する |
| 変更要求 | change_request | ITシステムの変更を管理 |
| 問題 | problem | インシデントの根本原因を特定し、恒久的な解決を図る |
| ケース | sn_customerservice_case | 顧客からの問い合わせや問題を管理 |
| サービス要求 | sc_request | サービスカタログのリクエストを管理 |
| 要求項目 | sc_req_item | サービスカタログのリクエスト項目 |
| タスクSLA | task_sla | 各タスクのSLA（サービスレベルアグリーメント）を管理 |

---

# テーブルの継承を確認する方法  
ServiceNowで特定のテーブルがどのテーブルを継承しているか確認する方法を以下に示す

## スキーママップ（Schema Map）を使用
- スキーママップ（Schema Map）とは？
    - ServiceNow内のテーブルの関係（継承、リレーションなど）を視覚的に表示する機能
- 「システム定義（System Definition）」 → 「Tables & Columns」 → テーブルを選択 → 「スキーママップ（Schema Map）」 を押下
![1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3624279/a2863b76-95f6-0342-55e8-b617b4da45ed.png)
- チェックボックスをポチポチしてカスタマイズする
### 各オプションの意味

| オプション         | 説明                                                                 | 具体例 |
|------------------|------------------------------------------------------------------|-----------------------------------------------------------|
| Show Referenced | 選択したテーブルが **参照している**（他のテーブルを参照するフィールドを持っている）テーブルを表示 | `incident` テーブルの `caller_id` フィールドは `sys_user` を参照している → `sys_user` が表示される |
| Referencing     | 選択したテーブルを **参照している**（他のテーブル内のフィールドに、このテーブルの値が格納されている）テーブルを表示 | `sys_user` テーブルを選択 → `incident`（`caller_id`）や `task`（`assigned_to`） などが表示される |
| Extended        | 選択したテーブルが **継承している**（親となる）テーブルを表示 | `incident` は `task` を継承している → `task` が表示される |
| Extending      | 選択したテーブルを **継承している**（子となる）テーブルを表示 | `task` を選択 → `incident`, `change_request`, `problem` などの子テーブルが表示される |

# 継承を利用するメリット  
- 再利用性の向上  
  → 共通のフィールドや機能を親テーブルに集約できる
- 開発の効率化  
  → すべての子テーブルで共通の動作を管理しやすくなる  
- データの一元管理  
  → task テーブルを継承することで、タスク管理全体の統一が取れる  


# task を継承しない代表的なテーブル  
一方で、task を継承しないテーブルもあります。  
これらのテーブルは、タスク管理ではなく、システムの基本設定や資産管理、ユーザー管理などに使われる

| 継承先のテーブル | テーブル ID | 説明 |
|---------------------------|--------------------------|-------------------------------------------|
| ユーザー | sys_user | システム内のユーザー情報を管理 |
| グループ | sys_user_group | ユーザーグループを管理 |
| 設備資産 | alm_asset | ハードウェアやソフトウェア資産を管理 |
| ソフトウェアインストール | cmdb_sam_sw_install | ソフトウェアのインストール情報を管理 |
| コンピュータ | cmdb_ci_computer | 構成管理データベース（CMDB）のコンピュータ情報 |
| ナレッジ記事 | kb_knowledge | ナレッジベースの記事を管理 |
| システムプロパティ | sys_properties | システムの設定値を管理 |
| 監査ログ | sys_audit | システム内の変更履歴を記録 |

## task を継承しない理由  
- task テーブルはタスク管理に特化しているため、ユーザー管理や設定管理には適さない  
- cmdb_ci（構成アイテム）や sys_user（ユーザー情報）は、タスクではなくリソース管理を目的としているため 
ど）は task を継承しない  

# 参考
https://mekeblog.com/servicenow-csa-data-schema/