Architecture des entrepôts de données

Transcription

1 MTI820 Entrepôts de données et intelligence d affaires Architecture des entrepôts de données Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 1

2 Le cycle de vie d un projet en BI Diagramme de flux de travail: Concep<on de l architecture technique Sélec<on et installa<on des produits Croissance Planifica<on de projet / programme Défini<on des besoins d affaires Modélisa<on des données Concep<on physique Concep<on et développement du système ETL Déploiement Concep<on des applica<on de BI Développement des applica<ons de BI Maintenance Ges<on de projet / programme Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 2

3 QuesPons À quoi sert le plan architecturel d une solupon de BI? Quels sont les facteurs pouvant avoir un impact sur l architecture de la solupon? Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 3

4 Architecture technique Besoins d affaires: «Que doit- on faire?» Architecture: «Comment allons- nous le faire?» Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 4

5 La valeur de l architecture Encourage la sapsfacpon des besoins: Les besoins techniques dérivent des besoins d affaires; Documents d architecture. Facilite la communicapon: Illustre les différents rôles au sein du système; Communique la complexité du projet aux cadres supérieurs. Aide à la planificapon: Regroupe tous les détails techniques; IdenPfie des dépendances et de nouveaux de besoins. Flexibilité, producpvité et maintenance: Métadonnées, sélecpon d oupls, etc. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 5

6 Facteurs à considérer [1/2] L interdépendance informaponnelle entre les unités de l entreprise Ex: bonne intégrapon (ex: MDM) VS silos de données Les sources de données Ex: 1 source VS 10 sources, ERP VS legacy, etc. La quanpté 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 solupon foncponnelle Ex: entrepôt d'entreprise (EDW) VS magasin de données Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 6

7 Facteurs à considérer [2/2] Le nombre d'uplisateurs Ex: uplisateurs vs uplisateurs La nature des tâches des uplisateurs finaux Ex: rapports simples VS fouille de données Les contraintes sur les ressources Ex: financières, main d'œuvre, biais technologique, etc. Les objecpfs du projet Ex: stratégique VS opéraponnel Autres facteurs Ex: polipques, habilités du personnel TI, etc. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 7

8 QuesPons Quelle est la différence entre un magasin de données et un entrepôt de données? Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 8

9 Les magasins de données (data mart) [1/2] CaractérisPques: ConPent une porpon 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 fluctuapons 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 relapvement simple, souvent fait à l aide de code maison; Même processus de conceppon que les entrepôts de données, mais demande moins de ressources. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 9

10 Les magasins de données (data mart) [2/2] Caractéris<que Magasin 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 à plusieurs Gb Gb jusqu à plusieurs Pb Horizon des données Courantes et historiques La plupart du temps historiques Transforma<on des données Faible à moyenne Importante Fréquence des mises- à- jour Horaire, journalier ou hebdomadaire Peu aller jusqu à mensuel Nombre d u<lisateurs simultanés Dizaines Centaines à milliers Types d u<lisateur Objec<fs d affaires Analystes dans le domaine spécifique et gesponnaires OpPmisaPon des acpvités dans le domaine spécifique Analyste d entreprise et cadres seniors OpPmisaPon inter- foncponnelle et support à la décision Source: E. Turban, R. Sharda, D. Delen et D. King (2010). «Business intelligence: A manegerial approach», Pearson. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 10

