テーブルのフラット化

  • リリースバージョン: Zurich
  • 更新日 2025年07月31日
  • 所要時間:5分
  • テーブルをフラット化すると、関連するテーブルの階層が 1 つのテーブルとしてリレーショナルデータベースに格納されます。

    拡張モデル

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

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

    クラス別テーブル

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

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

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

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

    階層別テーブル

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

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

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

    パーティション別テーブル

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

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

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

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

    MySQL データベースのベース構成アイテム [cmdb] テーブル階層には、[パーティション別テーブル] 拡張モデルが使用されます。Oracle データベースで [パーティション別テーブル] を使用する場合は、テクニカルサポートにお問い合わせください。