Proyecto de Tesis 03 PDF

Universidad Csar Vallejo
Escuela de Ingeniera de Sistemas

Filial Chimbote

APLICACIN DE UN DATAWAREHOUSE PARA AGILIZAR LA TOMA
DE DECISIONES EN EL REA DE RADIOLOGA DEL HOSPITAL
REGIONAL ELEAZAR GUZMN BARRN DE NUEVO CHIMBOTE.

Proyecto de Tesis para optar el ttulo profesional de Ingeniero de
Sistemas
Autores:
Balarezo Coronado Csar Eduardo.
Pastor Snchez Jhonny Richard.

Asesor Especialista:
Ing. Mg. Chvez Monzn, Carlos

Asesor Metodolgico:
Ing. Mg. Santos Fernndez, Juan Pedro

Chimbote, Per
2009

ii

INDICE

Contenido
INTRODUCCION ....................................................................................................................... vi
CAPITULO I ................................................................................................................................. 1
1.1. Titulo Tentativo ............................................................................................................. 2
1.2. Autor (es): ..................................................................................................................... 2
1.3. Tipo de Investigacin: ................................................................................................... 2
1.4. Lugar de Investigacin: ................................................................................................. 2
1.5. Institucin que la investiga: ........................................................................................... 2
1.6. Duracin del Proyecto: .................................................................................................. 2
CAPITULO II ............................................................................................................................... 4
2.1. El Problema. .................................................................................................................. 5
2.1.1. Realidad Problemtica: ......................................................................................... 5
2.1.2. Principales Problemas: .............................................................................................. 6
2.1.3. Formulacin del Problema: ....................................................................................... 7
2.1.4. Justificacin del Problema: ....................................................................................... 7
2.1.4.1. Justificacin Tecnolgica: ................................................................................. 7
2.1.4.2. Justificacin Operativa: ..................................................................................... 7
2.1.4.3. Justificacin Social: ........................................................................................... 8
2.1.4.4. Justificacin Econmica: ................................................................................... 8
2.1.4.5. Justificacin Acadmica: ................................................................................... 8
2.1.5. Limitaciones .............................................................................................................. 8
2.2. Objetivos General:......................................................................................................... 9
2.2.1. Objetivos Especficos: ........................................................................................... 9
2.3. Marco Referencial Cientfico ...................................................................................... 10
2.3.1. Antecedentes. ...................................................................................................... 10
2.3.2. Marco Terico ............................................................................................................... 16
iii

Business Intelligence ......................................................................................................... 16
Datawarehouse .................................................................................................................. 20
2.1. Arquitectura Datawarehouse ....................................................................................... 23
2.1.1. Diseo Lgico ..................................................................................................... 23
2.1.2. Diseo Fsico ....................................................................................................... 27
2.2. Elementos constituyentes de una Arquitectura Data Warehouse ..................................... 30
2.2.1. Base de datos operacional / Nivel de base de datos externo ............................... 31
2.2.2. Nivel de acceso a la informacin ........................................................................ 32
2.2.3. Nivel de acceso a los datos .................................................................................. 33
2.2.4. Nivel de Directorio de Datos (Metadata) ............................................................ 34
2.2.5. Nivel de Gestin de Procesos .............................................................................. 34
2.2.6. Nivel de Mensaje de la Aplicacin...................................................................... 35
2.2.7. Nivel DataWarehouse (Fsico) ............................................................................ 35
2.2.8. Nivel de Organizacin de Datos .......................................................................... 35
2.3. Operaciones en un DataWarehouse .................................................................................. 36
2.3.1. Sistemas Operacionales ....................................................................................... 36
2.3.2. Extraccin, Transformacin y Carga de los Datos .............................................. 37
2.3.4. Metadata .............................................................................................................. 37
2.3.5. Acceso de usuario final ....................................................................................... 38
2.3.6. Plataforma del DataWarehouse ........................................................................... 38
2.4. Almacenamiento OLAP ................................................................................................... 39
2.4.1. cubos multidimensionales ......................................................................................... 40
2.4.2. dimensiones ............................................................................................................... 41
2.4.3. medidas o metricas .................................................................................................... 42
2.4.4. jerarquias de dimensiones y niveles .......................................................................... 42
2.5. ESTRATEGIAS DE ALMACENAMIENTO. (ROLAP, MOLAP, HOLAP) ................. 44
2.5.1. MOLAP ..................................................................................................................... 45
2.5.2. ROLAP ...................................................................................................................... 45
2.6. Conceptualizaciones Sobre Transformacion Y Carga De Datos. ..................................... 46
iv

2.6.1. Migracion De Datos: Extraccion, Transformacion Y Carga ..................................... 46
2.6.2. Impactos DW............................................................................................................. 49
3. METODOLOGIAS ......................................................................................................... 53
3.1. Rational Unified Process (RUP) .................................................................................. 53
3.2. Extreme Programing (XP) ............................................................................................ 56
3.3. Metodologa Integradora de Procesos Empresariales (MIPE) ..................................... 60
3.4. Mtrica 3 ...................................................................................................................... 61
3.5. Microsoft Solution Framework (MSF).................................................................... 63
3.6. Metodologa Propuesta por Ralph Kimball ............................................................ 69
3.7. Seleccin De La Metodologa ................................................................................. 73
2.3.3. MARCO CONCEPTUAL ............................................................................................. 74
2.4. Hiptesis ...................................................................................................................... 77
2.5. Variables e Indicadores ............................................................................................... 77
2.5.1. Variables.............................................................................................................. 77
2.5.2. Indicadores .......................................................................................................... 78
2.6. Diseo de Ejecucin .................................................................................................... 81
2.6.1. Objeto de Estudio. ............................................................................................... 81
2.6.2. Metodologa. ....................................................................................................... 81
2.6.3. Tipo de Investigacin. ............................................................................................... 84
2.6.4. Diseo de Investigacin. ..................................................................................... 84
2.6.5. Poblacin y muestra de estudio ........................................................................... 85
2.6.5.1. Poblacin ......................................................................................................... 85
2.6.5.2. Muestra ............................................................................................................ 89
2.6.6. Tcnicas, instrumentos, fuentes e informantes .................................................. 101
2.6.7. Procedimientos de recoleccin de datos. ........................................................... 101
2.6.8. Tcnicas de procesamiento y anlisis de datos. ................................................ 102
CAPITULO III .......................................................................................................................... 103
3.1. Recursos ......................................................................................................................... 104
3.1.1. Personal ................................................................................................................... 104
v

3.1.2. Materiales y Equipos ............................................................................................... 104
3.2. Presupuesto ............................................................................................................... 105
3.2.1. Analtico ............................................................................................................ 105
3.2.2. Consolidado ....................................................................................................... 106
3.3. FINANCIACIN ...................................................................................................... 106
CAPITULO IV .......................................................................................................................... 107
REFERENCIA BIBLIOGRAFA ............................................................................................. 110
ANEXOS................................................................................................................................... 111

vi

INTRODUCCION

Actualmente el entorno empresarial est sometido a un estado de cambio permanente,
acelerado e interdependiente, para enfrentarlo las organizaciones deben ser giles,
capaces de enfrentar el ambiente competitivo y hacer las cosas de forma diferenciada,
para ello el conocimiento es la clave para mantener la actitud abierta hacia el cambio y
la mejora constante.

El valor fundamental de una empresa reside en su capacidad para superar a sus
competidores en trminos de costos y calidad de los productos y servicios que ofrece; es
decir, de su competitividad. Esta ltima, a su vez, depende considerablemente de la
habilidad de la empresa para adaptarse a las exigencias de su mercado y de su entorno.
Una variable que considera cualquier compaa exitosa hoy en da es la innovacin y la
gestin de su conocimiento solo as se garantiza su presencia en el mercado. As, la
vigilia o el estado de alerta frente a las fuerzas que afectan el negocio le permiten
procesar y transferir informacin, aplicar conocimientos y, con ello, innovar su oferta de
servicios. Competitividad e innovacin son nociones estrechamente ligadas a la
Inteligencia de Negocios y, en este sentido, la empresa moderna debe estar consciente
de la necesidad de crear un ambiente propicio para lograr que la efectiva transferencia
de la informacin y que la aplicacin del conocimiento obtenido se efecte de una
forma transparente en todas las actividades de sus trabajadores y, en todas las instancias
de la estructura organizacional. Como se obtiene, manipula y usa la informacin junto a
la capacidad de generar conocimiento ser el factor que determine si la empresa gana o
pierde.

Y es precisamente en este contexto que la implementacin de Business Intelligence se
incorpora como ese elemento clave que agiliza la Toma de decisiones para una exitosa
prestacin de los servicios a la poblacin.

El presente trabajo describe la implementacin de una Solucin de Inteligencia de
Negocios, como apoyo para agilizar la toma de decisiones en el rea de Radiologa en el
Hospital Regional Eleazar Guzmn Barrn de Nuevo Chimbote.

UNIVERSIDAD CSAR VALLEJO PROYECTO DE TESIS
- 1 -
Aplicacin de un DataWarehouse para agilizar la toma de
decisiones en el rea de Radiologa del Hospital Regional Eleazar
Guzmn Barrn de Nuevo Chimbote
Balarezo Coronado, Csar Eduardo
Pastor Snchez, Jhonny Richard

CAPITULO I
DATOS GENERALES
- 2 -

1.1. Titulo Tentativo
Aplicacin de un DataWarehouse para agilizar la toma de decisiones
en el rea de Radiologa del Hospital Regional Eleazar Guzmn Barrn
de Nuevo Chimbote

1.2. Autor (es):
Balarezo Coronado, Csar Eduardo.
o Email: balarezo.cesar@gmail.com
o Telfono: 043-943593508
Pastor Snchez, Jhonny Richard.
o Email: hardrichard@hotmail.com
o Telfono: 043-943813521

1.3. Tipo de Investigacin:
1.3.1. Por el fin que se persigue.
Tecnolgica: porque se har uso de Software para
implementar la solucin tecnolgica
1.3.2. Por el diseo de contrastacin.
Cuasiexperimental: porque se manipulara las variables
indirectamente y se obtendrn los datos de forma natural.

1.4. Lugar de Investigacin:
Hospital Regional Eleazar Guzmn Barrn
Av. Brasil S/N.
Nuevo Chimbote.

1.5. Institucin que la investiga:
Escuela de Ingeniera de Sistemas.
Universidad Csar Vallejo
Filial de Chimbote
Av. Bolognesi 485 - Chimbote - Tel. 342803
Campus Universitario: Urb. Los Portales Mz. H Lt. 1- Nvo Chimbote -
Tel. 316691

1.6. Duracin del Proyecto:
Fecha de inicio: 01/09/2009
Fecha de Fin: 10/12/2009

- 3 -

Etapa / Fase Fecha de Inicio Fecha de Termino
Duracin
(Semanas)
Recoleccin de Datos 03/08/2009 17/08/2009 2
Anlisis de Datos 18/08/2009 31/08/2009 2
Elaboracin del Informe 01/09/2009 11/12/2009 15
TOTAL 19

- 4 -

CAPITULO II
PLAN DE
INVESTIGACION
- 5 -
2.1. El Problema.
2.1.1. Realidad Problemtica:
El Hospital Regional Eleazar Guzmn Barrn, nosocomio dedicado a
la atencin de pacientes, en sus diferentes servicios de salud que son,
consultorios externos de Medicina, Traumatologa, Ciruga,
Dermatologa, Pediatra, Emergencia, etc.

Entre muchas de sus diferentes reas y departamentos del Hospital
Regional tiene el Departamento de Diagnsticos por Imgenes y ah el
rea de Radiologa en donde ser nuestro objeto de investigacin.
Esta rea cuenta con 5 Profesionales Tecnlogos encargados de realizar
las radiografas a los pacientes, de los cuales se dividen en turnos para
poder realizar las atenciones, que son maana , tarde y noche, se cuenta
tambin con una secretaria encargada de recepcionar las ordenes de los
pacientes que vienen de los diferentes consultorios para realizarse sus
respectivas radiografas y al Doctor en Jefe del Departamento, dichas
radiografas pueden ser de diferentes tipos, como por ejemplo:
Radiografas de Trax, Columnas Lumbares, Columnas LumboSacras,
Columnas Cervicales, Sacros, Crneos , Rodillas, Tobillos, Piernas,
Pelvis, Muecas, Hombros, Huesos Propios de la Nariz, Codos,
Parrillas Costales, Abdomen, Muslos y de los cuales estn en diferentes
posturas que son Frontales, Laterales, Oblicuos, entre diferentes edades
de los pacientes.

Dichas radiografas estn divididas en diferentes orgenes, de los cuales
son si los pacientes provienen de forma Ambulatoria (que son personas
particulares que cancelan su consulta por caja por medio de una
prefactura), pacientes por SIS (Sistema Integral de Salud) son pacientes
que estn afiliados a este seguro del estado del cual puede realizar sus
consultar y realizar sus atenciones de forma gratuita, tenemos tambin
por el PCT (Programa de Control de Tuberculosis) pacientes que se les
aplica un descuentos en sus atenciones y Radiografas, estn tambin
por SOAT de los cuales estn por AFOCAT y LA POSITIVA pacientes
- 6 -
que pueden realizar sus atenciones de forma gratuita por estar cubiertos
por este seguro, tambin por Seguros Privados y Convenios de los
cuales estn los seguros RIMAC, MAFRE, seguros que cubren con los
gastos de atencin y consultas de los pacientes asegurados y entre los
convenios estn con BASE NAVAL convenio con la Marina de Guerra
del Per, EXCOMBATIENTES, BENEFICENCIA, LOS DE
MEDICOS LEGISTAS, PERPETUO SOCORRO, LEY DE
EMERGENCIAS.

2.1.2. Principales Problemas:
Entre los principales problemas del rea de Radiologa estn el
extravi de las placas radiografas de los pacientes.
La generacin de los reportes mensuales de los pacientes atendidos
por diferentes tipos de atenciones.
No se cuenta con la informacin oportuna para mostrar estadsticas
de atenciones.
El tiempo para generar la informacin necesaria para la jefatura es
muy largo, reportes para la jefatura que por lo general tardan 2 das
en ser completadas.
El problema del extravi de los informes radiolgicos que son de
suma importancia para realizar los reportes mensuales para las
compaas de Seguros como AFOCAT, LA POSITIVA, SIS, BASE
NAVAL, etc.
Problemas a Nivel Tctico: la falta de Reportes Analticos histricos
con grficos y cuadros comparativos que muestren la informacin de
las atenciones realizadas as como los informes de las radiografas de
seguros , as como las placas radiogrficas faltantes por consecuencia
de extravos en otras reas a donde son derivadas las placas
radiogrficas para la toma de decisiones de las estrategias que ayuden
a contrarrestar la cantidad de extravos de las placas radiogrficas as
como los informes de los seguros.
- 7 -
La falta de integracin con las diferentes reas del Hospital Regional
Eleazar Guzmn Barrn que de cierta manera necesitan de la
informacin del rea de Radiologa para tomar decisiones como en el
caso de la oficina de controla los seguros pblicos y privados, la
oficina del SIS y PCT que necesitan llevar el control y saber el
comportamiento del flujo de atenciones realizadas mensualmente,
como estadsticas y reportes de atenciones, dichos reportes en la
actualidad toman realizar das.
El equipo de Tecnlogos tardan 1 da para realizar sus reportes
estadsticos de las atenciones realizadas en sus das de Turno.
2.1.3. Formulacin del Problema:
De qu manera la Aplicacin de un DataWarehouse incide en la
toma de decisiones del rea de Radiologa del Hospital Regional
Eleazar Guzmn Barrn de Nuevo Chimbote?
2.1.4. Justificacin del Problema:
2.1.4.1. Justificacin Tecnolgica:
La presente investigacin se justifica tecnolgicamente
porque se har uso de una herramienta que atraer
modernidad en los procesos para la organizacin, que est
dispuesta a siempre apostar por las soluciones tecnolgicas.

2.1.4.2. Justificacin Operativa:
La aplicacin de Business Intelligence est desarrollado
para el fcil entendimiento y uso del personal operacional de
la organizacin, sin tener que estar presente una especialista
en Business Intelligence.

- 8 -
2.1.4.3. Justificacin Social:
La presente investigacin se justifica socialmente porque
ser beneficioso para todos los integrantes de la
organizacin, pues contribuir con el desarrollo de las
diferentes reas de la organizacin hacia la modernidad en la
que actualmente se est viviendo.

2.1.4.4. Justificacin Econmica:
La presente investigacin se justifica econmicamente
porque esta solucin tecnolgica ayudara a mantener una
mejor gestin de los procesos del rea y de esa manera
agilizar la toma de decisiones evitndose prdidas
econmicas en futuros problemas.

2.1.4.5. Justificacin Acadmica:
La presente investigacin aportar conocimientos y un
modelo de cmo desarrollas un Business Intelligence que
agilice a la toma de decisiones de las organizaciones, por lo
tanto podr servir como referencia bibliogrfica a futuras
investigaciones que quieran realizar proyectos en este
campo.
2.1.5. Limitaciones
Entras las limitaciones que hemos encontrado a lo largo de la investigacin
son las siguientes:
La falta de tiempo para la recoleccin de investigacin en el rea en
donde haremos la investigacin.
La falta de antecedentes locales sobre nuestra investigacin.
La falta de acceso a la informacin de mas reas lo cual ayudara a
enriquecer en la presente solucin tecnolgica planteada para el manejo
de la informacin.
- 9 -
2.2. Objetivos General:
Agilizar la toma de decisiones en el rea de Radiologa del Hospital Regional
Eleazar Guzmn Barrn de Nuevo Chimbote.
2.2.1. Objetivos Especficos:

1. Reducir el tiempo para generar los reportes mensuales de las
atenciones por seguros.
2. Incrementar el nivel de satisfaccin de los usuarios del rea de
Radiologa.
3. Incrementar el nivel de satisfaccin de los usuarios del rea de
Estadstica.
4. Minimizar el tiempo que se requiere para obtener los reportes
estadsticos de los tecnlogos de las atenciones diarias realizadas.
5. Reducir el tiempo para el acceso de la informacin con las diferentes
reas integrado el sistema transaccional del rea de Radiologa con la
Unidad de Informtica y Sistemas.
6. Minimizar la cantidad de extravos de placas radiogrficas elaborando
Reportes analticos histricos con cuadros comparativos.
7. Minimizar el tiempo de bsqueda de informacin que muestre las
atenciones y por tipo de placas elaborando reportes analticos
histricos con cuadros comparativos.
8. Minimizar el tiempo de bsqueda de reportes mensuales por
atenciones de seguros y convenios que tiene el rea de radiologa
elaborando reportes analticos histricos con cuadros comparativos.
9. Minimizar el tiempo de emisin de reportes a las diferentes reas que
las requieran integrando las diferentes reas del hospital con el rea de
radiologa mediante un DataMart

- 10 -
2.3. Marco Referencial Cientfico
2.3.1. Antecedentes.
A) Antecedentes Nacionales
Titulo del antecedente

Solucin de Inteligencia de Negocios para Empresas de Servicios de asistencia
aplicacin prctica a la gerencia de asistencia de Touring y Automvil Club
Per (DHONY, 2006)

Autor(s)
Dhony Christian Espinoza Sevallos.
Renan Rancisco Quispe lvarez

Ao de la investigacin
2006
Lugar

TOURING Y AUTOMVIL CLUB PER
LIMA

Resumen

Objetivo
En la mencionada Tesis tuvo como finalidad de cmo implementar una solucin
en inteligencia de Negocios, como apoyo en la generacin de conocimiento para
empresas de Servicios de asistencia, ya que estas se mueven en un mercado
altamente Competitivo donde el cubrir las necesidades y buscar la satisfaccin del
cliente es primordial.

Logros
Permiti reducir drsticamente sus costos operativos y que se concentren
en el giro principal de su negocio.
Se Logro Captar el 90% del mercado de Seguros.
Se pudo identificar nuevos mercados y prever su comportamiento,
facilitando as la captacin de nuevos clientes, empresas de seguros y
reaseguros

Anlisis critico
En la mencionada Tesis nos muestra como aplicando Business Intelligence
podemos mejorar la capacidad competitiva de nuestra empresa en este caso se
aplico a una empresa de Asistencia de Touring y Automvil Club de Per y lo que
podemos notar que no solo podemos implementar una solucin utilizando BI en
una sola clase de Rubro empresarial, la podemos aplicar en diferentes rubros y
lograr los resultados esperados.

- 11 -
Una Metodologa para Sectorizar Pacientes en el consumo de medicamentos
aplicando DataMart y DataMing en un Hospital Nacional (IVAN, 2006)
Autor(s)
Ivn Gildo Tapia Rivas.
2006
Lugar
Hospital Nacional "Guillermo Almenara Irigoyen
LIMA

Resumen
Objetivo
En la presente Tesis, propone un mtodo para el anlisis de datos, para evaluar la
forma con la que se consumen los medicamentos en un hospital peruano, poder
identificar algunas realidades o caractersticas no observables que produciran
desabastecimiento o insatisfaccin del paciente, y para que sirva como una
herramienta en la toma de decisin sobre el abastecimiento de medicamentos en el
hospital, utilizando tcnicas para la Extraccin, Transformacin y Carga de datos,
y para la construccin de un Datamart, para finalmente un algoritmo de minera de
datos adecuado para el tipo de informacin que se encuentra contenida.

Logros
Permiti Identificar los diagnsticos por los que los pacientes peruanos
acuden a un hospital como la red EsSalud, nos permitira conocer tambin,
la realidad peruana en cuanto al tema de Salud personal y ambiental.
Permiti Identificar los diagnsticos ms comunes de la realidad peruana.

Anlisis critico
En la Tesis mencionada da a conocer otra de las herramientas que tiene la
Business Intelligence para propones soluciones tecnolgicas que ayuden a la
resolucin de los problemas de la organizacin, en este caso utiliza DataMart y la
Minera de Datos (DataMining) para la obtencin de datos histricos y
proyectarse a futuro para poder conocer el comportamiento del mercado y as
poder satisfacer con las necesidades del mercado.

- 12 -
B) Antecedentes Internacionales
Datawarehousing y su aplicacin como apoyo a la toma de decisiones en La
Espol (JUAN, 2005)

AUTOR(S)
Juan Carlos Bustamante.
Jos Francisco Rodrguez.
Fabricio Echeverra.
2005
Lugar
Escuela Superior Politcnica del Litoral
Ecuador
Resumen
El presente artculo presenta informacin sobre el diseo e implementacin de un
Datawarehouse y su aplicacin como apoyo a la toma de decisiones en la ESPOL.
El sistema incluye componentes de ubicacin de fuentes de datos, extraccin,
limpieza, montado, sumarizacin y consultas de cubos de informacin. Los
diversos mdulos estn diseados para poder ser ejecutados de manera
independiente; los componentes de administracin y control como una aplicacin
bajo Windows cliente-servidor y el componente de reportes y consultas por
intermedio de un navegador Web. Vale mencionar que esta implementacin
corresponde a una plataforma de informacin que est en capacidad de ser
accesada a travs de herramientas de terceros o propietarias.

Anlisis critico
En el presente artculo nos muestra como ayuda a la tomar de decisiones en la
Escuela Superior Politcnica del Litoral con la implementacin de una
Datawarehouse, ayudo a tener la informacin de forma ms oportuna, clara y
precisa para una buena toma de decisiones, y se puede notar una claramente como
Business Intelligence es una buena propuesta para soluciones tecnolgicas.

- 13 -
Midiendo y gestionando todas las actividades que sean esenciales para
impulsar la modernizacin hospitalaria (JOSE, 2007)

AUTOR(S)
Jos Mara Arce.
2007
Lugar
Hospital Universitario San Cecilio de Granada (HSC)
Espaa

Resumen
En el presente artculo nos muestra que un BI no solamente ayudar a la gestin
hospitalaria, un sistema BI repercute directamente en la satisfaccin de sus
pacientes, en su calidad de vida y en la percepcin sobre el nivel de atencin y del
servicio recibido, algo que debemos medir y analizar.

Se pudo predecir la evolucin de las lista de espera quirrgicas, detectar las
patologas que ms asistencia requeran y como han variado en tiempo, valorar el
cumplimiento efectivo de los compromisos de actividad establecidos con las
Consejeras dentro del Contrato Programa, conocer la actividad de los ingresos en
disporas (ectpicos), o con el fin de optimizar la actividad quirrgica conocer los
niveles de ocupacin de los quirfanos.

Anlisis critico
En una realidad como Espaa este articulo nos muestra como BI ayuda a la
gestin hospitalaria , de esa forma tener la informacin requerida ms rpida ,
precisa y clara, que ayuden a una buena toma de decisiones, como BI muestra sus
ventajas frente a los Sistemas Operacionales que se utilizar y muchas veces no son
suficientes para solucionar los problemas ms frecuentes en una realidad como un
Hospital que en donde los problemas son a diario, aqu nos reitera en otra realidad
como BI sigue siendo una buena solucin tecnolgica.

- 14 -
Datawarehouse para la gestin de lista de espera sanitaria (ITZIAR, 2007)

Autor(S)
ITZIAR ANGOITIA ESPINOSA.
2007
Lugar
Universidad Politcnica de Madrid
Espaa

Resumen
Objetivos:
En la Presente Tesis aborda un proyecto de Datawarehouse para la ayuda a la
toma de decisiones en el mbito de la Sanidad y en concreto en los Centros
Hospitalarios de una Comunidad Autnoma, aunque se podra aplicar en general a
la Gestin Hospitalaria de todo el pas. Lo se ha dividido en dos partes, una
primera en la que se describen las caractersticas tcnicas de cualquier
Datawarehouse, la organizacin de los sistemas que lo componen y las tcnicas
empleadas en cualquier desarrollo, y una segunda parte dnde se pone en
desarrollo todo lo expuesto para resolver un caso real en una Comunidad
Autnoma.

Logros:
Se homogeneiz la informacin de todos sus Centros Hospitalarios
pudiendo de esta manera comparar y mejorar el servicio entre los distintos
Centros, permitindole de esta manera una toma de decisiones rpida,
clara y concisa.
Se Consigui hacer accesible la informacin de toda la organizacin a las
diferentes capas de usuarios de una forma fcil y rpida, sin necesidad de
esperar a final de mes o a recoleccin de informacin tarda, manteniendo
una granularidad en la seguridad y asegurando que cada usuario viera lo
que le corresponda.

Anlisis critico
Con la presentes Tesis nos muestra como implementando un BI en una realidad
como un hospital pudo mejorar la gestin hospitalaria, mejorando los procesos de
los accesos a la informacin por las reas que las requeran en un menor tiempo a
lo expuesto, la informacin precisa, clara y consistente, obteniendo una ventaja
competitiva, como BI.

- 15 -
Plan Para Enfocar Las Campaas Bancarias Utilizando DataMining
(MAURICIO, 2006)

Autor(S)
Mauricio Pascual De Luca Venegas.

2006
Lugar
Universidad de Chile
Chile

Resumen
Objetivos:
El objetivo ltimo de la tesis consiste en demostrar que mediante DataMining es
posible elaborar un plan para enfocar la estrategia comercial en los productos de
crditos de consumo, tarjetas y lneas de crdito de un banco pequeo que carece
de un datawarehouse.

La hiptesis consiste en el supuesto de que el conjunto de bases de datos
operacionales que forzosamente cualquier Banco debe poseer proveen
informacin suficiente para elaborar un plan de DataMining como el que se desea
construir. El desarrollo de la tesis, en tanto, consiste en detallar paso a paso con
una metodologa de DataMining (CRISP-DM) como formular un plan para
enfocar las campaas bancarias mediante una segmentacin de riesgo y
rentabilidad basada en modelos predictivos generados a partir de los datos de las
bases operacionales antes mencionados

Anlisis critico
Con la presentes Tesis nos muestra como implementando un BI en una realidad
como un hospital pudo mejorar la gestin hospitalaria, mejorando los procesos de
los accesos a la informacin por las reas que las requeran en un menor tiempo a
lo expuesto, la informacin precisa, clara y consistente, obteniendo una ventaja
competitiva, como BI ayuda a la gestin del conocimiento dentro la organizacin,
pudiendo obtener la informacin necesaria para poder hacer una buena toma de
decisiones para el personal responsable en el nivel estratgico, se reitera
nuevamente que BI es una buena solucin tecnolgica para la organizacin.

- 16 -
2.3.2. Marco Terico
I. Business Intelligence
El termino Business Intelligence (BI), originalmente acuado por Gartner
Group en 1993, es un concepto usado frecuentemente desde dos
perspectivas: una puramente tecnolgica y la otra referida al proceso de
ayuda a la toma de decisiones. La primera hace referencia al conjunto de
soluciones, sistemas y aplicaciones de software dirigidas a recoger,
consolidar, analizar y proveer acceso a informacin que permita a los
usuarios de una organizacin tomar mejores decisiones de negocio. La
segunda se refiere a los procesos para incrementar las ventajas competitivas
de un negocio, mediante el uso inteligente de los datos disponibles para la
toma de decisiones. Esta segunda definicin es la ms interesante y la que
mejor se ajusta al significado del trmino. Lo que debe quedar claro, en
cualquier caso, es que cuando se habla de BI la tecnologa es algo implcito,
ya que el citado proceso utiliza las aplicaciones BI como herramientas
crticas para su desempeo.
Los principales objetivos del BI son: mejorar la planificacin,
productividad, calidad del servicio y rentabilidad del negocio, haciendo que
la informacin sea la ms comprensible, y usando el conocimiento del
negocio lo ms eficazmente posible. En resumen, el BI a utilizar los datos
del negocio como medio para obtener ventajas competitivas.
(BERENGUER. 2004)

Segn (LANGIT, 2007) la visin de BI con SQL Server 2005 se define
como: Inteligencia de Negocios es un mtodo de almacenamiento y
presentacin de datos empresariales clave a fin de que alguien en su
empresa de forma rpida y sencilla puede hacer preguntas de datos precisos
y oportunos. Eficaz BI permite a los usuarios finales utilizar los datos para
entender por qu su empresa obtuvo el resultado que lo hizo, para decidir
sobre los cursos de accin basados en datos anteriores, y para pronosticar de
manera precisa los resultados futuros.
BI datos se muestran de una forma que sea adecuada a cada tipo de usuario,
es decir, los analistas ser capaz de perforar en datos detallados, los
- 17 -
ejecutivos se vea oportuna resmenes, y los mandos medios a ver los datos
presentados en el nivel de detalle que tienen que hacer buenas decisiones de
negocios. Microsoft utiliza los cubos de BI, en lugar de tablas, para
almacenar la informacin y presenta la informacin a travs de informes.
Los informes pueden ser presentados a los usuarios finales en una variedad
de formatos: las aplicaciones de Windows, Aplicaciones Web, Microsoft BI
y herramientas de cliente, como Excel o SQL Reporting Services. En la
figura 1 muestra un tpico BI de una configuracin fsica. Usted nota que
figura una base de datos del servidor de etapas y un servidor de BI. Aunque
es posible colocar todos los componentes de BI en un nico servidor fsico,
la configuracin se muestra en la figura es la ms tpica de los proyectos de
BI.

Figura 1: An enterprise BI configuration
Fuente: (LANGIT 2007).

(ROTAECHE, 2007) define a Business Intelligence como la transformacin
de los datos de la compaa en conocimiento para obtener una ventaja
competitiva. Desde un punto de vista ms pragmtico, y asocindolo
directamente a las tecnologas de la informacin, podemos definir Business
Intelligence como el conjunto de metodologas, aplicaciones y tecnologas
que permiten reunir, depurar y transformar datos de los sistemas
transaccionales e informacin desestructurada (interna y externa a la
compaa) en informacin estructurada, para su explotacin directa
(Reporting, Anlisis OLAP...) o para su anlisis y conversin en
conocimiento soporte a la toma de decisiones sobre el negocio.
- 18 -
Esta definicin pretende abarcar y describir el mbito integral del entorno
BI, reflejado resumidamente en el grfico que aqu se muestra.

Figura 2: Modelo integral de una solucin BI
Fuente: (ROTAECHE, 2007)

Fuente : (STANDILAW, 2009)
Figura 3: Ejemplo De Bussiness Inteligence
- 19 -
Es importante considerar cualquier proyecto BI como un modelo objetivo
integral. Algunas organizaciones han desarrollado proyectos parciales BI,
sin tener en cuenta esta visin global, comprometiendo la calidad y
efectividad de los resultados obtenidos.

Para (BERENGUER, 2004) Los sistemas BI son la ltima generacin de
sistemas DSS; permiten a los usuarios extraer datos de una o ms fuentes
con contenidos diferentes, formatear fcilmente datos para informes y
representaciones graficas, y realizar anlisis multidimensionales.

El surgimiento de estas nuevas tecnologas, as como las nuevas tecnologas
web, ofrecen muchas mayor capacidad a un precio dramticamente menor,
conociendo estas tendencias, es crtico para cualquier negocio,
independientemente del tamao, contar con la mejor tecnologa que puedan
disponer y lograr obtener una ventaja competitiva en el mercado.
Los sistemas actuales de Business Intelligence estn construidos en una
moderna infraestructura, que consisten de una arquitectura modular que
acomoda todos los componentes en un moderno sistema de inteligencia del
negocio.
Estos sistemas incluyen:
a. DataWarehousing y DataMarts, sistemas de almacn de datos.
b. Aplicaciones analticas.
c. DataMining, herramientas para minera de datos.
d. OLAP, herramientas de procesamiento analtico de datos.
e. Herramientas de consulta y reporte de datos.
f. Herramientas de produccin de reportes personalizados.
g. ELT, herramientas de extraccin, traduccin y carga de datos.
h. Herramientas de administracin de sistemas.
i. Portales de informacin empresarial.
j. Sistemas de base de datos.
k. Sistemas de administracin del conocimiento.
- 20 -
Desde luego, una organizacin puede implementar por separado cada una de
stas herramientas y alcanzar un buen nivel de inteligencia, o bien,
implementar una solucin completa de Business Intelligence que muchos
proveedores ofrecen actualmente.
DATAWAREHOUSE
(Kimball ,2002) lo define como: " La conglomeracin de un conjunto de
datos, los cuales se requieren almacenar y presentar de forma organizada.
Los datos de la operacin que se almacenan estn estructurados de tal forma
que puedan ser consultados con el fin de analizarlos. Segn Kimball, podemos
distinguir algunos elementos bsicos del DataWarehouse:

Sistemas de Fuente Operacionales, la arquitectura en la cual se
almacena los datos de la operacin de la empresa.
rea de arreglo de los Datos, donde se ejecutan la depuracin,
estandarizacin y combinacin de los datos de la fuente operacional.
Adems se almacena los datos y se ejecuta procesos de ordenamiento.
rea de Presentacin de los Datos, donde se realiza la carga de los
datos que conforman un DataMart, haciendo uso del modelamiento
dimensional.
Herramientas de Acceso a los Datos, que incluye aplicaciones
para consulta especfica, generadores de reportes, anlisis de
datos, modelamiento de proyecciones y estimacin de resultados.

(PARRACIA, 2003), lo define como Proceso que recopila datos de varias
aplicaciones, en los sistemas operacionales de una organizacin, integra la
informacin en un modelo lgico de reas de tpicos comerciales, la almacena
de modo que resulte accesible a los tomadores de decisiones y se las provee a
travs de herramientas de consulta y generacin de informes. El objetivo es
poner informacin corporativa comparable y estandarizada en manos de
empleados para permitir una visin corporativa amplia de la empresa.

- 21 -
Segn (PARRACIA, 2003), el DW puede verse como una bodega donde estn
almacenados todos los datos necesarios para realizar las funciones de gestin
de la empresa, de manera que puedan utilizarse fcilmente segn se necesiten.
El contenido de los datos, la organizacin y estructura son dirigidos a satisfacer
las necesidades de informacin de analistas.
El datawarehouse intenta responder a la compleja necesidad de obtencin de
informacin til sin el sacrificio del rendimiento de las aplicaciones
operacionales, debido a lo cual se ha convertido actualmente en una de las
tendencias tecnolgicas ms significativas en la administracin de informacin.
Los almacenes de datos (o Datawarehouse) generan bases de datos tangibles
con una perspectiva histrica, utilizando datos de mltiples fuentes que se
fusionan en forma congruente. Estos datos se mantienen actualizados, pero no
cambian al ritmo de los sistemas transaccionales. Muchos Datawarehouse se
disean para contener un nivel de detalle hasta el nivel de transaccin, con la
intencin de hacer disponible todo tipo de datos y caractersticas, para reportar
y analizar. As un datawarehouse resulta ser un recipiente de datos
transaccionales para proporcionar consultas operativas, y la informacin para
poder llevar a cabo anlisis multidimensional. De esta forma, dentro de un
almacn de datos existen dos tecnologas complementarias, una relacional para
consultas y una multidimensional para anlisis.
Existen muchas definiciones para el DW, la ms conocida fue propuesta por

