Implementando un data warehouse con SQL 2000 y analysis services

1 Implementando un data warehouse con SQL 2000 y analysis...
Author: Aurora Valdéz Ayala
0 downloads 2 Views

1 Implementando un data warehouse con SQL 2000 y analysis servicesJose Mariano Alvarez Gonzalez

2 Agenda Características y objetivos de los data warehouseBases de datos involucradas Modelos dimensionales ETL y DTS MDX Herramientas del SQL Server 2000

3 Visión de Microsoft sobre BI“The more relevant, useful intelligence you have at your fingertips—about your business, your customers, your partners and your operations—the more your organization can make better decisions and increase competitive advantage.”

4 Que me da una solución de BIMinimizar el tiempo requerido para obtener la información relevante del negocio Automatizar la asimilación de la información Proveer herramientas de análisis para hacer comparaciones y decisiones mas inteligentes Cerrar el lazo desde la decisión a la acción

5 ¿ Qué es un data warehouse ?Es una fuente de datos de la empresa fácilmente consultable. Frecuentemente es la unión de los Data Marts que lo componen.

6 Características de un data warehouseData mining Analistas de base de datos OLAP Analistas avanzados Query tools Ejecutivos Aplicaciones a medida Analistas de negocio EIS

7 Preguntas de negocio Son los requerimientos de información para tomar decisiones Peden incluir graficos o reportes Se pueden responder con rankings, comparaciones, parettos, semáforos, reportes, diagramas de dispersión, paneles, etc.

8 Indicadores Son los componentes de las respuestas a las preguntas de negocio Pueden ser simples como acumulados Pueden ser variaciones relativas o absolutas Pueden ser comparaciones Etc

9 Diferencias con los sistemas operativos o transaccionales

10 Comparación (1) OLAP Análisis de métricas de negocio por categorías y atributos Optimizado para la carga masiva, consultas grandes, complejas e impredecibles que acceden a muchos registros por tabla OLTP Satisfacer las operaciones de negocio en tiempo real Optimizada para un conjunto de transacciones que habitualmente operan sobre una sola o pocas filas por tabla

11 Comparación (2) OLAP Cargado con datos consistentes y validos. No requiere validación en tiempo real Tiene menos usuarios concurrentes OLTP Optimizado para la validación de los datos que se cargan durante las transacciones Soporta miles de usuarios concurrentes

12 OLAP (1) On line analitical processEs la actividad general de consulta y presentación de datos desde el data warehouse, así como un estilo específicamente dimensional de consultar y presentar esos datos CUBOS

13 OLAP (2) Atlanta Denver Detroit Grapes Apples Melons Cherries Pears Q4Location Atlanta Denver Detroit Product Grapes Apples Melons Cherries Pears 1,930 UNITS $6,745 GROSS $5,831 COST Q4 Time Q1 Q2 Q3

14 Tipos de almacenamiento.

15 Olap Rolap - Relacional Molap - Multidimensional Holap - Híbrido

16 MOLAP Es un conjunto de interfaces de usuario, aplicaciones y técnicas de base de datos propietarias que están orientadas a hacia el modelo multidimensional. Las bases de datos no son relacionales No hay lenguajes de consulta estándar

17 ROLAP Relational OLAP Es un conjunto de interfaces y aplicaciones que le da a una base de datos relacional una presentación multidimensional.

18 HOLAP Combina los modelos ROLAP y MOLAP tratando de obtener lo mejor de cada uno de ellos.

19 Elementos involucradosData Warehouse Elementos involucrados

20 Elementos básicos

21 Sistemas fuente Son los sistemas operacionales de la empresa y cuyo propósito principal es llevar el registro de todas las transacciones de la empresa Se los suele llamar legacy systems Son los ERP, CRM, SCM, etc

22 Data stage área Es un área de almacenamiento y un conjunto de procesos que limpian, transforman, combinan, elimina duplicados, archiva y prepara los datos fuentes para ser usados en el data warehouse Es una de las etapas mas difíciles en empresas con muchos sistemas fuente

23 Presentation server Es la máquina de destino donde se almacenan y organizan los datos para la consulta directa por parte de los usuarios, generadores de reportes, y otras aplicaciones.

24 Dimensional Model Es la disciplina de modelado de datos que se suele usar en el Data Warehouse y esta especialmente preparada para este tipo de soluciones Sus componentes principales son las fact tables y los dimension tables

25 Business process o Proceso de negocioEs un conjunto coherente de actividades de negocio que dan sentido a los usuarios de negocio de nuestro data warehouse

