COMMON DATA MODELING PROBLEMS - A Developer's Guide to Data Modeling for SQL Server - page 174

By adding attributes for the professor's name, phone number, and e-mail
address, we meet the requirements of the Class entity; that is, we are track-
ing the class's professor. However, if you look below the surface, you should
see some glaring problems. The biggest problem is that this setup violates
the rules of first normal form and all that goes with it. We have not suc-
cessfully separated our entities into distinct groups of information. We are
storing both class and professor data in the same entity. In these situations,
you need to split the entity along 1NF guidelines. Figure 8.4 shows the ap-
propriate way to store this information.
F IGURE 8.4 The Class entity with the professor information moved to a new
Professor entity
As you are building models or reviewing existing models, keep an eye
out for these types of situations. We all want our data models to be simple
and easy to understand, but don't oversimplify. Remember that the things
you are modeling have some level of complexity, and as a rule your model
should not be less complex than real life. Having a lot of entities doesn't
necessarily lead to a confusing model, so don't be afraid to include all the
entities you need to build an accurate representation of real life.
Too Many Entities
As you might expect, if having too few entities can be a problem, then hav-
ing too many entities can also cause headaches. The usual trap here is try-
ing to overnormalize a database. Although normalization is a good thing,
overnormalization can cause performance problems and limit the model's
flexibility. Adding extra entities in places that aren't obvious can sometimes
be a good thing, but you must fully understand the data and its usage be-