Figura 4: The Business Intelligence process from end to end
Fuente: (MCGRAWHILL, 2008)
- 22 -
(B. INMON, 2004) en 1992: Un DW es una coleccin de datos orientados a
temas, integrados, no-voltiles y variante en el tiempo, organizados para
soportar necesidades empresariales.

En 1993, (SUSAN OSTERFELDT, 2004) publica una definicin que sin duda
acierta en la clave del DW: Yo considero al DW como algo que provee dos
beneficios empresariales reales: Integracin y Acceso de datos. DW elimina
una gran cantidad de datos intiles y no deseados, como tambin el
procesamiento desde el ambiente operacional clsico.

Esta ltima definicin refleja claramente el principal beneficio que el
datawarehouse aporta a la empresa, eliminar aquellos datos que obstaculizan la
labor de anlisis de informacin y entregar la informacin que se requiere en la
forma ms apropiada, facilitando as el proceso de gestin.

Segn (PARRACIA, 2003) las principales caractersticas que posee un
DataWarehouse son:

Es orientado a la informacin relevante de la organizacin:

En un DataWarehouse la informacin se clasifica en base a los aspectos
de inters para la empresa, es decir, se disea para consultar
eficientemente informacin relativa a las actividades bsicas de la
organizacin, como ventas, compras y produccin, y no para soportar
los procesos que se realizan en ella, como gestin de pedidos,
facturacin, etc.

Es integrado: integra datos recogidos de diferentes sistemas
operacionales de la organizacin y/o fuentes externas. Esta integracin
se hace estableciendo una consistencia en las convenciones para
nombrar los datos, en la definicin de las claves, y en las medidas
uniformes de los datos.

- 23 -
Es variable en el tiempo: los datos son relativos a un periodo de tiempo
y deben ser incrementados peridicamente. La informacin almacenada
representa fotografas correspondientes a ciertos perodos de tiempo.

Es no voltil: la informacin no se modifica despus de que se inserta, solo se
incrementa. El periodo cubierto por un DataWarehouse vara de 2 a 10 aos.

2.1. Arquitectura Datawarehouse

Podemos dividirla en dos tipos: De acuerdo a (ZVENGER, 2005)

2.1.1. Diseo Lgico

Existen algunos requerimientos que debe cubrir un diseo lgico para
un Datawarehouse.

Preparar el Datawarehouse para soportar la recuperacin de
una gran cantidad de filas de datos en forma rpida.

La mayora de los analistas de negocios van a querer ver datos
totalizados. Estos datos en lo posible deben pre-calcularse y
almacenarse de antemano para que esta recuperacin sea
rpida y eficiente. Es importante adems discutir el nivel de
granularidad y de detalle esperado por los analistas cuando
hacen operaciones de DRILLDOWN.

El diseo debe estar conducido por el acceso y por el uso, es
decir, teniendo en cuenta qu tipo de reportes o resmenes son
los ms frecuentes, y cules los ms urgentes.

Un diseo normalizado no es bueno, no solo por lo
mencionado en la seccin anterior, sino porque no resulta
- 24 -
demasiado intuitivo para una persona de negocios, y podra
volverse demasiado complejo.

Todos los datos que se incluyan ya deben existir en las fuentes
de datos operacionales, o ser derivables a partir de ellos.

Las dos tcnicas de diseo ms populares de almacenamiento lgico
de un Datawarehouse son las siguientes:

2.1.1.1. Esquema Estrella.

Este esquema est formado por un elemento central que consiste
en una tabla llamada la Tabla de Hechos, que est conectada a
varias Tablas de Dimensiones.
Las tablas de hechos contienen los valores pre-calculados que
surgen de totalizar valores operacionales atmicos segn las
distintas dimensiones, tales como clientes, productos o perodos
de tiempo. Las tablas de hechos representan un evento crtico y
cuantificable en el negocio, como ventas o costos.

Su clave est compuesta por las claves primarias de las tablas de
dimensin relacionadas (las FOREIGN KEYS).
Pueden existir varias tablas de hechos con informacin
redundante, porque podran contener distintos niveles de
agregacin de los mismos datos. Por ejemplo podra existir una
tabla de hechos para las Ventas por Sucursal, Regin y Fecha, otra
para Ventas por Productos, Sucursal y Fecha, y otra para Ventas
por Cliente, Regin y Fecha.

En general las tablas de hechos tienen muchas filas y
relativamente pocas columnas. Las tablas de dimensin
representan las diferentes perspectivas desde donde se ven y
analizan los hechos de la tabla de hechos. A diferencia de las
anteriores, su clave primaria est formada por un solo atributo, y
- 25 -
su caracterstica principal es que estn desnormalizadas. Esto
significa que si la dimensin incluye una jerarqua, las columnas
que la definen se almacenan en la misma tabla dando lugar a
valores redundantes, lo cual es aceptable en este esquema.

En general suelen tener muchas columnas pero pocas filas.
Siempre que sea posible, es conveniente compartir las tablas de
dimensin entre distintas tablas de hechos.

Una de las dimensiones ms comunes es la que representa el
tiempo, con atributos que describen periodos para aos,
cuatrimestres, periodos fiscales, y periodos contables.

Otras dimensiones comunes son las de clientes, productos,
representantes de ventas, regiones, sucursales.

El esquema estrella es el ms usado porque maneja bien la
performance de consultas y reportes que incluyen aos de datos
histricos, y por su simplicidad en comparacin con una base de
datos normalizada.

En la siguiente figura vemos un ejemplo de esquema Estrella,
donde la tabla de hechos es la tabla Ventas, y el resto son las
tablas de dimensiones.

Fuente: (ZVENGER, 2005)
Figura 5: Modelo Estrella
- 26 -
2.1.1.2. Esquema Copo de Nieve.

Es una variante del esquema estrella en el cual las tablas de
dimensin estn normalizadas, es decir, pueden incluir claves
que apuntan a otras tablas de dimensin.

Las ventajas de esta normalizacin son la reduccin del tamao y
redundancia en las tablas de dimensin, y un aumento de
flexibilidad en la definicin de dimensiones.
Sin embargo, el incremento en la cantidad de tablas hace que se
necesiten ms operaciones de unin para responder a las
consultas, lo que empeora la performance, adems del
mantenimiento que requieren las tablas adicionales.

En la siguiente figura vemos un esquema similar al anterior,
donde la tabla de dimensin Sucursal se expande en las tablas
Distrito y Regin. Ahora la tabla Sucursal contiene una columna
clave DistritoId que apunta a la tabla Distrito, y esta a su vez
tiene una columna RegionId que apunta a la tabla de dimensin
Regin.

Fuente :(ZVENGER, 2005)
Figura 6: Modelo de Copo de Nieve
- 27 -
2.1.2. Diseo Fsico

Debido a que los DataWarehouses trabajan tanto con datos detallados
como con datos resumidos, y frecuentemente almacenan algunos datos
en forma redundante, el tamao de estas bases de datos puede ser
enorme. Las bases de datos que se acercan o exceden el terabyte son
llamadas VLDBs (Very Large Databases). Disear una base de datos
de este tipo es un gran desafo y la tarea de mantenerlas es
demandante.

Entre las decisiones de implementacin que se deben tomar se
incluyen el tamao del espacio libre, el tamao del buffer, el tamao
del bloque, y si se usa o no una tcnica de compactacin de la base de
datos. Todas estas cuestiones afectaran la performance del
DataWarehouse.

A continuacin se detallan algunos temas que impactan sobre el diseo
fsico del DataWarehouse segn (ZVENGER, 2005)

2.1.2.1. Particionamiento

Las tablas deben particionarse y ubicarse en varios discos. Esto es
ms que nada importante en las VLDBs, donde las tablas de
hechos pueden llegar a ocupar varios cientos de gigabytes. El
particionamiento permite que los datos de una tabla lgica se
repartan en mltiples conjuntos de datos fsicos. Este
particionamiento se basa en una columna de la tabla de hechos,
que comnmente es la columna que indica la fecha. Dado que la
columna por la cual se particiones tiene que ser parte de la clave
primaria, no puede ser una columna derivada ni contener valores
nulos.

- 28 -
El particionamiento es importante porque permite que se hagan
backups y restauraciones de porciones de una tabla sin impactar
en la accesibilidad de otras porciones en la misma tabla que no
estn siendo backapeadas ni restauradas en ese momento.

Otra ventaja del particionamiento es la opcin de almacenar los
datos ms frecuentemente accedidos en dispositivos ms rpidos,
o guardar distintos niveles de agregaciones en diferentes
plataformas, por ejemplo, ubicar los datos totalizados en
servidores distribuidos y mantener los datos detallados en un
mainframe.

2.1.2.2. Clustering

Es una tcnica muy til para el acceso secuencial de grandes
cantidades de datos. El clustering se obtiene definiendo un ndice
clustering para una tabla, el cual determina el orden secuencial
fsico en el que se almacenan las filas en los conjuntos de datos.
Esta tcnica es importante porque mejora drsticamente la
performance del acceso secuencial, y este tipo de acceso es el ms
usado en el procesamiento OLAP. Cuando las filas de la tabla no
permanezcan almacenadas en el orden correspondiente a su ndice
clustering, situacin conocida como fragmentacin, la
performance bajar y habr que reorganizar la tabla.

2.1.2.3. Indexado

Existen dos estrategias extremas de indexado: una es indexar
todo, y la otra es no indexar nada, pero ninguna de las dos es
conveniente. Las columnas que se elijan para indexar deben ser
las que se usan ms frecuentemente para recuperar las filas, y las
que tienen una alta distribucin de valores, no una baja como por
ejemplo Cdigo Postal.
- 29 -

Una vez que se determinan las columnas a indexar, hay que
determinar la estrategia de ndice. La mayora de las DBMSs
proveen varios algoritmos, entre ellos B-tree, Hash, archivo
Invertido, Sparse y Binario. Se debera optar por el ms ptimo
para el producto DBMSs que se est usando.

2.1.2.4. Reorganizaciones

Las cargas incrementales de las bases de datos irn fragmentando
las tablas, y esta fragmentacin puede resultar en un decaimiento
de la performance. La mayora de las DBMSs proveen rutinas de
reorganizacin para reclamar el espacio fragmentado y mover
registros.
Las actividades bsicas involucradas en la reorganizacin de una
base de datos implican copiar la base de datos vieja en otro
dispositivo, rebloquear las filas y recargarlas. Estas tareas no son
triviales en un DataWarehouse, pero todos los DBMSs permiten
reorganizar particiones, lo cual es otra buena razn para
particionar las tablas.

2.1.2.5. Backup y Recupero

Los DBMSs proveen utilidades para hacer backups completos y
tambin incrementales. Muchas organizaciones tienen la errnea
impresin de que los DataWarehouses siempre se pueden recrear
a partir de las fuentes de datos originales. Sin embargo, adems de
que esta tarea puede llevar mucho tiempo porque hay que
reejecutar los programas de extraccin, transformacin y carga, es
posible que estos programas y los datos mismos ya no estn
disponibles.

- 30 -
2.1.2.6. Ejecucin de las consultas en paralelo

Para mejorar la performance de una consulta es mejor dividirla en
componentes que ejecuten concurrentemente. Algunos DBMSs
ofrecen ejecucin paralela en forma transparente, es decir, dividen
la consulta por si solos.

Los DBMSs estn basados en reglas internas intrincadas, que
deben entenderse y seguirse. Para esto las organizaciones
contratan administradores de bases de datos. Una situacin comn
es que se deje el diseo de la base de datos a los programadores,
quienes quiz no estn del todo familiarizados con el
funcionamiento interno del motor, y como consecuencia creen un
diseo pobre que no aproveche al mximo las caractersticas que
brinda el producto.

2.2. Elementos constituyentes de una Arquitectura Data Warehouse

De acuerdo a (CESARES, 2009), Claudio una arquitectura Data Warehouse
(Data Warehouse Architecture - DWA) es una forma de representar la
estructura total de datos, comunicacin, procesamiento y presentacin, que
existe para los usuarios finales que disponen de una computadora dentro de la
empresa.

La arquitectura se constituye de un nmero de partes interconectadas:

Base de datos operacional / Nivel de base de datos externo
Nivel de acceso a la informacin
Nivel de acceso a los datos
Nivel de directorio de datos (Metadata)
Nivel de gestin de proceso
Nivel de mensaje de la aplicacin
- 31 -
Nivel de datawarehouse
Nivel de organizacin de datos

2.2.1. Base de datos operacional / Nivel de base de datos externo

Los sistemas operacionales procesan datos para apoyar las
necesidades operacionales crticas. Para hacer eso, se han creado las
bases de datos operacionales histricas que proveen una estructura de
procesamiento eficiente, para un nmero relativamente pequeo de
transacciones comerciales bien definidas.
Sin embargo, a causa del enfoque limitado de los sistemas
operacionales, las bases de datos diseadas para soportar estos
sistemas, tienen dificultad al acceder a los datos para otra gestin o
propsitos informticos.

Esta dificultad en acceder a los datos operacionales es amplificada
por el hecho que muchos de estos sistemas tienen de 10 a 15 aos de
antigedad. El tiempo de algunos de estos sistemas significa que la
tecnologa de acceso a los datos disponible para obtener los datos
operacionales, es as mismo antigua.

Fuente: (CESARES, 2009)

Figura 7: Arquitectura de un DataWarehouse en la Empresa
- 32 -
Ciertamente, la meta del Datawarehousing es liberar la informacin
que es almacenada en bases de datos operacionales y combinarla con
la informacin desde otra fuente de datos, generalmente externa.

Cada vez ms, las organizaciones grandes adquieren datos
adicionales desde bases de datos externas. Esta informacin incluye
tendencias demogrficas, economtricas, adquisitivas y competitivas
(que pueden ser proporcionadas por
Instituciones Oficiales - INEI). Internet o tambin llamada
"information superhighway" (supercarretera de la informacin)
provee el acceso a ms recursos de datos todos los das.

2.2.2. Nivel de acceso a la informacin

El nivel de acceso a la informacin de la arquitectura datawarehouse,
es el nivel del que el usuario final se encarga directamente. En
particular, representa las herramientas que el usuario final
normalmente usa da a da. Por ejemplo: EXCEL, LOTUS 1-2-3,
FOCUS, ACCESS, SAS, etc.
Este nivel tambin incluye el hardware y software involucrados en
mostrar informacin en pantalla y emitir reportes de impresin, hojas
de clculo, grficos y diagramas para el anlisis y presentacin. Hace
dos dcadas que el nivel de acceso a la informacin se ha expandido
enormemente, especialmente a los usuarios finales quienes se han
volcado a los PCS monousuarios y los PCS en redes.

Actualmente, existen herramientas ms y ms sofisticadas para
manipular, analizar y presentar los datos, sin embargo, hay problemas
significativos al tratar de convertir los datos tal como han sido
recolectados y que se encuentran contenidos en los sistemas
operacionales en informacin fcil y transparente para las
herramientas de los usuarios finales. Una de las claves para esto es
encontrar un lenguaje de datos comn que puede usarse a travs de
toda la empresa.
- 33 -

2.2.3. Nivel de acceso a los datos

El nivel de acceso a los datos de la arquitectura datawarehouse est
involucrado con el nivel de acceso a la informacin para conversar en
el nivel operacional. En la red mundial de hoy, el lenguaje de datos
comn que ha surgido es SQL.
Originalmente, SQL fue desarrollado por IBM como un lenguaje de
consulta, pero en los ltimos veinte aos ha llegado a ser el estndar
para el intercambio de datos.
Uno de los adelantos claves de los ltimos aos ha sido el desarrollo
de una serie de "filtros" de acceso a datos, tales como EDA/SQL para
acceder a casi todo los Sistemas de Gestin de Base de Datos (Data
Base Management Systems - DBMSs) y sistemas de archivos de
datos, relacionales o no. Estos filtros permiten a las herramientas de
acceso a la informacin, acceder tambin a la data almacenada en
sistemas de gestin de base de datos que tienen veinte aos de
antigedad.

El nivel de acceso a los datos no solamente conecta DBMSS
diferentes y sistemas de archivos sobre el mismo hardware, sino
tambin a los fabricantes y protocolos de red. Una de las claves de
una estrategia Datawarehousing es proveer a los usuarios finales con
"acceso a datos universales".
El acceso a los datos universales significa que, tericamente por lo
menos, los usuarios finales sin tener en cuenta la herramienta de
acceso a la informacin o ubicacin, deberan ser capaces de acceder
a cualquier o todos los datos en la empresa que es necesaria para
ellos, para hacer su trabajo.

El nivel de acceso a los datos entonces es responsable de la interfaces
entre las herramientas de acceso a la informacin y las bases de datos
operacionales. En algunos casos, esto es todo lo que un usuario final
- 34 -
necesita. Sin embargo, en general, las organizaciones desarrollan un
plan mucho ms sofisticado para el soporte del datawarehousing.

2.2.4. Nivel de Directorio de Datos (Metadata)

A fin de proveer el acceso a los datos universales, es absolutamente
necesario mantener alguna forma de directorio de datos o repositorio
de la informacin metadata.

La metadata es la informacin alrededor de los datos dentro de la
empresa. Las descripciones de registro en un programa COBOL son
metadata. Tambin lo son las sentencias DIMENSION en un
programa FORTRAN o las sentencias a crear en SQL.
A fin de tener un depsito totalmente funcional, es necesario tener
una variedad de metadata disponibles, informacin sobre las vistas de
datos de los usuarios finales e informacin sobre las bases de datos
operacionales. Idealmente, los usuarios finales deberan de acceder a
los datos desde el datawarehouse (o desde las bases de datos
operacionales), sin tener que conocer dnde residen los datos o la
forma en que se han almacenados.

2.2.5. Nivel de Gestin de Procesos

El nivel de gestin de procesos tiene que ver con la programacin de
diversas tareas que deben realizarse para construir y mantener la
datawarehouse y la informacin del directorio de datos. Este nivel
puede depender del alto nivel de control de trabajo para muchos
procesos (procedimientos) que deben ocurrir para mantener el
datawarehouse actualizado.

- 35 -
2.2.6. Nivel de Mensaje de la Aplicacin

