IBM Cognos Analytics Version Instructions de modélisation des métadonnées IBM

(1)

IBM Cognos Analytics Version 11.1

Instructions de modélisation des métadonnées

IBM

(2)

©

Informations produit

Le présent document s'applique à IBM Cognos Analytics version 11.1.0 et peut aussi s'appliquer aux éditions ultérieures.

Copyright

Eléments sous licence - Propriété d'IBM

US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

IBM, le logo IBM et ibm.com sont des marques d'International Business Machines Corp. dans de nombreux pays. Les autres noms de produits et de services peuvent être des marques d'IBM ou d'autres sociétés. La liste actualisée de toutes les marques d' IBM est disponible sur la page Web " Copyright and trademark information ", à l'adresse suivante : www.ibm.com/legal/copytrade.shtml.

Les termes qui suivent sont des marques d'autres sociétés :

• Adobe, le logo Adobe, PostScript et le logo PostScript sont des marques d'Adobe Systems Incorporated aux Etats-Unis et/ou dans certains autres pays.

• Microsoft, Windows, Windows NT et le logo Windows sont des marques de Microsoft Corporation aux Etats-Unis et/ou dans certains autres pays.

• Intel, le logo Intel, Intel Inside, le logo Intel Inside, Intel Centrino, le logo Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep, Itanium, et Pentium sont des marques d'Intel Corporation ou de ses filiales aux Etats-Unis et dans certains autres pays.

• Linux est une marque de Linus Torvalds aux Etats-Unis et/ou dans certains autres pays.

• UNIX est une marque enregistrée de The Open Group aux Etats-Unis et/ou dans certains autres pays.

• Java ainsi que tous les logos et toutes les marques incluant Java sont des marques d’Oracle et/ou de ses sociétés affiliées.

Les captures d'écran des produits Microsoft ont été utilisées avec l'autorisation de Microsoft.

(3)

Table des matières

Chapitre 1. Modélisation des métadonnées... 1

Planification du projet...1

Flux de travaux de modélisation des métadonnées... 3

Chapitre 2. Importation et vérification des métadonnées...5

Chapitre 3. Désambiguïsation... 7

Cardinalité et modalités d'utilisation dans Cognos Analytics...7

Cardinalité dans le contexte d'une requête...8

Requêtes liées...9

Vérification des relations... 11

Résolution des relations ambiguës... 12

Dimensions de rôles...12

Jointures de boucle...13

Relations réflexives et récursives... 15

Chapitre 4. Conception et présentation du modèle...17

Chapitre 5. Requêtes à faits et à grains multiples... 21

Procédure pour éviter un double comptage... 22

Chapitre 6. Amélioration du modèle avec des fonctions supplémentaires... 23

Analyse de date relative et navigation dans les données...23

Utilisation du code SQL réduit ou procédure pour éviter la suppression de jointures... 24

Agrégation et ordre des opérations...27

Chapitre 7. Optimisation des performances des requêtes... 29

Cache de données...30

Ensembles de données...30

Comparaison des vues matérialisées sur des serveurs de données à la mise en cache des données dans Cognos Analytics...30

Réduction du temps de réponse des requêtes SQL ...31

Performances de jointure pour des sources de données hétérogènes... 33

Chapitre 8. Modifications du serveur de données et changement des fournisseurs de base de données...35

iii

(4)

(5)

Chapitre 1. Modélisation des métadonnées

L'objectif de la modélisation des métadonnées est de fournir une représentation conviviale des données dont disposent les utilisateurs de requêtes tout en ajoutant une valeur métier, si nécessaire.

Le travail du modélisateur de métadonnées consiste à garantir des résultats cohérents et valides aux utilisateurs qui créent ou utilisent le contenu d'IBM^® Cognos Analytics.

Ce document explique comment utiliser efficacement les concepts de modélisation pris en charge par IBM Cognos Analytics et garantir l'exactitude et les performances des résultats de requête.

Ce document ne contient pas d'instructions pas à pas. S'il y a lieu, des liens vers les documentations de composant associées sont fournis.

Clarification des termes utilisés

Ce document couvre différents outils de modélisation des métadonnées IBM Cognos Analytics qui peuvent chacun utiliser une terminologie légèrement différente pour les objets.

Par exemple, dans Framework Manager, les objets de requête sont appelés des sujets de requête de source de données et des sujets de requête de modèle. Dans les modules de données, les objets parallèles sont appelés des tables, des vues de table, des copies de table, des unions de tables, etc. En général, tous ces objets représentent une table ou une vue provenant d'une source de données, avec les colonnes qu'elles contiennent. Dans le présent document, les termes "tables" et "colonnes" sont utilisés.

Planification du projet

L'identification des besoins, la sélection minutieuse des sources de données et l'adoption de la meilleure méthode de conception permettent d'obtenir des métadonnées plus performantes.

Identification des besoins

Identifiez d'abord les besoins métier. Il est déconseillé de déterminer simplement quelles données sont disponibles et de mener une réflexion à partir de ce seul critère. Dans l'idéal, les données de la source doivent être structurées et enrichies pour des applications analytiques. Une approche courante consiste à combiner des schémas en étoile pour représenter un entrepôt dimensionnel conforme qui couvre un ou plusieurs domaines d'une entreprise.

Vérifiez que vos applications IBM Cognos Analytics reposent sur des sources de données correctement structurées qui répondent aux exigences de requête et aux attentes de performance des utilisateurs. Cela vous permettra d'éviter les requêtes qui "restructurent" et "enrichissent" continuellement les données lors de l'exécution. Il est préférable d'avoir des processus qui alimentent les données de la source, tels que le processus d'extraction, de transformation et de chargement (ETL), pour obtenir et stocker les données requises. Les performances reposent avant tout sur la source de données et sur toutes les optimisations qui peuvent être mises en oeuvre au sein de la source, comme les tables d'agrégation, les vues matérialisées, les calculs précalculés, l'indexation, etc.

Prenez en compte les autres questions suivantes :

• Quelles sont les attentes en matière de performances ?

• Quel est le niveau d'actualisation requis des données ?

• Quel est le niveau de détail requis ?

Les réponses à ces types de question permettent de déterminer les sources de données à utiliser, les données que les sources doivent contenir, le niveau de détail stocké (par exemple, données horaires ou quotidiennes, hebdomadaires ou mensuelles), la fréquence d'actualisation des données, etc.

(6)

Sélection des sources de données

Cognos Analytics fonctionne mieux avec des schémas en étoile ou en flocon. Ces schémas se composent de tables de dimensions qui contiennent des attributs, tels que le nom, la date, la couleur ou la ville, utilisés pour classer les données dans des catégories. Ils utilisent également des tables de faits qui contiennent des indicateurs clés de performance (KPI), également appelés mesures ou faits.

Dans l'exemple suivant, Products, Time, Order Method et Sales Order sont des tables de dimensions et Sales fact est la table de faits :

Les tables de dimensions référencées par plusieurs tables de faits sont appelées des tables de

dimensions partagées ou de référence. Dans l'exemple suivant, Products et Time sont des dimensions partagées pour les tables Returned items et Sales fact :

Si vous utilisez ce type de structure pour vos données d'entreprise, le processus de modélisation des métadonnées est nettement simplifié et assure des performances optimales. D'autres facteurs peuvent bien évidemment avoir une incidence sur les performances, notamment le volume de données, les ressources système, le fournisseur de base de données ou des optimisations de base de données, comme les index. Tous ces éléments doivent être pris en compte lors de la prise en charge d'un projet Cognos Analytics. Les tests effectués directement sur la structure de base de données, en dehors de Cognos Analytics, permet de s'assurer que le projet fonctionne comme prévu.

Cognos Analytics peut interroger de nombreux types de source de données différents, pas uniquement des bases de données. Des fichiers Microsoft Excel ou CSV peuvent être utilisés. En fonction de vos besoins, une source OLAP peut également apparaître comme la meilleure option. Par exemple, vous pouvez avoir des utilisateurs qui connaissent les fonctions dimensionnelles et qui nécessitent une source de données OLAP pour exécuter leurs requêtes. Vous devez prendre en compte ce qui fonctionne le mieux et ce qui répond aux besoins des utilisateurs.

(7)

Les sources de données peuvent également être combinées et associées. Par exemple, vous pouvez utiliser un fichier CSV et une table de base de données dans le même projet et créer une relation de jointure entre elles. Toutefois, cette opération doit être effectuée avec prudence car des problèmes de performances peuvent apparaître si ces deux sources de données ne sont pas combinées correctement.

L'utilisation de certaines techniques d'optimisation décrites ultérieurement dans ce document permet d'améliorer les performances lors de la combinaison de sources de données disparates dans un projet.

Analyse de la conception

Comme indiqué précédemment, Cognos Analytics fonctionne mieux avec la structure d'entrepôt de données comportant un schéma en étoile ou en flocon. Le service de requête Cognos Analytics est optimisé pour reconnaître les tables de dimensions et de faits en fonction de la nature de la jointure entre les tables. Plus un modélisateur de métadonnées parvient à identifier et à configurer clairement les tables de faits et de dimensions, plus le taux d'obtention de résultats exacts et performants est élevé.

Flux de travaux de modélisation des métadonnées

La modélisation des métadonnées est un processus itératif car vous préparez les métadonnées pour générer des rapports ou des tableaux de bord et explorer des données. Il y a un point de départ général et un flux de travaux à suivre. Les sections de cette rubrique présentent les étapes d'un flux de travaux de manière globale et inclut des liens vers un contenu plus détaillé.

Importation et vérification des métadonnées

Une fois que vos besoins sont définis et que les sources de données de support sont disponibles, vous pouvez importer les métadonnées requises dans l'outil de modélisation des métadonnées pour répondre aux besoins des utilisateurs. Vous pouvez être tenté de tout importer, puis d'identifier les éléments que vous souhaitez utiliser. Cette approche est déconseillée du point de vue de la maintenance, de la lisibilité et de la convivialité du modèle. Importez uniquement ce dont vous avez besoin, puis ajoutez d'autres éléments ultérieurement en fonction de l'évolution de vos besoins.

Pour plus d'informations, voir Chapitre 2, «Importation et vérification des métadonnées», à la page 5.

Désambiguïsation

Dans la conception de modèle, l'ambiguïté fait référence aux interprétations potentiellement erronées des relations et de leur cardinalité par le service de requête Cognos Analytics. Vous pouvez supprimer l'ambiguïté du modèle en vous assurant que les chemins de jointure corrects sont utilisés dans vos requêtes et que les tables de faits et les tables de dimensions prévues sont toujours traitées comme telles. Ce type de pratique génère l'agrégation prévue pour vos mesures.

Pour plus d'informations sur la suppression de l'ambiguïté, voir Chapitre 3, «Désambiguïsation», à la page 7.

Analyse de la conception de modèle

Au cours de cette phase, vous devez déterminer comment présenter des objets aux utilisateurs de manière claire, logique et concise. Vous pouvez consolider plusieurs tables au sein d'une même vue, consolider des tables regroupées de manière logique dans une seule partie du modèle, ajouter des filtres et des calculs selon vos besoins, etc.

Pour plus d'informations, voir Chapitre 4, «Conception et présentation du modèle», à la page 17.

Identification et configuration des requêtes à faits multiples ou à grains multiples

Dans certains scénarios, les faits de différentes tables de faits sont stockés à des niveaux de granularité différents qui correspondent à l'échelle ou au niveau de détail de l'ensemble de données. Par exemple, la table Inventory Fact stocke des valeurs mensuelles alors que la table Sales Fact stocke des valeurs quotidiennes. Des niveaux de granularité différents peuvent créer des situations où un fait est comptabilisé deux fois par erreur (et agrégé plus de fois qu'il ne le devrait compte tenu de la nature des

Chapitre 1. Modélisation des métadonnées 3

(8)

données). En tant que modélisateur de métadonnées, vous devez identifier ces scénarios potentiels et configurer le modèle en conséquence pour éviter un double comptage.

Pour plus d'informations, voir Chapitre 5, «Requêtes à faits et à grains multiples», à la page 21.

Amélioration du modèle avec des fonctions supplémentaires

En fonction des besoins et des exigences des utilisateurs, les modélisateurs de métadonnées peuvent utiliser différentes techniques et fonctions pour améliorer le modèle. Par exemple, certains utilisateurs peuvent souhaiter effectuer des comparaisons de date relative pour les données. Chaque outil de modélisation de métadonnées est en mesure d'effectuer ce type d'opération.

Framework Manager utilise des modèles DMR (Dimensionally Modeled Relational) à cette fin. Un modélisateur crée des objets dimensionnels qui permettent aux utilisateurs d'explorer les données en passant au niveau supérieur ou inférieur en fonction de hiérarchies définies. Des fonctions

dimensionnelles peuvent également être utilisées pour extraire et comparer des données de différentes périodes ou de différents segments de l'entreprise. Dans les modules de données, les modélisateurs peuvent mettre en place des chemins de navigation et des calendriers de date relative pour répondre à ce type d'exigence.

D'autres fonctions pour améliorer le modèle ou ses performances incluent notamment l'utilisation du langage SQL réduit et le contrôle du mode d'agrégation des données.

Pour plus d'informations, voir Chapitre 6, «Amélioration du modèle avec des fonctions supplémentaires», à la page 23.

Analyse des performances

Au fur et à mesure que vous développez votre modèle, vous devez tester constamment ses

performances. Les performances reposent en premier sur la source de données avec laquelle vous générez des rapports. Toutefois, un certain nombre d'optimisations clés peuvent être effectuées dans Cognos Analytics, telles que l'utilisation des caches de données, des ensembles de données et des optimisations de jointure dans des sources de données hétérogènes.

Pour plus d'informations, voir Chapitre 7, «Optimisation des performances des requêtes», à la page 29.

Itération

Comme pour n'importe quel projet, le modélisateur de métadonnées développe le modèle en fonction des besoins, effectue fréquemment des tests, puis modifie le modèle de manière itérative jusqu'à ce qu'il obtienne les résultats souhaités.

(9)

Chapitre 2. Importation et vérification des métadonnées

Après avoir identifié les métadonnées qui peuvent être utilisées dans votre modèle, importez uniquement les éléments nécessaires pour conserver un modèle gérable. Vérifiez également les propriétés Utilisation et Agréger pour les colonnes.

Les paramètres Utilisation suivants sont pris en charge : Identificateur

Représente une clé, un code ou une date.

Attribut

Représente un contexte, tel que le nom, la couleur, les informations géographiques, etc.

Mesure

Représente des indicateurs clés de performance qui sont généralement agrégés dans le contexte d'identificateurs ou d'attributs.

Par défaut, la propriété Agréger correspond à Nombre pour un identificateur ou un attribut et correspond à Somme ou Total pour une mesure. Même si une table de faits peut contenir un attribut ou un

identificateur numérique (par exemple, un numéro de commande), cela ne signifie pas que l'élément de la table des faits est une mesure ; son agrégation doit donc être définie en conséquence, par exemple Nombre ou Aucune agrégation. La même logique s'applique à une dimension où un attribut, comme une population ou une superficie, ne justifie pas nécessairement le paramètre d'agrégation Somme ou Total mais plutôt le paramètre "aucune agrégation".

En général, vous souhaitez vous assurer que les valeurs de type entier qui représentent des clés, des codes ou des attributs entiers non cumulés dans vos données utilisent la propriété Utilisation associée à la valeur Attribut ou Identificateur, et la propriété Agréger associée à la valeur Nombre. Il n'est pas logique que ces valeurs se comportent comme des mesures et soient définies en tant que total ou moyenne.

