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

1. MICRO
ETL
FOUNDATION
Idee e soluzioni per progetti di
Data Warehouse e
Business Intelligence
in 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 nomenclatura
pratico ed efficace per un progetto di Data Warehouse.
(parte 2)
MASSIMO CENCI

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

3. MICRO ETL FOUNDATION
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.

4. MICRO ETL FOUNDATION
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.

5. MICRO ETL FOUNDATION
Gli utilizzatori della Naming Convention
A01DWCST EDW_COM_CDI_CUST_DIT
Senza Naming Convention Con Naming Convention
CUSTOMER_DIT
DBA
Architect

6. MICRO ETL FOUNDATION
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.

7. MICRO ETL FOUNDATION
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.

8. MICRO ETL FOUNDATION
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

9. MICRO ETL FOUNDATION
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 per
ottimizzare 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>

10. MICRO ETL FOUNDATION
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

11. MICRO ETL FOUNDATION
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>

12. MICRO ETL FOUNDATION
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)

13. MICRO ETL FOUNDATION
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à.

14. MICRO ETL FOUNDATION
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.

15. MICRO ETL FOUNDATION
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.

16. MICRO ETL FOUNDATION
La Naming Convention dei ruoli
Sales Data Mart (SLS)
Indici
Indici
Sales Fact Table
EDW_DM0_SLS_FAT
Local Bitmap index
EDW_DM0_SLS_LBx
Monthly Sales
EDW_DM0_SLS_MONTH_FMV
Access
Role
to Sales Data Mart
EDW_DM0_SLS_SEL
Constraint Primary key
EDW_DM0_SLS_MONTH_PKx
Indici
Local Bitmap index
EDW_DM0_SLS_MONTH_LBx
Constraints foreign key
EDW_DM0_SLS_MONTH_FKx
Constraint Primary key
EDW_DM0_SLS_PKx
Constraints foreign key
EDW_DM0_SLS_FKx
Common Area (COM)
Datafile 1
EDW_COM_01.DBF
Enterprise Data Warehouse (EDW)
Indici
Common objects
Datafile 4
EDW_DM0_SLS_04.DBF
Datafile 3
EDW_DM0_SLS_03.DBF
Datafile 2
EDW_DM0_SLS_02.DBF
Datafile 1
EDW_DM0_SLS_01.DBF
Tablespace
EDW_DM0_SLS
Tablespace EDW_COM

17. MICRO ETL FOUNDATION
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.

18. MICRO ETL FOUNDATION
La Naming Convention dei package
Daily Sales
EDW_DM0_SLSD_FAT
Monthly Sales
EDW_DM0_SLSM_FMV
Loading modules
Daily Sales package
EDW_DM0_SLSD_FAT
Loading modules
Monthly Sales package
EDW_DM0_SLSM_FMV
Common package for the
Data Mart of Sales
EDW_DM0_SLS
Common modules
Common package for all
Data Mart of level 0
EDW_DM0
Common modules
Common package for all
Data Warehouse
EDW
Common modules
Load Load
Call
Call
Call
Call
Call
Call

19. MICRO ETL FOUNDATION
La Naming Convention dei package
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.

20. MICRO ETL FOUNDATION
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