テーブル構造の FAQIssue 次の KB には、Now Platform 内のテーブル構造に関する重要な情報が記載されています。インスタンスに実装する場合はテーブル構造を理解する必要があります。この KB は、プラットフォームでテーブルを直接操作するときに、トラブルシューティングが必要な状況で発生する質問と、考慮に入れるべき情報を提供します。 FAQ Now Platform ではどのテーブル構造が使用されますか？ ServiceNOW は、階層別テーブル (TPH)、クラス別テーブル (TPC)、およびパーティション別テーブル (TPP) の 3 種類のテーブル構造を採用しています。 TPC - すべての一般的な DB に使用される、通常のテーブル構造です。親子テーブル構造では、すべての直接の子孫は親テーブルからフィールド/列を継承します。子クラスのレコードには、子テーブル内のレコードと、各親テーブル内のレコードが含まれます。各レコードには、データフィールド、クラス固有のフィールドに加え、階層内のすべてのテーブルに共通する sys_id フィールドが含まれます。 TPH - このテーブルモデルは Dublin リリースで導入され、タスクテーブルのテーブル階層にのみ適用されます。特定の階層のすべてのクラスを格納する物理 DB テーブルが 1 つ存在します。現在、これはタスクテーブルで使用されます。つまり、1 つの物理データベーステーブル「タスク」があり、タスクのすべての子クラスは単一の物理タスクテーブルに格納されます。 TPP - このテーブルモデルは Jakarta で導入され、CMDB 階層内のテーブルにのみ適用されます。タスクと同様、TPH モデルの CMDB テーブルも単一のフラット化されたテーブルです。ただし、TPP では複数のパーティションテーブルを作成できる点が異なります。パーティショニングは、DB の制限 (64 KB の静的行サイズと最大 64 個のインデックス制限) を超過せずに、より多くの列を作成するための手段です。TPP テーブルクエリはタスククエリとは外観が異なることに注意してください。 拡張モデルを選択できますか？ いいえ。拡張モデルは、テーブルの作成時にプラットフォームによって設定されます。新しいスタンドアロンテーブルが作成されるか、スタンドアロンテーブルから拡張される場合、テーブルは TPC 拡張モデルを使用します。 タスク階層内のテーブルを拡張する新しいテーブルが追加された場合、通常は TPH になります。状況によっては、TPH/TPC のハイブリッド階層を作成する TPC テーブルとして作成できます。最も一般的なのは、新しいテーブルが階層に追加されたときのタスクテーブルの全体的なサイズです。階層内のテーブルを拡張して新しいテーブルを CMDB 階層に追加すると、そのテーブルは階層内のベーステーブルで指定された拡張モデルを使用します。Jakarta にアップグレードしたときに階層を TPP に変換しなかった場合を除き、通常は TPP になります。変換しなかった場合は TPC になります。拡張モデルは階層のベーステーブルでのみ設定され、空の場合はデフォルトで TPC になります。 TPH が導入されたのはなぜですか？ TPH はダブリンで紹介され、タスクテーブル周辺のパフォーマンスを軽減するために導入されました。 TPHの利点は何ですか? 1 つの物理タスクテーブルを使用して、タスクの子孫テーブルをクエリするときに必要な内部結合を排除します。これにより、クライアントユーザーのパフォーマンスが向上します。 TPH の欠点は何ですか？ TPH には、基本的に多くの追加テーブルで構成される 1 つのスーパーテーブルが含まれます。このテーブルモデルでは、64 KB の静的行サイズ、1000 列のハード制限、64 の最大インデックス制限 (使用している基になる DB バージョンに応じて 128 インデックス可能) などの DB 制限に達する可能性がはるかに高くなります。さらに、物理ストレージ列がテーブルに作成されると ALTER が開始されます。タスクテーブルは大きいスーパーテーブルなので、スキーマレベルの変更 (新しい列の追加、インデックスの追加、フィールド長の増減など) を行っている管理者は長時間をかけて ALTER を実行しなくてはなりません。これは、ライブ物理テーブルのすべてのデータは一時テーブルにコピーされるからです。タスクテーブルのサイズによっては、コピープロセスに時間がかかることがあります。 タスクのフラット化とは何ですか？ タスクのフラット化とは、タスクファミリ階層をクラス別テーブルから階層別テーブルに変更するプロセスのことです (複数の物理テーブルを 1 つの大きいスーパーテーブルにまとめます)。 ハイブリダイゼーションとは? これは、タスクテーブル（インシデントや問題など）の直接の子である階層のタスクフラット化を元に戻すプロセスです。階層内の各テーブルに対してTPCテーブルを作成し、データを入力します。ハイブリッド化できるのは、TPHのままの階層のみです。TPCテーブルはハイブリッド化できません。一度ハイブリッド化した階層は、将来元に戻すことはできません。 このプロセスは、タスクテーブルが64KBの静的行サイズまたは1000列の制限というDBの制限に近づいた際、テーブル構造から不要な列を削除したり、データモデル設計を変更してタスクテーブルに過剰な列が追加されないようにしたり（スタンドアロンの関連テーブルを導入するなど）ができない場合に検討されます。 階層には、選択した階層内でのみ使用されるフィールドが含まれている必要があるため、どの階層がハイブリダイゼーションの最適な候補であるかを判断するには分析が必要です。これにより、階層がハイブリダイズされるときにそれらのフィールドをタスクテーブルから削除できるため、静的な行サイズと列の合計数が削減されます。選択した階層内のすべてのテーブルが TPC テーブルに変換されます。実装後は、テーブルからデータを取得する際に、ハイブリッド化されたテーブルとタスクテーブル間の結合が必要になります。また、挿入、更新、削除は通常、複数のテーブルに対して実行する必要があります。したがって、ハイブリッド化によって影響が出る可能性はありますが、不要な列を削除できない場合は、他に選択肢がない可能性があります。 この操作は元に戻せないため、他のすべての手段を試した場合にのみ検討する必要があります。本番環境で実行する前に、この影響について徹底的にテストする必要があります。 ストレージエイリアスとは何ですか？ ストレージエイリアスレコードは、TPC テーブルと TPH テーブルの両方の情報を保持し、バックエンドデータベースで論理/物理要素がマップされる方法と場所を特定します。TPH 要素は論理要素として存在し (つまり物理タスクテーブルに物理的に存在しない)、a_str_3 という列名でタスクの物理列にマップされることがあります。TPC テーブル要素は、アプリケーション要素名が物理列名と同じである場合、通常どおりマップされます。 例：TPC：カスタムテーブル u_test の u_outage は、u_outage として DB に表示されます TPH：UI からフラット化されたタスクの u_test フィールドは、論理的には u_test として表示されますが、a_str_1 と呼ばれるタスクのフィールドに物理的にマップされます。 TPH または TPP では、物理フィールドが論理フィールドのmax_lengthよりも長くなる可能性があります。 ストレージエイリアスが必要なもう 1 つの理由は、プラットフォームでは、基盤となるデータベースの制限を超える長いテーブル名と要素名の使用が許可されていることです。その結果、テーブル名または要素名の長さが 30 文字を超える場合、名前は短縮され、結果のエイリアスが基礎となる物理テーブルの名前の代わりに使用されます。その後、プラットフォームは、データベースに対して SQL を実行するときに、長い名前とエイリアスの間でマップされます。 グロミングとは何ですか？ グロミングの概念は TPH テーブルに適用され、直接的な関係を持たない複数の論理要素 (兄弟要素といとこ要素) をタスクテーブルの単一の物理ストレージ列にマップできます。グロミングは、1 つのテーブルでの 64 KB の静的行サイズ、100 列のハード制限、最大 64 個のインデックスなど、DB の制限を緩和するのに役立ちます。CMDB の TPP にもグロミングはありますが、TPP ではフィールドが追加されたベーステーブルからフィールドを継承するすべてのテーブルに対してストレージエイリアスが必要である一方、TPC ではフィールドが追加されたテーブルに対してのみストレージエイリアスが指定される点が異なります。 テーブルに列を追加する時間に差異があるのはなぜですか？ 新しいディクショナリーエントリが作成されると、次のいずれかの処理が行われます。 既存の物理列に新しい要素を表示しようとします(TPHおよびTPP拡張モデルにのみ適用されます)表示する物理列がない場合は、タスクテーブルを変更し、新しい物理列を作成します。 TABLE ALTER が必要な場合、タスクテーブルのサイズが大きいと、物理タスクテーブルに列を作成するのに時間がかかることがあります。これは、一時テーブルを作成する際に、タスクテーブルのすべての生データをコピーし、一時テーブルを上書きしなくてはならないからです。この特定のプロセスは UI からは確認できず、バックエンド DB で発生します。タスクは、設計上、膨大な数のレコードを含むスーパーテーブルなので、新しいフィールドを一から作成するトランザクションには時間がかかります。Related Linksテーブルのフラット化 テーブル拡張とフラット化