Welcome to the Book Sales Database Management System. This project is a comprehensive data engineering journey that explores the evolution of database design. It starts with a traditional Relational Database (SQL) architecture based on strict Entity-Driven principles, and scales up to a Polyglot Persistence NoSQL architecture (Redis, Cassandra, Neo4j) designed for Big Data, ultimately integrating with the Hadoop Ecosystem (HDFS, MapReduce, YARN).
The overarching goal of this project is to demonstrate how to architect data solutions based on the application's read/write patterns (Query-Driven Design) rather than just the real-world entities.
In the initial phases, the system was designed using classical Relational Database Management Systems (RDBMS). The focus was on data integrity, ACID compliance, and eliminating redundancy.
- Entity-Relationship Modeling: Defined real-world entities like
Customer,Cashier,Book, andBill. - Normalization: Progressed the schema through 1NF, 2NF, and 3NF to prevent update anomalies.
- SQL Operations: Implemented advanced queries, views, triggers, and stored procedures to handle complex business logic (e.g., updating stock after a sale).
Figure 1: The Normalized Relational Schema (3NF)
As data volume grows to millions of transactions, horizontal scalability becomes crucial. In this phase, we abandoned the Entity-Driven approach in favor of a Query-Driven Design. We utilized three distinct NoSQL architectures, choosing the right tool for the right job (Polyglot Persistence).
Goal: Lightning-fast Bill:1001 fetches the customer info, cashier info, and all purchased books instantly.
Goal: Massive write performance and efficient analytical range queries without using expensive JOIN or global GROUP BY operations.
We designed tables around the exact questions the application asks. For instance, using Partition Keys (K) to group invoices by month, and Clustering Keys (C) to sort them by date automatically on the disk.
Goal: Deep relationship traversal and pattern discovery (e.g., recommendation engines).
We eliminated bridging tables (like Sale_Details) and foreign keys. Instead, we used physical Edges (Relationships) to connect Nodes, storing transactional properties like Quantity and TotalAmount directly on the [:CONTAINS] relationship.
To handle petabyte-scale data that traditional databases cannot process, the architecture relies on the Apache Hadoop ecosystem:
- HDFS (Hadoop Distributed File System): Stores massive denormalized sales logs by splitting them into 128 MB blocks and replicating them across multiple
DataNodesto ensure High Availability and Fault Tolerance (Partition Tolerance in CAP Theorem). - MapReduce: A distributed processing engine used to run heavy analytical jobs directly where the data lives. For example, aggregating millions of sales records to generate a "Sales Summary" by reducing key-value pairs (
<BookISBN, TotalRevenue>). - YARN (Yet Another Resource Negotiator): Acts as the operating system for the cluster, with the
ResourceManagerdynamically allocating CPU and RAM (Containers) toApplicationMastersexecuting the MapReduce jobs.
├── src/ # Source code for NoSQL queries
│ ├── cassandra_queries.cql # Cassandra table schemas and CQL queries
│ ├── neo4j_queries.cypher # Graph node creation and Cypher traversals
│ └── redis_commands.txt # Key-Value injection commands
├── diagrams/ # Architectural diagrams and models
│ ├── 1NF.png, 2NF.png, 3NF.png
│ ├── Key-Value Model.png
│ ├── Wide-Column Model.png
│ ├── Graph Model.png
│ └── HDFS Arch.jpg
└── docs/ # Detailed academic and technical reports
├── Phase01.pdf
├── Phase02.pdf
├── Phase03.pdf
└── Project - Database Management System.pdf



