Curso de Administracion de Bases de Datos Relacionales: 04 - Tercera forma normal

Hola bastante mas tarde, la tercera forma normal requiere que las tablas estén en 2FN y además que ningún atributo que no sea llave primaria tenga dependencias transitivas hacia cualquier atributo de la tabla.

Con lógica proposicional se busca que ninguna columna dependa de algo que no sea una llave primaria, un ejemplo imaginario sería que en la matricula existiera un aula y un numero de asientos, dentro de una misma matrícula debería guardarse el numero de aula y el numero de asientos, si el aula tiene su tamaño definido, es ilegal que para algunos matriculados el numero de asientos cambie, por que el aula es la misma, pero los datos no estarán actualizados para todos los matriculados, aquí se requiere una tabla que almacene el numero de aula y los asientos de la misma.

Conociendo esto, pasemos a analizar nuestra tabla punto a punto en búsqueda de reiteración de datos y errores de integridad referencial.

• Personas: Hay espacio para el nombre completo de una persona y su fecha de nacimiento, con la fecha podemos calcular la edad, si hubiera un campo para edad sería un error, por que tendríamos que revisar si el campo ha sido actualizado cada vez, es una perdida de tiempo, por eso tenemos la fecha de nacimiento y con ese dato cada vez podemos calcular la edad sin perder disco duro ni procesador.

 

• Estudiantes: DNIPersonas es una llave foránea, es el campo DNI que existe en la tabla personas, entonces se nos garantiza la integridad referencial con ese campo, los créditos del ciclo lectivo se calcularán usando los cursos recien matriculados, los créditos aprobados son sumar los créditos de los cursos que ya estén aprobados, se sumará ese valor al campo, existen una serie de formas para que esto suceda desde el cliente y desde el servidor según haga falta, así que es eficiente y dependiente del DNI, el promedio general es el promedio de todos los créditos cursados, es un calculo grande que conviene hacerlo pocas veces, para un estudiante inactivo o graduado este dato deja de actualizarse, por tanto es mas eficiente tener un campo que calcularlo cada vez

• Profesores: DNIPersonas es llave foránea del DNI, HorasLaboradas será un campo calculado hasta tres veces al año, es mucho mas eficiente conservarlo y con eso analizamos lo mas obvio.

• PersonasConTelefonos/PersonasConCorreos: una tabla pivote asocia dos llaves foráneas, garantizamos integridad referencial asociando de muchos a muchos indirectamente, hay poco mas que comentar.

• Telefonos/Correos/Estado/EstadoDelCurso: tiene una llave primaria y una única columna no llave, respeta hasta la 3FN

• Cursos: tenemos una llave primaria, la sigla del curso, el nombre del curso y los créditos que vale, no hace falta más cambios

• MatriculaDeCursos: IDCursos, DNIEstudiante, DNIProfesor son llaves foráneas, Año, Dia, HoraDeInicio, Grupo y Calificación son elementos informativos tanto para el estudiante, profesor y la universidad, de estos campos el grupo, año, dia y hora de inicio están mal, ninguno respeta la 3FN, se requiere otra tabla intermedia que los contenga para todos los estudiantes matriculados en un grupo, aquí el error es que los datos se repetirán independientemente para todos los matriculados en un mismo curso, causando problemas de integridad referencial y redundancia en 3FN.

Si creamos la tabla intermedia que hace falta para finalizar esta faena interminable, obtenemos por fin la tabla normalizada definitiva, hacemos que el IDCurso sea la llave primaria, se junte con el Grupo, haciendo que tanto el ID del curso como el grupo sean llave primaria de la tercera tabla, GrupoMatriculado, que será el catalogo donde se irán actualizando los cursos impartidos.

Y ahora podemos decir que todas las tablas tienen integridad referencial y atomicidad de 1FN, todos los atributos de las tablas dependen totalmente de su llave primaria de la 2FN y por ultimo, ningún atributo de la tabla depende de otros atributos de si misma, respetando también la 3FN, una vez terminados los asuntos filosóficos del diseño de bases de datos, resta enfrascarnos con los asuntos técnicos del motor de base de datos MySql, en mi caso usaré MariaDB, que es el mismo motor, pero reescrito bajo licencia GPLv3, de todas formas, la idea es aprender SQL bajo sus principios mas generales, por tanto válidos para cualquier motor de bases de datos que cumpla con el estándar ISO/IEC 9075, en este momento llamado SQL2016 y que se estará actualizado en los próximos años.