2/6/17. Le cycle de vie d un projet en BI. Questions. Architecture des entrepôts de données. Diagramme de flux de travail:

Transcription

1 MTI820 Entrepôts de données et intelligence d affaires Architecture des entrepôts de données Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desros iers 1 Le cycle de vie d un projet en BI Diagramme de flux de travail: Conception de l architecture te ch n iq u e Sé l e cti o n e t installation des produits Croissance Planification de projet / programme Dé finition des besoins d affaires Modélisation des données Conception physique Conception et développement du système ETL Dé ploie me nt Conception des ap p l i cati o n d e BI Dé ve loppe me nt des applications de BI Maintenance Ge stion de proje t / programme Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 2 Questions À quoi sert le plan architecturel d une solution de BI? Quels sont les facteurs pouvant avoir un impact sur l architecture de la solution? Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 3 1

2 Architecture technique Besoins d affaires: «Que doit-on faire?» Architecture: «Comment allons-nous le faire?» Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 4 La valeur de l architecture Encourage la satisfaction des besoins: Les besoins techniques dérivent des besoins d affaires; Documents d architecture. Facilite la communication: Illustre les différents rôles au sein du système; Communique la complexité du projet aux cadres supérieurs. Aide à la planification: Regroupe tous les détails techniques; Identifie des dépendances et de nouveaux de besoins. Flexibilité, productivité et maintenance: Métadonnées, sélection d outils, etc. Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 5 Facteurs à considérer L interdépendance informationnelle entre les unités de l entreprise Ex: bonne intégration (ex: MDM) VS silos de données Les sources de données Ex: 1 source VS 10 sources, ERP VS legacy, etc. La quantité des données Ex: gigaoctets VS teraoctets La latence des données Ex: mise-à-jour hebdomadaire VS temps-réel L urgence d obtenir une solution fonctionnelle Ex: entrepôt d'entreprise (EDW) VS magasin de données Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 6 2

3 Facteurs à considérer Le nombre d'utilisateurs Ex: utilisateurs vs utilisateurs La nature des tâches des utilisateurs finaux Ex: rapports simples VS fouille de données Les contraintes sur les ressources Ex: financières, main d'œuvre, biais technologique, etc. Les objectifs du projet Ex: stratégique VS opérationnel Autres facteurs Ex: politiques, habilités du personnel TI, etc. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Desros iers 7 Questions Quelle est la différence entre un magasin de données et un entrepôt de données? Département de génie logic iel et des TI MTI820 Hiver 2011 C. Desros iers 8 Les magasins de données (datamart) Caractéristiques: Contient une portion du contenu de l entrepôt de données; Se concentre sur 1 sujet d analyse Ex: les ventes OU les livraisons, mais pas les deux; Sert à faire des analyses simples et spécialisées Ex: les fluctuations des ventes par catégorie de produits; Nombre de sources limitées, provenant la plupart du temps d un même département; Processus ETL relativement simple Même processus de conception que les entrepôts de données, mais demande moins de ressources. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 9 3

4 Magasins de données vs EDW Caractéristique Magas in de données Entrepôt de données (EDW) Portée Un domaine d analyse Plusieurs domaines d analyse Temps de développement Mois Années Coûts de développement $ 10,000 à $ 100,000 + $ 1,000,000+ Complexité de développement Faible à moyenne Grande Taille des données Mb à plus ieurs G b Gb jusqu à plusieurs Pb Horizon des données Courantes et his toriques La plupart du temps historiques Transformation des données Faible à moyenne Importante Fréquence des mises-à-jour Horaire, journalier Peut aller ou jusqu à mensuel hebdomadaire Nombre d utilisateurs simultanés Dizaines Centaines à milliers Types d utilisateur Analys tes dans le domaine Analyste d entreprise et cadres spécifique et gestionnaires seniors Objectifs d affaires Optimisation des activités dans le Optimisation inter-fonctionnelle et domaine spécifique support à la décision Source: E. Turban, R. Sharda, D. Delen et D. King (2010). «Bus ines s intelligence: A manegerial approach», Pearson. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 10 Questions Quelles sont les différentes architectures d entrepôts de données? Quelles sont les critères permettant de comparer différentes architectures? Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 11 Les architectures d entrepôts de données 1. Magasins de données indépendants 2. Architecture en bus de magasins de données 3. Architecture Hub-and-spoke 4. Entrepôt de données centralisé 5. Architecture fédérée Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 12 4

5 Magasins de données indépendants Systèmes source ETL Datamarts indépendants Reporting Utilisateurs Source 1 Staging Area Datamart1 App 1 silos de données Source 2 Staging Area Datamart2 App 2 Source 3 Staging Area Datamart3 App 3 Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 13 Magasins de données indépendants Caractéristiques: Les datamarts sont développés et opèrent de manière indépendante; Les données sont disposées en «silos fonctionnels»; Pas de dimensions conformes. Avantages/inconvénients: (+) Architecture la plus simple et la moins coûteuse à dével opper; ( ) Incohérences et redondances entre les datamarts ( ) Il n y a pas une seule version de la vérité; ( ) Analyse inter-fonctionnelle difficile ou impossible; ( ) Vision limitée, pas extensible. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 14 Bus de magasins de données Datamarts liés Systèmes source ETL par dimensions conformes Reporting Utilisateurs Source 1 Datamart1 Source 2 Staging Area Datamart2 Infrastructure de reporting Source 3 Datamart3 Entrepôt de données conceptuel Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 15 5

6 Bus de magasins de données Caractéristiques: Approche bottom-up, proposée par R. Kimball; Datamarts développés par sujet/processus d affaires, en se basant sur des dimensions conformes; Modélisation dimensionnelle (schéma en étoile), au lieu du modèle entité-relation (ex: 3FN); Entrepôt de données conceptuel, formé de magasins de données inter-reliés à l aide d une couche d intergiciels (middleware). Avantages/inconvénients: (+) Intégration des données assurée par les dimensions conformes; (+) Approche incrémentale (processus les plus importants d abord); (+) Donne des résultats rapidement; ( ) Itérations futures plus difficiles à planifier; ( ) Performance sous-optimale des analyses impliquant plusieurs datamarts. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 16 Architecture Hub-and-spoke (Corporate Information Factory) Systèmes source ETL Datamarts dépendants Reporting Utilisateurs Entrepôt Source 1 de données d entreprise Datamart1 Source 2 Staging Area EDW Datamart2 Infrastructure de reporting Source 3 Datamart3 Concentrateur Rayons (hub) (spokes) Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 17 Architecture Hub-and-spoke Caractéristiques: Approche top-down, proposée par B. Inmon et al. Entrepôt (hub) contient les données atomiques (c.-à-d. le niveau de détail le plus fin) et normalisées (3FN); Les datamarts (spokes) reçoivent les données de l entrepôt; Les données des datamarts suivent le modèle dimensionnel et sont principalement résumées (pas atomique); La plupart des requêtes analytiques sont faites sur les datamarts. Avantages/inconvénients: (+) Intégration et consolidation complète et des données de l entreprise; (+) Approche itérative et potentiellement extensible (spokes); ( ) Peut avoir de la redondance de données entre les datamarts; ( ) Performance sous-optimale des analyses impliquant plusieurs datamarts. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 18 6

