Bases de datos relacionales: el modelo de datos en detalle

Las bases de datos son parte esencial de cualquier sistema informático, puesto que todos los programas necesitan recurrir a diversos datos mientras se ejecutan o generan otros que se han de almacenar de forma fiable, sin contradicciones y a largo plazo. Esto es posible en bases de datos (BD) estructuradas y gestionadas por sistemas de gestión de bases de datos (SGBD), aplicaciones de software que interactúan con el usuario o con otros programas para poner a su disposición un segmento de la información guardada en la base de datos.

Hasta hoy la gestión electrónica de datos ha estado dominada por el modelo de base de datos relacional. Entre los gestores de bases de datos relacionales más utilizados se cuentan, por orden alfabético:

• Db2: con Db2 los usuarios disponen de un SGBD relacional propietario de la casa IBM.
   
• Microsoft SQL Server: la aplicación de Microsoft para gestionar bases de datos relacionales está disponible con una licencia Microsoft de pago.
   
• MySQL: MySQL es el SGBD de código abierto más utilizado a nivel global. Desde que pasa a las manos de Oracle, MySQL se distribuye con una licencia dual. Sus primeros desarrolladores siguen encargándose del proyecto, ahora bajo el nombre de MariaDB.
   
• PostgreSQL: con PostgreSQL los usuarios disponen de un SGBD relacional libre y orientado a objetos de cuyo continuo desarrollo se ocupa su comunidad open source.
   
• Oracle Database: el programa de Oracle se distribuye como software propietario.
   
• SQLite: por último, SQLite constituye una biblioteca de programas con licencia de dominio público que contiene un gestor de bases de datos relacionales.

Todos estos sistemas se basan en una organización tabular de la información, pero ¿cómo exactamente? A continuación nos adentramos en los principios fundamentales del diseño de bases de datos relacionales, presentamos algunos ejemplos y las distinguimos de otros modelos de datos.

Un concepto capital del modelo relacional es el de relación, postulado por el matemático y teórico de bases de datos Edgar F. Codd. Siguiendo al científico británico, una relación representa un conjunto de entidades con las mismas propiedades. Cada relación se compone de una serie de filas o registros (las llamadas tuplas), cuyos valores dependen de ciertos atributos (columnas).

Para definir los atributos de una relación y el tipo de dato (dominio) permitido para estos valores, se utiliza un esquema con esta sintaxis:

R = (A₁:D₁, A₂:D₂, … , A_n:D_n)

Aquí, la relación R comprende de los atributos A₁ a A_n y cada atributo corresponde a un tipo de dato o dominio (D_1, D₂ , etc.).

Veámoslo a la luz de un ejemplo concreto. El siguiente esquema define los atributos de la relación “Empleados”:

segundo apellido, nombre, número de la seguridad social (nº SS), calle, código postal y municipio, y podría utilizarse para la gestión interna de los datos personales de la plantilla de una empresa.

A cada atributo le corresponde un tipo de dato, string o integer, lo que indica que hay atributos que esperan cómo valor una secuencia de caracteres (string) y otros que solo aceptan números enteros (integer).

Una relación con el esquema explicado arriba podría contener la siguiente tupla (fila):

Esta tabla guarda los datos de la plantilla de una empresa y se compone de cuatro registros, cada uno de los cuales contiene información sobre un solo empleado.

Los datos estructurados en tablas constituyen la BD de un sistema relacional. El SGBD define su estructura y gestiona también los permisos de escritura y lectura y para interactuar con él, los usuarios utilizan un lenguaje de bases de datos. Todo gestor de bases de datos relacionales soporta al menos un lenguaje formal que permite ejecutar las siguientes operaciones:

• Definir la estructura de datos: en la definición de los datos se guarda una descripción con metadatos de la estructura de datos en el diccionario del sistema. Cuando un usuario crea una tabla nueva, en el diccionario de datos se almacena su correspondiente esquema. El vocabulario de un lenguaje de bases de datos que se utiliza para definir los datos se denomina Data Definition Language (DDL), lenguaje de definición de datos.
   
• Definir derechos: todos los lenguajes de bases de datos proporcionan una sintaxis que permite otorgar o retirar permisos. En este contexto se habla de Data Control Language (DCL) o lenguaje de control de datos, un vocabulario integrado en el lenguaje de bases de datos.
   
