Diseño físico de datos y persistencia¶
| Proyecto | SuiteSET3 |
| Descripción | Plantilla para proyectos basada en ReadySET y Métrica 3. |
| Desarrollo | project:suiteset3-dev versión suiteset3-dev:version#1 |
| Plazos vigentes | FECHA INICIO - FECHA FINALIZACIÓN |
| Fecha edición | 30/10/2024 |
| Relacionados | ENLACES A ESTÁNDARES RELEVANTES ENLACES A OTROS DOCUMENTOS |
Resumen¶
TAREAS: Responda a las preguntas que se encuentran abajo para ayudar a diseñar las características de persistencia necesarias. Se muestran algunos ejemplos, añada o elimine texto según considere necesario.
¿Cuáles son los hechos más importantes que un desarrollador debería conocer sobre almacenamiento persistente de información de este sistema?
PÁRRAFOS O VIÑETAS
¿Cuáles son los objetivos categorizados para persistencia en este sistema?
- Expresividad
- Facilidad de acceso
- Confiabilidad
- Capacidad de Datos
- Seguridad en los Datos
- Desempeño
- Interoperabilidad
Base de Datos Central¶
¿Cuál es la lógica en el diseño de la base de datos?
El diseño lógico de la base de datos está descrita en este modelo UML o en este diagrama ER (entidad/relación).
Las consideraciones lógicas adicionales a la base de datos son:
Los estudiantes pueden repetir un curso (y obtener así dos registros para el mismo curso en su boleta) si y solo si tienen una calificación de "6.5" o menor, o el número del curso es 198, 199, 298 o 299.
Una calificación mayor de "10" es válida solo para entradas de boletas durante o después de otoño de 1990. Antes de esta fecha, la calificación másima posible es de "10".
CONSIDERACIÓN LOGICA QUE NO PUEDE SER EXPRESADA EN EL DIAGRAMA
CONSIDERACIÓN LOGICA QUE NO PUEDE SER EXPRESADA EN EL DIAGRAMA
¿Cuáles son las tablas físicas y las vistas?
el diseño de la base de datos física se describe en este modelo UML o en este href="LINK-TO-DIAGRAM">diagrama ER.
¿Cómo se almacenarán los objetos de la aplicación en la base de datos?
Utilizaremos una tabla de la base de datos para cada clase, y una fila en la base de datos para cada instancia persistente de esa clase.
Utilizaremos una libreria para hacer nuestro mapeo de objectos-relaciones. (Por ejemplo, torque, castor, JDO, ADO, hibernate)
¿Qué controles de acceso a la base de datos se utilizarán?
Una cuenta de usuario de la base de datos ha sido creadapara accesar las tablas necesarias de la aplicación. El nombre del usuario y la contraseña para esta cuenta se almacenna en un archivo de configuración que lee el servidor de aplicaciones. La base de datos limita el acceso de ese usuario a solo las direcciones IP usadas por el servidor de aplicaciones.
¿Pueden otras aplicaciones acceder a la base de datos central de la aplicación ?
Sí. La base de datos es un punto importante de interoperabilidad para nuevas aplicaciones que pueden ser añadidas más tarde. La misma base de datos provee soporte para controles de acceso y revisa las consideraciones de validez para que una aplicación defectuosa no pueda corromper la base de datos.
No. esta base de datos deberá ser siempre accesada por medio de esta aplicación. Todas las piezas de información relevante están disponibles a través de las interfaces de la aplicación. la base de datos en sí no cuenta con protección contra la corrupción de datos que pudieran causar otras aplicaciones.
Almacenamiento de Archivos¶
¿Qué información necesita ser almacenada en archivos?
No se almacena nada en archivos. Todo se encuentra en la base de datos.
El servidor almacena la mayoría de la información en la base de datos, pero los archivos anexos a la lista de correo son escritos en archivos en el disco duro del servidor.
Todos los documentos de los usuarios son almacenados en el disco duro de su computadora.
¿Cuáles son las convesiones para la estructura de directorios y el nombrado de archivos?
N/A
Los archivos son almacenados en el servidor como /var/data/attachments/msgNNNN-MMM.dat.
Lo usuarios almacenan sus archivos en cualquier lugar de su computadora, con el nombre de archivo y extension .TST.
¿Que controles de acceso al sistema de archivos se utilizarán?
N/A
Los archivos para mensajes adjuntos solo podrán ser leidos y editados por el proceso de archivación de la lista de correos que utiliza el usuario del sistema "archdaemon".
Los usuarios pueden utilizar cualquier permiso sobre el archivo que deseen.
Almacenamiento Distribuido¶
¿Qué información (si existe) se guadará en los equipos del cliente? ¿Por cuánto tiempo?
Una cookie se almacenará en el equipo del usuario con propósitos de identificar una sesión del usuario. Cuando el usuario salga del sistema o cierre su navegador, la cookie es eliminada. La mayoría de los navegadores ni siquiera escribirán esta cookie en el disco.
La cookie se almacena en el equipo del usuario y es equivalente a su contraseña (pero no su contraseña REAL). Esta cookie es necesaria para la caracerística de auto-login. La cookie dura un maximo de 30 días y solo puede ser usada desde la misma dirección IP.
Las preferencias de color del usuario son almacenadas en cookies en su navegador. Esta información no es delicada, así que se almacena indefinidamente.
Toda la información del usuario es almacenada en archivos en sus computadoras.
Lista de Pendientes de Mecanismos de Persistencia¶
Expresividad: ¿hasta qué punto se ha logrado esto?
2-4 ORACIONES
Facilidad de acceso: ¿hasta qué punto se ha logrado esto?
2-4 ORACIONES
Confiabilidad: ¿hasta qué punto se ha logrado esto?
2-4 ORACIONES
Capacidad: ¿hasta qué punto se ha logrado esto?
2-4 ORACIONES
Seguridad: ¿hasta qué punto se ha logrado esto?
2-4 ORACIONES
Desempeño: ¿hasta qué punto se ha logrado esto?
2-4 ORACIONES
Interoperabilidad: ¿hasta qué punto se ha logrado esto?
2-4 ORACIONES