Rittman Collab10 Biee Deepdive

T : +44 (0) 8446 697 995 or (888) 631 1410 (USA) E : enquiries@rittmanmead.com W: www.rittmanmead.
com
Collaborate10 IOUG Forum, Las Vegas, April 2010
Introduction to the Session

Deep Dive into Oracle BI EE 10g
T : +44 (0) 8446 697 995 E : enquiries@rittmanmead.com W: www.rittmanmead.com
Who Am I?
Oracle BI&W Architecture and Development Specialist
Co-Founder of Rittman Mead Consulting
Oracle BI&W Project Delivery Specialists
12+ years with Discoverer, OWB etc
Oracle ACE Director, ACE of the Year 2005
Writer for OTN and Oracle Magazine
Author of forthcoming Oracle Press OBIEE Book
Due Q4 2009
Longest-running Oracle blog
http://www.rittmanmead.com/blog
Ex-Chair of UKOUG BIRT SIG
Co-Chair of ODTUG BI&DW SIG
Editor of UKOUG Oracle Scene Magazine
T : +44 (0) 8446 697 995 or (888) 631 1410 (USA) E : enquiries@rittmanmead.com W: www.rittmanmead.com T : +44 (0) 8446 697 995 E : enquiries@rittmanmead.com W: www.rittmanmead.com
Rittman Mead Consulting
Oracle BI&DW Project Specialists providing consulting, training and support
Clients in the UK, USA, Europe, Middle-East
Voted UKOUG BI Partner of the Year 2008
Consultants in Europe and North America
Regular speakers at user group and Oracle events
T : +44 (0) 8446 697 995 or (888) 631 1410 (USA) E : enquiries@rittmanmead.com W: www.rittmanmead.com
What Do We Do?
Consulting, mentoring and support for Oracle BI projects
Technical design, project management, QA
Deliver entire project or just supplement your team
Advise on Oracle BI technology strategy
On-site training
Event organization
Support
Rittman Mead Blog
Longest-running Oracle (BI) Blog
Ten authors including Mark Rittman, Borkur Steingrimsson, Stewart Bryson, Peter Scott
and now Venkat J
(ex-http://oraclebizint.wordpress.com)
Articles on OBIEE, OWB, DW, Hyperion etc
All past presentations and articles
BI Forum Brighton 2009
Expert-level developer conference run in Brighton, May 2009
Attended by Oracle, Client and Industry developers and experts from around the world
Two days of presentations, discussions, knowledge exchange & networking
Focus on OBIEE, ODI, Essbase
Running again in May 2010
What Is This Session About?
Oracle Business Intelligence Enterprise Edition Plus
Oracles Next-Generation Business Intelligence Platform
In todays session you will learn:
What is OBIEE
How it connects to data sources
What data models it supports
How it federates data
How the BI Server joins data
How reports and portals are created
How it handles Essbase data
Whats coming in OBIEE 11g
Agenda
1. Introduction to Oracle BI EE
2. Oracle BI EE 10g Architecture
3. Data Modeling using star and 3NF data
4. Federating multiple data sources
5. Creating reports, dashboards and alerts (an overview)
6. Incorporating Essbase and other Multi-dimensional data
7. Whats coming in OBIEE 11g
The Seminar Format
Presentations and discussions
A break around 12pm
Finish at 3pm
Slides will be available online
Participant Introduction
The most important people in this room are you
It helps if I know a bit about you
Your Oracle BI experience
Your course objectives
Where you work
Introduce yourself to me, and to the
other seminar participants
Introduction to the Session

Lession 1 : Introduction to OBIEE 10g

Oracle Business Intelligence Enterprise Edition Plus 10g
Hot-Pluggable and Standards-Based
Connectivity to Most Applications and Data Sources
Oracle Business Intelligence Enterprise Edition is a federated query server
Connectivity to Oracle, MS SQL Server, Sybase, IBM DB2, Teradata etc
MS AS, Essbase, Oracle OLAP
Files, XML
Microsoft Excel
etc
Common Enterprise Information Model
Enables consistency, security, reuse, flexibility
Role-based views of the organization
Single metadata model of the business
Consistent definition of business measures,
metrics, calculations
Drill paths, summaries, security
Model once, deploy anywhere
Across any data source
Pervasive Information Access through a Unified BI Foundation
Oracle Business Intelligence Applications - Prebuilt Analytics
Oracle Interactive Dashboards
One-stop shop for reporting and analysis
All your reports in one place
Fully interactive
Graphs, reports, links
Delivered through your browser
Download to Excel
Print & Save your favorite
reports
Oracle Answers
Used for creating and amending reports
Point-and-click interactive environment
Tables, pivot-tables
Graphs
Gauges
Commentary text
Answers reports are then published
to dashboard
Sense and Respond
Delivers/Analytic Agents provides true real-time in context sense and respond
capabilities across systems tailored for any user on any device.
Sense and Respond
BI can also be embedded directly within the business processes.
All BI Content can be exposed as a set of services that are callable by SOA
enabled technologies and applications.
Oracle Disconnected Analytics
Fully-featured disconnected client
The user experience is identical to the connected user.
Dashboard and Answers functionality will act identically as if the user were
connected to the server.
Guided Analytics
Provide guidance and best next step for users
Conditionally display alerts, messages and entire reports
Oracle Briefing Books - Pack and Go
Bring along an electronic Briefing Book which is a collection of your most
important dashboards.
Briefing Books are extremely small, and can be delivered daily for enterprise
collaboration.
Oracle BI Publisher - Pixel-Perfect BI Publishing
Microsoft Office BI Integration
Oracle BI EE 10g
Demonstration
Summary
Oracle BI EE enables analytic analysis within your organization
Next-Generation Architecture, web-based analysis
Oracle BI Answers and Oracle BI Dashboards for analysis of data
Oracle BI Delivers provides scheduling and sense and respond
Offline analysis using Oracle BI Disconnected Analytics and Briefing Books
Microsoft Office integration to provide BI directly within your working environment
Many tools and opportunities
Oracle BI EE comes with a default repository so you can experiment straightaway
Lession 1 : Introduction to OBIEE 10g

Lession 2 : OBIEE Architecture and Relational Data Modeling

Oracle BI Suite Enterprise Edition Plus
Oracle Next-Generation BI tools platform
Based on Siebel Analytics
Originally developed by nQuire
Standards (J2EE) based
Heterogeneous connectivity
Server and Web-based
Oracle BI Server
Oracle Presentation Server
Oracle BI Answers
Oracle BI Delivers
Oracle BI Administration
Job Manager, Catalog Manager etc

Web Server
(IIS, Tomcat, Websphere, iPlanet )
Oracle BI Server Oracle BI Server
Intel l i gent Request Generati on Intel l i gent Request Generati on
Data Source Adapters Data Source Adapters
Nav igator Nav igator
Logical Request Generation Logical Request Generation
Aggregate
Nav igator
Fragmentation
Optimization
Multi-Pass /
Sub-Request Logic
Optimized Query Rewrites Optimized Query Rewrites
Sessi on Management Sessi on Management
M
e
t
a
d
a
t
a

I
n
t
e
r
c
h
a
n
g
e
M
e
t
a
d
a
t
a

I
n
t
e
r
c
h
a
n
g
e
Logical SQL ODBC/JDBC (Logical Business Model) Logical SQL ODBC/JDBC (Logical Business Model)
Cache Cache
Serv ices Serv ices
Oracle BI Administration Oracle BI Administration
Analytical and Operational Data Sources
Metadata Documentation Serv ices Metadata Documentation Serv ices
Metadata Management Serv ices Metadata Management Serv ices
Multi-User Dev elopment Serv ices Multi-User Dev elopment Serv ices
Serv er Management Serv ices Serv er Management Serv ices
ODBC ov er TCP/IP (SSL)
S
y
s
t
e
m

/

S
y
s
t
e
m

/

P
e
r
f
P
e
r
f

M
o
n
i
t
o
r
i
n
g

M
o
n
i
t
o
r
i
n
g
ODBC, CLI, OCI, XML, MDX
Oracle BI Presentation Services Oracle BI Presentation Services
SOAP Web Services, XML and URL Interface SOAP Web Services, XML and URL Interface
Cache Serv ices (Web) & Connection Cache Serv ices (Web) & Connection Mngmt Mngmt
XML XML
Framework Framework
Web Web
Catalog Catalog
Serv ice Serv ice
User Prof iling, Security and Session User Prof iling, Security and Session Mngmt Mngmt
Oracle Interactiv e Oracle Interactiv e
Dashboards Dashboards
Oracle Answers Oracle Answers
Load Bal ancer Load Bal ancer
S
e
c
u
r
i
t
y

S
e
r
v
i
c
e
s
S
e
c
u
r
i
t
y

S
e
r
v
i
c
e
s
Q
u
e
r
y

G
o
v
e
r
n
.
Q
u
e
r
y

G
o
v
e
r
n
.
TCP/IP
(SSL)
Jav ascript
f or Usability & Interactiv ity
Web Browser
XML, HTML,
XLS, PDF, TXT
over
HTTP/HTTPS
External Applications and Portals
HTML, SOAP
over
HTTP/HTTPS
Execution Engine Execution Engine
SAWBridge (J2EE/ISAPI) SAWBridge (J2EE/ISAPI)
TCP/IP (SSL)
Oracle BI Publisher Oracle BI Publisher
Delivery Server Delivery Server
Lay out Interfaces Lay out Interfaces
Data Logic Data Logic
XSL
Externalized
Authentication
LDAP
DB Authentication
Custom Authenticator
Oracle BI Oracle BI
Cluster Controller Cluster Controller
Oracle Delivers Server Oracle Delivers Server
Scheduling/Event Services Scheduling/Event Services
Agent Execution Logic Agent Execution Logic
Dev ice Adaptiv e Content Dev ice Adaptiv e Content
OBIEE 10g Architecture
Oracle BI Server
Calculation and Data Integration Engine
Virtual Data Warehouse
Allows reporting across multiple sources
Data accessed though metadata layer
Connects to RDBMS and OLAP data
Oracle Database (including Oracle OLAP)
IBM DB2
Microsoft SQL Server
Teradata
Microsoft Analysis Services (OLAP)
SAP BW 'info cubes'
Security, Summary Management
Translates incoming logical SQL
in to optimized, physical SQL

Oracle BI Presentation Server
BI Application Server
Single application that provides Oracle BI Answers, Dashboards
Metadata stored in Web Catalog
User Profiling, Security and Session Management
SOAP Web Services, XML and URL Interface
Web Server
(IIS, Tomcat, Websphere, iPlanet )
Oracle BI Presentation Services Oracle BI Presentation Services
SOAP Web Services, XML and URL Interface SOAP Web Services, XML and URL Interface
Cache Serv ices (Web) & Connection Cache Serv ices (Web) & Connection Mngmt Mngmt
XML XML
Framework Framework
Web Web
Catalog Catalog
Serv ice Serv ice
User Prof iling, Security and Session User Prof iling, Security and Session Mngmt Mngmt
Oracle Interactiv e Oracle Interactiv e
Dashboards Dashboards
Oracle Answers Oracle Answers
Jav ascript
f or Usability & Interactiv ity
Web Browser
XML, HTML,
XLS, PDF, TXT
over
HTTP/HTTPS
External Applications and Portals
HTML, SOAP
over
HTTP/HTTPS
SAW Bridge (J2EE/ISAPI) SAW Bridge (J2EE/ISAPI)
TCP/IP (SSL)
Oracle BI Delivers Server
Scheduling and distribution
Uses iBots (Intelligent Bots)
Integration (through Java) with BPEL
iBot chaining, calling from BPEL, calling BPEL
Permits alerts, through execution of Answers reports
If report returns rows, alert triggered
Alert appears on dashboard,
via email, SMS, cell phone
Can trigger narrative and
conditionally-appearing reports

on dashboard
Oracle Delivers Server Oracle Delivers Server
Scheduling/Event Services Scheduling/Event Services
Agent Execution Logic Agent Execution Logic
Dev ice Adaptive Content Dev ice Adaptive Content
Oracle BI Publisher Server
New in 10.1.3.2, based on Oracle XML Publisher
Separate application, integrated with Oracle BI Presentation Server
Initially usernames and passwords integrated
Thereafter separately administered
Provides high-fidelity layout, positioning of
data, charts etc
Multiple data sources
OBIEE Metadata Layer
Oracle BI Answers reports
Any source accessible via SQL
XML over HTTP

Oracle BI Publisher Oracle BI Publisher
Delivery Server Delivery Server
Lay out Interfaces Lay out Interfaces
Data Logic Data Logic
XSL
Oracle BI Administration
MS Windows application for managing BI Server
Creates and manages Common Enterprise Information Model
Physical, logical and presentation layers
Manage other aspects of BI Server
Security
Scheduler (Delivers server)
Jobs
Joins
Marketing
Sessions
Cache
Utilities and Tools
Connect to BI Server via ODBC DSN
Oracle BI Administration Oracle BI Administration
Metadata Documentation Serv ices Metadata Documentation Serv ices
Metadata Management Serv ices Metadata Management Serv ices
Multi-User Dev elopment Serv ices Multi-User Dev elopment Serv ices
Serv er Management Serv ices Serv er Management Serv ices
Other Tools
Catalog Manager
Job Manager
OC4J Start / Stop (when hosted in OC4J)
System Manager
ODBC Client
Oracle BI Publisher Enterprise
Core BI Server Functionality
Data Integration through Business Model View
Calculation and analytical engine
Support for RDBMS and OLAP data sources
Intelligent Request Generation and
Optimized Data Access
Security and Data Scoping
ODBC Interface out, native RDBMS and
OLAP interfaces in
Clustering, replication, support
for Windows and Unix/Linux hosts,
32-bit and 64-bit
Data Access
Reporting data may be sourced from
multiple databases, applications
Oracle Database (including Oracle OLAP)
IBM DB2
Microsoft SQL Server
Teradata
Microsoft Analysis Services (OLAP)
SAP BW 'info cubes'
SAP, Peoplesoft, Siebel, E-Business Suite
Oracle BI Server joins this source
data together and presents a
logical business model
Facts
Dimensions
Calculations
Joins
Presentation folders
Customer
Common Enterprise Information Model
Metadata layer for OBIEE tools
Three layers of metadata
Physical layer, connections to sources
Logical layer, denormalized facts
and dimensions
Presentation layer, report-centric
folders
Maintained using BI Administrator
Model is the center of the OBIEE
universe

Model First development
Data Modeling using Oracle BI Server
Design goal for the BI Server metadata layer is to create a Star Schema
Fact tables
Dimension tables
Drill paths
Source data can either be pre-integrated (data mart,
data warehouse) or integrated using
the BI Server (federated)
Federated can be faster to deliver (report in place)
- Assumes data sources share common key values
Data marts are simpler and faster to query
MDX (OLAP, Multi-dimensional) data is converted into
RDBMS row-sets
Logical layer is main integration point
Presentation layer allows report centric folders
Information Model Layers
Physical Layer contains connections, physical tables
Connections start as ODBC, switch to native (OCI etc)
Primary keys and foreign keys
Logical layer is where the data is integrated
Logical fact tables, logical dimension tables
Dimensions
Calculations
Complex joins to define relationships
Presentation layer is where data is presented
Can be a simple copy of the logical layer
Or can be made more personalized
Report centric
Star Schema Design Approach
Classic Kimball approach
Fact tables contain measures, and joins to dimensions
No attributes except for degenerate dimensions
Leave IDs in, remove in Presentation layer
Dimension tables contain lookup data
Customer, Product, Time etc
Dimensions can however be facts
- Use alias tables to disambiguate
Dimension objects define drill path
Multiple hierarchies supported
Ragged hierarchies possible (see later)
Time dimensions enable time-series queries
Sample Business Model
Data Modeling Workflow Steps
1. Create logical model in business model & mapping layer
2. Import physical data sources & define primary and foreign keys
3. Map logical model to physical model
4. Create initial calculations
5. Create dimensions
6. Rename and tidy-up logical model
7. Create initial presentation model
8. Create complex calculations, time dimensions etc
9. Add additional columns to presentation model
Exercise Reporting Scenario
Global Company has a data warehouse, containing order and customer data
Requirement is to take the existing warehouse (normalized)
and turn it into a star schema (denormalized)
For now, OBIEE will be used to map the data
Step 1: Create Logical Model in Business Model Layer
Firstly, create new logical model
Then create logical tables and columns
Either create from scratch, then connect to physical
(best practice)
Or define by dragging and dropping physical tables
Start from fact table and work outward to the dimensions
Do one fact/dimension combination first
Then add more facts
... and more dimensions
Add details on datatypes etc later on
Create a new Logical Business Model in the Repository
Demonstration
Step 2: Create Physical Layer
Create either a native (i.e. OCI) or ODBC connection through to data source
Import tables, views, keys etc from
data source
Define keys, foreign keys if needed
Update row counts
Define table aliases
Physical Join Types
If source data has foreign key joins, they will be imported
If not, they can be defined in the physical model
Two types of join
Foreign key joins (e.g. CUSTID = CUSTID)
- 1:N joins only
Complex joins (TRAN_DATE between
STARTDATEID and ENDDATEID)
- also supports 1:1, O:1, 1:O etc
Important to create physical joins
before importing in to logical layer
Logical joins rely on physical joins
to define paths
Makes life a lot simpler
Importing the Physical Table Metadata into the Repository
Demonstration
Step 3: Mapping the Logical Model to the Physical Model(s)
Once you have your logical model and one or more physical models, you can map
them together
The simpler the mapping, the better
Drag and drop physical columns
on to the logical model
Logical model will inherit
physical data types
Logical Table Sources
Logical tables can have more than one physical source
Can create >1 Logical Table Source
BI Server creates two physical queries
Useful when mapping data from
different levels
and when using fragmentation
Each Logical table source can have
>1 table mapped
BI server creates one query per LTS, joining
as per physical foreign key joins
Used when you need columns from other
joined tables in your logical table
(join only happens if additional
columns requested)
Consider Where to Join Data
Again, consider where to integrate and join data
Whilst the BI Server can join data, it may be faster to load into a data mart
ETL tools can integrate data at time of load
Denormalized data structures can be faster than joining at report time
Indexing, Summary Management, Query Optimization
Creating a data warehouse still is the optimal solution
BIEE data source joining features are most appropriate when bringing
new data in thats not yet in the data warehouse
Logical Join Types
Logical tables are by default not joined
Logical layer supports both foreign key
and complex joins
Foreign key joins not recommended
Restrict choices that BI server
can make over join paths
Only there for backward compatibility
Complex joins are preferred
Indicates relationship between
tables
Allows BI Server to determine
best join path
- Useful when more than one
Logical Table Source
Map Logical to Physical Model, and create Logical Joins
Demonstration
Step 4: Create Initial Calculations
Calculations are created as additional logical columns
Sit alongside existing logical columns derived from physical layer
Calculations can also
be created within report

OBIEE SQL and the Expression Editor
Calculations within the repository are defined using the Expression Editor
Uses OBIEE SQL Syntax
Reference functions,
expressions, logical
columns, constants,
variables
Same SQL syntax across
all supported databases
Ability to pass-through
function calls using
EVALUATE function
Create Calculations in the Optimal Location
Whilst the BI Server can create calculations, it may be more appropriate
to do this in the underlying database
Oracle Database analytic functions (LAG, LEAD, RANK etc)
Oracle Database OLAP functions (time-series, forecast, allocation)
Use the available architecture efficiently
Perform calculations as close to the source data as possible
Use dedicated OLAP technology if available
Use BI Server to provide features not found in the sources
Just because the BI Server can do something, doesnt mean it should do
something
Creating Calculations
Demonstration
Step 5: Create Dimensions and Hierarchies
Dimensions define hierarchical relationships between columns
Also used when defining level-based measures
and summaries
Level-based, starts with Grand Total level
One-way export out to Oracle dimensions (DDL)
also possible
Enables hyperlinks on columns within
dimension levels
Drill-down through the hierarchy
No drill-up or drill to related (yet)
Multiple Hierarchies and Ragged / Unbalanced Hierarchies
Dimensions with multiple hierarchies are possible
All hierarchies must share common top and bottom levels
Ragged hierarchies, unbalanced hierarchies only supported for
multi-dimensional data sources
MS Analysis Services, SAP BW,
Oracle Hyperion Essbase
For relational, need to balance
hierarchy beforehand
Creating Dimensions
Demonstration
Step 7: Create Initial Presentation Models
Business models themselves are not visible to users
Users see presentation models whose columns are
defined in business models.
Appear as subject areas
in the Oracle BI Answers
Appear as databases to
client tools using ODBC
Can create multiple
Presentation Catalogs from
single Logical Model
Creating Presentation Models
Demonstration
Step 9: Creating Time Dimension and Time-Series Calculations
OBIEE 10.1.3.2 supports limited time-series functions
AGO value of a measure x months, quarters, years ago

AGO(Videostore."Sales fact view".Sales, Videostore.TimesDim."Month", 1)

TODATE value of a measure to the end of a month, quarter, year

TODATE(Videostore."Sales fact view".Sales,
Videostore.TimesDim."Quarter", 1)

Requires at least one time dimension in the
metadata layer
Requires at least one or more Chronological keys
Monotonically increasing value (DAY etc)
The Calculation Wizard
Wizard that generates share, percentage change etc calculations
Useful in conjunction with
Time Dimension
% Change since last month
Change since last month etc
Index
Percent
Wraps ISNULL around calcs
Creating Time Dimension and Time-Series Calculations
Demonstration
Reporting Across Multiple Data Sources
OBIEE can combine and join data from multiple data sources
Data is retrieved in separate SQL, MDX calls and joined using the BI Server
Allows you to perform federated queries
Watch out for performance though
End goal should be to eventually move reporting data to a data warehouse
Federated Query Scenario
Additional data exists in an Excel spreadsheet
Contains quotas, plus information on products and dates
Quotas are at the product category and month level
Existing data is at the product and day level
Requirement is to join data, but only show quotas the relevant level
Joining A Second Data Source : Step 1
Import the new schema into the physical model, ensure FK and PK
constraints are set
Use the Join Manager, or Physical Model Diagrammer, to create
joins between tables in the two schemas
Add the new dimension tables as additional logical table sources
to the existing logical dimension tables
Set the dimension hierarchy level at which they
are applicable
Add the additional measures to the fact table
Set the dimension levels at which the measures become relevant
Adding Additional Data Sources
Demonstration
Summary
The Business Model is central to Oracle BI Suite Enterprise Edition
Consists of physical, logical and presentation layers
Foundation is properly-joined physical table sources
Denormalized star schema built using complex logical joins
Calculations (including time-series calculations) not available in the source
database can be added to logical model
Where possible though, use in-database analytics and OLAP
Dimensions defined to determine drill paths
Additional data sources can be combined in a single business model
Lession 2 : OBIEE Architecture and Relational Data Modeling

Lession 3 : Inside the Oracle BI Server

Inside the Oracle BI Server (10g)
Inside the Oracle BI Server
In this session, we will look in-depth at the Oracle BI EE Oracle BI Server
What components are in the BI Server
What is the Navigator, and how does it
turn incoming logical requests into
optimized physical SQL and MDX
What happens when it processes a query
What happens when the BI Server joins
resultsets in memory
And what influences SQL generation, join
strategy and BI Server resource usage
Why Is This Topic Important?
Now this could be a pretty boring topic
But its one of the most important parts of the BI EE technology stack
It provides all of these key features
Query Federation
Heterogeneous Connectivity
The Semantic Model
Aggregate Navigation
Time Travel (sort of)
So what really happens when Answers
fires off a query, and the BI Server
goes and gets the data...?
The Oracle BI EE 10g Server Architecture
The Oracle BI Server 10g Architecture
Logical SQL interface via ODBC and JDBC
Intelligent Request Generator, made up of
Logical request generator
Navigator
Optimized Query Rewrites
Execution Engine
Cache Services
Other services include
Load balancing (in conjunction with
cluster controller)
Query governance
Session Management
System / Perf Monitoring (JMX etc)
Intelligent Request Generation and the BI Server Navigator
The Navigator is the key component that
parses incoming requests and generates
the relevant physical SQL and MDX queries
Invoked if cache cannot be used
Handles the following translations
Function push-down
Multi-pass logic (time series etc)
Aggregate navigation
Fragmentation navigation
Responsible for generating optimized
SQL and MDX for the mapped data sources
Uses rules and definitions present in the RPD
The BI Server tries to push functions and joins down to the underlying databases
Where not possible, the BI Server will functionally compensate by calculation,
joining data sources in memory
Parse Incoming Logical SQL
Generate Optimized Physical SQL(s)
Receiving Incoming Resultsets
Apply any required functions and joins
Return data to user
The BI Server Functional Compensation Model
How Does The BI Server Process Queries?
So what happens when the BI Server processes an incoming query?
What are the steps involved in translating logical requests to physical queries?
What does the Navigator do?
What rules and statistics does it use?
How can we influence the physical queries that it generates?
How can we tell what is going on?
Step 1 : Request Arrives at Intelligent Request Generator
Query arrives from Answers or other ODBC tool, against Semantic Model
Passed to Intelligent Request Generation function
Step 2 : Request Passed to Logical Request Generation Engine
Request passed to Logical Request Generation engine, responsible for
generating the one or more logical SQL required to satisfy the query
In this case, request requires multiple columns and a derivation (calculation)
Step 3 : Check Cache if Enabled
If caching is enabled, Cache Services is checked for the result
Avoids calls to physical databases for frequently-requested data
Intelligent checking of cache including derivation, projection, nested formulas etc
Rules for a Cache Hit
Caching is enabled (CACHE=Y in the NQSConfig.INI file);
WHERE clause is semantically the same
or a logical subset of a cached statement;
All of the columns have either to be present
or derivable from cached copies
It has equivalent join conditions
If DISTINCT is used, the cached copy has to
use this attribute as well
Aggregation levels have to be compatible,
being either the same or more aggregated
than the cached query
No further aggregation (for example, RANK)
can be used in the incoming query
Compatible ORDER BY clause
Step 4 : Request Passed to the Navigator
Navigator is responsible for navigating the semantic model and generating
the execution plan, and most optimal physical SQLs, for the request
Contains multiple functions that are used dependent on the nature of the request
Step 5 : Multi-Pass / Sub-Request Logic
Analyzes request and works out the complexity of the query
Determines whether multi-pass logic is required (time-series etc)
Works out whether one request depends on the results of another (sub-request)
Navigator uses this
function to determine
the most efficient way
to satisfy the request
Step 6 : Fragment Optimization
When a measure is fragmented, the Fragment Optimization function will
transform base-level logical SQL into logical SQL fragments
Also automatically resolves fan-trap issues
Step 7 : Aggregate Navigation
Aggregate Navigation checks aggregates mapped in RPD for relevance
Execution Plan will be written to use aggregates if they return less rows than
the default logical table sources
Step 8 : Optimized Query Rewrite, and pass to Execution Engine
Optimized Query Rewrite checks database capabilities for function shipping
and ability to join subqueries
Generates optimal physical SQL or MDX for relevant data sources
Passed to Execution
Engine for transfer
to physical databases
Step 9 : Copy Back to Cache Services, if Enabled
Results are returned to calling application (Answers etc)
If caching is enabled, results are copied back to Cache Services
Key Navigator Functionality
BI Server will pick one or more LTSs at run-time based on query context
Generates an execution plan
Will try and generate as few physical SQL as possible
Will try to push down functions if possible
Will try to push down joins if possible
Will write the optimal SQL or MDX for the
data source, based on DBFunctions.INI matrix
Level 5 Query Logging and Logical Execution Plans
The execution plan generated by the Navigator can be viewed when Level 5
logging is enabled
Shows the execution plan, step-by-step row counts, and the physical SQL / MDX
generated for the request
BI Server Joins
(Almost) Every request requires joins
For simple queries, you dont notice this because they are pushed down to the DB
For more complex queries, the BI Server may need to get involved
Where more than one physical database provides data for the request
Where multi-pass logic is used
Where measures are fragmented
Where more than one fact table is used in the request
Basic principle is that the BI Server tries to push down all joins
Depending on the database type and version and nature of request,
the BI Server may need to perform the joins instead
The BI Server Source-to-Target Metadata Model
Facts and dimensions are mapped to physical sources Logical Table Sources
LTS are chosen at run time based on RPD
definitions (level mapping, fragmentation, federation etc)
So What Does The BI Server Do, When It Joins Data In Memory?
So just what goes on when the BI Server joins data in memory?
How can we tell when the BI Server has performed the join?
Why does the BI Server sometimes do the join, and sometimes get the database
to do it instead?
BI Server Join Type 1 : Fact + Dimension from Single Database
Single logical fact and dimension table, joined by a logical join
Both logical tables have single LTS, which both point to tables in the
same physical database
Physical tables are joined using a physical foreign key
Sales
Logical
Fact
Products
Logical
Dimension
Products
Physical
Table
Sales
Physical
Table
LTS Mapping
LTS Mapping
Single Database
Single Source Fact and Dimension Execution Plan & SQL
BI Server generates execution plan with single logical SQL including join clause

Single physical SQL with join pushed down to database
RqList <<2105>> [for database 3023:2820:orcl3,44]
PRODUCTS.PROD_SUBCATEGORY_DESC as c1 GB [for database 3023:2820,44],
sum(SALES.QUANTITY_SOLD by [ PRODUCTS.PROD_SUBCATEGORY_DESC] ) as c2 GB [for database 3023:2820,44]
Child Nodes (RqJoinSpec): <<2136>> [for database 3023:2820:orcl3,44]
PRODUCTS T2874
SALES T2911
DetailFilter: PRODUCTS.PROD_ID = SALES.PROD_ID [for database 0:0]
GroupBy: [ PRODUCTS.PROD_SUBCATEGORY_DESC] [for database 3023:2820,44]
OrderBy: c1 asc [for database 3023:2820,44]

select T2874.PROD_SUBCATEGORY as c1, sum(T2911.QUANTITY_SOLD) as c2from PRODUCTS T2874, SALES
T2911where ( T2874.PROD_ID = T2911.PROD_ID ) group by T2874.PROD_SUBCATEGORYorder by c1
BI Server Join Type 2 : Fact + Dimension from Two Databases
Both logical tables have single LTS, which point to different databases
Physical tables are joined using a
physical foreign key
Sales
Logical
Fact
Products
Logical
Dimension
Products
Physical
Table
Sales
Physical
Table
LTS Mapping
LTS Mapping
Database #1
Database #2
Multiple Source Fact and Dimension Execution Plan
Excerpt of plan (source rqList cropped)
Two logical SQL blocks with InnerJoin between fact and dimension tables
Can also be LeftOuterJoin, RightOuterJoin and FullOuterJoin
(
RqList <<2495>> [for database 3023:132:orcl,44]
SALES.PROD_ID as c2 [for database 3023:132,44],
sum(SALES.QUANTITY_SOLD by [ SALES.PROD_ID] ) as c3 [for database 3023:132,44]
Child Nodes (RqJoinSpec): <<2504>> [for database 3023:132:orcl,44]
SALES T211
GroupBy: [ SALES.PROD_ID] [for database 3023:132,44]
) as D901
InnerJoin <<2492>> On D901.c2 = D902.c2; actual join vectors: [ 0 ] = [ 1 ]
(
PRODUCTS.PROD_SUBCATEGORY_DESC as c1 GB [for database 3023:2500,44],
PRODUCTS.PROD_ID as c2 [for database 3023:2500,44]
PRODUCTS T2502
OrderBy: c2 asc [for database 3023:2500,44]) as D902
OrderBy: c2, c3 [for database 0:0,0] ) as D1
Multiple Source Fact and Dimension Physical SQL
Two physical SQL queries sent to the two databases
BI Server joins the two sources in-memory using a sort-merge join algorithm
-------------------- Sending query to database named orcl (id: <<6057>>):select T211.PROD_ID as c2, sum(T211.QUANTITY_SOLD) as c3from SALES T211group by T211.PROD_IDorder by c2+++Administrator:2b0000:2b000b:----2010/04/17 00:04:03-------------------- Sending query to database named orcl2 (id: <<6074>>):select T2502.PROD_SUBCATEGORY as c1, T2502.PROD_ID as c2from PRODUCTS T2502order by c2
BI Server Join Type 3 : Fact + Dimension Using Driving Table
Two tables typically LTS mapped to different physical databases
One of the logical tables defined as a driving table in the BMM logical join
Driving table uses Parameterized Nested
Loop Join (PNLJ) to probe other table
Sales
Logical
Fact
Products
Logical
Dimension
Products
Physical
Table
Sales
Physical
Table
LTS Mapping
LTS Mapping
Database #1
Database #2
PNLJ
Probe
Lookup
Driving Table Considerations
By default, federated queries will cause both tables to be loaded into the BI Server
memory, and then joined (as per previous example)
Can be expensive if one or more of the tables are large
An alternative is to designate one of the tables as
the driving table
Needs to be small, typically <1000 rows
This table is then queried and filtered first,
then its remaining rows are then applied as
a filter to the second table
Driving table is defined in the Logical Join dialog
Parameterized Nested Loop Join Algorithm & Physical SQL
1. Start reading rows from the driving table
2. Submit a parameterized query request to non-driving table
3. Bind values from the drive-table rows into the parameterized query and fetch results
4. Repeat until all rows from drive table are processed
RqList PRODUCTS.PROD_SUBCATEGORY as c1 GB, QUANTITY_SOLD:[DAggr(SALES.QUANTITY_SOLD by [ PRODUCTS.PROD_SUBCATEGORY] )] as c2 GBOrderBy: c1 asc
select T2502.PROD_SUBCATEGORY as c1, T2502.PROD_ID as c2from PRODUCTS T2502order by c2
select T211.PROD_ID as c2, sum(T211.QUANTITY_SOLD) as c3from
SALES T211where ( T211.PROD_ID in (:PARAM1, :PARAM2, :PARAM3,
:PARAM4, :PARAM5, :PARAM6, :PARAM7, :PARAM8, :PARAM9, :PARAM10,
:PARAM11, :PARAM12, :PARAM13, :PARAM14, :PARAM15, :PARAM16,
:PARAM17, :PARAM18, :PARAM19, :PARAM20) ) group by T211.PROD_ID
order by c2
Fact and Dimension Driving Table Execution Plan
Excerpt of plan
Note InnerJoin (left drive) and parameterized DetailFilter in plan
( RqList <<13655>> [for database 3023:2500:orcl2,44] PRODUCTS.PROD_SUBCATEGORY as c1 GB [for database
3023:2500,44], PRODUCTS.PROD_ID as c2 [for database 3023:2500,44] Child Nodes (RqJoinSpec): <<13658>> [for
database 3023:2500:orcl2,44] PRODUCTS T2502 OrderBy: c2 asc [for database 3023:2500,44] ) as D901
InnerJoin (left drive) <<13689>> On D902.c2 = D901.c2; actual join vectors: [ 1 ]=[ 0 ] ( RqList <<13673>> [for database
3023:132:orcl,46] SALES.PROD_ID as c2 [for database 3023:132,46], sum(SALES.QUANTITY_SOLD by [
SALES.PROD_ID] ) as c3 [for database 3023:132,46] Child Nodes (RqJoinSpec): <<13676>> [for database 3023:132:orcl,46]
SALES T211 DetailFilter: SALES.PROD_ID = ?1 or SALES.PROD_ID = ?2 or SALES.PROD_ID = ?3 or
SALES.PROD_ID = ?4 or SALES.PROD_ID = ?5 or SALES.PROD_ID = ?6 or SALES.PROD_ID = ?7 or SALES.PROD_ID = ?8
or SALES.PROD_ID = ?9 or SALES.PROD_ID = ?10 or SALES.PROD_ID = ?11 or SALES.PROD_ID = ?12
or SALES.PROD_ID = ?13 or SALES.PROD_ID = ?14 or SALES.PROD_ID = ?15 or SALES.PROD_ID = ?16
or SALES.PROD_ID = ?17 or SALES.PROD_ID = ?18 or SALES.PROD_ID = ?19 or SALES.PROD_ID = ?20 [for database 0:0]
GroupBy: [ SALES.PROD_ID] [for database 3023:132,46] OrderBy: c2 asc [for database 3023:132,46] ) as D902
BI Server Join Type 4 : Two Facts Using a Single Database
Query requires data from two fact tables, sharing a common dimension
BI Server creates two logical queries and stitches results together, to avoid fan trap
Join is pushed down to the database if possible
Sales
Logical
Fact
Products
Logical
Dimension
Costs
Logical
Fact
Single Database
Sales
Physical
Table
Products
Physical
Table
Costs
Physical
Table
LTS Mapping
LTS Mapping
LTS Mapping
Facts with Conformed Dimensions Execution Plan
Two result sets are generated, with a FullOuterStitchJoin between them
Capabilities of physical database determine whether join is pushed down to database
(
sum(COSTS.UNIT_COST by [ PRODUCTS.PROD_SUBCATEGORY_DESC] ) as c1 GB [for database 3023:2820,46],
PRODUCTS.PROD_SUBCATEGORY_DESC as c2 GB [for database 3023:2820,46]
PRODUCTS T2874
COSTS T2830
DetailFilter: COSTS.PROD_ID = PRODUCTS.PROD_ID [for database 0:0]
) as D1 FullOuterStitchJoin <<3565>> On D1.c2 = D2.c2
(
sum(SALES.AMOUNT_SOLD by [ PRODUCTS.PROD_SUBCATEGORY_DESC] ) as c1 GB [for database 3023:2820,46],
PRODUCTS.PROD_SUBCATEGORY_DESC as c2 GB [for database 3023:2820,46]
PRODUCTS T2874
SALES T2911
DetailFilter: PRODUCTS.PROD_ID = SALES.PROD_ID [for database 0:0]
) as D2
Facts with Conformed Dimensions Single Physical SQL
Where database supports subquery factoring (Oracle 10gR2+) a single physical SQL will
be generated with a full outer join between all shared dimension columns
WITH
SAWITH0 AS (select sum(T2830.UNIT_COST) as c1,
T2874.PROD_SUBCATEGORY_DESC as c2
from
PRODUCTS T2874,
COSTS T2830
where ( T2830.PROD_ID = T2874.PROD_ID )
group by T2874.PROD_SUBCATEGORY_DESC),
SAWITH1 AS (select sum(T2911.AMOUNT_SOLD) as c1,
from
PRODUCTS T2874,
SALES T2911
group by T2874.PROD_SUBCATEGORY_DESC)
select distinct SAWITH0.c1 as c1,
SAWITH1.c1 as c2,
case when SAWITH0.c2 is not null then SAWITH0.c2
when SAWITH1.c2 is not null then SAWITH1.c2 end as c3
from
SAWITH0 full outer join SAWITH1 On SAWITH0.c2 = SAWITH1.c2
order by c3
Facts with Conformed Dimensions Multiple Physical SQL
Otherwise, multiple physical SQL queries will be generated
BI Server will perform in-memory sort-merge stitch full outer join on shared dim columns
-------------------- Sending query to database named orcl3 (id: <<3018>>):

