Degenerate Dimension

While performing modeling in BMM layer I am hitting an issue.
I have two fact tables Revenue and Charges. Both has Sales Order Number as common column (Sales Order Number) is available in both the fact tables.
Now I want to create a report across both the fact tables.
The approach I am taking is to first create common degenerate dimension from both the fact tables (Sales order Number column is mapped to both the fact tables.
But when I try to create a dimension hierarchy by right clicking on degenerate dimension it throws an error saying 'AdminTool is unable to created a structure for dimension'. I believe this is because Sales Order Number is not unique in any of the fact tables.
Desired model should be able to use Sales Order Number across both fact tables.
Thank you,
DP.
Edited by: BIDeveloper on Nov 22, 2010 4:53 PM

DP,
As you mentioned "Sales Order Number" as degenerate dimension it is confined to a fact table (a standard definition).
Thus dimensional hierarchy cannot be created on facts.
Mandatory conditions for creating a dimensional hierarchy:
1. The logical table cannot be a logical fact table.
2. The logical table on which a dimensional hierarchy is bieng created should not have a hierarchy already created.
mark posts promptly.
J
-bifacts
http://www.obinotes.com

Similar Messages

Logical Key for Degenerate Dimension

Hi Gurus,
Need some help on the degenerate dimensions in the BMM layer.
I have one fact table with dimension attributes and I would like to move the attributes into separate logical table and treat it as dimension.
Now my newly created dimension has the Fact LTS and I would like to assign a logical key to the newly created table and then create the logical dimension.
Can anyone provide some inputs on we can assign the logical key to the column?
Thanks

Hi Srini,
Since my main logical fact table consists of two LTS and the dimension being created from this table will also have 2 LTS, the content level will be set to all levels on which the fact is joined.
So I would like to create a logical dimension based out of my dimension and then assign the content level at the detail level.
Please let me know if I am not clear.
Thanks

SQL08 Need example of creating AND using a Fact (degenerate) dimension

Can someone post a link to some examples of setting up and using a Fact (degenerate) dimension. Ive got the SSAS 2008R2 Adventureworks DW project setup and I see a few Fact dimensions in there, but id like some descriptions to go along with this or
something similar.
My scenario:
Orders - attributes include : Order#, OrderStartDate, SalesPerson, BusinessType, MarketType
OrderTransactions - attributes include: OrderKey , TransactionAmount, TransactionType, TransactionDate, AccountKey
Description:
Its more or less the typical Order > Order Detail type scenario, with the addition of Orders have some additional attributes.
So I want to be able to measure on for example:
Order counts - broken down by BusinessType and MarketType , and then within a date range
Revenue - which will be totals of transaction amounts, again grouped by BusinessType and MarketType, but also be able to drill down to see the related Order#

Hi Shiftbit,
According to your description, you need some examples about create and use degenerate dimensions, right?
Degenerate dimensions, also called fact dimensions, are standard dimensions that are constructed from attribute columns in fact tables instead of from attribute columns in dimension tables. Here is document that describes how to create and use degenerate
dimensions step by step, please refer to the links below.
https://msdn.microsoft.com/en-us/library/ms167409(v=sql.100).aspx
http://www.jamesserra.com/archive/2011/11/degenerate-dimensions/
Regards,
Charlie Liao
TechNet Community Support

Error When Loading a Degenerate Dimension

Hi,
I have received the link > http://blogs.oracle.com/warehousebuilder/entry/owb_11gr2_degenerate_dimensions#comments
from you to create a degenerate dimesion .
I have create a DIM_DD_LOAN with two attribue loan_no_business with idenitifier business and a description then I deploy the table related to this dim is called DIL_DD_LOAN_TAB but I got this error
ORA-37162: OLAP error
XOQ-02102: cannot find object "BANK_STG.DIM_DD_LOAN"
XOQ-02106: invalid property "Dimension" with value "BANK_STG.DIM_DD_LOAN" for object "BANK_STG.CUBE_PAID_LOAN.DIM_DD_LOAN" in XML document
XOQ-02106: invalid property "ConsistentSolve" with value "SOLVE ( SUM OVER DIM_BANKS HIERARCHIES (STANDARD), SUM OVER DIM_BRANCHES HIERARCHIES (STANDARD), SUM OVER DIM_CUSTOMERS HIERARCHIES (STANDARD), SUM OVER DIM_REQUESTS HIERARCHIES (STANDARD), SUM OVER DIM_CURRENCIES HIERARCHIES (STANDARD), SUM OVER DIM_BONDS HIERARCHIES (STANDARD), SUM OVER DIM_COLLATERALLS HIERARCHIES (STANDARD), SUM OVER DIM_CONTRACTS HIERARCHIES (STANDARD), SUM OVER DIM_OWNERSHIPS HIERARCHIES (STANDARD), SUM OVER DIM_SEGMENTS HIERARCHIES (STANDARD), SUM OVER DIM_USAGE_CODES HIERARCHIES (STANDARD), SUM OVER DIM_LOAN_DIVISIONS HIERARCHIES (STANDARD), SUM OVER DIM_LOAN_PURPOSES HIERARCHIES (STANDARD), SUM OVER DIM_NOMINALS HIERARCHIES (STANDARD), SUM OVER DIM_LOCATIONS HIERARCHIES (STANDARD), SUM OVER DIM_DATES HIERARCHIES (STANDARD), SUM OVER DIM_DD_LOAN)" for object "BANK_STG.CUBE_PAID_LOAN" in XML document
XOQ-02005: The Dimension "BANK_STG.DIM_DD_LOAN" referenced from object "BANK_STG.CUBE_PAID_LOAN" is not found.
XOQ-02100: cannot parse server XML string
ORA-06512: at "SYS.DBMS_CUBE", line 433
ORA-06512: at "SYS.DBMS_CUBE", line 465
ORA-06512: at "SYS.DBMS_CUBE", line 523
ORA-06512: at "SYS.DBMS_CUBE", line 486
ORA-06512: at "SYS.DBMS_CUBE", line 475
ORA-06512: at "BANK_STG.OWB$XMLCLOB_TAT_BANK_STG_DW", line 513
ORA-06512: at line 3
can you help me??
REgards,
Sahar

The degenerate dimension best practice I mention in the blog will not work for cube MVs, the cube MV will expect a dimension defined in the AW for any dimension defined in the cube. So if you followed the blog post to the word, you did not deploy the dimension so when the cube is deployed it is looking for the dimension object (which does not exist). If you did deploy it, then you would have to maintain the dimension...and it would not be degenerate.

Reporting on Degenerate Dimension without using aggregation

Hi Gurus,
I have 2 fact tables F1 and F2 and a conformed dimension D. Both the fact tables contains degenerate dimensions.
So I have created degenerated dimesnion in BMM layer DDF1 and DDF2 corresponding to F1 and F2 resp.
I want to generate report using DDF1, DDF2 and D without using any column from F1 or F2(basically I dont need any aggregation in my reports, but more than 1 fact table is used).
But I receive error while trying to implement this. I have created the dimensions and defined content mappings for the fact tables.
I had followed the steps given at [http://www.rittmanmead.com/2010/01/oracle-bi-ee-10-1-3-4-1-modeling-degenerate-dimensions-fact-attributes/]
Does this type of reporting without using aggregation possible in OBIEE?
Thanks in advance.

If you want it in pivot view it is not possible for ad-hoc to give it to end-users without measure columns.
You can do this in table view for only dimension columns wihtout measures easily possible.
If you want the look of pivot and same as results of pivot in your table view then you follow this blog
http://gerardnico.com/wiki/dat/obiee/table_to_pivot
UPDATE POST
the rittman blog mentioned follow that properly every step is given correctly,according to me your doing mistake at degenerate dimensions or conformed dimensions...that is why the error is throwing on the fact column that you are using.Please setup once again each and every step correctly you will achieve it.
Cheers,
KK
Edited by: Kranthi on Feb 8, 2011 3:06 AM

Loading a degenerate dimension

Hi,
I have source data which is used to load both a SCD2 dimension and fact table. Since, the dimension is derived from the fact data and is not a measure we can call it as a degenerate dimension.
Ex:
Source Row -- A,B,C,D,E
Fact data - A,B,C
Degenerate dimension data - D,E
I have to load the SCD2 degenerate dimension with D,E and maintain the dimension surrogate in Fact table.
So,
Degenerate dimension - 111,D,E
Fact - 201 ,A,B,C,111
111 is the dimension surrogate
201 is the fact sequence no.
How do i identify A,B,C,D,E belong to a single row in the source data , so that i can maintain the dimension surrogate key with Fact records.
Is there a way OWB 10g R2 can handle this, or we have to join the dimension row with the source row based on D,E and get 111,A,B,C as output.
Any suggestion or document on how to load a degenerate dimension and fact would be highly appreciated ?
Thanks and Regards,
Chakri

Hi Chakri
Which version are you using? With pre 11gR2 you will probably have to load the cube using the (fact) table operator rather than the cube operator.
Cheers
David

Oracle11g degenerate dimension usage

HI,
The context of my sales cube is as follows,
Dimensions: product,region,time
Degenerate dimension: order_number (which is huge list)
Measure: amount,quantity
Using oracle11g analytic workspace manager, I can create the dimension, measure and cube.
Will somebody please guide me to configure order_number dimension as degenerate dimension. This would be the dimension which reside in fact with no mapping to source and no aggregates across this dimension.
I should be able get results for queries like, " List all the order numbers for the product A under Region B and where quantity sold > 100K"
Plz ask for any clarifications..
Thanks in advance,
-- Vinay

Hi,
Refer this link:
http://books.google.co.in/books?id=VEGxVL2L0K0C&pg=PT62&lpg=PT62&dq=WhatisDegenerateDimensionandslowlychangingdimensionin+BW&source=bl&ots=1CyWv5TSRG&sig=07JISYkbaHUTSwmz4DH8tiH5HUE&hl=en&ei=9WYvS9fHG4-gkQWmkdCCBA&sa=X&oi=book_result&ct=result&resnum=9&ved=0CCEQ6AEwCA#v=onepage&q=What%20is%20Degenerate%20Dimension%20and%20slowly%20changing%20dimension%20in%20BW&f=false
It gives the contents of the book SAP BW certification: a business information warehouse study guide By Catherine M. Roze.
The contents give you an idea of all the types of dimensions like :
Degenerate
Partitioning
Categorical
Slowly changing
Reserved
Hope this helps.
Thanks,
Rahul

Storing degenerate dimension info in an OWB 10gR2 cube

Hi,
I'm looking to store "degenerate dimension" information in an OWB 10gR2 cube. Typically in a DW, I'd just add a column to the fact table to hold the information. However, in OWB 10gR2, I don't see any way to add a column to a "cube" object - everything appears to either have to be a dimension surrogate key, or a measure.
Not sure the best way to proceed. We've coded all our ETL using the standard cube objects and letting OWB do all the surrogate key lookup, etc. automagically for us, so I'd hate to be forced to go back to manually loading the fact tables. Is there an easier way?
Thanks,
Scott

Hi Scott,
The problems I've run into with dimensions and cubes are:
Dimensions abort if there are many roles - about 4 is the limit. This is very bad for the time dimension which should have 100s of aliases. Unfortunately I can't use the Time dimension wizard because we require ISO-Weeks. My workaround is to create several Time dimensions manually and assign 4 roles to each.
Naming - when I create several time dimensions with 4 roles each (see above), in the BI layer, the foreign keys in cubes are always named something like time_dim, time_dim_1, etc rather than named for role names. I have to manually rename them in tables and then when I deploy BI objects, manually rename them again in Discoverer Administrator.
Redeploying just about anything is broken. Table upgrade plans are invalid (even after running the grant scripts that support recommended), Redeploying BI objects runs successfully but if you read the job output, it does nothing since the objects already exist - again, the upgrade option does nothing.
Column ordering is random when deploying objects so I've taken to sorting alphabetically for our BI objects. Not ideal by any means.
As for the time savings with lookups, I don't save nearly that much. Due to many composite keys in our source systems, I assign surrogate keys in our staging area. These become the "business keys" in our DW layer and consequently I end up doing lookups against the staging MAP tables - really no more or less difficult than looking up dimension keys. That is more a design choice than anything and may just be my "Kimball" habits dying hard.
I'm encouraged to hear that you are having success. I chose to utilize the Dimensions and Cubes and so far am sticking with it. I'm hoping that there will be patches and/or point releases to OWB soon!

Limit rows for Degenerate dimension in SSAS 2012 Standard Edition

Hi Experts,
I have a fact table consisting of 4 measures and 6 descriptive fields. The Geography and Time dimension are separately palaced. I want to build SSAS cube on this schema.
I have created the dimension from fact table itself for the descriptive fields. The scenario is that we are not loading complete fact table in SSAS. Only recent 2 years out of 10 years is brought into SSAS. But the degenerate dimension is procssesing all
the rows from fact.
I want to limit the dimension processing to only recent two years of data. How will I be able to achieve this?
Please help me out of this.
Thanks,
RuchikaG

Use a view as the source for dimension. Inside that write logic to filter data from the fact for last two years.
ie like
WHERE dateField >= dateadd(yy,datediff,yy,0,getdate())-1,0)
AND dateField < dateadd(yy,datediff,yy,0,getdate()) + 1 ,0)
Then take distinct attributes from it for the dimension
Please Mark This As Answer if it solved your issue
Please Vote This As Helpful if it helps to solve your issue
Visakh
My Wiki User Page
My MSDN Page
My Personal Blog
My Facebook Page

