Almacenar los datos en ficheros presentaba un inconveniente importante, según iba creciendo la cantidad de campos que manejábamos por registro, nos veíamos obligados a registrar los mismos datos varias veces,  multiplicando las posibilidades de cometer errores y perdiendo calidad en los datos. Las bases de datos relacionales vinieron a solucionar el problema entre la redundancia y la calidad de los datos, creando estructuras de datos relacionadas que evitan la repetición de 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:

  1. Nombre del proveedor
  2. Contacto del proveedor
  3. Teléfono

Ahora pasamos a registrar también los siguientes datos:

  1. Producto que suministra
  2. Precio por unidad

De tal forma que, si antes teníamos un único registro por proveedor, ahora podemos tener varios.

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:

  1. Nombre del proveedor
  2. Contacto del proveedor
  3. Teléfono

Y la otra sería:

  1. Nombre del proveedor
  2. Producto que suministra
  3. 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 “Arquitectura de Datos” que reproduce los apuntes de la clase que imparto sobre el tema en ESIC. Puedes ver el índice de esta colección aquí.