Las bases de datos son parte esencial de cualquier sistema in­fo­r­má­ti­co, 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 co­n­tra­di­c­cio­nes y a largo plazo. Esto es posible en bases de datos (BD) es­tru­c­tu­ra­das y ge­s­tio­na­das por sistemas de gestión de bases de datos (SGBD), apli­ca­cio­nes de software que in­ter­ac­túan con el usuario o con otros programas para poner a su di­s­po­si­ción un segmento de la in­fo­r­ma­ción guardada en la base de datos.

Hasta hoy la gestión ele­c­tró­ni­ca de datos ha estado dominada por el modelo de base de datos re­la­cio­nal. Entre los gestores de bases de datos re­la­cio­na­les más uti­li­za­dos se cuentan, por orden al­fa­bé­ti­co:

  • Db2: con Db2 los usuarios disponen de un SGBD re­la­cio­nal pro­pie­ta­rio de la casa IBM.
     
  • Microsoft SQL Server: la apli­ca­ción de Microsoft para gestionar bases de datos re­la­cio­na­les está di­s­po­ni­ble 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 di­s­tri­bu­ye con una licencia dual. Sus primeros de­sa­rro­lla­do­res siguen en­ca­r­gá­n­do­se del proyecto, ahora bajo el nombre de MariaDB.
     
  • Po­s­t­gre­S­QL: con Po­s­t­gre­S­QL los usuarios disponen de un SGBD re­la­cio­nal libre y orientado a objetos de cuyo continuo de­sa­rro­llo se ocupa su comunidad open source.
     
  • Oracle Database: el programa de Oracle se di­s­tri­bu­ye como software pro­pie­ta­rio.
     
  • SQLite: por último, SQLite co­n­s­ti­tu­ye una bi­blio­te­ca de programas con licencia de dominio público que contiene un gestor de bases de datos re­la­cio­na­les.

Todos estos sistemas se basan en una or­ga­ni­za­ción tabular de la in­fo­r­ma­ción, pero ¿cómo exac­ta­me­n­te? A co­n­ti­nua­ción nos ade­n­tra­mos en los pri­n­ci­pios fu­n­da­me­n­ta­les del diseño de bases de datos re­la­cio­na­les, pre­se­n­ta­mos algunos ejemplos y las di­s­ti­n­gui­mos de otros modelos de datos.

Qué es una base de datos re­la­cio­nal

Un concepto capital del modelo re­la­cio­nal es el de relación, postulado por el ma­te­má­ti­co y teórico de bases de datos Edgar F. Codd. Siguiendo al cie­n­tí­fi­co británico, una relación re­pre­se­n­ta un conjunto de entidades con las mismas pro­pie­da­des. 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 A1 a An y cada atributo co­rre­s­po­n­de 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 uti­li­zar­se para la gestión interna de los datos pe­r­so­na­les de la plantilla de una empresa.

A cada atributo le co­rre­s­po­n­de un tipo de dato, string o integer, lo que indica que hay atributos que esperan cómo valor una secuencia de ca­ra­c­te­res (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 or­ga­ni­za­ción de la in­fo­r­ma­ción, es el formato que utiliza el modelo re­la­cio­nal para explicar de un modo visual la or­de­na­ción de los valores de una tupla en función de los atributos definidos en la relación. Una base de datos re­la­cio­nal no es otra cosa, entonces, que un conjunto de tablas in­ter­re­la­cio­na­das.

Las tablas son sistemas de cla­si­fi­ca­ción co­n­s­ti­tui­dos por filas ho­ri­zo­n­ta­les y columnas ve­r­ti­ca­les que permiten agrupar datos y pre­se­n­tar­los de forma ordenada. Cada fila de una tabla se denomina tupla. Los valores que contiene cada tupla vienen de­te­r­mi­na­dos por los atributos definidos en el esquema re­la­cio­nal.

Imagen: Representación gráfica de una relación según el modelo relacional
En el modelo de bases de datos re­la­cio­nal se llama relación a un conjunto de tuplas con los mismos atributos

En el siguiente ejemplo se muestra una tabla tal como re­su­l­ta­rí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 Vi­lla­rri­ba
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 Ca­m­poa­rri­ba
4 Casas González Antonia 23 17083912 78 Calle Grande 4 44444 Ca­m­poa­ba­jo

Esta tabla guarda los datos de la plantilla de una empresa y se compone de cuatro registros, cada uno de los cuales contiene in­fo­r­ma­ción sobre un solo empleado.

Nota

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 re­fe­re­n­cia también a las mismas re­la­cio­nes entre las tablas. Para evitar ma­le­n­te­n­di­dos, en adelante evi­ta­re­mos denominar re­la­cio­nes a las tablas.

Cómo funcionan las bases de datos re­la­cio­na­les

Los datos es­tru­c­tu­ra­dos en tablas co­n­s­ti­tu­yen la BD de un sistema re­la­cio­nal. El SGBD define su es­tru­c­tu­ra y gestiona también los permisos de escritura y lectura y para in­ter­ac­tuar con él, los usuarios utilizan un lenguaje de bases de datos. Todo gestor de bases de datos re­la­cio­na­les soporta al menos un lenguaje formal que permite ejecutar las si­guie­n­tes ope­ra­cio­nes:

  • Definir la es­tru­c­tu­ra de datos: en la de­fi­ni­ción de los datos se guarda una de­s­cri­p­ción con metadatos de la es­tru­c­tu­ra de datos en el di­c­cio­na­rio del sistema. Cuando un usuario crea una tabla nueva, en el di­c­cio­na­rio de datos se almacena su co­rre­s­po­n­die­n­te esquema. El vo­ca­bu­la­rio de un lenguaje de bases de datos que se utiliza para definir los datos se denomina Data De­fi­ni­tion Language (DDL), lenguaje de de­fi­ni­ción de datos.
     
  • Definir derechos: todos los lenguajes de bases de datos pro­po­r­cio­nan 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 vo­ca­bu­la­rio integrado en el lenguaje de bases de datos.
     
  • Definir co­n­di­cio­nes de in­te­gri­dad: por co­n­di­cio­nes de in­te­gri­dad se entienden los re­qui­si­tos de estado que se exigen a un banco de datos. Si se definen co­n­di­cio­nes para su in­te­gri­dad, la BD garantiza que se cumplan en todo momento. Se habla entonces de un estado co­n­si­s­te­n­te. Una condición básica de in­te­gri­dad en una base de datos re­la­cio­nal es, por ejemplo, que cada registro (tupla) pueda ide­n­ti­fi­car­se de forma ine­quí­vo­ca.
     
  • Definir tra­n­sac­cio­nes: cuando se lleva a una BD de un estado co­n­si­s­te­n­te a otro diferente se habla de tra­n­sac­ción. Estas tra­n­sac­cio­nes contienen una serie de in­s­tru­c­cio­nes que deben eje­cu­tar­se siempre de forma íntegra. Si una se in­te­rru­m­pe, la BD vuelve a su estado original (Rollback). Cada tra­n­sac­ción comienza con una orden para crear una conexión con la BD a la que siguen otras que inician las ope­ra­cio­nes de datos en sí, así como un paso de co­m­pro­ba­ción (Commit) que asegura la in­te­gri­dad de la BD. Las ope­ra­cio­nes que pongan en peligro la in­te­gri­dad de la tabla no se consignan (committed), es decir, no se escriben en la base de datos de forma pe­r­ma­ne­n­te. Por último, se cierra la conexión con la BD. Al vo­ca­bu­la­rio del lenguaje de bases de datos con el que se manipulan los datos se le conoce como Data Ma­ni­pu­la­tion Language (DML).
     
  • Definir vistas: las llamadas views son vistas virtuales de un su­b­co­n­ju­n­to 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 ope­ra­cio­nes que se uti­li­za­rían en tablas físicas. Según la función de la vista de datos pueden di­s­ti­n­gui­r­se distintos tipos de vista. Las más ha­bi­tua­les son aquellas que filtran de­te­r­mi­na­das 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 re­la­cio­nal se utiliza de forma estándar para estas ope­ra­cio­nes el lenguaje de bases de datos SQL (Stru­c­tu­red Query Language), basado en el álgebra re­la­cio­nal.

Las ope­ra­cio­nes típicas de las BD como consultar, crear, ac­tua­li­zar o borrar datos se realizan por medio de las llamadas se­n­te­n­cias SQL (SQL sta­te­me­nts), una co­m­bi­na­ción de órdenes SQL, se­má­n­ti­ca­me­n­te vi­n­cu­la­das al inglés y por este motivo bastante elo­cue­n­tes. La siguiente tabla contiene términos fu­n­da­me­n­ta­les del modelo de datos re­la­cio­nal y su equi­va­le­n­te en te­r­mi­no­lo­gía SQL:

Modelo de datos re­la­cio­nal 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;

Uti­li­za­mos SELECT en primer lugar para ordenar al SGBD re­la­cio­nal que consulte ciertos datos. A co­n­ti­nua­ción definimos los datos que queremos consultar pro­po­r­cio­na­n­do tanto la tabla como la columna que deseamos se­le­c­cio­nar. Con WHERE in­te­gra­mos una condición en la sentencia SQL porque no queremos abrir todos los valores en esta columna, sino solo el valor de un de­te­r­mi­na­do registro.

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

SELECT nº SS FROM Empleados WHERE e_ID = 3;

Esta de­cla­ra­ció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 se­le­c­cio­ne 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 ide­n­ti­fi­ca­do con el número 3.

Consejo

En nuestro tutorial básico de SQL pre­se­n­ta­mos una de­s­cri­p­ción detallada de las ope­ra­cio­nes fu­n­da­me­n­ta­les de SQL.

No­r­ma­li­za­ción

Cuando se trabaja con bases de datos re­la­cio­na­les, rara vez se hace con una única tabla. No­r­ma­l­me­n­te se manejan ar­qui­te­c­tu­ras en las cuales los datos se cla­si­fi­can en tablas separadas en función de su si­g­ni­fi­ca­do. La necesidad de hacer consultas cruzadas para obtener datos guardados en tablas di­fe­re­n­tes es la que da origen al concepto que sustenta el modelo re­la­cio­nal de bases de datos.

En principio, la in­fo­r­ma­ción de una base de datos re­la­cio­nal podría guardarse sin problemas en una sola tabla, con la ventaja de que no sería necesario in­te­r­co­ne­c­tar diversas tablas ni utilizar la compleja sintaxis derivada de las consultas a varias tablas di­fe­re­n­tes. Sin embargo, es aquí pre­ci­sa­me­n­te donde reside la fuerza del modelo re­la­cio­nal, pues el reparto de in­fo­r­ma­ción en varias tablas co­n­tri­bu­ye a reducir las entradas dobles (las llamadas anomalías), un proceso que se conoce como “no­r­ma­li­za­ción”. El grado de no­r­ma­li­za­ción de una tabla puede definirse a partir de varias formas normales:

  • Primera forma normal (1FN)
  • Segunda forma normal (2FN)
  • Tercera forma normal (3NF)
  • Forma normal de BoyceCodd (FNBC)
  • Cuarta forma normal (4FN)
  • Quinta forma normal (5FN)

Los re­qui­si­tos de cada una de estas formas normales y la tra­n­s­la­ción de una base de datos de una forma normal a otra son temas de nuestro artículo sobre la no­r­ma­li­za­ción.

En este modelo de datos se llama “re­la­cio­nes” (re­la­tio­n­shi­ps) a las re­la­cio­nes entre tablas separadas por medio de claves. Estas claves son las que conectan las tablas entre sí y permiten que los datos de tablas di­fe­re­n­tes puedan co­n­su­l­tar­se o mo­di­fi­car­se siempre con la misma sentencia.

Claves

Las tablas como la de nuestro ejemplo permiten consultar valores o registros de distintas formas, pero en todas ellas el co­m­po­ne­n­te principal son las claves. En el modelo re­la­cio­nal se conoce como claves a los atributos que sirven para ide­n­ti­fi­car un registro de forma ine­quí­vo­ca.

Volviendo a nuestra tabla “Empleados”, la siguiente clave permite ide­n­ti­fi­car una tupla:

{e_ID, 1er apellido, 2º apellido, nombre, nº SS}

Con los datos de la tabla, la siguiente clave serviría para ide­n­ti­fi­car 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 su­pe­r­cla­ves, si bien en la práctica tienen poca re­le­va­n­cia, entre otras cosas porque a menudo contienen más atributos de los ne­ce­sa­rios. En cambio, en el contexto de las bases de datos re­la­cio­na­les, aco­s­tu­m­bra a tra­ba­jar­se con los fra­g­me­n­tos más pequeños de una su­pe­r­cla­ve, los llamados ca­n­di­da­tos a clave. Una tabla puede contener varios ca­n­di­da­tos a clave que ide­n­ti­fi­can a las tuplas ine­quí­vo­ca­me­n­te.

Como hemos visto en nuestra consulta anterior, los registros de la tabla “Empleados” pueden ide­n­ti­fi­car­se solo con el número de ide­n­ti­fi­ca­ció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 en­co­n­trar­se a varios empleados con el mismo nombre y el mismo primer apellido). En co­n­se­cue­n­cia, una ide­n­ti­fi­ca­ció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 si­guie­n­tes ca­n­di­da­tos a clave:

