Cómo realizar el diseño de bases de datos relacionales
Una de las ventajas que nos aportan las bases de datos relacionales es la posibilidad de contar con un diseño robusto y estructurado de manera organizada.
Este tipo de bases de datos se caracteriza por el ahorro de espacio de almacenamiento a cambio de un pequeño costo de velocidad de respuesta, que en bases de datos normales apenas seremos capaces de notar.
Si vamos a trabajar con bases de datos muy grandes donde interese más la velocidad que el espacio de almacenamiento y el diseño estructurado, entonces debes pensar en las bases de datos no relacionales.
Pero en el artículo de hoy hablaremos de diseño de bases de datos relacionales, y te mostraremos todas las herramientas necesarias para que llegues a un diseño óptimo y puedas ahorrar en almacenamiento y ganar integridad en tus datos al quedar sin información redundante.
Sin más, comenzamos.
Normalización
Para el diseño de bases de datos relacionales existe un conjunto de aspectos bien definidos que deben cumplirse como buenas prácticas.
A este proceso se le denomina Normalización y tiene como objetivo evitar anomalías y la redundancia mediante la centralización de los datos, logrando bases de datos más naturales y limpias.
Este proceso cuenta con varios niveles que definiremos a continuación.
Primera Forma Normal (1FN):
Este primer nivel tiene como objetivo garantizar la atomicidad de los datos.
Para normalizar a este nivel debemos cumplir las siguientes indicaciones:
- En cada tabla están bien definidos los atributos que funcionan como llave primaria.
- Todos los datos de la fila deben estar identificados por su llave.
- Todos los atributos deben ser atómicos.
- Debe existir independencia en el orden tanto de tablas como de columnas.
- No hay grupos repetidos en la tabla. Cada celda debe contener un solo valor, no un conjunto de ellos.
Resumiendo, debes identificar los id por tabla y dividir las columnas que puedan contener datos compuestos en una relación con una nueva tabla que separe los datos en varios atributos.
Por ejemplo, supongamos que tenemos una tabla Estudiante en donde se almacenan sus datos personales, incluyendo las asignaturas que cursa:
Tenemos la llave de acceso a cada fila representada a través su atributo id, pero el campo asignaturas no es atómico.
Para llevar esta base de datos a la 1FN es necesario crear una nueva tabla para almacenar las asignaturas con la referencia al respectivo estudiante:
De este modo eliminamos la columna asignaturas de la tabla estudiante y logramos la atomicidad en nuestro diseño de bases de datos.
Pero en este caso nos surge el problema de la redundancia de la información al repetir las asignaturas por cada estudiante que la cursa, por lo que debemos sacar una tabla intermedia para convertir la relación a Muchos a Muchos. Finalmente quedaría de este modo:
Estudiante:
Asignatura:
Estudiante – Asignatura:
De este modo cada uno de los atributos es atómico y no hay grupos repetidos en la tabla, por lo que cumplimos con la Primera Forma Normal.
Segunda Forma Normal
Para que una relación esté en Segunda Forma Normal debe cumplir con todos los requisitos de la Primera Forma Normal y no contar con dependencias parciales, es decir, todos sus atributos deben depender únicamente de su llave primaria.
Una relación se encuentra en Segunda Forma Normal si cumples con los requisitos de la Primera Forma Normal y tienes una llave primaria simple, como en el caso anterior.
Si tienes una llave primaria compuesta, entonces cada atributo debe depender de todos los atributos que componen la llave.
Para poner un ejemplo similar al anterior, supongamos que tenemos la siguiente tabla, donde el existe una llave primaria compuesta por id_estudiante e id_asignatura, y el atributo curso de pende solamente de id_estudiante, por lo que no se encuentra en 2FN.
Para resolver este problema debemos crear una nueva tabla que relacione curso con id_estudiante, y dejar solamente en nuestra tabla inicial los atributos que dependen de la totalidad de la llave primaria.
Tercera Forma Normal (3FN)
Para cumplir con los requisitos de este paso nuestro diseño de bases de datos, debemos estar en la Segunda Forma Normal y no podemos tener dependencias funcionales transitivas.
Dicho en otras palabras, todos los atributos que no forman parte de la llave primaria deben depender únicamente de la llave primaria.
Si se nos da este caso, debemos mover los campos dependientes hacia una nueva tabla y referenciarlos mediante llave foránea.
Supongamos por ejemplo que a cada estudiante se le entrega un bono de biblioteca y se quiere llevar el control de la cantidad de estudiantes asignados a cada biblioteca.
En este caso, el atributo no_estudiantes no depende del identificador de la tabla Estudiantes, sino de no_biblioteca, que no forma parte de la llave, por lo que existe una dependencia funcional transitiva que debemos eliminar.
Forma Normal de Boyce – Codd (FNBC)
La forma normal de Boyce-Codd requiere que en nuestro diseño de bases de datos no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata.
Veamos un ejemplo.
Para que esta tabla cumpla con la Forma Normal de Boyce Codd debemos analizar las relaciones entre los atributos para determinar la llave candidata. Entonces:
Un Estudiante puede cursar varias asignaturas y a su vez tener varios profesores.
Un profesor imparte una única asignatura
Una asignatura tiene un profesor y varios estudiantes
Por tanto:
Estudiante y asignatura determinan al profesor
Profesor determina la asignatura
De este modo, nos enfocamos en la relación entre Profesor y Asignatura sacándola a una nueva tabla:
Y relacionamos estudiante con profesor, de modo que desde cualquier estudiante podemos acceder a la asignatura pasando por el profesor.
Y como resultado nuestro diseño de bases de datos ya cumple con la Forma Normal de Boyce Codd
Cuarta Forma Normal
Esta forma normal tiene como objetivo que las dependencias multivaluadas independientes estén correctas y eficientemente representadas en un diseño de base de datos relacionales.
Una tabla está en Cuarta Forma Normal si cumple los principios de la Tercera Forma Normal o la FNBC y no posee dependencias multivaluadas no triviales.
Una tabla con dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a muchos causa redundancia.
Veamos un ejemplo:
En este caso, un estudiante puede cursar varias asignaturas en aulas diferentes. Si queremos agregar un nuevo estudiante tenemos que agregar una tupla por cada asignatura y cada aula donde cursa esa asignatura.
La Cuarta Forma Normal se encarga de eliminar esta redundancia del diseño de bases de datos, separando las relaciones de este modo:
Como puedes observar, se elimina la redundancia por permutaciones entre las 2 relaciones que se involucraban en la misma tabla, reduciendo el número de tuplas.
Quinta Forma Normal (5FN)
Una relación se encuentra en Quinta Forma Normal, si se encuentra en 4FN y las únicas dependencias que existen son las denominadas dependencias de unión de una tabla con sus proyecciones, relacionándose entre sí mediante la clave primaria, o cualquier clave alternativa.
Se dice que hay dependencia de unión entre una tabla y sus proyecciones, si es posible obtener la tabla original por medio de la unión de dichas proyecciones.
Lo explicamos mediante un ejemplo:
Primeramente, debemos sacar las proyecciones de la tabla:
| Estudiante | Asignatura |
| Andres | Matematica |
| Andres | Fisica |
| Jessica | Matematica |
| Julio | Quimica |
| Fito | Matematica |
| Jessica | Quimica |
| Estudiante | Aula |
| Andres | 1 |
| Andres | 2 |
| Jessica | 1 |
| Julio | 3 |
| Fito | 2 |
| Jessica | 3 |
| Asignatura | Aula |
| Matematica | 1 |
| Fisica | 2 |
| Quimica | 3 |
| Matematica | 2 |
Debemos hacer ahora la unión entre las 2 primeras tablas, nos quedaría:
| Estudiante | Asignatura | Aula |
| Andres | Matematica | 1 |
| Andres | Matematica | 2 |
| Andres | Fisica | 1 |
| Andres | Fisica | 2 |
| Jessica | Matematica | 1 |
| Jessica | Matematica | 3 |
| Julio | Quimica | 3 |
| Fito | Matematica | 2 |
| Jessica | Quimica | 1 |
| Jessica | Quimica | 3 |
Verificamos si todos los valores de la tercera proyección están en la unión de las 2 primeras. En nuestro ejemplo podemos encontrar todos los valores.
En estos momentos verificamos la tabla resultante de la unión entre las proyecciones, y si obtenemos la tabla original no cumplimos con la Quinta Forma Normal y debemos descomponerla en sus proyecciones.
En nuestro caso, no pudimos restaurar las relaciones originales mediante la unión, por lo que nos encontramos en la Quinta Forma Normal.
Diagrama Entidad – Relación
El diagrama más utilizado para representar el diseño de bases de datos es el Entidad – Relación.
En este diagrama se representan como entidades los conceptos que serán representados como tablas en la base de datos, con sus respectivos atributos y sus relaciones entre ellos.
Estas relaciones tienen una cardinalidad que pueden ser:
Uno a Uno: Un registro de una entidad A se relaciona con solo un registro en una entidad B.
Uno a Muchos: Un registro de una entidad A se relaciona con varios registros en una entidad B.
Muchos a muchos: Un registro de la entidad A se puede relacionar con varios de la entidad B y viceversa.
Herramientas de diseño
Existen una gran variedad herramientas que facilitan enormemente la creación de este tipo de diagramas.
A continuación, te presento algunos que pudieras comenzar a probar:
Conclusiones
- El diseño de bases de datos es un proceso de alta complejidad.
- Una base de datos mal diseñada se vuelve ineficiente y muy difícil de mantener en el tiempo.
- Debemos aplicar la normalización para lograr bases de datos con integridad y sin redundancia.
- En la actualidad, la mayoría de las bases de datos llevan el proceso de normalización hasta la Tercera Forma Normal.
- El diagrama entidad relación es el que se utiliza generalmente por los especialistas en bases de datos para comunicarse y documentar su trabajo.
- Existen muchas herramientas gratuitas que permiten crear diagramas entidad relación de forma sencilla.
Con esto terminamos por hoy, pero si te sientes con fuerzas para seguir investigando después de todos estos conceptos de normalización te recomiendo que visites nuestro artículo sobre mantenimiento de bases de datos.
