Vous êtes sur la page 1sur 7

CHAPITRE I : INTRODUCTION AUX BASES DE DONNEES

I- RAPPELS SUR L’APPROCHE CLASSIQUE

I-1. Les Limites


Les limites des organisations classiques de fichiers sont dues essentiellement à la
dépendance très forte entre les programmes qui contiennent la description des données et les
données elles-mêmes.
Dans une méthodologie de mise en place d’applications selon un plan à 5 ans par
exemple, de nouveaux fichiers sont créés pour répondre aux nouveaux besoins. Ceci est lié
aux difficultés de modifier ceux déjà existants car toute modification de fichier : structure,
format de données, implique une modification des programmes, ce qui conduit très vite à une
prolifération des fichiers.
Exemple de planning :

Années Applications Fichiers


n Gestion de stocks STOCK
n+1 Facturation TARIF, CLIENT
n+2 Comptabilité client COMPTE
n+3 Comptabilité générale PERSONNEL
Au terme de ce plan et après une dizaine d’années d’exploitation : 500 à 1000
programmes réalisent les différentes applications et n’utilisent pas moins de 50 fichiers
différents.
Deux conséquences évidentes :

- Une maintenance très lourde des programmes (cette seule activité représente
parfois 75% des efforts de l’équipe analyse-programmation) d’où une baisse
considérable de la productivité.
- Une très forte redondance des données : dans l’exemple précédent, les fichiers
CLIENT et COMPTE ont en commun de nombreuses données (Nom, Adresse,
etc.) de même pour les fichiers TARIF et STOCK qui contiennent tous les deux les
données relatives aux produits (Code, Désignation, Conditionnement, etc.).

Des erreurs lors des saisies et des mises à jour successives des différents fichiers
conduisent à une perte de cohérence et le contenu des fichiers n’est plus l’image des données
réelles de l’organisation (par exemple, deux adresses différentes du même client dans deux
fichiers distincts)
Une autre limite vient de la difficulté de pouvoir prendre en compte les données et les
relations entre ces données.

I-2. Redondance et Incohérence

Il s’agit de trouver certaines données dupliquées sur plusieurs fichiers. Cette


redondance engendre des coûts de stockage et elle pose des problèmes aussi bien techniques (
cohérence et mises à jour ) que décisionnels.
Exemple : On dispose de deux applications indépendantes « SCOLARITE » et
« PERSONNEL » qui utilisent le fichier « ENSEIGNANT ».

Page: 1
Ce fichier est géré dans la première application et dans la deuxième.

Fichier ENSEIGNANT Fichier ENSEIGNANT

Matricule : A70000545 Matricule : 70000545


Nom : Anouar Nom : Anouar
. .
. .
Grade : Assistant Grade : Maître-assistant

SCOLARITE PERSONNEL

On remarque, que pour la même personne, on lui associe deux grades différents; c’est
une incohérence des données ( la même donnée ayant deux valeurs différentes ) due à la
redondance ( duplication de la même information ).

I-3. Inconvénients de l'Approche Classique

I-3-1. Redondance des informations


- Lourdeur des saisies.
- Lourdeur des mises à jour.
- Perte de cohérence.

I-3-2. Dépendance données/programmes


- Difficulté des modifications.
- Maintenance très lourde.
- Système peu souple.
- Système peu évolutif.

I-3-3. Absence d’informations de synthèse


- Difficulté lors de la prise de décision.
- Lourdeur au niveau des prestations.
- Temps de réponse très long pour certaines informations résultants de
traitements de plusieurs fichiers.

I-3-4. Absence de liens entre fichiers


- Peu de relations entre les données.
- Peu de points d’entrée ( un seul par fichier ).
- Chemins logiques très pauvres.

I-3-5. Maintenance coûteuse


- Lourdeur de la maintenance.
- Coût élevé de la maintenance.
- Baisse de la productivité.

Page: 2
II- L'APPROCHE BASE DE DONNEES

II-1. Historique
Suite aux problèmes d’incohérences et de redondance apparus, d’une part, et suite à la
lourdeur et au coût élevé de la maintenance, d’autre part, une conférence a été tenue en 1964,
à Santa Monica en Californie pour trouver des solutions à ces problèmes. C’est lors de cette
conférence, que le terme « base de donnée » est apparu.

