Quick BI:FAQ sur les jeux de données

Erreurs SQL personnalisées

Si votre SQL personnalisé échoue lors de l'exécution ou de l'enregistrement, vérifiez les causes courantes suivantes.

1. Syntaxe incorrecte du SQL personnalisé

Quick BI prétraite le SQL personnalisé avant de l'envoyer à la base de données : il analyse les espaces réservés, ajoute une clause limit et insère des commentaires SQL. Une erreur de syntaxe entraîne une erreur de la base de données à cette étape.

Exécutez l'instruction directement dans votre base de données pour vérifier la syntaxe. Vous pouvez consulter les instructions précédemment exécutées dans l'historique.

2. Instructions précédant l'instruction SELECT

Quick BI ajoute une clause limit 200 lors de l'exécution ou de l'enregistrement du SQL personnalisé ; la requête doit donc commencer par une instruction SELECT. L'ajout d'instructions — y compris les instructions HINT — avant SELECT provoque l'échec de la requête.

Pour utiliser une instruction HINT, sélectionnez l'option Set HINT Statement au lieu de l'écrire inline.

Pour connaître les sources de données prenant en charge les instructions HINT, consultez la liste des fonctionnalités des sources de données.

3. Espaces réservés utilisés sans valeurs par défaut

Le SQL personnalisé prend en charge le passage de paramètres via des espaces réservés. Lors de l'affichage d'un rapport, les contrôles de requête transmettent les valeurs des espaces réservés au SQL sous-jacent pour permettre un filtrage flexible. Pour plus d'informations sur les cas d'utilisation et la syntaxe des espaces réservés, consultez la documentation relative aux espaces réservés.

Tout espace réservé utilisé dans une instruction SELECT doit avoir une valeur par défaut. Sans celle-ci, le SQL est incomplet au moment de l'exécution et renvoie une erreur.

Dans l'exemple ci-dessous, le champ Order Level échoue car l'espace réservé de valeur $val{profit_range} n'a pas de valeur par défaut. L'attribution d'une valeur par défaut de 100 et la réexécution du SQL résolvent le problème.

Définissez une valeur par défaut globale pour les espaces réservés dans les instructions SELECT — et non uniquement une valeur par défaut au niveau du jeu de données — afin d'éviter les erreurs lorsque les utilisateurs ouvrent le tableau de bord sans définir de valeur de filtre.

SELECT report_date, order_level, shipping_type,price,order_number,area,
   case when profit_amt< $val{profit_range} then'Loss' 
   when profit_amt> $val{profit_range} then'Profit'
   else 'Break-even'
   end 'Order Level'
from company_sales_record
where $expr{report_date :report_date}
and $expr{order_level :order_level}
and $expr{order_number :order_number}

4. Autres problèmes

Respectez les conventions standard pour les commentaires et les alias dans le SQL personnalisé. Une utilisation non standard peut entraîner le renvoi de noms de champs inattendus par la base de données, provoquer des échecs d'analyse des espaces réservés ou générer d'autres erreurs.

N'ajoutez pas de point-virgule (;) à la fin de votre SQL personnalisé.

Erreurs dans les champs calculés

1. Les champs calculés font référence aux colonnes de la table physique. Pour convertir le type de données d'un champ, utilisez la fonction de conversion appropriée : modifier le type dans l'interface utilisateur ne modifie pas le type du champ physique sous-jacent et peut provoquer une erreur.

2. Les champs calculés de dimension ne peuvent pas contenir de fonctions d'agrégation telles que SUM ou AVG. Pour effectuer une agrégation, enregistrez plutôt le champ en tant que mesure.

3. Les champs textuels prennent uniquement en charge les agrégations COUNT et COUNTD. Les fonctions SUM, MAX et similaires ne sont pas disponibles pour les champs textuels. Convertissez le champ en type numérique avant d'effectuer ces calculs.

Création de jeux de données à partir de fichiers locaux

Lorsque vous créez un jeu de données à partir d'un fichier local téléchargé, utilisez la syntaxe SQL de la source de données de destination. Par exemple, le téléchargement d'un fichier dans un espace d'exploration nécessite l'utilisation de la syntaxe ClickHouse lors de la création et de l'interrogation du jeu de données.

Le téléchargement d'un fichier dans un espace d'exploration présente deux limitations : le SQL personnalisé n'est pas pris en charge et les jointures inter-sources ne sont pas disponibles. Pour utiliser ces fonctionnalités, téléchargez le fichier dans une source de données au sein d'un espace de groupe qui prend en charge les jointures inter-sources.

Si vous téléchargez un fichier dans une source de données de base de données et utilisez du SQL personnalisé, référez-vous au nom de la table physique généré automatiquement dans la base de données, et non au nom de fichier d'origine. Pour trouver le nom de la table physique, ouvrez la liste des fichiers de la source de données, cliquez sur l'icône des paramètres du fichier et recherchez le nom sur la page de modification.

Conversion d'horodatages Unix en date/heure

Configuration de l'affichage des valeurs nulles ou vides

1. Configurez le style d'affichage des valeurs vides dans les paramètres du jeu de données.

1. Configurez le style d'affichage des valeurs vides dans les paramètres du tableau de bord.

Utilisation du SQL paramétré pour les calculs de ratio

Quick BI ne prend pas nativement en charge les calculs de ratio, mais vous pouvez les mettre en œuvre à l'aide de SQL paramétré dans un jeu de données personnalisé.

