Agenda
• Traditional Relational Model
• MongoDB Document Model
• Associating Entities in MongoDB
• There will be a test at the end
Have to Manage Changes in 3 Places
Application
Code
Relational Database
Object Relational Mapping
XML Config DB Schema
Developers can be more productive
Application
Code
Rich Queries Geospatial
Text Search
Map Reduce
Aggregation
Key → Value store
• One-dimensional storage
• Single value is a blob
• Query on key only
• No schema
• Value can be replaced but not updated
Key Blob
Relational Record
• Two-dimensional storage
• Field contains a single value
• Query on any field
• Very structured schema
• Poor data locality requires many tables, joins, and indexes.
Primary Key
MongoDB Document
_id • N-dimensional storage
• Field can contain many values and embedded values
• Query on any field & level
• Flexible schema
• Optimal data locality requires fewer indexes and provides better performance
Documents are easier
Relational MongoDB { ! first_name: "Paul",! surname: "Miller"! city: "London",! location: [45.123,47.232],! cars: [ ! { model: "Bentley",! year: 1973,! value: 100000, … },! { model: "Rolls Royce",! year: 1965,! value: 330000, … }! }!}!
Terminology
MongoDB RDBMS
Document Row
Collection Table
Index Index
Embedded Document Join
Reference Foreign Key
Referencing
Addresses {
_id : , street : , city : , state : ”, zip_code : , country :
}
Contacts { _id : , name : , title : , company : ”, phone : , address_id : }
Embedding
Contacts { _id : , name : , title : , company : , address : {
street : , city : , state : , zip_code : , country :
}, phone : }
Schema Flexibility – different shapes
{ _id: , name : , title : , company : , address : {
street : , city : , state : , zip_code :
}, phone : }
{ _id : , name : , url : , title : , company : , email : , address : { street : , city : , state : , zip_code : } phone : , fax }
{ “_id”: , “name”: , “title”: , “company”: , “address”: [
{ “street”: , “city”: , “state”: , “zip_code”: , “country”:
}, { “street”: , “city”: , “state”:
} ], “phone”: }
Schema Flexibility – easily changed
{ _id : , name : , title : , company : , address : {
street : , city : , state : , zip_code : , country :
}, phone : }
Address Book Entity-Relationship
Contacts
• name • company • title
Addresses • type • street • city • state • zip_code
Phones • type • number
Emails • type • address
Thumbnails • mime_type • data
Portraits • mime_type • data
Groups • name
N
1
N
1
N
N
N
1
1
1
1 1
Twitter • name • location • web • bio
1
1
One-to-One
Contacts
• name • company • title
Addresses • type • street • city • state • zip_code
Phones • type • number
Emails • type • address
Thumbnails • mime_type • data
Portraits • mime_type • data
Groups • name
N
1
N
1
N
N
N
1
1
1
1 1
Twitter • name • location • web • bio
1
1
Contact • twitter
twitter 1
You can query or index on embedded fields. For example:
db.contacts.find( { "twitter.account" : "@Decameron" } )
General Recommendation One-to-One
{ _id : 1375-12-21, name : "Giovanni Boccaccio", twitter : { account : "@Decameron", page : "https://twitter.com/RealBoccaccio" } }
One-to-Many
Contacts
• name • company • title
Addresses • type • street • city • state • zip_code
Phones • type • number
Emails • type • address
Thumbnails • mime_type • data
Portraits • mime_type • data
Groups • name
N
1
N
1
N
N
N
1
1
1
1 1
Twitters • name • location • web • bio
1
1
Contact • phones
phone N
General Recommendation One-to-Many Few
{ _id : 1375-12-21, name : "Giovanni Boccaccio", twitter : { account : "@Decameron", page : "https://twitter.com/RealBoccaccio" } phone : [ work : "+39 0571-669811", home : "+39 671-946726", mobile : "+39 671-038747" ] }
Contacts
• name • company • title
Addresses • type • street • city • state • zip_code
Phones • type • number
Emails • type • address
Thumbnails • mime_type • data
Portraits • mime_type • data
Groups • name
N
1
N
1
N
N
N
1
1
1
1 1
Twitters • name • location • web • bio
1
1
Many-to-Many
Contacts • name • company • title • phone
Groups • name
GroupContacts • group_id • contact_id
Use arrays instead
XTraditional Relational Association
Join Table
Many-to-Many
group
• contact_ids: [ ]
contact N N
group contact • group_ids: [ ] N N
Duplicated data must be updated for consistency
group • contacts
contact N
contact • groups
group N
Schema Design Choices
Many-to-Many
Reference Embed
group contact • group_ids: [ ] N N
Many-to-Many
• Use case: address book
• Contact references groups
Reference
group
• contacts
contact N
Many-to-Many
• Use case: corporate email system
• Group embeds contacts for performance
Embed
Contacts • name • company • title
addresses • type • street • city • state • zip_code
phones • type • number
emails • type • address
thumbnail • mime_type • data
Portraits • mime_type • data
Groups • name
N
1
N
1
twitter • name • location • web • bio
N
N
N
1
1
Document model - holistic and efficient representation
Contact document example {
“name” : “Gary J. Murakami, Ph.D.”, “company” : “MongoDB, Inc.”, “title” : “Lead Engineer”, “twitter” : { “name” : “Gary Murakami”, “location” : “New Providence, NJ”, “web” : “http://www.nobell.org” }, “portrait_id” : 1, “addresses” :
, “phones” :
, “emails” :
}