Le document présente un aperçu détaillé de l'informatique décisionnelle et des systèmes d'information hospitaliers, incluant l'architecture des datawarehouses, la modélisation, et les concepts associés comme l'OLAP. Il met l'accent sur l'importance de ces systèmes pour aider les décideurs à analyser les données, à répondre à des questions critiques concernant la gestion des établissements de santé. Enfin, il aborde les langages de requêtage tels que MDX, utilisés pour interagir avec des données multidimensionnelles.

1. Alicante SYSTÈME D’INFORMATION ET PERFORMANCE HOSPITALIÈRE Présentation

2. Informatique décisionnelle

3. Informatique décisionnelle Problématique Rappels de bases de données Système de Gestion de Bases de Données datawarehouse : l’entrepôt de données Architecture technique Modélisation du datawarehouse OnLine Analytical Processing : OLAP En pratique MultiDimentionnal eXpression, un langage de requêtage 26/05/09

4. Informatique décisionnelle L' informatique décisionnelle (en anglais : DSS pour Decision Support System ou encore BI pour Business Intelligence ) désigne les moyens, les outils et les méthodes qui permettent de collecter, consolider, modéliser et restituer les données d'une organisation en vue d'offrir une aide à la décision 26/05/09

5. Problématique Les décideurs d'un hôpital, par exemple, doivent pouvoir répondre à un certain nombre de questions pour diriger leur établissement Qui sont mes patients ? Pourquoi sont ils mes patients ? Comment cibler ma clientèle ? Quel est l'évolution de telle pathologie ? Quel protocole de soins est il le plus efficace/rentable ? Quel financement vais-je obtenir si je spécialise mon établissement sur telle problématique ? … L'objectif est d'apporter aux décideurs les moyens de répondre à des questions sur le fonctionnement global de leur organisation Comment ? Par le biais d’indicateurs Par le biais du reporting 26/05/09

6. 26/05/09

7. Rappels de bases de données Conception d’une base de données relationnelle Modèle relationnel ou entité-relation Les formes normales Objectif : éviter les redondances 1, 2, 3 NF et BCNF 26/05/09

8. Système de Gestion de Bases de Données Modèle entité/relation en 3FN dérivé en modèle physique Gestion de transaction On Line Transaction Processing (OLTP) L'objectif est de pouvoir insérer, modifier et interroger rapidement et en sécurité la base Chaque transaction travaille sur de faibles quantités d'informations, et toujours sur les versions les plus récentes des données 26/05/09

9. Système de Gestion de Bases de Données(2) Interrogations via SQL Lectures, écritures Résultats instantanés Requêtes renvoyant des données sur 2 dimensions A chaque interrogation, les calculs sont ré-exécutés 26/05/09

10. Système de Gestion de Bases de Données(3) Les données applicatives métiers sont stockées dans plusieurs bases de données relationnelles (ou non relationnelles) Ces bases sont conçues pour être efficaces pour les fonctions sur lesquelles elles sont spécialistes Elles sont donc peu structurées pour l'analyse, avec souvent comme objectif principal de conserver l'information Différents vendeurs de SGBDR sur le marché nous amènent à considérer la globalité des données d’une organisation comme hétérogène 26/05/09

11. Système de Gestion de Bases de Données(4) Système d’information global « multidimensionnel » 26/05/09 Recueil des Actes Base Compta Annuaire des médecins … Base Patients

12. datawarehouse : l’entrepôt de données Constat : les bases de données de productions sont peu adaptées à la vision à long terme et donc à la prise de décision. 2 concepts dans un mot : Fédérer les données issues de bases de données de production Agréger ces énormes volumes de données dans le but de les interroger But : permettre à l'utilisateur d'y accéder de manière simple et ergonomique (reporting) 26/05/09

13. datawarehouse : l’entrepôt de données(2) Définition de Bill Inmon (1996): « Le datawarehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour le support d'un processus d'aide à la décision. » 26/05/09

14. datawarehouse : l’entrepôt de données(3) « Orientées sujet » : Les bases de production sont le plus souvent organisées par processus fonctionnels. Le datawarehouse est lui organisé autour des sujets majeurs de l'entreprise. Les données sont donc structurées par thèmes, ces thèmes étant souvent transverses par rapport aux structures fonctionnelles et organisationnelles (et donc transverses par rapport aux systèmes de production). 26/05/09

15. datawarehouse : l’entrepôt de données(4) 26/05/09 Recueil des Actes Base séjours Annuaire des médecins Base Patients DW Actes Base diagnostics DW Séjours

16. datawarehouse : l’entrepôt de données(5) « Données intégrées » : Les données proviennent de plusieurs sources différentes. Avant d'être intégrées au sein du datawarehouse elles doivent être mise en forme et unifiées Cela nécessite une forte normalisation, de bénéficier d'un référentiel unique et cohérent ainsi que de bonnes règles de gestion Cette phase est très complexe et représente une charge importante dans la mise en place d'un datawarehouse 26/05/09

17. datawarehouse : l’entrepôt de données(6) « Données historisées » : Contrairement au système de production les données ne sont jamais mises à jour (quasiment). Chaque nouvelle donnée est insérée. Un référentiel de temps doit être mis en place afin de pouvoir identifier chaque donnée dans le temps. 26/05/09

18. datawarehouse : l’entrepôt de données(7) « Données non volatiles » : Un datawarehouse veut conserver la traçabilité des informations et des décisions prises. Les données ne sont ni modifiées ni supprimées. Une requête émise sur les mêmes données à plusieurs mois d'intervalles doit donner le même résultat. 26/05/09

19. datawarehouse : l’entrepôt de données(8) Un datawarehouse définis donc à la fois un ensemble de données et un ensemble d'outils. Il s'agit de données destinés aux décideurs, qui sont souvent une copie des données de production avec une valeur ajoutées (orientées objet, agrégées, historisées). C'est un ensemble d'outils permettant de regrouper les données des différentes sources, de les nettoyer et de les intégrer, ainsi que d'y accéder de différentes manières (requêtes, rapport, analyse, datamining). 26/05/09

20. Architecture technique 26/05/09 Bases de production Saisie Outil d’alimentation datawarehouse Cube OLAP Outil de restitution Client

21. Architecture technique (2) Alimentation : phase critique L'alimentation des données à partir des bases de production est une phase primordiale d'un datawarehouse. Des outils logiciels sont alors nécessaires pour intégrer les données dans le datawarehouse. On parle d'ETL (Extract, Transform, Load). 26/05/09

22. Architecture technique (3) Alimentation : phase critique Les phases de l'alimentation d'un datawarehouse sont les suivantes : Découverte des données Extraction des données Transformation des données Chargement des données 26/05/09

23. Architecture technique (4) Exemple : 26/05/09 M,F 1,0 Homme,femme Eur $ Char(10) Dec(12,2) Numeric(7) Intégration datawarehouse M,F Eur Numeric(7)

24. Modélisation du datawarehouse On part toujours des besoins du client (que veut-il observer ?) On va définir deux concepts : le concept de fait et le concept de dimension Un fait représente un sujet d'analyse. Il est constitué de plusieurs mesures relatives au sujet traité. Ces mesures sont numériques et généralement valorisées de façon continue. Ex : Je m’intéresse au fait « Vente de produit », les mesures possibles sont le Chiffre d’affaire, la marge, le nombre de vente… dede 26/05/09

25. Modélisation du datawarehouse La dimensions est le critère suivant lequel on souhaite évaluer, quantifier, qualifier le fait. Ex : Je m’intéresse au fait « Vente de produit », les dimensions possibles sont : le temps, la géographie, les magasins, les catégories de produit… On part du principe que les données sont des faits à analyser selon plusieurs dimensions 26/05/09

26. Modélisation du datawarehouse (2) Au niveau logique cela peut se traduire par trois modèles différents : en étoile, en flocon de neige ou en constellation. 26/05/09

27. Modélisation du datawarehouse (3) Modèle en étoile : Le centre est la table des faits, et les branches en sont les dimensions 26/05/09

28. Modélisation du datawarehouse (4) Modèle en flocon : Le principe est le même que pour le modèle en étoile, mais en plus les dimensions sont décomposées (gain de place mais complexification du modèle) 26/05/09

30. Modélisation du datawarehouse (5) Modèle en constellation : On rassemble plusieurs tables des faits qui utilisent les mêmes dimensions 26/05/09

31. OnLine Analytical Processing Le concept OLAP serait apparu pour la première fois en 1993 dans un livre blanc réalisé par E.F. Codd , l'un des concepteurs des bases de données relationnelles Objectif : Travaille sur des agrégats par rapport au datawarehouse Ce système travaille en lecture seulement. Les programmes consultent d'importantes quantités de données pour procéder à des analyses. Les objectifs principaux sont regrouper, organiser des informations provenant de sources diverses, les intégrer et les stocker pour donner à l’utilisateur une vue orientée métier, retrouver et analyser l’information facilement et rapidement . 26/05/09

32. OnLine Analytical Processing (2) Concept d'analyse multidimensionnelle : analyser des données qui ont été agrégées suivant plusieurs dimensions. On utilise pour cela des hypercubes OLAP (cube suffit). Les données sont représentées dans des hypercubes à n dimensions. Les données sont structurées suivant plusieurs axes d'analyses (dimensions) comme le temps, la localisation ... Une cellule est l'intersection des différentes dimensions. Le calcul de chaque cellule est réalisé au chargement. Le temps de réponse est ainsi stable quelque soit la requête. 26/05/09

33. 26/05/09

34. 26/05/09

35. OnLine Analytical Processing (3) Voici un tableau récapitulatif des différences entre OLTP et OLAP : L'objectif des bases OLTP est de pouvoir répondre rapidement à des réponses simples, exemple : les ventes du produit X. Les bases OLAP permettent des requêtes plus complexes : les ventes du produit X par vendeur, région et par mois. 26/05/09

36. OnLine Analytical Processing (4) Les requêtes SQL ne pourraient-elles pas prétendre remplacer OLAP ? Non ! A l'origine, les premiers outils décisionnels ont cherché à exploiter les possibilités de requêtage des bases relationnelles. Cependant, cette voie a très vite montré ses limites. En effet, les infocentres traditionnels (OLTP - OnLine Transactional Processing - à 2 dimensions) ne se prêtent guère aux requêtes croisées ou multidimensionnelles. C'est pour répondre à cette problématique que E.F. Codd élabore la méthode OLAP 26/05/09

37. OnLine Analytical Processing (5) Avantages d’OLAP : Grande souplesse de son mode de requêtage (plusieurs dimensions) Quasi immédiateté si bien modélisé Inconvénients Très lourd si beaucoup de dimensions Très lent si beaucoup de dimensions 26/05/09

38. OnLine Analytical Processing (6) Mode de stockage des agrégats - MOLAP (pour Multidimensional OLAP) désigne les applicatifs multidimensionnels découlant directement du concept initial. - ROLAP (Relational OLAP) renvoie à une base relationnelle classique structurée pour réagir à la manière d'une base OLAP. Critiquée pour sa faible performance, elle serait néanmoins mieux adaptée à de grandes quantités de données. - HOLAP (Hybride OLAP) repose sur des bases ROLAP, et MOLAP, cette dernière prenant en charge les contenus les plus souvent recherchés. - OOLAP : C'est la technologie la plus récente, Object OLAP. Le modèle multidimensionnel se traduit ainsi :chaque fait correspond à une classe, appelée classe de fait. Chaque dimension correspond à une classe, appelée classe de dimension. Le principal avantage est d'augmenter le niveau d'abstraction. - DOLAP (Desktop OLAP) est un module OLAP directement installé sur le poste client. Très rapide, il demeure cependant limité en taille. 26/05/09

39. En pratique 26/05/09

40. MultiDimentionnal eXpression, un langage de requêtage Opérations « ensembliste » possibles sur un cube : Drill-up / down : « dé-zoom et zoom » Rotate Slicing : sélection d’une tranche Scoping : sélection d’un « sous-cube » 26/05/09

