Managed Meta Data Environment (Parte Seconda)

Il livello di integrazione dei meta-dati

Il livello d’integrazione dei meta-dati (Figura 6) accede alle diverse fonti di meta-dati, li integra e li carica nel repository dei meta-dati stessi. Questo approccio differisce leggermente dalle tecniche più comuni usate per caricare i dati all’interno di un data warehouse, poiché quest’ultimo separa nettamente il processo di trasformazione (che noi chiamiamo integrazione) da quello di caricamento. In un MME le due fasi sono combinate perché, in quest’ultimo, il volume dei meta-dati è molto diverso da quello dei dati di un data warehouse. Come regola generale, l’MME mantiene da 5 a 20 gigabyte di meta-dati; tuttavia, poiché gli MME stanno cercando di indirizzare anche meta-dati relativi alla verifica dei meta-dati già contenuti, la memoria necessaria può crescere nel range dei 20-75 gigabite ed entro i prossimi cinque anni vedremo che alcuni MME raggiungeranno l’ordine dei terabyte.

 Le fasi specifiche all’interno di questo processo dipendono dal fatto che stiate costruendo un processo personalizzato oppure che utilizziate uno strumento di integrazione dei meta-dati per assistervi in tale compito. Se decidete di usare uno strumento di integrazione dei meta-dati, la scelta di quest’ultimo impatterà grandemente sull’intero processo.

Repository dei meta-dati

Repository dei meta-dati è una definizione forse non molto chiara per un database progettato per raccogliere, mantenere e distribuire meta-dati. Il repository dei meta-dati (Figura 7) è responsabile per la catalogazione e memorizzazione durevole dei meta-dati

 Il repository dei meta-dati deve essere generico, integrato, aggiornato e storico. Generico significa che il modello dei meta-dati mira a memorizzare i meta dati ordinati per soggetto, invece che specificatamente per le applicazioni. Ad esempio, un meta-modello generico avrà un attributo denominato “DATABASE_PHYS_NAME” che conterrà i nominativi dei database fisici esistenti all’interno dell’impresa. Un meta-modello specifico per un’applicazione indicherà il medesimo attributo come, ad esempio, “ORACLE_PHYS_NAME”. Il problema con i meta-modelli specifici per le applicazioni è che le aree dei soggetti di riferimento dei meta-dati possono cambiare. Per tornare al nostro esempio, oggi Oracle potrebbe essere il nostro database standard. Domani, invece, potremmo passare ad un Server SQL come nuovo standard, ritenuto più vantaggioso in termini di costo e di compatibilità. Questa situazione causerebbe modifiche addizionali al meta-modello fisico, altrimenti non necessarie.[1]

Un repository dei meta-dati fornisce anche una visione integrata delle maggiori aree dei soggetti relativi ai meta-dati dell’impresa. Il repository consentirà agli utenti di vedere tutte le entità esistenti all’interno di quest’ultima e non solamente quelle caricate in Oracle, oppure quelle che si trovano unicamente nelle applicazioni CRM (Customer Relationship Management).

In terzo luogo, il repository dei meta-dati contiene i meta-dati attuali e quelli che verranno aggiunti in futuro. Questo significa che i meta-dati vengono aggiornati periodicamente per riflettere gli ambienti tecnici e di business attuali e futuri. Ricordate che il repository dei meta-dati deve essere necessariamente aggiornato per mantenere il suo valore reale.

Infine, i repository dei meta-dati hanno un grande valore storico. Un buon repository manterrà la visione storica dei meta-dati anche se questi si modificano nel tempo. Questo consente all’impresa di mantenere la conoscenza dell’evoluzione della propria attività nel tempo. Si tratta di un aspetto specialmente critico se l’ambiente MME supporta un’applicazione che contiene dati storici, come un data warehouse o un’applicazione CRM. Ad esempio, supponiamo che la definizione di “cliente” per un meta-dato di business sia “chiunque abbia comprato un prodotto della nostra società in uno dei nostri negozi o direttamente dal nostro catalogo”. Un anno dopo, la società aggiunge un nuovo canale di distribuzione. La società costruisce un sito web per consentire ai clienti di ordinare direttamente i prodotti. A questo punto, la definizione del meta-dato che indica il cliente sarà modificata in “chiunque abbia comprato un prodotto della nostra società in uno dei nostri negozi, tramite ordine postale dal catalogo o tramite il web”. Un buon repository dei meta-dati mantiene entrambe queste definizioni perché sono tutte e due valide, in base a quali dati verranno analizzati (oltre che in base alla loro età). Per concludere, si raccomanda fortemente di implementare il proprio repository di meta-dati su di una piattaforma di database relazionale aperto, invece di utilizzare un database proprietario.

Livello di gestione dei meta-dati

Il livello di gestione dei meta-dati fornisce una gestione sistematica del repository dei meta-dati e degli altri componenti MME (vedi Figura 8). Come per gli altri livelli, l’approccio a questo componente differisce notevolmente nel caso in cui lo strumento di integrazione dei meta-dati utilizzato per l’intero ambiente MME sia di tipo proprietario. Se uno strumento di integrazione dei meta-dati dell’impresa viene usato per la costruzione dell’MME, allora l’interfaccia di gestione dei meta-dati è verosimilmente inserita all’interno del prodotto. Questo non avviene quasi mai; tuttavia, se non è costruito all’interno del prodotto, allora dovrete realizzarlo in casa. Il livello di gestione dei meta-dati assicura le seguenti funzioni:

· Archivio

· Backup

· Modifiche del Database

· Messa a punto del Database

· Gestione dell’ambiente

· Schedulazione delle attività

· Statistiche di carico del sistema

· Depurazione dei dati

· Statistiche delle interrogazioni

· Generazione di interrogazioni e di report

· Recovery

· Processi di security

· Mappatura e movimentazione delle fonti

· Gestione dell’interfaccia utente

· Gestione delle versioni

[1] Per vedere diversi modelli di meta-dati fisici, vedi Capitoli 4 – 8 di “Universal Meta Data Models” (David Marco & Michael Jennings, Wiley 2004)

Archivio

La funzione Archivio consente all’architetto dei meta-dati di stabilire il criterio o l’evento che attiva il processo di archiviazione all’interno dell’MME. Tale funzione deve essere in grado di archiviare tutti i meta-dati all’interno del loro repository e dei data mart collegati, oltre a consentire l’archiviazione, quando necessario, di tabelle di meta-dati specifiche.

Backup

La funzione di backup spesso viene confusa con l’archiviazione. L’archiviazione riguarda la memorizzazione delle versioni più vecchie e meno utilizzate dell’MME, mentre il backup è il processo che assicura la memorizzazione dell’MME corrente in un database separato, in modo che se la versione dell’MME in produzione risulta errata oppure un suo componente non opera correttamente, una versione di backup possa essere attivata immediatamente on line. Spesso, la strategia di backup viene implementata al livello dell’hardware mediante la duplicazione (mirroring) dei dischi. Le migliori pratiche in quest’area comprendono la memorizzazione della copia di backup in una locazione fisica diversa da quella dell’MME in produzione.

Modifiche al database

Dal momento che il meta-modello è implementato in un database aperto e relazionale, spesso le tabelle e le colonne di dati all’interno del meta-modello debbono essere modificate o cancellate. Il livello di gestione dei meta-dati ha bisogno non solamente di assistenza in questo processo, ma anche di riconoscere i cambiamenti effettuati nell’MME.

Messa a punto del database

La messa a punto del repository dei meta-dati e dei data mart associati rappresenta una parte molto importante nell’ambito del livello di gestione dei meta-dati. In primo luogo, l’identificazione degli indici assicura che i report siano prodotti in maniera efficiente. Nell’analizzare le strutture del meta-modello fisico, normalmente vengono esaminati gli indici come chiavi di accesso primarie. Questo è segno di una strategia di indicizzazione inadeguata o mancante.

In secondo luogo, la messa a punto del database vi aiuta a identificare i meta-dati dormienti all’interno del repository. Un MME di grandi dimensioni, in uso anche da pochi anni, normalmente contiene una larga parte di meta-dati dormienti. Un MME ottimizzato conterrà i meta-dati che consentono le misurazioni statistiche operative sull’uso dei meta-dati nell’ambito dell’MME, in modo da permettere l’identificazione dei meta-dati inutilizzati da tempo.

Gestione dell’ambiente

Molti specialisti dei meta-dati commettono l’errore di credere che quando implementano un MME, stiano implementando e mantenendo un solo sistema. In verità, stanno costruendo e mantenendo tre (o forse più) sistemi:

• Produzione
• Test
• Sviluppo

La versione di produzione dell’MME è il sistema definibile come ambiente di produzione? di un’organizzazione, oltre ad essere la versione dell’MME cui hanno accesso gli utenti finali. L?ambiente di test è la versione utilizzata per verificare la correzione dei “bachi” di sistema trovati nella versione di produzione dell’MME. La versione di sviluppo dell’MME è utilizzata per sottoporre a test i futuri e maggiori miglioramenti dell’MME.

La definizione e le dimensioni degli ambienti MME sono diversi a seconda degli standard IT interni all’organizzazione; tuttavia, i tre ambienti menzionati sopra sono i più comuni. In ogni evento, un livello di gestione dei meta-dati può gestire un numero qualsiasi di ambienti e nomi, in base alle necessità dell’organizzazione. La porzione di gestione dell’ambiente del livello di gestione dei meta-dati ha comunque bisogno di organizzare e controllare la gestione e la migrazione dei dati tra queste tre versioni di sistema.

Schedulazione delle attività

Le attività relative ai programmi ed ai processi necessari che debbono essere eseguiti per caricare l’MME e per accedere ai meta-dati contenuti debbono essere schedulate e gestite. La porzione dedicata a questa funzione del livello di gestione dei meta-dati è responsabile della loro schedulazione sia in relazione al verificarsi di determinati eventi che in termini di attivazione di elaborazioni batch.

Statistiche di carico del sistema

I livelli di estrazione e di integrazione dei meta-dati dell’MME generano un gran numero di interessanti statistiche relative al carico di lavoro del sistema. Queste statistiche di carico dell?MME debbono essere conservate nella sezione storica all’interno della porzione dell’MME definita come repository. Alcuni esempi delle statistiche di carico più comuni comprendono:

• Quanto tempo di elaborazione assorbe un particolare passo di un processo (tempo di clock oppure di CPU)?
• Quanto tempo viene impiegato complessivamente dalle elaborazioni relative ai livelli di estrazione e di integrazione dei meta-dati (sia clock che CPU)?
• Quali errori sono stati incontrati nell’ambito dei livelli di estrazione e di integrazione dei meta-dati?
• Quali erano le categorie di errori rilevati (ad es., di informazione, di allerta, gravi, critici, ecc.)
• Quante righe sono state inserite, modificate o cancellate in ciascuna tabella del meta-modello?

Depurazione dei dati

Questa parte del livello di gestione dei dati definisce I criteri relativi alle necessità di depurazione dei dati. I vostri criteri e necessità specifiche di depurazione dei dati saranno governati dalle necessità dell’impresa. Come regola generale, un meta-dato che risulti non corretto o caricato erroneamente deve essere eliminato; tutti gli altri meta-dati debbono essere archiviati.

Statistiche delle interrogazioni

Una volta generati i vari report relativi al livello di consegna dei meta-dati, è importante ottenere le statistiche associate all’accesso a questi report e interrogazioni da parte degli utenti. Come minimo, il livello di gestione dei meta-dati deve poter accedere ai seguenti dati storici:

• Chi ha avuto accesso al report o all’interrogazione?
• Quali report o interrogazioni sono stati interessati?
• Quando è avvenuto l’accesso al report o all’interrogazione?
• Con quale frequenza avvengono gli accessi al report o all?interrogazione
• Quanto dura l’accesso al report o all’interrogazione?

Generazione di interrogazioni e di report

I report e le interrogazioni utilizzate nell’ambito del livello di consegna dei meta-dati sono definiti e generati nella sezione di generazione dei report, all’interno del livello di gestione dei meta-dati. Come questo avvenga dipende dal fatto che sia stato implementato uno strumento di accesso ai meta-dati oppure che sia stata sviluppate un’applicazione proprietaria di consegna dei meta-dati agli utenti. Questo componente deve anche gestire qualunque funzione di pubblicazione o di sottoscrizione che venga richiesta.

Recovery

Esistono molte situazioni che possono costringere un’impresa a un’azione di ripristino e ricaricamento di una versione precedente del proprio MME: ad es.,malfunzioni hardware, errori nel database, black out elettrici o errori all’interno del livello di gestione dei meta-dati. Il processo di recovery deve essere strettamente collegato alle funzioni di backup e di archiviazione del livello di gestione dei meta-dati. I processi di recovery possono essere realizzati ad hoc oppure possono utilizzare quelli già predisposti all’interno degli strumenti di integrazione dei meta-dati. Entrambi gli approcci debbono essere integrati all’interno delle applicazioni relative ai processi di recovery già esistenti nell’organizzazione

Processi di security

I processi di security gestiscono:

• Creazione di nuovi utenti dell?MME
• Raggruppamento degli utenti dell?MME
• Registrazione dei privilegi e dei profili degli utenti dell?MME
• Firewall/Infrastruttura
• Gestione delle password
• Verifica della locazione degli utenti
• Mascheramento dei meta-dati (livello dati o livello di accesso)

L’estensione dei processi di security dipende dalle necessità dell’impresa che ha realizzato l?MME. Ad esempio, le necessità di sicurezza degli MME del Dipartimento della Difesa oppure del Federal Bureau of Investigation (FBI) sono sicuramente maggiori di quelle di una banca.

Mappatura e movimentazione delle fonti

Le fonti di meta-dati debbono essere mappate con i corretti attributi ed entità del repository dei meta-dati. Questo processo di mappatura e movimentazione deve essere inserito e gestito nell?ambito del livello di gestione dei meta-dati dell’MME.

Gestione dell’interfaccia utente

Questo è il processo che consente di costruire, gestire e mantenere il sito Web (ovvero l?interfaccia utente raccomandata), che l’utente finale visiterà navigando all’interno dell’MME. Tipicamente, la schermata (versione del sito Web) che viene presentata all’utente dipende dal suo profilo e dai suoi privilegi di security. Un utente generico dell’impresa non sarà interessato a vedere le modifiche delle codifica dei programmi, per cui avrà senso non presentargli report o interrogazioni relativi meta-dati di valore esclusivamente tecnico, in base a un corretto controllo del suo ruolo aziendale.

Gestione delle versioni

Nel momento in cui un meta-dato venga modificato, aggiunto o cancellato è importante per il livello di gestione dei meta-dati mantenere una traccia storica (definita versione) del suo cambiamento di stato. Esistono due tecniche usate comunemente per mantenere traccia delle versioni dei meta-dati. La prima è basata sull’utilizzo della data. In altri termini, ad ogni riga di entità del vostro modello di meta-dati viene assegnata una data, in modo che in caso di modifiche successive si possa sempre risalire al dato storico.

La seconda tecnica consiste invece nell’assegnare un numero progressivo di versione ad ogni riga del modello dei meta-dati. I numeri di versione sono dei valori univoci (ad es., 1.1, 1.2, 1.a, ecc.). I numeri di versioni sono più limitativi delle date, che offrono una migliore visibilità agli utenti dell’MME. Per altro, i numeri di versione possono essere associati a date e valori temporali specifici, una soluzione che però aggiunge ulteriore complessità al caricamento dei meta-dati e un’aggiunta di carico negli accessi per richieste di dati o elaborazione di report.

Un’altra opportunità offerta dalla gestione delle versioni è la cattura di meta-dati che debbano essere inseriti nell’MME in un determinato momento futuro. Ad esempio, una nuova tabella fisica può essere spostata nell’ambiente di produzione in una data futura. Per gestire queste situazioni di cambiamento delle versioni, può risultare utile l’uso delle “righe con data effettiva”. Le righe con data effettiva costituiscono un processo che consente di inserire i dati in un gruppo (tabella) per una elaborazione successiva allo scadere della data indicata. I dati di questo tipo possono essere storici, attuali o futuri. Qui sotto elenchiamo i concetti fondamentali relativi alle righe con data:

Data effettiva. La data alla quale la riga di meta-dati diviene effettiva; la data in cui può essere sottoposta a elaborazione.

Stato effettivo. Consente a un’applicazione di selezionare le righe con le data effettive, in corrispondenza dello scadere della data effettiva (lista dei valori: “attivo” oppure “inattivo”).

Riga corrente.La prima riga di dati con una data effettiva uguale o minore della data di sistema e con uno stato effettivo “attivo”. Solo una riga può trovarsi in questo stato.

Riga futura. Righe di meta-dati che posseggono una data futura rispetto a quella del sistema.

Riga storica. Righe di meta-dati che hanno una data effettiva minore di quella della riga corrente.

La Tabella 1 illustra la tecnica delle righe con data effettiva. In questo esempio, la data corrente del sistema è il 20 gennaio 2004. La riga di meta-dati datata “27.01.2004” ha uno stato effettivo di “inattivo”. Tuttavia, quando la data corrente del sistema diverrà il 27 gennaio 2004, allora la riga di meta-dati datata “18.01.2004” diventerà una riga storica e la riga datata “27.01.2004” vedrà cambiare il proprio stato effettivo da “inattivo” ad “attivo”.

Tabella 1: Righe con le rispettive date effettive

I mart di meta-dati

Un mart di meta-dati è una struttura di database, normalmente derivante da un repository di meta-dati, progettata ad uso di un gruppo omogeneo di utenti dei meta-dati (vedi Figura 9). ?Gruppo omogeneo di utenti dei meta-dati? è una definizione generica di un gruppo di utenti che abbia necessità simili.

Esistono due ragioni che spiegano perché un MME debba avere una serie di mart di meta-dati. In primo luogo, una particolare comunità di utenti può richiedere che i meta-dati di proprio interesse siano organizzati in maniera diversa rispetto a quanto previsto per i componenti del repository dei meta-dati. In secondo luogo, un MME con una base di utenti estesa spesso è affetto da problemi di performance a causa del gran numero di collegamenti tra le tabelle, richieste per i report dei meta-dati. In queste situazioni, la cosa migliore è creare una serie di mart di meta-dati orientati specificatamente a soddisfare le esigenze dei diversi gruppi di utenti. I mart di meta-dati non avranno problemi di degrado delle performance perché saranno modellati in maniera multidimensionale. In aggiunta, un meta-mart separato fornisce un livello di buffer tra gli utenti finali e il repository dei meta-dati. Questo consente la manutenzione di routine, gli aggiornamenti, il backup e la recovery del repository senza impattare la disponibilità del mart dei meta-dati.

Il livello di consegna dei meta-dati

Il livello di consegna dei meta-dati è il sesto ed ultimo componente dell’architettura MME. Consegna i meta-dati agli utenti a partire dal repository dei meta-dati e alimenta ogni applicazione o strumento autorizzati alla richiesta di meta-dati (Figura 10).[1]

[1] Vedi il Capitolo 10 di “Building and Managing the Meta Data Repository” (David Marco, Wiley 2000) per una discussione dettagliata sui consumatori di meta-dati e sui problemi della loro consegna.

Le situazioni più comuni di richiesta di meta-dati a partire da un MME riguardano:

• Applicazioni
• Data warehouse e data mart
• Utenti finali (business o tecnici)
• Messaggi e transazioni
• Mart di meta-dati
• Strumenti software
• Terze parti
• Siti Web ed e-commerce

Applicazioni

Abbastanza spesso le applicazioni di tipo CRM (Customer relationship management), ERP (Enterprise resource planning) e altre debbono ricevere meta-dati dall’MME per le loro elaborazioni. In queste situazioni, normalmente viene creato un file di estrazione dal repository dei meta dati che viene reso disponibile per l’applicazione che viene reso disponibile per l’applicazione che lo abbia richiesto. Tipicamente, il repository genererà un semplice file all?interno di un’area di parcheggio, che verrà poi letto dall’applicazione quando ne avrà bisogno.

Data warehouse e data mart

Il livello di consegna dei meta-dati del data warehouse e dei data mart associati (normalmente le interrogazioni e i report vengono elaborati al livello dei data mart) è separato dalle applicazioni a causa di una sottile differenza nell’uso dei meta-dati. La Figura 11 mostra il processo di trasferimento dei meta-dati dall’MME, a fronte di interrogazioni e di creazione di report. Tipicamente l’accesso ai data mart avviene tramite strumenti di front-end (Business Objects, Cognos, Hyperion, Microstrategy e simili). Questi strumenti generano una codifica SQL. Ora, poiché il componente del repository dei meta-dati è memorizzato all’interno di un database relazionale aperto, è abbastanza semplice “puntare” con questi strumenti agli indici del repository e trasferire il meta-dato direttamente nell’applicazione di interrogazione o utilizzarlo per la creazione di un report (per un esempio, vedi Figura 11).

Per alcune applicazioni, per le quali il numero dei meta-dati nel data mart risulti molto voluminoso oppure che abbiano un alto numero di utenti finali, il sovraccarico di lavoro necessario per accedere a un database separato può creare tempi di ritardo alla risposta troppo penalizzanti per gli utenti. Questi problemi di implementazione possono essere risolti caricando i meta-dati direttamente all’interno dei data mart (Figura 12) durante il ciclo di caricamento dei mart.

Il livello di integrazione dei meta-dati

Il livello d’integrazione dei meta-dati (Figura 6) accede alle diverse fonti di meta-dati, li integra e li carica nel repository dei meta-dati stessi. Questo approccio differisce leggermente dalle tecniche più comuni usate per caricare i dati all’interno di un data warehouse, poiché quest’ultimo separa nettamente il processo di trasformazione (che noi chiamiamo integrazione) da quello di caricamento. In un MME le due fasi sono combinate perché, in quest’ultimo, il volume dei meta-dati è molto diverso da quello dei dati di un data warehouse. Come regola generale, l’MME mantiene da 5 a 20 gigabyte di meta-dati; tuttavia, poiché gli MME stanno cercando di indirizzare anche meta-dati relativi alla verifica dei meta-dati già contenuti, la memoria necessaria può crescere nel range dei 20-75 gigabite ed entro i prossimi cinque anni vedremo che alcuni MME raggiungeranno l’ordine dei terabyte.

 Le fasi specifiche all’interno di questo processo dipendono dal fatto che stiate costruendo un processo personalizzato oppure che utilizziate uno strumento di integrazione dei meta-dati per assistervi in tale compito. Se decidete di usare uno strumento di integrazione dei meta-dati, la scelta di quest’ultimo impatterà grandemente sull’intero processo.

Repository dei meta-dati

Repository dei meta-dati è una definizione forse non molto chiara per un database progettato per raccogliere, mantenere e distribuire meta-dati. Il repository dei meta-dati (Figura 7) è responsabile per la catalogazione e memorizzazione durevole dei meta-dati

 Il repository dei meta-dati deve essere generico, integrato, aggiornato e storico. Generico significa che il modello dei meta-dati mira a memorizzare i meta dati ordinati per soggetto, invece che specificatamente per le applicazioni. Ad esempio, un meta-modello generico avrà un attributo denominato “DATABASE_PHYS_NAME” che conterrà i nominativi dei database fisici esistenti all’interno dell’impresa. Un meta-modello specifico per un’applicazione indicherà il medesimo attributo come, ad esempio, “ORACLE_PHYS_NAME”. Il problema con i meta-modelli specifici per le applicazioni è che le aree dei soggetti di riferimento dei meta-dati possono cambiare. Per tornare al nostro esempio, oggi Oracle potrebbe essere il nostro database standard. Domani, invece, potremmo passare ad un Server SQL come nuovo standard, ritenuto più vantaggioso in termini di costo e di compatibilità. Questa situazione causerebbe modifiche addizionali al meta-modello fisico, altrimenti non necessarie.[1]

Un repository dei meta-dati fornisce anche una visione integrata delle maggiori aree dei soggetti relativi ai meta-dati dell’impresa. Il repository consentirà agli utenti di vedere tutte le entità esistenti all’interno di quest’ultima e non solamente quelle caricate in Oracle, oppure quelle che si trovano unicamente nelle applicazioni CRM (Customer Relationship Management).

In terzo luogo, il repository dei meta-dati contiene i meta-dati attuali e quelli che verranno aggiunti in futuro. Questo significa che i meta-dati vengono aggiornati periodicamente per riflettere gli ambienti tecnici e di business attuali e futuri. Ricordate che il repository dei meta-dati deve essere necessariamente aggiornato per mantenere il suo valore reale.

Infine, i repository dei meta-dati hanno un grande valore storico. Un buon repository manterrà la visione storica dei meta-dati anche se questi si modificano nel tempo. Questo consente all’impresa di mantenere la conoscenza dell’evoluzione della propria attività nel tempo. Si tratta di un aspetto specialmente critico se l’ambiente MME supporta un’applicazione che contiene dati storici, come un data warehouse o un’applicazione CRM. Ad esempio, supponiamo che la definizione di “cliente” per un meta-dato di business sia “chiunque abbia comprato un prodotto della nostra società in uno dei nostri negozi o direttamente dal nostro catalogo”. Un anno dopo, la società aggiunge un nuovo canale di distribuzione. La società costruisce un sito web per consentire ai clienti di ordinare direttamente i prodotti. A questo punto, la definizione del meta-dato che indica il cliente sarà modificata in “chiunque abbia comprato un prodotto della nostra società in uno dei nostri negozi, tramite ordine postale dal catalogo o tramite il web”. Un buon repository dei meta-dati mantiene entrambe queste definizioni perché sono tutte e due valide, in base a quali dati verranno analizzati (oltre che in base alla loro età). Per concludere, si raccomanda fortemente di implementare il proprio repository di meta-dati su di una piattaforma di database relazionale aperto, invece di utilizzare un database proprietario.

Livello di gestione dei meta-dati

Il livello di gestione dei meta-dati fornisce una gestione sistematica del repository dei meta-dati e degli altri componenti MME (vedi Figura 8). Come per gli altri livelli, l’approccio a questo componente differisce notevolmente nel caso in cui lo strumento di integrazione dei meta-dati utilizzato per l’intero ambiente MME sia di tipo proprietario. Se uno strumento di integrazione dei meta-dati dell’impresa viene usato per la costruzione dell’MME, allora l’interfaccia di gestione dei meta-dati è verosimilmente inserita all’interno del prodotto. Questo non avviene quasi mai; tuttavia, se non è costruito all’interno del prodotto, allora dovrete realizzarlo in casa. Il livello di gestione dei meta-dati assicura le seguenti funzioni:

· Archivio

· Backup

· Modifiche del Database

· Messa a punto del Database

· Gestione dell’ambiente

· Schedulazione delle attività

· Statistiche di carico del sistema

· Depurazione dei dati

· Statistiche delle interrogazioni

· Generazione di interrogazioni e di report

· Recovery

· Processi di security

· Mappatura e movimentazione delle fonti

· Gestione dell’interfaccia utente

· Gestione delle versioni

[1] Per vedere diversi modelli di meta-dati fisici, vedi Capitoli 4 – 8 di “Universal Meta Data Models” (David Marco & Michael Jennings, Wiley 2004)

Archivio

La funzione Archivio consente all’architetto dei meta-dati di stabilire il criterio o l’evento che attiva il processo di archiviazione all’interno dell’MME. Tale funzione deve essere in grado di archiviare tutti i meta-dati all’interno del loro repository e dei data mart collegati, oltre a consentire l’archiviazione, quando necessario, di tabelle di meta-dati specifiche.

Backup

La funzione di backup spesso viene confusa con l’archiviazione. L’archiviazione riguarda la memorizzazione delle versioni più vecchie e meno utilizzate dell’MME, mentre il backup è il processo che assicura la memorizzazione dell’MME corrente in un database separato, in modo che se la versione dell’MME in produzione risulta errata oppure un suo componente non opera correttamente, una versione di backup possa essere attivata immediatamente on line. Spesso, la strategia di backup viene implementata al livello dell’hardware mediante la duplicazione (mirroring) dei dischi. Le migliori pratiche in quest’area comprendono la memorizzazione della copia di backup in una locazione fisica diversa da quella dell’MME in produzione.

Modifiche al database

Dal momento che il meta-modello è implementato in un database aperto e relazionale, spesso le tabelle e le colonne di dati all’interno del meta-modello debbono essere modificate o cancellate. Il livello di gestione dei meta-dati ha bisogno non solamente di assistenza in questo processo, ma anche di riconoscere i cambiamenti effettuati nell’MME.

Messa a punto del database

La messa a punto del repository dei meta-dati e dei data mart associati rappresenta una parte molto importante nell’ambito del livello di gestione dei meta-dati. In primo luogo, l’identificazione degli indici assicura che i report siano prodotti in maniera efficiente. Nell’analizzare le strutture del meta-modello fisico, normalmente vengono esaminati gli indici come chiavi di accesso primarie. Questo è segno di una strategia di indicizzazione inadeguata o mancante.

In secondo luogo, la messa a punto del database vi aiuta a identificare i meta-dati dormienti all’interno del repository. Un MME di grandi dimensioni, in uso anche da pochi anni, normalmente contiene una larga parte di meta-dati dormienti. Un MME ottimizzato conterrà i meta-dati che consentono le misurazioni statistiche operative sull’ dei meta-dati nell’ambito dell’MME, in modo da permettere l’identificazione dei meta-dati inutilizzati da tempo.

Gestione dell’ambiente

Molti specialisti dei meta-dati commettono l’errore di credere che quando implementano un MME, stiano implementando e mantenendo un solo sistema. In verità, stanno costruendo e mantenendo tre (o forse più) sistemi:

• Produzione
• Test
• Sviluppo

La versione di produzione dell’MME è il sistema definibile come ambiente di produzione? di un’organizzazione, oltre ad essere la versione dell’MME cui hanno accesso gli utenti finali. L’ambiente di test è la versione utilizzata per verificare la correzione dei “bachi” di sistema trovati nella versione di produzione dell’MME. La versione di sviluppo dell’MME è utilizzata per sottoporre a test i futuri e maggiori miglioramenti dell’MME.

La definizione e le dimensioni degli ambienti MME sono diversi a seconda degli standard IT interni all’organizzazione; tuttavia, i tre ambienti menzionati sopra sono i più comuni. In ogni evento, un livello di gestione dei meta-dati può gestire un numero qualsiasi di ambienti e nomi, in base alle necessità dell’organizzazione. La porzione di gestione dell’ambiente del livello di gestione dei meta-dati ha comunque bisogno di organizzare e controllare la gestione e la migrazione dei dati tra queste tre versioni di sistema.

Schedulazione delle attività

Le attività relative ai programmi ed ai processi necessari che debbono essere eseguiti per caricare l’MME e per accedere ai meta-dati contenuti debbono essere schedulate e gestite. La porzione dedicata a questa funzione del livello di gestione dei meta-dati è responsabile della loro schedulazione sia in relazione al verificarsi di determinati eventi che in termini di attivazione di elaborazioni batch.

Statistiche di carico del sistema

I livelli di estrazione e di integrazione dei meta-dati dell’MME generano un gran numero di interessanti statistiche relative al carico di lavoro del sistema. Queste statistiche di carico dell?MME debbono essere conservate nella sezione storica all’interno della porzione dell’MME definita come repository. Alcuni esempi delle statistiche di carico più comuni comprendono:

• Quanto tempo di elaborazione assorbe un particolare passo di un processo (tempo di clock oppure di CPU)?
• Quanto tempo viene impiegato complessivamente dalle elaborazioni relative ai livelli di estrazione e di integrazione dei meta-dati (sia clock che CPU)?
• Quali errori sono stati incontrati nell’ambito dei livelli di estrazione e di integrazione dei meta-dati?
• Quali erano le categorie di errori rilevati (ad es., di informazione, di allerta, gravi, critici, ecc.)
• Quante righe sono state inserite, modificate o cancellate in ciascuna tabella del meta-modello?

Depurazione dei dati

Questa parte del livello di gestione dei dati definisce I criteri relativi alle necessità di depurazione dei dati. I vostri criteri e necessità specifiche di depurazione dei dati saranno governati dalle necessità dell’impresa. Come regola generale, un meta-dato che risulti non corretto o caricato erroneamente deve essere eliminato; tutti gli altri meta-dati debbono essere archiviati.

Statistiche delle interrogazioni

Una volta generati i vari report relativi al livello di consegna dei meta-dati, è importante ottenere le statistiche associate all’accesso a questi report e interrogazioni da parte degli utenti. Come minimo, il livello di gestione dei meta-dati deve poter accedere ai seguenti dati storici:

• Chi ha avuto accesso al report o all’interrogazione?
• Quali report o interrogazioni sono stati interessati?
• Quando è avvenuto l’accesso al report o all’interrogazione?
• Con quale frequenza avvengono gli accessi al report o all’interrogazione
• Quanto dura l’accesso al report o all’interrogazione?

Generazione di interrogazioni e di report

I report e le interrogazioni utilizzate nell’ambito del livello di consegna dei meta-dati sono definiti e generati nella sezione di generazione dei report, all’interno del livello di gestione dei meta-dati. Come questo avvenga dipende dal fatto che sia stato implementato uno strumento di accesso ai meta-dati oppure che sia stata sviluppate un’applicazione proprietaria di consegna dei meta-dati agli utenti. Questo componente deve anche gestire qualunque funzione di pubblicazione o di sottoscrizione che venga richiesta.

Recovery

Esistono molte situazioni che possono costringere un’impresa a un’azione di ripristino e ricaricamento di una versione precedente del proprio MME: ad es.malfunzioni hardware, errori nel database, black out elettrici o errori all’interno del livello di gestione dei meta-dati. Il processo di recovery deve essere strettamente collegato alle funzioni di backup e di archiviazione del livello di gestione dei meta-dati. I processi di recovery possono essere realizzati ad hoc oppure possono utilizzare quelli già predisposti all’interno degli strumenti di integrazione dei meta-dati. Entrambi gli approcci debbono essere integrati all’interno delle applicazioni relative ai processi di recovery già esistenti nell’organizzazione

Processi di security

I processi di security gestiscono:

• Creazione di nuovi utenti dell’MME
• Raggruppamento degli utenti dell’MME
• Registrazione dei privilegi e dei profili degli utenti dell’MME
• Firewall/Infrastruttura
• Gestione delle password
• Verifica della locazione degli utenti
• Mascheramento dei meta-dati (livello dati o livello di accesso)

L’estensione dei processi di security dipende dalle necessità dell’impresa che ha realizzato l?MME. Ad esempio, le necessità di sicurezza degli MME del Dipartimento della Difesa oppure del Federal Bureau of Investigation (FBI) sono sicuramente maggiori di quelle di una banca.

Mappatura e movimentazione delle fonti

Le fonti di meta-dati debbono essere mappate con i corretti attributi ed entità del repository dei meta-dati. Questo processo di mappatura e movimentazione deve essere inserito e gestito nell’ambito del livello di gestione dei meta-dati dell’MME.

Gestione dell’interfaccia utente

Questo è il processo che consente di costruire, gestire e mantenere il sito Web (ovvero l’interfaccia utente raccomandata), che l’utente finale visiterà navigando all’interno dell’MME. Tipicamente, la schermata (versione del sito Web) che viene presentata all’utente dipende dal suo profilo e dai suoi privilegi di security. Un utente generico dell’impresa non sarà interessato a vedere le modifiche delle codifica dei programmi, per cui avrà senso non presentargli report o interrogazioni relativi meta-dati di valore esclusivamente tecnico, in base a un corretto controllo del suo ruolo aziendale.

Gestione delle versioni

Nel momento in cui un meta-dato venga modificato, aggiunto o cancellato è importante per il livello di gestione dei meta-dati mantenere una traccia storica (definita versione) del suo cambiamento di stato. Esistono due tecniche usate comunemente per mantenere traccia delle versioni dei meta-dati. La prima è basata sull’utilizzo della data. In altri termini, ad ogni riga di entità del vostro modello di meta-dati viene assegnata una data, in modo che in caso di modifiche successive si possa sempre risalire al dato storico.

La seconda tecnica consiste invece nell’assegnare un numero progressivo di versione ad ogni riga del modello dei meta-dati. I numeri di versione sono dei valori univoci (ad es., 1.1, 1.2, 1.a, ecc.). I numeri di versioni sono più limitativi delle date, che offrono una migliore visibilità agli utenti dell’MME. Per altro, i numeri di versione possono essere associati a date e valori temporali specifici, una soluzione che però aggiunge ulteriore complessità al caricamento dei meta-dati e un’aggiunta di carico negli accessi per richieste di dati o elaborazione di report.

Un’altra opportunità offerta dalla gestione delle versioni è la cattura di meta-dati che debbano essere inseriti nell’MME in un determinato momento futuro. Ad esempio, una nuova tabella fisica può essere spostata nell’ambiente di produzione in una data futura. Per gestire queste situazioni di cambiamento delle versioni, può risultare utile l’uso delle “righe con data effettiva”. Le righe con data effettiva costituiscono un processo che consente di inserire i dati in un gruppo (tabella) per una elaborazione successiva allo scadere della data indicata. I dati di questo tipo possono essere storici, attuali o futuri. Qui sotto elenchiamo i concetti fondamentali relativi alle righe con data:

Data effettiva. La data alla quale la riga di meta-dati diviene effettiva; la data in cui può essere sottoposta a elaborazione.

Stato effettivo. Consente a un’applicazione di selezionare le righe con le data effettive, in corrispondenza dello scadere della data effettiva (lista dei valori: “attivo” oppure “inattivo”).

Riga corrente.La prima riga di dati con una data effettiva uguale o minore della data di sistema e con uno stato effettivo “attivo”. Solo una riga può trovarsi in questo stato.

Riga futura. Righe di meta-dati che posseggono una data futura rispetto a quella del sistema.

Riga storica. Righe di meta-dati che hanno una data effettiva minore di quella della riga corrente.

La Tabella 1 illustra la tecnica delle righe con data effettiva. In questo esempio, la data corrente del sistema è il 20 gennaio 2004. La riga di meta-dati datata “27.01.2004” ha uno stato effettivo di “inattivo”. Tuttavia, quando la data corrente del sistema diverrà il 27 gennaio 2004, allora la riga di meta-dati datata “18.01.2004” diventerà una riga storica e la riga datata “27.01.2004” vedrà cambiare il proprio stato effettivo da “inattivo” ad “attivo”.

Tabella 1: Righe con le rispettive date effettive

I mart di meta-dati

Un mart di meta-dati è una struttura di database, normalmente derivante da un repository di meta-dati, progettata ad uso di un gruppo omogeneo di utenti dei meta-dati (vedi Figura 9). Gruppo omogeneo di utenti dei meta-dati? è una definizione generica di un gruppo di utenti che abbia necessità simili.

Esistono due ragioni che spiegano perché un MME debba avere una serie di mart di meta-dati. In primo luogo, una particolare comunità di utenti può richiedere che i meta-dati di proprio interesse siano organizzati in maniera diversa rispetto a quanto previsto per i componenti del repository dei meta-dati. In secondo luogo, un MME con una base di utenti estesa spesso è affetto da problemi di performance a causa del gran numero di collegamenti tra le tabelle, richieste per i report dei meta-dati. In queste situazioni, la cosa migliore è creare una serie di mart di meta-dati orientati specificatamente a soddisfare le esigenze dei diversi gruppi di utenti. I mart di meta-dati non avranno problemi di degrado delle performance perché saranno modellati in maniera multidimensionale. In aggiunta, un meta-mart separato fornisce un livello di buffer tra gli utenti finali e il repository dei meta-dati. Questo consente la manutenzione di routine, gli aggiornamenti, il backup e la recovery del repository senza impattare la disponibilità del mart dei meta-dati.

Il livello di consegna dei meta-dati

Il livello di consegna dei meta-dati è il sesto ed ultimo componente dell’architettura MME. Consegna i meta-dati agli utenti a partire dal repository dei meta-dati e alimenta ogni applicazione o strumento autorizzati alla richiesta di meta-dati (Figura 10).[1]

[1] Vedi il Capitolo 10 di “Building and Managing the Meta Data Repository” (David Marco, Wiley 2000) per una discussione dettagliata sui consumatori di meta-dati e sui problemi della loro consegna.

Le situazioni più comuni di richiesta di meta-dati a partire da un MME riguardano:

• Applicazioni
• Data warehouse e data mart
• Utenti finali (business o tecnici)
• Messaggi e transazioni
• Mart di meta-dati
• Strumenti software
• Terze parti
• Siti Web ed e-commerce

Applicazioni

Abbastanza spesso le applicazioni di tipo CRM (Customer relationship management), ERP (Enterprise resource planning) e altre debbono ricevere meta-dati dall?MME per le loro elaborazioni. In queste situazioni, normalmente viene creato un file di estrazione dal repository dei meta dati che viene reso disponibile per l’applicazione che viene reso disponibile per l?applicazione che lo abbia richiesto. Tipicamente, il repository genererà un semplice file all?interno di un’area di parcheggio, che verrà poi letto dall’applicazione quando ne avrà bisogno.

Data warehouse e data mart

Il livello di consegna dei meta-dati del data warehouse e dei data mart associati (normalmente le interrogazioni e i report vengono elaborati al livello dei data mart) è separato dalle applicazioni a causa di una sottile differenza nell’uso dei meta-dati. La Figura 11 mostra il processo di trasferimento dei meta-dati dall’MME, a fronte di interrogazioni e di creazione di report. Tipicamente l’accesso ai data mart avviene tramite strumenti di front-end (Business Objects, Cognos, Hyperion, Microstrategy e simili). Questi strumenti generano una codifica SQL. Ora, poiché il componente del repository dei meta-dati è memorizzato all’interno di un data

base relazionale aperto, è abbastanza semplice “puntare” con questi strumenti agli indici del repository e trasferire il meta-dato direttamente nell’applicazione di interrogazione o utilizzarlo per la creazione di un report (per un esempio, vedi Figura 11).

Per alcune applicazioni, per le quali il numero dei meta-dati nel data mart risulti molto voluminoso oppure che abbiano un alto numero di utenti finali, il sovraccarico di lavoro necessario per accedere a un database separato può creare tempi di ritardo alla risposta troppo penalizzanti per gli utenti. Questi problemi di implementazione possono essere risolti caricando i meta-dati direttamente all?interno dei data mart (Figura 12) durante il ciclo di caricamento dei mart.