## 3 SQL-Like vs. NoSQL DBMS  
Nowadays, most of DBMS solutions are mainly based on the relational model and allow composing complex queries on data by means of the Structured Query Language (SQL). For this reason, they are also referred as SQL-like databases. The first Relational DBMS (RDBMS) solution appeared in the 1970s and for four decades they have dominated the market. However, the recent growing need of larger databases, due to the success of Cloud computing, social media and IoT have stood out the limits of RDBMS. In this context, NoSQL (that stands for Not Only SQL) has rapidly caught the attention of both academia and industry as the promising solution to address the \"Big Data problem\". In fact, since NoSQL solutions are able to manage scheme-less or scheme-free data models, they can easily store huge amount of heterogeneous and unstructured data coming from several different data sources. This is not possible in RDBMS solutions, where static data models have to be define a priori. The relational model is based on relational algebra and relational calculus, and represents a powerful tool that allows developers to write complex queries on data represented by means of relations. A schema defines the relation's name, specifying columns representing attributes or fields. Rows, also called _tuples_ or record, represent the instance of the relation. Integrity constraint is the property that relations must be satisfy in order to represent correct information in data instances. Integrity constraints can be classified according to the involved database elements:  
* domain constraints, which impose a restriction on the attributes' domain;
* intra-relational constraints, which need coherence in primary and foreign keys. In recent years, NoSQL database solutions have emerged to address limits of RDBMS in terms of management of big, unstructured, complex and dynamic data. Differently from SQL-like DBs, most of NoSQL solutions do not enforce domain and inter-relational constrains. We can identify four main _NoSQL_ DB families, each based on a different data model:  
1. **key-Value-Store DB**: based on a key-value model, where each record is characterized by a primary key and a collection of values; it is also called _row-store_, since data representing a single record are stored together. Examples of _NoSQL_ DB that use this data model are Redis and Riak. 2. **Column oriented DB**: data are stored in columns (it is complementary to DBs that store data instead along the rows, namely row-oriented DBs); each attribute of a table is stored in a separate file or region onto the storage system. Example of this type of DB is Cassandra. 3. **Document oriented DB**: data are stored in a document; documents can be nested and thus contain other documents, lists and arrays; this category also includes the native XML DB, so called because they define a logical model for the XML document. Examples are MongoDB and CoucheDB. 4. **Graph DB**: designed for data whose relations are well represented as a graph consisting of elements interconnected with a finite number of relations between them. Examples includes Neo4j and OrientDB. At this point the question is: how do we understand if the needs of an end user (e.g., a company, a developer, etc.) are better satisfied by a _NoSQL_ or _RDBMS_ solution? In order to answer this question, we start from ACID and CAP theorems. ACID refers to the four key properties of a transaction:* **A as Atomicity**: transactions must be atomic, which is indivisible; in DBMSs, the operations of a transition affect a DB coherently. * **C as Consistency**: a transaction must not violate the integrity constraints in the DB; if an inconsistency on data arises, all data come back to the state before the transaction. * **I as Isolation**: executions of a transaction must be independent from each other. * **D as Durability**: the transaction, after a commit execution commit, should take effect correctly on the DB and all changes must be applied and no more lost. **ACID** transactions are the basis of RDBMS solution.