Hi i m new to SSAS 2005/08. I want to create Cube from 1 table , Stored in OLTP Database. Table containg billions of records.
how to select dimension and Fact from this alone table.
Please help me.
A dimension derived from data in the fact table is known as a degenerate dimension:
http://en.wikipedia.org/wiki/Degenerate_dimension
Here's a link discussing how to model an data as both a dimension and fact attribute, if that's what you're wanting to do:
http://www.ralphkimball.com/html/07dt/KU97ModelingDataBothFactDimen.pdf
Related
I have a view in my sqlserver database,but now,I want to build a data cube instead of the view,aim to more select efficiency.
the view design picture.
two tables connect and select many column in this view.NOW,the trouble is in data cube, you have to have at least one measure table, But I just hope regards the two fact table as dimension table,so that I can get the similar output as the view.
Is there any help or other way? thanks!
It's not recommended, and I suggest you to keep an eye on star schema modelisation.
https://en.wikipedia.org/wiki/Star_schema
But If you want to add your tables in a cube you will need to duplicate it.
two tables will be used to create your measures (Aggregation, Sum, Count, Comparison, ...)
two other tables will be used to create your dimensions (Attributes, filters, ...)
I drew a small model for you
From Table1 (Dimension) and Table1 (Fact) your key will be facttable1.ID
and From Table1 (Dimension) and Table1 (Fact) your key will be your Foreign key
Does it help you?
Regards,
Arnaud
You need to create at least 1 dimension: for your case you can create New Named Query based on your view using ID as Key-Attribute for Dimension.
I am trying to use this to learn how about data warehousing and having trouble understanding the concept of the fact table.
http://www.codeproject.com/Articles/652108/Create-First-Data-WareHouse
What would be some queries that I could run to find information from the faceable, and what questions do they answer.
A fact table is used in the dimensional model in data warehouse design. A fact table is found at the center of a star schema or snowflake schema surrounded by dimension tables.
A fact table consists of facts of a particular business process e.g., sales revenue by month by product. Facts are also known as measurements or metrics. A fact table record captures a measurement or a metric.
Example of fact table -
In the schema below, we have a fact table FACT_SALES that has a grain which gives us a number of units sold by date, by store and by product.
All other tables such as DIM_DATE, DIM_STORE and DIM_PRODUCT are dimensions tables. This schema is known as the star schema.
Let's translate this a bit.
Firstly, in a fact table we usually enter numeric values ( rarely Strings , char's ,or other data types).
The purpose of a fact table is to connect with the KEYS of dimensional tables ,other fact tables (fact tables more rarely, and also not a good practice) AND measurements ( and by measurements I mean numbers that change frequently like Prices , Quantities , etc.).
Let's take an example:
Think about a row from a fact table as an product from a supermarket when you pass it by the check out and it get's scanned. What will be displayed in the check out row in your database fact table? Possibly:
Product_ID | ProductName | CustomerID | CustomerName | InventoryID | StoreID | StaffID | Price | Quantity ... etc.
So all those Keys and measurements are bringed together in one fact table, having some big performance and understandability advantage.
Fact Table Contain all Primary key of Dimension table and Measure like "Sales Amount"
A Fact table is a table that stores your measurements of a business process. Here you would record numeric values that apply to an event like a sale in a store. It is surrounded by dimension tables which give the measurement context (which store? which product? which date?).
Using the dimensions you can ask lots of questions of your facts, like how many of a particular product have been sold each month in a region.
Some further info
All dimension keys in a fact should be a FK to the dimension
if a key is unknown it should point to a zero key in the dimension detaialing this.
All joins from a fact to a dim are 1 to 1. bridge tables are is a technique to cater for many to many's, but this is more advanced
All measurements in a fact are numeric, but can contain NULLS if unknown (never put 0 to represent unknown)
When joining facts to dimensions there is no need to do an outer join, due to FKS applied above.
if you have 999 rows in a fact, no matter what dimensions you join to, you should always have 999 rows returned.
I have a model developed in Tabular 2012. When I connect to the cube, I see FACT and DIMENSION tables listed.
I am not a developer - I am just asked to test the data load.
I just need to locate an example record from my source DB in FACT( Or Dimension ) table in the cube. I goggled it well, but could not find anything relevant as the the MDX queries I explored were always using some [Measure].blah blah to retrieve the data. Developer has defined just 1 measure in the DB. Is it possible to retrieve 1 row using MDX just like select 8 from table in SQL?
My problem is that even if I put one fact column on the columns axis and dimension key on row- axis, it just retrieves value 1.
I was under the impression that tabular did not have multi-demnsional cubes but has a "tabular model" as the underlying structure.
If you are using mdx and want several columns of data with just one measure then use CROSSJOIN:
SELECT
[Measures].[X] ON COLUMNS,
{CROSSJOIN (
[Dimension1].[someLevel].members
,[Dimension1].[someLevel].members
,[Dimension1].[someLevel].members
,[Dimension1].[someLevel].members) }
ON ROWS
FROM [cubeName]
Alternative syntax is:
SELECT
[Measures].[X] ON COLUMNS,
[Dimension1].[someLevel].members
*[Dimension2].[someLevel].members
*[Dimension3].[someLevel].members
*[Dimension4].[someLevel].members
ON ROWS
FROM [cubeName]
Can Dimension Table became a fact table as well? For instance, I have a Customer dimension table with standard attributes such as name, gender, etc.
I need to know how many customers were created today, last month, last year etc. using SSAS.
I could create faceless fact table with customer key and date key or I could use the same customer dimension table because it has both keys already.
Is it normal to use Customer Dimension table as both Fact & Dimension?
Thanks
Yes, you can use a dimension table as fact table as well. In your case, you would just have a single measure which would be the count - assuming there is one record per customer in this customer table. In case you would have more than one record per customer, e. g. as you use a complex slowly changing dimension logic, you would use a distinct count.
Given your example, it is sufficient to run the query directly against the Customer dimension. There is no need to create another table to do that, such as a fact table. In fact it would be a bad idea to do that because you would have to maintain it every day. It is simpler just to run the query on the fly as long as you have time attributes in the customer table itself. In a sense you are using a dimension as a fact but, after all, data is data and can be queried as need be.
I have these 2 tables and I need to create a relationship between them so that I can import them into SSAS Tabular and run some analysis.
The first table has RollingQuarter(Moving Quarter) data. The second is a basic Date table with Date as PK.
Can anyone suggest ways to create a relationship with these?
Ill be using SQL Server 2012.
I could re-create a new date table also.
I think you may have a rough time finding a relationship with these tables.
Your top data table is derived data. It's an average over three months, reported monthly. The Quantity column applies to that window, not to a particular date like all of the stuff in the second table. So what would any relationship really mean?
If you have the primary data that were used to calculate your moving average, then use those instead. Then you can relate dates between the two tables.
But if your analysis is such that you don't need the primary data for the top table, then just pick the middle of each quarter (March 15th 2001 for the first record) and use that as your independent variable for your time series on the top. Then you can relate them by that.