[SOLUCIONADO] Base de datos de un Banco de Reactivos

JhondeKharl · #1 (**permalink**) 24/03/2015, 01:41

Muy buenas tardes (o noches, hay para todos los gustos)... Soy nuevo en la comunidad, me interesó sobre todo por los 'pocos' manuales que pude encontrar sobre base de datos y es que me han encargado como proyecto un sistema que Administre un "Banco de reactivos". No deseo que me hagáis mi trabajo, en encanta programar, diseñar y aprender por mi cuenta el problema, como el foro indica, es sobre mi "base de datos", esta sería la primera vez que utilizo BD para mi gran, no grata, sorpresa. . . no entiendo nada. Seré breve en la descripción de mi proyecto, y dolor de cabeza.

Es necesario la creación de un sistema que administre y emplee un “banco de reactivos”. Dicho proyecto permitirá a los docentes, de cualquier Academia (Dígase, DES de Informática, Matemática, Economía, Enfermería, etc), poder subir sus preguntas para que los alumnos de toda la Universidad puedan visualizarlas y responderlas.

Banco de Reactivos: Serie de preguntas con sus respectivas respuestas, es un tipo examen de acuerdo a la materia que estas impartiendo.

Partiendo de dicha primicia, comencé a pensar en una serie de tablas mal logradas, de acuerdo a las funciones que necesitaría mi sistema. Primero los usuarios que entraran en mi programa:

Los usuarios, son los siguientes:
-Alumnos [Son los únicos que responderán las preguntas realizadas por los profesores, además de ver un registro de avances]
-Maestros/Docentes [Crea las preguntas que se almacenarán en la base de datos, puede editarlos y eliminarlos, SIN EMBARGO no puede realizar dichas acciones con las preguntas de los demás profesores, sólo puede verlos {lectura}]
-Administrador General/Líder de la Academia [Mismo rango de los Maestros, con el agregado que puede Editar o Eliminar las preguntas de sus 'subordinados' PERO sólo los de su propia Academia {No puede eliminar/editar preguntas de Informática si pertenece a Socio Económicas}]

Los datos a pedir para el registro, son en todos los casos, los mismos:
-Matricula (Id_usuario) {tanto la matricula como el Numero de Docente son numéricos}
-Nombre (Nombre_usuario)
-Apellidos (Apellidos_usuario)
-Academia (Academia)
-Correo regular (Correo_base)
-Segundo correo (Correo_alter)
-Rol (Rol_moderador) {Aun no planteo muy bien como darle permiso al usuario, por el momento, darle a entender tres opciones a escoger [combo box]}
-Contraseña (Contraseña)

Código MySQL:
Ver original
Usuario
Id_usuario INT
Nombre_usuario VARCHAR 45
Apellidos_usuario VARCHAR 45
Academia VARCHAR 45
Correo_base VARCHAR 45
Correo_alter VARCHAR 45
Rol_moderador VARCHAR 45
Contraseña VARCHAR 6

Las preguntas están catalogadas de tal modo:
-Matricula<- (Id_usario)
-Identificador de pregunta (Id_pregunta)
-Curso/Materia (Curso)
-Temática/Tema (Temática)
-Pregunta (Pregunta_escrita)
-Imagen (Pregunta_img) {Se sigue valorando si esta opción puede ser válida/funcional, por el hecho que no se como subir imagen a la base de datos}
-Respuesta correcta (Respuesta_ok)
-Respuesta incorrecta 3 (Respuesta_in1)
-Respuesta incorrecta 2 (Respuesta_in2)
-Respuesta incorrecta 3 (Respuesta_in3)
-Número de veces que se ha aplicado (Aplicado_numero)
-Número de veces que se ha respondido correctamente (Respondido_numero)

Código MySQL:
Ver original
Pregunta
Id_usuario <-
Id_pregunta INT
Curso VARCHAR 45
Tematica VARCHAR 45
Pregunta_escrita VARCHAR 100
Pregunta_img VARBINARY 100
Respuesta_ok VARCHAR 100
Respuesta_in1 VARCHAR 100
Respuesta_in2 VARCHAR 100
Respuesta_in3 VARCHAR 100
Aplicado_numero INT
Respondido_numero INT

Y para rematar, se es necesaria (creo yo) otra tabla para los registros de avance de un Alumno usuario.

Código MySQL:
Ver original
Registro
Id_usuario <-
Fecha DATETIME
Curso VARCHAR 45
Tematica VARCHAR 45
Calificacion INT

Explicación de Funcionalidad: Cada Profesor registra una pregunta, por Curso y Temática. Un curso es propiamente una materia en concreto {Programación 1, Bases de Datos Relacionales, Matemáticas 2, etc.}. Una Temática, son los temas que se desglosan en un Curso {Matemáticas 1: Suma, Resta, Multiplicación División, etc}. Se almacena una Respuesta correcta y tres incorrectas. La pregunta puede ser Imagen {Pregunta_img VARBINARY 100} o textual {Pregunta_escrita VARCHAR 100, es por ello que Pregunta_img y Pregunta_escritas son NULL y no "NOT NULL" como correspondería}. Un Alumno puede escoger un Curso, siguiendo a una temática y automáticamente el sistema escoge 25 pregunta al azar sin importar que Docentes las escribió. Al finalizar, se guarda un registro, dicho archivo contiene la fecha y hora de cuando presentó el "examen", el Curso y tema, además de su Calificación {Preguntas bien contestadas/preguntas totales}.

