Student Guide. SAP BusinessObjects XI 3.0 Universe Design

Transcription

1 Student Guide SAP BusinessObjects XI 3.0 Universe Design

2 2

3 C O N T E N T S Lesson 1 Understanding BusinessObjects Universes Lesson introduction...1 BusinessObjects universe concepts...2 What is a universe?...2 The Semantic Layer...3 What type of database schema is used?...4 Classes and objects...5 How universes are used...5 Advantages of a universe...5 BusinessObjects Universe Designer components...6 Starting Universe Designer...6 Using the Quick Design Wizard...8 Using Universe Designer module commands...8 Saving and exporting a universe...11 Importing a universe...12 Universe file names as identifiers...12 Saving a universe definition as PDF...13 Giving all users access to a universe...13 Activity: Viewing a universe in Designer...14 The Universe Development Cycle...15 The Universe Development Cycle process...15 Preparation phase...16 Analysis phase...17 Planning phase...19 Implementation phase...20 Implementation phase 1: schema design...20 Implementation phase 2: building the universe...22 Testing phase...23 Deployment phase...24 Updating/maintenance...25 Prepackaged solutions...25 Activity: Planning a universe...26 Quiz: Understanding BusinessObjects universes...27 Lesson summary...28 Lesson 2 Creating the Course Universe Lesson introduction...29 The course database and universe...30 Table of Contents Learner s Guide iii

4 Course database description...30 Creating the universe...32 Creating a new universe...32 Defining universe parameters...33 Identifying the universe...33 Setting the database connection...34 Data access drivers...34 ODBC connection drivers...36 More about connection types...38 Viewing, modifying, and deleting available connections...38 Universe parameters...40 Definition tab...41 Summary tab...42 Strategies tab...43 Controls tab...44 SQL tab...44 Links tab...45 Parameters tab...46 Activity: Creating a new universe and defining its connection...47 Quiz: Creating the course universe...48 Lesson summary...49 Lesson 3 Building the Universe Structure Lesson introduction...51 Populating the universe structure...52 Designing a schema...52 Schema design and the universe creation process...52 Adding tables...52 Manipulating tables in the universe structure...55 Activity: Populating the universe structure...58 Defining joins in a universe...60 About joins and SQL WHERE clauses...60 Creating joins...61 About join properties...63 Editing the join expression...64 Using the Join SQL editor...64 Detecting joins...65 Setting join cardinalities...66 About cardinality...66 Setting cardinality manually or with the automatic detection tool...67 Displaying cardinalities...69 Detecting cardinality automatically...71 How is cardinality detected?...71 Detect cardinality for all joins...72 Best practice for setting join cardinality...73 Join types...74 Equi-joins...74 iv Universe Design Learner s Guide

5 Outer joins...75 Theta joins...77 Shortcut joins...78 Self-restricting joins...79 List Mode...81 Checking integrity...83 Activity: Defining joins in a universe...83 Quiz: Building the universe structure...86 Lesson summary...87 Lesson 4 Creating Dimension Objects Lesson introduction...89 Classes and objects...90 Classes...90 Objects...91 Creating classes and objects...93 Creating classes...93 Automatically creating classes and objects from a table...95 Defining a new object as a detail object...95 Working with classes and subclasses...96 Editing the object properties...97 Edit Properties: Properties Edit Properties: Advanced Edit Properties: Keys Edit Properties: Source Information Copying and pasting objects Find and replace Checking object integrity Viewing parent tables Testing objects Activity: Creating and testing classes and objects Quiz: Creating dimension objects Lesson summary Lesson 5 Creating Measure Objects Lesson introduction Measure object concepts Defining measure objects How a measure infers SQL The Query Process Aggregation at SELECT level Aggregation at projection level Setting selection and projection aggregates Creating measure objects Measure objects Table of Contents Learner s Guide v

6 Testing measure objects Activity: Creating and testing measure objects Delegated Measures What is a delegated measure? How does the delegated measure work? Using a delegated measure as a weighted average Best practices for using delegated measures Activity: Creating and using a delegated measure Quiz: Creating measure objects Lesson summary Lesson 6 Using Lists of Values Lesson introduction Creating a list of values What is a list of values? Using a list of values (LOV) Working with LOVs in Universe Designer Associating an LOV with an object Setting options for generating LOVs Editing the LOVs for the entire universe Adding data to the list by adding columns Creating a cascading LOV Setting up a cascading LOV Activity: Using a cascading LOV in Web Intelligence Rich Client Quiz: Using lists of values Lesson summary vi Lesson 7 Resolving Loops in a Universe Lesson introduction Understanding loops Recognizing loops Problems caused by loops Loops in a universe schema and not in the database What is the loop doing? Resolving loops Resolving loops using aliases About aliases Detecting loops and inserting aliases Redefining objects Listing and renaming aliases Choosing which alias method to use Resolving self-join loops using aliases Resolving loops using shortcut joins Using a shortcut join Activity: Resolving loops with aliases Universe Design Learner s Guide

7 Resolving loops using contexts About contexts Detecting and creating contexts Creating objects for each context Editing a context Testing contexts Updating contexts Activity: Resolving loops using contexts Quiz: Resolving loops in a universe Lesson summary Lesson 8 Resolving SQL Traps Lesson introduction Understanding SQL traps and universes About SQL traps Detecting and resolving chasm traps Chasm traps Detecting chasm traps The chasm trap scenario Resolving chasm traps Using multiple SQL statements for each measure to resolve chasm traps Drawbacks to the multiple SQL statements for each measure method Using contexts to resolve chasm traps Activity: Resolving chasm traps Detecting and resolving fan traps Fan traps The fan trap scenario Resolving fan traps Using aliases and contexts to resolve fan traps Solving a fan trap with two tables in a one-to-many relationship Avoiding fan traps altogether Activity: Resolving fan traps Quiz: Resolving SQL traps Lesson summary Lesson 9 Applying Restrictions on Objects Lesson introduction Restricting the data returned by objects Defining data restrictions Methods of restricting data in end-user modules Drawbacks to applying restrictions to objects An alternative to applying restrictions to objects Restrictions using condition objects Table of Contents Learner s Guide vii

8 Applying restrictions using the tables button Applying each type of restriction Activity: Applying restrictions Quiz: Applying restrictions on objects Lesson summary Lesson 10 with Objects Lesson introduction Activity: Quiz: with objects Lesson summary Lesson 11 Using Hierarchies Lesson introduction Understanding hierarchies and universes Hierarchies Working with hierarchies Default hierarchies Custom hierarchies The effect of custom hierarchies on default hierarchies Time hierarchies Testing automatic time hierarchies Advantages and disadvantages of automatic time hierarchies Time hierarchies based on database functions Advantages and disadvantages of database function time hierarchies Table-based time hierarchies Advantages and disadvantages of table-based time hierarchies Activity: Using hierarchies Quiz: Using hierarchies Lesson summary Lesson 12 Derived Tables and Indexes Lesson introduction viii Universe Design Learner s Guide

9 Using derived tables What is a derived table? Adding derived tables Derived tables as lookup for multiple contexts Nested derived tables Creating nested derived tables Activity: Adding derived tables Applying index awareness What is index awareness? Setting up index awareness What happens behind the scenes? Avoiding joins in tables Multiple foreign key entries SQL Editor dialog box Using an index awareness WHERE clause Activity: Setting up index awareness Quiz: Derived tables and indexes Lesson summary Appendix A Relational and Dimensional Modeling Understanding the metadata Data warehouses Online Transactional Processing systems Data Marts Dimensional Modeling Appendix B Alternative SQL syntaxes for other RDBMS SQL syntaxes for other RDBMS Answer Key Quiz: Understanding BusinessObjects universes Quiz: Creating the course universe Quiz: Building the universe structure Quiz: Creating dimension objects Quiz: Creating measure objects Quiz: Using lists of values Quiz: Resolving loops in a universe Quiz: Resolving SQL traps Quiz: Applying restrictions on objects Quiz: with objects Quiz: Using hierarchies Quiz: Derived tables and indexes Table of Contents Learner s Guide ix

10

11 Agenda Learner s Guide xi

12

13 Lesson 1 Understanding BusinessObjects Universes Lesson introduction To design effective and efficient universes for your business users, you need a general understanding of their structure and application. It is also important to become familiar with the process involved in building a successful universe. After completing this lesson, you will be able to: Define BusinessObjects universe concepts Use the Universe Development Cycle Understanding BusinessObjects Universes Learner s Guide 1

14 BusinessObjects universe concepts This lesson gives a general introduction to universes. After completing this unit, you will be able to: Describe a universe Describe BusinessObjects Universe Designer interface elements Save, export and import universes What is a universe? The BusinessObjects universe is the semantic layer that isolates business users from the technical complexities of the databases where their corporate information is stored. For the ease of the end user, universes are made up of objects and classes that map to data in the database, using everyday terms that describe their business environment. This means that by using a universe to create a query, users can retrieve exactly the data that interests them using their own business terminology. A BusinessObjects universe is a file that contains the following: Connection parameters to a single data source. SQL structures called objects that map to actual SQL structures in the database such as columns, tables, and database functions. Objects are grouped into classes. A schema of the tables and joins used in the database. Objects are built from the database structures that you include in your schema. Note: You associate data to universes by mapping to a data source. Data is not stored in the.unv file. 2 Universe Design Learner s Guide

15 End users select the universe they are authorized to access in order to build queries. They build a query by selecting objects defined in the universe, and in this way, they are not required to see or know anything about the underlying data structures in the database. BusinessObjects Designer XI Release 2 gives universe designers the ability to build universes from OLAP and metadata sources. It also offers the ability to build universes against Unicode databases and run reports that display data in one of many available languages. BusinessObjects Universe Designer XI 3.0 offers the following additions: Personal file universe creation wizard - universes have supported access to csv and xls files through generic ODBC. JavaBean - the JavaBean driver provides the ability to expose data returned by a JavaBean class and model it through a universe. Java database connectivity (JDBC) - access to a standard JDBC connection and JDBC support to all major sources is provided. Microsoft Analysis Services Microsoft Analysis Services 2005 support for OLAP universes is provided. Universes are used to query the database The role of the universe is to present a business-focused front end to the SQL structures in the database. The data used in a universe schema depends greatly on the end user requirements. It needs to provide an easy-to-use interface for end-users to: Run queries against a database Create reports Perform data analysis The Semantic Layer Universe Designer can be seen as the tool which creates the Semantic Layer. Metadata is imported into Universe Designer, and then the tables structure can be changed (using Derived Tables) or data can be changed before it is presented to the user (by manipulating objects). However, the source data essentially remains the same. This is what separates the Semantic Layer from Data Integrator. Data Integrator is an ETL Tool which can change the structure of the data, and also cleanse it from data errors. The semantic layer is also used for the Performance Management product suite. When building a Dashboard Manager or Set Analysis Metrics universe, the approach is slightly different to creating a normal ad hoc reporting universe: the Dashboard Manager or Set Analysis Metrics universe requires to have custom tags embedded within it (which can be considered a form of code), which are used by Dashboard Manager and Set Analysis products a mandatory self join is placed in the Dashboard Manager or Set Analysis Metrics universe to ensure that calculated metrics apply to one time period granularity in a time dimension, for example, daily, weekly, or monthly. Understanding BusinessObjects Universes Learner s Guide 3

16 custom filters are placed into the Dashboard Manager or Set Analysis Metrics universe to be able to compare sets (Joiner Filter, Leaver Filter, and so on), and to build metrics. This is why it is advisable not to use the same ad hoc reporting universe as your Dashboard Manager or Set Analysis Metrics universe. Information on building a Dashboard Manager or Set Analysis Metrics universe can be found in the Creating universes for use as metrics chapter of the BusinessObjects XI 3.0 Designer's Guide. What type of database schema is used? Before developing a universe you must familiarize yourself with the underlying data. Which type of database schema is going to be used for the universe? Will this be a Data Warehouse model, an Online Transactional Processing system (OLTP), or a Data Mart? How can you best implement the metadata into a universe schema to meet the end user requirements? Star Schemas The star schema is the simplest data warehouse schema. It is called a star schema because the diagram resembles a star, with points radiating from a center. The center of the star consists of one or more fact tables and the points of the star are the dimension tables. A star schema consists of fact tables and dimension tables: Fact tables A fact table typically has two types of columns: numeric facts and foreign keys to dimension tables. Facts can become measure objects in a BusinessObjects universe file. Dimension tables Dimension tables contain the qualitative descriptions that can be applied to the facts. Hierarchies may also be built into dimension tables. Dimension table data can become dimension or detail objects in a BusinessObjects universe file. Snowflake schemas The snowflake schema is a variation of the star schema used in a data warehouse. It is more complex than the star schema because the tables which describe the dimensions are normalized. 4 Universe Design Learner s Guide

17 Data modeling The traditional entity relationship (ER) model uses a normalized approach to database design. Database normalization is a technique for designing relational database tables to minimize duplication of information and to avoid data anomalies. Higher degrees of normalization typically involve more tables and create the need for a larger number of joins, which can reduce performance. Denormalization is the process of taking a normalized database and modifying table structures to optimize the performance by keeping a minimum relationship between tables; one dimension table versus one fact table. Another method is to use prebuilt summarized data in the schema. Classes and objects A universe contains the following structures: Classes Objects As the universe designer, you use Universe Designer to create objects and classes that represent database structures. The objects you create in the universe must be relevant to the end user s business environment and vocabulary. Classes A class is a logical grouping of objects within a universe. It represents a category of objects. The name of a class should indicate the category of the objects that it contains. A class can be divided hierarchically into subclasses. Objects An object is a named component that maps to data or derived data in the database. The name of an object should be drawn from the business vocabulary of the targeted user group. How universes are used A universe defines the connection to the database. By selecting a universe when creating new documents or editing existing documents, the business users automatically receive access to the data. The access to data, in turn, is restricted by the objects that are available in the universe. These objects have been created by you, the universe designer, based on the needs profile for a defined user group. Advantages of a universe The advantages of a universe are: Only the universe designer needs to know how to write SQL and understand the structure of the target database. Understanding BusinessObjects Universes Learner s Guide 5

18 The interface allows you to create a universe in an easy-to-use graphical environment. Data is secure. Users can see only the data exposed by the universe. Users can only read data, not edit it. The results are reliable and the universe is relatively easy to maintain. Users can use a simple interface to create reports. All users work with consistent business terminology. Users can analyze data locally. BusinessObjects Universe Designer components You create, modify, and update universes with Universe Designer. Universe Designer provides a connection wizard that allows you to connect to your database middleware. You can create multiple connections with Universe Designer, but only one connection can be defined for each universe. This database connection is saved with the universe. Universe 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 resolve loops in your schema. Users do not see this schema. Universe Designer provides an object explorer view. You use the explorer tree to create objects that map to the columns and SQL structures that are represented in the schema view. Users select these objects to run queries against a database. Starting Universe Designer Universe Designer can only be used with a BusinessObjects repository. You must log onto the repository before starting Universe Designer. After you start Universe Designer, you can open a universe in one of the following ways: Create a new universe. Import a universe from the repository. Open a universe directly from the file system. A universe is available to end users once it has been exported to the repository. Importing a universe, making changes, then exporting the updated universe to the repository is the most common way of working with Universe Designer. Note: You can save a universe to the file system. You do this when you are in the process of developing the universe locally and when you want to share the universe with other users who may not have connection rights to the target repository. Note: You can lock and secure a universe before importing it from or exporting it to the Business Objects repository for maintenance. 6 Universe Design Learner s Guide

19 To start Universe Designer 1. Click the Start button on the taskbar. 2. Select the Programs menu. 3. Select the BusinessObjects XI 3.0 menu. 4. Select the BusinessObjects Enterprise menu. 5. Select the Designer menu. The login dialog box for the repository appears. Login information System User Name Password Authentication name of the repository server your repository user name your repository password authentication method Note: This information is normally provided to you by the Business Objects administrator. Note: You can also use Designer standalone. Use the authentication method Standalone (No CMS). 6. Click the OK button. The Universe Designer start-up screen appears, and an empty Universe Designer session opens. The user name and repository name appear in the title bar. Note: Depending on options set for Universe Designer, the Quick Design Wizard can start automatically when you start in Universe Designer. Click Cancel to close the wizard. Understanding BusinessObjects Universes Learner s Guide 7

20 Using the Quick Design Wizard When you start a Universe Designer session for the first time, the Quick Design Wizard appears by default. You can use the wizard to quickly create a universe or to familiarize yourself with Universe Designer. However, unless your data source is a very simple model, it is not an appropriate tool for creating a complete universe that responds to end-user reporting requirements. Once you are familiar with Universe Designer, you will probably decide to disable the wizard and not use it to design universes. All the universe design, building, maintenance information, and procedures in this training manual are structured with the assumption that you have disabled the Quick Design Wizard. To deactivate the Quick Design Wizard You can prevent the wizard from appearing automatically when you create a new universe as follows: 1. Select Tools Options. Select the General tab. 2. Clear the Show Welcome Wizard check box, and click OK. Note: This check box is already cleared if you have cleared the Run this wizard at startup check box from the Startup Wizard Welcome page. Note: You can activate the Quick Design Wizard at any time by selecting the above check boxes from the General page of the Options dialog box. Using Universe Designer module commands There are three ways to issue commands in Universe Designer: Menu options Toolbar buttons Right-click menus Menu options You can perform most tasks by choosing options from the menu. The Universe Designer menu bar looks like this: Toolbar buttons The toolbar gives you quick access to many tasks. Universe Designer has three toolbars: the Standard toolbar, the Editing toolbar, and the Formula Bar toolbar. 8 Universe Design Learner s Guide

21 Right-click menus Right-click menus display on your screen when you click the right mouse button. These menus usually give you access to options related to the task you are currently performing. For example, if you right-click in the Universe pane, a drop-down menu for creating classes and objects is displayed: Universe Designer window The Universe Designer window is made up of two segments. On the right-hand side is the pane in which you insert the database tables and then view the universe structure that infers the FROM and SELECT clauses into a Select statement. This is known as the Structure pane. On the left-hand side is the pane in which you create the classes and objects that users will see when they build queries using this universe. The objects physically point to the tables you see in the Structure pane. This is known as the Universe pane. Manipulating the structure view There are three ways to manipulate the Structure pane in the Universe Designer window: toolbar buttons, drag and drop, and by using the Options panel. Zoom Often it is not possible to view the entire schema at normal magnification due to its size. Zoom in or out using the drop-down list on the toolbar to choose your percentage view for the schema. Arrange tables You can select this button to have Universe Designer automatically organize your tables sequentially and horizontally. Understanding BusinessObjects Universes Learner s Guide 9

22 Note: You can undo only the last command. If you do not like the arrange tables results, choose Undo from the Edit menu. Drag and Drop Different views of the universe structure can be achieved by selecting items and applying a command using one of the following methods: Double-clicking Dragging and dropping Right-clicking For example: Procedure To mark a single table To mark a join To mark more than one table or join To mark all tables and joins To move a table Action Click the header of the table. Click it. Ctrl-click the header of each table (or join) you want to highlight. Ctrl-A. Click the header of the table and drag and drop the table to the desired position. To roll up a table By default, the table header and a specified number of its columns are shown for all tables contained in the universe structure segment. This view can be altered for an individual table by double-clicking the table header. Double-click once to roll up a table so that only the header is shown. Double-click twice so that only the table header and key columns are shown. Double-click three times to return to an unrolled view of the table. To view the columns of a table If the view of a table does not show all the columns contained within that table, this is signified by three dots at the bottom of the table. To view the remaining columns Click the header of the table; a scroll bar appears on the right of the table. Alternatively, 10 Universe Design Learner s Guide

23 Procedure Action place the pointer on the bottom margin of the table and a double-headed arrow appears. You can then drag the bottom margin down to expand the number of columns shown in the table. To achieve this the table header must not be highlighted. To gain a partial view of the data content of the table Right-click the table header and choose the View Table Values option. Right-click the column required and choose the View Column Values option. To view the data values for a single column To view the number of rows for a table in the database By default, data is only displayed for the first 100 rows of the table. This number can be expanded or reduced using the Tools Options Database tab. Right-click the table header (or structure segment background if you want the number of rows for all tables) and then choose the Number of Rows in Table option. If you are front ending a large database, this may not be advisable due to the time it takes to process. Saving and exporting a universe Regularly save your universes during a work session. When you save a universe, Universe Designer stores it as a file with a.unv extension in your local file system. This is usually a universe folder in the BusinessObjects installation path. Any changes you have made to the universe file are saved locally but are not propagated to the universe version in the repository until you choose to export it. When you export the universe, the updated version is saved on the local file system, but it is copied to the BusinessObjects repository as well. This version is then available to end users connecting to the universe. It is also made available to other universe designers who are authorized by the BusinessObjects Administrator to access it. Regularly save your changes to a universe locally. When you have finished updating the universe, export the latest saved version to the repository. Understanding BusinessObjects Universes Learner s Guide 11

24 If you choose to browse to a copy of that universe file on your local file system and open it directly in Universe Designer, the file may not be the latest version of the universe. If you want to make changes to a universe that has already been exported to the repository, do not open a universe file directly using File Open menu. Instead, use File Import to ensure that you are viewing the most recent version. Make your modifications and export your universe again to make your changes available in the repository. Importing a universe When you import a universe, you import the latest version of the universe from the repository. The universe is copied to the local file system, and this file is opened in Universe Designer. You can import one or more universes stored in a universe folder in the repository. To import a universe 1. Select the Import command from the File menu. The Import Universe dialog box appears. 2. Select a universe folder from the drop-down list. Note: You can also import a universe by clicking the Browse button to select the universe you would like to import. Note: If you want to lock the universe, double-click the universe name. A locked universe appears with a padlock symbol. Locking a universe prevents other designers from importing or exporting this universe. The locked universe can still be read by users and other designers. To unlock a universe, double-click it again. 3. Click the universe name. This is the universe that you want to import. 4. Verify the file path for the import folder in the Import Folder box. This points to the location where the universes are exported. 5. Click OK. Universe file names as identifiers Do not change the universe file name after reports have been created based on that universe. If you change the file name, any report built on the universe with the old name does not point to the universe after its name has been changed. The universe name can be different from the.unv file name. When you use Save As to save the universe under a new name, the new universe is not associated in the repository. You must export the new universe to the repository to create a version of the new universe. 12 Universe Design Learner s Guide

25 You can use the following methods to save a universe: 1. Select File Save from the menu bar. 2. Click the Save icon. 3. Press CTRL+S on the keyboard. Do not save two different universes with the same file name. This leads to conflicts when you attempt to export these universes to the repository. Saving a universe definition as PDF You can also save the universe information in Adobe PDF format. This allows you to save to a PDF file with the same attributes that are defined for printing purposes. Note: You can view the default attributes by selecting the Tools Options menu and selecting the Print/PDF tab. The Options dialog box will be presented in detail in a later lesson. The attributes that you can print or save to a PDF file include: 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. Saving these attributes as a PDF file may be helpful for troubleshooting or maintenance purposes. To save universe information as a PDF file 1. In Universe Designer, open the universe you want to save as PDF. 2. Select File Save As. 3. Select Portable Document Format (PDF) from the Save As type drop- down list. 4. Click Save. Giving all users access to a universe If you want to make a universe available to universe designers who may not have access to your Central Management Server, you must save the universe with an unsecured connection. To make a universe accessible to all Universe Designer users 1. Verify that the universe that you want to make available to all users does not have a secured connection. Secured connections are required to export universes to the repository. If a universe has a secured connection, select or create a new personal or shared connection. Understanding BusinessObjects Universes Learner s Guide 13

26 Note: Creating connections is discussed in detail in a later lesson. 2. Select File Save As. 3. A File Save dialog box appears. 4. Select the Save For All Users check box. 5. Click OK. Activity: Viewing a universe in Universe Designer Objective Open a universe and identify universe elements in Universe Designer Instructions 1. Open Universe Designer. 2. In Universe Designer, click File Open. Browse to the efashion.unv file found in the default installation folder: C:\Program Files\Business Objects\BusinessObjects Enterprise 12.0\Samples\en\UniverseSamples Or, find the same file on the Resource CD for this course. 3. Explore the menu options, toolbar buttons, and right-click drop-down menus. 4. Select View Toolbars, and ensure that all three toolbars are selected. 5. Zoom to 125% (type directly into the field instead of using the drop-down list). 6. Click View Arrange Tables to automatically organize tables. 7. Click View List Mode to list all Tables, Joins, and Contexts. 8. Click the Article_Color_Lookup table in the Tables list and to see it highlighted in the structure below. 9. Select Tools Options and click on the Graphics menu tab. 10. Select the Show row count check box, and click OK. 11. Right-click the Article_Color_Lookup table to view the number of rows in the table (Refresh row count for all tables). 12. Right-click the Article_Color_Lookup table to view a sample of the table values. 13. Open the Product class to view the objects it contains. 14. Double-click the Color object (notice the name, description, and select fields). 15. Select Parameters on the File menu and change the universe long name to New efashion. 16. Close the universe. 14 Universe Design Learner s Guide

27 The Universe Development Cycle Universe development is a cyclical process that includes planning, designing, building, distribution, and maintenance phases. Use Universe Designer to design and build a universe. However, the usability of any universe is directly related to how successfully the other phases in the development cycle interact with each other. After completing this unit, you will be able to: Use the Universe Development Cycle The Universe Development Cycle process This unit presents an overview of a universe designing methodology that you can use to plan and implement a universe development project. The diagram below outlines the major phases in a typical Universe Development Cycle: The analysis of user requirements and design are the most important stages in the process. Users must be heavily involved in the development process if the universe is going to fulfill their needs both with the business language used to name objects and the data that can be accessed. Implementation will be successful if the first three stages are carried out properly. It is advisable to spend 80% of the time allocated to the development of a universe on the first three stages: preparing analyzing planning Understanding BusinessObjects Universes Learner s Guide 15

28 If you have spent the appropriate amount of time in laying the foundation for your universe, the remaining 20% of the time spent actually using Universe Designer to build your universe will be much more productive. Preparation phase During the preparation phase, the scope of a BusinessObjects universe is defined. The production and development architectures are identified and reviewed. Project teams are assembled and the initial task plan is defined. Identify universe scope The definition and communication of project scope eliminates risk associated with deploying the universe to pilot users during the Implementation phase. The scope is defined in terms of intended functionality of the universe. Identification of target users of the universe also helps create a shared understanding of project objectives. Key managers should be involved in the scoping process. Once formulated, the objectives of the project are communicated to everyone involved, directly or indirectly. Build a project team In designating the team members, individuals must be chosen to fill the following roles. One person may fill multiple roles. Role Sponsor Project Leader Analyst Data Expert Key User Pilot Users QA Reviewer Task Usually the individual funding the project. The project sponsor makes any final decisions regarding scope or unresolvable issues. The project leader develops the project plan, assigns resources, tracks, and reports on progress. Individual who gathers requirements in the form of candidate objects. An individual familiar with the data structures. Provides ongoing business perspective for developers. Users who will work with the universe during the universe build and development phase. An individual with BusinessObjects experience who is not part of the development process will perform a technical review of the final product. 16 Universe Design Learner s Guide

29 In most cases, a single person will be responsible for the bulk of the work, filling the roles of Analyst, BusinessObjects Administrator, and Data Expert. In designing and building the universe, this person will maintain a relationship with the Key User, who should also be one of the Pilot Users. This developer usually reports to a Manager or IS Director, who serves as Project Leader. The Leader maintains a close relationship with the Sponsor. Other roles that will be impacted by the project include the Database Administrator, the System Administrator, and the Data Administrator. Adopt standards Standards for the components of a BusinessObjects universe will help to guarantee consistency and stability in the final product. During preparation, the team adopts a set of standards for BusinessObjects components. Standards can be specified for: Universe names Object definition guidelines Names for objects Class names Alias names Help text The standards may be revised during the course of the first universe development project as the team becomes more familiar with the product. Conduct a meeting Communicate the preparation phase strategy in a meeting. This is your opportunity to gather all interested parties (developers, users, the sponsor) to ensure that everyone understands the scope of the endeavor. You can use this meeting to demonstrate BusinessObjects products and to help set expectations of the user community. Analysis phase The primary objective of analysis activities is to identify user requirements for the ad hoc query environment. These requirements are captured in the form of candidate classes and objects. Understanding BusinessObjects Universes Learner s Guide 17

