La base de datos relacional vino a dar respuesta a la necesidad de estructurar la información que se venía manejando en distintos ficheros. La creciente cantidad de datos con los que se trabajaba hacía que cada vez se crearan más ficheros con datos y forzó a encontrar una manera eficiente de estructurar toda esa información.
¿Qué es una base de datos relacional?
En realidad, una base de datos relacional no es otra cosa que un software que nos permite manejar estructuras de datos entre las que se crean relaciones. De esta forma, los datos no están aislados en las distintas estructuras, sino que están relacionados a través de las relaciones que se crean entre partes de estas estructuras.
Las estructuras en una base de datos relacional son las tablas, compuestas de varias columnas y filas. Las columnas representan los atributos de los datos que queremos almacenar, que normalmente denominaremos campos. Y en cada fila registramos un conjunto de valores para los distintos atributos, conformando lo que denominaremos un registro.
En la siguiente figura puede verse una tabla con 5 registros para los atributos: “Categoría”,”Producto”,”Unidades”,”Embase” y “Precio”.
Las relaciones se establecen entre campos de distintas tablas que almacenan la misma información, dándonos la posibilidad de combinar datos de las distintas tablas relacionadas.
Empleando las relaciones entre las tablas en la figura anterior, podríamos extraer la información de quien es el gestor de un determinado producto. Por ejemplo, si tuviéramos un problema con el producto “Detergente” y quisiéramos saber con quien hablar para solucionarlo, empleando la relación entre las dos tablas, veríamos que el gestor para dicho producto es “Juan Perez”.
La aparición de las bases de datos relacionales
Como hemos visto, almacenar los datos en ficheros presentaba un problema grave, según iba creciendo la cantidad de campos que manejábamos por registro, nos veíamos obligados a repetir información, a registrar los mismos datos varias veces. Todo esto, al final llevaba a que se cometieran errores y ocasionaba una pérdida de calidad en los datos.
Veámoslo en el comercio Gades de Antonio:
Hasta este punto, Antonio viene guardando los datos de proveedores en ficheros y como además tiene indexada la información, el tema le funciona relativamente bien. Sin embargo, su negocio sigue creciendo y sus necesidades de información crecen en paralelo. Ahora necesita saber también que productos suministra cada proveedor y a qué precio.
De momento los datos que veníamos registrando de cada proveedor eran muy pocos:
- Nombre del proveedor
- Contacto del proveedor
- Teléfono
Ahora pasamos a registrar también los siguientes datos:
- Producto que suministra
- Precio por unidad
De tal forma que, si antes teníamos un único registro por proveedor, ahora podemos tener varios.
Antes:
Ahora:
Se aprecia fácilmente la cantidad de información que estamos repitiendo de forma redundante, que es precisamente lo que incrementa la probabilidad de cometer un error y lo que finalmente redunda en una pérdida de calidad de los datos. Pongamos, por ejemplo, que hemos cometido un error y la información que hemos registrado es la siguiente:
Resulta complicado localizar el error, este se encuentra en el cuarto registro en el número de teléfono. Para facilitar su localización lo he marcado en rojo.
Bien, si ahora hiciéramos una búsqueda en nuestro fichero de aquellos proveedores que pueden proporcionarnos naranjas, nos saldría Frutas Gutierrez con el teléfono erróneo: 607454445. Nuestro amigo Antonio cogería el teléfono y llamaría a ese número para hacerles un pedido, y probablemente contactaría con un particular, el operador le indicaría que el número no existe o cualquier otra cosa. Lo que es claro es que no conseguiría contactar con el proveedor.
La solución a este problema fue propuesta por Edgard Ted Cood: Estructurar los datos en relaciones que luego combinamos para extraer la información. Los datos que repetimos insistentemente estarían en una estructura y los otros que varían en otra estructura. Es decir, ya no tendríamos todos nuestros datos en un único fichero en una estructura plana, sino en dos estructuras entre las que crearíamos una relación que nos permitiría extraer la información combinada de ambas estructuras.
Codd llamó Tuplas a lo que hemos venido llamando registros y Columnas a lo que hemos llamado campos o atributos.
Para establecer la relación entre estructuras, definimos una clave primaria, una Columna sin duplicados Que identifica unívocamente a la tupla. Esta columna tiene que aparecer en ambas estructuras ya que será a través de la cual se establezca la relación.
Veámoslo en nuestro ejemplo del fichero de proveedores, una primera estructura podría ser nuestra estructura antigua:
- Nombre del proveedor
- Contacto del proveedor
- Teléfono
Y la otra sería:
- Nombre del proveedor
- Producto que suministra
- Precio por unidad
Obsérvese que en la segunda estructura repetimos el dato de nombre de proveedor, este será el dato por el que establezcamos la relación entre ambas estructuras, nuestra clave primaria que no admite duplicados en la estructura de proveedores, pues tiene que identificar unívocamente a cada proveedor.
Al final nos quedarían las siguientes estructuras:
Al buscar ahora los proveedores que suministran naranjas, buscaría en la segunda estructura y utilizando la Columna de la relación, en nuestro caso Nombre del proveedor, recuperaría de la primera estructura los datos de contacto y teléfono.
Hemos evitado la redundancia en los datos de contacto y teléfono, y de esta forma hemos evitado posibles errores.
El modelo de Codd es conocido como modelo relacional, que además incluía otra importante propuesta: Que el diseño de estas estructuras se mantenga independiente de su implementación física. El usuario no tiene que preocuparse de cómo se almacena los datos en el soporte físico, un programa lo hace por él. Este programa es el Gestor de Bases de datos.
NOTA:
Este post es parte de la colección “Sistemas de acceso y almacenamiento de datos”. Puedes ver el índice de esta colección aquí.