PDF 118 ko D229_Chapitre-2

Bases de Données
date de dernière modification : 29 octobre 2000
NB : Ce chapitre s'adresse aux non spécialistes des bases de données. Il a un but d'initiation et de sensibilisation (en anglais
"primer"). Il ne saurait donc constituer une référence exhaustive sur le sujet et il n'en a pas l'ambition.
1.Organisation et modélisation
Les premières applications informatiques, dans le domaine de la gestion, consistaient en tandems programmes-fichiers. Les
fichiers contenaient les données nécessaires aux traitements opérés par les programmes. Le tandem programmes-fichiers
était indissociable car les fichiers ne pouvaient être manipulés que par les programmes et les programmes ne pouvaient
s'exécuter sans leurs fichiers. Comme les applications étaient développées successivement avec des matériels différents et
des langages de programmation divers, toutes ces applications n'étaient pas communicantes et étaient juxtaposées. Une mise à
jour des données devenait alors très complexe.
C'est alors que le concept de séparation des traitements et des données donna naissance aux bases de données dont une
définition peut être celle d'une collection structurée de données enregistrées sur des supports accessibles par l'ordinateur et
partagées par plusieurs utilisateurs .
De fait, dans une base de données, ces dernières forment un tout gérable indépendamment des traitements par un système de
gestion de base de données qui permet de structurer, d'administrer et de sécuriser la base. Les traitements peuvent être
créés indépendamment des données et, par le biais d'une interface appropriée, accéder à une partie (vue) de la base de
données. L'essor des bases de données est dû également à la technologie des disques magnétiques de grande capacité à accès
direct.

Les premières bases de données (1965-1970) se sont appuyées sur des modèles appelés "navigationels" étant donné le mode
d'accès aux données. Le modèle hiérarchique, premier à être utilisé, notamment avec le produit IMS (Information Management
System), structurait les données sous forme d'arbres, l'entrée dans la base se faisant par la racine ; le modèle qui a suivi fut
le modèle "réseau" ou CODASYL qui, avec la notion de connecteur, facilita les exécutions de requêtes mais au prix d'une
gestion par pointeurs assez lourde.
Exemple : Supposons qu'une maison de négoce en vins répertorie ses clients dans une base de données faisant apparaître les
produits commercialisés (numéro de vin, type, millésime, …), et les clients (nom, prénom,) ainsi que les achats de ces clients :
numéro de vin acheté, date d'achat, nombre de bouteilles. Le modèle hiérarchique peut correspondre au schéma client à vin
(modèle H1) dont quelques occurrences sont données ci-dessous.
On pourrait d'ailleurs imaginer aussi un modèle hiérarchique vin à client (modèle H2, figure ci-dessous).

Quel que soit le modèle hiérarchique adopté, les requêtes peuvent être quelquefois complexes dans leurs réalisations. Ainsi, si
dans le modèle H1, on recherche les vins achetés par le client "Dubois", la requête s'exprimera simplement :
Rq1 : Trouver client "Dubois"
Tant qu'il y a des vins sous "Dubois"
Trouver n°vin
Imprimer n°vin
Fin Tant Que
Si, par contre, on recherche les clients qui ont acheté le vin numéro "154", la requête est plus compliquée :
Rq2 : Tant qu'il y a des clients
Tant qu'il y a des vins sous le client
Lire numéro de vin sous le client
Si numéro="154" alors
imprimer le nom du client
Fin Si
Fin Tant Que
Fin Tant Que
Le modèle réseau apporte une amélioration en "symétrisant" l'arborescence du modèle hiérarchique par adjonction du
connecteur "date achat, nombre de bouteilles". Les associations entre l'entité VIN et le connecteur, d'une part, et entre
l'entité CLIENT et le connecteur, d'autre part, correspondent à deux familles de pointeurs (organisés en boucles
généralement comme indiqué sur la figure ci-dessous).

Les deux requêtes précédentes s'expriment alors de la manière suivante :
Rq1 : Trouver client "Dubois"
Tant qu'il y a des connecteurs
Trouver le n°vin associé au connecteur
Imprimer n°vin
Fin Tant Que
Rq2 : Trouver le vin numéro "154"
Tant qu'il y a des connecteurs sous ce vin
Trouver nom du client associé au connecteur
Imprimer nom du client
Fin Tant Que
On notera la symétrie de ces deux requêtes. On notera aussi les nombreux pointeurs nécessaires à l'implémentation de la base
de données réseau ce qui constitue un inconvénient majeur de ce type de modélisation.
2. Modèle relationnel
Le modèle relationnel, défini par Codd au début des années 70, a ses bases dans la théorie mathématique des ensembles et
constitue actuellement le modèle de données le plus répandu parmi les produits commercialisés (Oracle, Sybase, Informix, …).
Le concept de base est celui de relation qui n'est autre qu'un ensemble d'éléments appelés "tuples", chacun de ces tuples étant
constitué d'attributs prenant leurs valeurs dans un domaine spécifique.
Exemple : En reprenant l'exemple précédent, on peut imaginer la relation suivante
VIN (numvin, type, mil)

où numvin (numéro de vin) prend ses valeurs dans l'ensemble des entiers positifs ; type est un libellé figurant dans une liste
définie ; mil (millésime) prend ses valeurs dans l'ensemble des dates (années). Bien entendu, le triplet numvin, type, mil doit
avoir un sens. Par exemple le vin (169, Bordeaux Pauillac Château Latour, 2378) n'existe pas encore, il faudra attendre la
récolte de l'année 2378.
De même, on peut imaginer la relation
CLIENT(nomclient, prenomclient, adresse, da, nbout)
où da et nbout désignent respectivement la date d'achat et le nombre de bouteilles. Les tables correspondantes aux relations
VIN et CLIENT sont données ci-dessous.
Les tables ne constituent cependant pas une base de données relationnelle. Pour cela les tables/relations doivent satisfaire
certains critères qui sont basés sur le concept de dépendance fonctionnelle.
On dira qu'entre un attribut A et un attribut B il existe une dépendance fonctionnelle A à B si la donnée de A détermine
uniquement B.
Exemple : Dans l'exemple précédent, dans la relation VIN, on pourra considérer que le numéro de vin numvin correspond à un
vin unique (type) et à un millésime unique (mil). Dans la relation CLIENT, il n'y a pas de dépendance fonctionnelle nomclient à
prenomclient car il peut exister deux clients de même nom avec des prénoms différents.
Il n'y a pas de dépendances fonctionnelles évidentes de da vers nbout.
Une dépendance fonctionnelle est élémentaire si elle est du type A à B ou si la dépendance (A, B) à C ne peut se réduire à A à
C ou B à C.
Exemple : La dépendance fonctionnelle (numvin, type) à mil n'est pas élémentaire car on a la dépendance numvin à mil. Les
dépendances fonctionnelles numvin à mil, numvin à type sont élémentaires.
Une dépendance fonctionnelle A à B est directe s'il n'existe pas de transitivité du type A à C et C à B. Pour la construction des
relations, on ne prend en considération que les dépendances fonctionnelles élémentaires et directes et le signe "à " désignera
désormais ce type de dépendance fonctionnelle.
Si, dans une relation, un attribut A est tel que A à X où X est un attribut quelconque de la relation, alors on définit A comme
une clé.
Pour que les relations constituent une base de données relationnelle, elles doivent satisfaire à la condition de normalisation
suivante : Les seules dépendances fonctionnelles figurant dans une relation sont celles du type