Mini dimensions and "single dimension" query

Hi everyone,
I thought it is about time to bother you with a question. :)
I have a question about mini dimensions. In BI Apps mini dimensions are used within the dimensions like the Service Request Dimension. This dimension has two logical table sources: W_SRVREQ_D and W_SRVREQ_MD. Each logical table has a separate physical join on the fact table, i.e. the fact tables has a separate foreign key for each table.
The Service Request hierarchy is built up by the following levels: All > SR Attributes > Service Request Detail. The mini-dimension table W_SRVREQ_MD is set on logical level "SR attributes" and W_SRVREQ_D is on logical level "SR Detail".
"Status" is a column which is mapped to both tables and this column is on logical level SR Attributes. When I use Status and a measure from the fact table, the BI Server will hit the mini-dimension, because it is on a higher logical level. So far, so good.
But when I create a request which only contains the column Status, the BI Server chooses the more detailed dimension table W_SRVREQ_D, instead of W_SRVREQ_MD. I'm a suprised by this, because I would expect the BI Server to use the mini dimension table.
This can be a performance problem when a user wants to see all values from a column, for example when creating a filter. I know I can solve this with caching the dimension values, but hey.. you don't use mini dimensions for nothing! ;)
Adding an implict fact doesn't solve the problem. The implicit fact is only used when you combine multiple columns from different dimensions. I've also checked the number of elements per level, but these are also set correctly.
For now I don't see a solution to change this behaviour. Can anyone confirm and explain this behaviour? Does anyone have an idea how to force the BI Server to use the mini dimension table on a "single dimension" query? Thanks!
Regards,
Stijn

Stijn,
Did you ever get an answer to this?
In addition to the scenario that you mentioned (report on Status alone) another common case is a dashboard prompt that has a drop down list box for Status. I would hope that the BI server would choose the mini-dimension instead of a distinct query on the primary dimension (service request).
A possible solution is to add an LTS of a List of values table (LOV) that filters out only the statuses, but the problem there is that a query will result in LOV values that are not in use, whereas if the mini-dimension were used it would only result in actual statuses.
Thanks,
David

Similar Messages

Time Dimensions and Logical dimension "..that not join to any fact source"

Hi Guys,
I get the following error on the ANSWERS front end:
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14026] Unable to navigate requested expression: ToDate(SPECIFICG:[DAggr(RFACT.SPECIFIC [ ] by [ EFact.NO [ ] , Year.ID [ ] ] )], [Level Years]). Please fix the metadata consistency warnings. (HY000)
SQL Issued: SELECT EFact.NO saw_0, Fact.YTD_E saw_1, EFact.MTD_E saw_2 FROM "E#1" ORDER BY saw_0
The consistency manager shows no errors and the tables are physically joined up via foreign key i.e.
fact year monthday
data - date - date
year month
day
[see screen print|www.metallon.org/test/foreign.jpg]
I would be thankfull for any suggestions!

Hello wildmight.
I followed this tutorial:
http://www.rittmanmead.com/2007/04/30/obi-ee-time-dimensions-and-time-series-calculations/
Why should this layout not work?
Do you have a better idea?
When you say "it has to be one table" do you mean
that quartermonthday and year need to be ONE?
I just rememered that Oracle Hyperion Planning has to have
time and months seperated.
Hello mod100.
What do you mean hierachy over the time dimension?
Is it not obvious from the screen print that I have a hierachy
i.e. yeartotal - years and
quarters - months- days.
I read that by default the LEVELS are set to the lowerst. so thats fine. I set them by myself to the lowest as well but the ERROR is still the same.
no, I have not set the levels as in
http://obiee-tips.blogspot.com/2009/10/logical-levels.html

Dimension Design - Single Dimension with Multiple Hierarchies

