ÍNDEX

1. INTRODUCCIÓ

INTRODUCCIÓ

Objectiu

L'objectiu d'aquest document és bàsicament demostrar la gran necessitat de seguir una metodologia a l'hora de fer un projecte per a assolir l'èxit d'aquest. Es veurà la necessitat d'una fase d'especificació de requeriments amb entrevistes amb els implicats, d'una fase d'implantació, de redacció de documents al final de cada fase per a tenir-ho tot per escrit i així evitar confusions, en el fons, es veurà que ambdós metodologies descrites, a pesar de ser diferents, tenen un fons comú, i que s'adequa al que he estat estudiant aquest any a MP4. En aquest document s'explica doncs com l'aplicació de metodologies pot ajudar a dur a terme projectes tan inmensos i de tanta dificultat com ara muntar un Datawarehouse.

Un Datawarehouse és una arquitectura de dades orientades a una aplicació que les transforma en dades de suport a les decisions, és a dir, en dades que capturen la naturalesa bàsica del negoci.

Les dades han de ser integrades perquè són de naturalesa heterogènia, és a dir que provenen de diferents sistemes heretats o d'informació no processada i variables en temps.

Una altra característica del DW és que aquest incorpora contínuament informació que ha de ser integrada a la informació existent. A la vegada ha de permetre que els sistemes actuals continuin en operació sense interferir ni col·lisionar amb aquests.

També ha de consolidar inconsistències de dades entre els múltiples sistemes (heretats) de l'empresa en una sola base de dades orientada coherentment a la presa de decisions.

En el disseny d'un DW s'han d'abandonar els conceptes actuals de normalització de dades, ja que presenta problemes seriosos quan s'ha d'accedir a la informació.

Al desnormalitzar el conjunt de taules usant mètodes de DW, s'aconsegueix un disseny que permet realitzar “queries” usant SQL Estándar, massa complexos de realitzar amb una normalització tradicional.

Aquest disseny però, pot estar orientat a OLAP ( On Line Analytical Processing).

Un DW ha d'estar format com a mínim per els següents components :

• Base de dades font en un host ( pex: un OLTP).

• Eines d'extracció i transformació, utilitzades per a prendre la informació de la font, reorganitzar-la, sumaritzar-la i depositar-la en el repositori.

• Un repositori de dades o Target sobre un servidor que pot ser relacional o multidimensional.

• Eines Front-End utilitzades pels professionals en negocis, per a l'accés i anàlisi de les dades.

Abans de començar a dissenyar un DataWarehouse s'ha de seleccionar una base de dades “Target” i depenent de la que agafem, tindrem diverses eines d'accés i anàlisi per a l'usuari final.

Arquitectura genèrica

Els elements necessaris per a la implementació de sistemes de suport a la presa de decisions són els següents :

• Definició de l'ambient i àrees de negoci : Es necessita tindre definit l'ambient en el qual es desenvolupa el projecte. S'estarà sempre tractant amb els alts nivells de l'empresa i conéixer les àrees del negoci serà vital per al resultat final.

D'aquesta forma, a més de superar qüestions departamentals, s'estarà evidenciant el que és verdaderament important per a l'empresa, encara que s'estigui analitzant una petita part d'ella. Per això aquest anàlisi serà més utilitzat per a negocis que per a una estructura organitzacional.

• Análisi de necessitats d'informació : Ha de consistir en l'análisi de les necessitats d'informació de gerents i executius involucrats. Les seves decisions estan basades en els seus coneixements proporcionats per la pròpia empresa.

• Anàlisi de fonts de dades : És necessari també un anàlisi sobre les dades de l'empresa per a verificar si existeix informació suficient per a atendre les necessitats i qualitat d'informació.

• Projecte d'extracció de dades : Es segueix un projecte d'accés (extracció) de les dades de la manera més correcta sense interferir en el treball d'equip d'informàtica o de la persona responsable.

• El·laboració de Data Mart (model multidimensional) : Conegudes les necessitats dels executius i detalls sobre les dades per a ser utilitzats en l'extracció, es passa al peojecte i construcció dels Data Marts, un model mutidimensional OLAP.

• Personalització de les visions del model : Com a resultat de l'anàlisi amb els executius serà possible reunir les necessitats més sol·licitades per cadascun d'ells. Aquesta personalització augmenta la capacitat d'anàlisi de les persones encarregades de la presa de decisions al no tindre's que preocupar en saber com arribar-hi , simplement està allí per a ser utilitzada.

DIVERSES METODOLOGIES

Metodologia DM2

La metodologia DM2 es basa en les necessitats d'informació a nivell gerencial, on la informació ha de ser enfocada com a patrimoni de l'empresa, accessible a qui la necessiti.

