We have a table with 20M+ records and growing in SQL Server.Our users want to access this table and slice and dice the data preferably using pivot tables.
What is the best way to go about this? We don't have any tools per se in-house except for SSAS. So thinking of create a cube off a single table and giving the users an excel linked file.
Is this a good approach? Are there any other options?
TIA,
Bee
Update:
I apologize I forgot to add that I did try giving the users a Power Pivot file - but it showed up blank when they opened it (oops!). Plus they indicated that they prefer not to use power pivots.
We also have SSAS in-house but Multi-dimensional services. I was hoping to use SSAS tabular until I read that we cannot host both Tabular & MDS in one server. Hence the question.
Thanks again.
The excel option is the only best option. You can slice and dice in pivot table easily.
Related
I'm trying to build a report off the cubes we've built in SSAS, and I've found this documentation for DMV and MDX queries, but I can't find what I want. It can return the dimension names as seen in SSAS, but I want the table name as seen in SQL Server, i.e. if we have a table called billingLocation in the database I want that instead of Billing Location which is how it's seen in SSAS. Is this possible?
As an aside, can you pull fact tables from the same query type? I only see information about pulling dimensions.
Maybe it's too late but you can use LEFT(Column_Name,X) to get some characters. Could be useful
There is not an existed DMV in SSAS to load the dsv name of a measure group or dimension which related Cube schema. I think you have to create a program and connect to SSAS server with AMO.NET to get these information by yourself.
But there is an IDE to get these info and allow you to export to excel, it is not free(30 days free trial): MDXHelper, www.mdx-helper.com.
Hope this help you. Thanks.
Is there a native solution/application/script for creating documentation in Power BI? I am especially interested in documenting all relationships.
Power BI Models (and the new Tabular Models) have DMVs that are separate from the MDSCHEMA rowsets for SSAS multidimensional. While some of the SSAS MD DMVs mostly work, the new TMSchema DMVs work well since they are made specifically for this type of model. The trick is that you must know the connection info. The port and database number change each time you open Power BI Desktop. But generating documentation can be done.
There are a couple of ways to go about it. You can use DAX Studio to get your connection info (a la Chris Webb). Or you can get that info dynamically from Power BI (a la The BIccountant). Using DAX Studio works as a one-time way to get documentation, or if you are ok updating the connection and database info each time you want to run it. The BIccountant way is more dynamic. I haven't tried it, but it looks promising.
To get relationships, you can get your connection info for your Power BI model and then run queries against the following DMVs:
$System.TMSCHEMA_RELATIONSHIPS
$System.TMSCHEMA_TABLES
$System.TMSCHEMA_COLUMNS
Pull those down into Power BI (either in the same model you are documenting, or in a different model). Then either
A) Use the Edit Queries functionality to merge the queries to add the Name column from the Tables DMV and the Explicit Name column from the Columns DMV based upon FromTableID, FromColumnID, ToTableID, ToColumnID.
B) Create relationships between these columns using the modeling functionality of Power BI to achieve the same affect.
Once you've done this and cleaned up column names, hidden/deleted unused fields, you can then use Power BI to create your documentation. You can create plain tables and/or use something like a force-directed graph to show relationships. Here's a screenshot of one that I made.
I have available to me a Report that is generated in Microsoft SharePoint, and it holds the quantities for certain items. The reports can be exported as excel documents, but if it is possible i would like to avoid that.
In my Access database I have all the same items but with additional data concerning special requests and item identification in the item's respective documentation folders.
I am looking for a way to have the select few columns that represent the quantities and some other factors, to be automatically updated in my database.
How can I go about this? Is there a specific terminology for what I am attempting to do, I am unable to find it on Google?
So to clarify ... you have item data exported from SharePoint and item data in Access and ideally you'd like to merge both and store the results in Access.
Or maybe another way of putting it, you would like to compliment the data in Access with the data from SharePoint.
If the database that powered the SharePoint report ran in Access as well, the word you are looking for is replication. You want to automatically replicate the data from one server/database to another.
Unfortunately I don't know of any software that replicates data to Access.
Your best bet would be to write a program that scheduled the running of the SharePoint report and then imported that data into Access.
I'm happy to give you the terminology of what to Google for. Just don't make me use SharePoint and Access. :)
If you have the same items in a report in SharePoint and in Access hopefully there is a field that uniquely identifies each item and is used in each table (a unique key). If these items (typically we would say 'records' or 'tuples' in database circles) are inventory SKUs or product numbers would be examples of potential unique keys. If you re taking the information in two tables and merging them together using a unique key we call it a 'Natural Join'. I know Access and SharePoint both support SQL and using SQL this would be done using a SELECT statement.
I would try googling: Natural Join tables in SharePoint and Accesss
Or: SQL SELECT between SharePoint and Access
Hope this helps.
If you choose linked tables to SharePoint (as opposed to importing them local), then you will always have a live copy of the data. In fact this is replicated model in Access 2010. Then a query could be used that joins in the additional table columns with quanity etc. Replication would need caution since any changes to the local access table would go back up to SharePoint and that may not be desired or even allowed.
In this case I would thus simply import the SharePoint tables local and again use a join based on a PK to the tables with quanity etc. that is local. Note that the local copy + cache runs very fast in 2010, and prior to Access 2010 + SharePoint 2010 the speed of such a setup is not so good compared to Access 2010.
If you are using an older version of Access + SharePoint then I would suggest you continue your approach of important the SharePoint tables (as opposed to being linked to the live tables on SharePoint). You then again simply use a query that joins in the additional columns you wish to display in your reports.
Such a results query would not only be of use for reports, but you could export that query into Excel or word.
Best regards.
Is there any handy tool that can make updating tables easier? Usually I got an Excel file with the original value in one column and new value in another column. Then I write a formula in Excel to create the 'update' statement. Is there any way to simplify the updating task?
I believe the approach in SQL server 2000 and 2005 would be different, so could we discuss them both? Thanks.
In addition, these updates usually request by "non-programmer" (which means they don't understand SQL, so it may not feasible to let them do query), is there any tool that can let them update the table directly without having DBAs do this task? Also, that tool needs to limit the privilege to only modify certain tables. And better has a way rollback the change.
Create a DTS package that will import a csv file, make the updates and then archives the file. The user can drop the file in a specific folder designated for the task or this can be done by an ops person. Schedule the DTS to run every hour, day, etc.
In case your users would insist that they keep using Excel, you've got several different possibilities of getting the data transferred to SQL Server. My preferred one would be to use DTS/SSIS, as mentioned by buckbova.
However, another method is by using OPENROWSET(), which makes it possible to query your Excel file as if it was a table. I wrote a small article about it here: http://blog.hoegaerden.be/2010/03/29/retrieving-data-from-excel/
Another approach that hasn't been mentioned yet (I'm not a big fan of letting regular users edit data directly in the DB), any possibility of creating a small custom application for them?
There you go, a couple more possible solutions :-)
Valentino.
I think the best approach is to expose a view on your data accessible to users who are allowed to do updates, and set up triggers on the view to perform the actual updates on the underlying data. Restrict change to only the columns they should be changing.
This technique can work on SQL Server 2000 and 2005.
I would add audit triggers on the underlying tables so you can always track changes.
You'll have complete control, and they can connect to it with Access or whatever and perform their maintenance.
You could create some accounts in SQL Server for these users and limit their access to only certain tables and columns along with onlu select / update / insert privileges. Then you could create an access database with linked tables to these.
I have an SSIS project where one of the steps involves populating a SQL Server table from an Oracle Table.
The Oracle table has a column ssis_control_flag. I want to pull across all records that have this field set to 'T'.
Now, I was wondering which would be the best way of doing this, and the two options as I have detailed in the question presented themselves.
So really, I am wondering which would be faster/better. Should I create a conditional split in the SSIS package that filters off all the records I want? Or should I create a view in Oracle that selects the records based on the criteria, and utilise that view as the data source in SSIS?
Or is there an even better way of doing this? You help would be much appreciated!
Thanks
Why don't you use a WHERE clause to filter the records, instead of creating a view? May be I am not getting your question correctly.
Then in general, bringing all the data to SSIS and then filtering out is not recommended. Especially when you can do the filtering at the source DB end itself. Consider the network bandwidth costs as well.
Then this particular filter that you are talking about here, cannot be done with a better efficiency in SSIS than that can be done at DB. Hence better do it in the Oracle DB itself.
You can use a query using openrowset as the source for the dataflow instead of directly accessing the Oracle table.