Decomposing Relations | Database Design | Teradata Vantage - 17.10 - Decomposing Relations - Advanced SQL Engine - Teradata Database

Teradata Vantageā„¢ - Database Design

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
July 2021
Language
English (United States)
Last Update
2021-07-27
dita:mapPath
kko1591750222108.ditamap
dita:ditavalPath
kko1591750222108.ditaval

The principal goal of normalization is to eliminate update anomalies. By decomposing your relations into normalized forms, you can eliminate the vast majority of update anomalies.

Advocates of dimensional modeling argue against the method of decomposition because normalization tends to produce many relations. This is an implementation issue, not a logical design issue, and it originates in the inability of most vendor database products to make reasonably high-performing joins.

When you design enterprise database schemas using the dimensional model (see Dimensional Modeling, Star, and Snowflake Schemas), you create only a few fact relations with a composite primary key that is not free of transitive dependencies (see Functional, Transitive, and Multivalued Compatibilities), and smaller satellite relations called dimensions that contain detailed data about the fact relation.

An enterprise schema design using the dimensional model (see Dimensional Modeling, Star, and Snowflake Schemas) creates only a few fact relations with a composite primary key that is not free of transitive dependencies (see Functional, Transitive, and Multivalued Compatibilities), and smaller satellite relations called dimensions that contain detailed data about the fact relation.

Decomposing Relations for an Inherently Parallel Database Environment

Because the Vantage architecture is inherently parallel and optimized for join performance, it suffers no performance deficits when dealing with a physical schema that has been mapped directly from a normalized logical design.