L'exemple suivant calcule la part de chaque ville dans le total des ventes de sa province, avec une plage de dates et des filtres province/ville sélectionnables par l'utilisateur. Le jeu de données comporte quatre champs : date (date), province (province), ville (city) et montant des ventes (order_amt).

select a.city,sum(fenzi)/sum(fenmu) as ratio
from
(select province,city,sum(order_amt) fenzi
 from  zhanbi_test
 where  $expr{date:date_para}
 and    $expr{province:province_para}
 and    $expr{city:city_para}
 group by province,city
)a
left  join
(select province,sum(order_amt) fenmu
 from  zhanbi_test
 where  $expr{date:date_para}
 and    $expr{province:province_para}
 and    $expr{city:city_para}
 group by province
)b on a.province=b.province

Cette requête agrège les données par le champ city ; vous pouvez l'adapter pour agréger par d'autres champs. Après avoir généré le SQL, convertissez le champ de date en type date dans les paramètres du jeu de données, puis créez le jeu de données et ajoutez-le à un tableau de bord.

Utilisation du SQL paramétré pour les calculs cumulatifs

select  a.mon_date,avg(a.order_num) order_num,sum(b.order_num) add_num
from (
select date_format(report_date,'%Y/%m') mon_date,count(distinct order_id) order_num,max(date_format(report_date,'%Y/%m')) max_mon_date
from  company_sales_record_copy
where  $expr{report_date:month_date}
group by date_format(report_date,'%Y/%m')
)a
left join(
select date_format(report_date,'%Y/%m') mon_date,count(distinct order_id) order_num
from  company_sales_record_copy
where  $expr{report_date:month_date}
group by date_format(report_date,'%Y/%m')
)b on a.max_mon_date>=b.mon_date
group by a.mon_date        

Lorsque le contrôle de requête est lié au champ de paramètre dans le tableau de bord, le filtrage par plage de mois renvoie la valeur cumulative pour chaque mois à partir du premier mois de la plage.

Interrogation des N derniers jours avec une seule date

select   report_date,area,product_type,count(distinct order_id) order_num
from   company_sales_record
where  area in ('Southwest','Northwest','North China')
and    ( $expr{dateadd(report_date,1,'dd'):date1}
or      $expr{dateadd(report_date,2,'dd'):date1}
or      $expr{dateadd(report_date,3,'dd'):date1})
group by area,product_type,report_date

Sécurité au niveau des lignes

Oui. Pour plus d'informations, consultez la documentation sur la sécurité au niveau des lignes.

Limite d'affichage des lignes par défaut

Par défaut, 100 lignes sont affichées.

Pagination dans la vue des données

Non.

Nouveaux champs non affichés

Utilisation des données géographiques dans les graphiques cartographiques

Sur la page de modification du jeu de données, changez le type de dimension de votre champ géographique en le type d'information géographique approprié.

Pour plus de détails, consultez la documentation sur la création d'un jeu de données.

Utilisation des descriptions de champ comme noms

Dans les paramètres de l'espace de travail, vous pouvez configurer l'utilisation des noms de table ou des remarques lors de la création de jeux de données dans cet espace de travail.

Vous pouvez également sélectionner plusieurs champs dans le panneau de configuration groupée des champs du jeu de données et appliquer par lot leurs descriptions comme noms de champ.

Mise à jour des jeux de données après des modifications de table

Lorsqu'un champ physique n'est plus trouvé, Quick BI ne le supprime pas automatiquement — le champ peut toujours être référencé dans des analyses ou des tableaux de bord en amont. Cliquez sur la table sur le canevas pour afficher les modifications des champs dans le panneau de droite, puis supprimez tous les champs invalides en un seul clic.

Création de jeux de données à partir de plusieurs bases de données

Faites glisser les tables des deux sources de données sur le canevas et configurez une relation entre elles. Après accélération avec le Quick Engine, les données sont prêtes à l'emploi. Pour connaître les sources de données prenant en charge le Quick Engine, consultez la liste des fonctionnalités des sources de données.

Copie de jeux de données vers un autre espace de travail

Utilisez la fonctionnalité de copie de jeu de données entre espaces de travail. Pour plus de détails, consultez la documentation sur la copie d'un jeu de données entre espaces de travail.

Configuration de modèles de données pour l'analyse multi-tables

Pour plus d'informations, consultez la documentation sur la construction d'un modèle.

La configuration d'un modèle de données définit les relations JOIN entre les tables. Configurez-la sur la page de modification du jeu de données. Pour plus de détails, consultez la documentation sur la construction d'un modèle.

Avantages de la mise en cache des requêtes de jeu de données

L'activation de la mise en cache des résultats de requête accélère l'accès aux rapports et réduit la charge de la base de données. Après la première demande, les requêtes suivantes effectuées pendant la durée de validité du cache sont servies depuis le cache — la base de données n'est pas interrogée à nouveau jusqu'à l'expiration du cache.

Optimisation des requêtes SQL lentes sur les jeux de données

1. Optimisez la logique SQL : vérifiez que les index sont utilisés et remplacez les jointures complexes par des vues de base de données lorsque cela est possible.

2. Définissez des valeurs par défaut ayant une portée globale pour les espaces réservés SQL afin d'éviter les balayages complets de table lorsqu'aucun filtre n'est appliqué.