azure
Support formation Microsoft Azure
azure
Support formation Microsoft Azure
DP-203

icon picker
Analyser les données dans un entrepôt de données relationnelles

Gonzague Ducos
Pools SQL dédiés dans Azure Synapse Analytics
Comme toutes les bases de données relationnelles, un entrepôt de données contient des tables dans lesquelles les données que vous souhaitez analyser sont stockées.
Ces tables sont organisées dans un schéma optimisé pour la modélisation multidimensionnelle, dans lequel des mesures numériques associées aux événements, appelées faits, peuvent être agrégées par les attributs des entités associées à plusieurs dimensions.

Concevoir un schéma d’entrepôt de données

Tables d’un entrepôt de données

Modèle courant pour les entrepôts de données relationnelles : définir un schéma avec 2 types de tables :
tables de dimension
tables de faits

Tables de dimension

Décrivent les entités métier
Contiennent des colonnes pour les attributs d’une entité
Contient une colonne “clé unique” qui identifie de manière unique chaque ligne de la table
En fait, on aura 2 clés :
Une clé de substitution spécifique à l’entrepôt de données et qui identifie de manière unique chaque ligne de la table de dimension dans l’entrepôt de données (généralement, un nombre entier incrémenté).
Une clé secondaire, souvent une clé naturelle ou métier, utilisée pour identifier une instance spécifique d’une entité dans le système source transactionnel à partir duquel l’enregistrement d’entité provient (par exemple, un code de produit ou un ID client).
info
Pourquoi utiliser deux clés ?
Si plusieurs sources, entrainerait des doublons.
Clés numériques fonctionnent généralement mieux dans les requêtes
Les attributs d’entités peuvent changer au fil du temps, on veut conserver un enregistrement pour chaque instance d’une entité à plusieurs instants
Inclure une table de dimension qui représente le temps. ​La granularité la plus faible (appelée grain) d’une dimension de temps peut représenter des heures (à l’heure, à la seconde, à la milliseconde, à la nanoseconde, ou encore moins), ou des dates

Tables de faits

Stockent des détails ou des événements
Contient des colonnes pour les valeurs numériques qui peuvent être agrégées par dimensions
Contient des colonnes clés qui référencent des clés uniques dans les tables de dimension associées

Conceptions de schémas d’entrepôts de données

Dans une base de donnée transactionnelle utilisée dans les applications métier, les données sont normalisées pour réduire la duplication.
Dans un entrepôt de données, les données de dimension sont généralement dénormalisées pour réduire le nombre de jointures requises pour interroger les données.
Un entrepôt de données est organisé comme un schéma en étoile, dans lequel une table de faits est directement liée aux tables de dimension. Les attributs d’une entité peuvent être utilisés pour agréger des mesures dans des tables de faits sur plusieurs niveaux hiérarchiques.
Lorsqu’une entité comporte un grand nombre de niveaux d’attribut hiérarchique ou que certains attributs peuvent être partagés par plusieurs dimensions (par exemple, les clients et les magasins ont une adresse géographique), on applique une normalisation aux tables de dimension et on crée un schéma en flocon.

Création de tables d’entrepôt de données

⁠
Concevoir des tables - Azure Synapse Analytics
⁠
⁠

Création d’un pool SQL dédié

Espace de travail Azure Synapse Analytics > Gérer
Paramètres de configuration suivants :
Le nom unique du pool SQL dédié
Le niveau de performances du pool SQL (de DW100c à DW30000c) qui détermine le coût par heure du pool en cours d’exécution
Point de départ : un pool vide ou une base de données existante restaurée à partir d’une sauvegarde
Classement du pool SQL, qui détermine les règles d’ordre de tri et de comparaison de chaînes de la base de données (non modifiable une fois créé)

Éléments à prendre en compte pour la création de tables

Pour créer des tables : CREATE TABLE (ou parfois CREATE EXTERNAL TABLE).
Types de tables créées :
Tables de faits
Tables de dimension
Tables de mise en lots : souvent utilisées dans le cadre du processus de chargement de l’entrepôt de données pour ingérer des données provenant de systèmes sources
Selon taille :
Lors de la conception d’un modèle de schéma en étoile pour les jeux de données de taille réduite ou moyenne : Azure SQL.
Pour les jeux de données plus volumineux, il peut s’avérer utile d’implémenter votre entrepôt de données dans Azure Synapse Analytics au lieu de SQL Server. Voici les différences.

Contraintes d’intégrité des données

Les pools SQL dédiés dans Synapse Analytics ne prennent pas en charge les contraintes de clé étrangère (FOREIGN KEY) ni d’unicité (UNIQUE) : les travaux utilisés pour charger des données doivent maintenir le caractère unique et l’intégrité référentielle des clés, sans compter pour cela sur les définitions de table de la base de données.

Index

Pools SQL dédiés Synapse Analytics prend en charge les index cluster comme dans SQL Server.
Pour les pools SQL dédiés Synapse Analytics, le type d’index par défaut est columnstore cluster car avantage significatif en matière de performances lors de l’interrogation de grandes quantités de données.

Distribution



Concevoir un schéma d’entrepôt de données
Tables d’un entrepôt de données
Tables de dimension
Tables de faits
Conceptions de schémas d’entrepôts de données
Création de tables d’entrepôt de données
Création d’un pool SQL dédié
Éléments à prendre en compte pour la création de tables
Contraintes d’intégrité des données
Index
Distribution
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.