Pour plus d'informations sur la définition des propriétés de colonne dans les modules de données, voir la rubrique ."Propriétés d'objet" dans le document IBM Cognos Analytics - Guide de modélisation des données.

Pour plus d'informations sur la définition des propriétés d'élément de requête dans Framework Manager, voir la rubrique ."Eléments de requête" dans le document IBM Cognos Framework Manager - Guide d'utilisation.

Les modules de données peuvent indiquer que les colonnes correspondent à une zone géographique (ville, état, pays, etc.) ou sont de types temporels (jour, mois, trimestre, année, etc.). Il est possible d'exploiter automatiquement ces métadonnées étendues dans les requêtes. Par exemple, la propriété Représente des valeurs de données qui représentent des données géographiques est automatiquement associée à Emplacement géographique. Avec des données temporelles, cette propriété est

automatiquement associée à la valeur Temps. Cognos Analytics analyse également les données et permet d'exécuter d'autres fonctionnalités, comme des recommandations pour la visualisation des données. Vérifiez la propriété Représente des colonnes pour vous assurer qu'elle est définie comme prévu.

Pour les modèles Framework Manager, vous pouvez enrichir un pack publié afin d'obtenir la même fonction d'intelligence artificielle (IA) que dans les modules de données.

Pour plus d'informations, voir la rubrique "Enrichissement des packs" dans le document IBM Cognos Analytics - Guide de modélisation des données.

(10)

(11)

Chapitre 3. Désambiguïsation

Dans la conception de modèle, l'ambiguïté fait référence aux interprétations potentiellement erronées des relations et de leur cardinalité par le service de requête Cognos Analytics.

Les rubriques de cette section permettent de mieux comprendre comment le service de requête interprète les relations et comment vous pouvez modéliser les métadonnées pour obtenir des résultats pertinents et exacts.

Cardinalité et modalités d'utilisation dans Cognos Analytics

Les tables sont liées par des relations qui indiquent la valeur numérique des lignes connexes dans chaque table. Les relations les plus courantes sont les relations "un-à-plusieurs" et "un-à-un".

Les relations entre deux tables font référence à une ou plusieurs colonnes incluses dans les deux tables.

En général, la relation reflète l'intégrité référentielle définie dans une base de données (clés primaires, uniques et externes). Lorsque des métadonnées sont importées, IBM Cognos Analytics tente de localiser une intégrité référentielle disponible pour créer des relations par défaut.

Le service de requête Cognos Analytics utilise la cardinalité d'une relation dans les buts suivants :

• Pour identifier les tables qui se comportent comme des faits (côté n de la relation) ou des dimensions (côté 1 de la relation).

• Pour éviter le double comptage des mesures.

• Pour prendre en charge les jointures de boucle qui sont courantes dans les modèles à schéma en étoile.

Une relation peut spécifier la cardinalité minimale/minimale et la cardinalité facultative.

Dans 1:n, 1 est la cardinalité minimale et n est la cardinalité maximale.

Dans 0:1, 0 est la cardinalité minimale et 1 est la cardinalité maximale.

Une relation dont la cardinalité est définie sous la forme 1:1 à 1:n est généralement appelée une relation

"un-à-plusieurs" lorsque l'on se focalise sur les cardinalités maximales.

La cardinalité minimale 0 signifie que la relation est facultative. Par exemple, une relation entre

Customer et Sales peut être définie par défaut sous la forme 1:1 à 1:n. Dans ce cas, les clients sans les ventes ne sont pas renvoyés car la cardinalité des deux côtés n'est pas facultative. Pour inclure les clients sans les ventes, utilisez la cardinalité 1:1 à 0:n. Cette cardinalité indique que les requêtes affichent les informations client demandées même s'il n'existe peut-être pas de données de ventes.

Des relations peuvent être définies pour décrire les scénarios suivants :

• 1:1 à 1:n (jointure)

• 0:1 à 1:n (jointure externe droite)

• 0:1 à 0:n (jointure externe complète)

• 1:1 à 0:n (jointure externe gauche)

Vérifiez que la cardinalité est définie correctement dans vos métadonnées pour éviter toute ambiguïté.

Les tables incluant une seule cardinalité sont toujours considérées comme des dimensions dans le contexte d'une requête alors que les tables avec seulement des cardinalités n sont toujours considérées comme des faits. Les tables avec une combinaison de cardinalités 1 et n sont définies comme des dimensions ou des faits, selon le contexte de la requête. Pour plus d'informations sur le contexte et ses liens avec les requêtes, voir «Cardinalité dans le contexte d'une requête», à la page 8.

Lors de la génération de requêtes, le service de requête Cognos Analytics respecte les règles de base suivantes pour appliquer la cardinalité :

• Les règles de cardinalité sont appliquées dans le contexte d'une requête.

(12)

• La cardinalité 1 à n implique des données de dimension sur le côté 1 et des données de fait sur le côté n.

• Une table peut se comporter comme une table de faits ou une table dimensionnelle en fonction des relations requises pour répondre à une requête spécifique.

Dans Framework Manager, l'annotation par défaut dans le diagramme de relation utilise 1..1 ou 0..1 et 1..n ou 0..n pour représenter les cardinalités minimales et maximales. Dans les modules de données, 1 et n sont affichés pour représenter les cardinalités maximales dans le diagramme de relation ; la cardinalité facultative est indiquée par un fond blanc par opposition à un fond bleu dans l'annotation de cardinalité, comme l'indique la capture d'écran suivante.

Remarque : Si vous essayez de créer une jointure entre deux tables où les types de données des clés ne concordent pas, vous pouvez être tenté d'effectuer le transtypage de l'une des clés pour qu'elle

corresponde au type de données de l'autre clé. Il est déconseillé d'effectuer cette opération car elle risque d'altérer les performances. La non-concordance des types de données doit être résolue dans la base de données afin de tirer parti de l'optimisation de la base de données pour les clés primaires et externes. Lorsque vous effectuez un calcul dans les outils de modélisation pour exécuter un transtypage, une colonne de données est créée lors de l'exécution mais elle n'existe pas dans la base de données et ne sera pas optimisée.

Cardinalité dans le contexte d'une requête

Selon le contexte, la cardinalité peut être interprétée de différentes manières par le service de requête IBM Cognos Analytics.

Les exemples suivants montrent les interprétations possibles : Exemple 1 : Tables se comportant comme une dimension et un fait

Dans cet exemple, Sales Branch se comporte comme une dimension par rapport à Order header, et Order header se comporte comme un fait par rapport à Sales branch.

Exemple 2: Quatre tables dans une requête

Dans cet exemple, les quatre tables de requête sont toutes incluses dans une requête. Les tables Sales staff et Order details sont traitées comme des faits. Les tables Order header et Sales branch sont traitées comme des dimensions. Dans ce scénario, Order header se trouve sur le côté plusieurs et

(13)

le côté 1 de la relation. Dans ce contexte, le service de requête Cognos Analytics traite Order header comme une table de dimensions et évite le double comptage des mesures de cette table.

Exemple 3 : Trois tables dans une requête

Dans cet exemple, seules trois tables sont incluses dans une requête issue de l'exemple précédent. La table Order details n'est pas utilisée. La table Order header est maintenant traitée comme un fait.

La table Sales staff est toujours traitée comme un fait.

Requêtes liées

Lorsque des requêtes qui demandent des faits de plusieurs tables sont exécutées dans IBM Cognos Analytics, le service de requête effectue ce qu'IBM Cognos appelle une "requête liée". Les requêtes liées se composent de sous-requêtes, une pour chaque table de faits, qui sont ensuite fusionnées en fonction de leurs attributs communs provenant d'une table de dimension partagée.

Dans l'exemple suivant d'un modèle, Products et Time sont clairement des dimensions partagées en fonction de la cardinalité définie entre Returned items fact et Sales fact :

Dans les résultats de la requête ci-dessous qui est basée sur cet exemple, la dernière ligne indique qu'en 2013 il n'y a pas eu de retours pour l'article Hibernator Pad.

