<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Data mining is driving much of data warehousing</title>
	<atom:link href="http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/</link>
	<description>Choices in data management and analysis</description>
	<pubDate>Sun, 20 Jul 2008 01:31:52 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Will Dwinnell</title>
		<link>http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-19508</link>
		<dc:creator>Will Dwinnell</dc:creator>
		<pubDate>Mon, 26 Feb 2007 10:36:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-19508</guid>
		<description>The data I deal with comes from several sources.  Much of it would have been recorded anyway: administrative items and transactions.  Some of it comes from other sources, and is purchased largely for analytical purposes: credit bureau data, etc.

I'm not sure where you're going with this, though, since the answer would be the same whether we used our current process, KXEN or any other analytical tool.</description>
		<content:encoded><![CDATA[<p>The data I deal with comes from several sources.  Much of it would have been recorded anyway: administrative items and transactions.  Some of it comes from other sources, and is purchased largely for analytical purposes: credit bureau data, etc.</p>
<p>I&#8217;m not sure where you&#8217;re going with this, though, since the answer would be the same whether we used our current process, KXEN or any other analytical tool.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg</title>
		<link>http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-14773</link>
		<dc:creator>Greg</dc:creator>
		<pubDate>Thu, 21 Dec 2006 16:28:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-14773</guid>
		<description>Late contribution, but I have to ask: is this from the technical journal of "Duh!" or "Dee dee dee!"

Why would anyone store such voluminous amounts of data, in such ridiculous formats, if they did not intend to mine the data store?</description>
		<content:encoded><![CDATA[<p>Late contribution, but I have to ask: is this from the technical journal of &#8220;Duh!&#8221; or &#8220;Dee dee dee!&#8221;</p>
<p>Why would anyone store such voluminous amounts of data, in such ridiculous formats, if they did not intend to mine the data store?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Curt Monash</title>
		<link>http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-14420</link>
		<dc:creator>Curt Monash</dc:creator>
		<pubDate>Wed, 22 Nov 2006 18:43:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-14420</guid>
		<description>Will,

Yes, you're right about KXEN.  They're trying to be classic "disruptors."  And KDD2006 -- well, that was a conference for the putative disruptees.  I don't recall talking with or about KXEN there, but I have zero difficulty believing everything you're suggesting about their reception there.

As for your core point -- I see what you mean.  But let me throw another set of questions back at you:  Where did those several hundred candidate predictors come from?  Are they ALL from transactional data that HAD to be recorded in the ordinary cost of business anyway?  Or is there a cost to accumulating the info in the first place?

Thanks for the good discussion,

CAM</description>
		<content:encoded><![CDATA[<p>Will,</p>
<p>Yes, you&#8217;re right about KXEN.  They&#8217;re trying to be classic &#8220;disruptors.&#8221;  And KDD2006 &#8212; well, that was a conference for the putative disruptees.  I don&#8217;t recall talking with or about KXEN there, but I have zero difficulty believing everything you&#8217;re suggesting about their reception there.</p>
<p>As for your core point &#8212; I see what you mean.  But let me throw another set of questions back at you:  Where did those several hundred candidate predictors come from?  Are they ALL from transactional data that HAD to be recorded in the ordinary cost of business anyway?  Or is there a cost to accumulating the info in the first place?</p>
<p>Thanks for the good discussion,</p>
<p>CAM</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Will Dwinnell</title>
		<link>http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-14414</link>
		<dc:creator>Will Dwinnell</dc:creator>
		<pubDate>Wed, 22 Nov 2006 12:12:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-14414</guid>
		<description>From my conversations with the folks at KXEN, I'd say your point 'B' is their real goal, although it is questionable to what extent this is possible.  I can tell you that KXEN representatives who pushed point 'B' got a skeptical reception at KDD2006 (including from myself).

I work at an international bank where I construct statistical models of customer behavior.  My last project involved 200,000 records with several hundred candidate predictors.  The raw data was housed in a relational database and a local data warehouse, which was accessed via SQL and related qureying tools.  I completed this project using my tool of choice, MATLAB, running on a Windows PC sporting an AMD Athlon64 FX-53 and 2GB RAM (I have recently upgraded to a Windows PC with an Intel Core 2 Extreme X6800 and 4GB RAM).

As to the cost issue, which was my original point:  Neither PC I mentioned cost over US$3000 at the time of purchase (and that includes the monitor).  I use MATLAB which is a little less than $2,000 new (less than $3,000 with typical analytical options), and much less than that (a few hundred bucks) for the annual subscription.  The database would have been there anyway: incremental cost: $0.  The data extraction software I wouldn't count since any business analyst would have it anyway, but I admit that could be debated.  The most expensive part of this process?  Me.  Hiring a qualified nerd to do this work is not cheap.</description>
		<content:encoded><![CDATA[<p>From my conversations with the folks at KXEN, I&#8217;d say your point &#8216;B&#8217; is their real goal, although it is questionable to what extent this is possible.  I can tell you that KXEN representatives who pushed point &#8216;B&#8217; got a skeptical reception at KDD2006 (including from myself).</p>
<p>I work at an international bank where I construct statistical models of customer behavior.  My last project involved 200,000 records with several hundred candidate predictors.  The raw data was housed in a relational database and a local data warehouse, which was accessed via SQL and related qureying tools.  I completed this project using my tool of choice, MATLAB, running on a Windows PC sporting an AMD Athlon64 FX-53 and 2GB RAM (I have recently upgraded to a Windows PC with an Intel Core 2 Extreme X6800 and 4GB RAM).</p>
<p>As to the cost issue, which was my original point:  Neither PC I mentioned cost over US$3000 at the time of purchase (and that includes the monitor).  I use MATLAB which is a little less than $2,000 new (less than $3,000 with typical analytical options), and much less than that (a few hundred bucks) for the annual subscription.  The database would have been there anyway: incremental cost: $0.  The data extraction software I wouldn&#8217;t count since any business analyst would have it anyway, but I admit that could be debated.  The most expensive part of this process?  Me.  Hiring a qualified nerd to do this work is not cheap.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Curt Monash</title>
		<link>http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-14261</link>
		<dc:creator>Curt Monash</dc:creator>
		<pubDate>Thu, 09 Nov 2006 02:20:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-14261</guid>
		<description>Will,

The issue isn't so much whether the traditional tools and data sets of full-time data miners happen to fit on desktop machines in a certain enterprise.  (Although I'm curious -- what tools do you use, on what kinds of data sets, and what kind of warehouse/mart did they emerge from?)

Rather, KXEN is trying to do a few things:

A. Divide problems into more, smaller, simpler models.
B. Make data mining accessible to people who aren't data mining experts.
C. Take out a lot of steps from the data mining process, such as variable reduction.

And Verix is trying to outsource the whole data mining task altogether.</description>
		<content:encoded><![CDATA[<p>Will,</p>
<p>The issue isn&#8217;t so much whether the traditional tools and data sets of full-time data miners happen to fit on desktop machines in a certain enterprise.  (Although I&#8217;m curious &#8212; what tools do you use, on what kinds of data sets, and what kind of warehouse/mart did they emerge from?)</p>
<p>Rather, KXEN is trying to do a few things:</p>
<p>A. Divide problems into more, smaller, simpler models.<br />
B. Make data mining accessible to people who aren&#8217;t data mining experts.<br />
C. Take out a lot of steps from the data mining process, such as variable reduction.</p>
<p>And Verix is trying to outsource the whole data mining task altogether.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Will Dwinnell</title>
		<link>http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-14259</link>
		<dc:creator>Will Dwinnell</dc:creator>
		<pubDate>Thu, 09 Nov 2006 01:24:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-14259</guid>
		<description>"...to change the rules of data mining. (Verix currently runs on Oracle, by the way.) KXEN, in particular, would like data mining to be done in a lot more, but probably a lot smaller, processing runs than it is today."

You have been reading too much literature from bloated companies selling over-priced tools.  Data mining has been done on the desktop for years.  I work as a data miner for an international bank and spend much more time on my (admittedly, beefy) PC than I do on the UNIX machine.</description>
		<content:encoded><![CDATA[<p>&#8220;&#8230;to change the rules of data mining. (Verix currently runs on Oracle, by the way.) KXEN, in particular, would like data mining to be done in a lot more, but probably a lot smaller, processing runs than it is today.&#8221;</p>
<p>You have been reading too much literature from bloated companies selling over-priced tools.  Data mining has been done on the desktop for years.  I work as a data miner for an international bank and spend much more time on my (admittedly, beefy) PC than I do on the UNIX machine.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: The Monash Report&#187;Blog Archive &#187; The problem with dashboards, and business intelligence segmented</title>
		<link>http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-9825</link>
		<dc:creator>The Monash Report&#187;Blog Archive &#187; The problem with dashboards, and business intelligence segmented</dc:creator>
		<pubDate>Fri, 06 Oct 2006 01:03:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-9825</guid>
		<description>[...] Deep analysis and decision support. Routine, scheduling reporting was covered in my first two categories. But this third one is where the bulk of ad hoc query and data mining fall. Generally, it’s where lots of specialized and/or calculation-intensive analytic technology comes into play. It’s also where the drilldown aspect of standard reporting shows up. Also, this is the area that is driving much of the recent transformation and disruption in the data warehouse market, because different kinds of BI need different kinds of data warehousing technology. [...]</description>
		<content:encoded><![CDATA[<p>[...] Deep analysis and decision support. Routine, scheduling reporting was covered in my first two categories. But this third one is where the bulk of ad hoc query and data mining fall. Generally, it’s where lots of specialized and/or calculation-intensive analytic technology comes into play. It’s also where the drilldown aspect of standard reporting shows up. Also, this is the area that is driving much of the recent transformation and disruption in the data warehouse market, because different kinds of BI need different kinds of data warehousing technology. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DBMS2 &#8212; DataBase Management System Services&#187;Blog Archive &#187; SAS Intelligence Storage</title>
		<link>http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-9553</link>
		<dc:creator>DBMS2 &#8212; DataBase Management System Services&#187;Blog Archive &#187; SAS Intelligence Storage</dc:creator>
		<pubDate>Wed, 04 Oct 2006 10:22:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2006/10/04/data-mining-data-warehousing/#comment-9553</guid>
		<description>[...] It sounds as if the product is optimized for data mining and generic OLAP alike. Indeed, SAS Intelligence Storage is used to power both SAS’s data mining and other advanced analytics, and also its more conventional BI suite.      &#8226; &#8226; &#8226; [...]</description>
		<content:encoded><![CDATA[<p>[...] It sounds as if the product is optimized for data mining and generic OLAP alike. Indeed, SAS Intelligence Storage is used to power both SAS’s data mining and other advanced analytics, and also its more conventional BI suite.      &#8226; &#8226; &#8226; [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