26 Data Mart Es un subconjunto lógico del data warehouseNO ES un un conjunto de datos sumarizados En el modelo propuesto por Kimbal no son elementos diseñados por separado que luego se juntan.

27 Bases de datos involucradasDe los sistemas operacionales. (Suele haber más de una) Del proceso de extracción, transformación y carga (Puede haber más de una) De consulta (Puede haber más de una)

28 Procesos básicos de un data warehouseExtracción Transformación Carga e indexación Aseguración de calidad Publicación – release Actualización Armado de consultas Data feedbak (a legacy systems) Auditoria Seguridad Backup

29 Características, comparación y justificaciónModelado dimensional Características, comparación y justificación

30 Modelado dimensional Es la técnica para entregar datos a los usuarios dentro de un data warehouse. Busca presentar los datos en un esqueleto (framework) que es intuitivo y permite el acceso a los datos de forma altamente eficiente Orientada al análisis de datos

31 E-R Modeling Es una técnica que permite eliminar la redundancia de datos dentro del modelo relacional Es una disciplina dedicada a darle importancia a las relaciones microscópicas entre los elementos de datos. Orientada a las transacciones

32 Contras de E-R ModelongLos usuarios no pueden entender, recordar o navegar los modelos ER Las herramientas generalmente no pueden consultar en forma general los modelos ER El modelo ER va en contra de los principios del data warehouse tales como lo son intuitivo y eficiente.

33 ¿De que estamos hablando?

34 Modelos dimensionales Elementos componentesFact table Tabla de hechos. Generalmente es una tabla muy grande Dimension tables Tablas de dimensiones. Generalmente son pequeñas en comparación a la fact table

35 Tablas de dimensiones Tablas de dimensiones FACT TABLEStar schema Tablas de dimensiones Tablas de dimensiones FACT TABLE

36 Fact table Los hechos mas importantes en una fact table son los que tiene la propiedad de ser aditivos ya que permiten sumarizarse y obtener un resultado agrupado Otros hechos pueden utilizar otras funciones de agregación

37 Dimension Tables Contienen la descripciones textuales de la información Son los puntos de entrada del data warehouse Son las categorías en las cuales se agrupa la información

38 Mitos falsos En los modelos dimensionales hay menos informaciónLos modelos dimensionales son usados para datos agregados

39 Metadata Es la información y las características de los modelos y los datos. Sirve para las distintas etapas desde la extracción de los datos hasta la explotación Es esencial para el éxito a largo plazo

40 Metadata (2) La de los procesos de ETL queda en el DTSLa de los modelos y la explotación queda en la base del repositorio habitualmente en “C:\Program Files\Microsoft Analysis Services 2k\Bin\msmdrep.mdb”

41 Construcción del Data Warehouse

42 Alternativas de construcción tradicionalesTop Down Master Database Sumarizaciones y publicación Bottom Up Data mart no relacionados (por ejemplo departamentales) Data warehouse Bus Architecture

43 Clave para entender el modeloPara entender el modelo dimensional se debe tener en cuenta que un solo modelo entidad relación se descompone en múltiples modelos dimensionales

44 Como convertir un modelo E-R en un modelo multidimensional

45 Primer paso Identificar y separar los componentes del modelo entidad relación en los distintos procesos discretos de negocio, de forma tal de poder modelarlos separadamente

46 Segundo paso Identificar y seleccionar en estos modelos entidad relación separados, las tablas con relaciones muchos a muchos y que contienen hechos numéricos y aditivos (que no son claves del modelo ER) y determinar a partir de ellas las fact tables

47 Tercer paso Desnormalizar el resto de las tablas en tablas planas con un solo campo clave que se relaciona directamente con un campo idéntico en la fact table. Estas serán las tablas de las dimensiones

48 Resultado Matriz dimensional Un conjunto de modelos dimensionalesLos star schema tienen normalmente entre 5 y 10 dimensiones Algunas de las dimensiones son compartidas entre los distintos star schema

49 Ejemplo de matriz diemensional

50 Fortalezas del modelo (1)Al ser un esqueleto previsible permite tanto a los sistemas de bases de datos como a los “query tools” hacer fuertes suposiciones sobre los datos de forma tal de ayudar a la presentación y a la performance Permite soportar cambio en el comportamiento de los usuarios

