Administration Des BD

UNIVERSITE DE DOUALA
Faculté des Sciences
Département de Mathématiques et Informatique

Licence 3 - Informatique
SAD 366
Administration des Bases de

Données
Année Académique 2019/2020
Dr MOSKOLAI N. Justin
SAD 366. Administration des Bases de Données
(CM : 30h, TD : 10h, TP : 05h, TPE : 10h)
Objectifs pédagogiques :
Préparer des futurs informaticiens orientés vers la conception et l'administration de base de

données. L'accent est mis sur l'utilisation d'une méthodologie de conception de base de
données centralisée ou répartie, la maîtrise des éléments d'architecture logique et physique
d'une base de données relationnelle, les fonctions d'administration d'une base de données, la
démarche d'optimisation d'une base de données, les règles d'évaluation du coût des
opérations.
Compétences visées :
 Concevoir une base de données relationnelle.

 Administrer une base de données relationnelle.
 Connaître les caractéristiques de choix d’un SGBD.
Contenu :
Chapitre 1 : Bases de données relationnelles
Chapitre 2 : Modèle relationnel de bases de données
Chapitre 3 : Administration de bases de données
Chapitre 4 : Choix de plateforme d’administration de bases de données
1
SAD 366 - Administration des Bases de Données
FICHE DE PROGRESSION
PROCESSUS GENERAL DU DEROULEMENT DE CHAQUE COURS

1- Présentation de l’objet du cours
2- Rappels du cours précédent
3- Question sur la qualité du cours
a. Le rythme du Cours Magistral est-il convenable ?
b. Les explications sont-elles assez, ou insuffisantes ?
4- Libellé du nouveau cours
5- Proposer
a. Des exercices à faire à la maison
b. Un exercice durant le CM pour mieux illustrer le cours
SEQUENCES THEMES DEVELOPPES DUREE
Chapitre 1 : Bases de données relationnelles CM : 4h

SEQUENCE 1 - Rappels
Chapitre 1 : Bases de données relationnelles CM : 4h

- Système de gestion de base de données TD : 2h
SEQUENCE 2
- Conception d’une base de données
Chapitre 2 : Modèle relationnel de bases de CM : 4h

données TP : 2h
SEQUENCE 3
- MCD TD : 2h
- MLD
Chapitre 2 : Modèle relationnel de bases de CM : 4h
données TP : 2h
SEQUENCE 4
- Algèbre relationnel TD : 2h
- Langages de requêtes
Chapitre 3 : Administration de bases de CM : 4h
données TP : 2h
SEQUENCE 5 - Le métier TD : 2h
- Outils du DBA
- Compétences techniques
Chapitre 4: Choix de plateforme CM : 4h
d’administration de bases de données TP : 2h
SEQUENCE 6
- Plateforme MS ACCESS
- Plateforme MYSQL WORKBENCH
2
SEQUENCE 7 d’administration de bases de données TP : 2h
- Plateforme PostGrESQL TD : 2h
SEQUENCE 8 d’administration de bases de données TP : 2h
- Plateforme Oracle TD : 4h
3
SOMMAIRE
Objectifs du cours
Fiche de progression
I- Rappels sur les notions fondamentales ............................................................................................ 6

1- Qu’est-ce qu’une base de données ? .......................................................................................... 6
2- Quelles en sont les utilisations ? ................................................................................................. 6
3- Qui en sont les utilisateurs potentiels ? ...................................................................................... 8
4- Environnements des bases de données ...................................................................................... 8
5- Origine d’une base de données ................................................................................................. 12
II- Modèles de base de données .......................................................................................................... 12
1- Modèle hiérarchique ................................................................................................................. 12
2- Modèle réseau........................................................................................................................... 12
3- Modèle relationnel .................................................................................................................... 13
4- Modèle objet ............................................................................................................................. 13
III- Système de gestion de base de données (SGBD) ........................................................................ 13
1- Principes de fonctionnement .................................................................................................... 13
2- Objectifs..................................................................................................................................... 14
3- Quelques exemples de SGBD .................................................................................................... 15
IV- Conception d’une base de données.............................................................................................. 15
1- Méthode de conception ............................................................................................................ 16
2- Conception d’une application ................................................................................................... 17
3- Caractéristiques d’une bonne base de données ....................................................................... 17
Synthèse ................................................................................................................................................ 21
Chapitre 2 : Modèle relationnel de bases de données
Introduction ......................................................................................................................................... 22
I- Présentation du modèle ................................................................................................................... 22
II- Éléments constitutifs du modèle Logique .................................................................................... 23
III- Règles de passage du modèle conceptuel au modèle logique .................................................... 23
Synthèse ................................................................................................................................................ 26
4
Chapitre 3 : Administration de bases de données
Introduction ......................................................................................................................................... 27
I- Le métier........................................................................................................................................... 27
1. Rôles des DBA ................................................................................................................................ 28
2. Catégories de DBA ......................................................................................................................... 31
3. Missions principales ...................................................................................................................... 31
II- Outils du DBA ................................................................................................................................ 32
III- Compétences techniques .............................................................................................................. 33
1. Conditions générales d'exercice de la profession ......................................................................... 34
2. Qualités personnelles .................................................................................................................... 34
Synthèse ................................................................................................................................................ 34
Chapitre 4 : Choix de plateforme d’administration de bases de données
Introduction ......................................................................................................................................... 35
Références bibliographiques
5
I- Rappels sur les notions fondamentales
1- Qu’est-ce qu’une base de données ?
Une base de données est un mécanisme qui permet de stocker des informations de façon
organisée et de les retrouver. Il est possible de rechercher des données satisfaisant des critères
particuliers, si toutefois elles ont été organisées convenablement. En d’autres termes, la façon
de stocker les données dans la base détermine les possibilités de recherche par critères. Il est
également possible d’ajouter, de modifier ou de supprimer des données de la base.
Des exemples de bases de données sont :
- Carnet d’adresses ;
- Annuaire téléphonique ;
- Fichier bibliothèque ;
- Librairie en ligne ;
- Logiciel de comptabilité personnelle ;
- Carte routière.
2- Quelles en sont les utilisations ?
Prenons l’exemple d’une entreprise qui utilise des meubles classeurs répartis dans plusieurs
pièces pour stocker des informations. La gestion des informations d’un meuble classeur
représente certainement l’un des processus manuels les plus classiques que nous connaissons.
Des dossiers sont triés et rangés dans les tiroirs des classeurs. Les informations sont placées
dans les dossiers individuels de chaque tiroir. Pour retrouver l’enregistrement d’un employé, le
personnel doit se rendre dans la bonne pièce, puis ouvrir le bon classeur, le bon tiroir et enfin
le bon dossier. Que l’on procède manuellement ou que l’on utilise une base de données, le
classement est la clé de la gestion des informations.
D’autres exemples de processus manuels sont :

- Travailler avec des clients par téléphone ;
- Recevoir les commandes d’un client ;
- Livrer des produits à un client ;
- Interroger un employé ;
6
- Chercher un curriculum vitae dans un classeur ;
- Calculer le solde d’un compte chèque ;
- Remplir et envoyer un récépissé de dépôt ;
- Calculer les bénéfices de la journée ;
- Comparer les recettes et les dépenses ;
- Traiter les feuilles de présence.
Il est possible d’automatiser (informatiser) partiellement ou complètement de nombreux

processus manuels associés à une activité en recourant à une base de données. Parmi les
utilisations les plus courantes des bases de données, on a :
- Le suivi des statistiques et des tendances à long terme ;
- La réduction ou la suppression de documents papier ;
- La gestion des différents types de transactions ;
- La gestion des données historiques
Considérons le suivi des statistiques et des tendances à long terme en prenant l’exemple d’une
publicité et d’un programme de téléachat. Les statistiques utilisées portent sur les ventes
mensuelles de l’année en cours et des années précédentes, les produits les plus vendus sur
telle ou telle période, les marchandises les plus vendues en valeur absolue, la fréquence de
commandes de tel ou tel produit, etc. Les tendances concernent les produits les plus
demandés, les périodes les plus favorables et les types de clients susceptibles de commander
un produit plutôt qu’un autre. A l’aide de statistiques et des tendances, il est possible de
connaître la marchandise à proposer, la période à laquelle la présenter, le type de rabais et
l’heure de diffusion d’une éventuelle publicité.
Une base de données contribue à réduire ou à supprimer le volume de papier manipulé.

Prenons l’exemple d’un service de ressources humaines qui gère des centaines de curriculum
vitæ. Le stockage de ces documents s’effectue de façon classique dans un classeur dans un
ordre qui permet de les retrouver facilement. Pour sélectionner le curriculum vitæ de toutes
les personnes qui possèdent telle ou telle aptitude, il est nécessaire de lire tous les documents,
ce qui peut demander des heures. Quand les informations sont stockées dans une base de
données, on obtient les mêmes résultats en quelques secondes.
7
3- Qui en sont les utilisateurs potentiels ?
Banquiers, avocats, comptables, représentants de service clientèle, employés à la saisie de

données, etc. les utilisateurs potentiels des bases de données se retrouvent dans pratiquement
toutes les professions. Leurs besoins varient. Le banquier par exemple conserve les comptes
des particuliers et des sociétés, les lignes de crédits, les prêts personnels, les prêts d’entreprise,
etc. Lorsqu’un client souhaite clôturer son compte, le banquier contrôle les informations
personnelles du client en question.
Lorsque vous utilisez votre carte de crédit pour retirer de l’argent dans une banque, vous vous
connectez à une base de données … parfois sans le savoir ! Au fur et à mesure que l’argent est
retiré, le montant correspondant est déduit du solde de votre compte. Lorsque vous transférez
de l’argent du compte d’épargne au compte courant, la somme est créditée sur le compte courant
et débitée du compte d’épargne.
Lorsque vous chargez votre téléphone portable, vous vous connectez à une base de données. Le
crédit correspondant à votre carte vous est allouez si le numéro composé se trouve dans la base
de données correspondante. Au fur et à mesure que vous effectuez des appels, votre crédit est
consommé selon la tarification établie.
Lorsque vous effectuez une recherche dans Google, vous vous connectez à une base de données
qui contient des tonnes et des tonnes d’informations se rapportant à différents domaines.
4- Environnements des bases de données
Un environnement de base de données est en quelque sorte le lieu de résidence d’une base
de données, avec des moyens d’accès aux données. Les utilisateurs réalisent différents types de
tâches et leurs besoins varient selon qu’ils extraient des données, les modifient ou en créent de
nouvelles. On distingue les utilisateurs internes à l’environnement et les utilisateurs externes.
Certains utilisateurs internes peuvent être physiquement ou logiquement interdits d’accès aux
données.
Les trois environnements de base de données les plus courants sont :

 L’environnement de mainframe ;
8
 L’environnement client/serveur ;
 L’environnement informatique Internet.
a- Environnement de mainframe
L’environnement classique des premiers systèmes de bases de données est l’environnement
de mainframe, essentiellement constitué d’un ordinateur central puissant (mainframe) qui prend
en charge de nombreuses connexions d’utilisateurs. Plusieurs terminaux passifs sont connectés
au mainframe et permettent aux utilisateurs de communiquer avec le supercalculateur. Les
terminaux sont des extensions du mainframe et non des ordinateurs indépendants ; ils ne
pensent » pas par eux-mêmes, mais comptent sur le mainframe pour effectuer tous les
traitements.
Terminal Mainframe
Terminal
Appli
catio
n
BD
Terminal
Terminal
Figure 1. Une base de données dans un environnement mainframe
L’environnement mainframe pose de nombreux problèmes. En particulier, un terminal passif

ne peut communiquer qu’avec l’ordinateur principal. Des tâches, notamment des processus
manuels, l’utilisation d’un traitement de texte, ou un ordinateur personnel (PC) ne s’interfacent
pas toujours avec le mainframe. La plupart des entreprises actuelles ont fait migrer leurs
systèmes vers l’environnement client/serveur pour des raisons que nous étudierons dans la
prochaine section.
b- Environnement client/serveur
L’environnement client/serveur est probablement le plus largement répandu de nos jours. Il
nécessite un ordinateur principal appelé serveur et un ou plusieurs ordinateurs personnels
appelés clients, connectés en réseau au serveur. La base de données réside dans le serveur et
toute personne ayant besoin d’y accéder utilise un des postes clients du réseau.
9
PC PC
Intranet (réseau
PC interne) de l’entreprise
BD
PC Seveur
Copie
application
Figure 2. Une base de données dans un environnement client/serveur
Chaque poste client est un PC sur lequel on installe une application qui permet à l’utilisateur
d’accéder à la base de données du serveur. L’application située sur le client transmet à la base
des requêtes de données ou des transactions à travers le réseau. Les informations transitent vers
la base de données grâce à une connexion de base de données ouverte (ODBC, Open DataBase
Connectivity) ou un autre logiciel de réseau. L’environnement client/serveur pose notamment
le problème suivant : lorsqu’une nouvelle version de l’application est développée, il faut la
réinstaller et la reconfigurer sur chaque pose client, ce qui est parfois difficile et prend beaucoup
de temps.
L’utilisation et la maintenance d’une application sur un poste client imposent un coût

supplémentaire, mais présentent de nombreux avantages. En particulier, grâce à leurs propres
ressources, les clients peuvent exécuter une partie du traitement de l’application et décharger
ainsi le serveur qui n’a plus à assumer seul la totalité du travail. Les PC sont donc capables de
« penser » par eux-mêmes et d’exécuter d’autres applications, ce qui rend les utilisateurs plus
productifs. Exemple, une personne peut être connectée à la base de données du serveur tout en
travaillant sur un document et en lisant un e-mail. La technologie client/serveur résout ainsi de
nombreux problèmes inhérents à l’environnement de mainframe.
c- Environnement informatique Internet

Les environnements informatiques Internet et client/serveur se ressemblent en ce sens qu’ils
nécessitent un serveur, un réseau et un ou plusieurs clients. L’informatique Internet se distingue
toutefois par son ouverture sur Internet. Dans un environnement Internet, l’utilisateur a accès
10
aux ressources disponibles sur l’intranet de l’entreprise mais aussi à des bases de données
extérieures à l’intranet mais cela suppose l’utilisation de logiciels adaptés supplémentaires.
PC PC
Serveur
Intranet de
Intranet
l’entreprise BD
Locale
Serveur
Connexion
Web
Internet
BD PC
Web
Figure 3. Une base de données dans un environnement Internet
L’une des caractéristiques de l’informatique Internet, qui la rend puissante, est la transparence
de l’application pour l’utilisateur final. L’application est installée sur le serveur (serveur Web)
et nulle part ailleurs. L’utilisateur doit disposer d’une connexion à Internet et d’un navigateur
Web sur son PC afin de se connecter à l’URL du serveur Web. Ce dernier accède à la base de
données et renvoie les informations demandées au navigateur Web, lequel les affiche sur le PC
de l’utilisateur. Dans l’environnement Internet, la configuration et la maintenance de
l’application de l’utilisateur final sont simplifiées car il n’y a rien à installer, à configurer ou à
entretenir sur les postes clients ! Les modifications ou les configurations se font sur une seule
machine, le serveur web, ce qui limite les risques de configurations incohérentes et l’installation
de versions de logiciels incompatibles sur les clients et le serveur.
Les bases de données de la plupart des entreprises actuelles fonctionnent dans un
environnement client/serveur, mais l’informatique Internet ou la combinaison informatique
Internet et client/serveur tend à se développer.
11
5- Origine d’une base de données
La modélisation d’une activité, qui est à l’origine de toute base de données, consiste à
évaluer et à distinguer les tâches quotidiennes d’une activité. En ce sens, il faut converser avec
les décideurs de l’entreprise, ceux qui manipulent les données, ceux qui les exploitent, etc. Les
concepteurs de la base de données doivent apprendre à connaître l’activité et les utilisateurs de
la future base. Sans cette connaissance, il est impossible de créer un modèle de données complet
et exact. Il est de la responsabilité du concepteur d’évaluer les besoins et de les formuler dans
un modèle opérationnel, lequel deviendra une base de données fonctionnelle dotée d’une
application conviviale pour l’utilisateur finale.
II- Modèles de base de données
1- 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.
2- 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.
12
3- 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.
En 1970, Codd (1970) 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 puissent être jamais gérées 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é.
C’est dans ce type de modèle que se situe ce cours de base de données.
4- Modèle objet
La notion de bases de données objet ou relationnel-objet est plus récente et encore en phase de
recherche et de développement. Elle sera très probablement ajoutée au modèle relationnel.
III- Système de gestion de base de données (SGBD)
1- 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.
13
Le modèle client/serveur est assez souvent implémenté au moyen de l’interface des sockets
(voir le cours de réseau) ; le réseau étant Internet. Une variante de ce modèle est le modèle ASP
(Application Service Provider). Dans ce modèle, le client s’adresse à un mandataire (broker)
qui le met en relation avec un SGBD capable de résoudre la requête. La requête est ensuite
directement envoyée au SGBD sélectionné qui résout et retourne le résultat directement au
client.
Quel que soit le modèle, un des problèmes fondamentaux à prendre en compte est la cohérence
des données. 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.
2- 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
14
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 terminé l’opération interrompue.
3- Quelques exemples de SGBD
Il existe de nombreux systèmes de gestion de bases de données, en voici une liste non
exhaustive :
• PostgreSQL ;
• MySQL ;
• IBM DB2 ;
• Microsoft SQL;
• Sybase ;
• Oracle ;
• Informix ;
IV- Conception d’une base de données
Il revient donc au concepteur de la base de données d’évaluer les besoins et de les formuler
dans un modèle opérationnel, lequel deviendra une base de données fonctionnelle dotée d’une
application conviviale pour l’utilisateur final. Avant de s’atteler à la tâche, le concepteur d’une
15
base de données doit prendre le temps de connaître l’activité de l’organisme. Il s’agit de
déterminer les entités, données et règles internes à l’organisme, puis de convertir ces attributs
de l’activité en modèle d’activité, puis le modèle d’activité en modèle de base de données, en
suivant une méthode de conception. Le concepteur doit également posséder une solide
connaissance du modèle de base de données choisi (le modèle relationnel par exemple).
1- Méthode de conception
Une méthode de conception permet de concevoir une base de données en suivant un plan établi
dès le départ. Les avantages à utiliser une méthode de conception sont multiples, en particulier :
- Elle conduit pas à pas dans le processus de conception de la base
- Elle diminue le nombre d’essais et d’erreurs, voire elle les supprime,
- Les plans de conception, la représentation des besoins et autres indications facilitent la
documentation de la base de données et de l’application.
- L’organisation et la planification rendent plus aisées les modifications ultérieures de la
base de données.
Concevoir une base de données en fonction d’un modèle d’activité consiste à convertir les
composants du modèle d’activité, comme les entités et les attributs, en tables et vues. Si
nécessaire, le concepteur ajoute des contraintes aux colonnes des tables afin de mettre en place
l’intégrité des données et l’intégrité référentielle. La conception de la base de données est
terminée une fois que le modèle complet de l’activité (processus opérationnels, règles, entités)
se trouve converti en une base de données opérationnelle dans laquelle il est possible de stocker,
de modifier et de récupérer facilement les données de l’entreprise.
EN RESUME, la démarche préconisée pour concevoir et réaliser une base de données est la
suivante :
Etape 1. Concevoir le modèle conceptuel des données (MCD). Cela consiste à :
1. Déterminer les entités associées à cette activité.
2. Déterminer les relations qui existent entre ces entités.
3. Déterminer les propriétés de ces entités et de ces relations ainsi que les valeurs que ces
propriétés peuvent prendre.
4. Résumer tout cela dans un graphe appelé MCD
16
Etape 2. Transformer le modèle conceptuel des données (MCD) en un modèle logique des
données (MLD).
Etape 3. Implémenter la base de données en utilisant un logiciel de bases de données tels que
Access ou Oracle.
2- Conception d’une application
Concevoir une application consiste à transformer les processus opérationnels en application

conviviale qui permet à l’utilisateur d’accéder aisément aux données de la base. Une application
type est constituée par exemple de requêtes et de rapports prêts à l’emploi, d’un ensemble de
formulaires facilitant la création, la mise à jour, ou l’émission de requêtes. Parmi les outils de
développement courants d’une application, citons Oracle Designer, Oracle Developer/2000,
Visual Basic, PowerBuilder, Visual C++, Delphi.
3- Caractéristiques d’une bonne base de données
Une bonne base de données prend en compte les besoins du client ; elle découle de la vision
qu’en ont l’utilisateur final, les administrateurs de la base de la direction. Il est important de
connaître les caractéristiques d’une bonne base de données avant d’envisager d’en concevoir
une. De façon générale, une base de données est de qualité quand :
- Les besoins de stockage des données sont satisfaits
- L’utilisateur final accède facilement aux données
- Les données sont sécurisées
- Les données sont exactes et faciles à gérer
- Les performances globales de la base sont acceptables
- La quantité de données redondantes est réduite au minimum.
a- Besoins de stockage satisfaits

Le rôle le plus évident d’une base de données est le stockage de données. Pour savoir si elle
remplit correctement ce rôle, il est utile de se poser les questions suivantes :
- Tous les besoins de stockage sont-ils satisfaits ?
- Toutes les données sont-elles stockées efficacement ?
- Le modèle de base de données utilisé permet-il de gérer le volume de données et la
complexité des relations de l’activité ?
17
- Le matériel et le logiciel de base de données conviennent-ils aux besoins de stockage ?
- Est-il facile d’accéder aux données stockées hors ligne (i.e. archivées hors de la base) ?
- Toutes les données non indispensables en ligne sont-elles archivées sur un périphérique de
stockage hors ligne ?
Répondre favorablement à toutes ces questions suppose :

- De planifier soigneusement la conception de la base de données
- De choisir un logiciel de base de données adapté pour implémenter la base, sachant que
certains éditeurs de logiciels proposent des fonctionnalités que n’offre pas la concurrence
- De prévoir que les besoins de stockage dépassent à un moment donné les limites physiques
du matériel, même si le matériel et l’espace disque dédiés à la base sont initialement
convenables.
- De prendre en compte le type de données stockées
- D’archiver des données non indispensables en ligne pour désengorger la base. Si aucune
donnée n’est archivée, il peut apparaître que les besoins de stockage ne sont pas atteints.
b- Données disponibles
Les données doivent être à la disposition de l’utilisateur final, à tout moment, quand il en a
besoins. Si les données ne sont pas disponibles lorsqu’on en a besoins, la base de données ne
remplit pas son rôle. Lorsqu’il est nécessaire d’interrompre le fonctionnement d’une base de
données, l’opération doit être programmée à des heures de faible activité. Mais parfois des
interruptions de produisent à cause de facteurs liés à la conception de la base de données.
La disponibilité des données est également liée aux performances de la base que l’utilisateur
attend et perçoit. Supposons qu’un utilisateur lance une requête. La réaction de la base de
données demande plusieurs secondes et l’affichage à l’écran des résultats demande encore
quelques secondes supplémentaires. Ceci est suffisant pour que l’utilisateur perçoive la base
comme lente et peu performante. Cela ne signifie pas que l’environnement de la base de
données a été mal conçu et mal implémenté ou qu’il n’est pas performant ; il ne satisfait tout
simplement pas les attentes de l’utilisateur. Quelques modifications mineures de l’appliquent
suffisent parfois pour améliorer les performances de la base de données.
18
c- Données protégées
Dès que les données sont stockées dans la base de données, il faut les protéger des personnes
non autorisées à les visualiser. Pour savoir si la sécurité de la base de données est assurée, il est
important de se poser les questions suivantes :
- Existe-il une sécurité dans la base de données ?
- Les données sont-elles protégées des utilisateurs extérieurs et des utilisateurs internes ?
- Des utilisateurs non autorisés peuvent-ils facilement accéder aux données ?
- Y a-t-il des brèches dans la sécurité depuis l’implémentation de la base de données ?
- Est-il facile de limiter l’accès à des groupes d’utilisateurs dans les limites de visibilité de la
base de données ?
- Est-il facile d’accorder ou de supprimer le droit d’accès aux données à divers groupes
d’utilisateurs ?
En l’absence de mesures de sécurité, la base de données peut être corrompue sans difficulté,
volontairement ou non. Il faut donc interdire l’accès à la base de données aux individus qui
n’ont pas besoin de la consulter. En règle générale, on limite l’accès à un niveau très bas. De
nombreuses bases de données sont conçues avec peu de sécurité. Des problèmes peuvent se
poser et révéler cette insuffisance. Il revient alors aux décideurs de déterminer si cela se justifie
ou non de re-concevoir intégralement la base.
d- Données exactes
Il faut non seulement protéger les données contre les utilisateurs non autorisés, mais aussi
veiller à ce que les utilisateurs autorisés n’introduisent pas de valeurs erronées. Comment
procéder ? En utilisant principalement des contraintes. Les contraintes sont généralement
appliquées au niveau des colonnes des tables et assurent le contrôle des valeurs, sans empêcher
toutefois l’insertion de données inexactes. Il appartient aussi à l’utilisateur final de gérer
correctement les valeurs saisies.
Certaines précautions sont à prendre afin de garantir autant que faire se peut la justesse des
données. Pour évaluer si les mesures prises sont suffisantes, il faut se poser les questions
suivantes :
- Des contraintes d’intégrité référentielles (contraintes sur les clés primaires et étrangères)
sont-elles définies ?
- D’autres contraintes vérifient-elles l’absence d’unicité ou l’invalidité des données ?
- Les relations entre les données sont-elles facilement maintenues à l’intérieure de la base ?
19
- L’utilisateur final peut-il introduire sans difficulté des données invalides dans la base ?
- Outre les montages et les contraintes définis au niveau de la base de données, des mesures
de sécurité sont-elles prises au niveau de l’interface de l’application ?
- Des tables de code sont-elles définies pour les données communes ?
Cohérence et exactitude des données sont des notions proches mais différentes. Il faut obliger
les utilisateurs à saisir les données de façon cohérente car l’insertion de valeurs incohérentes
altère la base et affecte l’intégrité des données.
e- Performances acceptables
Les performances d’une base de données sont essentielles pour l’utilisateur final, la direction,
l’administrateur de la base, etc. Si l’utilisateur final n’est pas satisfait, le client ne l’est pas non
plus. Si le client est mécontent, la direction l’est aussi. Et si la direction n’est pas satisfaite, rien
ne va plus ! Les questions suivantes permettent d’évaluer si les performances d’une base de
données sont acceptables :
- Quel est le temps de réponse pour des transactions et les plus petites requêtes ?
- La base de données fonctionne-t-elle comme le veut l’utilisateur final ?
- Comment la base de données réagit-elle aux pointes d’activité des transactions ?
- Les traitements par lots comme les chargements massifs de données ou les requêtes de gros
volumes de données sont-ils rapidement effectués ?
- Les éventuels problèmes de performances sont-ils liés à la conception de la base de données,
à l’interface, au réseau ou au matériel ?
Il existe souvent une différence notable entre les performances escomptées par l’utilisateur
final, par exemple un temps de réponse instantané, et celles qu’il est possible de réaliser. Les
temps de réponse généralement acceptables pour obtenir un enregistrement ou effecteur une
transaction relativement petite se situent entre une et cinq secondes alors que les traitements par
lots et les requêtes de gros volumes de données sont évidemment plus longs. Les temps de
réponse dépendent de la conception de la base de données et de l’application, de la vitesse du
matériel et du réseau. Si le client et l’utilisateur final jugent les performances inacceptables, il
faut procéder à une évaluation précise afin d’identifier les points faibles.
20
f- Minimum de données redondantes
Dans la mesure du possible, chaque donnée ne doit figurer qu’une fois dans la base. La
prolifération des occurrences d’une base même donnée complique les mises à jour (suppression
ou ajout) de valeurs en ce sens qu’il faut effectuer les opérations à plusieurs endroits. Ces
interventions successives multiplient le danger d’introduire des valeurs incohérentes.
Outre les risques d’incohérence, il est délicat de récupérer et de modifier une donnée
redondante. Il est donc extrêmement important de limiter les redondances au moment de la
conception de la base de données.
Synthèse
« EN RESUME, modéliser une activité exige de l’évaluer. Cela suppose la définition des
processus opérationnels, des règles de gestion et des catégories de données. Les processus
opérationnels sont les tâches effectuées par les personnes dans le cadre d’une activité. Les règles
de gestion déterminent la façon de structurer le modèle de l’activité, les catégories de données
nécessaires, et la façon de les modifier et d’y accéder. Il est important de conduire des entretiens
avec les acteurs clés de l’activité et les utilisateurs finals, pour bien appréhender tous les besoins
de l’activité. Le modèle d’activité est complet lorsque tous les besoins ont été identifiés et
modélisés en objets d’activité, comme les entités et les attributs. Les entités sont des catégories
de données, et les attributs des données spécifiques à l’intérieur des entités »
21
Chapitre 2 : Modèle relationnel de Bases de données
Introduction
Le modèle relationnel a déjà été introduit dans les cours précédents.
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.
I- Présentation du modèle
Le succès du modèle relationnel auprès des chercheurs, concepteurs et utilisateurs est dû à la

