Tables & Dictionary - よくある質問 (FAQ)Issue <!-- div.margin { padding: 10px 40px 40px 30px; } table.tocTable { border: 1px solid; border-color: #e0e0e0; background-color: #fff; } .title { color: #d1232b; font-weight: normal; font-size: 28px; } h1 { color: #d1232b; font-weight: normal; font-size: 21px; margin-bottom: 5px; border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: #cccccc; } h2 { color: #646464; font-weight: bold; font-size: 18px; } h3 { color: #000000; font-weight: bold; font-size: 16px; } h4 { color: #666666; font-weight: bold; font-size: 15px; } h5 { color: #000000; font-weight: bold; font-size: 13px; } h6 { color: #000000; font-weight: bold; font-size:14px; } ul, ol { margin-left: 0; list-style-position: outside; } --> 概要 この記事の目的は、テーブルとディクショナリに関連してカスタマーサポートによく寄せられるいくつかのリクエスト/質問に答えることです。この記事を最新の状態に保つために、コメントに他の質問を追加してください。 この情報は一般的なものであり、フォローアップの質問がある場合は、カスタマーサポートにお問い合わせください。 FAQ どのテーブル拡張モデルが使用されていますか?列ラベルが空白または (空) と表示されるのはなぜですか?ストレージエイリアスとはどのようなもので、どのように使用されますか?スコープ対象のアプリケーションで独自のカスタムテーブルを削除できないのはなぜですか?カスタムテーブルに「update_synch」を追加できないのはなぜですか?物理テーブル内に格納できる列の数テーブルの作成時/列の追加時のデザインの検討計算フィールドを使用しています。このフィールドにソートを適用するときに順序が正しくないのはなぜですか?「テーブルあたりの最大列数に達しました」というエラーが表示されました。特長 どのテーブル拡張モデルが使用されていますか? Now Platform は次の拡張モデルを提供します。 クラス別テーブル: 親クラスと子クラスごとに個別のデータベーステーブルを作成します。階層別テーブル: 親クラス用に 1 つのデータベーステーブルを作成します。このテーブルには、親クラスと子クラスのすべてのレコードが格納されます。子クラスには個別のデータベーステーブルはありません。パーティション別テーブル: 親クラス用に 1 つのデータベーステーブルを作成します。このテーブルには、親クラスと子クラスのすべてのレコードが格納されます。子クラスには個別のデータベーステーブルはありません。データベーステーブルがストレージの上限に達すると、システムはストレージテーブル (パーティション) を動的に追加して追加のレコードを保存します。 これらの拡張モデルとその違いの詳細については、こちらを参照してください。 https://docs.servicenow.com/csh?topicname=table-extension-and-classes.html&version=latest 列ラベルが空白または (空) と表示されるのはなぜですか? 通常、列ラベルが空白または空として表示されている場合は、その列に関連する何かが壊れていることを意味します。辞書レコードの XML を表示すると、ラベルが入力されていることがわかりますが、UI には表示されていません。 これを引き起こす可能性のあるいくつかの要因は次のとおりです。 フィールドがデータベースで正しく作成されなかった。ストレージエイリアスが正しく作成されていないか、別の列で使用されている。列がまだ作成中。 この問題が発生していると思われる場合は、 KB0727729 を確認するか、カスタマーサポートにご連絡ください。 ストレージエイリアスとはどのようなもので、どのように使用されますか? ストレージエイリアスエントリは、インスタンス内のテーブルに作成されたフィールドごとに作成されます。ストレージエイリアスがどのような目的を果たすかを説明する前に、管理者/ユーザーが知っておくべき重要なフィールドがいくつかあります。 要素名:この値は、フィールドがフロントエンドからどのように表示されるかを反映します。つまり、ユーザーがsys_dictionaryでcolumn_nameフィールドを参照する場合、またはユーザー/管理者がフィールドの値を操作するスクリプトを記述する場合、これは要素名に基づいています。 ストレージエイリアス :この値は、特定の要素のデータが格納されている場所を正確に示します。フィールドがバックエンドデータベースから操作されている場合、プラットフォームはstorage_alias値を調べて、ストレージエイリアス値と、データが操作されているテーブルクラスの実際の値であるsys_class_nameに基づいて、どのデータを操作する必要があるかを理解します。ストレージ別名の値は、ベーステーブルの実際の物理列です。 ストレージテーブル名 :この値は、要素がどの物理テーブルに属しているかを示します。task 内のすべての論理要素について、ストレージテーブル名は常に task になります。これが TPC テーブルの場合、ストレージテーブル名の値は、物理要素が存在する物理テーブルの名前になります。 ストレージエイリアスの使用目的: 1.論理 TPH)/物理 (TPC) 要素をバックエンド データベース内の実際の物理列にマッピングします。 簡単に言うと、これは、物理ストレージテーブルの列から、要素内の実際のデータがどこにあるかを教えてくれることを意味します。 2.複数の兄弟要素が 1 つの物理列を共有できるようにします。 (グロミングとも呼ばれますが、TPH の場合のみ) 3.sys_documentation (ラベル) レコードをそれぞれの要素にマッピングします。これは、ユーザー/アドミンがフォーム、レポート、およびリストビューのアプリケーションフロントエンドから表示するものです。 その他の注意事項: - 同じ論理クラス内の 2 つの論理要素が同じ物理列を共有することはできません (つまり、ユーザーがインシデントに 2 つの文字列フィールドを作成した場合、データベース内の同じ物理列にマップされません)。 - 親要素と子要素が同じ物理列を共有することはできません (つまり、フィールドがインシデントで作成された場合、タスクのフィールドが既に物理列を使用している物理列にマップすることはできません。 - 兄弟要素のみが同じ物理列を共有できます(つまり、ユーザーはchange_requestとインシデントに参照フィールドを作成し、同じ物理列にマップできます)。 - フィールドがタスクテーブル(sys_class_nameはタスク)に直接作成された場合、グロムすることはできません。 スコープ対象のアプリケーションで独自のカスタムテーブルを削除できないのはなぜですか? スコープ対象のアプリケーションからカスタムテーブルを削除しようとすると、[テーブルを削除] ボタンが使用できない。これは既知の問題が原因です: PRB762839 には Orlando の修正バージョンが意図されています。 インスタンス内の特定のテーブルを削除できないように、システムに制限があります。現在、スコープアプリケーションのカスタムテーブルの削除はブロックされています。現在のところ、ワークアラウンドはカスタマーサポートに連絡することです。カスタマーサポートは、スコープ対象のアプリケーションから顧客テーブルを削除するお手伝いをします。 詳しくはこちら: KB0623901 カスタムテーブルに「update_synch」を追加できないのはなぜですか? この理由は、 のドキュメントに記載されています 警告:update_synch属性を辞書レコードに追加しないでください。不適切に使用された場合、この属性はパフォーマンス上の大きな問題を引き起こすか、インスタンスを使用不可能にする可能性があります。この属性の追加はサポートされていません。 ただし、「更新セット内で追跡」に関する OOB UI アクションsys_db_object使用して、これを sys_metadata に再ペアレンティングすることで、カスタムテーブルを更新セットで追跡するために使用できます。 ただし、これは注意して使用し、合法的で限られた状況で使用する必要があります。 この UI アクションを使用するには、この UI アクションを使用するために合格する必要がある基準のリストがあります。続行する前に、この KB のすべての情報を確認してください。 KB0726953 物理テーブル内に格納できる列の数 テーブル内の列数は、ServiceNow プラットフォームではなく、使用されるデータベースによって定義されます。 MYSQL MySQL の制限であり、ServiceNow によって制御されていません。:テーブルあたり 4096 列というハード制限がありますが、特定のテーブルでは有効な最大値より小さくなる可能性があります。正確な制限は、いくつかの相互作用する要因によって異なります。すべてのテーブル (ストレージエンジンに関係なく) の最大行サイズは 65,535 バイトです。ストレージエンジンでは、この制限に追加の制約が課せられ、有効な最大行サイズが減少する場合があります。すべての列の合計長がこのサイズを超えることはできないため、最大行サイズによって列の数 (および場合によってはサイズ) が制限されます。 Oracle Oracle では、物理テーブルごとに最大 1000 列がサポートされます。これについては、Oracleのドキュメントを参照してください。 https://docs.oracle.com/cd/B28359_01/server.111/b28320/limits003.htm#i288032 テーブルの作成時/列の追加時のデザインの検討 設計段階でデータの正規化を確認して空白を減らし、データが効率的に整理されるようにすることをお勧めします。 データベースの正規化については、ServiceNowのプロセスではなく、外部の記事が多数あります。例えば: https://en.wikipedia.org/wiki/Database_normalization 悪いデザインと見なされるものの単純な例を見つけてください。 テーブル:u_research column_nameタイプ最大長u_finding_1文字列40u_finding_2文字列40.........u_finding_9文字列40 この例では、u_finding という名前の 9 つのフィールドとそれに続くプリフィックス 1-9 を持つテーブルがあります。 9 つのフィールドのうち 2 つしか入力されていないレコードが挿入された場合、7 つのフィールドは入力されないままになります。これらの 7 つのフィールドは、ホワイトスペースと見なされるものです。 この問題を解決するには、u_researchテーブルを参照するすべての検出結果を格納する別のテーブルを作成します。 テーブル:u_finding column_nameタイプ最大長u_findingの詳細文字列40u_research参照32 すべての検出結果はテーブルu_findingで作成され、元のテーブルu_reserachにリンクされます。これにより、u_researchレコードに複数の検出結果が含まれる可能性があります。この方法では空白がなくなります 計算フィールドを使用しています。このフィールドにソートを適用するときに順序が正しくないのはなぜですか? 計算フィールドを使用すると、リストビューからデータにアクセスすると、データがリアルタイムで返されます。フィールドでソートする場合、ソートはデータベースに保存されている値に基づいて適用されます。 データベースに保存される値は、レコードが最後に保存された時点の値であり、リアルタイムデータとは異なる場合があります。 このフィールドを本当にソートする必要がある場合は、計算オプションを削除し、関連レコードが更新されたときにフィールドが更新されるようにビジネスルールを作成することを検討する必要があります。 「テーブルあたりの最大列数に達しました」というエラーが表示されました。 システムがテーブルごとに設定できるのは最大で 1000 列です。このエラーが発生した場合は、この制限に達したことが原因です。 1000 列が指定された制限であると定義されていますが、これはテーブル内に物理的に 1000 列を含めることができるという意味ではないことに注意してください。「物理テーブル内に格納できる列数」を参照してください。