Ralph Kimball

UNIVERSIDAD AMERICANA FACULTAD DE INGENIERIA
GUA METODOLGICA PARA LA DEFINICIN Y DESARROLLO DE UN DATA WAREHOUSE
Br. ERICKA GRACIELA SEVILLA BERROS
Monografa para optar al grado de INGENIERO EN SISTEMAS
Profesor Tutor
ING. CARLOS ALBERTO ZEPEDA S.
Managua, Nicaragua, Marzo 2003
A Ericka Daniela, el ser que ha sido capaz de llenar con su esencia y presencia cada elemento de mi vida. Gracias por mostrarme el significado de vivir y amar
AGRADECIMIENTOS
A Ronaldo Sevilla y Vida Berros, mis amados padres, quienes me dieron la vida y hasta el da de hoy han guiado mi camino con su amor y dedicacin, porque siempre han estado all para m, con sus brazos abiertos llenos de comprensin y la preocupacin en el corazn, compartiendo mis alegras y tristezas, infinitas gracias y an es poco. A mi querido hermano Ronaldo, siempre dispuesto, perseverando y acompandome en el andar de la vida y para la construccin de esta monografa. A mi tutor Carlos, por su disponibilidad y ayudarme a delimitar y esclarecer mis ideas, a Flavia e Irene y dems amigos por todos sus consejos y su tiempo, y a mis compaeros y colegas que juntos recorrimos la senda del saber. A todas aquellas personas que no han escatimado sus palabras ni acciones para apoyarme, darme nimos, ideas, etc y que por razones de espacio no puedo enumerar.
CONTENIDO
INTRODUCCIN ................................................................................................. i I. II. ANTECEDENTES ..................................................................................iii OBJETIVOS ............................................................................................. v A. General: ................................................................................................. v B. Especficos:............................................................................................ v DESARROLLO DE LA TESIS............................................................................ 1 I. MARCO TERICO ................................................................................. 1 A. El Data Warehouse................................................................................ 1 B. Metodologas ms utilizadas para construir un Data Warehouse ......... 6 II. ANLISIS CUALITATIVO DE LAS METODOLOGAS .................. 40 A. Barry Devlin........................................................................................ 41 B. William Inmon..................................................................................... 43 C. Ralph Kimball ..................................................................................... 45 D. Sntesis ................................................................................................ 48 III. CONTEXTO NICARAGENSE........................................................... 50 IV. ESTUDIO DE FACTIBILIDAD............................................................ 53 A. Factibilidad Tcnica ............................................................................ 54 B. Factibilidad Operativa ......................................................................... 57 C. Factibilidad Econmico-Financiera .................................................... 61 D. Factibilidad Legal................................................................................ 67 E. Sugerencia para el proyecto................................................................. 69 V. A. GUA METODOLGICA PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE ........................................................................... 70 Etapa 1: Anlisis y Comprensin del Entorno Analtico .................... 72 B. Etapa 2: Definicin de una Arquitectura............................................. 74 C. Etapa 3: Enriquecimiento de Datos ..................................................... 85 D. Etapa 4: Construccin en Incrementos, Data Marts............................ 91 CONCLUSIONES .............................................................................................. 99 RECOMENDACIONES................................................................................... 101 ANEXO A: INDICES DE ILUSTRACIONES Y TABLAS ANEXO B: BIBLIOGRAFA ANEXO C: COTIZACIONES DE EQUIPOS Y CRONOGRAMA ANEXO D: ENTREVISTAS
ANEXO E: REQUERIMIENTOS DE HERRAMIENTAS SOFTWARE ANEXO F: MODELOS DE DATOS Y SCRIPTS ANEXO G: CORRESPONDENCIA FUENTE DESTINO Y RUTINAS ETL ANEXO H: REPORTES OBTENIBLES ANEXO I: GLOSARIO
INTRODUCCIN
El presente estudio monogrfico, satisface la necesidad de un marco de referencia para la construccin de un Data Warehouse, unificado y adaptado a profesionales o estudiantes de Informtica que inician su aprendizaje sobre sta tecnologa. El resultado obtenido es una gua metodolgica que apoya la definicin y ensea el desarrollo de un Data Warehouse que rene y unifica las metodologas ms aceptadas y que adems concuerda con el conocimiento que sobre este proceso tienen los principiantes que desean por primera vez introducirse en la construccin de un Data Warehouse. Todo esto con el propsito de que quien utilice y ponga en prctica la gua encuentre una referencia slida y comprensible que le dirija a travs del proceso de desarrollo de un Data Warehouse. Un Data Warehouse es una coleccin almacenada de datos corporativos originados en diversos sistemas transaccionales dentro de una organizacin. Un Data Warehouse es un repositorio nico de informacin cuyo propsito especfico es soportar la toma de decisiones en un negocio, no las operaciones del mismo, por ello se encuentra organizado de una forma muy distinta a las bases de datos tradicionales. En el contexto nacional, las empresas nicaragenses que desean expandir su mercado ms all de nuestras fronteras o mejorar su rendimiento en el sector en el que se desempean, deben ser competitivas y obtener ventajas de todos sus recursos para asegurar la efectividad de sus estrategias y su correspondiente remuneracin. Uno de los recursos ms importantes con los que cuenta cualquier organizacin es la informacin. La explotacin de la informacin de la empresa habilita a los ejecutivos tomar decisiones ms adecuadas y efectivas, fundamentalmente reconocer oportunidades y posibilidades de crecimiento. Sin embargo, el uso apropiado que se haga de la informacin de una empresa estar en dependencia de la calidad de los datos que la originan, la claridad del significado que tienen para los tomadores de decisiones, su estructura lgica, organizacin y la disposicin a tiempo y en forma. Si los datos son veraces y adecuados pero son extemporneos difcilmente servirn para la toma de decisiones, ya que la problemtica que se le present a la empresa no pudo ser resuelta de la mejor manera posible. La velocidad
en la evaluacin de diferentes alternativas es un elemento primordial para la supervivencia en el mundo de los negocios actuales. El escenario anterior puede ser resuelto apropiadamente con la construccin de un Data Warehouse. Cuando la implementacin de un Data Warehouse es xitosa aumentan las visitas de los usuarios al Data Warehouse y es en este aspecto en donde se produce el retorno de la inversin, ya que a travs de las decisiones tomadas a partir de la informacin consultada se incrementa la eficiencia de la organizacin, elevando los mrgenes de rentabilidad de la misma. Las empresas que tienen conocimiento de todas las ventajas que se obtienen de un Data Warehouse tienen entre sus planes estratgicos la construccin de uno. Sin embargo, el desarrollo de un Data Warehouse es una inversin cara y delicada, por el tipo de herramienta y plataforma informtica que se necesita para su construccin. Adems, el personal especializado que puede asesorar la implementacin exitosa es escaso en el pas, lo que hace costoso su reclutamiento. Los factores anteriores son los que ms han detenido a proyectos de Data Warehouse de ser implementados. Esta gua adaptada a profesionales o estudiantes de Informtica que inician su aprendizaje sobre sta tecnologa lograr hacer ms fciles las iniciativas de construccin de Data Warehouses ya se cuenta con un marco terico de referencia slido y sencillo que guiar a todo aquel que desee realizar una primera experiencia de desarrollo de Data Warehouse sin necesidad de comprometerse en un proyecto de gran envergadura sin previa experiencia, proporcionando de esta manera personal con buenas bases y nociones de lo que es Data Warehousing a empresas que inicien el desarrollo de un Data Warehouse. Esta gua potencia la capacidad de las personas para planificar, de manera consistente, la implementacin del Data Warehouse dentro de la empresa y es dirigida al personal de Tecnologa de Informacin que pertenece a la organizacin en cada una de las etapas del proyecto de Data Warehouse, tomando lo mejor de las metodologas ms utilizadas y adaptndolo a principiantes, pero que puede ser fcilmente retomada por el director del proyecto como referencia de apoyo.
ii
I.
ANTECEDENTES
El trmino Arquitectura de una Organizacin se refiere a la coleccin de
componentes tecnolgicos y sus interrelaciones que integrados nos permiten satisfacer las necesidades de informacin en una compaa. Aqu se introduce el concepto de Arquitectura de Tecnologa de la Informacin de una Organizacin con la intencin de proporcionar un base de referencia sobre la tecnologa de Data Warehousing como uno de muchos componentes de una arquitectura de Tecnologa de la Informacin (IT). El concepto de Data Warehouse se desarrolla basndose en la necesidad de encontrar una estructura ptima para analizar los datos dejando el enfoque tradicional de estructuras orientadas al registro de transacciones; con ello la tecnologa de data Warehousing se establece como un modelo que evoluciona paralelamente al cambio en las necesidades actuales de construir sistemas que faciliten el proceso de toma de decisiones. Segn la definicin de W. H. Inmon, Un Data Warehouse es un conjunto de datos integrados, orientados hacia una materia, que varan con el tiempo y que no son transitorios, los cuales apoyan el proceso de toma de decisiones de una administracin[INMON92]. En otras palabras, un Data Warehouse es el almacenamiento de datos con fines estratgicos de negocio, concepto muy opuesto al objetivo de las bases de datos operativas. La importancia reside en que son fuente de materia prima selecta en los sistemas de soporte para la toma de decisiones. Los profesionales de IT deben asegurar una infraestructura IT que soporte adecuadamente una gran cantidad de requerimientos de los diferentes usuarios de negocios, cada uno de los cuales tiene necesidades constantes y diferentes. Adems, continuamente deben aprender nuevas tecnologas, evaluar nuevas herramientas y mantenerse en contacto permanentemente con sus asociados tecnolgicos. No todas las ltimas tecnologas son tiles, de modo que es necesario escoger de entre el rompecabezas e integrar las distintas piezas para formar un todo coherente. Este problema es resuelto a travs de la construccin de un Data Warehouse. Ante esta situacin los profesionales de IT han desarrollado estrategias y metodologas para la construccin de Data Warehouses segn entorno y propsito de
iii
desempeo especficos. No existe, un punto de vista nico que gue la construccin y adaptacin de un Data Warehouse a los requerimientos de las organizaciones en Nicaragua, debido a que las necesidades de cada una de ellas son diferentes, al igual que su contexto. Sin embargo, es posible establecer un marco de referencia unificado que brinde, a cada participante novel de un proyecto de Data Warehouse, el apoyo necesario para su definicin y desarrollo.
iv
II.
OBJETIVOS
A.
General:
Disear una gua metodolgica para que apoye la definicin y muestre el desarrollo de un Data Warehouse, mediante la elaboracin de un estudio para adaptar los enfoques y estrategias de construccin de las metodologas ms utilizadas hasta el ao 2001, a Tecnlogos de la Informacin noveles en Data Warehousing.
B.
Especficos:
i. Proponer una estrategia para la planificacin, definicin y desarrollo de un Data Warehouse, a travs de un anlisis cualitativo de las metodologas ms utilizadas, para lograr un mtodo base que sea fcil, entendible, prctico y adaptado a noveles en Data Warehousing. ii. Precisar la viabilidad de la puesta en prctica de la gua, a travs de la realizacin de un anlisis de Costo-Beneficio, para la factibilidad de construccin de un Data Warehouse utilizando la gua metodolgica propuesta. iii. Esbozar una propuesta de diseo de Data Warehouse, que utilice los criterios formulados en esta gua metodolgica dentro de una institucin financiera, a travs del uso de Modelado Dimensional de datos, para comprobar la funcionalidad de la gua.
Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse
DESARROLLO DE LA TESIS
I. A. MARCO TERICO El Data Warehouse La concepcin generalizada que se tiene acerca de lo que es un Data Warehouse, implica algn tipo de Base de Datos que proporciona varias funciones a varios usuarios, proviene ms bien de la implementacin del Data Warehouse que de su definicin conceptual. La divergencia de criterios sobre una el concepto en s se cimienta en el hecho de que no exista una definicin oficial de Data Warehouse, esto es, una definicin estndar soportada por un comit de estndares. A pesar de esto, las caractersticas del entorno analtico que supone ser el Data Warehouse son ampliamente reconocidas y aceptadas. Ambos, definicin y caractersticas a continuacin.
1.
Definicin Data Warehouse es un anglicismo que, como muchas de las expresiones que
predominan en el mundo de la Tecnologa de Informacin, no tiene traduccin exacta al castellano, la mejor aproximacin que se puede hacer sera llamarle Almacn de Datos. No obstante, si el Data Warehouse fuese exclusivamente un almacn de datos, los datos encontrados dentro de l no serviran para brindar soporte a la toma de decisiones dentro de una organizacin. Al verificar fuentes bibliogrficas se observa que diferentes libros y artculos atribuyen a diferentes autores el origen de la definicin de Data Warehouse, sin embargo las tendencias que ms predominan (las referencias ms utilizadas) indican principalmente dos fuentes distintas. Una de estas fuentes seala a Barry Devlin y Paul Murphy, quienes en 1988 escribieron "An Architecture for a Business and Information System"[Devlin88] que fue publicado en el IBM Systems Journal, y el cual es uno de los primeros artculos que describe la arquitectura de un Data Warehouse, que fue desarrollado entre 1985 y 1986 para uso interno de IBM Europa en Dubln. Ellos hicieron uso del trmino Information Warehouse para referirse al proyecto, dicha expresin en la actualidad es ampliamente usada para referirse a un Data Warehouse.
Posteriormente [Devlin97,p20] defini que Data Warehouse es un nico, completo y consistente almacn de datos obtenido de una variedad de fuentes y puesto a la disposicin de los usuarios finales de manera que ellos puedan entender y usar en el contexto del negocio. Sin embargo, la definicin ms difundida y aceptada de un Data Warehouse pertenece a William H. Inmon quien fue el primero en acuar el trmino. Un Data Warehouse es un conjunto de datos orientados hacia una materia, integrados, no transitorios y que varan con el tiempo, los cuales apoyan el proceso de toma de decisiones de una administracin [Inmon96, p33] Inmon es considerado el padre del Data Warehouse y a escrito una serie de libros junto a otros colaboradores donde abordan ampliamente los diferentes tpicos y niveles de la arquitectura Data Warehouse. Otros autores como Rob Mattison en [Mattison96] quien identifica cuatro caractersticas de un Data Warehouse estar organizado como un rea de almacn de datos neutral, es usado para data-mining y otras aplicaciones, llena un conjunto especfico de requerimientos de negocio y es usado para satisfacer un conjunto predefinido de criterios de negocio en su fondo coinciden plenamente con lo expresado por Inmon, en su ya clsica y comnmente usada definicin. La tecnologa de Data Warehouse, define en s misma un nuevo entorno de trabajo en el que hay profusin de nuevos trminos, los cuales hacen referencia a los conceptos que sirven de fundamento al Data Warehouse, por ello es sumamente necesario tener en claro el significado de cada uno de ellos, para poder desenvolverse con soltura y propiedad en el ambiente de los Data Warehouse.
2.
Caractersticas del Data Warehouse Al analizar un poco cada trmino utilizado en la definicin de Data Warehouse
de Inmon, nos indican claramente que un Data Warehouse se caracteriza por ser: Integrado: los datos almacenados en el Data Warehouse deben integrarse en una estructura que elimine las inconsistencias existentes entre los diversos sistemas operacionales, que sirven de fuentes de datos. La informacin suele estructurarse
tambin en distintos niveles de detalle para adecuarse a las distintas necesidades de los usuarios. Temtico: slo los datos necesarios para generar informacin del negocio se integran desde el entorno operacional. Los datos se organizan por temas, no por aplicacin, as se facilita el acceso y entendimiento por parte de los usuarios finales a los datos contenidos en el Data Warehouse. Esta caracterstica permite realizar anlisis y minera de datos (data mining). Histrico: el tiempo es parte implcita de la informacin contenida en un Data Warehouse. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente. Por el contrario, el Data Warehouse se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones y anlisis de tendencias, entre otras cosas. No voltil: el Data Warehouse se construye para ser ledo, y no modificado. La informacin que existe en un Data Warehouse es permanente, su actualizacin consiste en la incorporacin de los ltimos valores que tomaron las distintas variables contenidas en l sin alteracin a los datos que ya existan. Adems se puede agregar que un Data Warehouse tiene otras caractersticas, quiz menos trascendentales, pero que lo diferencian de otras tecnologas: Contiene datos diversos: es un repositorio unificado de informacin. Los datos de toda la organizacin aunque pertenezcan a aplicaciones dismiles son integrados en el Data Warehouse Optimizado para la consulta masiva: el diseo fsico tiene un objetivo distinto al de las bases de datos transaccionales, mejorar los tiempos de respuesta de consultas masivas de informacin, sin perder de vista la orientacin temtica y la facilidad de entendimiento que se debe brindar al usuario final La interfaz de usuario esta dirigida a los ejecutivos: las aplicaciones que se construyen sobre un Data Warehouse y que sirven para acceder a su informacin, en su mayora sern utilizadas por analistas de decisiones y altos ejecutivos que descubran las bondades del Data Warehouse, por lo que deben ser amigables e intuitivas. Gran volumen: Cuando se habla de Data Warehouse el espacio de almacenamiento se mide en Gigabytes y Terabytes, como consecuencia de la informacin sumarizada el Data Warehouse admite redundancia y de el largo tiempo de vida de la informacin usualmente entre 5 y 10 aos.
Todo lo expuesto presenta las caractersticas sobresalientes del nuevo entorno analtico-informtico que nace producto de la incorporacin de la tecnologa de Data Warehousing en una organizacin y que lo distingue del entorno operativo los sistemas transaccionales. Tambin se puede caracterizar un Data Warehouse haciendo un contraste de cmo los datos de un negocio almacenados en un Data Warehouse, difieren de los datos operacionales usados por las aplicaciones de produccin. [INEI97] La siguiente figura muestra las diferencias fundamentales entre el ambiente operacional y el Data Warehouse que se han discutido en esta seccin.
Ilustracin I-1 Diferencias entre Sistemas Operacionales y Data Warehouse
Estas diferencias representan un cambio radical en cuanto el enfoque que se le da a los sistemas de informacin y al rol que desempea el equipo de tecnologa de la informacin dentro de una organizacin. Ellas se encuentran resumidas en la tabla IV-1 Las ventajas que presenta la existencia de un Data Warehouse no pueden ser conocidas a priori (en avance), es decir antes de tener lista la primera etapa de implementacin porque un Data Warehouse es usado en una forma completamente distinta a otros datos y sistemas construidos por los sistemas de informacin. Esto hace que no sea posible aplicar anlisis del tipo Retorno a la Inversin (ROI) para justificar la inversin en un Data Warehouse. [Inmon96, p67]
Tabla I-1.- Diferencias entre Data Warehouse y las Bases de Datos Estndar
Base de Datos Estndar En su mayor parte son actualizaciones Muchas transacciones pequeas Mb Gb de Datos Snapshots Actuales Datos Crudos Los usuarios son oficinistas Data Warehouse En su mayor parte son lecturas Las consultas son largas y complejas Gb Tb de datos Historia Datos sumarizados y consolidados Tomadores de decisiones, los usuarios son analistas
Por sobre todo, las bondades del Data Warehouse no son cuantificables de manera cuantitativa sino cualitativa -Cunto vale una buena decisin, oportuna y a tiempo?- Los beneficios que brinda un Data Warehouse derivan directamente de los nuevos usos de la la informacin existente o de la disponibilidad de informacin que difiere en sustancia, calidad o detalle de la informacin que se tienen disponible y se usa en ese momento. Es a partir de esa informacin que las ventajas competitivas fluyen [Porter85]. Otras ventajas ms tangibles son: Alto desempeo de las consultas, el diseo del Data Warehouse lo permite. La informacin se encuentra disponible todo el tiempo, aun si los sistemas fuentes no lo estn. El procesamiento local en los sistemas fuentes no se afecta, todos los anlisis necesarios para soporte a la toma de decisiones se trasladan hacia el Data Warehouse y este se actualiza cuando los sistemas operacionales estn fuera de lnea, sin ocasionar interrupciones innecesarias. Informacin extra en el Data Warehouse. Mucha informacin ya se calcul en avance, existen muchos datos que ya se encuentran sumarizados. La informacin que ms se necesita ya est lista cuando se requiere. Consultas slo del mbito del Data Warehouse. En el Data Warehouse se puede realizar consultas que fuera de l seria imposible de conseguir, por restricciones de recursos y tiempo.
B.
Metodologas ms utilizadas para construir un Data Warehouse Cualquiera que construya un Data Warehouse necesita consultar referencias
adicionales de una mayor profundidad. Yo sugiero la lectura de Building the Data Warehouse de Bill Inmon, The Data Warehouse Toolkit de Ralph Kimball y Data Warehouse: From Architecture to Implementation de Barry Devlin [Porter02]. As se expresa, acerca de quienes son los principales exponentes de las metodologas Data Warehouse , John Porter quien es el Administrador de Datos y Patrocinador del proyecto de Data Warehouse de la Universidad del Estado de Arizona, uno de los primeros Data Warehouse empresariales en la Educacin Superior. La mayora de los expertos coinciden con Porter en que es conveniente para todo individuo que se inicia en el estudio de Data Warehousing, iniciarse en esta tecnologa con el conocimiento que proporciona el enfoque de Bill Inmon, continuar con las instrucciones y herramientas de Ralph Kimball e incluir tambin las enseanzas de Barry Devlin. Bill Inmon fue el primero en definir y defender el concepto de Data Warehouse, por lo cual se le conoce como el padre del Data Warehouse, adems de proponer estructuras como el ODS o la Fbrica de Informacin Corporativa (Corporate Information Factory) y de una estrategia corporativa para la construccin de Data Warehouses. Ralph Kimball, por su lado merecidamente puede ser llamado con el ttulo de padre de la Inteligencia de Negocio (Business Intelligence), pues l ha codificado el esquema estrella y las estructuras de datos llamadas copo de nieve, ha definido los conceptos de Data Mart, jerarquas de dimensiones, mtricas base y agrupadas, drilling, entre otras y en corto plazo ha desarrollado la ciencia detrs de las modernas herramientas de reportes analticos. Ambos han hecho inmensurables contribuciones al campo del Data Warehousing. [Lee02]. Barry Devlin, fue pionero al proclamar la construccin de sistemas inteligentes para soporte a la toma de decisiones, de una forma ms orientada al anlisis, a los que denomin Information Warehouse, y que en realidad es un Data Warehouse, esto ocurri desde los aos ochenta, an cuando su libro fuera publicado hasta en 1997, varios aos despus de lo libros de Inmon y Kimball, Devlin sigue siendo un innovador en sus enseanzas. Un enfoque exitoso de Data Warehousing debe contemplar mucho ms que el proceso de diseo. Las situaciones envuelven la arquitectura de datos del Data Warehouse, la cultura organizacional, los roles y responsabilidades cambiantes, la calidad de datos, integracin de datos y dems, por lo que es imperativo reconocer que no existe un nico mtodo aplicable a toda empresa u organizacin pues cada una es nica, si no ms bien
conocer y comprender cuales son las filosofas y metodologas ms exitosas para utilizarlas y obtener mayores beneficios, en lugar de enfocarse en una sola y disminuir la perspectiva. A continuacin se abordan ligeramente ests tres metodologas ya mencionadas.
1.
Las Enseanzas de Barry Devlin Barry Devlin es uno de los gurs del Data Warehouse. l plantea en su libro
[Devlin97] una metodologa para la construccin de un Data Warehouse que se propone satisfacer la necesidad de un enfoque generalizado e implementacin racional que necesitan las empresas en la actualidad. Su propuesta es una metodologa que trata de cubrir por entero todo el proceso de implementacin, en ella resaltan los elementos que se discutirn luego. Sin embargo, su metodologa no est claramente definida paso a paso como lo hace W. Inmon o Ralph Kimball. Devlin en cambio parte de una base de conceptos que se abordan a continuacin: Arquitectura de datos conceptual en tres capas Un atributo importante de la metodologa de Devlin es la exposicin de tres distintas arquitecturas de datos para los datos en el Data Warehouse, cada una con una, dos y tres capas respectivamente. Devlin concluye que la opcin ganadora, para la mayora de los proyectos, es la Arquitectura de datos conceptual en tres capas[Devlin97, p63], sin embargo acepta que la arquitectura de dos capas es muy difundida, ya que se adapta particularmente bien a los ambientes computacionales bastante homogneos que tienen un nmero relativamente pequeo de plataformas de hardware y software y a aquellos que utilizan el enfoque de Data Marts, propuesto por diversos autores, para la construccin del Data Warehouse. 1. Arquitectura de una capa: Cada elemento de dato se almacena una sola vez, por lo que todos los datos se gestionan como si fueran de tiempo real, incluso los datos derivados.
2. Arquitectura de dos capas: La capa ms baja es utilizada por los sistemas operacionales, son datos en tiempo real. La capa superior es utilizada por los sistemas informacionales, son datos derivados [Devlin97, p67]. 3. Arquitectura de tres capas: La primera capa es la de datos reales y la segunda capa de la arquitectura anterior se subdivide en dos: la capa de datos reconciliados y la de datos derivados. En este punto la capa de datos reconciliados es una base de datos normalizada que constituye la realizacin fsica del modelo de datos corporativo [Devlin97, p70]. Esta arquitectura es recomendada en todas las situaciones donde los negocios requieren una vista empresarial de los datos. En esta arquitectura Devlin denomina Business Data Warehouse (BDW) a la segunda capa y utiliza el trmino Business Information Warehouse (BIW) para referirse a la capa de datos derivados.
Ilustracin I-2. Arquitectura de tres capas
Replicacin de Datos Devlin la define como un conjunto de tcnicas que proveen soporte, de una forma comprensiva, para copiar y transformar los datos de la localidad fuente hacia la destino de una manera consistente, repetible y bien entendida, y que consta de los siguientes tres componentes de ejecucin claves: Captura: es un componente de la replicacin de datos que interacta con una fuente de datos almacenados para obtener una copia de algunos o todos los datos, o un registro de los cambios que han ocurrido en el almacn.
Transformacin: es el componente que convierte datos entre diferentes estructuras lgicas o fsicas de acuerdo a reglas predefinidas. Este componente acepta los datos en el formato de la fuente desde el componente de captura y lo cambia al formato que el componente de aplicacin utilizar en el destino.
Aplicacin: es un componente que aplica los datos capturados y transformados al almacn destino de los datos.
1.1.
Creacin del Activo de Datos Este primer apartado se refiere a utilizar los datos existentes para crear un
activo del activo de datos para la organizacin- un activo que debe ser administrado y protegido, razn por la cual existe el BDW. En la concepcin de Devlin el BDW es rigurosamente definido y en mayor parte centralizado que el BIW. Existen dos etapas que deben ser tomadas en consideracin: Diseo del BDW Segn el enfoque de Devlin, el BDW debe ser diseado con considerable cuidado, debido a que es un componente central del Data Warehouse. La etapa de diseo puede adems subdividirse en las siguientes partes: I. Modelado del BDW: este proceso consta de dos grandes iteraciones. A. Definicin del alcance del modelo entidad relacin: reducir el modelo entidad relacin de la organizacin a solamente aquellos aspectos que se aplican a los sistema informacionales. Se debe enfatizar en los aspectos relacionados con el tiempo, los cuales permiten el mantenimiento de datos peridicos. B. Diseo fsico del BDW: En esta segunda etapa existen tres reas de particular inters. 1. Mapeo hacia los sistemas operacionales: Establece una correspondencia entre los sistemas fuentes de datos y el BDW y resuelve los problemas de inexistencia de modelos de datos en los sistemas operacionales. 2. Restricciones de fuentes de datos: Se refiere a la disponibilidad fsica de los datos en los sistemas fuente, algunos datos ya no se encuentran disponibles u otros deberan estar unificados pero no existen elementos que permitan relacionarlos.
10
3. Restricciones de desempeo: Se refiere a la discordia entre desempeo y volmenes de datos, ambos factores son influenciados por el hecho que la poblacin del Data Warehouse opera en fuentes de datos fijas y con significativas restricciones operativas; y porque la poblacin del Data Warehouse en s misma tienen restricciones operativas similares. II. Estructura de Datos Peridicos: cada instancia de una entidad del negocio, es representada por un conjunto de registros, cada uno de los cuales tiene la misma clave pero que se diferencian por las marcas de tiempo utilizadas como parte de la llave. Se debe crear una lnea gua de entre los diferentes esquemas de marca de tiempo para maximizar la eficiencia de las mismas. III. Archivo y recuperacin: este proceso debe disear una funcin que pueda proveer almacenamiento manejable y eficiente y recuperacin de datos entre los diferentes niveles en la jerarqua de almacenaje. Poblacin del BDW La poblacin del BDW ha sido considerada una de las partes tcnicamente ms demandantes de la construccin del Data Warehouse, lo que hace necesario disear un proceso de obtencin de datos que permita que los datos fluyan sin problemas y de forma confiable desde los sistemas operacionales a el BDW. I. Captura- de datos desde los sistemas operacionales. Se debe definir la captura para la carga del BDW tomando en cuenta los requerimientos del sistema en cuanto a desempeo y la necesidad de transformar datos transitorios o semi- peridicos a datos peridicos. II. Transformacin- de datos entre los dos ambientes. Existen una serie de funciones de transformacin de las que deben seleccionarse las que ms satisfagan las necesidades del negocio con el objetivo de normalizar y alinear los datos entrantes al Modelo de Datos de la Organizacin. III. Aplicacin- Existen 4 modos de aplicacin de datos y debido a sus caractersticas unos u otros pueden ser usados en la creacin del BDW o en su mantenimiento, ambas situaciones requieren diferentes modos de aplicacin de los datos. 1.2. Liberacin del activo de datos para el usuario final En este apartado Devlin describe como el Warehouse soporta al usuario final, brindndole informacin en lugar de datos y como la empresa alcanzar beneficios a travs
11
del uso del Business Information Warehouses (BIWS). Los desarrolladores necesitan estructurar los BIW para permitir el acceso de los usuarios tan lejos como sea posible pues en su vasta mayora dicho acceso de parte de los usuarios ocurrir en este nivel [Devlin97, p245]. Diseo de BIW El diseo de BIW debe proveer un buen desempeo sobre un rango de las formas ms probables en que los usuarios utilizarn los datos en el BIW, puesto que el comportamiento de los usuarios es impredecible y no se puede conocer en avance. En general, los BIW son sustancialmente denormalizados en relacin al BDW, esto con el objetivo de incrementar el desempeo de las consultas y para reducir la complejidad de los datos desde el punto de vista de los usuarios [Devlin97, p231]. El diseo de BIWS tiene mucho en comn con el diseo del BDW en cuanto a las partes en las que se divide, pero se diferencia en los enfoques con que se aborda algunas partes: I. Modelado de BIW: la justificacin para modelar BIW proviene de la audiencia del mismo, si sta es pequea el modelado no es apropiado pues no se justifica el esfuerzo, si por otro lado el BIW servir a todo un departamento o sern datos de uso pblico el modelado de datos es vital para asegurar la consistencia de uso y entendimiento de los datos. II. Datos Histricos en el BIW: conjuntos de datos histricos deben ser generados segn se requiera para necesidades analticas especficas y retenidos slo por los perodos de tiempo requeridos. III. Archivo y Recuperacin: consideraciones similares al diseo de BDW. Poblacin de BIW Como en la poblacin del BDW, la funcin genrica usada para poblar los BIW es la replicacin de datos en sus tres pasos previamente identificados [Devlin97, p247]: I. Captura- de datos desde el BDW. Los BIW en su mayora utilizan datos provenientes de ms de una tabla del BDW, por lo que es necesaria la sincrona entre dichas tablas del antes de comenzar con la poblacin del BDW. II. Transformacin- de datos entre los dos ambientes. Se limita a aquellas funciones que utilizan primordialmente el estndar SQL para realizar las transformaciones entre las
12
que se destacan: agregacin y enriquecimiento, las cuales envuelven clculos sobre los datos. III. Aplicacin- Cualquiera de los cuatro modos de aplicacin de datos pueden utilizarse, en dependencia de las circunstancias. En el BIW co-existen snapshots y datos peridicos los cuales deben ser tratados de forma distinta por el componente de aplicacin. Acceso del Usuario a la Informacin Cualquier aplicacin que permita al usuario acceder y manipular los datos del negocio en el Data Warehouse contiene elementos de una Interfaz de Informacin del Negocio (Business Information Interface - BII). La BII provee las funciones necesarias para seleccionar los datos, realizar anlisis, guardar los resultados y producir reportes en cualquier formato requerido. Este proceso finalmente transforma los datos en informacin [Devlin97, p261]. La estructura del BII debe ser como sigue:
Ilustracin I-3. Estructura BII.
Slo a travs de este proceso y de las aplicaciones construidas alrededor del BII, el negocio obtiene valor real a partir de la inversin en un Data Warehouse. El BII debe soportar consultas, manipulacin y reporte de datos y tambin proveer los medios para guardar y re-usar los resultados, tanto a nivel personal o departamental de la organizacin [Devlin97, p274].
13
Informacin - Datos en Contexto Los Metadatos brindan soporte al usuario final para encontrar datos relevantes y entender el significado de los mismos, por lo tanto el acceso y uso de los metadatos depende en gran parte de la funcionalidad y estructura que estos presenten, lo que convierte la poblacin de metadatos en la mayor dificultad que se les asocia [Devlin97, p275]. El componente de Metadatos se complementa con el BII para lograr liberar el activo de datos a los usuarios finales que estarn en capacidad de percibir y por tanto obtener valores de los datos. Estos componentes proveen el enlace entre los datos fundamentales almacenados y administrados en el Warehouse y la informacin requerida por el usuario final, juntos transforman los datos en informacin. La estructura del componente de Metadatos, denominado BIG (Business Information Guide), es muy anloga a la del BII, incluso se puede decir que el BIG es una forma muy especializada del BII, optimizada para el uso con Metadatos [Devlin97, p296]. La estructura es como sigue:
Ilustracin I-4. Estructura BIG
14
1.3.
Implementacin del Data Warehouse Este apartado incluye la informacin que permite estructurar de forma integral
el Data Warehouse. Obstculos a la Implementacin Aborda los problemas de las reas claves y su posible resolucin: Tamao y alcance del Data Warehouse Segn [Devlin97, p304] un verdadero Data Warehouse envuelve a la empresa por completo, esto implica que el tamao del Data Warehouse es enorme. Con el objetivo de evitar desastres potenciales en la implementacin que puedan poner en peligro la realizacin del proyecto Devlin plantea dividir la implementacin completa en piezas alcanzables que puedan ser implementadas en un proceso de etapas. El resultado es un proceso que se expande a varios aos pero que entrega valor al negocio en ciclos de seis o doce meses, en paralelo con una implementacin progresiva y en etapas de la arquitectura del Data Warehouse. Colocacin del BDW y BIW en la empresa Esta etapa se refiere a la arquitectura fsica del Data Warehouse y se deben considerar aspectos de la estructura organizacional, geogrfica y de las plataformas fsicas usadas por la compaa, decidir si implementar de forma centralizada o distribuida. Esta etapa es altamente dependiente del ambiente de la empresa porque no existe una nica forma de implementacin. Planeacin de la Implementacin El aspecto ms importante de la planeacin de la implementacin es que este proceso debe armonizar juntos valor para el negocio y la infraestructura de entrega. El resultado es una serie de proyectos cada uno entregando valor al negocio e infraestructura de una manera controlada y en etapas. La prioridad de la secuencia de entregas en este proceso es determinada por una combinacin de las necesidades del negocio y de aspectos tcnicos, siendo la influencia ms importante el modelo de datos de la empresa [Devlin97, p333].
15
Para segmentar el Data Warehouse se debe seguir los siguientes pasos. 1. Definir el modelo de alto nivel de la empresa: este paso se realiza una sola vez. 2. Modelar un subconjunto del BDW: definir la estructura y las relaciones de las aplicaciones operacionales que son fuente de datos, este es el paso ms complejo. 3. Modelar el primer BIW: definir su estructura y sus relaciones con el BDW. Se debe planear una implementacin en etapas que entreguen la infraestructura requerida para asegurar el mximo re-uso de cdigo y esfuerzos realizados previamente y una asociacin cercana con las aplicaciones informacionales especficas priorizadas. Cada etapa combina tareas relacionadas con la infraestructura genrica y las aplicaciones especificas del negocio, stas son sus tres mayores componentes [Devlin97, 312]: 1. Desarrollo de la infraestructura: las reas de infraestructura que normalmente se presentan son: implementacin del DBMS, poblacin del BDW y del BIW, creacin del BIG y componentes de administracin. 2. Modelado Empresarial: Pasar del modelado lgico al nivel fsico de una rea definida del negocio. 3. Aplicacin del Negocio: La parte del trabajo que debe ser hecha para soportar los requerimientos de negocios especficos de los usuarios, incluye: obtencin de requerimientos para el uso de informacin, modelado del BIW a nivel lgico y fsico, documentacin de los trminos del negocio, definiciones de datos y dems, para la captura y uso del catlogo del Data Warehouse . Todo proceso de implementacin de un Data Warehouse debe iniciar con un proyecto piloto diseado para probar la viabilidad de todo el enfoque. Estructura Fsica del Data Warehouse El diseo lgico de la arquitectura de datos de tres capas lleva a un conjunto de opciones muy flexibles y poderosas para el diseo fsico del Data Warehouse. Estas opciones van desde una decisin basada en una implementacin centralizada hasta a un enfoque completamente distribuido basado en una mezcla de plataformas de distinto tamao [Devlin97, p378]. Hay dos formas de dividir el BDW en subconjuntos:
16
Segmentacin del BDW: Segmentar el BDW en conjuntos de tablas relacionadas muy estrechamente, donde cada conjunto corresponde a reas del modelo de datos que muestra muchas relaciones internas pero pocas externas. Particin del BDW: el cual puede ser dentro del segmento consiste en particionar los datos en el segmento de acuerdo a conjuntos de valores de datos para que reflejen distintas reas del negocio o de desempeo segn el nivel que ocupen. Al considerar el modelado de datos, los requerimientos de uso de los datos y sus restricciones y el trfico en la red, los diseadores del Warehouse pueden determinar una ptima distribucin fsica. Administracin del Data Warehouse De los componentes de administracin del Data Warehouse, es importante prestar atencin especial al componente de administracin de replicacin, utilizado para definir como opera la funcin de replicacin de datos, mantiene los metadatos- fuente, destino y mapeo de funciones requeridos para la replicacin. Tambin hay dos componentes ms que son utilizados para soportar las principales actividades de crear mantener y utilizar el Data Warehouse: Administracin de procesos: coordina las funciones que operan entre ambientes y cuyas acciones deben ocurrir en una secuencia particular. Transferencia de Datos: es responsable del movimiento de datos a todos los niveles de granularidad, desde un registro solo a un archivo completo, entre sistemas fsicamente separados.
2.
El enfoque de W. H. Inmon William H. Inmon es considerado el padre del Data Warehouse, pues fue el
primero en acuar el trmino, adems su libro con el cual dio a conocer su teora sobre el Data Warehouse, es hoy en da, una dcada despus de su primera publicacin, una de las referencias ms completas y utilizadas por los profesionales que ingresan al mundo de la tecnologa del Data Warehouse. l ha a escrito ms de 32 libros solo o en compaa, con lo que ha consolidado una serie de obras que abarcan cada aspecto del diseo, construccin y gestin de un Data Warehouse.
17
Inmon presenta dos descripciones del camino a seguir para la construccin de un Data Warehouse. Un plan de migracin y una metodologa. Segn describe el propio William Inmon en [Inmon96, p288] la metodologa que l propone difiere del plan de migracin en varias maneras. El plan de migracin describe actividades generales dinmicamente. La metodologa describe actividades especficas, los resultados de esas actividades y el orden de las actividades, pero las dinmicas iterativas de crear un Data Warehouse no son descritas. En otras palabras el plan de migracin describe un plan impreciso en tres dimensiones, mientras la metodologa describe un plan detallado en una dimensin. Juntos ellos forman un retrato completo de lo que se requiere para construir el Data Warehouse. 2.1. Data-Driven Development Methodology Uno de los aspectos sobresalientes de la metodologa dirigida por los datos es que ella construye sobre esfuerzos previos- construye sobre ambos cdigo y procesos que han sido desarrollados con anterioridad. La nica forma en que el desarrollo sobre esfuerzos previos puede ser alcanzado es a travs del reconocimiento de aspectos comunes. Antes que el desarrollador inicie su trabajo, l o ella necesita saber que es lo que realmente existe y como eso afecta el proceso de desarrollo. Esta es una de las esencias de la metodologa dirigida por los datos. Una metodologa dirigida por los datos tiene cuando menos dos caractersticas distintivas [Inmon96, p290]: 1. Se enfoca en utilizar el cdigo y los datos que han sido elaborados previamente como base para la nueva construccin en lugar de construir alrededor de ellos. Para realizar esto, es imperativo el reconocimiento de aspectos comunes en los datos y el procesamiento, la clave para este reconocimiento es el modelo de datos. 2. Hay un nfasis en el almacn central de datos El Data Warehouse- como la base para el procesamiento de soporte a la toma de decisiones, lo que reconoce que el procesamiento de soporte a la toma de decisiones tiene un ciclo de vida de desarrollo sumamente diferente a los sistemas operacionales. El desarrollo de sistemas operacionales se forma alrededor de un ciclo de vida de desarrollo que inicia con los requerimientos y termina con el cdigo, lo que se diferencia grandemente del procesamiento de soporte a la toma de decisiones, el cual inicia con los datos y termina con los requerimientos.
18
La metodologa propuesta por Inmon expone los resultados que se deben obtener y describe el orden en que las cosas deben ser hechas. Cmo son alcanzados los resultados requeridos se deja enteramente al criterio del desarrollador. La metodologa la dividi en tres partes componentes, incluye las actividades clsicas del desarrollo de sistemas operacionales para que sea una metodologa dirigida por los datos [Inmon96, p288]. A continuacin la esencia de la metodologa propuesta por Inmon en [Inmon96, p317], Apndice: METH-1: Desarrollo de Sistemas Operacionales M1. Actividades Iniciales del Proyecto: Obtencin de los requerimientos preliminares del sistema a travs de Entrevistas, recopilacin de datos, Diseo de Aplicaciones Conjuntas (JAD), anlisis del plan estratgico de negocios, requerimientos de parte de los sistemas existentes para los nuevos sistemas. M2. Uso de cdigo y datos existentes: Usar cuanto cdigo y datos sean posibles y preparar para futuros proyectos que usaran cdigo y datos desarrollados en el proyecto actual. M3. Determinacin de tamao y fases: Luego de la obtencin de los requerimientos generales se deben de determinar su tamao y dividir el desarrollo del proyecto en fases que funcionen como unidades pequeas y manejables. M4. Formalizacin de los requerimientos: asegurar que los requerimientos sean completos, organizados, lebles, comprensibles y a un nivel de detallen que permita ser efectivos, que no sean discordantes o se traslapen. Se debe separar los requerimientos operacionales de los de soporte a la toma de decisiones. Modelado de Datos D1. Diagrama Entidad Relacin: De la especificacin formal de los requerimientos resulta la necesidad de identificar las reas de mayor inters que constituirn el sistema y las relaciones y cardinalidad entre ellas. D2. Conjunto de Elementos de Datos: Cada tema es dividido (en trminos de nivel de detalle) en conjunto de elementos de datos (CED). Los CED contiene los atributos
19
de los datos, agrupamiento de los atributos, llaves, tipos de datos, conectores y agrupamiento secundario de los datos. Solo los datos primitivos se manejan aqu. D3. Anlisis de Desempeo: Se resuelve el asunto de la denormalizacin fsica de los datos que permita un ingreso y actualizacin eficientes, para el caso de grandes cantidades de datos o de procesamiento. D4. Diseo fsico de la Base de Datos: Obtencin de las tablas y bases de datos diseadas fsicamente, luego de transformar todas las consideraciones lgicas de diseo de datos, desempeo, actualizacin, ingreso, disponibilidad, etc. Especificaciones de Proceso P1. Descomposicin Funcional: Resulta de tomar todas las funciones amplias a ser alcanzadas por el sistema y dividirlas en una serie de funciones pequeas sucesivas. Es la descripcin de todas las actividades a ser realizadas durante el desarrollo desde un nivel alto hasta un nivel bajo. P2. Nivel de Contexto 0. Corresponde a D1, Diagrama Entidad-Relacin, en la especificacin de proceso. P3. Nivel de Contexto 1-n: Los niveles restantes de la descomposicin funcional describen ms detalladamente las actividades que ocurren, de manera ordenada, organizada, completa y en concordancia con el flujo de actividades. P4. Diagramas de Flujo de Datos (DFD): Existe un DFD para cada nivel de contexto n, indica la entrada de un proceso, la salida del proceso, el almacenamiento de datos necesario para establecer el proceso y una breve descripcin del proceso. P5. Especificaciones Algortmicas, Anlisis de Desempeo: Es el bosquejo del procesamiento actual paso por paso. Los procesos de cada DFD se dividen en especificaciones algortmicas detalladas, tomando en cuenta los aspectos de desempeo que deben ser resueltos en el diseo de los programas. P6. Pseudocdigo: Los algoritmos y especificaciones de programas se refinan en pseudocdigo, el cual debe incluir completitud, orden de ejecucin, todos los casos requeridos, todas las contingencias (manejo de errores, condiciones de excepcin), estructura de la codificacin. Corresponde a D4 en modelado de datos. P7. Codificacin: Construccin del cdigo fuente. La traduccin completa y eficiente de pseudocdigo en cdigo, incluyendo la documentacin en cdigo. P8. Caminata: Explicacin verbal del cdigo a los colegas, para encontrar y corregir la mayor cantidad posible de errores antes de las pruebas.
20
P9. Compilacin: El cdigo fuente es compilado y se corrigen todos los errores encontrados. P10. Pruebas unitarias: Pruebas del cdigo a diferentes niveles. P11. Implementacin: Esta etapa incluye en s muchas actividades como: Descarga inicial de datos Conversiones de datos Establecimiento de utilidades de monitoreo Escritura de la documentacin Establecimiento de procedimientos de recuperacin y respaldo.
METH-2: Desarrollo Del Data Warehouse Este es el componente de la metodologa que se ocupa del desarrollo de sistemas y procesamiento de soporte a la toma de decisiones. DSS1. Anlisis del Modelo de Datos: Confirmacin que el modelo de datos de la organizacin es slido y que contiene la identificacin de los temas de mayor inters, cada tema tiene separada su propia definicin de datos: subtipos de datos, atributos, relaciones claramente definidas, identificacin de llaves entre otros. DSS2. Anlisis Breadbox: Permite la determinacin del tamao estimacin bruta- del entorno de los sistemas de soporte a la toma de decisiones. Simplemente proyecta, en trminos crudos, que cantidad de datos mantendr el Data Warehouse. Con esto es posible determinar si ser necesario considerar mltiples niveles de granularidad. DSS3. Valoracin Tcnica: Contiene definiciones tcnicas que tienen la habilidad de manejar grandes cantidades de datos, permitir que los datos sean ingresados flexiblemente, organizar los datos de acuerdo al modelo de datos, recibir y enviar datos a una amplia variedad de tecnologas, contemplar descargas de datos masivas, acceder conjunto de datos simultneamente o registro por registro. DSS4. Preparacin del entorno tcnico: Instalacin, ubicacin y desarrollo de los componentes tcnicos que recibirn los datos: la red, el almacenamiento secundario, su sistema operativo, la interfaz hacia y desde el Data Warehouse el software administrador del Data Warehouse y el Data Warehouse en s. DSS5. Anlisis de los temas del Data Warehouse: Determinacin del tema que ser el primero en implementarse (poblarse). Debe ser grande lo suficiente para tener sentido y pequeo lo suficiente para permitir una rpida implementacin. DSS6. Diseo del Data Warehouse: Algunas de las caractersticas del diseo incluyen:
21

Acomodacin de los diferentes niveles de granularidad, si existen. Orientacin de los datos a los principales temas de la organizacin. La presencia de solo datos primitivos y datos derivados pblicamente. La ausencia de datos que no apoyan los sistemas de soporte a las decisiones. Variabilidad de tiempo en cada registro de datos. Denormalizacin fsica de los datos donde sea aplicable Adaptacin de los datos del entorno operacional al analtico- Data Warehouse.
DSS7. Anlisis de los Sistemas Fuente: Identificacin del sistema de registro, es decir el mapeo de los datos del ambiente operacional al ambiente analtico. Se deben resolver los siguientes aspectos relacionados a la integracin de los datos: La estructura y resolucin de llaves al pasar al ambiente analtico. Atribuciones: Eleccin de una fuente de datos entre muchas, que hacer cuando no hay fuente de datos, las transformaciones a realizar. Creacin de la variabilidad de tiempo en los registros a partir de datos actuales. Creacin de la estructura analtica a partir de la estructura operacional. Reflejo de las relaciones del entorno operacional en el ambiente analtico.
DSS8. Especificaciones: Formalizacin de la interfaz entre los ambientes operacionales y analticos en trminos de especificaciones de programas, que permitan la extraccin e integracin de los datos lo ms eficiente y simple posible. Verifica que datos operacionales deben ser obtenidos y como guardarlos. DSS9. Programacin: Programas de transformacin que permiten la extraccin, integracin y ubicacin en perspectiva de tiempo de los datos. Incluye todas las actividades estndar de programacin como: elaboracin de pseudocdigo, codificacin, compilacin, pruebas. Esto asegura que el cdigo generado sea eficiente, documentado, con capacidad de cambio rpido, eficaz y completo. DSS10. Poblacin: Ejecucin de los programas desarrollados en las etapas anteriores. Se deben resolver los aspectos de frecuencia de poblacin, reglas de purga, envejecimiento de los datos poblados, administracin de mltiples niveles de granularidad y refrescamiento. Con este paso final se obtiene un Data Warehouse poblado y funcional, accesible y comprensible que sirve las necesidades de la comunidad de los sistemas de soporte a la toma de decisiones.
22
Meth-3: Procesamiento Heurstico Esta componente de la metodologa de lo que Inmon llama entorno arquitectnico describe el uso del Data Warehouse para propsitos de anlisis. DEPT1. Repeticin del Desarrollo Estndar: Para la obtencin de reportes
estndares, el procesamiento analtico repetitivo debe seguir el procesamiento normal descrito en METH-1, exceptuando el modelado de datos, porque la fuente de datos es el Data Warehouse. IND1. Determinacin de los datos necesarios: Seleccin de datos para anlisis posteriores y uso potencial en la satisfaccin de los requerimientos de reportes. IND2. Programas para extraer datos: Escritura de un programa para acceder y recuperar los datos seleccionados. IND3. Combinar, Fusionar, Analizar: Edicin, combinacin con otros datos y refinamiento de los datos obtenidos para que los datos sean utilizables en anlisis. IND4. Anlisis de datos: Revisin de los resultados obtenidos para asegurar que satisfagan las necesidades del analista de datos, si no se inicia el proceso iterativo. IND5. Respuesta a la cuestin: Produccin del reporte final luego del proceso iterativo. IND6. Institucionalizacin: Si existe necesidad de elaborar un reporte de forma repetitiva, entonces se debe convertir ste en un conjunto de requerimientos a ser satisfechos mediante una operacin de ocurrencia regular. Todos los procesos IND ocurren a nivel individual, pues se realizan a travs de procesamiento realmente puros para satisfacer necesidades individuales en la organizacin. Los IND usualmente deben ser hechos varias veces antes de obtener un resultado satisfactorio, por lo que los programas escritos deben tener como caracterstica esencial su fcil modificacin para poder ser ejecutados en numerosas ocasiones.
23
Ilustracin I-5. Metodologa Data Warehouse de Inmon
24
2.2.
Migration Path El punto inicial del plan de migracin es el modelo de datos. El modelo de
datos representa las necesidades de informacin de la organizacin, no necesariamente lo que realmente tiene. El modelo de datos debe identificar cuando menos lo siguiente [Inmon96, p276]: Los temas de inters principales de la organizacin Las relaciones entre estos temas principales El agrupamiento de las llaves y atributos que representen ms plenamente los principales temas incluyendo: Atributos Las llaves Los grupos repetitivos de atributos y llaves Conectores entre las reas de los temas principales Relaciones de subtipos.
Luego que se tiene el modelo de datos en su lugar es necesario definir el sistema de registros, el cual se define en trminos de los sistemas existentes que la organizacin ya tiene. El sistema de registros es la identificacin de la mejor informacin que tiene la organizacin, determinada en funcin del modelo de datos. La determinacin de la mejor fuente existente de datos utiliza los siguientes criterios: Datos ms completos Datos ms oportunos Datos ms precisos Datos ms cercanos a la fuente de entrada Datos ms cercanos a la estructura del modelo de datos en trminos de llaves, de atributos, de agrupamiento de atributos de datos juntos. El siguiente paso es disear el Data Warehouse. Si el modelo de datos est elaborado correctamente el diseo del Data Warehouse slo requiere que pocos aspectos del modelo se cambien para convertirlo en un diseo de Data Warehouse, principalmente se debe:
25

Agregar un elemento de datos a la estructura de llaves, si esta no lo presenta. Eliminar los datos puramente operacionales. Las relaciones de integridad referencial deben ser cambiadas por otras fabricadas Los datos derivados usados frecuentemente deben ser agregados al diseo La estructura de datos debe ser alterada cuando sea apropiado para: Agregar arreglos de datos Agregar datos redundantes Futura separacin de datos en condiciones adecuadas Mezcla de tablas cuando sea apropiado Realizar anlisis de la estabilidad de las necesidades de datos.
Entre las reas de los temas de inters debe haber muchas tablas separadas, cada una de las cuales es conectada por una llave comn. Despus del diseo de datos, el siguiente paso es disear y construir las interfaces entre el sistema de registro y el Data Warehouse, las cuales poblarn el Data Warehouse en periodos de tiempo regulares. Las interfaces realizan una serie de actividades vitales de modificacin de los datos antes de cargar el Data Warehouse: Integracin de los datos Alteracin de las bases de tiempo de los datos Condensacin de los datos Exploracin eficiente del ambiente de los sistemas existentes. La etapa final de este plan de migracin es iniciar la poblacin del Data Warehouse con el primer tema de inters, es importante que solo una fraccin del Data Warehouse sea poblada inicialmente para asegurar que los inevitables cambios que sobrevienen y que deben ser hechos puedan llevarse a cabo de manera fcil y rpida, lo que garantiza la flexibilidad de la primera iteracin del Data Warehouse. Una vez que el usuario final tiene acercamiento a los datos y proporciona retroalimentacin al arquitecto de datos, entonces puede ser sano poblar cantidades mayores de datos. Los procesos de poblacin y retroalimentacin continan indefinidamente, mientras el Data Warehouse contina su proceso evolutivo incorporando cambios producto de stos dos procesos. Sin embargo, no se debe olvidar que las actividades y asuntos del
26
entorno del Data Warehouse son completamente independientes de las actividades y asuntos del entorno de los sistemas operacionales existentes. El ciclo de Retroalimentacin En el corazn del xito en el desarrollo de un Data Warehouse se encuentra el ciclo de retroalimentacin entre el arquitecto de datos y el analista de sistemas de soporte a la toma de decisiones [Inmon96, p283]. El Data Warehouse es poblado desde los sistemas operacionales. El analista de sistemas de soporte a la toma de decisiones usa el Data Warehouse como base para sus anlisis. Al encontrar nuevas oportunidades el analista de sistemas de soporte a la toma de decisiones transmite esos requerimientos al arquitecto de datos, quien realiza los ajustes apropiados. No se debe pasar por alto ninguno de los siguientes aspectos para asegurar una implementacin exitosa del ambiente del Data Warehouse [Inmon96, p284]: 1. El analista de sistemas de soporte a la toma de decisiones actual bajo las bases de obtener lo que desea para luego establecer que es lo que realmente necesita. 2. Cuanto ms corto sea el ciclo de retroalimentacin, ms exitoso ser el esfuerzo de construccin del Data Warehouse. 3. Cuanto ms grande sea el volumen de datos que deba ser cambiado ms largo ser el ciclo de retroalimentacin.
3.
El ciclo de Vida del Data Warehouse de Ralph Kimball. El primer libro de Ralph Kimball que vio luz fue The Data Warehouse Toolkit
[Kimball95], en el cual este autor mostraba como usar el modelado dimensional para disear Data Warehouses usables y efectivos. Sin embargo, la presentacin y explicacin de una metodologa que utilice estas tcnicas para la construccin de completos Data Marts y Data Warehouses aparece hasta en una publicacin posterior The Data Warehouse Lifecycle Toolkit [Kimball98]. La expresin Ciclo de Vida se refiere a todos los pasos del proceso completo de desarrollo de software: planeacin, diseo, codificacin, prueba, implementacin y administracin, el ciclo de vida de Kimball es una metodologa paso a paso para disear, desarrollar y desplegar Data Marts y Data Warehouses, y que es
27
enriquecido adems, por experiencias de otros coautores. Este libro aborda el proceso de construccin de inicio a fin de forma iterativa y tambin se muestra la utilizacin de las tcnicas del modelado dimensional. Este es el ciclo de vida propuesto por Ralph Kimball:
Ilustracin I-6 Ciclo de Vida Dimensional para implementar un Data Warehouse
El enfoque con el cual Kimball aborda el proceso de construccin del Data Warehouse, est plenamente soportado por herramientas que l ha comprobado son efectivas al utilizarse adecuadamente, es mucho ms tcnico en sus descripciones que los autores anteriores, pero logra ejemplificar adecuadamente sus ponencias, para aclarar los diversos puntos. 3.1. Administracin del Proyecto y Requerimientos Kimball, propone una metodologa de principio a fin, por lo cual inicia con planeacin del proyecto y establecimiento de requerimientos, en este sentido no difiere de las herramientas utilizadas en el proceso de construccin de un sistema tradicional, pero se diferencia en los objetivos que se persiguen. Planeacin y Gestin del Proyecto Este es el primer paso que se debe efectuar al iniciar la construccin de un Data Warehouse: definir el proyecto. En esta etapa se debe determinar la preparacin de la
28
organizacin para afrontar dicho proyecto. Tambin se debe elaborar el plan para el proyecto, as como gestionar la puesta en marcha del mismo, definiendo y manteniendo su alcance. Obtencin de Requerimientos Cada organizacin es nica en si misma, cada vez que se inicia un Data Warehouse, es imposible conocer en avance los requerimientos de tal instrumento de apoyo a la toma de decisiones, por tanto se debe de hacer uso de entrevistas o sesiones con facilitador para lograr obtener datos de la informacin necesaria en la empresa para poder definir de manera correcta el contenido y utilizacin del Data Warehouse. 3.2. Diseo de Datos o Modelado Dimensional Este es el corazn de la metodologa de Kimball, l defiende el modelado dimensional con el argumento de que proporciona grandes ventajas en desempeo e inteligibilidad adems de ser siempre aplicable. Aqu se diferencia de los autores ya expuestos pues ellos no se inclinan por ningn tipo de modelado, sino que solo sealan que es imperativo contar con un adecuado modelo a partir del cual fundamentar el Data Warehouse. El Modelado Dimensional, segn su creador Ralph Kimball, es el diseo fsico y lgico que transformar las antiguas fuentes de datos en las estructuras finales del Data Warehouse, a travs de una tcnica que busca la presentacin de los datos en un marco de trabajo estndar que es intuitivo y permite un acceso de alto desempeo. Cada modelo dimensional esta compuesto de una tabla que tiene una llave compuesta llamada tabla de hechos y un conjunto de tablas ms pequeas llamadas dimensiones. Cada tabla dimensin tiene una llave primaria simple, que corresponde exactamente a una de las partes de la llave compuesta en la tabla de hechos. Esta estructura caracterstica es usualmente llamada esquema estrella [Kimball98, p144]. Los pasos necesarios para convertir un Diagrama Entidad-Relacin (ERD) a un conjunto de diagramas de modelado dimensional son [Kimball98, p146]: 1. Separar el ERD de la organizacin en procesos de negocios discretos y modelar cada uno separadamente.
29
2. Seleccionar las relaciones muchos a muchos en el modelo entidad-relacin que contengan cantidades numricas y aditivas que no pertenezcan a la llave y designarlos como tablas de hechos. 3. Denormalizar todas las tablas restantes en tablas planas con llaves simples que conectan directamente a las tablas de hechos. Estas tablas se convierten en las dimensiones. En los casos en los que una tabla dimensin se conecte a ms de una tabla de hechos, se representa esta misma tabla dimensin en ambos esquemas, a estas tablas dimensin se les llama conformadas entre los dos modelos dimensionales. El objetivo de aplicar modelado dimensional a una estructura como el Data Warehouse se deriva de las fortalezas de este mtodo [Kimball98, p148], el cual proporciona: Un marco de trabajo predecible, que se obtiene al utilizar dimensiones conformadas, esto mejora la presentacin y tambin el desempeo, ya que un joint de N-tablas se traduce en una operacin sort-merge sobre las dimensiones que luego se aplican a las tablas de hechos. Soporta cambios inesperados en el comportamiento del usuario. Es fcilmente extensible para acomodar nuevos elementos de datos inesperados y nuevas decisiones de diseo. La Arquitectura de Bus del Data Warehouse Un Data Warehouse est hecho de las unin de muchos de sus Data Marts [Kimball98, p19]. Cada Data Mart debe ser representado por un modelo dimensional y dentro de un nico Data Warehouse, todos estos Data Marts deben ser construidos a partir de dimensiones conformadas y hechos conformados. Esta es la base de la arquitectura de bus del Data Warehouse. La planeacin del Data Warehouse debe iniciarse con un fase pequea de arquitectura de datos que cubra todo y que a la vez tenga metas muy finitas y especficas, luego se debe seguir esta arquitectura con una implementacin paso a paso de Data Marts separados, donde cada implementacin se adhiere a la arquitectura predefinida [Kimball98, p153]. Cada Data Mart para que sea prctico debe ser basado en los datos ms granulares (atmicos) que sea posible colectar y almacenar.
30
Cualquier implementador de Data Warehouse que quiera ser exitoso inevitablemente realiza los siguientes pasos: 1. Crear una arquitectura circundante que defina el alcance e implementacin del Data Warehouse completo. 2. Supervisar la construccin de cada pieza del Data Warehouse completo. Sin una adherencia estricta a las dimensiones conformadas un Data Warehouse no puede funcionar como un todo integrado, ya que a travs de las dimensiones conformadas se logra [Kimball98, p157]: 1. Una tabla dimensin sola puede ser usada contra mltiples tablas de hechos en el mismo espacio de base de datos 2. Las interfaces de usuario y los datos que contienen son consistentes en cualquier instante en que se utilice la dimensin. 3. Existe una interpretacin consistente de los atributos y por ende de los rollups a travs de los Data Marts. Las dimensiones y hechos conformados juegan el rol de un bus en el Data Warehouse. Al definir una interfase estndar de bus para un entorno de Data Warehouse dado, un nuevo Data Mart puede ser introducido en el Data Warehouse de modo que el puede coexistir tilmente con lo que ya se encuentra en su lugar [Kimball98, p164]. Tcnicas de Modelado Dimensional La idea fundamental del modelado dimensional es que casi cada tipo de datos de negocio puede ser representado como un tipo de cubo de datos, donde cada celda del cubo contiene un valor medido y las aristas del cubo definen las dimensiones naturales de los datos [Kimball98, p165]. Los elementos esenciales del modelado dimensional son: Hechos: Un hecho es algo que usualmente no se conocen en avance. Casi cualquier campo con valor numrico es un hecho, aunque algunos pueden ser valores de texto. Un hecho es una observacin del mercado de trabajo. Atributos: Usualmente son campos de texto que describen las caractersticas de algo tangible, como las descripciones de producto. Dimensiones: Los atributos textuales que describen los objetos y que tienen una alta correlacin entre ellos, son organizados dentro de las dimensiones.
31
Mtodo de Diseo de cuatro pasos para disear una tabla de hechos individual El diseo lgico detallado de un esquema dimensional es dirigido por los siguientes cuatro pasos [Kimball98, p 194]: 1. Escoger el Data Mart: En las primera implementaciones es aconsejable mantener la situacin lo ms simple posible por lo que es una adecuada decisin escoger una nica fuente de datos para el Data Mart. 2. Declarar la Granularidad de la tabla de Hechos: Consiste en una clara definicin de que se considera una tabla de hechos en el diseo dimensional propuesto, que estilo de tabla de datos se utilizara: transacciones individuales, snapshots de alto nivel o elementos individuales de documentos de control como facturas. 3. Escoger las Dimensiones: Seleccionar de todas las dimensiones posibles aquellas con la menor granularidad que tomen un valor nico en el contexto de un conjunto dado de medidas del negocio. 4. Escoger los Hechos: Los hechos deben ser siempre especficos a la granularidad de la tabla de hechos. No se deben mezclar hechos de otros perodos de tiempo u otras agregaciones para hacer los clculos convenientes. Construccin de Modelos Dimensionales Aqu Kimball expone que el conjunto de los modelos dimensionales constituyen el diseo lgico del Data Warehouse, pero es necesario decidir que modelo, es decir que Data Mart, se construir primero. Segn Kimball se debe comenzar con un enfoque de planeacin de arriba-abajo al que llama Matriz de Arquitectura del Data Warehouse, en la cual se nombran todos los Data Marts que sea posible construir junto con las dimensiones implicadas por dichos Data Marts y luego se relacionan ambos para determinar las dimensiones que son utilizadas por ms de un Data Mart y que deben ser conformadas para asegurar un Bus de Data Warehouse. En la siguiente etapa, una vez que ya se han identificado los Data Marts y sus dimensiones asociadas, se procede con los diseos fsico y lgico detallados de las tablas individuales, se utiliza el mtodo de cuatro pasos para disear cada tabla de hechos.
32
Luego ya ser posible la elaboracin del borrador inicial, el cual permitir rastrear e identificar los hechos base y los hechos derivados que deban ser incluidos, as como solucionar aspectos de hechos duplicados y otros, para adaptar mejor el modelo a las caractersticas y exigencias del negocio. En este proceso se realizan los cambios necesarios en el modelo, los cuales deben ser plenamente documentados, los realizados y los pendientes, junto a todas las decisiones que se realicen, desde elegir las fuentes de datos hasta determinar las frmulas de clculo de los hechos derivados y dems. El modelado dimensional para la primera implementacin, no el modelo de la empresa, se puede considerar finalizado una vez que se han resuelto los aspectos requeridos para alcanzar el objetivo del negocio, se pueden agrupar en las categoras siguientes [Kimball98, p 307]: Elementos crticos de datos. Elementos crticos de las polticas del negocio: implican decisin acerca de cmo manejar determinadas situaciones Futuro/Fuera del Alcance: son elementos interesantes de tener, pero que no justifican el esfuerzo necesario en la primera implementacin 3.3. Arquitectura Una arquitectura bien definida agrega valor al proyecto, al mejorar la comunicacin y planeacin. Una arquitectura efectiva producir un incremento en la flexibilidad del sistema, facilita el aprendizaje a los usuarios y mejora la productividad y el re-uso ya que permite elegir adecuadamente herramientas que automaticen partes de los procesos del Data Warehouse, as como reutilizar procesos existentes en lugar de iniciar de nuevo a partir de la nada [Kimball98, p 318]. El planteamiento de arquitectura al que se refiere Kimball, se resume en la tabla que sigue, llamada marco de trabajo de la arquitectura, donde las columnas muestran las principales reas de la arquitectura: datos, tcnica e infraestructura y las filas representan los niveles de detalle en orden creciente: requerimientos del negocio, modelo de arquitectura, modelo detallado, implementacin.
33
Tabla I-2. Marco de Trabajo de la Arquitectura

