Estimados especialistas en base de datos, Ha llegado el momento de presentar el trabajo logrado durante estos meses, el trabajo será presentado en grupo y deberá seguir las siguientes pautas: - El tiempo para cada grupo será de 20 minutos para presentación y 10 minutos de preguntas. - Todos vamos a ver las presentaciones, se sorteará el orden de grupos (ruleta). - Cada grupo deberá cargar en su respectiva URL para ver el demo, BBDD, etc. online (los datos de acceso al servidor se enviarán a cada grupo por teams). - Para la presentación podrán usar un documento de texto con el código SQL a emplear para solventar algo (consulta, transacción, etc.); es decir, no deberán escribir en ese momento. - Para la sustentación de las preguntas, el grupo podrá contar con recursos adicionales, PPT, fotos, gráficos, imágenes de tal manera que logre solventar la pregunta que se le asigne. - Carguen todo el trabajo archivos php + scripts.sql dentro de un repositorio de github, agreguen un documento "Readme" con indicaciones que permita la reproducibilidad de lo que han hecho, es decir, que cualquier otra persona pueda usar su código y sepa lo que hace y cómo usarlo. - Dentro de este github también deberán cargar los informes, vídeos, presentaciones y demás archivos o recursos elaborados en entregas previas, estos archivos deberán ser mencionados en el Readme en una sección denominada "Descripción del desarrollo de este proyecto", la idea es: explicar a quien visite sus proyectos (futuros estudiantes de la asignatura) la manera en que ustedes avanzaron en su construcción y que sea el ejemplo que podrían mejorar (sí, ustedes serán el ejemplo de otros estudiantes). # ¿Qué debe incluir la **presentación final**? 1. Pitch (1–3 min): aplicación, problema, usuarios, mejora propuesta del fork y criterios éticos/seguridad/técnicos/. 2. Arquitectura y datos (4-5 min): esquema relacional de la BBDD, el proceso empleado para establecer ese modelo, sus entidades, características, relaciones, etc; decisiones de normalización; constraints clave; mapeo con reglas de negocio. 3. DDL y DML empleado (3-5 min): Usando el código (script) empleado para montar/defiinir el diseño de la base de datos (DDL) así como el código para cargar/manipular datos (DML) en la BBDD, se deberá explicar al menos 2 chunk o bloques de código que consideren importantes. 4. Demo técnica (4–5 min): Explicar cómo ha sido el proceso de cargar el proyecto al servidor, presentar el uso de la interfaz gráfica para ejecutar en la que se ejecute: 1 consulta, 1 transacción y 1 trigger; aquí consideren que no necesariamente deben de estar estos elementos por separados, es decir, se podrían combinar. Se deberá ejecutar el demo, explicar lo con ayuda del código empleado (tanto de SQL como php). 5. Mensaje de cierre (2-3 min): Considerando el resultado de aprendizaje del curso: Aplicar el diseño de Ingeniería Informática para producir soluciones que satisfagan las necesidades específicas, teniendo en cuenta la salud pública, la seguridad y el bienestar, así como factores globales, culturales, sociales, ambientales y económicos. Describa la manera en que con su grupo han logrado alcanzar este resultado de aprendizaje. # Preguntas a responder De las siguientes preguntas, cada grupo responderá 3 por sorteo: - **Dependencia transitiva.** Explica qué es, **dónde aparece** en tu modelo (fragmento E-R) y **cómo la resolviste**. - **Relación N:M.** Señala una relación N:M real, **qué atributos propios** tenía, y **cómo la convertiste** a tabla puente. - **Llave natural vs. surrogate.** Elige una entidad central y justifica si usaste **llave natural** o **surrogate** (`id`). ¿Por qué? - **Regla de negocio → constraint.** Toma una regla (“no duplicar X”, “rango válido”, “fecha no futura”) y explica cómo la has solventado en tu proyecto (**UNIQUE / CHECK / FK**). - **Cardinalidad 1:N u opcionalidad.** Muestra una relación 1:N y explica la **participación** (total/parcial). ¿Qué se debería hacer si era opcional? - **Vista para consulta recurrente.** Muestra una consulta que el usuario pide a menudo y su respectivo **VIEW**. ¿Qué columnas expone y por qué? - **Trigger pequeño y útil.** Muestra un **trigger** que registre un cambio (auditoría mínima o cálculo derivado simple). - **Valores nulos con intención.** Señala una columna donde permitiste `NULL`. ¿Qué **significa** ese `NULL` en tu negocio? - **Integridad referencial al borrar.** Explica una decisión de `ON DELETE` (**CASCADE / RESTRICT / SET NULL**) y por qué elegiste esa. # Rúbrica de evaluación | Dimensión (peso) | Excelente (4) | Avanzado (3) | Básico (2) | Insuficiente (1) | | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | **1) Arquitectura y datos** (25 pts) _(E-R, relacional, normalización, constraints; mapeo a reglas de negocio)_ | **Diagrama E-R y esquema relacional** claros, completos y consistentes; **N:M** resueltas con tabla puente y atributos; **3FN/BCNF** justificada; **constraints** (PK/FK/UNIQUE/CHECK) mapeados explícitamente. | Modelo mayormente correcto; alguna cardinalidad/participación poco justificada; normalización hasta 3FN con pequeñas lagunas; mapeo reglas→constraints parcial pero entendible. | Modelo funcional pero con **inconsistencias** (p. ej., cardinalidades u opcionalidad); normalización incompleta o sin DFs; pocos constraints o mal elegidos. | Modelo confuso o contradictorio; no se evidencia normalización; constraints ausentes o incorrectos; no hay trazabilidad con reglas. | | **2) DDL/DML explicado** (20 pts) _(2 “chunks” de código significativos; orden de scripts; calidad de dominios y nombres)_ | Presentan **2 bloques de código clave** (p. ej., tabla puente con `UNIQUE`, CHECKs y `ON DELETE`; carga transaccional) con **lenguaje técnico** sólido; **naming** y dominios consistentes; orden `/sql` impecable. | Muestran 2 bloques relevantes con explicación suficiente; algún detalle menor de naming/domino/orden mejorable. | Bloques elegidos poco representativos o explicación superficial; orden de scripts confunde; dominios genéricos. | No explican el código o es incorrecto; scripts desordenados; errores de sintaxis o de integridad. | | **3) Demo técnica** (20 pts) _(1 consulta + 1 transacción + 1 trigger; servidor/interfaz; plan/índice)_ | Demo fluida en **servidor/interfaz**: consulta responde caso real, transacción **atomiza** cambios, trigger **evidencia** la regla (log/validación); muestran **EXPLAIN/índice** alineado. Plan B listo. | Demo completa pero con pequeños tropiezos; evidencia del trigger o del índice menos clara. | Se ejecutan partes por separado; la evidencia del trigger o de la transacción es insuficiente; sin plan/índice. | No se logra ejecutar la demo o no corresponde al modelo; sin elementos requeridos. | | **4) Preguntas sorteadas** (15 pts) _(3 preguntas; análisis y evidencia)_ | Responden **las 3 preguntas** con **análisis** y **evidencia** (mini-ER, DDL, EXPLAIN, prueba); soluciones coherentes con su diseño. | Responden 3 con buena lógica y alguna evidencia; pequeños vacíos técnicos. | Responden parcialmente (2/3) o sin evidencia; definiciones vagas. | No responden o responden sin sustento técnico. | | **5) Comunicación, ética y reproducibilidad** (20 pts) _(pitch/cierre; README/scripts; seguridad)_ | **Pitch** claro (problema-usuarios-mejora); **cierre** conecta con Resultado de Aprendizaje (ética, seguridad, impacto); Tiene GitHub con **README** reproducible (pasos, versiones, orden de scripts). | Buena comunicación; README suficiente pero con lagunas menores. | Mensaje disperso; README incompleto (cuesta replicar); seguridad apenas mencionada. | Comunicación confusa; sin README/orden; exponen credenciales/PII o no consideran seguridad. | Excelente = 100% del peso • Avanzado = 85% • Básico = 70% • Insuficiente = 40% del peso.