Segunda forma normal

Este artículo es una continuación de normalización de base de datos, que hace referencia al paso N° 5 de 5 en nuestro proceso de diseño de una base de datos desde cero.

** Segunda forma normal = 2FN.

Se dice que una tabla está en la 2FN cuando cumple estas reglas:

1. Cumple todas las reglas de la 1FN.

2. Todos los campos que no son clave, dependen funcionalmente de la clave primaria (en claves compuestas por varios campos).

3. Si una tabla tiene sólo un campo para clave primaria, entonces pasa a estar en 2FN automáticamente.

¿De qué se trata la dependencia funcional?

La premisa dice que un campo depende funcionalmente de otro cuando para cada valor del campo [A] le corresponde un único valor del campo [B] en la misma tabla, veamos:

Supongamos que tenemos una tabla [empleados], cada empleado tiene una cédula, varios empleados pueden tener el mismo nombre y apellido pero no la misma cédula; entonces el campo cédula [A] determina al campo nombre del empleado [B].

También suele presentarse como un campo derivado, esto indica que un campo no puede existir por si solo, porque depende de otro para tener sentido o existir, veamos un ejemplo tradicional:

La forma adecuada de hallar la edad en años de una persona es a través de un cálculo:

año actual [A] - año de nacimiento [B] = edad [C]

Como [A] es un valor público y siempre está disponible para su uso; el único valor del cual dependemos para hallar [C], es la variable [B]. Entonces, estas expresiones son correctas:

• [C] depende funcionalmente de [B].

• [B] determina a [C].

Otro ejemplo sería el campo {combustión}, que depende funcionalmente de una clave compuesta por los campos {calor + oxigeno + combustible}.

La segunda forma normal elimina las relaciones parciales, quedándose sólo con relaciones funcionales entre sus campos. Las relaciones parciales sólo pueden presentarse en aquellas tablas que su clave primaria esta compuesta por varios campos, en nuestro caso la única tabla que tiene más de un campo como clave es:

Para identificar quien depende o no del campo clave, tenemos que hacernos la siguiente pregunta por cada campo: ¿el campo N puede existir sin el campo clave? y te recomiendo que agregues el por qué, para que tu o el equipo se aseguren que tiene sentido la respuesta.

1. Hacer la pregunta, ¿el campo N puede existir sin el campo clave?

2. Crear las tablas correspondientes con los campos cuya respuesta fue: SI

Explicación de las tabla y campos:

• Reserva de citas: las mascotas para ser atendidas primero deben realizar una cita o reserva; la cual tiene fecha y hora que se va a atender a la mascota. Aquí depende funcionalmente la fecha y hora de la cita.

• Inventario: es la tabla tipo catálogo, donde estarán los productos que se pueden usar. Aquí depende funcionalmente el item de su código de item registrado.

• Ítem aplicados: es una tabla de relación donde se registrarán los items aplicados por cada cita, ya no existe el limite de uso de 7 items que teníamos hasta la 1FN, ahora podemos aplicar N items.

• Personal asignado a citas: una tabla intermedia que relaciona a las citas con los colaboradores, recordemos que más de un doctor o asistente puede ser asignado, dependiendo de la complejidad del caso clínico.

3. Aplicar relación y cardinalidad sobre el modelo

Puedes observar que el modelo se ha compactado, esto se debe a que con las nuevas tablas resultaron redundantes otras tablas y campos, te comento por qué:

[atención de casos] pasó a: [reserva de citas]

La clave primaria compuesta (mascota + fecha + hora) se cambió por el código de la cita, entonces, los campos fecha y hora dejaron de ser parte de la clave primaria, otro punto es que los colaboradores ya no forman parte de esta tabla porque creaban duplicidad, entonces pasaron a ser manejados en una tabla intermedia [personal asignado a citas] y se añadió un campo estado para conocer si la mascota asistió o faltó a su cita, como sucede en la práctica laboral.

[ficha clínica de mascotas] pasó a: [consultas medicas]

Era una tabla grande debido a que cada vez que en una atención alguna mascota usaba más items de los previstos, debía crearse nuevas columnas, al momento lo máximo que habían consumido eran 7 items por consulta; esta mala practica se corrigió con la 2FN, que nos ayudó a identificar que con una tabla inventario debíamos manejar el uso de items. El campo observación se mantuvo en la tabla y se agregaron otros campos interesantes como la receta medica y la fecha de la próxima cita.

Se mantienen sin cambios las tablas, relaciones y campos restantes.

¿Qué sigue?, hay que evaluar las dependencias transitivas. [ir a siguiente artículo]

#basededatos