Errores en entidades creadas y otras peticiones
rapid design and code using scrum
Brought to you by:
jrodeiro
Menu
▾
▴
Hola a todos,
Algunas entidades ya están subidas.
Otras no lo están.
Este viernes 30 de noviembre todas las entidades propias de funcionalidades deben estar subidas. Si no estan subidas se considerará el EP1 como no evaluable.
Esto significa que si no se han incluido en el BDIUTIC.sql las entidades propias de cada funcionalidad no se va a evaluar la EP1 de dicha funcionalidad.
En cuanto a las entidades ya subidas, se están apreciando falta de atributos en las mismas. Se utilizará el foro como lugar de aviso de estos fallos para su corrección por los propietarios de las mismas.
Yo verificaré los avisos y la modificación si fuere adecuado de las entidades. Esta parte de la materia se utilizá para que aprendais el trabajo en grupo o colaborativo. Si no trabajais en grupo o colaborais la EP1 está suspensa (con un cero).
Un saludo
Javi
Hola
Creo que el campo CODPRORES de la entidad ASIGNATURA debería ser un varchar(9) para que coincidiera con el DNI del usuario y así poder hacer las consultas pertinentes para trabajar con él en el resto de entidades, en mi caso en ASIPROASI.
Hola, primero me gustaría preguntarle a @jrodeiro donde hay que subir las entidades, segun el enunciado de la EP1 apartado 1 a) "Completar con las entidades necesarias el fichero BDIUTIC.sql que está en el directorio IUTIC". Creo que no es ese el archivo que se está modificando. Otra duda es si despues del Viernes 30 no se podrán realizar modificaciones en el archivo .sql
Y creo que por el mejor entendimiento del archivo .sql por parte de todos sería interesante que se añadiera un comentario encima de cada entidad para saber a que se refiere. Y incluso un @usuario con el autor para saber a quien preguntar directamente en caso de tener algo que discutir a cerca de dicha entidad
Además de esto en el archivo BDIUTIC/BDIUTIC.sql me aparecen algunos caracteres extraños en la línea 227 ¿soy el unico al que le pasa eso?
Hola
Yo creo que el enunciado a) "Completar con las entidades necesarias el fichero BDIUTIC.sql que está en el directorio IUTIC" indica claramente cual es el fichero que hay que actualizar. Si los alumnos modifican otro fichero será porque lo deciden así y será por su cuenta y riesgo.
A partir del viernes se puede seguir modificando el archivo, pero a los que no hayan incluido sus entidades propias antes del periodo indicado no se les evaluará la EP1 y tendrán un 0 en ella al no cumplir el requisito de tener subidas sus entidades propias en fecha.
Obviamente sería lo mas adecuado que se incluyese un comentario antes de cada entidad. Ya hay alumnos que lo están haciendo.
Yo acabo de mirar esa linea y no veo los caracteres extraños.
Tambien seria adecuado que los comentarios de los commits fuesen descriptivos, del estilo "Usuario actualizando ....."
saludos
"PLANIFICACION_HORAS" en IUTIC, fichero de base de datos:
El nombre de la tabla es USUARIOS, cuando los datos no corresponden en absoluto a usuarios.
Quien haya insertado PLANIFICACION_HORAS que lo corrija.
Hay muchas cosas que no coinciden....
en el diccionario de datos aparece un atributo TIPUSU como un enumerado [ enum('AD','PRA','P','AL') ] y en el fichero BDIUTIC.sql de /IUTIC aparece en la tabla USUTIPREL el mismo atributo como un int(6) y luego una tabla TIPUSU con el TIPUSU(int6) y la descripción del codigo, NOMTIP(varchar).
No sería mucho mas fácil, y ahorraríamos una tabla, poner en la tabla USUTIPREL, en el atributo TIPUSU, un enumerado y eliminar la tabla TIPUSU???? así nos ahorramos esa tabla y sería mucho más fácil para todos.
Hola
Los atributos de tablas de los que estas hablando corresponden con tablas no propias de funcionalidad.
Esas tablas se crean porque no están las entidades correspondientes y se crean cada uno como mas les guste.
Hasta mañana no sabremos cuales son las entidades propias finales con las que vamos a trabajar. En cuanto las entidades propias estén claras se deberán eliminar las NPR si existe una entidad propia que la cubra. Si a esta entidad le falta algún atributo o requiere alguna modificación se indicará en el foro.
El propietario de la entidad propia de funcionalidad es quien determina como será el formato de los atributos y los demás alumnos deberán ceñirse a la misma siempre y cuando permita cumplir su propósito.
Me consta que ya existe la entidad TIPUSU en el sql y que se introducirá en el diccionario de datos.
En la tabla USUARIO que debería ser la común para todos ya que no tiene el prefijo NPR, falta el atributo TIPUSU o CODTIPUSU ( como decida el/la que lleve gestión de usuarios ), el atributo PASSWORD debería de ser un varchar de 60 ya que sino la función mimd5() no funciona correctamente.
PD: En la tabla NPR-GPR-USUARIOS ( GPR = gestion preguntas y respuestas, mi funcionalidad ) el atributo TIPO que designa el tipo de usuario está como un VARCHAR(5) teniendo que ser un int(6) para adaptarse a la tabla TIPUSU. No lo he corregido ya que en principio esta tabla desaparecerá una vez se concrete la tabla USUARIOS para todos.
Estoy de acuerdo en el atributo PASSWORD que debería subirse a 60 para la encriptacion. Pero no falta el atributo TIPUSU porque existe una tabla para tipos de usuario y una tabla de relación entre los tipos de usuario y los usuarios (de esta forma se permite que un usuario sea de mas de un tipo)
Hola , en la tabla tipo de usuario falta por definir profesor responsable de asignatura
como ya he dicho en un post anterior. Existe una tabla de relación entre USUARIO y TIPUSU. En esa tabla se introducirán el codigo de usuario y el codigo de tipo de usuario para indicar todos los posibles roles que un usuario concreto tiene. Porque un usuario puede ser a la vez varios actores distintos. Cuando en una funcionalidad se asigne un rol a un usuario debe ponerse una entrada en esa tabla de relación además de la indicación concreta en la tabla de la funcionalidad (ejemplo: Asignar profesor responsable de asignatura, hace una entrada en la tabla de relación entre USUARIO y TIPUSU indicando que ese usuario es PROFESOR RESPONSABLE DE ASIGNATURA, y ademas en ASIGNATURA deberia estar el codigo de usuario en el atributo de profesor responsable)
Last edit: Javier Rodeiro Iglesias 2012-11-30
Tal como he expresado en el fichero SQL, quisiera pedir una serie de campos puesto que las tablas a modificar no me pertenecen. Necesito:
hola
no has expresado bien por aquí lo que necesitas.
El campo de PROFESOR RESPONSABLE DE TITULACION lo pides para TITULACION supongo. Por mi es correcto que tenga ese atributo.
El atributo para DEPUSU (DEPARTAMENTO DEL USUARIO) seria un codigo y tu (puesto que te hace falta) deberías crear la entidad DEPARTAMENTO con el código y el nombre del departamento puesto que nadie mas ha indicado que le hace falta.
me refiero a que es correcto que el responsable sea un int(6)
Como recomendación a la creación de tablas, sugeriría que los ids "CODALGO" en este caso, fuesen con el valor al lado AUTO_INCREMENT, ya que son claves primarias artificiales.
No te has leído el fichero de estandarización del proyecto.
Los autoincrementales están explicitamente prohibidos.
Recomiendo que se lean las condiciones de realización de las funcionalidades antes de hacer este tipo de recomendaciones.
Un autoincremental suspende directamente la EP1 al no ser capaz de seguirse el estandar de codificación.
Como ya le dije a Javi en un correo, creo que se deberían añadir más campos en algunas tablas. Por ejemplo, en asignaturas, se debería saber a que materia pertenecen, y no a que titulación.. ya que las que pertenecen a titulación son las materias. Otro dato que deberían tener las asignaturas es, el carácter que tienen, es decir, si es obligatoria, de formación básica, etc.. En la tabla ALUASI, también harían falta más campos, como por ejemplo el número de convocatorias que lleva el alumno. Cada vez que se inserte un alumno en la tabla, el campo NUMCON, por ejemplo, se incrementará en 1.
Otra cuestión es si en la tabla POREVA (porcentajes de evaluación), el atributo PORPAD no tendría que ser un int(6) ya que es como está definido el código en la propia tabla...
Por partes,
Efectivamente las materias pertenecen a titulaciones y las asignaturas a materias. Pero puede darse el caso de asignaturas que no pertenezcan a materias y puedan ser cursadas por varias titulaciones. Ya existe una asignación de asignaturas a materias y una gestión de las mismas. Creo que debe quedar la titulación en asignatura.
Si debe tener un atributo de caracter la asignatura. Puede ponerse para no complicar mas a gestion de asignaturas como un enumerado.
No estoy de acuerdo en cuanto a la tabla ALUASI. Va existir una tupla por asignatura, año academico y alumno. Por lo tanto un atributo numcon no tiene significación. Para ver el numero de convocatorias habria que ver la evaluación de la asignatura cada vez que la haya cursado. De esta manera puedes tener numero de matriculas y de convocatorias consumidas por un alumno en una asignatura.
Obviamente el atributo correspondiente al porcentaje padre tiene que identificarse de la misma manera que el porcentaje hijo, con un codigo numerico de 6 digitos.
saludos
Disculpad las molestias, me equivoqué en la petición en el foro aunque sí la indico correctamente en el .sql con el campo "responsable" en la tabla titulación. Acerca del otro campo que solicité lo quería definir por extensión y no por intensión, cuando te lo pregunté en el despacho no te pareció mal incluirlo en esa tabla, de hecho habíamos acordado que admitiese nulos, ¿por qué? Porque la relación con la tabla de usuarios es parcial y en función del tipo de usuario iban a tener o no departamento, de todas formas no es estrictamente necesario para mi funcionalidad, así que por favor descartad mi propuesta.
En cuanto al no uso de autoincrementales, la propuesta era para cambiar el estandar. El uso de claves artificiales tiene entre uno de sus objetivos principales el que el usuario no la tenga que introducir (además de temas de indexación y de no encontrar una clave candidata idónea), por eso lo he propuesto, la unicidad de claves es objetivo y un autoincremental lo garantiza. Perdón por las molestias que haya podido causar si alguien interpretó que no era dirigida a cambiar el estandar (se supone que lo hemos leido todos).
Hay tablas a las que les falta la clave primaria.. nose si hay más o no, pero a COMMAT y a COMASI les falta.
Como sugerencia, creo que se debería aumentar el tamaño de los campos.. ya que, por ejemplo, muchas nombres de asignaturas no cogen con un varchar(20). Ahora mismo no se si hay más campos a los que les pase eso, pero seguramente pase en algunos más.
Estoy de acuerdo
Me gustaría que se hiciera una explicacion de las entidades HORAS, ESFUERZO_ALUMNO y TIEDEDSEM (tiempo de dedicación semanal) yo considero que son las mismas y como usuario de TIEDEDSEM, pido que los respectivos autores contaquen conmigo para unificar estas entidades. La idea de TIEDEDSEM es almacenar el tiempo que un alumno le dedica a una actividad o tarea de una asignatura
Yo tambien he creado la entidad TARALU (tareas del alumno) con la idea de que alguien la completara. Y veo que se han creado las entiedades ACTIVIDAD y ACTIVIDADES. Pido también unificar estas tablas si son las mismas. Mi intención con TAREAS era almacenar cada actividad o tarea que deba realizar un alumno dentro de una asignatura, por ejemplo la ET1 es una tarea, la PREP4_ET1 es otra.
Y por favor, poned vuestros nombres en las entidades.
Muchas gracias a todos
Last edit: Adrian P 2012-12-02
He eliminado las entidades TIEDEDSEM y TARALU, pero queda el problema con ACTIVIDADES de JoseAlvarez(jsaalva) y ACTIVIDAD de AdolfoÁlvarezLópez(aalopez)
Como le dije a Javi, creo que sería conveniente poner en la tabla PREEXA un código tanto para identificar la asignatura, como para almacenar la nota obtenida en dicho examen. Creo que sería mucho más fácil si se almacena la nota, que si cada uno que la necesite tiene que calcularla con las respuestas de dicho examen.