Conceptos básicos de bases de datos relacionales

Una base de datos, contiene una o más tablas de información. Las filas de una tabla son llamadas registros, y las columnas de una tabla se denominan campos o atributos. Una base de datos que sólo contiene una tabla se llama una base de datos plana. Una base de datos que contiene dos o más tablas relacionadas entre sí, constituye una base de datos relacional. 

Imagina que eres el responsable de un hospital. Podrías utilizar una sola tabla (una base de datos plana) para realizar su seguimiento tal y como se muestra en la siguiente tabla.

Esta tabla  tiene algunos defectos graves en términos de eficiencia, espacio requerido, y tiempo de mantenimiento. Por ejemplo, un enfermo que sea ingresado dos o más veces por diferentes dolencias con dos o más salas o doctores asignados, tendrá que volver a introducir toda su información de contacto para cada doctor, especialidad, habitación o fecha de ingreso.

Por ejemplo, Daniel es ingresado una segunda vez, volver a introducir la información de contacto de Daniel será una pérdida de tiempo, y aumenta la probabilidad de cometer errores. Por otra parte, si fuera necesaria una actualización (por ejemplo, el número de teléfono) se debe hacer en cada lugar donde aparezca, con la consiguiente pérdida de tiempo en buscar y cambiar varias veces el mismo dato, aparte que podemos equivocarnos y poner dos números de teléfono diferentes (uno de ellos erróneo) para la misma persona.

Estos problemas se solventan mediante la normalización, en otras palabras: dividiendo la información en varias tablas con el objetivo de tener "un lugar para cada cosa”. Cada pieza de información debería aparecer sólo una vez, lo que simplifica la actualización de datos y disminuye el espacio de almacenamiento necesario. Por ejemplo podemos dividir los datos personales del paciente en una tabla y las especialidades del hospital en otra.

Ahora que los datos están dispuestos de manera eficiente, necesitamos una manera de mostrar qué registro de la tabla se corresponde con los demás de otras tablas, para ello definimos la clave primaria de la tabla que debe ser un campo que sea único para cada registro de la tabla. De este modo los pacientes y su especialidad se pueden relacionar a través de los diferentes campos clave de cada tabla. Por ejemplo una buena elección de clave para los pacientes es su DNI pues es único para cada persona.

Cuando no existen campos apropiados para ejercer de clave primaria, como es el caso de la tabla de Especialidades, siempre podemos añadir uno como identificador Id.Esp. En este caso y numerarlo desde el 1 sucesivamente. De este modo, resulta sencillo determinar qué valor del campo Id.Esp. Identifica de forma exclusiva los registros en esta tabla. También podemos utilizar este campo para relacionarlo con otros de otras tablas.

Para aumentar la eficiencia, y la reducción de espacio al mismo tiempo que  mejoramos la facilidad de mantenimiento, podemos separar en su propia tabla, la información de las fechas de ingreso y especialidad por la que ingresa cada paciente.

Por ejemplo, en la imagen inferior se puede ver la misma información contenida en la primera tabla pero en una tabla mucho más pequeña llamada Ingresos y apoyada por dos tablas auxiliares de Pacientes y Especialidades que se relacionan con la tabla de Ingresos a través de sus claves primarias.

En este caso la información de las tablas de Pacientes y Especialidades ya no es redundante, y no es necesario actualizarla mientras no haya cambios en los datos de los pacientes. Esto nos permite escribir una tercera tabla de Ingresos con la información relativa a las entradas y salidas de los pacientes en el hospital y relacionarla con la especialidad por la que fueron ingresados; de este modo, las fechas de ingreso y alta de cada paciente, son independientes del resto de datos y se relacionan con ellos, a través de las claves primarias. Así por ejemplo, se puede observar, que el paciente Pedro Rodríguez con DNI 56464555, produjo dos ingresos en la especialidad de Urología con Id. Esp. 003 de este modo, en la tabla Ingresos, sólo hay generar una fila adicional con la información relevante de las fechas y relacionarla con los identificadores correspondientes, evitando tener que repetir todos los datos de Pedro Rodríguez en cada ingreso. También se puede observar que el paciente Daniel Alonso DNI 76576567 produjo dos ingresos en dos especialidades distintas.

