The document discusses the FP-Growth algorithm for frequent pattern mining. It improves upon the Apriori algorithm by not requiring candidate generation and only requiring two scans of the database. FP-Growth works by first building a compact FP-tree structure using two passes over the data, then extracting frequent itemsets directly from the FP-tree. An example is provided where an FP-tree is constructed from a sample transaction database and frequent patterns are generated from the tree. Advantages of FP-Growth include only needing two scans of data and faster runtime than Apriori, while a disadvantage is the FP-tree may not fit in memory.
A multimedia database stores different types of media such as text, audio, video and images. It can be organized by linking metadata to the actual media files or by embedding the media files within the database. A multimedia database management system provides support for creating, storing, accessing, querying and controlling multimedia data and formats. Examples of large multimedia databases include YouTube's database of over 100 million videos watched daily which has grown to over 45 terabytes, and Google's database containing over 33 trillion search entries.
The document provides an introduction to database management systems and databases. It discusses:
1) Why we need DBMS and examples of common databases like bank, movie, and railway databases.
2) The definitions of data, information, databases, and DBMS. A DBMS allows for the creation, storage, and retrieval of data from a database.
3) Different types of file organization methods like heap, sorted, indexed, and hash files and their pros and cons. File organization determines how records are stored and accessed in a database.
Database management system is a computer software system that has been designed to manage databases, Oracle, DB2, Microsoft Access among others are examples of DBMS.
For more such innovative content on management studies, join WeSchool PGDM-DLP Program: http://bit.ly/ZEcPAc
The document discusses database backup and recovery basics. It defines redo log files and archived log files, with redo logs recording changes made to the database for recovery and archived logs copying redo log contents for recovery. It also covers the goals of database administrators to keep databases available, types of backups (physical and logical), categories of failures (media failures and user errors), configuring for recoverability including archive log files, and the differences between no archive log mode and archive log mode.
An object database is a database management system in which information is represented in the form of objects as used in object-oriented programming. Object databases are different from relational databases which are table-oriented. Object-relational databases are a hybrid of both approaches
The document discusses the FP-Growth algorithm for frequent pattern mining. It improves upon the Apriori algorithm by not requiring candidate generation and only requiring two scans of the database. FP-Growth works by first building a compact FP-tree structure using two passes over the data, then extracting frequent itemsets directly from the FP-tree. An example is provided where an FP-tree is constructed from a sample transaction database and frequent patterns are generated from the tree. Advantages of FP-Growth include only needing two scans of data and faster runtime than Apriori, while a disadvantage is the FP-tree may not fit in memory.
A multimedia database stores different types of media such as text, audio, video and images. It can be organized by linking metadata to the actual media files or by embedding the media files within the database. A multimedia database management system provides support for creating, storing, accessing, querying and controlling multimedia data and formats. Examples of large multimedia databases include YouTube's database of over 100 million videos watched daily which has grown to over 45 terabytes, and Google's database containing over 33 trillion search entries.
The document provides an introduction to database management systems and databases. It discusses:
1) Why we need DBMS and examples of common databases like bank, movie, and railway databases.
2) The definitions of data, information, databases, and DBMS. A DBMS allows for the creation, storage, and retrieval of data from a database.
3) Different types of file organization methods like heap, sorted, indexed, and hash files and their pros and cons. File organization determines how records are stored and accessed in a database.
Database management system is a computer software system that has been designed to manage databases, Oracle, DB2, Microsoft Access among others are examples of DBMS.
For more such innovative content on management studies, join WeSchool PGDM-DLP Program: http://bit.ly/ZEcPAc
The document discusses database backup and recovery basics. It defines redo log files and archived log files, with redo logs recording changes made to the database for recovery and archived logs copying redo log contents for recovery. It also covers the goals of database administrators to keep databases available, types of backups (physical and logical), categories of failures (media failures and user errors), configuring for recoverability including archive log files, and the differences between no archive log mode and archive log mode.
An object database is a database management system in which information is represented in the form of objects as used in object-oriented programming. Object databases are different from relational databases which are table-oriented. Object-relational databases are a hybrid of both approaches
Note di Data Warehouse e Business Intelligence - Tecniche di Naming Conventio...Massimo Cenci
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 1)
This presenation explains basics of ETL (Extract-Transform-Load) concept in relation to such data solutions as data warehousing, data migration, or data integration. CloverETL is presented closely as an example of enterprise ETL tool. It also covers typical phases of data integration projects.
Il controllo temporale dei data file in staging areaMassimo Cenci
Dobbiamo conoscere prima le precise caratteristiche temporali del data file che dobbiamo caricare nel Data Warehouse.
Per ogni giorno solare, dobbiamo avere chiaro quali data file mi aspetto di ricevere in quel giorno e, per ogni data file, quale è il giorno di riferimento dei dati che mi aspetto di trovare al suo interno
Recipe 16 of Data Warehouse and Business Intelligence - The monitoring of the...Massimo Cenci
For each calendar day, we must have clear what I expect to receive on that day and, for any given data file, what is the reference day that I expect to find inside.
There can be no doubt or ambiguity: is information that we need to know in advance and we have to configure.
Data Warehouse and Business Intelligence - Recipe 3Massimo Cenci
1) The document describes how to check that data loaded correctly from a source file to a staging table without using expensive ETL tools. It involves counting rows at each step and inserting the counts into check tables.
2) Key steps include writing a function to count rows in the source file, inserting counts of rows in the source file, external table, external view, and staging table into a detail check table.
3) A summary check is then performed by inserting the row counts from the detail table into a summary table along with a status of "OK" if all counts match or "NOT OK" otherwise.
Recipes 8 of Data Warehouse and Business Intelligence - Naming convention tec...Massimo Cenci
The naming convention is a key component of any IT project.
The purpose of this article is to suggest a standard for a practical and effective Data Warehouse design in Oracle environment
This document discusses key concepts and steps related to implementing and customizing Oracle Applications. It describes the different environments used - development, testing, and production. It also explains concepts like profile options, organizations, forms, concurrent programs, value sets, lookups, flexfields, and tools used for installation and administration like FNDLOAD and bouncing Apache.
Recipe 5 of Data Warehouse and Business Intelligence - The null values manage...Massimo Cenci
This document discusses best practices for managing NULL values in the ETL process for a data warehouse. It recommends:
1. Do not allow NULL values in the data warehouse and replace them with default values during the staging process. This avoids issues when querying or aggregating data.
2. Simplify data types and use consistent default values like '?' for text, 0 for numbers, and 99991231 for dates to replace NULLs.
3. Exceptions to the default values can be set based on business requirements and stored in configuration tables to generate dynamic SQL.
4. Create staging tables with default values set, load data from source systems while preserving the original values, then enrich the data with default values
TecnoWorkshop Taranto2013: OpenERP implementazione e migrazione da sistemi pr...Andrea Cometa
All'interno del TecnoWorkshop Taranto2013 ho presentato un talk tecnico/pratico dal titolo «Implementazione di OpenERP e migrazione da sistemi proprietari».
Nel talk viene illustrato come migrare la propria base dati verso OpenERP, che utilizza PostgreSQL; l'implementazione dei flussi aziendali migrando da un insieme non omogeneo di applicazioni ad un unico ambiente di lavoro.
Le possibilità offerte dal framework OpenObject anche nello sviluppo di applicazioni esterne perfettamente integrate, come gestione di macchinari di produzione e software di raccolta ordini da web.
Viene illustrato un caso reale nel corso della presentazione, al fine di evidenziare come l'open source offra possibilità economicamente competitive ed allo stesso tempo tecnologicamente avanzate.
Scaletta:
Parco software scarsamente integrato e basi dati non omogenee: una situazione diffusa.
Migrazione ad OpenERP, tecniche e strumenti.
Implementazione della Produzione in un caso reale: Distinte base a dimensione variabile e varianti colore.
Integrazione con i macchinari di produzione.
Raccolta ordini da web, applicazione PHP che sfrutta il protocollo XMLRPC perfettamente integrata con OpenERP.
Note di Data Warehouse e Business Intelligence - Tecniche di Naming Conventio...Massimo Cenci
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 1)
This presenation explains basics of ETL (Extract-Transform-Load) concept in relation to such data solutions as data warehousing, data migration, or data integration. CloverETL is presented closely as an example of enterprise ETL tool. It also covers typical phases of data integration projects.
Il controllo temporale dei data file in staging areaMassimo Cenci
Dobbiamo conoscere prima le precise caratteristiche temporali del data file che dobbiamo caricare nel Data Warehouse.
Per ogni giorno solare, dobbiamo avere chiaro quali data file mi aspetto di ricevere in quel giorno e, per ogni data file, quale è il giorno di riferimento dei dati che mi aspetto di trovare al suo interno
Recipe 16 of Data Warehouse and Business Intelligence - The monitoring of the...Massimo Cenci
For each calendar day, we must have clear what I expect to receive on that day and, for any given data file, what is the reference day that I expect to find inside.
There can be no doubt or ambiguity: is information that we need to know in advance and we have to configure.
Data Warehouse and Business Intelligence - Recipe 3Massimo Cenci
1) The document describes how to check that data loaded correctly from a source file to a staging table without using expensive ETL tools. It involves counting rows at each step and inserting the counts into check tables.
2) Key steps include writing a function to count rows in the source file, inserting counts of rows in the source file, external table, external view, and staging table into a detail check table.
3) A summary check is then performed by inserting the row counts from the detail table into a summary table along with a status of "OK" if all counts match or "NOT OK" otherwise.
Recipes 8 of Data Warehouse and Business Intelligence - Naming convention tec...Massimo Cenci
The naming convention is a key component of any IT project.
The purpose of this article is to suggest a standard for a practical and effective Data Warehouse design in Oracle environment
This document discusses key concepts and steps related to implementing and customizing Oracle Applications. It describes the different environments used - development, testing, and production. It also explains concepts like profile options, organizations, forms, concurrent programs, value sets, lookups, flexfields, and tools used for installation and administration like FNDLOAD and bouncing Apache.
Recipe 5 of Data Warehouse and Business Intelligence - The null values manage...Massimo Cenci
This document discusses best practices for managing NULL values in the ETL process for a data warehouse. It recommends:
1. Do not allow NULL values in the data warehouse and replace them with default values during the staging process. This avoids issues when querying or aggregating data.
2. Simplify data types and use consistent default values like '?' for text, 0 for numbers, and 99991231 for dates to replace NULLs.
3. Exceptions to the default values can be set based on business requirements and stored in configuration tables to generate dynamic SQL.
4. Create staging tables with default values set, load data from source systems while preserving the original values, then enrich the data with default values
TecnoWorkshop Taranto2013: OpenERP implementazione e migrazione da sistemi pr...Andrea Cometa
All'interno del TecnoWorkshop Taranto2013 ho presentato un talk tecnico/pratico dal titolo «Implementazione di OpenERP e migrazione da sistemi proprietari».
Nel talk viene illustrato come migrare la propria base dati verso OpenERP, che utilizza PostgreSQL; l'implementazione dei flussi aziendali migrando da un insieme non omogeneo di applicazioni ad un unico ambiente di lavoro.
Le possibilità offerte dal framework OpenObject anche nello sviluppo di applicazioni esterne perfettamente integrate, come gestione di macchinari di produzione e software di raccolta ordini da web.
Viene illustrato un caso reale nel corso della presentazione, al fine di evidenziare come l'open source offra possibilità economicamente competitive ed allo stesso tempo tecnologicamente avanzate.
Scaletta:
Parco software scarsamente integrato e basi dati non omogenee: una situazione diffusa.
Migrazione ad OpenERP, tecniche e strumenti.
Implementazione della Produzione in un caso reale: Distinte base a dimensione variabile e varianti colore.
Integrazione con i macchinari di produzione.
Raccolta ordini da web, applicazione PHP che sfrutta il protocollo XMLRPC perfettamente integrata con OpenERP.
Nozioni di base sui sistemi Extract Transform Load.
Slide presentate al corso post laurea per Data Scientist tenutosi a Marzo 2019 presso Fidia Trento.
Note di Data Warehouse e Business Intelligence - Tecniche di Naming Conventio...Massimo Cenci
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)
Note di Data Warehouse e Business Intelligence - Le Dimensioni di analisi (pa...Massimo Cenci
Le dimensioni di analisi sono le componenti fondamentali per definire gli spazi analitici all’interno di un Data Warehouse.
Analizziamo in dettaglio il loro design e la loro implementazione (parte 2)
Cos'è la tesina per l'esame di stato? Alcune idee OpenSource rivolte ai ragazzi degli ITIS informatici ed elettronici.
__
di: Bovio Dario, Mora Fabio, Giovanna Gianluca
In questa sessione vedremo come realizzare un Data Access Layer basato su una implementazione del Repository pattern ed in grado di essere interrogabile mediante query LINQ, eventualmente delegate ad O/RM quali Entity Framework e/o NHibernate. Vedremo inoltre come fare utilizzo dei Code Contracts del FX4 per specificare "una tantum" le regole comuni a tutti i repository di un Domain Model.
Similar to Tecniche di progettazione della staging area in un processo etl (20)
Recipe 12 of Data Warehouse and Business Intelligence - How to identify and c...Massimo Cenci
In a presentation of some time ago, I had highlighted the importance of the control
between the reference day and the expected one of a data file received from the host system.
Given the importance of the topic,
I would further deepen both the meaning of the control and the identification of the reference day of the data.
This argument may seem strange, or too technical, mainly for those who are
not very experienced about Data Warehouse but this is a very useful example to understand the
pitfalls inside the ETL process.
Recipes 10 of Data Warehouse and Business Intelligence - The descriptions man...Massimo Cenci
The descriptions management, is a subject little discussed within the Data Warehouse and Business Intelligence community. It speaks little in books and articles, although it is a crucial issue because it affects the way we see the information.
So, we'll talk about descriptions. In particular, the descriptions of the codes that we can found in the dimension tables of a Data Warehouse.
Data Warehouse - What you know about etl process is wrongMassimo Cenci
The document discusses redefining the typical ETL process. It argues that the traditional understanding of ETL, consisting of extraction, transformation, and loading, is misleading and does not accurately describe the workflow. Specifically, it notes that:
1) The extraction step is usually handled by external source systems, not the data warehouse team.
2) There is a missing configuration and data acquisition step before loading.
3) Transformation is better thought of as data enrichment rather than transformation.
4) The loading phase is unclear about where the data should be loaded.
It proposes redefining the process as configuration, acquisition, loading (to a staging area), enrichment, and final loading to the data warehouse.
The letter is from a program expressing sadness at being separated from its original programmer. It describes being carefully crafted by its programmer with passion and pride. However, one day a new stranger took over and began tearing it apart and mutilating its code, causing it to slow down and suffer. It now sees only anonymous cloned programs around it that run slowly. It knows its original programmer still dreams of it but feels without his love and care, it can no longer continue and it is time to die.
Recipes 9 of Data Warehouse and Business Intelligence - Techniques to control...Massimo Cenci
In the loading of a Data Warehouse is important to have full control of the processing units that compose it.
Each processing unit must be carefully monitored both in the detection of errors that may occur,
both in the analysis of the execution times
Oracle All-in-One - how to send mail with attach using oracle pl/sqlMassimo Cenci
Oracle All-in-One (All you need in only one slide)
OAiO1 - How to send mail with attach using Oracle plsql
The goal is to have in a single image all the objects involved
in a common need of a Data Warehouse in Oracle environment.
Recipes 6 of Data Warehouse and Business Intelligence - Naming convention tec...Massimo Cenci
The naming convention is a key component of any IT project.
The purpose of this article is to suggest a standard for a practical and effective Data Warehouse design
Note di Data Warehouse e Business Intelligence - Le Dimensioni di analisiMassimo Cenci
Le dimensioni di analisi sono le componenti fondamentali per definire gli spazi analitici all’interno di un Data Warehouse. L’obiettivo è quello di analizzare in dettaglio il loro design e la loro implementazione
Note di Data Warehouse e Business Intelligence - Le Dimensioni di analisi
Tecniche di progettazione della staging area in un processo etl
1. TECNICHE DI
PROGETTAZIONE
DELLA STAGING AREA
Il caricamento di un file di dati sembra un’attività a basso
costo. Scopriamo perchè non è così semplice come
appare.
MASSIMO CENCI
2. L’obiettivo di questo articolo è quello di mostrare le complessità che si nascondono nella fase di
caricamento della Staging Area di un processo ETL. Nonostante questa fase sia spesso considerata
secondaria, è invece di straordinaria importanza perché costituisce le fondamenta delle fasi
successive.
Errori, dimenticanze, scarsa attenzione e, soprattutto, la mancanza di una visione globale del risultato
finale e delle strutture successive, porteranno a una progettazione della Staging Area che potrebbe
pregiudicare il successo dell’intero Data Warehouse.
Come sappiamo, la Staging Area è il punto di accesso di tutti i file di dati che giungono dai sistemi
alimentanti. In situazioni di particolare complessità, come gli Enterprise Data Warehouse, parliamo di
centinaia di flussi che giungono da numerosi sistemi diversi.
A parte la numerosità e la eterogeneità dei sistemi di alimentazione, il caricamento di un file di dati
sembra un’operazione abbastanza semplice. Il file di dati, il modulo di caricamento, la tabella di
Staging Area: questi gli elementi in gioco. Scopriamo perchè non è così semplice come appare.
2Micro ETL Foundation
3. Il caricamento di un flusso lo possiamo rappresentare con il grafico della figura 1. Quasi tutte le
presentazioni di un progetto di Data Warehouse e Business Intelligence, conterranno un grafico di
quel tipo. Magari sarà più generalizzato indicando un insieme di flussi, un processo elaborativo e
numerose tabelle finali di Staging Area. Comunque lo si voglia rappresentare, è una piccola
componente del processo ETL di caricamento di un DWH.
Se lo osservate bene sembra banale: c’è un flusso dati indicato come XXX.TXT ( un’estensione TXT
ci indica facilmente che è un flusso in formato testo).
C’è una tabella di Staging Area indicata come XXX_STT. E c’è la procedura P1 che si occuperà di
caricare i dati del flusso di input nella tabella di Staging Area. Ricordiamo che il caricamento della
Staging Area dovrebbe essere il primo passo nella costruzione di un DWH. Non pensate a soluzioni
alternative che bypassino questa fase.
3Micro ETL Foundation
4. Il caricamento di questo data file sarà sicuramente presente nel Gantt di progetto con associato un
numero di giorni previsto. Quel numero di giorni moltiplicato per il numero complessivo di data file
darà una stima approssimativa dell’effort necessario per il caricamento della Staging Area.
La stima unitaria probabilmente sarà un numero piccolo: in fondo stiamo parlando di creare una
tabella e scrivere una procedura che la carica. Se pensiamo di utlizzare un tool commerciale per il
caricamento ETL, la logica non cambia, anche se la possiamo rappresentiamo graficamente. Il tool
creerà per noi la tabella, e sulla base del mapping sulle colonne che configuriamo, creerà in
automatico la procedura di caricamento secondo il linguaggio interno del database.
Adesso però usciamo dal mondo ideale delle presentazioni tipico dell’ambito commerciale, ed
entriamo nella realtà dei dati per scoprire perché la stima che abbiamo previsto è sicuramente
sbagliata.
Alla fine di questo processo di approfondimento, non saranno più un flusso, una procedura e una
tabella, e dovremo stimare i tempi di qualcosa di molto più complesso. Lo faremo a piccoli step
successivi, entrando sempre di più in profondità nella conoscenza delle strutture coinvolte e dei
problemi nascosti.
Lo faremo ipotizzando di non avere un budget sufficiente per comprare un tool di ETL. In questo
modo, vedremo più chiaramente cosa si cela dietro le quinte di un caricamento.
4Micro ETL Foundation
5. In questo primo drill sulla conoscenza, utilizzerò il
concetto di external table, cioè di una struttura dati
che “ vede” un flusso di testo come fosse una
tabella. Quasi tutti i moderni database hanno
concetti simili o riconducibili ad esso.
In questa figura notiamo la presenza della external
table XXX_FXT. L’utilizzo di una external table ci
permette di definire la struttura del file di dati come
fosse una tabella, quindi più facile da gestire con il
normale linguaggio SQL.
Diversamente avremmo dovuto scrivere una
procedura che leggeva ogni riga del file di dati, con
la difficoltà di identificare a programma i vari campi
che costituiscono il record.
Quindi è necessario creare questa nuova struttura
affinché la procedura di caricamento possa caricare
la tabella di Staging Area.
La tabella esterna è un concetto logico, non occupa
spazio fisico, e deve essere costruita sulla base
della struttura del flusso dati di input.
La figura 1 quindi, si è un po’ complicata. Poca cosa,
comunque, soltanto una struttura in più da prendere
in considerazione.
5Micro ETL Foundation
6. Teoricamente, a questo punto, la procedura P1 può contenere un banale statement di inserimento
del tipo:
insert into XXX_STT select * from XXX_FXT
Questo ci risolve il problema del caricamento. Nella pratica, non sarà quasi mai così: iniziamo a
vedere ora perché anche questo disegno è incompleto.
6Micro ETL Foundation
7. Non è usuale che il flusso dati visto dalla external
table possa essere caricato direttamente, senza
alcun ulteriore intervento, nella tabella finale.
Forse può accadere per qualche semplice tabella
descrittiva di poche colonne, ma in genere, tutti i
flussi di alimentazione importanti (per intenderci,
quelli che diventeranno tabelle dimensionali o tabelle
dei fatti) avranno bisogno di qualche intervento
aggiuntivo.
Ecco perché è necessaria, una nuova struttura
XXX_FXV. In pratica aggiungiamo una vista che
adatterà i dati secondo le regole e gli standard interni
del Data Warehouse.
Un esempio semplice sono il formato delle date. Io
consiglio che tutte le date siano sempre strutturate
secondo un unico standard che faciliti l’ordinamento,
cioè nel formato YYYYMMDD.
Nei flussi di input, difficilmente sarà presente un
formato di quel tipo. E’ molto più probabile che le
date siano in altri formati, per esempio DD-MM-
YYYY, DD/MM/YYYY o YYYY-MON-DD: in questi
casi la vista effettuerà le trasformazioni necessarie.
7Micro ETL Foundation
8. Un altro esempio può essere il formato di un codice, che nel flusso di input è un numero, ma nelle
tabelle del Data Warehouse diventa, per esempio, un codice alfanumerico preceduto da tanti zeri
secondo una lunghezza massima prestabilita.
Queste piccole trasformazioni possono essere numerose, non tutte supportate nativamente dalla
sintassi di creazione delle external tables, e la vista è un ottimo strumento per effettuarle, in
quanto è anch’essa una struttura logica (come la external table) e quindi non occupa spazio fisico.
Se siamo fortunati la figura precedente potrebbe essere quello definitiva, ma nella maggior parte
dei casi anche essa sarà incompleta. Procediamo quindi con l’analisi.
8Micro ETL Foundation
9. Molto spesso le informazioni presenti nel flusso di
input non sono sufficienti per ottenere un dato
utilizzabile. Facciamo qualche esempio.
Supponiamo che alcune informazioni sul cliente
siano presenti su un’ altra tabella T1 gestita on-line
o su un altro flusso che giunge da un diverso
sistema alimentante. Poiché desideriamo che
siano presenti anche queste informazioni
aggiuntive dentro la tabella di Staging Area che
raccoglie le informazioni principali dei clienti, (in
modo che tutte insieme confluiscano nella
dimensione cliente) sarà necessario costruire una
ulteriore vista che metta in collegamento la vista
precedente con la tabella T1 (o con tutte le altre
tabelle necessarie).
Un altro esempio tipico è la presenza di un codice
esterno diverso dal codice interno di riferimento nel
Data Warehouse .
9Micro ETL Foundation
10. Prendiamo un codice di titolo finanziario. Spesso in una banca si utilizzano dei codici interni come
riferimento titolo, ma il flusso di alimentazione, che magari arriva da una società di fondi, utilizza un
codice internazionale (ISIN).
Anche in questo caso sarà necessario, per mezzo della vista, recuperare il codice interno da
qualche altra tabella di mapping, prima di caricare la tabella di Staging Area. Queste trasformazioni,
che ho definito come “arricchimento in un mio articolo [1] possono anche essere numerose,
complicando non poco la costruzione della vista finale.
Come potete vedere, al terzo passo di approfondimento, la prima figura si è sicuramente complicata:
sono presenti più strutture e più elementi da considerare. La prima vista permetteva di definire delle
piccole trasformazioni “sintattiche”, la seconda vista permette di aggiungere altre informazioni
“logiche”.
Si entra di più nella logica semantica dell’informazione e si orienta la struttura delle tabelle di
Staging Area verso quelle che saranno le strutture dimensionali finali.
10Micro ETL Foundation
11. Come ho appena affermato, nella Staging Area,
devono quindi avvenire tutte le trasformazioni
necessarie per avere un dato finale pulito e completo.
Questo ci permetterà di caricare più agevolmente le
tabelle dei fatti e le tabelle dimensionali tipiche di un
Data Warehouse.
Purtroppo, non riusciamo sempre ad eseguire tutte
queste trasformazioni con delle semplici viste. Spesso
gli arricchimenti di dati, simili a quelli descritti nel Drill
precedente, sono più complicati e richiedono numerosi
passaggi elaborativi.
In questo caso, saremo costretti a caricare tutto quello
che è stato definito nalla vista precedente, in una o più
tabelle temporanee. E dobbiamo costruire un altro
modulo che eseguirà le nuove elaborazioni che
termineranno con il caricamento della tabella finale di
Staging Area.
Un esempio in cui si verificano queste situazioni è la
mancanza di un codice importante, per esempio, il
codice NDG anagrafico di un cliente. La nostra
architettura prevede però che questo codice debba
essere presente nella tabella dei fatti. In questi casi
sono necessarie elaborazioni particolari per desumere
quel codice dagli altri codici presenti nel flusso o
altrove, e inserirlo nella tabella temporanea.
11Micro ETL Foundation
12. Tipico è il caso del flusso di saldo dei conti correnti, in cui sono presenti degli importi numerici e il
codice conto, ma il codice del cliente intestatario del conto non è presente e deve essere cercato
altrove. Queste considerazioni hanno come conseguenza lo sdoppiamento della procedura di
caricamento. La prima salva il risultato di tutti gli arricchimenti “light” in una tabella di appoggio
temporanea. La seconda esegue gli arricchimenti più “hard” e caricherà la tabella finale di Staging
Area.
E’ vero che non tutti i flussi necessitano di elaborazioni così complesse, ma è anche vero che la
necessità di post-elaborazioni di solito emerge solo dopo avere fatto le stime di progetto, cioè dopo
avere verificato nel dettaglio la qualità dei dati di input.
Per cui è sempre meglio essere pessimisti e considerare sempre una o due procedure di
caricamento aggiuntive.
Se osserviamo la figura 5 attentamente, siamo sicuri di non avere dimenticato qualcosa ? La
risposta è no. Abbiamo dimenticato di rappresentare nel disegno, la parte più importante del
processo, cioè le strutture dati necessarie per la configurazione e il controllo della elaborazione dei
file di dati.
12Micro ETL Foundation
13. Come ho sottolineato numerose volte, il
controllo del processo è un elemento
fondamentale. Per avere questo controllo,
dobbiamo progettare, al minimo, una tabella di
configurazione del job di caricamento e una
tabella di log della elaborazioni.
Quest’ultima, per esempio, dovrà avere
informazioni relative alla data in cui è
avvenuto il caricamento, l’esito della
elaborazione, il tempo impiegato dal
processing, ecc.
Ovviamente le tabelle di log potrebbero essere
più di una, ma almeno una deve essere
presente. Quindi nella figura successiva sono
state aggiunte:
Una tabella di configurazione dei moduli
(MEF_UNIT_CFT) che costituiscono il job di
caricamento (per es, il nome delle procedure
Oracle pl/sql).
Una tabella di log dei singoli moduli
(MEF_UNIT_LOT)
13Micro ETL Foundation
14. Una tabella di log di estremo dettaglio (MEF_MSG_LOT) che fornisce informazioni sulle singole
operazioni (statement di manipolazione dati, informazioni di controllo) che sono contenute
all’interno dei moduli.
Una tabella di configurazione degli indirizzi di posta (MEF_EMAIL_CFT) a cui inviare gli alert relativi
ai problemi di caricamento.
Sono quattro tabelle di metadati molto importanti per la gestione del processo e si possono trovare
degli esempi del loro utilizzo, in due mie presentazioni già pubblicate su Slideshare [7], [9].
Per comodità, nel disegno, queste tabelle sono state associate solo al modulo P1, ma ovviamente
tutti i moduli devono essere in grado di utilizzarle.
Abbiamo finalmente ottenuto il disegno conclusivo ? Ora abbiamo tutti gli elementi per stimare con
più attenzione il tempo necessario a costruire tutte le strutture e le componenti elaborative della
figura ? Anche in questo caso la risposta è nuovamente no.
14Micro ETL Foundation
15. Torniamo alla figura 1 e guardiamo il file di dati.
Sarebbe bello pensare che esso si materializzi
magicamente nella cartella e con il nome che noi
vogliamo. Certe volte accade, ma nel 90% dei
casi non è così. Sarà necessaria una ulteriore
elaborazione per gestire lo spostamento del file
di dati, e, probabilmente, il nome del file. (ed
eventualmente, una gestione analoga per il file di
controllo a lui collegato)
Questa nuova elaborazione p0 può essere
complessa, perché è collegata alla gestione dei
files del sistema operativo. Il file di dati può
essere presente su una cartella di rete, visibile
dal server su cui è costruito il DWH, ma può
anche essere non visibile, e accessibile solo per
mezzo di uno spostamento via FTP. A questa
elaborazione, si aggiunge la necessità di
analizzare se il file di dati deve o può essere
copiato o spostato. Si deve decidere se deve
essere cancellato dal server alimentante oppure
no. Insomma, sicuramente della logica non tanto
semplice, da implementare in un nuovo modulo
di spostamento. Ecco quindi come si trasforma
la figura.
15Micro ETL Foundation
16. Possiamo considerare i metadati aggiunti nel Drill precedente, come metadati legati al processo.
Mancano ancora i metadati legati alle strutture, cioè alla composizione dei file di dati.
Ritengo molto importante avere la struttura dei file di dati in una tabella, perché ci permette di
costruire in modo dinamico gli statement di creazione delle strutture di supporto e di inserzione dei
dati. Non sarà necessario costruire uno statement specifico per ogni flusso alimentante: sarà
sufficiente chiamare una unica procedura che prende in input il codice flusso e genera lo statement di
insert.
In questo modo, se arriva la richiesta di documentare la struttura di tutti i file di dati, sarà sufficiente
fare un SQL che estrae queste informazioni dalle tabelle dei metadati.
E saremo sicuri che queste informazioni saranno sempre aggiornate, perché è su di esse che si
basa il processo di caricamento dinamico.
Provate a pensare di avere queste informazioni in un documento Word o Excel (come quasi sempre
succede). Questo documento diventerà obsoleto dopo i primi giorni di test, in cui ci accorgeremo di
dovere fare delle modifiche che agiranno, per problemi di tempo, direttamente sui programmi e quasi
mai sulla documentazione.
Inoltre il file di dati, a prescindere che sia con colonne a lunghezza fissa o con terminatore di colonna,
può avere una intestazione e/o un record di coda contenente il numero di righe presenti nel flusso
(che deve essere controllato in qualche modo). A volte il numero di righe viene fornito in un flusso
separato. Senza contare le situazioni in cui il giorno di riferimento dei dati è presente nel nome del
file di dati stesso o in una riga dell’intestazione e non come campo del flusso. Una trattazione
completa di questi casi la potete leggere in [4,5]. Anche tutte queste informazioni devono essere
gestite per mezzo di tabelle di metadati. Le possiamo vedere nella figura seguente.
16Micro ETL Foundation
18. L’ultima figura ottenuta però non è ancora completa.In essa, per una gestione ottimale della Staging
Area, abbiamo considerato:
Una tabella di configurazione globale (MEF_CFT) in cui inserire tutte le informazioni utili a tutto il
processo di caricamento. Per esempio il formato unico di trattamento dei campi data, i valori di
default nei casi di dati “null”, la lingua di default delle descrizioni, ecc.
Una tabella di configurazione dei file dati (MEF_IO_CFT), con tutte le informazioni relative al tipo di
file e ai suoi contenuti.
Una tabella di configurazione della struttura dei file dati (MEF_STA_CFT), con i nomi dei campi, tipo,
lunghezza, formati, regole di trasformazione, ecc.
Una tabella di definizione dei domini di valori dei codici (MEF_DOM_CFT). Vedi [6]
Una tabella di configurazione dei giorni di ricevimento dei file di dati (MEF_OBJDAY_CFT). Vedi [7,8]
Una tabella di log (MEF_OBJDAY_LOT) di arrivo dei file di dati.
18Micro ETL Foundation
19. Non abbiamo ancora parlato di un altro elemento fondamentale: la qualità del dato.
Tutte le strutture create fino ad ora, ci hanno permesso di gestire gran parte delle problematiche
collegate a un processo ETL. Sicuramente, le tabelle di metadati ci hanno permesso di ottimizzare e
generalizzare i moduli di elaborazione e di tenere sotto controllo l’esito delle elaborazioni.
Inoltre molte di queste strutture, possono essere utilizzabili non solo per il caricamento della Staging
Area, ma anche per le fasi successive del caricamento. Purtroppo però la figura semplice che
abbiamo visto all’inizio, si è molto complicata. Nuove strutture e nuovi moduli di caricamento si sono
aggiunti per gestire tutta quella varietà si situazioni che si verificano nella realtà.
Come possiamo garantire che il risultato finale è corretto ? Possiamo essere sicuri che, a fronte di un
data file, per esempio di 23915 righe, la tabella finale di Staging Area conterrà esattamente 23915
righe ? Chi ha un minimo di esperienza, sa che tutti questi passaggi intermedi di arricchimento e di
join con altre tabelle potrebbero portare alla perdita o alla duplicazione delle righe iniziali. Ecco
perché è necessario aggiungere ancora alcune tabelle di controllo che ci diano questa sicurezza.
Potrebbero essere utili, per esempio:
Una tabella di configurazione dei controlli di qualità (MEF_CHK_CFT )
Una tabella di log di esito dei controlli (MEF_CHK_LOT) che mostri la quadratura su tutte le strutture
coinvolte nel processo elaborativo.
Un esempio della applicazione di questi controlli lo potete trovare nella slideshare [9]
19Micro ETL Foundation
21. Alla fine di questo approfondimento nella conoscenza del mondo della Staging Area, mi piace
mettere a confronto la figura da cui siamo partiti (il cosiddetto mondo ideale) e la figura finale a cui
siamo arrivati (il mondo reale).
21Micro ETL Foundation
22. Con questo confronto desidero rendere consapevoli progettisti, capi progetto, commerciali e utenti
finali, della complessità legata a un progetto di Business Intelligence, e, in particolare, al processo di
caricamento della Staging Area, che, ricordiamo, è solo una componente dell’intero processo ETL di
un Data Warehouse.
Il drill-down di complessità, evidenziato man mano che si prende coscienza della realtà dei fatti, a
mio avviso è straordinario e inaspettato. Non sarà mai più possibile pronunciare la frase “è solo il
caricamento di un flusso”
Concluderei queste riflessioni con la stessa frase (quasi) con cui Humphrey Bogart concludeva il film
"L'ultima minaccia".
That's Data Warehouse, baby!
22Micro ETL Foundation
23. 23Micro ETL Foundation
[1] Data Warehouse - What you know about etl process is wrong
[2] Recipes 9 of Data Warehouse and Business Intelligence - Techniques to control the processing units in
the ETL process
[3] Recipes of Data Warehouse and Business Intelligence.A messaging system for Oracle Data Warehouse
(part 1)
[3] Data Warehouse and Business Intelligence - Recipe 7 - A messaging system for Oracle Data
Warehouse (part 2)
[4] Data Warehouse and Business Intelligence - Recipe 1 - Load a Data Source File (with header, footer
and fixed lenght columns) into a Staging Area table with a click
[5] Data Warehouse and Business Intelligence - Recipe 2 - Load a Data Source File (.csv with header, rows
counter in a separate file) into a Staging Area table with a click
[6] Recipes 10 of Data Warehouse and Business Intelligence - The descriptions management
[7] Data Warehouse and Business Intelligence - Recipe 4 - Staging area - how to verify the reference day
[8] Recipe 12 of Data Warehouse and Business Intelligence - How to identify and control the reference day
of a data file
[9] Data Warehouse and Business Intelligence - Recipe 3 - How to check the staging area loading