Jamie's Junk : DMX

The amazing flexibility of DMX Table Valued Parameters

JamieMac — Fri, 25 Sep 2009 01:58:57 GMT

When most people think of “Table Valued Parameters” they think of “ possibly the most anticipated T-SQL feature of SQL Server 2008 .” However, little may you know, that the Data Mining team added table valued parameters and table valued functions...(read more)

Querying the Dependency Net

JamieMac — Sat, 13 Dec 2008 00:42:22 GMT

OK, ok, so just yesterday I posted that it was easy to determine what queries were being used by the browsers to get the data underlying the view. Of course it’s easy to get them, but without a teensy weensy bit of documentation, it’s not necessarily...(read more)

Getting Data Mining results into SQL Tables

JamieMac — Wed, 08 Oct 2008 09:35:00 GMT

I've been seeing lots of questions about how to get data mining results into SQL tables. Most times the answers are "use the prediction query builder save button" or "build an SSIS package." Both of these have issues among them being that the former is really only suited to single-use, small jobs, and the latter has a lot of overhead (not to mention that if you want to use the Data Mining Query Transform you have to have Enterprise Edition).

Luckily, there happens to be a much easier way - and it's one of those "Doh!" moments when you learn about it, because it's that easy.

The way to do it is to simply use linked servers. Anyone who uses DMX knows to connect to SQL data with OPENQUERY. There's no reason you can't simply connect to Data Mining data using the same mechanism.

For example, use a query like this to establish a link to an AS server:

EXEC sp_addlinkedserver 
@server='LINKED_AS', -- local SQL name given to the linked server
@srvproduct='', -- not used 
@provider='MSOLAP', -- OLE DB provider 
@datasrc='localhost', -- analysis server name (machine name) 
@catalog='MovieClick' -- default catalog/database

Then you can select data using OPENQUERY like this:

SELECT * FROM 
OPENQUERY(LINKED_AS, 
  'SELECT Cluster() AS [Cluster], ClusterProbability() AS [Prob] 
   FROM [Customers - Clustering]
   NATURAL PREDICTION JOIN
   OPENQUERY([Movie Click],''SELECT * FROM Customers'') AS t')

Then, of course, you can do all kinds of manipulations on it, like finding the average cluster probability of each cluster, right? Well, almost, the data type returned by the Cluster function is actual text or ntext or something that GROUP BY chokes on, so you have to do some casting first. Therefore if you want to do that trick, use a query like this:

SELECT Cluster, AVG(Prob) FROM
(SELECT CAST(Cluster AS Char(30)) AS Cluster, Prob FROM OPENQUERY(LINKED_AS, 
  'SELECT Cluster() AS [Cluster], 
      ClusterProbability() AS [Prob] FROM [Customers - Clustering]
   NATURAL PREDICTION JOIN
   OPENQUERY([Movie Click],''SELECT * FROM Customers'') AS t')
   ) AS t
GROUP BY Cluster

That will give you a nice result showing you, in a way, the affinity of each cluster based on the input set. That is, if you ran such a query against the training data, you could say that the clusters with a higher probability are "tighter" than the ones with low probabilities. Anyway, that's besides the point of this post.

In any case, remember to double your single quotes and flatten any nested results and this technique should work just great for getting DMX into SQL.

-J

Unwinding MDX Flattening Semantics with DMX

JamieMac — Mon, 10 Mar 2008 11:49:00 GMT

When issuing an MDX statement in code, you have the option of requesting either a multidimensional set or a relational rowset as the result set. If you are familiar with MDX and multidimensional concepts, the multidimensional result is the obvious choice. However, if your application is more suited to dealing with tabular data, such as Reporting Services, it may be more convenient to request the rowset result. One issue is that it's not always obvious how the MDX flattening semantics will translate the multidimensional set into a flattened rowset.

You can see exactly how MDX flattens results right inside SQL Server Management Studio by exploiting a little trick using DMX.

For example, take the simple Adventure Works query below:

SELECT
       {Measures.[Measures].[Reseller Sales Amount] *
          [Product].[Category].MEMBERS} ON Columns,
       {[Date].[Month]} ON ROWS
FROM [Adventure Works]
WHERE [Date].[FY 2002]

Which produces a result like this:

How many columns do you think the flattened result will have? It would seem that you could represent the results in the six columns that of the multidimensional result. However, the result set actually contains the entire hierarchy for the month. You can exploit DMX's ability to accept raw MDX statements as input to extract the rowset result. Since DMX always returns a rowset, if you select the input columns, you will retrieve the flattened result of the MDX statement.

The next question, of course, is how to you create a model such that you can access the MDX? The answer, you don't really have to. You can use any mining model that happens to be there, or just create any arbitrary mining model for the purpose. This trick takes advantage of the NATURAL PREDICTION JOIN construct with matches input columns to model columns by name and simply ignores any columns that don't match up - in this case, likely all of them.

Therefore, the DMX statement

SELECT t.* FROM [Customer Tree]
NATURAL PREDICTION JOIN
(SELECT {Measures.[Measures].[Reseller Sales Amount] *
[Product].[Category].MEMBERS} ON COLUMNS,
{[Date].[Month]} ON ROWS
FROM [Adventure Works]) AS t

Essentially ignores the model and simple returns the flattened result of the MDX query, which in this case returns nine columns, like this:

This trick can be used against any dimensionality MDX query to extract the flattened results. From a data mining perspective, this is particularly useful to determine the column layout of an MDX query in order to train mining models with INSERT INTO.

DMX Queries - the DataSource hole

JamieMac — Mon, 04 Feb 2008 07:09:00 GMT

So many people have told me how much they like DMX - the fact that they can use a query language to create, train, and query mining models is simply unprecedented in the data mining world. And they love it.

Until.....

Until, that is, they decide to go whole hog on DMX and implement their entire solution using ONLY DMX. Wow! What a great idea! I'll create a new database just for mining, and then I'll use DMX to create a mining structure, then use ALTER MINING STRUCTURE to add all my models, and then train using INSERT INTO.

Oh, frizznet! I can't INSERT INTO - I don't have a datasource.

How do you create a datasource with DMX?

YOU DON'T!

DMX lacks any syntax for creating or managing datasources, even though the language depends on datasources for all external data access (unless you want to open that giant security hole that is OPENROWSET, but that's a story for another blog post...).

However, not all is lost. It is fairly trivial to create a stored procedure that will take a datasource definition and create it for you from a command interface. In fact, it's so easy, because all you have to do is copy and paste the source code below.

[SafeToPrepare(true)]
public void CreateDataSource(string DataSourceName, string ConnectionString,
                         string sImpersonationMode, string Account, string Password)
{
      if (Context.ExecuteForPrepare)
              return;

      // Connect to the calling session
      Microsoft.AnalysisServices.Server svr = new Microsoft.AnalysisServices.Server();
      svr.Connect("*");

      // Get the current database
      Database db = svr.Databases.GetByName(Context.CurrentDatabaseName);

      // Create a new datasource and set connection string
      DataSource ds = db.DataSources.AddNew(DataSourceName, DataSourceName);
      ds.ConnectionString = ConnectionString;

      // Set the impersonation info
      bool FoundMode = false;
      foreach (ImpersonationMode mode in Enum.GetValues(typeof(ImpersonationMode)))
      {
          if (mode.ToString() == sImpersonationMode)
          {
              FoundMode = true;
              ds.ImpersonationInfo = new ImpersonationInfo(mode, Account, Password);
              break;
          }
       }
      if (!FoundMode)
          throw (new SystemException("Invalid Impersonation Mode"));

      // Update the server with the new datasource
      ds.Update();
}

When you build a project with this code, you need to include AMO as well as Server ADOMD.Net references. When deploying the assembly to the server, you need to make the assembly access "Unrestricted" or it will throw exceptions when trying to execute the AMO code.

After you have successfully built and deployed the stored procedure you can call it like this

CALL MySproc.CreateDataSource('MyDataSourceName','
Provider=SQLNCLI;Location=localhost;Initial Catalog=MyDatabase','ImpersonateCurrentUser','','')

And there you have it - closed the datasouce hole in DMX in 100 lines of code or less. Of course, if you're adventurous, you can add other management functions to add permissions to datasources, delete them, whatever you want!

Enjoy!

To (a) or not to (a), that is the question?

JamieMac — Mon, 14 Jan 2008 08:36:00 GMT

While looking for content for the next edition of my book (newsflash! I'm currently working on the next edition of my book!) I went hunting around for that trick using decision trees to predict the states of a single column independently rather than all together. Turns out - I never wrote it! So, in case you don' t want to wait for it (or it doesn't make it into the book!), here it is now.

The classifier-type algorithms in SQL Server Data Mining (notably decision trees, naive bayes, neural networks) can all predict multinomial outputs - that is, output attributes with multiple states - 3,4, 10, 20, whatever. However, in reality, classifiers in general prefer the ying and yang of things, the black and white, the yes-ness and the no-ness. In short, they really are better at seperating between the states of a binomial attribute rather than those of a multinomial attribute - and so are you, actually. If I gave you ten things to look at and said what is the factor that most cleanly divides all ten of these things, you'd have a hard time, but if I gave you two things instead, you might not have a problem. You would be more accurate, and your model may be more accurate as well, if you only had binomials.

Additionally, with multinomials, your model - particularly with decision trees - is harder to interpret. Say you have the marital status states of "Married", "Single", "Seperated", "Divorced" and "Widowed". When I look at the dependency net and it shows that "Number of Children" is predictive of "Marital Status" - what does it mean? Which aspect of marital status is it talking about - all of them? One of them? Impossible to tell.

So what do you do when you have a multinomial output? The first choice is obvious - see if you can reduce it to two states - e.g. can they be changed into "Married" and "Not Married". If that's not an option, i.e. if the states are important, another option is to turn them into a series of binomials - e.g. "Marriend" and "Not Married", "Single" and "Not Single", etc.

Now we run into an additional problem - not only is transposing our data like that a royal pain in the butt, it increases the number of columns and we may exceed the maximum row length of SQL Server.

Luckily with SQL Server Data Mining, we have a way out. By using a trick with nested tables, we can create a model that treats each state as a binomial attribute without changing any of our data. Assume our original model looked like this:

CREATE MINING MODEL MyMultinomialModel
(
    CustomerID     LONG   KEY,
    Age            LONG   CONTINUOUS,
    Gender         TEXT   DISCRETE,
    NumChildren   LONG   CONTINUOUS,
    MaritalStatus TEXT   DISCRETE     PREDICT
) USING Microsoft_Decision_Trees

we can transform the MaritalStatus field into a nested table like this:

CREATE MINING MODEL MyBinomialModel
(
    CustomerID     LONG   KEY,
    Age            LONG   CONTINUOUS,
    Gender         TEXT   DISCRETE,
    NumChildren   LONG   CONTINUOUS,
    MaritalStatus TABLE PREDICT ONLY
    (
         Status    TEXT   KEY
    )
) USING Microsoft_Decision_Trees

OK, so now that we've created the model, how do we train it - we only have a single source table right? Well, you're right, but that doesn't really matter. Using the tools in BI Dev Studio, you can select a table as both a Case and Nested table, and you can do the same thing using DMX, like this

INSERT INTO MyBinomialModel(CustomerID,
                            Age, Gender, NumChildren,
                            MaritalStatus(SKIP, Status))
SHAPE{OPENQUERY(MyDataSource,
                'SELECT CustID, Age, Gender, NumChildren
                FROM Customers ORDER BY CustID') }
      APPEND
      {OPENQUERY(MyDataSource,'SELECT CustID, MaritalStatus
                              FROM Customers ORDER BY CustID')
      RELATE CustID to CustID} AS MaritalStatus

So why does this work? Since we're using the same table as the case and nested tables, we're guaranteed that each case will have one and only one "Status" in the "MaritalStatus" table. The MaritalStatus table is PREDICT ONLY, so there's no cross-confusion between the states. A decision tree model in this case will build five trees - one for each state of MaritalStatus. Each attribute is a binomial variable with two possibilities "This state exists" or "This state doesn't exist".

This also helps in prediction if you need to predict a particular state. You will get a much better prediction of whether or not a customer is or is not a particular state than if you did this the traditional way. You can find out how likely by using subselects with your prediction statements, e.g.

SELECT FLATTENED
   (SELECT * FROM
      PREDICT(MaritalStatus, INCLUDE_STATISTICS)
    WHERE Status='Single')
FROM MyBinomialModel PREDICTION JOIN ...

The above query will give you the probability and support of being single for each customer in the input set.

Additionally, in the dependency network, each state of MaritalStatus will appear as its own node, so you will finally be able to see whether Number Of Children is more predictive of "Married" or of "Divorced" J

And for those wanting more information on the book, I’m working once again with Zhaohui Tang on the book and this time we’ve added Bogdan Crivat as a new author. It will probably have some spiffy name like “Data Mining with SQL Server 2008” and will be released sometime around when the product ships – no comment on that!

(note: the author is happily married with four children, regardless of what your dependency net says)

New DMX Syntax option in SQL Server SP2

JamieMac — Wed, 25 Apr 2007 19:11:00 GMT

Quite a while back I promised to tell everyone about the subtle new feature in DMX in SQL Server 2005 SP2. Well, that day has finally arrived, true believers – your patience has paid off! J

One of the nice improvements we made to SQL Server 2005 DMX was the ability to predict the probability of a particular state. That is, in SQL Server 2000, I could get the probability of the predicted state using the following query:

SQL Server 2000:
SELECT PredictProbability([Gender]) FROM Customers
PREDICTION JOIN …

This query gives me the probability of whatever state is predicted for Gender for each row of the input. However if I wanted to get the probability that a customer was ‘Female’, for example, I would have to write a query like this:

SQL Server 2000:
SELECT FLATTENED
(SELECT $Probability FROM PredictHistogram([Gender])
WHERE [Gender]='Female')
FROM Customers PREDICTION JOIN …

Which, to put in polite terms, is a tad bit cumbersome. Not only that, but you get a column called “Expression.$PROBABILITY” as your output – not nice.

Luckily in SQL Server 2005 Data Mining, we added new syntax that allowed you to simply indicate the state for which you wanted the probability directly in the function call, like this:

SQL Server 2005:
SELECT PredictProbability([Gender], 'Female') FROM Customers
PREDICTION JOIN …

And life was good. We even made it nicer by allowing the specification of a parameter for the state, so you could write queries like the following:

SQL Server 2005 SP2:
SELECT PredictProbability([Gender], @Gender) FROM Customers
PREDICTION JOIN …

And specify the desired state at run-time. Wonderful! However, when we were implementing other features we ran into the one ommission. It turns out we even allowed arbitrary expressions like ‘Fe’+’male’ there, but we left out the ability to determine what the probability of a known state from the input. That means that if I wanted to determine what the probability was of a state and the state happened to be stored in the database, I would have to first issue a query to get the state and then issue another query to get the probability of that state. Not fun.

In SQL Server 2005 SP2 Data Mining we generalized the language so that essentially, every where you can place a parameter, you can also place a column reference. That means that I can solve the above problem with a query like this:

SELECT PredictProbability([Gender], t.Gender) FROM Customers
NATURAL PREDICTION JOIN
OPENQUERY([Movie Click], 'SELECT * FROM CUSTOMERS') AS t

Now, where is this useful? I’m sure all of the creative DMXers out there will find innumerable uses for this new flexibility, but the most obvious application (for me at least) is for accuracy and lift calculations. Now, in one query, I can generate lift figures for my entire testing set without caching the data, allowing, for example, the generation of lift reports in Reporting Services!

Enjoy this new found friend in DMX, and I’d enjoy hearing how you put it to use in your applications!

-Jamie

Predicting the non-majority state

JamieMac — Wed, 10 Jan 2007 11:00:00 GMT

The Predict() function in DMX always returns the highest probability non-missing (by default) state for the requested attribute. That is, if there are two states, the state with a probability higher than 50% will be returned. However in many cases you want a response to be a target state even though it may not have the highest probability. For instance, say you implemented the AdventureWorks Bike Buyer model, and your profit chart indicates you will recieve the highest profit by selecting all the cases where the probability of "Buy" is greater than 25%. Given the processes in place, you don't want to have a filtered result, rather you want to label each row in a table as a target or not.

Luckily, the flexibility of DMX makes this operation quite easy. All that has to be done is to express the condition that represents targets as a boolean expression, and place the expression in the select list. For example, in this case you could use the following query:

SELECT t.CustomerID, (PredictProbability([Bike Buyer],'Buy') > 0.25) AS IsTarget FROM MyModel PREDICTION JOIN ...

The expression PredictProbability([Bike Buyer],'Buy') > 0.25 evaluates to a boolean and is returned as IsTarget. Using this statement would tag cases as targets even though they have up to a 75% chance not to buy, since your tests showed that group to be the most profitable.

Predicting based on rules alone and getting everything you always wanted

JamieMac — Tue, 05 Dec 2006 10:53:00 GMT

In this post I explained how to couch an associative prediction that omitted predictions that were based solely on marginal statistics. The one catch was that if you asked for 5 items, you might not get 5, you could get 4 or 3 or even down to 0, since all predictions without a corresponding prediction node id were filtered out.

However, by leveraging the TopCount function, you can have your bread and butter it too (it's late). Use syntax like the following:

SELECT TopCount(
                  (SELECT Product, $Probability FROM
                          PredictAssociation(Products, INCLUDE_STATISTICS, INCLUDE_NODE_ID)
                          WHERE $NodeID <> ''),
                  $PredictProbability,
                  5) AS PredictedProducts
FROM MyAssociationModel
NATURAL PREDICTION JOIN
.....

Executing multiple DMX statements from SSMS

JamieMac — Sat, 10 Jun 2006 21:11:00 GMT

Many people have asked how to execute multiple DMX statements in SSMS, and my answer has always been "Analysis Services doesn't support IMultipleResults, so you can't execute multiple statements in a single document in SQL Management Studio." Well it turns out I was wrong, and I was wrong - in a sense, at least.

If you typed in multiple DMX statements seperated by semicolons and tried to execute them, what I stated above is actually true - it won't work. However, usually the reason people want to do this is that they want to script a CREATE MINING MODEL, INSERT INTO, and possibly a SELECT statement together. If you were to use the above method, assuming it would work, it actually would mean that all these statements would get executed in parallel - which wouldn't work or be what you wanted anyway. Because you have to create the model before training, and train before selecting, the statements need to be executed serially.

So what you want to do is to use the SQL Management Studio keyword "GO". When you type GO on its own line in SQL Management studio, it doesn't send the "GO" to the server, rather it sends the query up to that point, waits for a return and then sends the next statement serially (up to the next GO or the end) - exactly the behavior you want, and it works as well!

For example you can have a .DMX file that looks somewhat like this:

CREATE MINING MODEL [MyModel]
(
MyKeyColumn TEXT KEY,
MyInputColumn TEXT DISCRETE
) USING Microsoft_Clustering
;
GO

INSERT INTO [MyModel] (MyKeyColumn, MyInputColumn)
OPENQUERY ([MyDataSource],'SELECT MyKey,MyInput FROM MyTable')
;
GO

SELECT * FROM [MyModel].CONTENT

And execute the entire file by pressing F5 to create, train, and retrieve content from your model in one fell swoop.

Predict based on rules alone

JamieMac — Wed, 19 Apr 2006 23:18:00 GMT

I've been asked this question a few times and never thought of an answer until I was asked again today on the data mining newsgroups. We'll be posting a tip or trick on sqlserverdatamining.com on this, but since it's fresh in my mind I'll let everyone have it now.

The problem that some people are having is the behavior of associative prediction returning popular results if the algorithm doesn't actually predict anything. Many seem to want only results returned by predictions (we thought that if you asked for 5 you wanted 5 - who knew?). In any case you can check the node id to see if the prediction was based on a rule - if there's no node id, no rule - you can drop it.

A sample query using this technique looks like this:

SELECT

(SELECT * FROM PredictAssociation([MovieModel].[Movies],5,
INCLUDE_NODE_ID)
WHERE $NODEID<>'')

From

[MovieModel]

NATURAL PREDICTION JOIN

(SELECT (SELECT 'What''s New, Pussycat' AS [Movie]

UNION SELECT '28 Days' AS [Movie]) AS [Movies]) AS t

Another interesting flag to try out for PredictAssociation is INCLUDE_STATISTICS, so you can determine the probability and support for each suggestion.

Automatic Generation of CREATE MINING MODEL statements

JamieMac — Thu, 30 Mar 2006 21:51:00 GMT

I noticed through answering newsgroup and forum posts that we always want to know model definitions when discussing a problem. Luckily we have this great language called DMX that makes it very easy and simple to describe a model. Unluckily, our tools that we use to create models use an XML DDL that is very complex and, for the most part, not intelligible to human readers.

To solve this problem I sat down last night and wrote up a little stored procedure to create a CREATE MINING MODEL statement from any server model. All you have to do after building and deploying the stored procedure is execute the query

SELECT DMXtract.CreateMiningModelStatement() FROM [TreeModel]

To build this code you will have to add a reference to Microsoft.AnalysisServices.AdomdServer. For more information on how to deploy stored procedures see this article in Books Online.

Below is the code for CreateMiningModelStatement. One unforeseen benefit I discovered writing this code was that the parameters collection contains all parameters even if they weren’t set by the user. This makes it useful to determine how the algorithms automatically set specific parameter values on your behalf.

using System;

using System.Collections.Generic;

using System.Text;

using Microsoft.AnalysisServices.AdomdServer;

namespace DMXtract

{

public class DMXtract

{

[SafeToPrepare(true)]

public string CreateMiningModelStatement()

{

// Return empty string on prepare

if (Context.ExecuteForPrepare)

return "";

// Return the create statement for the current model

return CreateMiningModelStatement(Context.CurrentMiningModel);

}

private string CreateMiningModelStatement(MiningModel model)

{

int count = 0;

// Add the CREATE syntax

string statement = "CREATE MINING MODEL [" + model.Name + "]";

statement += "\r\n(\r\n";

// Add the columns

statement += ListModelColumns(model.Columns,1);

// Add the algorithm

statement += "\r\n) USING ";

statement += model.Algorithm;

// Add model parameters

if (model.Parameters.Count > 0)

{

statement += "(";

foreach(MiningParameter param in model.Parameters)

{

if (param.Name == "" | param.Value == "")

continue;

if (count > 0)

statement += ", ";

statement += param.Name + "=" + param.Value;

count++;

}

statement += ")";

}

// Add Drillthrough

if (model.AllowDrillThrough)

statement += "\r\nWITH DRILLTHROUGH";

return statement;

}

private string ListModelColumns(MiningModelColumnCollection columns, int indent)

{

int count = 0;

string statement = "";

// Iterate columns in collection

foreach (MiningModelColumn modelcol in columns)

{

if (count > 0)

statement = statement + ",\r\n";

// Indent as indicated

for (int i = 0; i < indent; i++)

statement += " ";

statement += "[" + modelcol.Name + "]\t";

MiningStructureColumn structcol = modelcol.StructureColumn;

if (modelcol.Type != MiningColumnType.Table)

{

// Append scalar column

statement += " " + modelcol.Type.ToString().ToUpper();

if (modelcol.Distribution != MiningColumnDistribution.Missing)

statement += " " + modelcol.Distribution.ToString().ToUpper();

if (modelcol.Flags != "")

statement += " " + modelcol.Flags;

statement += " " + modelcol.Content.ToString().ToUpper();

// Add prediction flags

if (modelcol.IsPredictable)

{

if (modelcol.IsInput)

statement += " PREDICT";

else

statement += " PREDICT_ONLY";

}

else

{

// Append nested table column

statement += " TABLE";

// Add prediction flags

if (modelcol.IsPredictable)

{

if (modelcol.IsInput)

statement += " PREDICT";

else

statement += " PREDICT_ONLY";

}

statement += "\r\n";

for (int i = 0; i < indent; i++)

statement += " ";

statement += "(\r\n";

// Append nested columns

statement += ListModelColumns(modelcol.Columns, indent + 1);

// Close nested table definition

statement += "\r\n";

for (int i = 0; i < indent; i++)

statement += " ";

statement += ")";

}

count++;

}

return statement;

}

Code from book and new XMLA template at SSDM

JamieMac — Tue, 15 Nov 2005 23:07:00 GMT

I just added a couple of new downloads on SQLServerDataMining.com

The first is the sample from chapter 16 (Forecasting in Excel) of my book, Data Mining with SQL Server 2005 which was misposted on the publisher's site (it will be updated there as well, but it's at SSDM for those of you who want it today).

The other download is a simple XMLA template that is surprisingly important since it fills a gap in our DMX language that was blocking common workflows.

DMX has great constructs for creating, training, and managing mining structures and models. Now that SQL Server Management Studio (SSMS) has a DMX editor, it's really nice to just open one up and start typing CREATE MINING STRUCTURE ... and do all of your mining right there. However, in general, once you got to INSERT INTO you were stuck (not to mention PREDICTION JOIN). Since we strongly encourage everyone to use OPENQUERY and a named datasource rather than OPENROWSET and a connection string, it would seem that there would be an easy way to create datasources in SSMS. Wrong.

The only "easy" way to create a datasource would be to fire up the BI Dev Studio, open the database, create a datasource in the UI and then switch back to SSMS - a user experience that leaves a bad taste in your mouth - essentially a big hole in the experience.

So the template I added allows you to easily create a datasource from SSMS by loading the template, setting some values (like a name, connection string, etc) and executing. Now you can perform your entire DM workflow directly in SSMS!

Enjoy! I welcome any feedback or many suggestions for new templates.

Time Series Prediction

JamieMac — Tue, 29 Mar 2005 01:06:00 GMT

Last week I was playing around with the Time Series algorithm - ok I was showing a customer - and I wanted to show the prediction language used to display the charts. So I used the tools and showed them the basic prediction query for forecasting, but I wanted to go further and show them cool stats like the variance and standard deviation of each predicted value. So I tried, and failed, and tried again, and failed, and after a few more furtive attempts had to admit to myself that I just didn't know (shame shame) how to get the standard deviation for a time series prediction.

But I didn't give up there - since you can see the deviations in the chart viewer, obviously you can get them from the server. I fired up my handy-dandy SQL Profiler, connected to my Analysis Server and viola! I pulled the query right out of the log! Immediately afterwards I had one of those "oh yeah" moments where you realize that you knew (or should have guessed) all along but had a brain dead moment and simply spaced.

In any case, the syntax you need to use is not trivial and no one not on the development team is likely to guess out of thin air, so I wrote up this tip explaining the convoluted syntax for the world to see. Once you see it, you won't likely forget it, and if you do - grab the profiler and puul it out, just like the dev team does!