Document Data Model

A document data model organizes information into documents containing field names and values. Values can include strings, numbers, booleans, nested objects, and arrays, subject to the database's supported types. A document typically has a unique identifier and belongs to a collection or an equivalent container. Unlike a relational table, documents in the same collection do not necessarily need identical fields. A product catalog can therefore store screen dimensions for televisions and fabric details for clothing without requiring every product to share every attribute.

The document is a useful boundary for information that an application commonly reads or changes together. For example, an order document might contain an order identifier, customer identifier, shipping address, and an array of purchased items. Embedding the shipping address and purchased item descriptions preserves the details used when the order was placed. The application can often retrieve this information without joining several tables. However, a customer's entire order history should not automatically become one ever-growing document; document size limits and update patterns may make separate order documents more appropriate.

Cloud document databases provide managed storage, querying, indexing, replication, and scaling capabilities, although their implementations differ. Engineers should start with expected access patterns: retrieving a profile by identifier, finding products by category, or listing orders for a customer. Keys and indexes should support those operations. In partitioned systems, partition-key selection affects how traffic and storage are distributed. A flexible record structure does not prevent a frequently accessed partition from becoming a bottleneck or make unindexed searches inexpensive.

The main modeling choice is often embedding versus referencing. Embedding related data can reduce database requests and make a single-document change easier to coordinate. Referencing another document avoids copying frequently changing shared data, but may require additional reads or database-supported joins. Denormalization deliberately duplicates data to support reads; it also creates responsibility for keeping copies synchronized when necessary. An address copied into a historical order may intentionally remain unchanged, while a duplicated current account status may require coordinated updates.

Flexible schema does not mean no schema. Applications still need field definitions, validation rules, compatible data types, and a strategy for older documents when structures evolve. Database validation features vary. Likewise, NoSQL does not mean transactions are impossible or that every read must be eventually consistent. Atomicity, transaction scope, consistency options, and query capabilities depend on the selected service and configuration.

For AWS Cloud Practitioner questions, recognize Amazon DynamoDB as a NoSQL database supporting both key-value and document data models. Its items can contain nested maps and lists, but access still depends on table keys and supported indexes. Amazon DocumentDB is another document database service, with MongoDB compatibility that must be checked against application requirements. Neither service should be confused with a relational database simply because records contain structured fields. Conversely, saving a JSON file in object storage does not by itself provide document-database querying, indexing, or update semantics.