Note di Data Warehouse e Business Intelligence - Tecniche di Naming Convention (parte 1)

MICRO

ETL

FOUNDATION

Idee e soluzioni per progetti diData Warehouse e

Business Intelligencein ambiente Oracle

Tecniche di Naming Convention

La naming convention è una componente fondamentale di ogni progetto informatico.L’obiettivo di questo articolo è quello di suggerire uno standard di nomenclaturapratico ed efficace per un progetto di Data Warehouse.(parte 1)

MASSIMO CENCI

MICRO ETL FOUNDATION

Introduzione

In generale, la naming convention è il metodo con cui si decide di assegnare un nome alle varie entità del Database System che si sta progettando. Il focus sarà ,ovviamente, sui sistemi di Data Warehouse, ma le tecniche adottate si possono tranquillamente applicare anche ai sistemi OLTP (On Line Transaction Processing).

Di seguito, il termine «entità» sarà sinonimo di «struttura» intendendo con questo termine genericamente le strutture dati tipiche di un database relazionale come Oracle: tabelle, viste, materialized view (il nome che Oracle utilizza per definire le tabelle aggregate), sinonimi, ecc.

L’applicazione di un metodo non si deve ritenere una tecnica a sé stante, incentrata sulla particolare entità che si sta analizzando, svincolata dalle logiche e dalla architettura del sistema. Al contrario, essa deve produrre un nome che deve essere in grado di evocare immediatamente tutta la natura semantica delle entità in gioco, poco importa la tipologia di sistema a cui appartengono.

Questa è la chiave di volta del metodo, perché definire una naming convention per una entità non significa semplicemente assegnarle un nome ma significa definirle un contesto architetturale. I nomi scelti, verranno utilizzati nelle discussioni, nelle riunioni, nei documenti, nei deliverables, negli schemi relazionali, e accompagneranno la nostra vita lavorativa per diversi mesi.

Molto presto l’intreccio delle relazioni fra le varie entità, e fra entità e programmi, impedirà qualunque modifica alla nomenclatura, e scelte sbagliate, o nessuna scelta, avranno spiacevoli conseguenze sull’economia dell’intero progetto.


Introduzione

Gli esempi esposti si focalizzano principalmente sulle tabelle, perché, in pratica, tutto il lavoro che si svolge all’interno del processo di caricamento dati, è finalizzato al riempimento di tali entità.

Come sappiamo, le tabelle sono il componente base del modello dati. Se si deve prendere in carico, visionare o modificare un Data Warehouse esistente di cui la documentazione è limitata o la si trova obsoleta, solo il suo modello dati, estratto dalle strutture interne del RDBMS (Relational Database Management System), potrà esserci di aiuto.

Proprio in questi casi l’efficacia della naming convention si manifesta chiaramente: provate a pensare al tempo necessario per acquisire la conoscenza del sistema nel momento in cui tutte le entità, magari centinaia, non hanno seguito uno standard o lo hanno seguito solo in parte o in modo ambiguo.

Lo scopo di queste tecniche è anche quello di evitare queste situazioni, per noi,e per i nostri interlocutori.


Le linee guida

La naming convention non solo è importante, ma è una necessità prioritaria. Essa deve essere valutata nelle prime fasi del ciclo di vita di un progetto. Non si può iniziare la fase di design fisico e la fase di sviluppo se non si è già definito lo standard di nomenclatura delle entità che costituiranno il nostro sistema.

Nessuna "create …" sarà possibile senza tali decisioni. Le linee guida che sono alla base delle tecniche sotto esposte sono solamente tre:

1. Il partizionamento logico2. La tipizzazione3. La regola di codifica

Il partizionamento logico permette di definire una struttura gerarchica fra le entità in gioco, la tipizzazione permette di associare alle entità anche una connotazione fisica, la regola di codifica standardizza la nomenclatura che deriva dal partizionamento e dalla tipizzazione.

Poiché il modo migliore per apprendere tali concetti è vederli agire nella pratica, le tre linee guida verranno approfondite nei prossimi paragrafi in cui vedremo come si possono applicare in una realtà progettuale. Concentriamo subito la nostra attenzione sulle entità.


Lo standard di nomenclatura delle entità

Il paradigma che sta alla base della naming convention delle entità può essere riassunto nella seguente formula:

<nome entità> = <codice progetto>_<codice area>_<codice sezione>_<nome logico>_<codice tipo>

Per comprendere la formula, utilizzeremo la prima linea guida, cioè il partizionamento logico. In realtà definirla linea guida è un eufemismo sicuramente riduttivo. In realtà è un momento di riflessione che può essere affrontato solo dopo avere realizzato la nostra visione globale del sistema.

Con il termine partizionamento logico si intende la scomposizione del sistema nelle sue componenti logiche essenziali, cioè le aree e le sezioni. È un approccio molto simile a un drill-down: da una visione generale verso una visione particolare. Si parte dal progetto, che è la root del nostro albero logico, lo si scompone in aree, ogni area la si scompone in sezioni.

Poiché parliamo di Data Warehouse, cosa sono le aree e le sezioni e il modo con cui si esegue il partizionamento logico può basarsi su alcune indicazioni euristiche che coprono, secondo me, l’ 80% dei progetti di tale tipo.

Alcuni di questi concetti sono già stati espressi in un mio articolo “The Hierarchical Model for Data Warehouse Design” [sito www.datawarehouse.com ormai non più attivo]. Qui verrano estesi e descritti nel modo più possibile pragmatico con esempi presi da casi reali.

È necessario sottolineare che le tecniche di naming convention descritte sono comunque di carattere generale, e possono adattarsi a qualunque entità di qualsiasi progetto; l’implementazione di tali principi è invece finalizzata ai sistemi di Business Intelligence. Analizziamo ora i singoli componenti del “<nome entità>”.

http://www.datawarehouse.com/


Il codice progetto

La prima decisione da affrontare in un progetto è assegnargli un codice. Può sembrare un’affermazione ovvia, ma l’identificazione di un codice progetto è una premessa fondamentale per indirizzare il progetto stesso nella giusta direzione. La scelta del codice progetto ha conseguenze immediate e importanti che impattano a diversi livelli. Vediamoli.

Il primo livello impattato è l’architettura logico/fisica del Data Warehouse. Una volta scelto il codice progetto, ogni entità che verrà definita inizierà con quel codice progetto seguito da underscore “_”.

Questo vuol dire che ogni tabella, vista, materialized view, sinonimo, programma, o in genere, qualunque struttura fisica venga creata, dovrà iniziare con “<codice progetto>_”.

Sia che le strutture fisiche siano allocate in un Server/RDBMS dedicato, sia che vengano create in Server o istanze del database già condivise da altri progetti, abbiamo così stabilito un modo univoco per identificare tutti gli oggetti del nostro Data Warehouse (ovviamente non deve esistere un altro progetto con lo stesso codice). Una banale selezione dal dizionario dati del database ci permetterà di identificare solo ed esclusivamente gli oggetti logico/fisici di nostra competenza.

Il secondo livello impattato è quello fisico del file system. Tutte le directory di progetto devono anch’esseiniziare con "<codice_progetto>_". Le directory di ricezione flussi, di invio flussi, o di ogni altro tipo, devono iniziare allo stesso modo. Un altro esempio possono essere le directory dei files del database, degli script di creazione, ecc.

Il terzo livello impattato è quello della documentazione e dei deliverables. Utilizzando anche per essi la stessa tecnica, saremo sicuri di identificare con le nostre search sempre e solo i documenti associati al nostro progetto.


Il codice progetto

A questo punto abbiamo bisogno di una regola di codifica. Se, per esempio, abbiamo definito il progetto come "Enterprise Data Warehouse", non è pensabile utilizzare 25 caratteri come codice progetto.

L'esperienza sulla progettazione di numerosi sistemi di Data Warehouse, ha fornito una indicazione molto chiara. A mio avviso, la migliore regola per identificare il codice progetto è la "regola del tre". Questa regola, suggerisce che il codice progetto deve essere di tre caratteri, acronimo del nome descrittivo che, in fase di analisi, è stato associato a quel progetto.

Nell’esempio in questione, un buon acronimo, e quindi il codice progetto, sarà "EDW". Se stiamo progettando un Data Warehouse di Exploration e Production di una società petrolifera, un buon codice progetto sarà "EPD".

Come si sa, tre è il numero perfetto, e nella identificazione delle codifiche da utilizzare, questa perfezione si è manifestata chiaramente in tutti i suoi aspetti. Due caratteri causano ambiguità e incomprensione, quattro caratteri o più possono risultare eccessivi.

Poiché tre è il numero perfetto, tale regola sarà applicata anche alle altre codifiche. Si parte quindi con il codice progetto "EDW".


Il codice area

Le aree sono un modo per effettuare un primo partizionamento logico degli oggetti del nostro Data Warehouse.

Suddividere tutti gli oggetti in aree di appartenenza, permette di associare in un unico scope tutti gli oggetti con una certa valenza logico/temporale.

Per comprendere bene le aree, si devono esprimere alcuni principi di datawarehousing, e in particolare, alcuni aspetti del processo ETL (Extract, Trasform and Load). Tali principi saranno semplificati il più possibile per garantire una comprensione anche a chi affronta per la prima volta tali tematiche.

Ovviamente esiste una letteratura molto ampia in materia a cui rimando per ulteriori approfondimenti. Diamo quindi una breve descrizione eella struttura del processo ETL.

Il processo ETL

I processi di caricamento che caricano le tabelle del Data Warehouse, seguono in genere un workflow del tipo seguente.

Giungono i flussi (files) di alimentazione dai sistemi alimentanti esterni. Tali sistemi possono essere di qualunque tipo (OLTP, altri Data Warehouse, Operational Data Store, ecc) e i files possono essere di qualunque formato (file ascii a lunghezza fissa, con terminatore, XML, ecc).

I dati contenuti in tali flussi, vengono caricati in tabelle di lavoro, definite di Staging. Queste tabelle sono quasi sempre un’immagine strutturata pressochè identica del flusso. I flussi sono principalmente flussi anagrafici e flussi dati.


Il codice area

Dopo che le tabelle di Staging sono state caricate, il processo prosegue con il caricamento delle tabelle successive, che sono chiamate fact table cioè tabelle dei fatti di base o di livello 0 (i fatti non sono altro che i dati numerici). Tale processo ha il compito di eseguire tutte le operazioni di pulizia e controllo sui dati in Staging, definire le chiavi artificiali per le tabelle dei fatti, e quindi caricare i dati “dimensionalizzati”. Con questo termine si intende la visione dimensionale dei dati espressa come una tabella dei fatti e le rispettive dimensioni di analisi che compongono quello che viene definito lo star-schema.

Dopo il caricamento delle tabelle dei fatti di livello 0, può esserci il caricamento di tabelle aggregate (per migliorare le performance di lettura dei dati da parte della reportistica) o di tabelle dei fatti di livello superiore (1,2,.. N) a seconda della complessità e delle esigenze del Data Warehouse.

Un tipico esempio in ambito GDO (Grande Distribuzione Organizzata) può essere la tabella di livello 0 che memorizza i dati del venduto dei negozi e quella dei costi associati agli articoli di vendita. Da queste tabelle dei fatti si può caricare una tabella dei fatti di livello 1, in cui si perdono alcune dimensioni di analisi e si mettono a confronto i fatti di venduto con i fatti dei costi per ottenere il margine netto o lordo.

Tutto il processo che carica i dati che arrivano dai flussi fino al caricamento di tutte le altre strutture viene definito processo ETL. Possono esserci ovviamente delle varianti a questo workflow, ma si può affermare che quasi tutti i progetti di Data Warehouse si adeguano a questa processo.

Dopo questo breve parentesi, torniamo al discorso lasciato in sospeso, cioè al collegamento del processo ETL con il nostro standard di nomenclatura. Il partizionamento delle entità che faremo infatti, è proprio incentrato sul processo descritto in precedenza.


Il codice area

Con il partizionamento delle entità si possono identificare le seguenti aree logiche:

• Area di Staging: in questa area ci sono tutte le entità che accolgono i dati contenuti nei flussi che giungono dai sistemi esterni.

• Area dei data mart di livello 0: in questa area ci sono tutte le entità che contengono i dati di base definitivi, puliti e dimensionalizzati dal processo di caricamento.

• Area dei data mart di livello 1 (e livelli successivi): in questa area ci sono le entità di livello superiore che vengono alimentate dalle entità di livello 0.

• Area comune: in questa area ci sono tutte le tabelle dimensionali (in pratica le anagrafiche con associata la chiave artificiale) e tutte quelle entità che sono comuni a tutto il processo, come tabelle di configurazione, di servizio, ecc.

Ovviamente si possono identificare anche altre aree. Per esempio possiamo identificare un’area chiamataOperational Data Store in cui sono presenti tutte le strutture dati normalizzate e non strutturate secondo il modello dimensionale, oppure possiamo identificare un’area di informazioni esclusivamente infrastrutturali, legata al log dei programmi e delle schedulazioni.

Insomma, le possibilità sono varie, e sarà nostra cura rifletterci con attenzione.

Il passo successivo è quindi quello di codificare con la “regola del tre” tutte le aree che abbiamo identificato. Usando acronimi molto intuitivi, come STA, DM0, DM1, COM otteniamo quanto indicato in Figura.


Il codice area

COM (Common entities)

Area

STA

(Staging and temporary

entities)

Area

ODS

(OperationalData

Store)

Area

DM0

(Level 0DataMart)

Area

DM1

(Level 1DataMart)

Project EDW (Enterprise Data Warehouse)

Area


Il codice area

Come si può notare, gli effetti della naming convention cominciano a prendere corpo e già a questo livello, ancora alto, si possono identificare facilmente tutte le entità con una appartenenza logica comune.

Se voglio sapere i nomi di tutte le entità che raccolgono i dati dai flussi di alimentazione, basta estrarre dal dizionario dati tutti i tipi di oggetto che iniziano con “EDW_STA_”.

Se voglio identificare tutte le tabelle dei fatti di livello 1, cercherò dal dizionario dati i tipi di oggetto che iniziano con “EDW_DM1_”.

Nella pratica, questo primo processo di partizionamento fornisce una visione ancora troppo ad alto livello. In Data Warehouse di tipo Enterprise, dove il numero delle entità è elevato, è opportuno partizionare ulteriormente le aree in sezioni o sottoaree.

Ogni area quindi dovrà essere decomposta in elementi più piccoli, che approfondisco e arricchiscono la conoscenza delle strutture del Data Warehouse.


Il codice sezione (sottoarea)

Le sezioni permettono di raggruppare ulteriormente in modo logico tutte le entità che appartengono alle varie aree. Ogni area ha delle caratteristiche specifiche, per cui anche il processo di partizionamento delle aree in sezioni è specifico di ogni singola area.

Ovviamente ogni progettista può definire le sezioni come ritiene opportuno basandosi sulla propria esperienza e inventiva. Le sezioni che ora saranno descritte per le aree definite in precedenza, sono quelle basate sulla mia personale esperienza e sono comunque un suggerimento per chi affronta per la prima volta un progetto di Data Warehouse. Vediamole in dettaglio.

Le sezioni dell’area di staging

Riprendendo l’esempio dei flussi dati di alimentazione al Data Warehouse, spesso i sottosistemi di produzione dei flussi possono essere vari, ognuno generante diversi flussi. Se per esempio, abbiamo tre sottosistemi di alimentazione, Negozi di vendita, Movimenti logistici e Contabilità, l’approccio che si può seguire è il seguente:

Codifichiamo con la regola del tre i sottosistemi esterni, per esempio i negozi di vendita con STO (Store), i movimenti di logistica con MOV (Movements) e la contabilità con PLS (Profit and Loss) Ogni entità legata a tali sottosistemi dovrà avere questi codici all’interno del suo nome. Se si vogliono conoscere i nomi di tutte le tabelle di Staging Area alimentate dai flussi di alimentazione del Sottosistema di logistica, basta estrarre dal dizionario dati tutte le entità che iniziano con “EDW_STA_MOV_”.

La prossima sezione da descrivere è quella dei Data Mart di livello 0. Poiché il concetto di Data Mart è fondamentale in un progetto di Data Warehouse, sarà opportuno aprire un’altra parentesi di principi di datawarehousing e darne una definizione precisa per comodità di comprensione della Naming convention che ne fa uso.


Il Data Mart

Il data mart è un “logical subset of the complete data warehouse” come indicato da R.Kimball nel suo libro[The Data WarehouseLifecycle Toolkit “, Wiley,1998]. Ogni data mart è di solito organizzato intorno a un singolo processo di business e l’unione di tutti i data mart costituisce il Data Warehouse.

Quindi le sezioni dell’area DM0, saranno specifiche del processo di business che si sta implementando. È da sottolineare un errore comune, in cui si fanno coincidere concettualmente la tabella dei fatti con il data mart.

Il data mart è un concetto logico, la tabella dei fatti è solo una componente della implementazione fisica di quel concetto logico. In realtà il data mart è costituito da una tabella dei fatti e da tutte le sue tabelle aggregate o viste materializzate che vengono create per incrementare le performance della reportistica associata a quell’area di business.

Ovviamente le strutture aggregate non sono un obbligo, ma sono una necessità per i VLDW (Very Large Data Warehouse), dove la mole di dati trattati può superare i Terabyte. Un data mart che contenesse solo la facttable, magari di numerosi Gigabyte di dati, non sarebbe un Data Mart, sarebbe un problema.

Poiché in un Data Warehouse di medie dimensioni il numero di tabelle aggregate tende ad essere elevato, la naming convention fornisce un aiuto prezioso per identificare immediatamente tutte le strutture datiassociate a una certa processo di business.

Riprendiamo ora il discorso, lasciato interrotto, delle sezioni delle aree.



Le sezioni dell’area dei Data Mart di base

Questa è un area fondamentale, perché in essa trovano spazio tutti i data mart di base, cioè quelli con la granularità informativa di massimo dettaglio.

Il miglior modo per partizionare in sezioni l’area DM0, cioè dei data mart di base (o livello 0), è ovviamente quello di identificare con la regola del tre i vari data mart che la compongono.

Per esempio, se un data mart contiene tutti i dati vendita, un codice opportuno sarà SLS o SAL (abbreviazione di Sales) , se contiene i dati dei costi, potrà essere CST o COS (abbreviazione di Costs)

Le sezioni dell’area DM1

In questa area ed eventualmente in quelle successive, si collocano i data mart il cui contenuto non è immediatamente derivabile da un data mart di livello 0, ma è costituito da dati presi da più data mart di livello inferiore o ottenuti con elaborazioni che non sono riconducibili a banali calcoli di aggregazione.

Facciamo subito due esempi per chiarire il concetto. Come già accennato in precedenza, in ambito Retail associato alla grande distribuzione, è tipico avere un data mart di Profitability, che contiene in una unica struttura dati le informazioni di vendita e di vari tipi di costo che permettono di ottenere il margine netto o lordo.

Il data mart della Profitability è sicuramente un data mart di livello 1, che verrà caricato dai due data mart di livello 0 indicati precedentemente, cioè EDW_DM0_SLS e il EDW_DM0_CST.Si potrà quindi codificare questo data mart della profitability con DW_DM1_PRF o EDW_DM1_PRO.



Un altro esempio è quello legato a dati aggregati che però non sono ottenibili immediatamente con semplici somme o conteggi (perché in quel caso costruiremmo delle semplici viste materializzate).

Se un requirement dell’utente è quello di vedere i dati a livello mensile associati a quelli dello stesso mese dell’anno precedente, sia puntuali che progressivi, una scelta progettuale può essere quella di alimentare, nel processo ETL, un Data Mart che già contenga questi dati aggregati e precalcolati, piuttosto che affidare questo compito al tool di reportistica.

In questo caso il data mart che otteniamo è ottenibile sì da un unico data mart di livello 0, ma il processo sarà sicuramente più complesso e difficilmente riproducibile con una semplice struttura aggregata.

Si può codificare questo Data Mart come EDW_DM1_MPY (a indicare un Monthly, con dati Previous year e progressivi da inizio anno, Year to date).

Le sezioni dell’area COM

A questa area associamo tutte le entità che sono comuni all’intero progetto, e non riconducibili a una delle aree già descritte. Esempi tipici di tali sezioni sono i seguenti:

• Sezione CDI (Conformed Dimension). Le dimensioni presenti in un Data Warehouse, non sono specifiche di un certo data mart, ma sono conformi, cioè comuni a molti data mart. Basti pensare alla dimensione tempo, presente praticamente in tutti i data mart di qualunque livello. Sono quindi strutture comuni che possono essere raggruppate in una unica sezione.



• Sezione CFA (Conformed Fact). Concetto analogo al precedente ma applicato alle tabelle dei fatti. Un esempio può essere la tabella di conversione delle valute, chè è una tipica fact table ma globale e utilizzabile da tutto il data warehouse.

• Sezione LOG (Logging). Tutte le strutture associate ai log del processo ETL.

• Sezione MTD (Metadata). Tutte le strutture di Metadati presenti nel Data Warehouse.

La Figura seguente completa quindi il nostro disegno con quanto appena descritto. A questo punto il nostro processo di partizionamento può dirsi concluso.

Ulteriori partizionamenti potrebbero dare scarso valore aggiunto alla conoscenza, oltre ad allungare ulteriormente il nome finale delle varie entità. Anzi, in progetti molto semplici, può essere sufficiente limitarsi al partizionamento a livello di area.



Section

CDI (Conformed Dimensions)

COM (Common entities)Area

STA (Staging and temporary entities)Area

ODS(Operational

DataStore)

AreaDM0 (Level 0Data Mart)Area

DM1 (Level 1Data Mart)

Project EDW (Enterprise Data Warehouse)

Area

Section

CFA (Conformed Facts)

Section

LOG (Elaboration Log)

Section

MTD (Metadata)

Section

STO (Sales and costs)

SectionMOV (Logistic Movements)

Section

PLS (Profit & Loss)

Section

SLS (Sales Data Mart)

Section

CST (Costs Data Mart)

Section

PRO (Profitability Data Mart)

Section

CSM (Cumulative Monthly Sales)


Il nome logico

Possiamo quindi completare il nome delle entità e identificare un nome logico, possibilmente breve, dopo il prefisso appena descritto.

Tornando all’esempio dei flussi alimentanti, se il Sottosistema Profit and Loss mi fornisce l’anagrafica clienti(Customer), il suo nome sarà: EDW_STA_PRL_CUST

Si può notare la ricchezza informativa che scaturisce dal nome di questa entità. In pochi caratteri sappiamo che sono i dati dei clienti forniti dal Sottosistema Profit and Loss, che vengono caricati in una Area di Staging che fa parte del progetto di Data Warehouse EDW.

Non è necessario che il nome logico sia sottoposto alla regola del tre, e, in certi casi, può essere omesso. Nelle aree dei data mart, il prefisso è già sufficientemente esplicativo, e l’aggiunta di un nome logico non darà alcun valore aggiunto alla comprensione del contenuto della sezione.

Infatti, già molto prima del passaggio in produzione, il Data Mart della Profitability esemplificato in precedenza, verrà chiamato “affettuosamente” PRF, e tutti lo riconosceranno citando solo i tre caratteri del codice sezione.


Il codice tipo

A questo punto si potrebbe pensare di avere ottenuto il nostro obiettivo iniziale. Il nome ottenuto seguendo le linee guida della naming convention è semanticamente significativo, e siamo convinti che se avessimo chiamato l’entità semplicemente CUSTOMER o CLIENTI, avremmo perso in conoscenza e contesto.

Purtoppo non è così, perché l’entità EDW_STA_PRL_CUST non ci dice ancora tutto della sua intima natura.Se rivediamo con attenzione la semantica che la naming convention ha dato alla parola EDW_STA_PRL_CUST,scopriamo che vi sono alcune carenze cognitive. È senz’altro chiaro che sono i dati dei clienti forniti dal Sottosistema Profit and Loss, ma non si evince da alcuna parte che è l’anagrafica clienti. Così come non si evince da alcuna parte che è una tabella di dati anagrafici. La tecnica di tipizzazione può aiutarci a colmare queste lacune.

Fra le varie entità che sono presenti all’interno di una sezione di un’area, possono esserci tabelle, ma anche view (viste, cioè la selezione di certe righe e/o di certe colonne di una tabella), sinonimi (cioè alias di tabelle) o altro.

Questa informazione può essere importante, perché ci evita di dover accedere al dizionario dati, a cui forse non abbiamo accesso, per sapere che tipo di struttura abbiamo di fronte. Il fatto non è da sottovalutare perché in molte situazioni, questa informazione, che sembra molto associata alla “fisicità” dell’entità, ha anche un contenuto logico notevole.

Pensiamo per esempio al caso delle fact table e delle materialized view. Le fact table sono le tabelle dei fatti che sono sempre presenti nei progetti di Data Warehouse. Le materialized view sono le tabelle aggregate (dette anche summary table) cioè tabelle che sono generate tipicamente dalle tabelle dei fatti ma che aggregano i dati secondo determinate dimensioni di analisi.


Il codice tipo

È importante saper distinguere immediatamente i due tipi di entità, perché il loro contenuto è differente e anche il loro processo di alimentazione è diverso ed effettuato in momenti diversi.

All’interno dell’area dei data mart di livello 0, ci può essere la sezione che identifica il data mart delle vendite, ma all’interno di questa sezione possono esserci decine di entità, e sapere quante e quali sono le “aggregate”, cioè le materialized view, è una informazione importante per noi e per il Database Administrator.

Con la tipizzazione, questa informazione sarà subito evidente, non solo per una specifica sezione o area, ma anche trasversalmente a tutte le aree. Se decidiamo di tipizzare tutte le materialized view derivate dalle tabelle dei fatti con il codice FMV (Fact Materialized View), tutte le entità il cui nome termina con FMV sicuramente saranno delle tabelle “aggregate”.

Quella che segue è un elenco abbastanza esaustivo di codici e relative descrizioni che sicuramente potrà aiutare nel processo di tipizzazione. Il codice tipo fa riferimento a una traduzione in inglese.

• DAT - Data Table. Generica tabella di dati di contenuto numerico tipica delle Aree di staging. Sono in pratica le tabelle che contengono le metriche, o misure, con i rispettivi codici naturali non ancora artificializzati. Il processo di dimensionalizzazione molto probabilmente le trasformerà in fact table.

• ANT - Anagraphic Table. Generica tabella di dati di contenuto anagrafico tipica delle Aree di staging. Sono in pratica le anagrafiche con i codici naturali e i rispettivi attributi.

• EDT - External Data Table. Flusso di dati di contenuto numerico tipica delle Aree di staging. L’ external table è una caratteristica molto utile di Oracle con cui un flusso viene visto a tutti gli effetti come una tabella. Interrogabile quindi con il linguaggio SQL.

• EAT - External Anagraphic Table. Analoga alla precedente ma con dati di contenuto anagrafico.


Il codice tipo

• EXT - Exception Table. Tabella che contiene tutte le righe che hanno fallito i controlli di integrità di un’altra tabella.

• FAT - Fact Table. Tabella dei fatti generica. Tipicamente contiene fatti a livello transazionale di massimo dettaglio, come i singoli movimenti di conto corrente o le singole righe degli scontrini emessi dalle casse di un supermercato.

• FFT - Factless Fact Table. Tabella dei fatti senza informazioni numeriche. In esse la sola presenza della riga certifica l’avvenimento di un fatto, per esempio la presenza di uno studente a un corso universitario.

• PSF - Periodic Snapshot Fact table. Questo tipo di tabella dei fatti reassume in una unica riga numerosi fatti riassuntivi di una situazione alla fine di un certo periodo di tempo. Tipico esempio è il conto corrente bancario: da esso si può costruire una tabella riassuntiva mensile alimentata dalla fact table di base in cui ci sono i dettagli di ogni singolo movimento bancario effettuato sul conto corrente.

• ASF - Accumulating Snapshot Fact table. Questo tipo di tabella descrive dei processi che hanno un inizio ed una fine non troppo dilazionati sul tempo e in cui una dimensione è ripetuta numerose volte. Tipico esempio sono la storia di un ordine o di una fattura riassunta tutta in una unica riga. Oppure un elenco di date (legate alla dimensione tempo) che rappresentano tutti i cambiamenti di stato di un certo oggetto o di un certo processo.

• FAV - Fact View – Vista parziale dei dati contenuti in una o più fact table • FMV - Fact Materialized View – Vista materializzata costruita su una o più tabelle dei fatti.• FAS - Fact Synonym – Sinonimo di una tabella dei fatti • DIT - Dimensional table – Tabella dimensionale di analisi• DIV - Dimensional View – Vista associate a una tabella dimensionale.• DIM – Dimensione – In Oracle la dimensione non è la tabella dimensionale, ma la struttura logica che ne

descrive il contenuto in termini di livelli gerarchici e attributi associati ai vari livelli.• TMT – Temporary table – Struttura temporaea o di appoggio che viene utilizzata nel processo ETL.


Il codice tipo

• CFT - Configuration table – Tabella generica di informazioni di configurazione• DET – Data Entry Table – Tabella che può essere modificata direttamente dall’utente con un interfaccia

grafica.• AWS - Analytic workspace – Cubo OLAP, cioè struttura dati tipica dei Database multidimensionali.• LOT – Log Table – Tabella che contiene informazioni di log.

Note di Data Warehouse e Business Intelligence - Tecniche di Naming Convention (parte 1)

Technology

Transcript of Note di Data Warehouse e Business Intelligence - Tecniche di Naming Convention (parte 1)