30 Identify candidate objects There are many places to look for candidate objects. The best way to identify them is by talking to the end users. When interviewing end users, the type of questions to ask are: What type of information do you need to do your job?, How do you know you are doing well?, How does your boss know you are performing well?, or What kind of information do others ask you for? As users answer these questions, document their answers in terms of class and object requirements. For example, if a user states, We require to retrieve information on employees by department and hire date you have identified a potential class ( information about employees ) and an object or two ( department and hire date ). When you identify a potential class, probe for objects. For example, What kind of information about Employees do they want? Candidate classes and objects can also be identified by reviewing existing reports. Document your classes and objects. For example: Type Name Description Source Class Customer Information on a customer, including location, credit ratings, and shipping preferences. Interview #1 Object (Measure) Total Revenue This object can be combined with date ranges, customers, and/or products to provide meaningful measures. Interview #3, #4 You should also try to document the qualification of objects (dimension/detail/ measure) and any potentially identified hierarchies. Relational modeling versus multi-dimensional modeling The questions asked during BusinessObjects interviews are similar to those asked in the development of OLTP applications. What is done with the answers is very different. When conducting Analysis for an OLTP application, analysts document data requirements in entity relationship diagrams. Rules of normalization are applied to the items that users request, breaking them down to an atomic level, or eliminating calculated objects. These activities optimize the data for storage in a relational database. By contrast, requirements for an ad hoc query environment should be expressed in terms that are optimized for retrieval of the information. A successful BusinessObjects universe presents information to a business person using user specific business terminology. The developer must unlearn analysis techniques used for the 18 Universe Design Learner s Guide

31 development of application systems. User requirements must be taken at face value, remaining in business terms. Basic rules of thumb: Do not normalize Do not eliminate objects that can be derived from other objects Do not try to figure out where this data can be found in the database For example: in an interview, a user states I need to look at annual sales figures by region. Document this at face value; identify the requirements, but do not attempt to transform them in a manner appropriate for storage in a relational database. You can identify three candidate objects: Year of Sale, Sales Amount, and Region. Do not eliminate Year of Sale because you have already documented a Date of Sale object. Do not reduce Sales to the components from which it is calculated (perhaps quantity multiplied by price ). Instead of normalizing object requirements, identify how they will support on-line analysis by end users. Identifying candidate objects as dimensions, details or measures will facilitate end user reporting and analysis flexibility. You can also plan for scope of analysis (drill-down and drill-up options) by identifying dimensional hierarchies. Once you have gathered and documented requirements in the form of candidate objects, you are ready to begin to plan the BusinessObjects universe requirements. Planning phase The planning phase will be used to identify a project strategy and determine resource requirements. Create a project plan The project plan is the key to timely implementation. For each task, the plan should assign responsibility and target dates. Creation of the plan and the tracking of progress against the plan are the primary responsibilities of the project leader. Plan the BusinessObjects architecture Technical architecture requirements may have been looked at in general in the preparation phase. A review of the technical architecture should take place during the planning phase of the project. Items to review include: Development environment Identify resources required to support a universe development environment. Understanding BusinessObjects Universes Learner s Guide 19

32 Production environment Identify resources required for a universe production environment. Computers Review required computing resources for developer and user workstations. Connectivity Configuration Security Support plan Change management plan Training plan Ensure infrastructure is in place to support connectivity between users/developers and the repository and data stores, including appropriate middle-ware to support communication between clients and servers. Identify planned configuration for client software. Ensure appropriate resources are available. Initiate a first look at security requirements. Develop support policy for when the universe goes into production. Identify procedures for the request, review, approval, and implementation of changes to the universe when in production. Plan for a user training program. Implementation phase The implementation phase can be split up into two stages: 1. Designing the schema 2. Building the universe Implementation phase 1: schema design The first task during schema design is to determine and document the data source for each candidate object. If requirements were gathered in a tabular format, add a column to the table where you can indicate the SQL fragment and source tables that will be used to retrieve the object. Type Name SQL fragment Description Source Class Customer Information on a customer, including location, credit ratings, and shipping preferences. Interview #1 20 Universe Design Learner s Guide

33 Type Name SQL fragment Description Source Object (Measure) Total Revenue SQL: sum(order_lines.quantity* products.price) Source Tables: Order_Lines, Products This object can be combined with date ranges, customers, and/or products to provide meaningful measures. Interview #3,4 Any candidate classes that were captured as general requirements without specific objects must be expanded now. For example, suppose there was a candidate class called Customer and the specific objects within this class were not identified. During the schema design stage, the developer must fill out this class. The developer might fill it out based on knowledge of the business by including all columns from one or more tables, or the developer might go back to users for more detail. There are several ways that objects can be mapped to enterprise data. Simple objects map back to a single column in the database. An example would be Customer First Name, which maps back to the First_Name column in the Customers table. Complex objects make use of SQL to manipulate data that comes from one or more columns. For example, a Customer Full Name object might connect the First_Name and Last_Name columns from the Customers table. Aggregate objects involve SQL GROUP functions. Counts, sums, and averages are all aggregate objects. The Total Revenue object is an aggregate object; it uses the SQL SUM function. Plan for object qualifications and drill-down functionality As you design the universe, you must complete the process you began during analysis. Identify each object as a measure, a dimension or a detail. For each detail object, identify the dimension it is associated with. Similarly, you need to identify hierarchies within your dimensions. These hierarchies will later enable users to drill-down and drill-up. Design a table diagram Now that the objects are mapped back to data sources, the developer reviews all the objects and produces a table-diagram of the database objects that will support the universe. Joins between the tables are then added to the diagram. The table diagram is a valuable tool for resolving loops and SQL traps in the model. It will also become an important reference for developers. Note: This diagram design is usually done on paper, however this can be created directly in the BusinessObjects Universe Designer software. Tip: If you find that you have documented a vast amount of classes and objects based on user requirements you may consider designing schemas that can be used to build: 1. Multiple universes which cater to a specific function within the business, reducing the complexity and amount of classes and objects. 2. Multiple universes specific to a business function, as this will prevent users from creating queries that can span the spectrum of the business. Understanding BusinessObjects Universes Learner s Guide 21

34 Revise objects and table diagram Once loops and SQL traps are resolved, the design of some objects will require modification. Any object based on a table that was replaced by an alias must be updated. Consult your table of objects created in the preparation phase for such objects. Note: If you are already using Universe Designer for the schema design you can view a table s associated objects to identify which objects require changes. Some objects may be applicable in the context of more than one of the aliases; these objects will be split into multiple objects. Make sure that object names make it clear what each one represents. Review join strategy Where table relationships are optional, the type of join to use must be chosen carefully. The use of standard (or inner) versus outer joins will impact the results of user queries. Using the wrong type of join may provide results that are not what users expect. In SQL, a standard join between two tables will return only rows where both tables meet the join criteria. If one of the tables has no corresponding row in the second table, its data will not be returned. An outer join tells the database processing the SQL query to substitute a null row if one of the joined tables has no corresponding row in the other table. With an outer join, information in one table that does not have corresponding data in the second table is returned with blanks in columns from the second table. The developer must review join possibilities with a key user wherever optional relationships exist. The chosen solution should produce results that users are most likely to expect. Identify allowable object usage The developer may identify certain objects that should not be used in qualifications by end users. Certain complex objects may not be usable in qualifications for technical reasons, or there may be performance considerations. Determine security approach Security requirements must also be addressed during the Implementation phase. Solutions to security requirements may involve complex object definition, reliance on database-level security, use of BusinessObjects access levels (public, private, controlled), restriction sets or the development of multiple universes. Chosen solutions may impact the database administrator and developers. Implementation phase 2: building the universe 22 Universe Design Learner s Guide

35 Once the schema design stage is complete, the development team is ready to begin using the BusinessObjects Universe Designer software to build the universe. Tip: Remember that it is better to have several smaller less complex universes than one large universe. This will reduce maintenance, avoid potential security impacts and will improve overall usability. Pilot users then begin to use the universe. They provide feedback to developers who refine the universe until build is completed. Build the universe The BusinessObjects Universe Designer software is used to actually build the universe. The developer must: Name the universe. Set up the universe parameters and connect to the relevant data source. Create aliases and contexts as identified in the schema design. Create joins as identified in the schema design. Create classes, subclasses and objects as identified in the schema design. Define objects as dimensions, details, or measures. Define hierarchies. Define lists of values and help text. Define conditions and implement user security, where applicable. Supply prebuilt queries and reports During the build stage, the team may identify certain queries and reports that will be of value to the entire enterprise. Created at anytime throughout the build, these queries and reports are re-checked after the universe is finalized to ensure that objects used have not been renamed or removed. They are then exported to the repository so that they are available to all users. Testing phase The pilot testing and refinement phase follows universe design implementation. Once an initial universe is built, it is deployed to the pilot users. These users work with the universe and provide feedback to the developers. Types of feedback include: Better names for classes and objects. Objects not in the universe that should be added. Objects that can be removed. Better ways to organize objects (for example, move an object from one class to another, reclassifying a dimension as a detail, and so on). Objects or queries that do not behave as expected. Understanding BusinessObjects Universes Learner s Guide 23

36 Based on this feedback, the universe is modified. The modified universe is made available to the pilot users for further evaluation. The testing phase can also address potential performance issues. As a developer you can look at implementing performance enhancements to the universe. Quality assurance After the build is finalized, the universe is reviewed for quality assurance. An independent reviewer makes the following checks: Corporate standards for universe, object, class, and alias naming are followed. Objects are only defined with tables that are referenced in the select text or Where condition. Objects return results without syntactic error. Objects return intended business results. Objects are correctly classified as dimensions, details or measures. Defined hierarchies make sense. Objects have help text. Aliases are used appropriately. Join syntax and foreign keys are accurate. Standard and outer joins are used appropriately. These checks are best made by an individual who was not part of the development of the universe, guaranteeing an objective perspective. Any issues that are identified are reported to the developers for correction and review. Deployment phase The universe has been built, and has passed all quality assurance checks. It is now ready for deployment. The final deployment of the universe cannot begin until any architectural issues identified during planning phase have been addressed. These issues include the establishment of user connectivity, planning the installation configuration, preparation of a training program, and identification of support and change management processes. Architecture Architectural considerations identified during the planning phase are reviewed. Any issues that have not been resolved will delay the deployment phase. Production environment The production environment has been set up in accordance with the architecture and security plans identified during preparation and planning. The universe is modified to access data from 24 Universe Design Learner s Guide

37 production systems, rather than from development systems and is exported to the production repository. Granting user access Any database accounts that will be required for BusinessObjects users should be created by the database administrator. These accounts should be given appropriate access privileges to the data objects used by the universe. Users are also added to the Central Management System (CMS) and granted access to the universe. Conduct training The release of the BusinessObjects universe to production users is coordinated with system and database administrators as appropriate. The user training program is executed in conjunction with the roll-out of the universe. Without appropriate training, users will not derive benefits from BusinessObjects, regardless of the quality of the universe. Updating/maintenance Be sure to inform users about the support and change control mechanisms available to them. They need to know who to call if they have a problem or question, and what procedure should be followed to request a change to the universe. These mechanisms were identified during the planning phase. Prepackaged solutions If you are designing a universe for Business Objects developers for developing precreated/ prepackaged reports, then the following items should be taken into consideration: Predefine all filters and calculations that are used in standard documents, to remain consistent throughout The universe can cover more than one business function, to allow cross functional reporting. Precreated reports tend to cross reference reports against different business functions. The universe will, therefore, have to cover multiple business functions to provide end-to-end business reporting. Understanding BusinessObjects Universes Learner s Guide 25

38 Activity: Planning a universe Objective Use the first three stages of the Universe Development Cycle. Instructions 1. From the resource CD launch the Planning_universe_activity.html file.(activity_resources > Lesson 1) to familiarize yourself with the Universe Development Cycle and to complete the activity questions. 2. Use this checklist of questions you need to ask when you begin designing a universe: What are the target data sources for your universes? What is the schema/structure of each of these data sources? Do you know the contents of each of the tables? Do you know how each of the tables are interrelated? Are you familiar with all of the necessary joins? Are you familiar with the cardinality of each of these joins? Have you procured database schemas from the database administrators who administrate the data sources? Are you familiar with your different user populations and how they are structured? Do you know what standard reports are required? Do you know what the users' ad-hoc information needs are? Are you familiar with their business terminology and formats? Have you considered how many universes need to be created to address users' needs? Have you considered how long universe development may take? Have you considered which universes should be developed before others? Have you considered who should test your universes for you? Have you considered how data sources and/or user requirements may change over time? Do you already have all of the information necessary to implement your universes? 26 Universe Design Learner s Guide

39 Quiz: Understanding BusinessObjects universes 1. What are the two main panes in Universe Designer? 2. What are the three ways to issue commands in Universe Designer? 3. Where can you define what specific information about the universe gets printed? Understanding BusinessObjects Universes Learner s Guide 27

40 Lesson summary After completing this lesson, you are now able to: Define BusinessObjects universe concepts Use the Universe Development Cycle 28 Universe Design-Learner's Guide

41 Lesson 2 Creating the Course Universe Lesson introduction This lesson introduces you to the database that is used in this course. It teaches you how to create a new universe and define a connection from the universe to the course database. To create a new universe and maximize its potential, it is necessary to learn about parameters. Parameters allow you to set the structure of your universe, including setting up a database connection. After completing this lesson, you will be able to: Describe the course database and universe Create the universe Creating the Course Universe Learner s Guide 29

42 The course database and universe In order to create a BusinessObjects universe, you must first be familiar with the data and structure of the database to which the universe will be connected. You also need to fully understand the users reporting requirements. After completing this unit, you will be able to: Understand the database used during this course Know the specifications of the universes built during this course Course database description During this course, you are going to build universes to report on a database for a fictional car sales and rentals organization called Prestige Motors. The database has the following characteristics: There are three showrooms, two in the US and one in the UK. Each showroom has the franchise for a number of different car makers, who all manufacture a number of different models, available in a range of colors. No new models have been brought out during the period. Customers may either rent or buy cars. Customers will usually rent or buy from the showroom in their own country but this is not always the case. The database contains data for two financial years 2003/2004 and 2004/2005. Each year begins on April 6 and ends on April 5 in the subsequent year. Information about employees who work within the organization is also available in the database. There are summary tables for quarterly and annual revenue and numbers to speed up queries. The data is stored in a SQL Server database. Connections to the database are to be made using ODBC. Assumptions There has been no inflation over the different years for which data is held. There is no stock data. All manufacturers are able to supply on demand. Users in all countries use the same currency (the US dollar). Analysis of reporting requirements Following an analysis of the company s reporting needs, the following specification has been identified. 1. Ad hoc reports are required on models. These are required to list the cars for sale and rent. 30 Universe Design Learner s Guide

43 Such reports may include the following: manufacturer, model, trim, engine size, available colors, and sale/rental price. Reports may be grouped by price range and style (for example, sport, or estate.) These reports will be used to show potential customers model availability and for general management reporting. 2. A report is required which lists the showrooms, their location and which manufacturers they have a dealership agreement with. This report will be created by the universe designer and distributed as a corporate document for all to read and refresh. 3. Ad hoc reports are required on car sales. These are required to list car, sale and customer details. Reports may be grouped according to customer, showroom, sale, model and manufacturer dimensions. These reports will be used to analyze results at all levels from sales specific details to general high level reports such as sales revenue per annum, per showroom, by manufacturer, or by car. 4. Ad hoc reports are required on car rentals. These are required to list car, rental and customer details. Reports may be grouped according to customer, showroom, rental, model and manufacturer dimensions. These reports will be used to analyze results at all levels from specific rentals details to general high-level reports such as rentals revenue per annum, per showroom, by manufacturer, or by car. Reports related to 2, 3 and 4 above will be used by sales staff, finance department staff, and managers. Development plan The remainder of this course will be spent developing universes for this imaginary deployment. In accordance with the iterative approach, the development will be phased as indicated below. 1. Design and develop a universe which enables end users to build reports which meet requirements 1 (model reporting) and 3 (sales reporting). The universe needed to do this can be regarded as relatively simple to create. 2. Extend the universe to meet reporting requirements 2 (franchise reporting) and 4 (rental reporting). This requires the introduction of loops, chasm and fan traps into the universe structure which need to be resolved. This constitutes a fairly complex universe structure. 3. Further extend the universe to refine and enhance the universe for end users by introducing conditions, LOVs and hierarchies for drilling. 4. Design and develop a universe for end users that enables them to build reports which meet requirements 5 (ad hoc reporting on employees). Creating the Course Universe Learner s Guide 31

44 Creating the universe In this unit, you will begin to create the course universe, based on the analysis of business requirements and the development plan. After completing this unit, you will be able to: Create a new universe Create a new data source name Create a new connection in Universe Designer Describe the universe parameter settings Creating a new universe Before you can build a universe, you must firstly create a new universe file. You save the new universe as a.unv file. The new universe contains no classes and objects. You create these during the universe development process by designing a table schema and then creating objects that map to database structures. To begin creating a new universe 1. In Universe Designer, select New from the File menu. The Universe Parameters dialog box displays: Note: Make sure the Universe Parameters dialog box displays with the Definition tab active. 32 Universe Design Learner s Guide

45 2. In the Name field, enter a name for the universe. 3. In the Description field, enter a brief description for the universe. This is used as a help description for the end user. It needs to accurately describe the content of the universe using terminology the end user will easily understand. 4. Select File Save from the menu bar. 5. Provide a name for the file. The universe file is saved as a.unv file Defining universe parameters To be able to start building the universe structure, you must first define a number of parameters, such as the parameters to be used to connect to the data source. Universe parameters are definitions and restrictions that you define for a universe. These parameters: identify the universe identify the database connection specify the type of queries that can be run using the universe set the controls on the use of system resources An important element of this setup process is selecting the kind of database connection you will use. Select an existing connection or create a new one. The other parameters can be set at this point but are better done at a later point in the universe building process. Identifying the universe Each universe is identified by the following parameters: Identifier File name Long name Description Unique system identifier Used by File system, Business Objects end-user querying tools to reference the universe Business Objects end-user querying tools Business Objects end-user querying tools Central Management Server Creating the Course Universe Learner s Guide 33

46 File names A file name is created when you save the universe. The length of the name is dependent on your operating system maximum. Windows allows approximately 156 characters. The file name extension is.unv. The local file system is the server on which Universe Designer is installed. Your universes are saved by default in the universes folder in your user profile path as follows: \\Documents and Settings\<user>\Application Data\Business Objects\Business Objects 12.0\Universes\<universe>.unv Note: Do not change the universe file name after reports have been created on that universe or the report files will no longer point to the universe. Long names The universe long name is set in the Name field on the Definition tab. You can enter up to 200 characters and there are no character restrictions. Universe descriptions The universe description is an optional field. Information in this field can provide useful details about the universe s role and is viewable by end users. Unique system identifiers The unique system identifier is assigned by the Central Management System (CMS). This occurs when the universe is exported to the repository for the first time. Setting the database connection In order to connect to the database for which you intend to build a universe, you need to create a BusinessObjects connection. A connection is a named set of parameters that defines how a Business Objects application accesses data in a database file. A connection links Web Intelligence to your middleware. You must have a connection to access data. The BusinessObjects connection contains all pertinent information for how to connect to the target database (for example: data access driver (middleware), connect string, connection type, and advanced connection parameters). If you are building several universes to front end the same database, then the connection may already exist. Therefore, you only have to select it from the available connections. However, if the connection does not exist, you will have to create one. Data access drivers A data access driver is the software layer that connects a universe to your middleware. 34 Universe Design Learner s Guide

47 Data access drivers are shipped with Business Objects products. There is a data access driver for each supported middleware. When you install Universe Designer, your data access key determines which data access drivers are installed. When you create a new connection, you select the appropriate data access driver for the relational database management system (RDBMS) middleware that you use to connect to the target RDBMS. The types of databases supported through data access drivers are: IBM DB2 Informix Microsoft SQL Server Oracle Red Brick Sybase NRC (Teradata) Hyperion Generic ODBC With the new XI architecture, connections can now be made to MS Analysis Services 2000, MySQL, and SAP. Additional connection options shown below have been added in XI R2 and XI 3.0. Creating the Course Universe Learner s Guide 35

48 ODBC connection drivers Open Database Connectivity (ODBC) is Microsoft's strategic interface for accessing data in a heterogeneous environment of relational and non- relational database management systems. An ODBC Driver can be the "back end" for a DBMS (Database Management System) server environment. Any ODBC client can access any DBMS for which there is an ODBC Driver, for example SQL Server, Oracle, AS/400, Foxpro, Microsoft Access, or any DBMS for which an ODBC driver exists. Note: Connections to the database can be made using ODBC as well as OLE DB (Object Linking and Embedding, Database). OLE DB extends the ODBC feature set to support a wider variety of non-relational databases, such as object databases and spreadsheets that do not necessarily implement SQL. To create an ODBC connection for SQL Server Note: This example describes how to create an ODBC connection. Direct connections are supported for certain database vendors, therefore the ODBC setup is not always required. SQL Server is the database used for this course, and requires an ODBC connection. 1. Navigate to the ODBC Data Source Administrator wizard. Start Programs Administrative Tools Data Sources (ODBC) Start Settings Control Panel Administrative Tools Data Sources (ODBC) 2. Click the System DSN tab. 3. Click Add. 4. Scroll down to select the SQL Server driver, and then click Finish. 5. In the Create a New Data Source to SQL Server window add or select the following: In the Name box, type a name that identifies the database you want to connect to. In the Server box, type (local) - unless SQL Server is installed on another machine. In that case, select the machine name from the list. 6. Click Next. 7. For the authentication, select the appropriate method for SQL Server to authenticate the login ID. Depending on the selected option, type in the required Windows or SQL Server authentication user name and password. 8. Select the Change the default database to check box, and then select the database to connect to from the drop-down list. 9. Click Next, and then click Finish. 10. Click Test Data Source. You should get the message TESTS COMPLETED SUCCESSFULLY. 36 Universe Design Learner s Guide

49 If you don t get this message, review your steps and verify the added authentication credentials. 11. Click OK until you can close the Administrative Tools window. To define a connection in Universe Designer 1. In the Universe Parameters dialog box, verify that the Definition tab is selected. 2. Click New. Note: You can also create a new connection from the Connections dialog box. Select Tools Connections and click the Add button in the Connections list. The Welcome page of the Connection Wizard appears. 3. Click Next. The Database Middleware Selection page appears. It lists the database and middleware that correspond to your data access driver key. 4. Select the connection type from the Type list box. Note: In order to deploy a universe to the BusinessObjects repository, you must define this connection type as Secured. 5. Define a name for the connection. You can enter up to 35 characters. 6. Expand the + box for the target database for the connection. The supported middleware for that database appears in the expanded area. 7. Expand the + box for the target middleware for the connection. The data access driver for the middleware appears. 8. Select a driver name and click Next. The Login Parameters page appears. 9. Select the required authentication mode. 10. In the User name and Password field enter the database login credentials. 11. In the Data source name field, select the appropriate data source for the database you are connecting to. 12. Once you have entered this information, click Next. 13. In the Configuration Parameters page, apply the required parameters or keep the default values selected. Click Next. 14. In the Custom Parameters page, apply the required parameters or keep the default values selected. Click Finish. 15. In the Wizard Connection dialog box, click the Test button to test the connection. Creating the Course Universe Learner s Guide 37

50 If the connection is valid, a message dialog box appears indicating that the connection is correct. If you receive an error message, check that you entered all the parameters correctly. If the error persists, refer to the section of your RDBMS documentation relating to error messages. 16. Click Finish to exit the wizard. If you created the connection from the Universe Parameters dialog box, the new connection is listed in the connection drop-down list. Note: Avoid creating two different secured connections with the same name. For example, one connection named "Status" and the other named "status". This may lead to a conflict in the repository. More about connection types The connection type determines who can use the connection to access data. You can create three types of connections with Universe Designer: personal, shared, and secured. Personal connections Use personal connections to restrict data access to the universe creator and the computer on which it was created. Using a personal connection, you have access to personal data on a local machine. You do not use personal connections to distribute universes. Shared connections Allow access to data for users. These connections are unsecured. Shared connections can be useful in a universe testing environment. Secured connections Secured connections centralize and control access to data. They are the safest type of connection. Use secured connections to protect access to sensitive data. You can create secured connections with Universe Designer. Connections are stored in the BusinessObjects repository. These can be shared with other designers with the appropriate privileges. You must use secured connections if you want to distribute universes through the BusinessObjects repository. Secured connections can be used and updated at any time. To define a secured connection you must be connected to the BusinessObjects repository. Viewing, modifying, and deleting available connections You can view all available stored connections in the Connections List. Using the Wizard Connection, you can edit existing connections, or create new ones. 38 Universe Design Learner s Guide

51 Note: You cannot modify the name of an existing connection. Created connections can be removed from the Connections List. To view available connections 1. Select Tools Connections. The Wizard Connection dialog box appears with the Connections List page. This list displays all the connections available to the designer, regardless of the universes. The current universe may be based on a SQL Server database, but you can add a new connection to an Oracle database in this wizard. You can add, delete and edit existing connections from this dialog box. 2. Click Cancel to close the dialog box. To edit a connection 1. Click Tools Connections. The Wizard Connection dialog box appears. 2. Select the connection that requires editing from the list of available connections. 3. Click Edit. The Login Parameters page for the connection appears. 4. Modify the login parameters or select a different data source for the connection. Creating the Course Universe Learner s Guide 39

52 5. Click Next. 6. Modify the configuration parameters as required, and click Next. 7. Modify the custom parameters as required, and click Finish. 8. Click the Test button to verify the modified connection. 9. Click Finish to apply the changes to the connection. To delete a connection 1. Click Tools Connections. The Wizard Connection dialog box appears. 2. Select the connection you want to delete from the list of available connections. 3. Click the Remove button. A confirmation dialog box appears. 4. Click Yes. The connection is removed from the list. Universe parameters This topic describes the parameters that you can define using the different tabs available in the Universe Parameters dialog box. Note: For more detailed reference information about these parameters, refer to Chapter 2 - Doing Basic Operations, Setting Universe Parameters in the Business Objects XI 3.0 Designer s Guide. Universe Parameters dialog box There are seven tabs on the Universe Parameters dialog box that allow you to change different parameters. This lesson provides a brief introduction to these tabs. They are discussed in more detail later in the course. This table provides a quick snapshot of the different tabs: Parameter Definition Description Universe name, description, connection parameters, and information. These parameters identify the universe. Summary Version and revision information, designer comments, and universe statistics. 40 Universe Design Learner s Guide

53 Parameter Strategies Description Strategies used by the universe. A strategy is a script used to extract structural information from a database. Controls SQL Links Parameter Limitations set for the use of system resources. Types of queries that the end user is allowed to run. Settings defined for linked universes. SQL parameters that can be dynamically configured. Definition tab On the Definition tab you can set the universe name and a meaningful description. There is no character limitation. End users will see these in their Business Objects querying tool when they select the universe. The Connection field displays the connection name defined against the database. Creating the Course Universe Learner s Guide 41

54 Summary tab The Summary tab displays universe administration information. Information Created Modified Description Universe creation date and the name of the creator. Date of last modification and the name of the modifier. Revision Revision number indicates the number of timesthe universe has been exported to the repository. Comments Information about the universe for yourself or another designer. This information is only available in Universe Designer. Includes information about the universe for users in the Description field on the Identification page. You can print the text contained in this box, which means that you can use it to track changes made to the universe and by whom, if you so desire. 42 Universe Design Learner s Guide

55 Information Statistics Description List of the number of classes, objects, tables, aliases, joins, contexts, and hierarchies contained in the universe. Strategies tab A strategy is a script that automatically extracts structural information from a database or flat file. Default strategies have two principle roles: Automatic join and cardinality detection Automatic class, object, and join creation Strategies are useful if you want to automate the detection and creation of structures in your universe based on the SQL structures in the database. Strategies that automate the creation of universe structures are not necessarily an essential part of universe design and creation. They are useful if you are creating a universe quickly, and you want to use metadata information that already exists in a database or database design tool. However, if you are building a universe by creating objects and joins that are based on relationships that come directly from a user needs analysis, then you will probably not use the automatic creation possibilities that this tab offers. Built-in strategies are the default strategies that are shipped with Universe Designer. You can select them by clicking the drop-down menus in this strategies parameters tab. There are built-in strategies for all supported databases, which cannot be modified. You can, however, create Creating the Course Universe Learner s Guide 43

56 custom strategies, which are known as external strategies. Built-in strategies appear by default before external strategies in the drop-down lists. Note: The built-in strategies for detecting joins will only select on matching column names, ignoring all other column names, and may create unnecessary joins. Controls tab On the Controls tab, you can limit the result size and execution times for queries that use this universe. The Limit execution time option allows you to restrict the execution time for any query generated via the universe for queries generating more than one SQL statement. The time limit that you specify for query execution is the total execution time for a query. If the query contains multiple SQL statements, then each statement is given an execution time equal to the total query execution time divided by the number of statements. The result is that each statement in the query has the same execution time. If one statement requires a lot more time than others to run, it may not complete as its execution time will not correspond to its allotted execution time within the query. When you specify an execution time limit for multiple SQL statements, you need to take into account the normal execution time of the single statement that takes the longest time to run, and multiply this value by the number of statements in the query. SQL tab 44 Universe Design Learner s Guide

57 You can set controls on the types of queries that end users can build in Business Objects querying tools. You can indicate controls for the following areas of query generation: Use of subqueries Use of operators and operands in individual queries Generation of multiple SQL statements Selection of multiple contexts Prevent or warn about the occurrence of a Cartesian product Note: The Multiple SQL statements for each measure option is selected by default. Accepting this default value could potentially impact query performance. This issue will be discussed in more detail in later lessons. Links tab Creating the Course Universe Learner s Guide 45

58 Links specify dynamic links between universes related to the same database. This allows a universe and its content to be embedded in another universe. Embedding universes optimizes maintenance where some objects are used in many universes. Note: Universes need to be exported to the repository before linking. Parameters tab In Universe Designer, you can configure certain SQL parameters that are common to most databases to optimize the SQL generated. These parameters apply only to the active universe, and are saved in the.unv file. 46 Universe Design Learner s Guide

59 Activity: Creating a new universe and defining its connection Objective Create a new universe and define its connection to the database. Instructions 1. Create a DSN for SQL Server 2005 called MotorsDSN. 2. Start a Universe Designer session and log on. 3. Create a new universe and define the following parameters: Name = Motors Description = This universe provides information on the Prestige Motor Cars Database for Showrooms, Models sold, Rental and Sales Business Connection = Motors_conn Tip: Use the New Connection Wizard to create the Motors connection against the Motors database in SQL Server. 4. Save the new Motors universe. The universe is saved in the local universe directory. 5. Create another new universe and define the following parameters: Name = Staff Description = This universe provides information on the personnel of Prestige Cars. Connection: Motors_conn Note: Use the same connection that you used in Step 5: that is, Motors_conn against the Motors database. 6. Save the Staff universe. Creating the Course Universe Learner s Guide 47

60 Quiz: Creating the course universe 1. Information about universe administration appears on the Universe Parameters dialog box. Under which tab can you find this information? 2. Can a universe and its content be embedded in another universe? 3. If you want to distribute the completed universe to the user population using the BusinessObjects repository, which type of connection should you use? 48 Universe Design Learner s Guide

61 Lesson summary After completing this lesson, you are now able to: Describe the course database and universe Create the universe Creating the Course Universe-Learner's Guide 49

62 50 Universe Design-Learner's Guide

63 Lesson 3 Building the Universe Structure Lesson introduction This lesson describes how to add tables to the universe structure and how to customize the way you work with tables. After completing this lesson, you will be able to: Populate the universe structure Define joins in a universe Building the Universe Structure Learner s Guide 51

64 Populating the universe structure A schema is a graphical representation of a database structure. In Universe Designer you create a schema for the part of the database that your universe represents. After completing this unit, you will be able to: Design a schema Add tables in the Structure pane Organize your view of tables Designing a schema The schema contains tables and joins. Objects are mapped to columns in tables that end users use to create reports. The joins link the tables so that the correct data is returned for queries that are run on multiple tables. Design the schema in the Structure pane by selecting tables from the target database using the Table Browser. You create joins to link the tables. When you have designed the schema for your universe, you can verify the schema using an automatic integrity check. Good schema design is essential to good universe design. Populate the schema with tables based on the columns that correspond to the objects that end users need to create reports. Define the objects according to a user needs analysis. Examine the database for tables that allow you to create these necessary objects. Schema design and the universe creation process After the initial schema design in the first implementation phase of the Universe Development Cycle, you will start using Universe Designer to build your universe. Adding tables The Structure pane of the Universe Designer interface is used to create a visual representation of the physical data structure to which the universe is mapped. When you create a new universe, the structure is empty and you need to populate it with the appropriate tables. Database tables are placed in the structure using the Table Browser, which provides a list of tables in the database. The Table Browser is an independent window that shows a tree view of the tables and columns in your target database. Use the Table Browser to view and select tables in your database that 52 Universe Design Learner s Guide

65 you want to insert into your schema. Expand the + box next to a table name to display the columns for the table. To open the Table Browser The Table Browser is not visible by default. You must activate the Table Browser when you want to add tables to the Structure pane. You can activate the Table Browser using any of the methods listed below. Note: A universe file has to be open in Universe Designer to be able to access the Table Browser. 1. You can open the Table Browser using one of the following methods: Click the Table Browser button on the Editing toolbar. Double-click the background area of the Structure pane. Select Insert Tables from the menu bar. Right-click the Structure pane and choose Tables from the drop-down menu. The Table Browser displays: From the Table Browser you can select tables to include in the universe schema. You can insert a single table or multiple tables simultaneously. To insert a single table 1. You can use the following methods to insert a single table: Building the Universe Structure Learner s Guide 53

66 In the Table Browser, click a table and drag it into the Structure pane. In the Table Browser double-click a table. In the Table Browser click a table, and click Insert. The table appears in the Structure pane. To insert multiple tables 1. In the Table Browser, hold the Shift key while you click the first table and last table to select a continuous block of tables. Multiple tables are selected. Note: The Ctrl key can also be used here to select multiple tables. Tip: It is a good practice to insert only a few tables together at one time. This makes the schema more manageable when making further adjustments and adding joins. 2. Use one of the following methods to add the tables to the Structure pane: Click Insert Drag and drop the selected tables in the Structure pane. Each table including all of its columns appears in the Structure pane. In the Table Browser, any table that you insert in the universe displays with a check mark beside its name. Note: Columns cannot be selectively chosen. When you select a table, all columns will be included in the structure. To view data from the Table Browser You can use the Table Browser to view the data contained in a table, or in an individual column. 1. Expand a table +box in the Table Browser and right-click a column or the entire table. 2. Select View Table Values from the right-click menu. A dialog box appears listing the data contained in the table or column. 54 Universe Design Learner s Guide

67 Manipulating tables in the universe structure When a table has been placed in the Structure pane, it shows the names of the columns it contains. You can use various commands to manipulate tables within the Structure pane. These are described in the sections that follow. You can move, copy, or delete tables in the Structure pane, as well as organize and change the table display. To select tables Usually the first step in moving, copying, or deleting tables is to select them. 1. To select a single table, click the table header. 2. To select several tables, press Ctrl and click the table header of each table you want to select in turn. 3. To select all tables, press Ctrl + A or choose Edit Select All from the menu bar. Tip: You can also select multiple tables by: Building the Universe Structure Learner s Guide 55

68 clicking on the Structure pane holding the left mouse button down dragging the mouse across the tables you want to select A line appears when you do this and boxes in your selection. 4. To deselect a table, click the background of the Structure pane. To move tables 1. Select the tables you want to move. 2. Drag the tables to a new position. To delete tables 1. Select the tables you want to delete. 2. Press the Delete key. To organize your tables There are several options that enable you to obtain a better view of your tables: 1. Use drag and drop to move the tables around the Structure pane. 2. Click the Arrange Tables button to arrange tables horizontally. 3. Select from the Zoom drop-down list to minimize or magnify the Structure pane. 56 Universe Design Learner s Guide

69 4. Double-click the table header in Structure pane to change the table display. To change a table display You can change tables so that they display all columns of a table, the table name only, or the primary and secondary keys (join columns) only. 1. There are three options to change a table display: Select View Change Table Display from the menu bar. Select Ctrl + T. Double-click the table header. Table name displays: 2. If you select View Change Table Display, Ctrl+T, or double-click a second time, only the Join columns will display in the table. Join columns only display: If you repeat one of those actions a third time, the original table view appears again. To view table values You can view the data for a database table or column in the same way as in the Table Browser. 1. Right-click the header of the table whose values you want to see. The following menu displays: Building the Universe Structure Learner s Guide 57

70 2. From the menu, choose Table Values. 3. Click Close. Activity: Populating the universe structure Objective Insert tables into the Motors universe. Instructions 1. Insert the tables listed below into your blank Motors universe. CLIENT COLOUR 58 Universe Design Learner s Guide

71 COUNTRY FINANCE_PERIOD MAKER MODEL REGION SALE SALES_PRICE_RANGE SALE_MODEL SHOWROOM STYLE 2. Order the tables so that they are laid out in the same way as the illustration below. 3. Save the changes to the universe. Building the Universe Structure Learner s Guide 59

72 Defining joins in a universe After you have inserted more than one table in the schema, you need to create joins between related tables. A join is a condition that restricts the resultset of a multi-relational query. Joins are as important as tables in a schema because they allow you to combine data from multiple tables in a meaningful way. After completing this unit, you will be able to: Understand why you need joins in the universe structure Create joins Set join cardinalities Explain the join types View join expressions using List Mode Check the integrity of the universe structure and its joins About joins and SQL WHERE clauses SQL specifies a join implicitly in a WHERE clause through a reference to the matching or common columns of the tables. Normally there is one WHERE clause for each pair of tables being joined. For example, if four tables are being combined, three WHERE conditions are necessary. In BusinessObjects querying tools, if you run a query that involves inferring a SELECT statement on two tables that have not been joined in the universe structure, the resulting report produces a Cartesian product, that is, an illogical question resulting in illogical data, as illustrated below. In other words, it outputs a report that joins every column in the first table to every column in the second table. To prevent this from happening, you need to specify a join between the tables in the Structure pane in Designer. 60 Universe Design Learner s Guide

73 Creating joins You have several approaches to creating joins in Designer: Defining joins manually in the schema Defining join properties directly in the Edit Join dialog box Using the Join SQL Editor to specify the join expression Each of these approaches is described in detail below. Defining joins manually in the schema You can graphically create individual joins between tables by using the mouse to drag a line from a column in one table to a matching column in another table. Creating the join by defining properties You can also create a join by directly defining the join properties in the Edit Join dialog box. To create a join by tracing manually 1. Click on any blank area of the Structure pane to deselect all tables. 2. Position the pointer over a column that you want to be one end of a join. The pointer appears as a hand symbol. 3. Click and hold down the left mouse button. The column is highlighted. 4. Drag the mouse to the column in another table that you want to be the other end of the join. As you drag, the pointer changes into a pencil symbol. 5. Position the pencil symbol over the target column. The target column is highlighted. 6. Release the mouse button. The join between the two tables is created. Note that the definition of the join appears in the Formula toolbar. 7. Double-click the new join. The Edit Join dialog box appears showing the join properties. Building the Universe Structure Learner s Guide 61

74 Note: The properties that you can set for a join, including cardinality and join type, are described later in this lesson. The Edit Join dialog box displays the default properties of the join. 8. Enter and select properties for the join. 9. Click OK to close the Edit Join dialog box. To create a join using the Edit Join dialog box 1. Select Insert Join from the menu, or click the Insert join button. The Edit Join dialog box appears. 2. Select a table from the Table1 drop-down list. The columns for the selected table appear in the list box under the table name. 3. Click the name of the column that you want to be at one end of the new join. 4. Select a table from the Table2 drop-down list box. The columns for the selected table appear in the list box under the table name. 5. Click the name of the column that you want to be at the other end of the new join. The join expression is dynamically built in the zones below and can be modified as necessary. Note: The properties that you can set for this join, including the join operator, cardinality, and join type are described later in this lesson. 62 Universe Design Learner s Guide

75 6. Click OK. The new join appears in the schema, linking the two tables and columns that you specified in the Edit Join dialog box. Note: Another method for inserting a join is to click the first table in the Structure pane, hold down the Ctrl key, click the other table, and then click Insert Join. The two tables are automatically entered in the Edit Join box and you can edit the join properties as required. About join properties You can define the following properties for a join. Property Table1 Table2 Operator Outer Join Cardinality Shortcut Join Expression Description Table at the left end of the join. Columns are listed for the table selected in the drop-down list. Table at the right side of the join. Columns are listed for the table selected in the drop-down list. Operator that defines how the tables are joined. The operators available to a join are described in the following section. When selected, determines which table contains unmatched data in an outer join relationship. Outer joins are described fully in the following section. When selected, allows you to define the cardinality for the join. Defining and using cardinalities is described in the following section. Defines the join as a shortcut join. Shortcut joins are described in the following section. WHERE clause used to restrict the data that is returned when the two joined tables are included in a query. This clause can be edited as necessary. Join operators You can select an operator for a join from the drop-down list between the Table1 and Table2 boxes. The operator allows you to define the restriction that the join uses to match data between the joined columns. You can select the following operators for a join: Operator Description = equal to!= not equal to Building the Universe Structure Learner s Guide 63

76 Operator Description > greater than < less than >= greater than or equal to <= less than or equal to Between Complex between (theta joins) complex relationship Editing the join expression Use the Edit Join dialog box to define and edit join properties. You can also access the Join SQL editor to edit join syntax directly from this dialog box. The Edit Join dialog box also has two features available that allow you to edit and verify the join syntax: Edit The Edit button opens an SQL editor. Use this graphic editor to modify the syntax for tables, columns, operators, and functions used in the join. Parse The Parse button starts a parsing function that verifies the SQL syntax of the join expression. If the parse is successful, you receive a result is OK message. If Designer encounters an error, you receive an error message indicating the source of the problem. Using the Join SQL editor You can use a graphical editor to directly modify the SQL expression for a join. You access this editor from the Edit Join dialog box by clicking the Edit button. To modify a join using the Join SQL editor 1. Double-click a join in the Structure pane, or click a join and select Edit Join. The Edit Join dialog box appears. 2. Below the Expression text box, click the Edit... button. 64 Universe Design Learner s Guide

77 The Join SQL Definition dialog box appears. The SQL expression for the join appears in the text box. 3. Modify the SQL syntax as required. You can use the following editing features to modify or add SQL syntax: If you want to... Change a column at either join end Change an operator used by the join Use a function in the join Then... Expand the table + box in the Tables and Columns box and double-click on a new column name. Double-click an operator in the Operators box. Expand a function family + box and double-click on a new function, or edit the SQL text directly. The column, operator, or function appears in the join definition. 4. Click OK to validate your changes. 5. Verify that the join expression in the Expression text box has been modified. 6. Click OK to close the Edit Join dialog box. Detecting joins Joins can also be created automatically. This procedure can be applied to multiple tables or, if none are selected, all tables in the Structure pane. Building the Universe Structure Learner s Guide 65

78 Note: The automatic detection of joins assumes that all columns with matching names are to be joined, and other columns will be ignored. This may not be appropriate, in which case it is better to insert the joins manually. To detect joins automatically 1. Click the table you want to select joins for. Note: You can select multiple tables by pressing the Shift key, and clicking each table. You can also select all tables in a zone by clicking in an empty space, and dragging the cursor to define a rectangular zone that includes any number of tables. 2. To detect the joins automatically: Select Tools Automated Detection Detect Joins. Click the Detect Joins button from the Editing toolbar. A Candidate Joins dialog box displays listing all the joins detected. 3. Click the join or joins you want to accept in the Candidate Joins dialog box. Note: You can accept and insert several joins at the same time using Shift-click or Ctrl-click. 4. Click Insert. The join or joins are inserted in the Structure pane. 5. Click Close. Setting join cardinalities Setting cardinality is a critical step in universe development. Cardinality is the term that refers to the relationship between two tables based on a join, specifically how many rows in one table will match those in the other. Whether or not cardinality is defined or how it is defined does not directly impact the SQL that is inferred in universe queries. Rather, a universe designer defines cardinality to benefit from powerful assistance from the Designer resolving-loops tool. About cardinality Cardinality is the means by which Designer identifies the relationships between tables in the universe structure. The cardinality can be: one-to-one (1-1) one-to-many (1-N) many-to-one ( 1) many-to-many (N-N) 66 Universe Design Learner s Guide

79 For example, a country can have many regions, so the relationship between a Country and a Region table is 1-N. Designer uses cardinality to detect and resolve loops. Note: It is very important that all cardinalities are set correctly for loop and context detection. This will be discussed in more detail later in this course. You can choose to set cardinality manually or by using an automatic detection tool. Setting cardinality manually or with the automatic detection tool Cardinality in universe design is based on a logical algorithm using a physical count. The automatic detection tool only works properly if the database is populated with realistic data in a completely normalized structure (for example, no multiple lookup tables or other tricks that are sometimes applied by database administrators). Also, it is important to understand that because the detection tool runs three queries on every join, it can take a long time to complete the detection method. The cardinality detection tool works by running the following queries: A count of the rows in each of the two tables that are joined (two queries) A count of the rows output when applying a query with the join specified in the WHERE clause (one query) For these reasons, you are strongly advised to apply cardinality manually for efficiency and accuracy. When you set cardinalities manually, you must consider each individual join. This helps you to become aware of potential join path problems in your schema. You may not find these problems if you only select automatically detected cardinalities; for example, isolated one-to-one joins at the end of a join path, or excessive primary keys where not all columns are required to ensure uniqueness. To set cardinality manually It is recommended that you systematically set the join cardinality when you first create a join, using the following manual method. 1. Double-click a join, or click a join and select Edit Properties. The Edit Join dialog box appears with the join expression already defined. In the center of the dialog box is the Cardinality zone. Building the Universe Structure Learner s Guide 67

80 2. To set the cardinality manually, click the appropriate 1 and N option buttons in the Cardinality zone. Note: 1 = one end of join; N = Many end of join. Tip: As you click the different options in the Cardinality zone, a message appears below the buttons to describe the relationship between the tables, based on the settings you select. 3. Select the 1 or N radio button for Table1. 4. Select the 1 or N radio button for Table2. 68 Universe Design Learner s Guide

81 5. Click OK to accept your changes and close the Edit Join dialog box. Displaying cardinalities You can display cardinalities in the Structure pane using the following symbols: Cardinality symbol Example Description Arrow Arrow indicates the one direction of the join. If cardinality is 1,1 then an arrow head is shown at each join end. Arity Crow s foot indicates the many end of the join. If cardinality is 1,1, then a straight line is shown. Building the Universe Structure Learner s Guide 69

82 Cardinality symbol Example Description 1,N Cardinality is shown as a ratio at each end of the join. To display cardinalities 1. Select Tools Options from the menu bar. 2. The Options dialog box opens to the General page. 3. Click the Graphics tab. The Graphics page appears. 4. Click the Arrow, Arity, or 1,n option. 5. Click OK to save the changes. 70 Universe Design Learner s Guide

83 Detecting cardinality automatically You can set Designer to detect cardinality automatically as you insert joins, however it is recommended that you use the manual method described previously, to ensure accurate results. You can detect cardinality for a single join by selecting that join and clicking the Detect Cardinalities icon in the Editing toolbar. This is due to the fact that, if the database is large, running the cardinality detection queries for every join can take considerable time. How is cardinality detected? To detect the cardinality of a join between two tables, the following three queries are run: SELECT count (*) FROM table1, table2 WHERE table1.column = table2.column SELECT count (*) FROM table1 SELECT count (*) FROM table2. The results of the three queries are then compared in an attempt to determine which query is the end of the join with one entity and which is the end with many (if there is one). To detect cardinality on a single join Cardinality can be detected on a single join using one of two methods. 1. Using the Edit Join dialog box: a. Double-click the join in the Structure pane to open the Edit Join dialog box. b. In the Cardinality zone of the Edit Join dialog box, click the Detect button. c. Check the cardinality statement to make sure that the one-to-many relationship proposed makes logical sense. d. Click OK to accept the proposed cardinality and close the Edit Join dialog box. In the Structure pane, Designer applies the cardinality symbol to the appropriate end of the join, based on the cardinality proposed by the detection tool. 2. Using the Detect Cardinality button: a. Select the join. b. Click the Detect Cardinalities button. The automatic tool detects the cardinality of the join and applies the arity symbol to the appropriate end of the join. c. Check the arity symbols displayed between the tables to make sure that the one-to-many relationship proposed makes logical sense. d. Edit the cardinality proposed in the Edit Join dialog box if necessary. Building the Universe Structure Learner s Guide 71

84 Detect cardinality for all joins You can use the Designer feature Detect Cardinalities to automatically detect all joins in the schema. When using automatic cardinality detection, cardinalities are implemented automatically on detection. You should use automatic cardinality detection appropriately. It can be very useful to quickly get all the cardinalities detected in the schema, however, there are a number of structural problems inherent in many relational databases which can lead to incorrect cardinality detection. To detect cardinality for all joins You can also detect cardinality all at the same time, although this is not a recommended procedure to ensure accurate results. 1. Click the Structure pane background to ensure no join is selected. 2. Click the Check Cardinality button on the toolbar. Note: Cardinality is detected by automatically running three subsequent queries at the target database per join. You are therefore advised to avoid automatic detection of cardinalities on large databases. Use the manual method whenever cardinality is known. A message appears. Designer requests confirmation because executing the detection tool takes a long time if it is being applied to a large database. 3. If you are sure you want to use the automatic detection tool, click OK to detect the cardinalities. The system inserts the cardinality symbols on the many ends of the joins. 72 Universe Design Learner s Guide

85 Designer offers yet another method for detecting cardinalities automatically: 1. Select Tools Options from the menu bar. 2. Click the Database tab. 3. Select the Detect cardinalities in joins check box. 4. Click OK. Best practice for setting join cardinality As mentioned previously, there are three reasons why using the automatic detection tool to set join cardinalities is not recommended: Cardinality is based on logic. It is logical that every country has more than one region; it is not logical that a region may have more than one country. The automatic detection tool uses physical cardinality, and runs a physical count on the values in both columns being joined. You may get incorrect results if the physical count does not return the same result as a logical analysis of the data. The algorithm used by the automatic detection tool assumes that you have sufficient quantity of data in both tables to be representative in ratio to the database in a live environment. If you are designing against a test database, for example, with only a representative sampling of data, you could receive an incorrect answer because the tool runs a physical count. The automatic detection tool runs three subsequent queries against the target database per join. You are, therefore, advised to avoid automatic detection of cardinalities on large databases. Building the Universe Structure Learner s Guide 73

86 Join types Join Type Equi-join (default) (includes the complex equi-join) Outer join Theta join (conditional join) Shortcut join Self-restricting join Description 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. You can also create complex equi-joins, where one join links multiple columns between two tables. Equi-join is the join type created by default between two tables. Link two tables, one of which has rows that may not match those in the common column of the other table. Link tables based on a relationship other than equality between two columns, as in for example, a BETWEEN join. Join providing an alternate 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. Single-table join used to set a restriction on the table. Equi-joins An equi-join is a restriction that conforms to the syntax set out below: Table1.column_a = Table2.column_a An equi-join is a join based on column values between two tables. In a normalized database, the columns used in an equi-join are often the primary key from one table and the foreign key in the other. A primary key of a relational table uniquely identifies each record in the table. Primary keys may consist of a single attribute or multiple attributes in combination. A foreign key is a field in a relational table that matches the primary key column of another table. When a SELECT statement is run, the SELECT and FROM clauses are now properly defined and prevent a Cartesian product. 74 Universe Design Learner s Guide

87 Outer joins An outer join is a join that links two tables, one of which has rows that may not match those in the common column of the other table. You define an outer join by specifying which table is the outer table in the original equi-join. The outer table contains the column for which you want to return all values, even if they are unmatched. You specify the outer table from the Edit Join dialog box for the selected join. For instance, the example illustrated above shows the Country and Region tables from a database. Note that there are three different values in the primary key of the Country table and only two distinct values in the corresponding foreign key of the Region table. If you were to apply an equi-join, the resultset of a query would only show information on US and UK. However, you may wish to show all three countries irrespective of equivalent foreign key values in the Region table. To achieve this, use an outer join. In specifying an outer join in a standard SQL SELECT statement, you are required to identify which of the two tables is the outer. Using straight SQL (as opposed to generating it using a universe), the problem is that different RDBMS define outer differently and the syntax of the statement also differs. For example, depending on the underlying RDBMS, the outer join may be on the left or right. Building the Universe Structure Learner s Guide 75

88 In a universe, the outer join is always placed on the table that contains all the data. That is, on Country in the example above. To do this, place a check against that table in the Edit Join dialog box. Tip: A good way to find out where to place your outer join is by reading the description that shows up in the Cardinality zone. If you select the outer join check box for Country the description reads: Each Country has ZERO or more Regions, AND each Region has one and only one Country. When you check the outer join box for the Country table, you will retrieve all countries whether they have a region or not. Once this is done, the correct outer join is inferred when used in the generated query, and the syntax is correctly inferred for the appropriate RDBMS (assuming you have the correct SQL inference driver). An outer join is shown by a small circle on the join line in the universe structure at the end that points to the table that may have missing values. Best Practice with Outer Joins It is recommended that outer joins be placed at the end of the flow of data, otherwise ambiguous outer join errors may occur. Potentially, this could cause the SQL to try to match on the equality of a NULL value, which it cannot do. If you do place outer joins in the middle of a table path, the subsequent joins in the path may also have to be made outer to avoid errors. 76 Universe Design Learner s Guide

89 Always remember that outer joins may cause the query to run slower than a query with no outer joins. This problem can be resolved by using aliases and aggregate aware. Theta joins A theta join is a between-type join that links tables based on a relationship other than equality between two columns. It is used to demonstrate ranges, such as start date and end date, or minimum and maximum. A theta join can use any operator other than the equal operator. For instance, there is a table in the Motors database called Sales_Price_Range. This contains a number of rows defining fixed price ranges by which you may wish to analyze data as illustrated above. To do this, the table needs to be included in the universe structure and a join set. The obvious table to join it to is the Model table which includes the price of a model. However, there is no common column between the Sales_Price_Range and Model tables so an equi-join cannot be used. Instead you need to infer that a join exists where the value in a row of the Model_Price column in the Model table is between the values in a row for the Price_Range_Min and Price_Range_Max columns of the Sales_Price_Range table. To create a theta join To create a theta join using range columns: 1. Click the Insert Join button, or select Insert Join. The Edit Join dialog box appears. 2. Select a table from the Table1 drop-down list. The columns for the selected table appear in the list under the table name. 3. Click the column you want to join. 4. Select the a table from the Table2 drop-down list. Building the Universe Structure Learner s Guide 77

90 The columns for the selected table appear in the list under the table name. 5. Press and hold down the Ctrl key and click two columns from the Table2 column list box. Note: The operand changes to Between automatically, and indicates that the join expression is dynamically built as a Between syntax. 6. Click the Parse button to test for the validity of the join. If you receive an error message, check to see that you have correctly selected the columns. 7. Set the correct cardinality. 8. Click OK. The theta join now appears between the two selected tables. Shortcut joins A common use of shortcut joins is to link a shared lookup table to another table further along a join path. The join path is comprised of several different tables in the same context. A shortcut join is a join that provides an alternate path between two tables. It improves the performance of a query by not taking into account intermediate tables, and shortening a normally longer join path. In such a case, the shortcut join is only effective when the value being looked up has been denormalized to lower levels in a hierarchy of tables so the same value exists at all the levels being joined. 78 Universe Design Learner s Guide

91 In the Motors sample database you can apply a shortcut join from the Country table to the Client table, bypassing the Region table. As there is already a join between Country and Region, adding a new join between Country and Client will effectively create a loop. You can avoid and solve this loop by using a shortcut join. To create a shortcut join 1. Identify the two tables in a join path that can be linked directly. 2. Create a join between the two tables. 3. Double-click the new join. The Edit Join dialog box appears. 4. Set the correct cardinality. 5. Select the Shortcut Join option. Note: Note that this will not change anything in the operands or the expression field. 6. Click OK. The shortcut join now appears as a dotted line between the two selected tables. Self-restricting joins A self-restricting join is not really a join at all, but a self-restriction on a single table, usually a transaction table. You can use a self-restricting join to restrict the results returned by a table using a fixed value. Building the Universe Structure Learner s Guide 79

92 The table in the example above contains rows of data for cars both sold and rented. The sale type column is used as a flag to indicate the type of transaction. Without the self-restricting join, the results set of the query would produce rows where the sale type column is equal to either car sales ('S') or car rental ('R'). With the self-restricting join expression set to sale type equal to S, any object based on the table or joins passing through that table would produce query results covering only car sales. To create a self-restricting join 1. Use one of the following methods to insert a join: Click on the Insert Join button. Select Insert Join. The Edit Join dialog box appears. 2. Select the table from the Table1 drop-down list. Select the table that you want to set the self restricting join against from the Table1 dropdown list box. The columns for the selected table appear in the list under the table name. 3. Click the column that you want to use to define the restriction from the column drop-down list box. 4. From the Table2 drop-down list, select the same table that you selected from the Table1 drop-down list box. 5. Click the same column that you selected in the Table1 column list box. The expression for the join appears in the Expression text box. 6. Replace the operand value in the join expression with the restriction value that you want to set on the join column. For example, if you want to restrict the returned values from the sale type column to car sales values only, you replace SALE_TYPE after the = sign with 'S' as shown below: Tip: This can also be done directly in the Expression field. 80 Universe Design Learner s Guide

93 Note: It is recommend that you set the cardinality of a self-restricting join to 1:1. Otherwise, when running detect contexts, you will get an error that not all cardinalities have been detected. 7. Click OK The self-restricting join now appears as an unconnected join line. You can view the join expression underlying a join line or all the join expressions for a table using List Mode as well as the Edit Joins dialog box. List Mode You can use List Mode to list the tables, joins, and contexts used in the active universe. In List Mode, Designer adds three panes above the display of the Structure pane; tables, joins, and Building the Universe Structure Learner s Guide 81

94 contexts. You can view the join expression underlying a join line or all join expressions for a table using List Mode as well as the Edit Joins dialog box. To use List Mode 1. Click the View List Mode button. After List Mode opens, you can view tables and join information and expressions in various ways. For example: 2. Click a join in the graphical Structure pane. The expression for the join is highlighted in the Joins pane in the List Mode. 3. Click a table in the Tables pane of List Mode, and click the arrow pointing to the Joins pane. Only the joins for the selected table are shown in the Joins pane. 4. Clear the highlighted arrow to view all the joins and tables again. 5. Click the View List Mode button to return to normal view. Note: Make sure you clear any arrows in List Mode before returning to normal view. The restricted view of tables could interfere with operations that you perform in normal view, such as detecting contexts. 82 Universe Design Learner s Guide

95 Checking integrity Use the Check Integrity option to detect any errors in the structure and joins of a universe. Be careful of checking cardinality automatically for all the reasons mentioned previously. As a general rule, never select the Check Cardinalities check box when you are checking the integrity of your universe. To check the integrity of a universe 1. Click the Check Integrity button. The Integrity Check dialog box displays: 2. Select check boxes for components to be verified. 3. Clear check boxes for components not to be verified 4. Click OK. Designer checks the universe and displays the Integrity Check Results dialog box. If there are no errors, click OK. Otherwise, you need to return to your Structure pane and correct any errors as indicated in the Integrity Check Results dialog box. Note: Some divergences in integrity results are acceptable. Activity: Defining joins in a universe Objective Insert joins between tables in the Motors universe and set cardinalities. Instructions 1. Insert the following equi-join using the drag-and-drop technique: Building the Universe Structure Learner s Guide 83

96 COUNTRY.COUNTRY_ID to REGION.COUNTRY_ID 2. Set the cardinality for the join manually in the Edit Join dialog box. 3. Insert the following equi-join using the Edit Join dialog box and set the cardinality. REGION.REGION_ID to CLIENT.REGION_ID 4. Insert the following theta join and set cardinality. MODEL.MODEL_PRICE BETWEEN SALE_PRICE_RANGE.PRICE_RANGE_MIN AND SALE_PRICE_RANGE.PRICE_RANGE_MAX 5. Insert the following self-restricting join and set cardinality. SALE.SALE_TYPE ='S' 6. Check integrity for: Universe structure and joins 7. Notice the divergences found in the integrity check of the Motors universe. This is the result of having un-joined tables. 84 Universe Design Learner s Guide

97 8. Check that the following joins and cardinalities are included in the universe structure. If not, add the remaining joins and cardinalities as specified in the table below: Joins Type Cardinality COUNTRY.COUNTRY_ID = REGION.COUNTRY_ID Equi 1:N REGION.REGION_ID = CLIENT.REGION_ID Equi 1:N MODEL.MODEL_PRICE BETWEEN SALE_PRICE_RANGE.PRICE_RANGE_MIN AND SALE_PRICE_RANGE.PRICE_RANGE_MAX Theta N:1 SALE.SALE_TYPE ='S' Self 1:N CLIENT.CLIENT_ID = SALE.CLIENT_ID Equi 1:N SHOWROOM.SHOWROOM_ID = SALE.SHOWROOM_ID Equi 1:N SALE_MODEL.MODEL_ID = MODEL.MODEL_ID Equi N:1 MODEL.STYLE_ID = STYLE.STYLE_ID Equi N:1 MODEL.MAKER_ID = MAKER.MAKER_ID Equi N:1 SALE_MODEL.COLOUR_ID = COLOUR.COLOUR_ID Equi N:1 SALE.SALE_DATE BETWEEN FINANCE_PERIOD.FP_START AND FINANCE_PERIOD.FP_END Theta N:1 SALE.SALE_ID = SALE_MODEL.SALE_ID Equi 1:N 9. Save the changes to the universe. Building the Universe Structure Learner s Guide 85

98 Quiz: Building the universe structure 1. A schema contains two elements. What are they? 2. What are three reasons why using the automatic detection routine for setting join cardinalities is not recommended? 3. What type of join is created by default between two tables? 86 Universe Design Learner s Guide

99 Lesson summary After completing this lesson, you are now able to: Populate the universe structure Define joins in a universe Building the Universe Structure-Learner's Guide 87

100 88 Universe Design-Learner's Guide

101 Lesson 4 Creating Dimension Objects Lesson introduction This lesson describes how you can create classes and objects that are used by end users to run queries and create reports. After completing this lesson, you will be able to: Describe classes and objects Create classes and objects Creating Dimension Objects Learner s Guide 89

102 Classes and objects Because universes are made up of objects and classes, it is important to understand exactly how each of these elements is used. After completing this unit, you will be able to: Explain what universe objects are Explain what universe classes are Classes Within a universe, objects are grouped into classes. This is done to provide a structure for the universe and makes it easier for users to locate particular objects. The strategy most often employed is to group related dimension and detail objects into one class and place measure objects into a unique and single-measures class. This strategy can be extended by introducing subclasses to break down the objects into further subsets. Each object in a universe must be contained within a class. You can create new classes and edit the properties of existing classes. Classes are represented as folders on a tree hierarchy in the Universe pane. In Universe Designer, you can qualify an object as being one of three types: Object qualification Examples Description Dimension Focus of analysis in a query. A dimension maps to one or more columns or functions in the database that are key to a query. Detail Provides descriptive data about a dimension. A detail is always attached to a dimension. It maps to one or more columns or functions in the database that provide detailed information related to a dimension. 90 Universe Design Learner s Guide

103 Object qualification Examples Description Measure Contains aggregate functions that map to statistics in the database. These are the metrics by which you want to compare dimensions. Dimension objects, where possible, tend to be organized hierarchically within a class. This is important if you intend to make use of default hierarchies for drilling. Detail objects are organized below their associated dimension objects. Note: Detail objects cannot be included in a drill path. Measure objects may be grouped in a separate class. This makes them easier for the user to find and also emphasizes the fact that they can be used with any dimension or detail object. Note: Only dimension objects can be merged to synchronize queries from multiple data sources in end-user querying tools. Objects In Business Objects products, an object is a named component in a universe that represents a column or function in a database. In Universe Designer, objects appear as icons in the Universe pane. Each object represents a meaningful entity, fact, or calculation used in an end user s business environment. The objects that you create in the Universe pane in Universe Designer are the objects that end users see and use in the Business Objects end-user querying tools. For example, in the Web Intelligence Rich Client Query Panel, users drag objects from the Data tab into the Result Objects pane to run queries and create reports that display the data returned by the query. Each object maps to a column or function in the target database, and when an object is selected in the Query Panel, the object infers a SELECT statement. When multiple objects are combined, Creating Dimension Objects Learner s Guide 91

104 a SELECT statement is run on the database which includes the SQL inferred by each object and a default WHERE clause. As a universe designer, you use Universe Designer to create the objects that end users select to build and run their queries. You can also create objects for use only in Universe Designer, so that they are hidden in the Business Objects end-user querying tools. 92 Universe Design Learner s Guide

105 Creating classes and objects After defining classes and objects, the next step is to understand how to employ these elements. After completing this unit, you will be able to: Create a class Create objects Create classes and objects automatically Create classes and objects by copy and paste from another universe Edit object parameters Check integrity Test the objects in Web Intelligence Rich Client Creating classes There are two ways to create a class in the Universe pane: Manually defining a class. Automatically by dragging a table from the Structure pane into the Universe pane. To create a class 1. Click the existing class below which you want the new class to appear. Note: If this is the first class you are creating, ignore this step. Note: If you create a class when an object within a class is highlighted, you will create a subclass within that class. 2. There are three ways you can insert a class: Click the Insert Class button from the Editing toolbar. Select Insert Class. Right-click in the Universe pane and choose Class from the right-click menu. 3. The Edit Properties dialog box displays. 4. In the Class Name field, enter a name. 5. In the Description field, enter a description of the class content. Use business language that is meaningful to the users in your description for when they review it. Avoid technical database language. Creating Dimension Objects Learner s Guide 93

106 6. Click OK. To manually create an object 1. Click the class in which you want the new object to be placed. 2. There are three ways you can insert an object: Click the Insert Object button from the Editing toolbar. Select Insert Object from the menu bar. Right-click the class and choose Object from the right-click menu. The Edit Properties dialog box for the object appears. 3. In the Definition tab. 94 Universe Design Learner s Guide

107 Ensure that object names are always expressed in the end user business vocabulary. This name may be different from the actual column names that the object is associated with in the database schema. 4. Type a SELECT statement in the Select box, or click the >> button to use the SQL editor. 5. Click the Properties tab and select object properties. 6. Click OK. Automatically creating classes and objects from a table You can also create classes and objects simply by dragging the entire table from the Structure pane into the Universe pane in Universe Designer. This is particularly useful if you are sure that you want all the columns in the table to correspond to objects in the universe. Note: The class is automatically populated with a dimension object for every column in the table. It is not advisable to do this because you are creating a universe based on the database structure, not on the requirements of the users. You can create an object automatically by selecting a column in a table in the Structure pane and dragging it to the Universe pane. An object is created under the nearest class to the point where you drop the column. The default name for the object is the column name. You should edit the new object properties to ensure that it is appropriately named, and is relevant to end-user needs. Whenever you create an object automatically, edit the properties of the object to: Change the name where appropriate. Enter a description. Change the object qualification from the default where necessary. Alter or remove the associated list of values settings where appropriate. Change other settings as required. To automatically create an object from a column 1. Click a table column in the Structure pane. 2. Drag the column across to the Universe pane and drop the table at the desired position in the class hierarchy. The column must be dropped under an existing class. A new object appears in the hierarchy. Defining a new object as a detail object The Properties tab in the Edit Properties dialog box allows you to define the object qualification. An object can be qualified as a dimension, detail, or measure object. Creating Dimension Objects Learner s Guide 95

108 A detail object provides descriptive data about a dimension, and is always attached to a dimension. It maps to one or more columns or functions in the database that provide detailed information related to a dimension. To define an object as a detail object 1. Double-click an object. The Edit Properties dialog box for the object appears. 2. Click the Properties tab. The Properties tab of the Edit Properties dialog box appears. 3. In the Qualification zone, select the Detail button. The Associated Dimension field appears in the Qualification zone. 4. Click the Associated Dimension field, and from the drop-down list of available dimension objects, select the one with which this detail object is to be associated. 5. Click OK to confirm the change. Working with classes and subclasses A subclass is a class within a class. You can use subclasses to help organize groups of objects that are related. A subclass can itself contain other subclasses or objects. Note: It is recommended that you do not create too many levels of subclasses (more than three). Too many levels make it difficult for users to find the objects they need. 96 Universe Design Learner s Guide

109 To create a subclass 1. Right-click the class in which you want to create a subclass. The drop-down menu appears. 2. Choose Subclass. The Edit Properties dialog box displays. 3. In the Class Name field enter the name of the subclass. 4. Click OK. The Universe pane should look similar to: To delete a class or a subclass 1. There are two ways to delete a class, or subclass: Click the class, or subclass that requires deletion. Press the Delete key. Right-click the selected class, or subclass. Select the Clear option from the drop-down menu. Editing the object properties The following example shows the properties of the dimension object, called Client Name. Creating Dimension Objects Learner s Guide 97

110 As the object is currently defined, there is no SELECT statement defined to reference the Client table. You need to edit the definition of the SELECT statement so the Client Name object returns the complete client name using the appropriate columns from the Client table. Note: The example above shows a concatenation of two columns. Depending on the RDBMS used the syntax can vary. Consult the documentation provided by your database vendor to see what types of concatenation functions are supported. 98 Universe Design Learner s Guide

111 To edit the object definition 1. Double-click the object that you want to edit. 2. In the Definition tab, type in the Name field if you want to edit the object name. 3. Click the Type arrow, and from the drop-down list, select the appropriate data type for the database column, or columns that the object references. 4. Click the Description text box and type help text for the end user. This text appears in Business Objects end-user querying tools when a user selects the object to build a query. The text describes the data returned when the user adds this object to a query. 5. Click the Select text box and enter the SELECT statement that will be inferred when a user builds a query using this object. This can be done in one of two ways: Type the SELECT syntax in the Select field to define the columns that will be referenced. Click the >> button to open the Edit Select Statement dialog box as displayed below. The Edit Select Statement dialog box appears. It is normally best to use the latter method because it enables you to specify most of the SELECT syntax from pick lists in the lower half of the screen by double-clicking the item required. This minimizes typing and averts syntax errors due to typing mistakes. 6. Create the SELECT statement so the object references the appropriate table columns. Creating Dimension Objects Learner s Guide 99

112 Note: You can use the fields below the text box to select the columns, operators or functions you need to use to enter the required SQL syntax. 7. Click the Parse button to validate the statement syntax. 8. Click OK to close the Edit Select Statement dialog box. The Edit Select Statement dialog box closes and the Definition tab of the Edit Properties dialog box displays the SQL statement in the Select text box. Edit Properties: Properties The Properties tab in the Edit Properties dialog box allows users to: 1. Select one of the object types in the Qualification zone. Note: By default, the object type selected will be either a dimension or measure dependent on the data type chosen on the Definitions tab. Dimension=Character, Date or Number Measure=Selected by default when there is an aggregate function in the SELECT clause Note: The Detail qualification check box will be grayed out if no dimension objects exist to which to attach a detail object. 2. Select the appropriate options in the Associate a List of Values zone. What is a list of values? When you create an object, Universe Designer automatically associates a list of values (LOV) with the object. The LOV is not created until a user or the universe designer chooses to display a list of values for the object in the Query Panel. A SELECT Distinct query is then run against the column or columns inferred by the object. The returned data is stored in a file with an.lov extension in the universe subfolder created under the same folder that stores the universe file. The.lov file is then used as the source for values for the list. This allows the SELECT Distinct query to be run only once for an object. When do you use a list of values? A list of values should only be used with an object if it will provide something useful for the user. LOVs are very useful where there is a limited set of distinct values for the database columns underlying the object. Note: If the object is likely to refer to a large number of distinct rows in the database, it is advisable not to associate an LOV or change its configuration to avoid performance issues. Setting LOV options In the Associate a List of Values zone, the Display button allows you to view all the values in the database returned by this object. 100 Universe Design Learner s Guide

113 To restrict the object so that some of the values are not returned when an end user uses this object in a query, you can click the Edit button to create a filter (or condition) in the Query Panel that appears. Edit Properties: Advanced The Advanced tab allows you to set the security access level of the object and how it can be used in a query or in a report. You can select a security level which restricts use of the object to users with the appropriate security level. In the Security Access Level zone you can assign the following security access levels: Public Controlled Restricted Confidential Private If you assign Public then all users can see and use the object. If you assign Restricted, then only users with the user profile of Restricted or higher can see and use the object. In the Can be used in zone, select one of the following options to define how this object can be used in a query: The Result check box - use this object to return results in a query. The Condition check box - use this object to apply a condition or query filter in a query. The Sort check box - specify the object in the ORDER BY clause of a SELECT statement. Creating Dimension Objects Learner s Guide 101

114 Note: This option can increase the processing speed of a query. However, in certain edited LOV situations, it is not useful to sort at query level because block-level sorting overrides any row order of data that is stored in the microcube. Edit Properties: Keys The Keys tab allows you to define index awareness for an object. Index awareness is the ability to take advantage of the indexes on key columns in the database to speed data retrieval. The objects that you create in Universe Designer are based on database columns that are meaningful to an end user. For example, a Customer object retrieves the field that contains the customer name. In this situation, the customer table typically has a primary key that is not meaningful to the end user, but which is very important for database performance. When you set up index awareness in Universe Designer, you tell Universe Designer which database columns are primary and foreign keys. This can have a dramatic effect on query performance. In the example below, primary and foreign keys have been defined on the Client Country object. The complete WHERE clause for the primary key is: COUNTRY.COUNTRY_ID = CLIENT.COUNTRY_ID If you then use Country and the Client Name object in a query, the query will not need to reference the Country table in the database; the Country data will be taken from the Client table directly. 102 Universe Design Learner s Guide

115 Edit Properties: Source Information For universes generated from Data Integrator, technical descriptions and formulas used to calculate target tables from source tables are displayed in this tab. You can specify the following types of information in the Source Information tab: Technical information: Technical descriptions that are available in universes generated from Data Integrator. Mapping information: The mapping applied within Data Integrator between the source tables and the target tables. The goal is not to provide the expression of the mapping, but to display it as a descriptive comment to inform the user of the source columns used in the object definition. Data Lineage information: List of source columns involved in a target column. This information facilitates the impact analysis through Data Integrator and Web Intelligence reports. It is possible to copy objects from one universe to another. This is useful if you want to create objects that are similar to those already existing in another universe. You can copy those objects or classes of objects and edit them as required. Note: When you copy an object from one universe into another, be sure to validate the object definition against the new universe structure and data source connection. Creating Dimension Objects Learner s Guide 103

116 Copying and pasting objects It is possible to copy objects from one universe to another. This is useful if you want to create objects that are similar to those already existing in another universe. You can copy those objects or classes of objects and edit them as required. Note: When you copy an object from one universe into another, be sure to validate the object definition against the new universe structure and data source connection. To copy and paste objects 1. Open the universe from where you want to copy objects. 2. Select the object(s) you want to copy. 3. Click copy from the standard toolbar. 4. Open the universe to which you want to copy the objects. 5. Click paste from the standard toolbar. Find and replace The Find and Replace functions can be very useful when editing. You can use the Find function to locate character strings in objects and their definitions. You can also use the Find function in conjunction with the Replace function to edit strings. To find a string 1. Ensure the Universe pane of the Universe Designer window is active. Note: If the Structure pane of the universe is active, the Find function searches for table names containing the specified string. 2. Click Find from the standard toolbar. The Find/Replace dialog box opens. 104 Universe Design Learner s Guide

117 3. Enter the character string for which to search. 4. Select the check box options as required. 5. Click Find Next. The appropriate object or part of the object definition will be displayed and the string will be highlighted. 6. To move to the next instance of the string, click Find Next or click the Find Next icon. To replace as you find 1. In the Find/Replace dialog box, select the Replace tab. 2. Enter the string to search for in the Find What field and the string with which it is to be substituted in the Replace field. 3. Select the check box as required. 4. Click Find Next. 5. Click Replace and then move to the next instance of the string by either clicking Find Next or the standard toolbar option. Checking object integrity Always check the integrity of your universe after defining classes and objects. Use the Check Integrity option to detect any errors in the SQL syntaxes used in the created objects. Note: Ensure that the Check Cardinalities box is cleared. With a large database, this will save time running the integrity check. To check object integrity 1. Click the Check Integrity button. Creating Dimension Objects Learner s Guide 105

118 The Integrity Check dialog box displays. 2. Select the Parse Objects check box. 3. Click OK. 4. Universe Designer checks the universe and displays the Integrity Check Results dialog box. 5. Identify the reason for any reported errors and resolve them. Viewing parent tables You can view the table in the Structure pane that is used in an object definition from the Universe pane. This can be useful to quickly identify a table used by an object when object names do not easily indicate a specific table. To view associated tables of an object 1. Right-click the object. 2. Select the View Associated Table option. The associated tables of the object will be highlighted in the Structure pane and the list mode display (if open). To view associated objects 1. Right-click any table. 2. Select the View Associated Objects option. 3. The associated objects of the selected table will be highlighted in the Universe pane. 106 Universe Design Learner s Guide

119 Testing objects As you create objects in the universe, test them in Business Objects end-user querying tools by building and running queries. There are three things you need to test: Do the objects exist? If not, you may have forgotten to save and export your universe since the object you are testing was created. Does the SQL appear correct? Are the results of the query correct? Remember that you must also test the joins already created in the structure. Activity: Creating and testing classes and objects Objective Create and test classes and objects. Instructions In this workshop you will create classes, subclasses and dimension and detail objects in the Motors universe and then test the universe s objects and joins. 1. Create the following class: Client 2. Create the following class and subclass: Car Sale Prices (subclass of Car) 3. Create a Client Name dimension object manually with the settings: Type = Character Description = Last name, First name SELECT = CLIENT.CLIENT_LASTNAME + ', ' + CLIENT.CLIENT_FIRSTNAME Associate an LOV 4. Create a Client ID detail object automatically with the settings: Type = Number Description = Unique Client ID Number SELECT = CLIENT.CLIENT_ID No Associated LOV 5. Check the integrity of the objects. 6. Create a Showroom class. Creating Dimension Objects Learner s Guide 107

120 7. Create objects for each of the classes as identified in the tables below. Some of the properties for each object have been specified for you. However, you will have to determine the data type, qualification, and whether or not an LOV should be associated with each object. 108 Universe Design-Learner's Guide

121 Car class Object Name SELECT Statement Object Description Maker MAKER.MAKER_NAME Car Manufacturer Category of Car Model STYLE.STYLE_NAME MODEL.MODEL_NAME +' ' + MODEL.MODEL_TRIM +' ' + MODEL.MODEL_ENGINE The style group into which a car fits (for example, coupe, 4x4) Model name, trim, and engine size Sale Prices class (a subclass of Car) Object Name Price Range Model Price SELECT Statement SALES_PRICE_RANGE.PRICE_RANGE MODEL.MODEL_PRICE Object Description Description of price range banding Manufacturer recommended retail price Showroom class Object Name Showroom Town SELECT Statement SHOWROOM.SHOWROOM_TOWN Object Description Town in which showroom exists Showroom SHOWROOM.SHOWROOM_NAME Name of showroom Showroom Address SHOWROOM.SHOWROOM_ADDRESS Address of showroom Client class Object Name Country Region Area Client Town SELECT Statement COUNTRY.COUNTRY_NAME REGION.REGION_NAME CLIENT.CLIENT_AREA CLIENT.CLIENT_TOWN Object Description Country in which client resides Region of country in which client resides Area of Region in which client resides (for example, county or state) Town or city in which client resides Creating Dimension Objects Learner s Guide 109

122 Object Name SELECT Statement Object Description Client Address CLIENT.CLIENT_ADDRESS Address of client Area Code CLIENT.CLIENT_AREA_CODE Postal or Zip Code Phone Number CLIENT.CLIENT_PHONE_NO Phone number of client Client ID CLIENT.CLIENT_ID Unique Client ID Number 8. Modify the properties of the following objects so that they are qualified as detail objects, and associated with the Client Name dimension object: Client Address Area Code Phone Number 9. Modify the properties of the Showroom Address object so that it is qualified as a detail object, and associated with the Showroom dimension object. 10. Create a class called Sales and two subclasses in the Sales class: Sales Details Sales Dates Sales Details class (a subclass of Sales) Object Name SELECT Statement Object Description Invoice ID Number SALE.SALE_ID Unique Invoice ID Number Sales Dates class (a subclass of Sales) Object Name SELECT Statement Object Description Sale Date SALE.SALE_DATE Date of sale 11. Drag the FINANCE_PERIOD table from the Structure pane and drop it in the Universe pane. Note: Delete the FP_Start and FP_End objects that are automatically created. 12. Edit the objects that have been created automatically in the new Finance class, according to the table below. 110 Universe Design Learner s Guide

123 Financial Period class Object Name SELECT Statement Object Description Financial Year FINANCE_PERIOD.FP_YEAR For example, FY03-04 Financial Quarter FINANCE_PERIOD.FP_QUARTER For example, Q1 Financial Month FINANCE_PERIOD.FP_MONTH For example, Month Make sure you have defined each object using the appropriate object type. The Universe pane in Universe Designer appears like this: 14. Save the universe. 15. Check the integrity of the objects, and make any alterations required. Note: Test the validity of the joins also. 16. Test the universe by building queries in Web Intelligence Rich Client using the new objects. Creating Dimension Objects Learner s Guide 111

124 17. Launch Web Intelligence Rich Client via Start Programs BusinessObjects XI 3.0 BusinessObjects Enterprise Web Intelligence Rich Client. 18. Log onto Web Intelligence Rich Client with the User name administrator. 19. Select the create a new document based on a data source icon. Select Browse for more data sources. 20. In the Data source selection menu select Universe, and click Next. 21. Select the Motors universe, and click OK. 22. Build a new query using the objects you have created. Drag and drop the objects into the Result Objects pane. 23. Click Run Query to view the final results displayed in the report. 112 Universe Design Learner s Guide

125 Quiz: Creating dimension objects 1. Which of the three types of objects contain aggregate functions that map to statistics in the database? 2. When you are testing objects, what are the three things for which you need to test? 3. If each object maps to a column or function in a target database, when used in a query, what kind of statement does the object infer? Creating Dimension Objects Learner s Guide 113

126 Lesson summary After completing this lesson, you are now able to: Define classes and objects Create classes and objects 114 Universe Design-Learner's Guide

127 Lesson 5 Creating Measure Objects Lesson introduction This lesson describes how to create measure objects and test that they produce the correct results when used in queries. After completing this lesson, you will be able to: Explain measure object concepts Create measure objects Create delegated measure objects Creating Measure Objects Learner s Guide 121

128 Measure object concepts After completing this unit, you will be able to: Define measure objects Determine levels of aggregation Defining measure objects A measure object returns numeric information. Measure objects are very flexible because they are semantically dynamic. This means that the values they return in a query will vary depending on the dimension and detail objects that are used with them. You can see from the illustration that two separate queries, using the same Sales Revenue measure object, but different dimension objects, results in the measure returning different values. You create a measure object by using an aggregate function in the SELECT definition of the object. The five basic aggregate functions are: Sum Count Average Maximum Minimum A measure object returns numeric data from the database that aggregates up or down according to the dimension objects in the query. The most regularly used aggregates are listed above. However, there are others that can be used. The full set of aggregate functions is held in the Number Functions pick list of the Edit Select Statement dialog box. How a measure infers SQL When a query uses a measure object with a dimension or detail object, the query definition automatically infers a GROUP BY clause in the SELECT statement. 116 Universe Design Learner s Guide

129 Inference of the GROUP BY clause is dependent on the SQL rule: When the SELECT clause line contains an aggregate, everything outside of that aggregate in the clause must also appear in the GROUP BY clause. That is why dimension and detail objects must not contain aggregates. Any dimension or detail that is used in the same query as a measure object will always be included in an inferred GROUP BY clause. When a query includes only a measure, the SQL inferred is the same as when the query uses a dimension object: The SELECT clause shows the object selected in the query with the syntax including the aggregate function. The FROM clause shows the tables involved in the measure object syntax. The WHERE clause identifies the joins among the tables involved. The query result shows one row of the total revenue value. In this example, the query includes only the Sales Revenue measure so the inference engine does not include a GROUP BY clause in the SQL statement. When a query uses at least one dimension or detail object and a measure, the inference engine includes a GROUP BY clause with all the objects except the measure in the SQL Statement: The SELECT clause shows the object(s) and measure selected in the query with the syntax including the aggregate function. The GROUP BY clause includes all the objects except the aggregate. In this example, the query includes the Sales Revenue measure and the Country object so the inferred SQL statement includes a GROUP BY clause with the Country. Creating Measure Objects Learner s Guide 117

130 In this example, the query includes two dimensions (Country and Region) so the inference engine includes both dimensions in the GROUP BY clause. As a result, the values returned for the Sales Revenue measure object are aggregated to a lower level, the Region. This mechanism in the inference engine allows the measure objects to adapt dynamically to other, associated objects. The Query Process How do the Business Objects end-user querying tools process the measure object in a query, and how do the values get projected? There are two levels of aggregation in the query process: Aggregation at SELECT level Aggregation at projection level 118 Universe Design Learner s Guide

131 Aggregation at SELECT level Aggregation at SELECT level occurs first in the query process: The user creates a query. Web Intelligence Rich Client defines the SQL from the query and sends a SELECT statement to the target database. The data is returned to the microcube. The first level of aggregation now takes place in the microcube. The results are projected in the query. The microcube projects the aggregated data onto the report, the SQL statement is inferred against the database, and the results are returned to the microcube. Aggregation at projection level When you run a query, the resultset of the SELECT statement is stored in the microcube. All data then held in the microcube is projected into a block (the table or chart in the report). Therefore, because data is projected from the lowest level held in the microcube, no projection aggregation takes place. Creating Measure Objects Learner s Guide 119