Degenerate dimensions

Hello friends ,
I need some clarifications regarding the creations of the Degenerate Dimension(fact generated ) Creations in a Cube .
1. How many degenerate dimensions can we create on a SSAS Cube .What is the possible limit . can we have more than 150 degenerate dimensions in a SSAS Cube ..?
2. What are the drawbacks/disadvantages of a De Generate dimensions.?
3. if the degenerate dimensions is followed . what will be affect on the calculations as well performance wise.
Please help in these 2 points

Hi Rakesh,
Degenerate dimensions have same granularity as Fact Table. To be simple these types of dimensions are used to display the textual information to the client that resides in the Fact tables. This explains that getting any sort of information
from these dimensions (Browsing) is painfully slow.It is recommended to hide these dimensions from user and only use it in actions- Drillthrough (Or other). I am able to create only one Degenerate dimension per measure group.
Regards,
Venkata
Venkata Koppula

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.

Defining Dimensions, Attribute Hierarchies for a Link Table(Many to Many)

I have 3 Tables in the Database
Table 1: Transactions (Fact Table) - PK(TransactionId)
Table 2: Relationship (Dimension1) - PK(Relationship Id), FK_TransactionId, FK_CompanyId, RelationshipType
Table 3: Companies (Dimension 2) - PK(CompanyId)
Table 2: Relationship table is a link table between Transactions & Companies to facilitate many to many relationship.
I defined Fact and Dimension tables accordingly but having issues defining Dimension & Attributes for Relationship tables
Relationship Dimension:
I have 3 hierarchy groups defined
Hierarchy 1 - Relation -Relationship Type,Relationship Id(PK)
Hierarchy 2 - Transaction - Transaction, Relationship Id(PK)
Hiearchy 3 - Company - CompanyId, Relationship Id(PK)
Defined the attribute relationship in the following way
RelationshipID(PK) ---> CompanyId , RelationshipID(PK) ---> TransactionId, RelationshipID(PK)
---> RelationshipTYpe
I am getting incorrect results when I deploy the cube. Not all the types are being displayed only 4 types are being displayed out of 27 types though there exists Transactions for all the Types.
To fix the incorrect results, I tried to break the Relationship Dimension into 2 dimensions seperating Transaction(Relationship Dim) & Company,Type (Companies Dim). I tried to configure a many
to many Relationship type between my Companies Dim & Fact Table Transaction. But I get the error that says
"Companies Dim many to many dimension in the Tansaction measure group requires that the granularity of the Relationship dimension is lower than that of the Relationship measure group "
Any help regarding how to difine Dimensions & Attribute Hierarchies on a Many to many link table is appreciated.

Hi Jaya,
According to your description, you are experiencing the issue when implement many to many relationship by using a bridge table in your SQL Server Analysis Services project, right?
Generally, a bridge table will have a surrogate key for the dimension and a surrogate key to the fact table or a degenerate dimension based on the fact table. Here are some blogs which describe how to implement many to many relationship using a bridge
table.
http://bifuture.blogspot.com/2011/06/ssaskimball-modeling-nm-relation.html
http://www.sqlchick.com/entries/2012/1/22/data-modeling-tip-when-using-many-to-many-bridge-tables-in-s.html
http://social.technet.microsoft.com/wiki/contents/articles/22202.a-practical-example-of-how-to-handle-simple-many-to-many-relationships-in-power-pivotssas-tabular-models.aspx
Regards,
Charlie Liao
TechNet Community Support

Should I relate a fact table to a fact table to a dimension table?

Hi All,
I'm designing a dimensional data mart for a client and I'm now forced to think about many-to-many relationships, among other complexities I haven't dealt with until now. Said client needs to be able to analyze contracts, subcontracts, bids, and bidders.
Each contract and subcontract can have multiple bids. Each bidder can only submit a single bid for any single contract or subcontract. And each bidder can submit a bid for any number of contracts and subcontracts.
My initial plan is this: FactContracts, with FactContractKey, ContractID, SubContractID; FactBids, with FactBidKey, FactContractKey, and BidderKey; finally, DimBidders, with BidderKey.
I've left out degenerate dimensions and original business keys only to keep this message short. Please let me know if more info is required, I really need a qualified designer or architect to advise me but I don't know anybody else that's accessible.
Thanks,
Eric B.

