Anchor Data Modelling

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

These methodologies aim to design data models that are flexible, scalable, and adaptable to changing business requirements. Anchor Data Modelling focuses on simplifying the Modelling process, improving data governance, and ensuring data consistency while supporting agile data integration and analytics.

The modelling process in the Anchor methodology is organized into below list of elements from which main are Anchor, Knot and Attribute.

The main elements of Anchor Data Modelling, as you mentioned, include Anchor, Knot, Attribute, and Tie. Below is an elaborate explanation of each of these elements:

1. Anchor

The Anchor is the fundamental building block of Anchor Data Modelling. It represents a core entity or concept that exists over time and is independent of other attributes. Anchors are stable and persistent throughout their lifecycle.

• Definition: Anchors represent the key business entities or subjects, such as Customer, Product, Order, Employee, etc.
• Purpose: The Anchor serves as the focal point of the model and is the foundation for structuring other components like Attributes and Knots.
• Characteristics: Anchors typically are associated with the "business keys" (unique identifiers) that define the core object. For example, a Customer Anchor could have a business key like Customer_ID.

2. Knot

The Knot is used to represent a value set or reference data. It holds the possible values for certain business attributes that could change or evolve over time.

• Definition: A Knot defines a reference domain or a category to which an Anchor entity can be related. It is essentially the "values" that an Anchor might be associated with.
• Purpose: The Knot provides a way to manage and track discrete values (such as status codes, geographical regions, or categories). These values could be updated or replaced over time, and the model can still maintain historical accuracy.
• Example: If the Anchor is Customer, a Knot could be Customer_Status, with values such as "Active", "Inactive", "Pending", etc.

3. Attribute

Attributes provide further detail or properties about the Anchor and describe characteristics of business entities. The Attribute element is crucial for capturing additional information associated with an Anchor.

Types of Attributes:

Attributes in the Anchor Data Modelling methodology can be categorized into two types:

a) Static Attribute

• Definition: A Static Attribute is an attribute whose value remains constant over time for an Anchor. It doesn’t change, even as the Anchor entity evolves.
• Purpose: Static Attributes typically represent key details or properties of an entity that are fixed, like a Customer's Name, Date of Birth, or Gender.
• Example: In a Customer Anchor, a Static Attribute could be Email_Address or Phone_Number.

b) Horizontal Attribute

• Definition: A Horizontal Attribute is an attribute whose value may change over time but is still related to an Anchor. The "horizontal" terminology comes from the idea that such attributes might vary horizontally (across different time periods).
• Purpose: Horizontal Attributes are used for values that represent metrics, amounts, or other characteristics that can evolve or fluctuate.
• Example: A Customer Anchor might have a Horizontal Attribute called Customer_Score (e.g., credit score), which can change over time.

4. Tie

Ties are used to define relationships between Anchors, representing how different entities are connected. Ties allow data models to track the associations between different Anchors, often indicating how one business entity links to another. The Tie element is what makes the model relational and is used to indicate the history of relationships.

Types of Ties:

There are two primary types of Ties in Anchor Data Modelling:

a) Static Tie

• Definition: A Static Tie is a relationship between two Anchors that remains constant over time. The link does not change, even though the data linked might evolve.
• Purpose: Static Ties can represent fixed relationships like Customer-Product associations, where a specific customer always has access to a certain product.
• Example: A Customer Anchor may have a Static Tie to a Product Anchor representing a product the customer has purchased.

b) Historical Tie

• Definition: A Historical Tie represents a relationship that changes over time. The historical tie tracks the state of a relationship, capturing historical associations between different Anchors.
• Purpose: Historical Ties allow the model to track and maintain the context of relationships over time, which is essential for handling time-series data or tracking changes.
• Example: A Customer Anchor might have a Historical Tie to a Sales_Region Knot to capture the region in which a customer made purchases during different periods (i.e., over time).

Summary of the Anchor Data Modelling Elements

Key Benefits of Anchor Data Modelling:

• Flexibility: ADM allows for a highly flexible model that can adapt to changing business needs without breaking existing data structures.
• Simplicity: The structure of Anchor, Knot, Attribute, and Tie makes it easy to understand and model complex relationships.
• Historical Accuracy: By using Historical Ties, Anchor Data Modelling ensures that changes in relationships or values over time are tracked accurately.
• Scalability: It works well for large datasets and allows data architects to handle big data environments, ensuring that new data sources can be integrated easily.
• Agility: ADM can be implemented and adjusted iteratively, making it suitable for environments that require rapid adaptation to business changes.

In conclusion, Anchor Data Modelling is a methodology that simplifies the design of complex data models and ensures that they are scalable, adaptable, and maintainable over time. By using Anchors, Knots, Attributes, and Ties, organizations can build data models that are not only easy to understand but also capable of tracking changes in business entities and relationships effectively.

Podcast

“In Anchor Modelling, every attribute table is temporal by design: ValidFrom/ValidTo capture business reality, and LoadDate captures when the system recorded it. All three fields together make Anchor Modelling a bi-temporal framework by default, not by exception.”

Loan Approval Example (Anchor Modelling Structures)

• Anchor_Loan → {LoanID}
• Anchor_Customer → {CustomerID}
• Anchor_Officer → {OfficerID}
• Tie_LoanCustomer → {LoanID, CustomerID}
• Tie_LoanOfficer → {LoanID, OfficerID}
• Attr_LoanAmount → {LoanID, LoanAmount, ValidFrom, ValidTo}
• Attr_InterestRate → {LoanID, InterestRate, ValidFrom, ValidTo}
• Attr_Status → {LoanID, StatusKnotID, ValidFrom, ValidTo}
• Knot_Status → {StatusKnotID, StatusValue}

If a loan’s interest rate changes from 7.5% to 8.0%, the old value stays in Attr_InterestRate with its validity range, and the new row is added, preserving full history. Likewise, Attr_Status always points to a Knot (e.g., Pending → Approved), ensuring semantic consistency across the model.

How it Reads

• Anchors store the stable identifiers of entities (Loan, Customer, Officer).
• Ties link those anchors together (Loan–Customer, Loan–Officer).
• Attributes historize descriptive properties (LoanAmount, InterestRate, Status) with ValidFrom/ValidTo ranges.
• Knots hold reusable, stable domain values (Pending, Approved, Rejected), referenced by attributes.

So, if a loan’s interest rate changes from 7.5% to 8.0%, the old value remains in Attr_InterestRate with its validity range, and a new row is added, preserving history. Similarly, when a loan moves from Pending → Approved, Attr_Status points to the correct Knot ID, ensuring semantic consistency across all systems.