Chapitre 1 : Principe des Bases de données

Modèles De Base De Données

Modèle hiérarchique

Une base de données hiérarchique est une forme de système de gestion de base de données qui lie des
enregistrements dans une structure arborescente de façon à ce que chaque enregistrement n’ait qu’un seul
possesseur (par exemple, une paire de chaussures n’appartient qu’à une seule personne).

Les structures de données hiérarchiques ont été largement utilisées dans les premiers systèmes de gestion de bases
de données conçus pour la gestion des données du programme Apollo de la NASA. Cependant, à cause de leurs
limitations internes, elles ne peuvent pas souvent être utilisées pour décrire des structures existantes dans le monde
réel.

Les liens hiérarchiques entre les différents types de données peuvent rendre très simple la réponse à certaines
questions, mais très difficile la réponse à d’autres formes de questions. Si le principe de relation « 1 vers N » n’est pas
respecté (par exemple, un malade peut avoir plusieurs médecins et un médecin a, a priori, plusieurs patients), alors la
hiérarchie se transforme en un réseau.

Modèle réseau

Le modèle réseau est en mesure de lever de nombreuses difficultés du modèle hiérarchique grâce à la possibilité
d’établir des liaisons de type n-n, les liens entre objets pouvant exister sans restriction. Pour retrouver une donnée
dans une telle modélisation, il faut connaître le chemin d’accès (les liens) ce qui rend les programmes dépendants de
la structure de données

Ce modèle de bases de données a été inventé par C.W. Bachman. Pour son modèle, il reçut en 1973 le prix Turing.

Modèle relationnel

Une base de données relationnelle est une base de données structurée suivant les principes de l’algèbre
relationnelle.

Le père des bases de données relationnelles est Edgar Frank Codd. Chercheur chez IBM à la fin des années 1960, il
étudiait alors de nouvelles méthodes pour gérer de grandes quantités de données car les modèles et les logiciels de
l’époque ne le satisfaisaient pas. Mathématicien de formation, il était persuadé qu’il pouvait utiliser des branches
spécifiques des mathématiques pour résoudre des difficultés telles que la redondance des données, l’intégrité des
données ou l’indépendance de la structure de la base de données avec sa mise en œuvre physique.

En 1970, Codd publia un article où il proposait de stocker des données hétérogènes dans des tables, permettant
d’établir des relations entre elles. De nos jours, ce modèle est extrêmement répandu, mais en 1970, cette idée était
considérée comme une curiosité intellectuelle. On doutait que les tables ne pourraient pas être gérer de manière
efficace par un ordinateur.

Ce scepticisme n’a cependant pas empêché Codd de poursuivre ses recherches. Un premier prototype de Système de
gestion de bases de données relationnelles (SGBDR) a été construit dans les laboratoires d’IBM. Depuis les années 80,
cette technologie a mûri et a été adoptée par l’industrie. En 1987, le langage SQL, qui étend l’algèbre relationnelle, a
été standardisé.
SYSTEME DE GESTION DE BASE DE DONNEES (SGBD)
Principes de fonctionnement

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érentes.

Actuellement, la plupart des SGBD fonctionnent selon un mode client/serveur. Le serveur (sous-entendu la machine
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

Quel que soit le modèle, un des problèmes fondamentaux à prendre en compte est la cohérence des données. Par
exemple, dans un environnement où plusieurs utilisateurs peuvent accéder concurremment à une colonne d’une
table par exemple pour la lire ou pour l’écrire, il faut s’accorder sur la politique d’écriture. Cette politique peut être :
les lectures concurrentes sont autorisées mais dès qu’il y a une écriture dans une colonne, l’ensemble de la colonne
est envoyée aux autres utilisateurs l’ayant lue pour qu’elle soit rafraîchie.

Objectifs

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.

Administration centralisée des données (intégration) :

Toutes les données doivent être centralisé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 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, 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.

Quelques SGBD connus et utilisés

Il existe de nombreux systèmes de gestion de bases de données, en voici une liste non exhaustive :

PostgreSQL:

MySQL ;

Oracle ;

IBM DB2 ;

Microsoft SQL ;

Sybase ;

Informix ;
POURQUOI UNE MODELISATION PREALABLE ?

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’association1. 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.

2.1.2 Merise

MERISE (Méthode d’Étude et de Réalisation Informatique par sous-ensemble) est certainement le langage de
spécification le 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émentation. 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 dynamique. L’expression conceptuelle des
données conduit à une modélisation des données en entités et en associations.

Merise propose une démarche, dite par niveaux, dans laquelle il s’agit de hiérarchiser les préoccupations 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’organisation 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 concrète dont le système sera mis en
place (SGBD retenu).
LES ETAPES DE LA MODELISATION
1 - Le Dictionnaire De Données :

Le Dictionnaire de données est un tableau qui regroupe toutes les données que vous aurez à conserver dans votre
base de données. Pour chaque donnée il indique :
- Le code : Il s’agit des variables utilisées dans la base de données
- La désignation : il s’agit d’une mention décrivant ce à quoi la donnée correspond
- Le type de données : il s’agit de préciser le type de l’information
o A ou Alphabétique lorsque la donnée est uniquement composée de caractère
o N ou Numérique : lorsque la donnée est uniquement composé de chiffre
o AN : lorsque la donnée peut être composée à la fois de caractère alphabétiques et numériques
o Date : Lorsque la donnée est une date (au format JJ-MM-AA)
- La taille : Elle s’exprime en nombre de caractères ou de chiffres. Dans le cas d’une date au format JJ-MM-
AA on compte également le nombre de caractères soit 8 caractères. Pour ce qui est du type Booléen, nul
besoin de préciser la taille.
- Et parfois des remarques ou observations complémentaires par exemple si une donnée est strictement
supérieure à 0

Exemple de dictionnaire

Code Désignation Type Taille Remarque

Id_I Identifiant de l’inscrit N 5
Nom_I Nom de l’inscrit A 30
Prenom_I Prenom de l’inscrit A 30
Rue_I Rue ou habite l’inscrit AN 50
Ville_I Ville de l’inscrit A 50
Cp_I Code postal de l’inscrit AN 5
Tel_I Téléphone Inscrit AN 15
Tel_Port_I Téléphone portable de l’inscrit AN 15
Email_I Email de l’inscrit AN 100
Date_Naiss_I Date de naissance de l’inscrit Date 10 Format JJ-MM-AAAA
Id_Livre Identifiant du livre N 5
An_Livre Année du livre N 4
Resume_Livre Resumé du livre AN 100
Libelle_T Libelle du type de livre AN 30
Id_Edit Identifiant de l’éditeur du livre N 5
Nom,_Edit Nom de l’éditeur du livre A 30
Id_Aut Identifiant de l’auteur du livre N 5
Nom_Aut Nom de l’auteur du livre A 30
Pre_Aut Prenom de l’auteur du livre A 30
DateNaiss_Aut Date de naissance de l’auteur Date 10
Id_P Identifiant du pays de l’auteur N 5
Nom_P Nom du Pays de l’auteur A 30
Date_Emp Date d l’emprunt Date 10
Delai_emp Délai de l’emprunt N 3
 Remarque :

Les données qui figurent dans le MCD (et donc dans le dictionnaire de données) doivent être dans la plupart
des cas élémentaires.

- Elles ne doivent pas être calculées

- Elles ne doivent pas être composées
- Lorsque l’on n’effectue jamais de calcul sur une donnée numérique, celle-ci doit être de type AN (Numéro
de téléphone par exemple)

2 - Les Dépendances Fonctionnelles

Soit deux propriétés P 1 et P2. On dit que P1 et P2 sont reliées par une dépendance fonctionnelle (DF) si et seulement
si une occurrence de P1 permet de connaitre une et une seule occurrence de P2

Cette dépendance est représentée comme ceci :

P1 P2

On dit que P1 est la source de la DF et P2 en est le but

Par ailleurs, plusieurs données peuvent être source comme plusieurs données peuvent être but d’une DF.

3 - Le Modèle Conceptuel De Données

- Les entités : Chaque entité est unique et est décrite par un ensemble de propriété encore appelé attribut
ou caractéristique. Une des propriétés de l’entité est l’identifiant. Cette propriété doit posséder des
occurrences uniques et doit être source de dépendances fonctionnelle avec toutes les autres propriétés
de l’entité. Bien souvent on utilise une donnée de type entier qui s’incrémente pour chaque occurrence.
Le formalisme d’une entité est le suivant :

NOM DE L’ENTITE

Identifiant
Propriété 1
Propriété 2
Propriété 3

Ainsi, si on reprend notre dictionnaire de données précédent, on schématise par exemple une entité auteur comme
ceci :
AUTEUR

Id_A
Nom_a
Prenom_a
DateNaiss_a

A partir de cette entité, on peut retrouver la règle de gestion suivante : Un auteur est identifié par un numéro unique
et est caractérisé par nom, un prénom, et une date de naissance.
Une entité peut avoir plusieurs occurrences.

Id_a Nom_a Prenom_a DateNaiss_a

1 CISSE Amadou 10-12-72
2 TOURE Moctar 08-08-80
3 TALL Issa 11-10-73

Les Associations

Une association définit un lien sémantique entre une ou plusieurs entités. En effet la définition de liens entre entités
permet de traduire une partie des règles de gestion qui n’ont pas été satisfaite par la simple définition des entités

Le formalisme d’une association est le suivant :

NOM DE L’ASSOCIATION

Liste des données portées

Généralement le nom de l’association est un verbe définissant le lien entre les entités qui sont reliées par cette
dernière. Par exemple.

AUTEUR
PAYS
Est né
Id_A 1.1 0.n Id_p
Nom_a
Nom_P
Prenom_a
DateNaiss_a

Ici, l’association « être né » traduit les deux règles de gestion suivantes

- Un auteur est né dans un seul pays

- Dans un pays sont nés plusieurs auteurs

Vous remarquez, que cette association est caractérisée par ces notations 1.1 et 1.n qui nous ont permis de définir les
règles de gestions. Ces annotations sont appelées les cardinalités

Une cardinalité est définie comme ceci : minimum, maximum

Les cardinalités les plus répandues sont les suivantes : 0,n ; 1,n ; 0,1 ;1,1. On peut toutefois tomber sur des règles de
gestion imposant des cardinalités avec des valeurs particulières, mais cela reste assez exceptionnel et la présence de
ces cardinalités imposera l’implémentation de traitements supplémentaires

L’identifiant d’une association ayant des cardinalités 0,n/1,n de part et d’autres est obtenu par la concaténation des
entités qui participent à l’association. Imaginons l’association suivante :
 AUTEUR
Rédiger LIVRE
1,n 1,n
Id_A
Nom_a Nbre chapitres Id_livre
Prenom_a Titre_livre
DateNaiss_a An_livre

Ici un auteur rédige au moins un ou plusieurs livres et pour chaque livre on connait le nombre de chapitre rédigés par
l’auteur.

L’association rédiger peut donc être identifiée par la concaténation des propriétés Id_a et Id_livre. Ainsi le couple
Id_a et Id_i doit être unique pour chaque occurrence de l’association. On peut également définir la dépendance
fonctionnelle suivante :

Ida, id_livre Nbre chapitre

On dit que le nombre de chapitre est une donnée portée par l’association « rédiger ». Cette association est donc une
association porteuse de données.

Elaboration du MCD
Cas Pratique 1
Pour construire une base de donnée sur la scolarité des étudiants, on dispose des éléments suivants : Num
étudiant, nom, prénom, date de naissance, Num module, nom module, Nbre heure enseignement, résultat
module, Num enseignant, nom enseignant, prénom enseignant, Num institut, nom institut, nombre enseignant
institut.

Soient les hypothèses suivantes :

- Un étudiant peut s’inscrire à plusieurs modules dont les cours sont dispensés à des dates différentes ;
- Le résultat d’un module caractérise la moyenne d’un étudiant dans un module donné ;
- Le nombre d’heure enseignement est spécifique au module ;
- Chaque module n’est assuré que par un enseignant ;
- Un enseignant est rattaché à un institut.

Etablir :

- Le dictionnaire de données
- La Liste et le graphe des dépendances fonctionnelles
- Le modèle conceptuel de données (MCD)
Cas Pratique : GESTION BANCAIRE
Soit les règles de gestion suivantes :

 Un client peut avoir un ou plusieurs Comptes Bancaires

 Un Compte bancaire est domicilié dans une Agence
 Une Agence est située dans une commune
 Le client peut faire un ou plusieurs Versements et Retrait sur son compte.
 Chaque compte est géré par un gestionnaire de compte.
 Le client à la possibilité de demander un prêt sur un compte donné.
 Au cas où le prêt est accordé, il est remboursé à des dates fixées par la banque.

Etablir :

- Le dictionnaire de données
- La liste et le graphe des dépendances fonctionnelles
- Le MCD
LE MODELE LOGIQUE DE DONNEES (MLD)
La description conceptuelle nous a permis de décrire le plus fidèlement sous forme d’abstraction les réalités de
l’univers à informatisé. Cette vision de l’information, n’est pas compréhensible par les SGBD. C’est la description
logique de données qui permet de passer de la description conceptuelle à l’implémentation de la base de données,
un abstrait manipulable dans les applications informatiques.

Les règles de passage du MCD au MLD sont les suivantes ;

- Chaque relation de type

ENTITE A ENTITE B
1,N 1,1
Relation Clé B
Clé A
Propriétés A 0,N 0,1 Propriétés B
N

Se transforme en 2 tables :

Table A (Clé A, Propriétés A)

Table B (Clé B, Clé A, Propriétés B)

NB : La clé du coté 1,N migre vers 1.1

- Chaque relation de type

ENTITE A ENTITE B
1,N Relation 1,N
Clé A Clé B
0,N Propriétés R 0,N
Propriétés A Propriétés B
N

Se transforme en 3 tables :

Table A (Clé A, Propriétés A)

Table B (Clé B, Propriétés B)
Table R (Clé A, Clé B, Propriétés R)

NB : Les clés migrent vers l’association porteuse de données

CAS PRATIQUE 3
PROBLEME : GESTION DES DOSSIERS COMPTABLES DANS UN CENTRE DE GESTION

On se situe dans un centre de gestion comprenant plusieurs agences délocalisées. Dans chaque agence travaillent
plusieurs comptables, chacun gérant plusieurs exploitations. Chaque exploitation est attribuée à un exploitant. Un
comptable ne travaille que dans une seule agence et une exploitation ne peut être gérée que par un seul
comptable. On souhaite connaître la liste des exploitations gérées par chacun des comptables et chacune des
agences. Les exploitations sont regroupées par type. Chaque type d’exploitation à un coût annuel fixe.

Etablir :

- Le dictionnaire de données
- La liste et le graphe des dépendances fonctionnelles
- Le M.C.D.
- Le M.L.D.
CAS PRATIQUE 4

PROBLEME : GESTION D’UNE AGENCE DE VOYAGE

Un responsable d'une agence de voyage souhaite automatiser l'organisation de ses voyages.

Le dictionnaire des données est le suivant :

Numéro voyage
Nom voyage
Numéro ville départ
Nom ville départ
Numéro ville Arrivée
Nom ville Arrivée
Numéro transport
Type transport
Numéro réservation
Date Réservation
Numéro client
Nom client
Prénom client
Adresse client
Numéro ville escale
Nom Ville d'escale
Date de départ
Prix du voyage
Code période
Nom période

Indications complémentaires :

- Une réservation est faite par un seul client

- Une réservation correspond à un voyage et à un seul
- Un voyage a une ville de départ et une ville d’arrivée
- Un voyage peut avoir plusieurs villes d'escale
- Un moyen de transport peut être utilisé par plusieurs voyages
- Le prix d'un voyage dépend de la période (Printemps, été, hiver etc . ..)

Travail à faire

Établir les modèles conceptuel et logique des données.

CAS PRATIQUE 5

GESTION DES RECUTEMENTS DANS UN CABINET

Pour la gestion de ses recrutements, un cabinet désire mettre en place une base de données pour une meilleure
présélection des candidats. La base doit être à mesure de gérer les informations suivantes :

Individu

Nom et prénom de l'individu

Date de naissance de l'individu
Langues pratiquées par l'individu
Niveau dans les langues pratiquées
Désignation des centres d'intérêt concernant un individu (sport, loisirs divers...)
Salaire actuel de l'individu
Salaire recherché

Attestation

Numéro de l’attestation
Libelle de l’attestation
Date d’obtention
Mention

Diplôme

Désignation du diplôme (code et libellé)

Date d'obtention du diplôme

Employeurs successifs

Raison sociale de l'employeur

Date d'entrée dans l'entreprise
Date de départ de l'entreprise
Fonction exercée chez l'employeur
Date de début de la fonction
Date de fin de la fonction

Les Informations complémentaires sont :

 Un individu est embouché chez un seul employeur et occupe une seule fonction
 Une attestation est délivrée à un seul individu
 Un Diplôme est délivré à un seul individu
 Un Individu peut parler plusieurs langues mais à un seul centre d’intérêt