Morning,
the purpose of this discussion is to understand how we should design a specific dimension with 3 levels and multiple hierarchies for optimal performance.
We have an institution dimension with the following characteristics:
Characteristics
Dimension: Institution
Levels:
1. Total Bank (TB) Level
2. Peer Group (PG) Level
3. Institution Level
Hierarchies:
1. Some of the hierarchies have 3 levels and others have only 2 levels (Skip Level)
2. ALL the hierarchies have a TB level and an Institution level
3. None of the hierarchies have the same leafs
4. Some of the hierarchies leafs can overlap
Design:
We are considering two approaches for the institution dimension levels:
a)
Levels:
Hierarchy 1 TB Level
Hierarchy 1 PG Level
Hierarchy 1 Inst Level
Hierarchy 2 TB Level
Hierarchy 2 Inst Level
Hierarchy 3 TB Level
Hierarchy 3 Inst Level
Note:
This approach is working and the resulting dimension and cubes are used by OBIEE, but some of the OBIEE analysis takes a long time (more than a minute) to return the results.
At this point, we are not sure whether this approach will result in an optimal design from a performance perspective and are looking at restructuring the dimension to represent only the three conceptual levels as indicated below.
b)
Levels:
1. Total Bank (TB) Level
2. Peer Group (PG) Level
3. Institution Level
The rest of the dimension i.e. hierarchies, attributes and mappings are defined in the same way.
The cube associated with this dimension have approximately 80 million records.
Please advise on any best practices or design considerations that we need to take into account.
Thanks

No, it is not possible to have multiple hiearchies in a PC logical dimension.
The concept of the Parent-Child (PC) hierarchy is completely different from the level-based hierarchy. Specifically the PC hierarchy expects a predefined / architected table with corresponding PC column/value structuring with or without attributes.
Short story even shorter it is not possible.
Longer...
In the RPD the BMM actually prevents you from adding a new logical level, child level, or parent level when you have selected that the logical dimension be a parent child logical dimension with Parent-Child hierarchy.
On another note...
Have you tried architecting/building your PC source table so that it represents the roll-up and bottom child-levels like you are seeking? That is, that same member in the child column more than once having a separate parent value. That should be doable.
That was a great question, please award points if this answered your question or it was helpful.
Cheers,
Christian
http://www.artofbi.com

Simple Design Analysis Question before designing dimensions and facts

Hi I have a simple question ... (I think its simple)
Suppose that i have the following staging table with the following columns:
Student_Name | RollNo | Test_Date | Subject-Taken
with data such as
Kevin |123|12-4-2010|Physics
now suppose that I want to design a cube on the basis of the above table so that I can succesfully get the result of a query such as
List the names of all those students who took the test b/w 12-4-2010 to 12-5-2010 of the Subject Physics
Here what i need to know what dimensions/Levels would u set and what would be our fact?
I think that one dimension would be time ( but i am not sure how i would accommodate and handle duration... any idea )
would it be wise to make each column a dimension ??? for example the student_nanme a dimension and details of the student its attributes??
Anyways the main thing is what bothers me is looking at the query we see that we are required 3 things the name of the student , the TestDate and subject taken so if i make the 3 columns the dimension i am still not sure that i would be able to acomodate the query properly...any ideas on how to approach and handle these situations
Edited by: Johnacandy on Dec 14, 2010 9:26 AM

ScoobySi wrote:
Yes I mean Time dimension, however in a DW you will have many Time dimensions, instead of creating a physical object for each you use a ROLE. If you edit a dimension in OWB you'll see that you can specify a ROLE on the first tab.
Thanks for the great explaination... could you explain the process of roles a little more that will really save me some time... furthermore u stated
+ "instead of creating a physical object for each you use a ROLE" +
The way i create dimensions is right clicking dimensions and selecting dimension.... for a standard dimension
however incase of a time dimension i use a wizard... I am still a bit confused about "Physical objects" ... Id really really appreciated it if you can clarify this up...
as discussed before one dimension would be Student and other would be subject
and 3rd one would be TEST_DATE with role ?? and should that be a time_dimension or a standard dimension with a role defined ???

Driver dimension and data load dim

Hello ,
Can anyone explain the difference between Driver dimension and normal dimension..(data load dimension)
Thank You!!!

Hi,
Driver dimensions are the varying column dimensions that reside in the data table or file (i.e. columns such as customer, product, date etc.). Single default members from other dimensions are fixed in the POV during data load (i.e. Actual scenario is usually fixed when loading actual data).
Cheers,
Alp

Dimensions and creation of Demension ID

I have a lot of experience with OWB and today I noticed with the new Release 2 - that when you create multiple levels and hierarchies that the Dimension ID if a negative number - is this what others are seeing?
I also notice with the Surrogate Key I create for the Dim and it is populated but I do not use the SK Operator?

