Knowledge Hub

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.

I am sure most of us know this term but not sure how accurate you are in terms of its importance.

‘The granularity of data means, the levels of data breakdown.’

Generally, people think having all relevant details about an entity is Granularity, but the question is what level of details?

For example, details can be name, email, and contact number, date of birth, color, blood group, home address, company, role, salary, father name, mother name and so. Is this the lower level of granularity? NO, when we say the lowest level of granularity, we can break down.

• Name into First Name, Middle Name and Last Name
• Address into Apartment Number, Building Name, Street, Area, City, District, Region, Country, Postal Code etc.

In OLTP systems, granularity must go as low as possible and in OLAP systems, it can depend on the business use case.

Now, when we have established what the Granularity is, let's discuss when it's needed. Data Wrangling, Data Mining, Data Science etc., all use raw data for analysis and analytics. And when we say RAW, the lower the level of granularity can be, the better the model result will be for DSS.

As the name says itself, these are traps. If we have Chasm or Fan Traps, then we have a serious problem as these can impact the whole data model.

‘Chasm and Fan Trap lead to Cartesian Data.’

Fan Trap: In Fan Trap, the model ends up having ‘One to Many’ relationship in more than two tables e.g., One Customer having Many Orders and One Order having many Order Products which is logically fine but if physical data model is created like 1) Customer with Order ‘One to Many’ 2) Order with Order Product also ‘One to Many’ then it’s not fine. It’s a Fan Trap.

• Issue: In this scenario, Order Id (Pkey) has been added in Order Products tables as Fkey which means there will be Low Cardinality in Order products tables means there will be duplication of Product in Product’s table which is a wrong approach. In the Products table, Product ID should be unique.
• Solution: One Product can have Many Orders but not the other way. The correct approach is to have Product ID (Pkey) from Order Products table as Fkey in Orders table.

This is a normal term for database modelers, but business users are not very familiar with it. Understand this and it will solve your 90% data problems. Don’t have good Data Model and you must deal with Chasm and Fan Traps.

Data Cardinality is about maintaining the level of details in a table. There are 2 types of Data Cardinality.

• High Cardinality: It is when there are no or less duplicates in a table. Tables with Pkey are mostly in Highest Cardinality mode.
• Low Cardinality: It is when there are high number of duplicates in a table. Tables with Fkey are mostly in Low Cardinality mode.

For example, Product table with details like Product ID, Product Name, and Product Manufactured Date etc. It can contain hundreds of products, but at the same time, a particular product cannot be repeated as it’s already in the table right. So, now we can say this table has High Cardinality. Referring to the same example if Product is there then one must sell it too. Sales of the products can be stored in a Sales table. Now, 1 type of product can be sold many times right. So, Sales tables can contain thousands of rows where hundreds of rows can be for 1 product means Product ID will be repeated in this Sales table so we can say this table is in Low Cardinality with respect to Products.

Another term, if data modelers are not aware and if data model doesn’t take care via proper Data Cardinality check and balance, data analysts are hit by Chasm and Fan Traps.

We know what Data Modelling is. We know what Data Cardinality is. Now, it’s time to understand Cartesian data which give nightmares to Finance department when they manually know the total is USD100k but when they run query, they see USD200 k 😊.

‘Cartesian Data is about writing a query on tables with ‘Many to Many (M:M)’ relationship.’

If there are two tables with ‘Many to Many’ relationship, it’s time for data modeler to introduce an intermediary table which can have unique records and then can have ‘One to Many’ relationship with previously used two tables.

If the Sales table is joined with Target tables directly based on Employee ID then surely there will Cartesian data as both Sales and Target tables can have more than 1 employee ID. But hang-on, even having intermediary table, if query is written wrongly then still data analyst can hit with Cartesian data know as Chasm Trap.

Data Hierarchy is a known term and most of us are aware of it but sometimes, it’s confused with Data Taxonomy & Data Ontology.

Data Taxonomy and Data Ontology are metadata for the purpose of Data Governance whereas Data Hierarchies presents actual data. A very well-known and famous example is the Organizational Chart where hierarchy starts from CEO and goes down to Database Administrator in data domain.

• ‘Data Taxonomies apply to identified objects or phenomena.’’
• ‘Data Ontologies apply to terms, concepts, or categories.’
• ‘Data Hierarchy is a chain of relationship in actually data.’

Family tree is another simple example.

Data can be grouped in a way where data exploration and representation become easy. For example, at database level, hierarchy can be Database 🡪 Files/ Tables 🡪 Records 🡪 Fields/ Columns 🡪 Bytes 🡪 Bits.

Same line Data Taxonomy, Data Hierarchy also have single parent and multiple child relationship among the rows of dataset.

This topic is very close to many experienced data modelers because it is surprisingly misunderstood. The confusion usually begins with one assumption: if both systems use Third Normal Form (3NF), then they must be conceptually the same. They are not.

In data architecture, the Data Warehouse concept popularized by Bill Inmon embraces the use of 3NF. Since 3NF is also widely used in OLTP systems, many architects assume the modeling philosophy and operational behavior are identical. The structure may look similar, but the intent, behavior, and lifecycle of data are fundamentally different.

OLTP 3NF: Designed for Transactional Efficiency

In an OLTP (Online Transaction Processing) system, the objective is operational efficiency. The system must support high-volume, real-time transactions such as order placement, payments, inventory updates, and customer modifications.

The primary goals are:

• Fast inserts, updates, and deletes
• Concurrency control
• Storage optimization
• Data consistency for current state