BMM Layer New Features-OBIEE11g

8/22/2019 BMM Layer New Features-OBIEE11g

1/31

OBIEE Data Modelling Best Practices and New Features

Introduction

This white paper aims to set out some basic good, and best practices for data modelling

using Oracle Business Intelligence Enterprise Edition. The basic good and bestpractices apply to all versions of Oracle Business Intelligence, whilst the latter half of thispaper sets out some new features available with the 11g release of Oracle BusinessIntelligence.

The OBIEE Semantic Model

Oracle Business Intelligence, like a number of enterprise business intelligence tool, has ametadata layer that aims to hide the complexity of underlying data sources and presentinformation using business terminology. This metadata layer is called the Semantic

Model and is stored in a repository, held in a single file usually referred to as an RPDfile, after the file extension that is uses.

This metadata layer works alongside a separate repository used for holding reports,dashboards and other presentation objects, called the Web Catalog.Conceptually, thesetwo repositories together with the source data can be thought of as a three-layer dataarchitecture, as shown in Figure 1 below.

Figure 1 : The Oracle Business Intelligence Data Architecture

The Oracle Business Intelligence Semantic Model is administered using the Oracle BI


2/31

Administration tool, a Windows application that ships with Oracle


3/31

Business Intelligence. This tool presents the semantic model as having threelayers, as shown in Figure 2 below.

Figure 2 : The Oracle Business Intelligence Administration Tool

The three layers are as follows:

1. The PhysicalLayer, which contains metadata on data sources, such as

relational databases, OLAP cubes, files and XML documents2. The Business Model and MappingLayer, which contains a dimensional

model of your business information, including calculations, drill paths,business definitions of data items, and in OBIEE 11g, lookup tables.

3. The Presentaton Layer, made up of one or more subject areas basedaround single fact tables and linked dimensions.

When creating an Oracle Business Intelligence semantic model, there are anumber of design objective that you should bear in mind. Starting with thephysical layer and moving through the business model, and then presentationlayers, the first objective should be to simplify the underlying data and present

it as a logical dimensional model, with measures held in one or more facttables linked to one or more conformed dimensions.

The federation capabilities of Oracle Business Intelligence should be used tolink disparate but related data sets, so that users can write queries that spanthe organizations data. The calculation capabilities of the business model andmapping layer should be used to create and expose common calculations,whilst logical dimensions can be used to formalize the drill paths within thedata set.

Finally, data should be presented to users in the form ofsubject areas (akin todata marts in physical data warehouses), with common links between them in

the form of conformed dimensions. Security, both row-level and subject area,should be set up so that users only see the data that is relevant to them, with


4/31

access made available through application roles linked to external directoriessuch as Oracle Internet Directory or Microsoft Active Directory.

Basic OBIEE Data Modelling Good Practices

So what are some basic, good practices for designing data models using anyversion of Oracle Business Intelligence Enterprise Edition? Whilst this paperdoes not intent to teach Oracle Business Intelligence data modelling from firstprincipals, here are a number of basic good practices that have worked for theauthor on a number of projects.

1. If Possible, Use a Data Warehouse as the Data Source

Whilst it is possible to have Oracle Business Intelligence report againstnormalized, OLTP-style data, the SQL generated by the BI Server will

become complex and will not perform as well against physical sourcedata already optimized into a star schema. The data modelling processis more straightforward when your source data is stored as adimensional data warehouse, and your queries will generally run faster.If possible, use a data warehouse as the data source for your OracleBusiness Intelligence semantic model.

2. Think in Terms of Dimensional Modelling

Again, whilst your source data does not have to be stored as a physicalstar schema, the business model that you build as part of the semantic

model has to be organized dimensionally, with measures in one ormore fact tables that then reference one or more (ideally conformed)dimensions. These dimensions should ideally be denormalized, thoughit is possible to snowflake the business model, and hierarchies andlevels should be defined within this model to formalize the drill pathswithin your data. If you have not done so already, read up on any of thebooks by Ralph Kimball, and think dimensionally for your businessmodel.

3. Define Keys in the Physical Layer, Ideally Against Aliased Tables

The physical layer within your semantic model generally needs primarykeys on all tables that will provide dimension source data, and foreignkeys between tables that provide fact data and tables that providedimension data. In addition, if you wish to create reports that spanmultiple databases, foreign key links between tables in thesedatabases are used by the federation capabilities of Oracle BusinessIntelligence to join, either at the database level or within the BI Server,data from these sources.

