Data Modeling

in Mongo
JSON, BSON, Data Types,
References, Embedded
Documents

Ref: mongoDB Documentation

1
 Key Data Structures in Mongo
MongoDB RDBMS Illustration

Collection Table {
{ {
item: 'almonds’,
item: 'almonds’,
price: item:
12, 'almonds’,
price:
quantity:
12,
price:
2 12, Collection
quantity: 2 2
quantity:
}
} }

Document Row
{
item: 'almonds’,
price: 12, Document
quantity: 2
}

Field Column
{
item: 'almonds’,
price: 12,
quantity: 2 Field
}
2 / 12
 Documents and Collections
MongoDB groups data through collections.
• A collection is simply a grouping of documents that have the same or a similar purpose.

• A collection acts similarly to a table in a traditional SQL database. However, it has a major difference:
In MongoDB, a collection is not enforced by a strict schema. Instead, documents in a collection can
have a slightly different structure from one another, as needed. This reduces the need to break items
in a document into several different tables, as is often done in SQL implementations.

• A document is a representation of a single entity instance of data in the MongoDB database.

A major difference exists between MongoDB and SQL, in that
RDBMS MongoDB
documents are different from rows.
Database Database
Table Collection Row data is flat, with one column for each value in the row. However,
in MongoDB, documents can contain embedded subdocuments,
Row Document
providing a much closer inherent data model to your applications.
{
name: "New Project", version: 1, Records in MongoDB that represent documents are stored as BSON, a
languages: ["JavaScript", "HTML", lightweight binary form of JSON. (Binary JSON)
"CSS"],
admin: {name: "Brad", password:
"****"},
It uses field:value pairs that correspond to JavaScript property:value
paths: {temp: "/tmp", pairs that define the values stored in the document
project:"/opt/project", html:
"/opt/project/html"} Little translation is necessary to convert MongoDB records back into
} JSON strings that you might be using in your application.
3 / 12
 BSON Structure
{
_id: ObjectId("5099803df3f4948bd2f98391“), name: "New Project",
languages: ["JavaScript", "HTML", "CSS"],
admin: {name: "Brad", password: "****"},
paths: {temp: "/tmp", project:"/opt/project", html: "/opt/project/html"}
}

BSON is lightweight JSON and stores data in field:value pairs

• Documents consist of name-value pairs separated by commas
• Documents start with a { and end with a }.
• Field names cannot contain null characters, dots (.), or dollar signs ($)
• Names are strings, such as “languages" and “paths".
• Values can be numbers, strings, Booleans (true or false), arrays, objects, or the NULL value.
• The values of arrays are listed within square brackets, that is [ and ].
• The values of objects are listed as key-value pairs within curly brackets, that is, { and }.
• _id field is reserved for Object ID that is auto-generated, is a unique ID for the system and
consists of the following parts:
• A 4-byte value representing the seconds since the last epoch
• A 3-byte machine identifier
• A 2-byte process ID
• A 3-byte counter, starting with a random value
• Maximum size of BSON document is 16MB (for performance reasons)
4 / 12
 BSON Structure: Example 2
var mydoc = {
_id: ObjectId("5099803df3f4948bd2f98370"),
name: { first: "Alan", last: "Turing" },
birth: new Date('Jun 23, 1912'),
death: new Date('Jun 07, 1954'),
contribs: [ "Turing machine", "Turing test", "Turingery" ],
views : NumberLong(1250000)
}

The above fields have the following data types:

• _id holds an ObjectId
• name holds an embedded document that contains the fields first and last
• birth and death hold values of the Date type
• contribs holds an array of strings
• views holds a value of the NumberLong type

5 / 12
 MongoDB Data Types
• The BSON data format provides several different data types used when
storing the JavaScript objects to binary form. These types match the
JavaScript type as closely as possible.
• It is important to understand these types because you can
actually query MongoDB to find objects that have a specific
property with a value of a certain type. For example, you can
look for documents in a database whose timestamp value is a
String object or query for ones whose timestamp is a Date object.

• MongoDB assigns each data type of an integer ID number from 1 to

255 when querying by type. Table lists the data types MongoDB
supports, along with the number MongoDB uses to identify them.

• Another point to be aware of when working with the different data

types in MongoDB is the order in which they are compared when
querying to find and update data. When comparing values of different
BSON types, MongoDB uses the following comparison order, from
lowest to highest: 1. Min key (internal type)
2. Null
3. Numbers (32-bit integer, 64-bit integer,
double)
4. Symbol, String
5. Object
6. Array
7. Binary data
Note that minkey number is now -1
8. Object ID
9. Boolean
10. Date, timestamp
https://docs.mongodb.com/manual/reference/bson-types/ 11. Regular expression
12. Max key (internal type)
6 / 12
MongoDB Data Model
 Flexible data schema
 Collections do not enforce Documents structure
 References store the relationships between data by including links or
references from one document to another.
 Embedded documents capture relationships between data by storing
related data in a single document structure.

Embedding

Referencing

7 / 12
‘References’ in Mongo

8 / 12
‘Embedded’ Documents in
Mongo

9 / 12
 Document References vs
Embedded Documents
 Using document references is similar to using a
‘normalized’ data model and is used:
 when embedding would result in duplication of data
but would not provide sufficient read performance
advantages to outweigh the implications of the
duplication.
 to represent more complex many-to-many relationships.
 to model large hierarchical data sets.
 Using embedded documents is similar to using a
‘denormalized’ data model and is used:
 you have “contains” relationships between entities.
 you have one-to-many relationships between entities

10 / 12
 RDBMS vs MongoDB
• Data is moved from rigid Tables to flexible and dynamic BSON documents that use data types, sub-
documents and arrays
• MongoDB document is stored as a single object, requiring only a single read from memory or disk
• As documents are self-contained, distributing the database across multiple nodes (a process called
sharding) becomes simpler and makes it possible to achieve massive horizontal scalability on
commodity hardware
• MongoDB documents tend to have all data for a given record in a single document, whereas in a relational
database information for a given record is usually spread across many tables.
• The complete document can be accessed with a single call to the database, rather than having to
JOIN multiple tables to respond to a query

• With the MongoDB document model, data is more localized, which significantly reduces the need to JOIN
separate tables.
• Structuring of data (via data models and schema) can be iterative and agile in MongoDB
• Data that belongs to a parent-child relationship in two RDBMS tables would commonly be collapsed
(embedded) into a single document in MongoDB
• The RDBMS optimizes data storage efficiency while MongoDB’s document model is optimized for how the
application accesses data (as developer time and speed to market are now more expensive than storage)
• MongoDB query model is implemented as methods or functions within the API of a specific
programming language, as opposed to a completely separate language like SQL.
• Application integration is simpler: MongoDB interface is implemented as methods (or functions) within
the API of a specific programming language, as opposed to a completely separate text-based
language like SQL. The affinity between MongoDB’s JSON document model and the data structures
used in object-oriented programming, makes integration with applications simple
• MongoDB provides document validation within the database. Users can enforce checks on document
structure, data types, data ranges and the presence of mandatory fields.
11 / 12
 Document Model Advantages
 Provide dramatically higher performance and scalability
across commodity hardware
 A single read to the database can retrieve the entire
document containing all related data.
 Don’t need to give up JOINs entirely
 For additional analytics flexibility, MongoDB preserves left-
outer JOIN semantics with the $lookup operator, enabling
users to get the best of both relational and non-relational
data modeling.
 MongoDB BSON documents are closely aligned to the
structure of objects in the programming language.
 This makes it simpler and faster for developers to model
how data in the application will map to data stored in the
database.

12 / 12