Pattern: Single Table Aggregation


The pattern shows how to map aggregation to a relational data model by integrating all aggregated objects’ attributes into a single table.


Consider the following object model:

Figure 1: An AddressType aggregated by more than one other types


How do you map aggregation to relational tables?



Put the aggregated object's attributes into the same table as the aggregating object’s.


The AggregatingObject is transformed to a table of the physical data model. The AggregatedObject’s Attributes are integrated into that table.

Example Resolved

To resolve our above example we look at the table created for the Customer object. The InvoiceAddress and the DeliveryAddress are both integrated into the Customer’s database table.

Figure 2: Mapping an aggregated object type into the aggregating object’s table

A prefix is used to distinguish the attributes. This is similar to the resolution of structures in C++, using a dot notation (like Customer.DeliveryAddress.Street).




We have discussed the simple case of a 1:1 relation between aggregating object type and aggregated object type. See Foreign Key Association for how to map a 1:n relation between aggregating object and aggregated object. See also Overflow Table [Kel+97 ] for a trick to avoid using foreign key associations in case of 1:n relations.

Related Patterns

Foreign Key Aggregation is an alternative solution to Single Table Aggregation. See also Representing Collections in a Relational Database [Bro+96]. When applied to ordinary relational database access layers, it can be compared to Denormalization [Kel+97 ].

Further Reading

Mainstream Objects”, a book by Ed Yourdon et al. [You+95] dedicates its whole chapter 21 to the question of when and how to use aggregation versus associations at the modeling level.