Funcionarios

Empleados

El sistema de gestión de empleados de una empresa.

Guía

Lo que fue desarrollado

El proyecto se desarrolló utilizando ASP.NET para el desarrollo de aplicaciones y SQL Server como una base de datos de almacenamiento. Se realizó un registro de empleados (persona + carga) donde es posible realizar las 4 acciones de los estándares CRUD. Leer, crear, editar y eliminar. Además, también se implementó la opción de recalculación salarial, donde la base de datos hace la relación nuevamente entre persona y oficina, poblando la tabla de persona en la descripción de la prueba.

Cómo ejecutar la aplicación

En los funcionarios/ copia de seguridad/ tiene un archivo de copia de seguridad de SQL Server que utilicé con todos los procedimientos utilizados y los datos ya ingresados. Por lo tanto, solo necesita que una restauración bancaria.

Nota : Después de hacer la restauración, debe cambiar la cadena de conexión presente en la clase de empleados dentro del archivo de empleados.aspx.cs. Cambio por la cadena de conexión de su máquina.

Después de configurar la base de datos, abra la solución a algún editor de código de su elección (utilicé Visual Studio) y ejecute la aplicación.

Procedimientos de almacenamiento

Para facilitar ver los procedimientos utilizados en la aplicación, pongo sus archivos de creación en los empleados/SQLS/.

Objetivos

• Crear la base de datos con datos anteriores
• Crea el proyecto base
• Acumular procedimiento de la población de la tabla Person_salario
• Table de persona popular_salario
• Procedimiento de almacenamiento de la creación de la persona
• Actualización del procedimiento de almacenamiento de la persona
• Procedimiento de exclusión de almacenamiento de la persona
• Procedimiento de almacenamiento para enumerar a personas y salarios
• Procedimiento de almacenamiento de posiciones Listado
• Procedimiento de almacenamiento de la selección de personas
• Página de listado de personas y sellos
• Rutina de creación de personas
• Rutina de actualización de la persona
• Rutina de exclusión de la persona
• Rutina de limpieza de campo
• Aparece la confirmación de la acción
• Calcular/recalcular el salario de rutina

Consideraciones sobre arquitectura

Durante el desarrollo encontré algunas cosas extrañas sobre la arquitectura propuesta. Principalmente en relación con la base de datos.

Se dice en la descripción de la prueba que es crear una tabla llamada Pessoa_Salario que haría la conexión de la tabla de la persona con la posición. Sin embargo, la existencia de esta tabla no es necesaria. Para la necesidad de crear una tabla intermedia solo es necesaria cuando hay una relación de muchos para muchos entre las dos tablas analizadas. Que no es el caso entre persona y oficina. Después de todo, una persona solo puede estar en una posición a la vez, por lo que hay un campo llamado Position_id en persona. Y a partir de esto, la forma única de la tabla de posición ya existe y, en consecuencia, ya es posible acceder a la posición y el salario de esa persona, sin la necesidad de crear una tabla para hacerlo.

La forma en que se describe en la prueba, hay un problema duplicado en el banco. Que además de estar equivocado arquitectónicamente, ya que puede generar inconsistencia en estos datos en algún momento, también se necesitaba una "corrección" de esto en la aplicación que fue la creación del botón de recaluación salarial. Después de todo, si el valor del salario de un interno en el futuro, por ejemplo, cambiara, la tabla de posición tendría el valor actualizado, pero la tabla de venta sanal aún tendría el valor anterior (problema de inconsistencia de datos) y sería necesario ir manualmente en la pantalla del empleado y activar la acción de recalculación salarial. Lo que no debería hacerse si no hubiera una tabla de persona, porque además de tener solo estos datos en un solo lugar, evitando las inconsistencias, la consulta estaría tomando el valor correctamente. Ambos antes de modificar la cantidad salarial y después.

Prueba de esto es analizar las consultas que generan las dos arquitecturas.

Esta es la consulta para devolver todos los datos de persona, carga y persona_salary utilizada en la lista de las propuestas de arquitectura:

 SELECT p . ID , p . Nome as Pessoa, Cidade, Email, CEP, Endereco, Pais, Usuario, Telefone, Data_Nascimento, c . Nome as Cargo, ps . Salario FROM Pessoa as p 
	INNER JOIN Pessoa_Salario as ps on p . ID = ps . Pessoa_ID
	INNER JOIN Cargo as c on p . Cargo_ID = c . ID

Y esto tiene la misma función que la consulta anterior, pero solo involucra a la persona y la oficina y devuelve exactamente los mismos datos de una manera más simple y optimizada:

 SELECT p . ID , p . Nome as Pessoa, Cidade, Email, CEP, Endereco, Pais, Usuario, Telefone, Data_Nascimento, c . Nome as Cargo, c . Salario FROM Pessoa as p 
	INNER JOIN Cargo as c on p . Cargo_ID = c . ID

Nota : Mis propuestas de solución se desarrollaron utilizando la arquitectura propuesta. Este comentario fue solo para mostrar la forma en que lo encontré más interesante y optimizado por la arquitectura.