UCI Sustento del uso justo de materiales protegidos por derechosde autor para fines educativos

Transcripción

1

2 UCI Sustent del us just de materiales prtegids pr derechsde autr para fines educativs El siguiente material ha sid reprducid, cn fines estrictamente didáctics e ilustrativs de ls temas en cuestión, se utilizan en el campus virtual de la Universidad para la Cperación Internacinal UCI - para ser usads exclusivamente para la función dcente y el estudi privad de ls estudiantes en el curs Administración de la Infrmación para la tma de Decisines perteneciente al prgrama académic MATI. La UCI desea dejar cnstancia de su estrict respet a las legislacines relacinadas cn la prpiedad intelectual. Td material digital dispnible para un curs y sus estudiantes tiene fines educativs y de investigación. N media en el us de ests materiales fines de lucr, se entiende cm cass especiales para fines educativs a distancia y en lugares dnde n atenta cntra la nrmal expltación de la bra y n afecta ls intereses legítims de ningún actr. La UCI hace un USO JUSTO del material, sustentad en las excepcines a las leyes de derechs de autr establecidas en las siguientes nrmativas: a- Legislación cstarricense: Ley sbre Derechs de Autr y Derechs Cnexs, N.6683 de 14 de ctubre de artícul 73, la Ley sbre Prcedimients de Observancia de ls Derechs de Prpiedad Intelectual, N artícul 58, permiten el cpiad parcial de bras para la ilustración educativa. b- Legislación Mexicana; Ley Federal de Derechs de Autr; artícul 147. c- Legislación de Estads Unids de América: En referencia al us just, mencina: "está cnsagrad en el artícul 106 de la ley de derech de autr de ls Estads Unids (U.S,Cpyright - Act) y establece un us libre y gratuit de las bras para fines de crítica, cmentaris y nticias, reprtajes y dcencia (l que incluye la realización de cpias para su us en clase)." d- Legislación Canadiense: Ley de derechs de autr C-11 Referids a Excepcines para Educación a Distancia. e- OMPI: En el marc de la legislación internacinal, según la Organización Mundial de Prpiedad Intelectual l previst pr ls tratads internacinales sbre esta materia. El artícul 10(2) del Cnveni de Berna, permite a ls países miembrs establecer limitacines excepcines respect a la psibilidad de utilizar lícitamente las bras literarias artísticas a títul de ilustración de la enseñanza, pr medi de publicacines, emisines de radi grabacines snras visuales. Además y pr indicación de la UCI, ls estudiantes del campus virtual tienen el deber de cumplir cn l que establezca la legislación crrespndiente en materia de derechs de autr, en su país de residencia. Finalmente, reiterams que en UCI n lucrams cn las bras de tercers, sms estricts cn respect al plagi, y n restringims de ninguna manera el que nuestrs estudiantes, académics e investigadres accedan cmercialmente adquieran ls dcuments dispnibles en el mercad editrial sea directamente ls dcuments, pr medi de bases de dats científicas, pagand ells misms ls csts asciads a dichs access.

3 Data Warehusing y metdlgía Hefest Ing. Bernabeu Ricard Dari Córdba, Argentina Lunes 19 de Juli de Cpyright 2007 Ing. Bernabeu, Ricard Dari. Se trga permis para cpiar, distribuir y/ mdificar este dcument baj ls términs de la Licencia de Dcumentación Libre de GNU, Versión 1.2 cualquier tra versión psterir publicada pr la Free Sftware Fundatin; requiriend permanecer invariable el nmbre de la metdlgía (HEFESTO), en cuant al diseñ de su lgtip, debe mantenerse el estil medieval para su cnfección y letra O representada pr el símbl de radiactividad ( ). Una cpia de la licencia está incluida en la sección titulada Licencia de Dcumentación Libre de GNU. I Data Warehusing: Investigación y Sistematización de Cncepts RESUMEN 1ra parte En esta primera parte de la publicación, se sistematizarán tds ls cncepts inherentes al Data Warehusing, haciend referencia a cada un de ells en frma rdenada, en un marc cnceptual clar, en el que se desplegarán sus características y cualidades, y teniend siempre en cuenta su relación interrelación cn ls demás cmpnentes del ambiente. Inicialmente, se definirá el cncept de Business Intelligence y sus respectivas características. Seguidamente, se intrducirá al Data Warehusing y se expndrán sus aspects más relevantes y significativs. Lueg, se precisarán y detallarán tds ls cmpnentes que intervienen en su arquitectura, de manera rganizada e intuitiva, atendiend su interrelación. Finalmente, se describirán alguns cncepts cmplementaris que deben tenerse en cuenta. El principal bjetiv de esta investigación, es ayudar a cmprender el cmplej ambiente del Data Warehusing, sus respectivs cmpnentes y la interrelación entre ls misms, así cm también cuáles sn sus ventajas, desventajas y características prpias. Es pr ell, que se hará énfasis en la sistematización de tds ls cncepts de la estructura del Data Warehusing, debid a que la dcumentación existente se enfca en tratar temas independientes sin tener en cuenta su vinculación y referencias a trs cmpnentes del mism. Cabe destacar que este dcument ha sid publicad a cn la Licencia de Dcumentación Libre de GNU (GFDL GNU Free Dcumentatin License), para permitir y prteger su libre difusión, distribución, mdificación y utilización, en ps de su futura evlución y actualización.

4 1. Business Intelligence 1.1 Intrducción Actualmente, en las actividades diarias de cualquier rganización, se generan dats cm prduct secundari, que sn el resultad de tdas las transaccines que se realizan. Es muy cmún, que ls misms se almacenen y administren a través de sistemas transaccinales en bases de dats relacinales. Per, la idea central de esta publicación, es que ests dejen de sl ser simples dats, para cnvertirse en infrmación que enriquezca las decisines de l@s usuari@s. Precisamente, la inteligencia de negcis (Business Intelligence - BI), permite que el prces de tma de decisines esté fundamentad sbre un ampli cncimient de sí mism y del entrn, minimizand de esta manera el riesg y la incertidumbre. Además, prpicia que las rganizacines puedan traducir sus bjetivs en indicadres de estudi, y que ests puedan ser analizads desde diferentes perspectivas, cn el fin de encntrar infrmación que n sl se encargue de respnder a preguntas de l que está sucediend ya sucedió, sin también, que psibilite la cnstrucción de mdels, mediante ls cuales se pdrán predecir events futurs. Cuand se nmbra el términ inteligencia, se refiere a la aplicación cmbinada de infrmación, habilidad, experiencia y raznamients, para reslver un prblema de negci. Cabe destacar, que la aplicación de slucines BI n es sl para grandes-medianas empresas, sin para quien desee tmar decisines a través del análisis de sus dats. Es pr ell que las slucines BI n sl se enfcarán a reslver temas relacinads a: aumentar la rentabilidad, disminuir csts y btener la famsa ventaja cmpetitiva. De acuerd a l plantead anterirmente se presentarán ds grandes ejempls de la aplicación de BI, una en una empresa de ventas de prducts, la tra en una bibliteca vecinal: 1. Empresa de venta de prducts: en este cas la aplicación de BI pdrá reslver las siguientes preguntas. Quiénes sn l@s mejres client@s?. Cóm minimizar csts y maximizar las prestacines?. Cuál será el prnóstic de ventas del próxim mes?. 2. Bibliteca vecinal: en este cas la aplicación de BI pdrá reslver las siguientes preguntas. Cuál es la temática más cnsultada?. Qué días hay mayr cncurrencia, y pr qué?. Qué librs deben ser adquirids?.

5 1.2 Definición Se puede describir BI, cm un cncept que integra pr un lad el almacenamient y pr el tr el prcesamient de grandes cantidades de dats, cn el principal bjetiv de transfrmarls en cncimient y en decisines en tiemp real, a través de un sencill análisis y explración. La definición antes expuesta puede representarse a través de la siguiente fórmula: Este cncimient debe ser prtun, relevante, útil y debe estar adaptad al cntext de la rganización. Existe una frase muy ppular acerca de BI, que dice: Inteligencia de Negcis es el prces de cnvertir dats en cncimient y el cncimient en acción, para la tma de decisines. BI hace hincapié en ls prcess de reclectar y utilizar efectivamente la infrmación, cn el fin de mejrar la frma de perar de una rganización, brindand a sus usuari@s, el acces a la infrmación clave que necesitan para llevar a cab sus tareas habituales y más precisamente, para pder tmar decisines prtunas basadas en dats crrects y certers. Al cntar cn la infrmación exacta y en tiemp real, es psible, aparte de l ya mencinad, identificar y crregir situacines antes de que se cnviertan en prblemas y en ptenciales pérdidas de cntrl de la empresa, pudiend cnseguir nuevas prtunidades readaptarse frente a la currencia de sucess inesperads. La Inteligencia de Negcis tiene sus raíces en ls Sistemas de Infrmación Ejecutiva (Executive Infrmatin Systems EIS) y en ls Sistemas para la Tma de Decisines (Decisin Supprt Systems DSS), per ha evlucinad y se ha transfrmad en td un cnjunt de tecnlgías capaces de satisfacer a una gran gama de usuari@s junt a sus necesidades específicas en cuant al análisis de infrmación. NOTA: Ls DSS sn una clase especial de sistemas de infrmación cuy bjetiv es analizar dats de diferentes prcedencias y brindar sprte para la tma de decisines. 1.3 Prces de BI A fin de cmprender cóm una rganización puede crear inteligencia de sus dats, para, cm ya se ha mencinad, prveer a l@s usuari@s finales prtuna y acertadamente acces a esta infrmación, se describirá a cntinuación el prces de BI. El mism está dividid en cinc fases, las cuales serán explicadas teniend cm referencia el siguiente gráfic, que sintetiza td el prces:

6 Figura 1.1: Fases del prces BI. FASE 1: Dirigir y Planear. En esta fase inicial es dnde se deberán reclectar ls requerimients de infrmación específics de l@s diferentes usuari@s, así cm entender sus diversas necesidades, para que lueg en cnjunt cn ell@s se generen las preguntas que les ayudarán a alcanzar sus bjetivs. FASE 2: Reclección de Infrmación. Es aquí en dnde se realiza el prces de extraer desde las diferentes fuentes de infrmación de la empresa, tant internas cm externas, ls dats que serán necesaris para encntrar las respuestas a las preguntas planteadas en el pas anterir. FASE 3: Prcesamient de Dats. En esta fase es dnde se integran y cargan ls dats en crud en un frmat utilizable para el análisis. Esta actividad puede realizarse mediante la creación de una nueva base de dats, agregand dats a una base de dats ya existente bien cnslidand la infrmación. FASE 4: Análisis y Prducción. Ahra, se prcederá a trabajar sbre ls dats extraíds e integrads, utilizand herramientas y técnicas prpias de la tecnlgía BI, para crear inteligencia. Cm resultad final de esta fase se btendrán las respuestas a las preguntas, mediante la creación de reprtes, indicadres de rendimient, cuadrs de mand, gráfics estadístics, etc. FASE 5: Difusión. Finalmente, se les entregará a l@s usuari@s que l requieran las herramientas necesarias, que les permitirán explrar ls dats de manera sencilla e intuitiva. 1.4 Beneficis Entre ls beneficis más imprtantes que BI prprcina a las rganizacines, vale la pena destacar ls siguientes: Reduce el tiemp mínim que se requiere para recger tda la infrmación relevante de un tema en particular, ya que la misma se encntrará integrada en una fuente única de fácil acces. Autmatiza la asimilación de la infrmación, debid a que la extracción y carga de ls dats necesaris se realizará a través de prcess predefinids.

7 Prprcina herramientas de análisis para establecer cmparacines y tmar decisines. Cierra el círcul que hace pasar de la decisión a la acción. Permite a l@s usuari@s n depender de reprtes infrmes prgramads, prque ls misms serán generads de manera dinámica. Psibilita la frmulación y respuesta de preguntas que sn claves para el desempeñ de la rganización. Permite acceder y analizar directamente ls indicadres de éxit. Se pueden identificar cuáles sn ls factres que inciden en el buen mal funcinamient de la rganización. Se pdrán detectar situacines fuera de l nrmal. Permitirá predecir el cmprtamient futur cn un alt prcentaje de certeza, basad en el entendimient del pasad. L@s usuari@s pdrán cnsultar y analizar ls dats de manera sencilla e intuitiva.

8 2. Data Warehusing & Data Warehuse 2.1 Intrducción Debid a que para llevar a cab BI, es necesari gestinar dats guardads en diverss frmats, fuentes y tips, para lueg depurarls e integrarls, además de almacenarls en un sl destin base de dats que permita su psterir análisis y explración, es imperativ y de vital imprtancia cntar cn un prces que satisfaga tdas estas necesidades. Este prces se denmina Data Warehusing. El Data Warehusing (DWH), es el encargad de extraer, transfrmar, cnslidar, integrar y centralizar ls dats que una rganización genera en tds ls ámbits de su actividad diaria (cmpras, ventas, prducción, etc) y/ infrmación externa relacinada. Permitiend de esta manera el acces y explración de la infrmación requerida, a través de una amplia gama de psibilidades de análisis multivariables, cn el bjetiv final de dar sprte al prces de tma de desicines estratégic y táctic. 2.2 Definición El Data Warehusing psibilita la extracción de dats de sistemas peracinales y fuentes externas, permite la integración y hmgeneización de ls dats de tda la empresa, prvee infrmación que ha sid transfrmada y sumarizada, para que ayude en el prces de tma de decisines estratégicas y tácticas. El Data Warehusing, cnvertirá entnces ls dats peracinales de la empresa en una herramienta cmpetitiva, debid a que pndrá a dispsición de l@s usuari@s indicad@s la infrmación pertinente, crrecta e integrada, en el mment que se necesita. Per para que el Data Warehusing pueda cumplir cn sus bjetivs, es necesari que la infrmación que se extrae, transfrma y cnslida, sea almacenada de manera centralizada en una base de dats cn estructura multidimensinal denminada Data Warehuse (DW). Una de las definicines más famsas sbre DW, es la de William Harvey Inmn, quien define: Un Data Warehuse es una clección de dats rientada al negci, integrada, variante en el tiemp y n vlátil para el sprte del prces de tma de decisines de la gerencia. Debid a que W. H. Inmn, es recncid mundialmente cm el padre del DW, la explicación de las características más sbresalientes de este cncept se basó en su definición.

9 Figura 2.1: Data Warehuse, características. Cabe aclarar que ls términs almacén de dats y depósit de dats, sn análgs a DW, y se utilizarán de aquí en adelante para referirse al mism. 2.3 Características 2.3 Características Orientada al negci Integrada Variante en el tiemp N vlátil 2.3. Características Orientada al negci La primera característica del DW, es que la infrmación se clasifica en base a ls aspects que sn de interés para la rganización. Esta clasificación afecta el diseñ y la implementación de ls dats encntrads en el almacén de dats, debid a que la estructura del mism difiere cnsiderablemente a la de ls clásics prcess peracinales rientads a las aplicacines. A cntinuación, y cn el fin de btener una mejr cmprensión de las diferencias existentes entre ests ds tips de rientación, se realizará un análisis cmparativ: Cn respect al nivel de detalle de ls dats, el DW excluye la infrmación que n será utilizada exclusivamente en el prces de tma de decisines; mientras que en ls prcess rientads a las aplicacines, se incluyen tds aquells dats que sn necesaris para satisfacer de manera inmediata ls requerimients funcinales de la actividad que sprten. Pr ejempl, ls dats cmunes referids a l@s client@s, cm su dirección de crre electrónic, fax, teléfn, D.N.I., códig pstal, etc, que sn tan imprtantes de almacenar en cualquier sistema peracinal, n sn tenids en cuenta en el depósit de dats pr carecer de valr para la tma de decisines, per sí l serán aquells que indiquen el tip de cliente, su clasificación, ubicación gegráfica, edad, etc.

10 En l que cncierne a la interacción de la infrmación, ls dats peracinales mantienen una relación cntinua entre ds más tablas, basadas en alguna regla cmercial vigente; en cambi las relacines encntradas en ls dats residentes del DW sn muchas, debid a que pr l general cada tabla del mism estará cnfrmada pr la integración de varias tablas u tras fuentes del ambiente peracinal, cada una cn sus prpias reglas de negci inherentes. El rigen de este cntraste es ttalmente lógic, ya que el ambiente peracinal se diseña alrededr de las aplicacines u prgramas que necesite la rganización para llevar a cab sus actividades diarias y funcines específicas. Pr ejempl, una aplicación de una empresa minrista manejará: stck, lista de precis, cuentas crrientes, pags diferids, impuests, retencines, ventas, ntas de crédit, cmpras, etc. De esta manera, la base de dats cmbinará ests elements en una estructura que se adapte a sus necesidades. En cntrapsición, siguiend cn el ejempl anterir, en una empresa minrista el ambiente DW se rganizará alrededr de entidades de alt nivel tales cm: clientes, prducts, rubrs, prveedres, vendedres, znas, etc. Que sn precisamente aquells sujets mediante ls cuales se desea analizar la infrmación. Est se debe a que el depósit de dats se diseña para realizar cnsultas e investigacines sbre las actividades de la rganización y n para sprtar ls prcess que se realizan en ella. En síntesis, la ventaja de cntar cn prcess rientads a la aplicación, está fundamentada en la alta accesibilidad de ls dats, l que implica un elevad desempeñ y velcidad en la ejecución de cnsultas, ya que las mismas están predeterminadas; mientras que en el DW para satisfacer esta ventaja se requiere que la infrmación este desnrmalizada, es decir, cn redundancia y que la misma esté dimensinada, para evitar tener que recrrer tda la base de dats cuand se necesite realizar algún análisis determinad, sin que simplemente la cnsulta sea enfcada pr variables de análisis que permitan lcalizar ls dats de manera rápida y eficaz, para pder de esta manera satisfacer una alta demanda de cmplejs exámenes en un mínim tiemp de respuesta Integrada La integración implica que tds ls dats de diversas fuentes que sn prducids pr distints departaments, seccines y aplicacines, tant interns cm externs, deben ser cnslidads en una instancia antes de ser agregads al DW, y deben pr l tant ser analizads para asegurar su calidad y limpieza, entre tras csas. A este prces se l cnce cm Integración de Dats, y cuenta cn diversas técnicas y subprcess para llevar a cab sus tareas. Una de estas técnicas sn ls prcess ETL: Extracción, Transfrmación y Carga de Dats (Extractin, Transfrmatin and Lad). Si bien el prces ETL es sl una de las muchas técnicas de la Integración de Dats, el rest de estas técnicas puede agruparse muy bien en sus diferentes etapas. Es decir, en el prces de Extracción tendrems un grup de técnicas enfcadas pr ejempl en tmar sl ls dats indicads y mantenerls en un almacenamient intermedi; en el prces de Transfrmación pr ejempl estarán aquellas técnicas que analizarán ls dats para verificar que sean crrects y válids; en el

11 prces de Carga de Dats se agruparán pr ejempl técnicas prpias de la carga y actualización del DW. La integración de dats, resuelve diferentes tips de prblemas relacinads cn las cnvencines de nmbres, unidades de medidas, cdificacines, fuentes múltiples, etc., cada un de ls cuales será crrectamente detallad y ejemplificad más adelante. La causa de dichs prblemas, se debe principalmente a que a través de ls añs l@s diseñadr@s y prgramadr@s n se han basad en ningún estándar cncret para definir nmbres de variables, tips de dats, etc., ya sea pr carecer de ells pr n creer que sean necesaris. Pr l cual, cada un pr su parte ha dejad en cada aplicación, módul, tabla, etc., su prpi estil persnalizad, cnfluyend de esta manera en la creación de mdels muy incnsistentes e incmpatibles entre sí. Ls punts de integración afectan casi tds ls aspects de diseñ, y cualquiera sea su frma, el resultad es el mism, ya que la infrmación será almacenada en el DW en un mdel glbalmente aceptable y singular, aún cuand ls sistemas peracinales y demás fuentes almacenen ls dats de maneras disímiles, para que de esta manera l@s usuari@s finales estén enfcad@s en la utilización de ls dats del depósit y n deban cuestinarse sbre la cnfiabilidad slidez de ls misms Variante en el tiemp Debid al gran vlumen de infrmación que se manejará en el DW, cuand se le realiza una cnsulta, ls resultads deseads demrarán en riginarse. Este espaci de tiemp que se prduce desde la búsqueda de dats hasta su cnsecución es del td nrmal en este ambiente y es, precisamente pr ell, que la infrmación que se encuentra dentr del depósit de dats se denmina de tiemp variable. Esta característica básica, es muy diferente de la infrmación encntrada en el ambiente peracinal, en el cual, ls dats se requieren en el mment de acceder, es decir, que se espera que ls valres prcurads se btengan a partir del mment mism de acces. Además, tda la infrmación en el DW psee su prpi sell de tiemp: Figura 2.2: Data Warehuse, variante en el tiemp.

12 Est cntribuye a una de las principales ventajas del almacén de dats: ls dats sn almacenads junt a sus respectivs histórics. Esta cualidad que n se encuentra en fuentes de dats peracinales, garantiza pder desarrllar análisis de la dinámica de la infrmación, pues ella es prcesada cm una serie de instantáneas, cada una representand un perid de tiemp. Es decir, que gracias al sell de tiemp se pdrá tener acces a diferentes versines de la misma infrmación. Es imprtante tener en cuenta la granularidad de ls dats, así cm también la intensidad de cambi natural del cmprtamient de ls fenómens de la actividad que se desarrlle, para evitar crecimients incntrlables y desbrdamients de la base de dats. El interval de tiemp y peridicidad de ls dats debe definirse de acuerd a la necesidad y requisits de l@s usuari@s. Es elemental aclarar, que el almacenamient de dats histórics, es l que permite al DW desarrllar prnóstics y análisis de tendencias y patrnes, a partir de una base estadística de infrmación N vlátil La infrmación es útil para el análisis y la tma de decisines sl cuand es estable. Ls dats peracinales varían mment a mment, en cambi, ls dats una vez que entran en el DW n cambian. La actualización, sea, insertar, eliminar y mdificar, se hace de frma muy habitual en el ambiente peracinal sbre una base, registr pr registr, en cambi en el depósit de dats la manipulación básica de ls dats es much más simple, debid a que sl existen ds tips de peracines: la carga de dats y el acces a ls misms. Pr esta razón es que en el DW n se requieren mecanisms de cntrl de cncurrencia y recuperación. Figura 2.3: Data Warehuse, n vlátil.

13 2.4 Cualidades Una de las primeras cualidades que se puede mencinar del DW, es que maneja un gran vlumen de dats, debid a que cnslida en su estructura la infrmación reclectada durante añs, prveniente de diversas fuentes y áreas, en un sl lugar centralizad. Es pr esta razón que el depósit puede ser sprtad y mantenid sbre diverss medis de almacenamient. Además, cm ya se ha mencinad, el almacén de dats presenta la infrmación sumarizada y agregada desde múltiples versines, y maneja infrmación histórica. Organiza y almacena ls dats que se necesitan para realizar cnsultas y prcess analítics, cn el prpósit de respnder a preguntas cmplejas y brindarles a l@s usuari@s finales la psibilidad de que mediante una interface amigable, intuitiva y fácil de utilizar, puedan tmar decisines sbre ls dats sin tener que pseer demasiads cncimients infrmátics. El DW permite un acces más direct, es decir, la infrmación gira en trn al negci, y es pr ell que también l@s usuari@s pueden sentirse cómd@s al explrar ls dats y encntrar relacines cmplejas entre ls misms. Cabe aclarar que el Data Warehusing n se cmpne sl de dats, ni tampc sl se trata de un depósit de dats aislad. El Data Warehusing hace referencia a un cnjunt de herramientas para cnsultar, analizar y presentar infrmación, que permiten btener realizar análisis, reprting, extracción y expltación de ls dats, cn alta perfrmance, para transfrmar dichs dats en infrmación valisa para la rganización. Cn respect a las tecnlgías que sn empleadas, se pueden encntrar las siguientes: Arquitectura cliente/servidr. Técnicas avanzadas para replicar, refrescar y actualizar dats. Sftware frnt-end, para acces y análisis de dats. Herramientas para extraer, transfrmar y cargar dats en el depósit, desde múltiples fuentes muy hetergéneas. Sistema de Gestión de Base de Dats (SGBD). Tdas las cualidades expuestas anterirmente, sn impsibles de saldar en un típic ambiente peracinal, y est es una de las raznes de ser del Data Warehusing. 2.5 Ventajas A cntinuación se enumerarán algunas de las ventajas más sbresalientes que trae aparejada la implementación de un Data Warehusing y que ejemplifican de mejr md sus características y cualidades: Transfrma dats rientads a las aplicacines en infrmación rientada a la tma de decisines.

14 Integra y cnslida diferentes fuentes de dats (internas y/ externas) y departaments empresariales, que anterirmente frmaban islas, en una única platafrma sólida y centralizada. Prvee la capacidad de analizar y expltar las diferentes áreas de trabaj y de realizar un análisis inmediat de las mismas. Permite reaccinar rápidamente a ls cambis del mercad. Aumenta la cmpetitividad en el mercad. Elimina la prducción y el prcesamient de dats que n sn utilizads ni necesaris, prduct de aplicacines mal diseñadas ya n utilizadas. Mejra la entrega de infrmación, es decir, infrmación cmpleta, crrecta, cnsistente, prtuna y accesible. Infrmación que l@s usuari@s necesitan, en el mment adecuad y en el frmat aprpiad. Lgra un impact psitiv sbre ls prcess de tma de decisines. Cuand l@s usuari@s tienen acces a una mejr calidad de infrmación, la empresa puede lgrar pr sí misma: aprvechar el enrme valr ptencial de sus recurss de infrmación y transfrmarl en valr verdader; eliminar ls retards de ls prcess que resultan de infrmación incrrecta, incnsistente y/ inexistente; integrar y ptimizar prcess a través del us cmpartid e integrad de las fuentes de infrmación; permitir a l@s usuari@s adquirir mayr cnfianza acerca de sus prpias decisines y de las del rest, y lgrar así, un mayr entendimient de ls impacts casinads. Aument de la eficiencia de l@s encargad@s de tmar decisines. L@s usuari@s pueden acceder directamente a la infrmación en línea, l que cntribuye a su capacidad para perar cn mayr efectividad en las tareas rutinarias n. Además, pueden tener a su dispsición una gran cantidad de valisa infrmación multidimensinal, presentada cherentemente cm fuente única, cnfiable y dispnible en sus estacines de trabaj. Así mism, l@s usuari@s tienen la facilidad de cntar cn herramientas que les sn familiares para manipular y evaluar la infrmación btenida en el DW, tales cm: hjas de cálcul, prcesadres de text, sftware de análisis de dats, sftware de análisis estadístic, reprtes, tablers, etc. Permite la tma de decisines estratégicas y tácticas. 2.6 Desventajas A cntinuación se enumerarán algunas de las desventajas más cmunes que se pueden presentar en la implementación de un Data Warehusing: Requiere una gran inversión, debid a que su crrecta cnstrucción n es tarea sencilla y cnsume muchs recurss, además, su misma implementación implica desde la adquisición de herramientas de cnsulta y análisis, hasta la capacitación de l@s usuari@s.

15 Existe resistencia al cambi pr parte de Ls beneficis del almacén de dats sn apreciads en el median y larg plaz. Este punt deriva del anterir, y básicamente se refiere a que n td@s l@s usuari@s cnfiarán en el DW en una primera instancia, per sí l harán una vez que cmprueben su efectividad y ventajas. Además, su crrecta utilización surge de la prpia experiencia. Si se incluyen dats prpis y cnfidenciales de clientes, prveedres, etc, el depósit de dats atentará cntra la privacidad de ls misms, ya que cualquier usuari@ pdrá tener acces a ells. Infravalración de ls recurss necesaris para la captura, carga y almacenamient de ls dats. Infravalración del esfuerz necesari para su diseñ y creación. Increment cntinu de ls requerimients de l@s usuari@s. Subestimación de las capacidades que puede brindar la crrecta utilización del DWH y de las herramientas de BI en general. 2.7 Redundancia Debid a que el DW recibe infrmación histórica de diferentes fuentes, sencillamente se pdría supner que existe una repetición de dats masiva entre el ambiente DW y el peracinal. Pr supuest, este raznamient es superficial y erróne, de hech, hay una mínima redundancia de dats entre ambs ambientes. Para entender claramente l antes expuest, se debe cnsiderar l siguiente: Ls dats del ambiente peracinal se filtran antes de pertenecer al DW. Existen muchs dats que nunca ingresarán, ya que n cnfrman infrmación necesaria suficientemente relevante para la tma de decisines. El hriznte de tiemp es muy diferente entre ls ds ambientes. El almacén de dats cntiene un resumen de la infrmación que n se encuentra en el ambiente peracinal. Ls dats experimentan una cnsiderable transfrmación, antes de ser cargads al DW. La mayr parte de ls dats se alteran significativamente al ser seleccinads, cnslidads y mvids al depósit. En vista de ests factres, se puede afirmar que, la redundancia encntrada al ctejar ls dats de ambs ambientes es mínima, ya que generalmente resulta en un prcentaje menr del 1%. 2.8 Estructura Ls DW estructuran ls dats de manera muy particular y existen diferentes niveles de esquematización y detalle que ls delimitan. En la siguiente figura se puede apreciar mejr su respectiva estructura:

16 Figura 2.4: Data Warehuse, estructura. Cm se puede bservar, ls almacenes de dats están cmpuests pr diverss tips de dats, que se rganizan y dividen de acuerd al nivel de detalle granularidad que psean. A cntinuación se explicarán cada un de ests tips de dats: Detalle de dats actuales: sn aquells que reflejan las currencias más recientes. Generalmente se almacenan en disc, aunque su administración sea cstsa y cmpleja, cn el fin de cnseguir que el acces a la infrmación sea sencill y velz, ya que sn bastante vluminss. Su gran tamañ se debe a que ls dats residentes pseen el más baj nivel de granularidad, sea, se almacenan a nivel de detalle. Pr ejempl, aquí es dnde se guardaría el detalle de una venta realizada en tal fecha. Detalle de dats histórics: representan aquells dats antigus, que n sn frecuentemente cnsultads. También se almacenan a nivel de detalle, nrmalmente sbre alguna frma de almacenamient externa, ya que sn muy pesads y en adición a est, n sn requerids cn mucha peridicidad. Este tip de dats sn cnsistentes cn ls de Detalle de dats actuales. Pr ejempl, en este nivel, al igual que en el anterir, se encntraría el detalle de una venta realizada en tal fecha, per cn la particularidad de que el día en que se registró la venta debe ser l suficientemente antigua, para que se cnsidere cm histórica. Dats ligeramente resumids: sn ls que prvienen desde un baj nivel de detalle y sumarizan agrupan ls dats baj algún criteri cndición de análisis. Habitualmente sn almacenads en disc. Pr ejempl, en este cas se almacenaría la sumarización del detalle de las ventas realizadas en cada mes.

17 Dats altamente resumids: sn aquells que cmpactan aún más a ls dats ligeramente resumids. Se guardan en disc y sn muy fáciles de acceder. Pr ejempl, aquí se encntraría la sumarización de las ventas realizadas en cada añ. Metadats: representan la infrmación acerca de ls dats. De muchas maneras se sitúa en una dimensión diferente al de trs dats del DW, ya que su cntenid n es tmad directamente desde el ambiente peracinal. Ests diferentes niveles de detalle granularidad, se btienen a través de tablas de hechs agregadas y/ preagregadas. 2.9 Fluj de Dats El DW psee un fluj de dats estándar y generalizad, el cual puede apreciarse mejr en la siguiente figura. Figura 2.5: Data Warehuse, fluj de dats. Cuand la infrmación ingresa al depósit de dats se almacena a nivel de Detalle de dats actuales. Ls dats permanecerán allí hasta que curra algun de ls tres events siguientes: Sean brrads del depósit de dats. Sean resumids, ya sea a nivel de Dats ligeramente resumids a nivel de Dats altamente resumids. Sean archivads a nivel de Detalle de dats histórics.

18 3. Arquitectura del Data Warehusing 3.1 Intrducción En este punt y teniend en cuenta que ya se han detallad claramente las características generales del Data Warehusing, se definirán y describirán tds ls cmpnentes que intervienen en su arquitectura ambiente. A través del siguiente gráfic se explicitará la estructura del Data Warehusing: Figura 3.1: Data Warehusing, arquitectura. Tal y cm se puede apreciar, el ambiente está frmad pr diverss elements que interactúan entre sí y que cumplen una función específica dentr del sistema. Pr ell es que al abrdar la expsición de cada element se l hará en frma rdenada y teniend en cuenta su relación cn las demás partes. Básicamente, la frma de perar del esquema superir se resume de la siguiente manera: Ls dats sn extraíds desde aplicacines, bases de dats, archivs, etc. Esta infrmación generalmente reside en diferentes tips de sistemas, rígenes y arquitecturas y tienen frmats muy variads. Ls dats sn integrads, transfrmads y limpiads, para lueg ser cargads en el DW. Principalmente, la infrmación del DW se estructura en cubs multidimensinales, ya que ests preparan esta infrmación para respnder a cnsultas dinámicas cn una buena perfrmance. Per también pueden utilizarse trs tips de estructuras de dats para representar la infrmación del DW, cm pr ejempl Business Mdels. L@s usuari@s acceden a ls cubs multidimensinales, Business Mdels (u tr tip de estructura de dats) del DW utilizand diversas herramientas de cnsulta, explración, análisis, reprtes, etc.

19 A cntinuación se detallará cada un de ls cmpnentes de la arquitectura del Data Warehusing, teniend cm referencia siempre el gráfic antes expuest, per resaltand el tema que se tratará. 3.2 OLTP Figura 3.2: OLTP OLTP (On Line Transactin Prcessing), representa tda aquella infrmación transaccinal que genera la empresa en su accinar diari, además, de las fuentes externas cn las que puede llegar a dispner. Cm ya se ha mencinad, estas fuentes de infrmación, sn de características muy disímiles entre sí, en frmat, prcedencia, función, etc. Entre ls OLTP más habituales que pueden existir en cualquier rganización se encuentran: Archivs de texts. Hipertexts. Hjas de cálculs. Infrmes semanales, mensuales, anuales, etc. Bases de dats transaccinales. 3.3 Lad manager 3.3 Lad Manager Extracción Transfrmación Cdificación Medida de atributs Cnvencines de nmbramient Fuentes múltiples Limpieza de dats Carga

20 3.3.4 Prces ETL 3.3. Lad Manager Figura 3.3: Lad Manager. Para pder extraer ls dats desde ls OLTP, para lueg manipularls, integrarls y transfrmarls, para psterirmente cargar ls resultads btenids en el DW, es necesari cntar cn algún sistema que se encargue de ell. Precisamente, la Integración de Dats en quien cumplirá cn tal fin. La Integración de Dats agrupa una serie de técnicas y subprcess que se encargan de llevar a cab tdas las tareas relacinadas cn la extracción, manipulación, cntrl, integración, depuración de dats, carga y actualización del DW, etc. Es decir, tdas las tareas que se realizarán desde que se tman ls dats de ls diferentes OLTP hasta que se cargan en el DW. Cm se mencinó anterirmente cuand se tratarn las características del DW, si bien ls prcess ETL (Extracción, Transfrmación y Carga) sn sl una de las muchas técnicas de la Integración de Dats, el rest de estas técnicas puede agruparse muy bien en sus diferentes etapas. Es decir, en el prces de Extracción tendrems un grup de técnicas enfcadas pr ejempl en tmar sl ls dats indicads y mantenerls en un almacenamient intermedi; en el prces de Transfrmación pr ejempl estarán aquellas técnicas que analizarán ls dats para verificar que sean crrects y válids; en el prces de Carga de Dats se agruparán pr ejempl técnicas prpias de la carga y actualización del DW. A cntinuación, se detallará cada una de estas etapas, se expndrá cuál es el prces que llevan a cab ls ETL y se enumerarán cuáles sn sus principales tareas Extracción Es aquí, en dnde, basándse en las necesidades y requisits de l@s usuari@s, se explran las diversas fuentes OLTP que se tengan a dispsición, y se extrae la infrmación que se cnsidere relevante al cas.

21 Si ls dats peracinales residen en un SGBD Relacinal, el prces de extracción se puede reducir a, pr ejempl, cnsultas en SQL rutinas prgramadas. En cambi, si se encuentran en un sistema n cnvencinal fuentes externas, ya sean textuales, hipertextuales, hjas de cálculs, etc, la btención de ls misms puede ser un tant más dificults, debid a que, pr ejempl, se tendrán que realizar cambis de frmat y/ vlcad de infrmación a partir de alguna herramienta específica. Una vez que ls dats sn seleccinads y extraíds, se guardan en un almacenamient intermedi, l cual permite, entre tras ventajas: Manipular ls dats sin interrumpir ni paralizar ls OLTP, ni tampc el DW. N depender de la dispnibilidad de ls OLTP. Almacenar y gestinar ls metadats que se generarán en ls prcess ETL. Facilitar la integración de las diversas fuentes, internas y externas. El almacenamient intermedi cnstituye en la mayría de ls cass una base de dats en dnde la infrmación puede ser almacenada pr ejempl en tablas auxiliares, tablas temprales, etc. Ls dats de estas tablas serán ls que finalmente (lueg de su crrespndiente transfrmación) pblarán el DW Transfrmación Esta función es la encargada de cnvertir aquells dats incnsistentes en un cnjunt de dats cmpatibles y cngruentes, para que puedan ser cargads en el DW. Estas accines se llevan a cab, debid a que pueden existir diferentes fuentes de infrmación, y es vital cnciliar un frmat y frma única, definiend estándares, para que tds ls dats que ingresarán al DW estén integrads. Ls cass más cmunes en ls que se deberá realizar integración, sn ls siguientes: Cdificación. Medida de atributs. Cnvencines de nmbramient. Fuentes múltiples. Además de l antes mencinad, esta función se encarga de realizar, entre trs, ls prcess de Limpieza de Dats (Data Cleansing) y Calidad de Dats Cdificación Una incnsistencia muy típica que se encuentra al intentar integrar varias fuentes de dats, es la de cntar cn más de una frma de cdificar un atribut en cmún. Pr ejempl, en el camp estad, algun@s diseñadr@s cmpletan su valr cn 0 y 1, trs cn Apagad y Encendid, trs

22 cn ff y n, etc. L que se debe realizar en ests cass, es seleccinar recdificar ests atributs, para que cuand la infrmación llegue al DW, esté integrada de manera unifrme. En la siguiente figura, se puede apreciar que de varias frmas de cdificar se escge una, entnces cuand surge una cdificación diferente a la seleccinada, se prcede a su transfrmación. Figura 3.4: Transfrmación: cdificación Medida de atributs Ls tips de unidades de medidas utilizads para representar ls atributs de una entidad, varían cnsiderablemente entre sí, a través de ls diferentes OLTP. Pr ejempl, al registrar la lngitud de un prduct determinad, de acuerd a la aplicación que se emplee para tal fin, las unidades de medidas pueden ser explicitadas en centímetrs, metrs, pulgadas, etc. En esta casión, se deberán estandarizar las unidades de medidas de ls atributs, para que tdas las fuentes de dats expresen sus valres de igual manera. Ls algritms que resuelven estas incnsistencias sn generalmente ls más cmplejs. Figura 3.5: Transfrmación: medida de atributs.

23 Cnvencines de nmbramient Usualmente, un mism atribut es nmbrad de diversas maneras en ls diferentes OLTP. Pr ejempl, al referirse al nmbre del prveedr, puede hacerse cm nmbre, razón_scial, prveedr, etc. Aquí, se debe utilizar la cnvención de nmbramient que para sea más cmprensible. Figura 3.6: Transfrmación: cnvencines de nmbramient Fuentes múltiples Un mism element puede derivarse desde varias fuentes. En este cas, se debe elegir aquella fuente que se cnsidere más fiable y aprpiada. Figura 3.7: Transfrmación: fuentes múltiples.

24 Limpieza de dats Su bjetiv principal es el de realizar distints tips de accines cntra el mayr númer de dats errónes, incnsistentes e irrelevantes. Las accines más típicas que se pueden llevar a cab al encntrarse cn Dats Anómals (Outliers) sn: Ignrarls. Eliminar la clumna. Filtrar la clumna. Filtrar la fila errónea, ya que a veces su rigen, se debe a cass especiales. Reemplazar el valr. Discretizar ls valres de las clumnas. Pr ejempl de 1 a 2, pner baj ; de 3 a 7, óptim ; de 8 a 10, alt. Para que ls utliers caigan en baj en alt sin mayres prblemas. Las accines que suelen efectuarse cntra Dats Faltantes (Missing Values) sn: Ignrarls. Eliminar la clumna. Filtrar la clumna. Filtrar la fila errónea, ya que a veces su rigen, se debe a cass especiales. Reemplazar el valr. Esperar hasta que ls dats faltantes estén dispnibles. Un punt muy imprtante que se debe tener en cuenta al elegir alguna acción, es el de identificar el prqué de la anmalía, para lueg actuar en cnsecuencia, cn el fin de evitar que se repitan, agregándle de esta manera más valr a ls dats de la rganización. Se puede dar que en alguns cass, ls valres faltantes sean inexistentes, ya que pr ejempl, l@s nuev@s asciad@s client@s, n pseerán cnsum medi del últim añ Carga 1) Esta función se encarga, pr un lad de realizar las tareas relacinadas cn: Carga Inicial (Initial Lad). Actualización mantenimient periódic (siempre teniend en cuenta un interval de tiemp predefinid para tal peración). La carga inicial, se refiere precisamente a la primera carga de dats que se le realizará al DW. Pr l general, esta tarea cnsume un tiemp bastante cnsiderable, ya que se deben insertar registrs que han sid generads aprximadamente, y en cass ideales, durante más de cinc añs.

25 Ls mantenimients periódics mueven pequeñs vlúmenes de dats, y su frecuencia está dada en función del gránul del DW y ls requerimients de l@s usuari@s. El bjetiv de esta tarea es añadir al depósit aquells dats nuevs que se fuern generand desde el últim refresc. Antes de realizar una nueva actualización, es necesari identificar si se han prducid cambis en las fuentes riginales de ls dats recgids, desde la fecha del últim mantenimient, a fin de n atentar cntra la cnsistencia del DW. Para efectuar esta peración, se pueden realizar las siguientes accines: Ctejar las instancias de ls OLTP invlucrads. Utilizar disparadres en ls OLTP. Recurrir a Marcas de Tiemp (Time Stamp), en ls registrs de ls OLTP. Cmparar ls dats existentes en ls ds ambientes (OLTP y DW). Hacer us de técnicas mixtas. Si este cntrl cnsume demasiad tiemp y esfuerz, simplemente n puede llevarse a cab pr algún mtiv en particular, existe la psibilidad de cargar el DW desde cer, este prces se denmina Carga Ttal (Full Lad). Ingresarán al DW, para su carga y/ actualización: Aquells dats que han sid transfrmads y que residen en el almacenamient intermedi. Aquells dats de ls OLTP que tienen crrespndencia directa cn el depósit de dats. Se debe tener en cuenta, que ls dats antes de mverse al almacén de dats, deben ser analizads cn el prpósit de asegurar su calidad, ya que este es un factr clave, que n debe dejarse de lad. 2) Pr tra parte, el prces de Carga tiene la tarea de mantener la estructura del DW, y trata temas relacinads cn: Relacines muchs a muchs. Claves Subrgadas. Dimensines Lentamente Cambiantes. Dimensines Degeneradas Prces ETL A cntinuación, se explicará en síntesis el accinar del prces ETL, y cuál es la relación existente entre sus diversas funcines. En la siguiente figura se puede apreciar mejr l antes descrit:

26 Figura 3.8: Prces ETL. Ls pass que se siguen sn: Se extraen ls dats relevantes desde ls OLTP y se depsitan en un almacenamient intermedi. Se integran y transfrman ls dats, para evitar incnsistencias. Se cargan ls dats desde el almacenamient intermedi hasta el DW. 3.4 Datawarehuse manager 3.4 Data Warehuse Manager Base de dats multidimensinal Tablas de Dimensines Tabla de Dimensión Tiemp Tablas de Hechs Tablas de hechs agregadas y preagregadas Cub Multidimensinal: intrducción Indicadres Atributs Jerarquías a) Relación b) Granularidad Tips de mdelamient de un DW Esquema en Estrella Esquema Cp de Nieve Esquema Cnstelación OLTP vs DW Tips de implementación de un DW ROLAP MOLAP HOLAP ROLAP vs MOLAP

27 3.4.8 Cub Multidimensinal: prfundización Metadats Mapping 3.4. Data Warehuse Manager Figura 3.9: Data Warehuse Manager. El DW Manager presenta las siguientes características y funcines principales: Se cnstituye típicamente al cmbinar un SGBD cn sftware y aplicacines dedicadas. Almacena ls dats de frma multidimensinal, es decir, a través de tablas de hechs y tablas de dimensines. Gestina las diferentes estructuras de dats que se cnstruyan describan sbre el DW, cm Cubs Multidimensinales, Business Mdels, etc. Gestina y mantiene metadats. Además, el DW Manager se encarga de: Transfrmar e integrar ls dats fuentes y del almacenamient intermedi en un mdel adecuad para la tma de decisines. Realizar tdas las funcines de definición y manipulación del depósit de dats, para pder sprtar tds ls prcess de gestión del mism. Ejecutar y definir las plíticas de particinamient. El bjetiv de realizar est, es cnseguir una mayr eficiencia y perfrmance en las cnsultas al n tener que manejar td el grues de ls dats. Esta plítica debe aplicarse sbre la tabla de hechs que, cm se explicará más adelante, es en la que se almacena tda la infrmación que será analizada. Realizar cpias de resguard incrementales ttales de ls dats del DW.

28 Base de dats multidimensinal Una base de dats multidimensinal es una base de dats en dnde su infrmación se almacena en frma multidimensinal, es decir, a través de tablas de hechs y tablas de dimensines. Prveen una estructura que permite, a través de la creación y cnsulta a una estructura de dats determinada (cub multidimensinal, Business Mdel, etc), tener acces flexible a ls dats, para explrar y analizar sus relacines, y cnsiguientes resultads. Las bases de dats multidimensinales implican tres variantes psibles de mdelamient, que permiten realizar cnsultas de sprte de decisión: Esquema en Estrella (Star Scheme). Esquema Cp de Nieve (Snwflake Scheme). Esquema Cnstelación cp de estrellas (Starflake Scheme). Ls mencinads esquemas pueden ser implementads de diversas maneras, que, independientemente al tip de arquitectura, requieren que tda la estructura de dats este desnrmalizada semi desnrmalizada, para evitar desarrllar unines (Jin) cmplejas para acceder a la infrmación, cn el fin de agilizar la ejecución de cnsultas. Ls diferentes tips de implementación sn ls siguientes: Relacinal ROLAP. Multidimensinal MOLAP. Híbrid HOLAP Tablas de Dimensines Las tablas de dimensines definen cm están ls dats rganizads lógicamente y prveen el medi para analizar el cntext del negci. Cntienen dats cualitativs. Representan ls aspects de interés, mediante ls cuales l@s usuari@s pdrán filtrar y manipular la infrmación almacenada en la tabla de hechs. En la siguiente figura se pueden apreciar alguns ejempls: Figura 3.10: Tablas de Dimensines.

29 Cm se puede bservar, cada tabla psee un identificadr únic y al mens un camp dat de referencia que describe ls criteris de análisis relevantes para la rganización, ests sn pr l general de tip text. Ls dats dentr de estas tablas, que prveen infrmación del negci que describen alguna de sus características, sn llamads dats de referencia. Más detalladamente, cada tabla de dimensión pdrá cntener ls siguientes camps: Clave principal identificadr únic. Clave fráneas. Dats de referencia primaris: dats que identifican la dimensión. Pr ejempl: nmbre del cliente. Dats de referencia secundaris: dats que cmplementan la descripción de la dimensión. Pr ejempl: del cliente, fax del cliente, etc. Usualmente la cantidad de tablas de dimensines, aplicadas a un tema de interés en particular, varían entre tres y quince. Debe tenerse en cuenta, que n siempre la clave primaria del OLTP, se crrespnde cn la clave primaria de la tabla de dimensión relacinada. Es recmendable manejar un sistema de claves en el DW (Claves Subrgadas) ttalmente diferente al de ls OLTP, ya que si ests últims sn recdificads, el almacén quedaría incnsistente y debería ser pblad nuevamente en su ttalidad Tabla de Dimensión Tiemp En un DW, la creación y el mantenimient de una tabla de dimensión Tiemp es bligatria, y la definición de granularidad y estructuración de la misma depende de la dinámica del negci que se este analizand. Tda la infrmación dentr del depósit, cm ya se ha explicad, psee su prpi sell de tiemp que determina la currencia de un hech específic, representand de esta manera diferentes versines de una misma situación. Es imprtante tener en cuenta que la dimensión tiemp n es sla una secuencia crnlógica representada de frma numérica, sin que mantiene niveles jerárquics especiales que inciden ntablemente en las actividades de la rganización. Est se debe a que l@s usuari@s pdrán pr ejempl analizar las ventas realizadas teniend en cuenta el día de la semana en que se prdujern, quincena, mes, trimestre, semestre, añ, estación, etc. Existen muchas maneras de diseñar esta tabla, y en adición a ell n es una tarea sencilla de llevar a cab. Pr estas raznes se cnsidera una buena práctica evaluar cn cuidad la tempralidad de ls dats, la frma en que trabaja la rganización, ls resultads que se esperan btener del almacén de dats relacinads cn una unidad de tiemp y la flexibilidad que se desea btener de dicha tabla.

