John Giles’ Data Model Patterns — Now Available in SqlDBM

At SqlDBM, we believe the best data modeling starts with understanding the business — not reinventing the wheel. That’s why we’re excited to announce that we’ve partnered with John Giles to bring his proven Data Model Patterns into SqlDBM, giving our users a powerful head start on their modeling projects.

Who Is John Giles?

John Giles is an Australian data modeling expert with decades of hands-on experience helping organizations get their data architecture right. He is the author of several acclaimed books, including The Nimble Elephant (on Agile data modeling), The Elephant in the Fridge (on Data Vault modeling), and The Data Elephant in the Board Room — a practical guide to building business-centered data models that deliver real value.

John’s core philosophy is simple: data modeling should be driven by the business, and modelers shouldn’t waste time solving problems that have already been solved. In The Data Elephant in the Board Room, John presents a collection of reusable data model patterns covering universal business concepts — from Parties and Products to Events and Agreements. These patterns serve as a proven foundation that can be adapted to virtually any organization or industry.

The idea behind these patterns is to help you quickly establish a “Data Town Plan”—a high-level map of the business concepts your organization manages and how they relate to one another. Instead of starting from a blank canvas every time, you begin with structures that have been refined across hundreds of real-world implementations. From there, you can make informed decisions about where to invest deeper modeling effort and how to derive your detailed logical and physical designs.

Patterns Matter – Stop Reinventing the Wheel

Every organization deals with people, products, agreements, events, and accounts in some form. Yet modeling teams routinely spend weeks building these foundational structures from scratch—often repeating design mistakes that others have already solved.

John’s patterns change that equation. They give you a battle-tested starting point that captures the essential relationships and attributes for each business domain. You can adopt them as-is for rapid prototyping, extend them to match your specific business rules, or use them as a reference to validate your existing designs. Either way, they accelerate your time-to-value and reduce the risk of structural missteps that become costly to fix later.

With these patterns now available directly in SqlDBM, your team can import a proven foundation and begin customizing it in minutes rather than days.

The Data Model Patterns

Below is the complete set of John Giles’ Data Model Patterns as they appear in SqlDBM. Each pattern addresses a fundamental business domain that you’ll encounter across virtually every industry.

Party

The Party pattern is arguably the most universally applicable model in any enterprise. It provides a unified structure for managing information about people and organizations — essentially, anyone your business interacts with. The pattern treats persons and organizations as entries in a sophisticated address book, supporting party types, identifiers, and the critical distinction between person and organization names.

What makes this pattern especially powerful is its extensibility. The foundation supports recording inter-relationships between parties—employment relationships between a person and an organization, ownership hierarchies between holding companies and subsidiaries, parent-child relationships between individuals, and any other party-to-party connection your business needs to track. If your organization interacts with customers, employees, vendors, regulators, or any combination of stakeholders, this pattern provides a robust starting point.

Address

The Address pattern addresses the complex challenge of managing contact information across multiple channels and formats. Rather than treating addresses as simple text fields bolted onto a person record, this pattern models addresses as first-class entities with their own lifecycle.

The pattern distinguishes among physical addresses, postal addresses, email addresses, and phone numbers—each with its own attributes—while unifying them under a common Address entity. It introduces the concept of an Address Service, which links a Party to an Address with a specific usage type (billing, shipping, home, work) and effective dates. This means you can track when a customer changed their mailing address, maintain multiple active addresses for different purposes, and support the full range of address service types your business requires.

Agreement

The Agreement pattern captures the formal and informal contracts that govern business relationships. Every organization operates through agreements—employment contracts, service-level agreements, purchase orders, leases, and partnerships —and the challenge is modeling them in a way that’s both flexible and consistent.

This pattern provides a type-driven structure in which the Agreement entity connects to an Agreement Type hierarchy, allowing you to classify agreements at the level of granularity your business requires. It supports agreement items (the individual line items or terms within an agreement), participation records that track which parties are involved and in what capacity, and agreement-to-agreement relationships that capture dependencies between contracts. The subtype examples shown (such as Employment Contract) are illustrative only —each organization will define its own agreement taxonomy based on its specific needs.

Account

The Account pattern addresses the management of financial accounts and their transactions. This domain appears not only in banking and finance but in any organization that tracks financial activity, from customer billing systems to internal cost centers.

The pattern separates the Account (with its type hierarchy and balance tracking) from the Accounting Transaction (with its line items and entries). It includes Account Participation, linking accounts to the parties that own or manage them, and the Accounting Entry structure that supports proper double-entry allocation across accounts. The pattern also accommodates account hierarchies through self-referencing relationships, enabling you to model parent-child account structures, chart of accounts rollups, and consolidated reporting views.

Product

Products are easy to describe in conversation, but often surprisingly difficult to model well. The Product pattern provides an elegant solution that separates the “category” of product (Product Type) from the “instance” of product (Product Item), which represents either a physical item or a specific instance of a service.

This distinction is critical because it allows you to define a product catalog with pricing, descriptions, and effective dates at the type level, while tracking individual serial numbers, inventory items, or service deliveries at the item level. The pattern further decomposes products into goods components and services components, supports product bundles through a subproduct composition structure, and cleanly handles the goods-vs-services distinction that trips up many modeling efforts. Whether you’re modeling a retail catalog, an insurance product suite, or a SaaS subscription portfolio, this pattern gives you the structural foundation to get it right.