7 Entrepôt de données centralisé Systèmes source ETL Reporting Utilisateurs Source 1 Entrepôt de données d entreprise Source 2 Staging Area EDW Infrastructure de reporting Source 3 Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 19 Entrepôt de données centralisé Caractéristiques: Similaire à Hub-and-spoke, mais sans les datamarts dépendants; Gigantesque entrepôt de données servant l entreprise entière; Les données peuvent être atomiques ou résumées. Avantages/inconvénients: (+) Les utilisateurs ont accès à toutes les données de l entreprise; (+) Intégration (ETL) et maintenance facile car les données sont à un seul endroit; (+) Performance optimale (ex: Appliance warehouse, Tera d a ta ). ( ) Long et coûteux à développer; ( ) Pas incrémental; ( ) Extensibilité limitée ou très coûteuse. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 20 Architecture fédérée Entrepôts Systèmes source ETL de données autonomes Reporting Utilisateurs Source 1 EDW 1 Entrepôt Source 2 Staging Area EDW 2 de données virtuel (ED W ) Infrastructure de reporting Source 3 EDW 3 Metadonnées Intégration virtuelle Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 21 7

8 Architecture fédérée Caractéristiques: Entrepôt de données distribué sur plusieurs systèmes hétérogènes; Opère de manière transparente (l utilisateur ne voit pas que les données sont réparties); Données intégrées logiquement ou physiquement à l aide de métadonnées (ex: XML); Complémente plutôt que remplace (selon les experts). Avantages/inconvénients: (+) Utile lorsqu il y a déjà un entrepôt en place (ex: acquisitions ou fusions de compagnies); (+) Demande peu de ressources matérielles additionnelles. ( ) Très complexe: synchronisation, parallélisme, concurrence, etc. ( ) Peu de contrôle sur les sources et la qualité des données; ( ) Faible performance (mais la technologie s améliore). Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 22 Comparaison entre les architectures Popularité: Architecture Fréque nce Hub-and-spoke 39 % Bus de datamarts 26 % Entrepôt centralisé 17 % Datamarts indépendants 12 % Entrepôts fédérés 4 % Source: T. Ariyachandra et H. Watson (2005). «Key factors in selecting a datawarehouse architecture», Bus ines s Intelligence Journal, vol. 10, no. 2. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 23 Comparaison entre les architectures Critères: Qualité de l information (précise, complète, cohérente); Qualité du système (flexible, extensible, intégration); Impact sur les individus (productivité, décisions, etc.); Impact sur l entreprise (satisfaction des requis, ROI, etc.). Résultats: Architecture Qualité de l information Qualité du système Impact sur les individus Impact sur l entreprise Hub-and-spoke Bus de datamarts Entrepôt centralisé Datamarts indépendants Entrepôts fédérés Source: T. Ariyachandra et H. Watson (2005). «Key factors in selecting a datawarehouse architecture», Bus iness Intelligence Journal, vol. 10, no. 2. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 24 8

9 Le modèle Data Vault Proposé par Dan Linstedt à la fin des années 90 Objectifs: Permettre de retracer facilement l information aux sources de données (ex: audit de données); Être robuste aux changements du modèle d affaires (ex: relation 1- N devenant N-N); Réduire les contraintes reliées aux règles d affaires en différant celles-ci (ex: datamarts en aval); Permettre un chargement efficace des données Principe de base: Séparer l information structurelle (Hub + Link) des attributs descriptifs (Satellites). Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 25 Hub: Le modèle Data Vault Représente les concepts centraux de l entreprise (ex: Client, Vendeur, Produit, etc.); Modélise uniquement la clé d affaires du concept (aucun attribut descriptif). Structure générale Clé primaireartif icielle Clé d affaires Dernier chargement (timestamp) Source de l enregistrement Exemple: Hub Produit HubProduitID CodeProduit ChargementTS EnregistrementSrc Note: stabilité assurée par la clé d affaires qui change relativement peu souvent Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 26 Link: Le modèle Data Vault Représente les relations naturelles entre les clés d affaires (ex: lien entre Client et Produit = Vente); Ne contient aucun attribut descriptif. Structure générale Clé primaireartif icielle Clé artificielle Hub 1... Clé artificielle Hub N Dernier chargement (timestamp) Source de l enregistrement Exemple: Link Transaction LinkTransactionID HubClientID HubProduitID HubVendeurID ChargementTS EnregistrementSrc Note: utilisé même pour les relations 1-N et 1-1 Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 27 9

10 Satellite: Le modèle Data Vault Contient l information descriptive reliée à une clé d affaires (Hub ou Link); L information d un même Hub ou Link peut être séparée en plusieurs Satellites (selon la source, fréquence de mise à jour, etc.) Structure générale Ex: Satellite Client 1 Satellite Client 2 Clé primaireartif icielle Hub Dernier chargement (timestamp) Attribut 1... Attribut N Source de l enregistrement HubClientID ChargementTS Nom Prénom Adresse EnregistrementSrc HubClientID ChargementTS DateNaissance DatePremierAchat... EnregistrementSrc Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 28 Source: Hans Hultgren. Introductory Guide to Data Vault Modeling, Le modèle Data Vault Chargement des données: Puisque les Hubs sont découplés (aucune clé étrangère d un Hub à un autre), on peut les charger en parallèle; Même chose pour les Links et Satellites. Lien avec la modélisation dimensionnelle: Les Hubs et leur Satellites correspondent aux table de dimension; Les Links et leur Satellites correspondent aux tables de faits; Il faut appliquer les règles d affaires lorsqu on charge les datamart (schéma en étoile) à partir du Data Vault. Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 30 10

11 Questions Les magasins/entrepôts de données s emploient-ils dans un contexte opérationnel (pas analytique)? Département de génie logic iel et des TI MTI820 Hiver 2011 C. Desros iers 31 Comptoirs de données opérationnelles (Operational data store ODS) Caractéristiques: Intègrent et consolident des données de sources hétérogènes dans le but de faciliter certaines opérations de l entreprise; Peuvent servir de source à des systèmes opérationnels ou un entrepôt de données; Contiennent rarement des données historiques; Mettent à jour les données au lieu de les ajouter; Effectuent les changements presque instantanément au lieu de les faire en lot; Ne remplacent pas les entrepôts de données. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 32 Comptoirs de données opérationnelles (Operational data store ODS) Utilisations: Valider des règles d affaires complexes impliquant des données de plusieurs sources; Analyser des données consolidées en (quasi) temps-réel; Simplifier le processus ETL d un entrepôt de données Exemples d applications: Bancaire: valider en temps-réel la solvabilité d un client appliquant pour un prêt, lorsque les comptes, placements, et dossiers de risque des clients sont gérés par des applications différentes; Té l é co m : suggérer un nouveau forfait à un client en se basant sur ses statistiques récentes d utilisation. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 33 11

12 Questions Que faire lorsque l entreprise n a pas les moyens d acquérir et/ou maintenir l infrastructure nécessaire à l entrepôt de données? Que faire lorsque l entreprise n a pas l expertise pour installer et configurer les ressources matérielles/logicielles nécessaires à l entrepôt de données? Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 34 Entrepôts de données hébergés (cloud) Caractéristiques: L infrastructure matérielle et informatique réside sur le site d un fournisseur; L entreprise loue l infrastructure. Deux types: plate-forme en tant que service (PaaS) ou logiciel en tant que service (SaaS) Avantages/inconvénients: (+) Minimisent l investissement dans l infrastructure; (+) Libèrent les ressources matérielles et humaines de l entreprise; (+) Évitent les tâches de mise-à-jour et de maintenance; ( ) Moins rentable à long terme; ( ) Sécurité et domaine privé des données. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 35 Entrepôts de données hébergés (cloud) Source: Wayne Eckerson, «Cloud BI Adoption: Gauging Market Demand», BeyeNetwork, 2011 Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 36 12

