• Múltiples diagnósticos • Varios titulares cuentas bancarias
Anuncio
Relaciones n-m entre tablas de hechos y dimensiones Ejemplos • • • Múltiples diagnósticos Varios titulares cuentas bancarias Múltiples propietarios Qué hacer • • • Insertar tabla puente entre hechos y dimensiones Generar llave foránea generalizada en tabla de hechos Llave generalizada almacena varios valores reales Tablas puente: estructura Cada registro contiene • una llave que agrupa valores posibles (registrada en tabla de hechos) • una llave individual, llave foránea de la dimensión • Valor de ponderación cuya suma en cada grupo de llaves integrando una llave de grupo sea 1 Relaciones n-m Dimensión diagnóstico Clave_diagnóstico Atributo 1 .... Atributo n Tabla de puente Clave_grupo_diagnostico Clave diagnóstico Factor_ponderación Tabla de hechos Cod_Fecha Cod_paciente Cod_grupo_diag .... costo Consultas • • • Resúmen de gastos generados por diagnóstico (registrado en tabla de hechos) De tabla puente se obtiene ponderación de diagnósticos individuales Valor individual calculado con base en ponderacion y dato almacenado en hechos Dimensiones cambian en el tiempo • • • Dimensiones pueden adicionar registros Cómo manejar cambios en registros existentes? Que pasa si una dimensión crece? Cambios lentos en dimensiones • • • Valores de algún atributo cambian para algunos registros Importante registrar esos cambios en dwh Alternativas de solución? • .. • .. Dimensiones cambiantes: tipos 1. 2. 3. Reescribir registro con nuevos valores Pérdida de historia Crear registro con nuevo valor de llave para el mismo objeto de la bd operacional Crear atributo “antiguo” en registro para almacenar valor anterior Tipo 1 y 2 • • • • • Utilizado cuando atributo que cambia no es significativo. (posibilidad de eliminarlo) Ejemplos: correcciones de errores Apropiado para llevar control de cambios en dimensiones. Fechas de vigencia de valor, no significativas en tabla de hechos Si hay mas de un cambio dificultad de interpretación Tipo 2 • • • • Ventajas de las llaves ficticias en este caso Posibilidad de almacenar cambios en una entidad( igual llave operacional) creando llave ficticia cuando se producen cambios Ejemplo: clientes con atributos (profesión, estado civil, número de hijos,..etc.) Valores pueden cambiar en la historia de cliente Tipo 2 • • • • • Cliente con identificación 4.555.890 vinculado inicialmente como estudiante Datos: soltero , 0 hijos Cambios en datos del cliente podrían cambiar hábitos de compra Importante registrarlos Mediante cédula acceso a historia Tipo 3 • • • • • Utilizado cuando el cambio no implica cambio en la historia Cambios “suaves” Se podría “ignorar” Ejemplo: cambio en la categoría de un producto Posibilidad de escoger la categoria deseada Dimensiones muy grandes • • • • • • Dwh muy detallados – dimensiones grandes clientes: millones de registros Personas en ISS Propio de entidades públicas Impuestos (renta), censo Necesidad de indexación y diseño Dimensiones grandes • • • • Soporte al acceso sin criterio de selección para atributos de baja cardinalidad Soporte a lectura eficiente de dimensión Eliminen entradas repetidas Tareas del gestor de bases de datos disponible Dimensiones grandes cambiando rápidamente • • • • Dividir tablas de dimensión entre atributos que cambian y no cambian Tabla de hechos tendra 2 referencias Ejemplo: datos de cliente de no cambian ( nombre, fecha de nacimiento,...) y datos demográficos ( sueldo, estado civil, # hijos...) Necesidad de discretizar sueldos por rangos Separación dimensión Tabla de cliente Clave_grupo_diagnóstico Clave diagnóstico Factor_ponderación Dimensión demografía Clave_demografia Banda_sueldo Banda_hijos .... Atributo n Tabla de hechos Cod_Fecha Cod_cliente Cod_demografia .... .... Limitaciones • • • Una vez definida discretización no se puede cambiar Necesidad de limitar número de valores para que dimensión no crezca demasiado Datos separados
