Distinct count of dimension business key in fact table

In my cube I have a fact table which joins to a patient dimension. The patient dimension is a type 2. What I would like to do is get a distinct count of patients who have records in the fact table. The business key in the patient dimension
is the PrimaryMrn. So a SQL query would look like this.
SELECT count(distinct PrimaryMrn)
FROM EncounterFact e
INNER JOIN PatientDim p
on e.PatientKey = p.PatientKey
Is it possible to do this via MDX?
Thanks for the help.

If you have to distinct count an attribute in a SCD 2, you might choose between:
Denormalizing that attribute in the fact table, and the create a classical DISTINCT COUNT measure
Use a many-to-many approach - see the "Distinct Count" scenario in the Many-to-Many White paper here:
http://www.sqlbi.com/articles/many2many (for both Multidimensional and Tabular
If you use Tabular, you might want to read also this pattern:
http://www.daxpatterns.com/distinct-count/
Marco Russo http://www.sqlbi.com http://www.powerpivotworkshop.com http://sqlblog.com/blogs/marco_russo

Similar Messages

What is the best practice for creating primary key on fact table?

what is the best practice for primary key on fact table?
1. Using composite key
2. Create a surrogate key
3. No primary key
In document, i can only find "From a modeling standpoint, the primary key of the fact table is usually a composite key that is made up of all of its foreign keys."
http://download.oracle.com/docs/cd/E11882_01/server.112/e16579/logical.htm#i1006423
I also found a relevant thread states that primary key on fact table is necessary.
Primary Key on Fact Table.
But, if no business requires the uniqueness of the records and there is no materilized view, do we still need primary key? is there any other bad affect if there is no primary key on fact table? and any benifits from not creating primary key?

Well, natural combination of dimensions connected to the fact would be a natural primary key and it would be composite.
Having an artificial PK might simplify things a bit.
Having no PK leads to a major mess. Fact should represent a business transaction, or some general event. If you're loading data you want to be able to identify the records that are processed. Also without PK if you forget to make an unique key the access to this fact table will be slow. Plus, having no PK will mean that if you want to used different tools, like Data Modeller in Jbuilder or OWB insert / update functionality it won't function, since there's no PK. Defining a PK for every table is a good practice. Not defining PK is asking for a load of problems, from performance to functionality and data quality.
Edited by: Cortanamo on 16.12.2010 07:12

Null key in fact tables

Hi all,
I have one role play dimension with some null key in fact table, I liked know if it's a good practice?
thanks

Depends on what you actually mean..
When one dimension column contains NULL in your fact table, then it's normally a bad practice. Create a entry in your dimension table to represent this state.
The problem is that NULL is a state, which means does missing or inapplicable information. This means that the row in the fact table is semantically meaningless. Cause your fact table is no longer additive over this dimension.

How can we know that size of dimension is more than fact table?

how can we know that size of dimension is more than fact table?
this was the question asked for me in interview

Hi Reddy,
This is common way finding the size of cube or dimensions or KF.
Each keyfiure occupies 10 Bytes of memory
Each Char occupies 6 Bytes of memory
So in an Infocube the maximum number of fields are 256 out of which 233 keyfigure, 16 Dimesions and 6 special char.
So The maximum capacity of a cube
= 233(Key figure)10 + 16(Characteristics)6 + 6(Sp.Char)*6
In general InfoCube size should not exceed 100 GB of data
Hope it answer your question.
Regards,
Varun

Few dimension values used in FACT tables.

Hello all,
We are trying to know if somebody faced this issue earlier. We have dimension tables containing 5 million records, but the fact table uses hardly 30k of these dimension values. The fact table contains 350 million records, so is there any way to improve the performance of the query in such a scenario, where hardly 20% of dimension values are actually used by the FACT tables.
Thanks and Regards,
Upendra

nilanjan chatterjee wrote:
Hi,
>
> The data for the parent members should be available in the SQL tables.
> For example, 2011.TOTAL is parent member. You should not have any data for this member in your database. If it is there, it might have come somehow (may be an import). But this is not right. You might want to remove these records. But be sure that you dont delete the records for the base level members.
>
> Hope this helps.
I guess you meant should not, right ?

Conformed dimension and query multiple fact tables

Hello,
Please if someone can guide me on this requirement.
Requirement - I have a conformed dimension D1 and two fact tables F1 and F2. Both fact tables have many columns so I cannot merge
the two fact tables into one logical table. Currently both these fact tables have logical tables F1 and F2 respectively.
As per design the conformed dimension is a simple logical table in the rpd and not a dimension.
Can someone guide me how should i proceed so that i'll be able to fetch information from both the fact tables?
Edited by: 930542 on Apr 26, 2012 12:28 PM

Hi,
Currently the dimension table is taken as a simple logical table in rpd as it does not have have any levels or hierarchy.
Its a flat dimension. Can you guide me how can I implement a flat dimension in OBIEE? Because this dimension is taken as simple logical table
I am not able to set appropriate level for fac tables. This dimension does not appear in the list of dimensions.

Same dimension in two different fact tables

Hi,
I have one same dimension in two different fact tables. I would like to know how BI server choose the fact table when I do a request in this dimension.
I know that is always using the same fact table, but I would like to know why choose this table and not the other.
Thanks

Sorry,
But it doesn't seem to me.
I reorded the tables in the BMM layer and it continues to use the same table, regardless this table is in last.
After, I droped that table in the BMM layer and it continued to use the same.
Thanks for your reply

Dimension foreign key on Fact gets updated with same value

Hi All,
I'm hoping someone has at least seen this problem and can provide insight.
Background:
- We are on OWB 10.2
- Fact table is Billing_F
- Fact table has foreign keys to Customer_Dim, SalesOrg_Dim, Time_Dim, etc.
- Fact table has update mode Update/Insert
Once in a while, every row in the Billing Fact gets updated with the SAME SalesOrg_Dim foreign key column value. In other words, the data would look like:
Before:
Line ID Amt SalesOrg_Key
1 100 19241
2 200 21925
3 140 08585
After:
Line ID Amt SalesOrg_Key
1 100 12345
2 200 12345
3 140 12345
*** The Source tables contain values in the Before table. ***
We can't reproduce this on a consistent basis. The only way to "correct" the data is to rerun the mapping from source -> staging -> fact again. No other change.
Please, has anyone else at least experienced this problem? If so, how were you able to fix it permanently?
Any help is greatly appreciated!
irene

Hi Irene
Difficult to help here without reviewing your mappings/schedule but does SalesOrgKey 12345 represent a particular value e.g. Unknown, Default?
I suspect it's something to do with your load order in that the data in the dimension is not available/ready when the fact is loaded and therefore a default value is being inserted. When the fact load is rerun I'm guessing the load of the dimension has finished and therefore the key lookup returns the proper keys from the dimension. Is the dimension truncated and reloaded?
Regards
Si

Primary key in Fact table

Hi ,
I have a question usually fact table consists of all primary keys from different dimensional tables but i have a requirement like this:
Fact table consists of non-dimensional columns and one primary key Amount_ID(PK) aand this amount_ID is a FK in another table which records day to day transactions. My question is can a fact table have a PK ?
Thanks,
ch

Yes Fact Table can have a Primary key
But in your case it looks like the Other Table which is storing Day to Day transaction should be made FACT , and the one you are calling FACT should be made Dimension..
Well depends again, how you are analysing data and against which attributes
Thanks
Ashish

Duplicate record with same primary key in Fact table

Hi all,
Can the fact table have duplicate record with same primary key . When i checked a cube i could see records with same primary key combination but the key figure values are different. My cube has 6 dimentions (Including Time,Unit and DP) and 2 key figures. So 6 fields combined to form the composite primary key of the fact table. When i checked the records in se16 i could see duplicate records with same primary key. Ther are no parallel loading happening for the cube.
BW system version is 3.1
Data base is : Oracle 10.2
I am not sure how is this possible.
Regards,
PM

Hi Krish,
I checked the datapacket dimention also. Both the record have same dimention id (141). Except the Keyfigure value there is no other change in the Fact table record. I know this is against the basic DBMS primary key rule. But i have records like this in the cube.
Can this situation arise when same records is there in different data packet of same request.
Thx,
PM
null

Adding Dimension field ($) in measures (fact) table in logical layer

Hi,
I have a field (amount) in the dimension table. I would like to add this field in the fact table at the logical layer. Dimension table and fact table had physical joins. Can I add into fact table and still do aggregation on that field based on the other dimensions linked to fact table. I working on Siebel Analytics version 7.8. Any help would be greatly appreciated.
Thanks in advance,
RK

Check here : How to create a measure from data that is stored in a dimension table
http://gerardnico.com/wiki/dat/obiee/bi_server/design/fact_table/obiee_measures_dimension
Cheers
Nico

Two Filter on Two dimensions without constraining the fact table

Hi All,
does anybody know how to avoid the fact constraint when creating a report with two filters on different dimensions?
I have a big fact table with more than 10 Million rows. In the starmodel the is the dimension customer and products. I create a filter on the customer atrribute "Status" and choose the value "Active". Now I add the column "Product Type" from the dimension "Product" to the filter section. When I want to choose a value OBIEE executes a select statement within the fact table. So I have to wait very long to select a value. Is there any way to say OBIEE only to select the dimension table without joining the fact table?
Thank you very much in Advance.
Regards,
Stefan

