Procesos ETL1

No veo lógico rechazar datos porque parezcan
increíbles.
Fred Hoyle
Procesos ETL
4
L os procesos ETL (Extraction, Transformation, and Loading, extracción, transformación y
carga) son los encargados de transportar los datos que contienen las fuentes de datos al almacén
de datos asegurando la calidad de los datos que serán luego analizados mediante las herramientas
de explotación. En este capítulo, tras una introducción a los procesos ETL, discutiremos las
opciones de diseño de estos procesos en función de la fase en la que se requieran: la de extracción,
transformación o carga.
Índice
4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2. Fase de extracción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3. Fase de transformación . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4. Fase de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Copyright © 2013. ECU. All rights reserved.
4.5. Elementos principales de diseño . . . . . . . . . . . . . . . . . . . . . 65
4.1. Introducción
Para introducir los procesos ETL, nada mejor que recordar la definición de almacenes de
datos que dio Bill Inmon, uno de los pioneros de esta tecnología:
Un almacén de datos es una colección de datos orientados por temas, integrados,

no volátiles y variables en el tiempo en apoyo de la toma de decisiones estratégicas.
de donde podemos destacar la cualidad de integrar múltiples fuentes de datos.
Trujillo, J. C. (2013). Diseño y explotación de almacenes de datos : Conceptos básicos de modelado multidimensional. ProQuest Ebook
51
Central <a onclick=window.open('http://ebookcentral.proquest.com','_blank') href='http://ebookcentral.proquest.com' target='_blank' style='cursor: pointer;'>http://ebookcentra
Created from upnortesp on 2020-10-01 22:03:35.
52 Capítulo 4. Procesos ETL
Figura 4.1.: Importancia de los procesos ETL
La integración de estas fuentes de datos se realiza mediante los denominados procesos de

extracción, transformación y carga o procesos ETL (del inglés Extraction-Transformation-
Loading). Estas tres fases en las que se puede dividir un proceso ETL se definen en base a
la extracción de datos desde fuentes de datos operacionales y heterogéneas, transformación de
esos datos mediante operaciones de limpieza tales como conversión de tipos, normalización, eli-
minación de valores nulos, etc. y su posterior carga en el almacén de datos dada una cierta
política de actualización.
Algunas tareas comunes de los procesos ETL son: la unión (join) de datos de distintas fuentes,
la agregación de datos, la conversión a un formato común, la generación de claves derivadas, la
verificación de la calidad de los datos, etc.
Con ello, los procesos ETL son de gran importancia para el éxito de una arquitectura de
almacenes de datos. Éstos contribuyen a que los datos sean relevantes y útiles para la toma de
decisiones. En la fig. 4.1 se muestran algunas de las claves del éxito de un almacén de datos en
las que los procesos ETL contribuyen, tales como la relevancia de los datos, su utilidad, calidad,
precisión y accesibilidad. Por la gran dependencia que tiene el almacén de datos de estos procesos
y dada su complejidad, los procesos ETL tienen un elevado coste en tiempo y recursos.
Consideraciones de diseño
Algunas consideraciones generales a tener en cuenta cuando se diseñan los procesos ETL son
las siguientes:
Definir una estrategia de calidad de datos para la empresa según política de toma de
decisiones.
Definir el nivel de calidad óptimo de los datos.
Considerar la modificación de las reglas de las fuentes de datos operacionales.
Documentar las fuentes de datos como paso básico para comprenderlas.
4.2. Fase de extracción 53
Diseñar los procesos de limpieza (y sus tareas) de forma muy cuidadosa.

