Vamos a recuperar la faceta didáctica que tenemos un poco olvidada últimamente antes de regresar a la serie que estábamos haciendo. Volvamos a serlo. Vamos a plantearnos un problema y a intentar dar respuesta a alguna de las preguntas que se nos plantean.
El contexto
Consideremos la siguiente situación.
Los sistemas de gestión de la información de nuestra empresa han quedado obsoletos. En nuestra organización existe un antiguo sistema PDM que ya no responde a las necesidades actuales y que su customización para adecuarlo presenta un coste superior a la implantación de un nuevo sistema. El nuevo sistema PLM y el antiguo PDM difieren en la forma en la que guardan los datos y por lo tanto, los datos se deberan tratar para poder ser usados en el nuevo sistema. A parte, existen datos corruptos, incoherentes y repetidos en la antigua base de datos.
Y, claro, el director de sistemas nos asigna la tarea de preparar una nueva base de datos: la migración de los datos. Bien, el reto es importante y a nivel teórico se puede enfocar la realización del mismo de diversas maneras.
Por ejemplo, se puede realizar la migración mendiante scripts de sql que aproveche las características esenciales de la bases de datos que usa la organización. Pero también, podría usarse cualquier lenguaje como java o c++ (o otros). Vamos a encarar el problema como excusa para usar una herramienta ETL.
¿Qué es ETL?
Como ya presentamos hace tiempo en un post anterior, ETL significa Extract, Transform and Load. Este acrónimo hace referencia a herramientas que permiten la extracción de datos de diferentes fuentes (bases de datos, ficheros,…), su transformación (unificación, gestionar la duplicación y la corrupción, asegurar la calidad,…) y su posterior carga en datawarehouse (o en otra base de datos).
¿Qué estas haciendo?
Entonces la pregunta que nos hacemos podría conviertirse en ¿por qué elegir una herramienta ETL? ¿Por qué plantearse la migración como un proceso ETL? Para responderla es mejor centrarse de nuevo en qué puede derivar un proceso de ETL:
- Implica una gran cantidad de trabajo de análisis, diseño e implementación.
- Implica mucho trabajo a nivel de programación.
- Los errores pueden derivarse en paralizar áreas de negocio.
Y también en las necesidades de la organización:
- Que el proceso sea trasparente para la organización.
- Que el proceso esté encarado a las necesidades de negocio.
- Obtener best practices en el proceso.
- Fácil de reutilizar
- Obtención de ROI (Return on Investment)
Por lo tanto, sería bueno centrarse en lo que queremos hacer y no en cómo lo queremos hacer a través de una herramientas que permita la ejecución de las tareas directamente desde el modelo, que sea sencilla de usar, ejecutar, mantener y reusar. Fácil de decir, sumamente complicado de ejecutar.
¿Qué herramienta vamos a escoger? La respuesta en un par de días.
Una respuesta a «Una cuestión didáctica (1 de 2)»