Event

The Event pattern models noteworthy occurrences—events that someone deemed important enough to record. In John’s words, an event is fundamentally an occurrence that someone decided was worth tracking.

The pattern supports hierarchical classification of event types, event-to-event relationships (capturing causal chains, escalations, or sequences of related events), and subtypes for domain-specific event categories, such as Observation Events, Safety Incidents, and Communication Events. The effective period tracking uses timestamps rather than dates, accommodating events that need to be recorded with precision. This pattern is invaluable for audit trails, incident management, compliance tracking, customer interaction histories, and any domain where understanding what happened and when is central to the business.

Task

The Task pattern represents actual or planned work and is the backbone of project and workflow management systems. What makes John’s approach particularly insightful is the clear differentiation between Template Tasks and Specific Tasks.

Template Tasks represent standard workflow specifications — the reusable process definitions that describe how work should be done. Specific Tasks are the actual work to be completed, cloned from templates and assigned to specific parties and resources. The pattern includes comprehensive scheduling support (planned early/late start and finish, actual start and finish), task dependencies with predecessor/successor relationships and lag times, calendar integration for work scheduling, recurrence specifications, and the ability to link tasks to triggering events. The object-to-task assignment structure supports assigning both individual parties and party role types, making it suitable for both named resource allocation and role-based staffing models.

Document

The Document pattern manages the lifecycle and relationships of both hard-copy and electronic documents, affecting every organization, regardless of industry.

The pattern models documents with type and format classifications, supports document-to-document relationships (versions, translations, supplements, amendments), and cleanly separates physical documents from electronic documents through a subtype hierarchy. Electronic documents are further classified as structured or unstructured. The inclusion of an Agreement Document association demonstrates how documents relate to other business entities—linking contracts to their supporting documentation, for example. This pattern provides the foundation for document management systems, regulatory filing archives, knowledge bases, and any scenario where tracking what was documented, in what format, and how documents relate to one another matters to the business.

Classification

The Classification pattern tackles one of the most pervasive challenges in enterprise data modeling: how to manage the codes, categories, and reference data that classify everything else. Rather than creating dozens of separate lookup tables, this pattern provides a unified structure for all classification schemes.

The pattern introduces Classification Schemes (systems of categorization, such as industry codes, risk ratings, and status codes), Classification Codes (the individual values within each scheme), and a Classification Code Hierarchy that organizes codes into parent-child trees within and across schemes. It supports both discrete value classifications and range-based classifications, making it equally suitable for categorical data (e.g., product categories, customer segments) and numeric ranges (e.g., tax brackets, age bands, credit score tiers). The scheme’s allowable hierarchy structure even governs which classification schemes can relate to one another, providing a metadata layer for managing your reference data governance.

Position

The Position pattern models organizational structure by defining roles within an organization, independent of the individuals who fill them. This is a critical distinction that many organizations get wrong by conflating a person with their job.

The pattern separates the Position (a defined role within an organization, such as “CFO” or “Senior Developer”) from the Position Assignment (the assignment of a specific person to that position, including the incumbency type and percent allocation). The Position Hierarchy captures reporting relationships between positions — not between people — allowing you to maintain a stable org chart even as individuals come and go. Effective period tracking across both positions and assignments enables you to model organizational changes over time, support future-dated restructuring plans, and maintain a complete history of how your organizational structure has evolved.

Resource

The Resource pattern models the assets and resources that an organization owns, manages, or utilizes. Examples include buildings, vehicles, computers, equipment, consumables, and any other tangible or intangible asset that needs to be tracked.

The pattern provides a clean type-driven structure with a Resource entity linked to a hierarchical Resource Type classification. Each resource carries an identifier, a name, and effective period dates for lifecycle management. While compact, this pattern serves as the anchor point for more complex structures — resources can be assigned to tasks (as shown in the Task pattern), allocated to positions, associated with locations, and linked to maintenance agreements. Its simplicity is intentional: it provides a stable core that you can extend to meet your specific asset management requirements.

Copyright and Attribution

Important: These data model patterns are used in SqlDBM with the express permission of John Giles. John retains all ownership and original copyright of these patterns and their associated intellectual property.

We encourage you to explore the full depth of John’s thinking by purchasing his book:

📘 The Data Elephant in the Board Room— available at technicspub.com/data-elephant

Use code “SqlDBM” at checkout for 25% off.

The book provides extensive explanation, context, and “how-to” guidelines to help readers build their own Data Town Plan. Steps include forming a tight team, delivering initial value (potentially within weeks), and enabling ongoing alignment of the business vision with the progressive delivery of IT solutions.

How to Get These Patterns in SqlDBM

These model patterns are available by request to SqlDBM users. Whether you’re an existing customer looking to accelerate a new project or evaluating SqlDBM for the first time, we’d love to get these patterns into your hands.

Our team can walk you through the patterns, help you identify which ones are most relevant to your project, and load them into your SqlDBM workspace so you can start building on a proven foundation right away. Whether it’s patterns, templates, or complete industry models, SqlDBM can accelerate your modeling journey.

Get in touch with us to learn more