Subjective andObjective Data Modelling

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.

Later, when operational data flows into analytical environments, data warehouses, lakehouses, semantic layers, or BI platforms, new modelling decisions are made. We may reshape the data into a star schema, snowflake schema, Data Vault, Anchor model, cube, or semantic layer. Regardless of the approach, we are still modelling data. The debate, therefore, is not about whether modelling is necessary, but about what type of modelling is appropriate for a given purpose.

To simplify the discussion, it is helpful to distinguish between two perspectives: Subjective Data Modelling and Objective Data Modelling.

Subjective Data Modelling

Subjective Data Modelling is commonly associated with transactional systems, especially OLTP environments. It typically relies on normalized structures such as 3NF and is concerned primarily with operational accuracy.

In this approach, the focus is on how the system captures and maintains data. Integrity, referential consistency, and transaction performance are paramount. For example, in an online retail system:

• Customer details are stored in one table.
• Orders are stored in another.
• Payments are stored separately.
• Relationships are enforced through foreign keys.

Each entity has a clear responsibility, and redundancy is minimized. The structure reflects how the application works internally. It is built from the ground up and designed to ensure reliable system behavior.

Without this type of modelling, operational systems would quickly become inconsistent and unstable. Subjective modelling protects operational truth.

Objective Data Modelling

Objective Data Modelling begins from a different starting point. Instead of asking, How does the system store data? it asks, How does the business need to analyze it?

This perspective is most common in data warehousing and analytical environments. Here, the focus shifts from transaction efficiency to analytical usability. Denormalization is often introduced deliberately to simplify reporting and improve query performance.

For example, in a retail analytics system:

• A central fact table stores measures such as SalesAmount, Quantity, and Discount.
• Dimension tables represent Time, Product, Geography, and Customer attributes.

This structure allows business users to analyze performance across multiple perspectives easily. The model is shaped by decision-making needs rather than operational constraints. It is typically designed top-down, guided by business questions.

Objective modelling enables insight generation. It makes data understandable and usable for strategic decision-making.

The Core Distinction

The difference between Subjective and Objective Data Modelling lies in orientation:

• Subjective modelling focuses on how data is captured and maintained in operational systems.
• Objective modelling focuses on how data is consumed and interpreted for analysis and decisions.

One emphasizes normalization, consistency, and transaction reliability. The other emphasizes clarity, aggregation performance, and analytical flexibility.

Both are valid. Both are necessary. And neither replaces the other.

An organization that excels operationally but lacks analytical modelling will struggle to derive meaningful insights. Conversely, an organization that builds analytical layers without strong operational foundations risks inconsistent definitions and unreliable reporting.

Even in Modern Architectures

In modern architectures that promote schema-on-read or flexible storage formats, modelling does not disappear. It simply becomes implicit. If modelling is not deliberate, it emerges accidentally, through ad hoc transformations, inconsistent metric definitions, duplicated KPIs, and fragmented logic.

When modelling is intentional:

• Definitions are clear.
• KPIs are aligned.
• Governance is manageable.
• Trust in data increases.

When modelling is accidental:

• Metrics conflict.
• Reports disagree.
• Confidence erodes.

The question is not whether modelling exists, but whether it is consciously designed.

Final Perspective

• Subjective Data Modelling protects operational truth.
• Objective Data Modelling enables business understanding.

One ensures systems function correctly. The other ensures insights are meaningful and actionable.

A mature data architecture does not choose between them. It integrates both thoughtfully and strategically. Data modelling is not a legacy discipline. It is the structural foundation of modern data platforms, analytics ecosystems, and even AI systems.

The real sign of architectural maturity is not whether data is modelled, it is whether it is modelled intentionally.