A grandes rasgos he descrito todo el proyecto, discúlpenme si me he salteado demasiados detalles o no me doy a entender muy bien, llevo tres semanas sólo por crear estas tres tablas, y la desesperación/desvelo me está pasando factura. Estoy utilizando MySQL Workbench para la elaboración. . . de todo. Se me hizo tan intuitivo que casi ni tutoriales necesité.

Mi Problema: Siendo mi primera vez, ¿me hace falta otras tablas? ¿Como "normalizo" estas tablas? ¿Que tipo de dato es necesario para subir una imagen a una BD o que me recomiendan para dicha acción? ¿Como las "conecto"/relaciono? ¿Como sería el diagrama de entidad-relación? Aun no sé como hacer eso de "Llave foránea" en Workbench, ¿como se hace? Así como la imagen a la base de datos (hay una opción que dice Open value in editor pero siempre me manda error)

Sinceramente, espero que me puedan orientar en este proyecto, creí que me llevaría una semana, maximo dos pero ya llevo casi un mes, y sólo he estado leyendo y leyendo pero sigo sin comprender mucho de este enorme mundo de las Bases de datos {si me hubieran permitido con Ficheros, en tres días les habría entregado un proyecto ¬¬}. De antemano, agradezco toda ayuda. Saludos~

Libras · #2 (**permalink**) 24/03/2015, 09:06

tanto tiempo para 3 tablas?? y de verdad crees que con ficheros quedaria mejor??? a ver vamos a ayudarte un poco:

Usuario
Id_usuario INT
Nombre_usuario VARCHAR 45
Apellidos_usuario VARCHAR 45
Academia VARCHAR 45
Correo_base VARCHAR 45
Correo_alter VARCHAR 45
id_Rol int Fk con roles
Contraseña VARCHAR 6

Roles
id_rol int
descripcion varchar 20

Matricula
id_matricula
id_usuario Fk con usuarios
descripcion

Curso
Id_curso
Id_matricula Fk con matriculas
descripcion

temas
id_tema
id_curso Fk con cursos
descripcion

Preguntas
id_pregunta
id_tema Fk con temas
pregunta
imagen
respuesta

Examen
Id_examen
id_usuario Fk con usuarios
id_tema Fk con temas
id_pregunta Fk con preguntas
fecha
respuesta_usuario

Con algo como eso puedes obtener lo que necesitas :P

JhondeKharl · #3 (**permalink**) 25/03/2015, 20:51

