Professional Documents
Culture Documents
Copyright
2008 Business Objects. All rights reserved. Business Objects owns the following U.S. patents, which may cover products that are offered and licensed by Business Objects: 5,555,403; 5,857,205; 6,289,352; 6,247,008; 6,490,593; 6,578,027; 6,831,668; 6,768,986; 6,772,409; 6,882,998; 7,139,766; 7,299,419; 7,194,465; 7,222,130; 7,181,440 and 7,181,435. Business Objects and the Business Objects logo, BusinessObjects, Business Objects Crystal Vision, Business Process On Demand, BusinessQuery, Crystal Analysis, Crystal Applications, Crystal Decisions, Crystal Enterprise, Crystal Insider, Crystal Reports, Desktop Intelligence, Inxight, the Inxight Logo, LinguistX, Star Tree, Table Lens, ThingFinder, Timewall, Let there be light, Metify, NSite, Rapid Marts, RapidMarts, the Spectrum Design, Web Intelligence, Workmail and Xcelsius are trademarks or registered trademarks in the United States and/or other countries of Business Objects and/or affiliated companies. All other names mentioned herein may be trademarks of their respective owners.
C O N T E N T S
About this Course
Course introduction...................................................................................................xiii Course description.....................................................................................................xiv Course audience.........................................................................................................xiv Prerequisites................................................................................................................xiv Level, delivery, and duration...................................................................................xiv Applicable certifications and designations.............................................................xiv Course success factors.................................................................................................xv Course setup.................................................................................................................xv Course materials..........................................................................................................xv Learning process..........................................................................................................xv
Lesson 1
iii
Implementation phase.........................................................................................21 Implementation phase 1: schema design..........................................................21 Implementation phase 2: building the universe..............................................23 Testing phase........................................................................................................24 Deployment phase...............................................................................................25 Updating/maintenance.......................................................................................26 Prepackaged solutions.........................................................................................26 Activity: Planning a universe.............................................................................27 Quiz: Understanding BusinessObjects universes...................................................28 Lesson summary..........................................................................................................29
Lesson 2
Lesson 3
iv
Manipulating tables in the universe structure.................................................59 Activity: Populating the universe structure.....................................................62 Defining joins in a universe........................................................................................64 About joins and SQL WHERE clauses .............................................................64 Creating joins........................................................................................................65 About join properties...........................................................................................67 Editing the join expression .................................................................................68 Using the Join SQL editor ..................................................................................68 Detecting joins .....................................................................................................69 Setting join cardinalities......................................................................................70 About cardinality.................................................................................................70 Setting cardinality manually or with the automatic detection tool..............71 Displaying cardinalities ......................................................................................73 Detecting cardinality automatically..................................................................75 How is cardinality detected?..............................................................................75 Detect cardinality for all joins.............................................................................76 Best practice for setting join cardinality ...........................................................77 Join types ..............................................................................................................78 Equi-joins ..............................................................................................................78 Outer joins ............................................................................................................79 Theta joins.............................................................................................................80 Shortcut joins........................................................................................................82 Self-restricting joins .............................................................................................83 List Mode...............................................................................................................85 Checking integrity ...............................................................................................87 Activity: Defining joins in a universe................................................................87 Quiz: Building the universe structure......................................................................90 Lesson summary..........................................................................................................91
Lesson 4
Copying and pasting objects.............................................................................108 Find and replace ................................................................................................108 Checking object integrity .................................................................................109 Viewing parent tables........................................................................................110 Testing objects ....................................................................................................111 Activity: Creating and testing classes and objects.........................................111 Quiz: Creating dimension objects...........................................................................117 Lesson summary........................................................................................................118
Lesson 5
Lesson 6
vi
Lesson 7
Lesson 8
vii
Drawbacks to the Multiple SQL statements for each measure method.................................................................................................................187 Using contexts to resolve chasm traps ...........................................................188 Activity: Resolving chasm traps.......................................................................190 Detecting and resolving fan traps ..........................................................................193 Fan traps .............................................................................................................193 The fan trap scenario ........................................................................................194 Resolving fan traps.............................................................................................195 Using aliases and contexts to resolve fan traps.............................................196 Solving a fan trap with two tables in a one-to-many relationship..............198 Avoiding fan traps altogether .........................................................................199 Activity: Resolving fan traps............................................................................201 Quiz: Resolving SQL traps ......................................................................................205 Lesson summary........................................................................................................206
Lesson 9
Lesson 10
viii
Lesson 11
Using Hierarchies
Lesson introduction...................................................................................................235 Understanding hierarchies and universes ............................................................236 Hierarchies..........................................................................................................236 Working with hierarchies ........................................................................................238 Default hierarchies ............................................................................................238 Custom hierarchies............................................................................................241 The effect of custom hierarchies on default hierarchies ..............................242 Time hierarchies ................................................................................................244 Testing automatic time hierarchies .................................................................247 Advantages and disadvantages of automatic time hierarchies ..................248 Time hierarchies based on database functions .............................................248 Advantages and disadvantages of database function time hierarchies ...............................................................................................................................249 Table-based time hierarchies ...........................................................................250 Advantages and disadvantages of table-based time hierarchies ...............251 Activity: Using hierarchies................................................................................252 Quiz: Using hierarchies ............................................................................................254 Lesson summary........................................................................................................255
Lesson 12
ix
Lesson 13
End-of-Course Challenge
Lesson introduction...................................................................................................273 End-of-course challenge............................................................................................274 Customer scenario..............................................................................................274 Activity: End-of-course challenge - Part 1......................................................275 Activity: End-of-course challenge - Part 2......................................................277 Lesson summary........................................................................................................278
Appendix A
Relational/Dimensional Modeling
Understanding the metadata...................................................................................279 Data warehouses........................................................................................................280 Online Transactional Processing systems..............................................................281 Data Marts...................................................................................................................282 Dimensional Modeling..............................................................................................283
Appendix B
Answer Key
Quiz: Understanding BusinessObjects universes.................................................291 Quiz: Creating the course universe.........................................................................292 Quiz: Building the universe structure....................................................................293 Quiz: Creating dimension objects...........................................................................294 Quiz: Creating measure objects...............................................................................295 Quiz: Using lists of values .......................................................................................296 Quiz: Resolving loops in a universe .......................................................................297 Quiz: Resolving SQL traps ......................................................................................298 Quiz: Applying restrictions on objects ..................................................................299 Quiz: Using @functions with objects .....................................................................300 Quiz: Using hierarchies ............................................................................................301 Quiz: Derived tables and indexes ...........................................................................302
Universe Design
Introductions, Course Overview...........................................30 minutes
Lesson 1
AgendaLearners Guide
xi
Lesson 7
Lesson 8
xii
xiii
Course description
This three-day instructor-led course is designed to give you the comprehensive skills needed to design, build and maintain BusinessObjects 6.5 and BusinessObjects XI R1/R2 universes. You should attend this course to understand universe design concepts and terminology, as well as the role of universes in relation to BusinessObjects reporting tools. The course provides an overview of the process for planning, designing and creating a universe and then walks you through the process of designing a universe that responds to identified requirements. The business benefit of this course is that you will learn best-practice methodology for creating universes that respond to your reporting requirements. Through well-designed universes, report designers and business users will be able to create reports without having to know anything about the underlying data source or structure.
Course audience
This course is designed to teach you how to design BusinessObjects universes using Universe Designer, using BusinessObjects 6.5 or BusinessObjects XI R1/R2. New features covered in the XI R2 course that are not applicable to BusinessObjects 6.5 or XI R1 learners include: Creating a cascading list of values associated with a hierarchy of objects in a universe The target audience for this course is universe designers.
Prerequisites
To be successful, learners who attend this course should have attended the following offerings: BusinessObjects Web Intelligence XI R1/R2: Report Design To be successful, learners who attend this course should have the following experience: SQL and relational database management systems concepts and structures Familiarity with the type of data and the logical structure of the databases in their organization Familiarity with BusinessObjects Web Intelligence report building
xiv
Course setup
Refer to the setup guide for details on hardware, software, and course-specific requirements.
Course materials
The materials included with the course materials are: Name card Learners Guide The Learners Guide contains an agenda, learner materials, and practice activities. The Learners Guide is designed to assist students who attend the classroom-based course and outlines what learners can expect to achieve by participating in this course. Evaluation form At the conclusion of this course, you will receive an electronic feedback form as part of our evaluation process. Provide feedback on the course content, instructor, and facility. Your comments will assist us to improve future courses. Additional resources include: Sample files The sample files can include required files for the course activities and/or supplemental content to the training guide. Online Help Retrieve information and find answers to questions using the online Help and/or users guide that are included with the product.
Learning process
Learning is an interactive process between the learners and the instructor. By facilitating a cooperative environment, the instructor guides the learners through the learning framework.
Introduction
Why am I here? Whats in it for me? The learners will be clear about what they are getting out of each lesson.
xv
Objectives
How do I achieve the outcome? The learners will assimilate new concepts and how to apply the ideas presented in the lesson. This step sets the groundwork for practice.
Practice
How do I do it? The learners will demonstrate their knowledge as well as their hands-on skills through the activities.
Review
How did I do? The learners will have an opportunity to review what they have learned during the lesson. Review reinforces why it is important to learn particular concepts or skills.
Summary
Where have I been and where am I going? The summary acts as a recap of the learning objectives and as a transition to the next section.
xvi
Lesson 1
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.
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 now 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.
Metadata is imported into 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 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. 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 Release 2 Designer's Guide.
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.
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; 1 dimension table versus 1 fact table. Another method is to use prebuilt summarized data in the schema.
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.
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. 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.
Starting Designer
Designer can only be used with a BusinessObjects repository. You must log onto the repository before starting Designer. After you start 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 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.
To start Designer
1. Click the Start button on the taskbar. 2. Select the Programs menu. 3. Select the BusinessObjects XI Release 2 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 Designer start-up screen appears, and an empty Designer session opens. The user name and repository name appear in the title bar. Note: Depending on options set for Designer, the Quick Design Wizard can start automatically when you start in Designer. Click Cancel to close the wizard.
Menu options
You can perform most tasks by choosing options from the menu. The Designer menu bar looks like this:
Toolbar buttons
The toolbar gives you quick access to many tasks. Designer has three toolbars: the Standard toolbar, the Editing toolbar, and the Formula Bar toolbar.
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:
Designer window
The 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.
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 Designer automatically organize your tables sequentially and horizontally. Note: You can undo only the last command. If you do not like the arrange tables results, choose Undo from the Edit menu.
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
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. 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.
To roll up a table
10
Procedure
Action
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. 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. Click the header of the table; a scroll bar appears on the right of the table. Alternatively, 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 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 To view the number of rows for a table in the Number of Rows in Table option. database If you are front ending a large database, this may not be advisable due to the time it takes to process.
11
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 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.
12
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.
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.
13
3. Select Portable Document Format (PDF) from the Save As type drop-down list. 4. Click Save.
Instructions
1. Open Designer. 2. In Designer, click File Open. Browse to the eFashion.unv file found in the default installation folder:
C:\Program Files\Business Objects\BusinessObjects Enterprise 11.5\Samples\en\Universes
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.
14
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.
15
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
16
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 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.
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.
In designating the team members, individuals must be chosen to fill the following roles. One person may fill multiple roles.
Role Sponsor 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.
QA Reviewer
17
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.
18
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 Class Name Customer Total Description Source
Information on a customer, including location, Interview #1 credit ratings, and shipping preferences. This object can be combined with date ranges, customers, and/or products to provide Interview #3, #4 meaningful measures.
Object (Measure)
Revenue
You should also try to document the qualification of objects (dimension/detail/ measure) and any potentially identified hierarchies.
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
19
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.
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.
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
20
Implementation phase
The implementation phase can be split up into two stages: 1. Designing the schema 2. Building the universe
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 Class Name Customer SQL fragment Description Information on a customer, including location, credit ratings, and shipping preferences. Source Interview #1
21
Type
Name
SQL fragment
Description
Source
SQL:
Object (Measure) Total Revenue This object can be combined with sum(order_lines.quantity* date ranges, customers, and/or Interview products.price) products to provide meaningful #3,4 Source Tables: Order_Lines, measures.
Products 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.
22
23
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.
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 (e.g., move an object from one class to another, reclassifying a dimension as a detail, etc.) Objects or queries that do not behave as expected
24
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 the 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
25
production systems, rather than from development systems and is exported to the production repository.
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.
26
Instructions
1. From the resource CD launch the Planning_universe_activity.html (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?
27
28
Lesson summary
After completing this lesson, you are now able to: Define BusinessObjects universe concepts Use the Universe Development Cycle
29
30
Lesson 2
31
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).
32
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).
33
34
Note: Make sure the Universe Parameters dialog box displays with the Definition tab active. 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 or define the data source connection. 5. Click OK. 6. Select File Save from the menu bar. 7. Provide a name for the file. The universe file is saved as a .unv file
File system, Business Objects end-user querying tools to reference the universe Business Objects end-user querying tools Business Objects end-user querying tools
35
Identifier
Used by
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 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 11.5\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 universes role and is viewable by end users.
36
37
38
You should get the message TESTS COMPLETED SUCCESSFULLY. If you dont get this message, review your steps and verify the added authentication credentials. 11.Click OK until you can close the Administrative Tools window.
39
40
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 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. After you have chosen your connection type and clicked Next, the Perform a test page appears. It summarizes the information for your connection and allows you to verify that the connection is valid.
41
3. Set the connection time and array fetch according to the database you are using. You can accept the default advanced settings or select from the advanced options. The Advanced Parameters page appears.
4. Click Next. 5. Customize the settings for listed parameters or accept the default settings. The Custom Parameters page appears.
42
6. Click Finish. 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.
43
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. Type a new data source or database name in the Data Source box if required. 5. Type modifications to login parameters as required. 6. Click Next. The Perform a Test page appears. 7. Click the Test Data Source button to verify the modified connection. 8. Click Next to move to the Advanced and Custom pages. You can modify parameters as required. You can also accept the default or existing values. 9. Click Finish from the Custom page to apply the changes to the connection.
44
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. 5. Click Finish.
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 Designers Guide.
Definition
Universe name, description, connection parameters, and information. These parameters identify the universe. Version and revision information, designer comments, and universe statistics. Strategies used by the universe. A strategy is a script used to extract structural information from a database. Limitations set for the use of system resources. Types of queries that the end user is allowed to run.
Summary
Strategies
Controls
SQL
45
Parameter
Description
Links
Settings defined for linked universes. SQL parameters that can be dynamically configured.
Parameter
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.
Summary tab
The Summary tab displays universe administration information.
46
Information
Description
Created
Universe creation date and the name of the creator. Date of last modification and the name of the modifier. Revision number indicates the number of times the universe has been exported to the repository. Information about the universe for yourself or another designer. This information is only available in 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. List of the number of classes, objects, tables, aliases, joins, contexts, and hierarchies contained in the universe.
Modified
Revision
Comments
Statistics
47
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 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 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.
48
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. If you set the Warn if cost estimate exceeds option, a message informs the user if the query is likely to take more than the number of minutes you specify here. This mechanism is dependent on whether the database statistics are up-to-date.
SQL tab
You can set controls on the types of queries that end users can build in Business Objects querying tools.
49
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
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.
50
Parameters tab
In 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.
51
Instructions
1. Create a DSN for SQL Server 2005 called MotorsDSN. 2. Start a 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.
52
53
Lesson summary
After completing this lesson, you are now able to: Describe the course database and universe Create the universe
54
Lesson 3
55
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 needs analysis. Examine the database for tables that allow you to create these necessary objects.
Adding tables
The Structure pane of the 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
56
you want to insert into your schema. Expand the + box next to a table name to display the columns for the table.
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.
57
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.
58
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: 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.
59
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.
60
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.
61
3. Click Close.
Instructions
1. Insert the tables listed below into your blank Motors universe. CLIENT
62
COLOUR 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.
63
64
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.
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.
65
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.
66
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.
Outer Join
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
= !=
67
Operator
Description
greater than less than greater than or equal to less than or equal to between (theta joins) complex relationship
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.
68
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.
69
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.
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)
70
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.
71
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.
72
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 onedirection of the join. If cardinality is 1,1 then an arrow head is shown at each join end.
Arity
Crows foot indicates the many end of the join. If cardinality is 1,1, then a straight line is shown.
73
Cardinality symbol
Example
Description
1,N
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. Select the Arrow, Arity, or 1,n option. 5. Click OK to save the changes.
74
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).
75
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.
76
1. 2. 3. 4.
Designer offers yet another method for detecting cardinalities automatically: Select Tools Options from the menu bar. Click the Database tab. Select the Detect cardinalities in joins check box. Click OK.
77
Join types
Join Type 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.
Outer join
Shortcut join
Self-restricting join
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.
78
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. 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.
79
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.
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.
80
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.
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. 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.
81
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. 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,
82
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.
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.
83
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.
84
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.
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
85
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.
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.
86
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.
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.
Instructions
1. Insert the following equi-join using the drag-and-drop technique:
87
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.
88
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 COUNTRY.COUNTRY_ID = REGION.COUNTRY_ID REGION.REGION_ID = CLIENT.REGION_ID MODEL.MODEL_PRICE BETWEEN SALE_PRICE_RANGE.PRICE_RANGE_MIN AND SALE_PRICE_RANGE.PRICE_RANGE_MAX SALE.SALE_TYPE = 'S' CLIENT.CLIENT_ID = SALE.CLIENT_ID SHOWROOM.SHOWROOM_ID = SALE.SHOWROOM_ID SALE_MODEL.MODEL_ID = MODEL.MODEL_ID MODEL.STYLE_ID = STYLE.STYLE_ID MODEL.MAKER_ID = MAKER.MAKER_ID SALE_MODEL.COLOUR_ID = COLOUR.COLOUR_ID SALE.SALE_DATE BETWEEN FINANCE_PERIOD.FP_START AND FINANCE_PERIOD.FP_END SALE.SALE_ID = SALE_MODEL.SALE_ID Type Equi Equi Cardinality 1:N 1:N
Theta
N:1
Theta
N:1
Equi
1:N
89
90
Lesson summary
After completing this lesson, you are now able to: Populate the universe structure Define joins in a universe
91
92
Lesson 4
93
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 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. 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.
Detail
94
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 Designer, objects appear as icons in the Universe pane. Each object represents a meaningful entity, fact, or calculation used in an end users business environment. The objects that you create in the Universe pane in Designer are the objects that end users see and use in the Business Objects end-user querying tools. In the Web Intelligence Java Report 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 Web Intelligence Java or HTML report panel, the object infers a SELECT statement. When multiple objects are combined, a SELECT statement is run on the database which includes the SQL inferred by each object and a default WHERE clause.
95
As a universe designer, you use Designer to create the objects that end users select to build and run their queries. You can also create objects for use only in Designer, so that they are hidden in the Business Objects end-user querying tools.
96
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.
97
6. Click OK.
98
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.
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.
99
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.
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.
100
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:
101
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.
102
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.
103
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.
104
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.
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.
105
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.
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.
106
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.
107
To find a string
1. Ensure the Universe pane of the 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.
108
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.
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.
109
2. Select the Parse Objects check box. 3. Click OK. 4. Designer checks the universe and displays the Integrity Check Results dialog box. 5. Identify the reason for any reported errors and resolve them.
110
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.
Instructions
In this workshop you will create classes, subclasses and dimension and detail objects in the Motors universe and then test the universes 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 syntax =
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 syntax =
CLIENT.CLIENT_ID
No Associated LOV 5. Check the integrity of the objects. 6. Create a Showroom class.
111
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 a LOV should be associated with each object.
112
Car class
Object Name SELECT Statement MAKER.MAKER_NAME Maker Car Manufacturer Object Description
Category of Car
STYLE.STYLE_NAME
The style group into which a car fits (for example, coupe, 4x4) Model name, trim, and engine size
Model
Price Range
Model Price
MODEL.MODEL_PRICE
Showroom class
Object Name Showroom Town Showroom Showroom Address SELECT Statement SHOWROOM.SHOWROOM_TOWN SHOWROOM.SHOWROOM_NAME SHOWROOM.SHOWROOM_ADDRESS Object Description Town in which showroom exists Name of showroom Address of showroom
Client class
Object Name Country Region SELECT Statement COUNTRY.COUNTRY_NAME 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)
REGION.REGION_NAME
Area
CLIENT.CLIENT_AREA
113
Object Name Client Town Client Address Area Code Phone Number Client ID
Object Description Town or city in which client resides Address of client Postal or Zip Code Phone number of client 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
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.
114
13.Make sure you have defined each object using the appropriate object type. The Universe pane in 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.Save the universe again and export to the BusinessObjects repository. 17.Test the universe by building queries by using the new objects: Log onto Web Intelligence with the User name administrator.
115
Select New Web Intelligence Document. Select Motors universe. The Web Intelligence Java report panel for the Motors universe opens. Build a new query in the Report Panel using the objects you have created. Click Run Query to view the final results displayed in the report.
116
117
Lesson summary
After completing this lesson, you are now able to: Describe classes and objects Create classes and objects
118
Lesson 5
119
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.
120
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.
121
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.
122
123
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 Designer.
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.
124
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:
125
126
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.
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))
127
3. Save and export the universe. This allows you to test the Sales Revenue object in Web Intelligence. 4. Log onto Web Intelligence. 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:
128
8. In 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 Cost of Car Sales Number of Cars Sold Select Statement Object Description
SUM(SALE_MODEL.SALE_QTY * MODEL.MODEL_COST) Total Cost of Car Sales SUM(SALE_MODEL.SALE_QTY) 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.
129
130
Lesson summary
After completing this lesson, you are now able to: Explain measure object concepts Create measure objects
131
132
Lesson 6
133
134
135
3. If you want to turn off the LOV for this object, click the Associate a List of Values check box to clear it.
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.
136
Note: The next section describes the following List of Values options: Automatic refresh before use option Export with universe option
137
138
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.
139
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 Designer Query Panel. 6. In the Properties tab of the objects 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.
140
141
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.
Instructions
1. In Designer, create a cascading LOV using the objects in the Car class. 2. Save and export the universe. 3. Build a query in Web Intelligence 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: In Designer, change the object definition to associate a standard list of values for all objects in the Car class.
142
143
144
Lesson summary
After completing this lesson, you are now able to: Create a list of values Work with LOVs in Designer Create a cascading LOV
145
146
Lesson 7
147
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 clients region and the clients 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.
148
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.
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 query on a universe involving such a loop will return misleading data. To avoid this, the loop must be resolved.
149
Resolving loops
Loops are an inherent problem when writing SQL statements. There are various techniques within SQL that you can apply to resolve loops.
150
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.
151
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. 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:
152
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, Designer might nominate either of the two as the candidate for the Alias table.
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. 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. Tip: Be careful not to delete the original table. Once you have created one or more alias tables, its 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.
153
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.
154
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
must understand how to choose table to alias, identify the need for candidate minimizing object redefinition analysis
Whichever method you choose, you must always redefine objects that now use the Alias table.
155
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 managers name. This is effectively a loop, as the path forms a closed circuit. However, we 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.
156
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.
157
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.
158
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.
159
Instructions
In this actvity 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 dont delete the original table. 8. Save and export the universe. 9. Test your changes in Web Intelligence 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.
160
11.In 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 by building a query containing Maker Country, Maker, and Model objects.
161
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.
162
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:
163
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.
164
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.
Detect contexts Detect Contexts detects and proposes a list of contexts to create.
165
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.
166
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.
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.
167
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.
168
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 contexts 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 fails 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.
169
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 Report 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 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
170
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, 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 therefore 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.
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.
171
1. In 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
172
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
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
Unique Invoice ID Number First day of Rental Date rental car has been/ is to be returned
RENTAL.SALE_DATE + RENTAL.SALE_RENTAL_PERIOD
Rental Revenue
11.Create a subclass called Day Rental Charges in the Car class. Then populate the subclass with the following objects.
Object Name SELECT Statement RENTAL_PRICE_RANGE.RENT_RANGE Object Description
MODEL.MODEL_DAYRENT
12.Save and export the universe, then test the contexts used to resolve the loops by building the following queries in Web Intelligence:
173
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
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. Join the tables as shown below:
174
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 and export the Staff universe.
175
176
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
177
178
Lesson 8
179
180
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.
181
182
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.
183
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 our 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.
184
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.
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.
185
With the option Multiple SQL statements for each measure selected, 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.
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.
186
4. Click OK. 5. Save and export the universe. 6. In Web Intelligence, 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 will display the separate SQL Statements.
187
It is not that there is anything inaccurate about the dates, but the multiple occurrences will be confusing to users.
188
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.
189
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: CLIENT SALE RENTAL (as an alias of the SALE table) 5. Create the following joins and set the cardinality: Join
CLIENT.CLIENT_ID=SALE.CLIENT_ID
CLIENT.CLIENT_ID=RENTAL.CLIENT_ID
SALE.SALE_TYPE='S'
RENTAL.SALE_TYPE='R'
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
190
Client Name Sale Date Rental Date Sales Revenue Rental Revenue
RENTAL.SALE_DATE
Sum(SALE.SALE_TOTAL)
Sum(RENTAL.SALE_TOTAL)
8. Perform an integrity check on: Check Universe Structure Parse Objects Parse Joins 9. Save and export the universe. 10.In Web Intelligence, 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. 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 Nameobjects. 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.
191
16. In Designer, edit the universe by clicking File Parameters SQL tab, and select the Multiple SQL statements for each measure option. 17.Save and export the universe. 18.In Web Intelligence, 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. 22. In 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: Context Joins
CLIENT.CLIENT_ID=SALE.CLIENT_ID
Sale
SALE.SALE_TYPE='S'
CLIENT.CLIENT_ID=RENTAL.CLIENT_ID
Rental
RENTAL.SALE_TYPE='R'
24.Save and export the universe. 25.In Web Intelligence, 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?
192
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.
193
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.
194
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.
Three tables in a one-to-many relationship A dimension coming from the first table and measures
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.
195
If you have...
Then...
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.
Create an alias for the table containing the initial aggregation, joining it back to the original table and then use the Detect Two tables in a one-to-many Contexts tool to detect and propose a context for the alias table and a context for the original table. relationship A dimension and a measure Both of these methods solve the fan trap problem because coming from the first table they will work with both measure and dimension objects and a measure coming from and do not cause inefficiencies. You will explore both in the the subsequent table(s) following sections.
Note: However, to be more efficient still, using the two-table scenario, you could also use the @aggregate_aware function.
196
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 needs 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.
197
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.
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.
198
199
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.
200
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
CLIENT.CLIENT_ID=SALE.CLIENT_ID
SALE.SALE_ID=SALE_MODEL.SALE_ID
SALE.SALE_TYPE='S'
6. Create a class called Fan Objects. 7. Add the following objects with the following syntax: Object SELECT Qualification
201
Sum(SALE_MODEL.SALE_QTY)
Sum(SALE.SALE_TOTAL)
8. Perform an integrity check on: Check Universe Structure Parse Objects Parse Joins 9. Save and export the universe. 10.In Web Intelligence, 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. 14. In Designer, edit the universe by clicking File Parameters SQL tab and select the Multiple SQL statements for each measureoption. 15.Save and export the universe. 16.In Web Intelligence, 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?
202
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. 20. In 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 CLIENT.CLIENT_ID=SALE2.CLIENT_ID Cardinality
1:N 1:1
SALE2.SALE_TYPE='S'
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'
CLIENT.CLIENT_ID=SALE2.CLIENT_ID
Sale2
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 Sum(SALE2.SALE_TOTAL) Qualification
Sale Revenue
Measure
25.Save and export the universe. 26.In Web Intelligence, 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.
203
What is the total sale amount? What is the total sale quantity? How many different models were purchased? What happened to your figures?
204
205
Lesson summary
After completing this lesson, you are now able to: Understand SQL traps and universes Resolve fan traps Resolve chasm traps
206
Lesson 9
207
208
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'
209
210
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')
211
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:
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:
212
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.
When you have created a condition object, test it in Web Intelligence 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.
213
214
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
215
only equi-joins, the object is then guaranteed to only return countries in which showrooms exist.
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.
216
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 and export the universe, then test the two new Client objects in Web Intelligence: 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 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. 2003 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 FY04-05 8. Save and export the universe, then test the two new calendar year Sales Revenue objects in Web Intelligence: 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
217
10.Save and export the universe and test each restriction by building a query in Web Intelligence. 11.Run a query using Showroom Country to see the list of countries that have showrooms. 12.In 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 and export the universe. 14.In Web Intelligence, run the above query again and compare the results. 15.In 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 and export the universe.
218
219
Lesson summary
After completing this lesson, you are now able to: Restrict the data returned by objects
220
Lesson 10
221
Using @functions
The @functions 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: Define @functions Use the @prompt function Use the @select function Use the @where function Describe the @aggregate_aware function
Defining @functions
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 of @functions. The most commonly used @functions are:
@prompt(,,,,) @select() @where() @aggregate_aware(,)
These functions can be applied in the Select and/or Where dialog boxes of objects.
@function @prompt @select @where @aggregate_awar 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
@prompt
The @prompt 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 the @prompt is specified. This is done by placing a restriction based on the @prompt 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:
222
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 the @prompt, you need only one.
@prompt syntax
The @prompt 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
The first two parameters are mandatory, and the last three are optional. However, if you leave out a parameter, you must still include the required commas. For example:
SHOWROOM.SHOWROOM_Name = @prompt('Enter 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.
223
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.
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'
@select
The @select function is a pointer to the Select dialog box properties of another object. It is used by placing the @select in the Select field of the Edit Properties dialog box of an object, using the following syntax:
@select(path of existing object)
You specify the path in the form Class_Name\Object_Name. The purpose of the @select 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.
224
This example shows how the @select works. The code in the SELECT properties of the Model object is:
MODEL.MODEL_NAME+' ' + MODEL.MODEL_TRIM+' '+MODEL.MODEL_ENGINE
225
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 the @select function:
@select(Car\Model)
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 the @select function. Therefore, when you change the code, you only change it once in the original object.
@where
The @where function is a pointer to the Where dialog box properties of another object. It is used by placing the @where in the Where field of the Edit Properties dialog box of an object, using the following syntax:
@where(path of existing object)
For example:
226
This example shows how the @where works. The code in the Where properties of the Model for Rental object is:
MODEL.MODEL_DAYRENT IS NOT NULL AND SHOWROOM.SHOWROOM_NAME = @prompt('Enter Showroom Name', 'A','Showroom\Showroom',mono,constrained)
If you want 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 the @where function:
@where(Day Rental Charges\Model for Rental)
227
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 the @where function. Therefore, when you need to change the syntax, you only change it once in the original object.
Note: You can use the @where function in a condition object to point to an object, but not the other way around.
As with @select, 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 the @where 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 restrictions code.
228
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 the @where 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 = @prompt ('Enter Showroom Name','A', 'Showroom\Showroom',mono,constrained)
Note that each of the Where clause restriction objects do not have SELECT properties specified. The @where 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 Designer Universe pane. They are not shown at all in Business Objects end-user querying tools.
229
@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 Designer, you can use a function called @aggregate_aware 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 the @aggregate_aware 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 queries.
@aggregate_aware(<SELECT 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 Release 2: Designers Guide.
Instructions
1. Use the @prompt function to achieve this. The parameters for the @prompt are:
230
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 the @select 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 the @where 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
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 uses @where functions to point to the Where clause restriction objects. Model for Rental object inherits the Rental Model objects WHERE clause. Showroom Rental Model condition object inherits the Showroom Choice objects WHERE clause. 8. The SELECT properties of the Rental Date and Return Date objects contain RENTAL.SALE_DATE. Use the @select 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 and export the universe. Note: Remember to test your solution in Web Intelligence.
231
232
Lesson summary
After completing this lesson, you are now able to: Use @functions
233
234
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
235
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.
236
For example, one Country has many Towns; one Town has many Showrooms; one Showroom has many Franchises.
237
Default hierarchies
A default hierarchy contains all the dimension objects in a class in the order they are presented in that class. It is based on the order of the objects within the class. As the name suggests, a default hierarchy is automatically inferred by Business Objects end-user querying tools whenever you have at least one dimension object in a class. It is therefore important to organize dimension objects hierarchically in a class. In this example, you can see that the dimension objects in each class follow an order from the most general to the most specific.
Using this method of organizing your dimension objects in their classes is the key to setting up usable default hierarchies.
238
You cannot add or remove objects from classes in the Hierarchies Editor. You can use the Hierarchies Editor to create Custom Hierarchies. 2. Click the + box next to any class if you want to see the dimension objects organized in these hierarchies. 3. Click Cancel to close the Hierarchies Editor dialog box.
239
The Scope of Analysis pane allows users to set up the query for drill analysis. All the dimensions selected for the query are highlighted here, within their default hierarchies. In order to allow users to drill down the hierarchy from one level to another, without having to modify the query, you can set the scope of analysis before the query is actually executed. Note: You can manually drag the objects you want to drill down to in this pane. In this case, the Custom value appears in the Scope of Analysis level drop-down list.
5. To define default levels of scope of analysis, select the level drop-down list in the Scope of Analysis, and click the arrow to select the scope of analysis levels. The levels you define in the scope of analysis will determine how many objects from the hierarchy will be included in the query, and therefore how many levels of detailed data will be returned to the Web Intelligence document.
6. Select the required level from the drop-down list. The Scope of Analysis pane will contain further dimensions, indicating the level down option you have just selected. This means that they will be included in the query, and the measure relevant to these two objects will be calculated and stored in the documents microcube. 7. Click Run Query to execute the query. Values returned by the two dimension objects will not immediately appear in the table that is displayed, but can be seen listed in the Data tab of the Report Manager on the side. As soon as a user decides to switch to drill mode, the data will be available for drill analysis. 8. Click the Drill button in the Reporting toolbar to display the report in drill mode. Note: The report page now shows the name Report 1 with a drill mode icon.
240
9. Move the mouse pointer over a value in the dimension object column. A flag appears indicating the next level of data available from the hierarchy.
10.Double-click to drill down. The data in the measure column is aggregated to reflect next level drill-down figures.
11.Drill down and up as you wish to explore the data available in the documents microcube.
Custom hierarchies
A custom hierarchy combines objects from default hierarchies to build a custom analysis path.
Default hierarchies are based on the order of the dimension objects in their classes. These default hierarchies may not provide the drill paths that users need to analyze their data. They may need to follow drill paths that contain dimension objects from more than one class.
241
For example, if users of the Motors universe wanted to look at Sales Revenue from the point of view of Client/Area and Financial Period, they would not be able to do this using the default hierarchies. As universe designer, you can build a permanent custom hierarchy as part of the universe. As a result, the hierarchy is available across documents to all users. In the analysis phase of the universe development process, the designer identifies those custom hierarchies that are to be used regularly and creates them in Designer as permanent custom hierarchies.
242
However, when you create a Custom Hierarchy, the Hierarchies mode lists only the custom hierarchies while the All Objects mode still shows all objects made available to the user.
At first, this appears to be a problem. However, the effect of creating a custom hierarchy is actually very useful because it provides a mechanism for selectively producing hierarchies for end users. Because a default hierarchy is always created for any class where a dimension object exists, it may be that there are some default hierarchies that you do not want users to use as drill paths. This mechanism can be used to exclude such default hierarchies. Once you decide to create custom hierarchies, you must copy any of the defaults that you want to keep over to the right-hand side list box. Even if you do not want to create new ones, to exclude the default hierarchies that you do not want users to use as drill paths, you must copy the useful ones over. In order to make any change at all in the hierarchies, you either start over by creating new custom hierarchies or you copy only the useful default hierarchies into the Custom Hierarchies list box.
243
2. Drag and drop only the default hierarchy folders you want the users to use as drill paths from the left panel of the Hierarchies Editor dialog box to the right panel.
Note: When more than one hierarchy starts with the same dimension object path but diverges at a lower level of the hierarchy, the default path in the user module will be the one that is higher in the list (if dimensions from both hierarchies are included in the query). You can alter this default priority by changing the order of the hierarchies in the Custom Hierarchies pane. You can do this using the Move Up and Move Down buttons, or using the drag-and-drop technique. Note: When you add default hierarchies to the Custom Hierarchies list, it is good practice to position the true custom hierarchy, if any, at the bottom of the list. 3. Click OK to save the changes to the hierarchies and close the Hierarchies Editor dialog box. 4. Save and export the universe.
Time hierarchies
One of the most common requirements for data analysis is to provide facilities for analysis against different time periods. Time is a special case because all the information for the dimension objects that make up the hierarchy can come from a single column in a database. In most other cases, each dimension object infers a separate database column. This is achieved by using SQL date scalar functions to extract the day, month, year, and possibly quarter from a single database column of a date type. When you create a Time Hierarchy, you are still creating a Default Hierarchy, in which the levels depend on the order of the Dimension objects. You create the standard time structure
244
by ordering the objects Year, Quarter, Month, and Week. The only difference with Time Hierarchies is the way in which you create the objects.
3. Click the Automatic Time Hierarchy button to open the Automatic Time Hierarchy dialog box.
245
4. Select the check boxes for the time-related dimension objects you want to create and edit the names of the dimension objects, if required. 5. Click OK to close the Automatic Time Hierarchy dialog box. 6. If necessary, alter other object properties as required. 7. Click OK to close the Edit Properties dialog box. In the Universe pane, the original date object has a plus next to it, indicating that other objects are attached to it. These are the automatically created time dimension objects.
8. Click the + box to view and check the objects attached to the date object.
Note: You can see that the arrangement of the objects is not as you might expect. The original date object is at the top of the hierarchy, and the other time objects appear to be subsidiary objects to it. From this, it is apparent that there are two further disadvantages to this method of creating time dimension objects. First, when a user sees a + box against an object, they will think that detail objects are attached to it. Second, the objects are not ordered hierarchically in the class, and, as a consequence, this might lead to confusion as to which is the highest-level object in the class. 9. Double-click one of the automatically created time dimension objects (year, quarter, or month) to view the Edit Properties dialog box for the object.
246
Note: The object properties cannot be edited. This is another disadvantage. However, you can also see one of the key advantages of using this method to create time dimension objects: the SQL inferred includes the scalar function used to extract the correct element of the date. 10.Click OK to close the Edit Properties dialog box. 11.Click the Hierarchies toolbar button to open the Hierarchies Editor dialog box. Notice that in the Default Hierarchies list, there are two new default hierarchy classes, an empty one bearing the name of the original class, and another bearing the name of the class appended with the name of the original date object. 12.Click the + box next to the class/object-named default hierarchy. You can see that the time hierarchy objects are correctly ordered despite the order of the dimension objects in the class. 13.Close the Hierarchies Editor dialog box. 14.Save and export the universe.
247
This can be confusing or unsatisfactory to end users. A better idea is to precede the numbers with a character string such as Quarter or Month. However, as you have already seen, it is impossible to edit a time dimension object that is created using the automated method.
Advantages
It is a fairly quick and easy way to set up a time hierarchy. Automatically creates the SQL SELECT statement using the appropriate scalar functions for the RDBMS of the target database.
Disadvantages
Does not give the designer any control over the layout of the dimension objects in the Universe pane. Does not give the designer any control over the format of the data in the query report. The layout of the dimension objects in the universe can be confusing to users, who normally expect to see detail objects under dimension objects. The format of the report can be confusing to users. An LOV can only be applied to the date seed object, not to individual time dimension objects. All the negative points listed above can be avoided if another method of creating time dimension objects is used.
248
Repeat the remainder of this procedure to create each time object required within the class that is based on the date scalar functions. 2. Drag the database column from the Structure pane table that contains the date required and drop it on the newly created class. 3. Double-click the object to open the Edit Properties dialog box. 4. Edit the properties of the object so that it will infer an element of the date as required. Change the object name to reflect the scalar function used. Change the Type if required, depending on the scalar function used. Change the SELECT statement to the relevant scalar function, string conversion, and required concatenated string value, depending on the RDBMS used. Clear the Associate list of values, if not required. 5. Click OK to close the Edit Properties dialog box. 6. Repeat steps 2 to 5 for each of the other time objects required within the class based on scalar functions. Tip: As you are creating a very similar time object to the previous one, it can be more efficient to edit a copy of the previous object, rather than creating a new one as suggested in step 2. 7. The Universe pane now contains a class or subclass as in the following example:
Advantages
The layout of the dimension object within the class is as a user would expect. Each of the objects can be edited individually. A separate LOV can be associated with each time dimension object as required. The name of the hierarchy and the order of the objects mirror the class exactly.
249
Disadvantages
It takes longer to create the objects of the time hierarchy than when using the Automatic Time Hierarchy method. The person designing the universe needs to know the relevant scalar functions and how to use them. Tip: If you do not know the relevant scalar functions, you could initially create the time objects within a class using the Automatic Time Hierarchy method. Then you could note the scalar functions automatically inferred, remove the automatically created objects, and recreate them using the database function method.
Another way of creating time dimension objects is to add a time-range table to the database with columns and data as in the following example. This table can then be added to the structure and its columns used to create time dimension objects. This is a good way of coping with financial periods that do not coincide with the calendar year.
250
3. Create a new class with an appropriate name. 4. Create the time objects required. In each instance, you will not need to use scalar functions. The SELECT statement of each object needs only to infer a database column name. Hence, it would be more efficient to use the automated method of creating objects (drag and drop). When the objects have been created, the class appears as in the example below:
A default time hierarchy will now be inferred from the class. 5. Save and export the universe.
Note: A time hierarchy created using this method is tested in the same way as any other hierarchy.
Advantages
It is a good method of creating time dimension objects for time periods other than calendar periods. The layout of the dimensions within the class is as a user would expect. Each of the objects can be edited individually. A separate LOV can be associated with each time dimension object, as required. The name of the hierarchy and the order of objects mirror the class exactly.
Disadvantages
The additional join reduces the efficiency of an inferred SQL statement.
251
Instructions
1. To view all hierarchies, click the hierarchy button. Remove all custom hierarchies in the Custom section. 2. Check that the hierarchical order of the dimension objects in the Client class is based on geography. The geographic hierarchy is: Country -> Region -> Area -> Town. 3. Save and export the universe, and then test the default hierarchy in Web Intelligence. 4. Create a Sale Year, Sale Quarter, and Sale Month dimension object using the Automatic Time Hierarchy method. 5. Save and export the universe again, and then test the resulting hierarchy in Web Intelligence. When you run the query, view the SQL and note the scalar function used. 6. Create a Rental Year, Rental Quarter, and Rental Month dimension object manually in the Rental Dates subclass. Ensure that the quarter and month dimension object values are formatted to show a full month value or are preceded by a character string such as Q and Calendar Year respectively. 7. Check that the order of the dimension objects in the Financial Period class is based on time. 8. Save and export the universe again, and then test the resulting hierarchies in Web Intelligence. 9. Prestige Motors wants to analyze clients geographically (by Country, Region, and Town) but then further analyze the breakdown of client expenditure by financial year. Create a custom hierarchy to allow users to do this by including the Country, Region, Town and Financial Year objects in the hierarchy. 10.Make the following default hierarchies available to the user: Car Day Rental Charges Showroom Financial Period Rental Dates Sale Dates 11.Save and export the universe again, and then test the resulting hierarchy in Web Intelligence. 12.Sales people want to drill down to a model using a specific drill path. In the bottom of your custom hierarchy list, create a hierarchy to allow this drill path using the following objects: Showroom Country
252
Showroom Name Maker Model 13.Save and export the universe again, and then test the resulting hierarchy in Web Intelligence.
253
254
Lesson summary
After completing this lesson, you are now able to: Understand hierarchies and universes Work with hierarchies
255
256
Lesson 12
257
258
Note: When using an aggregation function, or any other SQL function in the SQL syntax, it is important to alias the column that contains the calculation. Universe Designer uses these aliases as the column names in the derived table. 4. Click Check Syntax to parse and validate your SQL. 5. Click OK. The derived table appears in the schema next to the physical database tables. 6. Join the table to a table in the existing schema. If contexts have been applied to the schema, make sure the newly inserted join is included in at least one context. 7. Build objects based on the derived table columns in exactly the same way you do with regular tables. 8. Save and export the universe.
259
Instructions
1. Using Motors, insert a derived table to show the number of transactions per customer. 2. Name the newly derived table Best_Cust. 3. Create the SQL statement so that it looks like this:
SELECT CLIENT.CLIENT_ID, COUNT(SALE.SALE_ID) AS Number_of_transactions FROM CLIENT, SALE WHERE CLIENT.CLIENT_ID=SALE.CLIENT_ID GROUP BY CLIENT.CLIENT_ID
4. Use Check Syntax to verify your SQL statement syntax. 5. Insert a join between the Best_Cust and Client tables. 6. Add the new join to the Sales context. The join between the Best_Cust and Client tables is from the Client_ID primary key in the Client table to the Client_ID foreign key in the Best_Cust table. The table schema looks like this.
7. Add the Number of Transactions object to the Client class. Define the object as a measure object. 8. Save and export the universe. 9. In Web Intelligence, build a report that shows the number of transactions per customer and the number of transactions per country.
260
261
MAKER, MODEL, COUNTRY COUNTRY_MAKER WHERE (MODEL.MAKER_ID=MAKER.MAKER_ID) AND (MAKER.COUNTRY_ID=COUNTRY_MAKER.COUNTRY_ID) AND COUNTRY_MAKER.COUNTRY_NAME In ( 'United Kingdom','USA' ) GROUP BY MAKER.MAKER_NAME
In this case, Designer has created a join to the Maker Country table in order to restrict the countries retrieved. With index awareness, you can tell Designer that Country_ID is the primary key of the Country_Maker table and that it also appears in the Maker table as a foreign key. Using this information, Designer can restrict the countries without joining to the Country_Maker table. In this case, Designer is able to generate SQL that restricts the countries by filtering the values of the Country_ID foreign key. After setting up Index Awareness for Maker Country, Designer generates the following SQL, where 44 is the United Kingdom Country_ID value and 1 is the USA Country_ID value:
SELECT MAKER.MAKER_NAME, max(MODEL.MODEL_PRICE) FROM MAKER, MODEL WHERE (MODEL.MAKER_ID=MAKER.MAKER_ID) AND MAKER.COUNTRY_ID In ( 44,1 ) GROUP BY MAKER.MAKER_NAME
262
3. Click Insert. A key line is inserted in the list of keys box. 4. To define key awareness for the primary key: Click the drop-down arrow next to Primary Key and select Primary in the Key Type list.
Click within the line under Select field, and then click the ... button that appears, to open the SQL editing dialog box. The Edit Select Statement dialog box appears. In the Edit Select Statement dialog box, use the SQL Editor to build the primary key SQL Select clause or type it directly. 5. Select Enable. 6. Click OK. 7. Repeat steps 3 and 4 for all columns that make up the primary key.
263
Instead of using the County_Name field from Country_Maker table, it will now use Country_Id field from the Country_Maker table. This is determined from the key entries made in the object properties. But how did Business Objects convert the Maker Country names selected in the LOV into the primary key values necessary for the SQL? The default SQL query that is generated to retrieve the Maker Country LOV is:
SELECT DISTINCT COUNTRY_MAKER.COUNTRY_NAME FROM MAKER, COUNTRY COUNTRY_MAKER WHERE (MAKER.COUNTRY_ID=COUNTRY_MAKER.COUNTRY_ID)
Note: The WHERE clause shown here is a result from using the Tables button, and adding the Maker table, to make sure that Maker Country object only returns countries in which car manufacturers exist.
In order to convert the Maker Country names to primary keys, the primary key that was defined in the Keys tab is added to the query:
SELECT DISTINCT COUNTRY_MAKER.COUNTRY_NAME COUNTRY_MAKER.COUNTRY_ID FROM MAKER, COUNTRY COUNTRY_MAKER WHERE (MAKER.COUNTRY_ID=COUNTRY_MAKER.COUNTRY_ID)
This way Business Objects matches the country names from the Country_Maker table to the primary key values. Note: This SQL is visible by either editing the LOV for the Maker Country object and/or tracing SQL that passes through the middleware to the database. With index awareness defined, if you select Maker Country names from the LOV dialog you indirectly select the primary key values as well. The primary key values acts like a hidden column in the LOV dialog. The operand Value(s) from list dialog box in the BusinessObjects end-user querying tools returns the primary key values that match the visible values in the LOV dialog. Index Awareness allows universe designers to automatically redirect a WHERE clause condition to another column that is known to provide better performance at query time. The index awareness option can be used to determine which column to choose as an alternative based on database schema knowledge and the RDBMS optimizer. The LOV values that end users select actually tell Business Objects what primary key values to substitute in final query SQL. The Keys tab tells Business Objects which SQL syntax to substitute in the final query SQL.
264
2. Click the Properties tab. 3. Click Edit. The Designer Query Panel opens displaying the indexed object in the Result Objects pane. 4. Click View SQL. The SQL Viewer Opens. It now displays both the indexed object value and its index key as generated columns in the LOV.
This query has the Maker and Country_Maker tables in it which both can provide the Country_ID column. The Country_Maker table is only needed to satisfy the WHERE clause and is not needed in the SELECT or GROUP BY clauses. Using Index Awareness it is possible to remove the Country_Maker table from the query completely, by telling BusinessObjects to use the Maker table to retrieve Country_ID data from. By defining the foreign key in the Maker Country object, the same query returns the following SQL:
SELECT MAKER.MAKER_NAME, max(MODEL.MODEL_PRICE) FROM MAKER, MODEL WHERE (MODEL.MAKER_ID=MAKER.MAKER_ID) AND MAKER.COUNTRY_ID In ( 44,1 ) GROUP BY MAKER.MAKER_NAME
The Country_Maker table is no longer referenced in the SQL. This table no longer shows up in the FROM clause, nor in the WHERE clause as a join to the Maker table or as a table used to retrieve the condition values from.
265
Note: The LOV SQL is only affected by the primary key entry and always returns the primary key entries behind the scenes. Therefore all columns you provide in foreign key entries must have the same type of values and column type as the column referenced by the primary key entry.
266
If you set up the keys for the Client Country object we can give Business Objects three choices from which it can retrieve these values for the purposes of restricting data in the WHERE clause. This can aid query performance.
When running the Web Intelligence query shown above, the SQL generated is as follows:
SELECT CLIENT.CLIENT_LASTNAME + ', ' + CLIENT.CLIENT_FIRSTNAME, REGION.REGION_NAME FROM CLIENT, REGION WHERE (REGION.COUNTRY_ID=CLIENT.COUNTRY_ID) AND REGION.COUNTRY_ID In (1,44)
The Region table is used to restrict on Country_Region (Country_ID) as it is one of the foreign key entries and the Country_Region table is not used anywhere else in the query and is subsequently dropped from the SQL. Why does Business Objects use the Region table and not the Client table? Both tables exist in the FROM clause, however the Region table is used as the Country_ID key replacement. The reason for this is the order in which the foreign keys have been defined.). The Country_ID key from the Region table was the last one defined in the list and this is the one that will be used in the SQL generation. Rearranging the keys by placing the Country_ID key from the Client table last results in the following SQL instead:
SELECT CLIENT.CLIENT_LASTNAME + ', ' + CLIENT.CLIENT_FIRSTNAME, REGION.REGION_NAME FROM CLIENT, REGION WHERE (REGION.COUNTRY_ID=CLIENT.COUNTRY_ID) AND CLIENT.COUNTRY_ID In (1,44)
267
Note: If a shortcut join has been defined between the Country_Region and Client table, this shortcut key takes precedence as the foreign key, even if the last foreign key defined is the Region key.
268
Instructions
1. Using the Client Country object in Motors, enter the following under Keys:
Primary key WHERE Foreign key COUNTRY_REGION.COUNTRY_ID COUNTRY_REGION.COUNTRY_ID=CLIENT.COUNTRY_ID CLIENT.COUNTRY_ID
2. Save and export the universe. 3. Create a query in Web Intelligence with Client Country and Client Name. 4. Apply a query filter, and use the Value(s) from list option to restrict the data to a single country, such as the United States. 5. View the SQL. Notice that the WHERE clause no longer uses the COUNTRY_REGION.COUNTRY_NAME=USA statement (or whichever country you specified). It uses CLIENT.COUNTRY_ID =1.
269
270
Lesson summary
After completing this lesson, you are now able to: Use derived tables Apply index awareness
271
272
Lesson 13
End-of-Course Challenge
Lesson introduction
In this workshop you will edit and expand the Motors universe so that: Prestige Motors management and personnel can run reports on number of employees, absences and salaries by country, showroom department, job type, date and employee. Salaries should also be able to be reported on by financial year, quarter, month and date. Designing a universe is not just about using the Designer module. Careful planning needs to take place before you as a designer even think about starting up the Designer module. While working through the challenge, you will need to consider each of the five stages in the Universe Development Cycle process:
Preparation
Examine the database schema, maybe breaking it down into areas which cover particular departments to identify which tables will need to be used to satisfy the HR department's requirements.
Analysis
You require a detailed analysis of the precise information required by the users in each of the departments. There are a number of reports that have been identified. The focus must be on the business language users use to describe the information they require. This can then be used in the universe design.
Maintenance
When a universe has been distributed to the users, the designer is responsible for updating and maintaining the universe. This means keeping the universe up to date with any changes in user information requirements. After completing this lesson, you will be able to: Design and create the Prestige Motors universe
273
End-of-course challenge
A customer has called you in to provide a Proof of Concept using a sample of their data to ensure they are purchasing the correct product. Taking into account the complete product line of BusinessObjects products, you need to identify which tools would be best for the customer, not necessarily just the ones used in this challenge, but you do not need to go into any great detail on additional products. Your task is to work in a group and discuss the findings of some initial analysis with the HR department of Prestige Motors. Breakout session where as a group you need to identify the requirements Design the initial schema on paper Present the schema to the rest of the class Create the universe in Designer Test your universe in Web Intelligence
Customer scenario
Prestige motors has a total of 260 employees. Of the 260 employees, there are 12 who work within HR, few of whom are required to create the reports, most have viewing rights only. Most of the staff can schedule reports. The management needs to see high level reports, and not just straightforward tables. Showroom staff may be required to generate reports. Reports to detail the following: 1. Salary comparison. 2. Absence by department. 3. Salary levels versus Absence correlation. 4. Employee listing by manager. 5. List of Absences with Absentee. 6. Hierarchical reporting to be based on time, department and geographic locations. 7. A summary of the number of employees by grade and total salary amount per showroom for each year. 8. A Salary Cost Report broken down by financial year and country on which you can drill down to showroom from country and quarter and month from year. 9. A list of absences detailing the employee, job title, showroom, date of absence, duration of absence and reason for absence. These should be arranged by the reason for absence. 10.A summary of the salary costs and absences per showroom and per year. 11.Employees by department and when they were hired. 12.Departmental employee list by manager. Sample of objects to provide the above: Employee:
274
1. Country 2. Showroom 3. Department 4. Job Title 5. Distinct Number of employees 6. Manager detail object produces a list of line managers only when reported on and lists all managers from that table. 7. Ensure the country object produces a list of countries the showrooms are in. Salary: 1. Salary Description. 2. Financial Year (for Salary and Absence analysis only). 3. Financial Quarter (for Salary and Absence analysis only). 4. Financial Month (for Salary and Absence analysis only). 5. Date of Payment - no LOV, formatted to dd/mm/yyyy. 6. Salary Cost (based on the SALARIES table) - formatted as currency. Absence: 1. Start of Absence - no LOV, formatted to dd/mm/yyyy. 2. Duration of Absence (including weekends). 3. Reason for Absence. 4. Absence days - formatted with no decimal places. Two custom hierarchies are required: one for geographic drilling, the other for time based on a financial year. Items to watch out for: 1. Multipurpose lookup tables. 2. Chasm and fan traps. 3. Additional business requirements.
275
Instructions
1. Conduct a breakout session where as a group you need to identify the following points: Strategy: Define the scope of the universe. Identify and review the production and development architectures. Assemble project teams and define the initial task plan. Analysis: Identify the ad hoc data access requirements of the user community and record them in the form of candidate classes and objects. Identify security requirements. Schema Design: Map objects to corporate data sources. Resolve any circular paths or loops within the data structures that support the required objects. Plan the architecture for the project. Plan the development environment: Identify resources required to support a development universe area. Identify source for development data. Verify appropriate connectivity and initiate any changes or purchases required and plan their implementation. Plan the production environment: Identify resources required for a production universe. Locate source of production data. Verify connectivity. Initiate any changes or purchases required and plan their implementation. Adopt universe standards: Have appropriate naming conventions for universe names, object definition guidelines, names for simple, complex and aggregate objects, class names, alias tables, and help text. You may want to incorporate the class name in the object's name. This may make object names a little long, but it makes it easier for end users to understand where existing objects in a query come from, especially in reports containing many objects, some of which may have similar names. The object's name should always precede the class name(s). Example: Rental Date - Rental Dates - Rentals. Connectivity and configuration: Ensure the infrastructure is in place to support connectivity between users/developers and the enterprise system, including appropriate middleware to support the communication between clients and servers. Identify planned configuration for client software. Ensure appropriate resources are available. Security and support: Initiate a first look at security requirements - to be refined during subsequent phases. Develop a support policy that will be followed when the universe goes into production. Identify necessary resources. Change management and training: Identify procedures for the request, review, approval and implementation of changes to the production universe. It is essential to educate even existing users on how to use the universe to meet the business needs. Identify the best practices to be followed. Quality Assurance. 2. You need to identify the following for a high-level presentation: Have a schema of the universe prepared on paper. Key points to setting up your deployment: Best practices Strategies to adopt Design workflow to follow Architecture and health checks Potential products to use Schema of the universe based on the customer scenario
276
Instructions
1. Create a new universe called HR_Motors.unv. 2. Using your paper design as a reference, design the universe schema. Insert tables, joins, and create the appropriate classes and object. 3. Resolve any potential loops or SQL traps. 4. Check the universe integrity. 5. Test the universe in Web Intelligence.
277
Lesson summary
After completing this lesson, you are now able to: Design and create the Prestige Motors universe
278
Appendix A
Relational/Dimensional Modeling
Understanding the metadata
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?
279
Data warehouses
A data warehouse is an enterprise wide centralized storage facility for different types of data. Data stored in a data warehouse is characteristically subject oriented, time sensitive, and should be organized in a way that allows data analysis. For example, a data warehouse can contain customer information and sales details per customer, over the past five years. These customer details and sales records are often derived from several production systems in the enterprise. Performing query and trend analysis on this dispersed data can prove to be a difficult task. This is where data warehousing comes into play. Data warehousing is the process of collecting, aggregating, storing, and maintaining information so that it may lead to accurate business decisions. Some characteristics and features of data warehousing are as follows: Provides a consolidated storage of information from across the enterprise. Warehoused data is organized by subject area and is populated from many operational systems. Can act as a decision support system. Generally concerned with historical data and aggregates. Added to regularly, but loaded data is rarely ever directly changed. Regular schedule of dumps and loads from operational data stores. All these features differentiate data warehouses from typical operational database systems. Data warehouses are commonly kept on separate machines that can be tuned for a lower frequency of users with different querying characteristics. Data warehouses are usually read-only based systems, aside from the periodic loading of current information.
280
281
Data Marts
A data mart is a repository of data gathered from operational data or other sources and is designed to serve a particular department or functional group. It is similar to a Data warehouse, but there would be a difference in size and focus. The emphasis of a data mart is on meeting the specific demands of a particular group of users. These users can run reports and analyze data stored in the data mart that is designed to portray information based on their group requirement needs. A common approach to using data marts is to keep data at a detail level in the data warehouse and summarize this information into the data mart for each functional group or department. Sometimes data marts are designed for each departmental unit, and all departmental data marts are merged later on into an enterprise-level data warehouse. Either method offers the benefit of centralizing the information for the end users. Some characteristics of data marts are as follows: Data specialized for a particular group of an organization. Engineered for easy access. Optimal response from lower volume queries. Due to more simplified and specialized nature of data marts, organizations are turning to data marts, as a quick solution to their decision-support needs.
282
Dimensional Modeling
The traditional entity relationship (ER) model uses a normalized approach to database design. Normalization removes redundancy from the schema to optimize storage. Data warehousing is not that concerned with saving space. It is more concerned with meeting the decision support needs. A small amount of redundancy is usually acceptable.
Fact Tables
The fact table that sits in the center of this star schema usually contains business events recorded over time. Examples of data that can be found in this table are: sales transactions, orders and returns, bank transactions, shipments, and so forth. The fact table normally consists of a set of numeric values and a number of foreign keys that correspond to primary keys in the various dimension (lookup) tables. The information stored in the fact tables is usually static as it is historical. The most common example of a fact table in the star schema is for sales.
Dimensions
The dimension tables consist mainly of descriptive information linked to fact records. Example of dimension data are: customer names, product descriptions, suppliers, and vendors. Dimension tables contain fewer records than the facts table. An important factor is that the information in dimension tables is not static as records in dimension tables can be updated. For example, a customer address might be modified in the source system.
283
A typical data warehouse schema will always use dimension tables or tables that deal with periods of time. These tables are the key element to tracking the time variant information in these types of databases. Sometimes a more normalized approach is taken to the dimension tables. When this happens the star schema changes to a snowflake (or constellation) schema. A snowflake schema is basically one fact table, connected to a number of dimension tables, and these dimension tables in turn are connected to additional dimension tables.
In a snowflake schema it is also common to include aggregations across dimensional hierarchies, for example sales values summed up by store. These sales values can also be summarized into separate fact tables by region or district. The dimensional model is a logical technique optimized for queries and reporting. It is the most common model used in current data warehousing or data mart designs. It provides simplified hierarchical paths that would enable end users with drill-down analysis capabilities. Precalculated aggregations can be also embedded in the fact tables, which can result in rapid query-response times.
284
Appendix B
285
MySQL
DB2
Client Name
CONCAT(CONCAT( {fn concat({fn concat( {fn concat({fn concat( CLIENT.CLIENT_LASTNAME,', CLIENT.CLIENT_LASTNAME,', CLIENT.CLIENT_LASTNAME,', '), ')}, ')}, CLIENT.CLIENT_FIRSTNAME) CLIENT.CLIENT_FIRSTNAME)} CLIENT.CLIENT_FIRSTNAME)} {fn concat({fn concat( {fn concat({fn concat( MODEL.MODEL_NAME,' ')} ,MODEL.MODEL_TRIM)},' ')}, MODEL.MODEL_ENGINE)} {fn concat({fn concat( {fn concat({fn concat( MODEL.MODEL_NAME,' ')} ,MODEL.MODEL_TRIM)},' ')}, MODEL.MODEL_ENGINE)} {fn concat ('Calendar Year ',char(year( SALE.SALE_DATE)))}
Model
Sale Year
MONTH(SALE.SALE_DATE)
MONTH(SALE.SALE_DATE)
Rental Year
{fn concat {fn concat('Calendar CONCAT('Calendar Year ', ('Calendar Year Year ', TO_CHAR(RENTAL.SALE_DATE,'YYYY')) ',char(year( YEAR(RENTAL.SALE_DATE))} RENTAL.SALE_DATE)))} {fn concat {fn concat('Q', ('Q',char(quarter( QUARTER(RENTAL.SALE_DATE))} RENTAL.SALE_DATE)))}
TO_CHAR MONTH(RENTAL.SALE_DATE) MONTH(RENTAL.SALE_DATE) (RENTAL.SALE_DATE,'Month') sum(CASE WHEN to_char(SALE.SALE_DATE,'YYYY') ='2003' THEN (SALE_MODEL.SALE_QTY sum(CASE WHEN year(SALE.SALE_DATE) = 2003 THEN (SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE *(100 SALE.SALE_SALE_DISCOUNT)/100)) ELSE 0 END ) sum(CASE WHEN year(SALE.SALE_DATE) = 2004 THEN (SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE *(100 -
sum( CASE WHEN {fn year( SALE.SALE_DATE )} = 2003 Sales THEN Revenue * MODEL.MODEL_PRICE *(100 (SALE_MODEL.SALE_QTY * 2003 MODEL.MODEL_PRICE * SALE.SALE_SALE_DISCOUNT)/100)) (100 SALE.SALE_SALE_DISCOUNT)/100)) ELSE 0 END) ELSE 0 END ) sum(CASE WHEN to_char(SALE.SALE_DATE,'YYYY') ='2004' Sales Revenue THEN (SALE_MODEL.SALE_QTY 2004 * MODEL.MODEL_PRICE *(100 SALE.SALE_SALE_DISCOUNT)/100)) sum( CASE WHEN {fn year( SALE.SALE_DATE )} = 2004 THEN (SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE * (100 -
286
MySQL
DB2
SALE.SALE_SALE_DISCOUNT)/100)) SALE.SALE_SALE_DISCOUNT)/100)) ELSE 0 END ) ELSE 0 END ) sum(CASE WHEN FINANCE_PERIOD.FP_YEAR ='FY03-04' THEN (SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE *(100 SALE.SALE_SALE_DISCOUNT)/100)) ELSE 0 END ) sum(CASE WHEN FINANCE_PERIOD.FP_YEAR ='FY04-05'
sum(CASE WHEN sum( CASE WHEN FINANCE_PERIOD.FP_YEAR FINANCE_PERIOD.FP_YEAR ='FY03-04' ='FY03-04' Sales THEN (SALE_MODEL.SALE_QTY THEN Revenue (SALE_MODEL.SALE_QTY * * MODEL.MODEL_PRICE *(100 for MODEL.MODEL_PRICE * (100 FY03-04 SALE.SALE_SALE_DISCOUNT)/100)) SALE.SALE_SALE_DISCOUNT)/100)) ELSE 0 END ) ELSE 0 END) sum(CASE WHEN Sales Revenue FINANCE_PERIOD.FP_YEAR ='FY04-05' sum( CASE WHEN FINANCE_PERIOD.FP_YEAR ='FY04-05'
287
MySQL
DB2
THEN THEN (SALE_MODEL.SALE_QTY * (SALE_MODEL.SALE_QTY * * MODEL.MODEL_PRICE *(100 MODEL.MODEL_PRICE * for MODEL.MODEL_PRICE *(100 (100 FY04-05 SALE.SALE_SALE_DISCOUNT)/100)) SALE.SALE_SALE_DISCOUNT)/100)) SALE.SALE_SALE_DISCOUNT)/100)) ELSE 0 END ) ELSE 0 END) ELSE 0 END )
Object Name Client Name Model Sale Year Sale Quarter Sale Month Rental Year Rental Quarter Rental Month
Microsoft Access CLIENT.CLIENT_LASTNAME +', '+ CLIENT.CLIENT_FIRSTNAME MODEL.MODEL_NAME +' '+ MODEL.MODEL_TRIM +' '+ MODEL.MODEL_ENGINE 'Calendar Year ' + format(SALE.SALE_DATE,'YYYY') 'Q' + format(SALE.SALE_DATE,'Q') format(SALE.SALE_DATE,'Mmm') 'Calendar Year ' + format(RENTAL.SALE_DATE,'YYYY') 'Q' + format(RENTAL.SALE_DATE,'Q') format(RENTAL.SALE_DATE,'Mmm') sum(IIf{fn year(SALE.SALE_DATE )} = 2003, (SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE * (100-SALE.SALE_SALE_DISCOUNT)/100)),0)) sum(IIf{fn year(SALE.SALE_DATE )} = 2004, (SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE * (100-SALE.SALE_SALE_DISCOUNT)/100)),0)) sum(IIf(FINANCE_PERIOD.FP_YEAR ='FY03-04',(SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE * (100-SALE.SALE_SALE_DISCOUNT)/100)),0)) sum(IIf(FINANCE_PERIOD.FP_YEAR ='FY04-05',(SALE_MODEL.SALE_QTY * MODEL.MODEL_PRICE * (100-SALE.SALE_SALE_DISCOUNT)/100)),0))
288
Answer Key
This section contains the answers to the reviews and/or activities for the applicable lessons.
289
290
291
292
293
294
295
296
297
298
299
300
301
302
Notes
Notes
Notes
Notes