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:
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 = (A1:D1, A2:D2,… , An:Dn)
Aquí, la relación R comprende de los atributos A1a An y cada atributo corresponde a un tipo de dato o dominio (D1, D2 , etc.).
Veámoslo a la luz de un ejemplo concreto. El siguiente esquema define los atributos de la relación “Empleados”:
Empleados = ( e_ID : integer,
1er apellido : string
2º apellido : string,
nombre : string,
nº SS : string,
calle : string,
CP : string,
municipio : string )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):
(1, García, Fernández, Antonio, 32 12345678 12, Calle Principal 1, 11111, Villarriba)La tabla, concepto clásico de la organización de la información, es el formato que utiliza el modelo relacional para explicar de un modo visual la ordenación de los valores de una tupla en función de los atributos definidos en la relación. Una base de datos relacional no es otra cosa, entonces, que un conjunto de tablas interrelacionadas.
Las tablas son sistemas de clasificación constituidos por filas horizontales y columnas verticales que permiten agrupar datos y presentarlos de forma ordenada. Cada fila de una tabla se denomina tupla. Los valores que contiene cada tupla vienen determinados por los atributos definidos en el esquema relacional.
En el siguiente ejemplo se muestra una tabla tal como resultaría del esquema anterior:
| Empleados | |||||||
|---|---|---|---|---|---|---|---|
| e_ID | 1er apellido | 2º apellido | nombre | nº SS | calle | CP | municipio |
| 1 | García | Fernández | Antonio | 32 12345678 12 | Calle Principal 1 | 11111 | Villarriba |
| 2 | García | García | Josefa | 28 87654321 49 | Calle Iglesia 2 | 22222 | Villabajo |
| 3 | Expósito | Hernández | Gonzalo | 25 09122598 46 | Plaza Mercado 3 | 33333 | Campoarriba |
| 4 | Casas | González | Antonia | 23 17083912 78 | Calle Grande 4 | 44444 | Campoabajo |
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.
Tal y como lo definió Edgar F. Codd, el término “relación” se utiliza como sinónimo de “tabla”, pero en la práctica se aplica de forma diferente, entre otras cosas para hacer referencia también a las mismas relaciones entre las tablas. Para evitar malentendidos, en adelante evitaremos denominar relaciones a las tablas.
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:
En el modelo relacional se utiliza de forma estándar para estas operaciones el lenguaje de bases de datosSQL (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:
| Modelo de datos relacional | SQL |
|---|---|
| Relación | Table (tabla) |
| Atributo | Column (columna) |
| Tupla | Row (fila) |
Para ejecutar una consulta sencilla con SQL podemos utilizar este esquema:
SELECT columna FROM tabla WHERE columna = valor;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í:
SELECT nº SS FROM Empleados WHERE e_ID = 3;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.
En nuestro tutorial básico de SQL presentamos una descripción detallada de las operaciones fundamentales de SQL.
Cuando se trabaja con bases de datos relacionales, rara vez se hace con una única tabla. Normalmente se manejan arquitecturas en las cuales los datos se clasifican en tablas separadas en función de su significado. La necesidad de hacer consultas cruzadas para obtener datos guardados en tablas diferentes es la que da origen al concepto que sustenta el modelo relacional de bases de datos.
En principio, la información de una base de datos relacional podría guardarse sin problemas en una sola tabla, con la ventaja de que no sería necesario interconectar diversas tablas ni utilizar la compleja sintaxis derivada de las consultas a varias tablas diferentes. Sin embargo, es aquí precisamente donde reside la fuerza del modelo relacional, pues el reparto de información en varias tablas contribuye a reducir las entradas dobles (las llamadas anomalías), un proceso que se conoce como “normalización”. El grado de normalización de una tabla puede definirse a partir de varias formas normales:
Los requisitos de cada una de estas formas normales y la translación de una base de datos de una forma normal a otra son temas de nuestro artículo sobre la normalización.
En este modelo de datos se llama “relaciones” (relationships) a las relaciones entre tablas separadas por medio de claves. Estas claves son las que conectan las tablas entre sí y permiten que los datos de tablas diferentes puedan consultarse o modificarse siempre con la misma sentencia.
Las tablas como la de nuestro ejemplo permiten consultar valores o registros de distintas formas, pero en todas ellas el componente principal son las claves. En el modelo relacional se conoce como claves a los atributos que sirven para identificar un registro de forma inequívoca.
Volviendo a nuestra tabla “Empleados”, la siguiente clave permite identificar una tupla:
{e_ID, 1er apellido, 2º apellido, nombre, nº SS}Con los datos de la tabla, la siguiente clave serviría para identificar de forma única el registro del empleado Gonzalo Expósito:
(e_ID = '3', 1er apellido = 'Expósito', 2º apellido = 'Hernández', nombre = 'Gonzalo', nº SS = '25 091225 46') 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:
{e_ID}
{nº SS}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:
| coche_ID | marca | modelo | matrícula | fabricación | ITV |
|---|---|---|---|---|---|
| 1 | VW | Caddy | 1234 TGB | 2016 | 43452 |
| 2 | Opel | Astra | 9876 ZBU | 2010 | 43689 |
| 3 | BMW | X6 | 5847 LOG | 2017 | 43344 |
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:
| e_ID | 1er apellido | 2º apellido | nombre | nº SS | calle | CP | municipio | coche_ID |
|---|---|---|---|---|---|---|---|---|
| 1 | García | Fernández | Antonio | 32 12345678 12 | Calle Principal 1 | 11111 | Villarriba | 3 |
| 2 | García | García | Josefa | 28 87654321 49 | Calle Iglesia 2 | 22222 | Villabajo | 1 |
| 3 | Expósito | Hernández | Gonzalo | 25 091225 46 | Plaza Mercado 3 | 33333 | Campoarriba | 1 |
| 4 | Casas | González | Antonia | 23 170839 78 | Calle Grande 4 | 44444 | Campoabajo | 2 |
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:
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:
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:
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:
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:
{
"id" : 1,
"1er apellido" : "García",
"nombre" : "Antonio",
"nº SS" : " 32 12345678 12 ",
"calle" : "Calle principal, 1",
"CP" : "11111",
"Ciudad" : "Villarriba",
"coche_ID" : [1, 4]
}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:
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).
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.
Muy seguramente, todo desarrollador web se ha encontrado, en más de una ocasión, con el concepto CRUD. El acrónimo identifica a las operaciones típicas para la comunicación con los sistemas de bases de datos, encargadas de fijar las bases del proceso de gestión de datos. Ahora bien, ¿cómo se crean exactamente estas funciones de acceso y gestión de datos? y ¿qué papel juegan los lenguajes de...
Un punto fuerte del modelo relacional de bases de datos es el reparto de la información en bases de datos separadas que se estructuran en función de relaciones semánticas. Este concepto, denominado normalización, es la base para un almacenamiento de datos sin redundancia y requiere un mecanismo con el que puedan combinarse los datos de diferentes tablas para realizar consultas. Con los diferentes...
Las bases de datos en memoria permiten analizar y suministrar big data en tiempo real. El almacenamiento en la unidad de memoria RAM propicia esta alta velocidad de acceso. Las bases de datos tradicionales se basan, en cambio, en el almacenamiento en el disco duro. ¿En qué se diferencian las bases de datos en memoria de los sistemas de bases de datos tradicionales? Y ¿cuáles son las bases de datos...
El sistema de gestión de bases de datos PostgreSQL, conocido por muchos como Postgres, es el resultado de un trabajo de desarrollo que se extiende a lo largo de varias décadas. El proyecto, que nació en la Universidad de Berkeley en California, es hoy una base de datos de código abierto que no tiene miedo a plantar cara a las soluciones comerciales de la competencia, entre otras cosas porque la...
En general, las bases de datos se organizan en líneas. Las bases de datos columnares dan la vuelta a este sistema: en lugar de almacenar cada entrada una tras otra, una columnar database almacena las entradas categoría por categoría. Si se trabaja con grandes cantidades de datos, esto supone un gran aumento de la velocidad. Pero ¿cómo funcionan las bases de datos columnares?
Ofrece un servicio fiable y de alto rendimiento a tus clientes con un pack hosting de IONOS.
Ver planes