Normalisation d'une base de données relationnelle

Les principes sont en partie différents selon que l’on vise un modèle transactionnel et un modèle décisionnel (cf

Broken link⁠

Tables

Une base de données relationnelle est un type de base de données où les données sont stockées dans des lignes et des colonnes qui forment ensemble des structures appelées tables.

Colonnes

Une colonne peut être vue comme un attribut du contenu que la table stocke ou décrit. Une ligne d’une table peut être vue comme un enregistrement qui contient les données de ces colonnes.

Chaque colonne définie des propriétés :

Nom (généralement sans espace ni accent)

Légende (nom en clair affiché pour l’utilisateur)

Type de données (cf. ci-dessous)

Format

et des règles :

autoriser ou non la valeur Null

limite à une plage de données les valeurs acceptées (par ex. > 0)

contient un calcul issu d’autres colonnes (par ex. Hauteur x Longueur)

écrit une valeur par défaut (par ex. date du jour)

Modèle de données et relations

Les tables d’une base de données peuvent être liées entre elles par des valeurs de clé unique.

Un modèle de données est une représentation des tables d’une base de données relationnelle et de la façon dont ces tables sont liées ou se référencent les unes aux autres.

Une relation définit le lien entre 2 colonnes de 2 tables, dont on établit une dépendance.

La table du côté “1” doit comporter une colonne Index sans doublons

La table du côté “plusieurs” doit comporter une colonne qui contient les mêmes valeurs que la colonne côté 1, pour établir un lien.

Par exemple, un IDProduit dans une table Produits sera référencé dans une table Commandes. Vous pouvez également avoir des valeurs de clé qui sont liées dans une hiérarchie par une relation un à plusieurs ou une relation parent-enfant.

Index

Un index permet de :

obliger à une valeur unique

accélère la recherche de valeur

Peut être composé de plusieurs champs.

ACID

Les propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité) sont essentielles pour garantir la fiabilité des transactions dans les bases de données. Voici un exemple simple qui illustre ces propriétés :

Exemple : une application bancaire qui gère les transactions financières. Une transaction typique pourrait être un virement d’argent d’un compte à un autre.

Atomicité : La transaction est indivisible. Si un utilisateur transfère de l’argent, soit la totalité de la transaction se réalise (l’argent est débité d’un compte et crédité sur l’autre), soit rien ne se passe en cas d’erreur. Exemple : supposons qu’un client souhaite transférer 100€ de son compte courant vers son compte épargne. La transaction est composée de deux opérations : débiter 100€ du compte courant et créditer 100€ sur le compte épargne. Ces deux opérations doivent être exécutées comme une seule unité atomique. Si l’une des opérations échoue, aucune des deux ne doit être appliquée.

Cohérence : La transaction respecte toutes les règles de la base de données. Par exemple, elle ne permet pas un solde négatif si la règle est que les comptes ne peuvent pas être en dessous de zéro. Exemple : avant et après la transaction, la somme des soldes des deux comptes doit rester la même. Si le client a 500€ sur son compte courant et 1000€ sur son compte épargne avant le transfert, il doit avoir 400€ et 1100€ respectivement après le transfert, préservant ainsi la cohérence des données.

Isolation : Même si plusieurs transactions se produisent en même temps, elles sont traitées de manière à ce qu’elles n’interfèrent pas les unes avec les autres. Exemple : si deux clients effectuent des transactions en même temps, l’un transférant de l’argent entre ses comptes et l’autre empruntant de l’argent, le système doit garantir que ces transactions ne se perturbent pas mutuellement. Par exemple, le calcul des intérêts ne doit pas être affecté par ces transactions simultanées.

Durabilité : Une fois la transaction terminée, elle est enregistrée de manière permanente, même en cas de panne du système. Exemple : une fois la transaction de transfert terminée et confirmée, elle doit être enregistrée de manière permanente. Même en cas de panne de système immédiatement après, les données ne doivent pas être perdues et le transfert doit rester effectif.

Dé-normalisation

En passant dans un modèle tabulaire, on dénormalise les données pour en faciliter l’analyse.

Source :

Analyser la structure d’une table de base de données - Training⁠

⁠

Gallery

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.