Manipuler les bases de données - Merise
Dernière mise à jour : Janvier 2026
Parcours d'apprentissage
Partie 1 : Concevoir une base de données
Partie 2 : Modéliser les données
Partie 3 : Normaliser les données
Partie 1 : Concevoir une base de données
Analyser le cahier des charges
1. Introduction et Système d'Information
Dans chaque organisation, une quantité importante d'informations est échangée afin d'assurer le bon fonctionnement de cette organisation ainsi que la communication avec son environnement. Ces informations ont pour but d'être utilisables dans les activités opérationnelles quotidiennes ou encore dans la prise de décision.
Ces informations doivent être bien organisées et stockées. Il est donc nécessaire pour chaque organisme d'avoir une structure fonctionnelle et technique de gestion de l'information.
Le Système d'Information (SI)
Le système d'information représente l'ensemble des éléments participants aux activités d'acquérir, de stocker, de traiter et de communiquer les informations au sein d'une organisation.
Il se compose des acteurs suivants :
En plus des spécialistes des SI chargés de la conception, la mise en œuvre et la gestion du SI, cette catégorie comprend aussi les personnes qui utilisent ce dernier pour acquérir, communiquer, stocker ou traiter des informations.
Il s'agit de tout dispositif physique permettant d'émettre, manipuler ou stocker l'information.
Ce sont les programmes qui sont nécessaires au fonctionnement du SI ainsi que les procédures qui gèrent les traitements manuels et automatisés.
Elles constituent la matière première des traitements, qu'elles soient saisies, déduites ou calculées.
2. Définitions : Un projet informatique
Un projet informatique est un projet dont les livrables sont des outils ou services informatiques (logiciels, systèmes d'information, sites web, etc.). Il s'agit de projets généralement complexes, principalement dû à la grande diversité des intervenants (techniciens, responsables métier, marketeurs, gestionnaires, etc.) ainsi qu'à la difficulté de définir toutes les exigences.
Le processus de développement (5 phases)
Elaboration du schéma directeur
Il s'agit d'une étude globale du système d'information à construire. Le but de cette étape est de réaliser le schéma directeur ainsi que le plan de développement informatique.
Etude préalable
Il s'agit d'une étude critique de l'existant et de la définition des objectifs du nouveau système. Le but de cette étape est de produire un dossier d'étude et la prise de décision du choix de la solution.
Etude détaillée
Il s'agit de fournir avec précision la description de la solution souhaitée : Définir logiquement les données et les traitements informatiques, les interfaces, le matériel, etc. et construire le planning de réalisation. Le but est de produire un cahier de charges fonctionnel et technique.
Réalisation
Il consiste à la production du logiciel, l'implantation des bases de données et la mise en place de la solution.
Mise en œuvre de la solution et maintenance
Adapter la solution aux évolutions de l'environnement.
Le Cahier des Charges
Le cahier de charges est un document essentiel à l'élaboration et la réalisation d'un projet. Il s'agit du document sur lequel les développeurs se basent pour concevoir et implémenter une base de données.
Il présente une description détaillée du besoin des utilisateurs à savoir :
- Le contexte général
- L'objectif du projet
- Les fonctionnalités attendues
- Les flux d'information et les processus métier
- Les règles de gestions des données
Le cahier de charges technique (CDCT)
Il contient les exigences et contraintes techniques, économiques, industrielles, environnementales et matérielles d'un projet. Il sert à définir l'environnement technique : Architecture technique, les outils à utiliser, les technologies...
Le cahier de charges fonctionnel (CDCF)
Il décrit la structure, les besoins et les fonctionnalités attendues du maître d'ouvrage. Il contient les informations qui permettent d'adresser les exigences liées au projet en précisant les conditions de réalisation. Le CDCF doit comporter assez de détails pour être compréhensible par tous les acteurs.
La structure d'un cahier de charges
Contexte et présentation du projet
On commence par présenter l'entreprise et l'importance du projet dans son plan stratégique. On définit aussi les acteurs cibles, les objectifs et le périmètre du projet. Cette partie contient aussi la description de l'existant.
- Entreprise : Le groupe se compose de 4 hôpitaux. Sa mission est de fournir des services de santé pour les habitants de la région.
- Projet : Refonte du SI hospitalier pour augmenter la productivité, collecter plus d'infos et minimiser l'attente des patients.
- Périmètre : Utilisé par les différents hôpitaux (>2000 utilisateurs journaliers).
Description graphique et ergonomique
On y décrit la charte graphique ainsi que tous les éléments graphiques et ergonomiques exigés (logo, typographie, couleurs, illustrations...).
Description fonctionnelle et technique
Cette étape décrit les spécifications techniques et fonctionnelles des livrables.
- Plateforme technique
- Technologies de développement
- Sécurité
- Données à collecter
- Règles de gestion
Définition des résultats attendus
On présente dans ce stade toutes les prestations attendues à la fin du projet ainsi que les délais de livraison.
Budgétisation et fixation des délais
Cette phase concerne l'estimation du budget global permettant d'aiguiller les potentiels prestataires pour la réalisation de leurs devis.
Exercice d'application
Testez-vousParmi les éléments suivants, lequel appartient spécifiquement au Cahier des Charges Fonctionnel (CDCF) ?
- L'architecture serveur (Linux/Windows)
- Le diagramme des cas d'utilisation (Besoins utilisateurs)
- Le choix du langage de programmation (PHP/Java)
Voir la solution
Le CDCF décrit le QUOI (besoins métier), tandis que le CDCT décrit le COMMENT (solutions techniques comme les serveurs ou langages).
Description des limites et Périmètre du projet
Description des limites
Le cahier de charges représente les attentes, les besoins et les contraintes du client. En procédant à sa lecture, il faut définir :
- Le contexte du projet.
- L'ensemble des données que le système est supposé gérer et stocker.
- Les conditions et règles de gestion exprimées.
Définir le périmètre : 4 Étapes Clés
1. Définir les buts
Il s'agit des objectifs à réaliser par le biais du projet.
2. Définir les livrables
Identifier les résultats attendus (choses tangibles) pour détecter les dérivées des objectifs.
3. Définir les tâches et activités
Moyens permettant la création des livrables (livrables découpés en tâches).
4. Définir les contraintes
- Budget/Coût : Ressources financières (Matériel, Humain...).
- Temps : Calendrier de livraison/Phases.
- Portée : Objectifs/Fonctionnalités/Tâches.
Analyse des données et de la situation
Introduction et Définition
On inclut souvent dans un projet informatique : les bases de données et le système informatique comprenant les ressources, infrastructures réseau, applications et sécurité. L'élaboration des bases de données est un pilier du livrable.
Une Base de Données
Est une structure permettant de stocker un grand nombre d'informations afin d'en faciliter l'utilisation.
Les Phases de Conception d'une Base de Données
Analyse
Analyse du cahier de charges et clarification du besoin client.
Conception (MCD)
Modèle Conceptuel représentant tous les éléments nécessaires.
Traduction (MLD)
Passage du conceptuel au Modèle Logique.
Implémentation
Création physique de la base de données (Solution).
Exercice d'application
Testez-vousRemettez ces étapes de conception d'une base de données dans l'ordre chronologique :
- Implémentation (SQL)
- Analyse du besoin
- Modèle Logique (MLD)
- Modèle Conceptuel (MCD)
Voir la solution
On commence toujours par l'Analyse, on dessine le concept (MCD), on le traduit en tables (MLD) et enfin on le code (SQL).
Exemple Cahier de charges : Gestion d'un centre de formation
Le Besoin
Un centre de formation désire stocker et gérer des données concernant les étudiants et les formations dans lesquelles ils sont inscrits.
Le travail demandé est la modélisation des données persistantes et la représentation sous forme tabulaire de ces données telles qu'elles seront stockées.
Processus Métier
- Gérer les données des étudiants.
- Gérer les formations et sessions.
- Gérer les inscriptions (Choix formation, session, paiement).
Définition des Données (Dictionnaire)
- Étudiant : CIN (Identifiant), Nom, Prénom, Date de naissance, Adresse, Ville, Niveau scolaire.
- Inscription : Remplissage fiche, Choix Formation, Choix Session, Type cours (Présentiel/Distance).
- Formation : Code, Titre, Durée, Prix, Spécialités (Code, Nom).
- Session : Date début, Date fin.
Règles de Gestion (Contraintes)
- Un étudiant peut être inscrit dans plusieurs sessions de formations.
- La formation peut se tenir en plusieurs sessions.
- Un étudiant ne peut pas être inscrit à plusieurs sessions de la même formation.
- Une formation n'est ouverte que si il y a plus de 10 étudiants inscrits.
- Une formation peut faire partie de plusieurs spécialités.
Vers la Modélisation (Tables/Entités)
Les règles de gestion ainsi que les informations collectées permettent de définir les éléments de la base de données qu'on va construire, les relations entre ces éléments et aussi d'assurer l'intégrité (Exhaustivité, Exactitude, Cohérence).
Partie 2 : Modéliser les données
Contraintes déduites des règles de gestion
Les règles de gestion fournies par le cahier des charges permettent d'identifier les éléments de données de la base à concevoir. Ces règles doivent être traduites en contraintes afin d'assurer l'intégrité des données et la validation des modèles à construire.
Identification des éléments (Exemple Centre de Formation)
Les attributs des entités « ÉTUDIANT », « FORMATION », « SESSION » et « SPÉCIALITÉ » sont déduits du texte et des fiches de renseignements.
Règles de Gestion Identifiées
- Un étudiant peut être inscrit dans plusieurs sessions.
- La formation peut se tenir en plusieurs sessions.
- Un étudiant ne peut pas être inscrit à plusieurs sessions de la même formation.
- Une formation n'ouvre que si > 10 étudiants inscrits.
- Une formation peut faire partie de plusieurs spécialités.
Tableau de synthèse des règles
| N° | Énoncé de la règle |
|---|---|
| 1 | Un élément de l'entité ÉTUDIANT peut être associé à plusieurs éléments de l'entité SESSION. |
| 2 | Une SESSION concerne une FORMATION unique. |
| 3 | Une FORMATION peut être associée à plusieurs SESSIONS. |
| 4 | Une FORMATION peut être associée à une ou plusieurs SPÉCIALITÉS. |
Dictionnaire des données
Concepts Clés : Distinguer les informations
Le Concept
Objets qui deviendront des "Entités". Ils sont décomposables en plusieurs données.
La Donnée
Information élémentaire indivisible, souvent liée à un concept.
La Valeur
Occurrence ou exemple d'une donnée précise.
Exemple : Dictionnaire des données (Centre de Formation)
Extrait| Code Donnée | Désignation | Type | Taille | Observation |
|---|---|---|---|---|
| Entité : Etudiant | ||||
| numCINEtu | Numéro CIN | Alphanumérique | 9 | Identifiant |
| nomEtu | Nom de l'étudiant | Alphabétique | 30 | |
| Entité : Formation | ||||
| codeForm | Code de la formation | Alphanumérique | 9 | Identifiant |
| prixForm | Prix de la formation | Numérique | 5 | |
| Entité : Session | ||||
| codeSess | Code de la session | Alphanumérique | 9 | Identifiant |
| dateDebutSess | Date début | Date | - | |
Nettoyage des données (Contrôles à effectuer)
Exercice d'application
Testez-vousLa donnée MontantTotal (obtenue par Prix x Quantité) doit-elle figurer dans le dictionnaire des données ?
Voir la solution
C'est une donnée calculée. On ne stocke que les données brutes (élémentaires). Le total sera calculé à la volée par une requête.
Construction du graphe de dépendances fonctionnelles
Définition : Dépendance Fonctionnelle (DF)
Une relation entre deux données A (source) et B (cible) telle que : la connaissance de la valeur de A permet de déterminer de manière unique la valeur de B.
Liste des Dépendances (Exemple)
numCINEtu → prenomEtu
numCINEtu → dateNaissEtu
codeForm → titreForm
codeForm → prixForm
codeSess → nomSess
codeSess → dateDebutSess
codeSess → codeForm // Une session appartient à une formation
Contre-exemples (Attention !)
Faux car un étudiant peut s'inscrire à plusieurs formations. Le CIN ne permet pas de déterminer UN SEUL titre de formation.
Aucun rapport direct. De plus, le nom n'est pas un identifiant (homonymes possibles).
Graphe des DFs simplifié
TD Travaux Dirigés : Maîtriser les Dépendances Fonctionnelles
Entraînez-vous avec ces 6 cas d'études. Pour chaque cas, nous avons listé tous les champs du dictionnaire de données.
Votre mission : Tracez le Graphe des Dépendances Fonctionnelles (DF). Reliez chaque déterminant (Source) à ses dépendants (Cible).
Niveau 1 : Gestion Employés (2 Entités)
Débutant
Dictionnaire : Matricule, Nom, Prénom, DateEmbauche, Salaire, CodeDept, NomDept, Etage, Budget.
Règle : Un employé travaille dans un département précis. Un département a ses propres infos uniques.
Voir la solution (Graphe)
graph LR
%% Source Departement
CodeDept --> NomDept
CodeDept --> Etage
CodeDept --> Budget
%% Source Employé
Matricule --> Nom
Matricule --> Prénom
Matricule --> DateEmbauche
Matricule --> Salaire
%% Relation (DFExterne)
Matricule -- Travaille --> CodeDept
style Matricule fill:#d1fae5,stroke:#059669
style CodeDept fill:#d1fae5,stroke:#059669
Matricule détermine tout (ses infos + son département).
Niveau 2 : Client & Commande (3 Entités)
Facile
Dictionnaire : idClient, Nom, Adresse, Ville, Email, Tel, numCmd, DateCmd, Statut, Total, numFact, DateFact, Echeance, ModePaiement.
Règles : Facture concerne une Commande. Commande concerne un Client.
Voir la solution (Graphe)
graph LR
%% FACTURE
numFact --> DateFact & Echeance & ModePaiement
numFact -- DF Ext --> numCmd
%% COMMANDE
numCmd --> DateCmd & Statut & Total
numCmd -- DF Ext --> idClient
%% CLIENT
idClient --> Nom & Adresse & Ville & Email & Tel
style numFact fill:#dbeafe,stroke:#2563eb
style numCmd fill:#dbeafe,stroke:#2563eb
style idClient fill:#dbeafe,stroke:#2563eb
Une chaîne transitive parfaite.
Niveau 3 : Ligue de Football (4 Entités)
Moyen
Dictionnaire : numJ, Nom, Prénom, Poste, codeEq, NomEq, Ville, Stade, idDiv, NomDiv, Niveau, refAg, NomAg, Tel, Commission.
Règles : Joueur -> Equipe -> Division. Joueur -> Agent.
Voir la solution (Graphe)
graph TD
%% JOUEUR
numJ --> Nom & Prénom & Poste
numJ -- Joue --> codeEq
numJ -- Représenté --> refAg
%% EQUIPE
codeEq --> NomEq & Ville & Stade
codeEq -- Dans --> idDiv
%% DIVISION & AGENT
idDiv --> NomDiv & Niveau
refAg --> NomAg & Tel & Commission
style numJ fill:#e0e7ff,stroke:#4f46e5
style codeEq fill:#e0e7ff,stroke:#4f46e5
style refAg fill:#c7d2fe,stroke:#4f46e5
style idDiv fill:#c7d2fe,stroke:#4f46e5
Niveau 4 : Bibliothèque (5 Entités)
Avancé
Dictionnaire : ISBN, Titre, Année, NbPages, idAut, Nom, Prénom, Nat, idEdit, RaisonSoc, Adr, CodeRay, Thème, Capacité, NumAllée, Lettre, Eclairage.
Règles : Livre dépend de Auteur, Editeur, Rayon. Rayon dépend de Allée.
Voir la solution (Graphe)
graph LR
%% LIVRE
ISBN --> Titre & Année & NbPages
ISBN --> idAut & idEdit & CodeRay
%% DEPENDANCES
idAut --> Nom & Prénom & Nationalité
idEdit --> RaisonSoc & Adresse & Contact
CodeRay --> Thème & Capacité
CodeRay --> NumAllée
NumAllée --> Lettre & Eclairage
style ISBN fill:#f3e8ff,stroke:#9333ea
style idAut fill:#f3e8ff,stroke:#9333ea
style idEdit fill:#f3e8ff,stroke:#9333ea
style CodeRay fill:#f3e8ff,stroke:#9333ea
style NumAllée fill:#f3e8ff,stroke:#9333ea
Niveau 5 : Location de Voiture (6 Entités)
ExpertSituation : Le Contrat (NumContrat, Dates, Caution) centralise tout : Client (Permis...), Voiture (Immat...), Assurance (Code...), Agent (Matricule...).
Voir la solution (Graphe)
graph TD
NumContrat((NumContrat))
NumContrat --> DateDeb & DateFin & Caution
%% ETOILE
NumContrat --> NumPermis --> Nom & Prénom & Ville
NumContrat --> CodeAssur --> NomCie & Franchise
NumContrat --> MatcAg --> NomAg & Qualif
%% BRANCHE VOITURE
NumContrat --> Immat --> Marque & Modèle & Km
Immat --> CodeAg --> NomAg & VilleAg
style NumContrat fill:#fbcfe8,stroke:#db2777,stroke-width:3px
Boss Final : Gestion Complète Hôtel
Identifiez toutes les DFs, y compris celles de la table jointure "Consommer". Données : Clients, Chambres, Types, Résas, Factures, Prestations... (voir suite MCD).
Défi : Trouvez toutes les Dépendances Fonctionnelles (y compris les composées).
Révéler la Solution (Graphe)
graph LR
%% BRANCHE PRINCIPALE
NumFact --> DateEdit & Total
NumFact --> NumResa
NumResa --> DateArr & DateDep & NbPers
NumResa --> NumCli --> Nom & Email
NumResa --> NumCh --> Etage & Vue
NumCh --> CodeType --> Prix & NbLits
%% BRANCHE CONSO (COMPOSÉE)
C[NumResa + CodePrest] --> Quantité & DateConso
CodePrest --> Libellé & PrixUnit
C -.-> CodePrest
style C fill:#be185d,stroke:#fff,stroke-dasharray: 5 5
Notez la clé composée [NumResa + CodePrest] qui détermine la Quantité consommée.
Règles de passage au Modèle Conceptuel (MCD)
Méthode MERISE
Méthode française (années 70) séparant Données et Traitements. Elle propose 3 niveaux :
Les 5 Règles de Passage (Graphe DF ➜ MCD)
Source de DF = Entité + Identifiant
Toute donnée source devient identifiant d'une entité. Les données cibles deviennent des propriétés.
=> Entité ETUDIANT(numCIN, nom, prenom)
DF entre identifiants = Association simple
Si A -> B simple, alors Association non porteuse (1,1 -> 0,n).
=> Association "Concerne"
DF complexe (concaténée)
Si (A+B) -> C, alors C est une propriété portée par l'association entre A et B.
=> Assoc "EstInscrit" (avec typeCours)
Relations N,N
Associations issues de dépendances non fonctionnelles (Plusieurs à Plusieurs).
=> Plusieurs formations, plusieurs spécialités.
Exercice d'application
Testez-vousSi on a la Dépendance Fonctionnelle : (CodeClient, RefProduit) ➔ DateAchat.
Cela veut dire que DateAchat est une propriété de :
- L'entité Client
- L'entité Produit
- L'association entre Client et Produit
Voir la solution
La clé est concaténée (Client + Produit). C'est donc une Propriété portée par l'association (Ex: Table Achat).
Construction du Modèle Conceptuel de Données (MCD)
Comprendre les Cardinalités
| Card. | Signification | Exemple Contextuel |
|---|---|---|
| 0,1 | Au plus un (optionnel) | Un employé peut avoir 0 ou 1 bureau. |
| 1,1 | Un et un seul (obligatoire) | Une Session concerne exactement 1 Formation. |
| 0,n | Plusieurs (optionnel) | Une Formation peut avoir 0 (nouvelle) ou plusieurs Sessions. |
| 1,n | Au moins un (obligatoire) | Une facture a au moins 1 ligne de commande. |
Le MCD correspondant au projet du «Centre de formation»
TD Travaux Dirigés : Construction des MCD (Notation Merise)
Reprenez les 6 cas d'études. Cette fois, les entités sont détaillées. À partir du cahier des charges, dessinez le MCD complet avec tous les attributs et les cardinalités.
Niveau 1 : Gestion Employés
Simple
Cahier des charges :
On souhaite gérer les salariés d'une entreprise.
- Un Employé est défini par son Matricule, son Nom, son Prénom, sa Date d'embauche et son Salaire.
- Un Département est défini par un CodeDept, un Nom (Marketing, IT...), un Étage et un Budget annuel.
- Règle : Un employé travaille dans un seul département, mais un département compte plusieurs employés.
Voir le MCD Merise
flowchart LR
E1["EMPLOYE
Matricule
Nom
Prénom
DateEmbauche
Salaire"]
A1(("Travailler"))
E2["DEPARTEMENT
CodeDept
NomDept
Etage
Budget"]
E1 ---|"1,1"| A1
A1 ---|"0,n"| E2
style E1 fill:#fff,stroke:#333,stroke-width:2px
style E2 fill:#fff,stroke:#333,stroke-width:2px
style A1 fill:#e0e7ff,stroke:#333,stroke-width:1px
Niveau 2 : Client & Commande
Chaîne
Cahier des charges :
Une application e-commerce gère ses ventes.
- Client : idClient, Nom, Adresse, Ville, Email, Téléphone.
- Commande : numCmd, DateCmd, Statut (En cours, Livrée), MontantTotal.
- Facture : numFact, DateFact, DateEcheance, ModePaiement.
Règles : Un client passe des commandes. Une commande génère une facture unique.
Voir le MCD Merise
flowchart LR
C["CLIENT
idClient
Nom
Adresse
Email
Tel"]
A1(("Passer"))
CMD["COMMANDE
numCmd
DateCmd
Statut
Total"]
A2(("Generer"))
F["FACTURE
numFact
DateFact
Echeance
MoyenPaiement"]
C ---|"0,n"| A1
A1 ---|"1,1"| CMD
CMD ---|"0,1"| A2
A2 ---|"1,1"| F
style C fill:#fff,stroke:#333,stroke-width:2px
style CMD fill:#fff,stroke:#333,stroke-width:2px
style F fill:#fff,stroke:#333,stroke-width:2px
style A1 fill:#e0e7ff,stroke:#333
style A2 fill:#e0e7ff,stroke:#333
Niveau 3 : Ligue de Football
Arborescence
Cahier des charges :
Gestion d'un championnat.
- Joueur : numJ, Nom, Prénom, Poste, DateNaissance, Nationalité.
- Equipe : codeEq, NomEq, Ville, Stade, Couleurs.
- Division : idDiv, NomDiv (Ligue 1, Ligue 2), Niveau.
- Agent : refAg, NomAg, TelPro, PourcentageCom.
Règles : Un joueur a un seul agent et joue dans une équipe. Une équipe est dans une division.
Voir le MCD Merise
flowchart TD
J["JOUEUR
numJ
Nom
Prénom
Poste"]
A1(("Jouer"))
E["EQUIPE
codeEq
NomEq
Ville
Stade"]
A2(("Appartenir"))
D["DIVISION
idDiv
NomDiv
Niveau"]
A3(("Avoir Agent"))
Ag["AGENT
refAg
NomAg
Tel
Commission"]
J ---|"1,1"| A1
A1 ---|"0,n"| E
E ---|"1,1"| A2
A2 ---|"0,n"| D
J ---|"1,1"| A3
A3 ---|"0,n"| Ag
style J fill:#fff,stroke:#333,stroke-width:2px
style E fill:#fff,stroke:#333,stroke-width:2px
style D fill:#fff,stroke:#333,stroke-width:2px
style Ag fill:#fff,stroke:#333,stroke-width:2px
style A1 fill:#e0e7ff,stroke:#333
style A2 fill:#e0e7ff,stroke:#333
style A3 fill:#e0e7ff,stroke:#333
Niveau 4 : Bibliothèque
Relations Multiples
Cahier des charges détaillé :
Modélisez le fonds documentaire d'une médiathèque :
1. Livre : Identifié par ISBN. Titre, AnnéeParution, Résumé, NbPages.
2. Auteur : idAut, Nom, Prénom, DateNaiss, Nationalité. Un livre a un auteur principal.
3. Éditeur : idEdit, RaisonSociale, AdresseSiège, Tel, EmailContact.
4. Rayon : CodeRay, Thème (ex: SF, Histoire), CapacitéMax.
5. Allée : NumAllée, Lettre (A, B...), Eclairage (LED/Néon).
Localisation : Un livre est dans un rayon. Un rayon se trouve dans une allée précise.
Voir le MCD Merise
flowchart LR
L["LIVRE
ISBN
Titre
Année
NbPages"]
Aut["AUTEUR
idAut
Nom
Prénom
Nationalité"]
Edit["EDITEUR
idEdit
RaisonSoc
Adresse
Tel"]
Ray["RAYON
CodeRay
Thème
Capacité"]
All["ALLEE
NumAllée
Lettre
Eclairage"]
A1(("Ecrire"))
A2(("Publier"))
A3(("Ranger"))
A4(("Situer"))
L ---|"1,1"| A1 ---|"0,n"| Aut
L ---|"1,1"| A2 ---|"0,n"| Edit
L ---|"1,1"| A3 ---|"0,n"| Ray
Ray ---|"1,1"| A4 ---|"0,n"| All
style L fill:#fff,stroke:#333,stroke-width:2px
style Aut fill:#fff,stroke:#333,stroke-width:2px
style Edit fill:#fff,stroke:#333,stroke-width:2px
style Ray fill:#fff,stroke:#333,stroke-width:2px
style All fill:#fff,stroke:#333,stroke-width:2px
style A1 fill:#e0e7ff,stroke:#333
style A2 fill:#e0e7ff,stroke:#333
style A3 fill:#e0e7ff,stroke:#333
style A4 fill:#e0e7ff,stroke:#333
Niveau 5 : Location de Voiture
Central
Cahier des charges détaillé :
Système de gestion de location type "RentCar" :
- Voiture : Immat, Marque, Modèle, Couleur, Kilométrage, Année.
- Agence : CodeAg, Nom, Adresse, Ville, ChefAgence.
- Client : NumPermis, Nom, Prénom, Rue, Ville, Tel.
- Assurance : CodeAssur, NomCompagnie, TypeCouverture, Franchise.
- Agent : MatriculeAg, Nom, Qualification (Junior/Senior).
- Contrat : NumContrat, DateDébut, DateFin, CautionVersée.
Relations : Une voiture appartient à une agence. Le contrat est au centre : signé par un client, pour une voiture, géré par un agent, sous une assurance.
Voir le MCD Merise
flowchart TD
Contrat["CONTRAT
NumContrat
DateDeb
DateFin
Caution"]
Client["CLIENT
Permis
Nom
Prénom
Ville"]
Voit["VOITURE
Immat
Marque
Modèle
Km"]
Assur["ASSURANCE
Code
NomCie
Franchise"]
Agent["AGENT
Matricule
Nom
Qualif"]
Agence["AGENCE
CodeAg
NomAg
Ville"]
A1(("Signer"))
A2(("Concerner"))
A3(("Couvrir"))
A4(("Gerer"))
A5(("Appartenir"))
Contrat ---|"1,1"| A1 ---|"0,n"| Client
Contrat ---|"1,1"| A2 ---|"0,n"| Voit
Contrat ---|"1,1"| A3 ---|"0,n"| Assur
Contrat ---|"1,1"| A4 ---|"0,n"| Agent
Voit ---|"1,1"| A5 ---|"0,n"| Agence
style Contrat fill:#fff,stroke:#333,stroke-width:2px
style Client fill:#fff,stroke:#333,stroke-width:2px
style Voit fill:#fff,stroke:#333,stroke-width:2px
style Assur fill:#fff,stroke:#333,stroke-width:2px
style Agent fill:#fff,stroke:#333,stroke-width:2px
style Agence fill:#fff,stroke:#333,stroke-width:2px
style A1 fill:#e0e7ff,stroke:#333
style A2 fill:#e0e7ff,stroke:#333
style A3 fill:#e0e7ff,stroke:#333
style A4 fill:#e0e7ff,stroke:#333
style A5 fill:#e0e7ff,stroke:#333
Boss Final : Hôtel & Consommations
Complexe
Cahier des charges complet :
- Client : NumCli, Nom, Prénom, Email, Tel, Nationalité.
- Chambre : NumCh, Etage, Vue (Mer/Jardin), TelInterne, Statut (Propre/Sale).
- TypeChambre : CodeType, Libellé (Suite, Double...), PrixBase, NbLits.
- Réservation : NumResa, DateArr, DateDep, NbPersonnes, EtatArrhes.
- Prestation : CodePrest, Libellé (Petit-Dej, Spa, MiniBar), PrixUnit, TauxTVA.
- Facture : NumFact, DateEdit, MontantHT, MontantTTC, ModePaiement.
Interactions : Client fait Réservation. Réservation concerne une Chambre (d'un Type). Facture solde Réservation. Réservation contient plusieurs Prestations consommées (avec Quantité et DateConso).
Voir le MCD Merise
flowchart TD
CLI["CLIENT
NumCli
Nom
Email"]
RESA["RESERVATION
NumResa
DateArr
DateDep"]
CHAM["CHAMBRE
NumCh
Etage
Vue"]
TYPE["TYPE
CodeType
PrixBase
NbLits"]
FACT["FACTURE
NumFact
DateEdit
MontantTTC"]
PREST["PRESTATION
CodePrest
Libellé
PrixUnit"]
A1(("Effectuer"))
A2(("Concerner"))
A3(("Avoir Type"))
A4(("Cloturer"))
A5(("Consommer
Quantité
DateConso"))
CLI ---|"0,n"| A1 ---|"1,1"| RESA
RESA ---|"1,1"| A2 ---|"0,n"| CHAM
CHAM ---|"1,1"| A3 ---|"0,n"| TYPE
RESA ---|"0,1"| A4 ---|"1,1"| FACT
RESA ---|"0,n"| A5 ---|"0,n"| PREST
style CLI fill:#fff,stroke:#333,stroke-width:2px
style RESA fill:#fff,stroke:#333,stroke-width:2px
style CHAM fill:#fff,stroke:#333,stroke-width:2px
style TYPE fill:#fff,stroke:#333,stroke-width:2px
style FACT fill:#fff,stroke:#333,stroke-width:2px
style PREST fill:#fff,stroke:#333,stroke-width:2px
%% Associations
style A1 fill:#e0e7ff,stroke:#333
style A2 fill:#e0e7ff,stroke:#333
style A3 fill:#e0e7ff,stroke:#333
style A4 fill:#e0e7ff,stroke:#333
style A5 fill:#fbcfe8,stroke:#be185d,stroke-width:2px
Les Formes Normales (Normalisation)
Pourquoi normaliser ?
Le but est de découper vos données pour éviter les répétitions inutiles (redondances) et les erreurs de mise à jour.
Question fréquente : On normalise les Entités ou les Tables ?
Stricto sensu, la normalisation s'applique aux Relations (c'est-à-dire aux futures Tables de votre base de données).
Cependant, pour gagner du temps, on essaie d'appliquer ces règles dès la conception des Entités dans le MCD. Si vos entités sont bien conçues, vos tables seront naturellement normalisées !
Première Forme Normale (1FN) : Pas de listes !
La règle simple : Une case = Une seule information.
Interdit de mettre une liste de choses (ex: plusieurs téléphones, plusieurs prénoms) dans une seule colonne.
Table ETUDIANT
| Nom | Tél |
|---|---|
| Ali | 0611... , 0622... |
Deux numéros dans une case.
Solution
Soit on duplique la ligne (bof), soit mieux : on crée une autre table TELEPHONES liée à l'étudiant.
Deuxième Forme Normale (2FN) : Tout dépend de la clé entière
Condition : Avoir une clé primaire composée (plusieurs colonnes).
La règle simple : Chaque colonne doit dépendre de TOUTE la clé, pas juste d'un morceau de la clé.
Exemple : Table NOTE (Etudiant, Matière, Note, NomMatière)
- La Note dépend de l'Étudiant ET de la Matière. OK
- Le NomMatière dépend seulement de la Matière (pas de l'étudiant !). PAS OK
Troisième Forme Normale (3FN) : Pas de dépendance cachée
La règle simple : Une colonne ne doit pas dépendre d'une autre colonne normale. Elle doit dépendre DIRECTEMENT de la clé.
"La clé, toute la clé, rien que la clé."
Exemple : Table VOITURE (Immatriculation, Marque, Modèle, Couleur)
Supposons que le modèle détermine automatiquement la marque (ex: si modèle="Clio", marque="Renault").
Ici, Marque dépend de Modèle. C'est une dépendance transitive (A -> B -> C).
Risque : Si on se trompe en saisissant (Clio, Peugeot), on a une incohérence.
Solution : Créer une table MODELES (Modèle, Marque).
Forme Normale de Boyce-Codd (BCNF)
C'est une 3FN renforcée. Elle corrige un cas rare mais embêtant.
Simple : Si une colonne normale (non-clé) détermine une partie de la clé, il faut diviser la table.
L'Exemple du Professeur Remplaçant
Imaginons une table qui stocke quel professeur enseigne quelle matière à quel étudiant.
Table (Étudiant, Matière, Professeur)
- Clé = (Étudiant, Matière)
- MAIS : 1 Professeur enseigne 1 seule matière.
- Donc : Professeur ➔ Matière !
Un champ non-clé (Prof) détermine un bout de la clé (Matière).
Solution : Créer une table PROFESSEURS (Prof, Matière).
Quatrième Forme Normale (4FN)
Traite le problème des "options multiples indépendantes".
Simple : Si vous avez deux listes d'options indépendantes pour un même objet, ne les mettez pas dans la même table.
Exemple : Options de Voiture
Une voiture (Modèle X) peut avoir plusieurs Couleurs (Rouge, Bleu) et plusieurs Moteurs (Diesel, Essence).
Cela oblige à créer toutes les combinaisons : (X, Rouge, Diesel), (X, Rouge, Essence), (X, Bleu, Diesel)...
Si j'ajoute une couleur, je dois l'ajouter pour tous les moteurs ! C'est l'explosion.
1. Table COULEURS_DISPO (Modèle, Couleur)
2. Table MOTEURS_DISPO (Modèle, Moteur)
Les deux sont indépendantes.
Exercice d'application
Testez-vousSoit la table : COMMANDE (ID_Cmd, Date, ID_Client, Nom_Client).
Laquelle de ces règles n'est pas respectée ?
- 1FN (Atomicité)
- 3FN (Dépendance transitive)
Voir la solution
Le Nom_Client dépend de ID_Client, qui n'est pas la clé primaire (ID_Cmd). C'est une dépendance transitive. Il faut sortir le client dans une autre table.
Règles de passage du MCD au MLD
Règle 1 : Transformation des Entités
- L'entité devient une Table.
- L'identifiant devient la Clé Primaire.
- Les propriétés deviennent les Colonnes.
Règle 2 : Association (1,1) - (0,n)
Relation Père-Fils (Un élève a une classe, une classe a plusieurs élèves).
Ex: Session contient 'codeForm'.
Règle 3 : Association (0,n) - (0,n)
Relation N à N (Un élève suit plusieurs cours, un cours a plusieurs élèves).
Sa clé primaire est composée des clés des deux entités reliées.
Ex: Table 'Inscription' (CIN, codeSession).
Règle 4 : Cas Particuliers (1,1 - 1,1)
Relations rares (ex: Homme-Femme mariés).
Exercice d'application
Testez-vousComment traduit-on une association (0,n) - (1,1) en MLD ?
- On crée une table de jointure.
- On ajoute une clé étrangère dans la table du côté (0,n).
- On ajoute une clé étrangère dans la table du côté (1,1).
Voir la solution
Le "fils" (celui qui a le 1,1) doit pointer vers son "père". Donc on met l'ID du père comme clé étrangère dans la table du fils.
TD Travaux Dirigés : Passage au MLD (Avec Schéma Relationnel)
Pour chaque cas, visualisez la migration des clés (Flèches) et écrivez le schéma textuel.
Rappel : La flèche part de la Clé Étrangère et pointe vers la Clé Primaire qu'elle référence.
MCD: Employé (1,1) --- (0,n) Département
Voir la solution
graph LR
EMP[EMPLOYE
#CodeDept]
DEPT[DEPARTEMENT
CodeDept]
EMP -- Référence --> DEPT
style EMP fill:#fff,stroke:#333
style DEPT fill:#e0e7ff,stroke:#333
EMPLOYE (Matricule, Nom, Prénom, DateEmbauche, Salaire, #CodeDept)
MCD: Client -(0,n)-(1,1)-> Commande -(0,1)-(1,1)-> Facture
Voir la solution
graph LR
CMD[COMMANDE
#idClient] --Ref--> CLI[CLIENT]
FACT[FACTURE
#numCmd] --Ref--> CMD
style FACT fill:#fff
style CMD fill:#f0f9ff
style CLI fill:#e0f2fe
COMMANDE (numCmd, DateCmd, Statut, Total, #idClient)
FACTURE (numFact, DateFact, Echeance, ModePaiement, #numCmd)
Joueur dans Equipe, Equipe dans Division. Joueur a Agent.
Voir la solution
graph LR
J[JOUEUR]
EQ[EQUIPE]
DIV[DIVISION]
AG[AGENT]
J --#codeEq--> EQ
J --#refAg--> AG
EQ --#idDiv--> DIV
AGENT (refAg, NomAg, Tel, Commission)
EQUIPE (codeEq, NomEq, Ville, Stade, #idDiv)
JOUEUR (numJ, Nom, Prénom, Poste, #codeEq, #refAg)
4. Bibliothèque (Multi-FK)
Livre relié à Auteur, Editeur, Rayon.
Voir la solution
graph LR
L[LIVRE]
A[AUTEUR]
E[EDITEUR]
R[RAYON]
L --> A
L --> E
L --> R
R --> ALLEE
ALLEE (NumAllée, Lettre, Eclairage) | RAYON (CodeRay, Theme, Capacité, #NumAllée)
LIVRE (ISBN, Titre, Année, NbPages, #idAut, #idEdit, #CodeRay)
5. Location de Voiture (Central)
Le Contrat centralise Client, Voiture, Assurance et Agent.
Voir la solution
graph TD
CT[CONTRAT]
CT --> CLIENT
CT --> VOITURE
CT --> ASSURANCE
CT --> AGENT
VOITURE --> AGENCE
CLIENT (NumPermis, Nom, Prénom, Ville)
ASSURANCE (CodeAssur, NomCie, Franchise)
AGENT (MatriculeAg, Nom, Qualif)
VOITURE (Immat, Marque, Modèle, Km, #CodeAg)
CONTRAT (NumContrat, DateDeb, DateFin, Caution, #Immat, #NumPermis, #CodeAssur, #MatriculeAg)
Réservation, Facture et Consommations (Table de jointure).
Voir la solution complète
graph LR
RES[RESERVATION]
RES --> CLI[CLIENT]
RES --> CH[CHAMBRE]
fact[FACTURE] --> RES
CONS[CONSOMMER]
CONS --#NumResa--> RES
CONS --#CodePrest--> PREST[PRESTATION]
style CONS fill:#be185d,stroke:#fff,color:#fff
// Tables de référence
CLIENT (NumCli, Nom, Prénom, Email, Tel)
TYPE_CHAMBRE (CodeType, Libellé, PrixBase)
PRESTATION (CodePrest, Libellé, PrixUnit)
// Tables avec FK simples
CHAMBRE (NumCh, Etage, Vue, #CodeType)
RESERVATION (NumResa, Dates, #NumCli, #NumCh)
FACTURE (NumFact, Date, Montant, #NumResa)
// Association N,N -> Table Associative
CONSOMMER (#NumResa, #CodePrest, Quantité, DateConso)
Le MLD Final du Centre de Formation
Le MLD Final du Centre de Formation