51 Fortalezas del modelo (2)Soporta cambios de datos o modelo airosamente Agregado de datos no previstos del mismo grano que la tabla de hechos Agregado de nuevas dimensiones siempre y cuando un solo valor de esta nueva dimensión se define para cada registro de hechos Agregado de nuevos atributos de una dimensión Agregado de niveles mas bajos en una dimensión a partir de un momento en el tiempo

52 Fortalezas del modelo (3)Hay un numero importante de aproximaciones estándar para manejar situaciones comunes de modelado el mundo de los negocios. Slowly changing dimensions Heterogeneous products Pay in advance databases Event handling databases

53 Fortalezas del modelo (4)Un número creciente de aplicaciones y utilidades de software que apoyan la tecnología de modelado multidimensional propuesto y que proveen tecnología de agregación lo que permite respuestas más performantes

54 Data Warehouse Bus Architecture (DWBA)

55 Como realizar la construcciónNadie cree en un una aproximación totalmente monolítica Nadie defiende la aproximación de data marts aislados Todos los líderes defienden alguna clase de arquitectura paso a paso

56 Datamarts Los data marts deberán estar basados en datos lo más atómicos posibles que se puedan obtener de los legacy systems El termino data mart expresa la imposibilidad de la construcción de todo el data warehouse completo en un paso

57 Data marts en la DWBA (1) Comenzar la planificación con una completa y corta fase de arquitectura con metas específicas para todo el data warehuse Definir alcance Definir implementación

58 Data marts en la DWBA (2) Seguir con una fase de implementación paso a paso de cada data mart Supervisar la construcción de cada pieza completa del data warehouse

59 Dimensiones

60 Dimensiones Es la organización de los atributos que describen las cosas que componen el modelo dimensional Estos atributos están fuertemente correlacionados entre si Si hay datos poco correlacionados suele ser indicador de que se deben separar en dos dimensiones

61 Atributos de las dimensionesDeben ser lo más verborrágicos posible Deben ser descriptivos Deben ser completos Deben tener calidad. Documentados en la metadata Deben ser descripciones cortas y no códigos o abreviaciones

62 Niveles de las dimensionesEs la forma de agrupar los atributos de una dimensión Es el nombre del conjunto de miembros de una dimensión que se encuentran a una misma distancia de la raiz de la jerarquía Suele definirse un “ALL” (todos) que agrupa a todos y es la raiz de la jerarquía Se los usa para crear agregaciones

63 Ejemplo de niveles Dimensión Niveles de la dimensión

64 Claves (Keys) Usar claves sobrogadas, aun para la dimensión tiempoEvitar claves de múltiples campos Evitar darle significado a la clave

65 Claves subrogadas Son clave propias generadas dentro del modelo dimensional No son las mismas claves que la de los sistemas operacionales Aseguran el éxito ya que tarde o temprano los legacy systems pueden realizar cambios que sean incompatibles con el data warehouse

66 Creación de dimensiones

67 Conformed dimensions (1)Es una dimensión que significa lo mismo para cada posible fact table a la cual puede ser asociada Generalmente es la misma tabla para todos los data mart

68 Conformed dimensions (2)Es una de las mayores responsabilidades del grupo de diseño del data warehouse Debe realizar las siguientes tareas Establecer Publicar Mantener Imponer

69 Conformed dimensions (3)Sin la estricta adhesión a la realización de conformed dimensions el data warehouse no puede funcionar como un todo integrado

70 Conformed dimensions (4)Si no se realizan conformed dimensions se puede llegar a Tener modelos que no se pueden usar juntos Obtener resultados erróneos

71 Conformed dimensions (5)Una única dimensión puede ser usada en múltiples tablas de hechos Las interfaces de usuario y el contenido de datos es consistente en todos los lugares donde se la use Hay una coherente interpretación de los atributos en todos los data mart

72 Conformed dimensions (6)La determinación y el diseño de estas Conformed dimensions debería tomar unas pocas semanas Deberán ser definidas al nivel mas atómico posible El uso de conformed dimensions más que una decisión técnica suele ser una decisión política

73 Dimensiones compartidasSon las “conformed dimensions” Pueden ser usadas en varios cubos Pertenecen a una sola base de datos Permiten cruzar datos entre distintos cubos

74 Dimensiones privadas Son propias de un cuboNo son “conformed dimensions” Limitan la navegación cuando se crean cubos virtuales

75 Snowflake (copo de nieve 1)Se dice que una dimensión tiene este tipo de estructura cuando esta normalizada. Los campos de menor cardinalidad se encuentran separados en tablas

76 Snowflake (copo de nieve 2)

