Unidad 10: DATAWAREHOUSING y OLAP. Cátedra Bases de Datos

Transcripción

1 Unidad 10: DATAWAREHOUSING y OLAP Cátedra Bases de Datos

2 Introducción Dentro de una organización o empresa coexisten dos grupos diferentes de aplicaciones Aplicaciones Tradicionales Aplicaciones de Análisis Son el soporte para las transacciones del día a día (altas, bajas, modificaciones) Permiten analizar el negocio y dar soporte a la toma de decisiones Necesitan datos históricos 2

3 Introducción Bases de Datos Operacionales /Tradicionales /Transaccionales Proveen los datos Pueden proveer los datos Transacciones del día a día Aplicaciones de análisis que dan soporte a la toma de decisiones? Los datos provistos serían parciales y su acceso no sería eficiente 3

4 Introducción Detallando algunos problemas Aún pudiendo encontrar la información necesaria: Todos los datos necesarios no están on-line, deben rastrearse los backups correspondientes Los datos están esparcidos en distintas bases de datos, inclusive en otras fuentes (internas y/o externas) Altera el trabajo transaccional diario, deben postergarse a horarios sin carga de trabajo Los tiempos de respuestas no son los esperados La estructura de los datos está pensada para dar soporte a tareas transaccionales 4

5 Introducción Solución: Recoger los datos en un sistema separado y específico (datos históricos) Datawarehouse Almacén de Datos Bodegas de Datos Información precisa y en un tiempo razonable 5

6 Introducción Datos Tradicionales Datos Datawarehouse objetivo de explotación diferente BD orientadas al proceso BD orientadas al análisis OLTP (On Line Transaction Processing) OLAP (On Line Analytic Processing) 6

7 Introducción OLTP vs OLAP Datos dinámicos y de detalle Muchos usuarios (administrativos) Gran cantidad de transacciones concurrentes Orientado a los procesos de la organización Datos estáticos (históricos),detalle y de resumen Pocos usuarios (estratégicos) Baja o media cantidad de transacciones Orientado al análisis de datos 7

8 Introducción: Concepto En esta área existen discrepancias en muchos aspectos, inclusive en el concepto mismo. 8

9 Concepto - Inmon - "Un datawarehouse es una colección de datos orientados a temas integrados (provenientes de diversas fuentes), no-volátiles, variante en el tiempo, organizados para soportar necesidades empresariales" 9

10 Concepto Orientado a temas (a diferencia de orientados a los procesos) Ejemplo Compañía de Seguros: clientes políticas Producción Cobranzas premios demandas 10

11 Concepto Integrado 11

12 Concepto Problemas relativos a la integración: Codificación diferente 12

13 Concepto Problemas relativos a la integración: Diferentes Unidades de Medida o Aplicación A: Diámetro cm o Aplicación B: Diámetro pulgadas o Aplicación C: Diámetro m cm 13

14 Concepto Problemas relativos a la integración: Atributos Descriptivos Diferentes 14

15 Concepto Problemas relativos a la integración: Claves Diferentes 15

16 Concepto Variantes en el tiempo La información representa datos sobre un horizonte largo de tiempo, entre 5 y 10 años. Cada estructura en el DW contiene, implícita o explícitamente, un elemento de tiempo como día, semana, mes, etc. 16

17 Concepto No volátil El tipo de operaciones es diferente en ambos ambientes 17

18 Concepto Hay redundancia masiva de datos entre el ambiente operacional y el DW? Sí existe, pero es mínima Sólo los datos que se necesitan ingresarán al ambiente del DW. El horizonte de tiempo de los datos difiere de un ambiente a otro. La información en el ambiente operacional es más reciente con respecto a la del DW. El DW contiene un resumen de la información que no se encuentra en el ambiente operacional. Los datos experimentan una transformación fundamental cuando pasan al DW. La mayor parte de los datos se alteran significativamente al ser seleccionados y movidos al almacén. 18

19 Concepto - Ralph Kimball "A data warehouse is a copy of transaction data specifically structured for querying and analysis 19

20 Concepto - Larry Greenfield Disiente con Kimball: La forma en que los datos estén almacenados no determina que "algo" califique o no como datawarehouse No todos los datos son transaccionales 20

21 Concepto Si bien existen opiniones opuestas, hay importantes coincidencias BDT BDT BDT Fundamentalmente alimentados por bases de datos transaccionales Sistemas de soporte a la decisión - Procesamiento Analítico- 21

