CSGA Module 5 – Modélisation de l’information géographique

Rappel
Selon le cycle de vie en cascade classique, la conception d’une base de données passe par plusieurs
étapes selon le schéma suivant :

Monde réel

Dossier
d'analyse

Modéle
conceptuel
de données

Modéle
logique de
données

Base de
données

Monde réel : Correspond au domaine étudié et couvre le périmètre de votre projet et vos besoins en
terme de données.

Dossier d’analyse : Les besoins sont formalisés dans un dossier d’analyse (ou cahier de charge). On
peut utiliser des méthodes d’analyse formelles pour rédiger ce document.

Modèle conceptuel de données : Basé sur une modélisation de haut niveau, il permet la description
des données ainsi que leur structuration. Il existe plusieurs modèles concurrents, on peut citer parmi
les plus utilisés : le modèle entité-association et le diagramme de classes UML. Les modèles
conceptuels sont indépendants des contraintes informatiques (codage, stockage…), ce qui permet de
décrire les données indépendamment de leur future implémentation informatique.

Modèle logique de données : Ce modèle a été introduit avec l’apparition du paradigme base de
données. Son rôle est de décrire votre base de données selon un modèle assimilable par un Système
de Gestion de Base de Données (SGBD) . Il existe plusieurs modèles logiques de données, mais le plus
utilisé est le modèle relationnel puisque la plupart des SGBD du marché sont basés sur celui-ci.

Base de données : Correspond à l’implémentation physique de la base de données dans un SGBD en

prévision de son exploitation. On peut parler du Modèle physique de données. C’est le résultat final
du cycle de vie.

B. EL HATIMI 1/5 Modèle relationnel

CSGA Module 5 – Modélisation de l’information géographique

Le modele relationnel
Un Modèle Logique de Données (MLD) a pour rôle de décrire les données de la future base de
données dans un formalisme assimilable par le Système de Gestion des Bases de Données (SGBD)1.

Il existe plusieurs modèles logiques (hiérarchique, réseau…), mais le plus utilisé est le Modèle
Relationnel. On appelle Systèmes de Gestion de Bases de Données Relationnelles (SGBDR), les SGBD
qui utilisent le modèle relationnel, ce qui est le cas des principaux SGBD sur le marché. Oracle,
PostgreSQL ou Access de Microsoft sont des SGBDR. Ce modèle a été proposé par le britannique
Edgar CODD (1923 – 2003) dans un article paru en 1970.

Le modèle relationnel offre aux concepteurs des bases de données ce qu’on appelle un langage de
description de données (LDD). Un LDD décrit les objets qui constituent le schéma de la base de
données. A ce LDD va s’ajouter un langage de manipulation de données (LMD) dont le rôle est de
manipuler et d’interroger les informations stockées dans la base de données. Pour les SGBDR le LMD
utilisé est le langage SQL (Structured Query Language).

Notions de base
Le modèle relationnel est construit à partir de trois notions de base : le domaine de valeurs, La
relation (ou table) et l’attribut.

Domaine
Un domaine de valeurs est un ensemble de valeurs caractérisé par un nom. Ex : les domaines ENTIER,
REEL, BOOLEEN… On parle aussi de types de données.

Relation
Une relation, plus communément appelé une table, est défini comme le produit cartésien d’un
ensemble de domaines de valeurs, caractérisée par un nom. C’est l’objet de base du modèle
relationnel. Du fait de cette définition, une relation est assimilable à une table à deux dimensions
dont les colonnes sont les domaines du produit cartésien qu’on appellera des attributs et dont les
lignes sont les vecteurs de valeurs qu’on appellera des enregistrements.

Comme pour les entités dans le modèle entité-association, les relations (ou tables) vont modéliser
des objets pertinents, concrets ou abstraits, de la base de données.

Attribut
Un attribut (appelé aussi colonne) est une colonne de la relation vue comme une table à deux
dimensions.

Exemple
Soit la relation MONUMENT (REFERENCE : Chaîne de caractères, NOM : Chaîne de caractères, PAYS :
Chaîne de caractères)

1
SGBD : Logiciel de haut niveau en charge de la gestion et l’interrogation des bases de données. Ex : Oracle, MS
SQL Server, PostgreSQL, MySQL, MS Access…

B. EL HATIMI 2/5 Modèle relationnel

CSGA Module 5 – Modélisation de l’information géographique

Cette relation possède trois attributs auxquels sont associés les domaines de valeurs.

MONUMENT (REFERENCE : Chaîne de caractères, NOM : Chaîne de caractères, PAYS : Chaîne de

caractères) est la notation relationnel (LDD) de cette relation.

La représentation tabulaire de la relation permet de donner l’ensemble des enregistrements que

contient la relation MONUMENT. Ces enregistrements sont les données existantes à un instant t dans
la base de données. Dans cet exemple la table MONUMENT contient quatre enregistrements (lignes).

MONUMENT NOM PAYS

REF001 Tour Eiffel France
REF002 Tour Hassan Maroc
REF003 Grande Mosquée de Djenné Mali
REF004 Basilique Saint Marc Italie

Contraintes relationnelles
L’une des forces majeures du modèle relationnel est la définition de contraintes ou règles d’intégrité
que doivent respecter les valeurs des enregistrements dans la base de données.

Contrainte de domaine
Les valeurs d’un attribut dans une relation doivent appartenir au domaine de valeurs de l’attribut
considéré.

Contrainte de clé
Une clé est un ensemble minimum d’attributs d’une relation dont la connaissance des valeurs
permet de déterminer un enregistrement unique de la relation considérée. La clé d’une relation est
l’équivalent d’un identifiant d’entité.

Chaque relation du schéma doit avoir au moins une clé identifiée (on parlera de clé primaire). Elle
peut posséder d’autres clés qu’on appellera clés secondaires.

Dans l’exemple précédent, la clé de la relation MONUMENT est composé de l’attribut REFERENCE.
On soulignera les attributs constituant la clé primaire.

MONUMENT (REFERENCE : Chaîne de caractères, NOM : Chaîne de caractères, PAYS : Chaîne de

caractères)

Contrainte d’unicité
Si un attribut est défini avec une contrainte d’unicité, il ne peut pas y avoir dans la base de données
deux enregistrements différents ayant la même valeur pour l’attribut considéré.

Important ! Un attribut constituant la clé d’une relation doit respecter la contrainte d’unicité.

Attention ! L’unicité est une contrainte nécessaire mais pas suffisante pour définir une clé.

B. EL HATIMI 3/5 Modèle relationnel

CSGA Module 5 – Modélisation de l’information géographique

Contrainte de non-nullité
Le modèle relationnel introduit une valeur conventionnelle appelée valeur nulle (ou NULL). Cette
valeur nulle permet d’indiquer que pour un enregistrement donné, la valeur d’un attribut est soit
inconnue soit non applicable.

Définir un attribut avec une contrainte de non-nullité impose que tous les enregistrements de la
relation doivent avoir une valeur spécifiée pour l’attribut concerné et non une valeur nulle.

Notation : Dans un enregistrement on peut noter la valeur nulle soit pas un vide soit par NULL.

Contrainte d’entité
Cette contrainte impose que toute relation du schéma doit posséder une clé primaire (ou principale)
et que tout attribut participant à cette clé primaire soit non nul.

Contrainte référentielle
Le modèle relationnel ne possède pas de notion équivalente à l’association du modèle entité-
association.

On peut cependant définir une contrainte dite référentielle entre deux relations pour représenter un
lien entre ces dernières. Pour cela, on va ajouter à la première relation un ensemble d’attributs
correspondants à la clé primaire de la deuxième relation, de sorte que les valeurs de ces attributs
dans la première doivent apparaître comme valeurs d’une clé dans la deuxième. On appelle ces
attributs ajoutés à la première relation une clé étrangère.

Exemple :

Soit deux relations PARTICIPANT et MODULE

PARTICIPANT (CODE_PARTICIPANT : Chaîne de caractères, NOM : Chaîne de caractères, PRENOM :

Chaîne de caractères)

GROUPE (CODE_GROUPE : Chaîne de caractères, ANNEE : Chaîne de caractères)

Pour indiquer qu’un participant appartient à un groupe on ajoute à la relation PARTICIPANT un

nouvel attribut GROUPE comme clé étrangère. L’attribut GROUPE de PARTICIPANT sera lié par une
contrainte référentielle à la clé CODE_GROUPE de la relation GROUPE. Le schéma de la relation
PARTICIPANT devient :

PARTICIPANT (CODE_PARTICIPANT : Chaîne de caractères, NOM : Chaîne de caractères, PRENOM :

Chaîne de caractères, GROUPE : Chaîne de caractères)

Pour mieux comprendre le fonctionnement de la contrainte référentiel, passons à la représentation

tabulaire des deux relations.

B. EL HATIMI 4/5 Modèle relationnel

CSGA Module 5 – Modélisation de l’information géographique

Considérons la table GROUPE qui contient deux enregistrements :

CODE_GROUPE ANNEE
CSGA5 2015 – 2016
CSGA6 2016 – 2017

Considérons maintenant la table PARTICIPANT avec quatre enregistrements :

CODE_PARTICIPANT NOM PRENOM GROUPE

01256 Nom1 Prenom1 CSGA5
01257 Nom2 Prenom2
01258 Nom3 Prenom3 CSGA6
01259 Nom4 Prenom4 CSGA4

Les enregistrements 1 et 3 de la table PARTICIPANT respectent la contrainte référentielle car la

valeur de la clé étrangère dans les deux cas existent comme valeur de clé dans la table GROUPE.

Dans le cas de l’enregistrement 2 de la table participant, la clé étrangère porte la valeur nulle ce qui
n’enfreint pas la contrainte référentielle puisque la valeur nulle correspond à une valeur non connue
de l’attribut.

Par contre, l’enregistrement 4 de la table participant enfreint la contrainte référentielle car la valeur
CSGA4 n’existe pas comme valeur de clé dans la table GROUPE. Donc cet enregistrement ne peut pas
exister dans la base de données.

B. EL HATIMI 5/5 Modèle relationnel