Supertype/Subtype Pattern
One design pattern that's not used
often enough is the supertype/subtype pattern. The supertype/subtype
pattern is also perfectly suited to modeling an object-oriented design
in a relational database. For the application this model provides
advantages that may not be realized with the traditional relational
database design patters. However, because this model has the potential
to increase the number of tables by several times, writing queries for
reporting purposes could become an arduous task. Figure 6 provides a detail illustration of this method.
The supertype/subtype relationship leverages the
one-to-one relationship to connect one supertype entity with one or
more subtype entities. This extends the supertype entity with what
appears to be flexible attributes.
The textbook example is a database that needs to
store multiple types of contacts. All contacts have basic contact data
such as name, location, phone number, and so on. Some contacts are
customers with customer attributes (credit limits, loyalty programs,
and so on). Some contacts are vendors with vendor-specific data.
Although you can use separate entities for customers and vendors, an alternative design is to use a single Contact
entity (the supertype) to hold every contact, regardless of their type,
and the attributes common to every type (probably just the name and
contact attributes). Separate entities (the subtypes) hold the
attributes unique to customers and vendors. A customer would have a
tuple (row) in the contact and the customer entities. A vendor would
have tuples in both the contact and vendor entities. All three entities
share the same primary key (refer to Figure 6).
Sometime data modelers who use the supertype/subtype pattern add a type
attribute in the supertype entity, so it's easy to quickly determine
the type by searching the subtypes. This works well but it restricts
the tuples to a single subtype.
Without the type
attribute, you can allow tuples to belong to multiple subtypes.
Sometimes, this is referred to as allowing the supertype to have
multiple roles. In the contact example, multiple roles (for example, a
contact who is both an employee and customer) could mean the tuple has
data in the supertype entity (for example, contact entity) and each
role subtype entity (for example, employee and customer entities).
5. Domain Integrity Lookup Pattern
The domain integrity lookup pattern,
informally called the lookup table pattern, is common in production
databases. This pattern serves to only limit the valid options for an
attribute, as illustrated in Figure 7.
The classic example is the state, or
region, lookup entity. Unless the organization regularly deals with
several states as clients, the state lookup entity serves only to
ensure that the state attributes in other entities are correctly
entered. Its only purpose is data consistency.