77 Snowflake (copo de nieve 3)Normalmente se argumenta ahorro de espacio. No suelen ser óptimas para la navegación (performance) en ROLAP Los modelos son mas complejos En Analysis Services suele ser igual de óptimo que sin normalizar

78 Creación de una dimensión en copo de nieve (Snowflake)

79 Tipo de modelos según las dimensionesStar Cada dimensión se compone de 0 o 1 tabla relacionada con la tabla de hechos Snowflake Todas las dimensiones están normalizadas Starflake Solo alguna de las dimensiones esta normalizada

80 Dimensión tiempo (1) Ocupa un lugar especial en cada data warehouseCada fact table en un data warehouse es una serie de tiempo de observaciones da alguna clase Debido a la globalización debe soportar múltiples formas de visualización

81 Dimensión tiempo (2)

82 Creación de la dimensión tiempo

83 Slowly changin dimensionsA veces las claves de los sistemas transaccionales no cambian pero sus descripciones si. Los atributos de alguna de las dimensiones cambian Suelen ser esporádicos

84 Tipo 1 Sobreescribir el registro de dimensión con los nuevos valoresSe pierde la información histórica

85 Tipo 2 Crear un nuevo registro con los nuevos valoresSe requiere claves subrogadas Permite particionar claramente la historia para cada valor de atributo

86 Tipo 3 Crear un campo OLD en la dimensión para almacenar el atributo inmediato previo Se usa en cambios de la empresa del tipo “suaves” o tentativos

87 Cambios en Large dimensionNo se pueden utilizar las técnicas vistas Se debe separar en distintas tablas Información constante Información variable Se debe crear atributos de tipo banda con valores discretos

88 Cambios en Large dimension

89 Dimensiones degeneradasMaster-Detail. Cuando los datos de la fact table son “ítem de” El “Numero” de factura, pedido, etc se almacena en la fact table Hablamos de una dimensión degenerada porque si creáramos una tabla para la misma solo tendría el atributo “Número”

90 Junk Dimensions Suelen ser No suele ser útilAtributos que son flags de los sistemas transaccionales De baja cardinalidad y dispersos La interpretación depende del contexto No suele ser útil Dejarlos en la Fact table Crear una dimensión para cada uno

91 Junk Dimensions Se deben estudiar cuidadosamenteLa solución es crear una o varias dimensiones para todos agrupándolos lo máximo posible

92 Dimensiones balanceadas y desbalanceadas

93 Dimension Parent-Child (1)

94 Dimension Parent-Child (2)

95 Propiedades de miembrosSe definen en un nivel determinado Suelen usarse para crear dimensiones virtuales No se crean agregaciones por estas propiedades Se las usa cuando el atributo esta correlacionado con un nivel determinado de una dimension

96 Dimensiones VirtualesEs una dimensión lógica basada en una física Puede ser creada en base a Propiedades de los niveles Columnas de la dimension fisica No tienen agregaciones y por lo tanto no aumentan el espacio requerido al procesar el cubo Pueden ser más lentas

97 La calidad de los atributos define la calidad del data warehouse

98 Hechos

99 Tipo de hechos Aditivos Semiaditivos No aditivos

100 Hechos aditivos Se pueden obtener mediante medidas comunes o calculadas Se pueden sumarizar en cualquier dimensión Suelen expresar actividad Ejemplo Dolares o unidades vendidas

101 Hechos semiaditivos (1)Se suelen poder sumarizar en cualquier dimensión excepto alguna Suelen expresar intensidad o un estado en un momento determinado No suele ser útil la función AVG Ejemplo Niveles de balance Saldos de cuentas

102 Hechos semiaditivos (2)Para combinarlos a través de la dimensión tiempo se debe Primero sumarizar a través del tiempo Dividir por el numero de periodos de tiempo en cuestión No es el mismo resultado que la función AVG Requieren medidas calculadas

103 Hechos no aditivos No se los puede sumarizar pero si agregar.Se los puede promediar, obtener el máximo, etc Se puede usar la función AVG Ejemplo Temperatura

104 Diseño de la fact table Seleccionar la fuente de datos del data martDeterminar el grano de la fact table Seleccionar las dimensiones Seleccionar los hechos

105 Tipos de grano más usadosTransacciones individuales Fotos de los niveles ( actividad, endeudamiento, etc) Items de línea de documentos (facturas, ordenes de compra, etc)

106 Fact tables sin hechos (1)Describen eventos y alcance Se las usa en situaciones particulares donde generalmente se hacen cuentas y no sumarizaciones

107 Fact tables sin hechos (2)

