T3BasesDeDatos

 Este junto con el sp de simular día operación son los más grandes. En este sp se debe de procesar las asistencias de los empleados en cada una de las fechas. Para esto se registran los movimientos de horas normales, horas extras y horas extras dobles, dependiendo de la fecha de operación, de la hora de entrada y de la hora de salida. De igual forma se calcula el pago que recibe el empleado en función de su puesto y de la cantidad y tipo de horas trabajadas.  En este sp al igual que en el de simular día operación, se trabajan con tablas temporales para hacer los cálculos. 

  Se empezó el desarrollo de la app de administrador, esto en capa lógica en paralelo se trabaja la capa de presentación, hasta este momento se puede obtener la lista de los empleados y filtrar

  Se desarrollo la vista correspondiente, en la appLogin, esto en capa lógica. Se configuraron las URLs de Django correctamente para que la página que se muestre inicialmente sea, naturalmente, la del Login.  En esta vista se llama al SP de validarUsuario.

Se continuó con los restantes SPs para el CRUD de empleados, los cuales eran CU, crear una nueva entidad no era un proceso trivial precisamente, pues un nuevo empleado debía asociarse con las deducciones obligatorias, todo debía quedar en la bitácora y se estaba modificando la tabla a la que consulta constantemente la interfaz principal de la app de administrador. No obstante no hubo demasiados contratiempos.

 Con la corrección del XML para simulación se inicia el desarrollo de los sp requeridos. Se empieza con el desarrollo del spSimularDiaOperacion.  * En este sp se define si la fecha de operación es jueves o no y en función de esto realiza ciertas acciones - Inserta nuevos empleados o los deja en una tabla temporal hasta que sea jueves - Se eliminan empleado -Se asocian y desasocian deducciones -Se llama a spProcesarAsistencias para manejar los movimientos de cada empleado -Se ejecuta la apertura y cierre de semana dependiendo del dia - Se ejecuta apertura de mes dependiendo del dia Los datos del XML para una fecha de operación se insertan en tablas temporales para no afectar las tablas fijas de la base de datos. El desarrollo de esta sección es rápida debido a que se sigue el diseño planteado anteriormente

 Ante las consultas del XML, Arturo envía una versión corregida del archivo. Al revisarla en esta también se encontraron unos posibles problemas con la asignación de deducciones, por lo que se le informa de esto

 Se desarrollaron los SPs para los procesos de consultar empleados y eliminar un empleado particular No hubieron contratiempos en este desarollo

  Este se encarga de validar las credenciales del usuario que está intentando ingresar. Lo que retorna este SP es muy importante para el manejo de las paginas como administrador o como empleado. Retorna:

 Mientras se espera la corrección del archivo XML para la simulación, se trabaja en el sp encargado de llenar las tablas catálogo. Para hacer la carga de los datos, los diferentes nodos del xml son guardados en tablas temporales para posteriormente ingresarlo en la tabla fijas de la base de datos. Esta parte del desarrollo fue más rápida, pues seguía el mismo principio de carga de datos que la tarea #2 del curso. 

 Mientras se revisa nuevamente el XML de la simulación, se encuentra otro posible problema, por lo que s ele escribe a Arturo informándole de esto: Arturo responde que también revisará esta sección. Se espera la corrección del archivo para comprobar si los sp diseñados funcionarían con los datos del archivo

Aún se espera la respuesta sobre el XML de simulación, por lo que se sigue con otras secciones del proyecto.  Para la parte del empleado se debe de hacer consultas sobre las semanas y meses, información del salario y de las deducciones. Por esto se diseñan varios sp:

 Después del diseño de los sp para la simulación se empieza revisar la lógica de los mismos comparándolos con los datos dados en el XML. Sin embargo, se encuentran algunos problemas con este archivo y el orden de las operaciones. Por esta razón se le escribe a Arturo para hacer la consulta Ante esto Arturo responde que revisará los archivos. 

 Para poder hacer la simulación se creó un sp, que se encarga de agregar, eliminar usuario, asignar deducciones y otros cuatro sp auxiliares que se encargan de manejar las jornadas, abrir una semana, cerrar una semana y abrir un nuevo mes. Esta sección del diseño fue la que tomó más tiempo por la complejidad de la misma y las diferentes tareas que se tenían que hacer El diseño de estos sp es el siguiente: El resto puede consultarse en:https://lucid.app/lucidchart/37fd964d-b314-45c0-8cac-4121c1af600e/edit?page=0_0&invitationId=inv_896ac8ef-6b8a-42a9-8091-c241e9f2d2f6# 

 Siguiendo con el diseño de los sp para la aplicación. En esta ocasión se continúa con el diseño del sp para el manejo del login. En este sp se valida la existencia del usuario y contraseña ingresados por el usuario y dependiendo de si este usuario está dentro de la tabla de administradores o no se le redirige a la página de empleados o de administradores. El flujo de trabajo de este sp se puede entender por medio de la siguiente imagen: Para la siguiente sesión de trabajo se desarrollarán los sp correspondientes a la simualcion.  Para ver el diagrama completo: https://lucid.app/lucidchart/37fd964d-b314-45c0-8cac-4121c1af600e/edit?page=0_0&invitationId=inv_896ac8ef-6b8a-42a9-8091-c241e9f2d2f6#

 Para facilitar el desarrollo de la aplicación se decidió hacer el diseño previo de los sp que se van a requerir para el funcionamiento del proyecto. Estos sp fueron diseñados en LucidChart y en estos se incluye el flujo de trabajo de los sp y las tablas a las que debe de consultar o modificar.  El diseño de estos sp es el siguiente y corresponde a los requerimientos solicitados en la tarea para la página de administradores la intención de diseñar la lógica de la aplicación antes de empezar el desarrollo de la misma es tener un mejor entendimiento de cada una de las partes del proyecto y que su implementación sea más rápida y eficiente. Se puede acceder al LucidChart por medio de: https://lucid.app/lucidchart/37fd964d-b314-45c0-8cac-4121c1af600e/edit?page=0_0&invitationId=inv_896ac8ef-6b8a-42a9-8091-c241e9f2d2f6#

 Para poder entender adecuadamente los requerimientos, funcionalidades y simulaciones que se deben de hacer en la tarea se realiza una lectura exhaustiva del documento publicado por el profesor. En este se intentan identificar cuáles son las tablas que se deben de crear en la base de datos y cuáles sp se deben de desarrollar para cumplir con lo solicitado.  Se toma nota de: * El uso de triggers cuando se ingresan un empleado * El uso de una vista para realizar una consulta * Posibles tablas que se deben de crear *La estructura del XML de simulación

 Se crea la interfaz de usuario correspondiente a la sección del login. Además de esto, se configuran el resto de archivos de django para poder conectar las diferentes aplicaciones y mostrar las interfaces de usuario La configuración de las aplicaciones se hace por medio del archivo settings.py generado automáticamente por Django y las aplicaciones se comunican por medio de este codigo: Este es el desarrollo solo de la interfaz de usuario, aún no se ha agregado lógica a esta parte

 Se crean las apps que conforman el proyecto de Django, estas corresponden al Login, al manejo del administrador y al de empleados, para la creación de estas aplicaciones se consulta el siguiente video: https://www.youtube.com/watch?v=T1intZyhXDU&t=1956s&ab_channel=Fazt  En cada una de estas apps se van a crear la interfaz gráfica  y parte de la lógica correspondiente a la aplicación web. 

 Se crea una cuenta en GearHost, donde se va a alojar la base de datos en la nube. 

  Se crea el repositorio de GitHub en el que se subirán todas las actualizaciones realizadas a la tarea y al desarrollo de los requerimientos de la misma. Se comparte con el compañero para que también tenga acceso al repositorio de la tarea. 

 Se crea el proyecto de Django en el que se generan las carpetas y archivos necesarios para el desarrollo de la aplicación web y para la conexión SQL server management Studio. Esto se lleva a cabo durante la primera reunión y posteriormente se subirá a GitHub para poder trabajarlo en conjunto. 

  Se crea el blog, en el cual se llevará un registro de todas las actividades que estén relacionadas con el desarrollo de la tercera y cuarta tarea de Bases de Datos I. Esto se lleva a cabo durante la primera reunión. 

  Se lleva a cabo la primera reunión para el proyecto. En esta define las tecnologías que se van a utilizar para el proyecto: — Django — CloudCluster — Blogger Además de esto, se crea la cuenta de GearHost, el blog y el proyecto de Django