22 Concepto: Resumen Características Principales Agrupa y mantiene datos transaccionales y no transaccionales de distintas fuentes, incluso externas. Mantiene datos históricos. La forma en la que se almacenan los datos no es fija. El tipo de usuario correspondiente es de nivel gerencial. El tipo de proceso a realizar es de análisis. El objetivo de todo datawarehouse es proveer información suficiente y oportuna asistiendo a la toma de decisiones para alcanzar los objetivos del negocio. 22

23 Arquitectura 23

24 Arquitectura: Fuentes de Datos Bases de Datos (Internas o Externas) Datos contenidos en estructuras no base de datos (Internas o Externas) 24

25 Arquitectura: Gestor de Carga Permite realizar la extracción de los datos desde las fuentes y los carga al datawarehouse Encargado de soportar el proceso ETL (Extraction Transformation- Load) Extracción Transformación de los datos: Limpieza, Consolidación, Agregación de datos, etc. Carga Inicial Recarga Periódica (Refresco): Operación que propaga los cambios desde las fuentes 25

26 Arquitectura: Gestor de Carga Proceso de Carga Inicial Distinguir los diferentes tipos de datos a ser incorporados Datos de backup Datos actuales contenidos en el ambiente operacional Para ambos, el proceso se realiza sólo una vez No presenta demasiada complejidad Encontrar el momento oportuno para no recargar el ambiente operacional 26

27 Arquitectura: Gestor de Carga Proceso de Refresco Los datos provienen de las estructuras de los sistemas operacionales Específicamente, datos generados por cambios ocurridos en los sistemas transaccionales después de la última actualización Búsqueda de los datos procedentes de cambios Dónde se encuentra la mayor dificultad? 27

28 Arquitectura: Gestor de Carga Estrategias para reducir la cantidad de datos analizados: 1. Las aplicaciones operacionales graban el tiempo del último cambio sobre cada registro Los datos con una fecha posterior a la correspondiente al último refresco deberán ser incorporados 28

29 Arquitectura: Gestor de Carga Estrategias para reducir la cantidad de datos analizados: 2. Los cambios son generados en un archivo delta El proceso de refresco se realiza de manera muy eficiente 29

30 Arquitectura: Gestor de Carga Estrategias para reducir la cantidad de datos analizados: 3. Usar los archivos log generados por el propio procesamiento de las transacciones operacionales No es una alternativa muy conveniente: Muchas veces son protegidos por el propio sistema ya que son usados en procesos de recuperación No siempre es sencillo encontrar la información buscada ya que su formato puede contener muchos más datos de los que se necesitan para este propósito y se debe descifrar su formato interno 30

31 Arquitectura: Gestor de Carga Estrategias para reducir la cantidad de datos analizados: 4. Otra técnica es modificar el código de la aplicación. No es una alternativa muy aceptada. 31

32 Arquitectura: Gestor de Carga Estrategias para reducir la cantidad de datos analizados: 5. Mantener una imagen de un antes y un después juntas del archivo operacional En cada extracción se toma una instantánea de la base de datos. Las dos instantáneas (anterior al refresco y la actual) son serialmente comparadas para poder determinar los cambios que se han sucedido en ese lapso de tiempo. Alternativa pesada y tediosa. 32

33 Arquitectura: Gestor del Almacén DBMS que administra la base de datos correspondiente al datawarehouse: Permite realizar todas las funciones de definición y manipulación Definición Agregación Creación de Índices 33

34 Arquitectura: Datos (Almacén) En general, refiere a la base de datos física que contiene los datos 34

35 Arquitectura: Metadatos Datos sobre los datos (origen, descripción, nivel de agregación, etc) 35

36 Arquitectura: Herramientas Clientes/Usuarios Permiten extraer información/conocimiento Herramientas para diseñar consultas e informes (Presentación y Visualización) Herramientas estadísticas Herramientas de análisis de datos (OLAP) Herramientas de minería de datos Herramientas de EIS 36

37 Herramientas OLAP Las herramientas OLAP: Están basadas, generalmente, en sistemas o interfases multidimensionales. Utilizan operadores específicos (además de los clásicos): drill dwon, roll up, pivot, slice, etc. El resultado se presenta generalmente de manera matricial, y permite generar diferentes tipos de gráficos. En resumen, permiten realizar diferentes combinaciones de datos para visualizar los resultados hasta un grado determinado de detalle, permitiendo navegar por sus dimensiones y analizar sus datos desde diferentes puntos de vista 37

