Relación y cardinalidad entre tablas

Para recapitular, si lo necesitas, en el artículo anterior revisamos identificar la clave primaria de una tabla, que hace referencia al paso N° 3 de 5 en nuestro proceso de diseño de una base de datos desde cero.

Hemos organizado datos sueltos en tablas independientes, a esas tablas las hemos analizado para descubrir que campo las hace únicas, ahora estamos listos para conocer cómo se relacionan y su cardinalidad, en este paso justificaremos si la asignación de los datos en las tablas han sido eficientes o si tenemos que hacer ajustes al modelo.

¿A qué se refiere relación entre tablas?

Cada tabla tiene su razón de ser, pero eso no significa que estén aisladas en la base de datos, como expliqué en el primer artículo, los datos son generados por procesos en común (no se crean de la nada), entonces siempre tienen relación, veamos un ejemplo:

Diagrama de proceso que explica cómo se relacionan las tablas: ventas, proveedor, compras y stock

¿A qué se refiere cardinalidad entre tablas?

Simplificado, es el número de veces a nivel de registro en que una tabla se relaciona con otra, es de mucha importancia para asignar un espacio ideal de campos a aquellas tablas que tendrán mayor transacción y descubrir cuando hace falta crear tablas intermedias.

RELACIÓN.

La lógica impera en este proceso, veamos que tenemos actualmente:

Esto se representaría así:

Como observas, nada se ha quedado fuera, todo está relacionado directa o indirectamente; sin embargo, la relación así no dice mucho sobre ¿cómo viajan los datos entre las tablas?, para eso vamos a analizar la cardinalidad.

CARDINALIDAD.

Pueden ser de tres tipos.

• UNO a UNO, cuando para cada registro de la tabla A tiene solo un registro en la tabla B, se representa como (1:1)

• UNO a MUCHOS, cuando para cada registro de la tabla A tiene más de un registro en la tabla B, se representa como (1:N)

• MUCHOS a MUCHOS, cuando varios registros de la tabla A tienen varios registros en la tabla B, se representa como (M:N)

Ejemplo de una relación de uno a uno:

Relación (1:1), cada colaborador en una empresa tiene su propio carnet de acceso único

Ejemplo de una relación de uno a muchos:

Relación (1:N), cada colaborador en una emrpesa puede marcar muchas veces (entrada a la empresa, salida lunch, regreso lunch, salida empresa)

Ejemplo de una relación de muchos a muchos:

Relación (M:N), muchos colaboradores pueden recibir muchas capacitaciones (todo el departamento de sistemas y rrhh van a recibir capacitación en excel, project y visio)

Consideraciones:

• No es común tener relaciones (1:1), pero si tienes de esas, analízalas a profundidad a ver si es estrictamente necesario mantenerlas, por ejemplo en el caso que propuse ¿que pasa si la empresa se fusiona con otra?, la tabla de acceso al sistema no valida la empresa del colaborador porque asume que siempre existirá una sola empresa.

• Cuando tengas relaciones (M:N), debes crear una tabla intermedia que las relacione porque no se puede manejar directamente este tipo de relaciones a nivel técnico, por eso es importante revisar las relaciones y cardinalidad, para identificar estos casos y gestionarlos a tiempo.

¿Cómo creo una tabla intermedia en una relación (M:N)?

Siguiendo el ejemplo, la manera adecuada de crear una tabla intermedia es hacer que se relacionen las claves primarias de las otras tablas mediante claves foráneas [es indispensable que leas este artículo], cuando hacemos esto nos permite estructurar mejor las tablas; en nuestro caso en la tabla de capacitaciones agregamos algunos datos propios del tema que antes obviamos, como son: el contenido, los requisitos y la descripción general de la capacitación y, por otro lado le derivamos los campos de fecha, hora y el cupo a una tabla intermedia que se llama sesiones, planteo un caso:

Veamos la utilidad de la tabla intermedia sesiones, dos cursos se dictarán y están inscritos muchos colaboradores, de los cuales te he resaltado en color los que se han inscrito en más de un curso y hasta en la misma fecha, por ejemplo el colaborador 0925080912 que está en el curso A001 y X1W99 ambos el 15/11/2018 pero en diferente hora de asistencia.

Por último, te adjunto los diferentes tipos de conectores que existen:

Véase Crow’s Foot Notation.

Con esto concluimos el paso 4 de 5 del diseño de una base de datos relacional, ahora nos compete realizar la normalización de la base de datos, lo revisamos en el siguiente articulo, no te lo pierdas!. [ ir al siguiente artículo ]

#basededatos