Mesures et dimensions du cube Olap. Qu'est-ce qu'un cube ? OLAP sur client et serveur

/ De manière cubiste. Application des cubes OLAP dans la pratique de gestion des grandes entreprises


En contact avec

Camarades de classe

Constantin Tokmachev, architecte système

Dans un style cubiste.
Application des cubes OLAP dans la pratique de gestion des grandes entreprises

Peut-être est-il révolu le temps où les ressources informatiques d'une entreprise étaient consacrées uniquement à l'enregistrement d'informations et à des rapports comptables. Dans le même temps, les décisions de gestion étaient prises « à l'œil nu » dans les bureaux, lors de réunions et de réunions. Peut-être qu'en Russie, il est temps de ramener les systèmes informatiques d'entreprise à leur principale ressource : résoudre les problèmes de gestion sur la base des données enregistrées dans l'ordinateur.

À propos des avantages de l'analyse commerciale

Dans la boucle de gestion de l'entreprise, entre les données « brutes » et les « leviers » d'influence sur l'objet géré, il existe des « indicateurs de performance » - KPI. Ils forment une sorte de « tableau de bord », reflétant l'état des différents sous-systèmes de l'objet contrôlé. Doter une entreprise d'indicateurs de performance informatifs et suivre leur calcul et les valeurs obtenues est le travail d'un analyste commercial. Les services d'analyse automatisés, tels que l'utilitaire MS, peuvent fournir une aide significative dans l'organisation du travail analytique d'une entreprise. serveur SQL Analysis Services (SSAS) et sa principale fonctionnalité est le cube OLAP.

Un point supplémentaire doit être souligné ici. Disons que, dans la tradition américaine, une spécialité axée sur le travail avec des cubes OLAP s'appelle BI (Business Intelligence). Il ne faut pas se faire d’illusion : la BI américaine correspond au « business analyst » russe. Sans vouloir vous offenser, mais souvent notre analyste commercial est un « sous-comptable » et un « sous-programmeur », un spécialiste aux connaissances vagues et avec un petit salaire, qui n'a vraiment aucun de ses propres outils et méthodologies.

Un spécialiste BI est en fait un mathématicien appliqué, un spécialiste hautement qualifié qui introduit des méthodes mathématiques modernes dans l'arsenal de l'entreprise (ce qu'on appelait Operations Research - méthodes de recherche opérationnelle). La BI correspond davantage à la spécialité « analyste système » qui était autrefois en URSS, diplômé de la Faculté de mathématiques computationnelles et de mathématiques de l'Université d'État de Moscou. M.V. Lomonossov. Le cube OLAP et les services d'analyse peuvent devenir une base prometteuse pour le poste de travail d'un analyste commercial russe, peut-être après une formation avancée en direction de la BI américaine.

Récemment, une autre tendance néfaste est apparue. Grâce à la spécialisation, la compréhension mutuelle entre les différentes catégories d'employés des entreprises s'est perdue. Un comptable, un gestionnaire et un programmeur, comme « un cygne, une écrevisse et un brochet » dans la fable d’I.A. Krylov, tirent l'entreprise dans des directions différentes.

Le comptable est occupé au reporting ; ses montants, tant dans leur sens que dans leur dynamique, ne sont pas directement liés au processus commercial de l'entreprise.

Le manager est occupé par sa part du processus commercial, mais n'est pas en mesure d'évaluer globalement, au niveau de l'entreprise dans son ensemble, les résultats et les perspectives de ses actions.

Enfin, le programmeur, qui était autrefois (grâce à son éducation) un conducteur d'idées techniques avancées du domaine scientifique au domaine des affaires, est devenu un exécuteur passif des fantasmes du comptable et du gestionnaire, ce n'est donc pas le cas. Il n'est plus rare que les services informatiques des entreprises soient dirigés par des comptables et, en général, par tous ceux qui ne sont pas paresseux. Un manque d'initiative, un programmeur 1C analphabète mais relativement bien payé est un véritable fléau Entreprises russes. (C’est presque comme un footballeur national.) Je ne parle même pas des soi-disant « économistes et avocats », tout a été dit à leur sujet il y a longtemps.

Ainsi, le poste d'analyste d'affaires, doté d'un appareil SSAS à forte intensité de connaissances, maîtrisant les bases de la programmation et de la comptabilité, est capable de consolider le travail de l'entreprise en matière d'analyse et de prévision du processus métier.

Avantages des cubes OLAP

Le cube OLAP est remède moderne analyse de la base de données du système informatique de l'entreprise, qui permet de fournir aux salariés de tous les niveaux de la hiérarchie l'ensemble requis d'indicateurs qui caractérisent processus de fabrication entreprises. Le fait n'est pas seulement que l'interface pratique et le langage de requête flexible du cube MDX (MultiDimensional eXpressions) vous permettent de formuler et de calculer les indicateurs analytiques nécessaires, mais aussi la rapidité et la facilité remarquables avec lesquelles le cube OLAP le fait. De plus, cette rapidité et cette facilité, dans certaines limites, ne dépendent pas de la complexité des calculs et de la taille de la base de données.

Une introduction à OLAP-
Le cube peut être donné par un « tableau croisé dynamique » de MS Excel. Ces objets ont une logique similaire et des interfaces similaires. Mais, comme le montre l'article, les fonctionnalités OLAP sont incomparablement plus riches et les performances sont incomparablement plus élevées, de sorte que le « tableau croisé dynamique » reste un produit de bureau local, tandis qu'OLAP est un produit de niveau entreprise.

Pourquoi le cube OLAP est si efficace pour résoudre tâches analytiques? Le cube OLAP est conçu de telle manière que tous les indicateurs dans toutes les sections possibles sont pré-calculés (en tout ou en partie), et l'utilisateur ne peut « extraire » les indicateurs (mesures) et dimensions (dimensions) requis qu'avec le souris, et le programme peut redessiner les tableaux.

Toutes les analyses possibles dans toutes les sections forment un immense champ, ou plutôt, pas un champ, mais juste un cube OLAP multidimensionnel. Quelle que soit la demande que l'utilisateur (manager, analyste métier, cadre) s'adresse au service d'analyse, la rapidité de réponse s'explique par deux choses : premièrement, les analyses requises peuvent être facilement formulées (soit sélectionnées dans une liste par leur nom, soit spécifiées par un formule en langage MDX ), deuxièmement, en règle générale, elle a déjà été calculée.

La formulation de l'analyse est possible selon trois options : il s'agit soit d'un champ de base de données (ou plutôt d'un champ d'entrepôt), soit d'un champ de calcul défini au niveau de la conception du cube, soit d'une expression du langage MDX lorsque vous travaillez de manière interactive avec le cube.

Cela signifie plusieurs fonctionnalités attrayantes des cubes OLAP. Essentiellement, la barrière entre l'utilisateur et les données disparaît. La barrière se présente sous la forme d’un programmeur d’application qui doit d’abord expliquer le problème (définir une tâche). Deuxièmement, vous devrez attendre que le programmeur de l'application crée un algorithme, écrive et débogue le programme, puis éventuellement le modifie. S'il y a beaucoup d'employés et que leurs exigences sont variées et changeantes, alors toute une équipe de programmeurs d'applications est nécessaire. En ce sens, un cube OLAP (et un analyste commercial qualifié) remplace toute une équipe de programmeurs d'applications en termes de travail analytique, tout comme une puissante excavatrice avec un opérateur d'excavatrice remplace toute une équipe de travailleurs migrants avec des pelles lors du creusement d'un fossé !

En même temps, une autre qualité très importante des données analytiques obtenues est obtenue. Puisqu'il n'y a qu'un seul cube OLAP pour toute l'entreprise, c'est-à-dire Il s'agit du même domaine avec des analystes pour tout le monde, ce qui élimine les divergences gênantes dans les données. Lorsqu'un manager doit confier la même tâche à plusieurs salariés indépendants afin d'éliminer le facteur de subjectivité, mais qu'ils apportent quand même des réponses différentes, que chacun s'engage à expliquer d'une manière ou d'une autre, etc. Le cube OLAP assure l'uniformité des données analytiques aux différents niveaux de la hiérarchie de l'entreprise, c'est-à-dire si un manager souhaite détailler un certain indicateur qui l'intéresse, alors il reviendra certainement aux données de niveau inférieur avec lesquelles travaille son subordonné, et ce seront précisément les données sur la base desquelles l'indicateur de niveau supérieur a été calculé , et non d'autres données, reçues d'une autre manière, à un autre moment, etc. Autrement dit, l’ensemble de l’entreprise voit les mêmes analyses, mais à différents niveaux d’agrégation.

Donnons un exemple. Disons qu'un gestionnaire contrôle les comptes clients. Tant que le KPI des créances en souffrance est vert, cela signifie que tout est normal et qu'aucune action de gestion n'est requise. Si la couleur est passée au jaune ou au rouge, quelque chose ne va pas : on coupe les KPI par services commerciaux et on voit immédiatement les rayons « en rouge ». La section suivante est identifiée par les gestionnaires - et le vendeur dont les clients sont en retard de paiement. (De plus, le montant en souffrance peut être divisé par clients, par conditions, etc.) Le chef de l'entreprise peut contacter directement les contrevenants à n'importe quel niveau. Mais en général, le même KPI (à leurs niveaux hiérarchiques) est vu aussi bien par les chefs de service que par les responsables commerciaux. Par conséquent, pour corriger la situation, ils n'ont même pas besoin d'attendre un « appel sur le tapis »... Bien entendu, le KPI lui-même ne doit pas nécessairement être le montant des paiements en souffrance - il peut s'agir du durée moyenne pondérée des impayés ou, d'une manière générale, le taux de rotation des créances.

Notons que la complexité et la flexibilité du langage MDX, ainsi que les résultats rapides (parfois instantanés), nous permettent de résoudre (en tenant compte des étapes de développement et de débogage) des tâches de contrôle complexes qui autrement n'auraient peut-être pas été posées du tout. en raison de la complexité pour les programmeurs d'applications et de l'incertitude initiale dans la formulation. (Des délais longs pour les programmeurs d'applications pour résoudre des problèmes analytiques dus à des formulations mal comprises et à de longues modifications des programmes lorsque les conditions changent sont souvent rencontrés dans la pratique.)

Faisons également attention au fait que chaque employé de l'entreprise peut récolter sur le terrain général un analyste OLAP exactement la récolte dont il a besoin pour son travail, et ne pas se contenter de la « bande » qui lui est découpée en commun. « rapports standards ».

L'interface multi-utilisateur pour travailler avec un cube OLAP en mode client-serveur permet à chaque employé, indépendamment des autres, de disposer de ses propres blocs d'analyse (rapports), même créés par lui-même avec certaines compétences, qui, une fois définis, sont automatiquement mis à jour - en d'autres termes, ils sont toujours à jour.

C'est-à-dire que le cube OLAP permet de rendre le travail analytique (qui est en fait effectué non seulement par les analystes de réception, mais, en fait, par presque tous les employés de l'entreprise, même les logisticiens et les gestionnaires qui contrôlent les soldes et les expéditions) plus sélectif, «pas en termes généraux», ce qui crée les conditions d'une amélioration du travail et d'une augmentation de la productivité.

Pour résumer notre introduction, notons que l'utilisation de cubes OLAP peut élever la gestion d'une entreprise à un niveau supérieur. L'uniformité des données analytiques à tous les niveaux de la hiérarchie, leur fiabilité, leur complexité, la facilité de création et de modification d'indicateurs, les paramètres individuels, la grande vitesse de traitement des données et, enfin, les économies d'argent et de temps consacrés à la prise en charge de voies analytiques alternatives (programmeurs d'applications, calculs indépendants des employés) ouvrent des perspectives d'utilisation des cubes OLAP dans la pratique des grandes entreprises russes.

OLTP + OLAP : aperçu retour dans la chaîne de gestion de l'entreprise

Voyons maintenant l'idée générale des cubes OLAP et leur point d'application dans la chaîne de gestion d'entreprise. Le terme OLAP (OnLine Analytical Processing) a été introduit par le mathématicien britannique Edgar Codd en plus du terme OLTP (OnLine Transactions Processing) précédemment introduit. Cela sera discuté plus tard, mais E. Codd a bien sûr proposé non seulement les termes, mais aussi les théories mathématiques d'OLTP et d'OLAP. Sans entrer dans les détails, dans l'interprétation moderne, OLTP est une base de données relationnelle, considérée comme un mécanisme d'enregistrement, de stockage et de récupération d'informations.

Méthodologie de solution

Les systèmes ERP (Enterprice Resource Planning), tels que 1C7, 1C8, MS Dynamics AX, disposent d'interfaces logicielles orientées utilisateur (saisie et édition de documents, etc.) et d'une base de données relationnelle (DB) pour stocker et récupérer des informations, représentées aujourd'hui par des logiciels. des produits tels que MS SQL Server (SS).

Notez que les informations enregistrées dans la base de données du système ERP constituent en effet une ressource très précieuse. Il ne s'agit pas seulement que les informations enregistrées assurent le flux documentaire actuel de l'entreprise (extraction des documents, leur ajustement, capacité d'impression et de rapprochement, etc.) et pas seulement la capacité de calculer les états financiers (impôts, audit, etc. ). D’un point de vue managérial, il est bien plus important que le système OLTP (base de données relationnelle) soit en fait un véritable modèle numérique grandeur nature des activités de l’entreprise.

Mais pour gérer le processus, il ne suffit pas d'enregistrer des informations le concernant. Le processus doit être présenté sous la forme d'un système d'indicateurs numériques (KPI) caractérisant son avancement. De plus, des plages de valeurs acceptables doivent être définies pour les indicateurs. Et seulement si la valeur de l'indicateur tombe en dehors de l'intervalle autorisé, une action de contrôle devrait suivre.

À propos de cette logique (ou mythologie) du contrôle (« contrôle par déviation »), tant le philosophe grec Platon, qui a créé l'image du timonier (cybernose), qui s'appuie sur la rame lorsque le bateau dévie du cap, que le Le mathématicien américain Norbert Wiener, qui a créé la science de la cybernétique à la veille de l'ère informatique.

En plus du système habituel d'enregistrement des informations à l'aide de la méthode OLTP, un autre système est nécessaire : un système d'analyse des informations collectées. Ce module complémentaire, qui dans la boucle de contrôle joue le rôle de feedback entre la gestion et l'objet de contrôle, est un système OLAP ou, en bref, un cube OLAP.

En tant qu'implémentation logicielle d'OLAP, nous considérerons l'utilitaire MS Analysis Services, qui fait partie de la livraison standard de MS SQL Server, en abrégé SSAS. Notez que, selon le plan d'E. Codd, le cube OLAP en analyse devrait donner la même liberté d'action complète que celle fournie par le système OLTP et la base de données relationnelle (SQL Server) pour stocker et récupérer des informations.

Logistique OLAP

Regardons maintenant la configuration spécifique appareils externes, programmes d'application et opérations technologiques sur lesquels repose le fonctionnement automatisé du cube OLAP.

Nous supposerons que la société utilise un système ERP, par exemple 1C7 ou 1C8, dans lequel les informations sont enregistrées comme d'habitude. La base de données de ce système ERP se trouve sur un certain serveur et est prise en charge par MS SQL Server.

Nous supposerons également qu'un autre serveur dispose de logiciels installés, notamment MS SQL Server avec l'utilitaire MS Analysis Services (SSAS), ainsi que MS SQL Server Management Studio, MS C#, MS Excel et MS Visual Studio. Ces programmes forment ensemble le contexte requis : les outils et les interfaces nécessaires au développeur de cubes OLAP.

Le serveur SSAS dispose d'un programme distribué gratuitement appelé blat, appelé (avec paramètres) depuis ligne de commande et fournir un service postal.

Aux postes de travail des employés, dans réseau local, entre autres, les programmes MS Excel (versions au moins 2003) sont installés, ainsi que, éventuellement, un pilote spécial pour garantir que MS Excel fonctionne avec MS Analysis Services (sauf si le pilote correspondant est déjà inclus dans MS Excel).

Pour être précis, nous supposerons qu'un système d'exploitation est installé sur les postes de travail des employés. Système Windows XP, et sur les serveurs - Serveur Windows 2008. De plus, laissez MS SQL Server 2005 être utilisé comme SQL Server, avec Enterprise Edition (EE) ou Developer Edition (DE) installé sur le serveur avec le cube OLAP. Dans ces éditions, il est possible d'utiliser ce qu'on appelle. « mesures semi-additifs », c'est-à-dire supplémentaire fonctions d'agrégation(statistiques) autres que les sommes ordinaires (par exemple, extrêmes ou moyennes).

Conception de cube OLAP (cubisme OLAP)

Disons quelques mots sur la conception du cube OLAP lui-même. Dans le langage des statistiques, un cube OLAP est un ensemble d'indicateurs de performance calculés dans toutes les sections nécessaires, par exemple, l'indicateur d'expédition en sections par clients, par marchandises, par dates, etc. En raison de la traduction directe de l'anglais dans la littérature russe sur les cubes OLAP, les indicateurs sont appelés « mesures » et les sections sont appelées « dimensions ». Il s’agit d’une traduction mathématiquement correcte, mais syntaxiquement et sémantiquement peu réussie. Les mots russes « mesure », « dimension », « dimension » ont presque la même signification et l'orthographe, tandis que les mots anglais « mesure » et « dimension » sont différents à la fois dans l'orthographe et le sens. Par conséquent, nous privilégions les termes statistiques russes traditionnels « indicateur » et « coupe », dont le sens est similaire.

Il existe plusieurs options pour la mise en œuvre logicielle d'un cube OLAP par rapport au système OLTP où les données sont enregistrées. Nous ne considérerons qu'un seul schéma, le plus simple, le plus fiable et le plus rapide.

Dans cette conception, OLAP et OLTP ne partagent pas de tables et les analyses OLAP sont calculées de manière aussi détaillée que possible lors de l'étape de mise à jour du cube (processus), qui précède l'étape d'utilisation. Ce schéma est appelé MOLAP (Multidimensionnel OLAP). Ses inconvénients sont l'asynchronisme avec l'ERP et les coûts de mémoire élevés.

Bien qu'officiellement, un cube OLAP puisse être construit en utilisant l'ensemble (des milliers) de tables de bases de données relationnelles du système ERP comme source de données et l'ensemble (des centaines) de leurs champs comme indicateurs ou sections, en réalité cela ne devrait pas être fait. Vice versa. Pour charger dans un cube, il est plus correct de préparer une base de données distincte, appelée « vitrine » ou « entrepôt ».

Plusieurs raisons nous obligent à le faire.

  • Premièrement, Lier un cube OLAP à des tables d'une base de données réelle créera certainement des problèmes techniques. La modification des données dans une table peut déclencher une actualisation du cube, et l'actualisation d'un cube n'est pas nécessairement un processus rapide, le cube sera donc dans un état de reconstruction constante ; Dans le même temps, la procédure de mise à jour du cube peut bloquer (lors de la lecture) les données des tables de la base de données, ralentissant ainsi le travail des utilisateurs lors de l'enregistrement des données dans le système ERP.
  • Deuxièmement, Avoir trop d'indicateurs et de coupures augmentera considérablement la zone de stockage du cube sur le serveur. N'oublions pas que le cube OLAP stocke non seulement les données sources, comme dans le système OLTP, mais aussi tous les indicateurs résumés sur toutes les sections possibles (et même toutes les combinaisons de toutes les sections). De plus, la vitesse de mise à jour du cube et, en fin de compte, la vitesse de création et de mise à jour des analyses et des rapports utilisateur basés sur celles-ci ralentiront en conséquence.
  • Troisième, trop de champs (indicateurs et sections) créeront des problèmes dans l'interface du développeur OLAP, car les listes d'éléments deviendront immenses.
  • Quatrièmement, Le cube OLAP est très sensible aux violations de l'intégrité des données. Le cube ne peut pas être construit si les données clés ne se trouvent pas au niveau du lien spécifié dans la structure des connexions des champs du cube. Les violations d'intégrité temporaires ou permanentes et les champs vides sont courants dans une base de données d'un système ERP, mais cela ne convient absolument pas à OLAP.

Vous pouvez également ajouter que le système ERP et le cube OLAP doivent être situés sur des serveurs différents pour partager la charge. Mais alors, s'il existe des tables communes pour OLAP et OLTP, le problème du trafic réseau se pose également. Des problèmes pratiquement insolubles surviennent dans ce cas lorsqu'il est nécessaire de consolider plusieurs systèmes ERP disparates (1C7, 1C8, MS Dynamics AX) dans un seul cube OLAP.

Probablement, nous pouvons continuer à accumuler des problèmes techniques. Mais surtout, rappelez-vous que contrairement à OLTP, OLAP n'est pas un moyen d'enregistrer et de stocker des données, mais un outil d'analyse. Cela signifie qu'il n'est pas nécessaire de télécharger des données « sales » de l'ERP vers OLAP « juste au cas où ». Au contraire, il faut d'abord développer un concept de gestion d'entreprise, au moins au niveau du système KPI, puis concevoir un entrepôt de données applicatif (entrepôt), situé sur le même serveur que le cube OLAP, et contenant un petit , quantité raffinée de données de l'ERP nécessaires à la gestion.

Sans promouvoir de mauvaises habitudes, le cube OLAP par rapport à OLTP peut être assimilé au fameux « alambic », à travers lequel un « produit pur » est extrait de la « masse fermentée » de l'enregistrement réel.

Nous avons donc compris que la source de données pour OLAP est une base de données spéciale (entrepôt) située sur le même serveur qu'OLAP. Généralement, cela signifie deux choses. Premièrement, il doit y avoir des procédures spéciales qui permettront de créer un entrepôt à partir des bases de données ERP. Deuxièmement, le cube OLAP est asynchrone avec ses systèmes ERP.

Compte tenu de ce qui précède, nous proposons la version suivante de l'architecture du processus informatique.

Architecture des solutions

Supposons qu'il existe de nombreux systèmes ERP d'une certaine société (holding) situés sur différents serveurs, dont nous aimerions voir les données analytiques consolidées dans un seul cube OLAP. Nous soulignons que dans la technologie décrite, nous combinons les données des systèmes ERP au niveau de l'entrepôt, laissant inchangée la conception du cube OLAP.

Sur le serveur OLAP, nous créons des images (copies vierges) des bases de données de tous ces systèmes ERP. Nous effectuons périodiquement (tous les soirs) une réplication partielle des bases de données ERP actives correspondantes sur ces copies vides.

Ensuite, SP (procédure stockée) est lancée qui, sur le même serveur OLAP sans trafic réseau, sur la base de répliques partielles des bases de données du système ERP, crée (ou réapprovisionne) un entrepôt (entrepôt) - la source de données du cube OLAP.

Ensuite, la procédure standard de mise à jour/construction d'un cube basé sur les données de l'entrepôt est lancée (Opération Processus dans l'interface SSAS).

Commentons certains aspects de la technologie. Quel genre de travail les SP effectuent-ils ?

À la suite d'une réplication partielle, les données actuelles apparaissent dans l'image d'un système ERP sur le serveur OLAP. À propos, la réplication partielle peut être effectuée de deux manières.

Premièrement, à partir de toutes les tables de la base de données du système ERP, lors de la réplication partielle, seules celles nécessaires à la construction d'un entrepôt sont copiées. Ceci est contrôlé par une liste fixe de noms de tables.

Deuxièmement, une réplication partielle peut également signifier que tous les champs de la table ne sont pas copiés, mais uniquement ceux impliqués dans la construction de l'entrepôt. La liste des champs à copier est soit précisée, soit créée dynamiquement dans SP à l'image de la copie (si tous les champs ne sont pas initialement présents dans la copie de la table).

Bien entendu, il est possible de ne pas copier des lignes entières du tableau, mais uniquement d'ajouter de nouveaux enregistrements. Cependant, cela crée de sérieux inconvénients lorsqu’il s’agit de comptabiliser « rétroactivement » les révisions de l’ERP, ce qui est souvent le cas dans les systèmes réels. Il est donc plus simple, sans plus attendre, de copier tous les enregistrements (ou de mettre à jour la « queue » à partir d’une certaine date).

Ensuite, la tâche principale de SP est de convertir les données du système ERP au format d'entrepôt. S'il n'existe qu'un seul système ERP, la tâche de conversion se résume principalement à copier et éventuellement reformater les données nécessaires. Mais s’il est nécessaire de consolider plusieurs systèmes ERP de structures différentes dans un même cube OLAP, alors les transformations deviennent plus compliquées.

La tâche de consolider plusieurs systèmes ERP différents dans un cube est particulièrement difficile si les ensembles de leurs objets (répertoires de marchandises, sous-traitants, entrepôts, etc.) se chevauchent partiellement, les objets ont la même signification, mais sont naturellement décrits différemment dans les répertoires. de différents systèmes (au sens de codes, identifiants, noms, etc.).

En réalité, une telle image se présente dans une grande société holding, lorsque plusieurs de ses sociétés autonomes constitutives du même type exercent à peu près les mêmes types d'activités sur approximativement le même territoire, mais utilisent leurs propres systèmes d'enregistrement non convenus. Dans ce cas, lors de la consolidation des données au niveau de l'entrepôt, vous ne pouvez pas vous passer de tables de mappage auxiliaires.

Accordons une certaine attention à l'architecture de stockage en entrepôt. Généralement, un schéma de cube OLAP est représenté sous la forme d'une « étoile », c'est-à-dire comme une table de données entourée de « rayons » de répertoires – des tables de valeurs clés secondaires. Un tableau est un bloc d'« indicateurs » ; les ouvrages de référence sont leurs sections. Dans ce cas, le répertoire, à son tour, peut être un arbre arbitrairement déséquilibré ou une hiérarchie équilibrée, par exemple une classification à plusieurs niveaux de biens ou d'entrepreneurs. Dans un cube OLAP, les champs numériques d'une table de données provenant d'un entrepôt deviennent automatiquement des « indicateurs » (ou mesures), et les sections (ou dimensions) peuvent être définies à l'aide de tables de clés secondaires.

Il s’agit d’une description visuelle « pédagogique ». En fait, l'architecture d'un cube OLAP peut être beaucoup plus complexe.

Premièrement, un entrepôt peut être constitué de plusieurs « étoiles », éventuellement reliées via des annuaires communs. Dans ce cas, le cube OLAP sera une union de plusieurs cubes (plusieurs blocs de données).

Deuxièmement, le « rayon » d'un astérisque peut être non seulement un répertoire, mais tout un système de fichiers (hiérarchique).

Troisièmement, sur la base des sections de dimension existantes, de nouvelles sections hiérarchiques peuvent être définies à l'aide des outils de l'interface développeur OLAP (par exemple, avec moins de niveaux, avec un ordre de niveaux différent, etc.)

Quatrièmement, sur la base des indicateurs et des sections existants, en utilisant des expressions du langage MDX, de nouveaux indicateurs (calculs) peuvent être définis. Il est important de noter que les nouveaux cubes, les nouveaux indicateurs, les nouvelles sections sont automatiquement entièrement intégrés aux éléments d'origine. Il convient également de noter que des calculs mal formulés et des sections hiérarchiques peuvent ralentir considérablement le fonctionnement d'un cube OLAP.

MS Excel comme interface avec OLAP

L'interface utilisateur avec les cubes OLAP est particulièrement intéressante. Naturellement, l'interface la plus complète est fournie par l'utilitaire SSAS lui-même. Cela comprend une boîte à outils de développement de cube OLAP, un concepteur de rapports interactif et une fenêtre travail interactif avec un cube OLAP utilisant des requêtes MDX.

En plus de SSAS lui-même, il existe de nombreux programmes qui fournissent une interface à OLAP, couvrant plus ou moins leurs fonctionnalités. Mais parmi eux, il y en a un qui, à notre avis, présente des avantages indéniables. Il s'agit de MS Excel.

L'interface avec MS Excel est assurée par un pilote spécial, téléchargeable séparément ou inclus dans la distribution Excel. Il ne couvre pas toutes les fonctionnalités d'OLAP, mais avec la croissance des numéros de versions de MS Excel, cette couverture devient plus large (par exemple, dans MS Excel 2007, une représentation graphique des KPI apparaît, ce qui n'était pas dans MS Excel 2003, etc. ).

Bien entendu, outre ses fonctionnalités assez complètes, le principal avantage de MS Excel est la large diffusion de ce programme et sa connaissance étroite de la part de l'écrasante majorité des utilisateurs de bureau. En ce sens, contrairement à d’autres programmes d’interface, l’entreprise n’a pas besoin d’acheter quoi que ce soit de plus et n’a besoin de former personne en plus.

Le grand avantage de MS Excel en tant qu'interface avec OLAP est la possibilité de traiter de manière indépendante les données obtenues dans le rapport OLAP (c'est-à-dire de continuer à étudier les données obtenues à partir d'OLAP sur d'autres feuilles du même Excel, sans plus utiliser les outils OLAP, mais en utilisant les outils Excel habituels).

Cycle de soins nocturnes Facubi

Nous allons maintenant décrire le cycle de calcul quotidien (nuit) du fonctionnement d'OLAP. Le calcul est réalisé sous le contrôle du programme facubi, écrit en C# 2005 et lancé via Task Scheduler sur un serveur avec entrepôt et SSAS. Au début, facubi va sur Internet et lit les taux de change actuels (utilisés pour représenter un certain nombre d'indicateurs dans une devise). Ensuite, effectuez les étapes suivantes.

Tout d'abord, facubi lance des SP qui effectuent une réplication partielle des bases de données de divers systèmes ERP (éléments de détention) disponibles sur le réseau local. La réplication est effectuée, comme nous l'avons dit, sur des « arrière-plans » pré-préparés - des images de systèmes ERP distants situés sur le serveur SSAS.

Deuxièmement, via SP, un mappage est effectué à partir des répliques ERP vers le stockage de l'entrepôt - une base de données spéciale, qui est la source des données du cube OLAP et située sur le serveur SSAS. Dans ce cas, trois tâches principales sont résolues :

  • Données ERP ajusté aux formats de cubes requis ; nous parlons deà la fois sur les tables et les champs de table. (Parfois, le tableau requis doit être « façonné », par exemple à partir de plusieurs feuilles MS Excel.) Des données similaires peuvent avoir différents formats dans différents ERP, par exemple, les champs d'identification de clé dans les répertoires 1C7 ont un code de caractères à 36 chiffres de longueur 8. , et _idrref champs dans les répertoires 1С8 – nombres hexadécimaux de longueur 32 ;
  • pendant le traitement un contrôle logique des données est effectué (y compris l'écriture de « valeurs par défaut » à la place des données manquantes, lorsque cela est possible) et un contrôle d'intégrité, c'est-à-dire vérifier la présence de clés primaires et secondaires dans les classificateurs correspondants ;
  • consolidation de code des objets qui ont la même signification dans différents ERP. Par exemple, les éléments correspondants des répertoires de différents ERP peuvent avoir la même signification, par exemple s'il s'agit de la même contrepartie. Le problème de la consolidation des codes est résolu en construisant des tables de mappage, où divers codes les mêmes objets sont amenés à l'unité.

Troisièmement, facubi lance procédure standard mise à jour des données du cube de processus (à partir des procédures de l'utilitaire SSAS).

Sur la base des listes de contrôle, facubi envoie des e-mails sur la progression des étapes de traitement.

Après avoir exécuté facubi, Task Scheduler lance tour à tour plusieurs fichiers Excel, dans lesquels des rapports ont été pré-créés sur la base d'indicateurs de cube OLAP. Comme nous l'avons dit, MS Excel a un interface logicielle(pilote téléchargeable séparément ou intégré) pour travailler avec des cubes OLAP (avec SSAS). Lorsque vous démarrez MS Excel, les programmes MS VBA (tels que les macros) sont activés, ce qui garantit la mise à jour des données des rapports ; les rapports sont modifiés si nécessaire et envoyés par mail (programme blat) aux utilisateurs selon des checklists.

Les utilisateurs du réseau local ayant accès au serveur SSAS recevront des rapports « en direct » configurés pour le cube OLAP. (En principe, ils peuvent eux-mêmes, sans aucun courrier, mettre à jour les rapports OLAP dans MS Excel qui se trouvent sur leur ordinateurs locaux.) Les utilisateurs en dehors du réseau local recevront soit des rapports originaux, mais avec des fonctionnalités limitées, soit pour eux (après la mise à jour des rapports OLAP dans MS Excel), des rapports spéciaux « morts » seront calculés qui n'accèdent pas au serveur SSAS.

Évaluation des résultats

Nous avons parlé ci-dessus de l'asynchronie d'OLTP et d'OLAP. Dans la variante technologique considérée, le cycle de mise à jour du cube OLAP est effectué la nuit (par exemple, il commence à 1 heure du matin). Cela signifie que dans la journée de travail en cours, les utilisateurs travaillent avec les données d'hier. Étant donné qu'OLAP n'est pas un outil d'enregistrement (regardez la dernière révision du document), mais un outil de gestion (comprenez la tendance du processus), un tel décalage n'est généralement pas critique. Cependant, si nécessaire, même dans la version décrite de l'architecture cubique (MOLAP), la mise à jour peut être effectuée plusieurs fois par jour.

Le temps d'exécution des procédures de mise à jour dépend des caractéristiques de conception du cube OLAP (plus ou moins de complexité, définitions plus ou moins réussies des indicateurs et des sections) et du volume des bases de données des systèmes OLTP externes. Selon l'expérience, la procédure de construction de l'entrepôt prend de quelques minutes à deux heures, la procédure de mise à jour du cube (Process) prend de 1 à 20 minutes. Nous parlons de cubes OLAP complexes qui réunissent des dizaines de structures de type étoile, des dizaines de « rayons » communs (sections de référence) pour celles-ci et des centaines d'indicateurs. En estimant le volume des bases de données des systèmes ERP externes basées sur les documents d'expédition, nous parlons de centaines de milliers de documents et, par conséquent, de millions de lignes de produits par an. La profondeur historique du traitement qui intéressait l'utilisateur était de trois à cinq ans.

La technologie décrite est utilisée dans un certain nombre de grandes entreprises : depuis 2008 dans la Société russe de pêche (RRK) et la Société russe de la mer (RM), depuis 2012 dans la société Santa Bremor (SB). Certaines sociétés sont principalement des sociétés de négoce et d'achat (PPC), d'autres sont des sociétés de production (usines de transformation du poisson et des fruits de mer en République de Moldavie et en République de Biélorussie). Toutes les sociétés sont de grandes sociétés holding, réunissant plusieurs sociétés dotées de systèmes comptables informatiques indépendants et variés - allant des systèmes ERP standards tels que 1C7 et 1C8 aux systèmes comptables « reliques » basés sur DBF et Excel. J'ajouterai que la technologie décrite pour faire fonctionner les cubes OLAP (sans tenir compte de la phase de développement) soit ne nécessite aucun personnel spécial, soit relève de la responsabilité d'un analyste commercial à temps plein. Le problème tourne depuis des années mode automatique, fournissant quotidiennement aux différentes catégories de salariés de l’entreprise des reportings à jour.

Avantages et inconvénients de la solution

L'expérience montre que la solution proposée est assez fiable et simple à utiliser. Il est facilement modifiable (connexion/déconnexion de nouveaux ERP, création de nouveaux indicateurs et sections, création et modification de rapports Excel et de leurs listes de diffusion) avec invariance programme de contrôle facubi.

MS Excel en tant qu'interface avec OLAP offre une expressivité suffisante et permet à différentes catégories d'employés de bureau de se familiariser rapidement avec la technologie OLAP. L'utilisateur reçoit quotidiennement des rapports OLAP « standards » ; en utilisant l'interface MS Excel avec OLAP, vous pouvez créer indépendamment des rapports OLAP dans MS Excel. De plus, l'utilisateur peut continuer à étudier de manière indépendante les informations des rapports OLAP en utilisant les capacités habituelles de son MS Excel.

La base de données d'entrepôt « raffinée », dans laquelle sont consolidés plusieurs systèmes ERP hétérogènes (lors de la construction du cube), même sans aucun OLAP, permet de résoudre (sur un serveur SSAS, en utilisant la méthode de requête en Transact SQL ou la méthode SP , etc.) de nombreux problèmes de gestion appliquée. Rappelons que la structure de la base de données de l'entrepôt est unifiée et bien plus simple (en termes de nombre de tables et de nombre de champs de table) que les structures de base de données de l'ERP d'origine.

Nous notons particulièrement que dans la solution proposée, il existe la possibilité de consolider différents systèmes ERP dans un seul cube OLAP. Cela vous permet d'obtenir des analyses pour l'ensemble du portefeuille et de maintenir une continuité à long terme dans les analyses lorsqu'une entreprise passe à un autre système ERP comptable, par exemple lors du passage de 1C7 à 1C8.

Nous avons utilisé le modèle de cube MOLAP. Les avantages de ce modèle sont la fiabilité de fonctionnement et la rapidité de traitement des demandes des utilisateurs. Inconvénients : OLAP et OLTP sont asynchrones, ainsi que de grandes quantités de mémoire pour stocker OLAP.

En conclusion, voici un autre argument en faveur d’OLAP qui aurait pu être plus approprié au Moyen Âge. Parce que son pouvoir probant repose sur l’autorité. Un mathématicien britannique modeste et clairement sous-estimé, E. Codd, a développé la théorie des bases de données relationnelles à la fin des années 60. La puissance de cette théorie était telle qu'aujourd'hui, après 50 ans, il est déjà difficile de trouver une base de données non relationnelle et un langage d'interrogation de base de données autre que SQL.

La technologie OLTP, basée sur la théorie des bases de données relationnelles, fut la première idée d'E. En fait, le concept des cubes OLAP est sa deuxième idée, exprimée par lui au début des années 90. Même sans être mathématicien, on peut tout à fait s’attendre à ce que la deuxième idée soit aussi efficace que la première. Autrement dit, en termes d'analyse informatique, les idées OLAP vont bientôt conquérir le monde et supplanter toutes les autres. Tout simplement parce que le thème de l’analyse trouve sa solution mathématique globale dans OLAP, et que cette solution est « adéquate » (selon le terme de B. Spinoza) au problème pratique de l’analyse. « Adéquatement » signifie chez Spinoza que Dieu lui-même n'aurait pas pu penser à quelque chose de mieux...

  1. Larson B. Développement de l'analyse commerciale dans Microsoft SQL Server 2005. – Saint-Pétersbourg : « Peter », 2008.
  2. Codd E. Complétude relationnelle des sous-langages de base de données, systèmes de base de données, Courant Computer Science Sumposia Series 1972, v. 6, falaises d'Englwood, New York, Prentice – Hall.

En contact avec

Peut-être que pour certains, l'utilisation de la technologie OLAP (On-line Analytic Processing) lors de la création de rapports semblera quelque peu exotique, donc l'utilisation d'OLAP-CUBE pour eux n'est pas du tout l'une des exigences les plus importantes lors de l'automatisation de la budgétisation et de la comptabilité de gestion.

C'est en fait très pratique à utiliser CUBE multidimensionnel lorsque vous travaillez avec des rapports de gestion. Lors de l'élaboration de formats budgétaires, vous pouvez rencontrer le problème des formulaires multivariés (vous pouvez en savoir plus à ce sujet dans le livre 8, « Technologie de mise en place du budget dans une entreprise » et dans le livre « Mise en place et automatisation de la comptabilité de gestion »).

Cela est dû au fait qu’une gestion efficace d’une entreprise nécessite des rapports de gestion de plus en plus détaillés. Autrement dit, le système utilise de plus en plus de sections analytiques différentes (en systèmes d'information les analyses sont définies par un ensemble d’ouvrages de référence).

Naturellement, cela conduit au fait que les managers souhaitent recevoir des reporting dans toutes les sections analytiques qui les intéressent. Cela signifie que les rapports doivent être amenés à « respirer » d’une manière ou d’une autre. En d’autres termes, nous pouvons dire que dans ce cas nous parlons du fait que la signification du même rapport doit fournir des informations sous différents aspects analytiques. Par conséquent, les rapports statiques ne conviennent plus à de nombreux gestionnaires modernes. Ils ont besoin de la dynamique qu’un CUBE multidimensionnel peut offrir.

Ainsi, la technologie OLAP est déjà devenue un élément obligatoire des systèmes d'information modernes et futurs. Par conséquent, lors du choix d'un produit logiciel, vous devez faire attention s'il utilise la technologie OLAP.

De plus, vous devez être capable de distinguer les vrais CUBES des imitations. L'une de ces simulations est celle des tableaux croisés dynamiques dans MS Excel. Oui, cet outil ressemble à un CUBE, mais en fait ce n'en est pas un, puisqu'il s'agit de tables statiques et non dynamiques. De plus, ils ont une implémentation bien pire de la capacité de créer des rapports en utilisant des éléments de répertoires hiérarchiques.

Pour confirmer la pertinence d'utiliser CUBE dans la construction du reporting de gestion, nous pouvons donner un exemple simple avec un budget commercial. Dans l'exemple considéré, les sections analytiques suivantes sont pertinentes pour l'entreprise : produits, succursales et canaux de vente. Si ces trois analyses sont importantes pour l'entreprise, alors le budget (ou rapport) des ventes peut être affiché en plusieurs versions.

A noter que si vous créez des lignes budgétaires basées sur trois sections analytiques (comme dans l'exemple considéré), cela permet de créer des modèles budgétaires assez complexes et de créer des rapports détaillés à l'aide de CUBE.

Par exemple, un budget de vente peut être élaboré à l'aide d'une seule analyse (répertoire). Un exemple de budget de vente construit sur la base d'une analyse « Produits » est présenté sur Figure 1.

Riz. 1. Un exemple de budget de vente construit sur la base d'une analyse « Produits » dans OLAP-CUBE

Le même budget de vente peut être compilé à l'aide de deux analyses (répertoires). Un exemple de budget commercial construit sur la base de deux analyses « Produits » et « Branches » est présenté sur Figure 2.

Riz. 2. Un exemple de budget de vente construit sur la base de deux analyses « Produits » et « Branches » dans l'OLAP-CUBE du progiciel INTEGRAL

.

S'il est nécessaire de créer des rapports plus détaillés, le même budget de vente peut être compilé à l'aide de trois analyses (répertoires). Un exemple de budget de vente construit sur la base de trois analyses « Produits », « Branches » et « Canaux de vente » est présenté sur figure 3.

Riz. 3. Un exemple de budget de vente construit sur la base de trois analyses « Produits », « Branches » et « Canaux de vente » dans l'OLAP-CUBE du progiciel INTEGRAL

Rappelons que le CUBE utilisé pour générer les rapports permet d'afficher les données dans différentes séquences. Sur figure 3 Le budget commercial est d'abord « élargi » par produit, puis par branche, puis par canal de vente.

Les mêmes données peuvent être présentées dans un ordre différent. Sur Figure 4 le même budget de vente est « élargi » d'abord par produit, puis par canal de vente, et enfin par branche.

Riz. 4. Un exemple de budget de vente construit sur la base de trois analyses « Produits », « Canaux de distribution » et « Branches » dans l'OLAP-CUBE du progiciel INTEGRAL

Sur Figure 5 le même budget de vente est « déployé » d'abord par succursales, puis par produits, puis par canaux de vente.

Riz. 5. Un exemple de budget de vente construit sur la base de trois analyses « Branches », « Produits » et « Canaux de vente » dans le progiciel OLAP-CUBE « INTEGRAL »

En fait, ce n'est pas tout options possibles retrait du budget des ventes.

De plus, vous devez faire attention au fait que le CUBE vous permet de travailler avec structure hiérarchique livres de référence. Dans les exemples présentés, les répertoires hiérarchiques sont « Produits » et « Canaux de distribution ».

Du point de vue de l'utilisateur, dans cet exemple il reçoit plusieurs rapports de gestion (voir. Riz. 1-5), et du point de vue des paramètres dans produit logiciel- c'est un rapport. En utilisant simplement le CUBE, vous pouvez le visualiser de plusieurs manières.

Naturellement, en pratique, un très grand nombre d'options pour éditer divers rapports de gestion sont possibles si leurs articles s'appuient sur un ou plusieurs analystes. Et l’ensemble des analyses lui-même dépend des besoins de détails des utilisateurs. Certes, il ne faut pas oublier que, d'une part, plus l'analyste est grand, plus les rapports peuvent être élaborés. Mais d’un autre côté, cela signifie que le modèle de budgétisation financière sera plus complexe. Dans tous les cas, s'il existe un KUB, l'entreprise aura la possibilité de visualiser le reporting nécessaire dans différentes versions, conformément aux sections analytiques qui l'intéressent.

Il est nécessaire de mentionner plusieurs autres fonctionnalités d'OLAP-CUBE.

Dans un OLAP-CUBE hiérarchique multidimensionnel, il existe plusieurs dimensions : type de ligne, date, lignes, répertoire 1, répertoire 2 et répertoire 3 (voir. Riz. 6). Bien entendu, le rapport affiche autant de boutons avec des répertoires qu'il y en a dans la ligne budgétaire contenant le nombre maximum de répertoires. S'il n'y a pas un seul ouvrage de référence dans une ligne budgétaire, le rapport ne comportera pas un seul bouton avec des ouvrages de référence.

Initialement, l'OLAP-CUBE est construit dans toutes les dimensions. Par défaut, lors de la création initiale du rapport, les dimensions sont situées exactement dans les zones affichées dans Figure 6. C'est-à-dire qu'une dimension telle que "Date" est située dans la zone des dimensions verticales (dimensions dans la zone des colonnes), les dimensions "Lignes", "Répertoire 1", "Répertoire 2" et "Répertoire 3" - dans le zone de dimensions horizontales (dimensions dans les lignes de la zone), et la dimension « Type de ligne » se trouve dans la zone des dimensions « non développées » (dimensions dans la zone de la page). Si une dimension se trouve dans la dernière zone, les données du rapport ne seront pas « développées » sur cette dimension.

Chacune de ces dimensions peut être placée dans l’une des trois zones. Une fois les mesures transférées, le rapport est instantanément reconstruit pour correspondre à la nouvelle configuration de mesure. Par exemple, vous pouvez échanger la date et les lignes avec des ouvrages de référence. Ou vous pouvez déplacer l'un des ouvrages de référence vers la zone de mesure verticale (voir. Riz. 7). En d'autres termes, vous pouvez « tordre » le rapport dans OLAP-CUBE et sélectionner l'option de sortie du rapport qui convient le mieux à l'utilisateur.

Riz. 7. Un exemple de reconstruction d'un rapport après changement de configuration de mesure du progiciel INTEGRAL

La configuration de mesure peut être modifiée soit dans le formulaire principal CUBE, soit dans l'éditeur de carte de modification (voir. Riz. 8). Dans cet éditeur, vous pouvez également glisser et déposer des mesures d'une zone à une autre avec la souris. De plus, vous pouvez échanger les mesures dans une zone.

De plus, sous le même formulaire, vous pouvez configurer certains paramètres de mesure. Pour chaque dimension, vous pouvez personnaliser l'emplacement des totaux, l'ordre de tri des éléments et les noms des éléments (voir. Riz. 8). Vous pouvez également spécifier quel nom d'élément afficher dans le rapport : abrégé (Name) ou complet (FullName).

Riz. 8. Editeur de cartes de mesures du progiciel INTEGRAL

Vous pouvez éditer les paramètres de mesure directement dans chacun d'eux (voir. Riz. 9). Pour cela, cliquez sur l'icône située sur le bouton à côté du nom de la mesure.

Riz. 9. Exemple d'édition du répertoire 1 Produits et services dans

À l'aide de cet éditeur, vous pouvez sélectionner les éléments que vous souhaitez afficher dans le rapport. Par défaut, tous les éléments sont affichés dans le rapport, mais si nécessaire, certains éléments ou dossiers peuvent être omis. Par exemple, si vous devez afficher un seul groupe de produits dans le rapport, vous devez alors décocher tous les autres dans l'éditeur de mesures. Après cela, le rapport ne contiendra qu'un seul groupe de produits (voir. Riz. dix).

Vous pouvez également trier les éléments dans cet éditeur. De plus, les éléments peuvent être réorganisés différentes façons. Après un tel regroupement, le rapport est instantanément reconstruit.

Riz. 10. Exemple de sortie dans un rapport d'un seul groupe de produits (dossier) dans le progiciel INTEGRAL

Dans l'éditeur de dimensions, vous pouvez créer rapidement vos propres groupes, y glisser-déposer des éléments depuis des répertoires, etc. Par défaut, seul le groupe Autre est automatiquement créé, mais d'autres groupes peuvent être créés. Ainsi, à l'aide de l'éditeur de dimensions, vous pouvez configurer quels éléments des ouvrages de référence et dans quel ordre doivent être affichés dans le rapport.


Il convient de noter que tous ces réarrangements ne sont pas enregistrés. Autrement dit, après la fermeture du rapport ou après son recalcul, tous les répertoires seront affichés dans le rapport conformément à la méthodologie configurée.

En fait, tous ces changements auraient pu être apportés initialement lors de la mise en place des lignes.

Par exemple, en utilisant des restrictions, vous pouvez également spécifier quels éléments ou groupes de répertoires doivent être affichés dans le rapport et lesquels ne doivent pas l'être.

Note: le sujet de cet article est abordé plus en détail lors d'ateliers "Gestion budgétaire d'une entreprise" Et "Organisation et automatisation de la comptabilité de gestion" menée par l'auteur de cet article, Alexander Karpov.

Si l'utilisateur a presque régulièrement besoin d'afficher uniquement certains éléments ou dossiers de répertoire dans le rapport, il est alors préférable de définir ces paramètres à l'avance lors de la création des lignes de rapport. Si diverses combinaisons d'éléments de répertoire dans les rapports sont importantes pour l'utilisateur, il n'est alors pas nécessaire de définir des restrictions lors de la configuration de la méthodologie. Toutes ces restrictions peuvent être rapidement configurées à l'aide de l'éditeur de mesures.

04/07/2011 Derek Comingore

Si vous avez travaillé dans un domaine lié à la technologie, vous avez probablement entendu le terme « cube » ; cependant, la plupart des administrateurs et développeurs de bases de données ordinaires ne travaillaient pas avec ces objets. Les cubes fournissent une architecture de données puissante pour agréger rapidement des informations multidimensionnelles. Si votre organisation a besoin d'analyser de gros volumes de données, alors solution idéale ce sera un cube

Qu'est-ce qu'un cube ?

Les bases de données relationnelles ont été conçues pour gérer des milliers de transactions simultanées tout en préservant les performances et l'intégrité des données. De par leur conception, les bases de données relationnelles ne sont pas efficaces pour regrouper et rechercher de grands volumes de données. Pour agréger et renvoyer de gros volumes de données, une base de données relationnelle doit recevoir une requête basée sur un ensemble, dont les informations seront collectées et agrégées à la volée. De telles requêtes relationnelles sont très coûteuses car elles reposent sur plusieurs jointures et fonctions d'agrégation ; Les requêtes relationnelles agrégées sont particulièrement inefficaces lorsque vous travaillez avec de grandes quantités de données.

Les cubes sont des entités multidimensionnelles conçues pour combler cette lacune des bases de données relationnelles. En utilisant un cube, vous pouvez fournir aux utilisateurs une structure de données qui fournit une réponse rapide aux requêtes avec de grands volumes d'agrégation. Les cubes effectuent cette « magie d'agrégation » en agrégeant d'abord les données (dimensions) sur plusieurs dimensions. La pré-agrégation du cube est généralement effectuée lors du traitement. Lorsque vous traitez un cube, vous produisez des agrégations de données précalculées qui sont stockées sous forme binaire sur le disque.

Le cube est la structure de données centrale dans système opérateur Analyse des données OLAP de SQL Server Analytical Services (SSAS). Les cubes sont généralement construits à partir d'une base de données relationnelle sous-jacente appelée modèle dimensionnel, mais sont des entités techniques distinctes. Logiquement, un cube est un entrepôt de données composé de dimensions (dimensions) et de mesures (mesures). Les dimensions contiennent des fonctionnalités descriptives et des hiérarchies, tandis que les dimensions sont les faits que vous décrivez dans les dimensions. Les dimensions sont regroupées en combinaisons logiques appelées groupes de dimensions. Vous associez des dimensions à des groupes de mesures en fonction d'une caractéristique : le degré de détail.

DANS système de fichiers un cube est implémenté sous la forme d'une séquence de fichiers binaires liés. L'architecture binaire du cube facilite la récupération rapide de grands volumes de données multidimensionnelles.

J'ai mentionné que les cubes sont construits à partir d'une base de données relationnelle sous-jacente appelée modèle dimensionnel. Le modèle dimensionnel contient des tables relationnelles (fait et dimension) qui le connectent aux entités du cube. Les tableaux de faits contiennent des dimensions telles que la quantité d'un produit vendu. Les tables de dimensions stockent des attributs descriptifs tels que les noms de produits, les dates et les noms d'employés. En règle générale, les tables de faits et les tables de dimensions sont liées via des contraintes de clé étrangère primaire, les clés étrangères étant situées dans la table de faits (cette relation relationnelle est liée à l'attribut de granularité du cube évoqué ci-dessus). Lorsque les tables de dimensions sont liées directement à une table de faits, un schéma en étoile est formé. Lorsque les tables de dimensions ne sont pas directement liées à une table de faits, le résultat est un schéma en flocon de neige.

Veuillez noter que les modèles dimensionnels sont classés selon l'application. Un datamart est un modèle dimensionnel conçu pour un processus métier unique, tel que les ventes ou la gestion des stocks. Un entrepôt de données est un modèle dimensionnel conçu pour capturer les processus métier des composants afin de faciliter l'analyse des processus inter-métiers.

Logiciels requis

Maintenant que vous avez une compréhension de base de ce que sont les cubes et pourquoi ils sont importants, je vais allumer les engrenages et vous faire découvrir étape par étape la construction de votre premier cube à l'aide de SSAS. Il y a quelques composants de base logiciel, dont vous aurez besoin, donc avant de commencer à construire votre premier cube, assurez-vous que votre système répond aux exigences.

Mon exemple de cube de ventes sur Internet sera construit à partir de la base de données de test AdventureWorksDW 2005. Je vais créer le cube de test à partir d'un sous-ensemble de tables trouvées dans la base de données de test qui seront utiles pour analyser les données de ventes sur Internet. La figure 1 montre la disposition de base des tables de base de données. Puisque j'utilise la version 2005, vous pouvez suivre mes instructions en utilisant SQL Server 2005 ou SQL Server 2008.

Figure 1. Sous-ensemble du magasin de données Adventure Works Internet Sales

La base de données de formation Adventure WorksDW 2005 est disponible sur le site Web CodePlex : msftdbprodsamples.codeplex.com. Recherchez le lien « Les exemples de bases de données de produits SQL Server 2005 sont toujours disponibles » (http://codeplex.com/MSFTDBProdSamples/Release/ProjectReleases.aspx?ReleaseId=4004). La base de données de formation est contenue dans le fichier AdventureWorksBI.msi (http://msftdbprodsamples.codeplex.com/releases/view/4004#DownloadId=11755).

Comme mentionné, vous devez avoir accès à une instance de SQL Server 2008 ou 2005, y compris les composants SSAS et Business Intelligence Development Studio (BIDS). J'utiliserai SQL Server 2008, vous constaterez donc peut-être des différences subtiles si vous utilisez SQL Server 2005.

Création d'un projet SSAS

La première chose à faire est de créer un projet SSAS à l'aide de BIDS. Recherchez BIDS dans le menu Démarrer puis dans le menu Microsoft SQL Server 2008/2005, sous-élément SQL Server Business Intelligence Development Studio. En cliquant sur ce bouton, vous lancerez BIDS avec l'écran de démarrage par défaut. Créer nouveau projet SSAS en sélectionnant Fichier, Nouveau, Projet. Vous verrez la boîte de dialogue Nouveau projet, illustrée par la figure 1. Sélectionnez le dossier Projet Analysis Services et définissez la description du projet sur SQLMAG_MyFirstCube. Cliquez sur OK.

Une fois le projet créé, faites un clic droit dessus dans l'Explorateur de solutions et sélectionnez menu contextuelÉlément de propriétés. Sélectionnez maintenant la section Déploiement sur le côté gauche de la boîte de dialogue SQLMAG_MyFirstCube : Pages de propriétés et examinez les paramètres du serveur cible et de la base de données, comme le montre la figure 2. Si vous travaillez dans un environnement SQL Server distribué, vous devrez vous qualifier. la propriété Target Server avec le nom du serveur sur lequel vous allez déployer. Cliquez sur OK lorsque vous êtes satisfait des paramètres de déploiement de ce projet SSAS.

Définir la source de données

Le premier objet que vous devez créer est la source de données. Un objet source de données fournit le schéma et les données utilisés pour créer les objets associés et à la base du cube. Pour créer un objet source de données dans BIDS, utilisez l'Assistant Source Données Assistant Source.

Démarrez l'Assistant Source de données en cliquant avec le bouton droit sur le dossier Source de données dans le panneau Explorateur de solutions et en sélectionnant Nouvelle source de données. Vous constaterez que la création d'objets SSAS dans BIDS a une nature développementale. Tout d'abord, l'assistant vous guide tout au long du processus de création d'un objet et Réglages généraux. Ensuite, vous ouvrez l'objet SSAS résultant dans le concepteur et le personnalisez en détail si nécessaire. Une fois que vous avez dépassé l'écran d'invite, définissez une nouvelle connexion de données en cliquant sur le bouton Nouveau. Sélectionnez et créez une nouvelle connexion basée sur Native OLEDB\SQL Server Native Client 10 pointant vers celle que vous souhaitez Serveur SQL Serveur propriétaire de l'instance de base de données souhaitée. Vous pouvez utiliser l'authentification Windows ou SQL Server, en fonction des paramètres de votre environnement SQL Server. Cliquez sur le bouton Tester la connexion pour vous assurer que vous avez correctement identifié la connexion à la base de données, puis cliquez sur OK.

Viennent ensuite les informations d'emprunt d'identité qui, comme l'association de données, dépendent de la façon dont l'environnement SQL Server est structuré. L'emprunt de privilèges est le contexte de sécurité sur lequel SSAS s'appuie lors du traitement de ses objets. Si vous gérez votre déploiement sur un serveur unique principal (ou un ordinateur portable), comme je suppose que la plupart des lecteurs le sont, vous pouvez simplement sélectionner l'option Utiliser le compte de service. Cliquez sur Suivant pour terminer l'assistant de source de données et définissez AWDW2005 comme nom de source de données. Il est très pratique d'utiliser cette méthode à des fins de test, mais dans un environnement de production réel, ce n'est pas la meilleure solution. meilleur entrainement- utiliser un compte de service. Il est préférable de spécifier le domaine Comptes pour emprunter les droits de connexion SSAS à la source de données.

Vue de la source de données

Pour la source de données que vous avez définie, l'étape suivante du processus de création du cube SSAS consiste à créer une vue de source de données (DSV). DSV offre la possibilité de séparer le schéma attendu par votre cube de celui de la base de données sous-jacente. Par conséquent, DSV peut être utilisé pour étendre le schéma relationnel sous-jacent lors de la création d'un cube. Certaines des fonctionnalités clés de DSV pour étendre les schémas de sources de données incluent les requêtes nommées, les relations logiques entre les tables et les colonnes calculées nommées.

Allons-y et cliquez avec le bouton droit sur le dossier DSV et sélectionnez Nouvelle vue de source de données pour lancer l'assistant Créer une nouvelle vue DSV. Dans la boîte de dialogue, à l'étape Sélectionner une source de données, sélectionnez une connexion à une base de données relationnelle et cliquez sur Suivant. Sélectionnez les tables FactInternetSales, DimProduct, DimTime, DimCustomer et cliquez sur le bouton fléché droit pour déplacer ces tables vers la colonne Inclus. Enfin, cliquez sur Suivant et terminez l'assistant en acceptant le nom par défaut et en cliquant sur Terminer.

À ce stade, vous devriez avoir une vue DSV située sous le dossier Vues de source de données dans l’Explorateur de solutions. Double-cliquez sur le nouveau DSV pour lancer le concepteur DSV. Vous devriez voir les quatre tableaux pour un DSV donné, comme le montre la figure 2.

Création de dimensions de base de données

Comme je l'ai expliqué ci-dessus, les dimensions fournissent des fonctionnalités descriptives des dimensions et des hiérarchies qui sont utilisées pour permettre l'agrégation au-dessus du niveau de détail. Il est important de comprendre la différence entre une dimension de base de données et une dimension de cube : les dimensions de la base de données fournissent les objets de dimension sous-jacents pour les différentes dimensions du cube qui seront utilisées pour construire le cube.

Les dimensions de base de données et de cube offrent une solution élégante à un concept connu sous le nom de « dimensions de rôle ». Les dimensions basées sur les rôles sont utilisées lorsque vous devez utiliser plusieurs fois une seule dimension dans un cube. La date est un exemple parfait dans cette instance de cube : vous allez construire une seule dimension de date et la référencer une fois pour chaque date pour laquelle vous souhaitez analyser les ventes en ligne. La date du calendrier sera la première dimension que vous créerez. Cliquez avec le bouton droit sur le dossier Dimensions dans l'Explorateur de solutions et sélectionnez Nouvelle dimension pour lancer l'assistant de dimension. Sélectionnez Utiliser une table existante et cliquez sur Suivant à l’étape Sélectionner la méthode de création. À l'étape Spécifier les informations sur la source, spécifiez la table DimTime dans la liste déroulante Table principale et cliquez sur Suivant. Maintenant, à l'étape Sélectionner les attributs de la dimension, vous devez sélectionner les attributs de la dimension temporelle. Sélectionnez chaque attribut, comme le montre la figure 3.

Cliquez sur Suivant. À la dernière étape, saisissez Dim Date dans le champ Nom et cliquez sur Terminer pour terminer l'assistant de dimensionnement. Vous devriez maintenant voir la nouvelle dimension Dim Date située sous le dossier Dimensions dans l’Explorateur de solutions.

Utilisez ensuite l'Assistant Dimension pour créer des dimensions produit et client. Suivez les mêmes étapes pour créer la dimension de base que précédemment. Lorsque vous travaillez avec l'assistant de dimension, assurez-vous de sélectionner tous les attributs potentiels à l'étape Sélectionner les attributs de dimension. Les valeurs par défaut des autres paramètres conviennent à une instance de cube de test.

Créer un cube de vente sur Internet

Maintenant que vous avez préparé les dimensions de la base de données, vous pouvez commencer à créer le cube. Dans l'Explorateur de solutions, cliquez avec le bouton droit sur le dossier Cubes et sélectionnez Nouveau Cube pour lancer l'Assistant Cube. Dans la fenêtre Sélectionner la méthode de création, sélectionnez l'option Utiliser les tables existantes. Sélectionnez la table FactInternetSales pour le groupe de mesures à l’étape Sélectionner les tables du groupe de mesures. Décochez les cases en regard des dimensions Clé de promotion, Clé de devise, Clé de territoire de vente et Numéro de révision à l'étape Sélectionner les mesures, puis cliquez sur Suivant.

Sur l'écran Sélectionner les dimensions existantes, assurez-vous que toutes les dimensions de base de données existantes sont sélectionnées pour être utilisées comme dimensions de cube. Parce que je souhaite garder ce cube aussi simple que possible, désélectionnez la dimension FactInternetSales à l'étape Sélectionner de nouvelles dimensions. En laissant la dimension FactInternetSales sélectionnée, vous créerez ce que l'on appelle une dimension de fait ou dimension dégénérée. Les dimensions de faits sont des dimensions créées à l'aide d'une table de faits de base, par opposition à une table de dimensions traditionnelle.

Cliquez sur Suivant pour passer à l'étape Fin de l'assistant et saisissez « Mon premier cube » dans le champ Nom du cube. Cliquez sur le bouton Terminer pour terminer le processus de l'assistant de création de cube.

Expansion et traitement d'un cube

Vous êtes maintenant prêt à déployer et traiter le premier cube. Cliquez avec le bouton droit sur l’icône du nouveau cube dans l’Explorateur de solutions et sélectionnez Processus. Vous verrez une boîte de message indiquant que le contenu semble obsolète. Cliquez sur Oui pour déployer le nouveau cube sur le serveur SSAS cible. Lorsque vous déployez un cube que vous envoyez Fichier XML for Analisis (XMLA) vers le serveur SSAS cible, qui crée un cube sur le serveur lui-même. Comme mentionné, le traitement d'un cube remplit ses fichiers binaires sur le disque avec les données de la source principale, ainsi que les métadonnées supplémentaires que vous avez ajoutées (dimensions du cube, dimensions et paramètres).

Une fois le processus de déploiement terminé, une nouvelle boîte de dialogue Process Cube apparaît. Cliquez sur le bouton Exécuter pour commencer le traitement du cube, qui s'ouvre avec la fenêtre Progression du processus. Une fois le traitement terminé, cliquez sur Fermer (deux fois pour fermer les deux boîtes de dialogue) pour terminer les processus de déploiement et de traitement du cube.

Vous avez maintenant construit, déployé et traité votre premier cube. Vous pouvez afficher ce nouveau cube en cliquant dessus avec le bouton droit dans la fenêtre de l'Explorateur de solutions et en sélectionnant Parcourir. Faites glisser les dimensions vers le centre du tableau croisé dynamique et les attributs de dimension sur les lignes et les colonnes pour explorer votre nouveau cube. Remarquez la rapidité avec laquelle le cube traite diverses requêtes d'agrégation. Vous pouvez désormais apprécier la puissance illimitée et donc la valeur commerciale, Cube OLAP.

Derek Comingore ( [email protégé]) est architecte senior chez B.I. Voyage, qui possède le statut de partenaire Microsoft dans le domaine de l'analyse commerciale. Possède le titre SQL Server MVP et plusieurs certifications Microsoft



Un fichier de cube autonome (.cub) stocke les données sous un formulaire dans un cube de traitement analytique en ligne (OLAP). Ces données peuvent représenter une partie d'une base de données OLAP provenant d'un serveur OLAP ou peuvent avoir été créées indépendamment de toute base de données OLAP. Pour continuer à travailler avec les rapports de tableau croisé dynamique et de graphique croisé dynamique lorsque le serveur n'est pas disponible ou hors ligne, utilisez un fichier de cube hors ligne.

En savoir plus sur les cubes hors ligne

Lorsque vous travaillez avec un rapport de tableau croisé dynamique ou de graphique croisé dynamique basé sur une source de données provenant d'un serveur OLAP, utilisez l'Assistant Cube hors ligne pour copier les données source dans un fichier de cube hors ligne distinct sur votre ordinateur. Pour créer ces fichiers hors ligne, vous devez disposer d'un fournisseur de données OLAP prenant en charge ces fonctionnalités, tel que MSOLAP de Microsoft SQL Server Analysis Services, installé sur votre ordinateur.

Note: Création et utilisation de fichiers de cube hors ligne à partir de Microsoft SQL Server Analysis Services, sous réserve des conditions et des licences Installations Microsoft Serveur SQL. Passez en revue les informations de licence appropriées pour votre version de SQL Server.

Utilisation de l'assistant de cube hors ligne

Pour créer un fichier de cube hors ligne, utilisez l'Assistant Cube hors ligne pour sélectionner un sous-ensemble de données dans la base de données OLAP, puis enregistrez cet ensemble. Le rapport ne doit pas nécessairement inclure tous les champs inclus dans le fichier et vous pouvez choisir parmi n'importe laquelle de ses dimensions et champs de données disponibles dans la base de données OLAP. Pour réduire la taille du fichier, vous pouvez inclure uniquement les données que vous souhaitez pouvoir afficher dans le rapport. Vous pouvez ignorer toutes les dimensions et, pour la plupart des types de dimensions, également ignorer les détails et les fonctionnalités de niveau inférieur. haut niveau, qui n'ont pas besoin d'être affichés. Pour un fichier hors ligne, tous les éléments pouvant être inclus dans les champs de propriétés disponibles dans la base de données pour ces éléments sont également enregistrés.

Mettre les données hors ligne, puis les remettre en ligne

Pour ce faire, vous devez d'abord créer un rapport de tableau croisé dynamique ou de graphique croisé dynamique basé sur la base de données du serveur, puis créer un fichier de cube autonome à partir du rapport. Par la suite, lorsque vous travaillez avec un rapport, vous pouvez à tout moment basculer entre la base de données du serveur et le fichier hors ligne (par exemple, lorsque vous travaillez sur un ordinateur portable à la maison ou en déplacement, puis reconnectez l'ordinateur au réseau).

Ce qui suit décrit les étapes de base pour mettre les données hors ligne et les remettre en ligne.

Note:

    Cliquez sur le rapport de tableau croisé dynamique. S'il s'agit d'un rapport de tableau croisé dynamique, sélectionnez le rapport de tableau croisé dynamique associé.

    Sur "l'onglet" Analyse" en groupe calculs cliquez sur le bouton Service OLAP et appuyez sur le bouton OLAP hors ligne.

    Sélectionnez un élément OLAP avec connectivité puis cliquez sur le bouton D'ACCORD.

    Si vous êtes invité à rechercher une source de données, cliquez sur Trouver la source et recherchez le serveur OLAP sur le réseau.

    Cliquez sur le rapport de tableau croisé dynamique basé sur le fichier de cube hors ligne.

    Dans Excel 2016 : Sur l'onglet " données" en groupe demandes et connexions Tout mettre à jour et appuyez sur le bouton Mise à jour.

    Dans Excel 2013 : Sur l'onglet " données" en groupe Connexions cliquez sur la flèche à côté du bouton Tout mettre à jour et appuyez sur le bouton Mise à jour.

    Sur "l'onglet" Analyse" en groupe calculs cliquez sur le bouton Service OLAP et appuyez sur le bouton OLAP hors ligne.

    Cliquez sur le bouton Mode OLAP hors ligne, et puis - .

Note: Arrêt dans la boîte de dialogue.

Avertissement:

Création d'un fichier de cube hors ligne à partir d'une base de données de serveur OLAP

Note: Si la base de données OLAP est volumineuse et que le fichier cube est nécessaire pour donner accès à un grand sous-ensemble de données, de nombreuses espace libre sur le disque et la sauvegarde du fichier peut prendre beaucoup de temps. Pour améliorer les performances, il est recommandé de créer des fichiers de cube autonomes à l'aide d'un script MDX.

Problème : Mon ordinateur ne dispose pas de suffisamment d'espace disque lors de l'enregistrement d'un cube.

Les bases de données OLAP sont conçues pour gérer de grandes quantités de données détaillées, de sorte qu'une base de données hébergée sur un serveur peut occuper beaucoup plus d'espace que ce qui est disponible sur votre disque dur local. Si vous sélectionnez une grande quantité de données pour un cube de données hors ligne, vous ne disposerez peut-être pas de suffisamment d'espace disque libre. L'approche suivante aidera à réduire la taille du fichier de cube hors ligne.

Libérez de l'espace disque ou sélectionnez un autre disque Avant d'enregistrer le fichier cube, supprimez-le du disque. fichiers inutiles ou enregistrez le fichier sur un lecteur réseau.

Inclure moins de données dans un fichier de cube hors ligne Réfléchissez à la manière dont vous pouvez minimiser la quantité de données incluses dans le fichier afin que le fichier contienne toutes les données nécessaires à un rapport de tableau croisé dynamique ou à un graphique croisé dynamique. Essayez les étapes ci-dessous.

Connexion d'un fichier de cube hors ligne à une base de données de serveur OLAP

Mise à jour et recréation d'un fichier de cube hors ligne

La mise à jour d'un fichier de cube hors ligne créé à partir des dernières données obtenues à partir d'un cube de serveur ou d'un nouveau fichier de cube hors ligne peut prendre beaucoup de temps et nécessiter une grande quantité d'espace disque temporaire. Exécutez ce processus lorsque vous n'avez pas besoin d'un accès immédiat à d'autres fichiers, après vous être assuré que vous disposez de suffisamment d'espace sur votre disque dur.

Problème : Les nouvelles données n'apparaissent pas dans le rapport lors de l'actualisation.

Vérification de la disponibilité de la base de données source Le fichier de cube hors ligne peut ne pas parvenir à se connecter à la base de données du serveur source pour obtenir de nouvelles données. Assurez-vous que la base de données d'origine sur le serveur qui constitue la source de données du cube n'a pas été renommée ou déplacée vers un autre emplacement. Assurez-vous que le serveur est accessible et peut être connecté.

Vérification de nouvelles données Vérifiez auprès de votre administrateur de base de données si les données qui doivent être incluses dans le rapport ont été mises à jour.

Vérification de l'immuabilité de l'organisation de la base de données Si Cube OLAP serveur a été modifié, l'accès aux données modifiées peut nécessiter la réorganisation du rapport, la création d'un fichier de cube hors ligne ou l'exécution de l'assistant de création de cube OLAP. Pour en savoir plus sur les modifications de la base de données, contactez votre administrateur de base de données.

Inclure d'autres données dans le fichier de cube hors ligne

L'enregistrement d'un fichier de cube hors ligne modifié peut prendre du temps et nécessite de travailler dans Microsoft Excel n'est pas possible lors de l'enregistrement du fichier. Exécutez ce processus lorsque vous n'avez pas besoin d'un accès immédiat à d'autres fichiers, après vous être assuré que vous disposez de suffisamment d'espace sur votre disque dur.

    Vérifiez qu'il existe une connexion réseau et que la base de données du serveur OLAP source à partir de laquelle le fichier de cube hors ligne a obtenu les données est accessible.

    Cliquez sur un rapport de tableau croisé dynamique créé à partir d'un fichier de cube autonome ou sur un rapport de tableau croisé dynamique associé pour un rapport de graphique croisé dynamique.

    Sur l'onglet Possibilités en groupe Service cliquez sur le bouton Service OLAP et appuyez sur le bouton Mode OLAP hors ligne.

    Cliquez sur le bouton Mode OLAP hors ligne, et puis - Modifier le fichier de données hors ligne.

    Suivez l'assistant de cube hors ligne pour sélectionner d'autres données à inclure dans ce fichier. Dans la dernière étape, spécifiez le nom et le chemin d'accès au fichier à modifier.

Note: Pour annuler l'enregistrement du fichier, cliquez sur le bouton Arrêt dans la boîte de dialogue Création d'un fichier cube - progression.

Suppression d'un fichier de cube hors ligne

Avertissement: Si vous supprimez un fichier de cube hors ligne pour un rapport, vous ne pouvez plus utiliser ce rapport hors ligne et vous ne pouvez plus créer de fichier de cube hors ligne pour ce rapport.

    Fermez tous les classeurs contenant des rapports utilisant le fichier de cube hors ligne ou assurez-vous que tous ces rapports sont supprimés.

    DANS Microsoft Windows Recherchez et supprimez le fichier de cube hors ligne (fichier CUB).

Informations Complémentaires

Vous pouvez toujours poser une question à un spécialiste de la communauté Excel Tech, demander de l'aide à la communauté Answers et également suggérer nouvelle fonctionnalité ou amélioration du site internet

Dans un tableau croisé dynamique standard, les données sources sont stockées sur votre disque dur local. De cette façon, vous pouvez toujours les gérer et les réorganiser, même sans accès au réseau. Mais cela ne s'applique en aucun cas aux tableaux croisés dynamiques OLAP. Dans les tableaux croisés dynamiques OLAP, le cache n'est jamais stocké sur le disque dur local. Par conséquent, immédiatement après la déconnexion du réseau local, votre tableau croisé dynamique ne fonctionnera plus. Vous ne pourrez pas y déplacer un seul champ.

Si vous devez encore analyser les données OLAP après une mise hors ligne, créez un cube de données hors ligne. Un cube de données hors ligne est un fichier distinct qui constitue un cache de tableau croisé dynamique et stocke les données OLAP affichées après la déconnexion du réseau local. Les données OLAP copiées dans un tableau croisé dynamique peuvent être imprimées ; ceci est décrit en détail sur le site Web http://everest.ua.

Pour créer un cube de données autonome, créez d'abord un tableau croisé dynamique OLAP. Placez le curseur dans le tableau croisé dynamique et cliquez sur le bouton Outils OLAP dans l'onglet contextuel Outils, qui fait partie du groupe d'onglets contextuels Outils de tableau croisé dynamique. Sélectionnez la commande OLAP hors ligne (Fig. 9.8).

La boîte de dialogue Paramètres du cube de données OLAP hors ligne apparaît à l'écran. Cliquez sur le bouton Créer un fichier de données hors ligne. Vous avez lancé l'assistant de création de fichier de cube de données. Cliquez sur le bouton Suivant pour continuer la procédure.

Vous devez d'abord spécifier les dimensions et les niveaux qui seront inclus dans le cube de données. Dans la boîte de dialogue, vous devez sélectionner les données qui seront importées de la base de données OLAP. L'idée est de spécifier uniquement les dimensions qui seront nécessaires une fois l'ordinateur déconnecté du réseau local. Plus vous spécifiez de dimensions, plus le cube de données autonome sera grand.

Cliquez sur le bouton Suivant pour passer à la boîte de dialogue suivante de l'assistant. Cela vous donne la possibilité de spécifier des membres ou des éléments de données qui ne seront pas inclus dans le cube. En particulier, vous n'aurez pas besoin de la mesure Internet Sales-Extended Amount, sa case sera donc décochée dans la liste. Une case décochée indique que l'élément spécifié ne sera pas importé et occupera inutilement de l'espace sur votre disque dur local.

À la dernière étape, spécifiez l'emplacement et le nom du cube de données. Dans notre cas, le fichier cube s'appellera MyOfflineCube.cub et se trouvera dans le dossier Work.

Les fichiers de cube de données portent l'extension .lionceau

Après un certain temps, Excel enregistrera le cube de données hors ligne dans le dossier spécifié. Pour le tester, double-cliquez sur le fichier, ce qui générera automatiquement un fichier fonctionnel. Classeurs Excel, qui contient un tableau croisé dynamique associé au cube de données sélectionné. Une fois créé, vous pouvez distribuer le cube de données hors ligne à tous les utilisateurs intéressés qui travaillent en mode LAN hors ligne.

Une fois connecté à votre réseau local, vous pouvez ouvrir le fichier du cube de données hors ligne et le mettre à jour ainsi que le tableau de données correspondant. Le principe principal stipule que le cube de données hors ligne est utilisé uniquement pour fonctionner lorsque le réseau local est déconnecté, mais il doit être mis à jour une fois la connexion rétablie. Toute tentative de mise à jour d'un cube de données hors ligne après un échec de connexion entraînera un échec.




Haut