Todas las entradas de: micheleiurillo

Nueva etapa, nuevas personas en Dama España

Es con mucha tristeza que anuncio a toda la Comunidad de DAMA España que he presentado ayer a la presidencia de la asociación mi renuncia en seguir en la junta directiva debido a motivos personales.

Ha sido un periodo intenso y motivador donde hemos estado haciendo todo lo posible para hacer crecer la asociación y la comunidad del Dato en España. Encontramos cenizas y hoy la asociación presenta una cuentas aseada un numero de socios que nos pone entre los lideres mundiales y un numero de certificados sin iguales.

He fracasado en intentar imponer un cambio aun más acelerado y motivador no he sabido trasmitirlo al resto de la junta directiva y me siento completamente demotivado en el seguir dedicando tiempo y ver con impotencia que se toman decisiones que no comparto. O peor aun que no se toman y no se avanza.

He fracasado en intentar crear una junta amplia e integradora pero ha resultado inmanejable por falta de compromiso de algunos. 

Por coherencia no puedo seguir, por lo menos no en la actual junta. Seguiré siendo un socio raso pagando su cuota y aportando mi granito de arena cada vez que pueda. 

Agradezco todos mis compañeros que han estado conmigo en estos años, aquellos que han aguantado mi determinación y aquellos que no la han soportado. Si alguien se ha sentido ofendido por mi actitud pido disculpas. Siempre he metido vehemencia en todo porque creo en lo que hago. No es un pasatiempo para mi y tengo la mala costumbre de tomarme los compromisos en serio. He aprendido mucho de todos vosotros y sois unos profesionales como la copa de un pino.

Las personas no son imprescindibles lo son los valores, lo es la ética.

DAMA seguirá creciendo y confio plenamente que quien tome el relevo lo sepa hacer mejor yo he metido toda la energía que he podido.

Quedan pendiente muchas cosas que no se han podido abordar:

  • Profesionalizar la estructura asociativa con un gerente
  • Redactar e implicarse en un nuevo plan estratégico, un nuevo propósito
  • Dar el seguimiento que se merecen a nuestros patrocinadores
  • Redactar un manual de régimen interno que guíe la asociación, donde se ponga de manifiesto que, quien no participa de forma activa no puede estar en una asociación ya que hay un compromiso hacia los socios que tiene que ser prioritario
  • Re alinearse sin titubear a Dama International manteniendo nuestra particularidad

Estoy seguro que todo esto va a ser una prioridad de este junta directiva o la que siga. 

Gracias a todos
Michele Iurillo

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.

 

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?

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.

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.

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

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

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

El enfoque declarativo en el Data Management y la ventaja de Irion EDM

de Michele Iurillo* y ChatGPT

Este artículo se ha escrito a 4 manos.. (si se puede decir) de un lado he usado ChatGPT con preguntas muy concretas, del otro he añadido elementos para complementar la información. Imaginarlo como un experimento sobre el argumento del momento y una forma de concretar más el enfoque declarativo en Data Management que es uno de los puntos fuertes de la tecnología de Irion EDM.

El enfoque declarativo se refiere a una forma de expresar un problema o una solución en términos de lo que se desea lograr, en lugar de cómo se desea lograrlo. En lugar de especificar los pasos detallados para resolver un problema, se especifica el resultado deseado.

En programación, el enfoque declarativo se utiliza para escribir código que especifica qué se desea lograr, en lugar de cómo se desea lograrlo. Por ejemplo, en lugar de escribir código que especifica cómo recorrer una lista de elementos y realizar una determinada acción en cada uno de ellos, se escribe código que especifica que se desea realizar esa acción en cada elemento de la lista. El lenguaje de programación se encarga de resolver cómo realizar esa acción.

El enfoque declarativo se utiliza en varios campos, como en bases de datos, en donde los lenguajes declarativos son aquellos que se centran en describir los resultados deseados en una consulta, en lugar de describir cómo se obtienen esos resultados. SQL es un ejemplo de un lenguaje declarativo utilizado en las bases de datos relacionales.

En resumen, enfoque declarativo es una forma de abordar un problema o una solución enfatizando en lo que se quiere lograr en lugar de cómo se quiere lograrlo, permitiendo al sistema o lenguaje de programación encargarse de las tareas de implementación.

Algunos ejemplos de lenguajes de programación declarativos son:

  1. SQL (Structured Query Language): Es un lenguaje declarativo utilizado para acceder y manipular bases de datos relacionales. En lugar de especificar cómo recuperar los datos, se especifica qué datos se desean recuperar mediante consultas.
  2. Prolog: Es un lenguaje de programación lógico declarativo utilizado en inteligencia artificial y programación de sistemas expertos. Permite al programador especificar reglas y hechos, y luego utilizar un motor de inferencia para obtener conclusiones.
  3. Haskell: Es un lenguaje de programación funcional declarativo utilizado para construir sistemas concurrentes y distribuidos. En lugar de especificar cómo se deben realizar las operaciones, se especifican las operaciones que se desean realizar y el lenguaje se encarga de resolver cómo realizarlas.
  4. XSLT: (Extensible Stylesheet Language Transformations) es un lenguaje declarativo utilizado para transformar documentos XML en otro formato, como HTML o PDF. El programador especifica cómo se deben transformar los datos, en lugar de cómo se deben recuperar.
  5. RDF: (Resource Description Framework) es un lenguaje declarativo utilizado para describir recursos y relaciones entre ellos. Es ampliamente utilizado en la web semántica y el enriquecimiento de metadatos.

Enfoque Procedural

El enfoque procedural se refiere a una forma de expresar un problema o una solución en términos de los pasos específicos que deben seguirse para lograr un resultado. En lugar de especificar el resultado deseado, se especifican los pasos detallados para resolver el problema.

En programación, el enfoque procedural se utiliza para escribir código que especifica cómo se deben realizar las tareas, en lugar de qué tareas se deben realizar. Por ejemplo, en lugar de escribir código que especifica que se desea realizar una determinada acción en cada elemento de una lista, se escribe código que especifica cómo recorrer la lista y realizar la acción en cada elemento.

Los lenguajes de programación procedurales son aquellos que siguen un enfoque de programación estructurada, en donde se divide el código en bloques lógicos y se organizan en funciones y procedimientos

Algunos ejemplos de lenguajes de programación procedurales son:

C: Es un lenguaje de programación de alto rendimiento y de bajo nivel, que es ampliamente utilizado para desarrollar sistemas operativos, dispositivos embebidos y aplicaciones de bajo nivel. Es un lenguaje de programación estructurado, con un enfoque en la programación procedural.

Pascal: Es un lenguaje de programación estructurado, desarrollado para la enseñanza de la programación en las universidades. Es ampliamente utilizado para desarrollar aplicaciones de escritorio, juegos y aplicaciones científicas.

Fortran: es un lenguaje de programación procedural desarrollado para cálculo científico y numérico, es utilizado en aplicaciones como simulación de sistemas, modelado de fluidos y análisis estadísticos.

Basic: es un lenguaje de programación procedural muy fácil de aprender para principiantes. Fue diseñado para enseñar a los estudiantes de programación básica

¿Por qué es mejor el enfoque declarativo en Data Management?

El enfoque declarativo en Data Management tiene varias ventajas sobre el enfoque procedural. Algunas de estas ventajas son:

  1. Mayor claridad: El enfoque declarativo permite especificar los resultados deseados de manera clara y concisa, lo que ayuda a reducir el riesgo de errores y aumenta la eficiencia en el manejo de datos.
  2. Mayor flexibilidad: Al especificar los resultados deseados en lugar de los pasos para lograrlos, el enfoque declarativo permite adaptarse fácilmente a cambios en los datos o en los requisitos del sistema.
  3. Mayor escalabilidad: Al permitir la separación entre la especificación de los resultados y su implementación, el enfoque declarativo permite escalar el sistema de manejo de datos sin tener que modificar el código.
  4. Mayor portabilidad: Al separar la especificación de los resultados de su implementación, el enfoque declarativo permite el uso de diferentes sistemas o tecnologías para implementar la especificación.
  5. Mayor eficiencia: Al permitir que el sistema se encargue de implementar la especificación, el enfoque declarativo permite obtener resultados más rápidamente y con menos recursos.

En resumen, el enfoque declarativo en Data Management ofrece una mayor claridad, flexibilidad, escalabilidad, portabilidad y eficiencia en la gestión de datos. Al permitir especificar los resultados deseados en lugar de los pasos para lograrlos, permite una mayor escalabilidad, flexibilidad y portabilidad.

DELT(™) ELT Declarativo

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.

Para info: http://irion-edm.com/es

Como solventar el problema del loop login en Mac OS X en un MacBook 3.1 antiguo que no tiene modalidad R [solucionado]

He perdido 3 dias y al final leyendo mucho material incluso en aleman he llegado a la solución.

Lo que no vale en un MacBook 3.1 finales 2007

  • Primero no es posible hacer <option> – <R> 
  • No es posible hacer un boot desde USB porque no tenia otro mac y los experimentos
  • con Transmac y diferentes USB no han dado resultado porque el mac no admite boot de USB con la opción <alt>

Solución

Al arrancar este Mac que estaba en alguna parte sin usarse como 4 años empecé a ver el bucle de inicio de sesión: la máquina arranca bien, pero al poner el nombre de usuario y la contraseña, el sistema se cuelga durante unos 20 segundos antes de volver a mostrar la ventana de inicio de sesión. Está claro que algo se ha estropeado, y afortunadamente he podido solucionarlo.

Intenté las soluciones sugeridas – arrancar en modo seguro e iniciar la sesión (seguía teniendo el mismo problema); ejecutar una comprobación del sistema de archivos en modo de usuario único (no se informaba de ningún error); borrar las listas de la ventana de inicio de sesión; y cambiar la contraseña – pero no tuvieron ningún efecto. Pude entrar en la cuenta de administrador temporal que doy a Apple cuando la máquina se envía para el servicio, así que supe que era algo específico de mi cuenta diaria. Pude entrar en el modo de usuario único (manteniendo pulsado Comando-S justo después del sonido de arranque) y examinar el archivo /var/log/system.log. Esto es parte de la naturaleza UNIX subyacente de MacOSX, y fue el único lugar que encontré que daba pistas sobre lo que estaba pasando. Aquí está una parte del archivo de registro que se produce justo después de pulsar retorno en la pantalla de inicio de sesión:

oginwindow[23]: USER_PROCESS: 23 console

com.apple.launchd[1] (com.apple.UserEventAgent-LoginWindow[86]): Exited: Terminated

ReportCrash[106]: Formulating crash report for process lsregister[104]

La pista clave está en negrita – el proceso de lsregister está fallando. Encontré una pista para la solución en una publicación del blog de 2003 de un tipo llamado Rick cuando dijo Después de un par de horas de búsqueda, y un poco de suerte (pude conectarme desde otra máquina y ver el registro del sistema informar de los bloqueos), descubrí que la caché de Launch Services estaba dañada, y estaba causando que lsregister fallara. Su publicación estaba relacionada con MacOSX 10.2.6, y desde entonces el nombre del archivo de caché de Launch Services ha cambiado. Lo encontré en el mismo lugar (el directorio /Library/Caches), pero ahora hay más de uno y toman la forma de «com.apple.LaunchServices-023uid.csstore» donde uid varía dependiendo del número de userid apropiado. He eliminado todos los archivos de Launch Services de /Library/Caches, he reiniciado y he podido iniciar la sesión sin problemas. El único efecto secundario fue que la lista de aplicaciones que se lanzan al iniciar la sesión desapareció (la pestaña «Elementos de inicio de sesión» del panel de preferencias de la cuenta) y tuvo que ser reconstruida.

Ahora el Mac funciona aunque no puedo hacer mucho con el… 

Recapitulando:

Arrancar con modalidad S

al root#

 /sbin/fsck -fy

/sbin/mount -uw

 

Borrar todos los ficheros : «com.apple.LaunchServices-****.csstore” en la carpeta /Library/Caches con RM (foto)

hacer otro 

 

 /sbin/fsck -fy

 

Reiniciar… y ahora el Login Loop ya ha desaparecido…