Thanks, SQLBIGuyMN, you answered our question. It makes sense, too, because bids are only analyzed if they've been accepted and contracted, and they would only be related to the bidder through the contracts fact. I think we've also determined that contracts
needs to be an Accumulating Snapshot Table.
Thanks again,
Eric B.

Time dimension generated differently in 11gR2

Hi,
on generating a new default time dimension, I noticed some strange behaviour compared to the former release which seems to be incorrect.
1. No DIMENSION_KEY column as PK
2. the %_START_DATE columns are defined as business key instead of the %_NUMBER ord %_CODE columns
3. DAY_START_DATE is defined as PK column
I can modify this manually but what is the intention behind?
Is it meant that we should use a date column as FK reference in the cubes instead of the surrogate key.
Very odd !!
regards
Thomas

Hi,
thanks to Google I found Dave Allens excellent paper on [degenerate dimensions|http://blogs.oracle.com/warehousebuilder/2010/05/owb_11gr2_degenerate_dimensions.html].
Now it's a lot clearer to me.
Supposing you will read this, Dave, some more remarks:
1. The date column in the cube is a blessing not only with partitioning. Until now, I used to update the surrogate key of the time dimension to a number of format YYYYMMDD in order to ease my life.
2. But the time dimension table is still used not a mere stub as with DD?
3. I don't understand the context with SCD2. There, I need the DIMENSION_KEY.
4. I have the situation with a fact table containing one row per phone call. The unique phone call ID would be a candidate for a DD. But what would be the advantage to define the stub DD instead of just entering the string ?
Please give some more hints for a better understanding.
regards
Thomas

One to One relationship between Dimensions and Fact Tables

Hi,
Not a real Discoverer question, but seeing as there is such a huge pool of talent here, I thought I'd ask anyway...
Is the concept of having a one to one join between a Dimension and a Fact Table an Acceptable Thing (tm). I'm not talking about a degenerate dimension, as the Dimension would hold additional attributes.
It's something I'm trying to get my head around and would appreciate any viewpoints.
Thanks,
Andy

Hi Andy,
There is of course no distinction in SQL between 1-1 and 1-n joins, but in your database design you would avoid denormalizing data into a dimension table if it was only ever used once.
From a Discoverer perspective setting the join to 1-1 controls how aggregate queries are constructed. Normally, if you have a master-detail 1-n relationship and you aggregate items in both tables then you will get an incorrect result for the master table because the number of rows are multipled by the n detail records. Similarily if you have 2 detail tables in the query and you aggregate items in a detail table you will get incorrect results. Discoverer recognises these situations and raises an error.
Setting the join as 1-1 tells Discoverer that it will get the correct results in these situations and therefore no error is raised. So it is perfectly acceptable to set the joins as 1-1 as long as you know the implications.
Hope that helps,
Rod West

Degenerate Dimension

Similar Messages

Maybe you are looking for