March 2, 2013 at 6:40 am
Hi Richykong
thanks for the feedback.
Are you saying that I need to have a database on my database engine? As you may know, I already have 2 databases on the analysis server. For example, Adventure Works DW 2008R2.abf was downloaded and restored to AdventureWorksDW2008R2 on my analysis server(first database), as per the previous attachment. Then, a project was created to import the database by using the 'import an existing SQL Server Analysis Services database' (namely AdventureWorksDW2008R2). This created a database called 'Analysis Services Project 2' on the analysis server (also visible in the attachment). So that is a total of 2 identical databases on the analysis server. I think you are suggesting that I only need one database on the analysis server, which you refer to as the 'analysis services database'.
I think you are suggesting that I create a 2nd database, that resides on the database engine and that is what you refer to as the 'Adventure Works DW SQL database'.
Q1: Where do I find/download the 'Adventure Works DW SQL database'. Does it need to be 'paired' with a particular Adventure Works DW 2008R2.abf. By 'paired', I mean, for the Adventure Works DW 2008R2.abf I have restored to the analysis server, is there a specific 'Adventure Works DW SQL database'? I found http://msftdbprodsamples.codeplex.com/releases/view/59211 which lists lots of different download links but I think I need the link :-
AdventureWorksDW2008R2 Data File source code, 74944K, uploaded Apr 3, 2012
-which downloads Adventure Works DW 2008R2.mdf
Please confirm?
Q2: I am not clear on what you mean by 'When you import the Analysis Services database in BIDS, make sure you set the deployment properties of the project and point it to the server you want to deploy this too. Also make sure you verify the Data Source connection is valid and the impersonation is set to a login that has access to the SQL database.'. I think you are saying, once the 'Adventure Works DW SQL database' is installed on my database engine, the data source connection should be pointing to this database and NOT pointing to the Adventure Works DW 2008R2.abf that I have restored to the analysis server. Please confirm?
Q3: Currently, I have 2 identical databases on the analysis server. Do I need both the identical databases on the analysis server? I am struggling to understand why the project 'Analysis Services Project 2' needed to duplicate the original database - I suspect I didnt need to create a project in this manner but my thinking was that this was how you gained access to the cube definitions that come out of the box with the .abf file i.e by creating a project. I suspect that I should just rename 'Analysis Services Project 2', something like 'out of the box AW DW', so that I will always have a project that works, (assuming that I can get it to deploy without errors).
It should be noted that all the databases and servers (engine and analysis) reside on a single pc, to which I have administrator rights and I intend to impersonate as myself in all data source connections. This is a development environment and so I have scope to configure all aspects of the environment, if required.
I am new to SSAS but my understanding NOW is that the way it works is - that if you were starting from scratch trying to create a cube for say a regular production database in the engine(DB1), you then use BIDS to create an analysis server project that uses the DB1 as a data source. You then create cubes, dimensions etc within the project whereby the data source, cubes, dimensions etc get stored in a database on the analysis server (DB2). When data changes occur in the DB1 database and an individual subsequently runs a cube report, it will use the properties of the cube in the DB2 database to drive the functionality of the report and connect to DB1 (using an impersonating account) to retrieve the raw data from DB1.
Any insights greatly appreciated!
Regards Anthony
March 2, 2013 at 12:22 pm
Q1. This should give you the mdf and ldf you need for the SQL database.
http://adventureworksdw2008.codeplex.com/
Q2. Yes, the datasource should be connecting to the SQL database that was just attached. If you right click the project and go to the properties, you should see an option for deployment where you can define the server and Analysis Services database name you want to the deploy this project as.
Q3. Importing is the way to get a copy of a deployed SSAS database. If you just wanted to look at the code, you can connect directly to an existing SSAS database. In BIDS, File > Open > Analysis Services Database (or something named similar) and it'll ask for the server and database you want to connect to. This will open the live SSAS database. Any changes you save will be applied directly to the database on the server.
Overview of SSAS (MOLAP). (Molap is the storage setting in which structure and aggregate data is stored in the SSAS databse.)
SSAS is essentially an aggregated view of underlying SQL data. The storage of data in SSAS when using MOLAP can be thought of as massive complex indexes. All the definitions you create in the SSAS database are just indexes. To process and update these indexes, you have connect the SSAS objects (Measures and Dimensions) to the underlying data tables from the SQL database. The SQL table DimDate has all the dates in all the different formats you would want to see it. In SSAS, the Date(Time) dimension references the DimDate table and defines which columns are used and the format. SSAS dimension also allows you to define a hierarchy of the data. The SQL fact tables are used in the MeasureGroups of the SSAS database and the aggregation logic (SUM,MIN,...) is used to determine how that field is used. You can also define the relationship between the fact data and the dim data in the Cube.
The first step of a SSAS solution would be define the SQL data warehouse. The SQL data warehouse would usually be a star schema dimensional data model populated from your source system data. Once you create the data warehouse with Fact tables and Dimension tables, you can start creating your SSAS database.
1. Create an SSAS solution. Right click on the projcet (databse) and you should have a popup with Deployment configuration. Make sure you are deploying to the SSAS server you have access to and define the SSAS database name you want it deployed as.
2. Create a data source connecting to the data warehouse. Make sure you configure the impersonation settings correctly for processing after deployment.
3. Create a data source view from the data source you just created and import the fact and dimension tables.
4. Create a dimension for each of the dimension tables.
5. Create a Cube with measure groups using the fact tables.
6. Go to the Dimensions tab in the Cube and make sure dimensions are mapped to the fact. (If the relationship between fact and dimension are defined in the dsv, the connection should have been automatically created.) If a dimension is missing, right click and add the dimension. Make sure fact and dimension relationships are defined.
7. Deploy and process.
What happens at this point is:
The SSAS database definition will attempt create/alter objects on the SSAS server and database you defined in step 1.
Once the objects are deployed, it will attempt to process the data. Processing of the data entails selecting the fact and dimension data from the data warehouse tables and aggregating and storing it in the SSAS database.
I hope this all makes sense and helps. It's a Saturday and my mind is not at 100%.
May 30, 2013 at 10:26 am
its very help full to me
i was trying from long time
Thanks ,,,,
Regards
Arjun
October 10, 2013 at 10:43 pm
it works!!! thanks yulia, you are a life saver.
October 14, 2013 at 2:20 am
The answer to grant blanco rights to Network Service may still help people, but it is still wrong. On production servers, this is definitely NOT best practice. You should start with non-builtin service accounts and then grant minimum rights to the SSAS data sources either via that service account or individually via impersonation, like hinted at before.
November 19, 2013 at 8:55 am
Adding all rights is ok for my sandbox environment, but what is the best practice for assigning rights and permissions to SSAS in a production environment?
What are people doing out there that is considered the safe norm?
Thanks,
Andre Ranieri
February 20, 2015 at 3:00 am
Changing the server role of the NT AUTHORITY\SYSTEM account to sysadmin cured the login error.
I now get an error 'A connection could not be made to thedata source with the DataSourceID of 'Adventure Works DW2012'.
Can anyone help with this ?
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply