Original Teradata Design Goals Strongly Coupled With Normalization
Two of the principal design goals for the original Teradata parallel architecture were:
Teradata has always promoted full database normalization. The reasons for this unwavering support for fully normalized databases include the following factors:
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 186).