An optional good practice is to create aliases for each of the physicaltables in the physical layer, prefixing them with their role (Dim_ for

dimension, Fact_ for fact or Lkp_ for lookup) and adding a suffix if theyplay multiple roles. For example, if a table TIMES has metadataimported into the physical layer and is used for both Order Date and


5/31

Ship Date dimensions, it should be aliased as:

Dim_TIMES_Order_Date, andDim_TIMES_Ship_Date

to make it clear to other data modelers what purpose the table plays.Keys should then be defined against these aliases in accordance withthe above instructions.

4. Create Business Model using Business Terminology and Logic

The business model and mapping layer within the semantic model isused for creating a conformed, dimensional representation of theenterprise data set. As such, all measures (and only measures) shouldbe contained in one or more logical fact tables, the number of whichshould be determined by the distinct set of granularities in the data set.

Reference data used to slice and dice the measures should be held inlogical dimension tables, which should have logical dimensionstogether with hierarchies, logical levels and logical level keys. Logicaldimension tables should have logical keys associated with them, andlogical joins should be created between the logical fact and logicaldimension tables.

The logical columns within these logical tables should be renamed touse business terminology, changing for example REV_AMT to

Revenue Amount. When creating the business model, good practice

is to startby defining, at a high level, the logical fact and then logicaldimension tables, whereafter you can then drag and drop individual

physical columns into the relevant logical tables, renaming asnecessary, until the business model is compete.

Figure 3 below shows a simple initial business model, with one logicalfact table and two logical dimension tables with accompanying logicaldimensions. Note how the fact table does not contain any ID columnsfor linked dimensions, and how the logical dimensions are annoted todescribe their structure (the purpose of this will be explained later inthis paper).


6/31

Figure 3 : A Simple Business Model

5. Ensure Dimension Element Counts are (Reasonably) Accurate

The Number of Elements at this Level setting under the LogicalTable Properties dialog for logical tables gives the BI Server usefuladditional information about how may rows a query against a particularllogical dimension level will return. This information is used whendeciding between multiple aggregate logical table sources mapped into

a logical table, but is not populated automatically (Figure 4 showswhere this information should be entered by the developer).


7/31

Figure 4 : The Location of the Number of Elements at thisLevel Setting

To calculate the number of elements at a particular logical dimensionlevel, use SQL*Plus (or the equivalent for your data source) to runqueries similar to the following:

select count(distinct(prod_name)) from products;

select count(distinct(prod_type_desc)) from

products;

select count(distinct(prod_cat_desc)) from

products;

Ensure that these counts are updated if the number of elementschanges significantly, particularly if the number of elements changes

significantly in proportion to others in different levels in the same logicaldimension, or in comparable levels in other logical dimensions.

6. Publish One Subject Area Per Logical Star

it is typically good practice to contain just a single fact table, plusassociated dimension tables, within each presentation layer subjectarea, particularly now that with Oracle Business Intelligence 11g,analyses can span multiple subject areas as long as there are commonconforming dimensions. The advantage of having just a single facttable per subject area is that the purpose of the subject area is then

very clear, and it is harder to write analyses that contain incompatiblepresentation columns.


8/31

The 11g release of Oracle Business Intelligence makes it simple tocreate one or more subject areas for a related business model, withone subject area per logical fact table, through the use of the CreateSubject Areas for Logical Stars and Snowflakes feature, as shown in

Figure 5 below:

Figure 5 : Create Subject Areas for Logical Stars and Snowflakes


9/31

Using this feature, for a business model with two logical tablescontaining measures, would result in the following subject areas in thepresentation layer (Figure 6).

Figure 6 : Subject Areas Based on Individual Fact Tables

7. Develop Offline Initially, then Publish Online. Consider MUDE.

Whilst it is possible for a single developer to work online with arepository, checking in and checking out individual objects whilstdeveloping the semantic model, this approach does not generally workwell with teams of developers and also introduces overheads duringdevelopment through the need for the BI Administration tool to avoidconflicting development.

Good and best practice is for significant amounts of development workto be carried out with offline copies of repository files, with individualdevelopers changes being merged together either using the three-way

merge feature in the BI Administration tool, or more formally using theMulti-User Development Environment. Working offline with your owncopy of the repository file avoids the need to continiously check-in andcheck-out changes, and avoids the distruption to user or test queriesthat might occur if working with an online repository that is also beingreported against at the same time. Note that however, whilst multipledevelopers working online with a repository in OBIEE 10g wasunsupported, the 11gR1 release has been re-engineered to allow up tofive developers to work online with a repository, making this a valid wayto make ad-hoc changes to a repository after it has published by takingit online.

8. Pay Attention to Consistency Checks


10/31

When verifying the integrity of your semantic model (File > CheckGlobal Consistency from the BI Administration application menu), payattention to the warnings and errors that are reported.Whilst you willnot normally be able to place online a repository that has errors,

warnings are allowed but you may find that analyses return unexpectedresults, or return errors under particular circumstances.

It is general good practice to resolve all errors and warnings beforeplacing a repository online, particularly ones such as:

[39008] Logical dimension table Dim SurveyOrganizations has a source Dim_SURVEY_ORGANIZATIONthat does not join to any fact source.

that indicate that whilst your model is not invalid, there are logical

tables within the business model that have logical table sources thatmap to physical tables without the required foreign key links (this

will cause analyses to error when you include these tables in a report),

and

[39024] Dimension '"Sales"."Stores (Ragged, Skip-Level)"' has defined inconsistent values in itslevels' property 'Number of elements'.

that indicates logical inconsistencies in your data (caused, in thisinstance, by dimension member counts being incorrect). In general,most warnings will also lead to errors in your reports at some point, andin particular if you are new to Oracle Business Intelligence datamodelling, looks to resolve all warnings and errors before making arepository available for general use.

What is a Logical Table Source?

A concept that has been mentioned several times in this paper is alogical table source. Logical table sources are a key feature within thesemantic model but are often misunderstood, with common misconceptionsincluding a logical table source always equates to one physical table; alogical table source IS a physical table; and every physical tablereferenced by a logical table requires its own logical table source. So whatis a logical table source, and how are they used effectively in an OracleBusiness Intelligence semantic model?


11/31

Consider a simple business model, with three logical tables, one use for factdata and two for dimensions. Each has one logical table source mapped to it,as shown in Figure 7 below.

Figure 7 : A Sample Business Model, Showing Logical Table Sources

Each one of these logical table source represents a set of mappings, betweenthe logical columns in the business model and physical columns in thephysical layer of the semantic model. For example, the CUSTOMERS logicaltable source that is held in the Sources folder within the Customers logicaltable contains the column mappings shown in Figure 8 below.


12/31

Figure 8 : A Logical Table Source Mapping

In this mapping, all of the logical columns map to physical columns inthe same physical table. Now, consider a situation where there arecolumns in tables joined to the CUSTOMERS physical table that you wouldalso like to include in this mapping, as shown in Figure9 below.

Figure 9 : Additional Joined Physical Tables ContainingCustomer Data

To make it possible for the logical table source mapping to referencethese additional tables, firstly foreign key joins must exist between the tablesin the physical layer of the semantic model. Once the joins are in place, thelogical table source used for this logical table can then be extended, sothat itreferences these additional tables, as shown in Figure 10below:


13/31

Figure 10 : Extending a Logical Table Source to Include Related Tables

Then, the logical table source mapping can reference these additionalphysical column, as shown in Figure 11 below:

Figure 11 : A Logical Table Source Mapping Referencing Multiple Physical Tables

Each logical table in the business model will have one or more logicaltable sources associated with it; at the start, there will normally be just one.When the BI Server then comes to generate a physical SQL or MDX query toreturn data for a query using these logical tables, it will look at the total

set of physical tables referenced in the logical tables sources anddetermine whether they can be accessed via a single SQL statement,containing joins


14/31

between the tables (in effect, pushing the join down to the underlyingdatabase). If this is not possible, because for example the physical tablespointed to by one of the logical table sources are located on adatabase separate to the other tables, it will instead generate two or more

physical SQL or MDX queries, joining the results together in-memory inwhat is know as horizontal federation.

So if logical table sources can be extended to include related tables,why would a logical table require more than one logical table source?The first reason refers back to the horizontal federation concept, and iswhere individual logical columns in a logical table are actually sourced fromdifferent databases, making it impossible to write a single SQL statementthat covers both sources. In Figure 12 below, the Total Price measure ismapped to a physical table in the ORCL Oracle database, whilst theQuotas measure is mapped to a Microsoft Excel source called Quotas. As

