Modèle dimensionnel unifié (UDM)

Lorsqu'un utilisateur souhaite récupérer des informations directement à partir d'une source de données, telle qu'une base de données PGI (Progiciel de Gestion Intégré), il doit relever plusieurs défis de taille :

• Le contenu de telles sources de données est le plus souvent hermétique, car il s'adresse davantage aux systèmes et aux développeurs qu'aux utilisateurs.
• Les informations susceptibles d'intéresser l'utilisateur sont généralement réparties sur plusieurs sources de données hétérogènes. Même s'il explore uniquement différentes bases de données relationnelles, l'utilisateur doit comprendre les particularités de chacune, notamment le langage SQL utilisé. De plus, ces sources de données peuvent être de types très différents et comprendre, outre des bases de données relationnelles, des fichiers et des services Web.
• Tandis que de nombreuses sources de données stockent une grande quantité de détails dans les transactions, les requêtes mobilisées dans l'aide à la décision exigent fréquemment des informations de résumé, agrégées. Étant donné des volumes de données en constante augmentation, la récupération de ces valeurs résumées pour l'analyse interactive de l'utilisateur final est parfois interminable.
• Généralement, les règles métier ne sont pas encapsulées dans les sources de données. Les utilisateurs sont livrés à eux-mêmes pour interpréter les résultats.

Le rôle d'un UDM (Unified Dimensional Model) consiste à établir une passerelle entre l'utilisateur et les sources de données. Un UDM est construit sur une ou plusieurs sources de données physiques. L'utilisateur émet des requêtes sur cet UDM, à l'aide d'une large palette d'outils clients, tels que Microsoft Excel.

L'UDM ne constitue qu'une fine couche au-dessus de la source de données et offre à l'utilisateur final les avantages suivants : modèle de données plus simple et plus lisible, indépendance par rapport aux sources de données d'arrière-plan hétérogènes et optimisation des performances des requêtes de type résumé. Dans certains scénarios, il est possible de construire automatiquement un simple UDM. Lorsque l'UDM est construit avec des investissements plus conséquents, les avantages peuvent décupler grâce à la richesse des métadonnées que le modèle peut fournir.

L'UDM offre les avantages suivants.

• Il enrichit considérablement le modèle utilisateur.
• Il fournit des requêtes ultra-performantes prenant en charge l'analyse interactive, même sur des volumes importants de données.
• Il intègre les règles métier dans le modèle pour permettre une analyse plus approfondie.
• Il permet de « boucler la boucle » : les utilisateurs réagissent selon les données affichées.

Modèle de base de l'utilisateur final

Prenons l'exemple d'un utilisateur qui souhaite comparer les ventes à des quotas sur différentes périodes.

Les données de ventes sont stockées dans la base de données principale Sales and Inventory qui contient plusieurs autres tables. Même après avoir identifié les tables concernées, l'utilisateur découvre que les données relatives à une seule entité, telle que Product, s'étalent sur de nombreuses tables. Comme l'intégrité référentielle est assurée par la logique d'application, aucune relation n'est définie entre ces tables. Les données Sales Quotas sont stockées dans la base de données d'une autre application. Aucune des deux bases ne capture de règle métier, comme celle selon laquelle lorsque des quotas sont comparés aux ventes réelles, il est nécessaire d'utiliser la date d'expédition de la commande au lieu des nombreuses autres dates relatives aux commandes (date de la commande, date d'échéance, date prévue, et ainsi de suite).

Accès direct aux sources de données

Prenons tout d'abord le cas d'un utilisateur qui accède directement aux sources de données. L'illustration suivante montre l'exemple d'une requête en cours de construction à l'aide d'un exemple d'outil.

À ce stade, l'utilisateur a considérablement progressé. Ces progrès sont les suivants :

• L'utilisateur a passé en revue les innombrables tables au nom obscur pour dépister celles qui l'intéressent.
• Il a identifié les colonnes qui selon lui doivent être utilisées pour joindre les tables.
• Il a sélectionné les colonnes contenant les détails intéressants, souvent contraint de les extraire d'une masse de détails orientés système. Par exemple, sur 11 colonnes de tables contenant des détails sur les catégories de produits, seules les deux colonnes de noms le concernent réellement.

L'utilisateur doit à présent procéder à la définition des jointures « externes » ou « internes » à utiliser et regrouper les détails pour fournir les agrégats requis.

Cependant, l'utilisateur est confronté à d'autres tâches complexes. Par exemple, comment l'utilisateur peut-il joindre les données qui proviennent de l'autre source de données ? Même si l'une des bases de données prend en charge les requêtes distribuées, la construction de la requête s'étend bien au-delà des compétences de la plupart des utilisateurs, et les outils dont ils disposent pour accomplir cette tâche peuvent s'avérer insuffisants. L'exemple de code illustre une méthode d'interrogation des données externes.

SELECT Quotas.QuotaAmount, Quotas.EmployeeId, …
FROM OPENROWSET('SQLOLEDB','seattle1';
'Sales';'MyPass',
   'SELECT * FROM Forecasts.dbo.SalesQuota’ ) As Quotas

En ce qui concerne les autres sources de données, telles que les services Web, l'utilisateur se voit encore astreint à de lourdes tâches, puisqu'il doit déterminer comment effectuer correctement les appels distants et comment traiter le XML retourné pour le combiner aux autres données.

Enfin, une fois la première requête générée, l'utilisateur doit répéter le même travail pour la requête suivante, et pour toutes les requêtes subséquentes.

Accès aux sources de données à l'aide de UDM

Le schéma suivant illustre, pour sa part, un exemple de construction d'une requête menée via un UDM simple construit sur ces sources de données.

L'interface de conception graphique affichée dans cet exemple est disponible dans les outils de développement fournis avec Microsoft SQL Server 2005. Cependant, elle aurait aussi bien pu provenir d'autres outils clients tels que Office Excel ou Office Web Components (OWC) ou encore l'un des nombreux outils d'analyse et de création de rapports qui prennent en charge l'UDM.

L'arborescence affichée à gauche présente le contenu de l'UDM. Notez les points suivants dans cet exemple :

• Seuls les éléments pertinents, orientés utilisateur, sont exposés à l'utilisateur. Les colonnes système telles que rowguid ou date last modified ne sont pas visibles.
• Les noms utilisés sont des noms conviviaux, et non ceux résultant des conventions d'attribution de nom orientées développeur qui sont employées dans la base de données sous-jacente.

L'UDM regroupe également tous les attributs pour chaque entité métier, telle que Product ou Employee, dans des « dimensions » distinctes. Dans cet exemple, le client pourra donc se référer à Product Color, Subcategory et Category sans effectuer explicitement des jointures entre les nombreuses tables impliquées.

Les colonnes qui exposent les valeurs de transaction ou les mesures sont ensuite présentées comme des « mesures ». Par exemple, les utilisateurs sont généralement amenés à agréger des colonnes telles que le montant des ventes (sales amount) ou le quota des ventes (sales quota). Ce mode de présentation des données sous forme de « mesures » et de « dimensions » s'appelle « modélisation dimensionnelle ».

La partie droite du diagramme affiche les éléments inclus dans la requête en cours. Dans ce cas, pour obtenir le « Montant et quota des ventes par catégorie de produit », l'utilisateur a défini la requête en faisant simplement glisser les trois éléments concernés à partir de l'arborescence vers la partie droite de l'interface de conception graphique. Il n'a pas eu besoin de spécifier les détails nécessaires pour accéder concrètement aux deux différentes sources de données ni d'effectuer les jointures nécessaires entre les nombreuses tables impliquées.

Le modèle définit la mise en forme simple par défaut : l'utilisation des symboles monétaires, par exemple. Une mise en forme plus soignée peut également être définie, notamment la mise en forme conditionnelle telle que l'affichage d'une valeur en rouge si celle-ci est en deçà d'un certain seuil.

Le même modèle prend en charge diverses requêtes. Par exemple, les résultats peuvent être répartis par employé en faisant simplement glisser un attribut à partir de la dimension Employé (Employee).

Élargissement du modèle de base

L'exemple précédent montre combien un UDM, même simple, peut faciliter l'exploration de base de données. Cependant, les utilisateurs sont confrontés à d'autres difficultés lorsqu'il s'agit d'accéder aux données. Par exemple :

• Un UDM qui prend en charge différents types de requêtes émises par plusieurs utilisateurs peut atteindre une taille considérable. Comment faire pour qu'un utilisateur qui se concentre sur une tâche particulière ne soit pas submergé par des informations superflues ?
• Comment répondre à la demande des utilisateurs internationaux qui souhaitent consulter les rapports dans leur langue d'origine ?
• Comment simplifier les questions fréquentes incluant un facteur de temps ? Par exemple, un utilisateur peut souhaiter afficher les ventes par rapport à la même période l'année dernière.

Certaines de ces questions sont étudiées dans cette section, afin de montrer comment l'UDM prend en charge l'élargissement du modèle de base afin de permettre une exploration des données plus évoluée.

Hiérarchies

Même si le regroupement de tous les attributs d'une entité dans une dimension simplifie énormément le modèle pour l'utilisateur, il existe d'autres relations entre les attributs qu'une simple liste ne peut pas exprimer. Dans le cas précédent, Category, SubCategory et SKU définissent l'une des hiérarchies dans lesquelles les produits peuvent être organisés. Comme les utilisateurs souhaitent fréquemment effectuer une analyse à partir de ces hiérarchies, l'UDM permet de définir ces hiérarchies. Par exemple, après avoir consulté les totaux par Category, l'utilisateur peut descendre jusqu'à SubCategory, et enfin jusqu'au niveau le plus bas de SKU. Chaque hiérarchie correspond à une séquence d'attributs qui peuvent être utilisés dans les requêtes pour faciliter les scénarios d'exploration de la hiérarchie.

Le diagramme suivant est un exemple d'affichage des hiérarchies dans une interface utilisateur. Le modèle contient plusieurs hiérarchies différentes en fonction desquelles les produits sont organisés. La requête suivante répond à cette question : « afficher les ventes et les quotas par catégorie de produit, puis les répartir en sous-catégorie ». La requête a été définie en faisant glisser la hiérarchie « Products By Category » vers la grille. Pour afficher des données plus détaillées, l'utilisateur double-clique sur la catégorie « Bike » pour la développer.

L'UDM gère dans le détail la navigation d’un niveau à l'autre d’une hiérarchie. L'UDM gère également dans le détail le fait que les Quotas ne sont pas disponibles au niveau SubCategory, mais uniquement au niveau Category.

La hiérarchie parent-enfant est un type de hiérarchie particulier qui traite des entités ayant une relation compliquée entre elles. Dans l'illustration qui suit, la dimension Employé (Employee) possède une hiérarchie intitulée « Employees By Organization Structure ». Cette hiérarchie facilite la navigation de la relation parent-enfant et l'analyse des valeurs cumulées à chaque niveau de l'organisation. Par exemple, le quota de ventes du directeur commercial, Charles Marshall, inclut la somme des quotas de vente de tout son personnel, ainsi que tous les quotas de vente qui lui sont directement associés.

Catégorisation

Les utilisateurs appliquent naturellement des catégorisations à leurs données. Par exemple, un utilisateur peut estimer que « ces attributs concernent toutes les données personnelles d'un employé » ou « cet attribut est une adresse électronique ». L'UDM fournit deux mécanismes qui ont pour objet précis d'apporter une valeur ajoutée sur la base de ces catégorisations :

• Les dimensions, les attributs et autres objets peuvent être placés dans des catégories signifiantes du point de vue sémantique, assurant ainsi une utilisation plus intelligente dans un outil client. Par exemple, un attribut peut être marqué comme étant une URL. Le rapport qui contient cet attribut peut ensuite permettre la navigation à partir des valeurs de cette URL. Un autre attribut peut être marqué comme étant une adresse électronique. Ce dernier cas permet d'ouvrir automatiquement un nouveau courrier électronique à partir d'une action de l'utilisateur.
• Les mesures, les hiérarchies et autres objets peuvent être regroupés dans des dossiers lisibles pour l'utilisateur. Ce regroupement permet à l'outil de création de rapports d'afficher un large éventail d'attributs tout en restant maniable. Il peut, par exemple, exister un groupe d'attributs étiqueté « Customer Demographics ».

Temps

Les informations relatives au temps sont généralement enregistrées dans la source de données sous-jacente en utilisant les types de données DataTime ou Date. Bien qu'un utilisateur expert en langage SQL ou XPath puisse extraire les informations de date requises pour effectuer le total des données par année, il lui sera difficile de poser des questions d'un autre ordre sur le temps, telles que « Afficher les ventes par jour de la semaine » ou « Répartir par année fiscale, à compter du 1er juillet ».

L'UDM intègre toutefois des connaissances propres au temps, dont les différents calendriers suivants :

• le calendrier naturel ;
• le calendrier fiscal ;
• le calendrier de rapports (« 445 », etc.) ;
• le calendrier de fabrication (13 périodes) ;
• ISO8601

Le modèle peut donc inclure une dimension de temps qui propose un jeu complet d'attributs visant à définir des données détaillées sur chaque journée. Dans l'illustration suivante, l'utilisateur a choisi d'afficher le montant et le quota des ventes de l'année fiscale 2001. Pour ce faire, l'utilisateur a simplement fait glisser l'élément adéquat de l'arborescence vers la zone de filtre. L'UDM peut convertir cette action de l'utilisateur en une plage de dates et connaît également la règle métier selon laquelle la date à inclure dans la requête est la date d'expédition, et non la date d'échéance ou de commande. La jointure appropriée est implicitement réalisée par l'UDM.

De plus, l'UDM assure une prise en charge spécifique pour répondre aux questions courantes relatives au temps, telles que les comparaisons d'une période à une autre : « comparer ce mois au même mois de l'année dernière ».

Traductions

Dans les exemples précédents, le contenu du modèle et les données sont affichés dans une seule langue. Pourtant, les utilisateurs internationaux ont souvent besoin de visualiser les métadonnées dans leur propre langue.

Pour répondre à ce besoin, l'UDM permet de traduire les métadonnées dans n'importe quelle langue. Une application cliente qui se connecte avec des paramètres régionaux spécifiques peut ainsi voir toutes les métadonnées s'afficher dans la langue correspondante.

Le modèle propose également la traduction des données. Un attribut peut procéder à un mappage vers différents éléments de la source de données, assurant la traduction de ces éléments dans plusieurs langues. Ainsi, si l'utilisateur se connecte à l'aide de l'outil utilisé dans les exemples précédents à partir d'un ordinateur client dont les paramètres régionaux sont en français, il affiche l'UDM et les résultats de la requête en français, comme indiqué dans l'illustration.

Perspectives

Même si l'exemple de modèle traité ici est de taille très modeste, des modèles réels peuvent avoir une plus large étendue, incluant des dizaines de mesures et de dimensions, chaque dimension incluant elle-même des dizaines ou des centaines d'attributs. Les utilisateurs engagés dans une tâche donnée n'ont généralement pas besoin d'afficher l'intégralité du modèle. Il est nécessaire de pouvoir définir une vue qui affiche un sous-ensemble du modèle pour éviter d'imposer la totalité du modèle aux utilisateurs.

Ce type de vues fournit pas l'UDM s'appellent des perspectives. Un UDM peut avoir un grand nombre de perspectives, chacune d'entre elles ne présentant qu'un sous-ensemble spécifique du modèle (mesures, dimensions, attributs, etc.) qui correspond à un groupe d'utilisateurs particulier. Chaque perspective peut ensuite être associée aux rôles de sécurité des utilisateurs qui définissent les utilisateurs autorisés à afficher cette perspective.

Par exemple, une perspective intitulé Inventaire de Seattle peut être définie de façon à n'inclure que les mesures du groupe de mesures de l'inventaire, qui masque la hiérarchie « Entrepôt par emplacement », et à faire que la ville par défaut soit « Seattle ».

Sémantique des attributs

Un UDM fournit une sémantique supplémentaire pour les attributs. Ces sémantiques particulières sont destinées à faciliter l'exploitation des informations. Les informations suivantes sont des exemples de sémantiques applicables aux attributs :

• Noms ou clés : si l'on observe la base de données relationnelle, ID_Employé n'est pas nécessairement perçu comme une clé unique, générée par le système et non significative. L'UDM résout ce problème en permettant à l'attribut Employé de posséder à la fois une clé (ID_Employé unique) et un nom (par exemple, une concaténation de Prénom et de Nom). Une requête telle que « afficher les employés » distingue correctement les employés portant le même nom, en utilisant leur ID unique, et affiche le nom qui a un sens pour l'utilisateur.
• Classement : Il faut afficher fréquemment les valeurs des attributs dans un ordre fixe, autre qu'un simple ordre alphabétique ou numérique. L'UDM vous permet de définir un classement par défaut pour répondre à ce besoin. Par Exemple :
  • Les jours de la semaine se succèdent sous la forme Dimanche, Lundi, Mardi, etc.
  • Les priorités s'affichent dans l'ordre comme Élevée, Moyenne et Faible.
• Discrétisation : Pour les attributs numériques, il n'est pas toujours utile d'afficher chaque valeur distincte d'un attribut. Par exemple, l'affichage de l'ensemble des prix pour un produit (9,97 €, 10,05 €, 10,10 €, etc.) s'avère nettement moins utile que l'affichage des ventes par fourchette de prix (<10 €, 10 € - 15 €,...). L'UDM permet de regrouper les attributs dans de telles plages suivant des critères divers.

Indicateurs de performance clés

Les entreprises définissent fréquemment des indicateurs de performance clés qui constituent une métrique essentielle permettant de mesurer leur santé. L'UDM permet la création de ces indicateurs de performance clés afin de simplifier la présentation et le regroupement des données pour les entreprises. Un indicateur de performance clé peut aussi définir un graphique, tel qu'un feu de circulation bon, moyen, mauvais, pour afficher l'état et la tendance.

Chaque indicateur de performance clé de l'UDM définit jusqu'à quatre expressions destinées à chaque métrique de performance :

• valeur réelle
• valeur de l'objectif
• l'état    valeur normalisée comprise entre -1 et 1 qui indique le rapport de la valeur réelle par rapport à la valeur de l'objectif (-1 correspondant à « très mauvais » et 1 à « très bon ») ;
• la tendance   valeur normalisée comprise entre -1 et 1 qui indique l'évolution dans le temps (-1 correspondant à « nette aggravation » et 1 correspondant à « nette amélioration »).

L'utilisation d'indicateurs de performance clés permet aux outils clients de présenter des mesures apparentées de façon nettement plus lisible pour l'utilisateur. L'illustration ci-dessous affiche l'exemple de trois indicateurs de performance clés, organisés en dossiers d'affichage par un outil client.

Performances

L'exploration interactive pratiquée par les utilisateurs requiert des temps de réponse rapides. Les datasets explorés étant souvent très volumineux, ces conditions posent problème.

Pour améliorer les performances, l'UDM propose des services de mise en cache. Ces caches peuvent stocker à la fois les données détaillées lues à partir de la source de données sous-jacente et les valeurs d'agrégation précalculées à partir de ces données Toutefois, le recours à ces valeurs mises en cache peut se traduire par un certain degré d'obsolescence des données. Les besoins commerciaux dictent les exigences en matière d'actualité des données. Dans certains cas, l'affichage des données les plus à jour est indispensable ; dans d'autres, l'affichage de données datant de deux heures, voire de deux jours, convient parfaitement.

Afin de se conformer aux stratégies qui régissent l'actualisation des données, l'UDM autorise une gestion explicite du cache (l'actualisation du cache peut par exemple être planifiée chaque jour à 2 heures) ou transparente à l'aide de la mise en cache proactive. L'utilisateur peut spécifier le degré d'actualisation requis des données. L'UDM assure automatiquement la création et la gestion du cache afin de répondre le plus rapidement possible à la requête.

Analyse

Les sections précédentes décrivaient comment l'UDM prend en charge l'exploration interactive des données. Toutefois, le simple fait de rendre les informations disponibles à partir des sources de données sous-jacentes, même sous une forme nettement plus compréhensible et plus exploitable, ne répond pas de toute évidence à l'objectif qui consiste à insérer un logique métier dans le modèle de l'utilisateur. Par conséquent, l'UDM permet de définir des calculs tant simples que complexes sur les données.

Analyse de base

Les requêtes retournent généralement des données agrégées. Par exemple, une requête classique affiche les ventes par catégorie au lieu d'afficher chaque commande. Cependant, aucune information dans les données relationnelles sous-jacentes ne précise comment agréger une mesure particulière. Par exemple, le montant des ventes peut logiquement s'additionner, mais il faut calculer la moyenne du prix unitaire. L'UDM ajoute cette sémantique.

La méthode d'agrégation peut être définie à l'aide de divers schémas :

• une simple fonction d'agrégation Sum, Count, Distinct Count, Max ou Min peut être utilisée.
• L'agrégation peut être définie comme étant une semi-additive. Cela signifie qu'une simple fonction telle que Sum est utilisée pour toutes les dimensions, sauf celle du temps, pour laquelle Last period prévaut. Par exemple, bien que le niveau de stock puisse être additionné produit par produit, le niveau de stock mensuel n'est pas la somme des niveaux de stock de chaque jour, mais plutôt le niveau de stock au dernier jour du mois.
• L'agrégation peut être axée sur le type de compte (par exemple, les bénéfices par rapport aux dépenses).
• L'agrégation peut être personnalisée pour répondre à des besoins spécifiques.

Un UDM peut également contenir des membres calculés. Ces membres ne sont pas directement associés aux données sources, mais ils en sont plutôt dérivés. Par exemple, un membre calculé, Variance, peut être défini pour calculer l'écart entre les ventes et le quota.

De la même façon, un UDM peut définir des jeux d'entités présentant un intérêt aux yeux de l'utilisateur. par exemple, les 10 meilleurs clients (en termes de volume de ventes) ou les produits les mieux vendus. Ces jeux peuvent ensuite aisément être utilisés pour restreindre l'étendue d'une requête à un jeu d'entités donné.

Analyse avancée

Il arrive parfois que les calculs requis par les utilisateurs soient beaucoup plus complexes que la « Variance » de l'exemple précédent. Voici quelques exemples de calculs complexes :

• Afficher la moyenne mobile sur trois mois de chaque période.
• Comparer la croissance en glissement annuel de cette période à celle de la même période de l'année précédente.
• Si les ventes sont indiquées dans la devise de base, les reconvertir dans la devise d'origine en utilisant le taux de change moyen quotidien au moment de la vente.
• Calculer les ventes budgétisées par catégorie pour l'année prochaine en y ajoutant 10 % par rapport à cette année, puis les répartir sur chaque produit en fonction des ventes moyennes relatives réalisées au cours des trois dernières années.

L'UDM fournit un modèle élaboré pour définir de tels calculs et s'apparente à une feuille de calcul multidimensionnelle, où la valeur d'une cellule peut être calculée à partir des valeurs des autres cellules. Toutefois, même cette métaphore ne parvient toutefois pas à décrire avec justesse la richesse des calculs dans l'UDM. Un cellule peut être calculée non seulement en fonction de la valeur d'une autre cellule, mais aussi en fonction de la valeur qui y figurait. D'où la prise en charge des équations simultanées. Par exemple, les bénéfices sont dérivés des recettes moins les dépenses, mais les primes (incluses dans les dépenses) sont dérivées des bénéfices.

L'UDM propose non seulement le puissant langage d'expressions multidimensionnelles (MDX, Multi Dimensional Expressions), spécialement conçu pour créer de tels calculs, mais il permet également l'intégration à Microsoft.Net. Grâce à cette intégration, des procédures stockées et des fonctions peuvent être écrites dans un langage .NET vérifiable tel que C#.NET ou Visual Basic .NET. Les procédures stockées et les fonctions peuvent ensuite être appelées à partir de MDX en vue d'être utilisées dans les calculs.

Le client est tenu à l'écart des détails de ces calculs. Le modèle offre simplement aux applications clientes des mesures plus efficaces. Dans l'exemple suivant, l'utilisateur consulte différentes mesures calculées sur la base des ventes, concernant les produits les plus rentables vendus aux États-Unis.

Intégration à l'exploration de données

L'affichage de données sous une forme élaborée et facilement compréhensible s'avère extrêmement utile, mais les utilisateurs doivent aussi pouvoir déduire de nouvelles informations à partir de ces données.

L'UDM est étroitement intégré à la technologie d'exploration de données qui permet d'explorer des données, puis d'exploiter les modèles découverts pour effectuer des prévisions.

Rendre les données utilisables

Chez un utilisateur, l'affichage de données suscite souvent immédiatement de nouvelles questions ou le désir d'effectuer une action. Par exemple :

• « Quelles sont les ventes détaillées qui ont contribué à ce nombre ? »
• « Le quota est trop bas. Il faut que je l'augmente. »
• « Cela semble étrange. Je veux ajouter un commentaire à ce nombre. »
• « Quels sont les détails dont nous disposons sur cette promotion sur notre site Web ? »

Il ne suffit pas de présenter les données aux utilisateurs sous une forme facilement compréhensible. Il faut également leur faciliter la tâche lorsqu'ils souhaitent effectuer des actions inspirées par les données qui sont affichées.

L'UDM s'en charge de deux façons :

• en permettant de reporter des modifications dans les données.
• en permettant d'associer des actions aux données.

Écriture différée

L'UDM n'est pas en lecture seule. Les données peuvent également être mises à jour via l'UDM. Dans le cas des mesures, les mises à jour peuvent être maintenues à l'écart des valeurs d'origine, sous forme de modifications apportées à ces valeurs.

Il est également possible de mettre à jour les nombres généraux. Prenons l'exemple d'un scénario de budgétisation. Le montant budgétisé peut en fin de compte être connu jusqu'à un niveau détaillé (par équipe et par compte), mais les valeurs sont connues au départ uniquement à un niveau plus général (par service et par type de compte).

Actions

L'UDM prend en charge les actions sous la forme d'un lien entre les données et une action axée sur les données. Les principaux types d'actions sont les suivants :

• URL : accéder à une URL spécifiée. Ce type d'action permet de diriger l'utilisateur non seulement vers une URL pour obtenir des informations supplémentaires, mais aussi vers une application Web donnée permettant d'effectuer une nouvelle tâche. Par Exemple :
  • pour un produit, accéder au site Web d'une société décrivant ce produit ;
  • pour une combinaison produit/entrepôt, accéder à l'application Web de gestion des stocks, en faisant passer le produit/entrepôt sous la forme de paramètres, afin d'autoriser l'augmentation du niveau du stock de sécurité.
• Création de rapports : exécuter un rapport spécifié. Par exemple, pour un produit donné, l'action peut exécuter un rapport sur un produit paramétré qui décrit le produit et l'état actuel de la commande.
• Extraction : procéder à une extraction jusqu'au niveau de détail le plus bas disponible. Par exemple, un utilisateur étudiant le total des ventes par produit et par client peut procéder à une extraction pour afficher l'ensemble des transactions relatives aux ventes qui font partie du total.

Les actions peuvent être associées à des régions de données spécifiques. Par exemple, une action visant à accéder à une page Web peut s'appliquer à chaque produit, mais l'action visant à afficher les transactions relatives au transfert de stock peut s'appliquer à chaque valeur de quantité par produit et par entrepôt.

Même si les actions sont définies dans le cadre de l'UDM, il appartient à l'application cliente de récupérer le détail des actions applicables, de les proposer à l'utilisateur, puis de lancer l'action le cas échéant.

Sécurité

L'accès à l'UDM peut être contrôlé. Les principales fonctionnalités de sécurité sont les suivantes :

• L'UDM propose une sécurité basée sur les rôles. Des rôles peuvent être définis, des autorisations peuvent être accordées à ces rôles et des utilisateurs peuvent être inclus comme membres appartenant à chaque rôle. Les autorisations réelles d'un utilisateur sont la somme des autorisations accordées à chacun des rôles dont il fait partie. Les autorisations accordées à un rôle peuvent également définir des « refus catégoriques » qui suppriment des droits sans tenir compte des autres rôles dont l'utilisateur peut faire partie.
• Des autorisations administratives (pour modifier un UDM, par exemple) peuvent être accordées indépendamment des autorisations d'accès aux données. D'autres autorisations peuvent également être définies pour la lecture des métadonnées de l'objet et l'accès (en lecture/écriture) aux données.
• Les données peuvent être sécurisées selon un niveau de granularité fin jusqu'à des cellules individuelles. Par exemple, vous pouvez restreindre les possibilités d'affichage des ventes du produit « Widget » au client « ACME ». La sécurité peut être conditionnelle : par exemple, un rôle peut être autorisé à afficher le total des salaires d'un service uniquement si ce service emploie plus de cinq employés.
• Les autorisations peuvent indiquer si des valeurs visibles doivent être utilisées ; dans ce cas, les valeurs ne reproduisent que les membres de niveau inférieur pour lesquels l'utilisateur possède des autorisations. L'accès aux cellules peut également être contingenté, ce qui signifie que les cellules dérivées d'autres cellules sont visibles uniquement si toutes les autres cellules sont également visibles. Par exemple, si les bénéfices sont dérivés des recettes et des dépenses, les utilisateurs peuvent afficher les bénéfices uniquement pour les produits dont ils sont autorisés à afficher les recettes et les dépenses.

Voir aussi

Autres ressources

Concepts d'Analysis Services

Aide et Informations

Assistance sur SQL Server 2005