Modelo para la Construcción de un Almacén de Datos (Data Warehouse)-Edición Única

152  Descargar (0)

Texto completo

(1)

BIBLIOTECAS DEL TECNOLÓGICO DE MONTERREY

PUBLICACIÓN DE TRABAJOS DE GRADO

Las Bibliotecas del Sistema Tecnológico de Monterrey son depositarias de los trabajos recepcionales y de

grado que generan sus egresados. De esta manera, con el objeto de preservarlos y salvaguardarlos como

parte del acervo bibliográfico del Tecnológico de Monterrey se ha generado una copia de las tesis en

versión electrónica del tradicional formato impreso, con base en la Ley Federal del Derecho de Autor

(LFDA).

Es importante señalar que las tesis no se divulgan ni están a disposición pública con fines de

comercialización o lucro y que su control y organización únicamente se realiza en los Campus de origen.

Cabe mencionar, que la Colección de

Documentos Tec,

donde se encuentran las tesis, tesinas y

disertaciones doctorales, únicamente pueden ser consultables en pantalla por la comunidad del

Tecnológico de Monterrey a través de Biblioteca Digital, cuyo acceso requiere cuenta y clave de acceso,

para asegurar el uso restringido de dicha comunidad.

El Tecnológico de Monterrey informa a través de este medio a todos los egresados que tengan alguna

inconformidad o comentario por la publicación de su trabajo de grado en la sección Colección de

Documentos Tec

del Tecnológico de Monterrey deberán notificarlo por escrito a

(2)

Modelo para la Construcción de un Almacén de Datos (Data

Warehouse)-Edición Única

Title

Modelo para la Construcción de un Almacén de Datos

(Data Warehouse)-Edición Única

Authors

Adrián Enrique Amozorrutia Bautista

Affiliation

Tecnológico de Monterrey, Universidad Virtual

Issue Date

1999-12-01

Item type

Tesis

Rights

Open Access

Downloaded

18-Jan-2017 20:38:47

(3)
(4)

M O D E L O P A R A L A C O N S T R U C C I Ó N D E UN A L M A C É N DE D A T O S (DATA W A R E H O U S E )

I T E S M

Tesis presentada

por

ADRIAN ENRIQUE AMOZORRUTIA BAUTISTA

P r e s e n t a d a ante la Dirección Académica d e la Universidad Virtual del Instituto Tecnológico y d e Estudios Superiores de Monterrey c o m o requisito parcial para

optar al título d e

M A E S T R O E N A D M I N I S T R A C I Ó N DE T E C N O L O G I A S DE I N F O R M A C I Ó N

Diciembre de 1999

(5)

M O D E L O P A R A L A C O N S T R U C C I Ó N DE UN A L M A C É N DE D A T O S (DATA W A R E H O U S E )

T e s i s presentada

por

ADRIAN ENRIQUE A M O Z O R R U T I A B A U T I S T A

Aprobada en contenido y estilo por

M.C. Francisco J o s é Camargo Santacruz A S E S O R PRINCIPAL.

M.C. Humberto C á r d e n a s Anaya SINODAL.

M.C. Luis Humberto Franco C á r d e n a s SINODAL.

Dra. María del Socorro Marcos Kahn Programa de Graduados en Ingenierías y

(6)

A

(7)

RESUMEN

El objetivo principal de este trabajo e s crear un modelo para la construcción

de un almacén de datos y así a partir de este desarrollar la c a p a de toma de

decisiones y conocimientos de una e m p r e s a , para lograrlo s e tuvo que revisar

literatura referente a este t e m a a d e m á s de que s e implementaron varios c a s o s

para construirlo y s e utilizaron conocimientos y a adquiridos a lo largo de mi carrera

profesional en el área. P o r lo tanto el modelo construido e s una m e z c l a de

experiencia propia y de otros m o d e l o s y fuentes bibliográficas e s p e c i a l i z a d a s en el

tema.

L a contribución e s p e r a d a e s aportar a las e m p r e s a s de una herramienta

valiosa que les permita integrar su información en un almacén de datos y planear

con este modelo la creación de la c a p a de toma de decisiones así c o m o la de

conocimientos de s u negocio. A d e m á s de proveer a c c e s o rápido a la información

de la organización. Y contar c o n un almacén consistente para la toma de

decisiones en línea para poderlo publicar y distribuir la información con claridad y

(8)

ÍNDICE DE CONTENIDO

Capítulo Página

1. I N T R O D U C C I Ó NzyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA 1

2. IMPORTANCIA, C O N C E P T O S , O B J E T I V O S Y BENEFICIOS 6

2.1 Introducción 6 2.2 Diferencias entre Data W a r e h o u s e y sistemas operacionales 8

2.3 Definición 14 2.4 Objetivos 15 2.5 E l desarrollo del almacén 16

3. P L A N E A C I Ó N Y O R G A N I Z A C I Ó N 17

3.1 Introducción 17 3.2 L a instrumentación del almacén 20

3.3 E l reto 22 3.4 E t a p a s de la planeación y organización 22

3.5 Definición del objetivo, beneficios y justificación del proyecto 23

3.6 L o s beneficios 2 3 3.7 Criterios de éxito 24

3.8 R i e s g o 26 3.9 Identificación de usuarios 2 7

3.10 Selección / confirmación de la arquitectura de sistemas 28 3.11 Selección / confirmación de las herramientas de diseño,

extracción, transformación, explotación y desarrollo. 31

3.12 Selección del equipo de trabajo 31 3.13 Creación del plan de trabajo 32

4. REQUERIMIENTOS 32

4.1 Introducción 32 4.2 Entrevistas 3 3 4.3 Analistas y usuarios dirigidos a funciones de negocios 35

4.4 G e r e n t e s dirigidos a funciones de negocios 36 4.5 Analistas y usuarios relacionados a funciones de negocios 36

4.6 ¿Qué preguntar al usuario final? 39

4.7 Un análisis a d e c u a d o 41 4.8 Análisis de negocio 41 4.9 Información específica de datos 42

4.10 Documentación 44 4.11 E t a p a s para la fase de requerimientos 4 5

4.12 Determinación / confirmación de la comunidad de usuarios 4 5

(9)

4.15 Criterios para las herramientas de explotación y distribución 4 7

4.16 Cálculos 4 7 4.17 R e g l a s de cálculos 4 8

4.18 Navegación 4 9 4.19 Visualización 49 4.20 Triggers, A g e n t e s y Alertas 50

4.21 G r o u p w a r e 50 4.22 S e g u r i d a d 51 4.23 G o b i e r n o de A p l i c a c i o n e s 51

4.24 C a r g a de Información al metadata sobre el proceso 51

5. D I S E Ñ O D E L D A T A W A R E H O U S E 52

5.1 Introducción 56 5.2 E t a p a s para el diseño del Data W a r e h o u s e 56

5.3 Elaboración del cuadro elementos para el e s q u e m a estrella 56

5.4 Construcción del e s q u e m a lógico 5 7

5.5 P a s o s para modelar 57 5.6 Criterios para la selección de una herramienta de modelaje 58

5.7 Construcción del e s q u e m a físico 58

6. T R A N S F O R M A C I O N (Extracción, transformación y carga) 59

6.1 Introducción 59 6.2 E t a p a s de la transformación de datos 60

6.3 Análisis de r e s p o n s a b l e s de datos 60 6.4 Análisis de fuentes de datos 61 6.5 Desarrollo de la matriz de responsables de datos 61

6.6 Desarrollo de la matriz de fuentes de datos 62 6.7 Desarrollo de la matriz de fuentes de datos contra

requerimientos 62 6.8 Definición de la estrategia de transformación de datos 6 3

6.9 Identificación de los candidatos a ser s i s t e m a s de legado 64

6.10 Cuestionario de criterios 64 6.11 D o c u m e n t o s de fuentes de registro 64

6.12 Análisis de las fuentes 65 6.13 Revisión del "sourcing" de datos 66

6.14 Diseño de conversión de datos 66 6.15 Obtención (sourcing) inicial de datos 66 6.16 C a r g a de información al metadata sobre el proceso 68

7. E X P L O T A C I Ó N Y DISTIBUCIÓN 69

