février 4, 2022Lire l'article
Les modèles de données BI obéissent à des règles spécifiques distinctes de celles des modèles de données relationnels. Concevoir un modèle de données dans Power BI comme on le ferait pour un modèle relationnel revient à méconnaître la modélisation de données en BI. Cet article se propose de clarifier cette problématique. Nous commencerons par rappeler quelques règles de base de conception d’une base de données relationnelle, puis nous étudierons les règles de conception d’un modèle de données dans Power BI. La comparaison nous aidera à mieux comprendre le rôle de la BI.
Quelques rappel (nécessaire) de conceptions de base de données relationnel.
Une base de données relationnelle est un ensemble de tables reliées entre elles répondent à des règles de normalisation. Normaliser une base de données permet d’améliorer la performance et d’éviter la redondance. Les bases de données relationnelles correspondant aux modèles OLTP (Online Transactional Processing).
Les 4 formes normales qu’une base de données relationnelle doit atteindre :
Une relation est dite de première forme normale si tous les attributs de la relation contient une valeur atomique.
Dans cette table, l’attribut « Matière » n’est pas atomique. Cette table n’est pas en première forme normale.
Dans un modèle SQL il faudrait sortir l’attribut « Matière » de la table et le gérer autrement dans une autre table.
Dans un modèle BI on pourrait par exemple fractionner en ligne l’attribut « Matière » donnant la table suivante :
C’est ici que la notion de clé primaire est abordée. La clé primaire a pour but de rendre chaque ligne de la table unique.
Une relation en deuxième forme normale dépend de deux critères :
Dans cette table il faudrait « Nom » et « Matière » pour rendre une ligne unique. On dit alors que « Nom » et « Matière » sont des clés candidates, une seule sera choisie comme clé primaire. Cependant on observe que la colonne « Numéro_etudiant » dépend de « Nom » et non pas des deux colonnes « Nom » et « Matière ». L’attribut « Numéro_etudiant » ne dépend pas de l’intégralité des clés candidates. Donc cette table n’est pas en deuxième forme normale.
Dans un modèle SQL, pour être en deuxième forme normale il faudrait un modèle comme ci-après :
Dans un modèle BI on aurait conservé la table en l’état.
Une relation en 3ème forme normale répond à 2 critères :
Dans cette table, la colonne « Année_diplôme » dépend de la colonne « Diplôme ». Donc cette table n’est pas en 3ème forme normale.
Dans un modèle de données SQL les colonnes « Diplôme » et « Année_diplôme » seraient séparées dans une autre table.
Dans un modèle BI, la table serait conservée en l’état.
Une relation en 4ème forme normale répond à deux critères :
On observe dans cette table que "Produit", "Client" et "Facture" sont 3 colonnes indépendantes. En revanche puisqu'un client peut avoir plusieurs adresses chaque combinaison de client-produit-facture peut apparaître plusieurs fois pour différentes adresses. Donc les factures qui correspondent à un client sont dépendantes de la colonne "Adresse". Donc la relation n’est pas en 4ème forme normale.
Dans un modèle de données SQL les colonnes seraient séparées dans différentes tables.
Dans un modèle BI, sous certaines conditions, on aurait créé une table de dimension pour chaque colonne et ces colonnes auraient été reliées à la table.
Quelques règles de conceptions d’un modèle de données BI.
Les bases OLAP (Online Analytical Processing) sont des systèmes de gestion de bases de données conçus pour répondre rapidement aux requêtes analytiques complexes. Ces bases sont très utilisées dans la BI. Elles permettent d'effectuer des analyses de données sous plusieurs dimensions et d'exécuter rapidement des calculs complexes.
Les tables de faits concentrent les données quantitatives des transactions. Les tables de dimension fournissent les attributs descriptifs pour les données dans les tables de fait.
En ce qui concerne les relations, la bonne pratique consiste à éviter les relations de plusieurs à plusieurs. Ce type de relation paralyse très rapidement les rapports et rend le modèle de données inexploitables à court terme. Il faut privilégier les relations d’un à plusieurs ou un à un.
Dans l'exemple de modèle de données BI ci-dessus les tables Marge et Infomax sont des tables de faits et les tables Dim_Pays et Dim_Date sont des tables de dimensions. On observe les tables Dim_Date et Dim_Days reliées aux tables Infomax et Marge par des liens de plusieurs à un. En effectuant un premier filtre sur un pays de la table de dimension Dim_Pays et un deuxième filtre sur une date de la table Dim_Date les bonnes données ressortiront dans les tables de faits. Il sera même possible d’effectuer des calculs en utilisant les colonnes des deux tables de faits. Par exemple en multipliant la colonne réalisée de la table infomax par la colonne marge de la table marge. Vouloir relier directement les deux tables de faits par des liens de plusieurs à plusieurs serait une erreur.
Rôle de la BI.
Le rôle de la BI est de fournir une capacité de calcul et d'analyse puissante et rapide. C'est un ensemble d'outils qui permettent l'intégration de données de nature différentes, leurs transformations et leurs analyses.
Contrairement à SQL, qui est principalement utilisé pour interroger les bases de données relationnelles, la BI est utilisée pour l'analyse avancée de données. SQL est souvent une composante des outils de BI. SQL est l'outil pour manipuler les données, tandis que la BI est l'outil pour interpréter les données.