1.1 Evolución de los Decision Support Systems (DSS)

Transcripción

1 1. Introducción 1.1 Evolución de los Decision Support Systems (DSS) La historia de los data warehouses comienza con la evolución de los sistemas de información y sistemas para el soporte de toma de decisiones Los orígenes de data warehousing y los decision support systems (DSS) se remonta muy atrás a los comienzos de la computadora y los sistemas de información y continúa evolucionando día a día

2 La llegada del DASD En los 1970's surge el almacenamiento en disco, o "direct access storage device (DASD)". El almacenamiento en disco fue fundamentalmente diferente del almacenamiento en cinta, acceso directo vs acceso secuencial. Con los DASD llegó un nuevo tipo de software llamado "database management system (DBMS)".

3 Para mediados de los 1970's, las operaciones de transacciones en línea (online transaction processing (OLTP)) hicieron posible un acceso todavía más rápido a los datos, abriendo posibilidades a nuevas ideas de negocio y procesamiento. PC/4GL Technology Para los 1980's, arriban nuevas tecnologías, tales como las PCs y lenguajes de cuarta generacion (4GLs). Un "Management Information System (MIS)", como fue llamado al principio, pudo ser implementado gracias a dichos avances. Hoy conocido como DSS, el MIS era empleado para ayudar en la toma de decisiones 1.2 Data Warehouse y Business Intelligence Definición La definición universal de un data warehouse fue desarrollada por Bill Inmon en los 1980's: "es una colección de datos, orientados a un tema, integrados, variantes en el tiempo y no-volátiles utilizados en las estrategias de toma de decisiones. Diferentes metodologías y gurus del datawarehousing han dado a este componente distintos nombres, tales como: A staging area. Un variante de "back office" que es una etapa de poner todos los datos operativos juntos. The information warehouse. Un nombre utilizado en los inicio por IBM y algunos otros vendedores. Quién es el usuario? El usuario del data warehouse, también llamado analista DSS, es una persona de negocio en primera instancia y técnico en la segunda. El trabajo principal del analista DSS es definir y descubrir información utilizada en la toma de decisiones corporativas.

4 1.2.3 Business Intelligence BI, en el contexto de data warehouse, es la habilidad de una empresa para estudiar comportamientos y acciones anteriores para entender dónde ha estado la organización, determinar su situación, y predecir o cambiar que pasará en el futuro 1.3 Corporate Information Factory (lugar del dw en el BI) Definición The Corporate Information Factory (CIF) es una arquitectura conceptual aceptada ampliamente que describe y categoriza los almacenes de información utilizados para operar y administrar infraestructuras robustas de BI. Estos almacenes presentan 3 procesos de organización de alto nivel: Business operations están vinculadas con las operaciones del día-a-día. Business intelligence están enfocados con la búsqueda de un mejor entendimiento de la compañía, sus productos y clientes. Mientras que los procesos de operación de negocio son estáticos, los de BI están evolucionando constantemente (aunque también posee algunos estáticos). Business management es la función en la cual el conocimiento y nuevas ideas desarrolladas en la BI son institucionalizadas e introducidas en las operaciones diarias de la empresa; es decir, las hace parte de sus estrategias.

5 1.3.2 Componentes de la CIF Estos componentes han sido separados en 2 grupos de componentes y procesos: Getting data in consiste de los procesos y bases de datos involucrados en adquirir datos desde los sistemas en operación, integrarlos, limpiarlos y colocarlos en una base de datos de fácil uso. Los componentes de la CIF que se encuentran realizando esta función son: The operational system databases (source systems) que contienen datos utilizados en el correr del día a día del negocio de la compañía. Estos son todavía la mayor fuente de datos para los ambientes de toma de decisiones. The data warehouse es una colección o repositorio de datos integrados, detallados e históricos para apoyar al proceso de toma de decisiones. The operational data store es una colección de datos integrados, detallados y actuales para apoyar al proceso de toma de decisiones. Data acquisition es un conjunto de procesos y programas que extraen datos para el data warehouse y el operational data store desde los sistemas en operación. Además de incluir tareas de transformación y limpieza, esta capa también incluye un conjunto de procesos de control para el aseguramiento de la integridad de los datos. Getting information out consiste de los procesos y bases de datos involucradas en entregar BI al cliente de negocio o analista. Los componentes de la CIF para esta función son: The data marts son derivados del data warehouse, utilizados para proveer a

