![]() |
|
ブック構造の設計について効率的なブック構造をセットアップするには、ブック階層を慎重に計画する必要があります。会社のブック階層を設計および編集する際には、次の点に注意してください。
ユーザーブックユーザーブックを複製するカスタムブックを作成することで生じる欠点は、カスタムブック内のデータとデフォルトユーザーブック内のデータを同期化しなければならないということです。この余分なタスクにより、サーバー処理時間が増え、レコード取得速度に影響が出ます。 注:企業がユーザーブックの複製を検討する理由の1つとして、ユーザーに、別のユーザーのデータへの一時的なアクセスを許可する場合があります。このニーズを満たすためのより適した方法として、別のユーザーのデータにアクセスする必要があるユーザーを、そのデータを所有しているユーザーの委任ユーザーとして追加するという方法があります。 データアクセスのニーズブック構造に、企業の社内階層を反映させる必要はありません。その代わり、ブック構造には、社内でのデータの管理方法を反映することをお勧めします。社内業務は、地域別に管理できるものもあれば、製品ラインまたは業種別に管理できるものもあります。次の場合については、特に注意が必要です。
社内構造の関連性多くの企業において、親組織は、子組織の全データに対して完全なアクセス権を持っています。このような親組織のメンバーは、通常、すべての子組織のデータに対してグローバルなアクセス権を持ちます。 このような構造の企業の場合、親組織レベルの組織構造を反映するブックのセットアップは行うことはお勧めしません。ただし、次の状況が考えられます。
データの関連付けユーザーが部署を移動するときの手順について検討します。次に例を示します。
ユーザーのニーズとタスクブック構造を設計する際には、ユーザーが頻繁にブックを使用するタスクについて検討します。たとえば、リストからの作業、レコードの検索、レポートの作成や使用などです。 リストの使用ユーザーが必要とするリストを識別するために、頻繁に使用されるリストのタイプと、ユーザーにとって理想的なリストを判断します。このためには、社内ユーザーに入力を依頼します。ブック構造内に、理想的なリストに必要なすべてのレコードが含まれるブックがない場合、そのブック構造に階層がない可能性があります。たとえば、地域別階層と製品別階層の両方をセットアップすることができます。 1つのブックの特定のサブセット内で長時間作業する場合、そのサブセット用のサブブックを作成します。そのサブブックには、ユーザーが識別可能な名前を付けます。また、ユーザーが毎回適切なブックを選択する必要がないように、サブブックを[ブック]セレクタのデフォルトとして設定することもできます。[ブック]セレクタのデフォルトの設定方法については、「ユーザーおよびユーザー役割に対するブックの有効化」を参照してください。 レコードの検索社内ユーザーの検索ニーズを判断するために、ユーザーに特定のレコードを検索するシナリオについて尋ねます。ブック構造とブックサイズは、ユーザーが頻繁に実行する検索と検索基準を反映する必要があります。 注:既にブック構造が配置されており、それを編集している場合は、特定のレコードがその階層内の特定のブックに存在していることを確認できるかどうかをユーザーに尋ねてください。ユーザーが一様に、より高いレベルのブックしか確認できないと答える場合には、そのブック構造に別のサブセットがあれば、この検索範囲を絞ることができるかどうか確認してください。高いレベルのブックの検索は、通常の検索の例外としてのみ行うようにしてください。 検索で使用されるフィールドも、検索速度に影響します。
たとえば、ユーザーがインデックス付きフィールドを使用して担当者レコードを検索する場合は、最下位レベルのブック(リーフノードブックと呼ばれます)のレコード数は、各レコードタイプにつき最大100,000です。ただし、ユーザーがインデックスの付いていないフィールドを使用して担当者レコードを検索する場合は、リーフノードブックのサイズをレコード数20,000から30,000におさえることができます。 データ構成は会社によって異なります。ブックのレコード数について推奨値はありません。ブックのサイズは継続して管理することが必要です。ブックを使用すると検索するレコード数を減らすことができ、検索速度が上がります。 レポートの作成と使用管理者以外のユーザーは全員、レポート用のデータ表示ルールに従います。ユーザーブックまたはカスタムブックがレポートの[ブック]セレクタで指定された場合、レポート対象とみなされるデータは次のとおりです。
注:通常、ブック構造はセットアップ後に変更する必要はありませんが、変更することもできます。このような変更を行う場合、ダウンタイムは必要なく、変更もすぐに適用されます。ただし、この変更は、リアルタイプレポート内のデータにはすぐに反映されません。 レポート内のレコードの表示の詳細は、「分析のレコードの表示について」を参照してください。 マネージャ表示ブック階層を設計する際には、次の原則に基づいてください。
階層レベルすべてのレベルにレコードがあり、レベル数が多いブック階層は、管理者表示が有効になっているチーム機能と似た動作になります。このような階層では、データセットが小さいとパフォーマンスが向上します。データ量が大きくなるにつれて、階層内のレベル数が少ない方が(または、階層レベルがない方が)チーム機能よりはるかにパフォーマンスが良くなります。 ブック階層内のあるレベルが、データセキュリティまたはデータ組織にとって付加価値のないものである場合には、冗長ブックとそのサブブックをマージしてください。あるレコードが、同じ親ブック内の2つのサブブックのうちどちらに含まれているのかを識別できるかどうか、ブックユーザーに尋ねてください。識別できない場合には、その2つのサブブックを親ブックに折りたたむのが最適な方法です。 ブック階層内のレベル数を減らす簡単な方法は、サブブックに親ブック名を接頭辞として付けるという方法です。たとえば、North Americaという名前の親ブックを持つNorthという名前のサブブックがある場合、親ブックを削除して、サブブックの名前をNA – Northにします。 クロスリストクロスリストとは、複数のブック間でレコードを複製することです。クロスリストは同期化が必要で、その結果サーバーのパフォーマンスに影響する読み書き処理が増大するため、ユーザーが管理するための諸経費がかかります。クロスリストの使用は最小限にしてください。 ブックの管理の自動化通常、ブック割当基準はレコードタイプの1つ以上のフィールドにマップされます。これらのフィールドのうち1つが変わると、ブック割当を自動的に認識するワークフロールールを作成できます。 たとえば、Territoryというブック階層があった場合、あるレコードタイプ内のあるフィールド(たとえば、取引先のTerritoryフィールド)を監視するワークフロールールを作成し、次に、取引先のTerritoryフィールド値が変わると、そのレコードのTerritoryブックを新しいブックに更新するブック割当アクションをルールに設定することができます。 ブック名を設計する際には、ブック名を解決する式に基づいて単一のワークフローアクションで異なるブックを異なるレコードに割り当てることができるような方法で[ブックを割り当て]ワークフローアクションを使用する必要があるかどうかを検討します。 たとえば、北アメリカに取引先があり、EMEAに拠点を置く取引先もあるとします。それらの異なる所在地のために2つの別個のブックを設定し、取引先所在地に応じて適切なブックを取引先に割り当てる必要があります。この構成を設定するには、2つのブックを作成し、一方を「North America」、他方を「EMEA」という名前にします。次に、「Sales Location」という名前の、値が「North America」および「EMEA」であるカスタムピックリスト項目を作成し、そのカスタム項目を適切な役割の[取引先]レコードタイプのページレイアウトに追加します。その後、取引先レコードの更新時に以下のことが実行される、[ブックを割り当て]ワークフローアクションを作成します。
関連トピック関連情報については、次のトピックを参照してください。 |
公開日 2018 年 8 月 | Copyright © 2005, 2018, Oracle. All rights reserved. Legal Notices. |