Dimensional Design Question

I have done some reading on dimensional modeling and am a bit confused as to
how I create a dimension in our data warehouse using our transactional sourc
e.
I have a customer table which contains the customer id, customer name,
region codes and industry codes. Naturally I also have a region table and
industry table which has the region/industry descriptions.
I have read that the data warehouse should be designed using a star schema.
If that is the case, should I be creating a customer dimension with the
customer id, customer name, region desc, and industry name? Or should I
have a customer dimension, an industry dimension, and a region dimension?It depends on the kind of your analysis.
If Region and Industry are attributes of the customer and not
independent attributes of the fact you want to measure, they should be
normalized into the Customer dimension. If you want to track historycal
changes of Region/Industry of the customer, you should use SCD Type II
(Slowly Changing Dimension).
Only in particular scenarios you should consider a snowflake schema
instead of a star schema, but this is an exception and in my experience
you can safely avoid it in most of the models you have to manage.
I suggest you to read Kimball's books
(http://www.kimballgroup.com/html/books.html) as a reference for DW
modeling.
Marco Russo
http://www.sqlbi.eu
http://www.sqljunkies.com/weblog/sqlbi
JP wrote:
> I have done some reading on dimensional modeling and am a bit confused as
to
> how I create a dimension in our data warehouse using our transactional sou
rce.
> I have a customer table which contains the customer id, customer name,
> region codes and industry codes. Naturally I also have a region table an
d
> industry table which has the region/industry descriptions.
> I have read that the data warehouse should be designed using a star schema
.
> If that is the case, should I be creating a customer dimension with the
> customer id, customer name, region desc, and industry name? Or should I
> have a customer dimension, an industry dimension, and a region dimension?|||thanks marco. i do have the msft data warehouse toolkit but it doesn't
address this issue directly.
the region and industry are attributes of the customer so sounds like i
should have them "normalized" within the customer attribute. the fact tabl
e
is based on customer but i want to be able to roll-up the data to report by
industry, region, sub-industry, etc.
one item i left out was sub-industry. each sub-industry belongs to an
industry. so my customer dimension should look like the following?
customerkey (surrogate)
customerid (business key from source system)
region
industry
subindustry
"Marco Russo" wrote:

> It depends on the kind of your analysis.
> If Region and Industry are attributes of the customer and not
> independent attributes of the fact you want to measure, they should be
> normalized into the Customer dimension. If you want to track historycal
> changes of Region/Industry of the customer, you should use SCD Type II
> (Slowly Changing Dimension).
> Only in particular scenarios you should consider a snowflake schema
> instead of a star schema, but this is an exception and in my experience
> you can safely avoid it in most of the models you have to manage.
> I suggest you to read Kimball's books
> (http://www.kimballgroup.com/html/books.html) as a reference for DW
> modeling.
> Marco Russo
> http://www.sqlbi.eu
> http://www.sqljunkies.com/weblog/sqlbi
>
> JP wrote:
>|||Yes, you're right.
Flatten all customer attributes (Region, Industry, Subindustry, ...)
into Customer dimension.
You will find it's a very good schema to query now and to maintain in
the future, when you will add some other attributes.
Just to make an example: if you would have started with several tables,
imagine how adding a subindustry attribute would have impacted on your
schema and on your ETL implementation...
Marco Russo
http://www.sqlbi.eu
http://www.sqljunkies.com/weblog/sqlbi
JP wrote:[vbcol=seagreen]
> thanks marco. i do have the msft data warehouse toolkit but it doesn't
> address this issue directly.
> the region and industry are attributes of the customer so sounds like i
> should have them "normalized" within the customer attribute. the fact ta
ble
> is based on customer but i want to be able to roll-up the data to report b
y
> industry, region, sub-industry, etc.
> one item i left out was sub-industry. each sub-industry belongs to an
> industry. so my customer dimension should look like the following?
> customerkey (surrogate)
> customerid (business key from source system)
> region
> industry
> subindustry
>
> "Marco Russo" wrote:
>

Dimensional Design Question

I have done some reading on dimensional modeling and am a bit confused as to
how I create a dimension in our data warehouse using our transactional source.
I have a customer table which contains the customer id, customer name,
region codes and industry codes. Naturally I also have a region table and
industry table which has the region/industry descriptions.
I have read that the data warehouse should be designed using a star schema.
If that is the case, should I be creating a customer dimension with the
customer id, customer name, region desc, and industry name? Or should I
have a customer dimension, an industry dimension, and a region dimension?
It depends on the kind of your analysis.
If Region and Industry are attributes of the customer and not
independent attributes of the fact you want to measure, they should be
normalized into the Customer dimension. If you want to track historycal
changes of Region/Industry of the customer, you should use SCD Type II
(Slowly Changing Dimension).
Only in particular scenarios you should consider a snowflake schema
instead of a star schema, but this is an exception and in my experience
you can safely avoid it in most of the models you have to manage.
I suggest you to read Kimball's books
(http://www.kimballgroup.com/html/books.html) as a reference for DW
modeling.
Marco Russo
http://www.sqlbi.eu
http://www.sqljunkies.com/weblog/sqlbi
JP wrote:
> I have done some reading on dimensional modeling and am a bit confused as to
> how I create a dimension in our data warehouse using our transactional source.
> I have a customer table which contains the customer id, customer name,
> region codes and industry codes. Naturally I also have a region table and
> industry table which has the region/industry descriptions.
> I have read that the data warehouse should be designed using a star schema.
> If that is the case, should I be creating a customer dimension with the
> customer id, customer name, region desc, and industry name? Or should I
> have a customer dimension, an industry dimension, and a region dimension?
|||thanks marco. i do have the msft data warehouse toolkit but it doesn't
address this issue directly.
the region and industry are attributes of the customer so sounds like i
should have them "normalized" within the customer attribute. the fact table
is based on customer but i want to be able to roll-up the data to report by
industry, region, sub-industry, etc.
one item i left out was sub-industry. each sub-industry belongs to an
industry. so my customer dimension should look like the following?
customerkey (surrogate)
customerid (business key from source system)
region
industry
subindustry
"Marco Russo" wrote:

> It depends on the kind of your analysis.
> If Region and Industry are attributes of the customer and not
> independent attributes of the fact you want to measure, they should be
> normalized into the Customer dimension. If you want to track historycal
> changes of Region/Industry of the customer, you should use SCD Type II
> (Slowly Changing Dimension).
> Only in particular scenarios you should consider a snowflake schema
> instead of a star schema, but this is an exception and in my experience
> you can safely avoid it in most of the models you have to manage.
> I suggest you to read Kimball's books
> (http://www.kimballgroup.com/html/books.html) as a reference for DW
> modeling.
> Marco Russo
> http://www.sqlbi.eu
> http://www.sqljunkies.com/weblog/sqlbi
>
> JP wrote:
>
|||Yes, you're right.
Flatten all customer attributes (Region, Industry, Subindustry, ...)
into Customer dimension.
You will find it's a very good schema to query now and to maintain in
the future, when you will add some other attributes.
Just to make an example: if you would have started with several tables,
imagine how adding a subindustry attribute would have impacted on your
schema and on your ETL implementation...
Marco Russo
http://www.sqlbi.eu
http://www.sqljunkies.com/weblog/sqlbi
JP wrote:[vbcol=seagreen]
> thanks marco. i do have the msft data warehouse toolkit but it doesn't
> address this issue directly.
> the region and industry are attributes of the customer so sounds like i
> should have them "normalized" within the customer attribute. the fact table
> is based on customer but i want to be able to roll-up the data to report by
> industry, region, sub-industry, etc.
> one item i left out was sub-industry. each sub-industry belongs to an
> industry. so my customer dimension should look like the following?
> customerkey (surrogate)
> customerid (business key from source system)
> region
> industry
> subindustry
>
> "Marco Russo" wrote:

Dimension theory design question.

If I have a sales fact table with 1000 sales to 20 different customers would I have 20 rows in my customer dimension table or 1000 rows? Each sales row has a customer, but many would be duplicates. Do I add a row to the customer dimension for each sale or each customer?

Thanks.

Hello! You will have 20 customer records in your customer dimension table and 1000 records in your sales fact table.

You will have a one to many relation between the customer dimension table and the fact table.

Select Distinct (TSQL) will help you with duplicates in the customer dimension.

HTH

Thomas Ivarsson

|||

Thanks.

To recap: I have an identity integer field for the surrogate key in the dimCustomer table and a business key field. I have two choices for the business key: I can use the CustomerID or the SalesNum from the OLTP. I gather from your response that I should use the CustomerID as the business key. Then when I load the dimension table, if a new sale goes to an existing customer, a new row will NOT be added to the dimCustomer table. When I subsequently load my fact table, I'll use the CustomerID in my sales row to point to the business key in the dimension table and retrieve the surrogate key which will be loaded into the fact table as the foreign key to dimCustomer and part of my aggregate key in the factSales table.

Did I say that right? (There's a whole lot of keys goin on.)

|||

Correct! You will only add customers when the customer business key is not in that dimension table.

Yes, it is good design to use integers, non business keys, as a primary key(dimension table) and foreign key(fact table)

You load the dimension table first and the fact table after and you update the keys in the way you have described.

The fact table will only have the surrogate keys and the dimension table both the business key and the surrogate key.

Regards

Thomas Ivarsson

Dimension Design using attributes?

I would like to design a dimension as part of a cube to enable all survey results to be displayed in a single excel chart.

I have 10 questions each with answer choices (A, B, C, D, NO Response)

The excel chart would have a bar for each question, and each bar would be composed of 4 colors representing either A,B,C or D.

I can generate 10 dimensions (one for each question), but I can't get it to fit in the same chart. I would like to create one dimension encapsulating the entire survey..by possibly using attributes.

Is there a bettwer way to do this...using excel and as2005?

Any help or advise would be appreciated!

The "Survey" section of this paper on many-to-many dimensional modelling discusses how to incorporate the answers to multiple questions of a survey in a single dimension:

http://www.sqlbi.eu/Portals/0/Downloads/M2M%20Revolution%201.0.93.pdf

>>

...

Survey

The survey scenario is a common example of a more general case where you have a lot of attributes associated to a case (one customer, one product, and so on) and you want to normalize the model because you do not want to change the UDM each time you add a new attribute to data (as adding a new dimension or changing an existing one). One common scenario is a questionnaire consisting of questions that have predefined answers with both simple and multiple choices.

...

>>

Dimension design question

Hi,

what is the best practice for design of large dimension, such as Order? In my scenario users want to analyze order intake using order status, issuer name and couple of other attributes, possibly even order number. We use fact dimension to accomplish that. Everything works, but I'm a bit concerned about performance. There are more than 10mil members in that dimension (and there is also invoicing dim as well, about the same size).

Is this the best design for this scenario? What if I create separate dimensions Issuer, Order Status ... and link them directly to the fact? Will the performance (though it's not bad now, I'm just thinking ahead) improve, and, most importantly, WHY? :)

Thanks.

Radim

What are your concerns about dimension performance?

You got to quite specific when you talk about performance. What is schenario for using your dimensions?

Do you expect users to drill down to the lowest level? Do you have nice natural hierarhies stucture into your dimension?

Analysis Services can nandle your multiple large dimensions. See referece to Project Real implemenation http://www.microsoft.com/sql/solutions/bi/projectreal.mspx

Building navigation paths using right set of native hierarchies is key to the dimension performance.

Edward Melomed.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

sql

Dimension Design Question

I have a question about designing a dimension.

I have a fact table with 2 bit columns "IsBalance" & "IsAttribution". Possible values are (0 , 1), (1, 0) and (1,1). Pl note that the fact table cannot be changed.

I use SSAS 2005. I had created 2 dimensions (from named queries) called Balance (Members : 1, 0) and Attribution (Members : 1, 0) to implement the above. Both link to fact table directly.

Obviously this works but it is not the 100% correct business representation. The ideal way is to have a dimension called Type and have following members in it ==> Balance, Attribution, Both. Any suggestion on how to acheive this? Or Is there a better way of doing it?

Thanks,

Arun

It sounds like you just need to create a single dimension from a named query which contains the following rows:

DimKey Balance Attribution Both 0 TRUE FALSE FALSE 1 FALSE TRUE FALSE 2 TRUE TRUE TRUE

You can now build the three attributes you want from this table, plus a key attribute from the DimKey column which you can hide.

If the fact table can't be changed, you've got two options: either create a new named calculation on the fact table in the dsv to derive the DimKey value from the two existing columns or use a composite key for the DimKey attribute rather than the single column described above and join the two columns in this composite key to the two existing columns in your fact table.

HTH,

Chris

|||

Thanks Chris.

Sorry I was not clear in my first post.

Is it possible to have an attribute with following members ==> Balance, Attribution, Both from which the users can select either of them to filter the data across ?

The problem here is that when "Balance" member is selected, it should filter data for combination (Balance = 1, Attribution = 0) and (Balance = 1, Attribution = 1) . Same thing should happen for Attribution too.

|||

Ahh, ok. This sounds like a many-to-many relationship: keep the dimension designed in my previous reply but only build a single attribute on it based on the key, and then hide the whole dimension. Then create a dimension containing the single attribute that you want to see, off the following table:

M2MDimKey M2MDimName 0 Balance 1 Attribution 2 Both

Then create an measure group from a fact table containing the following values:

DimKey M2MDimKey 0 0 1 1 2 2 2 0 2 1

Put in regular relationships between the two new dimensions and this measure group, and last of all you'll be able to give the new dimension based on M2MDimKey/M2MDimName a many-to-many relationship to your main measure group. Now you should get the behaviour you want: selecting the Balance member will give you the aggregated values for all rows where Balance=1, but the Both member will only give you the value for Balance=1 and Attribution=1, and your All Member values will also show correct values.

Chris

|||

Thanks a lot Chris. Tried it out today and works great.

One of the things that I had noted :

I had set the "IsAggregatable" to False (as the "All" member does not make any sense in this case. "Both" member in level 1 will be the quivalent of top level) for this dimension and had set the default value to "Both". When I use the Agg design wizard, it complains that the dimension does not have any agg attribute and hence cannot proceed.

The work around is to set the "IsAggregatable" to True, design and set it back to "False" again. But is this is the right thing to do? (Should I use BIDS helper and delete agg that uses the top level of this dimension)

|||

Hmm, that's strange - I've never had that problem when setting IsAggregatable to false. Had you been setting the AggregationUsage property on the cube dimension or something?

Chris

|||Nope. I haven't changed the defaults on the cube dimension properties. I had set only for the dimension directly.

Dimension Design Help: Mix of Parent-Child and List

Hello Analysis Server Users!

I wonder if someone can help me with the setup a dimension that is a parent-child hierarchy first, but the leaves are not joined to the fact table, but instead to another table containing a list of elements for this leaf, and from there fianlly to the facts. Hmm... bad wording and description, sorry.

Maybe an example helps: say I got a list of 5 elements a-e that are in a simple list dimension and act as hosts for fact data. Just simple straight list a, b, c, d and e. This list is often used and must be kept, it is stored in a simple straight table in the database.

I would now like a group in addition to that, as an alternative, say I want to see grouped together b, c and e.

I could do that by adding an attribute "my group" - but that would automatically result in another group "not my group", containing a and d - It would look like this:

(all)

-mygroup

--b

--c

--e

-other group

--a

--d

In my world this group "other" and the data aggregated on it is nonsense, the business does not use the data in that combination.

So what I am looking for is something that looks like this:

(all)

-a

-d

-mygroup

--b

--c

--e

I know how to build that, I did do parent child dimensions before, but the special twist here is that I cannot add the mygroup name to the list of a - e, since than it appears as a new item in the list. Remember, I early said I want to keep the straight list a - e and only want the hierarchy in addition to it.

So, the hierarchy elements "mygroup" needs to be put into another table, and that is when I am stuck... Can I have a self refercing table as top level, then another table below it with the elements, and that finally leads to the 3rd table with the fact data?

Hello,

I think, you can use the parent-child hierarchy as you have build it, and for getting the straight list, you can reference it in MDX with Descendants([All], <last level number>, LEAVES), so for example if the last level is 3 and the top Level is [All]: Descendants ([All], 3, LEAVES), for getting a list a ... e

Hans

|||

I think I understand what you are trying to say, but I admit I cannot see how you "add" the MDX to the dimension.

Do you mean to build one or two dimensions? One, I guess, parent child type.

Where can I put the MDX to make the dimension get the two "apperances", to get the straight list "minus" (filtered out) those elements that form the hierarchy in the other view? Is that a property or?

|||

Hi,

No, I think you make one parent-child dimension with all the grouping you need. Than you make a calculated member under "Calculations" in visual studio with that MDX. Because the "list-view" is only "another view" with that dimension for retrieving data in that way. I think you didn't build this in a dimension, because it's only 2 different ways of viewing at the data. It's the same as in the relational world: you have one table and a lot of different querys fullfilling your nees. Here you have your dimensions and fact-tables an a lot of MDX queries (perhaps encapsulated as calculated members) which bring the data as you need it.

Hans

|||

I am not fully aware of what you would like to do here but visually it looks to me as a problem that dimension writeback can solve.

With dimension writeback you can create members in a parent-child dimension that do not exist in the source table. You can also move existing members in a dimension tree.

I think that you will need the SSAS2005 Enterprise edition for this feature.

Regards

Thomas Ivarsson

Dimension design

I have a cube, with a handset dimension. The facts I am measuring are counting the subscribers, their revenue and their usage. In the handset dimension, I have an attribute "score" which actually scores the features of the handsets. Now I would also like to measure the average handset score. Do I have to add a sum aggregated measure which sums up the handset score and create a calculated measure to divide this score measure by the subscriber count? Or is there another way to have the same result?

Thank you in advance

Joos

I think Sum/Count for this case.

SSAS 2005 also has Aggregation function AverageOfChildren, that specifies average of leaf descendants in time. Read about that one here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=548837&SiteID=1

Vidas Matelis

|||Could you explain the granulairy of the fact table - is it a periodic snapshot, or is there a record per handset owned by a subscriber? And when computing the average handset score for a given selection of data, is the average across all handsets in thst selection, or across all distinct handset types selected - could you illustrate with an example?|||

I have 2 fact tables. The first one is used to count subscribers and to measure their revenue. The second fact tabel measures the usage of subscribers.

In each fact table, I do have a record per subscriber/handset combination. Each handset has a score. This score is an attribute of the handset dimension. Of course, I do have other dimensions, but this does not matter for this problem.

For a given selection of data, I should sum up the scores of all corresponding handsets, and divide it by the nr of subscribers. To get a real average, I will not sum up the scores of all distinct handsets.

So for example:

Subscriber 1, handset A, score 5

Subscriber 2, handset B, score 4

Subscriber 3, handset A, score 5

This should result in an average score of (5+4+5)/3

Thanks

Joos

|||

Assuming that there is a [SubscriberCount] measure from the 1st fact table, and that there are [Handset] and [Score] attributes in the [Handset] dimension, where [Score] has a numeric MemberValue defined (like 4, 5 .. above):

Sum([Handset].[Handset].[Handset],

[Measures].[SubscriberCount] * [Handset].[Score].MemberValue)

/ [Measures].[SubscriberCount]

Or, for better performance, you could add the Handset Score to the 1st fact table using a Named Query, and create a "sum" measure on it like [HandsetScore]. Then, as Vidas suggested, you could use Sum/Count, like:

[Measures].[HandsetScore] / [Measures].[SubscriberCount]

dimension design

In my telco cube, I want to analyze usage. Eg how much sms's a subscriber has sent. The fact table is completely denormalized and has lots of columns with different types of usage. For example, following columns occur:

MO_VOI_PEAK

MO_VOI_OFFPEAK

MO_VOI_WEEK

MO_VOI_WEEKEND

Now the sum of these fields overlap. Evenings during the week are also offpeak... This is only an example. Different categories occur for different products, like voice, sms, mms and so on. And not all categories apply to all products. Eg, mms does not have the peak and offpeak distinction.

Is it possible to put this into one dimension, without aggregating double?

I have already normalised the fact table, meaning that for each usage type, I have one record. So the 4 types mentioned above, all occur in 4 records, instead of 4 columns.

I have also built up a table to link this usage type to its attributes. You can find an extract below.

UsageType

OrigDesc

ApplCode

PeakCode

RoamingCode

ScopeCode

WeekCode

PersCode

MO_VOI_NAT_ONNET

MO

VOI

NON-ROAM

NAT_ONNET

MO_VOI_NAT_OTHER

MO

VOI

NON-ROAM

NAT_OTHER

MO_VOI_NAT_FIXNET

MO

VOI

NON-ROAM

NAT_FIXNET

MO_VOI_INT

MO

VOI

NON-ROAM

INT

MO_VOI_ROAM

MO

VOI

ROAM

MO_VOI_OTHER_DEST

MO

VOI

NON-ROAM

OTHER_DEST

MO_VOI_FLATRATE

MO

VOI

NON-ROAM

FLATRATE

MO_VOI

MO

VOI

MT_VOI_NAT_ONNET

MT

VOI

NON-ROAM

NAT_ONNET

MT_VOI_NAT_OTHER

MT

VOI

NON-ROAM

NAT_OTHER

MT_VOI_NAT_FIXNET

MT

VOI

NON-ROAM

NAT_FIXNET

MT_VOI_INT

MT

VOI

NON-ROAM

INT

MT_VOI_ROAM

MT

VOI

ROAM

MT_VOI_OTHER_DEST

MT

VOI

NON-ROAM

OTHER_DEST

MT_VOI

MT

VOI

MO_VOI_PEAK

MO

VOI

PEAK

MO_VOI_OFFPEAK

MO

VOI

OFFPEAK

MO_VOI_WEEK

MO

VOI

WEEK

MO_VOI_WEEKEND

MO

VOI

WEEKEND

MT_VOI_PEAK

MT

VOI

PEAK

MT_VOI_OFFPEAK

MT

VOI

OFFPEAK

MT_VOI_WEEK

MT

VOI

WEEK

Is there a way to include all this information into 1 dimension, without aggregating in a wrong way, so without summing up double?

Thanks a lot

Joos

Could you clarify why there are multiple rows for some UsageTypes above, but with the same data in the columns shown? For example, these 6 rows are repeated later:

UsageType

OrigDesc

ApplCode

PeakCode

RoamingCode

ScopeCode

WeekCode

PersCode

MO_VOI_NAT_ONNET

MO

VOI

NON-ROAM

NAT_ONNET

MO_VOI_NAT_OTHER

MO

VOI

NON-ROAM

NAT_OTHER

MO_VOI_NAT_FIXNET

MO

VOI

NON-ROAM

NAT_FIXNET

MO_VOI_INT

MO

VOI

NON-ROAM

INT

MO_VOI_ROAM

MO

VOI

ROAM

MO_VOI_OTHER_DEST

MO

VOI

NON-ROAM

OTHER_DEST

|||

They are not the same...you have MO and MT, meaning originating and terminating.

Regards

Joos

|||

Do you want each UsageType to be independently aggregated, with no aggregation of usage across UsageTypes? If so, you could create a UsageType dimension, where the "IsAggregatable" property of the UsageType attribute is set to false. Otherwise, could you explain how you want usage to be aggregated in more detail, with an example?

http://msdn2.microsoft.com/en-us/library/ms174497.aspx

>>

SQL Server 2005 Books Online

Configuring the (All) Level for Attribute Hierarchies

...

The presence of an (All) level in an attribute hierarchy depends on the IsAggregatable property setting for the attribute and the presence of an (All) level in a user-defined hierarchy depends on the IsAggregatable property of the attribute at the top-most level of user-defined hierarchy. If the IsAggregatable property is set to True, an (All) level will exist. A hierarchy has no (All) level if the IsAggregatable property is set to False.

>>

|||

I do want aggregation of usage types, but I want to control aggregation...

I would like to include all attributes of the usage types as displayed in the table. With these attributes, I would like to build hierarchies, like for example origdesc - appl code - peak code, and origdesc - appl code - weekcode. However, for example for Voice, this is not the sum of all week, weekend, peak and offpeak usage types. Moreover, for example for mms, I do not have this distinction and ideally, I would only like to show the appl codes, for which the hierarchy applies, meaning that MMS should not occur in the given hierarchy. This last remark is impossible, I guess...

Most importantly, I would like to control which usage types should be taken to get eg the voice aggregate and eg the MO aggregate. If I would just sum up all voice usage types, this would not be correct...I would be counting more than double.

|||Well, you've given examples of how usage aggregates in some specific cases, but there's no systematic pattern that I can discern. One approach that comes to mind is a fact table where each row indicates (non-overlapping) usage, so that values there can always be aggregated. Then multiple UsageTypes could be related to each fact row via a bridge table/intermediate measure group, using the SSAS Many-to-Many dimension modelling feature.|||

I have chosen to include only those usage types that aggregate towards a real total. If there will be a need to include the others, I will do this in a seperate measure group.

Joos