Cours Bases de Données Et Langage SQL - Partie 1

Cycle : BACHELOR
Niveau : 1
Support de cours
Bases de données et langage SQL
ANNEE ACADEMIQUE 2022-2023

PLANNING DE DEROULEMENT DU COURS
ENSEIGNANT
Nom (s) et prénom (s) : DIFFOUO TAZO Evariste

Grade ou Qualification : Ingénieur Informaticien et Doctorant
Téléphone : 697481969 / 67726823
Courriel : evaristetazo@gmail.com / ediffouo@parisformations.fr
Quotas horaire semestriel prévus : 32 heures

Volume horaire hebdomadaire prévu : 08 heures
Volume horaire mensuel prévu : 32 heures
Jour hebdomadaire de cours : Mardi et jeudi
Objectifs du cours
A la fin de ce cours l’étudiant doit être capable de :
1. Comprendre les concepts liés aux bases de données relationnelles et objets ;

2. Créer une base de données et des tables nécessaires à la gestion des données ;
3. Gérer les relations entre les différentes tables d'une Base de Données ;
4. Manipuler l’information à l’aide des opérations fondamentales ; des opérateurs ensemblistes et les opérateurs rela-
tionnels spécifiques de l’algèbre relationnelle ;
5. Sélectionner des données selon de nombreux critères à l’aide du langage SQL sous MYSQL ;
6. Manipulation des données (modification, suppression, calculs divers) à l’aide du langage SQL ;
7. Gérer les transactions et les utilisateurs de la base de données.
APPROCHE PEDAGOGIQUE
L’approche pédagogique est conçue pour impliquer l’étudiant dans la construction et l’utilisation des savoirs.
Ce planning transmis à l’étudiant lui permet de préparer chaque séance de cours. Des travaux à faire lui sont donnés
à la fin de chaque cours afin d’assimiler l’unité d’enseignement.
Diverses stratégies peuvent être utilisées dont : l’enseignement magistral interactif, les exercices pratiques, la mé-
thode des cas, l’apprentissage par problèmes, le réseau de concepts etc.
Seuls les étudiants ayant préparé leur séance de cours ont accès en salle de classe.
DEROULEMENT DES EXERCICES ET CAS PRATIQUES

Hormis les exercices d’application une liste d’exercices est intégrée à l’annexe du cours.
A chaque séance l’étudiant a droit aux exercices / TP à faire en salle, à la maison ou en équipe.
Le(s) contrôle(s) continu(s) et l’examen final comptent chacun pour 50% de la note finale
Le contrôle continu est constitué de :
- La présence et participation en salle ;
- L’évaluation en salle ;
- Travaux à faire à la maison ;
- Les travaux d’équipes.
NB : Les travaux dirigés ou pratiques doivent être remis au début du cours ou envoyés par courrier électro-
nique.
CONTENU DE L’ENSEIGNEMENT
CHAPITRE I : Rappel des généralités sur les bases de données
CHAPITRE II : Conception des bases de données : le modèle entité association et modèle relationnel
CHAPITRE III : Les fondamentaux de l’algèbre relationnelle : logique mathématiques, théorie des en-
sembles et opérations
CHAPITRE IV : Le langage SQL et administration des bases de données sous MYSQL
Planification des activités d’enseignement
Date Chapitre Objectifs du chapitre Contenus du chapitre Lectures et exercices Travail à faire
préparatoires au
cours
Séance1 CHAPITRE I : Rappel des générali- - Faire une analyse systémique de l’entre- 1- Quelques définitions ; T.D. 1
tés sur les bases de données prise ; 2- Les taches des sous-systèmes d’une
- Le rôle des systèmes d’information entreprise ;
- Comprendre les systèmes d’information
dans une entreprise. 3- Les principaux rôles d’un SI ;
et les fonctions de l’entreprise ; 4- Définition : Qu’est-ce qu’une base de
- Maitriser les concepts liés aux bases de données ?
5 Les enjeux et modèles des bases de
données
données
Séance 2 CHAPITRE I : Rappel des générali- - Comprendre Les systèmes de gestion 1- Différents Les Niveaux de description CHAPITRE I : Rappel T.D. 1
tés sur les bases de données (Suite des bases de données (SGBD) ; des données et quelques exemples de des généralités sur les
et fin) - Comprendre la méthode MERISE et ses SGBD ;
bases de données
- Démarche d'informatisation des composants 2- La méthode MERISE ;
systèmes d’information. - Comprendre le modèle Entité Association 3- modélisation systémique de l’entre-
CHAPITRE II : Conception des et les formes normales prise ;
bases de données : le modèle entité 4- Le modèle Entité Association
association et modèle relationnel
(Début)
- Le modèle entité association
Séance 3 CHAPITRE II : Conception des - Comprendre le modèle relationnel ; 1- Définition des éléments du modèle re- CHAPITRE II : Concep- T.D.2
bases de données : le modèle entité - Comprendre les contraintes d’intégrités. lationnel ; tion des bases de don-
association et modèle relationnel nées : le modèle entité
2- Passage du modèle entités-associa- association et modèle
- Le modèle relationnel
tions au modèle relationnel ; relationnel
3- Les contraintes d’intégrités.
Séance 4 CHAPITRE III : Les fondamentaux -Comprendre les concepts liés à l’Algèbre 1- Introduction à l’algèbre relationnelle ; CHAPITRE III : Les fon- T.D.3
de l’algèbre relationnelle : logique relationnelle ; 2- Définition et description ; damentaux de l’algèbre
3- La Logique propositionnelle ; relationnelle : logique
mathématiques, théorie des en- - Comprendre la logique propositionnelle ;
4- Les Tables de vérité fondamentales mathématiques, théorie
sembles et opérations 5- La théorie des ensembles des ensembles et opé-
- logique mathématiques ; rations
- théorie des ensembles.

Séance 5 CHAPITRE III : Les fondamentaux - Comprendre les opérations de l’Algèbre 1- Les opérateurs binaires ensemblistes CHAPITRE III : Les fon- T.D.4
relationnelle. damentaux de l’algèbre
de l’algèbre relationnelle : logique (Union, Intersection, différence) ;
relationnelle : logique
mathématiques, théorie des en- 2- Les opérateurs unaires (Sélection, pro-
mathématiques, théorie
sembles et opérations jection, restriction) ; des ensembles et opé-
- Les opérations de l’algèbre rela- 3- Les opérateurs n-aires (produit carté- rations
tionnelle ; sien, jointure, division) ;
Séance 6 CHAPITRE IV : Le langage SQL et - Mise en œuvre de MYSQL sous Windows 1- Installation de MYSQL sous Windows ; CHAPITRE IV : Le lan- T.D.5
administration des bases de don- - Mises en œuvre ORACLE sous Win- 2- Installation de ORACLE sous Win- gage SQL et adminis-
dows ; tration des bases de
nées sous MYSQL et sous Oracle dows ;
données sous MYSQL
- Mise en œuvre de MYSQL et - Comprendre les généralités du SQL. 3- Maitriser les bases de SQL.
et sous Oracle
ORACLE sous Windows ;
- Les bases du SQL.
Séance 7 CHAPITRE IV : Le langage SQL et - Maitriser le processus de définition de 1- Définition de la BD ; CHAPITRE IV : Le lan- T.D.5
données en SQL ; 2- Définition des tables ; gage SQL et adminis-
administration des bases de don-
- Maitriser le processus de manipulation de 3- Création des index ; tration des bases de
nées sous MYSQL et sous Oracle données en SQL. 4- Insertions et gestion d’enregistre- données sous MYSQL
- Définition des données ; ments ; et sous Oracle
- Manipulation des données. 5- Modifications de colonnes.
Séance 8 CHAPITRE IV : Le langage SQL et - Maitriser le processus d’évolution d’un 1- Renommer une table ; CHAPITRE IV : Le lan- T.P.1
schéma de données en SQL ; 2- Modifications structurelles ; gage SQL et adminis-
administration des bases de don-
- Maitriser le processus d’interrogation de 3- Modifications comportementales ; tration des bases de
nées sous MYSQL et sous Oracle données en SQL.
4- Extraction des données par les re- données sous MYSQL
- Maitriser le processus de contrôle de don-
- Évolution d’un schéma ; quêtes.
nées en SQL ;
- Interrogation des données. 5- Gestion des utilisateurs ;
6- Gestion des bases de données ;
7- Gestion des privilèges et des accès dis-
tants
8- Les vues.
COURS Bases de données et langage SQL
Table des matières

Chapitre 1 : ................................................................................................................................................ 3
Rappel des généralités sur les bases de données................................................................ 3
I. Analyse systémique de l’entreprise et les systèmes d’information ................................................3
1. Analyse systémique de l’entreprise ..............................................................................................3
2. Le système d’information ..............................................................................................................4
3. Les principaux rôles, ressources et fonctions d’un système d’information ..............................5
II. Les bases de données......................................................................................................................7
1. Définition : Qu’est-ce qu’une base de données ? .........................................................................7
2. Les enjeux des bases de données ...................................................................................................8
3. Les modèles ou les types de bases de données .............................................................................8
III. Les systèmes de gestion des bases de données (SGBD) ...............................................................9
1. Définition et objectifs des SGBD...................................................................................................9
2. Les Niveaux de description des données ................................................................................... 10
3. Quelques SGBD connus et utilisés ............................................................................................. 11
4. Définition et objectifs des SGBD................................................................................................ 11
Chapitre 2 : .............................................................................................................................................. 13
Conception des bases de données : le modèle entité association et modèle
relationnel ............................................................................................................................................. 13
Introduction ............................................................................................................................................. 13
I. Le modèle Entité Association ......................................................................................................... 13
1. La méthode MERISE ................................................................................................................. 13
2. Éléments constitutifs du modèle entités-associations ............................................................... 15
II. Normalisation des type-entités et type-associations ................................................................. 18
1. Première forme normale (1FN) ................................................................................................. 19
2. Deuxième forme normale (2FN) ................................................................................................ 19
3. Troisième forme normale (3FN) ................................................................................................ 20
III. Le modèle relationnel ................................................................................................................. 20
1. Présentation ................................................................................................................................. 20
2. Définition des éléments du modèle relationnel ......................................................................... 21
3. Exemple de base de données relationnelle ................................................................................ 22
4. Passage du modèle entités-associations au modèle relationnel ............................................... 22
IV. Les contraintes d’intégrités ........................................................................................................ 26
1. Contraintes de clé........................................................................................................................ 27
2. Contraintes de types de données ................................................................................................ 27
Proposé par : Ing. DIFFOUO TAZO Evariste 1

3. Contraintes d’intégrité référentielle .......................................................................................... 27

Chapitre 3 : .............................................................................................................................................. 29
Les fondamentaux de l’algèbre relationnelle : logique mathématiques, théorie
des ensembles et opérations ......................................................................................................... 29
Introduction ............................................................................................................................................. 29
I. Introduction à l’algèbre relationnelle ........................................................................................... 29
1. Définition et description ............................................................................................................. 29
2. La Logique propositionnelle ...................................................................................................... 30
3. La théorie des ensembles ............................................................................................................ 32
II. Les opérations de l’Algèbre relationnelle ................................................................................. 35
1. Les opérateurs binaires ensemblistes ........................................................................................ 35
2. Les opérateurs unaires ............................................................................................................... 36
3. Les opérateurs n-aires ................................................................................................................ 38
Chapitre 4 : .............................................................................................................................................. 42
Le langage SQL et administration des bases de données sous MYSQL ................... 42

Chapitre 1 :
Rappel des généralités sur les bases de données
I. Analyse systémique de l’entreprise et les systèmes d’information
1. Analyse systémique de l’entreprise
L’entreprise est considérée comme un ensemble d’éléments (des moyens humains, matériels, finan-
ciers et techniques) en interrelations. Le SI est en quelque sorte la mémoire de l’entreprise.
Selon l’approche systémique, l’entreprise peut se décomposer en trois sous-systèmes qui sont en
perpétuelle interaction :
 Le système d’opérations (système opérant ou modules opérationnels - MO) : C’est là où
s’effectuent les processus de production (actions pour la transformation de ressources en produits
ou services).
 Le système de décision ou de pilotage (modules pilotes - MP) : C’est ce système qui
exerce un contrôle, une régulation, décision pour assurer la cohérence entre objectifs et les
actions.
 Le système d’information (SI) : C’est l'interface entre les modules pilotes et les modules
opérationnels. Il enregistre, mémorise et traite les informations en provenance des MO, afin
d’informer les MP. Ces derniers vont utiliser ces informations pour prendre des décisions
d’action. Enfin, le SI renvoie ces décisions aux MO. Voir le schéma ci-dessous.
Chaque sous-système possède des activités et apporte des services à l’autre. Ci-dessous présentées
les activités de chaque sous-système :

2. Le système d’information
Le SI (système d’information) est une notion qui peut paraître abstraite. Pour cela, nous défi-
nirons séparément les deux termes qui composent le concept : « information » et « système ».
Puis, nous analyserons son mode de fonctionnement afin de comprendre réellement son utilité.
i. Information
La matière première manipulée en informatique est l’information. Celle-ci se présente sous

forme de données. L’information est un élément de connaissance humaine susceptible d’être
représentée à l’aide d’un système de codage afin d’être conservée, traitée ou communiquée. Pour
qu’une information soit fonctionnelle, il faut qu’elle soit utilisable et de qualité. Pour s’en assu-
rer, elle doit remplir trois conditions : la dimension temporelle, le contenu et la forme.
o La dimension temporelle : l’information doit être régulièrement mise à jour et surtout

être accessible et disponible à tout moment ;
o Le contenu : l’information doit être fiable, exacte et précise. Elle doit provenir de
sources sûres et vérifiées. Elle doit aussi être pertinente, adaptée et utile ;
o La forme : L’information doit être claire. Son organisation doit permettre sa bonne
compréhension. Cette condition a été facilitée grâce aux nouvelles technologies de
l’information en permettant de les présenter sous des formes et supports variés.
L’information au sein d’une entreprise possède de multiples sources. Elles peuvent

être internes comme les documents comptables et financiers, les documents sociaux, les notes
de services, les informations concernant les salariés ou bien externe comme les médias, les
factures, la publicité, les lettres. L’information est donc considérée comme un outil de
communication externe et interne, elle est très importante au sein des entreprises.

L’information permet d'assurer la coordination des différents services qui composent

l'entreprise. Elle contribue ainsi à la cohésion sociale. Les entreprises doivent donc mettre en
place des moyens qui vont lui permettre une bonne gestion de la masse d’informations qui
circule en son sein.
ii. Système
Un système est un ensemble d’éléments reliés entre eux en interactions dynamiques et

constituant un tout cohérent et fonctionnel compris dans un ensemble plus grand. Généralement un
système est constitué de composants organisés ensemble dans le but de faciliter le flux d’informa-
tion, de matière, d’énergie…
iii. Système d’information
En Management des systèmes d’information, un SI peut être de différents types :
- Manuel : c’est-à-dire qu’il repose sur l’utilisation du papier et du crayon ;

- Parallèle : ceci représente ’’ le bouche à oreille’’ ;
- Informatisé : le SI repose sur des technologies informatiques, des logiciels et du matériel.
Lorsque nous parlerons de système d’information dans ce cours, nous ferons

référence à ce dernier type de système : le système d’information informatisé.
Un système d’information peut être vu comme un ensemble organisé de ressources (Personnes,

données, procédures, matériels, logiciels) permettant d’acquérir, de traiter, de stocker et de
communiquer des informations (sous forme de données, textes, images, sons) dans et / ou entre des
organisations (systèmes).
Cette approche nous permet de constater qu’un système d’information peut être organiser à partir
des différentes ressources et il peut aussi être vu comme est un ensemble finalisé d‘information
tournant autour d’objectifs et est susceptible d’être défini à différents niveaux.
3. Les principaux rôles, ressources et fonctions d’un système d’information

3.1. Les principaux rôles et ressources d’un système d’information
Les objectifs d’un système d’information peuvent être classiquement présentés comme opé-
rationnels (délai, qualité, coût …) ou stratégiques (différenciation, stratégie de niche). Les objectifs
opérationnels du système sont définis par rapport aux tâches à accomplir. Ces rôles principaux sont
les suivants :

 L’automatisation des tâches : Le SI va permettre de détecter des dysfonctionnements in-

ternes ou des situations anormales. Pour que cet outil soit opérationnel, le SI doit être la «
mémoire collective » de l'organisation en gardant constamment une trace de chaque infor-
mation. On dit du SI qu’il est un outil de contrôle de l’évolution de l'organisation.
 L’aide à la décision : Le SI permet aux responsables d’obtenir les informations qui leur sont
nécessaires pour les prises de décision. Ils vont pouvoir étudier plus facilement les consé-
quences possibles de leurs décisions. Le SI va aussi permettre d'automatiser certaines déci-
sions. On dit du SI qu’il est un outil de contrôle de l’évolution de l'organisation.
 La communication et la diffusion de l’information : Le SI va fournir des informations sur

l’entreprise et sur toutes ses composantes. Elles seront les mêmes pour l’ensemble des ser-
vices et seront mises à jour régulièrement. Tout le monde est informé de la même manière
selon son accès aux informations. On dit du SI qu’il est un outil de coordination des diffé-
rentes activités de l'entreprise.
Un système d’information regroupe différentes ressources : les individus ou acteurs, des logiciels,
les matériels, les données, les pratiques de travail et les réseaux. Ci-dessous présentée la hiérarchie
de ces ressources.
3.2. Les fonctions d’un système d’information
Un système d’information est conçu par nature pour exécuter des fonctions élémentaires appliquées
aux données. Il s’agit de :
 Saisir des données : c’est-à-dire d’acquérir sous une forme adaptée des données qui sont
très hétérogènes (entrée en stock par un lecteur ou un clavier, localisation d’objets connectés
par les capteurs, données géographiques par extraction sur le web, transaction par les réseaux
financiers…) ;
 Stocker des données : c’est-à-dire de les conserver sous une forme exploitable et d’être
capable de les retrouver rapidement et sans erreurs (fichiers des utilisateurs, base de données
internes, organisation des données sur le cloud), mise à jour, historisation…) ;

 Traiter les données : c’est-à-dire de transformer les données primaires en résultats par
des opérations de transformation, de sélection, de calcul, d’agrégation, de croisement, de
mise en forme… sur des ordinateurs personnels, centraux ou externes ;
 Communiquer des données : c’est-à-dire de les transmettre à d’autres utilisateurs
(Hommes ou Machines) : Les messageries, documents, échanges de données EDI, sites in-
ternet…
Le schéma suivant résume ces 4 fonctions de base d'un système d'information. Remarquez que la
communication s'effectue autant avec les systèmes de pilotage qu'avec le système opérant.
II. Les bases de données

1. Définition : Qu’est-ce qu’une base de données ?
Plusieurs définitions existent pour signifier la notion de base de données. Une définition très géné-
rale pourrait être : Une base de données est un ensemble organisé d’informations avec un objectif
commun.
Plus précisément, on appelle base de données un ensemble structuré et organisé permettant
le stockage de grandes quantités d’informations afin d’en faciliter l’exploitation (ajout, mise à jour,
recherche de données). Bien entendu, dans le cadre de ce cours, nous nous intéressons aux bases de
données informatisées.
Une base de données informatisée est un ensemble structuré de données enregistrées sur
des supports accessibles par l’ordinateur, représentant des informations du monde réel et pouvant
être interrogées et mises à jour par une communauté d’utilisateurs. Le résultat de la conception d’une
base de données informatisée est une description des données. Par description on entend définir les
propriétés d’ensembles d’objets modélisés dans la base de données et non pas d’objets particuliers.
Les objets particuliers sont créés par des programmes d’applications ou des langages de manipula-
tion lors des insertions et des mises à jour des données.

Cette description des données est réalisée en utilisant un modèle de données. Ce dernier est un outil
formel utilisé pour comprendre l’organisation logique des données. La gestion et l’accès à une base
de données sont assurés par un ensemble de programmes qui constituent le Système de gestion de
base de données (SGBD).
2. Les enjeux des bases de données

Les bases de données ont pris une place importante en informatique, et particulièrement dans le
domaine de la gestion. L’étude des bases de données à conduit au développement de concepts, mé-
thodes et algorithmes spécifiques, notamment pour gérer les données en mémoire secondaire
(disques durs).
En effet, dès l’origine de la discipline, les informaticiens ont observé que la taille de la RAM ne
permettait pas de charger l’ensemble d’une base de données en mémoire. Cette hypothèse est tou-
jours vérifiée car le volume des données ne cesse de s’accroître sous la poussée des nouvelles tech-
nologies du WEB. Ainsi, les bases de données de demain devront être capables de gérer plusieurs
dizaines de téraoctets de données, géographiquement distribuées à l’échelle d’Internet, par plusieurs
dizaines de milliers d’utilisateurs dans un contexte d’exploitation changeant (on ne sait pas très bien
maîtriser ou prédire les débits de communication entre sites) voire sur des nœuds volatiles. Comme
il est peu probable de disposer d’une technologie de disque permettant de stocker sur un unique
disque une quantité très importante d’informations, les bases de données se sont orientées vers des
architectures distribuées ce qui permet, par exemple, d’exécuter potentiellement plusieurs instruc-
tions d’entrée/sortie en même temps sur des disques différents et donc de diviser le temps total
d’exécution par un ordre de grandeur.
3. Les modèles ou les types de bases de données

Ils sont aussi appelés bases de données décisionnelles (dataware houses)
III. Les systèmes de gestion des bases de données (SGBD)

1. Définition et objectifs des SGBD
La gestion et l’accès à une base de données sont assurés par un ensemble de programmes qui cons-
tituent le Système de gestion de base de données (SGBD). Un SGBD doit permettre l’ajout, la mo-
dification et la recherche de données. Un système de gestion de bases de données héberge généra-
lement plusieurs bases de données, qui sont destinées à des logiciels ou des thématiques différents.
Actuellement, la plupart des SGBD fonctionnent selon un mode client/serveur. Le serveur (la ma-
chine qui stocke les données) reçoit des requêtes de plusieurs clients et ceci de manière
concurrente. Le serveur analyse la requête, la traite et retourne le résultat au client. Le modèle
client/serveur est assez souvent implémenté au moyen de l’interface des sockets ; le réseau étant
Internet.
Des objectifs principaux ont été fixés aux SGBD dès l’origine de ceux-ci et ce, afin de ré-
soudre les problèmes causés par la démarche classique. Ces objectifs sont les suivants :
Indépendance physique : La façon dont les données sont définies doit être indépendante des
structures de stockage utilisées.
Indépendance logique : Un même ensemble de données peut être vu différemment par des
utilisateurs différents. Toutes ces visions personnelles des données doivent être intégrées dans une
vision globale.
Accès aux données : L’accès aux données se fait par l’intermédiaire d’un Langage de Mani-
pulation de Données (LMD). Il est crucial que ce langage permette d’obtenir des réponses aux re-
quêtes en un temps « raisonnable ». Le LMD doit donc être optimisé, minimiser le nombre d’accès
disques, et tout cela de façon totalement transparente pour l’utilisateur.
Administration centralisée des données (intégration) : Toutes les données doivent être cen-
tralisées dans un réservoir unique commun à toutes les applications. En effet, des visions diffé-
rentes des données (entre autres) se résolvent plus facilement si les données sont administrées de
façon centralisée.
Non redondance des données : Afin d’éviter les problèmes lors des mises à jour, chaque don-
née ne doit être présente qu’une seule fois dans la base.

Cohérence des données : Les données sont soumises à un certain nombre de contraintes d’in-
tégrité qui définissent un état cohérent de la base. Elles doivent pouvoir être exprimées simplement
et vérifiées automatiquement à chaque insertion, modification ou suppression des données. Les
contraintes d’intégrité sont décrites dans le Langage de Description de Données (LDD).
Partage des données : Il s’agit de permettre à plusieurs utilisateurs d’accéder aux mêmes don-
nées au même moment de manière transparente. Si ce problème est simple à résoudre quand il
s’agit uniquement d’interrogations, cela ne l’est plus quand il s’agit de modifications dans un con-
texte multi-utilisateurs car il faut : permettre à deux (ou plus) utilisateurs de modifier la même
donnée « en même temps » et assurer un résultat d’interrogation cohérent pour un utilisateur
consultant une table pendant qu’un autre la modifie.
Sécurité des données : Les données doivent pouvoir être protégées contre les accès non auto-
risés. Pour cela, il faut pouvoir associer à chaque utilisateur des droits d’accès aux données.
Résistance aux pannes : Que se passe-t-il si une panne survient au milieu d’une modification,
si certains fichiers contenant les données deviennent illisibles ? Il faut pouvoir récupérer une base
dans un état « sain ». Ainsi, après une panne intervenant au milieu d’une modification deux
solutions sont possibles : soit récupérer les données dans l’état dans lequel elles étaient avant la
modification, soit terminer l’opération interrompue.
2. Les Niveaux de description des données
Pour atteindre les objectifs ci-dessus cités, trois niveaux de description des données ont été définis
par la norme ANSI/SPARC.
Le niveau externe : Il correspond à la perception de tout ou partie de la base par un groupe donné
d'utilisateurs, indépendamment des autres. On appelle cette description le schéma externe ou vue.
Il peut exister plusieurs schémas externes représentant différentes vues sur la base de données
avec des possibilités de recouvrement. Le niveau externe assure l'analyse et l'interprétation des
requêtes en primitives de plus bas niveau et se charge également de convertir éventuellement
les données brutes, issues de la réponse à la requête, dans un format souhaité par l'utilisateur.
Le niveau conceptuel : Il décrit la structure de toutes les données de la base, leurs propriétés (i.e. les
relations qui existent entre elles : leur sémantique inhérente), sans se soucier de l'implémentation
physique ni de la façon dont chaque groupe de travail voudra s'en servir. Dans le cas des
SGBD relationnels, il s'agit d'une vision tabulaire où la sémantique de l'information est exprimée en
utilisant les concepts de relation, attributs et de contraintes d'intégrité. On appelle cette
description le schéma conceptuel.
Le niveau interne ou physique : Il s'appuie sur un système de gestion de fichiers pour définir la

politique de stockage ainsi que le placement des données. Le niveau physique est donc responsable
du choix de l'organisation physique des fichiers ainsi que de l'utilisation de telle ou
telle méthode d'accès en fonction de la requête. On appelle cette description le schéma interne.
3. Quelques SGBD connus et utilisés
Il existe de nombreux systèmes de gestion de bases de données. Ci-dessous présentée une liste non
exhaustive :
- PostgreSQL : http ://www.postgresql.org/ ;
- MySQL : http ://www.mysql.org/;
- Oracle : http ://www.oracle.com/ ;
- IBM DB2 : http ://www-306.ibm.com/software/data/db2/ ;
- Microsoft SQL : http ://www.microsoft.com/sql/ ;
- Sybase : http ://www.sybase.com/linux ;
- Informix : http ://www-306.ibm.com/software/data/informix/ ;
- …
4. Définition et objectifs des SGBD
Plusieurs architectures sont définies pour les SGBD : architecture centralisée ; architecture
Client/serveur…


Chapitre 2 :
Conception des bases de données : le modèle entité
association et modèle relationnel
Introduction
Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement

du système. C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohérence.
Un modèle est un langage commun, précis, qui est connu par tous les membres de l’équipe et il est
donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est essentielle pour
aboutir à une compréhension commune aux différentes parties prenantes (notamment entre la maî-
trise d’ouvrage et la maîtrise d’œuvre informatique) et précise d’un problème donné.
Dans le domaine de l’ingénierie du logiciel, le modèle permet de mieux répartir les tâches et
d’automatiser certaines d’entre elles. C’est également un facteur de réduction des coûts et des délais.
Il est difficile de modéliser un domaine sous une forme directement utilisable par un SGBD. Une
ou plusieurs modélisations intermédiaires sont donc utiles, le modèle entités-associations constitue
l'une des premières et des plus courantes. Ce modèle, permet une description naturelle du monde
réel à partir des concepts d'entité et d'association. Basé sur la théorie des ensembles et des relations,
ce modèle se veut universel et répond à l'objectif d'indépendance données-programmes. Ce modèle,
utilisé pour la phase de conception, s'inscrit notamment dans le cadre d'une méthode plus générale
et très répandue : MERISE.
I. Le modèle Entité Association

1. La méthode MERISE
MERISE signifie Méthode d'Étude et de Réalisation Informatique pour les Systèmes d'Entreprise.
C’est l’un des langages de spécification les plus répandu dans la communauté de l'informatique des
systèmes d'information, et plus particulièrement dans le domaine des bases de données. Une repré-
sentation Merise permet de valider des choix par rapport aux objectifs, de quantifier les solutions
retenues, de mettre en œuvre des techniques d'optimisation et enfin de guider jusqu'à l'implémenta-
tion. Reconnu comme standard, Merise devient un outil de communication. En effet, Merise réussit
le compromis difficile entre le souci d'une modélisation précise et formelle, et la capacité d'offrir un
outil et un moyen de communication accessible aux non-informaticiens.
Un des concepts clés de la méthode Merise est la séparation des données et des traitements. Cette
méthode est donc parfaitement adaptée à la modélisation des problèmes abordés d'un point de vue

fonctionnel. Les données représentent la statique du système d'information et les traitements sa dy-
namique. L'expression conceptuelle des données conduit à une modélisation des données en entités
et en associations.
Pour Merise quatre niveaux d’abstraction existent : Le niveau conceptuel, le niveau organisationnel,
le niveau logique et le niveau physique.
- Au niveau conceptuel, le modèle conceptuel des données (MCD) formalise la signification des
informations sur lesquelles repose le système d’information, sans contrainte technique ni écono-
mique. Le modèle conceptuel de traitement (MCT) formalise l’activité du domaine abordé, sans
préciser les ressources ni leur organisation.
- Au niveau organisationnel, le modèle organisationnel de traitements (MOT) décrit

le fonctionnement du domaine en précisant les ressources humaines et matérielles mobilisées ainsi
que l’organisation de ces ressources dans le temps et dans l’espace. Le modèle organisationnel des
données (MOD) précise quelles sont parmi les données définies au niveau conceptuel (MCD) celles
qui sont prises en compte par le futur système informatisé, où ces données sont localisées (réparti-
tion par site organisationnel), leur confidentialité pour chaque intervenant de l’entreprise.
- Au niveau logique, le modèle logique de données (MLD) fournit une description

des données tenant compte des moyens informatiques de mémorisation et de leurs conditions d’uti-
lisation par les traitements. Le modèle logique de traitement (MLT) décrit comment les tâches in-
formatisées définies dans les MOT précédents sont conçues en termes de logiciel.
- Au niveau physique, le modèle physique de données (MPD) est une description de la ou des bases
de données ou de l’ensemble des fichiers, exprimée dans la syntaxe du système de gestion de bases
de données (SGBD) ou système de gestion de fichiers (SGF) adoptés. Enfin, le modèle physique de
traitements (MPT) précise, pour la réalisation, les spécifications techniques des différents modules
définis au niveau du MLT.

Dans ce cours, nous écartons volontairement la modélisation des traitements puisque nous ne nous
intéressons à la méthode Merise que dans la perspective de la modélisation de bases de données.
Merise propose une démarche, dite par niveaux, dans laquelle il s'agit de hiérarchiser les préoccu-
pations de modélisation qui sont de trois ordres : la conception, l'organisation et la technique. En
effet, pour aborder la modélisation d'un système, il convient de l'analyser en premier lieu de façon
globale et de se concentrer sur sa fonction : c'est-à-dire de s'interroger sur ce qu'il fait avant de
définir comment il le fait. Ces niveaux de modélisation sont organisés dans une double approche
données/traitements.
Les trois niveaux de représentation des données, puisque ce sont eux qui nous intéressent, sont dé-
taillés ci-dessous.
 Niveau conceptuel : le modèle conceptuel des données (MCD) décrit les entités du monde
réel, en termes d'objets, de propriétés et de relations, indépendamment de toute technique d'organi-
sation et d'implantation des données. Ce modèle se concrétise par un schéma entités-associations
représentant la structure du système d'information, du point de vue des données.
 Niveau logique : le modèle logique des données (MLD) précise le modèle conceptuel par
des choix organisationnels. Il s'agit d'une transcription (également appelée dérivation) du MCD dans
un formalisme adapté à une implémentation ultérieure, au niveau physique, sous forme de base
de données relationnelle ou réseau, ou autres. Les choix techniques d'implémentation (choix
d'un SGBD) ne seront effectués qu'au niveau suivant.
 Niveau physique : le modèle physique des données (MPD) permet d'établir la manière con-
crète dont le système sera mis en place (SGBD retenu).
2. Éléments constitutifs du modèle entités-associations
Le modèle conceptuel de données (MCD) est la représentation de l’ensemble des données du do-
maine, sans tenir compte des aspects techniques et économiques de mémorisation et d’accès, sans
se référer aux conditions d’utilisation par tel ou tel traitement.
Dans un système d’information en fonctionnement, données et traitements apparaissent intimement
liés (surtout du point de vue de l’utilisateur). L’ensemble des informations utilisées, échangées cons-
titue l’univers du discours du domaine. Dans cet univers du discours, on fait référence à des objets
concrets ou abstraits (l’assuré, le contrat) et à des associations entre ces objets (le contrat comporte
des garanties). L’objectif du modèle conceptuel de données est d’identifier, de décrire par des in-
formations et de modéliser ces objets et associations.
Le formalisme utilisé dans Merise est désigné par entité-relation. Ce formalisme comporte quatre
concepts types de base. Deux concepts sont structuraux, l’entité type ou l’objet et la relation type ;

le troisième concept est descriptif, c’est la propriété type ou l’attribut ; le quatrième qualifie la
liaison entre entité-type et relation-type, c'est la cardinalité. Ce formalisme possède une représen-
tation graphique présentée à la figure suivante :
i. La propriété type ou l’attribut

Une propriété type est la modélisation d’une information élémentaire présente dans le discours.
Elle peut prendre des valeurs ; par exemple :
Nom de client : Dupont, Durand, Martin, pierre…
Date de naissance : 23/07/2012, 02/03/202, 25/10/1995…
Montant du chèque : 250 000 F, 1 392,75 F, 31 745 F…
La propriété est l’élément descriptif de l’entité type ou de la relation type. Pour prendre sa signifi-
cation, une propriété est obligatoirement rattachée à une entité type ou à une relation type. Une
propriété est unique dans un modèle conceptuel et ne peut être rattachée qu’à un seul concept (entité
type ou relation type). Pour matérialiser une propriété ou un attribut, on doit respecter les règles
suivantes :
- Règle 1 : Un attribut ne peut en aucun cas être partagé par plusieurs type-entités ou type associations ;
- Règle 2 : Un attribut est une donnée élémentaire, ce qui exclut des données calculées ou dérivées ;
- Règle 3 : Une entité et ses attributs doivent être cohérents entre eux (ne traiter que d'un seul sujet).
Au niveau du type-entité ou du type-association, chaque attribut possède un domaine qui définit
l'ensemble des valeurs possibles qui peuvent être choisies pour lui (entier, chaîne de caractères,
booléen, …). Au niveau de l'entité, chaque attribut possède une valeur compatible avec son do-
maine.
ii. L’entité type ou l’objet
L’entité type permet de modéliser un ensemble d’objets de même nature, concrets ou abstraits, per-
çus d’intérêt dans le discours. L’entité exprime un type, une classe, un ensemble dont les éléments
sont appelés occurrences d’entité. Une entité désigne aussi un ensemble d’éléments qui possèdent
une sémantique et des propriétés communes.
iii. La relation type ou l’association
Une association modélise un ensemble de liaisons de même nature entre une ou plusieurs occur-
rences d’entités (de types différents ou du même type), perçus d’intérêt dans l’univers du discours.
Le choix de la relation type dépend de l’intérêt porté par le concepteur aux associations perçues. La
relation type n’existe qu’à travers les entités types qui la composent.

Une association (ou une relation) est un lien entre plusieurs entités. Comme les type-entités, les
type-associations sont définis à l'aide d'attributs qui prennent leur valeur dans les associations. Un
attribut peut être placé dans un type-association uniquement lorsqu'il dépend de toutes les entités
liées par le type-association. Un type-association peut ne pas posséder d'attribut explicite et cela est
relativement fréquent, mais on verra qu'il possède au moins des attributs implicites.
Exemple : Gestion d’une bibliothèque
Plusieurs relations types peuvent partager la même collection. De même Une association peut
exister entre les occurrences d’une même entité.
Exemples :
iv. Les cardinalités d’une entité type dans une relation type
Le terme cardinalité, dans le formalisme entité-relation, traduit la participation des occurrences
d’une entité type aux occurrences d’une relation type. Cette participation s’analyse par rapport à
une occurrence quelconque de l’entité type, et s’exprime par deux valeurs : la cardinalité minimum
et la cardinalité maximum. Pour matérialiser les cardinalités les règles suivantes doivent être res-
pectées :
- Règle 1 : L'expression de la cardinalité est obligatoire pour chaque patte d'un type-association.
- Règle 2 : Une cardinalité minimale est toujours 0 ou 1 et une cardinalité maximale est toujours 1 ou n.
Les cardinalités fréquemment utilisées sont :
Exemple de cardinalité sur une relation réflexive :

Exemple de cardinalité sur une relation binaire :
Exemples de cardinalité sur une relation ternaire :
Exemple de MCD complet
II. Normalisation des type-entités et type-associations
Les formes normales sont différents stades de qualité qui permettent d’éviter la redondance, source
d’anomalies. La normalisation peut être aussi bien effectuée sur un modèle entités-associations, où
elle s’applique sur les type-entités et type-associations, que sur un modèle relationnel.
Il existe 5 formes normales principales et deux extensions. Plus le niveau de normalisation est élevé,
plus le modèle est exempt de redondances. Un type-entité ou un type-association en forme normale
de niveau n est automatiquement en forme normale de niveau n - 1. Une modélisation rigoureuse
permet généralement d’aboutir directement à des type-entités et type-associations en forme normale
de Boyce-Codd. Nous irons alors jusqu’à la troisième forme normale.
1. Première forme normale (1FN)

Définition - Première forme normale (1FN) - Un type-entité ou un type-association est en pre-
mière forme normale si tous ses attributs sont élémentaires, c’est-à-dire non décomposables. Un
attribut composite doit être décomposés en attributs élémentaires (comme l’attribut Adresse sur la
figure suivante) ou faire l’objet d’une entité supplémentaire (comme l’attribut Occupants sur la fi-
gure suivante. L’élémentarité d’un attribut est toutefois fonction des choix de gestion. Par exemple,
la propriété Adresse peut être considérée comme élémentaire si la gestion de ces adresses est globale.
Par contre, s’il faut pouvoir considérer les codes postaux, les noms de rues, . . ., il convient d’éclater
la propriété Adresse.
2. Deuxième forme normale (2FN)
Définition - Deuxième forme normale (2FN) - Un type-entité ou un type-association est en deu-

xième forme normale si, et seulement si, il est en première forme normale et si tout attribut n’ap-
partenant pas à la clé dépend de la totalité de cette clé.
Autrement dit, les attributs doivent dépendre de l’ensemble des attributs participant à la clé. Ainsi,
si la clé est réduite à un seul attribut, ou si elle contient tous les attributs, le type-entité ou le type-
association est, par définition, forcément en deuxième forme normale. La figure suivante montre un
type-entité Article décrivant des produits provenant de différents fournisseurs. On suppose qu’un
même fournisseur peut fournir plusieurs produits et qu’un même produit peut être fourni par diffé-
rents fournisseurs. Dans ce cas, les attributs Produit ou Fournisseur ne peuvent constituer un iden-
tifiant du type-entité Article. Par contre, le couple Produit/Fournisseur constitue bien un identifiant
du type-entité Article. Cependant, l’attribut Adresse fournisseur ne dépend maintenant que d’une
partie de la clé (Fournisseur). Opter pour une nouvelle clé arbitraire réduite à un seul attribut N˚
article permet d’obtenir un type-entité Article en deuxième forme normale. On va voir dans ce qui
suit que cette solution n’a fait que déplacer le problème.

3. Troisième forme normale (3FN)
Définition -Troisième forme normale (3FN) - Un type-entité ou un type-association est en troi-

sième forme normale si, et seulement si, il est en deuxième forme normale et si tous ses attributs
dépendent directement de sa clé et pas d’autres attributs. Cette normalisation peut amener à désim-
briquer des type-entités cachées comme le montre la figure suivante. Un type-entité ou un type-
association en deuxième forme normale avec au plus un attribut qui n’appartient pas à la clé est, par
définition, forcément en troisième forme normale.
III. Le modèle relationnel

1. Présentation
Une base de données relationnelle est une base de données structurée suivant les principes de l’al-
gèbre relationnelle. Dans ce modèle, les données sont représentées par des tables, sans préjuger de
la façon dont les informations sont stockées dans la machine. Les tables constituent donc la structure
logique du modèle relationnel. Au niveau physique, le système est libre d'utiliser n'importe quelle
technique de stockage (fichiers séquentiels, indexage, adressage dispersé, séries de pointeurs, com-
pression, ...) dès lors qu'il est possible de relier ces structures à des tables au niveau logique. Les
tables ne représentent donc qu'une abstraction de l'enregistrement physique des données en mé-
moire.
Le succès du modèle relationnel auprès des chercheurs, concepteurs et utilisateurs est dû à la puis-
sance et à la simplicité de ses concepts. En outre, contrairement à certains autres modèles, il repose
sur des bases théoriques solides, notamment la théorie des ensembles et la logique des prédicats du
premier ordre.
Les objectifs du modèle relationnel sont :
- Proposer des schémas de données faciles à utiliser ;
- Améliorer l'indépendance logique et physique ;
- Mettre à la disposition des utilisateurs des langages de haut niveau ;
- Optimiser les accès à la base de données ;
- Améliorer l'intégrité et la confidentialité ;
- Fournir une approche méthodologique dans la construction des schémas.

De façon informelle, on peut définir le modèle relationnel de la manière suivante :
- Les données sont organisées sous forme de tables à deux dimensions, encore appelées rela-
tions, dont les lignes sont appelées n-uplet ou tuple ;
- Les données sont manipulées par des opérateurs de l'algèbre relationnelle ;
- L’état cohérent de la base est défini par un ensemble de contraintes d'intégrité.
Au modèle relationnel est associée à la théorie de la normalisation des relations qui permet de se
débarrasser des incohérences au moment de la conception d'une base de données relationnelle.
2. Définition des éléments du modèle relationnel
Plusieurs concepts sont définis dans le modèle relationnel :

Définition 1 : -attribut- Un attribut est un identificateur (un nom) décrivant une information
stockée dans une base.
Définition 2 : -Domaine- Le domaine d'un attribut est l'ensemble, fini ou infini, de ses valeurs
possibles.
Définition 3 : -relation- Une relation est un sous-ensemble du produit cartésien de n domaines
d'attributs (n > 0). Une relation est représentée sous la forme d'un tableau à deux dimensions dans
lequel les n attributs correspondent aux titres des n colonnes.
Définition 4 : -schéma de relation- Un schéma de relation précise le nom de la relation ainsi que
la liste des attributs avec leurs domaines.
Le tableau suivant montre un exemple de relation et précise son schéma.
Personne(N° Sécu : Entier, Nom : Chaîne, Prénom : Chaîne)

Définition 5 : -degré- Le degré d'une relation est son nombre d'attributs.
Définition 6 : -occurrence ou n-uplets ou tuples- Une occurrence, ou n-uplets, ou tuples, est un
élément de l'ensemble figuré par une relation. Autrement dit, une occurrence est une ligne du ta-
bleau qui représente la relation.
Définition 7 : -cardinalité- La cardinalité d'une relation est son nombre d'occurrences.
Définition 8 : -clé candidate- Une clé candidate d'une relation est un ensemble minimal des attri-
buts de la relation dont les valeurs identifient à coup sûr une occurrence. La valeur d'une clé candi-
date est donc distincte pour toutes les tuples de la relation. La notion de clé candidate est essen-
tielle dans le modèle relationnel.

NB : Toute relation a au moins une clé candidate et peut en avoir plusieurs. Ainsi, il ne peut ja-
mais y avoir deux tuples identiques au sein d'une relation. Les clés candidates d'une relation n'ont
pas forcément le même nombre d'attributs. Une clé candidate peut être formée d'un attribut arbi-
traire, utilisé à cette seule fin.
Définition 10 : -clé primaire- La clé primaire d'une relation est une de ses clés candidates. Pour
signaler la clé primaire, ses attributs sont généralement soulignés.
Définition 11 : -clé étrangère- Une clé étrangère dans une relation est formée d'un ou plusieurs
attributs qui constituent une clé primaire dans une autre relation.
Définition 12 : -schéma relationnel- Un schéma relationnel est constitué par l'ensemble des sché-
mas de relation.
Définition 13 : -base de données relationnelle- Une base de données relationnelle est constituée
par l'ensemble des n-uplets des différentes relations du schéma relationnel.
3. Exemple de base de données relationnelle
A titre d’exemple voici une base de données relationnelle rudimentaire, utilisant 3 tables représen-
tant les commandes de produits à des fournisseurs.
Le schéma de cette base est donc : produits(pno, design, prix, poids, couleur) ; fournisseurs(fno,
nom, adresse, ville) et commandes(cno, #fno, #pno, qute)
4. Passage du modèle entités-associations au modèle relationnel
i- Règles de passage
Une fois le MCD écrit par les analystes, le travail du concepteur de bases de données consiste à
traduire ce modèle en un modèle plus proche du SGBD utilisé : le MLD (modèle logique de don-
nées). Dans le MLD relationnel, l’unique type d’objet existant est la table. La méthode de passage
d’un MCD Merise aux tables relationnelles est simple et systématique :
Traitement des entités :
- Chaque entité devient une table.
- Chaque propriété d’une entité devient une colonne de cette table.
- L’identifiant d’une entité devient la clé primaire de la table correspondante (création d’un index).
Pour traduire un schéma du modèle entités-associations vers le modèle relationnel, on peut appliquer
les règles suivantes :
1. La normalisation devrait toujours être effectuée avant le passage au modèle relationnel. Dans
les faits, elle est parfois faite a posteriori, ce qui impose toujours une surcharge de travail impor-
tante.
2. Chaque type-entité donne naissance à une relation. Chaque attribut de ce type-entité devient
un attribut de la relation. L'identifiant est conservé en tant que clé de la relation.
3. Chaque type-association dont aucune patte n'a pour cardinalité maximale 1 donne naissance à une
relation. Chaque attribut de ce type-association devient un attribut de la relation. L'identifiant, s'il

est précisé, est conservé en tant que clé de la relation, sinon cette clé est formée par
la concaténation des identifiants des type-entités qui interviennent dans le type-association.
4. Un type-association dont au moins une patte a une cardinalité maximale à 1 (ce type-association
devrait être binaire et n'a généralement pas d'attribut) ne devient pas une relation. Il décrit en effet
une dépendance fonctionnelle. La relation correspondant au type-entité dont la patte vers le type-
association a une cardinalité maximale valant 1, se voit simplement ajouter comme attribut (et donc
comme clé étrangère) l'identifiant de l'autre type-entité.
ii- Traitement des associations

Cas particulier d'un type-association du type 1 vers 1
En considérant l’exemple suivant :
On constate que toutes les cardinalités maximales sont à 1. L'application des règles de passage du
modèle entités-associations au modèle relationnel énoncées ci- dessus nous donnerait :

- Citoyen(Num-Citoyen, #Num-Candidat, Nom, Prénom, Adresse)

- Candidat(Num-Candidat), Num-Citoyen, Parti)
L'attribut Num-Candidat dans la relation Citoyen est une clé étrangère de la relation Candidat.
L'attribut Num-Citoyen dans la relation Candidat est une clé étrangère de la relation Citoyen.
Le type-association Etre étant du type 1 vers 1, il est entièrement matérialisé dans la relation
Candidat par l'attribut Num-Citoyen. Il est donc inutile de la rematérialiser dans la relation Ci-
toyen.
L'attribut Num-Candidat dans la relation Citoyen doit donc être supprimé. D'autre part, dans la re-
lation Candidat, l'attribut Num-Citoyen, en plus d'être une clé étrangère, constitue une clé cand-
date.
On peut donc se passer de la clé Num-Candidat.
Le schéma relationnel adéquat correspondant au modèle entités-associations de la figure pré-
cédente devient donc :
- Citoyen(Num-Citoyen, Nom, Prénom, Adresse)
- Candidat(Num-Citoyen, Parti)
où Num-Citoyen, en plus d'être la clé de la relation Candidat, est une clé étrangère de la relation
Citoyen.
Cas particulier d'un type-association du type (0,n) vers (0,1)
Une association (0,n)-(0,l) (lien hiérarchique) provoque la migration d’une clé étrangère (l’identi-
fiant côté 0,n) vers la table de l’entité côté (0,1)- Si des propriétés étaient sur l’association elles
migrent côté (0,1).
FIG. 1.9 - MCD avec lien hiérarchique
L'application des règles de passage du modèle entités-associations au modèle relationnel énoncées

ci- dessus nous donnerait :

– Patient(Num-Patient, Nom-Patient, #Num-Mutuelle)

– Mutuelle(Num-Mutuelle, Nom-Mutuelle)
Cas particulier d'un type-association du type (0,n) ou (1,n) vers (0,n) ou (1,n)
Une association (0,n)-(0,n) (lien maillé) donne naissance à une nouvelle table. Les identifiants des
entités auxquelles l’association est reliée migrent dans cette table, la clé primaire de cette nouvelle
table est constituée de la réunion de ces identifiants. Si des propriétés étaient portées par l’associa-
tion, elles migrent dans la nouvelle table.
MCD
MLD correspondant
L'application des règles de passage du modèle entités-associations au modèle relationnel énoncées

ci- dessus nous donnerait :
– Fournisseur(fno, nom, adresse, ville)
– Produit(pno, design, prix, poids, couleur)
– Commandes(fno , pno, qute)
Cas particulier d'un type-entité sans attribut autre que sa clé
Lorsqu'un type-entité ne possède pas d'attribut en dehors de sa clé, il ne faut pas nécessairement en
faire une relation. En considérant l’exemple suivant :

Le type-entité Date ne doit pas se traduire par une relation. Le schéma relationnel adéquat corres-
pondant au modèle entités-associations du MCD précèdent est donc :
- Exemplaire(Num-Exemplaire, date-achat)
- Personne(Num-Personne, nom, prénom, adresse)
- Emprunter(Num-Exemplaire, Num-Personne, Date, date-retour)
Exemple complet
Voici les relations déduites du schéma entités-associations précèdent :

- Patient(Num-Patient, Nom-Patient, #Num-Mutuelle)
- Mutuelle(Num-Mutuelle, Nom-Mutuelle)
- Médecin(Num-Médecin, Nom-Médecin, Prénom-Médecin)
- Affection(Num-Affection, Nom-Affection)
- Hospitaliser(Num-Patient, Num-Affection, Num-Médecin, Date-Entrée, Chambre, DuréeHospi-
talisation)
IV. Les contraintes d’intégrités
La gestion automatique des contraintes d’intégrité est l’un des outils les plus importants d’une
base de données. Elle justifie à elle seule l’usage d’un SGBD. Selon les contraintes, différentes
anomalies que nous allons passer en revue peuvent se déclencher dès qu’un accès aux données (sai-
sie, modification, effacement) est effectué.
Dès qu’un accès non conforme aux contraintes spécifiées dans la base survient, l’action effectuée
est automatiquement rejetée puis soit présentée à l’utilisateur si le traitement se fait en interactif,
soit rangée dans une table d’erreurs si le traitement se fait en batch.

1. Contraintes de clé
Le premier type de contraintes d’intégrité traité par un SGBD permet de vérifier la présence
de clés uniques pour chacune des tables. Cette clé est nommée clé primaire de la table. Il ne peut y
en avoir qu’une seule par table. Une clé primaire peut bien sûr être constituée de plusieurs colonnes.
Quelle que soit la table, si une clé primaire est définie, elle doit être présente pour chaque enregis-
trement, elle doit être unique et aucun de ses constituants ne peut être NULL. Si la clé est omise, si
elle est à la valeur NULL ou si elle a déjà été saisie pour un autre enregistrement de la table, une
anomalie de clé est déclenchée.
Plusieurs regroupements d’attributs peuvent en général prétendre à être clé primaire. Ce sont les
clés candidates. Les clés candidates qui n’ont pas été choisies comme clé primaire sont alors décla-
rées avec la contrainte UNIQUE.
2. Contraintes de types de données
Le second type de contraintes d’intégrité traité par un SGBD permet ensuite de vérifier les
types des données saisies (entiers, réels, dates, chaînes de caractères, booléens etc ...) et les domaines
de validité pour chacune de ces données (date postérieure au 01/01/1980 pour la gestion des com-
mandes d’une entreprise créée à cette date, entier compris entre 0 et 20 pour représenter une note
d’étudiant, etc ...).
3. Contraintes d’intégrité référentielle
La gestion des contraintes d’intégrité permet aussi de vérifier automatiquement la présence
de données référencées dans des tables différentes. Ce type de contrainte est appelé contrainte d’in-
tégrité référentielle. Une contrainte d’intégrité référentielle peut s’appliquer dès qu’une clé primaire
d’une table est utilisée comme référence dans une autre table. On la nomme alors clé étrangère de
la seconde table. Par exemple, l’identifiant d’un produit est une clé étrangère dans la table des com-
mandes, de même l’identifiant d’un bus est une clé étrangère de la table des lignes de bus. Concrè-
tement, les clés étrangères se trouvent dans toutes les tables possédant un champ issu d’associations
du MCD. Comme pour la clé primaire, une clé étrangère peut être constituée de plusieurs colonnes.
Contrairement aux clés primaires, la valeur NULL est acceptée dans une clé étrangère. Ce cas se
produit notamment avec une contrainte du type ON DELETE SET NULL que nous verrons par la
suite.

Selon les SGBD utilisés, d’autres types de contraintes peuvent encore être gérées, notamment via
des procédures lancées automatiquement en cas d’ajout, de modification ou d’effacement de don-
nées (triggers). L’important est de noter que l’avantage qu’apporte un SGBD sur un système clas-
sique est que ces contraintes sont traitées au niveau des données et non pas placées dans les traite-
ments.

Chapitre 3 :
Les fondamentaux de l’algèbre relationnelle : lo-
gique mathématiques, théorie des ensembles et opé-
rations
Introduction
La représentation d'information sous forme relationnelle est intéressante car les fondements mathé-
matiques du relationnel, outre qu'ils permettent une modélisation logique simple et puissante, four-
nissent également un ensemble de concepts pour manipuler formellement l'information ainsi modé-
lisée.
Ainsi une algèbre relationnelle, sous forme d'un ensemble d'opérations formelles, permet d'exprimer
des questions, ou requêtes, posées à une représentation relationnelle, sous forme d'expressions al-
gébriques.
I. Introduction à l’algèbre relationnelle

1. Définition et description
1.1.Définition
L'algèbre relationnelle est un langage de requêtes dans des bases de données relationnelles. L'al-
gèbre relationnelle a été inventée en 1970 par Edgar Frank Codd, le directeur de recherche du centre
IBM de San José. Il s'agit de la théorie sous-jacente aux langages de requête des SGBD, comme
SQL. Le théorème de Codd dit que l'algèbre relationnelle est équivalente au calcul relationnel (lo-
gique du premier ordre sans symbole de fonction). L’algèbre relationnelle est l’ensemble d’opéra-
teurs qui s’appliquent aux relations. L’algèbre relationnelle permet de faire des recherches dans les
relations. Les questions formulées en algèbre relationnelle sont la base des questions formulées en
SQL pour interroger une base de données relationnelle.
1.2.Description
L'algèbre relationnelle est un support mathématique cohérent sur lequel repose le modèle relation-
nel. L'objet de cette section est d'aborder l'algèbre relationnelle dans le but de décrire les
opérations qu'il est possible d'appliquer sur des relations pour produire de nouvelles relations.
L'approche suivie est donc plus opérationnelle que mathématique.
On peut distinguer trois familles d'opérateurs relationnels :

- Les opérateurs unaires (Sélection, Projection) : ce sont les opérateurs les plus simples, ils
permettent de produire une nouvelle table à partir d'une autre table.

- Les opérateurs binaires ensemblistes (Union, Intersection, Différence) : ces opérateurs per-
mettent de produire une nouvelle relation à partir de deux relations de même degré et de
même domaine.
- Les opérateurs binaires ou n-aires (Produit cartésien, Jointure, Division) : ils permettent de
produire une nouvelle table à partir de deux ou plusieurs autres tables. Ces opérations seront
détaillées dans le chapitre suivant.
2. La Logique propositionnelle
Le programmeur, quel que soit le langage de programmation qu’il utilise, fait constamment usage
de boucles et d’instructions conditionnelles. Dans ces deux cas de figure (et bien d’autres encore),
il est indispensable de pouvoir tester la véracité de conditions, parfois imbriquées les unes dans les
autres, rendant compliquée la tâche d’expliquer dans quel état se trouve le système après exécution
d’une partie quelconque de son programme. Il est donc primordial de pouvoir passer de façon sys-
tématique d’un état à un autre, et de pouvoir expliquer sa démarche. On appelle proposition (ou
assertion) toute phrase d’un langage donné dont on peut déterminer sans ambiguïté si elle est vraie
ou fausse. Par exemple, les phrases en langue française "je suis allé étudier au campus hier soir" ou
"il a plu ce matin" peuvent être considérées comme des propositions. En logique mathématique (et
en informatique), l’on souhaite formaliser ce qu’est une proposition.
2.1.. Définition
En logique propositionnelle classique, une proposition est formée à partir de propositions atomiques
en nombre fini arbitraire, appelées variables propositionnelles (ou simplement variables),
en respectant des règles précises appelées des opérations logiques ou encore connecteurs logiques.
Ces connecteurs logiques sont :
— la négation ("non") notée ¬ ;
— la conjonction ("et") notée ˄ ;
— la disjonction ("ou") notée ˅ ;
— l’implication ("implique") notée ⇒;
— l’équivalence ou double implication ("si et seulement si") notée ⇔.
Dans le cadre de ce cours, nous noterons les propositions par les lettres P, Q, R, …..
2.2. Quelques exemples de propositions
Soient les proposition P et Q suivantes :

P : "Il a plu ce matin à Yaoundé." Q : "Il a neigé ce matin à Yaoundé."
On aura :
¬P : "Il n’a pas plu ce matin à Yaoundé.".
P˅Q : "Il a plu ou il a neigé ce matin à Yaoundé."

P˄Q : "Il a plu et il a neigé ce matin à Yaoundé."
Puisqu’une proposition est par principe soit vraie, soit fausse, on lui attribuera une valeur de vérité
"vrai" ou "faux", que l’on notera en général "1" ou "0" respectivement. Ces valeurs de vérité seront
consignées dans un tableau appelé « Table de vérité », répertoriant tous les cas possibles des valeurs
de vérité de la proposition.
2.3. Les Tables de vérité fondamentales
des propositions P⇒Q et Q⇒P est vraie.

Exercice d’application : montrer que les propositions P⇔Q et [(P⇒Q)˄(Q⇒P)] ont exactement
la même table de vérité.
֍ Parenthèses
Grâce aux connecteurs logiques, on peut construire de nouvelles propositions à partir d’anciennes.
Toutefois, il conviendra d’utiliser des parenthèses pour indiquer l’ordre dans lequel s’effectuent
les opérations logiques.
Exercice d’application : vérifier que les propositions P˄(Q˅R) et (P˄Q)˅R ont des tables de vé-
rité différentes, mais que : P˅(Q˅R) et (P˅Q)˅R ont les mêmes tables de vérité.
2.4.Equivalence
Deux propositions P et Q sont dites logiquement équivalentes lorsqu’elles ont exactement les
mêmes tables de vérité, et l’on note : P≡Q.
Exemple : P⇔Q ≡ [(P⇒Q)˄(Q⇒P)]
Exercices d’application :
1. Démontrer les équivalences logiques suivantes :
P ≡ ¬(¬P) P=>Q ≡ ¬P˅Q
P˄Q ≡ Q˄P ¬(P⇒Q) ≡ P˄¬Q
P˅Q ≡ Q˅P P⇒Q ≡ ¬Q⇒¬P
¬(P˅Q) ≡ ¬P˄¬Q P⇒(Q˅R) ≡ (P˄¬Q)=>R
¬(P˄Q) ≡ ¬P˅¬Q (P˅Q)⇒R ≡ (P⇒R)˄(Q⇒R)
2. Donner une proposition équivalente à P⇔Q ne contenant que les connecteurs ¬ et ˅.
2.5.Tautologie et contradiction
Une tautologie est une proposition toujours vraie, quelles que soient les valeurs de vérité attri-
buées aux variables propositionnelles qui la composent. Autrement dit, la dernière colonne de
la table de vérité d’une tautologie ne contient que la valeur 1.
Exemples : vérifier que les propositions suivantes sont des tautologies :
[(P⇒Q)˄P]⇒Q
[(P˅Q)˄¬P]⇒Q
La négation d’une tautologie est appelée contradiction ou absurdité. Il s’agit donc d’une propo-
sition toujours fausse, quelles que soient les valeurs de vérité attribuées aux variables proposition-
nelles qui la composent.
Exemple : [(P⇒Q)˄P]˄¬Q
3. La théorie des ensembles


II. Les opérations de l’Algèbre relationnelle
L'algèbre relationnelle est un support mathématique cohérent sur lequel repose le modèle
relationnel. L'objet de cette section est d'aborder l'algèbre relationnelle dans le but de décrire les
opérations qu'il est possible d'appliquer sur des relations pour produire de nouvelles relations.
L'approche suivie est donc plus opérationnelle que mathématique.
On peut distinguer trois familles d'opérateurs relationnels : Les opérateurs unaires (Sélection, Pro-
jection) : ce sont les opérateurs les plus simples, ils permettent de produire une nouvelle table à
partir d'une autre table.
Les opérateurs binaires ensemblistes (Union, Intersection, Différence) : ces opérateurs permettent
de produire une nouvelle relation à partir de deux relations de même degré et de même domaine.
Les opérateurs binaires ou n-aires (Produit cartésien, Jointure, Division) : ils permettent de produire
une nouvelle table à partir de deux ou plusieurs autres tables.
1. Les opérateurs binaires ensemblistes

1.1.L’union
L'union est une opération portant sur deux relations R1 et R2 ayant le même schéma et construisant
une troisième relation constituée des n-uplets appartenant à chacune des deux relations R1 et R2 sans
doublon, on la note R1 U R2. R1 et R2 doivent avoir les mêmes attributs et si une même occurrence
existe dans R1 et R2, elle n'apparaît qu'une seule fois dans le résultat de l'union. Le résultat de l'union
est une nouvelle relation qui a les mêmes attributs que R1 et R2. Si R1 et R2 sont vides, la relation
qui résulte de l'union est vide. Si R1 (respectivement R2) est vide, la relation qui résulte de l'union
est identique à R2 (respectivement R1)
En somme, L'union de deux relations R1 et R2 de même schéma produit une relation R de même
schéma constituée de l'ensemble des tuples appartenant à R1 et/ou à R2.
Exemple d'union : R = R1 U R2 :
1.2. L’Intersection
L'intersection est une opération portant sur deux relations R1 et R2 ayant le même schéma et cons-
truisant une troisième relation dont les n-uplets sont constitués de ceux appartenant aux deux rela-
tions, on la note R1 Ո R2.
En somme, L'intersection de deux relations R1 et R2 de même schéma produit une relation R3 de

même schéma constitué de l'ensemble des tuples appartenant à la fois à R1 et à R2. Notons que
l'intersection n'est pas une opération de base, car elle est équivalent à deux opérations de différence
successives.
Comme nous l'avons déjà dit, R1 et R2 doivent avoir les mêmes attributs. Le résultat de l'intersection
est une nouvelle relation qui a les mêmes attributs que R1 et R2. Si R1 ou R2 ou les deux
sont vides, la relation qui résulte de l'intersection est vide.
Exemple d'intersection : R = R1 Ո R2 :
1.3.La Différence
La différence est une opération portant sur deux relations R1 et R2 ayant le même schéma et cons-
truisant une troisième relation dont les n-uplets sont constitués de ceux ne se trouvant que dans la
relation R1 ; on la note R1 - R2.
En somme, La différence entre deux relations R1 et R2 de même schéma produit une relation R3 de
même schéma constituée de l'ensemble des tuples de R1 n'appartenant pas à R2. Notons que la
différence entre R1 et R2 n'est pas égale à la différence entre R2 et R1. Comme nous l'avons déjà
dit, R1 et R2 doivent avoir les mêmes attributs. Le résultat de la différence est une nouvelle relation
qui a les mêmes attributs que R1 et R2. Si R1 est vide, la relation qui résulte de la différence est
vide. Si R2 est vide, la relation qui résulte de la différence est identique à R1.
Exemple de différence : R = R1 - R2 :
2. Les opérateurs unaires
2.1. La Sélection
La sélection (parfois appelée restriction) génère une relation regroupant exclusivement toutes
les occurrences de la relation R qui satisfont l’expression logique E, on la note σ(E)R.
En d’autres termes, la sélection permet de choisir (i.e. sélectionner) des lignes dans le tableau. Le

résultat de la sélection est donc une nouvelle relation qui a les mêmes attributs que R. Si R est vide
(i.e. ne contient aucune occurrence), la relation qui résulte de la sélection est vide.
Exemple : Soit la relation personne suivante :
La sélection sur la relation Personne avec la contrainte : σ(Numero ≥5)Personne est
2.2. La Projection
La projection est une opération unaire (c'est à dire portant sur une seule relation). La projection de
R1 sur une partie de ses attributs {A1, A2, ...} produit une relation R2 dont le schéma est restreint
aux attributs mentionnés en opérande, comportant les mêmes tuples que R1, et dont les doublons
sont éliminés.
La projection consiste à supprimer les attributs autres que A1, . . . An d’une relation et à éliminer
les n-uplets en double apparaissant dans la nouvelle relation ; on la note Π(A1, ...An)R.
En d’autres termes, la projection permet de choisir des colonnes dans le tableau. Si R est vide, la
relation qui résulte de la projection est vide, mais pas forcément équivalente (elle contient généra-
lement moins d’attributs).
Remarque : Après suppression d'une partie des attributs du schéma, la relation peut comporter des
doublons. Étant donné que l'on ne pourrait plus identifier ces doublons les uns par rapport aux autres,
la seule solution sensée est donc de considérer que deux doublons sont équivalents, et donc de n'en
garder qu'un seul dans la relation résultante.
Exemple1 : Soit la relation personne suivante :
La projection sur la relation Personne notée ΠNomPersonne ou Projection (Personne, nom) est :
Exemple 2 : Soit la relation suivante : Personne (nom, prénom, age)

La projection sur la relation Personne notée ΠNom,agePersonne ou Projection (Personne, nom, age)
2.3.La restriction
La restriction est une opération unaire (c'est à dire portant sur une seule relation). La restriction de
R1, étant donnée une condition C, produit une relation R2 de même schéma que R1 et dont les tuples
sont les tuples de R1 vérifiant la condition C. Les synthases sont les suivantes :
Exemple : Soit la relation personne suivante :
Soit l'opération suivante : R = Restriction (Personne, age>25) ; On obtient alors la relation R com-
posée de l'unique tuple restant suivant :
3. Les opérateurs n-aires

3.1. Le Produit cartésien
Le produit cartésien est une opération portant sur deux relations R1 et R2 et qui construit une
troisième relation regroupant exclusivement toutes les possibilités de combinaison des occurrences
des relations R1 et R2, on la note R1 × R2.
Le résultat du produit cartésien est une nouvelle relation qui a tous les attributs de R1 et tous ceux
de R2. Si R1 ou R2 ou les deux sont vides, la relation qui résulte du produit cartésien est vide. Le
nombre d’occurrences de la relation qui résulte du produit cartésien est le nombre d’occurrences de
R1 multiplié par le nombre d’occurrences de R2.
Exemple 1 :

Exemple 2 de produit cartésien : R = Amie × Cadeau :
3.2. La Jointure
La jointure est une opération portant sur deux relations R1 et R2 qui construit une troisième relation
regroupant exclusivement toutes les possibilités de combinaison des occurrences des relations R1
et R2 qui satisfont l’expression logique E. La jointure est notée.
En d’autres termes, La jointure de R1 et R2, étant donné une condition C portant sur des attributs
de R1 et de R2, de même domaine, produit une relation R3 ayant pour schéma la juxtaposition de
ceux des relations R1 et R2 et pour tuples l'ensemble de ceux obtenus par concaténation des tuples
de R1 et de R2, et qui vérifient la condition C.
Si R1 ou R2 ou les deux sont vides, la relation qui résulte de la jointure est vide. En fait, la jointure
n’est rien d’autre qu’un produit cartésien suivi d’une sélection :

Exemple 2 : Soit les deux relations suivantes : Personne (nom, prénom, age) et Voiture (type,
marque, propriétaire).
Soit l'opération suivante : R = Jointure (Personne, Voiture, Personne.Nom=Voiture.Propriétaire) On

obtient alors la relation R composée des tuples suivants :
Remarque : La jointure est l'opération qui permet de rassembler les informations séparées entre
plusieurs tables et référencées par des clés étrangères.
3.3.La Division
La division est une opération portant sur deux relations R1 et R2, telles que le schéma de R2 est
strictement inclus dans celui de R1, qui génère une troisième relation regroupant toutes les parties
d’occurrences de la relation R1 qui sont associées à toutes les occurrences de la relation R2 ; on
la note R1 ÷ R2.
C’est à dire que la division de R1 par R2 a pour résultat R tel que R comporte le plus grand ensemble
possible de tuples qui concaténés à ceux de R2 donnent toujours un tuple de R1.
Remarque :
Autrement dit, la division de R1 par R2 (R1 ÷ R2) génère une relation qui regroupe tous les n-uplets
qui, concaténés à chacun des n-uplets de R2, donne toujours un n-uplet de R1.
La relation R2 ne peut pas être vide. Tous les attributs de R2 doivent être présents dans R1 et R1
doit posséder au moins un attribut de plus que R2 (inclusion stricte). Le résultat de la division est

une nouvelle relation qui a tous les attributs de R1 sans aucun de ceux de R2. Si R1 est vide, la
relation qui résulte de la division est vide.
Exemple 1 :
Exemple 2 :

Chapitre 4 :
Le langage SQL et administration des bases de don-
nées sous MYSQL
Voir la partie 2 du cours.

Cours Bases de Données Et Langage SQL - Partie 1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours Bases de Données Et Langage SQL - Partie 1

Transféré par

Droits d'auteur :

Formats disponibles

Cycle : BACHELOR

Bases de données et langage SQL

ANNEE ACADEMIQUE 2022-2023

Nom (s) et prénom (s) : DIFFOUO TAZO Evariste

Courriel : evaristetazo@gmail.com / ediffouo@parisformations.fr

Quotas horaire semestriel prévus : 32 heures

A la fin de ce cours l’étudiant doit être capable de :

1. Comprendre les concepts liés aux bases de données relationnelles et objets ;

DEROULEMENT DES EXERCICES ET CAS PRATIQUES

CHAPITRE I : Rappel des généralités sur les bases de données

- théorie des ensembles.

Table des matières

Proposé par : Ing. DIFFOUO TAZO Evariste 1

3. Contraintes d’intégrité référentielle .......................................................................................... 27

Proposé par : Ing. DIFFOUO TAZO Evariste 2

I. Analyse systémique de l’entreprise et les systèmes d’information

1. Analyse systémique de l’entreprise

Proposé par : Ing. DIFFOUO TAZO Evariste 3

La matière première manipulée en informatique est l’information. Celle-ci se présente sous

o La dimension temporelle : l’information doit être régulièrement mise à jour et surtout

L’information au sein d’une entreprise possède de multiples sources. Elles peuvent

Proposé par : Ing. DIFFOUO TAZO Evariste 4

L’information permet d'assurer la coordination des différents services qui composent

Un système est un ensemble d’éléments reliés entre eux en interactions dynamiques et

iii. Système d’information

En Management des systèmes d’information, un SI peut être de différents types :

- Manuel : c’est-à-dire qu’il repose sur l’utilisation du papier et du crayon ;

Lorsque nous parlerons de système d’information dans ce cours, nous ferons

Un système d’information peut être vu comme un ensemble organisé de ressources (Personnes,

3. Les principaux rôles, ressources et fonctions d’un système d’information

Proposé par : Ing. DIFFOUO TAZO Evariste 5

 L’automatisation des tâches : Le SI va permettre de détecter des dysfonctionnements in-

 La communication et la diffusion de l’information : Le SI va fournir des informations sur

3.2. Les fonctions d’un système d’information

Proposé par : Ing. DIFFOUO TAZO Evariste 6

II. Les bases de données

Proposé par : Ing. DIFFOUO TAZO Evariste 7

2. Les enjeux des bases de données

Proposé par : Ing. DIFFOUO TAZO Evariste 8

Ils sont aussi appelés bases de données décisionnelles (dataware houses)

III. Les systèmes de gestion des bases de données (SGBD)

Proposé par : Ing. DIFFOUO TAZO Evariste 9

2. Les Niveaux de description des données

Proposé par : Ing. DIFFOUO TAZO Evariste 10

3. Quelques SGBD connus et utilisés

4. Définition et objectifs des SGBD

Proposé par : Ing. DIFFOUO TAZO Evariste 11

Proposé par : Ing. DIFFOUO TAZO Evariste 12

Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement

I. Le modèle Entité Association

Proposé par : Ing. DIFFOUO TAZO Evariste 13

- Au niveau organisationnel, le modèle organisationnel de traitements (MOT) décrit

- Au niveau logique, le modèle logique de données (MLD) fournit une description

Proposé par : Ing. DIFFOUO TAZO Evariste 14

2. Éléments constitutifs du modèle entités-associations

Proposé par : Ing. DIFFOUO TAZO Evariste 15

i. La propriété type ou l’attribut

Proposé par : Ing. DIFFOUO TAZO Evariste 16

Exemple de cardinalité sur une relation réflexive :

Proposé par : Ing. DIFFOUO TAZO Evariste 17

Exemple de cardinalité sur une relation binaire :

Exemples de cardinalité sur une relation ternaire :

Exemple de MCD complet

II. Normalisation des type-entités et type-associations