datawarehouse

Marta [email protected]/materias

Ejemplo

Hechos

� Los hechos son transacciones que han ocurrido en algún punto en el pasado, y que es muy poco probable que cambien en el futuro

� Los hechos se pueden analizar de diferentes formas dependiendo de la información de referencia

� Los hechos suelen tener pocos atributos, puesto que no tiene datos operacionales

Dimensiones

� Sirven para representar cada uno de los factores por los que se puede analizar un determinado área de negocio

� Son tablas siempre más pequeñas� A menudo se desnormalizan

día mes

clave_día

clave_mesclave_mes

mes

día

clave_día

clave_mes

mes

Hechos y dimensiones

Ventas

July 2001

M T W T F S S

1

2 3 4 5 6 7 8

9 10 11 12 13 14 15

16 17 18 19 20 21 22

23 24 25 26 27 28 29

30 31

PcPortátil

Ratón

FaxTeléfono

Sucursales

Productos

Clientes

Fecha

Diagramas en estrella

Producto Cliente

Fecha Sucursal

Ventas Tabla de hechos

Tablas de dimensión

Datos multidimensionales

Ventas totales de television en T1.Fecha

Produ

cto

Tie

ndasuma

sumaTV

VCRPC

1Qtr 2Qtr 3Qtr 4Qtr

T1

T2

T3

suma

Diseño STAR: pasos a seguir

� De diagrama E/R surgen múltiples diagramas en estrella

� Separar en procesos discretos de negocio (hechos) y modelar cada hecho

� Seleccionar relaciones n:m con atributos numéricos

� Desnormalizar las tablas de dimensión

Diseño STAR: pasos a seguir

A BR

C

S

D

T E

R

A B

C Fecha

Diagrama E/R Diagrama enestrella

Diseño de la tabla de hechos

� Decidir la granularidad de la tabla de hechos� Establece lo que significa cada registro de la

tabla de hechos� Decidir las dimensiones� Decidir los hechos de la tabla de hechos

� Deben ser específicos para la granularidad seleccionada para la tabla de hechos

Diseño de la tabla de hechos

� Identificar el periodo histórico significativo para los distintos procesos y el grado de detalle requerido

� Eliminar todas las columnas del hecho que no sean requeridas para responder a preguntas de toma de decisiones

� Ajustar el tamaño de cada columna� Usar claves generadas

Claves primarias y extranjeras

� Todas las claves que se utilicen en tablas del Data Warehouse deben ser claves sin significado

� Nunca se deben usar claves de producción� Facilitar los cambios� Situaciones “no lo se”, “desconocido”� Dimensiones que cambian en el tiempo

Aditividad

� Siempre que sea posible, los hechos de la tabla de hechos deberían elegirse para que sean perfectamente aditivos (se pueden sumar por cualquier dimensión)

� Las medidas de actividad son generalmente aditivas

� Las medidas de intensidad no siempre lo son (niveles de inventario, balance de cuentas...)

Análisis de aditividad

Cod_Fecha

Cod_Sucursal

Cod_Producto

Cod_Cliente

Unidades

Fecha

Cliente

Ventas

producto

Sucursal

Cantidad aditiva

Fechaproducto

Almacén

Cod_Fecha

Cod_Almacén

Cod_Producto

Stock

Almacenes

Cantidad NO aditiva

Diseño de las dimensiones

� Son tablas más pequeñas� Desnormalizar si se acceden muy a menudo en las

consultas para acelerar el desempeño (Esquemas estrella)

� Establecer la política para dimensiones cambiantes� Actualizar los cambios� Atributos valor antiguo – valor nuevo� Generar un nuevo código para el nuevo valor

Normalización de dimensiones

� Se dice que una dimensión está “snowflaked”cuando los atributos de baja cardinalidad se llevan a tablas separadas

� Generalmente no se recomienda� A veces se usa para ahorrar espacio de

almacenamiento� No permite hacer uso de los índices de bitmap� Sin embargo existen situaciones (datos

demográficos) en las que son aconsejables

Diseñar las tablas dimensión

ProductoClave_productoSKUDescripcionClave_marca_comercialClave_marca_financieraClave_tipo_embalajeTamañoClave_saborAlturaCantidad_por_caja

MarketingClave_marca_comercialMarca_comercialClave_categoria_comercial

FinanzasClave_marca_financieraMarca_financieraClave_categoria_financiera

EmbalajesClave_tipo_embalajeTipo_embalaje

SaboresClave_saborSabor

Categorias comercialesClave_categoria_comercialCategoria_comercial

Categorias financierasClave_categoria_financieraCategoria_financiera


ProductoClave_productoSKUDescripciónClave_marca_comercialClave_marca_financieraClave_tipo_embalajeTamañoClave_saborAlturaCantidad_por_cajaCategoria_comercialCategoria_financieraMarca_financieraMarca_comercialTipo_embalajeSabor

Tabla de hechosClave_producto


ClienteClave cliente (PK)ID_clienteNombreDirecciónCiudadDepartamentoFecha primera compraScore de compraScore de crédito

Subdimensión demográficaDepartamentoNúmero de segmentoNombre del segmetoContador del segmentoPorcentaje del segmentoRanking del segmento

VentasClave_clienteClave_producto

Un esquema en estrella

VentasCod_FechaClave_ClienteClave_SucursalClave_Productounidadesprecio_unidadticket

FechasCódigoSysdateDíaMesdía_semana___

SucursalClaveDirecciónSegmentoDescripción

ProductoClave_productoSKUDescripciónClave_marca_comercialClave_marca_financieraClave_tipo_embalajeTamañoClave_saborAlturaCantidad_por_cajaCategoria_comercialCategoria_financieraMarca_financieraMarca_comercialTipo_embalajeSabor

ClienteClave cliente (PK)ID_clienteNombreDirecciónCiudadDepartamentoFecha primera compraScore de compraScore de crédito

Subdimensión demográficaDepartamentoNúmero de segmentoNombre del segmentoContador del segmentoPorcentaje del segmentoRanking del segmento

La importancia de los atributos

� La calidad del Data Warehouse se mide por la calidad de los atributos� Descriptivos� Completos (sin valores nulos)� Indexados� Palabras enteras� Documentados (metadatos)� Calidad asegurada

Tabla de fechas

FechaCodigoDíaDía semana (numero)Dia semana (nombre)FestivoMes (numero)Mes (nombre)Fin de semanaDia antes fin de semana....

Sucesos climaticosCodigo_FechaCodigo de sucesoNombre de suceso

Fiestas nacionalesCodigo_FechaCodigo de fiestaNombre fiesta

Fiestas locales Codigo_FechaCodigo de fiestaNombre fiesta

Sucesos politicosCodigo_FechaCodigo de sucesoNombre de suceso

Dimensión “degenerada”

� La mayoría de los diseños multidimensionales están alrededor de un documento de control: número de pedido, factura, ticket, ...

� Generalmente son contenedores de más de un producto

� Generalmente en estos casos la granularidad de la tabla la marca este número

� ¿Qué se hace con los números?� Se ponen en las tablas pero no tienen una dimensión

con la que hacer “join”

Aplicación de dimensiones “degeneradas ”

VentasCod_FechaCod_ClienteCod_SucursalCod_Productounidadesprecio_unidadticket

ClienteCodigoNombreSexoCluster___

FechasCodigoSysdateDíaMesdía_semana___

ProductoCodigoDescripcióntiposección

SucursalCodigoDirecciónSegmentoDescripcion

Dimensión degenerada

Dimensión “Cajón desastre”

� En ocasiones se tienen atributos textuales y “flags” de distinta naturaleza que no parecen organizarse de manera coherente

� La solución no parece sencilla• Dejar los atributos en la tabla de hechos• Hacer dimensiones separadas para cada atributo• Quitar directamente estos atributos

� La mejor solución es compactarlos todos en lo que se denomina una “junk dimension”

Aplicación de dimensión “junk"

GustosCodigoNiñosAscensorAlmohadaTipo_cama___

ClienteCodigoNombreFecha_nacimientoSexoTipo___

FechaCodigoDíaDía semanaFestivoMes___

SucesosCodigo_FechaSuceso Politico___

ReservasCod_ClienteCod_HabitacionCod_FechaReservaGustosdíascostedescuento

HabitacionCodigoPlantaSecciónTamaño

Cajón desastre

Tablas de hechos sin hechos

� Hay situaciones en las que se tiene en el diseño final una tabla de hechos sin hechos

� Son situaciones en las que interesa el suceso en sí

� Afluencia de público� Coberturas

Tablas de hechos sin hechos

Productos en promocionCod_FechaCod_promocionCod_producto"1"Producto

CodigoNombreTipo___

FechaCodigoDíaDía semanaFestivoMes___

PromocionCodigoTipoDiasDescripcion

Ejercicio a resolver

� Supónga un hospital en el se ha decidido construir un Data Warehouse para analizar

� Ocupación

� Tratamientos

� Diagnósticos

Pasos a seguir

� Estudiar el problema� Determinar los hechos fundamentales a estudiar� Para cada hecho

� Analizar la granularidad del hecho� Decidir las dimensiones

� Diseñar las dimensiones

Ocupación de camas

July 2001

S M T W T F S

1 2 3 4 5 6 7

8 9 10 11 12 13 14

15 16 17 18 19 20 21

22 23 24 25 26 27 28

29 30 31

OcupaciónPacientes

Camas

Fecha

Tratamientos

Tratamientos

July 2001

S M T W T F S

1 2 3 4 5 6 7

8 9 10 11 12 13 14

15 16 17 18 19 20 21

22 23 24 25 26 27 28

29 30 31

Pacientes

Médicos

Fecha

Tratamientos

Diagnósticos

July 2001

S M T W T F S

1 2 3 4 5 6 7

8 9 10 11 12 13 14

15 16 17 18 19 20 21

22 23 24 25 26 27 28

29 30 31

Pacientes

Doctores

Fecha

Diagnósticos

Diagnósticos

Tabla de ocupaciones

OcupaciónCod_FechaCod_camaCod_paciente"1"

PacienteCódigoNombreFecha_nacimientoSexoIdentificación___

FechaCódigoDíaDía semanaFestivoMes___

CamaCódigoPlantaSecciónEspecialidad

SucesosCódigo_FechaEpidemia___

Datos médicod

Tabla de diagnósticos

PacienteCódigoNombreFecha_nacimientoSexoFe___

MédicoCódigoLicenciaNombreFecha_nacimientoEspecialidad___

DiagnósticoCódigoNombreEspecialidadTipo

Diagnósticos_realizadosCod_MedicoCod_PacienteCod_DiagnósticoCod_FechaCod_IngresoCosto



SexoFecha de Grado...

Tabla de tratamientos

TratamientoCódigoNombrePresentaciónLaboratorioPosología

Flags_efectos_secundariosCódigoExitoProblemas gástricosInsomnioAlergia___

MédicoCódigoLicenciaNombreFecha_nacimientoEspecialidad___



Tratamientos_realizadosCod_MedicoCod_PacienteCod_FechaCod_TratamientoNIngresoCostoNúmero de díasDosis diariasCod_Junk

PacienteCódigoNombreFecha_nacimientoSexoFe___

datawarehouse

Engineering