Mmm. . . Si, ¿verdad? Para "tres tablas", Tres Semanas, suena más que exagerado, pena mas. Pero tengo mi excusa! Aprender todo este mundo nuevo me llevó mi tiempo, sin mencionar que todo lo que me dijeron fue "Haz un banco de reactivos". . . y ¡ya! Pero bueno, ya teniendo mi interfaz (programa en escritorio, todavía tengo que pelear con PHP para subirlo a la red. . . ese otro *edo ¬¬')

Doy las gracias por la. . . guía (sigo sin saber el ¡por que? debe de ser así, pero bueno). Sólo necesitaba un empujón para saber que tan mal encaminado iba y al parecer más que mal, estaba en la dirección contraria. Sin embargo, sólo me queda una duda. ¿Como hago la "consulta" para guardar una imagen (en Mysql, o Workbench {que es lo mismo pero sin consola})? y ¿Que tipo de variable es el más ajustado? Unos me recomiendan Varbinary y otro Blob más no me explican como usarlos correctamente.

De antemano agradezco toda la ayuda disponible. Igualmente muchas gracias TheLibras~ saludos~

Libras · #4 (**permalink**) 26/03/2015, 08:45

Mal encaminado, estas cometiendo uno de los errores basicos a la hora de programar, primero hacer la interfas y despues la base de datos, la aplicacion debe de adaptarse a la base de datos no al contratrio, sobre los campos de imagen, depende mucho de como lo vayas a manejar dentro de tu aplicacion, y de como se haga la serializada y deserializada de la misma.

gnzsoloyo · #5 (**permalink**) 26/03/2015, 08:57

Cita:

Iniciado por JhondeKharl

Mmm. . . Si, ¿verdad? Para "tres tablas", Tres Semanas, suena más que exagerado, pena mas. Pero tengo mi excusa! Aprender todo este mundo nuevo me llevó mi tiempo, sin mencionar que todo lo que me dijeron fue "Haz un banco de reactivos". . . y ¡ya! Pero bueno, ya teniendo mi interfaz (programa en escritorio, todavía tengo que pelear con PHP para subirlo a la red. . . ese otro *edo ¬¬')

Doy las gracias por la. . . guía (sigo sin saber el ¡por que? debe de ser así, pero bueno). Sólo necesitaba un empujón para saber que tan mal encaminado iba y al parecer más que mal, estaba en la dirección contraria. Sin embargo, sólo me queda una duda. ¿Como hago la "consulta" para guardar una imagen (en Mysql, o Workbench {que es lo mismo pero sin consola})? y ¿Que tipo de variable es el más ajustado? Unos me recomiendan Varbinary y otro Blob más no me explican como usarlos correctamente.

De antemano agradezco toda la ayuda disponible. Igualmente muchas gracias TheLibras~ saludos~

Vamos al principiobásico: Si son imágenes, no es buena idea guardarlas en la base de datos, a menos que sea una exigencia téncia o de sistema debiidamente fundamentada.
Lo usual, y lo práctico, es almacenar las imagenes en carpetas, y las rutas de acceso a las mismas en la base.

En ese sentido, "variables" no son temas de la base. Los campos sobn VARCHAR o BLOB, según se neesite para el caso.

En cuanto a lo que comenta Libras, es parcialmente correcto: La base se fundamenta en el sistema a soportar, y no en la aplicación, así como la aplicación no debe ser un reflejo de la base.
Esto es un tema de larga data y discusión, pero la idea es que:
- Una base debe ser lo suficientmente flexible como para responder a todas las consultas que pueda cubrir con sus datos, sin importar qué aplicación la invoque.
- La aplicación debe cumplir con losprocesos de negocio, no ajustarse a la estructura de la base.
- No debe existir exceso de acoplamiento entre ambas cosas, a fin de evitar que un cambio en una de ellas genere un fallo o inconsistencias.

Fundamentalmente:
- Las aplicaciones están orientadas a procesos, cumplen reglas de negocio. Las bases de Datos NO, se orientan a DATOS, en abstracción a su uso, y protege las restricciones de negocio, pero no las origina.
- Las bases de datos están orientadas al sistema, en abstracto. No a los procesos. Están más cerca de la representación de clases del sistema, que de las interfases de usuario.

Entremedio de las dos cosas (UI y DB) existe una capa que genera la relación (BL), y es allí donde se resuelve los procesos hacia y desde la base.

No hay que confundir los roles de cada cosa.

JhondeKharl · #6 (**permalink**) 26/03/2015, 10:11

Bueno, en eso les doy la razón. Sin embargo, si no daba un "adelanto" de mi trabajo me ahorcaban (sucios docentes que sólo saben exigir más no explicar), pero volver a realizar mi interfaz, luego de haber realizado mi BD. . . no me es problema, es más es divertido xD. Sobre las imágenes, bueno, no es "requisito técnico" mi tutor deseaba saber si era posible, para mi todo es posible (excepto la muerte) así que dije "claro que si" (maldito yo del pasado!) aun así creo que será mejor las rutas, más fácil y mucho menos pesado. Así que doy por terminado esta "pregunta". Gracias a todos. Saludos~

gnzsoloyo · #7 (**permalink**) 27/03/2015, 06:24

Bueno, a tu docente le puedes responder que es técnicamente posible, pero no es recomendable, especialmente si los usuarios que acceden a la base en ese caso (usuarios propios de MySQL) tienen restricciones de cuotas de datos, o bien si el buffer de consultas es restringido y no se puede modificar.
Para que se entienda:
- Es muy fácil y habitual en los hosting que te limiten la cuota de datos en la base para operaciones I/O. Con eso evitan que el motor sobrecarge el uso de memoria, que se necesita para el resto de las consultas de otros usuarios.
- Como cada bloque de datos que el motor recupera tiene un límite de tamaño almacenable en unidades, y mientras más datos en bytes se recuperen, más bloques de datos se deberán usar para transferir. Ergo, almacenar una imagen en una tabla ocupa en un ínico campo BLOB, muchas veces más bloques de datos que lo que se requiere para recuperar 1.000.000 de registros de otras consultas que obtienen datos alfanuméricos.
¿Se entiende?
- Además, una consulta de ese tipo podría intentar buscar do o más imágenes al miemso tiempo... imagina el impacto de eso.
- Todo lo que se recupera en las consultas, además de requerir espacio de memoria del servidor, requiere el uso del buffer de consultas, donde se almacena antes de ser derivado al cliente (aplicacion) que lo solicitó. Usualmente no suele configurarse un buffer de consultas demasiado grande, por lo que la recuperación de campos BLOB puede requerir varios ciclos de transferencia antes de entregar todo.
Trata de hacerte una idea de lo que implicaría para la performance del DBMS dedicar exclusivamente el buffer a la transferencia de imagenes... y lo que le puede pasar a los demas usuarios que estén accediendo al DBMS al mismo tiempo (concurrencia).

En definitiva, guardar imagenes en la tabla no es imposible, ni es difícil. Pero es una pésima estrategia de diseño.
Por eso es preferible guardar las rutas, y dejar que el WebServer se encargue de recuperar y transferír el archivo a la aplicación por FTP...