select sum(T2830.UNIT_COST) as c1,
from
PRODUCTS T2874,
COSTS T2830
group by T2874.PROD_SUBCATEGORY_DESC order by c2

+++Administrator:2a0000:2a0005:----2010/02/28 15:05:31

-------------------- Sending query to database named orcl3 (id: <<3055>>):

select sum(T2911.AMOUNT_SOLD) as c1,
from
PRODUCTS T2874,
SALES T2911
group by T2874.PROD_SUBCATEGORY_DESC order by c2
Stitch Joins and Federated Queries
Stitch joins are used whenever multiple fact tables are used in queries
Also used when federated fact table sources are used, and aggregate sources
Basic principle is to join facts using FullOuterStitchJoin
across all dimension attribute columns used in the query
...
) as D901 FullOuterStitchJoin <<7800>>
On D901.ProductCategory =NullsEqual D902.ProductCategory
and D901.ProductCategory =NullsEqual D902.ProductCategory;
actual join vectors: [ 0 1 ] = [ 0 1 ]
(
...
Rules for BI Server Join Strategy
Try to generate as few physical SQL / MDX queries as possible
Push as many joins (and functions) down to the database as possible
Where required, join fact and dimensions in memory using inner and outer sort-merge joins
If driving table is specified, iterate through join using nested loop algorithm
Generate one logical SQL query per fact table access,
push down stitch join to database using full outer join
if possible, if not have the BI Server do it
Logical execution plan and resulting
physical SQLs visible in the Level 5 log file
BI Server Join Variations 1 : Fragmentation (Partitioned Measures)
RPD has a measure mapped through two or more LTS to different physical tables
One physical source for historic data, one for real-time
One for Southern Region, one for Northern Region
Known as fragmentation
BI Server has to UNION the resultsets
together
Fragmentation (Partitioned Measures) Logical Execution Plan
Execution Plan will contain two logical SQL blocks (excerpt shown below)
RqUnion All unions the two resultsets, BI Server will attempt to push down to database
if possible (if not, two physical SQLs will need to be retrieved and UNION done in memory)
(
PRODUCTS.PROD_SUBCATEGORY_DESC as c2 [for database 3023:6594,44],
SALES_UPTO_2003.AMOUNT_SOLD as c3 [for database 3023:6594,44]
PRODUCTS T6596
SALES T6629
DetailFilter: PRODUCTS.PROD_ID = SALES_UPTO_2003.PROD_ID [for database 0:0]
RqUnion All <<7690>> [for database 3023:6594:orcl7,44]
PRODUCTS.PROD_SUBCATEGORY_DESC as c2 [for database 3023:6594,44],
SALES_BEYOND_2003.AMOUNT_SOLD as c3 [for database 3023:6594,44]
PRODUCTS T6596
SALES T6637
DetailFilter: PRODUCTS.PROD_ID = SALES_BEYOND_2003.PROD_ID [for database 0:0]
) as D3
BI Server Join Variations 2 : Time-Series Queries
Generated when time-series functions are used in a request
Requires time dimension to be defined in RPD
Currently limited to AGO and TODATE functions
Generates two or more logical SQL queries which need to be joined together to return time-
series results
Time Series Logical Execution Plan
Execution plan will show multiple nested logical SQL blocks
More complex set of nested blocks will be doing the time offset
Time offset block will need to be FullOuterStitchJoined to the present-day resultset
Excerpt shown below

Depending on DB capabilities, will either be shipped as one SQL (using subqueries)
or as two or more SQLs (with results full outer stitch joined in memory)
...
DetailFilter: ITEMS.ORDID = ORDERS.ORDID and ORDERS.ORDERDATE = D4.c2
and D3.c1 = D4.c1 and D3.c2 = 'May-2007' [for database 0:0] GroupBy: [ D3.c2, D3.c3] [for database 3023:4210,44]
) as D1 OrderBy: c1 asc [for database 3023:4210,44] ) as D901 FullOuterStitchJoin <<4892>>
On D901.c1 =NullsEqual D902.c1; actual join vectors: [ 0 ] = [ 0 ] (
RqList <<4963>> [for database 3023:4210:orcl4,44] D2.c2 as c1 [for database 3023:4210,44],
D2.c1 as c2 GB [for database 3023:4210,44], D2.c3 as c3 [for database 3023:4210,44]
...

Memory and Disk Usage During BI Server Joins
So what happens when the BI Server performs an in-memory join?
The BI Server requires memory to join the data sets using a sort-merge algorithm
Initial memory usage is determed by size/complexity of the RPD
Memory usage then rises with # of concurrent
sessions, in-memory joins, aggregations
Typically paged to file at
{ORACLEBIDATA}/tmp
Because of paging, use of BI Server
functional compensation is largely I/O
intensive rather than memory intensive
Extent of paging driven by
VIRTUAL_TABLE_PAGE_SIZE parameter
May benefit from increase on Unix systems
Docs do not imply much benefit though
So What Influences Execution Plans and Physical Query(ies)?
Logical Execution Plan largely determined by the LTS mappings in the RPD
BI Server Navigator generates execution plan based on context of the request
and the LTS configuration in the BMM layer
All can be determined by looking at the RPD
No equivalent to the Oracle database CBO
Physical SQL then determined by
execution plan and DBFeatures.INI
Are There The Equivalent of Object Statistics in the RPD?
There are some limited statistics in the RPD that influence the query plan
Row counts on physical tables are ignored
Number of Elements at this Level value can be used by the Navigator to
determine which of several aggregates to use for a request
Needs to be manually populated (rough figure is OK)
Dimension Level Element Counts In Use
Consider the following dimension
Time Dim -> Year (2), Month (24), Days (730)
Products Dim-> Type (10), Sub-Type (20), SKUs (1000)
Customers Dim-> Regions(20), Districts(500), Customers (100000)

Sales Fact joins to these dimensions at the lowest level.
Also assume I have a couple of aggregate tables :
Sales Fact Agg1 -> (Time Dim)Year, (Customer Dim) Districts
Sales Fact Agg2 -> (Time Dim)Year, (Product Dim) Sub-Type

Consider this Query Example :
Select Year, Sum(Revenue) from Sales ;
This can be satisfied by either Agg1 or Agg2, but BI Server has no way of
knowing which is the best option unless the number of elements are entered.
What Does the Logical Execution Plan Tell Us?
It tells us how the BI Server Navigator turned the logical request into physical SQL
and MDX queries
But theres nothing that you couldnt infer from the RPD
There are no parameters etc that you can use to alter join strategies etc
This is driven by the repository design only
Extra information provided by Level 7 logging is interesting
Times logged by each entry/step
Tells us how long the BI Server
takes to do each join
Can be used to fine-tune the
VIRTUAL_TABLE_POOL_SIZE
parameter
So What Does This All Tell Us?
Co-locate data as much as possible, minimize in-memory joins
Make sure the database version and capabilities is set correctly for each source
Maximize function push-down, mimimize functional compensation
Understand what happens with BI Server joins, and how to read the execution
plan
Understand what a FullOuterStitchJoin is, and how to avoid unneccesary ones
Understand the role of LTSs and when to add or remove them
There is some diagnostic data available for the BI Server, but most of what
you need is contained in the RPD design
Thank You for Listening
More details on this topic, and on OBIEE in general, can be found on our blog
http://www.rittmanmead.com/2010/02/25/inside-the-oracle-bi-server-part-1-the-bi-server-
architecture/
http://www.rittmanmead.com/2010/03/01/inside-the-oracle-bi-server-part-2-how-is-a-query-
processed/
http://www.rittmanmead.com/2010/03/03/inside-the-oracle-bi-server-part-3-bi-server-in-memory-
joins/
Thank you for your time
Any questions :
Web : http://www.rittmanmead.com
Email : mark.rittman@rittmanmead.com
Twitter : @markrittman
Lession 3 : Inside the Oracle BI Server

Inside the Oracle BI Server (10g)
Lession 4 : Building Reports and Dashboards

Introducing Oracle BI Answers
The Ad-hoc report editor for Oracle BI Suite Enterprise Edition
Modify existing reports, create new reports
Add graphs, formatting, titles and other features, then publish to dashboard
Starting Oracle Answers
New reports are created using Oracle Answers
Click on the Answers link at the top right-hand side of the dashboard
Selecting Subject Areas and Existing Reports
Answers initially presents you with a list of subject areas
Existing reports, in your own, and shared folders
Click on a subject area
to start creating a report
The Oracle BI Answers Interface
Filters Applied
To Results
Other Data
You Can Add
Tabs to View
Results, Prompts
Save, Open
and New Buttons
Data Items in
Your Report
(Criteria)
The Report Criteria
Lists out the data items (columns) that make up your report
Buttons for filtering, formatting, renaming columns
Adding Data Items to a Report
The left-hand pane in Answers lists the tables and columns
you can add to your report
Click on the tab name to display the available columns
Showing Report Results
Click on the Results tab to show the report results
Viewing the Results
Initial view of the results is a table
Simple listing of items
Notice the Title bar above the table - you will now configure it
Using the View Selector
Reports in Oracle Answers can have multiple Views associated with them
Default views are Table, Title and Compound
Table view is a simple listing
Title view provides a title, subtitle and icon
Compound view combines multiple views
Compound view is normally the view
displayed in the dashboard
Adding a Graph
From within the Results tab view, select Chart from the view selector
Chart view is then displayed, with Bar Chart as the default graph
Graph Types
Area
Horizontal Bar
Bubble
Vertical Bar
Line
Line-Bar Combo
Pareto
Pie
Radar
Scatter
Step
Adding Gauges
Gauges are another view option
Select using View Selector, choose Gauge type using drop-down menus
Adding Images into Reports
Reports can be more informative when
using pictures to illustrate values
Gauges to show KPIs
Arrows to show trends
Warning signs to show issues
Stars to show popularity
Answers can conditionally format any value
using a set of images
Adding Navigation to Views
By default, drilling on a column or heading displays data in more detail
Drill down from country > city > town > customer
Views can be instructed to instead navigate
to a different report or URL
Column value clicked on to
the target request
Receiving request needs to set filter to
Is prompted
Building Reports with Oracle BI Answers
Demonstration
Introducing Oracle BI Dashboard
One-stop shop for all your users reports
Fully interactive, single UI for report consumers
Dashboard Key Features
Reports
Selectors Graphs
Narratives
Tabs
Log In / Log Off
Print & Save Modify
The Dashboard Editor
Objects you can
add to dashboard
Reports you
add to dashboard
Dashboard
Sections
Control for
Viewing and Adding
Tabs (pages)
Buttons for Editing
Report and
Section Properties
Button for
Editing Dashboard
Properties
Adding Requests to the Dashboard
Drag and Drop from the list of available reports
Add Sections from the Dashboard Objects palette as required
Select view of data
Add links for printing,
downloading etc
Creating Dashboards
Demonstration
Lession 4 : Building Reports and Dashboards


Rittman Collab10 Biee Deepdive

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rittman Collab10 Biee Deepdive

Transféré par

Droits d'auteur :

Formats disponibles

T : +44 (0) 8446 697 995 or (888) 631 1410 (USA) E : enquiries@rittmanmead.com W: www.rittmanmead.

Vous aimerez peut-être aussi