Dear Readers, Welcome to BO Designer Interview Questions and Answers have been designed specially to get you acquainted with the nature of questions you may encounter during your Job interview for the subject of BO Designer. These BO Designer Questions are very important for campus placement test and job interviews. As per my experience good interviewers hardly plan to ask any particular questions during your Job interview and these model questions are asked in the online technical test and interview of many IT companies.
The Universe designer uses DESIGNER to design, create and maintain universes for a particular group of users. A universe designer can distribute a universe as a file through the file system, or by exporting it to a repository.
DESIGNER is a Business Objects product intended specifically for you the Universe designer.
It is important to analyze the type of information that the end users at your site will require so that you can develop universes that meet the needs of the user community. This includes the actual reports, information, or results likely to be required by the end users.
A universe is a mapping of the data structure found in databases: tables, columns, joins. A universe is made up of classes, objects and conditions.
A universe is the semantic layer that isolates the end user from the technical issues of the database structure.
Universe can be created by taking into consideration the type of data and the logical structure of your company’s databases.
Creating of the universe starts with gathering of user requirements, identifying the database tables where the data resides, inserting the db structure to the universe, creating classes and objects from the db tables, and creating measures. Creating the joins between the tables, resolving loops either by creating aliases or contexts. Finally testing & deploying.
@Aggregate_Aware, @Prompt, @Select, @Variable, Running Sum, Running Count, User Response, String functions, Date functions.
A universe is identified by:
• a file name which consists of up to 8 characters and a .unv extension.
• a long name which consists of up to 35 characters.
• a unique system identifier. This is the identifier assigned by the repository when you export the universe. This identifier is null if you have never exported the universe.
There are two ways to distribute a universe to end users or another designer:
1) Exporting to Repository (2) Through File system – Moving it as a file through the file Server.
A class is a logical grouping of objects and conditions within a universe.
An object maps to data or a derivation of data in the database.
An object can be qualified as a dimension, a detail, or a measure.
• Dimension objects retrieve character-type data that will provide the basis for analysis in a report.
• A detail object is always associated to one dimension object, on which it provides additional information.
• Measure objects retrieve numeric data that is the result of calculations on data in the database.
A measure object is derived from an aggregate function: Count, Sum, Minimum, or Maximum.
Conditional objects have a where clause, where normal objects do not have a where clause
DESIGNER provides three types of connections: (Tools ? Connections)
• Secured connection (Default): Stores the connection in the security domain of the BO repository to centralize and control access to sensitive or critical data. Designers and supervisors have the right to create this type of connection.
• Shared connection: Specifies that multiple users share the connection. All users who have access to this connection can use it and edit it. If you installed BO in Stand-Alone mode, the connection by default is stored in the sdac.lsi file (LocData subfolder). If you installed BO in Shared mode, the connection by default is stored in the sdac.ssi file (ShData subfolder). Designers and users have the right to create this type of connection.
• Personal connection: Specifies that the connection belong to the user who defined it. Other users cannot use or modify the connection. If you installed BO in Stand-Alone mode, the connection by default is stored in the pdac.lsi file (LocData subfolder). If you installed BusinessObjects in Shared mode, the connection by default is stored in the pdac.ssi file (ShData subfolder). Designers and users have the right to create this type of connection.
These parameters define the universe. They are Definition, Summary, Strategies, Controls, SQL and Links.
• Summary
Statistics of objects, joins, conditions, classes, contexts, hierarchies and alias in a universe. We get it from the Summary tab of the Universe parameters or File ? Parameters.
• Controls
The Control settings allow to limit the size of the result set and the execution time of queries.
• SQL
These parameter controls the query (allows use of subqueries, allows use of union, intersect and minus operators) and SQL generation options for the universe.
• Links
This links tab is used with dynamically linked universes.
A strategy is a script that automatically extracts structural information from a database or flat file. There are two types of strategies:
1. Built-in strategies
2. External strategies.
DESIGNER uses the following built-in strategies for creating the components of universes:
• The Objects Creation strategy, which tells DESIGNER how to define classes and objects automatically from the database’s tables and columns.
• The Joins Creation strategy, which tells DESIGNER how to define joins automatically from the database’s tables and columns.
• The Table Browser strategy, which tells DESIGNER how to read the table and column structures from the database’s data dictionary.
In the external strategy file you can customize an existing strategy or create your own.
External strategy files are named according to the following convention:
StxxxxEN.txt
where St means strategy, xxxx is an abbreviation for the RDBMS, and EN is the language in which Business Objects products are installed (EN =English)
For Oracle: Stora7en.txt in the Oracle folder
List mode command (View ? List Mode) provides list of all the tables, joins, and contexts.
A join is a relational operation that causes two or more tables with a common domain to be combined into a single table. The purpose of joins is to restrict the result set of a query run against multiple tables.
DESIGNER supports: • Equi-joins • Theta joins • Outer joins • Shortcut joins
Equi or Inner or Natural or Simple join: is 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.
? Self-Join: join a table to itself i.e create a self-join to find rows in a table that have values in common with other rows in the same table.
Theta or Non-Equi join: links tables based on a relationship other than equality between two columns.
Outer join: links two tables, one of which has rows that do not match those in the common column of the other table.
? Left Outer Join: All records from first table with matching rows from second.
? Right Outer Join: All records from second-named table with matching rows from left.
? Full outer join: All rows in all joined tables are included, whether they are matched or not.
Shortcut join: can be used in schemas containing redundant join paths leading to the same result, regardless of direction. Improves SQL performance.
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.
Cardinalities indicate whether the relationship or join between two tables is one-to-many (1,N), one-to-one (1,1), or many-to-many (N, N). Because a join is bi-directional, it must always have two cardinalities.
A Cartesian product is the result of a query in which two or more tables are not linked by a join.
If executed, the report shows results for each possible combination of each table row.
• It detects any errors in the objects, joins, conditions, and cardinalities of your universe.
• It detects whether there are any loops in the joins.
• It detects whether contexts are necessary.
• It determines whether any changes were made to the database to which the universe is connected.
Parse checking means how DESIGNER is to determine the validity of an object, join, or condition.
• Quick parsing checks only the syntax of components.
• Thorough parsing checks both the syntax and semantics of components.
By refreshing the structure I get the updated database structure.
Lookup tables: A lookup (or dimension) table contains information associated with a particular entity or subject.
Fact Tables: A fact table contains statistical information about transactions.
1. Loops (Too few rows) 2. Fan Trap (Too many rows) 3. Chasm Trap (Too many rows)
In a relational database, a loop occurs when joins form multiple paths between lookup tables.
1) Run the Check Integrity function, which indicates the existence of any loops.
2) Select the Detect Loops command from the Tools menu.
Loops can be resolved by creating aliases and contexts.
In SQL an alias is an alternative name for a table. In DESIGNER, an alias is just a pointer to another table. The purpose of aliases is to resolve structural issues in a database arising from SQL limitations. Whenever possible you should use an alias instead of a context.
Context is a method by which Designer can decide which path to choose when more than one path is possible from one table to another in the universe. Generally used transactional database with multiple Fact tables.
Dis-advantage:
When you use a context, you expose the BO end user to the database structure. They are forced to decide which context they want to use to run their query. The role of the universe is to shield end users from the database structure, so they do not have to make such decisions.
Fan Trap: occurs when a “One to Many” join links a table which is in turn linked by another “One to Many” join.
There are two ways to solve Fan trap:
• Creating an alias and applying aggregate awareness function. This is the most effective way to solve the Fan trap problem.
• Using Multiple SQL statements for each measure.
Chasm Trap: occurs when two “Many to one” joins from two Fact tables converge on a single Lookup table.
Can be solved by:
• Creating a Context.
• Using Multiple SQL statements for each measure
• Creating multiple universes (WEBINTELLIGENCE only).
You can use multiple universes to solve a Chasm trap in a WEBINTELLIGENCE universe when
Multiple SQL for Measures cannot be used as there are dimension objects defined for one or both of the fact tables.
You do not use multiple universes in the following situations:
• Full client BUSINESSOBJECTS universes
• When a WEBINTELLIGENCE universe does not contain dimension objects defined for any of the fact tables.
1) @Aggregate_Aware (2) @Prompt (3) @Script (4) @Select (5) @Variable (6) @Where
@Prompt: message prompts the end user to enter a specific value.
Syntax: @Prompt (‘message’, [‘type’], [lov], [MONO|MULTI], [FREE|CONSTRAINED])
@Script: This function recovers the results of Visual Basic for Applications macro (VBA macro).
Syntax: @Script (‘var_name’, ‘vartype’, ‘script_name’)
@Select: This function enables you to re-use the Select statement of an existing object.
Syntax: @Select (Classname\Objectname)
@Variable: The @Variable is used to reference the value assigned to a name or variable.
Syntax: @Variable(‘myname’)
@Where: This function lets you re-use the Where clause of an existing object.
Syntax: @Where (Classname\Objectname)
Is a function used to aggregate the data from table, is used to enhance the performance of SQL
transactions; it determines which tables to use in SQL generation either aggregate or detailed tables. Precedence: left to right
Syntax: @Aggregate_Aware (sum (table1.sal), sum (table2.sal))
Setting up Aggregate Awareness:
Build the Objects:
1. Identify all the possible definitions (table/column combinations) of the objects.
2. Arrange the objects by level of aggregation.
3. Build the objects using the @Aggregate_Awareness function.
Specify the incompatible objects
1. Build an objects/aggregate tables matrix.
2. For the first aggregate table, decide whether each object is either:
- at the same level of aggregation or higher (compatible)
- at a lower level of aggregation (incompatible)
3. Check only the boxes of objects that are incompatible for that table.
4. Repeat the steps for the remaining aggregate tables.
Define any necessary contexts
1.Define one context per level of aggregation.
Test the results
1. Run several queries.
2. Compare the results.
You can restrict an object so that only end users with the appropriate security access level can use it. Security access levels are assigned to user profiles by the supervisor from the Supervisor module.
The levels are from highest to lowest: Private, Confidential, Restricted, Controlled, and Public (Default level). The higher the level, the fewer the number of users can access it.
The purpose of multidimensional analysis is to organize data along a combination of “dimensions” and “hierarchies”.
BUSINESSOBJECTS allows two types of multidimensional analyses:
• Slice and dice
• Drill (available only with the BUSINESSOBJECTS EXPLORER).
Enterprise mode means working in an environment with a repository.
Online and offline modes are options that apply when you are working in enterprise mode.
Online mode: Online, the default mode, is appropriate for a networked environment in which
the general supervisor has set up a repository. In online mode, you can import or export universes.
Offline mode: Working in offline mode means essentially that you work with universes that are stored locally on your computer. To use this mode, you must have been connected at least once in online mode.
Workgroup mode means working in an environment without a repository.
DESIGNER can export a universe incrementally, meaning that it takes into account only the modifications made since the last export.
The following are the steps followed while migrating a universe across repositories:
1. First open the universe in the current repository and make the connection as shared.
2. Save the Universe. (Save for all Users)
3. Open the universe in the designer and export that to the required repository.
4. Change the connection type from shared to secured.
Note: Both the repositories must reside within the same database schema.
Linked universes are universes that share common components such as parameters, classes, objects, or joins.
Creating a universe by taking the components from another universe. Only one level of linking is possible in BO. There are thee approaches to linking: 1. Kernel 2. Master 3. Component
Disadvantages:
1.Any change made to the master universe is reflected onto the derived universe.
2. Designer does not save any list values, which may be associated with the linked universes.
• Linking a universe is a process, which includes the required objects/classes of the master on to the derived universe. But any change made to the master universe is reflected onto the derived universe.
• Including a universe creates all the required objects from the master universe on to the derived universe; any change made to the master universe does not impact the derived universe.