Business Objects

Designer Desktop Intelligence (Reporting)

Info view/Web Intelligence

CMC

What is Business Objects

Business Objects is an integrated query, reporting and analysis software used as the interface to the Data Warehouse. Business Objects provides integrated query, reporting, and analysis for the enterprise. It is a web enabled, full-client product that allows users to easily track, understand, and manage the wealth of information stored in multiple data sources within and beyond the enterprise.

UNIVERSE DESIGNER Business Objects Designer is a software tool that allows you to create universes for Web Intelligence and Desktop Intelligence users. Universe is a semantic layer between data base and business objects which converts data base tables and columns into classes and objects in BO. Designer provides a graphical interface that allows you to select and view tables in a database. The database tables are represented as table symbols in a schema diagram. You can use this interface to manipulate tables, create joins that link the tables, create alias tables, contexts, and solve loops in your schema.

A schema of the tables and joins used in the database. Objects are built from the database structures that you include in your schema. The schema is only available to Designer users. It is not visible to Web Intelligence and Desktop Intelligence users. Web Intelligence users connect to a universe, and run queries against a database. They can do data analysis and create reports using the objects in a universe, without seeing, or having to know anything about, the underlying data structures in the database.

The role of a universe is to provide an easy to use and understand interface for non technical Web Intelligence users to run queries against a database to create reports and perform data analysis. As the universe designer, you use Designer to create objects that represent database structures, for example columns and database functions, that users need to access and query, to get the information necessary to meet their business requirements. The objects that you create in the universe must be relevant to the end user business environment and vocabulary. Their role is to present a business focussed front end to the SQL structures in the database.

What does a universe contain? Classes Objects

A class is a logical grouping of objects within a universe. It represents a category of objects.

An object is a named component that maps to data or a derivation of data in the database.

In Business Objects, objects are qualified as one of three types: dimension, detail, or measure. Dimension : Parameters for analysis. Dimensions typically relate to a hierarchy such as geography, product, or time. For example Last Name and City_Id Detail : Provide a description of a dimension, but are not the focus for analysis. For example Phone Number

Measure : Convey numeric information which is used to quantify a dimension object. For example Sales Revenue

How do you use Designer to create universes?

Designer provides a connection wizard which allows you to connect to your database middleware. You can create multiple connections with Designer, but only one connection can be defined for each universe. This database connection is saved with the universe. Designer allows you to distribute universes by importing and exporting universes to the Central Management Console (CMC) repository.

What are universe parameters?

Universe parameters are definitions and restrictions that you define for a universe that identify a universe and its database connections, specify the type of queries that can be run using the universe, and set the controls on the use of system resources.
You define universe parameters from the Universe Parameters dialog box (File > Parameters) when you create a universe. The database connection is the only parameter that you must manually select or create when you create a new universe.

Selecting strategies : A strategy is a script that automatically extracts structural information from a database or flat file. Strategies have two principle roles: Automatic join and cardinality detection (Join strategies)

Automatic class, object, and join creation (Objects and Joins strategies)
Strategies can be useful if you want to automate the detection and creation of structures in your universe based on the SQL structures in the database.

What is a connection? A connection is a named set of parameters that defines how a Business Objects application accesses data in a database file. It is the link between Business Objects and your database. You must have a connection between your Business Objects application and your database in order to access your data.

Connection Types :
Personal Connection : A personal connection is used to access resources such as universes or documents. It can be used only by the user who created it. Information about a personal connection is stored in both the PDAC.LSI and PDAC.SSI files. Its definition is static and cannot be modified.

You could use personal connections in the following situations:

To access personal data on local machine To access Specific database accounts to test SQL sample through the Free hand SQL option in BO.

Shared Connection :

A shared connection is used to access common resources such as universes or documents.

It can be used by several users. Information about a shared connection is stored in a SDAC.LSI or SDAC.SSI file; Its definition is updated dynamically.

Secured Connection : A secured connection is used to access universes or documents that may be restricted or confidential. It can be shared by several authorized users stored in the repository. The definition of a secured connection is updated dynamically.

How to Import built universes from CMS

File Import
Using the above option we can import the universe which are exported to Server.

You can import one or more universes stored in a universe folder in the repository. You can only import a universe that has already been exported to the repository. When you import a universe, the CMS checks the universe version on the repository file system. If the version is identical, the universe is made available to Designer. If the universe version on the repository file system is more recent than the CMS version, a message box appears asking if you want to replace the universe in the folder. If you answer Yes, then the universe on the repository file system is replaced by the version in the CMS.

Exporting a universe :
You make a universe available to Web Intelligence users and other designers by exporting a universe to the repository. When you export a universe the universe is: moved to the selected universe folder on the repository file system

and
created in the Central Management System (CMS). Each time the universe is exported to the repository, the universe version in the CMS is updated. This is the version that is available to DI/WebI users.

How are universes used?

Universes are used by Desktop Intelligence and Web Intelligence users for reporting and analysis. The universe should provide them with classes and objects relevant to their business domain. The universes are stored in the Crystal Management System (CMS) repository. An end user connects to a universe from a Desktop Intelligence or web browser. The connection to the database is defined in the universe, so by connecting to the universe, the end user automatically has access to the data. The access to data is in turn restricted by the objects that are available in the universe.

Designing Schema:
A Schema is a graphical representation of database structures. In designer you can create a schema for the part of the database that your universe represents.

Phases:
Inserting and Organizing tables.
Creating Joins and setting Cardinalities. Resolving Join path problems. Testing the integrity of your schema

Joins :

A join is a condition that links the data in separate but related tables. The tables usually have a parent-child relationship. If a query does not contain a join, the database returns a result set that contains all possible combinations of the rows in the query tables. Such a result set is known as a Cartesian product and is rarely useful.
You use joins to ensure that queries returning data from multiple tables do not return incorrect results. A join between two tables defines how data is returned when both tables are included in a query.

Linking all tables in the schema with joins ensures that you restrict the number of ways that data from columns in different tables can be combined in a query. Joins limit column combinations between tables to matching or common columns. This prevents result data being returned that contains information from columns that have no sense being matched.

Equi-Joins Link tables based on the equality between the values in the column of one table and the values in the column of another. Because the same column is present in both tables, the join synchronizes the two tables. Theta Joins

Link tables based on a relationship other than equality between two columns.

Outer Joins
Link two tables, one of which has rows that do not match those in the common column of the other table.

Shortcut Joins
Join providing an alternative path between two tables, bypassing intermediate tables, leading to the same result, regardless of direction. Optimizes query time by cutting long join paths as short as possible.

Connectivity and Cardinality

The connectivity of a relationship describes the mapping of associated entity instances in the relationship. The values of connectivity are "one" or "many". The cardinality of a relationship is the actual number of related occurrences for each of the two entities

Cardinality :

A Property of a relationship between objects in a database describing how many objects of type A are associated with how many objects of type B. Cardinality expresses the minimum and maximum number of instances of an entity B that can be associated with an instance of an entity A. The minimum and the maximum number of instances can be equal to 0, 1, or N. Because a join represents a bidirectional relationship, it must always have two cardinalities. If you selected the Detect cardinalities in joins options in the Database tab of the Options dialog box, Designer detects and retrieves the cardinalities of the joins. If you do not use this option, you can still retrieve the cardinalities for one or all joins in the universe.

Types of Connectivity Relations One-to-One (1:1) Relationship is when at most one instance of a entity A is associated with one instance of entity B One-to-Many (1:N) Relationship is one instance of entity A, there are zero, one, or many instances of entity B, but for one instance of entity B, there is only one instance of entity A

 Many-to-Many (M:N) One instance of entity A, there are zero, one, or many instances of entity B and for one instance of entity B there are zero, one, or many instances of entity A We wont use this property for joins in Business Objects.

How are cardinalities used In Designer? The cardinality of a join does not have a role in the SQL generated when you run a query. However, Designer uses cardinalities to determine contexts and valid query paths.

Memory allocation for the connection server Seconds to allow while connecting to DB

Array Fetch size : Array Fetch Size is a parameter of universe connection so that you can retrieve a larger number of rows each time you go to the database. Array fetch size is an attempt to set the number of rows returned in a packet from the database Maximum size is 500

Array Bind size : Array Bind Size is a parameter of universe connection so that you can set how much data can be held in memory before being written to the repository. It is the memory allocation for connection server which is introduced from BO XI version. It has very small impact on the performance than Array Fetch parameter.

Login timeout : It relates to the universe connection to the data source. As BO Enterprise connection server connects to the data source, the user id and pwd in the connection parameters are passed to the data source.

This parameter setting allows you to increase the number of seconds the connection server will attempt to log in to the data source before returning an error message.

Join path problems in universe A join path is a series of joins that a query can use to access data in the tables linked by the joins.

Join path problems can arise from the limited way that lookup and fact tables are related in a relational database. The three major join path problems that you encounter when designing a schema are the following:
loops chasm traps fan traps

You can solve all these problems by creating aliases (a copy of a base table), contexts (a defined join path), and using features available in Designer to separate queries on measures or contexts.
What is a loop ? It is an occurrence of more than one path exists from one table to another table. That means loops occur when there are two different paths to accomplish one join.

We can solve loops by creating aliases (a copy of a base table), contexts (a defined join path), and using features available in Designer to separate queries on measures or contexts.

Two Types of Loop Problem:

1) FANTRAP PROBLEM :

Definition: Two One-to-many table link each other is in turn linked another one-to-many table.
2) CHASM TRAP PROBLEM :

Definition: Two Many-to-one table converges on one single lookup table. Loop can be detected while INTEGRITY CHECK is done. An option is there as "Check for LOOPS" available. By "Detect Loop" we can choose what to be applied for solving the loop.

Fan Trap

Chasm trap Trap

What is Fan trap? A fan trap is a type of join path between three tables when a one-to-many join links a table which is in turn linked by another one-to-many join. The fanning out effect of oneto-many joins can cause incorrect results to be returned when a query includes objects based on both tables. You cannot automatically detect fan traps. You need to visually examine the direction of the cardinalities displayed in the table schema.

What is Chasm trap? A chasm trap is a type of join path between three tables when two many-to-one joins converge on a single table, and there is no context in place that separates the converging join paths. The chasm trap causes a query to return every possible combination of rows for one measure with every possible combination of rows for the other measure.

Defining Aliases!
An Alias is a table that is an exact duplicate of the original table (base table), with a different name. The data in the table is exactly the same as the original table, but the different name "tricks" the SQL of a query to accept that you are using two different tables.

Define Contexts! The most common use of contexts is to separate two query paths, so that one query returns data for one path, and the other query returns data for another path of fact table. You use contexts to direct join paths in a schema where Aliases are not appropriate.

When you save a universe, the changes are not saved to the CMS. You must export the universe to the CMS when you have completed updating a universe. The universes stored in the CMS server are used for version control. When you export an updated universe to the repository, the updated universe is copied to the CMS server.

Saving a universe definition as PDF You save the universe information as an Adobe PDF file. You can save the same information that you can print out for a universe. This information includes: General information: parameters, linked universes, and the graphical table schema. Component lists: lists of components in the universe including objects, conditions, hierarchies, tables, joins, and contexts. Component descriptions: descriptions for the objects, conditions, hierarchies, tables, joins, and contexts in the universe.

Aggregate Tables
Aggregate tables are database tables contain summarized data at different levels. Aggregate tables contain information that has a coarser granularity (fewer rows) than the detail data used to load other tables. For example, in a retail database, the transaction-level data drawn from the online transaction processing (OLTP) system might be in the form of individual sales receipts. The Sales_Receipts fact table would contain this detail data, but the records in that table might also be aggregated over various time periods to produce a set of aggregate tables

An aggregate table is created with a standard CREATE TABLE statement at Database level.
It does not have to share a primary key/foreign key relationship with other tables in the database. However, a common design strategy is to create a "family" of aggregate tables, including one that references one or more aggregate dimension tables known as derived dimensions. This strategy optimizes query-rewriting performance.

Usage of aggregate tables in Designer You can use features in Designer to allow you to define the Select statement for an object to run a query against aggregate tables in the database instead of the base tables. You can set conditions so that a query will be run against aggregate tables when it optimizes the query, and if not, then the query will be run against the base tables. This ability of an object to use aggregate tables to optimize a query is called aggregate awareness.

Aggregate awareness is a term that describes the ability of a universe to make use of aggregate tables in a database. These are tables that contain pre-calculated data. You can use a function called @Aggregate_Aware in the Select statement for an object that directs a query to be run against aggregate tables rather than a table containing non aggregated data. Using aggregate tables speeds up the execution of queries, improving the performance of SQL transactions.

A Simple example for Aggregate Awareness

Consider a data warehouse organized into three dimensions: time, geography, and product.
At its lowest level, this data warehouse can store daily information about customers and products. There is one row for each customers daily product purchases; this can be expressed as follows:

365 days x 100 cities x 10 products = 365,000 rows.

If you ask for information about yearly sales, the database engine must add up a large number of rows. However, the yearly sales of companies may actually involve fewer rows, as follows:

3 years x 3 countries x 3 companies = 27 rows

So, in this example, 27 rows from a table are sufficient to answer the question. Based on this information, it would be far more efficient to pre summarize these rows into aggregate tables.

Creating User defined variable object:

Creating User defined variable object:

Working with Classes and Objects : Classes and Objects can be renamed, deleted, hidden and modified. You can do all these by using its properties window. Creating an user defined object You create objects in the Universe pane. Web Intelligence users identify an object by its name and qualification. You can create objects manually in the Universe pane using the existing variables and functions based on end users report requirement.

SQL Editor to create an Object: You can use an SQL editor to help you define the Select statement or a Where clause for an object. The SQL Editor is a graphical editor that lists tables, columns, objects, operators, and functions in tree views. You can double click any listed structure to insert it into the Select or Where boxes. Most of the user defined variables we create are dynamic.

A measure object returns numeric information. You create a measure by using aggregate functions. The five most common aggregate functions are the following: Sum Count Average Minimum

Maximum

Using List Of Values: A list of values is a list that contains data values associated with an object. A list of values can contain data from two types of data sources. Database file : When you create an object, Designer automatically associates a list of values with the object. The list of values is not created until a user, or you the designer, choose to display a list of values for the object in the query panel.The returned data is stored in a file with a .lov extension in the userdocs folder. External file : Personal data. For Ex: text file/Excel file can be associated with a list of values.

A .LOV file is also created whenever any condition is applied to an object in the query panel that requires a restriction on the column values inferred by the object. The list of values for an object appears showing values available for an object, allowing the user to choose the terms for the condition. The first time a list of values is used, it is saved as .lov file in the user data folder in the business objects path. This allows the SELECT DISTINCT query to be run only once for an object. This folder also stores the .lov files created in designer which are used to restrict the list of values returned for objects for which the designer wants to control access to the data.

Using @Functions @Functions are special functions that provide more flexible methods for specifying the SQL for an object. @Functions are available in the Functions pane of the Edit Select box for an object. @Functions are very flexible. Depending on what you want to achieve, you can use any @function in either a Select statement, or a Where clause.

@Aggregate_Aware The @Aggregate_Aware function allows an object to take advantage of tables containing summary data in the database. If your database contains summary tables and you are running queries that return aggregate data, it is quicker to run a Select statement on the columns that contain summary data rather than on the columns that contain fact or event data.

You can use the @Aggregate_Aware function to set up aggregate awareness in a universe. This process includes a number of other steps which are associated with the use of the @Aggregate_Aware function.

Syntax @Aggregate_Aware(sum(agg_table_1), ... sum(agg_table_n)) Ex:

@Aggregate_Aware(sum(AAYEAR.REVENUE), sum(AAQTR.REVENUE), sum(AAMONTH.REVENUE),sum(PRODUCTS.PRICE *ORDER_LINES.QUANT))

@Prompt

You can use the @Prompt function to create an interactive object. You use a @Prompt function in the Where clause for an object. It forces a user to enter a value for a restriction when that object is used in a query. When the user runs the query, a prompt box appears asking for a value to be entered. @Prompts are useful when you want to force a restriction in the inferred SQL but do not want to preset the value of the condition.

Syntax The syntax of the function is as follows:

@Prompt(message,type,[lov],[MONO|MULTI],[FRE E|CONSTRAINED])

Hierarchies : Tools Hierarchies The hierarchies editor appears. Designer represents hierarchies with a folder symbol and dimensions with a cube symbol. The left pane list all the classes that contain dimension objects in the active universe. The right pane shows all the customized hierarchies that you create.

Linking of the universes : Linked universes are the universes that share common components such as parameters, classes, objects or joins. When you link two universes one universe has the role of a core universe, the other is a derived universe. When the changes are made in core universe, they are automatically propagated to the derived universe.

What is core universe ?

The core universe is a universe to which other universe are linked. It contains components that are common to the other universes linking to it. These universes are called derived universes. The core universe represents a re-usable libriary of components. A core universe can be a kernal or master universe depending on the way the core universe components are used in the derived universes. What is derived universe? A derived universe is a universe that contains a link to the core universe. The link allows the derived universe to share common components of the core universe.

Advantages of linked universe

You can link the active universe to a core universe, only if the following requirements are met;
The core universe and derived universe use the same data account or data base and the same RDBMS. Using the same connection for both the core and the derived universe makes managing the universe easier, but this can be changed at any time.

Restrictions when linking universes All classes and objects are unique in both the core universe and the derived universe. If not conflicts occur. The two universe structures must allow joins to be created between a table in one universe to a table in the other universe. If not then Cartesian product can result when a query is run with objects from both structures.

Only the table schema, classes and objects of the core universe are available in the derived universe, contexts must be redetected in the derived universe.

Thank you