Los procesos de limpieza iniciales pueden variar de los procesos de refresco posteriores.
Datos incorrectos o engañosos producirán decisiones estratégicas erróneas.
El coste de los procesos ETL es de aproximadamente el 50 % del presupuesto total de los
proyectos de almacenes de datos.
Actualmente, el diseño y mantenimiento de procesos ETL es todavía un asunto “pendien-
te”.
Aunque existen varias herramientas en el mercado, no disponemos de modelo o metodología
estándar para su diseño desde primeros pasos de un proyecto de almacenes de datos.
Las soluciones dadas al diseño de procesos ETL abarcan las rutinas convencionales en len-
guajes de programación de cualquier índole (desde COBOL (COmmon Business-Oriented Lan-
guage) hasta los lenguajes de 4GL (Fourth-Generation programming Language) como C/C++,
Java o Ruby), herramientas especializadas, procesos de conversión personalizada y expertos de
negocio. Algunos de los factores involucrados en tal diseño son: la investigación para el desa-
rrollo de nuevas técnicas que mejoren las actuales, la dependencia con los tipos de fuentes de
datos (relacionales, web, etc.), el grado de estandarización de las soluciones comerciales y la
integración de las fuentes de datos.
Una aproximación de los pasos en el diseño de un proceso ETL sería el siguiente:
1. Seleccionar las fuentes para extraer datos.
2. Transformar las fuentes.
3. Unir las fuentes.
4. Seleccionar las estructuras destino a cargar datos (hechos, dimensiones, etc.).
5. Traducción de los atributos de las fuentes en los destinos.
6. Cargar los datos.
El paso de transformación también puede incluir limpieza de datos, por ejemplo, para detectar
y borrar errores e inconsistencias. Con todo ello, la creación manual y mantenimiento de los
procesos ETL aumenta el coste de los almacenes de datos. Incluso cuando se disponga de una
documentación adecuada para las fuentes de datos, la documentación de un proceso ETL puede
alcanzar gran cantidad de páginas de código, por lo que también se necesitan herramientas para
su gestión (como se verá en el capítulo de metadatos).
Así, a continuación se describirán en profundidad los procesos ETL mediante la exposición
de cada una de sus fases: (I) la extracción de las fuentes de datos, (II) la transformación de los
datos extraídos y (III) su carga en el almacén de datos.
4.2. Fase de extracción

Existen diversos tipos de fuentes de datos: de producción, archivos planos, internas o externas
a la organización que da lugar al almacén de datos, etc.
Figura 4.2.: Fuentes de datos de producción
Figura 4.3.: Archivos planos de datos
Fuentes de producción
Las fuentes de datos de producción (ver fig. 4.2) son las bases de datos de los sistemas de pro-
cesamiento de transacciones (OLTP (On-Line Transaction Processing, procesamiento transac-
cional en línea)). Existen, por tanto, multitud de tecnologías que los implementan en función
del vendedor: IMS, DB2, Oracle, SAP, etc.
Factores a tener en cuenta para este tipo de fuente son: el sistema operativo, el motor de bases
de datos en los que operan, la plataforma hardware (por ejemplo, capacidad de cálculo, tamaño
de la memoria o los protocolos de comunicación) y el sistema de archivos.
Archivos planos
Los archivos planos (ver fig. 4.3) son todo tipo de archivos de texto o binarios que se encuentran
dispersos en una organización y de los que se pueden cargar datos en el almacén de datos. En
este tipo de fuente de datos, se dan las siguientes características a comentar: existen archivos
en la empresa en los que se encuentran ya los datos históricos almacenados, son útiles para
análisis de largos períodos de tiempo y para realizar la primera carga del almacén de datos y
generalmente requerirán transformaciones para habilitar su carga en el almacén de datos.
Fuentes internas y externas

