テーブル構造の FAQDescription次の KB には、Now Platform 内のテーブル構造に関する重要な情報が記載されています。インスタンスに実装する場合はテーブル構造を理解する必要があります。この KB は、プラットフォームでテーブルを直接操作するときに、トラブルシューティングが必要な状況で発生する質問と、考慮に入れるべき情報を提供します。 FAQ Now Platform ではどのテーブル構造が使用されますか？ ServiceNOW は、階層別テーブル (TPH)、クラス別テーブル (TPC)、およびパーティション別テーブル (TPP) の 3 種類のテーブル構造を採用しています。 TPC - すべての一般的な DB に使用される、通常のテーブル構造です。親子テーブル構造では、すべての直接の子孫は親テーブルからフィールド/列を継承します。子クラスのレコードには、子テーブル内のレコードと、各親テーブル内のレコードが含まれます。各レコードには、データフィールド、クラス固有のフィールドに加え、階層内のすべてのテーブルに共通する sys_id フィールドが含まれます。 TPH - このテーブルモデルは Dublin リリースで導入され、タスクテーブルのテーブル階層にのみ適用されます。特定の階層のすべてのクラスを格納する物理 DB テーブルが 1 つ存在します。現在、これはタスクテーブルで使用されます。つまり、1 つの物理データベース テーブル "task" があり、タスクのすべての子クラスは 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 で発生します。タスクは、設計上、膨大な数のレコードを含むスーパーテーブルなので、新しいフィールドを一から作成するトランザクションには時間がかかります。Additional Informationテーブルのフラット化 テーブルの拡張とフラット化