Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

25 Chapitre 2 Théories de la Business Intelligence Théories de la Business Inte

25 Chapitre 2 Théories de la Business Intelligence Théories de la Business Intelligence 1. Architectures des systèmes décisionnels Depuis les premières requêtes sur les sources de données OLTP consolidées dans un tableur, les systèmes décisionnels se sont développés et ont pris maintes formes. Mais si la constitution d'un DW (Data Warehouse) d'entre- prise est considérée comme le must, cette solution est souvent surdimension- née. 1.1 Variétés des systèmes décisionnels L'informatique décisionnelle a pour objectif de mettre l'information métier cachée dans les systèmes opérationnels à la portée des décideurs, fussent-ils eux même opérationnels. Chaque entreprise possède sa propre expérience métier, sa propre infrastructure opérationnelle, sa propre organisation et ses propres objectifs. Il n'existe pas de recette miracle. Le système décisionnel doit être adapté au besoin des utilisateurs. Si le système opérationnel est loin d'être surchargé, et que la structure de stockage des données est connue, créer un simple outil d'extraction métier peut suffire. © Editions ENI - All rights reserved 26 Implémentation d’une solution de Business Intelligence SQL Server 2012 Si les clients de cet outil sollicitent trop la base, c'est souvent qu'ils sont plu- sieurs à demander la même information au même moment, juste avant une réunion par exemple. Dans ce cas publier cette information sur l'intranet, ou la pousser dans leur boîte aux lettres, permet de diminuer cette sollicitation. Lorsque les extractions deviennent trop longues ou qu'elles provoquent un ralentissement de l'activité, une simple réplication synchrone ou asynchrone de la base opérationnelle de données peut servir de source aux analyses et sup- prime la surcharge. Et certaines solutions préfèrent embarquer avec le schéma de données OLTP un schéma dédié au reporting automatiquement maintenu à jour. Si cette réplication n'est pas optimale car plusieurs bases de données sont concernées, la mise en place d'un ODS (Operational Data Store) est envisa- geable. L'ODS est une base de données dans laquelle plusieurs bases opéra- tionnelles sont répliquées. La réplication comporte une valeur ajoutée : identification des liens entre les différentes sources ou suppression des don- nées aberrantes... Elle est utile pour le reporting opérationnel et sert de source aux systèmes décisionnels. Au sein de l'ODS les données sont volatiles : elles ont la même profondeur d'historique que dans les systèmes répliqués. Si cet historique ne suffit pas aux yeux des décideurs, ils peuvent lancer un projet de DW opérationnel. L'entre- pôt de données opérationnel est proche de l'ODS, mais la profondeur d'histo- rique y est plus conséquente. Le DW opérationnel isole les systèmes source des traitements analytiques, mais du fait de sa structure proche de celle des systèmes OLTP il n'apporte pas de réponse à la complexité des lectures. Une couche applicative, parfois nommée univers, peut suffire à masquer cette complexité au travers d'objets métier familiers aux utilisateurs finaux. Mais pour certains utilisateurs finaux, les volumes de données à traiter sont tels qu’une couche logique métier seule ne suffit pas. Pour ceux-là, il est pos- sible de créer un DM (Data Mart), ou un cube, voire les deux. 27 Théories de la Business Intelligence Chapitre 2 Le DM est un ensemble de tables de données organisées dans une structure qui favorise la lecture pour du reporting analytique sur un historique plus important que celui conservé en production. Le DM est réellement orienté vers l'utilisateur final et les données et les axes d'analyses sont préparés selon son besoin. Le cube est très proche du DM, mais il contient en plus des données pré-agré- gées sur les divers niveaux des axes d'analyse. Ces agrégats constitués à l'avance permettent de réduire considérablement les temps de réponse aux demandes des utilisateurs. Il existe plusieurs types d'agrégat, le plus courant étant la somme. Toute donnée qui peut être sommée sur n'importe quel axe d'analyse tirera un grand avantage du cube, à partir du moment où vous en avez plusieurs millions de lignes. Le cube peut être construit à partir du DM ou directement à partir d'une autre source. La réunion dans une même base de plusieurs DM prend souvent le nom de DW décisionnel (Data Warehouse décisionnel). Enfin, certains appellent la réunion de plusieurs cubes un hypercube. Pour mener à bien un projet de DM, de DW ou de cube, il faut dès son initia- lisation penser à distribuer la donnée analytique vers les utilisateurs. Les inte- ractions entre le Back-End et le Front-End sont souvent plus importantes que prévu. Il faudra définir différentes catégories d'utilisateurs, définir leurs pro- fils, leurs besoins et l'outil qu'ils utiliseront. Certains demandent à creuser en profondeur la base de données décisionnelle pour y découvrir des modèles sta- tistiques (Data Mining), d'autres attendent un graphique sur leur smartphone, sans parler de ceux qui désirent manipuler les chiffres dans leur tableur favo- ri... Le système s'appuie sur les applications de Business Intelligence (BI appli- cations) utilisées pour distribuer les informations stockées dans le système. Les applications de BI sont soit des solutions du marché, soit des développe- ments spécifiques. Elles prennent la forme d'un portail web, d'un client lourd, d'un composant réutilisable dans le système d'information de l'entreprise... L'informatique décisionnelle est donc très variée. Et il n'est pas possible d'en traiter tous les aspects ici. Nous allons en développer plusieurs points clés dans ce chapitre, pour permettre au lecteur de bien comprendre les chapitres sui- vants. © Editions ENI - All rights reserved 28 Implémentation d’une solution de Business Intelligence SQL Server 2012 1.2 Data Mart et Data Warehouse Une des premières choses à réaliser quand un projet de BI est lancé, est de cla- rifier le sens des termes DM (Data Mart) et DW (Data Warehouse). Les défini- tions de ces deux expressions donnent lieu à d'incessants débats. Data Mart Un DM est un ensemble de données isolé des systèmes opérationnels, dédié à l'aide à la prise de décision, et son périmètre fonctionnel est généralement focalisé sur un point précis de l'activité de l'entreprise. Les données du DM sont entre autres exprimées sur un axe temporel, avec une profondeur définie. Par exemple, l'expression des ventes aux grossistes sur l'Europe, par jour, pour les trois dernières années est un DM. Il intéressera d'autant plus les utilisa- teurs s'il contient des informations sur les produits vendus, les promotions accordées, les régions des clients... Autre exemple de DM, les quantités de SMS passés le mois dernier, heure par heure. Comme le DM est créé pour être lu par des outils de décision, les données y sont structurées d'une manière adaptée à la lecture. Les créateurs du système OLTP normalisent les tables. Ceux du système décisionnel effectuent l'opéra- tion inverse : la dénormalisation. Le DM peut consolider plusieurs sources de données OLTP. Pour ce faire, les données sont préalablement nettoyées et rapprochées. Data Warehouse S'il y a généralement consensus autour du DM, les choses se compliquent avec le DW. Il existe des DW opérationnels et des DW décisionnels. Le périmètre du DW définit également deux catégories : le DW d'entreprise et le DW d'application... Le DW opérationnel est normalisé logiquement comme les applications source dont il conserve l'historique des données. Il est précieux comme source de construction des DM. Le DW décisionnel est dénormalisé. C'est un ensemble cohérent de DM. 29 Théories de la Business Intelligence Chapitre 2 Le DW d'entreprise a pour périmètre l'ensemble des opérations de l'entre- prise : les activités commerciales, les ressources humaines, la comptabilité, la gestion du parc automobile... Gérer un DW d'entreprise n'a pas de fin, car l'entreprise évolue. Le DW d'application n'a qu'une source de données, par exemple un ERP. Plus généralement, de nombreux DW possèdent un périmètre fonctionnel limité soit à une application, soit à une activité, soit à une entité juridique... Sardines et baleines À l'origine des confusions de vocabulaire, il y a deux grands maîtres de la BI dont les théories sont opposées. Pour Bill Inmon, le DW consolide les données détaillées de toute l'entreprise. Les DM sont ensuite construits selon les demandes des utilisateurs métier à partir de cette source complète. Pour Ralph Kimball, le DW est l'ensemble des DM ; chaque nouveau Data Mart vient enrichir le DW. Ces deux écoles n'ont jamais trouvé de point d'entente, si ce n'est la notion de DM. Lorsque Kimball dit « the Data Warehouse is nothing more than the union of all the data marts » (le DW n'est rien d'autre que l'union de tous les DM), Inmon lui répond : « You can catch all the minnows in the ocean and stack them together and they still do not make a whale » (Vous avez beau pêcher toutes les sardines de l'océan et les rassembler, vous n'obtiendrez jamais une baleine)... Choisir l'une ou l'autre de ces deux approches a des conséquences pour le projet. La méthode Inmon nécessite de créer en premier ce fameux DW, pour ensuite pouvoir délivrer des DM. L'inconvénient est que la création du DW est un tra- vail conséquent, la livraison du premier DM se fera donc attendre. L'avantage est qu'une fois le DW complet créé, n'importe quel DM peut être rapidement construit, y compris sur des besoins qui n'ont pas été uploads/Management/ extrait-du-livre.pdf