• Definir condiciones de integridad: por condiciones de integridad se entienden los requisitos de estado que se exigen a un banco de datos. Si se definen condiciones para su integridad, la BD garantiza que se cumplan en todo momento. Se habla entonces de un estado consistente. Una condición básica de integridad en una base de datos relacional es, por ejemplo, que cada registro (tupla) pueda identificarse de forma inequívoca.
   
• Definir transacciones: cuando se lleva a una BD de un estado consistente a otro diferente se habla de transacción. Estas transacciones contienen una serie de instrucciones que deben ejecutarse siempre de forma íntegra. Si una se interrumpe, la BD vuelve a su estado original (Rollback). Cada transacción comienza con una orden para crear una conexión con la BD a la que siguen otras que inician las operaciones de datos en sí, así como un paso de comprobación (Commit) que asegura la integridad de la BD. Las operaciones que pongan en peligro la integridad de la tabla no se consignan (committed), es decir, no se escriben en la base de datos de forma permanente. Por último, se cierra la conexión con la BD. Al vocabulario del lenguaje de bases de datos con el que se manipulan los datos se le conoce como Data Manipulation Language (DML).
   
• Definir vistas: las llamadas views son vistas virtuales de un subconjunto de los datos de una tabla. Para crear una vista, el SGBD genera una tabla virtual (relación lógica) sobre la base de las tablas físicas. En estas vistas pueden emplearse las mismas operaciones que se utilizarían en tablas físicas. Según la función de la vista de datos pueden distinguirse distintos tipos de vista. Las más habituales son aquellas que filtran determinadas filas (consulta de selección) o columnas (vista de columnas) de una tabla, así como las que conectan diversas tablas entre sí (vista de conjunto).

En el modelo relacional se utiliza de forma estándar para estas operaciones el lenguaje de bases de datos SQL (Structured Query Language), basado en el álgebra relacional.

Las operaciones típicas de las BD como consultar, crear, actualizar o borrar datos se realizan por medio de las llamadas sentencias SQL (SQL statements), una combinación de órdenes SQL, semánticamente vinculadas al inglés y por este motivo bastante elocuentes. La siguiente tabla contiene términos fundamentales del modelo de datos relacional y su equivalente en terminología SQL:

Para ejecutar una consulta sencilla con SQL podemos utilizar este esquema:

Utilizamos SELECT en primer lugar para ordenar al SGBD relacional que consulte ciertos datos. A continuación definimos los datos que queremos consultar proporcionando tanto la tabla como la columna que deseamos seleccionar. Con WHERE integramos una condición en la sentencia SQL porque no queremos abrir todos los valores en esta columna, sino solo el valor de un determinado registro.

Volviendo a nuestra tabla “Empleados”, esta sentencia SQL podría resultar así:

Esta declaración indica al gestor de la BD que invoque un valor de la columna nº SS de la tabla “Empleados”. La condición que hemos definido es que se seleccione el valor del registro cuyo valor de atributo de la columna e_ID equivalga al valor 3.

Como resultado, la base de datos entrega el valor 25 091225 46, el número de la seguridad social de Gonzalo Expósito Hernández, el empleado identificado con el número 3.

Con los datos de la tabla, la siguiente clave serviría para identificar de forma única el registro del empleado Gonzalo Expósito:

A estas llaves se las conoce como superclaves, si bien en la práctica tienen poca relevancia, entre otras cosas porque a menudo contienen más atributos de los necesarios. En cambio, en el contexto de las bases de datos relacionales, acostumbra a trabajarse con los fragmentos más pequeños de una superclave, los llamados candidatos a clave. Una tabla puede contener varios candidatos a clave que identifican a las tuplas inequívocamente.

Como hemos visto en nuestra consulta anterior, los registros de la tabla “Empleados” pueden identificarse solo con el número de identificación (e_ID). Otro candidato a clave podría ser el número de la seguridad social (nº SS). Una clave como {apellido, nombre}, en cambio, no sería un buen candidato, ya que esta pareja de atributos no puede asignarse con seguridad a un solo empleado (en una empresa podría encontrarse a varios empleados con el mismo nombre y el mismo primer apellido). En consecuencia, una identificación con esta clave no estaría libre de duda. Sin embargo, no puede haber dos empleados que compartan el ID o número de la seguridad social.

