Formalisation des bases de données

Slides
Author

Ludovic Deneuville

Objectifs

Structurer une base de données pour qu’elle soit :

  • efficace
  • propre
  • légère
  • facile à maintenir
  • pas de doublons et de redondances
  • Moins de risques d’incohérences entre différentes parties de la base
  • Stockage réduit, car les informations répétées sont éliminées.

1 Dépendances fonctionnelles

Définition

Une dépendance fonctionnelle indique qu’une colonne (ou un ensemble de colonnes) détermine de manière unique une autre colonne :

  • X → Y
  • X détermine Y
  • Y dépend fonctionnellement de X

Si on connait X, on peut en déduire Y

Les axiomes d’Armstrong

Nom Description
Réflexivité (X, Y) → X
Augmentation Si X → Y, alors XZ → YZ
Transitivité Si X → Y et Y → Z alors, X → Z
  • (nom, prenom) → nom
  • id_joueuse → nom alors (id_joueuse, id_partie) → (id_joueuse, nom)

Règles dérivées

Nom Description
Union Si X → Y et X → Z, alors X → YZ
Décomposition Si X → YZ, alors X → Z et X → Y
Pseudo-transitivité Si X → Y et WY → Z alors WX → Z

Deux Propriétés

Dépendance Fonctionnelle Élémentaire

X → Y est élémentaire s’il n’existe aucun sous-ensemble strict Z inclus dans X tel que Z → Y

Dépendance Fonctionnelle Directe

X → Y est directe s’il n’existe pas de Z tel que X → Z et Z → Y

  • pas élémenaire : num_client, nom → adresse

2 Formes normales

Normalisation

Définition

La normalisation vise à organiser les données :

  • en éliminant les redondances et les incohérences
  • en préservant les dépendances fonctionnelles
  • sans perdre d’informations

1ère forme normale

Définition

Une relation est 1NF si tous ses attributs sont atomiques.

  • Une date est atomique
  • Un nom est atomique
  • Une liste de prénoms n’est pas atomique
  • Est-ce qu’un adresse est atomique ?
  • atomique : représente une seule information
  • non atomique : plusieurs informations combinées
  • assez subjectif
  • dépend du cas d’utilisation
    • si vous n’utilisez pas le champ adresse -> atomique
    • si vous avez utiliser par exemple la ville -> pas atomique

2e forme normale

Définition

Une relation est 2NF si :

  • elle est 1NF
  • tout attribut non clé est en DF élémentaire avec la clé

Autrement dit, tous les attributs sont déterminés par la clé complète.

Exemple de relation non 2NF :

  • joueuse(nom, prenom, dnais) → elo
  • si par exemple (nom, dnais) → elo
    • si nom et dnais suffisent pour déterminer le elo

3e forme normale

Définition

Une relation est 3NF si :

  • elle est 2NF
  • tout attribut non clé est en DF directe avec la clé

Autrement dit, un attribut ne peut pas dépendre fonctionnellement d’un autre attribut non clé.

Exemple de relation non 3NF :

  • joueuse(id_joueuse, code_pays, capitale)
  • id_joueuse → (code_pays, capitale)
  • or code_pays → capitale donc DF non directe
Passer en 3NF

Créer une table pays

  • joueuse(id_joueuse, code_pays)
  • pays(code_pays, capitale)

3 Modélisation UML

Unified Modeling Language

Définition

UML est un langage de modélisation graphique standardisé utilisé pour spécifier, visualiser, concevoir et documenter différents aspects des systèmes logiciels.

Il offre une série de diagrammes pour représenter différents aspects d’un système.

Modèles

Modèle conceptuel

classDiagram
    class Joueuse {
        identifiant
        nom
        prenom
        elo
        identifiant du club
    }

Modèle physique

classDiagram
    class joueuse {
        id_joueuse SERIAL PK
        nom        VARCHAR50
        prenom     VARCHAR50
        elo        INT
        #id_club   INT
    }

  • Conceptuel : niveau utilisateur (accents, espaces)
  • Physique : niveau développeur (transposable directement en SQL)

Associations 1:n

classDiagram
    direction LR
    class joueuse {
        id_joueuse SERIAL PK
        nom        VARCHAR50
        prenom     VARCHAR50
        elo        INT
        #id_club   INT
    }
    
    class club {
        id_club   SERIAL PK
        nom       VARCHAR50
        ville     VARCHAR50
    }

    joueuse "*" -- "0..1" club

cf. Cours BDD, partie associations

Associations multiples

classDiagram
    direction LR
    class joueuse {
        id_joueuse SERIAL PK
        nom        VARCHAR50
        prenom     VARCHAR50
        elo        INT
        #id_club   INT
    }
    
    class partie {
        #id_blanc     INT
        #id_noir      INT
        #id_resultat  INT
    }

    partie "*" --> "1" joueuse : jouée avec les blancs par ▶
    partie "*" --> "1" joueuse : jouée avec les noirs par ▶

Associations n:n

classDiagram
    direction LR
    class joueuse {
        id_joueuse SERIAL PK
        nom        VARCHAR50
        prenom     VARCHAR50
        elo        INT
        #id_club   INT
    }
    
    class participe {
        #id_joueuse     INT
        #id_tournoi     INT
    }

    class tournoi {
        #id_tournoi     INT
        nom             INT
    }

    joueuse "1" -- "*" participe
    participe "*" -- "1" tournoi