Nivel de detalle Requerimientos de Negocio y Auditoria Modelos de arquitectura y Documentos Modelos detallados y Especificaciones Implementacin Datos (qu) Datos que dirigen el negocio El modelo dimensional El Modelo Fsico y Lgico Creacin de la BD, ndices, etc. Documentar Tcnica (cmo) Back room Como se trataran los datos Capacidades especificas para tratar los datos Que estndares y productos proveen dichas capacidades Programar, automatizar, documentar Front room Formas de anlisis de los datos Servicios para que los usuarios utilicen la informacin Especificaciones de reportes. Usuarios posibles. Frecuencia Construir el ambiente de reportes y anlisis. Documentar Infraestructura (donde) Hardware y software necesario Fuente-Destino de datos. Capacidad de almacenamiento Interaccin con las capacidades y utilidades del sistema. Instalar y probar los componentes nuevos de la infraestructura
Este marco de trabajo de la arquitectura del Data Warehouse ayuda a dividir en piezas manejables la tarea de construir la arquitectura del Data Warehouse. Arquitectura de Datos En el rea de arquitectura de datos se incluye el contenido del Warehouse, el diseo fsico y lgico de los modelos de datos, agregaciones, jerarquas y ms, los cuales ya fueron abordados en el apartado anterior. Arquitectura Tcnica El rea de arquitectura tcnica cubre los procesos y herramientas que se aplican a los datos [Kimball98, p323]. En el rea tcnica existen dos conjuntos que tienen distintos requerimientos, brindan sus propios servicios y componentes de almacenaje de datos, por lo que se consideran cada uno aparte: El back room (habitacin trasera) y el front room (habitacin frontal). El back room es el responsable de la obtencin y preparacin de los datos, por lo que tambin se conoce como adquisicin de datos. El front room es responsable de entregar los datos a la comunidad de usuario y tambin se le conoce como acceso de datos. A pesar de esta separacin ambos componentes interactan de manera significativa. En la arquitectura tcnica es importante conocer que existen principios de diseo que deben presentar todas las herramientas, procesos y componentes de las capas de servicio [Kimball98, p331]: Dirigidos por los Metadatos: los metadatos proveen parmetros e informacin (un conjunto de informacin de control acerca del Data Warehouse, su contenido,
34
sistemas fuentes y su proceso de carga) que permite que la aplicacin desempee sus tareas correctamente. Capas de Servicio Flexible: El servicio de consolidacin de datos y el servicio de consulta de datos son capas de aplicacin que tambin proveen cierto nivel de indireccin lo cual se agrega a la flexibilidad de la arquitectura. El back room es donde tiene lugar el proceso de preparacin de los datos. Es el cuarto de mquinas del Data Warehouse [Kimball98, p335]. Su principal asunto es resolver los problemas especficos de la migracin de datos del punto A al punto B, con las transformaciones apropiadas y en el momento justo. En la arquitectura del Back Room se debe analizar los aspectos relativos a: los sitios donde se almacenan los datos (sistemas fuente, rea de conciliacin de datos, servidores de presentacin), los servicios que proporcionara (extraccin, transformacin, carga, control del trabajo de conciliacin) y la administracin de los activos del back room (respaldo y recuperacin, archivo, seguridad de la extraccin y carga y servicios futuros). El front room es lo que los usuarios finales miran y utilizan para trabajar da a da. Es la cara del Data Warehouse [Kimball98, p373]. Su principal asunto es construir una capa intermedia entre los usuarios y la informacin que permita esconder algunas de las complejidades propias de la plataforma tcnica y que les ayude a encontrar lo que buscan. En la arquitectura del Front Room se debe analizar los aspectos relativos a: 1. Los sitios donde se almacenan los datos: herramientas de acceso a los almacenes de datos, almacenes de datos para reporte estndar como los Data Mart personales, sistemas de carga a otras aplicaciones. 2. Los servicios que proporcionara para el acceso de datos: navegacin, acceso y seguridad, monitoreo activo, administracin de consultas, localizacin de consultas, reportes estndar, servicios de acceso futuro, servicios de escritorio, modelacin de aplicaciones y Data mining, implicaciones web y enfoques para la arquitectura de herramientas de escritorio. Arquitectura de Infraestructura y Metadatos El rea de arquitectura de infraestructura se refiere a las plataformas que soportan los datos y procesos. Es la planta fsica del Data Warehouse y provee los cimientos para todos los elementos de la arquitectura ya descritos. La Infraestructura incluye el hardware, la red y funciones de bajo nivel que los componentes de ms alto nivel
35
no contemplan. Los metadatos son de un tipo distinto pero proveen el mismo tipo de capa base de soporte para las herramientas del back room y del front room [Kimball98, p411]. Para definir correctamente este componente en la arquitectura del Data Warehouse, siempre se debe tomar en consideracin: los requerimientos del negocio, los cuales dictaminan la direccin del Warehouse, la evolucin que la infraestructura sufrir en la puesta en marcha del proyecto y evolucin, los factores de la infraestructura del back room (tamao de datos, volatilidad, cantidad de usuarios, hardware, sistema operativo entre otros), factores de infraestructura del front room (consideraciones de los servidores de aplicacin, del escritorio), factores de redes y conectividad (ancho de banda, acceso remoto, gateways, transferencia de archivos, conectividad de la base de datos). En el aspecto relativo a los metadatos los puntos claves en los que pueden ser agrupados son: metadatos de los sistemas fuente, metadatos de conciliacin de datos, metadatos del DBMS, metadatos del front room. Finalmente, debe existir un catlogo de metadatos, lo cual es una herramienta que permita catalogar y darles seguimiento a todos los metadatos. 3.4. Implementacin Antes de iniciar la implementacin es importante decidir que hechos deben ser agregados con respecto a que dimensiones con el objetivo de mejorar el desempeo general del Data Warehouse, para ello es necesario que: Cada agregacin en cada nivel distinto sea guardado en su propia tabla de hechos, separados del resto de los datos atmicos. Siempre que sea posible las dimensiones adjuntas a las tablas de hechos deben ser versiones reducidas de las dimensiones asociadas con las tablas de hechos base. Las tablas base de hechos atmicos y sus tablas de hechos agregadas deben ser relacionadas como una familia de esquemas (permite que el navegador conozca que tablas estn relacionadas entre si). Se debe forzar a todas las rutinas SQL creadas por cualquier herramienta de usuario final para acceso a los datos o de aplicacin, se refieran exclusivamente a la tabla de hechos base y sus dimensiones de tamao completo. Otro elemento que debe ser completado es el diseo fsico.
36
Completar el Diseo Fsico Existen varios aspectos que por ser meramente de implementacin no se consideraron en el componente de arquitectura que define los modelos y diseo fsico. Por lo tanto una vez iniciada la implementacin del Data Warehouse es necesario completarlos. Estos detalles son altamente dependientes de los factores individuales de un proyecto: El modelo lgico de datos, el RDBMS del Warehouse, los volmenes de datos, los patrones de uso y las herramientas de acceso, sin embargo, es posible determinar un proceso de alto nivel para el diseo fsico. La secuencia bsica es iniciar con algo de planeacin desarrollo de estndares de nomenclatura y de la base de datos y una estrategia de seguridad. Luego, construir del modelo fsico incluyendo un corte en el tamao preliminar de la base de datos y de las tasas de crecimiento. Revisar el plan de agregaciones que ya se defini. Una vez que ya se conoce cuales son todas las tablas, se puede hacer un corte para la estrategia preliminar de ndices. En este punto, uno puede realmente iniciar la parte fsica, pues se cuenta con suficiente informacin acerca de lo que ocurre en la base de datos y cuando, los necesario para iniciar el diseo y construccin de la instancia de base de datos en sus mnimos detalles, e implementar herramientas de monitoreo de uso [Kimball98, p570]. Consolidacin de Datos El proceso de consolidacin de Datos se puede dividir en un plan de diez pasos para la creacin de la aplicacin de consolidacin de datos para el Data Mart [Kimball98, p610]:
Plan: 1. Crear un esquema de alto nivel, muy consolidado, del flujo de fuente a destino. 2. Probar, escoger e implementar la herramienta de consolidacin de datos. 3. Drill down por cada tabla destino, bosquejar grficamente cualquier reestructuracin o transformacin de datos compleja y el proceso de generacin de claves arbitrarias. Desarrollar la secuencia preliminar de trabajo. Carga de Dimensiones: 4. Construir y probar la carga de una tabla de dimensin esttica. 5. Construir y probar el proceso de cambio lento para una dimensin. 6. Construir y probar la carga de las dimensiones faltantes.
37
Tablas de hechos y automatizacin 7. Construir y probar la carga de las tablas de hechos histricas. 8. Construir y probar el proceso de carga incremental. 9. Construir y probar la carga de las tablas de agregaciones. 10. Disear, construir y probar las aplicaciones de automatizacin del proceso de conciliacin. Es en esta etapa cuando se debe asegurar la calidad de los datos y su limpieza y cuidar los detalles propios de implementacin de cada proyecto. Por todo esto, la etapa de conciliacin de datos es una de las piezas ms difciles de un proyecto de Data Warehouse. Construir las Aplicaciones de Usuario Final El proceso de construccin de estas aplicaciones se puede dividir en dos apartados: Especificacin de la aplicacin y Desarrollo de la Aplicacin [Kimball98, p665]. Este proceso es estndar y anlogo al desarrollo de aplicaciones para los sistemas transaccionales, con la salvedad en que tpicamente se basa en la herramienta de acceso de datos seleccionada y que debe brindar soporte a usuarios con requerimientos de anlisis improvisados. 3.5. Despliegue y Crecimiento Un despliegue exitoso de un Data Warehouse requiere planeacin consistente y coordinacin previa a la culminacin de los esfuerzos de desarrollo. Un apropiado mantenimiento y crecimiento evidencian el xito de llevar a cabo un proyecto importante como es un Data Warehouse, una correcta gestin que ponga en primer lugar satisfacer a los usuarios de negocio, sin sacrificar atencin al back room y entorno tcnico permite asegurar una adecuada evolucin del Data Warehouse si es acompaado de mediciones y rastreo en el Data Warehouse y retroalimentacin de parte de los usuarios. Planeacin del Despliegue Despliegue es la convergencia de tecnologa, datos y aplicaciones en los escritorios de los usuarios de negocios, junto con la necesaria educacin y estructura de soporte al usuario [Kimball98, p691].
38
El despliegue necesita mucho trabajo de planeacin y la coordinacin de muchas variables, por lo que su preparacin no puede iniciarse hasta ltima hora, sino con mucha antelacin. Esta planeacin y preparacin permite colocar todas las piezas del Warehouse en su respectivo lugar antes de desplegarlo. Mucho de la arquitectura e infraestructura del back room como el HW, el DBMS, el catlogo de Metadatos y dems sern establecidas mucho antes del despliegue puesto, que se necesitan para las actividades del despliegue mismo. La tecnologa que reside en los escritorios de los usuarios es la ltima pieza que debe ser colocada en su lugar puesto que es el punto de inicio del despliegue en si. La Planeacin del despliegue se puede dividir en varias partes. En una de ellas se determina la disponibilidad de instalacin en los escritorios de usuario, en otra es necesario desarrollar una estrategia de educacin del usuario final, que es clave para el xito del Data Warehouse, debe ser muy bien integrada e incluir los aspectos del contenido de datos, las aplicaciones de usuario final y de las herramientas de acceso de datos [Kimball98, p693]. Una estrategia de soporte al usuario final es fundamental para terminar de consolidar el proceso de aprendizaje y asegurar la correcta utilizacin y xito del Warehouse a travs de una fluida comunicacin y retroalimentacin de parte de los usuarios. Otra parte del despliegue consiste desarrollar un marco de trabajo para la emisin del despliegue. El proceso utilizado para desplegar el Data Warehouse debe ser evidentemente similar al proceso utilizado para desplegar un nuevo paquete comercial de software, las emisiones son definidas para un desarrollo basado en requerimientos. Cada cambio significativo al Data Warehouse, consistente en nuevos datos y/o contenido de aplicacin o nuevos grupos de usuarios, debe ser considerado una emisin [Kimball98, p705]. La parte final del despliegue es por supuesto el desarrollo de una estrategia para documentar el despliegue. Mantenimiento y Crecimiento del Data Warehouse Este es el ltimo componente de la metodologa de Ralph Kimball. Para administrar el entorno del Data Warehouse existente es importante enfocarse en los usuarios de negocio, los cuales son el motivo de su existencia, adems de
39
gestionar adecuadamente las operaciones del Data Warehouse, medir y proyectar su xito y comunicarse constantemente con los usuarios para establecer un flujo de retroalimentacin. Finalmente, es importante sentar las bases para el crecimiento y evolucin del Data Warehouse en donde el aspecto clave es manejar el crecimiento y evolucin de forma iterativa utilizando el Ciclo de Vida propuesto, y establecer las oportunidades de crecimiento y evolucin en orden por nivel prioridad.
40
II.
ANLISIS CUALITATIVO DE LAS METODOLOGAS. Para la elaboracin de la gua objeto de este estudio, es necesario realizar un
anlisis cualitativo de las metodologas abordaron, para determinar cual o cuales elementos de una o de todas las metodologas mejor cumplen el objetivo de servir de gua a noveles en Data Warehousing, y que les apoye en la definicin y desarrollo de un proyecto de Data Warehouse. Es necesario recalcar que un enfoque exitoso para la construccin de un Data Warehouse debe contemplar mucho ms que el proceso de diseo, pues el diseo es slo una parte del todo, an cuando el diseo mismo se encuentre en el ncleo del desarrollo. Las situaciones que se deben contemplar y resolver envuelven la arquitectura de datos del Data Warehouse, la cultura organizacional, la calidad de datos, integracin de datos y dems, con tantas variables en juego es imperativo reconocer que no existe un nico mtodo aplicable a toda empresa u organizacin pues cada una es nica, si no ms bien conocer y comprender cuales son las filosofas y metodologas que han sido ms exitosas y tratar de utilizarlas y adaptarlas a las circunstancias especficas que se afrontan, combinando sus mejores puntos, enseanzas y prcticas en un todo cohesivo, en lugar de enfocarse en una sola de ellas. Para que una metodologa tenga xito debe reunir ciertos elementos. La metodologa para una iniciativa de Data Warehouse debe resolver el amplio alcance arquitectnico y funcional del Data Warehouse. La estrategia de Data Warehouse que se elija se debe enfocar en producir un marco de trabajo conceptual de soluciones integradas para las distintas capas de la arquitectura, mediante la exploracin de los requerimientos de la arquitectura de datos, la arquitectura de metadatos, los procesos del back-end (extraccin, transformacin y aplicacin) y las aplicaciones del front-end (DSS), as como la infraestructura de tecnologa. El enfoque de la estrategia ser amplio, no profundo, ya que esto depende de la situacin en cada empresa. El objetivo es asegurar que la arquitectura de informacin entregue valor de negocio inmediatamente a los encargados de realizar las decisiones que dirigen el negocio y que coloque al negocio en posicin para xitos futuros. Se culmina con la entrega de una arquitectura conceptual consolidada y los planes para una estrategia de emisiones en etapas. Para que una estrategia de Data Warehouse sea alineada con la estrategia de un negocio, la metodologa debe explorar todos los aspectos de la estrategia del negocio.
41
De las metodologas abordadas en el Marco Terico es posible hacer por separado un anlisis cualitativo de los atributos y limitantes de cada una. A continuacin el anlisis:
A.
Barry Devlin El primer trabajo publicado en el tema de Data Warehouse, pertenece a Barry
Devlin, como se dijo en el Marco Terico. La metodologa expuesta por l, es una gua para implementar y construir un Data Warehouse que incluye el anlisis racional del negocio que debe ser hecho, la arquitectura tcnica con la que se debe contar y el proceso de implementacin completo. Esta metodologa provee una fundacin terica excelente para disear un ambiente integral de Inteligencia de Negocio (cualquier informacin que pertenece a la historia, estado actual o proyecciones futuras de una organizacin). Devlin estructur su punto de vista como una arquitectura comprensiva al integrar el Data Warehouse al desarrollo de los sistemas de informacin y considerarlos como un todo. Para Devlin el Warehouse es parte del diseo de sistemas a nivel corporativo, lo cual es un enfoque muy apropiado e innovador. En su visin, la base de datos del Data Warehouse es parte de una solucin ms grande, no un final en s mismo. El Data Warehouse es un activo estratgico desarrollado para servir los intereses de la comunidad de negocios entera. El Data Warehouse es una coleccin de datos que ser usada por los usuarios de negocio para suplir la mayor parte de las necesidades de acceso y anlisis de informacin. El Warehouse tambin ser un vehculo para incrementar la calidad y disponibilidad de los datos conforme a una naturaleza diversa de necesidades y usuarios, esto permite luego ingresar datos integrados y de calidad en el ciclo de retroalimentacin de la informacin y para que puedan ser usados por otros sistemas corporativos. En su enfoque, Devlin separa claramente los distintos componentes de una arquitectura eficaz y adecuada para la realizacin de un proyecto de Data Warehouse, que deben de estructurarse y trabajar en conjunto para asegurar el xito del proyecto. Adems, l proporciona un nmero de tcnicas, sugerencias y tips de cmo implementar y disear el ambiente de Inteligencia de Negocio.
42
El elemento diferenciador de la Arquitectura propuesta por Devlin, es la Arquitectura en tres capas, entre ellas destaca la capa intermedia de datos reconciliados. Su propsito es tomar los datos de sistemas operacionales diversos, heterogneos, distribuidos geogrficamente y combinarlos y enriquecerlos en una imagen nica y lgica del modelo de datos empresarial. De esta capa los datos pasan a la capa de datos derivados a travs de procesos que generan cualquier combinacin de datos que los usuarios puedan requerir. Todo esto es parte del Data Warehouse y no una plataforma separada, por lo que Devlin logra ampliar el alcance del DW en la organizacin. Esta caracterstica resulta de mucho valor para aquellos ambientes donde existen muchos y diversos sistemas fuentes de datos y algunos sistemas de soporte a la toma de decisiones que no estn logrando su objetivo. Entonces, se hace necesario reconciliar los datos procedentes de estos sistemas sin introducir nuevos entornos, porque implican ms duplicacin de datos, sin forzar los datos existentes para que quepan en los ambientes presentes aunque no sean adecuados para ellos, porque no se lograra suplir las necesidades de informacin de la empresa, y hacer coincidir todo en un ambiente acorde a los estndares de buenas prcticas de arquitectura de datos que proclaman una clara separacin del entorno operativo con el informacional. Otro de los componentes que Devlin claramente destila y del que aborda las caractersticas y estructura que lo constituyen, es la interfaz de usuario, esto se deriva del hecho de que para los usuarios de negocios, el Data Warehouse no es una Base de Datos sino una aplicacin. Aunque el Data Warehouse sea inmejorable, si la interfaz es pobre difcilmente ser exitoso. La clave de la importancia de este autor radica en que sus enseanzas son vitales para poder asimilar de forma clara como debe de ser idealmente un Data Warehouse, sus conceptos tericos son inmejorables y la evidente diferencia que marca entre uno y otro componente de la arquitectura del Data Warehouse, as como la descripcin detallada que hace de los mismos, permite que sea invaluable como metodologa de enseanza, aunque con la debilidad de presentar pocas herramientas de aplicacin real en el desarrollo de un proyecto, sino ms bien componentes a nivel lgico y conceptual.
43
Una de las debilidades de la propuesta de Devlin es que no muestra la forma en los distintos componentes de la arquitectura que l describe deben estar ensamblados e interactuar para formar un todo coherente, por lo que deja inconcluso este aspecto metodolgico y arquitectnico medular. Para que una metodologa sea slida es de suma importancia, que sta presente un diagrama completo de la situacin y solucin descrita, porque ocurre que surgen muchas preguntas y cuestiones que aparecen sin aparente solucin. El enfoque de Devlin deja sin puntualizar su propuesta, por lo que se vuelve difusa su efectividad en algunos puntos.
B.
William Inmon La definicin de Data Warehouse de Inmon ha puesto en claro una buena
sntesis de lo que es un Data Warehouse y ha ayudado inmensamente al desarrollo de la industria, debido a que provee guas concretas para construir un Data Warehouse. Implcitamente, esta definicin sustenta uno de los principios fundamentales del desarrollo de un Data Warehouse, el principio que el ambiente de origen de los datos y el ambiente de acceso de datos deben estar fsicamente separados en diferentes bases de datos y en equipos separados. Inmon tambin identifica la importancia de utilizar un Data Warehouse para guardar datos histricos continuos, ya que uno de los mayores obstculos para el anlisis de informacin relevante es no contar con datos disponibles sobre un periodo de tiempo extendido. Operacionalmente, se tiende a almacenar solamente una vista actual del negocio, lo cual es un perodo mucho muy corto para un anlisis serio de tendencias. A Inmon se le asocia frecuentemente con los esfuerzos de Data Warehouse a nivel empresarial, que involucran desde un inicio todo el mbito corporativo, sin centrarse en un incremento especfico hasta despus de haber terminado completamente el diseo del Data Warehouse. En su filosofa, un Data Mart es slo una de las capas del Data Warehouse, los Data Marts son dependientes (obtienen la informacin) del depsito central de datos o Data Warehouse Corporativo y por lo tanto se construyen luego de l. El enfoque de Inmon de desarrollar una estrategia de Data Warehouse e identificar las reas principales desde el inicio del proyecto es necesario para asegurar una solucin integral. Esto ayuda a evitar la aparicin de situaciones inesperadas en el futuro
44
cercano del proyecto que le puedan poner en peligro, debido a que se conoce con antelacin y bastante exactitud la estructura que presentarn los principales ncleos del desarrollo, lo cual permite enfocar los esfuerzos del desarrollo actual para ser compatible con los subsiguientes. Inmon es defensor de utilizar el modelo relacional para el ambiente en el que se implementar el Data Warehouse Corporativo, asegura que esta es la alternativa ms adecuada para que el almacn central sea ms eficiente sin afectar a los usurarios finales ya que la frecuencia de acceso de los mismos es muy escasa en este nivel. Mientras, aplicar al esquema estrella o modelado dimensional a la aplicacin Front End que llama Data Mart, y que es donde realmente tiene lugar el acceso de los usuarios en su Arquitectura. Inmon ciertamente coincide en que el modelado dimensional est bien para los Data Mart, pero hace nfasis en que estos deben ser dependientes del Data Warehouse Corporativo; sin embargo est muy convencido que un diseo basado en Diagramas Entidad Relacin es mucho ms apropiado para el Data Warehouse central de mayor magnitud. Segn Inmon y aqu tambin coincide Devlin, la estructura ideal que se busca para un Data Warehouse, porque proporciona la manera ms efectiva de colectar, almacenar y diseminar la Informacin, es muy probablemente: Datos antiguos, limpiados en un RDBMS (potencialmente un Data Warehouse Empresarial). Datos reconciliados, desde el Data Warehouse Empresarial obtienen su informacin los Data Marts, cubos y otras herramientas para anlisis y reportes que utilicen un enfoque multidimensional para mostrar la informacin. El problema que trae consigo este enfoque es que es ideal para los propsitos de desarrollo del equipo de Tecnologa de Informacin pero no para las finanzas de la organizacin. A esta estructura no es posible dividirle en partes modulares que al implementarse comiencen a ser explotadas, sino que es hasta que toda la arquitectura est en su lugar que los usuarios de negocio obtienen beneficio de ella. Es un enfoque de big bang que trae consigo mucho riesgo a la compaa que invierte grandes esfuerzos en el desarrollo del DW y no es sino hasta que comienzan a aparecer los Data Marts que realmente comienza a explotar su inversin y a obtener beneficios de ella.
45
La estrategia de big bang de Inmon es en cierta medida comparable con el ciclo de vida clsico del desarrollo de aplicaciones y comparte con sta metodologa algunos riesgos, el ms peligroso para un Data Warehouse es sin duda, que en el marco de que es imposible conocer en avance cuales son las necesidades concretas de informacin de una empresa, el ambiente dinmico en que se mueve la organizacin, el cambio de estructura que conlleva el desarrollo de la nueva plataforma y los consiguientes cambios a los sistemas transaccionales que su introduccin implica; es muy probable la posibilidad de que luego de un considerable plazo de tiempo y recursos invertidos en el desarrollo del Data Warehouse, una vez finalizado y puesto en explotacin el mismo, se hagan evidentes algunos cambios fundamentales que traen consigo altos costos de desarrollo para la organizacin, poniendo en evidente peligro el xito de todo el proyecto en s y que podan ser evitados con una pronta deteccin en una temprana puesta en explotacin de un primer avance del Data Warehouse. Otra de las restricciones que trabajan en contra de la metodologa de Inmon es que consume mucho ms tiempo trabajar nica y completamente con esta metodologa, esto tiene como consecuencia que muchas empresas se inclinen por usar metodologas de la que obtengan resultados tangibles en un espacio menor de tiempo.
C.
Ralph Kimball Kimball difiere de los otros autores abordados en enfoque: El Data Warehouse
no es nada ms que la unin de todos los Data Marts que lo constituyen [K, p19]. En el mundo de Kimball el Data Mart es el Data Warehouse, esto se afirma en el sentido de que Kimball expone que al construir los Data Marts ya se est construyendo el Data Warehouse de una manera incremental. Un Data Mart es un subconjunto de datos organizados, como en el Data Warehouse, para el soporte a la toma de decisiones, pero que slo representa la visin de un departamento o individuo, por este motivo Kimball es frecuentemente asociado con esfuerzos departamentales y no corporativos. En la actualidad la mayora de los proyectos de Data Warehouse implementan el modelo de Data Marts de Kimball en lugar del esquema de Data Warehouse empresarial propuesto por Bill Inmon o de la arquitectura en tres capas de Devlin, esto obedece a motivos de tiempo, costo y el riesgo de fracaso asociados con el desarrollo de los dos ltimos [Lee02]. A esta tendencia general se le ha identificado como la aproximacin que
46
pretende garantizar la probabilidad de xito ms grande en la implementacin de un Data Warehouse, tanto por la rapidez en la obtencin de resultados en perodos cortos (tiempo) con inversiones moderadas (costo) como por la modularidad posible de alcanzar con este enfoque considerando cada Data Mart como un incremento del sistema final, el Data Warehouse (menor riesgo de fracaso) [Wolf99]. El punto central de la metodologa de Kimball es el modelado dimensional. Un buen diseo asegura en gran parte el xito del proyecto. El objetivo primordial que se persigue con un Data Warehouse, servir de soporte a la toma de decisiones, slo es alcanzado si el diseo del Data Warehouse - Data Mart propone una estructura consistente y adecuada a las necesidades de informacin de la organizacin. Por este motivo Kimball pone nfasis en el diseo de los Data Marts, para lo cual utiliza el modelado dimensional en la versin del esquema estrella. Kimball afirma que esta tecnologa siempre puede ser aplicada en cualquier proyecto de Data Warehouse y que es el mtodo ms adecuado para alcanzar el objetivo ya mencionado. El esquema estrella representa la denormalizacin ptima de los datos que mejor se adapta a los requerimientos de los usuarios. El concepto clave que ha popularizado la metodologa del seor Kimball es que l aborda el proyecto de Data Warehouse como un proceso de Implementacin Gradual, Data Mart a Data Mart. Sin embargo, Kimball tambin pone en claro que lo primero que se debe hacer al comenzar el modelado dimensional es analizar la slida base que representa el Diagrama Entidad Relacin de la empresa y a partir de all iniciar el modelado dimensional, es decir, primero se debe contemplar toda la organizacin empresarial para encontrar los procesos discretos del negocio, luego corresponde establecer cuales son todos los posibles Data Marts y de entre ellos seleccionar cual es el ms adecuado de implementar, en la correspondiente iteracin del Data Warehouse. A continuacin ya se puede enfocar en l o los Data Mart que pertenecen a la etapa actual del proyecto y proceder con el ciclo de vida que expone en su metodologa. El ciclo de vida propuesto trae como consecuencia que existan Data Marts que se traslapen, para el caso en que se tienen que contemplar las diferentes vistas que distintos usuarios o departamentos tienen acerca del Modelo de Datos Corporativos, las implementaciones de vistas dismiles deben realizarse en Data Mart separados. Para asegurar la correcta unin y engranaje de los Data Marts y evitar que se conviertan en
47
conjuntos disjuntos (islas) de informacin Kimball establece el mtodo de dimensiones conformadas y lo designa como el Bus del Data Warehouse. Todos estos elementos para que funcionen sinrgicamente deben ajustarse en un marco de trabajo slido, flexible y extensible, que constituye la arquitectura que guiar la implementacin del Data Warehouse. Kimball como ya se vio, utiliza una matriz para clasificar tres grandes reas: Datos, Tecnologa e Infraestructura, los cuales tienen cuatro niveles de detalles siendo el ms bajo la implementacin fsica del Data Warehouse. Una vez establecida la arquitectura, se procede a implementar los primeros incrementos. La Implementacin por incrementos de Data Marts trae consigo algunas consideraciones importantes: La arquitectura Data Warehouse se debe desarrollar al principio del proyecto. El primer incremento se desarrolla basndose en la arquitectura. La operacin del Data Warehouse puede implicar la realizacin de cambios en la arquitectura. Cada incremento adicional puede extender el Data Warehouse. Cada incremento puede causar ajustes en la arquitectura. La operacin continua puede causar ajustes en la arquitectura. Por estas consideraciones muchos expertos afirman en que el enfoque de Kimball trabaja mejor si primero existe una estrategia de implementacin en la organizacin, pues de esta forma se reduce el nmero de cambios, que en muchos casos representa una gran parte de los esfuerzos de mantenimiento o de desarrollo del nuevo incremento. Estos cambios son necesarios de realizar para asegurar el adecuado funcionamiento y crecimiento del Data Warehouse. Es decir, que para un proyecto que envuelve la creacin de ms de un Data Mart es aconsejable que primero se deba desarrollar una estrategia corporativa como esqueleto y luego continuar con la metodologa de Kimball. Otro gran detrimento a la metodologa de Kimball, son consideraciones al corazn de la misma, el modelado dimensional. Un esquema estrella se construye obteniendo y asimilando requerimientos de los usuarios, lo que determina la forma y contenido de la estrella. El resultado de la estrella es ptimo para los usuarios que participan en el proceso de obtencin de requerimientos. El modelado dimensional es
48
excelente para representar las vistas de las personal que son de pensamientos similares, pero diferentes grupos de personas querrn su propia estrella que represente sus propias vistas. El esquema estrella se forma alrededor de los requerimientos de usuarios y porque estos requerimientos varan de un tipo de usuarios a los otros no es de sorprender que diferentes estrellas sean ptimas para diferentes tipos de usuarios. El problema real es cuando existen mltiples ambientes independientes de esquemas estrella, los mismos datos detallados aparecen en cada estrella. No existe reconciliacin de datos y las nuevas estrellas requieren la misma cantidad de trabajo para la creacin que las antiguas estrellas. Como resultado: Las uniones crecen innecesariamente grandes cuando cada estrella necesita datos detallados que otra estrella ya ha obtenido. Los resultados de cada estrella son inconsistentes con el resultado obtenido de cada otra estrella y la habilidad de reconciliar las diferencias no es aparente. No existen bases para construir nuevas estrellas porque cada una es construida independientemente. La interfase para soportar las aplicaciones que alimentan las estrellas se vuelve inmanejable. Se genera una gran cantidad de trabajo extra al construir cada parte en comparacin al enfoque de Data Warehouse Corporativo. Una vez establecido el anlisis sobre cada una de las metodologas estudiadas se han sentado las bases para la construccin de la gua objeto de estudio.
D.
Sntesis Las filosofas de Inmon y Kimball difieren principalmente en escala, Data
Warehouse Corporativo versus Data Warehouse por incrementos de Data Marts. Devlin es coincidente con Inmon en colocar los Data Marts como una capa aparte del Data Warehouse central, pero introduce otra capa intermedia, la capa de datos reconciliados en su arquitectura del Data Warehouse. Sin embargo, la diferencia real entre ellos se encuentra en el enfoque con el que se modela la Vista Corporativa. Todos coinciden en que es necesario al iniciar el proyecto analizar el modelo de datos empresarial con el que cuenta la empresa. A partir de aqu:
49
Kimball propone un esquema de denormalizacin del ERD para identificar procesos discretos de negocios (reas de inters) con sus posibles tablas de hechos y dimensiones. Luego, selecciona un subconjunto de datos para modelarlo utilizando el esquema estrella y continuar el desarrollo del Data Warehouse de forma iterativa, modelando un nuevo subconjunto cada vez.
Los otros autores realizan modelado Entidad Relacin sobre todo el conjunto de datos empresariales durante la primera iteracin del proyecto, de modo que se reconozca que datos son meramente operativos y cuales son de soporte a la toma de decisiones, se identifican las reas de inters y se procede a una reorganizacin de los datos para acomodarlos a las exigencias del Data Warehouse. En cada etapa se implementa solo un rea de inters. En las siguientes iteraciones, de ser necesario, solo ajustan el modelo inicial. El fracaso que sufren algunas organizaciones al utilizar la metodologa de
Kimball se deriva de que obvian la visin corporativa del Data Warehouse. La ventaja del enfoque corporativo es que con un buen diseo para el Data Warehouse empresarial se puede prevenir de los esfuerzos de duplicaciones y sincronizacin, que suelen aparecer en el enfoque de incrementos por Data Marts propuesto por Kimball.
50
III.
CONTEXTO NICARAGENSE La tecnologa de Data Warehousing no es nueva en el Mercado, pues se
remonta a ms de una dcada atrs, pero su crecimiento en el mundo a un ritmo acelerado, denota que la ltima palabra no est dicha, sino ms bien que apenas se comienza a vislumbrar la verdadera magnitud que sta puede alcanzar. El fundamento para la construccin de un Data Warehouse es algo ampliamente discutido y reconocido, por lo que cualquier empresa que desee ser competitiva y obtener valor a partir de los datos que posee, indudablemente se involucrar en un proyecto de Data Warehouse, en mayor o menor escala. Nicaragua no debe ser la excepcin a la regla. Las empresas para sobrevivir y crecer en el pas y ms all de sus fronteras deben estar en la capacidad de obtener el mayor beneficio posible de cada uno de sus recursos y la informacin es un recurso que, sin lugar a dudas, es invaluable. Para la obtencin de informacin confiable, consistente y oportuna, no es posible basarse en un entorno tecnolgico que est diseado y dirigido a automatizar transacciones (OLTP), sino hacer un cambio de paradigma y moverse a otro entorno, el analtico (OLAP) orientado a la toma de decisiones, que gestione la informacin necesaria para dirigir un negocio, sta es la premisa del Data Warehousing. Segn el Directorio Econmico Urbano INEC/MIFIC/GTZ, en su edicin de Febrero de 1998, en Nicaragua la cantidad de empresas que caben en la categora de grande y mediana con un rango de trabajadores de [21- 100 +] se encuentran clasificadas de la siguiente manera:
Tabla III-1 Empresas en Nicaragua

TIPO DE EMPRESA Grande Mediana Pequea No. DE EMPRESAS 160 712 4,526 No. EMPLEADOS 100 o ms [21-100] [ 6 - 20 ]
Y estas constituyen aproximadamente el 10 % de participacin en el mercado laboral de la nacin. Las, pequeas y mediana empresa constituyen la inmensa mayora de las empresas en el pas [La PYME en Nicaragua/MIFIC], y estn en crecimiento elevando
51
su clasificacin a una categora superior, las grandes empresas se consolidan en el mercado nacional y buscan su expansin. Nicaragua, se encuentra en una posicin tecnolgica distinta de la mayora de los pases de la regin, ya que debido a circunstancias que se dieron en su historia, el boom empresarial y tecnolgico no tuvo lugar sino hasta hace algunos aos, motivo por el cual el mayor porcentaje de empresas y organizaciones que radican en Nicaragua y que cuentan con sistemas de cmputo, son medianas y grandes empresas que exhiben una plataforma tecnolgica relativamente reciente, donde la existencia de sistemas de informacin, no supera la dcada de antigedad. Adems, la presencia de proyectos de Data Warehouse es insipiente, pero definitivamente esta tecnologa se desarrollar prontamente, pues las organizaciones en crecimiento necesitan ser cada vez ms competitivas, disminuir la brecha tecnolgica e incluirse cada vez ms en un mundo globalizado. En Nicaragua, debido a que hasta el momento no se ha desarrollado grandemente la industria Data Warehousing, no existen cursos de titulacin o especializacin en la materia y el personal capacitado y con experiencia en el ramo es realmente escaso, por lo cual se considera que la mayora de tecnlogos de la informacin presentes en el pas son noveles en la materia. El contexto tecnolgico de Nicaragua, representa una situacin muy especial que muestra la necesidad de una metodologa adaptada a la situacin presentada, que permita sacarle provecho a la realidad nicaragense y sus caractersticas propias. Es posible, para esto, adaptar las metodologas de Data Warehouse ms exitosas a las circunstancias particulares del pas unificando, reconciliando, condensando y adecuando las diferentes visiones, enfoques y procedimientos, para obtener una gua metodolgica que incluya los aspectos que ms se ajusten al contexto tecnolgico de Nicaragua y al hecho de que la mayora de los profesionales de tecnologa de informacin del pas son noveles en este campo. Para este caso se abordan las metodologas de Barry Devlin, William Inmon y Ralph Kimball, por su claro xito y reconocimiento y que previamente se discuti. Es un hecho real que casi ningn equipo en un proyecto de Data Warehouse construye un Data Warehouse utilizando una metodologa pura. Bsicamente cada equipo esta construyendo su propio enfoque y utilizando algunas de sus propias tcnicas, una vez que han asimilado lo mejor de las metodologas que elijan. Por ello, sta gua significa una
52
ayuda en la reduccin de la curva de aprendizaje de la tecnologa de Data Warehouse para el pblico nicaragense. Dicha gua servir de directriz al personal que realice por primera vez un proyecto de Data Warehouse y les presentar un ejemplo real de su aplicacin en una institucin financiera, tambin permitir que los usuarios de negocios comprendan en que consiste un Data Warehouse y los beneficios que se pueden obtener, para que reconozcan sus ventajas y se impulsen a implementarla en sus organizaciones. La gua constituye una base terica slida que le permite servir de referencia y material de apoyo a todos aquellos que deseen construir por primera vez un Data Warehouse, y les habilita a luego profundizar en la metodologa de alguno de los autores mencionados que mejor se adapte a sus requerimientos, al brindarles una visin precisa y compacta de las propuestas por las que cada uno ha destacado y se han merecido el reconocimiento mundial en este mbito.
53
IV.
ESTUDIO DE FACTIBILIDAD El estudio de Factibilidad consta de cuatro apartados de factibilidad: Tcnica,
Operativa, Econmica-Financiera y Legal, los cuales permitirn concluir y tomar la decisin de poner en prctica un proyecto, en este caso: El Data Warehouse. El apartado de la Factibilidad Tcnica es un estudio de la funcin, rendimiento y restricciones que puedan afectar la consecucin de un sistema aceptable para la implementacin y uso del Data Warehouse. Esto implica: adquirir y configurar los servidores, alojar el espacio de disco, construir las conexiones de red y seguridad; bsicamente la arquitectura tcnica del Data Warehouse. La Factibilidad Operativa permite verificar si la organizacin est en condiciones de absorber el cambio que significa la implementacin y uso del Data Warehouse para la cultura organizacional, entre estos podemos mencionar: El personal no tiene experiencia en el manejo de este tipo de sistemas. Los gerentes vern modificados los procedimientos de obtencin, anlisis y uso de informacin y adems debern estar a la cabeza del cambio. Se debe agregar el factor de la resistencia natural al cambio en todos los niveles. Se requerir la capacitacin del personal. Adems de todo esto se deber seguir cumpliendo con las actividades diarias para que el Negocio siga funcionando. Como vemos no se puede trivializar el estudio de factibilidad operativa, pues este permite poder reducir el margen de riesgo del proyecto y asegurar su xito dentro de la organizacin. La Factibilidad Econmico-Financiera del proyecto es una evaluacin del costo de desarrollo sopesado con los ingresos netos o beneficios obtenidos del producto desarrollado, en este caso del Data Warehouse. La justificacin econmica incluye una amplia gama de aspectos a tener en cuenta como son el anlisis de costo-beneficios, las estrategias de ingresos de la empresa a largo plazo, costo de recursos necesarios para el desarrollo y crecimiento potencial del mercado.
54
La Factibilidad Legal permite determinar y delimitar cualquier infraccin, violacin o responsabilidad legal en que se podra incurrir por el desarrollo del Data Warehouse. Por ltimo, se confeccionar el informe final para la alta direccin, con el resumen del Estudio de Factibilidad del Proyecto de inversin en un entorno analtico para la toma de decisiones. A continuacin el estudio de Factibilidad para la empresa donde se aplica la gua desarrollada.
A.
Factibilidad Tcnica En primer lugar se proceder a calcular la capacidad y a establecer el perfil
tcnico de los dispositivos y perifricos en funcin de los datos y aplicaciones que sern procesados por la futura instalacin. Tambin se necesita determinar que aplicaciones son necesarias para el desarrollo del proyecto de Data Warehouse.
1.
Requerimientos de la instalacin y aplicaciones La tabla IV-1 presenta el dimensionamiento de los elementos tcnicos
necesarios para llevar a cabo un proyecto de Data Warehouse.
Tabla IV-1 Requerimientos de Data Warehouse Categora Hardware Elemento Cnt Consideraciones
Tamao y organizacin de la memoria Escalabilidad Tecnologa Procesador Cantidad de procesadores Velocidad de procesador Cantidad de Discos Tiempo medio acceso a disco Capacidad de almacenamiento en discos Tipo (Fijos o removibles) CDs y Unidades de CDs Unidades de Tape Backup
Requerimientos
1.0 GB memoria o mayor Escalable en memoria, procesadores y disco duro RISC(*) o CISC 2 o ms 550 MHz o superior 6 discos en RAID 0+1 (*) 3 discos en RAID 0 SCSI 3 (*) 10krpm 100 GB en conjunto Hot Swap Plug Unidad de CD-ROM Presente(*)
Servidor
55
Categora
Elemento
Impresora UPS Catlogo de Metadatos
Cnt Consideraciones
1 2 Tipo (tinta o lser) Velocidad Capacidad Servicios de tipo general
Requerimientos
Lser 12 ppm o superior 2000 watts Control administrativo Informacin personal Informacin administrativa Calificacin de contenido Indispensable Indispensable Presente Indispensable RDBMS (*), MDBMS Preferido pero no indispensable Compatible con estndar SQL92 Juego de Instrucciones de DW Soporte para particiones que contengan datos fuertemente relacionados Indispensable Siempre que sea posible ERD DM(*) Extraccin, deduplicacin, duplicacin Microsoft Windows, Linux Indispensable Indispensable Opcional HOLAP (*), MOLAP, ROLAP Acceso a base de datos No requerido No requerido Opcional
Sistema Operativo
DBMS
Procesamiento en lotes de programas de aplicacin Multiprocesador Multiusuario Multitareas Tecnologa (RDBMS, MDBMS) Open System Lenguaje de Consulta Caractersticas de Data Warehouse Soporte de esquema estrella Uso de metadatos Tipo de modelado (Dimensional o ERD) Funcionalidades Soporte de plataformas Estandarizacin Procesamiento de textos Hojas de Clculo Software para modelar OLAP Reportes Data Mining EIS Productos hbiles para Web
Software
Modelador de Datos Herramienta ETL
Ofimtica
Herramienta de Acceso a Datos
(*) Indica la opcin preferente
2.
Opciones Disponibles Una vez determinados los requerimientos tcnicos se proceder a evaluar
opciones disponibles en el mercado que cumplen los requisitos establecidos y determinar su viabilidad. La tabla IV-2 presenta un resumen de stas opciones disponibles en el mercado nacional y que llenan los requisitos establecidos anteriormente. Sobre los elementos detallados en la tabla IV-2 se analizar la viabilidad de adquisicin para determinar cual ser la propuesta de adquisin ptima para la empresa en la que se realice el proyecto ejemplo.
56
Tabla IV-2 Alternativas de Adquisicin Elemento Servidores Opciones Dell Power Edge 2500 Compaq Proliant ML-350 Hewlet-Packard Netserver TC4100 Hewlet-Packard LaserJet 1200N Epson LA LQ-2180 Computer Associates Platinum Repository Metadata Management Corporation Design Bank IBM DB2 Microsoft SQL Server 7.0 Oracle9i Enterprise Edition Informatica Power Mart Designer IBM Warehouse Manager Oracle Warehouse Builder Oracle Designer/2000 Logic Works ERWin Microsoft Access, Excel Crystal Decisions Crystal Reports Microsoft Office 2000 StarOffice 6.0 Microsoft Windows 2000 Server Red Hat Linux 8.1
Impresora Catlogo de Metadatos DBMS
Herramientas ETL
Modelador de Datos Herramientas de Acceso a Datos Ofimtica Suites Sistema Operativo (en dependencia del DBMS)
En conclusin se ha establecido que la alternativa que representa una mejor adquisicin y desempeo desde el punto de vista tcnico, pues cumple plenamente con los requerimientos del sistema, en cuanto a programas y equipos esta dada por las variables que aparecen en la opcin A de la tabla siguiente. El software exclusivo de Data Warehouse (catlogo de metadatos, herramienta de ETL) no tiene disponible un representante en el pas, a diferencia de los restantes elementos para los que si se cuenta con un distribuidor y departamento de soporte tcnico. Los elementos fueron seleccionados producto de un anlisis de sus ventajas y desventajas, as para el caso del servidor se tom en cuenta la estabilidad de la firma que lo respalda, escalabilidad, precio, caractersticas de los componentes, soporte tcnico disponible. Una segunda alternativa a considerar en el estudio de factibilidad Econmica Financiera, introduce una variante en la alternativa del servidor sustituyendo el Hewlett Packard Netserver TC4100 por un Compaq Proliant ML-350, el cual consta con ms de un distribuidor autorizado en el pas, mientras el resto de opciones se conserva.
57
Tabla IV-3.- Opciones recomendadas Elemento Servidores Impresora Catalogo de Metadatos DBMS Modelador de Datos Herramientas de Acceso a Datos Ofimtica Suites Sistema Operativo (depende del DBMS) Opcin A Hewlett Packard Netserver TC4100 Hewlett-Packard LaserJet 1200N Computer Associates Platinum Repository Microsoft SQL Server 2000 Computer Associates ERWin Crystal Decisions Crystal Reports Microsoft Office 2000 Microsoft Windows 2000 Server Opcin B Compaq Proliant ML-350 Hewlett-Packard LaserJet 1200N Computer Associates Platinum Repository Microsoft SQL Server 2000 Computer Associates ERWin Crystal Decisions Crystal Reports Microsoft Office 2000 Microsoft Windows 2000 Server
Debido a que los costos del proyecto de data Warehouse podran resultar ser muy elevados para esta institucin en su etapa inicial y dado que sta se encuentra en un momento de renovacin de su plataforma tecnolgica, se ha suprimido la Herramienta de ETL (Extraction, Transformation, Load) del cuadro anterior y compensar su funcionalidad con algunas caractersticas propias del DBMS escogido. Es posible adems, prescindir del Catlogo de Metadatos y utilizar la caracterstica de metadatos propia de SQL Server 2000 con objetivos de la disminucin de costos. Por lo tanto, no se consideraran ambas herramientas en el apartado de Factibilidad Econmica- Financiera.
B.
Factibilidad Operativa El Data Warehouse tendr un profundo impacto en el funcionamiento de la
organizacin, debido a que una vez implementado, es un elemento estratgico de la empresa pues disminuye el grado de incertidumbre con la que se toman las decisiones. Algunas de las ventajas obtenidas del uso de un Data Warehouse que modifican, de manera positiva, el desempeo de la organizacin son: Contar con una fuente confiable de informacin que presenta una visin consistente de los datos e informacin de la empresa y su entorno. Elimina la necesidad de calcular informacin rutinaria de manera manual. Agiliza la gestin de datos e informacin relevante.
58

Pone a la disposicin de los niveles gerenciales la habilidad de hacer reportes de manera improvisada para satisfacer sus necesidades de informacin. Permite monitorear oportunamente los indicadores del negocio. Habilita el anlisis de tendencias, lo que permite descubrir oportunidades de utilidades para la empresa y debilidades que se deben corregir.
Alcance y Oportunidad Todo esto implica cambios organizacionales importantes en el esquema de trabajo. Estos cambios ocurrirn principalmente en los niveles donde se efecta la toma de decisiones: la media y alta gerencia. Sin embargo, a pesar de las ventajas que presenta la introduccin de un entorno analtico para quienes hagan uso del mismo, la curva de aprendizaje y la resistencia al cambio son factores a considerar. La empresa objetivo se encuentra en un proceso de cambio tecnolgico en la que se incluye poner a disposicin del personal tecnologa que le facilite el desarrollo de sus funciones, como la migracin de sistemas transaccionales a una plataforma ms adecuada y la introduccin de ordenadores del tipo Handheld para personal operativo y gerentes de todas las escalas y a todo el personal de tecnologa de informacin. En este marco el Data Warehouse se convierte en la secuencia ideal, al brindar soporte a la toma de decisiones. Las condiciones presentadas por el personal en las circunstancias mencionadas, permite afirmar que el personal de la organizacin presenta poca resistencia al cambio y que asimilarn de forma natural el nuevo entorno, si se establece un esquema de capacitacin adecuado como se ha hecho en las otras ocasiones, lo cual trae consigo adems una drstica disminucin en la curva de aprendizaje. El alcance del Data Warehouse ser organizacional. En cuanto al personal que conforma la media y alta gerencia, quienes harn mayor uso del Data Warehouse, el nivel de preparacin medio es muy alto. Ellos constituyen una base de recursos humanos que tiene inters en explotar las ventajas que brinda el Data Warehouse. La estructura organizativa de la empresa no se ver afectada, exceptuando que la gestin de informacin ser rpida y efectiva y el personal dispondr de mayor tiempo para realizar otras funciones, lo que aumentar el nivel de rendimiento y productividad del personal as como la calidad del trabajo realizado.
59
Dotacin El personal necesario para construir un Data Warehouse, no se puede establecer con exactitud y antelacin al desarrollo del proyecto, pues existen muchas circunstancias que no es posible anticipar y que pueden ocurrir y necesitar de la intervencin de personal ajeno al equipo base del proyecto que se encargar de desarrollar y dar mantenimiento al Data Warehouse. No obstante, es posible hacer una buena estimacin del grupo de recursos humanos que intervendrn y conformarn el equipo base, y las funciones que cumplirn. Los datos proporcionados a continuacin son una descripcin de las funciones bsicas que se deben desempear, para construir un Data Warehouse.
Tabla IV-4.- Dotacin de Personal Cargo

Analista de Negocios Arquitecto Tcnico Instructor DBA - Administrador de la Base de Datos Director de Proyecto Desarrollador de Reportes Desarrollador de rutinas ETL Soporte Tcnico
Funciones
Establece la definicin de trminos y operaciones del negocio. Anlisis de los procesos de negocios. Obtiene los requerimientos de informacin de los usuarios Anlisis de los sistemas fuentes de datos, construccin de los modelos de datos del Data Warehouse, definicin de la apariencia de la Base de Datos Capacitacin a los usuarios en el uso correcto del la funciones y habilidades del Data Warehouse Implementa los modelos de datos del Data Warehouse, mejora el desempeo de la Base de Datos, controla y monitorea el acceso y uso del Data Warehouse por los usuarios Coordina todas las actividades del personal. Establece el lmite del proyecto y el alcance de cada iteracin. Gestiona el plan del proyecto. Decide sobre las herramientas y metodologa a utilizar. Diseo e implementacin de los modelos de reportes a disposicin de los usuarios del Data Warehouse Desarrollo de los diseos para poblar la Base de Datos con los datos necesarios cuando se realice la carga del Data Warehouse. Asegurar la calidad de los datos Soporte con las plataformas de sistemas operativos, aplicaciones de escritorio, infraestructura de telecomunicacin.
El organigrama del grupo base del proyecto Data Warehouse es como sigue:
60
Director de proyecto
Arquitecto Tcnico
Analista de Negocios
DBA del Warehouse
Desarrollador de Rutinas ETL
Desarrollador de Reportes
Instructor
Ilustracin IV-1 Organigrama
Luego de la emisin del proyecto de Data Warehouse y de que se inicie su explotacin es necesario alojar personal que se encargue de su mantenimiento. Es el caso de que las funciones anteriormente expuestas, es muy aconsejable que sean desempeadas casi todas por personal perteneciente a la organizacin (ver apartado de factibilidad econmica-financiera). Se deber reestructurar el departamento para que personal que haya desempeado funciones de desarrollador de rutinas ETL y desarrollador de reportes puedan en adelante darle mantenimiento y solucionar posibles problemas en el Data Warehouse, cuando se requiera .El DBA debe estar en la posicin de implementar herramientas de monitoreo que le permitan ajustar mejor el desempeo del Data Warehouse a las necesidades de la organizacin. La dotacin de personal descrita, esta compuesto por personal de tiempo completo, de los que se exceptan el DBA y Soporte Tcnico los cuales son de carcter ocasional. Del personal de tiempo completo el nico cargo que debe ser desempeado durante todo el proyecto es el de Director de proyecto. Los roles de Analista de Negocios y Arquitecto Tcnico son desempeados en las primeras etapas del proyecto, Desarrollador de rutinas ETL y Desarrollador de Reportes aparecen despus cuando ya se tiene listo el diseo del Data Warehouse. El DBA aparece en la implementacin del Data Warehouse, mientras que Instructor es un rol que se desempea cuando el Data Warehouse esta a punto de entrar en produccin. Soporte Tcnico se requiere espordicamente para preparar y mantener la plataforma tecnolgica que soporta el Data Warehouse.
61
Una sola persona puede desempear ms de una funcin. En este sentido es posible que el personal que ha trabajado en los primeras etapas luego se mueva a otro puesto segn avance el proyecto como pasar de Arquitecto Tcnico a Desarrollador de rutinas ETL o que ya se desliguen del grupo base en modo de tiempo completo en el proyecto y pase a ser de carcter consultivo ocasional, lo cual implica un costo menor en el presupuesto. El Data Warehouse es un proyecto incremental, dividido en iteraciones, el resultado de cada etapa se presenta para la explotacin por los usuarios segn se concluye cada iteracin. La capacitacin del personal es tambin en etapas. Para cada iteracin la capacitacin del personal afectado, ser en sesiones de grupo de cinco a diez (5-10) usuarios por grupo con una duracin mxima de 3 horas y el Instructor realizara 2 sesiones por da. Cada grupo de usuario asistir a la sesin de capacitacin una vez, con lo que en un plazo de una semana se concluir de capacitar a todo el personal involucrado. Finalmente se pueden resumir los resultados: 1. La implementacin de un Data Warehouse, en la institucin analizada, tiene una alta probabilidad de xito. 2. El impacto del uso del Data Warehouse seguir una trayectoria de arriba abajo iniciando en los niveles de los tomadores de decisiones y se reflejara en un cambio en la gestin de la empresa. 3. El personal necesario para construir el Data Warehouse es un grupo base reducido con ayuda de las dems reas del departamento de tecnologa de la informacin. Una persona puede realizar ms de una funcin. 4. Los costos de la dotacin de personal no constituyen el mayor rubro de costos del proyecto.
C.
Factibilidad Econmico-Financiera Para efectuar el estudio de Factibilidad econmico-financiera resulta
imprescindible conocer la totalidad de los costos en que incurrir la empresa para incorporar el nuevo sistema analtico: el Data Warehouse. Tambin se debe contemplar el incremento de los costos debido a un aumento en las cargas de trabajo sobre la estructura, debido al funcionamiento del sistema luego de su puesta en marcha.
62
1.
Cuantificacin de la inversin Todos los costos que aparecen en el presente apartado son expresados en
Dlares Estadounidenses (US, $), por motivos del deslizamiento de la moneda nacional con respecto al mismo. Adems de los costos de hardware y software que representan el grueso de la inversin en el proyecto, ser necesario conocer los siguientes costos complementarios: Dotacin: Son los recursos humanos que intervendrn como grupo base en el desarrollo del proyecto de Data Warehouse, es preciso detallar el sueldo que percibirn, para la totalidad de puestos y vacantes, se puede establecer por proyecto o por periodo de tiempo.
Tabla IV-5.- Costos de Personal Cargo

Analista de Negocios Arquitecto Tcnico Instructor DBA Desarrollador de Reportes Desarrollador de rutinas ETL Director de proyecto Soporte Tcnico
Cant (unit)
1 1 1 1 2 2 1 1
Tiempo (mes)
1.50 2.50 0.50 1.50 1.50 2.00 4.75 0.50
Sueldo (mes)
$600.00 $600.00 $450.00 $800.00 $500.00 $600.00 $900.00 $450.00
Costo Total
$900.00 $1,500.00 $225.00 $1,200.00 $1,500.00 $2,400.00 $4,275.00 $225.00
TOTAL
$12,225.00
Cronograma del proyecto Las tareas que conforman el proyecto y que tendrn que ser desempeadas por el personal tienen establecidas una duracin estimada para cada tarea, con los que se calculan los costos en que se incurrir en concepto de personal para le proyecto de Data Warehouse. La realizacin de dichas tareas tiene un carcter secuencial y en otras de simultaneidad, ya sean estas dependientes o independientes y segn el orden de las tareas predecesoras ya finalizadas. En la Tabla.IV-6 se enumeran las tareas ha realizar en el proyecto y su duracin mientras que en los anexos se puede encontrar un Diagrama de Gant del Cronograma del proyecto.
63
Tabla IV-6-. Cronograma

ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Nombre Tarea Definicin del Proyecto Planeacin y Administracin del proyecto Definicin de los Requerimientos del usuario Modelado Dimensional Anlisis de las fuentes de Datos Diseo de la Arquitectura Tcnica Seleccin de Productos Instalacin de Productos Diseo fsico de la Base de Datos Implementacin fsica de la Base de Datos Diseo y Desarrollo de la preparacin de datos Poblacin y Validacin de Datos Ajustes de Desempeo Especificacin de las aplicaciones de usuario final Desarrollo de las aplicaciones de usuario final Prueba del sistema completo Total das Duracin 5 das 140 das 6 das 22 das 10 das 18 das 10 das 12 das 21 das 30 das 40 das 18 das 16 das 5 das 33 das 3 das 140 das
El total de das se estableci utilizando como perodo laborable base un da hbil que consta de nueve horas diarias de trabajo de Lunes a Viernes, la semana hbil comprende un total de cuarenta y cinco horas hombre para un trabajador cualquiera. Elementos Fsicos: Existen requerimientos para el desarrollo del proyecto que son de carcter fsico y forman parte de la infraestructura que servir de soporte al Data Warehouse, su consideracin en la factibilidad econmica-financiera ayuda a precisar los costos totales del desarrollo del proyecto. Los elementos en la categora disponible significa que existen a la disposicin dentro de la empresa y no deben ser adquiridos.
Tabla IV-7.- Costos de Infraestructura Concepto Mobiliario Instalacin elctrica Elemento
Rack para servidor Mesas para impresoras Regulador de tensin Ramal trifsico Puesta a tierra (Jabalinas de cobre)
Cant (unit)
1 1 1 1 1
Disponible (S/N)
S N N S S
Costo Unitario
$180.00 $20.00 $60.00 $15.00 $8.00 TOTAL
Costo Total
$180.00 $20.00 $60.00 $15.00 $8.00 $283.00
64
A estos costos se debern agregar los que tiene el estudio tcnico: Costo de Hardware, Software, ms Cargos por instalacin y Servicio Tcnico.
Tabla IV-8.- Costos Hardware y Software Elemento
DBMS Modelador de Datos Herramienta de Acceso a Datos Sistema Operativo Ofimtica Cargos por instalacin Servidor Hewlett Packard Servidor Compaq Impresoras
Cant
5 1 1 5 1 1 1 1 2
Disponible
(S/N)
Valor Unit
$188.48 $2,900.00 $468.00 $33.00 $130.00 $100.00 $9,923.00 $7,931.55 $747.00
Total
$942.40 $2,900.00 $468.00 $165.00 $130.00 $100.00 $9,923.00 $7,931.55 $747.00
N S S N S
N
N N N
Para establecer estos costos se consultaron a tres proveedores en los cuales el tiempo de vigencia de los presupuestos es de 15 o 30 das, la forma de pago puede ser en efectivo, con cheque o con tarjeta de crdito, todos entregan e instalan los equipos en un perodo menor a 20 das laborables y su disponibilidad es inmediata, las aplicaciones tienen soporte tcnico por el fabricante una vez adquirida su licencia a como lo estipula la ley de derechos de autor vigente, mayores detalles en el apartado de factibilidad legal. Con todos estos datos se proceder a cuantificar la inversin, evaluar las opciones y determinar la modalidad de contratacin ms ventajosa.
2.
Anlisis Comparativo En primer lugar se establecer el monto de inversin inicial, que incluye gastos
por nica vez, y luego, el cargo mensual del nuevo centro de costos. El cargo inicial del proyecto para que este pueda ser puesto en marcha, est compuesto por los conceptos de Dotacin de Personal, Hardware, Software, Mobiliario, Instalacin Elctrica y Sistema de Seguridad, los costos de elementos fsicos y hardware considerados para los elementos que estn disponibles en la empresa se sustituyen por valor cero ($0.00) para el anlisis comparativo, en el caso del software se establece valor nulo para el software ya licenciado, as el costo total de adquisicin al que ascienden las opciones A y B aparecen a continuacin:
65
Tabla IV-9.- Costos Comparativos de opciones de compra Concepto

Dotacin de Personal Hardware Software Mobiliario Instalacin Elctrica
Opcin A
$11,725.00 $10,670.00 $1,107.40 $40.00 $60.00
Opcin B
$11,725.00 $8,678.55 $1,107.40 $40.00 $60.00
TOTAL
$23,602.40
$21,610.95
Los costos mensuales estimados, estn dados por los conceptos de suministros para los equipos y del personal de mantenimiento y estos estn en relacin directa con el uso que se haga del Data Warehouse, un estimado de dichos costos aparece en la siguiente tabla:
Tabla IV-10.- Costos mensuales del proyecto Concepto
Suministros Personal de Mantenimiento
Valor total
$30.00 $400.00
TOTAL
$430.00
3.
Anlisis Costo Beneficio Los beneficios que se obtienen del data Warehouse no son cuantificables en
trminos monetarios, pues su valor reside en el soporte a la toma de decisiones. Cuando el data Warehouse entre en produccin existir una variedad de maneras en que los usuarios sern capaces de extraer informacin del sistema, ya que los usuarios tendrn la capacidad de efectuar reportes para sus fines especficos o darle tratamiento a informacin que ciertamente es confiable y veraz, para utilizarla de base en la toma de decisiones. Los principales beneficios derivados de la construccin de un Data Warehouse son: La obtencin de una plataforma que consta de una mejor calidad de datos y de ms fcil acceso, que solucione la problemtica de los niveles de decisin de la empresa, de no poder acceder a la informacin de su inters al no estar sta disponible. Hacer que el proceso de toma de decisiones sea ms acertado al estar basado en hechos y no en la intuicin o en datos de dudosa calidad.
66

Facilitar un acercamiento a los clientes al descubrir aspectos desconocidos de ellos como su patrn de comportamiento, preferencias y quejas. La construccin de un ambiente donde no es necesario un basto conocimiento tcnico para realizar consultas y elaborar reportes que satisfagan las necesidades de informacin, relevndose as la utilizacin de parte del personal tcnico de la organizacin para satisfacer necesidades especificas de los usuarios.
Proveer un repositorio de datos limpios de los sistemas de procesamiento transaccional contra el que se pueden realizar consultas sin necesariamente requerir un cambio en los sistemas transaccionales. Estos datos pertenecen a un intervalo de tiempo mucho mayor que el que pueden manejar con eficiencia los sistemas transaccionales haciendo posible anlisis de tendencias y de otros tipos.
Ganar competitividad y una mejor posicin en el mercado con la implementacin de un sistema estratgico que le d ventajas competitivas reales a la organizacin. El valor monetario de una decisin bien tomada es difcil de conocer en avance,
pero experiencias similares alrededor del mundo aseguran que si un data Warehouse es bien implementado y se encuentra en explotacin el retorno a la inversin es halagador. El costo total estimado para la primera fase de este proyecto es de $23,602.40 para la primera opcin, y de $21,610.95 para la segunda, pero los beneficios obtenidos indudablemente justifican tal inversin dado que la organizacin funcionar de una manera ms eficaz y gil, produciendo un alto retorno a la inversin. En este estudio se han ahorrado las consideraciones sobre la seguridad fsica de los equipos de cmputo que albergarn al Data Warehouse, debido a que se encuentra fuera de los objetivos y alcance de este estudio. Se da por sentado que al ser el Data Warehouse un activo estratgico de una organizacin las medidas para su proteccin sern igual o incluso ms meticulosas y cuidadosas que las que se tomen para proteger el entorno transaccional. Las medidas que apliquen en cada empresa estarn en dependencia directa de su situacin organizacional. Para el caso de la empresa objetivo, la localizacin fsica del Data Warehouse ser en las instalaciones del centro de cmputo de la empresa, el cual fue previamente acondicionado con las condiciones y polticas de seguridad que amerita el entorno
67
tecnolgico operativo de la financiera, motivo por el que no se considera como parte de los costos del proyecto los costos de seguridad fsica. Consideraciones sobre la Contratacin de un Servicio Externo de Computacin La opcin de outsourcing para la elaboracin de un proyecto de DW para la empresa en cuestin no presenta una ventaja en costo beneficio, debido al alto costo de los profesionales expertos en la tecnologa de Data Warehousing, los cuales tendran que ser reclutados en el exterior. Esto trae consigo adems de costos de desarrollo, problemas con el mantenimiento. En cambio es posible contratar al profesional que desempear el rol de Director de Proyecto para que gue y coordine al grupo base conformado de recursos humanos pertenecientes a la empresa, los cuales tienen la ventaja de conocer ya la situacin y contexto de la organizacin. Adems, se evita la problemtica con el mantenimiento.
D.
Factibilidad Legal Se deben considerar conceptos legales externos a la institucin, como parte de
la factibilidad de un proyecto, para ello se toman en cuenta las leyes vigentes en este momento en el pas que pueden afectar el desarrollo de un proyecto de Data Warehouse, por lo que es necesaria su consideracin. Las leyes a discutir son: La ley de Derechos de Autor Ley de Derechos de Autor aprobada por la Asamblea Nacional de la Repblica de Nicaragua y publicada por el diario oficial La Gaceta en su edicin del treinta y uno de Agosto de mil novecientos noventa y nueve. El marco legal de esta ley afecta directamente al proyecto ya implica la utilizacin de recursos de informticos de Software como parte integrante del proceso de desarrollo del Data Warehouse, los cuales estn protegidos por la ley de derechos de autor y derechos de propiedad. El corolario, de lo expuesto en la ley se traduce en disposiciones para la adquisicin y legalizacin de todo producto informtico que deba utilizarse y que se encuentre protegido por la Ley de Derechos de Autor para no ser ilegal o sujeto de duda.
68
Segn la Ley de Derechos de Autor en su arto.2 prrafo 2.26 se define un programa de cmputo como un conjunto de instrucciones expresadas mediante palabras, cdigo, grficas, diseo o en cualquier otra forma, que al ser incorporadas en un dispositivo de lectura autorizada, es capaz de hacer que un ordenador, aparato electrnico o similar capaz de elaborar informaciones y que ejercite determinado resultado. Tambin forma parte del programa su documento tcnico y sus manuales de uso. Luego en el arto.13 de esta ley se establece que estn protegidas por la ley todas las creaciones originales y derivados literarios, artsticos, cientficos independientemente de su gnero, mrito, forma actual o futura tales como [...], programas de cmputo, sean stos programas fuentes o programas objetos y cualquiera que sea su modo o forma de expresin. Capitulo VI se expresa otra regulacin importante de ser tomada en cuenta: La Transmisin de Derechos Patrimoniales, en el arto.52 expresa que cuando se trate de una obra realizada por un actor por cuenta de persona natural o jurdica en el marco de un contrato de trabajo y de su empleo, salvo disposicin en contrario del contrato, el primer titular de los derechos morales y patrimoniales ser el autor, pero los derechos patrimoniales sobre dicha obra se considerarn transmitidos al empleador en la medida justificada por las actividades habituales del empleador en el momento de creacin de la obra. La Ley de Derechos de Autor obliga a todo aquel que haga uso de programas de cmputo a adquirir las debidas licencias, para no infringir dicha ley, ni ser objeto de multas por su desobediencia. El presente proyecto requiere de la adquisicin de diversos programas de cmputo para su desarrollo. En la mayora de los casos ya se cuenta con la licencia requerida para dichos programas de cmputo, pues fueron previamente adquiridos por la institucin, pero en algunos otros se debern adquirir durante el desarrollo. Conclusin: La Ley de Derechos de Autor involucra que todas las aplicaciones a utilizarse en el proyecto deben de ser debidamente licenciadas y registradas. En caso contrario la
69
empresa se ver expuesta a la aplicacin de multas sobre el mbito del cumplimiento de tal normativa. Los derechos de autor sobre el Data Warehouse desarrollado son propiedad intelectual exclusiva de la empresa que lo desarrolle. Otras Consideraciones: Sigilo Bancario La informacin personal de clientes que se pueda alojar en el Data Warehouse, es para uso exclusivo de la empresa y no puede ser divulgada o vendida a terceros en carcter detallado e individual segn lo establece la regulacin de sigilo bancario sobre las instituciones financieras. Daos a Terceros La empresa no se hace responsable por los inconvenientes que pueda ocasionar a sus clientes si estos resultaran seleccionados como pblico de campaas publicitarias basndose en la informacin que la empresa tiene sobre sus clientes. La empresa no se hace responsable de la informacin errada que el cliente pueda haber proporcionado, ni de las consecuencias que de este hecho se deriven.
E.
Sugerencia para el proyecto Es recomendable la seleccin de la opcin A para la inversin ya que es muy
atractiva desde el punto de vista de desempeo versus monto invertido, sin embargo la opcin B es una alternativa un poco ms econmica, sin que ocurra una disminucin muy significativa en el desempeo. La opcin de outsourcing para este proyecto debe ser estudiada con cuidado, para no elevar significativamente el monto total a invertir en el proyecto. Es importante, para asegurar el xito del proyecto definir un adecuado programa de capacitacin para el personal de la institucin que intervendr en el mismo.
70
V.
GUA METODOLGICA PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE La esencia del Data Warehousing en s, es una metodologa no una tecnologa,
es una metodologa para alcanzar soluciones a los requerimientos de informacin del negocio. La gua metodolgica no pretende ahondar o explicar los conceptos abordados con mayor o menor amplitud en el marco terico sino ms bien componer con los conceptos destilados un nuevo enfoque reconciliado que dirija a los noveles en su camino para determinar la estrategia de Data Warehouse que mejor se adapte a sus necesidades. Para determinar que metodologa o enunciado de metodologa conviene incluirse en la gua, adems de ser acorde al objetivo del desarrollo, debe de tomar en cuenta los siguientes propsitos que sirven de base para mantener viable un proyecto de desarrollo Data Warehouse: 1. El retorno a la inversin debe ser lo ms pronto posible. Es esencial que al invertir en un entorno analtico la empresa vea resultados del esfuerzo y los utilice en el menor perodo de tiempo. 2. El Data Warehouse debe pasar a ser un activo estratgico de la organizacin rpidamente, los beneficios obtenidos del Data Warehouse deben poner en ventaja estratgica a la empresa. 3. Los costos de mantenimiento deben reducirse al mnimo. Si los costos de mantenimiento son muy elevados, producto de una mala concepcin y planeacin del proyecto de data Warehouse, este no ser rentable, ni seguir siendo viable y fracasar. En este punto es importante destacar lo siguiente: Al iniciar un proyecto de Data Warehousing no se debe olvidar establecer una base slida para el desarrollo, un marco de referencia para la construccin del Data Warehouse: la arquitectura de la implementacin, como la llama Kimball. En el proceso de construccin se puede distinguir dos etapas principales: adems de la definicin de una arquitectura Data Warehouse, la construccin de los incrementos de Data Warehouse.
71
La gua entonces, est estructurada en etapas ms que en pasos, pues los pasos pueden variar en cada proyecto, pero no as las etapas que este involucra. 1. 2. 3. 4. Etapa 1: Anlisis y Comprensin del Entorno Analtico Etapa 2: Definicin de una Arquitectura Etapa 3: Enriquecimiento de Datos Etapa 4: Construccin en Incrementos, Data Marts El desarrollo de la presente gua, ha sido acompaado de su puesta en prctica en una institucin financiera de tamao mediano que opera en el mbito nacional, bajo la modalidad de un proyecto piloto para la introduccin de una plataforma analtica que brinde ventajas competitivas a la organizacin. El desarrollo mencionado servir entonces para propsitos ilustrativos de cada etapa de la gua. En el entorno operativo de dicha institucin financiera, en la cual se desarrolla el proyecto piloto que servir de ejemplificacin, se presentan ciertas condiciones organizaciones que influye y determinan en cierta medida los ejemplos que se detallan para ilustrar la gua. Con miras a lograr la adecuada comprensin de los ejemplos presentados se debe considerar los siguientes elementos: 1. La institucin financiera consta de ms de una sucursal. Todas las sucursales son totalmente operativas. 2. El principal rubro de operacin de la financiera lo constituyen los crditos otorgados a los clientes. Los clientes disponen de una variedad de productos financieros entre los cuales pueden escoger el que mejor les convenga a sus intereses. 3. Todo crdito gestionado est a cargo de un analista de crdito que realiza los trmites que la empresa requiera e interacta directamente con el cliente. 4. La plataforma tecnolgica operativa est compuesta por Microsoft Windows 2000 Server como Sistema Operativo de Servidores y Microsoft Windows XP en las estaciones de trabajo, Microsoft SQL Server 2000 es el Sistema para Gestin de Bases de Datos, una aplicacin que consta de siete mdulos desarrollada con Visual Fox Pro 7.0 denominada LFS como sistema transaccional y una aplicacin en Clipper encargada de administrar la planilla.
72
Una vez establecido el marco de trabajo del presente estudio se abordan a continuacin las etapas de la gua con ejemplificacin de su aplicacin en la institucin financiera.
A.
Etapa 1: Anlisis y Comprensin del Entorno Analtico Como en cualquier proyecto y mucho ms en aquellos de gran envergadura
como un Data Warehouse, al iniciarlo hay que establecer slidas bases tericas que permitan vislumbrar un plan de accin efectivo y que minimice el riesgo de fracaso y dominar, adems los elementos y herramientas que intervendrn en el desarrollo de dicho proyecto. El desarrollo de un Data Warehouse no debe ser iniciado mientras no se tenga suficiente dominio sobre la filosofa detrs del proyecto, la forma en la que se puede realizar y cuales son los objetivos que se pretende alcanzar, este es el mapa que dirige el camino del proyecto. Para un Data Warehouse es prioritario reconocer las necesidades analticas que tiene una organizacin y establecer los objetivos que se persiguen al desarrollar un Data Warehouse en la organizacin en la que se desarrolle. Este es el primer paso a seguir, el anlisis y la comprensin del nuevo entorno, el entorno analtico. Esta etapa se debe cubrir con miras a cumplir los siguientes enunciados: 1. Entender las principales diferencias entre un Data Warehouse y un sistema transaccional. 2. Establecer y delimitar la diferencia entre un Data Warehouse Corporativo y los Data Marts, asimilar el objetivo de los distintos enfoques y su aplicacin a la situacin de la empresa. 3. Reconocer que patrones han sido exitosos en la industria y los errores que se han cometido. 4. Identificar y comprender las distintas herramientas a utilizar en las distintas etapas del desarrollo, asimilar las tcnicas de modelado utilizadas en el Data Warehouse o en los Data Marts y otros instrumentos. 5. Identificar y establecer qu es lo que los directores de la organizacin esperan obtener con la implementacin del proyecto. 6. Determinar la viabilidad del proyecto mediante la realizacin de un Estudio de Factibilidad.
73
Al iniciar el proyecto en la institucin financiera se tom en consideracin que requisitos expuestos en los primeros cuatro enunciados se cumplen con la comprensin y el dominio logrado sobre la teora y metodologas de Data Warehousing expuestas en el marco terico, mediante el cual se analizaron y comprendieron los distintos enfoques de un proyecto Data Warehouse, as como las caractersticas y beneficios que un entorno analtico brinda a una empresa. Luego, para determinar la situacin de la empresa e identificar las necesidades de informacin de los encargados de administrar el negocio, se utiliz como herramienta de recopilacin de datos, entrevistas aplicadas a nivel gerencial dentro de la empresa [Ver detalles de entrevistas en Anexo D]. La realizacin de entrevistas tiene un doble propsito para fines del proyecto, no solo permite obtener informacin de primera fuente y asegurar que se obtienen impresiones y necesidades que no estn plasmadas en ningn documento, sino que adems introduce el concepto de Data Warehouse en aquellos que tienen poder de decidir y que sera muy til tener como apoyo. As se logr averiguar sobre los siguientes aspectos medulares: 1. Objetivos de las distintas reas involucradas en el proyecto. 2. Prioridades de cada una de ellas. 3. Factores crticos de xito. 4. Decisiones ms relevantes y frecuentes. 5. Informacin Clave para dirigir el negocio. 6. Indicadores del estado del Negocio. 7. Reportes de uso ms frecuente. 8. Informacin crtica faltante. 9. Frecuencia de uso de informacin. La alineacin de la estrategia de negocios con la estrategia del Data Warehouse y la eleccin de una metodologa slida con los correctos entregables son aspectos crticos de una estrategia de Data Warehouse, por eso es importante que la mayor cantidad de personal que explotar al Data Warehouse sea involucrada en este proceso de recopilacin de informacin.
74
En esta etapa del proyecto an no se puede conocer cual ser el objetivo de la primera entrega del proyecto, por lo que es importante tomar en cuenta todas las reas de la organizacin. En la institucin financiera donde se aplic esta gua, las entrevistas fueron efectuadas en las reas de Crdito, Finanzas, Mercadeo, Sistemas y la Gerencia General. Es en esta etapa inicial cuando es adecuado realizar un Estudio de Factibilidad para estudiar la viabilidad del proyecto, dicho estudio para este proyecto fue presentado previamente, en el apartado anterior. Vale la pena aclarar que dicho estudio refleja un proyecto completo de Data Warehouse con sus costos reales y ejecutado por profesionales del rea de Data Warehousing, y servir de marco de referencia para determinar cuales seran los costos en los que incurrira un proyecto de esta envergadura en una empresa de tamao mediano en el contexto nicaragense.
B.
Etapa 2: Definicin de una Arquitectura. Una Arquitectura Data Warehouse establece el marco de trabajo, estndares y
Arquitectura Data Warehouse procedimientos a seguir para la construccin de un Data Warehouse a nivel empresarial. El objetivo de las actividades de la arquitectura es simple, integrar al Data Warehouse las necesidades de informacin empresarial. Ningn proyecto de Data Warehouse a ninguna escala puede ser exitoso si la base sobre la que se erige no es slida, sin que represente las necesidades de la organizacin y sin que permita el mejor aprovechamiento de los recursos disponibles. Los tres autores abordados brindan amplias descripciones sobre como debe ser una arquitectura de Data Warehouse, pero es Ralph Kimball quien en este aspecto propone la arquitectura estructurada y de ms sencilla comprensin, que previamente se introdujo en el Marco Terico. Para quienes nunca han participado en una proyecto de las caractersticas de un Data Warehouse, es difcil conceptuar claramente el objetivo que se persigue cuando se indica que se debe establecer una arquitectura slida, contando solamente con las referencias tericas y abstractas que detallan los otros dos autores. As que se escoge la arquitectura propuesta por Kimball debido a su pragmatismo, aplicabilidad y ms fcil
75
concepcin lo que lo convierte en un recurso valioso para detallar los distintos elementos que componen la arquitectura de un Data Warehouse. Esta arquitectura y sus resultados pueden, sin embargo, ser alcanzados utilizando algunas tcnicas muy apropiadas apuntadas por los otros autores. Resultados de la Arquitectura De los elementos podemos destacar como principales resultados de la aplicacin de la arquitectura de Data Warehouse los siguientes entregables, previamente abordados con mayor detalle: 1. El modelo de datos fuente. 2. El modelo de datos conceptual Data Warehouse. 3. Arquitectura tecnolgica Data Warehouse. 4. Estndares y procedimientos para desarrollo y mantenimiento del Data Warehouse. 5. El plan de implementacin incremental para el Data Warehouse. 6. Definicin a distintos niveles de los componentes del Data Warehouse. Los modelos de datos proveen una estructura para identificar, nombrar, describir y asociar los componentes de una base de datos. En general se necesitan modelos de datos para los datos fuente como para los datos seleccionados para existir en el Data Warehouse y la estructura que estos presentarn en el nuevo entorno. El primer entregable de esta etapa consiste en el establecimiento del modelo de datos fuente, en este aspecto Inmon introduce el anlisis al Diagrama Entidad Relacin de la empresa y a los distintos elementos del desarrollo de sistemas transaccionales para identificar elementos de inters del proyecto de Data Warehouse. Para los propsitos de desarrollo del proyecto en mencin, esto es muy adecuado y como resultado de su ejecucin se pudo comprobar que el estudio inicial de modelo de datos de la organizacin permite que se obtenga el dominio necesario del mismo para poder desenvolverse con soltura en las etapas sucesivas del mismo. El modelo de datos de una organizacin puede estar ms o menos normalizado y en ocasiones presentar cierto grado de redundancia o derivacin de datos con el objetivo de suplir ciertas necesidades de informacin. Es aconsejable identificar estos aspectos para
76
seleccionar solamente los datos originales ya que estos son ms fiables que los derivados y son una buena pista para reconocer informacin importante para la empresa. En la Ilustracin V-1 se puede apreciar una muestra del Modelo de Datos del Sistema Transaccional de la financiera sobre la que se aplic la gua y en la cual se distingue claramente que el modelo no est normalizado. Aqu cabe hacer un sealamiento sobre la presencia de llaves inteligentes (el campo ccodcta es compuesto) y sobre los nombres de campos nada descriptivos (csececo significa sector econmico), propios de los sistemas transaccionales, pues facilitan la programacin de aplicaciones, pero que impide deducir el significado de los datos contenidos en el campo.
Ilustracin V-1 Modelo de Datos de una Financiera
El modelo de Datos presentado en la Ilustracin V-1, se model utilizando la herramienta CASE Erwin/ERX 3.5.2 debido a que entre sus funcionalidades permite
77
efectuar Ingeniera en Reversa sobre la base de datos objetivo y determinar su modelo de datos, tambin influy su simple, pero clara forma de presentar el diagrama del modelo de datos, para una interpretacin ms fcil. El anlisis realizado en esta etapa permiti adems, identificar algunas problemticas del modelo de Datos inicial de la empresa que deben ser solucionadas como por ejemplo, presencia de tablas temporales para realizar consultas y redundancia que podra afectar la integridad entre otras. Esto es originado porque un nico entorno est supliendo las necesidades transaccionales y analticas, situacin que cambiar con la presencia de un Data Warehouse. El anlisis tambin permiti que se establezcan las bases de cambios futuros para adaptar los sistemas transaccionales al nuevo entorno que se introduce. En cuanto al modelo de datos del Data Warehouse se cuenta con dos posibles caminos a seguir. A continuacin algunas consideraciones sobre ambas opciones: Modelado Relacional: uso de Diagramas Entidad Relacin (ERD), el ERD est asociado con las leyes de normalizacin, lo que no es adecuado para el desempeo de las consultas. Otro riesgo asociado con el uso de ERD es que se vuelve un poco difusa la diferencia entre la estructura de un Data Warehouse y un sistema transaccional. Tambin se puede mencionar que un Data Warehouse relacional plantea la necesidad de contar con una plataforma extra para los data marts que sea capaz de utilizar tecnologa relacional y multidimensional. No obstante, siempre se debe recordar que en situaciones donde las cantidades de datos a manipular sean muy grandes esta solucin permite manipular cantidades ingentes de datos sin disminuir dramticamente el desempeo, en comparacin a si se utiliza el modelado dimensional. Modelado Dimensional: uso de Esquemas Estrellas o de Esquemas Copo de Nieve. Una debilidad de este modelado es que la cantidad requerida de almacenamiento crece exponencialmente, conforme se agregan nuevas dimensiones. El Data Warehouse se concibe como una composicin de Data Marts unidos por dimensiones conformadas por lo que no introduce una nueva plataforma, pero requiere de distintos procesos de poblacin de Datos para distintas estrellas, lo que conlleva a dificultad en mantener concordantes los datos cuando estos aparecen en Data Marts que cumplen distintas funciones.
78
Para decidir que tipo de modelado es ms adaptado al contexto nacional se tom en cuenta adems que la mayor parte de las empresas objetivo de la gua no generan cantidades masivas de datos; son de tamao mediano a grande, operan slo dentro del pas e implementaron sus sistemas operacionales hace menos de una dcada, esto hace que los volmenes de datos que albergue un Data Warehouse construido en este ambiente, sean modestos en escala comparativa. Lo anterior tambin es responsable de una disminucin en la consideracin de la duracin del proyecto y de las etapas de cada uno. Por lo tanto es adecuado aprovechar las ventajas del modelado dimensional y es est la opcin que se aplica en el desarrollo del proyecto de la institucin objetivo de la aplicacin de la gua. En sntesis, en lo correspondiente al tipo de modelado del Data Warehouse la solucin apropiada para el propsito de esta gua es modelar los datos dimensionalmente utilizando el esquema estrella siempre y cuando las cantidades de datos a manipular no impliquen un volumen de datos tan grande que vuelva ms complicada la solucin que el problema, al evitar se alcance uno de los principios del Data Warehouse su disponibilidad rpida de informacin para soporte a la toma de decisiones y se vuelva lento el acceso a la informacin, en el caso de que la cantidad de datos se prevea crezca en demasa se puede contemplar el modelado copo de nieve o segn el caso el modelado relacional. Una vez elegido como mtodo el modelado dimensional se debe elegir que Data Mart ser el primero en desarrollarse, para esto se utiliza la matriz de arquitectura del Data Warehouse, que se describi en el Marco Terico. La matriz de Data Marts muestra la relacin entre los posibles Data Marts y las dimensiones. Cualquier columna con ms de una X implica que sta dimensin debe ser conformada a travs de mltiples Data Marts para que pueda caber en el Data Warehouse. Basndose en los resultados obtenidos de las entrevistas realizadas, se pudo concluir que los tpicos de mayor inters para la financiera objeto son: Colocacin, Recuperacin y Mora, los cuales corresponde cada uno a un Data Mart y fueron marcados con ** en la matriz de la Tabla V-1, ya que fueron seleccionados para ser implementados en el primer incremento debido a la naturaleza crtica de estos tpicos para la empresa. Estos luego se pueden consolidar como un primer incremento de un nico Data Mart al que se denominar Gestin de Crditos.
79
Tabla V-1 Matriz de Data Marts

