DATA MODELING OVERVIEW - A Developer's Guide to Data Modeling for SQL Server - page 16

elements simply describe the groupings of data as they might exist in the
real world; in contrast, physical elements actually store the data in a data-
base. A single entity might be stored in only one table or in multiple tables.
In fact, sometimes more than one entity wind up being stored in one table.
The various physical elements and the ways they are used are the topics of
Chapter 3, Physical Elements of Data Models.
Normalization
A well-designed data model has some level of normalization. In short, nor-
malization is the process of separating data into logical groupings.
Normalization is divided into levels, and each successive level builds on
the preceding level.
First normal form, notated as 1NF, is the most basic form of nor-
malization. In essence, in 1NF the data is stored in a table and each col-
umn contains one type of data. This means that any given column in the
table stores the same piece of information, such as a phone number.
Additionally, 1NF requires that your data have a primary key. A primary
key is the column or columns that uniquely identify the row. Normaliza-
tion can go up to six levels; however, most well-built models conform to
third normal form.
Generally, in this topic we talk about topics in linear order; you must
do the current one before the next one. Normalization is the exception to
this rule, because there is not really a specific time during modeling when
you sit down and normalize the model, nor are you concerned with the
level your model conforms to. For the most part, normalization takes place
throughout your modeling. When you start defining entities that your
model will have, you will have already started normalizing your model.
Sound transactional models are normalized, and normalization helps with
many of the other areas we have discussed. Normalized data is easier to re-
trieve, is consistent, is scalable, and so on. You must understand this con-
cept in order to build models, and we cover it in detail in Chapter 4,
Normalizing a Data Model.
Business Requirements
In Part II, we focus on gathering business requirements. I have said it be-
fore and you can be sure I will say it again: You are building a database for
a reason, and that reason should be to solve a business problem. To that
end, you must be able to extract the requirements from the company and