Posted by arlene

Few things are more frustrating than successfully building a data ware- house and then having it rendered unusable by less-than-satisfactory user tools. This post presents some questions to consider when you’re evaluating tools you’re considering purchasing.

Can Users Easily Budd Their On Query and Report Screens?

In most data warehousing environments, a substantial number of report and query screens and templates are common to a significant portion of the user community, and the development team builds these capabilities for the users. At the same time, though, to avoid creating a backlog of requests that the support staff cannot easily handle, users must be able to create and use their own queries and reports.

While you’re evaluating a tool, find two users who have no experience in user reporting and querying products and a third user who has used another product but not the one you’re considering. A few days before you run your usability test, give the tutorial documentation (the written version) to only one of the users with no experience. Then have all three people try to solve two or three business problems of varying difficulty by creating a query or report with the tool. See how they do!

Can a User Stop a Runaway Query or Report?

Almost every user tool occasionally submits a query (or performs some other type of operation, such as running a report) that keeps going, and going, and going….

A user tool must give users a way to stop this type of query or report gracefully, without doing any of the following:

Locking up the user’s desktop PC and forcing him or her to have to turn it off or reboot

Interfering with other users‘ work (by having to halt the database server and restart it, for example)

Otherwise causing a disruption in business as usual

Check out each product, and make sure that any user can stop the runaway query or report from a desktop PC.

Now Does Performance Differ with Varying Amounts of Data

You may have determined during the project scope that your data warehouse will start with 5 gigabytes of data, for example, and grow to 50 gigabytes during the next two years. It pays to know, however, how each tool will perform with not only the initial 5 gigabytes and the eventual target but also with 100 or even 200 gigabytes, just in case.

In case of what? Here are just a few possibilities:

New data sources no one could foresee during the project scope A decision to add an increased level of detail to the data

A decision not to delete old data but rather to keep it in the data warehouse

If your data warehouse will never approach terabyte-size (a trillion bytes of data), don’t worry about how a tool performs with that much data — it’s irrelevant. What’s more significant is whether the tool will perform as well (or nearly as well) with 50 gigabytes of data as it does with its initial 5 gigabytes.

Performance is not a tool-only situation; it also depends on the DBMS you use, how you design your database, and many other factors. Ask your questions in an environment as close as possible to what is available during production.

Possibly related posts: (automatically generated)
Data Warehouse, Databases Easy Access Top ten Considerations part 1

• Data Warehouse, Databases Easy Access Top ten Considerations part 2
• Data Warehouse, how far we have gone?
• Database Tool, Efficient Enhance
• Hand in hand Database Design and Data Backup, Recovery
• Mimicking Built-In Functions with User-Defined Functions
• Using the New Wizards in SQL Server 2000
• Web Server Identifying your Customers by their Email Addresses
• Introduction to Web 2.0 Website Patterns
• Network Access Control Databases
• Data Project Plan Note part 1