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

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 2)

MASSIMO CENCI

MICRO ETL FOUNDATION

Introduzione

Nella prima parte di queste tecniche, la Naming Convention ha avuto come oggetto privilegiato le tabelle, senz’altro le entità basilari di un sistema informativo.

Abbiamo definito un nome a queste entità nella loro forma più semplice (table), nella loro forma aggregata (materialized view o summary), nella loro forma logica (view).

È stato sottolineato che queste tecniche si possono applicare a qualunque entità logico/fisica presente in un Data Warehouse. Continuerò quindi queste riflessioni avendo in mente tre obiettivi:

• Completezza: le tabelle sono basilari, ma da sole non costituiscono un Data Warehouse. Devono esistere dei diritti di accesso per poterle visualizzare, devono esistere dei programmi per poterle caricare, devono esistere degli indici per velocizzarne l’accesso, devono esistere dei vincoli per garantirne l’integrità. Anche i programmi, diritti, indici e vincoli devono essere creati rispettando la Naming Convention. Senza dimenticare che le tabelle sono fatte di attributi. E anche gli attributi hanno un nome. Ne parleremo.

• Pragmatismo: Solo vedendo applicare le tecniche descritte a un caso reale, se ne apprende appieno l’utilità, quindi esamineremo e daremo un nome anche a tutte le altre entità in gioco, utilizzando il Data Warehouse di esempio.

• Conoscenza: Alcune delle entità che saranno oggetto di naming sono specifiche di Oracle e questa è una buona occasione per poterne dare una breve descrizione.


Introduzione

Le scelte effettuate per la Naming Convention sono solo delle linee guida. Non sono neanche un obbligo. Possono essere discusse e variate secondo le nostre esigenze e la nostra particolare visione del sistema. L'obiettivo principale era quello di porre l'attenzione sulla importanza e l'utilità della Naming Convention.

Un altro punto che desidero sottolineare, è che la convenzione descritta è "Data Base Administator oriented" e non "Business oriented". Significa che i nomi scelti, per esempio, per le tabelle, saranno quelli fisici, e saranno quelli che solo i DBA vedranno. Il resto del mondo non dovrebbe vedere quei nomi, ma dei nomi "logici" cioè filtrati da sinonimi e/o viste.

Sulla base di alcuni utili feed-back ricevuti, (queste tecniche sono pubblicate anche in inglese) desidero chiarire questo punto.


Gli utilizzatori della Naming Convention

Prendiamo come esempio l'entità EDW_COM_CDI_CUST_DIT.

Questa entità rappresenta la tabella dimensionale (DIT) dei clienti (CUST) della sezione delle conformed dimensions (CDI) dell'area comune (COM) a tutte le entità del nostro Data Warehouse (EDW).

Il contenuto di questa entità risulta chiaro a qualunque DBA, anche a quello che, per esempio, eredita la gestione di un Data Warehouse che non conosce. (provate a pensare se la tabella si fosse chiamata A01DWCST).

L'entità EDW_COM_CDI_CUST_DIT è vista e gestita solo dal DBA. Secondo la mia visione, gli unici altri utenti che vedono le entità (e solo quelle che servono, cioè di solito, fatti e dimensioni) sono i costruttori delle Business Areas per mezzo di un modulo di amministrazione che fa parte del tool di front-end (per esempio di Oracle Business Intelligence).

Questi utenti non devono vedere il nome fisico EDW_COM_CDI_CUST_DIT, ma una vista/sinonimo di nome,per esempio, CUSTOMER_DIT. Se abbiamo avuto l'accortezza di rendere univoche le ultime due componenti del nome, il resto del mondo vedrà un nome di entità molto più breve, semplice e vicino alle sue logiche di business.


Gli utilizzatori della Naming Convention

A01DWCST

?

EDW_COM_CDI_CUST_DIT

Senza Naming Convention Con Naming Convention

CUSTOMER_DIT

DBA

Architect


La Naming Convention degli attributi

Come sappiamo dalla teoria dei database relazionali, gli attributi costituiscono un insieme di caratteristiche specifiche delle varie entità che definiscono il modello logico. Poiché abbiamo definito una Naming Convention per le entità, è necessario definire una Naming Convention anche per gli attributi.

Il paradigma che sta alla base della Naming Convention degli attributi può essere riassunto nella seguente formula:

<nome attributo> = <nome logico>_<codice tipo>

Per essi il nome è molto semplificato perché il loro contesto logico è già strutturalmente definito dalla entità di cui fanno parte. È sufficiente la tipizzazione.

Nelle tabelle del dizionario dati di un RDBMS come Oracle, è possibile individuare tutti gli attributi e le loro tabelle associate. Quindi un efficace standard di nomenclatura sarà molto utile nelle ricerche di tutti gli attributi con certe caratteristiche comuni. Ecco alcuni esempi tratti da esperienze personali.

In un Data Warehouse per una banca, si è presentata l’esigenza di modificare la dimensione dei campi di importo in valuta passando da numeri con due cifre decimali a sei cifre decimali. L’esigenza era ovviamente legata a problemi di arrotondamento.

Su centinaia di tabelle con diverse colonne coinvolte nella modifica, avere adottato lo standard di tipizzare tutte le colonne di importi in valuta con “<nome logico>_AMT” è stato determinante. Ha permesso di generare uno script in modo dinamico che, accedendo al dizionario dati, ha effettuato la modifica di struttura di tutte e sole le colonne interessate.


La Naming Convention degli attributi

Alcuni tool di ETL e reportistica, permettono di identificare in automatico tutte le colonne descrittive dei codici alfanumerici che verranno visualizzate in output : quello che l’interfaccia del tool richiede di indicare è soltanto la sigla con cui iniziano o terminano tali campi. Il tool userà poi una clausola "like" per individuare i campi.

Avere adottato lo standard di tipizzare tutte le colonne di descrizione di codici con “<nome logico>_DSC” permette di sfruttare questa caratteristica del tool e di non specificare ad uno ad uno tutti i campi descrittivi.

Vediamo anche in questo caso degli esempi di tipizzazione.

• COD – Code - Codice alfanumerico: è il classico codice a cui è associata una descrizione e un dominio. Può essere un codice cliente, un tipo di ordine,stato del conto,ecc. Consiglio di trattare i codici numerici come alfanumerici.

• DSC – Description - Descrizione del codice: è sempre la descrizione associata al codice che viene utilizzata nei tool di reportistica e di front-end. È una scelta progettuale capire se è sufficiente una sola descrizione oppure definire un tipo per una descrizione breve ( SDS che sta per short description) e un tipo per una descrizione lunga (LDS che sta per long description). Spesso capita che il cliente richieda la concatenazione della short description con il codice (CSD che sta per code and short description)

• AMT – Amount - Indica sempre un importo.• QTY – Quantità – Indica una quantità in pezzi, peso o in qualche altra unità di misura.• KEY – Indica sempre il campo che rappresenta una chiave artificiale. Una colonna con questo tipo deve

esistere in tutte le dimensioni di analisi e nelle corrispondenti colonne delle tabelle dei fatti.• DTS – Date Stamp – Data: indica una data nel formato Oracle, cioè comprensiva del time

(ore,minuti,secondi)• FLG – Flag – Indica sempre un campo flag binario, cioè che può valere solo 0 o 1.• TXT – Text – Campo generico di testo.


Le altre entità di un Data Warehouse

Identificare le principali entità o strutture presenti in un Data Warehouse non è un lavoro semplice senza dimenticare che in Oracle ci sono oltre 30 tipi diversi di strutture.

Ogni RDBMS ha le proprie esigenze e peculiarità e sarebbe prolisso e inutile cercare di dare una Naming Convention a tutto. Ci focalizzeremo quindi sulle entità principali, quelle che comunque sono sempre presenti, lasciando al lettore l’applicazione delle tecniche apprese per quelle rimanenti.

Ecco quindi l’elenco delle entità, oggetto delle nostre prossime linee guida.

• Indici• Tablespace• Datafile• Vincoli di integrità• Ruoli• Package


La Naming Convention degli indici

Poichè la Naming Convention è collegata al tipo di indice, darò una breve panoramica delle tipologie di indici più comuni. Essi coprono in genere il 90% delle necessità di un Data Warehouse.

Come tutti sanno, gli indici sono strutture dati che vengono create su una o più colonne di una tabella perottimizzare le performance dell’accesso ai valori chiave; lo scopo di un indice è quindi quello di fornire un puntamento fisico immediato alle righe della tabella che contiene tali valori.

In Oracle, ma anche in altri RDBMS, gli indici più utilizzati sono i classici b-tree, i bitmap locali o globali, e i function index.

Negli indici b-tree, i primi storicamente apparsi sulla scena, il puntamento è ottenuto memorizzando una lista di rowid (che è una combinazione di file + blocco Oracle + offest all’interno del blocco) per ogni chiave corrispondente alle righe con quel valore chiave.

Invece di utilizzare un puntatore alla riga contenente il valore chiave, gli indici bitmap utlizzzano una stringa di bit che indicano semplicemente la presenza (1) o la assenza (0) del valore chiave; questi indici possono essere locali (se la tabella è partizionata) o globali.

Nei function index il valore chiave è ottenuto mediante una funzione o un’espressione (tipico è il caso del codice concatenato con la descrizione).

Il paradigma che sta alla base della Naming Convention degli indici può essere riassunto nella seguente formula:

<nome indice> = <codice progetto>_<codice area>_<codice sezione>_<nome logico>_<tipo indice>


La Naming Convention degli indici

La Naming Convention degli indici avrà quindi la stessa sintassi della entità, ma cambierà solo la tipizzazione. In pratica il nome è identico a quello della tabella su cui viene creato l’indice tranne il suffisso finale.

Quello che segue è un elenco degli indici applicabili a una fact table delle vendite. X indica un progressivo numerico.

• EDW_DM0_SLS_LBx: Rappresenta un local bitmap index.• EDW_DM0_SLS_GBx: Rappresenta un global bitmap index.• EDW_DM0_SLS_NUx: Rappresenta un generico indice btree non unique• EDW_DM0_SLS_UIx: Rappresenta un generico indice btree unique• EDW_DM0_SLS_FUx: Rappresenta un function index


La Naming Convention dei vincoli di integrità

I vincoli di integrità (integrity constraints) ci permettono di associare delle regole formali e di business alle tabelle del sistema al fine di impedire l’introduzione di valori errati o non conformi.

È inutile sottolineare l’importanza che tali regole rivestono nella progettazione di un Data Warehouse. Sfatiamo subito un mito che spesso capita di sentire: i vincoli sulle tabelle appesantiscono la loro gestione. Niente di più falso. Vediamo di fare chiarezza.

1. È ovvio che l’introduzione di un vincolo di integrità rallenta il processo di manipolazione della tabella, ma il suo overhead è minimo e, in percentuale, il suo peso nel processo di caricamento sarà trascurabile. Ricordo, comunque, che i vincoli possono essere disattivati prima di caricare i dati e riattivati subito dopo il caricamento.

2. Implementati in modo programmatico nell’applicazione non saranno mai così completi, sicuri e gestibili come quelli definiti in automatico dal RDBMS.

3. Inserite i vincoli di integrità anche se i sistemi alimentanti del Data Warehouse sono a loro volta degli RDBMS con dei vincoli attivi. Non fidarsi è meglio: provate a pensare cosa significa scoprire di avere delle chiavi doppie dopo avere caricato qualche mese di dati ed essere in produzione.

4. I vincoli di integrità sono indispensabili per far funzionare il query rewrite di Oracle, cioè la sua funzionalità interna che è in grado di riscrivere una query basata sulla fact table reindirizzandola su una materialized view. Senza i vicoli di integrità fra la fact table e le sue dimension table questo meccanismo non funzionerà mai.

Il paradigma che sta alla base della Naming Convention dei vincoli di integrità può essere riassunto nella seguente formula:

<nome vincolo>=<codice progetto>_<codice area>_<codice sezione>_<nome logico >_<codice tipo vincolo>


La Naming Convention dei vincoli di integrità

Quello che segue è un elenco dei vincoli di integrità applicabili alla nostra fact table delle vendite. X indica un progressivo numerico.

• EDW_DM0_SLS_Nxx: Per indicare l’obbligo di avere sempre un valore diverso da null per un certo campo della colonna. XX sarà un numero progressivo per ogni colonna della tabella che necessita del vincolo.

• EDW_DM0_SLS_PK1: Per indicare la primary key.• EDW_DM0_SLS_UKx: Per indicare una unique key.• EDW_DM0_SLS_FKx: Per indicare le foreign key. Se si pensa che il numero di foreign key possa essere

superiore a 9, utilizzare la convenzione Fxx• EDW_DM0_SLS_CKx: Per indicare un controllo più complesso basato su delle condizioni. (per esempio

una data inizio deve sempre essere precedente a una data fine)


La Naming Convention delle tablespace

Le tablespace sono unità logiche con cui si possono collegare oggetti con caratteristiche logiche comuni. Ogni tabella, materialized view o indice ha sempre una tablespace che la contiene, sia espressa esplicitamente nello script di creazione, o implicita, cioè quella di default dell’utente creatore dell’oggetto.

A sua volta ad ogni tablespace sono associati uno o più datafile. Il paradigma che sta alla base della Naming Convention delle tablespace può essere riassunto nella seguente formula:

<nome tbs> = <codice progetto>_<codice area>_<codice sezione >_<codice tipo tbs>

dove il codice sezione e il codice tipo (dati o indici) sono opzionali; infatti la tecnica da applicare in questo caso, non è univoca, ma dipende dalle dimensioni degli oggetti che costituiscono la tablespace. Facendo riferimento al nostro Data Warehouse di esempio, potremmo avere le seguenti:

• EDW_COM: Tablespace degli oggetti comuni. Nell’area che abbiamo definito COM, ci sono sicuramente tabelle e indici di dimensioni contenute, rispetto a quelle dei dati di altre aree, per cui sarà sufficiente il codice progetto più il codice di area.

• EDW_STA: Tablespace degli oggetti temporanei. Anche in questo caso le tabelle di staging, che sono solo di appoggio transitorio e di piccole dimensioni, potranno alloggiare in una unica tablespace.

• EDW_DM0_SLS: Tablespace degli oggetti dal data mart delle vendite. Se il totale dello spazio occupato da tali oggetti è limitato, può essere sufficiente questa unica tablespace. (personalmente per limitato intendo sotto gli 8 Gb). Se i volumi sono superiori, si può tipizzare per DFT, IFT, DMT e IMT, cioè data fact table, index fact table, data materialized view e index materialized view. Nei casi di VLDW (Very Large Data Warehouse) è ipotizzabile una tablespace indici e una dati per ogni singola entità.


La Naming Convention dei datafile

Come affermato nel paragrafo precedente, la tablespace è costituita da datafile. Al momento della creazione della tablespace, bisogna già conoscere approssimativamente, lo spazio totale occupato dagli oggetti che alloggeranno nella tablespace, perché vi verrà chiesto lo spazio fisico da allocare.

Dimentichiamoci di “pilotare” la posizione dei data file su certi dischi del database Server. Ormai le tecniche di virtualizzazione dello spazio fisico ci permettono di vedere un unico disco. Il mio consiglio è di dividere lo spazio occupato dagli oggetti della tablespace in un certo numero di file diversi di dimensioni non troppo elevate per una loro migliore gestione.

Il paradigma che sta alla base della Naming Convention dei datafile può essere riassunto nella seguente formula:

<nome datafile> = <nome tablespace >_XX.DBF

In questo caso XX è un progressivo numerico, del tipo 01,02,.., mentre il tipo è associato all’estensione del file ed è fisso a DBF (Data Base File). Ovviamente invece di DBF potete associare anche altri acronimi, l’importante è che tutti i datafile seguano la stessa logica.


La Naming Convention dei ruoli

In un data warehouse, le tabelle e le loro strutture aggregate devono essere sempre accessibili agli utenti per la selezione dei dati. Fornire l’accesso significa dare le grant a tali strutture. Poiché gli utenti in genere accedono a uno o più data mart, il modo migliore per semplificare la gestione dei diritti di accesso è quello di raggruppare tutti gli accessi al data mart in ruoli, in modo che la grant non associ più, un utente con una struttura, ma un utente con un ruolo.

Appare subito chiaro che la Naming Convention dei ruoli sia strettamente collegata con i data mart, cioè con il partizionamento logico a livello di sezione.

Il paradigma che sta alla base della Naming Convention dei ruoli può essere riassunto nella seguente formula:

<nome ruolo> = <codice progetto>_<codice area>_<codice sezione>_< codice tipo>

Il codice tipo può essere opzionale, in quanto gli utenti del data warehouse accederanno sempre con delle query, quindi in select, ai dati; questo non significa che non si possa tipizzare con _SEL per indicare il ruolo di accesso in sola lettura, e con _UPD per il ruolo di accesso in scrittura, aggiornamento e cancellazione.

La figura seguente mostra un riassunto delle tecniche finora applicate.


La Naming Convention dei ruoli

Sales Data Mart (SLS)

IndiciIndici

Sales Fact TableEDW_DM0_SLS_FAT

Local Bitmap indexEDW_DM0_SLS_LBx

Monthly SalesEDW_DM0_SLS_MONTH_FMV

AccessRole

to Sales Data MartEDW_DM0_SLS_SEL

AccessRole

to Sales Data MartEDW_DM0_SLS_SEL

Constraint Primary keyEDW_DM0_SLS_MONTH_PKx

IndiciLocal Bitmap index

EDW_DM0_SLS_MONTH_LBx

Constraints foreign keyEDW_DM0_SLS_MONTH_FKx

Constraint Primary keyEDW_DM0_SLS_PKx

Constraints foreign keyEDW_DM0_SLS_FKx

Common Area (COM)

Datafile 1 EDW_COM_01.DBF

Datafile 1 EDW_COM_01.DBF

Enterprise Data Warehouse (EDW)

Indici

Common objects

Datafile 4 EDW_DM0_SLS_04.DBF








Tablespace EDW_DM0_SLS

Tablespace EDW_COM


La Naming Convention dei package

I package sono librerie di moduli PL/SQL. In Oracle, il PL/SQL (procedural language sql) è il linguaggio procedurale interno del database, anche se si possono scrivere programmi in Java, C, o altri linguaggi di programmazione richiamabili dai moduli PL/SQL. Questi modul i possono essere procedure o funzioni.

In Oracle, l’utilizzo dei package è fondamentale: consiglio vivamente che tutte le procedure e le funzioni necessarie al processo di caricamento siano incluse all’interno di essi. I vantaggi del loro utilizzo sono numerosi, e ne citerò solo due:

• Modularità: organizzare i programmi in modo ordinato in base al contesto in cui operano è indispensabile per chiunque lavori o lavorerà sul progetto.

• Prestazioni: quando si richiama un modulo di un package per la prima volta, l’intero package è caricato in memoria. Successive chiamate ad altri moduli del package non richiederanno operazioni accesso su disco.

Tornando alla Naming Convention, questo significa che la procedura che è utilizzata per il caricamento della fact table delle vendite o della aggregata mensile, deve essere contenuta nel package che ha lo stesso nome (se possibile) della tabella di destinazione, la fact table o la materialized view.

Se questa procedura utilizza funzioni o procedure comuni specifiche del Data Mart delle vendite, tale procedura dovrà essere contenuta nel package che ha lo stesso nome della sezione specificata. Il processo logico continuerà fino alle procedure comuni a tutto il data warehouse (per esempio, una funzione che mi ritorna la differenza di due date per dare il tempo di elapsed).

La Figura seguente mostra un esempio di tale incapsulamento.



Daily SalesEDW_DM0_SLSD_FAT

Monthly SalesEDW_DM0_SLSM_FMV

Loading modules

Daily Sales package

EDW_DM0_SLSD_FATLoading modules

Monthly Sales package

EDW_DM0_SLSM_FMV

Common package for theData Mart of Sales

EDW_DM0_SLSCommon modules

Common package for all Data Mart of level 0

EDW_DM0Common modules

Common package for all Data Warehouse

EDWCommon modules

Load Load

Call

Call

Call

Call

Call

Call



La Naming Convention da adottare per i package è molto flessibile e può essere nella sua forma più estesa:

<nome package> = <codice progetto>_<codice area>_<codice sezione>_<nome logico>_<codice tipo>così come nella sua forma più semplice:<codice_progetto>

La presenza del nome logico e del codice tipo può essere utilizzabile in sistemi complessi dove il numero dei package tende ad essere molto elevato.

Non dimentichiamo che la tipizzazione deve dare valore aggiunto alla semantica del nome. Aggiungere _PKG come codice tipo non crea valore aggiunto in quanto questa informazione è ottenibile dal catalogo Oracle con una semplice select.

Se invece si decide che tutti i moduli che richiamano procedure Java in una certa sezione siano all’interno di uno specifico package, allora la tipizzazione _PKG e _JPK sarà sicuramente una scelta efficace. Nel caso in cui, come in Oracle, non è possibile dare lo stesso nome a un package e a una tabella, tipizzare il package con_PKG sarà obbligatorio.


Conclusione

Siamo giunti al termine di questo breve viaggio all’interno delle tecniche di Naming Convention. Quanto esposto non è sicuramente esaustivo delle numerose possibilità di applicazione di tali tecniche, né intende essere un dogma a cui attenersi.

Ognuno di noi, sulla base della propria esperienza, potrà partizionare e tipizzare secondo le proprie necessità e secondo il proprio intuito. Infatti non è importante la scelta con cui si partiziona il sistema o si tipizzano i suoi componenti, ma è importante l’applicazione di un metodo di standardizzazione.

Una efficace Naming Convention fornisce sicuramente tutti gli strumenti necessari per tenere sotto controllo il sistema, in termini di conoscenza, gestione e manutenzione

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

Technology

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