¿Cómo

crear
un data
warehouse?
Jordi Conesa (coord.)
Josep Curto
Director de la colección: Lluís Pastor

Diseño de la colección: Editorial UOC

Primera edición: octubre 2015
Primera edición digital: noviembre 2015

© Jordi Conesa, Josep Curto Díaz, del texto

Todos los derechos reservados

© de esta edición, FUOC, 2015
Av. Tibidabo, 39-43, 08035 Barcelona
© Editorial UOC (Oberta UOC Publishing, SL) de esta edición, 2015
Rambla del Poblenou, 156, 08018 Barcelona
www.editorialuoc.com

Realización editorial: Oberta UOC Publishing, SL

ISBN: 978-84-9064-819-3

Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o
transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación fotocopia, o cualquier
otro, sin la previa autorización escrita de los titulares del copyright.
Índice
Cómo usar un modelo H2PAC7

El reto

El conocimiento imprescindible
La teoría
El desarrollo

Las soluciones
 Cómo usar un
modelo H2PAC
Este modelo plantea resolver propuestas clave a partir de
ACTIVIDADES. A continuación os explicamos cómo manejaros
por el libro y sacarle partido a través de tres fases.

El reto
En las páginas de color rojo encontrarás el reto que te plantea este libro.

El conocimiento
imprescindible
En las páginas centrales encontrarás la teoría imprescindible que te ayudará a
entender los conceptos clave y poder obtener las respuestas al reto.
 Las soluciones
En las páginas de color verde encontrarás el solucionario para resolver correctamente
el reto propuesto.
 El reto
Josep Curto
Jordi Conesa

Este reto está basado en un caso real: la evolución del modelo sanitario catalán y la
transformación de sus sistemas de información para adaptarse al entorno y a las nuevas
estrategias planteadas. El caso está enfocado en realizar el diseño e implementación del
núcleo de toda herramienta de inteligencia de negocio: el almacén de datos1.

El material del actual caso consta de cuatro partes diferenciadas. La primera está centrada en
la creación de un estudio de viabilidad sobre la creación de un almacén de datos; la segunda,
en desarrollar e implementar un almacén de datos que permita la gestión del área de
hospitalización de un hospital; la tercera, en diseñar e implementar los procesos de carga de
datos necesarios para disponer de información en almacén de datos implementado; y la cuarta,
en la creación de elementos de análisis multidimensional para la explotación de información.

Con el fin de poder desarrollar un proyecto lo más específico posible, se aborda el reto de
desarrollar un almacén de datos que solo describe parte de las áreas de un hospital básico del
sector público. Es importante recordar que el diseño, desarrollo e implantación de este tipo de
herramientas supone, en general, meses o incluso años en función de la naturaleza y el grado
de madurez de la empresa y del alcance del proyecto, requiriendo la participación de equipos
multidisciplinares que van implementando diferentes proyectos en un proceso de mejora
continua.

El objetivo de este caso no es desarrollar un almacén de datos que dé respuesta a todas las
necesidades de una organización, sino entender y utilizar las metodologías para desarrollar
este tipo de proyectos en un contexto real pasando por todas las fases que comprenden este
tipo de proyecto. A saber, evaluación, diseño, implementación, carga y explotación.

Mediante el desarrollo del caso planteado, el lector se enfrentará con los problemas, dudas y
dificultades más comunes que se plantean en un proyecto de estas características.

1. Contexto

El desarrollo de este caso se centrará, fundamentalmente, en el área de hospitalización.

Para que el lector tenga una referencia más concreta sobre la que desarrollar el caso, se
propone una estructura genérica de la organización, así como una descripción general de los
procesos básicos de hospitalización.

Esta estructura se ofrece solamente a título orientativo, sin que tenga que condicionar el
desarrollo del caso. El propósito principal es que sirva como referencia a todos aquellos que
no estén familiarizados con estos entornos, con el fin de que puedan comprender mejor la
actividad propia de un centro hospitalario.

2. Potenciales usuarios del almacénde datos

Antes de entrar a detallar el funcionamiento de las áreas de urgencias y hospitalización,

debemos saber quiénes son los potenciales usuarios del almacén de datos para un hospital
público; por lo tanto, se tendrá que indicar qué tipo de preguntas debe ser capaz de responder
nuestro sistema.

Los actores involucrados en un sistema de salud suelen tener intereses muy diversos y a
menudo contrapuestos. En nuestro caso particular, los actores a tener en cuenta son:
1) Las autoridades sanitarias, tanto por lo que respecta al Departamento de Salud de la
Generalitat como al Catsalut. A partir de sus políticas sanitarias y de compra de servicios,
determinarán de forma clave la actividad que debe proporcionar finalmente nuestro centro.
No podemos olvidar que un altísimo porcentaje de la facturación de los hospitales públicos
proviene de las propias autoridades sanitarias y, por lo tanto, será esencial dotarnos de
mecanismos que nos aseguren que nuestra cartera de servicios y nuestra «capacidad de
producción» están ajustadas a la oferta que debemos proveer.

2) La institución ICS. En nuestro caso, al tratarse de un centro del Instituto Catalán de la Salud
(ICS), los objetivos estratégicos de la institución ICS necesariamente se trasladarán a cada
uno de los centros. Con toda probabilidad, gran parte de estos objetivos estarán
completamente alineados con los objetivos de las autoridades sanitarias, pero habrá otros
que estarán condicionados por las propias directrices corporativas, o incluso, por los
procesos internos de gestión en ámbitos como pueden ser: logística, compra agregada,
política de recursos humanos, compra de productos intermedios, etc.
3) La propia dirección del centro. Obviamente, tendrá un papel clave según el grado de
autonomía que le otorga el propio ICS, supuestamente cada vez mayor debido a los
procesos de descentralización que se están produciendo dentro del nuevo modelo de
empresa pública. Probablemente, en un hospital general básico el grado de diferenciación o
especialización no será significativo y, por tanto, el grado de personalización y
especificidad de su sistema de cuadro de mando tampoco lo será.
4) Los profesionales. Otro de los actores relevantes serán los propios profesionales que
desarrollan su actividad en las diferentes áreas, como asistencial, administrativa, etc. Será
esencial, para los responsables de las distintas áreas, disponer de mecanismos para el
seguimiento y control de sus actividades, así como de la calidad de los servicios que
prestan, tanto desde un punto de vista cualitativo como cuantitativo. Cabe tener en cuenta
que su actividad estará enormemente condicionada por la oferta que deben generar (de
acuerdo a la compra de servicios pactada con las autoridades sanitarias) y de los recursos
de que dispongan para satisfacerla de acuerdo a unos determinados estándares de calidad,
propios o inducidos por otros actores.
5) El propio entorno sanitario del centro. A partir del despliegue del nuevo modelo de salud
en base a pago capitativo, es imprescindible tener en cuenta la interrelación y colaboración
entre los diferentes actores dentro de un mismo territorio (área capitativa).
6) El entorno político y social del centro. No debemos olvidar que estamos trabajando con
servicios públicos y que se establece una estrecha relación entre los distintos ámbitos
sociopolíticos locales: gobiernos locales, servicios sociales, agrupaciones de vecinos,
colectivos específicos, etc. Aunque no existe una relación directa entre la atención
individualizada y el papel que desempeñan estos colectivos, está claro que juegan un papel
decisivo en lo referente a representación social y, por lo tanto, es necesario tenerlos en
cuenta en el desarrollo de determinadas estrategias.
7) El ciudadano. El último actor a describir, aunque probablemente uno de los más relevantes.
El ciudadano, entendido como el paciente y su entorno familiar directo, es el beneficiario
 directo del servicio prestado. Sobre él será preciso desarrollar un seguimiento específico, y
no solo desde el punto de vista asistencial, sino también desde el emocional. En este
sentido, cabe tener presente que la atención sanitaria va mucho más allá del acto meramente
clínico y que comporta muchas otras variables, que a menudo pueden tener tanto o más peso
que la propia curación (siempre que sea posible) en la percepción del paciente: atención
prestada, buen trato, respeto, celeridad, diligencia, cantidad y calidad de la información
recibida, soporte emocional, psicológico, etc.

A menudo, veremos que muchos de los objetivos estratégicos pueden estar relacionados con
diferentes actores. Esto lo podemos observar rápidamente en los documentos de referencia de
las autoridades sanitarias:

• «Pla de Salut 2011-2015», del Departamento de Salud.

• «Tercer Informe» de la Central de Resultados.

En ellos, podemos ver el grado de detalle y la diversidad de ámbitos sobre los que se recoge
información, y que, cada vez de forma más clara, se reflejan en los contratos de servicios que
se establecen entre las autoridades sanitarias y los distintos centros sanitarios.

3. Funcionamiento básico del áreade urgencias

Las áreas de urgencias hospitalarias son las responsables de dar respuesta a las necesidades
de salud de los ciudadanos, en lo que se refiere a la atención de urgencias y emergencias que
tengan que ver con problemas de salud sobrevenidos, sea cual sea su causa.

Normalmente, estas áreas están diseñadas para la atención de urgencias críticas y graves.
Aunque históricamente, debido a diferentes motivos, han sido utilizadas por parte de la
mayoría de los ciudadanos para el tratamiento de cualquier problema de salud imprevisto o
sobrevenido, en lugar de dirigirse a la atención primaria. Este hecho ha impactado
enormemente en su funcionamiento, generando efectos negativos, como la sobreocupación de
espacios, las largas esperas, el hacinamiento, los tiempos de asistencias anormalmente largos,
los tiempos de espera excesivos para la realización de pruebas complementarias, etc. Todo
ello ha implicado una serie de problemas de gestión y ha provocado una pérdida de calidad
del funcionamiento de las áreas de urgencia.
Además, la enorme variabilidad de la práctica clínica en el uso de los recursos para cada una
de las asistencias puede ser tremendamente cambiante.

A continuación, mostramos un circuito estándar de atención en urgencias.

Los principales canales de entrada a las áreas de urgencias suelen ser los siguientes:

• El desplazamiento del propio paciente al servicio de urgencias por sus propios medios.
• A través de transporte sanitario, tras un accidente laboral, de tráfico o en otras
circunstancias, que le impiden la movilidad.
• La derivación desde otros centros sanitarios o de atención primaria que no pueden atender al
paciente en origen, por saturación o por no disponer de las especialidades y/o medios
necesarios.

Dependiendo de los síntomas, el diagnóstico inicial y la severidad potencial de la urgencia

detectada en las unidades de triaje,2 el paciente será asignado a una unidad para su tratamiento
y seguimiento, con el fin de determinar su diagnóstico y dar solución al problema de salud que
presenta. Un servicio de urgencias, como el de nuestro caso, generalmente suele contar con
una serie de servicios o especialidades básicas, ya que dispone de recursos humanos y
técnicos especializados para el tratamiento de problemas de salud relativos a los mismos. A
modo de ejemplo, los servicios básicos pueden ser:

• Urgencias generales.
• Urgencias obstétricas (relativas al parto) y ginecológicas.
• Urgencias pediátricas.
• Urgencias traumatológicas.
• Urgencias oftalmológicas.

Adicionalmente, podremos encontrar:

• Las unidades o salas de observación, que no están vinculadas necesariamente a una
especialidad, sino que suelen ser espacios polivalentes, en los cuales el paciente queda en
observación con el fin de evitar la ocupación de las áreas específicas de cada servicio, o
asegurar que pueden ser fácilmente supervisados por personal médico.
• Las unidades de corta estancia, que están dedicadas a los tratamientos que no requieren de
hospitalización, pero que dada su urgencia no suelen tratarse dentro de las áreas de consulta
externa.

Normalmente, el paciente será sometido a pruebas diagnósticas (radiología, laboratorio,

diagnóstico por la imagen, etc.), a tratamientos farmacológicos y a los procedimientos
médicos y quirúrgicos que se consideren necesarios en función de la patología diagnosticada.

Las asistencias en urgencias derivan en uno de los siguientes motivos de alta:

• Alta a domicilio (normalmente, según criterio médico, aunque también puede ser por
abandono o voluntaria).3
• Ingresos (con o sin intervención).
• Derivación hacia otro centro sanitario.
• Defunción.

Además de los requerimientos que se puedan establecer desde el propio centro o urgencias, el
Catsalut también monitoriza, especialmente en determinadas épocas del año o zonas, el
funcionamiento de dichas áreas con el fin de identificar situaciones de excesiva saturación o
incluso analizar posibles problemas epidemiológicos que puedan surgir y que afecten a la
salud pública. En este sentido, a través del PIUC (Plan Integral de Urgencias de Cataluña), se
monitorizan a diario determinados parámetros de funcionamiento y clínicos de las áreas de
urgencias de todos los centros de la XHUP (Red Hospitalaria de Utilización Pública).

4. Funcionamiento básico del áreade hospitalización

Los hospitales están organizados (desde un punto de vista asisten cial) en servicios clínicos,
con mayor o menor nivel de especialización dependiendo de su categoría.
De forma genérica, los servicios clínicos se organizan en dos grandes ámbitos, el médico y el
quirúrgico, que se diferencian fundamentalmente en el uso que se realiza de las áreas
quirúrgicas (preanestesia, quirófanos y reanimación) por parte de los médicos.

Aunque esta separación no siempre es completamente clara, ya que hay subespecialidades

dentro de la cartera de servicios que superponen los dos ámbitos, los servicios habituales en
un centro hospitalario básico son los siguientes:

Aparte de los servicios de soporte claramente identificados, en los procesos del hospital hay
otros relacionados con la atención hospitalaria, como son:

• Las unidades de cuidados intensivos (UCI).

• Los servicios de anestesia y reanimación, también a menudo relacionados con áreas médicas
para curas paliativas (la clínica del dolor).

Para simplificar nuestro caso, consideraremos solo la hospitalización convencional,

excluyendo la actividad vinculada a la cirugía sin ingreso, la cirugía mayor ambulatoria4 o el
hospital de día.

En lo que se refiere a las áreas de hospitalización, podemos considerar dos líneas bien
diferenciadas de acceso:

• La admisión urgente, generalmente derivada de la actividad del servicio de urgencias.

• La admisión programada, que normalmente vendrá derivada de atención primaria o de la
atención especializada (consulta externa) del propio centro.

Esta actividad programada tiene que ser gestionada por las áreas de gestión asistencial
(gestión administrativa) y por los propios servicios clínicos, que deben priorizar y asignar sus
recursos (generalmente, basados en ocupación de camas o quirófanos) según la urgencia,
criticidad y complejidad de cada caso, y según la disponibilidad de recursos. Esta gestión es
lo que se conoce como gestión de la lista de espera.

Aparte de la gestión propia de la lista de espera, determinada por el propio servicio y, por
extensión, del propio centro, dependiendo de su funcionamiento y de la disponibilidad de
recursos, las autoridades sanitarias establecen objetivos a cumplir por parte de cada uno de
los centros en sus contratos de compra de servicios, y que afectan al pago de los servicios
adquiridos de acuerdo a los niveles de cumplimiento mínimos establecidos.

Cabe recordar que, en el modelo de compra y facturación de los servicios establecidos por
Catsalut, no solo se compra una determinada actividad quirúrgica, sino que esta también debe
prestarse de acuerdo a unos determinados indicadores de calidad (normalmente de tipo
temporal). Los centros deberán garantizar el cumplimiento de estos indicadores para asegurar
que se satisfacen adecuadamente los contratos de compra firmados con Catsalut.

5. Gestión de la lista de espera

Es de primordial interés para el centro conocer, en todo momento, el número de pacientes de

cada patología y el tiempo que llevan registrados para asegurar que se cumplen los plazos
fijados por la ley o, incluso, en caso de ser necesario, se puedan derivar hacia otros centros;
además, hay que poder distribuir la actividad en función de la disponibilidad de los espacios,
los profesionales, las pruebas complementarias, etc.

Cabe diferenciar dos tipos de espera:

• La estructural, provocada por el propio sistema. Cuando el paciente está esperando a ser
intervenido por estar pendiente de otra prueba médica o diagnóstica, o por razones
administrativas, como la no existencia de quirófano libre o que el médico haya tenido que
ausentarse.
• La no estructural, debida al deseo del paciente. Preferencia de no ser derivado a otro centro
hospitalario para ser atendido, motivos personales que hacen posponer su intervención o
cita, elección de un periodo determinado para su intervención, o cualquier otra razón que
haga que la intervención se retrase por causa del paciente.

Asimismo, mediante sistemas de puntuación, los propios facultativos establecen prioridades

sobre la urgencia o necesidad de la intervención para que las unidades de gestión asistencial
gestionen eficientemente la lista de espera basándose en criterios clínicos.

A partir de la prescripción de la intervención quirúrgica por parte del personal facultativo, el

centro debe entregar un documento informativo de indicación de la intervención quirúrgica,
donde consta la fecha de inclusión en la lista de espera para la intervención en garantía.

Periódicamente (mínimo una vez al mes), el centro debe notificar a Catsalut la relación de
pacientes que están incluidos en la lista de espera.

Los datos que habitualmente se manejan en la lista de espera quirúrgica son los siguientes (a
título orientativo):

1) Los datos mínimos a incluir por cada registro de demanda quirúrgica deben ser:
• Datos de identificación del paciente.
• Fecha de inscripción en el registro.
• Indicación de la intervención quirúrgica por el facultativo especialista responsable del
paciente, con constancia de los diagnósticos y procedimientos previstos.
• Prioridad clínica de la intervención.
• Aceptación por el paciente, o persona autorizada, de su inscripción en el registro.

2) Si procede, además, debe incluir los siguientes datos:

• Causa de la suspensión del cómputo del plazo máximo de atención quirúrgica.
• Fecha de inicio de la suspensión.
• Fecha de reinicio del cómputo del plazo máximo de atención quirúrgica, una vez
desaparecida la causa que motivó la suspensión.
• Fecha de baja en el registro.
• Causa de la baja en el registro.
• Causa que motiva la pérdida de la garantía de atención quirúrgica en el plazo que se haya
establecido y fecha de la pérdida de la garantía.

Por otro lado, existe una información necesaria para la dirección clínica y el propio centro,
que debe ser gestionada:

• Fecha de entrada del paciente en el registro.

• Servicio quirúrgico que prescribe la inclusión en RDQ (registro de demanda quirúrgica).
• Facultativo.
• Prioridad clínica del paciente:
– Prioritario.
– Preferente.
 – Ordinario.
• Diagnóstico de inclusión: codificación según la Clasificación Internacional de
Enfermedades (CIE-9 y CIE-10) vigente.
• Procedimiento quirúrgico previsto: codificación según la Clasificación Internacional de
Enfermedades (CIE-9 y CIE-10) vigente.
• Situación del paciente (tipo de espera):
– Paciente en espera «estructural».
– Paciente transitoriamente no programable.
– Paciente en espera tras rechazo de centro alternativo.
• Motivo de salida (tipo de conclusión del episodio):
– Episodio no finalizado en la fecha de análisis.
– Intervención en el propio centro.
– Intervención en otro centro alternativo.
– Otros motivos de salida.
• Fecha de salida:
– Sin fecha de salida (episodio no finalizado en la fecha de análisis).
– Fecha de la intervención quirúrgica del paciente o la fecha de salida por otros motivos.

6. Fuentes de datos

Para el presente caso, cuyo objetivo es el diseño de un almacén de datos y la consecuente

carga de información, se proporcionan datos de hospitalización. Los datos de urgencias y lista
de espera no se tendrán en cuenta para delimitar el problema a un volumen más manejable
para un caso práctico de estas características. Estos ficheros son el resultado del
funcionamiento operativo de un hospital básico y recogen la información principal en términos
de paciente, procedimiento, fechas, tratamiento, etcétera descrita en los apartados anteriores.

Cabe comentar que estos ficheros han sido tratados para que cumplan las condiciones de la
Ley orgánica de protección de datos (LOPD) y en ningún momento se vulnere los derechos de
los pacientes.
Los datos pueden descargarse desde la wiki asociada al libro, concretamente desde el
siguiente enlace: http://goo.gl/NGGR8s

7. Actividades a realizar para satisfacerel reto planteado

7.1. Estudio preliminar

Como todo proyecto, el diseño e implementación de un almacén de datos debe ser viable y
rentable para ser llevado a cabo. Como punto inicial de este caso, el lector deberá evaluar si
el proyecto debe ser implementado o no en función de distintos parámetros.

Para ello, el lector debe hacer un análisis del periodo de retorno de inversión,5 de la tasa
interna de rentabilidad,6 del descuento de flujos financieros7 y del retorno de la inversión.8

Para facilitar dicho análisis, se van a asumir ciertas hipótesis sobre el proyecto.

Supongamos que el hospital básico tiene la intención de desplegar, progresivamente, el

proyecto de almacén de datos incorporando más usuarios al sistema conforme pasan los años,
de forma que el primer año tan solo habrá 25 usuarios y se incorporan de 10 en 10 los
siguientes años, alcanzando los 65 usuarios en el quinto año.

Supongamos que la inversión inicial del proyecto es 76.000 euros y que los costes de los
siguientes años incluyen mantenimiento, evolución y nuevas licencias del sistema, siendo
16.700 euros anuales para los siguientes tres años. Consideremos también que la compañía
considera que es capaz de generar beneficios derivados de la implantación del almacén de
datos (como, por ejemplo, resultantes de liberar recursos por la automatización de tareas). Los
beneficios estimados son 20.000 euros en el primer año, 25.000 en el segundo y 35.000 en
cada uno de los tres años restantes. Finalmente, consideremos que la tasa de descuento es del
10 % a lo largo del periodo de cinco años considerado.

Bajo el contexto descrito, la dirección general del hospital se pregunta si vale la pena invertir
en el proyecto de diseño de un almacén de datos para la gestión de urgencias y
hospitalización, y en qué medida el proyecto podría ser rentable.
7.2. Diseño de data warehouse

A partir del análisis del contexto del caso y de las fuentes de datos disponibles de
hospitalización,9 se deberá diseñar un almacén de datos que permita realizar el seguimiento
estratégico y operativo del área de hospitalización de un hospital general básico tal y como se
ha descrito en el contexto.

Con el objetivo de poder recorrer todas las fases de este tipo de proyectos, la actividad se
centrará tan solo en la hospitalización.

Mediante la metodología de diseño de un data warehouse, se deberá plantear:

1) El análisis de requerimientos: describir las necesidades de la organización e identificar las

preguntas que debe responder el sistema para el área de hospitalización.
2) El análisis de fuentes de datos: dónde se deben revisar las fuentes de datos proporcionadas,
qué tipo de información contienen, cuál es su formato, y qué cantidad representa para la
carga inicial.
3) El análisis funcional: proponer el tipo de arquitectura para la factoría de información
adecuada para el proyecto (por ejemplo, si es necesario un data mart operacional o una
estructura de carga intermedia).
4) Diseño para el modelo conceptual, lógico y físico del almacén de datos: dónde se deben
identificar, diseñar e implementar las tablas de hecho, las dimensiones y atributos que
pueden representar la información de hospitalización para un hospital general, así como
aquellas estructuras consideradas en el punto 3.

Para el desarrollo del data warehouse, es preciso definir correctamente los hechos (facts), las
dimensiones de análisis (dimensions) y los atributos que nos permitan tener el nivel de
granularidad suficiente para la medida y presentación de los objetivos que se definan en el
análisis de requerimientos.

7.3. Carga de datos

Se pide el desarrollo de los procesos de carga del data warehouse propuesto en la segunda
parte de este caso.

A partir del análisis de fuentes de datos, se deberán diseñar los procesos de extracción,
transformación y carga de los datos existentes en los ficheros proporcionados, que contienen
información operativa.

Se deberá tener en cuenta que esta es una carga inicial de almacén de datos, por lo que se
espera que, teniendo en cuenta el período que comprenden los datos y su cantidad, se hagan
estimaciones sobre las necesidades de arquitectura del almacén de datos (por ejemplo, tiempo
de carga, estimaciones de crecimiento, etc.).

Por lo tanto, las tareas a realizar son:

• Identificar los procesos necesarios para la extracción, transformación y carga de datos.

• Describir las acciones a realizar en cada proceso,
• Implementar los procesos mediante las herramientas de diseño proporcionadas.
• Realizar la carga de datos de forma efectiva.

7.4. Explotación de datos

Por último, se debe diseñar un modelo OLAP para el análisis multidimensional de la

información disponible en el data warehouse que permita a un analista de negocio investigar
el rendimiento operativo del área de hospitalización de un hospital general básico. Para ello,
debe:

a) A partir del análisis de requerimientos:

• Identificar qué usuarios son los susceptibles de usar análisis multidimensionales, teniendo
en cuenta que este tipo de usuarios son avanzados y, por lo tanto, buscar analizar ellos
mismos la información.
• Proponer el tipo de preguntas que debe responder el análisis multidimensional para estos
usuarios.
• El sistema debe responder cómo mínimo a las siguientes preguntas:
– Evolución de las hospitalizaciones
– Evolución de las hospitalizaciones por tipo de alta
– Evolución de las hospitalizaciones por meses y años
– Evolución de las hospitalizaciones por servicio del hospital
b) Diseñar e implementar un análisis multidimensional que responda al contexto descrito.
c) Mostrar cómo el sistema responde a las preguntas mínimas de los usuarios.

Wiki de soporte

Para el presente caso, la UOC proporciona una wiki que contiene todos los elementos
necesarios para que el lector pueda reproducir todos los pasos que se describen en este libro.
En particular, la wiki contendrá los ficheros necesarios para realizar la actividad, detalles
sobre el sistema utilizado para implementar la solución y la guía, paso a paso, de las
diferentes etapas de creación del data warehouse.

Se puede acceder a la wiki a través de la siguiente URL

http://cv.uoc.edu/webapps/xwiki/wiki/disenodatawarehouse/ o utilizando el siguiente código
QR:

7.5. Glosario

cartera de servicios f Conjunto de prestaciones, tratamientos y procedimientos que ofrece un

determinado centro a partir de sus unidades asistenciales. Normalmente, están organizadas
sobre la base de servicios clínicos, como los que se han descrito en el presente caso.

cirugía mayor ambulatoria f Se encarga de las intervenciones realizadas en pacientes de muy

diferentes especialidades, que no están ingresados sino que pasan el posoperatorio en su
domicilio. El paciente es convocado para una intervención y, una vez recuperado y pasado el
periodo de observación, se le deriva al domicilio, dentro del mismo día, sin ocupar una
habitación en ningún momento del proceso. La cirugía mayor ambulatoria tiene unas
características propias: es un proceso asistencial común, se realiza en un número limitado de
procedimientos y es multidisciplinaria. Su actividad ha ido en aumento, con reconversiones de
la cirugía convencional y la de estancia corta, mejorando su eficacia y eficiencia. Estas
unidades suelen llevar a cabo mucha actividad de anestesia loco-regional (terminología
médica para indicar anestesias que afectan a una zona o región específica, por ejemplo,
epidural), técnica que ha evolucionado en los últimos años con la utilización del seguimiento
ecográfico. sigla CMA

CMA f Véase cirugía mayor ambulatoria.

hospital de día m Estructura sanitaria asistencial donde el paciente recibe las técnicas
terapéuticas que requiere sin necesidad de abandonar su entorno familiar. El paciente es
internado por un plazo de horas determinado, durante las cuales recibe todos los tratamientos
especializados (terapias con aparatos, análisis, control postoperatorio, etc.) que requieren
seguimiento por parte de personal especializado, o de aparatos médicos que deben ser
manipulados dentro de instalaciones médicas. Al finalizar la atención, el paciente vuelve a su
hogar. Como ejemplos tenemos, entre otros, la diálisis, tratamientos oncológicos, etc.

productos intermedios m pl Cualquiera de los tratamientos, pruebas, etc. a que es sometido el

paciente con objeto de dar soporte y/o mejorar el diagnóstico o tratamiento de su proceso de
salud. En este sentido, podemos considerar como producto intermedio las pruebas
diagnósticas, rehabilitación, análisis clínicos, pruebas funcionales, etc.

