En la nota anterior comparamos Texto en columnas de Excel Clásico con Dividir Columna de Power Query para mostrar cuanto más eficiente es esta última herramienta.
En esta nota voy a mostrar una situación imposible de resolver cob Texto en Columnas y que Power Query lo hace con facilidad.
Consideremos esta tabla de clientes agrupados por vendedores
En otra tabla tenemos las ventas a cada cliente. Ahora supongamos que se nos pide calcular las comisiones de cada vendedor para lo cual tenemos que totalizar las ventas por vendedor. Obviamente los datos están organizados de manera tal que no podemos realizar la tarea. Necesitamos "aplanar" la tabla de tal manera que en cada fila haya una celda con el nombre del vendedor y la la celda contigua el nombre del cliente. De esa manera podremos usar Combinar consultas del Power Query para calcular las ventas por vendedor (o, si prefieran y espero que no lo prefieran, usar BUSCARV para extraer las ventas en cada fila y luego resumirlas con una tabla dinámica o SUMAR.SI).
Vamos a mostrar como hacerlo con Power Query es cuestión de segundos.
Una tarea frecuente cuando de transformar datos se trata es dividir una columna en varias. Desde sus primeras versiones Excel cuenta con una herramienta para dividir columnas: Texto en Columnas, denominación que nunca logré entender; "Dividir columna" (Split column) me parece más apropiado.
Pero no es éste el tema del post. Vamos a mostrar por que Dividir columna del Power Query es superior a Texto en Columnas del Excel clásico.
Veamos el siguiente caso. Hemos recibido una lista de clientes con una única columna que incluye el nombre del cliente, la dirección y la ciudad.
Nuestra tarea es extraer al ciudad de cada línea. Aparentemente Texto en columnas lo puede hacer con facilidad usando la coma como separador de los campos. Pero si nos fijamos con atención veremos que la fila 2 aparecen dos comas, una separa el nombre de la dirección y la otra la dirección de la ciudad, pero en la fila 3 hay tres comas (una precede el numero 23, la otra inmediatamente después del número).
Si usamos Texto en columnas obtendríamos ésto:
En algunos casos la ciudad aparece en la columna C y en otros en la columna D. Remediar esta situación en la hoja de Excel sería extenuante (supongamos una lista de cientos o tal vez miles de clientes).
Si usamos Power Query la tarea se convierte en "coser y cantar". Como siempre, empezamos por crear una conexión a la tabla
En el menú Inicio-Transformar abrimos las opciones de Dividir Columna-por delimitador
En el diálogo que se abre
Elegimos la opción Delimitador situado más a la derecha y apretamos Aceptar y ....
El nombre de la nueva columna lo establece Power Query. Podemos cambiarlo haciendo un doble clic sobre el encabezamiento o usando el menú contextual Cambiar nombre. También podemos editar el código del paso aplicado usando la barra de fórmulas
cambiando "Clientes.2" por el nombre deseado (digamos, Ciudad). Sencillamente lo editamos en la barra y apretamos Enter.
Ahora tenemos que separar el nombre del cliente de la dirección. Como ya habrán supuesto, usamos la opción Delimitador situado más a la izquierda.
En la nota anterior sobre el tema mostramos como comparar tablas con Power Query para encontrar, por ejemplo, diferencias entre ambas tablas. Por ejemplo, podemos comparar dos listas de nombres para controlar que nombres de las lista1 no aparecen en la lista2 o viceversa.
Todas las tareas las hicimos usando la interfaz del usuario. Es decir, sin necesidad de escribir o modificar ninguna línea de código para obtener el resultado. Sin embargo con cada paso que aplicamos, y que vemos reflejado en el panel de "Pasos Aplicados", Power Query está escribiendo líneas de código en su lenguaje, conocido como el lenguaje "M".
Voy a aprovechar esta nota para mostrar como podría comparar dos listas un usuario con ciertos conocimientos del lenguaje. Para lo cual voy a dedicar algunas líneas al lenguaje M.
El lenguaje M comprende objetos y funciones. Entre los objetos voy a mencionar las Tablas y las Listas. La diferencia entre una tabla y una lista, dicho en forma general, es que la lista siempre tendrá una sola columna. Así, por ejemplo, podemos tomar una columna de una tabla y convertirla en Lista y, a su vez, podemos convertir una lista en Tabla.
El motivo para estas transformaciones es que cada objeto, Listas y Tablas en nuestro caso, tiene su propia colección de funciones.
Power Query no tiene incorporado un asistente de funciones de manera que para consultar qué funciones existen tenemos que abrir está página (por ahora no se ha publicado una versión en castellano).
En nuestro ejemplo vamos a usar la función List.Difference. Las funciones están organizadas por categorías; la nuestra se encuentra en la categoría List Functions
Como vemos la función utiliza dos variables, las listas a comparar, y una tercera opcional que ignoraremos en esta nota.
"List" que antecede al nombre de la función nos indica que se trata de una que actúa sobre Listas. Esto quiere decir que para usarla tendremos que convertir, previamente, las columnas de nuestras tablas a listas.
Para evitar un tsunami de palabras en un largo post, voy a mostrar y explicar el proceso con este video
Ahora bien, si podemos hacer la comparación usando la interfaz de usuario, ¿por qué hacerlo escribiendo código?
La interfaz de usuario de Power Query es muy poderosa; nos permitirá resolver algo así como el 40% de nuestras necesidades de transformación de datos. Pero no todos los casos se pueden resolver sin escribir código o de la manera más eficiente.
Según Gil Raviv estas son las etapas del aprendizaje de Power Query y el lenguaje M
Solo interfaz - nos permite solucionar aproximadamente el 40% de los problemas.
Edición básica en la barra de fórmulas - Si bien no tenemos sólidos conocimientos de M y las funciones, si podemos asociar elementos en las fórmulas con las pasos dados con la interfaz y lograr ciertas transformaciones. En esta etapa ya podemos resolver el 60% de los problemas.
M en columnas personalizadas - En esta etapa dominamos el uso de columnas personalizadas y podemos crear fórmulas efectivas; dominamos el uso de condicionales y los operadores Booleanos. En esta etapa ya nos enfrentamos con éxito al 80% de los problemas.
Funciones personalizadas - En esta etapa ya dominamos el uso de funciones personalizadas lo que nos permite reusar transformaciones que hemos creado. Ahora ya podemos resolver el 95% de los problemas.
Iteraciones avanzadas - En esta etapa ya sabemos enfrentarnos a escenarios complejos y es cuando empezamos a usar funciones como List.Accumulate y List.Generate para crear iteraciones de transformaciones. Ya sabemos resolver el 99% de los desafíos que nos presenten; el 1% restante pueden ser resueltos usando otras herramientas.
Gil describe una sexta etapa sobre la cual no me voy a extender ya que está reservada a los super-humanos (o Cyborgs o seres de otras galaxias).
Para los simples mortales un buen punto de comienzo es el curso de Ivan Pinar Dominguez
