le to vary a number of records for one business entity using composite keys. For example, user account can be modeled as a set of entries with composite keys like UserID_name, UserID_email, UserID_messages and so on. If user has no email or messages then a corresponding entry is not recorded.
BigTable model supports soft schema via variable set of columns within a column family and variable number of versions for one cell.
Document databases are inherently schema-less, although some of them allow to validate incoming data using user-defined schema.
Soft schema allows to form classes of entities with complex internal structure (nested entities) and vary structure of particular entities.This feature provides two major facilities:
Minimization of one-to-many relationships by means of nested entities and, consequently, reduction of joins.
Masking of “technical” differences between business entities and modeling of heterogeneous business entities using one collection of documents or one table.
These facilities are illustrated in the figure below. This figure depicts modeling of product entity for eCommerce business domain. Initially, we can say that all products have ID, Price, and Description. Next, we discover that different types of products have different attributes like Author for Book or Length for Jeans. Some of these attributes have one-to-many or many-to-many nature like Tracks in Music Albums. Next, it is possible that some entities can not be modeled using fixed types at all. For example, Jeans attributes are not consistent across brands and specific for each manufacturer. It is possible to overcome all these issues in relational normalized data model, but solutions are far from to be elegant. Soft schema allows to use single Aggregate (product) that can model all types of products and their attributes:
Entity Aggregation
Embedding with denormalization can greatly impacts updates both in performance and consistency, so a special attention should be paid to update flows.
Applicability: Key-Value Stores, Document Databases, BigTable-style Databases
(3) Application Side Joins
Joins are rarely supported in NoSQL solutions. As a consequence of the “question-oriented” NoSQL nature, joins are often handled at design time as opposed to relational model where joins are handled at query execution time. Query time joins are almost always mean performance penalty, but in many cases one can avoid joins using Denormalization and Aggregates, i.e. embedding of nested entities. Of course, in many cases joins are inevitable and should be handled by an application. The major use cases are:
Many to many relationships are often modeled by links and require joins.
Aggregates are often inapplicable when entity internals are subject of frequent modifications. It is usually better to keep a record that something happened as opposed to changing a value and join these records at query time. For example, messaging system can be modeled as a User entity that contains nested Message entities. But if messages are often appended, it may be better to extract Messages to independent entities and join them to User at query time:
Applicability: Key-Value Stores, Document Databases, BigTable-style Databases, Graph Databases
General Modeling Techniques
In this section we discuss general modeling techniques that applicable to variety of NoSQL implementations.
(4) Atomic Aggregates
Many, although not all, NoSQL solutions have limited transaction support. In some c |