El nivel de mensaje de la aplicacin tiene que ver con el transporte de
informacin alrededor de la red de la empresa. El mensaje de
aplicacin se refiere tambin como "subproducto", pero puede
involucrar slo protocolos de red. Puede usarse por ejemplo, para
aislar aplicaciones operacionales o estratgicas a partir del formato de
datos exacto, recolectar transacciones o los mensajes y entregarlos a
una ubicacin segura en un tiempo seguro.

2.2.7. Nivel DataWarehouse (Fsico)

En la datawarehouse (ncleo) es donde ocurre la data actual, usada
principalmente para usos estratgicos. En algunos casos, uno puede
pensar del datawarehouse simplemente como una vista lgica o
virtual de datos. En muchos ejemplos, el datawarehouse puede no
involucrar almacenamiento de datos.

En un datawarehouse fsico, copias, en algunos casos, muchas copias
de datos operacionales y/o externos, son almacenadas realmente en
una forma que es fcil de acceder y es altamente flexible. Cada vez
ms, los datawarehouses son almacenados sobre plataformas
cliente/servidor, pero por lo general se almacenan sobre mainframes.

2.2.8. Nivel de Organizacin de Datos

(CESARES) afirma que el componente final de la arquitectura
datawarehouse es la organizacin de los datos. Se llama tambin
gestin de copia o rplica, pero de hecho, incluye todos los procesos
necesarios como seleccionar, editar, resumir, combinar y cargar
datos en el depsito y acceder a la informacin desde bases de datos
operacionales y/o externas.

- 36 -
La organizacin de datos involucra con frecuencia una programacin
compleja, pero cada vez ms, estn crendose las herramientas
datawarehousing para ayudar en este proceso. Involucra tambin
programas de anlisis de calidad de datos y filtros que identifican
modelos y estructura de datos dentro de la data operacional existente.
2.3. Operaciones en un DataWarehouse

De acuerdo a (CESARES), en la Figura N 6 se muestra algunos de los tipos
de operaciones que se efectan dentro de un ambiente datawarehousing.

Fuente :(CESARES)

2.3.1. Sistemas Operacionales

Los datos administrados por los sistemas de aplicacin operacionales
son la fuente principal de datos para el datawarehouse. Las bases de
datos operacionales se organizan como archivos indexados (UFAS,
VSAM), bases de datos de redes/jerrquicas (I-D-S/II, IMS, IDMS) o
sistemas de base de datos relacionales (DB2, ORACLE, INFORMIX,
etc.). Segn las encuestas, aproximadamente del 70% a 80% de las
Figura N 8: Tipos de Operaciones con el DataWarehouse
- 37 -
bases de datos de las empresas se organizan usando DBMSS no
relacional.

2.3.2. Extraccin, Transformacin y Carga de los Datos

Se requieren herramientas de gestin de datos para extraer datos desde
bases de datos y/o archivos operacionales, luego es necesario
manipular o transformar los datos antes de cargar los resultados en el
datawarehouse.

Tomar los datos desde varias bases de datos operacionales y
transformarlos en datos requeridos para el depsito, se refiere a la
transformacin o a la integracin de datos. Las bases de datos
operacionales, diseadas para el soporte de varias aplicaciones de
produccin, frecuentemente difieren en el formato.
Los mismos elementos de datos, si son usados por aplicaciones
diferentes o administrados por diferentes software DBMS, pueden
definirse al usar nombres de elementos inconsistentes, que tienen
formatos inconsistentes y/o ser codificados de manera diferente. Todas
estas inconsistencias deben resolverse antes que los elementos de datos
sean almacenados en el datawarehouse.

2.3.4. Metadata

Otro paso necesario es crear la metadata. La metadata (es decir, datos
acerca de datos) describe los contenidos del datawarehouse. La
metadata consiste de definiciones de los elementos de datos en el
depsito, sistema(s) del (os) elemento(s) fuente. Como la data, se
integra y transforma antes de ser almacenada en informacin similar.

- 38 -
2.3.5. Acceso de usuario final

Los usuarios acceden al datawarehouse por medio de herramientas de
productividad basadas en GUI (Graphical User Interface - Interface
grfica de usuario). Pueden proveerse a los usuarios del data
warehouse muchos de estos tipos de herramientas.
Estos pueden incluir software de consultas, generadores de reportes,
procesamiento analtico en lnea, herramientas data/visual mining, etc.,
dependiendo de los tipos de usuarios y sus requerimientos particulares.
Sin embargo, una sola herramienta no satisface todos los
requerimientos, por lo que es necesaria la integracin de una serie de
herramientas.

2.3.6. Plataforma del DataWarehouse

Segn (CESARES) La plataforma para el datawarehouse es casi
siempre un servidor de base de datos relacional. Cuando se
manipulan volmenes muy grandes de datos puede requerirse una
configuracin en bloque de servidores UNIX con multiprocesador
simtrico (SMP) o un servidor con procesador paralelo masivo (MPP)
especializado.

Los extractos de la data integrada/transformada se cargan en el
datawarehouse.

Uno de los ms populares RDBMSs disponibles para
Datawarehousing sobre la plataforma UNIX (SMP y MPP)
generalmente es Teradata. La eleccin de la plataforma es crtica. El
depsito crecer y hay que comprender los requerimientos despus de
3 o 5 aos.

Muchas de las organizaciones quieran o no escogen una plataforma
por diversas razones: el Sistema X es nuestro sistema elegido o el
Sistema Y est ya disponible sobre un sistema UNIX que nosotros ya
- 39 -
tenemos. Uno de los errores ms grandes que las organizaciones
cometen al seleccionar la plataforma, es que ellos presumen que el
sistema (hardware y/o DBMS) escalar con los datos.

El sistema de depsito ejecuta las consultas que se pasa a los datos por
el software de acceso a los datos del usuario. Aunque un usuario
visualiza las consultas desde el punto de vista de un GUI, las consultas
tpicamente se formulan como pedidos SQL, porque SQL es un
lenguaje universal y el estndar de hecho para el acceso a datos.

2.4. Almacenamiento OLAP

Segn (ZVENGER, 2005) OLAP se define como el anlisis
multidimensional e interactivo de la informacin de negocios a escala
empresarial. El anlisis multidimensional consiste en combinar distintas
reas de la organizacin, y as ubicar ciertos tipos de informacin que
revelen el comportamiento del negocio. .

Los usuarios de herramientas OLAP se mueven desde una perspectiva de
negocio a otra, por ejemplo, pueden estar observando las ventas anuales por
sucursal y pasar a ver las sucursales con ms ganancias en los ltimos tres
meses, y adems con la posibilidad de elegir entre diferentes niveles de
detalle, como ventas por da, por semana o por cuatrimestre. Es esta
exploracin interactiva lo que distingue a OLAP de las herramientas simples
de consulta y reportes.

(ZVENGER, 2005) afirma que El anlisis multidimensional, permite a los
analistas de negocios examinar sus indicadores clave o medidas, como
ventas, costos, y ganancias, desde distintas perspectivas, como periodos de
tiempo, productos, regiones. Estas perspectivas constituyen las dimensiones
desde las que se explora la informacin.

- 40 -
La escala empresarial, se refiere a que OLAP trabaja con fuentes de datos
corporativos, que contienen datos de toda la empresa.

Para proveer estas caractersticas, toda herramienta OLAP tiene tres
principales caractersticas:

Un modelo multidimensional de la informacin para el anlisis
interactivo.
Un motor OLAP que procesa las consultas multidimensionales sobre
los datos.
Un mecanismo de almacenamiento para guardar los datos que se van a
analizar. Este componente puede ser externo a la herramienta, como un
RDBMS o un DataWarehouse.

La herramienta no solo permite flexibilidad en cuanto a la navegacin por el
modelo multidimensional de la informacin, sino que tambin es flexible en
la definicin de los reportes y aplicaciones que se construyen a partir de ella.

2.4.1. CUBOS MULTIDIMENSIONALES

Segn (ZVENGER, 2005) en una base de datos multidimensional, el
modelo de datos est constituido por lo que se denomina un Cubo
multidimensional o simplemente Cubo. En un cubo la informacin se
representa por medio de matrices multidimensionales o cuadros de
mltiples entradas, que nos permite realizar distintas combinaciones de
sus elementos para visualizar los resultados desde distintas
perspectivas y variando los niveles de detalle. Esta estructura es
independiente del sistema transaccional de la organizacin, facilita y
agiliza la consulta de informacin histrica ofreciendo la posibilidad
de navegar y analizar los datos.

Aqu vemos como ejemplo un cubo multidimensional que contiene
informacin de ventas discriminadas por periodos de tiempo,
productos y zonas geogrficas de la empresa.
- 41 -

Los ejes del cubo son las Dimensiones, y los valores que se presentan
en la matriz, son las Medidas.

2.4.2. DIMENSIONES

Segn (ZVENGER, 2005) las dimensiones son objetos del negocio
con los cuales se puede analizar la tendencia y el comportamiento del
mismo. Las definiciones de las dimensiones se basan en polticas de la
compaa o del mercado, e indican la manera en que la organizacin
interpreta o clasifica su informacin para segmentar el anlisis en
sectores, facilitando la observacin de los datos.

Para determinar las dimensiones requeridas para analizar los datos
podemos hacer preguntas como: Cundo, Dnde, Qu, Quin, Cul,
etc.

Fuente: (PREZ)
Figura N 9: Diagrama de Cubo Multidimensional
- 42 -
2.4.3. MEDIDAS O METRICAS

Segn (ZVENGER, 2005) son caractersticas cualitativas o
cuantitativas de los objetos que se desean analizar en las empresas. Las
medidas cuantitativas estn dadas por valores o cifras porcentuales.

Por ejemplo, las ventas en dlares, cantidad de unidades en stock,
cantidad de unidades de producto vendidas, horas trabajadas, el
promedio de piezas producidas, el porcentaje de aceptacin de un
producto, el consumo de combustible de un vehculo, etc.

2.4.4. JERARQUIAS DE DIMENSIONES Y NIVELES

Segn (ZVENGER, 2005) generalmente las dimensiones se
estructuran en jerarquas, y en cada jerarqua existen uno o ms
niveles, los llamados Niveles de Agregacin o simplemente Niveles.
Toda dimensin tiene por lo menos una jerarqua con un nico nivel.
En la figura vemos un ejemplo de una dimensin de vendedores, que
consiste de una nica jerarqua, y tres niveles de agregacin para
agruparlos por ciudades y por regiones.

Figura N 10: Ejemplo de Jerarquizacion de Dimensiones y Niveles.
- 43 -
En el grafico anterior, los niveles de Zonas y Gerencia no estn
relacionados entre s, a pesar de que ambos estn relacionados con las
reas.

Segn (MNDEZ) en la figura 09 el diseo representa una
transferencia fundamental desde los sistemas de soporte de decisin
convencionales. Ms que simplemente proveer datos a los usuarios
finales a travs de software de consultas y reportes, el server de
DataMining aplica los modelos de negocios del usuario directamente
al DataWarehouse y devuelve un anlisis proactivo de la informacin
ms relevante.

Estos resultados mejoran los metadatos en el server OLAP proveyendo
un estrato de metadatos que representa una vista fraccionada de los
datos.

Fuente: (MNDEZ)
Figura N 11: Pirmide de Niveles
- 44 -
2.5. ESTRATEGIAS DE ALMACENAMIENTO. (ROLAP, MOLAP,
HOLAP)

Las bases de datos relacionales estn optimizadas para obtener una
performance ptima en consultas simples y frecuentes, pero no funcionan
de manera ideal para las consultas multidimensionales y complejas de estas
aplicaciones, ya que existen muchas de ellas que no se pueden expresar en
una nica consulta SQL, y seguramente se requerirn muchas operaciones
de JOIN, lo cual reduce drsticamente el tiempo de respuesta de la
consulta.

Para cubrir estas deficiencias surgieron tres estrategias de almacenamiento:

Bases de datos multidimensionales especializadas, que proveen
almacenamiento y recupero de datos optimizado para consultas
OLAP.
DataWarehouses, construidos sobre una tecnologa relacional, pero
la optimizacin se dirige al soporte de decisiones en lugar de a las
operaciones transaccionales.
Una tercera estrategia que consiste en la combinacin de las dos
anteriores.
Las herramientas OLAP que usan almacenamiento
multidimensional son llamadas MOLAP, mientras que a las que
almacenan los datos en bases relacionales se les llama herramientas
ROLAP. Las herramientas que combinan los dos enfoques se
conocen como OLAP Hbrido u HOLAP.

Cada alternativa tiene sus ventajas y desventajas. En lugar de discutir cual
de las dos es mejor hay que definir un criterio para optar por una u otra, y
evaluar el alcance de HOLAP, que en la prctica intenta combinar lo mejor
de ambos mundos.

- 45 -
Algunas de las ventajas ms importantes de cada enfoque segn
(ZVENGER, 2005) son:

2.5.1. MOLAP

Buena performance en las consultas, ya que el almacenamiento esta
optimizado para el anlisis multidimensional.
La escalabilidad est limitada por la capacidad del Motor de
Base de Datos y por el tiempo de carga de los datos.
En general el anlisis est limitado a los datos totalizados o
sumarizados.
El modelo multidimensional no es lo suficientemente flexible como
para acomodarse a las necesidades constantemente cambiantes del
negocio.
La estructura que guarda los datos est incluida en la herramienta.
Requiere una capa adicional de manejo de datos.
No incluye soporte de paralelismo, replicacin ni recuperacin de
datos.
Puede requerir aprendizaje por ser una tecnologa nueva en la
organizacin.

2.5.2. ROLAP

La performance de las consultas no es tan ptima como en
MOLAP.
Es capaz de manejar conjuntos de datos muy grandes, por encima de
un terabyte.
Adems del anlisis de informacin sumarizados, se pueden analizar
datos detallados hasta el nivel de las transacciones.
Es capaz de analizar los datos desde cualquier perspectiva en
cualquier momento.
La herramienta ROLAP requiere un DataWarehouse de donde
extraer los datos para analizar.
- 46 -
Las cuestiones tcnicas del manejo de los datos est a cargo del
Motor de Base de Datos.

2.6. CONCEPTUALIZACIONES SOBRE TRANSFORMACION Y CARGA
DE DATOS.
2.6.1. MIGRACION DE DATOS: EXTRACCION,
TRANSFORMACION Y CARGA
La migracin de los datos desde las fuentes operacionales al
DataWarehouse requiere la necesidad de procesos para extraer,
transformar y cargar los datos, actividad que se conoce como ETL.

La mayora de los datos de origen son los datos operacionales actuales,
aunque parte de ellos pueden ser datos histricos archivados.

Si los requerimientos de datos incluyen algunos aos de historia es
necesario desarrollar tres conjuntos de programas ETL: una Carga
Inicial, una Carga Histrica, y una Carga Incremental.

2.6.1.1. Carga Inicial

La carga inicial se asemeja mucho al proceso de conversin
entre sistemas que se da en las organizaciones cuando pasan,
por ejemplo, de sus viejos sistemas operacionales a un
producto ERP.

2.6.1.2. Carga Histrica

Este proceso debe verse como una extensin de la carga
inicial, pero la conversin aqu es un poco diferente porque los
datos histricos son datos estticos.

A diferencia de los datos operacionales, los datos estticos ya
se archivaron en dispositivos de almacenamiento offline. Es
- 47 -
comn que con el transcurso del tiempo se eliminen elementos
de datos que ya no sirven, se agreguen nuevos, se modifiquen
los tipos de ciertos datos o los formatos de los registros, lo que
implica que los datos histricos no necesariamente se puedan
sincronizar con los datos operacionales. Por lo tanto los
programas de conversin escritos para la carga inicial quiz no
sean aplicables a la carga de datos histricos sin algunos
cambios previos.

2.6.1.3. Carga Incremental

Una vez que el DataWarehouse est cargado con datos
inciales e histricos, hay que desarrollar otro proceso para la
carga incremental, que se ejecutar mensual, semanal o
diariamente. Existen dos formas de disear la carga
incremental:

Extraer todos los registros: Se extraen todos los
registros operacionales, independientemente de los
valores que hayan cambiado desde la ltima carga
realizada.
En general esta opcin no es viable debido al volumen
de los datos, por eso la mayora opta por la siguiente
opcin.
Extraer Deltas solamente: Solo se extraen registros
nuevos o registros que contengan valores que
cambiaron desde la ltima carga realizada.
Disear programas ETL para extracciones delta es ms
fcil cuando las fuentes consisten en bases de datos
relacionales y contamos con una columna timestamp
para determinar los deltas. .

Expliquemos ahora, lo que debe contemplar este proceso:
- 48 -
A. Extraer los Datos.

Que consiste en determinar tcnicas, para combinar
eficiencia en el uso de la data de origen, as como detectar
redundancias y datos y algn otro ruido. Adems, hay que
distinguir un dato que puede estar duplicado en distintas
tablas.
B. Transformar Datos.

Este proceso es el ms crtico, debido a que debe controlar
algunos factores: Claves primarias inconsistentes, valores
inconsistentes, datos con diferentes formatos, valores
errneos, sinnimos y homnimos, Lgica embebida,
Integracin y Derivacin, etc. descrito en la figura vemos
algunos ejemplos de transformacin de datos: El primero
referente a sexo, el segundo referente a unidades de
medida, el tercero se refiere a estandarizar nombres, y por
ltimo, estandarizar formatos de fecha.

Figura N 12: Diagrama de Transformacin de Datos
para el poblamiento del Datawarehouse
- 49 -
C. Cargar Datos.

Este paso, es el ms simple, y sera el que completara el
proceso ETL. Aqu se tendra que tener cuidado,
bsicamente con los ndices, y a la integridad referencial.

2.6.2. Impactos DW

El xito de DW no est en su construccin, sino en usarlo para mejorar
procesos empresariales, operaciones y decisiones. Posicionar un DW
para que sea usado efectivamente, requiere entender los impactos de
implementacin en los siguientes mbitos:

2.6.2.1. Impactos Humanos.
Efectos sobre la gente de la empresa:
Segn (WOLFF), Carmen la Construccin del DW: Construir
un DW requiere la participacin activa de quienes usarn el
DW. A diferencia del desarrollo de aplicaciones, donde los
requerimientos de la empresa logran ser relativamente bien
definidos producto de la estabilidad de las reglas de negocio a
travs del tiempo, construir un DW depende de la realidad de
la empresa como de las condiciones que en ese momento
existan, las cuales determinan qu debe contener el DW. La
gente de negocios debe participar activamente durante el
desarrollo del DW, desde una perspectiva de construccin y
creacin.