{e_ID} 
{nº SS}

Las bases de datos re­la­cio­na­les suelen es­tru­c­tu­rar­se de tal forma que uno de los posibles ca­n­di­da­tos 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 ide­n­ti­fi­ca­ti­vos co­n­se­cu­ti­vos. En nuestra tabla sería e_ID.

Por su capacidad para ide­n­ti­fi­car los registros en las bases de datos re­la­cio­na­les, las claves se ajustan a la pe­r­fe­c­ción para in­te­r­co­ne­c­tar las di­fe­re­n­tes 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 pre­se­n­ta­mos a co­n­ti­nua­ción contiene los datos que una empresa podría haber re­gi­s­tra­do sobre su parque móvil. La clave primaria de la tabla llamada “Vehículos” es un coche_ID co­n­se­cu­ti­vo:

coche_ID marca modelo matrícula fa­bri­ca­ció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 co­ne­c­tar­se la tabla “Vehículos” con la tabla “Empleados”. Una forma de hacerlo sería in­te­gra­n­do 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 Vi­lla­rri­ba 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 Ca­m­poa­rri­ba 1
4 Casas González Antonia 23 170839 78 Calle Grande 4 44444 Ca­m­poa­ba­jo 2

Ahora sabemos que el tra­ba­ja­dor 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é tra­ba­ja­dor 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 ope­ra­cio­nes de BD que abarcan varias tablas se realizan en el modelo re­la­cio­nal con ayuda de las llamadas se­n­te­n­cias JOIN.