puissance et à la simplicité de ses concepts. En outre, contrairement à certains autres modèles,
il repose sur des bases théoriques solides, notamment la théorie des ensembles et la logique des
prédicats du premier ordre.
Les objectifs du modèle relationnel sont :
- Proposer des schémas de données faciles à utiliser ;

- Améliorer l’indépendance logique et physique ;
- Mettre à la disposition des utilisateurs des langages de haut niveau ;
- Optimiser les accès à la base de données ;
- Améliorer l’intégrité et la confidentialité ;
- Fournir une approche méthodologique dans la construction des schémas.
22
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é.
Au modèle relationnel est associée à la théorie de la normalisation des relations qui permet de
se débarrasser des incohérences au moment de la conception d’une base de données
relationnelle.
II- Éléments constitutifs du modèle Logique
La représentation du modèle logique s’appuie sur trois concepts de base :
- La clé primaire,
- La clé étrangère,
Le passage du modèle conceptuel (entité-association) au modèle Logique (relationnel).
Clé primaire : La clé primaire d’une relation est une de ses clés candidates. Pour signaler la
clé primaire, ses attributs sont généralement soulignés.
Clé étrangère : Une clé étrangère dans une relation est formée d’un ou plusieurs attributs qui
constituent une clé primaire dans une autre relation
Schéma relationnel : Un schéma relationnel est constitué par l’ensemble des schémas de
relation.
III- Règles de passage du modèle conceptuel au modèle

logique
Règle 1. Un conceptuel se transforme en relation. Chaque propriété se transforme en attribut.

L’identifiant de l’objet devient la clé primaire de la table.
23
CLIENT
N° client
Nom client
Prénom client
Adresse client
CLIENT (N° CLIENT, NOM CLIENT, PRENOM CLIENT, ADRESSE CLIENT)
Règle 2. Une relation binaire (ou réflexive) ayant des cardinalités (1,1) – (1,n) ou (1,1) – (0,n)
se traduit par une redondance (glissement, migration) de l’identifiant de l’objet à cardinalité
(1,n) ou (0,n) dans la relation issue de l’objet à cardinalité (1,1). L’identifiant de l’objet à
cardinalité (1,1) devient la clé primaire de la relation. La propriété dupliquée devient clé
étrangère dans la relation. Si la relation est réflexive, c’est l’identifiant de l’objet qui est
dupliqué dans la relation issue de ce même objet après avoir été renommé.
Si la relation (conceptuelle) est porteuse de propriétés, celles-ci de retrouvent comme attributs

dans la relation issue de l’objet à cardinalités (1,1).
Exemple 1.
RG1 : « Un employé travaille dans un service et un seul »
RG2 : « Un service regroupe un ou plusieurs employés
SALARIE SERVICE
N° salarié (1,1) REGROUPE (1,n) Code service
Nom du salarié Nom service
Prénom salarié Nb employés
Qualification Spécialisation
SERVICE (CODE SERVICE, NOM SERVICE, NB EMPLOYES, SPECIALISATION)
SALARIE (N° SALARIE, NOM DU SALARIE, PRENOM DU SALARIE, QUALIFICATION, CODE SERVICE)
24
Exemple 2.
RG1 : « Un employé peut avoir un et seul supérieur hiérarchique »
RG2 : « Un employé peut être le supérieur hiérarchique de plusieurs employés »
EMPLOYE (0,1)
ID employé
SUPERIEUR
Nom employé
Prénom employé
(0,n)
EMPLOYE (ID EMPLOYE, NOM EMPLOYE, PRENOM EMPLOYE, ID SUPERIEUR)
Règle 3. Une relation n-aire du modèle conceptuelle, porteuse ou non de propriétés, se

transforme en une relation du schéma relationnel ayant comme clé primaire composite les
attributs issus des identifiants des objets participant à cette relation conceptuelle.
Cas particulier :
Une relation binaire à cardinalités (0,1) – (0,n) ou (0,1) – (1,n) se traduit soit suivant la Règle
2, soit suivant la Règle 3.
Exemple
RG 1 : « Une commande concerne un ou plusieurs articles »
RG2 : « Un article peut être concerné par plusieurs commandes »
COMMANDE ARTICLE
CONCENER
N° commande (1,n) (0,n) N° article
Date commande Libellé article
Prix unitaire
Quantité en stock
COMMANDE (N° COMMANDE, DATE COMMANDE)

25
ARTICLE (N° ARTICLE, LIBELLE ARTICLE, PRIX UNITAIRE, QUANTITE EN STOCK)
CONCERNER(N° COMMANDE, N° ARTICLE, QUANTITE COMMANDE)
Règle 4. La relation réflexive, si elle ne répond pas à la définition de la Règle 2 se traduit par
une relation porteuse de deux attributs, duplications de l’identifiant de l’objet, et toutes deux
renommées. Cet ensemble d’attributs constitue la clé primaire composite de cette relation
relationnelle.
Exemple.
RG1 : « Un matériel peut être composé de plusieurs matériels »
RG2 : « Un matériel peut se retrouvé dans plusieurs autres matériels »
MATERIEL (0,n)
COMPOSE
N° matériel
Nom matériel
Type matériel
(0,n)
COMPOSE(N° MATERIELB, N° MATERIELB, QUANTITE)
MATERIEL(N° MATERIEL, NOM MATERIEL, TYPE MATERIEL)
Synthèse
Le modèle relationnel ainsi présenté dans le cadre de ce chapitre constitue une brique de base
pour l’implémentation et l’administration des bases de données dites relationnelles. Dans les
prochains chapitres, quelques plateforme d’administration de bases de données sont présentées
ainsi que les critères de choix des plateformes.
26

Administration Des BD

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Administration Des BD

Загружено:

Авторское право:

Доступные форматы

UNIVERSITE DE DOUALA

Faculté des Sciences

Département de Mathématiques et Informatique

Administration des Bases de

Année Académique 2019/2020

Préparer des futurs informaticiens orientés vers la conception et l'administration de base de

 Concevoir une base de données relationnelle.

Chapitre 1 : Bases de données relationnelles

Chapitre 2 : Modèle relationnel de bases de données

Chapitre 3 : Administration de bases de données

Chapitre 4 : Choix de plateforme d’administration de bases de données

PROCESSUS GENERAL DU DEROULEMENT DE CHAQUE COURS

SEQUENCES THEMES DEVELOPPES DUREE

Chapitre 1 : Bases de données relationnelles CM : 4h

Chapitre 1 : Bases de données relationnelles CM : 4h

Chapitre 2 : Modèle relationnel de bases de CM : 4h

Chapitre 1 : Bases de données relationnelles

I- Rappels sur les notions fondamentales ............................................................................................ 6

Chapitre 2 : Modèle relationnel de bases de données

Chapitre 4 : Choix de plateforme d’administration de bases de données

I- Rappels sur les notions fondamentales

1- Qu’est-ce qu’une base de données ?

2- Quelles en sont les utilisations ?

D’autres exemples de processus manuels sont :

Il est possible d’automatiser (informatiser) partiellement ou complètement de nombreux

Une base de données contribue à réduire ou à supprimer le volume de papier manipulé.

Banquiers, avocats, comptables, représentants de service clientèle, employés à la saisie de

4- Environnements des bases de données

Les trois environnements de base de données les plus courants sont :

Figure 1. Une base de données dans un environnement mainframe

L’environnement mainframe pose de nombreux problèmes. En particulier, un terminal passif

L’utilisation et la maintenance d’une application sur un poste client imposent un coût

c- Environnement informatique Internet

Figure 3. Une base de données dans un environnement Internet

II- Modèles de base de données

Le modèle réseau est en mesure de lever de nombreuses difficultés du modèle hiérarchique

III- Système de gestion de base de données (SGBD)

3- Quelques exemples de SGBD

IV- Conception d’une base de données

2- Conception d’une application

Concevoir une application consiste à transformer les processus opérationnels en application

3- Caractéristiques d’une bonne base de données

a- Besoins de stockage satisfaits

Répondre favorablement à toutes ces questions suppose :

Le modèle relationnel a déjà été introduit dans les cours précédents.

Le succès du modèle relationnel auprès des chercheurs, concepteurs et utilisateurs est dû à la

Les objectifs du modèle relationnel sont :

- Proposer des schémas de données faciles à utiliser ;

II- Éléments constitutifs du modèle Logique

La représentation du modèle logique s’appuie sur trois concepts de base :

Le passage du modèle conceptuel (entité-association) au modèle Logique (relationnel).

III- Règles de passage du modèle conceptuel au modèle

Règle 1. Un conceptuel se transforme en relation. Chaque propriété se transforme en attribut.

CLIENT (N° CLIENT, NOM CLIENT, PRENOM CLIENT, ADRESSE CLIENT)

Si la relation (conceptuelle) est porteuse de propriétés, celles-ci de retrouvent comme attributs

RG1 : « Un employé travaille dans un service et un seul »

RG2 : « Un service regroupe un ou plusieurs employés

SERVICE (CODE SERVICE, NOM SERVICE, NB EMPLOYES, SPECIALISATION)

RG1 : « Un employé peut avoir un et seul supérieur hiérarchique »

RG2 : « Un employé peut être le supérieur hiérarchique de plusieurs employés »

EMPLOYE (ID EMPLOYE, NOM EMPLOYE, PRENOM EMPLOYE, ID SUPERIEUR)

Règle 3. Une relation n-aire du modèle conceptuelle, porteuse ou non de propriétés, se

RG 1 : « Une commande concerne un ou plusieurs articles »