March 30, 2005 at 9:46 pm
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/pressrelease/tableausoftwaredebuts.asp
April 4, 2005 at 1:41 pm
This, like many other tools seems to be a great decision support tool. However the "gotcha" in decision support is not in the tool used to present information. The real pain is in the actual data analysis and classification.
I have been a first-hand witness to a company pouring out millions of dollars trying to find a way to represent information in a sensible way, however being totally unwilling to invest capital into re-tuning and re-thinking poor data architecture.
Typically, when companies implement SQL Server, the nice graphical widgets provide the false impression to management that professional DBAs and data analysts are not needed. Therefore good design theory and practice are not applied until such a time that a company finds out their "data" is not capable of providing information needed and the need to hire professional DBAs arise. Even so, companies are usually unwilling to swallow the bitter pill of "re-engineering" that the DBA recommends providing the "information" needed. Typically DBAs hands are tied to making small changes (if any) over a long period of time, all the while the current architecture is kludged upon to keep the business demands met.
As much as possible, we need to continue to evangelize the key differences between DATA and INFORMATION. Data is an entity that stands on its own and typically has a set of attributes that define it (i.e. I am an individual whose attributes are my name, birthdate, social security number, etc.). Information is knowledge gained from data (i.e. there are 15 persons that my company does business with who have the same birthdates as mine). Databases are designed with the former (data) in mind.
Believe it or not, the jury is still out on how valuable databases containing pre-processed information (i.e. typical decision support "Kimball" style star / snowflake) are to a constantly changing business need. Many (Ralph Kimball) contend the performance gains of having data and information combined horizontally are absolutely essential, even if the integrity of the data is compromised. Others (Adrian Pascal, E.F. Codd) contend the performance problems are due to individual vendors refusal to adopt database theory fully and that no database should be designed to compromise the core data and attributes.
For us normal DBAs, this leaves us in a rather precarious state. Do we knowingly and wittingly compromise integrity for performance because it is a business need today? If we value our jobs, we do. However our "future" jobs may also depend on the limited expandability created by the compromised data architecture. What a quandary!
Myself, I hope to retire before the architectural issues I am forced to create are discovered by a changing business requirement. 😉
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply