Biblioteca Online : ¡La Suscripción ENI por 9,90 € el primer mes!, con el código PRIMER9. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. Scripting Python en Linux
  3. Manipulación de datos
Extrait - Scripting Python en Linux Desarrolle sus herramientas de sistema
Extractos del libro
Scripting Python en Linux Desarrolle sus herramientas de sistema Volver a la página de compra del libro

Manipulación de datos

Introducción

Este capítulo no fue realmente planeado al principio. Fue solo durante la escritura, cuando un lenguaje como Python me pareció útil para hacer este tipo de cosas. Se dedica, como sugiere su título, a la manipulación de datos de un formato a otro o de una base de datos a otra.

Muy a menudo es necesario leer datos en algún lugar, para transmitirlos en otro formato reconocido por los usuarios y/o los desarrolladores. Y cuando las herramientas originales no lo permiten, Python llena ese vacío.

Nota del autor: “En el último siglo, he desarrollado muchos scripts para transformar archivos EBCDIC a ASCII, verificando archivos generados por ’MainFrames’ usando lenguaje COBOL o esos viejos archivos interbancarios. Hoy en día, es de JSON a CSV, de XML a HTML o de PostGreSQL a base Oracle. "

SQLite en memoria

SQLite es una base de datos pequeña, pero tiene todo lo de una grande. Por lo tanto, siempre que no necesite administrar el acceso simultáneo, esta pequeña base de datos puede proporcionar muchos servicios.

En primer lugar, está integrada en Python, lo que facilita las cosas. Pero además, no hay nada que instalar, simplemente cree el archivo de la base de datos, y este archivo puede muy bien almacenarse en la memoria. Además, es suficiente con abrir la base de datos con el nombre ": memory:" para no necesitar más archivos en el disco.

Esto supone que tiene poca memoria RAM si debe procesar grandes volúmenes de datos, pero puede ser muy útil cuando, por ejemplo, quiere traducir datos de un formato a otro.

El origen de este ejemplo tiene su origen en el entorno profesional del autor, donde se extrajo información de una herramienta: JIRA Service Desk (que se utiliza para gestionar el soporte a cliente), para formatearla en un formato aceptable para los compañeros de oficina: el formato CSV.

JIRA Service Desk es una herramienta de pago y es difícil encontrar un acceso a una base de datos de prueba, si es que existe. Entonces, después de investigar un poco, para ilustrar este capítulo, se decidió transformar los datos JSON a formato CSV, a través de una base de datos SQLite en memoria.

Esto es casi el mismo principio que el origen de este ejemplo.

1. La misión

El origen de los datos es una base de datos legible por todos: https://es.openfoodfacts.org/

Es una base de datos colaborativa y contiene 652.046 productos en el momento de escribir este libro.

Nuestra misión, si decide aceptarlo, es encontrar productos españoles que contengan un ingrediente específico y proporcionarnos información sobre esos productos.

El ingrediente es la taurina, un ingrediente muy conocido por su presencia en algunas bebidas y queremos información como:

  • El código EAN del producto

  • Su nombre

  • La cantidad de venta

  • La marca

  • El código nutricional

  • El nombre genérico

Esta información debe estar en formato CSV en dos archivos separados PRO-DUCTOS.csv y MARCAS.csv. El primero contendrá el detalle de los productos encontrados, mientras que el segundo ejecutará un conteo de productos por marca.

2. La recuperación de los datos

En el sitio web aparece: "Open Food Facts...

SMS a HTML (u otro)

Si hay un área en la que las cosas han evolucionado demasiado rápido, es la telefonía móvil (el término smartphone también es apreciable).

Estas pequeñas máquinas, llamadas "teléfonos inteligentes", contienen una gran cantidad de datos, esencialmente personales. Entre estos datos se encuentran los SMS (Short Message Service o Servicio de mensajes cortos).

Estos SMS contienen mucha información y en ocasiones, puede resultar interesante extraerlos para ordenarlos y convertirlos a un formato más conveniente, desde el punto de vista informático.

Tenga en cuenta que esto solo afecta a los SMS y no a los MMs (Multimedia Messaging Service o Servicio de mensajería multimedia), que aparentemente son administrados de manera diferente por el teléfono y/o el operador.

El objetivo de esta sección es describir un método que funciona principalmente con teléfonos inteligentes Android, pero probablemente también sea aplicable a otros tipos de teléfonos inteligentes.

Este método se basa en tres etapas:

  • Etapa 1: extracción de los SMS del aparato

  • Etapa 2: transformación de estos SMS

  • Etapa 3: conversión

1. Extracción de los SMS

Por una vez, utilizamos una herramienta muy práctica para hacer una copia de seguridad de ciertos datos en el teléfono: la aplicación ’SuperBackup’, que se puede encontrar en Google Store.

Esto le permite simplemente hacer una copia de seguridad de los SMS en la nube (Google Drive) o enviar el archivo generado por correo electrónico.

2. Transformación de los SMS

El archivo generado está en formato XML:

<?xml version="1.0" encoding="UTF-8"?>  
<allsms count="3507">  
   <sms address="+3355512345" time="11 enero 2020 08:57:12"  
date="1578729432385" type="2" body="Ok" read="1" service_center= 
"" name="DARK VADOR" />  
...  
<allsms> 

y se estructura como sigue:

<allsms count=“Nombre de sms en el archivo">  
<sms address = "" time = "" date = "" type = "" body ="" read = 
"" service_center = "" name = "" />  ...

De una base de datos a otra

La ventaja de un lenguaje como SQL es que es bastante estándar. Es muy posible generar código SQL y usarlo para transferir datos de una base de datos a otra.

Si las bases de datos son del mismo fabricante, esto no es un problema. Pero cuando se trata de diferentes bases de datos, no es lo mismo. Y aquí es donde un lenguaje como Python puede resultar muy útil.

De hecho, ¿por qué no utilizar la capacidad de Python para conectarse a diferentes bases de datos, para transferir datos directamente de una base de datos a otra?

A continuación se muestra un ejemplo que ilustra este principio. Sin embargo, es necesario describir un poco el contexto y los actores de este episodio.

1. El contexto

Por un lado, un software de gestión de incidencias (JIRA Service Desk), donde se pueden encontrar detalles del tiempo dedicado por los empleados a los tickets de los clientes.

Por otro lado, un ERP de gestión bajo Oracle, que conoce muy pocos formatos de importación y utiliza un lenguaje específico desarrollado por el fabricante, un lenguaje fuertemente orientado a la informática de gestión, pero muy poco abierto al mundo y menos aún a las bases de datos gratuitas.

Resultado: los desarrolladores solo pueden usar la técnica ancestral de generar archivos ASCII para exportar y luego importar datos. Al menos, esto tiene el mérito de funcionar sin sorpresas, pero ahora que conocemos Python puede haber otra solución más sutil, de la que se presenta a continuación su principio básico.

Por un lado, tenemos una tabla en PostgreSQL y nos gustaría hacer una copia periódica de la misma, en la base de datos de Oracle. El objetivo es que los desarrolladores puedan realizar actualizaciones sobre otras tablas de la gestión de la empresa.

Solo estamos leyendo la base de datos PostgreSQL, así que no se preocupe. Por otro lado, para la base de datos Oracle, será necesario pasar por una tabla intermedia dedicada, con un usuario dedicado (o esquema dedicado), accesible por los desarrolladores.

2. Los esquemas

Primera cosa que hay que hacer: sincronizar los esquemas de un lado y de otro.

 

POSTGRESQL

ORACLE

Columna

Tipo

Tipo

id

numeric(18,0)

number(18,0)

issueid

numeric(18,0)

number(18,0)

author

character varying(255)

varchar2(255)

grouplevel

character varying(255)

varchar2(255)

rolelevel

numeric(18,0)...

Resumen

La manipulación de datos se está convirtiendo cada vez más en una necesidad en la actualidad. Durante años, nuestros servidores han almacenado y archivado grandes volúmenes de datos, que a menudo no se utilizaban. Es un gran clásico de la informática de gestión. Con demasiada frecuencia, los datos se dejan en la herramienta principal, cuando es obvio que es caro no archivarlos correctamente.

Mucha gente ha sido engañada por el gran volumen de datos. Al principio, las tablas son solo unos pocos miles de registros, luego unos cientos de miles y después de unos años, millones de filas. Y ahí, debemos pensar en los procesos de manera diferente.

En promedio, una empresa mantiene un ERP durante siete años y a veces, entre la toma de decisiones y la puesta en marcha, lleva de uno a tres años migrar de una versión a otra o de un ERP a otro. Y durante ese tiempo, los datos continúan creciendo.

Hace algún tiempo, las herramientas de “business intelligence” eran muy caras y solo podían justificarse en una estructura empresarial grande. Bien utilizadas, permiten sintetizar o agregar determinados datos, mediante la creación de un almacén de datos.

Durante mucho tiempo parecieron herramientas mágicas y, desde cierto punto de vista, es casi cierto. Pero la mejor herramienta del mundo solo puede ofrecer aquello para...