11 QuesPons Quelles sont les différentes architectures d entrepôts de données? Quelles sont les critères perme{ant de comparer différentes architectures? Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 11

12 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 logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 12

13 Magasins de données indépendants [1/2] Systèmes source ETL Datamarts indépendants Repor<ng U<lisateurs Source 1 Staging Area Datamart 1 App 1 silos de données Source 2 Staging Area Datamart 2 App 2 Source 3 Staging Area Datamart 3 App 3 Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 13

14 Magasins de données indépendants [2/2] CaractérisPques: Les datamarts sont développés et opèrent de manière indépendante; Les données sont disposées en «silos foncponnels»; Pas de dimensions conformes. Avantages/inconvénients: (+) Architecture la plus simple et la moins coûteuse à développer; ( ) Incohérences et redondances entre les datamarts (ex: dimensions, définipons, mesures, types, etc.); ( ) Il n y a pas une seule version de la vérité; ( ) Analyse inter- foncponnelle difficile ou impossible; ( ) Vision limitée, pas extensible. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 14

15 Bus de magasins de données [1/2] Systèmes source ETL Datamarts liés par dimensions conformes Repor<ng U<lisateurs Source 1 Datamart 1 Source 2 Staging Area Datamart 2 Infrastructure de repor<ng Source 3 Datamart 3 Entrepôt de données conceptuel Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 15

16 Bus de magasins de données [2/2] CaractérisPques: Approche bo8om- up, proposée par R. Kimball; Datamarts développés par sujet/processus d affaires, en se basant sur des dimensions conformes; ModélisaPon dimensionnelle (schéma en étoile), au lieu du modèle enpté- relapon (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égraPon des données assurée par les dimensions conformes; (+) Approche incrémentale (processus les plus importants d abord); (+) Donne des résultats rapidement; ( ) ItéraPons futures difficiles à planifier; ( ) Performance sous- oppmale des analyses impliquant plusieurs datamarts. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 16

17 Architecture Hub- and- spoke [1/2] (Corporate Informa>on Factory) Systèmes source ETL Datamarts dépendants Repor<ng U<lisateurs Source 1 Entrepôt de données d entreprise Datamart 1 Source 2 Staging Area EDW Datamart 2 Infrastructure de repor<ng Source 3 Datamart 3 Concentrateur (hub) Rayons (spokes) Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 17

18 Architecture Hub- and- spoke [2/2] (Corporate Informa>on Factory) CaractérisPques: Approche top- down, proposée par B. Inmon et al. Entrepôt (hub) conpent 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 analypques sont faites sur les datamarts. Avantages/inconvénients: (+) IntégraPon et consolidapon complète et des données de l entreprise; (+) Approche itérapve et facilement extensible; ( ) Peut avoir de la redondance de données entre les datamarts; ( ) Performance sous- oppmale des analyses impliquant plusieurs datamarts. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 18

19 Entrepôt de données centralisé [1/2] Systèmes source ETL Repor<ng U<lisateurs Source 1 Entrepôt de données d entreprise Source 2 Staging Area EDW Infrastructure de repor<ng Source 3 Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 19

20 Entrepôt de données centralisé [2/2] CaractérisPques: Similaire à Hub- and- spoke, mais sans les datamarts dépendants; Gigantesque entrepôt de données servant l entreprise enpère; Les données peuvent être atomiques ou résumées. Avantages/inconvénients: (+) Les uplisateurs ont accès à toutes les données de l entreprise; (+) IntégraPon (ETL) et maintenance facile car les données sont à un seul endroit; (+) Performance oppmale (ex: Appliance warehouse, Teradata). ( ) Long et coûteux à développer; ( ) Pas incrémental; ( ) Extensibilité limitée ou très coûteuse. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 20

21 Architecture fédérée [1/2] Systèmes source ETL Entrepôts de données autonomes Repor<ng U<lisateurs Source 1 Source 2 Staging Area EDW 1 EDW 2 Entrepôt de données virtuel (EDW) Infrastructure de repor<ng Source 3 EDW 3 Metadonnées IntégraPon virtuelle Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 21

22 Architecture fédérée [2/2] CaractérisPques: Entrepôt de données distribué sur plusieurs systèmes hétérogènes; Opère de manière transparente (l uplisateur ne voit pas que les données sont réparpes); Données intégrées logiquement ou physiquement à l aide de méta- données (ex: XML); Complémente plutôt que remplace (selon les experts). Avantages/inconvénients: (+) UPle lorsqu il y a déjà un entrepôt en place (ex: acquisipons ou fusions de compagnies); (+) Demande peu de ressources matérielles addiponnelles. ( ) Très complexe: synchronisapon, 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 logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 22

23 Comparaison entre les architectures [1/2] Popularité: Architecture Hub- and- spoke Bus de datamarts Entrepôt centralisé Datamarts indépendants Entrepôts fédérés Fréquence 39 % 26 % 17 % 12 % 4 % Source: T. Ariyachandra et H. Watson (2005). «Key factors in selecpng a datawarehouse architecture», Business Intelligence Journal, vol. 10, no. 2. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 23

24 Comparaison entre les architectures [2/2] Critères: Qualité de l informapon (précise, complète, cohérente); Qualité du système (flexible, extensible, intégrapon); Impact sur les individus (producpvité, décisions, etc.); Impact sur l entreprise (sapsfacpon des requis, ROI, etc.). Résultats: Architecture Qualité de l informa<on 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 selecpng a datawarehouse architecture», Business Intelligence Journal, vol. 10, no. 2. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 24

25 Le modèle Data Vault [1/6] Proposé par Dan Linstedt à la fin des années 90 ObjecPfs: Perme{re de retracer facilement l informapon aux sources de données (ex: audit de données); Être robuste aux changements du modèle d affaires (ex: relapon 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); Perme{re un chargement efficace des données Principe de base: Séparer l informapon structurelle (Hub + Link) des a{ributs descrippfs (Satellites). Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 25

26 Hub: Le modèle Data Vault [2/6] Représente les concepts centraux de l entreprise (ex: Client, Vendeur, Produit, etc.); Modélise uniquement la clé d affaires du concept (aucun a{ribut descrippf). Structure Clé primaire arpficielle Clé d affaires Dernier chargement (Pmestamp) Source de l enregistrement Hub Produit HubProduitID CodeProduit ChargementTS EnregistrementSrc Note: stabilité assurée par la clé d affaires qui change relapvement peu souvent Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 26

27 Link: Le modèle Data Vault [3/6] Représente les relapons naturelles entre les clés d affaires (ex: lien entre Client et Produit = Vente); Ne conpent aucun a{ribut descrippf. Structure Clé primaire arpficielle Clé arpficielle Hub 1... Clé arpficielle Hub N Dernier chargement (Pmestamp) Source de l enregistrement Link Transac<on LinkTransacPonID HubClientID HubProduitID HubVendeurID ChargementTS EnregistrementSrc Note: uplisé même pour les relapons 1- N et 1-1 Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 27

28 Satellite: Le modèle Data Vault [4/6] ConPent l informapon descrippve reliée à une clé d affaires (Hub ou Link); L informapon 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 Clé primaire arpficielle Hub Dernier chargement (Pmestamp) A{ribut 1... A{ribut N Source de l enregistrement Satellite Client 1 HubClientID ChargementTS Nom Prénom Adresse EnregistrementSrc Satellite Client 2 HubClientID ChargementTS DateNaissance DatePremierAchat... EnregistrementSrc Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 28

29 Sample Data Vault Model Fig. 15 Full Data Vault Model Source: Hans Hultgren. Introductory Guide to Data Vault Modeling, 2012.

30 Le modèle Data Vault [6/6] 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élisapon 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) à parpr du Data Vault. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 30

31 QuesPons Les magasins/entrepôts de données s emploient- ils dans un contexte opéraponnel (pas analypque)? Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 31

32 Comptoirs de données opéraponnelles [1/2] (OperaPonal data store ODS) CaractérisPques: Intègrent et consolident des données de sources hétérogènes dans le but de faciliter certaines opérapons de l entreprise; Peuvent servir de source à des systèmes opéraponnels ou un entrepôt de données; ConPennent rarement des données historiques; Me{ent à 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 logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 32

33 Comptoirs de données opéraponnelles [2/2] (OperaPonal data store ODS) UPlisaPons: 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 applicapons: 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 applicapons différentes; Télécom: suggérer un nouveau forfait à un client en se basant sur ses stapspques récentes d uplisapon. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 33

34 QuesPons 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 experpse pour installer et configurer les ressources matérielles/logicielles nécessaires à l entrepôt de données? Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 34

35 Entrepôts de données hébergés (cloud) CaractérisPques: L infrastructure matérielle et informapque réside sur le site d un fournisseur; L entreprise loue l infrastructure. Avantages/inconvénients: (+) Minimisent l invespssement 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 logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 35

36 Entrepôts de données hébergés (cloud) Source: Wayne Eckerson, «Cloud BI AdopPon: Gauging Market Demand», BeyeNetwork, 2011 Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 36

37 Entrepôts de données hébergés (cloud) Source: TATA Consultancy Services, Business Intelligence on the Cloud: Overview and Use Cases, 2012 Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 37

38 SoluPons clé en main Data Warehouse Appliance (DWA): Ensemble intégré de serveurs, disposipfs de stockage, DBMS, systèmes d exploitapon et de logiciels pré- installés et pré- oppmisés pour l entreposage de données; UPlisent une architecture de traitement massivement parallèle; SoluPon allant du terabyte au 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 logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 38

39 SoluPons clé en main Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 39

40 SoluPons clé en main Source: Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 40

41 Architectures orientées service Service oriented architectures (SOA): Méthode d intégrapon et de développement de systèmes dans laquelle les foncponnalités sont regroupées autour de processus d affaires et offertes sous la forme de services interopérables; Permet la communicapon entre des systèmes qui n ont pas été conçus dans ce{e oppque, et leur parpcipapon conjointe dans des processus d affaires. Dans le contexte des entrepôts de données: Facilite la communicapon entre les sources et les applicapons UPlisé dans l architecture Entreprise Applica>on Integra>on (EAI) pour l intégrapon des données Réduit les dépendances technique perme{ant une approche «best- of- breed». Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 41

42 QuesPons 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 logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 42

43 DéfiniPon: Métadonnées InformaPon définissant et décrivant les structures, opérapons 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, transformapons, règles d affaires, etc. Stockage: tables, champs, types, indexes, parppons, dimensions, etc. Présenta<on: modèle de données, rapports, cédules, privilèges d accès, etc. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 43

44 Métadonnées d affaires: Métadonnées Décrit le contenu de l entrepôt dans des termes compréhensibles par les uplisateurs d affaires; Ex: descripteurs de tables et champs. Métadonnées de processus: Décrit le résultat de diverses opérapons du système de BI; Ex: logs ETL (début, fin, écritures disque, ), stapspques sur les requêtes, etc. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 44

45 Bénéfices: Métadonnées Découple la dépendance entre la technologie et son uplisapon (ex: reconfigurer dynamiquement le système ETL pour modifier ou ajouter une source) Permet de monitorer l'état et la performance de la solupon BI Sert de documentapon 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 solupon BI Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 45

46 Couche de préparapon de données (back- room) Système ETL Systèmes sources OpéraPonnels, ODS ERP, CRM MDM Externes RDMBS Fichiers plats, XML Queues de messages Fichiers log & redo Formats propriétaires Extrac<on Profilage de données Capture des changements ExtracPon Consolida<on CorrecPon d erreurs DéduplicaPon des données ConformaPon des dimensions Services de ges<on ETL ProgrammaPon et monitoring des tâches Sauvegarde et restaurapon Contrôle de version/migrapon Qualité des données Historique de processus Données préparées Copies de référence des dimensions Répertoire de métadonnées Livraison Clés arpficielles SCD Hiérarchies Tables de dimension Tables de faits Lignage et dépendances ParallélisaPon Sécurité et conformité GesPon des dimensions Comptoir de données ETL Tables de consultapon/décodage Copies de référence des hiérarchies Données d audit Métadonnées processus: StaPsPques ETL Résultats d audits Résultats de filtrages Métadonnées ETL Métadonnées techniques: Inventaire système et version DescripPons des sources Schémas relaponnels, scripts LDD Logique des tâches ETL Paramètres sauvegarde, sécurité Métadonnées d affaires: DicPonnaire de données Carte logique des données Logique des règles d affaires Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 46

47 Couche de préparapon de données (back- room) Besoins généraux: Support à la producpvité (ex: environnement de développement) Convivialité (ex: interface graphique simple) Flexibilité (ex: métadonnées) FoncPonnalités ETL: Extrac<on: Ex: profilage des données, capture des changements, copie des données Consolida<on: Ex: règles de transformapon, résolupon d'incohérences, intégrapon Livraison: Ex: inserpon dans les tables de faits/dimensions, gespon des changements (SCD) Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 47

48 Couche de préparapon de données (back- room) Services de gespon ETL: PlanificaPon de tâches (job scheduler) Sauvegarde/restauraPon Sécurité etc. Comptoir de données ETL (data store): Données temporaires d'extracpon (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 logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 48

49 Couche de stockage de données (presenta>on) Back- room Front- room Système ETL ExtracPon ConsolidaPon Livraison Services de gespon ETL Magasins de données ETL Serveur de présenta<on Architecture de bus d entreprise (Kimball): RDBMS pour le niveau de détail atomique Dimensions dénormalisées avec clés arpficielles Dimensions changeantes (SCD) type 1, 2 ou 3 Dimensions hiérarchiques Dimensions et faits conformes AgrégaPons/OLAP, indexes d étoile et bitmap Métadonnées processus: Monitoring de la BD StaPsPques d uplisapon d agrégats/olap Métadonnées présenta<on Métadonnées techniques: Tables système de la BD Paramètres des parppons Procédures stockées/scripts Métadonnées d affaires: Descripteurs de tables/champs DéfiniPons d agrégats/olap Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 49

50 Couche de stockage de données (presenta>on) ObjecPf: Fournir un accès simplifié et rapide aux données, pour les uplisateurs (ex: requêtes ad hoc) et applicapons de BI. CaractérisPques souhaitées: Données provenant des principaux processus d'affaires Données atomiques ET agrégées Source unique de données à tous les uplisateurs (peu importe l'emplacement physique des données) Analyses variées avec les mêmes données Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 50

51 Couche de stockage de données (presenta>on) ConsidéraPons: Tables de dimensions dénormalisées (schéma en étoile) Clés arpficielles Dimensions à évolupon lente (SCD 1, 2, 3) Dimensions conformes basées sur la matrice en bus de données Données atomiques au niveau des transacpons Stratégies d'agrégapon (ex: OLAP, ROLAP, etc.) Stratégies de performance (ex: index, parpponnement, etc.) etc. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 51

52 Couche de resptupon de données (front- room) Serveur de présenta<on Modèles dimensionnels Données atomiques des processus d affaires Dimensions/faits conformes Requêtes à accès direct Rapport standards ApplicaPons analypques Tableaux de bord/scorecards Modèles de forage de données Monitoring d uplisapon ApplicaPon de la sécurité ApplicaPon de la conformité GesPon des requêtes Applica<on BI Types d applica<on Services de ges<on BI BI opéraponnel Interface du portail BI ApplicaPons personnalisées Interfaces pour plateforme mobile ReporPng d entreprise ReformulaPon de requêtes Services du portail Web Comptoirs de données BI Rapports stockés Caches des serveurs d applicapon BD usager, tableurs, documents et présentapons Données d authenpficapon et d autorisapon Métadonnées processus: StaPsPques d exécupon de rapports, requêtes, etc. StaPsPques d uplisapon de la sécurité réseau Métadonnées de res<tu<on Métadonnées techniques: Couche sémanpque BI DéfiniPon des rapports / requêtes standards Logique applicapve Paramètres du portail BI Métadonnées d affaires: Liste des a{ributs conformes PoliPque des SCD PoliPques de gespon des valeurs nulles / erreurs DocumentaPon uplisateur Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 52

53 Couche de resptupon de données (front- room) ObjecPfs: Supporter les besoins analypques des uplisateurs 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 gespon BI: GesPon des requêtes ReformulaPon/opPmisaPon RedirecPon vers la bonne ressource informaponnelle NavigaPon d'agrégapon GesPon de priorité GesPon de la sécurité/accès Monitoring de l'uplisapon/performance Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 53

54 Couche de resptupon de données (front- room) Comptoirs de données BI: Modèles de rapports Cache du serveur d'applicapon (performance) Magasin de données locaux (a{enpon aux silos de données) etc. Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 54

55 QuesPons 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 inipaux? Comment fait- t- on pour choisir les produits les mieux adaptés aux besoins techniques? Département de génie logiciel et des TI MTI820 Hiver 2011 C. Desrosiers 55

56 Processus de développement d architecture QuesPons selon le niveau de détail: Niveau de détail Back- room Front- room Besoins d affaires et audit de données Comment obtenir les données nécessaires aux besoins d affaires? Comment mesurer, suivre, analyser et faciliter les opportunités d affaires? ImplicaPons architecturelles et modèles Modèles détaillées et spécificapons SélecPon de produit et implémentapon Quelles sont les foncpons 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 sont- elles situés? 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? Que requièrent les uplisateurs pour avoir l informapon dans une forme uplisable? Quelle est la stratégie de portail BI? À quoi ressemblent 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 logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 56

57 Document d implicapons architecturelles Exemple: Besoins d affaires Implica<on architecturelle Sous- système Améliorer le taux de réponse à l aide d une stratégie de vente croisée Améliorer le taux de réponse à la campagne par courriel en fournissant aux analystes des oupls pour générer les listes de clients ciblés OuPls d intégrapon perme{ant de coupler les clients avec les produits CréaPon de listes de vente croisée et monitoring de base à l aide d oupls BI Traitement des offres et suivi des réponses par le système CRM ETL App. BI App BI Valeur / priorité Haute / 8 Moyenne / 7 N/A ApplicaPon analypque App. BI Moyenne / 7 Augmenter la précision des prédicpons de vente à l aide d une meilleure historique de données et de meilleurs modèles analypques ApplicaPon analypque avec prédicpon de séries temporelles Extraire de l informapon des systèmes externes pour le suivi des ventes App. BI /forage de données ETL N/A Haute / 8 Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 57

58 Document de plan architecturel Contenu: 1. DescripPon sommaire du projet et ses objecpfs; 2. Méthodologie; 3. Besoins et implicapons architecturelles; 4. Survol de l architecture Ex: modèle haut- niveau, métadonnées, couches de service, etc. 5. Composantes architecturelles principales Ex: ETL, applicapons 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élecpon de produits, etc. 7. Modèle architecturel. Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 58

59 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 logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 59