This is correct. OWB creates positive dimension keys for every member of the lowest level of your dimension and negative dimension keys for every level above the lowest level. Only the record with a positive dimension key are referenced in the cubes.
Regards,
Jörg

Setting Evaluation order and Reordering dimension

hi i was going through the hp admin pdf and i have a few doubts
what do you mean by setting the evaluation option in planning means and why is it reccomended to select only one dimension(setting evaluation order)
in "About Reordering Dimensions" topic it was mentioned about the ordering of aggregating sparse dimensions before non aggregatin ones , what are these two types and also it was said to arrange the sparse dimensions in the order of more sparse members to less sparse members but isnt it the opposite way around i mean as per the hour glass model the order should be from least sparse to most sparse dimension and attribute dimension in the end
what exactly is the diffrence in Setting Evaluation Order and Reordering dimensions ?

Reording the dimensions sets the order of the dimensions in essbase, reordering the dimensions can be part of optimizing the database.
Setting the evaluation order is more to do with how the dimensions are evaluated in forms, so if account is set to be first then the properties of the account members data type will be used first, for instance if the account member is set to Percentage then member will be displayed as a percentage.
Cheers
John
http://john-goodwin.blogspot.com/

Cubes - how to extract a single dimension and save it in a table

Hi,
I am new to the cubes concept, although I've used it several times in the past to analyse the data but never explored options beyond that. using excel, I can get different dimentions from the cube such as customer information, location, etc.
is there a way to extract (automatically) a single dimension and save it in a table...? e.g I want to pull customer name and revenues only from the cube, how would I do it?
Thanks

Hi,
tparvaiz wrote:
Hi,
I am new to the cubes concept, although I've used it several times in the past to analyse the data but never explored options beyond that. using excel, I can get different dimentions from the cube such as customer information, location, etc.
is there a way to extract (automatically) a single dimension and save it in a table...? Sure, you can do that.
Say you had a table with many customers, and you were interested in only one of those customers: what would you do? You'd write a query with a WHERE clause that included only the customer you wanted to see.
A cube is a table with many dimensions. You're interested in only one of those dimensions, so what can you do? You can write a query with a WHERE clause to include only the dimension you want to see.
e.g I want to pull customer name and revenues only from the cube, how would I do it?Exactly how to do it depends on the table(s), your requirements and your Oracle version. As the others have said, post a little sample data (CREATE TABLE and INSERT statements to simulate what your real table looks like), and the results you want from that data.
Always say which version of Oracle you're using (e.g. 11.2.0.2.0).
See the forum FAQ {message:id=9360002}

How to display single dimension members in Columns and rows

Item category on rows Item brand on columns, Different levels in the Item hierarchy , can it be presented as above in the pivot table ?
I have Item dimension with the below hierarchy :
Item
|- All Items
|-- CAT-Beauty Products
| |-- SEG-Skin Care
| |-- BD-Andes
| -- CAT-Beverages
| |-- SEG-Bottled Water
| |--BD-Agua Vide
| -- CAT-Grocery
| |-- SEG-Meats
| |- BD-Harris
I need to display All 'CAT' elements in rows and all its children (SEG and BD elements) in columns in a pivot table.
Could you please help me to form the MDX query to display the data in ADF Pivot table.
Sample query that I used:
SELECT
{[Item].[CAT-Beauty Products].Siblings}
ON COLUMNS,
{[CAT-Beauty Products].members}
ON ROWS
FROM Vcp_Tu1.Supply
This is giving the below error message:
Statement Executed with Warnings.
Repeated dimension [Item] in MDX Query
Unexpected Essbase error 1200549
Edited by: Swathi on Jun 7, 2011 11:42 PM

Sorry you can't do that. as a work around you could create attribute dimensions for the parent and the could cposstab them, or split the dim into two dimensions

How to Get the min,max and original values in a single query

Hi,
I have a task where in i have to the min , max and the original values of a data set .
I have the data like below and i want the target as well as mentioned below
SOURCE
DATASOURCE
INTEGRATIONID
SLOT_DATE
SLOT1
SLOT2
SLOT3
SLOT4
SLOT5
SLOT6
SLOT7
SLOT8
SLOT9
SLOT10
1
101
201111
100
100
200
100
100
100
300
300
300
300
1
101
2011112
200
200
200
200
100
100
100
100
200
300
TARGET
DATASOURCE
INTEGRATIONID
SLOT_DATE
SLOT_VALUE
SLOT MIN
SLOT_MAX
SLOT NUMBER
1
101
201111
100
1
2
SLOT1
1
101
201111
100
1
2
SLOT2
1
101
201111
200
3
3
SLOT3
1
101
201111
100
4
6
SLOT4
1
101
201111
100
4
6
SLOT5
1
101
201111
100
4
6
SLOT6
1
101
201111
300
7
10
SLOT7
1
101
201111
300
7
10
SLOT8
1
101
201111
300
7
10
SLOT9
1
101
201111
300
7
10
SLOT10
1
101
2011112
200
1
4
SLOT1
1
101
2011112
200
1
4
SLOT2
1
101
2011112
200
1
4
SLOT3
1
101
2011112
200
1
4
SLOT4
1
101
2011112
100
5
8
SLOT5
1
101
2011112
100
5
8
SLOT6
1
101
2011112
100
5
8
SLOT7
1
101
2011112
100
5
8
SLOT8
1
101
2011112
200
9
9
SLOT9
1
101
2011112
300
10
10
SLOT10
e
so basically i would first denormalize the data using the pivot column and then use min and max to get the slot_start and slot_end.
But then i
can get the min and max ... but not the orignal values as well.
Any thoughts would be appreciated.
Thanks

If you want to end up with one row per slot per datasource etc, and you want the min and max slots that have the same value as the current slot, then you probably need to be using analytic functions, like:
with t as
(SELECT 1 datasource,101    INTEGRATIONID, 201111     slotdate, 100    SLOT1, 100        SLOT2,    200    slot3, 100    slot4, 100    slot5, 100    slot6, 300    slot7, 300    slot8, 300    slot9, 300 slot10 FROM DUAL union all
SELECT 1,    101,    2011112,    200,    200,    200,    200,    100,    100,    100,    100,    200,    300 FROM DUAL),
UNPIVOTED AS
(SELECT DATASOURCE,INTEGRATIONID,SLOTDATE,1 SLOT,SLOT1 SLOT_VALUE
FROM T
UNION ALL
SELECT DATASOURCE,INTEGRATIONID,SLOTDATE,2 SLOT,SLOT2
FROM T
UNION ALL
SELECT DATASOURCE,INTEGRATIONID,SLOTDATE,3 SLOT,SLOT3
FROM T
UNION ALL
SELECT DATASOURCE,INTEGRATIONID,SLOTDATE,4 SLOT,SLOT4
FROM T
UNION ALL
SELECT DATASOURCE,INTEGRATIONID,SLOTDATE,5 SLOT,SLOT5
FROM T
UNION ALL
SELECT DATASOURCE,INTEGRATIONID,SLOTDATE,6 SLOT,SLOT6
FROM T
UNION ALL
SELECT DATASOURCE,INTEGRATIONID,SLOTDATE,7 SLOT,SLOT7
FROM T
UNION ALL
SELECT DATASOURCE,INTEGRATIONID,SLOTDATE,8 SLOT,SLOT8
FROM T
UNION ALL
SELECT DATASOURCE,INTEGRATIONID,SLOTDATE,9 SLOT,SLOT9
FROM T
UNION ALL
SELECT DATASOURCE,INTEGRATIONID,SLOTDATE,10 SLOT,SLOT10
FROM T)
select DATASOURCE,INTEGRATIONID,SLOTDATE,slot,slot_value,min(slot) OVER (partition by datasource,integrationid,slotdate,rn) minslot,
    max(slot) OVER (partition by datasource,integrationid,slotdate,rn) maxslot
FROM
select DATASOURCE,INTEGRATIONID,SLOTDATE,max(rn) over (partition by datasource,integrationid,slotdate order by slot) rn,slot,slot_value
FROM
    (SELECT DATASOURCE,INTEGRATIONID,SLOTDATE,slot,slot_value,
          case when row_number() over (partition by datasource,integrationid,slotdate order by slot) = 1 or
          lag(slot_value) over (partition by datasource,integrationid,slotdate order by slot) <> slot_value
              then row_number() over (partition by datasource,integrationid,slotdate order by slot)
              ELSE null
              END rn
    from unpivoted
order by DATASOURCE,INTEGRATIONID,SLOTDATE,slot

Possible to limit dimensions and measures when creating presentations?

We are trying to use OLAP/BI Beans to add BI functionality to our next-generation data warehouse application. This application has its own security framework, with the ability to define permissions/privileges for objects. We need to integrate BI Beans/OLAP with this security framework.
One of the things we need to do is control which OLAP objects (like dimensions and measures) are available to a given user in the Items tab when creating a presentation. For example, user A might see dimensions Alpha, Bravo and measure Charlie, while user B might see dimensions Delta, Echo and measure Foxtrot.
We need to be able to apply these dimension/measure restrictions without using different Oracle users, with each having access only to their own OLAP objects. Our data warehousing application does not use Oracle and Oracle users to control security; it has its own internal frameworks for privileges/permissions. We therefore need to find a way to restrict access to OLAP objects in some programmatic way.
Here's an example of how this might work:
- I am a clinical analyst. I sign on to the data warehouse application. The data warehouse knows that as a clinical analyst, I have access to a certain list of objects and functionality across the application. One of the apps I have privilege to is the BI Bean Presentation Creation Application, so I click the menu to bring this up. I can now create BI presentations, but since I am a clinical analyst my list of available dimensions and measures do not contain any of the G/L, payroll or other financial OLAP objects.
- If I signed onto the data warehousing application as a different user, one that has a financial analyst role, I might see a different set of OLAP objects when I run the presentation application application.
So what we need is some API way to specify which dimensions and measures are available to a given user when they launch the presentation wizard. I've been digging through the BI Beans help and javadoc and have found a few things, but they aren't what I need.
Here's what I found:
- setItemSearchPath: this allows you to specify which folders are to be displayed. We want control at the OLAP object level, not at the folder level, so this doesn't work for us
- setVisibleDimensions: this controls which dimensions are available in the Dimensions tab, not which dimensions can be selected in the Items tab. Doesn't work for us
- setDimensionContext/setMeasureContext: These might work for us but I haven't been able to get them to retrieve anything yet. It also seems to me that these might set which dimensions/members are initially selected in the Items tab, not the list of dims/measures that are available for selection.
Any assistance on this matter would be greatly appreciated.
s.l.

Reply from one of our developers:
The get/setMeasureContext and get/setDimensionContext methods are currently only used by the Thick CalcBuilder (in a few limited scenarios) and cannot be used "to scope the dimensions and measures listed in Query and Calc builder based on user access rights".
The scoping of dimensions and measures based on user access rights should be performed at the MetadataManager/Database level.
This may change going forward as the real issue here is the static nature of the metadata and a general issue with the GRANT option within the database. So from the database perspective it is not possible to grant select priviledges on a single column of a table.
The metadata issue is more complex as the OLAP API reads the metadata only once on startup of a session. The list of available measures is based on the GRANT priviledge, so for relational OLAP this limits the data scoping capabilities. In 10g, the metadata for AW OLAP becomes more dynamic and contained and read directly from the AW. Therefore, with an AW OLAP implementation with 10g it could be possible to scope boht dimensions and measures quickly and easily.
Hope this helps
Business Intelligence Beans Product Management Team
Oracle Corporation

Having more LTSs in logical dimension table hit the query performance?

Hi,
We have a logical table having around 19 LTSs. Having more LTSs in logical dimension table hit the query performance?
Thanks,
Anilesh

Hi Anilesh,
Its kind of both YES and NO. Here is why...
NO:
LTS are supposed to give BI Server an optimistic and logical way to retrieve the data. So, having more Optimistic LTS might help the BI Server with some good options tailored to a variety of analysis requests.
YES:
Many times, we have to bring in multiple physical tables as a part of single LTS (Mostly when the physical model is a snowflake) which might cause performance issues. Say there is a LTS with two tables "A" and "B", but for a ad-hoc analysis just on columns in "A", the query would still include the join with table "B" if this LTS is being used. We might want to avoid this kind of situations with multiple LTS each for a table and one for both of them.
Hope this helps.
Thank you,
Dhar

Foreign keys in SCD2 dimensions and fact tables in data warehouse

Hello.
I have datawarehouse in snowflake schema. All dimensions are SCD2, the columns are like that:
ID (PK) SID NAME ... START_DATE END_DATE IS_ACTUAL
1 1 XXX 01.01.2000 01.01.2002 0
2 1 YYX 02.01.2002 01.01.2004 1
3 2 SYX 02.01.2002 1
4 3 AYX 02.01.2002 01.01.2004 0
5 3 YYZ 02.01.2004 1
On this table there are relations from other dimension and fact table.
Need I create foreign keys for relation?
And if I do, on what columns? SID (serial ID) is not unique. If I create on ID, I have to get SID and actual row in any query.

>
I have datawarehouse in snowflake schema. All dimensions are SCD2, the columns are like that:
ID (PK) SID NAME ... START_DATE END_DATE IS_ACTUAL
1 1 XXX 01.01.2000 01.01.2002 0
2 1 YYX 02.01.2002 01.01.2004 1
3 2 SYX 02.01.2002 1
4 3 AYX 02.01.2002 01.01.2004 0
5 3 YYZ 02.01.2004 1
On this table there are relations from other dimension and fact table.
Need I create foreign keys for relation?
>
Are you still designing your system? Why did you choose NOT to use a Star schema? Star schema's are simpler and have some performance benefits over snowflakes. Although there may be some data redundancy that is usually not an issue for data warehouse systems since any DML is usually well-managed and normalization is often sacrificed for better performance.
Only YOU can determine what foreign keys you need. Generally you will create foreign keys between any child table and its parent table and those need to be created on a primary key or unique key value.
>
And if I do, on what columns? SID (serial ID) is not unique. If I create on ID, I have to get SID and actual row in any query.
>
I have no idea what that means. There isn't any way to tell from just the DDL for one dimension table that you provided.
It is not clear if you are saying that your fact table will have a direct relationship to the star-flake dimension tables or only link to them through the top-level dimensions.
Some types of snowflakes do nothing more than normalize a dimension table to eliminate redundancy. For those types the dimension table is, in a sense, a 'mini' fact table and the other normalized tables become its children. The fact table only has a relation to the main dimension table; any data needed from the dimensions 'child' tables is obtained by joining them to their 'parent'.
Other snowflake types have the main fact table having relations to one or more of the dimensions 'child' tables. That complicates the maintenance of the fact table since any change to the dimension 'child' table impacts the fact table also. It is not recommended to use that type of snowflake.
See the 'Snowflake Schemas' section of the Data Warehousing Guide
http://docs.oracle.com/cd/B28359_01/server.111/b28313/schemas.htm
>
Snowflake Schemas
The snowflake schema is a more complex data warehouse model than a star schema, and is a type of star schema. It is called a snowflake schema because the diagram of the schema resembles a snowflake.
Snowflake schemas normalize dimensions to eliminate redundancy. That is, the dimension data has been grouped into multiple tables instead of one large table. For example, a product dimension table in a star schema might be normalized into a products table, a product_category table, and a product_manufacturer table in a snowflake schema. While this saves space, it increases the number of dimension tables and requires more foreign key joins. The result is more complex queries and reduced query performance. Figure 19-3 presents a graphical representation of a snowflake schema.

Multiple hierarchies single dimension single report

I am trying to add multiple hierarchies from a single dimension in a single report. To create the hierarchy in BI admin I followed the instructions found here
Oracle BI EE 10.1.3.3/2 &#8211; One Dimension &#8211; Multiple Hierarchies &laquo; Business Intelligence &am…
and here
https://forums.oracle.com/thread/2440305
My Patient hierarchy looks like the this
All Patients->Gender->Patient ID
All Patients->Age Group->Patient ID
When I drag and drop the second hierarchy in the Criteria Oracle BI Answers says the following "...you can only add one hierarchy per dimension to a report". I deduct that what I am trying to do is not possible!:-)
Q1: Is this feature indeed not supported or am I doing something wrong?
Q2: If this is not supported can someone explain why?
Version Oracle Business Intelligence 11.1.1.6.0

