Base de données
  1. Introduction.
  2. Qu'attendre d'une base de données ?
  3. Architecture
    1. Définitions.
    2. Niveaux d'abstractions.
    3. Caractéristiques.
  4. Histoire.
  5. Base de données relationnelles.
    1. Introduction.
    2. Normalisation.
    3. SQL.
  6. Base de données objet.
  7. Bibliographie/Liens.
  8. Conclusion.
1. Introduction

Le but de ce document est d'offrir un éclairage théorique à tout un chacun qui désire collecter ou rassembler des données. Les informations récoltées ici permettront sans doute de rendre des développements futurs - sous MySql ou Access notamment - plus rigoureux.
Vous trouverez un aperçu de la théorie sur les bases de données, je vous invite à vous référez à la bibliographie pour prolonger votre étude.

2. Qu'attendre d'une base de données ?
Contrôle de la redondance des données.
Si plusieurs utilisateurs ou applications accèdent aux mêmes données, celles-ci doivent être enregistrées dans la machine à un seul endroit.
Incohérence des données.
La transaction est enregistrée sur disque au moment où elle est terminée.
Partage des données.
Les données stockées peuvent être partagées.
Sécurité.
On doit pouvoir définir des droits d'accès ou des restrictions sur la base.
Intégrité des données.
L'intégrité sera assurée s'il n'y a ni redondance, ni inconsistance. De plus, dans l'application, un ensemble de contraintes doit être défini pour que les données restent intègres : une date de naissance libellée comme suit 36/15/1998 est impensable.
Indépendance des données pour l'application.
Différents services offerts par le système de base de données ne doivent avoir aucun impact sur l'application :
  1. Définition d'index
  2. Définition de données distribuées ou partagées
  3. Représentations internes des données
  4. Système de back-up
  5. Notion de vue
  6. Accès à la base
3.1 Définitions.
Entité
Un ensemble d'informations liées entre elles.
Attribut
Les entités ont des propriétés appelées attributs.
Domaine
Chaque attribut a un ensemble de valeurs qui est appelé le domaine.
Clé
Une clé est définie à partir de colonnes. Une valeur de chaque colonne permettant d'identifier univoquement un enregistrement de l'entité.
Relation
Une relation permet de lier des entités entre elles.
Administrateur de base de données (DBA)
Personne ou groupe de personnes responsable du contrôle de la base de données.
Système de gestion de base de données (DBMS)
Ensemble de softwares nécessaire aux contrôles de la base de données.
Dictionnaire de données (DD)
Un ensemble d'entités représentant les caractéristiques de la base de données appelé aussi méta-database.
Programme de l'application
Un programme qui utilise une base de données est appelé un programme de l'application.
Host langage
Un programme de l'application est écrit dans un langage de programmation. Ce langage est appelé Host langage (Java, C/C++, Cobol...)
Langage de définitions de données (DDL)
Langage permettant d'interfacer le dictionnaire pour créer la base de données ( création de tables, d'index...).
Langage de manipulation de données (DML)
Langage utilisé pour manipuler les données.
3.2 Différents niveaux d'abstractions.

Dans ce paragraphe nous expliquerons comment les objectifs de contrôle de redondance, de données partagées et spécialement l'indépendance des données peuvent être réalisées dans un système de base de données.

Nous débutons la discussion en présentant les trois niveaux d'abstraction. Nous discuterons également des deux différents langages utilisés dans le système de base de données, celui pour la définition des données (DDL) et celui pour la manipulation des données (DML).



Le modèle externe
Le modèle externe est en fait une vue pour l'utilisateur (end user). Il peut y en avoir plusieurs : jusqu'à un par utilisateur.
Par utilisateur, il peut être défini :

  1. le host langage
  2. une vue (sous ensemble de la base de données)
  3. accès à la base de données (login)

Le modèle conceptuel
Le modèle conceptuel est fréquemment appelé le «data model» de la base de données. Il définit toutes les entités, associations, index,... à travers le langage de définition de données (DDL). La description de la base de données est enregistrée dans le dictionnaire. Contient l'ensemble des process et libraries.

Le modèle interne
La représentation physique des données est spécifiée dans le modèle interne. L'utilisateur n'a pas accès à cette partie du modèle. Le modèle interne permet de cacher la complexité de l'implémentation de la base de données.

