Relational Databases & the ER Model Explained
When analytics data is structured, interviewers expect you to know how it is stored, linked, and cleaned before querying. A relational database stores data in structured tables with rows and columns, linked via keys, and normalisation organises that data to reduce redundancy. This matters in Razorpay or Flipkart style analytics discussions because database choice affects whether the system is built for transactional systems, caching, event streaming, or OLAP analytics.
- Relational Database: Data stored in structured tables with rows (records) and columns (attributes), linked via keys.
- Primary Key (PK): Uniquely identifies each row (e.g., customer_id).
- Foreign Key (FK): Links to PK in another table (e.g., orders.customer_id -> customers.customer_id).
- Normalisation: Process of organising data to reduce redundancy.
- Normalisation moves from 1NF (atomic values) -> 2NF (no partial dependency) -> 3NF (no transitive dependency).
- RDBMS fits transactional systems, structured data, strong consistency, while NoSQL and Cloud Data Warehouse options fit different structures and use cases.
Big Picture: Relational Databases and the ER Model
The practical modelling base is to connect three ideas: structured tables, keys that link tables, and normalisation that reduces redundancy. Once that base is clear, database type choice becomes easier: RDBMS for transactional systems and structured data, NoSQL for flexible or fast-access patterns, and Cloud Data Warehouse for OLAP analytics, large-scale aggregations, and BI.
Relational Database: Data stored in structured tables with rows (records) and columns (attributes), linked via keys.
Primary Key and Foreign Key
Primary Key (PK): Uniquely identifies each row (e.g., customer_id). Foreign Key (FK): Links to PK in another table (e.g., orders.customer_id -> customers.customer_id).
In an interview answer, this is the simplest way to explain how tables are connected: one table has the unique identifier, and another table stores a reference to that identifier.
Normalisation: Cleaning the Structure
Normalisation: Process of organising data to reduce redundancy. It moves through 1NF, 2NF, and 3NF as the structure becomes cleaner.
Database Types Compared
The main interview comparison is not just relational versus non-relational. It is about structure, examples, when to use each database type, and the Indian context where that choice appears.
How to Use the Comparison in Analytics Interviews
For transactional systems, structured data, and strong consistency, use the RDBMS row: Razorpay payments DB and HDFC Core Banking are the Indian context examples. For semi-structured data and varying schemas, use NoSQL - Document with Swiggy restaurant menu catalogue.
For caching, session management, and real-time lookup, use NoSQL - Key-Value with Flipkart cart session caching (Redis). For time-series, high write throughput, and IoT data, use NoSQL - Column with Airtel network event streaming. For OLAP analytics, large-scale aggregations, and BI, use Cloud Data Warehouse with Meesho analytics on BigQuery.
Structuring a Relational Databases & the ER Model Explained Interview Answer
"Explain relational databases, primary keys, foreign keys, and normalisation. When would you use RDBMS versus NoSQL or a Cloud Data Warehouse?"
Do not answer only with tool names like MySQL, MongoDB, Redis, or BigQuery. Anchor the answer in structure, keys, normalisation, when to use each database type, and the Indian context examples.
The most frequent error is treating RDBMS, NoSQL, and Cloud Data Warehouse as interchangeable storage choices. It costs points because the comparison separates transactional systems, structured data, strong consistency from semi-structured data, caching, time-series, and OLAP analytics use cases.
Conclusion
Relational databases are the foundation of structured analytics data: tables store rows and columns, keys link records across tables, and normalisation reduces redundancy. For interviews, the final takeaway is to explain the model clearly and then choose the right database type based on structure, use case, and context.