7.1 C a p a de toma de decisiones 70 7.2 C a p a de conocimientos 71

(10)

9.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA A P L I C A C I Ó N DE C A S O SzyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA 73

C A S O 1: Construcción de un Data W a r e h o u s e para la BCI del I T E S M - 74 C E M

C A S O 2: Construcción de un Data W a r e h o u s e para la Dirección de 91 Informática del I T E S M - C E M

C A S O 3: Construcción del un Data W a r e h o u s e en Distribution S e r v i c e s 112 Ltd. para el proyecto C O M E R S A .

C O N C L U S I O N E S 135

(11)

CAPÍTULO 1

Introducción

E n la actualidad la competitividad y eficiencia de las e m p r e s a s

d e p e n d e en gran m e d i d a de la rapidez con que s e p u e d a obtener

información consistente para la toma de decisiones. A u n q u e s e cuente con

a c c e s o a la información de la operación diaria, esta no e s suficiente. P a r a

analizar tendencias, desempeño y hacer mejores decisiones de negocio s e

requiere un fácil y rápido a c c e s o a la información corporativa. L a solución e s

un almacén de datos. U n almacén d e datos integra toda la información de la

e m p r e s a y la p o n e disponible a toda la gente, esta información forma parte

de varias fuentes operacionales por lo tanto debe de haber un proceso de

extracción, limpieza, transformación, c a r g a a un receptáculo donde

cualquiera p u e d a tener a c c e s o a ella o ésta p u e d a ser distribuida a la

organización y así iniciar el p r o c e s o de toma de decisiones en toda la

e m p r e s a .

S o b r e definiciones del concepto de data warehouse hay

diferentes, sin embargo, las definiciones sobre el tema tres qué s o n las

(12)

• E s el lugar d o n d e los directivos de la e m p r e s a pueden a c c e d e r

información para realizar p r o c e s o s gerenciales. (Oracle, C o m p u t e r

Select).

• U n almacén de datos que las e m p r e s a s construyen y d o n d e

depositan s u información c o m o un activo valioso para que ellos puedan

extraer conocimiento y entendimiento de la operación y desempeño de su

negocio. (Logic W o r k s , C o m p u t e r Select).

• E s una b a s e de datos analítica que e s u s a d a c o m o la b a s e

tecnológica para los s i s t e m a s de soporte a la toma de decisiones

(Vidette, P o e , 1 9 9 6 )

El objetivo principal de este trabajo e s crear un modelo para la construcción

de un almacén de datos y así a partir de este desarrollar la c a p a de toma de

d e c i s i o n e s y conocimientos de una e m p r e s a , para lograrlo s e tuvo que revisar

literatura referente a este t e m a además de que s e implementaron varios c a s o s

para construirlo y s e utilizaron conocimientos y a adquiridos a lo largo de mi carrera

profesional en desarrollo de software. P o r lo tanto el modelo construido e s u n a

m e z c l a de experiencia propia y de otros m o d e l o s y fuentes bibliográficas

(13)

A l final de la tesis s e entregará c o m o producto final un modelo que apoye a

la construcción de un almacén de datos (data warehouse) y a partir de este

m o d e l o poder construir la c a p a de toma de decisiones y conocimientos de una

e m p r e s a .

L a contribución e s p e r a d a e s aportar a las e m p r e s a s de una

herramienta v a l i o s a que les permita planear con este modelo la creación de

la c a p a d e t o m a de d e c i s i o n e s así c o m o la de conocimientos de su negocio.

A d e m á s de proveer a c c e s o rápido a la información de la organización. Y

contar c o n un almacén consistente para la toma de decisiones en línea para

poderlo publicar y distribuir la información con claridad y precisión.

E n el capítulo uno s e habla principalmente sobre el marco teórico

describe principalmente los conceptos o terminología que gira en tomo al

t e m a d e a l m a c e n e s de datos c o m o s o n : sistemas de apoyo a la toma de

d e c i s i o n e s , s i s t e m a s operacionales, O n L i n e Analytical P r o c e s s del análisis

multidimensional entre otros conceptos. Y s e expone el modelo para la

(14)

E s t a e s la f a s e de planeación y organización con la cual s e c o m i e n z a el

modelo y consiste en c o n o c e r c u a l e s s o n las n e c e s i d a d e s de nuestro usuario,

entender el negocio y definir objetivos, beneficios, flujo de la información y la

arquitectura e infraestructura, así m i s m o establecer una aplicación que s e a la guía

para el desarrollo del proyecto y que e s t a s e siga de una m a n e r a tal que no s e

pierda la principal preocupación de la m i s m a , s e debe establecer u n a línea de

trabajo y s e d e b e mantener e s a m i s m a línea todo el tiempo.

Requerimientos en esta fase s e realizan todas las entrevistas que

proporcionen la información relacionada c o n la construcción del almacén de datos,

e s decir s e determinan e s forma específica las n e c e s i d a d e s de información. Esto

e s de s u m a importancia para poder c o n o c e r la forma en c o m o fluye la información

dentro de la e m p r e s a y así construir un modelo a d e c u a d o a las n e c e s i d a d e s de

información del negocio.

E n la construcción del w a r e h o u s e s e hace la esquematización

correspondiente a los distintos d i a g r a m as estrella que seguirán los datos y la

forma en c o m o s e relacionarán entre sí, estos diagramas son información

relevante para c o n o c e r c o m o s e representará la información internamente en el

almacén. P o r lo tanto la parte fuerte de esta fase e s modelar a partir de los

elementos de información que s e hayan identificado en la fase de requerimientos y

(15)

E n la f a s e de transformación s e d e b e identificar las fuentes origen de donde

se v a n a extraer los datos, así m i s m o s e determinan procesos de transformación

de datos p a r a cargarlas al almacén. E n esta fase s e establecen los estándares a

seguir en cuanto a la forma en que s e d e b e n introducir los datos en el w a r e h o u s e

para que toda la información incluida en el warehouse mantenga los m i s m o s

estándares y no s e tengan problemas en cuanto a la compatibilidad de los

mismos. E n conclusión s e lleva a c a b o la arquitectura e infraestructura del

almacén.

L a explotación y distribución consiste en determinar las herramientas para

poder hacer la explotación de la información a l m a c e n a d a en el almacén de datos,

las distintas formas en c o m o s e harán las búsquedas de datos y la forma en c o m o

se deberán operar las políticas de a c c e s o en el almacén de datos.

E n el capítulo de administración y control s e proponen m e c a n i s m o s para

llevar u n a documentación de todo el proceso para la construcción del almacén así

c o m o ciertas aplicaciones para controlar los c a m b i o s y administrar los

requerimientos.

E n el capítulo de aplicación de c a s o s s e presenta un resumen sobre las

fases de c a d a proyecto d o n d e s e aplica el modelo y s u s resultados finales. P o r

(16)

CAPÍTULO 2

Importancia, conceptos, objetivos y beneficios

2.1 Introducción

Para competir dentro del ambiente de negocios actual y en constante

cambio, una empresa no se puede arriesgar a perder el tiempo entre montañas de

información en busca de los datos que se necesitan para tomar decisiones críticas

de negocios. Hoy en día, no es suficiente contar con el acceso a la información de

las operaciones diarias. Para dar seguimiento a las tendencias, analizar el

rendimiento y tomar mejores decisiones de negocios, se necesita de un acceso

fácil y rápido a los datos corporativos y a la información competitiva. La solución

es construir un almacén de datos (data warehouse) y así crear la capa de toma de

decisiones y de conocimientos de una empresa. Por lo tanto, en un país que sufre

y sufrirá cambios intensos, internos como externos, las necesidades de

información serán dinámicas y la gente que toma decisiones necesitará una

respuesta rápida a sus requerimientos para tomar decisiones, además de contar

con herramientas que les permitan hacer un análisis en tiempo real y así llevar a

cabo una evaluación del desempeño y comportamiento de la empresa y su

entorno, mediante indicadores de negocios. (OpenWorld, 1997)

(17)

L o s s i s t e m a s de a p o y o a la toma de decisiones (Decisión Support Systems)

han sido el resultado de la preocupación de los departamentos de tecnología de

información de las e m p r e s a s d e s d e h a c e varios años. P e r o en los últimos treinta