38 Herramientas OLAP Un ejemplo de la funcionalidad permitida en una herramienta OLAP Cantidad de prestamos bibliotecarios con dos ejes de análisis (carrera y año) en formato de tabla y gráfico. 38

39 Herramientas OLAP Otro ejemplo de la funcionalidad en una herramienta OLAP 39

40 Herramientas OLAP 40

41 Herramientas OLAP Cuál es la diferencia entre un EIS y una herramienta OLAP? 41

42 Herramientas de Minería Si bien existen herramientas que permiten en análisis de datos, como las OLAP Existen casos donde no son adecuadas Por qué? 42

43 Herramientas de Minería (DataMining) Las bases de datos relacionales revolucionaron los Sistemas de Información: Los DBMS constituyen un soporte eficiente para el almacenamiento y el acceso a datos. Los medios de almacenamiento de datos tienden a ser cada vez más baratos y más eficientes. Volumen de Datos Crecimiento exponencial de las Bases de Datos Décadas

44 Herramientas de Minería Explosión en la cantidad de los datos almacenados en las bases de datos transaccionales!!! Son necesarias herramientas automáticas para el análisis y extracción ya que ello escapa al trabajo manual. El análisis requiere descubrir relaciones ocultas entre los datos como soporte a decisiones empresariales. Minería de Datos 44

45 Minería de Datos: Características 45

46 Herramientas de Minería 46

47 Herramientas de Minería Cuál es la diferencia entre una herramienta OLAP y una de minería de datos? 47

48 Concepto: Datawarehouse vs. Datamart Es frecuente encontrar los términos datawarehouse y datamart usados en forma equivalente. Sin embargo, existen semejanzas y diferencias entre ambos conceptos. Semejanzas: Contienen datos históricos provenientes de fuentes operacionales. El tipo de proceso que se efectúa sobre ambos, es de análisis. Diferencias: En este punto, las opiniones se dividen en dos grupos Según Inmon Según Kimball 48

49 Concepto: Datawarehouse vs. Datamart Inmon Un datawarehouse es fuente de datos de todo datamart Los clientes naturales de un datamart son las herramientas OLAP El tipo de estructura de un datamart son diferentes a las de un datawarehouse Kimball La diferencia está dada fundamentalmente por el tamaño de la base de datos, en términos de objetos de análisis que mantienen (no en cuanto a extensión sino a intensión) El tipo de estructura en un datamart y en un datawarehouse es la misma 49

50 Repasando Necesidades Concepto Arquitectura Fuentes de datos Gestor de Carga: Asiste en el proceso ETL Gestor del almacén Usuarios o Clientes Datamarts vs. Datawarehouse 50

51 Construcción/Diseño de un datawarehouse De los métodos existentes se distinguen 2 enfoques Conducidos por los datos Conducidos por los requerimientos o por la demanda Inmon Kimball Alternativa sobre la que vamos a seguir Más ampliamente utilizado 51

52 Proceso de Construcción (Conducido por los Requerimientos) Recordemos Objetivo de todo datawarehouse Proveer información suficiente y oportuna asistiendo a la toma de decisiones para alcanzar los objetivos del negocio 52

53 Proceso de Construcción: Requerimientos La fase de relevamiento Alineada a los objetivos del negocio 53

54 Proceso de Construcción: Requerimientos La fase de relevamiento Datos Exactitud de los datos: Conformidad del dato en relación al valor en el mundo real. Dos factores influyen en este aspecto, exactitud de los datos en las fuentes y errores en el proceso de carga. Completitud: Capacidad del sistema de representar todos los estados del mundo real Consistencia Oportunidad: Nivel de actualización necesaria para la tarea que lo usa + Identificación de las fuentes Disponibilidad Tipo: Concretas: Los datos se encuentran tal como los necesitamos Adicionales: Es necesario combinar datos de fuentes + Políticas de actualización 54

55 Proceso de Construcción: Diseño Vista multidimensional Procesos de Análisis Datawarehouse almacenado 55

56 Proceso de Construcción: Diseño Los distintos enfoques se diferencian principalmente en la forma en la que almacenan los datos (estructuras de almacenamiento) 56

57 Proceso de Construcción: Diseño La mayor parte de la bibliografía adopta (tácitamente) una perspectiva relacional debido a la importancia y supremacía de las bases de datos relacionales 57

58 Proceso de Construcción: Diseño Existen dos enfoques de implementación: Motor de base de datos relacional Motor de base de datos multidimensional 58