Aquesta metodologia s'assembla a la forma “top-down”, i retalla en funció raonable el temps entre l'inici de l'anàlisi i la implantació. Aquesta rapidesa és molt bona per al client i exigida i necessària pel propi ambient que el rodeja. Qui decideix no pot esperar mesos d'anàlisi, projecte i implementació per a poder prendre decisions.

Essencialment la metodologia DM2 està concentrada en crear un model multidimensional OLAP que satisfagi aquestes necessitats. Es pot dir que es basa en dos principis :

• Conéixer l'estructura del negoci o core business, ja que l'empresa coneix les necessitats d'informació dels usuaris finals.

• Conegut el negoci sabrem quins òrgans han de ser entrevistats i estudiades les necessitats d'informació, sabrem “què“ buscar i “on” estan les dades.

DM2 doncs, surgeix per a organitzar i estructurar la forma d'obtenció d'informació i implantació del model multidimensional, basat en l'arquitectura genèrica explicada a la introducció. d'aquesta forma es divideix en :

• Anàlisis corporatius.

• Definició de l'ambient de les àrees del negoci.

• Desenvolupament de Data Marts.

• Anàlisi de les necessitats d'informació.

• Anàlisi de la font de dades.

• Projecte d'extracció de dades.

• Elaboració del model multidimensional.

• Personalització de visions dels cubs.

• Anàlisi inter-departamental.

• Eliminació de redundàncies.

Algunes d'aquestes etapes podrien no ser necessàries, tot depenent de la complexitat i extensió del projecte.

2.1.1. Anàlisis corporatius

El primer pas realitza l'anàlisi de la corporació a partir de la missió i àrees de negoci. No s'analitzaran departaments, sectors ..., sinó les funcions de negoci i els seus processos. D'aquesta manera s'obté un anàlisi enfocat cap al negoci, independentment de la seva estructura organitzacional.

El resultat d'aquest anàlisi és un document que caracteritza a l'empresa amb la seva estructura organitzacional, les àrees de negoci involucrades en el projecte i amb un cronograma per a haver-lo de complir en la realització del projecte.

Això és important perquè a partir d'ell vàries orientacions es prendran durant el projecte. Prioritats, àrees i negocis, directors i gerents s'haurien d'entrevistar en aquesta fase.

No és aconsellable l'ús d'aquesta fase en projectes petits o pilots, ja que seria una despesa innecessaria de temps en una cosa que no serà gaire definitiva doncs els projectes petits estan al voltant d'una part d'una àrea del negoci de l'empresa, o dins d'un departament aïllat.

2.1.2. Desenvolupament de Data Marts

Aquest és el cos principal de la metodologia. Un cop identificats els processos de cada funció rellevant del projecte, es segueixen les següents fases :

• Identificació de Data Marts : Un cop estan definits els processos de les funcions de negoci de l'empresa, es pot saber quins són els Data Marts.

Aquest “mapa” sol ser simple, però ha de ser realitzat amb molt de compte doncs en aquest anàlisi es podrà detectar si algú té la necessitat d'acompanyar o verificar el funcionament d'alguna activitat.

• Anàlisi OLAP : D'aquesta fase s'obtenen totes les informacions que donaran cos al Data Marts. Els usuaris finals hauran de ser els entrevistats, amb aquestes entrevistes s'anirà descobrint quines són les necessitats d'informació de cada usuari i per a cada necessitat quins són els paràmetres de consulta que utilitzen.

Aquestes infromacions obtingudes són el nucli de tota metodologia, són l'objectiu de qualsevol projecte, per això s'ha d'obtindre el màxim nombre d'informació sobre cada necessitat i sobre cada espectativa.

Al final, es farà la preparació del Document d'Anàlisi OLAP per a ser avaluat amb l'usuari final.

• Anàlisi OLTP : Aquest anàlisi dirà on està l'origen de la informació necessària per a atendre l'anàlisi OLAP. Aquestes informacions no són invencions ni aproximacions, són amb dades adquirides del passat, de la història de l'empresa, dades que donen perfils que no poden ser desperdiciats.

Generalment aquestes informacions es troben an la BD corporativa i per tant les millors presones per a respondre sobre les dades de l'empresa seran els DBAs de diversos sistemes que tinguin informació per als cubs.

Al final d'aquesta fase s'obté el Document d'Anàlisi OLTP per a avaluar-lo amb l'equip d'informàtica involucrat.

• Anàlisi de viabilitat : En aquesta fase se sintetizen les diferències entre les necessitats d'informació i els paràmetres de consulta de les dades de les BD corporatives.

S'ha de concloure el grau de dificultat que tindrà desenvolupar els cubs i els processos d'extracció i conversió.

• Projecte OLAP : En aquesta fase es transformen totes les dades obtingudes de la fase d'anàlisi d'OLAP en el model multidimensional OLAP. Al final d'aquesta fase, el model podrà ser implementat en algun paquet de SW que contingui eines per aplicacions OLAP.

Al final d'aquesta fase s'obté un Document de Projecte OLAP que contindrà les informacions necessàries per a la implementació dels Data Marts i els cubs amb les seves dimensions i mesures.

• Projecte OLTP OLAP : En aquesta fase es preparen els SGBDs i el servidor OLAP per a la migració de les dades necessàries a O3.

Al final d'aquesta fase s'obté un projecte OLTP OLAP que contindrà les informacions necessàries per a l'extracció de dades dels bancs de dades corporatius.

2.1.3. Projecte de visualització

Finalment es creen les visions i s'implementen els accessos dels usuaris i els cubs de Data Marts ja creats. S'ha de tornar a l'usuari final per a que doni la seva aprovació.

Al final d'aquesta fase s'obté un Document de Projecte OLTP OLAP que relaciona cada usuari amb els Data Marts, cubs, dimensions i mesures que utilitza.

Metodologia Ràpida de SAS

La metodologia ràpida de SAS és un mètode iteratiu i evolucionari que divideix projectes potencialment llargs en projectes molt més petits i amb menys riscos. Cada subprojecte d'aquests es construeix sobre l'entorn previ d'emagatzemament tenint molta cura en fer que continui adpatant-se a les necessitats de l'empresa. Cada sub-projecte construit, ràpidament pot afegir capacitats adicionals als usuaris d'aquesta, els quals poden estar explotant l'emmagatzemament de dades molt més ràpid que si s'hagués utilitzat un sistema tradicional en cascada.

Així es podria dir que una implementació ràpida, seguint és clar una metodologia, significa obtindre resultats mesurables més ràpidament.

S'ha de tindre molt clar des del principi que molts projectes d'emmagatzemament de dades fracassen a causa d'una falta de participació en aquests per part de l'usuari des de l'inici al final. Per això, en aquesta metodologia participen “sponsors” en els assesorament d'alt nivell, requeriments d'extracció i modelació de l'empresa, que representen a tota la organització i es realitzen revisions regulars per a assegurar-se que l'emmagatzemament continua donant resultats útils.

Aquesta metodologia doncs, proporciona un marc flexible i consistent per a planificar, dissenyar, implementar i revisar els beneficis del DW. A més, facilita la planificació per al manteniment i l'administració del DW.

Un aspecte important de la metodologia és l'ús de rols de projecte per a assegurar que les tasques es porten a terme i que els objectius del projecte s'aconsegueixen.

Els rols de projecte que s'utilitzen són :

• Sponsor executiu : Almenys un executiu amb experiència és responsable de tota la iniciativa d'emmagatzemament i s'assigna un director a cada àrea diferent del projecte. Pot participar un comité de seguiment executiu per a assegurar que el projecte de DW no interfereix amb altres projectes de l'empresa.

• Direcció del projecte : Generalment aquest rol el compleix un grup. Pot incloure un director de projecte amb experiència. Aquest grup és el responsable de supervisar tot el projecte, controlant el progrés del projecte en temps i assegurant que els altres membres de l'equip saben quins són els seus rols i funcions.

• Arquitecte de Warehouse : Aquesta persona és responsable del disseny lògic i físic de l'entorn d'emmagatzematge, incloent la infraestructura tècnica i és a qui s'ha de consultar en cas d'afegir nous components.

• Administrador de Warehouse : Se n'ha d'assignar almenys un. Aquesta persona supervisa i potser desenvolupa la definició, extracció, transformació, validació i càrrega del magatzem físic adequant-se als requeriments tècnics. Aquest rol ha d'estar present a través de tot el cicle de vida del projecte.

• Administrador de dades : És l'encarregat de definir les normalitzacions de les dades en un entorn d'organització de la informació. Aquest rol és crític per a l'administració de la qualitat de les dades.

• Equip de construcció.

• Equip IT : Són especialistes en proveir la planificació, la xarxa, l'emmagatzemament i altres sistemes de suport.

• Equip de direcció de qualitat : Aquest equip és el responsable d'assegurar que la qualitat està fixada, documentada i dirigida en tots els aspectes de l'entorn d'emmagatzemament, incloent les dades, els processos i les aplicacions d'explotació.

• Usuaris representants de l'empresa : Els usuaris finals de l'empresa informen a l'equip de projecte dels requeriments de l'emmagatzemament i ajuden a assegurar la qualitat d'aquest. Són aquests els que han de ser els experts durant l'extracció de requeriments, els que controlin les fases següents i els que revisin els plans de projecte i les estratègies durant les fases de la metodologia.

La metodologia ràpida de SAS consta de les següents fases :

Valoració

Aquesta fase és crucial per a esbrinar fins a on la organització està disposada a comprometre's per a un rpjecte da DW d'aquestes característiques. Si la organització no està disposada a comprometre's, s'haurà de postpondre el projecte.

L'equip de valoració pot recomanar un nombre de fases per a assolir aquesta disposició.

Requeriments

La fase de requeriments esbrina totes les necessitats de l'entorn de DW. En aquesta fase s'obtenen tant els requeriments d'usuari com del sistema (també la infraestructura). Es fan entrevistes, tallers i anàlisi dels diversos documents i sistemes ja existents per a confirmar les necessitats actuals.

D'aquesta fase s'obté el document de requeriments, que serà revisat per tots els grups afectats. Aquest document inclou la identificació dels objectius de l'empresa i l'anàlisi tècnic. També poden incloure's recomanacions, com ara els nombre de projectes i la prioritat de cada un.

Disseny

La fase de disseny es centra en construir un sol subprojecte alhora. Les activitats d'aquesta fase són :

• Anàlisi i requeriments detallats per a cada subprojecte.

• Dissenys lògic i físic detallats per al model de dades.

• Especificació detallada del model de procès per a l'extracció, transformació i càrrega de dades.

• Creació del model d'aplicació o selecció de les eines d'explotació.

• Disseny dels aspectes adicionals com ara la seguretat i els model de meta-data.

El document de requeriments s'utilitza com a entrada a aquesta fase, i s'obté un document detallat del disseny per al subprojecte seleccionat. En les successives construccions, el document detallat del disseny dels anteriors s' utilitza com a entrada de l'actual; d'aquesta manera s'assegura que el treball actual incorpora decisons d'implementació prèvies.

Tant el director del projecte com l'arquitecte de warehouse han d'estar involucrats en aquesta fase. L'administrador de dades, el director de construcció i el personal de l'equip poden ser consultats i els usuaris representants de l'empresa i tècnics revisen el perfil del disseny.

Construcció

Durant la fase de construcció, els equips d'implementació codifiquen i omplen el warehouse amb les dades i desenvolupen les aplicacions per als usuaris finals i creacions d'informes. Els usuaris de l'empresa i l'organització IT testejen rigurosament el warehouse i les aplicacions per a verificar que tots els criteris es compleixen.

Un aspecte important d'aquesta fase és la preparació per al rodatge dels sistema de producció. El consultaor de DW i els directors de projecte revisen els processos de creació, actualització i manteniment dels warehouse amb l'administrador de warehouse. En aquesta fase es prepara un document de manteniment que conté la informació per a una referència futura.

Implantació

La fase d'implantació consta en fer el rodatge dels DW i de les aplicacions dels usuaris finals. Per a una bona acceptació del projecte, els usuaris han d'haver sigut formats correctament i les dades han de ser accessibles ràpidament.

Revisió

En la fase de revisó es duen a terme tres accions per a cada sub-projecte :

• Seguiment de la fase de construcció per a assessorar les processos d'implementació i aprendre dels avenços i retarssos.

• 3-6 mesos després revisar la fase d'implantació i assegurar que els usuaris poden accedir al sistema sense cap tipus de probelma.

• 18-24 mesos després de la construcció inicial mesurar els beneficis quantitatius i assegurar-se que el DW continua adaptant-se als requeriments de l'empresa.

Manteniment i Administració

CONCLUSIONS

Un disseny que no contempli els fonaments de DW treu total importància a la resta dels aspectes com ara la discussió de si s'ha d'associar a un repositori de dades MDBMS (Multidimensional DataBase Management System) o RDBMS (Relational DataBase Managemtn System).

No existeix el producte que sense un disseny adequat pugui solucionar la problemàtica de la presa de decisions, és per això que la metodologia de treball per a un DSS contempla implementacions progressives.

S'ha pogut veure en aquest treball que les metodologies que fan servir dos empreses diferents, tenen punts en comú, i que són els que s'han donat a classe, entre d'altres.

Així doncs, és obvi que és necessari adoptar una metodologia per a dissenyar i construir el DW, ja que es tracta d'un projecte molt gran i complex perque treballa amb gran quantitat de dades i tant el seu disseny com la seva implementació demanen tindre-ho en compte ; generalitzant, es pot dir que per a qualsevol projecte informàtic fa falta adoptar una metodologia que ens assegurarà assolir els objectius del projecte i per tant el seu èxit.