13 Entrepôts de données hébergés (cloud) Source: TATA Cons ultancy Services, Business Intelligence on the Cloud: Ov erv iewand Use Cases, 2012 Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 37 Solutions clé en main Data Warehouse Appliance (DWA): Ensemble intégré de serveurs, dispositifs de stockage, DBMS, systèmes d exploitation et de logiciels pré-installés et pré-optimisés pour l entreposage de données; Utilisent une architecture de traitement massivement parallèle; Solution allant du terabyteau petabyte. Avantages/inconvénients: (+) Faibles coûts de mise-en-place et de maintenance; (+) Bonnes performance et extensibilité due à l architecture parallèle; (+) Permet d obtenir rapidement des bénéfices; ( ) Achat très dispendieux ($100K - $1M). Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 38 Solutions clé en main Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 39 13

14 Solutions clé en main Source: Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 40 Architectures orientées service Service orientedarchitectures (SOA): Méthode d intégration de systèmes offrant des fonctionnalités sous la forme de services interopérables; Permet la communication entre des systèmes qui n ont pas été conçus dans cette optique, et leur participation conjointe dans des processus d affaires. Dans le contexte des entrepôts de données: Facilite la communication entre les sources et les applications Utilisé dans l architecture Entreprise Application Integration (EAI) pour l intégration des données Réduit les dépendances techniques permettant une approche «best-of-breed». Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 41 Questions Quelles sont les principales composantes d un entrepôt de données? Comment fait-on pour rendre ces composantes le plus modulaire possible? Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 42 14

15 Définition: Métadonnées Information définissant et décrivant les structures, opérations et le contenu du système de BI; Trois types: technique, d affaires et de processus. Métadonnées techniques: ETL: sources et cibles pour les transferts de données, transformations, règles d affaires, etc. Stockage: tables, champs, types, indexes, partitions, dimensions, etc. Présentation: modèle de données, rapports, cédules, privilèges d accès, etc. Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desros iers 43 Métadonnées Métadonnées d affaires: Décrit le contenu de l entrepôt en termes compréhensibles par les utilisateurs d affaires; Ex: descripteurs de tables et champs. Métadonnées de processus: Décrit le résultat de diverses opérations du système de BI; Ex: logs ETL (début, fin, écritures disque, ), statistiques sur les requêtes, etc. Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desros iers 44 Métadonnées Bénéfices: Découple la dépendance entre la technologie et son utilisation (ex: reconfigurer dynamiquement le système ETL pour modifier ou ajouter une source) Permet de monitorer l'état et la performance de la solution BI Sert de documentation au système Permet de déterminer l'impact d'un changement Idéal: Avoir un seul répertoire de métadonnées partagé par toutes les composantes de la solution BI Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desros iers 45 15

16 Couche de préparation de données (back-room) Système ETL Systèmes sources Opérationnels, ODS ERP, CRM MDM Externes RDMBS Fichiers plats, XML Queues de messages Fichiers log & redo Formats propriétaires Extraction Profilage de données Capture des changements Extraction Consolidation Correction d erreurs Déduplic ation des données Conformation des dimensions Services de gestion ETL Programmation et monitoring des tâches Sauvegarde et restauration Contrôle de vers ion/ migration Qualité des données His torique de proc es s us Données préparées Comptoir de données ETL Copies de référence des dimens ions Données d audit Répertoire de métadonnées Livraison Clés artificielles SCD Hiérarc hies Tables de dimension Tables de faits Lignage et dépendances Parallélisation Sécurité et conformité Gestion des dimensions Tables de consultation/décodage Copies de référence des hiérarchies Métadonnées processus: Statistiques ETL Résultats d audits Rés ultats de filtrages Métadonnées ETL Métadonnées techniques : Inventaire système et version Métadonnées d affaires: Dic tionnaire de données Descriptions des sources Carte logique des données Schémas relationnels, scripts LDD Logique des règles d affaires Logique des tâches ETL Paramètres sauvegarde, sécurité Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 46 Couche de préparation de données (back-room) Besoins généraux: Support à la productivité (ex: environnement de développement) Convivialité (ex: interface graphique simple) Flexibilité (ex: métadonnées) Fonctionnalités ETL: Extraction: Ex: profilage des données, capture des changements, copie des données Consolidation: Ex: règles de transformation, résolution d'incohérences, intégration Livraison: Ex: insertion dans les tables de faits/dimensions, gestion des changements (SCD) Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 47 Couche de préparation de données (back-room) Services de gestion ETL: Planification de tâches (job scheduler) Sauvegarde/restauration Sécurité etc. Comptoir de données ETL (data store): Données temporaires d'extraction (staging area) Historique du processus ETL (métadonnées processus, QA) Sauvegarde des références ETL (métadonnées techniques) etc. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 48 16

17 Couche de stockage de données (presentation) Back-room Front-room Système ETL Serveur de présentation Extraction Consolidation Livraison Services de gestion ETL Magas ins de données ETL Architecture de bus d entreprise (Kimball): RDBMS pour le niveau de détail atomique Dimens ions dénormalisées avec clés artificielles Dimensions changeantes (SCD) type 1, 2 ou 3 Dimens ions hiérarc hiques Dimensions et faits conformes Agrégations/OLAP, indexes d étoile et bitmap Métadonnées processus : Monitoring de la BD Statistiques d utilisation d agrégats/olap Métadonnées présentation Métadonnées techniques : Tables système de la BD Paramètres des partitions Procédures stockées/scripts Métadonnées d affaires: Desc ripteurs de tables/ c hamps Définitions d agrégats/olap Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 49 Couche de stockage de données (presentation) Objectif: Fournir un accès simplifié et rapide aux données, pour les utilisateurs (ex: requêtes ad hoc) et applications de BI. Caractéristiques souhaitées: Données provenant des principaux processus d'affaires Données atomiques ET agrégées Source unique de données à tous les utilisateurs (peu importe l'emplacement physique des données) Analyses variées avec les mêmes données Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 50 Couche de stockage de données (presentation) Considérations: Tables de dimensions dénormalisées (schéma en étoile) Clés artificielles Dimensions à évolution lente (SCD 1, 2, 3) Dimensions conformes basées sur la matrice en bus de données Données atomiques au niveau des transactions Stratégies d'agrégation (ex: OLAP, ROLAP, etc.) Stratégies de performance (ex: index, partitionnement, etc.) etc. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 51 17

18 Couche de restitution de données (front-room) Applic ation BI Serveur de présentation Modèles dimensionnels Données atomiques des processus d affaires Dimensions / faits conformes Requêtes à accès direct Rapport s tandards Applications analytiques Tableaux de bord/scorecards Modèles de forage de données Monitoring d utilisation Application de la sécurité Application de la conformité Gestion des requêtes Types d application Services de gestion BI BI opérationnel Interface du portail BI Applications personnalisées Interfaces pour plateforme mobile Reporting d entreprise Reformulation de requêtes Services du portail Web Comptoirs de données BI Rapports stockés Caches des serveurs d application BD usager, tableurs, documents et présentations Données d authentification et d autorisation Métadonnées processus : Statistiques d exécution de rapports, requêtes, etc. Statistiques d utilisation de la sécurité réseau Métadonnées de restitution Métadonnées techniques : Couche s émantique BI Définition des rapports / requêtes standards Logique applicative Paramètres du portail BI Métadonnées d affaires: Liste des attributs conformes Politique des SCD Politiques de gestion des valeurs nulles / erreurs Doc umentation utilis ateur Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 52 Couche de restitution de données (front-room) Objectifs: Supporter les besoins analytiques des utilisateurs Ex: rapports, analyse OLAP, fouille de données, etc. Offrir des interfaces d'accès simplifiées aux données Ex: portail Web, service SOA Offrir une performance adéquate Services de gestion BI: Gestion des requêtes Reformulation/optim isation Redirection vers la bonne ressource informationnelle Navigation d'agrégation Gestion de priorité Gestion de la sécurité/accès Monitoring de l'utilisation/performance Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 53 Couche de restitution de données (front-room) Comptoirs de données BI: Modèles de rapports Cache du serveur d'application (performance) Magasin de données locaux (attention aux silos de données) etc. Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 54 18

19 Questions Quelles sont les principales étapes dans le développement de l architecture? Comment s assure-t-on que l architecture répond bien aux besoins d affaires initiaux? Comment fait-t-on pour choisir les produits les mieux adaptés aux besoins techniques? Département de génie logic iel et des TI MTI820 Hiver 2011 C. Des ros iers 55 Processus de développement d architecture Questions selon le niveau de détail: Niveau de détail Back-room Front-room Bes oins d affaires et audit de données Implications architecturelles et modèles Modèles détaillées et spécifications Sélection de produit et implémentation Comment obtenir les données néces s aires aux besoins d affaires? Quelles sont les fonctions et composantes nécessaires pour obtenir les données dans la forme, l endroit et le moment désirés. Quels sont les principales sources de données et où sont-elles situées? Quel est la stratégie de métadonnées? Quel est le contenu spécifique de chaque source de données? Quel sont les capacités spécifiques de chaque service? Quels produits fournissent les capacités requises? Comment ceux-ci seront-ils assemblés? Comment mes urer, suivre, analyser et faciliter les opportunités d affaires? Que requièrent les utilisateurs pour avoir l information dans une forme utilisable? Quelle est la stratégie de portail BI? À quoi res s emblent les rapports standards? Comment ceux-ci seront-ils présentés? Quel est le design du portail BI? Quels produits fournissent les capacités requises? Comment ceux-ci seront-ils assemblés? Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 56 Document d implications architecturelles Exemple: Besoins d affaires Implication architecturelle Sous-système Valeur / priorité Améliorer le taux de réponse à l aide d une stratégie de vente croisée Outils d intégration permettant de coupler les clients avec les produits Création de lis tes de vente crois ée et monitoring de base à l aide d outils BI Traitement des offres et suivi des répons es par le système CRM ETL Haute / 8 App. BI Moyenne / 7 App BI N/A Améliorer le taux de réponse à la campagne par courriel en fournis s ant aux analystes des outils pour générer les listes de clients ciblés Application analytique App. BI Moyenne / 7 Augmenter la précision des prédictions de vente à l aide d une meilleure his torique de données et de meilleurs modèles analytiques Application analytique avec prédiction de séries temporelles Extraire de l information des systèmes externes pour le suivi des ventes App. BI / forage N/A de données ETL Haute / 8 Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 57 19

20 Document de plan architecturel Contenu: 1. Description sommaire du projet et ses objectifs; 2. Méthodologie; 3. Besoins et implications architecturelles; 4. Survol de l architecture Ex: modèle haut-niveau, métadonnées, couches de service, etc. 5. Composantes architecturelles principales Ex: ETL, applications BI, sources de données, répertoire de métadonnées, infrastructure, etc. 6. Processus de développement de l architecture Ex: phases, preuve de concept, standards et sélection de produits, etc. 7. Modèle architecturel. Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 58 Modèle architecturel (exemple) Projet centré sur les données d un club de points d une chaîne de supermarchés Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 59 Sélection des produits Guidée par les besoins d affaires; Étapes: 1. Comprendre le processus d achat de l entreprise; 2. Faire une étude de marché: Sources: internet, cours et séminaires, publications du domaine, consultants externes, etc.; Critères: fonctionnalité, performance, productivité, support (technique, documentation, formation), etc. 3. Évaluer les solutions les plus prometteuses Ex: rencontres avec les vendeurs, version d essai, comparaison de prototypes, etc. 4. Rédiger un rapport de recommandation de produit; 5. Tester le produit retenu durant une période d essai (ex: 90 jours ); 6. Négocier le contrat (licences, support, formation, etc.). Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 60 20

21 Exemple: Matrice d évaluation de produits Département de génie logic iel et des TI MTI820 Hiver 2011 S. Chafki, C. Desrosiers 61 21