## 3 SQL-Like vs. NoSQL DBMS
### CRUD Operations
#### 4.1.3. Limits of Data Relationships  
By manipulating the structure of documents it is possible to define relationships among data within a collection. Thus, relations among data were accomplished within a collection by means of reference and embedded documents techniques:  
* **Reference** allows managing data relationships including references or links from a document to another one. Different applications can use these references to access related data. In principle, these data patterns are normalized. MongoDB uses two methods to carry out such a type of relationship among different pieces of data: 1. manual references, which allow saving the field of a document into another document as a reference, so the application can run a second query to return the embedded data. 2. _DBRef_, including the following fields:  
Figure 6: Comparison between reading operations in MongoDB and SQL-like DBMS respectively. * 5 ref contains the name of the collection where the referenced document resides. * 5 id contains the value of the field _id of the referenced document. * 5 db (optional) contains the name of the database where the document resides. Example: { \"_id\" : _Object1d(\"5126 bbf64 aed4 daf9e2 ab765\"), founder: [ \"$ref\" : \"founders\", \"$id\" : _Object1d(\"5126 bc054 aed4 daf9e2 ab766\"), \"$db\" : \"users\" ] } In the example DBRef points to a document in the collection _founders_ which has in the field _id_ the value _Object1d(\"5126 bc054 aed4 daf9e2 ab766\") and which resides in the database _users_.
* **Embedded** allows managing the data relationships considering nesting documents. MongoDB, in fact, allows incorporating more documents within another one as a field or as a matrix. These data models are denormalised and allows the applications to retrieve and manipulate the related data by means a single operation on the collection. MongoDB also uses _dot_ notation to access the elements of an array and the fields in a incorporated document. To access an element of an array, you concatenate the name of the array with the index of the element through the _dot_, enclosing all in quotation marks: \" \(<array>.<index>\)\" To access the field of a sub-document with the _dot_ notation, you concatenate the name of the sub-document with the name of the field through the _dot_, enclosing it quotation marks: \" \(<subdocument>.<field>\)\" With both approaches, relations among data are managed inside the data model itself. As a consequence, if a new query requires a new type of relation among data that was not planned previously, the whole data model has to be modified. In order to solve such a problem, starting from version 3.2, the MongoDB open source community has introduced union operation among collections. In particular MongoDB 3.2 was improved with the _$lookup_ operator. These improvements want to extend the options to perform analytics on operational database continuing to keep efficient and quickly answers to the queries. In the previous MongoDB versions the join between two collections was performed at application-layer by developers. In other words considering two collections, we had the first collection (we can call it \"left-collection\") containing the \"_id\" filed of the documents of the other multiple collections (right-collections). The left-collection contains the references to access the right-collection. Before the MongoDB 3.2 this linking was implemented in application code. MongoDB 3.2, instead introduces the _$lookup_ operator that can now be included as a stage in an aggregation pipeline. This operator allows combining the data of the left and right collections within the database. But this new operator considers only a particular case of the \"join\"'s potentiality namely the \"_Left Outer Equi-Join_\". The _Left Outer Equi-Join_ is an \"external join\". It provides a query result where all the collections' documents are involved.