El accesado el DW: El DW intenta proveer los datos que
posibilitan a los usuarios accesar su propia informacin
cuando ellos la necesitan. Esta aproximacin para entregar
informacin tiene varias implicancias:

a) La gente de la empresa puede necesitar aprender nuevas
destrezas.
- 50 -
b) Anlisis extensos y demoras de programacin para
obtener informacin ser eliminada. Como la informacin
estar lista para ser accesada, las expectativas
probablemente aumentarn.
c) Nuevas oportunidades pueden existir en la comunidad
empresarial para los especialistas de informacin.
d) La gran cantidad de reportes en papel sern reducidas o
eliminadas.
e) La madurez del DW depender del uso activo y
retroalimentacin de sus usuarios.

El Usando aplicaciones DSS/EIS: usuarios de aplicaciones
DSS y EIS necesitarn menos experiencia para construir su
propia informacin y desarrollar nuevas destrezas.

2.6.2.2. Impactos Empresariales.

Los Procesos Empresariales Y Decisiones Empresariales. Se
deben considerar los beneficios empresariales potenciales de los
siguientes impactos:

a) Los Procesos de Toma de Decisiones pueden ser
mejorados mediante la disponibilidad de informacin.
Decisiones empresariales se hacen ms rpidas por gente
ms informada.
b) Los procesos empresariales pueden ser optimizados. El
tiempo perdido esperando por informacin que finalmente
es incorrecta o no encontrada, es eliminado.
c) Conexiones y dependencias entre procesos empresariales
se vuelven ms claros y entendibles. Secuencias de
procesos empresariales pueden ser optimizadas para ganar
eficiencia y reducir costos.
d) Procesos y datos de los sistemas operacionales, as como
los datos en el DW, son usados y examinados. Cuando los
- 51 -
datos son organizados y estructurados para tener
significado empresarial, la gente aprende mucho de los
sistemas de informacin.

2.6.3. La Comunicacin e Impactos Organizacionales.

Apenas el DW comienza a ser fuente primaria de informacin
empresarial consistente, los siguientes impactos pueden comenzar a
presentarse:

a) La gente tiene mayor confianza en las decisiones
empresariales que se toman. Ambos, quienes toman las
decisiones como los afectados conocen que est basada
en buena informacin.
b) Las organizaciones empresariales y la gente de la cual
ella se compone queda determinada por el acceso a la
informacin. De esta manera, la gente queda mejor
habilitada para entender su propio rol y
responsabilidades como tambin los efectos de sus
contribuciones; a la vez, desarrollan un mejor
entendimiento y apreciacin con las contribuciones de
otros.
c) La informacin compartida conduce a un lenguaje
comn, conocimiento comn, y mejoramiento de la
comunicacin en la empresa. Se mejora la confianza y
cooperacin entre distintos sectores de la empresa,
vindose reducida la sectorizacin de funciones.
d) Visibilidad, accesibilidad, y conocimiento de los datos
producen mayor confianza en los sistemas operacionales.

- 52 -
2.6.3.1. Impactos Tcnicos De DW.

Considerando las etapas de construccin, soporte del DW y
soporte de sistemas operacionales, se tienen los siguientes
impactos tcnicos:
Las Nuevas destrezas de desarrollo: cuando se construye el
DW, el impacto ms grande sobre la gente tcnica est dada por
la curva de aprendizaje, muchas destrezas nuevas se deben
aprender, incluyendo:

a. Conceptos y estructura DW.
b. El DW introduce muchas tecnologas nuevas (ETT, Carga,
Acceso de Datos, Catlogo de Metadatos, Implementacin
de DSS/EIS), y cambia la manera que nosotros usamos la
tecnologa existente. Nuevas responsabilidades de soporte,
nuevas demandas de recursos y nuevas expectativas, son los
efectos de estos cambios.
c. Destrezas de diseo y anlisis donde los requerimientos
empresariales no son posibles de definir de una forma
estable a travs del tiempo.
d. Tcnicas de desarrollo incremental y evolutivo.
e. Trabajo en equipo cooperativo con gente de negocios como
participantes activos en el desarrollo del proyecto.

Las Nuevas responsabilidades de operacin: Cambios sobre los
sistemas y datos operacionales deben ser examinados ms
cuidadosamente para determinar el impacto que estos cambios
tienen sobre ellos, y sobre el DW.

- 53 -
3. METODOLOGIAS
3.1. Rational Unified Process (RUP) (REYNOX, 2005)
3.1.1. Descripcin: RUP es un proceso que define claramente quien,
cmo, cundo y qu debe hacerse; y, como su enfoque est
basado en modelos utiliza un lenguaje bien definido para tal fin,
el UML.
ste aporta herramientas como los casos de uso, que definen los
requerimientos. Permite la ejecucin iterativa del proyecto y del
control de riesgos.
Los elementos del RUP son:
Actividades, Son los procesos que se llegan a determinar
en cada iteracin.
Trabajadores, Vienen hacer las personas o entes
involucrados en cada proceso.
Artefactos, Un artefacto puede ser un documento, un
modelo, o un elemento de modelo.

Una particularidad de esta metodologa es que, en cada ciclo de
iteracin, se hace exigente el uso de artefactos, siendo por este
motivo, una de las metodologas ms importantes para alcanzar
un grado de certificacin en el desarrollo del software.
3.1.2. Caractersticas: Las caractersticas principales del proceso
son:
Guiado por los Casos de Uso
Centrado en la Arquitectura
Guiado por los Riesgos
Iterativo
A travs de un proyecto guiado por RUP, los requerimientos
funcionales son expresados en la forma de Casos de Uso, que
guan la realizacin de una arquitectura ejecutable de la
aplicacin. Adems el proceso focaliza el esfuerzo del equipo
en construir los elementos crticos estructuralmente y del
- 54 -
comportamiento (llamados Elementos Arquitecturales) antes de
construir elementos menos importantes. La mitigacin de los
riesgos ms importantes gua la definicin / confirmacin del
alcance en las primeras etapas del ciclo de vida. Finalmente
RUP particiona el ciclo de vida en iteraciones que producen
versiones incremntales de los ejecutables de la aplicacin.
RUP implementa las siguientes mejores prcticas asociadas al
proceso de Ingeniera de Software:
Desarrollo Iterativo
Manejo de los Requerimientos
Uso de una Arquitectura basada en componentes
Modelizacin Visual
Verificacin Continua de la Calidad
Manejo de los Cambios

3.1.3. Fases: La metodologa RUP, llamada as por sus siglas en
ingls Rational Unified Process, divide en 4 fases el desarrollo
del software. Cada Fase tiene definido un conjunto de objetivos
y un punto de control especifico. A saber:

Inicio: El Objetivo en esta etapa es determinar la visin
del proyecto.
Elaboracin: En esta etapa el objetivo es determinar la
arquitectura ptima.
Construccin: En esta etapa el objetivo es llevar a
obtener la capacidad operacional inicial.
Transmisin: El objetivo es llegar a obtener el release
del proyecto.
Cada una de estas etapas es desarrollada mediante el ciclo de
iteraciones, la cual consiste en reproducir el ciclo de vida en
cascada a menor escala. Los Objetivos de una iteracin se
establecen en funcin de la evaluacin de las iteraciones
precedentes.
- 55 -
Vale mencionar que el ciclo de vida que se desarrolla por cada
iteracin, es llevada bajo dos disciplinas:
3.1.4. Disciplina de Desarrollo:
Ingeniera de Negocios: Entendiendo las necesidades del
negocio.
Requerimientos: Trasladando las necesidades del
negocio a un sistema automatizado.
Anlisis y Diseo: Trasladando los requerimientos
dentro de la arquitectura de software.
Implementacin: Creando software que se ajuste a la
arquitectura y que tenga el comportamiento deseado.
Pruebas: Asegurndose que el comportamiento requerido
es el correcto y que todo los solicitado esta presente.

3.1.5. Disciplina de Soporte:
Configuracin y administracin del cambio:
Guardando todas las versiones del proyecto.
Administrando el proyecto: Administrando horarios y
recursos.
Ambiente: Administrando el ambiente de desarrollo.
Distribucin: Hacer todo lo necesario para la salida del
proyecto.
Es recomendable que a cada una de estas iteraciones se les
clasifique y ordene segn su prioridad, y que cada una se
convierte luego en un entregable al cliente. Esto trae como
beneficio la retroalimentacin que se tendra en cada entregable
o en cada iteracin.

- 56 -

3.2. Extreme Programing (XP): (REYNOX, 2005)
3.2.1. Descripcin: Es una de las metodologas de desarrollo de
software ms exitosas en la actualidad utilizadas para proyectos
de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La
metodologa consiste en una programacin rpida o extrema,
cuya particularidad es tener como parte del equipo, al usuario
final, pues es uno de los requisitos para llegar al xito del
proyecto.
Enfatiza la satisfaccin del cliente y promueve el trabajo en
equipo. En XP, las actividades improductivas han sido
eliminadas para reducir costos y frustraciones.
Esta metodologa ha sido diseada para solucionar el eterno
problema del desarrollo de software por encargo: entregar el
resultado que el cliente necesita a tiempo.

Fuente: (REYNOX, 2005)
Figura N 13: Ciclo de Vida de la Metodologa RUP
- 57 -
3.2.2. Caractersticas: La metodologa se basa en:
Pruebas Unitarias: se basa en las pruebas realizadas a
los principales procesos, de tal manera que
adelantndonos en algo hacia el futuro, podamos hacer
pruebas de las fallas que pudieran ocurrir. Es como si
nos adelantramos a obtener los posibles errores.
Refabricacin: se basa en la reutilizacin de cdigo,
para lo cual se crean patrones o modelos estndares,
siendo ms flexible al cambio.
Programacin en pares: Una particularidad de esta
metodologa es que propone la programacin en pares, la
cual consiste en que dos desarrolladores participen en un
proyecto en una misma estacin de trabajo. Cada
miembro lleva a cabo la accin que el otro no est
haciendo en ese momento. Es como el chofer y el
copiloto: mientras uno conduce, el otro consulta el mapa.

El desarrollo bajo XP tiene caractersticas que lo
distinguen claramente de otras metodologas:
Los diseadores y programadores se comunican
efectivamente con el cliente y entre ellos mismos
Fuente: (REYNOX, 2005)
Figura N 14: Propuesta de la programacin Extrema
- 58 -
Los diseos del software se mantienen sencillos y libres
de complejidad o pretensiones excesivas.
Se obtiene retroalimentacin de usuarios y clientes
desde el primer da gracias a las bateras de pruebas
El software es liberado en entregas frecuentes tan
pronto como sea posible
Los cambios se implementan rpidamente tal y como
fueron sugeridos.
Las metas en caractersticas, tiempos y costos son
reajustadas permanentemente en funcin del avance
real obtenido.

Con estas caractersticas no es sorprendente que XP sea
la metodologa ms apropiada para un entorno
caracterizado por requerimientos cambiantes originados
por un mercado fluctuante y los propios avances de la
tecnologa y los negocios.

3.2.3. Fases:
Planificacin: (permanente dilogo entre deseable y
posible):
3.2.3.1. Negocio
mbito Qu debe resolver el software?
Prioridad Qu debe ser hecho en primer lugar?
Composicin de versiones Cunto es necesario
hacer para aportar valor?
Fechas de versiones Fechas para presencia del
software?
3.2.3.2. Tcnico.
Estimaciones Cunto lleva implementar una
caracterstica?
Consecuencias, informar sobre consecuencias de
las decisiones que adopta el negocio.
- 59 -
Procesos Cmo se organiza el trabajo en el
equipo?
Programacin detallada: En una versin Qu
se resolver primero?
3.2.3.3. Diseo:
Metfora.
Diseo sencillo.
Funcionan todas las pruebas.
No existe lgica.
Manifiesta cada intencin imprtate para los
programadores.
Tiene el menor nmero posible de clases,
mtodos o funciones.
3.2.3.4. Desarrollo
Recodificacin.
Programacin por parejas.
Propiedad colectiva.
Integracin contina.
40 Horas semanales.
Cliente in-situ.
Estndares de codificacin.

Fuente: (MONOGRAFIA, 2005)

Figura N 15: CICLO DE VIDA DE LA METODOLOGIA PROGRAMACION EXTREMA (XP)
- 60 -
3.3. Metodologa Integradora de Procesos Empresariales (MIPE):
(MONZON A, 2009)
Autor: CARLOS CHVEZ MONZN
3.3.1. Descripcin: MIPE busca integrar los tres niveles aplicando
medicin de desempeo enmarcado en la gestin del
conocimiento de la empresa para administrar mejor la creacin
del valor. MIPE Busca realzar los inductores no financieros de
creacin de valor como son: las relaciones estratgicas con los
proveedores y los clientes, los procesos internos crticos, los
recursos humanos y el crecimiento empresarial. MIPE es el
apalancamiento para aumentar la capacidad de respuesta e
innovacin dentro de las empresas. MIPE ayuda a la innovacin
que es la base de conocimiento de la empresa que radica en los
procesos empresariales. MIPE integra los procesos
empresariales en los niveles estratgicos, tcticos y
operacionales con un enfoque sistmico orientado a la creacin
del valor.

MIPE puede trabajar con un objetivo estratgico de un rea de
la empresa, con toda el rea o con toda la empresa. Se ajusta a
cualquier investigacin en Sistemas que se est realizando.
Esta metodologa tiene 5 fases:

1. Fase 1: Aplicacin de la Ingeniera del Conocimiento:
Modelado organizacional, modelado de tareas, modelado
de agentes, modelado de comunicacin, modelado de
conocimiento, modelado de artefactos de diseo.

2. Fase 2: Nivel Estratgico con Business Intelligence:
Aplicacin de estrategias en funcin a los requerimientos
de la organizacin, en: e-crm, e-scm, e-marketing, e-
commerce, e-learning, e-prm, e-brm, e-grm, TQM,
ABCM, ERP, BSC, JIT con KM, MRPII con KM,
Kanban con KM, uso de MicroStrategy.
- 61 -

3. Fase 3: Nivel Tctico con Business Intelligence y
Datawarehouse. Modelamiento multidimensional,
Herramientas OLAP.

4. Fase 4: Nivel Operacional: Integracin de Procesos
transaccionales aplicando RUP

5. Fase 5: Control de la Integracin de los niveles
estratgicos, tcticos y operacionales mediante Balanced
ScoreCard

3.4. Mtrica 3 (Metodologa de Planificacin, Desarrollo y
Mantenimiento de Sistemas de Informacin) (MANUEL, 2005)

3.4.1. Descripcin: Se descompone cada uno de los procesos en
actividades, y stas a su vez en tareas. Para cada tarea se
describe su contenido: Principales acciones, productos,
tcnicas, prcticas y participantes.

Fuente: (MONZON B, 2009)

Figura N 16: Metodologa Integradora de Procesos Empresariales

- 62 -
3.4.2. Procesos principales:
Planificacin De Sistemas De Informacin (PSI):
Obtencin de un marco de referencia para el desarrollo
de SI que responda a los objetivos estratgicos de la
organizacin.
Desarrollo de sistemas de informacin
Mantenimiento de sistemas de informacin (msi)
Obtencin de una nueva versin de un SI desarrollado
con MTRICA v. 3n 3 2, a partir de las peticiones de
mantenimiento que los usuarios realizan con motivo de
un problema detectado en el sistema, o por la necesidad
de una mejora del mismo.

3.4.3. Procesos principales del Desarrollo de SI:
Estudio De Viabilidad Del Sistema (Evs)
Anlisis de un conjunto concreto de necesidades para
proponer una solucin a corto plazo, que tenga en cuenta
restricciones econmicas, tcnicas, legales y operativas.
Anlisis Del Sistema De Informacin (Asi)
Obtencin de una especificacin detallada del SI que
satisfaga las necesidades de informacin de los usuarios
y sirva de base para el posterior diseo del sistema.
Diseo Del Sistema De Informacin (Dsi)
Definicin de la arquitectura del sistema y del entorno
tecnolgico que le va a dar soporte, junto con la
especificacin detallada de los componentes del sistema
de informacin.
Construccin Del Sistema De Informacin (Csi)
Se genera el cdigo de los componentes del SI, se
desarrollan todos los procedimientos de operacin y
seguridad y se elaboran todos los manuales de usuario
final y de explotacin con el objetivo de asegurar el
correcto funcionamiento del sistema para su posterior
implantacin.
- 63 -
Implantacin Y Aceptacin Del Sistema (Ias)

Todo proyecto Mtrica 3 consta de un conjunto de fases que se
desglosan en mltiples punto , como se muestra en la Figura N 15,
cuya cronologa hay que seguir con claridad para ir avanzando en el
desarrollo del proyecto.

3.5. Microsoft Solution Framework (MSF): (TECHNET, 2006)

3.5.1. Descripcin: Esta es una metodologa flexible e
interrelacionada con una serie de conceptos, modelos y prcticas
de uso, que controlan la planificacin, el desarrollo y la gestin
de proyectos tecnolgicos. MSF se centra en los modelos de
proceso y de equipo dejando en un segundo plano las elecciones
tecnolgicas.
MSF es un compendio de las mejores prcticas en cuanto a
administracin de proyectos se refiere. Ms que una
metodologa rgida de administracin de proyectos, MSF es una
serie de modelos que puede adaptarse a cualquier proyecto de
tecnologa de informacin.

Fuente: (AULADIRECTIVA, 2006).
Figura N 17: Fases de la Metodologa
Mtrica 3
- 64 -
Todo proyecto es separado en cinco principales fases:
Visin y Alcances.
Planificacin.
Desarrollo.
Estabilizacin.
Implantacin.
3.5.2. Visin y Alcances:
La fase de visin y alcances trata uno de los requisitos ms
fundamentales para el xito del proyecto, la unificacin del
equipo detrs de una visin comn. El equipo debe tener una
visin clara de lo que quisiera lograr para el cliente y ser capaz
de indicarlo en trminos que motivarn a todo el equipo y al
cliente. Se definen los lderes y responsables del proyecto,
adicionalmente se identifican las metas y objetivos a alcanzar;
estas ltimas se deben respetar durante la ejecucin del proyecto
en su totalidad, y se realiza la evaluacin inicial de riesgos del
proyecto.
3.5.3. Planificacin:
Es en esta fase es cuando la mayor parte de la planeacin para el
proyecto es terminada. El equipo prepara las especificaciones
funcionales, realiza el proceso de diseo de la solucin, y
prepara los planes de trabajo, estimaciones de costos y
cronogramas de los diferentes entregables del proyecto.
3.5.4. Desarrollo:
Durante esta fase el equipo realice la mayor parte de la
construccin de los componentes (tanto documentacin como
cdigo), sin embargo, se puede realizar algn trabajo de
desarrollo durante la etapa de estabilizacin en respuesta a los
- 65 -
resultados de las pruebas. La infraestructura tambin es
desarrollada durante esta fase.
3.5.5. Estabilizacin:
En esta fase se conducen pruebas sobre la solucin, las pruebas
de esta etapa enfatizan el uso y operacin bajo condiciones
realistas. El equipo se enfoca en priorizar y resolver errores y
preparar la solucin para el lanzamiento.
3.5.6. Implantacin:
Durante esta fase el equipo implanta la tecnologa base y los
componentes relacionados, estabiliza la instalacin, traspasa el
proyecto al personal soporte y operaciones, y obtiene la
aprobacin final del cliente.
3.5.7. Modelo de roles
El modelo de equipos de MSF (MSF team model) fue
desarrollado para compensar algunas de las desventajas
impuestas por las estructuras jerrquicas de los equipos en los
proyectos tradicionales.

