1

Objectif général : Être capable de concevoir une base de données

Programme
1. Généralités sur les bases de données
1.1. Le concept de bases de données
1.1.1. Les fichiers et leurs limites
1.1.2. La définition d’une base de données
1.1.3. Les différents modèles de bases de données
1.2. Le système de gestion de bases de données
1.2.1. Les fonctions d’un SGBD
1.2.2. Accès aux données
1.3. Architecture d’un SGBD
1.3.1. Niveau conceptuel
1.3.2. Niveau interne
1.3.3. Niveau externe
1.3.4. Langages et modèles de données LDD, LMD, LCD
2. Le modèle Entité - Association
2.1. Définitions et généralités
2.2. Les concepts
2.3. Démarche de conception du MEA (Entité-Association)
3. Présentation du modèle réseau
3.1. Généralités
3.2. Les concepts
4. Modèle à objets
4.1. Généralités
4.2. Les concepts
2
1.1. Le concept de bases de données

1.1.1. Les fichiers et leurs limites

Les fichiers sont définis pour un ou plusieurs programmes de traitement. Les

données d’un fichier sont directement associées à un programme par une
description contenue dans le programme de traitement lui-même. Il n’existe
aucune indépendance entre le programme et les données. Toute modification de
la structure des données nécessite la réécriture du programme. Toute manipulation
de fichier exige trois niveaux d’intervention, et trois couches logicielles :
Niveaux d’intervention Couches logicielles
Gestion des contenus Programmes applicatifs Niveau 3
calculs, tests, affichages ...

Gestion des structures internes des Système de gestion de fichiers Niveau 2

fichiers, et des méthodes d’accès
(SGF)
ouverture, fermeture, lecture, écriture…

Gestion du support physique Pilote d’entrées-sorties Niveau 1

Disques durs, disquette, streamers… (Driver)

Un tel système est rigide, contraignant et long.

1.1.2. La définition d’une base de données

Une base de données est un ensemble structuré et organisé de données permettant

le stockage de grandes quantités d’informations afin d’en faciliter leur utilisation
(ajout, mise à jour, recherche et éventuellement analyse dans les systèmes les plus
évolués), généralement géré par un système spécialisé (SGBD). Ce terme vient de
l’anglais “database” apparue pour la première fois en 1964. Elle désigne alors un
ensemble d’information numérisées, échangées entre plusieurs utilisateurs d’un

3
système informatique. Elle organise l'information qu'elle contient en tables, en
champs (les colonnes) et en enregistrements (les lignes).

1.1.3. Les différents modèles de bases de données

 Les fichiers et COBOL
Le stockage des données a commencé dans les années 1960 avec les systèmes
de gestion de fichiers et le langage COBOL (Common Business Oriented
Language). Loin d’être dépassé, ce dernier fut le plus utilisé entre 1960 et 1980.
En 2002, il permet une programmation de type objet, la gestion des informations
Unicode et une intégration avec XML. En 2005, le Gartner Group estimait que
COBOL manipulait près de 75 % des données de gestion stockées. Le principal
inconvénient des applications COBOL est la forte dépendance qui existe entre
les données stockées et les traitements. En effet, le fait de déclarer dans chaque
programme les fichiers utilisés impose une maintenance lourde si la structure
d’un fichier doit être modifiée. De plus, les instructions de manipulation
(ouverture, lecture, écriture et modification) sont très liées à la structure de
chaque fichier. La structure des fichiers de données s’apparente à celle d’une
table (suite de champs de types numériques ou alphanumériques).
 Le modèle hiérarchique
Les bases de données hiérarchiques ont introduit un modèle de données du même
nom. Il s’agit de déterminer une arborescence de données où l’accès à un
enregistrement de niveau inférieur n’est pas possible sans passer par le niveau
supérieur. Promus par IBM et toujours utilisés dans le domaine bancaire, les
SGBD hiérarchiques souffrent toutefois de nombreux inconvénients. La figure
suivante illustre un modèle hiérarchique de données dans lequel des compagnies
aériennes peuvent embaucher plusieurs pilotes. Un pilote peut travailler pour le
compte de différentes compagnies.

4
 Figure 1-1. Modèle de données hiérarchique
Les inconvénients récurrents sont toujours la forte dépendance entre les
données stockées et les méthodes d’accès. Les chaînages internes impliquent
forcément une programmation complexe. Outre ces problèmes de
programmation, ce modèle montre des lacunes lors de l’accès à la base.

 Extraire la liste des pilotes implique le parcours de toutes les

compagnies.
 L’insertion peut se révéler problématique : l’ajout d’un pilote sans
compagnie n’est pas possible, à moins d’ajouter une compagnie fictive.
 La suppression peut se révéler dangereuse : une compagnie disparaît,
alors de fait ses pilotes aussi.
 La modification est souvent problématique : les incohérences
proviennent d’éventuelles redondances (le nom ou l’adresse d’un pilote
qui change doit se répercuter à tous les enregistrements). Bien qu’il
existe de nombreuses hiérarchies autour de nous, le monde qui nous
entoure n’est pas un arbre !
 Le modèle réseau
Quelques années plus tard, C. W. Bachman, pionnier dans le domaine de
l’informatique, s’est essayé aux bases de données en inventant un modèle
brisant cette hiérarchie plutôt arbitraire. Les bases de données réseau étaient
nées avec le modèle CODASYL, première norme décidée sans IBM. Bien que
résolvant quelques limitations du modèle hiérarchique et annonçant des
performances en lecture honorables, le modèle réseau n’est ni plus ni moins

5
qu’une usine à gaz gavée de pointeurs. Pour preuve, plus personne n’utilise
de tels SGBD où la dépendance entre les données stockées et les méthodes
d’accès existe toujours, et l’évolution d’une base de données est très coûteuse
en termes de recompilation de pointeurs.

Figure 1-2. Modèle de données réseau

Ce monde ressemble bien à une telle usine à gaz ! Mais pas question de
stocker ainsi les données, ce serait bien trop compliqué de concevoir le bon
graphe. Le modèle de données se doit d’être plus simple.

 Le modèle relationnel
En 1970, E. Codd publie l’article de référence posant les bases du modèle
relationnel. D’un seul coup, toutes les limitations des précédents modèles sont
résolues. Le but initial de ce modèle était d’améliorer l’indépendance entre les
données et les traitements. Cet aspect des choses est réussi et avec ça d’autres
fonctionnalités apparaissent :
 Normalisation (dépendances fonctionnelles) et théorie des ensembles
(algèbre relationnelle).
 Cohérence des données (non-redondance et intégrité référentielle).
 Langage SQL (déclaratif et normalisé).
 Accès aux données optimisé (choix du chemin par le SGBD).
 Indexation, etc.

6
Les liens entre les enregistrements de la base de données sont réalisés non pas
à l’aide de pointeurs physiques, mais à l’aide des valeurs des clés étrangères
et des clés primaires. Pour cette raison, le modèle relationnel est dit « modèle
à valeurs ».

Figure 1-3. Modèle de données relationnel

La force de ce modèle de données réside dans le fait qu’il repose sur des
principes simples et permet de modéliser des données complexes. Le modèle
relationnel est à l’origine du succès que connaissent aujourd’hui les grands
éditeurs de SGBD, à savoir Oracle, IBM, Microsoft et Sybase dans différents
domaines :

 OLTP (OnLine Transaction Processing) où les mises à jour des données

sont fréquentes, les accès concurrents et les transactions nécessaires.
 OLAP (Online Analytical Processing) où les données sont
multidimensionnelles (cubes), les analyses complexes et l’informatique
décisionnelle.
 Systèmes d’information géographiques (SIG) où la majorité des
données sont exprimées en 2D ou 3D et suivent des variations
temporelles.
 Les modèles NoSQL
Depuis quelques années, le volume de données à traiter sur le Web a mis à
rude épreuve les SGBD relationnels, qui ont été jugés non adaptés à de
nombreuses montées en charge. Les grands acteurs du Big Data, comme
7
Google, Amazon, LinkedIn ou Facebook, ont été amenés à créer leurs propres
systèmes de stockage et de traitement de l’information (BigTable, Dynamo,
Cassandra). Des implémentations d’architectures open source comme Hadoop
et des SGBD comme HBase, Redis, Riak, MongoDB ou encore CouchDB ont
permis de démocratiser ce nouveau domaine de l’informatique répartie. On
distingue plusieurs modèles de données parmi les SGBD NoSQL du moment
: clé-valeurs, orienté colonnes, documents et graphes. Plus le modèle est
complexe, moins le système est apte à évoluer rapidement en raison de la
montée en charge.

Figure 1-4. Modèles de données du NoSQL

 Modèle de données clé-valeurs

Le mode de stockage du modèle clé-valeurs (key-value) s’apparente à une
table de hachage persistante qui associe une clé à une valeur (de toute nature
et de type divers, la clé 1 pouvant référencer un nom, la clé 2 une date, etc.).
C’est à l’application cliente de comprendre la structure de ce blob. L’intérêt
de ces systèmes est de pouvoir mutualiser cette table sur un ou plusieurs
serveurs. Les SGBD les plus connus sont Memcached, CouchBase, Redis et
Voldemort (LinkedIn).

Figure 1-5. Modèle de données clé-valeurs

8
 Modèle de données orienté colonnes
Le modèle orienté colonnes ressemble à une table dénormalisée (sans la
présence de NULL, toutefois) dont la structure est dynamique. Les SGBD les
plus connus sont HBase (implémentation du BigTable de Google) et
Cassandra (projet Apache qui reprend à la fois l’architecture de Dynamo
d’Amazon et BigTable).

Figure 1-6. Modèle de données orienté colonnes

 Modèle de données orienté documents

Le modèle orienté documents est toujours basé sur une association clé-valeur
dans laquelle la valeur est un document (JSON généralement, ou XML). Les
implémentations les plus populaires sont CouchDB (Apache), RavenDB, Riak
et MongoDB.

Figure 1-7. Modèle de données orienté documents

 Modèle de données orienté graphes

Le modèle de données orienté graphes se base sur les nœuds et les arcs
orientés et éventuellement valués. Ce modèle est très bien adapté au traitement
des données des réseaux sociaux où on recherche les relations entre individus
de proche en proche. Les principales solutions du marché sont Neo4j (Java)
et FlockDB (Twitter).

9
 Figure 1-8. Modèle de données en graphes

1.2. Le système de gestion de bases de données

1.2.1. Les fonctions d’un SGBD

 Définition de données (LDD) : Un SGBD permet la description des entités

(Exemple : élève, classe, ...), des propriétés ou attributs de l’entité
(Exemple : nom d’un élève, module d’une classe, ...), des liens entre les
entités (Exemple : un élève est inscrit dans une classe, ...), des contraintes
(Exemple : l’effectif d’une classe de BTS ne doit pas dépasser 30 élèves).
Pour assurer cette fonction, les SGBD offrent un langage spécifique nommé
langage de définition de données (LDD).
 La manipulation des données (LMD) : Les SGBD offrent des capacités
de création, recherches, modification et de suppression de données grâce à
un langage dit « langage de manipulation des données (LMD) ».
Exemple : insertion d’un nouvel élève, modification de tel d’un élève suite
à la perte de son tel, recherche de la moyenne d’un élève.
 L’intégrité des données : il s’agit d’assurer que les contraintes (règles)
d’intégrités définies par le LDD soient respectées à chaque manipulation
de la base de données.
Exemple : l’âge d’un élève de BTS ne doit pas dépasser 27 ans, ou
l’identifiant d’un élève doit être unique ...
 La gestion d’accès concurrents : le SGBD gère l’accès simultané des
