Databases
In many respects, the database market is like the new-home-buying market. Like a home, a database is a necessary thing, and even in economic downturns, necessary things sell. Databases are vital technology components that build business. Databases feed Web-based dynamic content and facilitate page updates; they reuse data across multiple applications and reduce redundancy; they also store in data warehouses information that's culled, mined and aggregated by business applications and knowledge-discovery tools.
Yes, this market continued growing in 2000, albeit at a slower pace. The DBMS market grew 10 percent in 2000, down from 18-percent growth in 1999 and 12 percent in 1998, according to an August Dataquest report. Today's economy will have its effect -- even on this crucial market.
Slower growth is allowing market leaders to pull away from the pack. In 2000, Oracle, IBM and Microsoft had 34 percent, 30 percent and 15 percent of the market, respectively, totaling 79 percent of the DBMS market, according to Dataquest's report. During the past year, each of the big three made big news. Oracle came out with 9i, touting improvements in performance, scalability and management. Then Oracle implemented a controversial pricing scheme but dropped it after a backlash from licensees.
IBM bought Informix's database products in July, after a dip in Informix's market share. For now, IBM is maintaining separate product lines with the Informix OLTP database server and Red Brick line. We'll have to wait and see what IBM will do.
Microsoft hasn't been sitting still, but since the release of SQL Server 2000, the company has been paying more attention to delivery of its .Net solution than to SQL Server.
On the open-source front, lots of small -- and some large -- Web sites are using PostgreSQL and MySQL at the back end. Some have complained about PostgreSQL's speed and MySQL's database functionality, but their price is right. Within the past year, each has made improvements where needed.
Data Warehousing
In today's business model, information is everything -- and information comes from data. You have data about your business, your customers, their buying practices and thousands of other variables. If you can just get a handle on your data, you can make informed decisions for your business. Behold the promise of data warehousing. But do you really need a data warehouse?
If your business needs are met by historical reports from a TPS (transaction processing system) and your hardware can support report generation from a live system without degrading performance, maybe you don't. But if you want to run ad hoc query and reporting tools against a variety of data resources in multiple data formats, a data warehouse is at least worth investigating.
Designing, building and maintaining a data warehouse can be costly. Make sure to keep focused so your data warehouse is solving the problems you want it to; otherwise it's just a time and money pit. And remember, data-warehouse benefits won't show up overnight. There will be some trial and error with business processes and analytical rules/algorithms for accessing the data you want. And you'll have to revisit the underlying logic when your needs or processes change.
There are two data-warehousing schools of thought. The first is that you must design your data warehouse for the entire enterprise. The second suggests you can build pieces of your data warehouse as data marts. Proponents of each tend to take issue with the other.
With a data mart, you can focus on a single business process or department of your business. This way you can investigate the technical benefits of this system while watching it relieve your TPS databases. You'll also get to see the benefits gained by your information-gathering efforts and decision-making processes.
If it's a success, you can build multiple data marts or go for the whole data warehouse. With multiple marts, use some shared design principles and a common database staging area for ELS (electronic library system) functions. That way, you can use an incremental approach to building focused data marts and aggregate them using a common set of data definitions.
Some data-warehouse proponents say data marts make stovepipe solutions that don't scale to the enterprise, thereby depriving you of the data warehouse's true benefits. If you have the resources to engage an enterprisewide data warehouse, design and implement with common data structures and model data to speed up queries and reports -- for example, by using a star schema.
Bitmapped indexes will also speed analytical processing but may use up as much space as the warehouse itself. You'll need plenty of real estate for a large back-end data warehouse. In the end, your warehouse should provide information on your customers' buying habits, let you personalize your Web site and target your marketing efforts.
Whatever you decide, data warehouses are the foundation of applications that make sense of large amounts of data. We'll be looking at how these applications meld with CRM (customer-relationship management), portals, ERP (enterprise resource planning) and knowledge management in 2002.
Steven J. Schuchart Jr. covers storage and servers for Network Computing. Previously he worked as a network architect for a general retail firm, a PC and electronics technician, a computer retail store manager, and a freelance disc jockey. Send your comments on this article to him at sschuchart@nwc.com.
RSS