Los equipos organizados bajo este modelo son pequeos y
multidisciplinarios, en los cuales los miembros comparten
responsabilidades y balancean las destrezas del equipo para
mantenerse enfocados en el proyecto que estn desarrollando.
Comparten una visin comn del proyecto y se enfocan en
implementar la solucin, con altos estndares de calidad y
deseos de aprender.
El modelo de equipos de MSF tiene seis roles que corresponden
a las metas principales de un proyecto y son responsables por las
mismas. Cada rol puede estar compuestos por una o ms
- 66 -
personas, la estructura circular del modelo, con valos del
mismo tamao para todos los roles, muestra que no es un
modelo jerrquico y que cada todos los roles son igualmente
importantes en su aporte al proyecto. Aunque los roles pueden
tener diferentes niveles de actividad durante las diversas etapas
del proyecto, ninguno puede ser omitido.
La comunicacin se pone en el centro del crculo para mostrar
que est integrada en la estructura y fluye en todas direcciones.
El modelo apoya la comunicacin efectiva y es esencial para el
funcionamiento del mismo.
3.5.8. Caractersticas: MSF tiene las siguientes caractersticas:
Adaptable: es parecido a un comps, usado en cualquier
parte como un mapa, del cual su uso es limitado a un
especfico lugar.
Escalable: puede organizar equipos tan pequeos entre
3 o 4 personas, as como tambin, proyectos que
requieren 50 personas a ms.
Flexible: es utilizada en el ambiente de desarrollo de
cualquier cliente.
Tecnologa Agnstica: porque puede ser usada para
desarrollar soluciones basadas sobre cualquier
tecnologa. (BS, 2005)
3.5.9. Etapas:
MSF se compone de varios modelos encargados de planificar las
diferentes partes implicadas en el desarrollo de un proyecto:
Modelo de Arquitectura del Proyecto, Modelo de Equipo,
Modelo de Proceso, Modelo de Gestin del Riesgo, Modelo de
Diseo de Proceso y finalmente el modelo de Aplicacin.

- 67 -

Modelo de Arquitectura del Proyecto: Diseado para
acortar la planificacin del ciclo de vida. Este modelo
define las pautas para construir proyectos empresariales
a travs del lanzamiento de versiones.
Modelo de Equipo: Este modelo ha sido diseado para
mejorar el rendimiento del equipo de desarrollo.
Proporciona una estructura flexible para organizar los
equipos de un proyecto. Puede ser escalado
dependiendo del tamao del proyecto y del equipo de
personas disponibles.
Modelo de Proceso: Diseado para mejorar el control
del proyecto, minimizando el riesgo, y aumentar la
calidad acortando el tiempo de entrega. Proporciona
una estructura de pautas a seguir en el ciclo de vida del
proyecto, describiendo las fases, las actividades, la
liberacin de versiones y explicando su relacin con el
Modelo de equipo.

Fuente: (MICROSFT, 2006)
Figura N 18: Ciclo de Vida de la Metodologa MSF
- 68 -
Modelo de Gestin del Riesgo: Diseado para ayudar al
equipo a identificar las prioridades, tomar las
decisiones estratgicas correctas y controlar las
emergencias que puedan surgir. Este modelo
proporciona un entorno estructurado para la toma de
decisiones y acciones valorando los riesgos que puedan
provocar.

Modelo de Diseo del Proceso: Diseado para
distinguir entre los objetivos empresariales y las
necesidades del usuario. Proporciona un modelo
centrado en el usuario para obtener un diseo eficiente
y flexible a travs de un enfoque iterativo. Las fases de
diseo conceptual, lgico y fsico proveen tres
perspectivas diferentes para los tres tipos de roles: los
usuarios, el equipo y los desarrolladores.

Modelo de Aplicacin: Diseado para mejorar el
desarrollo, el mantenimiento y el soporte, proporciona
un modelo de tres niveles para disear y desarrollar
aplicaciones software. Los servicios utilizados en este
modelo son escalables, y pueden ser usados en un solo
ordenador o incluso en varios servidores.
(MICROSFT, 2006)

- 69 -

3.6. Metodologa Propuesta por Ralph Kimball (ANGOITIA, 2006)

3.6.1. Planeamiento: La fase de Planteamiento se compone de:
Seleccin de la estrategia de implementacin
Seleccin de la metodologa de desarrollo
Seleccin del mbito de implementacin
Seleccin del enfoque arquitectnico
Desarrollo de un programa y del presupuesto de un
proyecto
Desarrollo de escenarios de uso empresarial
Recopilacin de metadatos

Uno de los pasos ms importantes consiste en decidir la
estrategia de implementacin. La decisin se basa en cmo se
llevan a cabo las tareas dentro de la organizacin. Se debe
Modelo Descriptivo
MSF 4.0
Metamodelo
Template de Proceso
MSF para
Desarrollo de
aplicaciones giles
Template de Proceso
MSF para el
proceso de mejora
CMMI
Template de Proceso
Otra
Metodologa
Template de Proceso
Su personalizacin
Al proceso gil
Template de Proceso
Su personalizacin
Al proceso CMMI
Informa
Informa
Copia y
Modifica
Copia y
Modifica
Visual Studio Team System
Modelo Prescriptivo
Fuente: (TECHNET, 2006)

Figura N 19: Modelo Prescriptito del MSF
Estructura de MSF 4.0
- 70 -
tener en cuenta la metodologa a utilizar, las ms conocidas
son: Mtodo en Cascada y Mtodo Espiral, donde se define el
mtodo arquitectnico, el desarrollo del programa y los
escenarios que la empresa va tener cuando se implemente el
Data Warehouse y para ello se define claramente los
metadatos.

3.6.2. Requerimiento En esta fase describe una especificacin
precisa de las funciones que se obtendrn del Data Warehouse,
es decir, hay que dejar constancia de las definiciones que se
indican a continuacin.
Definir los requerimientos del propietario
Definir los requerimientos del arquitecto
Definir los requerimientos del desarrollo
Definir los requerimientos de los usuarios finales.

3.6.3. Anlisis: En esta fase es conveniente convertir los
requerimientos agrupados en un conjunto de especificaciones
que puedan apoyar el diseo. En este anlisis debe
considerarse tres tipos de especificaciones:
Especificacin de requerimientos de enfoque
empresarial que delinean las fronteras de la
informacin que debe comprender el Data Warehouse.
El enfoque empresarial determinar tambin la
audiencia y sus requerimientos de informacin.
Especificacin de requerimientos de fuentes de datos
que delinean las fronteras de informacin disponible en
las fuentes de datos actuales.
Especificaciones de requerimientos de usuario final y
acceso, las cuales definen cmo se utilizar la
informacin del Data Warehouse. Junto con stas se
encuentra la especificacin de los tipos de herramientas
y tcnicas que se usarn.
- 71 -
3.6.4. Diseo. En la fase de diseo se encuentran las siguientes dos
actividades principales
Diseo detallado de la arquitectura de datos: Que define
como el desarrollo del modelo fsico de datos para la
base de datos del Data Warehouse.
Diseo detallado de la arquitectura de aplicaciones: Es
la correspondencia de los modelos fsicos de datos de la
fuente de datos con el modelo fsico del Data
Warehouse.

3.6.5. Construccin. En esta fase se realiza la implementacin fsica
de los diseos desarrollados durante la fase de diseo. Las
aplicaciones que se necesitan construir son las siguientes:
Programas que creen y modifiquen la base de datos
para el Data Warehouse.
Programas que traigan datos de fuentes relacionadas y
no relacionadas.
Programas que realicen transformacin de datos.
Programas que realicen actualizacin de base de datos
Programas que efecten bsquedas en base de datos
muy grande

3.6.6. Despliegue. Los requerimientos de despliegue para un Data
Warehouse son:
La informacin contenida en el Data Warehouse debe
estar en trminos y lenguajes que comprendan los
usuarios ya que ellos no son tcnicos.
Debe existir una necesidad de que la informacin que
proporcione el Data Warehouse debe de ser precisa
para los usuarios finales.

- 72 -
3.6.7. Expansin. En esta etapa se prev algunas de las siguientes
reas de mejora:
Consultas empresariales que no pueden formularse o
satisfacerse debido a la limitacin del Data Warehouse.
Consultas empresariales que comprenden fuente de
datos externas que no formaron parte de la
implementacin Inicial
Desempeo no satisfactorio de componentes del Data
Warehouse.

Fuente: (RIMENRI, 2009)
Figura 20: Proceso de la Metodologa
- 73 -
3.7. SELECCIN DE LA METODOLOGA

En la siguiente Matriz se reconoce las respuestas de los encuestados
realizados a 3 expertos (Ver Anexo 1, Anexo 2, Anexo 3)

C
1
=Estndar
C
2
=Bibliografa Abundante
C
3
=Soporte al Software
Metodologa seleccionada: (*)

Criterio

Metodologa
C
1
C
2
C
3

( )
3
i
Ci

RUP 3,7 4,0 3,7 3,8
XP 2,3 3,0 3,0 2,8
METRICA 2,7 2,3 2,7 2,6
MFS 2 2,7 2,3 2,3
RALPH KIMBALLL 4,7 4,0 4,3 4,3 *
B. IMMON 3.7 4.0 3.7 3.7
MIPE 1,7 2,3 2,7 2,2
NIVEL DE IMPACTO ESCALA
Muy Bajo 1
Baja 2
Medio 3
Alto 4
Muy alto 5
- 74 -

2.3.3. MARCO CONCEPTUAL
2.3.3.1. Sistemas Operacionales
Son aquellos que tienen como objetivo reflejar el estado y
funcionamiento de la empresa registrando las transacciones u
operaciones diarias; de aqu, que los mismos se conozcan como
sistemas de Procesamiento de Transacciones en Lnea (OLTP).

2.3.3.2. Sistemas para el Soporte de Decisiones (DSS)
Son aquellos que tienen como objetivo medir y controlar el
desarrollo de las variables importantes del negocio, buscando
identificar, proyectar y predecir tendencias a partir de los datos
acumulados.
2.3.3.3. Sistemas de Informacin
Un sistema de informacin es un conjunto de elementos que
interactan entre s con el fin de apoyar las actividades de una
empresa o negocio.
2.3.3.4. Tecnologa de la Informacin
Es necesario establecer que la tecnologa de la informacin (TI) se
entiende como "aquellas herramientas y mtodos empleados para
recabar, retener, manipular o distribuir informacin. La tecnologa
de la informacin se encuentra generalmente asociada con las
computadoras y las tecnologas afines aplicadas a la toma de
decisiones.
2.3.3.5. DataWareHouse - Almacenes de Datos
Un almacn de datos es una coleccin de datos consistente
semnticamente que sirve como implementacin fsica de un modelo
de datos de apoyo a la toma de decisiones y que almacena la
- 75 -
informacin que la organizacin necesita para la toma de decisiones
estratgicas.
2.3.3.6. OLTP (On-Line Transaction Processing)
OLTP es un acrnimo de Procesamiento de Transacciones en Lnea.
Son sistemas de produccin computarizados que renen y consumen
los datos operativos de cada da. Los sistemas OLTP sirven para
crear aplicaciones en todo gnero de actividad. Entre ellas pueden
citarse los sistemas de reservaciones, punto de venta, sistemas de
rastreo, control de inventarios, estaciones de trabajo de
intermediarios burstiles y sistemas de control para fbricas
manufactureras. En los sistemas OLTP lo comn es que el cliente
interacte con un servidor de transacciones no con un servidor de
base de datos.
2.3.3.7. rea de Estacionamiento de Datos
El rea de estacionamiento de datos es todo lo que est entre el
sistema origen y el servidor de presentacin. Es un rea de
almacenamiento y conjunto de procesos que limpian, transforman,
combinan, optimizan, archivan y preparan los datos de origen para
uso en el Data Warehouse. Aunque sera agradable que el rea de
estacionamiento de datos fuera un dispositivo centralizado en una
pieza de hardware, es comn que el rea de estacionamiento de datos
est dispersada sobre un nmero de mquinas.
2.3.3.8. DataMart
Un DataMart es una versin especial de almacn de datos
(DataWarehouse). Son subconjuntos de datos con el propsito de
ayudar a que un rea especfica dentro del negocio pueda tomar
mejores decisiones. Los datos existentes en este contexto pueden ser,
agrupados, explorados y propagados de mltiples formas para que
diversos grupos de usuarios realicen la explotacin de los mismos de
la forma ms conveniente segn sus necesidades.
- 76 -

2.3.3.9. Modelo Multidimensional
En el modelo multidimensional se utiliza un esquema
multidimensional en el que se representa una actividad que es objeto
de anlisis (hecho) y las dimensiones que caracterizan la actividad
(dimensiones). La informacin relevante sobre el hecho (actividad)
se representa por un conjunto de indicadores (medidas o atributos de
hecho) La informacin descriptiva de cada dimensin se representa
por un conjunto de atributos (atributos de dimensin).
2.3.3.10. Diseo Lgico
El diseo lgico de un almacn de datos se basa en la determinacin
de las dimensiones y medidas; las cuales, desde el punto de vista
lgico, pueden organizarse o estructurarse de alguna de las
siguientes formas:
Esquema en estrella (star): Una tabla de hechos en el
centro conectada con un conjunto de tablas de
dimensiones.
Esquema copo de nieve (snowflake): Un refinamiento
del anterior donde algunas tablas se normalizan en
tablas ms pequeas.
Constelacin de hechos: Mltiples tablas de hechos
comparten tablas de dimensin que se visualizan como
una coleccin de hechos.

2.3.3.11. Metadata
Uno de los componentes ms importantes de la arquitectura de un
DataWarehouse son los metadatos. Se definen comnmente como
"datos acerca de los datos" en el sentido de que se trata de datos que
describen cul es la estructura de los datos que se van a almacenar y
- 77 -
cmo se relacionan. El metadato documenta, entre otras cosas, qu
tablas existen en una base de datos, qu columnas posee cada una de
las tablas y qu tipo de datos se pueden almacenar.
2.3.3.12. ODS (Operational Data Stage)
El Almacn de Datos Operacional es un contenedor de datos activos;
es decir, operacionales que ayudan al soporte de decisiones y a la
operacin. Est entre un OLAP y un OLTP. Su funcin es integrar
los datos al igual que en el DataWarehouse pero con una ventana de
actualizacin muy pequea (del orden de minutos) y con mucho
menos detalle. Considrese tambin: OBS (Operacional Business
Stage)
2.4. Hiptesis
H0: Aplicacin de un DataWareHouse Agiliza la Toma de Decisiones en el
rea de Radiologa del Hospital Regional Eleazar Guzmn Barrn de
Nuevo.
H1: Aplicacin de un DataWareHouse no Agiliza la Toma de Decisiones
en el rea de Radiologa del Hospital Regional Eleazar Guzmn Barrn de
Nuevo.

2.5. Variables e Indicadores
2.5.1. Variables
2.5.1.1. Variable independiente
Aplicacin de un DataWareHouse
2.5.1.2. Variable Dependiente
Toma de Decisiones en el rea de Radiologa

- 78 -
2.5.2. Indicadores
N INDICADOR TIPO UNIDAD MEDIDA INSTRUMENTO FUENTE INFORMANTE OPERATIVA
1 Nivel de satisfaccin de
los usuarios del rea de
Radiologa.

Cualitativo Escala Valorada del 1
al 5
Encuesta
Tabulada
rea de
Radiologa
Usuarios

2 Nivel de satisfaccin de
los usuarios de las
diferentes reas
integradas con el rea de
Radiologa.

Cualitativo Escala Valorada del 1
al 5
Encuesta
Tabulada
rea de
Radiologa y
las diferentes
rea integradas
Usuarios

3 Tiempo que se requiere
para obtener los reportes
estadsticos de los
tecnlogos de las
atenciones diarias
realizadas.

Cuantitativo Segundos Cronometro rea de
Radiologa
Tecnlogos
4 Tiempo de bsqueda de
informacin que muestre
las atenciones y por tipo
de placas elaborando
reportes analticos
histricos con cuadros
comparativos.

Radiologa
Encargado de
Archivos

n
AI
PNSUAI
n
NSUAI
i=1
n
TOR
i=1
n
AR
PTOR =
n
TBI
i=1
n
AR
PTBI =
n
NSUAR
i=1
n
AR
PNSUAR =
- 79 -
5 Minimizar el tiempo de
Reportes mensuales por
atenciones de seguros y
convenios que tiene el
rea de radiologa
elaborando reportes
analticos histricos con
cuadros comparativos.

Radiologa
Secretaria

6 Tiempo para el acceso de
la informacin con las
diferentes reas integrado
el Sistema de Soporte de
Decisiones del rea de
Radiologa centralizado
en la Unidad de
Informtica y Sistemas.
Radiologa y
las diferentes
rea integradas
Usuarios
7 Tiempo de emisin de
reportes a las diferentes
reas que las requieran
integrando las diferentes
reas del hospital con el
rea de radiologa
mediante un DataMart.

Radiologa y
las diferentes
rea integradas
Usuarios
n
TBRM
i=1
n
AR
PTBRM =
n
TAIAI
i=1
n
AI
PTAIAI =
n
TERAI
i=1
n
AI
PTERAI =
- 80 -

8

Cantidad de extravos de
placas radiogrficas
elaborando Reportes
analticos histricos con
cuadros comparativos.

Cuantitativo

Promedio extravos

Cuadros
Comparativos

rea de
Radiologa

Encargado de
Archivos

Donde:
PNSUAR: Promedio de Nivel de Satisfaccin del usuario del rea de Radiologa
PNSUAI: Promedio de Nivel de Satisfaccin del usuario de reas integradas
PTOR: Promedio de Tiempo de Obtencin de Reportes.
PTBI: Promedio de Tiempo de Bsqueda de informacin.
PTBRM: Promedio de Tiempo de Bsqueda de Reportes Mensuales
PTAIAI: Promedio de Tiempo de Acceso a la Informacin de reas integradas
PTERAI: Promedio de Tiempo de Emisin de Reportes de reas integradas.
PCEPR: Promedio de Cantidad de Extravos de placas radiogrficas.

NSUAR: Nivel de Satisfaccin del usuario del rea de Radiologa
NSUAI: Nivel de Satisfaccin del usuario de reas integradas
TOR: Tiempo de Obtencin de Reportes.
TBI: Tiempo de Bsqueda de informacin.
TBRM: Tiempo de Bsqueda de Reportes Mensuales
TAIAI: Tiempo de Acceso a la Informacin de reas integradas
TERAI: Tiempo de Emisin de Reportes de reas integradas.
CEPR: Cantidad de Extravos de placas radiogrficas.

n
CEPR
i=1
n
AR
PCEPR =
- 81 -
2.6. Diseo de Ejecucin
2.6.1. Objeto de Estudio.
La Toma de decisiones del jefe del rea de Radiologa del Hospital
Regional Eleazar Guzmn Barrn de Nuevo.

2.6.2. Metodologa.
La metodologa a utilizar ser la propuesta por Ralph Kimball donde nos
seala 7 pasos para realizar una correcta elaboracin de un
DataWarehouse

1. Planeamiento: La fase de Planteamiento se compone de:
Seleccin de la estrategia de implementacin
Seleccin de la metodologa de desarrollo
Seleccin del mbito de implementacin
Seleccin del enfoque arquitectnico
Desarrollo de un programa y del presupuesto de un proyecto
Desarrollo de escenarios de uso empresarial
Recopilacin de metadatos

Uno de los pasos ms importantes consiste en decidir la estrategia de
implementacin. La decisin se basa en cmo se llevan a cabo las tareas
dentro de la organizacin. Se debe tener en cuenta la metodologa a
utilizar, las ms conocidas son: Mtodo en Cascada y Mtodo Espiral,
donde se define el mtodo arquitectnico, el desarrollo del programa y
los escenarios que la empresa va tener cuando se implemente el Data
Warehouse y para ello se define claramente los metadatos.

2. Requerimiento En esta fase describe una especificacin precisa de las
funciones que se obtendrn del Data Warehouse, es decir, hay que dejar
constancia de las definiciones que se indican a continuacin.
Definir los requerimientos del propietario
Definir los requerimientos del arquitecto
Definir los requerimientos del desarrollo
Definir los requerimientos de los usuarios finales.
- 82 -
3. Anlisis: En esta fase es conveniente convertir los requerimientos
agrupados en un conjunto de especificaciones que puedan apoyar el
diseo. En este anlisis debe considerarse tres tipos de especificaciones:
Especificacin de requerimientos de enfoque empresarial que
delinean las fronteras de la informacin que debe comprender el
Data Warehouse. El enfoque empresarial determinar tambin la
audiencia y sus requerimientos de informacin.
Especificacin de requerimientos de fuentes de datos que delinean
las fronteras de informacin disponible en las fuentes de datos
actuales.
Especificaciones de requerimientos de usuario final y acceso, las
cuales definen cmo se utilizar la informacin del Data
Warehouse. Junto con stas se encuentra la especificacin de los
tipos de herramientas y tcnicas que se usarn.

4. Diseo. En la fase de diseo se encuentran las siguientes dos actividades
principales
Diseo detallado de la arquitectura de datos: Que define como el
desarrollo del modelo fsico de datos para la base de datos del
Data Warehouse.
Diseo detallado de la arquitectura de aplicaciones: Es la
correspondencia de los modelos fsicos de datos de la fuente de
datos con el modelo fsico del Data Warehouse.

5. Construccin. En esta fase se realiza la implementacin fsica de los
diseos desarrollados durante la fase de diseo. Las aplicaciones que se
necesitan construir son las siguientes:
Programas que creen y modifiquen la base de datos para el Data
Warehouse.
Programas que traigan datos de fuentes relacionadas y no
relacionadas.
Programas que realicen transformacin de datos.
Programas que realicen actualizacin de base de datos
Programas que efecten bsquedas en base de datos muy grande
- 83 -

6. Despliegue. Los requerimientos de despliegue para un Data Warehouse
son:
La informacin contenida en el Data Warehouse debe estar en
trminos y lenguajes que comprendan los usuarios ya que ellos
no son tcnicos.
Debe existir una necesidad de que la informacin que proporcione
el Data Warehouse debe de ser precisa para los usuarios finales.

7. Expansin. En esta etapa se prev algunas de las siguientes reas de
mejora:
Consultas empresariales que no pueden formularse o satisfacerse
debido a la limitacin del Data Warehouse.
Consultas empresariales que comprenden fuente de datos externas
que no formaron parte de la implementacin Inicial
Desempeo no satisfactorio de componentes del Data Warehouse.

- 84 -
2.6.3. Tipo de Investigacin.
2.6.3.1. De acuerdo al fin que se persigue.
Descriptiva: porque se va describir el proceso de toma de
decisiones del jefe del rea de radiologa.

2.6.3.2. De acuerdo al diseo de investigacin.
Cuasi-experimental: porque se manipulara las variables
indirectamente y se obtendrn los datos de forma natural.
2.6.4. Diseo de Investigacin.
Se usar el tipo de investigacin cuasi-experimental porque el
investigador manipula las variables indirectamente y se obtendrn los
datos de forma natural del entorno en el que el problema se presenta.
Para el diseo de contrastacin se utilizar el mtodo de sucesin o en
lnea con un solo grupo llamado tambin Pretest -Postest
As tenemos:

Donde:
O1: Procesos de Toma de Decisiones en el rea de Radiologa
despus de la implementacin de la Metodologa
Integradora de Procesos Empresariales.
O2: Procesos de Toma de Decisiones en el rea de Radiologa
antes de la implementacin de la Metodologa Integradora
de Procesos Empresariales.
X: Implementacin de Business Intelligence utilizando
DataWareHouse
01
X
02
Y
- 85 -
Y: Metodologa Integradora de Procesos Empresariales
(MIPE)
2.6.4.1. Diseo Pre Test
Realizacin de entrevistas al personal del rea, para medir
su conocimiento en Tecnologas de Informacin, as
como para definir las dificultades en el desarrollo de los
procesos.
Analizar los diferentes documentos que nos puedan
brindar el personal del rea de Radiologa, acerca de los
informes finales resultante de los procesos propios de la
Gestin.
Medicin del tiempo de ejecucin de procesos y de
respuesta hacia el usuario.

2.6.4.2. Diseo Post Test.
Realizar cuestionarios a los usuarios del sistema, para
evaluar su interaccin con este.
Medicin del tiempo de ejecucin de procesos y de
respuesta hacia el usuario.
Determinacin del porcentaje de Aceptacin del sistema
en cada rea.

2.6.5. Poblacin y muestra de estudio
2.6.5.1. Poblacin
2.6.5.1.1. Para Indicadores Cualitativos

- 86 -

a) Nivel de satisfaccin de los usuarios del rea de Radiologa

La poblacin de los usuarios internos (trabajadores) en el rea de
Radiologa son diez (10), los cuales son:

USUARIOS INTERNOS
1. Jefe de rea
2. Sub-Jefe del rea
3. Secretaria
4. Encargado de Archivos
5. Tecnlogo 1
6. Tecnlogo 2
7. Tecnlogo 3
8. Tecnlogo 4
9. Tecnlogo 5
10. Recepcionista

N
AR
= 10 usuarios internos.

b) Nivel de satisfaccin de los usuarios de las diferentes reas
integradas con el rea de Radiologa

La poblacin de los usuarios externos (reas Integradas) relacionados
con el rea de Radiologa para el acceso de la informacin, siendo un
total de 5 personas, es decir:

N
AI
= 5 usuarios externos

USUARIOS EXTERNOS
1. Jefe de rea de Estadstica
2. Secretaria del rea de Estadstica
3. Jefe del rea de Seguros Privados y Pblicos
4. Secretaria del rea de Seguros Privados y Pblicos
5. Jefe de la Unidad de Informtica y Sistemas

- 87 -

2.6.5.1.2. Para Indicadores Cuantitativos

a) Tiempo para obtener reportes estadsticos de atenciones
diarias.

El tiempo para la obtencin de los reportes de atenciones diarias
tarda aproximadamente entre 100 minutos y 130 minutos por
reporte.
Tomaremos una poblacin de 30 das de levantamiento de datos,
se tiene una poblacin de reportes de:
N
TOR
= 30 Reportes.
b) Tiempo de bsqueda de informacin que muestre las
atenciones y por tipo de placas.

El tiempo para la obtencin de bsqueda de informacin de las
atenciones por tipo de placa tarda aproximadamente entre 70
minutos y 120 minutos
Tomaremos una poblacin de 30 bsquedas de levantamiento de
datos, se as muestra poblacin de:

N
TBI
= 30 bsquedas.

c) Tiempo de bsqueda de reportes mensuales por atenciones de
seguros y convenios.

Se estima el nmero de reportes mensuales por atenciones de
seguros y convenios, tarda aproximadamente entre 50 minutos y
60 minutos.
Tomando una poblacin del ltimo trimestre de levantamiento de
datos, se tiene una poblacin de reportes de:

N
TBRM =
90 reportes
- 88 -
d) Tiempo para el acceso de la informacin con las diferentes
reas integrado el Sistema de Soporte de Decisiones del rea
de Radiologa centralizado en la Unidad de Informtica y
Sistemas.

Se estima el nmero de acceso a la informacin por las diferentes
reas se tarda entre 20 minutos a 30 minutos.

Tomando una poblacin de 30 accesos de levantamiento de datos,
se tiene una poblacin de:

e) Tiempo de emisin de reportes a las diferentes reas que las
requieran integrando las diferentes reas del hospital con el
rea de radiologa mediante un DataMart.

El tiempo para la obtencin de los reportes diarios presentadas a
las reas integradas tarda aproximadamente entre 100 minutos y
130 minutos por reporte.
Tomaremos una poblacin de 30 das de levantamiento de datos,
se tiene una poblacin de reportes de:
N
TERAI
= 30 Reportes.
f) Cantidad de extravos de placas radiogrficas elaborando

Se estima el nmero de extravos de las placas radiogrficas son
de 0 a 3 placas por das.

Tomando una poblacin de 30 das de levantamiento de datos, se
tiene una poblacin de

N
TAIAI=
30 accesos
N
CEPR=
30 Das
- 89 -
2.6.5.2. Muestra
2.6.5.2.1. Para indicadores Cualitativos.
b) Nivel de satisfaccin de los usuarios del rea de Radiologa.

En cuanto al Personal rea de Radiologa, la muestra estar
conformada por toda la poblacin, debido a su pequea
cantidad.
N
AR
=10

c) Nivel de satisfaccin de los usuarios de las diferentes reas
integradas con el rea de Radiologa.

En cuanto al Personal de las reas involucradas con el rea de
Radiologa, la muestra estar conformada por toda la
poblacin, debido a su pequea cantidad.

N
AI
=6
2.6.5.2.2. Para indicadores Cuantitativos.
d) Tiempo para obtener reportes estadsticos de atenciones
diarias.

En 30 das de levantamiento de datos, con un reporte diario
obtenemos un total de 30 reportes, para dicho estudia va a
tomar una nuestra aleatoria, de tal manera que el error de
muestre no sea mayor de 0.5 minutos para un nivel de
confianza del 95% y que la desviacin estndar obtenida por
dicha poblacin seria calculado de la siguiente forma:

- 90 -
=
Xi
fi Xi
X
*
[ ]

=
fi
fi X Xi *
2
( )
( )( ) ( )( )
2 2
2
2
61 . 7 96 . 1 5 . 0 1 30
61 . 7 ) 96 . 1 ( 30
+
=
TOR
n
Intervalo fi Xi Xi*fi |Xi -X|
2
*fi
100 - 105 4 102.5 410 1225
105 - 110 0 107.5 0 0
110 - 115 0 112.5 0 0
115 - 120 7 117.5 822.5 43.75
120 - 125 12 122.5 1470 75
125 - 130 7 127.5 892.5 393.75
Total 30 3595 1737.5

Con una media de

Desviacin Estndar:
= 7.61 minutos
Se tienen los siguientes datos:

N
TOR
= 30 reporte en 30 Das
E= 0.5 minutos
Z= 1.96
= 7.61 minutos

Reemplazando en la ecuacin (eq.1)

n
TOR
= 29 reportes con un tiempo promedio de 120
minutos de para generar un reporte diario

Ajustando el valor anterior, empleando la siguiente
ecuacin:

120
30
3595
= = X Minutos
( )
2 2
2 2
1
*
=
TOR
TOR
TOR
N
N
n
(eq. 1)
- 91 -
72 , 14
30
29
1
29
'
=
+
= TOR n
portes n TOR Re 15
'
=

Donde:
n: Valor de muestra ajustada
n : Valor de la muestra estimada
N: Poblacin muestral
Reemplazando valores en ecuacin (eq.2), se tiene:

15 reportes para nuestra muestra, con un promedio de 120
minutos para generar un reporte

e) Tiempo de bsqueda de informacin que muestre las
atenciones y por tipo de placas.

En 30 bsquedas de levantamiento de datos, para dicho estudio
va a tomar una nuestra aleatoria, de tal manera que el error de

Intervalo fi Xi Xi*fi |Xi -X|
2
*fi
70 - 78 5 74 370 2816.36
78-86 5 82 410 1237.69
86-94 5 90 450 299.02
94+102 2 98 196 0.14
102-110 2 106 212 136.68
110+118 6 114 684 1587.63
118-126 5 122 610 2944.36
TOTAL 30 2932 9021.87
N
n
n
n
+
=
1
'
..(eq. 2)
- 92 -
=
Xi
fi Xi
X
*
[ ]

=
fi
fi X Xi *
2
( )
( )( ) ( )( )
2 2
2
2
34 . 17 96 . 1 5 . 0 1 30
34 . 17 ) 96 . 1 ( 30
+
=
TBI
n

Con una media de

Desviacin Estndar:

= 17.34 minutos

N
TBI
= 30 Bsquedas diarias

E= 0.5 minutos
Z= 1.96
= 17.34 minutos


n
TBI
= 29 bsquedas con un tiempo promedio de 98
minutos para una bsqueda

ecuacin:

98
30
2932
= = X Minutos
N
n
n
n
+
=
1
'
..(eq. 2)
( )
2 2
2 2
1
*
=
TBI
TBI
TBI
N
N
n
(eq. 1)
- 93 -
72 , 14
30
29
1
29
'
=
+
= TBI n
portes n TBI Re 15
'
=
Donde:
n : Valor de muestra ajustada
N : Poblacin maestral


15 bsquedas de nuestra, con un promedio de 98 minutos
para una bsqueda.

f) Tiempo de bsqueda de reportes mensuales por
atenciones de seguros y convenios.

En 3 meses de levantamiento de datos, con un reporte
mensuales obtenemos un total de 3 reportes, para dicho
estudia va a tomar una nuestra aleatoria, de tal manera que el
error de muestre no sea mayor de 0.5 minutos para un nivel
de confianza del 95% y que la desviacin estndar obtenida
por dicha poblacin seria calculado de la siguiente forma:

Intervalo fi Xi Xi*fi |Xi -X|2 *fi
50-52 9 21 189 112.36
52-54 5 23 115 11.76
54-56 5 25 125 1.09
56-58 6 27 162 36.51
58-60 5 29 145 99.76
TOTAL 30 736 261.47

- 94 -
=
Xi
fi Xi
X
*
[ ]

=
fi
fi X Xi *
2
( )
( )( ) ( )( )
2 2
2
2
95 . 2 96 . 1 5 . 0 1 30
95 . 2 ) 96 . 1 ( 30
+
=
TBRM
n
Con una media de

Desviacin Estndar:
= 2.95 minutos

N
TBRM
= 3 reporte en tres meses
E= 0.5 minutos
Z= 1.96
= 2.95 minutos


n
TBRM
= 3 mes de muestras, y tarda un tiempo promedio
de 25 minutos de para generar un reporte por mes

ecuacin:

Donde:

N : Poblacin muestral

25
30
736
= = X Minutos
N
n
n
n
+
=
1
'
..(eq. 2)
( )
2 2
2 2
1
*
=
TBRM
TBRM
TBRM
N
N
n
(eq. 1)
- 95 -
5 . 1
3
3
1
3
'
=
+
=
TBRM
n
=
Xi
fi Xi
X
*

2 meses para nuestra muestra, con un promedio de 25
minutos para generar un reporte mensual

g) Tiempo para el acceso de la informacin con las
diferentes reas integrado el Sistema de Soporte de
Decisiones del rea de Radiologa centralizado en la
Unidad de Informtica y Sistemas.

En 30accesos de levantamiento de datos, para dicho estudio

20-22 5 21 105 108.89
22-24 5 23 115 35.56
24-26 4 25 100 1.78
26-28 7 27 189 12.44
28-30 9 29 261 100.00
TOTAL 30 770 258.67

Con una media de

2
'
= TBRM n Meses de Estudio
26
30
700
= = X Minutos
- 96 -
[ ]

=
fi
fi X Xi *
2
( )
( )( ) ( )( )
2 2
2
2
94 . 2 96 . 1 5 . 0 1 30
94 . 2 ) 96 . 1 ( 30
+
=
TAIAI
n
Desviacin Estndar:

= 2.94 minutos


N
TAIAI
= 30 accesos
E= 0.5 minutos
Z= 1.96
= 2.94 minutos


N
TAIAI
= 24 accesos con un tiempo promedio de 26 minutos
para un acceso

Ajustando el valor anterior, empleando la siguiente ecuacin:

Donde:


( )
2 2
2 2
1
*
=
TAIAI
TAIAI
TAIAI
N
N
n
(eq. 1)
N
n
n
n
+
=
1
'
..(eq. 2)
- 97 -
33 . 13
30
24
1
24
'
=
+
= TAIAI n
=
Xi
fi Xi
X
*
[ ]

=
fi
fi X Xi *
2

13 accesos de nuestra, con un promedio de 26 minutos
para un acceso

h) Tiempo de emisin de reportes a las diferentes reas que
las requieran integrando las diferentes reas del hospital
con el rea de radiologa mediante un DataMart.

