---
sourceDocument: Xanadu Now Platform の管理
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/platform-administration

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu Now Platform の管理

ft:clusterId :

    - platadm

bundleId :

    - platadm

workflow :

    - Platform


---

# テーブルのフラット化

# テーブルのフラット化 {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：4分

テーブルをフラット化すると、関連するテーブルの階層が 1 つのテーブルとしてリレーショナルデータベースに格納されます。

## 拡張モデル {#c_TaskTableFlattening__section_lsz_nvx_cbb}

システムには、リレーショナルデータベースにテーブル階層を格納するために、次のような拡張モデルがあります。  
{#c_TaskTableFlattening__table_chh_wbf_dbb__entry__2}

| 拡張モデル | テーブルのフラット化の有無 |
|-|-|
| クラス別テーブル | なし |
| 階層別テーブル | あり |
| パーティション別テーブル | はい |
[表 : 1. 利用可能な拡張モデル]

{#c_TaskTableFlattening__table_chh_wbf_dbb}

## クラス別テーブル {#c_TaskTableFlattening__section_gcd_t2y_cbb}

\[クラス別テーブル\] 拡張モデルでは、階層の各テーブルをリレーショナルデータベースにある独自の物理テーブルに格納します。各物理テーブルは、ソーステーブルのテーブルプリフィックスを使用して、それぞれ異なるクラスのレコードを格納します。\[クラス別テーブル\] 拡張モデルの例には、資産 \[alm_asset\] テーブルとその子テーブルであるハードウェア \[alm_hardware\]、消耗品 \[alm_consumable\]、施設 \[alm_facibility\]、およびソフトウェアライセンス \[alm_license\] があります。階層の親テーブルである資産は、子孫テーブルにすべてのレコードのコピーを格納します。

\[クラス別テーブル\] 拡張モデルのレコードを検索するため、システムでは複数のテーブルのレコードをクエリし、結果を結合します。たとえば、関連施設でハードウェアを検索する場合、システムはハードウェア、施設、および資産テーブルの結果を結合する必要があります。

テーブルの結合は、リレーショナルデータベースでパフォーマンスのボトルネックを引き起こします。クエリーに含まれるクラスが多いほど、クエリーのパフォーマンスは低下します。したがって、テーブル階層の最上位のレコードに対してクエリーを行うと、すべての子孫テーブルを結合する必要があるため、パフォーマンスは最も低くなります。

テーブルの作成時には、デフォルトで \[クラス別テーブル\] 拡張モデルが使用されます。ほとんどのシステムテーブルでも、フラット化してもパフォーマンス上のメリットがないため、 \[クラス別テーブル\] 拡張モデルが使用されます。

## 階層別テーブル {#c_TaskTableFlattening__section_qqk_52y_cbb}

\[階層別テーブル\] 拡張モデルでは、リレーショナルデータベースにある単一のフラットな物理テーブルに、テーブル階層全体を格納します。物理テーブルには、「タスク」のような階層の親テーブルの名前が付けられます。物理テーブルには、テーブル階層のすべてのレコードが含まれ、階層の各子孫テーブルにクラス名列の値が割り当てられます。ソーステーブルの名前がクラス名の値として使用されます。たとえば、タスクレコードには、変更、インシデント、問題などのクラス名を付けることができます。

テーブル階層内のレコードを検索するために、システムでは物理テーブルをクエリーし、クラス名列を使用して結果を絞り込みます。このようなクエリーでは複数のテーブルの結果を結合する必要がないため、システムの検索パフォーマンスが向上します。

MySQL データベースのタスクテーブル階層には、\[階層別テーブル\] 拡張モデルが使用されます。他のテーブルでは、フラット化してもパフォーマンス上のメリットがないため、\[クラス別テーブル\] 拡張モデルが使用されます。Oracle データベースで \[階層別テーブル\] を使用する場合は、テクニカルサポートにお問い合わせください。

## パーティション別テーブル {#c_TaskTableFlattening__section_d5h_v2y_cbb}

\[パーティション別テーブル\] 拡張モデルでは、リレーショナルデータベースにある単一のフラットな論理テーブルに、テーブル階層全体を格納します。各論理テーブルには、それをサポートするパーティションと呼ばれる複数の物理ストレージテーブルを含めることができます。各パーティションは、列数、インデックス数、行サイズなど、物理テーブルで使用できるデータベースリソースを最適化します。論理テーブルに追加のリレーショナルデータベースリソースが必要になるたびに、パーティションが追加されます。

各論理テーブルには階層の親テーブルの名前が付けられ、サポートしている各物理パーティションの名前は論理名にパーティション名を加えて構成されます。たとえば、ベース構成アイテムの \[cmdb\] テーブルは、パーティションのない論理テーブルとして開始されます。ハードウェア構成アイテムが相当量のデータベースリソースを消費すると、それらを格納する cmdb$par1 というパーティションが作成されるとします。その後、コンピューター構成アイテムが相当量のデータベースリソースを消費した場合は、もちろんこれらのレコードを格納するために 2 つ目のパーティション cmdb$par2 が作成されます。

各論理テーブル内では、階層の各子孫テーブルにクラス名列の値が割り当てられます。たとえば、ベース構成アイテムの論理テーブル内には、アプリケーション、コンピューター、および IP ルーターのクラス名を含むレコードがあります。また、階層の各子孫テーブルには 2 桁のクラスパス値も割り当てられます。クラスパスは、階層内のテーブルの場所に基づいています。たとえば、親クラス「ハードウェア」には「/!!/!D」などのクラスパスがあり、子クラス「コンピューター」には「/!!/!D/!!」などのクラスパスがあります。

\[パーティション別テーブル\] 拡張モデルのレコードを検索するために、システムは論理テーブルとそのパーティションをクエリし、クラスパスの列を使用して結果を絞り込みます。このようなクエリーでは複数のテーブルの結果を結合する必要がないため、システムの検索パフォーマンスが向上します。さらに、クラスパスによって検索するレコードの合計数が削減されるため、さらに検索パフォーマンスが向上します。

MySQL データベースのベース構成アイテム \[cmdb\] テーブル階層には、\[パーティション別テーブル\] 拡張モデルが使用されます。Oracle データベースで \[パーティション別テーブル\] を使用する場合は、テクニカルサポートにお問い合わせください。
* **[テーブル階層と拡張モデルの表示](https://servicenow-prod.fluidtopics.net/yB_1s5JAh83e0BhAKA3Lmg)**   
  テーブルで使用される拡張モデルを決定します。