años han mostrado u n a evolución que v a d e s d e la utilización de reportes c r e a d o s

por un mainframe c o n b a s e en un archivo maestro, hasta el surgimiento de los

a l m a c e n e s de datos (data warehouses). ( W . H . Inmon, 1996)

L a llegada de los s i s t e m a s manejadores de b a s e s de datos en los 70, así

c o m o de las herramientas para usuarios finales, dieron a las organizaciones u n a

habilidad única para a c c e s a r y controlar datos directamente (Sprangue, Ralph H.,

Watson, Hugh, 1993). S e formaron varios centros de información, ofreciendo a los

usuarios finales c a p a c i d a d e s de extracción de e s a información a través de

programas, que m á s adelante s e volvieron insuficientes pues no podían realizar

las siguientes funciones:

• Validar las fuentes de los datos, y a fueran internas o externas.

• Validar el margen de tiempo que representaban los datos.

• Validar el p r o c e s o de transformación que habían llevado a c a b o los datos.

• T e n e r u n a definición universal de lo que contenía el centro de extracción de

información.

• T e n e r u n a localidad s o l a y unificada para ver la información originada por

(18)

E s t o s s i s t e m a s han evolucionado considerablemente durante los últimos

años, teniendo c o m o estado actual de evolución el data warehouse o almacén de

datos, considerado hoy c o m o la mejor solución en arquitectura para el soporte a la

toma de decisiones. S i g u i e n d o esta línea de evolución p o d e m o s notar que están

a punto de a l c a n z a r un equilibrio y entrar a una fase en la cual podrán ganar

madurez. E l siguiente crecimiento significativo en ellos sería la fusión de distintas

tecnologías de apoyo a las t o m a s de decisiones conocidas ( O L A P / R O L A P / A d H o c

Query, Report Writing y D a t a Mining) para convertirse en una solución más amplia

para los c o n s u m i d o r e s de datos, d e s d e analistas de negocios hasta altos

ejecutivos de las e m p r e s a s . ( W . H . Inmon, 1996)

2.2 Diferencias entre data warehouse y sistemas operacionales.

U n a de las r a z o n e s más importantes detrás del surgimiento de una data

w a r e h o u s e e s la n e c e s i d a d de a c c e d e r a la información, e s decir, que la b a s e de

datos c u a n d o reciba un query no devuelva datos, sino información, en oposición al

a c c e s o operacional a datos corporativos. L o s datos operacionales describen el

estado actual de un negocio, y la mayoría de las aplicaciones operacionales

existen para resolver preguntas b a s a d a s en el funcionamiento diario de la

e m p r e s a . E l a c c e s o a la información que maneja una data warehouse e s utilizado

para apoyar consultas de alto nivel, así c o m o la planeación y las actividades de

decisiones estratégicas. E n a c c e s o a la información generalmente s e tiene que

(19)

P o c a s a p l i c a c i o n e s soportan preguntas de esta naturaleza y la mayoría de

las v e c e s los gerentes tienen que tomar la decisión que mejor les p a r e z c a .

Durante m u c h o s años los departamentos de tecnología de información han tratado

de satisfacer tanto los requerimientos de procesamiento operacional c o m o de

información d e s d e u n a s o l a fuente de datos corporativos, con éxito limitado

d e s d e un punto de a p o y o a las decisiones. El enfoque del data warehousing h a

traído c o n s i g o un reconocimiento de parte del la industria de T.I., de que los

s i s t e m a s informacionales y operativos s o n fundamentalmente diferentes e

incompatibles. L o s requerimientos para c a d a tipo de sistema s o n diferentes y c a d a

s i s t e m a presenta las siguientes diferencias:

M u c h a s aplicaciones operacionales contestan las siguientes preguntas: El

pedido a sido expedido ¿El cliente pagó su factura? ¿Cuál e s el estatus de un

pedido d a d o ? ; y las aplicaciones operacionales las contestan bien. L o s datos

o p e r a c i o n a l e s describen el estado actual del negocio.

E n lo que refiere al almacén de datos, s e u s a para respaldar la toma de

d e c i s i o n e s d e alto nivel, planeación y d e c i s i o n e s estratégicas para soporte de la

t o m a d e d e c i s i o n e s . E l a c c e s o a la información usualmente maneja grandes

(20)

¿Cuál e s el impacto en el negocio si las ventas directas s e reducen en un

2 0 % ?

D I F E R E N C I A S O P E R A C I O N A L A L M A C E N D E D A T O S Contenido de datos V a l o r e s actuales Archivados y calculados Organización de datos Aplicación por aplicación A r e a s específicas de la

e m p r e s a Naturaleza de los datos Dinámicos Estáticos Formato de la estructura

de los datos

C o m p l e j a Simple

Probabilidad de a c c e s o Alta M o d e r a d a a alta Actualización de los datos Actualizada en un c a m p o

por registros.

A c c e s a d a y manipulada, no hay actualización directa

Uso P r o c e s o s repetitivos P r o c e s o s analíticos Figura 1zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA. diferencias entre data warehouse y sistemas operacionales.

P o r lo tanto, un s i s t e m a operacional o de procesamiento en línea ( O L T P :

On-line Transaction Processing), e s un s i s t e m a tal c o m o el de administración de

recursos h u m a n o s , de asignación de créditos bancarios, de recuperación y control

de cartera o d e control de seguros, y su función principal e s dar el soporte a las

necesidades diarias de la e m p r e s a ; s o n s i s t e m a s normalmente optimizados para

el manejo de un conjunto predefinido de transacciones. L a mayoría de los

sistemas existentes dentro de las organizaciones s o n sistemas operacionales

orientados al manejo de transacciones. E s t a s aplicaciones representan, en sí

mismas, s i s t e m a s aislados cuyo contenido de datos fue diseñado para atender los

