Showing posts with label data. Show all posts
Showing posts with label data. Show all posts
Wednesday, April 08, 2009
Tech: Data Provisioning
I grant that some of my technical pieces may be rather esoteric for a general audience. So I have sequestered them off to a separate blog for my professional pursuits. You'll find the first post here, on a neologistic use of the term Data Provisioning for a successor model to the Enterprise Data Warehouse.
Sunday, August 24, 2008
Business Intelligence 2.0
A provocative article on B.I. dating back a year and a half makes an interesting juxtaposition between the development of Web 2.0 and business intelligence. Or at least, where he thinks B.I. will be. Or ought to be.
It's by a bloke called Neil Raden, and you can read it here. There are limits to the analogy, of course. Web 2.0 is about a ramping up due to interactivity, collaboration. Business Intelligence 2.0, from what the author says, is simply about what B.I. would be like if the professionals and software developers just got on with the job and came up with more sophisticated tools.
At first glance, I thought it was pie in the sky. Second glance, it all made sense in a general way: the toolset is not what it should be in an ideal world, and there's no reason the B.I. space shouldn't go that way. But in reality, such evolution would take quite some time. And in fact I query how susceptible to simplification something as mercurial as data - and people's approach to it - can be. Raden acknowledges here the value of the semantic web project, and that may actually be whence the best initiatives emerge.
Still, it's challenging, and worth reading for those in the industry, or who are touched by the issue.
It's by a bloke called Neil Raden, and you can read it here. There are limits to the analogy, of course. Web 2.0 is about a ramping up due to interactivity, collaboration. Business Intelligence 2.0, from what the author says, is simply about what B.I. would be like if the professionals and software developers just got on with the job and came up with more sophisticated tools.
At first glance, I thought it was pie in the sky. Second glance, it all made sense in a general way: the toolset is not what it should be in an ideal world, and there's no reason the B.I. space shouldn't go that way. But in reality, such evolution would take quite some time. And in fact I query how susceptible to simplification something as mercurial as data - and people's approach to it - can be. Raden acknowledges here the value of the semantic web project, and that may actually be whence the best initiatives emerge.
Still, it's challenging, and worth reading for those in the industry, or who are touched by the issue.
Tuesday, July 22, 2008
SQL Server: varchar to real
I was having trouble loading some data into a SQL Server database (MS). The particular problem was converting a type char to type real.
There are several ways to change data types. Typically, you'd use cast or convert functions. But everything I tried returned the same message: "Error converting data type varchar to real."
I googled to find out how other people dealt with this, but found nothing useful.
Then I tried something that worked: convert the type varchar to type money, then to type real. Easy.
Of course, this makes perfect sense if your numbers only run to two decimal places. In fact, it works to four decimal places (the same if you choose type money or smallmoney, except that the latter is stored in fewer bytes).
The options for retaining precision past four decimal places are somewhat messier. One way is to multiply the numbers by a few factors of ten, but you still have to pay attention to the range of viable values for money or smallmoney.
I'm not convinced that this issue is yet another demonstration of the unwieldiness of MS SQL Server. All databases have their pain points; this is just another one.
There are several ways to change data types. Typically, you'd use cast or convert functions. But everything I tried returned the same message: "Error converting data type varchar to real."
I googled to find out how other people dealt with this, but found nothing useful.
Then I tried something that worked: convert the type varchar to type money, then to type real. Easy.
Of course, this makes perfect sense if your numbers only run to two decimal places. In fact, it works to four decimal places (the same if you choose type money or smallmoney, except that the latter is stored in fewer bytes).
The options for retaining precision past four decimal places are somewhat messier. One way is to multiply the numbers by a few factors of ten, but you still have to pay attention to the range of viable values for money or smallmoney.
I'm not convinced that this issue is yet another demonstration of the unwieldiness of MS SQL Server. All databases have their pain points; this is just another one.
Monday, August 07, 2006
Tech: semantic integration
Have a look at a thoughtful article on semantic integration, flagged from Wikipedia.
In a nutshell, this is a form of integration that focuses on data, and relies on ontologies (effectively metadata by domain, or data dictionaries) being published in a relatively standardised format.
The ultimate goal would surely be a product which sucks all a company’s metadata into one source – regardless of original format - then enables updating from that source. Now there’s a business opportunity.
In a nutshell, this is a form of integration that focuses on data, and relies on ontologies (effectively metadata by domain, or data dictionaries) being published in a relatively standardised format.
The ultimate goal would surely be a product which sucks all a company’s metadata into one source – regardless of original format - then enables updating from that source. Now there’s a business opportunity.
Subscribe to:
Posts (Atom)