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 STARSNOWFLAKE

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