59 Proceso de Construcción: Diseño Enfoque multidimensional La estructura de datos que soporta es el arreglo n-dimensional No necesita transformar los objetos almacenados para presentarlos a los clientes Optimiza el acceso a la información 59

60 Proceso de Construcción: Diseño Enfoque multidimensional Eje 2 de análisis: Artículos Eje 3 de análisis: Clientes Propiedad objeto de análisis Eje 1 de análisis: Fecha 60

61 Proceso de Construcción: Diseño Enfoque multidimensional 61

62 Proceso de Construcción: Diseño Enfoque multidimensional 62

63 Proceso de Construcción: Diseño Enfoque multidimensional 63

64 Proceso de Construcción: Diseño Enfoque multidimensional Arreglos n-dimensionales: Variables dependientes (celdas) Variables independientes (dimensiones o ejes de análisis) en conjunto determinan los valores de las variables dependientes 64

65 Proceso de Construcción: Diseño - Enfoque Relacional La única estructura de datos que soporta el enfoque relacional es la relación (tabla) Un datawarehouse implementado en un motor relacional estará formado por tablas 65

66 Proceso de Construcción: Diseño - Clave Primaria Tabla de Clientes Enfoque Relacional Id. de cliente Nombre de compañía Dirección Ciudad Región País Teléfono CACTU Cactus Comidas para llevar Cerrito 333 Buenos Aires Argentina (1) OCEAN Océano Atlántico Ltda. Ing. Gustavo Moncada 8585 Piso 20-A Buenos Aires Argentina (1) RANCH Rancho grande Av. del Libertador 900 Buenos Aires Argentina (1) Clave Primaria Clave Foránea Tabla de Pedidos Id. de pedido Id.de cliente OCEAN Empleado Leverling, Janet Fecha de pedido Fecha de entrega RANCH Peacock, Margaret CACTU Callahan, Laura OCEAN King, Robert RANCH Peacock, Margaret CACTU Dodsworth, Anne

67 Proceso de Construcción: Diseño - Enfoque Relacional Las tablas deberán estar vinculadas de tal manera de poder brindar la vista multidimensional Esquemas Estrella, Copo de Nieve, Constelación de Estrellas, Estrella Agrupado, etc. 67

68 Proceso de Construcción: Diseño - Enfoque Relacional Cualquiera sea el esquema o modelo utilizado: Tabla de hechos Tabla de dimensiones 68

69 Proceso de Construcción: Diseño - Enfoque Relacional Tabla de Hechos (variables dependientes) Describen datos sobre actividades básicas de la organización que son objeto de análisis 69

70 Proceso de Construcción: Diseño - Enfoque Relacional Tabla de Dimensiones (variables independientes) Describen objetos relevantes de la organización por los cuales se analiza la actividad 70

71 Proceso de Construcción: Diseño - Enfoque Relacional Esquema Estrella: tabla de hechos clave primaria Sección de referencias clave primaria datos tabla de dimensión clave foránea clave foránea clave claves foránea clave foránea clave primaria datos tabla de dimensión clave primaria datos tabla de dimensión datos Sección descriptiva clave primaria datos tabla de dimensión 71

72 Proceso de Construcción: Diseño - Enfoque Relacional Esquema Estrella: Una tabla de hechos y n tablas de dimensiones Se relacionan directamente a través de claves foráneas 72

73 Proceso de Construcción: Diseño - Enfoque Relacional Atributos Tabla de hechos : Sección de referencias (dimensiones) Sección descriptiva (medidas) 73

74 Proceso de Construcción: Diseño - Enfoque Relacional Atributos Tabla de dimensiones: Identificador del objeto Atributos descriptivos, es decir, propiedades del objeto 74

75 Proceso de Construcción: Diseño - Enfoque Relacional Esquema Copo de Nieve: jerarquía Tabla de Tabla de entre dimensiones dimensiones dimensiones clave primaria datos tabla de dimensión clave primaria datos clave foránea tabla Tabla de dimensión de dimensiones clave primaria datos tabla de dimensión Tabla tabla de hechos clave primaria clave foránea clave foránea clave claves foránea clave foránea datos Sección descriptiva Sección de referencias Tabla de dimensiones clave primaria datos tabla de dimensión Tabla de dimensiones clave primaria datos clave foránea tabla de dimensión jerarquía entre dimensiones Tabla de dimensiones Extensión del esquema estrella cuando las dimensiones se organizan en jerarquías de dimensiones clave primaria datos tabla de dimensión 75

76 Proceso de Construcción: Comparación de Modelos 76