132 However, when you edit the table, for example, by removing a column, and therefore project only partial data from the microcube, aggregation is required to show measure values at a higher level. The data in the microcube remains unchanged. For instance, if you do not project the region data into the block, the four rows related to USA need to be reduced to one to show the overall Sales Revenue for that country. In this instance, a sum aggregation is required. When projecting all variables in the microcube, no aggregation takes place. When projecting only some variables from the microcube, aggregation occurs. Projection aggregation is separate from SELECT aggregation and depends on how you define the measure object properties when you create the measure object using Universe Designer. Setting selection and projection aggregates Statistically, only certain SELECT and projection aggregates are compatible. SELECT Aggregate Sum Count Average Maximum Minimum Recommended Projection Aggregate Sum Sum None Maximum Minimum For the reports to present statistically correct results for a measure object both at query and projection level, the SELECT and projection aggregates need to complement each other. However, as a universe designer, if you configure a measure differently, the Business Objects end-user querying tools will not stop you. Note: With the exception of Average, the correct projected aggregate is selected by default. When you set the SELECT syntax to Average, for example Avg(SALES.SALES_TOTAL), the projection aggregation for this object would automatically be placed as a SUM. This would need to be changed manually to NONE. 120 Universe Design Learner s Guide

133 Creating measure objects After completing this unit, you will be able to: Create measure objects Test measure objects in Web Intelligence Rich Client Measure objects You create measure objects in the same way that you create a dimension or detail object. They can be created using the automatic or manual method. It is recommended that you group measure objects together in separate classes from dimension and detail objects, if they are generic. In other words, if they can be used in the same query as any dimension and detail object in the universe, then they are considered generic, and you must group them in separate classes. If they are only compatible with certain objects, however, then you may want to place them in the same class as those objects, to indicate this fact to the report designers. It is important to remember the following when you create measure objects: In the Definition tab The Data Type field must be set to Number. The Select field must include an aggregate function. Tip: It is best to use the Select Edit dialog box to insert the SELECT clause content of a measure as you can then use the Function and Columns pick lists. Note: When an aggregate function is used in the Select Edit dialog box, the qualification is automatically set to Measure type. In the Properties tab The qualification must be set as a Measure type. In the Function field, make sure the function you use is compatible with the aggregate used in the SELECT statement. A measure object should not have a list of values associated with it. Therefore, the Associate a List of Values check box should be unchecked. Creating Measure Objects Learner s Guide 121

134 Testing measure objects When you test a measure, you must be far more rigorous in your checks than with a dimension or detail object. This is because you have to check that the values of the measure aggregate correctly both at SELECT and projection level. The three elements to testing a dimension or a detail object are: 1. Check that the objects exist. 2. Check the inferred SQL. 3. Check the query results. For measure objects, the additional elements are: Repeat with the other dimensions. Make a query with a minimum of two dimensions and a measure. To validate the accuracy of the measure aggregate, it is recommended that you test it with at least three separate queries. Testing measures at SELECT level To test the inferred SELECT statements for a measure object, you must make at least two separate queries using different dimension objects to produce different levels of aggregation. Three or more queries are preferable. In each instance, you must check the following: The inferred SQL of the query 122 Universe Design Learner s Guide

135 In particular, you should check the GROUP BY clause has been inferred correctly. Note: If it has not been inferred at all, it is likely that you have set a calculation and not an aggregate in the Select field of the measure object properties. The results of the query Check that the query produces the correct results. Testing measures at projection level To test for projected aggregation, you need to build a query containing at least two dimension objects, as well as the measure object you are testing. This allows you to project from other than the lowest level of data held in the microcube and therefore test aggregation. Activity: Creating and testing measure objects Objective Create and test measure objects. Instructions 1. Create the following subclass in the Sales class: Sales Figures 2. Create a Sales Revenue measure object with the settings: Type = Number Description = Total Sale Invoice Revenue Select statement = SUM(SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE * ((100 - SALE.SALE_SALE_DISCOUNT) / 100)) Function = SUM No associated LOV Creating Measure Objects Learner s Guide 123

136 3. Save and export the universe. This allows you to test the Sales Revenue object in Web Intelligence Rich Client. 4. Log onto Web Intelligence Rich Client. You will test the Sales Revenue object by running three queries. 5. Create a new query based on the universe you just exported, containing the Sales Revenue object. Note the value returned. 6. Test the Sales Revenue measure object by creating a second query, using the following steps: a. Edit the query created in the previous step, and click Add Query. b. Select the Motors.unv. c. Create a new query with Country and Sales Revenue. Check the SQL and note the GROUP BY clause. It should contain the SQL for the Country object. d. Click Run Queries. Note: You will be prompted to select a way to display the new query. You can leave the default option to add a new tab to the report or you can select the option to display the table in the current report. e. Apply a SUM calculation to the Sales Revenue column in the new projected block. Does the sum match the value shown in the first table? Note the value of the Sales Revenue in a row of the block (for example, USA). 7. Test the Sales Revenue measure object by creating a third query, using the following steps: a. Edit the second query and then click Add Query. b. Create a new query with Country, Region, and Sales Revenue. c. Check the SQL and note the GROUP BY clause. It should now contain the SQL for the Country and Region objects. Click Run Queries. d. Apply a break to the Country column and apply the sum calculation to the Sales Revenue column of the new projected block. Does the Country group sum match the value of the noted block row in the second table (for example, USA)? e. Edit the query. Change the projection to the block from the microcube by removing the Region column from the block. Does it aggregate to Country level correctly? f. Edit the query again. Change the projection to the block from the microcube by removing the Country column from the block. Does it aggregate to the total Sales Revenue level correctly? g. Edit the query again. Add the Showroom and Maker objects. h. Using drag and drop, insert two new tables, one to show Showroom and Sales Revenue, and the other to show Maker and Sales Revenue, and apply a sum to both tables. Note the total values remain the same. The final version of the report should look similar to this: 124 Universe Design Learner s Guide

137 8. In Universe Designer, create the following measure objects in the Sales Figures subclass and test them. The SQL code for the SELECT properties of each object has been specified for you. However, you will have to determine the appropriate projection function aggregate. Object Name Select Statement Object Description Cost of Car Sales Number of Cars Sold SUM(SALE_MODEL.SALE_QTY * MODEL.MODEL_COST) SUM(SALE_MODEL.SALE_QTY) Total Cost of Car Sales Total Number of Cars Sold 9. Create the measure objects listed below. In the Car class and Sale Prices subclass: Lowest Priced Value based on Manufacturers recommended retail price. In the Car class and Sale Prices subclass : Highest Priced Value based on Manufacturers recommended retail price. In the Client class: Number of Clients. 10. Save and export the universe. 11. Test the new objects in Web Intelligence Rich Client. Creating Measure Objects Learner s Guide 125

138 Delegated Measures The XI 3.0 release of Universe Designer allows designers to create measures whose calculation is delegated to the database. These are called "delegated smart measures". After completing this unit, you will be able to: Explain what the delegated measure is and how it works Understand how you benefit from using delegated measures Know how to use delegated measures appropriately Apply best practices when using delegated measures What is a delegated measure? A delegated measure is a measure that delegates its aggregation calculation to the database. The universe designer defines a delegated measure in the universe to make it available to report users for ad hoc reporting or for viewing reports built on that universe. A universe designer can create a delegated measure when conventional Web Intelligence or Web Intelligence Rich Client aggregation does not provide an accurate result for the measure, such as for: Complex averages, such as Weighted averages (an average of a percentage). Ratios. Other measures that do not aggregate along all the dimensions in a report. OLAP sources where measure aggregations are already available in the OLAP cube. The delegated measure is then available to report designers in Web Intelligence and Web Intelligence Rich Client. Delegated measures are available for all relational and OLAP data sources. The benefits of delegated measure The delegated measure represents an extension of Web Intelligence and Web Intelligence Rich Client calculations by supporting aggregation within the database and makes non-additive measures available within the universe. You benefit from delegated measures because they: Increase Web Intelligence and Web Intelligence Rich Client querying efficiency. Make non-additive measures available within the universe. Use database-specific syntax to improve performance and provide optimization on the internal architecture of all vendors. Extend support of calculations beyond Web Intelligence and Web Intelligence Rich Client documents. 126 Universe Design Learner s Guide

139 How does the delegated measure work? By default, Web Intelligence and Web Intelligence Rich Client calculate measures based on the objects used within the query. The dimensions used in the query are called a grouping set. The delegated measure calculates the aggregation of the measure for any subset of dimensions required in the report. For example, a query that retrieves the dimensions Country, Region, Maker, Year, Number of Cars Sold and Average Sales Total would, by default, calculate the Number of Cars Sold and Average Sales Total for that grouping set. However, when you format your report, if you want to present the Number of Cars Sold and Average Sales Total for Region and Maker, Web Intelligence does not know how to calculate the correct Average Sales Total for these smaller entities. The delegated measure, on the other hand, calculates the measures for all subsets of the dimensions in the report. Thus, it would calculate Number of Cars Sold and Average Sales Total per: Country Country and Year Country, Region, and Year Country, Region, Maker, and Year What happens when changes are made to the report? When the report changes, the delegated measure updates the grouping set accordingly. When users add to the grouping set, the value #TOREFRESH appears to indicate that the value is missing and they need to refresh the report to see the measure. When users save their report, it removes unused grouping sets. Using a delegated measure as a weighted average A report designer wants to calculate the average sales total per region, and also for all regions. The universe designer has created a measure called Average Sales Total that calculates the average of the sales totals. When the user runs this in a Web Intelligence Rich Client query, together with Region, the average sales total per each region is calculated. The user then wants to calculate the average sales total level for all regions, and adds an average calculation on the Average Sales Total column. Creating Measure Objects Learner s Guide 127

140 A new row appears at the bottom of the table and this row displays the average sales total for all regions. This appears accurate, but it is not. Web Intelligence Rich Client is adding up the values shown in the Average Sales Total column and then dividing them up by six, since there are six regions available. The values in the Average Sales Total column are already calculated averages, so Web Intelligence is actually calculating the average of averages. What is required here is a weighted average, as some regions have more car sales revenue returns than others. The sales total value returned by those regions with more sales returns needs to count more heavily than those regions with fewer returns. When adding the Number of Cars sold figure to the query, you see here that the number of cars sold per region varies considerably. Sixty-eight cars were sold in the West Coast, while only thirteen in the East Coast. When Web Intelligence Rich Client calculates the overall average sales total, it cannot take into account the fact that the West Coast should have more weight in the calculation of the average. 128 Universe Design Learner s Guide

141 Web Intelligence Rich Client does not have access to the detailed data, just to the regional average value, returned by the Average Sales Total measure. To calculate a weighted average, you need to create a delegated measure in the universe, which will delegate this calculation to the database. To do this, you must modify the universe using BusinessObjects Universe Designer. In properties of the Average Sale Total measure, setting the function to Database delegated will delegate this calculation to the database and effectively calculate a weighted average. Running the same query using the Average Sales Total measure with the function set to Database delegated, will result in the correct average total: Creating Measure Objects Learner s Guide 129

142 Best practices for using delegated measures Keep in mind the following best practices for effective use of delegated measures: Use a delegated measure when report users manipulate the measures in reports. When they only need to refresh, view and print their reports, the calculation may be simpler to perform in the report. Use a delegated measure to replace multiple query aggregates. Use a delegated measure on calculations that could give inaccurate results when calculated in the report (such as a complex average). Use a delegated measure for measures requiring division. This ensures report designers can quickly recognize a delegated measure when they glide their mouse over it in a query, when you create the delegated measure in the universe make sure that in the Edit Properties dialog box for the measure, on the Definition tab, you enter identifying text in the Description field. Activity: Creating and using a delegated measure Objectives Create a delegated measure in Universe Designer. Use a delegated measure in Web Intelligence Rich Client. Instructions 1. In Universe Designer, open the Motors universe. 2. In the Sales Figures class, create a new measure called Average Sales Total : SELECT syntax: avg(sale.sales_total) In the Properties tab, set the aggregation function to Average. 3. Save the universe and log onto Web Intelligence Rich Client. 4. Create a new query using the Region and the Average Sales Total objects. Click Run Query. 5. Select the Average Sales Total column and select the average function from the toolbar. Activate the sum drop-down list, and select average. Is the result correct? 6. Return to Universe Designer and copy the Average Sales Total and paste it in the same class. Name the copied object Delegated Sales Total Average. 7. In the Properties tab, set the aggregation function to Database delegated. Save the universe. 8. Return to Web Intelligence Rich Client. 9. Add Region, the Average Sales Total, and the Delegated Sales Total Average objects to the Query Panel. Click Run Query. 130 Universe Design Learner s Guide

143 10. Add an average to the Average Sales Total column, as done in step Drag the Delegated Sales Total measure object from the Data tab and position it in the cell at the bottom of the Delegated Sales Total column. Drop the Delegated Sales Total measure object in the cell at the bottom of this column. Note that the cell now displays a text string: #TOREFRESH. This indicates that the average will not be calculated by Web Intelligence Rich Client, but it must be calculated by the database. You need to refresh the document to retrieve the calculated results from the database. 12. Click Refresh Data. You see here that the average calculated by the database does not return the same value as the value calculated by Web Intelligence Rich Client. Because the database has access to the detailed data concerning all satisfaction levels in these regions, the result is based on a weighted average. The database is able to take into account the difference in numbers of customers per region. Creating Measure Objects Learner s Guide 131

144 Quiz: Creating measure objects 1. Measure objects are very flexible because they are semantically dynamic. What does this mean? 2. Measure objects are created in the same way as a dimension or detail object. However, the object properties differ in two ways. What are they? 132 Universe Design Learner s Guide

145 Lesson summary After completing this lesson, you are now able to: Explain measure object concepts Create measure objects Create delegated measure objects Creating Measure Objects Learner s Guide 133

146 134 Universe Design-Learner's Guide

147 Lesson 6 Using Lists of Values Lesson introduction This lesson explains how you can add, modify, or remove a list of values (LOV) for an object. It also introduces how to create a cascading list of values in Designer and how to use them in Web Intelligence Rich Client. After completing this lesson, you will be able to: Create a list of values Work with LOVs in Universe Designer Create a cascading LOV Using Lists of Values Learner s Guide 135

148 Creating a list of values A list of values is a list that contains the distinct data values associated with an object. After completing this unit, you will be able to: Explain what a list of values (LOV) is Use a list of values in Web Intelligence Rich Client What is a list of values? When you create a dimension or detail object in Universe Designer, it is automatically assigned an associated list of values, or LOV. This list does not physically exist when you create an object, but by default the object has the ability to query the database to return a list of its values when used to build a query. Lists of values are based on the results of a SELECT Distinct query on the column or columns held in the Select statement in the object s Edit Properties dialog box. If you select the Export with Universe option in the Associate a List of Values pane of the Properties tab, the list of values is converted to XML when you export the universe, and then stored in a.unw file in the Central Management Server (CMS). The first time a list of values is used to filter results returned by a query, the LOV is stored in an encrypted file on the local file server in the sessions folder. As you create objects in the universe, use the following questions as a guide to help you decide whether to associate an LOV to an object or not: Do the users need to see a list of values for this object? Are they likely to want to apply query filters or conditions on this object? Is the data dynamic or static? Will the data be updated frequently? How long will it take to run the SELECT Distinct query? What does the list need to include? Using a list of values (LOV) When users build queries, they can define query filters to restrict the amount of data returned by a specific object used in the query. To do this, they view the list of values for that object in order to specify which value(s) will be returned. The LOV for the object appears in the Filter or Editor, which helps the user choose the terms for the filter. For example, a manufacturer object with the SELECT clause for the manufacturer name column will have an LOV that contains all the available distinct car manufacturer s names. A user who wants to limit the query to a single manufacturer could select that name for the query filter by choosing it from the LOV. 136 Universe Design Learner s Guide

149 Working with LOVs in Universe Designer A list of values is a list that contains the distinct data values associated with an object. After completing this unit, you will be able to: Associate an LOV with an object View the contents of an LOV Set options for generating an LOV Modify the contents of an LOV Create a hierarchical view of an LOV Associating an LOV with an object By default, an LOV is attached to every dimension and detail object that is created in Universe Designer. When you create a dimension or detail object in Universe Designer, it is automatically assigned an associated list of values, or LOV. This list does not physically exist when you create an object, but by default the object has the ability to query the database to return a list of its values when used to build a query. There are three things to keep in mind, as a universe designer, when deciding whether or not to associate an LOV to an object: An LOV is based on a SELECT Distinct query that is fired at the target database. This could have potential performance implications for the efficiency of Business Objects end-user querying tools. The only purpose for creating an LOV is to assist the end user in choosing an operand value for a query filter. The LOV only holds values that exist within the database. It is therefore recommended that you do not provide an LOV for the following types of objects: All measure objects. Any object where the LOV consists of a large number of values. Any object where the list on its own would be meaningless. To view an object s default LOV properties 1. Double-click the object to open the Edit Properties dialog box for the object. 2. Click the Properties tab. Using Lists of Values Learner s Guide 137

150 3. If you want to turn off the LOV for this object, click the Associate a List of Values check box to clear it. To view the contents of an LOV in Universe Designer 1. Double-click the relevant object to open the Edit Properties dialog box. 2. Click the Properties tab. 3. In the Associate a List of Values zone, click the Display button. A SELECT Distinct query is fired at the target database and the LOV displays. 4. Click the Cancel button to close the window. To create a file to hold the contents of the LOV query in Universe Designer, use the same procedure, but instead of clicking Cancel at step 4, click OK. In that case, the list is saved as an.lov file in the universe subfolder on the file system. The default location is the Universe subfolder of the default installation folder: C:\Documents and Settings\<user_name>\Application Data\ Business Objects\Business Objects 12.0\Universes\@<server_name>\<universe_name> The name of the LOV file is the same name as shown in the List Name field, in the Properties tab. As a designer, you can edit the list name to call the file anything you want (over 100 characters long), provided that the file ends in an.lov extension. Clicking the Restore Default button changes the name back to the default file name. 138 Universe Design Learner s Guide

151 Setting options for generating LOVs By default, the first time that an LOV is used in a user login session, the system fires a query at the target database and uses the results to populate the list. Thereafter, the.lov file from this query is referred to each time the LOV is used. However, you can alter the strategy for refreshing the list by selecting options from the Associate a List of Values zone, in the Edit Properties dialog box. Note: The next section describes the following List of Values options: Automatic refresh before use option Export with universe option Delegate search option Automatic refresh before use If you select this check box, the system sends the SELECT Distinct query to the target database every time the user selects the LOV. This refreshes the contents of the list much more frequently than the default strategy, where the list is refreshed only the first time it is used in a user login session. It is recommended that you select the Automatic refresh before use check box if the contents of the list are dynamic and frequently changing. If the contents of the list are stable and unchanging, you can increase speed and efficiency by clearing this check box. Export with universe If you select the Export with universe check box, the list of values is converted to XML when the universe is exported, and stored in a.unw file. This file is stored in the BusinessObjects Central Management Server (CMS). Delegate search The Delegated list of values (LOV) search allows you to delegate the search of values in an LOV to the database. This feature: Prevents the LOV from loading automatically Restricts the data set returned Improves performance by limiting the load time Using Lists of Values Learner s Guide 139

152 Instead, the report user can perform a search for a pattern within the database. This option can be helpful when using an SAP BW data source. An SAP BW query can contain more than ten variables, which means that ten or more lists of values can be loaded. Loading and refreshing lists of values can have an important impact on performance. The delegate search option on the list of values properties presents the user with an empty list of values at query run time. The user enters search criteria to limit the number of values returned in the list of values. Note: The delegated search is not supported for cascading lists of values. Modifying the contents of the LOV In Universe Designer, you can modify the contents of the list in two ways: Remove values from the list by creating a filter. Add data to the list by adding columns to the list. The remaining two options, Allow users to edit this list of values and Hierarchical Display, are not available for users creating reports with Web Intelligence and Web Intelligence Rich Client. To apply a condition to an LOV 1. In Universe Designer, in the object s Edit Properties tab (in the Associate a List of Values zone), click Edit to the left of the Display button. The Universe Designer Query Panel displays, showing the default query for the LOV. The active object is listed in the Result Objects. 2. Drag an object that you want to serve as a condition on the list of values for the active object over to the Conditions pane. 3. Double-click an operator in the Operators pane. 4. Double-click an operand in the Operand pane. 5. Select or type values as required. 6. Click Run to save the condition and close the Universe Designer Query Panel. 7. Click Display to view the restricted list of values. If a blank list appears, click Refresh. The values appear in the list. 8. Click OK to accept the modified list. The.LOV file in the universe subfolder updates with the modified list. This is the LOV that the end users see when they use the edited object in a query. 140 Universe Design Learner s Guide

153 Editing the LOVs for the entire universe If you want to view all the objects in the universe that have LOVs associated with them, and possibly edit some of these LOVs at the same time, you can edit the lists from the Universe Designer Tools menu. To edit the LOVs from the Tools menu 1. From the Tools menu in Universe Designer, select List of Values. 2. Select Edit a List of Values from the drop-down menu. The List of Values dialog appears displaying all the objects in this universe that have an LOV associated with them. From here, you can select any of these objects to display, edit, purge and refresh their LOV. 3. Click the +box next to each class name displayed to see the objects in this universe that have an LOV associated with them. 4. Select an object from the list. 5. Click Display. The list of values for the selected object displays. 6. Click OK to close the List of Values dialog box. The Tools List of Values Edit List of Values option is useful if you want to edit all the LOVs in the universe at the same time, instead of displaying the Edit Properties dialog box for each object separately. Using Lists of Values Learner s Guide 141

154 Adding data to the list by adding columns The second way you can modify the LOV is to add more data to the list by adding columns to it. This helps end users to find the value they want. It is also an appropriate method for an LOV that contains a lot of values. To add additional columns to an LOV 1. Double-click on an object to open the Edit Properties tab. 2. Click on the Properties tab. 3. Select Edit (in the Associate a List of Values zone). The Universe Designer Query Panel displays. 4. Drag the objects you want to place in the hierarchy into the Result Objects pane to the right of the existing object and place the respective sorts on them. 5. Click Run to save the LOV query and close the Universe Designer Query Panel. 6. In the Properties tab of the object s Edit Properties dialog box (in the Associate a List of Values zone), click the Display button to see the LOV. Note: If the list is blank, click the Refresh button to update the list. 142 Universe Design Learner s Guide

155 Creating a cascading LOV A cascading LOV is a feature in Universe Designer that allows you to associate an LOV to a series of objects defined in a hierarchy. When a user applies a prompted query filter to one of the objects used in the cascading LOV, Web Intelligence or Web Intelligence Rich Client prompts the user to select a value for each level of the hierarchy. This feature only applies to Web Intelligence XI R2,Web Intelligence XI 3.0, and Web Intelligence Rich Client XI 3.0. Note: You remove a cascading LOV in the same way that you remove an ordinary LOV, by editing the object properties and deleting the condition in the object definition. After completing this unit, you will be able to: Set up a cascading LOV Use the cascading LOV in Web Intelligence Rich Client Setting up a cascading LOV A cascading LOV is a sequence of lists of values associated with a hierarchy of objects in a universe. As universe Universe Designer, you define prompts for each hierarchy level and when the user adds one of the objects to a query, the query prompts the user to select a value for each level. Universe designers build the prompt(s) in the object definition, and report designers and power users use it when they create and refresh reports using queries. Using Lists of Values Learner s Guide 143

156 A universe designer defines the universe so that the user is always required to answer a series of prompts to specify the values in a hierarchy of dimensions to be displayed in the report. Only the data concerning the selected values is returned to the microcube. Users can create a query that builds one of the objects into a prompted query filter. The Prompts dialog box displays the list of values for all the objects you placed in the cascading LOV in Universe Designer, in reverse order. To build a cascading LOV on an object 1. From the Tools menu in Universe Designer, select List of Values. 2. Select Create cascading Lists of Values from the drop-down menu. The Create Cascading List of Values dialog box appears. 3. Open the appropriate class and double-click the object to move it into the Cascading List of Values list. By default, text appears in the Prompt Text zone to set the text that users will see if this object is used in a prompted query filter after you add the next object. 4. Double-click additional objects that need to appear in hierarchical order in the cascading list of values. Edit the prompt text if required. 5. Verify that the Hierarchical View check box is selected. 6. Click Generate LOVs to create the list of values. 144 Universe Design Learner s Guide

157 If LOVs already exist for the selected objects, you will be prompted with a message asking whether you want to overwrite the existing values. 7. Click OK. The Create Cascading List of Values dialog box closes. 8. Save and export the universe. To test the cascading LOV in Web Intelligence Rich Client Now that you have assigned LOVs to objects that are grouped together in a hierarchy as a cascading LOV, you can create a query that builds one of the objects into a prompted query filter. 1. In Web Intelligence Rich Client, build a query and create a prompt on one of the objects in the cascading LOV. 2. Click Run Query. The Prompts dialog box appears. The Prompts dialog box displays the list of values for all the objects you placed in the cascading LOV in Universe Designer, in reverse order. Note: If you are sure you know the exact value that interests you, you can always type in the Type a value text box. 3. Scroll down the list of values and click the + box to expand that folder. 4. Expand the further + boxes to select the lowest level value for your query. The little arrow displayed next to the prompt text at the top of the Prompts dialog box changes to a green check mark and the value you have chosen appears in the prompt. 5. Click Run Query to create the report. The report displays the selected values. Activity: Using a cascading LOV in Web Intelligence Rich Client Objective Associate a Cascading LOV to an object. Instructions 1. In Universe Designer, create a cascading LOV using the objects in the Car class. 2. Save the universe. 3. Build a query in Web Intelligence Rich Client that shows the number of cars sold per showroom and prompts the users to select the Category of Car that they want to see in the report. Note: At the end of this activity, please remove the Cascading List of Values using the following steps: Using Lists of Values Learner s Guide 145

158 In Universe Designer, change the object definition to associate a standard List of Values for all objects in the Car class. Save the universe. 146 Universe Design-Learner's Guide

159 Quiz: Using lists of values 1. By default what values are contained in a list of values (LOV)? 2. What are three things that a universe designer should keep in mind when deciding whether to associate an LOV with an object? 3. For what types of objects is it recommended not to provide an LOV? Using Lists of Values Learner s Guide 147

160 Lesson summary After completing this lesson, you are now able to: Create a list of values Work with LOVs in Universe Designer Create a cascading LOV 148 Universe Design Learner s Guide

161 Lesson 7 Resolving Loops in a Universe Lesson introduction This lesson describes loops, a particular type of join issue that can arise as you create joins between tables in your schema. It explains how you can detect and resolve loops to ensure that the join paths taken by queries run on the universe return correct results. After completing this lesson, you will be able to: Understand loops Resolve loops using shortcut joins Resolve loops using aliases Resolve loops using contexts Resolving Loops in a Universe Learner s Guide 149

162 Understanding loops A loop is a join path issue that arises from the way that tables are related in a relational database. Loops can produce instances where a query returns too few rows of data. After completing this unit, you will be able to: Understand the causes of loops Detect loops in a universe structure Recognizing loops A loop exists when the joins between tables form a closed path. For example, in the table layout above, the designer has added joins between the tables Showroom and Country to create two linked sets of information. One set links the car sale details, the client, the client s region and the client s country of residence. The other set links the car sale details, the showroom, and the country where the showroom is located. Together, these joins form a loop. Problems caused by loops Suppose users of the Motors universe want to produce reports showing the revenue generated by car sales to clients, including both the location of the showroom where the cars are sold and the address (including country) of the clients. 150 Universe Design Learner s Guide

163 The designer adds the tables needed to provide this information and creates the joins as shown in the previous example. The designer has also created objects for the Showroom Country, Client Country, and Sales Revenue. If the loop was allowed to remain and a query could be run using the Showroom Country, Client Country and Sales Revenue objects, the report results will be incorrect. The report would suggest that only clients from the US bought cars in the US showrooms, and only clients from the UK bought cars in the UK showrooms. However, the report would not show any clients from any other countries. When you know that there are clients from other countries, this result indicates that there is a problem with the report. Loops in a universe schema and not in the database In a database, multiple paths between tables can be valid and implemented to meet specific user requirements. When each path is included individually in a query, it returns a distinct set of results. However, a schema that you design in Universe Designer often needs to allow queries that include more than one path, which a relational database may not be designed to handle. As a result, the information returned can be incorrect. The rows that are returned are an intersection of the results for the path, so fewer rows are returned than expected. It is often difficult to determine the problem when you examine the results. What is the loop doing? The joins in the Structure pane are used to create the WHERE clause in the inferred SQL of a query. Joins restrict the data that is returned by the query. In a loop, the joins will apply more restrictions than the designer intended, and the data returned will be incorrect. This is an example of a WHERE clause created by a loop: WHERE {COUNTRY.COUNTRY_ID=SHOWROOM.COUNTRY_ID} AND {COUNTRY.COUNTRY_ID=REGION.COUNTRY_ID } AND {REGION.REGION_ID=CLIENT.REGION_ID } AND {CLIENT.CLIENT_ID=SALE.CLIENT_ID } AND {SHOWROOM.SHOWROOM_ID=SALE.SHOWROOM_ID } AND {SALE.SALE_ID=SALE_MODEL.SALE_ID } AND {SALE.SALE_TYPE= 'S' } Notice that the two joins at the top of the SQL statement are both applying a restriction to the Country table, which is serving two purposes: It is being used as the Lookup for the Showroom Country It is also the Lookup for the Client Country This creates a restriction so that data is returned only when the Showroom Country is the same as the Client Country. Consequently, the report shows only the revenue generated by US clients in the US showrooms and by UK clients in the UK showrooms. In summary, while the above loop does infer legitimate SQL, the results will not include all intended values. Therefore, a Resolving Loops in a Universe Learner s Guide 151

164 query on a universe involving such a loop will return misleading data. To avoid this, the loop must be resolved. Resolving loops Loops are an inherent problem when writing SQL statements. There are various techniques within SQL that you can apply to resolve loops. How Universe Designer deals with loops There are automatic methods built into Universe Designer that can be used to identify and resolve almost all loop problems. The two main methods of resolving loops are: Aliases Contexts Loops can be resolved by creating aliases and contexts manually. However, depending on the complexity of a universe, this can be a cumbersome task. There is functionality built into Universe Designer that allows for automatic detection and resolution of loops. This functionality can only be reliable if cardinality has been defined correctly for each join in the universe. Furthermore, due to performance implications, it is recommended that all cardinality be set manually at the time each join is created. 152 Universe Design Learner s Guide

165 Resolving loops using aliases One way to solve a loop in the universe structure is to create an alias table. After completing this unit, you will be able to: Describe aliases Resolve loops using aliases Resolve self-join loops using aliases About aliases An alias breaks a loop by using the same table twice in the same query for a different purpose. The alias is identical to the base table but with a different name. The data in the alias is exactly the same as the original table, but the different name tricks SQL into using the same database table for two different purposes. The Country table has already been identified as a shared lookup table because it is serving two purposes in the query you are trying to run (providing data for the Client Country and also for the Showroom Country). In the example above, you can see the Country table joined to the Region table for the Client side of the query. The Country table also is the Showroom table for the Showroom side of the query. Note: Another way of spotting the problem table in a loop is that it will have only the one end of the one-to-many joins going into it. Check the other tables in the loop. If you find no others with only one-end joins, the loop can be resolved using an alias, assuming there are no other tables joined to country. To resolve the loop, you need to use the same table (the Country table) twice in the same query when it is being used for different purposes. However, you cannot do this in SQL unless you create an Alias table. You can resolve the loop satisfactorily by creating only one alias table in the example we have been using. The Region join uses the original Country table, while the Showroom join uses the alias table. However, you could create a separate alias table for each join in the original table. In the past, this was necessary for some relational databases. Today, it is not necessary. However, some universe designers prefer to alias both tables. Detecting loops and inserting aliases The Universe Designer module has automatic tools that detect loops and create aliases for you. You can use the Detect Loops or Detect Aliases toolbar icons, to automatically detect and indicate the tables causing loops in the active universe. Detect Aliases proposes candidate tables that you can edit, and insert in the schema. Note: Before using Detect Aliases, verify that all the tables in schema are linked by joins, and that all cardinalities are set. Resolving Loops in a Universe Learner s Guide 153

166 To detect loops using the automatic detection tool 1. Click the Detect Loop button. The system highlights the loop in the Structure pane, and displays the Loop Detection dialog box. 2. The Loop 1/1 indicates how many loops have been detected. If there are others, you can use the forward and back arrow buttons to check each loop. The message beneath the buttons indicates (in this case) that the loop can be resolved with an alias. 3. Click Insert Alias in the Loop Detection dialog box. Universe Designer automatically creates an alias for the required table. You may need to move the new alias table so that you can see the Structure pane. Note: The original table name will show up in brackets in the Alias table header. 4. Close the Loop Detection dialog box. The Structure pane will look similar to this: 154 Universe Design Learner s Guide

167 In the example diagram, the Country_Showroom alias table has been created in the Structure pane, the join between this Alias table and the Showroom table has been made automatically, and the loop has been broken. Note: When the problem table has two purposes, Universe Designer might nominate either of the two as the candidate for the Alias table. To insert an alias automatically Universe Designer has an automatic tool that detects the tables that could be aliased to resolve loops. 1. Click the Detect Aliases button. The system displays an Alias Detection message similar to the following: If you have not yet set cardinalities, this message reminds you that you must do so first. If cardinalities have already been set, the reason for the message may be a self-restricting join within the universe structure. Cardinality is not relevant for these types of joins and so designers tend not to set cardinality for them. However, to avoid the message, you could make self-restricting joins one-to-one. 2. Click OK. The Candidate Alias dialog box displays. 3. Select a table name and click Rename. The Rename Table dialog box displays. 4. Enter the new name for the alias and click OK. The Rename Table dialog box closes and the new alias name is shown in the right panel. 5. To create the alias table, click Create. Universe Designer displays a confirmation request. 6. Click OK to create the alias table. Note: If there are several candidates for aliases, you can then repeat the process for the next table. When there is only one candidate, the Candidate Alias dialog box closes. Resolving Loops in a Universe Learner s Guide 155

168 Tip: Be careful not to delete the original table. Once you have created one or more alias tables, it s a good idea to click beside the original table in the Structure pane and type Aliased table Do not remove, for example, to remind you not to delete it. To insert an alias manually Instead of using the Loop Detection or Alias Detection tools, you can create the alias manually. 1. Select the table for which you want an alias by clicking the table header. 2. Insert an alias using one of the following methods: Click the Insert Alias button. Right-click the table and select Alias from the right-click menu. 3. Enter the new name for the alias table and click OK. This creates an alias table for the selected table. Note: The original table name appears in brackets in the Alias table header. 4. Remove the appropriate join from the original table. 5. Reset the join to the alias table. 6. Set the cardinality for the join. The Structure pane should now look the same as when using the first method, the Loop Detection tool. Redefining objects When you create an alias table, check that any existing objects that are defined from the original table still refer to the right table. They may need to be defined from the alias table to infer the correct SQL and get the correct result. Finding objects defined from a table In a simple universe, it is not difficult to find the objects that have been defined from a table. There is a utility in Universe Designer that allows you to easily determine all existing objects that point to a single table in the structure of the universe. Universe Designer provides an option to assist in finding the relevant objects. 1. Right-click the header of the original table in the Structure pane. 2. Choose View associated objects from the right-click menu. This highlights all the objects that were defined from the original table in the Universe pane. Redefine the highlighted objects to make sure they point to the correct table. 3. Double-click the affected object to open the Object Properties dialog box. 4. Redefine the SELECT statement to use the alias table instead of the original table. 156 Universe Design Learner s Guide

169 5. Click OK and then save the universe. Listing and renaming aliases You can list aliases and rename them. To invoke the aliases list: 1. Select the List of Aliases option from the Tools drop-down list. The List of Aliases panel appears. To rename an alias from the List of Aliases panel To rename aliases from the list of aliases: 1. Click the alias you want to rename. 2. Edit the alias name in the New Name field and click OK. Note: The alias name changes in the universe structure as well as any object referencing the alias and context lists. Choosing which alias method to use Method Advantages Disadvantages Detect loops can view loops before applying them may show other loops to be resolved by contexts Detect aliases finds all candidate aliases exclusively no visual check prior to acceptance Insert alias choose table to alias, minimizing object redefinition must understand how to identify the need for candidate analysis Whichever method you choose, you must always redefine objects that now use the Alias table. Resolving self-join loops using aliases A self-join is a join from one column of a table to another column of the same table. A classic example of when such a join is required is in a situation whereby you want to report on the hierarchical structure of an organization via a Personnel database. In such a situation, Resolving Loops in a Universe Learner s Guide 157

170 it is most probable that all employee records are held in a single table, irrespective of status. Hence, a self-join is required to report on the hierarchical relationship between those employees. For example, in the Motors database there is an employees table that contains columns as shown below: Each employee is uniquely identified by the Emp_Id field, and each employee has a manager, who is identified by the Emp_Mgr_Id field. However, the managers are themselves employees, and the table therefore contains a hierarchical structure. If you want to add a join to link each employee with their respective manager, the obvious way is to link the Emp_Mgr_Id field to the Emp_Id field, as in this example: The code used to identify the manager (Emp_Mgr_Id ) is itself an employee code. You can therefore use it to look up the Emp_Id codes in the Employee table and identify the manager s name. This is effectively a loop, as the path forms a closed circuit. However, you cannot resolve it by using the usual method of detecting the cardinalities and then detecting aliases. This is because the cardinality detection tool cannot work on a self-join. Moreover, a structure expressed this way will not infer the correct SQL. To resolve a self-join with an alias 1. Right-click the table header and choose Alias from the right-click menu. 2. Enter an appropriate alias table name. 158 Universe Design Learner s Guide

171 3. Click OK. 4. Draw the join between the original table and its alias. 5. Double-click the join. The Edit Join dialog box opens. 6. Set the cardinality for the join. 7. When the self-join has been resolved, you can create separate objects for both tables. Resolving Loops in a Universe Learner s Guide 159

172 Resolving loops using shortcut joins Another way to solve a loop in the universe structure is to use a shortcut join. After completing this unit, you will be able to: Describe how shortcut joins can make a query more efficient Resolve loops using shortcut joins Using a shortcut join A shortcut join is a join that links two tables together but bypasses intervening tables that exist in the universe. This is used when designing universes where it is possible in certain circumstances to make the inferred SQL more efficient. For example, in the Motors universe, the geographical information relating to clients comes from the Client, Region, and Country tables: If an end user runs a query including Country and Client (but not Region) objects, you will find that the inferred SQL includes the joins to the Region table. This is necessary because the Region table forms the link between the Client and Country tables. However, the additional lookup decreases the efficiency of the SQL. You can overcome this inefficiency by making a join directly from the Client table to the Country table. Now if a user builds a query just using Country and Client, the query will not have to refer to the Region table. You now have a loop. In this case, you do not have a multipurpose lookup table scenario, and should therefore not alias. Instead you would convert the created join to a shortcut join to break the loop. 160 Universe Design Learner s Guide

173 To convert a standard join to a shortcut join 1. Double-click the join that you want to convert to a shortcut join. The Edit Join dialog box appears. 2. Click the Shortcut join check box just below the Cardinality zone. 3. Click OK to close the dialog box. The join has been redefined as a shortcut join, which appears in the Structure pane. If you were to try detecting loops, none would be detected. The shortcut join, in the above example, is telling the SQL only to use this join if the Region table is not included in the query. Therefore, there is no loop, and the efficiency of the SQL has been improved. Shortcut joins are not automatically detected for contexts. If you want to include them in a context you have to manually edit the context. However, this is not always desirable. Ideally, shortcut joins should bypass contexts when specific queries do not require one or more contexts to return the results, and therefore should be left as standalone or isolated joins. The efficiency gains of a shortcut join are based on the fact that it spans across contexts. In the Motors universe, a shortcut join can be the ideal way of joining Showroom to Maker in order to produce a report for managers, wishing to see which showrooms have which franchises. This shortcut join would not use the Rental or Sales contexts. Instead it would go directly from Showroom to Maker, as the shortcut join takes precedence over any other join. However applying a shortcut join here is not possible due to the keys set up in the tables. A linking table between Showroom and Maker, together with a new context, will be required to return the same results. Activity: Resolving loops with aliases Objectives Resolve loops by creating alias tables Test your results in Web Intelligence Rich Client Resolving Loops in a Universe Learner s Guide 161

174 Instructions In this activity you will add new tables, insert new joins, and set cardinality, that will create loops in the Motors universe. You will then resolve the loops and test them. 1. Insert the following join and set its cardinality. COUNTRY.COUNTRY_ID=SHOWROOM.COUNTRY_ID 2. Use the Detect Loop toolbar button to test for loops in your universe. To solve the loops that you have detected by creating alias tables, press the Insert Aliases button in the Loop Detection dialog box, or use the Insert Alias toolbar button and create two alias tables called: COUNTRY_SHOWROOM COUNTRY_REGION 3. Disconnect the original COUNTRY table from the other tables and use the alias tables to redefine the joins as follows: COUNTRY_SHOWROOM.COUNTRY_ID=SHOWROOM.COUNTRY_ID COUNTRY_REGION.COUNTRY_ID=REGION.COUNTRY_ID COUNTRY_REGION.COUNTRY_ID=CLIENT.COUNTRY_ID 4. Set the new join cardinalities. In the third join, be sure to select the Shortcut join check box. 5. Create a Country object in the Showroom class with the settings: Name = Showroom Country Type = Character Description = Country in which showroom exists SELECT = COUNTRY_SHOWROOM.COUNTRY_NAME Associate an LOV 6. Edit the Country object in the Client class as follows: Name = Client Country SELECT = COUNTRY_REGION.COUNTRY_NAME 7. Check integrity by selecting the Check Integrity button in the toolbar. The check integrity tool finds divergences because the COUNTRY table is now isolated. Ignore this message and don t delete the original table. 8. Save the universe. 9. Test your changes in Web Intelligence Rich Client by building a query containing Showroom Country, Client Country, and Sales Revenue objects. 10. Edit the query and remove the Client Country, and Sales Revenue objects. Run the query with just the Showroom Country object. 162 Universe Design Learner s Guide

175 11. In Universe Designer, create an additional alias of the COUNTRY table, called COUNTRY_MAKER. 12. Insert the following join: COUNTRY_MAKER.COUNTRY_ID=MAKER.COUNTRY_ID Make sure that the join cardinality is set to one-to-many (1-N). 13. Create a Maker Country object in the Car class. 14. Test your changes in Web Intelligence Rich Client by building a query containing Maker Country, Maker, and Model objects. Resolving Loops in a Universe Learner s Guide 163

176 Resolving loops using contexts Another way to solve a loop in the universe structure is to create contexts. After completing this unit, you will be able to: Describe contexts Resolve loops using contexts About contexts A context resolves a loop by defining a set of joins that define one specific path through tables in a loop. It ensures that joins are not included from different paths within the same SQL query. You often use contexts in schema that contain multiple fact tables that share lookup tables. An example of this situation is the Sale table in the Motors universe. The Sale table contains rows of data for cars both sold and rented. The Sale_Type column is used as a flag to indicate the type of transaction (S = car sale, R = car rental). Without the self restricting join, the resultset of the query would produce rows where the Sale_Type column is equal to either S or R. Previously, you defined this self-restricting join to S, so that any object based on the table or joins passing through that table would produce query results covering only car sales. In order to retrieve data concerning rental sales as well, you create an alias of the Sale table called Rental, set the self-restricting join to R and create an alias table of the Sale_Model table called Rental_Model. Creating the aliases tables, however, will create a loop because the query will not know which table to go through to get to the Model table, Sale or the alias Rental. You can solve this type of loop by creating two contexts which will define the correct route through the universe structure. These routes link tables together in the structure. What is a context? A context is a list of joins that define a path for a query. The tables involved in the joins are included in the context. Any objects derived from tables included in a context are compatible with each other. When a query is made with objects related to separate contexts, more than one SELECT statement is inferred and run. The results of the queries are then merged in the microcube. This avoids incorrect results that might arise due to a loop or other situation with alternative routes. Alternative routes can exist without a loop in the universe structure. Detecting and creating contexts A separate context is identified for each table with only the many end of joins attached. The joins in a context are identified by working back from the table with only the many end of joins attached - many-to-one, many-to-one. 164 Universe Design Learner s Guide

177 Identifying the joins that make up a context Universe Designer detects contexts by identifying tables that have only the many ends of joins attached. It does this progressively throughout the structure. No joins flowing back from one-to-many are included. To help to see the flow of contexts within a structure, you can arrange the tables so that all the joins flow as many-to-one from left to right across the structure. Included in the context are all the tables that can be reached by following the flow from many-to-one (N-1). Tables that can only be reached by flowing back from one-to-many (1-N) are not included in the context. Note: If contexts are an important part of your universe structure, it can be very helpful to arrange your tables in this way, so that you can easily see the individual contexts. When it is not appropriate to resolve a loop by using an alias to break the loop, the loop must be left in place. However, this results in an error message when running an end-user query. This is because there are two alternate routes around the structure. Contexts are used to specify those alternate routes and ensure that a single inferred SELECT statement only includes reference to columns from tables in one of those routes. In the Sales and Rental example, you can follow two different paths from the Client table to the Model table: By way of Rental and Rental_Model: Resolving Loops in a Universe Learner s Guide 165

178 By way of Sale and Sale_Model: Each context represents what may be inferred in a single SELECT statement. Any query that infers some SQL code exclusive to one context and some exclusive to the other will infer two separate SELECT statements. 166 Universe Design Learner s Guide

179 This loop can be resolved by two candidate contexts: Rental_Model Context COUNTRY.COUNTRY_ID=REGION.COUNTRY_ID Sale_Model Context COUNTRY.COUNTRY_ID=REGION.COUNTRY_ID REGION.REGION_ID=CLIENT.REGION_ID REGION.REGION_ID=CLIENT.REGION_ID CLIENT.CLIENT.ID=RENTAL.CLIENT_ID CLIENT.CLIENT.ID=SALE.CLIENT_ID RENTAL.SALE_ID=RENTAL_MODEL.SALE_ID SALE.SALE_ID=SALE_MODEL.SALE_ID RENTAL_MODEL.MODEL_ID=MODEL.MODEL_ID SALE_MODEL.MODEL_ID=MODEL.MODEL_ID MODEL.MODEL_DAYRENT between RENTAL_PRICE_RANGE.RENT_RANGE_MIN and RENTAL_PRICE_RANGE.RENT_RANGE_MAX MODEL.MODEL_PRICE between SALES_PRICE_RANGE.PRICE_RANGE_MIN and SALES_PRICE_RANGE.PRICE_RANGE_MAX Note: The name of the context is normally defined by the table with only the many (N) end of joins attached to it. You then create different sets of objects from the tables in the different contexts. As a result, users can run either Sales queries or Rentals queries, dependent on the objects they select. Note: Every join (except shortcut joins) must exist in at least one context. Detecting and creating contexts The table below shows the toolbar buttons you can use to detect and create contexts. Detect loops Loop detection tool suggests candidates for both aliases and contexts. Detect contexts Detect Contexts detects and proposes a list of contexts to create. Insert contexts Insert Contexts inserts a context manually. Resolving Loops in a Universe Learner s Guide 167

180 To detect contexts using the Loop Detection tool 1. Click the Loop Detection button in the Editing toolbar. The system displays the Loop Detection dialog box. The first loop is highlighted in the Structure pane, and the message tells you that this loop is not covered by any context. If other loops exist, click the forward arrow button to cycle through the loops. Each loop is highlighted in turn, and a method of resolution is recommended. 2. Click the Candidate Context button to see what the tool suggests. The Candidate Contexts dialog box displays. 3. Highlight the candidate context you want to add and click the Add button. The context moves across to the Accepted Contexts field. You can click the Rename button to give each context a more meaningful name. Note: You may choose to leave the original context name in brackets. This can be useful in order to remind you that you have changed the joins in the context, while still allowing you to view the original definition. 4. Repeat the process until you have accepted all the candidate contexts. Note: Each candidate context is highlighted in the structure as you highlight it in the Candidate Contexts field. This enables you to check the context before accepting it. The Candidate Contexts dialog box closes, and the List Mode window opens in the upper part of the Structure pane. 5. Click OK. 168 Universe Design Learner s Guide

181 6. Close the Loop Detection dialog box. The List Mode window shows the created contexts. The Joins pane indicates the joins that are involved in the currently highlighted context. The Structure pane highlights the tables that are involved. 7. When you have created the contexts you require to resolve the loops, save the universe. To detect contexts using the detect contexts tool 1. Select Tools Automated Detection Detect Contexts, or click the Detect Contexts button. The system may display this message: You may have just set the cardinalities, but you can still get this message because of self-restricting joins. The system does not set cardinality on these, and therefore displays this message. Click OK to continue because you have set the cardinality for all of the joins. 2. Click OK. The system displays the Candidate Contexts dialog box. 3. Highlight the candidate context you want to add and click the Add button. You move contexts across to the Accepted Contexts field. Rename them, if required, in the same way as when using the Loop Detection tool. 4. Repeat the process until you have accepted all the candidate contexts. 5. Click OK and save the universe. Resolving Loops in a Universe Learner s Guide 169

182 To insert contexts manually 1. Click the Insert Contexts button. The New Context dialog box appears. 2. Define a name to identify the context in the Context Name field. 3. Select the joins that define the path for the context by clicking the individual joins in the Current context join list. To remove a join from the selected list, click it again to remove the highlight. Note: From the List Mode window, you can open the Edit Context dialog box to add joins by double-clicking the context in the Contexts pane. 4. When you have made a selection of joins, click the Check button to have Universe Designer check whether there are any loops in the joins you have selected. 5. In the Description field, enter the text that displays in the user module Help field. 6. Click OK to create the context and close the dialog box. Creating objects for each context When all the contexts are in place, you can create objects. Some objects refer to tables that are included in only one of the contexts. In this example, such objects include Sales Revenue or Rental Revenue. Other objects refer to tables which appear in both contexts. In this example, such objects include Client Name. Editing a context Sometimes, a user creates a query using objects that reference tables from opposite ends of two contexts, for example, a query using Client Name and Model. The Client and Model tables are on opposite sides of the Rental and Sales contexts. As a result, there are two potential routes for the inference engine to use in the SELECT statement so, when the end users run the query, they receive a prompt message to choose one of those contexts. As the term context is not meaningful to end users, you need to ensure that the context names and the Help descriptions clearly indicate how the choice of context influences the results. To edit the name and help description 1. Open the List Mode window by clicking the View List Mode button on the standard toolbar. 2. In the Contexts pane, double-click the context you want to edit. The Edit Context dialog box displays. 170 Universe Design Learner s Guide

183 The Context Name shows the name you accepted (or altered) when you created the context. The Join List shows all the joins that are included in the context path. The highlighted joins are included. 3. Scroll down the list of highlighted joins to verify that all required joins are included. You can add additional joins, or remove unnecessary joins. 4. Click the Description field and enter a suitable explanation of the context s purpose. 5. Click OK to close the Edit Context dialog box. 6. Click the View List Mode button to close the List Mode window. 7. Save the universe. The description that you entered appears in the Context Selection Help dialog box in Business Objects end-user querying tools, and the process of selecting a context is made easier for end users. Testing contexts Any end-user query that generates a SELECT statement which spans across the loop will fail without contexts in place. If contexts are in place, the end-user query tool generates the SELECT statement(s) in one of three ways. To test contexts, make at least three queries, one to test each form of SQL generation when applying contexts. The three query types are: Inferred query Incompatible objects query Ambiguous query Inferred query A query is run without prompting an end user to choose a context. The query contains enough information for the correct context to be inferred. For example, a user runs a query using the Showroom, Model and Sales Revenue objects. When these queries are run, the data is returned without prompting the user to select a context. The Sales Revenue object is a sum on the Sale_Model table, which is part of the Sales context. The query infers that the Sales context is the one to use for the query. Incompatible objects query Objects that reference tables with joins belonging to two different contexts are included in a single query. The tool creates one SELECT statement for each context, executes the queries, and then unites the results together so that the report data can be presented in a single table. For example, if you run a query containing the Showroom, Model objects with both Sales Revenue and Rental Revenue objects, no single context contains all the joins necessary to include the Showroom, Sale, Sale_Model, Rental, and Rental_Model tables to which the three objects refer. It therefore generates two SELECT statements in the query and merges the results in a single microcube report. Note: For an incompatible objects query to work, you need two contexts. Resolving Loops in a Universe Learner s Guide 171

184 Ambiguous query An end user is prompted to choose between one query path or another. This occurs when a query includes objects that, when used together, do not give enough information to determine one context or the other. When a query is ambiguous, the user is prompted by a dialog box in the Query Panel to select the appropriate context. When the user selects a context, the corresponding tables and joins are inserted into the SQL query. For example, if you run a query containing only the Showroom and Model objects, more than one context contains all the joins necessary to include the Showroom and Model tables to which the two objects refer. The user is prompted to identify which context to use by displaying the Context Selection dialog box. When the user selects one of the contexts and clicks OK, a SELECT statement is inferred using the join path for the context chosen. Note: For a user to select more than one context when running an ambiguous query, the Allow selection of multiple contexts option in the SQL tab of the Universe Parameters dialog box in the Universe Designer module must be selected. Updating contexts Contexts are not updated automatically when the universe structure is changed. If you add or remove any tables or joins to the structure, you will have to update all the contexts. If you have made only a simple change to the structure, you can update the joins that are included in each context manually using the Edit Context dialog box. However, if you have 172 Universe Design Learner s Guide

185 made significant changes to the universe structure, it can be safer to remove the current contexts and recreate them. Recommended sequence It is always best to create all your alias tables first, and then create your contexts, because of the requirement to update contexts. Otherwise, your alias tables will not be included in your previously created contexts. For loop resolution, therefore, the sequence is as follows: 1. Set cardinality on all joins. 2. Use Detect Aliases to detect all the loops that can be resolved with alias tables. 3. Insert all the required alias tables and their associated joins. Remember to set cardinality on any new joins. 4. Use Detect Contexts to detect all the contexts that can be used to resolve the remaining loops that could not be resolved with an alias. 5. Accept the candidate contexts, or create your own contexts manually. The need to follow this sequence highlights the main drawback of using the Loop Detection tool. If you detect all loops, and then follow the Loop Detection dialog box suggestions for resolving them in the order that they are presented, you will not necessarily resolve all the alias table loops first, followed by all the context loops. It is therefore better to use the alias detection tool first, and then the context detection tool. Remember also that you will have to redefine any objects that are based on tables for which you have created aliases. The overall sequence in universe design is as follows: 1. Add tables to the universe. 2. Insert joins. 3. Detect and resolve loops. 4. Create all the classes and objects. Note: If you want to test your loop resolution in a query, you may need to create some basic objects to allow you to run some simple queries. If you do this, always bear in mind the need to redefine them when you have finished resolving loops. Activity: Resolving loops using contexts Objective Resolve loops by using contexts. Instructions In this workshop you will add new tables, insert new joins, and set cardinality, that will create loops in the Motors universe. You will then resolve the loops using contexts, and test them. Resolving Loops in a Universe Learner s Guide 173

186 1. In Universe Designer, create the following aliased tables: RENTAL (alias of SALE) RENTAL_MODEL (alias of SALE_MODEL) 2. Insert the table. RENTAL_PRICE_RANGE 3. Insert the following joins and set their cardinality. Joins CLIENT.CLIENT_ID=RENTAL.CLIENT_ID RENTAL.SALE_ID=RENTAL_MODEL.SALE_ID RENTAL.SALE_TYPE='R' RENTAL.SALE_DATE between FINANCE_PERIOD.FP_START and FINANCE_PERIOD.FP_END RENTAL_MODEL.MODEL_ID=MODEL.MODEL_ID SHOWROOM.SHOWROOM_ID=RENTAL.SHOWROOM_ID RENTAL_MODEL.COLOUR_ID=COLOUR.COLOUR_ID MODEL.MODEL_DAYRENT between RENTAL_PRICE_RANGE.RENT_RANGE_MIN and RENTAL_PRICE_RANGE.RENT_RANGE_MAX 4. View loops using the loop detection tool. Tip: You should find 10 loops. 5. Resolve the loops by using the context detection tool. 6. Edit the RENTAL_MODEL context as follows: Change the name of the context to RENTALS. As a description for the context enter: "Returns information on cars rented". Remove the following join from the context list: MODEL.MODEL_PRICE between SALES_PRICE_RANGE.PRICE_RANGE_MIN and SALES_PRICE_RANGE.PRICE_RANGE_MAX Add the following self-restricting join to the context: RENTAL.SALE_TYPE='R' 7. Edit the SALE_MODEL context as follows: 174 Universe Design Learner s Guide