Hi Stefan,
Generally queries on the dimensions (across dimesions also) always go through a fact. In case, you would like the queries not be through fact table, but just the dimension tables right away, you can set up a separate subject area for them.
You can create a separate subject area based on a dummy fact table to get these prompt values.
Please refer to http://gerardnico.com/wiki/dat/obiee/presentation_service/obiee_parameter_prompt_subject_area for more details on this setup.
Hope this helps.
Thank you,
Dhar

Calculating distinct counts of dimension columns

Hi, OBIEE Gurus. Here's today's question on the quiz show "Can this be done?".
Month
Region
Sales
# Months
# Regions
Jan-2013
East
1000
2
3
Jan-2013
Central
2000
2
3
Jan-2013
West
3500
2
3
Feb-2013
East
1250
2
3
Feb-2013
Central
1925
2
3
Feb-2013
West
3450
2
3
The # Months and # Regions columns are the goal today. There are two months in this analysis (Jan-2013, Feb-2013), out of a total population of 96 months. There are three regions in this analysis (East, Central, West) out of a total population of 7 regions. I want those values (2 and 3, respectively) reflected in the # Months and # Regions columns.
I've tried various combinations of the usual suspects (count, count distinct, sum(count..., sum(count distinct... and so forth) but I haven't found the correct magic spell yet. Any ideas?

I found one potential (but somewhat flawed) solution for # Months:
count(distinct aggregate("Facts"."Sales" at "Geographies"."Geography"."Total Locales"))
Region is part of my Geography hierarchy, whose highest level is Total Locales. This says to calculate sales for each row for the Total Locales level, so essentially ignore the Region column. The flaw here is that two different months that just happen to have exactly the same sales will only generate one distinct value of sales, so there is the potential to undercount. (I can get around it with a minor calculation, but that's just another complication.)
It also seems rather clunky, because it has to be modified to accommodate any newly added columns and (basically) create a level-based fact for the highest level of every hierarchy represented except for the column of interest. So it's not very pretty solution.
If you have anything more elegant, bring it on.

Oracle Administration Tool (RPD) One Dimension linked with many fact tables

How to connect One dimension with many table facts in the Lgical level of RPD without having an error about connection between table facts?

It's not about "linking two catalogs". That's Siebel Marketing stuff. Forget about it. Just create your models and put them in their respective presentation catalogs.
Whatever you fire from answers will hit that specifc presentation catalog and search its way through the metadata to contruct the query.
Hence conforming dimensions as a technical concept are definitely the thing you want...not the rpd object type "conformed dimension links".

OBIEE 10G - Repository Business Model adding Fact Table

Hi there,
I've tried to search in the forum for problems similar to this one but didn't find any thread that answered my doubts.
I'll try to explain this well (without images it's complicated). Let's assume we have a schema with the following tables:
Dim_1, Dim_2 , Dim_3, Dim_4, Dim_5, Fact_1, Fact_2
Fact_1 is connected to Dim_1, Dim_2 and Dim_3
Fact_2 is connected to Dim_2, Dim_3, Dim_4 and Dim_5
And on the business model of the repository we already have a model with the following tables:
Dim_1, Dim_2, Dim_3 and Fact_1. This was the state of the repository the last time we saved it.
Now i want to add to the business model the table Fact_2 and the Dims that connect with Fact_2. What should i do here?
If i drag from the physical layer only the tables (Dim_4, Dim_5 and Fact_2 since Dim_1 and Dim_2 already exist in the business model) when i check on the business model diagram the Fact_2 table and direct joins i will only see joins to Dim_4 and Dim_5 and not the joins to the two other dimesion tables (Dim_1 and Dim_2). I don't know if OBIEE will still act like these joins are made or if i will have problems when i work on presentation services.
If i drag from the physical layer the tables (Dim_2, Dim_3, Dim_4, Dim_5 and Fact_2) i will see all joins but i will have on the business model repeated tables, something like this:
Dim_1, Dim_2, Dim_2#1, Dim_3, Dim_3#1, Dim_4, Dim_5, Fact_1 and Fact_2
So what's the solution here? Do i have to redo everything i want to add something and this situation occurs? Doesn't sound smart and there has to be a better solution. I know i can redo the direct joins manually but is that the best solution i can look for in this situation?
I hope i was clear :)
Thanks

Hi,
Follow these steps,
1.Drag Dim_4, Dim_5 and Fact_2 to BMM
2.Select (Press Ctrl to select multiple objects)in BMM: Dim 1 to 5, Fact_1 and Fact_2
3.Right click ->Business Model diagram->Selected objects only
4.Give the necessary joins,
Dim 4,&5 joins to Fact1(as 1,2,3 are already joined)
Dim 2,3,4,5 joins to Fact2
5.Check consistency.
Rgds,
Dpka

Distinct count of dimension business key in fact table

Similar Messages

Maybe you are looking for