6 la comunidad de negocio el acceso a varios tipos de estrategias de análisis. The oper marts son derivados del ODS y utilizados para proveer a la comunidad de negocio con acceso dimensional a los datos actuales de operación. Data delivery es el proceso que mueve datos desde el data warehouse hacia los data y oper marts. Similar a la capa de adquisición, manipulan datos mientras los mueven Operational Systems Son los sistemas que soportan las actividades día-a-día de la empresa Data Acquisition Muchas compañías son tentadas a saltarse el paso crucial de verdaderamente integrar sus datos, escogiendo en su lugar desplegar una serie de no coordinados, no integrados data marts. Esto provoca que terminen con información aisladas o específica para un departamento específico, los cuales no pueden combinarse para producir información válida y obviamente no pueden ser compartidos a través de la empresa Data Warehouse Actua como el punto central de integración de datos, es el primer paso hacia la conversión de datos en información. Propósitos de Data Warehouse Brinda una vista común de todos los datos, sin importar como serán usados posteriormente por los clientes. Dada la enorme necesidad de información histórica, el dw puede crecer a proporciones inmensas ( 20 o 100 terabytes o más). Finalmente, es el encargado de proveer de datos a cualquier tecnología de análisis dentro de la comunidad de negocio. Esto es, muchos data marts pueden ser creados a partir de los datos contenidos en el dw, NO cada data mart tiene sus propios métodos de producir y consumir datos Operational Data Store El operational data store (ODS) es utilizado para decisiones tácticas, mientras que el dw soporta decisiones estratégicas Está orientado a un tema, como lo hace el data warehouse Sus datos están completamente integrados, como en el data warehouse. Sus datos son actuales (tanto como sea posible). Sus datos son volátiles y actualizables (a diferencia de lo estático del

7 datawarehouse) Sus datos son detallados casi completamente con un mínimo de agregación dinámica o sumarización. Contiene datos a nivel transacción Data Delivery Está generalmente limitado a operaciones tales como agregación de datos, filtros por dimensiones específicas, reformateo de datos para facilitar el acceso de usuarios o herramientas de BI y finalmente transmitir datos a través de la organización Data Marts Son un subconjunto del dw y es donde la mayor parte de las actividades analíticas de BI toman parte. Los datos en cada data mart son adaptados para una función particular, tales como análisis de beneficios, análisis demográficos, etc. Cada data mart no es necesariamente válido para otros usos Meta Data Management Es el conjunto de procesos que recolectan, administran y despliegan meta datos a través de la CIF. Existen de 3 tipos: Technical Business Administrative Information Feedback Es el mecanismo de compartición que permite al conocimiento y la inteligencia ser compartidos con otros data stores, según sea apropiado. Aca se habla de una "Learning organization" Information Workshop Es el conjunto de herramientas disponibles para los usuarios de negocio, para ayudarles en el uso de recursos de la Corporate Information Factory. Provee medios para organizar y categorizar los datos y otros recursos.

8 Operations and Administration Incluye el soporte crucial y las funciones de infraestructura necesarias para el crecimiento sostenible. 1.4 Rol y propósito de un Data Warehouse Rol No sirve únicamente como punto de integración, debe servir también como punto de distribución Características de un data warehouse. Debe estar enfocado a la empresa. Será utilizado primeramente por múltiples departamentos o muchas compañías o subdivisiones. Su diseño debe ser resistente al cambio, tanto como sea posible. Dado que es utilizado para almacenar datos masivos a través de los años, es poco deseable tener que descargar datos, rediseñar la base de datos entonces volver a cargar los datos. Para evitarlo, hay que pensar en términos de procesos independientes, aplicaciones independientes y modelos de datos independientes de la tecnología de BI. Debe ser diseñado para cargar cantidades enormes y masivas de datos en corto tiempo. La base de datos del dw debe ser creada con un mínimo de redundancia o duplicados de atributos o entidades. Para ello se emplean técnicas de paralelización, carga de datos por bloque y API's nativos. Debe ser diseñado para el procesamiento óptimo de la extracción por los programas de entrega (delivery programs). Esto es crucial ya que de aquí se alimentan los data marts. Debe estar en un formato que permita el análisis de muchas o todas las tecnologías de BI Tipos de Data Marts soportados OLAP data mart. Están diseñados para apoyar el análisis multidimensional realizado por las herramientas de software de OLAP. Exploration warehouse. Mientras que el común de los data marts son diseñados para soportar tipos específicos de análisis y reporteo, el almacén de exploración es construido para proveer navegación exploratoria "ad hoc" a través de los datos. Data-mining o statistical warehouse. Es un data mart especializado en dar a investigadores y analistas la habilidad de profundizar en relaciones conocidas o desconocidas de datos y eventos, sin tener nociones preconcebidas de dichas

9 relaciones. Customizable analytical applications. Estas nuevas adiciones permiten la refinación de aplicaciones de manera efectiva y económica Extract Program El programa de extracción es el más simple de todos los programas. Recorre a través de un archivo o base de datos, utiliza un criterio de selección de datos y, encontrando los datos calificados para dicho criterio, transporta los datos hacia otro archivo o base de datos. Debido a que el proceso de extracción mueve datos lejos del alto rendimiento del OLTP, no hay conflictos en términos de velocidad al momento de ser analizados en masa. Cuando los datos son movidos fuera del OLTP, lejos del procesamiento de transacciones, un cambio en el control ocurre. El usuario final posee los datos una vez que ha tomado control de ellos.

