Universe design:

----------------
guidelines & best practices introduction gives the basic guidelines/practices t
hat could be followed in any universe design connection --> when using a reposit
ory, always define a secured connection to the database. --> use the universe pr
operty panel to define the universe use and version (last update). --> define th
e connection name that helps for easy database identification. Class --> define
universe classes / subclasses as per the business logic & naming convetion. -->
avoid auto class generation in the designer. --> give description for the use of
each class/subclass. --> avoid deep level of subclasses as it reduces the navig
ability and usability. Objects --> object to be used in calculation has to be me
asure objects. --> object to be used in analysis has to be dimension objects. --
> give description for the use of each object. --> include an eg. In the descrip
tion for objects used in lov. --> do not set lov option for each dimension. Use
it only for required objects, esp. Those to be used in report prompts. --> keep
"automatic refresh before use" option clicked for lov objects: --> if lov is edi
table by the user, provide a significant name to list name under object properti
es. --> all the measure objects should use aggregate functions. --> avoid having
dupicate object names (in different classes). Predefined conditions --> give de
scription for the use of each pre-defined condition. --> if condition is resulti
ng in a prompt, make sure associated dimension object has lov. Tables --> alias
tables should be named with proper functional use. --> arrange the tables in the
structure as per business/functional logic. This helps other universe users in
understanding. Joins & context --> avoid keeping hanging (not joined) tables in
the structure. --> avoid having joins that are not part of any context. --> give
proper functional naming to the context for easy identification. --> avoid havi
ng 1:1 joins. Import/export --> make sure of the path for import, which usually
is always in the business objects' universe folder. --> lock the universe if adm
inistrator/designer does not want any user to import/export. --> do "integrity c
heck" before exporting the universe. --> good to have correct folder structure ,
so that you can have a secured environment. Migration --> better take a backup
of the repository and then proceed with the migration in bo5.x and bo6.x version
report design: guidelines & best practices introduction gives the basic guideli
nes/practices that could be followed in any report design. General --> give mean
ingful names for the report tabs --> for complex reports, keep an overview repor
t tab explaining the report --> use the report properties to give more informati
on about the report dataproviders --> each dataprovider should be given a name t
hat reflects the usage of the data its going to fetch. --> select objects in suc
h a fashion that the resulting sql gives a hierarchial order of tables. This hel
ps to achieve sql optimisation. --> avoid bringing lot of data into the report w
hich will unnecessarily slow down the report performance. Report variables --> f
ollow the naming convention of "var_" as prefix to each report level variable. T
his helps to identify report variables different from universe objects. --> each
variable that carries a calculation involving division should have if <denomina
tor> <> 0 then <object>. This avoids display of #div/0 errors in the report. -->
avoid having deep nested calculations which will slow down the performance of t
he report. Report structure --> make use of report templates when having most of
the report with similar structures. This makes the work to move faster and cons
istant across. Report formats --> all the reports should have page layout set in
a printable manner. (landscape/portrait, fit in 1 page wide or/and 1 page tall
are different options). --> all the reports should have page numbers in the foot
er. --> all the reports should have last refreshed timestamp in the header or fo
oter. --> all the above can be standardized by using templates report cell forma
ts --> all numeric should be given number format as per the language eg. For ger
man #.##00 for english #,##00. --> number cells should have a right alignment wh
ile text cells should have left alignment. --> cell showing percentage should ca
rry the % text (either column header or in each cell). --> indenting should alwa
ys be done using the indenting tool and not by using " ".