Skip to content
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

Open
fdemian opened this issue Jun 18, 2016 · 10 comments
Open

Modelo de datos #12

fdemian opened this issue Jun 18, 2016 · 10 comments

Comments

@fdemian
Copy link

fdemian commented Jun 18, 2016

Implementar el modelo de datos de la aplicación.

@afilgueira afilgueira modified the milestone: Empanada de Atún Jun 18, 2016
@afilgueira
Copy link

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

@demiangonda
Copy link

demiangonda commented Jun 20, 2016

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
Copy link
Contributor

gndelia commented Jan 6, 2017

@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
Copy link

demiangonda commented Jan 6, 2017

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
Copy link
Contributor

gndelia commented Jan 7, 2017

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
Copy link
Author

fdemian commented Jan 8, 2017

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
Copy link

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
Copy link
Contributor

gndelia commented Jan 9, 2017

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
Copy link
Member

@fdemian
Copy link
Author

fdemian commented Jan 10, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants