Diseño de una base de datos para un sistema de reclutamiento

¿Quiere aprender a diseñar un sistema de base de datos y mapear un proceso comercial a un modelo de datos? Entonces esta publicación es para ti.

En este artículo, verá cómo diseñar un esquema de base de datos simple para una empresa de reclutamiento. Después de leer este tutorial, podrá comprender cómo se diseñan los esquemas de base de datos para aplicaciones del mundo real.

El proceso comercial del sistema de contratación

Antes de diseñar cualquier base de datos o modelo de datos, es imperativo comprender el proceso comercial básico para ese sistema. El esquema de base de datos que crearemos es para una empresa o equipo de contratación imaginario. Veamos primero los pasos involucrados en la contratación de nuevos empleados:

1. Las empresas se ponen en contacto con las agencias de contratación para contratar en su nombre. En algunos casos, las empresas contratan empleados directamente.
2. La persona responsable del reclutamiento inicia el proceso de reclutamiento. Este proceso puede tener varios pasos, como la selección inicial, una prueba escrita, la primera entrevista, la entrevista de seguimiento, la decisión de contratación real, etc.
3. Una vez que los reclutadores han acordado un proceso en particular, y esto puede cambiar según el cliente, la empresa o el trabajo en cuestión, la vacante se anuncia en varias plataformas.
4. Los solicitantes comienzan a solicitar el trabajo.
5. Los solicitantes son preseleccionados e invitados a una prueba o entrevista inicial.
6. Los candidatos aparecen para la prueba/entrevista.
7. Los reclutadores califican las pruebas. En algunos casos, las pruebas se envían a especialistas para su calificación.
8. Las entrevistas de los solicitantes son calificadas por uno o más reclutadores.
9. Los solicitantes son evaluados sobre la base de pruebas y entrevistas.
10. Se toma la decisión de contratación.

Un esquema de base de datos del sistema de contratación

En vista del proceso mencionado, nuestro esquema de base de datos se divide en cinco áreas temáticas:

• Process
• Jobs
• Application, Applicant, and Documents
• Test and Interviews
• Recruiters and Application Evaluation

Revisaremos cada una de estas áreas en detalle, en el orden en que aparecen. A continuación, puede ver todo el modelo de datos.

Proceso

La categoría de proceso contiene información relacionada con los procesos de contratación. Contiene tres tablas:process , step y process_step . Veremos cada uno.

El process tabla almacena información sobre cada proceso de reclutamiento. Cada proceso tendrá una identificación especial, un código y una description de ese proceso. También tendremos el recruiter_id de la persona que inicia el proceso.

El step La tabla contiene información sobre los pasos seguidos a lo largo de ese proceso de selección. Cada paso tiene un id y un code nombre. La columna de nombre puede tener valores como "evaluación inicial", "prueba escrita", "entrevista de recursos humanos", etc.

Dado que un proceso puede tener varios pasos y un paso puede ser parte de muchos procesos, necesitamos una tabla de búsqueda. El process_step La tabla contiene información sobre cada paso (en step_id ) y el proceso al que pertenece (en process_id ). También tenemos un estado, que nos dice el estado de ese paso en ese proceso; esto puede ser NULL si el paso aún no se ha iniciado. Finalmente, tenemos una priority , que nos dice en qué orden ejecutar los pasos. Los pasos con la priority más alta value se ejecutará primero.

Trabajos

A continuación tenemos los Jobs área temática, que almacena toda la información relacionada con el(los) trabajo(s) para los que estamos reclutando. El esquema para esta categoría se ve así:

Vamos a explicar cada una de las tablas en detalle.

La job_category tabla describe ampliamente el tipo de trabajo. Podríamos esperar ver categorías de trabajo como "TI", "administración", "finanzas", "educación", etc.

El job_position La tabla contiene el título del trabajo real. Dado que se puede anunciar un título para varios trabajos (por ejemplo, "Gerente de TI", "Gerente de ventas"), hemos creado una tabla separada para los puestos de trabajo. Podríamos esperar ver valores como "Líder del equipo de TI", "Vicepresidente" y "Gerente" en esta tabla.

La job_platform tabla se refiere al medio utilizado para anunciar la oferta de trabajo. Por ejemplo, un trabajo podría publicarse en Facebook, una bolsa de trabajo en línea o en un periódico local. Se puede agregar un enlace a esa publicación de trabajo en la description campo.

La organization table almacena información sobre todas las empresas que alguna vez han utilizado esta base de datos como parte de su proceso de contratación. Obviamente, esta tabla es importante cuando el reclutamiento se realiza para otra empresa.

La última tabla en esta área temática, job , contiene la descripción del trabajo real. La mayoría de los atributos se explican por sí mismos. Debemos tener en cuenta que esta tabla tiene muchas claves foráneas, lo que significa que se puede usar para buscar la categoría, el puesto, la plataforma, la organización de contratación y el proceso de contratación relacionado con esa oferta de trabajo.

Solicitud, Solicitante y Documentos

La tercera parte del esquema consta de tablas que almacenan información sobre los solicitantes de empleo, sus solicitudes y cualquier documento que venga con las solicitudes.

La primera tabla, applicant , almacena la información personal de los solicitantes, como su nombre, apellido, correo electrónico, número de teléfono, etc. El campo de resumen se puede utilizar para almacenar un breve perfil del solicitante (es decir, un párrafo).

La siguiente tabla contiene información para cada application , incluyendo su fecha. La tabla también contiene la experience y education columnas Estas columnas podrían ser parte del applicant pero un solicitante puede querer o no mostrar una calificación educativa particular o experiencia laboral en cada solicitud que envíe. Por lo tanto, estas columnas son parte de la application mesa. La other_info La columna almacena cualquier otra información relacionada con la aplicación. En la application En la tabla Jobs_id y Solicitante_id son claves externas de las tablas Job y Solicitante, respectivamente.

Dado que puede haber varias solicitudes para cada trabajo, pero cada solicitud es solo para un trabajo, habrá una relación de uno a muchos entre los jobs y applications mesas. De manera similar, un solicitante puede presentar múltiples solicitudes (es decir, para diferentes trabajos), pero cada solicitud es de un solo participante; hemos implementado otra relación de uno a muchos entre los applicants y applications mesas para manejar esto.

El document table gestiona los documentos justificativos que los solicitantes pueden adjuntar a su solicitud. Estos pueden ser CV, currículos, cartas de referencia, cartas de presentación, etc. Tenga en cuenta que esta tabla tiene una columna binaria denominada documento, que almacenará el archivo en formato binario. Se puede almacenar un enlace al documento en la url campo; la columna de nombre almacena el nombre del documento y last_update significa la versión más reciente cargada por el solicitante. Tenga en cuenta que ambos document y url son anulables; ninguno es obligatorio, y un solicitante puede optar por utilizar uno o ambos métodos para agregar información a su solicitud.

No todas las solicitudes tendrán un documento adjunto. Un documento se puede adjuntar a varias solicitudes y una solicitud puede tener varios documentos de respaldo. Esto significa que existe una relación de muchos a muchos entre la application y document mesas. Para administrar esta relación, la tabla de búsqueda application_document ha sido creado.

Pruebas y Entrevistas

Ahora pasaremos a las tablas que almacenan información sobre las pruebas y entrevistas relacionadas con el proceso de selección.

La test la tabla almacena los detalles de la prueba, incluido su id único , code nombre, su duration en minutos, y el maximum puntaje posible para esa prueba.

Una aplicación se puede asociar con varias pruebas y una prueba se puede asociar con varias aplicaciones. Una vez más, tenemos una tabla de búsqueda para implementar esta relación:application_test . El start_time y end_time las columnas pueden anularse, ya que es posible que una prueba no tenga una duración, hora de inicio o hora de finalización específicas.

Varios reclutadores pueden calificar una prueba y un reclutador puede calificar varias pruebas. Las answers table es la tabla que lo hace posible. Las total_grades La columna registra qué tan bien le fue al candidato en la prueba, y la columna de aprobación simplemente indica si esa persona aprobó o reprobó. Los detalles de cada prueba individual se registran en answer_details columna. Tenga en cuenta que estas tres columnas aceptan valores NULL; se puede asignar una prueba de aplicación a un reclutador que aún no la ha calificado. Además, a un reclutador se le puede asignar una prueba antes de que realmente se tome.

La interview tabla almacena información básica (el start_time , end_time , un id único y el application_id relevante ) para cada entrevista. Una entrevista puede estar asociada con una sola aplicación. Por otro lado, una aplicación puede tener múltiples entrevistas. Por lo tanto, existe una relación de uno a muchos entre la aplicación y la tabla de entrevistas.

Varios revisores pueden realizar una entrevista y un revisor puede realizar varias entrevistas. Es otra relación de muchos a muchos, por lo que hemos creado la tabla de búsqueda interview_note . Almacena información sobre la entrevista (en interview_id ), el reclutador (en recruiter_id ), y las notas del reclutador sobre la entrevista. Los reclutadores también pueden registrar si el solicitante pasó o no la entrevista en la columna de aprobación, que es anulable.

Evaluación y estado de la solicitud de los reclutadores

La última parte de nuestro modelo de reclutamiento almacena información sobre los reclutadores, los estados de las solicitudes y las evaluaciones de las solicitudes.

Los recruiters la tabla almacena el first_name de cada reclutador , last_name y id único número.