II-2. Définition
Une base de données est un ensemble structuré de données enregistrés sur des supports
accessibles par l’ordinateur, représentant des informations du monde réel et pouvant être
interrogées et mises à jour simultanément et de façon sélective une communauté
d’utilisateurs.
Ces informations vont devoir être partagées par différents services qui n’ont pas les mêmes
besoins (service commercial, service financier, service marketing, etc.).

Outre les informations elles-mêmes, il faudra pouvoir également exploiter les relations
qui peuvent être établies entre elles pour créer les chemins logiques d’accès qui constitueront
les réponses aux requêtes des utilisateurs et offrir de nombreux points d’entrée.

II-3. schéma d’une base de données

D1
TRAITEMENTS
D2 CONTROLE & et/ou
MISE A JOUR INTERFACES

D3

Saisie Stockage Extraction Utilisation


D4

Une base de données nécessite :

 Un espace de stockage.
 Un logiciel permettant l’accès aux données : système de gestion de bases de données
(SGBD).

Page: 3
II-4. Système de Gestion de Bases de Données : SGBD

II-4-1. Définition :

Un SGBD est un ensemble de programmes permettant la création et l’exploitation des


bases de données.

P1
S
P2 G
B BD
P3 D

Le SGBD assure notamment l’interface entre la base de données physique et les


programmes d’application (P1, P2 et P3) qui réalisent des accès, des traitements et des mises à
jour. Contrairement aux programmes utilisés avec les fichiers classiques, ceux-ci ne
connaissent pas l’implémentation physique des données, ni leur format.

II-4-2. Fonctionnalités d’un SGBD :

- Recherche et mise à jour de l’information


- Contrôle des traitements
- Définition de la base de données (LDD)
- Contrôle de données (LCD)
- Manipulation des données (LMD)
- Protection de la base de données

II-5. Représentation de l'Environnement Base de Données

Utilisateur 1 Utilisateur 2 Utilisateur 3

INTERFACE

Disque Dur SGBD BD

ADMINISTRATEUR DE LA
BASE DE DONNEES

Page: 4
II-6. Administrateur de la Base de Données (DBA)

C’est le premier responsable de la base de données. Il peut être une personne ou un


groupe de personnes qui décident sur tout ce qui concerne la base de données.

Les principales fonctions d’un administrateur (DBA) sont les suivantes :

- Décide le contenu de la base.


- Définit les droits d’accès à la base.
- Contrôle les performances de la base.
- Fixe les stratégies de sauvegarde et de reprise.

III- OBJECTIFS DES BASES DE DONNEES

III-1. Intégration des données sans redondance

Les données sont regroupées en une ou plusieurs bases de données. Si ce type d’organisation
vise à supprimer la redondance, elle peut être acceptée dans des cas particuliers, soit dans une
même base, soit le plus souvent dans des bases distinctes.

III-2. Partage des ressources

Les ressources constituées par l’ensemble des matériels, des logiciels et des données
de la base de données doivent être partagées entre plusieurs utilisateurs. Les programmes
d’application doivent pouvoir réaliser des accès simultanés aux données pour des
interrogations ou des mises à jour avec des temps de réponse satisfaisants. Le SGBD doit
résoudre notamment les problèmes de conflits d’accès.

III-3. Indépendance des données et des programmes


Les accès réalisés par les programmes d’application à la base de données sont pris en
charge par le SGBD qui est le seul à connaître la description du format et de la structure
physique des données.Les programmes d’application sont écrits dans un langage appelé LMD
(Langage de Manipulation des Données) qui ne s’intéresse qu’à la structure logique des
données. La description de leur format et de leur structure physique est exprimée dans un
langage appelé LDD (Langage de Définition des Données) au moyen de modules transmis au
SGBD.
III-4. Intégrités des données et la cohérence
L’intégrité est le résultat d’une bonne protection des données contre les altérations ou
destructions accidentelles ou malveillantes - contre les risques dus aux transactions ou
opérations inachevées, ou aux accès concurrents.

Un SGBD doit assurer une bonne cohérence des données, c’est-à-dire se pré-munir contre les
risques qui viennent d’être évoqués afin que la base de données reste l’image fidèle du monde
réel qu’elle doit représenter.

III-5. La confidentialité
Un SGBD doit offrir des mécanismes pour définir des droits d’accès aux utilisateurs et
les vérifier.

Page: 5
Ces droits qui concernent des classes d’utilisateurs sont définis pour des opérations telles que
: lecture, mise à jour (modification), suppression, création.
Les règles de confidentialité sont fixées par l’administrateur de la base de données.
L’authentification de l’utilisateur (vérification des droits d’accès) peut s’effectuer par mot de
passe (le changer souvent) mais des techniques telles que badges ou code ou cartes à mémoire
peuvent être envisagées. Les règles d’accès peuvent donc être définies :
- pour des classes d’utilisateurs,
- pour des opérations,
- pour un niveau de finesse qui peut être le fichier, l’article, la donnée.
Par exemple : Telle classe d’utilisateurs qui peuvent accéder à toutes les données relatives au
personnel sauf des cadres à partir d’un certain montant.

III-6. Interface utilisateur


Le dialogue avec la base de données doit être réalisé avec un langage dont les
américains ont bien défini les qualités en le qualifiant selon une hiérarchie de :Sans exiger
d’un tel langage qu’il séduise vraiment l’utilisateur, qu’il lui permette au moins d’exprimer
très simplement ses requêtes au terme d’une formation dont la durée ne devrait pas excéder
deux jours.

III-7. Les Performances


Les performances dus système dans un environnement Multi-Utilisateurs doivent être
satisfaisantes. Ces performances sont surtout fonction des caractéristiques techniques du
support matériel : unité centrale, mémoire, buffer, réseau, etc.. Elles vont très fortement
conditionner les temps de réponse qui devront être compatibles avec les contraintes de
l’application.

III-8. La fiabilité et la sécurité


Le SGBD doit garantir aux utilisateurs une bonne sécurité de fonctionnement et offrir
en cas de panne ou d’erreur des mécanismes de reprise.
Des procédures de sauvegarde sont prévues qui permettent en cas de destruction de tout ou
partie de la base, de la régénérer à partir de copies précédentes et de fichiers (journaux de
transaction) que le système aura créés.
En cas de panne au moment de l’exécution d’une transaction de mise à jour par exemple, le
système devra offrir au moment de la reprise une base de données dans un état cohérent à
partir duquel l’utilisateur pourra de nouveau exécuter la transaction.

Page: 6
IV. Les Différents Niveaux de Représentation d'une Base de Données
On distingue trois niveaux de représentation d’une base de données : niveau interne
(physique), niveau conceptuel, niveau externe.

1. Niveau interne (Physique)


C’est la structure interne de la base, stockée sur des supports physiques. De ce niveau
dépendent les performances du système (temps de réponse, nombre d’utilisateurs, volume de
données, etc.).

2. Niveau conceptuel
C’est la synthèse de tous les schémas externes intégrés dans un schéma unique qui
constitue un invariant de l’organisation, car il est indépendant des traitements (des moyens,
méthodes, algorithmes, etc.) et du SGBD qui sera retenu par la suite. La théorie suppose
qu’un tel schéma existe, les schémas externes sont tous des dérivations obéissant
éventuellement à un certain nombre de règles du schéma conceptuel. Il est établi par un
homme de l’art supposé capable de synthétiser intelligemment les différentes vues.

3. Niveau externe
C’est la vision des données d’un utilisateur particulier dans le cadre d’une application.
Elle est donc par définition partielle et incomplète. Il y a autant de schémas externes qu’il y a
d’utilisateurs ou groupe d’utilisateurs. On les appelle encore vues. Les utilisateurs travaillent
en général sur des données différentes mais aussi en partie sur des données communes, donc
les vues peuvent se recouvrir plus ou moins complètement.
D’autre part, la même information dans deux vues différentes pourra être perçue de deux
façons différentes par les utilisateurs.

Réel

Modèle conceptuel  Indépendant du


modèle de
données
 Indépendant du
Médecin effectue Visite
SGBD

Modèle logique  Dépendant du Codasyl Relationnel Objet XML


modèle de
données
 Indépendant du
SGBD

Modèle Physique  Dépendant du  Organisation physique des données


modèle de  Structures de stockage des données
données  Structures accélératrices (index)
 Dépendant du
SGBD
Page: 7

Vous aimerez peut-être aussi