# Guía de trabajo en equipo — **02 Informe de BBDD E-R del proyecto (PDF)** ## ¿Qué deben entregar? **Informe de Diseño (PDF)** — evidencia de que el equipo pasó de **conceptual** a **lógico** y aplicó **normalización**. **Nombre de archivo:** `Equipo##_InformeDiseno_2025-08-15.pdf` **Dónde:** Canal de cadaequipo → carpeta **"Informe 2"** (Teams). ## Objetivo del informe 1. Consolidar el **modelo E-R** con cardinalidades; 2. **Mapear** E-R → esquema relacional (tablas, PK, FK); 3. **Normalizar** hasta **3FN**; 4. Definir **restricciones** e **índices** iniciales; 5. Dejar **diccionario de datos** base. > Debe trazarse con el Informe de inicio (semana 2): cada regla de negocio debe verse reflejada en entidades/relaciones o restricciones o en su defento agregarlas. ## Estructura obligatoria (6–8 páginas + anexos) 1. **Resumen y alcance actualizado** (½ pág.) - Qué cambió desde el Informe de inicio y por qué. 2. **Modelo E-R (conceptual)** (1–2 págs.) - Diagrama legible con **entidades, atributos clave, relaciones, cardinalidades** y participación (total/parcial). - Supuestos explícitos (p.ej., “un Student puede pertenecer a un solo Department”). 3. **Mapeo E-R → Relacional** (1–2 págs.) - Detalle de tablas: `Entidad/Relación | Tabla | Atributos | PK | FK | Observaciones (resolución N:M, participación, Otros detalles)` - Resolver relaciones **N:M** con **tablas puente** (clic aquí para más información). 4. **Normalización (1FN → 2FN → 3FN)** (2–3 págs.) - Para cada tabla **de partida**: - **DF** relevantes (dependencias funcionales) que justifican cada paso. - Evidencia breve de eliminación de **repetición, parcialidad y transitividad**. - Resultado final por tabla (en 3FN o BCNF) y nota si quedó una **PK compuesta**. 5. **Restricciones e Integridad** (½–1 pág.) - **PK**, **FK**, **UNIQUE**, **NOT NULL**, **CHECK** (ej.: límites de créditos, rangos de fechas). - Reglas de negocio mapeadas a restricciones (mini matriz: Regla → Tabla/Columna/Constraint). 6. **Índices iniciales (borrador)** (½ pág.) - ¿Qué columnas indexarías y por qué? (búsqueda por código, uniones frecuentes). 7. **Diccionario de datos (extracto)** (1 pág.) - Describe de tablas: - `Tabla | Atributo | Descripción | Dominio/Unidad | Null? | Observaciones`. - No necesitas fijar tipos de datos del motor; vale con dominios (entero, texto corto, fecha, booleano). **Anexos:** - Fuente del E-R (DrawDB). - Hojas de normalización (plantilla 1FN→3FN). - Cualquier nota de revisión del grupo. ## Rúbrica (25 pts) - **E-R correcto y legible** (entidades, relaciones, cardinalidades) – **8 pts** - **Mapeo E-R → relacional** (tablas, PK/FK bien resueltas, N:M) – **6 pts** - **Normalización hasta 3FN** (DFs claras, justificación) – **6 pts** - **Integridad & índices iniciales** (coherencia con reglas) – **3 pts** - **Diccionario y presentación** (claridad, trazabilidad con Informe de inicio) – **2 pts** ## Checklist antes de entregar - ( ) Todas las **relaciones N:M** pasan por **tabla puente**. - ( ) No hay **atributos multivaluados** sin resolver. - ( ) **PK** y **FK** están identificadas en **todas** las tablas. - ( ) Cada regla de negocio importante tiene **reflejo** en el esquema (constraint o diseño). - ( ) Hay **DF** por cada tabla que normalizaste y queda claro el paso a 3FN. - Diccionario de datos incluye **definiciones semánticas**, no solo nombres. ## Roles y dinámica - **Curador de entidades → Modelador lógico**: lidera E-R y mapeo. - **Cartógrafo funcional → Tester de integridad**: revisa cardinalidades y participación. - **Detective de negocio → Responsable de normalización**: redacta DFs y justifica 1FN→3FN. - **Historiador de usuarios**: valida que el diseño soporte los **flujos críticos**. - **Documentador**: integra todo, controla formato y trazabilidad con el informe anterior. ## Errores comunes a evitar - Llamar “ID” distinto en cada tabla sin convención (usa prefijos: `student_id`, `course_id`). - Confundir 1:N con N:M (si un estudiante puede inscribirse en muchos cursos **y** un curso tiene muchos estudiantes → **N:M**). - Mantener atributos calculados/derivados sin justificación (p.ej., `total_credits` almacenado). - Dejar **nullable** campos que deberían ser **NOT NULL** según la regla de negocio. ## Herramientas recomendadas - **E-R**: DrawDB - **Normalización**: hoja de trabajo (1FN→3FN) con tablas.