UTNianos / 2.0

MIT License
1 stars 0 forks source link

Modelo de datos #12

Open fdemian opened 8 years ago

fdemian commented 8 years ago

Implementar el modelo de datos de la aplicación.

afilgueira commented 8 years ago

whatsapp-image-20160618 2 whatsapp-image-20160618 1 whatsapp-image-20160618

demiangonda commented 8 years ago

Diseño (DRAFT)

Notas

(1) Correlativas se mantiene en MPl (Materias por Plan) (Grafo dirigido aciclico) (2) Cambios de planes, carrera y/o facultad se manejan en tablas de Profesor o Alumno (3) EMAl transaccional principal (4) Un Plan es la implementacion de un plan para una facultad, y mantienen atributos asociados a cada materia particulares a facultad.

Relaciones entre tablas

U -< Pr -< PrM >- M U -< Al -< EMAl >- M F -< FC >- C -< Pl F -< Pl -< MPl >- M M -< ApM >- Ap

Tablas de Dimensiones / MasterData

U: Usuarios (Uid) Pr: Profesor (Prid, Uid, FCid1, FCid2, ... , FCidn) (2) Al: Alumno (Alid, Uid, Plid1, Plid2, ... , Plid3 , FCid1, FCid2, ... , FCidn) (2) M: Materia (Mid) Ap: Apunte (Apid) F: Facultad (Fid) C: Carrera (Cid) Pl: Plan (Plid, Cid, Fid)

Tablas Bridges

PrM: (Prid, Mid) Materias dadas por un profesor EMAl: (Mid, Alid, Estado) Materias por alumno con estado actual (3) ApM: (Apid, Mid) Apuntes por Materia MPl: (Mid, Plid, M Requerimientos Cursada, M Requerimientos Aprobada, M Dependencias Cursada, M Dependencias Aprobada) Materia por Plan (1) FC: (Fid, Cid) Carrera por Facultad

Volumen

|FC| = |F| x |C| |PrM| = |Pr| x |M| |EMAl| = |M| x |A| (3) |ApM| = |Ap| x |M| |MPl| = |M| - |M(h)| + |M(h)| x |Pl|

M(h): Materias Homogeneas

gndelia commented 7 years ago

@demiangonda

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. Sobre la vieja estructura ya la conozco, sobre la nueva tengo dudas:

Donde se anotarían las correlativas aca? Según entiendo es en MPI, donde habría una fila por IdMateria-IdPlan, y cada fila corresponde a una correlativa(es decir, una materia que debo cursar, o que debo rendir) No me cierra la parte de "Dependencias", sería que materias me habilita una vez cursada / aprobada? No me quedaría data repetida ? (digo, como es información indepentiende de las correlativas, que dependencia persisto con que fila de correlativas?) o pretendes separarlo en mas tablas? O pretendes poner todo en una fila y guardar las correlativas en un campo y las dependencias en otro, de alguna manera que quepa en una fila, tipo un string json ? O se me escapa alguna alternativa mas?

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!

demiangonda commented 7 years ago

Como va Gonza,

Donde se anotarían las correlativas aca? Según entiendo es en MPI, donde habría una fila por IdMateria-IdPlan, y cada fila corresponde a una correlativa(es decir, una materia que debo cursar, o que debo rendir)

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. M Requerimientos Aprobada: Materias Aprobadas necesarias para Cursar la Mid, Plid. M Dependencias Cursada: Materias que podes Cursar si cursaste la Mid, Plid. M Dependencias Aprobada: Materias que podes Cursar si aprovaste la Mid, Plid.

No me cierra la parte de "Dependencias", sería que materias me habilita una vez cursada / aprobada?

Si. Lo que no contempla el modelo son Materias necesarias para dar final.

No me quedaría data repetida ? (digo, como es información indepentiende de las correlativas, que dependencia persisto con que fila de correlativas?)

Si. La idea es que tener que tracear el grafo de dependencias por cada consulta de API porque ya las tenes "precalculadas".

o pretendes separarlo en mas tablas? O pretendes poner todo en una fila y guardar las correlativas en un campo y las dependencias en otro, de alguna manera que quepa en una fila, tipo un string json ?

Sí, que el set sea directo un json

O se me escapa alguna alternativa mas?

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.

gndelia commented 7 years ago

Lo que no contempla el modelo son Materias necesarias para dar final.

El modelo actual (el del seguidor del foro) sí lo contempla. Porque no lo contemplamos ?

fdemian commented 7 years ago

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:

1) Como me llegan las materias 2) Como me llegan las coorrelativas 3) Como me llegan las materias que aprobo el usuario.

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.

demiangonda commented 7 years ago

El modelo actual (el del seguidor del foro) sí lo contempla. Porque no lo contemplamos ?

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.

gndelia commented 7 years ago

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. Despues te armo un dercito asi ves como está ahora

Javier-Rotelli commented 7 years ago

@fdemian http://www.utnianos.com.ar/foro/tema-documentacion-plugin-academicas ahi esta todo.

fdemian commented 7 years ago

@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).