Guide de l'exploration de données économique

Contrairement à la programmation d'application traditionnelle, où les fonctions de l'API changent chaque jour, la programmation de base de données reste fondamentalement la même. La première version de Microsoft Visual Studio .NET a été publiée en février 2002, avec une nouvelle version publiée environ tous les deux ans, sans compter les versions du Service Pack. Ce rythme de changement rapide oblige le personnel informatique à évaluer les applications de leur entreprise tous les deux ans, laissant la fonctionnalité de leur application intacte mais avec un code source complètement différent afin de rester au courant des dernières techniques et technologies.

On ne peut pas en dire autant du code source de votre base de données. Une requête standard de SELECT / FROM / WHERE / GROUP BY , écrite aux débuts de SQL, fonctionne toujours aujourd'hui. Bien sûr, cela ne veut pas dire qu'il n'y a pas eu d'avancées dans la programmation de bases de données relationnelles ; il y en avait, et ils ont été plus logiques que techniques .

Depuis l'époque où Bill Inmon et Ralph Kimball ont publié leurs théories sur la conception d'entrepôts de données, les progrès de la programmation de bases de données se sont concentrés sur la prévention de la perte d'informations précieuses et l'extraction de toutes les informations précieuses des données. Une fois qu'Inmon et Kimball ont introduit le monde des bases de données dans l'entreposage de données, des modifications majeures ont été apportées aux outils ETL (Extract/Transform/Load) qui ont permis aux développeurs de bases de données d'accéder facilement aux métadonnées et aux données provenant de sources de bases de données non relationnelles, avec lesquelles il était difficile de travailler. dans le passé. Cela a augmenté la quantité de données disponibles à partir desquelles extraire des informations précieuses, et cette augmentation des données disponibles a conduit à des progrès dans le traitement des données via des cubes OLAP et des algorithmes d'exploration de données.

L'ajout d'un entrepôt de données, de cubes OLAP et d'algorithmes d'exploration de données à votre architecture de base de données peut considérablement rationaliser les processus métier et mettre en lumière des modèles dans vos données dont vous n'auriez jamais soupçonné l'existence. L'automatisation peut également avoir un impact profond sur les capacités d'informatique décisionnelle.

Cependant, avant de commencer à ajouter de nouveaux outils et technologies, vous devez vous assurer que la base de données des transactions est correctement créée.

Base de données des transactions

La base de données de transactions est la base, et si votre base de données de transactions n'est pas fiable et précise, ajouter quoi que ce soit par dessus est une recette pour un désastre.

Un point important à garder à l'esprit lors de l'ajout de couches supplémentaires à votre base de données est que tous les projets doivent montrer un retour sur investissement , c'est pourquoi il est préférable de tirer le meilleur parti de votre architecture actuelle avant d'ajouter d'autres couches. Toutes ces couches utilisent des données provenant d'une base de données de transactions. Dans de nombreuses situations, vous pouvez obtenir le même résultat en interrogeant simplement votre base de données de transactions. Bien sûr, lire tous vos rapports à partir d'un entrepôt de données ou d'un cube OLAP est la méthode idéale, mais lorsqu'une organisation n'est pas prête pour ce niveau de complexité, il est plus important que ses besoins en matière de rapports soient satisfaits en premier. Une fois les besoins de reporting de base satisfaits, il est beaucoup plus facile d'entamer une discussion sur la manière dont un entrepôt de données approprié, et éventuellement un cube OLAP, peut bénéficier à son activité.

Presque tous les programmeurs connaissent les trois règles de normalisation des bases de données. Les procédures stockées lues à partir de la base de données de transactions constituent le chemin vers l'optimisation. Les problèmes à rechercher sont la lisibilité, les appels multiples à la même table de base de données et l'utilisation inutile de variables.

Tous les programmeurs de base de données d'élite sont pointilleux sur la lisibilité de leurs procédures stockées. Il existe quelques points communs dans la façon dont les professionnels des bases de données formatent leurs requêtes, ce qui est différent de celui d'un développeur d'applications. En règle générale, les mots-clés et les fonctions d'agrégation sont en majuscules, tandis que les noms de table et de champ utilisent soit la casse camel, soit des traits de soulignement. Les alias de table ont une certaine corrélation avec le nom réel de la table. L'alignement des sections de la procédure stockée a un certain type de modèle de bloc.

Vous trouverez ci-dessous un exemple de requête qui utilise un format lisible.

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

La prochaine chose à rechercher est si une requête touche une table plus d'une fois. Dans la plupart des requêtes, une table n'a besoin d'être accédée qu'une seule fois, à l'exception des rares fois où vous devez agréger une autre fonction d'agrégation. C'est une autre erreur que font certains programmeurs d'applications, peut-être parce qu'un programmeur d'applications pense en termes de conception orientée objet.

La conception orientée objet crée des objets séparés pour chaque élément de données unique, mais un programmeur de base de données doit penser en termes de logique d'ensemble. Le simple fait qu'une requête accède à une table plus de fois que nécessaire ne signifie pas que la requête produit des données inexactes, mais les performances de la requête sont affectées.

Un autre problème est la suppression ou la duplication des enregistrements à chaque fois que vous avez une jointure, ce qui compromet l'exactitude de votre requête. L'utilisation inutile de variables est un autre signe qu'une requête a été développée par un développeur d'applications. Les développeurs d'applications utilisent des variables dans leur code alors qu'une requête a très rarement besoin d'utiliser des variables, sauf lorsqu'elles sont déclarées en tant que paramètre de la procédure stockée. Une fois de plus, c'est un signe que le développeur ne pensait pas en termes de logique d'ensemble.

ETL (charge de transformation d'extraction) et création de rapports

Une fois que la base de données de transactions d'un client contient des requêtes qui fonctionnent correctement, l'étape suivante consiste à rationaliser les processus métier.

Le moyen le plus simple d'identifier les besoins d'une entreprise en matière de processus ETL ou de rapports automatisés est de savoir qui lit les données d'une base de données de transactions, puis de manipuler les données à l'aide d'une feuille de calcul. Une feuille de calcul a la même structure qu'une table de base de données. Les deux contiennent des lignes et des colonnes. Si vous avez des utilisateurs finaux qui manipulent des données par eux-mêmes, vous devriez vous demander : « Pourquoi ce processus ne peut-il pas être automatisé ? »

L'automatisation des processus métier offre un retour sur investissement immédiat et doit toujours être envisagée avant de passer à des projets plus coûteux, tels que l'entreposage de données. L'identification des utilisateurs finaux manipulant des données via une feuille de calcul peut sembler simple, mais il y a une mise en garde à ce processus.

Les développeurs aiment automatiser les processus ; c'est ce qu'ils font. Les utilisateurs finaux n'aiment pas nécessairement les processus automatisés, surtout s'ils menacent leur travail. Alors, ne soyez pas naïf et pensez que les utilisateurs finaux vont se précipiter vers vous et identifier les tâches quotidiennes qui peuvent être automatisées. Vous devez vraiment prendre l'initiative d'identifier les opportunités de rationalisation.

Un système ETL bien construit devrait également permettre de revenir en arrière sur toutes les données chargées dans une base de données de transactions vers le fichier source d'origine. Il s'agit d'un élément essentiel de l'architecture de la base de données. Si vous ne connaissez pas la date/heure exacte à laquelle chaque enregistrement a été ajouté, ainsi que le nom de la source (nom d'utilisateur ou nom de fichier) qui a ajouté les enregistrements, vous n'êtes pas prêt à gérer les mauvaises données chargées dans votre base de données de transactions. Vous devriez vous demander : "Et si quelqu'un nous envoie un mauvais fichier ?" Combien de temps vous faudrait-il pour identifier les enregistrements qui en sont issus ?

Entrepôt de données

Il existe deux théories pour la conception d'un entrepôt de données. La différence entre les théories d'Inmon et de Kimball peut être résumée comme suit :

La théorie d'Inmon consiste à développer d'abord un entrepôt de données, puis à créer des magasins de données dimensionnels pour les rapports à partir de l'entrepôt de données. La théorie de Kimball consiste à développer d'abord des datamarts dimensionnels pour le reporting, puis à les fusionner pour créer l'entrepôt de données.

Vous voulez toujours offrir aux clients le retour sur investissement le plus rapide. La construction de data marts est un processus simple. Vous commencez par prendre les requêtes sous-jacentes à vos rapports et modifiez-les de renvoyer des ensembles de résultats au stockage des ensembles de résultats dans des tables permanentes. Vous ajoutez simplement TRUNCATE TABLE tablename ; INSERT INTO nom de table avant le mot-clé SELECT d'origine. Une fois que vous avez quelques tables de datamart fonctionnelles, l'identification des opportunités de fusion des datamarts devrait se mettre en place ; recherchez les requêtes de rapport qui utilisent la même liste de tables, puis fusionnez la liste des champs. Cela nécessite une requête plus compliquée, en particulier lorsque la liste des tables augmente. Cependant, tant que vous testez minutieusement la requête, chaque modification incrémentielle peut être effectuée sans perturber les processus métier normaux.

Chaque fois que vous apportez une amélioration à la conception d'un entrepôt de données Kimball, vous avez la possibilité de montrer un retour sur investissement au client. En effet, l'entrepôt de données est construit en premier et les magasins de données de reporting sont construits à partir d'un entrepôt de données statique. Par conséquent, vous engagez la majorité de vos coûts au début du projet d'entrepôt de données.

Cube OLAP

Un cube OLAP peut bénéficier à une organisation en fournissant des données agrégées avec un temps de réponse rapide, des capacités d'exploration ad hoc pour les utilisateurs finaux et l'exploration de données. Lorsque vous disposez d'un cube OLAP approprié, vous pouvez extraire chaque bit de valeur de vos données. Un cube OLAP est construit au-dessus d'un entrepôt de données, mais il utilise un langage différent, MDX, d'une base de données SQL standard. Il nécessite également un effort de configuration plus complexe qu'un serveur de base de données. Cette complexité rend un projet OLAP coûteux, et il est difficile de trouver des développeurs MDX expérimentés.

Les architectes de données voient parfois des cubes OLAP existants avec rien de plus qu'un simple tableau de bord utilisant le cube, sans un seul processus qui ne pourrait pas être remplacé par une requête SQL, un entrepôt de données ou un rapport prédéfini. Un cube OLAP peut fournir un temps de réponse plus rapide qu'un rapport prédéfini, mais dans la plupart des situations, la différence est négligeable. Vous pouvez également bénéficier des fonctionnalités d'exploration vers le bas, cependant, avant de fournir des fonctionnalités d'exploration vers le bas aux utilisateurs finaux, il est judicieux d'utiliser des rapports prédéfinis qui fournissent une interface ad hoc similaire.

Cela vous permet d'enregistrer les requêtes ad hoc exécutées par les utilisateurs finaux, puis d'identifier de nouveaux rapports prédéfinis dont les utilisateurs finaux ne savaient pas qu'ils pouvaient être créés. Étant donné que les améliorations du temps de réponse et de l'exploration en profondeur sont généralement minimes lors du développement d'un cube OLAP, il n'est pas nécessaire de le suggérer à un client tant qu'il n'a pas besoin d'une architecture de base de données capable de gérer l'exploration de données impliquée. C'est à ce moment-là que vous pouvez vraiment impressionner les clients et leur montrer quelque chose sur leur entreprise qu'ils n'auraient peut-être jamais connu sans une architecture de base de données robuste.

Comme mentionné précédemment, la construction d'un cube OLAP peut être difficile. C'est une bonne politique d'envisager un cube OLAP hybride. PowerPivot de Microsoft Excel fournit des outils d'exploration de données faciles à utiliser sans la complexité d'un cube OLAP complet. Le principal inconvénient d'un hybride est qu'il n'a pas le même temps de réponse. Cependant, un grand avantage est qu'il est plus facile de créer des rapports d'exploration de données à l'aide d'Excel par rapport à l'utilisation de MDX. Lors de l'exploration de données, trois rapports sont utiles. Nous pouvons regarder quelques exemples du monde réel et comment les interpréter.

Tous ces rapports proviennent d'une application de day trading automatisée construite par l'auteur.

Rapports visuels

Rapport de diagramme de dispersion

Un rapport de diagramme de dispersion est un rapport de niveau de détail qui compare deux variables. L'ajout de couleur et de taille aux points réels permet de visualiser les résultats réels par rapport à ces variables.

Rapport sur la boîte et les moustaches

Ce rapport résume les valeurs x et y du rapport de nuage de points. Les valeurs de l'axe x sont discrétisées dans un ensemble de compartiments.

Les extrémités de chaque moustache (ligne) représentent les valeurs aberrantes. Les barres jaune et bleu clair représentent les plages d'écart type supérieure et inférieure.

Modèle de régression linéaire

Ce rapport montre la corrélation entre les valeurs des axes x et y, ainsi qu'un lissage de la ligne, qui peut être représenté par une formule mathématique. La valeur R au carré est incluse pour montrer la fiabilité de la corrélation.

Conclusion

Au fur et à mesure que votre entreprise grandit, votre base de données grandira également.

La plupart des organisations n'ont pas initialement besoin d'un professionnel des bases de données ou d'une société spécialisée dans la science des données pour répondre à leurs besoins. Au lieu de cela, leur personnel informatique gère plusieurs responsabilités ou, comme le dit le proverbe, « porte plusieurs chapeaux ». Cela fonctionne jusqu'à un certain point, mais finalement, vous devez faire appel à des spécialistes.

Les éléments répertoriés dans ce document constituent un moyen simple et rapide d'identifier les problèmes de base de données dont vous n'aviez peut-être pas connaissance. J'espère qu'il a également expliqué comment vous pouvez créer des outils d'exploration de données de premier ordre sans dépenser beaucoup d'argent en licences logicielles coûteuses. De cette façon, vous aurez une meilleure idée des avantages que votre organisation pourrait tirer de l'ajout d'un professionnel des bases de données à votre personnel informatique.