I am working on a simple project using SSAS Cube on SQL Server 2016 and SSDT2015. DW_Orders database is from Orders DW. The table factor orders contains attributes UnitPrice, Quantity and Discount with the calculation member TotalSale defined as [Measures].[Unit Price][Measures].[Quantity](1-[Measures].[Discount]), well as the FK members CustomerID and OrgID. I want to get the TotalSale based on Country-City Hierarchy from dimension dimCustomers. But I got the following result:
enter image description here
it is obvious that the UnitPrice, Quantity and Discount have been summed under the city or country so that we got wrong and negative result of TotalSale from the calculation. Tried in the Edit Measure, cannot get what I expect. Need your help on some settings, thanks.
You need to edit the aggregation type for the 2 measures(discount and unit price). By default, the type is SUM, you need to use Average. To do that, go to the measure group, select the measure and access its properties to set the aggregation.
I am a newb when it comes to MDX so please bear with me as I try to explain this.
I have cube with a measure for cost [Measure].[Cost] and the query is setup with a time parameter to obtain the total cost up to that point in time. #ToAcctDate and is used in the FROM statement as such:
FROM (SELECT (STROSET(#ToAcctDate, CONSTRAINED)) ON COLUMNS
but I would like to get the PREVIOUSMEMBER if possible and to something like
WITH
MEMBER [Measures].[PriorPeriod] AS
SUM( (STROSET(STROSET(#ToAcctDate, CONSTRAINED).PREVMEMBER), [Measures].[Cost])
so that I can then have both the YTD costs as of #ToAcctDate and the YTD Costs at the beginning of the period [Measures].[PriorPeriod] in the same query without unions. is this possible? and if so, is this the right approach?
Maybe along the lines of this?
HEAD will find the first member of the set which you can then apply PREVMEMBER to:
SUM(
HEAD(STROSET(#ToAcctDate, CONSTRAINED)).ITEM(0).ITEM(0).PREVMEMBER)
, [Measures].[Cost]
)
I would like to count all clients accounts in my cube. I have created new calculation and I wrote a query in MDX langugage like:
COUNT(
[Client].[IdClient]
)
but when I would like to know how many accounts have, I always get '1' value instead e.g. '6000'.
This is my first time with MDX and OLAP Cubes.
What I supposed to do to get correct value?
Try this:
COUNT(
EXISTING [Client].[IdClient].[IdClient].Members
)
If you aren't happy with the performance of that then delete the calculated measure and replace it with a measure group built on the Client table. Build a Count measure.
I have a calculated measure that needs to cross join Customer and Product dimension then cross join a total sales measure to get a percentage for a specific customer sale.
[Measures].[Sale Value] / [Measures].[Total Sales]
each measure has a link to the time dimension, and are set to last non empty.
The problem is that as I look at more information over longer periods (days, months, years etc) it gets slower and slower and slower. I am assuming this is because the calculated measure does its processing on the fly and there is no caching.
Is this correct? I have about 2000 customers and 50 products.
Please please help! any information about how to speed this up would be great.
The answer to this was to set a many to many relationship between Customer/Prodcut and the [Measures].[Total Sales] measure group.
I am looking for the best way to structure my database. I have quarterly financial statements for 1000’s of companies from 1997-2012. Each company has three different statements, an income statement, a balance sheet, and a cash flow statement.
I want to be able to perform calculations on the data such as adding up each quarter to get a yearly total for each line item on each statement.
I have tried two ways so far:
1) Storing each line item for each statement in it’s own table i.e. Sales would be one table and have only sales data for all companies I am tracking, with company as the primary key, and each quarters data as a separate column. This seems like the easiest way to work with the data, but updating the data each quarter is time consuming as there are hundreds of tables.
Sales Table
Company q32012 q22012 q12012
ABC Co. 500 100 202
XYZ Co. 230 302 202
2) The other option which is a little easier to update but harder to work with the data is to have a separate table for each company for each statement. For example, the income statement for Royal Bank would have it’s own table, with the primary column being the line item.
Income Statement for Royal Bank
Line_Item q32012 q22012 q12012
Sales
Net Profit
The problem here is when I try to annualize this data, I get a really ugly output due to the group by
SELECT
(CASE WHEN Line_Item = 'Sales' THEN SUM(q4 + q3 + q2 + q1) ELSE '0' END) AS Sales2012,
(CASE WHEN Line_Item = 'NetProfit' THEN SUM(q4 + q3 + q2 + q1)
ELSE '0' END) AS Inventories2012
FROM dbo.[RoyalBankIncomeStatement]
GROUP BY Line_Item
Any help would be appreciated.
Whenever I've had to build a database for fiscal reports by fiscal quarter, month, or year or whatever, I've found it convenient to borrow a concept from star schema design and data warehousing, even if I'm not really building a DW.
The borrowed concept is to have a table, let's call it ALMANAC, that has one row for each date, keyed by the date. In this case a natural key works out well. Dependent attributes in here can be what fiscal month and quarter the date belongs to, whether the date was one where the enterprise was open for business (TRUE or FALSE), and whatever other quirks are in the company calendar.
Then, you need a computer program that just generates this table out of nothing. All the strange rules for the company calendar are embedded in this one program. The ALMANAC can cover a ten year period in a little over 3,650 rows. That's a tiny table.
Now every date in the operational data can be used like a foreign key into the ALMANAC table, provided you consistently use the Date datatype for dates. For example, each sale has a date of sale. Then aggregating by fiscal quarter, or fiscal year, or whatever you like is just a matter of joining operational data with the ALMANAC, and using GROUP BY and SUM() to get the aggregate you want.
It's simple, and it makes generating a whole raft of time period reports a breeze.
My advice to you is to think about not using a SQL database to do this. Instead, think of using something like SQL Server Analysis Services (SSAS). If you want to get a quick start with SSAS, I recommend getting up to speed on PowerPivot for Excel. You can take the model you develop in PowerPivot and import it into SSAS when you're ready.
Why don't I recommend SQL? Because you're going to have a problem aggregating accounts in SQL Server. For example, your balance sheets aren't going to be something you're going to be able to aggregate easily in SQL -- Asking SQL Server for the "Cash" for 2010, for example means that you want to get the entry for the end of December 2010, not that you want to SUM all of the entries for Cash for that year (which would be a nonsense number). On the other hand, with income and expense accounts such as those which would appear on your income statements, you would want to SUM those values up. To make matters worse, some reports are going to have a mix of account types on them, which is going to make reporting quite difficult.
SSAS has provisions inside the product where it "knows" how to aggregate for your reports based on account type, and there are many tutorials out there which can show you how to set this up.
Either way, you're going to need to store your data somewhere before it goes into your reporting system or Analysis Services cube. In order to do that, you should structure your data something like this. Let's say you're storing your data in a table called Reports:
Reports
--------
[Effective Date]
[CompanyID]
[AccountID]
[Amount]
Your Account table would have the description of what you're trying to store (income, expenses, etc). Your [Effective Date] column would link back into a Dates table which describes to which year, quarter, etc., your data belongs. In essence, what I'm describing is a classic shape for reporting databases, called a star schema.
I would probably go with the following structure in one data table:
Company
StatementType
LineItem
FiscalYear
Q1, Q2, Q3, Q4
StatementType would be Income Statement, Balance Sheet or Cash Flow Statement. Line Item would be the coded/uncoded text of the item on the statement, Fiscal Year is 2012, 2011 and so on. You'd still need to make sure that Line Items are consistent across companies.
This structure would let you query for flat statement -
select
LineItem, Q1, Q2, Q3, Q4
from Data
where
Company = 'RoyalBank'
and FiscalYear = 2012
and StatementType = 'Income Statement'
or
QoQ
select
FiscalYear,
Q1
from Data
where
Company = 'Royal Bank'
and
StatementType = 'Income Statement'
and
LineItem = 'Sales'
order by FiscalYear
in addition to aggregates. You'd probably want to have another table for line items with some kind of an index reference to make sure you can pull the statement back in the original order of line items.