Table des matières:
- Les bases
- Y a-t-il une limite au nombre de dimensions?
- Comment choisir les niveaux dans une hiérarchie?
- Bien que presque tous les produits MDDB soient construits autour du concept de faits, de dimensions et de hiérarchies, personne n'a proposé de définition standard MDDB. Dans le monde relationnel, la non-standardisation a également été un problème, en particulier en ce qui concerne les fonctionnalités à valeur ajoutée, telles que les contraintes et les procédures stockées.
Vidéo: Cours d'ACP : théorie et pratique 2024
Les bases de données multidimensionnelles (MDDB) jettent les conventions de leurs ancêtres relationnels et organisent les données de manière très propice à l'analyse multidimensionnelle. Pour comprendre les bases de données multidimensionnelles, vous devez donc d'abord comprendre les bases des fonctions analytiques effectuées avec les données qui y sont stockées.
L'analyse multidimensionnelle est construite autour de quelques concepts simples d'organisation des données - spécifiquement, les faits et les dimensions:
-
Faits: Un fait est une occurrence d'une occurrence ou d'un événement particulier et les propriétés de l'événement sont toutes stockées dans une base de données. Avez-vous vendu une montre à un client vendredi après-midi? C'est un fait. Votre magasin a-t-il reçu hier une livraison de 76 bagues de classe d'un fournisseur en particulier? C'est un autre fait.
-
Dimensions: Une dimension est un descripteur de clé, un index, par lequel vous pouvez accéder aux faits en fonction de la valeur (ou des valeurs) que vous voulez. Par exemple, vous pouvez organiser vos données de vente en fonction de ces dimensions: heure, client et produit.
Les bases
Dans ces exemples simples, vous pouvez organiser et afficher vos données de ventes sous la forme d'un tableau tridimensionnel, indexé par les dimensions heure, client et produit:
-
En octobre 2008 (la dimension temporelle), Client A (la dimension client) a acheté des anneaux de classe (la dimension du produit) - 79 pour 8 833 $.
-
En 2007 (la dimension temporelle), le client A (la dimension client) a acheté de nombreux produits différents (la dimension du produit) - un total de 3, 333 unités pour 55 905 $ (les faits).
Notez le subtil différent entre la façon dont les dimensions sont utilisées dans ces deux exemples. Dans le premier, la dimension temporelle se rapporte à un mois; la dimension client concerne un client spécifique; et la dimension du produit est pour un produit spécifique.
Dans le deuxième exemple, cependant, le temps est pour une année, pas un mois; le client est toujours le même (un client individuel); et le produit est pour toute la gamme de produits.
L'analyse multidimensionnelle prend en charge la notion de hiérarchies dans les dimensions. Par exemple, vous pouvez organiser l'heure dans une hiérarchie d'année → trimestre → mois. Vous pouvez afficher les faits (ou la consolidation des faits) dans la base de données à l'un de ces niveaux: par année, trimestre ou mois.
De même, vous pouvez organiser les produits dans une hiérarchie de familles de produits → type de produit → produits spécifiques. Les anneaux de classe peuvent être un type de produit; "Anneau de classe, style moderne, pierre d'onyx" pourrait être un produit spécifique.En outre, les bagues de classe, les montres, les autres bagues et autres articles se retrouveraient dans la famille des bijoux.
Y a-t-il une limite au nombre de dimensions?
Théoriquement, vous pouvez avoir autant de dimensions dans votre modèle multidimensionnel que nécessaire. La question existe toujours, cependant, de savoir si votre produit de base de données multidimensionnelle peut les prendre en charge. Mais voici une question plus importante - même si un produit permet un certain nombre de dimensions (15, par exemple), est-il sensé de créer un modèle de cette taille?
Vous devriez travailler en étroite collaboration avec vos utilisateurs pour déterminer si le nombre de dimensions rend votre solution trop complexe - et donc limiter la population d'utilisateurs - ou améliore la facilité d'utilisation - et donc augmenter la population d'utilisateurs.
Vous pouvez, par exemple, ajouter une zone géographique à la liste des dimensions qui contient l'heure, le client et le produit afin que vous puissiez voir et organiser les faits en fonction des zones de vente, des états, des villes et des magasins spécifiques.
Comment choisir les niveaux dans une hiérarchie?
Les niveaux dans une hiérarchie vous permettent d'exécuter la fonctionnalité zoom avant . Et en ayant plusieurs niveaux dans une hiérarchie, vous pouvez obtenir rapidement des réponses à vos questions en raison des informations qui ont été définies à chacun de ces niveaux spécifiés, de sorte que les informations n'attendent que vos requêtes.
Parce que les bases de données multidimensionnelles ont des structures assez rigides construites autour du pré - calcul des faits (créer et stocker des agrégats dans la base de données, plutôt que d'agréger et de calculer) plus vous avez de dimensions et plus vous avez de niveaux dans chaque dimension, plus vos besoins de stockage sont importants et plus vos temps de construction ou de chargement sont longs. Structures de base de données physiques dans un MDDB
Bien que presque tous les produits MDDB soient construits autour du concept de faits, de dimensions et de hiérarchies, personne n'a proposé de définition standard MDDB. Dans le monde relationnel, la non-standardisation a également été un problème, en particulier en ce qui concerne les fonctionnalités à valeur ajoutée, telles que les contraintes et les procédures stockées.
Cependant, la structure relationnelle table-rangée-colonne de base a été assez facile à exporter ou à décharger dans un fichier plat d'un certain type, puis à la recharger dans un autre produit SGBDR.
Dans le monde du MDDB, les vendeurs ont adopté différentes approches pour la représentation physique des données de leurs produits respectifs. Ils cherchent tous des moyens de surmonter les problèmes de stockage et de complexité causés par un grand nombre de dimensions (par exemple, plus de 15) et des niveaux de hiérarchie profonds (par exemple, 20 niveaux de profondeur).
Lorsque vous évaluez des produits, ne vous préoccupez pas des techniques de stockage physique: assurez-vous que les représentations logiques fournies avec les produits (telles que les hiérarchies, les niveaux et les faits) peuvent répondre aux besoins de votre entreprise. Éliminer les produits qui semblent maladroits ou qui ont, par exemple, un modèle hiérarchique qui ne semble pas tout à fait correct pour vos données.
Ensuite, après avoir trouvé des produits qui semblent convenir à votre activité, donnez un coup de pied aux pneus (pour ainsi dire) pour voir comment ils fonctionnent à l'intérieur.