Archivo de la etiqueta: destacada

Base de Datos, Business Intelligence

Data Warehousing: Kimball vs Inmon, Data Vault y Virtualización

Dos formas completamente diferentes de enfocar el mismo problema. Dos formas no del todo contrapuestas y ambas válidas. Quizá el enfoque departamental de Kimball es un generador de Silos y es quizá por esto que desde la perspectiva del framework de DAMA se habla mucho más de Inmon y de su CIF (Corporate Information Factory)

En el desarrollo conceptual del data warehousing, se destacan dos figuras prominentes: Ralph Kimball y Bill Inmon (que he tenido la suerte de entrevistar hace unas semanas). Aunque ambas perspectivas comparten objetivos similares, difieren considerablemente en sus enfoques metodológicos, dando lugar a dos filosofías distintas en el diseño de estrategias de datos.

La visión de Kimball se fundamenta en la premisa de que los procesos de negocio deben dictar la arquitectura del datawarehouse. Parte de la premisa de la existencia previa de datos, ya sea en forma de datamarts organizados de manera más o menos estructurada, los cuales sirven como la base para la construcción del datawarehouse futuro.

Que sea rápido… y departamentalizado

Para Kimball, la velocidad en el procesamiento de datos destinados a la toma de decisiones es primordial. Por ende, estructura el datawarehouse conforme a patrones dimensionales, con el objetivo de agilizar las consultas y ofrecer una organización más intuitiva y natural de los datos para los usuarios.

La arquitectura propuesta por Kimball se caracteriza por ser una aproximación «bottom-up», donde se parte de los datos y procesos existentes para modelar el datawarehouse de manera que se adapte a ellos. Esta metodología prioriza la eficiencia temporal y la representación intuitiva de los datos sobre la normalización.

Esencialmente el modelo dimensional de Kimball se apoya en el modelo estrella donde las dimensiones no están normalizadas. Si de un lado su construcción resulta más rápida y sencilla puede generar problemas de redundancia.

El esquema en estrella es capaz de filtrar datos a partir de información denormalizada para satisfacer las necesidades de almacenamiento de datos. Se genera una clave única asociada a cada tabla de hechos para identificar cada fila. Este esquema permite realizar cálculos y agregaciones de manera rápida, como el total de ingresos obtenidos y la cantidad total de artículos vendidos al final de cada mes. Estos detalles pueden filtrarse según sea necesario mediante consultas apropiadas. El esquema en estrella se centra en la medición de eventos que incluyen valores numéricos finitos, que se vinculan a claves externas relacionadas con las tablas de dimensiones. Existen varios tipos de tablas de hechos que contienen valores a nivel atómico. Por ejemplo, la tabla de hechos de transacciones almacena datos sobre eventos específicos, como ventas y días festivos, mientras que los hechos de registro incluyen períodos específicos, como información de cuenta al final del año o cada trimestre. Por otro lado, las tablas dimensionales proporcionan datos detallados sobre los atributos o registros que se encuentran en la tabla central.

Que sea conformado y normalizado y a ser posible por entidades primarias

Por otro lado, el enfoque de su colega Inmon, reconocido como el pionero del concepto de data warehouse, presenta una estrategia «top-down» en la resolución del problema. En este enfoque, el primer paso en el desarrollo del datawarehouse consiste en establecer una estructura de datos en tercera forma normal (3FN), completamente normalizada y depurada. Los datos que ingresan a esta estructura suelen ser depurados previamente en un «área de carga» antes de ser integrados en el datawarehouse normalizado. Esto supone otro proceso ETL.

A partir de esta estructura central, se pueden crear datamarts que organicen de manera más lógica y, si se desea, multidimensional, la información contenida en el datawarehouse principal. Esta metodología, como se puede apreciar, es más organizada pero menos flexible que la anterior, ya que aquí es la estructura y la normalización de los datos lo que dicta el proceso de trabajo en lugar de los procesos de negocio existentes.

El enfoque de Inmon se apoya es encialmente en el esquema copo de nieve donde las dimensiones están normalizadas.

El esquema de copo de nieve requiere poco espacio en disco, lo cual es una ventaja significativa. Este modelo no es relativamente fácil de implementar aunque presenta una estructura modular y a las tablas de dimensiones bien definidas. Las tablas de dimensiones suelen contener al menos dos atributos para definir información en múltiples niveles de granularidad. Sin embargo, debido a la presencia de múltiples tablas de dimensiones y relaciones más complejas, el rendimiento del esquema de copo de nieve tiende a ser inferior en comparación con el esquema en estrella. A pesar de esto, el esquema de copo de nieve ofrece el más alto nivel de integridad de datos y baja redundancia gracias a su enfoque en la normalización de datos.

Donde tiramos…

¿Cuál es la preferible? No se puede afirmar que una sea superior a la otra; simplemente, cada una enfatiza diferentes aspectos en el diseño de un datawarehouse. Kimball representa la orientación hacia el usuario final, la flexibilidad y la rápida disponibilidad de la información. Por otro lado, Inmon destaca por su enfoque en el diseño meticuloso y el cumplimiento de normas que aseguren la precisión, integración y coherencia de los datos.

Con el tiempo, los profesionales del data warehousing han aprendido a combinar ambas tendencias en modelos híbridos que incorporan lo mejor de ambas soluciones. Estos modelos suelen cerrar el ciclo de vida de la información mediante procesos ETL (Extract, Transform, Load) y utilizan estructuras dimensionales para representar la información de manera que facilite su explotación.

Las diferencias entre los enfoques de Inmon y Kimball en el desarrollo de un Data Warehouse son notables y van más allá de simplemente variaciones en la estructura interna y el alcance. Estas diferencias afectan también a la intención y el propósito subyacentes de cada modelo.

El enfoque de Inmon se caracteriza por su orientación «top-down», donde se prioriza la construcción de un almacén de datos altamente normalizado y depurado desde el principio. Este enfoque busca asegurar la precisión y coherencia de los datos, estableciendo una sólida base estructural sobre la cual se pueden desarrollar datamarts y otras estructuras de información.

Por otro lado, el enfoque de Kimball es más «bottom-up», centrándose en la rápida disponibilidad de la información para la toma de decisiones. Kimball aboga por estructuras dimensionales que se adapten a las necesidades específicas de los usuarios finales, lo que permite una mayor flexibilidad y agilidad en la explotación de los datos.

En este debate también se encuentra el concepto de Data Vault, que es una metodología de modelado de datos que se ha vuelto popular en los últimos años. El enfoque de Data Vault se centra en la escalabilidad, la flexibilidad y la trazabilidad de los datos. Utiliza una estructura de modelado específica que consiste en hubs, enlaces y satélites, lo que permite una fácil adaptación a los cambios en los requisitos de negocio y una mayor capacidad para rastrear el historial y la procedencia de los datos.

Dicho esto, afirmar que uno de estos enfoques es «correcto» o «incorrecto» sería demasiado simplista. En lugar de eso, es importante comprender las fortalezas y debilidades de cada enfoque y seleccionar el que mejor se ajuste a las necesidades y objetivos específicos de cada proyecto de Data Warehouse. En muchos casos, la combinación de elementos de diferentes enfoques, como lo hacen los modelos híbridos, puede resultar ser la opción más adecuada para obtener los mejores resultados.

El Data Vault

 

El Data Vault es una metodología de modelado de datos diseñada para proporcionar una estructura flexible y escalable en entornos de data warehousing. Se caracteriza por su enfoque en la gestión de datos históricos, la trazabilidad y la capacidad para adaptarse a cambios en los requisitos empresariales. En un modelo de Data Vault, los datos se organizan en tres tipos principales de componentes:

 

Hubs: Representan entidades de negocio fundamentales y actúan como puntos centrales para conectar datos relacionados. Los hubs contienen claves de negocio y son la base para la integración y la trazabilidad de los datos.

 

Enlaces (Links): Establecen las relaciones entre los hubs y representan las asociaciones entre entidades de negocio. Los enlaces contienen claves foráneas que conectan dos o más hubs, permitiendo el modelado de relaciones complejas entre los datos.

 

Satélites: Almacenan atributos descriptivos adicionales relacionados con los hubs y enlaces. Los satélites contienen información detallada sobre los datos, como metadatos, fechas de validez y cualquier otra información contextual relevante.

 

El diseño en forma de Data Vault facilita la escalabilidad y la flexibilidad al permitir la incorporación de nuevos datos y cambios en los requisitos empresariales sin tener que modificar la estructura básica del modelo. Además, su enfoque en la trazabilidad y la gestión de datos históricos lo hace especialmente adecuado para entornos donde es crucial mantener un registro detallado de la evolución de los datos a lo largo del tiempo.

 

El ETL como cuello de botella

 

Cualquier enfoque queramos utilizar siempre nos toparemos con los problemas derivados de los procesos ETL.

 

Minimizar los procesos ETL (Extracción, Transformación y Carga) en datawarehousing puede ser beneficioso para reducir la complejidad y los costos asociados con la gestión de datos. Aquí hay algunas ideas para lograrlo:

 

Incrementar la integración en la fuente: En lugar de extraer datos de múltiples fuentes y luego transformarlos para la carga en el almacén de datos, se puede trabajar en integrar los datos en la misma fuente. Esto implica implementar estándares de integración de datos en las aplicaciones fuente para garantizar la coherencia y la calidad de los datos antes de que se extraigan.

 

Utilizar estructuras de datos flexibles: Emplear modelos de datos flexibles y dinámicos, como el Data Vault, que permiten agregar nuevas fuentes de datos con facilidad y minimizan la necesidad de transformaciones complejas durante el proceso ETL.

 

Automatizar la limpieza y transformación de datos: Utilizar herramientas de calidad de datos y transformación de datos para automatizar tareas como la limpieza, normalización y enriquecimiento de datos. Esto reduce la dependencia de procesos manuales y acelera el flujo de datos a través del proceso ETL.

 

Implementar cambios incrementales: En lugar de realizar extracciones completas de datos cada vez, implementar estrategias de extracción incremental (delta) o de cambio de datos (CDC) para identificar y cargar sólo los datos que han cambiado desde la última ejecución del proceso ETL. Esto reduce la cantidad de datos que se procesan y carga en cada ciclo de ETL.

 

Optimizar el rendimiento de las consultas: Diseñar modelos de datos eficientes y utilizar técnicas de indexación y particionamiento para optimizar el rendimiento de las consultas en el almacén de datos. Esto puede reducir la necesidad de realizar transformaciones complejas durante el proceso de carga.

 

Utilizar herramientas ETL de alto rendimiento: Emplear herramientas ETL de alto rendimiento y escalables que puedan manejar grandes volúmenes de datos de manera eficiente y procesar transformaciones complejas en paralelo para acelerar el proceso ETL.

 

La virtualización: no mover datos más bien consultarlos…

 

La virtualización de datos es una tecnología que puede desempeñar un papel significativo en la reducción o eliminación de los procesos ETL en data warehousing. Al aprovechar la virtualización de datos, las organizaciones pueden acceder y combinar datos de múltiples fuentes en tiempo real, sin necesidad de replicar o mover físicamente los datos a un almacén centralizado. Esto significa que los datos permanecen en su ubicación original y se integran de manera virtual en una capa de abstracción, lo que elimina la necesidad de realizar extracciones y transformaciones complejas.

 

La virtualización de datos permite a los usuarios acceder a los datos de manera transparente y unificada, independientemente de su ubicación física o formato subyacente. Esto significa que los procesos ETL tradicionales, que implican la extracción de datos de múltiples fuentes, su transformación y carga en un almacén de datos centralizado, pueden ser reemplazados por consultas virtuales que acceden y combinan los datos según sea necesario, en tiempo real.

 

Al eliminar la necesidad de replicar y mover grandes volúmenes de datos, la virtualización de datos reduce significativamente la complejidad y el costo asociado con los procesos ETL. Además, al permitir el acceso en tiempo real a los datos, la virtualización de datos puede mejorar la agilidad y la capacidad de respuesta de las organizaciones ante los cambios en los requisitos de negocio y las fuentes de datos. En resumen, la virtualización de datos ofrece una alternativa eficaz para minimizar o incluso eliminar los procesos ETL en datawarehousing, al tiempo que proporciona una integración de datos ágil y flexible.

 

sql

Explorando las Diferentes Tipologías de JOIN en SQL: Ejemplos Prácticos

Cuando se trata de manipular datos en SQL, las sentencias JOIN son una herramienta poderosa para combinar información de múltiples tablas. Sin embargo, entender las diferentes tipologías de JOIN puede ser clave para escribir consultas eficientes. Vamos a explorar algunas de las más comunes con ejemplos prácticos.

  1. INNER JOIN:
    • Este JOIN devuelve solo las filas que tienen coincidencias en ambas tablas.
    SELECT clientes.nombre, pedidos.producto
    FROM clientes
    INNER JOIN pedidos ON clientes.id = pedidos.cliente_id;
  2. LEFT JOIN:
    • Devuelve todas las filas de la tabla izquierda y las coincidencias de la tabla derecha.
    SELECT empleados.nombre, departamentos.nombre
    FROM empleados
    LEFT JOIN departamentos ON empleados.departamento_id = departamentos.id;
  3. RIGHT JOIN:
    • Similar al LEFT JOIN pero devuelve todas las filas de la tabla derecha y las coincidencias de la izquierda.
    SELECT departamentos.nombre, empleados.nombre
    FROM departamentos
    RIGHT JOIN empleados ON departamentos.id = empleados.departamento_id;
  4. FULL OUTER JOIN:
    • Devuelve todas las filas cuando hay una coincidencia en cualquiera de las tablas.
    SELECT clientes.nombre, pedidos.producto
    FROM clientes
    FULL OUTER JOIN pedidos ON clientes.id = pedidos.cliente_id;
  5. SELF JOIN:
    • Se utiliza cuando necesitas combinar una tabla consigo misma. Por ejemplo, para encontrar empleados que tienen el mismo gerente.
    SELECT a.nombre, b.nombre AS gerente
    FROM empleados a
    INNER JOIN empleados b ON a.gerente_id = b.id;

Entender estas tipologías de JOIN y cuándo utilizarlas puede mejorar tus consultas SQL y tu capacidad para extraer información valiosa de tus bases de datos. ¿Has utilizado alguna de estas antes?

Italiano

Esplorando la Tendenza di Rimpatriare Dati dal Cloud: Cause e Riflessioni

Oggi, vorrei immergerci in una tendenza interessante che sta guadagnando popolarità nel mondo della tecnologia: il rimpatrio dei dati e delle applicazioni dal cloud. Sebbene il cloud abbia agito come catalizzatore di trasformazione, alcune organizzazioni stanno optando per riportare una parte del loro ambiente tecnologico in casa. Cosa spinge questa tendenza e cosa possiamo imparare da essa?

🔗 Il Ritorno a Casa dal Cloud: Mentre le aziende migrano verso il cloud alla ricerca di scalabilità e flessibilità, alcune stanno riconsiderando questa scelta. Il rimpatrio implica riportare risorse informatiche e dati dai fornitori di servizi cloud alle infrastrutture interne. Può sembrare una mossa audace, ma è motivata da una serie di cause fondamentali.

🌐 Cause Comuni del Rimpatrio:

  1. Costi ed Efficienza: A volte, i costi di utilizzo continuo del cloud possono superare le aspettative. Il rimpatrio consente di controllare le spese e ottimizzare le risorse in base alle necessità specifiche.
  2. Regolamentazione e Conformità: Alcune industrie sono soggette a rigorose normative su dove devono essere conservati i dati. Il rimpatrio può essere una risposta a queste restrizioni legali.
  3. Latenza e Prestazioni: Alcune applicazioni richiedono bassa latenza e prestazioni ottimali. In questi casi, il rimpatrio può essere preferibile per avere un controllo diretto sull’infrastruttura.
  4. Complessità della Gestione: Man mano che gli ambienti cloud crescono, la gestione può diventare complessa. Il rimpatrio può semplificare l’amministrazione riportando determinati carichi di lavoro in un ambiente interno.
  5. Sicurezza e Privacy: Per alcune organizzazioni, la sicurezza e la privacy sono fondamentali. Il rimpatrio offre un maggiore controllo sulla sicurezza dei dati e delle applicazioni.

🌟 Lezioni per la Trasformazione Tecnologica: Il rimpatrio non è un segno di insuccesso nell’adozione del cloud, ma un esempio di flessibilità e adattabilità. Ci ricorda che la tecnologia è un mezzo per un fine e che ogni organizzazione ha esigenze uniche.

🚀 Guardando Avanti: La tecnologia continuerà a evolversi e le decisioni di rimpatrio o adozione del cloud dipenderanno dalla strategia e dalle circostanze di ciascuna azienda.

#Tecnologia #Cloud #Rimpatrio #TrasformazioneDigitale #Adattabilità #TendenzeTecnologiche

Condividiamo le nostre prospettive! Hai mai considerato il rimpatrio o hai esperienze da condividere? Conversazioni coinvolgenti ci guidano verso un futuro tecnologico più informato.

Italiano

L’Incredibile Longevità di SQL: Radici del Successo e il Potere del Paradigma Dichiarativo

Oggi, vorrei gettare luce su un linguaggio che ha attraversato epoche e rivoluzioni digitali, rimanendo saldamente al centro della gestione dei dati: SQL. La sua longevità è più che un semplice fatto storico; è il risultato di principi profondamente radicati e del potere del paradigma dichiarativo.

🔗 Un Viaggio Attraverso il Tempo: SQL, Structured Query Language, è nato negli anni ’70 e da allora ha attraversato ogni evoluzione tecnologica con eleganza e resilienza. Ma quale è il segreto di questa longevità senza pari?

🌟 Principi Fondamentali del Successo di SQL:

  1. Universalità: SQL è universalmente riconosciuto e utilizzato. Le aziende di tutte le dimensioni e settori lo abbracciano per la sua affidabilità e capacità di gestire complessità.
  2. Semplicità ed Espressività: La semplicità di SQL non ne mina la potenza. Le sue istruzioni chiare ed espressive permettono di manipolare e recuperare dati in modo intuitivo.
  3. Flessibilità: SQL si adatta alle mutevoli esigenze dei dati. Che si tratti di interrogare un database o di elaborare un vasto insieme di dati, SQL offre le basi per farlo in modo efficiente.
  4. Approccio Dichiarativo: E qui risiede il cuore del successo. L’approccio dichiarativo di SQL ci consente di dire «cosa» vogliamo ottenere, piuttosto che «come» ottenerlo. Questo paradigma sposta il focus dalla logica di esecuzione ai risultati desiderati.

🔍 Il Potere del Paradigma Declarativo:

L’approccio dichiarativo rappresenta un cambio di paradigma fondamentale. Ci affrancano dalla gestione dei dettagli operativi e ci consentono di concentrarci sui problemi e sulle soluzioni a un livello più elevato.

In un mondo in continua evoluzione, l’importanza del paradigma dichiarativo diventa ancora più evidente. Ci libera da codici intricati, consentendoci di adattarci agilmente alle mutevoli esigenze aziendali.

🚀 Riflettiamo e Innoviamo:

L’eccezionale longevità di SQL ci insegna che la solida base di principi e il paradigma dichiarativo possono portare a un successo duraturo. La storia di SQL non è solo un tributo al suo passato, ma anche un monito per abbracciare principi fondamentali mentre innoviamo nel futuro.

#SQL #GestioneDati #ParadigmaDichiarativo #Tecnologia #Innovazione #Longevità

Condividiamo riflessioni e esperienze su questo viaggio attraverso la tecnologia. La longevità di SQL ci ispira a perseguire l’innovazione con radici solide.

Italia, Italiano, Libros

Finalmente disponibile in Amazon mi ultimo libro: Dowshifting, Decrescita e Impresa Liquida

Non una semplice traduzione dal libro giá uscito 5 anni fa in Spagnolo. Una riedizione ampliata e aggiornata che dopo la pandemia ha trovato nuovi spunti e nuove materie di confronto.

Siamo in un ambiente instabile, per un po’ di tempo ci siamo divertiti. Ma le cose sono cambiate, dobbiamo passare dalla zona di comfort alla zona di inquietudine. Dobbiamo capire che ci sono nuovi paradigmi e nuovi modi di vedere le cose. Dobbiamo agire e smettere di lamentarci nel ricordo di quanto era bello prima, di quanto era comodo avere uno stipendio fisso a fine mese, di quanto era comodo comprare ciò che non potevamo permetterci, la crisi ci ha liberato da molte schiavitù e come diceva Einstein l’unica crisi è la crisi dell’incompetenza. Incompetenza lavorativa, etica e politica e fallimento del sistema inteso come «esisto, spendo e pretendo».

Essere liberi dalle buste paga significa rischiare, essere liberi dalle buste paga significa essere liberi di vivere la nostra vita nel modo che più ci piace e facendo ciò che ci piace. Al nostro ritmo e senza essere incanalati nei ritmi altrui.

La falsa sicurezza che il sistema ci offre serve a impedirci di pensare. La paura di fallire, di non riuscire ad andare avanti ci blocca. La paura è il più efficace inibitore del cambiamento. È per questo che non cambiamo.

«Il denaro è lo sterco del demonio», ma ne abbiamo bisogno per sentirci persone. Questo è assurdo. Paghiamo il prezzo della sicurezza perdendo parte del nostro cervello. 

Ma non vogliamo una vita frugale. Vogliamo sembrare non essere. Vogliamo che gli altri abbiano un’immagine di successo di noi. Perciò non viviamo realmente la nostra vita, cerchiamo continuamente di vivere la vita degli altri, compriamo, consumiamo senza alcun rispetto, senza alcuna logica.

“Un’opportunità significa essere disposti ad agire. Essere disposti ad agire significa essere disposti a correre un rischio. Essere disposti a rischiare significa essere disposti ad accogliere il cambiamento. (Michael Levine)”

Indice dei contenuti

  • 1 – Contro la pazzia 12
      • Downshifting ed equilibrio personale 13
      • La nuova rivoluzione non è collettiva, è individuale 14
      • Morire di fame… 15
      • Ma non siamo pazzi 15
      •   La grande invenzione dei Social 19
      • Il sottobosco “social” 25
      • Il talento non ci da da mangiare… la perseveranza sì 27
  • 2 – La crisi, un cómodo alibi sociale 29
      • Chi è stato vittima di tutto questo? 35
      • Vecchio a 40 anni 35
      • Europa e USA: siamo diversi 36
      • Dove usare il nostro talento… 39
  • 3 – Punto di svolta 40
      • Chi sono? 40
      • Qual è la mia filosofia di vita? 42
      • Perché sono arrivato qui? 42
      • Quali sono gli obiettivi più importanti della mia vita? 42
      • Quali sono le mie aspirazioni piú profonde? 43
      • Dove vado? 43
      • Che valori e principi mi guidano? 44
      • Cosa voglio conseguire? 44
      • In cosa credo? Quali sono i miei ideali? 44
      • Che ruolo voglio svolgere nella vita? 45
      • Quali fattori mi rendono irripetibile? 45
      • Cosa è decisivo per il mio successo personale? 45
      • Situazioni che generano un punto di svolta 46
      • Seneca e la visione stoica dell’imprenditorialità 47
  • 4 – Racconti per pensare 51
      • Un downshifting imposto 52
      • Un downshifting volontario 62
  • 5 – La mappa delle paure 68
      • Paura della povertá 68
      • Paura della solitudine 69
      • Paura della esclusione sociale 70
      • Paura dell’incertezza 70
      • Paura della paura 71
  • 6 – Capire la “impermanenza” (transitorietá) 76
      • La schiavitú dello stipendio 77
      • Un giorno il sistema scoppió… 77
      • La impermanenza (transitabilitá) 78
  • 7 – La Decrescita è la risposta? 81
      • Collettivizzare la rivoluzione 83
      • Vivere con meno (less is sexy) 84
      • Se la politica prendesse l’iniziativa 92
      • Nuove idee per le transazioni 93
      • Il Wir e le Criptovalute 94
      • Podemos e Movimento 5 Stelle 98
      • La societá é malata di crescita 99
      • Le regole il vero nemico della Frugalitá 105
      • Come le politiche dell’UE ci colpiscono 111
      • Che la «convivialità» ritorni 112
  • 8 – La grande menzogna della crescita sostenibile e il ricatto dei mercati 121
      • Se un peto sposta lo Spread 126
      • Malati di crescita 135
  • 9 – Downshifting in un mondo impermanente 140
      • Vivere per lavorare o lavorare per vivere? 141
      • Slow Movement un’idea italiana una prospettiva internazionale 143
      • Un appello ai giovani universitari 144
      • L’Anno sabbatico 146
      • Il Downshifting Manager 146
      • Into The Wild 148
      • Mappa strategica del Downshifting 152
      • Conto economico downshifting 154
      • Com’è la vita là fuori… 158
      • Invidia e falsita 159
      • Il giorno zero 160
      • Ricadute e perseveranza 162
      • Downshifting nutrizionale 163
      • Libri che ti cambiano la vita 165
      • Pochi secondi a volte possono essere molto preziosi per la nostra salute 173
      • Quando l’industria ci inganna con le etichette.. 175
      • La grande truffa della piramide alimentare 175
      • Fare sport… Yes We Can 176
  • 10 – La impresa liquida in mondo impermanente 178
      • Nuovi valori e nuove competenze 179
      • Cloud management 182
      • Il “mio posto di lavoro” non esiste 182
      • No company (la «no impresa») 183
      • Circondatevi di teste pensanti 184
      • Benessere 185
      • Lo shock del Futuro 186
      • La dichiarazione di Consulenza Artigiana 190
      • Un altro tipo di azienda è possibile 193
  • 11 – Strumenti per l’impresa liquida 196
      • Il viaggio inutile (storia vera) 197
      • Mobilitá nel lavoro 198
      • Quanto vale il nostro tempo 200
      • Uffici virtuali e Co-Working 201
      • Qualsiasi luogo è un buon posto per lavorare 203
      • Videoconferenze, web meeting e webinar: lo smart working in sintesi 206
      • Strumenti di collaborazione 212
      • Social Networks senza esserne schiavi 214
      • Twitter è uno strumento di business? 215
      • Software libero, più sicuro, più sostenibile 217
      • Tecnologia dell’informazione come servizio 220
      • Strumenti gratuiti per l’impresa liquida 223
  • 12 – Alcune teorie 226
      • Jerry Mander, el fin del capitalismo 226
      • La teoria di Keynes 228
      • Principio de Peter 231
      • La teoría del dare 233
      • Economia comportamentale 234
      • Teoria della crescita endogena 237
      • Teoria della selezione avversa 239
      • Teoria delle Reti 240
      • Economia delle piattaforme 243
      • Il Minimalismo “Less is More” 245
      • La ontologia del linguaggio 247
      • La teoria del denaro libero di Silvio Gesell 248
  • 13 – Conclusioni: Non finisce qui 249
      • Ringraziamenti 252
  • Bibliografía 252
  • Disponibile su Amazon in Kindle e Copertina Semirigida
Libros

Libro: 20 cose da sapere sul Data Management

C’è stato un tempo in cui abbiamo detto alle aziende che dovevano esaminare i loro dati: è nata la business intelligence. C’è stato un tempo in cui volevamo democratizzare l’uso dei dati: è nata la data-driven. Dopo un po’, ci siamo resi conto che grazie alla virtualizzazione e al cloud non era necessario spostare i dati, ed è nata la Data Virtualization. Alcune persone mi dicono che fondamentalmente non è cambiato nulla. Abbiamo una tecnologia straordinaria: cloud computing, questo ha cambiato molte cose.

Non siamo nella «trasformazione digitale», non si tratta di qualcosa che arriva e a cui bisogna adattarsi, ma é meglio parlare di «abitudine all’evoluzione digitale». Perché si tratta di un processo continuo, non di un evento isolato. Un processo che ha bisogno della Data Governance così come ha bisogno di altri aspetti legati ai dati (Data Quality, Data Analysing, Data Virtualisation, ecc.).

Siamo nell’era dei metadati. Se è vero che la Business Intelligence ha cristallizzato la strategia (passando dal «cosa» fare al «come» farlo), la Virtualizzazione dei dati ha liberato i dati dai legami fisici; la Data Governance concentrerà i suoi sforzi sui metadati. Non importa più quanti dati possiamo gestire e come li gestiamo. Dobbiamo sapere cosa ci dicono questi dati e chi decide cosa ci dicono. Senza Data Governance non c’è Data Management, questa è la visione di DAMA e io la condivido pienamente.

Mi occupo di gestione dei dati da alcuni anni e, sebbene esista un framework di riferimento importantissimo come il DmBok 2 di DAMA che utilizzo quotidianamente, ho pensato che sarebbe stato interessante sviluppare qualcosa di molto didattico per tutti coloro che si stanno avvicinando al mondo del Data Management. Potremmo dire che questo libro è una sorta di dizionario esteso per comprendere meglio questo affascinante mondo dei dati.

Ora più che mai i dati non sono un’opzione, sono il business!

Libro su Amazon

Business Intelligence, DAMA, Data Governance

Libro: 20 cosas que tienes que saber sobre Data Management

Si es verdad que el 75% de los activos de las empresas Standard & Poor ‘s no son físicos: ¿De qué estamos hablando? ¡De Datos! Qué sería de empresas como Booking, AirBNB, Facebook sin sus datos (y los nuestros) esto es motivo más que suficiente para entender la importancia del Data Management.

Hubo un tiempo en que dijimos a las empresas que tenían que mirar sus datos: nació el business intelligence. Hubo un tiempo en el que quisimos democratizar el uso de los datos y nació el data-driven. Pasado un tiempo, comprendimos que gracias a la virtualización y la nube no es necesario mover los datos y nació Data Virtualization. Algunos me dicen que en el fondo nada ha cambiado. Tenemos una tecnología impresionante, el cloud y el cómputo en la nube disparan el potencial de todo, pero también disparan la entropía.

No estamos en la “transformación digital”, no se trata de algo que llega y al que hay que adaptarse, se trata de hablar de “hábito de evolución digital”. Porque se trata de un proceso continuo no de algo puntual. Un proceso que necesita la Data Governance de la misma forma que necesita otros aspectos relacionados con los datos (Data Quality, Data Analyzing, Data Virtualization, etc.)

Estamos en la era de los Metadatos. Si es verdad que la Inteligencia de Negocio ha cristalizado la estrategia (pasando de “qué” hacer a “como” hacerlo), la Data Virtualization ha permitido liberar los datos de vínculos físicos; la Data Governance va a focalizar sus esfuerzos en los metadatos. Ya no importa la cantidad de datos que podamos tratar ni como lo tratamos. Necesitamos saber que estos datos nos dicen y quien decide que digan algo. Sin Data Governance no existe el Data Management, es la visión de DAMA y la comparto completamente.

Desde hace unos cuantos años me dedico a la gestión de datos, aunque existe un framework referente super importante como el DmBok 2 de DAMA que utilizo a diario, me pareció interesante desarrollar algo muy didáctico para todos aquellos que se acercan al mundo del Data Management. Podríamos decir que este libro es una especie de diccionario alargado para comprender mejor este mundo tan fascinante de los datos.

¡Ahora más que nunca el dato no es una opción es el negocio!

Hablaremos de: Data Literacy, Metadatos, Data Governance, Business Glossary, Data Dictionary, Data Catalog, ETL, ELT , Master Data, Data Lake, Data Warehouse,OLAP, ROLAP, MOLAP, DOLAP y HOLAP, Data Fabric, Data Mesh, Enfoque Declarativo vs Enfoque Procedural, Data Vault, Data Monetization, CDC, Data Virtualization y DmBoK2

Para comprar el libro : https://www.amazon.es/cosas-tienes-saber-sobre-Management/dp/8409483882libr

DAMA, Data Governance

Data Fabric: Soluciones convergentes para evitar un mosaico de herramientas complejas

Según Gartner, el Data Fabric es una arquitectura y un conjunto de servicios de datos que proporciona una funcionalidad consistente en una variedad de entornos, desde los locales hasta la nube. Data fabric simplifica e integra la gestión de datos en las instalaciones y en la nube, acelerando la transformación digital. ¿Cómo vamos a convencer a las empresas de que los datos son absolutamente transversales? ¿Cómo podemos realizar una valoración sólida de los datos? ¿Puede el data fabric ayudarnos en esto? ¿Podemos someter los silos de datos?

Gartner define el data fabric como un concepto de diseño que sirve como capa integrada (tejido) de datos y procesos de conexión. Una estructura de datos utiliza el análisis continuo de los activos de metadatos existentes para apoyar el diseño, el despliegue y el uso de datos integrados y reutilizables en todos los entornos, y es una necesidad para las organizaciones impulsadas por los datos: «El enfoque de la estructura de datos puede mejorar los patrones tradicionales de gestión de datos y sustituirlos por un enfoque más receptivo. Ofrece a los gestores de D&A la posibilidad de reducir la variedad de plataformas de gestión de datos integradas y ofrecer flujos de datos interempresariales y oportunidades de integración«.

Por eso es necesario un enfoque «todo en uno», es decir, una plataforma que pueda operar en toda la cadena de datos, desde la ingesta de datos hasta su explotación y visualización.

Un enfoque totalmente virtual (un sistema LDW basado en consultas) tiene la limitación de no poder materializar todos los procesos y, sobre todo, no permite una auditoría completa a lo largo del tiempo y en entornos muy regulados, como la banca y los seguros. El almacén de datos lógicos es un enfoque que puede resolver algún requisito específico, pero no tiene cabida en los procesos estructurados. El regulador no sólo puede preguntarnos cómo se realiza un determinado proceso de extracción y su linaje, también puede querer ver la réplica de un determinado proceso en una fecha concreta para ver todas las transformaciones y todos los procesos que han intervenido.

En contra de las herramientas Patchwork

Normalmente, cuando nos acercamos a una empresa para cualquier tipo de proyecto de datos, nos encontramos con un escenario típicamente fragmentado. Las empresas suelen incorporar herramientas según una lógica más bien comercial del momento histórico de la empresa. Así que es normal encontrar un mosaico de muchas herramientas diferentes: Tendremos fuentes de datos, diferentes almacenes de datos de distintos proveedores, motores analíticos, motores de reporting, cubos OLAP, etc. En el mejor de los casos, pueden proceder del mismo proveedor, pero aún así hay que resolver algunos problemas. ¿Cómo hacemos la automatización del flujo de trabajo? ¿Cómo gestionamos los metadatos? ¿Cómo documentamos los procesos? ¿Qué pasa con la responsabilidad? ¿Cómo respondemos al regulador? Es entonces cuando nos preguntamos a nivel de arquitectura que quizá deberíamos haber hecho de otra manera.

Un enfoque de gestión de datos empresariales (EDM), en el que todos los activos de datos se concentran en una única plataforma, sería la solución óptima. Además, según DAMA, la eliminación de los silos y la plena responsabilidad deberían estar en el centro de cualquier proyecto de datos. ¿Puede el concepto de Data Fabric ser una solución? Según Gartner, los data fabrics reducen el tiempo de diseño de la integración en un 30%, el despliegue en un 30% y el mantenimiento en un 70%, ya que los diseños tecnológicos se basan en la capacidad de utilizar/reutilizar y combinar diferentes estilos de integración de datos. Además, los data fabrics pueden aprovechar las habilidades y tecnologías existentes de los data hubs, data lakes y data warehouses, al tiempo que introducen nuevos enfoques y herramientas para el futuro. En este sentido, aunque un buen enfoque es disponer de una plataforma «todo en uno» con plenas capacidades de interoperabilidad, la implantación de un data fabric no requiere ninguna de las inversiones tecnológicas del cliente.

Articulo completo: https://www.linkedin.com/pulse/data-fabric-soluciones-convergentes-para-evitar-un-mosaico-iurillo/

Articulo original en ingles en DataVersity: https://www.dataversity.net/data-fabric-convergent-solutions-to-avoid-complex-tools-patchwork/

Base de Datos, Business Intelligence, inteligencia de negocio

ETL, CDC, ELT y DELT(TM)

Una de las cosas más fascinante que he encontrado dentro de IRION es sin duda el enfoque Declarativo. Es algo tan sencillo y tan potente. En años de Data Management siempre me he topado con problemáticas de gestión de datos. De procesos de extracción, de manos en la masa de datos, proyectos interminables, lentos, procesos de cargas sin fin, etc. 

 

Este artículo es fruto de mi afán de entender las cosas bien. Quería aclararme bien mi storytelling para la introducción de Irion en el mercado Español. Lo más bonito de mi trabajo es el aprendizaje que cada día los diferentes clientes y proyectos me aportan. Pero vamos con orden ¿que es un enfoque declarativo? Volviendo a mis antiguos apuntes de programación “Los programas se pueden clasificar por el paradigma del lenguaje que se use para producirlos. Los principales paradigmas son: imperativos, declarativos y orientación a objetos.” Sin ir mucho más lejos, SQL es declarativo, lanzar una query quiere decir quiero obtener un resultado concreto no me interesa saber de qué forma lo haces a nivel interno ya que los programas que usan un lenguaje declarativo especifican las propiedades que la salida debe conocer y no especifican cualquier detalle de implementación. El ejemplo más típico es el de la Paella, si voy a comer una a un restaurante simplemente pido “una paella”, no comunicó al camarero que quiero que se vayan sofriendo pollo y conejo con algo de ajo, aceite y romero, para luego poner las verduras, para luego poner el tomate el pimienton, todo ello con el caldo para luego verter el arroz… No somos expertos de cualquier cosa (aunque mi paella debido a los años de vida en Valencia no está nada mal por ser italiano) y cuando no llegamos a algo o no sabemos hacer algo delegamos en trabajo en alguien que sepa hacerlo mejor, más rápido y más bueno (sobre todo si de paella se trata).

 

Pero nosotros nos ocupamos de datos, muchos datos, estructurados, no estructurados en una gran cantidad de fuentes externas, de proveniencia histórica o reciente. Datos que tenemos que Gobernar y tener bien aseados a nivel de calidad. Datos que tenemos que rectificar, reconciliar, mantener historicizados. Datos que tenemos que “documentar” porque es el regulador que nos lo impone y de ellos tenemos que tener una trazabilidad total y el proceso tiene que ser repetible. Hasta ayer, hoy todo esto se nos hacía muy complejo, estos datos tenían que limpiarse, adaptarse, extraerse, copiarse, y por ello existen diferentes enfoques el más histórico y utilizado ha sido el ETL.

 

ETL Extract Transform Load

 

Ya hemos hablado largo y tendido de todas las problemáticas de los procesos ETL en otro artículo. Justo para introducir el tema, ETL son las siglas de Extract-Transform-Load. El término ETL describe el proceso de mover datos y hacer manipulaciones con ellos. Las herramientas ETL suelen tener funciones de conexión a múltiples plataformas de datos y aplican transformaciones a los datos en la memoria. Después, presumiblemente, el resultado se registra en algún lugar. Los algoritmos ETL también pueden escribirse en la mayoría de los lenguajes de programación modernos, pero muchas organizaciones consideran que esta opción es menos preferible debido a la sobrecarga que supone escribir el código desde cero y a la complejidad desconocida del soporte posterior. 

 

Llegó un momento en que nos dimos cuenta de era inutil repetir estos procesos de cargas, y las nuevas tecnologías y los nuevos enfoques nos han brindando el CDC (Change Data Capture)

 

CDC Change Data Capture

 

CDC es uno de los patrones ETL para copiar datos. Se utiliza para auditar cada cambio en un registro: ya sea que cambie alguno de los valores o que se elimine un registro. Antiguamente, este patrón se implementa con herramientas ETL comparando la última copia de los datos con el origen o comprobando la marca de tiempo de actualización del registro de origen. El rendimiento era pésimo y había una enorme posibilidad de perder algunas de las actualizaciones. Las herramientas de CDC han cambiado las cosas drásticamente, utilizan registros de transacciones para rastrear los cambios, por lo que ningún cambio pasa desapercibido, y ni siquiera afecta al rendimiento de la base de datos de origen. Hay dos métodos diferentes para detectar y recoger los cambios: el data el versionado, que evalúa las columnas que identifican las filas que han cambiado (por ejemplo, las columnas last-update- columnas de fecha y hora, columnas de número de versión, columnas de indicador de estado), o mediante lectura de registros que documentan los cambios y permiten replicarlos en sistemas secundarios. El CDC nos brindó muchas mejoras sobre todo en términos prestacionales, herramienta como Qlik ha hecho de CDC un mantra sobre todo cuando su producto ha querido salir del mundo OLAP. Pero… Llegó la nube y lo cambió todo, almacenamiento y cómputo de alta disponibilidad han creado un nuevo escenario. 

 

ELT Cargamos primero…

 

El enfoque ETL fue una vez necesario debido a los altos costos de la computación y el almacenamiento en las instalaciones. Con el rápido crecimiento de los almacenes de datos basados en la nube y la caída en picado de los costos de la computación y el almacenamiento basados en la nube, hay pocas razones para seguir haciendo la transformación antes de la carga en el destino final. De hecho, dar la vuelta a los dos permite a los analistas hacer un mejor trabajo de forma autónoma.

En pocas palabras ahora los analistas pueden cargar los datos antes de transformarlos, no tienen que determinar de antemano exactamente qué conocimientos quieren generar antes de decidir el esquema exacto que necesitan obtener y esta es una gran ventaja.

En su lugar, los datos de la fuente subyacente se replican directamente en un almacén de datos, que comprende una «única fuente de verdad». Los analistas pueden entonces realizar transformaciones en los datos según sea necesario. Los analistas siempre podrán volver a los datos originales y no sufrirán transformaciones que puedan haber comprometido la integridad de los datos. Esto hace que el proceso de inteligencia de negocio sea incomparablemente más flexible y seguro.

 

DELT(™)

 

Delt es una de las tecnologías propietarias de IRION. El motor orquesta y sincroniza el plan de procesamiento y control de datos con algoritmos inteligentes, lo que permite a los profesionales de la gestión de datos -que utilizan la plataforma Irion EDM®- trabajar en un entorno autoadaptativo y basado en metadatos.

Las ventajas principales son:

  • El enfoque declarativo permite al motor DELT™ alcanzar altos niveles de rendimiento al maximizar el paralelismo de las fases de procesamiento.
  • la arquitectura DELT™ está diseñada para trabajar eficazmente con grandes volúmenes de datos mediante motores orientados a conjuntos.
  • El ingeniero de datos se encarga de los aspectos semánticos de las soluciones delegando en la plataforma la gestión automática de las estructuras de datos.
  • la integración de motores con tecnologías heterogéneas, como Query, Script, Rule, R, Python, Masking, Profiling, permite utilizar la herramienta más adecuada para cada situación.

 

Un enfoque declarativo permite concentrarse en lo que se quiere obtener. Esto es lo que importa. 

 

 

 

Data Governance

Actividades Claves en el diseño de una estrategia de Gobierno de Datos

Este encierro forzado por el #Covid19 y la preparación de los cursos de Data Governance para la certificación de DAMA-I me permiten compartir con vosotros algunas buenas prácticas a la hora de diseñar un estrategia de Data Governance

Como ya he escrito en otros artículos y publicaciones sobre la materia, no considero la Data Governance como un proyecto sino más bien como un proceso continuo y sostenido en el tiempo. Es fundamental un acercamiento por fases e incremental para poder organizar los datos de la organización sin traumas y sin fisuras. Hacer las cosas bien nos permite tener que rectificar lo menos posible. Las 4 fases clásicas se acercan mucho al enfoque PMO ya que tenemos una iniciación, una planificación, una ejecución y un cierre que realmente no es como tal sino más bien un proceso continuo de mejora.

Siguiendo el enfoque del marco de DAMA tenemos algunas pautas que nos pueden ayudar:

Evaluar el grado de preparación de la organización

Habrá que considerar las características culturales y ambientales, así como las aspiraciones de la organización y sobre todo será necesario evaluar la madurez de la DM: ¿qué hace la organización con los datos? ¿Qué piensan las empresas y los individuos sobre el uso organizativo de los datos? Será necesario evaluar la capacidad de cambio: dado que la DG requiere un cambio de comportamiento, si antes el acceso a los datos era sencillo y desordenado, un proceso de Gobierno de Datos trae consigo un cambio fundamental, quizás al principio haya cierta resistencia y ganas de saltarse el sistema de control, pero poco a poco la organización se irá adaptando si las cosas se hacen bien desde el principio, más que dotarse de una herramienta desde el minuto uno será más necesario tener claro que el gobierno de los datos es algo que la organización no puede pasar por alto.

¿Tienen un programa o una estructura de gestión del cambio? ¿Han gestionado el cambio anteriormente? Esta fase también ayudará a comprender los posibles puntos de «resistencia» que siempre hay.

Articulo completo aquí: https://www.linkedin.com/pulse/actividades-claves-en-el-dise%C3%B1o-de-una-estrategia-gobierno-iurillo/