However, not all NoSQL databases are strongly oriented towards running on clusters. Graph databases are one style of NoSQL databases that uses a distribution model similar to relational databases but offers a different data model that makes it better at handling data with complex relationships.
Capítulo 1.5. The Emergence of NoSQL [2] Lo dice claramente el texto citado, no todas las bases de datos NoSQL están fuertemente orientadas a la ejecución en clústeres. Las bases de datos orientadas a grafos son una variedad NoSQL que utiliza un modelo de distribución similar a las bases de datos relacionales, pero ofrecen un modelo diferente con el propósito de manejar datos con relaciones complejas. Neo4j es un ejemplo de bases de datos NoSQL no orientadas a ejecutarse sobre un clúster sino orientada a simplificar la interpretación de los datos.Relational databases provide many advantages, but they are by no means perfect.[...]For application developers, the biggest frustration has been what’s commonly called theimpedance mismatch: the difference between the relational model and the in-memory data structures.The relational data model organizes data into a structure of tables and rows, or more properly,relations and tuples. In the relational model, a tuple is a set of name-value pairs and a relation is aset of tuples. (The relational definition of a tuple is slightly different from that in mathematics andmany programming languages with a tuple data type, where a tuple is a sequence of values.) Alloperations in SQL consume and return relations, which leads to the mathematically elegant relationalalgebra.This foundation on relations provides a certain elegance and simplicity, but it also introduces limitations. In particular, the values in a relational tuple have to be simple—they cannot contain anystructure, such as a nested record or a list. This limitation isn’t true for in-memory data structures,which can take on much richer structures than relations. As a result, if you want to use a richer inmemory data structure, you have to translate it to a relational representation to store it on disk.
Capítulo 1.2. Impedance Mismatch [2] Como ya se ha avanzado, la afirmación es falsa. Las bases de datos relacionales no son perfectas, existen limitaciones como por ejemplo el problema de la impedancia. En las bases de datos comentadas una tupla relacional debe ser simple: no puede contener ninguna estructura, como un registro anidado o una lista. Esta limitación no es cierta para las estructuras de datos en memoria, que pueden asumir estructuras mucho más ricas que las relaciones. Como resultado, si desea utilizar una estructura de datos in memory más rica, debe traducirla a una representación relacional para almacenarla en el disco. Es decir, las bases de datos relacionales presentan el problema de la impedancia (impedance mismatch).Relational databases have no concept of aggregate within their data model, so we call them aggregate-ignorant. In the NoSQL world, graph databases are also aggregate-ignorant. Being aggregate-ignorant is not a bad thing. It’s often difficult to draw aggregate boundaries well, particularly if the same data is used in many different contexts. An order makes a good aggregate when a customer is making and reviewing orders, and when the retailer is processing orders. However, if a retailer wants to analyze its product sales over the last few months, then an order aggregate becomes a trouble. To get to product sales history, you’ll have to dig into every aggregate in the database. So an aggregate structure may help with some data interactions but be an obstacle for others. An aggregate-ignorant model allows you to easily look at the data in different ways, so it is a better choice when you don’t have a primary structure for manipulating your data
Capitulo 2.1.2.Consequences of Aggregate Orientation. [2] Como indica el texto citado, las bases de datos relacionales y las orientadas a grafos no tienen un concepto de agregación dentro de su modelo de datos. Esta característica les permite ver fácilmente los datos de diferentes maneras, por lo que es una mejor opción cuando no tiene una estructura principal para manipular sus datos. Dicho esto, al conocer claramente la estructura en la que se van a consultar los datos, la mejor opción sería un modelo agregado.Dealing in aggregates makes it much easier for these databases to handle operating on a cluster, since the aggregate makes a natural unit for replication and sharding. Aggregates are also often easier for application programmers to work with, since they often manipulate data through aggregate structures.
Capítulo 2.1. Aggregates. [2] Como dice el texto los agregados hace que sea mucho más fácil el funcionamiento en un clúster, ya que esta estructura constituye una unidad natural de replicación y fragmentación.As well as handling changes, a schemaless store also makes it easier to deal with nonuniform data: data where each record has a different set of fields. A schema puts all rows of a table into a straightjacket, which becomes awkward if you have different kinds of data in different rows. You either end up with lots of columns that are usually null (a sparse table), or you end up with meaningless columns like custom column 4. Schemalessness avoids this, allowing each record to contain just what it needs—no more, no less.
Capítulo 3.3. Schemaless Databases [2] Refiriéndose a las bases de datos relacionales, el documento de estudio nos advierte que estos sistemas deben rellenar todas las filas de una tabla obligatoriamente, lo que resulta incómodo si tiene diferentes tipos de datos en diferentes filas. O terminas con muchas columnas que generalmente son nulas (sparse table) o terminas con columnas sin sentido. La ausencia de esquema evita esto, permitiendo que cada registro contenga justo lo que necesita, ni más ni menos. La conclusión es clara, la afirmación es falsa.Once you have built up a graph of nodes and edges, a graph database allows you to query that network with query operations designed with this kind of graph in mind. This is where the important differences between graph and relational databases come in. Although relational databases can implement relationships using foreign keys, the joins required to navigate around can get quite expensive — which means performance is often poor for highly connected data models. Graph databases make traversal along the relationships very cheap. A large part of this is because graph databases shift most of the work of navigating relationships from query time to insert time. This naturally pays off for situations where querying performance is more important than insert speed.
Capítulo 3.2. Graph Databases. [2] Una vez que se ha creado un grafo con sus nodos y sus aristas podemos consultar su estructura utilizando algoritmos basados en grafos. Estos sistemas se puede recorrer velozmente las relaciones entre los diferentes nodos debido a que están muy optimizados para ello. Su estructura interna penaliza la inserción de nuevos elementos a favor de permitir recorridos sobre la red más veloces, es decir, prima el rendimiento de las consultas sobre la inserción. Por lo tanto, la afirmación es correcta.
Se propone un agregado que represente la información por meses. Cada agregado estará compuesto por un campo mes, ano y las diferentes categorias. Por su parte, categorias estará compuesto por nombrecat (un texto o número que permitirá identificar la categoría, ya que, sin estar especificado en el enunciado, he considerado útil añadir este campo) y el agregado de clientes. Continuando con el análisis de la estructura, los clientes estarán compuestos por los campos dni, nombre y apellidos y los diferentes productos adquiridos. El agregado producto está compuesto por un id y la cantidad de productos comprados.
Se propone un agregado que represente la información por zonas. Cada zona estará compuesta por un campo nombrezona como elemento descriptivo y las diferentes fechas de entrega. Cada agregado fecha estará compuesto por un campo dia, mes, ano y los diferentes pedidos. Por su parte, los pedidos estarán compuesto por id, el agregado de cliente y los agregados de producto. Continuando con el análisis de la estructura, los clientes estarán compuestos por los campos dni, nombre y apellidos.Por cada producto obtendremos un id y la cantidad de elementos entregados.