Original Teradata Design Goals Strongly Coupled With Normalization - Teradata Database

Original Teradata Design Goals Strongly Coupled With Normalization

Two of the principal design goals for the original Teradata parallel architecture were:

To overcome the performance barriers that existing decision support systems faced

To eliminate redundant, inconsistent data banks and the costs, both tangible and intangible, of those redundancies and inconsistencies

Teradata has always promoted full database normalization. The reasons for this support for fully normalized databases include the following factors:

Normalization is a provable, logical, and consistent method for designing provably correct database schemas. In their research that won the ACM PODS best paper award, Arenas and Libkin (2003) demonstrate the rigor of normalization by showing that its correctness can be proven not only with formal logic, but also by employing entropy measures derived from information theory.

The Teradata parallel architecture was designed from the outset to support normalized databases.

Because of these factors, this chapter focuses on the principles of designing fully normalized databases. Significantly, other commercially available relational database engines cannot simultaneously achieve acceptable performance levels and support fully normalized physical database schemas.

Teradata Database architecture is optimized and parallelized so thoroughly that its performance is neutral with respect to the particulars of schema design (see Hurwitz Group, 1999), and the Optimizer attempts to generate an optimal query path irrespective of the physical schema of the database. For example, see SQL Request and Transaction Processing for a detailed explanation of the various star join optimizations available to the Optimizer. Of course, these optimizations cannot compensate for the update anomalies that exist in any database schema that is not fully normalized.

Furthermore, the appropriate application of views can effectively mask the underlying physical database schema from end users by presenting the look and feel of one or many very different virtual schemas (see “Dimensional Views” on page 136).