You are on page 1of 23

Session 2 Track 2

Best Practices: Advanced Universe Architecture and Design

Agenda
Introductions Views vs. Derived Tables DTs as an efficient mechanism for dynamic grouping of data. Identify techniques and best practices for data and universe object security including implementing row level data restrictions. Implementing pass-through authentication for database object security. Dynamic aggregate table awareness for measure and dimension objects. Q&A

Introductions
Tom Wolniewicz, Senior BI / DW Solutions Architect, BroadstreetData Customer Ambassador: Anand Menon, Analytics CoE Development, Celestica

Views vs. Derived Tables


Benefits of Views:
Views can represent a subset of the data contained in a table Views can join and simplify multiple tables into a single virtual table Views can act as aggregated tables, where the database engine aggregates data (sum, average etc) and presents the calculated results as part of the data Views can hide the complexity of data; for example a view could appear as Sales2000 or Sales2001, transparently partitioning the actual underlying table Views take very little space to store; the database contains only the definition of a view, not a copy of all the data it presents Depending on the SQL engine used, views can provide extra security Views can limit the degree of exposure of a table or tables to the outer world

Views vs. Derived Tables


Advanced View Features:
Various databases have extended the basic views from simple read-only to updatable data sets frequently used in Data Warehousing:
ORACLE introduced the concept of MATERIALIZED VIEW which not only expose the data but allow for its modification IBM DB2 has MQTs (Materialized Query Tables). Similarly MSSQL has Indexed Views

Views vs. Derived Tables


Behind the Scenes:
View Query (VIEW_1):
SELECT OBJECT_ID, OBJECT_NAME FROM SOME_TABLE

Usage:
SELECT * FROM VIEW_1

Behind the scenes the Database does this:


SELECT * FROM (SELECT OBJECT_ID, OBJECT_NAME FROM SOME_TABLE) VIEW_1

Views vs. Derived Tables


Derived Tables in BO Universe are SELECT statements that allow for the exact same functionality as using a Database View Benefits:
Easy to maintain Same Database performance as using a View Quicker and faster to develop (Views require database permissions to create and use)

Views vs. Derived Tables


Reasons to use a View over a Derived Table:
Views can be re-used in multiple universes and maintained within the Database Views may offer additional performance if they are Materialized/Indexed Views (depending on the platform) Views can be integrated with Database security to limit access to data

Using DTs to Group Data


In the following example we have a sample universe with transaction level data:

Using DTs to Group Data


Our goal is to create statistical analysis reports that group transactions into buckets (size and unit of measure defined at run-time as well as number of buckets to show). Buckets are containers for transactions, e.g. a Bucket containing 5 entries, means that there are 5 transactions within the bucket size (e.g. 0-30 days).

Using DTs to Group Data

Hands-on Example

Universe Security
Access Restrictions in Universe Designer allow for restrictions to be put in place on an individual user or group basis. The following items can be managed:
Connection Controls (number of records) SQL generation (allow the use of sub queries, etc.) Objects (disable use of objects defined in the list) Rows (automatically append a WHERE clause to specific tables Table Mappings (automatically map to another table/view that has the same structure)

Universe Security
Sample access restriction shown below:

Universe Security
Pass-through authentication can also be used in one of two ways:
Enterprise AD/KERBEROS Delegation

Universe Security
Enterprise authentication to DB pass-through uses DB_USER and DB_PASS properties as defined in the CMC:

It will utilize DB named user accounts as defined in the database and is configured on an individual basis.

Universe Security
AD/KERBEROS authentication can also be passed through if using SSO using delegation. Presently this is only supported on the Microsoft Platform (Windows) with SQL Server database. Benefits include the ability to use AD groups to manage security within the database (access to tables/views/columns)

Universe Security
Pass-through configured in Designer Connection Parameters:

This requires KERBEROS to be configured for SSO authentication

Aggregate Awareness
Business Objects Universe supports the notion of Aggregate Awareness which can dynamically select an aggregate table (summary) to improve query performance depending on the level of granularity of objects selected in the query.

Aggregate Awareness
We can use the Transaction Amount Measure and define it to be Aggregate Aware using the @ function.

Aggregate Awareness
Afterwards we need to define incompatibilities to trigger the detail level of aggregate awareness (otherwise only the summary is used)

Aggregate Awareness
Now when I generate a report using only the Transaction Amount I get the following SQL:

But when I add any other dimension the SQL automatically changes to use the detail table for the measure:

Reference Resources
Business Objects XI 3.1 Universe Designer http://help.sap.com/businessobject/product_guides/boexir31/en/xi3-1_designer_en.pdf

Business Objects XI 3.1 Administrators Guide: http://help.sap.com/businessobject/product_guides/boexir31/en/xi31_bip_admin_en.pdf


Business Objects Enterprise Deployment Planning Guide: https://websmp202.sap-ag.de/~sapidb/011000358700001647142008E/xi31_bip_deploy_plan_en.pdf Business Objects Backup and Recovery Best Practice Guide: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c0020482-ca8d-2c109bad-d1bd332bbb28?QuickLink=index&overridelayout=true

Q&A

Thank You!