10 1.5 Problemas con una arquitectura naturalmente evolutiva La arquitectura evolutiva presenta muchos retos, tales como: Credibilidad de los datos (Data credibility) Productividad (Productivity) Problemas para transformar datos en información (Inability to transform data into information) Credibilidad de los datos (Data credibility) La crisis es extensa y predecible. Por qué?, básicamente por 5 razones: Los datos no tienen base de tiempo La diferencia algorítmica de los datos Los niveles de extracción El problema de datos externos No hay una fuente común de datos desde el principio

11 1.5.2 Productividad (Productivity) Ej. El diseñador asigna la tarea que propone 3 cosas a realizar para producir un reporte: Localizar y analizar los datos para el reporte. Compilar los datos para el reporte. Conseguir un programador/analista para realizar estas 2 tareas.

12 La siguiente tarea para producir el reporte es compilar los datos una vez localizados. El programa deber ser escrito de manera simple y debe obtener la información de distintas fuentes, esto es complicado por las siguientes razones: Muchos programas deben ser escritos. Cada programa deber modificado para requisitos particulares. Los programas atraviesan toda tecnología que la compañía utiliza.

13 1.5.3 Problemas para transformar datos en información (Inability to transform data into information) Poca integración de datos

14 No hay material histórico Cambio de estrategias

15 Algunas de las diferencias entre las dos: Datos primitivos son datos utilizados para correr las operaciones día-a-día de la compañía. Datos derivados han sido resumidos o calculados para cumplir con las necesidades administrativas de la compañía. Datos primitivos pueden ser actualizados. Datos derivados pueden ser recalculados pero nunca actualizados directamente. Datos primitivos son datos primariamente "actuales". Datos derivados son a menudo datos históricos. Datos primitivos son operados por procedimientos repetitivos. Datos derivados son operados por heurísticas, programas y procedimientos no repetitivos. Datos operativos son primitivos, datos DSS son derivados. Datos primitivos soportan funciones administrativas. Datos derivados soportan funciones directivas. 1.6 El ambiente de la arquitectura Niveles

16 El ambiente departamental - algunas veces llamado nivel de data mart, nivel de OLAP, o nivel multidimensional del DBMS contiene información útil para los distintos departamentos físicos de una compañía. Existe una base de datos para el departamento de marketing, una para el de contabilidad, otra para el actuarial, etc. El data warehouse es la fuente de todos estos datos departamentales. Mientras que el data mart ciertamente relaciona los datos encontrados en el nivel operacional o el data warehouse, los datos encontrados en la departamental o data mart son fundamentalmente diferentes de los datos en el datawarehouse, porque los datos del data mart están denormalizados, resumidos y

17 formados por los requerimientos de operación de un solo departamento. El nivel final de datos es el nivel individual. Los datos individuales son usualmente temporales y pequeños. Muchos análisis heurísticos son realizados a este nivel. Como regla, los niveles individuales de datos son asistidos por la PC. Executive information systems (EIS) típicamente están a este nivel Integración de datos en el contexto de la arquitectura No hay un solo punto desde la extracción de datos del ambiente de OLTP hacia el datawarehouse, que no lleve integración. Si la información llega al dw en un estado no integrado, no puede ser utilizada para ayudar a la vista corporativa de los datos (vista global), lo cual es esencial Extract/transform/load (ETL) Software puede automatizar muchos de estos procesos tediosos. Además, este proceso de integración tiene que ser realizado solo una vez; pero de cualquier forma es necesario que los datos fluyan hacia el datawarehouse de manera integrada, no solamente aventada.

18 1.7 The Development Life Cycle

19 1.8 Patterns of Hardware Utilization 1.9 Monitoring the Data Warehouse Environment Una vez que el datawarehouse es construído, debe ser mantenido. Un componente principal del mantenimiento de un data warehouse es la administración del rendimiento, que comienza monitoreando el ambiente del data warehouse. Algunos de los resultados importantes que son obtenidos al realizar el monitoreo son: Identificar qué crecimiento esta ocurriendo, dónde esta ocurriendo el crecimiento y en que porcentaje Identificar qué datos están siendo utilizados Calcular el tiempo de respuesta que está teniendo el usuario final

20 Determinar quién realmente está utilizando el data warehouse Especificar que cantidad de datos están siendo utilizados por los usuarios finales Localización de dónde están siendo utilizados los datos Reconocer que tánto esta siendo usado el data warehouse Examinar el nivel de uso del data warehouse Los perfiles de datos que pueden ser creados durante el proceso de monitoreo de datos son los siguientes: Un catálogo de todas las tablas en el warehouse Un catálogo del contenido de esas tablas Un perfil del crecimiento de las tablas en el data warehouse Un catálogo de los índices disponibles para una entrada en las tablas Un catálogo de las tablas resumidas y las fuentes para dicho resumen La necesidad de monitorear la actividad en el datawarehouse es ilustrada por las siguientes preguntas: Qué esta siendo accesado? Cuándo? Por quién? Qué tan frecuente? En qué nivel de detalle? Cuál es el tiempo de respuesta para la solicitud? En que punto del día es enviada la solicitud? Qué tan grande fue la solicitud? Fue terminada la solicitud o terminó naturalmente? Lectura: