Premières Approches Et Définitions: 1.1. Bases de Données

Introduction aux Bases de Données Relationnelles
1. Premières approches et Définitions

1.1. Bases de Données
Une base de données peut être vue comme le besoin de mémoriser de façon durable des
données et de pouvoir exprimer le plus précisément possible les relations qu’entretiennent
ces données.
Il est difficile de donner une définition exacte de la notion de base de données. Une
définition très générale pourrait être :
Un ensemble organisé d’informations avec un objectif commun.
Peu importe le support utilisé pour rassembler et stocker les données (papier, fichiers, etc.),
dès lors que des données sont rassemblées et stockées d’une manière organisée dans un but
spécifique, on parle de base de données.
Plus précisément On appelle base de données un ensemble structuré et organisé
permettant le stockage de grandes quantités d’informations. D’où la définition :
Une Base de données est un gros ensemble d’informations structurées mémorisées sur un
support permanent.
Cette organisation se fait suivant un modèle de conception ayant pour but de décrire de
façon formelle les données qui seront mémorisé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 de ces données.
Une fois cette représentation faite il est nécessaire d’associer des fonctionnalités
(programmes et des requêtes) à cette base de données afin de pouvoir l’exploiter le plus
facilement possible.
1.2. SGBD
On peut remarquer qu’une organisation consistant en un (ou plusieurs) fichier(s) stockés
sur mémoire secondaire est conforme à la définition d’une base de données. Un ensemble
de fichiers ne présentant qu’une complexité assez faible, il n’y aurait pas là matière à longue
dissertation. Malheureusement l’utilisation directe de fichiers soulève de très gros
problèmes :
• Lourdeur d’accès aux données. En pratique, pour chaque accès, même le plus
simples, il faudrait écrire un programme.
M.P. SECK –DBA Analyste Page 1

• Manque de sécurité. Si tout programmeur peut accéder directement aux fichiers, il

est impossible de garantir la sécurité et l’intégrité des données.
• Pas de contrôle de concurrence. Dans un environnement où plusieurs utilisateurs
accèdent aux mêmes fichiers, des problèmes de concurrence d’accès se posent.
D’où le recours à un logiciel chargé de gérer les fichiers constituant une base de données, de
prendre en charge les fonctionnalités de protection et de sécurité et de fournir les différents
types d’interface nécessaires à l’accès aux 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).
Un SGBD doit permettre l’ajout, la modification et la recherche de données. Un système
de gestion de bases de données héberge généralement plusieurs bases de données, qui sont
destinées à des logiciels ou des thématiques différents.
En particulier, une des tâches principales du SGBD est de masquer à l’utilisateur les
détails complexes et fastidieux liés à la gestion de fichiers. D’où la définition :
Un Système de Gestion de Bases de Données (SGBD) est un logiciel de haut niveau qui
permet de manipuler les informations stockées dans une base de données.
2. Objectifs des SGBD
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
Manipulation de Données (LMD). Il est crucial que ce langage permette d’obtenir des
réponses aux requê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.

Non redondance des données : Afin d’éviter les problèmes lors des mises à jour, chaque
donné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’inté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
données au même moment de manière transparente. Si ce problème est simple à résoudre
quand il s’agit uniquement d’interrogations et quand on est dans un contexte mono-
utilisateur, cela ne l’est plus quand il s’agit de modifications dans un contexte 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
autorisé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.
La réalisation de ces objectifs induit la réalisation d’un certain nombre de tâches par
le SGBD à différents niveaux :
– Niveau physiques : gestion sur mémoire secondaire (fichiers) des données, du schéma, des
index ; Partage de données et gestion de la concurrence d’accès ; Reprise sur pannes
(fiabilité) ; Distribution des données et interopérabilité (accès aux réseaux).
– Niveau logique : Définition de la structure de données : Langage de Description de
Données (LDD) ; Consultation et Mise à Jour des données : Langages de Requêtes (LR) et
Langage de Manipulation de Données (LMD) ; Gestion de la confidentialité (sécurité) ;
Maintien de l’intégrité ;

– Niveau externe : Vues ; Environnement de programmation (intégration avec un langage de

programmation); Interfaces conviviales et Langages de 4e Génération (L4G) ; Outils d’aides
(e.g. conception de schémas) ; Outils de saisie, d’impression d’états.
En résumé, un SGBD est destiné à gérer un gros volume d’informations, persistantes

(années) et fiables (protection sur pannes), partageables entre plusieurs utilisateurs et/ou
programmes et manipulées indépendamment de leur représentation physique.
3. Conception et Modèles
La conception d’un schéma correct est essentielle pour le développement d’une
application viable. Dans la mesure où la base de données est le fondement de tout le
système, une erreur pendant sa conception est difficilement récupérable par la suite. Une ou
plusieurs modélisations intermédiaires sont donc utiles (une telle modélisation est appelée
Modèle Conceptuel de Données ou MCD), le modèle entité-association constitue l’une des
premières et des plus courantes. Ce modèle, présenté par Chen (1976), permet une
description naturelle du monde réel à partir des concepts d’entité et de relation. 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.
3.1. Le modèle Entité/Association
Le formalisme entité-association fait appel à trois concepts premiers, soit entité,
association, et attribut qui sont relatifs à la sémantique des données et trois concepts
accessoires, identifiant occurrence et multiplicité, pour l’expression des contraintes
d’intégrité des données du modèle .
3.1.1. Entités
Il est difficile de donner une définition très précise des entités. Les points essentiels
sont résumés ci-dessous.
Définition entité1 : On désigne par entité tout objet identifiable et pertinent pour
l’application
Définition entité 2 : Une entité est un objet, une chose concrète ou abstraite qui peut être
reconnue distinctement et qui est caractérisée par son unicité.

Définition entité 3 : Une entité est un regroupement homogène d’information, d’intérêt pour
le domaine
Définition entité 4 : Une entité est la représentation d'un élément matériel ou immatériel ayant un
rôle dans le système que l'on désire décrire.
Exemples d’entité : Jean Dupont, Pierre Bertrand, un livre que je tiens entre les mains, etc.
Les entités ne sont généralement pas représentées graphiquement.
Une entité concrète possède une existence physique c’est le cas d’un client, d’un
équipement, d’un produit par exemple. Une entité abstraite a une existence conceptuelle,
par exemple une transaction, un tarif, l’annulation d’un vol d’avion. Le client Jean Dupond
est une entité, la commande COM0001 est aussi une entité, la première concrète, l’autre
abstraite. Bien qu’une commande puisse prendre la forme d’un document papier, ce qui
intéresse le modélisateur c’est l’aspect conceptuel de la transaction car elle peut ne pas
exister sur papier .Elle sera donc considérée avant tout comme un objet abstrait.
On appelle classe d'entité ou type-entité un ensemble composé d'entités de même type,

c'est-à-dire dont la définition est la même. Le classement des entités au sein d'une classe
s'appelle classification (ou abstraction). Une entité est une instanciation de la classe. On
parle encore d’occurrence d’entité pour désigner un élément particulier d’une entité type,
identifiable de façon unique. Chaque entité est composée de propriétés, données
élémentaires permettant de la décrire.
Prenons par exemple une Ford Fiesta, une Renault Laguna et une Peugeot 306. Il s'agit de 3
entités faisant partie d'une classe d'entité que l'on pourrait appeler voiture. La Ford Fiesta
est donc une instanciation de la classe voiture. Chaque entité peut posséder les propriétés
couleur, année et modèle.

3.1.2. Attribut
Les entités sont caractérisées par des propriétés :l’âge (d’une personne), sa date de
naissance, l’adresse, la marque (de voiture), le code d’un fournisseur, le numéro d’un produit
etc. Ces propriétés sont dénotées attributs dans la terminologie du modèle E/A.
Il n’est pas question de donner exhaustivement toutes les propriétés d’une entité. On
ne garde que celles utiles pour l’application.
Un attribut est désigné par un nom et prend ses valeurs dans un domaine
énumérable comme les entiers, les chaînes de caractères, les dates, etc.
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, etc.). Au niveau de l’entité, chaque attribut possède une valeur
compatible avec son domaine.
3.1.3. Association
Une Association permet de décrire les liens "sémantiques" entre des entités, peut
être caractérisé par des attributs. Une association est un lien entre plusieurs entités. Elle
représente souvent la mémoire d’un événement qui a permis d’établir un lien logique entre
ces entités. Tout comme une entité appartient à une entité type, une association appartient
à une association type. Les associations de ce type-association lient des entités de ces types-
entités.
Comme les types-entités, les types-associations sont définis à l’aide d’attributs qui
prennent leur valeur dans les associations. 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.

3.1.3.1. Exemples
Exemples de type-association : l’emprunt de livre à la bibliothèque.
Elèves
Livres
Lien « emprunt »
•
Marie
• Seigneur des Anneaux
• Discours de la méthode
• Une si longue lettre
• • Le pouvoir de la volonté
Nabou • L’intelligence
émotionnelle
Association entre deux ensembles. (Association binaire)
Nous avons encore une autre représentation de cette association celle proposée par la
méthode MERISE.
Elèves Livres
Emprunte
Num_Elève Num_Livre
Date_emprunt
Nom Titre
Prènom Autre
Exemple de représentation graphique d’un type-association liant deux types-entités

Le modèle de la figure ci-dessus est une représentation abstraite qui, par analogie, pourrait
correspondre intuitivement à deux bacs de fiches, le premier portant le nom Client et l’autre
le nom Commande .Certaines fiches du bac Client sont reliées à des fiches du bac
Commande par une ficelle.

3.1.3.2. Typologie des associations
Un type association peut être :
• récursif (ou réflexif) : relie la même classe d'entité :

Exemple
Employé
Supervise
Num_Employé
Nom
Prénom
Exemple d’association réflexif
Une telle association met en cause des occurrences de la même entité.

• Binaire : relie deux classes d'entité
Elèves Livres
Emprunte
Num_Elève Num_Livre
Date_emprunt
Nom Titre
Prénom Autre
Exemple de représentation graphique d’un type-association liant deux types-entités
• Ternaire : relie trois classes d'entité

Imaginons par exemple qu’un internaute soit amené à noter à plusieurs reprises un film, et
que l’on souhaite conserver ’historique de ces notations successives. Pour distinguer des
liens multiples entre deux mêmes entités (Ici Internautes et Films). Le seul moyen pour
effectuer une telle distinction est d’introduire une entité discriminante, par exemple la date
de la notation. On obtient alors une association ternaire dans laquelle on a ajouté un type
d’entité Date (exemple tiré du cours de Base de données de Rigaux)
Exemple d’association ternaire

Ajout d’une entité Date pour conserver l’historique des notations
Même si cette solution est correcte, elle présente l’inconvénient d’introduire une entité
assez artificielle, Date, qui porte peu d’information et vient alourdir le schéma. En pratique
on s’autorise une notation abrégée en ajoutant un attribut date dans l’association. (nous y
reviendons)
Internautes Date Films
Note
Notation abrégée d’une association avec un type d’entité Date

Un autre exemple avec les associations ternaires
Enseignant
Num_Enseignant
Nom
Enseigne
Matière
Classe
Code_Matière Nom_Classe
Désignation
Exemple d’association ternaire
• formalisme mathématique :
Une association binaire entre les ensembles d’entités E1 et E2 est un ensemble de

couples (e1, e2) appartenant à E1 x E2
Une association n-aire entre les ensemble d’entité E1, E2,….En est un ensemble de
n-uplet (e1,e2,…,en) appartenant à E1 x E2 x …..xEn
Une occurrence d’une association d’occurrences d’entités différentes est appelée un couple
pour deux entités, un triplet pour trois et en général s’il s’agit de n entités on parlera d’un
tuple. La notion de tuple est un concept mathématique faisant référence précisément à
une association de divers objets provenant de domaines différents

3.1.4. Notion de clés
Définition clé 1 : Une Clé d’un type-entité ou d’un type-association est un identifiant
constitué par un ou plusieurs de ses attributs qui doivent avoir une valeur unique pour
chaque entité ou association de ce type.
Exemples d’identifiant : le numéro d’immatriculation d’une voiture, le code ISBN d’un livre
pour un livre (pas pour un exemplaire).
Chaque type-entité possède au moins un identifiant, éventuellement formé de plusieurs

attributs. Chaque type-entité possède au moins un attribut qui, s’il est seul, est donc
forcément l’identifiant.
L’identifiant, qu’il soit explicite ou non, d’un type-association doit être la concaténation des
identifiants des types-entités liés. On admet cependant un identifiant plus naturel, à
condition qu’il ne soit qu’un moyen d’exprimer plus simplement cette concaténation.
Définition clé 2 : Soit E un type d’entité et A l’ensemble des attributs de E. Une clé de E est
un sous ensemble de A permettant d’identifier de manière unique un entité parmi n’importe
quelle extention de E.
Exemple : Le type-entité VOITURE : VOITURE(immat#, chassis#, type, marque, puissance)
admet immat# et chassis# comme clés.
Il est possible d’avoir plusieurs clés pour un même ensemble d’entités. Dans ce cas on en
choisit une comme clé primaire, et les autres comme clés secondaires. Le choix de la clé
(primaire) est déterminant pour la qualité du schéma de la base d’information.
Dans la situation, fréquente, où on a du mal à déterminer quelle est la clé d’une entité, on
crée un identifiant exemple RefProduit pour le type-entité PRODUIT.
Définition clé 3 : La clé d’une association (binaire) entre un type d’entité E1 et un type
d’entité E2 est le couple constitué de la clé de E1 et de la clé de E2.

3.1.5. Les cardinalités
Les associations sont caractérisées par des cardinalités. Le terme cardinalité traduit la
participation des occurrences de type-entité à une association.
Définition Soit une association (E1, E2) entre deux types d’entités. La cardinalité de l’as-
sociation pour Ei, i∈ {1 ; 2} est une paire [min, max] telle que :
• Le symbole max (cardinalité maximale) désigne le nombre maximal de fois où une

entité ei de E1 peut intervenir dans l’association.
• Le symbole min (cardinalité minimale) désigne le nombre minimal de fois où une
entité ei de Ei peut intervenir dans la relation.
La cardinalité minimale doit être inférieure ou égale à la cardinalité maximale.
Exemple de cardinalité : une personne peut être propriétaire de 0 à n appartements, un

appartement peut avoir de 1 à n propriétaires.
0-n 1-n
PERSONNE propriétaire APPARTEMENT
Représentation graphique d’une cardinalité
La cardinalité minimale peut-être :
– 0 : Cela signifie qu’une entité peut exister tout en étant impliquée dans aucune
association.
– 1 :Cela signifie qu’une entité ne peut exister que si elle est impliquée dans aumoins une
association.
– n : Cela signifie qu’une entité ne peut exister que si elle est impliquée dans plusieurs
associations.
Attention, le cas n est rare et pose problème. Il est prudent de l’éviter.
La cardinalité maximale peut-être :

– 0 : Cela signifie qu’une entité ne peut pas être impliquée dans une association. En toute
logique, le cas 0 ne doit pas exister : il démontre un problème de conception puisque le
type-entité est inutile au type-association. Il faut alors reconsidérer la cardinalité ou retirer
la liaison entre le type-entité et le type-association.
Autres Exemples :
0-1 1-1
PERSONNE reçoit FEUILLEIMPÔT
0-n 0-1
PERSONNE propriétaire VOITURE
1-n 0-n
CLIENT commande PRODUIT
Les cardinalités et le choix des clés font vraiment partie des aspects décisifs des choix de conception.
Nous noterons que les associations permettent de décrire les liens "sémantiques" entre des entités,
peuvent être caractérisées par des attributs.
Dans une association binaire, la multiplicité la plus près de l’entité indique combien d’occurrences
de cette entité peuvent être associées à une occurrence de l’autre entité.
Dans le cas d’une association de degré supérieur n, la multiplicité près d’une entité indique combien
d’occurrences de cette entité peuvent être associées à une combinaison mettant en cause une
occurrence de chacune des n–1 autres entités.
Exemple :
Supposons une société aérienne où il est stipulé qu’une réservation comporte des vols et des tarifs.
Pour la compréhension du domaine, précisons qu’une réservation peut comporter plusieurs vols
différents, par exemple Québec-Montréal, Montréal-Paris, Paris-Toronto, Toronto-Québec. Sur
chaque vol de la réservation, un tarif est appliqué et celui-ci peut varier d’un vol à l’autre Un tarif
est identifié par un code qui précise les conditions rattachées au prix du billet .Par exemple le tarif

YHJLI pourrait avoir comme conditions: classe économique, non remboursable, payé 30 jours avant le
départ
(notation UML)
Transformation en Association binaire

Les multiplicités sont déterminées en considérant chaque entité de l’association à tour de rôle.
Transformation en Association binaire

3.1.6. Notion d’entité faible
Jusqu’à présent nous avons considéré le cas d’entités indépendantes les unes des autres.
Chaque entité, disposant de son propre identifiant, pouvait être considérée isolément. Il
existe des cas où une entité ne peut exister qu’en étroite association avec une autre, et est
identifiée relativement à cette autre entité. On parle alors d’entité faible.
L’entité faible est sans identifiant propre et n’existe qu’en référence à une autre entité dite
Identifiante. L’association qui les unit est dite association identifiante. L’entité faible a une
cardinalité 1-1 sur son association identifiante.
1-n 1-1
OUVRAGE avoir EXEMPLAIRE
Même si modèle E/A se veut d’être simple et suffisamment puissant pour représenter des
structures relationnelles et de répondre à l’objectif d’indépendance données-programmes,
il souffre également de nombreuses insuffisances : la principale est de ne proposer que
des structures. Il n’existe pas d’opération permettant de manipuler les données, et pas (ou
peu) de moyen d’exprimer des contraintes. Un autre inconvénient du modèle E/A est de
mener à certaines ambiguités pour des schémas complexes.
3.2. Le modèle relationnel
Le modèle relationnel procède à la transformation et au raffinement des résultats du

modèle Entité\Association pour ainsi définir un ensemble d’informations structurées,
préparer les données à être directement manipulée et acceptée par un système
informatique.
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, compression, …) 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.
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 relations, dont les lignes sont appelées n-uplet ou tuple en anglais ;
• 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é.
Le modèle relationnel représente l'information dans une collection de relations :
• une relation est une table à double entrée