a) Reporting across levels of 2 hierarchies is not supported. As explained below, you cannot use OLAP to get aggregate values at cross combination of levels from hierarchies: H1 and H2.
However if you wish to, you can report at the lowest level, Patient, common to both hierarchies and display the Age Group as well as Gender attributes corresponding to each patient. This becomes reporting at Patient/lowest level. You can of course use the capabilities of the reporting tool like obiee to use a Pivot object (say) and exclude Patient columns like Id, name etc. and get obiee to perform localized summaries within the reporting layer and get summarizations of interest. OBIEE Pivot measures allow for aggregation using Min, Max, Sum, Count, Running Sum etc. OLAP facilitates this solution but does not particularly help in the aggregation (since aggregation is now being done in obiee and not as per cube definition rules in olap aw). It acts as a source for information at the lowest level stored in the cube. Some performance degradation would result but it may be acceptable/manageable depending on the data volumes/report criteria.
NOTE: For workaround/solution, use the regular fields, not hierarchical columns, from OBIEE presentation layer.
b) Not supported: OLAP Cubes contain pre-calculated (or dynamically calculated) summaries at various level of each hierarchy. This aids in faster reporting performance. Allowing 2 hierarchies at the same time defeats this feature/goal. A cross combination of levels across different hierarchies requires a dynamic recalculation of the detail records to get the right values for, say, Age Group: 30-39 and Gender: Male. H1 summaries at AgeGroup level for Age Group: 30-39 cover all genders and cannot be split up into male/female w/o recalculation. Similarly H2 summaries at Gender level for Gender: Male cover all age groups. Splitting it up is not possible except via workaround/ solution explained in (a).
Hope that helps.