Cuando dos tablas tienen una relación desigual, la tabla que depende de otra se llama tabla hija y la tabla de la que depende se llama tabla padre. Se puede identificar la tabla primaria o padre que es la que contiene registros sin necesidad de poseer un registro correspondiente en la tabla hija.  Por ejemplo, es posible tener una especialidad (Oncología 006)  para la que no existe contrapartida en la tabla de Ingresos. Entonces decimos que la tabla de Especialidades es padre y la tabla de Ingresos es hija. En caso de que todas las especialidades tuvieran su contrapartida, podemos detectar la tabla padre, porque no podemos eliminar de ella un registro sin antes eliminar su correspondiente de la tabla hija (Ingresos); mientras que en la tabla hija podemos eliminar cualquier registro, sin que sea necesario eliminarlo de la tabla padre.

Si de alguna manera la tabla secundaria contuviera un registro que no tiene contrapartida en su registro correspondiente registro de la tabla padre, ese registro se llama huérfano. Los registros huérfanos son un problema que por lo general requiere atención por parte del administrador de la base de datos.

Otra forma de identificar la tabla secundaria o hija, es encontrar el campo que se refiere a un identificador ID de otra tabla. En la tabla Ingresos el campo Id. Esp. Apunta a la tabla padre. Mientras que la tabla Especialidades no tiene ningún campo Id. Esp.  Aparte de su clave primaria.

Otro concepto a considerar es la cardinalidad, que describe el número de registros en una tabla que puede estar relacionado con los registros de otra tabla. Dos tablas pueden tener una cardinalidad de 1-1 (uno a uno), 1-∞ (Uno a varios), 1-3 (uno a tres), ∞ - ∞ (varios a varios), etc. 

La relación en la tabla Ingresos es 1 a varios pues un paciente puede ingresar muchas veces, del mismo modo la relación de especialidades es uno a varios pues un paciente puede ingresar por varias especialidades.

A continuación, se muestra un ejemplo para cada tipo de cardinalidad.

Relación 1 a 1

Por cada registro de la tabla principal (tabla que contiene la clave principal) puede existir un sólo registro en la tabla relacionada. En nuestro ejemplo podemos añadir una tabla de directores de especialidad en la que sólo un médico puede ser director de un área de especialidad esta relación quedaría como la mostrada en la figura es una relación en la que cada especialidad sólo tiene un director y cada director sólo tiene una especialidad.

Relación 1 a varios

Por cada registro de la tabla principal (lado 1 de la relación) pueden existir muchos (infinitos) registros en la tabla relacionada (lado varios de la relación). La tabla relacionada no puede contener un registro que no esté relacionado con uno de la tabla principal, pero puede haber muchos registros que estén relacionados con el mismo registro de la tabla principal.

Ya se ha explicado antes, por ejemplo un paciente puede ser ingresado varias veces. En este caso el paciente es el lado 1 y las veces que ingresa, representa  el lado de varios.

Relación varios a varios

Se establece cuando hay tres tablas relacionadas entre sí con una relación de uno a varios, en este caso la relación entre las tablas de los extremos es de varios a varios. Es necesaria una tabla de unión entre ambas para que se produzca la relación varios a varios. 

En nuestro ejemplo añadimos una nueva tabla de habitaciones del hospital en la que se ingresan los pacientes, cada paciente tiene asignada una habitación y una especialidad, pero como puede ingresar varias veces, puede hacerlo en diferentes habitaciones y diferentes especialidades, de este modo las especialidades se relacionan con las habitaciones en modo varios-varios pues cada especialidad puede tener varios pacientes ingresados en varias habitaciones. Esto se representa en la figura de abajo. 

Si realmente estuviéramos diseñando el modelo de datos (tablas, campos, relaciones, etc.) para un hospital, continuaríamos separando aún más los datos (como los médicos, pacientes, habitaciones, especialidades) en otras tablas hasta que el modelo sea tan eficiente como sea posible.