77 Proceso de Construcción: Diseño - Enfoque Relacional Normalización: Las desventajas de un esquema de base de datos relacional no normalizado están relacionadas fundamentalmente con los problemas de update 77

78 Proceso de Construcción: Diseño - Enfoque Relacional En un datawarehouse no se efectúan update como en una base de datos transaccional Se incrementa en forma periódica 78

79 Proceso de Construcción: Diseño - Enfoque Relacional Datawarehouses Normalización pierde importancia Se pueden generar esquemas no normalizados para alcanzar una mejor performance 79

80 Proceso de Construcción: Diseño - Enfoque Relacional Esquema Estrella (no normalizado 3FN): Tabla tabla de hechos clave primaria clave primaria datos exclave foránea datos tabla de dimension no normalizada clave primaria datos tabla de dimension clave foránea clave foránea clave claves foránea clave foránea datos clave primaria datos tabla de dimension clave primaria datos exclave foránea datos tabla de dimension no normalizada 80

81 Proceso de Construcción: Diseño - Enfoque Relacional Dimensión Tiempo: Presente en todo dw Aunque SQL ofrece funciones sobre el tipo DATE, la representación de la dimensión permite representar otros atributos no calculables en SQL Atributos frecuentes: nro. de día, nro. de semana, valores absolutos del calendario juliano que permiten ciertos cálculos aritméticos, día de la semana (lunes, etc.), día festivo, fin de semana 81

82 Proceso de Construcción: Diseño - Enfoque Relacional Analizando el enfoque Relacional Ventajas: Tecnología madura Extremadamente utilizada y conocida Sistemas altamente escalables Poseen lenguaje de consulta standard En general, las organizaciones ya poseen las licencias Desventajas: Las estructuras del modelo no son naturales para el procesamiento OLAP Por ello necesitan contar con una capa intermedia que mapee ambas estructuras provocando una baja performance en las consultas 82

83 Proceso de Construcción: Diseño Granularidad: Nivel de detalle de la información almacenada en las estructuras 83

84 Proceso de Construcción: Diseño A mayor nivel de granularidad: Mayor tiempo de procesamiento en la carga Menor volumen de información Consultas con mejor performance Escasa flexibilidad ante consultas no planificadas 84

85 Proceso de Construcción: Diseño Analizar cuidadosamente el nivel de detalle adecuado en cada caso de manera de poder balancear ventajas y desventajas 85

86 Proceso de Construcción: Diseño Relacional: Cuan resumida o no es la información de la tabla de hechos Multidimensional: El grado de detalle de la variable dependiente 86

87 Proceso de Construcción: Diseño Definir el intervalo de tiempo oportuno entre cada actualización del dw Balancear: Sobrecarga del ambiente operacional Actualidad del datawarehouse 87

88 Proceso de Construcción: Diseño Definir la Ventana de tiempo oportuna de un dw Cuánta historia debe mantener el datawarehouse? 88

89 Ejemplo La empresa GUMA S.A. vende productos alimenticios. Los datos transaccionales que maneja diariamente son referidos a: Los productos que comercializa Las ventas (facturas) efectuadas por sus empleados Las pedidos recibidos Los clientes Los proveedores Las compañías de envíos que se encargan de la entrega de los pedidos Los empleados que trabajan en ella 89

90 Ejemplo Para soportar las operaciones diarias (transaccionales) que administran los datos mencionados posee una base de datos cuyo modelo conceptual es el presentado a continuación 90

91 Ejemplo Rubro Proveedor 1,1 Incluye Provee Producto Detalle Pedido Pedido Detalle Factura Factura EsRealizada Empleado EsDeUn Cliente EsEnviado Compañía de Envío EsJefe 91

92 Ejemplo 92

93 Ejemplo 1. El gerente plantea la siguiente situación: Hay que aumentar los ingresos 2. Por lo tanto, se pregunta: Qué podemos hacer Disminuir gastos? Vender más? Existen proveedores preferidos Qué productos nos conviene vender,? Para responder a esas preguntas, por ejemplo necesitaría saber: Qué productos se venden más? Cuál es el producto que genera el mayor ingreso de dinero a la empresa? Qué proveedor provee los productos más vendidos? Qué categoría o rubro es el más vendido?... 93

94 Ejemplo Datos Poductos Proveedores Facturas Conocimiento Nos conviene que se incrementen las ventas del producto PP Los productos del proveedor X son los más vendidos Información Los productos P1 y P2 son los más vendidos El producto PP es el que provoca el mayor ingreso a la empresa El producto PP es uno de los menos vendidos Los productos P1 y P2 son provistos por el proveedor X Decisión Estudiemos la posibilidad de incorporar nuevos productos del proveedor X Generemos promociones que combinen los productos P1 y PP y/o P2 y PP Investiguemos si el proveedor X vende el producto PP. En ese caso se lo compremos a él 94

