Sistema DataWarehousing Carga y control de Calidad INFORME PRINCIPAL Raquel Abella, Luca Cppola, Diego Olave

Sistema DW: Carga y Control de Calidad Proyecto de Grado de la Carrera Ingeniera en Computacin Facultad de Ingeniera Universidad de la Repblica,1999 Raquel Abella Luca Cppola Diego Olave Tutor: Ral Ruggia Informe Principal 2

Sistema DW: Carga y Control de Calidad 5(680(1 '( &217(1,'2 INTRODUCCION INTRODUCCION Contexto Objetivos del Proyecto Experiencia Anterior Pricipales Aportes Visin Glo bal del Sistema Organizacin del Informe Cmo leer el Informe CONOCIMIENTO EXISTENTE CONOCIMIENTO EXISTENTE Introduccin al Datawarehousing Calidad de Datos Arquitectura de DW Diseo de DW SISTEMA DESARROLLADO SISTEMA DESARROLLADO Planteo del Sistema Estrategia de Desarrollo Descripcin Tcnica del Desarrollo CONCLUSIONES CONCLUSIONES Conclusiones Finales Agradecimientos Bibliografia Informe Principal 3

Sistema DW: Carga y Control de Calidad DESARROLLO SISTEMA DW APARTADO 1 DataMart: Presupuesto Requerimientos Anlisis Diseo Implementacin DataMart: Bedela Re querimientos Anlisis Diseo Implementacin Apndice: Tcnica para Identificacin de datos R equeridos METADATA DEL SISTEMA DW APARTADO 2 Analisis General Mapeos Modelos Conceptuales - Modelos Fsicos Anlisis Detallado Ma peos Modelos de Datos Seleccionados - Modelos Fsicos Base de Datos del DW Pseudocd igo Procesos de Carga MANUAL DE USUARIO APARTADO 3 Manual de usuario del sistema desarrollado Informe Principal 4

Sistema DW: Carga y Control de Calidad &217(1,'2 1 INTRODUCCIN.................................................................... .................................................................6 1.1 CONTEXTO ................................................................................ ...........................................................7 1.2 EXPERIENCIA ANT ERIOR .......................................................................... .............................................8 1.3 OBJETIVOS DEL PROYECTO ...... ................................................................................ ..............................8 1.4 PRINCIPALES APORTES ........................ ................................................................................ ..................9 1.5 VISIN GLOBAL DEL SISTEMA ................................ ............................................................................10 1 .6 ORGANIZACIN DEL INFORME ...................................................... .......................................................12 1.7 CMO LEER EL INFORME ............................................................................... ......................................14 2 CONOCIMIENTO EXISTENTE .............. ................................................................................ ................16 2.1 INTRODUCCIN AL DATA WAREHOUSING .......................... ...........................................................17 2.1.1 Data warehou se.............................................................................. ...........................................17 2.1.2 DATA WAREHOUSING ........... ................................................................................ ................19 2.2 CALIDAD DE DATOS......................................... ............................................................................23 2 .2.1 Un enfoque prctico ......................................................... ........................................................24 2.2.2 Evolucin ....... ................................................................................ ..........................................25 2.2.3 Soluciones .................. ................................................................................ ..............................26 2.2.4 Herramientas ............................ ................................................................................ ...............28 2.2.5 Calidad en un DATA WAREHOUSE ........................... ...............................................................31 2.3 ARQUITECTU RA DEL DATA WAREHOUSE .......................................................... ....................................41 2.3.1 Data warehouse Central ............ ................................................................................ ...............41 2.3.2 Estrategias Data Marts ................................. ............................................................................42 2 .4 DISEO DE UN DATA WAREHOUSE.................................................... ........................................44 2.4.1 Introduccin..................... ................................................................................ ........................44 2.4.2 'A transformations based approach for designing the Data Warehouse'.....................................44 2.5 REFERENCIAS .... ................................................................................ .................................................48 3 SISTEMA DESARROLLADO ..... ................................................................................ ............................49 3.1 PLANTEO DEL SISTEMA.......................... ................................................................................ .....50 3.2 ESTRATEGIA DE DESARROLLO ........................................... .......................................................51 3.2.1 Desarrollo de un Data Mart ..................................................................... ................................55 3.3 DESCRIPCION TECNICA...................... ................................................................................ ...........62 4 CONCLUSIONES ................................................... ................................................................................ ..71 4.1 CONCLUSIONES FINALES .................................................. ...................................................................72 4.2 AGRADE CIMIENTOS.......................................................................

......................................................78 4.3 BIBLIOGRAFIA....... ................................................................................ .............................................79 Informe Principal 5

Sistema DW: Carga y Control de Calidad INTRODUCCIN 1 1 INTRODUCCIN Informe Principal 6

Sistema DW: Carga y Control de Calidad &217(;72 Este proyecto surge como propuesta del rea Base de Datos del Instituto de Computa cin (I.N.CO) de la Facultad de Ingeniera de la Universidad de la Repblica (F.I.). E l mismo se enmarca dentro de un conjunto de trabajos presentados a los estudiant es como opciones al proyecto de grado de la carrera Ingeniera en Computacin. La id ea es continuar el desarrollo de un Sistema de Data Warehousing (DW) para el I.N .CO. Dividir el proyecto global en dos grupos de desarrollo y as presentar dos pr oyectos diferentes que apunten al mismo objetivo. Se presentan entonces, los pro yectos 'Sistema de DW: OLAP (OnLine Analytical Process)' y 'Sistema de DW: Carga y Control de Calidad'. Ambos tienen un fin comn, continuar el desarrollo del Sis tema de DW para el I.N.CO realizado en el ao 1997 y seguir investigando en el tem a data warehousing. Este proyecto 'Sistema de DW: carga y control de calidad', a punta a construir el data warehouse relacional, con el cual el proyecto 'Sistema de DW: OLAP' trabajar, para mostrar la informacin requerida por el usuario. Las c aracterstica principal del sistema a desarrollar, es su naturaleza gerencial. El mismo, facilitar el proceso de toma de decisiones de dos Comisiones dentro de la F.I., la Comisin de Seguimiento de la Carrera y la Comisin de Administracin del Pre supuesto. Para esto, el sistema permitir el seguimiento de los estudiantes en sus carreras y el anlisis en el tiempo del manejo del presupuesto de la facultad. Es to permitir detectar tendencias dentro de cada una de stas reas, informacin valiosa al momento de tomar decisiones importantes. La duracin del proyecto es de 9 meses a partir de junio de 1998, con opcin a prrroga de 3 meses y es monitoreado por el profesor Ing. Raul Ruggia. 1 Informe Principal 7

Sistema DW: Carga y Control de Calidad

;3(5,(1&,$ 17(5,25 1 El proyecto continua el camino comenzado en el ao 1997 por el proyecto 'Estudio d e Tcnicas y Software para la construccin de sistemas de DW' [P21]. El mismo, fue l a primer experiencia en el desarrollo de un sistema de DW dentro del Area Base d e Datos del I.N.CO. Los puntos a destacar en dicho proyecto son, el desarrollo d e un Sistema de DW para el I.N.CO y la metodologa utilizada. Las sugerencias pres entadas en dicho proyecto, promovieron nuevos estudios e investigaciones. Resalt amos entre ellas, la necesidad de profundizar en la formalizacin y documentacin de l desarrollo de un Sistema de DW y la importancia de enriquecer la metodologa pro puesta con conclusiones extradas de desarrollos tericos y otras experiencias prctic as. Se cita ste trabajo por considerarlo la base a partir de la cual nace la prop uesta de sta proyecto. El cual, mucho tiene que ver con la experiencia realizada, las concluciones obtenidas y las sugerencias propuestas en el proyecto anterior . N %-(7,926 '(/ 352<(&72 Realizar el diseo, carga, control de calidad e implementacin de un data warehouse relacional. Investigar el tema Calidad de Datos en un sistema DW. Continuar la e xperiencia realizada el ao 1997 por el proyecto 'Estudio de Tcnicas y Software par a la construccin de sistemas de DW'. Experimentar una nueva forma de desarrollar un Sistema de DW, dividindolo de forma horizontal en dos mdulos: A. Diseo, carga, c ontrol de calidad e implementacin de un data warehouse relacional B. Construccin d el Modelo Multidimensional, diseo e implementacin de consultas de usuario final. A plicar en el diseo del data warehouse, la teora desarrollada en el trabajo 'A tran sformations based aproach for designing the Data Warehouse' presentado como tesi s de maestra por la profesora Ing. Adriana Marotta. N N N N Informe Principal 8

Sistema DW: Carga y Control de Calidad 35,1&,3$/(6 $3257(6 El principal aporte de ste proyecto es el Sistema de DW construido, la experienci a realizada a lo largo de su desarrollo y su documentacin. La estrategia de desar rollo creada, los problemas que se presentaron, cmo se resolvieron y las conclusi ones que se obtuvieron. El Sistema de DW construido permite al usuario el anlisis de la evolucin universitaria de los estudiantes y del presupuesto de la Facultad de Ingeniera. Mediante la formulacin de consultas a partir de la informacin presen tada, el usuario podr visualizar datos valiosos para su rea de negocio en particul ar. La Estrategia de Desarrollo surge a partir del estudio sobre el conocimiento existente en la materia, de la inventiva del grupo y de la experiencia obtenida durante el transcurso del taller. Dentro del conocimiento existente en la mater ia se puso nfasis en los temas Calidad de Datos y Diseo de un Data Warehouse Relac ional. Del estudio sobre Calidad de Datos, se destaca la importancia del mismo e n un sistema de DW, su evolucin y las soluciones existentes al momento. El estudi o sobre el tema Diseo de un Data Warehouse Relacional, se bas en el trabajo 'A tra nsformations based aproach for designing the Data Warehouse' presentado por la p rof. Ing. Adriana Marotta en su tesis de maestra. La experiencia fue enriquecedor a en ambos sentidos ya que ste proyecto aplic por primera vez el conjunto de primi tivas presentadas en el trabajo mencionado. La experiencia realizada actu de feed back para el desarrollo de dicho trabajo el cual, se desarroll en paralelo al pro yecto. Se incluy ambos temas dentro de la estrategia de desarrollo presentada. Re specto del tema Calidad de Datos, se logr que la estrategia de desarrollo asegure de alguna manera la calidad en los datos del data warehouse relacional. En cuan to al tema Diseo de un Data Warehouse Relacional se aplica el conjunto de primiti vas presentadas en el trabajo mencionado al realizar el diseo del data warehouse. Consideramos interesante, la experiencia realizada en cuanto a la divisin horizo ntal del trabajo. La forma en que interactuamos con los estudiantes del otro pro yecto, como result, qu dificultades se presentaron y como se solucionaron. 1 Informe Principal 9

Sistema DW: Carga y Control de Calidad 9,6,1 */2%$/ '(/ 6,67(0$ El sistema de DW construido, constituye uno de los resultados principales de est e proyecto. El sistema apoya el proceso de toma de decisones de dos comisiones d e la F.I., la Comisin de seguimiento de los estudiantes en la carrera y la Comisin de administracin del presupuesto. Se construyen dos data marts identificados com o Presupuesto y Bedela. Cada data mart mantiene informacin relevante a su rea de ne gocio. El data mart de Presupuesto almacena informacin sobre el presupuesto de la facultad y el de Bedela sobre el comportamiento de los estudiantes en sus carrer as. Los datamarts estn constitudos por tablas relacionales que forman parte del da tawarehouse y cubos multidimensionales. En este proyecto, el termino data mart s e refiere al conjunto de tablas relacionales. En estos terminos, el data warehou se puede verse como la integracin de ambos data marts, la cual en ste caso es triv ial por no existir informacin compartida. La figura 1 detalla los componentes del sistema DW construdo. 1 Figura 1: Visin global del Sistema Informe Principal 10

Sistema DW: Carga y Control de Calidad Base de datos Sistemas Operacionales: Conjunto de bases de datos de los sistemas operacionales que son fuente de datos del data warehouse. Distintos procesos de carga se encargan de extraer los datos de dichas bases y de ingresarlos al data warehouse. Base de datos del Data Warehouse: Base de datos donde se encuentran los datos de los data marts de Presupuesto y Bedela. En el primer subnivel de la base de datos del data warehouse estn las bases de datos auxiliares. En el caso d e presupuesto son bases limpias porque contienen los datos extrados de las fuente s luego de ser transformados, limpiados e integrados. En el caso de bedela, se en cuentran los datos extrados de la base de datos fuente de Bedela. Estos son ingres ados a la bd. del datawarehouse mediante el comando LOAD de Oracle, pero no se r ealiza ningn tipo de transformacin o limpieza en ste proceso. Cabe resaltar que el proceso de carga de los datos fuente a la bd. auxiliar de Bedela no forma parte d e ste proyecto. Distintos procesos de carga son los encargados de llevar los dato s desde las bases de datos auxiliares, transformarlos adecuadamente e ingresarlo s a su respectivo data mart. Las bases de datos de los data marts de Presupuesto y Bedela constituyen los data marts relacionales del sistema, se encuentran en u na base Oracle. Los distintos procesos de carga constituyen la carga del sistema , son procesos PLSQL almacenados en el data warehouse. Son llamados desde una ap licacin Visual Basic que oficia de interfaz grfica de integracin de procesos de car ga. Dentro del data warehouse se encuentran tambin los diccionarios de datos ambo s data marts. Cada diccionario est constitudo por el catlogo que provee la herramie nta Impromptu de Cognos. Bases de datos multidimensionales: Constitudas por difer entes cubos multidimensionales. Los cubos extraen los datos de los data marts qu e se encuentran en el data warehouse. Toman los datos segn lo definido en el dicc ionario de datos correspondiente a cada data mart. Los cubos estn implementados c on la herramienta PowerPlay de Cognos[www.Cognos.com]. Herramientas de consulta: Distintas herramientas de usuario final que permiten consultar los cubos multid imensionales o directamente el data warehouse. Las herramientas de consulta util izadas son las brindadas por el paquete Cognos. Metadata del sistema: Abarca tod os los niveles, documenta la informacin sobre los datos manejados en todo el sist ema. La divisin horizontal del trabajo de construr el sistema completo puede verse con facilidad en la figura. Las flechas a la derecha indican el alcance de la t esis Sistema DW: Carga y control de calidad y de la tesis Sistema DW: OLAP [P24]. La primera se ocupa de construir el data warehouse y los procesos de carga. La seg unda se ocupa de construir las bases de datos multidimensionales y configurar la s herramientas de usuario final. 1 1 Informe Principal 11

Sistema DW: Carga y Control de Calidad 25*$1,=$&,1 '(/ ,1)250( Captulo 1: Introduccin Introduccin a la tesis Sistema DW: Carga y Control de calidad. Contexto. Descripcin del contexto en el que se desarrolla el proyecto. Experiencia anterior. Introduc cin general a la tesis 'Estudio de Tcnicas y Software para la construccin de sistem as de Data Warehousing' . Principales aportes. Puntos importantes a destacar de s ta tesis. Visin global del sistema. Descripcin global del sistema construdo. Organi zacin del informe.. Cmo leer el informe. Breve gua de cmo leer el informe segn los in tereses del lector. 1 Captulo 2: Conocimiento Existente Brinda una visin general de los temas relevantes al proyecto. Introduccin. Define los conceptos principales en data warehousing. Calidad de Datos. Estudio del tem a calidad de datos en un sistema de DW. Resume la importancia del tema, su evolu cin, soluciones existentes en el mercado y propone una metodologa de trabajo para asegurar la calidad de los datos en un data warehouse. Arquitectura del Data War ehouse. Describe las posibles arquitecturas de un data warehouse. Diseo del Data warehouse.Introduce la tcnica utilizada para disear el data warehouse relacional. Presenta el trabajo de maestra A transformations based aproach for designing the D ata Warehouse de la Ing. Adriana Marotta. Captulo 3: Sistema Desarrollado Visin global del desarrollo del proyecto. Planteo del Sistema. Describe las carcte rsticas principales del sistema DW. Estrategia de Desarrollo. Propone Estrategia de Desarrollo en base al planteo anterior. Informe Principal 12

Sistema DW: Carga y Control de Calidad Overview del Desarrollo. Diagramas de las etapas principales de la estrategia Pr opuesta y como stas se aplicaron en el desarrollo realizado. 1 Captulo 4: Conclusiones Conclusiones Finales. Conclusiones principales del proyecto. Agradecimientos. Bi bliografa. Apartado 1: Desarrollo del Sistema de DW Documentacin del desarrollo . Aplicacin de estrategia propuesta. Data uesto. Documenta el desarrollo del Data Mart de Presupuesto. Data Mart: ocumenta el desarrollo del Data Mart de Bedela. Apndice: Tcnica para tos Requeridos. Describe la tcnica utilizada para la identificacin de idos en el data warehouse. Mart: Presup Bedela. D Identificar Da datos requer

Apartado 2: Metadata del Sistema de DW Anlisis General. Anlisis General de Bases de Datos Fuente Mapeo: M.Conceptuales-Mo delos Fsicos. Mapea Modelo Conceptuales de Bases Fuente con Modelo Fsico Anlisis De tallado. Anlisis detallado de Bases de Datos Fuente Mapeo: M.Datos Seleccionados. Mapea Modelo de Datos Seleccionados con Modelo Fsico Base de Datos del Data Ware house. Documenta Base de Datos del Data warehouse Pseudocdigo Procesos de Carga. Documenta procesos de Carga Informe Principal 13

Sistema DW: Carga y Control de Calidad Apartado 3: Manual de Usuario Manual de Usuario del sistema desarrollado. Especifica como utilizar el sistema desarrollado. 1 &02 /((5 (/ ,1)250( Se divide el informe en cuatro libros para facilitar su lectura: 1. Informe Prin cipal. Informe central del proyecto. Su lectura brinda una visin general del proy ecto pero no documenta al detalle el desarrollo realizado. 2. Apartado 1. Desarr ollo del sistema Documenta al detalle el desarrollo realizado. La documentacin de l desarrollo sigue el orden propuesto en la estrategia de desarrollo planteada e n el Informe Principal. 3. Apartado 2. Metadata del sistema Contiene Metadata de l sistema desarrollado. Toda informacin del desarrollo realizado, relevante para el mantenimiento y administracin del mismo. 4. Apartado 3. Manual de usuario del sistema Explica cmo utilizar el sistema construdo. Para obtener una visin general d el sistema construdo referirse al punto 1.5 del captulo del Informe Principal. Si no se conoce del tema DW, es fundamental la lectura del captulo 2 del Informe Pri ncipal. De todos modos, algunos puntos del capitulo 2 son importantes para compr ender el desarrollo realizado. En particular, dentro de la seccin 2.2, el punto Ca lidad en un Data Warehouse, fundamenta la postura de la estrategia de desarrollo respecto al tema calidad. Dentro de la seccin 2.4, el punto Diseo de un Data Wareho use, documenta la tcnica utilizada al disear cada data mart. Si se est interesado en conocer la forma de trabajo utilizada, puede referirse a la seccin 3.2 Estrategia de desarrollo. En la misma se documenta una estrategia para construir un data wa rehouse, procesos de carga, asegurar la calidad de los datos dadas las condicion es descriptas en la seccin 3.1 Planteo del proyecto. Las experiencias de desarrollo de los data marts de Presupuesto y Bedela estn documentadas en el Desarrollo del Sistema. Para una buena comprensin de las mismas se recomienda leer las secciones 3.1 y 3.2 del Informe Principal. Informe Principal 14

Sistema DW: Carga y Control de Calidad La metadata del sistema se encuentra en Metadata del Sistema. En el Desarrollo d e Sistema tambin se encuentra informacin del tipo Metadata pero relacionada al des arrollo. El manual de usuario del sistema desarrollado se encuentra en Manual de Usuario. A lo largo del informe se utilizaron los siguientes tips: 1. Resalta l as caractersticas prinicipales de la seccin. 2. Comentarios de nuestra experiencia en particular. Informe Principal 15

Sistema DW: Carga y Control de Calidad ESTADO DEL ARTE 2 2 CONOCIMIENTO EXISTENTE Informe Principal 16

Sistema DW: Carga y Control de Calidad ,1752'8&&,1 $/ '$7$ :$5(+286,1* El siguiente captulo, delinea las ideas principales que hay detrs del concepto dat a warehousing. Las mismas, fueron recogidas de una serie de libros y artculos que documentamos al final del informe. '$7$ :$5(+286( 'A data warehouse is a copy of transaction data specifically structured for quer y and analysis' [Ralph Kimball] 2 2 La necesidad de obtener informacin de las bases de datos operacionales para apoya r el soporte de toma de decisiones, nace junto con el desarrollo de las primeras aplicaciones pero su importancia es reconocida mucho tiempo despus. El primer in tento por satisfacer sta necesidad fue la construccin de reportes, stos listaban la informacin existente en las bases de datos. Luego se utilizaron los extractos, r ecabando informacin de ms de una base de datos, no pudindose resolver los problemas de consistencia de datos e integracin que se presentaban. Con el advenimiento de l PC, los usuarios creyeron que se independizaban de los desarrolladores pudiend o acceder ellos mismos a las bases de datos para obtener la informacin de su inte rs. Pero, con todo el poder que brinda el PC, hubo frustracin al descubrir que los datos que llegaban no eran mejores que aquellos con los que se dispona antes. Figura 2: Arquitectura decisional antes del data warehouse Se acepta finalmente, la incapacidad de las antiguas aplicaciones de satisfacer la necesidad de informacin que requieren las organizaciones para ser ms competitiv as y eficientes. Los Informe Principal 17

Sistema DW: Carga y Control de Calidad sistemas operacionales, satisfacen los requerimientos operativos de la organizac in pero no estn diseadas para apoyar al proceso de toma de decisiones. Es aqu cuando se decide separar el procesamiento de datos en dos grandes categoras: Operaciona l y Decisional. Aparece entonces una nueva arquitectura, la cual tiene como prin cipal componente, el Data Warehouse. Las siguientes figuras ilustran las solucio nes para la obtencin de informacin decisional, antes y despus de la arquitectura da ta warhouse. 2 Figura 3: Nueva arquitectura para manejo de informacin Un data warhouse es una base de datos diferente a la de los sistemas operacional es en cuanto a que: N Es orientado a sujetos N Maneja grandes cantidades de info rmacin N Comprende mltiples versiones de un esquema de bases de datos N Condensa y agrega informacin N Integra y asocia informacin de muchas fuentes de datos Un dat a warehouse organiza y orienta los datos desde la perspectiva del usuario final. Muchos sistemas operativos organizan sus datos desde la perspectiva del negocio , para mejorar la rapidez de acceso y actualizacin de los datos. Este tipo de org anizacin, no es la ms indicada para operacines de consulta, tpicas en el ambiente de cisional. La mayora de los data warehouses contienen informacin histrica que se ret ira con frecuencia de los sistemas operativos porque ya no es necesaria para las aplicaciones operacionales y de produccin. Por la necesidad de administrar tanto la informacin histrica como la actuales, un data warehouse es mayor que las bases de datos operacionales. Un data warehouse guarda informacin histrica y la adminis tra. Como la informacin histrica muchas veces es manejada por diferentes versiones de esquemas de bases de datos, el data warehouse debe controlar la informacin or iginada por bases de datos diferentes. 18 Informe Principal

Sistema DW: Carga y Control de Calidad Un data warehouse condensa y agrega la informacin para presentarla en forma compr ensible a las personas. La condensacin y adicin es esencial para retroceder y ente nder la imagen global. Debido a que las organizaciones han administrado histricam ente sus operaciones utilizando numerosas aplicaciones de software y mltiples bas es de datos, se requiere de un data warehouse para recopilar y organizar en un s olo lugar la informacin que stas aplicaciones han acumulado al paso de los aos. '$7$ :$5(+286,1* 2 ' A warehouse is a place, warehousing is a process' [R. Hackathorn] Un data ware house es una base de datos, pero por s sola no significa nada, hay una gran canti dad de procesos detrs de una arquitectura de data warehouse de suma importancia p ara el mismo. Estos comprenden desde procesos de extraccin que estudian y selecci onan los datos fuente adecuados para el data warehouse hasta procesos de consult a y anlisis de datos que despliegan la informacin de una forma fcil de interpretar y analizar. Procesos bsicos de un data warehouse [L2]: Extraccin: El proceso de ex traccin consiste en estudiar y entender los datos fuente, tomando aquellos que so n de utilidad para el data warehouse. Transformacin: Una vez que los datos son ex trados, stos se transforman. Este proceso incluye correccin de errores, resolucin de problemas de dominio, borrado de campos que no son de inters, generacin de claves , agregacin de informacin, etc. Carga e Indices: Al terminar el proceso de transfo rmacin, se cargan los datos en el data warehouse. Chequeo de Calidad: Una vez ing resada la informacin al data warehouse, se realizan controles de calidad para ase gurar que la misma sea correcta. Liberacin/Publicacin: Cuando la informacin se encu entra disponible, se le informa al usuarios. Es importante publicar todo cambios que se hallan realizado. Consulta: El usuario final debe disponer de herramient as de consulta y procesamiento de datos. Este proceso incluye consultas ad hoc, reportes, aplicaciones DSS, data mining, etc. Informe Principal 19

Sistema DW: Carga y Control de Calidad Feedback: Aveces es aconsejable seguir el camino inverso de carga. Por ejemplo, puede alimentarse los sistemas legales con informacin depurada del data warehouse o almacenar en el mimso alguna consulta generada por el usuario que sea de inte rs. Auditora: Los procesos de auditora permiten conocer de donde proviene la inform acin as como tambin qu clculos la generaron. Seguridad: Una vez construdo el data ware house, es de inters para la organizacin que la informacin llegue a la mayor cantida d de usuarios pero, por otro lado, se tiene sumo cuidado de protegerlo contra po sibles 'hackers', 'snoopers' o espas. El desarrollo de Internet a incrementado ste dilema. Respaldo y Recuperacin: Se deben realizar actividades de backup y restor e de la informacin, tanto la almacenada en el data warehouse como la que circula desde los sistemas fuente al data warehouse. 2 ELEMENTOS BSICOS EN UN SISTEMA DW Un data warehouse es una base de datos, data warhousing es un proceso. Un sistem a de DW est compuesto por todas esas cosas y algunas ms. A continuacin detallamos l os componentes fundamentales de un sistema de DW [L2]. Figura 4: Elementos de un data warehouse Informe Principal 20

Sistema DW: Carga y Control de Calidad Sistemas Fuente : Es un sistema operacional, cuya funcin es capturar las transacc iones tpicas del negocio. La prioridad en este tipo de sistema la tienen las oper aciones de actualizacin. Las consultas sobre estos sistemas son simples y su dema nda est restringida. Mantienen pocos datos histricos. Data Staging Area : Area de almacenamiento y un conjunto de procesos que limpian, transforman, combinan, qui tan duplicados, archivan y preparan los datos fuente para ser utilizados en el d ata warehouse. Servidor de Presentacin : Mquina fsica en donde se almacenan y organ izan los datos del data warehouse para luego ser consultados por reportes, consu ltas de usuario y otras aplicaciones. Modelo Dimensional : Disciplina especfica p ara modelar datos que es una alternativa al modelo entidadrelacin. Data Mart : Es un conjunto lgico del data warehouse. Un data warehouse se construye como la int egracin de varios data marts. Data Warehouse : Fuente de datos apta para consulta s en una organizacin. Operational Data Store : Lugar en donde se integran los sis temas operacionales antes de ser cargados al data warehouse. OLAP (On-Line Analy tic Processing) : La actividad de consultar y presentar de una forma especfica lo s datos del data warehouse. ROLAP (Relational OLAP) : Conjunto de interfaces de usuario y aplicaciones que dan a las bases relacionales un sabor multidimensiona l. MOLAP (Multidimensional OLAP) : Conjunto de interfases, aplicaciones y bases de datos propietarias que tienen un fuerte sabor multidimensional. Aplicacin Usua rio Final : Coleccin de herramientas que consultan, analizan y presentan la infor macin necesaria para apoyar las necesidades del negocio. 2 Informe Principal 21

Sistema DW: Carga y Control de Calidad Herramientas de Acceso de Usuario Final : Son clientes del data warehouse, manti enen una sesin con el servidor de presentacin mandndole sentencias SQL. La informac in obtenida es presentada de forma de pantalla, reporte, grfico o alguna otra form a de anlisis del usuario . Herramientas de Consultas Ad Hoc : Es un tipo especfico de herramienta de acceso a los datos que invita al usuario a formularse sus pro pias consultas manipulando directamente las tablas relacionales. Aplicaciones de Modelado : Cliente sofisticado del data warehouse, con capacidad analtica. Entre ellas se encuentran las herramientas de data mining. Metadata : Toda informacin en el data warehouse que no sean los datos almacenados. 2 Informe Principal 22

Sistema DW: Carga y Control de Calidad

&$/,'$' '( '$726 En este captulo desarrollaremos el tema de calidad de datos, donde se muestra la evolucin del tema, los problemas frecuentes en los datos, las caractersticas de la s soluciones planteadas hasta el momento y las herramientas que han surgido en e l mercado. Por ltimo se plantean un proceso de limpieza de datos a realizarse dur ante la carga de un data warehouse y una gua para mantener la calidad en los dato s. Desde un principio las organizaciones empresariales se han visto atradas por l a evolucin tecnolgica. En el mundo de hoy es difcil encontrar empresas que no utili cen la tecnologa informtica como herramienta para manejar su negocio o parte de l, y ms difcil an es encontrar empresas que dejando de lado la tecnologa, logren domina r su mercado. En el comienzo, el uso mayoritario que se les daba a las computado ras, era el de procesamiento de transacciones, de modo de disminuir el tiempo de los procesos internos del negocio. Esta focalizacin en la automatizacin de los pr ocesos, sin embargo, ignoraba el valor que tienen los datos dentro de los sistem as, y desaprovechaba la ganancia que brinda su anlisis. El rol de la informacin en crear ventajas competitivas para empresas de negocios y otras compaas es ahora bi en conocido, y casi se ha convertido en un axioma dentro del mundo de los negoci os. Sin embargo darle un uso productivo a la informacin es un objetivo que slo es alcanzado cuando se logran identificar tres puntos fundamentales: la utilidad qu e se le quiere dar a la informacin, la fuente de donde extraerla y la ubicacin mas apropiada que tendr la misma dentro de la infraestructura de la organizacin, de m odo de sacarle su mayor beneficio. Surge entonces el concepto de arquitectura de informacin que se desarrolla en proyectos como Operational Data Store (ODS), DW y Data Marts, como soluciones a las dificultades de convertir montaas de datos, p roducidos por sistemas operacionales, en datos productivos para el negocio. A su vez, aparecen tecnologas complementarias que ayudan en los procesos de recoleccin , manejo, procesamiento y entrega de informacin til a partir de la masa inicial de datos crudos y desconectados generados en los sistemas operacionales. Desde el mome nto en que las compaas comienzan a usar DW para compartir datos a travs de aplicaci ones y unidades de negocio, aparece el concepto que alcanza todos los puntos ant eriores, el de Calidad de Datos. La frase siguiente resume la importancia del te ma calidad y justifica el estudio del mismo. Si vamos a confiar en la informacin de nuestra organizacin para tomar decisiones de negocio debemos estar seguros que los datos sobre los cuales estamos tomando estas decisiones crticas, son: exacto s, completos y relevantes. 2 Informe Principal 23

Sistema DW: Carga y Control de Calidad El rea de procesamiento de datos es comn enfrentarse a los siguientes planteos: N Acceso a los datos ("Tenemos los datos pero no podemos acceder a ellos"). N Herr amientas de consulta ("Quiero un sistema que me muestre qu es importante y por qu e"). N Calidad de datos ("Sabemos que alguno de nuestros datos no son buenos, po r ejemplo, no tenemos una lista centralizada de clientes"). El mercado de base d e datos ha respondido a la necesidad de acceso a los datos con la arquitectura C liente-Servidor, software y hardware especial para data warehouses y familias en teras de esquemas de comunicacin para conectar usuarios con sus datos. Por otro l ado, el mercado de las herramientas de consultas brinda una gran variedad de pro ductos que van desde herramientas ad-hoc, generadores de reportes, ambientes de desarrollo de aplicaciones, hasta herramientas OLAP/ROLAP y datamining. En cambi o, el tema calidad de datos, a pesar de su conocida importancia, ha sido dejado de lado en la mayora de los casos. 2 Ni la tecnologa de base de datos ms sofisticada, ni la interfaz grfica ms seductora puede asegurar el xito de un data warehouse si los datos son incorrectos. 81 (1)248( 35&7,&2 En el mercado competitivo de hoy en da una compaa exitosa es aquella que construye los vnculos ms fuertes con sus clientes, distribuidores, proveedores y cualquier o tra entidad clave en su negocio, y conoce todas las relaciones entre estas entid ades. Es aquella que tiene la habilidad de extraer informacin significativa a par tir de millones de registros de datos. Es aquella que sabe que la exactitud de l a informacin es un componente crtico para su xito. Con informacin de calidad una com paa puede entender completamente su base de clientes y sus elecciones de compra, e l completo espectro de "holdings" de clientes y la historia de costos de su prov eedor. Puede realmente focalizarse en el cliente. Con informacin de calidad una c ompaa tiene lo que necesita para ser competitiva. Pero cmo puede un negocio reajust ar dcadas de viejos datos para obtener la informacin exacta y temporal necesaria p ara el complejo ambiente empresarial de nuestros das ? Cmo se puede obtener inform acin valiosa y consolidada sobre las relaciones entre clientes de legiones de reg istros, bases de datos, elementos de datos escondidos dentro de campos de texto sin formato ? Cmo se puede reajustar los antiguos sistemas centralizados en las c uentas a uno centralizado en el cliente ? La calidad de los datos es el desafo ms grande que enfrentan aquellas organizaciones que contemplan el cambio hacia un a mplio sistema empresarial o Data Warehouse. Informe Principal 24

Sistema DW: Carga y Control de Calidad Las compaas estn de acuerdo en la importancia del Data Warehouse para el crecimient o de sus negocios. Sin embargo, no es tan claro el camino a tomar para alcanzar el xito dentro de todas las tendencias de desarrollo. (92/8&,1 Inicialmente, la idea fue construir un repositorio de datos nico, centralizado y de alcance empresarial, el cual combinase todos los datos de todos los sistemas y tericamente brindase a todos los usuarios acceso a la informacin apropiada. Aunq ue algunos proyectos tuvieron xito, la mayora fueron extremadamente costosos en di nero, trabajo y tiempo. Uno de los principales temas que surgi, es la inmensa can tidad de datos y metadatos que llegan al warehouse desde distintos sistemas, tod os ellos con valores en diferentes formatos, cumpliendo diferentes estndares y te niendo diferentes significados dependiendo del contexto en el cual se originaron . Respondiendo a estos problemas, la industria decide cambiar la arquitectura de l Data Warehousing y desarrolla el concepto de Data Mart. Con esto, mltiples data marts se distribuyen dentro de la organizacin y son usados por los individuos de ntro de cada departamento para analizar su parte del negocio. Este mtodo ayud a ha cer la tecnologa warehouse mas accesible consumiendo menos tiempo. Pero poco apor ta esta arquitectura al tema de la calidad de los datos. Ahora distintos departa mentos acceden a los mismos datos y tratan de interpretarlos simultneamente desde diferentes contextos. Adems el problema que puede ocasionar un error en un dato, ahora impacta aplicaciones a nivel empresarial. La siguiente lista de problemas en los datos nos ayudar a comprender ms la importancia de la calidad de datos y cm o los datos corruptos pueden impactar en las organizaciones [P6][P19][P2]. 2 PROBLEMA EJEMPLO Los datos se representan en mltiples formatos. Falta de estndares Por ejemplo: dif erentes formas de escribir un nombre, diferentes formas de escribir fechas. Info rmacin decisiva (identificacin de entidades de negocio) Informacin perdida en es in gresada en campos de texto. campos de texto Por ejemplo: se tiene un campo descr ipcin y ah se ingresa la cdula del cliente. Mltiples identificadores de una misma en tidad. Informacin no consolidada Por ejemplo: un mismo cliente con distintos cdigo s. Entidades de negocio representadas en una amplia variedad de Comparacin comple ja y formas dificulta relacionar todas las instancias o condensarlas consolidacin en una representacin nica. Informe Principal 25

Sistema DW: Carga y Control de Calidad Valores en los datos que escapan de las descripciones de los campos y de las reg las de negocio. Por ejemplo: nombres comerciales mezclados con nombres Sorpresas de datos dentro personales, indicaciones de ubicacin en campos de de campos indi viduales direcciones, uso inconsistente del espacio en blanco, caracteres especi ales y lmites de campos ( cortar una palabra en un campo y continuar en el siguie nte) Dentro de las cuales se encuentran errores tipogrficos, faltas Errores de or tografas, valores fuera de rango y tipos de datos incorrectos. Palabras que se es criben igual y tienen diferente significados, a Homnimos veces hasta sin relacin o conflictivos, y su significado correcto depende del contexto. Datos con estruct ura y valor apropiados pueden omitir informacin inadvertidamente. Datos que falta n o datos Por ejemplo: la direccin de una persona J.M. Perez 324 invisibles puede s er valida pero si es un edificio se estara omitiendo el numero de apto. En ocasio nes se ingresan valores especiales indicando que el campo tiene valor desconocid o o que no se utiliza ms. Datos Fantasma Por ejemplo: en un campo de fecha se pue de encontrar el valor 99/99/9999 62/8&,21(6 Hasta el momento las compaas lo que han hecho para combatir los problemas vistos a nteriormente, fue limpiar mltiples veces los mismos datos para las diferentes aplic aciones data marts. Por supuesto esto se traduce en esfuerzos duplicados y altos costos y muestra la necesidad de llevar la solucin del problema al nivel de la f uncionalidad del sistema. Esto es, realizando la limpieza de datos a nivel de lo s sistemas funcionales, como una utilidad bsica de la empresa, y obtener as una ef iciencia significativa. Los proyectos de calidad de datos entonces comienzan a c rearse, pero vale la pena analizar en que momento y como. En la mayora de los cas os, la calidad de los datos surge cuando ocurre una crisis y algn proyecto clave corre peligro. Desafortunadamente entonces se desarrollan proyectos especiales q ue no son permanentes ni consistentes en toda la organizacin, y por lo general re sultan en meses de esfuerzo y miles de dlares en soluciones que no son por natura leza permanentes. Tradicionalmente los proyectos de reingeniera de datos carecan d el factor principal para su xito en la compaa: programas para el manejo de la calid ad en los datos, un conjunto de procesos tecnolgicos consistentes que institucion alizaran la calidad de los datos como un bien estratgico, y procesos para explota r su ventaja competitiva. Los requerimientos de reingeniera son de alcance global por naturaleza. A la vez que las compaas quieren crecer en el mercado global, los procesos deben poder soportar una variedad de datos y valores internacionales. Mientras que existe una necesidad de establecer estndares de informacin e Informe Principal 26

Sistema DW: Carga y Control de Calidad identificacin de clientes a nivel mundial, existen pocas referencias disponibles para validar elementos de datos internacionales como nombres de corporaciones, tt ulos, productos y servicios. Una razn ms para insistir en un estndar a nivel empres arial para la calidad de datos. Se llega a la conclusin que el costo asociado a l a limpieza de datos no agrega valor, simplemente lleva los datos a un estado de utilidad y relativa confianza. Es necesario mejorar la calidad de los datos, bus car eliminar los costos, problemas y oportunidades perdidas causados por datos d e baja calidad. EDQM: ENTERPRISE DATA QUALITY MANAGEMENT. 2 Para que un data warehouse sea existoso dos procesos paralelos e igualmente impo rtantes deben ponerse en prctica: la limpieza de los datos y la mejora en la cali dad de los mismos. Para mejorar la calidad de datos se debe prevenir que datos s in calidad entren a la base de datos. Una consecuencia positiva de eliminar la e ntrada de datos incorrectos es la reduccin de los considerables costos que trae a parejado el arreglo de los problemas causados por datos sin calidad. Para establ ecer procesos de limpieza de datos y mejoramiento de calidad efectivos se debe d esarrollar un plan bien definido que incluya un modelo de data warehouse focaliz ado en la empresa, identifique fuentes de datos significativas y establezca el o rden en que se propagarn y transformarn los datos [P2]. La calidad no aparece, req uiere planificacin. Los datos deben ser nombrados y definidos de manera consisten te a lo largo de las reas de negocio para soportar procesos estratgicos y anlisis c ruzados de las funcionalidades del negocio. Cuando se consoliden clientes, produ ctos y rdenes de mltiples fuentes de datos se debe desarrollar una arquitectura co mn con definiciones de datos consistentes, formatos y dominios de valores de dato s. Luego de algunos aos de intentar manejar el tema de la calidad de los datos, u na nueva disciplina ha emergido dentro del desarrollo de arquitecturas de inform acin para dirigir la necesidad de un correcto manejo de la calidad de los datos. Esta disciplina conocida como Enterprise Data Quality Managment (EDQM) tiene com o cometido asegurar la exactitud, temporalidad, relevancia y consistencia de los datos en una organizacin o en mltiples unidades de negocio dentro una organizacin, y de esta forma asegurar que las decisiones se basen en informacin consistente y exacta. El enfoque efectivo de EDQM puede reducir significativamente los costos de la limpieza de datos. Si los datos estuvieran correctos en las fuentes y en un formato definido a nivel empresarial, no se necesitara gastar tanto en la limp ieza de los datos. Esta disciplina pretende redefinir los procesos de negocio y crear estndares a nivel de la organizacin, lo que puede ser extremadamente difcil y costoso si se quiere aplicar en conjunto a toda la organizacin ( big band ). Sin embargo, si se comienza de a una unidad de negocio, utilizando un conjunto de e stndares consistentes con toda la organizacin, hasta Informe Principal 27

Sistema DW: Carga y Control de Calidad abarcar toda la empresa (step by step), se pueden alcanzar los objetivos con men os recursos y aprovechando la experiencia de las unidades que ya lo realizaron. Desarrollar programas para convertir datos de un formato a otro no es difcil. Dis ear procesos para limpiar y estandarizar los datos en una escala empresarial, inc luyendo valores de datos que pueden no ser obvios, es un gran desafo. Afortunadam ente la nueva generacin de soluciones para el manejo de datos provee herramientas de reingeniera de datos y procesos, junto con programas de conversin para asistir a las compaas en la implementacin de programas EDQM.

+(55$0,(17$6 2 Una vez que los expertos en data warehouses y practicantes descubrieron la neces idad de calidad en los datos la pregunta fue: cmo alcanzarla ?. Inicialmente la r eingeniera de datos consista en cdigo escrito manualmente e interpuesto entre las f ases de extraccin de datos y la de carga al data warehouse. Cada proyecto tena nec esidades especficas asociadas con estructuras de datos y contexto especfico y es p or esto que cada proyecto requera lgicas adaptadas a las necesidades de cada clien te para poder alcanzar la calidad de datos requerida para el data warehouse. La limpieza de datos ha crecido desde este proceso inicial de edicin hasta una serie de herramientas de primera y segunda generacin que permiten manejar la calidad d e los datos. Iniciativas proactivas para el manejo de la calidad de los datos co mienzan en la fase de la entrada de datos. Las validaciones en la entrada de dat os son la primer lnea de defensa contra datos errneos, chequean rangos de datos y aseguran que todos los campos requeridos sean llenados durante el proceso de ent rada de datos. La ventaja de chequear la calidad de los datos al momento de la e ntrada es bastante obvia: los errores son "arrancados de cuajo" cuando la inform acin es fresca y de esta forma evitar la necesidad de trabajar doblemente en el f uturo. Las validaciones en la entrada de datos no son de todas formas a prueba d e tontos, as como un corrector ortogrfico no detecta errores gramaticales, el pers onal de entrada de datos puede ingresar cdigos incorrectos en los campos adecuado s en el correcto formato y rango y el error no ser detectado. Este es el motivo p or el cual las herramientas deben ser usadas en conjunto con estndares empresaria les. Estos deben ser implementados a un nivel empresarial para asegurar que todo s los departamentos involucrados en la entrada de datos usen las convenciones co nsistentemente. HERRAMIENTAS DE PRIMERA GENERACIN Las herramientas de primera generacin consisten en procesos batch que analizan lo s datos en busca de defectos y construyen rutinas para reparar los datos al mome nto que son pasados de la fuente al sistema destino. Desafortunadamente estos pr ocesos basados en el paradigma de crear capas de lgica programtica, producen aplic aciones complejas, difciles de manejar. Informe Principal 28

Sistema DW: Carga y Control de Calidad Este tipo de producto de primera generacin que requiere un enorme compromiso de t iempo y recursos es difcil de mantener, mover o reutilizar; tornndose poco til a ni vel empresarial. Adems estas herramientas tienden a ser retrospectivas, detectand o y corrigiendo errores en vez de proactivas, previniendo errores y corrigiendo los datos a traves de procesos en la fuente. Algunas de estas herramientas son [ P2]: N Herramientas para el formateo de correspondencia: identifican direcciones errneas comparndolas con listas de datos vlidos y formatean la informacin de forma que cum plan con normas de distintas organizaciones de servicio postal. Ventajas: requie ren poco esfuerzo en la preparacin de los datos, hacen casi todo el trabajo con p oca interaccin con el usuario. Desventajas: sirven para un nico propsito y realizan una funcin mecnica, y no sacan ningn beneficio de los datos limpios. Herramientas verticales para industrias: soluciones especficas para una industria (bancos, ase guradoras, etc.), que surgen a partir de exigencias regulatorias. Formatean regi stros usando terminologa estndar de la industria y diseo de archivos. Son efectivas identificando relaciones familiares entre los registros. Ventajas: Se ajustan a los requerimientos del negocio del usuario final. Desventajas: Son caras debido a que tienen un mercado limitado; la lgica es en general propietaria y difcil de modificar, y requiere programacin para adaptarla al cliente; frecuentemente requi eren de ayuda de consultores y profesionales expertos en la lgica del negocio par a poder ponerlas en marcha, esto implica que la organizacin debe confiar sus proc esos de negocios a expertos externos que una vez terminado el proyecto se llevan el conocimiento consigo. Herramientas de programacin: consisten en algoritmos pr opietarios que se aplican a casi todas las industrias. Desventajas: son herramie ntas para codificar, no soluciones. Cada problema nuevo requiere generacin de cdig o adicional, lo cual agrega capa sobre capa de complejidad y necesita un gran ma ntenimiento para asegurar el xito. Estas herramientas no tienen inteligencia prop ia, y deben ser continuamente mantenidas. En muchos casos se limitan a bases de datos y plataformas especficas. Los usuarios invierten esfuerzo y tiempo consider able en aprender el lenguaje de programacin de la herramienta y su metodologa, y s u uso efectivo requiere de soporte consultor caro. N N Muchas compaas han encontrado que el uso de herramientas de primera generacin ha ag regado complejidad a sus sistemas. Es comn encontrar en grandes compaas una gran va riedad de soluciones para la limpieza de datos, cada una con sus herramientas y tcnicas, las cuales requieren entrenamiento y soporte. Esto genera problemas de m antenimiento y entrenamiento para mltiples herramientas adems del problema potenci al de resultados diferentes sobre los mismos datos debido a las diferencias en e l software. Informe Principal 29

Sistema DW: Carga y Control de Calidad HERRAMIENTAS DE NUEVA GENERACIN En muchas maneras EDQM es similar a TQM. Esta ltima promueve la importancia en la prevencin de faltas, mientras que EDQM entiende la naturaleza de la inconsistenc ia de los datos y provee de reingeniera en la fuente y dentro de la infraestructu ra organizacional. Ambas apuntan a la empresa en su totalidad y buscan tecnologa que permita la implementacin exitosa de programas. Ha surgido un conjunto de herr amientas de nueva generacin para la reingeniera de datos que soporta el EDQM. Difi eren significativamente de las herramientas de primera generacin en que son [P2]: N Verstiles y poderosas: soluciones ptimas proveen procesamiento sensible al context o para grandes volmenes de datos al momento de la entrada de datos y en modo batc h dentro de los sistemas. Portable e independiente de la plataforma. Basados en estndares: facilitan el mantenimiento y entrenamiento, as como ayudan a codificar y estandarizar toda la compaa alrededor de la calidad de datos. Funcionalidad glob al: como todas las tecnologas, la limpieza de datos y prcticas de reingeniera deben focalizarse en el mercado global. Los requerimientos para procesar clientes int ernacionales presentan grandes desafos, debido a que hay una gran variacin en los estndares de datos de los diferentes pases y en el nivel de completitud de la info rmacin capturada. Extensible y adaptable: son los suficientemente flexibles para adaptarse a los distintos ambientes de tipos de datos, y pueden manejar una gran variedad de conjuntos de reglas. Fciles de usar: enfocan la limpieza de datos en forma intuitiva. Utilizan archivos de texto en vez de generar cdigo. 2 N N N N N Por todo esto las herramientas de segunda generacin son mejores para un enfoque e mpresarial que puede acarrear la implementacin de mltiples data marts, as como ajus tarse a los sistemas OLTP para prevenir problemas de datos en vez de arreglarlos posteriormente. Tambin puede ser reconfigurado ms fcilmente para responder a las c ondiciones cambiantes del negocio. Informe Principal 30

Sistema DW: Carga y Control de Calidad &$/,'$' (1 81 '$7$ :$5(+286( Lo fundamental es tomar un enfoque balanceado que incluya: una buena definicin de los datos, la limpieza de los mismos tanto en su origen como en el data warehou se y la mejora de la calidad de los datos atacando la raz de las causas de los pr oblemas de calidad. Ubicndonos en el marco de referencia de un proyecto de data warehousing y basndono s en la informacin recabada en el transcurso del taller acerca del tema calidad d e datos, presentamos una solucin para construir un data warehouse de calidad. Es una propuesta a nivel general, donde se presentan pautas a seguir para lograr di cho objetivo. El objetivo es lograr construir un data warehouse que refleje una imagen vlida y consistente del negocio para el cual se est implementando. La credi bilidad en los datos reportados es fundamental en el xito del proyecto, ya que en ellos se basar el usuario final para tomar sus decisiones de negocio. Consideram os que para alcanzar dicho objetivo se deben poner en prctica los siguientes proc esos: limpieza de datos y mejoramiento de la calidad de los datos. La limpieza d e datos es el proceso de llevar a un estado de calidad los datos que sern ingresa dos en el warehouse. Este paso es necesario para evitar la entrada al data wareh ouse de datos en mal estado generados durante aos por procesos errneos de los sist emas operacionales. El mejoramiento de la calidad de los datos es un proceso que va mas all de la construccin del data warehouse en s. A diferencia de la limpieza de datos que apunta a corregir errores, el proceso de mejoramiento de la calidad busca prevenirlos atacando los problemas de raz, en la fuente de datos. Para rea lizar la propuesta nos basamos en distintos artculos y white papers que hablan de l tema. Tomamos distintas ideas de cada uno, las cuales adaptamos, ordenamos y a grupamos para asi convertirlas en una solucin general y completa. Dentro de las p ublicaciones ledas no encontramos mucha informacin concreta de cmo construir un dat a warehouse de calidad. Salvo propuestas de algunas herramientas, tanto artculos como libros dan ideas generales de tareas puntuales que se deben realizar. Esta fue nuestra motivacin principal para definir esta propuesta, donde se intenta aba rcar todos los puntos importantes a considerar. Aunque solamente se dan pautas, la propuesta servir como punto de partida para el desarrollo de futuras solucione s ms sofisticadas [A1][A15][P6]. 2 Informe Principal 31

Sistema DW: Carga y Control de Calidad PROCESO DE LIMPIEZA DE DATOS El proceso de limpieza de los datos puede verse como una actividad dentro del pr oceso global de carga de datos al data warehouse. En general, dentro de los proc esos de carga estndar se pueden diferenciar dos etapas: el In-flow y el Up-flow ( figura 5). El In-flow describe el flujo de los datos desde su creacin o captura h asta su ingreso al warehouse. El Up-flow abarca las etapas donde los datos se re sumen a formas relevantes a los usuarios. A travs del uso de proyecciones, funcio nes de agregacin y agrupamientos, los datos son empaquetados dentro de vistas que focalizan asuntos de negocios especficos. Se presenta el proceso, como un conjun to de rutinas distribudas tanto en el in-flow como en el up-flow. Dichas rutinas reportan errores, estandarizan, transforman e integran los datos, resultando en un data warehouse consistente que refleja correctamente el negocio que documenta . 2 Figura 5: Proceso global de carga al data warehouse Las rutinas de limpieza se convierten en otro de los productos a construir dentr o del desarrollo del data warehouse, a menos que se cuente con herramientas que faciliten la tarea. Veremos cules son estas rutinas de limpieza de datos y una me todologa para asegurar la limpieza de datos en el proceso de desarrollo de un dat a warehouse. Informe Principal 32

Sistema DW: Carga y Control de Calidad A. RUTINAS PARA LA LIMPIEZA DE LOS DATOS Presentamos una lista de rutinas que deben ser tenidas en cuenta dentro del proc eso de carga de datos al data warehouse. Si bien, las necesidades especficas de l impieza pueden variar de un proyecto a otro, las rutinas son aplicables a la may ora. 1. Chequeo de versin El chequeo de versin se realiza para detectar cambios en la e specificacin del meta-data. Los cambios en la codificacin de datos fuente, pueden ser capturados comparando la especificacin del metadata. Un caso de utilidad es c uando se tiene un campo booleano codificado con valores 1 o 0 y se modifica la c odificacin a TRUE o FALSE. El chequeo se realiza apenas se extraen los datos de s us fuentes. La deteccin a tiempo de estos casos previene la entrada de datos que pueden ser mal interpretados posteriormente en el data warehouse. 2 2. Chequeo de uniformidad Asegura que los valores de los datos que estan siendo cargados, se encuentren dentro de limites preestablecidos. Las reglas de negocio determinan qu valores son factibles en cada campo de datos, este chequeo verific a que los datos que se ingresen al data warehouse cumplan dichas reglas. El cheq ueo se realiza durante el in-flow e intenta evitar que datos invlidos pasen al da ta warehouse. 3. Transformacin de datos Las rutinas de transformacin de datos, convierten los da tos a una forma adecuada para el data warehouse. Si bien los datos fuente pueden ser correctos para los sistemas operacionales, por su forma, no siempre son de utilidad al data warehouse. Dado que dichos datos contienen la informacin necesar ia, se utilizan rutinas para que los transforme apropiadamente. Podemos distingu ir las transformaciones a dos niveles diferentes: N N Acondicionamiento y estandarizacin de datos se modifican los datos cuando tienen error o no tiene valores (campos vacos). Utilizar reglas de negocio aplicar regla s caractersticas del negocio para transformar los datos adecuadamente. Las transformaciones tambin ocurren durante el in-flow. Informe Principal 33

Sistema DW: Carga y Control de Calidad En general en toda construccin de un data warehouse se necesitan realizar transfo rmaciones de los datos. Los datos operacionales no se adaptan directamente a los requerimientos de un data warehouse, la misma informacin se necesita ver desde o tra ptica. 4. Integracin de datos Las rutinas de integracin de datos tienen como objetivo ide ntificar y consolidar registros. Implica la tarea de identificar entidades de da tos para que no vuelvan a ser cargadas equivocadamente como entidades nuevas al data warehouse, y de resolver conflictos entre datos provenientes de diferentes fuentes. La integracin se debe realizar durante el in-flow. En los proyectos dond e se extraen datos de diferentes fuentes, los conflictos de integracin se dan a m enudo. Incluso pueden ocurrir estos mismos conflictos dentro del mismo sistema, donde la informacin representa una misma entidad pero se encuentra guardada de di stinta manera. Determinar automticamente cuando dos entidades en realidad son la misma no siempre es una tarea simple. 2 5. Supervivencia y formateo de datos Ocurre en la ltima etapa del in-flow, donde se termina de preparar la informacin, para asegurar que los datos mas relevantes sean tenidos en cuenta y se encuentren en la forma adecuada. La rutina se encarg a de varias tareas: N Data filling ingresar valores faltantes en registros remplazndolos con valores de registros relacionados, correspondientes a la misma entidad. Resolucin de confli ctos de datos resolver problemas de registros mltiples que se refieren a la misma entidad con atributos conflictivos. Un ejemplo a este caso son registros de cli entes que coinciden en el nombre y direccin pero tienen diferente nmero de RUC. En riquecimiento de datos suplemental. N N agregar datos de fuentes externas que provean informacin N Supervivencia de datos determinar los datos apropiados a cargar en caso de mltipl es posibilidades. La informacin se puede encontrar en ms de un lugar y debe determ inarse cul seleccionar para el data warehouse. Salida de datos adaptar la salida a los requerimientos tcnicos y de negocio. El data warehouse es consultado utiliz ando distintas herramientas de consulta y anlisis, por lo que sus datos deben pod er ser accesibles a las mismas. N Informe Principal

34

Sistema DW: Carga y Control de Calidad 6. Chequeo de completitud Determina la completitud y correctitud de las agregaci ones de datos. Las agregaciones son tiles pero pueden ocultar datos importantes. Un ejemplo es sacar un promedio de ventas a partir de campos con valores nulos, el promedio puede estar bien calculado pero no refleja la realidad correctamente . Ocurre durante el up-flow cuando se realizan las agregaciones de datos. 7. Chequeo de conformidad Correlaciona los datos con fuentes de datos estndares. Valida si los datos se adecuan a otras fuentes de datos y reportes. Este chequeo permite descubrir casos excepcionales, donde se debe investigar si la causa de los mismos proviene de datos errneos o que los resultados reflejan un cambio en l a realidad. Por ejemplo, si el promedio de ventas en un departamento del pais se mantiene constante durante todos los meses del ao y en determinado mes aumenta a l doble, los resultados pueden deberse a datos ingresados en forma errnea por los operadores de los sistemas operacionales o que las ventas en realidad subieron en dicho mes. Ocurre en el up-flow cuando los datos se encuentran en la forma ad ecuada para el data warehouse. 2 8. Genealogico Provee un auditoria completa de la fuente de datos. Ocurre durant e el reporte de datos cuando el consumidor de la informacin cuestiona la validez de los datos. Con las herramientas OLAP, el chequeo genealgico se refiere a reali zar un drill-down sobre una agregacin y llegando a un nivel de granularidad mas f ino en los datos. B. METODOLOGA PARA ASEGURAR LA LIMPIEZA DE DATOS Se plantea una metodologa de trabajo para construir un sistema de DW de buena cal idad, donde el proceso de carga se encarge de ejecutar las rutinas vistas en el punto anterior. Se define un conjunto de tareas que deben ser realizadas durante las distintas etapas de desarrollo del data warehouse. La metodologa aplica un e nfoque bottom-up, comenzando al nivel de los valores de los datos. Mediante la i nvestigacin de cada valor en los campos, descubriendo informacin dentro de campos sin formato, resolviendo problemas de estandarizacin y reconociendo informacin per dida, se puede alcanzar el conocimiento necesario acerca del nivel de calidad en que se encuentran los datos fuente. Dado el nivel de calidad de las fuentes pod emos determinar entonces si los datos son lo suficientemente confiables para imp lementar un data warehouse en base a los mismos. Ubicado el conjunto de problema s en los datos fuente, Informe Principal 35

Sistema DW: Carga y Control de Calidad podemos definir las rutinas de limpieza necesarias para transformar dichos datos en informacin correcta, completa y consistente para el data warehouse. La metodo loga se aplica al proceso de construccin de un data warehouse, pero ms precisamente , al proceso de desarrollo de la carga y construccin del data warehouse relaciona l, que compone el proceso global. Pensamos que la metodologa es til para proyectos de tamaos chicos y medianos y se ajusta a las necesidades actuales de nuestro me dio. En la figura de abajo podemos observar como participa la metodologa en el pr oceso de desarrollo de un data warehouse. Las llamadas contienen en su interior el nombre de las tareas que deben realizarse durante las etapas de anlisis, diseo e implementacin. 2 Figura 6: Metodologa de aseguramiento de la limpieza en los datos Veamos en detalle que implica cada tarea. 1. Investigacin de datos La investigacin de los datos brinda una visin sobre la con dicin real de los mismos, ayudando a conocer y comprender mejor la informacin que se encuentra en las fuentes de datos y su nivel de calidad. La documentacin de lo s sistemas operacionales puede establecer qu informacin manejan dichos sistemas, p ero esto no nos asegura que lo documentado es realmente lo almacendo. El sistema fuente puede estar diseado para trabajar con cierta informacin pero por muchos Informe Principal 36

Sistema DW: Carga y Control de Calidad motivos ( ingreso de informacin errnea, procesos con bugs, manejo inadecuado del s istema, etc.) la informacin que realmente se encuentre almacenada puede ser muy d istinta o contener muchos errores. La investigacin detallada de los datos se conv ierte en la base de conocimiento ms importante sobre los datos fuente, sobre la c ual se determina si el estado de calidad de la fuente es adecuado para poblar el data warehouse. El proceso de investigacin se realiza en la etapa de anlisis del proceso de desarrollo del data warehouse. El anlisis de los datos, en conjunto co n la documentacin del sistema fuente y el conocimiento de las reglas de negocio, permiten determinar los datos vlidos para el data warehouse, datos que se necesit en transformar o limpiar, datos ocultos de utilidad y datos que se tienen que de scartar, tanto porque no tienen informacin necesaria o porque la cantidad de erro res en los mismos es irremediable. Se realiza un anlisis detallado de los datos f uente que se compone de las siguientes actividades principales: N 2 Data typing Asignarle un significado relativo al negocio, a cada valor encontrad o en los campos de datos. Se estudia que el mismo tenga sentido dentro del negoc io. Metadata mining Descubrir metadata oculta y prcticas de negocio no documentad as. Parsing de datos y extraccion de entidades y atributos Extraer datos especif icos que se encuentren mezclados en campos de diferente dominio. N N En el mercado han surgido algunas herramientas que facilitan este tipo de invest igacin de los datos. En particular INTEGRITY de Vality Technology define y utiliz a en su metodologa las tres actividades mencionadas, lo hace en forma automtica ap licando anlisis lexicogrfico, procesamiento de formatos (pattern processing) y mat cheo estadstico. Tambin otra herramienta, WizRule utiliza algoritmos matemticos par a revelar las reglas que gobiernan los datos. La caracterstica ms sobresaliente en estas herramientas es su elevado precio, que obligan en muchos casos a descarta r su uso. Sin embargo an es posible realizar la investigacin de los datos. Si esta mos analizando una fuente con poca cantidad de datos, la labor puede realizarse usando herramientas ad-hoc para ejecutar consultas significativas. En caso de te ner que analizarse una fuente de gran cantidad de datos, esta tarea puede llevar mucho tiempo por lo que sera conveniente desarrollar aplicaciones propias que ap liquen algoritmos, al estilo de las herramientas mensionadas, para revelar la in formacin que ocultan las bases fuentes de datos. 2. Diseo de soluciones. Dentro del proceso de desarrollo del data warehouse, desp us de finalizada la etapa de anlisis, se est en condiciones de definir las rutinas de limpieza que se necesitan incluir en la carga. Se conoce el conjunto de datos fuente seleccionados para cargar, se conoce el nivel de calidad en que se encue ntran los datos y est ya analizado todo lo requerido por el data warehouse. Infor me Principal 37

Sistema DW: Carga y Control de Calidad En la etapa de diseo entonces, se define el conjunto de rutinas de limpieza que s e incluirn para solucionar los problemas de calidad encontrados durante el anlisis . Se pueden encontrar herramientas que realicen las rutinas, herramientas que en general que se encargan de realizar todo el proceso de carga. Pero tambin las ru tinas pueden generarse dentro del proceso de desarrollo del data warehouse, en c uyo caso en esta etapa se realizara el diseo de las mismas. Las rutinas pueden ser diseadas como soluciones automticas, semi-automticas o directamente manuales, dond e debe participar el usuario encargado de la carga. El diseo adems de influir en e l proceso de carga, tambin puede influir en el diseo de las estructuras de almacen amiento del data warehouse. Por lo que el diseo de estas soluciones debe realizar se en conjunto con el diseo de las estructuras de almacenamiento y del proceso de carga. Por otro lado, si bien las rutinas pueden disearse como soluciones a prob lemas particulares a un sistema, sera interesante que se disearan en forma que se adapten a distintos casos. De esta manera en cada proyecto solamente se tendran q ue customizar las rutinas de limpieza. Por ejemplo, definir la rutina de chequeo d e versin en forma genrica, que acceda a la especificacin del metadada y verifique s i los datos fuente cumplen con la especificacin. Podra tambin definirse los distint os chequeos para que permitan customizar las reglas que deben cumplirse en cada oc asin y entonces los chequeos utlizaran estas reglas para validar los datos. 2 3. Implementacin de algoritmos. En caso de realizar las propias rutinas de limpie za de datos, en la etapa de implementacin del data warehouse, se desarrollaran las mismas. Si utilizamos soluciones externas debemos incluirlas al proceso de carg a a menos que el mismo ya las contenga. Estas tres etapas constituiran la metodol oga de aseguramiento de limpieza de datos. Metodologa que debiera aplicarse al des arrollo de cada data warehouse o data mart que implementemos. Informe Principal 38

Sistema DW: Carga y Control de Calidad CALIDAD EN LOS DATOS Sin duda alguna, para asegurar la calidad en los datos del data warehouse se deb en mejorar los procesos de negocio que producen los datos y concientizar la orga nizacin de la importancia que tiene la calidad de los datos para lograr beneficio s en el negocio. Alcanzar la calidad significa colmar las expectativas del cliente y en un data w arehouse el cliente es el trabajador experto, el usuario que se basa en los dato s para tomar las decisiones en su negocio. Quin provee los datos al data warehous e ? Los sistemas de informacin ? No !. Los proveedores son los productores de dat os que crean y actualizan los datos en la medida que hacen su trabajo. Los produ ctores de datos deben ingresar los datos de una manera que satisfaga no slo los r equerimientos de calidad de su departamento sino que tambin satisfaga a todos los usuarios del data warehouse, quienes no estn relacionados directamente con ellos . Hacer entender esto a los usuarios de los sistemas operacionales no siempre es una tarea fcil. Tampoco lo es, plantearle a la gerencia, que los sistemas operac ionales no tienen la calidad suficiente para utilizar sus datos en el data wareh ouse, siendo nosotros mismos quienes desarrollamos esos sistemas. 2 Figura 7: Influencia de usuarios Sist. Operac. sobre los usuarios del data wareh ouse Informe Principal 39

Sistema DW: Carga y Control de Calidad A. GUA PARA ASEGURAR LA CALIDAD DE DATOS La gua que presentamos resume los puntos ms importantes a considerar dentro de una organizacin para asegurar la calidad de datos. N Desarrollar una filosofa de calidad en la produccin de los datos. Ingeniar los pro cesos de negocio y aplicaciones tales que los datos creados colmen las expectati vas de los usuarios del data warehouse. Definir los datos consistentemente entre todos los futuros usuarios del data warehouse. Reestructurar los procesos de ne gocio antes de automatizarlos para eliminar pasos intermedios que pueden agregar costos e introducir errores sin agregar valor. Ubicar los programas de captura de datos lo ms cerca posible del evento de negocio que origina esos datos. Ingres ar reglas de validacin automtica que se disparen al momento que se ingresan los da tos y validen si los mismos son correctos. Capturar todos los datos del negocio, requeridos por usuarios del data warehouse o procesos subsiguientes. Permitir a ctualizar los datos siempre. Automatizar captura de datos para evitar errores in termedios. Permitir cargar el valor "desconocido" en cada uno de los campos para cuando el productor de los datos no conoce el valor real. Mantener comunicacin f recuente y feedback entre usuarios del data warehouse y productores de datos par a asegurar la vigencia de los datos voltiles. Estimular a la gente de negocios a tener los datos lo ms actualizados posible. Identificar y designar registro orige n, registro de referencia y base de datos replicadas. Distribuir los datos media nte transformacin de los mismos. replicacin y controlar fuertemente cualquier N N 2 N N N N N N N N N N N N Entrenar a los productores de datos y proveerles acceso a la definicin de los dat os. Hacer que tanto los encargados de ingresar los datos como los encargados de los procesos de negocios se sientan responsables de la calidad de los datos. Informe Principal 40

Sistema DW: Carga y Control de Calidad 548,7(&785$ '(/ '$7$ :$5(+286( El xito de la tecnologa de DW ha sido muy grande en los ltimos aos y ha permitido ev olucionar mucho la materia. Las distintas experiencias demostraron, ideas que en un principio parecan correctas, no lo eran tanto. En este captulo nos centraremos en los cambios que ha sufrido el DW con respecto a la arquitectura del sistema. '$7$ :$5(+286( &(175$/ 2 El concepto inicial detrs del DW era el de crear un repositorio de alcance empres arial que homogeneizara y uniera todos los datos de la organizacin en una nica est ructura, desde donde todos los departamentos pudieran obtener una visin coherente de la organizacin. Este concepto implicaba que todos los sistemas de produccin pr ovieran de informacin al warehouse y que todas las extracciones y transformacines dentro de toda la organizacin estuvieran bajo el control de un nico proceso. Figura 8: Arquitecutra data warehouse global centralizado Los problemas en proyectos que aplicaron este concepto estilo big bang fueron apar eciendo. Construir un data warehouse global centralizado es complicado por varia s razones que incluyen temas polticos empresariales, temas financieros, temas de performance y temas de estrategia. Los temas polticos principalmente se relaciona n con pertenencia de datos y provincialismo, algunos departamentos no estn de acu erdo con compartir sus datos. Financiar estos proyectos implica invertir mucho d inero y esperar varios meses para obtener algo de utilidad. Surgen problemas tam bin de performance al momento que usuarios de distintos departamentos quieren con sultar su informacin al mismo tiempo dentro del warhouse. Por ltimo, dado el tiemp o que se necesita para desarrollar un sistema de este tamao desalienta a los usua rios dado que al momento que se complete los requerimientos ya habrn cambiado. Informe Principal 41

Sistema DW: Carga y Control de Calidad (675$7(*,$6 '$7$ 0$576 En contrapartida a la estrategia anterior los Data Mart se basan en la teora Divid e and Conquer, donde se construyen almacenes de informacin especifica que apuntan a una rea del negocio en particular. El concepto en este caso deriva de la certez a que cualquier usuario tiene necesidades de informacin limitada, y aunque tipica mente existen requerimientos para analisis funcionales cruzados, el tamao de los requerimientos es reducido materialmente si limitamos el tamao del warehouse en s mismo. Dos estrategias distintas se desarrollan a partir del concepto de data ma rts, la de data marts dependientientes y la de data marts independientes. 2 DATAMART DEPENDIENTES En esta arquitectura los datos son cargados desde los sistemas de produccin hacia el data warehouse empresarial y entonces subdivididos en data marts. Se llaman data marts dependientes porque utilizan los datos y metadatos del data warehouse en lugar de obtenerlos de los sistemas de produccin. Esta solucin resuelve los pr oblemas de performance, estrategia, finanzas e incluso algunos de los problemas polticos. Aunque tiene esos puntos a favor, sigue teniendose que construir el dat a warehouse global antes que los data marts sean implementados. Figura 9: Arquitectura de Datamart dependientes Informe Principal 42

Sistema DW: Carga y Control de Calidad DATA MART INDEPENDIENTES Esta ptica es considerada por muchos como una alternativa del data warehouse cent ral. Con ella es posible comenzar con un sistema pequeo, invirtiendo menos dinero y obteniendo resultados limitados entre tres a seis meses. Los que proponen est a arquitectura, argumentan que luego de comenzar con un data mart pequeo, otros m arts pueden proliferar en otras lineas de negocio o departamentos que tengan nec esidades, y que satisfaciendo las distintas necesidades divisionales, una organi zacin puede construir su camino para el data warehouse completo, de una manera bo ttom up. En este caso de data marts mltiples tambin se tienen procesos de carga mlt iples donde los datos son extraidos desde sistemas de produccin quizs en forma red undante. 2 Figura 10: Arquitectura de Datamarts independientes Informe Principal 43

Sistema DW: Carga y Control de Calidad ',6(f2 '( 81 '$7$ :$5(+286( ,1752'8&&,1 El estudio realizado sobre el tema diseo de un data warehouse, se centra en el tr abajo 'A transformations based approach for designing the Data Warehouse' de la Ing. Adriana Marotta, presentado como tesis de su maestra al departamento de Comp utacin de la Facultad de Ingeniera de la Universidad de la Repblica del Uruguay. Pr esentamos aqu una breve descripcin del trabajo. 2 $ 75$16)250$7,216 %$6(' $3352$&+ )25 '(6,*1,1* 7+( '$7$ :$5(+286( Las caractersticas particulares de un data warehouse hacen que el proceso de diseo sea diferente del diseo tradicionalmente utilizado para bases de datos relaciona les. Se debe tener en cuenta por ejemplo, que la existencia de redundancia es ne cesaria a la hora de disear un data warehouse ya que mejora la performance de las consultas. Adems, la redundancia no implica anomalas al actualizar los datos ya q ue por lo general la actualizacin de un data warehouse se realiza mediante proces os de carga batch. El trabajo 'A transformations based approach for designing th e Data Warehouse', propone un conjunto de primitivas para apoyar el diseo de un d ata warehouse por considerar que 1) las primitivas materializan el conocimiento existente sobre diseo de data warehouses, 2) permiten el seguimiento del diseo una vez realizado. Adems, aumentan la productividad del diseador, ya que el mismo dis pone de piezas de diseo predefinidas, solo le resta seleccionar aquellas que cons idere de su utilidad para el caso que enfrente y combinarlas de forma de obtener el diseo final del data warehouse. La mayor contribucin de ste trabajo es la propu esta de un conjunto de primitivas para el diseo de un data warehouse. Estas primi tivas deben ser aplicadas a la integracin de los sistemas fuente para luego obten er el data warehouse final. Junto con cada primitiva, se provee la especificacin de las transformaciones que deben aplicarse, a instancias del esquema fuente, pa ra realizar la carga al data warehouse. Informe Principal 44

Sistema DW: Carga y Control de Calidad PRIMITIVAS PARA EL DISEO DE UN DATA WAREHOUSE El siguiente es un resumen de las primitivas definidas, donde se presenta la des cripcin de cada una de ellas. 1 2 3 3.1 3.1 4 4.1 Data Filter Temporalization Key Generalization Version digitis Key Extension DDAdding DD-Adding 1-1 4.2 DD-Adding N-1 4.3 DD-Adding N-N 5 6 Attribute Adding N:1 Dim Relationships 6.1 N:1 Dim Relationships 6.2 N:1 Dim Relationships Dada una tabla de medidas, filtrar los atributos que son de inters. Utilidad: Eli minar los datos puramente operacionales. Dada una tabla de medidas o de dimensin, agregar un elemento de tiempo al conjunto de atributos de la tabla. Dada una re lacin de dimensin, se generaliza la clave, agregando 2 dgitos de versin a cada valor de este atributo. Dada una relacin de dimensin, se generaliza la clave agregando dos dgitos de versin a cada valor de este atributo. Dada una relacin de dimensin, se extiende la clave, haciendo que este compuesta por ms atributos. Estas primitiva s tienen como objetivo general agregar a una relacin un atributo que es derivado a partir de otros. Dada una relacin, agregar un atributo que es derivado (calcula do) a partir de otros de la misma. Este atributo no debe cambiar la granularidad de la tabla. Dadas dos relaciones, agregar en una de ellas un atributo que se d eriva de la otra. En este caso la funcin de clculo trabaja sobre solo una tupla de la otra relacin. Esta tupla debe poderse obtener en forma nica mediante un join. El atributo derivado puede definirse como clave externa con respecto a otra rela cin. Dadas dos relaciones, agregar en una de ellas un atributo que se deriva de l a otra. En este caso la funcin de clculo trabaja sobre un conjunto de tuplas de la otra relacin. Este se obtiene mediante un join de las dos relaciones. Dada una r elacin de dimensin, agrega uno o ms atributos a sta. Utilidad: Mantener en una misma tupla ms de una versin de un mismo atributo. Primitivas para transformar un esque ma compuesto por: una tabla de movimientos R1 y dos tablas de dimensiones R2 y R 3, en donde existe una relacion N:1 entre R2 y R3, la cual cambia lentamente. Da do un esquema compuesto por: una tabla de movimientos R1 y dos tablas de dimensi ones R2 y R3, en donde existe una relacion N:1 entre R1 y R2 y una relacin N:1 en tre R2 y R3, generaliza la clave de la tabla R2, y hace que la tabla de movimien tos la referencie. Dado un esquema compuesto por: una tabla de movimientos R1 y dos tablas de dimensiones R2 y R3, en donde existe una relacion N:1 entre R1 y R

2 y una relacin N:1 entre R2 y R3, hace que la tabla de movimientos, adems de refe renciar a la tabla de dimensin R2 tambin referencia a R3. 2 Informe Principal 45

Sistema DW: Carga y Control de Calidad 6.3 N:1 Dim Relationships 6.4 N:1Dim Relationships 7 Hierarchy Roll Up 8 Aggregate Generation Table Merge 9 10 Data Array Creation 11 Partition by Stability 11.1 Vertical Partition 11.2 Horizontal Partition 12 Hierarchy Generation 12.1 De-Normalized Dado un esquema compuesto por: una tabla de movimientos R1 y dos tablas de dimen siones R2 y R3, en donde existe una relacion N:1 entre R1 y R2 y una relacin N:1 entre R2 y R3, generaliza la clave de la tabla R2, y hace que la tabla de movimi entos la referencie. Incluye los datos de la tabla R3 en R2 (desnormaliza). Dado un esquema compuesto por: una tabla de movimientos R1 y dos tablas de dimension es R2 y R3, en donde existe una relacion N:1 entre R1 y R2 y una relacin N:1 entr e R2 y R3, incluye los datos de la tabla R3 en la tabla de movimientos R1 y en l a tabla R2 (desnormaliza). Dada una tabla de medidas R1 y una tabla de dimensin R 2 que contiene una jerarqua, obtiene una tabla de medidas R'1 en donde se aument e l nivel en la jerarqua (se disminuy la granularidad) del atributo correspondiente (que es clave externa) a la dimensin R2. Adems puede generar una tabla R'2 derivad a de R2, con la granularidad tomada anteriormente. Dada una tabla de medidas R, obtiene una tabla de medidas R'1 en donde los datos estn resumidos (o agrupados) segn un conjunto de atributos dado. Dadas dos relaciones R1 y R2, que representan informacin de tipo cabezal-renglones, genera una nica relacin R' cuyos atributos s on la unin de los de R1 y R2. Dada una relacin de medidas, con un atributo de medi da A, un atributo B que representa un conjunto de valores predeterminados (por e j., mes), y un atributo de tiempo C, genera una relacin en donde en vez de los at ributos B y A, aparece un conjunto de atributos que representan las medidas corr espondientes a cada valor posible del atributo B. Estas primitivas particionan u na relacin, de forma de facilitar el almacenamiento de la historia de los datos d e sta. Segn el criterio que se desee aplicar, se podrutilizar la primera (Vertical

Partition) o la segunda primitiva (Horizontal Partition) del grupo. Dada una rel acin de dimensin, sta se particiona en varias relaciones distrubuyendo sus atributo s de forma que queden agrupados segn su propensin a los cambios. A partir de una r elacin R se generan dos relaciones Ract y Rhist, que contienen los mismos atribut os que R, y una restriccin de integridad para cada uno que especifica que los dat os deben ser actuales o histricos, segn el caso. Estas primitivas generan relacion es de dimensin correspondientes a una jerarqua, a partir de relaciones que incluye n a la jerarqua o a parte de sta. Adems, hace que estas relaciones referncien a la jerarqua con una clave externa. Esta primitiva genera una relacin de dimensin que e s una jerarqua, a partir de relaciones que incluyen a la jerarqua o a parte de est a. Adems, hace que las relaciones referencien a la jerarqua con una clave externa. Informe Principal 46

Sistema DW: Carga y Control de Calidad Esta primitiva genera varias relaciones de dimensin que corresponden a una jerarq ua, representada en forma normalizada, a partir de relaciones que incluyen a la 1 2.2 Snowflake jerarqua o a parte de sta. Adems, hace que estas relaciones referenci en a la relacin correspondiente al nivel ms bajo de la jerarqua con una clave exter na. Esta primitiva genera varias relaciones de dimensin que corresponden a una je rarqua, a partir de relaciones que incluyen a la jerarqua o a parte de esta. Adems, hace que estas relaciones referencien a la relacin 12.3 Free Decomposition corre spondiente al nivel ms bajo de la jerarqua, con una clave externa. Las relaciones generadas para la jerarqua tendrn la forma (distribucin de atributos) que el diseado r decida. Dada una relacin de dimensin, se separa de sta un 13 Minidimension Break off conjunto de atributos, formando con ellos una nueva dimensin. Dadas varias re laciones de dimensin o de cruzamiento, donde cada una tiene un atributo en comn co n alguna de loas otras, genera una nica relacin de cruzamiento 14 New Dimension Cr ossing cuyos atributos son la unin de algunos atributos de las anteriores. Informe Principal 47

Sistema DW: Carga y Control de Calidad #()(5(1&,$6 Introduccin al Datawarehousing. [L1],[L2],[L3],[L7] Calidad de Datos. [A1],[A4],[A6],[A15] [P1],[P2],[P6],[P7],[P10],[P11],[P14],[P15],[P17],[P18],[P1 9] Arquitectura de DW. [P1] Diseo de DW. [P22] 2 Informe Principal 48

Sistema DW: Carga y Control de Calidad SISTEMA DESARROLLADO 3 3 Informe Principal DESARROLLADO ISTEMA 49

Sistema DW: Carga y Control de Calidad 3/$17(2 '(/ 6,67(0$ Se plantea construr un sistema DW que incluya tres data marts: N N N Presupuesto, debe contener informacin de utilidad para la comisin encargada de adm inistrar el Presupuesto de la F.I. Bedela, debe contener informacin de utilidad pa ra la comisin del I.N.CO. encargada del seguimiento de los estudiantes Asignacion es, debe contener informacin acerca de los docentes del I.N.CO y sus asignaciones a cargos en dicho instituto. El sistema de DW debe construrse aplicando una estrategia Bottom Up, construyendo los distintos data mart que lo componen. Cada data mart debe ser desarrollado a plicando una estrategia Top Down, comenzando con el relevamiento de los requerim ientos de usuario, para luego realizar las etapas de anlisis, diseo e implementacin . Los data mart de Presupuesto y Bedela deben comenzar su desarrollo en paralelo, hasta llegar al diseo, en ese momento comienza el desarrollo del data mart de As ignaciones, cuyo diseo debe integrarse al de los data marts anteriores. Luego de finalizados los diseos se realizan las implementaciones paralelamente (*). Los da ta marts deben construrse dividiendo el desarrollo horizontalmente entre dos grup os de desarrollo. Un grupo es el encargado de relevar los requerimientos de usua rio, definir el modelo multidimensional, y generar las aplicaciones de usuario f inal. El otro grupo, en particular nuestro grupo, es el encargado de construir e l data mart relacional y su carga. Se sabe que ambos equipos deben interactuar d urante el desarrollo, no estn completamente definidas estas interacciones. En un principio este equipo de desarrollo recibe del otro equipo el modelo mutlidimens ional de los datamarts, construye cada data mart relacional y su carga, el otro equipo extrae entonces los datos almacenados para cargar los cubos. La tarea del primer grupo forma parte del proyecto: Sistema de data warehousing: OLAP. La tare a del segundo grupo, forma parte del proyecto que estamos documentando en este i nforme. 3 (*) La idea planteada incialmente de desarrollar en paralelo los data marts de P resupuesto y Bedela no pudo llevarse a cabo. Como no se contaba con informacin del sistema operacional de Bedela, y la informacin recaudada por el taller anterior n o contemplaba las modificaciones a causa del cambio de plan, se comenz unicamente con el data mart de Presupuesto, defasndose asi los desarrollos de ambos data ma rts. El data mart de Asignaciones no fue construdo debido a que se pensaban extra er los datos de un sistema que finalmente no se realiz. Informe Principal 50

Sistema DW: Carga y Control de Calidad (675$7(*,$ '( '(6$552//2 El sistema data warehousing que debe construrse es planteado bajo ciertas condici ones, especificadas en la seccin anterior, donde se indican algunas caractersticas del sistema y puntualizaciones de cmo organizar el trabajo. Se define entonces u na estrategia para desarrollar un sistema data warehousing, de modo que tanto el sistema como el desarrollo cumplan las condiciones planteadas. La estrategia se centra en el desarrollo del data mart relacional y su carga (Figura 11) y tiene como objetivo final la construccin del data warehouse. Se consideran principalme nte los siguientes puntos para la construccin de la estrategia: A. Cmo desarrollar el data warehouse dada la estrategia Bottom Up ? B. Cmo asegurar la limpieza de los datos del data warehouse ? C. Cmo interactuar con el desarrollo OLAP ? En res puesta al punto A) se decide focalizar la estrategia al desarrollo de un data ma rt. De esta manera el desarrollo de un sistema DW, se define como varios desarro llos ms pequeos, uno por cada data mart, los cuales son construdos aplicando la est rategia. La respuesta al punto B) integra la Metodologa para asegurar la limpieza de un data warehouse a la estrategia de desarrollo de cada data mart. Dicha metod ologa se especifica en detalle en la seccin Calidad de un data warehouse del captulo anterior. Finalmente se estudia cmo coordinar este trabajo, la construccin del dat a warehouse relacional y su carga, con el desarrollo de la parte OLAP del sistem a, resolviendo de sta forma el punto C). Dado que la estrategia se centra en el d esarrollo de un data mart, se define la interaccin durante el desarrollo del mism o. 3 Figura 11: Alcance de la estrategia Informe Principal 51

Sistema DW: Carga y Control de Calidad A. DESARROLLO DEL SISTEMA DW Se divide el desarrollo del Sistema DW en pequeos desarrollos, uno por cada data mart que lo componga. Figura 12: Divisin del desarrollo en data marts El sistema DW se va constituyendo mediante la construccin de nuevos data marts. Los data marts se crean a medida q ue surjan requerimientos especficos a un rea del negocio. Por lo que pueden darse, tanto situaciones en que se construyan data marts secuencialmente, como situaci ones en que surjan data marts en forma conjunta. La estrategia se adapta a ambas situaciones. En particular, en el segundo caso puede aplicarse en forma paralel a, resaltndose la importancia de la comunicacin que debe existir entre los desarro llos de cada data mart a modo de evitar conflictos de diseo y trabajo duplicado ( Figura 12). En este tipo de estrategia Bottom Up, hay dos puntos importantes a c onsiderar, la integracin con otros data marts y la reutilizacin de componentes. Al desarrollar data marts en forma independiente, quizs alejados en el tiempo, esto s temas pueden llegar a ser olvidados y por consiguiente aumentar inecesariament e la complejidad del desarrollo. En cuanto a integracin con otros data marts, nos referimos a que tanto los ya construdos como otros en vas de construccin, pueden m anejar la misma informacin. Debe analizarse si la informacin cumple con los requer imientos actuales, si es conveniente realizar una integracin o no, etc. La estrat egia presentada tiene en cuenta este punto en la etapa de anlisis. La reutilizacin de componentes es tambin interesante, evita realizar trabajos en forma duplicada . Puede ser de mucha utilidad principalmente en el rea de procesos de carga. Se d estaca la importancia de la metadata del sistema. Toda documentacin sobre sistema s operacionales, datos fuente, modelos lgicos, modelos multidimensionales, datos del data mart, procesos de carga, configuracin de herramientas, etc. sirve y faci lita la resolucin de los puntos antes discutidos. La estrategia define en cada et apa la documentacin que debe generarse. 3 Informe Principal 52

Sistema DW: Carga y Control de Calidad B. ASEGURAMIENTO DE CALIDAD DE DATOS Se enriquece el desarrollo de cada data mart con la Metodologa para asegurar la li mpieza de datos. 3 Figura 13: Desarrollo teniendo en cuenta Metodologia para asegurar la limpieza d e datos La importancia que tiene el tema calidad en un sistema DW no es discutible, sin embargo, la forma de considerarlo s lo es. En este caso se opt por adaptar la estr ategia de desarrollo de cada data mart, para que incluyera la Metodologa para aseg urar la limpieza de datos (Figura 13). Es una solucin que permite construir data m arts confiables. En la seccin Calidad de un data warehouse del captulo anterior, s e habla de la necesidad de realizar dos procesos en paralelo, limpieza y mejoram iento de la calidad de los datos. Esta estrategia considera principalmente la li mpieza pero no deja de lado lo segundo ya que la gua de calidad presentada puede aplicarse en las distintas etapas de desarrollo. Si a nivel de la organizacin emp resarial se define un plan de mejoramiento de calidad, la estrategia puede adapt arse a dicho plan. Informe Principal 53

Sistema DW: Carga y Control de Calidad C. INTERACCIN CON DESARROLLO OLAP Dado que la estrategia se centra en el desarrollo de cada data mart, la interfas e con el desarrollo OLAP se define dentro de la construccin de cada data mart. 3 Fig 14: Interaccin del desarrollo Carga y Control de calidad con el desarrollo OL AP En el diagrama (figura 14) pueden observarse tres puntos de interaccin, los cuale s especificamos a continuacin. La interaccin A, es una entrada de informacin para e l desarrollo del data mart relacional y su carga, en donde se recibe el modelo m ultidimensional del data mart. El mismo es construdo en el desarrollo OLAP, luego de haber relevado los requerimientos de usuarios finales del sistema y de haber modelado el negocio. No especificamos las tareas que componen las etapas de req uerimientos y anlisis del desarrollo OLAP pero s, lo que se considera importante r ecibir como entrada en esta etapa. El modelo multidimensional debe representar t oda la informacin que el data mart necesite manejar. Documentar el significado de todo lo requerido, especificar las dimensiones, los cruzamientos de interes, la s medidas y el nivel de granularidad en los datos. Debe especificar la evolucin e n el tiempo de cada medida, si es diaria, mensual, semestral, anual, etc. Informe Principal 54

Sistema DW: Carga y Control de Calidad La interaccin B tiene la particularidad de ser de entrada y de salida. El grupo r esponsable de construir el data mart relacional y su carga informa al grupo OLAP , los datos con los que se cuenta para poblar el data mart. Lo que puede llevar a que el grupo OLAP realice modificaciones al modelo multidimensional para que st e se adapte a la realidad y/o que el grupo de diseo busque la forma de obtener la informacin faltante. En la interaccin deben aclararse inquietudes, como por ejemp lo: qu formatos especiales que deben tener los datos almacenados?, quin se encarga d e calcular ciertos datos, la herramienta de usuario final o se guardan calculado s?, cmo se cargarn los cubos, en forma incremental o total? ( no todas las herramie ntas soportan carga incremental), etc. Las respuestas a las anteriores inquietud es influyen sistemticamente en el diseo de las tablas del datamart y sus procesos de carga. Por ltimo, en la interaccin C, creadas las tablas del data mart se infor ma de su estructura y contenido al grupo OLAP para que ste cree el diccionario de datos. '(6$552//2 '( 81 '$7$ 0$57 Se detallan los pasos que componen el desarrollo de un data mart, aplicando la m etodologa para asegurar la limpieza en los datos e interactuando con el desarroll o OLAP. Se especifican las distintas etapas dentro del desarrollo encargado de c onstruir el data mart relacional y su carga. 3 Figura 15: Etapas desarrollo de un data mart Las etapas en el desarrollo de cada data mart son: requerimientos, anlisis, diseo e implementacin. En ese orden, a continuacin se explican las mismas. Se define el objetivo de cada etapa, las fases que las componen, las tareas a realizar en ell as y la metadata que se debe generar. Informe Principal 55

Sistema DW: Carga y Control de Calidad Requerimientos La etapa de requerimientos tiene como objetivos, especificar las caractersticas y funcionalidades del data mart y describir el ambiente operativo en que se entre gar el mismo. La lista de requerimientos es grande, pero se resumen en tres punto s fundamentales para construir el data mart realcional y su carga: Requerimiento s tecnolgicos, Modelo Multidimensional y Relevamiento de Fuentes. La recopilacin d e los requerimientos de usuario es realizada por el equipo de desarrollo OLAP y es una de las tareas ms importantes en la construccin de un data mart. Dicho equip o a partir de esos requerimientos elabora en la etapa de anlisis, un modelo multi dimensional que es recibido como un requerimiento ms por el equipo de desarrollo encargado del diseo relacional y la carga del data mart. En el diagrama Interaccin con desarrollo OLAP (figura 14) se aprecia esta interaccin. 3 1. Requerimientos tecnolgicos Especifican el ambiente de produccin del data mart: procesadores, ambiente operativo, almacenamiento de datos, metadatos, redes, com unicaciones, herramientas disponibles para la extraccin, transformacin y limpieza de datos, etc. Metadata a generar: Documentacin de requerimientos. 2. Modelo mult idimensional Es construdo por el equipo de desarrollo OLAP como resultado de su e tapa de anlisis y es el pilar del desarrollo del data mart. Del anlisis del modelo surje la informacin que se necesita almacenar en el data mart. Es utilizado para disear el data mart relacional y los procesos de carga. El modelo define las reas temas de inters, la granularidad de los datos (nivel de detalle de los mismos), las dimensiones (constitudas por los conjuntos de elementos existentes en la real idad) y las mediciones que se quieren realizar sobre los movimientos que sufren las relaciones entre las dimensiones en el tiempo. Para mas informacin sobre las caractersticas del modelo ver el informe correspondiente a la tesis: Sistema DW: O LAP. Metadata a generar: Documentacin del modelo multidimensional recibido. Informe Principal 56

Sistema DW: Carga y Control de Calidad 3. Relevamiento de fuentes Especifica los sistemas operacionales disponibles par a ser fuente de datos al data mart. Determina la funcionalidad de los sistemas, las caractersticas tecnolgicas, la informacin que manejan , su volatilidad y el uso que se les da a los mismos. La informacin se releva mediante el estudio de la do cumentacin de los sistemas operacionales y entrevistas a personas conocedoras de los mismos (administradores, desarrolladores, usuarios). Metadata a generar: Doc umentacin de sistemas operacionales. Documentacin de informacin recabada. Anlisis 3 El objetivo de la etapa de anlisis es identificar los datos que se necesitan alma cenar en el data mart, investigar con qu datos se dispone y en qu estado de calida d se encuentran, para luego definir qu datos se van a extraer de los sistemas ope racionales. En caso de no disponer de todos los datos requeridos, se define qu ha cer al respecto. Tambin se analizan todos los problemas a enfrentar en el proceso de carga del data mart. 1. Anlisis General Se estudia la informacin que manejan los sistemas operacionales osea, lo almacenado en sus bases de datos. Se estudian las estructuras fsicas de las tablas, los datos que manejan y como stos se relacionan. Se analizan las reg las de negocio que gobiernan los datos. Esta fase brinda una visin global de la i nformacin que mantienen los sistemas operacionales. Es importante contar con mode los conceptuales ya que permiten visualizar las relaciones existentes entre los datos. Si no existe documentacin de los mismos, se deben construir. Metadata a ge nerar: Modelos fsicos de las bases de datos fuente. Modelos conceptuales de las b ases de datos fuente. Mapeo entre modelos conceptuales y modelos fsicos de las ba ses de datos (bd) fuente. Documentacin sobre las reglas de negocio. Informe Principal 57

Sistema DW: Carga y Control de Calidad 2. Identificacin de datos requeridos Se identifican los objetos de los modelos co nceptuales de las bd fuente que manejan la informacin requerida por el modelo mul tidimensional. Se realiza un mapeo entre los elementos del modelo multidimension al y los objetos de los modelos conceptuales. Este tipo de anlisis permite identi ficar, Datos requeridos: informacin requerida mantenida en un sistema fuente, Dat os que Faltan: informacin requerida no mantenida en ningun sistema y Datos a Inte grar: informacin requerida mantenida por ms de un sistema. Tambin se pueden identif icar datos que si bien no son requeridos por el modelo multidimensional, pueden ser de utilidad para futuros requerimientos. Ver apndice por informacin acerca de la tcnica utilizada para realizar el mapeo. Metadata a generar: Mapeo entre eleme ntos del modelo multidimensional y objetos de los modelos conceptuales. 3. Anlisis detallado (Investigacin de datos) Siguiendo la medodologa para la limpie za de datos, se realiza un anlisis minucioso de los datos en cada tabla, estudian do todos los valores posibles en cada campo. La especificacin de las actividades que se deben realizar se encuentra en la seccin 2.3 Calidad de datos. Las tablas a analizar son aquellas que se correspondan con los objetos identificados como d e inters en la fase de identificacin de datos requeridos. El anlisis detallado da u na visin sobre el estado de calidad en que se encuentran los datos fuente. Permit e descubrir si la informacin que dice manejar el sistema, realmente es la que est almacenada, permite encontrar problemas en los datos y permite conocer la forma real de los mismos. Adems se pueden detectar manejos no documentados de los siste mas operacionales. Metadata a generar: Documentacin de resultados de las activida des. 3 4. Seleccin de datos Se seleccionan los datos a extraer de las bases fuente. Se c onstruye un modelo conceptual que permite visualizar en forma integrada el conju nto de datos de los sistemas fuente con los que se cuenta para cargar el futuro data mart. La seleccin se realiza en base al estado de calidad de los datos, cara ctersticas tecnolgicas de los sistemas fuente, confiabilidad de los datos, volatil idad de la informacin, accesibilidad de la informacin y cualquier aspecto consider ado de importancia a la hora de optar entre un sistema u otro cuando ambos manti enen la informacin de forma duplicada e incluso para no optar por ninguno cuando s tos no mantienen la informacin de forma correcta. Metadata a generar: Modelo conc eptual de integracin de datos seleccionados. Especificacin de integracin (en caso t rabajar con ms de un sistema fuente). Mapeo entre modelo conceptual integrado y m odelos fsicos de las bd fuente. 5. Anlisis de carga Se analizan los puntos principales que deben considerarse par a realizar la carga de datos al data mart. El diseo del proceso de carga debe con templar todos los puntos analizados. Informe Principal 58

Sistema DW: Carga y Control de Calidad Datos que Faltan: datos identificados como requeridos pero que no se encuentran en los sistemas fuente o que s se encuentran pero se descartan por su bajo nivel de calidad. N Datos a Integrar: distintos datos fuente que se corresponden a un mismo objeto del modelo conceptual de datos seleccionados. N Datos a Calcular: e lementos del modelo multidimensional (en general medidas) que se calculan a part ir de objetos del modelo conceptual de datos seleccionados. N Datos a Transforma r: campos de objetos seleccionados cuyos valores deben transformarse a la forma especificada en el modelo multidimensional. N Datos a Limpiar: datos fuente que requieren limpiarse para ingresar al data mart. N Granularidad de Datos: anlisis del nivel de granularidad en el que se almacenarn los datos del data mart. El niv el esta dado en un principio por el modelo multidimensional pero puede ser de ut ilidad almacenar los datos a uno o varios niveles ms de granularidad, como tambin puede no contarse con los datos al nivel requerido. N Volatilidad de la Informac in: la volatilidad de los datos fuente influye en la periodicidad con que se debe n cargar dichos datos al data mart. Se debe analizar la volatilidad de los datos correspondientes a objetos del modelo conceptual de datos seleccionados. N Evol ucin en el Tiempo: debe analizarse si se puede obtener la evolucin en el tiempo de todos los datos requeridos segn el modelo multidimensional. N Tecnologa Disponibl e: todos los problemas relacionados a la tecnologa de los sistemas operacionales, el data warehouse, vas de comunicacin, etc, influyen en diseo del proceso de carga y por lo tanto deben analizarse. N Volumen de datos: el volumen de datos que ma nejar periodicamente el proceso de carga y que ir haciendo incrementar el volumen de datos del data mart, influye tanto en el diseo del data mart relacional como d el proceso de carga. N Accesibilidad a los Datos Fuente: debe analizarse si todo s los datos seleccionados de los sistemas operacionales podrn ser extrados peridica mente. Por problemas organizacionales, polticos, de confiabilidad, etc. no siempr e puede contarse con toda la informacin requerida. Metadata a generar: Documentac in de los puntos mencionados. 6. Integracin con otros Data Marts Se analizan posib les problemas de integracin con la informacin almacenada en el data warehouse rela cional. Se debe analizar si dentro de los data mart ya construdos se encuentra in formacin que es requerida por el data mart en construccin y/o que pueda entrar en conflicto con el mismo. Se deben analizar posibles soluciones de integracin. Es i mportante tener una buena documentacin de los data marts que constituyen el data warehouse para asi poder acceder a la misma a la hora de realizar este anlisis. E n caso de desarrollar varios data marts en paralelo, se deben estudiar los anlisi s de dichos data marts para detectar puntos de contacto que puedan presentarse y resolver los conflictos. Metadata a generar: Documentacin de conflictos y posibl es soluciones. N Informe Principal 59

Sistema DW: Carga y Control de Calidad Diseo El objetivo de esta etapa es, disear el proceso global de carga y disear el data m art relacional. Por lo primero se entiende definir el conjunto de procesos que c argan los datos al data mart. Lo segundo consiste en definir las tablas que comp onen el data mart relacional y cualquier otra estructura auxiliar necesaria. 1. Arquitectura del data mart Se definen en forma general los componentes del data mart, tanto procesos como estrucuturas de almacenamiento. La construccin de la ar quitectura se ve influenciada por las siguientes variantes: ubicacin de los datos fuente, manejador de bd (RDBMS) del data warehouse, herramientas disponibles pa ra desarrollar el proceso de carga, espacio de almacenamiento disponible, comple jidad del proceso de carga, etc. Se toman decisiones acerca de herramientas a ut ilizar, lenguajes de programacin, protocolos de comunicacin, manejadores de base d e datos, etc. Metadata a generar: Documentacin de componentes del data mart. 2. D iseo de tablas Se realiza el diseo de las tablas relacionales del Data Mart y de c ualquier otra estructura auxiliar necesaria tanto para facilitar la carga como p ara la limpieza y tansformacin de datos. Para realizar el diseo de las tablas del Datamart, se utiliza el conjunto de primitivas presentado en la tesis 'A transfo rmations based approach for designing the Data Warehouse'. Las primitivas recibe n como entrada, esquemas de tablas relacionales y devuelven esquemas de tablas d iseadas adecuadamente para un data warehouse. Adems documentan la forma de transfo rmar los datos para pasarlos de la tabla original a la tabla destino del data wa rehouse. Es a partir de la total comprensin del modelo multidimensional que se pu ede seleccionar qu primitiva aplicar a la hora de disear el data warehouse. La sel eccin de las primitivas se ve influenciada por: N nivel de granularidad requerido N performance de las consultas al data mart N espacio de almacenamiento disponi ble N complejidad y performance del proceso de carga Informe Principal 60 3

Sistema DW: Carga y Control de Calidad El proceso de diseo parte de un esquema de tablas relacionales, diseadas para mant ener datos operacionales, a las cuales se les aplican repetidamente las primitiv as de transformacin, hasta obtener un diseo adecuado para el modelo multidimension al del data mart. Metadata a generar: Documentacin de primitivas aplicadas y proc eso de aplicacin. Modelo fsico de tablas del data mart. Documentacin del contenido del data mart relacional. 3. Diseo de la carga Se realiza el diseo de las distintas rutinas de extraccin y ca rga de datos al data mart. Se disean rutinas de limpieza de datos que resuelvan l os problemas de calidad detectados en la etapa de anlisis. La complejidad del pro ceso de carga est dada por la complejidad del negocio y del modelo multidimension al junto a la calidad en que se encuentran los datos. Se define la periodicidad de la carga teniendo en cuenta la volatilidad de los datos en los sistemas fuent e y la realidad del negocio. En caso de utilizar una herramienta que se encarge de realizar toda o parte del proceso de carga, en esta etapa se define la parame trizacin necesaria en lugar de disear las rutinas de carga. Metadata a generar: Do cumentacin del proceso de carga/Parametrizacin. 3 Implementacin En esta etapa se implementan los diseos desarrollados en la etapa anterior. En ca so de disponer de herramientas que faciliten el proceso de carga, se parametriza n las mismas. Metadata a generar: Ubicacin y descripcin de: servidores, bases de d atos, tablas y programas de carga. Informacin de herramientas, lenguajes de progr amacin utilizados y estndares aplicados. Informe Principal 61

Sistema DW: Carga y Control de Calidad '(6&5,3&,21 7(&1,&$ El sistema DW es introducido en el captulo anterior, donde se presentan sus compo nentes principales. En las secciones 3.1 y 3.2, se plantea el sistema a construr en este proyecto y la estrategia de desarrollo utilizada para realizarlo. Para c ompletar lo que sera una visin global del proyecto, se presenta ahora un resumen d e las etapas en la construccin de los datamarts de Presupuesto y Bedela, haciendo incapi en los resultados obtenidos en cada una de ellas. La descripcin detallada s e encuentra en el Apartado 1, Desarrollo del sistema DW. Dentro del sistema cons trudo se encuentra el data warehouse, diseado para apoyar la toma de decisiones de las comisiones encargadas del presupuesto de la facultad y del seguimiento de l os estudiantes. La informacin relativa a cada rea de negocios se almacena en los d istintos data marts del data warehouse (Presupuesto y Bedela). Las bases de datos operacionales participan del sistema brindando la informacin requerida. Diferent es procesos de carga transladan los datos de los sistemas operacionales hacia el data warehouse. Los datos sufren una serie de modificaciones antes de ingresar al data warehouse, que incluyen chequeos de calidad, integraciones, estandarizac iones, formateos y transformaciones. La bd limpia de Presupuesto apoya al proces o de carga, almacenando los datos fuente luego de haber sido chequeados, integra dos y estandarizados. La bd fuente auxiliar de Bedela contiene una copia de algun os datos de la bd del sistema operacional de Bedela. La metadata del sistema docu menta la informacin relativa a la estructura y contenido de las bases de datos in volucradas (bd. sistemas operacionales, bd. auxiliares y data warehouse) y los p rocesos de carga desarrollados. En la figura 16 se visualiza el sistema construdo . 3 Figura 16: Arquitectura del sistema construdo Informe Principal 62

Sistema DW: Carga y Control de Calidad En un principio se construye el data mart de Presupuesto, generndose la primer ve rsin del data warehouse. Luego se desarrolla el data mart de Bedela y se lo integr a al data warehouse. La integracin es trivial porque los datamarts no tienen dato s en comn. Ambos data mart se desarrollan aplicando la Estrategia de Desarrollo p ropuesta en la seccin 3.2. REQUERIMIENTOS Los datamarts de Presupuesto y Bedela deben construirse sobre una base de datos O racle que se encuentra en un servidor Unix dentro del INCO. El servidor est conec tado a una intranet por la cual tambin se podr acceder al sistema. Presupuesto El modelo conceptual multidimensional de Presupuesto es entregado por el grupo ' SISTEMA DW: OLAP' y tomado como requerimiento en el desarrollo del data mart de Presupuesto. Documenta la informacin de relevancia para el data mart y de su anlis is se deriva la informacin que deber almacenar el data warehouse. El Reelevamiento de Fuentes de Presupuesto, se realiza en base a entrevistas con los funcionario s de la Seccin de Personal de la F.I. La misma utiliza dos sistemas operacionales independientes para llevar el presupuesto de la facultad, los llamamos Sistema O riginal y Sistema Nuevo. Manejan informacin relativa a los cargos ejecutados (un fun cionario ocupa el cargo y recibe un sueldo por ello), cargos vacantes y comprome tidos, movimientos de los cargos, funcionarios, institutos de la F.I., fuentes d e financiancin y relacin entre los sueldos de los funcionarios con su grado y cant idad de horas trabajadas. Algunos datos son manejados unicamente por un sistema y otros datos son manejados por ambos sistemas 3 Bedela El modelo multidimensional de Bedela es entregado por el grupo 'SISTEMA DW: OLAP' y tomado como requerimiento en el desarrollo del data mart de Bedela. El Reeleva miento de Fuentes de Bedela es complejo porque no se tiene acceso a la bd del sis tema operacional de Bedela de la F.I. Se utiliza como fuente de datos para el dat a mart una base de datos fuente auxiliar donde peridicamente se copia informacin p roveniente del sistema operacional de Bedela. Dicha bd maneja informacin de los es tudiantes, carreras, materias, inscripciones de estudiantes en carreras y result ado de los estudiantes en las actividades de las materias. El relevamiento se re aliza analizando la documentacin de la bd. fuente auxiliar. Por una descripcin ms detallada de la etapa de requerimientos y los resultados obt enidos ver la seccin 1.1 y 2.1 del Apartado 1. Informe Principal 63

Sistema DW: Carga y Control de Calidad ANALISIS El anlisis es una etapa crucial dentro del desarrollo, todo lo analizado influye en el diseo del data warehouse y su carga, todo lo pasado por alto repercute la f eliz culminacin del sistema DW. La figura 17 presenta un esquema general de la et apa de anlisis aplicada en el desarrollo del data mart de Presupuesto. Se present a la misma para el caso de este data mart porque tiene la particularidad de part ir de dos sistemas operacionales independientes que manejan informacin de inters. Se muestran los resultados obtenidos y las flechas que representan la relacin ent re los mismos. 3 Figura 17: Overview de la etapa de anlisis del data mart Presupuesto Informe Principal 64

Sistema DW: Carga y Control de Calidad Presupuesto El anlisis de presupuesto comienza estudiando las bases de datos fuente, en parti cular la bd del Sistema Original y del Sistema Nuevo. Se analiza su estructura y con tenido. La bd del Sistema Original es completamente desnormalizada. La bd del Si stema Nuevo tampoco es una base normalizada y algunas tablas tienen la misma est ructura solo difieren en su contenido. Como no existen modelos conceptuales de l as mismas, se construyen aplicando tcnicas de reingeniera de datos. Al no poseer d ocumentacin de los sistemas, la construccin de los modelos conceptuales se vuelve por momentos compleja. Una vez obtenidos los modelos conceptuales, se realiza la identificacin de datos requeridos, mapeando las entidades del modelo multidimens ional (dimensiones y medidas) con las entidades de los modelos conceptualues. En la figura 17 puede observarse que el mapeo se realiza para cada sistema fuente. Con ello se analiza si la informacin requerida en el modelo mutlidimensional exi ste en las bases de datos fuente y cules son las entidades conceptuales que la ma nejan. Algunas entidades requeridas no se encuentran en las bd fuente y algunas otras se encuentran en ambas. El anlisis detallado permite visualizar el estado d e calidad de los datos fuente y la forma real de los mismos. El Sistema Nuevo supe ra en calidad al Sistema Original, lo que constituye un resultado decisivo para realizar la seleccin de datos. El anlisis detallado revela que los sistemas operac ionales son manejados en forma especial por los usuarios de la Seccin de Personal para que cumplan con sus necesidades. Los datos del Sistema Original no cumplen estndares, se encuentra mucha informacin importante dentro de campos de texto sin formato alguno. Se realiza la seleccin de datos fuente teniendo en cuenta la ide ntificacin de datos requeridos y el anlisis detallado. En la figura puede verse un cuadro que representa la seleccin de sistema fuente cuando los datos estn en ms de uno. Se construye como resultado, el modelo conceptual integrado de los datos f uente seleccionados. Este modelo brinda una visin completa de los datos disponibl es para cargar el data mart de Presupuesto. Para un mejor entendimiento de la fu ente fsica especfica de los datos seleccionados, se documenta el mapeo entre el mo delo conceptual y las estructuras fsicas correspondiente (de las bd fuente). Habi endo finalizado la seleccin de datos, se analizan todos los asuntos relacionados a la carga de los datos fuente al data warehouse. Se utiliza como gua los puntos de anlisis de carga presentados en la estrategia de desarrollo. Todo lo analizado influye luego en el diseo del data mart relacional de Presupuesto y su carga. Al finalizar el anlisis se interacta con el grupo 'SISTEMA DW: OLAP'. Se les informa de los datos requeridos que estn disponibles y de los no disponibles. Se discute n asuntos particulares de la carga, algunos clculos se desiden materializar en el data warehouse para facilitar la implementacin multidimensional. Se determinan f ormatos especiales de los datos, tipos de carga de los cubos(incremental o total ), etc. 3 Informe Principal 65

Sistema DW: Carga y Control de Calidad Bedela Se comienza analizando la estructura y contenido de la bd fuente auxiliar de Bed ela en base a documentacin de la misma y se construye un modelo conceptual de la m isma. La bd tiene una estructura en general normalizada. Algunas tablas tienen l a misma estructura y difieren en su contenido segn los datos correspondan a estud iantes del plan nuevo, de planes viejos o adaptados al plan nuevo. A partir del modelo multidimensional y el modelo conceptual se realiza la identificacin de dat os requeridos. La mayora de la informacin requerida se encuentra en la bd fuente. El anlisis detallado brinda una visin del nivel de calidad que tienen los datos fu ente. Revela que los datos son de buena calidad, estn estandarizados y no present an grandes problemas. El anlisis de Bedela fue ms sencillo por solo involucrar una base fuente. En ste caso, se Identificaron los datos requeridos, pero la seleccin de fuentes fue trivial. Tambin result simple la construccin del modelo conceptual d e datos seleccionados, por no existir ms de una fuente. La seleccin de datos es re lativamente sencilla porque no se presentan problemas de calidad en los datos y solamente se cuenta con un sistema fuente de datos. Se construye un modelo conce ptual de los datos seleccionados. En el anlisis de carga se estudian los distinto s puntos a considerar en la carga del datamart para que los datos fuente cumplan con la forma requerida por el modelo multidimensional. Al ser Bedela el segundo data mart en construrse, se realiza la etapa de integracin con otros data marts. E n este caso es trivial porque no hay datos en comn con el data mart de Presupuest o. 3 Por una descripcin ms detallada de la etapa de anlisis y los resultados ver la secc in 1.2 y 2.2 del Apartado 1. Informe Principal 66

Sistema DW: Carga y Control de Calidad DISEO En la etapa de diseo se define la arquitectura general del data mart, se disean la s tablas relacionales y el procesos de carga. Las tablas se disean utilizando las primitivas vistas en la seccin 2.4. En la figura 18 se grafica la etapa de diseo de un datamart. Se muestra el caso en que se crea una bd limpia para facilitar e l proceso de limpieza si ste es muy complejo (no siempre es necesario). El data m art de Presupuesto es un ejemplo en el que se disea una bd limpia. 3 Figura 18: Overview de la etapa de diseo Presupuesto Como primer instancia se define la arquitectura del data mart de Presupuesto. Da dos los problemas de calidad encontrados en los datos fuente se decide crear una bd limpia (tablas limpias) donde ingresar temporalmente dichos datos luego de h aber sido chequeados, integrados, limpiados y verificados que cumplan con las re stricciones de integridad. En esa base se ingresan unicamente datos validos. Informe Principal 67

Sistema DW: Carga y Control de Calidad En el anlisis se encontr que algunos datos requeridos no se hallaban en las bd fue nte. Se decide almacenar esos datos en el data warehouse (tablas base) y crear p rocesos para que se ingresen los mismos. Se disean las tablas limpias para almace nar temporalmente los datos fuente luego de ser validados. El diseo de estas tabl as se realiza en base a la estructura de las bd fuentes para no complicar el pro ceso de carga. En la figura 18 la flecha entre el modelo fsico fuente y el modelo fsico de la bd limpia representa el diseo realizado. El modelo fsico fuente se obt iene del mapeo entre el modelo conceptual de los datos seleccionados y las bd fu ente de Presupuesto (se realiza en el anlisis), representa las estructuras fsicas que almacenan los datos seleccionados. Se disean las tablas base de modo que perm itan almacenar la informacin que indica el modelo multidimensional de Presupuesto y que no se encuentra en las bd fuente. Estas tablas forman parte del data mart de Presupuesto, su diseo no se muestra explcitamente en la figura 18. El modelo fs ico del data mart de Presupuesto se disea aplicando el conjunto de primitivas a l as estructuras del modelo fsico de la bd limpia. En la figura 18 se representa la realizacin del diseo mediante las flechas anchas que pasan por las primitivas has ta llegar al modelo fsico del data mart. Las tablas se disean de forma de optimiza r en lo posible la consulta a las mismas teniendo en cuenta de no complicar el i ngreso de datos que debe realizar periodicamente el proceso de carga. Los nuevos datos se ingresan mediante inserts unicamente. Se disean varios procesos de carg a representados en la figura 18 por las flechas celestes rectas. Uno de los proc esos lleva ciertos datos seleccionados directamente al data mart, transformndolos y chequandolos antes de ser ingresados. Otro en cambio extrae el resto de los da tos seleccionados, los chequea, integra, limpia e ingresa en la bd. limpia tempo ral. Por ltimo el siguiente proceso tomar los datos limpios y los transformar para ingresarlos finalmente al data mart. Este ltimo se basa en las sentencias definid as en las primitivas utilizadas para realizar el diseo del data mart. Los tres pr ocesos de carga se unen en un gran proceso que se debe ejecutar mensualmente. Bedela La arquitectura que se define para el data mart de Bedela es ms simple que la defi nida para el de Presupuesto. En este caso se decide que los datos fuente se ingr esen al data mart directamente, no hay bd limpia intermedia. S se definen vistas para unificar las tablas que tienen igual estructura. El modelo fsico del data ma rt se disea utilizando las primitivas. Se parte del modelo fsico de los datos sele ccionados y se aplican las primitivas reiteradamente hasta alcanzar un diseo adec uado al modelo multidimensional de Bedela ( de modo de optimizar las consultas). El proceso de carga toma los datos seleccionados, los chequea, limpia y transfor ma para ingresarlos luego al data mart. El proceso se divide en tres subprocesos que se debern Informe Principal 68

Sistema DW: Carga y Control de Calidad ejecutar peridicamente en distintos perodos del ao. Las inscripciones a carreras se cargan anualmente luego de finalizado el perodo de inscripciones. Los resultados de las actividades se cargan luego de finalizados los perodos de feb-marzo y jul io-agosto. El desempeo de los estudiantes se carga anualmente luego de finalizado cada ao escolar (finaliza en marzo). Todos los procesos de carga ( de ambos data marts) ingresan en un log de errores los problemas encontrados en los datos fue nte. Se ingresa el tipo de error y el registro de datos fuente. El tipo de error indica si los datos fueron ingresados al data mart a pesar del problema o direc tamente descartados por ello. Por una descripcin detallada de la etapa de diseo de ambos data marts ver las secc iones 1.3 y 2.3 del Apartado 1. 3 Informe Principal 69

Sistema DW: Carga y Control de Calidad IMPLEMENTACION El data warehouse se implementa en una base de datos Oracle, que se encuentra en el servidor Unix (Felipe) del INCO. Los procesos de carga de ambos data marts se implementan en PLSQL y se almacenan en la misma bd del data warehouse. Se genera una aplicacin, desarrollada en Visual Basic, como interfase para ejecutar los pr ocesos de carga. La aplicacin unifica todos los procesos de carga y brinda abms pa ra ingresar ciertos datos de presupuesto que no se encuentran en las bd fuente. Permite visualizar la lista de errores encontrados durante los procesos de carga en los datos fuente. 3 Figura 19: Implementacin En la figura 19 se distinguen las diferentes funcionalid ades que brinda la aplicacin grfica de los Procesos de Carga. Los distintos ABMs tr abajan directamente con las tablas correspondientes en el data mart de Presupues to. La interfaz grfica de las cargas de Presupuesto y Bedela llaman a procedimient os PLSQL almacenados en la bd del data warehouse. Los procedimientos PLSQL se en cargan de realizar todos los procesos de carga. Las flechas salientes sealan los niveles de componentes del data warehouse con los que trabajan los procesos. En la secciones 1.4 y 2.4 del Apartado 1 se encuentra una descripcin detallada de lo implementado. En la secciones 5 y 6 del Apartado 2 se encuentran la definicin de la bd del data warehouse y los pseudocdigos de los procesos de carga implementad os en PLSQL respectivamente. El apartado 3 describe cmo usar la aplicacin de inter faz grfica de los procesos de carga. Informe Principal 70

Sistema DW: Carga y Control de Calidad CONCLUSIONES 4 4 Informe Principal CONCLUSIONES 71

Sistema DW: Carga y Control de Calidad 21&/86,21(6 ),1$/(6 Al llegar al final del proyecto, podemos decir que el desarrollo de un Sistema d e DW es complejo. Abarca gran cantidad de personas, usuarios finales del DW, usu arios de los sistemas fuente, desarrolladores, etc. Tambin comprende diferentes c omponentes, sistemas fuente, herramientas de extraccin, herramientas de consulta, redes, aplicaciones de usuario final, bases de datos, etc. Un Sistema de DW deb e combinar todos stos elementos y brindar un producto final consistente, amigable y confiable que a su vez est preparado para enfrentar los continuos cambios que surjan debido a su tan variada estructura. Un trabajo no trivial. El desarrollo de un sistema de DW es diferente al desarrollo de un sistema operacional. A gran des rasgos, uno apoya al negocio transaccional y el otro al decisional. El rea de DW es un terreno nuevo en el cual queda mucho por experimentar. No existe an, un a metodologa universalmente reconocida para construir un sistema de esta ndole. Es por esto que construmos una estrategia de trabajo que sirva de gua durante el des arrollo. La misma, fue elaborada por nosotros a lo largo del proyecto y actualiz ada a medida que la ibamos experimentando. Consideramos la estrategia un aporte interesante al proyecto que puede ser de utilidad a futuros desarrollos. No disp oner de herramientas de apoyo especficas para la construccin de un sistema de DW c omo ser, herramientas de extraccin transformacin e integracin de datos, detectores de reglas en los datos, reconocedores de patterns, etc., agreg complejidad al des arrollo, afect los tiempos del mismo y priv de experimentar nuevas tecnologas exist entes en la actualidad. De todas formas se desarroll un sistema lo ms completo y c onfiable posible. MODELO MULTIDIMENSIONAL El modelo multidimensional result de suma importancia a la hora de construir los data marts. Especifica los puntos fundamentales para realizar el diseo del data m art relacional y su carga. La dimensin tiempo, siempre presente, influye cualitat ivamente en el diseo del data mart relacional. El volumen de datos a almacenar en el data mart depende directamente de esta dimensin. No siempre es posible cumpli r con el nivel de granularidad requerida (da, semana, quincena, etc.) en el model o multidimensional, para sta dimensin. Depender de la capacidad de almacenamiento, la volatilidad de los datos fuente y la complejidad de los clculos. En el comienz o del proyecto, contbamos unicamente con los requerimientos de usuario. No estaba definida la interaccin con el desarrollo OLAP y entonces se decidi comenzar con e l anlisis a partir de los requerimientos de usuario, mientras se esperaba el mode lo multidimensional. Con esa informacin, el diseo del data mart era complejo de re alizar. 4 Informe Principal 72

Sistema DW: Carga y Control de Calidad Se pens, hacer un modelo conceptual relacional del data mart para comenzar con el diseo. Pudimos experimentar que dicho modelo conceptual no tiene la capacidad pa ra modelar los datos variantes en el tiempo y tampoco es eficaz para modelar los cruzamientos entre todas las dimensiones. En este proyecto utilizamos finalment e el modelo conceptual definido en el trabajo Modelo Conceptual Multidimensional p resentado por el profesor Ing. Fernando Carpani en su tesis de maestra. Independi entemente del modelo especfico a utilizar, se encontraron algunas caractersticas mn imas necesarias que debe tener dicho modelo para ser de utilidad. Debe: N defini r las dimensiones (o perspectivas de anlisis), especificando su significado y la informacin que manejan N definir las medidas (o indicadores), especificando su si gnificado N definir los cruzamientos, indicando las medidas interesantes a obten er en cada uno de ellos (no siempre interesan todas las medidas para todos los c ruzamientos) N especificar el mayor nivel de granularidad por el que se quieren ver las medidas Actualmente en los desarrollos de sistemas de DW se manejan dife rentes modelos, no existe uno universalmente aceptado. La estrategia de desarrol lo planteada en esta tesis es independiente del modelo, pero si en un futuro sur je modelo radicalmente diferente podra ser necesario modificarla. DIVISION HORIZONTAL DEL TRABAJO En este proyecto se experiment una forma de trabajo en particular, donde el siste ma de DW se construye como dos desarrollos paralelos que interactan en su camino. Es una forma interesante de trabajar, por lo menos en lo que respecta al desarr ollo del data mart relacional y su carga. Las tareas que nos competen, pueden se r complejas y necesitar de varios meses para su elaboracin, lo mismo ocurre con r especto al desarrollo OLAP. Trabajando en paralelo, se reduce el tiempo total de construccin del sistema y es posible centrar la atencin en los puntos importantes dentro de cada desarrollo. Fue un primer acercamiento a esta forma de trabajo y por lo tanto quedan elementos por definir. La interaccin entre ambos equipos deb e discutirse ms en detalle, evitando trabajos duplicados. La pieza fundamental en la interaccin es el modelo multidimensional. Debe profundizarse en temas como, e l momento en que el grupo de desarrollo OLAP entrega el modelo, si el modelo deb e ser armado considerando los requerimientos de usuario y conociendo los datos q ue manejan los sistemas operacionales, o solamente a partir de la realidad del n egocio. Estos puntos influyen en el proceso de desarrollo del sistema y su durac in. Es interesante destacar, que la segunda interaccin, donde se comunica al desar rollo OLAP si se cuenta realmente con todos los datos requeridos, puede tener un impacto importante en el diseo de los cubos multidimensionales. O sea, es probab le que los cubos a disear no cumplan directamente con lo analizado en el modelo m ultidimensional porque la informacin no existe. En cambio, dicha segunda interacc in no influye de manera tan importante a este 4 Informe Principal 73

Sistema DW: Carga y Control de Calidad grupo de desarrollo. El diseo se realiza principalmente en base a los resultados de la etapa de anlisis, teniendo en cuenta las consideraciones que surjen de la i nteraccin. ESTRATEGIA DE DESARROLLO Tener una estrategia de desarrollo es fundamental para construir un sistema de D W. Con una estrategia definida, es posible planear la totalidad del desarrollo, estimar plazos, organizar las tareas. Sirve como gua, marcando los objetivos en c ada etapa, definiendo las tareas a realizar y la documentacin a elaborar. Un sist ema de DW significa mucho trabajo de anlisis, por cierto complejo en muchos casos . La estrategia pone nfasis en esta etapa, permitiendo realizar un anlisis en form a completa y detallada. Tambin destaca la importancia de la calidad de los datos en el data warehouse, definiendo tareas especficas para alcanzar este fin. La est rategia planteada es un primer acercamiento a la definicin de un proceso de desar rollo de un sistema de DW. Como se explic en su presentacin, se centra en la const ruccin del data mart relacional y su carga. Consideramos importante continuar la formalizacin de la estrategia para poder alcanzar un proceso de desarrollo ms auto matizado. La formalizacin en la especificacin de la Metadata a generar en el desar rollo es otro punto interesante de estudio. La interaccin con el grupo OLAP es ot ro aspecto a mejorar el cual se ir perfeccionando con la puesta en prctica de la e strategia. DISEO DEL DATA WAREHOUSE RELACIONAL Si desarrollamos un sistema operacional, sabemos con certeza disear su base de da tos relacional. En ese caso, el diseo debe permitir almacenar informacin sin redun dancia innecesaria y a la vez permitir recuperar la informacin fcilmente. Son univ ersalmente conocidas las tcnicas para disear bases de datos normalizadas, por ejem plo utilizando dependencias funcionales. Sin embargo para los sistemas de DW las tcnicas de diseo estn an en investigacin y experimentacin. Una base de datos normaliz ada no es una cualidad en este caso, sino todo lo contrario, el objetivo princip al pasa a ser el acceso rpido a los datos. Podra pensarse entonces que un diseo a i magen y semejanza del modelo multidimensional sera lo mejor, nos referimos a tene r una tabla por cada dimensin y una gran fact table con todos los cruzamientos y medidas. La carga de los cubos multidimensionales sera ptima, pero qu hay de la car ga de los datos fuente a dichas tablas? No siempre se cuenta con todos los datos al mismo tiempo, algunos datos se calculan a partir de otros, no todas las medi das tienen sentido para todos los cruzamientos de dimensiones posibles, etc. Por todo esto, la carga del data warehouse se volvera compleja, de baja performance y difcil de mantener, teniendo que actualizar datos, realizar clculos complejos, i ngresar valores dummys, etc. 4 Informe Principal 74

Sistema DW: Carga y Control de Calidad El punto justo est entonces en disear el data warehouse de forma de optimizar las consultas sin complicar su carga y no olvidar que el data warehouse debe almacen ar todo lo especificado en el modelo multidimensional. Es aqu donde juegan un pap el importante las primitivas documentadas en el trabajo 'A transformations based approach for designing the Data Warehouse'. Las mismas resumen las tcnicas de di seo existentes y estn especificadas de forma clara por lo que son fciles de utiliza r. Las primitivas brindan un conjunto de soluciones de diseo, el diseador solament e debe encontrar la que sea ms apropiada para el caso en particular y aplicarla. Se parte de la estructura fsica de las tablas fuente y se aplican las primitivas reiteradamente de forma de transformar el diseo de las tablas fuente a tablas con un diseo adecuado para un data warehouse. Qu se necesita para poder utilizar las primitivas ? Conocer las estructuras de tablas donde se encuentran almacenados l os datos fuente seleccionados. Entender el contenido de dichas tablas fuente y c omprender perfectamente el modelo multidimensional. En la experiencia obtenida d urante este proyecto observamos que si bien las primitivas pudieron ser aplicada s en la mayora de los casos, existan situaciones que las mismas no consideraban. R esumiendo, estn pensadas para ser aplicadas a diseos normalizados de bases de dato s y no siempre los sistemas operacionales cuentan con dicha cualidad. A su vez, especifican las transformaciones que deben realizarse a los datos pero suponen q ue los datos fuente son limpios y no necesitan ser validados. Entonces, cuando se est frente a una fuente de datos de bajo nivel de calidad, para poder utilizar la s primitivas, primero se debe crear una data staging area (o base de datos limpia) donde ingresar los datos limpios y aplicar las primitivas a esas tablas, fue el caso del data mart de Presupuesto. Para el caso de Bedela, los problemas de cali dad no eran graves y no fue necesario crear tablas limpias, sin embargo las tran sformaciones especificadas en las primitivas no eran suficientes para disear el p roceso de carga ya que igualmente se necesitaban realizar validaciones, filtros y transformaciones a los datos fuente. Quedan asuntos interesantes por discutir, como ser qu almacenar en el data warehouse datos primitivos o datos calculados?, d atos al mayor nivel de granularidad especificado en el modelo multidimensional o a otro nivel aun mayor (si es posible)? Son preguntas que surgieron en este pro yecto y para las que se tomaron soluciones adecuadas a cada caso. Pero son tambin preguntas que pueden aparecer en cualquier otro caso y sobre las que se encuent ran respuestas dispares. CALIDAD Durante la investigacin realizada sobre el tema calidad, descubrimos la importanc ia que sta tiene en los sistemas de DW. Datos que pueden ser aceptables para un s istema operacional pueden ser inutilizables para un sistema DW. Es un tema que n o se tuvo en cuenta en el inicio de la tecnologa DW y que surgi a partir de muchos fracasos millonarios de proyectos por esta causa. En un futuro los sistemas ope racionales podrn ser creados para que sus datos sean fcilmente utilizados por un s istema DW pero en la actualidad el reto est en tratar de aprovechar los billones de datos que ya hay almacenados. 4 Informe Principal 75

Sistema DW: Carga y Control de Calidad En este proyecto se dan pautas de cmo construir un data warehouse de calidad y cmo lograr la calidad a nivel empresarial. El primer punto fue considerado durante la construccin de ambos data marts ( presupuesto y bedela ), e incluso en la estra tegia de desarrollo planteada. El segundo punto, fue tenido en cuenta en la medi da de lo posible, pero en general las soluciones planteadas estaban fuera del al cance de este proyecto, no teniendo la autoridad necesaria sobre los sistemas op eracionales para realizarlas. Cabe resaltar que igualmente, todo lo documentado sobre dichos sistemas es un importante aporte para la reestructuracin y mejora de los mismos. Adems, se inform a los encargados de los sistemas de la seccin de Pers onal la importancia de ingresar datos correctos y en fecha y se dieron sugerenci as para mejoramiento de calidad a largo plazo (modificar el sistema) y a corto p lazo (cambios en ciertas operativas del mismo). Por ltimo, como feedback entre el usuario final del data warehouse y los usuarios de los sistemas operacionales s e implement un log de errores adecuado para poder identificar claramente problema s en los datos fuente. Dada la importancia de la calidad y el auge de los sistem as de DW, podran crearse talleres para profundizar el tema. Actualmente estn surgi endo en el mercado herramientas que brindan soluciones para limpiar datos, trans formarlos, descubrir reglas en los datos, etc. Sera interesante investigar dichas herramientas y experimentar de construir un data warehouse utilizndolas. Por otr o lado, sera tambin interesante desarrollar soluciones propias, automatizando algu nos puntos de la metodologa de limpieza planteada. Por ejemplo, que se almacenen en la bd las reglas de negocio y que el proceso de carga verifique que los datos cumplan esas reglas. Sera interesante estudiar la potencialidad que tiene el met adata del sistema sobre la limpieza de datos. Almacenando cierta metadata especi fca, en una forma adecuada permitira realizar varios chequeos en forma automtica. E l anlisis detallado de los datos es una tarea muy importante dentro del desarroll o que no debe dejarse de lado pero tambin es una tarea engorrosa de realizar si n o se cuenta con herramientas que faciliten su realizacin. Estn surgiendo varios pr oductos en el mercado que intentan realizar esta labor o parte de ella [P6, P9, P11]. Consideramos importante evaluar estos nuevos productos y su utilizacin en p royectos DW en nuestro medio. Definir mtricas para medir la calidad de los datos fuente sera un complemento til. La seleccin ( y por lo tanto descarte) de datos se basa en parte en los resultados obtenidos en el anlisis detallado. Una mtrica del estado de calidad de los datos brindara argumentos contundentes sin tener que baja r a los problemas particulares en los datos. Es posible que se d el caso de descar tar una base de datos fuente entera por problemas de calidad y los fundamentos d e tal decisin deben poder ser comprendidos por personas tanto de perfiles tcnicos como gerenciales. El argumento no puede ser la calidad es mala y tampoco un report e con el anlisis detallado. Las mtricas adems dan informacin de gran utilidad para e stimar la complejidad y tiempo de desarrollo de los procesos de carga. Para defi nir la mtrica se deben agrupar los problemas de calidad en categoras y definir las medidas interesantes sobre cada una de ellas. A su vez deben definirse los nive les mnimos o mximos (depende de que se est midiendo) de aceptacin en cada una. Por e j. si calculadas las medidas la mayora tienen niveles aceptables la base de datos se toma como fuente al DW y en caso contrario no. Informe Principal 76

Sistema DW: Carga y Control de Calidad TRABAJO FUTURO N N N N N N N N N Investigacin del tema Metadata, cmo aprovechar al mximo su informacin. Administracin de un sistema DW. Cmo enfrentar los cambios del negocio y de los sistemas operacio nales? Investigacin y desarrollo de tcnicas de diseo del data warehouse que se adap ten a los cambios. Reutilizacin en sistemas DW y la relacin con la metadata. Tunni ng del data warehouse. Optimizacin de procesos de carga. Que conviene ms: utilizac ion de data staging relacional o procesamiento secuencial. Planeamiento del desa rrollo, estimacin de tiempos, recursos y costos. Experimentacin de nuevas tecnologa s en el rea. Profundizar en la tcnica de identificacin de datos requeridos. Informe Principal 77

Sistema DW: Carga y Control de Calidad

*5$'(&,0,(1726 Queremos agradecer de forma especial la colaboracin brindada en el transcurso del proyecto por los profesores Raul Ruggia, Adriana Marotta y Joaquin Goyoaga. Sus aportes e inquietudes fueron de gran utilidad para nosotros. Tambin agradecer el enorme apoyo recibido por parte de la seccin de Personal de la Facultad de Ingen iera. Gracias por recibirnos y facilitarnos toda la informacin a su alcance para p oder llevar a cabo nuestra tarea. Debemos agradecer tambin a nuestros lugares de trabajo por la flexibilidad e inters demostrados. Por ltimo, queremos agradecer a nuestros familiares y amigos, su apoyo incondicional y su fuerza nos ayudaron en los momentos ms dficiles. Muchas Gracias. 4 Informe Principal 78

Sistema DW: Carga y Control de Calidad ,%/,2*5$),$ LIBROS [L1] Ralph Kimball. 'The data warehouse Toolkit'. 1996 [L2] Ralph Kimball. 'The data warehouse Lifecycle Toolkit'. 1998 [L3] Hardjinder , Gil, Rao. 'Data wareho using: La integracin de informacin para la mejor toma de decisiones'. 1996 [L4] Le n Silverston, W.H. Inmon, Kent Graziano. 'The datamodel resource book'. [L5] W.H . Inmon. 'Building the data warehouse'. [L6] Batini, Ceri, Navathe. Diseo conceptu al de bases de datos, Un enfoque de entidades-interrelacionales. 1994 [L7] Robert Orfali, Dan Harkey, Jeri Edwards. The Essential Client/Server Survival Guide. 199 6 ARTICULOS [A1] Richard Hackathorn. Data Warehousings Credibility Crisis. [BYTE Magazine, Agos to 1997 ] [A2] Ralph Kimball. Mastering Data Extraction. [DBMS, Junio 1996] [A3] R alph Kimball. Automating Data Extraction. [DBMS, Julio 1996] [A4] Ralph Kimball. De aling with Dirty Data. [DBMS, Setiembre 1996] [A5] Ralph Kimball. Its time for Data Compression. [DBMS, Octubre 1996] [A6] Joseph Williams. Tools for Traveling Data. [DBMS, Junio 1997 ] [A7] Kathy Bohn. Converting Data for Warehouses. [DBMS, Junio 1997] [A8] Ralph Kimball. Its Time for Time. [DBMS, Julio 1997] [A9] Ralph Kimball. A Dimensional Modeling Manifesto Drawing the Line Between Dimensional Modeling a nd ER Modeling Techniques. [DBMS, Agosto 1997] [A10] Ralph Kimball. Is Data Stagin g Relational?. [DBMS, Abril 1998] 4 Informe Principal 79

Sistema DW: Carga y Control de Calidad [A11] Jill Dyche. Scoping Your Datamart Implementation. [DBMS, Agosto 1998] [A12] Michele Bokun, Carmen Taglienti. Incremental Data Warehuose Updates: Approaches a nd Strategies for Capturing Changed Data. [DM Review, Mayo 1998 ] [A13] Neil Rade n. Data, Data Everywhere. [Information week, Octubre 1995] [A14] Neil Raden. Modeli ng The Data Warehouse. [Information week, 1996] [A15] Larry P. English. Help For D ata Quality. [Information week, Octubre 1996] [A16] Andy Feibus. An Easy-to-Use To ol For Data Transformation. [Information week, 1999] [A17] Wayne W. Eckerson. Buil ding the Legacy Systems of Tomorrow. Recipes of Prevention and Integration. [Open Information Systems, Noviembre 1995 Diciembre 1995] [A18] Rosemary Cafasso. Qual ity Control. [PC Week, Junio 1996] PUBLICACIONES [P1] The applied Technologies Group. Meeting the Data Integration Challenge.[1997] [www.techguide.com] [P2] The applied Technologies Group. A practical Guide to Ac hieving Enterprise Data Quality. [1998 ][www.techguide.com] [P3] The applied Tech nologies Group. Right Sizing Your Data Warehouse. [1998] [www.techguide.com] [P4] The applied Technologies Group. Managing the Warehouse. [1998] [techguide.com] [P5 ] The applied Technologies Group. Putting Metadata to Work in the Warehouse. [1998 ] [www.techguide.com] [P6] Vality Technology Inc. The Five Legacy Data Contaminan ts That You Will Encounter In Your Data Migrations. [1998] [www.vality.com] [P7] Duane Hufford. warehouse.com] Quality and the Data Warehouse. [1998] [www.data 4 [P8] Knosys Inc. Transforming Data into Understanding. [1998] [www.data warehouse. com] [P9] Kamran Parsaye, Mark Chignell. Quality Unbound. [1998] Informe Principal 80

Sistema DW: Carga y Control de Calidad [www.data warehouse.com] [P10] George Burch. Five Common Excuses For Not Reengine ering Legacy Data. [www.datawarehouse.com] [P11] Abraham Meidan. Wiz Rule: A New A pproach to Data Cleansing. [1998] [www.data warehouse.com] [P12] Louis Rolleigh a nd Joe Thomas. Data Integration: The Warehouse Foundation. [1998] [www.data wareho use.com] [P13] Bob Lambert. Data Warehousing Fundamentals: What You Need to Know to Succed [1998] [www.data warehouse.com] [P14] Charles B. Darling. How To Integra te Your Data warehouse. [1996] [www.datamation.com] [P15] Anne Knowles. Dump your dirty data for added profits. [1997] [www.datamation.com] [P16] Esprit Project 22 469 DWQ. Foundations of Data Warehouse Quality [1998] [www.cordis.lu/esprit/home.h tml] [P17] Ron Dvir, Dr. Stephen Evans. A TQM Approach to the Improvement of Info rmation Quality. [P18] Sophie Allen. Name and Address Data Quality. [www.mastersoft .com] [P19] K.I. Gordon. The why of data standards - Do you really know your data ?. [www.island.net/~gordon] [P20] IBM Corporation. The Road to Business Intelligen ce. [www.ibm.com] [P21] Veronika Peralta, Alvaro Illarze. 'Estudio de Tcnicas y So ftware para la Construccin de Sistemas de Data Warehousing'. [1998] [Facultad de Ingeniera, Universidad de la Republica] [P22] Adriana Marotta. 'A transformations based approach for designing the data warehouse'. [1999] [Facultad de Ingeniera, Universidad de la Republica] [P23] Fernando Carpani. 'Modelo Conceptual Multidi mensional'. [1999] [Facultad de Ingeniera, Universidad de la Republica] [P24] Osv aldo Varallo, Andrea Pereira. 'Sistema Data Warehousing: OLAP'. [1999] [Facultad de Ingeniera, Universidad de la Republica] 4 Informe Principal 81

Sistema DW: Carga y Control de Calidad Informe Principal 82