search

Elecciones2016 / Db-build

Scripts necesarios para poblar la base de datos para la API
1 stars 0 forks source link

Diseñar modelo de datos final #1

Open YerkoPalma opened 8 years ago

YerkoPalma commented 8 years ago

Senadores

senadores

YerkoPalma commented 8 years ago

modelo de datos - new page

hkmgosu commented 8 years ago

debes tener una clase que controle las asistencias y unir senador a esa clase mejor o no?

comision - sesion - partido - senador ------< registro_asistencias (o cualkier nombre)

registro asistencia: id, fecha entrada, fecha salida, campaign (?), elecctiones (?), voto (bolean, verdadero a favor / falso en contra (?) o 1 y 0 ), id_senador, id_sesion, id_comision, id_partido.

al momento de hacer una query sobre quienes votaron, se hacen 'inner join' a las tablas de senador por ejemplo con registro asistencia, en el caso de que sea null es xk no fue, y se puede dejar como ausente en el caso de null y tener un listado completo del registro de ese dia, pero si los datos vienen de la página y se ve que no fue es mejor hacer un campo definido de opciones igual 0: en contra, 1: a favor, 2: ausente

comision: id, nombre, fechas si es que hay, etc. sesion: id, nombre, fechas, etc partido, id, nombre, postura (izquierda, derehca, identificar para demostrar que izq o derecha los que roban no tienen postura, son solo ladrones y corruptos)

YerkoPalma commented 8 years ago

debes tener una clase que controle las asistencias y unir senador a esa clase mejor o no?

Tener un Documento (en MongoDb hablamos de documentos, no tablas ni clases) para controlar la asistencia es una de las opciones de diseño. El tema principal es poder hacer consultas del tipo

Por lo tanto, la asistencia definitivamente corresponde a un documento, ahora, no me parece que sea un único documento.

al momento de hacer una query sobre quienes votaron, se hacen 'inner join' a las tablas de senador por ...

Una de las caracteristicas de las bases de datos NoSql, es que no existen tablas, por lo tanto no existen joins. O sea, al momento de hacer un query no se juntan los documentos mediante un join, por lo tanto es factible tener data duplicada (no normalizada). En base a lo anterior lo que busco es poder responder las consultas que mencione de la siguiente forma

//Allamand
db.senadores.find(5002921).asistencia; //obtiene json con los detalles de la asistencia de Allamand, incluyendo comisiones y sesiones de sala
db.comisiones.find(123123123).asistencia; //obtiene el detalle de la asistencia a la comision 123123123

En resumen, lo más probable es que adopte el enfoque inicial, de la primera imagen, y repita la información de la asistencia. Tengo un ejemplo de como quedaría la información (hecho con información real). Seria bueno que lo revisaras, para que veas que información hay disponible (paginas del senado y servel)

PD: En cuanto a tu ultimo comentario

comision: id, nombre, fechas si es que hay, etc. sesion: id, nombre, fechas, etc partido, id, nombre, postura (izquierda, derehca, identificar para demostrar que izq o derecha los que roban no tienen postura, son solo ladrones y corruptos)

Toda la razón xd. De hecho, esta dentro de las consideraciones comparar el voto de cada senador/diputado con el de su partido, como lo hacen en opencongres.org

hkmgosu commented 8 years ago

la costumbre de llamarles clases, que trabajo en parse.com (facebook) y ahí trabajan con esto mismo pero ellos le llaman clase, usan las mismas funciones .find(id) get etc , con rockdb una version de mongo.

lo de iiner join iba en comillas ya que la mayoria entiende la union de 2 documentos y que su objetos tengan las id correspondientes (iba a decir clases de nuevo) mediante sql relacional x eso lo aplico siempre ese lenguaje :x

los requerimientos funcionales o algun formulario que indique que acciones o consultas se quieren hacer a la db?

El 15 de diciembre de 2015, 10:24, Yerko Palma notifications@github.com escribió:

debes tener una clase que controle las asistencias y unir senador a esa clase mejor o no?

Tener un Documento (en MongoDb https://www.mongodb.org/ hablamos de documentos, no tablas ni clases) para controlar la asistencia es una de las opciones de diseño. El tema principal es poder hacer consultas del tipo

  • Detalle de la asistencia de un senador el ultimo mes
  • _Detalle de la asistencia de senadores a la sesión con id=2135435

Por lo tanto, la asistencia definitivamente corresponde a un documento, ahora, no me parece que sea un único documento.

al momento de hacer una query sobre quienes votaron, se hacen 'inner join' a las tablas de senador por ...

Una de las caracteristicas de las bases de datos NoSql, es que no existen tablas, por lo tanto no existen joins. O sea, al momento de hacer un query no se juntan los documentos mediante un join, por lo tanto es factible tener data duplicada (no normalizada). En base a lo anterior lo que busco es poder responder las consultas que mencione de la siguiente forma

//Allamanddb.senadores.find(5002921).asistencia; //obtiene json con los detalles de la asistencia de Allamand, incluyendo comisiones y sesiones de sala

db.comisiones.find(123123123).asistencia; //obtiene el detalle de la asistencia a la comision 123123123

En resumen, lo más probable es que adopte el enfoque inicial, de la primera imagen, y repita la información de la asistencia. Tengo un ejemplo https://github.com/Elecciones2016/Db-build/blob/master/DATABASE.md de como quedaría la información (hecho con información real). Seria bueno que lo revisaras, para que veas que información hay disponible (paginas del senado y servel)

PD: En cuanto a tu ultimo comentario

comision: id, nombre, fechas si es que hay, etc. sesion: id, nombre, fechas, etc partido, id, nombre, postura (izquierda, derehca, identificar para demostrar que izq o derecha los que roban no tienen postura, son solo ladrones y corruptos)

Toda la razón xd. De hecho, esta dentro de las consideraciones comparar el voto de cada senador/diputado con el de su partido, como lo hacen en opencongres.org https://www.opencongress.org/

— Reply to this email directly or view it on GitHub https://github.com/Elecciones2016/Db-build/issues/1#issuecomment-164779339 .

YerkoPalma commented 8 years ago

Me falta detallar (documentar) mejor esa parte :P lo más cercano que tengo esta en el sitio El objetivo principal del proyecto, es generar una API que provea información de la clase politica. Inicialmente, habia pensado en generar la API sin una BD, ya que la información esta disponible y como pensaba en node, podría tener una api que hiciera scrapping asincrono, pero rapidamente me di cuenta que no era buena idea xd, por que dependia mucho de las páginas o sitios del gobierno, y por que gran parte de esta información, sobre todo la del servel, esta en pdf. Asi que cree este proyecto para proveer la base de datos.

A que voy con esto, es que es distinto lo que exponga la base de datos y la api, con lo que se muestre más adelante en la aplicación móvil. O sea, podriamos decir que mis objetivos secundarios o especificos son

Con el ultimo punto quiero hacer que en la aplicacion la gente pueda hacer preguntas como: cuánto gastan en viajes (promedio) los politicos oficialistas? cuántas inasistencias tiene el senador x? qué partido obtuvo más aportes reservados en las elecciones pasadas? o por ejemplo que se den cuenta que ni un senador fue escogido con más del 10% de representación de su distrito...

Te recomiendo mirar los otros proyectos asociados, especialmente el de la API