both of these sources are at the same level of granularity, but the BI Serveris being asked to run queries against more than one data source, this isagain referred to as horizontal federation.

Figure 12 : Multiple Logical Table Sources in a Single Logical Table


15/31

Figure 13 shows the different column mappings in the two logical tablesources, with one logical table source pointing towards the Oracledatabase,and one towards the Microsoft Excel spreadsheet. The BI Serverwill combine these two data sets together at run time through a full-outer

stitch join, a full outer join between the two data sets.

Figure 13 : Two Logical Table Source Mappings

For example, in Figure 14 below, we can see one logical table source for theFact Sales logical table mapping to an database schema containingaggregate data, whilst another points to a schema containing detail-leveldata.


16/31

Figure 14 : Logical Table Sources Mapping to Detail, and Aggregate--Level Data Sources

The Fact_A_SALES_AGG logical table source is differentiated from theFact_SALES logical table source through the Logical Dimension levelmappings held in the logical table source properties, which in this caseindicate that the logical table source contains aggregated data, as shownin Figure 15 (Product Category and Quarter are logical levels above theleaflevel of their respective dimensions).


17/31

Figure 15 : Logical Table Source Logical Dimension Level Mappings

Only one of these logical table sources would be accessed by the BIServer when a physical SQL or MDX query needed to be generated, and thedecision would be based on the level and type of aggregation requested bythe analyses. This is referred to as vertical federation, and together withhorizontal federation, these two scenarios are the major reason whylogical tables have more than one logical table source, which are simplysets ofmappings between logical and physical columns that may, or maynot be referenced depending on the context of the users analysis.

New Features in OBIEE 11gR1 for DataModelling

So now that we have gone through some basic good practices withprevious and current releases of Oracle Business Intelligence, it is worthlooking at some new features introduced with the 11g release of OracleBusiness Intelligence that may be of use to data modelers. These newfeatures include:


18/31

1. Enhanced support for logical dimensions, including skip-level,ragged and parent-child hierarchies

When creating level-based hierarchies (the only option with OracleBusiness Intelligence 10g), the situation may arise where the hierarchy

that you need to create is either ragged (where each leaf member isnot necessarily at the same level in the hierarchy), or skip-level(where some members may not have an immediate parent, insteadskipping to the level above). Figure 16 below shows a level-basedhierarchy that is both ragged, and skip-level.

Figure 16 : A Sample Ragged, and Skip-Level Dimension Hierarchy


19/31

Ragged and skip-levels are represented in the underlying datasetthrough NULLs at either what would normally be the leaf level, or at

levels that would normally hold a dimension member ID.

The 11g release of Oracle Business Intelligence gives developers theability to specify dimensions as having ragged, and/or skip-levelhierarchies, when editing the properties of the logical dimension,shown in Figure 17 below:

Figure 17 : Specifying Ragged and Skip-Level Dimension Structure


20/31

Specifying Ragged and/or Skip-Level means that the BI Server willanticipate NULLs for dimension member IDs, and when used in

combination with hierarchical columns (described below), either stopdrilling down at that point (for ragged hierarchies) or jump up or downtwo levels (for skip-level hierarchies).

One point should be noted when working with ragged and skip-levelhierarchies. When working with a ragged hierarchy, as each leafmember of the ragged dimension may not be at the lowest level of thehierarchy, it is necessary to add a surrogate key to the dimension tableto provide a consistent column on which to join to the fact table. Thissurrogate key should be used as the key for the logical dimensiontable, and used as the lowest level in the logical dimension, as shown

in Figure 18 below.

Figure 18 : Adding a Surrogate Key Level to the Logical DimensionHierarchy

When creating an associated hierarchical column for the logicaldimension, as mentioned in point 2 below, this additional level can bedeleted as a presentation level from the hierarchical column, so that

the user can only drill down as far as the immediate level above, whichis the maximum depth at which a leaf member could normally exist.

The 11g Release of Oracle Business Intelligence also introducessupport for parent-child, or value-based hierarchies. Now, when adeveloper chooses to create a logical dimension within the businessmodel, the option is given to create the logical dimension as eitherlevel-based or parent-child, as shown in Figure 20 below:


21/31

Figure 19 : Specifying a new Logical Level as Having a Parent-Child Hierarchy

Then, when the new logical dimensions properties are specified, thedeveloper has to specify the logical column that contains the Parent ID