108 Fact tables sin hechos (3)

109 Cubos reales Se crean físicamenteContienen los datos y las agregaciones Contiene al menos una partición Se pueden escribir

110 Cubos virtuales Es una “vista” de uno o varios cubosNo contiene datos ni agregaciones Contiene solo la definición

111 Medidas Define la forma en que se agregan los datosPueden tener operaciones sobre la columna dbo.precio * dbo.cantidad

112 Medidas calculadas Se obtienen a partir de otras medidas del cuboSe usa MDX para definirla Pueden traer problemas de performance

113 Medidads de flujo y de stockFLUJO: Analizan un indicador en intervalos o transacciones Suelen ser aditivas STOCK: Analizan fotos de la situación Suelen ser semi aditivas respecto del tiempo

114 Transactions Facts Es útil crear campos de auditoriaSe pueden realizar análisis poderosos que no se pueden realizar con datos sumarizados Permiten analizar comportamiento Análisis de colas comportamiento secuencial Detección de fraude No dan rápida respuesta a algunas preguntas de negocio

115 Snapshot facts Son la solución cuando las respuestas de negocio corresponden a actividad Permiten medir rápidamente el estado de la empresa Suelen estar orientadas a cuentas y tiempo Aparecen dimensiones de estado

116 Conformed fact (1) Las conformed dimensions son el 80% del esfuerzo de construcción de la arquitectura del data warehouse El restante 20 % lo constituye la identificación de definiciones de conformed facts, Se realizan al mismo tiempo que las conformed dimensions

117 Conformed fact (2) Usualmente los hechos tienen unidades naturales de medidas idénticas para todos los modelos Algunas veces los hechos pueden tener diferentes unidades naturales de medidas

118 Conformed fact (3) Algunas veces es imposible obtener conformed factsPor mas que se refiera a los mismos tipos de hechos se deberá asegurar que las diferentes interpretaciones tengan diferentes nombres

119 Características de los hechosSuelen ser numéricos y rara vez son alfanuméricos Suelen ser campos con datos en punto flotante de los sistemas transaccionales Se pueden medir

120 Granularidad La granularidad de las fact tables de cada data mart deberá estar al nivel más bajo de todas las dimensiones integrantes del modelo Cuando se hace drill down no es inteligente perder los beneficios de la presentación dimensional en los últimos pasos

121 Idea fundamental Cada tipo de de datos de negocio puede ser representado por un cubo con Valores mensurables en las celdas del cubo Las aristas del cubo definen las dimensiones naturales de los datos

122 Características de los cubosLos modelos tienen generalmente entre 4 y 15 dimensiones Modelos con 2 o 3 dimensiones son raros Modelos con mas de 15 dimensiones suelen tener dimensiones que se pueden combinar

123 Creación de cubos

124 Donde comenzar Comenzar con datamarts de una sola fuente de información para Minimizar riesgos Asegurarse la implementación

125 Importante Una implementación eficiente de un datamart de una sola fuente de información proveerá suficientes datos interesantes como para mantener a los usuarios felices y tranquilos mientras se realizan las tareas más difíciles de construcción del resto del data warehouse

126 Agregaciones (1) Permiten mejorar los tiempos de respuestaRequieren almacenamiento adicional Si no son controladas pueden provocar una explosion en los requerimientos de almacenamiento

127 Agregaciones (2) Debe controlarse cuidadosamente cuando hau muchas dimensiones y niveles Comenzae con un % de mejora bajo 30% o menos Se suele mejorar las agregaciones de acuerdo al perfil de consultas

128 Impacto en la performanceA mayor numero de agregaciones mas tiempo de procesamiento y mas espacio se requiere A mayor numero de agregaciones es probable que se obtenga un mejor tiempo de respuesta de las consultas

129 ETL Extraccion Transformación Carga

130 Extraccion Generalmente se accede a los sistemas fuente y suele programarse en el mismo lenguaje Se define una periodicidad de extracción y se la programa Suelen definirse interfaces en archivos planos de texto o colas

131 Transformación (1) Validación de datos PrecisiónValida que las filas de la tabla de hechos tengan el correspondiente elemento de cada una de las dimensiones Precisión Valida que todos los campos tengan valores correctos

132 Transformación (2) Conversión de tipos y datosSe asegura que todos los valores de un mismo campo estén almacenados y codificados de la misma forma sin importar cual es el sistema fuente que lo informa. Aplicación de reglas de negocio Asegura que se cumplen las reglas de negocio

