En esta sección, describimos los tipos esenciales de estructuras de datos que probablemente necesitarás en tu sistema ETL.
Archivos Planos
En muchos casos, no necesitarás alojar tus datos dentro de los límites de un DBMS. Si no estás utilizando una herramienta ETL dedicada y estás realizando todas las tareas ETL con SQL en tu base de datos, necesitas crear estructuras de tabla DBMS para almacenar todos tus datos en etapa de preparación. Sin embargo, si cuentas con una herramienta ETL o estás utilizando scripts de shell o programas de scripting como Perl, VBScript o JavaScript, que pueden manipular archivos de texto, puedes almacenar datos en etapa de preparación directamente en tu sistema de archivos como archivos de texto simples.
Cuando los datos se almacenan en columnas y filas dentro de un archivo en tu sistema de archivos para emular una tabla de base de datos, se le conoce como un archivo plano o secuencial. Si tu sistema operativo es cualquier versión de UNIX o Windows, los datos en tus archivos planos están en un código de caracteres estandarizado conocido como Código Estándar Americano para el Intercambio de Información (ASCII). ¡Los archivos planos ASCII pueden ser procesados y manipulados por herramientas ETL o lenguajes de scripting como si fueran tablas de base de datos, y en ciertos casos mucho más rápido!
Un DBMS requiere sobrecarga para mantener metadatos sobre los datos que se están procesando, lo cual en casos simples no es realmente necesario en el entorno de preparación de datos. Ha sido la sabiduría convencional que ordenar, fusionar, eliminar, reemplazar y muchas otras funciones de migración de datos son mucho más rápidas cuando se realizan fuera del DBMS. Existen muchos programas de utilidad dedicados a la manipulación de archivos de texto. Ten en cuenta al realizar manipulaciones de archivos planos con lenguajes de scripting que puedes tener la obligación de informar por separado a tus tablas de seguimiento de metadatos sobre las transformaciones que estás realizando. Si el seguimiento de metadatos (digamos, para fines de cumplimiento) es tan importante como las propias transformaciones, deberías pensar en manejar estas operaciones a través de una herramienta ETL dedicada que pueda proporcionar automáticamente el contexto de metadatos.
La plataforma exacta para almacenar tus tablas de preparación de datos depende de muchas variables, incluyendo estándares y prácticas corporativas. Sin embargo, hemos observado que es más práctico usar archivos planos en lugar de tablas de base de datos para partes del proceso ETL cuando el propósito fundamental del proceso es uno de los siguientes:
Almacenamiento de Datos Fuente
Cuando extraes datos de su fuente original, debes entrar rápidamente al sistema, seleccionar exactamente lo que necesitas y salir. Si el proceso ETL falla después de que los datos son extraídos, debes poder empezar sin penetrar de nuevo en el sistema fuente. El mejor enfoque para reiniciar un proceso fallido sin penetrar constantemente el sistema fuente es volcar los datos extraídos en un archivo plano para su resguardo. Si el proceso falla en cualquier punto después de que los datos han sido colocados en el archivo plano, el proceso puede reiniciar fácilmente recogiendo los datos ya extraídos del archivo plano en el área de preparación.
Ordenamiento de Datos
Ordenar es un prerrequisito para prácticamente cada tarea de integración de datos. Ya sea que estés agregando, validando o realizando búsquedas, preordenar datos optimiza el rendimiento. Ordenar datos en el sistema de archivos puede ser más eficiente que seleccionar datos de una tabla de base de datos con una cláusula ORDER BY. Dado que la naturaleza del ETL es integrar datos dispares, fusionar datos eficientemente es una prioridad principal que requiere ordenamiento intensivo. Una gran fracción de los ciclos de procesador de tu sistema ETL se destinarán a ordenar.
Filtrado
Supongamos que necesitas filtrar un atributo que no está indexado en la base de datos fuente. En lugar de forzar al sistema fuente a crear índices que pueden obstaculizar el procesamiento de transacciones, podría ser más rápido extraer todo el conjunto de datos en un archivo plano y grep (un comando UNIX para filtrar archivos de datos simples) solo las filas que cumplan con tus requisitos. Otro beneficio de tener la capacidad de filtrar datos sin usar una base de datos se realiza cuando los datos no provienen de una base de datos sino de archivos de datos. Un ejemplo común de esto son los registros web. Al procesar datos de clickstream, usamos una declaración grep con el interruptor -v para seleccionar todas las filas que no contienen ciertos valores como .gif o .jpg, por lo que los hits que están sirviendo archivos de imagen se excluyen del almacén de datos. Filtrar archivos planos es tremendamente más eficiente que insertar todos los datos en una tabla de base de datos, indexar la tabla y luego aplicar una cláusula WHERE para eliminar o seleccionar los datos en otra tabla.
Reemplazo/Sustitución de Cadenas de Texto
El sistema operativo puede recorrer rápidamente un archivo de texto, traduciendo cualquier cadena a cualquier otra cadena de forma sorprendentemente rápida usando el comando tr. Realizar búsquedas de subcadenas y reemplazar datos en una base de datos puede requerir funciones escalares anidadas y sentencias de actualización. Este tipo de procesamiento de archivos secuenciales es mucho más rápido a nivel de sistema de archivos que con una base de datos.
Agregación
La agregación debe ser soportada de dos maneras: en el flujo de datos ETL regular antes de cargar en una base de datos y en la base de datos misma cuando se agregan datos que solo pueden ser solicitados con filtrado de base de datos. Fuera de la base de datos, tiene más sentido usar un paquete de ordenamiento dedicado. Dentro de la base de datos, casi siempre tiene más sentido quedarse con la capacidad de ordenamiento de la base de datos, aunque ocasionalmente puede ser útil volcar grandes volúmenes de datos fuera de la base de datos y usar el paquete de ordenamiento.
Referenciación de Datos Fuente
En sistemas de transacciones normalizadas, es común tener una única tabla de referencia que soporte muchas otras tablas. Una tabla de Estado genérica, por ejemplo, puede soportar estados de pedidos, estados de envío y estados de pago. En lugar de consultar la misma tabla en el sistema fuente una y otra vez, es más eficiente extraer la tabla de referencia y alojarla en el área de preparación una vez. Desde allí, puedes buscar datos con tu herramienta ETL. La mayoría de las herramientas ETL pueden leer una tabla de búsqueda en memoria y almacenarla allí durante la vida del proceso. Acceder a tablas de referencia almacenadas en memoria es extremadamente rápido. Además, utilizar datos de referencia en etapa de preparación mantiene las consultas que golpean el sistema fuente más simples y eficientes, ya que se pueden omitir muchas de las uniones de tablas.
Conjuntos de Datos XML
XML es un lenguaje para la comunicación de datos. Superficialmente, XML toma la forma de documentos de texto plano que contienen tanto datos como metadatos, pero no información de formato. XML se expresa con una notación muy similar a HTML pero se aparta de la arquitectura de un documento HTML. En contraste, HTML contiene datos e información de formato, pero no metadatos.
Las diferencias entre XML y HTML son cruciales para entender cómo XML afecta a los almacenes de datos. Los metadatos de XML consisten en etiquetas que identifican de manera inequívoca cada ítem en un documento XML. Por ejemplo, una factura codificada en XML contiene secuencias como: Aquí, Customer es un elemento XML cuya definición ha sido establecida entre las partes emisora y receptora antes de que se transmita la factura. El elemento customer ha sido definido para contener varios atributos XML, incluyendo nombre, dirección, ciudad y posiblemente otros.
XML tiene una extensa capacidad para declarar estructuras jerárquicas, como formularios complejos con subcampos anidados repetitivos. Estas estructuras jerárquicas no se mapean directamente en tablas relacionales bidimensionales estándar con filas y columnas. Cuando el almacén de datos recibe un conjunto de datos XML, puede haber un proceso de extracción complejo para transferir permanentemente los datos a un almacén de datos relacional. Ha habido cierta discusión sobre extender las bases de datos relacionales para proporcionar soporte nativo para las estructuras jerárquicas de XML, pero esto supondría una extensión sustancial de la sintaxis y semántica de las bases de datos relacionales basadas en SQL, lo cual hasta el momento de escribir esto, no ha ocurrido.
Dejando de lado los problemas de estructuras jerárquicas complejas, XML es hoy en día un medio extremadamente efectivo para mover datos entre sistemas de otro modo incompatibles, ya que XML (y los Esquemas XML que le siguen) proporcionan suficiente información para realizar una declaración completa de CREATE TABLE en una base de datos relacional y luego poblar esta tabla con datos con los tipos de columna correctos. XML define un lenguaje universal para compartir datos. Esa es su fortaleza. La desventaja de XML para la transferencia de datos de gran volumen es la sobrecarga de la propia estructura del documento XML. Si estás transmitiendo millones de registros similares y predecibles, deberías buscar una estructura de archivos más eficiente que XML para la transferencia de datos.
DTDs, Esquemas XML y XSLT
En XML, la forma estándar para que dos partes definan un conjunto de posibles etiquetas es intercambiando un documento especial conocido como Definición de Tipo de Documento (DTD). La declaración DTD para nuestro ejemplo de cliente podría ser expresada como:
<!ELEMENT Customer (Name, Address, City?, State?, Postalcode?)>
<!ELEMENT Name (#PCDATA)>
más líneas similares para Address, City, State y Postalcode. Aquí, los signos de interrogación después de City, State y Postalcode indican que estos campos son opcionales. La declaración #PCDATA indica que Name es una cadena de texto sin formato.
Nótese que el DTD contiene algo menos de información que una declaración SQL CREATE TABLE. En particular, no hay longitud de campo.
Hasta ahora, los DTDs han sido la base para establecer un entendimiento de metadatos entre dos partes que intercambian XML. Varios grupos de la industria han estado definiendo DTDs estándar para sus áreas temáticas. Pero como administradores de almacenes de datos, no obtenemos suficiente de los DTDs para construir una tabla relacional. Para rectificar este problema, la organización de estándares W3C ha definido un sucesor de los DTDs de fuerza industrial conocido como Esquemas XML. Los Esquemas XML contienen mucha más información orientada a la base de datos sobre tipos de datos y cómo se relacionan los elementos XML entre sí, o en otras palabras, cómo se pueden unir las tablas.
Cuando se ha acordado un Esquema XML y se ha recibido contenido XML, el contenido informativo se representa a través de otra especificación llamada Transformaciones de Lenguaje de Hojas de Estilo Extensible (XSLT). En realidad, XSLT es un mecanismo general para traducir un documento XML en otro documento XML, pero su uso más visible es para convertir XML en HTML para la presentación final en pantalla.
Tablas Relacionales
Los datos en etapa de preparación pueden opcionalmente almacenarse dentro de los límites de un DBMS relacional. Utilizar tablas de base de datos es especialmente apropiado cuando no se dispone de una herramienta ETL dedicada. Almacenar tablas de preparación en una base de datos tiene varias ventajas:
- Metadatos Aparentes: Una de las principales desventajas de usar archivos planos es que carecen de metadatos aparentes. Al almacenar datos en una tabla relacional, el DBMS mantiene automáticamente los metadatos técnicos, y los metadatos de negocio pueden adjuntarse fácilmente a la tabla dentro del DBMS. Información como nombres de columnas, tipos y longitudes de datos, y cardinalidad es inherente al sistema de base de datos. Las descripciones de negocios de tablas y columnas son elementos comúnmente añadidos a los catálogos de datos del DBMS.
- Habilidades Relacionales: Hacer cumplir la integridad de datos o referencial entre entidades es fácil de lograr en un entorno relacional. Si estás recibiendo datos de sistemas no relacionales, podría tener sentido preparar los datos en un modelo normalizado antes de transformarlos en un modelo dimensional.
- Repositorio Abierto: Una vez que los datos están en un DBMS, pueden ser fácilmente accesibles (asumiendo que se concede permiso) por cualquier herramienta compatible con SQL. El acceso a los datos es crucial durante las pruebas de aseguramiento de calidad y auditoría.
- Soporte de DBA: En muchos entornos corporativos, el grupo de DBA es responsable solo de los datos dentro del DBMS. Los datos fuera de la base de datos, en el sistema de archivos, usualmente no son supervisados. La asignación de espacio, respaldo y recuperación, archivado y seguridad son tareas que el equipo ETL debe coordinar cuando los datos en preparación no están en un DBMS.
- Interfaz SQL: Encontrarás muchas ocasiones en las que necesitarás escribir SQL para manipular datos y obtener el formato correcto. La mayoría sabe que SQL es el lenguaje estándar para comunicarse con los datos, es fácil de escribir y es poderoso. SQL es probablemente el lenguaje de programación más conocido en el entorno de TI. La mayoría de los sistemas de bases de datos vienen con robustas funciones SQL que ahorran numerosas horas de codificación manual. Oracle, por ejemplo, tiene funciones sobrecargadas como to_char() que pueden tomar prácticamente cualquier tipo de datos y convertirlo en una cadena de caracteres en una variedad de formatos. Además de hacer cumplir la integridad referencial, tener la capacidad de usar SQL nativo es la razón principal para almacenar datos en etapa de preparación en un entorno de base de datos.
Tablas de Trabajo Independientes del DBMS
Si decides almacenar tus datos en etapa de preparación en un DBMS, tienes varias opciones de arquitectura cuando estás modelando el esquema de preparación de datos. Diseñar tablas en el área de preparación puede ser incluso más desafiante que diseñar modelos de transacciones o dimensionales. Recuerda, las bases de datos de transacciones están diseñadas para ingresar datos; los diseños dimensionales para extraer datos. Los diseños del área de preparación deben hacer ambos. Por lo tanto, no es raro ver una mezcla de arquitecturas de datos en el área de preparación.
Para justificar el uso de tablas de preparación independientes, utilizaremos uno de nuestros aforismos favoritos: Manténlo simple. Las tablas independientes reciben su nombre porque no tienen dependencias con otras tablas en la base de datos. En el entorno transaccional, estas tablas son conocidas como huérfanas porque no tienen relaciones con otras tablas en el esquema. Debido a que las tablas independientes no tienen relaciones, son candidatas principales para almacenarse fuera de una base de datos relacional.
La mayoría de las veces, la razón por la que creas una tabla de preparación es para asentar los datos para que puedas manipularlos nuevamente usando SQL o un lenguaje de scripting. En muchos casos, especialmente en proyectos de almacenes de datos más pequeños, las tablas independientes son todo lo que necesitas en el área de preparación.
Solo porque las tablas independientes no están necesariamente normalizadas, no deben ser tratadas como archivos de volcado. Los archivos de volcado se crean típicamente de forma arbitraria sin preocuparse por el espacio en disco o el rendimiento de las consultas. Cada campo de un archivo o tabla independiente debe tener un propósito y una definición lógica. Las columnas superfluas se omiten de cualquier diseño de tabla independiente. Para las tablas de base de datos, se debe establecer e implementar un plan de índices adecuado en todas las tablas independientes.