to go with the Member ID, creating the parent-child link. Once this isdone, a closure table has to be created, which contains, for eachdimension member, a recursive list of which members are its parents,grandparents etc, avoiding the need for the BI Server to issue recursiveSQL when the dimension is traversed. Figure 21 shows the wizard thatcan be used to create this closure table, which generates two SQLscripts, one to create the closure table, and one to populate it, thesecond of which needs to be re-run whenever the underlyingdimension data is refreshed.

Figure 20 : Creating the Closure Table

So, one question that developers new to the 11g release of OracleBusiness Intelligence may have, is when to use a ragged level-basedhierarchy, or in fact a parent-child hierarchy, if they wish to create aragged hierarchy within the business model (as parent-child hierarchiesare by their nature, naturally ragged).

The answer to this question is determined by the nature of the data in


22/31

the source dimension table. If the table naturally has levels (e.g.,columns that hold clearly identifiable levels of data) then you shouldcreate the dimension hierarchy as level-based and ragged. If theunderlying source data does not naturally have named levels (perhaps

in an organizational hierarchy, or a hierarchy of trading books) then itwould better suited to a parent-child dimension hierarchy.

2. Hierarchical Columns

The 11g Release of Oracle Business Intelligence allows you to dragand drop logical dimensions from the business model into presentationlayer subject areas, to create hierarchical columns. These columns aremade up of presentation layers, and when included in an analysis,allows the user to perform in-column drilling on their data set.Hierarchical columns can exist alongside regular dimension columns

(now called attribute columns) and measure columns. Figure 22 showsa hierarchical column being created from a logical column in thebusiness model.

Figure 21 : Creating a Hierarchical Column


23/31

When included in an analysis, the hierarchical column allows the userto drill into the hierarchy within the same column, coping with ragged,parent-child and skip-level members without problems, as shown inFigure 23.

Figure 22 : Displaying a Hierarchical Column in an Analysis

As shown in the previous item regarding ragged hierarchies, thesehierarchical columns can implement all, or a subset, of the logicallevels in their related logical dimension, and each hierarchical columnrepresents a single hierarchy, so that two are created for examplewhen a logical dimension with two hierarchies is dragged into apresentation layer subject area.


24/31

3. Lookup Tables

Whilst most lookup data will be referenced in a semantic model byextending logical table sources to reference associated data, in somecases developers may wish to import the metadata for standalone,

lookup tables that may, or may not, contain lookup values for aparticular dimension member.

Figure 23 : Defining a Logical Lookup Table

Typical scenarios where this may be useful, include:

- Currency conversions that you wish to perform as a separate,standalone calculation

- accessing datatypes such as CLOBs that cannot be included ina

GROUP BY

clause

- avoiding the mandatory including of joins and tables in an SQL queryrelating to a logical table source that uses an outer join

The 11g release of Oracle Business Intelligence allows developers toeither reference lookup data in a physical table, through a logical tablesource mapping, through a new LOOKUP function, or to define a

logical table as being a lookup table and again reference it throughthe new LOOKUP function. In both cases, the lookup can be specified

as being either DENSE (where there will always be a corresponding

lookup value for a dimension member), or SPARSE (where values

may not be present, analogous to a left outer joinin SQL).

The syntax for SPARSE and DENSE LOOKUPs is asfollows:

Lookup(DENSE ,

)


25/31

Lookup(SPARSE , ,

)

When a physical table is referenced through the LOOKUP function,the BI Server will generally push the inner or outer join required toaccess it into the general SQL statement used for the query. Forlogical tables accessed via a Lookup function, the BI Server willgenerate a separate SQL statement for the lookup, which it will joinback to the main data set using an in-memory join.

To create a lookup involving a physical table, first import the physicaltables metadata into the physical layer for the semantic model,ensuring that you define a primary key for the table. Then, extend therelevant logical table source to include an entry for the new lookup

column. Finally, using the new LOOKUP function, use it to referencethe lookup column, using a function call such as:

Lookup(DENSE"orcl".""."GCBC_SALES"."Lkp_SEASONS"."SEASON_DESC","orcl".""."GCBC_SALES"."Dim_TIMES"."MONTH_YYYYMM" )

where SEASON_DESC is the column being looked up, and

MONTH_YYYYMM is the column in the logical table that corresponds

to the key of the lookup table.