Una clasificación paralela de las fuentes de información es la que se da respecto a su pertenencia
a la organización que da origen al almacén de datos. Así, las internas serán aquellas que estén
controladas por la empresa, mientras que las externas se situarán fuera de ésta.
4.3. Fase de transformación 55
Figura 4.4.: Datos internos según el sistema de origen
Algunos ejemplos de fuentes de datos internas son las de ventas, marketing y finanzas. En
ellas podemos encontrar tanto hojas de trabajo o spreadsheets con datos estructurados como
documentos de cualquier tipo con datos no estructurados. En cualquier caso, dadas las necesi-
dades de información de los analistas, puede ser necesario acceder a cualquiera de estos tipos
con independencia de la dificultad para extraer sus datos.
Por otro lado, el acceso a las fuentes de datos externas (ver fig. 4.4) depende del tipo de
tecnología con la que implementen. Tenemos desde otras bases de datos (a las que se accederá
mediante los protocolos adecuados) de compañías especializadas, información de competidores
(en informes públicos), predicciones financieras en la bolsa de valores y en general cualquier
recurso accesible a través de Internet.
Respecto a las técnicas de extracción, existen las siguientes posibilidades: los programas en
C, COBOL, PL/SQL (Structured Query Language, lenguaje de consulta estructurado) para
las fuentes de origen accesibles mediante gestores de bases de datos, gateways para el acceso
transparente de estas bases de datos y herramientas de diversa índole. Estas últimas deben
elegirse cuidadosamente en función de criterios como el coste de adquisición (que puede ser muy
alto) y mantenimiento (inclusive el propio coste de propiedad con el que muchas herramientas
cuentan), el grado de automatización que ofrecen y las capacidades para la limpieza de los datos.
4.3. Fase de transformación

La fase de transformación de un proceso ETL toma sentido dadas las anomalías que existen
en las fuentes operacionales. Por ello, se requiere, entre otras tareas, limpiar los datos. Como
ejemplo, la fig. 4.5 muestra un caso típico donde un tipo de datos complejos está almacenado
en la fuente de datos con distintas codificaciones. Gracias a los procesos ETL, estos datos se
traducen a múltiples campos donde la codificación se uniformiza.
Típicas anomalías son que normalmente no existe clave única, de codificación (un mismo tipo
de datos presenta diferentes formatos para su representación) e inconsistencias en la ortografía.
Tómese como ejemplo el mismo de la fig. 4.5, donde aparece una misma entidad (Telefónica)
con múltiples codificaciones, tanto para su identificador, nombre y dirección.
Figura 4.5.: Anomalías en las fuentes de datos
Nombre
WRAPPER
Apellidos Nombre Apellidos Salario
Salario
...
Figura 4.6.: Wrapper para abstraer archivos planos en tablas de un modelo relacional
A continuación se explicarán los operadores o transformaciones comunes que se pueden em-

