Knowledge Hub

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.

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.

Medallion Architecture is a new term but again just like many other jargons used by Salespeople, this one is no more than a Buzz word. In other words, we already know this, we are already use it if we have a lakehouse implemented.

People who are working with Databricks and have implemented their Lakehouse probably know what this Medallion Architecture is. Let me try to explain in a few lines for the audience reading this book.

Medallion Architecture is sitting in Delta Lake tables, and it is about processing data in multiple layers i.e., Bronze ⇒ Silver ⇒ Gold layer tables.

• Raw Layer: This layer is normally not under Medallion Architecture as it totally Raw whereas Bronze, Silver and Gold all are in Delta Lake tables. So Raw Layer hosts source data which can’t be pushed to Bronze Layer directly. Most of the organizations prefer to land all source systems data in Raw layer (I also prefer this).
• Bronze: Those source systems which have connectors with Databricks/ Delta Lake can land data in Bronze else Bronze source is most Raw layer. Some data standardization transformation happens here like.

Framework for Big Data Processing

Lambda Architecture is an essential concept in the world of Big Data, gaining attention as technology for handling massive data volumes has advanced. It forms the backbone of many decision-support systems by providing a structured approach to data processing, integrating both batch and real-time data workflows. The Lambda Architecture model offers a comprehensive system for handling data from generation to end-user access, balancing speed and accuracy through batch and real-time layers.

The Foundations of Lambda Architecture

Lambda Architecture is grounded in lambda calculus, a formal system in mathematical logic that supports computation using function abstraction, application, and variable substitution. Lambda calculus is a universal model that can theoretically simulate any Turing machine, making it foundational to computer science and software engineering. In data processing, Lambda Architecture uses this mathematical basis to create a dual-layered system that can handle data asynchronously and in real time.

Kappa Architecture is mostly confused with Lambda Architecture which is fair as both processes Streaming as well as Batch data. Then how both are different?

Due to high demand of Real-Time data, Kappa Architecture has emerged but not for all kinds of data sizes just like Lambda Architecture is.

We have gone through in detail (in separate topic) like what is Lambda Architecture so won’t go in details like how Streaming and Batch works. Let’s understand how Kappa is different than Lambda Architecture.

Kappa Architecture offers ONLY stream processing using Queuing tools like KAFKA for both Streaming and Batch datasets. It doesn’t offer separate tools or technologies to process batches. It says, process both Real-Time Streaming and Batch data using same tool as KAFKA but the biggest differentiator here is, it stores data in a separate data store which might not be suitable to store TBs or PBs of dataset. It offers batch related downstream applications to connect directly to its storage.

Unified Data Architecture is about covering all aspects of data with respect to organizational architectures. There is no pre-defined Unified Data Architecture for everyone.

Let’s see how many Architectures we can have, in an organization with respect to Data.

• Architecture for Source Applications i.e., OLTP
• Architecture for Data Warehouse i.e., OLAP and Cubes
• Architecture for Data Lake, Delta Lake, Data Mesh, Data Vault, Business Vault, Data Hub, Data Fabric
• Architecture for Advance Analytics i.e., for Machine Learning and Deep Learning etc.
• Data Virtualization Architecture

As highlighted above, if not all but there can be many Data Architectures in-place in every organization. In the current era, where data has become the central focus element for everyone, one must design Unified Data Architecture for 30,000 feet view before designing Data Architectures for each component mentioned above.

Just like Enterprise Architecture is about Business Architecture, Application Architecture, Technical Architecture and Data Architecture, all these must follow Enterprise Architecture standards. Same way, all Data Architectures in an organization must follow Unified Data Architecture standards.

In today’s rapidly evolving digital landscape, security threats are more sophisticated and pervasive than ever. Traditional perimeter-based security is no longer sufficient to protect your organization’s most valuable asset – its data. This is where Zero Trust Architecture (ZTA) comes into play.

Data breaches can have catastrophic consequences, both financially and reputationally. Zero Trust Architecture ensures that no entity – human or machine – is trusted by default, minimizing the risk of unauthorized access. With millions of IoT devices and diverse infrastructures spanning on-premises and cloud environments, ZTA offers a robust security framework that addresses these complexities through stringent authentication, authorization, and entitlement mechanisms.

Starting with a zero-trust baseline where no one has access, the architecture gradually opens doors through verified credentials and continuous monitoring. This adaptive approach, combined with data encryption, masking, and anonymization, ensures that your defenses are resilient against emerging threats. Implementing Zero Trust Architecture significantly reduces the risk of data breaches, ensures regulatory compliance, streamlines security operations, and future-proofs your security strategy.

NEON-Inspired Architecture refers to a modern architectural approach that separates storage from compute, allowing systems to scale more efficiently and flexibly. The idea is inspired by cloud-native database designs where data storage and processing power are decoupled instead of tightly integrated.

In traditional database systems, storage and compute are bundled together. If you need more processing power, you often have to scale the entire system, including storage, even if storage capacity is sufficient. This creates inefficiencies in cost and scalability.

In a NEON-inspired approach, storage and compute operate independently. Storage is centralized and durable, while compute instances can scale up or down based on workload demand. This architecture supports elasticity, better resource utilization, and faster provisioning of environments.

One of the well-known implementations of this concept is Neon, which applies serverless principles to PostgreSQL by separating compute nodes from storage layers. While the term “NEON-inspired” may not refer exclusively to that company, it reflects the broader architectural pattern of disaggregation and cloud-native database design.

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.

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.