From 2043a7b4538c86af29f78ecf0d8310467d6fa233 Mon Sep 17 00:00:00 2001 From: medina5 Date: Wed, 10 Sep 2025 07:32:05 +0200 Subject: [PATCH] bi --- Arbres.md | 161 ++++++++++++++++++++++++-- Home.md | 11 ++ Jointure.md | 1 - arbre/autojointure.svg | 57 ++++++++++ datawarehouse.md | 64 +++++++++++ models.md | 84 ++++++++++++++ prime_tree_azure.svg | 250 ----------------------------------------- 7 files changed, 368 insertions(+), 260 deletions(-) create mode 100644 arbre/autojointure.svg create mode 100644 datawarehouse.md create mode 100644 models.md delete mode 100644 prime_tree_azure.svg diff --git a/Arbres.md b/Arbres.md index 06adc30..afe8a8d 100644 --- a/Arbres.md +++ b/Arbres.md @@ -13,7 +13,7 @@ Chaque nœud stocke l’identifiant de son parent. Avantages - Simple à comprendre. -- Facile à insérer / modifier. +- Facile à insérer et à modifier. Limites - Difficile d’interroger plusieurs niveaux sans récursivité. @@ -35,18 +35,161 @@ CREATE TABLE familles ( └── Accessoires TV ``` -### +### Lire la famille de premier niveau -## Nested Sets (modèle d’ensembles imbriqués) -Représentation intervallaire +```sql +SELECT code, famille, code_parent + FROM famille + WHERE code = '02' +``` +### Lire les enfants directs du premier niveau + +```sql +SELECT code, famille, code_parent + FROM famille + WHERE code_parent = '02' +``` + +code|famille|parent +---|---|--- +02RACINE| **** Racines & Tubercules |02 +02CUCURB| **** Cucurbitacées |02 +02LEGUM| **** Légumineuses |02 +02COMPOS| *** Produits composés |02 +02FEUILLE| **** Feuilles et tiges v02 +02SOLAN| **** Solanacées |02 +02CHAM| Champignons |02 +02CHOU| Chou |02 +02MAIS| Maïs |02 + +### Combiner les résultats + +```sql +SELECT code, famille, code_parent + FROM famille + WHERE code = '02' +UNION ALL +SELECT code, famille, code_parent + FROM famille + WHERE code_parent = '02' +``` + +Utiliser la récursivité pour descendre en profondeur + +```sql +WITH RECURSIVE famille_parent AS ( +SELECT code, famille, code_parent + FROM famille + WHERE code = '01' +UNION ALL +SELECT f.code, f.famille, f.code_parent + FROM famille f + join famille_parent on f.code_parent = famille_parent.code +) +SELECT * FROM famille_parent; +``` + +### Remonter les familles jusqu'à la racine + +```sql +WITH RECURSIVE ancetre AS ( + SELECT code, famille, code_parent, 1 AS niveau + FROM famille + WHERE code = '02CUCURB' + UNION ALL + SELECT f.code, f.famille, f.code_parent, a.niveau + 1 + FROM famille f + JOIN ancetre a ON a.code_parent = f.code +) +SELECT * +FROM ancetre +ORDER BY niveau DESC; -- de la racine vers le nœud +``` + +Récupérer la hiérarchie dans une chaine de caractères formatée. + +```sql +SELECT string_agg(nom, ' > ' ORDER BY niveau DESC) AS fil_ariane +FROM ancetres; +``` + +## représentation intervallaire + +Le modèle d’adjacency list (parent_id) est simple, mais certaines requêtes deviennent complexes, surtout : + +- récupérer tous les descendants d’un nœud, +- récupérer le chemin complet d’un nœud. + +La représentation intervallaire ou modèle d’ensembles imbriqués (Nested Sets) résout ce problème en attribuant à chaque nœud deux valeurs entièrement déterministes : + +inf (gauche) +sup (droite) + +Ces valeurs définissent un intervalle [inf, sup] qui contient tous les descendants du nœud. + +### Principe + +Chaque nœud reçoit deux nombres (inf et sup) de telle sorte que : + +- la racine a l’intervalle le plus large [1, 2n] pour n nœuds, +- un enfant est strictement inclus dans l’intervalle de son parent, +- aucun nœud n’a un intervalle qui chevauche celui d’un nœud non descendant. + +La représentation intervallaire est très efficace pour les lectures d’arbres complexes. Elle est particulièrement adaptée aux arbres stables. En cas de modifications il faut recalculer les bornes de tous les noeuds. + +```sql +SELECT * +FROM famille +WHERE inf BETWEEN 2 AND 7 +ORDER BY inf; +``` + +### Récupérer tous les ancêtres + +```sql +SELECT * +FROM familles +WHERE inf <= 5 AND sup >= 6 +ORDER BY inf; +``` + +### Calculer la profondeur + +```sql +SELECT COUNT(parent.id) AS profondeur +FROM famille AS node +JOIN famille AS parent + ON parent.inf < node.inf AND parent.sup > node.sup +WHERE node.code = '02CUCURB'; +``` ## Materialized Path (chemin matérialisé) -Trouver tous les articles descendants d’une catégorie +Dans les bases de données relationnelles, représenter une hiérarchie peut être complexe. Les modèles classiques, comme Adjacency List ou Nested Sets, nécessitent des requêtes récursives ou des mises à jour délicates pour récupérer les descendants, ancêtres ou construire un fil d’Ariane. + +PostgreSQL propose l’extension ltree, spécialement conçue pour représenter des arborescences de manière simple et efficace. Elle permet de stocker un chemin complet pour chaque nœud et fournit des opérateurs et fonctions pour manipuler ces chemins. + +L’extension introduit le type ltree, qui est une chaîne de labels séparés par des points, représentant le chemin depuis la racine jusqu’au nœud. Chaque segment (label) correspond à un nœud de l’arbre. +Il représente le chemin complet depuis la racine, ce qui simplifie toutes les opérations sur l’arbre. + + + +### Trouver toutes les familles descendantes d’une catégorie + +Utilisation d'un nouvel opérateur `<@` ```sql -SELECT a.name -FROM articles a -JOIN categories c ON a.category_id = c.id -WHERE c.path <@ 'Legumes.Racine'; +select famille +FROM famille +WHERE famille.arborescence <@ 'Jardin.Primeur.Legumes'; +``` + +### Trouver toutes les ancetres d’une famille + +```sql +SELECT f.* +FROM famille f +JOIN famille cible ON cible.code = '02POTIR' +WHERE f.arborescence @> cible.arborescence +ORDER BY nlevel(f.arborescence); ``` diff --git a/Home.md b/Home.md index b4a0048..94a6b12 100644 --- a/Home.md +++ b/Home.md @@ -8,6 +8,8 @@ - [Vues et fonctions](View.md) - [Fonctions de fenêtrage](window.md) - [Colonnes calculées](Calculated.md) +- [Business Intelligence](datawarehouse.md) + - [Les modèles de données](models.md) - [Intervalles](intervalle.md) - [Arbres](Arbres.md) - [Données spatiales](Spatial.md) @@ -45,6 +47,15 @@ group by mois --date_trunc('month', date_ticket) - Afficher pour chaque adhérent la date et le montant de son dernier ticket. [voir](sousrequete.md#laterals). +## Séance 2 + +- Calculer le chiffre d'affaire par jour de la semaine. Quel est le jour où il y a plus de vente ? +- Ajouter une colonne calculée à la table adhérent pour calculer l'age de l'adhérent +- Créer une vue materialisée de type flat table contenant les toutes informations des tickets +- Analyser le total des ventes par mois + + + Arrondir les montant à deux chiffres après la virgule. diff --git a/Jointure.md b/Jointure.md index bd718a9..03e01cc 100644 --- a/Jointure.md +++ b/Jointure.md @@ -112,7 +112,6 @@ where famille.code is null Attention ! La valeur `null` ne peut être comparée à rien. L'égalité avec null retourne ni vrai ni faux mais null. Ainsi null n'est pas égal à null. Pour la comparaison avec null il faut utiliser les mots-clés `is` ou `is not`. - ## Jointure croisée ou produit cartésien La jointure croisée renvoie le produit cartésien des deux tables. Chaque ligne de la première table est combinée avec chaque ligne de la deuxième table. Cela produit un très grand nombre de lignes de résultat. diff --git a/arbre/autojointure.svg b/arbre/autojointure.svg new file mode 100644 index 0000000..6c097bb --- /dev/null +++ b/arbre/autojointure.svg @@ -0,0 +1,57 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 1 + 3 + diff --git a/datawarehouse.md b/datawarehouse.md new file mode 100644 index 0000000..0781f18 --- /dev/null +++ b/datawarehouse.md @@ -0,0 +1,64 @@ +--- +title: Entrepôts de données +--- + +Un data warehouse, ou entrepôt de données, est un système de gestion de base de données conçu pour stocker, consolider et organiser de grandes quantités de données provenant de sources multiples en vue d’une analyse et d’un reporting. Il sert de référentiel centralisé où les données sont structurées de manière à faciliter la prise de décision et les analyses historiques dans les entreprises. + +- **Centralisation des données** : Un data warehouse intègre des données provenant de différentes sources (bases de données opérationnelles, ERP, CRM, fichiers externes, etc.). Ces données sont rassemblées dans un seul et même endroit pour un accès facilité et une vision globale des informations. +- **Historisation des données** : Contrairement aux bases de données transactionnelles, qui stockent des données en temps réel ou à court terme, un data warehouse contient des données historiques. Il permet donc d’analyser des tendances et d’effectuer des prévisions basées sur plusieurs années d’informations. +- **Optimisation pour l'analyse** : Les données dans un data warehouse sont structurées de manière à faciliter les requêtes analytiques complexes. Elles sont souvent organisées selon un modèle multidimensionnel (modèle étoile ou flocon) pour permettre une analyse rapide et facile à travers divers axes (produits, clients, régions, temps, etc.). +- **Extraction, Transformation, Chargement (ETL)** : Les données intégrées dans un data warehouse passent par un processus ETL : + - **Extraction** : Les données sont extraites des différentes sources. + - **Transformation** : Les données sont nettoyées, agrégées et transformées pour être cohérentes entre elles. + - **Chargement** : Les données transformées sont ensuite chargées dans le data warehouse. +- **Non volatile** : Une fois les données intégrées dans l’entrepôt de données, elles ne sont pas modifiées ou mises à jour, contrairement aux bases de données opérationnelles. Cela permet d'assurer une intégrité historique des informations pour des analyses fiables. +- **Orienté sujet**: Les data warehouses sont souvent organisés par thème ou sujet d’intérêt. Par exemple, un entrepôt de données peut avoir des sections dédiées aux ventes, aux finances, ou à la logistique. Cela permet aux utilisateurs d'accéder directement aux données pertinentes pour leurs besoins. + +## Architecture d'un data warehouse + +### Sources de données +Des données proviennent de différentes applications et bases de données (systèmes transactionnels, feuilles Excel, ERP, CRM, etc.). + +### Processus ETL +Ce processus assure la transformation et l’intégration des données. Il comprend l’extraction des données des systèmes sources, leur nettoyage, la gestion des incohérences, l’intégration et le chargement dans l’entrepôt. + +### Entrepôt de données +Il s'agit de la base de données centralisée où les données sont stockées de manière structurée pour faciliter l’analyse. + +### Outils d'accès et d'analyse +Les utilisateurs peuvent accéder aux données du data warehouse via des outils de Business Intelligence (BI) comme des tableaux de bord, des rapports, ou des outils de requête SQL. + +## Avantages d'un data warehouse + +- Consolidation des données : Il centralise les données provenant de diverses sources, ce qui permet une vision globale et cohérente de l'entreprise. +- Analyse historique : Les données historiques stockées dans le data warehouse permettent d'identifier des tendances et de prendre des décisions stratégiques éclairées. +- Amélioration des performances analytiques : Les entrepôts de données sont conçus pour optimiser les requêtes analytiques complexes, ce qui les rend plus rapides et efficaces que les bases de données transactionnelles. +- Fiabilité et intégrité des données : Les processus ETL garantissent que les données sont nettoyées, transformées et harmonisées avant d’être chargées dans l’entrepôt, réduisant ainsi les risques d’erreurs. + +## Exemples d'utilisation d'un data warehouse + +- Analyse des ventes : Une entreprise peut utiliser un data warehouse pour analyser les tendances de vente sur plusieurs années, en segmentant les données par produit, région, ou période. +- Prévision financière : Un entrepôt de données peut aider à compiler et à analyser des données financières provenant de différents services pour prévoir les performances futures. +- Optimisation des opérations : En agrégeant des données de production, de logistique et de ventes, un data warehouse permet d’optimiser les chaînes d'approvisionnement et les processus opérationnels. + +Dans le cadre de la Business Intelligence (BI) et plus précisément dans la conception des entrepôts de données, les tables de faits et les tables de dimensions sont des concepts centraux du modèle en étoile ou modèle multidimensionnel. + +## Tables de faits + +Une table de faits est au cœur d'un entrepôt de données. Elle stocke des données **quantitatives** ou **mesurables** liées aux événements d'une entreprise. Ces événements sont souvent des transactions ou des interactions importantes que l'entreprise souhaite analyser. Les données de la table de faits représentent des **mesures chiffrées** (par exemple, ventes, revenus, quantité vendue, etc.), qui sont généralement utilisées pour l'analyse et l'évaluation des performances. + +Caractéristiques d'une table de faits : + +- **Granularité** : Chaque ligne de la table représente un événement unique ou une transaction. La granularité définit le niveau de détail des faits (par exemple, un enregistrement par jour, par produit, par client, etc.). +- **Mesures** : Les colonnes de la table de faits contiennent les mesures numériques (chiffres de vente, quantités, coûts, bénéfices, etc.). +- **Clés étrangères** : Les tables de faits contiennent des clés étrangères qui se réfèrent aux clés primaires des tables de dimensions. Ces clés permettent de relier les faits aux informations contextuelles (produit, temps, client). + +## Tables de dimensions + +Les tables de dimensions fournissent des informations **qualitatives** ou **descriptives** qui donnent un contexte aux données stockées dans les tables de faits. Elles ne contiennent généralement pas de mesures, mais des **attributs** qui décrivent les faits. Par exemple, dans une analyse des ventes, les dimensions pourraient être le produit, le client, ou le temps. + +## Relation entre les tables de faits et les tables de dimensions + +La relation entre les tables de faits et de dimensions se fait par des clés étrangères. Par exemple, une vente spécifique (enregistrée dans la table de faits) est liée à un produit précis, un client spécifique et une date donnée (enregistrés dans les tables de dimensions correspondantes). Cela permet de construire des analyses détaillées, telles que les ventes par produit, par période de temps ou par région. + +Les tables de dimensions apportent le **contexte descriptif** nécessaire pour analyser ces données. diff --git a/models.md b/models.md new file mode 100644 index 0000000..8894edf --- /dev/null +++ b/models.md @@ -0,0 +1,84 @@ +--- +title: Modèles de données +--- + +Il existe deux (trois) modèles principaux, le modèle étoile (star) et le modèle flocon (snowflake). Ils sont utilisés dans les entrepôts de données pour organiser les données de manière à **faciliter** les analyses multidimensionnelles, particulièrement dans les systèmes de Business Intelligence (BI). Ces modèles se distinguent par la manière dont les tables de faits et les tables de dimensions sont structurées et reliées entre elles. + +## Modèle étoile (Star Schema) + +Le modèle en étoile est une structure simple où une table de faits est reliée **directement** à plusieurs tables de dimensions. Il est appelé "étoile" parce que la table de faits est au centre, et les tables de dimensions sont organisées autour d’elle, formant ainsi une structure qui ressemble à une étoile. + +### Caractéristiques du modèle étoile : + +- **Simplicité** : Les tables de dimensions ne sont pas normalisées, c’est-à-dire qu’elles peuvent contenir des données redondantes ou dupliquées. +- **Accès rapide** : Comme les tables de dimensions sont dénormalisées (les données sont centralisées et répétées), les requêtes sont plus simples et plus rapides à exécuter. Il y a moins de jointures à réaliser +- **Lisibilité** : Le modèle est simple à comprendre et à concevoir, car il n'y a qu'une seule relation directe entre la table de faits et chaque table de dimension. Idéal pour des besoins analytiques simples avec de grandes quantités de données. + +## Modèle flocon (Snowflake Schema) + +Le modèle flocon est une extension du modèle étoile. Dans ce modèle, certaines ou toutes les tables de dimensions sont **normalisées**, c’est-à-dire qu'elles sont subdivisées en plusieurs sous-tables pour éliminer les redondances. Le modèle est appelé "flocon" parce que la structure résultante a une forme plus complexe, semblable à celle d'un flocon de neige. + +### Caractéristiques du modèle flocon + +- **Normalisation** : Les tables de dimensions sont divisées en plusieurs sous-tables pour éliminer les données redondantes. Chaque sous-table représente une dimension spécifique. +- **Complexité** : Les requêtes sont plus complexes à écrire et prennent plus de temps à s'exécuter car elles impliquent plusieurs jointures entre les tables de dimensions et sous-tables. +- **Réduction de la redondance** : Le modèle flocon réduit la redondance des données dans les dimensions. Les tables étant normalisées, les données redondantes sont éliminées, ce qui réduit la taille des tables. + +#### Inconvénients + +- **Requêtes plus lentes** : Le modèle flocon nécessite des jointures supplémentaires entre les tables, ce qui peut ralentir l’exécution des requêtes. +- **Complexité accrue** : La structure est plus complexe à comprendre et à concevoir par rapport au modèle étoile. + +## Table aplatie (flat table) + +Tout est regroupé dans une seule table large. + +Exemple : une seule table qui contient directement Produit, Sous-famille, Famille, Client, Date, etc. + +Avantage : très simple pour les outils BI et le reporting. +Il existe deux (trois) modèles principaux, le modèle étoile (star) et le modèle flocon (snowflake). Ils sont utilisés dans les entrepôts de données pour organiser les données de manière à **faciliter** les analyses multidimensionnelles, particulièrement dans les systèmes de Business Intelligence (BI). Ces modèles se distinguent par la manière dont les tables de faits et les tables de dimensions sont structurées et reliées entre elles. + +## Modèle étoile (Star Schema) + +Le modèle en étoile est une structure simple où une table de faits est reliée **directement** à plusieurs tables de dimensions. Il est appelé "étoile" parce que la table de faits est au centre, et les tables de dimensions sont organisées autour d’elle, formant ainsi une structure qui ressemble à une étoile. + +### Caractéristiques du modèle étoile : + +- **Simplicité** : Les tables de dimensions ne sont pas normalisées, c’est-à-dire qu’elles peuvent contenir des données redondantes ou dupliquées. +- **Accès rapide** : Comme les tables de dimensions sont dénormalisées (les données sont centralisées et répétées), les requêtes sont plus simples et plus rapides à exécuter. Il y a moins de jointures à réaliser +- **Lisibilité** : Le modèle est simple à comprendre et à concevoir, car il n'y a qu'une seule relation directe entre la table de faits et chaque table de dimension. Idéal pour des besoins analytiques simples avec de grandes quantités de données. + +## Modèle flocon (Snowflake Schema) + +Le modèle flocon est une extension du modèle étoile. Dans ce modèle, certaines ou toutes les tables de dimensions sont **normalisées**, c’est-à-dire qu'elles sont subdivisées en plusieurs sous-tables pour éliminer les redondances. Le modèle est appelé "flocon" parce que la structure résultante a une forme plus complexe, semblable à celle d'un flocon de neige. + +### Caractéristiques du modèle flocon + +- **Normalisation** : Les tables de dimensions sont divisées en plusieurs sous-tables pour éliminer les données redondantes. Chaque sous-table représente une dimension spécifique. +- **Complexité** : Les requêtes sont plus complexes à écrire et prennent plus de temps à s'exécuter car elles impliquent plusieurs jointures entre les tables de dimensions et sous-tables. +- **Réduction de la redondance** : Le modèle flocon réduit la redondance des données dans les dimensions. Les tables étant normalisées, les données redondantes sont éliminées, ce qui réduit la taille des tables. + +#### Inconvénients + +- **Requêtes plus lentes** : Le modèle flocon nécessite des jointures supplémentaires entre les tables, ce qui peut ralentir l’exécution des requêtes. +- **Complexité accrue** : La structure est plus complexe à comprendre et à concevoir par rapport au modèle étoile. + +## Table aplatie (flat table) + +Tout est regroupé dans une seule table large. + +Exemple : une seule table qui contient directement Produit, Sous-famille, Famille, Client, Date, etc. + +Avantage : très simple pour les outils BI et le reporting. + +#### Inconvénients + +- beaucoup de redondance, +- consommation d’espace, +- difficile à maintenir. + +#### Inconvénients + +- beaucoup de redondance, +- consommation d’espace, +- difficile à maintenir. diff --git a/prime_tree_azure.svg b/prime_tree_azure.svg deleted file mode 100644 index a7574cb..0000000 --- a/prime_tree_azure.svg +++ /dev/null @@ -1,250 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 - - - - - - - 3 -