Les langages de la base de données
Il existe trois types de langages :

  1. langage de définition de la base (création de table,...)
  2. langage de manipulation de données (insertion de données, ...)
  3. host langage : langage de programmation où les instructions des deux langages précédents peuvent être insérées.
3.3 Caractéristiques générales d'une base de données
  1. notion de transaction avec commit (j'écris dans la base de données) et rollback (j'annule ce que je viens de faire donc je n'écris rien dans la base de données)
  2. backup et restore (recovery) d'une base
  3. notion de lock (verrou) pour les accès parallèles
  4. distribution et réplication de données
  5. gestion des index sans modification des données
  6. extensions de la base de données sans l'arrêter (scalable)
  7. accès aux données (peut être distant)
  8. structuration des données
  9. droit d'accès
  10. cacher la complexité (grâce aux différents modèles vus au point 3.2)
4. Histoire.

Au commencement vînt le Verbe, puis l'Ecrit et enfin la Base de données...

  • Base de données hiérarchique : ne permettait que des relations 1-N, aujourd'hui disparue.
  • Base de données réseau : hiérarchique améliorée, gère les relations M-N, lie les enregistrements les uns aux autres (liste chaînées, pointeurs), devenue rare.
  • Base de données relationnelle : plus riche.
    Qualités : richesse du langage SQL, backup, verrous, distribuée, répliquée...
    Défauts : les colonnes ont des limites, pas de types complexes (liste chaînées, FIFO)
  • Base de données objet : jeune et peut-être immature. Colle à n'importe quelle structure, pas de tables, pas de colonnes, pas de limites de types.
5.1 Introduction aux bases de données relationnelles.

Les bases de données relationnelles sont les plus répandues (Oracle et Access par exemple) et nous allons donc nous y attarder.
On trouve dans ces bases de données les notions d'entité, de relation, de table, d'attribut, de clé primaire, de clé étrangère, de vue, d'index, de SQL.
Les bases de données relationnelles reprennent toutes les caractéristiques énumérées au point 3.3.

5.2 Normalisation.

La normalisation est certainement une étape essentielle dans la construction de votre base de données car elle permet d'éviter la redondance. Pour rendre ce propos clair (le sujet n'est pas simple!), nous l'illustrerons à l'aide d'exemples.
Deux tables serviront de base à ces exemples. Il s'agit d'un cas courant : des fournisseurs qui vendent des pièces, les pièces viennent de différents fournisseurs.

  1. La table FOURNISSEURS composée comme suit :
    NOFOUR Numéro de fournisseur
    NOMFOUR Nom du fournisseur
    VILLE Ville du fournisseur
    PROVINCE Province du fournisseur
    NOPCE Numéro de pièce vendue par le fournisseur
    PRIX Prix de la pièce vendue par le fournisseur
  2. La table PIECES composée comme suit :
    NOPCE Numéro de pièce
    NOMPCE Nom de la pièce
    STOCK Stock de la pièce
    NOFOUR Numéro du fournisseur qui vend la pièce
Soit la relation N-M, FOURNISSEURS-PIECES, qui nous permet de visualiser toutes les pièces vendues avec les fournisseurs qui les vendent.

Une relation non normalisée donnerait ceci :

NOPCE NOMPCE STOCK NOFOUR NOMFOUR VILLE PROVINCE PRIX
1 AA 100 100 XX LLN BW 10000



200 YY BXL BT 20000



300 ZZ WAV BW 15000
2 BB 30 200 YY BXL BT 10000



400 NN GD FL 10

Une relation normalisée première forme appelée 1NF donne ceci :