utilisateurs à la base de données. Le SGBD doit offrir des mécanismes de
10
 gestion des conflits d’accès. (Autorisation des accès multiples en
consultation, verrouillage lors d’accès en modification...). Exemple : lors
de la mise à jour des données concernant un élève, le SGBD interdit la
modification de ces données par autre utilisateurs non autorisés.
 La confidentialité : tous les utilisateurs d’une base de données ne sont pas
supposés pouvoir consulter ou modifier toutes les informations donc il faut
établir des règles de droit d’accès et de modification de données par le biais
des mots de passe et des privilèges d’accès. Exemple : Seul le directeur peut
changer l’affectation d’un élève d’une classe à une autre.
 La sécurité de fonctionnement : offre des mécanismes de récupération des
données comme la journalisation et les procédures de reprise après panne
en cas d’incident matériel ou logiciel.
Exemple : sauvegarde de la base de données une fois par semaine.

1.2.2. Accès aux données

 Gestion des droits d’accès

Les droits aux accès des données d’une base de données sont omniprésents dans
la gestion de celle-ci. Ils nécessitent l’autorisation des accès en imposant des
restrictions. Il est question de la gestion de sécurité, pour assurer la sécurité des
bases de données, nous avons :
- Confidentialité : seules les personnes autorisées ont accès aux ressources
de la base de données qui sont des données stockées dans la base ainsi que
les traitements activables sur ces données.
- Intégrité : les ressources de la base de données ne doivent pas être
corrompues, les données stockées et échangées doivent être protégées de
toute modification illicite (destruction, altération, substitution)
- Disponibilité : l’accès aux ressources de la base de données est garanti de
façon permanente.

11
  Rôles
On crée un rôle auquel on attribue des droits. Puis on attribue des rôles à des
utilisateurs ou connexions.
Rôles prédéfinis :
- Rôles serveur : Administration du serveur, configuration des paramètres
niveau serveur, exécution de certaines procédures stockées et d’ajout des
serveurs liés, gestion des connexions serveur, gestion des traitements au
sein du serveur, création ou modification des bases de données, gestion des
fichiers sur le disque, exécution d’instruction BULK INSERT.
- Rôles base de données : propriétaire base de données, ajout et suppression
des utilisateurs de base de données, utilisation d’instruction SELECT,
utilisation des instructions (INSERT, UPDATE et DELETE), des
opérations sur les objets de base de données, gestion des éléments de
sécurité sur la base de données, utilisation des backups, Interdit
l’instruction SELECT, Interdit l’écriture sur la base de données.
Rôle créer par utilisateur

1.3. Architecture d’un SGBD

Un SGBD est fréquemment décrit par une structure en couches correspondant à

des perceptions différentes des données, associées à des tâches différentes pour
différents acteurs. Nous distinguerons en général trois types d'acteurs : les
administrateurs de la base de donnée, les développeurs et les utilisateurs. Au
niveau externe, proche de l'utilisateur, la perception est totalement indépendante
du matériel et des techniques mises en œuvre, tandis qu'au niveau le plus intérieur,
se trouvent les détails de l'organisation sur disque et en mémoire.

12
1.3.1. Niveau conceptuel

On précise à ce niveau les tables, les relations entre tables, les contraintes
d'intégrité, les vues et les droits par groupe d'utilisateurs. Ce niveau concerne
l'administrateur et les développeurs.

1.3.2. Niveau interne

On définit les index et tous les éléments informatiques susceptibles d'optimiser

les ressources et les accès aux données. Ce niveau concerne l'administrateur.

1.3.3. Niveau externe

Au niveau externe, les utilisateurs et développeurs d'application ont une

perception limitée de la base de données. On parle de vue. Une vue peut être
considérée comme une restriction du schéma logique à un type d'utilisateur. Ce
niveau concerne les utilisateurs et les développeurs.

13
1.3.4. Langages et modèles de données LDD, LMD, LCD

Langage de définition de données - LDD

Le langage de définition de données est un langage orienté au niveau de la
structure de la base de données. Il permet de créer, modifier, supprimer des objets,
de définir le domaine des données et d’ajouter des contraintes de valeur sur les
données. Il permet enfin d’autoriser ou d’interdire l’accès aux données et d’activer
ou de désactiver l’audit pour un utilisateur donné.
 Création, modification et suppression d’objet
 Créer une table : CREATE TABLE
 Création simple
CREATE TABLE nom_table (nom_champ1 TYPE1, nom_champ2 TYPE2, ...)

 Modifier une table : ALTER TABLE

 Ajout ou modification de colonne
ALTER TABLE nom_table {ADD/MODIFY} ([nom_champ type [contrainte],
...])
 Ajout d’une contrainte de table
ALTER TABLE nom_table ADD [CONSTRAINT nom_contrainte] contrainte
 Renommer une colonne
ALTER TABLE nom_table RENAME COLUMN ancien_nom TO
nouveau_nom
 Renommer une table
ALTER TABLE nom_table RENAME TO nouveau_nom
 Supprimer une table : DROP TABLE
DROP TABLE nom_table

 Type de données
INTEGER : permet de stocker des entiers signés codés sur 4 octets.
BIGINT : permet de stocker des entiers signés codés sur 8 octets.

14
REAL : permet de stocker des réels comportant 6 chiffres significatifs codés sur
4 octets.
DOUBLE PRECISION : permet de stocker des réels comportant 15 chiffres
significatifs codés sur 8 octets.
NUMERIC[(précision, [longueur])] : permet de stocker des données
numériques à la fois entières et réelles avec une précision de 1000 chiffres
significatifs. Longueur précise le nombre maximum de chiffres significatifs
stockés et précision donne le nombre maximum de chiffres après la virgule.
CHAR(longueur) : permet de stocker des chaînes de caractères de longueur fixe.
Longueur doit être inférieur à 255, sa valeur par défaut est 1.
VARCHAR(longueur) : permet de stocker des chaînes de caractères de longueur
variable. Longueur doit être inférieur à 2000, il n’y a pas de valeur par défaut.
DATE : permet de stocker des données constituées d’une date.
TIMESTAMP : permet de stocker des données constituées d’une date et d’une
heure.
BOOLEAN : permet de stocker des valeurs Booléenne.
MONEY : permet de stocker des valeurs monétaires.
TEXT : permet des stocker des chaînes de caractères de longueur variable.

 Contraintes
 Contraintes de colonne
 NOT NULL ou NULL: interdit (NOT NULL) ou autorise (NULL)
l’insertion de valeur NULL pour cet attribut.
 UNIQUE: désigne l’attribut comme clé secondaire de la table. Deux n-
uplets ne peuvent recevoir des valeurs identiques pour cet attribut, mais
l’insertion de valeur NULL est toutefois autorisée. Cette contrainte peut
apparaître plusieurs fois dans l’instruction.
 PRIMARY KEY: désigne l’attribut comme clé primaire de la table. La
clé primaire étant unique, cette contrainte ne peut apparaître qu’une
seule fois dans l’instruction. La définition d’une clé primaire composée

15
 se fait par l’intermédiaire d’une contrainte de table. En fait, la contrainte
PRIMARY KEY est totalement équivalente à la contrainte UNIQUE
NOT NULL.
 REFERENCES table [(colonne)] [ON DELETE CASCADE]:
contrainte d’intégrité référentielle pour l’attribut de la table en cours de
définition. Les valeurs prises par cet attribut doivent exister dans
l’attribut colonne qui possède une contrainte PRIMARY KEY ou
UNIQUE dans la table. En l’absence de précision d’attribut colonne,
l’attribut retenu est celui correspondant à la clé primaire de la table
spécifiée.
 CHECK (condition): vérifie lors de l’insertion de n-uplets que
