Data Modelling and Schema Design Patterns

Where is schema defined in a document database environment, and what drives its evolution over time?

Schema is defined at the application level and within the database itself, often as a flexible structure that can adapt to changes. Its evolution is driven by application requirements, data usage patterns, and the need for scalability.

What three fundamental considerations must developers evaluate when designing a document schema?

• Queries & Application Data Needs: The specific data fields required by the application's queries.

• Read & Write Patterns: How the application accesses, updates, and writes data.

• Data Relationships: Whether relationships between entities should be linked (referenced) or embedded

Explain what a "data-driven dynamic schema" is. Why is storing keys as data values (e.g., results: { john: { score: 25 }, fred: { score: 20 } }) considered an anti-pattern compared to an array of objects?

A data-driven dynamic schema occurs when field names/keys are dynamically generated from actual data values (e.g., using person names like john or fred as field keys). This is an anti-pattern because field keys cannot be indexed dynamically or queried easily across arbitrary field names. The correct design is to store values as element fields inside an array of structured objects (e.g., results: [{ player: 'john', score: 25 }, { player: 'fred', score: 20 }]), enabling straightforward indexing and querying.

Identify the three classic database relationship cardinalities supported in schema design and give an example of entities for each as illustrated in the slides

• One-to-One ($1$-$1$): E.g., customers to customer_id details.

• One-to-Many ($1$-$N$): E.g., customers to invoices.

• Many-to-Many ($N$-$N$): E.g., invoices to products

State the explicit criteria provided in the slides for deciding when to Embed vs. when to Link

• When to Embed:

  • For integrity with read operations.

  • For integrity with write operations.

  • For One-to-One and standard One-to-Many relationships.

  • For data that is deleted together by default.

• When to Link:

  • When the "many" side of a relationship represents a huge/unbounded number.

  • For integrity on write operations in Many-to-Many relationships.

  • When one piece of data is frequently used but another is rarely used, and memory is a concern.

Outline the three sequential stages of MongoDB's flexible schema modelling methodology and what occurs in each phase.

• Identify Workload: Qualify and quantify application operations, measure data sizes, and isolate the most frequent operations.

• Entities + Relationships: Identify entities, quantify relationships, and decide whether to embed or link entities.

• Transformation Patterns: Apply schema design patterns (e.g., Pattern A, B, C) to optimize collections, fields, shapes, queries, and indexes based on performance vs. simplicity goals.

According to the methodology matrix, how do workload identification and entity relationship decisions shift when moving from a goal of pure Simplicity to pure Performance?

• Simplicity Goal: Evaluates only the Most Frequent Operation, relies on Mostly Embedding, and applies simple baseline transformation patterns.

• Simplicity & Performance Goal: Analyzes Data Size and Quantifies Operations, balances between Embed & Link, and applies moderate transformation patterns.

• Performance Goal: Deeply analyzes Data Size, Quantifies Operations, and Qualifies Operations, extensively utilizes both Embed & Link, and applies advanced combined transformation patterns.

Define the following five core design patterns explicitly listed in the slides:

1. Attribute Pattern

2. Subset Pattern

3. Outlier Pattern

4. Bucket Pattern

5. Computed Pattern

• Attribute Pattern: Uses dynamic key-value tuples/pairs inside an array to represent variable attributes instead of adding many sparse top-level columns.

• Subset Pattern: Stores a small subset of frequently accessed data (e.g., the last 5 comments) in the main document to reduce working set size and read latency.

• Outlier Pattern: Keeps standard/normal-sized documents uniform in the primary collection, but moves exceptionally large or unusual documents to an alternate structure to prevent edge cases from degrading overall performance.

• Bucket Pattern: Groups related time-series data or stream events together into a single document, array, or subdocument.

• Computed Pattern: Precomputes and stores aggregated or calculated values directly on the document when calculation at query time is too expensive.

Based on the patterns matrix slide, identify which schema design patterns are specifically highlighted for the following domain use cases:

1. Internet of Things (IoT) / Time Series

2. Catalog / Inventory Management

3. Mobile Applications

• nternet of Things (IoT): Bucket Pattern, Computed Pattern, Outlier Pattern, Preallocated Pattern, Schema Versioning Pattern.

• Catalog: Attribute Pattern, Computed Pattern, Document Versioning Pattern, Extended Reference Pattern, Polymorphic Pattern, Schema Versioning Pattern, Subset Pattern, Tree Pattern.

• Mobile Applications: Approximation Pattern, Computed Pattern, Extended Reference Pattern, Outlier Pattern, Polymorphic Pattern, Schema Versioning Pattern, Subset Pattern.