¿Estoy violando alguna regla NF en el diseño de mi base de datos?


8

Soy un novato en la creación de bases de datos ... Necesito crearlo para mi aplicación web de reclutamiento.

Mi solicitud necesita programar evaluaciones, exámenes y entrevistas de los solicitantes y guardar el resultado en la base de datos.

El esquema de mi base de datos es el siguiente:

ingrese la descripción de la imagen aquí

Mi problema es que incluí applicant_iden otras tablas ... por ejemplo, examen, entrevista, tipo de examen.

¿Estoy violando alguna regla de normalización? Si lo hago, ¿qué me recomiendan para mejorar mi diseño?


1
No creo que nadie sin un conocimiento específico del dominio empresarial / empresa pueda simplemente mirar su modelo de datos y darle consejos realistas sobre claves, restricciones, tipos de datos, etc. Sin embargo, puedo decirle que cualquier columna anulable violará Una interpretación estricta de 1NF.
cuando el

Respuestas:


10

Hay pocas cosas a considerar aparte de la normalización. Por ejemplo, tiene una columna para EDAD. ¿Vas a actualizar eso cada año? ¿Cómo sabrá cuándo hacer eso? Lo mismo ocurre con años de experiencia.

Hay algunas columnas que probablemente tendrán múltiples valores para cada solicitante: escuela, curso, etc.

También es posible que desee verificar su opcionalidad en esas relaciones. En este momento, un solicitante debe tener un examen relacionado, pero un examen no tiene que tener un solicitante asociado. Supongo que eso es al revés de cómo funcionan las cosas en la vida real. Tienes problemas similares con todas las demás relaciones.

Ayuda si lee las relaciones después de crearlas.


1
Hay pocas cosas que considerar aparte de las tablas y columnas :) Mi país tiene leyes de protección de datos (límite de tiempo en la retención de datos, la persona tiene derecho de acceso a sus datos, etc.) y leyes de discriminación por edad que deberían hacer que los empleadores al menos lo piensen dos veces antes de registrar la edad de alguien en la etapa de entrevista.
cuando el

5

Supongo que realmente necesita una relación de muchos a muchos entre su tabla de Solicitante y las otras tablas principales (Principalmente Screening and Exam). Eso si tuviera una evaluación que contenga más de un solicitante (y la situación similar para las otras tablas).

Vería una entrevista con un solo candidato, pero un examen o sesión de evaluación con más de un candidato. En este caso, necesitará una tabla de relaciones que vinculará la evaluación con el solicitante.

Vea aquí sobre las relaciones de muchos a muchos.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.