U1
Aggregate Data Models
Represents a collection of related objects
treated as a unit for storage and manipulation.
Originates from Domain-Driven Design.
Key Characteristics:
Simplifies handling large, distributed datasets.
Natural unit for replication and sharding.
Easier for application developers to manage.
Aggregate Structure:
Unit of Data Retrieval
Context-Specific
Atomic Operations
Multiple Aggregates
Implications for NoSQL:
Aggregate-ignorant: Relational and graph
databases -> inefficient in distributed env
NoSQL Support: clusters handled well
Data Modeling in NoSQL:
Key-Value and Document databases support
aggregate-oriented models.
Each aggregate is accessed by a key or ID.
Benefits of Aggregate Orientation:
Easier to scale in distributed systems.
Improved data retrieval and manipulation in
large datasets.
Challenges:
Handling multiple aggregates and relationships
efficiently.
Lack of ACID transactions in NoSQL databases
for cross-aggregate consistency.
Aggregates
A collection of related data that is treated as a
single unit.
Originates from Domain-Driven Design (DDD)
Characteristics:
Encapsulates related data to be treated as a
single unit, e.g., a customer with orders.
Simplifies operations by grouping related entities
together.
Typically consists of a root entity (aggregate
root) and other related entities or value objects.
Aggregates are important for consistency and
transactional boundaries.
Usage in NoSQL:
NoSQL databases handle aggregates efficiently,
especially when using a cluster.
Common for storing and managing objects like a
"customer" aggregate, which includes customer
details and order history.
Supports easier sharding, replication, and scaling
by grouping data that is often accessed together.
Benefits:
Easier to manage and maintain consistency
within a unit of data.
Helps reduce complex joins by embedding
related data within aggregates.
Facilitates atomic operations on a single
aggregate for improved performance.
Example:
A "customer" aggregate might include personal
information, order history, and payment details,
all stored together for easy access.
Reduces the need for complex joins and
simplifies data retrieval for the application.
Key-Value & Document Data Models
Key-Value:
Stores data as pairs of unique keys and
associated values.
Efficient for fast, simple lookups where key is
known.
Ideal for caching and session storage.
Data retrieval based on the key only, no query
flexibility.
Document:
Data stored as documents (e.g., JSON, BSON,
XML).
Supports nested structures, arrays, and varying
schemas.
Flexible for managing semi-structured data (e.g.,
e-commerce product catalog).
Allows complex queries, indexing on fields inside
documents.
Example: MongoDB, CouchDB.
Relationships
Single Aggregate:
Data grouped as a single unit, simplifying
retrieval.
Example: A "Customer" aggregate may include all
their orders and personal info.
In NoSQL, aggregates are atomic, meaning
updates or queries occur within the same unit.
Multiple Aggregates:
In NoSQL, relationships between aggregates (e.g.,
customer and orders) are handled through
application logic, not database joins.
Difficult for NoSQL to enforce relational integrity
or referential constraints like Foreign Keys (FK).
Requires application-level handling of inter-
aggregate relationships.
Graph Databases
Structure:
Data represented as nodes (entities) and edges
(relationships).
Efficient for highly connected data, such as
social networks or recommendation systems.
Each node stores data, and edges hold
relationship types (e.g., "LIKES",
"FRIENDS_WITH").
Queries often involve traversing relationships
(e.g., "Find friends of friends").
Advantages:
Ideal for complex, interconnected data models.
Efficient for queries that involve multiple levels
of relationships, which would be costly in
relational databases.
Example: Neo4j, OrientDB.
Example:
A recommendation system that suggests
products based on friends' preferences.
Schemaless Databases
Flexibility:
No predefined schema; the structure of data can
change without affecting operations.
Suitable for dynamic data or when the data
schema evolves frequently.
Ideal for unstructured or semi-structured data
(e.g., JSON).
Challenges:
Lack of consistency or predictability in data
structure.
Difficult to manage relationships across different
applications accessing the same database.
Requires application-level logic to interpret and
enforce data integrity.
Use Case:
Storing logs, user-generated content, or IoT data
where the structure is inconsistent across
entries.
Materialized Views
Definition:
Precomputed views of data that are stored
physically, enabling faster query results.
A materialized view is essentially a snapshot of
the data at a particular time.
Usage:
Especially useful for reporting or analytics where
data is queried frequently.
Updates the view periodically through batch jobs
or real-time refresh (e.g., after each update).
Reduces the computational cost of complex
queries by storing results.
Example:
In an e-commerce system, a materialized view
may store the total number of orders per
customer, updated periodically.
Helps in scenarios where the same data is
computed repeatedly (e.g., sales reports).
