To Embed or Reference - MongoDB Applied Design Patterns - page 5

Now we're back to first normal form, but we had to introduce some redundancy into our data
model. The problem with redundancy, of course, is that it introduces the possibility of in-
consistency, where various copies of the same data have different values. To remove this re-
dundancy, we need to further normalize the data by splitting it into two tables: Table 1-5 and
Table 1-6 . (And don't worry, we'll be getting back to MongoDB and how it can solve your
redundancy problems without normalization really soon now.)

Table 1-5. Phone book v4 (contacts)

contact_id name zip_code

1 Rick 30062

2 Mike 30062

3 Jenny 01209

Table 1-6. Phone book v4 (numbers)

contact_id phone_number

1 555-111-1234

2 555-222-2345

2 555-212-2322

3 555-333-3456

3 555-334-3411

As part of this step, we must identify a key column which uniquely identifies each row in the
table so that we can create links between the tables. In the data model presented in Table 1-5
and Table 1-6 , the contact_id forms the key of the contacts table, and the (contact_id,
phone_number) pair forms the key of the numbers table. In this case, we have a data model
that is free of redundancy, allowing us to update a contact's name, zip code, or various phone
numbers without having to worry about updating multiple rows. In particular, we no longer
need to worry about inconsistency in the data model.