La application_evaluation La tabla contiene información sobre las evaluaciones de aplicaciones. Además del application_id y recruiter_id , contiene comentarios del reclutador (en notes ) y la decisión final de contratación, si la hubiere, en hired . Una aplicación puede ser evaluada por múltiples reclutadores y un reclutador puede evaluar múltiples aplicaciones, por lo que tanto el recruiter y la application la tabla tiene una relación de uno a muchos con la application_evaluation mesa.

Una solicitud puede pasar por varias etapas durante el proceso de contratación, p. "no enviada", "en revisión", "esperando decisión", "decisión tomada", etc. Una solicitud tendrá el estado "no_enviada" cuando el usuario haya iniciado una solicitud pero no la haya enviado para que la revisen los reclutadores. Una vez que se envía la solicitud, el estado cambia a "en revisión", y así sucesivamente. El application_status tabla se utiliza para almacenar dicha información.

El application_status_change La tabla se utiliza para mantener un registro de los cambios de estado de todas las solicitudes enviadas. El date_changed La columna almacena la fecha del cambio de estado. Esta tabla puede ser útil si desea analizar el tiempo de procesamiento para cada etapa de diferentes aplicaciones. Además, el estado de cualquier columna en particular se puede recuperar usando el application_id columna de application_status_change mesa.

Un caso de uso de reclutamiento simple

Veamos cómo nuestra base de datos podría ayudar en el proceso de reclutamiento.

Suponga que una empresa le ha asignado la contratación de un administrador de TI con experiencia en programación. Nuestra base de datos puede ayudarnos a contratar a esa persona ejecutando los siguientes pasos:

1. El primer paso es iniciar un nuevo proceso de contratación. Para ello, se introducen datos en el process y steps mesas. Un reclutador puede agregar tantos pasos como necesite.
2. Durante la tarea anterior, el reclutador puede crear un nuevo trabajo e ingresar los detalles en el job , job_category , job_position y organization mesas. Finalmente, se colocará un anuncio de trabajo en una de las plataformas almacenadas en job_platform mesa.
3. A continuación, los solicitantes crearán un perfil enviando sus datos al applicant mesa. Luego, lanzarán una nueva aplicación ingresando más datos en la application mesa.
4. Los solicitantes también pueden adjuntar documentos a sus solicitudes. Estos datos se almacenarán en el document y application_document mesas.
5. Si un usuario quiere postularse para más de un trabajo, repetirá los pasos 3 y 4.
6. Una vez que se envía la solicitud, el estado de la solicitud se establecerá en "enviada" (u otro nombre de estado elegido por el reclutador).
7. El reclutador evaluará la solicitud e ingresará sus comentarios en la application_evaluation mesa. En esta etapa, la columna contratada no contendrá información.
8. Una vez que se recibe una cantidad adecuada de solicitudes, el reclutador ejecutará el siguiente paso que se muestra en el process_step mesa.
9. Si el siguiente paso es administrar algún tipo de prueba, el reclutador creará una prueba agregando datos a la test mesa.
10. Las pruebas creadas en el paso 9 se asignarán a una aplicación en particular. La información que asigna cada prueba a cada aplicación se almacenará en el application_test mesa. Tenga en cuenta que, durante cada etapa, el estado de la aplicación seguirá cambiando. Esto se registrará en el application_status_change mesa.
11. Una vez que el solicitante complete la prueba, el reclutador marcará las calificaciones de cada prueba de solicitud y las ingresará en la answer mesa.
12. Una vez que se realiza la prueba, el siguiente paso del process_step se ejecutará la tabla. Digamos que el siguiente paso es la entrevista.
13. Los datos de la entrevista se ingresarán en la interview mesa. El reclutador ingresará sus comentarios y dirá si la persona pasó la entrevista o no. Esto se almacenará en el interview_note mesa.
14. Si el process contiene más pasos de entrevista y prueba, se ejecutarán hasta que se alcance el último paso.
15. El último paso en el process_step mesa es normalmente la decisión de contratación. Si el solicitante pasa sus pruebas y entrevistas y la empresa decide contratarlo, los datos se ingresan en la columna de contratación de la application_evaluation mesa y la persona es contratada.

¿Qué opina sobre nuestro modelo de datos del sistema de contratación?

En este artículo, vimos cómo crear un esquema de base de datos muy simple para un sistema de reclutamiento. Dividimos el esquema en cuatro categorías y luego explicamos cada una de ellas en detalle. Finalmente, ejecutamos un caso de uso para mostrar que nuestro esquema puede realmente ayudar a reclutar a un empleado.

Los trabajos de diseño de bases de datos están en auge. ¿Quiere agregar a sus habilidades de base de datos? Tanto si es un recién llegado que busca aprender los conceptos básicos de SQL como si es un profesional experimentado que desea diversificarse en Creación de tablas en SQL | Curso Interactivo | Vertabelo Academy" target="_blank">diseño de base de datos, consulte los cursos a su propio ritmo de LearnSQL.com.