• chaque ligne de la table (appelée nuplet ou tuple) peut être vue comme un fait
décrivant une entité du monde
• une colonne de la table est appelée un attribut.
A chaque relation est associée une clé (attribut souligné) qui l’identifie de manière unique.
C’est une notion centrale, proche encore de son origine de clé d’accès à un enregistrement.
Ce formalisme sert de base à nombre de systèmes de gestion de base de données, dits
relationnels.

3.2.1. schéma de relation

Le concepteur d’une BD relationnelle doit élaborer ce qu’il est convenu d’appeler le schéma
relationnel de la base de données.
On parlera de schéma de relation pour préciser le nom de la relation ainsi que la liste des
attributs avec leurs domaines.
• Attributs
Les attributs nomment les colonnes d’une relation. Ils servent à la fois à indiquer le
contenu de cette colonne, et à la référencer quand on effectue des opérations. Un
attribut est toujours associé à un domaine présentant certaines caractéristiques
commune surtout sémantique..
• Domaine
Le domaine d’une donnée est l’ensemble des valeurs que peut prendre cette donnée.
Pour un attribut donné, chaque domaine regroupe donc des les valeurs considérées
comme « légales ». Ainsi, le montant des achats effectués doit il être un nombre réel, et
être exprimé dans une monnaie nationale, le domaine des dates de naissance peut être
distinct de celui des dates d’entrée en activité et celles-ci ne devrait pas être
antérieures à la date de création de l’Entreprise.
Le domaine d’un attribut est l’ensemble, fini ou infini, de ses valeurs possibles. Par exemple,
l’attribut nom a pour domaine l’ensemble des combinaisons de lettres (une combinaison
comme cette dernière est généralement appelée chaîne de caractères ou, plus simplement,
chaîne). L’attribut âge a pour domaine l’ensemble des entiers naturels {1 ;2 ;….}
Il peut être :
- étendu: il correspond alors au type d’une donnée : Numérique, alphabétique, etc.
- restreint: on l’exprime alors au moyen d’une liste ou d’un intervalle. Par exemple, pour la
rubrique « Sexe », le domaine sera la liste de valeurs « F », « M ».

Exemples 1 : schéma de la relation personne

Attribut
N° Nom Prénom Age
tuple D43T Diagne Sidy 19
D24 Lô Moussa 21
S274 Cissé Nathalie 19
Y743 Faye André 20
Exemples 2 : schéma de la relation Employé

• Clé
A toute relation correspond une clé, simple ou composée, qui repère les différents
tuples. Aucun tuple ne peut avoir une clé ayant une valeur identique à celle d’un autre
tuple. Cette clé est obtenue par la combinaison d’un ou de plusieurs attributs. Cette
notion de clé est strictement identique à la notion d’identifiant.
Une clé sera dite :
• Principale si elle sert effectivement à repérer des tuples ;

• Candidate si ses qualités sont telles qu’elle pourrait repérer un tuple de manière
alternative à la clé principale. Il en sera ainsi du nom du client dans la relation client
par exemple ;
• étrangère lorsqu’ elle est clé principale dans une autre relation.
Les relations du schéma doivent toutes posséder les propriétés suivantes:

• Une relation a un nom distinct de toutes les autres du même schéma
• Chaque attribut d’une relation ne peut recevoir qu’une seule valeur atomique (type
de données simple)
• Chaque attribut a un nom distinct
• Les valeurs d’un attribut font toutes partie du même domaine: même type de
données et même contraintes d’intégrité
• Chaque tuple de la relation est distinct; pas de tuple en double
• L’ordre des tuples n’a pas d’importance
• L’ordre des attributs n’a pas d’importance
3.2.2. Formalisme de schéma de relation

Un schéma de relation R est simplement un nom suivi de la liste des attributs, chaque
attribut étant associé à son domaine. La syntaxe est donc :
R(A1 :D1,A2 :D2,……,An :Dn)
où les Ai sont les noms d’attributs et les Di les domaines. L’arité d’une relation est le
nombre de ses attributs.

On peut trouver dans un schéma de relation plusieurs fois le même domaine, mais une seule
fois un nom d’attribut. Le domaine peut être omis en phase de définition.
Exemple :
Dans une université les étudiants suivent différentes UV. Chacune d’elles est assurée par
différents enseignants chacun d’eux pouvant en assurer plusieurs. De plus chaque UV peut
être dans différentes salles. La modélisation correspondante en relationnel est donc :
ETUDIANT (N°_Etudiant, Nom_etudiant, Adresse_etudiant)
ENSEIGNANT (N°_Enseignant, Nom_Eseignant)
UV (N°_UV, Titre_UV, N°_Enseignant)
INSCRIPTION (N°_Etudiant, N°_UV, Note)
Plusieurs points sont à noter :
-L’attribut clé de la relation est par convention souligné.
-Dans la relation UV apparaît la clé étrangère N°_Enseignant qui permet de traduire le lien
avec la relation ENSEIGNANT.
-La relation INSCRIPTION a une clé principale composée pour pouvoir traduire l’association
de type m :n entre les relations ETUDIANT et UV.
Les liens entre les relations ne sont pas exprimés physiquement. Pour pouvoir mettre les
données en relation ce modèle propose des opérateurs qui permettront d’exprimer des
requêtes ainsi que des transactions.
3.2.3. Opérateurs relationnels
Un des grands attraits du modèle relationnel est d’intégrer des opérateurs très puissants
permettant d’exprimer des manipulations ensemblistes sur les données ne faisant pas appel
à un cheminement explicite (exploration de données) dans la base de données.
Ces opérateur sont au nombre de huit et comprennent :
• La selection

• La projection
• Le produit cartésien
• L’union
• L’intersection
• La différence
• La jointure
• La division
Ces opérateurs sont à la base de langages dits algébriques.
3.3. Règle de passage du modèle E\A au modèle relationnel
Il s’agit de transformer le modèle Entité\Association en un modèle relationnel en suivant un certain

nombre de règles :
Règle 1 : Toute entité devient une relation. L’identifiant de l’entité devient clé primaire de la relation.
• On crée une relation de même nom que l’entité.

• Chaque propriété de l’entité, y compris l’identifiant, devient un attribut de la relation.
• Les attributs de l’identifiant constituent la clé de la relation
Autrement dit : Chaque type-entité du modèle conceptuel devient une table dans le modèle logique.
Les identifiants de la classe d'entité sont appelé clés de la table, tandis que les attributs standard
deviennent des attributs de la table, c'est-à-dire des colonnes.
Exemple : PERSONNE (ID_Pers,nom,prénom,âge) dans le modèle conceptuel nous obtenons dans le

modèle logique :
Relation PERSONNE :
ID_Pers nom prénom âge

Règle 2 : Toute entité reliée par des associations de type 1 :1, les tables doivent avoir la même clé
PERSONNE FEUILLEIMPÔT
0-1 1-1
Reçoit
No_sécu No_feuille
Nom Date_édition
Prénom montant
PERSONNE FEUILLEIMPÔT
Ou
No_sécu No_feuille
N°_feuille N°_sécu
Nom Date_édition
Règle 3 : Dans le cas des entités reliées par des association de type 1 :n chaque table possède sa
propre clé, mais la clé de l’entité côté 1,n (ou 0,n) migre vers la table côté 1,1 (ou 1,1) et devient une
clé étrangère.

CLIENT COMMANDE
1-n 1-1
Reçoit
Code_Client No_Commande
Nom Date
Prénom montant
CLIENT COMMANDE
No_Client No_Commande
Nom Date
Prènom No_Client
Règle 4 : Toute association de type (m-n) devient une relation qui hérite des identifiants des entités
participants à la relation. Si l’association est porteuse, la relation sera complétée par la liste des
propriétés portées.

COMMANDE PRODUIT
1-n 0-n
Se compose de
No_Commande RefProduit
Date libelle
montant PU
COMMANDE PRODUIT
1-n 0-n
Se compose de
No_Commande RefProduit
Date libelle
montant PU
Ligne -Commande
Propriété
portée No_Commande
RefProduit
Qte
Si l’association n’est pas porteuse, la relation ne contiendra que les clés des entités

Exemple :
ACTEUR FILM
0-n 1-n
joue
No_Acteur RefFilm
nom titre
prénom genre
ACTEUR FILM
No_Acteur RefFilm
nom titre
prénom genre
TOURNAGE
RefFilm
No_Acteur

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.
Exemple 1 :
Par exemple, le type-entité Date de la figure ci dessus ne doit pas se traduire par une
relation. Le schéma relationnel adéquat correspondant au modèle entités-associations de
cette figure est donc :
• Exemplaire(Num-Exemplaire, date-achat)
• Personne(Num-Personne, nom, prénom, adresse)
• Emprunter(Num-Exemplaire, Num-Personne, Date, date-retour)

Exemple 2:
Comme exemple d’application, voici les relations déduites du schéma entités-associations

de la figure ci dessus :
• 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ée-Hospitalisation)
Un des grands avantages du modèle relationnel est sa très grande simplicité. Il n’existe en effet
qu’une seule structure, la relation. Une relation peut simplement être représentée sous forme de
table. Cependant l’élaboration du schéma se heurte parfois à certaines contraintes liées à la
redondance, ou aux incohérences ou à la perte d’information.

Exemple : Relation produit
RefProduit Désignation PU Quantité Dep_ID Ville
P1 CD 100 350 1 Dakar
P1 CD 100 700 2 Thiès
P3 K7 250 900 4 Kaolack
Dans cette relation nous pouvons noter :
• une redondance : Désignation et pu apparaissent pour chaque instance d'un produit

• Un risque d'introduction d'incohérence lors de l'insertion d'une nouvelle instance de p1
• Un risque de perte d'information : la suppression du produit p3 entraîne la perte de son
Désignation, de son prix unitaire et des information relatives au dépôt 4.
Deux solutions sont envisageables :
– Transformer les relations dangereuses en plusieurs relations pertinentes, puis établir les
dépendances fonctionnelles, ensuite normaliser
– Se poser la question avant d’écrire les schémas de relations : schéma entités/associations (E/A),
puis transformation en relationnel.
4. Normalisation
L’exigence de relations normalisées pour la cohérence d’une Base de Données relationnelle

est fondamentale. Un schéma relationnel normalisé doit répondre aux exigences minimales
suivantes:
• Non redondance : un attribut n’appartient qu’à une seule relation, donc à une seule table,
à moins qu’il n’agisse comme clé étrangère pour assurer l’association avec une autre table;
• Cohérence : les attributs qui décrivent le même objet appartiennent à la même table et
dépendent chacun fonctionnellement et totalement de la clé primaire de la table.

Pour assurer l’exigence de cohérence, chaque table doit répondre à trois propriétés de base
appelées les trois formes normales. Les formes normales sont différents stades de qualité
qui permettent d’éviter des anomalies dans les bases de données relationnelles et
représentent l’état des tables relationnelles en fonction de leurs dépendances
fonctionnelles.
4.1. Dépendances fonctionnelles

• Définition :
Un attribut ou une liste d'attributs Y dépend fonctionnellement d'un attribut ou
d'une liste d'attributs X dans une relation R, si étant donnée une valeur de X, il ne
lui est associé qu'une seule valeur de Y dans toute instance de R.
On note X Y une telle dépendance.
Exemples :
Reprenons l’exemple ci-dessus :
Relation produit
RefProduit Désignation PU Quantité Dep_ID Ville Volume
P1 CD 100 350 1 Dakar 90000
P1 CD 100 700 2 Thiès 60000
P3 K7 250 900 4 Kaolack 2000
RefProduit → Désignaaon
RefProduit → pu
dep_id → adr, volume
RefProduit, dep_id → qte

• Propriétes
Soit U la liste des attributs de R, on a alors les propriétés :
(F1) Réflexivité : Y ⊆ X et X ⊆ U alors X Y
(F2) Augmentation : X Y alors X ∪ Z Y

Y∪Z
(F3) Transitivité : X Y et Y Z alors X Z
(F4) Union : X Y et X Z alors X Y ∪ Z
(F5) Pseudo-transitivité : X Y et Y ∪ W Z alors X ∪ Z Z
(F6) Décomposition : X Y et Z ⊆ Y alors X Z
• Typologie des dépendances fonctionnelles :
Définition 2 : Une dépendance X Y est triviale si Y ⊆ X
Définition 3 : Une dépendance X Y élémentaire si pour tout X' ⊂ X, la dépendance fonctionnelle

n'est pas vraie (Y ne dépend pas fonctionnellement d'une partie de X)
Exemple :
CODE_CLIENT, NOM_CLIENT → ADRESSE_CLIENT n’est pas élémentaire puisque
CODE_CLIENT → ADRESSE_CLIENT
Définition 4 : Une dépendance X Y directe si elle est élémentaire et si Y ne dépend pas

transitivement de X
Exemple :
RefProduit Désignation PU Quantité Dep_ID Ville Volume
P1 CD 100 350 1 Dakar 90000
P1 CD 100 700 2 Thiès 60000
P3 K7 250 900 4 Kaolack 2000

RefProduit → pu est élémentaire, mais elle est transitve car RefProduit → Désignaaon et
Désignation → pu, donc n’est directe.
Pour les redondances, on devra veiller à ce que toute dépendance fonctionnelle entre la
propriété identifiante de l’entité et une propriété non identifiante de l’entité soit directe.
4.2. Les formes normales

• Première forme normale :
Une relation est en première forme normale 1NF) si, et seulement si, tout attribut contient
une valeur. Autrement dit, Une relation est en première forme normale si, et seulement si,
tout attribut contient une valeur atomique (non multiples, non composées).
Exemple :
Personne (id, nom, les_diplômes) où les_diplômes est l'ensemble des diplômes obtenus par
une personne n'est pas en 1NF
Personne(id, nom) est en 1NF
Diplôme(id, unDiplome) est en 1NF.
• Deuxième forme normale

Une relation est en deuxième forme normale (2NF) si, et seulement si, elle est en première
forme normale et si tout attribut n’appartenant pas à une clé ne dépend pas d’une partie de
cette clé.
De manière équivalente, on dit qu’une relation est en deuxième forme normale si, et
seulement si, elle est en première forme normale et si toutes les dépendances fonctionnelles
entre la clé et les autres attributs sont élémentaires
Exemple :
Stock(prod_id, dep_id, libellé, qte) n'est pas en 2NF car
prod_id, dep_id → qte et prod_id → libellé

Stock(prod_id, dep_id, qte) est en 2NF
Produit(prod_id, libellé) est en 2NF
Autre exemple :
Supposons la table suivante représentant des modèles génériques de télévisions construites
par différents fabricants. La marque et le modèle permettent d’identifier de façon unique
chaque sorte de télévision. Le mode sonore ainsi que la résolution sont spécifiques au
modèle et non à la marque.
TÉLÉVISION (Marque, Modèle, ModeSon, Résolution)
Il y a donc une DF entre "Modèle" et "ModeSon", ainsi qu’entre "Modèle" et "Résolution"
Il faudra donc diviser cette table en deux de la façon suivante :
TÉLÉVISION (Marque, Modèle)
MODÈLETV (Modèle, ModeSon, Résolution)
• Troisième forme normale

Une relation est en troisième forme normale si, et seulement si, elle est en deuxième forme
normale et si tout attribut n’appartenant pas à une clé ne dépend pas d’un attribut non clé.
De manière équivalente, on dit qu’une relation est en troisième forme normale si, et
seulement si, elle est en deuxième forme normale et si toutes les dépendances
fonctionnelles entre la clé et les autres attributs sont élémentaires et directes.
Exemple : Relation Avion
N°avion constructeur type capacité propriétaire
AH32 Boeing B747 C1 Air France
FM34 Airbus A320 C2 Africa Airways
BA45 Boeing B747 C1 Air Sénégal
La relation n'est pas en 3NF car type → capacité, constructeur et type n'est pas une clé

Avion(no_avion, type, propriétaire) est en 3NF
Modèle(type, constructeur, capacité) est en 3NF.
Autre exemple :
Dans le cas des voitures usagées, toutes les voitures de la même année sont vendues au même prix.
VOITURE (NoStock, Marque, Modèle, Année, Couleur, Prix, TélFabricant)
Il y a donc une DF entre "Année" et "Prix", ce qui signifie que cette table n’est pas en
3FN. Il faut donc décomposer cette table en deux.
VOITURE (NoStock, Marque, Modèle, Année, Couleur, TélFabricant)
PRIXVENTE (Année, Prix).
• Forme normale de BOYCE-CODD

Boyce and Codd (BCNF) : "une relation R est en BCNF si les seules dépendances
fonctionnelles élémentaires qu'elle comporte sont celles où une clé détermine un attribut"
code_ville(code, ville) et
code_rue(code, rue) sont en BCNF.
Autre exemple :
CLAVIER (MarqueClavier, NombreTouches, TypeClavier)
Supposons qu’il y a une DF entre le type de clavier et le nombre de touches. Il faut donc
diviser en deux tables de la façon suivante :
CLAVIER (MarqueClavier, TypeClavier)
TOUCHES (TypeClavier, NombreTouches)

5. L’Algèbre relationnelle
Le modèle relationnel a été à l'origine proposé avec deux LMD de base, l'algèbre
relationnelle et le calcul des tuples. A partir de ces deux langages, d'autres LMD ont pu
être définis, qui sont plus conviviaux pour les utilisateurs, et qui ont au moins la même
puissance d’expression que l'algèbre ou le calcul.
SQL qui est le LMD relationnel le plus répandu du fait que c'est la seule norme existante
pour les LMD relationnels, comporte des caractéristiques de type algébrique et d'autres
de type prédicatif.
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 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.
5.1. La sélection
Cet opérateur construit une relation résultat où n'apparaissent que certains tuples de la
relation opérande (en termes de tableau, cela revient à extraire certaines lignes). Les
tuples retenus sont ceux satisfaisant une condition explicite, appelée prédicat de
sélection.
Soit R (A1, A2, ...., An) une relation, la sélection de R selon un prédicat p, notée:
σ [p] R crée une nouvelle relation, temporaire, de schéma identique à celui de R, et de
population l'ensemble des tuples de R pour lesquels le prédicat p est vrai, c'est-à-dire,
regroupant exclusivement toutes les occurrences de la relation R qui satisfont l’expression logique
E, on la note σ(p)R.

Exemple :
Soit la relation
Personne ( nom , prénom , jour-nais , mois-nais , an-nais , sexe)
Pour créer une relation Femmes contenant l'ensemble des personnes de sexe féminin,
on écrira:
Femmes := σ [sexe = 'F'] Personne
ce qui donne en résultat :
Femmes ( nom, prénom , jour-nais , mois-nais , an-nais , sexe)
On obtient la liste des hommes nés avant 1975 par l’expression :

H := σ [sexe = 'M' ∧ an-nais < 75] Personne
ce qui donne en résultat :
H ( nom, prénom , jour-nais , mois-nais , an-nais , sexe)

5.2. La projection
Cet opérateur construit une relation résultat où n'apparaissent que certains attributs de la
relation opérande (en termes de tableau, cela revient à extraire certaines colonnes).
Soit R (A1, A2, ...., An) une relation, et soit Ai1, Ai2, ....., Aij un sous-ensemble de ses attributs,
la projection de R sur Ai1, Ai2, ....., Aij, notée :
π[Ai1, Ai2, ....., Aij] R
crée une nouvelle relation, temporaire, de schéma (Ai1, Ai2, ....., Aij) et de population
égale à l'ensemble des tuples de R "tronqués à Ai1, Ai2, ....., Aij ", i.e. :
{t / ∃r (r∈ R ∧ t.Ai1 = r.Ai1 ∧ t.Ai2 = r.Ai2 ∧ .... ∧ t.Aij = r.Aij)}
Exemple : soit la relation
On construit l'ensemble des noms et prénoms des personnes avec l'opération:

NP := π[nom, prénom] Personne
On obtient :

L'opération : NA := π [nom, an-nais] Personne donnera en résultat :
Les opérateurs de l'algèbre peuvent être combinés dans des expressions pour exprimer des
requêtes non élémentaires.

Exemple:
On obtient la liste des noms et prénoms des hommes nés avant 1975 par l’expression :
H := π [nom, prénom] σ [sexe = 'M' ∧ an-nais < 75] Personne
Le même résultat pourrait être obtenu en écrivant deux opérations l'une après l'autre en
créant une relation intermédiaire (dans ce cas il faut nommer les relations intermédiaires):
H1 := σ [sexe = 'M' ∧ an-nais < 75] Personne
H := π [nom, prénom] H1
5.3. L’Union
Soient R et S deux relations de même schéma : R (A1, A2, …, An) , S (A1, A2, …, An).
L’Union R ∪ S crée une relation temporaire de même schéma et de population égale à
l'ensemble des tuples de R et de ceux de S (avec élimination des doubles éventuellement
créés).
L’Union R ∪ S réunit dans une même relation les tuples de R et ceux de S.
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).
5.4. L’Intersection
L’Intersection R ∩ S crée une relaaon temporaire de même schéma et de population égale à
l'ensemble des tuples de R qui ont un tuple de même valeur dans S.
L’intersection est une opération portant sur deux relations R1 et R2 ayant le même schéma et
construisant une troisième relation dont les n-uplets sont constitués de ceux appartenant aux
deux relations, on la note R1 ∩ R2.
Il s’agit une opération binaire ensembliste commutative.

5.5. La différence
La différence est une opération portant sur deux relations R1 et R2 ayant le même schéma
et construisant 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.
La différence : R1- R2 crée une relation temporaire de même schéma et de population

égale à l'ensemble des tuples de R1 moins ceux de R2, c'est à dire : les tuples qui se
trouvent dans R1 mais pas dans R2.

5.6. Le produit cartésien

Soient deux relations, R (A1, A2, …, An) et T (B1, B2, …, Bp), n'ayant pas d'attribut de même nom,
alors le produit de R par T, noté R × T, crée une relation temporaire de schéma (A1, A2, …, An, B1, B2,
…, Bp) et de population toutes les concaténations possibles de tuples de R et de T.

5.7. Les jointures

5.7.1. La thêta jointure
Soient deux relations R (A1, A2, …, An) et T (B1, B2, …, Bp) n'ayant pas d'attribut de même
nom, la thêta jointure de R et T selon le prédicat p, notée :
R *[p] T crée une nouvelle relation temporaire de schéma (A1, A2, …, An, B1, B2, …, Bp), et de
population égale à l'ensemble des tuples de R et de T concaténés qui satisfont le prédicat.
Une thêta-jointure est une jointure dans laquelle l’expression logique E est une simple
comparaison entre un attribut A1 de la relation R1 et un attribut A2 de la relation R2. La
theta-jointure est notée R1 ▷◁E R2

5.7.2. L’équijointure
Une équijointure est une thêta-jointure dans laquelle l’expression logique E est un test
d’égalité entre un attribut A1 de la relation R1 et un attribut A2 de la relation R2. L’equi-
jointure est notée R1 ▷◁A1,A2 R2.
Remarque : Il vaut mieux écrire R1 ▷◁A1=A2 R2 que R1 ▷◁A1,A2 R2 car cette dernière notation
peut prêter à confusion avec une jointure naturelle explicite
5.7.3. La jointure naturelle
Une jointure naturelle est une jointure dans laquelle l’expression logique E est un test
d’égalité entre les attributs qui portent le même nom dans les relations R1 et R2. Dans la
relation construite, ces attributs ne sont pas dupliqués mais fusionnés en une seule colonne
par couple d’attributs. La jointure naturelle est notée R1 ▷◁ R2. On peut préciser explicitement
les attributs communs à R1 et R2 sur lesquels porte la jointure : R1 ▷◁A1, …, An R2.
étant donné deux relations R(X, Y) et S(Y, Z), où X, Y, Z symbolisent soit un attribut, soit un
ensemble d'attributs, et où Y n'est pas vide, la jointure (naturelle) de R et S, notée :
R * S crée une nouvelle relation temporaire, de schéma (X, Y, Z). La population de R * S est
l'ensemble des tuples <x, y, z> créés par composition d'un tuple <x, y> de R et d'un tuple <y,
z> de S, tels que les deux tuples ont la même valeur pour Y.

Exemple:
5.8. La division
Soient deux relations R (A1, …, An) et V (A1, …, Af) et (f < n) telles que tous les attributs de V
sont aussi attributs de R, alors la division de R par V, notée :
R / V crée une nouvelle relation temporaire de schéma (Af+1, Af+2, …, An), et de population
égale aux tuples de R, tronqués à [Af+1, Af+2, …, An], et qui existent dans R concaténés à
tous les tuples de V, c'est-à-dire:
{<af+1, af+2, ..., an> / ∀ <a1, a2, ... af> ∈ V, ∃ <a1, a2, ... af, af+1, af+2, ..., an>∈R}
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.




Premières Approches Et Définitions: 1.1. Bases de Données

Transféré par

Informations du document

Titre original

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

Premières Approches Et Définitions: 1.1. Bases de Données

Transféré par

Droits d'auteur :

Formats disponibles

Introduction aux Bases de Données Relationnelles

1. Premières approches et Définitions

M.P. SECK –DBA Analyste Page 1

• Manque de sécurité. Si tout programmeur peut accéder directement aux fichiers, il

2. Objectifs des SGBD

M.P. SECK –DBA Analyste Page 2

M.P. SECK –DBA Analyste Page 3

– Niveau externe : Vues ; Environnement de programmation (intégration avec un langage de

En résumé, un SGBD est destiné à gérer un gros volume d’informations, persistantes

M.P. SECK –DBA Analyste Page 4

On appelle classe d'entité ou type-entité un ensemble composé d'entités de même type,

M.P. SECK –DBA Analyste Page 5

M.P. SECK –DBA Analyste Page 6

Exemples de type-association : l’emprunt de livre à la bibliothèque.

Association entre deux ensembles. (Association binaire)

Exemple de représentation graphique d’un type-association liant deux types-entités

M.P. SECK –DBA Analyste Page 7

M.P. SECK –DBA Analyste Page 8

3.1.3.2. Typologie des associations

Un type association peut être :

• récursif (ou réflexif) : relie la même classe d'entité :

Exemple d’association réflexif

Une telle association met en cause des occurrences de la même entité.

M.P. SECK –DBA Analyste Page 9

• Binaire : relie deux classes d'entité

Exemple de représentation graphique d’un type-association liant deux types-entités

• Ternaire : relie trois classes d'entité

Exemple d’association ternaire

M.P. SECK –DBA Analyste Page 10

Ajout d’une entité Date pour conserver l’historique des notations

Internautes Date Films

Notation abrégée d’une association avec un type d’entité Date

M.P. SECK –DBA Analyste Page 11

Un autre exemple avec les associations ternaires

Exemple d’association ternaire

Une association binaire entre les ensembles d’entités E1 et E2 est un ensemble de

n-uplet (e1,e2,…,en) appartenant à E1 x E2 x …..xEn

M.P. SECK –DBA Analyste Page 12

3.1.4. Notion de clés

Chaque type-entité possède au moins un identiﬁant, éventuellement formé de plusieurs

Exemple : Le type-entité VOITURE : VOITURE(immat#, chassis#, type, marque, puissance)

admet immat# et chassis# comme clés.

M.P. SECK –DBA Analyste Page 13

3.1.5. Les cardinalités

• Le symbole max (cardinalité maximale) désigne le nombre maximal de fois où une

La cardinalité minimale doit être inférieure ou égale à la cardinalité maximale.

Exemple de cardinalité : une personne peut être propriétaire de 0 à n appartements, un

Représentation graphique d’une cardinalité

La cardinalité minimale peut-être :

Attention, le cas n est rare et pose problème. Il est prudent de l’éviter.

La cardinalité maximale peut-être :

M.P. SECK –DBA Analyste Page 14

M.P. SECK –DBA Analyste Page 15

Transformation en Association binaire

M.P. SECK –DBA Analyste Page 16

Transformation en Association binaire

M.P. SECK –DBA Analyste Page 17

3.1.6. Notion d’entité faible

il souffre également de nombreuses insufﬁsances : la principale est de ne proposer que

3.2. Le modèle relationnel

Le modèle relationnel procède à la transformation et au raffinement des résultats du

M.P. SECK –DBA Analyste Page 18

Les objectifs du modèle relationnel sont :