CREATING THE PHYSICAL MODEL WITH SQL SERVER - A Developer's Guide to Data Modeling for SQL Server - page 206

Payments, which includes the subtypes CreditCards, GiftCards, and
BankAccounts.
Let's first look at Customers, which on the surface looks like an entity
that would work as a single table. In reality, the company wants to be able
to store multiple addresses for each customer. If you look at our model, we
can store only a single address for each customer. To remedy this, we cre-
ate a new table, named tbl_address, remove the address information from
tbl_customer, and set up a relationship between the two tables. The re-
sulting address and customer tables are shown in Figure 9.8.
F IGURE 9.8 The newly added address table and the customer table with
address information removed
As you can see, we can now store multiple addresses for each customer
and keep track of them by providing an address label such as “Home” or
“Work.”
As it happens, the Orders entity has a similar address problem. If you
look at the Orders entity in the logical model, shown earlier in Figure 9.7,
you will see that we are storing another set of address information. This is
the address that the order will be shipped to. If all our customer addresses
are stored in the address table, then putting an additional address in our
order table will cause us to have duplicate data, and we would be violating
the rules of normalization. Now we can simply delete the address detail
from Orders and replace it with a relationship to the appropriate record in
the address table.
We have one last change as it relates to addresses: Our employee table
also contains address detail. Even though we said that the employee table