JOIN

JOIN puede tra­du­ci­r­se como la acción de “unir” o “combinar” y en este contexto hace re­fe­re­n­cia a una operación que permite consultar varias tablas de datos si­mu­l­tá­nea­me­n­te. Los datos que se extraen de las tablas se­le­c­cio­na­das se agrupan en un su­b­co­n­ju­n­to con todos los posibles re­su­l­ta­dos (espacio de muestreo en ma­te­má­ti­cas) y se entregan en función de las co­n­di­cio­nes que se han definido.

El fu­n­da­me­n­to ma­te­má­ti­co del JOIN de SQL lo componen dos ope­ra­cio­nes del álgebra re­la­cio­nal: el producto ca­r­te­siano 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 im­po­r­ta­n­tes se cuentan:

  • INNER JOIN (co­m­bi­na­ción interna)
  • OUTER JOIN (co­m­bi­na­ció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 re­la­cio­na­les y qué has de tener en cuenta al escoger el tipo de JOIN.

Di­fe­re­n­cias con otros modelos de bases de datos

Las bases de datos re­la­cio­na­les basadas en SQL se di­fe­re­n­cian de los conceptos que rompen con la es­tru­c­tu­ra fija de las tablas y persiguen un enfoque al­te­r­na­ti­vo a la hora de organizar los datos. Entre los más im­po­r­ta­n­tes se en­cue­n­tran las bases de datos orie­n­ta­das a objetos y los sistemas basados en do­cu­me­n­tos.

Con las bases de datos orie­n­ta­das a objetos (BDOO) entra en escena a finales de la década de 1980 un nuevo modelo que retoma elementos de la pro­gra­ma­ción orientada a objetos y permite el al­ma­ce­na­mie­n­to de los datos en forma de objetos. Aunque este principio no logra co­n­so­li­dar­se, algunas de sus ideas consiguen colarse en el de­sa­rro­llo de sistemas de bases de datos re­la­cio­na­les. El resultado son productos con ex­te­n­sio­nes objeto-re­la­cio­na­les que facilitan el al­ma­ce­na­mie­n­to de tipos ab­s­tra­c­tos de datos en el modelo re­la­cio­nal 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 re­la­cio­nal volvió a ser objeto de críticas. En el marco del mo­vi­mie­n­to NoSQL (Not only SQL), cuyo objeto era crear sistemas de BD de gran re­n­di­mie­n­to aptos para apli­ca­cio­nes con un uso masivo de datos, comienzan a de­sa­rro­llar­se entonces modelos al­te­r­na­ti­vos como el de las bases de datos orie­n­ta­das a do­cu­me­n­tos (BDOD). Estos dos modelos, los orie­n­ta­dos a objetos y a do­cu­me­n­tos, se di­fe­re­n­cian del modelo re­la­cio­nal sobre todo en la forma como se almacenan y se accede a los datos.

Bases de datos orie­n­ta­das a objetos

El modelo orientado a objetos considera el al­ma­ce­na­mie­n­to de datos como objetos, los cuales se procesan de forma análoga a como sucede en la pro­gra­ma­ción orientada a objetos. Un objeto define a una entidad y contiene:

  • los atributos ne­ce­sa­rios para describir a la entidad,
  • co­ne­xio­nes (re­la­cio­nes) con otros objetos,
  • funciones que permiten acceder a los datos al­ma­ce­na­dos (métodos).

Un objeto es, así, una co­m­bi­na­ción de datos en la cual también se define el punto de acceso a estos datos. Los objetos se co­n­si­de­ran tipos ab­s­tra­c­tos de datos.

El SGBD orientado a objetos (ODBMS, object database ma­na­ge­me­nt system) asigna au­to­má­ti­ca­me­n­te un ID a cada objeto que permite ide­n­ti­fi­car­le de forma única y dirigirse a él con métodos. Este ID es in­de­pe­n­die­n­te del estado del objeto y está de­s­vi­n­cu­la­do de sus valores. Esto permite asignar ID di­fe­re­n­tes a dos objetos con los mismos datos, esto es, con un mismo estado. El modelo orientado a objetos se aleja así del re­la­cio­nal, modelo en el que cada tupla puede ide­n­ti­fi­car­se a partir de sus datos, por ejemplo, con una clave primaria.

Otra ca­ra­c­te­rí­s­ti­ca del modelo orientado a objetos es el ai­s­la­mie­n­to de los datos: la única forma de acceder a los datos guardados es uti­li­za­n­do los métodos que el usuario ha definido pre­via­me­n­te. Esto protege a los datos de cambios pro­ce­de­n­tes de puntos de acceso no definidos.

Por otro lado, las es­tru­c­tu­ras de bases de datos se definen aquí por medio de un sistema de clases je­rá­r­qui­co. En el contexto de la pro­gra­ma­ción orientada a objetos, una clase es un conjunto de objetos que poseen las mismas pro­pie­da­des y a cada clase de objetos le subyace una de­fi­ni­ción de clases. Este esquema prescribe los atributos y los métodos de todos los objetos de la misma clase, de­te­r­mi­na­n­do así cómo se crean y se modifican.

Para in­ter­ac­tuar 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 re­su­l­ta­dos posibles, sino una lista de todos los objetos que sa­ti­s­fa­cen las co­n­di­cio­nes de la de­cla­ra­ción OQL.

Algunas im­ple­me­n­ta­cio­nes conocidas del modelo de BDOO son Realm, ZODB y Perst.

El de­sa­rro­llo de las BDOO pretendía so­lu­cio­nar un problema de la pro­gra­ma­ción de apli­ca­cio­nes, la in­co­m­pa­ti­bi­li­dad de im­pe­da­n­cia objeto-re­la­cio­nal (Object-re­la­tio­nal impedence mismatch), que se produce in­e­vi­ta­ble­me­n­te si se guardan objetos de un lenguaje orientado a objetos como C#, C++ o Java en una base de datos re­la­cio­nal y resulta de las di­fe­re­n­cias fu­n­da­me­n­ta­les entre ambos pa­ra­di­g­mas de pro­gra­ma­ción, como son:

  • Las bases de datos re­la­cio­na­les no soportan conceptos orie­n­ta­dos a objetos como las clases y la herencia.
  • El modelo re­la­cio­nal no permite la ide­n­ti­fi­ca­ción de objetos in­de­pe­n­die­n­te del estado.
  • El modelo re­la­cio­nal tampoco cuenta con el mecanismo de pro­te­c­ción que aporta el ai­s­la­mie­n­to de datos.

Una forma de evitar estos problemas de in­co­m­pa­ti­bi­li­dad consiste en no utilizar bases de datos re­la­cio­na­les y optar por una BDOO cuando se programan apli­ca­cio­nes orie­n­ta­das a objetos. Sin embargo, la de­s­ve­n­ta­ja de esta opción es que los datos en­ca­p­su­la­dos en objetos dejan de estar di­s­po­ni­bles fuera de la apli­ca­ción. A esto se añade la reducida expansión de este tipo de bases de datos. La mayoría de he­rra­mie­n­tas e in­te­r­fa­ces que se utilizan para analizar bancos de datos sigue estando diseñada para bases de datos re­la­cio­na­les y no soportan el modelo orientado a objetos.

Pese a todo, los pro­gra­ma­do­res de apli­ca­cio­nes que no quieran pre­s­ci­n­dir de las ventajas del modelo re­la­cio­nal tienen la po­si­bi­li­dad de compensar estas in­co­m­pa­ti­bi­li­da­des con ayuda del mapeo objeto-re­la­cio­nal (O/R mapping o object-re­la­tio­nal mapping, ORM). Las fu­n­cio­na­li­da­des para la re­pre­se­n­ta­ción objeto-re­la­cio­nal se im­ple­me­n­tan con bi­blio­te­cas que crean una capa de ab­s­tra­c­ción entre la apli­ca­ción orientada a objetos y los datos guardados en las tablas.

Asimismo, hay muchos fa­bri­ca­n­tes de sistemas re­la­cio­na­les que equipan sus productos con funciones para compensar estas in­co­m­pa­ti­bi­li­da­des con la pro­gra­ma­ción orientada a objetos. Estos sistemas se conocen como objeto-re­la­cio­na­les.

Las BDOO trasponen los pri­n­ci­pios de la orie­n­ta­ción a objetos a la te­c­no­lo­gía de bases de datos y por ello son adecuadas sobre todo en la pro­gra­ma­ción de apli­ca­cio­nes orientada a objetos, pero los sistemas de bases de datos de este tipo son poco fre­cue­n­tes y aún muy nuevos para el mercado.

Bases de datos objeto-re­la­cio­na­les

Los sistemas mixtos son sistemas de bases de datos re­la­cio­na­les que se han ampliado con conceptos del modelo orientado a objetos. De este modo los pri­n­ci­pios probados del modelo re­la­cio­nal se am­plia­rían a tipos ab­s­tra­c­tos de datos como los objetos.

Para poder gestionar estos tipos ab­s­tra­c­tos de datos, las bases de datos objeto-re­la­cio­na­les amplían las bases de datos re­la­cio­na­les con:

  • Tipos de datos complejos y pe­r­so­na­li­za­bles: mientras que las bases de datos re­la­cio­na­les solo pueden procesar datos al­fa­nu­mé­ri­cos, con los tipos de datos pe­r­so­na­li­za­bles también se pueden gestionar archivos mu­l­ti­me­dia es­tru­c­tu­ra­dos de forma compleja.
  • Co­n­s­tru­c­to­res de tipos: permiten derivar tipos nuevos de los tipos básicos ya exi­s­te­n­tes.
  • Funciones y métodos: como SQL no permite crear funciones, los sistemas objeto-re­la­cio­na­les han de proveer ex­te­n­sio­nes con las cuales puedan definirse funciones de acceso y edición de tipos de datos complejos.

A partir del cambio de siglo se incluyen ex­te­n­sio­nes objeto-re­la­cio­na­les, como los tipos es­tru­c­tu­ra­dos, en las últimas versiones del estándar SQL, pero no los soportan todos los SGBD. Algunos sistemas conocidos que disponen de estas ex­te­n­sio­nes son IBM Db2, Oracle Database y Microsoft SQL Server.

Bases de datos orie­n­ta­das a do­cu­me­n­tos

Si en las bases de datos re­la­cio­na­les los datos se almacenan en tablas, el modelo orientado a do­cu­me­n­tos se basa en un conjunto he­te­ro­gé­neo de datos compuesto por do­cu­me­n­tos, que pueden ser es­tru­c­tu­ra­dos, como archivos JSON, YAML o XML, o no es­tru­c­tu­ra­dos, como Binary Large Objects (BLOB) –archivos de imagen, vídeo o audio.

En el caso de los do­cu­me­n­tos es­tru­c­tu­ra­dos, el al­ma­ce­na­mie­n­to 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 re­la­cio­nal. Los valores pueden equivaler a cualquier tipo de in­fo­r­ma­ció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 co­n­s­tru­c­ció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 do­cu­me­n­tos pueden agruparse en una colección de do­cu­me­n­tos, una llamada co­lle­c­tion. Este documento con datos de empleados podría unirse a otra parte de la colección “Empleados”.

Las consultas tienen lugar uti­li­za­n­do funciones, lo que puede hacerse con Ja­va­S­cri­pt. Los SGBD que trabajan orie­n­ta­dos a do­cu­me­n­tos otorgan un ID único a cada documento, pero, a di­fe­re­n­cia de como ocurre en el modelo re­la­cio­nal, aquí no existe ningún esquema que abarque a la base de datos por completo. Los do­cu­me­n­tos en una base de datos basada en do­cu­me­n­tos no han de observar ninguna forma normal ni existen pro­pie­da­des es­tru­c­tu­ra­les que hayan de cumplirse en todos los do­cu­me­n­tos. En principio, cada documento puede tener una es­tru­c­tu­ra diferente. Pese a todo, en lo que hace al de­sa­rro­llo de apli­ca­cio­nes, se re­co­mie­n­da crear los do­cu­me­n­tos en uno de los esquemas adecuados a la apli­ca­ción para lograr los re­qui­si­tos ne­ce­sa­rios para poder realizar consultas.

Las re­la­cio­nes, como la conexión de tablas de bases de datos en el modelo re­la­cio­nal, no son posibles aquí. Aunque es posible añadir ma­nua­l­me­n­te el ID de un documento como re­fe­re­n­cia en un documento diferente, los SGBD orie­n­ta­dos a do­cu­me­n­tos no ofrecen JOIN, con lo que estas po­si­bi­li­da­des de consulta deben pro­gra­mar­se a propósito.

En de­fi­ni­ti­va, los sistemas orie­n­ta­dos a do­cu­me­n­tos son la mejor opción si se han de procesar grandes ca­n­ti­da­des de datos con es­tru­c­tu­ra he­te­ro­gé­nea y escasa in­te­r­co­ne­xión. Esto hace a este modelo apto sobre todo para el trabajo con big data.

Los sistemas re­la­cio­na­les controlan en todo momento que se cumplan las co­n­di­cio­nes indicadas en las de­fi­ni­cio­nes 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 re­qui­si­tos de co­n­si­s­te­n­cia de datos tan estrictos, condición que los hace adecuados para grandes ar­qui­te­c­tu­ras en las cuales se han de gestionar de forma paralela muchas in­s­ta­n­cias de base de datos.

También las apli­ca­cio­nes web recurren con fre­cue­n­cia creciente a las bases de datos orie­n­ta­das a do­cu­me­n­tos. Pero si se requiere una fuerte in­te­r­co­ne­xión, el al­ma­ce­na­mie­n­to basado en do­cu­me­n­tos va ligado a un esfuerzo mucho mayor. En este caso sería más co­n­ve­nie­n­te utilizar sistemas re­la­cio­na­les.

Algunos ejemplos de bases de datos orie­n­ta­das a do­cu­me­n­tos son BaseX, CouchDB, eXist, MongoDB y RavenDB.

Bases de datos re­la­cio­na­les: ¿qué ventajas tienen?

El modelo re­la­cio­nal para bases de datos se ha impuesto, no sin motivo, en el entorno del pro­ce­sa­mie­n­to ele­c­tró­ni­co de datos. Resumimos a co­n­ti­nua­ción los pri­n­ci­pa­les puntos fuertes de este modelo de base de datos:

  • Sencillez: el modelo de datos que subyace a la base de datos re­la­cio­nal se im­ple­me­n­ta y gestiona más fá­ci­l­me­n­te que otros modelos. Las ingentes ca­n­ti­da­des de in­fo­r­ma­ción (datos de clientes, listas de pedido, mo­vi­mie­n­tos de las cuentas) que las empresas quieren almacenar a largo plazo se organizan sin problemas en la es­tru­c­tu­ra de tablas en que se basa el modelo re­la­cio­nal de base de datos.
     
  • Escasa re­du­n­da­n­cia de datos: las formas normales del modelo re­la­cio­nal fijan una normativa que tiene el fin de evitar du­pli­ca­cio­nes. Si las reglas de no­r­ma­li­za­ción se aplican de forma co­n­se­cue­n­te, los sistemas re­la­cio­na­les facilitan un al­ma­ce­na­mie­n­to de datos libre de re­du­n­da­n­cias, puesto que solo es necesario editar los datos una única vez, lo que si­m­pli­fi­ca sobre todo el ma­n­te­ni­mie­n­to interno y técnico del banco de datos.
     
  • Alta co­n­si­s­te­n­cia de datos: las bases de datos re­la­cio­na­les no­r­ma­li­za­das permiten almacenar datos sin co­n­tra­di­c­cio­nes, co­n­tri­bu­ye­n­do así a la co­n­si­s­te­n­cia de los datos. Asimismo, los sistemas re­la­cio­na­les presentan funciones con las cuales se definen y se controlan au­to­má­ti­ca­me­n­te las co­n­di­cio­nes de in­te­gri­dad. Aquellas tra­n­sac­cio­nes que ponen en peligro la co­n­si­s­te­n­cia de los datos se bloquean.
     
  • Pro­ce­sa­mie­n­to de datos orientado a conjuntos: el sistema de base de datos re­la­cio­nal se apoya en un pro­ce­sa­mie­n­to orientado a conjuntos que subdivide cada entidad en valores mínimos. Esto permite conectar entidades di­fe­re­n­tes por medio del contenido, así como realizar consultas complejas como JOIN.
     
  • Lenguaje de consultas homogéneo: para la rea­li­za­ción de consultas a bases de datos re­la­cio­na­les se ha co­n­so­li­da­do el lenguaje SQL, que ha sido es­ta­n­da­ri­za­do por la ISO y la IEC. El propósito de tal es­ta­n­da­ri­za­ción es que las apli­ca­cio­nes puedan de­sa­rro­llar­se y eje­cu­tar­se con in­de­pe­n­de­n­cia del SGBD en que se utilicen. Con todo, el soporte de SQL varía mucho en función del SGBD.

In­co­n­ve­nie­n­tes de las bases de datos re­la­cio­na­les

Según el escenario en que se emplean los sistemas de bases de datos re­la­cio­na­les, ciertas ventajas, como el estar basados en tablas, así como el reparto de los datos en tablas in­te­r­co­ne­c­ta­das, pueden in­te­r­pre­tar­se también como de­s­ve­n­ta­jas. Además, algunas de sus pro­pie­da­des más de­s­ta­ca­das son di­fí­ci­l­me­n­te re­co­n­ci­lia­bles con los modernos re­qui­si­tos de la pro­gra­ma­ción de apli­ca­cio­nes (orie­n­ta­ción a objetos, mu­l­ti­me­dia y big data).

  • Pre­se­n­ta­ción de los datos en tablas: no siempre es posible integrar cualquier tipo de dato en el formato fijo de las tablas bi­di­me­n­sio­na­les aun cuando estén in­te­r­co­ne­c­ta­das (impedance mismatch). Los datos ab­s­tra­c­tos o no es­tru­c­tu­ra­dos que surgen en relación con las apli­ca­cio­nes mu­l­ti­me­dia y las so­lu­cio­nes de big data no pueden re­pre­se­n­tar­se en el modelo re­la­cio­nal.
     
  • Sistema no je­rá­r­qui­co: las bases de datos re­la­cio­na­les no ofrecen la po­si­bi­li­dad, a di­fe­re­n­cia de las orie­n­ta­das a objetos, de de­sa­rro­llar tablas con clases or­ga­ni­za­das de forma je­rá­r­qui­ca, im­pi­die­n­do, así, poner en práctica conceptos como las entidades su­bo­r­di­na­das, que heredan pro­pie­da­des de entidades su­pe­rio­res. De este modo no es posible, por ejemplo, crear subtuplas: todas las tuplas de una base de datos re­la­cio­nal están al mismo nivel je­rá­r­qui­co.
     
  • Se­g­me­n­ta­ción de los datos: el principio de base de los sistemas re­la­cio­na­les que consiste en almacenar la in­fo­r­ma­ción en tablas separadas (no­r­ma­li­za­ción) conduce in­e­vi­ta­ble­me­n­te a su se­g­me­n­ta­ción. Este diseño deriva en complejas consultas que abarcan varias tablas, de modo que el elevado número de segmentos re­su­l­ta­n­tes aco­s­tu­m­bra a re­fle­jar­se ne­ga­ti­va­me­n­te en el re­n­di­mie­n­to.
     
  • Peor re­n­di­mie­n­to frente a las bases de datos NoSQL: el modelo re­la­cio­nal plantea elevados re­qui­si­tos en cuanto a la co­n­si­s­te­n­cia de datos que van en de­tri­me­n­to de la velocidad de escritura en las tra­n­sac­cio­nes.

Co­n­clu­sión

El modelo re­la­cio­nal para bases de datos se ca­ra­c­te­ri­za por la claridad, tiene una base ma­te­má­ti­ca y ha probado su eficacia en la práctica durante más de 40 años. Pese a todo, el al­ma­ce­na­mie­n­to de datos en tablas es­tru­c­tu­ra­das no se ha adaptado a las ne­ce­si­da­des de la te­c­no­lo­gía de la in­fo­r­ma­ción moderna.

Son es­pe­cia­l­me­n­te la gestión de grandes volúmenes de datos en el marco de los análisis de big data y el al­ma­ce­na­mie­n­to de datos ab­s­tra­c­tos los factores que saturan la capacidad de los sistemas re­la­cio­na­les. Y es pre­ci­sa­me­n­te aquí donde los sistemas es­pe­cia­li­za­dos, como las BD basadas en objetos o los conceptos de­sa­rro­lla­dos en la senda del mo­vi­mie­n­to NoSQL, muestran su su­pe­rio­ri­dad, si bien no es posible pre­s­ci­n­dir co­m­ple­ta­me­n­te del modelo re­la­cio­nal. Las bases de datos re­la­cio­na­les de­s­plie­gan todo su potencial sobre todo en aquellos ámbitos co­r­po­ra­ti­vos pro­ta­go­ni­za­dos por el pro­ce­sa­mie­n­to de datos de tra­n­sac­cio­nes.

Los datos sobre acciones de los clientes o medidas de marketing pueden re­pre­se­n­tar­se pe­r­fe­c­ta­me­n­te en el formato de tabla, a la par que los usuarios sacan provecho de una sintaxis que, pese a su si­m­pli­ci­dad, permite consultas complejas.

Ir al menú principal