requerimientos específicos delimitados por el a l c a n c e de la aplicación. ( E D S ,

(21)

E s t o s s i s t e m a s generan los datos operacionales, los c u a l e s s e caracterizan

por ser datos detallados, no redundantes, que s e actualizan constantemente y que

reflejan valores al período de tiempo actual. E s t o s datos serán transformados para

ser el insumo del data w a r e h o u s e .

P o r ello, e s necesario analizar y definir cuidadosamente de los sistemas

o p e r a c i o n a l e s aquellos datos que representen la e s e n c i a o filosofía del negocio

que s e pretenda manejar, para que s e transformen y s e transfieran al data

w a r e h o u s e .

Mediante e s e proceso a g r e g a m o s valor a los datos convirtiéndolos en

información y haciéndolos de utilidad para el manejo del negocio.

C o n b a s e en lo anterior, p o d e m o s identificar que los s i s t e m a s operacionales

manejan los datos detallados y estructurados para registrar la operación de la

organización, y por lo tanto, no están preparados para facilitar su explotación y la

toma de d e c i s i o n e s .

C o n s i d e r a n d o el e s q u e m a anterior, el análisis de la información más

relevante de la operación de la e m p r e s a , su interpretación y la t o m a de decisiones

b a s a d a en d i c h a información, resulta un elemento clave en la búsqueda y solución

(22)

P a r a el a p o y o de este proceso, en los últimos años han surgido una gran

cantidad de a p l i c a c i o n e s de tecnología y s i s t e m a s de información, c o m o s o n los

sistemas de información ejecutiva c o n o c i d o s c o m o S I E ' s o E I S ' s y los sistemas de

soporte a la t o m a de d e c i s i o n e s c o n o c i d o s c o m o D S S .

L o s s i s t e m a s de información gerencial (MIS) están orientados a producir

reportes que organizan información (un reporte de requerimientos de materiales, la

elaboración de e s t a d o s financieros, etc.)

L o s s i s t e m a s para soporte de d e c i s i o n e s ( D S S ) o los s i s t e m a s expertos,

tienen c o m o objetivo apoyar la toma de decisiones mediante la aplicación de

modelos matemáticos y estadísticos, o de conocimiento específico a un problema

particular. L o s S i s t e m a s de Información Ejecutiva tienen c o m o objetivo primordial

proveer d e t o d a la información n e c e s a r i a a los ejecutivos de alto nivel para

apoyarlos e n la t o m a de decisiones. E n e s e sentido, un S I E e s un sistema de

información que permite a los ejecutivos a c c e s o rápido y efectivo a información

compartida, crítica para el negocio, utilizando interfaces gráficas. L a interfaz del

usuario proporcionada por este tipo de s i s t e m a s e s más sofisticada que la de las

(23)

L a minería de datos e s el descubrimiento automatizado de patrones y

relaciones en las b a s e s de datos. A diferencia de sistemas de consulta,

aplicaciones O L A P (OnLine Analytical P r o c e s s ) o del análisis multidimensional, los

cuales requieren u n a gran interacción del hombre para encontrar información en

una b a s e de datos, la minería de datos hace uso de técnicas a v a n z a d a s de

estadística y del aprendizaje de las máquinas para descubrir h e c h o s en grandes

b a s e s d e datos. (Thomsen Erik, 1997)

U n s i s t e m a de minería de datos está formado por varios programas de

cómputo, q u e realizan, de m a n e r a automática, la búsqueda en una b a s e de datos,

de tendencias, d e s v i a c i o n e s , anomalías, patrones y situaciones "interesantes."

L a s redes neuronales son una tecnología de procesamiento de información

de inteligencia artificial que b u s c a reproducir el funcionamiento del cerebro

humano respecto a la forma c o m o p r o c e s a el conocimiento.

L o s s i s t e m a s expertos son c a p a c e s de hacer inferencias siguiendo p a s o s

c o m p a r a b l e s a los que sigue un especialista (médico, biólogo, geólogo,

matemático, etc.), c u a n d o resuelve un problema propio de su disciplina.

C u a n d o los datos no s e encuentran a c c e s i b l e s y el tiempo e s un factor

crítico, las d e c i s i o n e s d e b e n llevarse a c a b o en suposiciones sin b a s e s y en la

intuición. P o r ello, e s fundamental el contar c o n una visión corporativa de los datos

(24)

P a r a proveer datos a los s i s t e m a s de soporte a la toma de decisiones, los

datos operacionales relevantes s e extraen de las aplicaciones b a s a d a s en

transacciones. E n t o n c e s s o n transformados a un formato a d e c u a d o a la toma de

d e c i s i o n e s y alimentan el almacén de datos corporativo. A partir de ahí s e facilita

la explotación y análisis d e la información d e s d e distintos enfoques o tipos de

sistemas.

2.3 Definición

El Data w a r e h o u s e e s un almacén de datos que las e m p r e s a s construyen y

d o n d e depositan s u información c o m o un activo valioso para poder luego extraer

conocimiento y entendimiento de la operación y desempeño de su negocio. (Logic

(25)

2.4 Objetivos

• P r o v e e r a c c e s o a la corporación o a los datos de la organización. El almacén

de datos d e b e permitir a los usuarios conectarse con s u s computadoras

p e r s o n a l e s y a s e a dentro o fuera de la e m p r e s a . L a s c o n e x i o n e s deben ser

inmediatas, en d e m a n d a y c o n alto desempeño.

• C o n s i s t e n c i a en los datos del almacén. L a consistencia s e refiere a obtener los

m i s m o s h e c h o s en cualquier punto del tiempo. Además, d e b e considerar la

consistencia en la actualización de la información.

• Slice a n d dice (rebanar y picar). D e b e proveer facilidades de combinar

diferentes c o n c e p t o s de negocio.

• A d e m á s de datos d e b e proporcionar herramientas para realizar análisis en

línea.

• Publicar y distribuir información c o n calidad y precisión (atributos de la

información).

• D e b e ser un medio confiable para una reingeniería de negocios.

• D e b e proponer la construcción de u n a arquitectura operativa en c a s o de que

no existan los s i s t e m a s fuentes que proporcionen información al almacén de

(26)

2.5 El desarrollo del almacén

El p r o c e s o de desarrollo del almacén está dividido en los siguientes componentes.

Componente Descripción

Organización y

Planeación Definición del objetivo, beneficios y justificación del proyecto Identificación de procesos de alto nivel del negocio y flujo de información

- Determinación de criterios de éxito Determinación de riesgos del proyecto - Identificación de tipos de usuario - Selección del equipo de trabajo

- Selección / confirmación de la arquitectura de sistemas

Selección / confirmación de las herramientas de diseño, extracción, transformación, explotación, distribución y desarrollo - Creación del plan de trabajo

Requerimientos - Determinación / confirmación de la comunidad de usuarios Determinación / confirmación de los requerimientos

- Confirmación de las herramientas de explotación y distribución. - Carga de información al metadata sobre el proceso

Construcción del almacén - Creación del modelo de datos lógico - Creación del modelo de datos físico

- Carga de información al metadata sobre el proceso Transformación

(Extracción,

transformación y carga)

- Análisis de responsables de datos - Análisis de fuentes de datos

- Desarrollo de la matriz de responsables de datos (metadata) - Desarrollo de la matriz de fuentes de datos (metadata)

Desarrollo de la matriz de fuentes de datos contra requerimientos (metadata)

Definición de la estrategia de extracción, transformación y carga de datos

- Carga de información al metadata sobre el proceso Explotación y distribución - Construcción de la capa multidimensional

Definición de la estrategia de distribución de la información - Construcción de la capa de conocimientos

- Carga de información al metadata sobre el proceso

Administración y control - Construcción de la aplicación metadata, control de cambios y análisis de impacto.

(27)

CAPÍTULO 3

Planeación y organización

3.1 Introducción

L a s o r g a n i z a c i o n e s que dan inicio a esfuerzos de instrumentación de

a l m a c e n e s d e datos, conjuntan u n a serie de grupos internos divergentes, para

apoyar el desarrollo de tales proyectos. L a s perspectivas de los participantes en lo

que s e refiere a lo que e s un almacén de datos y la mejor m a n e r a de utilizarlo,

pueden variar en gran medida.

• L a g e r e n c i a d e alto nivel s e muestra tradicionalmente sorprendida por el costo

y sin e m b a r g o reconoce la ventaja competitiva que representa.

• L o s administradores de datos inician las labores de diseño tan pronto c o m o el

proyecto e s mencionado.

• L o s usuarios s e muestran e n t u s i a s m a d o s por la habilidad de "Saberlo T o d o y

Verlo T o d o " .

• L o s directores de s i s t e m a s s e muestran e n t u s i a s m a d o s por la posibilidad de

utilizar n u e v o s elementos de "hardware" y "software". M u y pronto los

(28)

T o d o esto p u e d e ser positivo para la organización. Desgraciadamente,

m u c h o s a l m a c e n e s de datos terminan en fracaso cuando los objetivos son vagos

o poco realistas. El camino del éxito está lleno de proyectos fallidos por malas

decisiones, o peor aún, a c a u s a de la indecisión.

L o s a l m a c e n e s de datos pueden a l m a c e n a r varios niveles de detalle de

información. P o r ejemplo, descripciones múltiples, relacionadas a c a d a depósito

hecho en una sucursal bancaria, incluyendo:

• N o m b r e , dirección, números telefónicos

• F e c h a s , cantidades, tipos y t a s a s de interés de transacciones

• Destinatarios de las transacciones, estados de cuenta, otras cuentas bajo el

m i s m o nombre

• Servicios utilizados por el cliente, etc.

El almacenamiento de tales cantidades de información detallada,

rápidamente d a c o m o resultado e n o r m e s a l m a c e n e s de datos del orden de los

"gigabytes". Diseñar un almacén de datos para resolver preguntas específicas

produce a l m a c e n e s de menor tamaño con altos niveles de utilización y mejores

(29)

• ¿Cuáles s u c u r s a l e s tienen el mayor número ventas?

• ¿Cuál e s el motivo de devolución m á s frecuente?

• ¿Cuál fue el efecto de una c a m p a ñ a publicitaria, en la d e m a n d a y oferta de un

producto?

• ¿Cuál e s el porcentaje de gastos por área c o n respecto al total?

E s t a s preguntas identifican la información específica requerida para

resolverlas.

L a s b a s e s de datos s e utilizan para capturar transacciones de negocios en

el instante en q u e ocurren, a través de s i s t e m a s de proceso transaccional en línea

("On-line Transactional P r o c e s s i n g Systems") conocido c o m o O L T P . Esto significa

que la b a s e de datos contiene u n a duración limitada. E s t a s b a s e s de datos son

actualizadas rápidamente por m u c h o s usuarios, día con día.

Un almacén de datos, por el contrario, maximiza el conocimiento a c e r c a de

la información durante el p r o c e s o de análisis en línea ("On-line Analytical

Process") también llamado O L A P . L a información e s a l m a c e n a d a por períodos

más largos, al m i s m o tiempo que la información detallada e s s u m a r i z a d a en

(30)

Existen seis características que distinguen un almacén de datos de otros

tipos d e b a s e s d e datos:

1. U n almacén de datos está s e p a r a d o de los sistemas operacionales.

2. S u propósito e s integrar fuentes de datos.

3. U n almacén de datos puede ser descrito d e s d e el punto de vista de modelo.

4. L a información e s sensitiva al tiempo.

5. L a información e s sensitiva al sujeto (materia, t e m a o colección).

6. E l almacén d e datos e s accesible a usuarios c o n un conocimiento limitado

a c e r c a de estructuras de datos. ( W . H . Inmon, 1996)

3.2 La instrumentación del almacén

L a s instrumentaciones de a l m a c e n e s de datos tienden a diferir de otros

proyectos de administración de información en lo siguiente:

• T i e n d e n a tener u n a mayor visibilidad y sin embargo la gerencia d e m a n d a

mayor asesoría por parte de los expertos.

• T o d a s las n u e v a s herramientas y equipo de cómputo requieren ser e v a l u a d a s y

s e l e c c i o n a d a s . L a selección de herramientas e s probablemente uno de los

p a s o s m á s críticos durante el proyecto de estudio.

• L a instrumentación del almacén requiere de un proceso iterativo que involucre

el tiempo suficiente para llevar a c a b o pruebas, rediseño y una nueva serie de

(31)

• L a s corporaciones en muy raras o c a s i o n e s han tenido experiencias con todos

los c o m p o n e n t e s de un almacén.

• L o s requerimientos más críticos e m p i e z a n a aparecer después de que el

a l c a n c e inicial h a sido definido, lo que provoca rezago.

• Debido a los m e c a n i s m o s de almacenamiento de los a l m a c e n e s de datos,

frecuentemente resulta difícil estimar con exactitud, el tamaño y los

requerimientos de C P U .

• El uso a d e c u a d o d e un sistema de administración de c a m b i o s no e s muy

común. El impacto resultante de la falta de uso de este tipo de sistemas sobre

un almacén de datos, puede ser una serie indiscriminada de c a m b i o s a los

s i s t e m a s o p e r a c i o n a l e s que no s e reflejan a su v e z en el almacén de datos. (

Armstrong, Robert, 1997)

L o s proyectos exitosos d e p e n d e n de los p r o c e s o s y técnicas que luchan por

alcanzar retos c o m o los arriba m e n c i o n a d a s con las siguientes lecciones:

• El reclutamiento del personal a d e c u a d o e s crucial. L o s recursos calificados son

e s c a s o s .

• L a s d e c i s i o n e s técnicas y de negocios están relacionadas y deben ser

c o n s i d e r a d a s paralelamente.

• L a instalación del nuevo medio ambiente técnico implica entrenar nuevamente

al personal técnico y de análisis.

• El desarrollo rápido y el uso de prototipos deben ser combinados con el fin de

(32)

3.3 El reto

El almacén d e datos plantea varios retos a ser instrumentados:

1. D e s e m p e ñ o - El volumen a s o c i a d o con el almacén con frecuencia resulta

impresionante. L o s asuntos relacionados con el almacenamiento y la

organización s o n los más relevantes.

2. E l personal que tiene el conocimiento e s el principal protagonista del almacén

de datos. R e s u l t a m u c h o m á s sencillo agregar espacio en disco y c a p a c i d a d

del p r o c e s a d o r que encontrar personal conocedor.

3. El conjunto de herramientas d e b e recolectar, depurar y analizar la información

requerida.

3.4 Etapas de la planeación y organización

• Definición del objetivo, beneficios y justificación del proyecto

• Identificación de p r o c e s o s de alto nivel del negocio y flujo de información

• Determinación de criterios de éxito

• Determinación de riesgos del proyecto

• Identificación de tipos de usuario

• Selección / confirmación de la arquitectura de sistemas

• Selección / confirmación de las herramientas de diseño, extracción,

transformación, explotación, distribución y desarrollo

• Selección del equipo de trabajo

(33)

3.5 Definición del objetivo, beneficios y justificación del proyecto

Definir el objetivo e s muy importante y a que s e entenderá el propósito

principal del proyecto a d e m á s ayudará a mantener a todo el equipo y al cliente

enfocado hacia un fin c o m ú n y así no crear falsas expectativas.

3.6 Los beneficios

C u a n d o el reto de la instrumentación h a sido superado, los siguientes

beneficios p u e d e n ser obtenidos por la organización entera:

1. L a información estará disponible a tiempo.

2. L o s datos s e convierten en información.

3. L a s d e m a n d a s de los analistas s e verá reducida debido al alto nivel de

organización de la información.

4. El uso de recursos mejorará debido a la extracción eficiente de información de

los s i s t e m a s operacionales.

5. L a información g e n e r a d a por diversos s i s t e m a s será integrada en forma

(34)

L a m e t a tanto del diseñador, c o m o del desabollador del almacén de datos,

consiste en h a c e r que toda la información s e encuentre disponible para todos los

usuarios autorizados. E s t o h a c e posible que todos los usuarios tengan a c c e s o a la

información q u e requieren en un período corto de tiempo, llevar a c a b o su análisis

y tener la certidumbre a c e r c a de su exactitud y consistencia. Finalmente el análisis

iterativo d e datos c r e a la oportunidad para llevar a cabo un análisis conjunto de la

información.

3.7 Criterios de éxito

El criterio d e éxito del almacén de datos e s utilizado para determinar las

ventajas q u e éste traerá a la operación del negocio de la organización que

patrocina el proyecto. L a s expectativas de los usuarios finales son valoradas y

b a l a n c e a d a s contra el costo del desarrollo y la operación del almacén. L o s

criterios de éxito que serán instrumentados por el equipo de diseño y desarrollo

deben e s t a b l e c e r s e en términos cuantificables y sin ambigüedad.

L a información adicional relacionada con el criterio de éxito del almacén de

datos incluye lo siguiente:

• U n conjunto de usuarios finales de acuerdo a lo definido en los requerimientos.

L o s usuarios serán clasificados c o m o Estratégicos (consulta de información),

O p e r a c i o n a l e s (organizadores de datos) y Tácticos (generadores de datos).

(35)

• U n a matriz q u e mostrará las c a p a c i d a d e s de los usuarios (crear, leer,

actualizar y borrar), para c a d a área sujeto del almacén.

• U n a matriz d e usuarios con la velocidad de a c c e s o requerido, frecuencia y

v o l u m e n p a r a c a d a área sujeto del almacén.

• U n a matriz de usuarios con la complejidad de a c c e s o para c a d a área sujeto del

almacén.

S e p u e d e decir que todo almacén d e datos b u s c a el desarrollo de un

modelo de datos expansible que incluya los componentes que a p o y e n las áreas

sujeto d e s i g n a d a s , a saber:

• El desarrollo de reglas relacionadas con el "sourcing" de datos de las áreas

sujeto, una v e z que los requerimientos finales para las m i s m a s hayan sido

terminados.

• El desarrollo d e reglas relacionadas c o n la consistencia del "sourcing" de datos

del almacén, a partir de las áreas sujeto identificadas que soportan las b a s e s

de datos de las aplicaciones.

• El "sourcing" de datos d e s d e las b a s e s de datos de los sistemas operacionales,

hacia las áreas sujeto del almacén de datos, aplicando las transformaciones

(36)

• L a selección e instrumentación de la(s) plataforma(s) de "hardware" y la

infraestructura c o n los recursos suficientes para satisfacer los requerimientos

del almacén de datos.

• L a selección e instrumentación de las herramientas de generación de reportes

("On-line Analytical P r o c e s s " O L A P ) para satisfacer el número y las

características d e los requerimientos de los usuarios finales.

• El desarrollo de un e s q u e m a de a c c e s o y seguridad de usuarios apropiado,

que permita un a c c e s o controlado al almacén de datos.

• El desarrollo de u n a estrategia exitosa de respaldo y recuperación para

soportar el ambiente de trabajo del almacén de datos y del usuario final.

3.8 Riesgos

L o s riesgos permiten valorar el impacto en el éxito del almacén de datos

propuesto, c u a n d o los c o m p o n e n t e s del m i s m o no están disponibles o están

(37)

3.9 Identificación de tipos de usuario

P o d e m o s clasificar a los usuarios del almacén de datos de la siguiente forma:

TIPO DE USUARIO DESCRIPCIÓN CREAR L E E R

ACTUA

LIZAR BORRAR

ADMINISTRADOR DE B A S E DE D A T O S (DBA)

Lleva a cabo el monitoreo de la base de datos correspondiente al Almacén de Datos desde el punto de vista técnico, realizando el mantenimiento de sus componentes con el fin de garantizar su integridad y eficiencia

D E S A R R O L L A D O R Se encarga del desarrollo de aplicaciones encaminadas a la explotación del Almacén de Datos con base en los requerimientos generados por los Usuarios de Reportes Finales

ANALISTA La labor del Analista consiste en generar información para el soporte a la toma de decisiones con base en el análisis directo de los hechos almacenados en el Almacén de Datos

USUARIO D E R E P O R T E S F I N A L E S

Usuarios de reportes predefinidos y

generados periódicamente

Figura 3. Identificación de tipos de usuario

Y dentro de la categoría de usuarios finales s e puede encontrar los siguientes:

• Usuario c a s u a l : a c c e d e solamente en o c a s i o n e s especiales. N e c e s i t a análisis

predefinido y navegación.

• A n a l i s t a d e negocio: u s a la información a diario, pero no tiene el conocimiento

técnico para realizar reportes.

• Usuario poderoso: h a c e s u s propios m a c r o s y reportes, c a m b i a los parámetros

(38)

• Desarrollador de aplicación: proporciona soporte alzyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA negocio, no solo crea

reportes sino que define estándares e identifica dónde y c ó m o ubicar reportes.

(Vidette P o e , 1996)

Lo importante e s que s e identifique a los diferentes tipos de usuario y s e les

proporcionen las herramientas y licencias n e c e s a r i a s para que exploten el

almacén de datos de acuerdo a s u s n e c e s i d a d e s .

3.10 Selección / confirmación de la arquitectura de sistemas

L a arquitectura e s un conjunto de reglas o estructuras que proveen el marco

de soporte para el armazón de todo el diseño del producto o el sistema. Definir el

tipo de arquitectura lógica y física (infraestructura) e s una parte importante del

modelo, y a que de acuerdo al tipo de arquitectura que s e elija s e definirán las

estrategias de extracción, transformación, explotación y distribución del almacén

de datos. (Vidette P o e , 1996)

L o s tipos de arquitectura m á s c o m u n e s s o n los siguientes:

Data w a r e h o u s e centralizado: e s la arquitectura más común, normalmente

es u n a b a s e de gran tamaño donde s e centraliza la información y la

administración. L a ventaja e s que e s posible migrar de esta arquitectura a otra y la

(39)

Data w a r e h o u s e descentralizado: los datos s o n transformados, rediseñados

y c a r g a d o s en b a s e s s e p a r a d a s (data marts). Este tipo de arquitectura no tiene

una b a s e de datos de gran tamaño, sin embargo la administración e s compleja.

Data w a r e h o u s e distribuido: en esta arquitectura todas las áreas obtienen

información de un modelo corporativo y a unificado. T o d a s las áreas obtienen

información validada, probada, consistente y verificada. S e s e p a r a el proceso de

transformación e integración del proceso de diseño. S e aumenta el desempeño en

el a c c e s o a la información. H a y más seguridad en la información. P e r o la

administración e s m á s compleja

Virtual data w a r e h o u s e : s e utiliza tecnología middleware. L o s usuarios

requieren de u n a interfaz inteligente para crear un metadata (diccionario de datos)

de las fuentes y ejecutar peticiones en línea y en tiempo real. Necesita b u e n a

infraestructura de redes. S i las b a s e s s o n distribuidas e s posible que h a y a retraso

en la respuesta de peticiones.

Data w a r e h o u s e c o n actualización: los datos s o n extraídos e integrados en

una b a s e relacional o corporativa debido a que existen diferentes fuentes con

inconsistencia en la información. L a información e s c a r g a d a después a el data

warehouse, y los n u e v o s datos s o n actualizados con información que necesita ser

(40)

L a m i s m a arquitectura lógica puede requerir una diferente arquitectura física

(infraestructura) dependiendo de un ambiente corporativo en particular. (Vidette

P o e , 1996)

P a r a definir el tipo de infraestructura que s e utilizará en el almacén de datos

se d e b e n tomar en cuenta los siguientes puntos:

• El tipo de infraestructura y arquitectura con que cuenta la e m p r e s a para s u s

s i s t e m a s operacionales. L a relación que tiene la e m p r e s a con proveedores y a

existentes.

• C a p a c i d a d e s t i m a d a del almacén de datos. S e debe proyectar dentro de un

límite d e tiempo, incluyendo los archivos para producción, pruebas y desarrollo.

También las áreas de soporte a los sistemas que e s el espacio requerido para

a l m a c e n a r "sotfware" y soportar su operación.

• Cálculo d e c a p a c i d a d del procesador. T o m a n d o en cuenta los p r o c e s o s en

línea (On Line Transactions). L o s p r o c e s o s batch que s o n u s a d o s para generar

reportes predeterminados. C a r g a diaria (creación y actualización del almacén

de datos). C a r g a m e n s u a l (creación y actualización del almacén de datos) y

transformaciones de datos (sumarizaciones). A d e m á s s e debe tomar en

consideración los p r o c e s o s de desarrollo. Utilización de la red actual de

transmisiones y servidores. Debido a la cantidad de información que

proporciona el almacén de datos a los usuarios hay que determinar el impacto

(41)

3.11 Selección / confirmación de las herramientas de diseño, extracción, transformación, explotación,zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA distribución y desarrollo

Al s e l e c c i o n a r las herramientas d e cualquiera d e las e t a p a s e s

recomendable seguir los siguientes criterios:

• A s e g u r a r q u e la e m p r e s a s e a líder en el mercado y tenga p r e s e n c i a en

México c o n s i d e r a b l e .

• E l soporte q u e d e n s e a local

• O f r e z c a servicios de capacitación

• E l equipo d e hardware s e a e s c a l a b l e

• Integración y conectividad c o n la arquitectura elegida y del negocio

3.12 Selección del equipo de trabajo

El personal q u e tiene el conocimiento e s el principal protagonista del

almacén d e datos. R e s u l t a m u c h o m á s sencillo agregar e s p a c i o en disco y

c a p a c i d a d d e l p r o c e s a d o r que encontrar personal conocedor. Y lo importante en

formar un buen equipo e s que tengan conocimiento sobre el enfoque técnico de

(42)

3.13 Creación del plan de trabajo

L a creación del plan de trabajo d e b e realizarla el equipo en conjunto, y a

que c a d a uno e s experto en su área de conocimiento y puede estimar el tiempo

que tomará en c a d a parte del proyecto.

CAPÍTULO 4: Requerimientos

4.1 Introducción

E s importante entender que el desarrollo de un Almacén de datos D W H

(Data W a r e h o u s e ) , e s diferente al desarrollo de un sistema operacional de

información, esto s e d e b e aplicar al tratar de obtener los requerimientos de los

usuarios. E l objetivo c o m o d e s a b o l l a d o r de este tipo de sistemas e s reconocer las

n e c e s i d a d e s de información de los usuarios. P o r lo que s e d e b e aplicar la

experiencia n e c e s a r i a para llevar las entrevistas de m a n e r a a d e c u a d a y así

obtener la información n e c e s a r i a para el desarrollo. Otra parte que s e d e b e cuidar

e s el h e c h o d e que m u c h o s de los usuarios no han tenido contacto con un proceso

analítico, ni han utilizado herramientas de tipo final para el apoyo en la t o m a de

decisiones, por lo que no p u e d e n imaginar el rango de opciones que puede

otorgar un s i s t e m a de este tipo, y e s muy c o m ú n que el usuario.(Vidette P o e , 1996)

El propósito de la recolección de requerimientos para un D W H e s entender

(43)

3.13 Creación del plan de trabajo

L a creación del plan de trabajo d e b e realizarla el equipo en conjunto, y a

que c a d a uno e s experto en su área de conocimiento y puede estimar el tiempo

que tomará en c a d a parte del proyecto.

CAPÍTULO 4: Requerimientos

4.1 Introducción

E s importante entender que el desarrollo de un Almacén de datos D W H

(Data W a r e h o u s e ) , e s diferente al desarrollo de un sistema operacional de

información, esto s e d e b e aplicar al tratar de obtener los requerimientos de los

usuarios. E l objetivo c o m o d e s a b o l l a d o r de este tipo de sistemas e s reconocer las

n e c e s i d a d e s de información de los usuarios. P o r lo que s e d e b e aplicar la

experiencia n e c e s a r i a para llevar las entrevistas de m a n e r a a d e c u a d a y así

obtener la información n e c e s a r i a para el desarrollo. Otra parte que s e d e b e cuidar

e s el h e c h o d e que m u c h o s de los usuarios no han tenido contacto con un proceso

analítico, ni han utilizado herramientas de tipo final para el apoyo en la t o m a de

decisiones, por lo que no p u e d e n imaginar el rango de opciones que puede

otorgar un s i s t e m a de este tipo, y e s muy c o m ú n que el usuario.(Vidette P o e , 1996)

El propósito de la recolección de requerimientos para un D W H e s entender

(44)

manejan. U n a clave básica e s que los usuarios siempre harán preguntas para la

toma de d e c i s i o n e s . P o r ello, el sistema d e b e de ser dirigido hacia estos objetivos

,ya que s e pude diseñar un sistema increíble, pero dirigido hacia otras

expectativas y no para la futura toma de decisiones.

4.2 Entrevistas

Existen puntos que deben de tomarse en cuenta en el proceso de

entrevistas, a saber:

• U n a perspectiva amplia de negocios: por ejemplo que la e m p r e s a esté

planeando la posible expansión en una área específica de negocios en los

siguientes cinco años.

• Especificación de detalles a c e r c a de los datos y los elementos que serán

clave s en la implantación inicial del D W H .

• Entender el u s o principal del núcleo de los datos iniciales.

• Compartir la información que s e tenga en común para que otra unidad de

negocios h a g a uso de ella o en el futuro puedan integrarse.

• T e n e r presente que pueden existir otros usuarios con a c c e s o a los datos e

(45)

P a r a asegurar el éxito e s importante contar con analistas de sistemas y

modeladores de datos que participen en el proceso de entrevista. S i el equipo de

trabajo no c u e n t a c o n experiencia en un proyecto de D W H e s necesario incluir un

consultor de D S S (Decisión Support System) en el equipo.

También e s importante involucrar a personas pertenecientes a la

comunidad de usuarios finales, este tipo de personal tiene mucho trabajo, por lo

que e s difícil de contactar; sin embargo, e s necesario hacerlos conscientes de la

importancia del proyecto y mantenerlos al tanto. P a r a e s c o g e r la persona a quien

se v a a entrevistar e s necesario tener en cuenta las siguientes características:

• Analistas y usuarios dirigidos a funciones de negocios.

• G e r e n t e s dirigidos a funciones de negocios.

• Analistas y usuarios relacionados a funciones de negocios.

• G e r e n t e s relacionados a funciones de negocios.

(46)

4.3 Analistas y usuarios dirigidos a funciones de negocios.

1. Definir la calendarización de entrevistas d e b e ser una de las primeras c o s a s

que s e d e b e n establecer al iniciar un proyecto.

2. C o n s e g u i r la a g e n d a del usuario.

3. Manejar c o m o máximo 2 entrevistas por día, para examinar las notas obtenidas

entre s e s i o n e s .

4. P r o v e e r un m a r c o al usuario por medio de una muestra de entrevista.

5. T e n e r u n a p e r s o n a de alto rango que involucre al personal y estos s e sientan

c o m p r o m e t i d o s c o n él.

6. Pedir a los usuarios una muestra de los reportes que ellos reciben

periódicamente, c r e a n , etc.

7. Publicar las entrevistas para que los demás s e p a n quién está involucrado.

8. Dejar el tiempo necesario para la captura de c a d a una de la entrevistas.

9. P a s a r tiempo c o n las p e r s o n a s para las que está dirigido el sistema. El objetivo

de e s t a entrevista e s entender el análisis diario (qué e s lo que s e maneja de

m a n e r a m a n u a l , los reportes c r e a d o s y los tipos de preguntas que s e

manejan).

10. S e d e b e d e limitar el número de personas que s e entrevistan teniendo c o m o

máximo cuatro.

E s t a s entrevistan d e b e n tener c o m o duración, un mínimo de 2 horas y un

(47)

L a primera entrevista e s siempre la m á s larga, las entrevistas s u b s e c u e n t e s

son de m e n o r duración. S e d e b e ser un tanto formal, manejar las entrevistas de

m a n e r a directa, sin la p r e s e n c i a de una p e r s o n a de mayor jerarquía y a que esto

puede influir en los resultados. . (Vidette P o e , 1996)

4.4 Gerentes dirigidos a funciones de negocios.

E s t a s entrevistas d e b e n durar d o s horas c o n un máximo de 4 personas. L a

meta principal e s entender los objetivos del negocio. ¿Cómo s e d e b e comportar el

personal? ¿Qué tipo de análisis realiza usted m i s m o ? ¿Qué e s lo que hace con los

reportes que le d a n ?

4.5 Analistas y usuarios relacionados a funciones de negocios.

E s t a entrevista también d e b e de durar d o s horas y tener un máximo de 4

personas. L a s p e r s o n a s más útiles s o n aquellas que interactúan de m a n e r a

directa c o n los datos y/o funciones de negocio. S e d e b e mantener este grupo

monitoreado para ver c ó m o utilizan los m i s m o s datos y qué otros datos s o n

(48)

Gerentes relacionados a funciones de negocios.

L a s entrevistas c o n este grupo han dado muy buenos resultados, debido a

que tienen m u c h a s responsabilidades. E s t a s entrevistas d e b e n de durar una hora

c o m o máximo.

Ejecutivos

L a p e r s o n a de alto nivel que nos está dando apoyo s e debe entrevistar de

m a n e r a personal e individual. L a s entrevistas d e b e n de durar 30 minutos y c o m o

máximo 1 hora. E s t a s d e b e n manejarse hasta el final de todas las entrevistas. C o n

esta entrevista s e d e b e n armar todas las entrevistas que s e han realizado por lo

que e s básica para integrarlas.

E s t a s p e r s o n a s tienen una visión muy amplia de que e s lo que quieren del

departamento en un futuro inmediato, mediano plazo y largo plazo. S u

participación hará que las diversas áreas s e involucren con mayor seriedad el

(49)

Debido al tiempo previsto, s e d e b e de ser breve y conciso, en las preguntas

que s e realicen.

• ¿Cuáles s o n las responsabilidades de tu puesto?

• ¿Cuáles s o n los objetivos del corporativo?

• ¿Cuáles s o n los factores críticos que impiden alcanzar dichos objetivos?

• ¿Qué ayudaría a prevenir dichos factores?

• ¿Cuáles s o n las presiones m a s grandes de negocios que s e tienen hoy

e n día?

• ¿Cuáles serían los impactos financieros al solucionar estos problemas?

• ¿Porqué necesita información diaria?

• ¿Cuáles s o n tus requerimientos de análisis?

• ¿Cuáles s o n las oportunidades que s e tienen para mejorar los

beneficios?

(50)

4.6 ¿ Q u é preguntar al usuario final?

S e harán diferentes preguntas a los ejecutivos, gerentes y analistas. A los

gerentes y analistas s e les harán las siguientes preguntas:

• Describe tu puesto.

• ¿Cómo s e mide tu desempeño?

• ¿Cuáles s o n los problemas de negocio que enfrentas hoy en día?

E s importante c o n o c e r el flujo de la información dentro y fuera del

departamento. E n m u c h o s c a s o s el esfuerzo que s e h a g a para entender el manejo

de este flujo hará que s e disminuya el tiempo de análisis.

• ¿Qué e s lo que s e recibe?

• ¿Qué reportes s e reciben con mayor frecuencia?

• ¿Cuáles s o n los que utilizas?

• ¿Qué tan seguido recibes este reporte?

• ¿Qué e s lo que s e b u s c a dentro del reporte?

(51)

P o r lo general s e inicia con este reporte y después s e h a c e todo un análisis

otro tipo de hoja, por lo que el reporte tan solo fue el inicio.

¿Qué e s lo que c r e a s ?

¿Qué reportes c r e a s ?

¿Con qué periodicidad desarrollas este análisis?

¿Quién obtiene e s t a información?

¿Otras áreas crean el m i s m o reporte? D e ser así ¿cuál?

¿ C ó m o s e utiliza?

¿Cuánto tiempo te lleva al crearlo?

¿De dónde obtienes la información?

S i tuvieras tiempo, ¿cuáles serían los siguientes p a s o s que harías para

analizar e s t a información?

(52)

14.7 Un análisis adecuado.

L a mayoría de los usuarios finales no s o n c a p a c e s de definir cuales son s u s

requerimientos a d e c u a d o s . D e s d e su punto de vista les gustaría tener los últimos

10 años a detalle y c o n esto podrían hacer su análisis. C o m o esto no e s posible e s

necesario h a c e r preguntas a d e c u a d a s para s a b e r c u a l e s son los análisis

a d e c u a d o s para el futuro. (Vidette Poe,1996)

• ¿Qué tipos de análisis h a c e s ?

• ¿Quién h a c e la pregunta original? (cliente, jefe)

• ¿ C ó m o resuelves e s t a s preguntas hoy en día?

• H a y ejemplos de lo que s e h a h e c h o en el p a s a d o

Existirán situaciones en d o n d e el análisis esta diversificado, e s decir, que

otra área también lo h a c e por lo que las funciones s e duplican.

4.8 Análisis de negocio

Ejemplo de preguntas de negocio:

• ¿ C ó m o desarrollas los programas de promoción?

• ¿ C ó m o evalúas la productividad de la promoción?

• ¿Con qué frecuencia, revisas el comportamiento de los proveedores?

(53)

4.9 Información específica de datos

• ¿De dónde vienen los datos?

• ¿ Q u é tan seguido s e actualizan?

• ¿ Q u é nivel de detalle s e necesita?

• ¿Quién e s el responsable de e s t o s ?

Después s e d e b e explorar la fuente de los datos y hacer las m i s m a s

preguntas. L a jerarquía de las fuentes d e b e quedar claramente establecida, s e

incluirá un d i a g r a m a . L a mayoría de las organizaciones tienen ventas de producto,

un departamento de ventas, etc.

P a r a entender este tipo de estructuras s e deben tener claros los siguientes

puntos:

• A qué nivel s e desarrolla el análisis (hay v e c e s que s e hace en donde s e

necesita o en d o n d e e s lo único a lo que s e tiene acceso).

• Cuál e s el nivel m á s bajo de detalle dentro de la organización.

• E x i s t e n c i a de múltiples jerarquías (dentro de la organización puede existir

u n a jerarquía en algún o algunos departamentos).

• Termino del año fiscal.

(54)

Si aún no s e establecen estos períodos, e s posible partir del análisis de los

reportes existentes.

S e d e b e estar preparado para discutir el proyecto con este usuario, esta

(55)

4.10 D o c u m e n t a c i ó n

S e d e b e escribir todo lo obtenido en las entrevistas al momento de hacerlas

y no e s p e r a r a que todas hayan sido h e c h a s . L o s resúmenes de las entrevistas

tienen varios objetivos:

• C a p t u r a r todo el conocimiento de lo que s e h a y a discutido en el metadata.

• T e n e r mayor entendimiento del negocio.

• Servir c o m o futura documentación.

• P r o v e e r documentación para dar capacitación a nuevos miembros del

proyecto.

S i e m p r e s e d e b e resumir todo lo aprendido por escrito. Esto e s básico para

integrar los requerimientos del D W H .

S e d e b e de organizar la información de la siguiente manera:

• R e s p o n s a b i l i d a d e s de trabajo: incluir un breve resumen de lo que s e h a y a

compartido.

• Análisis: incluir u n a descripción de los diferentes tipos de análisis que s e hayan

(56)

• Requerimientos de Datos: incluir una descripción de c a d a c a m p o de datos

que s e h a y a m e n c i o n a d o , así c o m o el nivel de detalle que s e d e s e a

manejar.

• Miscelánea: esta sección sirve para capturar otros conceptos importantes.

U n a v e z terminado el resumen, s e debe de compartir con todos los

participantes y en cuanto todos los grupos lo hayan aceptado, s e integrará al

resumen final. (Vidette P o e , 1 9 9 6 )

4.11 Etapas para la fase de requerimientos

1. Determinación / confirmación de la comunidad de usuarios.

2. Determinación / confirmación de los requerimientos.

3. Confirmación de las herramientas de explotación y distribución.

4. C a r g a de información sobre el proceso al metadata.

4.12 Determinación / confirmación de la comunidad de usuarios

L a determinación y confirmación de los usuarios e s una tarea muy

importante y a que s e d e b e considerar a los usuarios c o m o parte del proyecto y

asegurarse de que estén involucrados en todas las etapas del proceso. Así

mismo, la comunicación con el usuario permitirá explicar las ventajas de la

(57)

P o r otro lado, si o b t e n e m o s la retroalimentación de los usuarios,

lograremos un mejor entendimiento del negocio, lo cual nos permitirá una mejor

planeación d e las siguientes f a s e s del proyecto.

4.13 Determinación / confirmación de los requerimientos

C o n las entrevistas de n e g o c i o s que s e realicen, s e deben definir las

n e c e s i d a d e s de información por parte del usuario, y a que los elementos de este,

ayudan a construir el modelo de la siguiente fase.

C O L E C C I O N / T E M A :

R E S P O N S A B L E : REQUERIMIENTO: USUARIO: BENEFICIOS TIPO REQUERIMIENTO Negocio, Operacional ELEMENTO(S) DE I N F O R M A C I Ó N

información que se desea obtener

DIMENSION T E M P O R A L

Agrupación temporal para consulta (Diaria, semanal, mensual,...)

F R E C U E N C I A D E A C T U A L I Z A C I Ó N

Actualidad de datos

F O R M A T O D E P R E S E N T A C I Ó N

Tabular, texto, gráfica...

Figure

Figura 1zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA. diferencias entre data warehouse y sistemas operacionales

Figura 1zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA.

diferencias entre data warehouse y sistemas operacionales p.20
Figura 2.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA el desarrollo del almacén

Figura 2.zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA

el desarrollo del almacén p.26
Figura 3. Identificación de tipos de usuario

Figura 3.

Identificación de tipos de usuario p.37
Figura 4.

Figura 4.

p.57
Figura 5. Alternativas de diseño.

Figura 5.

Alternativas de diseño. p.64
Figura 6. Elaboración del cuadro elementos para el esquema estrella

Figura 6.

Elaboración del cuadro elementos para el esquema estrella p.67
Figura 7. Desarrollo de la matriz de responsables de datos.

Figura 7.

Desarrollo de la matriz de responsables de datos. p.72
Figura 8. desarrollo de la matriz de fuentes de datos (metadata)

Figura 8.

desarrollo de la matriz de fuentes de datos (metadata) p.73
Figura 9. Aplicación del modelo en el caso ITESM-CEM BCI

Figura 9.

Aplicación del modelo en el caso ITESM-CEM BCI p.93
Figura 10. Arquitectura de 3 capas para el proyecto ITESM-CEM BCI

Figura 10.

Arquitectura de 3 capas para el proyecto ITESM-CEM BCI p.101
Figura 11. Flujo de información

Figura 11.

Flujo de información p.132
Figura 12. Determinación de usuarios.

Figura 12.

Determinación de usuarios. p.137
Figura 12. Arquitectura elegida para el proyecto D S L .

Figura 12.

Arquitectura elegida para el proyecto D S L . p.138