To define a logical table as being a lookup table, tick the LookupTable tickbox (as shown in Figure 24, above) to define it as such in thebusiness model. It will then pass repository consistency checks eventhough it does not have a logical join to a fact table, and you canreference it using the regular Lookup function syntax.


26/31

4. ID and Descriptive Double Columns

Another new feature introduced with OBIEE 11g is the ability toassociate ID columns with descriptive columns in the repository, so thatfilters applied to analyses can use these IDs. This is useful, for

example, when you wish to display product descriptions as text, butfilter on the ID, and is also useful when you wish to create multiplelogical columns containing translations but filter on a common IDcolumn.

To define this feature, called Double Columns in the OBIEEdocumentation, edit the properties of the descriptive column in therepository and use the Descriptor ID setting to select the associatedID column, as shown in Figure 25 below.

Figure 24 : Setting an ID Column for a Descriptive Column

To make use of the new ID column, create a dashboard prompt asnormal, and you will see the ID column listed as the Included CodeColumn under the Prompt For Column setting, as shown in Figure 26below.


27/31

Figure 25 : Creating a Dashboard Prompt using Double Columns


28/31

The Enable user to select by Code Column tickbox then allows theuser to optionally display the code alongside the descriptions whenusing the dashboard prompt. Figure 27 shows a typical dashboardprompt where the user has chosen to display the IDs (this is optional,

and the feature still works without the ID being displayed).

Figure 26 : Displaying the ID along with Description in a Dashboard Prompt

To make use of the double column, create the analysis as normal using

the Is Prompted filter, and create the filter against the descriptioncolumn as normal, as shown in Figure 28 below.


29/31

Figure 27 : Filtering Against the Descriptive Column

Then, when a column is defined as having an associated column,regardless of whether the user chose to display the ID valuesalongside the descriptive values in the dashboard prompt, the SQLissued by the BI Server will still filter against the ID values only.

5. Logical Table Source Priority Group Ordering

When a situation arises where more than one logical table sourcecould provide data for a logical column, the source that is chosen is

typically determined by the level in the logical dimension that thesource is mapped in at, so that for example, a logical table sourcemapping to aggregated data is chosen in preference to a detail-levelone when a analysis involves aggregation. In circumstances wherethere are multiple source mapped in that refer to aggregated data, theNumber of Elements at This Level value is considered, for eachapplicable dimension, to determine which source is used.

As it can sometimes be unclear which source will be used in thesecircumstances, the 11g release of Oracle Business Intelligenceintroduces a feature called priority group order that allows thedeveloper to explicitely prioritise data sources in this situation. Thissetting is then generally the favoured determinant in selecting a logical


30/31

table source for a logical column. Figure 29 shows this setting, with anaggregate logical table source initially being set to Priority Group 0

(so that it is considered as high priority as the detail-level logical tablesource, and therefore used), and then being set to 1 (making it

lower priority than the detail-level source, leading to it not beingused even though otherwise it would qualify)

Figure 28 : LTS Priority Group Settings, and affect on Generate SQL

6. Changes to Repository Handling and Maintenance

The final major change to data modelling with Oracle BusinessIntelligence 11g is in handling of the actual RPD file. As users and

groups are no longer stored in the repository (instead, moving to in thecurrent release the WebLogic server), there is now no mandatoryAdministrator account with an Administrator group. So that repositoryfiles can still be opened offline, securely, RPD files now are encryptedand have a repository password, which can be set using the BIAdministration tool menu.

In addition, Oracle Fusion Middleware Control is now used to takerepositories online, rather than the developer editing by hand theNQSConfig.INI file, as shown in Figure 30 below.


31/31

When a new repository needs to be taken online, Fusion MiddlewareControl is used to browse to the required RPD file, and then thesechanges are activated which in turn moves a copy of the file to the

relevant instance directory, and updates the NQSConfig.INI file. Afterthis file has been applied, the Restart to apply recent changes button ispressed which then gives the developer the option to restart allservices, or just the BI Server, so that the changes in the configurationfile are then made active.

Summary

There are a number of good practices that apply when working with Oracle

Business Intelligence data modeling, including working with data stored in adata warehouse, building the business model using business terminology andlogic and to a dimensional model.

Date post:	08-Aug-2018
Category:	Documents
Upload:	naresh-ch
View:	217 times
Download:	0 times

BMM Layer New Features-OBIEE11g

Documents