Pfc itziar angoitia_espinosa

DATA WAREHOUSE
PARA LA GESTIÓN DE
LISTA DE ESPERA SANITARIA

AUTORA: ITZIAR ANGOITIA ESPINOSA
TUTORA: ERNESTINA MENASALVAS RUÍZ

A mis padres y hermano
que se empeñaron en hacerme estudiar.
Y a Rafa
que se empeñó en que terminase este libro.
THDM

AGRADECIMIENTOS
Mi especial agradecimiento a Ernestina Menasalvas por las ideas aportadas para
la elaboración de este proyecto, por la paciencia demostrada y por el tiempo
dedicado pese a la carga de trabajo con la que cuenta.

Muchas gracias.

Tabla de contenidos

Definiciones y acrónimos...............................................................................................iii
1. INTRODUCCIÓN ....................................................................................................... 3
2. CONCEPTOS Y TERMINOLOGÍA DE DATA WAREHOUSE .......................... 3
2.1. OLTP versus Data Warehouse.................................................................................. 3
2.2. ¿Qué es un Data Warehouse? .................................................................................. 3
2.2.1. Sistemas operacionales.......................................................................................................... 3
2.2.2. Data Warehouse ...................................................................................................................... 3
2.2.3. Servicios de consulta .............................................................................................................. 3
2.3. Fases y Equipos de trabajo ....................................................................................... 3
3. TÉCNICAS PARA LA CONSTRUCCIÓN DE UN DATA WAREHOUSE........ 3
3.1. Modelado dimensional................................................................................................ 3
3.1.1. Técnicas básicas de modelado dimensional ....................................................................... 3
3.1.2. Dimensiones y hechos conformados .................................................................................... 3
3.2. Procesos ETL................................................................................................................ 3
3.2.1. Técnicas básicas de los procesos ETL. ............................................................................... 3
3.2.2. Control de procesos ETL. ....................................................................................................... 3
3.3. Almacenamiento........................................................................................................... 3
3.3.1. Indexación................................................................................................................................. 3
3.3.2. Agregados................................................................................................................................. 3
3.4. Presentación. ................................................................................................................ 3
3.4.1. Análisis de la información del Data Warehouse.................................................................. 3
3.4.2. Herramientas de acceso a la información............................................................................ 3
4. DESARROLLO Y CONSTRUCCIÓN DE UN DATA WAREHOUSE PARA
LA GESTIÓN DE LISTA DE ESPERA SANITARIA. .................................................... 3
4.1. Planteamiento y requerimientos, las necesidades del cliente......................... 3
4.2. Análisis. .......................................................................................................................... 3
4.3. Diseño y construcción. Planteamiento de la solución....................................... 3
4.3.1. Modelo dimensional................................................................................................................. 3
4.3.1.1. Descripción de las tablas de hechos ............................................................................ 3
4.3.1.2. Descripción de las dimensiones .................................................................................... 3
4.3.2. Procesos ETL ........................................................................................................................... 3
4.3.2.1. Procesos de extracción y transformación .................................................................... 3
4.3.2.2. Procesos de carga ........................................................................................................... 3
4.4. Despliegue. Aplicaciones de usuario. .................................................................... 3
5. CONCLUSIONES Y TRABAJOS FUTUROS....................................................... 3

_____________________________________________________________________________________
___

i
Data Warehouse para la Gestión de Lista de Espera Sanitaria

5.1. Conclusiones ................................................................................................................ 3
5.2. Trabajos futuros ........................................................................................................... 3
6. REFERENCIAS ......................................................................................................... 3
7. ENLACES DE INTERÉS .......................................................................................... 3

ii

Definiciones y acrónimos

Dada la extensión del documento y dado que se repiten muchas veces los mismos términos,
he optado por utilizar algunos acrónimos y normas que permitan seguir con mayor facilidad el
contenido del documento.

Se ha usado la letra

• cursiva con negrita la primera vez que se han nombrado terminos importantes en el
desarrollo del documento y que con posterioridad se han escrito sólo en cursiva.

• cursiva para indicar palabras que tienen especial importancia en lo que se está
indicando en ese momento, así se han escrito en cursiva los nombres asociados a
dimensiones o palabras que han sido definidas con anterioridad y que para un
desconocedor del tema serían palabras de difícil comprensión; pero que ya se han
explicado con anterioridad en el documento y que por lo tanto deberían tener un
sentido conocido.

• ETC/ETL: Extraer, Transformar y Cargar / Extract, Transform and Load.

• LEQ o RDQ: Representa la Lista de Espera Quirúrgica o Registro de Demanda
Quirúrgica como se le ha venido llamando últimamente. Este proyecto surgió como
respuesta a una Ley aparecida en el BO de una determinada Comunidad Autónoma,
que fácilmente se puede extender a cualquier otra Comunidad e incluso a la totallidad
del Estado Español, durante el desarrollo del mismo hubo términos que cambiaron y
donde en un principio se nombraba Lista de Espera Quirúrgica y Consulta Externa,
pasó a denominarse Registro de Demanda Quirúrgica y Consulta Externa. En este
documento, así como en todas las tablas a las que se hace referencia se ha
mantenido el acrónimo de LEQ, aunque de aparecer RDQ se estaría haciendo
referencia al mismo término.

• CEX: Representa la Lista de Consulta Externa.

• CIE: Clasificación Estadística Internacional de Enfermedades y otros Problemas de
Salud; del inglés ICD (International Statistical Classification of Diseases and Related
Health Problems)

• SNS: Servicion Nacional de Salud

• MSC: Ministerio de Sanidad y Consumo.

• VPD: Virtual Private Database, también conocidas como “acceso de control de grano

iii

fino”, del inglés, “fine graind access control” (FGAC).

La política de nombrado de las tablas utilizadas en el proyecto, ha sido la de utilizar ocho
letras para nombrar todas las tablas. Las cuatro letras centrales intentan representar el
contenido significativo de lo que contienen, las dos primeras letras indican el acrónimo del
proyecto al que pertenecen, LE (Lista de Espera) y las dos letras finales son:

• DI: para indicar una dimensión. Ejemplo LEPROFDI – Profesionales o LEHOSPDI -
Hospitales

• HE: para indicar una tabla de hechos. Ejemplo: LELEQCHE - Lista de Espera
Quirúrgica o LECOEXHE - Lista de Consulta Externa

iv

1. INTRODUCCIÓN

1. INTRODUCCIÓN

En los tiempos en los que nos movemos, las empresas necesitan depositar toda su
confianza en la Toma de Decisiones - Decision Support. Dada la competencia existente,
que crece en todo momento, estas decisiones deben ser rápidas y deben ser tomadas sobre
una gran cantidad de hechos y cifras. Comparar los resultados por regiones o meses podría
proporcionar una base para nuevas iniciativas de marketing. Un profundo análisis de la
competencia también podría ser un catalizador para las prioridades de mejora. Las
decisiones son las unidades básicas de la gestión. Las buenas decisiones son la base para
conseguir un rendimiento excepcional. Ahora las empresas no dependen tan solo de
factores como ubicación, productos, etc., sino que también del conocimiento. Tal
conocimiento, basado en información comprensible, detallada y relevante es crucial para
lograr y sostener ventaja competitiva. El poseer conocimientos correctos significa tener
respuestas correctas y realizar decisiones estratégicas para la ejecución de la empresa. La
tarea de recolectar, procesar, limpiar y transformar la información necesaria para la toma de
decisiones no es una tarea sencilla, sobre todo si consideramos que una empresa tiene
distintas áreas, que a veces, se encuentran alejadas de los ejecutivos de negocios. Por otro
lado, se dispone de fuentes de datos cada vez más numerosas, desconectadas entre si y a
menudo incompatibles. Fuentes de datos que tienen que cambiar a lo largo de la evolución
de las estrategias de las empresas. Necesitamos herramientas que nos ayuden a minimizar
el tiempo para analizar toda esa información con mayor velocidad y precisión; logrando de
esta manera mantenernos competitivos, y reaccionar a los cambios del mercado,

El componente de Inteligencia del Negocio - Bussines Intelligence - que resuelve este
caos de los datos para una rápida toma de decisiones es el Almacén de datos – Data
Warehouse. El Data Warehouse es un conjunto de procesos y acciones, es una colección
de datos orientados a un tema, integrados y no volátiles en el soporte al proceso de toma de
decisiones de una empresa.

Este trabajo aborda un proyecto de Data Warehouse para la ayuda a la toma de decisiones
en el ámbito de la Sanidad y en concreto en los Centros Hospitalarios de una Comunidad
Autónoma, aunque se podría aplicar en general a la Gestión Hospitalaria de todo el país. Lo
he dividido en dos partes, una primera en la que se describen las características técnicas de
cualquier Data Warehouse, la organización de los sistemas que lo componen y las técnicas
empleadas en cualquier desarrollo, comentándose en el capítulo “CONCEPTOS DE UN
DATA WAREHOUSE” y “TÉCNICAS PARA LA CONSTRUCCIÓN DE UN DATA
WAREHOUSE” y una segunda parte dónde se pone en desarrollo todo lo expuesto para

1

1. INTRODUCCIÓN

resolver un caso real, “CONSTRUCCIÓN DE UN DATA WAREHOUSE PARA LA GESTIÓN
DE LISTA DE ESPERA SANITARIA” en una Comunidad Autónoma, que solicitó:

“…el diseño, construcción e implantación de un Data Warehouse corporativo para
las Listas de Espera Quirúrgicas, de Consultas Externas y de Pruebas
Complementarias, en el ámbito de la atención especializada del Servicio de Salud.
Este proyecto continuiría el primer paso en el diseño de un sistema de ayuda a la
toma de decisiones en el ámbito del Sistema de Salud, y, por lo tanto, debería
permitir su integración con los actuales subsistemas de datos y la agregación de
subsistemas futuros, y debería definir los procesos y protocolos básicos a emplear
en el futuro en este ámbito. Los distintos establecimientos hospitalarios del Sistema
de Salud disponían en la actualidad de aplicaciones informáticas que permiten la
gestión de las listas de espera a nivel del Centro Hospitalario… “

El cliente expuso diferentes exigencias como que los Servidores fueran UNIX y el Sistema
Gestor de base de datos fuera ORACLE y otroas aspectos que se explicarán a lo largo del
documento.

2

2.CONCEPTOS Y TERMINOLOGÍA DE DATA WAREHOUSE

2. CONCEPTOS Y TERMINOLOGÍA DE DATA
WAREHOUSE

2.1. OLTP versus Data Warehouse

Desde que a principios de la década de 1980 comenzaron a desarrollarse bases de datos
siguiendo el modelo relacional, la capacidad y velocidad de estos sistemas ha ido
mejorando año tras año. La información almacenada en las bases de datos se orientó desde
un primer momento al registro de transacciones, sistemas OLTP - On Line Transaction
Processing - de un modo tal que los procesos se diseñaron fundamentalmente para
introducir información en los sistemas, pero no para extraerla de ellos. A medida que ha ido
creciendo el volumen de información almacenada, ha crecido también la dificultad de
acceder a ella de un modo sencillo y eficiente.

Un Data Warehouse es un sistema en el que se almacenan datos con el objetivo de que los
usuarios puedan extraer fácilmente la información que necesitan. OLAP es el acrónimo en
inglés de procesamiento analítico en línea - On-Line Analytical Processing -. Es una
solución utilizada en el campo de la Inteligencia de Negocios, la cual consiste en consultas a
estructuras multidimensionales que contienen datos resumidos de grandes Sistemas
Transaccionales. En el Data Warehouse se almacenan los datos de los sistemas
transaccionales con una organización no relacional que facilita la consulta y la extracción de
información de grandes volúmenes de datos.

Los sistemas Data Warehouse están orientados a procesos de consultas en contraposición
con los procesos transaccionales, sus tablas pueden no estar normalizadas y se admite
redundancia en los datos. Un Data Warehouse no se encuentra en la Tercera forma normal
(3NF), lo que le hace más rápido a la hora de hacer SELECTS, en contraposición con un
OLTP que es la mejor opción para INSERTS, UPDATES y DELETES. El OLTP,
normalmente, está formado por un número mayor de tablas, cada una con pocas columnas,
mientras que en un Data Warehouse el número de tablas es menor, pero cada una de éstas
tiende a ser mayor en número de columnas. Los OLTP son continuamente actualizados por
otros sistemas del día a día, mientras que los Data Warehouse son actualizados en batch
de manera periódica. Las estructuras de los OLTP son muy estables, rara vez cambian,
mientras las de los Data Warehouses sufren cambios constantes derivados de su evolución.

3


Esto se debe a que los tipos de consultas a los cuales están sujetos son muy variados y es
imposible preverlos todos de antemano. Un Data Warehouse, normalmente, almacena
muchos meses o años de datos para análisis históricos de la información, un OLTP,
normalmente, almacena algunas semanas

Las aplicaciones de OLTP están organizadas para ejecutar las transacciones para los
cuales fueron hechos, como por ejemplo: mover dinero entre cuentas, un cargo o abono,
una devolución de inventario, etc. Por otro lado, un Data Warehouse está organizado en
base a conceptos, como por ejemplo: clientes, facturas, productos, etc.

Las diferencias entre un OLTP y un Data Warehouse en su parte arquitectónica, se puede
reducir a:

Otra diferencia radica en el número de usuarios. Normalmente, el número de usuarios de un
Data Warehouse es menor al de un OLTP. Es común encontrar que los sistemas
transaccionales son accedidos por cientos de usuarios simultáneamente, mientras que los
Data Warehouse sólo por decenas. Los sistemas de OLTP realizan cientos de
transacciones por segundo mientras que una sola consulta de un Data Warehouse puede
tomar minutos.

Las diferencias entre un OLTP y un Data Warehouse en la operativa se pueden reducir a:

SISTEMA TRADICIONAL DATA WAREHOUSE
Predomina la actualización Predomina la consulta
La actividad más importante es de tipo La actividad más importante es el análisis y la
operativo (día a día) decisión estratégica
Predomina el proceso puntual Predomina el proceso masivo

4


Mayor importancia a la estabilidad Mayor importancia al dinamismo
Datos en general desagregados Datos en distintos niveles de detalle y agregación
Importancia del dato actual Importancia del dato histórico
Importante del tiempo de respuesta de la Importancia de la respuesta masiva
transacción instantánea
Estructura relacional Visión multidimensional
Usuarios de perfiles medios o bajos Usuarios de perfiles altos
Explotación de la información relacionada Explotación de toda la información interna y
con la operativa de cada aplicación externa relacionada con el negocio

2.2. ¿Qué es un Data Warehouse?

La información, en la mayor parte de los casos, se almacena de dos modos diferentes: en
un sistema operacional o en un Data Warehouse. El sistema operacional es, a grandes
rasgos, el sistema en el que se introducen los datos y el Data Warehouse es el sistema
que se utiliza para extraer la información. A pesar de que en un principio puede parecer
que un único sistema es suficiente para cubrir las necesidades tanto de introducción de
datos como de extracción de información, en los últimos años se ha puesto de manifiesto
que, para organizaciones que manejan grandes volúmenes de datos, el modo de conseguir
un rendimiento óptimo pasa indiscutiblemente, por la separación de ambos sistemas,
debido a las diferentes necesidades de configuración y organización de la información.

Un Data Warehouse es un sistema, no un producto, en el que se almacenan datos. Es una
técnica para consolidar y administrar datos de variadas fuentes con el propósito de
responder preguntas de negocios y tomar decisiones, de una forma rápida. Un Data
Warehouse se vale de una base de datos relacional diseñada para el acceso rápido y
análisis y no al proceso transaccional. El Data Warehouse separa la carga del análisis y
normalmente contiene datos históricos derivados de datos transaccionales.

Existen muchas definiciones para el Data Warehouse, la más conocida fue propuesta por
William Inmon - considerado el padre del Data Warehouse - en 1992:

"Un DW es una colección de datos orientados a temas, integrados, no-volátiles
y variante en el tiempo, organizados para soportar necesidades empresariales".

William Inmon indicó que un Data Wafehouse se caracterizaba por ser:

• Temático: Los Data Warehouses están diseñados para ayudar a analizar los datos
de un determinado tema o significado. Por ejemplo, para saber más

5


sobre un Centro Hospitalario se puede construir un Data Warehouse que
concentre las consultas. Utilizando este Data Warehouse se podrían
hacer preguntas del tipo ¿Cuál ha sido la enfermedad más habitual este
año?. Esta habilidad de localizar un tema prioritario hace que se cree un
Data Warehouse orientado a un tema.

• Integrado: La integración está muy relacionada con el punto “temático”. Los Data
Warehouses deben aunar datos de fuentes dispares de una forma
consistente. Deben resolver problemas tales como el nombre de los
campos, conflictos de inconsistencia en unidades y medidas antes de ser
almacenados.

• No volátil: No volátil significa que una vez introducidos los datos en el Data
Warehouse, estos datos no deben ser cambiados. Esto es lógico debido
a que el propósito del Data Warehouse es ser capaz de analizar lo que
ya ha acurrido.

• Variante en el tiempo: El foco del Data Warehouse se centra en los cambios
realizados a lo largo del tiempo, es decir, estudia como el tiempo hace
evolucionar los diferentes elementos. Para esto se necesita una gran
cantidad de datos almacenados a lo largo de mucho tiempo. En esto
difiere mucho de un sistema transaccional, donde los datos históricos
son archivados y poco accedidos.

También en 1993, Susan Osterfeldt publicó una definición que sin duda acierta en la clave
del DW:

"Yo considero al DW como algo que provee dos beneficios empresariales
reales: Integración y Acceso de datos. DW elimina una gran cantidad de datos
inútiles y no deseados, como también el procesamiento desde el ambiente
operacional clásico".

Los requerimientos del negocio son los que dirigen la arquitectura de diseño de un Data
Warehouse por lo que se debe tener bien claro todos los asuntos del negocio, las
estrategias, los procesos, la disponibilidad y las expectativas de ejecución del negocio.

Los objetivos de un Data Warehouse son:

• Hacer accesible la información de la organización. La información contenida en
el Data Warehouse debe ser navegable, fácilmente comprendida por los usuarios,
y sobre todo de acceso rápido.

6


• Hacer que la información de la organización sea consistente. La información
de un departamento de la organización puede ser contrastada con la información
de otro departamento. Si dos mediciones tienen el mismo nombre, entonces
significan lo mismo, por el contrario, si dos mediciones representan conceptos
diferentes, deben llamarse de distinto modo de manera que toda la información es
correcta y está al día.

• Ser una fuente adaptable de información. El Data Warehouse está diseñado
para afrontar con éxito continuos cambios. Cuando surgen nuevas necesidades de
información, nuevas preguntas o nuevos datos añadidos, las tecnologías y los
datos existentes no deben verse afectadas. El diseño de núcleos de información
separados (Data Marts) debe ser distribuido e incremental.

• Ser la base para la toma de decisiones. Los datos contenidos en el Data
Warehouse son adecuados para justificar decisiones estratégicas de la
organización. Las decisiones se toman una vez que el Data Warehouse ha
aportado los datos que las justifican.

En la imagen siguiente se describe la arquitectura tecnológica que hace posible que se
cumplan todos estos objetivos.

Fig.: 2.1 Arquitectura de un sistema de Data Warehouse

Donde podemos distinguir tres áreas diferenciadas:

• Sistemas operacionales. Son el origen de los datos, los sistemas que recogen los
datos en la organización. De ellos se extraen los datos que se almacenan en el
Data Warehouse.

• Data Warehouse y servidores de presentación. Es el lugar en el que se
almacenan físicamente los datos del Data Warehouse. La información acerca de

7


los datos almacenados (qué significan, de dónde se obtienen, etc.) se almacena en
un catálogo de metadatos.

• Servicios de consulta. Lo normal es que los procesos de un Data Warehouse ,
se cierren con una Explotación de la información a través de informes o
herramientas de fácil manejo que hagan más sencilla la toma de decisiones. Son
los sistemas que proporcionan acceso a los usuarios y a las diferentes aplicaciones
a los datos del Data Warehouse.

Por otro lado, los servicios de consulta pueden y deben ser utilizados como un medio para
hacer evolucionar los sistemas de recogida de información de la organización para hacer
frente a nuevas necesidades de información, o sencillamente mejorar la calidad de la
información recogida; pero veamos cada bloque en profundidad.

2.2.1. Sistemas operacionales

Los orígenes de datos son los sistemas encargados de recoger la información de las
transacciones generadas en la organización. Estos sistemas se conocen habitualmente
como sistemas operacionales o “sistemas legacy”. Deben ser sistemas fiables y
consistentes, aunque entre ellos haya marcadas diferencias en los formatos y las
estructuras de los datos. Estos sistemas quedan fuera del Data Warehouse por lo que no
tenemos el control sobre el contenido de sus datos.

El área de transformación de los datos (ATD) consta tanto del área de almacenamiento
como del conjunto de procesos que se usan frecuentemente para la extracción,
transformación y carga de los datos. A este conjunto de procesos se les conoce como
Procesos ETL y viene de las siglas inglesas Extraer, Transformar y Cargar - Extract,
Transform and Load. Es el enlace entre los sistemas operacionales y el Data Warehouse.
Concretamente se distinguen:

1. Extracción: Normalmente los Data Warehouse consolidan diferentes sistemas de
fuentes de datos. Cada sistema separado puede usar una organización diferente de
los datos o formatos distintos. Los formatos de las fuentes normalmente se
encuentran en bases de datos relacionales o ficheros planos, pero pueden incluir
bases de datos no relacionales u otras estructuras diferentes. La fase de extracción
convierte los datos de los diferentes sistemas, a un formato preparado para iniciar el
proceso de transformación.

Al mecanismo para especificar las correspondencias o mapeos entre el esquema
fuente y un esquema intermedio para cargar la información en el Data Warehouse

8


se denomina mapping o mapeo. Estos mapeos son cálculos y funciones y se
considera parte del código o metadatos del Data Warehouse

2. Transformación: La fase de transformación aplica una serie de reglas de negocio o
funciones sobre los datos extraídos para convertirlos en datos que puedan ser
cargados. Algunas fuentes de datos requerirán alguna pequeña manipulación de los
datos. Algunas de las transformaciones más sencillas pueden ser:

a. Seleccionar solo ciertas columnas para su carga (o si lo prefiere, que las
columnas con valores nulos no se carguen)

b. Traducir códigos (Ej. Si la fuente almacena una "H" para Hombre y "M" para
Mujer pero el destino tiene que guardar "1" para Hombre y "2" para Mujer )

c. Codificar valores libres (ej. Mapear "Hombre", "H" y "Sr" en un "1")

d. Derivar nuevos valores calculados (ej. qty_venta = qty * precio)

e. Unir datos de múltiples fuentes (ej. búsquedas, fusión, etc)

f. Sumar múltiples filas de datos (ej. ventas totales de cada región)

g. Generación de campos clave en el destino

h. Transponer o pivotar (girando múltiples columnas en filas y viceversa)

3. Carga: La fase de carga es el momento en el cual los datos de la fase anterior son
cargados en el destino. Dependiendo de los requerimientos de la organización,
este proceso puede abarcar una amplia variedad de procesos diferentes. Algunos
Data Warehouses sobrescriben información antigua con nuevos datos. Los
sistemas más complejos pueden mantener un historial de los registros de manera
que se pueda hacer una auditoría de los mismos y disponer de un rastro de toda la
historia de un dato, lo que se denomina seguimiento de cambios.

2.2.2. Data Warehouse

Los datos del Data Warehouse se almacenan en un equipo con el software adecuado
(sistema operativo servidor, gestores de bases de datos configurados para almacenar
grandes volúmenes de información, etc.) para que puedan ser consultados por usuarios y
aplicaciones. A este equipo se le conoce como servidor de presentación.

9


En la mayor parte de los Data Warehouses con grandes volúmenes de datos construidos
hasta la fecha, el servidor de presentación puede estar basado en dos tecnologías
diferentes:

• basado en tecnologías de bases de datos relacionales con tablas organizadas en
esquemas en estrella, también conocidos como modelos dimensionales.

• basado en una tecnología no relacional conocida como, Procesamiento Analítico
en Línea del inglés OLAP - On Line Analytic Processing - en la que los datos se
organizan de una manera similar a los modelos dimensionales. Las herramientas
OLAP se pueden ver como la síntesis, análisis y consolidación de grandes
volúmenes de datos empresariales en la perspectiva de múltiples dimensiones tales
como el tiempo, los clientes, las cadenas, las operaciones financieras, etc. Este
análisis en línea de los datos puede utilizar fórmulas matemáticas y análisis
estadísticos para consolidar y resumir los datos.

El modelado dimensional es una técnica de modelización de información, que puede ser
utilizada como alternativa a las técnicas de modelado entidad-relación - E/R. Un modelo
dimensional contiene la misma información que un modelo E/R, aunque organizada
siguiendo un formato simétrico cuyos objetivos son facilitar la comprensión a los usuarios,
optimizar el rendimiento de las consultas y facilitar las modificaciones en el modelo para
permitir una rápida adaptación ante cambios en las necesidades de información. El modelo
dimensional divide el mundo de los datos en dos grandes tipos: las medidas y las
descripciones del entorno de estas medidas. Las medidas, que generalmente son
numéricas, se almacenan en las tablas de hechos y las descripciones de los entornos que
son textuales se almacenan en las tablas de dimensiones.

• Las tablas de hechos son las tablas principales en el modelo dimensional y contiene
las mediciones sobre atributos de la organización, valores del Negocio. Los hechos
más útiles son los que contienen información numérica y aditiva. Cada tabla
representa una interrelación muchos a muchos y contiene dos o más claves
externas – foreign key - que acoplan con sus respectivas tablas de dimensiones.
Para construir la tabla de hechos se tiene en cuenta la idea principal del negocio.

• Las tablas de dimensiones complementan las tablas de hechos. Cada dimensión se
define por su clave primaria – primary key - que sirve para mantener la integridad
referencial en la tabla de hechos con la que se acopla. La mayor parte de las
dimensiones contienen un gran número de atributos de texto que sirven de base
para restringir y agrupar las consultas sobre el Dara Warehouse. Las tablas de

10


dimensiones contienen información jerárquica que permitirán la realización de las
agregaciones o profundizaciones, como trataremos en más profundidad en el
punto de “Drill up y Drill down” del capítulo Técnicas básicas de modelado
dimensional.

La arquitectura del Data Warehouse se convierte en el esquema de producción, no es un
plan de proyectos o una lista de tareas, es el “qué” se debe hacer y no cómo y por qué.
Desarrollar una arquitectura es difícil, pero posible y decisiva para el éxito del Data
Warehouse. La arquitectura está dirigida por el Negocio y por otro lado, los requerimientos
del negocio traen implicaciones técnicas sobre la arquitectura. Por ejemplo: las
actualizaciones nocturnas conllevan a adecuar el procesamiento en el ATD; si se quiere
tener una disponibilidad a nivel mundial se requiere de servidores distribuidos o paralelos;
etc

Al construir un Data Warehouse se puede plantear la pregunta de si conviene construir un
único Data Warehouse o por el contrario es mejor construir varios sistemas independientes
a medida que surjan nuevas necesidades. Ninguna de las dos aproximaciones es
conveniente en la práctica. Al construir un inmenso sistema independiente, la gran cantidad
de información que debe recuperarse y organizarse para llevar a cabo la aproximación
centralizada hace que ésta sea prácticamente imposible de completar con éxito. Por otra
parte, la construcción de sistemas de información aislados provoca la pérdida de la
posibilidad de obtener una visión general de la organización. La solución a este dilema pasa
por definir una fase inicial del proyecto en la que se obtenga una visión general de la
organización para definir una arquitectura global, y una segunda fase en la que se
implementen sistemas que cubran necesidades de información específicas pero siguiendo
la arquitectura definida en la primera fase. A estos sistemas se les conoce con el nombre de
Data Marts. La arquitectura resultante de aplicar esta estrategia se conoce como
Arquitectura en Bus. Un Data Warehouse formado por varios Data Marts siguiendo una
arquitectura en bus consiste en un conjunto de sistemas de información que cumplen una
serie de características comunes que les permiten interactuar. En una primera fase de la
construcción del Data Warehouse se realiza un estudio de la organización en el que se
define una arquitectura de datos general, de esta forma se establecen las pautas necesarias
para que diferentes equipos de trabajo puedan trabajar de forma independiente en la
construcción de los Data Marts que aporten información específica. Cuando exista un
número suficiente de Data Marts podrán pasar a formar parte de un sistema mayor, sistema
que tendrá un valor añadido al proporcionar información generada a partir de la combinación
de diferentes fuentes de datos.

11


Otra característica del Data Warehouse es que contiene datos relativos a los datos,
concepto que se asocia al término de metadatos. Los metadatos permiten mantener
información de la procedencia de la información, la periodicidad de refresco, su fiabilidad,
forma de cálculo o mapeo, seguridad a nivel personal, de grupo de trabajo y de empresa,
con el objetivo de visualizar, cambiar y distribuir resúmenes adaptados, relativos a los datos
de nuestro almacén. Estos metadatos son los que permiten simplificar y automatizar la
obtención de la información desde los sistemas operacionales hacia los sistemas
dimensionales.

Los metadatos son como el mapa de caracteres hacia los datos. En forma muy parecida a la
que una ficha de catálogo de biblioteca apunta tanto al contenido como a la ubicación de los
libros de una biblioteca, los metadatos apuntan a la ubicación y al significado de información
dentro del Data Warehouse.

Los metadatos recopilan todos los aspectos del Data Warehouse, los cuales pueden constar
de los siguientes tipos de elementos:

• Ubicación y descripción de servidores, bases de datos, tablas, nombres y
resúmenes del Data Warehouse.

• Reglas para la profundización automática al detalle o al resumen y a través de
jerarquías de dimensión empresarial, tales como productos, mercados y cuadros
contables.

• Nombres elegidos o alias definidos por el usuario final para los encabezados y
hechos de datos con nombres más técnicos.

• Seguridad a nivel personal, de grupo de trabajo y de empresa, para visualizar,
cambiar y distribuir resúmenes adaptados.

• Descripciones de fuentes originales y transformaciones. Algoritmos de resumen.

• Definiciones lógicas de tablas y atributos del Data Warehouse.

• Definiciones físicas de tablas y columnas, así como de sus características.

• Ubicación integrada de las tablas del Data Warehouse.

• Antecedentes de extracción.

Los objetivos que deben cumplir los metadatos, según el colectivo al que va dirigido, serían:

• Soportar al usuario final, ayudándole a acceder al Data Warehouse con su propio
lenguaje de negocio, indicando qué información hay y qué significado tiene,

12


ayudándole a construir consultas, informes y análisis, mediante herramientas de
navegación.

• Soportar a los responsables técnicos del Data Warehouse en aspectos de auditoría,
gestión de la información histórica, administración del Data Warehouse, elaboración
de programas de extracción de la información, especificación de las interfaces para
la realimentación a los sistemas operacionales de los resultados obtenidos, etc.

2.2.3. Servicios de consulta

Para acceder al Data Warehouse se implementan las herramientas de acceso de datos del
usuario final. Estas herramientas constituyen el cliente del Data Warehouse que mantiene
una interacción con el servidor enviando a éste solicitudes SQL y devuelve los resultados
ya sea en pantalla, en un reporte, en un gráfico o alguna otra forma superior de análisis
para el usuario.

Existen diferentes tipos de aplicaciones que dan acceso a dicha información, variando sus
características en función del tipo de utilización requerido. Son de destacar:

• Aplicaciones de usuario final, son un conjunto de herramientas que consultan,
analizan y presentan información orientada a cubrir una necesidad concreta del
negocio. Este conjunto está compuesto como mínimo por una herramienta de
acceso a datos, una hoja de cálculo y una herramienta para generación de
gráficas.

• Herramientas de acceso a datos. Son los clientes del Data Warehouse. En los
casos en los que el Data Warehouse está basado en tecnología de base de datos
relacional, estas herramientas consisten básicamente en un cliente que mantiene
una sesión con el servidor de presentación, gestor de base de datos relacional y
envía una serie de consultas en SQL - Structured Query Language - al servidor.
Existen herramientas de acceso a datos más sofisticadas, que además de realizar
consultas sobre el servidor de presentación, proporcionan la capacidad de
presentar la información en formato gráfico, en informes predefinidos o en otros
tipos de estructuras de alto nivel que faciliten el análisis de la información.

• Herramientas de consulta ad-hoc, son un tipo específico de herramientas de
acceso a datos que facilitan al usuario la generación de sus propias consultas
manipulando directamente representaciones de las tablas y sus relaciones. Cuanto
mayor sea la sofisticación de la herramienta y de su interfaz de usuario, menos

13


conocimientos informáticos específicos para elaborar las consultas que obtienen la
información requerida son necesarios. Las consultas que hace la aplicación al
servidor de los datos se realizan invocando procedimientos almacenados que
están en el servidor y que agilizan notablemente dichas consultas.

• Aplicaciones de análisis avanzado. Las aplicaciones de análisis avanzado son
clientes que acceden al Data Warehouse para obtener información de entrada,
pero que muestran al usuario la información obtenida después de realizar una serie
de transformaciones específicas. Ejemplos de aplicaciones de análisis avanzado
son:

o Modelos predictivos. Utilizan la información almacenada en el Data
Warehouse para predecir el futuro.

o Modelos de clasificación del comportamiento. Clasifican y agrupan la
información contenida en el Data Warehouse.

o Herramientas de Minería de datos - Data Mining.

2.3. Fases y Equipos de trabajo

La construcción del Data Warehouse, empieza con el Planeamiento, Requerimiento,
Análisis, Diseño para continuar con la Construcción, Despliegue y Expansión que este
puede tener en la empresa donde se desearía implementar.

1. Planeamiento: La fase de Planteamiento se compone de:

• Selección de la estrategia de implementación

• Selección de la metodología de desarrollo

• Selección del ámbito de implementación

• Selecciónn del enfoque arquitectónico

• Desarrollo de un programa y del presupuesto de un proyecto

• Desarrollo de escenarios de uso empresarial

• Recopilación de metadatos

Uno de los pasos más importantes consiste en decidir la estrategia de implementación.
La decisión se basa en cómo se llevan a cabo las tareas dentro de la organización. Se

14


debe tener en cuenta la metodología a utilizar, las más conocidas son: Metodo en
Cascada y Metodo Espiral, donde se define el método arquitectónico, el desarrollo del
programa y los escenarios que la empresa va tener cuando se implemente el Data
Warehouse y para ello se define claramente los metadatos.

2. Requerimiento En esta fase describe una especificación precisa de las funciones que
se obtendrán del Data Warehouse, es decir, hay que dejar constancia de las definiciones
que se indican a continuación.

• Definir los requerimientos del propietario

• Definir los requerimientos del arquitecto

• Definir los requerimientos del desarrollo

• Definir los requerimientos de los usuarios finales.

3. Análisis: En esta fase es conveniente convertir los requerimientos agrupados en un
conjunto de especificaciones que puedan apoyar el diseño. En este análisis debe
considerarse tres tipos de especificaciones :

• Especificación de requerimientos de enfoque empresarial que delinean las
fronteras de la información que debe comprender el Data Warehouse. El
enfoque empresarial determinará también la audiencia y sus requerimientos de
información.

• Especificación de requerimientos de fuentes de datos que delinean las
fronteras de información disponible en las fuentes de datos actuales.

• Especificaciones de requerimientos de usuario final y acceso, las cuales
definen cómo se utilizará la información del Data Warehouse. Junto con éstas
se encuentra la especificación de los tipos de herramientas y técnicas que se
usarán.

4. Diseño. En la fase de diseño se encuentran las siguientes dos actividades principales

• Diseño detallado de la arquitectura de datos: Que define como el desarrollo del
modelo físico de datos para la base de datos del Data Warehouse.

• Diseño detallado de la arquitectura de aplicaciones: Es la correspondencia de
los modelos físicos de datos de la fuente de datos con el modelo físico del
Data Warehouse.

15


5. Construcción. En esta fase se realiza la implementación física de los diseños
desarrollados durante la fase de diseño. Las aplicaciones que se necesitan construir son
las siguientes:

• Programas que creen y modifiquen la base de datos para el Data Warehouse.

• Programas que traigan datos de fuentes relacionadas y no relacionadas.

• Programas que realicen transformación de datos.

• Programas que realicen actualización de base de datos

• Programas que efectúen búsquedas en base de datos muy grande

6. Despliegue. Los requerimientos de despliegue para un Data Warehouse son :

• La información contenida en el Data Warehouse debe estar en términos y
lenguajes que comprendan los usuarios ya que ellos no son técnicos.

• Debe existir una necesidad de que la información que proporcione el Data
Warehouse debe de ser precisa para los usuarios finales.

7. Expansión. En esta etapa se prevé algunas de las siguientes áreas de mejora:

• Consultas empresariales que no pueden formularse o satisfacerse debido a la
limitación del Data Warehouse.

• Consultas empresariales que comprenden fuente de datos externas que no
formaron parte de la implementación Inicial

• Desempeño no satisfactorio de componentes del Data Warehouse.

Para obtener el éxito en la construcción de un Data Warehouse se debe desarrollar de
forma gradual, seleccionando a un departamento usuario como piloto y expandiendo
progresivamente el Data Warehouse a los demás usuarios. Por ello es importante elegir un
departamento con pocos usuarios, en el que la necesidad de este tipo de sistemas es muy
alta y se puedan obtener y medir resultados a corto plazo. Podemos describir los equipos de
trabajo involucrados en el planteamiento, desarrollo y mantenimiento de un Data Warehouse
como:

1. Promotor. El promotor es un miembro de la organización en la que se implanta
el Data Warehouse. Es el máximo responsable interno del proyecto. Sus
responsabilidades son:

16


• Participar en la toma de decisiones estratégicas.
• Motivar a los usuarios del Data Warehouse.

2. Equipo central de coordinación del Data Warehouse. El equipo central es el
encargado de realizar el análisis inicial en el que se definirá la arquitectura del
Data Warehouse. Coordina y gestiona el desarrollo de los diferentes Data
Marts. Sus responsabilidades son:

• Definir el alcance del Data Warehouse.
• Definir los requisitos de información para cada Data Mart.
• Definir, publicar y mantener la arquitectura en bus, dimensiones
conformadas, hechos conformados.
• Supervisar la construcción de cada Data Mart para garantizar que siguen la
arquitectura definida.

3. Equipos de desarrollo de Data Marts. Son los encargados de desarrollar los
procesos de extracción de datos, de crear y mantener la base de datos del Data
Warehouse, y de desarrollar la aplicación de generación de informes. Sus
responsabilidades son:

• Diseñar y construir el modelo dimensional siguiendo la arquitectura en bus.
• Diseñar y desarrollar los métodos de extracción de información de los
sistemas legacy.
• Diseñar y desarrollar la aplicación de usuario.

4. Administradores de sistemas legacy. Pertenecientes a la organización, son el
personal a cargo de los sistemas de información de los cuales se extraerán los
datos para el Data Warehouse. Sus responsabilidades son:

• Definir las fuentes de información disponibles para el Data Warehouse.
• Dar acceso a dichas fuentes para permitir la extracción de información.
• Aclarar las dudas acerca del significado real en la organización de los datos
del legacy.

5. Grupos de usuarios de Data Marts. Son los usuarios finales en la
organización, que generarán los informes necesarios para ayuda a la toma de
decisiones estratégicas. Sus responsabilidades son:

• Comunicar sus necesidades de información.
• Generar informes.

17

3.TÉCNICAS PARA LA CONSTRUCCIÓN DE UN DATA WAREHOUSE

18


3. TÉCNICAS PARA LA CONSTRUCCIÓN DE
UN DATA WAREHOUSE

La construcción de un Data Warehouse es una tarea compleja que requiere la utilización de
técnicas muy diversas. Son necesarios conocimentos sobre modelización y almacenamiento
de grandes volúmenes de información para el almacén de datos; sobre estrategias de
extracción, transformación y carga y sobre técnicas de presentación de información al
usuario final.

A lo largo del siguiente capítulo se ofrece una visión general de las técnicas necesarias para
construir adecuadamente un Data Warehouse. En el capítulo Modelado dimensional, se
describen las técnica utilizada para organizar la información contenida en el Data
Warehouse para que esta sea fácil de acceder y el rendimiento de las consultas sea el
mejor posible. En el capítulo Procesos ETL, se describen las técnicas a seguir para extraer,
transformar y cargar los datos contenidos en los sistemas operacionales en el Data
Warehouse. El capítulo Almacenamiento, presenta técnicas de configuración de los
gestores de base de datos para posibilitar el almacenamiento de grandes volúmenes de
datos, así como técnicas de indexación para optimizar el rendimiento de las consultas. Por
último, se describen las técnicas para facilitar a los usuarios el acceso a la información del
Data Warehouse, y los tipos de aplicaciones utilizadas para presentar dicha información.

3.1. Modelado dimensional

El modelado dimensional es una técnica de diseño lógico que presenta los datos de un
modo estandarizado que es intuitivo para los usuarios y proporciona un acceso eficiente a la
información.

La idea principal del modelado dimensional es que prácticamente toda la información de una
organización puede ser representada como un hipercubo de datos de n dimensiones, dónde
cada celda del hipercubo contiene una medición y cada eje del cubo determina una
dimensión de estudio de los datos. En la siguiente figura puede verse la representación de
los datos de un Centro Hospitalario como un cubo tridimensional cuyas dimensiones
representan las diferentes patologías por centro, el motivo de la espera y la fecha en las que
se producen las esperas.

19


Figura 3.1. Hipercubo de datos de 3 dimensiones

Por supuesto, en la mayor parte de los casos tres dimensiones no son suficientes para
aportar la información necesaria. El número de dimensiones de un modelo dimensional
suele variar entre 4 y 15 dimensiones [Kimball98], dependiendo del dominio de estudio. Los
modelos con más de 15 dimensiones suelen tener dimensiones innecesarias que pueden
ser combinadas entre si, dando lugar a un número menor. Los modelos con demasiadas
dimensiones complican en exceso la comprensión de los modelos por los usuarios (en la
práctica es raro encontrar dominios en los que las mediciones estén afectadas por más de
15 variables independientes).

3.1.1. Técnicas básicas de modelado dimensional

Describamos una serie de técnicas estándar utilizadas al desarrollar modelos
dimensionales. Para un estudio más detallado de las técnicas de modelado dimensional
puede encontrarse información en [Kimball96] y [Kimball98].

Tablas de hechos y dimensiones

Los modelos dimensionales utilizan el modelo relacional con importantes restricciones.
Cada modelo dimensional está formado por una tabla con una clave múltiple denominada
tabla de hechos y un conjunto de tablas menores denominadas dimensiones. Cada
dimensión tiene una clave primaria simple que se corresponde exactamente con uno de los
componentes de la clave múltiple de la tabla de hechos, lo que proporciona al modelo su
característico aspecto en estrella.

Como se apuntó en el apartado Data Warehouse, en las tablas de hechos además de la
clave múltiple que representa la relación muchos a muchos entre las dimensiones, existen
atributos (hechos) con valores para cada combinación de las claves que identifican cada

20


registro. Los hechos más útiles en los modelos dimensionales son numéricos y aditivos. La
aditividad es especialmente importante porque a la hora de utilizar la información
almacenada en un Data Warehouse rara vez se accede a los registros de la tabla de hechos
individualmente, sino que el acceso se realiza sobre agrupaciones de datos realizando
operaciones sobre los hechos, generalmente sumas o promedios.

Por el contrario, las dimensiones contienen generalmente información descriptiva en formato
de texto. Los atributos de las dimensiones son la fuente de la mayor parte de las
restricciones aplicadas a las consultas realizadas sobre la información del Data Warehouse,
además de los principales componentes de los resultados. Las dimensiones pueden
considerarse como los puntos de entrada al Data Warehouse. Existen dimensiones en las
que sus atributos se consideran no relevantes, por lo que se eliminan dando lugar a
dimensiones vacías; pero su clave primaria aporta información a la tabla de hechos, por lo
que se incorpara a la tabla de hechos dando lugar a una clave foránea sin dimensión, esto
se conoce como dimensión degenerada – junk.

En la siguiente figura se puede ver un ejemplo sencillo de modelo dimensional:

Figura 3.2 Ejemplo de modelo dimensional

Drill up y Drill down

A la acción de navegar por los datos del Data Warehouse se le conoce con el término inglés
drill, traducido literalmente drill significa taladrar. Por drill down se entiende conseguir
datos con un nivel de detalle mayor, profundizar, es la habilidad para poder navegar de lo
general a lo particular en la información presentada. Por ejemplo, en un informe de ventas

21


en una compañía, se debe poder "taladrar" en los datos de cada región mundial para
obtener los datos por país, y en el total de un país para obtener la información de las
ciudades dentro del país o bien si a partir de un informe de las ventas mensuales de un
producto determinado queremos obtener las ventas diarias de dicho producto, añadiendo a
la consulta el campo fecha de la dimensión tiempo, estaremos realizando una acción de drill
down. Por drill up se entiende lo contrario, conseguir datos con un nivel de detalle menor,
sintetizar, es agregar un dato según una jerarquía de una dimensión, significa ver menos
nivel de detalle, sobre la jerarquía, significa generalizar o sumarizar, es decir, subir en el
árbol jerárquico. Siguiendo el modelo de la figura 3.2, si lo que nos interesa son las ventas
anuales, quitando de la consulta el campo mes de la dimensión tiempo y dejando
únicamente el campo año, estaremos realizando una acción de drill up. Existe otro tipo de
navegación, drill across, que implica la obtención de medidas de diferentes modelos
dimensionales utilizando como enlaces dimensiones comunes, véase los apartados Data
Warehouse y Dimensiones y hechos conformados sobre la arquitectura en bus y las
dimensiones conformadas.

En los modelos dimensionales, los atributos de las dimensiones juegan un papel crucial a la
hora de realizar la navegación. Estos atributos son atributos de texto, o por lo menos se
comportan como atributos de texto, toman valores discretos y son la fuente de las
restricciones en las consultas y las cabeceras de las líneas de resultado de los informes
generados a partir de la información del Data Warehouse. Además, generalmente en las
dimensiones existen una serie de jerarquías que relacionan entre sí a los atributos de la
dimensiones. En el modelo de la figura 3.2 existe una jerarquía en la dimensión tiempo,
compuesta por los atributos Fecha, DiaSemana, Mes, Trimestre y Año. Estas jerarquías son
especialmente útiles para realizar la navegación drill up y drill down de un modo más
intuitivo, de hecho muchas aplicaciones de usuario finales las utilizan para proporcionar
opciones de navegación automática.

Desnormalización

A diferencia de los modelos relacionales, los modelos dimensionales están
desnormalizados. El objetivo de la normalización es, en la mayor parte de los casos,
conseguir un ahorro del espacio ocupado por los datos, no se repiten atributos de texto y
facilitar el mantenimiento y la integridad de los datos, en el ejemplo de la figura 3.3, una
corrección del nombre de una provincia en la dimensión desnormalizada implicaría tantas
actualizaciones como localidades tuviese dicha provincia, mientras que en la dimensión
normalizada implicaría una única actualización en la tabla “Provincia”. En los modelos
dimensionales estas ventajas de la normalización no son excesivamente importantes, ya
que el contenido de los datos de las dimensiones no varía y el espacio ocupado a mayores

22


por la tabla desnormalizada no es significativo en comparación con el tamaño total del Data
Warehouse, en un modelo dimensional, en la mayoría de los casos, la tabla de hechos
ocupa entre el 95 y el 98% del espacio, por lo que no tiene sentido realizar esfuerzos para
conseguir un ahorro en el espacio ocupado por las dimensiones.

Figura 3.3. Dimensión desnormalizada y normalizada

Sin embargo, en una dimensión desnormalizada se puede realizar una navegación más
sencilla para el usuario por los datos contenidos, además de mejorarse el rendimiento de las
consultas al reducirse el número de joins necesarios para obtener la información. Por otra
parte, en las dimensiones desnormalizadas pueden utilizarse unos nuevos tipos de índices,
los índices binarios de los que se habla en el apartado Indexación, que mejoran todavía más
el rendimiento. Por estas razones, en los modelos dimensionales es conveniente no
normalizar las dimensiones.

Por otra parte existe una técnica orientada también al ahorro de espacio conocida como
modelización en copo de nieve – snowflakes - consistente en sustituir los atributos
textuales de baja cardinalidad por claves foráneas de menor tamaño que apunten a tablas
que contengan dichos atributos textuales. Esta técnica tampoco es adecuada para los
modelos dimensionales por la misma razón que no lo es la normalización, aunque está
justificada para casos especiales en los que se puedan mover a la nueva tabla un número
elevado de atributos que no sean utilizados frecuentemente en la navegación (pocos joins
adicionales) y el ahorro de espacio sea considerable, por ejemplo, en dimensiones con un
gran número de datos, como las de clientes de empresas de telefonía que pueden llegar a
tener más de 10 millones de registros, puede ahorrarse una gran cantidad de espacio. La
identificación de estos casos especiales depende del criterio del desarrollador.

23


Claves foráneas, claves primarias y claves subrogadas

Todas las dimensiones poseen claves primarias compuestas por un único campo. Todas
las claves primarias de un Data Warehouse deben ser claves subrogadas sin significado.

La cuestión de si una clave primaria debe ser semántica o no sigue siendo fuente de
discusiones. Una clave semántica, también llamada inteligente, es aquella que tiene
significado por sí misma, independientemente de que sea o no la clave, es decir que el o los
atributos que la conformen contengan valores que describan "realmente" a la entidad
reflejada en la tupla, por ejemplo, los apellidos o el DNI en una relación que denote
personas. Lo contrario, es decir, una clave arbitraria cuya única función es la de identificar la
entidad designada por la tupla, se denomina clave subrogada.

En ningún caso deben utilizarse las claves de los sistemas operacionales ya que no se
puede garantizar que las claves del operacional no vayan a sufrir cambios o que no vayan a
ser reutilizadas, lo que provocaría inconsistencias en la información del Data Warehouse y
además deben utilizarse claves subrogadas cuando sea necesario mantener un histórico de
los cambios en la información de la dimensión.

La estrategia más acertada, a la hora de elegir las claves para las dimensiones del Data
Warehouse, es utilizar un valor entero, que tomará valores desde 1 en adelante para cada
registro de la dimensión. El criterio de asignación de claves a los registros debe ser lo más
sencillo posible, utilizándose generalmente la técnica de asignar las claves de modo
incremental a medida que aparezcan nuevos registros. La clave no debe aportar ningún tipo
de información adicional. Generalmente son suficientes enteros de cuatro bytes para las
claves, ya que pueden contener 232 registros, 2000 millones de enteros positivos
comenzando por el uno, cifra suficiente prácticamente para cualquier dimensión.

La obligatoriedad de utilizar claves subrogadas en las dimensiones afecta incluso a las
dimensiones que representan el tiempo. Es un error muy común utilizar un campo de tipo
fecha, timestamp de SQL, como clave primaria para la dimensión tiempo. En primer lugar el
tipo timestamp ocupa 8 bytes, por lo que se están desperdiciando 4 bytes en cada clave. En
segundo lugar, el único motivo por el que se puede justificar el uso de este tipo de datos es
para realizar las restricciones sobre fechas directamente sobre la clave foránea de la tabla
de hechos, ahorrándose el join con la dimensión tiempo. Este es un ejemplo de utilización
de claves con significado añadido, algo no deseado ya que provoca que parte del
conocimiento resida en las aplicaciones en lugar de en las dimensiones. Por último, la
utilización del tipo de dato timestamp para las claves de la dimensión tiempo, impide la
utilización de registros que representen eventos como “desconocido” o “no ha ocurrido
todavía”. Todas estas cuestiones se resuelven utilizando claves subrogadas. En caso de

24


que además de recogerse información acerca del día en el que ocurre un hecho sea
necesario conocer además el instante exacto en el que se produjo, debe considerarse la
inclusión de un atributo de tipo timestamp en la tabla de hechos que no sea parte de la clave
de la dimensión tiempo, claro ejemplo de dimensiones degeneradas - junk.

Datos históricos

En ocasiones es posible que se produzcan modificaciones en la información de una
dimensión, por ejemplo un cambio en el precio de un producto o la modificación de la
dirección de un cliente. Dependiendo del caso concreto, puede ser necesario mantener la
información antigua para evitar inconsistencias en los datos, una modificación en el precio
de un producto puede producir resultados incorrectos en cálculos existentes si se vuelven a
realizar con el nuevo precio o simplemente para proporcionar una visión de las
modificaciones realizadas. A los datos obsoletos que interesa mantener en las dimensiones
se les denomina datos históricos.

Cuando se producen modificaciones en los datos contenidos en las dimensiones del Data
Warehouse existen tres alternativas a seguir:

1. Sobreescribir la información antigua con la nueva perdiendo, por lo tanto, la
capacidad de realizar análisis con datos históricos.

2. Crear un nuevo registro en la dimensión con la nueva información usando un
nuevo valor de la clave subrogada de la dimensión.

3. Crear un campo “obsoleto” en la dimensión para almacenar la información de la
versión inmediatamente anterior.

La primera alternativa es adecuada para sistemas en los que la información histórica no es
útil y puede ser descartada, o para los casos en los que la modificación sea producto de la
corrección de un error en los datos en lugar de un cambio en la información.

La segunda alternativa es la técnica principal para realizar un seguimiento de los cambios
de la información de una dimensión. Para que esta alternativa sea efectiva, debemos
presuponer que la clave del operacional no varía, por lo que es posible obtener las
diferentes versiones del dato a partir de ella. Es imprescindible además el uso de claves
subrogadas en la dimensión. En ocasiones puede ser adecuado añadir a la dimensión dos
atributos temporales que representen las fecha de inicio y de fin de validez del registro,
nótese que la fecha de fin de validez de un registro debe coincidir con la fecha de inicio de
validez del siguiente registro en el tiempo, y que el registro más reciente tendrá valor nulo
en su fecha de fin de validez. La segunda alternativa es adecuada para situaciones en las
que sea necesario mantener una copia de cada versión de la información cada vez que se

25


produce un cambio. Cada diferente valor de la clave sorrogada representa una versión única
de la información asociada a, por ejemplo, un producto o un cliente, en un período de
tiempo determinado.

Por último, la tercera alternativa es adecuada para situaciones en las que es necesario tener
un cierto conocimiento acerca de valores anteriores de la información, pero sin llegar a
requerir un nivel de detalle tan exacto como el proporcionado por la segunda alternativa.
También es adecuada para situaciones en las que no puede realizarse una separación
disjunta de las diferentes versiones, debido a que es necesario utilizar simultáneamente la
información antigua y la nueva en el mismo registro.

Hechos aditivos, semiaditivos y no aditivos

Siempre que sea posible, deben elegirse hechos para la tabla de hechos que sean
perfectamente aditivos. Esto significa que los hechos pueden ser sumados al realizar
estudios sobre cualquier dimensión del modelo. Las medidas numéricas como el beneficio
de una venta o unidades vendidas son generalmente aditivas. Sin embargo, otros tipo de
medidas numéricas suelen no serlo. Este es el caso de mediciones de intensidad, como el
estado de cuentas bancarias o de niveles de inventarios. Estas mediciones son
instantáneas de una situación en un momento determinado de tiempo, y no representan un
flujo de eventos a lo largo del tiempo. Por lo tanto, este tipo de medidas son sumables a lo
largo de todas las dimensiones excepto el tiempo, en cuyo caso debe realizarse un
promedio dividiendo la suma entre el número de resultados de cada periodo de estudio, no
es lo mismo que utilizar la función AVG de SQL, que divide entre el número total de
resultados. A los hechos que son aditivos sólo para un subconjunto de las dimensiones se
les denomina hechos semiaditivos.

Existen casos en los que las mediciones no pueden ser sumadas independientemente de la
dimensión de estudio. A estos hechos se les llama hechos no aditivos. Un ejemplo de
hecho no aditivo es la medición de la temperatura de diferentes habitaciones, ya que
siempre es necesario realizar un promedio de los resultados. En los hechos no aditivos sí
que es adecuado el uso de la función AVG de SQL.

Tablas de hechos sin hechos

En ocasiones a la hora de realizar un modelo dimensional no es posible identificar ningún
hecho en la tabla de hechos, por lo que ésta está compuesta únicamente por las claves
foráneas a las dimensiones. A pesar de que las tablas de hechos sin hechos no contienen
información de ninguna medición, son especialmente útiles para describir eventos, por
ejemplo la puesta en oferta de un producto en un periodo de tiempo, controles de asistencia,
etc..., de modo que podamos obtener información acerca de lo que ha o no ha ocurrido.

26


Figura 3.4. Modelo con tabla de hechos sin hechos

Por ejemplo, en un modelo dimensional de ventas de productos como el de la figura 3.2,
podemos conocer qué productos se han vendido en una tienda un día determinado, pero no
qué productos no se han vendido ya que si no se produce una venta no se introduce
información en la tabla de hechos de ventas. Por esta razón no podremos dar respuesta a
preguntas como qué productos puestos en oferta en una tienda en un día concreto no se
han vendido. Para dar respuesta a esta situación, se puede crear una nueva tabla de
hechos en la que se indiquen qué productos están en oferta en cada tienda cada día, dando
lugar a un modelo como el de la figura 3.4, como se puede observar, la tabla de hechos de
la figura no tiene ningún hecho, sólo está compuesta por las claves foráneas a las
dimensiones “Tiempo”, “Tienda”, “Producto” y “Oferta”. Sin embargo, a partir de la
información contenida en la estrella de la figura 3.4 podemos conocer qué productos están
en oferta en una tienda un día determinado, y si a ese conjunto de productos le restamos los
productos vendidos, información obtenida de la estrella de la figura 3.2, obtenemos
respuesta a la pregunta de qué productos en oferta no se han vendido.

3.1.2. Dimensiones y hechos conformados

El objetivo de la primera fase de la construcción del Data Warehouse es definir la
arquitectura en bus descrita en el apartado Data Warehouse, estableciendo un conjunto de
dimensiones conformadas y estandarizando el modo de definir los hechos. Las dimensiones
conformadas son dimensiones con el mismo significado independientemente de la tabla de
hechos a la que estén asociadas. En general esto significa que una dimensión
conformada es exactamente la misma dimensión en cada Data Mart. Ejemplos típicos de
dimensiones conformadas son cliente, producto, tiempo o una dimensión geográfica.

27


La elección y la definición de las dimensiones conformadas son tareas clave en la
construcción del Data Warehouse. Si una dimensión como tiempo se utiliza con una
definición o significado diferente en distintos Data Marts, éstos no podrán ser utilizados
conjuntamente, o lo que es peor, podrían obtenerse resultados incorrectos en caso de que
dichos Data Marts fuesen utilizados conjuntamente. La utilización adecuada de las
dimensiones conformadas proporciona las siguientes ventajas:

• Una única tabla de dimensión puede ser utilizada por varias tablas de hechos en la
misma base de datos.

• El interfaz de usuario y los datos obtenidos son consistentes independientemente
de dónde se esté utilizando la dimensión.

• Existe una interpretación única de cada atributo de la dimensión, por lo que es
posible combinar información de diferentes Data Marts a través de las dimensiones
conformadas, drill across.

A la hora de diseñar las dimensiones conformadas se debe tener un cuidado especial al
elegir el nivel de detalle. Hay que tener en cuenta que las dimensiones conformadas serán
utilizadas por todo el sistema y por ello aunque en un principio pueda parecer adecuado
definir cierto nivel de detalle (por ejemplo definir semanas como la unidad mínima de
información en la dimensión tiempo) esto puede impedir que el sistema crezca si aparecen
nuevas necesidades de información con un nivel de detalle mayor, continuando el ejemplo
anterior, no se podría añadir al sistema un Data Mart que necesitase diferenciar hechos a
nivel de días en lugar de semanas. Por esta razón es recomendable que las dimensiones
conformadas tengan el máximo nivel de detalle posible, atómico.

En ciertos casos las diferencias existentes entre las distintas divisiones de una organización
dificultan la definición de las dimensiones conformadas. Por ejemplo, una organización con
varias líneas de negocio puede necesitar definiciones muy diferentes de dimensiones como
cliente o producto. Una posible solución a esta situación es agrupar todos los atributos
necesarios para cada línea de negocio en la dimensión conformada, aunque no es deseable
porque provocaría una excesiva "diagonalización" de la dimensión al tener cada elemento
información únicamente para los atributos de la línea de negocio a la que pertenece. La
técnica recomendada cuando se da esta situación de heterogeneidad es determinar los
atributos comunes de las líneas de negocio y crear con ellos la dimensión conformada,
dejando los atributos específicos para dimensiones separadas. De este modo se conservan
las ventajas del uso de dimensiones conformadas y se evita la diagonalización de la
dimensión.

28


Si además de existir diferencias notables en la definición de las dimensiones existen
diferencias en los contenidos, por ejemplo si el conjunto de individuos almacenados en la
dimensión cliente es distinto en función de la línea de negocio, deja de ser conveniente el
uso de las dimensiones conformadas, ya que no se podría aprovechar ninguna de sus
ventajas. En tal caso, lo recomendable es intentar encontrar nombres claramente
diferenciados para cada una de las dimensiones, de forma que no lleve a equívocos.

En resumen, las dimensiones conformadas deben:

• Tener igual significado en todos los Data Marts.

• Estar definidas al nivel de detalle más alto (atómico).

• Tener una clave subrogada.

• Estar desnormalizadas.

Las dimensiones conformadas no deben:

• Estar demasiado diagonalizadas.

• Representar conjuntos de datos disjuntos para cada línea de negocio.

Para garantizar la coherencia de los datos obtenidos al extraer información de varios Data
Marts es necesario, además de la utilización de dimensiones conformadas, establecer un
criterio común en la definición de los atributos de las tablas de hechos. De esta forma se
consigue que un mismo hecho, por ejemplo beneficio o precio, esté definido de la misma
forma en todos los Data Marts, evitándose situaciones como, por ejemplo, la comparación
de un precio almacenado con IVA en un Data Mart y sin IVA en otro.

3.2. Procesos ETL.

Una de las partes más importantes en un Data Warehouse y la que consume más tiempo y
recursos en el desarrollo de los sistemas, es el área de extracción de datos. Los procesos
ETL son los encargados de trasladar la información desde los sistemas operacionales hasta
el Data Warehouse

29


Figura 3.5 Esquema de los procesos ETL

Las tareas llevadas a cabo por los procesos ETL pueden verse esquematizadas en la figura
3.5 y son:

• Extracción. La extracción es el primer paso para obtener la información que será
introducida en el Data Warehouse. Para realizar la extracción de la información
deben conocerse y comprenderse los orígenes de datos, y copiar los datos
necesarios para procesarlos en las siguientes etapas de la carga.

• Transformación. Una vez extraídos los datos existen diferentes tipos de
transformaciones posibles sobre ellos:

• Corrección de errores en los datos, por ejemplo, errores tipográficos al
introducir los datos, introducción de datos ausentes, y el parseado de los datos
para adecuarlos a formatos estándar.

• Combinación de fuentes de datos mediante búsquedas exactas por atributos
clave o por búsquedas difusas a partir de atributos que no son claves. Estas
búsquedas de información se conocen como look up.

• Creación de claves subrogadas para cada registro de las dimensiones para
eliminar las dependencias con las claves de los sistemas operacionales. La
creación de claves subrogadas debe garantizar la integridad referencial entre
las tablas de hechos y las dimensiones.

• Construcción de agregados para acelerar el rendimiento de consultas
comunes.

• Carga e indexado. Una vez finalizado el proceso de transformación, los datos
tienen el formato adecuado para ser introducidos en el Data Warehouse. La carga
de los datos debe realizarse mediante procesos especiales para grandes
volúmenes de datos, mucho más eficientes que las cargas registro a registro. Una

30


vez introducida la información en el Data Mart correspondiente, deben generarse los
índices que permitirán acelerar las consultas sobre el Data Warehouse.

• Control de calidad. Una vez que se han cargado todos los datos y creados los
índices y los agregados en cada Data Mart, antes de hacer accesible la información
a los usuarios debe asegurarse la calidad de la información introducida.

3.2.1. Técnicas básicas de los procesos ETL.

A continuación se describen una serie de técnicas básicas empleadas por los procesos ETL.
Para un estudio más detallado de las técnicas de los procesos ETL puede encontrarse
información en [Kimball96] y [Kimball98].

Servicios de extracción

Obtener los datos de los sistemas operacionales es probablemente la tarea que más
esfuerzo requiere a la hora de construir un Data Warehouse, especialmente si los sistemas
operacionales son antiguos y no están bien documentados. El reto a la hora de implementar
los procesos de extracción es determinar qué información extraer y cómo filtrarla. Es
fundamental tener un conocimiento en profundidad de los sistemas operacionales y de sus
peculiaridades, ya que es común la presencia de campos de tablas en los que se almacena
información de naturaleza cambiante o que no exista integridad referencial en las
relaciones.

La mayor parte de los procesos de extracción generan archivos temporales de carga que se
convierten en la entrada de la siguiente etapa de procesamiento. Generalmente la
información se obtiene a partir de los sistemas legacy y se proporciona en un formato
simplificado y fácilmente accesible. A continuación se describen los requisitos
fundamentales que deben cumplir los procesos de extracción:

• Fuentes Múltiples. Los procesos de extracción deben estar preparados para poder
acceder a múltiples fuentes de información, ya que la mayoría de los Data Warehouses
obtienen sus datos de más de una fuente de información. Esto implica que los procesos
deben acceder a diferentes sistemas con diferentes sistemas de almacenamiento de
información, diferentes sistemas operativos y diferentes protocolos de comunicaciones.

• Desacoples. Para afectar lo menos posible al rendimiento del operacional durante las
extracciones, es conveniente poder extraer los datos a un sistema de almacenamiento
temporal para no tener que acceder de nuevo al operacional en caso de tener que
repetirse la carga.

31


• Múltiples tipos de extracción. Los procesos de extracción deben permitir realizar los
siguientes tipos de extracción, dependiendo de las necesidades a la hora de construir el
Data Warehouse:

• Cargas incrementales. Las cargas de datos se realizan periodicamente, y en cada
carga sólo es preciso obtener información de los datos nuevos o que han sido
modificados.

• Seguimiento de transacciones. En los casos en los que no es posible conocer de
modo simple qué datos han sido cargados o modificados desde que se realizó la
última carga, es necesario dotar al sistema de capacidad para identificar los
distintos tipos de transacciones para detectar qué información debe ser procesada.

• Cargas completas. Cuando la identificación de las modificaciones es demasiado
costosa o simplemente no es posible, la información del sistema operacional debe
ser recargada en su totalidad.

• Compresión / Descompresión. La compresión de la información es una tarea
especialmente importante cuando los archivos temporales de carga tienen un tamaño
elevado. De no comprimirse los datos, los canales de comunicación pueden convertirse
en un cuello de botella.

Servicios de transformación de datos

Una vez que han sido extraídos los datos de los sistemas operacionales, se ven sometidos
a una serie de transformaciones para convertirlos en información presentable a los usuarios.
A continuación se describen los tipos de transformación más comunes a los que son
sometidos los datos de los sistemas operacionales:

• Integración. La integración implica la generación de claves subrogadas, relacionar las
claves de los diferentes sistemas, y añadir a los códigos sus descripciones
correspondientes.

• Seguimiento de cambios. Deben identificarse los datos que han sido modificados en
las dimensiones en las que interese mantener información histórica, y generar los
nuevos registros con nuevas claves subrogadas cuando sea necesario.

• Comprobación de integridad referencial. A pesar de que la integridad referencial
puede comprobarse a nivel de base de datos, es conveniente realizar las
comprobaciones oportunas durante las cargas y almacenar en ficheros de log aquellos

32


registros que no hayan podido ser incluidos en el Data Warehouse por no estar sus
claves presentes en las tablas necesarias.

• Desnormalización y normalización. La desnormalización de una jerarquía de tablas
separadas en una única dimensión es una transformación estándar en el entorno de
Data Warehousing. En ocasiones también es necesario normalizar información obtenida
de los sistemas operacionales, esto sucede por ejemplo cuando se obtiene la
información de las ventas mensuales de un año en un único registro con doce campos.

• Conversión de tipos de datos. Transformaciones a bajo nivel para homogeneizar los
formatos de las diferentes fuentes de información, por ejemplo de EBCDIC a ASCII.

• Cálculo, derivación y distribución. Estos tipos de transformaciones se realizan a partir
de reglas de negocio identificadas en la toma de requisitos del Data Warehouse. Un
ejemplo puede ser la combinación de los datos del nombre de un cliente, nombre,
primer apellido y segundo apellido, para presentarlos de modo estándar, primero los
apellidos seguidos de una coma, un espacio y el nombre, con la primera letra de cada
nombre en letras mayúsculas y el resto en minúsculas.

• Auditoría del contenido de los datos. Debe comprobarse que la información obtenida
de los sistemas operacionales es correcta, corrección de errores tipográficos, de errores
de formato en la entrada, de errores en las unidades de las medidas etc...

• Valores nulos. La ausencia de información en los campos de los sistemas
operacionales puede estar representada de modos muy diversos, generalmente
mediante la utilización de valores que no suelen ocurrir en la realidad y a los que se les
da un significado especial, por ejemplo 9/9/9999 para representar una fecha
desconocida. Este tipo de información no es aceptable para la presentación al usuario
ya que puede inducir a errores, por lo que deben modificarse estos valores especiales
por otro tipo de información comprensible para los usuarios y estandarizada en el Data
Warehouse, por ejemplo utilizando un registro específico con descripción
“Desconocido”.

Servicios de carga de datos

Las funcionalidades requeridas para la carga de datos dependen del sistema de
almacenamiento elegido, generalmente del gestor de base de datos utilizado. Las más
importantes son:

33


• Múltiples destinos. El Data Warehouse puede estar formado por varios Data Marts que
no tienen por que estar almacenados en el mismo sistema. Los procesos de carga
deben tener en cuenta las peculiaridades de los sistemas que albergan cada uno de los
Data Marts a la hora de realizar las cargas.

• Optimización de las cargas. Deben utilizarse los métodos optimizados para cargas de
grandes volúmenes de información que proporcionan la mayor parte de los gestores de
bases de datos relacionales, cada gestor usa sus propias técnicas. Además, para
mejorar el rendimiento de las cargas deben desactivarse las opciones de generación de
log y de actualización de índices, es mucho más rápido reconstruir los índices una vez
finalizada la carga que permitir que se actualicen a medida que se va introduciendo
nueva información.

3.2.2. Control de procesos ETL.

El proceso completo de extracción, transformación y carga de datos de los sistemas
operacionales al Data Warehouse debe ser controlado, en la medida de los posible,
mediante una entorno de aplicaciones de monitorización sencillo y basado en metadatos.
Este entorno de aplicaciones puede ser desde un simple conjuntos de procedimientos
almacenados en SQL hasta una compleja aplicación que integre todas las fuentes de datos,
aunque sean heterogéneas y facilite la elaboración y ejecución de los procesos ETL.

En la figura 3.6 puede verse un ejemplo de entorno gráfico comercial que permite acceder a
múltiples fuentes de información, y definir y controlar la ejecución de los procesos ETL de un
modo gráfico.

Independientemente de las herramientas utilizadas para controlar la ejecución de los
procesos ETL, deben proporcionarse las siguientes funcionalidades:

• Definición de trabajos. En primer lugar deben definirse las dependencias entre los
diferentes procesos involucrados en el proceso global de carga, y el orden en que
deben ser ejecutados.

• Planificación de trabajos. Como mínimo deben proporcionarse servicios de
planificación temporales, por ejemplo realizar la carga de los hechos todas las noches y
basados en eventos, por ejemplo realizar la carga de los datos de una dimensión en
cuanto estén disponibles los ficheros necesarios.

34


• Monitorización. La ejecución de procesos de carga no debe ser una caja negra. Deben
proporcionarse datos en todo momento que indiquen lo que está sucediendo y el
progreso de la carga, en qué momento se inició, en que etapa de la carga se encuentra,
cuanto está previsto que tarde en finalizar, etc...

• Generación de logs. En los logs debe incluirse información acerca del proceso de
carga al completo, no sólo de lo que ocurre en cada momento. A partir de la información
de los logs debe ser posible recuperar o reiniciar la ejecución de un trabajo de modo
controlado en caso de que se produjesen errores. Como mínimo, los logs deben
almacenarse en ficheros de texto, aunque es preferible la utilización de una base de
datos para proporcionar a mayores la capacidad de generar gráficos e informes que
permitan analizar los rendimientos y optimizar los procesos de carga.

• Control de errores y excepciones. La calidad de los datos de los sistemas de
operaciones no siempre es todo lo buena que cabría desear. En algún punto de una
carga, puede recibirse un dato con un formato incorrecto o que no cumpla las
restricciones de integridad referencial. El sistema necesita saber cómo actuar ante este
tipo de situaciones, dónde almacenar la información incorrecta, limitar el número de
errores permitidos en una ejecución y proporcionar un modo de finalizar los procesos de
un modo controlado aunque se produzcan errores.

Figura 3.6. Entorno de desarrollo y ejecución de procesos ETL. Oracle Warehouse Builder.

3.3. Almacenamiento

La gran mayoría de las técnicas empleadas para optimizar el espacio ocupado y el
rendimiento de las cargas y las consultas de información del Data Warehouse varían en
función del gestor de base de datos utilizado. Sin embargo, existen una serie de
consideraciones a tener en cuenta que no dependen del software de almacenamiento
utilizado: la indexación y la construcción de agregados. La utilización de ambas técnicas,

35


descritas en los siguientes apartados, mejoran el rendimiento pero suponen un gasto
adicional de espacio en disco, por lo que deben emplearse siempre teniendo en cuenta la
relación entre el coste y el beneficio de la construcción de un índice o un agregado en cada
caso. Adicionalmente, deben tenerse en cuenta los siguientes puntos:

• Elección de tipos de datos adecuados. La correcta definición de los tipos de datos de
las tablas del Data Warehouse puede ahorrar grandes cantidades de espacio en disco.
Es especialmente importante, por su impacto final en el espacio ocupado, una elección
cuidadosa de la longitud de los campos de texto en dimensiones con un gran número de
registros y en los tipos de datos de las claves primarias de las dimensiones por su
inclusión en las claves de las tablas de hechos.

• Realización de estimaciones de volumen. Una correcta estimación del espacio
ocupado por los datos cargados a lo largo del tiempo permite dimensionar
adecuadamente el gestor de base de datos y el disco necesario, evitando problemas
posteriores.

• Optimización de cargas. Independientemente del gestor de base datos utilizado, las
cargas de información deben realizarse siempre con todas las restricciones de
integridad desactivadas, sin registros de transacción, redo logs y sin actualizar los
índices existentes, de modo que cada inserción de datos implique el menor número de
comprobaciones posibles para ser más rápidas. En el caso de las restricciones de
integridad serán activadas una vez finalizada la carga, comprobándose a posteriori la
validez de la información introducida. En cuanto a los registros de transacción no son
necesarios, ya que se dispone de la información original en el sistema operacional. Los
índices serán recalculados una vez finalizada la carga, ya que es más rápido recalcular
un índice para toda una tabla que cada vez que se realiza una modificación en su
contenido.

3.3.1. Indexación

Un índice es una estructura de memoria secundaria que permite el acceso directo a las filas
de una tabla. Si bien es cierto que los índices aceleran las operaciones de consulta, también
debe tomarse en cuenta que el mantenimiento de un índice tiene efecto sobre el
rendimiento de las operaciones de eliminación, inserción y actualización ya que es doble el
trabajo de manipulación de bloques de datos, debe almacenarse información en los bloques
de datos de una tabla y de los diferentes índices sobre ella definidos. El objetivo de la
indexación de los campos de las tablas del Data Warehouse es mejorar el rendimiento de

36


las consultas. En los Data Warehouses se utilizan dos tipos diferentes de índices: los
índices bitmap, también llamados binarios y los índices en árbol-B.

Índices en árbol-B

Los índices en árbol-B son índices organizados en una estructura de datos en árbol. El nivel
inferior del árbol contiene los valores reales del campo indexado, con apuntadores a las filas
de la tabla correspondiente, ROWIDs y al siguiente nivel del árbol. Al nivel inferior se le
denomina conjunto secuencia. Los niveles superiores, denominados conjunto índice,
proporcionan un acceso eficiente a las diferentes partes del conjunto secuencia. Puede
encontrarse información sobre la estuctura de los índices en árbol-B y las técnicas para su
construcción y mantenimiento en [Date93]. En la siguiente figura puede verse un ejemplo
sencillo de índice en árbol-B.

Figura 3.7. Índice en árbol-B con t = 3

En general, los índices en árbol-B se utilizan para mejorar el rendimiento de consultas que
recuperan un número pequeño de filas. Este tipo de consultas se realizan de un modo más
rápido buscando los registros en el índice que realizando una búsqueda sobre la tabla
completa. Sin embargo, la mayoría de las consultas de un Data Warehouse recuperan un
gran número de filas para después realizar operaciones de agregación, de modo que los
beneficios de la utilización de índices en árbol-B en ocasiones son escasos, especialmente
para las tablas de hechos.

Índices bitmap

Un índice bitmap está organizado como un B*-Tree, pero la estructura de los nodos hoja
cambia para almacenar un bitmap definido sobre los valores de la clave en lugar de
ROWIDs. Cada bit en el bitmap corresponde a un posible ROWID, si el bit está encendido,
significa que el ROWID en cuestión posee el valor indicado para la clave. Los índices

37


bitmap, mapa de bits, se utilizan ampliamente en los sistemas de Data Warehouse,
proporcionando:

• Reducción el tiempo de respuesta en consultas sobre grandes tablas.

• Reducción del espacio ocupado por el índice, en comparación con otras técnicas de
indexación.

• Grandes mejoras de rendimiento incluso en sistemas con relativamente poca
memoria o número de procesadores.

• Mantenimiento eficiente durante cargas de datos.

En los índices bitmap, cada fila de la tabla lleva asociado un grupo de bits en los que cada
bit representa un valor posible del campo indexado. Cuando un bit está activado significa
que el registro correspondiente contiene el valor representado por el bit. Por lo tanto la
estructura de los índices bitmap consiste en una matriz de ceros y unos en la que cada fila
corresponde con un único registo de la tabla y cada columna con un posible valor del
campo. Como la matriz tendrá tantas columnas como valores posibles tome el campo
indexado, el tamaño del índice será menor cuanto menor sea el número de valores. Una
función convierte cada fila de la matriz en un identificador de fila de la tabla real, rowid,
proporcionándose por lo tanto la misma funcionalidad que con los índices convencionales.

La mayor eficacia de los índices bitmap se consigue para consultas con varias condiciones
en la cláusula WHERE de la consulta. Las condiciones AND y OR de la cláusula WHERE
pueden ser resueltas rápidamente realizando las operaciones booleanas correspondientes
directamente sobre los mapas de bits antes de realizar la conversión del mapa de bits en
identificadores de filas. Así, las filas que cumplen sólo alguna de las condiciones de la
cláusula, son filtradas antes de acceder a los datos de la tabla, lo que mejora enormemente
los tiempo de respuesta.

Tomemos la dimensión Oferta del modelo dimensional de la figura 3.4 para proporcionar un
ejemplo del funcionamiento de los índices bitmap. A continuación se muestran algunos de
los valores que podrían estar contenidos en la dimensión:

pkOferta Tipo Descuento TipoAnuncio
101 A 15% Prensa
102 B 17% TV
103 B 20% Prensa
104 A 10% Carteles
105 A 12% Carteles

Tanto el campo “Tipo” como el campo “TipoAnuncio” de la tabla ejemplo son campos de
baja cardinalidad, dos valores distintos en el caso de “Tipo” y tres en el de “TipoAnuncio”.

38


Ambos campos son, por lo tanto, buenos candidatos para ser indexados con un índice
bitmap. En la siguiente tabla se muestra cómo sería un índice bitmap para el campo
“TipoAnuncio”:

TipoAnuncio = TipoAnuncio = ’TV’ TipoAnuncio =
‘Prensa’ ‘Carteles’
1 0 0
0 1 0
1 0 0
0 0 1
0 0 1

Cada bit del índice corresponde a una única fila de la dimensión Oferta. El valor de cada bit
depende del valor del campo en la fila correspondiente de la dimensión. Por ejemplo, la
columna “TipoAnuncio = ‘TV’” tiene un uno en la segunda fila y ceros en las restantes, ya
que sólo la segunda fila de la dimensión toma el valor “TV” en el campo “TipoAnuncio”.

Si fuese necesario dar respuesta a una pregunta del tipo “¿cuántos productos en oferta se
han vendido que hayan sido anunciados en prensa o carteles?”, se realizarían las siguientes
operaciones sobre el índice para obtener el conjunto resultado:

TipoAnuncio = TipoAnuncio =
‘Prensa’ ‘Carteles’
1 0 1
0 0 0
1 0 1
OR =
0 1 1
0 1 1

Comparativa entre índices bitmap e índices en árbol-B

El mejor rendimiento con índices bitmap se obtiene cuando:

• las columnas indexadas tienen baja cardinalidad, es decir, columnas en las que el
número de valores diferentes que pueden tomar es bajo en comparación con el
número de filas de la tabla. Una columna para representar el género, que sólo toma
dos valores diferentes, hombre o mujer, es ideal para un índice bitmap. Sin
embargo es posible la utilización de índices bitmap en columnas con cardinalidades
mucho mayores, alcanzando buen rendimiento con una cardinalidad entre 10.000 y
20.000 valores para tablas de un millón de registros. Un índice bitmap en dicha
columna puede ofrecer un rendimiento mucho mejor que el de un índice en árbol-B,
especialmente si las consultas tienen restricciones sobre otras columnas.

• muy eficientes para predicados OR y AND

Los índices en árbol-B son eficaces para:

39


• columnas con alta cardinalidad, es decir, columnas que contienen muchos valores
diferentes como por ejemplo “Nombre de cliente” o “Número de teléfono”.

• Cuando se accedan a consultas de no más del 10-15% de las filas de la tabla

En un Data Warehouse los índices en árbol-B deben ser utilizados sólo en columnas con
valores únicos, claves candidatas o con cardinalidades muy altas, en las que prácticamente
todos los valores son diferentes. La mayor parte de los índices de un Data Warehouse
deben ser índices bitmap.

3.3.2. Agregados

La manera más sencilla y más efectiva de mejorar el rendimiento de un modo notable en un
Data Warehouse con grandes volúmenes de datos es proporcionar un conjunto adecuado
de tablas agregadas que coexistan con las tablas de hechos principales. Las tablas
agregadas son tablas con un grano de información más grueso que las tablas de hechos, y
que permiten acceder a los resultados de ciertas operaciones de un modo inmediato. Estas
tablas deben ser recalculadas después de cada carga de datos.

Por ejemplo, en el modelo dimensional de la figura 3.2 el grano de la tabla de hechos es una
venta individual, pero supongamos que en la organización son frecuentes los análisis que
utilizan información acerca de las ventas totales diarias de cada tienda. Para ello es
necesario acceder a todas las ventas de cada tienda y sumar las ventas de cada día, lo que
para grandes volúmenes de información se convierte en una tarea muy costosa. Para
acelerar el proceso es posible crear una tabla de hechos en la que se almacenen los
resultados requeridos, siendo el grano de la nueva tabla las ventas totales por tienda y por
día. Acceder a la información a través de la nueva tabla es una tarea mucho menos costosa,
ya que se accede a un número mucho menor de filas. Esta nueva tabla es un ejemplo de
tabla agregada.

En un Data Warehouse bien diseñado debe proporcionarse un conjunto de tablas
agregadas que representen niveles de agregación comunmente utilizados en los análisis de
información de la organización. Qué niveles de agregación y sobre qué atributos de las
dimensiones deben ser realizados es una cuestión de diseño y depende únicamente del
modo en que se utilice la información en la organización. El conjunto de tablas agregadas es
variable, debido a los cambios que se producen en las necesidades de información de la
organización algunas tablas agregadas pueden dejar de ser necesarias y puede requerirse
la definición de otras nuevas.

40


La utilización de agregados debe ser transparente al usuario, para no complicar la
accesibilidad de la información. Para que esto sea posible debe añadirse al Data
Warehouse un componente software llamado navegador de agregados, que a partir de las
consultas SQL producidas por los usuarios o las aplicaciones pueda determinar si existe
algún agregado que contenga la información requerida, y en caso afirmativo reescribir la
consulta para que utilice la información agregada. De este modo los usuarios no sabrán si la
información obtenida proviene de la tabla de hechos original o de una tabla agregada,
aunque experimentarán unos tiempos de respuesta mucho menores.

3.4. Presentación.

La capa de presentación de un Data Warehouse es el conjunto de aplicaciones que dan a
los usuarios acceso a la información almacenada. A pesar de que los modelos
dimensionales reducen la complejidad de la información, para obtener y manejar la
información de un modo eficiente los usuarios necesitan herramientas que les faciliten estas
tareas. A continuación se describen algunas de las técnicas de análisis de información y las
características de las herramientas utilizadas.

3.4.1. Análisis de la información del Data Warehouse.

El objetivo final de un Data Warehouse es obtener información que proporcione a los
usuarios conocimiento sobre su organización. Para ello no es suficiente extraer los datos del
Data Warehouse y presentar los resultados a los usuarios, si no que además deben
proporcionarse capacidades de análisis, drill up, drill down, ordenaciones, etc...

La obtención de la información mediante consultas SQL no proporciona todas las
funcionalidades de análisis necesarias. Por ejemplo, no es posible definir una consulta SQL
que, a partir del modelo de la figura 3.2, proporcione información acerca de las ventas de
cada tienda ordenadas por volumen de beneficios, no es posible realizar ordenaciones en
SQL sobre los resultados de funciones de agregación, la función SUM en el caso del cálculo
del volumen de beneficios. Por lo tanto, para determinar en el ejemplo anterior qué tienda ha
sido la que más beneficios ha dado, sería necesario obtener un listado de los beneficios de
todas las tiendas y buscar de algún modo la que tenga un valor mayor. Existen dos
alternativas para conseguir esto:

• Presentar la información a través de una aplicación que tenga la capacidad de realizar
operaciones sobre los datos obtenidos mediante SQL estándar. La aplicación podría,

41


por ejemplo, realizar una ordenación mediante el algoritmo quick sort sobre los datos
obtenidos y presentar el resultado.

• Utilizar extensiones específicas de SQL que proporcionen las capacidades de análisis
necesarias a la hora de obtener la información.

Cualquiera de las dos alternativas es adecuada, aunque la más utilizada es la utilización de
herramientas para manipular la información obtenida. En el apartado Herramientas de
acceso a la información., se describen las funcionalidades de este tipo de herramientas. En
cuanto a las extensiones de SQL, no existe un conjunto de funciones estandar, y dependen
del gestor de base de datos utilizado. Oracle es probablemente el gestor que a día de hoy
proporciona un conjunto de extensiones de SQL más amplio, entre las que destacan
[Lane99]:

• Cube y rollup. Las funciones cube y rollup amplían las capacidades de funcionamiento
de la cláusula GROUP BY, añadiendo filas con subtotales al conjunto de filas resultado
de una consulta agrupada, para facilitar las acciones de drill up y drill down.

• Rank. La función rank permite ordenar los resultados de una consulta por un campo
calculado a partir de una función de agregación, SUM, AVG, MAX, MIN, etc... Mediante
el uso de esta función se resolvería el problema de la ordenación del listado por
volumen de beneficios descrito anteriormente.

• TOP_N y BOTTOM_N. Las funciones TOP_N y BOTTOM_N, combinadas con la
función rank, permiten obtener sólo los n primeros o los n últimos elementos del
resultado de la consulta. Son especialmente útiles para dar respuesta a preguntas del
tipo: ¿cuáles han sido las cinco tiendas con menos beneficios? o ¿cuáles han sido los
diez productos más vendidos?

3.4.2. Herramientas de acceso a la información.

Las herramientas de acceso a la información son el conjunto de aplicaciones que permiten a
los usuarios obtener información del Data Warehouse. Existen diferentes tipos de
aplicaciones, desde herramientas que proporcionan una visión navegable de la información
de la organización hasta herramientas de generación de informes, aunque las más
utilizadas son las herramientas de consulta ad hoc debido a su mayor flexibilidad y
adaptabilidad a nuevas necesidades de información.

42


Las herramientas de consulta ad hoc proporcionan funcionalidades de exploración
interactiva de los datos. Además, proporcionan una serie de funcionalidades que permiten
compensar las deficiencias de los lenguajes de extracción de datos como SQL a la hora de
realizar análisis de información. A continuación se describen una serie de funcionalidades
que deben proporcionar las herramientas de consulta:

Formulación de consultas

La principal tarea de las herramientas de consulta ad hoc es, como su nombre indica, la
formulación de consultas. La formulación automática de consultas es una tarea que se
complica por la evolución de los estándares de SQL para permitir consultas cada vez más
complejas. Deben incluirse las siguientes capacidades a la hora de generar las consultas:

• SQL Múltiple. Para realizar comparaciones o para calcular correctamente medidas no
aditivas en informes, la herramienta debe poder descomponer la consulta en varias
consultas más simples que se enviarán por separado al gestor de base de datos. La
herramienta combinará automáticamente los resultados de las diferentes consultas. El
SQL múltiple permite además la realización de la navegación drill across entre la
información de diferentes Data Marts ubicados en bases de datos diferentes.

• Resaltado. Cuanta más información recibe el usuario, más difícil resulta identificar
situaciones especiales. Para proporcionar al usuario una serie de alertas que le
permitan identificar valores especiales, la herramienta de consulta debe poder resaltar
los resultados que cumplan una determinada condición indicada en la consulta (por
ejemplo los valores que superen un determinado umbral).

• Restricciones sucesivas. Los resultados de una consulta son utilizados para filtrar
consultas sucesivas. Esta capacidad es especialmente importante cuando se realizan
estudios de comportamiento, en los que se identifica un patrón y luego se realizan
estudios individuales.

• Sumas semiaditivas. Existen un número relativamente elevado de mediciones en las
tablas de hechos que no son aditivas para todas las dimensiones de estudio,
especialmente las medidas de intensidad respecto al tiempo. Estas mediciones deben
ser promediadas en lugar de sumadas, pero como se vio en el apartado Técnicas
básicas de modelado dimensional, la función AVG de SQL no es adecuada ya que
realiza el promedio entre el número total de valores en lugar del número de valores de
cada agrupación. La herramienta debe proporcionar una función específica que realice
correctamente los promedios.

43


• Utilización de ANSI SQL 92. El estándar ANSI SQL 92 proporciona un gran número de
capacidades especialmente útiles que deben ser soportadas por la herramienta.
Destacan los operadores UNION, unión de los resultados de dos consultas, MINUS,
resta de los resultados de una consulta a los resultados de otra consulta o la utilización
de SELECTs anidadas en la consulta, incluida en la clausula FROM. Las consultas
anidadas son una alternativa a las restricciones sucesivas, con la ventaja de que es
necesario un único acceso a la base de datos.

• SQL directo. Por último, la herramienta de consulta debe permitir al usuario escribir
directamente las sentencias SQL, fundamentalmente para introducir consultas
complejas o añadir indicaciones al optimizador del gestor de base de datos utilizado. La
utilización de SQL directo no debe ser una de las prácticas principales, de serlo sería un
indicativo de que la herramienta de consulta no es adecuada.

Capacidades de presentación y análisis

No es suficiente con recuperar los datos del Data Warehouse y presentarlos a los usuarios
en forma de tabla. La herramienta de consulta debe permitir manipular y presentar los datos
de un modo adecuado, teniendo especial importancia las siguientes capacidades:

• Cálculos básicos sobre el resultado. Deben incluirse un conjunto de funciones
matemáticas, estadísticas, de operación sobre cadenas de texto, de procesamiento
secuencial, lógicas, condicionales y de generación de informes para operar sobre el
resultado de las consultas.

• Rotación de resultados. La rotación es la base del análisis multidimensional. Los
resultados basados en columnas de la consulta SQL en muchas ocasiones son
presentados en un formato con una o varias dimensiones representadas en la parte
superior del informe y una o varias dimensiones en la parte lateral.

• Cálculos sobre columnas de resultados rotados. Estos cálculos crean una nueva
columna en función de dos o más columnas rotadas.

• Cálculos sobre filas y columnas. Algunos cálculos como mostrar el valor de una fila o
columna como el porcentaje en relación con otra fila o columna son muy útiles.

• Ordenaciones. Las ordenaciones permiten mostrar los resultados ordenados según
diferentes criterios una vez obtenidos los datos. Son especialmente útiles cuando se
realizan sobre datos que no se muestran en el informe final.

• Representaciones complejas. La herramienta debe permitir crear informes con
múltiples secciones, cada uno con diferentes tablas sencillas, tablas rotadas o gráficos.

44


Debe proporcionarse un amplio conjunto de herramientas de diseño gráfico como
líneas, cuadros, sombreados, fuentes, tamaños, colores, etc.

• Representaciones gráficas. La herramienta debe permitir representar la información
en formato gráfico, como diagramas de barras o gráficos circulares.

• Utilización de variables. Los usuarios deben poder definir sus propias variables que
almacenen resultados de operaciones para que estas puedan ser incluidas en cualquier
parte del informe sin necesidad de volver a definir la fórmula a partir de la que se
obtienen los valores.

Interfaz del usuario

No es suficiente con que la herramienta cumpla todos los requisitos técnicos, la herramienta
debe poder ser utilizada de forma amigable por los usuarios. Debe tener las siguientes
características:

• Facilidad de uso. La herramienta debe tener un interfaz sencillo e intuitivo, que
requiera un mínimo de aprendizaje por parte de los usuarios. En general, esto implica
proporcionar una herramienta con un interfaz similar al de las demás herramientas que
los usuarios estén acostumbrados a manejar, en general los paquetes ofimáticos de
Microsoft.

• Acceso a los metadatos. La herramienta debe proporcionar ayuda sensible al
contexto, no sólo acerca de la herramienta en sí, si no también acerca de los datos.
Esto significa que la herramienta debe poder acceder de una manera flexible a las
descripciones de datos del catálogo de metadatos.

• Listas de valores. Los usuarios deben poder acceder a listas en las que se muestren
los posibles valores que puede tomar un dato, para utilizarlas como restricciones o filtros
de una consulta. Aunque en ocasiones es suficiente con realizar una consulta SELECT
DISTINCT sobre un atributo de una dimensión, si el número de valores es demasiado
elevado debe proporcionarse un método de recuperar la información jerarquizada para
que las listas de valores tengan un tamaño razonable.

• Integración con otras aplicaciones. Como mínimo debe ser posible cortar y pegar los
valores mostrados en la herramienta a otras aplicaciones. Una mejor integración implica
la definición de los informes o los gráficos como objetos OLE - Object Linking and
Embedding - para permitir incluirlos en otras aplicaciones.

45


• Capacidades de exportación en múltiples formatos. Los informes generados por la
herramienta deben poder, en el mejor de los casos, ser exportados a ficheros de texto,
correos electrónicos o páginas web para facilitar su publicación.

Características técnicas

A continuación se describen una serie de características técnicas que debe poseer la
herramienta de generación de consultas. A pesar de no proporcionar capacidades
espectaculares, su omisión provocaría importantes incomodidades en los usuarios.

• Multitarea. Los usuarios deben poder ejecutar varias consultas simultáneamente, así
como poder ejecutar otros programas a la vez que la herramienta de generación de
consultas.

• Cancelación de consultas. Debe ser posible finalizar la ejecución de una consulta sin
afectar a las demás consultas lanzadas por el usuario. Esta finalización debe realizarse
de modo controlado para no dejar conexiones abiertas con el gestor de base de datos, y
no debe requerir reiniciar el equipo del usuario.

• Conectividad. La herramienta debe poder acceder a diferentes fuentes de información
para asegurar una completa integración de fuentes heterogéneas , diferentes gestores
de base de datos, hojas de cálculo, ficheros de texto, etc...

• Planificación. Las consultas que requieran un elevado tiempo de procesamiento deben
poder ser ejecutadas de un modo automático en los momentos del día determinados por
el usuario (generalmente por la noche).

• Administración del software sencilla. A medida que prolifera el uso de las
aplicaciones web esta característica cobra menos importancia. De todos modos, por el
momento sigue siendo necesario una serie de mecanismos para reducir al máximo el
esfuerzo a la hora de instalar y actualizar las herramientas de consulta y el software de
conexión con las fuentes de datos, sobre todo en grandes despliegues.

• Seguridad. La herramienta debe utilizar los sistemas globales de autentificación de la
organización, usuario de dominios NT, LDAP, etc... Una política de seguridad basada
exclusivamente en la herramienta no suele proporcionar la flexibilidad adecuada.

46


Figura 3.8. Ejemplo de herramienta de acceso a la información. Oracle Discoverer

47


.

48

4. DESARROLLO Y CONSTRUCCIÓN DE UN
DATA WAREHOUSE PARA LA GESTIÓN DE LISTA DE ESPERA SANITARIA

DATA WAREHOUSE PARA LA GESTIÓN DE
LISTA DE ESPERA SANITARIA.

El objeto del presente capítulo es el diseño, construcción e implantación de un Data
Warehouse dimensional para las Listas de Espera Quirúrgicas y de Consultas Externas, en el
ámbito de la Atención Especializada del Servicio de Salud de una Comunidad Autónoma,
llevando a cabo todo lo expuesto anteriormente. Como objetivo general del sistema, este Data
Warehouse debe integrar todas las áreas de gestión del Servicio de la Salud y del
Departamento de Salud y Consumo, de tal forma que dé soporte a la Alta Dirección en la toma
de decisiones, así como a los niveles intermedios de la organización en el análisis
departamental de la información debiendo permitir su integración con los actuales subsistemas
de datos y la agregación de subsistemas futuros, definiendo los protocolos básicos a emplear
en el futuro.

4.1. Planteamiento y requerimientos, las necesidades del cliente

La situación actual de la Comunidad Autónoma en estudio, dispone de diferentes Centros
Hospitalarios distribuidos por cada una de las Provincias que la componen. Todos los Centros
disponen del mismo sistema informático de recogida de actividad hospitalaria, el HP-HIS
(Sistema Integral Hospitalario-Hewlett-Packard). Cada uno de los Centros Hospitalarios
gestiona sus datos y obtienen sus propios informes, además, mensualmente recolecta
resúmenes de la actividad, que remite a los Servicos Informáticos de Sistemas Centrales,
quienes recomponen esa información, la tratan y obtienen nuevos informes individuales y
agregados.

49


Figura 4.1. Situación actual

Este mecanismo de trabajo hace que la información para Sistemas Centrales se recopile con
mucho tiempo de retraso, se gestione de forma imprecisa y se demore en la toma de
decisiones importantes. Todo esto se agrava cuando se comprueba que algún dato no es
correcto y hay que volver a generar todo el proceso. Por otro lado, la nueva Ley de Garantía de
Procesos Quirúrgicos, que garantiza el tiempo de respuesta en el tratamiento de determinados
procesos quirúrgico con una determinada prioridad y en caso contrario se abonará el
tratamiento en cualquier otro Centro elegido por el paciente, el traslado y la estancia del
acompañante si lo necesitara, hacen imprescindibles el desarrollo de un sistema más ligero,
rápido y fiable que le permita tomar decisiones en intervalos mínimos de tiempo, haciéndose
palpable la necesidad de la construcción de un Data Warehouse para Lista de Espera.

Como parte primordial para la construcción de este Data Warehouse, están las entrevistas y
encuestas realizadas al usuario hasta entender perfectamente el funcionamiento de su
Negocio. En este proyecto se siguió un Método en Cascada hasta conseguir entender
perfectamente el Negocio. Se seleccionaron dos Centros Hospitalarios claves en el Negocio
de las operaciones quirúrgicas y de las Consultas Externas y se estudió su forma y método de
trabajo.

El estudio de estos centros nos llevó a entender que el Negocio de la Lista de Espera, se
puede desglosar en dos vertientes totalmente independientes, el Negocio de Lista de Espera
Quirúrgica consistente en la gestión de un conjunto de ciudadanos, conocidos como
Pacientes, desde el momento en el que son registrados en el Centro Hospitalario, donde han
sido o están esperando para ser intervenidos de alguna de las Patologías existentes. Algunas
de estas intervenciones están garantizadas por Ley, de manera que la Comunidad Autónoma

50


se compromete a intervenir a un determinado Paciente con una determinada Patología y
Prioridad en un máximo de tiempo, pudiendo para poder cumplir este compromiso, el Derivar a
un Paciente de un Centro Hospitalario a otro. Por otro lado, el Paciente está en su derecho de
rechazar la Derivación a otro Centro, así como el rechazo a la intervención por cualquier
Motivo reconocido o no e incluso retrasar la fecha de la intervención, perdiendo en algunos
casos los beneficios que se indicaran en la Ley de Garantía e incluso su puesto en la Lista de
Espera, empezando a contar su tiempo de cero, sin que por ello, pierda su derecho, bajo
ningún concepto, a la intervención.

Por otro lado, se encuentra el Negocio de Consulta Externa consistente en el estudio de un
conjunto de ciudadanos, conocidos igual que en Lista de Espera Quirúrgica como Pacientes,
que han estado o están esperando para ser citados por un Especialista de una determinada
Patología para diagnosticarle algún tipo de intervención, tratamiento o visitas sucesivas. Estos
Pacientes son registrados en Agendas según la Patología por la que quieran ser entrevistados
y serán atendidos por un determinado especialista. Por otro lado, puede ocurrir que un
paciente quiera ser entrevistado por un especialista en una determinada fecha alejada en el
tiempo, por lo que la agenda en la que debe ser registrado, no ha sido abierta todavía, este
paciente es registrado en una Bolsa de pacientes sin que por ello empiece a ser contado como
tiempo de espera.

Es de primordial interés para la Comunidad Autónoma conocer en todo momento el número de
Pacientes de cada Patología, en cada Centro y el tiempo que llevan esos Pacientes
registrados, de manera que puedan Derivar Pacientes de unos Centros a otros para cumplir
una Ley, en el caso de la Lista de Espera Quirúrgica, así como poder distribuir sus
Profesionales a lo largo de sus Centros Hospitalarios según las necesidades del momento e
incluso decidir el ampliar o reducir sus instalaciones en caso de necesidad.

En este negocio se diferencia entre el tiempo que un paciente está esperando a ser
intervenido o citado por razones administrativas como pueden ser que no exista quirófano
libre, que el médico haya tenido que ausentarse o que esté en espera de otra prueba médica,
llamándose a esto Espera Estructural, dado que es una espera debida a la estructura del
negocio de la Sanidad y Espera (Espera No Estructural) debida al deseo del paciente al
preferir no ser derivado a otro Centro Hospitalario donde se le atendería de forma inmediata,
post-poner su intervención o cita por algún motivo personal, elegir un periodo para su
intervención o cita, o cualquier otra razón que haga que la intervención se retrase por causa
del paciente. Todo paciente al ser registrado en Lista de Espera o Consulta Externa empieza
con un tipo de Espera Estructural que pasa a ser Espera y de nuevo a Espera Estructural
dependiendo de la historia del registro o cita a lo largo del tiempo.

51


Una vez conocida la problemática de su negocio, los requerimientos a nivel global que solicita
el cliente son:

• Unificar, homogeneizar e integrar la información de las distintas áreas del Departamento de
Salud y Consumo, posibilitando la obtención de cruces de información entre las mismas. El
concepto de homogeneización resulta fundamental para que la información que se obtenga
pueda ser comparable.

• Dotar a usuarios con conocimiento del negocio, de un conjunto de herramientas y técnicas
que posibiliten el acceso a los datos corporativos de tal forma que les permita obtener de
forma ágil y eficaz información personalizada.

• Desarrollar los procesos de Captura, Transformación y Carga del Data Warehouse con el
máximo nivel de automatización que el funcionamiento de la organización permita.

• Diseñar la solución teniendo en cuenta los actuales sistemas de información y las
aplicaciones transferidas.

• Propiciar la cultura del Data Warehouse en los distintos niveles de la estructura
organizativa y la familiarización con las herramientas de ayuda a la toma de decisiones

A nivel tecnológico, los requerimientos del cliente son bastante nimios.

• Debe trabajar sobre una arquitectura unix

• El SGBD debe ser Oracle

• Todas las herramientas de acceso al Data Warehouse y de ayuda a la toma de desciones
deben ser Oracle

4.2. Análisis.

El Data Warehouse de Listas de Espera debe permitir el conocimiento actualizado de la
situación de las demoras para intervenciones, consultas o pruebas tanto para mejorar la
gestión y toma de decisiones en los diferentes ámbitos con responsabilidad sobre el tema en el
Departamento de Salud y Consumo, como la disponibilidad de información periódica sobre su
situación para los ciudadanos. La definición de items de información y de indicadores se
corresponderá con los estándares definidos por el Grupo de Expertos del Consejo
Interterritorial, con los datos mínimos a incluir en el RDQ, Registro de Demanda Quirúrgica y
con lo existente en la actualidad en el ámbito de los Hospitales de la Comunidad Autónoma.

52


El Data Warehouse deberá incluir la información necesaria de cada una de las distintas
Provincias de las que se compone la Comunidad Autónoma y de cada uno de los Centros
Hospitalarios en los que se realizan operaciones Quirúrgicas y Consultas de Especialidades de
los que se componen las Provincias. Los distintos establecimientos hospitalarios disponen de
aplicaciones informáticas que permiten la gestión de las listas de espera a nivel del hospital y
control de sus consultas y pacientes.

Los puntos imprescindibles a cumplir:

1. Los datos mínimos a incluir por cada Registro de Demanda Quirúrgica deben ser:

o Datos de identificación del paciente.

o Fecha de inscripción en el Registro.

o Indicación de la intervención quirúrgica por el facultativo especialista responsable
del paciente, con constancia del o de los diagnósticos y procedimientos previstos.

o Prioridad clínica de la intervención.

o Aceptación por el paciente, o persona autorizada, de su inscripción en el Registro.

o Si procede:

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.

Fecha de la pérdida de la garantía.

2. Por otro lado existe una información necesaria para la Alta Dirección y que tiene que
ser mostrada de cierta manera. Esta información es:

o Fecha de entrada del paciente en el registro

o Servicio quirúrgico que prescribe la inclusión en RDQ

o Prioridad clínica del paciente

53


Prioritario

Preferente

Ordinario

o Diagnóstico de inclusión: Codificación según Clasificación Internacional de
Enfermedades (CIE-9 y CIE-10) vigente en el conjunto del Servicio Nacional de
Salud - SNS.

o Procedimiento quirúrgico previsto: Codificación según Clasificación Internacional
de Enfermedades (CIE-9 y CIE-10) vigente en el conjunto del SNS.

o Situación del paciente (tipo de espera)

Paciente en espera “estructural”

Paciente transitoriamente no programable

Paciente en espera tras rechazo de centro alternativo

o 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

o 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 fecha de salida por otros
motivos

3. Para la medición y monitorización permanente del RDQ en los diferentes Servicios
de Salud, resulta necesario disponer de información válida y exhaustiva sobre el
ritmo de crecimiento/disminución de la demanda así como de los tiempos de espera
de los pacientes.

De acuerdo a los requisitos básicos de disponibilidad, consistencia y facilidad de
interpretación establecidos para el Sistema de Información, se ha definido la espera de
los pacientes como el tiempo total de permanencia en el registro, desde su entrada
(momento de la indicación) hasta la baja por intervención o por otros motivos, y con
independencia de la situación del paciente en cada momento. No obstante, se
recomienda avanzar en los criterios de medida del tiempo de espera, con una

54


monitorización específica según los tipos de espera definidos: tiempos de espera
atribuibles a la organización, a la propia voluntad del paciente o a su situación clínica.

Debido al comportamiento observado en el fenómeno de espera, con un reducido
número de pacientes con tiempos de demora relativamente altos en comparación con
los experimentados por la mayoría, deberán incorporarse de forma progresiva nuevos
indicadores de medida, como la espera mediana (espera máxima soportada por el 50%
de los pacientes), que al no verse afectada por los valores extremos, permite un cálculo
más realista de la espera previsible para los pacientes pendientes de intervención.

Se proponen como datos e indicadores básicos más significativos para el conocimiento
de la situación, evolución y capacidad de resolución del problema en el conjunto del
Sistema Nacional de Salud, los siguientes:

• Número de pacientes pendientes de intervención quirúrgica

Número total de pacientes incluidos en el registro al final del periodo de estudio.

El número total de pacientes pendientes de intervención quirúrgica programada se
desglosará, atendiendo al tipo de espera en:

Número de pacientes en espera estructural

Número de pacientes transitoriamente no programables

Número de pacientes en espera tras rechazo de centro alternativo

• Tiempo medio de espera de los pacientes pendientes de intervención quirúrgica

Tiempo promedio, expresado en días, que llevan esperando los pacientes
pendientes de intervención, desde la fecha de entrada en el registro (fecha de
prescripción de la intervención) hasta la fecha final del período de estudio.

Σ(fecha final período de estudio – fecha de entrada en registro) / nº pacientes
en el registro

El tiempo medio de espera se calculará para cada uno de los grupos de pacientes
establecidos en función del tipo de espera:

o Tiempo medio de espera de los pacientes en espera estructural

o Tiempo medio de espera de los pacientes transitoriamente no
programables

o Tiempo medio de espera de los pacientes en espera tras rechazo de centro
alternativo

55


• Distribución de los pacientes pendientes de intervención por tramos de espera

Número de pacientes pendientes de intervención, en cada uno de los tramos de
tiempo de espera definidos:

o 0 – 90 días

o 91-180 días

o 181-365 días

o > 365 días

• Distribución por tramos de espera para el total de pacientes pendientes de
intervención y para cada uno de los grupos de pacientes establecidos en función
del tipo de espera.

• Número de entradas en el registro de pacientes pendientes de intervención
quirúrgica

Número de nuevos casos incluidos en el registro durante el período de estudio.

• Número de salidas del registro de pacientes pendientes de intervención quirúrgica

Se definen dos indicadores para el análisis de las salidas del registro:

o Número total de salidas durante el período de estudio

Número de pacientes dados de baja por cualquier motivo durante el
período de estudio.

o Número de pacientes intervenidos durante el período de estudio

Número de pacientes dados de baja por intervención quirúrgica durante el
período de estudio.

• Espera media de los pacientes intervenidos

Tiempo promedio, expresado en días, que han esperado los pacientes ya
intervenidos, desde la fecha de entrada en el registro (fecha de la indicación) hasta
la fecha de intervención quirúrgica.

Σ (fecha de salida – fecha de entrada) / salidas del registro por intervención

Se definen dos indicadores para el análisis de la espera media de las salidas del
registro por intervención quirúrgica:

o Espera media del total de pacientes intervenidos

56


o Espera media de los pacientes intervenidos de forma programada (se
excluyen para el cálculo del indicador los pacientes del registro
intervenidos vía urgente)

• Demora media prospectiva

Tiempo, expresado en días naturales, que tardaría en absorberse el total de
pacientes pendientes de intervención quirúrgica al ritmo de trabajo de un período
anterior definido.

Total pacientes pendientes / promedio diario de salidas totales del registro en
los últimos doce meses

4. Con el fin de disponer de información que permita la comparación entre
Comunidades Autónomas y con otros países de nuestro entorno, se hace necesario
calcular los indicadores referidos en relación con la población residente, utilizando
para su cálculo el registro oficial existente en cada momento.

5. Las necesidades expuestas a nivel de seguridad y acceso, por parte del usuario,
plantea un sistema dirigido tanto a usuarios de Servicios Centrales, Direcciones
Provinciales y los diferentes Centros Hospitalarios.

La información para la toma de decisiones debe ser vista a tres niveles de restricción.
Uno a nivel del propio Centro Hospitalario o generador de la información, a nivel de
Dirección Provincial, capaz de ver toda la información referente a la misma Provincia y
otro a nivel de Servicios Centrales o Comunidad Autónoma, que puede ver toda la
información sin restricciones de Provincia o Centro Hospitalario.

Por otro lado existirán dos tipos de informes o listados. Unos listados “fijos” en los que
sólo se pueda determinar Centro, Provincia, fecha o Especialidad y otros en los que el
usuarios debe estar en total liberdad de seleccionar la información como le interese en
ese momento y agruparla como en cada momento estime.

En la figura 4.2 se muestra un esquema de cómo se podría clasificar la información a
nivel de cantidad de información y forma de acceso.

57


Figura 4.2 Clasificación de estudios por role de usuario y capacidad de análisis

Una vez planteada la necesidad y requerimientos por parte del cliente, se analizó la información
de la que se disponía. Toda la información de la que disponen los Centros Hospitalarios reside
en diferentes sistemas operacionales, independientes por Centro Hospitalario y gestionados
todos por el mismo sistema informático de recogida de actividad hospitalaria, el HP-HIS
(Sistema Integral Hospitalario-Hewlett-Packard). Dado que la herramienta utilizada para la
gestión de los operacionales no es propietaria, no dispusimos del estudio exhaustivo y
conocimiento de la misma; pero el grupo de mantenimiento nos proporcionó toda la información
necesaria y gestionó las descargas necesarias.

Cada uno de los sistemas operacionales a partir de los que se obtiene la información de la
mayoría de las dimensiones y movimientos para el Data Warehouse se basa en la creación de
un registro de las visitas realizadas o programadas de los diferentes pacientes en los Centros
Hospitalarios. Dada la diferencia de gestión de los negocios y el ciclo de vida de los registros,
nos indicaron que existían dos grandes bloques de tablas disociadas entre ellos en la propia
aplicación de gestión y recogida de información, se podía explicar como si la herramienta se
compusiera de diferentes paquetes que se pudieran instalar por separado, de manera que un
paquete gestionaba un tipo de negocio y otro, el otro. Aún así, existe un juego de tablas que
participa tanto en la parte Quirúrgica como en la parte de Consulta Externa.

SISTEMA OPERACIONAL PARA LISTA DE ESPERA QUIRÚRGICA

Cada vez que un paciente es atendido en un Centro Hospitalario se genera un registro en el
sistema operacional con el código de paciente, el código de hospital, el código de provincia, el
código de patología y la fecha de entrada, así como cada vez que se le anuncia su intervención
quirúrgica se crea un registro con el código de paciente, el código de hospital, el código de
provincia, el motivo de la intervención, la fecha de entrada – fecha de aviso de la intervención -

58


fecha garantizada de intervención, si es que existe y fecha de la intervención. La generación de
estos registros se realiza a través de la aplicación corporativa y a través de acceso Web.

En la figura 4.3 puede verse, bastante resumido, el modelo entidad-relación del sistema
operacional para Lista de Espera Quirúrgica.

Figura 4.3. Modelo de datos del sistema operacional para Lista de Espera Quirúrgica.

SISTEMA OPERACIONAL PARA CONSULTAS EXTERNAS

De igual manera que en Quirúrgica, cada vez que un paciente es atendido en un Centro
Hospitalario de una especialidad, se genera un registro en el sistema operacional con el código
de paciente, el código de hospital, el código de provincia, el código de patología, la fecha de
entrada y la fecha en la que el Profesinal o Especialista le tratará, junto con la agenda en la que
está apuntado para la cita. La generación de estos registros se realiza a través de la aplicación
corporativa y a través de acceso Web.

En la figura 4.4 puede verse el modelo entidad-relación del sistema operacional para Consulta
Externa.

59


Figura 4.4. Modelo de datos del sistema operacional para Consulta Externa.

A parte de las tablas de movimientos, donde se registraban las intervenciones y citas de los
pacientes, en las conversaciones con el equipo de mantenimiento se nos indicó que la
aplicación de gestión era configurable en su instalación y que algunas descripciones de lo que
más tarde se identificaron como dimensiones, podían diferir entre los diferentes Centros
Hospitalarios, complicando el tema, dado que cada Centro Hospitalario quería ver la
información con la misma descripción a la que estaba acostumbrado. Esta tablas eran poco
dinámicas, contando con modificaciones escasas o nulas. Existían tablas maestras,
inmodificables e identificadas en todos los Centros.

4.3. Diseño y construcción. Planteamiento de la solución.

Después de la recopilación exhaustiva de requerimientos e información, las distintas reuniones
y ajustes a la arquitectura, la solución ofrecida fue la siguiente:

60


Figura 4.5. Solución propuesta.

Se propuso una solución en la que, basándonos en la información que se obtendría de los
sistemas operacionales existentes en cada Centro Hospitalario, junto con la creación de dos
nuevos sistemas legacy se cargaría en un Data Warehouse de donde tanto los Centros
Hospitalarios como las Direcciones Provinciales y los Servicios Centrales obtendrían listados,
informes y reports de generación instantánea, donde en todo momento se tendría la
información actualizada, realizándose carga de la información de forma diaria desde cada uno
de los Centros o bajo petición de los sistemas de información.

Básicamente habrá dos tipos de usuarios:

• Usuarios de “informes predefinidos” o “Reporting Web estructurado”. Es el apropiado
para aquellos usuarios que sean meros consumidores de información regular. Cada
informe suele tener un filtro de información particularizado para que el usuario pueda
indicar qué información quiere extraer. Los informes tienen una navegación limitada y una
amplia difusión.

• Usuarios de “Análisis OLAP ad-hoc”. Esta capacidad es la necesaria para analistas y
usuarios avanzados. Habitualmente, solo un 5-10 % de los usuarios debería tener
habilitada esta funcionalidad, puesto que la ejecución indiscriminada de análisis no
predefinidos y que pueden ser tremendamente consumidores de recursos supone un
riesgo operativo a tener en cuenta. Los análisis ad-hoc se realizan durante el desarrollo de
un estudio casual puntual para, una vez obtenidas las conclusiones, cesar en su
ejecución. Es habitual que estas consultas deban resolverse en el nivel de información
detallada, con selecciones de registros y combinaciones de criterios muy complejas. Si

61


alguna de las consultas pasan a ejecutarse de forma frecuente y desde diversos ámbitos,
conviene adjuntarla al repertorio de reporting estructurado o informes predefinidos,
habilitando en ese caso los mecanismos que permitan su ejecución eficiente.

Se dispondrán de diferentes tipos de informes:

• Informes Estáticos. Elaborados con la herramienta Oracle Reports a los que se podrá
acceder a través de la intranet. Estos informes estarán compuestos de estructuras
complejas donde se combinarán tablas cruzadas y gráficos indistintamente. Estos informes
suele tener un filtro de información particularizado para que el usuario pueda indicar que
información quiere extraer, sin posibilidad de navegación.

• Informes Dinámicos. Elaborados con la herramienta de explotación Oracle Discoverer, a
los que se accederá a través de la intranet o de forma local. Los usuarios de esta
herramienta podrán realizar nuevas explotaciones o utilizar explotaciones ya definidas,
modificando según demanda dichos informes, incorporando o eliminando filtros de
información, nuevos criterios de búsqueda, etc.

Roles de acceso a la información:

Para solventar el tema de acceso a la información dependiendo de su grado en la jerarquía
institucional de la Comunidad, la solución que se propuso fue la de la utilización de VPD de
Oracle o Virtual Private Database, también conocidas como “acceso de control de grano fino”,
del inglés, “fine graind access control” (FGAC), que permite definir qué registros de información
puede ser accedidos por un determinado usuario.

Este mecanismo se base en la construcción de roles y unas políticas que fuerzan a que un
mecanismo de Oracle se dispare y añada de forma automática una cláusula WHERE en cada
una de los accesos a las tablas donde se han definido las políticas.

Lo más sencillo será un sencillo ejemplo para entenderlo:

El ejemplo es el típico de una compañía con diferentes departamentos, empleados que
pertenecen a un departamento y sólo uno y una tabla con las vacaciones de cada empleado,
que son secretas para otros departamentos; pero no para los miembros de un mismo
departamento para poder gestionar las faltas por vacaciones.

create table departamento (
dep_id int primary key,
nombre varchar2(30)
);

create table empleado (
dep_id references departamento,
nombre varchar2(30)

62


);

create table vacaciones (
dep_id references departamento,
fechas varchar2(30)
);

insert into departamento values (1, Investigación y Desarrollo');
insert into departamento values (2, 'Ventas' );
insert into departamento values (3, 'Recursos Humanos' );

insert into empleado values (2, 'Rafa');
insert into empleado values (3, 'Sergio');
insert into empleado values (3, 'Sandra');
insert into empleado values (1, 'Carmelo');
insert into employee values (2, 'Enrique' );
insert into employee values (1, 'Selene' );

insert into vacaciones values (1, '01-Ago / 15-Ago' );
insert into vacaciones values (2, '01-Jul / 31-Jul' );

Para el funcionamisto de VPD en Oracle se necesita crear un paquete, un trigger y definer la
política:

create or replace package pck_vpd
as
p_dep_id departamento.dep_id%type;

procedure set_dep_id(v_dep_id departamento.dep_id%type);

function predicate (obj_esquema varchar2, obj_nombre varchar2) return
varchar2;
end pck_vpd;
/

create or replace package body pck_vpd as

procedure set_dep_id(v_dep_id departamento.dep_id%type) is
begin
p_dep_id := v_dep_id;
end set_dep_id;

function predicate (obj_esquema varchar2, obj_nombre varchar2) return
varchar2 is
begin
return 'dep_id = ' || p_dep_id;
end predicate;

end pck_vpd;
/

El trigger se dispara cada vez que alguien accede a la bbdd para localizar el atributo dep_id,
que entonces llama al paquete set_dep_id.

create or replace trigger trg_vpd

63


after logon on database

declare
v_dep_id departamento.dep_id%type;

begin
select dep_id into v_dep_id
from empleado where upper(nombre) = user;

pck_vpd.set_dep_id(v_dep_id);
end;
/

La política es un procedimiento que es utilizado para añadir una claúsula WHERE si alguien
ejecuta una query.

begin

dbms_rls.add_policy (
user,
'vacaciones',
'choosable policy name',
user,
'pck_vpd.predicate',
'select,update,delete');

end;
/

La forma de probar esto sería con el juego de pruebas:

create user selene identified by selene default tablespace users temporary
tablespace temp;
create user Carmelo identified by Carmelo default tablespace users temporary
tablespace temp;
create user Rafa identified by Rafa default tablespace users temporary
tablespace temp;
The necessary privileges are granted.
grant all on vacaciones to Selene;
grant all on vacaciones to Carmelo;
grant all on vacaciones to Rafa;

grant create session to Selene;
grant create session to Carmelo;
grant create session to Rafa;

create public synonym vacaciones for vacaciones;

Si acceso Francisco a la bbdd

connect Selene/Selene;

select * from department_secrets;
DEP_ID FECHAS
---------- ------------------------------
1 01-Ago / 15-Ago
1 16-Ago / 31-Ago

Si accede Pedro y hace la misma Quero.

connect Rafa/Rafa;

64


select * from department_secrets;
DEP_ID FECHAS
---------- ------------------------------
2 01-Jul / 15-Jul
2 16-Jul / 31-Jul

Dada la necesidad de restricción del acceso a los registros según el Centro Hospitalario, la
Dirección Provincial o Servicios Centrales que tienen derecho a contemplar toda la
información, se llevó a cabo la puesta en marcha este mecanismo de VPD de Oracle. Este
mecanismo fue sencillo de implementar, dado que toda la información se descargaba desde
los Centros Hospitalarios identificando cada uno de los registros con el Código Identificador
del Centro o número CEGA. Este código CEGA se compone de cuatro dígitos cuyos primeros
dos dígitos coinciden con el código de la Provincia al que pertenece el Centro.

En el diseño se introdujo este campo en cada una de las tablas de hechos y en las
dimensiones que se estimaron sensibles a la restricción de la información y se creó una
política de acceso mediante los campos, *_CO_CEGA o *_ID_CEGA (dependiendo del
nombre en la tabla), de manera que todos los usuarios que se daban de alta en el sistema
para estudio de Lista de Espera se le asignaba un role de nombre ROLE_<CEGA> o
ROLE_<PROV>, donde PROV son los dos primeros dígitos del CEGA y la política incluía un
WHERE del tipo

WHERE <TABLA>_CO_CEGA like ‘CE%’ --- Para la Dirección
Provincial
WHERE <TABLA>_CO_CEGA like ‘CEGA%’ --- Para el Centro Hospitlario
WHERE <TABLA>_CO_CEGA like ‘%’ --- Para Servicios Centrales

Esto conlleva que el Data Warehouse ofrecerá tres visiones de la información, de los
indicadores y variables en estudio:

• Una visión global, integrada y normalizada adecuada para los usuarios de Servicios
Centrales

• Una visión parcial adecuada para los usuarios de la Dirección Provincial, que únicamente
podrán ver los datos concernientes a los Centros Hospitalarios de su provincia con unos
valores de indicadores limitados a la misma.

• Una visión local adecuada para los usuarios de los Centros Hospitalarios (los jefes de
servicio) que precisan una visión acorde con los servicios y nombre de las listas de espera
que utilizan en los Centros y que no necesariamente debe coincidir con los nombres
normalizados por el Servicio de Salud de la Comunidad Autónoma en estudio.

Después de definir estas características de acceso e información accedida, los usuarios, se
puede resumir que se agruparon de la siguiente manera:

65


Grupo de usuarios Tipo de acceso Limitación de acceso a información
Usuarios de Accederá a informes predefinidos. Acceso a toda la información
Servicios Centrales Podrán crear nuevos informes y
podrán enviarlos a grupos de usuarios.
Usuarios de la Accederá a informes predefinidos. Acceso a la información de los
Dirección Provincial Podrán crear nuevos informes. centros hospitalarios de su provincia.
Usuarios de Accederá a informes predefinidos. Acceso a la información de su
Hospitales Podrán crear nuevos informes y hospital y a información de los niveles
podrán enviarlos a grupos de usuarios superiores.
de su hospital.
Resto de Usuarios Accederá a informes predefinidos Acceso a la información según la
definición de los informes.
Por otro lado, dados los requerimientos del cliente se incluyeron dos sistemas independientes
de la gestión hospitalaria actual, los sistemas de “Población de Referencia” y los “Procesos”.

Nuevos sistemas legacy

Para los requerimientos del cliente y ante su necesidad de los estudios comparativos entre la
población de los diferentes Centros Hospitalarios o el estudio de Patologías o Procesos que
agruparan diferentes Diagnósticos y Procedimientos, se hizo necesaria la definición de dos
tipos de información que hasta el momento no se estaban incluyendo en ningún Centro
Hospitalario y que dependían directamente de la definición de Servicios Centrales.

• Poblaciones de Referencia, dependiente directamente de Servicios Centrales: Esta
información indica el número de pacientes que puede asistir cada Centro Hospitalario.
Permite realizar alguno de los cálculos comparativos entre poblaciones, que el usuario
quiere estudiar y lo normal es que se cargue únicamente una vez al año, al inicio del
mismo.

La información para la Población de Referencia no se extrae, actualmente, de ningún
sistema existente, sino que se genera con la información Administrativa de la Comunidad
Autónoma. Esta información se deberá generar una vez al año, al inicio del año y no se
deberá modificar en todo el transcurso del mismo.

Esta información se utiliza para el cálculo de ciertos indicadores como “salida por
habitante”. De no cargar esta información sólo se vería afectado el cáculo del indicador
pero el resto del Data Warehouse no se vería afectado.

Este sistema no existe actualmente y se debe generar nuevo para satisfacer las
necesidades del usuario, por lo que se propone un archivo de construcción sencilla, se
configura como archivo plano nombrado Poblaciones.txt. Se compone de un registro por
Centro Hospitalario y año. Los registros no son de tamaño fijo y se componen de tres

66


campos separados por “;” (punto y coma). El registro termina con un retorno de carro y no
por “;” (punto y coma). El orden de los campos es:

Campo Descripción
CEGA CEGA del Centro Hospitalario del que se carga la Población de
Referencia
AÑO Año para el que se carga la Población de Referencia
POBLACIÓN Número de habitantes que puede atenderse en el Centro Hospitalario
ese año.

Un ejemplo de fichero de Población de Referencia puede ser:

Poblaciones.txt
1234;2005;200000
2345;2005;3000
1234;2004;400000
2345;2003;50000
1234;2003;600000
• Procesos, dependiente directamente de Servicios Centrales. El Proceso se carga en el
movimiento durante la carga del Data Warehouse y perdura en el movimiento de forma
invariable, de manera que si los Procesos no son cargados de forma correcta, los
movimientos pueden no disponer de la información correcta.

La información para la clasificación de Procesos o Patologías no se obtiene de la
extracción de ningún sistema operacional, sino de los conocimientos y clasificaciones
cedidas por la Legislación actual. Esta información debería ser totalmente estable, cargarse
una vez y no volver a modificarse.

Esta información se almacena en el movimiento o hecho, de manera que si se modificase
el movimiento ya almacenado contendría información no exacta.

Al igual que el de Población de Referencia no existe actualmente, por lo que se configura
de forma sencilla, se pide que se cree como archivo plano nombrado Procesos.txt. Se
compone de un registro por Proceso con diagnóstico de inicio, diagnóstico de fin y/o
procedimiento de inicio y fin. Los registros no son de tamaño fijo y se componen de ocho
campos separados por “;” (punto y coma). El registro termina con un retorno de carro y no
por “;” (punto y coma). El orden de los campos es:

Campo Características Descripción
CÓDIGO CHAR(6) CEGA del Centro Hospitalario del que se carga la
Población de Referencia
DESCRIPCIÓN CHAR(60) Año para el que se carga la Población de Referencia
DIAG_INI CHAR(60) Mínimo código CIE9 del procedimiento que identifica
el proceso.
DIAG_FIN CHAR(6) Máximo código CIE9 del diagnóstico que identifica el
proceso.
PROC_INI CHAR(6) Mínimo código CIE9 del procedimiento que identifica

67


el proceso.
PROC_FIN CHAR(6) Máximo código CIE9 del procedimiento que identifica
el proceso.
BOE CHAR(1) El código se agrupa para estudios BOE. Posibles
valores:
• S
• N
BOC CHAR(1) El código se agrupa para estudios BOC. Posibles
valores:
• S
• N

Este archivo cumple ciertas características para que la generación de Procesos sea
correcta.

• Todo registro que se componga de un diagnóstico debe disponer de un diagnóstico de
inicio y un diagnóstico de fin.

• Todo registro que se componga de un procedimiento se debe componer de un
procedimiento de inicio y un procedimiento de fin.

• El registro que disponga de diagnóstico o procedimiento de inicio y no se componga de
diagnóstico o procedimiento de fin, deja el proceso abierto de manera que cualquier
diagnóstico o procedimiento que sea mayor que el inicial será caracterizado por ese
proceso.

• Cualquier código de proceso que se componga de más de un registro implicará un OR
lógico de manera que cualquier diagnóstico o procedimiento que cumpla alguna de las
condiciones de un registro, le caracterizará para ese proceso.

• Si un registro se compone de un diagnóstico de inicio y fin y un proceso de inicio y fin,
implica un AND lógico y el movimiento deberá disponer de un diagnóstico comprendido
entre el diagnóstico de inicio y fin y además de un procedimiento incluido entre el
procedimiento de inicio y fin.

• El proceso se carga en el movimiento durante la carga del Data Warehouse y perdura
en el movimiento para siempre de manera que si los Procesos no son cargados de
forma correcta, los movimientos pueden no disponer de la información correcta.

Un ejemplo de fichero de Procesos puede ser:

Procesos.txt
ARTROD;OSTEOARTROSIS LOCALIZADA SIN ESPECIFICAR-PIERNA;;;81.54;81.55;N;S
ARTROD;OSTEOARTROSIS LOCALIZADA SIN ESPECIFICAR-PIERNA;;;81.54;81.55;S;N
ARTROS;ARTROSCOPIA ;;;80.2;80.29;S;N
BOCINO;BOCIO NODULAR NO TOXICO;241;241.9;;;S;S
BOCIO;BOCIO SIMPLE Y NO ESPECIFICADO;240;240.9;;;S;S
CARDCO;CIRUGM-MA CORONARIA;410;414.9;;;N;S
CARDCO;CIRUGM-MA CORONARIA;;;36;36.99;N;S
CARDVA;CIRUGM-MA VALVULAR;394.0;397.9;35;35.99;N;S
CARDVA;CIRUGM-MA VALVULAR;424.0;424.99;35;35.99;N;S

68


CATAR;CATARATA;366;366.9;;;N;S
CATAR;CATARATA;;;13.1;13.69;N;S
CATAR;CATARATA;;;13.71;13.71;N;S
CATAR;CATARATA;366;366.9;;;S;N

Indicadores de estudio

La solución propuesta contempla todos los indicadores de negocio obtenidos mediante
sesiones con un grupo un de trabajo representando a la Comunidad Autónoma en estudio
descritos con la capacidad de ser explotados bajo la perspectiva de todas las variables o
dimensiones que caracterizan los episodios de Lista de Espera y que se recogen a través de
los diferentes Centros Hospitalarios. El Data Warehouse se diseña para garantizar la capacidad
de navegación de los indicadores sobre todas las dimensiones de estudio.

En el capítulo Aplicaciones de usuario. Podemos ver una definición completa de todos los
indicadores existentes para la aplicación.

Se prevén dos tipos de estudios diferenciados:

• Estudios longitudinales por periodos que permitirán evaluar los indicadores asociados a
eventos. Por ejemplo, número de entradas en lista de espera, número de salidas, número
de suspensiones, demora de las salidas de lista de espera, etc.

• Estudios transversales o cortes en el tiempo que permiten evaluar los indicadores
asociados al estado en que se encuentran los episodios de lista de espera. Por ejemplo,
número de episodios que se encuentran en suspensión a una fecha determinada.

Dichos estudios se realizarán sobre diferentes tipos de periodo (quincenal, mensual, semestral,
anual) o, en el caso de estudios transversales, a una fecha cualquiera.

Figura 4.6. Tipos de indicadores

69


4.3.1. Modelo dimensional

En este capítulo se recoge la información de las diferentes estrellas, junto con las dimensiones
e indicadores que forman el Data Warehouse para Lista de Espera. En este punto sólo se
muestran los indicadores básicos o hechos y no los derivados que normalmente se calculan a
partir de formulas en las herramienta de acceso a los datos.

Como se ha indicado con anterioridad, el estudio de Lista de Espera en realidad se compone
de dos estudios independientes en administración y gestión, por lo que para no interferir en las
cargas y gestión de las mismas se diseñaron dos Data Marts independientes entre ellas,
Espera Quirúrgica y Consulta Externa, perfectamente diferenciadas aunque compartiendo
algunas dimensiones y que pasamos a estudiar.

El Data Warehouse de Lista de Espera Quirúrgica y Consulta Externa consta en realidad de
tres tablas de hechos, una para Lista de Espera Quirúrgica y otras dos de ellas para Consulta
Externa y Pruebas Radiológicas, aunque una de estas últimas, es una tabla de hechos sin
hechos como vimos que era posible en el punto Técnicas básicas de modelado dimensional,
es una tabla de hechos para aquellas consultas que llevan incorporada una prueba
radiológica, dado que la Comunidad Autónoma tiene especial interés en estudiar ese conjunto
de citas. Si nos fijamos en esa tabla de hechos, se compone únicamente de las claves
necesarias para identificarla con un registro de las Consultas Externas y con la clave de la
prueba radiológica a efectuar, por lo que se podía haber incorporado perfectamente en la
estrella inicial; pero hubiera sobrecargado gran cantidad de registros de movimientos con
campos vacios al no disponer la mayoría de ellos de estos atributos.

Por otro lado, todos los hechos definidos en esta Data Warehouse son aditivos, pudiéndose
operar sobre ellos sin problema, pues lo único que acumulan son números de días.

La estrella de Lista de Espera Quirúrgica donde podemos ver la tabla de hechos LELEQCHE y
las dimensiones que le afectan es:

70


LEPGARDI LEGARADI

LETPANDI LEMSGADI

LETPACDI
LESITLDI
LEMSALDI
LECRINDI
LESEXODI
LEPROFDI
LEINTVDI
LETPGADI
LELEQCHE LELISRDI
LEPPACDI
LEREDEDI
LEPACDDI
LECEGADI
LEGARTDI
LEPRIODI
LEPROCDI
LEHOSPDI
LESCLFDI
LESCLPDI
LESERVDI
LEPERDDI
LESITBDI
LEDATADI

Figura 4.7 Modelo dimensional. Estrella de Lista de Espera Quirúrgica.

Y la estrella de Consulta Externa que se compone a su vez de dos tablas de hechos,
LECOEXHE y LECEXPHE una de Consulta Externa y otra de Pruebas Radiológicas con sus
dimensiones es.

Figura 4.8 Modelo dimensional. Estrella de Consultas Externas y Pruebas Radiológicas.

71


4.3.1.1. Descripción de las tablas de hechos

El modelo dimensional diseñado para almacenar la información acerca de la gestión de
pacientes en Lista de Espera Quirúrgica o Consulta Externa está compuesto por dos estrellas
compuestas por las tablas de hechos que se indican a continuación:

Hechos Entidad Descripción
Consulta Externa LECOEXHE Hechos de la consulta externa
LECEXPHE Hechos de las Múltiples técnicas Radiológicas de una cita
Lista de Espera LELEQCHE Hechos de Lista de Espera Quirúrgica
La primera estrella - figura 4.7 - o Estrella de Lista de Espera Quirúrgica, consiste en trece
dimensiones específicas, con información acerca de las Circunstancias de inclusión, Motivo de
Salida, Motivo de Suspensión de la Garantía, Perdida de la Garantía, Procesos, Rechazos de
la Derivación, Situación de la Garantía, Situación en Lista, Tipos de Actividad, Tipos de
Anestesia, Tipos de Garantía, Tipos de Lista, además de otras quince generales que comparte
con la estrella de Consulta Externa y que indica el Diagnóstico CIE, el Procedimiento CIE, la
estructura Funcional, la Financiación del Paciente, la Geografía, el Hospital, la Prioridad, la
Procedencia del Paciente, el Sexo, el Profesional que atiende al Paciente y lo indispensable en
un Data Warehouse, la dimensión Tiempo además de una tabla de hechos LELEQCHE – Lista
de Espera Quirúrgica - con cinco hechos, cuenta, dias, diasdrv, diasee y diast. La tabla de
hechos de Lista de Espera Quirúrgica, contiene un registro por cada vez que un Paciente tiene
que ser intervenido. La estrella de hechos de Lista de Espera Quirúrgica permite realizar
estudios de volumen de pacientes en espera para ser intervenido y las razones por las que se
están efectuando esas esperas, así como permite realizar estudios estadísticos por sexo y
edad del tipo de operaciones que se realizan en cada una de las Provincias y en la Comunidad
Autónoma en estudio.

La tabla de hechos LELEQCHE, contine un registro por cada uno de los pacientes que están
o han estado registrados para una intervención quirúrgica. Está formada por una clave múltiple
compuesta por las claves de las dimensiones asociadas y los hechos:

• cuenta, que siempre toma valor 1,

• dias que acumula el número de días que el paciente lleva registrado por una causa
diferente a las de nivel administrativo,

• diasdrv que acumula el número de días que el paciente lleva derivado, si es el caso,

• diasee que acumula el número de días que el paciente está esperando por un motivo
administrativo y

• diast que acumula el total de días desde el ingreso del paciente en lista de espera.

72


Puede ocurrir que el hecho diasee coincida con diast, si el ingreso es normal y el paciente no
ha pedido ningún cambio en sus fechas de intervención por razones personales.

Esta tabla es totalmente dinámica, siendo sensible de actualizarse e insertar registros de forma
constante y masiva todos los días. Existe un registro por cada uno de los pacientes existentes
en Lista de Espera, esté abierto o cerrado el movimiento y un registro adicional por cada uno
de los periodos por los que vaya trascurriendo el proceso. Este desdoblamiento de registros se
realiza para un acceso rápido en los estudios por periodos.

Sobre esta tabla se definió la política de acceso VPD de Oracle por el campo LEQC_ID_CEGA,
dado que cada movimiento es propio de un Centro Hospitalario y Provincia.

Atributos
Tabla: LELEQCHE
Descripción: Tabla de Hechos de Lista de Espera Quirúrgica
Tipo: Hechos
Columna Tipo Comentario PK FK
LEQC_ID_NHM NUMBER(9) Identificador del Número Historial del Movimiento Yes No
LEQC_ID_PROCPAC NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_ANESTESIA NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_MOTPGARANT NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_SITGARANTIA NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_FXINILEQ NUMBER(6) Clave subrogada del DW.Identificador de la Fecha Yes Yes
de Entrada en RDQ
LEQC_ID_FXFINLEQ NUMBER(6) Clave subrogada del DW.Identificador de la Fecha Yes Yes
de Salida RDQ
LEQC_ID_FXMAXGAR NUMBER(6) Clave subrogada del DW.Identificador de la Fecha Yes Yes
Maxima de Garantía
LEQC_ID_FXLSTGAR NUMBER(6) Clave subrogada del DW.Identificador de la Fecha Yes Yes
de Perdida de Garantia
LEQC_ID_FXINISPN NUMBER(6) Clave subrogada del DW. Identificador de la Yes Yes
Fecha Inicio Suspension
LEQC_ID_FXINIDRV NUMBER(6) Clave subrogada del DW. Identificador de la Yes Yes
Fecha Inicio Derivación
LEQC_ID_FXPREINT NUMBER(6) Clave subrogada del DW. Identificador de la Yes Yes
Fecha Prevista de Intervención
LEQC_ID_SITLISTA NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_CIRCINCL NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_MOTSAL NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_MOTSGAR NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_MRECDER NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_LISTA NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_PROFESIO NUMBER(10) Clave subrogada del DW Yes Yes
LEQC_ID_PACIENTE NUMBER(10) Clave subrogada del DW Yes Yes
LEQC_ID_DIAGCIEA NUMBER(10) Clave subrogada del DW. Identificador del Yes Yes
Diagnostico de la CIE (A)
LEQC_ID_PRIORIDAD NUMBER(2) Clave subrogada del DW Yes Yes
LEQC_ID_HOSPDRV NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_CEGA NUMBER(4) Clave subrogada del DW Yes Yes
LEQC_ID_TIPGARANT NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_SERVICIO NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_PROCCIEA NUMBER(10) Clave subrogada del DW. Identificador de los Yes Yes
Procedimientos CIE (A)
LEQC_ID_GARANTE NUMBER(10) Clave subrogada del DW Yes Yes
LEQC_ID_INTERV NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_FXINI NUMBER(6) Clave subrogada del DW. Identificador de la fecha Yes Yes
de inicio del Periodo

73


LEQC_ID_FXFIN NUMBER(6) Clave subrogada del DW. Identificador de la fecha Yes Yes
de Fin del Periodo
LEQC_ID_SITBOE NUMBER(5) Clave subrogada del DW Yes Yes
LEQC_ID_SEXO NUMBER(2) Clave subrogada del DW No Yes
LEQC_ID_FXFINSPN NUMBER(6) Clave subrogada del DW. Identificador de la No Yes
Fecha de Fin de Suspensión
LEQC_ID_FXINIAPL NUMBER(6) Clave subrogada del DW. Identificador de la No Yes
Fecha Inicio Aplazamiento
LEQC_ID_FXFINAPL NUMBER(6) Clave subrogada del DW. Identificador de la No Yes
Fecha Fin de Aplazamiento
LEQC_ID_FXFINDRV NUMBER(6) Clave subrogada del DW. Identificador de la No Yes
Fecha de rechazo de Derivación
LEQC_ID_FXAPTO NUMBER(6) Clave subrogada del DW. Identificador de la No No
Fecha de Apto
LEQC_ID_FXPRECDC NUMBER(6) Clave subrogada del DW. Identificador de la No
Fecha prevista de caducidad
LEQC_ID_PERIODO NUMBER(6) Clave subrogada del DW No Yes
LEQC_ID_PROCESO NUMBER(6) Clave subrogada del DW No Yes
LEQC_ID_TIPOACT NUMBER(5) Clave subrogada del DW No Yes
LEQC_ID_DIAGCIEB NUMBER(10) Clave subrogada del DW. Identificador de No Yes
Diagnostico CIE (B)
LEQC_ID_PROCCIEB NUMBER(10) Clave subrogada del DW. Identificador del No Yes
Procedimiento CIE (B)
LEQC_CO_PREOP VARCHAR2(1) Indica si dispone de Preoperatorio No No
LEQC_CO_AMBITO NUMBER(1) Valor que indica el Ambito No No
LEQC_CO_REALIZ VARCHAR2(1) Valor que indica si el preoperatorio se ha realizado No No
LEQC_CO_DRVBLE NUMBER(1) Indica si el paciente es derivable No No
LEQC_CA_CUENTA NUMBER(2) Incorpora un valor para poder realizar las No No
operaciones necesarias.
LEQC_CA_DIAS NUMBER(5) Número de Dias eliminado los Aplazamientos y No No
Suspensiones
LEQC_CA_DIASDRV NUMBER(5) Número de Días que permanecen derivados No No
LEQC_CA_DIASEE NUMBER(8) Número de Días en Espera Estructural No No
LEQC_CA_DIAST NUMBER(10) Número de Días Totales No No
LEQC_FX_CARGA DATE Fecha en la que se incorpora en el Sistema No No
LEQC_FX_LOAD DATE Fecha en la que se realiza la descarga del HP- No No
HIS.

La segunda estrella - figura 4.8 – o Estrella de Consulta Externa, consiste en diecisiete
dimensiones específicas, con información acerca de la Agenda, el Centro de Atención Primaria,
Estados del buzón, Motivos de la Anulación, Motivos de Reprogramación, Motivos de Salida,
Motivos de Salida Oficial, Motivos de Solicitud, Prestación, Pruebas Radiológicas, Situación de
la Cita, Situación del Paciente, Tipo de Cita, Tipo de Consulta, Tipos de Entrada, Tipos de
Visita, Origen de Petición de la Cita así como de las quince generales que comparte con Lista
de Espera Quirúrgica, una tabla de hechos LECOEXHE – Consulta Externa - con tres hechos,
cuenta, diase y diast. En el caso de Consulta Externa y dada su complejidad y que la
importancia del tema no es la misma que en espera quirúrgica, el paso de una espera
estructural a una espera no estructural no está clasificada y por lo tanto una vez que el
paciente a modificado su estatus de espera estructural, en la que siempre se empieza, a una
espera no estructural, se mantiene en ese tipo de espera sin más transitos. La tabla de hechos
de Consulta Externa, contiene uno o dos registros por paciente dependiendo de si el paciente
ha realizado alguna reprogramación de su cita o no. La estrella de hechos de Consulta Externa
permite realizar estudios de volumen de pacientes en espera para ser citados o entrevistados y
las razones por las que se están efectuando estas esperas, así como permite realizar estudios

74


estadísticos por sexo y edad del tipo de especialidades más visitadas que se realizan en cada
una de las Provincias y en la Comunidad Autónoma en estudio.

La tabla de hechos LECOEXHE, contiene uno o dos registros por cada una de las citas de un
paciente. Contine un único registro si el paciente no ha reprogramado su cita y dos registros si
a lo largo de la historia de esa cita se ha reprogramado. Si por alguna razón una cita ya
reprogramada, se vuelve a reprogramar, estos registros se van fusionando. Estos registros
están formados, al igual que la de LEQ, por una clave múltiple compuesta por las claves de las
dimensiones asociadas y los hechos:

• cuenta, que siempre toma valor 1,

• diase que acumula el número de días que el paciente está esperando por un motivo
administrativo y

• diast que acumula el total de días desde el ingreso del paciente en lista de espera.

Esta tabla es totalmente dinámica, siendo sensible de actualizarse e insertar registros de forma
constante y masiva todos los días. Existe al menos un registro por cada uno de los pacientes
existentes en Consulta Externa, esté abierto o cerrado el movimiento y un registro adicional si
en algún momento esa cita se ha reprogramado.

Sobre esta tabla se definió la política de acceso por el campo COEX_ID_CEGA, dado que cada
movimiento es propio de un Centro Hospitalario y Provincia.

A continuación se detallan únicamente las tablas de hechos utilizadas en esta estrella:

Atributos
Tabla: LECEXPHE
Descripción: Recoge las Técnicas Radiológicas que han tenido las citas
Tipo: Hechos
CEXP_ID_PRESCEX NUMBER(10) Clave subrogada del DW Yes Yes
CEXP_ID_CITA NUMBER(10) Identificador de la Cita Yes Yes
CEXP_ID_FILABUZ NUMBER(10) Identificador del Buzon Yes Yes
CEXP_ID_CEGA NUMBER(4) Clave subrogada del DW Yes Yes
CEXP_FX_CARGA DATE Fecha en la que se realiza la incorporación al Sist. No No
Tabla: LECOEXHE
Descripción: Recoge la información de las Citas.
Tipo: Hechos
COEX_ID_CITA NUMBER(10) Identificador de la Cita Yes No
COEX_ID_FILABUZ NUMBER(10) Identificador del Buzon Yes No
COEX_ID_AGENDAS NUMBER(10) Clave subrogada del DW Yes Yes
COEX_ID_ORIGPET NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_ESTBUZON NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_MOTANUL NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_MOTREPROG NUMBER(5) Clave subrogada del DW Yes Yes

75


COEX_ID_PACIENTE NUMBER(10) Clave subrogada del DW Yes Yes
COEX_ID_PRIORIDAD NUMBER(2) Clave subrogada del DW Yes Yes
COEX_ID_HOSPITAL NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_MTSALCEX NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_FXINICEX NUMBER(6) Clave subrogada del DW Yes Yes
COEX_ID_FXPREPRG NUMBER(6) Clave subrogada del DW Yes Yes
COEX_ID_FXINIBZN NUMBER(6) Clave subrogada del DW Yes Yes
COEX_ID_FXINICIT NUMBER(6) Clave subrogada del DW Yes Yes
COEX_ID_FXREPROG NUMBER(6) Clave subrogada del DW Yes Yes
COEX_ID_FXSLCRPR NUMBER(6) Clave subrogada del DW Yes Yes
COEX_ID_FXFINCEX NUMBER(6) Clave subrogada del DW Yes Yes
COEX_ID_TIPOENT NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_TIPCONS NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_MOTSALOFI NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_TIPOSCITA NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_PROFESIO NUMBER(10) Clave subrogada del DW Yes Yes
COEX_ID_PROCPAC NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_CEGA NUMBER(4) Clave subrogada del DW Yes Yes
COEX_ID_SITPACIENTE NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_SERVICIO NUMBER(5) Clave subrogada del DW Yes Yes
COEX_ID_GARANTE NUMBER(10) Clave subrogada del DW Yes Yes
COEX_ID_MOTSOL NUMBER(2) Clave subrogada del DW Yes Yes
COEX_ID_TPVISITA NUMBER(2) Clave subrogada del DW Yes Yes
COEX_ID_DIAGCIT NUMBER(10) Clave subrogada del DW Yes Yes
COEX_ID_DIAGALT NUMBER(10) Clave subrogada del DW Yes Yes
COEX_ID_PRESCEX NUMBER(10) Clave subrogada del DW Yes Yes
COEX_ID_CENTROAP NUMBER(7) Clave subrogada del DW No Yes
COEX_ID_INTERV NUMBER(5) Clave subrogada del DW No Yes
COEX_ID_PERIODO NUMBER(6) Clave subrogada del DW No Yes
COEX_ID_FXINIAPL NUMBER(6) Clave subrogada del DW No Yes
COEX_ID_FXFINAPL NUMBER(6) Clave subrogada del DW No Yes
COEX_CA_DIAST NUMBER(7) Número de Días Totales No No
COEX_CA_DIASE NUMBER(7) Número de Días en Espera Estructural No No
COEX_CA_CUENTA NUMBER(1) Variable para realizar los cálculos No No
COEX_FX_CARGA DATE Fecha en la que se realiza la descarga de los No No
sistemas operacionales
COEX_FX_LOAD DATE Fecha en la que se realiza la carga en el sistema No No
dimensional

La tabla de hechos de Lista de Espera Quirúrgica se podría utilizar conjuntamente con la de
Consulta Externa mediante sus dimensiones comunes (paciente, profesional, hospital,
Diagnóstico CIE, Procedimiento CIE y tiempo) para estudiar como puede derivar un paciente
desde un Centro de Atención Primaria a un Centro Hospitalario y como un Motivo de Salida en
Consulta Externa puede derivar en una Circunstancia de Ingreso, así como cuantas Salidas de
Lista de Espera Quirúrgica provocan Primeras Consultas Externas de continuación; pero esta
parte no se ha incluido en el actual Data Warehouse en desarrollo.

A continuación se describen las dimensiones y las tablas de hechos que componen las
estrellas de Lista de Espera Quiúrgica y Consulta Externa

4.3.1.2. Descripción de las dimensiones

Las dimensiones utilizadas en el Data Warehouse son las que se describen de forma breve a
continuación.

Como peculiaridad para todas ellas, se va a indicar un grado de cardinalidad, alto o bajo

76


según el número de registros que contengan y de dinamismo si en las dimensiones se
actualizan, borran o insertan registros de forma habitual o no, razones que se utilizaron para
decidir si la dimensión en estudio se desnormalizaba o no, siguiendo la regla de ante una
dimensión de baja cardinalidad o bajo dinamismo se desnormalizaría premiando en todo
momento el rápido acceso a la información y penalizando la duplicidad de información, más
cuando la mayoría de las dimensiones son totalmente estáticas. Para todas estas
desnormalizaciones se utilizó el mecanismo de look-up como se verá en el capítulo Procesos
de carga y para todas las dimensiones se generaron claves subrogadas mediante creación de
secuencias, como se definen en el mismo punto, para la identificación de todos los registros
creados en el Data Warehouse.

Se van a indicar aquellas dimensiones que se incluyeron en la política de selección por
registros o se marcaron para la VPD, mecanismo que se ha explicado en este mismo capítulo
para la granularidad de selección de los registros según su sensibilidad al Centro Hospitalario,
Dirección Provincial o Servicios Centrales.

Y por otro lado se indicará si las dimensiones disponen de cargas incrementales o no según la
diferencia que se expondrá en el punto Procesos ETL..

Dimensiones

Tipo Dimensión Dimensión Entidad Descripción
Dimensión Dimensión Diagnósticos CIE LECAPIDI Capitulo de los Diagnósticos CIE
Común LESECNDI Sección de los Diagnósticos CIE
LECATGDI Categoría de los Diagnósticos CIE
LESCTGDI Subcategoría de los Diagnósticos CIE
LESCLFDI Subclasificación de lDiagnósticos CIE
Dimensión Estructura LEGANADI Área de Gestión Analítica
Funcional LEGFNCDI Grupo funcional
LEMAESDI Servicios Maestros
LESERVDI Servicios locales al centro (GFH)
Dimensión Financiación LEFIPADI Financiación del Paciente
Paciente LEGARTDI Garante
Dimensión Geográfica LECMATDI Comunidad Autónoma
LEPOBLDI Población
LEPROVDI Provincias
Dimensión Hospital LESECTDI Sectores
LEHOSPDI Hospitales
Dimensión Hospitales CEGA LECEGADI Centros de Gasto
LEPBRFDI Población de Referencia
Dimensión Intervalos LEBOEIDI Intervalos BOE para RDQ
LEBOAIDI Intervalos BOA para RDQ
LEITVCDI Intervalos de CEX
LEINTVDI Intervalos para CEX y RDQ
Dimensión Periodos LEPERDDI Periodos disponibles de estudio
Dimensión Prioridad LEPRIODI Prioridad
Dimensión Procedencia del LECPRODI Procedencia del Paciente
Paciente LEPPACDI Procedencia oficial del paciente
Dimensión Procedimientos LESCLPDI Subclasificación de Procedimientos CIE
CIE LECAPPDI Capitulo de los Procedimientos CIE
LESECPDI Sección de los Procedimientos CIE
LECATPDI Categoría de los Procedimientos CIE
LESCTPDI Subcategoría de Procedimientos CIE

77


Dimensión Profesionales LEPROFDI Profesionales
Dimensión Sexo LESEXODI Sexo
Dimensión Temporal LEYEARDI Año de Estudio
LEQUTEDI Trimestre de Estudio
LEMNTHDI Mes de Estudio
LEDATADI Día de Estudio
Dimensión Pacientes LEPACTDI Datos Personales de los pacientes
LEPACDDI Datos de Domicilio del paciente
Dimensión de Dimensión Agendas LEAGAGDI Dimensión de Agrupación de Agendas
CEX LEAGENDI Dimensión de Agendas
Dimensión Centro Atención LECAPRDI Centros de Atención Primaria
Primaria
Dimensión Estados Buzón LEEBUZDI Centros de Atención Primaria
Dimensión Motivos de LEHSMADI Histórico Motivos de Anulación
Anulación LEMTANDI Motivos de Anulación
Dimensión Motivos de LEDWMRDI Motivos de reprogramación oficiales de
Reprogramación descarga estándar
LEMAMRDI Motivo de aplazamiento asociado
LEMTRPDI Motivos de reprogramación locales al centro
Dimensión Motivos de Salida LEMSHIDI Motivos de Salida Históricos
LEMTSLDI Motivos de Salida
Dimensión Motivos de Salida LEMSLODI Motivos de salida oficial
Oficial
Dimensión Motivos de LEMSOLDI Motivos de Solicitud de consulta
Solicitud
Dimensión Prestación LEPCAGDI Agrupación al que pertenece la prestación
LEPCEXDI Prestaciones
Dimensión Pruebas LETROFDI Pruebas radiológicas de la descarga
Radiológicas estándar
LETCRDDI Técnicas Radiológicas
Dimensión Situación Cita LESCITDI Situación de la Cita
Dimensión Situación Paciente LESPACDI Situación del Paciente
Dimensión Tipos de Cita LETPCTDI Tipos de Cita
Dimensión Tipos de Consulta LETPCNDI Tipos de Consulta
Dimensión Tipos de Entrada LETPENDI Tipos de Entrada
Dimensión Tipos de Visita LETPVSDI Tipos de Visita
Origen de Petición de Cita LEORPCDI Origen de Petición de Cita
Dimensión de Dimensión Circunstancias de LECLINDI Clasificación de Circunstancias de Inclusión
LEQ Inclusión LECRINDI Circunstancias de Inclusión
Dimensión Motivos de Salida LENMSLDI Motivos de Salida Oficial
LEMSALDI Motivo de Salida
Dimensión Motivos de LECSGADI Aplazamiento relacionado
Suspensión de Garantía LEMSGADI Motivo de Suspensión de Garantía
Dimensión Perdida de LEPGARDI Motivos de Perdida de Garantia
Garantia
Dimensión Procesos LEPROCDI Estructura donde se recogen los procesos.
LEPROCDS Estructura de desacoplo
Dimensión Rechazos de LEAGRDDI Agrupación de Rechazos de Derivación
Derivación LEREDEDI Rechazos de Derivación
Dimensión Situación de LEGAAGDI Agrupación de la situación de garantía
Garantía LEGARADI Situación de la Garantía
Dimensión Espera LESITBDI Situación BOE
Dimensión Situación en Lista LESTAGDI Agrupación de la situación
LESITLDI Situación en Lista
Dimensión Tipos de Actividad LETPACDI Tipos de Actividad
Dimensión Tipos de LEAGANDI Agrupación de Anestesia
Anestesia LETPANDI Tipos de Anestesia
Dimensión Tipos de Garantía LETPGADI Tipo de Garantía
Dimensión Tipos de Lista LETPLSDI Tipos de Lista
LELISRDI Listas de Espera locales del centro

Las dimensiones se pueden clasificar de la siguiente manera:

Dimensiones comunes: Dimensiones utilizadas por más de una de las estrellas del sistema
de análisis (Estructura Funcional, Diagnósticos CIE, etc.).

78


Dimensiones específicas: Dimensiones utilizadas únicamente por una de las estrella del
sistema de análisis (Estado Buzón, Perdida de Garantía , etc.).

1. DIMENSIONES COMUNES

1.1. DIMENSIÓN DIAGNÓSTICOS CIE: Se pueden utilizar de diferente manera:

● Diagnóstico A: Primer diagnóstico que se le da al paciente en el Registro de
Demanda Quirúrgica

● Diagnóstico B: Segundo diagnóstico que se la da al paciente en el Registro de
Demanda Quirúrgica

Esta dimensión se basa en la Clasificación Internacional de Enfermedades, clasificación
oficial que una vez definida no se modifica. Son idénticas para todos los Centros, aunque
algunos tratan unos diagnósticos más que otros y por lo tanto en sus tablas maestras
cargan unos valores y no otros. En el Data Warehouse se cargan todos los valores
diferentes en código y descripción que vengan de los diferentes Centros Hospitalarios, no
diferenciando entre los Centros, dado que todos los códigos y descripciones deben ser las
mismas.

Dado que es una dimensión estática que no necesita mantenimiento, se creó una carga
inicial pero no una carga incremental, aunque se podría gestionar la carga de nuevos
diagnósticos siempre y cuando el nuevo Diagnóstico cumpla la CIE-9 ó CIE-10 por la que
se está gestionando en estos momentos. En el supuesto que se intente generar un
registro que no cumpla la jerarquía o propiedades de los existentes, la carga no funcionará
paralizando la creación y exigiendo una intervención manual como se indica en el punto:
Procesos ETL.

Esta dimensión se compone de diferentes entidades para la clasificación de los
diagnósticos según una subclasificación, subcategoría, categoría, sección y capítulo. Dado
que los estudios conllevarán distintos tipos de clasificaciones por los diferentes niveles de
los diagnósticos y que el volumen de datos puede ser de un millar de registros en total y
que su mantenimiento es nulo, se desnormalizó la dimensión incluyendo en cada una de
las capas inferiores el código y descripción de los niveles superiores, premiando la
búsqueda al ahorro de espacio. Para la desnormalización y carga de las diferentes
entidades se utilizó el mecanismo de look-up.

Esta tabla es de libre acceso para todos los niveles de usuarios.

Entidades:

79


Entidad Descripción
LECAPIDI Capitulo de los Diagnósticos CIE
LESECNDI Sección de los Diagnósticos CIE
LECATGDI Categoría de los Diagnósticos CIE
LESCTGDI Subcategoría de los Diagnósticos CIE
LESCLFDI Subclasificación de los Diagnósticos CIE

Representación grafica de las entidades que componen dicha dimensión

LECAPIDI

R/1

LESECNDI
R/2

LECATGDI

R/3

LESCTGDI
R/4

LESCLFDI

1.2. DIMENSIÓN ESTRUCTURA FUNCIONAL: de un Centro Hospitalario. Existe una
estructura de Servicios, Grupo funcional Homogéneo… en la que se definen las unidades
básicas que prestan actividad y determina la inclusión del paciente en el registro de
pacientes en espera.

Dimensión estática, aunque se puede dar la circunstancia de crear nuevos Servicios
atendidos por el Centro Hospitalario, esto hace que se disponga de una carga inicial y una
carga incremental que gestione la creación de nuevos Servicios. Cualquier cambio en
estas entidades deben cumplir las reglas definidas en la jerarquía existente o de lo
contrario provocará el fallo en la carga incremental y la posible paralización de la carga del
Centro que intente dar de alta ese registro, exigiendo la intervención humana.

Esta dimensión se compone de diferentes entidades para la clasificación de Servicios
dentro del Centro Hospitalario. Dado que los informes requeridos, conllevarán distintos
tipos de estudios por los diferentes niveles administrativos de Servicios y que el volumen
de datos no llega a la centena, se prefirió desnormalizar la dimensión incluyendo en cada
una de las capas inferiores el código y descripción de los niveles superiores, premiando la
búsqueda al ahorro de espacio y siendo casi núlo el mantenimiento de estas entidades.

Esta tabla es de libre acceso para todos los niveles de usuarios

Entidades:


80


LEGANADI Área de Gestión Analítica
LEGFNCDI Grupo funcional
LEMAESDI Servicios Maestros
LESERVDI Servicios locales al centro (GFH)


LEGFNCDI LEGANADI

R/74 R/24

LEMAESDI

R/22

LESERVDI

1.3. DIMENSIÓN FINANCIACIÓN PACIENTE: Indica la financiadora que corre con los gastos
de la operación, ya sea la Seguridad Social o cualquier otra Financiadora.

Esta dimensión es estática, aunque puede ocurrir que un garante pase de una
financiadora a otra o incluso desaparecer y aparecer nuevos, el volumen de cambios es
bastante reducido y normalmente anual. Dispone de una carga inicial y otra incremental
para ir gestionando estos cambios.

Esta dimensión incluye la financiadora y los garantes que son financiados por ellas.
Aunque no se hacen muchos estudios según esta dimensión, los que se realicen pueden
ser por financiadora o garante y dado su bajo mantenimiento se prefirió desnormalizar la
dimensión incluyendo en el garante el código y descripción de la financiadora que la acoge
mediante el mecanismo de look-up y premiando la rapidez en los accesos, al ahorro de
espacio, que sería mínimo.

La financiadora y garante están codificados de forma libre por cada Centro Hospitalario, ya
que aunque coincidan en nombre y clasificación, cada Centro los ha ido registrando según
trabajaban con ellos, codificándolos a su manera. Las posibilidades de unificación, que
teníamos, eran codificar de nuevo las entidades para igualar las codificaciones en los
diferentes Centros y hacer un “barrido” de los movimientos para volver a codificar la
información histórica de los Centros o mantener la codificación de cada Centro. El cliente
decidió que la segunda opción era la mejor, dado que muchos Centros trabajaban por
código y la nueva codificación conllevaría erróres humanos que preferían evitar. Por esta
razón y dado que se tenía que ver la información a los tres niveles de usuarios se
incluyeron los campos FIPA_CO_CEGA y GART_CO_CEGA respectivamente en las

81


entidades y se definió sobre ellas la política de acceso de registros o VPD de manera que
cada Centro Hospitalario a Dirección Provincial viera las financiadoras o garantes que
ellos habían dado de alta y con las descripciones que ellos habían definido.

Entidades:
LEFIPADI Financiación del Paciente
LEGARTDI Garante


LEFIPADI

R/5

LEGARTDI

1.4. DIMENSIÓN GEOGRÁFICA: No se trata de una dimensión que aparezca de forma directa
en la explotación de datos, pero forma parte de otras dimensiones como la de Hospital y
Pacientes. Permite realizar estudios agregados o discretos, por distinto tipo de agrupación,
Comunidad Autónoma, Provincia o Localidad.

Esta dimensión es estática, existiendo un mantenimiento nulo, por lo que dispone de una
carga inicial; pero no incremental. De hecho, se podía haber generado la información a
través de un proceso de post-instalación para cargar la dimensión durante el proceso de
creación de la base de datos dimensional; pero se prefirió cargarla desde el operacional
por homogenización y facilidad del proceso

Dado que los estudios a nivel de Servicios Centrales pueden incluir navegación por las
diferentes Provincias o Poblaciones y que el volumen de datos es reducido, se prefirió
desnormalizar la dimensión incluyendo en cada una de las capas inferiores el código y
descripción de los niveles superiores, premiando la búsqueda al ahorro de espacio.


Entidades:
LECMATDI Comunidad Autónoma
LEPROVDI Provincias
LEPOBLDI Población


82


LECMATDI

R/19

LEPROVDI

R/31

LEPOBLDI

1.5. DIMENSIÓN HOSPITAL: Conjunto de Hospitales con los que operera la Comunidad para
la derivación de pacientes para realizar la intervención que tuviera pendiente en el
Registro de Demanda.

Esta dimensión es estática con un mantenimiento nulo. Dispone únicamente de una carga
inicial y no incremental, cualquier tipo de menatenimiento se debe de realizar a mano por
un Administrador que conozca la estructura funcional de la aplicación.

La dimensión Hospital permite clasificar la información de forma más clara; pero no ayuda
a una toma de decisiones clara y concisa, aunque dado que los estudios a nivel de
Servicios Centrales pueden incluir navegación por las diferentes Provincias o Poblaciones,
dimensión Geografía con la que interrelaciona y que el volumen de datos no llega a la
centena, se prefirió desnormalizar la dimensión, incluyendo en cada una de las capas
inferiores el código y descripción de los niveles superiores, premiando la búsqueda al
ahorro de espacio y siendo casi nulo el mantenimiento de estas entidades.


Entidades:
LEPOBLDI Población
LESECTDI Sectores
LEHOSPDI Hospitales


LEPOBLDI LESECTDI

R/18

R/32

LEHOSPDI

1.6. DIMENSIÓN HOSPITALES CEGA: Centros Hospitalarios que participan en la gestión de
la Lista de Espera de la Comunidad Autónoma en estudio y por lo tanto de los que se
dispone de información, gestionan las descargas de los sistemas operacionales con los
que se trabaja en el Data Warehouse y se carga la información en el mismo para la toma

83


de decisiones pertinentes. Cada Hospital dispone de una población de referencia anual,
esta población es una estimación del número de pacientes distintos que pueden llegar a
ser atendidos en el Hospital durante el año.

Todos los Centros son identificados por cuatro dígitos únicos o CEGA, cuyos dos primeros
dígitos coinciden con el código de Provincia Geográfica y que es el código que ha
permitido referenciar la información privada de cada Centro o Provincia, transmitiéndose
por todas las dimensiones que lo necesitaran y creando la politica de selección de
registros o VPD, comentada en: Diseño y construcción. Planteamiento de la solución.

La dimensión Hospitales CEGA es estática, de nulo mantenimiento que indica una carga
inicial; pero la no existencia de una carga incremental.

Dimensión normalizada en la que hay que destacar la peculiaridad de la entidad
LEPBRFDI, que indica la Población de Referencia de cada Centro e implica la inserción de
un registro por Centro una vez al año, pudiéndo eliminarse los registros de años de los
que se estime no se vayan a obtener reports históricos que los necesiten.

Dado que estas entidades incluyen información sensible al Centro Hospitalario al que
hacen referencia se incluyeron los campos CEGA_ID_CEGA y PBRF_ID_CEGA
definiendo sobre ellas la politica de acceso de registros o VPD, de manera que cada
Centro Hospitalario o Dirección Provincial vea l ainformación referente al Hospital sobre el
que disponga de permisos.

Entidades:
LECEGADI Centros de Gasto
LEPBRFDI Población de Referencia


LECEGADI

R/158

LEPBRFDI

1.7. DIMENSIÓN INTERVALOS: contiene los intervalos publicados por el BOE Estos
intervalos son necesarios para clasificar las intervenciones según se quiera estudiar. Dado
que el BOE o el BOC (Boletín Oficial de la Comunidad) tienen diferentes intervalos de
estudio, la Comunidad intenta ser más restrictivo de manera que salten las alarmas de la
Comunidad con antelación al Estado y de esta manera dar solución a posibles problemas
más molestos, se incluyeron ambas clasificaciones para ver la información de una manera
u otra.

84


El número de registros de estas entidades, es mínimo, menos de diez intervalos de
estudio, ya sea en el BOE o en el BOC y bastante estable, ya que no existen muchas más
posibilidades más allá de mensual, quincenal, anual, tri-quincenal o trimestral y los
estudios pasan de una clasificación a la otra de forma muy rápida, se desnormalizó la
dimensión premiando la rapidez de acceso al consumo de almacenamiento.

Todos los usuarios de la aplicación pueden acceder a la información existente en esta
dimensión.

Entidades:
LEBOEIDI Intervalos BOE para RDQ
LEBOAIDI Intervalos BOA para RDQ
LEITVCDI Intervalos de CEX
LEINTVDI Intervalos para CEX y RDQ


LEBOEIDI

R/142
LEBOAIDI LEITVCDI

R/143 R/172
LEINTVDI

1.8. DIMENSIÓN PERIODO: Son periodos de estudio de diferente naturaleza. Utilizándolos se
podrán hacer estudios por año, mes, quincena e incluso día.

Esta dimensión se incorporó como soporte y ayuda de selección rápida en la clasificación
de los movimientos en los estudios de movimientos abiertos durante un determinado
periodo. En los Centros Hospitalarios todos los estudios se centran al final en movimientos
abiertos desde el principio de un mes y el final del mes. Aunque pueden desear ver qué
movimientos están abiertos en un determinado día, lo habituall es centrarse en los casos
abiertos desde el día 1 de un mes y el día 15, 30/31 del mismo, por lo que se definió una
dimensión en la que se marcaba la fecha de inicio y fin de un mes o trimestre y su clave
subrogada era incorporada a cada movimiento, de manera que a la hora de gestionar
fechas se realizaban menos operaciones que las que se llevaría al operar con las fechas
de apertura y cierre del movimiento.

Esta información es de libre acceso a todos los usuarios de la aplicación.

Entidades:
LEPERDDI Periodos disponibles de estudio


85


LEPERDDI

1.9. DIMENSIÓN PRIORIDAD: en función de los días en los que debe ser atendido el paciente
para una indicación quirúrgica.

Sólo existen tres prioridades dependiendo de cómo se asume de rápido la solución de la
patología, por lo que no se crearón cargas iniciales a través de Oracle Warehouse Builder,
ni mucho menos incrementales. Se insertaron los registros como paso de post-instalación
a la creación de la base datos.

Esta dimensión disponía de diferentes descripciones según los Centros; pero dado que su
tamaño es insignificante y su importancia máxima y dado que podía herir la susceptibilidad
de los pacientes, se decidio corregir y poner en todos los Centros las mismas
descripciones, siendo Urgente, Alta y Preferente eliminando términos como Alta, Media y
Baja.


Entidades:
LEPRIODI Tipos de Prioridad


LEPRIODI

1.10. DIMENSIÓN PROCEDENCIA DEL PACIENTE: contiene los posibles ámbitos de
procedencia sanitaria de un paciente.

Dimensión estática, de baja cardinalidad y nulo mantenimiento, que indica una
desnormalización para favorecer el acceso a la información en consultas a pesar de que
se almacena información duplicada.

Por otro lado, indica la creación de una carga inicial; pero la no existencia de carga
incremental, que permitiría la incorporación renueva información siempre de foram manual
a través de un Administrador con conocimientos funcionales de la aplicación y no desde
una posible mala gestión desde un Centro Hospitalario.

Los ámbitos desde los que puede proceder un paciente, son iguales para los diferentes
Centros Hospitalarios; pero los Servicios Centrales quieren, además, agruparlos de forma
específica, por lo que la dimensión se compone de dos entidades estables de baja
cardinalidad, donde se ha vuelto a premiar la velocidad a la cantidad de almacenamiento y
al nulo mantenimiento, desnormalizando la dimensión. Se ha utilizado la gestión de look-

86


up para la desnormalización de la dimensión.


Entidades:
LECPRODI Procedencia del Paciente
LEPPACDI Procedencia oficial del paciente


LECPRODI

R/6

LEPPACDI

1.11. DIMENSIÓN PROCEDIMIENTOS CIE: Se pueden utilizar de diferente manera:

● Procedimiento A: Primer procedimiento que se le da al paciente en el Registro de
Demanda Quirúrgica

● Procedimiento B: Segundo procedimiento que se la da al paciente en el Registro de
Demanda Quirúrgica

Esta dimensión, al igual que la dimensión DIAGNÓSTICOS CIE, se basa en la
Clasificación Internacional de Enfermedades, clasificación oficial que una vez definida no
se modifica. Son idénticas para todos los Centros, aunque algunos tratan unos
procedimientos más que otros y por lo tanto en sus tablas maestras cargan unos valores y
no otros. En el Data Warehouse se cargan todos los valores diferentes en código y
descripción que vengan de los diferentes Centros Hospitalarios, no diferenciando entre los
Centros, dado que todos los códigos y descripciones deben ser las mismas.

Dado que es una dimensión estática que no necesita mantenimiento, se creo una carga
inicial pero no una carga incremental, aunque se podría gestionar la carga de nuevos
procedimientos siempre y cuando el nuevo Procedimiento cumpla la CIE-9 ó CIE-10 por la
que se está gestionando en estos momentos. En el supuesto que se intente generar un
registro que no cumpla la jerarquía o propiedades de los existentes, la carga no funcionará
paralizando la creación y exigiendo una intervención manual como se indica en el punto:
Procesos ETL.

Esta dimensión se compone de diferentes entidades para la clasificación de los
procedimientos según una subclasificación, subcategoría, categoría, sección y capítulo.
Dado que los estudios conllevarán distintos tipos de clasificaciones por los diferentes

87


niveles de los procedimientos y que el volumen de datos puede ser de un millar de
registros en total y que su mantenimiento es nulo, se desnormalizó la dimensión
incluyendo en cada una de las capas inferiores el código y descripción de los niveles
superiores, premiando la búsqueda al ahorro de espacio. Para la desnormalización y
carga de las diferentes entidades se utilizó el mecanismo de look-up.

Esta tabla es de libre acceso para todos los niveles de usuarios.

Entidades:
LESCLPDI Subclasificación de los Procedimientos CIE
LECAPPDI Capitulo de los Procedimientos CIE
LESECPDI Sección de los Procedimientos CIE
LECATPDI Categoria de los Procedimientos CIE
LESCTPDI SubCategoria de los Procedimientos CIE


LECAPPDI

R/1 LESECPDI

R/2 LECATPDI

LESCTPDI
R/3
R/91
LESCLPDI

1.12. DIMENSIÓN PROFESIONALES dispone del personal facultativo del hospital que
prescribe la realización de la actividad programada.

Dimensión normalizada. Cada uno de los Centros Hospitalarios dispone de sus propios
profesionales y el mantenimiento de esta dimensión es casi nulo, existiendo altas; pero
pocas modificacines o bajas, dado que siempre hay que mantener el histórico, por lo que
existe una carga inicial y una carga incremental en la que sólo se gestionan altas.

Dado que esta entidad incluyen información sensible al Centro Hospitalario al que hace
referencia se incluyó el campo PROF_ID_CEGA, definiendo sobre ellas la politica de
acceso de registros o VPD, de manera que cada Centro Hospitalario a Dirección Provincial
ve los porfesionales que han dado de alta y con las descripciones que ellos han definido.

Entidades:
LEPROFDI Profesionales


LEPROFDI

88


1.13. DIMENSIÓN SEXO: indica el sexo del paciente.

Esta dimensión es totalmente estable incluyendo los valores de DESCONOCIDO, para los
movimientos en los que el paciente no esta determinado o por el nombre no se ha podido
determinar el sexo e INDETERMINADO para pacientes en transito de operaciones de
sexo.

Fue una de las dimensiones que aún con lo pequeña y lo mínimo de sus registros, sólo
cuatro, hubo que recodificar y realizar transformaciones básicas, en los Centros dado que
cada uno había utilizado diferentes codificaciones como 0/1, Hombre/Mujer, H/M,
Masculino/Femenino, M/F.

La cardinalidad de esta dimensión es insignificante y se decidió no crear carga inical, sino
insertar los registros como paso de post-instalación una vez creada la base de datos
dimensional.

Entidades:
LESEXODI Sexo


LESEXODI

1.14. DIMENSIÓN TEMPORAL: dimensión clave en cualquier Data Warehouse. Se crearon
diferentes entidades para realizar estudios de forma más rápida, la entidad diaria, la
trimestral, mensual y anual.

Esta dimensión es totalmente estable dado que se incorporaron todos los registros
necesarios desde el 2000, fecha de la que había estudios grabados, hasta el 2050, fecha
en la que se supone que habrá que realizar el mantenimiento de dicha tabla para
incorporar nuevos registros de fecha de inicio y fin de los periodos con posterioridad a esa
fecha.

Dado la utilidad de estas entidades y que su utilización es completa se desnormalizó
totalmente para los estudios a realizar.

Esta dimensión es común y de libre acceso para todos los usuarios de la aplicación.

Entidades:
LEYEARDI Año de Estudio
LEQUTEDI Trimestre de Estudio
LEMNTHDI Mes de Estudio
LEDATADI Día de Estudio

89



LEYEARDI

R/53 LEQUTEDI

LEMNTHDI
R/54
R/55 LEDATADI

1.15. DIMENSIÓN PACIENTES recoge todos los pacientes que tienen relación con la Lista
de Espera, engloba una serie características relativas al paciente y al episodio.

Dimensión normalizada. Cada uno de los Centros Hospitalarios dispone de sus propios
pacientes y el mantenimiento de esta dimensión es bastante dinámico, dado que
constantemente se dan pacientes de alta o se corrigen sus datos. Las bajas son nulas a
no ser que se realice una FUSIÓN o identificación de dos pacientes como uno sólo dado
de alta dos veces debido a que un dato de identificación incorrecto o incompleto.

Dado que la información almacenada sobre el PACIENTE es mucha, nombre, apellidos,
dirección, teléfonos de contacto, nacionalidad… y que parte de esta información es
estática una vez conocida, nombre, apellidos, DNI y bastante dinámica otra dirección,
teléfono… se decidió dividir esta dimensión en dos LEPACTDI con la información estable
del paciente y LEPACDI con los datos del domicilio o más dinámica de manera que no se
trabajara con tanto información en los mantenimientos o selecciones.

Estas entidades son sensibles al tipo de usuario, por lo que disponen de los atributos
PACT_CO_CEGA y PATD_CO_CEGA para incluirlas en la política de selección de
registros o VPD.

Entidades:
LEPACTDI Datos Personales de los pacientes
LEPOBLDI Población
LEPACDDI Datos de Domicilio del paciente


LEPACTDI LEPOBLDI

R/20
R/95

LEPACDDI

2. DIMENSIONES DE CEX – CONSULTA EXTERNA

90


2.1. DIMENSIÓN AGENDAS: pertenecen a un Servicio, al que pertenecerán los facultativos
que presten sus servicios; pero asimismo, también pertenecen a un Centro.

La peculiaridad de las agendas es que toda cita debe ir asociada a una agenda que tiene
un periodo de vida, se abre en un determinado periodo de tiempo y se cierra una vez
transcurrido un determinado periodo de tiempo. Se puede decir que una agenda viene
definida por un Servicio o especialidad, un periodo de tiempo y un grupo de profesionales
que la puede atender.

En cualquier momento un especialista puede decidir incluir un paciente en una
determinada agenda; pero si esta todavía no está abierta, el paciente se coloca en un
buzón a espera de abrir la agenda, donde se le incluye de forma inmediate según esa
agenda se abre y se le elimina del buzón donde ha estado esperando.

Esta dimensión se puede tratar como estática ya que sólo se indica si está abierta o no y
el resto de la información es estática a lo largo del tiempo.

Existe la posibilidad de agrupar las agendas, según Especialidades y dados los estudios
realizados se ha desnormalizado la dimensión para incluir toda la información del Servicio
en la entidad Agenda y obtener mayor rendimiento en las consultas.

Se dispone de una carga inicial y cargas incrementales para gestionar las nuevas agendas
que secrean en todos los Centros.

Esta dimensión es propia de cada centro, por lo que se definieron los campos
AGAG_CO_CEGA y AGEN_CO_CEGA respectivamente para definir la política de acceso
de registros o VPD.

Entidades:
LEAGAGDI Dimensión de Agrupación de Agendas
LEAGENDI Dimensión de Agendas


LEAGAGDI

R/33
LEAGENDI

2.2. DIMENSIÓN CENTRO ATENCIÓN PRIMARIA: cuando la cita procede de un Centro de
Atención Primaria. Además incluye los CIAS de los profesionales adscritos a dicho Centro.

91


Esta dimensión identifica la procedencia dentro de la Sanidad Pública de la que procede el
paciente, si no ha entrado por urgencias y se le ha derivado de un estudio previo que
aconseja su visita a un centro de Especialidades.

Es una dimensión estable, sin grandes modificaciones y con un número de registros fijo
que varía muy poco a lo largo del tiempo, de la que sólo se dispone de una carga inicial y
cualquier incorporación nueva implica la gestión de un Administrador que conozca la
aplicación a nivel funcional.

En ella se definió el campo CAPR_CO_CEGA para la selección de registros según el
Centro Hospitalario en estudio, basándonos en la VPD ya definida.

Entidades:
LECAPRDI Centros de Atención Primaria


LECAPRDI

2.3. DIMENSIÓN ESTADO DEL BUZÓN: contiene los posibles estados relacionados con las
peticiones del Buzón. Todas las cita que no proceden de un buzón se encontrarán en
estado “SIN BUZÓN”.

Todas las citas deben ser registradas en una agenda para su tratamiento por un
profesional; pero si la solicitud de cita se crea con anterioridad a la apertura o creación de
la agenda, algunos pacientes proceden de segundas visitas con periodicidad anual o
incluso mayor y por lo tanto no se sabe qué Servicio, Profesional o periodo exacto de
tiempo va a cubrir esa especialidad un año más tarde, estas citas se registran en un
buzón que se va distribuyendo por las agendas según estas se crean. Dado que ninguna
información es borrada del sistema, estas citas se guardan como “citadas”, “canceladas” o
“reprogramadas” según sea la historia de la misma.

Esta dimensión es dinámica, creándose registros constantemente, aunque no con el
mismo dinamismo que en agendas, lo que implica una carga inicial en la que se cargaron
todos los registros históricos que se mantenían y se creó una carga incremental de
ejecución diaria.

Sobre esta dimensión los estudios no son extensos a no ser, número de registros en el
buzón o tiempo transcurrido en él antes de entrar en agendas.

Entidades:

92


LEEBUZDI Estados del Buzón


LEEBUZDI

2.4. DIMENSIÓN MOTIVOS ANULACIÓN: contiene los diferentes motivos de anulación por
los que puede pasar una cita en lista de espera.

Dimensión estática y de cardinalidad reducida. La peculiaridad de esta dimensión reside en
la homogeneización de la misma en todos los Centros para consulta de la información
estándar y codificación nueva debido al cambio en los BBOO (Boletines Oficiales); pero se
tenía interés en mantener la información anterior dada la inmensa cantidad de información
de movimientos CEX existente y la no exactitud de correspondencia entre una codificación
y otra, por ello, se definieron dos entidades relacionadas en las que se hicieron
corresponder los códigos actuales con los anteriores y se desnormalizaron para un rápido
acceso a la información.

Esta dimensión dispone de una carga inicial; pero no así de incremental, dado que se
entiende que es una dimensión fija.

Esta dimensión es accesible por todos los usuarios de la aplicación.

Entidades:
LEHSMADI Historico Motivos de Anulación
LEMTANDI Motivos de Anulación


LEHSMADI

R/26
LEMTANDI

2.5. DIMENSIÓN MOTIVOS REPROGRAMACIÓN: contiene los diferentes motivos de
reprogramación por los que puede pasar una cita en lista de espera.

Esta dimensión, como muchas de las configurables por el propio Centro, disponía de
codificaciones diferentes para cada uno de los Centros y se decidió mantener esa
codificación aunque se debería crear una nueva que los agrupase y además indicar una
codificación uniforme para la información solicitada por Servicios Centrales. Para resolver
este problemática se introdujeron los campos DWMR_CO_CEGA, MAMR_CO_CEGA y

93


MTRP_CO_CEGA en cada una de las entidades, que permite seleccionar la información
por la política de selección de registros o VPD.

Por otro lado y dada la baja cardinalidad de las tablas y su nulo mantenimiento, dado que
son tablas que no se modifican una vez creadas y cargas, se decidio desnormalizarlas para
un más rápido acceso a la información, como en todos los procesos la desnormalización se
obtuvo a partir de look-up de busqueda de información e ingreso en el resto de las
entidades de la dimensión.

Esta dimensión dispone de una carga inicial; pero de carga incremental dado que es una
dimensión estática.

Entidades:
LEDWMRDI Motivos de reprogramación oficiales de descarga estandar
LEMAMRDI Motivo de aplazamiento asociado
LEMTRPDI Motivos de reprogramación locales al centro


LEDWMRDI

R/27 LEMAMRDI

LEMTRPDI
R/28

2.6. DIMENSIÓN MOTIVOS SALIDA: por los cuales una cita sale de consulta Externa.

Dimensión estática y con cardinalidad reducida. Esta es otra de las dimensiones que se
homogeneizaron a la largo de la creación del Data Warehouse para que todos los Centros
pudieran ver y referenciar la misma información; pero se tenía interés en mantener la
información anterior dada la inmensa cantidad de información de movimientos CEX
existente y la no exactitud de correspondencia entre una codificación y otra, Por ello se
definieron dos entidades relacionadas en las que se hicieron corresponder los códigos
actuales con los anteriores y se desnormalizaron para un rápido acceso a la información.

Esta dimensión por sus características dispone de una carga inicial; pero no así de carga
incremental, dado que ningún registro debe ser cambiado.


Entidades:
LEMSHIDI Motivos de Salida Históricos
LEMTSLDI Motivos de Salida

94



LEMSHIDI

R/97

LEMTSLDI

2.7. DIMENSIÓN MOTIVOS SALIDA OFICIAL: contiene los diferentes motivos de salida por
los que puede pasar una cita en lista de espera.

Esta dimensión incluía información totalmente nueva por la que los Servicios Centrales
tenía interés en reorganizar la salida de las citas y aunque el nombre llevaba a considerarla
similar a MOTIVOS SALIDA, su tratamiento y codificación no tenía nada que ver,
creándose dos dimensiones totalmente independientes.

Esta dimensión es estática sin necesidad de mantenimiento alguno y dada su baja
cardinalidad y su no existencia en los Centros actuales, su carga se hizo como proceso
post-isntalación dela base de datos dimensional, no existiendo carga inicial ni incremental.

La información de esta dimensión es genérica para todos los usuarios de la aplicación.

Entidades:
LEMSLODI Motivos de Salida Oficiales


LEMSLODI

2.8. DIMENSIÓN MOTIVOS DE SOLICITUD: esta dimensión muestra los motivos por los que
un profesional solicita la cita de una Consulta Especializada.

Es una dimensión estática sin posibilidad de mantenimiento. Se crean los valores en la
carga inicial y no dispone de carga incremental, cualquier creación o modificación de los
valores de la misma deben hacerse a mano por el Administrador correspondiente.

La información de esta dimensión es genérica para todos los usuarios de la aplicación.

Entidades:
LEMSOLDI Motivos de Solicitud


95


LEMSOLDI

2.9. DIMENSIÓN PRESTACIÓN: indica la prestación para la que ha sido solicitada la cita.
Prestación es una agrupación de Servicios y Pruebas que resumen toda la atención dada
al paciente.

Esta dimensión es algo dinámica; pero de baja cardinalidad en la que la información se ve
de formas diferentes, tal cual las quiere ver el Centro Hospitalario con la descripción dada
por el Centro y agrupadas según las quiere registrar Servicios Centrales. Dado que los
Centros no asumen el cambio se decide nuevamente incluir el campo PCEX_CO_CEGA,
que hará que los Centros Hospitalarios accedan a los registros con la política VPD y los
Servicios Centrales agrupen la información como les interesa.

Existen cargas iniciales e incrementales para la gestión de los posibles cambios en las
prestaciones ejercidas por cada Centro.

Entidades:
LEPCAGDI Agrupación al que pertenece la prestación
LEPCEXDI Prestaciones


LEPCAGDI

R/98
LEPCEXDI

2.10. DIMENSIÓN PRUEBAS RADIOLÓGICAS: indica las técnicas diagnósticas que le han
sido efectuadas en una cita, cuando esta ya ha sido efectuada.

Dimensión para cargar de valor informativo el movimiento y que indica las pruebas
radiológicas que se pueden realizar en el centro. Cada Centro tiene clasificadas y definidas
sus pruebas, de manera que se definen los campos TROF_CO_CEGA y TCRD_CO_CEGA
para acceso a la información de forma selectiva por la política de VPD.

Es una dimensión con cierto nivel de dinamismo, por lo que aunque se desnormaliza para
un rápido acceso a la información y a la generación de informes para la toma de
decisiones, se dispone de una carga inicial y una carga incremental para realizar de forma
fácil la incorporación de nuevos registros y cambios sobre ellos.

96


Entidades:
LETROFDI Pruebas radiológicas de la descarga estándar
LETCRDDI Técnicas Radiológicas


LETROFDI

R/99 LETCRDDI

2.11. DIMENSIÓN SITUACIÓN DE LA CITA: Indica el estado en el que se encuentra la cita
en un momento determinado.

Es una dimensión estable y de cardinalidad muy baja. Dado que los Centros tienen los
mismos conceptos se resume a los mismos valores y no existe mantenimiento de la misma.
No existen cargas iniciales ni incrementales, sino una inserción post-instalación de la base
de datos dimensional.

Es una dimensión de libre acceso a todos los usuarios de la aplicación.

Entidades:
LESCITDI Situación de la Cita


LESCITDI

2.12. DIMENSIÓN SITUACIÓN PACIENTE: Dimensión que indica la clasificación del
paciente respecto a la cita.

Dimensión estática y de cardinalidad baja que provoca la no existencia de cargas iniciales
ni incrementales, sino una inserción post-instalación de la base de datos dimensional. Si
se quiera crear nuevas situacines de paciente, la creación sería posible y rápida; pero la
creación debería ser hecha a mano por un Administrador que tuviera conocimientos de la
lógica funcional de la aplicación.

La información es accesible por todos los usuarios de la aplicación

Entidades:
LESPACDI Situación del Paciente


97


LESPACDI

2.13. DIMENSIÓN TIPO CITA: contiene los diferentes tipos de cita con respecto a entrada
en lista de espera. Si la cita se ha concedido en el primer hueco que existía, si se ha
desplazado del primer hueco existente por motivos voluntarios o por algún motivo clínico.

se quiera crear nuevos tipos de cita, la creación sería posible y rápida; pero la creación
debería ser hecha a mano por un Administrador que tuviera conocimientos de la lógica
funcional de la aplicación.


Entidades:
LETPCTDI Tipos de Cita


LETPCTDI

2.14. DIMENSIÓN TIPOS CONSULTA: contiene los diferentes tipos de consulta que puede
tener una cita en lista de espera, es decir, si es la primera consulta provocada por un
Especialista o si es una cita sucesiva provocada por una primera cita control del proceso o
control del enfermo crónico.

se quiera crear nuevos tipos de consulta, la creación sería posible y rápida; pero la


Entidades:
LETPCNDI Tipos de Consulta


LETPCNDI

98


2.15. DIMENSIÓN TIPOS ENTRADA: contiene los diferentes estados por los que puede
pasar una cita en lista de espera con respecto a la entrada. Una cita puede ser Original, si
se ha citado y aceptado sin más o Reprogramada, si ha sido citada y con posterioridad
cambiada de fecha.

se quiera crear nuevos tipos de entrada, la creación sería posible y rápida; pero la


Entidades:
LETPENDI Tipos de Entrada


LETPENDI

2.16. DIMENSIÓN TIPOS VISITA: Se puede indicar que es una dimensión similar a la de
TIPO DE CONSULTA, de hecho se le indicó al cliente que no aportaba mucha más
información ni ayuda a la hora de la toma de decisiones. Es una dimensión que indica si
una cita es Preventiva, Primera o Sucesiva, si nos fijamos igual a TIPO DE CONSULTA;
pero el cliente no quiso deshacerse de ella y todo nos hace creer que fue debido al
aprovechamiento de la arquitectura para más adelante incluir en esa dimensión algún
valor de peso similar.

se quiera crear nuevos tipos de visita, la creación sería posible y rápida; pero la creación
debería ser hecha a mano por un Administrador que tuviera conocimientos de la lógica
funcional de la aplicación.


Entidades:
LETPVSDI Tipos de Visita


LETPVSDI

99


2.17. DIMENSIÓN ORIGEN DE LA PETICIÓN: contiene los diferentes origenes
institucionales que puede tener una cita en lista de espera.

se quiera crear nuevos orígenes de la petición, la creación sería posible y rápida; pero la


Entidades:
LEORPCDI Origen de Petición de Cita


LEORPCDI

3. DIMENSIONES DE LEQ – LISTA DE ESPERA QUIRÚRGICA

3.1. DIMENSIÓN CIRCUNSTANCIAS DE INCLUSIÓN: indica cómo ha sido dado de alta el
paciente en la lista de espera.

Esta dimensión se compone de dos entidades en la que una de ella recoge la inferior
agrupada en diferentes aspectos. Ambas son totalmente estáticas y de baja cardinalidad,
por lo que se decidió desnormalizar para beneficiar la rapidez en el acceso a la
información. Son entidades fijas para todos los Centros de manera que no existe el
mantenimiento de la dimensión, cualquier cambio sobre la misma debe de ir dirigido a
través de un Administrador que de forma controlado gestione ambas tablas.

Información accesible a todos los usuarios de la aplicación por igual.

Entidades:
LECLINDI Dimensión Clasificación de Circunstancias de Inclusión
LECRINDI Dimensión Circunstancias de Inclusión


LECLINDI

R/12 LECRINDI

100


3.2. DIMENSIÓN MOTIVOS DE SALIDA: Dimensión que informatiza sobre el motivo que el
movimiento ha sido cerrado, ya sea habiendo terminado su ciclo de forma normal o de
forma precipitada sin llegar a un final deseado.

Dimensión estática y de cardinalidad reducida. Mientras que los Servicios Centrales creen
que sólo es necesario un grupo de valores reducidos de motivos de salida, los Centros
tienen interés en tener un mayor abanico de razones, por los que se determinan dos
niveles de Motivos de Salida, uno para gestión de los Centros y otro más reducido en el
que se agrupan estos de forma unívoca para el estudio según Servicios Centrales.

Dada la baja cardinalidad de las entidades, se desnormalizan para ganar velocidad en las
consultas ignorando la duplicidad en las descripciones.- Por otro lado no exis ten cargas
incrementales de las mismas.


Entidades:
LENMSLDI Motivos de Salida Oficial
LEMSALDI Motivo de Salida


LENMSLDI

R/10 LEMSALDI

3.3. DIMENSIÓN MOTIVOS SUSPENSIÓN DE GARANTÍA: contiene los diferentes motivos
por los que se puede iniciar un período de suspensión sobre una Garantía de Demora
activa.

A pesar de tener un proceso garantizado, este puede verse “suspendido” sin perdida de la
garantía por motivos facultativos o en espera de pruebas necesarias. Estos motivos de
suspensión interesa estudiarse a dos niveles con mayor y menor granularidad, de manera
que surgen las dos entidades que se indican.

Dado que son entidades totalmente estables y de baja cardinalidad se desnormalizan
premiando la velocidad de acceso a la cantidad de información almacenada.

La información de estas entidades es uniforme y accesible por cualquier usuario de la
aplicación.

101


Las entidades que intervienen en esta dimensión son:

Entidades:
LECSGADI Aplazamiento relacionado
LEMSGADI Motivo de Suspensión de Garantía


LECSGADI

R/13 LEMSGADI

3.4. DIMENSIÓN MOTIVOS PERDIDA DE GARANTÍA: contiene los diferentes motivos por los
que se puede perder una Garantía de Demora activa.

Dimensión estable y de baja cardinalidad que no dispone de mantenimiento y por lo tanto
de carga incremental. Cualquier cambio en la dimensión implica una gestión manual del
Administrador.

Esta información es accesible a todos los usuarios de la aplicación de igual manera.

Entidades:
LEPGARDI Motivos de Perdida de Garantía


LEPGARDI

3.5. DIMENSIÓN PROCESOS: son agrupaciones de Diagnósticos y/o Procedimientos a nivel
de categoría, sub-categoría o sub-clasificación.

Existen estudios que interesan según sus Diagnósticos y Procedimientos definidos, estos
estudios no son siempre totalmente definidos, sino que interesan un grupo de
Diagnósticos con una serie de Procedimientos o un Procedimiento en diferentes
Diagn´soticos, por lo que se definieron los Procesos.

Los procesos se determinan con relación al Diagnóstico A y Procedimiento A del
movimiento que esté en estudio.

Debería ser una dimensión estática; pero no es así dado que según los estudios y
adelantos en los Diagnósticos y Procedimientos, se puede decidir a agrupar estos de
diferente manera, aunque con pequeñas variaciones y no de forma muy habitual. Por ello,
se crearon la carga inicial e incremental.

102


Dada la complejidad e importancia de los procesos, cuentan con una carga específica,
independiente de las dimensiones y los movimientos que en el caso de fallar, paraliza la
carga de todos los Centros hasta la resolución del problema.

La información de esta dimensión está disponible a todos los usuarios de igual forma.

Entidades:
LEPROCDI Estructura donde se recogen los procesos
LEPROCDS Estructura de desacoplo


LEPROCDI

R/159 LEPROCDS

3.6. DIMENSIÓN RECHAZO DE DERIVACIÓN: contiene los posibles motivos de rechazo de
derivación a otro Centro para su tratamiento quirúrgico.

En esta dimensión como en otras muchas, mientras los Centros Hospitalarios tienen
interés en estudiar un amplio abanico de motivos de rechazo a la derivación, los Servicios
Centrales prefieren clasificarlos en un número inferior de motivos, por lo que los motivos
de los Centros son agrupados de forma univoca como indiquen los Servicios Centrales.

Dada la baja cardinalidad de estas entidades y el bajo dinanismo de las mismas, se
decide una vez más, primar la rapidez de acceso y disculpar la duplicidad de
descripciones, desnormalizando la dimensión. Por esta misma razón, lo poco dinámicas
que son estas entidades, esta dimensión dispone de una carga inicial; pero no de carga
incremental.

Por otro lado la información de esta dimensión depende del Centro, dado que cada uno
incluye sus propias descripciones, por lo que se incluyen los campos AGRD_CO_CEGA y
REDE_CO_CEGA para acceder por la politica de VPD a la información que le
corresponde.

Entidades:
LEAGRDDI Agrupación de Rechazos de Derivación
LEREDEDI Rechazos de Derivación


103


LEAGRDDI

R/146

LEREDEDI

3.7. DIMENSIÓN SITUACIÓN GARANTÍA: contiene los diferentes estados por los que puede
estar un proceso de Lista de Espera en relación a la Garantía.

En esta dimensión como en la anterior, mientras los Centros Hospitalarios tienen interés
en estudiar un amplio abanico de situaciones en los que se puede encontrar una garantía,
los Servicios Centrales prefieren clasificarlos en un número inferior de situaciones, por lo
que las situaciones de los Centros son agrupados de forma univoca como indiquen los
Servicios Centrales.

Dada la baja cardinalidad de estas entidades y el bajo dinanismo de las mismas, se
decide una vez más, primar la rapidez de acceso y disculpar la duplicidad de
descripciones, desnormalizando la dimensión. Por esta misma razón, lo poco dinámicas
que son estas entidades, por lo que esta dimensión dispone de una carga inicial; pero no
de carga incremental.

En este caso la información es igual para todos los Centros Hospitalarios y por lo tanto
accesible de igual manera a todos los usuarios de la aplicación.

Entidades:
LEGAAGDI Agrupación de la situación de garantía
LEGARADI Situación de la Garantía


LEGAAGDI

R/134
LEGARADI

3.8. DIMENSIÓN ESPERA: indica si la espera del paciente durante su permanencia en el
Registro de Demanda Quirúrgica es debida a una incidencia del propio paciente o debida
a la institución Hospitalaria.

El tipo de Espera no depende de la Situación en Lista del paciente, sino de la historia del
paciente durante su permanencia en el Registro de Demanda Quirúrgica.

Esta dimensión no cuenta con flujo de carga y cualquier cambio en la misma debe de
pasar por mantenimiento específico.

104


Uno de los puntos importantes de este Data Warehouse, es la de distinguir entre
pacientes en “Espera Estructural” y pacientes en “Espera No Estructural”. Se ha
considerado pacientes en “Espera Estructural” aquellos cuya espera sea “EE” con
identificador 10 y pacientes en “Espera No Estructural” todos los demás.

Es una dimensión estática de nulo mantenimiento por lo que no dispone de carga
incremental. Y los valores de los que dispone son iguales para todos los usuarios de la
aplicación.

Entidades:
LESITBDI Espera


LESITBDI

3.9. DIMENSIÓN SITUACIÓN EN LISTA: contiene las posibles situaciones de un paciente
durante su permanencia en Lista de Espera.

Cada situación se agrupa, en el Data Warehouse, a otro nivel para consultas en los
Centros Hospitalarios según la tabla inferior. Estas entidades son igualmente estables y
de baja cardinalidad, por lo que se desnormalizan para ganar en los accesos en los que
intervengan la agrupación y el nivel inferior.

La información de estas entidades es igual para todos los Centros Hospitalarios.

Entidades:
LESTAGDI Agrupación de la situación
LESITLDI Situación en Lista


LESTAGDI

R/151
LESITLDI

3.10. DIMENSIÓN TIPOS DE ACTIVIDAD: indica lo que se va a realizar sobre el paciente.

Esta dimensión informatiza los tipos de actividades dentro del Centro Hospitalario. Estas
actividades dependen del Centro y de las descripciones que ellos definan, por lo que se
define el campo TPAC_CO_CEGA para acceso selectivo por lo política de VPD.

Esta dimensión dispone de carga incremental dado que cada Centro puede incorporar

105


nuevas actividades o modificar las ya existentes.

Entidades:
LETPACDI Tipos de Actividad


LETPACDI

3.11. DIMENSIÓN TIPOS DE ANESTESIA: contiene diferentes tipos que el Hospital suele
utilizar en la actividad quirúrgica.

Cada Tipo de Anestesia se agrupa, en el Data Warehouse, a otro nivel para consultas en
los Centros Hospitalarios según la tabla inferior. Estas entidades son igualmente estables
y de baja cardinalidad, por lo que se desnormalizan para ganar en los accesos en los que
intervengan la agrupación y el nivel inferior.

La información de estas entidades difiere para cada Centro Hospitalario, por lo que se
definen los campos AGAN_CO_CEGA y TPAN_CO_CEGA, para la definición de accesos
de la VPD. Por otro lado, la carinalidad de estas entidades es baja y se sigue la regla de
desnormalización para obtener mayor rendimiento en los accesos y rápido giro en los
informes dinámicos que se generen en la toma de decisiones.

Entidades:
LEAGANDI Agrupación de anestesias
LETPANDI Tipos de Anestesia


LEAGANDI

R/11
LETPANDI

3.12. DIMENSIÓN TIPOS DE GARANTÍA: Indica qué garantia cubre a cada movimiento, en
la gran mayoría no corresponde ningún tipo de garantía.

Esta dimensión es estática y de cardinalidad insignificante, que se carga en la Carga Inical
y no dispone de mayor mantenimiento. Toda su información en genérica y de igual acceso
para la totalidad de los usuarios de la aplicación.

Entidades:
LETPGADI Tipo de Garantía


106


LETPGADI

3.13. DIMENSIÓN TIPOS DE LISTA: El tipo de lista indica la especialidad a la que se le
asigna el movimiento y bajo la que depende en la espera a ser tratado.

Esta dimensión depende del centro Hospitalario, dado que cada Centro tiene un grupo de
Especialidades y las gestiona a su manera, eso sí, todo los Centros disponen de las
mismas Especialidades bajo las que tienen que cuadrar sus movimientos, por lo que se
definen los campos TPLS_CO_CEGA y LISR_CO_CEGA para la selección de información
bajo la política definida para VPD.

Esta dimensión es de baja cardinalidad y de casi nulo mantenimiento, por lo que aunque
se pueden crear nuevas Listas, se decide desnormalizarla para ganar tiempo en el acceso
a consultas complejas.

Entidades:
LETPLSDI Tipo de Lista de espera.
LELISRDI Listas de Espera por Servicio


LETPLSDI

R/14 LELISRDI

4.3.2. Procesos ETL

A la hora de extraer la información de los sistemas operacionales, un gran problema que se
presenta es el de la diferencia de fuentes. En este proyecto, como hemos visto a lo largo de la
definición de las dimensiones que intervienen en el Data Warehouse, esto no fue problema,
dado que todos los Centros Hospitalarios disponen de la misma herramienta para inclusión y
gestión de pacientes y desde Servicios Centrales se hacen llegar sólo dos archivos en formato
diferente, uno un fichero plano con la Población de Referencia de cada centro Hospitalario y
otro una hoja Excel con los Procesos según su Diagnóstico CIE y su Procedimiento CIE,
información que debe ser recogida en el Data Warehouse para disponer de toda la información
posible. El problema no es el formato, sino el sentido de la información. Muchas de las tablas
de la herramienta de gestión son configurables y definidas según el método de trabajo de cada
uno de los Centros Hospitalarios, teniendo distintos valores para representar lo mismo, e
incluso en algunos Centros mayor variedad de información que en otros. Por lo tanto los
procesos de extracción y limpieza deben homogeneizar el contenido de todos ellos, agrupando

107


o traduciendo lo que cada Centro quiere ver y lo que la Comunidad Autónoma pretende
controlar, lo que conlleva que en algunos casos se tengan varias dimensiones de igual sentido
para ver la información de una u otra forma, como por ejemplo “Motivos de salida” y “Motivos
de salida Oficiales” que muestra a cada Centro Hospitalario la información según están
acostumbrados a verla y además las agrupa según la comunidad quiere consultarla. Para
resolver este problema, en cada una de las dimensiones en las que no se ha homogeneizado
la información, se ha incluido en cada registro, el CEGA del Centro Hospitalario que lo inserta y
por otro lado a la hora de consultar la información, el usuario se identificará con el código
CEGA al que esté asociado viendo la información según está acostumbrado.

Para resolver un posible problema en el futuro, si se incorpora un nuevo Centro Hospitalario
con diferente herramienta de gestión, se ha desvinculado la fase de extracción de la fase de
carga. Gracias a este desacople es posible modificar las técnicas de extracción de datos de
una fuente determinada, y añadir o quitar fuentes de información sin afectar al resto de las
fases de la carga. En la figura 4.5 se observa cómo, para cada una de las diferentes fuentes de
datos, se proporciona un adaptador encargado de acceder a los datos. Cada uno de estos
adaptadores tiene un interfaz de uso común. Los objetos que representan información de los
sistemas legacy acceden a la información mediante este adaptador, de modo que si en alguna
ocasión el dato cambia de fuente (puede suceder por ejemplo que un dato obtenido de un
fichero de texto pase a obtenerse de una base de datos después de una reingeniería del
operacional) sólo será necesario cambiar el adaptador y no la definición del objeto. La
utilización de patrones de diseño es de una gran ayuda en estas tareas.

Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a
problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de
interacción o interfaces. Puede encontrarse información sobre este tema en en [Gamma95].

Por otro lado, dado que todos los sistemas operacionales son administrados a través de la
misma herramienta y que las modificaciones en un Centro Hospitalario son muy similares a las
de el resto de los Centros Hostipalarios, no podemos decir que exitan tres tipos de procesos,
Extracción, Transformación y Carga, sino que la fase de Transformación se embebió entre la
fase de Extracción/Descarga y la de Carga.

A continuación se describen los tipos de fuentes de datos contemplados en este trabajo, las
tecnologías utilizadas por los diferentes adaptadores para acceder a ellos y como se
convirtieron a fichero plano de fácil manejo y manipulación desde los sistema unix.

Todos los Centros Hospitalarios adscritos a la Comunidad Autónoma en estudio son
reconocidos a través de un identificador único conocido como CEGA. Este CEGA es un número

108


único de cuatro dígitos que se utilizará para la identificación y clasificación de los distintos tipos
de usuarios y cuyos dos primeros dígitos coinciden con el código de la Provincia según la
Administración Pública.

Los tipos de formatos con los que se ha trabajado en este proyecto han sido:

• Bases de datos. Para construir las descargas de los sistemas legacy de dimensiones y
movimientos y dado que estas eran bbdd relacionales se utiliza acceso directo a la
información de la misma. Para la descarga inicial se ejecutan SELECTS de las tablas
implicadas con condiciones estudiadas. Para las descargas incrementales se ejecutan
disparadores o triggers que vuelcan la nueva información en tablas temporales o, en este
caso, en fichero plano. La descarga se efectuó directamente en fichero plano para evitar
posibles problemas de inaccesibilidad a la información si el operacional no estaba
disponible y evitar posibles cargas en el mismo. Los registros de los archivos son de
diferente tamaño, donde se coloca al inicio del registro un código indicador de la dimensión
afectada y otro código a continuación, que indica si el elemento es nuevo o modifica alguno
ya existente. De esta fuente de datos se obtiene toda la información de las dimensiones
implicadas en el Data Warehouse a excepción de Población de Referencia y Procesos

• Microsoft Excel. La parte de Procesos llega en formato de hoja de cálculo Microsoft Excel.
Se definen accesos a datos ODBC, a los que se accederá mediante un driver puente
ODBC-JDBC para transformar la información en fichero plano de formato csv.

• Ficheros planos. De hecho y dado que la plataforma utilizada es unix, todos las fuentes se
transforman a fichero plano de fácil manejo y gestión. Todos los ficheros planos
consistentes en líneas de tamaño variable donde el inicio de la línea indica qué formato
tiene el registro que encabeza. En estos ficheros es habitual que los datos no sean
correctos, ya que es fácil que el número de columnas no sea el esperado, los formatos de
los datos estén equivocados (por ejemplo se utiliza la coma decimal cuando se esperaba
un punto), etc. Todos los registros que puedan tener algún tipo de problema son
rechazados en la carga a través del Oracle9i Warehouse Builder®, y su visualizador de
errores, la herramienta Runtime Audit Viewer.

• Ficheros csv. Los ficheros csv (Comma Separated Values) son un caso concreto de
ficheros planos con un formato estándar. Estos ficheros están compuestos por líneas con
un número fijo de columnas cuyos valores están separados por el caracter ‘;’ (punto y
coma).

109


4.3.2.1. Procesos de extracción y transformación

Como se ha comentado, procesos de extracción sólo existen de los sistemas legacy de
dimensiones y movimientos y debemos diferenciar en ambos casos, dos tipos de extracciones,
una Inicial y otra Incremental. En la descarga inicial se descargan los valores existentes de
todas las dimensiones que van a existir en el Data Warehouse mientras que en las descargas
incrementales o diarias, sólo se descarga la información modificada o incorporada a lo largo del
periodo desde la última descarga. El formato de las fuentes a cargar es la misma,
diferenciándose únicamente el volumen de información a cargar.

• Descarga inicial: En la que se extráen todos los valores de las dimensiones existentes en
este momento en cada uno de los sistemas operacionales, así como todo el histórico de
movimientos existente en el Centro Hospitalario, desde dónde se tuviera información
almacenada de forma digital y los movimientos abiertos en estos momentos. Estas
descargas se obtienen a partir de programas MultiBase que se ejecutan una única vez en
cada Hospital de la Comunidad Autónoma.

Los programas que se crearon en Consulta Externa fueron dos:

o aradcex4.sct Datos de movimientos de CEX: Como el periodo de datos solicitado
puede ser de varios años, el programa aradcex4, se podrá ejecutar varias veces
pasando como parámetro el intervalo de fechas. El periodo a descargar se pasa en
parámetros:

ctl aradcex4 fecha_inicio fecha_fin hora_fin
p.e. : ctl aradcex4 ‘01012004’ ‘31122004’ ’23:59’

Si el programa se ejecuta varias veces se deberá ir modificando el nombre del
fichero generado porque la descarga siempre genera el mismo fichero.

o aracex01.sct Datos de maestros de CEX. Los pacientes se calculan del año 2005
de Citas, Actividad y Anulación

Para Lista de Espera Quirúrgica, los programas fueron:

o aradleq1.sct Datos de movimientos de LEQ, se calcula todo el activo y desde el
01.01.2004 del histórico.

o araleq01.sct Datos de maestros de LEQ. Los pacientes se calculan de todo el
activo y de todo el histórico.

110


• Descarga incremental: Descargas diarias en las que sólo se extráe los registros
modificados o insertados en el día de la descarga. Estas descargas se obtienen a partir de
triggers que activan procedimientos almacenados que generan ficheros de texto.

Los triggers creados en Lista de Espera Quirúrgica son:
Triggers
Procedimiento CLAVE Descripción
datamart_acti QACLE Procedimiento para la obtención del maestro trig_ins_acti
tipos de Actividades de LIE. trig_upd_acti
datamart_anes QANES Procedimiento para la obtención del maestro trig_ins_anes
de Anestesias trig_upd_anes
datamart_blista QMSAL Procedimiento para la obtención del maestro trig_ins_blista
de Motivos de salida de LIE. trig_upd_blista

datamart_diag_proc QDIAG Procedimiento para la obtención del maestro trig_ins_tablas
QPROC de Diagnósticos y Procedimientos. trig_upd_tablas
datamart_finan QFINA Procedimiento para la obtención del maestro trig_ins_garantes
de Financiaciones y Garantes. trig_ins_grupocas
trig_upd_garantes
trig_upd_grupocas
datamart_fus_doc GFUSI Procedimiento para la obtención de las
QPACI fusiones y revisiones de pacientes, tambien se
usa para la obtención de datos de los
pacientes que se incluyen en LIE y CEX. Este
se utiliza cuando está instalado DOCTOR
datamart_fusion GFUSI Procedimiento para la obtención de las datamart_movle
QPACI fusiones y revisiones de pacientes, también se trig_ins_fusion
usa para la obtención de datos de los trig_ins_revi
pacientes que se incluyen en LIE y CEX
datamart_hospi GHOSP Procedimiento para la obtención del maestro trig_ins_hospi
de Hospitales. trig_upd_hospi
datamart_manula CMANU Procedimiento para la obtención del maestro trig_ins_manula
de motivos de anulación de CEX. trig_upd_manula
datamart_motsal CMSAL Procedimiento para la obtención del maestro trig_ins_motsal
de motivos salidas de CEX. trig_upd_motsal
datamart_movle Procedimiento para la obtención de los trig_ins_hlespadm
movimientos de LIE (Entradas, Salidas, trig_ins_lie
Anulaciones de Salidas, Aplazamientos, trig_upd_lie
Suspensiones), este procedimiento llama al
datamart_fusion para la obtención de los datos
del paciente.
datamart_pacientes QPACI Procedimiento para la obtención de los trig_upd_pacientes
maestros de pacientes. (solo modificaciones
de datos del paciente)
datamart_pgar QPGAR Procedimiento para la obtención de los trig_ins_pgar
maestros de motivos de perdida de garantía. trig_upd_pgar
datamart_profe GPROF Procedimiento para la obtención de los trig_ins_profe
maestros de profesionales(médicos) trig_upd_profe
datamart_recha QREDE Procedimiento para la obtención de los trig_ins_recha
maestros de los motivos de rechazo a la trig_upd_recha
derivación.
datamart_repro CMREP Procedimiento para la obtención de los trig_ins_repro
maestros de motivos de reprogramación. trig_upd_repro
datamart_servi GFUNC Procedimiento para la obtención de los trig_ins_servi
maestros de servicios. trig_upd_servi
datamart_sgar QSGAR Procedimiento para la obtención de los trig_ins_sgar
maestros de motivos de suspensión de la trig_upd_sgar
Garantía.
datamart_tlista QTLIS Procedimiento para la obtención de los trig_ins_tlista
maestros de los tipos de listas de LIE. trig_upd_tlista
datamart_maesgaran QTGAR Procedimiento para la obtención del maestro trig_ins_maesgaran
de garantías. trig_upd_maesgaran

Los ficheros se descargan en el directorio indicado por la constante 30303 y tiene el

111


siguiente nombre:

Maestros : <cega><año><mes><dia> Ej : 999920040910
Movimientos LE : <cega><año><mes><dia>MOVLE Ej : 999920040910MOVLE

Los triggers creados en Consulta Externa son:

Procedimiento CLAVE Descripción Triggers
datamart_agen CAGEN Procedimiento para la obtención del maestro de trig_ins_agen
Agendas de CEX trig_upd_agen
datamart_cenpri GCAP Procedimiento para la obtención del maestro de trig_ins_cenpri
Centros de Atención Primaria y los Cias asociados trig_upd_cenpri
a cada uno de ellos
datamart_cias GCAP Procedimiento para la obtención del maestro de trig_ins_cias
Centros de Atención Primaria y los Cias asociados trig_upd_cias
a cada uno de ellos
datamart_fusion GFUSI Procedimiento para la obtención de las fusiones y datamart_movle
QPACI revisiones de pacientes, también se usa para la trig_ins_fusion
obtención de datos de los pacientes que se trig_ins_revi
incluyen en LIE y CEX
datamart_movcex Procedimiento para la obtención de los trig_ins_anucex
movimientos de CEX (Citas, Peticiones, Captura, trig_ins_capcex
Reprogramación, Anulación), este procedimiento trig_ins_citas
llama al datamart_fusion para la obtención de los trig_ins_petcex
datos del paciente. trig_upd_citas
trig_upd_petcex
datamart_prest CPTEC Procedimiento para la obtención de los maestros trig_ins_prest
de prestaciones trig_upd_prest
datamart_tecni CPRAD Procedimiento para la obtención de los maestros trig_ins_tecni
de las técnicas de rayos. trig_upd_tecni
datamart_calen CCALE Procedimiento para la obtención del calendario. trig_ins_calen
trig_upd_calen
datamart_hora CHORA Procedimiento para la obtención de los horarios trig_ins_hora
de las agendas. trig_upd_hora

Los ficheros se descargan en el directorio indicado por la constante 30303 y tiene el
siguiente nombre :

Maestros : <cega><año><mes><dia> Ej : 999920040910
Movimientos CEX : <cega><año><mes><dia>MOVCEX Ej : 999920040910MOVCEX

La limpieza de datos se lleva a cabo en el propio proceso de extracción, se realizará un
parseado previo de los ficheros de texto para verificar que el formato es el esperado, y se
generarán distintos tipos de excepciones a medida que se realiza la extracción al encontrar
valores nulos en campos no nulos, valores con coma decimal en lugar de punto, valores fuera
de rango, etc.

Existen diferentes casuísticas a contemplar por la modificación de información realizada en los
sistemas operacionales que pueden afectar al Data Warehouse:

• Las modificaciones realizadas en los sistemas operacionales que no se encuentren
registradas en la estructura de los ficheros de carga que suministra, quedarán fuera del
Data Warehouse. El procedimiento a seguir para trasladar dicha información al sistema
será la petición concreta de los datos y la modificación de los procesos de carga que se
vean afectados para su posterior incorporación. Adicionalmente se tendrá que realizar las

112


modificaciones pertinentes en la capa semántica para su correcta explotación desde el
Data Warehouse. Esta situación conlleva la ausencia de datos históricos de la nueva
información disponible, teniendo que realizar procesos particulares para su incorporación.

4.3.2.2. Procesos de carga

Las cargas del Data Warehouse se realizarán utilizando la herramienta de Oracle Warehouse
Builder. Las capacidades de la herramienta permiten que se puedan gestionar de una manera
integrada y automatizada la carga desde diferentes bases de datos, así como la ejecución y
control de cargas periódicas. Dados los requerimientos de un sistema de arquitectura unix, las
cargas se han diseñado para aprovechar la potencia y ventaja del sistema operativo. Las
cargas se ejecutan de forma automática con una periodicidad diaria aunque se podrán realizar
a petición del usuario.

La función de los procesos de carga es crear y mantener una imagen fiel de la realidad
reflejada en las bases de datos origen. En ningún caso se prevé la realización de
monitorizaciones o seguimientos de cambio de estado en el Data Warehouse que no tengan su
contrapartida en las bases de datos de origen.

Las cargas, tanto la inicial como las incrementales, se diseñaron utilizando estructuras de
desacoplo; es decir, estructuras intermedias que se cargan directamente desde los ficheros de
datos origen y que contienen una imagen prácticamente idéntica a los ficheros de origen. El
trabajo con estructuras de desacoplo conlleva, entre otras, las siguientes ventajas:

• Facilitar el diagnóstico de problemas y su aislamiento.

• Evitar que una situación anómala en un Centro, bloquee la extracción y posterior carga del
resto de los centros.

• Permite que se puedan independizar las diferentes extracciones y cargas, realizándolas en
el mejor momento para cada Centro.

• Reduce el tiempo global de proceso.

El procedimiento de actualización del sistema de análisis consiste en realizar las inserciones y
actualizaciones de registros necesarias, a la vista de la comparación de la información
contenida en el desacoplo y en el Data Warehouse. No se realizan borrados automáticos de
registros del Data Warehouse. El proceso de transformación consiste en la asignación de
valores a las propiedades de los objetos del Data Warehouse a partir de las propiedades de los

113


objetos legacy, ya sea directamente o realizando las transformaciones oportunas. Las acciones
principales realizadas en la transformación son:

• Transformaciones básicas. Modificaciones sencillas en los valores datos, como
eliminar espacios en blanco en cadenas de caracteres o cambiar las unidades de
medida de un dato.

• Lookups. Consisten en buscar en otras tablas o fuentes de información datos
asociados para desnormalizar la información contenida en el operacional. Con el
modelo de objetos legacy los lookups son muy sencillos de implementar, ya que
simplemente es necesario acceder a las propiedades de objetos relacionados.

• Seguimiento de cambios. En los casos en los que sea necesario mantener un
histórico de la información de las dimensiones (por ejemplo el código de paciente que
ha sido mal codificado o trasladado desde otro centro con diferente número de
identificación) debe realizarse una comprobación de la información obtenida del
operacional y la contenida en el Data Warehouse, en caso de ser diferente se crea un
nuevo registro en la dimensión y se actualiza la versión anterior para indicar que ya no
es válida.

• Generación de claves subrogadas. Como se ha indicado a lo largo de este trabajo,
las claves del operacional no deben ser utilizadas en ningún caso como claves de los
modelos dimensionales. Por lo tanto, a la hora de generar las dimensiones deben
crearse claves subrogadas para cada registro. La generación de las claves subrogadas
se realiza mediante un entero autoincremental, cuyo cálculo se delega en el método
constructor de cada una de las clases del Data Warehouse.

Carga de los archivos de Población de Referencia

La carga de este archivo debería ser anual, al comienzo del año y sólo afecta a los indicadores
comparativos por población. Si este archivo se recarga, los indicadores cambian y los informes
anteriores estarían desactualizados.

Este archivo para su correcta carga se debe situar en el directorio $RLE_CARGA o
$LNZ_CARGA del entorno de la aplicación. No existe ninguna aplicación que sitúe este archivo
en dicho directorio y se considera que es colocado de forma manual por el Usuario, en concreto
alguien bajo el control de Servicios Centrales a los que se consideran responsables de esta
información.

Carga de los archivos de Procesos y Patologías

114


La carga de este archivo debería ser una vez, al comienzo de la creación del Data Warehouse
y dada la estabilidad de la información no modificarse nunca. Esta información se utiliza para la
carga del movimiento, por lo que cualquier variación en esta dimensión provoca que los
movimientos existentes en el Data Warehouse no dispongan de una información exacta.

Este archivo para su correcta carga se debe situar en el directorio $RLE_CARGA o
$LNZ_CARGA del entorno de la aplicación. No existe ninguna aplicación que sitúe este archivo
en dicho directorio y se considera que es colocado de forma manual por el Usuario, en concreto
alguien bajo el control de Servicios Centrales a los que se consideran responsables de esta
información.

Carga de dimensiones y movimientos

Las cargas de dimensiones y movimientos se procesarán de forma independiente para cada
uno de los Centros Hospitalarios, no siendo posible la carga simultánea de varios centros. De
este modo, se consigue que los procesos de carga sean más óptimos y rápidos. La información
de los movimientos se recibe a través de tres archivos procedentes de cada uno de los Centros
Hospitalarios. Siendo estos archivos de envío periódico, aunque el Usuario puede decidir
realizar un envío en un momento determinado o variar la periodicidad en cualquier momento.
Puede ocurrir que, si no existen movimientos no se remitan archivos desde un determinado
Centro Hospitalario al Data Warehouse.

Estos archivos, de existir, se les podrá identificar por la siguiente nomenclatura:

Nombre del archivo Observaciones
CEGA .- Código Identificativo del Centro Hospitalario.
CEGAYYYYMMDD YYYYMMDD.- Fecha en la que se produce la descarga. Con la siguiente
máscara (año, mes, día).
YYYYMMDD.- Fecha en la que se produce la descarga. Con la siguiente
CEGAYYYYMMDDMOVLE
MOVLE. Identifica los movimientos del Registro de Demanda Quirúrgica.
YYYYMMDD.- Fecha en la que se produce la descarga. Con la siguiente
CEGAYYYYMMDDMOVCEX
MOVCEX. Identifica los movimientos de LECyT.

• Un archivo con nombre CEGAYYYYMMDD. Este archivo contendrá las nuevas
incorporaciones o cambios realizados el día en cuestión en las entidades del sistema
operacional, consideradas como dimensiones y que son las características de información
para el Data Warehouse. En este archivo se incorpora la información del Registro de
Demanda Quirúrgica y Consultas Externas y Técnicas Diagnósticas.

115


• Un archivo con nombre CEGAYYYYMMDDMOVLE. Este archivo contendrá las nuevas
incorporaciones o cambios realizados en los movimientos del Registro de Demanda
Quirúrgica.

• Un archivo con nombre CEGAYYYYMMDDMOVCEX. Este archivo contendrá las nuevas
incorporaciones o cambios realizados en los movimientos de Consultas Externas y
Técnicas Diagnósticas.

Para poder cargar los movimientos del Registro de Demanda Quirúrgica, Consultas Externas y
Técnicas Diagnósticas se deberá haber procesado previamente los archivos de movimiento de
las dimensiones.

Carga de Dimensiones

Debido a la naturaleza de los sistemas operacionales, se dispone de tablas maestras que
nutren de información la operativa diaria. Estas tablas maestras se pueden clasificar en
entidades homogéneas a todos los Centros Hospitalarios y entidades propias de cada
Centro. Por ese motivo se han diferenciado entre Dimensiones Fijas y Variables:

o Dimensiones Fijas. Se consideran dimensiones fijas a todas aquellas que son
homogéneas a todos los centros hospitalarios.

o Dimensiones Variables. Son todas aquellas dimensiones que disponen de valores
independientes entre los diferentes centros.

Todas las dimensiones, a su vez son flexibles, añadiendo, eliminando o cambiando los
literales y valores básicos según a la Comunidad Autónoma/Centro Hospitalario le parezca
conveniente.

Los cambios en algunas de las dimensiones son desiguales en cantidad y semántica,
haciendo que el Data Warehouse tenga que mantener los cambios a lo largo de la Historia
de un Centro Hospitalario para consultar registros ya cerrados a la par que deben de ser
coherentes con la información en curso para poder realizar estudios comparativos.
Algunos de estos cambios no son iguales en los distintos Centros Hospitalarios y el Data
Warehouse es capaz de mostrar la información según le interese verla al Centro
Hospitalario y agregarla según normativa para que la pueda estudiar la Dirección
Provincial o Servicios Centrales.

La carga de las dimensiones se efectuará de forma automática una vez al día o tantas
veces como decida el usuario.

116


Es imprescindible que la carga de los dimensiones sea anterior a la carga de los
Movimientos en Espera Quirúrgica y Consultas Externas y Técnicas Diagnosticas, dado
que los movimientos pueden contener información referente a esas dimensiones y si no
están cargadas en el Data Warehouse, el lookup para la desnormalización puede fallar.

Estructura del Archivo de Dimensiones

En realidad el archivo de las dimensiones es un compendio de registros de diferentes
formatos y longitudes en el que se reúnen todos los registros de maestros modificados ese
día con un formato determinado. A continuación se detalla las diferentes estructuras:

• Acción sobre el registro (1 dígito)

• Tabla afectada (5 dígitos)

• Código CEGA

• Número variable de campos separados por pipes “|” y que dependen de la tabla a
la que hace referencia el campo anterior.

• Todos los registros terminan con fecha de extracción con el formato: (YYYYMMDD
HHMISS)

o YYYY.- Año (4 dígitos)
o MM.- Mes (2 dígitos)
o DD.- Día (2 dígitos)
o Espacio en blanco (1 dígito)
o HH.- Hora (2 dígitos)
o MI.- Minuto (2 dígitos)
o SS.- Segundos (2 dígitos)

En realidad las dimensiones son bastante estables a excepción de la dimensión de
pacientes que diariamente recibe modificaciones o inserciones.

A continuación se incluye una breve descripción de las estructuras maestras que se
utilizan y se hace referencia a algunos de los valores existentes en este momento, aunque
se insiste que estos valores son variables y se cargan diariamente con los nuevos valores
que pueden aparecer en los diferentes Centros Hospitalarios, además se indican las
dimensiones comunes entre el Registro de Demanda Quirúrgica y la Lista de Espera de
Consultas Externas y Técnicas Diagnósticas.

Estructura RDQ CEX Tipo Descripción
Almacena las autonomías, provincias y poblaciones con
Estructura Geográfica X X Fija
los que trabaja la comunidad Autónoma.

117


Diagnóstico ( A Y B) X Fija Diagnósticos que se le da a un paciente en RDQ (CIE-9)
Procedimientos (A Y B) X Fija Procedimientos que se le da a un paciente en RDQ (CIE-9)
Financiación del Esta estructura agrupa las Financieras con las que trabaja
X X Variable
Paciente cada Centro Hospitalario.
Procedencia del
X X Fija Es el Servicio solicitante de la intervención
Paciente
Todos los centros hospitalarios que pertenecen a la
Hospital X X Fija
Comunicad Autónoma.
Todos los centros hospitalarios adscritos o no a la
Hospital Derivación X X Variable Comunidd Autónoma con los que los Centros Hospitalarios
tienen relación
Estructura que registra todas los servicios con los que se
Estructura Funcional X X Variable
trabaja en el Centro Hospitalario
Motivos de Salida RDQ X Fija Motivos de salida del Registro de Demanda Quirúrgica.
Contiene los tipos de anestesia con el que se trabaja en los
Tipos de Anestesia X Variable
Centros Hospitalarios
Tipo de prioridad para cualquier proceso existente en el
Tipos de Prioridad X X Fija
ámbito del Servicio de Salud de la Comunida Autónoma.
Muestra la situación en la que se encuentra un proceso
Situación de Garantía X Fija
respecto a la característica de la garantía
Motivos que conllevan la pérdida de la garantía y la
Motivos Pérdida
X Fija invalidez de la fecha máxima de garantía al no tener
Garantía
efectividad alguna.
Motivos Suspensión
X Fija Motivos que conllevan la suspensión de la garantía.
Garantía
Son clasificaciones de tipos de listas dentro de cada
Tipos de Listas X Variable
Centro Hospitalario
Situación en Lista X Fija Estados en los que se encuentra un paciente en RDQ
Tipo de Espera X Fija Tipo de espara en el que se encuentra el paciente en RDQ.
Se extraen directamente de los pacientes existentes en
Pacientes X X Variable Sist. Opracional siempre que se encuentre en alguno de
los activos de RDQ o LECyT
Sexo X X Fija Indica el sexo del paciente.
Profesionales X X Variable Información del profesional solicitante del servicio
Ámbito X Fija Indica si el paciente pertenece al ámbito.
Derivable X Fija Indica si el paciente es derivable.
Motivos Rechazo Indica la raz´ón por la que el paciente rechaza la
X Fija
Derivación derivación.
Tipo de Garantía X Fija Garantía que le cubre al paciente.
Series Temporals X X Calendario donde se realizan los movimientos
Agrupación de días según los estudios, quincenal,
Intervalos X Fija
semanala, mensual, trimestral…
Agendas X Variable Agendas existentes para Consulta Externa
Situación de la Cita X Fija Estados en los que se encuentra la cita en CEX
Situación del Paciente X Fija Estado en el que se encuentra un paciente en CEX.
Motivos de Anulación X Fija Razón por la que se anula una cita.
Los diferentes motivos de reprogramación de una cita en
Motivos Reprogramación X Fija
CEX
Los diferentes valores que pueden tener los motivos de
Motivos Salida (CEX) X Fija
salida CEX.
Prestación y Tec. Los diferentes valores que pueden tener la prestación y
X Variable
Diagnósticas técnicas diagnósticas.
Clasificación de las distintas enfermedades por Diagnostico
Procesos X Fija
y Porcedimiento
Centros de Atención
X Fija Centros de los que pueden proceder los pacientes de CEX.
Primaria
Los diferentes valores que puede tener las pruebas
Pruebas Radiológicas X Variable
radiológicas
Los diferentes valores que puede tener el origen de
Origen Petición / Cita X Fija
petición / cita.
Estados del Buzón X Fija Los diferentes estados que puede tener el buzón.
Los diferentes tipos de entrada que se dan en lista de
Tipos de Entrada X Fija
espera
Tipos de Cita X Fija Los tipos de cita que se pueden dar en la lista de espera.
Tipos de Consulta X Fija Los tipos de consulta que se pueden dar en lista de espera

118


Motivos Salida Oficiales X Fija Motivos de salida oficiales de lista de espera CEX

Carga de Hechos

La información de los movimientos se recibe a través de dos archivos procedentes de
cada uno de los Centros Hospitalarios.

Estructura de los Archivos de Hechos

Se reciben dos archivos de movimientos por Centro Hospitalario y día, uno para RDQ y
otro para LECyT. Ambos disponen de formatos y estructuras independientes, recogiendo
todos los movimientos que se pudieran dar en ambas listas de espera. A continuación se
detalla la estructura común para ambos ficheros:

• Acción sobre el registro (2 dígito)

• Código CEGA

• Número de campos separados por pipes “|” varían en función de RDQ y LECyT.

• Todos los registros terminan con fecha de extracción con el formato: (YYYYMMDD
HHMISS)

o YYYY.- Año (4 dígitos)
o MM.- Mes (2 dígitos)
o DD.- Día (2 dígitos)
o Espacio en blanco (1 dígito)
o HH.- Hora (2 dígitos)
o MI.- Minuto (2 dígitos)
o SS.- Segundos (2 dígitos)

Existen diferentes situaciones en las que el proceso de carga puede dejar de procesar
información:

o Fallo Estructural. Este error puede ocurrir tanto en dimensiones como en
movimientos y se produce por un error de estructura en los ficheros que se recibe
del Centro Hospitalario. Esta situación genera una desactivación de los procesos
de carga al Data Warehouse del Centro Hospitalario donde se detectase dicha
anomalía hasta subsanar el error.

o Fallo Lógico. Este error puede ocurrir tanto en dimensiones como en hechos y se
produce por un error lógico de los registros. En cada situación funciona de forma
diferente:

119


Fallo en Dimensiones

Esta situación genera una desactivación de los procesos de carga del Data Warehouse
para el centro en cuestión. Quedando pendiente su re-activación hasta subsanar el error.

Fallo en Hechos

Esta situación no genera una parada de los procesos de carga, sino que genera una serie
de rechazos de los registros que no han podido ser cargados en el Data Warehouse,
quedando pendiente su posterior incorporación en futuros archivos.

Mecánica de las cargas

La carga de los Centros Hospitalarios es independiente entre ellos, pudiendo seguir diferente
periodo de carga. Algunos de los pasos de la carga no afectan la continuación de la carga,
mientras que otros pueden llegar a paralizar la carga de un Centro e incluso la carga de todos
los Centros. La carga de datos se realiza automáticamente a través de la herramienta Oracle9i
Warehouse Builder®. Las restricciones indicadas para realizar las cargas son:

1. Se comienza con la carga de Población de Referencia, de existir el archivo a cargar.
Este fichero no afecta para nada a la carga y la información que contiene sólo afecta a
una serie de indicadores calculados en los informes, por lo que si existe problemas en
su carga, aparece el correspondiente registro de error; pero la carga continúa sin
problemas.

2. Se continúa con la carga de Procesos, si existe. La carga de esta dimensión sí que
afecta a la información del Data Warehoise debido a que valores estables de la tabla
de hechos LELEQCHE, son definidos por esa dimensión y dependiendo del valor
asociado en cada momento puede significar una cosa u otra. La dimensión Proceso, no
conlleva seguimiento de cambio dada que la información de esa dimensión debería ser
totalmente estable. Un problema en la carga de esta dimensión paraliza la carga
completa de todos los Centros Hospitalarios hasta que un Administrador resuelva el
problema, dado que la información incorrecta o incompleta de esta dimensión puede
conllevar un análisis incorrecto.

3. A continuación se cargan las dimensiones comunes a LEQ y CEX, así como las
dimensiones que afectan solamente a LEQ. Un fallo en esta carga paraliza la carga del
Centro Hospitalario afectado hasta la intervención del Administrador.

120


4. A continuación se lanza la carga de los hechos de LEQ. Un problema en esta carga
paraliza el Centro Hospitalario afectado.

5. Por último se cargan las dimensiones específicas de CEX y sus hechos. Un problema
en cualquiera de las dos cargas implica una parada en las cargas del Centro hasta una
intervención del Administrador.

En este proyecto conlleva una gran cantidad de información diaria, información que permite
“cerrar” unos registros al haber cerrado su ciclo de vida y resuelto la intervención quirúrgica o la
cita en un sentido u otro. Estos registros ”cerrados” son estables sin futuras modificaciones y
sólo van a ser utilizado para análisis y toma de decisiones, por otro lado función primordial de
nuestro Data Warehouse y otra información en continuo movimiento implicando incluso varias
modificaciones diarias. Por esto y dado que se almacena mucha información histórica la
filosofía de trabajo en las cargas que se utiliza, es la de utilizar tablas intermedias de igual
formato que las tablas definitivas, de manera que toda la gestión se efectúa sobre un número
muy pequeño de registros (los registros que son sensibles de modificarse al estar “abiertos”)
dejando el resto libres de bloqueos durante la carga. Las ventajas que se obtienen de esta
manera son:

• Manipulación de pocos registros, con lo que las busquedas y modificaciones son más
rápidas.

• Pocos bloqueos. Al realizarse los análisis sobre una estructura y las modificaciones
sobre otras, los bloqueos son nulos.

• Problemas de deshacer nulos. Si durante la carga se produce un error en el sistema y
la carga está a medias, la solución es tan sencilla como eliminar las tablas temporales
y volver a empezar.

Los esquemas globales para las cargas se pueden resumir en:

Para la carga de Lista de Espera Quirúrgica:

121


Fig. 4.9 Flujo de carga para RDQ

En este flujo aparecen representados las entidades o estructuras que se ven afectadas por el
flujo del proceso de carga. El flujo es invocado por el Oracle9i Warehouse Builder®. Una vez
invocado llamará al LANZALEQ, desarrollados en PL/SQL que cargan las tablas de hechos.

Las tablas de desacoplo utilizadas son:
Hechos Tabla Descripción
RDQ LELEQCAX Estructura que recibe la información del HP-HIS. Esta información es
incorporada a partir de un proceso del Oracle Warehouse Builder. Esta
estructura se purga cada vez que se realiza una carga (inicial, incremental) de
cualquier centro.
LELEQDAX Estructura donde se almacenan los registros una vez procesados e inicializados.
En esta estructura se mantienen los registros de los pacientes que se
encuentran pendientes de tener salida en la lista de espera. Únicamente se
eliminan los registros finalizados.
LELEQCDS Estructura donde se almacenan los diferentes vectores para un paciente
determinado. La unidad básica del vector es mensual y cualquier fecha (Fecha
Suspensión, Fec. Aplazamiento y Fec. Derivación) genera una fragmentación.
Una vez finalizada la carga se realiza un “Truncate” de la tabla.
LEGERRAX Estructura Auxiliar donde se almacenan todos los mensajes que se pueden
producir en un proceso de carga de hechos de cualquier CEGA. No se realiza
ningún tipo de mantenimiento sobre esta estructura.
SYERROAX Estructura donde se almacenan los registros rechazados durante los procesos
de carga. No se realiza ningún tipo de mantenimiento sobre esta estructura.

122


Para la carga de Lista de Consulta externa:

Fig. 4.10 Flujo de carga para RDQ

Y sus tablas de desacoplo:

Hechos Tabla Descripción
CEX LECOEXAX Estructura que recibe la información del HP-HIS. Esta información es incorporada a
partir de un proceso del Oracle Warehouse Builder. Esta estructura se purga cada
vez que se realiza una carga (inicial, incremental) de cualquier centro.
LECOEDAX Estructura donde se almacenan los registros una vez procesados e inicializados. En
esta estructura se mantienen los registros de las citas que se encuentran pendientes
de tener salida en consulta externa. Únicamente se eliminan los registros finalizados.
LECOEXDS Estructura donde se almacenan los registros previos a la carga de los hechos. Una
vez finalizada la carga se realiza un “Truncate” de la tabla.
LEGERRAX Estructura Auxiliar donde se almacenan todos los mensajes que se pueden producir
en un proceso de carga de hechos de cualquier CEGA. No se realiza ningún tipo de
mantenimiento sobre esta estructura.
SYERROAX Estructura donde se almacenan los registros rechazados durante los procesos de
carga. No se realiza ningún tipo de mantenimiento sobre esta estructura.

Debido a la gran cantidad de información manejada en los procesos de transformación y carga,
es fundamental cuidar al máximo la optimización de los procesos para garantizar un
rendimiento adecuado. Durante las cargas se eliminan todos los índices existentes en las
tablas en las que se carga la información, a excepción de los índices sobre campos sobre los
que se realicen lookups. Los índices serán reconstruidos por completo una vez finalizada la

123


carga. Por ejemplo, en los logs de carga de hechos se consiguen cargar algo más de 40
registros por segundo. Estas mismas cargas con todos los índices activados no procesaron
más de 4 registros por segundo, diez veces más lento. Los tiempos de carga de las
dimensiones son algo mayores debido al seguimiento de cambios:

4.4. Despliegue. Aplicaciones de usuario.

Existen numerosas maneras de explotar la información contenida en un Data Warehouse,
desde la utilización de un cliente de base de datos sencillo que simplemente permita ejecutar
consultas SQL hasta la utilización de herramientas con avanzadas capacidades de análisis y
generación automática de consultas. Para este proyecto se ha utilizado una herramienta de
análisis como es el Discoverer de Oracle. Discoverer es una herramienta prácticamente
intuitiva que permite explorar la base de datos del sistema dimensional, realizar análisis
relacionales y en diversos niveles de profundidad de la información, construir informes,
mantenerlos, modificarlos, actualizarlos en instantes y visualizarlos de diferentes formas,
inclusive gráficas. Además de proporcionar difusión a través de la WEB. Esencialmente,
permite a los usuarios de cualquier y todos los niveles de la organización, acceder al Data
Warehouse, en correspondencia con los esquemas de seguridad que se dispongan
integralmente para el conjunto de las aplicaciones. Discoverer proporciona facilidades de uso y
un muy buen desempeño en la exploración de datos.

Para generar informes de usuario con Discoverer es necesario construir una capa de
metadatos denominada Área de Negocio utilizada por la herramienta para hacer la información
más accesible al usuario organizándola según sus conocimientos y permitiendo construir
automáticamente las consultas SQL. La visualización de la herramienta para el usuario es del
tipo explorador de Windows como podemos ver a continuación

Fig. 4.11 Vista del área de negocio según Discoverer

124


A continuación se proporciona una definición de los componentes definidos en el Área de
Negocio de Discoverer para LEQ, aunque si se desea ver todos los definidos para LEQ y CEX
se puede consultar el documento: Guía de uso de Discoverer

Carpeta Elemento Descripción
Hospital Cod. CEGA Código identificativo del Centro Hospitalario en la Comunidad
Cod. Nacional Código Nacional del Centro Hospitalario
Nombre Hospital Nombre del Centro Hospitalario
Sector Sector al que pertenece el Centro Hospitalario
Cod. Postal Código Postal del Centro Hospitalario
Provincia Provincia en la que se encuentra el Centro Hospitalario
Municipio Municipio en el que se encuentra el Centro Hospitalario
Población Referencia Población Ref. Número de pacientes que son atendidos en el Centro Hospitalario
Pacientes Ident. Ciudadano Identificación del ciudadano. Valor interno
NHC Número de Historial Clínico
Nombre Nombre del paciente
Apellido 1 Primer apellido del paciente
Apellido 2 Segundo apellido del paciente
Apellidos y Nombre Apellidos, Nombre del paciente
DNI DNI del paciente
Num. Seguridad Social Número de la Seguridad Social
CIP CIP del paciente
CIAS Código de Identificación de Atención Sanitaria
Centro Salud Centro de Salud al que pertenece el paciente
Edad Paciente Edad del paciente en este instante.
Fecha Nacimiento Fecha Nacimiento del paciente
Telefono Teléfono del paciente
Telf. Contacto Segundo teléfono de contacto del paciente
Dirección Dirección del paciente
Cod. Postal Pac. Código postal del paciente
Población Pac. Población del paciente
Provincia Pac. Provincia del paciente
CCAA Pac. Comunidad autónoma del paciente
Cod. CEGA CEGA del Centro Hospitalario al que pertenece el paciente
Cod. Centro AP. Código del Centro de Atención Primaria del paciente
Centro A.P. Nombre del Centro de Atención primaria del paciente
Sexo Sexo Sexo del Paciente
Profesionales Apellidos, Nombre Apellidos y Nombre del profesional que atendió la cita
Nombre Nombre del profesional que atendió la cita
Apellidos 1 Primer apellido del profesional que atendió la cita
Apellidos 2 Segundo apellido del profesional que atendió la cita
DNI DNI del profesional que atendió la cita
CIAS Código CIAS del profesional que atendió la cita
Cod. Colegiado Número de colegiado del profesional que atendió la cita
Cod. Local Código local del profesional que atendió la cita
Activo Indica si ese profesional está activo o ya no trabaja en el Centro.
Cod. CEGA CEGA al que pertenece el profesional que atendió la cita en el
momento de atenderle
Anestesia Agrup. Anestesia Agrupación de los tipos de anestesia
Cod. Anestesia Código de Anestesia
Anestesia Anestesia que se solicita para el paciente
Diagnosticos CIE 1 Cod. Capítulo Diag. A Código del capítulo del diagnóstico A indicado al paciente
Capitulo Diag. A Capítulo del diagnóstico A indicado al paciente
Cod. Seccion Diag. A Código de la sección del diagnóstico A indicado al paciente
Sección Diag. A Sección del diagnóstico A indicado al paciente
Cod. Categoria Diag. A Código de la categoría del diagnóstico A indicado al paciente
Categoria Diag. A Categoría del diagnóstico A indicado al paciente
Cod. Subcategoria Diag. A Código de la subcategoría del diagnóstico A indicado al paciente
Subcategoria Diag. A Subcategoría del diagnóstico A indicado al paciente
Cod. Subclasificación Código de la subclasificación del diagnóstico A indicado al paciente
Diag. A
Subclasificación Diag. A Subclasificación del diagnóstico A indicado al paciente
Diagnosticos CIE 2 Cod. Capítulo Diag. B Código del capítulo del diagnóstico B indicado al paciente
Capitulo Diag. B Capítulo del diagnóstico B indicado al paciente

125


Cod. Seccion Diag. B Código de la sección del diagnóstico B indicado al paciente
Sección Diag. B Sección del diagnóstico B indicado al paciente
Cod. Categoria Diag. B Código de la categoría del diagnóstico B indicado al paciente
Categoria Diag. B Categoría del diagnóstico B indicado al paciente
Cod. Subcategoria Diag. B Código de la subcategoría del diagnóstico B indicado al paciente
Subcategoria Diag. B Subcategoría del diagnóstico B indicado al paciente
Cod. Subclasificación Código de la subclasificación del diagnóstico B indicado al paciente
Diag. B
Subclasificación Diag. B Subclasificación del diagnóstico B indicado al paciente
Procedimientos CIE 1 Cod. Capítulo Diag. A Código del capítulo del procedimiento A indicado al paciente
Capitulo Diag. A Capítulo del procedimiento A indicado al paciente
Cod. Seccion Diag. A Código de la sección del procedimiento A indicado al paciente
Sección Diag. A Sección del procedimiento A indicado al paciente
Cod. Categoria Diag. A Código de la categoría del procedimiento A indicado al paciente
Categoria Diag. A Categoría del procedimiento A indicado al paciente
Cod. Subcategoria Diag. A Código de la subcategoría del procedimiento A indicado al paciente
Subcategoria Diag. A Subcategoría del procedimiento A indicado al paciente
Cod. Subclasificación Código de la subclasificación del procedimiento A indicado al
Diag. A paciente
Procedimientos CIE 2 Cod. Capítulo Diag. B Código del capítulo del procedimiento B indicado al paciente
Capitulo Diag. B Capítulo del procedimiento B indicado al paciente
Cod. Seccion Diag. B Código de la sección del procedimiento B indicado al paciente
Sección Diag. B Sección del procedimiento B indicado al paciente
Cod. Categoria Diag. B Código de la categoría del procedimiento B indicado al paciente
Categoria Diag. B Categoría del procedimiento B indicado al paciente
Cod. Subcategoria Diag. B Código de la subcategoría del procedimiento B indicado al paciente
Subcategoria Diag. B Subcategoría del procedimiento B indicado al paciente
Cod. Subclasificación Código de la subclasificación del procedimiento B indicado al
Diag. B paciente
Subclasificación Diag. B Subclasificación del procedimiento B indicado al paciente
Prioridad Cod. Prioridad RDQ Código para la prioridad según el RDQ
Cod. Prioridad CEX Código para la prioridad según CEX
Prioridad Prioridad del movimiento
Cod. BOE RDQ Código de la prioridad según el BOE para RDQ
Cod. BOE CEX Código de la prioridad según el BOE para CEX
Limite Límite, en días para esa prioridad
Letra Prioridad Nemotécnico empleado para la prioridad de tres dígitos
Procesos Proceso Garantizado Descripción del proceso garantizado
Garantizados Abreviatura Abreviatura para el proceso garantizado
Patologías Cod. Patología Código Patología
Patologías Patologías
Clasificación BOE Clasificación BOE de las Patologías
Clasificación BOA Clasificación BOA de las Patologías
Situación Garantía Garantizado Indica si un proceso está garantizado o no
Sit. Garantía Situación exacta en la que se encuentra un proceso con respecto a
la garantía
Cod. Sit. Garantía Código de la situación exacta en la que se encuentra un proceso
con respecto a la garantía
Motivos Perdida Cod. Mot. Perd. Garantia Código del motivo por el que se pierde la garantía
Garantía Mot. Perd. Garant Descripción del motivo por el que se pierde la garantía
Motivos Rechazo Cod. Rechazos Deriv. Código de los rechazos a la derivación
Derivación Mot. Rechazo Deriv. Descripción del motivo del rechazo a la derivación
Motivos Suspensión Cod. Mot. Susp. Garantia Código del motivo de la suspensión de la garantía
Garantía Mot. Susp. Garantía Motivo de la suspensión de la garantía
Motivos Salida Cod. Normalizado Código unificado, del motivo de la salida del RDQ
Normalizado Descripción unificada del motivo de la salida del RDQ
Cod. Motivo Salida Código del motivo de la salida del RDQ. Este código es propio de
cada Centro Hospitalario
Motivo Salida Motivo de la salida del RDQ. Esta descripción es propia de cada
Centro Hospitalario
Intervenciones Clasificación de los motivos de Salida. Indicando cuales son
intervenciones
Tipo Lista Cod. Actividad Código de la actividad a al que está ligada la lista
Tipo Actividad Tipo de actividad a la que está ligada al lista
Cod. Lista Código de la lista
Lista Lista

126


Tipo Espera Nemónico Código de tres letras para identificar de forma sencilla el Tipo de
Espera
Descripción Descripción completa para el Tipo de Espera
Situación Lista Cód. Situación en lista Código de la situación en la que se encuentra el movimiento. Este
Oficial código es Oficial
Situación en lista Oficial Situación en la que se encuentra el movimiento. Este código es
oficial
Cod. Situación en lista Código de la situación en la que se encuentra el movimiento. Este
código es propio de cada Centro Hospitalario
Situación en lista Situación en la que se encuentra el movimiento. Este código es
propio de cada Centro Hospitalario
Financiación Paciente Financiación Financiador del paciente
Garante Garante del paciente
Serie Temp. Mes Mes de Estudio
Num. Mes Número de Mes de Estudio
Trimestre Trimestre de Estudio
Año Año de Estudio
Servicios Cod. Grupo funcional Código Grupo Funcional
Grupo funcional Descripción del Grupo Funcional
Cod. Área Gest. Analítica Código del área de gestión analítica
Área Gestión Analítica Descripción del área de gestión analítica
Cod. Especialidad Código del servicio maestro
Especialidad Descripción del servicio maestro
Cod. Servicio Código del grupo funcional homogéneo
Servicio Grupo funcional homogéneo
Intervalos RDQ Intervalos BOE Intervalos definidos por el BOE
Intervalos BOA Intervalos definidos por el BOA
Intervalos Intervalos de estudio
Indicadores Edad Paciente Edad del paciente al ingresar en RDQ
Num. Historial Mov. Número del historial clínico del movimiento
Fecha Inicio Análisis Fecha de inicio del análisis
Fecha Fin Análisis Fecha de fin del análisis y fecha de corte en los indicadores al corte.
Fecha Entrada RDQ Fecha de entrada del movimiento en el Registro de Demanda
Quirúrgica
Fecha Salida RDQ Fecha de salida del movimiento en el Registro de Demanda
Quirúrgica
Fecha Optima Este dato tiene sentido únicamente para listados de pacientes.
Intervención
Fecha Perdida Garantía Fecha en la que el movimiento perdió la garantía al alguna razón
Fecha Inicio Suspensión Fecha de inicio de un aplazamiento en un proceso garantizado
Fecha Fin Suspensión Fecha de fin de un aplazamiento en un proceso garantizado
Fecha Derivación Fecha en el que se derivó un paciente a otro Centro Hospitalario
Fecha Rechazo Fecha en la que un paciente fue rechazado tras una derivación a
Derivación otro centro
Fecha Prevista Fecha en la que se estima que el paciente será intervenido.
Intervención
Fecha Inicio Aplazamiento Fecha de inicio de un aplazamiento del movimiento
Fecha Fin Aplazamiento Fecha de fin de un aplazamiento del movimiento
Fecha Apto Fecha en la que el paciente se da como apto para su intervención
Fecha Prevista Caducidad Fecha en la que las pruebas realizadas a un pacientes caducarán y
se deberán volver a realizar
Ámbito
Derivable Flag que indica si un paciente se puede o no derivar a otro Centro
Hospitalario
Pacientes Pendientes Número de pacientes incluidos en el RDQ antes de la fecha final del
RDQ periodo de estudio y que no tengan fecha de salida.
Pacientes Garantía Activa Pacientes pendientes en RDQ con procesos incluidos en el Decreto
de Garantía de Plazo. Con código de situación en lista G (CON
GARANTÍA)
Pacientes Derivados a fin Número de pacientes derivados a otro Centro Hospitalario, el último
Periodo día del periodo de estudio.
Pacientes Derivados Número de pacientes derivados a un Centro Concertado en el
periodo de estudio y que no hayan sido rechazados durante el
periodo.
RDQ Superior a 180 días Número de pacientes que llevan en el RDQ más de 180 de espera
total.
RDQ Superior a 180 días Número de pacientes que llevan en el RDQ más de 180 de espera

127


EE estructural.
RDQ 91 a 180 días Número de pacientes que llevan en el RDQ de 91 a 180 días de
espera total.
RDQ 91 a 180 días EE Número de pacientes que llevan en el RDQ de 91 a 180 días de
espera estructural.
RDQ 0 a 91 días Número de pacientes que llevan en el RDQ menos de 91 días de
espera total.
RDQ 0 a 91 días EE Número de pacientes que llevan en el RDQ menos de 91 días de
espera estructural.
% Salidas sobre IQ % Salidas sobre IQ
Entradas RDQ Número de movimientos que entraron en el RDQ durante el periodo
de estudio
Salidas RDQ Número de pacientes que salieron del RDQ durante el periodo de
estudio
Perdidas Garantía Nº de pacientes que han perdido la garantía en un periodo. Con
código de situación en lista P (G.PERDIDA)
Demora Media Media del número de días desde la fecha de entrada en el RDQ
hasta la fecha final del periodo de estudio de los pacientes
pendientes a la fecha de corte.
Demora Media Estructural Media del número días que llevan esperando los pacientes
pendientes a fecha final del periodo de estudio y que se encuentran
en Espera Estructural
Demora Media Total Media del número días que llevan esperando los pacientes
pendientes a fecha final del periodo de estudio.
Demora Media Centro Media de los días que llevan esperando los pacientes derivados y
Concertado sin salida al último día del periodo de estudio.
Demora Media Tiempo que tardaría en absorberse el total del RDQ del intervención
Prospectiva al ritmo de trabajo de los últimos 365 días
Espera Media Espera Media
Espera Media Estructural Espera Media Estructural
Espera Media Total Espera Media Total Salidas
Salidas
Espera Media Centro Espera Media Centro Concertado
Concertado
Índice Entrada / Salida Relación de entradas por salidas
Índice Demora Estructural Relación entre la espera media estructural y la demora media
estructural
Índice Demora Total Relación entre la espera media total y la demora media total
MPA – Entradas RDQ Número de movimientos que entraron en el RDQ durante el mismo
periodo de estudio del año anterior
MPA – Salidas RDQ Número de pacientes que salieron del RDQ durante el mismo
periodo de estudio del año anterior
MPA – Pacientes Número de pacientes incluidos en el RDQ sin fecha de salida, en el
Pendientes mismo intervalo del año anterior.
MPA – Pacientes Garantía Pacientes pendientes en RDQ con procesos incluidos en el Decreto
de Garantía de Plazo, en el mismo intervalo del año anterior. Con
código de situación en lista G (CON GARANTÍA)
MPA – Pacientes Número de pacientes derivados a un Centro Concertado en el
Derivados mismo periodo de estudio; pero del año anterior y que no hubieran
sido rechazados durante el periodo.
MPA - Demora Media Número de días desde la fecha de entrada en el RDQ de los
pacientes pendientes, hasta la fecha final del periodo de estudio;
pero del año anterior, dividido por el número de pacientes.
MPA – Demora Media Número de días desde la fecha de entrada en el RDQ hasta la
Estructural misma fecha final; pero del año anterior, de los pacientes
pendientes, eliminando periodos de suspensión y aplazamientos,
dividido por el número de pacientes.
MPA – Demora Media Número de días desde la fecha de entrada en el RDQ de los
Total pacientes pendientes, hasta la fecha final del periodo de estudio;
pero del año anterior, dividido por el número de pacientes.
MPA – Espera Media Número de días que esperaron los pacientes, que a fecha de fin de
estudio del año anterior, ya habían salido de RDQ, eliminando los
aplazamientos no estructurales, dividido por el número de esos
pacientes.
Estructural estudio del año anterior, ya habían salido de RDQ, eliminando los
aplazamientos no estructurales, dividido por el número de esos
pacientes.

128


Total Salidas estudio del año anterior, ya habían salido de RDQ, sin eliminar
ningún aplazamiento, dividido por el número de esos pacientes.
TAM – Entradas Número de movimientos que entraron en el RDQ durante los 365
días anteriores al periodo de estudio
TAM – Salidas Número de pacientes que salieron del RDQ durante los 365 días
anteriores al periodo de estudio
TAM – Perdidas Garantía Nº de pacientes que han perdido la garantía en los 365 días
anteriores al periodo en estudio.
TAM – Pacientes Número de pacientes derivados a un Centro Concertado en los 365
Derivados días anteriores al periodo de estudio.
TAM – Indice Entrada / Relación de entradas por salidas en los 365 días anteriores al
Salida periodo de estudio
Días Totales Total de días que un paciente está en RDQ por una u otra razón.
Días EE Número de días que un paciente está en RDQ por causas
hospitalarias
Días Sin Spn/Apl Días que un paciente está en RDQ, eliminando todos los
aplazamientos y suspensiones
Días Drv Número de días que un paciente está en derivado.

La herramienta de generación de informes permite a los usuarios elegir entre las diferentes
carpetas y elementos y presenta al usuario diferentes pantallas para especificar las
restricciones deseadas. A partir de esa elección y de las relaciones entre los datos definidas en
el área de negocio, Discoverer construye las consultas SQL necesarias para obtener la
información. Pueden encontrarse más detalles acerca de Discoverer y su manejo en
[Darlene01].

En las figuras siguientes, pueden verse ejemplos de información obtenida a partir de los datos
del Data Warehouse desarrollado en este trabajo.

• La figura 4.12 es un listado con los pacientes pendientes de intervención quirúrgica
según las Especialidades y Prioridades para el mes de enero.

Fig. 4.12 Pacientes pendientes por especialidad y prioridad

• La figura 4.13 es un listado de entradas y salidas en LEQ por Centro Hospitalario,
Especialidad e Intervalo de estudio.

129


Fig. 4.13 Entradas y salidas por Centro e intervalo

• La figura 4.14 corresponde al mismo informe 4.13; pero en formato gráfica, para un
vistazo más rápido de la información.

Fig. 4.14 Entradas y salidas por Centro e intervalo

Por otro lado se realizaron informes a media que permitieran análisis más complejos. Estos
informes no pueden ser elaborados por Discoverer dada la limitación de Discoverer de montar
informes con varios gráficos o combinando graficos y listados, por ello se utilizó la herramienta
Oracle Reports® que es una poderosa herramienta que tiene por objetivo el diseño y la
generación de informes, permite la creación de reportes en archivos jsp (Java Server pages),

130


rdf, xml, rtf entre otros. De igual manera permite enviar el resultado de los informes a archivos
de texto, pdf, html, xml, rtf, de texto delimitados, entre otros, lo cual permite su lectura y
publicación en diversos formatos. Con esta herramienta se consiguieron publicar vía web
informes de ejecución inmediata como los de la fig. 4.15, que no llega a ser un Cuadro de
Mandos; pero es una primera aproximación al tema.

El concepto de cuadro de mando deriva del concepto denominado Tableau de bord en Francia
– Dashboards en inglés - que traducido de manera literal, vendría a significar algo así como
tablero de mandos, como en el salpicadero de un coche. La gestión de las empresas requiere
un sistema de indicadores que nos faciliten la toma de decisiones y el control, es decir, requiere
un sistema completo de análisis financiero. El sistema de indicadores debe organizarse en un
cuadro de mando que recoge los principales indicadores y los presenta de un modo claro y útil.
El cuadro de mando es un sistema que nos informa de la evolución de los parámetros
fundamentales del negocio. Para mayor información sobre el tema se puede leer el libro
[Wayne06]

131


Fig. 4.15 Estudio de Consulta Externa

132

5. CONCLUSIONES Y TRABAJOS FUTUROS


5.1. Conclusiones

El trabajo realizado alcanzó todas las perspectivas del cliente y los objetivos de un Data
Warehouse.

• Homogeneizó la información de todos sus Centros Hospitalarios pudiendo de esta
manera comparar y mejorar el servicio entre los distintos Centros, permitiéndole de
esta manera una toma de decisiones rápida, clara y concisa.

• Consiguió hacer accesible la información de toda la organización a las
diferentes capas de usuarios de una forma fácil y rápida, sin necesidad de
esperar a final de mes o a recolección de información tardía, manteniendo una
granularidad en la seguridad y asegurando que cada usuario viera lo que le
correspondía.

• La información fue consistente en todos los centros, consiguiendo que todos
midieran lo mismo de la misma manera y al mismo tiempo.

• Se vió como se podía incorporar nueva información y generar nuevas
consultas de forma rápida sin afectar al resto de la información existente,
consiguiendo toma de decisiones rápidas y con datos que las ratificaran.

5.2. Trabajos futuros

Un punto importantísimo que surgió durante el desarrollo del Data Warehouse de Lista de
Espera fue un tipo de fraude, hasta cierto punto consentido pero perjudicial para la
Sanidad Pública y que por lo tanto debería ser controlado de forma inmediata, la
duplicidad de pacientes en Listas de Espera. Dado que hasta el momento las Listas de
Espera estaban disociadas por Centro Hospitalario y Provincias, el estudio sólo se
realizaba en número de pacientes, no controlando la identidad de dicho paciente. La
construcción del Data Warehouse permitió de manera rápida y concisa, comprobar que
algunos pacientes, sobre todo aquellos que vivían en Poblaciones limítrofes entre dos
Provincias asistían a diferentes Centros a la vez, dependiendo de la “fama” del profesional
o de las circunstancias personales, haciéndo así que la Lista de Espera aumentara y se

133


produjeran muchos rechazos, una vez que se le atendía en una de ellas e incluso ignorar
las planificaciones de uno de los Centros una vez que había sido atendido en otro,
ralentizando el servicio, así como su encarecimiento o llegando a desperdiciar un slot de
servicio que ha otro paciente le era de vital importancia.

Por otro lado, durante el desarrollo del Data Warehouse de Lista de Espera se vió como se
podía ampliar y mejorar esta solución con otros Data Marts que pudiera integrar un proyecto
general en el que se incorpore información sobre las diferentes Areas:

• Consumo farmacéutico

• Gestión de Agendas

• Atención Primaria

• Salud Mental

• Servicios Sociosanitarios

• Control Económico y Presupuestario

• Asistencia Concertada y Prestaciones

• Inspección Sanitaria e Incapacidad temporal

• Recursos Humanos y Relaciones Laborales

La finalidad de cada Data Mart sería dar respuesta a las necesidades de explotación de la
información en cada una de las áreas.

Dada la similitud del tema y el conocimiento y manejo ya adquirido durante el desarrollo del
Data Warehouse de Lista de Espera del tema, el Data Marts de Agendas se comenzó a
desarrollar de forma inmediata, generando una nueva estrella de conexión directa con la de
Consulta Externa. Por otro lado, aunque el tema es diferente; pero sería un puente de
conexión inmediata con el Data Marts de Atención Primaria, se comenzó con la Toma de
Requerimientos para el Data Marts de “Consumo farmacéutico”.

134

6. REFERENCIAS

6. REFERENCIAS

[Date93] Date, C.J. “Introducción a los Sistemas de Bases de Datos, Volumen 1”. Addison-
Wesley, 1993.

[Darlene01] Darlene Armstrong-Smith; Michael Armstrong-Smith “MANUAL DE ORACLE
DISCOVERER“. Editorial McGraw-Hill 2001

[Gamma95] Gamma, Erich. “Design Patterns. Elements of Reusable Object Oriented
Software”. Addison-Wesley, 1995.

[Kimball96] Kimball, Ralph. “The Data Warehouse Toolkit”. Wiley, 1996.

[Kimball98] Kimball, Ralph. “The Data Warehouse Lifecycle Toolkit”. Wiley, 1998.

[Lane99] Lane, Paul. “Data Warehousing Guide, Release 2 (8.1.6)“. Oracle Corporation,
1999.

[Wayne06] Wayne W. Eckerson. “Performance Dashboards. Measuring, Monitoring, and Managing
Your Business”. Wiley, 2006

135

6. REFERENCIAS

136

7. ENLACES DE INTERÉS


The Data Warehousing Information Center www.dwinfocenter.org
CIO’s Magazine’s DW Resource Center www.cio.com/forums/data
Data Warehousing on the WWW www.datawarehousing.com
Ralph Kimball Associates www.rkimball.com
IBM Cognos 8 Business Intelligence http://www.cognos.com/
MySQL www.mysql.com
Business Objects www.businessobjects.com
Archives of BUSOB-L listserv.aol.com/archives/busob-l.html
Your Database Support and Training Experts http://www.dba-oracle.com/
Oracle Business Intelligence Discoverer
http://www.oracle.com/technology/products/discoverer/index.html

137


138

Pfc itziar angoitia_espinosa

Más contenido relacionado

Destacado (7)

Similar a Pfc itziar angoitia_espinosa (20)

Pfc itziar angoitia_espinosa