Fecha_Vencimiento
Data Mart **Recuperaciones **Colocaciones **Mora Rentabilidad Productividad Promociones de Mercadeo Cobranzas Embargos Quejas
X X X X X X X X X
X X X
X X
X X
X X X X
X X X X X
X X X X X
X X X X
X X X X X X
X X X
X X
X X
X X X X X
X X X
X X
Un aspecto importante de utilizar la matriz de la arquitectura es que permite realizar el modelado de las dimensiones que se incluyan en el primer incremento, de manera que sea conforme con todos los data Marts que la utilizarn. En la matriz de la Tabla V-1 es obvio que los temas elegidos a implementar en un nico Data Mart comparten muchas dimensiones, lo cual se debe a que son temas complementarios y por eso se consider adecuado y beneficioso para la empresa que su desarrollo se consolide en un nico incremento. En adicin se hace patente que dimensiones como Fecha deben ser diseadas con cuidado, pues de ello dependa que los siguientes incrementos las puedan utilizar y se relacionen sin problemas para juntos consolidar el Data Warehouse Corporativo de la organizacin. A continuacin, una vez elegido el Data Mart, el modelado puede iniciarse con una abstraccin para visualizar las dimensiones y los hechos y las estructura de cada estrella y luego dar paso a las definiciones formales del modelo lgico y fsico que presentar la base de datos del Data Warehouse. El modelo fsico, contrasta con el modelo lgico en que este es dependiente de la plataforma tecnolgica seleccionada y por lo tanto se podr disponer o no de ciertas capacidades dependientes de la implementacin.
Circunstancia
Fuente Finan
Fecha_Final
Modo Pago
Cuenta LM
Convenio
Producto
Sucursal
Garanta
Analista
Cliente
Fecha
Tasas
Hora
80
En el desarrollo del proyecto ejemplo, la abstraccin mencionada previamente, tiene el aspecto mostrado en la Ilustracin V-2, en la que se muestra un esquema sencillo que permite visualizar para una dimensin su elemento clave y tambin el resto de informacin que la acompaa. La dimensin mostrada es la dimensin fecha siendo su elemento clave o de mayor detalle del da y los dems atributos de la dimensin el mes, ao y otros ms.
Error! Ao Fiscal Ao Calendario Trimestre Calendario
Trimestre Fiscal
Ao Fiscal
Mes Calendario
Semana Fiscal Tipo de Da Semana Calendario
Da de Semana
Da
Festivo
Ilustracin V-2- Dimensin Fecha
Este esquema es sencillo y de fcil interpretacin, sin embargo se puede utilizar otro tipo de herramientas grficas o de esquemas para la representacin siempre y cuando se logre el objetivo de tal prctica que es determinar la composicin de las dimensiones, de las tablas de hechos y sus relaciones, siguiendo el esquema de cuatro pasos detallados por Kimball para el modelado dimensional y que se puede encontrar en el marco terico. En el desarrollo del proyecto piloto, luego que se tuvo clara la forma que deban de disearse el Data Warehouse para representar las necesidades de informacin de la compaa, era necesario pasar al siguiente nivel y definir de manera formal el diseo lgico
81
en un diagrama de entidades que presentar cada uno de los campos que contiene cada tabla de hecho o dimensin, el nombre lgico que recibirn y las llaves primarias de cada tabla. El siguiente paso es transformar el Diagrama de Entidades al diseo fsico que le corresponde, este diagrama adems mostrar las caractersticas de los campos en dependencia del tipo de dato que debe albergar (tipos de datos y longitud, por ejemplo). En la ejecucin de este nuevo procedimiento, se hizo uso de la herramienta Oracle / Designer 2000. Esta eleccin obedece a las bondades de la aplicacin de permitir pasar de una definicin de alta abstraccin como un Diagrama de Entidades, hasta el script de definicin para la generacin de la Base de Datos, segn la plataforma destino que se haya elegido, sin ms entrada de datos que la necesaria para realizar el diagrama de entidad, en el que tambin se indica que tipo de datos y longitud contendr el campo. Designer tambin permite el trabajo en equipo, donde dos o ms diseadores pueden estar trabajando sobre las mismas entidades y elementos sin corromper el diseo. Su salida grfica es sencilla y muy descriptiva, lo que facilita la interpretacin de los diagramas. La Ilustracin V-3 muestra una parte del diagrama de entidades para la financiera ejemplo, se pueden observar algunas dimensiones importantes como Cliente, Analista, Producto y una tabla de hechos, la tabla de Abonos de Crditos que se encuentra en el extremo izquierdo. Como se muestra claramente en la Ilustracin V-3, el diseo del Data Warehouse dista mucho del diseo del sistema transaccional y como ejemplo puedo nombrar las tablas de Cliente_Dim y Abono_Credito_Fact, que corresponden a una dimensin y una tabla de hechos respectivamente.
82
Ilustracin V-3 Diagrama de Entidades
En el primer caso, siguiendo las etapas de la gua y para obtener la tabla clientes, se tuvo que tomar en cuenta adems, la situacin encontrada en la institucin objetivo, en la cual existen muchas inconsistencias entre los datos, como problemas de duplicacin de cdigos para clientes, por lo que un mismo cliente puede presentar en algunos casos dos o ms cdigos asociados, lo que provoca se genere informacin errada sobre algunos indicadores de la empresa como la cartera de clientes de la institucin y el promedio de crditos por cliente; para solucionar esta complicacin se introdujo un nuevo cdigo que permita que cada cliente tenga un identificador nico lo que habilita que la informacin de la empresa sea correcta. Para el caso de la tabla de hechos, se consider importante por ejemplo incluir una referencia a la dimensin hora, lo cual se hace introduciendo una llave externa a dicha dimensin, por que esto permite luego obtener informacin como a cuales horas ocurre el mayor movimiento de caja y esto puede servir para habilitar cajas temporales en ese perodo o redoblar la vigilancia en la oficina y brindarle mejor servicio al cliente. Tambin
83
se observ que dada la situacin particular del pas en donde la moneda nacional se desliza de manera diaria en comparacin con el dlar, era necesario indicar de forma separada el monto abonado en este concepto y que no se incluya en ninguno de los otros conceptos, ya que de lo contrario no se podra conocer el impacto, que para la empresa tiene una poltica monetaria de pas como sta y tambin se podra dar la impresin que el total recuperado es mucho mayor que las cantidades desembolsadas a los clientes originalmente.
Leyenda: Obligatorio
Opcional
789 Numrico
A Carcter
31
Fecha
Ilustracin V-4 Diseo fsico de la base de datos del Data Warehouse
En el diseo fsico de la financiera, como se puede apreciar en el diagrama de la Ilustracin V-4, no se indican las relaciones que existen entre las tablas, esto es por una consideracin al desempeo del Data Warehouse. La presencia de relaciones propia de las bases de datos normalizadas trae consigo la verificacin de integridad referencial, esta verificacin tiene como costo la disminucin de desempeo cuando se realiza la carga del
84
Data Warehouse. Se ha decidido que el mecanismo de identificar relaciones para asegurar la integridad referencial no es necesario puesto que los datos que llegan al Data Warehouse son originados en sistemas transaccionales que fueron los encargados de realizar la verificacin. Para informacin completa acerca del modelo de datos y tambin del diseo lgico y fsico de la base de Datos, referirse al anexo de Modelado donde aparecen todos los documentos producidos para el Modelo de Datos del Data Warehouse. Las consideraciones de requerimientos de la arquitectura tecnolgica necesaria para implementar un Data Warehouse en el contexto de las empresas nicaragense ya descrito son expuestas en el estudio de factibilidad detallado en el anexo respectivo. Los estndares para el desarrollo del Data Warehouse son una parte importante de su arquitectura. Sin estndares, oportunidades para re-usar no son posibles y hay riesgos de que partes del desarrollo no funcionen trabajando juntos. Los estndares aseguran que todos los involucrados en el desarrollo de proyecto cuenten con un marco que les ayude a interactuar positivamente. Para est implementacin en la financiera, los estndares utilizados son con respecto a nomenclatura de campos, de paquetes de transformaciones de datos, y en cuanto al diseo de dimensiones conformadas. Los estndares para el desarrollo de rutinas en lenguajes de programacin no se lograron concretar por carecer de este concepto en la financiera, al no contar con estndares los sistemas transaccionales, la implementacin organizacional de estndares de codificacin escapaba al objetivo de ejemplificacin de la gua del proyecto dentro de la financiera. Solamente se hizo uso de las buenas prcticas de programacin estructurada y de comentar el cdigo fuente. Ver anexo G con definiciones sobre las rutinas ETL. El plan de implementacin Data Warehouse es la parte de la arquitectura de Data Warehouse que identifica los incrementos del Data Warehouse y describe la secuencia de desarrollo de estos incrementos, as se aprovechan los esfuerzos que se realicen para los incrementos posteriores.
85
La definicin de los componentes indica las tcnicas a utilizar para soportar, presentar y explotar la funcionalidad del Data Warehouse. Aqu se deben de tomar en cuenta polticas de la empresa y las restricciones propias del proyecto, como ejemplo: el presupuesto asignado, herramientas con que se cuentan, plataforma OLTP, cultura organizacional.
C.
Etapa 3: Enriquecimiento de Datos Enriquecimiento de Datos Los datos del Data Warehouse son integrados atravesando los mrgenes de los
sistemas de aplicacin, dichos datos son extrados de las restricciones y lmites impuestos por las aplicaciones que los originaron, luego deben ser estandarizados e integrados para proveer una perspectiva de informacin que traspasa los procesos la cual es esencial para el anlisis de utilidades. Una vez que se tiene en su lugar el modelo de datos del Data Warehouse es necesario poblar su estructura con sus datos respectivos, pero para lograr que los datos del sistema transaccional se acomoden y quepan en el entorno analtico y se conviertan en informacin, es necesario que dichos datos sufran procesos de transformacin que los reconcilien, limpien y enriquezcan ya sea dividindolos en algunos casos, fusionndolos en otros, adicionndolos, o derivndolos y que posteriormente estn listos para que cumplan apropiadamente su nuevo rol como base para la toma de decisiones. Con estos requerimientos plenamente identificados se toma en cuenta adems la situacin empresarial nicaragense, cabe destacar que las condiciones ms comunes, de los sistemas organizacionales, consiste en implementaciones que abarcan distintos DBMS y/o distintos lenguajes de programacin, otro aspecto es que la tecnologa de informacin predominante es moderna, con apenas un poco ms de una dcada de antigedad o menos en la mayora de los casos. La etapa del Enriquecimiento de Datos como se le ha designado en la gua debe proveer mecanismos para realizar la migracin de datos desde los sistemas fuente, que pueden residir en distintas plataformas y transformarlos hasta que estn en condiciones de poblar el Data Warehouse, para servir de ayuda en la toma de decisiones. Esta es la etapa ms tardada y que ms esfuerzos necesita, en lo relativo a la cantidad de trabajo por
86
realizar, dentro de un proyecto de Data Warehouse y depende directamente de la calidad de los datos de los sistemas transaccionales, de la diferencia tecnolgica entre la plataforma fuente versus la Plataforma Destino, fundamentalmente entre otros aspectos. Resultados del Enriquecimiento Para que la implementacin de esta etapa no salga fuera de control ponga en riesgo el margen de xito del Data Warehouse, es necesario determinar detalladamente el plan a seguir. Las resultas correspondientes a esta etapa son: Documento de Correspondencia Fuente Destino. Diseo del rea de Preparacin de Datos. Diseo de las rutinas de Extraccin, Transformacin y Carga de Datos. No importa cual metodologa se elija seguir en el desarrollo de un Data Warehouse, siempre se est refiriendo a la construccin de un nuevo entorno, el cual es poblado con los datos, provenientes de los sistemas fuentes, luego de ser extrados y transformados para enriquecerlos. Para facilitar el inicio del proceso de enriquecimiento de datos, es muy conveniente hacer una correspondencia entre los datos para identificar el sitio en el cual estos se originan y su campo destino en el Data Warehouse, seleccionando aquellos datos que sean ms confiables y que mejor se acomoden al nuevo entorno, un mapeo fuente destino como le llama Kimball. Para el caso de ejemplo en la financiera, la situacin es de las ms sencillas que se puede encontrar por cuanto, solo existe un sistema fuente que utiliza un DBMS relacional para gestionar la Base de datos, aunque mucha informacin se encuentra en tablas auxiliares creadas mediante la implementacin propia del sistema y que no son del dominio del DBMS sino del lenguaje de programacin con el que se desarroll la aplicacin. En cuanto a la forma en la que se puede formalizar el documento de correspondencia, este puede ser simplemente una tabla en la que se indican los campos fuente (origen) de datos, la narracin de las transformaciones que se deben aplicar hasta llegar a los campos destino y el tipo de datos del Data Warehouse, como se observa en la Tabla V-2, tambin se deben indicar el sistema origen en el caso de ser ms de uno y las
87
fuentes de datos externas que sean necesarias incluir para desarrollar la informacin pertinente en el Data Warehouse. La tabla de correspondencia completa aparece tambin en el Anexo G.
Tabla V-2 Correspondencia Fuente Destino
Tabla Destino Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Columna Destino Fecha_Clave Fecha_Vence_Clave Hora_Clave Analista_Clave Cliente_Clave Sucursal_Clave Convenio_Clave Producto_Clave Tipo de Datos Integer Integer Integer Integer Integer Integer Integer Integer Tabla Fuente Credkar Credkar Cjgdlog Credkar Credkar cremcre Credkar Credkar cremcre Credkar cremcre Credkar cremcre Credkar Credkar Credkar Credkar Credkar Credkar Credkar Credkar Credkar credppg, credgas Campo Fuente Dfecsis Dfecpro Dfectrx Ccodcta ccodcta , ccodcli Ccodcta ccodcta ccodgru ccodcta ccodpro, cdescre csececo Ccodcta Nmonto Nmonto Nmonto Nmonto Nmonto dfecpro dfecsis Cnrodoc Ccodcta Cnrocuo ncapita ncappag + intere nintpag Notas transformacin de Datos reemplazar fecha con la clave en fecha_dim reemplazar fecha con la clave en fecha_vence_dim Obtener la hora con respecto a la fecha asociar la cuenta con el analista en cremcre asociar la cuenta con el cliente en cremcre left(ccodcta,2) para el cdigo oficina asociar la cuenta con el convenio en cremcre asociar la cuenta con ccodpro, cdescre y csececo en cremcre Asociar la cuenta con datos en cremcre Elegir el cconcep con valor cj(caja) Elegir el cconcep con valor kp capital Elegir el cconcep con valor in interes Elegir el cconcep con valor '02' servicios Elegir el cconcep con valor mo mora efectuar calculo de dfecpro_dfecsis
Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts
Circunstancia_Clave Monto_Total_Abono Principal_Abono Interes_Abono Servicios_Abono Interes_Mora Dias_Mora No_Recibo_Caja No_Credito No_Cuota Monto_Total_Cuota
Integer Numeric(82) Numeric(82) Numeric(72) Numeric(72) Numeric(72) Integer Varchar(12) Varchar(12) Integer Numeric(72)
En la Tabla V-2 aparece parte de la correspondencia de datos para la tabla Abonos_Credito_Facts que guarda los hechos concernientes a la forma en que los clientes realizan abonos a los crditos que se le otorgaron. Esta tabla se corresponde principalmente con dos tablas observadas en el Ilustracin V-1, credkar y cremcre, la informacin de ambas tablas es necesaria para completar la estructura de la mayor parte de los datos que requiere la tabla Abono_Credito_Facts.
88
La correspondencia de la tabla de Abono_Credito_Facts, a la cual se le ha dado seguimiento, muestra la aplicacin de algunas consideraciones como por ejemplo en el campo de hora, a pesar de que la tabla credkar es el origen de datos de la fecha y de que el campo correspondiente es un datetime, este campo se almacena con la hora vaca, por lo que es mejor fuente de datos lo registrado en la tabla cjgdlog para el campo hora pues almacena la hora en la que se realiz el abono, que es el dato que se pretende guardar en la tabla de Abonos_Credito_Facts del Data Warehouse. Esto tambin se aplica para la clave de sucursal, que a pesar de contar con un campo ccodofi, que guarda el cdigo de la sucursal, del estudio del modelo de datos se conoce que esta informacin presenta inconsistencias, lo que motivo se decidiera mejor utilizar como fuente del dato un subconjunto de la llave inteligente del numero de crdito. Otro caso de ejemplo se puede observar que en la situacin de los campos Monto_Total_Abono, Principal_Abono, Interes_Abono, Servicios_Abono, Interes_Mora, todos tienen como origen el mismo campo Nmonto, pero ellos realmente solo toman el valor de Nmonto en funcin del valor que tome el campo cconcep, conocimiento que queda registrado en la tabla de correspondencia. El objetivo de tal documento de correspondencia es servir de gua para conocer de forma inequvoca el origen de los datos, lo cual es indispensable para el mantenimiento y durante la siguiente iteracin del Data Warehouse, para asegurar que se conoce el significado y origen de los datos y facultar la compatibilidad de ambas iteraciones. La tabla de correspondencia presenta las derivaciones y todos los tipos de transformaciones que debe sufrir un dato hasta llegar a su destino final. Este documento es fuente de metadatos, habilita a que los dems integrantes del equipo de desarrollo y en algunos casos los usuarios que lo requieran puedan comprender que significa la informacin almacenada en el Data Warehouse. Otro de los beneficios que se obtiene de elaborar este documento, es poder homogenizar el proceso de extraccin, transformacin y carga, ya que se pueden detectar fcilmente incongruencias en el procesamiento de algunos datos que deberan ser coincidentes.
89
Finalmente, es importante tener detallada la correspondencia fuente destino ya que esta documentacin sirve de gua para la definicin de las rutinas ETL y para la concepcin del rea de Preparacin de Datos. Una vez determinada la correspondencia y con el conocimiento de las transformaciones necesarias es posible disear el espacio intermedio, llmese rea de Preparacin de Datos, con el objetivo de minimizar este procesamiento y que las rutinas ETL lleven a cabo su trabajo en el menor tiempo posible, optimizando el desempeo del sistema. El Diseo del rea de Preparacin de Datos es abordado por todos los autores analizados anteriormente no obstante, a pesar de que todos coinciden en su conceptualizacin como una instancia intermedia que albergar los datos crudos o en procesamiento antes de que stos sean depositados en la estructura definitiva del Data Warehouse, las caractersticas, temporalidad y otros aspectos son dismiles para ellos. Uno la concibe como inmersa en una capa del Data Warehouse, en la capa de datos reconciliados, que es donde se solucionan las diferencias de formato, tipo de dato y organizacin de los datos provenientes de distintos sistemas fuentes, los cuales pueden ser o no compatibles, para luego convertirse en informacin. La capa de Datos Derivados representa el modelo de Datos de la organizacin y en ella es donde se almacenan todos los datos ya integrados para el Data Warehouse. Kimball no detalla mucho en ella, pero la menciona como parte de la arquitectura tcnica de la adquisicin de datos. Y finalmente Inmon, quien presenta como el rea de preparacin de Datos al Operational Data Store (ODS), un entorno en el que se integran y reconcilian los Datos de los sistemas transaccionales, pero que es voltil pues slo presenta el instante actual de los datos de negocio, cambia a la misma velocidad que los sistemas transaccionales y no cuenta con la presencia de Datos derivados, ni el contexto histrico como en un Data Warehouse, pues su objetivo es el monitoreo operacional. En est etapa de la gua se estableci la necesidad de disear el rea de preparacin de datos, porque en ella es que se integran y reconcilian los datos fuentes hasta convertirse en datos destino, pero este diseo depende en cierta medida del enfoque se le elija. En la institucin financiera ejemplo, para decidir que enfoque utilizar se consideraron adems, los objetivos del proyecto y los costos que conlleva cada propuesta.
90
Cuando el rea de Preparacin de Datos est inmersa en una capa del Data Warehouse, como propone Devlin, el rea de almacenamiento permanente requerida puede disminuir, si los datos son desechados luego de la carga. Sin embargo, hay que apreciar que sobre esta capa existe la capa de datos derivados, anloga a los Data Marts dependientes de Inmon, lo que efectivamente aumenta de forma considerable los requerimientos de almacenamiento para albergar simultneamente ambas capas, se aumenta el tiempo de desarrollo del proyecto, lo que tambin provoca una elevacin en los costos y entra en contradiccin con el objetivo de la gua de adaptarse al contexto nicaragense en el que las empresas medianas y grandes se veran en dificultad para disponer de recursos suficiente para el mantenimiento de ambas capas paralelamente. El ODS de Inmon requiere un esfuerzo similar al de desarrollar un Data Warehouse para su construccin, pero no es una plataforma para el anlisis sino de monitoreo, valga hacer la salvedad que luego que se desarrolla un ODS, la construccin de un Data Warehouse, es mucho ms sencilla pues ya se cuenta con una plataforma de datos de calidad. Si se utiliza un razonamiento anlogo al aplicado a la propuesta de Devlin, se aprecia que la introduccin de una nueva plataforma para el ODS, sin embargo, podra tener un costo restrictivo para el proyecto. Inmon aparte de la proposicin del ODS deja abierto el criterio sobre la forma en la que se deben preparar o reconciliar los datos al igual que Kimball. En la presente gua de ambas propuestas se consolid una proposicin atractiva en la que se disminuye el costo de desarrollo, la redundancia y la necesidad de almacenamiento, considerando siempre el objetivo de la gua de mantenerse en el marco empresarial nicaragense. El rea de preparacin de Datos, ser una Base de Datos de transicin que albergar los datos que estn en proceso de transformacin mientras las rutinas de ETL hacen su trabajo, hasta que stos no sean depositados en su destino final dentro del Data Warehouse, y que una vez completada la carga de datos, es limpiada de contenido, dejando solamente su estructura, a menos que alguna consideracin propia de cada proyecto indique que stos deben permanecer. Siempre se reservar cierto espacio dispuesto para contener los datos en el momento en que se estn llevando a cabo las transformaciones, para posteriormente ser liberado. No se considera una capa ms del Data Warehouse sino un espacio pre-formateado que sirve de apoyo para que los datos se
91
depositen mientras siguen su camino al Data Warehouse, que podra estar conformado de Data Marts y no en dos capas. En el Anexo F aparece la definicin del rea de Preparacin de Datos del proyecto que se utiliza de ejemplo. Pasando ahora a la siguiente resulta de esta etapa, las rutinas de Extraccin de Datos, deben ser diseadas siguiendo los estndares definidos en la arquitectura, con el objetivo de minimizar el esfuerzo necesario para implementar los distintos pasos de la ETL al Data Warehouse y que la ETL sea lo ms eficiente posible. Este aspecto es fundamentalmente importante cuando existen varias personas trabajando en el desarrollo de las rutinas de ETL para que los distintos componentes se unan y funcionen de manera apropiada. Aunque sta no es la parte ms difcil si consume mucho tiempo y recursos para definir las rutinas siguiendo los patrones ya establecido y el nivel de detalle suficiente.
D.
Etapa 4: Construccin en Incrementos, Data Marts. Construccin en Incrementos: Cualquier proyecto de Data Warehouse, en cualquier contexto, tiene mayor
probabilidad de xito si se construye mediante incrementos, que permitan que los usuarios tengan prontamente a su disposicin un subconjunto del Data Warehouse completo y se inicie la retroalimentacin y ajustes al desarrollo. Por supuesto, que no se debe menospreciar los beneficios que esta modularidad implica para las finanzas de un proyecto. Las tres metodologas abordadas, presentan aproximaciones distintas de construccin en incrementos. Inmon, por ejemplo, coloca primero todo el diseo del Data Warehouse en su lugar y luego indica la eleccin de subconjuntos del Data Warehouse Corporativo para implementar, sin embargo los usuarios solo comienzan a explotar el desarrollo del Data Warehouse, hasta que aparecen los Data Marts dependientes y eso ser hasta que se complete la construccin del Data Warehouse corporativo. Devlin presenta una propuesta parecida.
92
Kimball es radicalmente distinto desde su concepcin inicial, el Data Warehouse Corporativo surge luego de los Data Marts, cada Data Mart es un subconjunto del Data Warehouse que puede ser desarrollado de forma independiente y puesto a la disposicin de los usuarios antes de iniciar otro Data Mart. A esta altura del desarrollo de la gua, se debe considerar adems las alternativas previamente seleccionadas y puestas en prctica. Al haber escogido en la segunda etapa el modelado dimensional, se eligi tambin una aproximacin a un Data Warehouse mediante la construccin de Data Marts que utilizan dimensiones conformadas para unirse y poder funcionar como un verdadero Data Warehouse. La implementacin en incrementos del Warehouse desarrolla y genera un subconjunto del Data Warehouse total. La implementacin incremental es una aproximacin pragmtica para construir un Warehouse a un nivel empresarial en forma evolutiva. Esta es la etapa en que toda la preparacin y diseos anteriores son llevados a la realidad y puestos en funcionamiento. En esta etapa ya se vincula estrechamente el diseo de las etapas anteriores con la plataforma Hardware y Software que se decidi conformar a tomando en cuenta todo lo reflejado en el estudio de factibilidad. Resultados de Implementacin: Los resultados ms significativos obtenidos de la implementacin de un incremento Data Warehouse, incluyen: Definiciones de las bases de datos del Data Warehouse. Programas y procedimientos para extraer, transformar y cargar datos. Poblacin del Data Warehouse con los datos necesarios. Poblacin del catlogo de metadatos. Seleccin, instalacin y configuracin de herramientas de acceso a los datos. Tcnicas de uso y soporte del Warehouse. Las definiciones de las bases de datos del Data Warehouse, consisten en el procedimiento automatizado que genere la estructura de la base de datos a como se defini en su diseo en la plataforma elegida para sustentar el Data Warehouse.
93
El DBMS elegido en la financiera ejemplo es Microsoft SQL Server 2000, por lo que las definiciones de las bases de datos, usan un dialecto denominado Transact SQL, que se base en el estndar SQL92. El script que genera la Base de Datos del Data Warehouse aparece en el Anexo F. Lo que se enuncia como programas y procedimientos para extraer, transformar y cargar datos, no es ms que el cdigo fuente y los ejecutables del software necesario para realizar la ETL. Existen dos tipos de programas y procedimientos los correspondientes a la carga inicial que ocurre cuando se realiza la poblacin del Data Warehouse por primera vez y los procedimientos de la carga peridica que se encargan de mantener actualizada la informacin del Data Warehouse. De estos dos tipos de carga, la inicial y la peridica, para el propsito de esta gua se construy nicamente una parte del conjunto de carga inicial, pues la ETL es una de las partes que ms recursos se necesitan y el objetivo de ejemplificacin de la gua se cumple con seleccionar ciertas dimensiones y hechos para ser poblados y construir programas y procedimientos necesarios. Como ya se mencion, SQL Server 2000 ser el gestor de la base de datos que albergar el Data Mart de prueba que se implementa en la financiera, una de las razones por las cuales se haya tomado dicha decisin es por los Servicios de Transformacin de Datos que SQL Server 2000 presenta incluidas con la licencia del gestor y que facilita y automatiza grandemente el proceso de ETL. Los Servicios de Transformacin de Datos o DTS (como se les llama por sus siglas en Ingls), se presentan con una interfaz grfica que permite visualizar las tareas que se deben ejecutar en el proceso de carga y su secuencia de ejecucin, cada tarea sin embargo, puede corresponder a la llamada a un programa previamente desarrollado, ejecucin de sentencias SQL o ejecucin de tareas nativas de carga y transformacin de datos que realizan transformaciones de registros definidas en Visual Basic Script o Java Script. Una muestra del paquete que realiza la carga de la tabla de Hechos de los Abonos a Crditos (Abonos_Credito_Facts), se puede observar en la Ilustracin V-5
94
Cada icono representa una conexin con una Base de Datos o una tarea del DTS. Las tareas pueden ser tan sencillas como la ejecucin de una sentencia SQL o ms complejas como transformaciones de registros con base a criterios especificados con los lenguajes de sripting que soporta.
Ilustracin V-5 Paquete DTS de carga a una tabla de hechos
Para que los usuarios inicien la explotacin del Data Warehouse, ste debe contener los datos de la compaa. A pesar de todo el cuidado y dedicacin que se haya puesto en las etapas anteriores siempre habr que hacer algunos ajustes cuando llegue el momento final en que se realiza la poblacin completa por primera vez y todas las piezas pasen a ocupar su lugar respectivo y a interactuar con las dems. Luego habr que monitorear persistentemente la carga del Data Warehouse y sus componentes para que esta se est realizando libre de errores, adems de verificar su desempeo con el objetivo de hacer ajustes de mantenimiento y de optimizacin de procesos y de la base de datos del Data Warehouse.
95
Esta resulta de la construccin en incrementos, queda pendiente de realizar en la empresa financiera ejemplo, pues an no se ha terminado la poblacin completa con todas las rutinas necesarias, y mientras no se realice la carga peridica y se puedan identificar partes rutinarias que puedan ser optimizadas o mejoradas si estn presentando errores. Un elemento importante y que no debe ser dejado de un lado pues es indispensable para la adecuada gestin del Data Warehouse es la gestin de los metadatos, ya existen para esto herramientas especializadas que se encargan de ellos y les administran en un catlogo. Para que lo metadatos estn a disposicin de los usuarios y entre en funcionamiento debe realizarse la poblacin del catlogo de metadatos. Una vez en lnea esta herramienta, se logra la automatizacin de muchas rutinas y un correcto seguimiento e interpretacin de los datos contenidos en el Data Warehouse. Aqu tambin es importante destacar, como claramente expresa Devlin, que los usuarios harn uso del catalogo de metadatos para poder entender e interpretar los datos que son puestos a su alcance. Por restricciones de la naturaleza del proyecto piloto en la financiera, y algunas consideraciones de costo, el componente del catlogo de metadatos y el repositorio de metadatos, no pudo ser llevado a la prctica, esta limitante sin embargo, sirvi para verificar, que si se descuida la gestin de los metadatos o se ignora la importancia de ellos, el resultado es que el proceso de seguimiento del desarrollo del proyecto puede llegar a ser bastante complejo. En lo respectivo al mantenimiento del Data Warehouse, la ausencia de metadatos adecuados se manifiesta como la falta de una fuente de datos en formato digital extensiva y formal que pueda ser utilizada como apoyo por otras herramientas para dirigir los distintos procesos que se necesitan en la rutina diaria de un Data Warehouse, como por ejemplo la carga de actualizacin o la redefinicin de algn dato que vare con el tiempo como la tasas de inters aplicada. El proceso de seleccin, instalacin y configuracin de herramientas de acceso a los datos, determina que el front room del Data Warehouse sea concretado. Este proceso es delicado puesto que se debe tener siempre en cuenta que el front room es la fachada del Data Warehouse ante la mayor parte de los usuarios y por lo tanto mucho del xito del
96
proyecto depende de que tan bien y til sean las herramientas de acceso a datos, para que se obtenga el mayor beneficio posible del la informacin contenida en el Data Warehouse. Es necesario mencionar que las herramientas a elegir deben ser configurables hasta el punto que se puedan adaptar adecuadamente al ambiente de la organizacin y tratar de disminuir al mnimo posible la curva de aprendizaje y sin perder de vista un adecuado balance costo beneficio. En esta parte se incluye la instalacin de las herramientas en el ambiente del usuario y su preparacin para el uso. Para poner la carga de prueba en manos de los usuarios y determinar el xito del proyecto piloto desarrollado en la financiera, se utiliz como herramienta de acceso a datos un servicio propio de SQL Server 2000, cuyo nombre es OLAP Server, el cual brinda la posibilidad de gestionar multidimensionalmente cubos de datos de n-dimensiones a partir de la informacin obtenida del Data Mart. La definicin de los cubos, indica se realicen y almacenen los clculos de agregacin para cada posible combinacin de hechosdimensin que conforman el cubo. Una vez creados los cubos, estos pueden proporcionar su informacin para ser analizada a las aplicaciones cliente que as lo requieran, como los cubos fueron construidos con el Servidor OLAP de SQL Server 2000 pueden consultarse utilizando una simple hoja de clculo de la aplicacin Excel que viene incluida en la Suite Office de Microsoft. Excel utiliza para hacer consultas al cubo fuente, una tabla dinmica que tenga como origen de datos el cubo previamente definido y procesado. En la Ilustracin V-6 se puede apreciar un reporte elaborado de la forma anteriormente descrita.
97
Ilustracin V-6 Informe de Colocaciones
En la ilustracin anterior se muestra claramente que es posible obtener de forma sencilla y precisa indicadores de desempeo de una empresa, en este caso de una financiera, en tan solo una hoja, los campos que son cuadros desplegables permiten seleccionar los elementos que se quieren visualizar con solo elegirlos; por ejemplo el cuadro desplegable de estado_credito permite elegir entre crditos vigentes o cancelados en el perodo especificado que puede llegar hasta el detalle de semana o totalizar para un ao. Las tcnicas de uso y soporte del Warehouse comprenden en parte a los metadatos, pues significa plasmar en un documento tcnico la forma en que se debe dar mantenimiento al Data Warehouse y la forma en la que los usuarios deben interactuar con l para aprovechar mejor sus bondades. Al ser el Data Warehouse parte de los sistemas de informacin de una compaa es importante se realice un documento tcnico que indique la forma en la que debe mantener en produccin el Data Warehouse y otro en el que se le indique a los usuarios como debern utilizar las herramientas que se estn poniendo a su disposicin y las bases para interpretar los resultados obtenidos, para que ellos se familiaricen con la filosofa del entorno analtico y comiencen la verdadera explotacin del Data Warehouse recin desarrollado.
98
Un Data Warehouse es exitoso en la medida en que ms usuarios lo utilicen y obtengan beneficio de l, as se mejorar la situacin estratgica de la empresa en el competitivo mundo actual de los negocios.
99
CONCLUSIONES
Con esta gua se demuestran los elementos esenciales del desarrollo de un Data Warehouse con el propsito de que sirva de partida a los noveles en la materia y darle sentido a las numerosas metodologas disponibles. Existen muchas estrategias de Data Warehouse contradictorias y similares a la vez que han tenido xitos en diferentes ambientes empresariales que dificultan el aprendizaje y dominio de esta tecnologa a los noveles en la materia. Adaptar y conciliar las metodologas de Data Warehousing ms difundidas en el mercado tiene un alto sentido, pues permite la creacin de un marco de trabajo que engloba elementos cuya aplicacin adecuada ha demostrado asegurar la realizacin y utilidad de un proyecto de Data Warehouse. El desarrollo de un proyecto de Data Warehouse introduce un nuevo entorno en el cual es posible obtener informacin vital para la empresa casi instantneamente lo que habilita la toma de decisiones que mejoren el desempeo de la compaa y los rditos que sta obtiene. Adems, pone al descubierto problemticas en los sistemas transaccionales que son origen de debilidades y que deben ser solucionados. Un Data Warehouse es parte de los sistemas de informacin corporativos. La forma que cada organizacin y equipo elija para implementar las etapas de la gua y la utilizacin o no de las herramientas presentadas es decisin de los responsables de cada proyecto de Data Warehouse y estar en dependencia de lo que ms le convenga a los intereses de la organizacin. Se debe propiciar el desarrollo de proyectos del tipo de Data Warehouse como una herramienta para hacer ms competitivas las empresas nicaragenses en crecimiento, sin embargo la implementacin de un entorno analtico debe ser cuidadosamente analizado para no correr el riesgo de realizar una alta inversin y no generar beneficios para la organizacin. No hay que olvidar que la justificacin de una empresa para la inversin en la construccin de un Data Warehouse, es que el Data Warehouse suplir la necesidad de informacin estratgica que tiene la empresa y no precisamente del tamao que sta presenta.
100
Si existen porciones de una metodologa que son inapropiados para el proyecto de Data Warehouse que se este desarrollando, stas deben ser excluidas; no se debe sentir la obligacin de completar todas las partes de la metodologa que se elige implementar. La mejor opcin es consolidar un enfoque hbrido que tome en cuenta el contexto del proyecto y que permita ser lo ms efectivo en cuanto a la obtencin de una plataforma analtica que satisfaga las necesidades de la empresa, para la que se est llevando a cabo el proyecto, como se hizo con los metadatos, que quedaron fuera en el primer incremento por motivos presupuestarios.
101
RECOMENDACIONES
Las recomendaciones sirven de base para que futuros trabajos que tomen como referencia el presente estudio monogrfico, estn en mejores condiciones de poder realizarse con xito. Esto deriva del hecho de que se cuenta con la ventaja de aprovechar recomendaciones basadas en la experiencia, que sirvan para evitar cometer errores graves como menospreciar tpicos importantes que afecten considerablemente el proyecto, lo cual sin duda es valioso y se encarga de complementar las conclusiones a las que se lleg con el desarrollo. De la realizacin del presente estudio monogrfico se desprendes las siguientes recomendaciones: 1. Se recomienda la utilizacin de herramientas que permitan el seguimiento de las actividades realizadas en el desarrollo del proyecto de Data Warehouse, para facilitar su posterior mantenimiento y xito ya que si la definicin de los metadatos se deja para el final su definicin ser muy pobre y esto le resta utilidad a un Data Warehouse. 2. Se debe incluir en todo equipo de desarrollo un integrante con amplio dominio de los sistemas transaccionales y de la forma en que opera la organizacin para disminuir la duplicacin de esfuerzos aplicada a determinar la utilidad de los datos, su origen, forma y significado. 3. Se debe involucrar de la mayor manera posible al personal importante de la organizacin que har uso del Data Warehouse, para que la implementacin tenga xito en suplir las necesidades de informacin de ellos y con esto se asegura en gran parte el uso y xito del Data Warehouse. 4. No se debe menospreciar la importancia de un buen diseo de la ETL, pues aun con un buen diseo, en la implementacin surgen imprevistos y elementos no tomados en cuenta originalmente, lo que puede alargar el proceso ms de lo estimado poniendo en peligro la continuidad del proyecto.
102
5.
Se recomienda aplicar la metodologa de Ralph Kimball a proyectos de Data Warehouse que tengan un tamao moderado, por motivos de costo, tiempo y menor riesgo de fracaso, adems de permite priorizar las reas de mayor necesidad de la compaa para ser desarrolladas en el Data Warehouse.
6.
Es recomendablemente utilizar la metodologa de Inmon para modelar los datos de una organizacin, cuando el proyecto desde su primera entrega, implique la inclusin de ms de tres o cuatro departamentos o ms de un sistema transaccional como fuente de informacin, porque en estas condiciones aumenta el trabajo necesario para integrar, reconciliar y enriquecer los datos, y la metodologa de Inmon ayuda a disminuir el riesgo en este tipo de ambientes delicados de construir incrementos que posteriormente no se puedan integrar.
ANEXO A: INDICES DE ILUSTRACIONES Y TABLAS
INDICE DE ILUSTRACIONES Ilustracin I-1 Diferencias entre Sistemas Operacionales y Data Warehouse...................... 4 Ilustracin I-2. Arquitectura de tres capas............................................................................. 8 Ilustracin I-3. Estructura BII. ............................................................................................. 12 Ilustracin I-4. Estructura BIG ............................................................................................ 14 Ilustracin I-5. Metodologa Data Warehouse de Inmon..................................................... 23 Ilustracin I-6 Ciclo de Vida Dimensional para implementar un Data Warehouse............ 27 Ilustracin IV-1 Organigrama.............................................................................................. 60 Ilustracin V-1 Modelo de Datos de una Financiera........................................................... 76 Ilustracin V-2- Dimensin Fecha ....................................................................................... 80 Ilustracin V-3 Diagrama de Entidades............................................................................... 82 Ilustracin V-4 Diseo fsico de la base de datos del Data Warehouse .............................. 83 Ilustracin V-5 Paquete DTS de carga a una tabla de hechos ............................................ 94 Ilustracin V-6 Informe de Colocaciones............................................................................. 97
INDICE DE TABLAS Tabla I-1.- Diferencias entre Data Warehouse y las Bases de Datos Estndar .................... 5 Tabla I-2. Marco de Trabajo de la Arquitectura.................................................................. 33 Tabla III-1 Empresas en Nicaragua ..................................................................................... 50 Tabla IV-1 Requerimientos de Data Warehouse .................................................................. 54 Tabla IV-2 Alternativas de Adquisicin ............................................................................... 56 Tabla IV-3.- Opciones recomendadas .................................................................................. 57 Tabla IV-4.- Dotacin de Personal ...................................................................................... 59 Tabla IV-5.- Costos de Personal .......................................................................................... 62 Tabla IV-6-. Cronograma ..................................................................................................... 63 Tabla IV-7.- Costos de Infraestructura ................................................................................ 63 Tabla IV-8.- Costos Hardware y Software ........................................................................... 64 Tabla IV-9.- Costos Comparativos de opciones de compra................................................. 65 Tabla IV-10.- Costos mensuales del proyecto ...................................................................... 65 Tabla V-1 Matriz de Data Marts .......................................................................................... 79 Tabla V-2 Correspondencia Fuente Destino........................................................................ 87
ANEXO B: BIBLIOGRAFA
Bibliografa
[Devlin88] [Devlin97] [Geiger00] [Humphries99] [INEI97] [Inmon92] [Inmon296] [Kimball98] [Mattison96] [Porter85] [SAS01] [Simon01] Devlin, Barry. An Architecture for a Business and Information System, IBM Systems Journal, 1988 Devlin, Barry. Data Warehouse: from Architecture to Implementation, Addison Wesley Longman, 1997 Geiger, Jonathan G. The Data Warehouse Model. EC Media Group, 2000 Humphries, Mark; Hawkins, Michael and Dy, Michelle. Data Warehousing, Architecture and Implementation, Prentice Hall, 1999 INEI, Instituto Nacional de Estadstica e Informtica de Per, Manual de Construccin de un Data Warehouse, 1997 Inmon, William H. Building the Data Warehouse, Technical Publishing Group, 1992 Inmon, William H., Imhoff, C. and Battas, G. Building the Operational Data Store, John Wiley & Sons, 1996 Kimball, Ralph, et. al. The Data Warehouse Lifecycle Toolkit, John Wiley & Sons, 1998 Mattison, Rob. Data Warehousing, 1996 Porter, M. E, Competitive Advantage: Creating and Sustaining Superior Performance, Free Press, New York, 1985 SAS Institute, Inc. SAS Rapid Warehousing Methodology, SAS Institute White Paper, 2001 Simon, Alan and Shaffer, Steven L. Data warehousing and Business Intelligence for e-commerce. Morgan Kauffmann Publisher. 2001.
ANEXO C: COTIZACIONES DE EQUIPOS Y CRONOGRAMA
Cotizaciones de Equipos
COTIZACION No. 220-056

FINDESA ATN: ERIKA SEVILLA NOTA 1: Garanta Estndar de Hardware de: 3 Aos NOTA 2: Esta cotizacin es vlida por 15 das. NOTA 3: Este producto lo tenemos de entrega inmediata hasta agotar existencias
CODIGO P3549A DESCRIPCION
HEWLETT PACKARD NETSERVER TC4100 Hewlett Packard Netserver TC4100 Procesador Pentium III DE 1.4 Ghz con capacidad de dos (2) procesadores Memoria Cache L2: 512 kb en cada procesador 256 MB memoria RAM PC-133MHZ ECC SDRAM DIMM EXPANDIBLE A 4 GB
Fecha: 30/08/2002 Ciudad: Managua Pas: Nicaragua

CODIGO: 354
La garanta solo por desperfectos de fabrica
Cant Precio Unit 1 $2,338.28
Total $2,338.28
P3559A D8266A P4620A
HP PROCESADOR 1.4GHZ 133MHZ FRONT-SIDE BUS* HP MEMORIA 256 MB PC-133 MHZ ECC SDRAM DIMM* Discos Wide Ultra-3 SCSI de 36 GB HOT-SWAP EXPANDIBLE A 584 GB Capacidad de 8 discos instalados De 10,000 rpm MARCA: HP, 10k Ultra 3 Wide SCSI-3 hot Swap HDD Unidad de CD-Rom, 48X Tolerancia a Fallas, RAID (1,3 y 5)
1 3 3
$1,350.00 $180.00 $570.00
$1,350.00 $540.00 $1,710.00
P3410A
HP NetRAID 1M Controller Tarjeta Controladora de Red Inteligente WAKE ON LAN, FAST Ethernet de 10/100 Mbps Tarjeta de Red Incluida Interfases: 2 serial, 1 paralelo, 1 Grafico, 1 puerto de Mouse PS/2 3.5" 1.44MB Unidad de Disco Flexible 6 Slots de Expansin PCI (4- 32 Bits, 2- 64 Bits) HP NetServer Navigator, Symantec PC ANYWHERE Conforme con SNMP, DMI e IPMI, incluye Top Tool de HP administracin HP Mini DIN Mouse HP NetServer Keyboard Fuentes de Poder de 350Watts
$736.17
$736.17
P2535A D8899A
HP fuente de Poder redundante de 350 Watts for TC4100 Monitor HP Color de 15" HP Top Tools para Servidores HP Openview Managex Event Manager Integrated Remote Assistant Sistemas soportados Microsoft Windows NT4, Windows 2000, Novell NetWare 4.2,5.0, Red Hat Linux, SCO Open Server and UNIXWARE 7.x
1 1
$619.00 $180.00
$619.00 $180.00
C1556D C7474A C7434A INST
HP SureStore DAT24E Externo de 24GB HP SureStore Ultra3 Wide PCI HBA Kit 68 Pin HD to 68 Pin VHD SCSI Adapter Instalacin y Configuracin de Software Plaza de compras, colonia C.A, P.O. BOX #2820, Managua, 3505-026, Nic. Tel.(505) 278-8000 Ext: 150 Fax: (505) 278-0041 e-mail:[email protected]
1 $1,272.00 1 $335.00 1 $64.00 1 $100.00 SUB TOTAL IGV TOTAL
$1,272.00 $335.00 $64.00 $9,144.45 $1,371.67 $10,516.12
Net Solutions
Vicky 1-1/2 C al Sur # 251 Altamira, Managua Telefax : 277 3185 CLIENTE: Ing. Ericka Sevilla EMPRESA: DIRECCION: TELEFONO: E-MAIL: FECHA: 16 de Septiembre de 2002 EJECUTIVO DE VENTAS: Lic. Denis Ros EQUIPOS Equipos de Cmputo Server Compaq PROLIANT ML350 TWR G2 Procesador Pentium III de 1266MHz Memoria RAM de 1024MB expandible a 4GB CD-ROM de 48x Disk Floppy de 1.44MB CANT. No FAX: COTIZACION No 1321
PRECIO US $ 3,609.00
TOTAL US $ 3,609.00
Disco duro LA 36.4GB U160 SCSI HD
745.00
2,235.00
Procesador P3/1266 512K PROC OPT Pentium III de 1266MHz
1,053.00
1,053.00
Para ms especificaciones ver archivo PDF adjunto o visite:

http://www.compaq.com/products/servers/proliantml350/index.html
Condiciones : Forma de Pago : 100% al aprobar cotizacin Tiempo de Entrega : 10 das laborales Oferta vlida por 15 das.
Sub Total US $ IGV 15% Total
6,897.00 1,034.55 7,931.55
PROPUESTA DE EQUIPO DELL
CANT. 1
ESPECIFICACIONES TECNICAS
PowerEdge 2500,Procesador Intel Pentium III , 1.4GHz, 512K Cache PowerEdge 2500, Intel Pentium III, 1.4GHz, 512K Cache 1GB SDRAM,133MHZ,2X512MB DIMM Drives attached to embedded SCSI controller,No RAID 1X6 HOT-PLUGGABLE HDD BACKPLANE 36GB,U160 SCSI,1 IN,10K HD 36GB,U160 SCSI,1 IN,10K HD 36GB,U160 SCSI,1 IN,10K HD Dell E551,15in (13.8in Viewable) en Gris 24X IDE,CD-ROM [430-5000] 3COM 3C980C 10/100 NIC 3 aos de garanta limitada a domicilio 3.5 IN,1.44MB,FD,PE2500 Logitec System Mouse (Gris) Redundant Power Supply 2+1 [310-4100] Teclado Estandr de Windows PE2500 USER'S AND TRBL SHOOTING GUIDE TOWER CHASSIS 20/40GB,INT,CC,TB,P2500
PRECIO
VALOR DEL EQUIPO Este precio no incluye el IGV ESPECIFICACIONES DE LA PROPUESTA:

U$ 8,400.00
Este equipo estar disponible en nuestras instalaciones luego de 18 das a partir de la fecha en que se reciba la orden de compra. Esta oferta es vlida por 30 das. La Garanta de Calidad por desperfectos de fbrica es de TRES aos.
ANEXO D: ENTREVISTAS
Entrevistas
Diseo de las Entrevistas
Gerencia General: 1. Cules son los objetivos de su organizacin? Cules son sus metas de negocio de mayor prioridad? Qu est tratando de alcanzar? 2. Cules son sus mtricas de xito (indicadores)? Qu tan frecuente mide sus factores clave de xito? Qu tipo de decisiones son las que usted toma frecuentemente? Cmo sabe que est haciendo lo correcto? 3. Qu funciones y departamentos dentro de la organizacin son los cruciales para asegurar que estos factores clave de xito sean alcanzados? Qu rol juegan ellos? Cmo trabajan en conjunto para asegurar el xito? 4. Cules son las cuestiones (elementos) claves del negocio que usted debe enfrentar en este momento? Qu impide que usted alcance dichos objetivos? Cul es el impacto en la organizacin? 5. Cmo identifica problemas/excepciones o reconoce que va en direccin hacia los problemas? 6. Qu visualiza como oportunidades adicionales de utilidades que no son aprovechadas en este momento? 7. Dnde se sitan en el uso de tecnologa de informacin en comparacin con la competencia?Se encuentra en la capacidad de responder rpidamente a las condiciones del mercado y asegurar la productividad de su staff? 8. Qu papel juegan los anlisis de datos en decisiones que deben hacer los gerentes para dirigir el negocio? 9. Qu informacin necesita responder para mantener su puesto? Cul es la 1er, 2da, 3ra... pregunta relativa a crditos/ganancias que usted debe responder en su rea de trabajo? 10. Qu informacin clave se requiere para hacer o soportar las decisiones que usted toma en el proceso de alcanzar las metas y sobreponerse a los obstculos? Cmo obtiene esta informacin en este momento? 11. Cules son los reportes que ms le ayudan a hacer su trabajo? Qu datos en el reporte son importantes? Cmo usa esta informacin? Si el reporte fuera dinmico, que sera distinto en l?
Entrevistas 12. Qu preguntas le han quedado sin responder simplemente porque usted sabe que no hay respuesta disponible? Existe alguna otra informacin faltante que crea puede tener un impacto significativo en ayudarle a alcanzar sus metas? 13. Qu tan difcil es en este momento conseguir esa informacin? Cmo debera presentarse, de que forma? Qu tan frecuente la necesita: Diario, Semanal, Mensual, Anual? 14. Qu capacidades analticas le gustara tener? 15. Qu oportunidades existen para mejorar dramticamente el negocio, basado en un mejor acceso a la informacin? Cul es el impacto financiero? 16. Qu debe alcanzar este proyecto para ser considerado exitoso? El criterio debe ser mesurable.
Entrevistas Gerencias de Crdito, Finanzas y Mercadeo: 1. Qu tipo de decisiones son las que usted toma frecuentemente? 2. Qu informacin necesita responder para mantener su puesto? 3. Cules son los indicadores que debe monitorear constantemente? 4. Si tuviera abundancia de informacin sobre su rea, que hara con ella? 5. Qu tan difcil es en este momento conseguir esa informacin? 6. Qu preguntas le han quedado sin responder simplemente porque usted sabe que no hay respuesta disponible? 7. Qu tan frecuente necesita esta informacin: Diario, Semanal, Mensual, Anual?Cmo debera presentarse esta informacin, de que forma? 8. Cul es la 1er, 2da, 3ra... pregunta relativa a crditos/ganancias que usted debe responder en su rea de trabajo? 9. Cules son los reportes que ms le ayudan a hacer su trabajo? 10. Con quienes discute y analiza la informacin de su rea? 11. Cmo se organiza y funciona su departamento?Cmo fluye la informacin en su depto? 12. Cmo le ayuda el sistema actual a desempear su trabajo y a la toma de decisiones? 13. Cules son las metas de su rea? Cules son las prioridades de su rea? 14. A que le llamara factor crtico de xito en su departamento? 15. Cmo ayuda la informacin de su rea al desempeo de la empresa?
Entrevistas Gerencia de Sistemas: 1. Cules son las caractersticas de los sistemas actuales? 2. Haga una breve Descripcin de la plataforma tecnolgica con la que cuentan 3. Cunto tiempo de informacin se tiene en lnea? 4. Qu tan estable es el modelo de datos de la organizacin? 5. Quines son los responsables de los mdulos de los sistemas transaccionales? 6. Quines estn a cargo de los cambios en el sistema transacciones? 7. Existe algn tipo de documentacin sobre los sistemas que utiliza la organizacin? Diccionario de Datos, Manuales Tcnico y de Usuario, por ejemplo 8. Cules son los sistemas heredados o antiguos con los que se cuenta? 9. Existen datos histricos almacenados fuera de lnea? Cunto tiempo de datos? 10. Dnde guardan el histrico? 11. Quin conoce la estructura de los datos del sistema transaccional? Estn limpios? 12. Cules herramientas de usuario final para reportes y anlisis tiene la empresa?
Entrevistas
Resultados de las Entrevistas Gerencia General Proveer servicios financieros innovativos, giles y ajustados a las necesidades del mercado Participar del veinticinco por ciento del mercado financiero en los prximos cinco aos Contar con una cartera de estipulada a mediano plazo. Capitalizar cierto monto sobre las acciones. Correcta seleccin de Clientes Disminuir riesgos en la operacin financiera Disponer de Recursos Humanos adecuados Identificacin de riesgos y dificultades Anlisis de problemas de la institucin Coordinacin de las reas y sucursales de la empresa Rendimiento de Capital Rendimiento de Equidad Determinar soluciones posibles a los problemas de la empresa Aprobar estrategias y solicitudes presentadas por los directivos de departamentos y sucursales Anlisis del rendimiento sobre desembolsos Anlisis de disponibilidad: Capacidad de pago de cuota, cobertura promedio de las garantas Lquidez Rendimiento financiero Costos financieros Gastos Administrativos Calidad de los activos y Comprobacin de activos Productividad por analista Recursos lquidos Relacin de cantidad total por pasivo total Estructura de la cartera por moneda contra el pasivo por moneda Calidad de Cartera Mora Calidad de Cartera Gastos Administrativos Rentabilidad sobre capital Productividad de Clientes por analistas La informacin no esta accesible Existen datos bsicos pero deben realizar clculos sobre ellos si se quiere disponer de agregados. Los datos tienen poco significado pues no estn relacionados para la toma de decisiones. Informes de Mora Para cobranza Resumen de contaminada Informes de Colocaciones:
Objetivos
Prioridades
Factor crtico de xito Decisiones ms frecuentes Informacin Clave
Indicadores
Disponibilidad de informacin
Reportes de uso ms frecuente
Entrevistas
Por fecha Por actividad econmica Por analista Informes de Recuperaciones Para cobranza Por analista Resumen de recuperaciones Pagos recibidos Informe de Saldos de Cartera Calidad de Cartera Informe de Liquidez Contabilidad Clasificacin de mora por: Edad Sexo rea geogrfica Garantas Actividad Econmica Inventario Volumen de Venta Sucursal -Analista Clasificacin de la Cartera Activa por: rea geogrfica Producto Monto Calificacin del Sistema Sector Econmico Sexo Sucursal Analista Cruce entre las Clasificaciones anteriores Semanal Mensual Reportes Grficos Gerencia Financiera Gerencia de Crdito Gerencia de Mercadeo Gerencia de Sistemas Recursos Humanos Los reportes brindan datos crudos, que luego deben ser procesados para poder realizar los informes gerenciales y otra documentacin para monitorear el desempeo y tomar decisiones.
Informacin faltante
Frecuencia de uso de informacin Forma de presentacin preferida Interaccin con dems dependencias Desempeo del sistema actual en la toma de decisiones
Entrevistas
Objetivos
Prioridades
Factor crtico de xito Decisiones ms frecuentes Informacin Clave
Indicadores
Disponibilidad de informacin
Reportes de uso ms frecuente
Informacin faltante
Gerencia Financiera Obtener fondos necesarios para incrementar la Cartera y mantener liquidez. Liquidez mayor o igual al un porcentaje establecido en relacin con la cartera bruta. Registro contable de las operaciones. Control Interno enfocado al control del efectivo Mantener el flujo de recursos necesarios para las operaciones de la institucin. Garantizar procedimientos que regulen y controlen las operaciones de caja, tesorera y contabilidad. Cumplimiento de metas establecidas en presupuestos Gestin de Recursos Liquidez Rentabilidad de la institucin Autorizacin de traslados de fondos a sucursales Gestin de desembolsos a entidades fuentes de financiamiento. Venta o compra de devisas extranjeras Estado de Liquidez Estados Financieros Estado de la Gestin de Recursos Rentabilidad de Colocacin Costo de Pasivos Calce de plazos y calce de monedas Gastos Administrativos Saldos de Caja por cada Oficina Nivel de Recuperacin Nivel de Colocacin Pagos de obligaciones Gastos Administrativos reales Comparacin ejecucin real contra el presupuesto Es obtenida de las sucursales existentes. Tambin por gestin de la Gerencia de Sistemas en donde se encuentra la Base de Datos Central. Datos de algunos crditos que se perdieron o corrompieron en la migracin al sistema actual. Estados Financieros Plan de Negocios: Direccin del volumen de colocacin / Recuperacin Presupuesto de colocacin / Recuperacin Gastos administrativos Estados de Resultados Anual Disponibilidades Obligaciones Reportes de cartera por fuentes de fondos : Colocaciones Recuperaciones Mora
Entrevistas
Indices de captacin de otros ingresos a travs del sistema No se puede registrar los pagos de clientes por honorarios, avalos, inscripciones, tarjetas inteligentes, pagars, fondos en custodia. No hay distincin entre el Estado de Resultado de los ingresos financieros que slo estn devengados (registrados como ingresos pero no pagados) de los que estn devengados y efectivamente pagados. Reporte de Estado de cumplimiento de proyeccin de colocacin por montos Semanal Reportes Gerencia General Gerencia de Crdito Mercadeo Gerencias de Sucursales Contabilidad General Programacin Financiera Ayuda de alguna forma, pero es muy pobre
Frecuencia de uso de informacin Forma de presentacin preferida Interaccin con dems dependencias
Desempeo del sistema actual en la toma de decisiones Informacin del departamento que ayuda al mejor desempeo de la empresa
ndice de Ganancia y Prdida ndice de Rentabilidad Necesidad de modificacin al plan de negocio Apertura de nuevos mercados Tasa Comisin Costos
Entrevistas
Objetivos
Prioridades Factor crtico de xito Decisiones ms frecuentes
Gerencia de Crdito: Asegurar una cartera de Calidad Garantizar nivel de Calidad de los Clientes Desarrollar productos atractivos al mercado Desarrollar una metodologa crediticia eficiente y consistente Cumplir con las metas de la empresa Mantener niveles saludables de Saldos de Cartera Asegurar una Cartera Sana Mantener una Cartera Sana Aprobacin de Crdito: revisin de expedientes Medidas de contencin para clientes Morosos Gestin del Manual de Crditos Gestin de Procedimientos de Crdito Contratacin / Despidos Nivel de Colocacin Nivel de Recuperacin Calidad de Cartera Concentracin de mora Productividad de los analistas Productividad de las Sucursales Tiempo de Procesamiento de Solicitud Mora Colocacin Recuperacin Productividad Margen de Ganancia por Productividad Se dispone de informacin elemental. Otra informacin se puede conseguir a travs de la Gerencia de Sistemas. Informe de Mora Informe de Colocaciones Informe de Recuperaciones Informe de Saldos de Cartera Reporte de Mora por Calificacin del Sistema Clasificacin de Clientes por tamao de su negocio Nivel de Ingreso de los Clientes Distribucin Geogrfica de los Crditos Consolidados Anuales Clasificacin de la Cartera Activa por: rea geogrfica Producto - Monto Calificacin del Sistema Sector Econmico Sucursal Analista Sexo Cruce de Clasificaciones
Informacin Clave
Indicadores
Disponibilidad de informacin Reportes de uso ms frecuente Informacin faltante
Entrevistas
Frecuencia de uso de informacin Forma de presentacin preferida Interaccin con dems dependencias Desempeo del sistema actual en la toma de decisiones Informacin del departamento que ayuda al mejor desempeo de la empresa Diario Mensual(consolidado) Reportes Gerencia General Gerencia Financiera Gerencia de Mercadeo Gerencias de Sucursales Ayuda a resolver necesidades de informacin en un 70% Informe de consolidado se debe hacer manual ndice de Colocacin ndice de Recuperacin Saldos de Cartera
Entrevistas
Objetivos
Prioridades Factor crtico de xito Decisiones ms frecuentes Informacin Clave
Indicadores
Disponibilidad de informacin Reportes de uso ms frecuente
Informacin faltante
Gerencia de Mercadeo Gestionar el crecimiento de los Clientes Nuevos Asegurar el mantenimiento de la Cartera Vigente Identificar oportunidades de Mercado Determinar campaas de inversin publicitaria Satisfacer las necesidades de los Clientes Ayudar a conseguir metas de colocacin Mejorar el nivel de satisfaccin de nuestros clientes Gestin de Publicidad Gestin de Atencin al Cliente Visitas a Clientes Potenciales Investigar Quejas Tiempo de gestin de solicitud de Crdito Cantidad de dinero reembolsado Motivos de no renovacin de crditos Clientes que cancelan en el perodo Revolvencias de los crditos Rentabilidad de la Publicidad Crecimiento de nuevos crditos Crecimiento de clientes nuevos Bajas de clientes Nivel de satisfaccin de los clientes actuales Mantenimiento de la Cartera Vigente Informacin sobre algunos tpicos importantes existe pero se debe obtener manualmente a partir de varios reportes y sobre otros no existe ni un dato Clientes actuales Clientes inactivos Crditos Otorgados por actividad econmica y por analistas, Crditos repetitivos y nuevos Proyeccin de Reembolso Saldos de Cartera Tiempo de gestin de solicitud de crdito de inicio a fin Control de quejas ndice de renovacin de Clientes Factor de retorno a la inversin publicitaria Fichas de perfil personal de los clientes Clasificacin de la Cartera Activa por: Sucursal Analista Zona Producto Monto Fechas de solicitud, evaluacin, desembolso Cruce de Clasificaciones Revolvencias de Lneas de crdito: Cantidad de Revolvencias por cliente Resumen de Revolvencias
Entrevistas
Frecuencia de uso de informacin Forma de presentacin preferida Interaccin con dems dependencias Desempeo del sistema actual en la toma de decisiones Semanal Mensual (consolidado) Reportes Gerencia General Gerencia de Crdito Gerencia de Sistemas Ayuda a resolver necesidades de informacin en un 60%. Informe de renovacin de clientes en un perodo se elabora manual. Contiene a los clientes que no han renovado en un perodo determinado con sus correspondientes niveles de mora de cada crdito. Actualmente existe un reporte de renovacin pero es incorrecto, ya que para algunos clientes asume la mora promedio de todos los crditos Datos sobre publicidad no se reflejan en ningn informe Manifestacin de factores y puntos crticos en la gestin de la empresa hacia los clientes Pautas de inversin en Publicidad Establecimiento de oportunidades de ampliacin de mercado
Informacin del departamento que ayuda al mejor desempeo de la empresa
Entrevistas
Sistema Actual
Cantidad de Informacin en lnea Estado de la informacin fuera de lnea Evolucin del modelo de Datos Mdulos del sistema transaccional
Gerencia de Sistemas: Sistema de Gestin de Crdito (LFS) consta de los mdulos: Crdito, Clientes, Reportes, Caja, Contabilidad Sistema de Planilla Bases de Datos Distribuida entre las sucursales y fuera de lnea. Existe una Base de Datos central que se actualiza en modo BATCH LFS: 2 aos Informix: 3 aos Almacenado en forma de respaldos en CD y Disco Duro. Los datos se deben montar en la base de Datos para accederlos Los datos presentan cierta inconsistencia. La calidad de los datos no es ptima El Modelo de Datos (MD) de la organizacin es dinmico, cambia adaptndolo a nuevos requerimientos de la empresa. El MD an no se ha consolidado de forma estable. Clientes Reportes Caja Crdito Ahorro Contabilidad Presupuesto LFS: Manual Tcnico (80%): ERD, Diccionario de Datos del mdulo clientes Manual de usuario: No existe Informix: Manual Tcnico Manual de Usuario Sistemas Operativos: Windows 98, Windows 2000 Server, Windows XP, Linux Suse 7.0 DBMS: SQL Server 7.0 Programacin: VFP 7.0, Visual Studio 6.0, Clipper(planilla) Ofimtica: MS-Oficce 97, 2000, XP, Crystal Reports
Documentacin
Recursos Disponibles
ANEXO E: REQUERIMIENTOS DE HERRAMIENTAS SOFTWARE
Requerimientos Software
SOFTWARE UTILIZADO Categora

Automatizador de ETL
Software
Data Transformation Services de Microsoft SQL Server 2000
Funcionalidades Requeridas
Capacidad de: Extraccin de datos almacenados en diversas plataformas. Deduplicacin de datos redundantes. Duplicacin de Datos. Estandarizacin. Transformaciones por tabla, columnas, registros, campos. Programacin de la ejecucin de tareas automatizadas. Registro de operaciones efectuadas (logs). Realizacin de Ingeniera en Reversa a partir de bases de datos almacenadas en SQL Server 2000. Presentacin de modelos relaciones o multidimensionales. Soporte de distintas metodologas de diagramacin. Capacidad de exportar a otros repositorios. Tecnologa Relacional. Capacidad de interactuar con Base de Datos multidimensionales. Lenguaje de Consulta Compatible con estndar SQL 92. Administracin de integridad referencial . Registro de operaciones efectuadas (logs). Capacidad de realizar respaldos de la informacin. Juego de Instrucciones para Data Warehouse. Soporte para particiones que contengan datos fuertemente relacionados. Soporte de esquema estrella . Soporte de roles de usuarios. Uso de metadatos y repositorio de metadatos. Plataforma OLAP con soporte para HOLAP MOLAP, ROLAP Gestin de cubos de datos multidimensionales Servir de fuente de datos para consulta de otras aplicaciones. Capacidad de utilizacin de metadatos. Realizacin y almacenamiento de agregados para mejorar consultas. Capacidad de procesamiento en lotes Soporte para Data Mining y para Executive Information Systems. Soporte para productos con habilidades Web. Acceso a Base de Datos SQL Server 2000.
Licencia
Adquirida de agente autorizado
CASE
Platinum Erwin/ERX 3.5
Licencia de perodo de evaluacin
DBMS
Microsoft SQL Server 2000 Service Pack 2
Herramienta de Acceso a Datos
Microsoft Analysis Services 2000
Requerimientos Software Categora

Modelador de Datos
Software
Oracle Designer / 2000 2.0
Funcionalidades Requeridas
Entorno integrado para modelar Bases de Datos. Capacidad de modelado Dimensional o Relacional Posibilidad de generar diseo fsico a partir de Diagrama Entidad Relacin de alto nivel Permite trabajo concurrente de diseadores de datos Generacin de Scripts de Definicin de Bases de Datos, para la implementacin del diseo Presentacin de Diagramas del modelo desarrollado a distinto nivel de detalle, desde ERD hasta el diagrama de especificacin fsica. Posibilidad de exportar a distintos repositorios Independencia de la plataforma del sistema operativo Hojas de Clculo: Capacidad de conexin a servidor OLAP, Analysis Services Flexibilidad para manipular grandes cantidad de datos Capacidad de realizar anlisis estadsticos como desviacin estndar, 80-20, etc Consulta dinmica de datos. Drill down y roll up Procesamiento en lotes de programas de aplicacin Multiprocesador Multiusuario Multitareas Soporte para SQL Server 2000, Analysis Services y Oracle Designer
Licencia
Oracle TecnologyN etwork, licencia de perodo de evaluacin
Ofimtica
Microsoft
Sistema Operativo
Microsoft Windows 2000 Server.
ANEXO F: MODELOS DE DATOS Y SCRIPTS
Modelos Dimensionales
Tabla de Contenido
DIMENSIONES DE LOS DATA MART DETALLE DE LAS DIMENSIONES DIMENSIN FECHA DIMENSIN CLIENTE DIMENSIN PRODUCTO DIMENSIN TASAS DIMENSIN SUCURSAL DIMENSIN ANALISTA DIMENSIN MODO DE PAGO DETALLE DE LOS HECHOS CRDITOS _ GESTIONADOS CRDITOS_ABONADOS HECHOS PROYECCIN_RECUPERACIN HECHOS NIVEL 2: GRANO SEMANAL PRESUPUESTO_RECUPERACIN HECHOS CREDITOS_ABONADOS_SEMANALES HECHOS
Dimensiones de los Data Mart
Fech Condicion
Fecha Vencimient Fecha Final
Estado
Analista
Hora
Grupos de Convenio Client
Cuentas Fuente Financiamien
Product
Tasas Formas
Descripciones de las Dimensiones Nombre Dimensin Fecha Fecha Vencimiento Fecha Final Hora Cliente Producto Tasas Modalidad de Pago Descripcin de la Dimensin Contiene todos los atributos asociados con la fecha en que la actividad ocurri. Contiene todos los atributos asociados con la fecha en que vence el plazo de pago del monto otorgado o de la cuota actual Contiene todos los atributos asociados con un final o fecha de resolucin (fin de contrato de crdito, fecha cancelacin de deuda) Contiene todos los atributos acerca de la hora en que una actividad ocurri. Representa a ambas personas naturales o jurdicas y todos que son clientes y los atributos asociados a ellos. Contiene informacin acerca de productos y servicios que se ofrecen. Describe las tasas de interes usado para los creditos de los clientes. Describe las diferentes modalidades de frecuencia y moneda entre los que un
Modelos Dimensionales Nombre Dimensin Fuentes Financiamiento Cuentas LM Convenio Analista Condicion Estado Descripcin de la Dimensin cliente puede elegir para pagar Caractersticas de compaas de las que se obtienen recursos liquidos para la institucin Numeros de cuentas del libro mayor utilizadas para seguimientos financieros y reportes. El Grupo de instituciones que han firmado convenios de pago con la empresa. Describe a los analistas individuales de la compaa. Describe la condicion en la que se encuentra un credito segn los pagos realizados. Describes el estado del credito que gestiona un cliente.
Detalle de las Dimensiones

Dimensin Fecha Ao Fiscal Trimestr Fiscal Ao Fiscal Semana Fiscal Tipo de Da Semana Calendario Ao Calendario Trimestre Calendar io Mes Calendario
Da de Semana
Da
Festivo
Descripciones de Atributos de la Dimensin Fecha Nombre de Atributos Da Da de Semana Festivo Tipo de Da Semana Calendario Mes Calendario Trimestre Calendario Ao Calendario Semana Fiscal Mes Fiscal Trimestre Fiscal Ao Fiscal Descripcin de Atributos El Da especifico que una actividad tuvo lugar. El nombre especifico del Da. Identifica que este da es Festivo. Indica si este Da es o no un Da Semana El dia que finaliza la Semana, siempre es un Sabado. FS significa Fin de Semana. El mes Calendario. El Trimestre Calendario. El Ao Calendario. La Semana que representa el Calendario de la empresa. Notar que la F en El valor del dato indica que este es un periodo de tiempo fiscal. El periodo fiscal comprendido de 4 o 5 Semanas. Notar que la F en El valor del dato indica que este es un periodo de tiempo fiscal. El grupo de 3 meses fiscales. El grupo de 52 Semanas fiscales / 12 meses fiscales que comprende el ao financiero. Valores de Muestra 06/04/2001;6/05/2001 Lunes; Martes Dia Madre; Navidad Fin de Sem; Da de S FS 06/06/2001; FS 06/13/2001 Enero,2001; 2001Q1; 2001Q4 2001 F Semana 1 2001; F Semana 46 2001 F Enero, 2001; F Febrero, 2001 F 2001Q1; F2001Q2 F 2001; F 1999
Dimensin Cliente
Perfil de Casa
Grupo Industrial
Cobro a Departamento Casa Industria
Cobro a Ciudad
Direccin de Cobro Nivel Educacin del Cliente Perfil demogrfico. del Cliente Fecha de Nac. del Cliente Sucursal asignada a Cliente Fecha de 1er Servicio
Sexo Cliente
Cliente
Tipo de Cliente
Pas Domicilio Cliente
Direccin Domicilio Cliente
Departamento Domicilio Cliente
Sucursal Asignada cliente
Localidad Cliente
Ciudad Domicilio cliente
Clasificacin Cliente
Identificador Cliente
Calificacin Cliente
Modelos Dimensionales Dimensin Cliente Descripciones de Atributos Nombre de los Atributos Identificador Cliente Sucursal asignada al Cliente Direccin de domicilio del Cliente Ciudad de domicilio del Cliente Departamento de domicilio del Cliente Pais de domicilio del Cliente Cliente Tipo de Cliente Sexo Cliente Fecha de Nacimiento del Cliente Perfil Demogrfico del Cliente Actividad Econmica Casa Nivel de Educacin del Cliente Direccin de Cobro Cobro a Ciudad Cobro a Departamento Industria Grupo Industrial Fecha de Primer Servicio Clasificacin Cliente Calificacin Cliente Atributo Descripcin Identificador o cdigo actual para el cual se presta los servicios. Nombre de la sucursal especifica que es responsable de manejar las cuentas del Cliente. La direccin de domicilio para este Cliente. Nota: El barrio, distrito sern separados para una completa flexibilidad. El Nombre de la ciudad donde este Cliente tiene su domicilio. El Nombre del departamento donde este Cliente tiene su domicilio. El Nombre del pas donde este Cliente tiene su domicilio. Identificador nico por cada Cliente. Este ser representado de mltiples maneras incluyendo nombre e identificador de Cliente para los Clientes naturales Indica si el Cliente es una personal jurdica o natural. Indica el sexo del Cliente natural. Indica la fecha de nacimiento del Cliente natural. Cada Cliente natural es asignado al perfil demogrfico que major se adapta. Cada Cliente natural es asignado al perfil de actividad econmica que mejor se adapta a las labores que desempea Clientes natural son agrupados en aquellos habitando en una unica residencia. Indica el ms alto nivel de educacin formal que ha completado el Cliente. La direccin de cobro para este Cliente. Nota: El barrio, distrito sern separados para una flexibilidad completa. El Nombre de la ciudad de la direccin de cobro de este Cliente. El Nombre del departamento de la direccin de cobro de este Cliente. Para Clientes comerciales, esto indica el estndar industrial que mejor describe sus negocios. Un agrupamiento de industrias en categoras similares. Indica la Fecha cuando se realize negocios con este Cliente por primera vez Indica si un cliente ha utilizado ms una o ms de una vez los servicios de la empresa Agrupa a los clientes en categoras segn su historial de pago, mora promedio, nmero de crditos Valores de muestra 02-000405-1; 08-000010-3 Matagalpa, Leon, Rio Blanco Casa Pellas Santa Ana 3c al Sur, Santa Ana, Distrito IV Sbaco Matagalpa Nicaragua Talleres Rapidito.; Susana Bez Natural; Jurdico Femenino, Masculino 07/03/1960 Profesional Soltero, Padre de Familia Farmacia, Elaboracin de Bebida, Ferretera 1000; 2000 Secundaria; Universidad; Maestria Casa Pellas Santa Ana 3c al Sur, Santa Ana, Distrito IV Sbaco Matagalpa Taller Mecnico.; Farmacia Salud, Hidrulica 1/04/1989 Nuevo, Repetitivo AAA; B
Dimensin Producto
Categora de Productos
Clase de Productos Sector Econmico Producto/ Servicio Destino
Dimensin Producto Descripciones de Atributos Nombre de Atributos Producto/Servicio Sector Economico Destino Crdito Clase de producto Categora Producto Descripcin de Atributos Describe el producto individual o servicio ofrecido, que un Cliente adquiri Indica el sector econmico que mejor se ajusta al perfil del producto que solicita el cliente Indica para que ser utilizado el los fondos del crdito otorgado Una coleccin de productos Una coleccin de clases de producto Valores de Muestra Ordinario, Ra-Fl, Lnea de Crdito, Personal Industria, comercio, personal, servicio, agrcola, ganadero e hipotecario Credicompu, Capital de Trabajo, Activo Fijo Productos para la micro empresa. Productos familiares Crdito, Ahorro
Dimensin Tasas
Tipo de Comisin
Trminos de la Comisin
Trminos de Servicios
Trminos Tipo de de Servicios Servicios
Fecha Inicio Comisin Fecha Final Comisin
Fecha Inicio Servicios Fecha Final Tasa Comisin Servicios
Tasa Comisin
Tasa Servicios.
Fecha Inicio Inters Fecha Final Inters Trminos del Inters
Fecha Inicio Interes Moratorio Fecha Final Interes Moratorio
Trminos del Interes Moratorio
Tasa Inters
Tasa Inters Moratorio
Lmite Superior
Sector Econmico
Lmite Inferior
Identificador Tasas
Extensin Lm Superior
Modelos Dimensionales Dimensin Tasas Descripciones de Atributos Nombre de Atributos Identificador de Tasa Limite inferior Limite superior Extensin de limite superior Sector Econmico Tasa de Inters Fecha Inicio Inters Fecha Final Inters Trminos del Inters Tasa de comisin Tipo de Comisin Fecha Inicio Comisin Fecha Final Comisin Trminos de la Comisin Tasa de Servicios Tipo de Servicios Fecha Inicio Servicios Fecha Final Inters Trminos de los Servicios Tasa de Inters Moratorio Fecha Inicio Inters Moratorio Fecha Final Inters Moratorio Descripcin de Atributos Describe de manera unica una coleccin de informacin de las tasas que se le asignan al producto solicitado por el cliente. Indica cual es el monto que se fija como lmite inferior para aplicarle la tasa actual Indica cual es el monto que se fija como lmite superior para aplicarle la tasa actual Describe la extensin en el monto del lmite superior que es posible utilizar en algunos crditos especiales Indica el sector econmico que se le asocia a una tasa individual Indica el inters aplicado en la tasa actual definido de forma porcentual y en valores diarios La Fecha en que este tipo de inters se puso a la disposicin de los clientes La Fecha en que este tipo de inters ya no estuvo disponible para los clientes. Indica los trminos o condiciones especiales que tambin pueden aplicar a este inters. Indica la comisin definida de forma porcentual que se aplica sobre cada desembolso al utilizar la tasa actual Forma en la que se determina ser pagada la comisin La Fecha en que este tipo de comisin se puso a la disposicin de los clientes La Fecha en que este tipo de comisin ya no estuvo disponible para los clientes. Indica los trminos o condiciones especiales que pueden aplicarse a esta comisin. Indica la tasa de servicios expresada en valor porcentual que se aplica de forma anual en la tasa actual Forma en la que se determina sern pagados los servicios La Fecha en que este tipo de servicios se puso a la disposicin de los clientes La Fecha en que este tipo de servicios ya no estuvo disponible para los clientes. Indica los trminos o condiciones especiales que tambin pueden aplicar a este servicio. Indica el inters moratorio aplicado en la tasa actual definido de forma porcentual y en valores diarios La fecha en que este tipo de inters moratorio se puso a la disposicin de los clientes La fecha en que este tipo de inters moratorio ya no estuvo disponible para los clientes. Valores de Muestra 001; 002 10,000 50,000 10,000 Ganadera; Comercio 0.0833 %; 0.0667 % 04/15/1996 3/26/1997 Plazo mnimo 1 ao 3.5 %; Deducida; Financiada 04/15/1996 3/26/1997 Nunca puede ser financiada 1.5 % 6.0 % Financiados, Al vencimiento 04/15/1996 3/26/1997 Pagar al final del periodo 0.0833 %; 0.0667 % 04/15/1996 3/26/1997
Dimensin Sucursal
Departamento de la Sucursal
Direccin Sucursal
Ciudad de la Sucursal
Gerente. Sucursal
Sucursal
Cantidad de Empleados
Dimensin Sucursal Descripciones de Atributos Nombre de Atributos Sucursal Gerente Sucursal Direccin Localidad Sucursal Ciudad Localidad Sucursal Departamento Localidad Sucursal Cantidad de Empleados Descripcin de Atributos Representa las oficinas sucursales que la organizacin tiene en distintas localidades del pas Indica quien fungia en el cargo de gerente y diriga la sucursal . La direccin de localidad para esta sucursal. El Nombre de la ciudad donde esta localizada la sucursal El Nombre del departamento donde esta localizada la sucursal. Indica la cantidad de empleados que se encuentran operando en la sucursal. Valores de Muestra Managua, Ivan Montenegro Pedro Lpez, Aminta Sols Managua Managua 10, 7, 12
Dimensin Analista
Direccin Analista Departamento del Analista Fecha Original de contratacin Ciudad del Analista Nivel de Educ del Analista Fecha Actual de contratacin
Fecha de Nac. Analista
Estado de Empleo
Empleado
Sexo Analista
Dimensin Analista Descripcin de Atributos Nombre de Atributos Analista Estatus de empleo Sexo del Analista Fecha de nacimiento del Analista Nivel de Educacin del Analista Fecha Original de Contratacin Fecha Actual de Contratacin Direccin de contacto del Analista Ciudad de contacto del Analista Departamento de contacto del Analista Descripcin de Atributos Representa a los individuos contratados por Findesa. Analistas podr ser visto por el nmero de Analista, Nombre, cdula y nmero de INSS. El status de los individuos contratados. Indica el sexo de este Analista. Indica la fecha de nacimiento de este Analista. Indica el ms alto nivel de educacin formal que el Analista ha completado. Indica la primera fecha de contratacin del Analista. Indica la fecha ms reciente que el Analista fue contratado. La direccin de contacto para este Analista. Nota: El barrio, distrito sern separados para una completa flexibilidad. El Nombre de la ciudad donde se puede establecer contacto con este Analista. El Nombre del departamento donde se puede establecer contacto con este Analista. Valores de Muestra Carla Chvez, Braudilio Urey Activo; Retirado; salio de la empresa Masculino; Femenino 04/24/1974 Secundaria, Licenciatura, Maestra 09/15/1996 08/01/2001 Casa Pellas Santa Ana 3c al Sur, Santa Ana, Distrito IV Managua Managua
Dimensin Modo de Pago Frecuencia de pago Moneda de pago
Forma de pago
Modalidad de pago
Dimensin Modo de Pago Descripcin de Atributos Nombre de los Atributos Modalidad de Pago Periodo de pago Frecuencia de pago Descripcin de Atributos Forma que identifica la modalidad de pago elegida por el cliente Indica la forma que se elije los das de pago para pago de las cuotas en dependencia de la frecuencia de pago seleccionada Representa la periodicidad que ha elegido un cliente para efectuar el pago de las cuotas del producto seleccionado. Indica en cuantas cuotas un cliente desea cancelar su crdito Indica la moneda en la que se gestiona una transaccin, pago o desembolso. Valores de Muestra Modo 1 Modo 2 Fecha Fija Perodo Fijo Semanal, Catorcenal, Quincenal, Mensual, Bimensual, Trimestral, Semestral, Anual, Vencimiento 12, 24 Crdobas, Dlares
Cantidad de cuotas Moneda de pago
Detalle de los Hechos

Crditos _ gestionados
Fuente de Financiamiento
Identificador Fuente
Fecha
Da
Fecha Vecimiento
Da
Estado
Estado
Fecha Final
Da
Identificador Garanta
Garanta
Analista Crditos Gestionados

Identificador Analista
Modalidad de Pago
Modo de Pago
Cliente
Identificado r
Tasas
Sucursal
No Sucursal
Producto
Producto/Servicio
Convenio
Identificador Convenio
Hechos Descripcin de los hechos Crditos Gestionados Nombre Hecho No de crdito Total Crdito Principal Comisin Servicios Mtto Valor Cargos Legales Intereses Intereses moratorios Valor Recargo Das Plazo Valor cuota Monto Garanta Descripcin Hecho Representa el nmero actual del crdito Monto total que pagar el cliente producto del financiamiento otorgado Monto total aprobado para ser financiado en un crdito especfico Cantidad total que se deduce en concepto de comisin Cantidad total que se cobra en concepto de servicios. Cantidad total que se cobra en concepto de mantenimiento del Valor Cantidad total que se paga en concepto de cargos legales: Pagars, Contratos, Inscripciones Monto que se devenga en concepto de intereses por el crdito otorgado Monto que el cliente acumul en concepto de intereses moratorios durante la vida del crdito Monto total que el cliente ha pagado como multa por pagos tardos El total de das de plazo para la cancelacin del crdito. Indica el monto que abonara a su deuda el cliente cada vez Indica el monto en que se valora la garanta presentada por el cliente RAD N/A Sum Sum Sum Sum Sum Sum Sum Sum Sum N/A N/A Sum
Crditos_Abonados Hechos
Modo de Pago
Modalidad de Pago
Fecha_ Vencimiento
Da
Fecha
Da
Condicin
Condicin
Hora
Minuto
Crditos Abonados
Analista
Tasas
Identificador Tasas
Cliente
Producto
Producto/Servicio
Sucursal Convenio
Identificador Convenio No Sucursal
Crditos_Abonados Descripcin de Hechos Nombre Hecho No Recibo de caja No de crdito No Desembolso No de cuota Abono final Monto total abono Monto total cuota Abono a Principal Abono a Intereses Abono a Servicios Abono a Comisin Mtto Valor Dias_mora Monto Interes Mora Recargo Instrumento de pago Descripcin Hecho Representa el nmero actual del recibo de caja que respalda el pago hecho por el cliente Representa el nmero actual del crdito Representa el nmero de desembolso que se paga acualmente Indica el numero actual de la cuota que se paga Indica si el abono actual cancela el desembolso hecho Indica el total que el cliente abono a esta cuota en el da actual Indica el monto total que el cliente debe pagar en esta cuota. Monto que se abona al principal del crdito Monto que se abona a los intereses del crdito Monto que se abona a los servicios del crdito Monto que se abona a la Comisin del crdito Monto que se paga en concepto de mantenimiento del valor Cantidad de das en que ha incurrido en mora esta cuota, contados despus de la fecha de vencimiento de la cuota que paga Cantidad pagada en concepto de interes moratorio Cantidad pagada en concepto de multa por pago tardo Indica el instrumento monetario con el que se efectan pagos (Efectivo, Cheque personal, Cheque gerencia) RAD N/A N/A N/A N/A Sum Sum Sum Sum Sum Sum Sum N/A Sum Sum
Proyeccin_Recuperacin hechos
Fecha_ Vencimiento Fuente de Financiamiento
Identificador Fuente Da Vence
Analista
Convenio
Identificador Convenio
Cliente Proyeccin Recuperacin

Identificador Cliente Cliente
Modo de Pago
Modalidad Pago
Sucursal
No Sucursal
Tasas
Inters
Producto
Producto/Servicio
Proyeccin_Recuperacin Descripcin de Hechos Nombre Hecho No de crdito No Desembolso No de cuota Cuota final Monto cuota Monto en Mora Principal Intereses Servicios Comisin Mtto Valor Descripcin Hecho Representa el nmero del crdito que debe ser abonado Indica el numero desembolso de la cuota que se paga Indica el numero actual de la cuota que se paga Indica si la cuota actual cancela el desembolso hecho Indica el monto total que el cliente debe pagar de cuota. Indica el monto total que el cliente debe pagar en esta cuota. Monto que debe ser recuperado en concepto de principal del crdito Monto que debe ser recuperado en concepto de intereses del crdito Monto que debe ser recuperado en concepto de servicios del crdito Monto que debe ser recuperado en concepto de comisin del crdito Monto que se paga en concepto de mantenimiento del valor RAD N/A N/A N/A N/A Sum Sum Sum Sum Sum Sum Sum
Nivel 2: grano Semanal

Presupuesto_Recuperacin hechos
Fecha_ Vencimiento
Semana Vence
Presupuesto Recuperacin
Sucursal
No Sucursal
Analista
Presupuesto_Recuperacin Descripcin de Hechos Nombre Hecho Presupuesto_Recup Proyeccin_Recu Ejecutado_Recu Descripcin Hecho Representa el valor que se presupuest a ser recuperado para determinada semana del ao Indica el valor que se proyecta a recuperar para dicha semana del ao (agregado semanal de la estrella proyeccin) Indica el monto real que se recuper en dicha semana RAD sum sum sum
Creditos_Abonados_Semanales Hechos
Modo de Pago
moneda
Fecha
Semana
Circusntancia
Cirecunstancia
Crditos Abonados
Analista
Tasas
Identificador Tasas
Producto
Producto/Servicio
Sucursal Convenio
Identificador Convenio No Sucursal
Crditos_Abonados Descripcin de Hechos Nombre Hecho Descripcin Hecho Creditos cancelados Cantidad de creditos que se cancelaron en la semana Monto total abono Indica el total que la empresa recibio de abono a esta semana Abono a Principal Monto que se abona al principal Abono a Intereses Monto que se abona a los intereses Abono a Servicios Monto que se abona a los servicios Abono a Comisin Monto que se abona a la comisin Mtto Valor Monto que se paga en concepto de mantenimiento del valor Monto Interes Cantidad pagada en concepto de interes moratorio Moratorios Recargo Cantidad pagada en concepto de multa por pago tardo
RAD sum Sum Sum Sum Sum Sum Sum Sum Sum
ANEXO G: CORRESPONDENCIA FUENTE DESTINO Y RUTINAS ETL
Correspondencia Fuente Destino

Tabla de Correspondencia Fuente Destino Tabla Destino Columna Destino Tipo de Datos Integer Varchar Varchar Integer Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Datetime Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Datetime Varchar Varchar Varchar Varchar Varchar Varchar Integer Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Integer Integer Integer Integer Varchar Integer Varchar Varchar Varchar Varchar Datetime Long Tabla / Archivo Fuente 9 climide 60 climide climide 40 climide 5 climide 20 climide 40 climide 40 climide 25 climide 17 climide 100 climide 3 climide climide climide climide climide climide climide climide climide climide climide climide climide climide climide climide climide Campo Fuente Notas transformacin de Datos
Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Cliente_Dims Sucursal_Dims Sucursal_Dims Sucursal_Dims Sucursal_Dims Sucursal_Dims Sucursal_Dims Sucursal_Dims Sucursal_Dims Sucursal_Dims Sucursal_Dims Hora_Dims Hora_Dims Hora_Dims Hora_Dims Analista_Dims Analista_Dims Analista_Dims Analista_Dims Analista_Dims Analista_Dims
Cliente_Clave Cod_Cliente Direccion_Dom_Cliente Id_Domicilio_Cliente Barrio_Dom_Cliente_ Descr Distrito_Dom_Cliente Sucursal_Asignada Ciudad_Dom_Cliente Depto_Dom_Cliente Pais_Dom_Cliente Id_Cliente Nombre_Cliente Tipo_Cliente Fecha_Primer_Servicio Direccion_Cobro_Cliente Barrio_Cobro_Cliente Distrito_Cobro_Cliente Ciudad_Cobro_Cliente Depto_Cobro_Cliente Calificacion_Cliente Clasificacion_Cliente Sexo_Cliente Fecha_Nacimiento_ Cliente Demog_Cliente Activ_Econo_Cliente Educacion_Cliente Casa_Cliente Industria Grupo_Industria Sucursal_Clave Id_Sucursal Nombre_Sucursal Direccion_Sucursal Barrio_Sucursal Distrito_Sucursal Ciudad_Sucursal Depto_Sucursal Gerente_Sucursal Cant_Empl_Sucursal Hora_Clave Minuto Hora Bandera_Am_Pm Analista_Clave Id_Analista Nombre_Analista Estado_Analista Sexo_Analista Fecha_Nac_Analista
Campo identidad de la tabla ccodcli cdirdom ccoddom cdirdom ccodofi cdirdom ccodofi cnudoci cnomcli cclaper dregist no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento otras calificaciones son externas cambiar codigo a etiqueta de sexo cambiar soltero, casado a perfil demog no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento Campo identidad de la tabla 2 20 60 35 4 20 35 60 tabtofi tabtofi ccodofi ccodofi establecer etiqueta de acuerdo al codigo incluir direccion en rutina programada incluir barrio en rutina programada incluir distrito en rutina programada establecer etiqueta de acuerdo al codigo establecer etiqueta de acuerdo al codigo incluir distrito en rutina programada incluir distrito en rutina programada Campo identidad de la tabla separar minuto separar hora y pasar a formato am/pm determinar bandera Campo identidad de la tabla 4 Tabtusu 60 Tabtusu 20 Tabtusu 9 ccodana cnomana no disponible digitalmente por el momento no disponible digitalmente por el momento separa direccion de barrio separar barrio de direccion lista de barrio contra distrito extraer ciudad de direccin domicilio asociar sucursal con depto prestamos solo a nacionales numero de cedula pesona juridica, natural con negocio, natural sin negocio
60 40 5 40 20 3 10 9 20 30 12 5 20 20
ccalcli cclaci csexo dnacimi cestciv
tabtofi tabtofi
ccodofi ccodofi
cjgdlog cjgdlog 2 cjgdlog
chortrx chortrx chortrx

Tabla Destino Columna Destino Tipo de Datos Varchar Datetime Datetime Varchar Varchar Varchar Varchar Varchar Integer Datetime Integer Integer Integer Integer Varchar Varchar Varchar Datetime Varchar Varchar Integer Varchar Integer Integer Varchar Integer Varchar Integer Varchar Integer Integer Integer Varchar Varchar Varchar Varchar Varchar Varchar Varchar Integer Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Long Tabla / Archivo Fuente 12 Campo Fuente Notas transformacin de Datos
Analista_Dims Analista_Dims Analista_Dims Analista_Dims Analista_Dims Analista_Dims Analista_Dims Analista_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Fecha_Dims Modo_Pago_Dims Modo_Pago_Dims Modo_Pago_Dims Modo_Pago_Dims Modo_Pago_Dims Modo_Pago_Dims Modo_Pago_Dims Modo_Pago_Dims Producto_Dims Producto_Dims Producto_Dims Producto_Dims Producto_Dims Producto_Dims Producto_Dims Producto_Dims Producto_Dims Producto_Dims Producto_Dims Producto_Dims
Educacion_Analista Fecha_Orig_Contr_ Analista Fecha_Actual_Contr_ Analista Direccion_Dom_ Analista Barrio_Dom_Analista Distrito_Dom_Analista Ciudad_Dom_Analista Departamento_Analista Fecha_Clave Dia No_Dia_En_Mes_Calendar No_Dia_En_Anio_Calendar No_Dia_En_Mes_Fiscal No_Dia_En_Anio_Fiscal Dia_De_Semana Festivo_Bandera Tipo_De_Dia Semana_Calendar No_Semana_Calendar Mes_Calendar No_Mes_Calendar Trimestre_Calendar No_Trimestre_Calendar Anio_Calendar Semana_Fiscal No_Semana_Fiscal Mes_Fiscal No_Mes_Fiscal Trimestre_Fiscal No_Trimestre_Fiscal Anio_Fiscal Modo_Pago_Clave Modo_Pago Id_Periodo_Pago Periodo_Pago Id_Frecuencia_Pago Descr_Frecuencia_Pago Id_Moneda_Pago Moneda_Pago Producto_Clave Id_Producto Descr_Producto Descr_Producto_Larga Id_Sector_Econo Descr_Sector_Econo Id_Destino Descr_Destino Id_Clase_Producto Descr_Clase_Producto Id_Categoria_Producto Descr_Categoria_Producto
no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento no disponible digitalmente por el momento Campo identidad de la tabla generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado generado por procedimiento programado Campo identidad de la tabla establecer etiqueta de acuerdo al id
60 40 5 40 40
10 2 2 4 16 7
13 18 9
7 2 12 2 15 1 9
credscs credscs credscs credscs credscs credscs
ctipper ctipper cdiasug cdiasug cmoneda cmoneda
establecer etiqueta de acuerdo al id establecer etiqueta de acuerdo al id establecer etiqueta de acuerdo al id Campo identidad de la tabla
2 12 60 2 30 2 30 2 60 2 60
cremcre cremcre cremcre cremcre cremcre cremcre cremcre cremcre cremcre cremcre cremcre
ccodprd ccodprd ccodprd csececo csececo cdescre cdescre
establecer etiqueta de acuerdo al id establecer etiqueta de acuerdo al id establecer etiqueta de acuerdo al id establecer etiqueta de acuerdo al id no establecidas todavia no establecidas todavia por el momento solo existe 01 categoria 01 corresponde a crdito

Tabla Destino Columna Destino Tipo de Datos Integer Integer Integer Integer Integer Integer Integer Integer Integer Integer Integer Integer Numeric Numeric Numeric Numeric Numeric Integer Varchar Varchar Integer Numeric Long Tabla / Archivo Fuente credkar credkar cjgdlog credkar credkar credkar credkar credkar credkar credkar credkar credkar credkar credkar credkar credkar credkar credkar Campo Fuente dfecsis dfecpro dfectrx ccodcta ccodcta ccodcta ccodcta ccodcta Notas transformacin de Datos
Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts Abono_Credito_Facts
Fecha_Clave Fecha_Vence_Clave Hora_Clave Analista_Clave Cliente_Clave Sucursal_Clave Convenio_Clave Producto_Clave Tasas_Clave Modo_Pago_Clave Fuente_Finan_Clave Circunstancia_Clave Monto_Total_Abono Principal_Abono Interes_Abono Servicios_Abono Interes_Mora Dias_Mora No_Recibo_Caja No_Credito No_Cuota Monto_Total_Cuota
asociar fecha con la clave en fecha_dim asociar fecha con la clave en fecha_vence_dim obtener la hora con respecto a la fecha asociar la cta con el analista en cremcre asociar la cta con el cliente en cremcre left(ccodcta,2) para el codigo oficina asociar la cta con el convenio en cremcre asociar la cta con ccodpro, cdescre y csececo en cremcre asociar la cta con datos en credscs asociar la cta con la cfuefin en cremcre asociar la cta con datos en cremcre revisar el cconcep el asociado con cj(caja) revisar el cconcep el asociado con kp capital in cconcep='02' mo efectuar calculo de dfecpro_dfecsis
82 82 72 72 72
10 12 72
Abono_Credito_Facts
Abono_Final
Varchar Integer Integer Integer Integer Integer Integer Integer Integer
ccodcta ccodcta ccodcta ccodcta nmonto nmonto nmonto nmonto nmonto dfecpro dfecsis credkar cnrodoc credkar ccodcta credkar cnrocuo credppg,c ncapitaredgas ncappag +intere nintpag credppg credkar credkar credppg cremcre cremcre cremcre cremcre cremcre dfecsis dfecpro dfecven ccodana ccodcli ccodcta ccodgru ccodpro, cdescre, csececo ccodcta ccodcta ccodcta cfuefin nmonapr
Numero max del abono para la cta en credppg asociar fecha con la clave en fecha_dim asociar fecha con la clave en fecha_vence_dim asociar fecha con la clave en fecha_final_dim asociar analista con la clave en analista_dim asociar el cliente con la clave en cliente_dim left(ccodcta,2) para el codigo oficina asociar el convenio con la clave en convenio_dim asociar ccodpro, cdescre y csececo con la clave en producto_dims
Gestion_Credito_Facts Fecha_Clave Gestion_Credito_Facts Fecha_Vence_Clave Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Fecha_Final_Clave Analista_Clave Cliente_Clave Sucursal_Clave Convenio_Clave
Gestion_Credito_Facts Producto_Clave
Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts Gestion_Credito_Facts
Tasas_Clave Modo_Pago_Clave Garantia_Clave Estado_Clave Fuente_Finan_Clave Monto_Total_Credito Principal Comision Servicios Mtto_Valor Cargos_Legales Intereses Intereses_Mora Recargos Plazo_Dias
Integer Integer Integer Integer Integer Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Numeric Integer
cremcre credscs cremcre credkar cremcre 17.2 14.2 8.2 8.2 6.2 6.2 8.2 7.2 8.2 cremcre cremcre cremcre
asociar la cta con datos en credscs asociar la cta con la cfuefin en cremcre asociar la cta con datos en cremcre obtenidas de las claves de las dimensiones
cremcre cremcre cremcre cremcre

Tabla Destino Columna Destino Tipo de Datos Numeric Numeric Varchar Integer Integer Integer Integer Integer Integer Long Tabla / Archivo Fuente 10.2 cremcre 19.2 cremcre 12 cremcre Campo Fuente Notas transformacin de Datos
Gestion_Credito_Facts Cuota Gestion_Credito_Facts Monto_Garantia Gestion_Credito_Facts No_Credito Proyeccion_Recu_Facts Proyeccion_Recu_Facts Proyeccion_Recu_Facts Proyeccion_Recu_Facts Proyeccion_Recu_Facts Fecha_Vence_Clave Analista_Clave Cliente_Clave Sucursal_Clave Convenio_Clave
ccodcta dfecven ccodana ccodcli ccodcta ccodgru ccodpro, cdescre, csececo ccodcta ccodcta asociar fecha con la clave en fecha_final_dim asociar analista con la clave en analista_dim asociar el cliente con la clave en cliente_dim left(ccodcta,2) para el codigo oficina asociar el convenio con la clave en convenio_dim asociar ccodpro, cdescre y csececo con la clave en producto_dims obtenidas de las claves de las dimensiones asociar la cta con datos en credscs asociar la cta con la cfuefin en cremcre igual que en abono
Proyeccion_Recu_Facts Producto_Clave
Proyeccion_Recu_Facts Proyeccion_Recu_Facts Proyeccion_Recu_Facts Proyeccion_Recu_Facts Proyeccion_Recu_Facts
Tasas_Clave Modo_Pago_Clave Fuente_Finan_Clave Monto_Cuota Principal
Integer Integer Integer Numeric Numeric Numeric Numeric Numeric Varchar Integer Integer
10.2 credppg 10.2 credppg 8.2 credgas 8.2 credppg 6.2 credppg 12 credppg credppg credppg
Proyeccion_Recu_Facts Servicios Proyeccion_Recu_Facts Intereses Proyeccion_Recu_Facts Proyeccion_Recu_Facts Proyeccion_Recu_Facts Proyeccion_Recu_Facts Mtto_Valor No_Credito No_Cuota Cuota_Final
ncapitancappag nmongasnmopag intere nintpag ccodcta cnrocuo
para ctipgas = 02
igual que en abono
Rutinas ETL
Rutinas de Extraccin, Transformacin y Carga
Figura 1. Conjuntos de Paquetes de DTS para la carga inicial de Datos.
En la figura anterior se puede observar dentro de la carpeta de Servicios de Transformacin de Datos de Microsoft SQL Server 2000, los paquetes que se encargan de realizar el proceso de Extraccin, Transformacin y Datos (ETL). Los DTS se encargan de poblar el Data Mart con los datos que sean necesarios, de aplicar transformaciones que se requieran auxilindose del rea de preparacin de datos, donde los datos intermedios son depositados temporalmente, mientras se encuentra en proceso, a la espera de ser transformados para llegar luego a su destino final.
Rutinas ETL
Figura 2- Paquete DTS del proceso de transformacin de datos para la tabla Abono_Credito_Facts
En la figura se puede apreciar que un paquete DTS esta conformado de un conjunto de tareas de diversa ndole y conexiones a fuentes de datos. Para ejecutar las transformaciones requeridas se utiliza la ejecucin de un proceso de tareas secuenciales, y en algunos casos en paralelo, la definicin de la secuencia se puede observar claramente con los smbolos de flechas que muestran el orden que sigue el flujo de datos, stas flechas indican cuales son las siguientes tareas en ejecutarse en dependencia del xito, finalizacin o fracaso de la tarea. Los iconos de conexiones hacen referencia a orgenes de datos especificando una fuente y un destino para el proceso de transformacin, tambin hay tareas que ejecutan sentencias SQL. Otro elemento que se observa en el extremo inferior derecho de la figura es el icono que corresponde a una llamada a programa y que permite el paso de los parmetros respectivos; esta herramienta es muy til en los casos que necesiten la aplicacin de programas que puedan realizar las transformaciones necesarias.
Rutinas ETL
Figura 3- Paquete que crea la Dimension Analista
En la figura 3 se aprecia que cierta informacin del Data Mart debe ser poblada a partir de datos almacenados en tablas auxiliares que pertenecen al sistema transaccional, pero que no eran administradas por un Sistema Gestor de Bases de Datos, por lo que se necesitaba que la herramienta ETL contar con conectores que pudieran acceder a dicha fuente. Este es un elemento importante a la hora de elegir una herramienta de automatizacin de la ETL, la herramienta seleccionada debe ser capaz de obtener los datos necesarios a partir de todas las fuentes de Datos que se requieran, de lo contrario, se perdera mucha flexibilidad en el tratamiento que se le diera a los datos.
Rutinas ETL
Figura 4- Cdigo de tranformacion de una tarea
En la figura 4 se aprecia una muestra del cdigo que define las transformaciones que sobre los registros de una tabla realiza una tarea que pertenece a un determinado paquete. En el paquete de la figura, en concordancia con lo previamente definido en la tabla de correspondencia se obtiene el valor que guardaran los campos ciudad y departamento de la dimensin Clientes, sobre la base de la direccin de domicilio del Cliente.
Rutinas ETL
Figura 5 - Cdigo en lenguaje Visual Basic Script
ANEXO H: REPORTES OBTENIBLES
Reportes Obtenibles
INFORME DE RECUPERACIONES DE CREDITOS

Datos Demogrficos de Clientes - Abonos Realizados
Edad
Toda Edad
Datos Moneda Credito Principal Abono Principal Cor Genero Cliente

FEMENINO CASADO DIVORCIADO SOLTERO UNION LIBRE VIUDO NO ESPECIFICA MASCULINO CASADO DIVORCIADO SOLTERO UNION LIBRE VIUDO NO ESPECIFICA
Demog Cliente
CORDOBAS
8351305.81 4809182.55 79893.52 2891173.05 391393.74 178048.32 1614.63 8816323.18 6332986.36 35595.58 1960477.17 460562.52 22436.62 4264.93
DOLARES
390228.39 243297.36 5055.33 113303.4 9247.41 19324.89 -457045.11 355905.58 3817.09 83449.66 10111.85 366.18 3394.75
CORDOBAS
8351305.81 4809182.55 79893.52 2891173.05 391393.74 178048.32 1614.63 8816323.18 6332986.36 35595.58 1960477.17 460562.52 22436.62 4264.93
DOLARES
5652027.79 3524759.83 73262.67 1640226.92 133902.77 279875.6 -6621769.47 5157248.67 55076.2 1208361.27 146624.09 5313.37 49145.87
Total general
17167628.99
847273.5
17167628.99
12273797.26
Reportes Obtenibles
Reportes Obtenibles
Reportes Obtenibles
INFORME DE GESTION DE CREDITOS

Sucursal y Estado por Periodo y Moneda del Credito Moneda Fecha_Semana Toda Moneda NOVIEMBRE
Id Estado Datos Vigente Cancelado Sucursal Creditos Principal_cor Creditos Principal_cor Managua 242 C$ 3,928,566.20 54 C$ 1,162,109.79 Leon 174 C$ 3,237,359.26 36 C$ 661,592.13 Matagalpa 82 C$ 2,833,788.55 52 C$ 546,753.97 Rio blanco 179 C$ 5,099,335.45 50 C$ 822,634.16 Masaya 56 C$ 1,415,076.96 42 C$ 389,976.23 Esteli 76 C$ 1,926,296.23 29 C$ 504,324.85 Rivas 101 C$ 1,896,087.74 49 C$ 530,600.58 Sebaco 45 C$ 1,950,734.72 22 C$ 706,829.25 Chinandega 108 C$ 2,485,051.60 17 C$ 306,834.62 Ivan Montenegro 115 C$ 2,945,076.26 24 C$ 251,490.12 Total general 1178 C$ 27,717,372.97 375 C$ 5,883,145.70
ANEXO I: GLOSARIO
GLOSARIO
Agregacin: Actividad de combinar datos desde mltiples tablas para formar una unidad de informacin ms compleja, necesitada frecuentemente para responder consultas del Data Warehouse en forma ms rpida y fcil. Atributos: Conjunto de campos de las tablas de una base de datos transaccional o analtica que definen la informacin que se almacena en una tabla en particular Base de datos multidimensional: Base de datos diseada para procesamiento analtico on-line (OLAP). Estructurada como un hipercubo con un eje por dimensin. Data Mart: Conjunto de hechos y datos organizados para soporte a la toma de decisiones basados en la necesidad de un rea o departamento especfico. y sus datos no tienen porque tener las mismas fuentes que los de otro DataMart Data Mining: La extraccin de informacin predecible escondida en grandes bases de datos para el anlisis de los datos con el objetivo de descubrir relaciones, patrones, o asociaciones desconocidas. Data Warehouse: Sistema de Base de Datos que almacena una gran cantidad de datos transaccionales integrados y enriquecidos para ser usados para anlisis por usuarios especializados (encargados de tomar decisiones en la empresa). Dato: Es la representacin computarizada de la informacin en todo negocio. Existen muchas variedades de datos que se pueden almacenar en las computadoras. Los datos que deben ser incluidos en el Data Warehouse son aquellos datos comprensibles y consistentes en si mismos que son necesarios para manejar el negocio como un todo y en sus partes individuales (indicadores). Datos anormales: Datos que resultan de errores (por Ej. Errores en el ingreso de datos durante la carga) o que representan eventos inusuales. Datos Derivados: Datos que resultan luego de efectuar operaciones de transformacin sobre un conjunto dado de datos origen, con el objetivo de ser de mayor significado para el proceso de toma de decisiones. Datos Peridicos: Conjunto de datos generados o extrados con cierta periodicidad a partir de los sistemas transaccionales para alimentar el entorno analtico de la organizacin DBMS (Data Base Management System): Sistema Relacional que se encarga del control y seguridad de los datos organizados en tablas proveyndoles de un entorno en que las aplicaciones clientes pueden realizar sus operaciones sin poner en riesgo la estructura de datos del modelo. Adems realiza control de integridad y presenta la capacidad de realizar consultas a los datos almacenados.
Diccionario de Datos: Un compendio de definiciones y especificaciones para las categoras de datos y sus relaciones. Dimensin: Conjunto de entidades similares agrupadas en una tabla; que sirve como llave de bsqueda (actuando como ndice), o como mecanismo de seleccin de datos. Dentro del esquema estrella, corresponde a las tablas que estn unidas a la tabla central a travs de sus respectivas llaves. La cantidad de estas tablas le otorgan la caracterstica de multidimensionalidad a esta estrategia. Drill Down: Exponer progresivamente un nivel de mayor detalle del elemento que resulte seleccionado dentro de un reporte o consulta Drill-Up: Es el efecto contrario a drill-down. Significa ver menos nivel de detalle, sobre la jerarqua significa generalizar o sumarizar, es decir, subir en el rbol jerrquico. Entregables: Resultado que se espera obtener como producto de la aplicacin de un procedimiento enunciado previamente. ETL (Extraction, Transformation and Load): Pasos por los que atraviesan los datos para ir desde el sistema OLTP ( o la fuente de datos utilizada) al entorno analitico. Extraccin, se refiere al mecanismo por medio del cual los datos son ledos desde su fuente original. Transformacin (tambin conocida como limpieza) es la etapa por la que puede atravesar una base de datos para estandarizar los datos de las distintas fuentes, normalizando y fijando una estructura para los datos. Finalmente est la Carga, que consiste bsicamente en llevar los datos ledos y estandarizados al Data Warehouse (puede ser remota o localmente). Hechos: Conjunto de medidas de negocio interrelacionadas que se agrupan en una tabla; con el objetivo de representar una evaluacin cuantitativa del desempeo de la organizacin. Dentro del esquema estrella, corresponde a la tabla central a la que se encuentran unidas las dimensiones por medio de llaves externas y cuyo conjunto conforma la llave primaria de la tabla de hechos, lo cual permite que las dimensiones acten como ndice de bsqueda. Jerarqua: Es un conjunto de atributos descriptivos que permite que a medida que se tenga una relacin de muchos a uno se ascienda en la jerarqua. Por ejemplo: los Centros de Responsabilidad estn asociados a un Tipo de Unidad, el cual pueden corresponder a una gerencia, subgerencia, superintendencia, etc.; por otro parte, cada CR est asociado a otro CR a nivel administrativo y, tambin existe una clasificacin a nivel funcional. Metadatos: Son datos que describen el significado de la estructura de los datos del negocio, as como tambin la manera en que stos son creados, accedidos y usados, lo que asegurar que los datos del negocio sean usados de manera completa y consistente.
Modelo de Datos Corporativo: Representa la definicin de datos que correponde a la descripcin de las actividades en las que se desempea la empresa y de los objetos del mundo real (clientes, localidades y productos) con los que se interrelaciona la organizacin. Este modelo de datos sirve de fundamento para sistemas de procesamiento de transacciones y sistemas de soporte a la toma de decisiones. ODS (Operational Data Store): es la construccin arquitectnica donde los datos operacionales que han sido integrados colectivamente son almacenados. Es una coleccin de datos integrados, orientados a temas (comnmente basada en el cliente), tomada directamente de los sistemas operacionales para soportar monitoreo operacional. OLAP - Procesamiento analtico on-line (On Line Analytical Processing): Conjunto de principios que proveen una ambiente de trabajo dimensional para soporte decisional. se refiere a aplicaciones de bases de datos orientadas a arreglos que permite a los usuarios ver, navegar, manipular y analizar bases de datos multidimensionales. OLTP (On-line Transaction Processing): Sistema transaccional diario (o en detalle) que mantiene los datos operacionales del negocio. Script: Programa o secuencia de instrucciones que es interpretado o ejecutado por otro programa en lugar del procesador de la computadora. Sistema de Soporte de Decisiones: Sistema de aplicaciones automatizadas que asiste a la organizacin en la toma de decisiones mediante un anlisis estratgico de la informacin histrica. SGBD (Sistema Gestor de Bases de Datos): ver DBMS Snapshot: Imagen instantnea de los datos contenidos en un sistema en un tiempo dado. Sumarizacin: Actividad de incremento de la granularidad de la informacin en una base de datos. La sumarizacin reduce el nivel de detalle, y es muy til para presentar los datos para apoyar al proceso de Toma de Decisiones.

Ralph Kimball

Cargado por

Copyright:

Formatos disponibles

Ralph Kimball

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ralph Kimball

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD AMERICANA FACULTAD DE INGENIERIA

GUA METODOLGICA PARA LA DEFINICIN Y DESARROLLO DE UN DATA WAREHOUSE

Br. ERICKA GRACIELA SEVILLA BERROS

Monografa para optar al grado de INGENIERO EN SISTEMAS

ING. CARLOS ALBERTO ZEPEDA S.

Managua, Nicaragua, Marzo 2003

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Ilustracin I-1 Diferencias entre Sistemas Operacionales y Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Ilustracin I-2. Arquitectura de tres capas

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Ilustracin I-3. Estructura BII.

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Ilustracin I-4. Estructura BIG

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Ilustracin I-5. Metodologa Data Warehouse de Inmon

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Ilustracin I-6 Ciclo de Vida Dimensional para implementar un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Tabla I-2. Marco de Trabajo de la Arquitectura

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse

Gua Metodolgica para la Definicin y Desarrollo de un Data Warehouse