erDiagram
HECHO_EVALUACION_ACADEMICA {
int id_estudiante
int id_asignatura
int id_tiempo
decimal calificacion
int creditos
int indicador_reprobado
}
7 Modelado Multidimensional
El modelado multidimensional constituye la base conceptual de los almacenes de datos (Data Warehouses, DW). A diferencia del modelo relacional tradicional altamente normalizado (diseñado para sistemas transaccionales (OLTP) donde predominan inserciones y actualizaciones frecuentes) el modelo multidimensional está optimizado para el análisis (OLAP), es decir, para responder preguntas complejas de negocio de manera rápida, clara y comprensible para los usuarios finales.
Como se enfatiza en el material del curso, el diseño de un DW no comienza por la base de datos ni por la tecnología, sino por las decisiones que el negocio desea tomar y la información necesaria para sustentarlas. El modelo se construye entonces alrededor de preguntas analíticas, no alrededor de procesos operativos.
A diferencia del modelo relacional normalizado, aquí se utilizan estructuras optimizadas para consultas complejas:
- Tabla de Hechos (Fact Table): Contiene las métricas cuantitativas o medidas del negocio.
- Tablas de Dimensiones: Contienen los atributos descriptivos que contextualizan los hechos (Tiempo, Geografía, Producto, Estudiante, etc.).
7.1 Hechos y Dimensiones
Un hecho representa un evento medible del negocio. Debe cumplir tres características fundamentales: ocurre en un momento específico, se puede medir y sucede repetidamente. En lugar de describirlo solo de forma conceptual, puede entenderse mejor mediante una representación estructural.
A continuación se muestra un ejemplo de una tabla de hechos académica, donde cada fila representa la evaluación de un estudiante en una asignatura durante un periodo determinado.
En esta tabla:
- Cada registro corresponde a un evento académico concreto.
- Las columnas
calificacion,creditoseindicador_reprobadoson medidas. - Las claves (
id_estudiante,id_asignatura,id_tiempo) conectan el hecho con su contexto.
Las dimensiones proporcionan precisamente ese contexto. Permiten responder preguntas como: ¿quién?, ¿cuándo?, ¿dónde? y ¿qué? ocurrió el evento.
A continuación se muestra una representación simplificada de algunas dimensiones académicas:
erDiagram
DIMENSION_ESTUDIANTE {
int id_estudiante
string nombre
string sexo
int generacion
string carrera
string facultad
}
DIMENSION_TIEMPO {
int id_tiempo
int semestre
int anio
string periodo
}
DIMENSION_ASIGNATURA {
int id_asignatura
string nombre_asignatura
string tipo
}
El hecho adquiere significado únicamente cuando se conecta con estas dimensiones. Conceptualmente, la relación puede representarse así:
erDiagram
HECHO_EVALUACION_ACADEMICA }o--|| DIMENSION_ESTUDIANTE : pertenece_a
HECHO_EVALUACION_ACADEMICA }o--|| DIMENSION_TIEMPO : ocurre_en
HECHO_EVALUACION_ACADEMICA }o--|| DIMENSION_ASIGNATURA : corresponde_a
De esta forma, una fila del hecho puede interpretarse como:
“El estudiante X cursó la asignatura Y en el periodo Z y obtuvo determinada calificación”.
Un hecho aislado es poco informativo; adquiere significado al conectarse con dimensiones. Esta relación también guía el diseño del modelo: si una medida no puede explicarse adecuadamente con las dimensiones disponibles, suele indicar que falta una dimensión relevante, como campus, plan de estudios, modalidad o grupo.
7.2 Granularidad: la decisión de diseño más importante
La granularidad define qué representa exactamente una fila en la tabla de hechos.
Impacta directamente el volumen de datos, el costo de infraestructura, la complejidad del ETL y el tipo de análisis que puede realizarse.
7.2.1 Comparación de niveles de granularidad
erDiagram
HECHO_TRAYECTORIA_SEMESTRAL {
int id_estudiante
int id_tiempo
int total_materias
int total_creditos
decimal promedio_semestre
}
HECHO_EVALUACION_ACADEMICA {
int id_estudiante
int id_asignatura
int id_tiempo
decimal calificacion
int creditos
int indicador_reprobado
}
Izquierda: Granularidad baja — una fila por alumno por semestre.
Cada registro resume el desempeño global del estudiante en un periodo.
No se almacenan materias individuales, sino resultados agregados del semestre.
Con 200 alumnos y 2 semestres por año se generan aproximadamente 400 filas por año (2,000 en cinco años).
Este enfoque reduce volumen y complejidad, pero limita el análisis detallado por asignatura o profesor.
Derecha: Granularidad alta — una fila por alumno por materia por semestre.
Cada registro representa una inscripción específica en una asignatura.
Permite analizar reprobación por materia, desempeño por docente y evolución por plan de estudios.
Con 200 alumnos, 6 materias promedio y 2 semestres por año se generan aproximadamente 4,800 filas por año (24,000 en cinco años).
Este enfoque aumenta capacidad analítica, pero también volumen, costo y complejidad operativa.
7.2.2 Hecho aditivo
Un hecho es aditivo cuando puede sumarse correctamente a través de todas las dimensiones del modelo (incluida la dimensión tiempo). En el material del curso se menciona como ejemplos típicos: número de inscritos, créditos inscritos y número de reprobados.
Ejemplos claros:
- Ventas: sumar “monto vendido” por día, por tienda, por producto, por ciudad. La suma conserva sentido en cualquier nivel de agregación.
- Académico: sumar “créditos inscritos” por estudiante, por carrera, por semestre o por año; y sumar “indicador_reprobado” (0/1) para obtener el total de reprobados en un conjunto dado (por asignatura, periodo, generación, etc.).
Implicación de diseño: si una medida es aditiva, suele ser una buena candidata para almacenarse directamente en la tabla de hechos, porque habilita muchas consultas rápidas y robustas.
7.2.3 Hecho semi-aditivo
Un hecho es semi-aditivo cuando puede sumarse en algunas dimensiones, pero no en todas; típicamente no se suma válidamente a través del tiempo. En el material se ejemplifica con “estudiantes activos al finalizar semestre” o “créditos acumulados”.
Ejemplo:
- “Estudiantes activos” por carrera en un mismo semestre: sumar por carrera para obtener el total de activos en ese semestre puede tener sentido (si las carreras son particiones disjuntas).
- “Estudiantes activos” entre semestres: sumar activos del semestre 1 más activos del semestre 2 suele perder interpretación porque muchas personas se repiten; el resultado puede inflarse y no representa una entidad real.
Implicación de diseño: medidas semi-aditivas a menudo se consultan con funciones como MAX, MIN o “valor al cierre del periodo”, o bien se modelan como “snapshots” (cortes periódicos), dependiendo del caso.
7.2.4 Hecho no aditivo
Un hecho es no aditivo cuando no puede sumarse en ninguna dimensión; requiere cálculo (promedio, razón, porcentaje). En el curso se mencionan: promedio de calificaciones, tasa de reprobación y porcentaje de deserción.
Ejemplo:
- La tasa de reprobación se calcula como (reprobados / inscritos) bajo un filtro o un grupo; no se almacena como tal en la tabla de hechos porque debe recomponerse según el contexto de la consulta.
- El promedio de calificaciones depende de la población (y a veces de ponderaciones). “Sumar promedios” rara vez es significativo.
Implicación de diseño: en general se almacenan los componentes base (numeradores/denominadores, conteos, sumas) y se calculan métricas derivadas en la capa semántica o en vistas/consultas.
7.4 Conclusión
El modelado multidimensional organiza los datos alrededor de hechos medibles y dimensiones descriptivas, priorizando claridad y desempeño para análisis. Para que el diseño sea correcto, debe fijarse adecuadamente la granularidad y entender la aditividad de las medidas, ya que esto determina qué agregaciones son válidas y qué métricas deben calcularse.