plear para diseñar un proceso ETL.
Wrapper
El primero de ellos es el wrapper : un operador para transformar fuentes de datos nativos en
fuentes de datos basadas en registros. Este operador es útil para realizar la transformación de
los datos de las fuentes de datos del almacén.
Generador de claves
Otra operación es la de generar una clave única a partir de una clave compuesta en la fuente
de datos. Por ejemplo, la fig. 4.7 presenta una clave compuesta de producto donde se codifica
en un único campo desde el código del país hasta el del vendedor del producto.
Otro ejemplo de codificación múltiple se muestra en la fig. 4.8 donde el sexo de una persona
se codifica con una letra (m o f), con un bit (1 o 0) o con una etiqueta completa (masculino
Figura 4.7.: Claves compuestas
Figura 4.8.: Claves compuestas y generación de claves simples
Figura 4.9.: Generación de claves a partir de claves compuestas con errores
o femenino). Todos ellos pueden ser unificados en otro formato distinto o convertidos a alguno
de ellos como es el caso de la figura.
Asimismo, cuando alguno de los datos de origen no se corresponde con un valor entre los
esperados (fig. 4.9), entonces se deben diseñar rutinas de gestión de error según corresponda.
Conversión
Uno de los operadores más útiles en los procesos ETL es el de conversión. Por ejemplo, en la
fig. 4.10 se muestra la conversión de unidades de medida, fechas y precios. Para cada tipo, se
necesita, por un lado, identificar el dominio de origen del dato y, por otro, diseñar la rutina de
conversión propiamente dicha, donde el dominio de origen se traduce al de destino. Para estos
dominios se debe tener en cuenta que existen múltiples formatos válidos e incluso estándares y
que se pueden necesitar herramientas o filtros para preprocesarlos. En la fig. 4.11 se muestra tal
tipo de conversiones.
Figura 4.10.: Operador de conversión
Figura 4.11.: Operador de conversión (2)
Figura 4.12.: Operador de unión
Filtrado
Un filtro es toda operación que devuelve solo los datos que cumplen cierta condición. Con
los filtros se pueden transformar los valores nulos en el origen, ignorándolos, esperando a que el
usuario decida qué hacer con ellos, marcando las filas o extrayendo bajo condiciones establecidas.
Unión
El operador de unión permite combinar filas provenientes de múltiples fuentes en una única
fila atendiendo a los valores de algunos de sus campos. Esta operación se realiza como se muestra
en la fig. 4.12, donde se muestra la unión de dos consultas (select) de SQL.
Combinación
El operador de combinación sirve para integrar múltiples campos en una única fila. Por ejem-
plo, si tenemos los siguientes datos: nombre, contacto y preferencias podríamos formar una
única fila con el nombre del cliente. Ante esto, es importante destacar que debemos asegurar
que el significado de cada elemento sea el correcto. Así se evitan malas interpretaciones. Sin
embargo, establecer claramente el significado de los datos no siempre es fácil. Para paliar esta
situación se debe documentar siempre que sea posible el significado de los datos en los metadatos
correspondientes.
Fusión (merge)
El operador de fusión de datos (ver fig. 4.13) toma varias fuentes de datos compatibles y las
fusiona en la salida.
Figura 4.13.: Operador de fusión
Marcas temporales
Otra operación útil es la del marcado temporal de los datos. Permite así analizarlos a lo largo
del tiempo añadiendo marcas temporales, tanto a los hechos como a las dimensiones del almacén
de datos.
Clave sustituta
El operador de clave sustituta genera claves para el almacén de datos a partir de las de las
fuentes de origen. Por ejemplo, las ventas identificadas en el origen como SRC1, SRC2, etc., pueden
ser traducidas a DW1, DW2, etc., en el almacén de datos.
Agregación
El operador de agregación toma un conjunto de filas de datos y genera una única fila con un
conjunto de registros cuyos valores son comunes para todas las filas de origen y otro conjunto
de registros como resultado de aplicar una función de agregación sobre ellos. Esta tarea puede
realizarse durante la extracción de los datos, durante su tratamiento en la staging area o después
de cargar los datos en el almacén de datos.
Respecto a los metadatos de los procesos ETL, se deben documentar tanto las reglas de
transformación como los programas y algoritmos utilizados. Algunos de los datos para elegir la
herramienta adecuada para esta fase son: la carga de trabajo que soporta (número de operaciones
por unidad de tiempo), el uso de la CPU y del espacio en disco, el ancho de banda de la red,
el paralelismo, el tiempo de carga, la calidad de los mensajes al usuario, las capacidades de
monitorización y documentación del proceso ETL, la funcionalidad ofrecida, la interfaz gráfica,
el acceso a los metadatos de fuentes de datos y repositorio, el procesamiento de la entrada
y salida, las capacidades de limpieza, reformateo y auditoría, sus referencias y la curva de
aprendizaje.
4.4. Fase de carga

El planteamiento general para la fase de carga de un proceso ETL es el siguiente. La carga
o loading es el proceso de llevar los datos del staging area al almacén de datos. Este proceso
puede llevar mucho tiempo dados los grandes volúmenes de datos que se manejan. Por ello,
se debe considerar la ventana de carga y planificar concienzudamente la carga para intentar
automatizar todos los procesos involucrados. Es previsible que en la primera carga el volumen
de datos sea mayor que en las posteriores. En cualquier caso, es el propio entorno organizativo el
que dictaminará en buena medida cuándo realizar las cargas de datos: típicamente, se planearán
en aquellos momentos en los que la carga de trabajo sea menor en las fuentes de datos. Así, se
aliviará la potencia de trabajo requerida para las fuentes de datos sin que se detecten bajadas
en el rendimiento.
La primera carga del almacén de datos se hará con los datos históricos ya almacenados en las
fuentes de datos. Dado que se necesita almacenar la historia de los datos, se deberá planear una
primera carga masiva de datos. Para aliviar tal carga, se puede descomponer un proceso ETL en
distintas tareas ETL. Sin embargo, se seguirán requiriendo grandes cantidades de procesamiento
después de la primera carga.
Las subsiguientes cargas del almacén de datos o refrescos se realizarán conforme el ciclo de
negocio. Se detectarán los períodos de menor actividad en las fuentes de datos para realizar la
carga en esos momentos. Esta es una tarea más simple que la primera carga, pues idealmente
habrá menos datos por cargar. Los ETL son menos complejos dado que hay menos rutinas de
procesamiento después de la carga.
La estrategia de refresco será la siguiente: (I) considerar la ventana de carga, (II) identificar
los volúmenes de datos, (III) identificar los ciclos, (IV) conocer la infraestructura técnica, (V)
planificar un área de “trastienda” (staging) y (VI) determinar cómo detectar cambios. En lo
siguiente se comentarán cada uno de estos pasos.
Requisitos de usuario
En primer lugar, se deben considerar los requisitos multidimensionales de los usuarios. Ellos
definen también el ciclo de refresco. Asimismo, se deben documentar todas las tareas y procesos.
Para ello, se pueden consultar a los usuarios expertos.
Proceso de transporte
Para construir el proceso de transporte, se deberán especificar: las técnicas y herramientas

a utilizar, los métodos de transferencia de ficheros, la ventana de carga, la ventana de tiempo
para otras tareas, los volúmenes de primera carga y refresco, la frecuencia del ciclo de refresco
y el ancho de banda de conectividad.
Ventana de carga
Para considerar la ventana de carga se debe evaluar el tiempo disponible para todo el proceso
ETL. Esto se traduce en planificar, comprobar y monitorizar la carga de trabajo de las fuentes
de origen como se muestra en la fig. 4.14 donde los períodos de menor actividad del usuario
son de madrugada. Es precisamente en esos momentos cuando se debería entonces ejecutar los
procesos ETL. Planificar tal carga requerirá de una estrategia en función del volumen de datos,
4.4. Fase de carga 61
Figura 4.14.: Ventana de carga de un proceso ETL
Figura 4.15.: Ejemplo de carga (1)
la infraestructura técnica, la novedad de los datos y los requisitos de los usuarios, pues ciertos
requisitos pueden significar una ventana de carga pequeña.
Granularidad
En cuanto a la granularidad de los datos, se deben planear los requisitos de espacio: el tipo
de almacenamiento, las copias necesarias, los métodos de recuperación, el particionamiento y
la carga. Los niveles de granularidad bajos implicarán un elevado coste de carga (nivel de
procesamiento, más disco, más detalle), mientras que los niveles más altos serán más baratos al
necesitar menor detalle.
Plani cación de la carga

Las figs. 4.15 & 4.17 muestran un ejemplo de la planificación de una carga. En primer lugar,
se obtendrán los requisitos de usuario. En segundo, se diseñará el ciclo de carga en base a estos.
Tras ello, (3) se actualiza el fichero de control con los datos de la carga a realizar. En (4), el
proceso de control comienza. El siguiente paso (5) es cargar el almacén de datos. Este paso se
realiza a las tres de la mañana. Entonces se verifican, analizan y reemplazan los datos cargados
(6). A las seis, la indización de los datos comienza (7), se crean resúmenes (8) y se actualizan los
metadatos (9). Tras ello, se realizan las copias de seguridad del almacén de datos (10) y se crean
las vistas para las herramientas especializadas (11). Con todo ello, los usuarios pueden acceder

4.4. Fase de carga 63
a los datos resumidos (12), publicarlos (13) y a partir de las nueve de la mañana empezar el
acceso típico al sistema de almacenes de datos.
Refresco
Continuando con la captura de datos para refrescar el almacén de datos, ésta se realiza de la
siguiente forma. Se capturan los nuevos datos de los hechos en primer lugar. Luego se capturan
los datos de las dimensiones que han cambiado. Para ello, se debe determinar el método de
captura. Existen varios: reemplazar datos a gran escala, comparar instancias de bases de datos,
comprobar/escanear las marcas temporales (timestamping), lanzar los triggers en las bases de
datos de origen, escanear los archivos de log de éstas. Por supuesto, para cualquier refresco, se
pueden utilizar técnicas híbridas como combinación de cualquiera de las anteriores.
Al refrescar existen dos estrategias. La primera es reemplazar a gran escala los datos ya guar-
dados. Sin embargo, esta estrategia es cara, los datos históricos son limitados, se reemplazan los
períodos de tiempo y está orientada solo a la carga de data marts. La segunda, es la comparación
de instancias de la base de datos actual con las pasadas. Esta estrategia es simple, pero todavía
cara y necesita ficheros de cambios con los cambios de los datos operaciones desde el último
refresco.
Los cambios para refrescar pueden identificarse, como se ha comentado, mediante el marcado
temporal de los datos de origen. Este método permite una rápida comprobación para los registros
cambiados desde la última extracción, aunque se debe actualizar la fuente de datos con las fechas
de cada dato cuando se cambian a la par de que no es capaz de detectar los datos borrados.
Otro método es el uso de disparadores en las fuentes de datos. Estos disparadores, a diferencia
del método anterior, permiten identificar el cambio tan pronto ocurre. Los datos cambiados son
interceptados a nivel del servidor, aunque hace un uso extra de los dispositivos de entrada/salida
y necesita un mantenimiento extra.
Como último método, tenemos el uso de archivos de log. Mediante su análisis podemos extraer
el conocimiento acerca de qué campos son los que se han actualizado. Se registran imágenes de
la base de datos antes y después del cambio. Sin embargo, necesita el uso de checkpoints del
sistema. Pese a todo, es un método muy común para identificar los cambios a refrescar.
Con lo expuesto, podríamos preguntarnos acerca de cuál es el método a elegir. Para respon-
derla deberemos: analizar cada método de forma individual, considerar una solución híbrida si
un solo método no es adecuado y considerar elementos como aplicaciones actuales, bases de
datos operacionales disponibles y tecnología actual disponible. Por otro lado, la aplicación de
los cambios se puede consultar las políticas de modelado esbozadas por Kimball en lo referente
a dimensiones y hechos que cambian lenta o rápidamente.
Técnicas de transporte
En cuanto a las técnicas de transporte, estas dependen de: herramientas, utilidades y lenguajes
de cuarta generación (4GL), gateways, programas de copias personalizados. Pueden utilizarse
también réplicas, servidores FTP (File Transfer Protocol ) o realizarse de forma totalmente
manual. Para aplicar realizar el refresco se debe tener en cuenta que: las herramientas adecuadas
tienden a ser muy caras, las utilidades son rápidas y potentes y los gateways no son siempre los
más rápidos. Estos últimos se emplean para acceder a otras bases de datos, proporcionar data
marts, soportar entornos distribuidos y proporcionar acceso en tiempo real si fuera necesario.
Figura 4.18.: Método para la gestión de restricciones en la generación de índices
Pese a todo, independientemente de la alternativa elegida, suele necesitarse un tratamiento

posterior a la carga (una fase de posprocesado).
Índices
En cuanto a la definición de índices en el almacén de datos durante el proceso de carga, si
se calculan antes de la carga, es más rápido que si se hace durante o después de ésta, pues se
debe añadir un tiempo adicional a la ventana de carga. Para generar índices únicos se deben
gestionar las restricciones de integridad del almacén de datos como muestra la fig. 4.18, esto es,
deshabilitarlas antes de la carga del almacén de datos y volverlas a activar antes de la creación
de índices.
Datos derivados y agregados

Durante la carga, es momento de generar las claves derivadas para el almacén de datos. Usar
tal tipo de claves (que se derivan de las de la fuente de datos), se mantiene la unicidad de
la fila, aunque se necesita una política y proceso administrativo para asignar las claves. Para
ello, se puede concatenar las claves operacionales con un cierto número. Este método es fácil
de mantener y las claves generadas mantienen un tamaño manejable. Sin embargo, el método
más adecuado es el de las claves sustitutas, donde la clave de origen simplemente se traduce a
la correspondiente clave de destino en el almacén de datos tomada de un cierto dominio (por
ejemplo, el de los números naturales). Debe atenderse en este caso a que no tengan un significado
concreto salvo el de identificar unívocamente cada fila de datos. Por otro lado, las operaciones
de extracción deberán referirse a las tablas operacionales para asignar las claves sustitutas.
Respecto a la carga de datos agregados, solo hacer notar que durante la carga también deberán
tenerse en cuenta tales elementos. Por ello, se puede necesitar tanto crear las tablas agregadas
correspondientes como cargar los data marts desde el almacén de datos.
Integridad y disponibilidad
Con todo ello, solo resta verificar la integridad de los datos ya cargados. Para esta tarea se
pueden cargar los datos en un fichero o tabla intermedia y comprobar los totales en el almacén de
datos con totales antes de la carga. Algunas otras tareas de verificación son: evaluar el estado de
la carga consultando el fichero de log, evaluar si el proceso ha finalizado correctamente, todos los
datos han sido cargados o lanzar el proceso ETL de nuevo en caso de que hubiese habido algún
4.5. Elementos principales de diseño 65
problema. Otras tareas asociadas son la actualización de los metadatos tanto de los procesos
ETL como de las herramientas de consulta, la publicación de los nuevos datos (en función de
su disponibilidad, de las vistas del negocio y de los propios cambios) y considerar aspectos de
seguridad para los accesos no deseados.
Para que los datos estén disponibles, a veces se requiere de hasta 24 horas para realizar todo
el proceso de carga. Por ello, se debe llegar a un compromiso entre el tiempo de carga y el
acceso por usuarios finales. Las soluciones a este compromiso pasan por considerar copias de las
actualizaciones, tablas temporales o utilizar tablas separadas para reconciliar ambos tiempos.
Dado que los procesos ETL pueden ser realmente complejos como se ha tratado de exponer con
toda la problemática tratada en este capítulo, cualquier tipo de automatización al respecto será
bienvenida. Las tareas a automatizar serán: las propias actividades de extracción, transformación
y carga, el procesamiento posterior a la carga, la actualización de los metadatos y la publicación
de los cambios después del proceso. Sin embargo, siempre puede ser necesaria la intervención
humana para tratar las cuestiones imprevistas.
4.5. Elementos principales de diseño

A modo de resumen, comentaremos los elementos principales en el diseño de cada una de las
fases estudiadas.
Para el diseño de los procesos de extracción se deben analizar las fuentes y tecnologías de
origen y los tipos de datos, su calidad y propietarios. Como opciones de diseño tenemos la
gestión manual, personalizada, gateways y de terceros o la réplica ya sea total o parcial. Como
elementos de diseño tendremos los volúmenes de datos, actualizados y copias y la automatización
en función de la tecnología disponible.
Para el diseño de los procesos de transformación deberemos analizar las traducciones invo-
lucradas entre fuentes de datos y destino (el almacén de datos), las reglas de negocio, la gra-
nularidad de los datos, las claves o los metadatos, entre otros. Con ello, las opciones de diseño
se centran en seleccionar el lenguaje de codificación (por ejemplo, PL/SQL), el replicado de
los datos, los clientes y terceros. Los elementos a diseñar serán el rendimiento, el tamaño del
preprocesado y el manejo de restricciones de integridad y excepciones.
Para el diseño de los procesos de carga, el análisis se centrará en los volúmenes de datos a
cargar y sus actualizaciones y la distribución en data marts de la arquitectura de almacenes de
datos. Para las las opciones de diseño tendremos la especificación de réplicas, la personalización,
el lenguaje de programación y las herramientas externas. En cuanto a los elementos a diseñar,
estarán los períodos permitidos de carga (las ventanas de carga), el particionamiento de los
datos y su distribución.
Como ejemplo de una solución comercial a lo expuesto en este capítulo, tenemos la plataforma
Oracle. En ella, el proceso de extracción se realiza mediante SQL*Loader desde ficheros planos
y bases de datos a tablas intermedias (la denominada staging area). Mediante el entorno de
diseño visual proporcionado por Oracle (OWB, Oracle Warehouse Builder ), este código se genera
de forma automática mediante modelos visuales sin necesidad de codificar explícitamente las
instrucciones de carga. La fase de transformación se realiza mediante el modelado de los flujos
de datos y los operadores de transformación involucrados que son luego traducidos por OWB a
código PL/SQL de Oracle, mientras que la fase de carga final se realiza de igual forma atendiendo
al tipo de política de actualización seguida (por ejemplo, insertando siempre los nuevos datos,
no cargando los datos en caso de que ya existiera un registro en el destino, etc.).

Procesos ETL1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Procesos ETL1

Cargado por

Copyright:

Formatos disponibles

No veo lógico rechazar datos porque parezcan

4.5. Elementos principales de diseño . . . . . . . . . . . . . . . . . . . . . 65

Un almacén de datos es una colección de datos orientados por temas, integrados,

de donde podemos destacar la cualidad de integrar múltiples fuentes de datos.

Figura 4.1.: Importancia de los procesos ETL

La integración de estas fuentes de datos se realiza mediante los denominados procesos de

Deﬁnir el nivel de calidad óptimo de los datos.

Considerar la modiﬁcación de las reglas de las fuentes de datos operacionales.

Documentar las fuentes de datos como paso básico para comprenderlas.

Diseñar los procesos de limpieza (y sus tareas) de forma muy cuidadosa.

4.2. Fase de extracción

Figura 4.2.: Fuentes de datos de producción

Figura 4.3.: Archivos planos de datos

Fuentes internas y externas

Figura 4.4.: Datos internos según el sistema de origen

4.3. Fase de transformación

Figura 4.5.: Anomalías en las fuentes de datos

A continuación se explicarán los operadores o transformaciones comunes que se pueden em-

Figura 4.7.: Claves compuestas

Figura 4.8.: Claves compuestas y generación de claves simples

Figura 4.9.: Generación de claves a partir de claves compuestas con errores

Figura 4.10.: Operador de conversión

Figura 4.11.: Operador de conversión (2)

Figura 4.12.: Operador de unión

Figura 4.13.: Operador de fusión

4.4. Fase de carga

Para construir el proceso de transporte, se deberán especiﬁcar: las técnicas y herramientas

Figura 4.14.: Ventana de carga de un proceso ETL

Figura 4.15.: Ejemplo de carga (1)

necesitar menor detalle.

Plani cación de la carga

Figura 4.16.: Ejemplo de carga (2)

Figura 4.17.: Ejemplo de carga (3)

Figura 4.18.: Método para la gestión de restricciones en la generación de índices

Pese a todo, independientemente de la alternativa elegida, suele necesitarse un tratamiento

Datos derivados y agregados

4.5. Elementos principales de diseño

También podría gustarte