133 Transformación (3) Limpieza de datos NormalizacionEliminacion de ruido Valores perdidos Inconsistencias Discretizacion o generacion de conceptos o categorias

134 Componentes ETL de SQL ServerDTS SQL Server Agent T-SQL Ole-DB COM

135 Multidimensional ExpressionsIntroducción al MDX. Multidimensional Expressions

136 ¿Qué es MDX? Sintaxis para definir y manipular objetos multidimensionales. Es equivalente al SQL para los objetos relacionales. No es una ampliacion del SQL.

137 Partes de una sentencia MDXCubo o cubos (alcance) Especificación de Ejes Especificacion de las dimensiones (tuplas miembro de cada dimensión), nivel de anidamiento que aparece en cada eje y el orden Especificacion de slice o corte (where)

138 Algunos conceptos (1) Los datos multidimensionales se representan en dimensiones (DIMENSION) Las dimensiones tienen niveles en donde hay miembros (MEMBER) Un miembro a su vez se puede dividir en un nivel inferior en mas miembros (LEVEL) En cada intersección de los miembros de un cubo PUEDE haber medidas (MEASURES)

139 Algunos conceptos (1 Bis)

140 Algunos conceptos (2) CELDA es la intersección de todas las dimensiones de un cubo. TUPLA es la referencia de una o de varias celdas en cuyo caso estamos hablando de SLICES. SET (conjunto) es una colección ordenada de tuplas. NAMED SET es un conjunto con nombre o alias.

141 Ejemplos de tuplas (Source.[Eastern Hemisphere].Africa, Time.[2nd half].[4th quarter], Route.Air, Measures.Packages) (Source.[Eastern Hemisphere]) (Time.[2nd half], Source.[Western Hemisphere])

142 Ejemplo de set { (Time.[1st half].[1st quarter]) , (Time.[2nd half].[3rd quarter]) }

143 Algunos conceptos (3) MEASURES (medidas) es tratada como una dimensión privada más y de donde generalmente obtenemos los datos que analizamos.

144 Algunos conceptos (4) Calculated Members (miembros calculados) Son miembros que se basan en la evaluación de expresiones MDX User-Defined Functions (funciones definidas por el usuario) MDX provee extensibilidad mediante estas funciones usando las interfaces (COM).

145 Instrucción típica SELECT Solo un cuboFROM WHERE Solo un cubo

146 Algunos conceptos (5) Axis dimension Slicer dimension

147 Algunos conceptos (5 bis)Cada dimensión en una consulta de un cubo puede ser : axis dimension slicer dimension Una dimension no puede participar de ambas a la vez Las dimensiones que no se explicitan en el query se asignan automaticamente como slicer dimensions

148 Slicer Dimension Criterio de selección Sus miembros por defecto(ALL) Todos sus miembros Clausula WHERE

149 Where WHERE ( [Route].[All], [Time].[1st half] )

150 Miembros (1) Member name Member Key Member Functions[Time].[2nd half].[4th quarter] Member Key [Time].[2nd half].&[Q4] Member Functions Time.FirstChild (es lo mismo que Time.[1st half] si ese es el primer hijo)

151 Miembros (2) Calculated MembersWITH MEMBER [Measures].[PackagesForecast] AS '[Measures].[Packages] * 1.1'

152 Tuplas (1) (Time.[2nd half])

153 Tuplas (2) (Time.[2nd half], Route.nonground.air)

154 Set Functions {[1st quarter]:[4th quarter]}{[1st quarter], [2nd quarter], [3rd quarter], [4th quarter]}

155 Ejemplos

156 Importancia de las herramientas de explotación.

157 Clientes Aplicaciones de usuario final Aplicaciones de acceso a datosData report Graph reports Query tools Aplicaciones de modelo Forecasting Socoring de comportamiento Data mining

158 Drill

159 Drill down Drill down Significa agregar mas detalle por ejemplo agregando un atributo más Las herramientas de explotación suelen llamar: Drill Down: agregar al reporte detalle de nivel más bajo dentro de la misma dimensión Drill To: agregar al reporte detalle de otra dimensión

160 Drill up Drill up análogamente significa quitar algún detalle dentro del reporte

161 Drill

162 Ejemplod e DRILL

163 Justificación económica para el data warehouseAhorros en recursos usados en la generación de información Ahorro por mejoras en la toma de decisiones Mejores resultados por mejores decisiones ROI habitual del 50% en los proyectos exitosos

164 Muchas gracias por su atenciónJose Mariano Alvarez Gonzalez