Así, para nuestra tabla pueden definirse los siguientes candidatos a clave:

Las bases de datos relacionales suelen estructurarse de tal forma que uno de los posibles candidatos a clave indique el orden de los registros. Este candidato a clave se convierte entonces en clave primaria (primary key) y suele tratarse de números identificativos consecutivos. En nuestra tabla sería e_ID.

Por su capacidad para identificar los registros en las bases de datos relacionales, las claves se ajustan a la perfección para interconectar las diferentes tablas que componen una BD. Para hacerlo, la clave primaria de una tabla se convierte en la clave ajena (foreign key) de otra.

La tabla que presentamos a continuación contiene los datos que una empresa podría haber registrado sobre su parque móvil. La clave primaria de la tabla llamada “Vehículos” es un coche_ID consecutivo:

Ahora, para mostrar el coche que conduce cada empleado debería conectarse la tabla “Vehículos” con la tabla “Empleados”. Una forma de hacerlo sería integrando la clave primaria de la tabla del automóvil (coche_ID) como clave ajena en la tabla con los datos sobre la plantilla:

Ahora sabemos que el trabajador García Fernández conduce un automóvil con el ID 3, la señora Casas González uno con el ID 2 y que Josefa y Gonzalo comparten el coche con el ID 1.

Si se tratara de saber qué trabajador llevará la próxima vez el coche al taller y cuándo lo hará, se deberá consultar tanto la tabla “Empleados” como la tabla “Vehículos”. Pero como se han conectado mediante la clave ajena, esta consulta puede hacerse una sola vez. Las operaciones de BD que abarcan varias tablas se realizan en el modelo relacional con ayuda de las llamadas sentencias JOIN.

JOIN puede traducirse como la acción de “unir” o “combinar” y en este contexto hace referencia a una operación que permite consultar varias tablas de datos simultáneamente. Los datos que se extraen de las tablas seleccionadas se agrupan en un subconjunto con todos los posibles resultados (espacio de muestreo en matemáticas) y se entregan en función de las condiciones que se han definido.

El fundamento matemático del JOIN de SQL lo componen dos operaciones del álgebra relacional: el producto cartesiano y la selección. Los usuarios deciden con la elección del tipo de JOIN y con ayuda de una condición de selección qué datos se extraen de las tablas.

Los JOIN se dividen en EQUI JOIN y NON EQUI JOIN.

Entre los tipos de JOIN más importantes se cuentan:

• INNER JOIN (combinación interna)
• OUTER JOIN (combinación externa)
• SELF JOIN (una tabla enlaza consigo misma)

En nuestro artículo sobre los JOIN de SQL conocerás cómo funcionan los JOIN de SQL en las tablas de bases de datos relacionales y qué has de tener en cuenta al escoger el tipo de JOIN.

Las bases de datos relacionales basadas en SQL se diferencian de los conceptos que rompen con la estructura fija de las tablas y persiguen un enfoque alternativo a la hora de organizar los datos. Entre los más importantes se encuentran las bases de datos orientadas a objetos y los sistemas basados en documentos.

Con las bases de datos orientadas a objetos (BDOO) entra en escena a finales de la década de 1980 un nuevo modelo que retoma elementos de la programación orientada a objetos y permite el almacenamiento de los datos en forma de objetos. Aunque este principio no logra consolidarse, algunas de sus ideas consiguen colarse en el desarrollo de sistemas de bases de datos relacionales. El resultado son productos con extensiones objeto-relacionales que facilitan el almacenamiento de tipos abstractos de datos en el modelo relacional de base de datos.

Con los cambios en el uso de Internet que trajo consigo el nuevo siglo y la web 2.0, el modelo relacional volvió a ser objeto de críticas. En el marco del movimiento NoSQL (Not only SQL), cuyo objeto era crear sistemas de BD de gran rendimiento aptos para aplicaciones con un uso masivo de datos, comienzan a desarrollarse entonces modelos alternativos como el de las bases de datos orientadas a documentos (BDOD). Estos dos modelos, los orientados a objetos y a documentos, se diferencian del modelo relacional sobre todo en la forma como se almacenan y se accede a los datos.

El modelo orientado a objetos considera el almacenamiento de datos como objetos, los cuales se procesan de forma análoga a como sucede en la programación orientada a objetos. Un objeto define a una entidad y contiene:

• los atributos necesarios para describir a la entidad,
• conexiones (relaciones) con otros objetos,
• funciones que permiten acceder a los datos almacenados (métodos).

Un objeto es, así, una combinación de datos en la cual también se define el punto de acceso a estos datos. Los objetos se consideran tipos abstractos de datos.

El SGBD orientado a objetos (ODBMS, object database management system) asigna automáticamente un ID a cada objeto que permite identificarle de forma única y dirigirse a él con métodos. Este ID es independiente del estado del objeto y está desvinculado de sus valores. Esto permite asignar ID diferentes a dos objetos con los mismos datos, esto es, con un mismo estado. El modelo orientado a objetos se aleja así del relacional, modelo en el que cada tupla puede identificarse a partir de sus datos, por ejemplo, con una clave primaria.

Otra característica del modelo orientado a objetos es el aislamiento de los datos: la única forma de acceder a los datos guardados es utilizando los métodos que el usuario ha definido previamente. Esto protege a los datos de cambios procedentes de puntos de acceso no definidos.

Por otro lado, las estructuras de bases de datos se definen aquí por medio de un sistema de clases jerárquico. En el contexto de la programación orientada a objetos, una clase es un conjunto de objetos que poseen las mismas propiedades y a cada clase de objetos le subyace una definición de clases. Este esquema prescribe los atributos y los métodos de todos los objetos de la misma clase, determinando así cómo se crean y se modifican.

Para interactuar con el sistema gestor de estas bases de datos, los usuarios utilizan un lenguaje de consultas inspirado en SQL, el lenguaje de consultas a objetos u OQL (Object Query Language). El resultado de una consulta OQL no es, como en SQL, un espacio de resultados posibles, sino una lista de todos los objetos que satisfacen las condiciones de la declaración OQL.

Algunas implementaciones conocidas del modelo de BDOO son Realm, ZODB y Perst.

El desarrollo de las BDOO pretendía solucionar un problema de la programación de aplicaciones, la incompatibilidad de impedancia objeto-relacional (Object-relational impedence mismatch), que se produce inevitablemente si se guardan objetos de un lenguaje orientado a objetos como C#, C++ o Java en una base de datos relacional y resulta de las diferencias fundamentales entre ambos paradigmas de programación, como son:

• Las bases de datos relacionales no soportan conceptos orientados a objetos como las clases y la herencia.
• El modelo relacional no permite la identificación de objetos independiente del estado.
• El modelo relacional tampoco cuenta con el mecanismo de protección que aporta el aislamiento de datos.

Una forma de evitar estos problemas de incompatibilidad consiste en no utilizar bases de datos relacionales y optar por una BDOO cuando se programan aplicaciones orientadas a objetos. Sin embargo, la desventaja de esta opción es que los datos encapsulados en objetos dejan de estar disponibles fuera de la aplicación. A esto se añade la reducida expansión de este tipo de bases de datos. La mayoría de herramientas e interfaces que se utilizan para analizar bancos de datos sigue estando diseñada para bases de datos relacionales y no soportan el modelo orientado a objetos.

Pese a todo, los programadores de aplicaciones que no quieran prescindir de las ventajas del modelo relacional tienen la posibilidad de compensar estas incompatibilidades con ayuda del mapeo objeto-relacional (O/R mapping o object-relational mapping, ORM). Las funcionalidades para la representación objeto-relacional se implementan con bibliotecas que crean una capa de abstracción entre la aplicación orientada a objetos y los datos guardados en las tablas.

Asimismo, hay muchos fabricantes de sistemas relacionales que equipan sus productos con funciones para compensar estas incompatibilidades con la programación orientada a objetos. Estos sistemas se conocen como objeto-relacionales.

Las BDOO trasponen los principios de la orientación a objetos a la tecnología de bases de datos y por ello son adecuadas sobre todo en la programación de aplicaciones orientada a objetos, pero los sistemas de bases de datos de este tipo son poco frecuentes y aún muy nuevos para el mercado.

Los sistemas mixtos son sistemas de bases de datos relacionales que se han ampliado con conceptos del modelo orientado a objetos. De este modo los principios probados del modelo relacional se ampliarían a tipos abstractos de datos como los objetos.

Para poder gestionar estos tipos abstractos de datos, las bases de datos objeto-relacionales amplían las bases de datos relacionales con:

• Tipos de datos complejos y personalizables: mientras que las bases de datos relacionales solo pueden procesar datos alfanuméricos, con los tipos de datos personalizables también se pueden gestionar archivos multimedia estructurados de forma compleja.
• Constructores de tipos: permiten derivar tipos nuevos de los tipos básicos ya existentes.
• Funciones y métodos: como SQL no permite crear funciones, los sistemas objeto-relacionales han de proveer extensiones con las cuales puedan definirse funciones de acceso y edición de tipos de datos complejos.

A partir del cambio de siglo se incluyen extensiones objeto-relacionales, como los tipos estructurados, en las últimas versiones del estándar SQL, pero no los soportan todos los SGBD. Algunos sistemas conocidos que disponen de estas extensiones son IBM Db2, Oracle Database y Microsoft SQL Server.

Si en las bases de datos relacionales los datos se almacenan en tablas, el modelo orientado a documentos se basa en un conjunto heterogéneo de datos compuesto por documentos, que pueden ser estructurados, como archivos JSON, YAML o XML, o no estructurados, como Binary Large Objects (BLOB) –archivos de imagen, vídeo o audio.

En el caso de los documentos estructurados, el almacenamiento tiene lugar por medio de pares clave/valor donde a cada clave se le asigna un valor concreto. En este contexto se utiliza el término “clave” como sinónimo de atributo y no tiene nada que ver con las claves del modelo relacional. Los valores pueden equivaler a cualquier tipo de información. Las listas o las matrices también podrían ser valores.

Un documento en formato JSON para almacenar los datos de nuestra plantilla podría tener esta construcción:

Varios documentos pueden agruparse en una colección de documentos, una llamada collection. Este documento con datos de empleados podría unirse a otra parte de la colección “Empleados”.

Las consultas tienen lugar utilizando funciones, lo que puede hacerse con JavaScript. Los SGBD que trabajan orientados a documentos otorgan un ID único a cada documento, pero, a diferencia de como ocurre en el modelo relacional, aquí no existe ningún esquema que abarque a la base de datos por completo. Los documentos en una base de datos basada en documentos no han de observar ninguna forma normal ni existen propiedades estructurales que hayan de cumplirse en todos los documentos. En principio, cada documento puede tener una estructura diferente. Pese a todo, en lo que hace al desarrollo de aplicaciones, se recomienda crear los documentos en uno de los esquemas adecuados a la aplicación para lograr los requisitos necesarios para poder realizar consultas.

Las relaciones, como la conexión de tablas de bases de datos en el modelo relacional, no son posibles aquí. Aunque es posible añadir manualmente el ID de un documento como referencia en un documento diferente, los SGBD orientados a documentos no ofrecen JOIN, con lo que estas posibilidades de consulta deben programarse a propósito.

En definitiva, los sistemas orientados a documentos son la mejor opción si se han de procesar grandes cantidades de datos con estructura heterogénea y escasa interconexión. Esto hace a este modelo apto sobre todo para el trabajo con big data.

Los sistemas relacionales controlan en todo momento que se cumplan las condiciones indicadas en las definiciones de las tablas, lo que, al procesar grandes volúmenes de datos, conduce a una menor velocidad de escritura. Los sistemas NoSQL no presentan unos requisitos de consistencia de datos tan estrictos, condición que los hace adecuados para grandes arquitecturas en las cuales se han de gestionar de forma paralela muchas instancias de base de datos.

También las aplicaciones web recurren con frecuencia creciente a las bases de datos orientadas a documentos. Pero si se requiere una fuerte interconexión, el almacenamiento basado en documentos va ligado a un esfuerzo mucho mayor. En este caso sería más conveniente utilizar sistemas relacionales.

Algunos ejemplos de bases de datos orientadas a documentos son BaseX, CouchDB, eXist, MongoDB y RavenDB.

El modelo relacional para bases de datos se ha impuesto, no sin motivo, en el entorno del procesamiento electrónico de datos. Resumimos a continuación los principales puntos fuertes de este modelo de base de datos:

• Sencillez: el modelo de datos que subyace a la base de datos relacional se implementa y gestiona más fácilmente que otros modelos. Las ingentes cantidades de información (datos de clientes, listas de pedido, movimientos de las cuentas) que las empresas quieren almacenar a largo plazo se organizan sin problemas en la estructura de tablas en que se basa el modelo relacional de base de datos.
   
