Q

Should a data steward have direct SQL access for reporting purposes?

Find out when a data steward should have direct SQL access and how to request SQL access to get data directly from the data warehouse for reporting and analytical purposes.

Our company (a relatively small Swiss regional bank) has started a data warehouse project which mainly aims at satisfying reporting needs. I am in charge of customer analytics (e.g. satisfying any kinds of ad-hoc analysis request from our marketing department, producing predictive models for churn, cross-sell etc.) Currently my work is very difficult because I must extract all the data I need from the operational banking system. I had hoped that in the future with the new data warehouse I would be able to concentrate on the analytical work instead of data extraction and cleansing. However, I just learned that the data warehouse will be accessible only through certain business intelligence (BI) front-end tools (such as Business Objects). For me it is unthinkable to work without having direct SQL access to the data warehouse tables. The analytical requirements are so difficult to predict and in many cases so complex that I don't think I will be able to satisfy even a fraction of our requirements if I am restricted to such a BI tool. Or am I wrong? My feeling is that the BI tools offer access only a predefined ways to predefined data (e.g. the different join types and criteria are pre-defined, and one cannot make complicated filter criteria based on sub-queries). Is it not common best practice to give SQL-literate power users direct SQL access to a data warehouse for analytical purposes?

As someone who is in charge of customer analytics, you sit in a role that is neither completely business nor completely IT, regardless of where it is placed in an organizational chart. Your work should mostly entail using the data provided in the data warehouse, as opposed to sourcing data into the warehouse. However, as a "data steward," you should have great influence over what gets sourced and how it may be transformed en route to...

the warehouse. It's the job of the data warehouse team to actually do it, but you should be part of the extended design team.

If it helps you do your job more effectively, you should have the ability to utilize SQL. However, I do understand their desire to roll out the warehouse in a measured fashion and I also understand their interest in getting users to utilize the full capabilities of the BI tool(s). The extreme alternative, which is not good for the organization, is everybody pulls raw data from the warehouse. Following this method, anyone can apply all manner of calculations to the data in spreadsheets, as opposed to working with the data warehouse team to bake those calculations into the warehouse ETL so that it's easier, supportable and everybody can benefit.

As long as you are truly analyzing the data and not doing processing that really belongs in the ETL, your request makes sense. Over time, warehouse usage naturally evolves into multiple tools across multiple categories. Long gone are the days when we foisted SQL access on the pedestrian end user, but SQL remains a viable tool for the power user.

Work on communication and alleviate their concerns, but if both sides acknowledge that the focus needs to be on business value, you should be "SQL'ing" away.

This was first published in February 2009

Dig deeper on Business intelligence software

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchDataManagement

SearchAWS

SearchContentManagement

SearchCRM

SearchOracle

SearchSAP

SearchSQLServer

Close