30 Así mism, si se requiere analizar ls dats pr Fecha (añ, mes, día, etc) y pr Hra (hra, minut, segund, etc), l más recmendable es cnfeccinar ds tablas de dimensión Tiemp; una cntendrá ls dats referids a la Fecha y la tra ls referids a la Hra. Si bien, el lenguaje SQL frece funcines del tip DATE, en la tabla de dimensión Tiemp, se mdelan y presentan dats temprales que n pueden calcularse a través de cnsultas SQL, l cual le añade una ventaja más. Es cnveniente mantener en la tabla de dimensión Tiemp un camp que se refiera al día Julian. El día julian se representa a través de un númer secuencial e identifica unívcamente cada día. Mantener este camp permitirá la psibilidad de realizar cnsultas que invlucren cndicines de filtrad de fechas desde-hasta, mayr que, menr que, etc, de manera sencilla e intuitiva; ya que si pr ejempl a partir de tal fecha se desea analizar ls dats de ls 81 días siguientes, el valr "desde" sería el día Julian de la fecha en cuestión y el valr "hasta" sería igual a "desde" más Tablas de Hechs Las tablas de hechs cntienen, precisamente, ls hechs que serán utilizads pr l@s analistas de negci para apyar el prces de tma de decisines. Cntienen dats cuantitativs. Ls hechs sn dats instantánes en el tiemp, que sn filtrads, agrupads y explrads a través de cndicines definidas en las tablas de dimensines. Ls dats presentes en las tablas de hechs cnstituyen el vlumen de la bdega, y pueden estar cmpuests pr millnes de registrs dependiend de su granularidad y antigüedad de la rganización. Ls más imprtantes sn ls de tip numéric. El registr del hech psee una clave primaria que está cmpuesta pr las claves primarias de las tablas de dimensines relacinadas a este. En la siguiente imagen se puede apreciar un ejempl de l antes mencinad: Figura 3.11: Tablas de Hechs. Cm se muestra en la figura anterir, la tabla de hechs VENTAS se ubica en el centr, e irradiand de ella se encuentran las tablas de dimensines CLIENTES, PRODUCTOS y FECHAS,

31 que están cnectadas mediante sus claves primarias. Es pr ell que la clave primaria de la tabla de hechs es la cmbinación de las claves primarias de sus dimensines. Ls hechs en este cas sn ImprteTtal y Utilidad. A cntinuación, se entrará más en detalle sbre la definición de un hech, también llamad dat agregad: Ls hechs sn aquells dats que residen en una tabla de hechs y que sn utilizads para crear indicadres, a través de sumarizacines preestablecidas al mment de crear un cub multidimensinal, Business Mdel, etc. Debid a que una tabla de hechs se encuentra interrelacinada cn sus respectivas tablas de dimensines, permite que ls hechs puedan ser accedids, filtrads y explrads pr ls valres de ls camps de estas tablas de dimensines, bteniend de este md una gran capacidad analítica. Las sumarizacines n están referidas sl a sumas, sin también a prmedis, mínims, máxims, ttales pr sectr, prcentajes, fórmulas predefinidas, etc, dependiend de ls requerimients de infrmación del negci. Para ejemplificar este nuev cncept de hechs, se enumerarán alguns que sn muy típics y fáciles de cmprender: ImprteTtal = preciprduct * cantidadvendida Rentabilidad = utilidad / PN CantidadVentas = cantidad PrmediGeneral = AVG(ntasFinales) A la izquierda de la igualdad se encuentran ls hechs; a la derecha ls camps de ls OLTP que sn utilizads para representarls. En el últim ejempl se realiza un precálcul para establecer el hech. Existen ds tips de hechs, ls básics y ls derivads, a cntinuación se detallará cada un de ells, teniend en cuenta para su ejemplificación la siguiente tabla de hechs: Figura 3.12: Hechs básics y derivads. Hechs básics: sn ls que se encuentran representads pr un camp de una tabla de hechs. Ls camps preci y cantidad de la tabla anterir sn hechs básics. Hechs derivads: sn ls que se frman al cmbinar un más hechs cn alguna peración matemática lógica y que también residen en una tabla de hechs. Ests pseen

32 la ventaja de almacenarse previamente calculads, pr l cual pueden ser accedids a través de cnsultas SQL sencillas y devlver resultads rápidamente, per requieren más espaci físic en el DW, además de necesitar más tiemp de prces en ls ETL que ls calculan. El camp ttal de la tabla anterir en un hech derivad, ya que se cnfrma de la siguiente manera: ttal = preci * cantidad Ls camps preci y cantidad, también pertenecen a la tabla HECHOS. Cabe resaltar, que n es necesari que ls hechs derivads se cmpngan únicamente cn hechs pertenecientes a una misma tabla. Ls hechs sn gestinads cn el principal bjetiv de que se cnstruyan indicadres basads en ells, a través de la creación de un cub multidimensinal, Business Mdel, u tra estructura de dats Tablas de hechs agregadas y preagregadas Las tablas de hechs agregadas y preagregadas se utilizan para almacenar un resumen de ls dats, es decir, se guardan ls dats en niveles de granularidad superir a ls que inicialmente fuern btenids y/ gestinads. Para btener tablas agregadas preagregadas, es necesari establecer un criteri pr el cual realizar el resumen. Pr ejempl, est curre cuand se desea btener infrmación de ventas sumarizadas pr mes. Cada vez que se requiere que ls dats en una cnsulta se presenten en un nivel de granularidad superir al que se encuentran aljads en el Data Warehuse, se debe llevar a cab un prces de agregación. El bjetiv general de las tablas de hechs agregadas y preagregadas es similar, per cada una de ellas tiene una manera de perar diferente: Tablas de hechs agregadas: se generan lueg de que se prcesa la cnsulta crrespndiente a la tabla de hechs que se resumirá. En general, la agregación se prduce dinámicamente a través de una instrucción SQL que incluya sumarizacines. Tablas de hechs preagregadas: se generan antes de que se prcese la cnsulta crrespndiente a la tabla de hechs que se resumirá. De esta manera, la cnsulta se realiza cntra una tabla que ya fue previamente sumarizada. Habitualmente, estas sumarizacines se calculan a través de prcess ETL. Las tablas de hechs preagregadas cuentan cn ls siguientes beneficis: Reduce la utilización de recurss de hardware que nrmalmente sn incurrids en el cálcul de las sumarizacines. Reduce el númer de registrs que serán analizads pr l@s usuari@s.

33 Reduce el tiemp utilizad en la generación de cnsultas pr parte de Las tablas de hechs preagregadas sn muy útiles en ls siguientes cass generales: Cuand ls dats a nivel detalle (menr nivel granular) sn innecesaris y/ n sn requerids. Cuand una cnsulta sumarizada a determinad nivel de granularidad es slicitad cn mucha frecuencia. Cuand ls dats sn muy abundantes, y las cnsultas demran en ser prcesadas demasiad tiemp. Cm cntrapartida, las tablas de hechs preagregadas presentan una serie de desventajas: Requieren que se mantengan y gestinen nuevs prcess ETL. Demandan espaci de almacenamient extra en el depósit de dats Cub Multidimensinal: intrducción Si bien existen diversas estructuras de dats, a través de las cuales se puede representar ls dats del DW, slamente se entrará en detalle acerca de ls cubs multidimensinales, pr cnsiderarse que esta estructura de dats es una de las más utilizadas y cuy funcinamient es el más cmplej de entender. Un cub multidimensinal hipercub, representa cnvierte ls dats plans que se encuentran en filas y clumnas, en una matriz de N dimensines. Ls bjets más imprtantes que se pueden incluir en un cub multidimensinal, sn ls siguientes: Indicadres: sumarizacines que se efectúan sbre algún hech expresines basadas en sumarizacines, pertenecientes a una tabla de hechs. Atributs: camps criteris de análisis, pertenecientes a tablas de dimensines. Jerarquías: representa una relación lógica entre ds más atributs. De esta manera en un cub multidimensinal, ls atributs existen a l larg de varis ejes dimensines, y la intersección de las mismas representa el valr que tmará el indicadr que se está evaluand. En la siguiente representación matricial se puede ver más claramente l que se acaba de decir:

34 Figura 3.13: Cub multidimensinal. Para la creación del cub de la figura anterir, se definiern tres Atributs ( Atribut 1, Atribut 2 y Atribut 3 ) y se definió un Indicadr ( Indicadr 1 ). Entnces el cub qued cmpuest pr 3 dimensines ejes (una pr cada Atribut), cada una cn sus respectivs valres asciads. También, se ha seleccinad una intersección al azar para demstrar la crrespndencia cn ls valres de las Atributs. En este cas, el indicadr Indicadr 1, representa el cruce del Valr 5 de Atribut 1, cn el Valr 4 de Atribut 2 y cn el Valr 3 de Atribut 3. Se puede bservar, que el resultad del análisis está dad pr ls cruces matriciales de acuerd a ls valres de las dimensines seleccinadas. Más específicamente, para acceder a ls dats del DW, se pueden ejecutar cnsultas sbre algún cub multidimensinal previamente definid. Dich cub debe incluir entre trs bjets: indicadres, atributs, jerarquías, etc, basads en ls camps de las tablas de dimensines y de hechs, que se deseen analizar. De esta manera, las cnsultas sn respndidas cn gran perfrmance, minimizand al máxim el tiemp que se hubiese incurrid en realizar dicha cnsulta sbre una base de dats transaccinal Indicadres Ls indicadres sn sumarizacines efectuadas sbre algún hech expresines basadas en sumarizacines, que serán incluids en algún cub multidimensinal, cn el fin de analizar ls dats almacenads en el DW. El valr que ests adpten estará cndicinad pr ls atributs/jerarquías que se utilicen para analizarls. Ls indicadres, además de hechs, pueden estar cmpuests pr trs indicadres, per n ambs simultáneamente. Pueden utilizarse para su creación funcines de sumarización (suma, cnte, prmedi, etc), funcines matemáticas, estadísticas, peradres matemátics y lógics Atributs

35 Ls atributs cnstituyen ls criteris de análisis que se utilizarán para analizar ls indicadres dentr de un cub multidimensinal. Ls misms se basan, en su gran mayría, en ls camps de las tablas de dimensines y/ expresines. Dentr de un cub multidimensinal, ls atributs sn ls ejes del mism Jerarquías Una jerarquía representa una relación lógica entre ds más atributs pertenecientes a un cub multidimensinal; siempre y cuand psean su crrespndiente relación padre-hij. Las jerarquías pseen las siguientes características: Pueden existir varias en un mism cub. Están cmpuestas pr ds más niveles. Se tiene una relación 1-n padre-hij entre atributs cnsecutivs de un nivel superir y un inferir. Pr l general, las jerarquías pueden identificarse fácilmente, debid a que existen relacines 1- n padre-hij entre ls prpis atributs de un cub. La principal ventaja de manejar jerarquías, reside en pder analizar ls dats desde su nivel más general al más detallad y viceversa, al desplazarse pr ls diferentes niveles. La siguiente figura muestra un pequeñ ejempl de l recién expuest: Figura 3.14: Jerarquía Fechas.

36 Aquí, se puede apreciar claramente cm se cnstruye una jerarquía: 1. Se crearn ds atributs, FECHA - Añ y FECHA - Mes, ls cuales están cnstituids de la siguiente manera: FECHA - Añ = FECHA.Añ FECHA - Mes = FECHA.Mes A la izquierda de la igualdad se encuentra el nmbre del atribut; a la derecha el nmbre del camp de la tabla de dimensión FECHA. 2. Se creó la jerarquía llamada Jerarquía Fechas, en la cual se clcó el atribut más general en la cabecera y se cmenzó a disgregar ls niveles hacia abaj. En este cas, la figura se explica cm sigue: Un mes del añ pertenece sl a un añ. Un añ puede pseer un más meses del añ a) Relación Una relación representa la frma en que ds atributs interactúan dentr de una jerarquía. Existen básicamente ds tips de relacines: Explícitas: sn las más cmunes y se pueden mdelar a partir de atributs directs y están en línea cntinua de una jerarquía, pr ejempl, un país psee una más prvincias y una prvincia pertenece sl a un país. Implícitas: sn las que curren en la vida real, per su relación n es de vista directa, pr ejempl, una prvincia tiene un más rís, per un rí pertenece a una más prvincias. Cm se puede bservar, este cas se trata de una relación muchs a muchs b) Granularidad La granularidad representa el nivel de detalle al que se desea almacenar la infrmación sbre el negci que se esté analizand. Pr ejempl, ls dats referentes a ventas cmpras realizadas pr una empresa, pueden registrarse día a día, en cambi, ls dats pertinentes a pags de suelds cutas de scis, pdrán almacenarse a nivel de mes. Mientras mayr sea el nivel de detalle de ls dats, se tendrán mayres psibilidades analíticas, ya que ls misms pdrán ser resumids sumarizads. Es decir, ls dats que psean granularidad fina (nivel de detalle) pdrán ser resumids hasta btener una granularidad media gruesa. N sucede l mism en sentid cntrari, ya que pr ejempl, ls dats almacenads cn granularidad media pdrán resumirse, per n tendrán la facultad de ser analizads a nivel de detalle. O sea, si la granularidad cn que se guardan ls registrs es a nivel de día, ests dats pdrán sumarizarse pr semana, mes, semestre y añ, en cambi, si ests registrs se almacenan a nivel de mes, pdrán sumarizarse pr semestre y añ, per n l pdrán hacer pr día y semana.

37 Tips de mdelamient de un DW Esquema en Estrella El esquema en estrella, cnsta de una tabla de hechs central y de varias tablas de dimensines relacinadas a esta, a través de sus respectivas claves. En la siguiente figura se puede apreciar un esquema en estrella estándar: Figura 3.15: Esquema en Estrella. El mdel ejemplificad cuand se abrd el tema de las tablas de hechs, es un esquema en estrella, pr l cual se l vlverá a mencinar para explicar sus cualidades. Figura 3.16: Esquema en Estrella, ejempl.

38 Este mdel debe estar ttalmente desnrmalizad, es decir que n puede presentarse en tercera frma nrmal (3ra FN), es pr ell que pr ejempl, la tabla de dimensión PRODUCTOS cntiene ls camps Rubr, Tip y NmbrePrduct. Si se nrmaliza esta tabla, se btendrá el siguiente resultad: Figura 3.17: Desnrmalización. Cuand se nrmaliza, se pretende eliminar la redundancia, la repetición de dats y que las claves sean independientes de las clumnas, per en este tip de mdels se requiere n evitar precisamente est. Las ventajas que trae aparejada la desnrmalización, sn las de bviar unines (Jin) entre las tablas cuand se realizan cnsultas, prcurand así un mejr tiemp de respuesta y una mayr sencillez cn respect a su utilización. El punt en cntra, es que se genera un ciert grad de redundancia, per el ahrr de espaci n es significativ. El esquema en estrella es el más simple de interpretar y ptimiza ls tiemps de respuesta ante las cnsultas de l@s usuari@s. Este mdel es sprtad pr casi tdas las herramientas de cnsulta y análisis, y ls metadats sn fáciles de dcumentar y mantener, sin embarg es el mens rbust para la carga y es el más lent de cnstruir. A cntinuación se destacarán algunas características de este mdel, que ayudarán a cmprender mejr el pr qué de sus ventajas: Psee ls mejres tiemps de respuesta. Su diseñ es fácilmente mdificable. Existe paralelism entre su diseñ y la frma en que l@s usuari@s visualizan y manipulan ls dats. Simplifica el análisis. Facilita la interacción cn herramientas de cnsulta y análisis.

39 Esquema Cp de Nieve Este esquema representa una extensión del mdel en estrella cuand las tablas de dimensines se rganizan en jerarquías de dimensines. Figura 3.18: Esquema Cp de Nieve. Cm se puede apreciar en la figura anterir, existe una tabla de hechs central que está relacinada cn una más tablas de dimensines, quienes a su vez pueden estar relacinadas n cn una más tablas de dimensines. Este mdel es más cercan a un mdel de entidad relación, que al mdel en estrella, debid a que sus tablas de dimensines están nrmalizadas. Una de ls mtivs principales de utilizar este tip de mdel, es la psibilidad de segregar ls dats de las tablas de dimensines y prveer un esquema que sustente ls requerimients de diseñ. Otra razón es que es muy flexible y puede implementarse después de que se haya desarrllad un esquema en estrella. Se pueden definir las siguientes características de este tip de mdel: Psee mayr cmplejidad en su estructura. Hace una mejr utilización del espaci. Es muy útil en tablas de dimensines de muchas tuplas. Las tablas de dimensines están nrmalizadas, pr l que requiere mens esfuerz de diseñ. Puede desarrllar clases de jerarquías fuera de las tablas de dimensines, que permiten realizar análisis de l general a l detallad y viceversa. A pesar de tdas las características y ventajas que trae aparejada la implementación del esquema cp de nieve, existen ds grandes incnvenientes de ell:

40 Si se pseen múltiples tablas de dimensines, cada una de ellas cn varias jerarquías, se creará un númer de tablas bastante cnsiderable, que pueden llegar al punt de ser inmanejables. Al existir muchas unines y relacines entre tablas, el desempeñ puede verse reducid. La existencia de las diferentes jerarquías de dimensines debe estar bien fundamentada, ya que de tr md las cnsultas demrarán más tiemp en devlver ls resultads, debid a que se deben realizar las unines entre las tablas Esquema Cnstelación Este mdel está cmpuest pr una serie de esquemas en estrella, y tal cm se puede apreciar en la siguiente figura, está frmad pr una tabla de hechs principal ( HECHOS_A ) y pr una más tablas de hechs auxiliares ( HECHOS_B ), las cuales pueden ser sumarizacines de la principal. Dichas tablas yacen en el centr del mdel y están relacinadas cn sus respectivas tablas de dimensines. N es necesari que las diferentes tablas de hechs cmpartan las mismas tablas de dimensines, ya que, las tablas de hechs auxiliares pueden vincularse cn sl algunas de las tablas de dimensines asignadas a la tabla de hechs principal, y también pueden hacerl cn nuevas tablas de dimensines. Figura 3.19: Esquema Cnstelación. Su diseñ y cualidades sn muy similares a las del esquema en estrella, per psee una serie de diferencias cn el mism, que sn precisamente las que l destacan y caracterizan. Entre ellas se pueden mencinar: Permite tener más de una tabla de hechs, pr l cual se pdrán analizar más aspects claves del negci cn un mínim esfuerz adicinal de diseñ.

41 Cntribuye a la reutilización de las tablas de dimensines, ya que una misma tabla de dimensión puede utilizarse para varias tablas de hechs. N es sprtad pr tdas las herramientas de cnsulta y análisis OLTP vs DW Debid a que, ya se han explicad y caracterizad ls distints tips de esquemas del DW, se prcederá a expner las raznes de su utilización, cm así también las causas de pr qué n se emplean simplemente las estructuras de las bases de dats tradicinales: Ls OLTP sn diseñads para sprtar el prcesamient de infrmación diaria de las empresas, y el énfasis recae en maximizar la capacidad transaccinal de sus dats. Su estructura es altamente nrmalizada, para brindar mayr eficiencia a sistemas cn muchas transaccines que acceden a un pequeñ númer de registrs y están fuertemente cndicinadas pr ls prcess peracinales que deben sprtar, para la óptima actualización de sus dats. Esta estructura es ideal para llevar a cab el prces transaccinal diari, brindar cnsultas sbre ls dats cargads y tmar decisines diarias, en cambi ls esquemas de DW están diseñads para pder llevar a cab prcess de cnsulta y análisis para lueg tmar decisines estratégicas y tácticas de alt nivel. A cntinuación se presentará una tabla cmparativa entre ls ds ambientes, que resume sus principales diferencias: Figura 3.20: OLTP vs Data Warehuse.

42 Tips de implementación de un DW ROLAP Este tip de rganización física se implementa sbre tecnlgía relacinal, per dispnen de algunas facilidades para mejrar el rendimient. Es decir, ROLAP (Relatinal On Line Analytic Prcessing) cuenta cn tds ls beneficis de una SGBD Relacinal a ls cuales se les prvee extensines y herramientas para pder utilizarl cm un Sistema Gestr de DW. En ls sistemas ROLAP, ls cubs multidimensinales se generan dinámicamente al instante de realizar las diferentes cnsultas, haciend de esta manera el manej de cubs transparente l@s usuari@s. Este prces se puede resumir a través de ls siguientes pass: 1. Se seleccinan ls indicadres, atributs, jerarquías, etc, que cmpndrán el cub multidimensinal. 2. Se ejecutan las cnsultas sbre ls atributs, indicadres, etc, seleccinads en el pas anterir. Entnces, de manera transparente a l@s usuari@s se crea y calcula dinámicamente el cub crrespndiente, el cual dará respuesta a las cnsultas que se ejecuten. Al n tener que intervenir l@s usuari@s en la creación y el mantenimient explícit de ls cubs, ROLAP brinda mucha flexibilidad, ya que dichs cubs sn generads dinámicamente al mment de ejecutar las cnsultas. Psibilitand de esta manera la btención de cnsultas ad hc. La principal desventaja de ls sistemas ROLAP, es que ls dats de ls cubs se deben calcular cada vez que se ejecuta una cnsulta sbre ells. Est prvca que ROLAP n sea muy eficiente en cuant a la rapidez de respuesta ante las cnsultas de l@s usuari@s. Para incrementar la velcidad de respuesta, en alguns cass se puede ptar pr almacenar ls resultads btenids de ciertas cnsultas en la memria caché (ya sea en el servidr en una terminal), para que en un futur, cuand se desee vlver a ejecutar dicha cnsulta, ls valres sean btenids más velzmente. Cabe aclarar que si ls dats del DW sn almacenads y gestinads a través de un SGBD Relacinal, n se requiere de tr sftware que administre y gestine ls dats de manera Multidimensinal. Entre las características más imprtantes de ROLAP, se encuentran las siguientes: Almacena la infrmación en una base de dats relacinal. Utiliza índices de mapas de bits. Utiliza índices de Jin. Psee ptimizadres de cnsultas. Cuenta cn extensines de SQL (drill-up, drill-dwn, etc).

43 Cm se aclaró anterirmente, el almacén de dats se rganiza a través de una base de dats multidimensinal, sin embarg, puede ser sprtad pr un SGBD Relacinal. Para lgrar est se utilizan ls diferentes esquemas, en estrella, cp de nieve y cnstelación, ls cuales transfrmarán el mdel multidimensinal y permitirán que pueda ser gestinad pr un SGDB Relacinal, ya que sl se almacenarán tablas MOLAP El bjetiv de ls sistemas MOLAP (Multidimentinal On Line Analytic Prcessing) es almacenar físicamente ls dats en estructuras multidimensinales de manera que la representación externa y la interna cincidan. Para ell, se dispne de estructuras de almacenamient específicas (Arrays) y técnicas de cmpactación de dats que favrecen el rendimient del DW. MOLAP requiere que en una instancia previa se generen y calculen ls cubs multidimensinales, para que lueg puedan ser cnsultads. Este prces se puede resumir a través de ls siguientes pass: 1. Se seleccinan ls indicadres, atributs, jerarquías, etc., que cmpndrán el cub multidimensinal. 2. Se precalculan ls dats del cub. 3. Se ejecutan las cnsultas sbre ls dats precalculads del cub. El principal mtiv de precalcular ls dats de ls cubs, es que psibilita que las cnsultas sean respndidas cn mucha rapidez, ya que ls misms n deben ser calculads en tiemp de ejecución, bteniend de esta manera una muy buena perfrmance. Existen una serie de desventajas que están directamente relacinadas cn la ventaja de precalcular ls dats de ls cubs multidimensinales, ellas sn: Cada vez que se requiere es necesari realizar cambis sbre algún cub, se debe tener que recalcularl ttalmente, para que se reflejen las mdificacines llevadas a cab. Prvcand de esta manera una disminución imprtante en cuant a flexibilidad. Se precisa más espaci físic para almacenar dichs dats (esta desventaja n es tan significativa). Habitualmente, ls dats del DW sn almacenads y gestinads a través de SGBD Relacinales, ya que ests tienen la ventaja de pder realizar cnsultas directamente a través del lenguaje SQL. En ests cass, para la generación de ls cubs multidimensinales se requiere de tr sftware que administre y gestine ls dats de manera Multidimensinal HOLAP HOLAP (Hybrid On Line Analytic Prcessing) cnstituye un sistema híbrid entre MOLAP y ROLAP, que cmbina estas ds implementacines para almacenar alguns dats en un mtr relacinal y trs en una base de dats multidimensinal.

44 Ls dats agregads y precalculads se almacenan en estructuras multidimensinales y ls de menr nivel de detalle en estructuras relacinales. Es decir, se utilizará ROLAP para navegar y explrar ls dats, y se empleará MOLAP para la realización de tablers. Cm cntrapartida, hay que realizar un buen análisis para identificar ls diferentes tips de dats ROLAP vs MOLAP En la siguiente tabla cmparativa se pueden apreciar las principales diferencias entre ests ds tips de implementación: Figura 3.21: ROLAP vs MOLAP Cub Multidimensinal: prfundización Ahra que ya se tiene una visión general de ls tips de mdelamient e implementación de un DW, se vlverá a abrdar el tema de ls cubs multidimensinales, per esta vez se hará énfasis en su cnstrucción y se ejemplificará cada pas, a fin de que se puedan visualizar mejr ls resultads de cada acción. La frma que se utilizará para graficar el cub que se creará, será la siguiente:

45 Figura 3.22: Cub estándar. Tal y cm pdems bservar, el gráfic tma una estructura de árbl, en la cuál en la raíz figura el cub en cuestión y dependiend de este sus diferentes bjets relacinads. En el cas de las jerarquías, ls atributs que la cmpnen, también deben estructurarse en frma de árbl, teniend en cuenta su respectiva relación padre-hij. Se tmará cm base para la realización de ls ejempls, el siguiente esquema en estrella: Figura 3.23: Esquema en Estrella. Cm primer pas se creará un cub multidimensinal llamad Cub de Ventas, gráficamente: Figura 3.24: Cub multidimensinal, pas 1. Lueg se crearán ds atributs:

46 De la tabla de dimensión PRODUCTOS, se tmará el camp Prduct para la creación del atribut denminad: PRODUCTOS - Prduct. De la tabla dimensión MARCAS, se tmará el camp Marca para la creación del atribut denminad: MARCAS - Marca. Gráficamente: Figura 3.25: Cub multidimensinal, pas 2. También se creará un indicadr: De la tabla de hechs VENTAS, se sumarizará el hech Venta para crear el indicadr denminad: VENTAS - Venta. La fórmula utilizada para crear este indicadr es la siguiente: VENTAS - Venta = SUM(VENTAS.Venta). Gráficamente: Figura 3.26: Cub multidimensinal, pas 3. En este mment, tenems un cub multidimensinal de ds dimensines, cuya representación matricial sería la siguiente:

47 Figura 3.27: Cub multidimensinal de ds dimensines. Este cub psee ds ejes dimensines, PRODUCTOS - Prduct y MARCAS - Marca. La intersección de ls ejes representa las ventas de cada prduct cn su respectiva marca (indicadr VENTAS - Venta ). Pr ejempl: Las ventas asciadas al prduct P1 y a la marca M1 sn 40. Las ventas asciadas al prduct P1 y a la marca M2 sn 25. Las ventas asciadas al prduct P1 y a la marca M3 sn 60. Ahra, al cub plantead se le agregará un nuev atribut: De la tabla de dimensión CLIENTES, se tmará el camp Cliente para la creación del atribut denminad: CLIENTES - Cliente. Gráficamente: Figura 3.28: Cub multidimensinal, pas 4. De esta manera, ahra tenems un cub multidimensinal de tres dimensines, cuya representación matricial sería la siguiente:

48 Figura 3.29: Cub multidimensinal de tres dimensines. En este cas ls valres del indicadr VENTAS - Venta están dads de acuerd a las ventas de cada prduct, de cada marca, a cada cliente. Para finalizar, se añadirá un cuart atribut al cub: De la tabla de dimensión TIEMPO, se tmará el camp Añ para la creación del atribut denminad: TIEMPO - Añ. Gráficamente: Figura 3.30: Cub multidimensinal, pas 5. Entnces, la representación matricial del cub multidimensinal resultante sería la siguiente:

49 Figura 3.31: Cub multidimensinal de cuatr dimensines. Ls valres del indicadr VENTAS - Venta en este mment, estarán cndicinads pr las ventas de cada prduct, de cada marca, a cada cliente, en cada añ. Esta última imagen, demuestra claramente ls cncepts expuests de la tabla de dimensión tiemp, dnde se decía que pueden existir diferentes versines de la situación del negci. Cabe aclarar que pueden crearse tants cubs se deseen y que ls misms pueden cexistir sin ningún incnveniente Metadats Ls metadats sn dats que describen dan infrmación de trs dats, que en este cas, existen en la arquitectura del Data Warehusing. Brindan infrmación de lcalización, estructura y significad de ls dats, básicamente mapean ls misms. El cncept de metadats es análg al us de índices para lcalizar bjets en lugar de dats. Es imprtante aclarar que existen metadats también en las bases de dats transaccinales, per ls misms sn transparentes a l@s usuari@s. La gran ventaja que trae aparejada el Data Warehusing en relación cn ls metadats es que l@s usuari@s pueden gestinarls, exprtarls, imprtarls, realizarles mantenimient e interactuar cn ells, ya sea manual autmáticamente. Las funcines que cumplen ls metadats en el ambiente Data Warehusing sn muy imprtantes y significativas, algunas de ellas sn: Facilitan el fluj de trabaj, cnvirtiend dats autmáticamente de un frmat a tr. Cntienen un directri para facilitar la búsqueda y descripción de ls cntenids del DW, tales cm: bases de dats, tablas, nmbres de atributs, sumarizacines, acumulacines, reglas de negcis, estructuras y mdels de dats, relacines de integridad, jerarquías, etc. Pseen un guía para el mapping, de cóm se transfrman e integran ls dats de las fuentes peracinales y externs al ambiente del depósit de dats.

50 Almacenan las referencias de ls algritms utilizads para la esquematización entre el detalle de dats actuales, cn ls dats ligeramente resumids y ésts cn ls dats altamente resumids, etc. Cntienen las definicines del sistema de registr desde el cual se cnstruye el DW. Se pueden distinguir tres diferentes tips de Metadats: Ls metadats de ls prcess ETL, referids a las diversas fuentes utilizadas, reglas de extracción, transfrmación, limpieza, depuración y carga de ls dats al depósit. Ls metadats peracinales, que sn ls que básicamente almacenan tds ls cntenids del DW, para que este pueda desempeñar sus tareas. Ls metadats de cnsulta, que cntienen las reglas para analizar y expltar la infrmación del almacén, tales cm drill-up y drill-dwn. Sn ests metadats ls que las herramientas de análisis y cnsulta emplearán para realizar dcumentacines y para navegar pr ls dats Mapping El términ mapping, se refiere a relacinar un cnjunt de bjets, tal cm actualmente están almacenads en memria en disc, cn trs bjets. Pr ejempl: una estructura de base de dats lógica, se pryecta sbre la base de dats física. 3.5 Query Manager 3.5 Query Manager Drill-dwn Drill-up Drill-acrss Rll-acrss Pivt Page Drill-thrugh 3.5. Query Manager

51 Figura 3.32: Query Manager. Este cmpnente realiza las peracines necesarias para sprtar ls prcess de gestión y ejecución de cnsultas relacinales, tales cm Jin y agregacines, y de cnsultas prpias del análisis de dats, cm drill-up y drill-dwn. Query Manager recibe las cnsultas de l@s usuari@s, las aplica a la estructura de dats crrespndiente (cub multidimensinal, Business Mdels, etc.) y devuelve ls resultads btenids. Cabe aclarar que una cnsulta a un DW, generalmente cnsiste en la btención de indicadres a partir de ls dats (hechs) de una tabla de hechs, restringidas pr las prpiedades cndicines de ls atributs que hayan sid creads. Las peracines que se pueden realizar sbre mdels multidimensinales y que sn las que verdaderamente les permitirán a l@s usuari@s explrar e investigar ls dats en busca de respuestas, sn: Drill-dwn. Drill-up. Drill-acrss. Rll-acrss. Pivt. Page. Drill-thrugh. A cntinuación, se explicará cada una de ellas y se ejemplificará su utilización, para l cual se utilizará cm guía el siguiente esquema en estrella.

52 Figura 3.33: Esquema en Estrella. El mism psee cuatr tablas de dimensines y una tabla de hechs central, en la cual el hech Venta representa las ventas a un cliente, de un prduct en particular, de una marca específica en un añ dad. Sbre este mdel, entnces, se creará un cub llamad Cub - Query Manager que será utilizad para explicar las peracines del Query Manager. El mism cntiene ls siguientes bjets: De la tabla de hechs VENTAS, se sumarizará el hech Venta para crear el indicadr denminad: VENTAS - Venta. La fórmula utilizada para crear este indicadr es la siguiente: VENTAS - Venta = SUM(VENTAS.Venta). De la tabla de dimensión MARCAS, se tmará el camp Marca para la creación del atribut denminad: MARCAS - Marca. De la tabla dimensión TIEMPO, se tmará el camp Añ para la creación del atribut denminad: TIEMPO - Añ. De la tabla dimensión PRODUCTOS, se tmará el camp Prduct para la creación del atribut denminad: PRODUCTOS - Prduct. De la tabla dimensión PRODUCTOS, se tmará el camp Clase para la creación del atribut denminad: PRODUCTOS - Clase.

53 Se definió la jerarquía Jerarquía PRODUCTOS, que se aplicará sbre ls atributs recientemente creads, PRODUCTOS - Prduct y PRODUCTOS - Clase, en dnde: Una clase de prduct pertenece sl a un prduct. Un prduct puede ser de una más clases. Gráficamente: Figura 3.34: PRODUCTOS, relación padre-hij. Entnces, el cub quedará cnfrmad de la siguiente manera: Figura 3.35: Cub - Query Manager. Para simplificar ls ejempls que se presentarán, se utilizará sl una pequeña muestra de dats crrespndientes al añ Drill-dwn Permite apreciar ls dats en un mayr detalle, bajand pr una jerarquía definida en un cub. Est brinda la psibilidad de intrducir un nuev nivel criteri de agregación en el análisis, disgregand ls grups actuales. Drill-dwn es ir de l general a l específic. Gráficamente:

54 Figura 3.36: Drill-dwn. Para explicar esta peración se utilizará la siguiente representación tabular: Figura 3.37: Resultads antes de aplicar Drill-dwn. Cm puede apreciarse, en la cabecera de la tabla se encuentran ls atributs y el indicadr (destacad cn clr de fnd diferente) definids anterirmente en el cub multidimensinal; y en el cuerp de la misma se encuentran ls valres crrespndientes. Se ha resaltad la primera fila, ya que es la que se analizará más en detalle. En este cas, se realizará drill-dwn sbre la jerarquía Jerarquía PRODUCTOS, entnces: Figura 3.38: Resultads después de aplicar Drill-dwn.

55 Tal y cm puede apreciarse en ls ítems resaltads de la tabla, se agregó un nuev nivel de detalle ( PRODUCTOS Clase ) a la lista inicial, y el valr 40 que pertenecía a las ventas del Prduct1, de la marca M1, en el añ 2007, se dividió en ds filas. Est se debe a que ahra se tendrá en cuenta el atribut PRODUCTOS - Clase para realizar las sumarizacines del indicadr VENTAS - Venta. La siguiente imagen muestra este mism prces per, representad matricialmente: Figura 3.39: Drill-dwn, representación matricial. De aquí en más se utilizará esta frma para explicar cada peración Drill-up Permite apreciar ls dats en menr nivel de detalle, subiend pr una jerarquía definida en un cub. Est brinda la psibilidad de quitar un nivel criteri de agregación en el análisis, agregand ls grups actuales. Drill-up es ir de l específic a l general. Gráficamente: Figura 3.40: Drill-up.

56 Se tmará cm referencia ls resultads anterires: Figura 3.41: Resultads antes de aplicar Drill-up. Se aplicará drill-up sbre la jerarquía Jerarquía PRODUCTOS, entnces: Figura 3.42: Resultads después de aplicar Drill-up. Cm se puede bservar en la lista resultante, en la fila resaltada se sumarizarn ls valres 22 y 18 de la tabla inicial, debid a que al eliminar el atribut PRODUCTOS - Clase, las ventas se agruparn sumarizarn de acuerd a PRODUCTOS - Prduct, MARCAS - Marca y TIEMPO - Añ. La siguiente imagen muestra este mism prces per, representad matricialmente:

57 Figura 3.43: Drill-up, representación matricial Drill-acrss Funcina de frma similar a drill-dwn, cn la diferencia de que drill-acrss n se realiza sbre una jerarquía, sin que su frma de ir de l general a l específic es agregar un atribut a la cnsulta cm nuev criteri de análisis. Se partirá de ls siguientes resultads: Figura 3.44: Resultads antes de aplicar Drill-acrss. Ahra, se aplicará drill-acrss, al agregar el atribut MARCAS - Marca, entnces: Figura 3.45: Resultads después de aplicar Drill-acrss. La siguiente imagen muestra este mism prces per, representad matricialmente:

58 Figura 3.46: Drill-acrss, representación matricial Rll-acrss Funcina de frma similar a drill-up, cn la diferencia de que rll-acrss n se hace sbre una jerarquía, sin que su frma de ir de l específic a l general es quitar un atribut de la cnsulta, eliminand de esta manera un criteri de análisis. Se tmará cm base la representación tabular anterir: Figura 3.47: Resultads antes de aplicar Rll-acrss. Se aplicará la peración rll-acrss, quitand de la cnsulta el atribut MARCAS - Marca, entnces: Figura 3.48: Resultads después de aplicar Rll-acrss. La siguiente imagen muestra este mism prces per, representad matricialmente:

59 Figura 3.49: Rll-acrss, representación matricial Pivt Permite seleccinar el rden de visualización de ls atributs e indicadres, cn el bjetiv de analizar la infrmación desde diferentes perspectivas. Se tmará cm referencia, para explicar esta peración, la siguiente tabla: Figura 3.50: Resultads antes de aplicar Pivt. Cm puede apreciarse, el rden de ls atributs es: TIEMPO - Añ, PRODUCTOS - Prduct y MARCAS - Marca. Ahra, se hará pivt, rerientand la vista multidimensinal: Figura 3.51: Resultads después de aplicar Pivt.

60 El nuev rden de ls atributs es: MARCAS - Marca, TIEMPO - Añ y PRODUCTOS - Prduct. La siguiente imagen muestra este mism prces per, representad matricialmente: Figura 3.52: Pivt, representación matricial. Pivt permite realizar las siguientes accines: Mver un atribut indicadr desde el encabezad de fila al encabezad de clumna. Mver un atribut indicadr desde el encabezad de clumna al encabezad de fila. Cambiar el rden de ls atributs indicadres del encabezad de clumna. Cambiar el rden de ls atributs indicadres del encabezad de fila Page Presenta el cub dividid en seccines, a través de ls valres de un atribut, cm si se tratase de páginas de un libr. Gráficamente:

61 Figura 3.53: Page. Page es muy útil cuand las cnsultas devuelven muchs registrs y es necesari desplazarse pr ls dats para pder verls en su ttalidad. Se tmará cm referencia, para explicar esta peración, la siguiente tabla: Figura 3.54: Resultads antes de aplicar Page. Se realizará Page sbre el atribut PRODUCTOS - Prduct, entnces se btendrán las siguientes páginas: Página Nr 1:

62 Figura 3.55: Página Nr 1, representación tabular. Matricialmente: Figura 3.56: Página Nr 1, representación matricial. Página Nr 2: Figura 3.57: Página Nr 2, representación tabular. Matricialmente:

63 Figura 3.58: Página Nr 2, representación matricial. Cuand existe más de un criteri pr el cual realizar Page, debe tenerse en cuenta el rden en que ests serán prcesads, ya que dependiend de est, de pdrán btener diferentes resultads sbre una misma cnsulta. Para ejemplificar este cncept se utilizará cm base la tabla expuesta al inici. Entnces, si se desea realizar Page pr PRODUCTOS - Prduct y MARCAS - Marca, se dispndrá de ds pcines de rdenación: 1. Primer pr PRODUCTOS - Prduct y lueg pr MARCAS - Marca : en este cas, si se seleccina la página crrespndiente al prduct Prduct1, se btendrán las siguientes sub-páginas, que se crrespnden cn ls valres de las marcas: M1, M2 y M3. Expresad en esquema de árbl jerárquic, quedaría cm sigue: Página Nr 1: Prduct1 Sub-página Nr 1.1: M1. Sub-página Nr 1.2: M2. Sub-página Nr 1.3: M3. Página Nr 2: Prduct2 Sub-página Nr 2.1: M1. Sub-página Nr 2.2: M2. Sub-página Nr 2.3: M3. Cm puede bservarse, se btendrán ds páginas, cn tres sub-páginas cada una de ellas. 2. Primer pr MARCAS - Marca y lueg pr PRODUCTOS - Prduct : en este cas, si se seleccina la página crrespndiente a la marca M1, se btendrán las siguientes subpáginas, que se crrespnden cn ls valres de ls prducts: Prduct1 y Prduct2. Expresad en esquema de árbl jerárquic, quedaría cm sigue: Página Nr 1: M1

64 Sub-página Nr 1.1: Prduct1. Sub-página Nr 1.2: Prduct2. Página Nr 2: M2 Sub-página Nr 2.1: Prduct1. Sub-página Nr 2.2: Prduct2. Página Nr 3: M3 Sub-página Nr 3.1: Prduct1. Sub-página Nr 3.2: Prduct2. Cm puede bservarse, se btendrán tres páginas, cn ds sub-páginas cada una de ellas. Es decir, el primer criteri utilizad para realizar Page cndicina ls valres dispnibles en el segund, y así sucesivamente Drill-thrugh Permite apreciar ls dats en su máxim nivel de detalle. Est brinda la psibilidad de analizar cuáles sn ls dats relacinads al valr de un Indicadr, que se ha sumarizad dentr del cub multidimensinal. Se tmará cm referencia, para explicar esta peración, la siguiente tabla: Figura 3.59: Resultads antes de aplicar Drill-thrugh. Se aplicará la peración drill-thrugh sbre el Indicadr de la fila seleccinada, para btener el detalle de este valr:

65 Figura 3.60: Resultads después de aplicar Drill-thrugh. La siguiente imagen muestra este mism prces per, representad matricialmente: Figura 3.61: Drill-thrugh, representación matricial. 3.6 Herramientas de Cnsulta y Análisis 3.6 Herramientas de Cnsulta y Análisis Reprtes y Cnsultas OLAP Dashbards Data Mining Redes Neurnales Sistemas Experts Prgramación Genética Árbles de Decisión Detección de Desviación EIS

66 3.6. Herramientas de Cnsulta y Análisis Figura 3.59: Herramientas de Cnsulta y Análisis. Las herramientas de cnsulta y análisis sn sistemas que permiten a l@s usuari@s realizar la explración de dats del DW. Básicamente cnstituyen el nex entre el depósit de dats y l@s usuari@s. Utilizan la metadata de las estructuras de dats que han sid creadas previamente (cubs multidimensinales, Business Mdels, etc.) para trasladar a través de cnsultas SQL ls requerimients de l@s usuari@s, para lueg, devlver el resultad btenid. Estas herramientas también pueden emplear simples cnexines a bases de dats (JNDI, JDBC, ODBC), para btener la infrmación deseada. A través de una interfaz gráfica y una serie de pass, l@s usuari@s generan cnsultas que sn enviadas desde la herramienta de cnsulta y análisis al Query Manager, este a su vez realiza la extracción de infrmación al DW Manager y devuelve ls resultads btenids a la herramienta que se ls slicitó. Lueg, ests resultads sn expuests ante l@s usuari@s en frmats que le sn familiares. Este prces se puede cmprender mejr al bservar la siguiente figura: Figura 3.60: Prces de Cnsulta y Análisis.

67 El mism, se lleva a cab a través de seis pass sucesivs: 1. L@s usuari@s seleccinan establecen que dats desean btener del DW, mediante las interfaces de la herramienta que utilice. 2. La herramienta recibe el pedid de l@s usuari@s, cnstruye la cnsulta (utilizand la metadata) y la envía al Query Manager. 3. El Query Manager ejecuta la cnsulta sbre la estructura de dats cn la que se esté trabajand (cub multidimensinal, Business Mdel, etc.). 4. El Query Manager btiene ls resultads de la cnsulta. 5. El Query Manager envía ls dats a la herramienta de cnsulta y análisis. 6. La herramienta presentan a l@s usuari@s la infrmación requerida. Una de las principales ventajas de utilizar estas herramientas, es que l@s usuari@s n se tienen que precupar pr cncer cuáles sn las características y funcinalidades de las estructuras de dats utilizadas, ni pr saber emplear el lenguaje SQL, sl se deben enfcar en el análisis. Las herramientas de cnsulta y análisis, en general, cmparten las siguientes características: Accesibilidad a la infrmación: permiten el acces a la infrmación a través de las diferentes estructuras de dats de frma transparente a l@s usuari@s finales, para que est@s sl se enfquen en el análisis y n en el rigen y prcedencia de ls dats. Apy en la tma de decisines: permiten la explración de ls dats, a fin de seleccinar, filtrar y persnalizar ls misms, para la btención de infrmación prtuna, relevante y útil, para apyar el prces de tma de decisines. Orientación l@s usuari@s finales: permiten a través de entrns amigables e intuitivs, que l@s usuari@s puedan realizar análisis y cnsultas, sin pseer cncimients técnics. Si bien l realmente imprtante sn ls dats misms, que ests puedan ser interpretads y analizads pr l@s usuari@s dependerá en gran medida de cóm se presenten y dispngan. Existen diferentes tips de herramientas de cnsulta y análisis, y de acuerd a la necesidad, tips de usuari@s y requerimients de infrmación, se deberán seleccinar las más prpicias al cas. Entre ellas se destacan las siguientes: Reprtes y Cnsultas. OLAP. Dashbards. Data Mining. EIS Reprtes y Cnsultas

68 Se han desarrllad muchas herramientas para la prducción de cnsultas y reprtes, que frecen a l@s usuari@s, a través de pantallas gráficas intuitivas, la psibilidad de generar infrmes avanzads y detallads del tema de interés de interés que se este analizand. L@s usuari@s sl deben seguir una serie de simples pass, cm pr ejempl seleccinar pcines de un menú, presinar tal cual btón para especificar ls elements de dats, sus cndicines, criteris de agrupación y demás atributs que se cnsideren significativs. Actualmente las herramientas de generación de reprtes y cnsultas cuentan cn muchas prestacines, las cuales permiten dar variadas frmas y frmats a la presentación de la infrmación. Entre las pcines más cmunes se encuentran las siguientes: Parametrización de ls dats devuelts. Selección de frmats de salida (planilla de cálcul, HTML, PDF, etc.). Inclusión de gráfics de trtas, barras, etc. Utilización de plantillas de frmats de fnds. Inclusión de imágenes. Frmats tipgráfics. Links a trs reprtes OLAP El prcesamient analític en línea OLAP (On Line Analytic Prcessing), es la cmpnente más pdersa del Data Warehusing, ya que es el mtr de cnsultas especializad del depósit de dats. Las herramientas OLAP, sn una tecnlgía de sftware para análisis en línea, administración y ejecución de cnsultas, que permiten inferir infrmación del cmprtamient del negci. Su principal bjetiv es el de brindar rápidas respuestas a cmplejas preguntas, para interpretar la situación del negci y tmar decisines. Cabe destacar que l que es realmente interesante en OLAP, n es la ejecución de simples cnsultas tradicinales, sin la psibilidad de utilizar peradres tales cm drill-up, drill-dwn, etc, para expltar prfundamente la infrmación. Además, a través de este tip de herramientas, se puede analizar el negci desde diferentes escenaris histórics, y pryectar cm se ha venid cmprtand y evlucinand en un ambiente multidimensinal, sea, mediante la cmbinación de diferentes perspectivas, temas de interés dimensines. Est permite deducir tendencias, pr medi del descubrimient de relacines entre las perspectivas que a simple vista n se pdrían encntrar sencillamente. Las herramientas OLAP requieren que ls dats estén rganizads dentr del depósit en frma multidimensinal, pr l cual se utilizan cubs multidimensinales. Además de las características ya descritas, se pueden enumerar las siguientes:

