As with installing the SQL Server or Oracle software, you should spend some time learning the purpose of a SQL database before you create the database itself. You should take a two-step approach for any new databases you create. First, understand the purpose of the database, and then create the database with the appropriate parameters. Consider what the database will be used for and how much data it will contain. You should understand the underlying hardware that you'll use—the number and type of CPUs, the amount of memory, the number of disks, the controllers for the disks, and so on. Because the database is stored on the disks, many tuning problems can be avoided with proper capacity and I/O subsystem planning.
Planning your database and the supporting hardware requires insights into the scale or size of the workload and the type of work the system will perform. Some of the considerations that will affect your database design and hardware configuration include the following:

Financial Reporting Subdimensions (FRS) is used to sub-divide the codes for an analysis dimension into meaningful parts. This is only possible if different sections of the analysis codes have different meanings. For example, the 2nd and 3rd characters of a 5 character product code might identify the product type.
Subdimensions can be used by the Financials report writers to refine the codes used to select transactions for reporting. Using the product code example above, you could create a subdimension to identify the product type portion of the code and use this to restrict the transactions selected for a report to those for a particular product type.
A subdimension code uses a mask character, an '*' asterisk, to identify the positions of the code that are to be ignored. It leaves the important characters in the code blank.
You can define several subdimensions for a dimension, for example where different parts of the code are to be used to extract details for different reporting requirements.

• extract and display selected transactions to provide inquiries, for example Account Inquiry.
• extract selected transactions and pass them to a printing function, for example to produce account statements, picking lists, sales invoice, or dispatch notes.
• select journals for import from the Ledger Import tables.
• send selected transactions to account allocation for matching or split
• send selected transactions to a payment function

• present the results of the inquiry in a summarized format, depending on the summary details defined on the filter. These can then be expanded through a set number of levels down to the most detailed level.
• resequence the results.
• carry out further visual selection before launching an associated function.
• drill to further data associated to the current data on display using drills defined in Drill Association Designer.
• print the extracted transaction.

A number of useful codes may have already been defined in your SunSystems implementation, if you are using the facilities that require this information. For example, if you are using Order Fulfilment you will have identified all of your inventory items, warehouses and product groups. If so, you can use them as the valid analysis codes for an analysis dimension. Or another example can be a multi -site  customer, where a few customer records from CUS  share the same debtor account in chart of  accounts. The only option available  to  segregate the customer transactions from one another is to use one of the ledger analysis dimensions. Using linkage between existing codes and  analysis dimension Every time you create a new customer  in CUS it will be automatically created as a ledger analysis code.