• Escasa redundancia de datos: las formas normales del modelo relacional fijan una normativa que tiene el fin de evitar duplicaciones. Si las reglas de normalización se aplican de forma consecuente, los sistemas relacionales facilitan un almacenamiento de datos libre de redundancias, puesto que solo es necesario editar los datos una única vez, lo que simplifica sobre todo el mantenimiento interno y técnico del banco de datos.
   
• Alta consistencia de datos: las bases de datos relacionales normalizadas permiten almacenar datos sin contradicciones, contribuyendo así a la consistencia de los datos. Asimismo, los sistemas relacionales presentan funciones con las cuales se definen y se controlan automáticamente las condiciones de integridad. Aquellas transacciones que ponen en peligro la consistencia de los datos se bloquean.
   
• Procesamiento de datos orientado a conjuntos: el sistema de base de datos relacional se apoya en un procesamiento orientado a conjuntos que subdivide cada entidad en valores mínimos. Esto permite conectar entidades diferentes por medio del contenido, así como realizar consultas complejas como JOIN.
   
• Lenguaje de consultas homogéneo: para la realización de consultas a bases de datos relacionales se ha consolidado el lenguaje SQL, que ha sido estandarizado por la ISO y la IEC. El propósito de tal estandarización es que las aplicaciones puedan desarrollarse y ejecutarse con independencia del SGBD en que se utilicen. Con todo, el soporte de SQL varía mucho en función del SGBD.

Según el escenario en que se emplean los sistemas de bases de datos relacionales, ciertas ventajas, como el estar basados en tablas, así como el reparto de los datos en tablas interconectadas, pueden interpretarse también como desventajas. Además, algunas de sus propiedades más destacadas son difícilmente reconciliables con los modernos requisitos de la programación de aplicaciones (orientación a objetos, multimedia y big data).

• Presentación de los datos en tablas: no siempre es posible integrar cualquier tipo de dato en el formato fijo de las tablas bidimensionales aun cuando estén interconectadas (impedance mismatch). Los datos abstractos o no estructurados que surgen en relación con las aplicaciones multimedia y las soluciones de big data no pueden representarse en el modelo relacional.
   
• Sistema no jerárquico: las bases de datos relacionales no ofrecen la posibilidad, a diferencia de las orientadas a objetos, de desarrollar tablas con clases organizadas de forma jerárquica, impidiendo, así, poner en práctica conceptos como las entidades subordinadas, que heredan propiedades de entidades superiores. De este modo no es posible, por ejemplo, crear subtuplas: todas las tuplas de una base de datos relacional están al mismo nivel jerárquico.
   
• Segmentación de los datos: el principio de base de los sistemas relacionales que consiste en almacenar la información en tablas separadas (normalización) conduce inevitablemente a su segmentación. Este diseño deriva en complejas consultas que abarcan varias tablas, de modo que el elevado número de segmentos resultantes acostumbra a reflejarse negativamente en el rendimiento.
   
• Peor rendimiento frente a las bases de datos NoSQL: el modelo relacional plantea elevados requisitos en cuanto a la consistencia de datos que van en detrimento de la velocidad de escritura en las transacciones.

El modelo relacional para bases de datos se caracteriza por la claridad, tiene una base matemática y ha probado su eficacia en la práctica durante más de 40 años. Pese a todo, el almacenamiento de datos en tablas estructuradas no se ha adaptado a las necesidades de la tecnología de la información moderna.

Son especialmente la gestión de grandes volúmenes de datos en el marco de los análisis de big data y el almacenamiento de datos abstractos los factores que saturan la capacidad de los sistemas relacionales. Y es precisamente aquí donde los sistemas especializados, como las BD basadas en objetos o los conceptos desarrollados en la senda del movimiento NoSQL, muestran su superioridad, si bien no es posible prescindir completamente del modelo relacional. Las bases de datos relacionales despliegan todo su potencial sobre todo en aquellos ámbitos corporativos protagonizados por el procesamiento de datos de transacciones.

Los datos sobre acciones de los clientes o medidas de marketing pueden representarse perfectamente en el formato de tabla, a la par que los usuarios sacan provecho de una sintaxis que, pese a su simplicidad, permite consultas complejas.