1 En inglés, data warehouse.
2 En lasunidades de triaje se estableceunaprimeraclasificación de los paci¬entes en función de sucriticidad y patología. La
atención de los pacientes se priorizaráporlasdecisiones de triaje y no pororden de llegada. El objetivoesatenderrápidamente a los
pacientescríticos y evitarquepermanezcan en la sala de espera sin tratamiento.
3 Se entiendeporaltavoluntariaaquella en la que el paciente decide aban¬donar el hospital en contra del criteriomédico. En
talcasodebefirmar un documentoqueexime al médico/hospital de cualquierresponsabilidadsobre lo que le puedasuceder con
relación al diagnósticorealizado.
4 Para másinformación, vercirugía mayor ambulatoriaen el glosario.
5 El periodo de retorno de la inversiónes el tiempoquetrascurreparaque el proyectogenereunflujo de cajaequivalente a la
inversiónrealizada.
6 La tasainterna de rentabilidad, TIR, mide la tasa de variación de la riquezageneradapor el proyectoporunidad de tiempo. En el
caso de unproyecto de inversión, si la TIR es mayor que la tasa de descuento, se acepta el proyecto.
7 El descuento de flujosfinancierossirveparaobtener el valor actual neto, VAN, de los flujos de ingresos y gastos en el periodo de
vida de la inversión.
8 El ROI o retorno de la inversiónpermitedeterminar la rentabilidaddel cap¬ital invertido en un proyecto. La fórmula de
cálculocorresponde al cociente entre los beneficiosconseguidos y el capital invertido.
9 Fichero en formato Excel que se proporcionaconjuntamente con el enun¬ciadodelcaso y quepuededescargasedesde la wiki
asociada al libro.
El conocimientoimprescindible
Josep Curto
Jordi Conesa

La teoría
1. Introducció

Un sistema de inteligencia de negocio está formado por diferentes elementos, pero de todas las
piezas la principal de ellas es el datawarehouse o almacén de datos, ya que es el componente
que almacena los datos a analizar. En este capítulo vamos a explicar qué es un data
warehouse, cómo se cargan los datos en el data warehousemediante los procesos de
Extracción, Transformación y Carga (ETL) y cómo se pueden consultar los datos del data
warehouse de forma fácil, eficiente y potente mediante tecnologías OLAP.

2. Data warehouse: el núcleode la inteligencia de negocio

Un data warehouse1 es un repositorio de datos que proporciona una visión global, común e
integrada de los datos de la organización, independiente de cómo se vayan a utilizar
posteriormente por los consumidores o usuarios, con las propiedades siguientes: estable,
coherente, fiable y con información histórica.

Al abarcar el ámbito global de la organización y un amplio alcance histórico, el volumen de

datos de un data warehouse puede ser muy grande (centenas de terabytes). Las bases de datos
relacionales han sido el medio más usado para almacenar los data warehouse. No obstante, en
la actualidad existen otras opciones que ofrecen modelos de datos más cercanos a las
necesidades analíticas, como por ejemplo, las bases de datos orientadas a columnas o incluso
las basadas en lógica asociativa.

Resumiendo, el data warehouse presenta las siguientes características:

• Orientado a un tema: organiza una colección de información alrededor de un tema central.

• Integrado: incluye datos de múltiples orígenes y presenta consistencia de datos.
• Variable en el tiempo: se realizan fotografías de los datos basadas en fechas o hechos a lo
largo de periodos de tiempo prefijados.
• No volátil: sólo de lectura para los usuarios finales.

Debemos tener en cuenta que existen otros elementos en el contexto de un data warehouse.
Podemos diferenciar estos elementos en los almacenes de datos, procesos y metadatos:

a) Almacenes de datos: permiten definir versiones más actuales, sectoriales o versiones

intermedias del data warehouse. De entre ellos podemos destacar:

• Data Mart: contiene un subconjunto de los datos del DataWarehouse con el objetivo de
responder a un determinado análisis, función o necesidad y con una población de usuarios
específica. Al igual que en un data warehouse, los datos están estructurados en modelos
de estrella o copo de nieve. Los datamarts pueden ser dependientes o independientes de
un datawarehouse. El data mart está pensado para cubrir las necesidades de un grupo de
trabajo o de un determinado departamento dentro de la organización.
• Operational Data Store: es un tipo de almacén de datos que tiene como objetivo permitir
realizar analítica sobre los últimos valores de los datos no disponibles en el data
warehouse. Para ello, los Operational Data Stores proporcionan los últimos valores de
los datos, pero no su historial. Permiten generalmente un pequeño desfase o retraso sobre
los datos operacionales.
• Staging Area: es un área de almacenaje intermedia que se encuentra entre las fuentes de
datos y el data warehouse. Sus principales objetivos son:

– Facilitar la extracción de datos desde fuentes de origen que tengan una gran
heterogeneidad y complejidad.
– Mejorar la calidad de datos.
– Ofrecer una cache de datos operacionales que de soporte al proceso de data
warehousing.
– Permitir al acceso a información no contenida en el datawarehouse.

b) Procesos: permiten el análisis, filtraje, mejora, integración y carga de los datos en los
distintos almacenes de datos. Podemos destacar:

• Data warehousing: es el proceso de diseño, creación, mantenimiento y ampliación de la

arquitectura de un data ware-house. Dentro de los procesos de data warehousing destacan
aquellos que permiten extraer y filtrar datos de las operaciones comunes de la
organización, procedentes de los distintos sistemas de información operacionales y/o
sistemas externos, para transformarlos, integrarlos y almacenarlos en un almacén de datos
con el fin de acceder a ellos para dar soporte en el proceso de toma de decisiones de una
organización.
• Procesos de ETL: es una de las principales tecnologías de integración de datos basada en
la consolidación de datos que se usa tradicionalmente para alimentar los distintos
almacenes de datos (data warehouse, data mart, staging area y operational datastore).
 Usualmente se combina con otras técnicas de consolidación de datos. Es la tecnología que
usaremos en este libro.

c) Metadatos: Datos estructurados y codificados que describen características de los datos y

los procesos que participan en los procesos de data warehousing.

2.1. Elementos de un data warehouse

Es de esperar que la estructura relacional de una base de datos operacional siga las formas
normales de Codd en su diseño. En un datawarehouse no debe seguirse ese patrón de diseño y
se permite desnormalizar la información con el objetivo de optimizar las consultas.

Para identificar la información a tener en cuenta en el data warehouse, debemos identificar, en

el seno de nuestra organización, los procesos de negocio, las vistas para el proceso de
negocio y las medidas cuan tificables asociadas a los mismos. De esta manera hablaremos de
los siguientes elementos del data warehouse:

• Hechos: permiten representar los procesos de negocio de la organización. Por ejemplo, una
venta puede identificarse como un proceso de negocio de manera que es factible, si
corresponde en nuestra organización, considerar el hecho ventas.
• Dimensiones: permiten representar las distintas vistas para un cierto proceso de negocio (o
los distintos puntos de vista desde los cuales se puede analizar). Si regresamos al ejemplo de
una venta, podemos estudiarla a partir del cliente que la ha realizado, la fecha en la que se ha
realizado, los productos que se han venido... Estos conceptos pueden ser considerados como
vistas para este proceso de negocio. Puede ser interesante recuperar todas las compras
realizadas por un cliente. Ello nos hace entender por qué la identificamos como una
dimensión.
• Métricas: son los indicadores de negocio de un proceso de negocio, es decir, aquellos
conceptos cuantificables que permiten medir un proceso de negocio. Están asociados a las
tablas de hecho. Por ejemplo, en una venta tenemos el importe de la misma.

Existen principalmente dos tipos de esquemas para estructurar los datos en un almacén de
datos:

• Esquema en estrella: permite estructurar la información de procesos, vistas y métricas

mediante una estructura de estrella. A nivel de diseño, consiste en una tabla de hecho
(también denominada a veces fact table) en el centro para el hecho objeto de análisis y una o
varias tablas de dimensión por cada punto de vista de análisis que participa de la
descripción de ese hecho. En la tabla de hecho encontramos los atributos destinados a medir
(cuantificar): sus métricas. La tabla de hechos sólo presenta uniones con dimensiones.

• Esquema en copo de nieve: es un esquema de representación derivado del esquema en

estrella, en el que las tablas de dimensión se normalizan en múltiples tablas. Por esta razón, la
tabla de hechos deja de ser la única tabla del esquema que se relaciona con otras tablas, y
aparecen nuevas uniones.

Debido a su importancia, creemos que es conveniente profundizar en los conceptos de tabla de

hecho, dimensión y métrica.

2.2. Tipos de hechos

Un hecho es una representación de un proceso de negocio. A nivel de diseño, en un entorno

relacional, se representa mediante una tabla que permite guardar dos tipos de atributos
diferenciados:

• Medidas del proceso/actividad/flujo de trabajo/evento que se pretende representar.

• Claves foráneas hacia registros en tablas de dimensión (o en otras palabras, como ya
sabemos, hacia una vista de negocio).

Existen diferentes tipos de tablas de hecho:

• Transaction Fact Table: representan eventos que suceden en un determinado espacio-tiempo.

Se caracterizan por permitir analizar los datos con el máximo detalle. Por ejemplo, podemos
pensar en una venta, con métricas como el importe de la misma o el descuento aplicado.
• Factless Fact Tables/Coverage Table: son tablas que no tienen medidas. Estas tablas de
hecho pueden tener sentido para representar la ocurrencia de un determinado hecho. Por
ejemplo, podemos pensar en la asistencia a un acto benéfico. En este caso, podríamos
almacenar un registro por cada persona que asista pero podríamos no tener ninguna métrica
asociada más. Frecuentemente se añaden contadores a dichas tablas para facilitar las
consultas SQL.
• Periodic Snapshot Fact Table: son tablas de hecho usadas para recoger información de
forma periódica a intervalos de tiempo regulares que dependen de las necesidades de
negocio. Por ejemplo, podemos pensar en el balance mensual donde los datos se recogen
acumulados de forma mensual.
• Accumulating Snapshot Fact Table: representan el ciclo de vida completo de una actividad
o proceso, que tiene un principio y final. Se caracterizan por presentar múltiples dimensiones
relacionadas con los eventos presentes en un proceso. Por ejemplo, podemos pensar en un
proceso que gestiona una incidencia, que recopila diferentes datos, como el inicio de la
incidencia o la asignación del responsable que debe gestionarla su resolución.

2.3. Tipos de dimensiones

Las dimensiones recogen los puntos de análisis de un hecho. Por ejemplo, una venta se puede
analizar respecto el día de venta, el producto vendido, el cliente, el vendedor o el canal de
venta utilizado entre otros.

Respecto la gestión histórica que se realiza sobre los datos de las dimensiones, se pueden
clasificar como SCD Tipo X, donde SCD es la abreviatura de Slowly Changing Dimension y
X es un número que indica la política de actualización de datos usada. Los tipos posibles son:

• SCD Tipo 0: No se tiene en cuenta la gestión de los cambios históricos y no se realiza

esfuerzo alguno. Nunca se cambia la información, ni se reescribe.
• SCD Tipo 1: No se guardan históricos. La nueva información siempre sobrescribe la antigua.
Principalmente la sobrescritura se realiza por errores de calidad de datos. Estas dimensiones
son fáciles de mantener y son usadas cuando la información histórica no es importante.
• SCD Tipo 2: Toda la información histórica se guarda en el data warehouse. Cuando hay un
cambio se crea un nuevo registro que contiene la nueva información y su correspondiente
fecha de carga. A partir de ese momento, el nuevo valor será el valor usado para las futuras
entradas. Las antiguas usaran el valor anterior.
• SCD Tipo 3: Toda la información histórica se guarda en el data warehouse. En este caso se
crean nuevas columnas con los valores antiguos y los actuales son remplazados con los
nuevos.
• SCD Tipo 4: es lo que se conoce habitualmente como tablas históricas. Existe una tabla con
los datos actuales y otra con los antiguos o los cambios.
• SCD Tipo 6 / Híbrida: combina las aproximaciones de los tipos 1, 2 y 3 (y claro, entonces
1+2+3=6). Consiste en considerar una dimensión de tipo 1 y añadir un par de columnas
adicionales que indican el rango temporal de validez de una de las columnas de la tabla. Si
bien es diseño es complejo, entre sus beneficios podemos destacar que reducen el tamaño de
las consultas temporales. Existe otra variante para este tipo de dimensión que consiste en
tener versiones del registro de la dimensión (numerados de 0 a n+1 donde 0 siempre es la
versión actual).

Existen otros tipos de dimensiones, cuya clasificación es funcional:

• Degeneradas: son dimensiones que, por su simplicidad, pueden representarse mediante

atributos en la tabla de hechos, como por ejemplo, el género de un paciente. Se suelen
encontrar como atributos en la tabla de hecho si bien tiene el significado de un punto de vista
de análisis. Contienen información de baja cardi nalidad formada por relaciones
dicotómicas.
• Monster: dimensiones que pueden crecer desmesuradamente. Una buena práctica en este tipo
de dimensiones es romper la dimensión en dos tablas: una que contenga los valores estáticos
y otra que contenga los valores volátiles. Un ejemplo claro, puede ser la información de
cliente. Debemos ser conscientes de cuál es la información primordial del mismo respecto la
que sólo se usa puntualmente en los informes u otros análisis.
• Junk: contiene información volátil que se usa puntualmente y que no se guarda de forma
permanente en el data warehouse.
• Conformadas: permite compartir información entre dimensiones y cruzar información.
Consiste en dimensiones vinculadas a uno o más hechos que coinciden en todos los niveles
de detalle en sus atributos. El ejemplo más fácil es la dimensión temporal.
• Bridge: permiten definir relaciones de muchos a muchos (N a M) entre hechos. Un ejemplo
sería la tabla necesaria para relacionar un piloto y sus múltiples patrocinadores.
• Role-playing: tienen asignado un significado. Por ejemplo, podemos tener la dimensión
fecha, pero también fecha de entrega.
• Alta cardinalidad: contienen una gran cantidad de datos difícilmente consultables en su
totalidad. Por ejemplo, cada uno de los habitantes de un país.

2.4. Tipos de métricas

Podemos distinguir diferentes tipos de medidas, basadas en el tipo de información que

