Domain tables are a special type of table in data modeling. They contain
knowledge known a priori about the application’s
domain, and the contents within these tables don’t normally change through
interaction with the application. In our data model, we already have an
example of a domain table: the
table. Regardless of what our application looks like or how it changes
over time, regardless of what data we intend to store about users, movies,
or orders, the set of ratings and their meanings in the context of the
domain of motions pictures is set.
Domain tables are particularly special because at first glance they can seem extraneous. Since they don’t change frequently, you could encode the data they contain in application code rather than directly in the database. In fact, many beginners to data modeling leave out domain tables completely, preferring to store the concepts they encode in the code itself. However, promoting domain data to fully fledged relational tables and records provides numerous benefits.
First, domain tables play a key role in helping to maintain
referential integrity. If multiple tables reference ratings, having them
defined once in a single table ensures that all tables reference the same
set. If multiple tables have a text column for the movie rating as our
movies table did at the start of Chapter 5, it would be very easy for each table to store different sets of ratings, perhaps “PG-13” in one table, and “pg13” in another. It would ...