Les bases de données
Support de coursPascal Ballet
Introduction
Les fondements
Une base de données a deux objectifs principaux : - le stockage structuré de l'information
ET
- le traitement des données stockées Par exemple, un calepin permet :
- de stocker des informations sur nos amis, collègues... Ces informations sont structurées (nom, téléphone, adresse)
ET
- de retrouver rapidement un nom grâce aux onglets (A, B, C...)
Un calepin constitue donc bel et bien une base de données. Certes il n'est pas informatisé, mais il possède les deux attributs essentiels d'une base de données : stocker de manière structurée et retrouver de l'information.
Un calepin possède des limites :
- au delà d'une centaine de contacts, il devient difficilement gérable
- si nous voulons ajouter le champ "Age", il faut modifier chacune des pages
- si nous cherchons à faire la moyenne d'age de tous nos contacts, cela devient très fastidieux - de même si nous voulons rechercher les personnes dont le prénom est Jean
Les possibilités
L'ordinateur permet le traitement rapide de nombreuses données. Une fois l'information stockée de manière structurée dans l'ordinateur, il est possible de :
- retrouver rapidement une ou plusieurs informations, - modifier, compléter ou supprimer les données stockées,
- changer la manière dont l'information est stockée (modifier la structure), - mettre en forme les données (pour l'impression par exemple),
- contraindre la saisie des données sous un certain format (numérique, code postal...),
- mettre des données en relations (permet d'éviter les doublons et de croiser des informations),
Les méthodes de stockage
A- Une manière simple de stocker de manière structurée des données est d'utiliser un tableau.
Pour le calepin, voici comment ce tableau se représente :
Nom Téléphone Adresse
Einstein Albert 01 23 45 Ulm - Allemagne
Turing Alan 54 32 10 Londres - Grande Bretagne
B- Une autre manière de stocker les données est la manière hiérarchique. Par exemple les
fichiers d'un ordinateur sont stockés dans des dossiers, contenant à leur tour d'autres dossiers, etc. Une des premières bases de données utilisant une arborescence est IMS. Elle fut créée par IBM en 1966 pour le compte de Rockwell et le programme Apollo (toujours en fonctionnement aujourd'hui).
C- Le stockage hiérarchique des données n'est pas toujours adapté aux problèmes rencontrés
dans le monde réel. C'est pourquoi, le modèle de base de données relationnelles est beaucoup plus répandu. Une base de données relationnelle est structurée suivant les principes de l’algèbre relationnelle. La théorie des bases de données relationnelles est issue des travaux de Edgar Frank Codd1. Une base de donnée relationnelle permettant de stocker et de traiter notre calepin aurait une table identique au tableau du point A :
Nom Téléphone Adresse
Einstein Albert 01 23 45 Ulm - Allemagne
Turing Alan 54 32 10 Londres - Grande Bretagne
Dans la terminologie des bases de données relationnelles, "Nom", "Téléphone" et "Adresse" sont des champs. Les deux lignes qui suivent sont les enregistrements.
- Les champs font partie de la structure de la base et - les enregistrements font partie des données de la base.
D- Il existe également des bases de données orientées objet, comme il existe des langages de
programmation orientés objet. Malgré les atouts de l'approche objet (encapsulation,
1
héritage...), celles-ci sont peu répandues. Les bases de données relationnelles sont, actuellement, le standard de fait.
Nous étudierons dans ce cours essentiellement les bases de données relationnelles.
Le traitement des données
La manière de stocker ne fait pas tout. En effet, n'oublions pas qu'une base de données doit être capable d'exploiter les données. Pour ce faire, un langage appelé SQL (Structured query language) a été développé dans les années 1980 (première norme éditée par l'ANSI en 1986 puis adoptée par l'ISO en 1987). Ce langage, adapté aux bases de données relationnelles permet :
- de définir les données (DDL, Data definition language),
- de manipuler les données (DML, Data manipulation language), - de contrôler les données (DCL, Data control language).
Par exemple, si pour notre calepin nous voulions retrouver tous les contacts dont l'age dépasse 20 ans, nous écririons en SQL :
select * from contacts where age > 20
Les clés
Pour permettre la cohérences des données et, accessoirement augmenter la vitesse de traitement des informations, une table associe généralement à l'un de ses champs une clé dite primaire. Un champ à qui une clé est associée ne peut pas avoir de doublons dans ses enregistrements. Par exemple, dans notre calepin, si nous désignons le champ nom comme clé primaire de la table contacts, il ne sera pas possible d'avoir deux personnes ayant le même nom. Dupont (Jean) et Dupont (Emilie) ne pourront pas être sur le calepin car ces deux personnes ont exactement le même nom.
Une possibilité, pour pallier à ce problème, serait par exemple d'ajouter un champ insee, pour indiquer le numéro de sécurité sociale de chacun de nos contacts. En effet, chaque citoyen possède un numéro insee et ce numéro est unique.
Si l'on pousse le raisonnement un peu plus loin, on se rend compte que ce numéro insee marche bien pour nos contacts français. Or, si nous avons des contacts étrangers (japonais, américain...), le numéro insee n'est plus possible. De plus, il serait quelque peu délicat de demander à chacun de ses contacts son numéro insee...
C'est pourquoi, pour notre calepin, nous n'utiliserons pas le numéro inse mais simplement un champ numéro qui associe (éventuellement automatiquement) un nombre unique à chacun de nos contact. Le champ numéro est alors clé primaire de la table contacts.
La table contacts devient alors :
Numéro (clé) Nom Téléphone Adresse
0 Einstein Albert 01 23 45 Ulm - Allemagne
La notion de clé permet également de mettre en relation différents types d'information. C'est ce que nous développons dans la partie suivante.
Les relations
Supposons que pour chaque contact de notre calepin, nous désirions placer éventuellement plusieurs numéros de téléphones.
La première solution qui vient à l'esprit est d'ajouter deux ou trois nouveaux champs du type :
téléphone-portable, téléphone-maison, téléphone-travail à la table contacts.
Cette solution a l'avantage d'être simple mais ne permet pas une grande souplesse dans le nombre de numéros de téléphones mémorisables par contact. En effet, si l'un de nos contacts nous donne son numéro de téléphone de vacances, nous sommes dans l'embarras. Nous pouvons alors ajouter le champ téléphone-vacances, mais ajouter un champ rien que pour un contact n'est pas rentable en terme :
- de place mémoire utilisée, car ce champ se répète pour tous les autres contacts (même si ce champ est vide)
- et si nous devons ajouter un nouveau champ téléphone-portable-travail, il faut à nouveau modifier la structure de la table.
L'idée est d'ajouter une nouvelle table contenant uniquement les numéros de téléphones de nos contacts. Cette table doit donc associer à chacun de nos contacts plusieurs numéros de téléphone. Attention, un contact est repéré de manière unique par son numéro et non pas par son nom à cause des homonymes. La table téléphones est alors la suivante :
Numéro Téléphone
0 01 23 45
0 06 07 08
1 54 32 10
Cette table signifie que notre contact 0 (à savoir Einstein) possède deux numéros de téléphone, un fixe et un portable et que notre contact 1 (Turing) possède un numéro de téléphone fixe.
Nous nous rendons compte alors qu'il est possible de rajouter à tout moment un nouveau numéro de téléphone pour l'un ou l'autre de nos contacts. Si nous voulons ajouter un numéro de vacances pour Einstein, voilà à quoi ressemblera la table téléphones :
Numéro Téléphone
0 01 23 45
0 06 07 08
0 05 54 43
1 54 32 10
Comme premier bilan de notre calepin à ce stade de développement, nous voyons que deux tables sont nécessaires :
- la table contacts, - la table téléphones.
Ces tables sont les suivantes : Contacts :
Numéro(clé) Nom Téléphone Adresse
0 Einstein Albert 01 23 45 Ulm - Allemagne 1 Turing Alan 54 32 10 Londres - Grande
Bretagne Téléphones : Numéro Téléphone 0 01 23 45 0 06 07 08 0 05 54 43 1 54 32 10
Nous observons cependant une incohérence / redondance du fait que la table contacts possède un champ téléphone. Or dorénavant, c'est la table téléphones qui s'occupe de traiter les numéros de téléphones. Nous devons donc supprimer le champ téléphone de la table contacts afin de :
- supprimer les doublons,
- faciliter ainsi la maintenance et la cohérence de la base calepin en n'ayant qu'un seul enregistrement à changer si l'un des numéro de téléphone venait à être modifié (par exemple le 01 23 45 devient 01 23 46).
La table contacts devient alors :
Numéro(clé) Nom Adresse
0 Einstein Albert Ulm - Allemagne 1 Turing Alan Londres - Grande
Bretagne et ne gère plus du tout les numéros de téléphones.
La difficulté qui nous apparaît alors et qu'il faut maintenant gérer 2 tables distinctes. Pour avoir le numéro de téléphone de vacances d'Einstein, il faut ouvrir son calepin à Einstein, regarder quel est son numéro (0) puis chercher dans la table téléphone son numéro de vacances. Tout cela n'est guère pratique.
Voilà en quoi les relations entre les tables vont nous servir. Si nous regardons de prêt nos deux tables, nous nous rendons compte qu'elles possèdent un champ commun :
- c'est le champ numéro.
Pour le moment, c'est à nous de remplir correctement le champ numéro de la table
téléphones. Opération qui peut s'avérer délicate car la moindre erreur dans un numéro (de
contact, à savoir 0 pour Einstein...) et l'on attribut un mauvais numéro de téléphone à une personne.
Les bases de données relationnelles permettent de relier deux champs de même contenus se trouvant dans deux tables distinctes.
Nous pouvons donc créer une relation entre le champ numéro de la table contacts et le champ numéro de la table téléphones. La base de donnée calepin peut alors gérer la cohérence entre les deux tables :
Une relation se fait entre :
- un champ de type clé et un champ quelconque > relation 1 à plusieurs (N) - un champ de type clé et un autre champ de type clé > relation 1 à 1
- un champ quelconque et un champ quelconque > relation indéfinie
> La relation la plus couramment utilisée est la relation 1 à plusieurs (1 à N). Cela signifie pour notre calepin que pour un contact particulier (unique), il peut avoir 0 ou plusieurs numéros de téléphones :
> Le type de relation 1 à 1 est moins couramment utilisé car une relation 1 à 1 signifie que l'on peut tout simplement fusionner les deux tables mises en relation en une seule et même table.
> Le type de relation indéfinie n'est pas utilisé en pratique.
Les outils
ORACLE MySQL ACCESS NOVEL etcL'outil informatique associé à notre cours est MS Access :
Applications simples
Exemple 1
Mise en place d'une gestion de titres musicaux avec les critères suivants : - une table contient les artistes (nom, prénom et numéro unique (clé))
- une autre table contient les titres des artistes (numéro des artistes et titres des l'albums) - établir une relation entre ces 2 tables (1 à N)
Artistes
Numéro Nombre - clé
Nom Texte - non vide
Prénom Texte
La relation indique qu'un artiste (1) peut posséder plusieurs titres (N). - donner un exemple de base contenant 2 artistes et 3 titres
Titres
Numéro Nombre
Titre Texte - non vide
Artistes
Numéro Nom Prénom
0 Mozart
1 Beethoven Ludwig
Titres
Numéro Titre
0 Les noces de Figaro 0 La flûte enchantée
1 Hymne à la joie
Exemple 2
Dorénavant, un titre peut aussi avoir été interprété (ou composé) par plusieurs artistes. - Quelles sont les tables et les relations à créer ?
Artistes NuméroArtiste Nombre - clé Nom Texte - non vide Prénom Texte
La table ArtistesTitres permet de créer la relation indirecte du type "plusieurs à plusieurs" : un artiste peut avoir composé (ou interprété) plusieurs titre et un titre peut avoir été composé (ou interprété) par plusieurs artistes.
- Donner un exemple avec 2 artistes et 3 titres (dont 1 en commun).
La table ArtistesTitres se lit ainsi : L'artiste 0 a interprété les titres 0 et 2, l'artiste 1 a interprété
les titres 1 et 2, le titre 0 a été interprété par l'artiste 0, le titre 1 par l'artiste 1 et le titre 2 par les artistes 0 et 1. Ainsi, la table ArtistesTitres permet bien d'avoir une relation (indirecte) du
type "plusieurs à plusieurs".
Titres NuméroTitre Nombre - clé Titre Texte - non vide ArtistesTitres NuméroArtiste Nombre NuméroTitre Nombre Artistes
NuméroArtiste Nom Prénom
0 Pavarotti Luciano 1 Domingo Placido Titres NuméroTitre Titre 0 Aida 1 La Tosca 2 Marche hongroise ArtistesTitres NuméroArtiste NuméroTitre 0 0 0 2 1 1 1 2 1 1 N N