NOPCE NOMPCE STOCK NOFOUR NOMFOUR VILLE PROVINCE PRIX
1 AA 100 100 XX LLN BW 10000
1 AA 100 200 YY BXL BT 20000
1 AA 100 300 ZZ WAV BW 15000
2 BB 30 200 YY BXL BT 10000
2 BB 30 400 NN GD FL 10
Une relation est 1NF si chaque valeur dans la relation est atomique (c'est-à-dire définie).

Une relation normalisée deuxième forme appelée 2NF donne ceci :

PIECES
NOPCE NOMPCE STOCK
1 AA 100
2 BB 30
ASSOCIATION
NOPCE NOFOUR PRIX
1 100 10000
1 200 20000
1 300 15000
2 200 10000
2 400 10

FOURNISSEUR
NOFOUR NOMFOUR VILLE PROVINCE
100 XX LLN BW
200 YY BXL BT
300 ZZ WAV BW
400 NN GD FL
Ces 3 tables font disparaitre la redondance, elles prennent moins de place et facilitent les manipulations (mise à jour, maintenance...). Ainsi, la mise à jour de l'adresse d'un fournisseur par exemple se fera au moyen d'une seule mise à jour dans la table fournisseur. En 1NF, il faudrait mettre à jour TOUTES les lignes qui contiennent ce fournisseur. Ce qui peut représenter plusieurs milliers de mises à jour !
Votre base de données devrait être au moins sous cette forme.
Une relation est 2NF si :
1. elle est 1NF
2. chaque attribut non clé dépend une seule fois de la clé primaire

Une relation normalisée troisième forme appelée 3NF donne ceci :
Nous ne touchons plus aux tables PIECES et ASSOCIATION par contre, la table FOURNISSEUR peut encore être normalisée;. En effet, certaines colonnes non clé peuvent être liées entre elles.

FOURNISSEUR
NOFOUR NOMFOUR VILLE
100 XX LLN
200 YY BXL
300 ZZ WAV
400 NN GD
PROVINCE
VILLE PROVINCE
LLN BW
BXL BT
WAV BW
GD FL

Ceci est une forme classique(notamment pour les codes postaux), si une ville change de province une seule mise à jour est nécessaire.
Essayez si possible de normaliser jusqu'ici.
Une relation est 3NF si :
1. elle est 2NF
2. chaque attribut non clé est directement dépendant de la clé primaire

Bon, si vous êtes arrivé jusqu'ici, BRAVO !
Mais on peut normaliser encore plus loin, mais là je vous renvoie à la bibliographie.

5.3 SQL.

Le SQL est un langage de manipulation de données qui vous permet de travailler avec votre base de données. Certains gestionnaires de base de données vous permettent d'entrer ces commandes en ligne ou vous pouvez les insérer dans votre langage favori (VisualBasic, Cobol, C,...)
Le but n'est pas dans cette section de vous donner toutes les commandes SQL, pour cela je vous renvoie à la documentation ou à l'aide de votre gestionnaire de base de données.
A propos d'Access, lorsque vous créer une requête, vous pouvez en cliquant sur le bouton SQL visualiser le code SQL généré. Remarque : ce code n'est pas vraiment optimisé.

Les commandes qui suivent sont libellées sur plusieurs lignes et indentées pour des raisons de lisibilité uniquement.
Il se peut que pour des raisons de sécurité vous ne puissiez pas r&eacutealiser certaines commandes sur le serveur de votre entreprise !

Créer une table :
CREATE TABLE FOURNISSEUR (NOFOUR INTEGER NOT NULL,
                     NOM    CHAR(20),
                          STATUS INTEGER,
                   VILLE  CHAR(30));

On crée une table FOURNISSEUR avec comme colonne NOFOUR un entier qui ne peut être NULL(saisie obligatoire en création), NOM une chaîne de 20 caractères ... la commande SQL se termine en g&eacuten&eacuteral par un point-virgule.
Détruire une table :
DROP TABLE FOURNISSEUR;

Détruit la table FOURNISSEUR.
Créer un index : (pour accéder plus rapidement aux enregistrements)
CREATE INDEX PR-FOUR1 ON FOURNISSEUR(VILLE);

Crée un index nommé PR-FOUR1 sur la colonne VILLE de la table FOURNISSEUR.
Créer un index unique :
CREATE UNIQUE INDEX PR-FOUR2 ON FOURNISSEUR(NOFOUR);

Crée un index unique nommé PR-FOUR2 sur la colonne NOFOUR de la table FOURNISSEUR, NOFOUR est donc une clé primaire.
Créer un index unique composé :
CREATE UNIQUE INDEX PR-ASSOC1 ON ASSOCIATION(NOPCE,NOFOUR);

Crée un index unique composé nommé PR-ASSOC1 sur les colonnes NOPCE et NOFOUR de la table ASSOCIATION, (NOPCE,NOFOUR) est donc une clé primaire.
Détruire un index :
DROP INDEX PR-FOUR1;

Détruit l'index PR-FOUR1.
Ajouter une colonne à une table :
ALTER TABLE PIECES ADD NOM CHAR(20);

Ajoute la colonne NOM, chaîne de 20 caractères, à la table PIECES.

Nous allons maintenant passer à la manipulation des données proprement dite :

Sélectionner le nom de tous les fournisseurs qui vivent à Paris :
SELECT NOM FROM FOURNISSEUR WHERE VILLE="PARIS";
Sélectionner toutes les villes où vivent les fournisseurs :
SELECT DISTINCT VILLE FROM FOURNISSEUR;

Le DISTINCT permet d'obtenir une liste qui ne contient qu'une fois chaque nom de ville.
Trouver les noms de tous les fournisseurs qui vendent la pièce numéro 2 :
SELECT NOM FROM FOURNISSEUR WHERE NOFOUR IN
  (SELECT NOFOUR FROM ASSOCIATION WHERE NOPCE=2);

Le IN signifie inclus dans. Il existe une autre méthode appel&eacutee JOIN qui est nettement MOINS efficace n'en déplaise à Access. Pour comprendre les requêtes (ou query) imbriquées, il faut exécuter d'abord la requête entre parenthèses.
Trouver les noms de tous les fournisseurs qui ne vendent pas la pièce numéro 1 :
SELECT NOM FROM FOURNISSEUR WHERE 1 NOT IN
   (SELECT NOPCE FROM ASSOCIATION WHERE NOFOUR=FOURNISSEUR.NOFOUR);

FOURNISSEUR.NOFOUR veut dire le numéro de fournisseur de la table FOURNISSEUR.
Différents opérateurs peuvent être utilisés :
   =
 IN
        NOT IN
    CONTAINS
  DOES NOT CONTAIN
Différentes fonctions peuvent être utilisées :
   COUNT
     SUM
       AVG
       MIN
       MAX
Mise à jour :
UPDATE ASSOCIATION SET PRIX=30 WHERE NOPCE=5 AND NOFOUR="ZZ";

Dans la table ASSOCIATION pour tous les enregistrements dont le NOPCE=5 et NOFOUR=ZZ, la colonne PRIX sera mise à 30.
Suppression :
DELETE FOURNISSEUR WHERE NOFOUR="ZZ";

Dans la table FOURNISSEUR supprime l'enregistrement dont NOFOUR=ZZ, il faut s'assurer que ce fournisseur n'est pas utilisé dans la table ASSOCIATION.
Création :
INSERT INTO ASSOCIATION (NOPCE,NOFOUR,PRIX) VALUES(1,"KK",10);

Crée dans la table ASSOCIATION un enregistrement en assignant des valeurs aux colonnes.

Voilà qui termine le chapître consacré au SQL, des différences de syntaxe peuvent exister selon le gestionnaire de base de données que vous utilisez mais vous avez ici un aperçu des opérations les plus courantes.

6. Base de données objet.

Première remarque : il existe sur le marché des bases de données qui intègrent de nouveaux types de données mais ce sont toujours des base de données relationnelles.

Deuxième remarque : nous ne ferons qu'effleurer le sujet, les bases de données relationnelles sont et resteront les base de données les plus importantes un bout de temps.

Une base de données objet c'est :

  • Cacher l'implémentation (encapsuler) :
    créer des classes composées de méthodes (publiques) et de données (membres privés ou protégés)
    méthodes (constructeur, destructeur), opérateurs (redéfinition), réutilisation (héritage)
  • Définition de classes qui contiennent des données persistantes ou volatiles.
  • Gestion des références vers les autres classes d'objets (contrairement aux bases de données relationnelles qui ne réfèrent pas vers les autres enregistrements)
  • Difficilement scalable, indexable.
7. Bibliographie/Liens.
  1. Maîtriser les bases de donnés par Georges Gardarin - Eyrolles
    Complet, illustré d'exemples, un chapître est consacré aux base de données objet.
  2. Structured Systems Analysis : Tool and Technique par Gane & Sarson - McDonnell Douglas Information
    En anglais, plus orienté sur l'analyse : entit&eacute-relation-attribut, normalisation...
8. Conclusion.

Cet exposé n'a pas la prétention de remplacer un cours académique mais pourra éventuellement servir de départ à vos investigations.

Ce cours est une adaptation d'un de mes textes publié en 1998 sur Le Laurent Express, mis à jour le 4 mars 2002 sur phpzoom.com et remis en ligne le 17 janvier 2008 sur cybermonde.org.