Why doesn't quantity group by dimension? - ssas

Very simple question.
I have created a multi-dimensional model for SQL Server Analysis Services in Visual Studio. But I can't get why my relations in data model don't work.
For example
this is how relations look like
see data relations model
Sales is related to Item-Current on [WWI Stock Item ID]
It should work.
But when I try to calculate [Sales].[Quantity] by [Items-Current].[Color], I get a wrong result.
see wrong result
What did I do wrong?
Thank you.

I think that the issue is that your dimension key is different than the key used to link it with the fact (Dimension Key = Stock Item Key, Dimension attribute that is used to link with fact: WWI Stock Item ID). That is why it is not linking properly. you can solve this in 2 ways:
1 Make WWI Stock Item ID your dimension's primary key
2 In the dimension attribute relationships, connect the color attribute to WWI Stock Item ID and remove the relationship between color and Stock Item Key)

Related

Understanding the Cube display in SQL Studio Manager

I have built a small data warehouse using the Adventure works database. I have deployed it to SQL Studio Manager. I have written my first MDX query
select
customer.[full name].members on rows,
order (measures.[sales amount],asc) on columns
from [Adventure Works DW2012]
Please see the screenshot below:
I understand that the top level of the hierarchy are dimensions i.e. Customer, Date, Due Date, Interne Sales, Order Date, Product and Ship Date. I understand that dimensions have attributes. For example: Model Name, Product Line, Product Name are attributes of the Product dimension and Product Model Lines is a hierarchy of the Product dimension.
What is meant by: Financial; History and Stocking?
You've come up against something I think is a genuinely confusing and ill-designed aspect of SSAS.
You're correct that Model Name, Product Line and Product Name are attributes of the Product dimension. But what you're seeing here (in your screenshot) is hierarchies called Model Name, Product Line and Product Name.
These are not "hierarchies" in the sense that most people use the term (a structure with more than one level). They're the "attribute hierarchies" based on the attributes of the same name. They only have one level two levels. (EDIT: as whytheq pointed out, they have one leaf level, and almost always also have an "All" level).
(EDIT) Product Model Lines is a "real" (aka "user") hierarchy, with multiple levels apart from the All and leaf levels, based on multiple attributes.
Financial, History and Stocking are "folders". They get "created" by the setting of any AttributeHierarchyDisplayFolder property of any Attribute in the Dimension design (or the DisplayFolder property of any "real" hierarchy). They have nothing to do with any dimension structure - they're just for display convenience. Probably necessary because, as becomes clearer the more I try to explain it, the structure of Dimensions in SSAS is really unnecessarily complicated.
You can hide the "attribute hierarchies" from client applications (e.g. Excel) by setting the AttributeHierarchyVisible property of the attribute to False. But they'll still show up in the MDX "helper" screen you're looking at.

How to work with map property in RQL (Oracle's ATG Web Commerce)

We use Oracle's ATG Web Commerce for our project. And currently we need construct RQL query which obtain products which SKU's tacticalTradeStatuses contains certain status and ordered by status value.
I briefly describe the relationship between entities: Product item descriptor contains list of SKUs. Each SKU contains map tacticalTradeStatuses (key - tactical trade status, value - sequense)
For example, how to obtain all products which SKU's tacticalTradeStatuses property contains key 'BEST_SELLER' and ordered by value associated with key 'BEST_SELLER'.
Key by which we want to select products we want to pass as RQL parameter.
i have two ways to doing that
1) first create a query which fetches all the product based on map key BEST_SELLER
2) Now pass it to foreach droplet and add sort properties. which help to sort the result based on your requirements
for sorting please refer to below link
http://docs.oracle.com/cd/E23095_01/Platform.93/PageDevGuide/html/s1316foreach01.html
2 way i think is to use query options in RQLStatement.. which work same as sort properties in for each
If you provide some XML Repository structure that will be good..hope it will help you

SQL OLAP Cube and dimension

In a windows Server 2008, using SQL server 2005, Visual Studio and SQL Server Analysis Services i created an OLAP Cube.
The scenario is a typical store with sell products, customer and agents.
The cube is made by a fact table tblVendite (sell data) and dimensions based on sql views.
NOTE: I tried embed the screenshot here but they will resized and will not clear so i posted them in a safe site to view it:
SCREENSHOT: stucture of the cube
FACT TABLE tblVendite (sell) > PK: CdArticolo (IDProduct)
DIMENSION Prodotti (produtcs)
DIMENSION Calendario (calendar)
DIMENSION Agenti (agents)
DIMENSION Clienti (customer)
Browsing the cube with basic filters as calendar, customer/agent, products, brand ... all work fine
Now i need to provide a new feature as:
Comparing the "top sell brand" of all company with the sell of each agent to see how he sell those brand
So i did a new table and the related view: vwMarcheOrd (top sell brand)
The table top sell brand is pre-populated by a sp and contain 1 record for each brand (CdMarca - Position - Description order by Position)
NOTE: from vwMarcheOrd i cant have direct link to the fact table because the PK is CdMarca and it's not present so i need to "bridge" the view Products by CdMarca and get the CdArticolo to link the fact table
Dimension and the attributes for Brand and Top Brand:
SCREENSHOT: cube dimension
BROWSE THE CUBE AND THE PROBLEM
Adding the dimension Brand(1) to the row fields the result is correct but if i add the Top Brand(2) is incorrect and many brand are missing (but they exist)
SCREENSHOT: browse Top Brand
So my questions are 2:
What i missing or wrong or misunderstand with the Top Brand Dimension ?
How i can display all records of Top Brand in the row fields even if the agent didnt sell any item of that brand (blank row) ?
p.s. i tried also make a dimension based only with vMarcheOrd and then create a Referenced Relationship with the Product table to bridge CdMarca > CdArticolo > Fact Table but the result are the same
Thanks in advance who can really help me to solve this problem that block me since many days
From what I understand, it looks like the top brand could change over time. This means that you would need to somehow track that over time. In my opnion, the easiest way to do that would be to add the TopBrandKey to the fact table and join the top brand dimension directly to the fact table. This way the time tracking is done for you in the fact table. As new records come in, you would look up the key for the top brand and add that to the fact table. I don't think the way you have it would work because the product which was sold would not have the brand which is the top brand (those are two different things).
ciao luka :)
it seems to me that you don't have the proper attribute relationship between the attributes on your cube.
I see you are using BIDS 2005, which I'm not very familiar with it (it would be easier to help on 2008), but what you have to do is set the relations between Prodoti -> Brand -> top brand
you can do that by those + signs on the attributes bellow the dimension name.

Modeling products pricing structure

I need to model a rather complex pricing structure for some of our products.
Today we lookup the prices manually. Here's a picture with explanations of the "matrix" that we use today: Sample model (sorry for the link - but I'm not allowed to post images because I've just opened my account.)
Now I need to transfer this model to a RDBMS system (SQL Server 2008 R2). The entry point when looking up a price is the Category, then the yearly interval and finally the interval depending on how many products we're selling on this order. The result of the query should be two prices.
Do you have any suggestions on how to model this? I was thinking of modeling it as a matrix with a RowNumber, CellNumber and a CellValue. But then I need another table for describing what is contained in each cell (by referencing the row and cell numbers). If doing that, I could just include the prices in that description table. But that doesn't seem like the best solution.
Do you have any hints/solutions on how to model this problem the best way?
I think I would make something like this:
Categories are separated into its own table.
Each row in the price table are uniquely identified by the category and starting point of the sold and shipped range. I don't think you would need to specify ending point in the table (since the end point of a range should be the starting point of the next range minus one).
Edit: With this model, you will need to add a row in the Prices table for each combination of category, units sold-interval and units shipped-interval, but right now I can't think of an easier way.

Implicit Fact division and Dimension Usage

I have a star schema with Implicit Fact division as shown in Figure 5 at http://www.information-management.com/infodirect/20020308/4858-1.html?pg=2.
My question is how do I set up the Dimension Usage? My first thought was to set up 3 Referenced Relationships (CustomerGroup to InvoiceItemFacts, GroupToCustomer to CustomerGroup, CustomerDimension to GroupToCustomer), but when I try this I get the message "A loop was found in the data source view at the 'dbo_CustomerGroup' table".
Update:
I have found that if I create a Regular Relationship between GroupToCustomer and InvoiceItemFacts (effectively by passing the CustomerGroup table because I already have the Customer Group Key) I can get some results. However, when I browse the cube and display the InvoiceItemFacts by Customer, the InvoiceItemFacts only display on the first Customer in the group.
GroupToCustomer looks to be a "Fact-less Fact Table", so you would create a measuregroup on that, doesn't need to be visible to the end users, then do a Many-Many join via that fact in the dimension usage tab.
It's a little complicated by the extra table in the way, but that should be the approach.