En 30 reportes de levantamiento de datos, para dicho estudio

100-105 4 102.5 410 698.47
105-110 3 107.5 322.5 202.42
110-115 4 112.5 450 41.33
115-120 7 117.5 822.5 22.32
120-125 8 122.5 980 368.37
125-130 2 127.5 255 277.81
TOTAL 28 3240 1610.71

Con una media de

Desviacin Estndar:

= 3.73 minutos

13
'
= TAIAI n Accesos
116
30
3240
= = X Minutos
- 98 -
( )
( )( ) ( )( )
2 2
2
2
73 . 3 96 . 1 5 . 0 1 30
73 . 3 ) 96 . 1 ( 30
+
=
TERAI
n
93 . 13
30
26
1
26
'
=
+
= TERAI n

N
TERAI
= 30 reportes
E= 0.5 minutos
Z= 1.96
= 3.73 minutos


N
TERAI
= 26 reportes con un tiempo promedio de 116 minutos
para un reporte
ecuacin:

Donde:



( )
2 2
2 2
1
*
=
TERAI
TERAI
TERAI
N
N
n
(eq. 1)
N
n
n
n
+
=
1
'
..(eq. 2)
14
'
= TERAI n Reportes
- 99 -
=
Xi
fi Xi
X
*
[ ]

=
fi
fi X Xi *
2
14 reportes de nuestra, con un promedio de 116 minutos

para un reporte

i) Cantidad de extravos de placas radiogrficas elaborando

En 30 das de levantamiento de datos, para dicho estudio va a
tomar una nuestra aleatoria, de tal manera que el error de

0-1 24 0.5 12 1.71
01-Feb 4 1.5 6 2.15
02-Mar 2 2.5 5 6.01
TOTAL 30 23 9.87

Con una media de

Desviacin Estndar:

= 0.57 placas

N
TERAI
= 30 dias
E= 0.5 placas
Z= 1.96
= 0.57 placas

1
30
87 . 9
= = X Placa Perdida
- 100 -
( )
( )( ) ( )( )
2 2
2
2
57 . 0 96 . 1 5 . 0 1 30
57 . 0 ) 96 . 1 ( 30
+
=
CEPR
n
54 . 3
30
4
1
4
'
=
+
= CEPR n


N
CEPR
= 4 das, hay un promedio de 1 placa que se pierde
diario.

Ajustando el valor anterior, empleando la siguiente ecuacin:

Donde:


4 das de nuestra, con un promedio de 1 placa por da se
pierde

( )
2 2
2 2
1
*
=
CEPR
CEPR
CEPR
N
N
n
(eq. 1)
N
n
n
n
+
=
1
'
..(eq. 2)
4
'
=
CEPR
n
Placas
- 101 -

2.6.6. Tcnicas, instrumentos, fuentes e informantes
Entrevistas:
Se concertarn reuniones con el personal del rea de Radiologa del
Hospital Regional Eleazar Guzmn Barrn de Nuevo Chimbote, con
la finalidad de saber los requerimientos funcionales y no funcionales
que se implementarn en el nuevo Sistema.
Cuestionarios:
Estarn dirigidas a los usuarios del sistema, se disearan preguntas de
acuerdo al manejo de los requerimientos y de las nuevas tecnologas
de la Informacin que estos manejen.
Observacin:
Se realizar constantemente hacia el comportamiento de los actores y
procesos que se realizan en la Gestin en estudio.
2.6.7. Procedimientos de recoleccin de datos.
En cuanto a los procedimientos de la recoleccin de datos tenemos:
Para cuantificar los tiempos que determinar la generacin de reportes
estadsticos para las diferentes reas, los reportes diarios de
atenciones, los reportes mensuales para los seguros utilizamos como
instrumento para recoleccin de los datos un cronometro que nos dar
los tiempos reales que toma el personal correspondiente elaborar los
reportes respectivos correspondiente a sus cargos, en el cual
procederemos mediante el muestre por conveniencia no probabilstica
ya que mantiene un flujo estndar al momento de realizar los reportes
correspondientes.
En cuanto los niveles de satisfaccin tanto del personal perteneciente
al rea de Radiologa como del personal de las diferentes reas del
hospital que requieren la de informacin para cumplir con sus
funciones utilizamos la tcnica de las encuestas con la ayuda de la
estadstica cuantificar el nivel de satisfaccin del personal.

- 102 -
2.6.8. Tcnicas de procesamiento y anlisis de datos.
En cuanto a las tcnicas que utilizaremos para el procesamiento y anlisis
de los datos tenemos:
Utilizaremos la tcnica de las encuestas para medir y cuantificar el nivel de
satisfaccin de los empleados tanto del rea de radiologa y de las
diferentes reas del hospital, de manera que tabularemos el resultado de las
encuestas realizadas a cada personal involucrado, una vez tabulado
realizaremos a procesarlas mediante cuadros estadsticos que nos
mostraran el comportamiento de las variables con una frecuencia de
tiempo a travs de histogramas.
Cuando el tamao de la muestra es menor de 30 se aplicara la prueba
estadstica de T de Estudient con diferencias de medias.
En cuanto al tamao de muestra es mayor a 30 se aplicara la prueba
estadstica de Chi cuadrado.

- 103 -

CAPITULO III
ADMINISTRACIN DEL
TRABAJO DE
INVESTIGACIN
- 104 -
3.1. Recursos
3.1.1. Personal
Tesistas:
o Balarezo Coronado, Csar Eduardo
o Pastor Sanchez, Jhonny Richard
Asesor
o Mg. Ing. Chvez Monzn, Carlos

3.1.2. Materiales y Equipos
3.1.2.1. Materiales
Millar de Hojas Bond A-4
CDs - R 700 MB
Memoria USB
3.1.2.2. Equipos
Una PC Pentium Corel 2 Duo de 2.66 Ghz, memoria RAM de 2
Gb , monitor LG de 17, 350Gb de disco duro.
3.1.2.3. Software
Se evaluar la utilizacin del siguiente software;
Sistema Operativo:
Windows XP Professional
Microsoft Office 2007
3.1.2.4. locales
rea de Radiologa del Hospital Regional Eleazar Guzmn
Barrn
Domicilio

- 105 -
3.2. Presupuesto
3.2.1. Analtico
Item Descripcin Disponibilidad Unidad Cantidad Precio. U
S/.
Sub Total
S/.
A Personal
1 Tesistas SI 2 0.00 0.00
2 Asesor NO
1
0.00 0.000
B Material
3 Hojas Bond NO Hojas 1000 0.025 25.00
4 CD-R700
MB
NO CD 4 1.00 4.00
5 Memoria
USB
SI CD 1 0.00
6 Material
Escritorio
NO tiles 20.00
C Equipos
7 Computador
a
SI 2 0.00
8 Impresora SI 1 0.00
D Software
9 Windows
XP
SI 0.00
10 Office 2003 SI 0.00
11 Utilitarios SI 0.00
12 Internet
Explorer
SI 0.00
E Servicios
13 Internet SI 0.00
14 Fotocopiado NO hojas 600 0.05 30.00
- 106 -
Item Descripcin Disponibilidad Unidad Cantidad Precio. U
S/.
Sub Total
S/.
15 Biblioteca SI Lugar 0.00
16 Anillado NO Anillado 2 4.00 8.00
17 Impresiones SI 0.10 0.00
18 Grabadas de
CDs
SI 0.50 0.00
19 Llamadas
Telefnicas
NO 0.20 100.00
20 Servicios de
Luz
NO 50.00
F Locales
21 Hospital
Regional
SI 0.00
22 Domicilio SI 0.00

3.2.2. Consolidado

Item Concepto Importe S/.
1 Personal 0.00
2 Material, Equipos y Software 49.00
3 Servicios y Locales 188.00
Presupuesto Total S./ 237.00

3.3. FINANCIACIN

Recursos Propios: 100%

- 107 -

CAPITULO IV
CRONOGRAMA
- 108 -

Figura N 19: Diagrama de Actividades Parte 01
- 109 -

Figura N 20: Diagrama de Actividades Parte 02
- 110 -
REFERENCIA BIBLIOGRAFA

ALARCOS. METODOLOGA DE PLANIFICACIN, DESARROLLO Y
MANTENIMIENTO DE SISTEMAS DE INFORMACIN [en lnea]
[Fecha de consulta: 01 de mayo 2009]
Disponible en: http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema08.pdf

ANGOITIA. DATA WAREHOUSE PARA LA GESTIN DE LISTA DE
ESPERA SANITARIA [en lnea]
[ Fecha de consulta: 20 de mayo 2009].
Disponible en:
http://oa.upm.es/1095/01/PFC_ITZIAR_ANGOITIA_ESPINOSA.pdf

AULADIRECTIVA. METODOLOGA MTRICA V3 [ Fecha de consulta 01
de mayo 2009]. [en lnea]
Disponible en: http://www.auladirectiva.com/curso/metrica-
v3/presentacion.html

BERENGER, Jos y RAMOS, Juan. Negocios Digitales. Compertir usando
Tecnologas de Informacin. Espaa: EUNSA, Ediciones Universidad de
Navarra, 2004. 228 p. ISBN: 84-313-2121-0

BS, METODOLOGIA DE TRABAJO MICROSOFT SOLUTIONS
FRAMEWORK (MSF) [en lnea],
[Fecha de consulta: 15 de mayo2009].
Disponible en :
http://www.bs.com.ar/bsweb/MENU/Consultoria/metodologia.html

CESARES, Claudio. DataWarehousing , [en lnea]. [Fecha consultada: 7 de
junio 2009]
Disponible en: http://personal.lobocom.es/claudio/gen006.htm

DHONY, Solucin de Inteligencia de Negocios para Empresas de Servicios de
asistencia aplicacin prctica a la gerencia de asistencia de Touring y
Automvil Club Per
Disponible en :
http://www.cybertesis.edu.pe/sdx/sisbib/notice.xsp?id=sisbib.2006.quispe_ar|TH
.4&qid=pcd-
q&base=documents&dn=1&id_doc=sisbib.2006.quispe_ar&num=&query=data
warehouse&isid=sisbib.2006.quispe_ar|TH.4&idcorreo=@@@@@

IVAN, Una Metodologa para Sectorizar Pacientes en el consumo de
medicamentos aplicando DataMart y DataMing en un Hospital Nacional
Disponible en:
http://www.cybertesis.edu.pe/sdx/sisbib/notice.xsp?id=sisbib.2006.tapia_ri|TH.b
ack.2&qid=pcd-
- 111 -
q&base=documents&dn=1&id_doc=sisbib.2006.tapia_ri&num=8&query=dataw
arehouse&isid=sisbib.2006.tapia_ri|TH.back.2&idcorreo=@@@@@
ITZIAR, Datawarehouse para la gestin de lista de espera sanitaria
Disponible en:
http://oa.upm.es/1095/01/PFC_ITZIAR_ANGOITIA_ESPINOSA.pdf

JOSE, Midiendo y gestionando todas las actividades que sean esenciales para
impulsar la modernizacin hospitalaria
Disponible en:
http://www.gestiondelrendimiento.com/Articulos/002/gdr%2002%20p%C3%A1
g.%2020-23.pdf

JUAN, Datawarehousing y su aplicacin como apoyo a la toma de decisiones
en La Espol
Disponible en: http://www.dspace.espol.edu.ec/bitstream/123456789/18/1/1.pdf

LANGIT, Lynn. Foundations of SQL Server 2005 Business Intelligence.
United States of America: Apress, 2007. 396 p. ISBN 978-1-59059-834-4

MANUEL. UNA EXPLICACIN DE LA PROGRAMACIN EXTREMA.,
[Fecha de consulta: 1 de mayo 2009] [en lnea]
Disponible em: http://www.avemundi.com/archivos/XP.ppt

MAURICIO, Plan Para Enfocar Las Campaas Bancarias Utilizando
DataMining
Disponible en: http://www.cybertesis.cl/tesis/uchile/2006/deluca_m/html/index-
frames.html
http://hdl.handle.net/2250/942

MCGRAWHILL, "Business Intelligence with Microsoft Office
PerformancePonit Server 2007", The McGraw-Hill Companies, New York,
2008, 6 p, E-ISBN - 0-07-158943-0

MENDEZ,. Fundamentos de DataWarehouse. Centro de Actualizacin
Permanente en Ingeniera del Software. Argentina . ISSN C1106ACD .

MICROSFT. MICROSOFT SOLUTION FRAMEWORK V.4 AGILE (MSF).
[ Fecha de consulta: 20 de mayo 2009]. [en lnea]
Disponible en: http://download.microsoft.com/download/4/4/E/44E1B331-
E509-4D10-A9E3-60640A3A403/20051206-ARC-BA.ppt

MONOGRAFIAS. A PROPSITO DE PROGRAMACIN EXTREMA XP
(EXTREME PROGRAMING). [Fecha de consulta: 01 de mayo 2009]. [en lnea]
Disponible en: http://www.monografias.com/trabajos51/programacion-
extrema/Image3551.gif

MONZON A. ARTICULO METODOLOGA INTEGRADORA DE PROCESOS
EMPRESARIALES MIPE. 2007. [Fecha de consulta: 01 de mayo 2009] [en
lnea]
- 112 -
Disponible en: http://www.scribd.com/doc/2338667/Articulo-Metodologia-
Integradora-de-Procesos-Empresariales-MIPE-2007

MONZON B. METODOLOGA INTEGRADORA DE PROCESOS
EMPRESARIALES, [Fecha de consulta: 01 de mayo 2009] [en lnea]
Disponible en: http://mipe.zoomblog.com

PARRACIA, Natalia L. Datawarehousing [en lnea]. 19 Agosto 2003. [Fecha
consultada: 5 de mayo 2009]
Dsiponible en: http://www.sabetodo.com/contenidos/EpyEFFFVylEfpewjjY.php

PREZ, Erith E. El Modelo de Hechos Dimensionales (DFM) [en linea]. [Fecha
de consultada: 4 de mayo 2009]
Disponible en: http://www.monografias.com/trabajos57/data-warehouse-
sql/data-warehouse-sql2.shtml

REYNOX, METODOLOGA DE DESARROLLO DE SOFTWARE. [Fecha de
consultada: 01 de mayo 2009] [en lnea]
Disponible en: http://www.reynox.com/sap/metodologia.php

RIMENRI. KIMBALL, COGNOS, RIMENRI: ROADMAP BI/DW
[ Fecha de consulta: 20 de mayo 2009]. [en lnea]
Disponible en: http://rimenri.blogspot.com/2008/06/kimball-cognos-rimenri-
roadmap-bidw.html

ROTAECHE, Estibaliz. Business Intelligence [en linea]. 2007. [ Fecha de
consultada: 1 de mayo 2009].
Disponible en:
http://www.ibermatica.com/publicaciones/BusinessIntelligence.pdf

STANDILAW, Kozielski, "New Trends in DataWarehouse and Data Analysis",
New York in USA, 2009, 8 p. E-ISBN-13: 978-0-387-87431-9

TECHNET. MSF PROCESS MODEL OVERVIEW.
[Fecha de consulta: 20 de mayo 2009]. [en lnea]
Disponible en:
http://technet.microsoft.com/enus/library/cc785993%28WS.10%29.aspx

WOLFF, Carmen. La Tecnologa Datawarehousing [en linea][Fecha de
consulta: 5 de junio 2009]
Disponible en: http://www.inf.udec.cl/revista/edicion3/cwolff.htm

ZVENGER, Patricia A. Introduccin al soporte de Decisiones Incorporacin de
Soluciones OLAP en entornos empresariales [en lnea]. Diciembre 2005.
[Fecha consultada: 5 de mayo 2009]
Disponible en:
http://www.devoo.net/Introduccion_al_Soporte_de_Decisione.pdf

- 113 -

ANEXOS
- 114 -
ANEXO 01

ENCUESTA PARA DETERMINAR CUAL ES LA MEJOR ALTERNATIVA EN
CUANTO A METODOLOGIA PARA IMPLEMTAR UN DATAWAHOUSE

APELLIDOS Y NOMBRES: ZAVALETA ROLDAN, Edward
PROFESION: INGENIERO DE SISTEMAS
GRADO: INGENIERO
CARGO: JEFE DE DESARROLLO DEL HOSPITAL MARIA AUXILIADORA LIMA -
PERU

Ingresar en una escala de 1 al 5 el grado de importancia de cada criterio para determinar si es
una buena alternativa en cuanto a metodologa para la implementacin de un Datawarehouse.

C
1
=Estndar
C
2
C
3

Criterio

Metodologa
C
1
C
2
C
3
RUP 3 5 4
XP 2 4 3
METRICA 2 3 3
MFS 2 2 2
RALPH KIMBALLL 5 4 5
B. IMMON 4 4 4
MIPE 2 3 3
- 115 -
ANEXO 02

APELLIDOS Y NOMBRES: PEREZ LOPEZ, Mary
PROFESION: INGENIERO DE SISTEMAS
GRADO: INGENIERO
CARGO: JEFE DE LA UNIDAD DE INFORMATICA Y SISTEMAS DEL HOSITAL
REGIONAL ELEAZAR GUZMAN BARRON

una buena alternativa en cuanto a metodologa para la implementacin de un Datawarehouse

C
1
=Estndar
C
2
C
3

Criterio

Metodologa
C
1
C
2
C
3
RUP 4 4 4
XP 2 2 2
METRICA 3 2 3
MFS 2 3 2
B. IMMON 3 4 3
MIPE 1 2 3
- 116 -
ANEXO 03

APELLIDOS Y NOMBRES: CARRANZA LUJAN, Jorge
PROFESION: INGENIERIO DE SISTEMAS
GRADO: INGENIERO
CARGO: JEFE DE SISTEMAS EN EL HOSPITAL LA CALETA

una buena alternativa en cuanto a metodologa para la implementacin de un Datawarehouse

C
1
=Estndar
C
2
C
3

Criterio

Metodologa
C
1
C
2
C
3
RUP 4 3 3
XP 3 3 4
METRICA 3 2 2
MFS 2 3 3
B. IMMON 2 4 3
MIPE 2 2 2

Proyecto de Tesis 03 PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Proyecto de Tesis 03 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Universidad Csar Vallejo

Escuela de Ingeniera de Sistemas

Reemplazando valores en ecuacin (eq.2), se tiene:

14 reportes de nuestra, con un promedio de 116 minutos

S-ar putea să vă placă și