ALGEBRE RELATIONNELLE & LANGAGE SQL

Youness MADANI
Université Sultan Moulay Slimane
Faculté Polydisciplinaire
Licence Fondamentale(Tronc Commun) : Mathématiques - Informatique - Physique −→ Informatique

16 mars 2025

1 / 44
Plan

1. MERISE au service des systèmes d’information

2. Introduction à MERISE et son rôle dans le cours

3. Modélisation d’une base de données au niveau conceptuel

2 / 44
Système d’information

• Un système d’information (SI) désigne l’ensemble des moyens humains, matériels

et immatériels mis en place pour gérer l’information au sein d’une organisation,
comme une entreprise ou une institution.
• Son rôle principal est d’assurer une gestion efficace des données pour faciliter la prise
de décision et l’exécution des processus métiers.
• Il est important de ne pas confondre un système d’information et un système infor-
matique. Un système d’information peut exister sans support informatique : bien
avant l’ère du numérique, les organisations utilisaient déjà des méthodes manuelles
pour collecter, stocker et exploiter l’information (exemple : registres papier, dossiers
physiques).
• L’informatique et les technologies de l’information (TIC) ont cependant profondément
transformé la gestion des SI en automatisant et en optimisant ces processus.

3 / 44
Système d’information
Les Quatre Fonctions Essentielles du SI
Un système d’information remplit quatre fonctions fondamentales :
• La collecte de l’information : Il s’agit de l’enregistrement des données, qui peut se
faire par divers moyens (saisie manuelle, formulaires en ligne, capteurs automatiques,
etc.).
• La mémorisation de l’information : Les données collectées doivent être stockées de
manière organisée et sécurisée. Autrefois conservées sous format papier (dossiers, ar-
chives), elles sont aujourd’hui majoritairement enregistrées dans des fichiers numériques
ou des bases de données.
• Le traitement de l’information : Le SI permet d’exploiter les données via différentes
opérations : consultation, tri, mise à jour, calculs ou analyses pour générer de nouvelles
informations utiles.
• La diffusion de l’information : Une fois traitées, les données sont partagées avec les
utilisateurs concernés sous différentes formes (rapports, tableaux de bord, notifications,
etc.).
4 / 44
Système d’information

L’Évolution vers les Systèmes Informatisés

• Historiquement, la gestion de l’information reposait sur des processus manuels, impli-
quant des documents papier et des traitements réalisés par des employés.
• Avec l’essor des technologies numériques, ces systèmes ont progressivement évolué
vers des solutions informatisées.
• Aujourd’hui, les systèmes de gestion de bases de données relationnelles (SGBDR)
jouent un rôle clé dans les SI en offrant des outils puissants pour stocker, organiser et
manipuler l’information de manière efficace et sécurisée.
• Cette transition vers l’informatique permet une meilleure accessibilité aux données,
une automatisation des tâches et une fiabilité accrue, contribuant ainsi à une gestion
optimisée de l’information au sein des organisations.

5 / 44
La Conception des Systèmes d’Information

• La conception d’un système d’information consiste à définir la structure et le fonction-

nement du SI en fonction des besoins de l’organisation. C’est une phase essentielle
qui précède la mise en place du système et qui vise à assurer son efficacité, sa cohérence
et sa pérennité.
• La conception repose sur plusieurs principes :
• Identification des besoins : Comprendre les objectifs du SI et les informations qu’il doit
gérer.
• Organisation des données : Structurer l’information pour qu’elle soit facilement acces-
sible et exploitable.
• Optimisation des processus : S’assurer que les méthodes de collecte, de traitement et
de diffusion de l’information sont efficaces.

6 / 44
La Conception des Systèmes d’Information
• Pourquoi concevoir un SI ?
Une conception bien pensée permet :
• D’éviter les erreurs dès le départ (incohérences, pertes de données. . . ).
• D’optimiser la performance en organisant les données efficacement.
• D’adapter le système aux besoins des utilisateurs.
• De faciliter la maintenance du système.
• D’assurer l’évolutivité du système pour qu’il puisse s’adapter aux changements futurs.
• Exemple : Imaginons qu’une université souhaite mettre en place un système de gestion
des étudiants. Avant de créer une base de données, il faut concevoir le SI en définissant :

• Les informations à stocker (nom, prénom, date de naissance, filière. . . ).

• Les interactions entre les données (un étudiant peut suivre plusieurs cours, chaque
cours est dispensé par un professeur. . . ).
• Les règles de gestion (un étudiant ne peut s’inscrire qu’à un certain nombre de cours
par semestre. . . ).
• C’est cette phase de réflexion et d’organisation qui constitue la conception du SI.
7 / 44
Modélisation des Systèmes d’Information

• La modélisation est une étape clé de la conception. Elle permet de représenter visuel-
lement et logiquement les données et les processus du système avant de le développer.
• Cette représentation facilite la compréhension et l’optimisation du SI.
• Les Types de Modélisation : Il existe plusieurs types de modélisation, en fonction
des aspects du SI que l’on souhaite représenter :
• Modélisation des données : Représente les données du système et leurs relations (ex. :
diagramme de base de données).
• Modélisation des traitements : Décrit comment les données sont manipulées et quelles
opérations sont effectuées (ex. : flux de travail).
• Modélisation des interactions : Met en évidence la manière dont les utilisateurs inter-
agissent avec le système.

8 / 44
Modélisation des Systèmes d’Information

• Exemple : Dans notre exemple de l’université, la modélisation des données peut être
représentée par un diagramme où :
• Une entité Étudiant est liée à une entité Cours via une relation S’inscrire.
• Chaque Cours est associé à un ou plusieurs Professeurs.
• Ce type de modélisation permet de clarifier la structure du SI avant de passer à la phase
de développement.
• Importance de la Modélisation avant la Mise en Place du SI
• Facilite la communication entre les développeurs, les analystes et les utilisateurs.
• Permet d’anticiper les problèmes et d’améliorer la conception avant l’implémentation.
• Assure une meilleure organisation des données pour une utilisation efficace.
• Dans ce cours, nous allons apprendre à modéliser une base de données de manière
rigoureuse avant de la mettre en place sous SQL.
• Pour cela, nous utiliserons la méthode MERISE, qui fournit une structure logique et
cohérente pour la conception des bases de données relationnelles.

9 / 44
Introduction à MERISE et son rôle dans le cours

• MERISE(Méthode d’étude et de réalisation informatique pour les systèmes d’entre-

prise) est une méthode française née dans les années 70, développée initialement par
Hubert Tardieu.
• Elle a ensuite été mise en avant dans les années 80, à la demande du ministère de
l’Industrie, qui recherchait une méthode de conception des systèmes d’information.
• MERISE est ainsi une méthode d’analyse et de conception des systèmes d’information
reposant sur le principe de distinction entre les données et les traitements.
• Elle permet de modéliser les données et les traitements d’un système afin de structurer
sa mise en place et son évolution.
• La méthode MERISE repose sur une séparation claire des préoccupations en trois
niveaux distincts : conceptuel, logique et physique. Cette séparation permet de
structurer la conception d’un système d’information en se concentrant sur des aspects
spécifiques à chaque niveau.

10 / 44
Introduction à MERISE et son rôle dans le cours
• Niveau conceptuel :
• Identification des entités, des associations et des règles de gestion sans considérer les
contraintes techniques.
• Décrire ce que le système doit faire sans se préoccuper des aspects techniques.
• Focus : Les besoins métier, les règles de gestion et les interactions entre les acteurs.
• Niveau logique :
• Transformation du modèle conceptuel en un modèle logique adapté à une base de données
relationnelle.
• Décrire comment le système fonctionne en termes de structures de données et de traite-
ments.
• Focus : La modélisation des données (tables, relations)
• Exemple : Convertir les entités et associations du MCD en relations.
• Niveau physique :
• Implémentation finale dans un SGBD (Système de Gestion de Base de Données).
• Décrire comment le système est implémenté techniquement.
• Exemple : Implémenter les tables dans un SGBDRs comme MySQL ou PostgreSQL.
• Dans ce cours, nous nous concentrerons uniquement sur certains schémas utilisés pour
concevoir une base de données relationnelle, puis la mettre en œuvre sur un SGBDR.11 / 44
Introduction à MERISE et son rôle dans le cours

Présentation des principaux modèles utilisés en MERISE

• Modèle Conceptuel de Données (MCD)
• Objectif : Représenter les entités, leurs proprietés (attributs) et leurs relations de manière
structurée avec une représentation graphique.
• Éléments clés :
• Entités : Objets ou concepts du monde réel (ex. : Étudiant, Cours).
• Attributs : Propriétés des entités (ex. : Nom, Prénom, Âge).
• Associations : Relations entre les entités (ex. : Inscription entre Étudiant et Cours).
• Cardinalités : Nombre d’occurrences d’une entité par rapport à une autre (ex. : 1,N).
• Exemple :
• Entité : Étudiant (ID, Nom, Prénom).
• Association : Inscription (Étudiant ←→ Cours).

12 / 44
Introduction à MERISE et son rôle dans le cours

• Modèle Logique de Données (MLD)

• Objectif : Transformer le MCD en un modèle utilisable par un SGBDR.
• Éléments clés :
• Relations : Représentation des entités, mais aussi des associations, dans certains cas.
• attributs : Ces attributs sont des données élémentaires issues des propriétés des différentes
entités, mais aussi des identifiants et des données portées par certaines associations..
• Clés primaires et étrangères : Représentation des associations.
• Exemple :
• Relation : Étudiant (ID, Nom, Prénom).
• Relation : Cours (ID, titre, Professeur ID#).

13 / 44
Introduction à MERISE et son rôle dans le cours

• Modèle Physique de Données (MPD)

• Objectif : Implémenter le MLD dans un SGBDR concret.
• Éléments clés :
• Scripts SQL : Pour créer les tables, les index et les contraintes.
• Optimisation : Partitionnement, indexation, réplication.
• Exemple :

1 CREATE TABLE Etudiant (

2 ID INT PRIMARY KEY ,
3 Nom VARCHAR (50) ,
4 Pr é nom VARCHAR (50)
5 );

14 / 44
Introduction à MERISE et son rôle dans le cours
• Pourquoi utiliser MERISE pour concevoir une base de données ?
• Analyser et structurer les besoins des utilisateurs.
• Standardiser la conception des bases de données.
• Assurer la cohérence et la normalisation des données.
• Faciliter la communication entre les développeurs et les utilisateurs.
• Exemple : Prenons l’exemple d’une université souhaitant gérer les inscriptions des
étudiants, les enseignements et les notes. En appliquant MERISE, nous allons :
• Identifier les entités principales (ex. : Étudiant, Enseignant, Cours, Notes).
• Déterminer les relations entre ces entités (ex. : Un étudiant s’inscrit à plusieurs cours,
un enseignant dispense plusieurs cours).
• Créer un modèle conceptuel de données (MCD) représentant ces informations sous
forme de diagramme.
• Passer au niveau logique et physique pour implémenter la base de données sous SQL.
• Dans les prochaines sections, nous explorerons en détail le modèle conceptuel de
données (MCD) et les règles de transformation vers le modèle logique (MLD) puis
physique (MPD).
15 / 44
Modélisation d’une base de données au niveau conceptuel
• L’objectif principal de la modélisation conceptuelle est de créer une vision globale et
cohérente du système, en identifiant les éléments clés et leurs interactions.
• Cette étape sert de base pour les niveaux suivants (logique et physique) et facilite
la communication entre les différents acteurs du projet, qu’ils soient experts métier,
analystes ou développeurs.
• Cela consiste à élaborer le modèle conceptuel des données (MCD), une représentation
graphique et structurée des informations stockées dans un système d’information. Le
MCD repose sur deux notions fondamentales : les entités et les associations, d’où
sa seconde appellation : le schéma Entité/Association.
• L’élaboration du MCD passe par les étapes suivantes :
• L’établissement des règles de gestion (si elles ne sont pas fournies) : Comprendre les
contraintes et les processus métier à respecter.
• L’élaboration du dictionnaire des données.
• L’identification des dépendances fonctionnelles entre les données : Identifier les
relations entre les attributs pour garantir la cohérence des données.
• La création du MCD en suivant ces étapes : définition des entités→établissement
des associations→ puis ajout des cardinalités. 16 / 44
Les règles de gestion métier
• Avant de créer vos tables (ou même vos entités et associations dans un cadre
conceptuel), il est essentiel de recueillir les besoins des futurs utilisateurs de l’applica-
tion. Ces besoins vous permettront ensuite de définir les règles de gestion des données
à conserver.
• Une règle de gestion est une contrainte ou une directive qui régit le fonctionnement
d’un système d’information (SI) en fonction des besoins de l’organisation. Elle définit
ce qui est autorisé, interdit ou obligatoire dans un processus métier.
• Pourquoi sont-elles essentielles pour le MCD ? ?
• Garantir la cohérence des données dès la conception.
• Respect des contraintes métiers – Elles garantissent que les données respectent les
règles propres à l’organisation.
• Déterminer les cardinalités des associations.
• Prévoir les contraintes d’intégrité à appliquer plus tard en base de données.
• Exemple : Un étudiant ne peut s’inscrire qu’à une seule formation par année académique.
Cette règle doit être respectée au niveau du système et intégrée dans la modélisation
des données.
17 / 44
Les règles de gestion métier

Exemples de Règles de Gestion dans un SI Universitaire et leur Impact sur le

MCD :
Nous allons prendre un exemple concret d’un système universitaire qui gère les étudiants,
enseignants, cours et inscriptions.
• Règles de Gestion sur les Étudiants :
• Règles métier :
• Chaque étudiant est identifié de manière unique par un numéro d’étudiant.
• Un étudiant doit obligatoirement avoir un nom, un prénom, une date de naissance et
une adresse e-mail.
• Un étudiant ne peut être inscrit qu’à une seule formation par année universitaire.
• Impact sur le MCD :
• Une entité Étudiant avec NumÉtu comme Identifiant.
• Une association Inscription entre Étudiant et Formation, avec une cardinalité (1,1) côté
Étudiant et (0,N) côté Formation.

18 / 44
Les règles de gestion métier
• Règles de Gestion sur les Enseignants
• Règles métier :
• Chaque enseignant est identifié par un numéro unique, et on doit mémoriser son nom,
prénom, adresse, téléphone et adresse e-mail .
• Un enseignant peut enseigner plusieurs matières.
• Une matière peut être enseignée par un ou plusieurs enseignants.
• Impact sur le MCD
• Une entité Enseignant avec IdEns comme Identifiant.
• Une association Enseigner entre Enseignant et Matière, avec une cardinalité (1,N) côté
Enseignant et (1,1) côté Matière.
• Règles de Gestion sur les Cours et Inscriptions
• Règles métier :
• Une formation est composée de plusieurs cours.
• Chaque cours appartient à une seule formation.
• Un étudiant doit être inscrit à une formation pour suivre un cours.
• Impact sur le MCD
• Une entité Cours liée à Formation.
• Une association Suivre entre Étudiant et Cours, et une association Contient entre Formation
et Cours.
19 / 44
Le dictionnaire des données

• Le dictionnaire des données est un document rassemblant l’ensemble des informa-

tions à conserver dans la base, et qui seront donc présentes dans le MCD.
• Le dictionnaire des données est un document essentiel dans la conception d’une base
de données. Il sert de référence pour décrire de manière détaillée les données qui
composent le système d’information.
• Il s’agit d’une étape intermédiaire qui peut s’avérer précieuse, notamment lorsqu’un
projet implique plusieurs collaborateurs travaillant sur une base de données de grande
envergure.
• Son objectif :
• Décrire chaque donnée du système.
• Assurer une bonne conception de la base de données.
• Servir de référence pour les développeurs et administrateurs.
• Éviter les incohérences et garantir la normalisation des données.
• Dans Le dictionnaire des données, pour chaque donnée nous indiquons :
20 / 44
• Code mnémonique : il s’agit d’un libellé désignant une donnée (par exemple ”Nom etud”
pour le nom d’un étudiant) .
• Désignation : il s’agit d’une mention décrivant ce à quoi la donnée correspond (Des-
cription claire de la donnée (ex : ”Nom de l’étudiant”).
• Type de donnée :
• A ou Alphabétique : lorsque la donnée est uniquement composée de caractères al-
phabétiques (de ’A’ à ’Z’ et de ’a’ à ’z’).
• N ou Numérique : lorsque la donnée est composée uniquement de nombres (entiers ou
réels).
• AN ou Alphanumérique : lorsque la donnée peut être composée à la fois de caractères
alphabétiques et numériques.
• Date : lorsque la donnée est une date (au format AAAA-MM-JJ).
• Booléen : Vrai ou Faux.
• Taille : Elle s’exprime en nombre de caractères ou de chiffres. Dans le cas d’une
date au format AAAA-JJ-MM, on compte également le nombre de caractères, soit
10 caractères. Pour ce qui est du type booléen, nul besoin de préciser la taille (ceci
dépend de l’implémentation du SGBDR).
• Remarques ou observations (complémentaires ) : Contraintes spécifiques (ex :
”Ne peut pas être vide”, ”Valeur > 0”).
21 / 44
Le dictionnaire des données

Code mnémonique Désignation Type Taille Remarque

id etudiant Identifiant numérique d’un étudiant N
nom etudiant Nom de l’étudiant A 30
prenom etudiant Prénom de l’étudiant A 30
date naissance et Date de naissance de l’étudiant Date 10 Au format AAAA-MM-JJ
email etudiant Adresse e-mail de l’étudiant AN 100
tel etudiant Numéro de téléphone de l’étudiant AN 15
adresse etudiant Adresse de l’étudiant AN 100
id enseignant Identifiant numérique d’un enseignant N
nom enseignant Nom de l’enseignant A 30
prenom enseignant Prénom de l’enseignant A 30
email enseignant Adresse e-mail de l’enseignant AN 100
tel enseignant Numéro de téléphone de l’enseignant AN 15
specialite enseignant Spécialité de l’enseignant A 50
id formation Identifiant numérique d’une formation N
nom formation Nom de la formation AN 50
niveau formation Niveau de la formation AN 20 Ex. Licence, Master, Doctorat

22 / 44
Le dictionnaire des données

Code mnémonique Désignation Type Taille Remarque

duree formation Durée de la formation en années N 1
id cours Identifiant numérique d’un cours N
titre cours Titre du cours AN 50
description cours Description du cours AN 1000
id ue Identifiant numérique d’une unité d’enseignement N
nom ue Nom de l’unité d’enseignement AN 50
semestre ue Semestre de l’unité d’enseignement N 1 1 ou 2
id inscription Identifiant numérique d’une inscription N
date inscription Date d’inscription Date 10 Au format AAAA-MM-JJ
statut inscription Statut de l’inscription AN 20 Ex. En cours, Validée, Annulée
id note Identifiant numérique d’une note N
note obtenue Note obtenue N 5 Note sur 20 avec 2 décimales
id eval Identifiant numérique d’une évaluation N
type eval Type d’évaluation AN 20 Ex. Examen, Contrôle, TP

23 / 44
Le dictionnaire des données

• Les données qui figurent dans le Modèle Conceptuel de Données (MCD) et, par exten-
sion, dans le dictionnaire des données, doivent respecter certaines règles pour garantir
leur qualité et leur utilité.
• Les données doivent être élémentaires :Les données stockées dans la base de
données doivent être élémentaires, c’est-à-dire qu’elles ne doivent pas être calculées
ou composées.
• Les données calculées ne doivent pas être stockées directement dans la base de données.
Elles doivent être obtenues par des calculs à partir de données élémentaires.
• Les données composées doivent être obtenues par concaténation de données élémentaires.
• Lorsqu’une donnée numérique n’est jamais utilisée pour des calculs, elle doit être
stockée comme une donnée de type (AN) plutôt que comme un nombre.
• Exemple : Un numéro de téléphone est une donnée numérique, mais il ne doit pas être
stocké comme un nombre (type N), car on ne fait jamais de calculs dessus.

24 / 44
Les dépendances fonctionnelles

• Définition 1 :
• Une dépendance fonctionnelle décrit une relation entre deux ensembles d’attributs dans
une table.
• Elle indique que la valeur d’un ensemble d’attributs (appelé déterminant) détermine de
manière unique la valeur d’un autre ensemble d’attributs (appelé dépendant).
• Notation : Si X détermine Y, on note X → Y
• Exemple : Dans une entité Étudiant, l’attribut ID détermine les attributs Nom et
Prénom. On note : ID → Nom, Prénom
• Définition 2 :
• Deux propriétés (ou données) P1 et P2 sont dites en dépendance fonctionnelle (DF) si,
et seulement si, une valeur de P1 permet de déterminer de manière unique une valeur
de P2.
• Cette dépendance est représentée comme ceci : P1 → P2
• On dit que P1 est la source de la DF et que P2 en est le but.

25 / 44
Les dépendances fonctionnelles

• Importance des dépendances fonctionnelles :

• Cohérence des données : Elles garantissent que les données restent exactes et non
redondantes.
• Normalisation : Elles sont essentielles pour la normalisation des bases de données, qui
vise à éliminer les redondances et les anomalies.
• Conception de la base de données : Elles aident à structurer les tables et à définir les
clés primaires et étrangères.
• Une dépendance fonctionnelle (DF) peut impliquer plusieurs attributs comme
source (déterminants) ou but (dépendants). Cela signifie qu’un ensemble d’attributs
peut déterminer un autre ensemble d’attributs.
• Notation : Si {A,B} détermine {C,D}, on note : {A,B}→ {C,D}

26 / 44
Les dépendances fonctionnelles

• Exemple 1 : Plusieurs attributs source

• DF : {P1,P2} → P3
• Explication : Les attributs P1 et P2 déterminent ensemble l’attribut P3.
• Cas pratique : Dans une table Commande, Client ID et Produit ID déterminent Quan-
tité.
• Exemple 2 : Plusieurs attributs but
• DF : P1 → {P2,P3}
• Explication : L’attribut P1 détermine les attributs P2 et P3.
• Cas pratique : Dans une table Étudiant, ID détermine Nom et Prénom.
• Exemple 3 : Plusieurs attributs source et but
• DF : {P1,P2} → {P3,P4,P5}
• Explication : Les attributs P1 et P2 déterminent ensemble les attributs P3, P4 et P5.
• Cas pratique : Dans une table Inscription, Étudiant ID et Cours ID déterminent Date Inscriptio
Statut et Note.

27 / 44
Les dépendances fonctionnelles

• Reprenons les données du dictionnaire des données du système universitaire et établissons

des dépendances fonctionnelles pertinentes.
• DF1 : id etudiant → nom etudiant, prenom etudiant, date naissance et
• Explication : à partir d’un numéro d’étudiant, on obtient son nom, son prénom et sa
date de naissance
• DF2 : id enseigant → nom enseigant, prenom enseignant
• Explication : L’identifiant de l’enseignant détermine le nom et le prénom de l’étudiant.
• DF3 : id etudiant, id cours → date inscription, statut inscription
• Explication : La combinaison de l’identifiant de l’étudiant et de l’identifiant du cours
détermine la date et le statut de l’inscription.
• DF4 : id etudiant, id cours → note obtenue
• Explication : La combinaison de l’identifiant de l’étudiant et de l’identifiant du cours
détermine la note obtenue.
28 / 44
Remarques sur les dépendances fonctionnelles (DF)

• Une DF doit être élémentaire :

• Une dépendance fonctionnelle est élémentaire si l’intégralité de la source (déterminant)
est nécessaire pour déterminer le but (dépendant). En d’autres termes, aucun sous-
ensemble de la source ne peut déterminer le but.
• Exemple : Si P1 → P3, alors P1,P2 → P3 n’est pas élémentaire, car P2 n’est pas
nécessaire pour déterminer P3.
• Une DF doit être directe :
• Une dépendance fonctionnelle est directe si elle n’est pas obtenue par transitivité. En
d’autres termes, il ne doit pas y avoir d’attribut intermédiaire qui permet de déduire la
DF.
• Exemple : si P1 → P2 et P2 → P3, alors P1 → P3 est une DF transitive (non directe).
• Conclusion : Les dépendances fonctionnelles entre les données sont parfois intuitives
et ne nécessitent pas toujours une modélisation. Cependant, leur formalisation peut
être bénéfique, notamment pour identifier clairement les futures entités du MCD ainsi
que leurs identifiants.
29 / 44
Le Modèle Conceptuel de Données (MCD)
Les Entités

• Le Modèle Conceptuel de Données (MCD) est une représentation abstraite de

la structure d’une base de données. Il permet de décrire les données d’un système
d’information de manière claire et indépendante de toute implémentation technique.
• Qu’est-ce qu’une entité ?
Une entité représente un objet du monde réel qui possède des propriétés (appelées
attributs) et qui doit être stocké dans la base de données.
• Chaque entité est unique et est décrite par un ensemble de propriétés encore appelées
attributs ou caractéristiques.
• Une des propriétés de l’entité est l’identifiant. Cette propriété doit posséder des oc-
currences uniques et doit être source des dépendances fonctionnelles avec toutes
les autres propriétés de l’entité.
• Bien souvent, on utilise une donnée de type entier qui s’incrémente pour chaque
occurrence, ou encore un code unique spécifique du contexte
30 / 44
Les Entités
• Dans le formalisme MERISE, une entité est représentée par un rectangle contenant
son nom. Ses attributs sont listés dans une boı̂te attachée à ce rectangle.
• Le formalisme d’une entité est le suivant :

• On schématise par exemple une entité ”Auteur” comme ceci :

• À partir de cette entité, on peut déduire la règle de gestion suivante : un auteur est
identifié par un identifiant unique (id) et possède comme caractéristiques un nom, un
prénom et une date de naissance.
31 / 44
Les Entités

• Une entité peut n’avoir aucune, une ou plusieurs occurrences. voici un exemple de
table d’occurrences de l’entité ”Auteur” :

id nom prenom date naissance

1 Youness Youness 1970-02-26
2 Ali Ali 1913-11-07
3 Hanane Hanane 1986-04-23
• Cette table contient trois occurrences (enregistrements) représentant l’entité Auteur.
• Les occurrences sont parfois appelées tuples. Par ailleurs, la table d’occurrences peut
être comparée à l’instance d’une relation (implantation relationnelle d’une entité ou
association) à un moment donné. Nous reviendrons sur cette notion de relation dans
la partie du MLD.

32 / 44
Les associations

• Une association est un lien sémantique entre une ou plusieurs entités. Elle permet
de traduire les règles de gestion qui ne peuvent pas être exprimées uniquement par la
définition des entités.
• Exemple : Une association peut relier l’entité Étudiant à l’entité Cours pour représenter
l’inscription d’un étudiant à un cours.
• Le formalisme d’une association est le suivant :

• Le nom d’une association est généralement un verbe qui décrit la nature du lien entre
les entités.
• Exemple :
Inscrit : Lien entre un étudiant et un cours.
Enseigne : Lien entre un enseignant et un cours.
33 / 44
Les associations

• Exemple :

• L’association  être né  reflète deux règles de gestion principales :

• Un auteur naı̂t dans un seul et unique pays.
• Un pays peut être le lieu de naissance d’aucun, d’un ou de plusieurs auteurs.
• Vous noterez que cette association est caractérisée par les annotations 1,1 et 0,N, qui
ont servi de base à la définition des règles de gestion mentionnées précédemment. Ces
annotations sont désignées sous le terme de cardinalités.
34 / 44
Les associations : Les cardinalités
• Définition : Une cardinalité définit le nombre minimum et maximum d’occurrences
d’une entité qui peuvent participer à une association.
• Les cardinalités permettent de décrire les règles de gestion et les contraintes d’intégrité
entre les entités.
• Les cardinalités sont souvent notées sous la forme (min, max), où :
• min : Nombre minimum d’occurrences.
• max : Nombre maximum d’occurrences.
Pourquoi les cardinalités sont-elles importantes ?
• Cohérence des données : Elles garantissent que les données respectent les règles métier.
• Contraintes d’intégrité : Elles empêchent les incohérences lors des opérations d’inser-
tion, de mise à jour ou de suppression.
• Clarté du modèle : Elles rendent le modèle de données plus compréhensible pour les
utilisateurs et les développeurs.
• Les cardinalités les plus couramment utilisées sont : 0,N ; 1,N ; 0,1 ; et 1,1. Cependant,
il est possible de rencontrer des règles de gestion exigeant des cardinalités avec des
valeurs spécifiques, bien que cela reste relativement rare.
35 / 44
Les associations : Les cardinalités
• Les cardinalités peuvent être classées en plusieurs types, en fonction des valeurs de
min et max. Voici les types les plus courants :
• Cardinalité (1,1) : Une occurrence exacte est requise.
• Exemple :
Entités : Cours, Enseignant.
Association : Enseigne.
Cardinalités :
• Cours : (1,1) (chaque cours doit être enseigné par un et un seul enseignant).
• Enseignant : (1,N) (un enseignant peut enseigner plusieurs cours).
• Cardinalité (0,1) : Zéro ou une occurrence est possible.
• Exemple :
Entités : Enseignant, Bureau.
Association : Attribution.
Cardinalités :
• Enseignant : (1,1) (chaque enseignant a un bureau).
• Bureau : (0,1) (un bureau peut être attribué à zéro ou un enseignant).
36 / 44
Les associations : Les cardinalités

• Cardinalité (1,N) : Au moins une occurrence et plusieurs occurrences sont possibles.

• Exemple :
Entités : Département, Enseignant.
Association : Appartient.
Cardinalités :
• Département : (1,N) (un département doit avoir au moins un enseignant et peut en avoir
plusieurs).
• Enseignant : (1,1) (chaque enseignant appartient à un seul département).
• Cardinalité (0,N) : Zéro ou plusieurs occurrences sont possibles.
• Exemple :
Entités : Étudiant, Cours.
Association : Inscrit. Cardinalités :
• Étudiant : (0,N) (un étudiant peut s’inscrire à zéro ou plusieurs cours).
• Cours : (0,N) (un cours peut avoir zéro ou plusieurs étudiants).

37 / 44
Les associations : Les cardinalités

Impact des cardinalités sur la conception de la base de données

• Normalisation :
• Les cardinalités aident à structurer les tables pour éviter les redondances et les anomalies.
Exemple : Une association 0,N-0,N entre Étudiant et Cours nécessite une table in-
termédiaire Inscription pour gérer les inscriptions.
• Contraintes d’intégrité :
• Les cardinalités permettent de définir des contraintes pour garantir la cohérence des
données.
Exemple : Un cours doit avoir au moins un enseignant (cardinalité (1,1)).
• Optimisation des requêtes :
• Les cardinalités aident à optimiser les requêtes en clarifiant les relations entre les tables.
Exemple : Savoir qu’un étudiant peut s’inscrire à plusieurs cours permet de prévoir des
jointures efficaces.

38 / 44
Les associations porteuses de données

• Une association porteuse de données est une association qui contient des attributs(données
portées par l’association). Ces attributs décrivent des informations spécifiques à la re-
lation entre les entités.
• Exemple : L’association Inscription entre Étudiant et Cours peut contenir des attri-
buts comme la date d’inscription ou le statut de l’inscription.
• Pourquoi les associations porteuses de données sont-elles importantes ?
• Décrire la relation : Elles permettent de stocker des informations spécifiques à la relation
entre les entités.
• Éviter les redondances : Elles évitent de dupliquer des informations dans les entités.
• Structurer les données : Elles aident à organiser les données de manière logique et
cohérente.

39 / 44
Les associations porteuses de données
• Exemple : Association Inscrit entre Étudiant et Cours
Entités : Étudiant, Cours.
Association : Inscrit.
Données portées par l’association :
• Date Inscription : La date à laquelle l’étudiant s’est inscrit au cours.
• Statut Inscription : Le statut de l’inscription (ex. : En cours, Validée, Annulée).

• L’association  Inscrit  peut donc être identifiée par la concaténation des propriétés

ID Cours et ID Etudiant. Ainsi, le couple ID Cours,ID Etudiant doit être unique pour
chaque occurrence de l’association. On peut également définir la dépendance fonc-
tionnelle suivante : ID Cours,ID Etudiant → Date inscription, Statut Inscription 40 / 44
Élaboration du MCD pour la Gestion des Étudiants
• Objectif du système
• Le système doit permettre la gestion des étudiants au sein d’un établissement universitaire.
Il devra couvrir :
• La gestion des étudiants (inscription, informations personnelles, formation suivie).
• La gestion des formations et des enseignants.
• L’organisation des cours et des enseignements.
• Règles de gestion métier :
• Un étudiant est identifié par un numéro unique. Il possède un nom, un prénom, une
date de naissance et une adresse e-mail.
• Une formation est identifiée par un code et possède un intitulé.
• Un étudiant peut s’inscrire à une seule formation.
• Un enseignant est identifié par un numéro unique et possède un nom, un prénom et une
spécialité.
• Un cours est identifié par un code et possède un intitulé.
• Un cours est dispensé par un enseignant.
• Une formation peut regrouper plusieurs cours.
• Un étudiant peut être inscrit à aucun ou à plusieurs cours, et un Cours peut être suivi
par plusieurs Étudiants. 41 / 44
Élaboration du MCD

• Identification des entités et associations :

• Entités :
Étudiant (num etu, nom, prénom, date naissance, email)
Formation (code formation, intitulé)
Enseignant (num ens, nom, prénom, spécialité)
Cours (code cours, intitulé)
• Associations :
Inscrit : Un étudiant suit une formation (Étudiant - Formation)
Enseigne : Un enseignant dispense un cours (Enseignant - Cours)
Contient : Une formation regroupe plusieurs cours (Formation - Cours) SUIVRE :
Un Étudiant peut suivre plusieurs Cours( Étudiant - Cours)

42 / 44
Élaboration du MCD

• Détermination des cardinalités :

• Un étudiant s’inscrit dans une et une seule formation. Une formation peut regrouper
plusieurs étudiants. (1,1 - 0,n)
• Un enseignant peut dispenser plusieurs cours, mais un cours est dispensé par un seul
enseignant. (0,n - 1,1)
• Une formation peut contenir plusieurs cours, et un cours peut être dans plusieurs
formations. (1,n - 1,n)
• Un Étudiant peut suivre 0 ou plusieurs Cours (0,N). Un Cours peut être suivi par 0
ou plusieurs Étudiants (0,N).

43 / 44
Élaboration du MCD
Pour que le MCD soit sémantiquement valide, toute entité doit être reliée à au moins une
association.

44 / 44