Post on 23-Jan-2016
Modelado de datos
La pregunta central
¿De qué modo deben diseñarse las bases de datos que conforman un Data Warehouse para soportar eficientemente los requerimientos de los usuarios?
¿Por qué es importante?
• Visualización del universo del negocio
• Modelo de abstracción de las “preguntas” que los usuarios necesitan responder
• Diseño del plan de implantación del Data Warehouse
Dos técnicas
Modelo E-R
– Entidades
– Atributos
– Relaciones
Modelo dimensional
– Hechos
– Dimensiones
– Medidas
Modelo E-R
Modelo dimensional: HECHOS
• Hechos : colección de items de datos y datos de contexto. Cada hecho representa un item de negocio, una transacción o un evento
• Los hechos se registran en las tablas CENTRALES del DW
Modelo dimensional: DIMENSION
• Una dimensión es una colección de miembros o unidades o individuos del mismo tipo
• Cada punto de entrada de la tabla de HECHOS está conectado a una DIMENSION
• Determinan el contexto de los HECHOS
Modelo dimensional: DIMENSIONES
• Se utilizan como parámetros para los análisis OLAP
• Dimensiones habituales son:– Tiempo– Geografía– Cliente– Vendedor
Modelo dimensional:DIMENSIONES - Miembros
Dimensión MiembroTiempo Meses, Trimestre, AñosGeografía País, Región, CiudadCliente Id ClienteVendedor Id Vendedor
Modelo dimensionalDIMENSIONES - Jerarquía
Modelo dimensionalDIMENSIONES : Medidas
• Medida : es un atributo numérico de un hecho que representa la performance o comportamiento del negocio relativo a la dimensión
• Ejemplos:– Ventas en $$– Cantidad de productos– Total de transacciones, etc.
Visualización de un modelo dimensional
DW - OLAP
El modelo dimensional es ideal para soportar las 4 operaciones básicas de la tecnología OLAP:
– Relacionadas con la granularidad: ROLL UP - DRILL DOWN
– Navegación por las dimensiones : SLICE - DICE
Drill Down - Roll Up
Slice and Dice
Modelos básicos dimensionales
STAR SNOWFLAKE
Star
SnowFlake
E-R - Modelo dimensional
• El modelo dimensional puede verse como un caso particular del modelo de ER
• Foreing keys Dimension
• Hecho Entidad
Datawarehousing process
Manage the Project
• Es un proceso cíclico e iterativo
• Refiere al manejo del PROYECTO, no al manejo del Warehouse (ONGOING)
Define the project
• ¿Qué se necesita analizar y por qué?¿Cuál es el alcance del proyecto?
• El contexto de definición y los alcances del proyecto DEBEN permitir FLEXIBILIDAD. NO deben ser demasiado específicos.
Requirements gathering
• Quién (personas, grupos, usuarios, etc)• Qué (se quiere analizar)• Por qué• Cuándo (factores de oportunidad en el tiempo)• Dónde (factores geográficos) • Cómo definir las medidas
Source driven
• Los requerimientos se definen utilizando las fuentes de datos operacionales.
• La mayor ventaja es que de antemano se conoce que todos los datos podrán ser provistos ya que se sabe qué está disponible
Source driven
• Se minimiza el tiempo de interacción con los usuarios en las primeras etapas (se gana velocidad).
• El riesgo es producir un conjunto incorrecto de requerimientos por la poca participación del usuario
• El usuario recibe “lo que tenemos”
User driven
• Los requerimientos se definen a partir de las necesidades del usuario.
• Conduce a proyectos más acotados pero probablemente más útiles
• Tiene como desventaja que al no limitarse el pedido del usuario pueden solicitarse objetivos imposibles
Relevamiento:Source driven vs User driven
Source driven - User driven
• Data Mart : User driven
• Global Data Warehouse : Source driven para partir el proyecto en áreas temáticas. Luego para cada área se utiliza un enfoque User driven