187 Change the name of the context to SALES. As a description for the context enter: "Returns information on cars sold". Remove the following join from the context list: MODEL.MODEL_DAYRENT between RENTAL_PRICE_RANGE.RENT_RANGE_MIN and RENTAL_PRICE_RANGE.RENT_RANGE_MAX Add the following self-restricting join to the context: SALE.SALE_TYPE='S' 8. Create a class called Rentals above the Sales class. 9. Create the following subclasses in the Rentals class: Rental Details Rental Dates Rental Figures 10. Create the following four objects in the appropriate subclass of the Rentals class: Object Name SELECT Statement Object Description Invoice ID Number RENTAL.SALE_ID Unique Invoice ID Number Rental Date RENTAL.SALE_DATE First day of Rental Return Date RENTAL.SALE_DATE + RENTAL.SALE_RENTAL_PERIOD Date rental car has been/ is to be returned Rental Revenue SUM(RENTAL.SALE_RENTAL_PERIOD* RENTAL_MODEL.SALE_QTY* MODEL.MODEL_DAYRENT* ((100 - RENTAL.SALE_SALE_DISCOUNT)/100)) Total Rental Invoice Value 11. Create a subclass called Day Rental Charges in the Car class. Then populate the subclass with the following objects. Resolving Loops in a Universe Learner s Guide 175

188 Object Name SELECT Statement Object Description Day Rental Range RENTAL_PRICE_RANGE.RENT_RANGE Description of Rental Charge banding Model Day Rental Charge MODEL.MODEL_DAYRENT Standard Day Rental Charge 12. Save the universe, then test the contexts used to resolve the loops by building the following queries in Web Intelligence Rich Client: Showroom dimension and Sales Revenue measure objects. The inferred SELECT statement for this query should use the SALES context. Showroom dimension and Rental Revenue measure objects. The inferred SELECT statement for this query should use the RENTALS context. Showroom dimension, Sales Revenue and Rental Revenue measure objects. This query should infer two SELECT statements, one for each context. Showroom, Model, and Maker dimension objects. With this query, a dialog box should appear asking which context to use. 13. Insert the table named FRANCHISE in the universe structure. Insert the joins specified below and set cardinalities. SHOWROOM.SHOWROOM_ID=FRANCHISE.SHOWROOM_ID FRANCHISE.MAKER_ID=MAKER.MAKER_ID 14. Detect contexts using the method of your choice. Tip: In this instance, it is unnecessary to remove existing contexts and redetect them as they are not affected by the FRANCHISE table and its joins. 15. Create the following object in the Showroom class, and then use it in a query to test that the context has resolved the loop correctly. Object Name SELECT Statement Object Description Franchises MAKER.MAKER_NAME Car manufacturers with which the showroom has a contracted dealership. 16. Check the integrity of the Motors universe with all options except Cardinality checked. Resolve any relevant divergence. 17. Save the Motors universe and close it. 18. Open the Staff universe. You want to report on Managers and their staff. 19. Create a class called Employees. 20. Create an alias table of the EMPLOYEE table and rename it MANAGERS. 176 Universe Design Learner s Guide

189 Join the tables as shown below: 21. Create a Staff dimension object based on the EMPLOYEE table. Concatenate the Employee Last Name and First Name. 22. Create a Managers dimension object based on the alias MANAGERS table. Concatenate the Managers Last Name and First Name. Tip: To get the query to infer the correct SQL, you will need to resolve the self-join in the universe structure. 23. Check the integrity of the Staff universe with all except the cardinality options checked. Resolve any relevant divergence. Tip: You should not find any divergences. 24. Save the Staff universe. Resolving Loops in a Universe Learner s Guide 177

190 Quiz: Resolving loops in a universe 1. What is the first step in resolving loops? 2. What causes a loop? 3. What are the two main methods of resolving loops? 4. What are the three types of queries you can use to test your contexts? 178 Universe Design Learner s Guide

191 Lesson summary After completing this lesson, you are now able to: Understand loops Resolve loops using shortcut joins Resolve loops using aliases Resolve loops using contexts Resolving Loops in a Universe Learner s Guide 179

192 180 Universe Design-Learner's Guide

193 Lesson 8 Resolving SQL Traps Lesson introduction This lesson deals with two common SQL Traps: Chasm and Fan. Chasm traps and fan traps are problems inherent in SQL that are caused by the order in which the elements of the SELECT statement are processed. After completing this lesson, you will be able to: Understand SQL traps and universes Resolve fan traps Resolve chasm traps Resolving SQL Traps Learner s Guide 181

194 Understanding SQL traps and universes In order to avoid common SQL traps in your universe, it is important to understand how aggregates in queries may result in incorrect data. After completing this unit, you will be able to: Explain how SQL traps can cause queries to return inaccurate results About SQL traps Chasm traps and fan traps are problems inherent in SQL that are caused by the order in which the elements of the SELECT statement are processed. In SQL, a SELECT statement processes the SELECT, FROM, and WHERE clauses first (with the exception of any aggregates). In doing so, it creates a product of all the tables in the FROM clause on the basis of the joins and restrictions specified in the WHERE clause. This can be thought of as a virtual table. Normally this does not cause a problem, but if an aggregate is applied then it may, in particular circumstances, result in wrong output being generated. This is particularly worrying because SQL does not produce an error message, it just projects the results. Unlike loops that return fewer rows than expected, chasm traps and fan traps return too many rows. Fortunately, there are ways of identifying situations in which chasm traps and fan traps can occur, and there are methods of resolving these situations. 182 Universe Design Learner s Guide

195 Detecting and resolving chasm traps This unit explains how chasm traps can occur in the universe structure and how to resolve them. After completing this unit, you will be able to: Explain what a chasm trap is Detect chasm traps in a universe structure Resolve chasm traps Chasm traps A chasm trap is a common problem in relational database schemas in which a join path returns more data than expected. 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. You only get incorrect results when the following circumstances all exist simultaneously: 1. There is a many-to-one-to-many relationship between three tables in the universe structure. 2. The query includes objects based on the two many tables. 3. There are multiple rows returned for a single dimension value. For example, in this diagram there is no loop, but the flow around the three tables is many-to-one-to-many. Note: A chasm trap is not dependent on the object types. The query could be made up of only dimensions, only details, or only measures, or any combination of the three types with the many tables for a chasm to occur. When a query that uses objects Y and Z is run, the inferred SQL includes tables B, C, and A that have a many-one-many relationship respectively. 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. This results in the values for each object being multiplied by the other. The effect is similar to a Cartesian product but is known as a chasm trap. The chasm trap is resolved by executing separate SELECT statements for object Y and object Z. Resolving SQL Traps Learner s Guide 183

196 Detecting chasm traps Unlike loops, chasm traps are not detected automatically by Designer. However, you can detect them in one of the following ways: Analyze the one-to-many (1-N) join paths in your schema to detect chasm traps graphically. Select Tools Detect Contexts or click the Detect Contexts button to automatically detect and propose candidate contexts in your schema. Detect Contexts examines the many-to-one (N-1) joins in the schema and proposes contexts to separate the queries run on the table. This is the most effective way to ensure that your schema does not have a chasm trap. Add additional dimension or detail objects to display more information in the report. If there is a chasm trap, aggregated values will be doubled, alerting you to the problem. You can use Detect Contexts to detect and propose candidate contexts, and then examine the table where any two contexts diverge. The point where two contexts intersect is the source of a chasm trap. Any two tables that have multiple rows converging to a single row in the table with the one relationship may potentially cause a chasm trap. The chasm trap scenario This section demonstrates a chasm trap in the Motors universe, and proposes two solutions to the problem. In the diagram below, the Sale, Client and Rental (Sale) tables are joined by a many-to-one-to-many relationship. 184 Universe Design Learner s Guide

197 The following objects in Motors reference the tables above: In this scenario, the universe designer has not selected the Multiple SQL statements for each measure option in the Universe Parameters SQL tab. A user creates a series of queries using these objects and gets inaccurate results. Resolving SQL Traps Learner s Guide 185

198 The first two queries return the correct data, but combining Sales Revenue and Rental Revenue in the third query returns inaccurate results. To understand what is happening here, you need to examine the rows that are returned by the queries to make the aggregated figures. In this example, you can do this by adding the Sale Date and Rental Date objects to the queries to return individual transaction details. Notice that there are two sale transactions in the first table. There are also two rental transactions in the second table. If you add the dates to the combined query as in the third table, you can see why the sale and rental revenues have doubled. The query returns every possible combination of sale rows with every possible combination of rental rows. Hence, the sale transactions each appear twice as do the rental transactions, and as a result of this the aggregates have been multiplied by the number of related rows on the alternative many table. Where you have a many-one-many relationship for tables in the FROM clause, the resulting logical table produces something akin to a Cartesian product. Only then is aggregation applied. This is the reason for the chasm effect. The problem with chasm traps is that, unless you look at the detail rows, there is nothing to alert you to the situation. Resolving chasm traps To resolve a chasm trap, you need to make two separate queries and then combine the results. Depending on the type of objects defined for the fact tables and the type of end-user environment, you can use the following methods to resolve a chasm trap: Modify the SQL parameters for the universe so you can generate separate SQL queries for each measure. This method is not recommended as it only works with measures and will result in certain inefficiencies in processing. It does not generate separate queries for dimension or detail objects. Create a context for each fact table. 186 Universe Design Learner s Guide

199 This solution works in all cases and will not result in inefficiencies. Using multiple SQL statements for each measure to resolve chasm traps If you have only measure objects defined for both fact tables, then you can use the Universe Parameters option Multiple SQL statements for each measure. This forces the generation of separate SQL queries for each measure that is used in the query. It does not work for queries that do not contain measures. With the option Multiple SQL statements for each measure selected, Universe Designer will now make separate SQL SELECT statements for each measure object in the query. The results in the report are now correct, as the query has automatically generated two SQL statements. Using this option will resolve the chasm trap problem. However, there are drawbacks to using this method to resolve chasm traps. Resolving SQL Traps Learner s Guide 187

200 To activate multiple SQL statements for each measure to resolve chasm traps 1. Select File Parameters from the menu bar or click the Parameter button. The Universe Parameters dialog box appears. 2. Click the SQL tab. 3. Click the Multiple SQL Statements for Each Measure check box in the Multiple Paths zone to select this option. 4. Click OK. 5. Save the universe. 6. In Web Intelligence Rich Client, create a new query using a dimension object, and two measure objects from the many-to-one-to-many table relationship. 7. Run the query. The results in the report are now correct, as the query has automatically generated two SQL statements. 8. Access the SQL that is generated in the SQL Viewer by clicking the Edit Query button on the toolbar to open the Report Panel. 9. Click on the View SQL button. This displays the separate SQL Statements. 188 Universe Design Learner s Guide

201 Drawbacks to the multiple SQL statements for each measure method Using the Multiple SQL statements for each measure option will resolve the chasm trap problem. There are, however, two main drawbacks to using this method. The results can be confusing The SQL Parameter used specifies: Multiple SQL statements for each measure. One of the drawbacks is that it does not run separate SELECT statements if the query contains only dimension objects. The report contains a single block with the results displayed as a Cartesian product. It is not that there is anything inaccurate about the dates, but the multiple occurrences will be confusing to users. The query is inefficient Another drawback is that any query including multiple measures will infer a separate SELECT statement for each measure irrespective of whether it is required or not. Resolving SQL Traps Learner s Guide 189

202 To find a complete solution to chasm traps, you must use contexts. Using contexts to resolve chasm traps You can define a context for each table at the many end of the joins. In this example you could define a context from Client to Sale and from Client to Rental. 190 Universe Design Learner s Guide

203 When you run a query that includes objects from both contexts, this creates two SELECT statements that are synchronized at run-time in Business Objects end-user query tools to prevent the creation of a Cartesian product. Creating contexts will always solve a chasm trap in a universe. When you have a many-to-one-to-many situation, always use a context. To use contexts to resolve a chasm trap 1. Identify the potential chasm trap by analyzing the many-to-one-to-many join path relations in the schema. 2. Select Tools Automated Detection Detect Contexts from the menu bar or click the Detect Contexts button. The Candidate Contexts dialog box appears. 3. Select a proposed context in the Candidate Contexts list box and click Add to add it to the Accept Contexts list box. Click OK. 4. Repeat for other listed contexts. The new contexts are listed in the Contexts pane of the List View window. 5. Select File Parameters from the menu bar or click the Parameters button. The Universe Parameters dialog box appears. 6. Click the SQL tab. 7. Select the Multiple SQL for each Context check box to clear the option. 8. Click OK. When you run queries on the tables in the chasm trap, the query separates the SQL into what is compatible for separate SELECT statements. Activity: Resolving chasm traps Objective Detect contexts to resolve a chasm trap in the universe structure. Instructions 1. Create a new universe called Chasm.unv. Use the Motors_conn connection to connect to the Motors database. 2. Select File Parameters from the menu bar or click the Parameter button and select the SQL tab. 3. Clear the Multiple SQL statements for each measure option by clearing the check box. 4. Add the following tables: Resolving SQL Traps Learner s Guide 191

204 CLIENT SALE RENTAL (as an alias of the SALE table) 5. Create the following joins and set the cardinality: Join Cardinality CLIENT.CLIENT_ID=SALE.CLIENT_ID 1:N CLIENT.CLIENT_ID=RENTAL.CLIENT_ID 1:N SALE.SALE_TYPE='S' 1:1 RENTAL.SALE_TYPE='R' 1:1 6. Create two classes: one called Chasm Objects, and the other called Measures. 7. Add the following objects with the following syntax: Object SELECT Qualification Client Name CLIENT.CLIENT_LASTNAME + ', ' + CLIENT.CLIENT_FIRSTNAME Dimension Sale Date SALE.SALE_DATE Dimension Rental Date RENTAL.SALE_DATE Dimension Sales Revenue Sum(SALE.SALE_TOTAL) Measure Rental Revenue Sum(RENTAL.SALE_TOTAL) Measure 8. Perform an integrity check on: Check Universe Structure Parse Objects Parse Joins 9. Save the universe. 10. In Web Intelligence Rich Client, create a new document with two control queries to display the correct sales and rental figures for Paul Brendt in the Chasm universe. In the first query, use the Sale Revenue, and Client Name objects. 192 Universe Design Learner s Guide

205 Select the Client Name object, and click the Apply a Quick Filter button. From the List of Values, select Brendt, Paul. In the second query, use the Rental Revenue, and Client Name objects. Select the Client Name object, and click the Apply a Quick Filter button. From the List of Values, select Brendt, Paul. 11. Click Run Queries and view the results in the report. What is the sale amount now? What is the rental amount? 12. In the same report add a new table by clicking the Edit Query button. Click Add Query, and create a new query using the Sale Revenue, Rental Revenue, and Client Name objects. Select the Client Name object, and click the Apply a Quick Filter button. From the List of Values, select Brendt, Paul. 13. Click View SQL to check the SQL statement generated. 14. Click Run Queries and select the Insert a table in the current report option. What is the sale amount in the new table? What is the rental amount in the new table? What happened to your figures? 15. Log out of Web Intelligence Rich Client. 16. In Universe Designer, edit the universe by clicking File Parameters SQL tab, and select the Multiple SQL statements for each measure option. 17. Save the universe. 18. In Web Intelligence Rich Client, create a new document using the Sale Revenue, Rental Revenue, and Client Name objects. Select the Client Name object, and click the Apply a Quick Filter button. From the List of Values, select Brendt, Paul. Click View SQL to check the SQL statement generated. What is the sale amount? What is the rental amount in the new table? What happened to your figures? 19. Edit the query by clicking the Edit Query button on the toolbar. 20. Remove the Sales Revenue, and the Rental Revenue objects. Drag the Sale Date, and Rental Date objects into the Report Panel. Click Run Query. What happens to the SQL and to the results? 21. Log out of Web Intelligence Rich Client. 22. In Universe Designer, edit the universe by clicking File Parameters SQL tab and clear the Multiple SQL statements for each measure option again (clear the check box). 23. Insert the following contexts: Resolving SQL Traps Learner s Guide 193

206 Context Joins Sale CLIENT.CLIENT_ID=SALE.CLIENT_ID SALE.SALE_TYPE='S' Rental CLIENT.CLIENT_ID=RENTAL.CLIENT_ID RENTAL.SALE_TYPE='R' 24. Save the universe. 25. In Web Intelligence Rich Client, create a new query with the Client Name, Sales Revenue, and Rental Revenue objects. Select the Client Name object and click the Apply a Quick Filter button. From the List of Values, select Brendt, Paul. What is the sale amount? What is the rental amount? What happened to your figures? 194 Universe Design Learner s Guide

207 Detecting and resolving fan traps This unit explains how fan traps can occur in the universe structure and how to resolve them. After completing this unit, you will be able to: Explain what a fan trap is Detect fan traps in the universe structure Resolve fan traps Fan traps Fan traps occur when there is a one-to-many join to a table that fans out into another one-to-many join to another table. This is a common structure and will not normally result in a fan trap. You only get incorrect results from the fan trap when the query includes a measure object on the middle table (B) of the table path and an object (of any kind) from the subsequent table (C). The trap only occurs where (due to the database design) a column in table B holds data values which are already a sum of those values held at table C. The results are normally noticeably wrong. When a query is run using objects Y and Z, the inferred SQL includes tables B and C which have a one-to-many relationship. This results in a value for the Y object being multiplied by the number of values of the Z object related to that Y object value. Like the chasm trap, the effect is similar to a Cartesian product. Like the chasm trap, the fan trap can be resolved by executing a separate SELECT statement for object Y and object Z. The alternate solution is to avoid it in the first place. You cannot automatically detect fan traps. You need to visually examine the direction of the cardinalities displayed in the table schema. If you have two tables that are referenced by measure objects and are joined in a series of many-to-one joins, then you may have a potential fan trap. Resolving SQL Traps Learner s Guide 195

208 The fan trap scenario This section demonstrates a fan trap in the Motors universe, and proposes solutions to the problem. In the diagram below, the Client and Sale tables are joined by a many-to-one-to-many relationship, as are the Sale and Sale_Model tables. The fan trap problem becomes apparent in a query that aggregates both an object based on the Sale_Total column in the Sale table, and an object based on the Sale_Qty column in the Sale_Model table. 196 Universe Design Learner s Guide

209 What happens in the fan trap When you run the Test 1 query to report the Sales Revenue for a client, the measure is correctly aggregated. This is a simple aggregate from one table in the fan trap structure. However, if you also wanted to know the number of vehicles the client has purchased, and you included the Number of Cars Sold object in the query, you get an inflated value returned for Sales Revenue. To understand what is happening, you need to look at the rows that are returned. Since two different Model ID numbers are involved in the Sale Quantity (Number of Cars Sold), there are two rows returned. As with chasm traps, a single SELECT statement joins each Model ID row with the same Sales Revenue row, which gives you the doubled figure. There is nothing to alert you to the situation, unless you look at the detail rows. Where you have a one-many-many relationship for tables in the FROM clause the resulting logical table produces something akin to a Cartesian product. Only then is aggregation applied. This is the reason for the fan effect. Resolving fan traps The recommended ways to solve a fan trap problem are: Alter the SQL parameters for the universe. Use a combination of aliases and contexts. Avoid the fan trap scenario. Alter the SQL parameters for the universe This method is not recommended as it only works for measure objects and may result in inefficiencies in processing the query. This resolution works the same for chasm and fan traps. Use a combination of aliases and contexts There are two possible situations which may require different solutions. If you have... Three tables in a one-to-many relationship A dimension coming from the first table and measures Then... Create an alias for the table (on the many end of the join) containing the initial aggregation, joining it back to the non-aggregation table (on the one end of the join). Use the Detect Contexts tool to detect and propose a context for the alias table and a context for the original table. Resolving SQL Traps Learner s Guide 197

210 If you have... Then... coming from the two subsequent tables This is the most effective way to solve the fan trap problem because it works with measure and dimension objects and does not cause inefficiencies. Two tables in a one-to-many relationship A dimension and a measure coming from the first table and a measure coming from the subsequent table(s) Create an alias for the table containing the initial aggregation, joining it back to the original table and then use the Detect Contexts tool to detect and propose a context for the alias table and a context for the original table. Both of these methods solve the fan trap problem because they will work with both measure and dimension objects and do not cause inefficiencies. You will explore both in the following sections. Note: However, to be more efficient still, using the two-table scenario, you could also use function. Avoid the fan trap scenario You can avoid the scenario in the first place by relating all measure objects in the universe to the same table in the universe structure. Avoid placing a measure on anything other than the last table in a table path, which is the table with the many cardinality attached to it. Using aliases and contexts to resolve fan traps You create an alias table for the table producing the aggregation and then detect and implement contexts to separate the query. This procedure is demonstrated in the diagram below: In this scenario your schema would look similar to: 198 Universe Design Learner s Guide

211 The SELECT clause of the Sales Revenue object needs to be edited, so that it refers to the alias table rather than the original Sale table. As with resolving a chasm trap problem, two contexts need to be created. In this example, a context for Sale, and a context for Sale_Model need to be defined. This allows for the results to be merged into a single microcube to produce the correct results. Moreover, if you make a query which includes a dimension object on the lower table in the one-many-many path, you will not suffer the fan trap, even when that dimension object contains the same value for all rows related to the measure value. The fact that the measure and dimension objects are in separate contexts forces two separate SELECT statements, thus avoiding the problem. To use aliases and contexts to resolve a fan trap 1. Identify the potential fan trap by analyzing the one-to-many-to-one-to-many join path relations in the schema. 2. Create an alias for the table that is producing the multiplied aggregation. 3. Create a join between the new alias table, and the table that holds the dimension information. 4. Set cardinality. 5. Set contexts. 6. Change the SELECT clause of the measure object so that it refers to the alias table rather than the original table. Resolving SQL Traps Learner s Guide 199

212 7. Create a query using a measure object from the alias table and another measure from the subsequent table in the table path of the universe structure. This results in two SELECT statements and the data is merged into a single microcube to produce the correct results. Solving a fan trap with two tables in a one-to-many relationship The structure shown here involves two tables instead of three. In this example, both a dimension and measure object are from the same table, and another measure is from a table in a one-to-many relationship further along the universe structure. To resolve this type of fan trap, you can: 1. Create an alias of table A. 2. Create a join from the alias An to table A and set cardinalities. 3. Set contexts B and A. 4. Edit object Y so that it refers to columns in the alias An rather than table A. In the universe structure shown below, you have created an alias table of the Sale table and created a join between the alias and the original table. This is to separate the dimension in Sale from the measure, which will now refer to Sale_Alias. 200 Universe Design Learner s Guide

213 To use aliases in a fan trap involving only two tables 1. Create an alias of the table that contains both dimension and measure values. 2. Create a join between the new alias table, and the original table. 3. Force the cardinality for this join to N:1. 4. Set contexts. 5. Change the SELECT clause of the measure object so that it refers to the new alias table rather than the original table. 6. Save the universe. 7. In Web Intelligence Rich Client, test the solution using a dimension object from the original table, a measure object from the alias table, and a measure from the second table in the schema. When you look at the SQL in the SQL Viewer, there will be two SELECT statements. Note: Aggregate awareness provides another solution to this problem. Avoiding fan traps altogether In certain situations, it is possible to avoid the fan trap completely, as shown in the diagram below. To avoid the trap, the database column in table B to which the Y measure object relates must represent a preaggregation of more detailed data in table C. If this is the case, you can change Resolving SQL Traps Learner s Guide 201

214 the code of the Y measure object so that it refers to table C. Hence, there is no longer a one-to-many relationship incurred. This is the method used to avoid the fan trap in the Motors universe, when the Sales Revenue and Number of Cars Sold measure objects are included in the same query. In the Motors universe you have created during this course, the Sales Revenue measure is not based on the total figure in the SALES table but on a number of columns from the Sale, Sale_Model and Model tables which are held in the database at the same level of granularity as the number of cars sold. Hence, no fan trap exists and the correct result will be obtained. Note: Another method of resolving a less common form of fan trap is by using Aggregate Awareness. 202 Universe Design Learner s Guide

215 Activity: Resolving fan traps Objective Detect contexts to resolve a fan trap in the universe structure. Instructions 1. Create a universe called Fans.unv. Use the Motors_conn connection to connect to the Motors database. 2. Select File Parameters from the menu bar or click the Parameter button and select the SQL tab. 3. Clear the Multiple SQL statements for each measure option by clearing the check box. 4. Add the following tables: CLIENT SALE SALE_MODEL 5. Create the following joins and set the cardinality: Join Cardinality CLIENT.CLIENT_ID=SALE.CLIENT_ID 1:N SALE.SALE_ID=SALE_MODEL.SALE_ID 1:N SALE.SALE_TYPE='S' 1:1 6. Create a class called Fan Objects. 7. Add the following objects with the following syntax: Object SELECT Qualification Resolving SQL Traps Learner s Guide 203

216 Client Name CLIENT.CLIENT_LASTNAME + ', ' + CLIENT.CLIENT_FIRSTNAME Dimension Model ID SALE_MODEL.MODEL_ID Dimension Sale Quantity Sum(SALE_MODEL.SALE_QTY) Measure Sales Revenue Sum(SALE.SALE_TOTAL) Measure 8. Perform an integrity check on: Check Universe Structure Parse Objects Parse Joins 9. Save the universe. 10. In Web Intelligence Rich Client, create a new document using the Sales Revenue and Client Name objects. Select the Client Name object and click the Apply a Quick Filter button. From the List of Values, select Crandall, Sean. 11. Click Run Query and view the results in the report. What is the sale amount? 12. Edit the query and add the Sale Quantity object. What is the sale amount now? What is the sale quantity? 13. Log out of Web Intelligence Rich Client. 14. In Universe Designer, edit the universe by clicking File Parameters SQL tab and select the Multiple SQL statements for each measure option. 15. Save the universe. 16. In Web Intelligence Rich Client, create a new document using the Sales Revenue, Sale Quantity, and Client Name objects. Select the Client Name object and click the Apply a Quick Filter button. From the List of Values, select Crandall, Sean. 17. Click Run Query and view the results in the report. What is the sale amount? What is the sale quantity? 18. Edit the query and add the Model ID object. What is the total sale amount? What is the total sale quantity? How many different models were purchased? What happened to your figures? 204 Universe Design Learner s Guide

217 Tip: To retrieve the sum value, highlight the relevant measure column without highlighting the header, and select the Insert Sum toolbar icon. 19. Log out of Web Intelligence Rich Client. 20. In Universe Designer, edit the universe by clicking File Parameters SQL tab and clear the Multiple SQL statements for each measure option by clearing the check box. Select the Multiple SQL statements for each context option if it is not already selected. 21. Add an alias to the SALES table (SALES2). 22. Create the following joins: Join Cardinality CLIENT.CLIENT_ID=SALE2.CLIENT_ID 1:N SALE2.SALE_TYPE='S' 1:1 Note: Force the cardinality on CLIENT.CLIENT_ID=SALE2.CLIENT_ID join to 1:N. 23. Use the Detect Contexts button to detect contexts. Be sure you have the following contexts. You may have to edit the context by removing or adding joins. Context Joins CLIENT.CLIENT_ID=SALE.CLIENT_ID Sale Model SALE.SALE_ID=SALE_MODEL.SALE_ID SALE.SALE_TYPE='S' Sale2 CLIENT.CLIENT_ID=SALE2.CLIENT_ID SALE2.SALE_TYPE='S' 24. Modify the definition of the object that is performing multiple aggregations so that it points to the alias table: Object SELECT Qualification Sale Revenue Sum(SALE2.SALE_TOTAL) Measure 25. Save the universe. 26. In Web Intelligence Rich Client, create a new document using the Sales Revenue, Sale Quantity, and Client Name objects. Select the Client Name object and click the Apply a Quick Filter button. From the List of Values, select Crandall, Sean. 27. Click Run Query and view the results in the report. Resolving SQL Traps Learner s Guide 205

218 o o o o What is the total sale amount? What is the total sale quantity? How many different models were purchased? What happened to your figures? 206 Universe Design-Learner's Guide

219 Quiz: Resolving SQL traps 1. A chasm trap can occur when: 2. Describe two ways to resolve chasm traps. 3. Describe three ways to resolve fan traps. Resolving SQL Traps Learner s Guide 207

220 Lesson summary After completing this lesson, you are now able to: Understand SQL traps and universes Resolve fan traps Resolve chasm traps 208 Universe Design Learner s Guide

221 Lesson 9 Applying Restrictions on Objects Lesson introduction This lesson will help you understand and use restrictions, which are conditions in SQL that set criteria to limit the data returned by a query. After completing this lesson, you will be able to: Restrict the data returned by objects Applying Restrictions on Objects Learner s Guide 209

