Video: MS Excel - TRUCCHI E SEGRETI: Tabelle Pivot – SUPER TRUCCO Creazione automatica report di pagina 2025
L'ambiente di data warehousing o un data mart specifico che il vostro principale il data warehouse verrà alimentato potrebbe avere la missione di generare una serie di report finiti e prevedibili. Ecco un approccio alla progettazione di un database relazionale per supportare tale missione, costruito attorno al principio di denormalizzazione del database , o deliberatamente violare i buoni principi di progettazione di database relazionali nell'interesse dell'efficienza delle prestazioni.
La denormalizzazione è più adatta per soluzioni a colpo rapido, in cui è necessario disporre rapidamente di un data warehouse relazionale su scala ridotta o di un data mart. Ad esempio, è possibile creare un database relazionale denormalizzato per una carta specifica per produrre un determinato insieme di report che non saranno più disponibili a seguito di uno sforzo di migrazione del sistema legacy.
Sebbene la denormalizzazione non sia proprio un vicolo cieco, crea una grande quantità di dati duplicati e le strutture di database create non hanno molta flessibilità. Inoltre, è probabile che dispongano di funzionalità di query limitate (oltre ai report standard) poiché tali funzionalità sono strettamente legate alle strutture di reporting formalizzate nella progettazione della tabella. Tuttavia, potresti voler controllare questo approccio.
Un semplice esempio di denormalizzazione, mostrato nella figura, mostra come appaiono le tabelle del database di origine in un'applicazione che tiene traccia delle prestazioni di vendita, con quelle tabelle strutturate principalmente in base ai principi di progettazione di database relazionali standard (sono normalizzati).
Per supportare il formato del report mostrato nella parte inferiore della figura, le strutture di origine sono mappate in una tabella denormalizzata da cui è possibile generare il report senza dover accedere a nessuna tabella. (Per dirla in modo più semplice, il report viene eseguito molto rapidamente.)
Nota : Un esempio reale coinvolge molte più tabelle (da 10 a 50 o più) e molti più report di quelli mostrati nella figura. Questa cifra dovrebbe far passare l'idea, comunque.
In alternativa, potresti voler seguire i principi e le tecniche del design dimensionale. Poiché gli RDBMS ora hanno meno problemi di gestione delle strutture orientate alle dimensioni rispetto al passato, è probabile che si ottengano prestazioni adeguate per le esigenze di reporting e si abbia ancora la flessibilità di supportare un'ampia varietà di query ad hoc e multidimensionali.
Per un'implementazione rapida orientata ai rapporti, tuttavia, almeno prendere in considerazione la progettazione basata sulla denormalizzazione per i dati relazionali.