69 Permite reclectar y rganizar la infrmación analítica necesaria para l@s usuari@s y dispner de ella en diverss frmats, tales cm tablas, gráfics, reprtes, tablers de cntrl, etc. Sprta análisis cmplejs de grandes vlúmenes de dats. Cmplementa las actividades de tras herramientas que requieran prcesamient analític en línea. Presenta a l@s usuari@s una visión multidimensinal de ls dats (matricial) para cada tema de interés del negci. Es transparente al tip de tecnlgía que sprta el DW, ya sea ROLAP, MOLAP u HOLAP. N tiene limitacines cn respect al númer máxim de dimensines permitidas. Permite a l@s usuari@s, analizar la infrmación basándse en más criteris que un análisis de frma tradicinal. Al cntar cn muestras grandes, se pueden explrar mejr ls dats en busca de respuestas. Permiten realizar agregacines y cmbinacines de ls dats de maneras cmplejas y específicas, cn el fin de realizar análisis más estratégics Dashbards Ls Dashbards se pueden entender cm una clección de reprtes, cnsultas y análisis interactivs que hacen referencia a un tema en particular y que están relacinads entre sí. Existen diversas maneras de diseñar un Dashbard, cada una de las cuales tiene sus bjetivs particulares, per a md de síntesis se expndrán algunas características generales que suelen pseer: Presentan la infrmación altamente resumida. Se cmpnen de cnsultas, reprtes, análisis interactivs, gráfics (de trta, barras, etc), semáfrs, indicadres causa-efect, etc. Permiten evaluar la situación de la empresa cn un sl glpe de vista. Pseen un frmat de diseñ visual muy llamativ Data Mining Esta herramienta cnstituye una pdersa tecnlgía cn un gran ptencial que ayuda y brinda sprte a l@s usuari@s, cn el fin de permitirles analizar y extraer cncimients cults y predecibles a partir de ls dats almacenads en un DW en un OLTP. Clar que es deseable que la fuente de infrmación sea un DW, pr tdas las ventajas que aprta.

70 La integración cn el depósit de dats facilita que las decisines peracinales sean implementadas directamente y mnitrizadas. Implementar Data Mining permitirá analizar factres de influencia en determinads prcess, predecir estimar variables cmprtamients futurs, segmentar agrupar ítems similares, además de btener secuencias de events que prvcan cmprtamients específics. Una de las principales ventajas del Data Mining es que, cm recién se ha hech mención, permite inferir cmprtamients, mdels, relacines y estimacines de ls dats, para pder desarrllar prediccines sbre ls misms, sin la necesidad de cntar cn patrnes reglas preestablecidas, permitiend tmar decisines practivas y basadas en un cncimient acabad de la infrmación. Además brinda la psibilidad de dar respuesta a preguntas cmplicadas sbre ls temas de interés, cm pr ejempl Qué está pasand?, Pr qué? y Qué pasaría sí?, ests cuestinamients aplicads a una empresa pdrían ser: Cuál de ls prducts de tal marca y clase serán más vendids en la zna nrte en el próxim semestre? y pr qué? Además se pdrán ver ls resultads en frma de reprtes tabulares, matriciales, gráfics, tablers, etc. Entnces, se puede definir Data Mining cm una técnica para descubrir patrnes y relacines entre abundantes cantidades de dats, que a simple vista que mediante trs tips de análisis n se pueden deducir, ya que tradicinalmente cnsumiría demasiad tiemp estaría fuera de las expectativas. Ls sistemas Data Mining se desarrllan baj lenguajes de última generación basads en Inteligencia Artificial y utilizan métds matemátics tales cm: Redes Neurnales. Sistemas Experts. Prgramación Genética. Árbles de Decisión. Sprta además, sfisticadas peracines de análisis cm ls sistemas Scring, aplicacines de Detección de Desviación y Detección de Fraude. Es muy imprtante tener en cuenta que en las herramientas OLAP y en ls reprtes y cnsultas, el análisis parte de una pregunta hipótesis generada pr l@s usuari@s, en cambi Data Mining permite generar estas hipótesis. Generalmente las herramientas de Data Mining se integran cn platafrmas de hardware y sftware existentes (cm DW) para incrementar el valr de las fuentes de dats establecidas y para que puedan ser integradas cn nuevs prducts y sistemas en línea (cm OLAP). En adición a est, hacer minería de dats sbre un depósit de dats permite entre tras ventajas cntar cn ls beneficis de ls prcess ETL y de las técnicas de limpieza de dats, tan necesaris en este tip de análisis.

71 Redes Neurnales Se utilizan para cnstruir mdels predictivs n lineales que aprenden a través de entrenamient y que semejan la estructura de una red neurnal bilógica. Una red neurnal es un mdel cmputacinal cn un cnjunt de prpiedades específicas, cm la habilidad de adaptarse aprender, generalizar u rganizar la infrmación, td ell basad en un prcesamient eminentemente paralel. Pr ejempl, las redes neurnales pueden emplearse para: Reslver prblemas en dminis cmplejs cn variables cntinuas y categóricas. Mdelizar relacines n lineales. Clasificar y predecir resultads Sistemas Experts Un sistema expert, puede definirse cm un sistema infrmátic (hardware y sftware) que simula a l@s expert@s human@s en un área de especialización dada. La principal ventaja de ests sistemas es que l@s usuari@s cn pca experiencia pueden reslver prblemas que requieren el cncimient de una persna experta en el tema. Pr ejempl, ls sistemas experts pueden utilizarse para: Realizar transaccines bancarias a través de cajers autmátics. Cntrlar y regular el fluj de tráfic en las calles y en ls ferrcarriles, mediante la peración autmática de semáfrs. Reslver cmplicads prblemas de planificación en ls cuales intervienen muchas variables. Descubrir relacines entre diverss cnjunts de variables Prgramación Genética El principal bjetiv de la prgramación genética es lgrar que las cmputadras aprendan a reslver prblemas sin ser explícitamente prgramadas para slucinarls, generand de esta manera slucines a partir de la inducción de ls prgramas. El verdader valr de esta inducción está fundamentad en que tds ls prblemas se pueden expresar cm un prgrama de cmputadra. Pr ejempl, la prgramación genética se utiliza para: Reslver prblemas, para ls cuales es difícil y n natural tratar de especificar restringir cn anticipación el tamañ y frma de una slución eventual. Analizar sistemas que actúan sbre cndicines inestables en ambientes cambiantes. Generar de manera autmática prgramas que slucinen prblemas planteads.

72 Árbles de Decisión Sn estructuras de frma de árbl que representan cnjunts de decisines. Estas decisines generan reglas para la clasificación de un cnjunt de dats, las cuales explican el cmprtamient de una variable cn relación a tras, y pueden traducirse fácilmente en reglas de negci. Sn utilizads cn finalidad predictiva y de clasificación. Pr ejempl, ls árbles de decisión pueden emplearse para: Optimizar respuestas de campañas. Identificar clientes ptenciales. Realizar evaluación de riesgs Detección de Desviación Analiza una serie de dats similares, y cuand encuentra un element que n cincide cn el rest l cnsidera una desviación. Usualmente para la detección de la desviación en base de dats grandes se utiliza la infrmación explícita externa a ls dats, así cm las limitacines de integridad mdels predefinids. En un métd lineal, al cntrari, se enfca el prblema desde el interir de ls dats, empleand la redundancia implícita de ls misms. Pr ejempl, la detección de desviación puede utilizarse para: Descubrir excepcines a mdels establecids. Delimitar grups que cumplan cn cndicines preestablecidas EIS EIS (Executive Infrmatin System) prprcina medis sencills para cnsultar, analizar y acceder a la infrmación de estad del negci. Además, pne a dispsición facilidades para que l@s usuari@s puedan cnseguir ls dats buscads rápidamente, empleand el menr tiemp psible para cmprender el us de la herramienta. Usualmente, EIS se utiliza para analizar ls indicadres de perfrmance y desempeñ del negci área de interés, a través de la presentación de vistas cn dats simplificads, altamente cnslidads, mayrmente estátics y preferentemente gráfics. El cncept principal de esta herramienta, se basa en el simple hech de que l@s ejecutiv@s n pseen tiemp, ni las habilidades necesarias para analizar grandes cantidades de dats. Al igual que OLAP y Data Mining, ls EIS, se pueden aplicar independientemente de la platafrma DW. Per tener cm base un depósit de dats para implementar esta herramienta, cnlleva tdas las ventajas implícitas del mism.

73 3.7 Figura 3.61: que psee el DW sn que se encargan de tmar decisines y de planificar las actividades del negci, es pr ell que se hace tant énfasis en la integración, limpieza de dats, etc, para pder cnseguir que la infrmación psea tda la calidad psible. Es a través de las herramientas de cnsulta y análisis, que l@s usuari@s explran ls dats en busca de respuestas para pder tmar decisines practivas. Para cmprender mejr a l@s usuari@s del almacén de dats, se hará referencia a las diferencias que ests tienen cn respect a ls del OLTP: L@s usuari@s que acceden al DW cncurrentemente sn pc@s, en cambi ls que acceden a ls OLTP en un tiemp determinad sn much@s más, pueden ser cients inclus miles. Est se debe principalmente al tip de infrmación que cntiene cada fuente. L@s usuari@s del DW generan pr l general cnsultas cmplejas, n predecibles y n anticipadas. Usualmente, cuand se encuentra una respuesta a una cnsulta se frmulan nuevas preguntas más detalladas y así sucesivamente. Es decir, primer se analiza la infrmación a nivel de dats actual para averiguar el qué, lueg, para btener mayr detalle y examinar el cóm, se trabajan cn ls dats ligeramente resumids, derivads de la cnsulta anterir, y desde allí se puede explrar ls dats altamente resumids. Teniend en cuenta siempre la psibilidad de utilizar el detalle de dats históric. Al cntrari, l@s usuari@s de ls OLTP sl manejan cnsultas predefinidas. L@s usuari@s del DW, generan cnsultas sbre una gran cantidad de registrs, en cambi ls del OLTP l hacen sbre un pequeñ grup. Est se debe a que cm ya se ha mencinad, el depósit cntiene infrmación histórica e integra varias fuentes de dats. Las cnsultas de l@s usuari@s del DW n tienen tiemps de respuesta crítics, aunque sí se espera que se prduzcan en el mism día en que fuern realizadas. Mientras mayr sea el tamañ del depósit y mientras más cmpleja sea la cnsulta, mayres serán ls tiemps

74 de respuestas. En cambi, las respuestas de las cnsultas en un OLTP sn y deben ser inmediatas. En ls OLTP, l@s usuari@s típicamente realizan actualizacines, tales cm agregar, mdificar, eliminar y cnsultar algún registr. En cambi en un DW, la única peración que pueden realizar es la de cnsulta. Las mencinadas diferencias entre ests ds tips de usuari@s se pueden apreciar mejr en la siguiente tabla cmparativa: Acces cncurrente Usuari@s de OLTP Much@s. Usuari@s de Data Warehuse Pc@s. Tip de cnsultas Predefinidas. Cmplejas, n predecibles y n anticipadas. Registrs cnsultads Pcs. Muchs Tiemp de respuesta Crític. N crític. Accines permitidas Agregar, mdificar, eliminar y cnsultar. Cnsultar. Figura 3.62: Usuari@s de OLTP vs Usuari@s de DW.

75 4. Cncepts Cmplementaris 4.1 Sistema de Misión Crítica siempre pseen una cierta resistencia al cambi cada vez que se les presenta una nueva herramienta sftware, es pr ell que al principi n td@s cnfiarán en el DW, y pr ende n l utilizarán. Per a medida que pasa el tiemp y l@s usuari@s pueden cmprbar pr sí mism@s su buen funcinamient, se adapten, aprendan a usarl y disuelvan sus dudas e incertidumbres, tant el númer de usuari@s cm su utilización se incrementará de manera significativa. Además, a medida que las empresas cnfían y emplean más el almacén de dats, y están más pendientes de la dispnibilidad de infrmación que él cntiene, cm así también en su acces, este se trna fundamental para la misión del negci área que apya, cnvirtiéndse paulatinamente en un Sistema de Misión Crítica. Llegand al punt en que, un errr en el mism puede prvcar una falla en las actividades del negci. En resumen, cnfrme la empresa cmienza a utilizar cada vez más ls dats del DW, y desde lueg se fían de su buen funcinamient y desempeñ para prducir de frma sencilla, rápidas cnsultas, l@s usuari@s cmenzarán a dejar para últim mment la generación de la infrmación necesaria. Pr este mtiv, es de suma imprtancia que el DW psea una buena perfrmance, seguridad y cnsistencia, y que tdas las aplicacines herramientas que l manipulen estén a dispsición en td mment. Teniend tda esta infrmación presente, se puede afirmar que es prácticamente impsible cnstruir un DW perfect en una primera instancia, es más, tratar de alcanzar este bjetiv terminaría pr ralentizar ls prcess sin cnseguir tal fin. De este md, la maduración del DW se cnseguirá paulatinamente cn cada nueva iteración requerimient. 4.2 Data Mart En adición al DW principal pueden existir varis Data Mart (DM) departamentales. Un DM es la implementación de un DW cn alcance restringid a un área funcinal, prblema en particular, departament, tema grup de necesidades. Muchs depósits de dats cmienzan siend Data Mart, para, entre trs mtivs, minimizar riesgs y prducir una primera entrega en tiemps raznables. Per, una vez que ests se han implementad exitsamente, su ámbit se irá ampliand paulatinamente. De acuerd a las peracines que se deseen requieran desarrllar, ls DM pueden adptar las siguientes arquitecturas: Tp-Dwn: primer se define el DW y lueg se desarrllan, cnstruyen y cargan ls DM a partir del mism. En la siguiente figura se encuentra detallada esta arquitectura:

76 Figura 4.1: Tp-Dwn. Cm se puede apreciar, el DW es cargad a través de prcess ETL y lueg este alimenta a ls diferentes DM, cada un de ls cuales recibirá ls dats que crrespndan al tema departament que traten. Esta frma de implementación cuenta cn la ventaja de n tener que incurrir en cmplicadas sincrnizacines de hechs, per requiere una gran inversión y una gran cantidad de tiemp de cnstrucción. Bttm-Up: en esta arquitectura, se definen previamente ls DM y lueg se integran en un DW centralizad. La siguiente figura presenta esta implementación: Figura 4.2: Bttm-Up Ls DM se cargan a través de prcess ETL, ls cuales suministrarán la infrmación adecuada a cada un de ells. En muchas casines, ls DM sn implementads sin que exista el DW, ya que tienen sus mismas características per cn la particularidad de que están enfcads en un tema específic. Lueg de que hayan sid creads y cargads tds ls DM, se prcederá a su integración cn el depósit. La ventaja que trae aparejada este mdel es que cada DM se crea y pne en funcinamient en un crt laps de tiemp y se puede tener una pequeña slución a un cst n

77 tan elevad. Lueg que tds ls DM estén puests en marcha, se puede decidir si cnstruir el DW n. El mayr incnveniente está dad en tener que sincrnizar ls hechs al mment de la cnslidación en el depósit. Dentr de las ventajas de aplicar un Data Mart a un negci, se han seleccinad las siguientes: Sn simples de implementar. Cnllevan pc tiemp de cnstrucción y puesta en marcha. Permiten manejar infrmación cnfidencial. Reflejan rápidamente sus beneficis y cualidades. Reducen la demanda del depósit de dats. 4.3 SGBD Ls SGBD (Sistema de Gestión de Base de Dats) sn un tip de sftware muy específic, dedicads a servir de interfaz entre la base de dats, l@s usuari@s y las aplicacines que l utilizan. Se cmpne de lenguajes de definición, manipulación, cnsulta y seguridad de dats. El prpósit general de ls SGBD es el de manejar de manera clara, sencilla y rdenada un cnjunt de dats. Existen diferentes bjetivs que deben cumplir ls SGBD, de ls cuales se han enumerad ls siguientes: Hacer transparente a l@s usuari@s ls detalles del almacenamient físic de ls dats, mediante varis niveles de abstracción de la infrmación. Permitir la realización de cambis a la estructura de la base de dats, sin tener que mdificar la aplicación que la emplea. Prveer a l@s usuari@s la seguridad de que sus dats n pdrán ser accedids, ni manipulads pr quien n tenga permis para ell. Debid a est, debe pseer un cmplej sistema que maneje grups, usuari@s y permiss para las diferentes actividades que se pueden realizar dentr del mism. Mantener la integridad de ls dats. Prprcinar una manera eficiente de realizar cpias de seguridad de la infrmación almacenada en ells, y permitir a partir de estas cpias restaurar ls dats. Cntrlar el acces cncurrente de l@s usuari@s. Facilitar el manej de grandes vlúmenes de infrmación. Existen ds tips de SGBD:

78 1. SGBD Multidimensinales: ests aprtan mucha perfrmance al DW en cuant a la velcidad de respuesta, ya que ls dats sn almacenads en frma multidimensinal, sin embarg sn difíciles de gestinar y de mantener. 2. SGBD Relacinales: ests sn cada vez más ptentes y pseen una interfaz gráfica más avanzada. 4.4 Particinamient En un DW, el particinamient se utiliza mayrmente para dividir una tabla de hechs, en varias tablas más pequeñas, a través de un criteri preestablecid. Usualmente, existen ds raznes principales, pr las cuales se emplea esta práctica: Psibilitar un fácil y ptimizad mantenimient del DW y de sus crrespndientes ETL. Aumentar la perfrmance de las cnsultas. Las particines mejran ls resultads de las cnsultas, ya que reducen al mínim el númer de registrs de una tabla que deben leerse para satisfacer las cnsultas. Mediante la distribución de ls dats en varias tablas, las particines mejran la velcidad y la eficacia de las cnsultas al almacén. El tiemp es el criteri más cmúnmente utilizad para realizar particines, ya que de esta manera se limita el crecimient de las tablas y se aumenta la estabilidad. Las particines pueden ser lógicas, físicas, hrizntales verticales. 4.5 Business Mdels Un Business Mdel es un representación de ls dats desde una perspectiva empresarial, que permite que se pueda visualizar la infrmación del negci y su respectiva interrelación. Se cmpne de entidades, atributs y relacines, que están enfcads en dar respuesta a las preguntas de la infrmación que se desea cncer. El Business Mdel permite definir en cmprtamient que tendrá cada miembr dentr de este, cm pr ejempl indicar cuáles camps serán utilizads para realizar sumarizacines y cuál será el criteri emplead a tal fin y cuáles serán ls camps que se utilizarán para analizar la infrmación. Per l más imprtante de este tip de estructura de dats, es que el mism se define a través de reglas de negci y teniend en cuenta las áreas temáticas que sn de interés en la empresa. A cntinuación se listarán algunas de sus características más sbresalientes: Es cmpletamente independiente de las estructuras rganizacinales. Plantea la infrmación de la empresa cm si fuesen piezas que encajan entre sí.

79 4.6. Áreas de Dats Dentr del diseñ de la arquitectura de un sistema de Data Warehuse es cnveniente tener en cnsideración ls diferentes entrns pr ls que han de pasar ls dats en su camin hacia el DW hacia ls Data marts de destin. Dada la cantidad de transfrmacines que se han de realizar, y que nrmalmente el DW, además de cumplir su función de sprte a ls requerimients analítics, realiza una función de integración de dats que van a cnfrmar el Almacén Crprativ y que van a tener que ser cnsultads también de la manera tradicinal pr ls sistemas peracinales, es muy recmendable crear diferentes áreas de dats en el camin entre ls sistemas rigen y las herramientas OLAP. Cada una de estas áreas se distingue pr las funcines que realiza, de qué manera se rganizan ls dats en la misma, y a qué tip de necesidad puede dar servici. El área que se encuentra 'al final del camin' es imprtante, per n va a ser la única que almacene ls dats que van a expltar las herramientas de reprting. Tampc hay una cnvención estandar sbre l que abarca exactamente cada área, y la bligatriedad de utilizar cada una de ellas. Cada pryect es diferente, e influyen muchs factres cm la cmplejidad, el vlumen de infrmación del mism, si realmente se quiere utilizar el Data Warehuse cm almacén crprativ Sistema Maestr de Dats, si existen necesidades reales de sprte al reprting peracinal. En ls siguientes punts se explican las áreas de dats que suelen utilizarse, y se perfila una prpuesta de arquitectura que hay que adaptar a las necesidades de cada pryect, y teniend en cuenta que la utilización de cada área de dats ha de estar justificada. N siempre tdas sn necesarias. Figura 4.6: Áreas de dats del sistema Staging Area Es un área tempral dnde se recgen ls dats que se necesitan de ls sistemas rigen. Se recgen ls dats estrictamente necesaris para las cargas, y se aplica el mínim de transfrmacines a ls

80 misms. N se aplican restriccines de integridad ni se utilizan claves, ls dats se tratan cm si las tablas fueran fichers plans. De esta manera se minimiza la afectación a ls sistemas rigen, la carga es l más rápida psible para actar la ventana hraria necesaria, y se reduce también al mínim la psibilidad de errr. Una vez que ls dats han sid traspasads, el DW se independiza de ls sistemas rigen hasta la siguiente carga. L únic que se suele añadir es algún camp que almacene la fecha de la carga. Obviamente ests dats n van a dar servici a ninguna aplicación de reprting, sn dats temprales que una vez hayan cumplid su función sn eliminads, de hech en el esquema lógic de la arquitectura muchas veces n aparece, ya que su función es meramente perativa. Alguns autres cnsideran que la Staging Area abarca más de l cmentad, inclus que englba td el entrn dnde se realizan ls prcess de ETL, en este dcument se cnsidera sól cm área tempral Operatinal Data Stre (ODS) Cm su nmbre indica, esta área es la que da sprte a ls sistemas peracinales. El mdel de dats del Almacén de Dats Operacinal sigue una estructura relacinal y nrmalizada, para que cualquier herramienta de reprting sistema peracinal pueda cnsultar sus dats. Está dentr del Data Warehuse prque se aprvecha el esfuerz de integración que supne la creación del Almacén de Dats Crprativ para pder atender también a necesidades peracinales, per n es bligatri. Ni siquiera es alg específic del BI, ls ODS ya existían antes de que surgieran ls cncepts de Data Warehusing y Business Intelligence. N almacena dats histórics, muestra la imagen del mment actual, aunque es n significa que n se puedan registrar ls cambis. Ls dats del ODS se recgen de la Staging Area, y en este prces sí que se realizan transfrmacines, limpieza de dats y cntrles de integridad referencial para que ls dats estén perfectamente integrads en el mdel relacinal nrmalizad. Se debe tener en cuenta que la actualización de ls dats del ODS n es instantánea, ls cambis en ls dats de ls sistemas rigen n se ven reflejads hasta que finaliza la carga crrespndiente. Es decir, que ls dats se refrescan cada ciert tiemp, csa que hay que explicar al usuari final, prque ls infrmes que se lancen cntra el ODS siempre devlverán infrmación a fecha de la última carga. Pr esta razón es recmendable definir una mayr frecuencia de carga para el ODS que para el Almacén Crprativ. Se puede refrescar el ODS cada 15 minuts, y el rest cada día, pr ejempl Almacén de Dats Crprativ (DW) El Almacén de Dats Crprativ sí que cntiene dats histórics, y está rientad a la expltación analítica de la infrmación que recge. Las herramientas DSS de reprting analític cnsultan

81 tant ls Data marts cm el Almacén de Dats Crprativ. El DW puede servir cnsultas en las que se precisa mstrar a la vez infrmación que se encuentre en diferentes Datamarts. En él se almacenan dats que pueden prvenir tant de la Staging Area cm del ODS. Si ya se realizan prcess de transfrmación e integración en el ODS n se repiten para pasar ls misms dats al Almacén Crprativ. L que n se pueda recger desde el ODS sí que hay que ir a buscarl a la Staging Area. El esquema se parece al de un mdel relacinal nrmalizad, per en él ya se aplican técnicas de desnrmalización. N debería cntener un númer excesiv de tablas ni de relacines ya que, pr ejempl, muchas relacines jerárquicas que en un mdel nrmalizad se implementarían cn tablas separadas aquí ya deberían crearse en una misma tabla, que después representará una dimensión. Otra particularidad es que la mayría de las tablas han de incrprar camps de fecha para cntrlar la fecha de carga, la fecha en que se prduce un hech, el perid de validez del registr. Si el Data Warehuse n es demasiad grande, el nivel de exigencia n es muy elevad en cuant a ls requerimients 'peracinales', para simplificar la estructura se puede ptar pr prescindir del ODS, y si es necesari adecuar el Almacén de Dats Crprativ para servir tant al reprting peracinal cm al analític. En este cas, el área resultante sería el DW Crprativ, per en casines también se denmina cm ODS Data Mart (DM) Otr área de dats es el lugar dnde se crean ls Data marts. Ésts acstumbran a btenerse a partir de la infrmación recpilada en el área del Almacén Crprativ, aunque también puede ser a la inversa. Cada Data Mart es cm un subcnjunt de este almacén, per rientad a un tema de análisis, nrmalmente asciad a un departament de la empresa. El Data Mart se diseña cn estructura multidimensinal, cada bjet de análisis es una tabla de hechs enlazada cn diversas tablas de dimensines. Si se diseña siguiend el Mdel en Estrella habrá prácticamente una tabla para cada dimensión, es la versión más desnrmalizada. Si se sigue un mdel de Cp de Nieve las tablas de dimensines estarán mens desnrmalizadas y para cada dimensión se pdrán utilizar varias tablas enlazadas jerárquicamente. Este área puede residir en la misma base de dats que las demás si la herramienta de expltación es de tip ROLAP, también puede crearse ya fuera de la BD, en la estructura de dats prpia que generan las aplicacines de tip MOLAP, más cncida cm ls cubs multidimensinales. Si se sigue una aprximación Tp-dwn para la creación de ls Data mart, el pas del área de DW a esta ha de ser bastante simple, csa que además prprcina una cierta independencia sbre el sftware que se utiliza para el reprting analític. Si pr cualquier razón es necesari cambiar la herramienta de OLAP hay que hacer pc más que redefinir ls metadats y regenerar ls cubs, y si el cambi es entre ds de tip ROLAP ni siquiera est últim sería necesari. En cualquier cas, las áreas anterires n tienen prqué ser mdificadas.

82 II HEFESTO: Metdlgía para la Cnstrucción de un Data Warehuse RESUMEN En esta segunda parte de la publicación, se presentará una metdlgía prpia para la cnstrucción de un Data Warehuse, que partirá de la reclección de requerimients y necesidades de infrmación de l@s usuari@s, y cncluirá en la cnfección de un esquema lógic y sus respectivs prcess de extracción, transfrmación y carga de dats. Además, se ejemplificará cada etapa de la metdlgía a través de su aplicación a una empresa real, que servirá de guía para que se puedan visualizar ls resultads que se esperan de cada pas y para clarificar ls cncepts enunciads. Primer, se describirán ls aspects más sbresalientes de la metdlgía y lueg se explicará cada pas cn su respectiva aplicación. Finalmente, se expndrán algunas cnsideracines que deben tenerse en cuenta al mment de cnstruir e implementar un Data Warehuse. El principal bjetiv es facilitar el ardu trabaj que significa cnstruir un Data Warehuse desde cer, aprtand infrmación que permitirá aumentar la perfrmance del mism. En adición a ell, esta metdlgía estará rientada a evitar el tedi que prvca el tener que seguir pass sin terminar de cmprender el pr qué de ls misms. Adicinal a td est, se ejemplificará la creación de cubs multidimensinales basads en el DW resultante del cas práctic. 5. Metdlgía Hefest 5.1 Intrducción a la Metdlgía HEFESTO En esta sección se presentará la metdlgía HEFESTO, que permitirá la cnstrucción de Data Warehuse de frma sencilla, rdenada e intuitiva. Su nmbre fue inspirad en el dis grieg de la cnstrucción y el fueg, y su lgtip es el siguiente: Figura 5.1: Metdlgía HEFESTO, lgtip.

83 Figura 5.2: Metdlgía HEFESTO, lgtip versión 2.0. HEFESTO es una metdlgía prpia, cuya prpuesta está fundamentada en una muy amplia investigación, cmparación de metdlgías existentes, experiencias prpias en prcess de cnfección de almacenes de dats. Cabe destacar que HEFESTO está en cntinua evlución, y se han tenid en cuenta, cm gran valr agregad, tds ls feedbacks que han aprtad quienes han utilizad esta metdlgía en diverss países y cn diverss fines. La idea principal, es cmprender cada pas que se realizará, para n caer en el tedi de tener que seguir un métd al pie de la letra sin saber exactamente qué se está haciend, ni pr qué. La cnstrucción e implementación de un DW puede adaptarse muy bien a cualquier cicl de vida de desarrll de sftware, cn la salvedad de que para algunas fases en particular, las accines que se han de realizar serán muy diferentes. L que se debe tener muy en cuenta, es n entrar en la utilización de metdlgías que requieran fases extensas de reunión de requerimients y análisis, fases de desarrll mnlític que cnlleve demasiad tiemp y fases de despliegue muy largas. L que se busca, es entregar una primera implementación que satisfaga una parte de las necesidades, para demstrar las ventajas del DW y mtivar a l@s usuari@s. La metdlgía HEFESTO, puede ser embebida en cualquier cicl de vida que cumpla cn la cndición antes declarada. Cn el fin de que se llegue a una ttal cmprensión de cada pas etapa, se acmpañará cn la implementación en una empresa real, para demstrar ls resultads que se deben btener y ejemplificar cada cncept. 5.2 Descripción La metdlgía HEFESTO puede resumirse a través del siguiente gráfic:

84 Figura 5.2: Metdlgía HEFESTO, pass. Cm se puede apreciar, se cmienza reclectand las necesidades de infrmación de y se btienen las preguntas claves del negci. Lueg, se deben identificar ls indicadres resultantes de ls interrgativs y sus respectivas perspectivas de análisis, mediante las cuales se cnstruirá el mdel cnceptual de dats del DW. Después, se analizarán ls OLTP para determinar cóm se cnstruirán ls indicadres, señalar las crrespndencias cn ls dats fuentes y para seleccinar ls camps de estudi de cada perspectiva.

85 Una vez hech est, se pasará a la cnstrucción del mdel lógic del depósit, en dnde se definirá cuál será el tip de esquema que se implementará. Seguidamente, se cnfeccinarán las tablas de dimensines y las tablas de hechs, para lueg efectuar sus respectivas unines. Pr últim, utilizand técnicas de limpieza y calidad de dats, prcess ETL, etc, se definirán plíticas y estrategias para la Carga Inicial del DW y su respectiva actualización. 5.3 Características Esta metdlgía cuenta cn las siguientes características: Ls bjetivs y resultads esperads en cada fase se distinguen fácilmente y sn sencills de cmprender. Se basa en ls requerimients de l@s usuari@s, pr l cual su estructura es capaz de adaptarse cn facilidad y rapidez ante ls cambis en el negci. Reduce la resistencia al cambi, ya que invlucra a l@s usuari@s finales en cada etapa para que tme decisines respect al cmprtamient y funcines del DW. Utiliza mdels cnceptuales y lógics, ls cuales sn sencills de interpretar y analizar. Es independiente del tip de cicl de vida que se emplee para cntener la metdlgía. Es independiente de las herramientas que se utilicen para su implementación. Es independiente de las estructuras físicas que cntengan el DW y de su respectiva distribución. Cuand se culmina cn una fase, ls resultads btenids se cnvierten en el punt de partida para llevar a cab el pas siguiente. Se aplica tant para Data Warehuse cm para Data Mart. 5.4 Empresa analizada Antes de cmenzar cn el primer pas en la cnstrucción del Data Warehuse, es menester describir las características principales de la empresa a la cual se le aplicará la metdlgía HEFESTO, así se pdrá tener cm base un ámbit predefinid y se cmprenderá mejr cada decisión que se tme cn respect a la implementación y diseñ del DW. Además, este análisis ayudará a cncer el funcinamient y rganización de la empresa, l que permitirá examinar e interpretar de frma óptima las necesidades de infrmación de la misma, cm así también apyará a una mejr cnstrucción y adaptación del depósit de dats. La descripción de la empresa se encuentra en el Apéndice A.

86 5.5 Pass y aplicación metdlógica Pas 1) Análisis de Requerimients PASO 1) ANÁLISIS DE REQUERIMIENTOS a) Identificar preguntas b) Identificar indicadres y perspectivas c) Mdel Cnceptual PASO 1) ANÁLISIS DE REQUERIMIENTOS L primer que se hará será identificar ls requerimients de l@s usuari@s a través de preguntas que expliciten ls bjetivs de su rganización. Lueg, se analizarán estas preguntas a fin de identificar cuáles serán ls indicadres y perspectivas que serán tmadas en cuenta para la cnstrucción del DW. Finalmente se cnfeccinará un mdel cnceptual en dnde se pdrá visualizar el resultad btenid en este primer pas. Es muy imprtante tener en cuenta que HEFESTO se puede utilizar para cnstruir un Data Warehuse un Data Mart a la vez, es decir, si se requiere cnstruir pr ejempl ds Data Marts, se deberá aplicar la metdlgía ds veces, una pr cada Data Mart. Del mism md, si se analizan ds áreas de interés de negci, cm el área de Ventas y Cmpras, se deberá aplicar la metdlgía ds veces a) Identificar preguntas El primer pas cmienza cn el acpi de las necesidades de infrmación, el cual puede llevarse a cab a través de muy variadas y diferentes técnicas, cada una de las cuales pseen características inherentes y específicas, cm pr ejempl entrevistas, cuestinaris, bservacines, etc. El análisis de ls requerimients de l@s diferentes usuari@s, es el punt de partida de esta metdlgía, ya que ell@s sn l@s que deben, en ciert md, guiar la investigación hacia un desarrll que refleje claramente l que se espera del depósit de dats, en relación a sus funcines y cualidades. El bjetiv principal de esta fase, es la de btener e identificar las necesidades de infrmación clave de alt nivel, que es esencial para llevar a cab las metas y estrategias de la empresa, y que facilitará una eficaz y eficiente tma de decisines. Debe tenerse en cuenta que dicha infrmación, es la que prveerá el sprte para desarrllar ls pass sucesivs, pr l cual, es muy imprtante que se preste especial atención al relevar ls dats. Una frma de asegurarse de que se ha realizad un buen análisis, es crrbrar que el resultad del mism haga explícits ls bjetivs estratégics planteads pr la empresa que se está estudiand. Otra frma de encaminar el relevamient, es enfcar las necesidades de infrmación en ls prcess principales que desarrlle la empresa en cuestión.

87 La idea central es, que se frmulen preguntas cmplejas sbre el negci, que incluyan variables de análisis que se cnsideren relevantes, ya que sn estas las que permitirán estudiar la infrmación desde diferentes perspectivas. Un punt imprtante que debe tenerse muy en cuenta, es que la infrmación debe estar sprtada de alguna manera pr algún OLTP, ya que de tra frma, n se pdrá elabrar el DW. Cas práctic: Se indagó a l@s usuari@s en busca de sus necesidades de infrmación, per las mismas abarcaban casi tdas las actividades de la empresa, pr l cual se les pidió que escgieran el prces que cnsiderasen más imprtante en las actividades diarias de la misma y que estuviese sprtad de alguna manera pr algún OLTP. El prces elegid fue el de Ventas. A cntinuación, se prcedió a identificar qué era l que les interesaba cncer acerca de este prces y cuáles eran las variables perspectivas que debían tenerse en cuenta para pder tmar decisines basadas en ell. Se les preguntó cuáles eran según ell@s, ls indicadres que representan de mejr md el prces de Ventas y qué sería exactamente l que se desea analizar del mism. La respuesta btenida, fue que se deben tener en cuenta y cnsultar dats sbre la cantidad de unidades vendidas y el mnt ttal de ventas. Lueg se les preguntó cuáles serían las variables perspectivas desde las cuales se cnsultarán dichs indicadres. Para simplificar esta tarea se les presentó una serie de ejempls cncrets de trs cass similares. Las preguntas de negci btenidas fuern las siguientes: Se desea cncer cuántas unidades de cada prduct fuern vendidas a sus clientes en un perid determinad. O en tras palabras: Unidades vendidas de cada prduct a cada cliente en un tiemp determinad. Se desea cncer cuál fue el mnt ttal de ventas de prducts a cada cliente en un perid determinad. O en tras palabras: Mnt ttal de ventas de cada prduct a cada cliente en un tiemp determinad. Debid a que la dimensión Tiemp es un element fundamental en el DW, se hiz hincapié en él. Además, se pus much énfasis en dejar en clar a l@s usuari@s, a través de ejempls práctics, que es este cmpnente el que permitirá tener varias versines de ls dats a fin de realizar un crrect análisis psterir. Cm se puede apreciar, las necesidades de infrmación expuestas están acrde a ls bjetivs y estrategias de la empresa, ya que es precisamente esta infrmación requerida la que prveerá un ámbit para la tma de decisines, que en este cas permitirá analizar el cmprtamient de l@s client@s a l@s que se pretende satisfacer ampliamente, para así lgrar btener una ventaja cmpetitiva y maximizar las ganancias.

88 b) Identificar indicadres y perspectivas Una vez que se han establecid las preguntas de negci, se debe prceder a su descmpsición para descubrir ls indicadres que se utilizarán y las perspectivas de análisis que intervendrán. Para ell, se debe tener en cuenta que ls indicadres, para que sean realmente efectivs sn, en general, valres numérics y representan l que se desea analizar cncretamente, pr ejempl: salds, prmedis, cantidades, sumatrias, fórmulas, etc. En cambi, las perspectivas se refieren a ls bjets mediante ls cuales se quiere examinar ls indicadres, cn el fin de respnder a las preguntas planteadas, pr ejempl: clientes, prveedres, sucursales, países, prducts, rubrs, etc. Cabe destacar, que el Tiemp es muy cmúnmente una perspectiva. Cas práctic: A cntinuación, se analizarán las preguntas btenidas en el pas anterir y se detallarán cuáles sn sus respectivs indicadres y perspectivas. Figura 5.3: Cas práctic, indicadres y perspectivas. En síntesis, ls indicadres sn: Unidades vendidas. Mnt ttal de ventas. Y las perspectivas de análisis sn: Clientes. Prducts. Tiemp c) Mdel Cnceptual

89 En esta etapa, se cnstruirá un mdel cnceptual a partir de ls indicadres y perspectivas btenidas en el pas anterir. Mdel Cnceptual: descripción de alt nivel de la estructura de la base de dats, en la cual la infrmación es representada a través de bjets, relacines y atributs. A través de este mdel, se pdrá bservar cn claridad cuáles sn ls alcances del pryect, para lueg pder trabajar sbre ells, además al pseer un alt nivel de definición de ls dats, permite que pueda ser presentad ante l@s usuari@s y explicad cn facilidad. La representación gráfica del mdel cnceptual es la siguiente: Figura 5.4: Mdel Cnceptual. A la izquierda se clcan las perspectivas seleccinadas, que serán unidas a un óval central que representa y lleva el nmbre de la relación que existe entre ellas. La relación, cnstituye el prces área de estudi elegida. De dicha relación y entrelazadas cn flechas, se desprenden ls indicadres, ests se ubican a la derecha del esquema. Cm puede apreciarse en la figura anterir, el mdel cnceptual permite de un sl vistaz y sin pseer demasiads cncimients previs, cmprender cuáles serán ls resultads que se btendrán, cuáles serán las variables que se utilizarán para analizarls y cuál es la relación que existe entre ells. Cas práctic: El mdel cnceptual resultante de ls dats que se han reclectad, es el siguiente:

90 Figura 5.5: Cas práctic, Mdel Cnceptual. Cm puede bservarse, la relación mediante la cuál se unen las diferentes perspectivas, para btener cm resultad ls indicadres requerids pr es precisamente Venta Pas 2) Análisis de ls OLPT PASO 2) ANÁLISIS DE LOS OLTP a) Cnfrmar Indicadres b) Establecer crrespndencias c) Nivel de granularidad d) Mdel Cnceptual ampliad PASO 2) ANÁLISIS DE LOS OLTP Seguidamente, se analizarán las fuentes OLTP para determinar cóm serán calculads ls indicadres y para establecer las respectivas crrespndencias entre el mdel cnceptual cread en el pas anterir y las fuentes de dats. Lueg, se definirán qué camps se incluirán en cada perspectiva. Finalmente, se ampliará el mdel cnceptual cn la infrmación btenida en este pas a) Cnfrmar Indicadres En este pas se deberán explicitar cm se calcularán ls indicadres, definiend ls siguientes cncepts para cada un de ells: Hech/s que l cmpnen, cn su respectiva fórmula de cálcul. Pr ejempl: Hech1 + Hech2. Función de sumarización que se utilizará para su agregación. Pr ejempl: SUM, AVG, COUNT, etc.

91 Cas práctic: Ls indicadres se calcularán de la siguiente manera: Unidades Vendidas : Hechs: Unidades Vendidas. Función de sumarización: SUM. Aclaración: el indicadr Unidades Vendidas representa la sumatria de las unidades que se han vendid de un prduct en particular. Mnt Ttal de Ventas : Hechs: (Unidades Vendidas) * (Preci de Venta). Función de sumarización: SUM. Aclaración: el indicadr Mnt Ttal de Ventas representa la sumatria del mnt ttal que se ha vendid de cada prduct, y se btiene al multiplicar las unidades vendidas, pr su respectiv preci b) Establecer crrespndencias El bjetiv de este pas, es el de examinar ls OLTP dispnibles que cntengan la infrmación requerida, cm así también sus características, para pder identificar las crrespndencias entre el mdel cnceptual y las fuentes de dats. La idea es, que tds ls elements del mdel cnceptual estén crrespndids en ls OLTP. Cas práctic: En el OLTP de la empresa analizada, el prces de venta está representad pr el diagrama de entidad relación de la siguiente figura. Diagrama de Entidad Relación: representa la infrmación a través de entidades, relacines, cardinalidades, claves, atributs y jerarquías de generalización.

92 Figura 5.6: Cas práctic, Diagrama de Entidad Relación. A cntinuación, se expndrá la crrespndencia entre ls ds mdels: Figura 5.7: Cas práctic, crrespndencia.

93 Las relacines identificadas fuern las siguientes: La tabla Prducts se relacina cn la perspectiva Prducts. La tabla Clientes cn la perspectiva Clientes. El camp fecha de la tabla Facturas_Venta cn la perspectiva Tiemp (debid a que es la fecha principal en el prces de venta). El camp cantidad de la tabla Detalles_Venta cn el indicadr Unidades Vendidas. El camp cantidad de la tabla Detalles_Venta multiplicad pr el camp preci_fact de la misma tabla, cn el indicadr Mnt Ttal de Ventas c) Nivel de granularidad Una vez que se han establecid las relacines cn ls OLTP, se deben seleccinar ls camps que cntendrá cada perspectiva, ya que será a través de ests pr ls que se examinarán y filtrarán ls indicadres. Para ell, basándse en las crrespndencias establecidas en el pas anterir, se debe presentar a l@s usuari@s ls dats de análisis dispnibles para cada perspectiva. Es muy imprtante cncer en detalle que significa cada camp y/ valr de ls dats encntrads en ls OLTP, pr l cual, es cnveniente investigar su sentid, ya sea a través de diccinaris de dats, reunines cn l@s encargad@s del sistema, análisis de ls dats prpiamente dichs, etc. Lueg de expner frente a l@s usuari@s ls dats existentes, explicand su significad, valres psibles y características, est@s deben decidir cuales sn ls que cnsideran relevantes para cnsultar ls indicadres y cuales n. Cn respect a la perspectiva Tiemp, es muy imprtante definir el ámbit mediante el cual se agruparán sumarizarán ls dats. Sus camps psibles pueden ser: día de la semana, quincena, mes, trimestres, semestre, añ, etc. Al mment de seleccinar ls camps que integrarán cada perspectiva, debe prestarse mucha atención, ya que esta acción determinará la granularidad de la infrmación encntrada en el DW. Cas práctic: De acuerd a las crrespndencias establecidas, se analizarn ls camps residentes en cada tabla a la que se hacia referencia, a través de ds métds diferentes. Primer se examinó la base de dats para intuir ls significads de cada camp, y lueg se cnsultó cn el encargad del sistema sbre alguns aspects de ls cuales n se cmprendía su sentid.

94 De tdas frmas, y cm puede apreciarse en el diagrama de entidad relación antes expuest, ls nmbres de ls camps sn bastante explícits y se deducen cn facilidad, per aún así fue necesari investigarls para evitar cualquier tip de incnvenientes. Cn respect a la perspectiva Clientes, ls dats dispnibles sn ls siguientes: id_cliente: es la clave primaria de la tabla Clientes, y representa unívcamente a un cliente en particular. Cdig: representa el códig del cliente, este camp es calculad de acuerd a una cmbinación de las iniciales del nmbre del cliente, el grup al que pertenece y un númer incremental. Razn_Sc: nmbre razón scial del cliente. Telefn1: númer de teléfn del cliente. Telefn2: segund númer telefónic del cliente. Fax1: númer de fax del cliente. Fax2: segund númer de fax del cliente. Mail1: dirección de crre electrónic del cliente. Mail2: segunda dirección de crre del cliente. id_sit_fiscal: representa a través de una clave fránea el tip de situación fiscal que psee el cliente. Pr ejempl: Cnsumidr Final, Exent, Respnsable N Inscript, Respnsable Inscript. CUIT: númer de C.U.I.T. del cliente. CnveniMultilateral: indica si el cliente psee n cnveni multilateral. DGR: númer de D.G.R. del cliente. id_clasificación: representa a través de una clave fránea la clasificación del cliente. Pr ejempl: Muy Buen, Buen, Regular, Mal, Muy Mal. id_nta: representa a través de una clave fránea una bservación realizada acerca del cliente. Cta_Habilitada: indica si el cliente psee su cuenta habilitada. id_rubr: representa a través de una clave fránea el grup al que pertenece el cliente. Pr ejempl: Bancs, Cnstrucción, Educación Privada, Educación Pública, Particulares. idcuentacntable: representa la cuenta cntable asciada al cliente, la cual se utilizará para imputar ls mvimients cntables que este genere.

95 Eliminad: indica si el cliente fue eliminad n. Si fue eliminad, n figura en las listas de clientes actuales. En la perspectiva Prducts, ls dats que se pueden utilizar sn ls siguientes: id_prd: es la clave primaria de la tabla Prducts, y representa unívcamente a un prduct en particular. stck: stck actual del prduct. stck_min: stck mínim del prduct, se utiliza para dar alerta si el stck actual está cerca del mism, al ras si ya l superó. Preci: preci de venta del prduct. Detalle: nmbre descripción del prduct. id_rubr: representa a través de una clave fránea el rubr al que pertenece el prduct. id_marca: representa a través de una clave fránea la marca a la que pertenece el prduct. stck_max: stck máxim del prduct. Al igual que stck_min, se utiliza para dar alertas del nivel de stck actual. tip: clasificación del prduct. Pr ejempl: Prduct, Servici, Cmpuest. Cst: preci de cst del prduct. cdig: representa el códig del prduct, este camp es calculad de acuerd a una cmbinación de las iniciales del nmbre del prduct, el rubr al que pertenece y un númer incremental. Imagen: ruta de acces a una imagen dibuj mediante la cual se quiera representar al prduct. Este camp n es utilizad actualmente. Generic: indica si el prduct es genéric n. Eliminad: indica si el prduct fue eliminad n. Si fue eliminad, n figura en las listas de prducts actuales. PreciR: preci de lista del prduct. Cn respect a la perspectiva Tiemp, que es la que determinará la granularidad del depósit de dats, ls dats más típics que pueden emplearse sn ls siguientes: Añ. Semestre.

96 Cuatrimestre. Trimestre. Númer de mes. Nmbre del mes. Quincena. Semana. Númer de día. Nmbre del día. Una vez que se reclectó tda la infrmación pertinente y se cnsultó cn l@s usuari@s cuales eran ls dats que cnsideraban de interés para analizar ls indicadres ya expuests, ls resultads btenids fuern ls siguientes: Perspectiva Clientes : Razn_Sc de la tabla Clientes. Ya que este hace referencia al nmbre del cliente. Perspectiva Prducts : detalle de la tabla Prducts. Ya que este hace referencia al nmbre del prduct. Nmbre de la tabla Marcas. Ya que esta hace referencia a la marca a la que pertenece el prduct. Este camp es btenid a través de la unión cn la tabla Prducts Perspectiva Tiemp : Mes. Referid al nmbre del mes. Trimestre. Añ d) Mdel Cnceptual ampliad En este pas, y cn el fin de graficar ls resultads btenids en ls pass anterires, se ampliará el mdel cnceptual, clcand baj cada perspectiva ls camps seleccinads y baj cada indicadr su respectiva fórmula de cálcul. Gráficamente:

97 Figura 5.8: Mdel Cnceptual ampliad. Cas práctic: Teniend est en cuenta, se cmpletará el diseñ del diagrama cnceptual: Figura 5.9: Cas práctic, Mdel Cnceptual ampliad Pas 3) Mdel lógic del DW PASO 3) MODELO LÓGICO DEL DW a) Tip de Mdel Lógic del DW b) Tablas de dimensines

98 c) Tablas de hechs d) Unines PASO 3) MODELO LÓGICO DEL DW A cntinuación, se cnfeccinará el mdel lógic de la estructura del DW, teniend cm base el mdel cnceptual que ya ha sid cread. Para ell, primer se definirá el tip de mdel que se utilizará y lueg se llevarán a cab las accines prpias al cas, para diseñar las tablas de dimensines y de hechs. Finalmente, se realizarán las unines pertinentes entre estas tablas. Mdel Lógic: representación de una estructura de dats, que puede prcesarse y almacenarse en algún SGBD a) Tip de Mdel Lógic del DW Se debe seleccinar cuál será el tip de esquema que se utilizará para cntener la estructura del depósit de dats, que se adapte mejr a ls requerimients y necesidades de l@s usuari@s. Es muy imprtante definir bjetivamente si se empleará un esquema en estrella, cnstelación cp de nieve, ya que esta decisión afectará cnsiderablemente la elabración del mdel lógic. Cas práctic: El esquema que se utilizará será en estrella, debid a sus características, ventajas y diferencias cn ls trs esquemas b) Tablas de dimensines En este pas se deben diseñar las tablas de dimensines que frmaran parte del DW. Para ls tres tips de esquemas, cada perspectiva definida en en mdel cnceptual cnstituirá una tabla de dimensión. Para ell deberá tmarse cada perspectiva cn sus camps relacinads y realizarse el siguiente prces: Se elegirá un nmbre que identifique la tabla de dimensión. Se añadirá un camp que represente su clave principal. Se redefinirán ls nmbres de ls camps si es que n sn l suficientemente intuitivs. Gráficamente:

99 Figura 5.10: Diseñ de tablas de dimensines. Para ls esquemas cp de nieve, cuand existan jerarquías dentr de una tabla de dimensión, esta tabla deberá ser nrmalizada. Pr ejempl, se tmará cm referencia la siguiente tabla de dimensión y su respectivas relacines padre-hij entre sus camps: Figura 5.11: Jerarquía de GEOGRAFIA. Entnces, al nrmalizar esta tabla se btendrá: Figura 5.12: Nrmalización de GEOGRAFIA. Cas práctic: A cntinuación, se diseñaran las tablas de dimensines. Perspectiva Clientes : La nueva tabla de dimensión tendrá el nmbre CLIENTE. Se le agregará una clave principal cn el nmbre idcliente. Se mdificará el nmbre del camp Razn_Sc pr Cliente.

100 Se puede apreciar el resultad de estas peracines en la siguiente gráfica: Figura 5.13: Cas práctic, tabla de dimensión CLIENTE. Perspectiva Prducts : La nueva tabla de dimensión tendrá el nmbre PRODUCTO. Se le agregará una clave principal cn el nmbre idprduct. El nmbre del camp Marca n será cambiad. Se mdificará el nmbre del camp Detalle pr Prduct. Se puede apreciar el resultad de estas peracines en la siguiente gráfica: Figura 5.14: Cas práctic, tabla de dimensión PRODUCTO. Perspectiva Tiemp : La nueva tabla de dimensión tendrá el nmbre FECHA. Se le agregará una clave principal cn el nmbre idfecha. El nmbre ls camps n serán mdificads. Se puede apreciar el resultad de estas peracines en la siguiente gráfica:

101 Figura 5.15: Cas práctic, tabla de dimensión FECHA c) Tablas de hechs En este pas, se definirán las tablas de hechs, que sn las que cntendrán ls hechs a través de ls cuales se cnstruirán ls indicadres de estudi. Para ls esquemas en estrella y cp de nieve, se realizará l siguiente: Se le deberá asignar un nmbre a la tabla de hechs que represente la infrmación analizada, área de investigación, negci enfcad, etc. Se definirá su clave primaria, que se cmpne de la cmbinación de las claves primarias de cada tabla de dimensión relacinada. Se crearán tants camps de hechs cm indicadres se hayan definid en el mdel cnceptual y se les asignará ls misms nmbres que ests. En cas que se prefiera, pdrán ser nmbrads de cualquier tr md. Gráficamente: Figura 5.16: Tabla de hechs. Para ls esquemas cnstelación se realizará l siguiente:

102 Las tablas de hechs se deben cnfeccinar teniend en cuenta el análisis de las preguntas realizadas pr en pass anterires y sus respectivs indicadres y perspectivas. Cada tabla de hechs debe pseer un nmbre que la identifique, cntener sus hechs crrespndientes y su clave debe estar frmada pr la cmbinación de las claves de las tablas de dimensines relacinadas. Al diseñar las tablas de hechs, se deberá tener en cuenta: Cas 1: Si en ds más preguntas de negci figuran ls misms indicadres per cn diferentes perspectivas de análisis, existirán tantas tablas de hechs cm preguntas cumplan esta cndición. Pr ejempl: Figura 5.17: Cas 1, preguntas. Entnces se btendrá: Figura 5.18: Cas 1, diseñ de tablas de hechs. Cas 2: Si en ds más preguntas de negci figuran diferentes indicadres cn diferentes perspectivas de análisis, existirán tantas tablas de hechs cm preguntas cumplan esta cndición. Pr ejempl: Figura 5.19: Cas 2, preguntas.

103 Entnces se btendrá: Figura 5.20: Cas 2, diseñ de tablas de hechs. Cas 3: Si el cnjunt de preguntas de negci cumplen cn las cndicines de ls ds punts anterires se deberán unificar aquells interrgantes que psean diferentes indicadres per iguales perspectivas de análisis, para lueg reanudar el estudi de las preguntas. Pr ejempl: Figura 5.21: Cas 3, preguntas. Se unificarán en: Figura 5.22: Cas 3, unificación. Cas práctic: A cntinuación, se cnfeccinará la tabla de hechs: La tabla de hechs tendrá el nmbre VENTAS. Su clave principal será la cmbinación de las claves principales de las tablas de dimensines antes definidas: idcliente, idprduct e idfecha.

104 Se crearán ds hechs, que se crrespnden cn ls ds indicadres y serán renmbrads, Unidades Vendidas pr Cantidad y Mnt Ttal de Ventas pr MntTtal. En el gráfic siguiente se puede apreciar mejr este pas: Figura 5.23: Cas práctic, diseñ de la tabla de hechs d) Unines Para ls tres tips de esquemas, se realizarán las unines crrespndientes entre sus tablas de dimensines y sus tablas de hechs. Cas práctic: Se realizarán las unines pertinentes, de acuerd crrespnda:

105 Figura 5.24: Cas práctic, unines Pas 4) Integración de Dats PASO 4) INTEGRACIÓN DE DATOS a) Carga Inicial b) Actualización PASO 4) INTEGRACIÓN DE DATOS Una vez cnstruid el mdel lógic, se deberá prceder a pblarl cn dats, utilizand técnicas de limpieza y calidad de dats, prcess ETL, etc.; lueg se definirán las reglas y plíticas para su respectiva actualización, así cm también ls prcess que la llevarán a cab a) Carga Inicial Debems en este pas realizar la Carga Inicial al DW, pbland el mdel de dats que hems cnstruid anterirmente. Para l cual debems llevar adelante una serie de tareas básicas, tales cm limpieza de dats, calidad de dats, prcess ETL, etc. La realización de estas tareas pueden cntener una lógica realmente cmpleja en alguns cass. Afrtunadamente, en la actualidad existen muchs sftwares que se pueden emplear a tal fin, y que ns facilitarán el trabaj. Se debe evitar que el DW sea cargad cn valres faltantes anómals, así cm también se deben establecer cndicines y restriccines para asegurar que sl se utilicen ls dats de interés.

106 Cuand se trabaja cn un esquema cnstelación, hay que tener presente que varias tablas de dimensines serán cmpartidas cn diferentes tablas de hechs, ya que puede darse el cas de que algunas restriccines aplicadas sbre una tabla de dimensión en particular para analizar una tabla de hechs, se puedan cntrapner cn tras restriccines cndicines de análisis de tras tablas de hechs. Primer se cargarán ls dats de las dimensines y lueg ls de las tablas de hechs, teniend en cuenta siempre, la crrecta crrespndencia entre cada element. En el cas en que se esté utilizand un esquema cp de nieve, cada vez que existan jerarquías de dimensines, se cmenzarán cargand las tablas de dimensines del nivel más general al más detallad. Cncretamente, en este pas se deberá registrar en detalle las accines llevadas a cab cn ls diferentes sftwares. Pr ejempl, es muy cmún que sistemas ETL trabajen cn "pass" y "relacines", en dnde cada "pas" realiza una tarea en particular del prces ETL y cada "relación" indica hacia dnde debe dirigirse el fluj de dats. En este cas l que se debe hacer es explicar que hace el prces en general y lueg que hace cada "pas" y/ "relación". Es decir, se partirá de l más general y se irá a l más específic, para btener de esta manera una visión general y detallada de td el prces. Es imprtante tener presente, que al cargar ls dats en las tablas de hechs pueden utilizarse preagregacines, ya sea al nivel de granularidad de la misma a trs niveles diferentes. Cas práctic: Para simplificar la aplicación del ejempl, el cas práctic sl se centrará en ls aspects más imprtantes del prces ETL, bviand entrar en detalle de cóm se realizan algunas funcines y/ pass. El prces ETL plantead para la Carga Inicial es el siguiente: Figura 5.26: Cas práctic, Carga Inicial.

107 Las tareas que lleva a cab este prces sn: Inici: inicia la ejecución de ls pass en el mment en que se le indique. Establecer variables Fecha_Desde y Fecha_Hasta: establece ds variables glbales que serán utilizadas psterirmente pr alguns pass. Para la variable "Fecha_Desde" se btiene el valr de la fecha en que se realizó la primera venta. Para la variable "Fecha_Hasta" se btiene el valr de la fecha actual. Carga de Dimensión CLIENTE: ejecuta el cntenedr de pass que cargará la dimensión CLIENTE, más adelante se detallará el mism. Carga de Dimensión PRODUCTO: ejecuta el cntenedr de pass que cargará la dimensión PRODUCTO, más adelante se detallará el mism. Carga de Dimensión FECHA: ejecuta el cntenedr de pass que cargará la dimensión FECHA, más adelante se detallará el mism. Carga de Tabla de Hechs VENTAS: ejecuta el cntenedr de pass que cargará la tabla de hechs VENTAS, más adelante se detallará el mism. A cntinuación, se especificarán las tareas llevadas a cab pr "Carga de Dimensión CLIENTE". Este pas es un cntenedr de pass, así que incluye las siguientes tareas: Figura 5.27: Cas práctic, Carga de Dimensión CLIENTE.

108 Obtener dats de OLTP: btiene a través de una cnsulta SQL ls dats del OLTP necesaris para cargar la dimensión CLIENTE. Se tmará cm fuente de entrada la tabla Clientes del OLTP mencinad anterirmente. Se cnsultó cn l@s usuari@s y se averiguó que deseaban tener en cuenta sl aquells clientes que n estén eliminads y que tengan su cuenta habilitada. Es imprtante destacar que aunque existían numerss mvimients de clientes que en la actualidad n pseen su cuenta habilitada que figuran cm eliminads, se decidió n incluirls debid a que el énfasis está puest en analizar ls dats a través de aquells clientes que n cuentan cn estas cndicines. Ls clientes eliminads sn referenciads mediante el camp Eliminad, en el cual un valr 1 indica que este fue eliminad, y un valr 0 que aún permanece vigente. Cuand se examinarn ls registrs de la tabla, para muchs clientes n había ningún valr asignad para este camp, l cual, según cmunicó el encargad del sistema, se debía a que este se agregó pc después de haberse cread la base de dats inicial, razón pr la cual existían valres faltantes. Además, cmentó que en el sistema, si un cliente psee en el camp Eliminad un valr 0 un valr faltante, es cnsiderad cm vigente. Cn respect a la cuenta habilitada, el camp del OLTP que le hace mención es Cta_Habilitada, y un valr 0 indica que n está habilitada y un valr 1 que sí. Seguidamente, se expndrá la sentencia SQL que cntiene este pas: Figura 5.28: Cas práctic, CLIENTE - Obtener dats de OLTP. Cargar CLIENTE: almacena en la tabla de dimensión CLIENTE ls dats btenids en el pas anterir.

109 A cntinuación, se especificará las tareas llevadas a cab pr "Carga de Dimensión PRODUCTO". Este pas es un cntenedr de pass, así que incluye las siguientes tareas: Figura 5.29: Cas práctic, Carga de Dimensión PRODUCTO. Obtener dats de OLTP: btiene a través de una cnsulta SQL ls dats del OLTP necesaris para cargar la dimensión PRODUCTO. Las fuentes que se utilizarán, sn las tablas Prducts y Marcas. En este cas, aunque existían prducts eliminads, l@s usuari@s decidiern que esta cndición n fuese tmada en cuenta, ya que habían mvimients que hacían referencia a prducts cn este estad. Es necesari realizar una unión entre la tabla Prducts y Marcas, pr l cual se debió asegurar que ningún prduct hiciera mención a alguna marca que n existiese, y se tmarn medidas cntra su futura aparición. El SQL que cntiene este pas es el siguiente: Figura 5.30 : Cas práctic, PRODUCTO - Obtener dats de OLTP.

110 Cargar PRODUCTO: almacena en la tabla de dimensión PRODUCTO ls dats btenids en el pas anterir. A cntinuación, se especificarán las tareas llevadas a cab pr "Carga de Dimensión FECHA". Este pas es un cntenedr de pass, así que incluye las siguientes tareas: Figura 5.31 : Cas práctic, Carga de Dimensión FECHA. Para generar esta tabla de dimensión, infaltable en td DW, existen varias herramientas y utilidades de sftware que prprcinan diversas pcines para su cnfección. Per, si n se cuenta cn ninguna, se puede realizar manualmente mediante algún prgrama, llenand ls dats en un archiv, tabla, hja de cálcul, etc, y lueg exprtándls a dnde se requiera. L que se hiz, fue realizar un prcedimient que hace l siguiente: Recibe cm parámetrs ls valres de "Fecha_Desde" y "Fecha_Hasta". Recrre una a una las fechas que se encuentran dentr de este interval. Analiza cada fecha y realiza una serie de peracines para crear ls valres de ls camps de la tabla de la dimensión FECHA:

111 Figura 5.32: Cas práctic, dats de FECHA. idfecha = YEAR(fecha)* MONTH(fecha)*100 + DAY(fecha). Añ = YEAR(fecha). Trimestre = CASE WHEN QUARTER(fecha) = 1 then '1er Tri'... END. Mes = CASE WHEN MONTH(fecha) = 1 then 'Ener'... END. Inserta ls valres btenids en la tabla de dimensión FECHA. Cm puede bservarse, la clave principal "idfecha" es un camp numéric representad pr el frmat "yyyymmdd". A cntinuación, se especificará las tareas llevadas a cab pr "Carga de Tabla de Hechs VENTAS". Este pas es un cntenedr de pass, así que incluye las siguientes tareas: Figura 5.33: Cas práctic, Carga de Tabla de Hechs VENTAS.

112 Obtener dats de OLTP: btiene a través de una cnsulta SQL ls dats del OLTP necesaris para cargar la tabla de hechs VENTAS. Para la cnfección de la tabla de hechs, se tmarn cm fuente las tablas Facturas_Ventas y Detalles_Venta. Al igual que en las tablas de dimensines, se reclectarn las cndicines que deben cumplir ls dats para cnsiderarse de interés, y en este cas, se trabajará slamente cn aquellas facturas que n hayan sid anuladas. Se investigó al respect, y se llegó a la cnclusión de que el camp que da dicha infrmación en Anulada de la tabla Facturas_Ventas y si el mism psee el valr 1 significa que efectivamente fue anulada. Otr punt imprtante a tener en cuenta es que la fecha se debe cnvertir al frmat numéric yyyymmdd. Se decidió aplicar una preagregación a ls hechs que frmarán parte de la tabla de hechs, es pr esta razón que se utilizará la cláusula GROUP BY para agrupar tds ls registrs a través de las claves primarias de esta tabla. La sentencia SQL que cntiene este pas fue la siguiente: Figura 5.34: Cas práctic, VENTAS - Obtener dats de OLTP..

113 Cargar VENTAS: almacena en la tabla de hechs VENTAS ls dats btenids en el pas anterir b) Actualización Cuand se haya cargad en su ttalidad el DW, se deben establecer sus plíticas y estrategias de actualización refresc de dats. Una vez realizad est, se tendrán que llevar a cab las siguientes accines: Especificar las tareas de limpieza de dats, calidad de dats, prcess ETL, etc., que deberán realizarse para actualizar ls dats del DW. Especificar de frma general y detallada las accines que deberá realizar cada sftware. Cas práctic: Las plíticas de Actualización que se han cnvenid cn l@s usuari@s sn las siguientes: La infrmación se refrescará tds ls días a las dce de la nche. Ls dats de las tablas de dimensines PRODUCTO y CLIENTE serán cargads ttalmente cada vez. Ls dats de la tabla de dimensión FECHA se cargarán de manera incremental teniend en cuenta la fecha de la última actualización. Ls dats de la tabla de hechs que crrespnden al últim mes (30 días) a partir de la fecha actual, serán reemplazads cada vez. Estas accines se realizarán durante un perid de prueba, para analizar cuál es la manera más eficiente de generar las actualizacines, basadas en el estudi de ls cambis que se prducen en ls OLTP y que afectan al cntenid del DW. Para evitar que se extienda demasiad la aplicación del ejempl, el cas práctic sl incluirá l que debería realizar el prces ETL para actualizar el DW. El prces ETL para la actualización del DW es muy similar al de Carga Inicial, per cuenta cn las siguientes diferencias: Inici: iniciará la ejecución de ls pass tds ls días a las dce de la nche. Establecer variables Fecha_Desde y Fecha_Hasta: La variable "Fecha_Desde" btendrá el valr resultante de restarle a la fecha actual treinta días. La variable "Fecha_Hasta" btendrá el valr de la fecha actual.

114 Carga de Dimensión CLIENTE: a la serie de tareas que realiza este pas, se le antecederá un nuev pas que brrará ls dats de la dimensión CLIENTE. Carga de Dimensión PRODUCTO: a la serie de tareas que realiza este pas, se le antecederá un nuev pas que brrará ls dats de la dimensión PRODUCTO. Carga de Dimensión FECHA: en este pas, en vez de recibir el valr de la variable "Fecha_Desde", se tmará la fecha del últim registr cargad en la dimensión FECHA. Carga de Tabla de Hechs VENTAS: a la serie de tareas que realiza este pas, se le antecederá un nuev pas que brrará ls dats de la tabla de HECHOS crrespndientes al interval entre "Fecha_Desde" y "Fecha_Hasta". en el pas "Obtener dats de OLTP" se le agregará a la sentencia SQL la siguiente cndición: WHERE Facturas_Venta.Fecha >= {Fecha_Desde} AND Facturas_Venta.Fecha <= {Fecha_Hasta} 5.6 Creación de Cubs Multidimensinales Capítul 5. Metdlgía HEFESTO 5.6 Creación de Cubs Multidimensinales Creación de Indicadres Creación de Atributs Creación de Jerarquías Otrs ejempls de cubs multidimensinales 5.6. Creación de Cubs Multidimensinales A cntinuación se creará un cub multidimensinal de ejempl, que será llamad Cub de Ventas y que estará basad en el mdel lógic diseñad en el cas práctic de la metdlgía Hefest:

115 Figura 5.30: Cas práctic, mdel lógic. La creación de este cub tiene las siguientes finalidades: Ejemplificar la creación de cubs multidimensinales. Prpiciar la crrecta distinción entre hechs de una tabla de hechs e indicadres de un cub. Prpiciar la crrecta distinción entre camps de una tabla de dimensión y atributs de un cub Creación de Indicadres En este mment se crearán ds indicadres que serán incluids en el cub Cub de Ventas : De la tabla de hechs VENTAS, se sumarizará el hech Cantidad para crear el indicadr denminad: Unidades Vendidas. La fórmula utilizada para crear este indicadr es la siguiente: Unidades Vendidas = SUM(VENTAS.Cantidad). De la tabla de hechs VENTAS,se sumarizará el hech MntTtal para crear el indicadr denminad: Mnt Ttal de Ventas. La fórmula utilizada para crear este indicadr es la siguiente: Mnt Ttal de Ventas = SUM(VENTAS.MntTtal). Entnces, el cub quedaría cnfrmad de la siguiente manera:

116 Figura 5.31: Cub ejempl, pas Creación de Atributs Ahra se crearán y agregarán al cub seis atributs: De la tabla de dimensión CLIENTE, se tmará el camp Cliente para la creación del atribut denminad: Clientes. De la tabla de dimensión PRODUCTO, se tmará el camp Marca para la creación del atribut denminad: Marcas. De la tabla de dimensión PRODUCTO, se tmará el camp Prduct para la creación del atribut denminad: Prducts. De la tabla de dimensión FECHA, se tmará el camp Añ para la creación del atribut denminad: Añs. De la tabla de dimensión FECHA, se tmará el camp Trimestre para la creación del atribut denminad: Trimestres. De la tabla de dimensión FECHA, se tmará el camp Mes para la creación del atribut denminad: Meses. Entnces, el cub quedaría cnfrmad de la siguiente manera:

117 Figura 5.32: Cub ejempl, pas Creación de Jerarquías Finalmente se crearán y agregarán al cub ds jerarquías: Se definió la jerarquía Jerarquía Prducts, que se aplicará sbre ls atributs recientemente creads, Marcas y Prducts, en dnde: Un prduct en especial pertenece sl a una marca. Una marca puede tener un más prducts. Gráficamente: Figura 5.33: PRODUCTO, relación padre-hij. Se definió la jerarquía Jerarquía Fechas, que se aplicará sbre ls atributs recientemente creads, Añs, Trimestres y Meses, en dnde: Un mes del añ pertenece sl a un trimestre del añ. Un trimestre del añ tiene un más meses del añ. Un trimestre del añ pertenece sl a un añ. Un añ tiene un más trimestres del añ.

118 Gráficamente: Figura 5.34: FECHA, relación padre-hij. Entnces, el cub quedaría cnfrmad de la siguiente manera: Figura 5.35: Cub ejempl, pas Otrs ejempls de cubs multidimensinales A partir del mdel lógic plantead, pdrían haberse cread una gran cantidad de cubs, cada un de ls cuales estaría rientad a un tip de análisis en particular. Tal y cm se explicó antes, ests cubs pueden cexistir sin ningún incnveniente.

119 A cntinuación se expndrán una serie de cubs de ejempl: Cub 1: Figura 5.36: Cub 1, ejempl Cub 2: Figura 5.37: Cub 2, ejempl. Cub 3: Figura 5.38: Cub 3, ejempl.

120 6. Cnsideracines de Diseñ 6.1 Tamañ del DW Dependiend del negci, el vlumen de dats y el alcance del pryect, el tamañ del DW puede variar cnsiderablemente, pr l cual, es una buena práctica tener est en cuenta al mment de diseñar el depósit y al determinar ls recurss físics, ls tiemps de desarrll y ls respectivs csts inherentes. De acuerd al tamañ del depósit de dats, se l puede clasificar cm: Persnal: si su tamañ es menr a 1 Gigabyte. Pequeñ: si su tamañ es mayr a 1 Gigabyte y menr a 50 Gigabyte. Median: si su tamañ es mayr a 50 Gigabyte y menr a 100 Gigabyte. Grande: si su tamañ es mayr a 100 Gigabyte y menr a 1 Terabyte. Muy grande: si su tamañ es mayr a 1 Terabyte. 6.2 Tiemp de cnstrucción Divers@s autr@s resaltan la imprtancia del factr tiemp en la cnstrucción de un DW, pr l cual se ha cnsiderad interesante expner tres frases seleccinadas al respect: El 70 % del tiemp ttal dedicad al pryect se insume en definir el prblema y en preparar la tabla de dats. Estime el tiemp necesari, multiplíquel pr ds y agregue una semana de resguard. Regla : el primer 90 % de la cnstrucción de un sistema absrbe el 90 % del tiemp y esfuerz asignads; el últim 10 % se lleva el tr 90 % del tiemp y esfuerz asignad. 6.3 Implementación Las implementacines de ls depósits de dats varían entre sí de frma cnsiderable, teniend en cuenta las herramientas de sftware que se empleen, ls mdels que se utilicen, recurss dispnibles, SGBD que l sprten, herramientas de análisis y cnsulta, entre trs.

121 6.4 Perfrmance Cuand se diseñan ls ETLs, es muy imprtante que ls misms sean l más eficientes psible, ya que una vez que se tenga un gran vlumen de dats, el espaci en disc se vlverá fundamental y ls tiemps incurrids en el prcesamient y acces a la infrmación serán esenciales, y más aún si el DWH es cnsiderad tmad cm un sistema de misión crítica. También es muy imprtante cnfigurar crrectamente el SGBD en el que se almacene y mantenga el DW, así cm l es elegir las mejres estrategias para mdelar las diferentes estructuras de dats que se utilizarán. Para mejrar la perfrmance del DWH, se pueden llevar a cab las siguientes accines sbre el DW y las estructuras de dats (cubs multidimensinales, Business Mdels, etc): Prestar especial atención a ls tips de dats utilizads, pr ejempl, para valres enters pequeñs cnviene utilizar tinyint smallint en lugar de int, cn el fin de n asignar tamañs de dats mayres a ls necesaris. Est tma vital imprtancia cuand se aplica en las claves primarias, debid a que frmarán parte de la tabla de hechs que es la que cntiene el vlumen del almacén de dats. Utilizar Claves Subrgadas. Utilizar técnicas de indexación. Utilizar técnicas de particinamient. Crear diferentes niveles de sumarización. Crear vistas materializadas. Utilizar técnicas de administración de dats en memria caché. Utilizar técnicas de multiprcesamient, cn el bjetiv de agilizar la btención de resultads, a través de la realización de prcess en frma cncurrente. 6.5 Mantenimient Un punt muy imprtante es mantener en crrect funcinamient al DW, ya que a medida que pase el tiemp, este tenderá a crecer significativamente, y surgirán cambis, tant en ls requerimients cm en las fuentes de dats. 6.6 Impacts Al implementar un DWH, es fundamental que l@s usuari@s del mism participen activamente durante td su desarrll, debid a que sn ell@s l@s que cncen en prfundidad su negci y saben cuáles sn ls resultads que se desean btener. Además, es precisamente en base a la utilización que se le de, que el depósit de dats madurará y se adaptará a las situacines cambiantes pr las que atraviese la empresa. L@s usuari@s, al trabajar junt a l@s desarrlladr@s y analistas pdrán cmprender más en prfundidad sus prpis sistemas peracinales, cn td l que est implica.

122 Cn la implementación del DWH, ls prcess de tma de decisines serán ptimizads, al btener infrmación crrecta al instante en que se necesita, evitand perdidas de tiemp y anmalías en ls dats. Al cntar cn esta infrmación, l@s usuari@s tendrán más cnfianza en las decisines que tmarán y en adición a ell, pseerán una base sustentable para justificarlas. Usualmente, ls DW integrarán fuentes de dats de diversas áreas y sectres de la empresa, est tendrá cm benefici cntar cn una sla fuente de infrmación centralizada y cmún para td@s l@s usuari@s. Est psibilitará que en las diferentes áreas se cmpartan ls misms dats, l cual cnducirá a un mayr entendimient, cmunicación, cnfianza y cperación entre las mismas. El DWH intrducirá nuevs cncepts tecnlógics y de inteligencia de negcis, l cual requerirá que se aprendan nuevas técnicas, herramientas, métds, destrezas, frmas de trabajar, etc. 6.7 DM cm subpryects Al diseñar e implementar DM cm partes de un pryect DW, se debe tener en cuenta que el análisis que se efectuará, ls mdels que intervendrán y el alcance, deben ser glbales, cn el fin de determinar, pr ejempl, tablas de dimensines cmunes entre las diferentes áreas de trabaj. Est evitará que se realicen tareas repetidas, ahrrand tiemps y enfcándse en la cnslidación, unificación y centralización de la infrmación de ls diferentes sectres. 6.8 Tería de Grafs Para evaluar la validez de la estructura lógica del depósit de dats, puede emplearse la tería de grafs, la cual afirma que su estructura será crrecta sí y sl sí está cnfrmada únicamente pr trayectrias acíclicas. Si se encuentran trayectrias cíclicas, deberán ser transfrmadas para que las cnsultas al DW sean válidas y cnfiables. Una trayectria acíclica, es aquella que sól tiene una frma de recrrid (en un sl sentid). Pr ejempl, en la siguiente figura se puede apreciar que existe una sla manera de recrrer las tablas de dimensines. Figura 6.1: Trayectria acíclica.

123 Una trayectria cíclica, es aquella que se puede recrrer en ds más secuencias diferentes. Pr ejempl, en la siguiente imagen se pueden distinguir ds sentids pr ls cuales recrrer las tablas de dimensines. Figura 6.2: Trayectria cíclica. 6.9 Elección de Clumnas Cuand se seleccinan ls camps que integrarán el DW, se debe tener en cuenta l siguiente: Se deben descartar aquells camps cuys valres tengan muy pca variabilidad. Se deben descartar ls camps que tengan valres diferentes para cada bjet, pr ejempl el númer de D.N.I. cuand se analizan persnas. En ls cass en que n existan jerarquías dentr de alguna tabla de dimensión, en la cual la cantidad de registrs que psee la misma sn demasiads, es cnveniente, cnjuntamente cn l@s usuari@s, definirlas. Per, si llegase a suceder que n se encntrase ningún criteri pr el cual jerarquizar ls camps, es una buena práctica crear jerarquías prpias. El bjetiv de llevar a cab esta acción, es la de pder dividir ls registrs en grups, prpiciand de esta manera una explración más amena y cntrlable. Para ejemplificar este punt, se utilizará cm referencia la tabla de dimensión de la siguiente figura. La misma n psee ninguna jerarquía definida y la cantidad de registrs cn que cuenta sn cients:

124 Figura 6.3: Tabla de dimensión PRODUCTO. Entnces, l que se realizará será crear una nueva jerarquía a partir de ls camps dispnibles: Se añadirá a la tabla un nuev camp ( Letra ), el mism estará frmad pr la primera letra del atribut Prduct que l acmpaña. Pr ejempl, si el valr de Prduct es Lapicera, Letra será L ; si es Cartuchera será C, etc. El resultad será el siguiente: Figura 6.4: Jerarquía de PRODUCTO. Además, se pueden aplicar algunas de las accines que se expndrán a cntinuación sbre ls valres de ls camps que se incluirán en el depósit de dats: Factrizar: se utiliza para descmpner un valr en ds más cmpnentes. Pr ejempl, el camp códig perteneciente a un prduct está frmad pr tres identificadres separads pr guines medis, que representan su rubr, marca y tip ( idrubr-idmarcaidtip ), entnces este camp puede factrizarse y separarse en tres valres independientes ( idrubr, idmarca e idtip ). Estandarizar: se utiliza para ajustar valres a un tip de frmat nrma preestablecida. Pr ejempl, se puede emplear esté métd cuand se desea que tds l camps del tip text sean cnvertids a mayúscula. Cdificar: es utilizad para representar valres a través de las reglas de un códig preestablecid. Pr ejempl, en el camp estad se pueden cdificar sus valres, 0 y 1, para transfrmarls en Apagad y Encendid respectivamente. Discretizar: es emplead para cnvertir un cnjunt cntinu de valres en un discret. Pr ejempl, cuand se especificarn ls tamañs del DW se realizó está peración.

125 6.10 Claves Primarias en Tablas de Dimensines Al mment de añadir la clave principal a una tabla de dimensión, se puede establecer: 1. Una única clumna que sea clave primaria e identifique unívcamente cada registr. 2. Varias clumnas que sean clave primaria e identifiquen en cnjunt, unívcamente cada registr. La primera pción requiere mens espaci de almacenamient en el DW y permite que las cnsultas SQL sean más sencillas. La segunda pción requiere más espaci de almacenamient en el DW, prvca que las cnsultas SQL sean más cmplejas y pr cnsiguiente hace que se demre más tiemp en prcesar ls resultads. Sin embarg, esta última alternativa hace que ls prcess ETL sean mens cmplejs y más eficientes. Más allá de estas ds grandes pcines, es ttalmente recmendable la utilización de Claves Subrgadas Balance de Diseñ El siguiente gráfic muestra ls tres punts más imprtantes que se deben balancear al mment de diseñar y cnstruir el mdel lógic de dats del DW: Figura 6.5: Balance de diseñ. Estas tres características están fuertemente relacinadas y cndicinadas entre sí, pr l cual, el valr que adpte cada una de ellas, afectará a las tras de manera significativa. Pr ejempl, si se enfca la atención en ls requerimients de l@s usuari@s, se btendrá un DW muy cmplej que cubrirá tdas las necesidades de análisis. Sin embarg, traerá cm cntrapartida una disminución en la perfrmance de las cnsultas y un aument del mantenimient de las bases de dats.

126 6.12 Relación muchs a muchs Siempre que sea psible, se debe evitar mantener en el DW tablas de dimensines cn relacines muchs a muchs entre ellas, ya que esta situación puede, entre trs incnvenientes, prvcar la pérdida de la capacidad analítica de la infrmación y cnducir a una sumarización incrrecta de ls dats. Para explicar esta prblemática, se tmará cm ejempl la relación existente entre rís y prvincias, es decir: Una prvincia tiene un más rís, y un rí pertenece a una más prvincias. Además, se tmará cm referencia las siguientes tablas pertenecientes a un OLTP, que cntienen básicamente ls dats relacinads a rís y prvincias: Figura 6.6: Tabla RIOS. Figura 6.7: Tabla PROVINCIAS. Cuand existe este tip de relación (muchs a muchs) entre ds más tablas, se pueden realizar diferentes accines para slventar esta situación. Una psible slución, sería llevar a cab ls siguientes pass: 1. Crear una tabla de dimensión pr cada entidad que pertenece a la relación. Cada una de estas tablas n debe incluir ninguna crrespndencia a las demás. En este cas se

127 crearán ds tablas de dimensines, DIM_RIOS (crrespndiente a la entidad RIOS ) y DIM_PROV (crrespndiente a la entidad PROVINCIAS ). 2. Crear tra tabla de dimensión (en este cas DIM_RELACION), que sea hija de las tablas de dimensines recientemente cnfeccinadas (en este cas DIM_RIOS y DIM_PROV), que estará cmpuesta de ls siguientes camps: Clave principal: dat autnuméric autincrementable (en este cas id_dim_relacin ). Claves fráneas: se deben añadir cada una de las clumnas que representan la clave principal de las tablas de dimensines en cuestión (en este cas id_dim_ri y id_dim_prv ). Otrs camps de infrmación adicinal. 3. Incluir el camp clave principal cread en el pas anterir (en este cas id_dim_relacin ) en la tabla de Hechs. Gráficamente, el resultad sería el siguiente: Figura 6.8: Psible slución al mdelad de la relación muchs a muchs. Otra psible slución sería agregar las ds claves primarias de las tablas de dimensines DIM_RIOS y DIM_PROV en la tabla de hechs. Existen tras slucines para slventar esta brecha, per la primera prpuesta psee mucha perfrmance, ya que: Elimina la relación muchs a muchs. Sl se necesita un camp clave en la tabla de Hechs. Las relacines entre las tablas resultantes es simple y fácil de visualizar. La única desventaja es en cuant a ls prcess ETL, ya que se aumenta su cmplejidad y tiemp de prces.

128 6.13 Claves Subrgadas Las claves existentes en ls OLTP se denminan claves naturales; en cambi, las claves subrgadas sn aquellas que se definen artificialmente, sn de tip numéric secuencial, n tienen relación directa cn ningún dat y n pseen ningún significad en especial. L anterir, es sl una de las raznes pr las cuales utilizar claves subrgadas en el DW, per se pueden definir una serie de ventajas más: Ocupan mens espaci y sn más perfrmantes que las tradicinales claves naturales, y más aún si estas últimas sn de tip text. Sn de tip numéric enter (autnuméric secuencial). Permiten que la cnstrucción y mantenimient de índices sea una tarea sencilla. El DW n dependerá de la cdificación interna del OLTP. Si se mdifica el valr de una clave en el OLTP, el DW l tmará cm un nuev element, permitiend de esta manera, almacenar diferentes versines del mism dat. Permiten la crrecta aplicación de técnicas SCD (Dimensines lentamente cambiantes). Esta clave subrgada debe ser el únic camp que sea clave principal de cada tabla de dimensión. Una frma de implementación sería, a través de la utilización de herramientas ETL, mantener una tabla que cntenga la clave primaria de la tabla del OLTP y la clave subrgada crrespndiente a la dimensión del DW. En la tabla de dimensión Tiemp, es cnveniente hacer una excepción y mantener un frmat tal cm "yyyymmdd", ya que est prvee ds grandes beneficis: Se simplifican ls prcess ETL. Brinda la psibilidad de realizar particines de la tabla de hechs a través de ese camp Dimensines lentamente cambiantes Las dimensines lentamente cambiantes SCD (Slwly Changing Dimensins) sn dimensines en las cuales sus dats tienden a mdificarse a través del tiemp, ya sea de frma casinal cnstante, implique a un sl registr la tabla cmpleta. Cuand curren ests cambis, se puede ptar pr seguir alguna de estas ds grandes pcines: Registrar el histrial de cambis. Reemplazar ls valres que sean necesaris. Inicialmente Ralph Kimball planteó tres estrategias a seguir cuand se tratan las SCD: tip 1, tip 2 y tip 3; per a través de ls añs la cmunidad de persnas que se encargaba de mdelar bases de dats prfundizó las definicines iniciales e incluyó varis tips SCD más, pr ejempl: tip 4 y tip 6. A cntinuación se detallará cada tip de estrategia SCD:

129 SCD Tip 1: Sbreescribir. SCD Tip 2: Añadir fila. SCD Tip 3: Añadir clumna. SCD Tip 4: Tabla de Histria separada. SCD Tip 6: Híbrid. De acuerd a la naturaleza del cambi se debe seleccinar qué Tip SCD se utilizará, en alguns cass resultará cnveniente cmbinar varias técnicas. Es imprtante señalar que si bien hay diferentes maneras de implementar cada técnica, es indispensable cntar cn claves subrgadas en las tablas de dimensines para aplicar pder aplicar dichas técnicas. Al aplicar las diferentes técnicas SCD, en muchs cass se deberá mdificar la estructura de la tabla de dimensión cn la que se este trabajand, pr l cual estas mdificacines sn recmendables hacerlas al mment de mdelar la tabla; aunque también puede hacerse una vez que ya se ha mdelad y cntiene dats, para l cual al añadir pr ejempl una nueva clumna se deberá especificar ls valres pr defect que adptarán ls registrs de la tabla. NOTA: para tds ls ejempls a cntinuación, "id_prduct" es una clave subrgada que es clave principal de la tabla utilizada. SCD Tip 1: Sbreescribir Este tip es el más básic y sencill de implementar, ya que si bien n guarda ls cambis histórics, tampc requiere ningún mdelad especial y n necesita que se añadan nuevs registrs a la tabla. En este cas cuand un registr presente un cambi en algun de ls valres de sus camps, se debe prceder simplemente a actualizar el dat en cuestión, sbreescribiend el antigu. Para ejemplificar este cas, se tmará cm referencia la siguiente tabla: id_prduct Rubr Tip Prduct 1 Rubr 1 Tip 1 Prduct 1 Ahra, se supndrá que este prduct ha cambiad de Rubr, y ahra a pasad a ser "Rubr 2", entnces se btendrá l siguiente: id_prduct Rubr Tip Prduct 1 Rubr 2 Tip 1 Prduct 1

130 Usualmente este tip es utilizad en cass en dnde la infrmación histórica n sea imprtante de mantener, tal cm sucede cuand se debe mdificar el valr de un registr prque tiene errres de rtgrafía. El ejempl plantead es sl a fines práctics, ya que cn esta técnica, tds ls mvimients realizads de "Prduct 1", que antes pertenecían al "Rubr 1", ahra pasarán a ser del "Rubr 2", l cual creará una gran incnsistencia en el DW. SCD Tip 2: Añadir fila Esta estrategia requiere que se agreguen algunas clumnas adicinales a la tabla de dimensión, para que almacenen el histrial de cambis. Las clumnas que suelen agregarse sn: FechaInici: fecha desde que entró en vigencia el registr actual. Pr defect suele utilizarse una fecha muy antigua, ejempl: "01/01/1000". FechaFin: fecha en la cual el registr actual dejó de estar en vigencia. Pr defect suele utilizarse una fecha muy futurista, ejempl: "01/01/9999". Versión: númer secuencial que se incrementa cada nuev cambi. Pr defect suele cmenzar en "1". Versión actual: especifica si el camp actual es el vigente. Este valr puede ser en cas de ser verdader: "true" "1"; y en cas de ser fals: "flase" "0". Entnces, cuand curra algún cambi en ls valres de ls registrs, se añadirá una nueva fila y se deberá cmpletar ls dats referids al histrial de cambis. Para ejemplificar este cas, se tmará cm referencia la siguiente tabla: id_prduct Rubr Tip Prduct 1 Rubr 1 Tip 1 Prduct 1 A cntinuación se añadirán las clumnas que almacenarán el histrial: id_prduct Rubr Tip Prduct FechaInici FechaFin Versin VersinActual 1 Rubr 1 Tip 1 Prduct 1 01/01/ /01/ true Ahra, se supndrá que este prduct ha cambiad de Rubr, y ahra a pasad a ser "Rubr 2", entnces se btendrá l siguiente:

131 id_prduct Rubr Tip Prduct FechaInici FechaFin Versin VersinActual 1 Rubr 1 Tip 1 Prduct 1 01/01/ /11/ false 2 Rubr 2 Tip 1 Prduct 1 07/11/ /01/ true Cm puede bservarse, se lleva a cab el siguiente prces: Se añade una nueva fila cn su crrespndiente clave subrgada ("id_prduct"). Se registra la mdificación ("Rubr"). Se actualizan ls valres de "FechaInici" y "FechaFin", tant de la fila nueva, cm la antigua (la que presentó el cambi). Se incrementa en un el valr del camp "Versin" que psee la fila antigua. Se actualizan ls valres de "VersinActual", tant de la fila nueva, cm la antigua; dejand a la fila nueva cm el registr vigente (true). Esta técnica permite guardar ilimitada infrmación de cambis. SCD Tip 3: Añadir clumna Esta estrategia requiere que se agregue a la tabla de dimensión una clumna adicinal pr cada clumna cuys valres se desea mantener un histrial de cambis. Para ejemplificar este cas, se tmará cm referencia la siguiente tabla: id_prduct Rubr Tip Prduct 1 Rubr 1 Tip 1 Prduct 1 A cntinuación se añadirá una clumna para mantener el históric de cambis sbre ls dats de la clumna "Rubr": id_prduct Rubr RubrAnterir Tip Prduct 1 Rubr 1 - Tip 1 Prduct 1

132 Ahra, se supndrá que este prduct ha cambiad de Rubr, y ahra a pasad a ser "Rubr 2", entnces se btendrá l siguiente: id_prduct Rubr RubrAnterir Tip Prduct 1 Rubr 2 Rubr 1 Tip 1 Prduct 1 Cm puede bservarse, se lleva a cab el siguiente prces: En la clumna "RubrAnterir" se clca el valr antigu. En la clumna "Rubr" se clca el nuev valr vigente. Esta técnica permite guardar una limitada infrmación de cambis. SCD Tip 4: Tabla de Histria separada Esta técnica se utiliza en cmbinación cn alguna tra y su función básica es almacenar en una tabla adicinal ls detalles de cambis histórics realizads en una tabla de dimensión. Esta tabla histórica indicará pr ejempl que tip de peración se ha realizad (Insert, Update, Delete), sbre que camp y en que fecha. El bjetiv de mantener esta tabla es el de cntar cn un detalle de tds ls cambis, para lueg analizarls y pder tmar decisines acerca de cuál técnica SCD pdría aplicarse mejr. Pr ejempl, la siguiente tabla histórica registra ls cambis de la tabla de dimensión "Prducts", la cual supndrems emplea el SCD Tip 2: id_prduct Rubr_Cambi Tip_Cambi Prduct_Cambi FechaDeCambi 1 Insert /06/ Insert Insert - 25/10/ Insert - 17/01/ Insert 18/02/2009 Tmand cm ejempl el primer registr de esta tabla, la infrmación allí guardada indica l siguiente:

133 El día "05/06/2000", el registr de la tabla de dimensión "Prducts" cn "id_prduct" igual a "1" sufrió un cambi de "Rubr", pr l cual se debí insertar ("Insert") una nueva fila cn ls valres vigentes. SCD Tip 6: Híbrid Esta técnica cmbina las SCD Tip 1, 2 y 3. Se denmina SCD Tip "6", simplemente prque: 6 = Dimensines Degeneradas El términ Dimensión Degenerada, hace referencia a un camp que será utilizad cm criteri de análisis y que es almacenad en la tabla de hechs. Est sucede cuand un camp que se utilizará cm criteri de análisis psee el mism nivel de granularidad que ls dats de la tabla de hechs, y que pr l tant n se pueden realizar agrupacines sumarizacines a través de este camp. Ls "númers de rden", "númers de ticket", "númers de transacción", etc, sn alguns ejempls de dimensines degeneradas La inclusión de ests camps en las tablas de hechs, se lleva a cab para reducir la duplicación y simplificar las cnsultas Dimensines Clustering Las dimensines Clustering, sn aquellas que están relacinadas a ds más dimensines y que brindan infrmación diferente a cada una de ellas. Pr ejempl, en el siguiente esquema, se puede apreciar que ds tablas de dimensines ( CLIENTES y PROVEEDORES ) cmparten tra en cmún ( CIUDADES ), además esta última prvee diferente infrmación dependiend de la tabla de dimensión que la cnsulte, es decir, devuelve el nmbre de la ciudad de l@s client@s bien la de l@s prveedr@s. En este cas y debid a l dich anterirmente, la dimensión CIUDADES, es una dimensión Clustering. Figura 6.18: Dimensión Clustering: "CIUDADES"

134 Obviamente n se puede mantener este esquema si se pretende analizar ls hechs de acuerd a la ciudad de l@s prveedr@s y de l@s client@s simultáneamente. Para slucinar esta situación pueden llevarse a cab diferentes estrategias, cada una de las cuales trae aparejadas sus ventajas y desventajas, pr l cual dependiend cual sea el cntext se elegirá entre una y tra. A cntinuación se destacarán algunas slucines a esta situación: 1. Se pueden incluir tds ls camps de la dimensión Clustering en cada tabla de dimensión cn que se relacine y eliminar lueg la dimensión Clustering. En este cas: Agregar el camp nmbreciudad de la dimensión Clustering CIUDADES a la tabla de dimensión CLIENTES. Agregar el camp nmbreciudad de la dimensión Clustering CIUDADES a la tabla de dimensión PROVEEDORES. Eliminar la dimensión Clustering CIUDADES. Figura 6.19: Dimensión Clustering: primera psible slución. Ventajas: Elimina ls JOINs entre las tablas. Desventajas: Ante cualquier cambi en ls nmbres de las ciudades se debe mdificar/actualizar tdas las dimensines implicadas. 2. Se puede crear una nueva tabla de dimensión basada en la dimensión Clustering pr cada tabla que se relacine cn esta y lueg eliminar la dimensión Clustering. En este cas: Crear la tabla de dimensión CIUDADES_CLI, esta estará basada en la dimensión Clustering CIUDADES.

135 Crear la tabla de dimensión CIUDADES_PROV, esta estará basada en la dimensión Clustering CIUDADES. Eliminar la dimensión Clustering CIUDADES. Figura 6.20: Dimensión Clustering: segunda psible slución. Ventajas: Ante cualquier cambi en ls nmbres de las ciudades, sl se deben mdificar/actualizar las nuevas dimensines que están basadas en la dimensión Clustering. Desventajas: Mantiene ls JOINs entre las tablas. A. Descripción de la Empresa Descripción de la empresa. Apéndice A A Descripción de la empresa A.1 Identificación de la empresa A.2 Objetivs A.3 Plíticas A.4 Estrategias A.5 Organigrama A.6 Dats del entrn específic A.7 Relación de las metas de la rganización cn las del DWH A.8 Prcess Descripción de la empresa A.1. Identificación de la empresa La cmpañía analizada, desarrlla las actividades cmerciales de mayrista y minrista de artículs de limpieza, en un ambiente gegráfic de alcance nacinal. De acuerd a su vlumen de peracines, se la puede cnsiderar de tamañ median. Cn respect a su clasificación, es una sciedad de respnsabilidad limitada cn fines de lucr. Su estructura está frmalizada y psee características de una rganización funcinal.