Modelado de datos La pregunta central De qu

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

Modelo dimensional DIMENSIONES - Jerarquía

Modelo dimensional DIMENSIONES : 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

Snow. Flake

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