Focal Point Data Modelling

Just like Data Vault, Focal Point Data Modelling also belongs to the family of Ensemble Data Modelling.

The modelling process in the Focal methodology is organized into five distinct stages, referred to as the Focal Forms:

• Focal Form One – Identify and define the primary business concept entities.
• Focal Form Two – Identify and define the natural business relationships between the core business concepts.
• Focal Form Three – Identify the attributes of the core business concepts, focusing on capturing terms or attributes that are categorized as descriptive characteristics of the business concepts.
• Focal Form Four – Group the attributes into Descriptor Concepts. This step is unique to Focal, as it emphasizes good definition practices. The task is to categorize attributes into one of 10 predefined Descriptor Concepts, each with a specific definition. For example, one such descriptor concept is Condition, which is a qualifying attribute related to a Focal. A Condition serves two main purposes: (1) it imposes constraints or modifications on the Entity’s characteristics or behaviour, and (2) it specifies requirements that must be met by the Entity. These Conditions are often established through agreements between relevant parties regarding specific Focal members. In practice, Conditions take the form of concrete parameters that influence business relationships or transactions. For instance, in a Contract Focal, the start date acts as a temporal Condition; in a Loan Focal, the interest rate represents a financial Condition; and in an Order Focal, the payment date serves as a temporal Condition that needs to be met.
• Focal Form Five – Atomic Context. Determine which attributes group together at the most granular level, answering a specific atomic question. This step is crucial for physical implementation, as it helps identify attribute sets that consist of a small number (usually no more than five) of related attributes.

The Focal implementation pattern.

Physical Descriptor Table Pattern

Instantiation of the Table Pattern as a Focal Customer Descriptor Table

The Focal implementation pattern follows a Physical Descriptor Table Pattern, which is instantiated as specific tables, such as a Focal Customer Descriptor Table.

Once the physical data model is implemented in Focal Point Modelling, it typically remains stable, with minimal changes thereafter unlike in Data Vault, where the physical model tends to evolve more frequently.

“In Focal Point Modelling, Descriptors can be temporal: ValidFrom/ValidTo capture the period when a loan term or officer detail was true in business reality, while LoadDate (if included) records when the system ingested the change. Unlike Anchor, historization is not enforced on every Descriptor, but when applied, Focal models provide temporal tracking with less rigidity and more business-friendly structures.”

How It Reads

• Focal_Loan defines the central entity (L001, L002).
• Relations link each loan to a Customer and an Officer.
• Descriptors capture historized loan terms and officer details

Podcast

Scenario#1:

If business requirement is only to focus on one Entity e.g., Loan, then that will Loan will have One Focal along with its own Descriptor details. Now, as part of the same requirement, if we also need Officer details which need to go via Officer Entity, so we will have Relation (table) i.e., LoanOfficer to host LoanID and OfficerID, which will than have its own Descriptor for Officer details.

Scenario#2:

If business requirement is to focus on more than one Entity e.g., Loan, Customer, and Officer then that will be One Focal for each Entity which then will be able to join via Relation (table). Then of course, each focal will have their own Descriptor tables

DIMENSIONAL & ENSEMBLE MODELLING VS TEMPORAL DATA MODELLING

Temporal Data Modelling is not a competing “family” like Dimensional (Kimball) or Ensemble (Data Vault, Anchor, Focal Point). It is a principle that elevates time to a first-class citizen across the entire schema. In a fully temporal design, every entity and relationship can carry explicit time attributes such as ValidFrom/ValidTo (valid time) and TxnStart/TxnEnd (transaction time). This enables bi-temporal queries by design and supports both operational (OLTP) and analytical (OLAP) use cases.

To understand the distinction clearly, it is useful to compare their intent and scope.

Dimensional Modelling (Analytics Lens)

Dimensional modelling focuses primarily on analytics and reporting. It structures data into facts and dimensions for fast aggregation and business-friendly querying. Historical tracking is handled through techniques such as Slowly Changing Dimensions (SCD Types 1–6). However, temporal handling in dimensional models is typically partial and attribute-level. Time is present, but it is not systemic across every entity and relationship.

In a loan approval example, a Fact_LoanApproval table records approval events. A Dim_Customer table may use SCD Type 2 to track address or segment changes over time. History is supported, but primarily for reporting needs.

Dimensional modelling excels at dashboards and performance-focused OLAP queries. Its weakness is that temporal handling is often “bolted on” rather than deeply embedded in the model’s structure.

Ensemble Modelling (Enterprise Historization Lens)

Ensemble techniques such as Data Vault, Anchor, and Focal Point prioritize enterprise integration and full historization. History is baked into the design. In Data Vault, Satellites store time-variant attributes by default. In Anchor modelling, attributes are historized at a granular level. Time is not optional; it is inherent to the modelling pattern.

In a loan approval environment, Hubs represent Loan and Officer entities. Links capture their relationships. Satellites store evolving LoanTerms or Status changes with timestamps. The model preserves complete lineage and supports audit and compliance needs.

Ensemble modelling is scalable and highly auditable but may be complex for casual analysts. It is optimized for integration and governance rather than immediate reporting simplicity.

Temporal Modelling (Cross-Cutting Principle)

Temporal modelling goes a step further. It treats time as an explicit dimension of truth across all entities and relationships. Any entity-Loan, Customer, Officer, or relationship, Loan–Officer approval, can carry both valid time (when the fact is true in the real world) and transaction time (when the system recorded it).

This enables powerful queries such as:

• What did we believe on February 1 was valid on January 15?
• What interest rate was considered effective at the time of approval, and when was that decision recorded?

Unlike dimensional or ensemble modelling, temporal modelling is not a schema by itself. It must be applied within relational, dimensional, or ensemble structures. It acts as a design principle above them.

Comparative View

In summary, Dimensional modelling provides the analytics lens, Ensemble modelling provides enterprise historization, and Temporal modelling provides the time-aware foundation that can strengthen either approach. Temporal modelling does not replace dimensional or ensemble methods, it enhances them by ensuring that time is explicitly and consistently modelled across the entire data landscape.