l’attribut réalise la condition.
 DEFAULT valeur: permet de spécifier la valeur par défaut de l’attribut.

 Contraintes de table
 PRIMARY KEY (colonne, …): désigne la concaténation des attributs
cités comme clé primaire de la table. Cette contrainte ne peut apparaître
qu’une seule fois dans l’instruction.
 UNIQUE (colonne, …): désigne la concaténation des attributs cités
comme clé secondaire de la table. Dans ce cas, au moins une des colonnes
participant à cette clé secondaire doit permettre de distinguer le n-uplets.
Cette contrainte peut apparaître plusieurs fois dans l’instruction.
 FOREIGN KEY (colonne, …) REFERENCES table [(colonne, …)]
[ON DELETE CASCADE | SET NULL]: contrainte d’intégrité
référentielle pour un ensemble d’attributs de la table en cours de définition.
Les valeurs prises par ces attributs doivent exister dans l’ensemble
d’attributs spécifié et posséder une contrainte PRIMARY KEY ou
UNIQUE dans la table.
 CHECK (condition): contrainte permet d’exprimer une condition qui doit
exister entre plusieurs attributs de la ligne.

16
 Langage de manipulation de données - LMD
Le langage de manipulation de données est l’ensemble des commandes
concernant la manipulation des données dans une base de données. Il permet
l’ajout, la suppression et la modification de lignes, la visualisation du contenu des
tables et leur verrouillage.

 Ajout, suppression et modification de lignés

 Insertion de n-uplets : INSERT INTO
INSERT INTO nom_table (nom_col_1, nom_col_2, ...)
VALUES (val_1, val_2, ...)

 Modification de n-uplets : UPDATE

UPDATE nom_table
SET nom_col_1 = {expr0ession_1 | (SELECT ...)},
nom_col_2 = {expression_2 | (SELECT ...)},
...
nom_col_n = {expression_n | (SELECT ...)}
WHERE prédicat
 Suppression de n-uplets : DELETE
DELETE FROM nom_table
WHERE prédicat
 Interrogation d’une base de données
SELECT [ALL | DISTINCT] {* | expression [AS nom_affiché]} [, ...]
FROM nom_table [[AS] alias] [, ...]
[ WHERE prédicat]
[ GROUP BY expression [, ...]]
[HAVING condition [, ...]]
[{UNION | INTERSECT | EXCEPT [ALL]} requête]
[ ORDER BY expression [ ASC | DESC] [, ...]]

17
  SELECT : cette clause permet de spécifier les attributs que l’on désire
voir apparaître dans le résultat de la requête.
 FROM: cette clause spécifie les tables sur lesquelles porte la requête.
 WHERE: cette clause permet de filtrer les n-uplets en imposant une
condition à remplir pour qu’ils soient présents dans le résultat de la
requête.
 GROUP BY : cette clause permet de définir des groupes
 HAVING : cette clause permet de spécifier un filtre (condition de
regroupement des n-uplets) portant sur les résultats.
 UNION, INTERSECT et EXCEPT : cette clause permet d’effectuer
des opérations ensemblistes entre plusieurs résultats de requête
 ORDER BY : cette clause permet de trier les n-uplets du résultat

Langage de contrôle de données - LCD

Le Langage de Contrôle des Données (LCD) est un langage de programmation
et un sous-ensemble de SQL qui permet de contrôler l’accès aux données d’une
base de données.
 Commandes de contrôle de données
Le contrôle de données se fait via l’émission d’ordres SQL dont les plus connus
sont :
 GRANT : autorisation d'un utilisateur à effectuer une action ;
GRANT <Liste des droits> ON <nom de la table | vue> TO <Liste
usagers> [WITH GRANT OPTION]
 DENY : interdiction à un utilisateur d'effectuer une action ;
DENY <Liste des droits> TO <Liste usagers>
 REVOKE : annulation d'une commande de contrôle de données
précédente ;
REVOKE <Liste des droits> ON <nom de la table | vue> FROM <Liste
usagers>

18