recopilan así como su funcionalidad asociada:

• Métricas: valores que recogen el proceso de una actividad o los resultados de la misma.
Estas medidas proceden del resultado de la actividad de negocio.

– Métricas de realización de actividad (leading): miden la realización de una actividad. Por

ejemplo, la participación de un jugador en un partido de básquet.
– Métricas de resultado de una actividad (lagging): recogen los resultados de una actividad.
Por ejemplo, la cantidad de puntos de un jugador en un partido.

• Indicadores clave: entendemos por este concepto, valores correspondientes que hay que
alcanzar, y que suponen el grado de asunción de los objetivos. Estas medidas proporcionar
información sobre el rendimiento de una actividad o sobre la consecución de una meta.

– Key Performance Indicator (KPI): Indicadores clave de rendimiento. Más allá de la

eficacia, se definen unos valores que nos explican en qué rango óptimo de rendimiento nos
deberíamos situar al alcanzar los objetivos. Son métricas de proceso. Por ejemplo, un
grado de satisfacción de cliente de 9 sobre 10.
– Key Goal Indicator (KGI): Indicadores de metas. Definen mediciones para informar a la
dirección general si un proceso ha alcanzado sus requisitos de negocio, y se expresan por
lo general en términos de criterios de información. Por ejemplo, en algunos deportes los
bonos de los jugadores están ligados a la cantidad de puntos o goles marcados.

Debemos distinguir que existen también indicadores de desempeño. Los indicadores clave de
desempeño (en definitiva, son KPI) definen mediciones que determinan qué tan bien se está
desempeñando el proceso de TI para alcanzar una determinada meta. Su uso permite estimar
cuan factible será alcanzar una meta o no, y son buenos indicadores de las capacidades,
prácticas y habilidades. Los indicadores de metas de bajo nivel se convierten en indicadores
de desempeño para los niveles altos.

2.5. Arquitectura de un data warehouse

Existen principalmente tres enfoques en la arquitectura corporativa de un data warehouse:

• Enterprise Bus Architecture (o Data Warehouse Virtual / Federado): También conocido

como MD (Multidimensional Architecture), consiste en una arquitectura basada en data
marts independientes federados que pueden hacer uso de una staging area en caso de ser
necesario. Federados quiere decir que se hace uso de una herramienta EII (Enterprise
Information Integration) para realizar las consultas como si se tratara de un único data
warehouse. Puede existir también un ODS, en caso de que se considere necesario.

• Corporate Information Factory (o Enterprise Data Warehouse):Consiste en una

arquitectura en la que existe un data warehouse corporativo y distintos data mart (o incluso
cubos OLAP) dependientes del mismo. El acceso a datos se realiza a partir de los data marts
o del ODS en caso de existir, pero nunca se consulta el data warehouse directamente. Puede
existir, en el caso de ser necesaria, una staging area.
• Enterprise Data Warehouse 2.0: consiste en la revisión de la metodología de Bill Inmon
para incluir toda la experiencia de los últimos veinte años. El punto diferencial es que se
separa la información según su antigüedad y se clasifica según su uso. Se caracteriza por
incluir tanto información estructurada como no estructurada y por focalizarse en responder a
todas las necesidades actuales de negocio. Es decir, distingue diferentes entornos en función
de lo actual que es la información y como se usa.
3. Procesos de ETL

En el contexto del data warehousing existen diferentes técnicas y tecnologías para la

integración de datos. Se entiende por integración de datos al conjunto de aplicaciones,
productos, técnicas y tecnologías, que permiten una visión única consistente de nuestros datos
de negocio.

En el contexto de la inteligencia de negocio, las herramientas de ETL han sido la opción usual
para alimentar el data warehouse. La funcionalidad básica de estas herramientas está
compuesta por:

• Gestión y administración de servicios

• Extracción de datos
• Transformación de datos
• Carga de datos
• Gestión de datos

En los últimos años, estas herramientas han evolucionado incluyendo más funcionalidades
propias de una herramienta de integración de datos. Podemos destacar:

• Servicios de acceso/entrega de datos (vía adaptadores/conectores)

• Gestión de servicios
• Data profiling
• Data Quality
• Procesos Operacionales
• Servicios de transformación: CDC, SCD, validación, agregación
• Servicios de acceso a tiempo real.
• Extract, Transform and Load (ETL)
• Enterprise Information Integration (EII)
• Enterprise Application Integration (EAI)
• Capa de transporte de datos
• Gestión de metadatos

Esta evolución es consecuencia de diversos motivos. Por un lado está la propia evolución de
las necesidades de negocio y por otro, el incremento en riqueza de los tipos de datos
disponibles en la organización:

• Estructurados: contenidos en bases de datos.

• Semiestructurados: en formatos legibles para máquinas si bien no están completamente
estructurados: HTML tabulado, Excel, CSV... que pueden obtenerse mediante técnicas
estándar de extracción de datos.
• No estructurados: en formatos legibles para humanos, pero no para máquinas: Word, HTML
no tabulado, PDF. que pueden obtenerse mediante técnicas avanzadas como text mining u
otras.

A continuación, revisaremos las diferentes técnicas y tecnologías que conforman la integración

de datos.

3.1. Técnicas de integración de datos

Existen diferentes técnicas de integración de datos:

• Técnica push: consiste en la actualización continua y en línea del entorno destino mediante
aplicaciones de integración de datos que capturan los cambios en origen y los transmiten a
destino, donde son almacenados. En estas técnicas los datos son automáticamente enviados al
entorno remoto.
• Técnica pull: consiste en la provisión de datos mediante procesos batch en intervalos
prefijados (frecuentemente superior a varias horas).
• Propagación de datos: consiste en copiar datos de un lugar de origen a un entorno destino
local o remoto. Los datos pueden extraerse del origen mediante programas que generen un
fichero que debe ser transportado al destino, donde se utilizará como fichero de entrada para
cargar en la base de datos de destino. Una aproximación más eficiente es descargar sólo los
datos que han cambiado en origen respecto a la última propagación realizada, generando un
fichero de carga incremental que también será transportado al destino. Este tipo de procesos
trabajan habitualmente en línea y suelen usar una arquitectura de tipo push.
• CDC (Change Data Capture): se utilizan para capturar los cambios producidos por las
aplicaciones operacionales en las bases de datos de origen, de tal manera que pueden ser
almacenados y/o propagados a los entornos destino para que éstos mantengan la consistencia
con los entornos origen. A continuación trataremos las cuatro principales técnicas de change
data capture.

– Por aplicación: la aplicación de negocio es la que genera la actualización de datos en

origen, y se encarga de actualizar directamente los entornos destino, o almacenar
localmente los cambios en una tabla de paso (staging).
– Por timestamp: se puede emplear cuando los datos de origen incorporan un timestamp (por
 ejemplo a nivel de fila si el origen es una tabla relacional) de la última actualización de
ésta. El CDC se limitará a escanear los datos de origen para extraer los datos que posean
un timestamp posterior al de la última vez que se ejecutó el proceso de CDC: estos datos
son los que han cambiado desde la última captura de datos y, por tanto, son los que deben
actualizarse en los entornos destino.
– Por triggers: Los triggers o disparadores son acciones que se ejecutan cuando se
actualizan (por UPDATE, DELETE o INSERT) los datos de una determinada tabla sobre la
que están definidos. Estos triggers pueden utilizar los datos de una actualización en
sentencias SQL para generar cambios en otras tablas locales o remotas. Por lo tanto, una
forma de capturar cambios en los datos origen es crear triggers sobre las tablas de origen,
cuyas acciones modifiquen los datos de las tablas destino.
– Por captura de LOG: consiste en examinar constantemente el fichero de log de la base de
datos de origen en busca de cambios en las tablas que se deben monitorizar. Estos
programas basan su eficiencia en la lectura de los buffers de memoria de escritura en el
log, por lo que la captura de la información no afecta al rendimiento del gestor relacional
al no requerir acceso al disco que contiene el fichero de log.

• Consolidación de datos: consiste en capturar los cambios realizados en múltiples entornos

origen y propagarlos a un único entorno destino, donde se almacena una copia de todos estos
datos. Ejemplos son un data warehouse o un ODS, alimentado por varios entornos de
producción. Con esta técnica es difícil trabajar con tiempos de latencia bajos:

– Cuando no se requiere latencia baja, se suele utilizar la técnica pull mediante consultas
SQL.
– Cuando se requiere latencia baja, se suele utilizar la técnica push. En este caso, la
aplicación de integración de datos debe identificar los cambios producidos en origen para
transmitir sólo esos cambios, y no todo el conjunto de datos del origen. Para ello, se suele
emplear algún tipo de técnica de tipo CDC (change data capture).

• Federación de datos: proporciona a las aplicaciones una visión lógica virtual común de una
o más bases de datos. Esta técnica permite acceder a diferentes entornos origen de datos, que
pueden estar en diferentes gestores de bases de datos y máquinas, y crear una visión
integrada de los datos como si se encontrarán en la práctica en una base de datos única e
integrada. Cuando una aplicación de negocio lanza una consulta SQL contra esta vista
federada, el motor de federación de datos descompone la consulta en consultas individuales
para cada uno de los orígenes de datos físicos involucrados y la lanza contra cada uno de
ellos. Cuando ha recibido todos los datos de respuesta a las consultas, integra los resultados
parciales en un resultado único, realizando las sumarizaciones, agregaciones y/o
ordenaciones necesarias para resolver la consulta original y devuelve los datos a la
aplicación que lanzó la consulta original. Uno de los elementos clave del motor de
federación es un catálogo de datos común. Este catálogo contiene información de la
estructura de los datos, de su localización y, en ocasiones, sobre la demografía de los datos
(volumen de datos, cardinalidad de las claves, claves de clustering,etc.). Ello permite que
 se pueda optimizar la división de la consulta original al enviarla a los gestores de bases de
datos origen y se elija el camino de acceso global a los datos más eficiente.
• Técnicas híbridas: la técnica elegida en la práctica para la integración de datos dependerá
de los requisitos de negocio para la integración, pero también en gran medida de los
requisitos tecnológicos y de las probables restricciones presupuestarias. A la práctica se
suele emplear varias técnicas de integración constituyendo lo que se denomina una técnica
híbrida.

3.2. Tecnologías de integración de datos

Existen diferentes tecnologías de integración de datos basadas en las técnicas presentadas:

• ETL: permite extraer datos del entorno origen, transformarlos según nuestras necesidades de
negocio y cargar estos datos en los entornos destino. Los entornos origen y destino son
usualmente bases de datos y/o ficheros, pero en ocasiones también pueden ser colas de
mensajes de un determinado middleware, así como ficheros u otras fuentes estructuradas,
semiestructuradas o no estructuradas. Estas tecnologías están basadas en técnicas de
consolidación. Las herramientas de ETL en la práctica mueven o transportan datos entre
entornos origen y destino, pero también documentan cómo estos datos son transformados (si
lo son) almacenando esta información en un catálogo propio de metadatos; intercambian
estos metadatos con otras aplicaciones que puedan requerirlos y administran todas las
ejecuciones y procesos de la ETL: planificación del transporte de datos, logde errores, log
de cambios y estadísticas asociadas a los procesos de movimiento de datos. Las
herramientas ETL suelen tener una interfaz de usuario de tipo GUI y permiten diseñar,
administrar y controlar cada uno de los procesos del entorno ETL. Podemos encontrarlas de
distintos tipos:

– ETL de generación de código: constan de un entorno gráfico donde se diseñan y especifican

los datos de origen, sus transformaciones y los entornos destino. El resultado generado es
un programa de que permite realizar las transformaciones de datos. Aunque estos
programas simplifican el proceso ETL, incorporan pocas mejoras en cuanto al
establecimiento y automatización de todos los flujos de procesos necesarios para realizar
la ETL. Usualmente son los administradores de datos los encargados de distribuir y
administrar el código compilado, planificar y ejecutar los procesos en lotes, y realizar el
transporte de los datos.
– ETL basados en motor: permiten crear flujos de trabajo en tiempo de ejecución definidos
mediante herramientas gráficas. El entorno gráfico permite especificar el mapping de los
entornos de datos de origen y destino, las transformaciones de datos necesarias, el flujo de
procesos y los procesos por lotes necesarios. Toda esta información es almacenada en un
catálogo de metadatos. Tiene diferentes componentes que permiten extraer datos de
diferentes fuentes de origen, transformar los datos acordes a las necesidades de negocio y
 cargar dichos datos en las fuentes de destino. Además incluye componentes para gestionar
y administrar los procesos ETL.
– ETL integrado en la base de datos: algunos fabricantes incluyen capacidades ETL dentro
del motor de la base de datos (al igual que lo hacen con otro tipo de características, como
soporte OLAP y minería de datos). En general, presentan menos funcionalidades y
complejidad que los sistemas ETL presentados, y son una solución menos completa que los
ETL comerciales basados en motor o de generación de código.

• EII: el objetivo de la tecnología EII es permitir a las aplicaciones el acceso a datos

dispersos (desde un data mart hasta un fichero de texto o incluso un servicio web) de forma
federada.
• EDR: tiene el objetivo de detectar los cambios que suceden las fuentes de origen. Está
soportada por las técnicas de integración de datos de CDC (change data capture) y por la
técnica de propagación de datos.

3.3. Tipos de subsistemas ETL

Existen múltiples tipos de procesos ETL. Según la clasificación de Ralph Kimball existen
treinta y cuatro tipos clasificados en cuatro grandes grupos:

• Extracción: extraen la información de las fuentes de datos de origen.

• Limpieza y conformación: consiste en acciones que permiten validar y mejorar la calidad de
la información.
• Entrega: consiste en la preparación de la información para su posterior entrega.
• Gestión: aúna las tareas de administración de procesos ETL.

A continuación se detallan los tipos de procesos para cada uno de estos grupos.

Extracción

• Data profiling: consiste en la exploración de los datos para verificar su calidad y si cumplen
los estándares conforme a los requerimientos.
• Change Data Capture: detecta los cambios para refinar los procesos ETL y mejorar su
rendimiento.
• Sistema de extracción: permite la extracción de datos desde la fuente de origen a la fuente
destino.

Limpieza y conformación

• Data Cleansing: implementa los procesos de calidad de datos que permiten detectar
 incoherencias en los datos o potenciales mejoras en los mismos.
• Rastreo de eventos de errores: captura los errores derivados de los procesos ETL,
proporcionando información valiosa sobre la calidad de datos y permitiendo la mejora de
los mismos.
• Creación de dimensiones de auditoría: permite crear metadatos asociados a cada tabla. Estos
metadatos permiten, entre otros, validar la evolución de la calidad de los datos.
• Deduplicación: eliminar información redundante de tablas importantes como cliente o
producto. Requiere cruzar múltiples tablas en múltiples sistemas de información para
detectar el patrón que permite identificar cuando una fila está duplicada.
• Conformación: permite identificar elementos equivalentes que permiten compartir
información entre tablas relacionadas.

Entrega

• Slowly Changing Dimension (SCD): permite crear atributos de variabilidad lenta a lo largo
del tiempo.
• Surrogate Key: permite crear claves subrogadas independientes para cada tabla.
• Jerarquías: permite hacer inserciones en estructuras jerárquicas de tablas.
• Dimensiones especiales: permite crear dimensiones especiales como junk, mini o de
etiquetas.
• Tablas de hecho: permite crear tablas de hecho.
• Pipeline de claves subrogadas: permite remplazar las claves operacionales por las claves
subrogadas.
• Constructor de tablas multivaluadas: permite construir tablas puente para soportar las
relaciones N:M.
• Gestión para información tardía: permite aplicar modificaciones a los procesos en caso que
los datos tarden en llegar.
• Gerente de dimensión: autoridad central que permite crear y publicar dimensiones
conformadas.
• Aprovisionador de tablas de hecho: permite la gestión de las tablas de hecho.
• Creador de agregadas: permite gestionar datos agregados.
• Creador de cubos OLAP: permite alimentar de datos a esquemas OLAP desde esquemas
relacionales.
• Propagador de datos: permite preparar información conformada para ser entregada.

Gestión

• Programador de trabajos: permite gestionar procesos ETL pertenecientes a la categoría de

trabajos.
• Sistema de backup: permite realizar copias de respaldo de los procesos ETL.
• Reinicio y recuperación: permite reiniciar procesos ETL en el caso de error.
• Control de versiones: permite hacer control de versiones de un proyecto ETL y de sus
metadatos asociados.
• Migración de versiones: permite pasar proyectos en fase test a producción mediante
versionado.
• Monitorización de workflow: permite monitorizar flujos de trabajo. Dado que un proceso de
ETL es un flujo de trabajo, es importante monitorizarlos para medir su rendimiento.
• Ordenación: permite calibrar los procesos ETL para mejorar su rendimiento.
• Linealidad y dependencia: permite realizar la trazabilidad del dato, identificando elementos
dependientes y las transformaciones en las que participa o han participado los datos.
• Escalado de problemas: suporta la gestión de incidencias.
• Paralelismo / clustering: permite el uso de procesos en un entorno de computación
distribuida (paralelo, grid computing y clustering)para mejorar el rendimiento.
• Seguridad: gestiona el acceso a ETL y metadatos.
• Compliance Manager: permite soportar la legislación vigente respecto la custodia y
responsabilidad de datos que debe aplicarse a la organización.
• Repositorio de metadatos: almacena los metadatos de los procesos ETL, de los datos de
negocio y de los aspectos técnicos.

4. Procesamiento Analítico en Línea(OLAP)

OLAP forma parte de lo que se conoce como sistemas analíticos que permiten responder
preguntas de tipo ¿por qué paso? Estos sistemas pueden encontrarse tanto integrados en suites
de Business Intelligence como de forma independiente.

Es necesario, antes de continuar, presentar una definición formal de OLAP:

Se entiende por OLAP, o procesamiento analítico en línea, al método para organizar y

consultar datos sobre una estructura multidimensional. A diferencia de las bases de datos
relacionales, todas las potenciales consultas están calculadas de antemano, lo que proporciona
una mayor agilidad y flexibilidad al usuario de negocio.

Una herramienta OLAP está formada por un motor y un visor. El motor es, en realidad, justo el
concepto que acabamos de definir. El visor OLAP es una interfaz que permite consultar,
manipular, reordenar y filtrar datos existentes en una estructura OLAP mediante una la interfaz
gráfica de usuario que dispone de funciones de consulta MDX2 y otras.

Las estructuras OLAP permiten resolver preguntas que serían sumamente complejas de
resolver mediante consultas SQL.

Imaginemos que queremos responder a la siguiente pregunta: ¿cuál es el margen de beneficios

de la venta de bicicletas para febrero de 2007?

Si tenemos un cubo, como el de la imagen anterior, formado por el tiempo, los productos y las
medidas, la respuesta es la intersección entre los diferentes elementos. Cabe observar que una
estructura de esta forma permite consultas mucho más completas como por ejemplo comparar
el margen de beneficios de febrero y mayo, entre diferentes productos...

Además, mediante el visor OLAP se proporcionan libertad a los usuarios finales para realizar
dichas consultas de forma independiente al departamento de IT.

4.1. Tipos de OLAP

Existen diferentes tipos de OLAP, en función a la forma en que se almacenan los datos.
Podemos destacar los siguientes:

• MOLAP (Multidimensional OLAP): es la forma clásica de OLAP y frecuentemente es

referida con dicho acrónimo. MOLAP utiliza estructuras de bases de datos generalmente
optimizadas para la recuperación de los mismos. Lo que se conoce como bases de datos
 multidimensionales (o más coloquialmente cubos). En definitiva, se crea un fichero que
contiene todas las posibles consultas pre-calculadas. A diferencia de las bases de datos
relacionales, estas formas de almacenaje están optimizadas para la velocidad de cálculo.
También se optimizan a menudo para la recuperación a lo largo de patrones jerárquicos de
acceso. Las dimensiones de cada cubo son típicamente atributos tales como período,
localización, producto o código de la cuenta. La forma en la que cada dimensión será
agregada se define por adelantado.
• ROLAP (Relational OLAP): utiliza el modelo relacional, almacenando las dimensiones
como tablas relacionales y utilizando tablas adicionales para guardar la información
agregada. Suele trabajar directamente con las bases de datos relacionales, que almacenan los
datos base.
• HOLAP (Hybrid OLAP): No hay acuerdo claro en la industria en cuanto a qué constituye el
OLAP híbrido, exceptuando el hecho que es una base de datos en la que los datos se dividen
almacenaje relacional y multidimensional. Por ejemplo, para algunos vendedores, HOLAP
constituye en utilizar las tablas relacionales para guardar las cantidades más grandes de
datos detallados, y utiliza el almacenaje multidimensional para algunos aspectos de
cantidades más pequeñas de datos menos detallados o agregados.
• DOLAP (Desktop OLAP): es un caso particular de OLAP ya que está orientado a equipos de
escritorio. Consiste en obtener la información necesaria desde la base de datos relacional y
guardarla en el escritorio. Las consultas y análisis son realizados contra los datos guardados
en el escritorio.
• In-memory OLAP: es un enfoque por el que muchos nuevos fabricantes están optando.
Consiste en una estructura dimensional que se genera sólo a nivel de memoria y se guarda el
dato original en algún formato que potencia su despliegue de esta forma (por ejemplo,
comprimido o mediante una base de datos de lógica asociativa). En este último punto es
dónde cada fabricante pone su énfasis.

Cada tipo tiene ciertas ventajas e inconvenientes, aunque hay desacuerdo sobre las ventajas
entre los diferentes proveedores se suelen cumplir las siguientes máximas:

• MOLAP funciona mejor en sistemas con un volumen bajo/medio de datos. Es más rápido en
calcular agregaciones y retornar respuestas y necesita menos espacio de almacenaje.
Últimamente, in-memory OLAP está apuntalándose como una opción muy válida al MOLAP.
• ROLAP se considera más escalable. Sin embargo, el pre-proceso necesario en las consultas
es difícil de implementar eficientemente en grandes volúmenes de datos. De otro modo, el
funcionamiento de las consultas puede no ser óptimo.
• HOLAP es una solución de compromiso entre MOLAP y ROLAP, permite preprocesar
rápidamente los datos y escalar adecuadamente.

Todos los tipos son, sin embargo, propensos a la explosión de la base de datos. Éste es un
fenómeno causado por la gran cantidad de espacio de almacenaje que requieren las bases de
datos OLAP al resolver consultas con ciertas, pero frecuentes, condiciones: alto número de
dimensiones, resultados calculados de antemano y datos multidimensionales escasos.

La dificultad en la implementación OLAP deviene en la formación de las consultas, en elegir

los datos base y en desarrollar el esquema adecuado. Como resultado, la mayoría de los
productos modernos vienen con bibliotecas que contienen gran cantidad de consultas pre-
configuradas. Otra dificultad en los cubos OLAP puede ser la calidad de datos, para que la
explotación tenga sentido se necesita que el conjunto de datos sea completo.

4.2. Elementos OLAP

OLAP permite el análisis multidimensional. Ello significa que la información está estructurada
en ejes (puntos de vista de análisis) y celdas (valores que se están analizando).

En el contexto de OLAP existen diferentes elementos comunes a las diferentes tipologías

OLAP. Lo que difiere es su creación en los distintos sistemas (en MOLAP se precalculan los
datos, en ROLAP no y en in-memory OLAP se generan al iniciar el sistema):

• Esquema: un esquema es una colección de cubos, dimensiones, tablas de hecho y roles.

• Cubo: es una colección de dimensiones asociadas a una tabla de hecho. Un cubo virtual
permite cruzar la información entre tablas de hecho a partir de sus dimensiones comunes.
• Tabla de hecho, dimensión y métrica.
• Jerarquía: es un conjunto de miembros organizados en niveles. A nivel de base de datos se
puede entender como una ordenación de los atributos de una dimensión.
• Nivel: es un grupo de miembros en una jerarquía que tienen los mismos atributos y nivel de
profundidad en la jerarquía.
• Miembro: es un punto en la dimensión de un cubo que pertenece a un determinado nivel de
una jerarquía. Las métricas (medidas) en OLAP se consideran un tipo especial de miembro
que pertenece a su propio tipo de dimensión. Un miembro puede tener propiedades
asociadas.
• Roles: permisos asociados a un grupo de usuarios.
• MDX: es el lenguaje de consulta de estructuras OLAP, fue creado en 1997 por Microsoft y si
bien no es un lenguaje estándar la gran mayoría de fabricantes de herramientas OLAP lo han
adoptado como estándar de hecho.

4.3. Características de los sistemas OLAP

La definición de OLAP presentada anteriormente se basa en las 12 leyes que acuñó Edgar F.
Codd en 1993. Estas reglas son las que, en mayor o menor medida, intentan cumplir los
fabricantes de software:

• Vista conceptual multidimensional: se trabaja a partir de métricas de negocio y sus

dimensiones.
• Transparencia: el sistema OLAP debe formar parte de un sistema abierto que soporta fuentes
de datos heterogéneas (lo que llamamos actualmente arquitectura orientada a servicios).
• Accesibilidad: se debe presentar el servicio OLAP al usuario con un único esquema lógico
de datos (lo que en definitiva, nos indica que debe presentarse respecto una capa de
abstracción directa con el modelo de negocio).
• Rendimiento de informes consistente: el rendimiento de los informes no debería degradarse
cuando el número de dimensiones del modelo se incrementa.
• Arquitectura cliente/servidor: basado en sistemas modulares y abiertos que permitan la
interacción y la colaboración.
• Dimensionalidad Genérica: capacidad de crear todo tipo de dimensiones y con
funcionalidades aplicables de una dimensión a otra.
• Dynamic sparse-matrix handling: la manipulación de datos en los sistemas OLAP debe
poder diferenciar valores vacíos de valores nulos y debe ser capaz de ignorar las celdas sin
datos.
• Debe permitir soporte multiusuario.
• Operaciones cruzadas entre dimensiones sin restricciones: todas las dimensiones son creadas
igual y las operaciones entre dimensiones no deben restringir las relaciones entre celdas.
• Manipulación de datos intuitiva: Dado que los usuarios a los que se destinan este tipo de
sistemas son frecuentemente analistas y altos ejecutivos, la interacción debe considerarse
desde el prisma de la máxima usabilidad de los usuarios.
• Reporting Flexible: Los usuarios deben ser capaces de manipular los resultados que se
ajusten a sus necesidades conformando informes. Además, cambios en el modelo de datos
deben reflejarse automáticamente en esos informes.
• Niveles de dimensiones y de agregación ilimitados: No deben existir restricciones para
construir cubos OLAP con dimensiones y con niveles de agregación ilimitados.
 El desarrollo

1. Estudio preliminar

El primer paso en todo proyecto, y esto se aplica también a aquellos vinculados a las
tecnologías de la información, es determinar la viabilidad y la rentabilidad del mismo. En
nuestro caso particular, es necesario hacer un análisis del periodo de retorno de inversión, de
la tasa interna de rentabilidad, del descuento de flujos financieros y del retorno de la
inversión.

Primero, se debe recopilar la información que nos proporcionan en el enunciado.1 La

información proporcionada es la siguiente:

• Se considera la evolución de proyecto durante cinco años.

• El primer año el sistema tendrá 25 usuarios. El número de usuarios se incrementará
progresivamente de 10 en 10, hasta llegar a los 65 usuarios en el quinto año.
• La inversión inicial del proyecto es 76.000 euros.
• Los costes de los siguientes años incluyen mantenimiento, evolución y nuevas licencias, y se
mantienen constantes ascendiendo a 16.700 euros por año.
• Los beneficios estimados para el primer año son 20.000 euros, 25.000 para el segundo y
 35.000 para los siguientes años.
• La tasa de descuento es del 10 % a lo largo de los años considerados.

Los datos proporcionados no permiten entrar en un detalle pormenorizado de las líneas que
componen costes y beneficios, si bien en un caso real para llegar a estas cantidades se habrán
determinado las principales magnitudes, como, por ejemplo, el coste de hardware, software,
implementación, mantenimiento o ampliación del proyecto.

El enunciado proporciona una información que puede llevar a diferentes interpretaciones y,

