Databases and Data Modeling
As was noted in chapter 1 (see “The Heart of the Data Warehouse” on page 19), the heart of any data warehouse is its database. A data warehouse is a set of processes about a population of data. That population of data is its underlying database.
The usefulness of a data warehouse is directly proportional to the quality of the database that supports it.
The purpose of this manual is to provide guidelines to help you design a Teradata Database that provides any user of the warehouse with all of the following characteristics:
These attributes can only be achieved by careful collection and analysis of requirements and through careful planning of how to implement those requirements. The name used to describe the planning of the structure and relationships of a database is data modeling. Note that the expression data model has two very different meanings. In the original definition, a data model is taken to be a set of abstract constructs that can be applied to many different specific applications. Examples would be the relational and CODASYL models for database management. In the case described in this section, the term refers to logical database modeling, which is a specific application of the properties provided by the relational data model. An analogy that is sometimes made is that a data model in the first sense is akin to a programming language while a data model in the second is akin to a particular application program written in a particular programming language.
Data modeling comes in two modes: logical and physical.