How will u know that a dimension can b a lineitem Dim b4 loading into Cube

Question

Hi, Im new to this. My qury is how will u know that a dim will b a LineItem dimension bfore loading in to cube , are there anystandard to b followed. Ca u give me some realtime detailed scenarious.

Answer 1

Hi,
     When compared to a fact table, dimensions ideally have a small cardinality. However, there is an exception to this rule. For example, there are InfoCubes in which a characteristic Document is used, in which case almost every entry in the fact table is assigned to a different Document. This means that the dimension (or the associated dimension table) has almost as many entries as the fact table itself. We refer here to a degenerated dimension.
Generally, relational and multi-dimensional database systems have problems to efficiently process such dimensions. You can use the indicators line item and high cardinality to execute the following optimizations:
      1.      Line item: This means the dimension contains precisely one characteristic. This means that the system does not create a dimension table. Instead, the SID table of the characteristic takes on the role of dimension table. Removing the dimension table has the following advantages:
       When loading transaction data, no IDs are generated for the entries in the dimension table. This number range operation can compromise performance precisely in the case where a degenerated dimension is involved.
      A table- having a very large cardinality- is removed from the star schema. as a result, the SQL-based queries are simpler. In many cases, the database optimizer can choose better execution plans.
Nevertheless, it also has a disadvantage: A dimension marked as a line item cannot subsequently include additional characteristics. This is only possible with normal dimensions.
We recommend that you use DataStore objects, where possible, instead of InfoCubes for line items. See Creating DataStore Objects.
       2.      High cardinality: This means that the dimension is to have a large number of instances (that is, a high cardinality). This information is used to carry out optimizations on a physical level in depending on the database platform. Different index types are used than is normally the case. A general rule is that a dimension has a high cardinality when the number of dimension entries is at least 20% of the fact table entries. If you are unsure, do not select a dimension having high cardinality.
Activities
When creating dimensions in the InfoCube maintenance, flag the relevant dimension as a Line Item/ having High Cardinality.
Define lots of small dimensions rather than a few large dimensions.
     The size of the dimension tables should account for less than 10% of the fact table.
     If the size of the dimension table amounts to more than 10% of the fact table, mark the dimension as a line item dimension.
To attain good performance for a query on non-cumulative InfoCubes, you should take note of the following:
Compression:
Compress all requests in the non-cumulative InfoCube, or at least most of them.
The performance of a query based on a non-cumulative InfoCube depends heavily on how the InfoCube is compressed. If you want to improve the performance of a query of this type, first check – in so far as this is possible - whether the data in the InfoCube should be compressed. You should always compress data when you are sure that the request affected will not need to be deleted from the InfoCube.
Validity Table
Use as few validity-determining characteristics as possible.
The number and cardinality of the validity-determining characteristics heavily influences performance. Therefore, you should only define characteristics as validity-determining characteristics when it is really necessary.
Time Restrictions in the Query
As far as possible, restrict queries based on non-cumulative InfoCubes to time characteristics.
The stricter the time-based restriction, the faster the query is generally executed, as the non-cumulative is reconstructed if the number of times is smaller.
Time Drilldown in the Query
If you no longer need the average, split a query on a non-cumulative InfoCube (which contains both key figures with LAST aggregation and key figures with AVERAGE aggregation) into two queries.
With non-cumulative key figures with the exception aggregation LAST, the time characteristic included in the drilldown makes a difference to performance. If, for example, both Calendar Day and Calendar Month are included in the InfoCube, drilldown by month is faster than drilldown by day, because the number of times for which a non-cumulative has to be calculated is smaller.
For the other types of exception aggregation (average, average weighted with factory calendar, minimum and maximum), this rule is not valid as in these cases, the data is always calculated on the level of the most detailed time characteristic first before exception aggregation is performed.
Totals Rows
Hide the totals row in the query when not required.
Depending on the type of aggregation being used, the calculation of totals rows can be very time-consuming.
When selecting MDC dimensions, proceed as follows:
        Select dimensions for which you often use restrictions in queries.
        Select dimensions with a low cardinality.
