Note di Data Warehouse e Business Intelligence - Tecniche di Naming Convention (parte 2)
Download as PPTX, PDF1 like935 views
Il documento fornisce linee guida pratiche sulla naming convention per progetti di data warehouse e business intelligence in ambiente Oracle, enfatizzando l'importanza di una nomenclatura coerente per entità, attributi, indici e vincoli. Le convenzioni sono progettate per migliorare la chiarezza e la gestione del database, permettendo agli DBA di lavorare in modo efficace e agli utenti finali di avere una visione più semplice e logica delle entità. Viene inoltre sottolineato che le convenzioni possono variare secondo le esigenze specifiche del progetto.
Note di Data Warehouse e Business Intelligence - Tecniche di Naming Convention (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