A Family of Mortises: Supertype and Subtype Patterns

Opening Scene

Every mortise in a joiner’s pattern book shares the same essential idea: a rectangular cavity cut to receive a tenon. But the family branches from there. A through mortise cuts all the way to the far face of the wood, visible from the other side once assembled. A blind mortise stops short, hidden entirely once the joint closes. A haunched mortise adds a shallow notch to resist twisting under load. Each variant is genuinely still a mortise — sharing the core cavity, the core purpose — while carrying its own extra detail that only that variant needs. A joiner doesn’t relearn “what a mortise is” for each one; they learn the shared core once, and the variant-specific refinements on top.

This is exactly the shape of a supertype and subtype relationship in data modeling.

In Plain English

A supertype/subtype pattern models an entity that has a shared core set of attributes, plus one or more variants that each carry additional attributes specific to themselves. A Vehicle supertype might hold attributes every vehicle shares — a VIN, a manufacture date, a color — while a Car subtype adds a trunk capacity, and a Truck subtype adds a towing capacity. Every car and every truck is genuinely a vehicle, sharing the vehicle-level data in one place, while each subtype’s own table (or discriminator column, depending on the implementation strategy) holds only what’s genuinely specific to it.

The Old Way

Before this pattern was well understood, teams handled variants of the same core entity in less disciplined ways:

• Some designs created entirely separate, unrelated tables for each variant — a CarTable and a TruckTable sharing no structure at all — duplicating every shared attribute and making it genuinely difficult to answer a simple question like “how many vehicles do we have in total.”
• Others crammed every possible variant’s attributes into one enormous table, leaving most columns null for any given row — a truck’s row with an empty trunk capacity, a car’s row with an empty towing capacity — creating a wide, sparse, confusing structure.
• The supertype/subtype pattern resolved both problems, giving the shared core one clean home while letting each variant’s own attributes live where they genuinely belong, queryable together or separately as needed.

Choosing the right implementation strategy — one table per subtype, one shared table with a type discriminator, or a hybrid — has always depended on how differently the subtypes actually behave and how often queries need to cross between them.

What’s Changing (and Why AI Is the Reason)

1. AI-assisted schema analysis tools can now detect a hidden supertype/subtype structure inside a wide, sparse table, recognizing clusters of columns that are only ever populated together for certain rows — a strong signal that what looks like one entity is actually several variants that would model more cleanly with a proper supertype/subtype split.
2. Generative AI coding assistants building object-oriented application code naturally reach for inheritance, and translating that inheritance correctly into a relational supertype/subtype schema is a common place AI-generated ORM mappings get the implementation strategy wrong — flattening genuinely distinct subtypes into one sparse table, or over-splitting a simple case into unnecessary separate tables.
3. AI agents querying across variant types increasingly need the supertype level to be genuinely and cleanly queryable on its own, since a question like “list every vehicle regardless of type” should be answerable without the agent having to know and union together every individual subtype table itself.

The Metaphor, Fully Extended

Joinery Element	ER Modelling Concept
The core rectangular cavity every mortise shares	The supertype entity, holding attributes common to every variant
The through-mortise’s extra visible far-face cut	A subtype’s own additional, variant-specific attributes
The blind mortise’s hidden, stopped cut	Another subtype, with its own distinct additional attributes
A pattern book entry titled simply “Mortise,” referenced by every variant	The supertype table, queryable on its own for anything true of every variant
A joiner scanning a stack of sparse, mostly-empty joint templates and recognizing they’re really one family with variants	AI-assisted detection of a hidden supertype/subtype structure inside a wide, sparse table

Quick Recap

• A supertype/subtype pattern models a shared core entity alongside variants that each add their own specific attributes, the same way every mortise shares a core cavity while each variant adds its own refinement.
• This avoids both unrelated duplicate tables and one enormous sparse table trying to hold every variant’s attributes at once.
• Choosing the right implementation strategy depends on how differently the subtypes behave and how often queries need to cross between them.
• AI tools can now detect hidden supertype/subtype structure in sparse tables, and reviewing AI-generated inheritance mappings for correct translation is a genuinely valuable check.

Where This Fits in the Series

Article 4 covered whether a relationship must exist; this article covered variants sharing a common core. Article 6 looks at a related but distinct idea — the same entity playing genuinely different roles depending on context.