Degenerate and Junk dimensions

I am new to SSAS. I want to understand degenerate and junk dimensions in detail. It would be good if you provide with practical examples please.
Regards,
Ramu
Ramu Gade

Junk Dimensions
There are certain scenarios where you will find that the source for a fact table contains a bunch of low-cardinality attributes that don’t really relate to any of the other attributes describing these facts. Some of the more common examples are bit/character
based “flags” or “codes” which are useful to the end users for filtering and aggregating the facts. For example, imagine a user who wants to analyze orders from the order fact table that are flagged as “reprocessed”…they can either filter for facts with
the reprocessed flag if they are only interested in that subset…or they can group by the “reprocessed” flag calculate things like the percent of orders that are “reprocessed”…
Instead of building a separate dimension for each of these individual attributes, another option is to combine them and build what’s known as a Junk Dimension based on the Cartesian product of each of these attributes and they’re corresponding range of values.
This technique does 2 important things:
Saves Disk Space
consider a single 4byte integer key linking to the junk dimension vs. a handful of 4byte integer keys each linking to a separate dimension. Might not sound like a lot on a per-record basis, but once you extrapolate out over a 100mm record fact table the
savings really adds up.
Improves End-User Experience
By keeping the total number of dimensions down to a manageable size it will be easier for your end-users to find the attributes they’re looking for during ad-hoc analysis. Kimball recommends <= 26 dimensions per fact table – of course there are always a
few edge-case exceptions.
Degenerate Dimensions
The Degenerate Dimension is another modeling technique for attributes found in the source transaction table. The main differences between these attributes and the ones that would fall into our Junk Dimension are as follows:
Cardinality
these are typically high-cardinality attributes – in some cases having a 1 to 1 relationship with the fact. These are likely to be the business keys of the fact table such as Purchase Order Number, Work Order Number, etc. Another potential candidate
for the degenerate dimension is free-form comment fields.
Use Case for End-Users
these attributes are not going to be used for filtering/aggregating facts. Instead, these are the types of attributes that are typically going to be used in drilldown or data mining scenarios (ex. Market Basket Analysis). For example, imagine a user who is
analyzing purchase orders in the “delayed” status. After drilling down on the delayed POs for a certain supplier in a certain time period…the next step might be to pick up the Purchase Order Number which would allow this user to trace this small subset of
PO’s back to the source system to find out why they are “delayed”.
Storage
Despite the name, these attributes typically remain in the fact table. There really isn’t much point in moving them out to an actual dimension – because of the high-cardinality there’s likely to be zero space savings…in fact it would probably cost you space
due to the additional surrogate-keys. You’ll also likely be paying a heavy price on the join at query time.
Analysis Services Implementation
For Junk Dimensions, you will create a new dimension at the project-level pointing it to the table (or view) in the data warehouse that materializes the distinct combinations of values for the various junk-attributes. After configuring the dimension at
the SSAS project-level, it can be added to the cube(s) and linked up to the measure group(s) via regular relationships (where appropriate).
For Degenerate Dimensions, the process is the same except you base the project-level dimension off of the fact table (or view). Once the project-level dimension is configured, it can be added to the cube(s) and linked up to the measure group(s) using “fact”-relationships
(where appropriate).
Please mark as Answer if this helps!
Rajasekhar.

Mini dimensions and "single dimension" query

Similar Messages

Maybe you are looking for