-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modelo de datos #12
Comments
Diseño (DRAFT)Notas(1) Correlativas se mantiene en MPl (Materias por Plan) (Grafo dirigido aciclico) Relaciones entre tablasU -< Pr -< PrM >- M Tablas de Dimensiones / MasterDataU: Usuarios (Uid) Tablas BridgesPrM: (Prid, Mid) Materias dadas por un profesor Volumen|FC| = |F| x |C| M(h): Materias Homogeneas |
estoy haciendo un par de abms en react para probarlo, y de paso quería hacer algo util, asique dije, me voy a hacer un par de abms para cargar las materias/cursadas/relaciones/etc y tanto para la estructura vieja de la db (xq faltan carreras ahi) como para la nueva. Donde se anotarían las correlativas aca? Por lo demas, segun entiendo cargo por un lado las facultades, los planes por otro, y las materias, y luego hago una carrera que es la asociación de una facultad, plan, y una lista de materias con sus relaciones/correlatividades. el resto es información generada por los usuarios (usuarios, alumnos, profesores, profesores que dan materias, estado de materias por alumno) gracias! |
Como va Gonza,
En el 2do modelo: MPl: (Mid, Plid, M Requerimientos Cursada, M Requerimientos Aprobada, M Dependencias Cursada, M Dependencias Aprobada) Materia por Plan (1) M Requerimientos Cursada, M Requerimientos Aprobada, M Dependencias Cursada y M Dependencias Aprobada son sets de Mids correspondientes a las materias. El objetivo del diseño es simplificar consultas de API (si te piden materias cursadas necesarias para cursar, por ejemplo, mandas el set directo), pero la contrapartida es que la operación de Alta es más compleja, entre otras cosas no podes usar FK en la base para validar una correlativa, tiene que ser lógica de validación metida en el ABM. M Requerimientos Cursada: Materias Cursadas necesarias para Cursar la Mid, Plid.
Si. Lo que no contempla el modelo son Materias necesarias para dar final.
Si. La idea es que tener que tracear el grafo de dependencias por cada consulta de API porque ya las tenes "precalculadas".
Sí, que el set sea directo un json
Hay varias alternativas. Como decís se puede modelar con 2 tablas para Cursada y 2 para Aprobar. Pueden ser 2 de Requerimientos (dos tablas Mid, Plid, Mrid, donde Mrid es la materia cursada necesaria para cursar, y la otra la materia aprobada necesaria para cursar) si queres que la dirección del grafo acíclico sea de 5to año a 1ero (que las hojas sean las materias de 1ero) y/o 2 tablas de Dependencias si querés que las hojas del grafo sean las materias de 5to. Esto lo necesitarías diferenciado entre Requerimimentos/Dependencias para Cursar y para Aprobar. Seguramente hay más alternativas que no se me están ocurriendo, pero el requerimiento base es mantener información de a nivel de materia por plan de otras materias cursadas necesarias para cursar, materias aprobadas necesarias para cursar, materias cursadas necesarias para aprobar y materias aprobadas necesarias para aprobar, definiendo si querés que las hojas sean las materias de 5to, las materias de 1ero, o manteniendo dos modelos para no tener que invertir grafos dirigidos por cada consulta de API (en caso de que sea un issue). EDIT: Dije una ganzada, si mantenes tablas Mid, Plid, Mrid no tenes grafo direccionado a nivel modelo de datos, y no necesitas duplicar. Saludos. |
El modelo actual (el del seguidor del foro) sí lo contempla. Porque no lo contemplamos ? |
Ping. Estoy luchando con lo mismo (quiero incorporarlo al seguidor de carreras). Por ahora estoy usando los datos del foro ( https://github.com/fdemian/SeguidorCarrera/blob/master/data/materias.json) y adaptándolas. ¿Hay alguna API a la que se le pueda pegar de esto? Mis preocupaciones principales son:
Entiendo que (1) llegaría junto con (3) (o al menos esa es la idea) y estaría bueno definir el formato en que llegan en una spec. Por ahora estoy usando la manera en la cual "llegan" en el seguidor actual las materias, el tema es que no indican su estado (esto viene aparte y no encuentro el JSON del servidor de donde sale esto). No se si es el topic para hablar de esto igual. Cualquier cosa abro otro. |
Usemos el modelo del foro entonces (no lo conozco) Si no, es un duplicado del modelo para cursar. En el modelo bidireccional de 2 tablas necesitas 4, en el modelo de repeticion con columnas Requerimiento/Dependencia tenes que duplicar la cantidad de columnas. |
el problema del modelo actual del foro es que no soportaba electivas libres, ni tampoco se adaptaba a cualquier otro tipo de plan de otra universidad (si es que lo queremos tener como idea a futuro). Creo que por eso no lo usamos. |
@Javier-Rotelli me refería más a lo nuevo que estamos planeando (supongo que le voy a pegar a la api de 2.0 en lugar de la api del foro). Mi problema con lo viejo igual es que en ningún lado esta documentado como llegan el estado de las materias. Llegan las materias y las coorrelativas...pero en ningún lado veo que este llegando "lo que curso/aprobo/firmo el usuario" (obviamente no puede estar llegando mágicamente, pero debuggear código minificado del seguidor es bastante engorroso y no me llevo a ningún lado todavía). |
Implementar el modelo de datos de la aplicación.
The text was updated successfully, but these errors were encountered: