"Name":"[Prestazioni] Non utilizzare tipi di dati in virgola mobile (flotating)",
"Category":"Prestazioni",
"Description":"Il tipo di dati a virgola mobile \"Double\" dovrebbe essere evitato, poiché può causare errori di arrotondamento imprevedibili e prestazioni ridotte in determinati scenari. Usare \"Int64\" o \"Decimale\" dove più appropriato (ma tieni presente che \"Decimale\" è limitato a 4 cifre dopo il segno decimale).",
"Name":"[Prestazioni] Imposta IsAvailableInMdx a false su colonne che non sono attributi",
"Category":"Prestazioni",
"Description":"Per accelerare il tempo di elaborazione e conservare la memoria dopo l'elaborazione, le gerarchie di attributi non devono essere create per le colonne che non vengono mai utilizzate per lo slicing dai client MDX. In altre parole, tutte le colonne nascoste che non vengono utilizzate come Ordina per colonna o a cui viene fatto riferimento nelle gerarchie utente devono avere la proprietà IsAvailableInMdx impostata su false. Riferimento: https://blog.crossjoin.co.uk/2018/07/02/isavailableinmdx-ssas-tabular/",
"Name":"[Prestazioni] Evitare relazioni bidirezionali utilizzando colonne ad alta cardinalità",
"Category":"Prestazioni",
"Description":"Per prestazioni ottimali, si consiglia di evitare l'uso di relazioni bidirezionali con colonne ad alta cardinalità. Per eseguire questa regola, devi prima eseguire lo script mostrato qui: https://www.elegantbi.com/post/vertipaqintabulareditor",
"Name":"[Prestazioni] Ridurre l'uso di colonne con stringhe lunghe e con elevata cardinalità",
"Category":"Prestazioni",
"Description":"È meglio evitare lunghe colonne di testo. Ciò è particolarmente vero se la colonna ha molti valori univoci. Questi tipi di colonne possono causare tempi di elaborazione più lunghi, dimensioni del modello eccessive e query utente più lente. La lunghezza lunga è definita come più di 100 caratteri.",
"Name":"[Prestazioni] Dividi data e ora in colonne separate",
"Category":"Prestazioni",
"Description":"Questa regola trova le colonne datetime che hanno valori non a mezzanotte (00:00:00). Per massimizzare le prestazioni, l'elemento ora dovrebbe essere diviso dall'elemento data (oppure il componente ora dovrebbe essere arrotondato a mezzanotte in quanto ciò ridurrà la cardinalità della colonna). Riferimento: https://www.sqlbi.com/articles/separate-date-and-time-in-powerpivot-and-bism-tabular/",
"Name":"[Prestazioni] Tabelle grandi dovrebbero partizionate",
"Category":"Prestazioni",
"Description":"Le tabelle di grandi dimensioni devono essere partizionate per ottimizzare l'elaborazione. Affinché questa regola venga eseguita correttamente, è necessario eseguire lo script mostrato qui: https://www.elegantbi.com/post/vertipaqintabulareditor",
"Name":"[Prestazioni] Ridurre l'utilizzo di colonne calcolate che usano la funzione RELATED",
"Category":"Prestazioni",
"Description":"Le colonne calcolate non si comprimono così come le colonne di dati native e possono causare tempi di elaborazione più lunghi. Pertanto, le colonne calcolate dovrebbero essere evitate se possibile. Uno scenario in cui potrebbero essere più facili da evitare è se utilizzano la funzione RELATED. Riferimento: https://www.sqlbi.com/articles/storage-differences-between-calculated-columns-and-calculated-tables/",
"Name":"[Prestazioni] Considerare prima uno Star-Schema invece di un'architettura Snowflake",
"Category":"Prestazioni",
"Description":"In generale, uno schema a stella è l'architettura ottimale per i modelli tabulari. Stando così le cose, ci sono casi validi per utilizzare un approccio a fiocco di neve. Controlla il tuo modello e considera il passaggio a un'architettura con schema a stella. Riferimento: https://docs.microsoft.com/en-us/power-bi/guidance/star-schema",
"Name":"[Prestazioni] Il modello dovrebbe avere una tabella contrassegnate con la proprietà Date Table",
"Category":"Prestazioni",
"Description":"In generale, i modelli dovrebbero generalmente avere una tabella delle date. I modelli che non dispongono di una tabella delle date in genere non sfruttano funzionalità come l'intelligenza temporale o potrebbero non disporre di un'architettura adeguatamente strutturata.",
"Name":"[Prestazioni] Le tabelle di tipo data/calendario dovrebbero essere contrassegnate come Date Table",
"Category":"Prestazioni",
"Description":"Questa regola cerca le tabelle che contengono le parole \"data\" o \"calendario\" poiché probabilmente dovrebbero essere contrassegnate come tabella di date. Riferimento: https://docs.microsoft.com/en-us/power-bi/transform-model/desktop-date-tables",
"Name":"[Prestazioni] Rimuovi le tabelle automatiche di data\\calendario (auto-date table)",
"Category":"Prestazioni",
"Description":"Evita di utilizzare tabelle di datazione automatica (Auto data-tables). Assicurati di disattivare la tabella di datazione automatica nelle impostazioni in Power BI Desktop. Ciò farà risparmiare risorse di memoria. Riferimento: https://www.youtube.com/watch?v=xu3uDEHtCrg",
"Name":"[Prestazioni] Evitare l'uso eccessivo di relazioni bidirezionali o molti-a-molti",
"Category":"Prestazioni",
"Description":"Limita l'uso delle relazioni b-direzionali e molti-a-molti. Questa regola contrassegna il modello se più del 30% delle relazioni è bi-direzionale o molti a molti. Riferimento: https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/",
"Name":"[Prestazioni] Limita le logiche di sicurezza a livello di riga (RLS)",
"Category":"Prestazioni",
"Description":"Prova a semplificare il DAX utilizzato per la sicurezza a livello di riga. L'utilizzo delle funzioni all'interno di questa regola può essere probabilmente scaricato sui sistemi upstream (data warehouse).",
"Name":"[Prestazioni] Considerare l'utilizzo di aggregazioni se si utilizza Direct Query in Power BI",
"Category":"Prestazioni",
"Description":"Se usi Direct Query in Power BI Premium, potresti prendere in considerazione l'uso di aggregazioni per migliorare le prestazioni. Riferimento: https://docs.microsoft.com/en-us/power-bi/transform-model/desktop-aggregations",
"Name":"[Prestazioni] Minimizza l'utilizzo delle trasformazioni di Power Query",
"Category":"Prestazioni",
"Description":"Riduci al minimo le trasformazioni di Power Query per migliorare le prestazioni di elaborazione del modello. Se possibile, è consigliabile scaricare queste trasformazioni nel data warehouse. Inoltre, controlla se il raggruppamento delle query (Query Folding) si verifica all'interno del tuo modello. Fare riferimento all'articolo di seguito per ulteriori informazioni sul raggruppamento delle query. Riferimento: https://docs.microsoft.com/en-us/power-query/power-query-folding",
"Name":"[Prestazioni] Evitare di utilizzare i dati \"unpivottati\" nelle tabelle.",
"Category":"Prestazioni",
"Description":"Evita di utilizzare dati pivot nelle tabelle. Questa regola controlla specificamente i dati pivot per mese. Riferimento: https://www.elegantbi.com/post/top10bestpractices",
"Name":"[Prestazioni] Ridurre l'utilizzo delle tabelle calcolate",
"Category":"Prestazioni",
"Description":"Migra la logica della tabella calcolata nel tuo data warehouse. Fare affidamento su tabelle calcolate porterà a debiti tecnici e potenziali disallineamenti se si dispone di più modelli sulla piattaforma.",
"Name":"[Prestazioni] Misura che usano la Time Intelligence non sono performanti in modelli Direct Query",
"Category":"Prestazioni",
"Description":"Al momento, è noto che le funzioni di Time Intelligence non funzionano altrettanto bene quando si utilizza Direct Query. Se riscontri problemi di prestazioni, potresti provare soluzioni alternative come l'aggiunta di colonne nella tabella dei fatti che mostrano i dati dell'anno precedente o del mese precedente.",
"Name":"[Prestazioni] Ridurre il numero di colonne calcolate",
"Category":"Prestazioni",
"Description":"Le colonne calcolate non si comprimono bene come le colonne di dati, quindi occupano più memoria. Inoltre, rallentano i tempi di elaborazione sia per la tabella che per il ricalcolo del processo. Delega la logica delle colonne calcolate nel tuo data warehouse e trasforma queste colonne calcolate in colonne di dati. Riferimento: https://www.elegantbi.com/post/top10bestpractices",
"Name":"[Prestazioni] Verifica se le relazioni bi-direzionali e molti-a-molti sono valide",
"Category":"Prestazioni",
"Description":"Le relazioni bidirezionali e molti-a-molti possono causare un degrado delle prestazioni o persino avere conseguenze indesiderate. Assicurati di controllare queste relazioni specifiche per assicurarti che funzionino come previsto e che siano effettivamente necessarie. Riferimento: https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/",
"Severity":1,
"Scope":"Relationship",
"Expression":"FromCardinality.ToString() = \"Many\" and ToCardinality.ToString() = \"Many\"\r\nor\r\nCrossFilteringBehavior == CrossFilteringBehavior.BothDirections",
"Name":"[Prestazioni] Verifica se è necessaria la sicurezza dinamica sulle riga (Dynamic RLS)",
"Category":"Prestazioni",
"Description":"L'utilizzo della sicurezza dinamica a livello di riga (RLS) può aggiungere memoria e sovraccarico delle prestazioni. Si prega di ricercare i pro/contro del suo utilizzo. Riferimento: https://docs.microsoft.com/en-us/power-bi/admin/service-admin-rls",
"Name":"[Espressioni DAX] I riferimenti in colonna devono essere pienamente qualificati. Usare NomeTabella[NomeCampo]",
"Category":"Espressioni DAX",
"Description":"L'utilizzo di riferimenti di colonna completi semplifica la distinzione tra i riferimenti di colonna e di misura e consente inoltre di evitare determinati errori. Quando si fa riferimento a una colonna in DAX, specificare prima il nome della tabella, quindi specificare il nome della colonna tra parentesi quadre. Riferimento: https://www.elegantbi.com/post/top10bestpractices",
"Expression":"DependsOn.Any(Key.ObjectType = \"Column\" and Value.Any(not FullyQualified))",
"CompatibilityLevel":1200
},
{
"ID":"DAX_MEASURES_UNQUALIFIED",
"Name":"[Espressioni DAX] I riferimenti alle misure non dovrebbero essere qualificati. Usare solo il Nome Misura",
"Category":"Espressioni DAX",
"Description":"L'utilizzo di riferimenti a misure non qualificati semplifica la distinzione tra riferimenti di colonna e di misura e consente inoltre di evitare determinati errori. Quando si fa riferimento a una misura utilizzando DAX, non specificare il nome della tabella. Utilizzare solo il nome della misura tra parentesi quadre. Riferimento: https://www.elegantbi.com/post/top10bestpractices",
"Expression":"DependsOn.Any(Key.ObjectType = \"Measure\" and Value.Any(FullyQualified))",
"CompatibilityLevel":1200
},
{
"ID":"AVOID_DUPLICATE_MEASURES",
"Name":"[Espressioni DAX] Due misure non dovrebbero avere la stessa definizione",
"Category":"Espressioni DAX",
"Severity":2,
"Scope":"Measure",
"Expression":"Model.AllMeasures.Any(Expression.Replace(\" \",\"\").Replace(\"\\n\",\"\").Replace(\"\\r\",\"\").Replace(\"\\t\",\"\") = outerIt.Expression.Replace(\" \",\"\").Replace(\"\\n\",\"\").Replace(\"\\r\",\"\").Replace(\"\\t\",\"\") and it <> outerIt)",
"Name":"[Espressioni DAX] Usa la funzione TREATAS invece di INTERSECT per le relazioni virtuali",
"Category":"Espressioni DAX",
"Description":"La funzione TREATAS è più efficiente e fornisce prestazioni migliori rispetto alla funzione INTERSECT quando viene utilizzata nelle relazioni virtuali. Riferimento: https://www.sqlbi.com/articles/propagate-filters-using-treatas-in-dax/",
"Name":"[Espressioni DAX] Usa la funzione DIVIDE per la divisione",
"Category":"Espressioni DAX",
"Description":"Utilizzare la funzione DIVIDE invece di utilizzare \"/\". La funzione DIVIDE risolve i casi di divisione per zero. Pertanto, si consiglia di utilizzare per evitare errori. Riferimento: https://docs.microsoft.com/en-us/power-bi/guidance/dax-divide-function-operator",
"Name":"[Espressioni DAX] Evitare di usare la funzione IFERROR",
"Category":"Espressioni DAX",
"Description":"Evitare di utilizzare la funzione IFERROR poiché potrebbe causare un degrado delle prestazioni. Se sei preoccupato per un errore di divisione per zero, usa la funzione DIVIDE poiché risolve naturalmente tali errori come vuoti (oppure puoi personalizzare ciò che dovrebbe essere mostrato in caso di tale errore). Riferimento: https://www.elegantbi.com/post/top10bestpractices",
"Name":"[Espressioni DAX] Le misure non dovrebbero essere riferimenti diretti ad altre misure",
"Category":"Espressioni DAX",
"Description":"Questa regola identifica le misure che sono semplicemente un riferimento ad un'altra misura. Ad esempio, si consideri un modello con due misure: [MisuraA] e [MisuraB]. Questa regola verrebbe attivata per MisuraB se il DAX di MisuraB fosse MisuraB:=[MisuraA]. Tali misure duplicate dovrebbero essere rimosse.",
"Name":"[Espressioni DAX] Filtra i valori delle colonne con la sintassi corretta",
"Category":"Espressioni DAX",
"Description":"Invece di utilizzare questa sintassi FILTER('Table','Table'[Column]=\"Value\") per i parametri di filtro di una funzione CALCULATE o CALCULATETABLE, utilizzare una delle opzioni seguenti. Per quanto riguarda l'utilizzo della funzione KEEPFILTERS, vedere il secondo collegamento di riferimento di seguito. Opzione 1: KEEPFILTERS('Table'[Column]=\"Value\") Opzione 2: 'Table'[Column]=\"Value\" Riferimento: https://docs.microsoft.com/power-bi/guidance/dax-avoid-avoid-filter-as-filter-argument Reference: https://www.sqlbi.com/articles/using-keepfilters-in-dax/",
"Name":"[Espressioni DAX] Quando fai una misura prediligi il filtro per colonne, non per tabelle",
"Category":"Espressioni DAX",
"Description":"Invece di utilizzare questo modello FILTER('Table',[Measure]>Value) per i parametri di filtro di una funzione CALCULATE o CALCULATETABLE, utilizzare una delle opzioni seguenti (se possibile). Il filtraggio su una colonna specifica produrrà una tabella più piccola da elaborare per il motore, consentendo così prestazioni più veloci. L'utilizzo della funzione VALUES o della funzione ALL dipende dal risultato della misura desiderato. Opzione 1: FILTER(VALUES('Table'[Column]),[Measure] > Value) Opzione 2: FILTER(ALL('Table'[Column]),[Measure] > Value) Riferimento: https://docs. microsoft.com/power-bi/guidance/dax-avoid-avoid-filter-as-filter-argument",
"Name":"[Espressioni DAX] Relazioni inattive che non vengono mai attivate",
"Category":"Espressioni DAX",
"Description":"Le relazioni inattive vengono attivate utilizzando la funzione USERELATIONSHIP. Se una relazione inattiva non viene referenziata in alcun modo tramite questa funzione, la relazione non verrà utilizzata. Dovrebbe essere determinato se la relazione non è necessaria o attivare la relazione tramite questo metodo. Riferimento: https://docs.microsoft.com/power-bi/guidance/relationships-active-inactive Reference: https://dax.guide/userelationship/",
"Name":"[Espressioni DAX] Evita di usare la sintassi '1-(x/y)'",
"Category":"Espressioni DAX",
"Description":"Invece di utilizzare la sintassi '1-(x/y)' per ottenere un calcolo percentuale, utilizzare le funzioni DAX di base (come mostrato di seguito). L'utilizzo della sintassi migliorata generalmente migliorerà le prestazioni. La sintassi '1-...' restituisce sempre un valore, mentre la soluzione senza '1-...' no (poiché il valore potrebbe essere 'vuoto'). Pertanto la sintassi '1-...' può restituire più righe/colonne che possono comportare una velocità di query più lenta. Chiariamo con un esempio: 1 - SUM ( 'Sales'[CostAmount] ) / SUM( 'Sales'[SalesAmount] ) Better: SUM ( 'Sales'[SalesAmount] ) - DIVIDE ( SUM ( 'Sales'[CostAmount] ), SUM ( 'Sales'[SalesAmount] ) ) Meglio: VAR x = SUM ( 'Sales'[SalesAmount] ) RETURN x - DIVIDE ( SUM ( 'Sales'[CostAmount] ), x )",
"Name":"[Prevenzione Errori] Le colonne di dati devono avere una colonna di origine",
"Category":"[Prevenzione errori]",
"Description":"Le colonne di dati devono avere una colonna di origine. Una colonna di dati senza una colonna di origine causerà un errore durante l'elaborazione del modello.",
"Name":"[Prevenzione errori] Gli oggetti dipendenti dalle espressioni devono avere un'espressione",
"Category":"[Prevenzione errori]",
"Description":"Le colonne calcolate, gli elementi di calcolo e le misure devono avere un'espressione. Senza un'espressione, questi oggetti non mostreranno alcun valore.",
"Name":"[Prevenzione errori] Evita origini dati strutturate con partizioni del provider",
"Category":"[Prevenzione errori]",
"Description":"Power BI non supporta le partizioni del provider (dette anche \"legacy\") che fanno riferimento a origini dati strutturate. Le partizioni che fanno riferimento a origini dati strutturate devono utilizzare il linguaggio M. In caso contrario, le partizioni \"provider\" devono fare riferimento a un'origine dati \"provider\". Questo può essere risolto convertendo l'origine dati strutturata in un'origine dati del fornitore (vedere il secondo collegamento di riferimento di seguito). Riferimento: https://docs.microsoft.com/power-bi/admin/service-premium-connect-tools#data-source-declaration Riferimento: https://www.elegantbi.com/post/convertdatasources",
"Name":"[Prevenzione errori] Evita la funzione USERELATIONSHIP e RLS sulla stessa tabella",
"Category":"[Prevenzione errori]",
"Description":"La funzione USERELATIONSHIP non può essere utilizzata su una tabella che sfrutta anche la sicurezza a livello di riga (RLS). Questo genererà un errore quando si utilizza la misura particolare in un oggetto visivo. Questa regola evidenzierà la tabella utilizzata nella funzione USERELATIONSHIP di una misura così come RLS. Riferimento: https://blog.crossjoin.co.uk/2013/05/10/userelationship-and-tabular-row-security/",
"Name":"[Prevenzione errori] Le colonne usate nelle relazioni devono essere dello stesso tipo di dati",
"Category":"Error Prevention",
"Description":"Le colonne utilizzate in una relazione devono essere dello stesso tipo di dati. Idealmente, saranno di tipo di dati intero (consultare la regola correlata \"[Formattazione] Le colonne di relazione dovrebbero essere di tipo di dati intero\"). Avere colonne all'interno di una relazione che sono di tipi di dati diversi può portare a vari problemi.",
"Name":"[Manutenzione] Rimuovi colonne non necessarie",
"Category":"[Manutenzione]",
"Description":"Le colonne nascoste a cui non fanno riferimento espressioni DAX, relazioni, livelli gerarchici o proprietà \"Ordina per\" devono essere rimosse.",
"Name":"[Manutenzione] Rimuovere le misure non necessarie",
"Category":"[Manutenzione]",
"Description":"Le misure nascoste a cui non fa riferimento alcuna espressione DAX dovrebbero essere rimosse per la manutenibilità",
"Severity":2,
"Scope":"Measure",
"Expression":"(Table.IsHidden or IsHidden) \r\nand ReferencedBy.Count = 0",
"FixExpression":"Delete()",
"CompatibilityLevel":1200
},
{
"ID":"FIX_REFERENTIAL_INTEGRITY_VIOLATIONS",
"Name":"[Manutenzione] Correggi le violazioni dell'integrità referenziale",
"Category":"[Manutenzione]",
"Description":"Questa regola evidenzia le relazioni che presentano violazioni dell'integrità referenziale. Ciò indica che nella tabella sul lato \"da\" della relazione sono presenti valori che non esistono nella tabella sul lato \"a\" della relazione. Le violazioni dell'integrità referenziale produrranno anche il valore del membro \"vuoto\" nei filtri dei dati. Si consiglia di risolvere questi problemi assicurandosi che la colonna della chiave primaria della tabella \"a\" abbia tutti i valori nella colonna della chiave esterna della tabella \"da\". Riferimento: https://blog.enterprisedna.co/vertipaq-analyzer-tutorial-relationships-referential-integrity/",
"Name":"[Manutenzione] Rimuovi i ruoli senza membri",
"Category":"[Manutenzione]",
"Description":"Puoi rimuovere ruoli senza membri.",
"Severity":1,
"Scope":"ModelRole",
"Expression":"Members.Count() == 0",
"FixExpression":"Delete()",
"CompatibilityLevel":1200
},
{
"ID":"ENSURE_TABLES_HAVE_RELATIONSHIPS",
"Name":"[Manutenzione] Assicurati che le tabelle abbiano relazioni",
"Category":"[Manutenzione]",
"Description":"Questa regola evidenzia le tabelle che non sono collegate a nessun'altra tabella nel modello con una relazione.",
"Severity":1,
"Scope":"Table, CalculatedTable",
"Expression":"UsedInRelationships.Count() == 0",
"CompatibilityLevel":1200
},
{
"ID":"OBJECTS_WITH_NO_DESCRIPTION",
"Name":"[Manutenzione] Oggetti visibili senza descrizione",
"Category":"[Manutenzione]",
"Description":"Aggiungi descrizioni agli oggetti. Queste descrizioni vengono visualizzate al passaggio del mouse nell'elenco dei campi in Power BI Desktop. Inoltre, puoi sfruttare queste descrizioni per creare un dizionario dati automatizzato (vedi link sotto). Riferimento: https://www.elegantbi.com/post/datadictionary",
"Name":"[Manutenzione] Prospettive senza oggetti",
"Category":"[Manutenzione]",
"Description":"Le prospettive che non contengono oggetti (tabelle) molto probabilmente non sono necessarie. In questa regola, è solo necessario controllare le tabelle poiché l'aggiunta di una colonna/misura/gerarchia a una prospettiva aggiunge anche la tabella alla prospettiva. Inoltre, le tabelle in generale coprono anche le tabelle calcolate e i gruppi di calcolo.",
"Name":"[Naming Conventions] Il nome della partizione deve corrispondere al nome della tabella per le singole tabelle delle partizioni",
"Category":"Naming Conventions",
"Description":"Le tabelle con una sola partizione dovrebbero corrispondere ai nomi delle tabelle e delle partizioni. Le tabelle con più di una partizione dovrebbero avere ogni nome di partizione che inizia con il nome della tabella.",
"Severity":1,
"Scope":"Table",
"Expression":"(Partitions.Count = 1 and Partitions[0].Name <> Name)",
"FixExpression":"Partitions[0].Name = it.Name",
"CompatibilityLevel":1200
},
{
"ID":"SPECIAL_CHARS_IN_OBJECT_NAMES",
"Name":"[Naming Conventions] I nomi degli oggetti non devono contenere caratteri speciali",
"Expression":"(\nName.StartsWith(\"Is\") and \nDataType = \"Int64\" and \nnot (IsHidden or Table.IsHidden)\n) \r\nor\r\n\n(\nName.EndsWith(\" Flag\") and \nDataType <> \"String\" and \nnot (IsHidden or Table.IsHidden)\n)",
"Expression":"Name.IndexOf(\"Month\", \"OrdinalIgnoreCase\") >= 0 and DataType = \"DateTime\" and FormatString <> \"MMMM yyyy\"",
"FixExpression":"FormatString = \"MMMM yyyy\"",
"CompatibilityLevel":1200
},
{
"ID":"PROVIDE_FORMAT_STRING_FOR_MEASURES",
"Name":"[Formattazione] Fornire una stringa di formato per le misure",
"Category":"Formattazione",
"Description":"Le misure visibili dovrebbero avere la proprietà formato assegnata",
"Severity":3,
"Scope":"Measure",
"Expression":"not IsHidden \r\nand not Table.IsHidden \r\nand string.IsNullOrWhitespace(FormatString)",
"CompatibilityLevel":1200
},
{
"ID":"NUMERIC_COLUMN_SUMMARIZE_BY",
"Name":"[Formattazione] Non riepilogare colonne di tipo numerico",
"Category":"Formattazione",
"Description":"Le colonne numeriche (integer, decimal, double) devono avere la proprietà SummarizeBy impostata su \"Nessuno\" per evitare la somma accidentale in Power BI (creare invece misure).",
"Name":"[Formattazione] Le colonne delle relazioni devono essere di tipo intero",
"Category":"Formattazione",
"Description":"È consigliabile che le colonne di relazione siano di tipo intero. Questo vale non solo per il data warehousing, ma anche per la modellazione dei dati.",
"Name":"[Formattazione] Aggiungi categoria di dati per colonne",
"Category":"Formattazione",
"Description":"Aggiungi la proprietà Categoria dati per le colonne appropriate. Riferimento: https://docs.microsoft.com/en-us/power-bi/transform-model/desktop-data-categorization",
"Name":"[Formattazione] Il mese (come stringa) deve essere ordinato",
"Category":"Formattazione",
"Description":"Questa regola evidenzia le colonne del mese che sono stringhe e non sono ordinate. Se non vengono ordinati, verranno ordinati in ordine alfabetico (ad es. aprile, agosto...). Assicurati di ordinare tali colonne in modo che vengano ordinate correttamente (gennaio, febbraio, marzo...).",