222 Restricting the data returned by objects A restriction is a condition in SQL that sets criteria to limit the data returned by a query. You define restrictions on objects to limit the data available to users. Your reasons for limiting user access to data depend on the data requirements of the target user. A user may not need access to all the values returned by an object. You might also want to restrict user access to certain values for security reasons. After completing this unit, you will be able to: Define data restrictions Apply data restrictions to objects Apply data restrictions using condition objects Apply restrictions to tables Apply data restrictions using the Tables button Apply each type of restriction Defining data restrictions The WHERE clause in an SQL statement restricts the number of rows that are returned by the query. So far in your universe design work, the WHERE clauses have only been populated by the joins you made between the tables in the Structure pane. The joins restrict the resultsets, usually based on equality between tables and prevent Cartesian products. You can also use the WHERE clause to further restrict the data that is returned in a query in circumstances where you may want to limit certain users to query on a subset of the data. For example, the report below is an unrestricted block containing data for Clients from all Countries: 210 Universe Design Learner s Guide

223 The WHERE clause for the query is created from the SQL inferred from the joins made in the Structure pane: WHERE (COUNTRY_REGION.COUNTRY_ID=REGION.COUNTRY_ID) AND (REGION.REGION_ID=CLIENT.REGION_ID) AND (SALE_MODEL.MODEL_ID=MODEL.MODEL_ID) AND (SALE.SALE_ID=SALE_MODEL.SALE_ID) AND (CLIENT.CLIENT_ID=SALE.CLIENT_ID) AND (SALE.SALE_TYPE='S') AND (SALE.SALE_DATE between FINANCE_PERIOD.FP_START and FINANCE_PERIOD.FP_END) Compare this with the following report, which is a restricted block containing data only for clients from the United Kingdom: The WHERE clause for the query now has an extra line at the bottom. This is the restriction added by the designer that limits the return of data to UK Clients: WHERE (COUNTRY_REGION.COUNTRY_ID=REGION.COUNTRY_ID) AND (REGION.REGION_ID=CLIENT.REGION_ID) AND (SALE_MODEL.MODEL_ID=MODEL.MODEL_ID) AND (SALE.SALE_ID=SALE_MODEL.SALE_ID) AND (CLIENT.CLIENT_ID=SALE.CLIENT_ID) AND (SALE.SALE_TYPE='S') AND (SALE.SALE_DATE between FINANCE_PERIOD.FP_START and FINANCE_PERIOD.FP_END) AND (COUNTRY_REGION.COUNTRY_NAME = United Kingdom Methods of restricting data in end-user modules Within the design of a universe, you can either: Force restrictions, which the end user cannot override: Object, Table, Conditional SELECT, Additional Joins Provide optional restrictions, which the end user can choose to apply: Condition Objects Remember that users can apply conditions themselves by way of the Report Panel. Therefore, avoid creating optional restrictions that are of a simple nature, as the end user should be capable of creating such conditions for themselves on a query-by-query basis. There are often problems associated with inferred restrictions, as will become evident during this module. You are therefore advised only to force restrictions where they are absolutely necessary. Applying Restrictions on Objects Learner s Guide 211

224 To ensure that a restriction is always inferred when a particular object is used in an end-user query, place the restriction in the Where box of the Definition tab in the Edit Properties dialog box related to the object. You can do this when you create the object or you can add it later. To apply a restriction to an object 1. Open the Edit Properties dialog box for the object and select the Definition tab. 2. Enter the restriction directly in the Where field, or via the Edit Where Clause dialog box by selecting the >> button. 3. Click OK. When you have created or edited your object to include a restriction, you should test it by running a new query using a BusinessObjects end-user query tool. Always view the inferred SQL to check whether the SELECT statement includes the restriction in the WHERE clause and has the desired effect. Remember to save your universe before doing this. The inferred SQL displays the restriction. The last line of the WHERE clause is taken from the object restriction. Drawbacks to applying restrictions to objects Only create restrictions against objects when it is absolutely necessary. For example, consider the situation where users of Motors need to make queries of only those cars that can be rented. The only distinguishing factor in the underlying Motors database between cars that can be rented and those that are stocked for sale is that the Model.Model_Dayrent column contains data for rental cars and is null for sale-only cars. To create an object to list cars for rental, the object would have to include the restriction: Model.Model_Dayrent is not null. If it is not necessary, do not create the restriction. To see why, consider the implications of creating a UK Clients object as illustrated: 212 Universe Design Learner s Guide

225 The drawbacks are as follows: You would get a confusing proliferation of objects for end users because you would then need a French Clients object, a German Clients object, and so on. As these objects would all represent alternate restrictions, you would not be able to construct a logical default hierarchy, which end users make use of when drilling down. Although the UK Clients example is fairly clear, in many cases the restriction will not be obvious to the user simply from the name of the object: the details of the WHERE clause are not shown in the end-user interface. If two or more similarly restricted objects are included in the same query, the conflict between the WHERE clauses will cause no data to be returned. Consider the situation if a user wanted data for UK Clients and US Clients. You might think that including both the UK Clients and US Clients objects would meet that need. However, the inferred SQL for the query would include the following two lines: AND (CLIENT_COUNTRY.COUNTRY_NAME = United Kingdom ) AND (CLIENT.COUNTRY.COUNTRY_NAME = USA ) As no country satisfies both these conditions, no data is returned. An alternative to applying restrictions to objects There is an alternative to applying restrictions to objects without using WHERE clauses. You will still have multiple objects, but you will avoid the conflicts that affect the return of data in queries. This method involves using a conditional SELECT clause for the object instead of a WHERE clause. Applying Restrictions on Objects Learner s Guide 213

226 For example, if you want to force users to select financial results by year, you could create a series of Sales Revenue objects (one for each year). Each object would be edited, starting from the standard sum aggregate used in the basic Sales Revenue SELECT statement: You would apply the condition for each year using the database function that applies IF THEN ELSE logic. For Sales Revenue 2003, the SELECT statement would look like this: Note: The Else value 0 is optional. For Sales Revenue 2004, the SELECT statement would look like this: Note: Many databases support the CASE function. Consult the documentation provided by your database vendor to see what types of conditional functions are supported. After you have created or edited the objects, test them individually and together in a single query. When you view the SQL to check whether the inferred SELECT statement includes the conditional SELECT syntaxes, the SQL appears as follows: When the query is run, the report looks similar to this: 214 Universe Design Learner s Guide

227 The conditional SELECT statements have removed the problem of the conflicting WHERE clauses. The data correctly shows the 2003 and 2004 Sales Revenue for each client. Restrictions using condition objects A condition object, or predefined query filter, is a preset restriction created in Universe Designer that a user can choose whether or not to apply to a query. When users create queries they can create their own query filters to limit the data returned by the query. They can also use the predefined query filters that the universe designer may have built into the universe to make it easier for them to restrict the data. In Web Intelligence Rich Client, the predefined query filter built into the universe can be viewed in the Report Manager Data tab, identified as predefined query filters. For example, if the designer has created condition objects for French Clients and UK Clients, the Predefined Conditions tab would contain these condition objects: When you have created a condition object in Universe Designer, test it in Web Intelligence Rich Client by making a query that uses the filter. View the SQL to check that the inferred SELECT statement includes the restriction in the WHERE clause and has the desired effect. The advantages of using condition objects Useful for complex or frequently used conditions Gives users the choice of applying the condition No need for multiple objects Applying Restrictions on Objects Learner s Guide 215

228 Condition objects do not change the user view of the dimension objects in the Classes and Objects tab in the Web Intelligence Rich Client Report Panel To create a condition object 1. In Universe Designer, select the Filter option button at the bottom of the Universe pane. The Universe pane changes to show the Condition Object View. Note: Objects are not shown in the Condition Object View, but classes are. You add a condition object to a particular class. Also, be aware that deleting a class in the Condition Object View will delete that class from the whole universe, not just from this view. 2. Click the class in which you want to place the condition object. 3. There are two ways you can insert a condition: Select the Insert Condition on the Editing toolbar. Right-click the class and choose Condition from the drop-down menu. This opens the Edit Properties dialog box for condition objects. 4. In the Name field, enter a name for the condition object. 5. In the Description field, enter a help message for users describing the condition and any effect it will have on queries they make. 6. Enter the condition directly in the Where field or via the Edit Where Clause dialog box by selecting the >> button. 7. Click OK. 8. Save the universe. The new predefined condition object built into the universe can be viewed in Web Intelligence Rich Client in the Report Panel Data tab. Applying restrictions using the tables button If a table in your database has a flag that is used to switch between two or more domains, you can use this to apply restrictions at the table level. For example, the Sale table in the Motors database has a column called Sale_Type, which is used to distinguish between sales transactions and rentals transactions. The flag is set to S for sales or R for rentals. If you do not apply any restriction to this table, users running queries for sales (with appropriate objects) will get a resulting report that includes data on rentals as well as sales. Therefore, the results will be wrong. You can apply a restriction to this table using a self-restricting join. The self-restricting join appears as a stub join in the Structure pane: 216 Universe Design Learner s Guide

229 The expression in the Edit Join dialog box is set as follows: With this restriction in place, the data returned will be restricted to sales data, no matter where the table is used in the inferred SQL. For example, if the Sale table appears only in the FROM clause of the SQL, the restriction will still be applied in the WHERE clause. This is the main advantage of applying restrictions at the table level. A lookup table in a database can be used to provide a description for more than one dimension from a database. For example, in the Motors database, the Country table contains a single list of countries, but these include the country from which clients come, the country where a car showroom is located, and the country where a car maker is located. As a designer, you can create objects from the Country table for use in the Client class (for the Client Country), in the Car class (for the car Maker Country), and in the Showroom class (for the Showroom Country). We have done this in previous lessons and avoided loops by creating the appropriate alias tables. If a user ran a query to answer the question: Which countries do our showrooms exist in?, you might think that a simple query using only the Showroom Country object in the Showroom class would provide the answer. However, in the current universe, such a query would actually infer SQL that returns all countries held in the Showroom_Country table. SELECT SHOWROOM_COUNTRY.COUNTRY_NAME FROM SHOWROOM_COUNTRY To solve this problem, the Showroom Country object in the Showroom class must be restricted so that it returns only country data relating to showrooms. This is done by specifying that whenever the Showroom Country object is used in a query, the Showroom table must also be inferred in the FROM clause of the SELECT statement. Providing that the Showroom_Country table is joined to the Showroom table (by intervening tables) using Applying Restrictions on Objects Learner s Guide 217

230 only equi-joins, the object is then guaranteed to only return countries in which showrooms exist. To restrict data by adding tables to the object definition 1. Double-click the object you want to restrict. The Edit Properties dialog box for the selected object displays. 2. Click the Tables button. The Tables dialog box appears. 3. Scroll down the list of tables until you can see the table that is already highlighted. 4. Hold down the Ctrl key and click an additional table to force joins between the selected tables. 5. Click OK to close the Tables dialog box. 6. Click Apply in the Edit Properties dialog box. 7. Click OK. Applying each type of restriction Apply restrictions to objects when you need to force a restriction on users. However, the forced restriction is not automatically inferred whenever the table is included in the SQL. Be aware of the drawbacks of multiple objects and conflicting restrictions. Use conditional SELECT statements instead. Use condition objects when you want to assist users by providing optional filters, and when it is important to avoid multiple objects and changes to the Classes and Objects view. Use self-restricting joins to apply restrictions to tables when you want the restriction to apply, irrespective of where the table is used in the SQL. This method is ideal when a table uses a flag to switch between two or more domains. Use additional joins when a lookup table serves more than one purpose in the universe. This method ensures that the user gets the correct answer to the question behind the query. Activity: Applying restrictions Objective Apply enforced restrictions to objects and tables and create optional restrictions using condition objects. Instructions The sales staff of Prestige Motors needs to drill from Day Rental Range through Model Day Rental Charge to Model for Rental to deal with queries from potential customers. 218 Universe Design Learner s Guide

231 1. Create a Model for Rental dimension object in the Day Rental Charges subclass. This object will have the same SELECT properties as the Model object. 2. Add a WHERE restriction to the Model for Rental object so that only models available for rent are returned. The restriction is: MODEL.MODEL_DAYRENT IS NOT NULL 3. Create a US Clients dimension object in the Client class below the Client Name object with the settings: Type = Character Description = Returns only data for clients in the USA Select syntax: CLIENT.CLIENT_LASTNAME + ', ' + CLIENT.CLIENT_FIRSTNAME Where syntax: COUNTRY_REGION.COUNTRY_NAME = 'USA' 4. Create another object in the Client class for UK Clients. 5. Save the universe, then test the two new Client objects in Web Intelligence Rich Client: Build a query containing UK Clients, US Clients, and Sales Revenue objects The query returns no data because of the conflict of restrictions. 6. In Universe Designer, create a new subclass below the Sales class called Annual Revenue. Populate it with separate Sales Revenue measure objects for the calendar years 2003 and 2004 as indicated below. Use the CASE function to do this Sales Revenue 2004 Sales Revenue 7. In the Annual Revenue subclass create two separate Sales Revenue measure objects related to financial years FY03-04 and FY04-05 as indicated below. Use the CASE function to do this. Sales Revenue for FY03-04 Sales Revenue for FY Save the universe, then test the two new calendar year Sales Revenue objects in Web Intelligence Rich Client: Build a query containing Showroom, 2003 Sales Revenue, and 2004 Sales Revenue objects. Replace 2003 Sales Revenue and 2004 Sales Revenue objects with the objects related to financial years FY03-04 and FY04-05, instead of calendar years. 9. Remove the US and UK objects in the Client class that you just created, and create the following condition objects instead: A condition object for US Clients A condition object for European Clients (excluding UK; UK clients are part of the Other Clients condition object) A condition object for Other Clients Applying Restrictions on Objects Learner s Guide 219

232 10. Save the universe and test each restriction by building a query in Web Intelligence Rich Client. 11. Run a query using Showroom Country to see the list of countries that have showrooms. 12. In Universe Designer, edit the properties of the Showroom country object by adding the Showroom table to the list of tables associated with the object. Use the Tables button in the Edit Properties, Definition tab of the object to do this. 13. Save the universe. 14. In Web Intelligence Rich Client, run the above query again and compare the results. 15. In Universe Designer, ensure that the Client Country object will only return the countries in which clients exist, whichever query is run. Do this by adding the Client table to the list of tables associated with the object. 16. Edit the Maker Country object in the same way, to ensure that it only returns the countries in which car makers exist. 17. Edit the Franchise object so that it automatically infers the FRANCHISE context instead of prompting the user to choose among the SALES, RENTALS and FRANCHISE contexts. This allows end users to report on the franchises and their location regardless of sales or rentals information. Use the Tables button to highlight the MAKER and FRANCHISE tables. 18. Check the integrity of the universe. 19. Save the universe. 220 Universe Design Learner s Guide

233 Quiz: Applying restrictions on objects 1. What is a restriction? 2. Explain two drawbacks of using restrictions at the object level. 3. When should you use self-restricting joins? Applying Restrictions on Objects Learner s Guide 221

234 Lesson summary After completing this lesson, you are now able to: Restrict the data returned by objects 222 Universe Design-Learner's Guide

235 Lesson 10 with Objects Lesson introduction This lesson will help you use to provide more flexible methods for specifying the SQL for an object. After completing this lesson, you will be able to: with Objects Learner s Guide 223

236 are located in the Functions panel of the Edit Select Statement and in the Edit Where Clause dialog boxes for objects. After completing this unit, you will be able to: Use function Use function Use function Describe function In the Edit Properties dialog box of an object, if you look in the Functions panel of either the Edit Select Statement dialog box or the Edit Where Clause dialog box, you will find a list The most commonly @aggregate_aware(,) These functions can be applied in the Select and/or Where dialog boxes @aggregate_aware Can be used in... Both Select and Where clauses Only to be used in Select clauses Only to be used in Where clauses Only to be used in Select clauses are used to provide flexible methods of specifying function is used by the designer to force the end user to enter a value for a restriction when a query is run which includes the object in which is specified. This is done by placing a restriction based on in the Where field of the Edit Properties dialog box of an object. When the user runs a query including that object, a prompt dialog box appears requesting a value to be entered. It can be useful when you want to force a restriction in the inferred SQL but do not want to preset the value of the condition. For example: 224 Universe Design Learner s Guide

237 In the example, the object Model for Rental is to be used by a salesman to list the models that can be rented. However, different models are rented from different showrooms. Hence, you would want to restrict the returned list to cars rented from a single showroom. If you hard coded the restriction, you would need a separate object for each showroom in the universe. Using you need only syntax syntax consists of five parameters, separated by commas: Prompt Data type (A, N, or D) LOV pointer or hard-coded list Mono or multi Free or constrained Primary key Persistent or not persistent 'Default value':'key value' The first two parameters are mandatory, and the remaining parameters are optional. Note: The first three parameters must be inside single quotes. The last three parameters; primary key, persistent/not persistent, and 'default value: key value', are newly added in BusinessObjects XI 3.0. The full syntax of function is as mono/multi,free/constrained/primary_key, with Objects Learner s Guide 225

238 persistent/not_persistent, [{'default value':'default key' [,'default value':'default key',...]}) For example: SHOWROOM.SHOWROOM_Name Showroom Name','A', 'Showroom\Showroom', Mono, Constrained) Prompt This is the text, or question, that appears in the prompt dialog box when the query is run. The text must be enclosed in single quotes. Data type Data type refers to a character to specify the type of data that will be returned: A for alphanumeric N for numeric D for date The specified character must be enclosed in single quotes. List of values (optional) There are two methods of specifying a list of values: A hard-coded list: Each value is separately enclosed in single quotes and separated by a comma and the whole list is enclosed in curly brackets. For example: {'Australia', 'France', 'Japan', 'United Kingdom', 'USA'} A pointer to a list of values from an existing object: This can be invoked by double-clicking the object whose list of values you want to use in the Classes and Objects pick list. This gives the class name and the object name, separated by a back-slash. It must be enclosed in single quotes. For example: 'Client\Country' Mono or multi (optional) Mono: Allows the user to select or enter a single value from the list of values. Multi: Allows the user to select or enter multiple values from the list of values. Free or constrained (optional) Free: Users can enter a value of their own, or pick one from the list of values. Constrained: Users can only choose a value from the list of values. 226 Universe Design Learner s Guide

239 Primary key Use the primary key parameter with "free" or "constrained". The user enters a value or selects from the list of values. If the primary key parameter is present, the entered or displayed value is not used to generate the query. The associated key value from the index awareness column is used. Persistent or not persistent Persistent: When refreshing a document, the last values used in the prompt is displayed by default. Not persistent: When refreshing a document, no values used is displayed in the prompt by default. 'Default value':'key value' The default values parameter is used to define default values presented to the user. You can define multiple default values. The syntax for each default value is: value : key. The colon (:) is the separator between the value and the key. When refreshing a document these values are displayed by default but if the persistent option is set, then the last values used in the prompt are used instead of the default values. If you specify the primary key parameter in the prompt definition, then you must provide the key value(s) for City:', 'A','City Class\City',Multi,Constrained, value(s) for Client Name: ', 'A','Client\Client Name',Multi,primary_key, { Baker : 1, Brendt : 2 function is a pointer to the Select dialog box properties of another object. It is used by placing in the Select field of the Edit Properties dialog box of an object, using the following of existing object) You specify the path in the form Class_Name\Object_Name. The purpose of function is to allow you to reuse existing code, giving the advantage of having to specify SQL code only once. Specifying SQL only once has two key advantages: You need to maintain only one instance of the SQL code. It ensures consistency of the code. For example: with Objects Learner s Guide 227

240 This shows how works. The code in the SELECT properties of the Model object is: MODEL.MODEL_NAME+' ' + MODEL.MODEL_TRIM+' '+MODEL.MODEL_ENGINE If you wish to create a new object called Model for Rental with the same code, rather than creating the same code twice, you can refer to the original Model object via 228 Universe Design Learner s Guide

241 The benefit is that a dynamic link is created between the objects. When changes occur in the SELECT statement of the original object, the changes are reflected in the SELECT statement of any other objects that refer to it via function. Therefore, when you change the code, you only change it once in the original function is a pointer to the Where dialog box properties of another object. It is used by placing in the Where field of the Edit Properties dialog box of an object, using the following of existing object) For example: with Objects Learner s Guide 229

242 This shows how works. The code in the Where properties of the Model for Rental object is: MODEL.MODEL_DAYRENT IS NOT NULL AND SHOWROOM.SHOWROOM_NAME Showroom Name', 'A','Showroom\Showroom',mono,constrained) If you wish to create a new object called Showroom Rental Model that has to contain the same WHERE syntax, rather than creating the same code twice, you can refer to the original Model for Rental object via Rental Charges\Model for Rental) 230 Universe Design Learner s Guide

243 The benefit is that a dynamic link is created between the objects. When changes occur in the WHERE statement of the original object, the changes are reflected in the WHERE statement of any other objects that refer to it via function. Therefore, when you need to change the syntax, you only change it once in the original object. Note: You can use function in a condition object to point to an object, but not the other way around. As its purpose is to allow you to reuse existing code, and it has the same advantages: You need to maintain only one instance of the SQL code. It ensures consistency of the code. There are further benefits for using function. If there are a number of objects and/or condition objects that require the same restrictions to be placed upon them, you could use a WHERE restriction object strategy to make the most efficient use of that restriction s code. with Objects Learner s Guide 231

244 The idea behind the strategy is that you create a new and separate object for every restriction required, in a separate class to the normal object classes. Then, within the original objects, whenever a restriction is required, you point to the appropriate WHERE restriction object using function. In the previous example, you can see that two Where clause restriction objects have been created that contain only a name and Where clause restriction, as follows: Rental model MODEL.MODEL_DAYRENT IS NOT NULL Showroom choice SHOWROOM.SHOWROOM_NAME ('Enter Showroom Name','A', 'Showroom\Showroom',mono,constrained) Note that each of the Where clause restriction objects do not have SELECT properties specified. pointer can now be used to specify the restrictions required for the object called Model for Rental without the need to double up on the WHERE syntax. Also, by specifying each restriction in a separate Where clause restriction object, the strategy has enabled you to build up the multiple restrictions on the object one step at a time. This is particularly useful when creating complex restrictions on an object. Moreover, the individual restrictions can be used for other objects and condition objects. In the example above, the Where clause restriction object called Showroom Choice has also been used for the Showroom condition object. For this strategy to work, you need to be able to hide the class containing all the Where clause restriction objects from end users. The Where clause restriction object strategy has a number of advantages: Maintenance is easy because only a single instance of each restriction is required. The restrictions are easy to find. They are all under a single class. Restrictions can be mixed and matched without the need for repetition. To hide the class containing all the Where clause restriction objects from end users 1. Click the class or object you want to hide. 2. There are different ways to hide classes and objects: Select the Show or Hide Item button on the Edit menu. Right-click the object or class and select Hide Item(s) from the drop-down menu. Use Ctrl+Shift+H. Hidden classes and objects appear in italics in the Universe Designer Universe pane. They are not shown at all in Business Objects end-user querying tools. 232 Universe Design Learner s Guide

245 @aggregate_aware Some databases contain Summary Tables. These tables are created by the Database Administrator (DBA) and contain figures such as revenue aggregated to a high level (year, for example) rather than to the fact/event level. The summary tables are usually populated and updated regularly by an automated program that runs SQL against the fact or event data at transaction level. This means that there are two methods that you can use to return aggregated data: Run a SELECT statement for the fact or event data Run a SELECT statement for the summary data Where possible, it is best to choose the latter method as the statement will process quicker. In Universe Designer, you can use a function in the SELECT statement for an object, so that both methods are referenced. This function directs a query to run against aggregate tables whenever possible. If the data in the aggregate table is not calculated at the level of granularity required to run the query, the object will direct the query to run against the tables containing the non-aggregated data. A universe that has one or more objects with alternate definitions based on aggregate tables is said to be aggregate aware. These definitions correspond to levels of aggregation. For example, an object called Profit can be aggregated by month, by quarter, or by year. The reliability and usefulness of aggregate awareness in a universe depends on the accuracy of the aggregate tables. They must be refreshed at the same time as all fact tables. When you apply function, be aware of the available levels, and be clear about the descending order of aggregation. Each aggregation level SELECT statement is separated by a comma, and the entire expression is enclosed in brackets. The final SELECT statement must be valid for all statement for highest agg level>, <SELECT statement for second highest agg level>,.. <SELECT statement for second lowest agg level>, <original SELECT statement for basic agg calculation>) Note: Setting up aggregate awareness in a universe is a four-part process. For more information, refer to the BusinessObjects XI 3.0: Designer s Guide. Activity: Objective to objects and condition objects. Continue to work with the Model for Rental dimension object that you created in the Day Rental Charges subclass. This object returns all models available for rental. This is to be used by sales staff and requires further restriction to a specific showroom. Instructions 1. Use function to achieve this. The parameters for are: with Objects Learner s Guide 233

246 Prompt = 'Enter showroom name' Data type = 'A' LOV = 'Showroom\Showroom' Mono Constrained 2. The SELECT properties of the Model and Model for Rental objects are the same. Use in the Model for Rental object to point to the SELECT properties of the Model object. 3. Create a new condition object called Showroom Rental Model in the Showroom class. The Where clause restrictions for this condition already exist in the Model for Rental object. Use function in the condition object to point to the where properties of the Model for Rental object. 4. Create a new class called Where Restriction Objects. 5. Create two new objects to go into the Where Restriction Objects Class as follows: Rental Model containing the restriction: MODEL.MODEL_DAYRENT IS NOT NULL Showroom Choice containing the restriction: SHOWROOM.SHOWROOM_NAME ('Enter showroom name', 'A', 'Showroom\Showroom', mono, constrained) 6. Hide the Where Restriction Objects Class. 7. Edit the following object and condition object so that the WHERE clause of each contains no SQL code, but instead functions to point to the Where clause restriction objects. Model for Rental object inherits the Rental Model object s WHERE clause. Showroom Rental Model condition object inherits the Showroom Choice object s WHERE clause. 8. The SELECT properties of the Rental Date and Return Date objects contain RENTAL.SALE_DATE. Use in the Return Date object to point to the SELECT properties of the Rental Date object to avoid duplication of SQL code. 9. Create a Maker Choice condition object under the Car class that, when used in a query, produces a prompt dialog box requesting the user to enter a single manufacturer. 10. Check the integrity of the universe. Note: The Integrity Check dialog box alerts you regarding the two hidden objects. 11. Save the universe. Note: Remember to test your solution in Web Intelligence Rich Client. 234 Universe Design Learner s Guide

247 Quiz: with objects 1. What parameter does require? 2. True or False. You can use function in a condition object to point to an object, but not the other way round. 3. What function is used to create an interactive object that causes a message to appear at query runtime, that asks the user for specific input? 4. In two parameters are mandatory and three are optional. What parameters are optional? with Objects Learner s Guide 235

248 Lesson summary After completing this lesson, you are now able to: 236 Universe Design-Learner's Guide

249 Lesson 11 Using Hierarchies Lesson introduction Hierarchies allow you to organize dimension objects so that users can perform multi-dimensional analysis using drill mode in end-user queries. After completing this lesson, you will be able to: Understand hierarchies and universes Work with hierarchies Using Hierarchies Learner s Guide 237

250 Understanding hierarchies and universes Hierarchies in universes allow users to create reports that are enabled for multi-dimensional analysis with drill mode. After completing this unit, you will be able to: Explain how hierarchies allow users to drill down to different levels of detail using drill mode in end-user queries. Hierarchies A hierarchy is an ordered series of related dimension objects that are used for multi-dimensional analysis. For example, a geographical hierarchy could group together dimension objects such as Country, Region and City. Multi-dimensional analysis is a technique for manipulating data so that it can be viewed from different perspectives and at different levels of detail. In Business Objects end-user querying tools, users can analyze data at different levels of detail using a feature known as drill mode. The example below shows a hierarchy of the dimension objects Country, Region and City. At the highest level, the user will see a Country. At the next level down, the Country is broken down into more detail: the regions. At the next lower level, the regions are broken down into more detail: the cities. A user can then analyze a measure object, such as Sales Revenue, against any of the levels in the hierarchy. Natural hierarchies A natural hierarchy is one that follows a naturally occurring pattern from the most general at the highest level to the most detailed at the lowest level. Examples of natural hierarchies can be found in the geographical definitions of places and in the measurement of time: Country, Region, State, City, District, Street Year, Quarter, Month, Week, Day Logical hierarchies BusinessObjects hierarchies are not restricted to natural hierarchies. You can construct a hierarchy from any related group of dimension objects that will create a sensible analysis path. The relationship between the dimension objects in a hierarchy normally will be one-to-many as you descend through the levels. 238 Universe Design Learner s Guide

251 For example,one Country has many Towns; one Town has many Showrooms;one Showroom has many Franchises., Showroom Country ),Showroom Town ),Showroom ), Franchises - Using Hierarchies--Learner s Guide 239