Knowledge Hub

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.

The Unified Star Schema (USS) is an advanced dimensional modelling approach that enhances traditional star schemas by introducing a central structure known as the Puppini Bridge. This bridge aligns facts and dimensions into a single, consistent analytical framework, making queries more reliable, intuitive, and resistant to common join errors.

The primary goal of USS is to provide a unified query entry point that eliminates ambiguity when working with multiple fact tables. It simplifies drill-across analysis and ensures business users receive consistent results without needing deep SQL expertise.

In a traditional dimensional warehouse, each business process, such as Loan Approvals, Repayments, or Customer Interactions, typically has its own fact table. While dimensions may be conformed across these stars, combining multiple fact tables in a single query can lead to common modelling pitfalls:

Yes, you are right, you might have not heard, or implemented HOOKS before. This is a new term introduced by Andrew Foad.

HOOK is a technique to Data Warehousing especially proper to Data Lakehouse and virtualized architectures, but having said that it can be applied on any SQL based database. It is a hybrid methodology that borrows features from other methodologies such as Data Vault and Kimball dimensional modelling.

Whereas Data Vault and Kimball methodologies have multiple table types (Hubs, Links, Satellites, Dimension, Facts, etc.), HOOKS has a single structure called a Bag, which is used to wrap existing data warehouse table and exposes Business Keys which align to Business Concepts define in the Enterprise Data Model (EDM).

Bags align with data ingested into the data warehouse from the operational system (source-aligned) and Business Concepts defined in the Enterprise Data Model (business-aligned).

Metadata Modelling is the discipline of designing structured frameworks that describe data about data. It defines how business, technical, and operational descriptors are captured, organized, and related so that data assets can be understood, discovered, traced, and governed consistently across the enterprise.

The primary goal of metadata modelling is to establish a structured and standardized approach to cataloguing and managing metadata. By doing so, organizations can improve compliance, strengthen data governance, enhance data quality, and increase trust in analytical and operational systems.

Metadata modelling focuses on descriptors such as:

• Business definitions
• Data ownership and stewardship
• Lineage (upstream and downstream data flow)
• Data source systems
• Refresh frequency
• Sensitivity classification
• Quality rules and thresholds
• Storage location and format

Unlike ontologies, which emphasize semantic meaning and relationships between business concepts, metadata modelling emphasizes the management attributes of data assets. It does not primarily answer “What does a Loan mean?” but rather “Where does the Loan data come from?”, “Who owns it?”, “How often is it refreshed?”, and “Is it sensitive?”

Security & Access Control Modelling is the practice of defining structured rules and frameworks that determine who can access what data, under which conditions, and in what manner. It formalizes data protection through roles, permissions, entitlements, and policies aligned with organizational security requirements and regulatory obligations.

The primary goal of this modelling approach is to ensure that sensitive information is accessible only to authorized users while still enabling legitimate business access. It balances protection and productivity by translating business security rules into enforceable system controls.

At its core, Security & Access Control Modelling defines entities such as:

• Users (individual identities)
• Roles (grouped responsibilities or job functions)
• Permissions (allowed actions, such as read, write, approve)
• Policies (conditional rules governing access)

Typically, users are assigned to roles, roles carry permissions, and policies define constraints such as time of access, geographic location, or device type.

AI / Machine Learning Feature Modelling is the discipline of designing, structuring, and governing features, the measurable variables used as inputs to machine learning models. It defines how features are created, catalogued, versioned, and reused so that model inputs remain consistent, explainable, and trustworthy across the enterprise.

The primary goal of Feature Modelling is to provide a standardized and governed framework for engineering and managing features. Instead of allowing every data scientist to independently create slightly different versions of the same metric, Feature Modelling ensures that features are defined once, documented clearly, and reused consistently across multiple AI use cases.

In practice, raw transactional or external data is rarely fed directly into machine learning algorithms. It is first transformed into structured features such as:

• Customer credit score
• Average repayment delay
• Loan utilization ratio
• Officer approval rate
• Customer income stability index

Do We Really Need Data Modelling?

In recent years, a recurring question has surfaced in data conversations: Do we really need data modelling anymore? With cloud-native platforms, data lakes, AI pipelines, and schema-on-read architectures dominating the narrative, some assume modelling is optional, or even obsolete.

The reality is far simpler. There is no such thing as data without a model. Whether designed consciously or not, every system that stores data follows a structure. That structure, explicit or implicit, is a data model.

When we build operational applications, we design backend databases. These typically follow normalization principles, often in Third Normal Form (3NF). Customer data is stored separately from orders, orders from payments, and relationships are maintained through keys and constraints. This structure prevents redundancy, preserves integrity, and ensures consistency. That is data modelling in action.

A Data Glossary is a vital step towards mitigating the risk of creating a potential Data Swamp.

Data Glossary vs. Data Dictionary falls under the umbrella of Metadata Management.

• A Data Dictionary is a repository that houses the names, definitions, and attributes of data elements, providing critical contextual information about data.
• A Data Glossary, on the other hand, is a collection of terms that define the key characteristics of your data. These terms are organized in an easy-to-search format to facilitate quick understanding and access.

What Does a Data Glossary Contain?

A Data Glossary includes business terms that provide meaning and context. For instance, a table may have terms like region, sales, quantity, brand, and year. Anyone analysing this table will quickly understand that it relates to sales data, with quantities likely provided brand-wise at a regional level.

A comprehensive Data Glossary can refer to:

A Data Dictionary is the next step towards mitigating the Risk of a potential Data Swamp.

‘Data Dictionary comes under Metadata Management.’

In the IT World, we all know that new products and solutions keep coming year by year, so it's very important to capture what has been implemented. A Data Dictionary is one of the most important items for a system's impact analysis as it gives a clear picture of all the elements in the database.

With the introduction of Big Data where semi and unstructured datasets have come onto surfaces like video, audio, logs, emails, pdf & social media etc., so if one doesn't have a Data Dictionary in place then all future implementations will take 2x-3x more time.

Data Dictionary stores metadata information about databases like.

• List of all the objects and when each was created or updated.
• Details like field name, description, data type, length, indexes, primary & foreign keys etc.
• Relationships between tables, schema(s) and databases etc.
• Number of records in each table

We discussed the Data Dictionary and the Data or Business Glossary. What is Data Catalog?

‘Data Catalog comes under Metadata Management.’

Although all three Data Dictionaries, Data or Business Glossary and Data Catalog look similar, it's very important to understand the difference.

Data Dictionary stores metadata details about the solution and Data or Business Glossary is the collection of all business terms about the solution whereas Data Catalog jointly refers to Dictionary and Glossary like which business term is referring to which table or dashboard etc. In other words, Catalog gives a complete picture of both Dictionary and Glossary.

Let's take an example of a Bank Account Number (BAN).

• Data Glossary: BAN is the unique identifier for a customer across all banking applications whether it’s HR, Finance, Marketing etc.
• Data Dictionary: BAN is a unique identifier with field type as string, field length as 10, with two times # in it etc., metadata detail.
• Data Catalog: It tells the whole story i.e., BAN is the unique identifier for a customer across all banking applications and it is stored in tables i.e., x, y, and z, it is in which schema and database. And which department owns which databases, tables, dashboards, and reports etc.