En esta sesión, los estudiantes de Ingeniería de Sistemas analizarán un problema auténtico de gestión de información: una universidad necesita registrar estudiantes, asignaturas e inscripciones, pero su hoja de cálculo actual contiene datos repetidos, inconsistencias y dificultades para responder consultas. A partir de este caso, los estudiantes formularán una pregunta de investigación, analizarán una estructura de datos, identificarán problemas de dependencia y redundancia, propondrán un modelo relacional básico y comprobarán sus decisiones mediante consultas SQL.

La clase se desarrolla con la metodología de Aprendizaje Basado en Investigación. En lugar de recibir únicamente una explicación sobre bases de datos, los estudiantes observarán evidencia, plantearán hipótesis, consultarán fuentes técnicas primarias —como la documentación oficial de PostgreSQL— y contrastarán sus propuestas mediante ejemplos concretos. El trabajo permitirá relacionar conceptos como entidad, atributo, clave primaria, clave foránea, integridad referencial y normalización con sistemas que utilizan diariamente, como plataformas académicas, aplicaciones de comercio electrónico, bancos y servicios de streaming.

Al finalizar, cada equipo entregará una respuesta argumentada a su pregunta de investigación, acompañada de un esquema relacional y una consulta SQL breve. De esta manera, se integran competencias de análisis, modelado, búsqueda de información técnica, argumentación y validación de soluciones propias de la formación profesional en Ingeniería de Sistemas.

Objetivos de aprendizaje

• Formular una pregunta de investigación relacionada con la calidad y organización de los datos en un sistema relacional.
• Analizar una tabla con información académica para identificar redundancias, anomalías y posibles claves.
• Diseñar un esquema relacional básico con entidades, claves primarias y claves foráneas.
• Validar una propuesta de diseño mediante una consulta SQL y una fuente técnica primaria.
• Argumentar decisiones de modelado utilizando evidencia obtenida del caso y de documentación especializada.

Recursos requeridos

• Una computadora por pareja o por grupo de tres estudiantes, con acceso a Internet.
• Proyector y presentación breve del docente con el caso, la tabla inicial y las instrucciones.
• Hoja impresa del caso “Inscripciones universitarias” y de una tabla desnormalizada con 8 registros por equipo.
• Pizarra, marcadores y notas adhesivas de tres colores.
• Editor SQL en línea, como DB Fiddle, o instalación local de PostgreSQL con pgAdmin.
• Documentación oficial de PostgreSQL sobre restricciones de tabla: PostgreSQL Documentation: Constraints.
• Documentación oficial de PostgreSQL sobre consultas SELECT: PostgreSQL Documentation: SELECT.
• Plantilla digital o impresa para registrar: pregunta, evidencia, hipótesis, propuesta y conclusión.
• Rúbrica breve de evaluación y ticket de salida individual.

Requisitos previos

• Reconocer qué es un dato, un registro, un campo y una tabla.
• Distinguir, de manera introductoria, entre una base de datos y una hoja de cálculo.
• Conocer la estructura básica de una sentencia SQL SELECT, FROM y WHERE.
• Comprender operaciones básicas de conjuntos y relaciones entre elementos.
• Haber trabajado previamente con diagramas sencillos o representaciones gráficas de sistemas.
• Tener habilidades básicas para leer documentación técnica y registrar fuentes consultadas.

Actividades de aprendizaje

Fase de Inicio

Tiempo estimado: 10 minutos.

Propósito de la sesión

Docente: Explica: “Hoy investigaremos por qué una base de datos mal estructurada puede producir errores en un sistema universitario. No comenzaremos memorizando definiciones; observaremos evidencia, plantearemos una pregunta, consultaremos una fuente técnica y construiremos una solución verificable”. Presenta los objetivos y organiza a los estudiantes en grupos de tres: analista de datos, investigador de fuentes y relator. Los roles pueden rotarse durante la actividad.

Estudiantes: Escuchan el reto, identifican su rol y preparan la plantilla de investigación.

Activación de conocimientos previos y diagnóstico

El docente proyecta estos tres registros de una tabla llamada Inscripciones:

• 001 | Ana Pérez | Ingeniería de Sistemas | Bases de Datos | Docente: Luis Gómez
• 002 | Carlos Ruiz | Ingeniería de Sistemas | Bases de Datos | Docente: Luis Gómez
• 003 | Ana Pérez | Ingeniería de Sistemas | Redes | Docente: Marta Silva

Pregunta exactamente: “Si cambiamos el nombre del docente de Bases de Datos, ¿cuántas celdas tendríamos que modificar? ¿Qué podría ocurrir si olvidamos una? ¿Qué campo podría identificar de manera única cada inscripción?”

Estudiantes: Responden individualmente durante un minuto y luego comparan su respuesta con un compañero. El docente recoge tres respuestas en la pizarra sin corregirlas todavía. Esta actividad funciona como evaluación diagnóstica.

Motivación y contextualización

El docente plantea el reto profesional: “Una plataforma académica debe mostrar correctamente las asignaturas cursadas, los docentes y las calificaciones de miles de estudiantes. Si el diseño permite datos contradictorios, el problema no es solo visual: afecta reportes, matrículas y decisiones institucionales”. Pregunta: “¿En qué aplicaciones que utilizan diariamente sería grave que un mismo dato apareciera con valores diferentes?”

Estudiantes: Mencionan ejemplos como bancos, compras, redes sociales o plataformas educativas. El docente conecta sus respuestas con la necesidad de diseñar estructuras consistentes y anuncia que la investigación de la sesión responderá: “¿Cómo puede un diseño relacional básico reducir las anomalías de una tabla de inscripciones?”

Fase de Desarrollo

Tiempo estimado: 40 minutos.

Presentación investigativa del contenido: observar, preguntar y proponer

Tiempo: 8 minutos. Docente: Entrega a cada grupo una tabla desnormalizada con las columnas id_estudiante, nombre_estudiante, programa, id_asignatura, nombre_asignatura, docente, semestre, calificacion. Solicita que marquen con una nota amarilla los datos repetidos, con una azul los datos que podrían funcionar como identificadores y con una roja los posibles conflictos o anomalías. No define todavía todos los conceptos; pregunta: “¿Qué información depende del estudiante?, ¿qué información depende de la asignatura?, ¿qué información depende de la inscripción?”

Estudiantes: Observan los registros, subrayan patrones y formulan una primera explicación. El docente introduce, a partir de sus hallazgos, los conceptos de entidad, atributo, clave primaria, clave foránea, redundancia, anomalía de actualización e integridad referencial. Presenta la idea de separar Estudiantes, Asignaturas e Inscripciones, aclarando que se trata de una hipótesis de diseño que deberá validarse.

Actividad 1: Pregunta y evidencia

Tiempo: 10 minutos. Objetivo asociado: Formular una pregunta de investigación y analizar redundancias.

• Docente: Indica: “Escriban una pregunta que pueda responderse con la tabla y con una fuente técnica. Eviten preguntas demasiado amplias como ‘¿qué es una base de datos?’. Utilicen el formato: ¿Cómo influye __________ en __________ dentro del caso de inscripciones?”
• Estudiantes: En grupos, redactan una pregunta, identifican dos evidencias concretas de la tabla y escriben una hipótesis de una o dos frases.
• Preguntas guía del docente: “¿Qué dato se repite? ¿Qué modificación podría generar inconsistencia? ¿La clave propuesta identifica un estudiante, una asignatura o una inscripción?”
• Producto: Ficha con pregunta, hipótesis y dos evidencias numeradas.

Organización: grupos de tres. Rol docente: verifica que las preguntas sean investigables y orienta sin proporcionar la respuesta final.

Actividad 2: Consulta de fuente primaria y diseño relacional

Tiempo: 14 minutos. Objetivos asociados: Diseñar un esquema relacional y argumentar decisiones de modelado.

• Docente: Proporciona el enlace a la documentación oficial de PostgreSQL sobre restricciones y solicita localizar la definición o ejemplo relacionado con PRIMARY KEY y FOREIGN KEY. Indica: “Registren el nombre de la fuente, la sección consultada y una idea que respalde su diseño”.
• Estudiantes: Consultan la fuente, extraen una idea relevante y construyen en papel o en una pizarra digital tres tablas: Estudiantes, Asignaturas e Inscripciones.
• Estudiantes: Proponen atributos, subrayan la clave primaria de cada tabla y utilizan flechas para representar las claves foráneas. Deben justificar por qué Inscripciones necesita relacionar un estudiante con una asignatura.
• Docente: Pregunta: “¿Podría el nombre del estudiante ser una clave primaria? ¿Qué sucede si dos estudiantes tienen el mismo nombre? ¿Qué restricción impediría registrar una inscripción con un estudiante inexistente?”
• Producto: Esquema relacional anotado y registro de la evidencia documental.

Transición: El docente indica: “Ya tienen una propuesta basada en patrones y documentación. Ahora deben someterla a una prueba: una consulta que produzca información útil sin repetir innecesariamente los datos”.

Actividad 3: Validación mediante SQL y revisión entre pares

Tiempo: 8 minutos. Objetivos asociados: Validar el diseño y argumentar la solución.

• Docente: Entrega o proyecta esta consulta de referencia, adaptada al esquema propuesto: SELECT e.nombre, a.nombre_asignatura, i.calificacion FROM Estudiantes e JOIN Inscripciones i ON e.id_estudiante=i.id_estudiante JOIN Asignaturas a ON a.id_asignatura=i.id_asignatura WHERE i.semestre='2026-1';
• Estudiantes: Ejecutan la consulta en DB Fiddle o la revisan de forma manual si no hay conexión. Identifican qué tablas participan, qué campos conectan las tablas y qué resultado esperan obtener.
• Estudiantes: Intercambian su esquema con otro grupo y aplican una lista de cotejo: ¿cada tabla tiene una clave primaria?, ¿las relaciones están representadas?, ¿se evita repetir el nombre del docente o del estudiante sin necesidad?, ¿la consulta puede responder una pregunta del caso?
• Docente: Solicita que cada grupo registre una mejora recibida y una decisión que mantendría.

Producto: Consulta comentada, resultado esperado y revisión de pares.

Diferenciación y acompañamiento

Para quienes necesiten apoyo, el docente entrega una plantilla con las tres tablas parcialmente dibujadas, un glosario de cinco términos y tarjetas con las palabras “entidad”, “clave primaria” y “clave foránea”. También puede leer en voz alta el fragmento técnico seleccionado y permitir una explicación oral en lugar de una extensa redacción. Para quienes terminan antes, se propone el reto: “Incluyan la entidad Docentes y expliquen si la relación con Asignaturas es uno a uno o uno a muchos”. El docente realiza preguntas diferenciadas, observa la participación de los roles y verifica que la evidencia documental no sea una simple copia, sino una justificación aplicada al caso.

Fase de Cierre

Tiempo estimado: 10 minutos.

Síntesis colectiva

Tiempo: 4 minutos. El docente dibuja tres columnas en la pizarra: Problema observado, Decisión de diseño y Evidencia de validación. Cada grupo aporta una idea en una nota adhesiva. El docente organiza las respuestas y construye con el curso la cadena: redundancia o anomalía → separación en entidades relacionadas → claves y restricciones → consulta verificable.

Estudiantes: Presentan en treinta segundos la principal decisión de su equipo y explican qué evidencia la respalda.

Reflexión metacognitiva y retroalimentación

Tiempo: 4 minutos. Cada estudiante responde individualmente en el ticket de salida:

• “¿Qué anomalía concreta identificaste en la tabla original y cómo la resolvería tu esquema?”
• “¿Qué diferencia existe entre una clave primaria y una clave foránea en tu propuesta?”
• “¿Qué evidencia de la tabla, de la consulta SQL o de la documentación oficial respalda mejor tu conclusión?”

Docente: Revisa rápidamente dos productos, destaca aciertos y corrige errores frecuentes, como confundir una clave foránea con un atributo descriptivo o usar nombres como identificadores únicos. La retroalimentación se ofrece con el patrón: fortaleza observada, ajuste necesario y siguiente acción.

Transferencia y tarea

Tiempo: 2 minutos. El docente conecta la sesión con el diseño de bases de datos para sistemas reales: “La próxima etapa será transformar este esquema en instrucciones DDL y aplicar restricciones”. Como reto individual opcional o tarea breve, cada estudiante seleccionará una aplicación cotidiana, identificará tres posibles entidades y redactará una pregunta sobre cómo garantizar la consistencia de sus datos. Deberá incluir una fuente técnica oficial o un artículo académico y una justificación de cinco líneas.

Estrategia de evaluación

Tipo y momentos: La evaluación es diagnóstica durante el Inicio, formativa durante el Desarrollo y sumativa al finalizar el Cierre. En el minuto 6 del Inicio se revisan las respuestas sobre modificaciones y claves. En los minutos 18, 32 y 38 se observan la ficha de investigación, el esquema relacional y la validación SQL. En los minutos 46 a 50 se valora el producto final y el ticket de salida.

Criterios de evaluación

• Pregunta e hipótesis — Objetivo 1: Formula una pregunta delimitada, investigable y relacionada con la calidad de los datos; plantea una hipótesis coherente con el caso.
• Análisis de datos — Objetivo 2: Identifica correctamente al menos dos redundancias, anomalías o dependencias relevantes en la tabla inicial.
• Diseño relacional — Objetivo 3: Propone entidades pertinentes, claves primarias adecuadas y claves foráneas que representan las relaciones del caso.
• Validación técnica — Objetivo 4: Interpreta o ejecuta una consulta SQL que utiliza las relaciones del esquema y produce un resultado pertinente.
• Argumentación — Objetivo 5: Utiliza al menos una fuente primaria técnica y conecta su contenido con una decisión concreta de diseño.

Instrumentos sugeridos

• Lista de cotejo para la ficha de pregunta, hipótesis y evidencias.
• Rúbrica analítica de cuatro niveles para el esquema relacional, la consulta y la argumentación.
• Observación directa del trabajo colaborativo y de las preguntas formuladas por cada rol.
• Coevaluación entre grupos mediante la lista de cotejo.
• Autoevaluación individual mediante el ticket de salida.

Evidencias de aprendizaje

• Ficha grupal con pregunta de investigación, hipótesis y evidencias de la tabla.
• Esquema relacional con las tablas Estudiantes, Asignaturas e Inscripciones.
• Registro de la fuente primaria consultada y explicación de su pertinencia.
• Consulta SQL comentada o resultado esperado de la consulta.
• Ticket de salida individual con respuestas sobre anomalías, claves y respaldo de la conclusión.