Spilt ends
Story by Mark Whitehorn, 01-06-2008, 0 comment
Teradata epitomises the top end of the data warehouse market, so is its shock announcement of a data warehouse appliance a sign it is changing course or is it intelligently exploiting a market opportunity?
I've just come back from the Teradata Universe conference in Lisbon where Teradata announced that it had extended its family of products. Of particular note are the Teradata 550 and Teradata 2500. The 550 is a symmetric multiprocessing (SMP) box with a price in the order of $67,000 (£33,000) per terabyte. Teradata describes it as a departmental data warehouse. "The Teradata 550 was developed to run a single application or support test and development workloads. It is simple to set up and can use the Novell SUSE Linux 64-bit operating system or Windows. Customers can license and run the Teradata 12 database on their choice of Intel-based platforms, starting at $40,000." The Teradata 2500 is described as an "entry-level data warehouse".
Despite the terminology Teradata uses to describe them – "analytical platforms" – these are what you and I would recognise as data warehouse appliances.
This announcement is significant because Teradata doesn't just lean towards the high-volume, complex analytics end of the data warehouse spectrum, it is that end of the spectrum. And DWAs are from the other end. So finding Teradata with a DWA is like finding a Wagon Wheel in Fortnum & Mason's food hall: not impossible but certainly unexpected. This is about a totally different philosophical approach to data warehouse architecture.
What's this spectrum?
We can conveniently (and somewhat simplistically) identify three main data warehouse architectures. All of them start with the premise that the operational data of the enterprise sits in a set of transactional databases (HR, finance, sales, etc). The systems are great for performing transactions but bad at reporting and analytics.
However, after that, the three architectures differ significantly.
Isolated data mart
Each department looks after its own reporting needs. The data from its own transactional system(s) is copied and placed in a reporting server, often called a data mart. This data mart is used for reporting (Figure 1).

This architecture is very cost effective and quick to implement. The disadvantage is that there is no attempt to unify the meaning of data across the enterprise.
In practice this is a serious issue. Many of the entities that feature in reports (Customers, Products, Employees, etc) are of interest to many departments. If the data marts are created and managed independently, it is likely that the data collected (and the definitions applied) will differ between them. So when two departments calculate a value for, say, the average sale per customer, they will get different answers. As soon as that discrepancy is spotted (at, say, a board meeting) the limitations of this approach are thrown into sharp relief.
Enterprise data warehouse
At the opposite end of the spectrum, the enterprise data warehouse (EDW) neatly answers this particular criticism. Instead of using isolated data marts, the data from the operational systems is pulled into one central repository (the EDW). There it is massaged into a relational set of data and reports are generated directly from that data set (Figure 2).
Post new comment
Top 10 Most Popular Articles
Lab: multifunction printers
Down to business
Icing on the cake
Don't knock NAS
Tunnelling in
The Holy Grail
Clever clustering
The stakes are high
Data Crunch
The Case Against...Wireless
Down to business
Icing on the cake
Don't knock NAS
Tunnelling in
The Holy Grail
Clever clustering
The stakes are high
Data Crunch
The Case Against...Wireless
Want to advertise here? Follow me!
Syndication.