Showing posts with label quarter. Show all posts
Showing posts with label quarter. Show all posts

Monday, March 19, 2012

Aggregation Problem with Hours and Minutes in Time Dimension

For the first time, I have created a time dimension that includes hours and minutes, in addition to the Year, Quarter, Month, and Date that I am familiar with.

I want to display the average of my measures at whatever level of Time the user chooses. I thus chose "AverageOfChildren" as the aggregation method for these measures.

Unfortunately, SSAS aggregates these measures by Sum over Hours and Minutes, and then by AverageOfChildren over Date, Month, Quarter, and Year.

I am confused.

How can I force it to perform an "AverageOfChildren" at all levels ?

First, have a look at this document(http://www.microsoft.com/technet/prodtechnol/sql/2005/realastd.mspx) and think about your design a second time(on page 34-35 in the word version)

Next. This is only a guess but how are your attribute relations between minutes, hours, date,quarter and year defined, if they are included in the same user hierarchy?

HTH

Thomas Ivarsson

Thursday, March 8, 2012

Aggregate Transpose Problem

My example code (CODE 1) returns quarter counts for several fields in
Northwind (I'm using Northwind to simulate my actual data). It returns code
that looks like FIGURE 1.
Can my sql be modified so the Field names are the GROUPED BY and run down
the 1st column while forcing the Quarters to be the header columns and
replace the ctShipName, ctShipCity and ctShipCountry positions and result
looking like FIGURE 2?
FIGURE 1 (Current Result):
Quarter ctShipName ctShipCity ctShipCountry
1996, Qtr. 3 185 185 185
1996, Qtr. 4 220 220 220
1997, Qtr. 1 241 241 241
1997, Qtr. 2 253 253 253
1997, Qtr. 3 256 256 256
FIGURE 2 (Desired Result):
Fields 1996, Qtr. 3 1996, Qtr. 4 1997, Qtr. 1
1997, Qtr. 2 1997, Qtr. 3
ctShipName 185 220 241
253 256
ctShipCity 185 220 241
253 256
ctShipCountry 185 220 241
253 256
CODE 1:
SELECT CAST(DATEPART(yyyy, Orders.OrderDate) AS VARCHAR) + ', Qtr. ' +
CAST(DATEPART(q,
Orders.OrderDate) AS VARCHAR) AS Quarter
COUNT(Orders.ShipName) AS ctShipName,
COUNT(Orders.ShipCity) AS ctShipCity, COUNT(Orders.ShipCountry) AS
ctShipCountry
FROM Categories INNER JOIN
Products ON Categories.CategoryID =
Products.CategoryID INNER JOIN
Orders INNER JOIN
[Order Details] ON Orders.OrderID = [Order
Details].OrderID ON Products.ProductID = [Order Details].ProductID
GROUP BY CAST(DATEPART(yyyy, Orders.OrderDate) AS VARCHAR) + ', Qtr. ' +
CAST(DATEPART(q,
Orders.OrderDate) AS VARCHAR)
ORDER BY CAST(DATEPART(yyyy, Orders.OrderDate) AS VARCHAR) + ', Qtr. ' +
CAST(DATEPART(q,
Orders.OrderDate) AS VARCHAR)Scott (sbailey@.mileslumber.com) writes:
> My example code (CODE 1) returns quarter counts for several fields in
> Northwind (I'm using Northwind to simulate my actual data). It returns
> code that looks like FIGURE 1.
> Can my sql be modified so the Field names are the GROUPED BY and run down
> the 1st column while forcing the Quarters to be the header columns and
> replace the ctShipName, ctShipCity and ctShipCountry positions and result
> looking like FIGURE 2?
Yes, but to conserve space, I only include the first two quarters:
SELECT col AS " ",
SUM(CASE WHEN datepart(YEAR, O.OrderDate) = 1996 AND
datepart(Q, O.OrderDate) = 3 THEN
CASE col WHEN 'ctShipName' THEN
CASE WHEN O.ShipName IS NOT NULL THEN 1 ELSE 0 END
WHEN 'ctShipCity' THEN
CASE WHEN O.ShipCity IS NOT NULL THEN 1 ELSE 0 END
WHEN 'ctShipCountry' THEN
CASE WHEN O.ShipCountry IS NOT NULL THEN 1 ELSE 0 END
END
ELSE 0
END) AS "1996, Qtr. 3",
SUM(CASE WHEN datepart(YEAR, O.OrderDate) = 1996 AND
datepart(Q, O.OrderDate) = 4 THEN
CASE col WHEN 'ctShipName' THEN
CASE WHEN O.ShipName IS NOT NULL THEN 1 ELSE 0 END
WHEN 'ctShipCity' THEN
CASE WHEN O.ShipCity IS NOT NULL THEN 1 ELSE 0 END
WHEN 'ctShipCountry' THEN
CASE WHEN O.ShipCountry IS NOT NULL THEN 1 ELSE 0 END
END
ELSE 0
END) AS "1996, Qtr. 4"
FROM (SELECT col = 'ctShipName'
UNION ALL
SELECT 'ctShipCity'
UNION ALL
SELECT 'ctShipCountry') AS names
CROSS JOIN (Orders O
JOIN [Order Details] OD ON O.OrderID = OD.OrderID
JOIN Products P ON P.ProductID = OD.ProductID
JOIN Categories C ON C.CategoryID = P.CategoryID)
GROUP BY col
Now, I presume that in your real-world case, you result set is not
entirely static as here. In that case, you will have to play with
dynamic SQL again.
But before you rush ahead, have a look at http://www.rac4sql.net. This
is a third-party tool which reportedly is very good for crosstabs and
similar. I have never used it myself, but I've heard people speak
positively about it.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||thanks, that was a tough one, but I see what I have to do.
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9728DBD278581Yazorman@.127.0.0.1...
> Scott (sbailey@.mileslumber.com) writes:
> Yes, but to conserve space, I only include the first two quarters:
> SELECT col AS " ",
> SUM(CASE WHEN datepart(YEAR, O.OrderDate) = 1996 AND
> datepart(Q, O.OrderDate) = 3 THEN
> CASE col WHEN 'ctShipName' THEN
> CASE WHEN O.ShipName IS NOT NULL THEN 1 ELSE 0 END
> WHEN 'ctShipCity' THEN
> CASE WHEN O.ShipCity IS NOT NULL THEN 1 ELSE 0 END
> WHEN 'ctShipCountry' THEN
> CASE WHEN O.ShipCountry IS NOT NULL THEN 1 ELSE 0
> END
> END
> ELSE 0
> END) AS "1996, Qtr. 3",
> SUM(CASE WHEN datepart(YEAR, O.OrderDate) = 1996 AND
> datepart(Q, O.OrderDate) = 4 THEN
> CASE col WHEN 'ctShipName' THEN
> CASE WHEN O.ShipName IS NOT NULL THEN 1 ELSE 0 END
> WHEN 'ctShipCity' THEN
> CASE WHEN O.ShipCity IS NOT NULL THEN 1 ELSE 0 END
> WHEN 'ctShipCountry' THEN
> CASE WHEN O.ShipCountry IS NOT NULL THEN 1 ELSE 0
> END
> END
> ELSE 0
> END) AS "1996, Qtr. 4"
> FROM (SELECT col = 'ctShipName'
> UNION ALL
> SELECT 'ctShipCity'
> UNION ALL
> SELECT 'ctShipCountry') AS names
> CROSS JOIN (Orders O
> JOIN [Order Details] OD ON O.OrderID = OD.OrderID
> JOIN Products P ON P.ProductID = OD.ProductID
> JOIN Categories C ON C.CategoryID = P.CategoryID)
> GROUP BY col
> Now, I presume that in your real-world case, you result set is not
> entirely static as here. In that case, you will have to play with
> dynamic SQL again.
> But before you rush ahead, have a look at http://www.rac4sql.net. This
> is a third-party tool which reportedly is very good for crosstabs and
> similar. I have never used it myself, but I've heard people speak
> positively about it.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pr...oads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodin...ions/books.mspx

Aggregate integrity problems

Has anyone else had any problems with cubes showing incorrect aggregates?
For instance, the sales for a Quarter is showing twice the amount of the 3
months showing. As well, there are values associated to products (lowest
level in dimension) that should not be there. When I re-process the cubes,
the issues are eventually resolved but I feel that I cannot trust any numbers
that the cubes show now.
Thanks in advance
Data Integrity starts at the souce and, once validated, is only maintained
through constraints.
The old adage applies here: Garbage In, Garbage Out.
I'd look at the integrity constraints of the primary sources. If those look
intact, I'd attempt to run manual queries to aggregate the data to see if any
anomolies show up. Finally, if all looks well, the next time some
abnormality shows up in the cube, instead of reprocessing, I'd look at the
source first to see if you could manually replicate the numbers.
I have not seen what you are describing except where there were data errors
in the sources. But if you feel that all has been checked out, I would most
certainly open up a PSS case.
Sincerely,
Anthony Thomas
"fastforward" wrote:

> Has anyone else had any problems with cubes showing incorrect aggregates?
> For instance, the sales for a Quarter is showing twice the amount of the 3
> months showing. As well, there are values associated to products (lowest
> level in dimension) that should not be there. When I re-process the cubes,
> the issues are eventually resolved but I feel that I cannot trust any numbers
> that the cubes show now.
> Thanks in advance
|||I agree, Garbage In, Garbage Out. I have experience more than I want to.
In this case however, the data is clean. It has been checked and double
checked. There are no problems with this set of data. Could this have
anything to do with how I have designed my aggregates or writeback issues?
"AnthonyThomas" wrote:
[vbcol=seagreen]
> Data Integrity starts at the souce and, once validated, is only maintained
> through constraints.
> The old adage applies here: Garbage In, Garbage Out.
> I'd look at the integrity constraints of the primary sources. If those look
> intact, I'd attempt to run manual queries to aggregate the data to see if any
> anomolies show up. Finally, if all looks well, the next time some
> abnormality shows up in the cube, instead of reprocessing, I'd look at the
> source first to see if you could manually replicate the numbers.
> I have not seen what you are describing except where there were data errors
> in the sources. But if you feel that all has been checked out, I would most
> certainly open up a PSS case.
> Sincerely,
>
> Anthony Thomas
>
> "fastforward" wrote:
|||Data integrity is always issue number one but if you've checked that out,
then logic comes next. I'd run the aggregate process manually on a few
deminsions with normal T-SQL aggregates. Then, most certainly, I would
consider a more simple design for your cubes to see if the problem clears up.
If so, I'd add complexity, one layer at a time.
If you continue to run into aggregations issues, I would most certainly
consider contacting MS PSS.
Sincerely,
Anthony Thomas
"fastforward" wrote:
[vbcol=seagreen]
> I agree, Garbage In, Garbage Out. I have experience more than I want to.
> In this case however, the data is clean. It has been checked and double
> checked. There are no problems with this set of data. Could this have
> anything to do with how I have designed my aggregates or writeback issues?
> "AnthonyThomas" wrote:

Aggregate integrity problems

Has anyone else had any problems with cubes showing incorrect aggregates?
For instance, the sales for a Quarter is showing twice the amount of the 3
months showing. As well, there are values associated to products (lowest
level in dimension) that should not be there. When I re-process the cubes,
the issues are eventually resolved but I feel that I cannot trust any numbers
that the cubes show now.
Thanks in advanceData Integrity starts at the souce and, once validated, is only maintained
through constraints.
The old adage applies here: Garbage In, Garbage Out.
I'd look at the integrity constraints of the primary sources. If those look
intact, I'd attempt to run manual queries to aggregate the data to see if any
anomolies show up. Finally, if all looks well, the next time some
abnormality shows up in the cube, instead of reprocessing, I'd look at the
source first to see if you could manually replicate the numbers.
I have not seen what you are describing except where there were data errors
in the sources. But if you feel that all has been checked out, I would most
certainly open up a PSS case.
Sincerely,
Anthony Thomas
"fastforward" wrote:
> Has anyone else had any problems with cubes showing incorrect aggregates?
> For instance, the sales for a Quarter is showing twice the amount of the 3
> months showing. As well, there are values associated to products (lowest
> level in dimension) that should not be there. When I re-process the cubes,
> the issues are eventually resolved but I feel that I cannot trust any numbers
> that the cubes show now.
> Thanks in advance|||I agree, Garbage In, Garbage Out. I have experience more than I want to.
In this case however, the data is clean. It has been checked and double
checked. There are no problems with this set of data. Could this have
anything to do with how I have designed my aggregates or writeback issues?
"AnthonyThomas" wrote:
> Data Integrity starts at the souce and, once validated, is only maintained
> through constraints.
> The old adage applies here: Garbage In, Garbage Out.
> I'd look at the integrity constraints of the primary sources. If those look
> intact, I'd attempt to run manual queries to aggregate the data to see if any
> anomolies show up. Finally, if all looks well, the next time some
> abnormality shows up in the cube, instead of reprocessing, I'd look at the
> source first to see if you could manually replicate the numbers.
> I have not seen what you are describing except where there were data errors
> in the sources. But if you feel that all has been checked out, I would most
> certainly open up a PSS case.
> Sincerely,
>
> Anthony Thomas
>
> "fastforward" wrote:
> > Has anyone else had any problems with cubes showing incorrect aggregates?
> > For instance, the sales for a Quarter is showing twice the amount of the 3
> > months showing. As well, there are values associated to products (lowest
> > level in dimension) that should not be there. When I re-process the cubes,
> > the issues are eventually resolved but I feel that I cannot trust any numbers
> > that the cubes show now.
> >
> > Thanks in advance|||Data integrity is always issue number one but if you've checked that out,
then logic comes next. I'd run the aggregate process manually on a few
deminsions with normal T-SQL aggregates. Then, most certainly, I would
consider a more simple design for your cubes to see if the problem clears up.
If so, I'd add complexity, one layer at a time.
If you continue to run into aggregations issues, I would most certainly
consider contacting MS PSS.
Sincerely,
Anthony Thomas
"fastforward" wrote:
> I agree, Garbage In, Garbage Out. I have experience more than I want to.
> In this case however, the data is clean. It has been checked and double
> checked. There are no problems with this set of data. Could this have
> anything to do with how I have designed my aggregates or writeback issues?
> "AnthonyThomas" wrote:
> > Data Integrity starts at the souce and, once validated, is only maintained
> > through constraints.
> >
> > The old adage applies here: Garbage In, Garbage Out.
> >
> > I'd look at the integrity constraints of the primary sources. If those look
> > intact, I'd attempt to run manual queries to aggregate the data to see if any
> > anomolies show up. Finally, if all looks well, the next time some
> > abnormality shows up in the cube, instead of reprocessing, I'd look at the
> > source first to see if you could manually replicate the numbers.
> >
> > I have not seen what you are describing except where there were data errors
> > in the sources. But if you feel that all has been checked out, I would most
> > certainly open up a PSS case.
> >
> > Sincerely,
> >
> >
> > Anthony Thomas
> >
> >
> > "fastforward" wrote:
> >
> > > Has anyone else had any problems with cubes showing incorrect aggregates?
> > > For instance, the sales for a Quarter is showing twice the amount of the 3
> > > months showing. As well, there are values associated to products (lowest
> > > level in dimension) that should not be there. When I re-process the cubes,
> > > the issues are eventually resolved but I feel that I cannot trust any numbers
> > > that the cubes show now.
> > >
> > > Thanks in advance

Aggregate integrity problems

Has anyone else had any problems with cubes showing incorrect aggregates?
For instance, the sales for a Quarter is showing twice the amount of the 3
months showing. As well, there are values associated to products (lowest
level in dimension) that should not be there. When I re-process the cubes,
the issues are eventually resolved but I feel that I cannot trust any number
s
that the cubes show now.
Thanks in advanceData Integrity starts at the souce and, once validated, is only maintained
through constraints.
The old adage applies here: Garbage In, Garbage Out.
I'd look at the integrity constraints of the primary sources. If those look
intact, I'd attempt to run manual queries to aggregate the data to see if an
y
anomolies show up. Finally, if all looks well, the next time some
abnormality shows up in the cube, instead of reprocessing, I'd look at the
source first to see if you could manually replicate the numbers.
I have not seen what you are describing except where there were data errors
in the sources. But if you feel that all has been checked out, I would most
certainly open up a PSS case.
Sincerely,
Anthony Thomas
"fastforward" wrote:

> Has anyone else had any problems with cubes showing incorrect aggregates?
> For instance, the sales for a Quarter is showing twice the amount of the 3
> months showing. As well, there are values associated to products (lowest
> level in dimension) that should not be there. When I re-process the cubes
,
> the issues are eventually resolved but I feel that I cannot trust any numb
ers
> that the cubes show now.
> Thanks in advance|||I agree, Garbage In, Garbage Out. I have experience more than I want to.
In this case however, the data is clean. It has been checked and double
checked. There are no problems with this set of data. Could this have
anything to do with how I have designed my aggregates or writeback issues?
"AnthonyThomas" wrote:
[vbcol=seagreen]
> Data Integrity starts at the souce and, once validated, is only maintained
> through constraints.
> The old adage applies here: Garbage In, Garbage Out.
> I'd look at the integrity constraints of the primary sources. If those lo
ok
> intact, I'd attempt to run manual queries to aggregate the data to see if
any
> anomolies show up. Finally, if all looks well, the next time some
> abnormality shows up in the cube, instead of reprocessing, I'd look at the
> source first to see if you could manually replicate the numbers.
> I have not seen what you are describing except where there were data error
s
> in the sources. But if you feel that all has been checked out, I would mo
st
> certainly open up a PSS case.
> Sincerely,
>
> Anthony Thomas
>
> "fastforward" wrote:
>|||Data integrity is always issue number one but if you've checked that out,
then logic comes next. I'd run the aggregate process manually on a few
deminsions with normal T-SQL aggregates. Then, most certainly, I would
consider a more simple design for your cubes to see if the problem clears up
.
If so, I'd add complexity, one layer at a time.
If you continue to run into aggregations issues, I would most certainly
consider contacting MS PSS.
Sincerely,
Anthony Thomas
"fastforward" wrote:
[vbcol=seagreen]
> I agree, Garbage In, Garbage Out. I have experience more than I want to.
> In this case however, the data is clean. It has been checked and double
> checked. There are no problems with this set of data. Could this have
> anything to do with how I have designed my aggregates or writeback issues?
> "AnthonyThomas" wrote:
>

Saturday, February 25, 2012

Aggr

Hi,

What I want is to to get SUM of col1 and list quarter data when
applicable.

DDL:
create table #temp (col1 int, rent int, transport int, qtr smallint,
other int);

DML:
insert into #temp
values(1, 800, 300, 1, 200)

insert into #temp
values(1, 800, 300, 2, 300)

insert into #temp
values(2, 800, 300, 2, 400)

Data retrieval DML:
select col1, sum(other) as other_Total, case when qtr = 1 then
sum(other) end qtr_total
from #temp
group by col1,qtr

Current Resultset:
col1 other_Total qtr_total
---- ---- ----
1 200 200
1 300 NULL
2 400 NULL

Desirable Resultset: (get ride of the middle row above and add up the
200 and 300), so, it would look like
col1 other_Total qtr_total
---- ---- ----
1 500 200
2 400 NULL

What am I missing here?

TIA.SELECT col1, SUM(other) AS other_total,
SUM(CASE WHEN qtr = 1 THEN other END) qtr_total
FROM #temp
GROUP BY col1

--
David Portas
SQL Server MVP
--|||Thank you, David.

Don