The MDC dimension is created in the column with the dimension keys (DIMID). The number of different combinations in the dimension characteristics determines the cardinality. Therefore, select a dimension with either one, or few characteristics and with only a few different characteristic values.
Line item dimensions are not usually suitable, as they normally have a characteristic with a high cardinality.
If you specifically want to create an MDC dimension for a characteristic with a low cardinality, you can define this characteristic as a line item dimension in the InfoCube. This differs from the norm that line item dimensions contain characteristics with a very high cardinality. However, this has the advantage for multidimensional clustering that the fact table contains the SID values of the characteristic, in place of the dimension keys, and the database query can be restricted to these SID values.
        You cannot select more than three dimensions, including the time dimension.
        Assign sequence numbers, using the following criteria:
        Sort the dimensions according to how often they occur in queries (assign the lowest sequence number to the InfoObject that occurs most often in queries).
        Sort the dimensions according to selectivity (assign the lowest sequence number to the dimension with the most different data records).
Note: At least one block is created for each value combination in the MDC dimension. This memory area is reserved independently of the number of data records that have the same value combination in the MDC dimension. If there is not a sufficient number of data records with the same value combinations to completely fill a block, the free memory remains unused. This is so that data records with a different value combination in the MDC dimension cannot be written to the block.
If for each combination that exists in the InfoCube, only a few data records exist in the selected MDC dimension, most blocks have unused free memory. This means that the fact tables use an unnecessarily large amount of memory space. Performance of table queries also deteriorates, as many pages with not much information must be read.
Example
The size of a block depends on the PAGESIZE and the EXTENTSIZE of the tablespace. The standard PAGESIZE of the fact-table tablespace with the assigned data class DFACT is 16K. Up to Release SAP BW 3.5, the default EXTENTSIZE value was 16. As of Release SAP NetWeaver 2004s the new default EXTENTSIZE value is 2.
With an EXTENTSIZE of 2 and a PAGESIZE of 16K the memory area is calculated as 2 x 16K = 32K, this is reserved for each block.
The width of a data record depends on the number of dimensions and the number of key figures in the InfoCube. A dimension key field uses 4 bytes and a decimal key figure uses 9 bytes. If, for example an InfoCube has 3 standard dimensions, 7 customer dimensions and 30 decimal key figures, a data record needs 10 x 4 bytes + 30 x 9 bytes = 310 bytes. In a 32K block, 32768 bytes / 310 bytes could write 105 data records.
If the time characteristic calendar month (0CALMONTH) and a customer dimension are selected as the MDC dimension for this InfoCube, at least 100 data records should exist for each InfoPackage, for each calendar month and for each dimension key of the customer dimension. This allows optimal use of the memory space in the F fact table. In the E fact table, this is valid for each calendar month and each dimension key of the customer dimension,dimension contains a characteristic whose value already uniquely determines the values of all other characteristics from a business-orientated viewpoint, then the dimension is named after this characteristic.
  The customer dimension could, for example, be made up of the customer number, the customer group and the levels of the customer hierarchy.