95 Ejemplo Los datos que deben analizarse existen dentro de la empresa? Sí, pero como mencionamos anteriormente: Recuperar los datos desde las fuentes, altera el trabajo transaccional diario No se puede dar respuesta a las solicitudes en tiempo real Los datos necesarios constituyen un subconjunto de la totalidad de datos de la empresa La estructura de los datos está pensada para dar soporte a tareas transaccionales 95

96 Ejemplo Construyamos un datawarehouse (datamart) que permita extraer la información/conocimiento que necesitamos 96

97 Ejemplo Pasos a seguir: 1. Identificar el proceso de la organización a analizar, es decir el objeto de análisis Tabla de Hechos Ventas 97

98 Ejemplo Pasos a seguir: 2. Determinar la granularidad de los datos necesaria (nivel de detalle) Cada una de las ventas 98

99 Ejemplo Pasos a seguir: 3. Identificar las dimensiones de análisis Tablas de Dimensiones Productos Proveedores Clientes Empleados Tiempo 4. Identificar las jerarquías entre las dimensiones de análisis 99

100 Ejemplo Rubro Proveedor 1,1 Incluye Provee Producto Detalle Pedido Pedido Detalle Factura Factura EsRealizada Empleado EsDeUn Cliente EsEnviado Compañía de Envío EsJefe 100

101 Ejemplo Pasos a seguir: 5. Identificar las propiedades tanto del objeto de análisis como de las dimensiones Atributos de la tabla de hechos (medidas) Atributos descriptivos de las tablas de dimensiones 101

102 Ejemplo Tablas y sus relaciones: 102

103 Ejemplo 21/07/ :22 p.m. Cátedra Bases de Datos 103

104 Ejemplo Objeto de Análisis: Ventas Medidas: Cantidad e Importe Dimensiones de Análisis: Empleado, Producto, Proveedor, Cliente y Tiempo Jerarquías de dimensiones: Producto Proveedor Fecha Día Mes - Año 104

105 Ejemplo Esquema Estrella Granularidad Fina Empleado IdEmpleado Nombre FechaNac FechaCont Tiempo Fecha Día Mes Año Venta IdProducto IdCliente IdEmpleado Fecha Importe Cantidad Producto IdProducto Nombre Rubro IdProveedor NombreCompañia Ciudad Region CodPostal País Cliente IdCliente Nombre Ciudad Region CodPostal País 105

106 Ejemplo Esquema Copo de Nieve Granularidad Fina Empleado IdEmpleado Nombre FechaNac FechaCont Venta IdProducto Producto IdProducto Nombre Rubro IdProveedor Proveedor IdProveedor NombreCompañia Ciudad Region CodPostal País IdCliente IdEmpleado Fecha Cliente Tiempo Fecha Día Mes Año Importe Cantidad IdCliente Nombre Ciudad Region CodPostal País 106

107 Ejemplo Esquema Estrella Granularidad Menos Fina Empleado IdEmpleado Nombre FechaNac FechaCont Tiempo Fecha Día Mes Año No se discrimina por producto Venta IdProveedor IdCliente IdEmpleado Fecha Importe Cantidad Proveedor IdProveedor NombreCompañia Ciudad Region CodPostal País Cliente IdCliente Nombre Ciudad Region CodPostal País 107

108 Lenguaje SQL El standard SQL da soporte a las Bases de Datos multidimensionales, con extensiones que proveen las funcionalidades necesarias cláusula group by funciones específicas 108

109 Lenguaje SQL Cláusula group by: 109

110 Operador Rollup 110

111 Operador Cube 111

112 Operador Grouping Set 112

113 Comparación de Operadores 113

114 Ejemplos: Roll-up Drill-down Sobre las tablas del esquema SH de Oracle 1. Agrupamiento común select prod_id, cust_id, sum(amount_sold) from sh.sales group by prod_id, cust_id; 2. Disminuyo el nivel de detalle respecto de (1): select prod_id, sum(amount_sold) from sh.sales group by prod_id; (ROLL-UP) 3. Aumento el nivel de detalle : select prod_id, cust_id, channel_id, sum(amount_sold) from sh.sales group by prod_id, cust_id, channel_id; (DRILL-DOWN) 114