41. MultiDimentionnal eXpression, un langage de requêtage Drill-up / down 26/05/09

42. MultiDimentionnal eXpression, un langage de requêtage Rotate 26/05/09

43. MultiDimentionnal eXpression, un langage de requêtage Slicing 26/05/09

44. MultiDimentionnal eXpression, un langage de requêtage Scoping 26/05/09

45. MultiDimentionnal eXpression, un langage de requêtage MDX, l’équivalents de SQL dans le monde OLAP Origine : Microsoft Langage permettant d’effectuer les opérations décrites précédemment 26/05/09

46. MultiDimentionnal eXpression, un langage de requêtage 26/05/09 EXEMPLE DE REQUETE MDX : select { ([Measures].[Quantite] ) , ([Measures].[Somme des ventes])} on columns , { ([DimensionProduit].[Produit].[Categorie].Members) } on rows from [MONCUBE]

47. MultiDimentionnal eXpression, un langage de requêtage Notion de tuple : Un tuple est une collection de membres, dont chacun est choisi parmi une dimension différente Exemple : (Cycles, Vente, 1997) Le tuple est l'unité de base pour former un axe . Notion d’Axe : Un axe est un groupe, une collection, de membres d'une ou plusieurs dimensions, organisée comme tuples Ex : {([Time].[1998],[Department].[All Department].[HQ Finance and Accounting])} ON COLUMNS Les ‘’{‘’ représentent la notion d’ensemble qui permet de placer plus d’un membre sur un axe. 26/05/09

48. MultiDimentionnal eXpression, un langage de requêtage Notion d’ensemble : L'ensemble est un composant important de la syntaxe MDX. Les ensembles sont typiquement joints par " { } " et apparaissent souvent dans la partie SELECT d'une question 26/05/09

49. MultiDimentionnal eXpression, un langage de requêtage Exemples Pratiques Nous commencerons par une illustration : Nous sommes invités par un consommateur de l'information à fournir tout l’effectif pendant les années 1997 et 1998 individuellement pour l'organisation entière. SELECT{([Time].[1997]), ([Time].[1998])} ON COLUMNS FROM HR WHERE([Measures].[Count]) Le diagramme ci-dessous marque les diverses parties de la question 26/05/09

50. MultiDimentionnal eXpression, un langage de requêtage Exemples Pratiques Nous sommes invités par un consommateur de l'information à fournir tout l’effectif pendant les années 1997 et 1998 individuellement pour l'organisation entière croisé par les types de paiements. SELECT {([Time].[1997]),([Time].[1998])}ON COLUMNS, {[Pay Type].[Pay Type].Members} ON ROWS FROM HR WHERE ([Measures].[Count]) Le diagramme ci-dessous marque les diverses parties de la question 26/05/09

51. MultiDimentionnal eXpression, un langage de requêtage SELECT {[Measures].[Units Shipped]} ON COLUMNS, {[Store].[Store State].[CA], [Store].[Store State].[OR], [Store].[Store State].[WA]} ON ROWS FROM [Warehouse] 26/05/09

52. MultiDimentionnal eXpression, un langage de requêtage Introduction aux membres et aux fonctions de membre Les membres représentent un concept important et dominant dans un arrangement de données MDX. Un membre est, simplement, un article dans une dimension ; les membres composent les valeurs d'attributs qui appartiennent à une dimension. Maintenez dans votre esprit que les mesures sont elles-mêmes des dimensions , et ainsi elles, aussi, se composent de membres. Pour illustrer ce qu’est un membre, prenons l’exemple d’une dimension basée sur la géographie, qui pourrait contenir le pays, l'état et la ville comme niveaux, les Etats-Unis, l'Idaho, et la Nouvelle-Orléans pourrait représenter des membres valides. 26/05/09

53. MultiDimentionnal eXpression, un langage de requêtage L'opérateur Members fournit des moyens d'obtenir un niveau, une hiérarchie ou une dimension donnée. SELECT [Measures].Members ON COLUMNS, [Department].Members ON ROWS FROM [HR]Résultat : de 26/05/09

54. MultiDimentionnal eXpression, un langage de requêtage Introduction aux fonctions de membre de "famille« Les fonctions qui composent ce groupe incluent : Parent Children Ancestor() FirstChild LastChild FirstSibling LastSibling 26/05/09

55. MultiDimentionnal eXpression, un langage de requêtage 26/05/09 /* Members = accès via les hiérarchies pour aller chercher tous les membres d'un niveaux */ select { ([Measures].[Order Quantity] ) , ([Measures].[Sales Amount])} on columns , { ([Dim Product].[Product].[Category].Members) } on rows from [MONCUBE]

56. MultiDimentionnal eXpression, un langage de requêtage 26/05/09 /* Children : Accès par les membres */ select { ([Measures].[Order Quantity] ) , ([Measures].[Sales Amount])} on columns , { ([Dim Product].[Product].[Bikes].Children ) } on rows from [MONCUBE]

57. MultiDimentionnal eXpression, un langage de requêtage 26/05/09 select { CrossJoin ( { ([Order Date].[Time Hier].[Year].[2003]) , ([Order Date].[Time Hier].[Year].[2004]) }, { ( [Measures].[Sales Amount]),([Measures].[Order Quantity] ) } ) } on columns, { CrossJoin ( [Dim Product].[Dim Product Category].[Dim Product Category].Members , [Dim Product].[Dim Product Subcategory].Members) } on rows from [MONCUBE]

58. MultiDimentionnal eXpression, un langage de requêtage 26/05/09 select { NonEmptyCrossJoin ( { ([Order Date].[Time Hier].[Year].[2003]) , ([Order Date].[Time Hier].[Year].[2004]) }, { ( [Measures].[Sales Amount]),([Measures].[Order Quantity] ) } ) } on columns, { NonEmptyCrossJoin ( [Dim Product].[Dim Product Category].[Dim Product Category].Members , [Dim Product].[Dim Product Subcategory].Members) } on rows From [MONCUBE]

59. MultiDimentionnal eXpression, un langage de requêtage 26/05/09 select { NonEmptyCrossJoin ( { ([Order Date].[Time Hier].[Year].[2003]) , ([Order Date].[Time Hier].[Year].[2004]) }, { ( [Measures].[Sales Amount]),([Measures].[Order Quantity] ) } ) } on columns, { NonEmptyCrossJoin ( [Dim Product].[Dim Product Category].[Dim Product Category].Members , [Dim Product].[Dim Product Subcategory].Members) } on rows From [MONCUBE]

60. MultiDimentionnal eXpression, un langage de requêtage Membres Calculés Les membres calculés, en bref, nous permettent de définir de nouveaux membres, basés sur les dimensions ou les mesures qui existent dans le cube. Ce sont des membres dont les valeurs dépendent d'une expression plutôt que de la valeur d'une cellule dans un cube. Syntaxe : WITH MEMBER dimension.name AS 'Expression' 26/05/09

61. MultiDimentionnal eXpression, un langage de requêtage 26/05/09 with Member [Measures].[Sales by Unit] as ( [Measures].[Sales Amount] / [Measures].[Order Quantity] ) select { ([Measures].[Sales Amount] ), ([Measures].[Order Quantity] ) , ([Measures].[Sales by Unit] ) } on columns, { ([Dim Product].[Product].[Category].Members) } on rows from [MONCUBE]

62. MultiDimentionnal eXpression, un langage de requêtage La Fonction de CurrentMember La fonction CurrentMember "retourne le membre courant le long d'une dimension pendant une itération". L'axe de la requête que nous construisons fournit le contexte dans lequel le "courant" a la signification. WITH MEMBER [Measures].[Warehouse Margin] AS '([Time].CurrentMember , [Measures].[Warehouse Sales])-([Time].Currentmember,[Measures].[Warehouse Cost])‘ SELECT {[Measures].[Warehouse Sales],[Measures].[Warehouse Cost],[Measures].[Warehouse Margin]} ON COLUMNS, {([Warehouse].[Country].[USA])} ON ROWS FROM Warehouse WHERE ([Time].[1998]) 26/05/09

63. Merci de votre attention. [email_address]