NOSQL
Module - 1
1. Why NoSQL?
NoSQL databases are used because traditional relational databases cannot handle very large, fast,
and distributed data efficiently.
• Modern apps (web, mobile, cloud) generate very large data
• Data is often not in fixed table form (JSON, text, images, logs)
• Handles unstructured and semi-structured data
2. The Value of Relational Databases
Relational databases are valuable because they store data in a structured and organized way,
making data accurate, reliable, and easy to manage.
• Data is stored in tables with rows and columns, which is easy to understand
• They use SQL, a powerful and standard language to query data
ACID Properties
A – Atomicity
• A transaction is all or nothing
• If any part fails, the whole transaction is cancelled
C – Consistency
• Data must always be correct and valid
• After a transaction, the database stays in a proper state
I – Isolation
• Multiple transactions run independently
• One transaction does not affect another until it finishes
D – Durability
• Once a transaction is completed, data is permanently saved
• Data remains safe even after power failure or crash
3. Concurrency
Concurrency means many users or programs accessing the database at the same time.
• Databases allow multiple users to read and write data simultaneously
• They use transactions and locks to avoid conflicts
• Prevents problems like wrong updates or lost data
4. Integration
Integration means sharing the same data between different applications.
• Multiple systems use one database
• Data remains consistent across applications
• Relational databases support easy integration using SQL
5. A (Mostly) Standard Model
Relational databases follow a well-defined and commonly accepted data model.
• Data is stored in tables with rows and columns
• Relationships are defined using primary keys and foreign keys
• SQL is used almost everywhere, with minor differences
• This makes databases easy to learn, maintain, and migrate
6. Impedance Mismatch
Impedance mismatch is the gap between object-oriented programs and relational databases.
• Applications use objects, classes, and inheritance
• Databases use tables and rows
• Mapping objects to tables is not direct
• Extra code or tools (like ORM) are needed, which increases complexity and overhead
7. Aggregate Data Models
• An Aggregate Data Model is a way of storing data where related information is kept together
instead of spreading it into many tables.
• This model is mostly used in NoSQL databases.
What is an Aggregate?
An aggregate is a group of related data that is treated as one single unit.
• One main object is called the aggregate root
• Other related data stays inside it
• The whole group is saved and read together
Example of Relations and Aggregates
Traditional (Relational Database)
In Relational database data is split into many tables:
• Customer table
• Order table
• Order items table
To get full order details, the database must join tables, which takes more time.
Aggregate Data Model
All related data is stored in one place.
Example: Order Aggregate
• Order ID
• Order Date
• Customer details
• List of items (item name, quantity, price)
Everything is stored together, so:
• No table joining
• Faster access
Consequences of Aggregate Orientation
Using aggregates changes how data behaves.
1. Easy and Fast Data Reading
• You get all related data in one request
• No joins are needed
• Makes the system faster
Example: One order request gives order + items together.
2. Easy to Keep Data Correct
• Changes inside one aggregate happen together
• Reduces errors
Example: Updating order status and item quantity at the same time.
3. Same Data May Be Repeated
• Some information is copied into many aggregates
• This avoids joins but uses more space
Example: Customer name saved in every order
4. Better for Large Systems
• Aggregates can be easily stored on different servers
• Works well for big applications
Example: Different users’ orders can be stored on different machines.
5. Aggregates Should Not Be Too Big
• Very large aggregates slow the system
• Keep only related data together
8. Key-Value and Document Data Models
These data models are commonly used in NoSQL databases.
1. Key-Value Data Model
The Key-Value data model stores data in the form of key and value, just like a dictionary.
Key → Value
• Key = unique identifier (like a name or ID)
• Value = actual data (can be a string, number, list, or object)
• To get the data, we use the key.
How it Works
• You give a key
• The database quickly returns the value
• The database does not care what is inside the value
Example (Student Record)
Key: student_101
Value:
"name": "Rahul",
"course": "MCA",
"marks": 85
• student_101 is the key
• All student details are stored as one value
2. Document Data Model
The Document data model stores data as documents, similar to files, usually in JSON format instead
of rows and columns.
• Each document is a self-contained record
• Stored in formats like JSON / BSON / XML
• Each document can have different structure
How it Works
• Each document stores complete information in one place.
• Each document has:
o Fields
o Values
• Fields can contain numbers, text, arrays
• Different documents can have different fields.
Example (Student Document)
"student_id": 101,
"name": "Rahul",
"course": "MCA",
"subjects": ["Cloud", "AI", "DBMS"],
"contact": {
"phone": "9876543210",
"email": "rahul@[Link]"
}
9. Column-Family Stores
A Column-Family Store is a type of NoSQL database that stores data by columns instead of rows.
• Row Key. Each row has a unique key, which is a unique identifier for that row.
• Column. Each column contains a name, a value, and timestamp.
• Name. This is the name of the name/value pair.
• Value. This is the value of the name/value pair.
• Timestamp. This provides the date and time that the data was inserted.
10. Relationship
A relationship describes how two or more data entities are connected in a database.
Types of Relationships
One-to-One
• One record relates to only one record
• Example: Person → Passport
One-to-Many
• One record relates to many records
• Example: One teacher teaches many students
Many-to-Many
• Many records relate to many records
• Example: Students enroll in many courses
11. Graph Databases
A graph database stores data in the form of a graph, using nodes, edges (relationships),
Core Components
• Nodes
Represent real-world entities such as people, places, products, or accounts.
Example: A node for a user named “Amit”.
• Relationships (Edges)
Show how two nodes are connected and always have a direction and type.
Example: Amit → FRIEND_OF → Rahul
• Properties
Key–value pairs stored in nodes or relationships.
Example: name = "Amit", age = 22
12. Schemaless Databases
A schemaless database allows storing data without a fixed structure.
Key Idea
• No predefined schema like rows and columns
• Structure is decided at runtime
• Data is usually stored as documents, key-value pairs, or graphs
13. Materialized Views
A materialized view is a precomputed and stored result of a query.
Unlike a normal view, it physically stores data and does not run the query every time.
Why Materialized Views are Used
• Queries on large tables are slow
• Repeating the same complex query wastes time
• Pre-stored results give faster access
14. What is Modeling for Data Access?
Modeling for data access means designing the database structure based on how data is read and
written, not just how it looks conceptually.