Les instructions pseudo-SQL ci-dessous indiquent que la requête a été exécutée, Cognos Analytics a créé deux sous-requêtes, une pour Sales et une pour Returns. Les données des sous-requêtes sont

combinées à l'aide d'une opération de jointure externe complète sur les colonnes Year et Product.

Comme il y a eu des ventes mais pas de retours pour l'article Hibernator Pad en 2013, une valeur nulle est renvoyée pour Return quantity.

Select

coalesce(D2.Year1,D3.Year1) as Year1,

Chapitre 3. Désambiguïsation 9

(14)

coalesce(D2.Product_Name,D3.Product_name) as Product_name, D2.Quantity as Quantity,

D3.Return_quantity as Return_quantity from (Sub query 1) D2

full outer join (Sub query 2) D3

on ((D2.Year = D3.Year) and (D2.Product_name = D3.Product_name))

Examinez les résultats de chaque sous-requête. Regardez tout d'abord les résultats de la sous-requête qui extraient des données pour le fait Quantity. La requête a renvoyé les quatre enregistrements suivants :

Examinons maintenant les résultats de la sous-requête pour le fait Return quantity. Notez qu'il n'y a que trois enregistrements. Il n'y a pas de retours pour 2013.

Toutefois, dans une requête liée, lorsqu'il y a plus d'enregistrements dans une sous-requête que dans une autre, des valeurs nulles sont renvoyées pour les lignes sans correspondance, comme indiqué dans le résultat de la requête suivant (présenté précédemment dans cette section) :

Dans l'exemple d'instructions pseudo-SQL précédent, la fonction coalesce est utilisée pour renvoyer le premier ensemble d'enregistrements non null des sous-requêtes. Si les deux sont null, aucun

enregistrement n'est renvoyé. Si l'une est null et que l'autre ne l'est pas, un enregistrement est renvoyé mais la sous-requête qui n'a pas de correspondance affiche une valeur null.

Pour plus d'informations sur la gestion des valeurs null dans les calculs lors de la génération de rapports, reportez-vous à cet article (www.ibm.com/support/pages/node/6252027).

Si des dimensions et des faits ne sont pas correctement identifiés, des requêtes liées risquent d'être inutilement créées, ce qui peut altérer les performances. Le format des requêtes peut également être incorrect et générer des résultats erronés.

Dans certaines situations, la détection des faits et les requêtes liées ne sont pas souhaitables. Dans ces cas de figure, vous devez bien connaître les données et être sûr que les relations sont de type un-à-un car sinon, les agrégations de lignes récapitulatives risquent d'être incorrectes. Cela se produit généralement dans les scénarios comportant une analyse des combinaisons.

Pour plus d'informations sur l'analyse des combinaisons, voir cet article (www.ibm.com/support/pages/

node/6252021).

(15)

Vérification des relations

Les outils de modélisation des métadonnées peuvent détecter et créer des relations entre les tables lors de l'importation. Toutefois, à l'issue de cette opération, il est recommandé de vérifier que les relations correspondent bien à ce qu'elles doivent être pour répondre aux exigences de la requête.

Les tables de faits sont-elles réellement des tables de faits en n'étant associées qu'à une cardinalité de type n ? Les tables de dimensions sont-elles réellement des tables de dimensions en n'étant associées qu'à une cardinalité de 1 ?

Il peut y avoir des exceptions pour les tables de dimensions dans la mesure où il s'agit de dimensions en flocon. Une dimension en flocon se compose de plusieurs tables qui représentent toutes la dimension globale. Les tables sont normalisées.

Les tables Product suivantes représentent un exemple de dimension en flocon :

Les tables Product line, Product type et Product composent toutes la hiérarchie Product de la dimension Product. On peut se demander si les tables Product type et Product ne pourraient pas être considérées comme des tables de faits dans le contexte d'une requête puisqu'elles sont toutes deux associées à une cardinalité de type n. Dans ce cas, la réponse est non car il existe un chemin linéaire "un- à-plusieurs" vers la table Sales fact. Le service de requête Cognos Analytics ne considère aucune de ces tables de produits comme des tables de faits dans le contexte d'une requête.

Examinons le scénario suivant :

Dans ce scénario, si les tables Product, Product name lookup et Sales fact étaient toutes incluses dans la requête, les tables Product name lookup et Sales fact seraient toutes deux traitées comme des tables de faits et généreraient une requête liée inutile. La relation entre Product et Product name lookup est-elle vraiment une relation "un-à-plusieurs" ? Lors de l'examen des données, Product name lookup est une table multilingue qui contient plusieurs lignes pour chaque produit de la table Product. La relation est donc réellement une relation "un-à-plusieurs". Toutefois, si l'on prend en compte les exigences de l'entreprise, une seule langue doit s'afficher à la fois et la langue choisie est déterminée par le paramètre d'environnement local de l'utilisateur dans Cognos Analytics. Un filtre peut donc être ajouté à la table Product name lookup. Il ne renverra qu'une seule ligne par produit, ce qui transforme la relation en relation 1 à 1, comme indiqué dans le scénario suivant :

(16)

Lorsque vous examinez vos relations, vérifiez toujours que les dimensions sont traitées comme des dimensions et que les faits sont traités comme des faits. Ce travail est facile si vous utilisez une conception de base de données à schéma en étoile simple. Toutefois, dans de nombreux cas, des scénarios de conception de la base de données doivent être traités dans le modèle. Les sections ultérieures de ce document examinent les options à utiliser pour consolider des dimensions à flocon.

Résolution des relations ambiguës

Des relations ambiguës apparaissent lorsque les données représentées par une table ou une dimension peuvent être visualisées dans plusieurs contextes ou rôles, ou peuvent être jointes de plusieurs manières.

Les relations ambiguës les plus courantes sont les dimensions de rôles, les jointures de boucle, et les relations réflexives et récursives. Pour plus de détails sur ces types de relation, reportez-vous aux sous- sections de cette rubrique.

Dimensions de rôles

Une table comportant plusieurs relations entre elle-même et une autre table est appelée une dimension de rôle.

La table Sales fact de l'exemple suivant comporte plusieurs relations avec Time sur les clés Order Day, Ship Day et Close Day :

Créez une table pour chaque rôle que la table Time doit remplir. Si votre dimension de rôle ne nécessite qu'un sous-ensemble de colonnes de la table d'origine, vous pouvez supprimer les colonnes inutiles pour obtenir une présentation plus claire, et fournir des noms appropriés, tels que Date dans Time, Ship Date dans Ship Day et Close Date dans Close Day. Vous pouvez également nommer les clés de manière appropriée. Par exemple, renommez Day Key en Ship Day Key dans Ship Day et en Close Day Key dans Close Day. Vérifiez qu'il existe une relation unique et appropriée entre chaque table de rôles et la table de faits pour la clé appropriée. Dans l'exemple ci-dessous, la table Time est utilisée pour représenter Order Day pour une vente. Les deux autres dimensions de rôles, Ship Day et Close Day, sont explicites.

(17)

Les dimensions de rôles que vous créez peuvent s'appliquer ou non à d'autres tables de faits. Par exemple, il est possible que Product forecast fact ne s'applique qu'à la dimension Time et qu'elle ne soit jointe qu'à cette dimension.

La table Time peut désormais être utilisée pour comparer Product forecasts et Sales.

Jointures de boucle

Les jointures de boucle sont causées par une définition ambiguë des relations entre les tables en fonction de la cardinalité. Elles peuvent entraîner des résultats imprévisibles. Toutefois, ce problème ne

s'applique pas aux jointures de boucle d'un schéma en étoile où la cardinalité identifie clairement les faits et les dimensions.

IBM Cognos Analytics peut corriger automatiquement les jointures de boucle causées par les données d'un schéma en étoile lorsque vous avez plusieurs tables de faits jointes à un ensemble commun de tables de dimensions.

Dans l'exemple de jointure de boucle ci-dessous, plusieurs tables de faits sont jointes à un ensemble commun de tables de dimensions.

Lorsque des tables sont définies de manière ambiguë en fonction de la cardinalité (ce qui signifie qu'on ne peut pas dire clairement si une table est un fait ou une dimension) et qu'elles font partie d'une jointure de

(18)

boucle, les jointures utilisées dans une requête sont déterminées en fonction d'un certain nombre de facteurs, notamment :

• L'emplacement des relations

• Le nombre de segments dans les chemins de jointure

• Le premier chemin de jointure par ordre alphabétique (à facteurs identiques)

Dans le scénario ci-dessous, la table Sales staff est définie de manière ambiguë en fonction de la cardinalité. La table est associée à la cardinalité 1 et n et fait partie d'une jointure de boucle. Si les colonnes des trois tables sont sélectionnées dans une requête, il est difficile de savoir quels chemins de jointure sont sélectionnés. Serait-ce le chemin Branch vers Sales staff et Order et la jointure entre Sales staff et Order serait-elle ignorée ? Serait-ce le chemin Branch vers Order et Sales staff vers Order et la jointure entre Branch et Sales staff sera-t-elle ignorée ?

Pour supprimer cette ambiguïté, vous pouvez utiliser Branch comme dimension de rôle (dans ce cas, Sales staff branch) pour corriger la jointure de boucle, comme indiqué dans l'exemple suivant :

Vous pouvez même combiner les colonnes Sales staff branch et Sales staff au sein d'une même table contenant les colonnes Staff et Branch pour simplifier la présentation.

(19)

Relations réflexives et récursives

Les relations réflexives et récursives impliquent au moins deux niveaux de granularité dans une table avec une profondeur fixe.

Par exemple, la table Sales staff établit une relation récursive entre Sales_Staff_Code et Manager_Code.

L'exemple suivant présente les données telles qu'elles peuvent apparaître dans une table : Tableau 1. Relation récursive entre Sales_Staff_Code et Manager_Code

Sales_Staff_Code Sales_Staff_Name Manager_Code

1 Jane Smith NULL

2 Martin Doe 1

3 Stephanie Sharaki 1

Jane Smith est associée à la valeur 1 pour Sales_Staff_Code mais ne possède pas de valeur pour Manager_Code car elle assure des fonctions de direction. Martin Doe et Stephanie Sharaki travaillent tous deux sous la direction de Jane Smith.

Pour créer une relation réflexive fonctionnelle dans votre modèle, vous pouvez créer un raccourci d'alias (dans Framework Manager uniquement) ou une copie de la table. La seconde option est préférable car vous pouvez nommer les colonnes en conséquence et créer une relation entre la table d'origine et la nouvelle table.

Par exemple, créez une table appelée Manager qui inclut Sales_Staff_Code et Sales_Staff_Name et basée sur la table Sales staff. Renommez Sales_Staff_Name en Manager name dans la table Manager du modèle. Créez une relation avec une cardinalité de 1 à n entre Manager et Sales staff pour Sales_Staff_Code et Manager code.

(20)

Pour une structure simple à deux niveaux qui utilise une table de modèle pour Manager basée sur Sales staff, le modèle se présente comme suit :

Pour une hiérarchie réflexive et équilibrée, répétez cette structure pour chaque niveau supplémentaire de la hiérarchie. Par exemple, le tableau 1 pourrait également inclure Director_Code, VP_Code, etc.

Vous pouvez aller plus loin et combiner chaque niveau des tables connexes de la hiérarchie pour obtenir la table finale Sales staff, qui présente des colonnes pour tous les niveaux de la hiérarchie. Cette nouvelle table finale sera jointe à vos tables de faits.

Les volumes de données importants qui comportent de nombreux niveaux réflexifs peuvent altérer les performances. Testez votre travail de manière approfondie pour évaluer les performances et vous assurer qu'il répond à vos besoins et à vos attentes. Pour des raisons de performances, il est recommandé

d'aplatir la hiérarchie dans la base de données pour obtenir une table unique qui inclut tous les niveaux requis dans leurs propres colonnes. Un exemple est présenté dans le tableau suivant :

Tableau 2. Hiérarchie aplatie pour obtenir une table unique avec tous les niveaux requis dans leurs propres colonnes

Sales_Staff_Code Sales_Staff_Name Manager_Code Manager_Name

1 Jane Smith 100 Jane Smith

2 Martin Doe 100 Jane Smith

3 Stephanie Sharaki 100 Jane Smith

La même technique peut être utilisée pour une hiérarchie déséquilibrée dont les branches se terminent à différents niveaux. La hiérarchie doit être aplatie et rééquilibrée en ajoutant des données pour les branches qui se terminent à des niveaux supérieurs, comme indiqué dans le tableau 2.

(21)

Chapitre 4. Conception et présentation du modèle

Vous devez toujours vous efforcer de présenter aux utilisateurs les métadonnées de manière claire et concise sous la forme de regroupements logiques faciles à lire et à comprendre.

Vous pouvez parfois être amené à regrouper plusieurs tables dans une même vue pour obtenir un regroupement logique. Par exemple, si vous avez trois tables représentant des données produits, vous pouvez présenter les données sous la forme d'une seule table métier logique qui simplifie la procédure de création de requêtes. Cette nouvelle table extrait de manière transparente les données des tables sous- jacentes.

Vous pouvez également souhaiter effectuer des calculs, appliquer des filtres ou mettre en place des invites pour répondre aux exigences des requêtes métier. Toutefois, lorsque vous effectuez ces opérations, envisagez de précalculer les colonnes dans les données de la source au lieu de réévaluer continuellement la logique dans le modèle.

Toutefois, le précalcul des colonnes dans les données de la source n'est pas toujours possible. Par exemple, dans certains cas, les responsables des systèmes source n'autorisent pas la modification du système. L'application Cognos Analytics doit donc continuellement calculer les expressions que vous définissez dans le modèle. De même, une équipe chargée des applications souhaite pouvoir s'adapter rapidement aux évolutions des exigences métier et ne peut pas attendre la modification de l'entrepôt de données. Il faut trouver un juste milieu mais dans chaque situation, les performances doivent primer.

Framework Manager et les modules de données ont une approche légèrement différente de la conception du modèle.

Dans Framework Manager, il est recommandé de modéliser plusieurs couches comprenant :

• La couche de base de données pour les tables importées.

Cette couche est considérée comme le cache de métadonnées.

• La couche métier pour les améliorations et la présentation du modèle.

Cette couche assure également la fonction de couche d'isolement pour les rapports afin de les protéger des modifications apportées à la couche de base de données sous-jacente.

• La couche de présentation qui regroupe les faits et les dimensions associées via un regroupement sous forme de schéma en étoile.

La fonction de regroupement sous forme de schéma en étoile présente aux utilisateurs les dimensions qui sont partagées par des faits car ils voient le même nom de dimension dans plusieurs regroupements sous forme de schémas en étoile. Elle permet aux utilisateurs de comprendre la portée de chaque dimension et des tables de faits associées. En comprenant cette règle simple, les utilisateurs qui veulent couvrir plusieurs tables de faits dans une requête savent qu'ils doivent inclure une colonne d'au moins une dimension partagée. Pour plus d'informations, voir la rubrique "Création de groupes sous forme de schémas en étoile" dans le document IBM Cognos Framework Manager - Guide d'utilisation.

La capture d'écran ci-dessous présente les différentes couches de modélisation dans Framework Manager :

(22)

La capture d'écran ci-dessous est une vue de présentation avec des regroupements sous forme de schémas en étoile. Les dimensions qu'ils partagent peuvent être identifiées par leur nom identique. Par exemple, Time et Products apparaissent à la fois dans les regroupements sous forme de schémas en étoile Sales Target et Sales.

Vous devrez peut-être créer et fournir plusieurs couches de présentation. Par exemple, une couche peut être destinée aux utilisateurs métier qui souhaitent créer leurs propres tableaux de bord et une autre couche peut être destinée aux créateurs de rapports qui doivent prendre en charge des exigences plus complexes.

Dans des modules de données, le cache de métadonnées est géré automatiquement et ne nécessite donc pas la couche de base de données. Vous pouvez vous concentrer sur les éléments à consolider et sur la valeur métier que vous souhaitez ajouter pour les utilisateurs. Bien que le regroupement sous forme de schéma en étoile ne soit pas une fonction disponible dans les modules de données, les utilisateurs peuvent posséder des droits en lecture seule dans le module de données pour voir sa portée et examiner les relations entre les dimensions et les faits. Contrairement à un modèle Framework Manager, un module de données est disponible dans le portail Cognos Analytics pour tous les utilisateurs dotés de droits d'affichage.

La capture d'écran ci-dessous présente un exemple de module de données dans l'interface utilisateur de modélisation :

(23)

Dans les deux outils de modélisation, vous pouvez créer des objets réutilisables et des couches d'abstraction. Par exemple, vous pouvez créer des calculs ou des filtres qui peuvent être réutilisés à plusieurs endroits, ou des copies de tables à utiliser dans différents contextes métier, comme avec des dimensions de rôles. Vous pouvez développer des objets dans un seul modèle et créer des liens vers eux à partir d'autres modèles en vue de leur réutilisation. Cette méthode de travail permet un paradigme multimodélisateur ou réduit simplement les opérations de maintenance. Par exemple, vous pouvez créer et gérer toutes vos dimensions communes dans un même modèle et les référencer dans d'autres

modèles où elles sont jointes aux tables de faits applicables. Les modifications apportées aux dimensions du modèle source sont propagées aux modèles qui les référencent.

Cognos Analytics prend en charge plusieurs sources de données dans ses outils de requête, tels que Génération de rapports ou Dashboarding. Dans Framework Manager, vous pouvez créer plusieurs modèles plus petits et plus simples à gérer qu'un seul modèle volumineux contenant l'ensemble des éléments. Vous pouvez ensuite publier plusieurs packs plus petits qui représentent différents aspects de l'entreprise et les visualiser dans les rapports ou les tableaux de bord.

Vous pouvez utiliser plusieurs modules de données comme sources de données dans Dasboarding.

Toutefois, dans Génération de rapports, un seul module de données peut être utilisé comme source. Si vous devez utiliser plusieurs modules de données dans Génération de rapports, ajoutez-les à un module de données "parent", puis utilisez ce module comme source.

Plus vos modèles sont petits, plus ils sont faciles à gérer. Si vous n'avez pas besoin d'interroger plusieurs tables de faits, il est inutile d'inclure toutes ces tables dans un même modèle. Vous pouvez répartir différents aspects de l'entreprise dans différents modèles et réutiliser des tables de dimensions

commune dans chacun d'eux. Même si vous pouvez disposer des modèles sous forme de couches, notez que plus le nombre de couches est élevé, plus il est difficile d'assurer la gestion, la maintenance et la correction des métadonnées.

Chapitre 4. Conception et présentation du modèle 19

(24)

(25)

Chapitre 5. Requêtes à faits et à grains multiples

Des requêtes à faits et à grains multiples se produisent lorsqu'une table qui contient des données dimensionnelles est jointe à plusieurs tables de faits sur des colonnes de clés différentes.

Par exemple, la dimension Time est jointe à Sales Fact sur Day Key (granularité de jour) et à Sales Target Fact sur Month Key (granularité de mois). Les tables ci-dessous, qui utilisent des données simples, présentent les concepts et les sorties des requêtes.

Tableau 3. Table de dimension Time

Year Quarter Month Day

2020 202001 20200101 Jan 1 2020

2020 202001 20200101 Jan 2 2020

2020 202001 20200101 Jan 3 2020

Tableau 4. Table de faits Sales

Day Key Revenue

Jan 1 2020 10

Jan 2 2020 10

Jan 3 2020 10

Tableau 5. Table de faits Sales Target

Month Key Sales Target

20200101 25

Une table dimensionnelle contient généralement des groupes (ou niveaux) distincts de données d'attribut avec des clés qui se répètent. Dans l'exemple précédent, la dimension Time illustre cette règle avec la répétition des valeurs Year, Quarter et Month. Cognos Analytics agrège automatiquement les valeurs au niveau de granularité commun le plus bas dans la requête. Le risque de double comptage apparaît lors de la création de totaux dans les colonnes contenant des données qui se répètent. Par exemple, les valeurs de Sales Target Fact, qui se trouvent au niveau de Month Key, se répètent pour chaque entrée Day Key pour les valeurs de Sales Fact, qui se trouvent au niveau Day Key.

Si vous visualisez les données à un niveau de granularité inférieur au niveau commun le plus bas, ici le niveau Day, les données de granularité supérieure, à savoir le niveau Month, sont répétées, comme indiqué pour Sales Target dans le tableau suivant :

Tableau 6. Résultats de la requête avec les données Sales Target agrégées de manière incorrecte

Year Month Day Revenue Sales Target

2020 20200101 Jan 1 2020 10 25

2020 20200101 Jan 2 2020 10 25

2020 20200101 Jan 3 2020 10 25

Total 30 75

Notez que la valeur Total de Sales Target correspond à 75, ce qui est incorrect car la valeur de Sales Target pour le mois de janvier n'est que de 25.

(26)

Lorsque le niveau de granularité des données est modélisé correctement, le double comptage des valeurs Sales Target Fact est évité, comme indiqué dans le résultat de la requête du tableau suivant :

Tableau 7. Résultats de la requête avec les données Sales Target agrégées correctement

Year Month Day Revenue Sales Target

2020 20200101 Jan 1 2020 10 25

2020 20200101 Jan 2 2020 10 25

2020 20200101 Jan 3 2020 10 25

Total 30 25

Pour plus d'informations, voir «Procédure pour éviter un double comptage», à la page 22.

Scénario avec une dimension non partagée

Dans l'exemple de requête ci-dessous, la table Order Method est ajoutée à la requête. Order Method s'applique uniquement à Revenue de la table Sales Fact, pas à Sales Target de la table Sales Target Fact. Dans ce scénario, Sales Target est répété pour chaque ligne introduite par Order Method mais les valeurs de Sales Target ne sont pas comptabilisées deux fois.

Tableau 8. Les valeurs de Sales Target ne sont pas comptabilisées deux fois

Year Month Day Order Method Revenue Sales Target

2020 20200101 Jan 1 2020 Mail 4 25

2020 20200101 Jan 1 2020 Web 4 25

2020 20200101 Jan 1 2020 Visit 2 25

2020 20200101 Jan 2 2020 Mail 5 25

2020 20200101 Jan 2 2020 Visit 5 25

2020 20200101 Jan 3 2020 Mail 5 25

2020 20200101 Jan 3 2020 Web 5 25

Total 30 25

Procédure pour éviter un double comptage

Les outils de modélisation vous permettent de configurer des modèles en prenant en compte des scénarios de double comptage.

Des exemples présentant ces types de scénario sont disponibles dans la rubrique Chapitre 5, «Requêtes à faits et à grains multiples», à la page 21.

Pour mieux comprendre la configuration des modules de données et éviter un double comptage, voir la rubrique "Dépendances de colonne" dans le document IBM Cognos Analytics - Modélisation des données.

Pour mieux comprendre la configuration des modèles Framework Manager et éviter le double comptage, voir la rubrique "Déterminants" dans le document IBM Cognos Framework Manager - Guide d'utilisation.

(27)

Chapitre 6. Amélioration du modèle avec des fonctions supplémentaires

En tant que modélisateur, vous pouvez utiliser différentes techniques et fonctions pour améliorer le modèle.

Par exemple, vous pouvez ajouter une analyse de date relative ou une fonction de navigation dans les données, vous assurer que le langage SQL réduit est utilisé et contrôler le mode d'agrégation des données.

Les rubriques de cette section décrivent les techniques et les fonctions que vous pouvez utiliser pour améliorer votre modèle.

Analyse de date relative et navigation dans les données

Les outils de modélisation permettent l'analyse de date relative et la navigation dans les données, même si chaque outil exécute ces procédures de manière différente.

Remarque : Cette section suppose que vous connaissez les sources de données dimensionnelles, comme OLAP et ROLAP, ainsi que le concept de cubes utilisés en tant que structure de données, avec des

dimensions, des hiérarchies, des niveaux, des membres, des mesures, etc.

Framework Manager prend en charge la modélisation DMR (Dimensionally Modeled Relational), qui est comparable à ROLAP. Ce type de modélisation permet à Cognos Analytics de générer un cache des données pour les cubes afin d'exécuter des requêtes standard de type OLAP à l'aide du langage de requête MDX (Multidimensional Expression), qui est utilisé pour interroger des sources dimensionnelles.

Avec les modèles DMR, les créateurs peuvent utiliser des fonctions dimensionnelles puissantes pour l'analyse, la comparaison et la manipulation des données.

En utilisant un modèle DMR, vous pouvez effectuer facilement une analyse de date relative en faisant glisser les membres que vous souhaitez comparer dans la requête, ou utiliser des fonctions

dimensionnelles pour extraire les membres à comparer. Le modèle DMR permet également de naviguer dans les hiérarchies des dimensions ; cette action s'appelle "passer au niveau inférieur ou supérieur". Elle permet une analyse rapide et puissante des données avec la possibilité d'explorer les détails en passant à un niveau inférieur.

Pour plus d'informations, voir la rubrique "Définition de la représentation dimensionnelle du modèle"

dans le document IBM Cognos Framework Manager - Guide d'utilisation.

Dans les modules de données, l'analyse de date relative est effectuée de manière exclusivement relationnelle en construisant des filtres et des mesures de date relative. La capture d'écran ci-dessous présente les filtres de date relative de la colonne Open Date dans un exemple de module de données :

(28)

La capture d'écran ci-dessous présente les mesures de date relative pour la mesure Service Requests dans le même exemple de module de données :

Pour plus d'informations, voir la rubrique "Analyse de date relative" dans le document IBM Cognos Analytics - Guide de modélisation des données.

Des modules de données permettent également de naviguer dans des niveaux définis de vos données à l'aide de la fonction de chemin de navigation. Vous pouvez définir des niveaux liés de manière logique, tels que l'année, le mois, la date, ou des niveaux sans lien entre eux, tels que le produit, la région, le client, etc. Lorsque des chemins de navigation sont autorisés, les utilisateurs peuvent accéder au niveau supérieur ou inférieur des données dans des tableaux de bord ou des explorations.

Pour plus d'informations, voir la rubrique "Création des chemins de navigation" dans le document IBM Cognos Analytics - Guide de modélisation des données.

Utilisation du code SQL réduit ou procédure pour éviter la suppression de jointures

Une table conçue dans les outils de modélisation,peut comporter plusieurs colonnes provenant de plusieurs tables. Lorsque vous interrogez une seule colonne de cette table modélisée, vous vous attendez

(29)

à voir un code SQL qui omet les tables dont les colonnes ne sont pas référencées. Ce concept est appelé

"suppression de jointures" ou "SQL réduit".

En fonction de la conception du modèle, il se peut que le code SQL réduit ne soit pas utilisé et que la requête agisse comme une vue. Dans ce cas, toutes les jointures des tables sous-jacentes sont

appliquées dans une sous-requête avant que la requête parent ne sélectionne la colonne unique dans la liste de projection finale. Dans certains cas, ce comportement peut être souhaité lorsque vous voulez appliquer une structure de jointure qui contrôle la quantité et le type de données renvoyés. Ce comportement de vue permet également d'éviter la suppression des jointures.

Par exemple, prenons le cas d'une dimension Product qui inclut quatre tables sous-jacentes, Product Dim et trois tables de correspondance qui ont une relation avec Product dim : Product line

lookup, Product type lookup et Product lookup. Lorsque vous interrogez Product line à partir de Product line lookup, vous pouvez souhaiter que seules des lignes de produits soient renvoyées lorsqu'il existe également des types de produit et des produits. Dans ce cas, vous devez vous assurer que la jointure sous-jacente entre ces tables est appliquée, sous réserve que des jointures internes soient définies dans le modèle. Toutefois, dans certaines situations, lorsque vous interrogez Product line, vous souhaitez voir toutes les tables, quels que soient les types de produit et les produits associés. Dans ce cas, vous disposez de deux méthodes pour y parvenir. La première consiste à configurer une jointure externe gauche pour Product type lookup à partir de Product line lookup en maintenant l'application de toutes les jointures sous-jacentes dans une sous-requête. La seconde consiste à s'assurer qu'un code SQL réduit est généré en configurant le modèle dans ce but.

Examinons les différences présentées par le code SQL pour la requête Product line. L'exemple suivant présente un code SQL non réduit (sans suppression de jointures).

WITH

"PRODUCT_LOOKUP0" AS (

SELECT

"PRODUCT_LOOKUP01"."PRODUCT_NUMBER" AS "PRODUCT_NUMBER", "PRODUCT_LOOKUP01"."PRODUCT_LANGUAGE" AS "PRODUCT_LANGUAGE", "PRODUCT_LOOKUP01"."PRODUCT_NAME" AS "PRODUCT_NAME",

"PRODUCT_LOOKUP01"."PRODUCT_DESCRIPTION" AS "PRODUCT_DESCRIPTION"

FROM

"PRODUCT_LOOKUP" "PRODUCT_LOOKUP01"

WHERE

"PRODUCT_LOOKUP01"."PRODUCT_LANGUAGE" IN ( 'EN' )

),

"Product_Line_Lookup_View_1" AS (

SELECT

"PRODUCT_LINE_LOOKUP0"."PRODUCT_LINE_EN" AS "PRODUCT_LINE_EN"

FROM

"PRODUCT_LINE_LOOKUP" "PRODUCT_LINE_LOOKUP0"

INNER JOIN "PRODUCT_DIM" "PRODUCT_DIM0"

ON "PRODUCT_LINE_LOOKUP0"."PRODUCT_LINE_CODE" = "PRODUCT_DIM0"."

PRODUCT_LINE_CODE"

INNER JOIN "PRODUCT_LOOKUP0"

ON "PRODUCT_LOOKUP0"."PRODUCT_NUMBER" = "PRODUCT_DIM0"."PRODUCT_NUMBER"

INNER JOIN "PRODUCT_TYPE_LOOKUP" "PRODUCT_TYPE_LOOKUP0"

ON "PRODUCT_TYPE_LOOKUP0"."PRODUCT_TYPE_CODE" =

"PRODUCT_DIM0"."PRODUCT_TYPE_CODE"

) SELECT

"Product_Line_Lookup_View_1"."PRODUCT_LINE_EN" AS "Product_Line"

FROM "Product_Line_Lookup_View_1"

GROUP BY

"Product_Line_Lookup_View_1"."PRODUCT_LINE_EN"

Notez toutes les jointures internes dans la sous-requête pour Product_Line_Lookup_View_1. Les jointures pour les quatre tables sont appliquées.

Comparez ce code SQL à l'exemple de code SQL réduit suivant (suppression des jointures) pour la requête Product line :

SELECT

"Product_Line_Lookup_View_1"."PRODUCT_LINE_EN" AS "Product_Line"

FROM

Chapitre 6. Amélioration du modèle avec des fonctions supplémentaires 25

(30)

"PRODUCT_LINE_LOOKUP" "Product_Line_Lookup_View_1"

GROUP BY

"Product_Line_Lookup_View_1"."PRODUCT_LINE_EN"

Dans ce cas, il s'agit simplement d'une sélection de colonnes dans une table.

Si vous aviez ajouté un élément de Sales fact à la requête, les jointures sous-jacentes appropriées qui relient Product line lookup à Product dim et à Sales fact seraient utilisées pour agréger les valeurs de la table Sales fact.

SQL réduit dans Framework Manager

Dans Framework Manager, vous pouvez configurer un sujet de requête pour qu'il utilise le langage SQL réduit, qui représente le paramètre par défaut. Pour plus d'informations, voir la rubrique "Modification du mode de génération du code SQL" dans le document IBM Cognos Framework Manager - Guide

d'utilisation.

Toutefois, si vous créez un sujet de requête de modèle et que vous lui associez une relation de jointure, le sujet de requête continue à agir comme une vue même si le mode SQL réduit est configuré dans

Framework Manager. Les jointures sont appliquées comme indiqué dans le scénario de conception de modèle ci-dessous, ce qui génère un code SQL non réduit :

Pour générer un code SQL réduit comme indiqué dans le scénario ci-dessous, vous ne créez pas de jointure pour relier Products à Sales fact. Au lieu de cela, vous devez joindre Product dim à partir des tables de produit sous-jacentes avec la table Sales fact. Lorsque vous interrogez une seule colonne, telle que Product line de Products, le code SQL est réduit comme prévu.

(31)

Si vous aviez ajouté un élément de Sales fact à la requête, les jointures sous-jacentes appropriées qui relient Product line lookup à Product dim et à Sales fact seraient utilisées pour agréger les valeurs de la table Sales fact.

SQL réduit dans les modules de données

Dans les modules de données, si vous souhaitez appliquer le comportement du code SQL réduit ou de la vue, utilisez la propriété de table Liste d'éléments. Une table consolidée associée à une jointure de relation utilise cette propriété pour générer le code SQL réduit ou appliquer les jointures sous-jacentes.

Pour plus d'informations, voir la rubrique "Génération du code SQL de la requête" dans le document IBM Cognos Analytics - Guide de modélisation des données.

Agrégation et ordre des opérations

Dans les outils de modélisation et les outils de requête, vous pouvez effectuer un calcul, puis agréger les résultats, ou agréger d'abord les valeurs dans le calcul, puis effectuer le calcul.

Pour contrôler cette fonction, vous devez définir les propriétés d'agrégation. Pour effectuer le calcul, puis l'agrégation, définissez la propriété de colonne en lui affectant la valeur Somme ou Total (selon

l'interface utilisateur). Pour effectuer l'agrégation, puis le calcul, définissez la propriété en lui affectant la valeur Calculé. Le paramètre Calculé s'applique uniquement aux calculs autonomes (sélectionnables) créés en dehors d'une table dans les outils de modélisation et dans les outils de requête, tels que Dashboarding ou Génération de rapports.

Le tableau ci-dessous présente les différents résultats obtenus lorsque les valeurs sont calculées avant ou après l'agrégation.

Tableau 9. Calcul des valeurs avant et après l'agrégation

Numéro de ligne A B A * B (avec le

paramètre Somme)

A*B (avec le paramètre Calculé)

1 5 10 50 50

2 10 5 50 50

Total 15 15 100 225

Dans la colonne A*B (avec le paramètre Somme), le calcul est effectué en premier, puis les valeurs sont additionnées (50 + 50 = 100). Dans la colonne A*B (avec le paramètre Calculé), les lignes détaillées sont agrégées en premier (15 pour chaque total), puis les résultats sont multipliés (15*15 = 225).

Chapitre 6. Amélioration du modèle avec des fonctions supplémentaires 27

(32)

Pour plus d'informations, reportez-vous à la documentation connexe des composants suivants :

• Génération de rapports : Rubrique "Fonctions récapitulatives" dans le document IBM Cognos Analytics - Génération de rapports - Guide d'utilisation.

• Module de données : Rubrique "Calculs" dans le document IBM Cognos Analytics - Guide de modélisation des données.

• Framework Manager : Rubrique "Définition de l'ordre des opérations pour les calculs de modèles" dans le document IBM Cognos Framework Manager - Guide d'utilisation.

(33)

Chapitre 7. Optimisation des performances des requêtes

Cognos Analytics est conçu pour tirer pleinement parti de votre infrastructure de données. La principale stratégie d'accès aux données consiste à déléguer, dans la mesure du possible, le traitement des données à un serveur de données.

Dans des scénarios classiques, le volume de données est donc déterminé par la capacité du serveur de données à répondre aux requêtes analytiques en tenant compte du temps d'attente que les utilisateurs peuvent tolérer. En général, les utilisateurs n'aiment pas attendre une requête plus de quelques secondes lorsqu'ils interagissent avec des données.

Cognos Analytics génère des requêtes SQL (Structured Query Language) pour extraire des données de serveurs de données relationnelles. Les utilisateurs doivent attendre que le serveur de données réponde à ces requêtes. Par exemple, lors de la connexion à l'interface SQL d'un serveur de données, Cognos Analytics génère des instructions SQL adaptées au type et à la version de la technologie du serveur de données et optimisées pour réduire le délai d'attente des utilisateurs.

En général, le nombre de lignes qui doivent être transférées du serveur de données vers Cognos Analytics correspond au nombre de valeurs à afficher dans Cognos Analytics. Si un graphique à barres affiche cinq barres dans un tableau de bord Cognos Analytics, seules cinq lignes de données doivent être extraites même si votre serveur de données stocke des milliards d'enregistrements. Le serveur de données traite l'ensemble des jointures, des agrégations, des calculs et des filtres, qui entraînent l'affichage des cinq valeurs dans la visualisation Cognos Analytics.

Il est possible que certaines demandes ne puissent pas être traitées par un serveur de données sous- jacent. Ces types de demande peuvent nécessiter un traitement effectué par le service de requête Cognos Analytics. Bien que ce ne soit pas toujours possible, Cognos Analytics est conçu pour éviter la génération d'instructions SQL qui renvoient un grand nombre de lignes de données dont seul un faible pourcentage est présenté aux utilisateurs. Bien que ces instructions SQL ne soient peut-être pas trop complexes ou trop lourdes pour être traitées sur le serveur de données, elles peuvent entraîner le transfert de grandes quantités de données vers le serveur Cognos Analytics pour un traitement local et augmenter ainsi les temps d'attente.

L'extraction des données directement à partir d'un serveur de données n'est pas toujours souhaitable.

Vous pouvez éviter d'attendre le traitement du serveur de données en activant la mise en cache des données ou en utilisant des ensembles de données.

Les temps de requête peuvent être fortement affectés par des agrégations, des calculs, des jointures et d'autres opérations de ce type qui nécessitent le traitement des données par Cognos Analytics ou un serveur de données. Notez que les tableaux de bord présentent généralement des perspectives

récapitulatives des données, qui peuvent être plus détaillées (granularité fine) au niveau de la source. La première étape recommandée pour identifier et résoudre les problèmes de performances des tableaux de bord consiste à identifier des widgets qui accèdent à des millions de lignes de données stockées, qui sont ensuite traitées pour réduire le nombre de lignes à un petit nombre de valeurs affichées dans une visualisation. Une grande partie de ce temps de traitement pourrait être évité si le résultat final des données présenté à l'utilisateur était prétraité. Pour résoudre ce problème, de nombreuses technologies de serveur de données utilisent le concept de "vue matérialisée", qui représente un résultat précalculé d'une requête accessible à d'autres requêtes. Le même concept peut porter des noms différents.

Les vues matérialisées peuvent réduire le temps d'attente des utilisateurs dans Cognos Analytics en fournissant des données préagrégées au niveau de la clé et des intersections fréquemment demandées de l'agrégation logique. Pour plus d'informations, voir «Comparaison des vues matérialisées sur des serveurs de données à la mise en cache des données dans Cognos Analytics», à la page 30.