por lo tanto, generar diferentes escenarios de análisis.

En el escenario planteado se considera que la inversión inicial, antes del primer año, y que los
beneficios que proporciona el proyecto se refieren a beneficio bruto.2

Esta información se resume en la siguiente tabla y nos permite calcular el flujo de caja durante
los primeros cinco años del proyecto.

Consecuentemente, podemos calcular las métricas que nos permitirán tomar una decisión sobre
el proyecto:

¿Cómo hemos realizado los cálculos?

• Para calcular el flujo de caja del proyecto en un determinado año t, que llamaremos Ft, se
realiza la diferencia entre beneficios y costes (o en el caso del primer año, la inversión
inicial). De esta forma, el flujo de caja del año inicial es:
• Para calcular el VAN en el período t, es necesario utilizar la siguiente fórmula:

donde asumimos que TIRi es constante e igual a la tasa de descuento, donde Fi es el flujo de
caja.

• De esta forma, para calcular el VAN para el primer año, simplemente aplicamos la fórmula:

• El cálculo del TIR es más complejo. Supone resolver la ecuación resultante de igualar el
VAN del periodo t a cero.

La ecuación en el año 1 no tiene sentido por definición. El TIR se calcula para el segundo
año. Para nuestro caso particular en el año 2, la ecuación resultante es:

La ecuación anterior es resoluble por métodos algebraicos, proporcionando el valor:

Y sustituyendo nos proporciona el valor: -73.7 %. Como es posible deducir a medida que
hay más años, la ecuación polinómica a resolver resulta más compleja. Por ejemplo, para el
año 3 deberíamos resolver una ecuación de tercer grado (para la que hay aún fórmula). De
forma que se usa software como Excel para resolver, de forma automática, este tipo de
cálculo usando una función.6
• Para el cálculo de ROI, debemos aplicar la siguiente fórmula:

Para el año 1, por lo tanto, el ROI es:

Para el año 2, el ROI es:

• Los valores para los siguientes años se calculan de forma equivalente.

Consecuentemente, podemos evaluar los resultados que nos permitirán tomar una decisión
sobre el proyecto:

• El cálculo del TIR nos indica que no se superará el mínimo de rentabilidad exigido por la
organización (el 10 %), condición necesaria para dar viabilidad al proyecto. De forma que,
tras el período de cinco años, el proyecto no es viable.7
• El cálculo del TIR también nos indica una serie de rasgos importantes: (1) con los beneficios
identificados a partir del quinto año se llegará a un valor positivo en rentabilidad (3 %), por
lo que si la rentabilidad exigida fuera del 3 %, el proyecto se consideraría viable; (2) en el
caso de considerar una rentabilidad del 3 %, será necesario a lo largo del proyecto
identificar otros beneficios potenciales que puedan derivarse del almacén de datos y que
permitan conseguir antes la rentabilidad exigida y mayores beneficios; y (3) en este
escenario, será necesaria una gestión excelente del proyecto, pues cualquier impacto en
tiempo, recursos y dinero puede incidir negativamente sobre la rentabilidad.
• El cálculo del VAN, como es posible imaginar, está vinculado con el cálculo del TIR. Si uno
nos indica el periodo en el que llegamos a la rentabilidad exigida, el otro indica la cantidad
de ganancias. En nuestro caso particular, en el quinto año, la inversión producirá ganancias
por debajo de la rentabilidad exigida (10 %) y, por lo tanto, es natural que el VAN sea
negativo en dicho año.
• Por otro lado, por las hipótesis de esta actividad, sabemos que a partir del segundo año se
genera beneficio neto positivo. Pero no es hasta el quinto año donde realmente se genera un
ROI positivo para el proyecto. Esto nos da una idea de que este tipo de proyectos son a largo
plazo y, por ello, es necesario identificar áreas de alto impacto para asegurar la continuidad
 de los mismos a largo plazo.

Teniendo en cuenta estos resultados, los comentarios iniciales para la gerencia es que el
proyecto no consigue la rentabilidad esperada a los cinco años y no es viable. En el caso de
considerar una tasa de retorno del 3 %, sería viable, pero con un retorno de la inversión muy
limitado. En este sentido, las recomendaciones más prudentes son:

• Revisar el escenario actual para identificar otros posibles beneficios, así como potenciales
reducciones de costes para reducir los riesgos en la viabilidad y la rentabilidad.
• En el caso de que sea posible, conseguir otros escenarios para la implementación del
proyecto (en los que cambia la solución, el hardware, el proveedor y los costes) para poder
tener otras opciones a comparar.
• En el caso de que no sea posible tener otros escenarios y deber desarrollar el proyecto con
un escenario con tasa 3 %, cabe iniciar el proyecto con personal experto en la gestión de
proyectos de implementación de almacenes de datos para evitar impactos en la rentabilidad y
viabilidad del proyecto.

2. Entorno de trabajo

El presente caso se ha implementado sobre una máquina con las siguientes características:

• Memoria RAM: 2GB

• Sistema operativo: Windows 7
• Espacio: 8GB
• Base de datos: Oracle XE 11g
• Herramienta ETL: Microsoft SQL Server Integration Services 2012
• Herramienta MOLAP: Microsoft SQL Server Analysis Services 2012
• Herramienta de diseño de ETLs y Analysis Services: Microsoft Visual Studio 2012

Se puede consultar la configuración de la máquina utilizada y obtener información sobre los

programas instalados en la wiki del libro: http://goo.gl/aMUxEe
3. Diseño del data warehouse

Tal y como se indica en el enunciado de la actividad, el diseño de la factoría de información

en esta actividad se centrará solo en el área de hospitalización para facilitar la creación de
una solución de inicio a fin.

3.1. Análisis de requerimientos

El análisis de requerimientos se basa en identificar las necesidades específicas que tiene una
organización particular con respecto al análisis de la información. La información recopilada
en esta fase permite definir a posteriori los procesos de negocio a analizar y las perspectivas
de negocio sobre las que interesa analizar el rendimiento de la organización.

Normalmente, en esta fase, se debe ser previsor y pensar más allá de las necesidades actuales
para poder cubrir las futuras. Por ejemplo, si los usuarios han mostrado interés por un análisis
mensual, pero hay información más detallada, es necesario identificar si la solución de
factoría de información puede beneficiarse a futuro de información más desglosada o es
suficiente con ciertos niveles agregados de información.

Es necesario comentar que, aunque para esta actividad el análisis de requisitos se fundamenta
en el enunciado proporcionado y se complementa con las fuentes de datos, esta fase se debe
realizar entrevistando al cliente, analizando las necesidades de información de la organización
que se cubren actualmente y las que debe cubrir el proyecto a futuro. Por lo que, como
consultores del proyecto, es conveniente hacer un diagnóstico y conceptualización adecuada
del mismo. Es decir, identificar claramente los objetivos y el contenido del proyecto.

En este caso, el objetivo es diseñar un almacén de datos que permita mejorar la gestión del
área de hospitalización. En el caso del contenido, el proyecto incluye la creación e
implementación de un modelo relacional, el diseño e implementación de procesos ETL, el
diseño e implementación del modelo OLAP y, por último, el diseño de las consultas mínimas
establecidas en el enunciado.

En un proyecto real, es necesario tener en cuenta criterios de negocio y gestión de proyectos

para, por un lado, generar valor en la organización y, por el otro, lograr un proyecto de éxito.

En nuestro caso particular del área de hospitalización de un hospital general básico, es de

primordial interés para el centro gestionar de forma eficiente el comportamiento y el uso de
esta área.

Esto se traduce en que, dentro de las necesidades de información por parte de la dirección
clínica y el propio centro, podemos identificar las siguientes:

1) Conocer la evolución del uso del área de hospitalización, que consiste en conocer el uso
que han realizado los ciudadanos de los servicios de hospitalización a lo largo del tiempo:
cuántos pacientes ha tenido el área, cuál ha sido su episodio, qué tipo de demanda
quirúrgica hay asociada a la hospitalización, cuál ha sido la evolución del paciente en caso
de reingreso, etcétera.
2) Esta evolución debe poderse analizar desde diferentes puntos de vista. Para cada paciente,
en el momento de alta en el área de hospitalización se debe registrar la siguiente
información, la cual nos proporciona diferentes perspectivas de negocio para el análisis:
• Fecha de entrada del paciente.
• Servicio que prescribe la inclusión en RDQ.8
• Facultativo.
• Prioridad clínica del paciente.
• Diagnóstico de inclusión.
• Procedimiento quirúrgico.
• Situación del paciente.
• Motivo de salida.
• Fecha de salida.

Si se tiene en cuenta toda esta información, el sistema resultante podrá responder a múltiples
preguntas que puedan generar la dirección clínica y el propio centro.

De forma específica, se pide que el sistema debe, como mínimo, ser capaz de dar respuesta a
las siguientes preguntas:

• Evolución de las hospitalizaciones.

• Evolución de las hospitalizaciones por tipo de alta.
 • Evolución de las hospitalizaciones por meses y años.
• Evolución de las hospitalizaciones por servicio del hospital.

En siguientes fases de esta actividad, será necesario definir otros aspectos relevantes para este
tipo de proyectos como, por ejemplo, la periodicidad de los datos (para determinar la
necesidad de carga y las ventanas de carga existentes).

En este sentido, en los proyectos de diseño de factoría de información corporativa existe una
fase inicial del proyecto en la que se realiza una carga inicial, pero a posteriori hay cargas
incrementales que reducen y optimizan el tiempo de carga necesario.

3.2. Análisis de fuentes de datos

En los proyectos de almacenes de datos resulta muy relevante analizar las fuentes de datos. De
su análisis puede desprenderse información clave para el éxito y la evolución de proyecto, así
como la identificación de riesgos vinculados. Por ejemplo:

• Identificar si existe un gobierno de datos y su nivel dentro de la organización. En el caso de

no existir una política de gestión del dato, este análisis nos debe permitir identificar, como
mínimo, la calidad del dato y los procesos en los que participa, así como otros aspectos
vinculantes como la propiedad o la periodicidad.
• Descubrir, a través de la estructura de las fuentes, que existen registros desconocidos por los
usuarios de negocio que puede aportar valor para comprender el rendimiento del área que
deben ser comunicados a los usuarios para su evaluación.

Puesto que en nuestro caso particular no tenemos acceso a las partes interesadas del proyecto,
usaremos el sentido común para el análisis de fuentes de datos.

Para esta actividad contamos con solo una fuente de datos, que es un fichero Excel
denominado BI_UOC_Datos_Hospitalizacionv1.

El objetivo de analizar este fichero es:

• Identificar los campos de datos contenidos.

• Identificar los campos de datos no relevantes y que se pueden eliminar.
• Identificar el tipo de campo y si son opcionales, por lo que aceptan resultados nulos.

Este fichero puede descargarse desde la wiki del libro9. Los principales aspectos a destacar
de esta fuente de información son:

• El fichero tiene tres hojas: datos, descripción tabla y ficha.

• La hoja «datos» contiene los registros de la actividad del área de hospitalización de
ejemplo.
• La hoja «descripción tabla» contiene la descripción del significado de cada una de las
columnas de los registros.
• La hoja «ficha» proporciona información sobre el conjunto de datos de esta actividad, en
particular del periodo de tiempo: de enero de 2012 a enero de 2013.
• La fuente de datos contiene 14.326 registros a analizar. Cada registro está formado por 40
campos, si bien no todos son obligatorios, hecho que viene determinado por el tipo de
paciente y su historial.
• La información de varios de los atributos está codificada de forma numérica.
• Parte de los campos están en catalán, por lo que debemos hacer una correspondencia al
castellano.
• Los campos que incluye la fuente de datos son los siguientes (y es posible encontrar esta
información en la hoja «descripción tabla»):
Además, tenemos la tabla de altas que contiene información sobre los tipos de alta:
Una vez sabemos qué información contiene nuestra fuente de datos, es necesario discernir el
tipo de dato para cada campo y cuántos niveles de información contiene. Los niveles de
información definen cuánta información jerarquizada incluye un campo. Ello nos va a permitir,
en un futuro, definir las jerarquías de cada dimensión. Por otro lado, las fuentes de origen de
datos de una organización contienen información que no tiene por qué reflejarse en el almacén
de datos. La información no relevante es diferente en función de la fuente de origen. Por
ejemplo, los sistemas de información como ERP o CRM contienen atributos en la base de
datos que solo tienen valor para la gestión de dicha aplicación, pero no tienen valor de
negocio. Por eso, se deben omitir. Por tanto, en nuestro caso particular, debemos revisar el
significado de cada campo del fichero de datos facilitado para determinar su relevancia
respecto al sistema a desarrollar.

El resultado del análisis de los campos anteriores se recoge en la siguiente tabla, que presenta
el resultado del análisis realizado en cada uno de los campos en términos de tipo de datos y
nivel de información contenida. Esta última columna presenta el nivel de información, o bien
refleja si debe omitir el campo.
Este análisis nos permite identificar que, de los 39 campos que tiene cada registro, hay 12 que
se pueden omitir. Estos campos son valores auxiliares que permiten usar el fichero Excel para
crear consultas de negocio comparativas. El modelo MOLAP que crearemos en posteriores
fases de esta actividad permite recrear este tipo de análisis comparativos.

De los 27 campos restantes, existen 8 que pueden estar vacíos o ser opcionales, puesto que,
para algunas hospitalizaciones, el paciente no habrá pasado por todas las unidades y, por lo
tanto, no tendrá asociada una estadía. En este sentido, en el momento de carga de datos,
podemos completar el campo con el valor nulo correspondiente.
3.3. Análisis funcional

En el momento de considerar los requisitos funcionales, es necesario tener en cuenta que cada
requisito tendrá una prioridad asociada y podrá ser exigible o deseable.

En el contexto de esta actividad, los requerimientos exigibles son aquellos que demanda el
enunciado y los deseables son aquellos que complementan la actividad.

Por otro lado, en términos de la escala de prioridades, asignamos una prioridad de 1 a 4,

siendo 1 completamente prioritario para la actividad y 4 no prioritario para la actividad.

A continuación, se describen los requerimientos funcionales para el diseño de una factoría de

información para el área de hospitalización bajo las consideraciones del enunciado:

Cabe comentar que, en un caso genérico, podemos encontrar otros requerimientos funcionales
como:

• Creación de procesos de calidad de datos.

• Creación de data marts (si se analizan otras áreas).
• Automatizar cada proceso de carga de data marts (en función de sus necesidades).
• Creación de procesos de cargas totales e incrementales.
• Se creará un soporte a los metadatos de gestión del almacén de datos, así como de los
procesos ETL.

Asimismo, dado que estos sistemas frecuentemente forman parte de la implementación de un

sistema de inteligencia de negocio, la lista de requerimientos funcionales sería mucho mayor.

En términos de la arquitectura funcional, tenemos los siguientes elementos:

• Las fuentes de datos están compuestas por un único fichero Excel.

• La arquitectura de la factoría de información puede estar formada por varios elementos que
estarán alojados en la misma máquina:
– Staging area10 (opcional): en el caso de tener múltiples ficheros, sería conveniente
consolidarlos en una estructura de carga intermedia. En nuestro caso particular, sería
creada en la misma base de datos. En todo caso, teniendo en cuenta el modelo simplificado
 del que partimos, se omite este paso.
– Data mart. Hospitalización: al centrarnos en una única área, es más correcto considerar
que se está creando un data marten lugar de un almacén de datos corporativo.
– MOLAP: a partir de la información, en el data mart de hospitalización, se creará cubo
multidimensional.

El siguiente gráfico resume los elementos de la arquitectura para esta actividad.

4. Diseño del modelo conceptual, lógicoy físico

4.1. Diseño conceptual

A partir del análisis de requerimientos y del análisis de fuentes de datos, se ha identificado

una tabla de hecho con 2 atributos, 9 métricas y 12 dimensiones.

La tabla de hecho corresponde al proceso de hospitalización.

La tabla de hecho tiene los siguientes atributos y métricas:

• Atributos:
– Episodio: identificación episodio.
– NHC: número de historia clínica.

• Métricas:
– d_hosp: días hospitalizado.
– est_ReaPQ: estadía en servicios especiales de reanimación (en milisegundos).
– est_sep: estadía en servicios especiales (en milisegundos).
– est_UCI: estadía en servicios especiales de Unidades de Cuidados Intensivos (en
milisegundos).
– est_UCI_CCA: estadía en servicios especiales de Unidades de Cuidados Intensivos CCA
(en milisegundos).
– est_uni_coro: estadía en servicios especiales de enfermedades coronarias (en
milisegundos).
– num_unid: número de unidades por las que ha pasado un paciente.
– p_GRD: peso GDR que permite medir la complejidad.
– t_hosp: tiempo de hospitalización.

Las dimensiones corresponden a las perspectivas de negocio sobre las que queremos analizar
el proceso de hospitalización:
4.2. Diseño lógico

Para cada dimensión, se han determinado sus atributos, y para las tablas de hechos, las
principales métricas. De nuevo, se debe tener en cuenta la consideración anterior que detalla
las dimensiones de cada tabla de hecho.

Las dimensiones anteriores tienen los siguientes atributos:

4.3. Diseño físico

En el momento de hacer el diseño físico, debemos tener en cuenta diversos aspectos:

• Tipo de base de datos con el que trabajamos, puesto que cada una de ellas tiene su
particularidad.
• El diseño físico debe estar orientado a generar un buen rendimiento en el procesamiento de
consultas.
• Se debe definir también los procesos de administración futuros del data warehouse.
• El diseño físico inicial deberá revisarse, de forma periódica, para validar que continúa
dando respuesta a las necesidades del cliente.
Una vez determinados qué hechos, dimensiones, métricas y atributos existen, podemos
determinar también las claves foráneas que debe incluir el modelo físico. En este paso, es
necesario tener en cuenta el tamaño adecuado de los atributos (por ejemplo, qué longitud tiene
una cadena). También es relevante acordarse de crear las pertinentes claves primarias, claves
foráneas y disparadores (por ejemplo, para actualizar de forma automática las claves
primarias).

Para la tabla de hecho de hospitalización tendremos:

Un detalle importante es que nuestra tabla de hechos tiene cinco referencias temporales. En
lugar de crear cinco dimensiones temporales diferentes, es mucho más lógico crear una única
dimensión temporal a nivel físico y que la tabla de hechos tenga cinco claves foráneas que
apuntan a dicha dimensión, puesto que todas las dimensiones tienen el mismo nivel de
profundidad. A esta única dimensión temporal la llamaremos d_fecha.

Otro detalle importante es que la dimensión d_t_adm y d_t_adm_posterior son la misma

dimensión, por lo que podemos hacer el mismo juego anterior. Estos dos cambios simplifican
el modelo final con el que trabajaremos, al tener menos dimensiones, y simplificará también
los procesos de carga de dimensiones.

Tras esta reflexión, ha llegado el momento de pasar al diseño físico mediante Oracle XE. En
la entrada titulada «Implementación de las tablas del data warehouse en la base de datos» de
la wiki del libro,11 se encontrará el detalle de cómo hacerlo. En la wiki también se encontrará
el script de creación de la base de datos.12

Dichos recursos web pueden accederse mediante los siguientes códigos QR:
Después de crear las distintas tablas en la base de datos, obtendremos el siguiente esquema:

Así, tenemos una tabla de hecho y 8 tablas de dimensiones. Como ya hemos comentado, las 8
dimensiones en realidad representan 13 dimensiones (como podemos validar con las
relaciones entre la tabla de hecho y las dimensiones).
5. Metadatos

En cada fase del diseño de una factoría de información corporativa, debemos tener en cuenta
los metadatos necesarios y asociados. Aunque trabajamos con un ejemplo limitado, podemos
reflexionar sobre los metadatos a considerar. En cuanto al diseño del almacén de datos, es
necesario tener en cuenta los siguientes metadatos:

• Sobre la factoría de información:

– Arquitectura de la factoría de información
– Tipo de tablas de hecho en el almacén de datos
– Tipos de dimensiones en el almacén de datos
– Información sobre la base de datos
• Sobre las tablas:
– Nombre, atributos y rol
• Sobre las columnas:
– Nombre, tipo de dato, longitud, reglas de edición, definición

Parte de esta información está presente en este documento, y también está accesible a través
del sistema gestor del almacén de datos. Frecuentemente, se incluye un gestor de metadatos
para gestionar de forma correcta, y en único punto, este tipo de información y favorecer
posteriores desarrollos.

Un tipo de metadato más vinculado con el ciclo de vida del dato es cuando es creado y
cuando, de ser necesario, es modificado. Aunque no lo hemos contemplado en nuestra
solución, por su limitación de alcance, cada tabla puede incluir un par de campos para
gestionar este tipo de información.

5.1. Optimización de la factoría de información

Este ejemplo es pequeño, por lo que parte de lo que vamos a comentar en esta sección es
opcional. La optimización de la factoría de información es un proceso continuo; es necesario
tener en cuenta:

• La previsión de crecimiento de datos

• La previsión del tipo de consultas que se realizarán
Con este tipo de información, se implementarían:

• Propuesta de tablespace para las tablas, vistas e índices del datawarehouse.

• Índices extras para mejorar las consultas.
• Vistas materializadas.

Después de la carga de datos, discutiremos sobre el tamaño actual del almacén y sus
necesidades futuras.

Una vez que el data warehouse está diseñado e implementado en la base de datos, el siguiente
paso es la creación de los procesos de carga de datos en el mismo, tal y como se ve en la
siguiente sección.

6. Carga de datos

Una vez tenemos una propuesta de diseño del almacén de datos y ha sido implementada en la
base de datos con la que trabajamos, es el momento de centrarnos en los procesos ETL. Como
ya sabemos, estos procesos consisten en la extracción, transformación y carga de los datos. En
definitiva, lo que se persigue es estructurar y acomodar los datos de las fuentes de origen en el
almacén de datos.

En nuestro caso particular tenemos solo una fuente de origen, un fichero Excel, y una fuente de
destino, Oracle, la base de datos donde se aloja nuestro almacén de datos.

6.1. Identificación de los procesos ETL necesarios

Los procesos ETL deben conceptualizarse como manipulaciones de flujos de datos. Estos
procesos deben diseñarse teniendo en cuenta diversos factores: (1) cómo debe cargarse de
forma lógica la información, es decir, qué debe cargarse primero y qué después, (2) la ventana
de tiempo disponible, hecho que puede condicionar lo que debemos cargar, y (3) tipo de
carga: inicial o incremental.
En nuestro caso, está claro que esta es una carga inicial, por lo que nuestros procesos no se
diseñarán con el objetivo de repetirse periódicamente. También es cierto que desconocemos la
ventana de tiempo disponible (y no es una condición para esta actividad), pero en el contexto
de producción este es un factor muy relevante. Un diseño incorrecto de los procesos ETL
puede significar que la información no está disponible en el almacén de datos y, por lo tanto,
que consecuentemente no está disponible para usuarios, procesos y aplicaciones que se
apalancan sobre esta información de calidad.

El primer paso en la creación de los procesos ETL es comprender qué procesos son
necesarios y en qué orden deben realizarse. En general, el criterio de los procesos ETL sigue
las siguientes pautas:

• Se identifica si los datos se deben cargar en un área intermedia. En nuestro caso, no es

necesario.
• En el caso de la carga de las dimensiones, podemos diferenciar dos tipos de situaciones:
– Dimensiones con valores fijos ya conocidos (estáticas), presentes en el Excel en la hoja
descripción tabla, y que no van a cambiar en el tiempo. Estas dimensiones son: sexo, tipo
de episodio, tipo de admisión y tipo de alta. Estos valores son reducidos y se insertarán
directamente en la base de datos.
– Dimensiones con valores no fijos que se extraerán, transformaran y cargarán mediante
procesos ETL (dinámicas). Estas dimensiones son: fecha, diagnóstico y servicio.
• La tabla de hecho, hospitalización, se cargará también mediante un proceso ETL.
• Las dimensiones se cargan antes que las tablas de hecho.

En nuestro caso particular, identificamos por lo tanto dos conjuntos de tareas:

• Proceso de creación de las dimensiones estáticas que realizaremos directamente desde

Oracle APEX.
• Procesos ETL que primero carga las dimensiones dinámicas fecha, diagnóstico, GRD y
servicio, y después carga la tabla de hecho hospitalización. Este será un único proceso ETL.

Por lo tanto, hemos identificado cinco procesos ETL que crear.

6.2. Descripción de las acciones en cada proceso ETL

Vamos a describir, en este apartado, la funcionalidad a alto nivel de los procesos ETL que
hemos identificado. Tener claro a alto nivel qué debe hacer el ETL ayuda a posteriori en el
proceso de diseño usando una herramienta específica.

En el momento de diseñar los procesos ETL, se empieza siempre por las dimensiones y se
finaliza con la tabla de hecho, ya que necesitamos las claves primarias de cada una de las
dimensiones para insertar valores en la tabla de hecho.
La estrategia, en este caso, es la que sigue:

• Existen varias dimensiones que no cambian en el tiempo y que presentan un número reducido
de casos. Para estas dimensiones, simplemente identificamos los valores que las componen y
hacemos una inserción directa en la base de datos.
• Para el resto de dimensiones, se creará un proceso ETL para cada una de ellas que extraerá
los datos de la fuente de origen, transformará el dato en la medida que lo necesite la
dimensión y realizará un proceso de inserción en la correspondiente tabla en el data mart
previamente creado.
• Finalmente, se creará un proceso ETL para la tabla de hecho que extraerá los datos de la
fuente de origen, recuperará la clave primaria de cada dimensión para cada registro y
realizará el proceso de inserción.

Para cada ETL describimos su objetivo y las tareas (o pasos) que lo componen.
Vamos a revisar brevemente el proceso ETL para la tabla de hechos. La siguiente captura de
pantalla muestra el proceso completo de la carga inicial de la tabla de hechos. Este proceso
ETL está formado por 12 pasos en los que, progresivamente, se capturan, preparan e insertan
los datos:

• Paso 1: extracción de datos de la fuente de origen Excel. En este mismo paso, indicamos qué
valores vamos a omitir en la hoja Excel, puesto que no son necesarios para la tabla de hecho
o para recuperar las claves primarias de las tablas de dimensiones.
• Pasos 2 al 10: cruzamos la información del fichero Excel con la información de cada una de
las dimensiones para recuperar el id correspondiente del registro de la dimensión. Como es
posible apreciar, se empieza en este ejemplo con la dimensión tipo de alta y se finaliza con
la dimensión fecha urgencia.
• Paso final: insertamos el flujo de datos que contiene las métricas y las claves foráneas en las
tablas de dimensiones y en la tabla de hecho.

En la wiki del libro podéis encontrar información detallada sobre cómo se han cargado las
dimensiones estáticas,13 sobre el entorno ETL utilizado para crear los procesos ETL14 y sobre
cómo se han creado los procesos ETL para cargar los datos de las dimensiones dinámicas y
las tablas de hechos.15

El resultado de los procesos de carga nos reporta:

6.3. Consideraciones finales

Tras el diseño de los procesos de carga y la ejecución de los mismos, podemos conocer el
tamaño del almacén de datos. Esta información va a permitir a futuro optimizar la factoría de
información. Por ejemplo, teniendo en cuenta el tamaño de los registros para este ejemplo, no
se propone una vista por años, pero quizás sería conveniente en el ejemplo real.

Una vez tenemos la información cargada en nuestro almacén de datos, ya podemos pasar a la
fase de explotación.

7. Creación del modelo OLAP

Una vez realizada la carga de datos en nuestro data warehouse, es el momento de crear un
modelo OLAP. Para ello, debemos identificar qué usuarios son los susceptibles de usar
análisis multidimensional, teniendo en cuenta que este tipo de usuarios son avanzados y, por lo
tanto, buscan analizar ellos mismos la información.

Como se apuntó en el análisis de requerimientos, los usuarios del sistema son la dirección
clínica y el propio centro. Dentro de la dirección clínica y el propio centro, los potenciales
tipos de usuario que pueden usar el modelo OLAP son diversos:

• Responsable del área de hospitalización. Este usuario busca comprender la evolución del
 área de hospitalización y tener claro qué servicios son los más demandados para poder
planificar, de forma adecuada, los servicios que se ofrecen. El usuario consultará la
información directamente o a través de la figura de un analista de negocio.
• Dirección clínica. A través de la figura de un analista de negocio, se busca entender cómo ha
evolucionado el área de hospitalización dentro del conjunto de áreas del hospital y cómo lo
que sucede en ella afecta al comportamiento global del hospital.

Aparte, existen otros usuarios que se pueden beneficiar del datawarehouse:

• Departamento financiero. Cada tipo de estadía tiene asociado un coste para el hospital.
Incluso teniendo un fin social, el hospital debe controlar correctamente los costes asociados
por paciente, para garantizar su sostenibilidad. Por tanto, el analista financiero/contable
deberá ser capaz de cruzar esta información con los costes para poder identificar si se ha
seguido el presupuesto planeado, calcular los costes reales y poder hacer planificaciones
futuras.

Para la creación del modelo OLAP, vamos a hacer uso de Visual Studio 2010, que nos va a
permitir generar de forma sencilla una estructura MOLAP basada en las tablas en Oracle que
hemos diseñado con anterioridad.

Una pregunta natural que surge es la siguiente: ¿qué sentido tiene crear un modelo OLAP?
Crear un modelo OLAP significa crear un cubo que represente el data warehouse o, en
general, un subconjunto del mismo. La importancia de crear este elemento de análisis es
múltiple:

• Evitar el acceso de los usuarios a información más allá de su alcance de negocio.

• Precalcular todas las posibles consultas mutidimensionales (reduciendo problemas de
rendimiento).
• Proporcionar una fuente de datos «transportable» y fuera de línea para los usuarios. Por
ejemplo, un usuario comercial podría llevarse una copia del cubo en su ordenador en el caso
de necesitarla y acceder ella mediante Excel.
• Proporcionar una herramienta de análisis no predefinida a los usuarios que necesitan una
herramienta más allá de los informes.

La creación del cubo OLAP necesario para contestar las preguntas analíticas planteadas es un
proceso altamente tecnológico, el cual dependerá de la herramienta a utilizar. El cubo
responderá a los criterios establecidos (dimensiones, hechos, jerarquías de agregación) en el
apartado de diseño del data warehouse. El lector encontrará en la wiki información sobre el
entorno que hemos utilizado para la creación del cubo OLAP,16 sobre cómo enlazar esta
herramienta con los datos del data warehouse,17 sobre cómo crear el cubo OLAP18y sobre
cómo acabar de ajustar el cubo y definir las jerarquías de agregación.19 El cubo resultante y
sus dimensiones se muestran en la siguiente figura:
Una vez generado el cubo, es necesario procesarlo. El procesado tiene dos funciones: la
validación del cubo y la generación del cubo. La validación comprobará que la estructura del
cubo es correcta. La generación es importante porque realizará precálculos del cubo para
mejorar el tiempo de respuesta del sistema. En la wiki del libro se puede ver, paso a paso,
cómo realizar la generación del cubo y acabar de ajustar los últimos detalles del mismo para
su uso.20

1 Según W. H. Inmon (consideradopormuchos el padre delconcepto), un data warehouse es un conjunto de
datosorientadosportemas, integrados, variantes en el tiempo y no volátiles, quetienenporobjetivodarsoporte a la toma de
decisiones. Según Ralph Kimball (considerado el principal promotordelenfoque dimensional para el diseño de almacenes de
datos), un Data Warehouse esunacopia de los datostransaccionalesespecíficamenteestruc¬turadapara la consulta y el análisis.
2 MDX hacereferencia a multidimensional expressions.Se considera el lengua¬je de consulta OLAP estándarde facto en el
mercado.
1 Determinarcorrectamentelas magnitudes quedefinen el proyectoparapodercalcular de forma precisa la viabilidad y
rentabilidaddelproyectoesuna de lasfasesmásrelevantes del proyecto y, es crucial paradeterminarpreviamente y posteriormente
el éxito del proyecto de la implementación del almacén de datos.
2 Esconvenienteconsiderardiferentesescenarios y calcularsucorrespon¬dienteanálisis de viabilidaddelproyecto. En el wiki
esposibleencontrarunaextensión de esteanálisis en la que se incluyen dos escenariosmásquecomplementan el análisisrealizado.
http://cv.uoc.edu/webapps/xwiki/wiki/disenodatawarehouse/
3 Acrónimo de valor actual neto, cuyosignificadoes el valor presente de undeterminadonúmero de flujos de cajafuturos.
4 Acrónimo de tasainterna de retorno, cuyosignificadoes el promediogeomé¬trico de los rendimientosfuturosesperados de
dichainversión, tasa de des¬cuento con la que el valor actual neto o valor presenteneto (VAN o VPN) esigual a cero.
5 Acrónimo de return on investment (retorno de la inversión).
6 Las hojas de datosactualesofrecenfuncionesparacalcular el TIR fácil¬mente.Porejemplo, con Excel la
funcióncorrespondienteesTIR().
7 En el caso de tenerinformaciónpormeses, se podríaajustar, con mayor precisión, el períodonecesarioparaque el proyectollegue
a la rentabilidadestablecidapor la tasa de descuento.
8 Acrónimo de registro de demandaquirúrgica.
9 http://goo.gl/yuvmvy
10 Estructura de cargaintermedia.
11 http://goo.gl/CtxQS0
12 http://goo.gl/iz7RZQ
13 http://goo.gl/tbZPd7
14 http://goo.gl/43IkFw
15 http://goo.gl/xF5sa1
16 http://goo.gl/y2Sgdo
17 http://goo.gl/syLbvD
18 http://goo.gl/66dcVs
19 http://goo.gl/rTFgwG
20 http://goo.gl/2kMOHP
Bibliografía

Referencias

Catsalut. Web de «Listas de espera». [Fecha de consulta: 3 de marzo de 2013].

<http://www.10.gencat.cat/catsalut>
Pla de Salut Catalunya 2011-2015. Departament de Salut, 2012. [Fecha de consulta: 3 de
marzo de 2013]. <http://www20.gencat.cat/portal/site/salut>
Real decreto 605/2003, de 23 de mayo, por el que se establecen medidas para el tratamiento
homogéneo de la información sobre las listas de espera en el Sistema Nacional de Salud.
BOE de 5 junio de 2003 (n.° 134).
Tebé, C.; Adam, P.; Alomar, S.; Espallargues, M. (2011). Impacte delsistema de
priorització de pacients en llista d’espera per artroplàstiesde genoll i maluc i cirurgia
de cataracta. Barcelona: Agència d’Informació, Avaluació i Qualitat en Salut. Servei
Català de la Salut. Departament de Salut. Generalitat de Catalunya. [Fecha de consulta: 3
marzo de 2013].
<http://www.gencat.cat/salut/depsan/units/aatrm/pdf/prioritzacio_artroplasties_catarac_aiaqs2011ca.
Tercer informe de la Central de Resultats. Barcelona: Agència d’Informació, Avaluació i
Qualitat en Salut. Servei Català de la Salut. Departament de Salut. Generalitat de
Catalunya, 2011. [Fecha de consulta: 3 de marzo de 2013].
<http://observatorisalut.gencat.cat>
Material de la asignatura Data warehouse de la UOC.
Devlin, B. (1997). Data Warehouse from Architecture Implementation.Estados Unidos:
Addison Wesley Longman, Inc.
Inmon, W. H. (1996). Building the Data Warehouse (2.a ed.). Estados Unidos: John Wiley &
Sons Inc.
Inmon, W. H. (1999). Building the Operational Data Store. Estados Unidos: John Wiley &
Sons Inc.
Inmon, W. H.; Hackathorn, R. D. (1994). Using the Data Warehouse.Nueva York: Wiley.
Inmon, W. H.; Imhoff, C.; Sousa, R. (1998). Corporate InformationFactory. Estados
Unidos: John Wiley & Sons Inc.
Inmon, W. H.; Strauss, D.; Neushloss, G. (2008). DW 2.0: The Architecture for the next
generation of Data Warehousing. Estados Unidos: Morgan Kaufman Series.
Kimball, R. (2013). The Data Warehouse Toolkit (3.a ed.). Nueva York: John Wiley & Sons
Inc.
Krish, K. (2013). Data Warehousing in the Age of Big Data. The Morgan Kaufmann Series on
Business Intelligence.
Enlaces de internet
Getting started with SQL Server Analysis Services:
http://www.mssqltips.com/sqlservertip/1167/getting-started-with-sql-serveranalysis-
services/
Breakthrough Insights using Microsoft SQL Server 2012 Training-Analysis Service:
http://www.microsoftvirtualacademy.com/training-courses/breakthrough-insights-using-
microsoftsql-server-2012-analysis-services
MSDN Analysis Services tutorial: http://msdn.microsoft.com/en-
us/library/ms170208%28v=SQL.105%29.aspx
Oracle Database 11g Express Edition Tutorial Series: http://apex.oracle.com/pls/apex/f?
p=44785:24:112757326496942::NO:24:P24_CONTENT_ID%2CP24_PREV_PAGE:5922%2C
Tutorial Integration Services: http://technet.microsoft.com/es-es/library/ms169917.aspx
 Las soluciones
Josep Curto
Jordi Conesa

Una vez llegados a este punto, ya tenemos la infraestructura necesaria para la creación de las
consultas que den solución a las necesidades analíticas definidas por los usuarios de negocio.
Como se indica en el reto, el sistema debe ser capaz de responder a las siguientes preguntas:

• Evolución de las hospitalizaciones.

• Evolución de las hospitalizaciones por tipo de alta.
• Evolución de las hospitalizaciones por meses y años.
• Evolución de las hospitalizaciones por servicio del hospital.

En este apartado final de la solución, veremos cómo el cubo OLAP que hemos diseñado es
capaz de responder a cada una de preguntas anteriores.

La consulta al cubo puede realizarse de diferentes formas:

• Directamente, mediante la pestaña «Examinador» en la edición del cubo.

• Mediante un visor OLAP como puede ser Microsoft Excel u otros.

En la wiki del libro (http://goo.gl/CtXdni), se muestra, mediante videotutoriales, cómo

acceder a los datos del cubo mediante ambos entornos.

En nuestro caso particular, lo haremos directamente con el «Examinador».

Los siguientes códigos QR apuntan a los dos videotutoriales comentados

En el caso de que las consultas sean sencillas, tan solo debemos arrastrar medidas o niveles
para ser capaces de hacer preguntas al sistema.

OLAP es una herramienta de alto valor para un usuario que persigue comprender un aspecto de
negocio desde múltiples perspectivas y necesita una herramienta flexible que le proporcione
respuestas, tal y como se van generando preguntas en un proceso de autoservicio.

Vamos a revisar cada una de las preguntas.

1. Evolución de las hospitalizaciones

Si arrastramos la medida de hospitalizaciones, rápidamente sabremos que el número total es

14.326.
Como gestor, también podemos preguntarnos por otras métricas como, por ejemplo, los días
de hospitalización totales, y visualizarlos al mismo tiempo que las hospitalizaciones.

Está claro que las 14.326 altas han estado precedidas de 83.866 días de hospitalización.

Pero es necesario contextualizar estas métricas. Por ello, una pregunta natural es segmentar
este tipo de información por tipo de admisión. Esto nos da:
Este análisis nos permite entender que, si bien hay más hospitalizaciones programadas, es
cierto que las urgentes generan más días de hospitalización.

Al añadir, por ejemplo, el nivel año de la dimensión fecha alta, descubrimos rápidamente que
hubo más altas de hospitalizaciones en 2012 que en 2013.

Y podemos estudiar las hospitalizaciones por fecha de ingreso también:

Como es posible apreciar, para el conjunto de pacientes que estamos considerando, los
ingresos de hospitalizaciones se concentran en 2012 y 2013, aunque tenemos alguna fecha de
ingreso del año 2008 y 2011. Eso quiere decir que, aunque el conjunto de datos hagan
referencia a 2012 y 2013, es cierto que tenemos pacientes aún ingresados en periodos
anteriores.

También podemos hacernos otras preguntas con respecto a las hospitalizaciones, como por
ejemplo, si ingresan más hombres que mujeres:

Parece que el número de hospitalizaciones de hombres es superior al de mujeres. Se puede

consultar este hecho de forma histórica (por años, respecto a la fecha de ingreso):
Es interesante comprobar que el paciente ingresado en 2008 es un hombre. Podemos
profundizar en el análisis y comprender el tipo de episodio por fecha de ingreso y sexo:

2. Evolución de las hospitalizaciones portipo de alta

Si, a la medida de hospitalizaciones, le añadimos el nivel descriptivo del tipo de alta,

veremos la distribución de la medida por cada uno de los valores:
Podemos comprobar, por lo tanto, que el tipo de alta más frecuente es a domicilio, seguida por
agudos/psiquiátrico y exitus. Es relevante constatar que el tipo de alta menos frecuente es
huida y tan solo hay un par de casos esporádicos.

3. Evolución de las hospitalizaciones pormeses y años

A la consulta anterior, en la que estudiábamos la evolución de las hospitalizaciones por fecha

de ingreso, podemos añadir años y meses, como vemos a continuación:
Podemos apreciar, por lo tanto, que en los primeros meses del año tanto en 2012 y 2013 se
concentran las hospitalizaciones. Será relevante para el gestor continuar investigando por qué
se concentran en esos tres meses iniciales.

4. Evolución de las hospitalizaciones porservicio del hospital

Como en los casos anteriores, para responder esta pregunta simplemente tenemos que arrastrar
los niveles y las medidas que nos interesan. Es decir, hospitalizaciones y Desc Servicio.
De igual manera, añadiendo las fechas de ingreso, podríamos estudiar cómo ha evolucionado
el servicio.

Finalmente, este análisis nos permite conocer que el paciente que ingresó en 2008 lo hizo por
cirugía general y digestiva.

Estas son algunas de las preguntas que puede hacerse un usuario. A medida que el usuario
conozca más a fondo los datos presentes como sus capacidades, es probable que, de forma
natural, pida mayor información. Lo que implicará enriquecer el modelo incluyendo nuevas
métricas o más información para las dimensiones.