About Designing Book Structures
To set up an efficient book structure, you must plan your book hierarchies carefully. Consider the following guidelines when you design and refine the book hierarchies for your company:
The disadvantage of creating custom books that replicate user books is that the data in the custom books and in the default user books must be synchronized. This additional task increases server-processing time, and affects the speed at which records are retrieved.
NOTE: One reason why a company might consider replicating user books is to give a user temporary access to another user’s data. A better way of meeting this need is to add the user who wants to access the data as a delegate for the user who owns the data.
Data Access Needs
Your book structure does not have to reflect your company’s corporate hierarchy. Instead, it is recommended that your book structure should closely reflect how your company organizes its data. Parts of your business can be organized by geography, while other parts can be organized by product line or industry. Pay special attention to cases where:
Relevance of Corporate Structure
In many companies, a parent organization has complete access to all data in the child organizations. Members of such a parent organization typically have global access to data across all child organizations.
If your organization is structured in this way, it is recommended that you do not to set up books that reflect organizational structure at the parent organization level. However, consider the following:
Examine the procedures that your company follows when a user transfers from one department to another. For example:
User Needs and Tasks
When designing your book structure, consider the task where users most commonly use books, including working through lists, searching for records, and creating and using reports.
Working Through Lists
To help you to identify the lists that users need, determine the types of lists that are most frequently used, and the ideal lists for your users. Ask the users in your company for input to help you to do this. If no book in your book structure contains all the necessary records for an ideal list, the book structure is probably missing a hierarchy. For example, you can set up both a geographic hierarchy and a product-oriented hierarchy.
If users spend a lot of time working in a specific subset of one book, create a subbook for the subset. Name the subbook in a way that allows users to recognize it. The subbook can also be set as the default for the Book selector, so that users do not have to select the appropriate book every time. For more information about setting the default for the Book selector, see Enabling Books for Users and User Roles.
Searching for Records
To determine the search needs of the users in your company, ask the users about scenarios where they look up particular records. Your book structure and book sizes should reflect the searches and search criteria that users perform most frequently.
NOTE: If you already have a book structure in place, and are further refining it, ask users if they can typically identify that a particular record is part of a particular book in the hierarchy. If the users consistently say that they can be certain only about a book at a higher level, ask them if another subdivision of the book structure would allow them to narrow their search further. Users should be forced to search higher-level books only as an exception to their normal searches.
The fields that are used in a search also affect the speed of the search:
For example, if you determine that users typically search contact records based on indexed fields, the number of records for the lowest-level book (called the leaf-node book) might be up to 100,000 for each record type. However, if users typically search contact records based on nonindexed fields, you can restrict the size of your leaf-node books to between 20,000 and 30,000 records for each record type.
Data configuration varies from company to company. As a result, there is no recommended number of records for books. You must manage book size continuously. Books facilitate faster searches by reducing the number of records that are searched.
Creating and Using Reports
All users except administrators are subject to data-visibility rules for reports. When a user book or custom book is specified in the Book selector for reporting, the data considered for the reports is as follows:
NOTE: Although you do not typically need to change your book structure after you set it up, you can do so. No downtime is required to make such changes, and the changes are applied immediately. However, the changes are not immediately reflected in the data in real-time reports.
For more information about visibility to records in reports, see Reports.
When you are designing your book hierarchies, base your designs on the following principles:
Book hierarchies that have large numbers of levels, with records at every level, behave in a similar way to the team functionality where manager visibility is enabled. Such hierarchies perform well with small data sets. However, as data volumes grow, books with fewer levels in the hierarchy (or with no hierarchy levels) perform far better than team functionality.
If one level of your book hierarchy provides no additional value to data security or data organization, merge the redundant book and its subbooks. Ask book users if they can typically identify whether a record is in one subbook or another subbook of the same parent book; if they cannot, it indicates that the best option is to collapse the two subbooks into the parent book.
A simple method of reducing the number of levels in a book hierarchy is to prefix subbooks with the name of the parent book. For example, if you have a subbook called North with a parent book called North America, remove the parent book, and rename the subbook as NA – North.
Cross-listing is the practice of duplicating records across multiple books. Cross-listing has an administrative overhead for users, because synchronization is required, resulting in many read-write operations that affect the server's performance. Keep cross-listing to a minimum.
Automated Book Management
Typically, book assignment criteria are mapped to one or more fields in a record type. You can create workflow rules to automatically reorganize the book assignment when one of those fields changes.
For example, if you have a book hierarchy called Territory, you can create a workflow rule to monitor a field in a record type (for example, the Territory field on accounts), and then create an Assign a Book action on the rule to update the Territory book on the record with a new book when the Territory field value on the account changes.
|Published 5/4/2012||Copyright © 2005, 2012, Oracle. All rights reserved. Legal Notices.|