The sales dimension could contain the characteristics ‘sales person’, ‘sales group’ and ‘sales office’.                                            
The time dimension could be given using the characteristics ‘day’ (in the form YYYYMMDD), ‘week’ (in the form YYYY.WW), ‘month’ (in the form YYYY.MM), ‘year’ (in the form YYYY) and ‘period’ (in the form YYYY.PPP).
Use
When defining an InfoCube, characteristics for dimensions are grouped together to enable them to be stored in a star schema table (dimension table). The aforementioned business-orientated grouping can be the basis for this. With the aid of a simple foreign key dependency, dimensions are linked to one of the key fields of the fact table.
When you create an InfoCube, the dimensions data package, time and unit are already defined by default. The data package dimension contains technical characteristics. Time characteristics and units are automatically assigned to the corresponding dimensions. When you activate the InfoCube, only those dimensions that contain InfoObjects are activated.
From a technical viewpoint several characteristic values are mapped to an abstract dimension key (DIM ID), to which the values in the fact table refer. The characteristics chosen for an InfoCube are divided up among InfoCube-specific dimensions when creating the InfoCube.
Also refer to the following for specific cases arising when defining dimensions:
Line Item and High Cardinality
The methods for setting and getting data from a named range use the separation between the description of the range and the data itself. Note that the sequence must be observed both in the range description (structure soi_range_list ) and in the data (structure soi_generic_table ). This means that you must list all data from the first range before you can insert data into the second range.
Structure soi_range_list
Field
Type
Description
name
C
Name of the range
rows
C
Number of rows
columns
C
Number of columns
code
C
Function in the range:
SPREADSHEET->SPREADSHEET_CLEAR : Deletes range
SPREADSHEET->SPREADSHEET_COLUMNSHIDE : Hides columns
SPREADSHEET->SPREADSHEET_ROWSHIDE : Hides rows
SPREADSHEET->SPREADSHEET_PROTECT : Range is protected
SPREADSHEET->SPREADSHEET_UNPROTECT : Range is not protected
SPREADSHEET->SPREADSHEET_COLUMNSSHOW : Columns are displayed.
SPREADSHEET->SPREADSHEET_ROWSSHOW : Rows are displayed.
SPREADSHEET->SPREADSHEET_INSERTALL : The entire table is inserted, regardless of the size of the area
SPREADSHEET->SPREADSHEET_NEWRANGE : Creates a new range
The name identifies the range in the worksheet. This is, in effect, the key with which you always access the range. The size of the range is always given in columns and rows.
Some functions allow you to access a specific area in a worksheet. You can see from the table which functions are implemented.
Description of Data Type soi_generic_table
In this table, you can save data from the range and use the  Data Provider to transfer it to or retrieve it from the frontend. The data is transferred directly as a string with no type information.
Structure soi_generic_table
Field
Type
Description
row
C(4)
Row
column
C(4)
Column
value
C(256)
Value
The sequence of the data must correspond to the sequence of the range description, for example, range1 before range2 . The data table must then contain the data for the ranges in the sequence range1 range2 .
Description of Data Type soi_format_table
Use this table to specify the format of a range. The format consists of various attributes, all of which can be set in a single line. Each variable attribute corresponds to a column of the structure.
To create a work area for this table, use the structure soi_format_item as a reference.
The entry "-1" always indicates that the existing attribute value for the range should not be changed.
Structure soi_format_table
Field
Type
Description
name
C(256)
Name of the range
front
I
Font color (see color palette)
back
I
Background color (see color palette)
font
C(256)
Name of the font family. The following values are permitted:
'Arial'
'Courier New'
'Times New Roman'
size
I
Font size
'-1' : Unchanged
bold
I
'1' : Bold
'0' : Normal
'-1' : Unchanged
italic
I
'1' : Italic
'0' : Normal
'-1' : Unchanged
align
I
Alignment:
'-1' : Unchanged
'0' : Right-justified
'1' : Centered
'2' : Left-justified
frametype
I
Control byte for setting the frame
'-1' : Unchanged
framecolor
I
Frame color (see color palette)
'-1' : Unchanged
currency
C(3)
ISO standard currency code
number
I
Specifies the format of a cell in a range.
1: Display as a simple number
2: Scientific display
3: Display as a percentage
The control byte type contains the following bits. If a bit is set, its corresponding line is drawn. You can set the thickness of the line to one of four levels using bits 6 and 7.
Bit
Description
0
Sets the left margin
1
Sets the top margin
2
Sets the bottom margin
3
Sets the right margin
4
Horizontal line
5
Sets the left margin
6
Thickness
7
Thickness
Description of Data Type soi_full_range_table
Each line of a table with the type soi_full_range_table specifies the full definition of a range. The individual lines have the data type soi_full_range_item .
Structure soi_full_range_table
Field
Type
Description
name
C(128)
Name of the range
top
I
Top row of the range
left
I
Leftmost column of the range
rows
I
Number of rows in the range
columns
I
Number of columns in the range
sheets
C(128)
Worksheet on which the range is defined
Description of Data Type soi_cell_table
Each line of a table with the type soi_cell_table specifies the attributes of a range of cells. However, no range name is used. Instead, the cell area is defined by its starting position and the number of rows and columns it contains.The individual lines have the data type soi_cell_item .
Structure soi_cell_table
Field
Type
Description
top
I
Top row of the range
left
I
Leftmost column of the range
rows
I
Number of rows in the range
columns
I
Number of columns in the range
front
I
Font color (see color palette)
back
I
Background color (see color palette)
font
C(256)
Font. The following are permitted:
Arial
Courier New
Times Roman
size
I
Font size
Use -1 if the font size is to remain unchanged.
bold
I
'1' : Bold
'0' : Normal
'-1' : Unchanged
italic
I
'1' : Italic
'0' : Normal
'-1' : Unchanged
align
I
Alignment:
'-1' : Unchanged
'0' : Right-justified
'1' : Centered
'2' : Left-justified
frametype
I
Control byte for setting the frame
'-1' : Unchanged
framecolor
I
Frame color (see color palette)
'-1' : Unchanged
currency
C(3)
ISO standard currency code
number
I
Specifies the format of a cell in a range.
1: Display as a simple number
2: Scientific display
3: Display as a percentage
decimals
I
Number of decimal places
input
I
'0' : Input off
'1' : Input on
Description of Data Type soi_dimension_table
You can use an internal table with this type to identify a range by specifying the coordinates of its top left-hand corner, its length, and its width. The lines of soi_dimension_table have the line type soi_dimension_item .
Structure soi_dimension_item
Field
Type
Decription
top
I
Topmost row of the range
left
I
Leftmost column of the range
rows
I
Number of rows
columns
I
Number of columns
Term
Definition
Board
A tabbed area in the workspace used to manipulate the model and its elements: Design board, Layout board and Source board.
Characteristic
A type of InfoObject in SAP BI systems that provides a classification such as company code, product, customer group, fiscal year, period, or region. Related to the OLAP-standard term dimension.
Component
A reusable model element, such as a UI component or a data service.
Cube
A set of data organized as a multidimensional structure defined according to dimensions and measures.
Related SAP BI terms include InfoCube and query.
Data binding
A connection between two UI components (or between a web service and a UI component) that channels identical data from the output port of one UI component to the input port of the other UI component.
Data flow
The means by which data is channeled between a data service and connected UI components, or between two UI components whose connection was changed from Data binding to Data flow.
Data mapping
Connection between two model elements, describing, for example, the data that is input to an element or the fields that are output from another element.
Data service
Any function call, business object or query imported into the model. At runtime, the data service is called and returns results.
Data store
A central data container where data of a model can be temporarily stored for future use.
Dimension
In OLAP-standard systems:
A collection of similar data which, together with other such collections, forms the structure of a cube. Typical dimensions include time, product, and geography. Each dimension may be organized into a basic parent-child hierarchy or, if supported by the data source, a hierarchy of levels.  For example, a geography dimension might include levels for continent, country, state, and city.
The related term in SAP BI systems is characteristic.
In SAP BI systems:
A grouping of those evaluation groups (characteristics) that belong together under a common superordinate term.
With the definition of an InfoCube, characteristics are grouped together into dimensions in order to store them in a star schema table (dimension table).
Element
A general term indicating any item used to create a model, including: components, connectors and operators.
Enterprise service
A Web service defined to perform functions of an SAP system. Web services are published to and stored within a repository.
Field
An element of a table that contains a single piece of data. Fields are organized into rows, which contain all the data relevant for one specific entry in the table.  In some databases, field is a synonym for column.
Filter
A set of criteria that restricts the set of records returned as the result of a query. With filters, you define which subset of data appears in the result set.
Hierarchy
A logical tree structure that organizes the members of a dimension into a parent-child relationship. If supported by the data source, the hierarchy consists of levels, where the top level is an aggregate of all members and each subsequent level has zero or more child members.
InfoArea
An element for grouping meta-objects in the Business Information Warehouse. Each InfoProvider is assigned to an InfoArea. The resulting hierarchy is displayed in the Administrator Workbench.
InfoCube
An SAP BI system that consists of a quantity of relational tables created according to the star schema: a large fact table in the center, with several dimension tables surrounding it. It provides a self-contained dataset which can be used for analysis and reporting.
Similar to the OLAP-standard term cube.
InfoObject
A business evaluation object (for example, customer or quantity) in SAP BI systems. Types of InfoObjects include characteristics, key figures, units, time characteristics, and technical characteristics (such as request numbers).
JDBC
Java Database Connectivity, which provides an API that lets you access relational databases using the Java programming language. This enables connectivity to a wide range of SQL databases, and also provides access to tabular data sources such as spreadsheets or flat files. The BI JDBC Connector accesses data from JDBC-compliant systems.
Join
A relationship between two tables that produces a result set that combines their contents. You create a join by indicating how selected fields in one table are related to selected fields in the other table.
Key figure
A value or quantity in SAP BI systems. Related to the OLAP-standard term measure. You may also define calculated key figures, which are derived using a formula.
Layer
A collection of UI elements that are all visible at the same time at runtime.
Level
A set of nodes (members) in a tree hierarchy in supporting data sources that are at the same distance from the root of the tree. For example, in a geography hierarchy, the top level might be all places, the second level might be continents, the third level might be countries, and the fourth level might be cities.
MDX
Multidimensional Expressions, a query language used to retrieve and manipulate multidimensional data.
Measure
One category of values – usually numeric – used to define a cube. These values are derived from one or more columns in the cube's fact table and are the basis for aggregation and analysis.
Related SAP BI terms include key figure and structure element.
Member
An element of a dimension that represents one or more occurrences of data. A member can be unique (it occurs only once) or non-unique (it may occur more than once in its dimension).  For example, in a geography dimension that includes cities in the US, the member Portland could be non-unique, since there is a city called Portland in the state of Oregon and in the state of Maine.
In SAP BI systems, members are referred to as instances of characteristics.
Model
An object created in Storyboard. Models may contain packages, pages, iViews and any other model elements.
Multidimensional data
Data in dimensional models suitable for business analytics. In this documentation, we use the term multidimensional data synonymously with OLAP data.
Navigation line
A connection that provides event annotation, running between model layers. The source element raises the event that can be handled by the connected element. By default, a navigation line is curved.
ODBO
OLE DB for OLAP – Microsoft’s set of objects and interfaces that extend the ability of OLE DB to provide access to multidimensional data sources on the Windows platform. Providers of OLAP data can implement the interfaces described with OLE DB for OLAP to allow all OLAP clients to access their data. The BI ODBO Connector accesses data from ODBO-compliant systems.
OLAP
Online analytical processing – a system of organizing data in a multidimensional model that is suitable for decision support. SAP BI systems are OLAP systems.
Operation
A functionality provided by a Web service.
Operator
A mechanism used to manipulate data returned from the data service before it is displayed in the iView.
Package
A high-level “container”; it can contain any number of pages, iViews or other packages.
Port
A defined point of interface into and out of a component.
Query
In SAP BI systems, a collection of selected characteristics and key figures (InfoObjects) used together to analyze the data of an InfoProvider. A query always refers exactly to one InfoProvider, whereas you can define as many queries as you like for each InfoProvider.
Query view
In SAP BI systems, a view of a query after navigation, saved in an InfoCube. You can use this saved query view as a basis for data analysis and reporting.
Relational database
A repository for typically large amounts of information, structured in accordance with the relational model, in tables with columns. A relational database is created and administered by a relational database management system (RDBMS).
Row
A set of fields within a table that contains the data for one specific entry in the table. Each row in a given table has the same structure, predefined for a particular table. In some databases, row is a synonym for record.
SAP Query
A component that allows you to create custom reports without any ABAP programming knowledge. The BI SAP Query Connector uses SAP Query to access data from such SAP operational applications.
Storyboard
The Visual Composer client from which you design models.
Table
A set of rows, also known as a relation. The table is the central object of the relational model.
Task panel
A work area of the Visual Composer Storyboard desktop that displays a specific set of tools for building a model.
Toolbar
The horizontal row of buttons under the main menu (main toolbar) or the vertical row of buttons in the task panel (task-panel toolbar).
Toolbox
A set of board-specific tools that assist in performing tasks in the Visual Composer workspace.
Value help
The offering, typically in a pop-up dialog box, of possible valid values for an input field. Also known as input help, selection help, or F4 help.
Web service
An interface between two or more software applications that is implemented with the industry standards SOAP, WSDL and UDDI.
Workspace
The main grid area of Visual Composer that displays the model as it is built and modified. The workspace consists of boards.
XMLA
XML for Analysis, an XML-messaging-based protocol specified by Microsoft for exchanging analytical data between client applications and servers (for example, OLAP providers) using HTTP and SOAP as a service on the Web. The BI XMLA Connector accesses data from XMLA-compliant systems.
Clustering allows you to save sorted data records in the fact table of an InfoCube. Data records with the same dimension keys are saved in the same extents (related database storage unit). This means that same data records are not spread across a large memory area and thereby reduces the number of extents that the system has to read when it accesses tables. This greatly accelerates read, write and delete access to the fact table.
Prerequisites
Currently the function is only supported by the database platform DB2 for Linux, UNIX, and Windows. You can use partitioning to improve the performance of other databases. For more information, see Partitioning.
Features
Two types of clustering are available: Index clustering and multidimensional clustering (MDC).
Index Clustering
Index clustering organizes the data records of a fact table according to the sort sequence of an index. Organization is linear and corresponds to the values of the index field.
If a data record cannot be inserted in accordance with the sort sequence because the relevant extent is already full, the data record is inserted into an empty extent at the end of the table. For this reason, the system cannot guarantee that the sort sequence is always correct, particularly if you perform many insert and delete operations. Reorganizing the table restores the sort sequence and frees up memory space that is no longer required.
The clustering index of an F fact table is, by default, the secondary index in the time dimension. The clustering index of an E fact table is, by default, the acting primary index (P index).
As of release SAP BW 2.0, index clustering is standard for all InfoCubes and aggregates.
Multidimensional Clustering (MDC)
Multidimensional clustering organizes the data records of a fact table in accordance with one or more fields that you define freely. The selected fields are also marked as MDC dimensions. Only data records that have the same values in the MDC dimensions are saved in an extent. In the context of MDC, an extent is called a block. The system can always guarantee that the sort sequence is correct. Reorganizing the table is not necessary, even with many insert and delete operations.
Block indexes from within the database, instead of the default secondary indexes, are created for the selected fields. Block indexes link to extents instead of data record numbers and are therefore much smaller. They save memory space and the system can search through them more quickly. This accelerates table requests that are restricted to these fields.
You can select the key fields of the time dimension or any customer-defined dimensions of an InfoCube as an MDC dimension. You cannot select the key field of the package dimension; it is automatically added to the MDC dimensions in the F fact table.
You can also select a time characteristic instead of the time dimension. In this case, the fact table has an extra field. This contains the SID values of the time characteristic. Currently only the time characteristics Calendar Month (0CALMONTH) and Fiscal Year/Period (0FISCPER) are supported. The time characteristic must be contained in the InfoCube. If you select the Fiscal Year/Period (0FISCPER) characteristic, a constant must be set for the Fiscal Year Variant (0FISCVARNT) characteristic.
Clustering is applied to all the aggregates of the InfoCube. If an aggregate does not contain an MDC dimension of the InfoCube, or if all the InfoObjects of an MDC dimension are created as line item dimensions in the aggregate, the aggregates are clustered using the remaining MDC dimensions. Index clustering is used for the aggregate if the aggregate does not contain any MDC dimensions of the InfoCube, or if it only contains MDC dimensions.
Multidimensional clustering was introduced in Release SAP NetWeaver 2004s and can be set up separately for each InfoCube.
For procedures, see Definition of Clustering.
Screen capture input to SAP Business Graphics must adhere to certain format rules in order to be recognized correctly.
SAP Business Graphics assumes that your screen data resembles the basic SAP table structure. This structure is somewhat flexible, but the table must obey the format rules listed in this section.
Restrictions on the Format of the Data
If you use the screen capture facility to input graphics data, the input table can contain either a single list of values, or rows and columns. If the data is a single list, you can include the values themselves and labels for each value. If the data has rows and columns, you can include a label for each row, a label for each column, and the table values themselves.
You cannot use the screen capture facility to input data in multiple tables. If you want to graph data occurring in multiple tables, you must write the input values to a file using ABAP programming tools. See SAP Graphics: Programming Interfaces for more information.
Format Rules for Numerical Values
Numerical values must obey the following rules:
Within a numerical value, the screen capture recognizes only the minus sign (hyphen), the comma, and the decimal point (period) as legitimate punctuation. Exponential notation and other variations are not recognized.
Note that the functions of the period and the comma in the English system are exactly opposite to their functions in some European systems. If your numbers are not being interpreted correctly, check with the system administrator to determine how these characters should be used.
The minus sign must occur after the number, with no intervening spaces.
All numbers in a row must be separated by spaces.
A column of numbers is right-justified and identified by the position of its right-most character. Each number belonging to this column must have its right-most character in the correct position.
If you have values partially or entirely out of alignment with the given right-most character position, they will not be interpreted as belonging to the proper column. In most cases, the screen capture program assumes these are values for an entirely new column.
You may leave out values for a given row or column.
Format Rules for Text Strings
You can include labels in the table to name the rows and columns. You can also provide a title for the set of rows, for the set of columns, and for the graph as a whole.
SAP Business Graphics does not accept more than 32 elements per dimension. As a result, you cannot have more than 32 rows or 32 columns in your table.
Any string of characters not identifiable as a number is assumed to be a label. Labels may occur at the beginnings of a row, at the head of a column, as a title for the rows or columns, or as the graph main title. A non-numeric item placed in among the data values is ignored by the graphics program.
A legitimate number occurring where a label should be is interpreted as a number. If you want to use labels that look like numbers, you must modify them to contain at least one non-numeric character.
Placement of labels for row-names or column-names:
Row-names can occur only at the beginning (left side) of a row.
Column-names should line up above the columns they are heading, but do not necessarily need to begin in the same column. They should be separated by at least two spaces.
If you don't adhere to these requirements, the screen capture program attempts to pick out the labels anyway. However, the results may not be what you expect. (Check the selection bars in the Selection view to see if your headers were correctly identified.)
Placement of titles for rows or columns as a set:
The title for the rows as a set should be placed directly above the column of row-names.
The title for the columns as a set should occur directly above the first of the column-names, and begin in exactly the same position.
The main title for the graph should occur in the very first line of the highlighted area. If you have more text there than just the title, the screen capture program attempts to pick out the string in the center of the line. The longest string in the center of the line separated from other text by double spaces is assumed to be the title.
The maximum length for a text string cannot be specified exactly since this depends on the size of your window, the resolution of your monitor, and other factors.
Many strings too long for a small window are displayed correctly when you enlarge the window to full-screen size. In general, you must experiment to find the optimal length for text strings.