Pourquoi organiser une base de données ?

La prise en compte de masse d'informations importantes dans des

environnements riches soulève plusieurs difficultés:

 Maîtrise de la représentation de données complexes:

Comment représenter des informations très diverses, très
complexes, relevant de différents domaines (à l'intérieur de
l'entreprise) et malgré tout interdépendantes.
Ainsi, en tant qu'étudiant, vous appartenez au Système
d'Information de l'université, comme Dominique Gonzalez en tant
qu'enseignant... or il existe bien un lien entre ces deux informations,
lien qui passe par d'autres éléments : cours, TP, formation...
 Maîtrise des accès personnalisés:
Comment mettre à disposition les informations dont un utilisateur a
besoin sans le noyer sous des tonnes de données, sans
l'empoisonner avec des données dont il n'a que faire, et en
garantissant le bon usage des informations. Ainsi, les étudiants
peuvent avoir accès à leur résultat d'examen, mais ils ne peuvent
pas les modifier.
 Maîtrise des traitements:
Dès lors que la masse d'information est riche, complexe, en
constante évolution, accessible à de multiples intervenants les
traitements, auxquels seront soumises ces informations auront
tendance à être eux-aussi riches et complexes. Alors que dans des
contextes plus restreints, avec une moindre diversité des situations,
les traitements seront souvent plus simples.
Ainsi l'élaboration de la paye, chez un commerçant employant
quelques vendeurs et agents de service, sera sans comparaison
avec celle d’une grande entreprise employant une grande variété de
salariés sur quantité de régimes différents.

Ces raisons vont nous amener vers l’analyse. L'exercice suivant va nous
en donner d'autres raisons.
Pourquoi l'analyse informatique ?

La difficulté essentielle dans la réalisation du SAI réside dans le fait qu'elle

concerne un nombre important de personnes, de caractéristiques très
variées (la direction, le service informatique, les responsables de service,
les utilisateurs terminaux) d'où la nécessité d'une méthode.

Les premières informatisations se sont souvent révélées catastrophiques

(la liste suivante n'est pas exhaustive):

 logiciel ne fonctionnant pas ou ne réalisant pas ce pourquoi il avait

été prévu,
 logiciel incapable d'évoluer avec le matériel, la taille de l'entreprise,
les changements dans l'entreprise,
 Etudes correctes sur le papier mais impossibles d’implanter,
 logiciel correct mais mettant trop de temps à délivrer les résultats,
 informatisation bouleversant l'organisation humaine de l'entreprise,
rejetée par le personnel...

Tirant leçon de ces déboires, deux questions particulières ont été

examinées:

1. comment réaliser un logiciel conforme à un cahier des charges ?

2. comment réaliser un cahier des charges qui décrive exactement et
précisément ce que l'on attend?

La première question ne concerne que les informaticiens: le génie logiciel.

La deuxième question concerne également les informaticiens, mais aussi,
et de manière essentielle, toute personne amenée à suivre, accompagner,
diriger l'informatisation d'un service: l'analyse informatique. On pourra
rencontrer aussi l'expression conception de systèmes d’information.

La difficulté essentielle de l'analyse informatique réside dans le fait qu'elle

doit établir un pont entre des personnes qui connaissent le
fonctionnement de leur service mais souvent de façon implicite (les détails
de fonctionnement n'ont jamais été explicités, encore moins formalisés) et
des personnes qui ne savent travailler que sur des objets formels, ceux-ci
n'ayant pour eux aucun sens, puisqu'ils ne connaissent pas l'entreprise.

Les demandeurs ne savent pas exprimer exactement ce qu'ils veulent ni

ce qu'ils peuvent attendre réellement de l'informatique, tandis que les
informaticiens croient savoir ce que l'on attend d'eux.

Une conclusion provisoire: l'analyse informatique ne peut pas être faite de

manière complètement empirique.
Une méthode d'analyse informatique: Merise

Plusieurs outils chargés de guider l'analyse ont été conçus, le plus connu
d'entre eux étant Merise (créé en 1978, sous l'impulsion du ministère de
l'industrie, par un groupement de 6 sociétés de services et un centre de
recherche informatique).

Merise propose une méthode de conception et de développement de

Systèmes d'Information complète, détaillée, en grande partie formalisée,
qui garantit (en principe) une informatisation réussie. Cependant aucune
méthode, aussi sophistiquée soit elle, ne dispense de réfléchir et une
application sans compréhension de cette méthode doit également pouvoir
produire des catastrophes. Nous ne présenterons pas cette méthode de
manière exhaustive mais seulement ses principes de base. Ceux-ci
suffisent, lorsqu'on leur adjoint un peu de réflexion, à mener correctement
l'analyse de projets informatiques de taille moyenne.

Les principales caractéristiques de la méthode sont:

1. Approche globale menée parallèlement sur les données et les

traitements.
2. Description du SI en trois niveaux:

On trouvera au paragraphe 3.6 (page ) une vue plus détaillée

des trois niveaux.
3. Découpage du processus de développement en quatre étapes
1. Étude préalable:
 recueil des infos
 diagramme des flux
 élaboration des MOT (modèle organisationnel des
traitements) et MCD (modèle conceptuel des données)
actuels
 synthèse et bilan (service rendus, analyse des
insuffisances, synthèse des besoins d'amélioration).
 choix MCD et MCT (modèle conceptuel des traitements)
nouvelle solution
 évaluation nouvelle solution
2. Étude détaillée:
  MCD, MCT, MLD (modèle logique des données) et MOT
nouvelle solution
 Conception générale: Description des MCD, MCT, MLD,
MOT. Définir l'environnement de développement
(matériel et logiciel). Mise en œuvre du dictionnaire des
données. Etude préliminaire de la mise en œuvre
(ébauche: plan de formation, documentation, plan de
réception, démarrage, initialisation des données). Etude
des solutions dégradées.
 conception détaillée: Spécification détaillée des phases à
temps réels et à temps différé. Validation données-
traitements (optimisation du MLD, ébauche du MPD
(modèle physique des données)). Evaluation de la
charge de réalisation (durée), évaluation de la mise en
œuvre, plan d'équipement matériels-logiciels.
3. Réalisation:
 Etude technique: Description de l'environnement
technique, description de l'architecture du logiciel,
description du modèle physique des données.
 Production du logiciel: Ecriture du logiciel (en appliquant
les méthodes du génie logiciel), tests unitaires (par unité
de traitement) et d'intégration.
4. Mise en œuvre:
 Mise en place des moyens: Moyens techniques (locaux,
matériel informatique, fournitures...). Moyens humains
(formation des utilisateurs, mise en place des fichiers et
de la documentation.
 Réception et lancement: Exécution des jeux d'essais
utilisateurs. Conformité avec le dossier d'étude détaillée.
Lancement du nouveau système en vraie grandeur (en
parallèle avec le système existant) pendant une période
d'observation. Arrêt de l'ancien système.
4. Description de la structure de travail:
 o Comité directeur: fixe les orientations, prend les décisions
importantes...
o Groupe projet: seule structure permanente, il comprend le
chef de projet informatique, les concepteurs et les réalisateurs
des logiciels, les représentants du groupe utilisateur. C'est lui
qui réalise les dossiers d'étude et les logiciels.
o Comité utilisateur: participe à l'élaboration des solutions, à la
validation des dossiers d'étude produits par le groupe projet.

Principes

Cette architecture est organisée en une hiérarchie de niveaux

correspondant à des perceptions différentes de la base de données. Le
groupe de normalisation Nord American ANSI , au sein duquel a été créé le
Standard Planning and Requirement Committee (SPARC) a proposé de
distinguer les niveaux suivants:

 le niveau conceptuel ;
 le niveau logique ;
 le niveau physique.

Niveau conceptuel

Décrire le QUOI indépendamment de toute contrainte d'organisation ou

technique.

 le MCD (modèle conceptuel des données):

o vocabulaire: ENTITES, RELATIONS, PROPRIETES...
o
  le MCT (modèle conceptuel des traitements):
o vocabulaire: PROCESSUS, OPERATION, EVENEMENT,
RESULTAT, SYNCHRONISATION...
o

Schéma conceptuel . Il correspond à la structure générale des données

acceptable par tous les utilisateurs potentiels; c'est le dépositaire de la
sémantique de la BD; il doit représenter l'abstraction la plus fidèle possible
de l'univers modelisé. Le modèle conceptuel permet le passage d'un
concret inaccessible (informatiquement parlant) à une abstraction
manipulable. Ce schema peut être completé par l'expression de
contraintes d'intégrité (gamme de valeurs, unicité de clé...) garantissant
la cohérence et la vraisemblance des données. Plusieurs types de
sch�mas conceptuels existent: mod�le binaire, r�seaux s�mantiques,
le mod�le E/A (entit�s/associations) .

Analogie. Si on voulait faire comparaison avec l'algorithmique et la

programmation, on pourrait comparer avec la notion de matrice carrée
au niveau conceptuel, qui donnera au niveau logique (lors du passage
à la programmation) un tableau var t : array[1..n,1..n] of integer;

Niveau logique ou organisationnel

Décrire le QUI FAIT QUOI et OU

 le MLD (mod�le logique des donn�es): Les mod�les logiques

peuvent �tre class�s selon un petit nombre de familles:
hi�rarchiques (gestion par des fichiers �classiques�), r�seaux
 (mod�le CODASYL) , objets, relationnels . C'est ce dernier mod�le
(le plus r�pandu) que nous �tudierons.
 le MOT (mod�le organisationnel des traitements): La r�partition
homme/machine, fonctionnement en temps r�el ou diff�r�,
r�partition g�ographique des donn�es et des traitements,
encha�nements des �crans, traitements associ�s � chaque
�cran...

Le sch�ma logique est la traduction du sch�ma conceptuel selon un

mod�le existant (hi�rarchique-r�seau-relationnel). Il servira de
r�f�rence aux diff�rentes vues particuli�res. Ces sch�mas sont
totalement ind�pendants de la technologie utilis�e (mat�rielle et
logicielle).

Niveau physique ou op�rationnel

Le COMMENT FAIRE. Le logiciel de développement ainsi que le type de

matériel qui sera utilisé sont choisis.

 le MPD (modèle physique des données): Description de

l'implantation physique en termes de fichiers, adresses, pointeurs...
 le MPT (modèle oPérationnel des traitements): Description de
l'architecture des unités de traitement du logiciel: les transactions
(temps réel), les programmes batch (temps différé).

Le niveau physique : perception technique de l'organisation des données.

On décrit à ce niveau un ensemble d'objets informatiques (fichiers, index,
listes, pointeurs, zones de débordements, tables d'allocation...)

Analogie. A[i,j] est log� � l'adresse

Avantages

Les applications sont indépendantes du niveau interne et donc des

chemins d'accés aux données. Un changement de stratégies d'accés ou
d'organisation entraîne une modification du schema interne, le schema
conceptuel reste inchangé.

Au niveau de la correspondance conceptuel/interne, on peut inserer un

optimiseur qui choisira le meilleur chemin d'acces aux données.

La distinction conceptuel/externe assure l'indépendance entre le niveau

des applications et le niveau conceptuel. Il est donc possible d'enrichir le
schema conceptuel sans perturber les applications existantes. L'interêt se
situe également sur le plan de la personnalisation de la base de données
aux besoins des utilisateurs, notamment afin d'assurer la confidentialité
des données.

MCD

Un modèle de données est donc un formalisme permettant de décrire les

données intervenant dans un SI et les liens existant entre ces informations
de façon claire, simple, complète et non ambiguë. Les formalismes utilisés
se situent déliberement en dehors de considérations techniques de
stockage informatique des données. Ils ne s'occupent pas plus de savoir
ce qui sera automatisé. On n'a donc aucun a priori sur la nature et
l'organisation des supports physiques de l'information (papier, fichier, ou
autres).
Nous n'abordons ici que l'aspect �données�, et laissons à d'autres plus
qualifiés l'étude des autres aspects d'une analyse informatique (champ
extrêmement vaste).

 L'élaboration du modèle de données

 Exemples
 Modèle Conceptuel des Données
o Entité
o Relations
o Propriétés
o Occurrences et Identifiants
o Les cardinalités
o Règles de verification et de normalisation d'un MCD
 Elaboration d'un MCD
o Quand?
 Modèle logique des données
 Clé d'une relation
o Relations avec des clés communes
o Les valeurs indéterminées

L'élaboration du modèle de données

Il nécessite un recensement exhaustif de toutes les informations brassées

par le système: la déstructuration. Cette phase fournit un dictionnaire de
toutes les informations évoluant dans le cadre du SI. Cette vision très
éclatée des informations du SI doit être considérée comme le point de
départ d'une recomposition, d'une structuration de ces informations qui
mettra en évidence:
  des objets, individualités identifiables, séparables de leur contexte,
caractérisés par certaines propriétés: les entités ;
 des relations entre ces entités car dès lors qu'elles interviennent à
l'intérieur d'un même système, il existe des relations (d'inter-
dépendances) entre elles.

L'idée théorique de déstructuration/restructuration se concrétise par un

travail de recollement de tous les documents circulant dans l'organisation
(avec le souci de tout rassembler). Il existe donc déjà une certaine
structuration de l'information.

On peut remarquer que cette méthode d'analyse est une méthode

ascendante (on part du détail pour arriver au général), contrairement à la
méthode généralement utilisée en algorithmique (méthode descendante).

Exemples

Ces exemples illustreront la suite de ce cours.

Exemples

Ces exemples illustreront la suite de ce cours.

Modèle Conceptuel des Données

But:

 Modéliser (formaliser) les données mémorisées dans le SI. Aspect

statique du SI.
 Le QUOI sans se préoccuper des contraintes d'organisation et
techniques.

Relations

Une relation entre plusieurs occurences (d'entités différentes ou non)

traduit l'existence de liens entre des entités. Ces liens peuvent s'établir
parfois au travers de formes particulières d'objets qui par nature mettent
en relation plusieurs entités.

Dans l'exemple 4.1: Le client X a passé la commande Y, la commande Y

contient les produits Z et T, la commande Y a produit la facture W.
Dans l'exemple 4.2: Une bibliothèque possède un livre, un livre correspond
à une uvre, une uvre a pour auteur, un livre a pour éditeur.

Propriétés

Les entités ont des propriétés, appelées attributs, chacun des attributs
d'une entité prend une valeur parmi une variété de valeurs possibles (le
domaine de l'attribut). L'ensemble des valeurs des attributs d'une entité
caractérise (complètement) l'entité considérée relativement au SI dans
lequel on se place.

L'identification des attributs pertinents des entités est une étape cruciale
dans la définition du modèle de données.

Ainsi, un étudiant aura les attributs suivants: son nom, ses prénoms, sa
date de naissance, son adresse, sa nationalité, son numéro INSEE, son
numéro d'inscription, le montant de ses droits d'inscription, un indicateur
sur le fait qu'il est ou non boursier...

Dans l'exemple 4.1: Nom de client, prénom de client.

Dans l'exemple 4.2: œuvre-ISBN, livre-cote.

Les relations peuvent être porteuses de propriétés (au même titre que
les entités ). Ainsi, un cours est en fait le point de contact entre un groupe
d'étudiants, un enseignant, une matière et une salle, et celui-ci se
caractérise par un lieu, un jour, une heure et une durée.

Occurrences et Identifiants

Dans l'exemple 4.1: Durand est une occurrence de l'entité client.

Dans l'exemple 4.2: Dunod est une occurrence de l'entité éditeur.
Dans l'exemple 4.1: Durand passe la commande Co1
Durand passe la commande Co2
Dupond passe la commande Co3
Dupond passe la commande Co4
Martin ne passe pas commande On a quatre occurrences de la relation; on
pourrait, par exemple, les représenter par

ou d'une manière plus générale par

En principe, comme chaque occurrence d'une entité est distinguable d'une

autre, pour chaque occurrence d'une entité, il existe un attribut ou un
groupe d'attributs qui constitue une clé . Un groupe d'attributs est une clé
pour une entité à la condition que :

 deux entités différentes aient systématiquement deux valeurs de clé

différentes, ou encore que toute évaluation de ce groupe d'attributs
caractérise au plus une entité;
 un sous-ensemble de ce groupe d'attributs ne soit pas une clé;
(notion de minimalité : si on retire l'un des attributs du groupe, celui-
ci perd sa qualité de clé).

Pour une même entité, plusieurs groupes d'attributs peuvent avoir le

statut de clé.
Certaines clés sont plus pratiques à manipuler: numéro, code,
mnémonique; d'autant qu'elles correspondent à des critères fréquents
d'accès aux informations.

Dans l'exemple 4.1 on pourrait par exemple prendre le numéro INSEE

comme identifiant de l'entité client. Le nom de famille ne pourrait pas être
un identifiant.

Les cardinalités
Règles de vérification et de normalisation d'un MCD
Quand?

 Dans l'étude préalable: MCD de l'existant, ébauche du MCD de la

nouvelle solution.
 Dans l'�tude d�taill�e: MCD complet de la nouvelle solution.
 On suppose avoir �tabli:
o un inventaire des propri�t�s manipul�es (enlever
polys�mes et synonymes) avec leur nature (stable, structure,
param�tre, calcul�es, mobiles, test);
o un diagramme des flux (sera revu avec le MCT);
o on a explicit� les r�gles de gestion de l'entreprise.

Mod�le logique des donn�es

Nous n'�tudierons que le mod�le relationnel mais il en existe d'autres.

Le mod�le relationnel est le mod�le de donn�es sur lequel se fonde une

famille de syst�mes de gestion de base de donn�es. Les SGBD
relationnels acceptent donc comme description de base de donn�es un
sch�ma relationnel et int�grent des proc�dures de manipulation des
donn�es ainsi structur�es.

Le concept math�matique sous-jacent au mod�le relationnel est la

notion (ensembliste) de relation , c'est-�-dire de sous-ensembles du
produit cart�sien d'ensembles (domaines).

Dans le cadre de base de donn�es, on suppose implicitement que l'on

consid�re des relations finies.

Les �l�ments d'une relation sont appel�s tuples ou n-uples . Une

relation de contient des tuples , les
appartenant � . D'un point de vue plus pratique, la relation peut �tre
vue comme une table , chaque ligne correspondant � un tuple, les
colonnes correspondant aux composantes d'un tuple. Les colonnes (au lieu
d'�tre rep�r�es par un indice) portent des �noms� appel�s attributs .
Le sch�ma d'une relation est la liste de ses attributs (assortis
�ventuellement de leur domaine ).

Une entit� E sera repr�sent�e par une relation dont le sch�ma consiste
en la liste des propri�t�s (attributs) de cette entit�. Chaque tuple de la
relation repr�sente donc une occurence.

Un ensemble de relations (ou de tables) constitue donc une structure

d'accueil de donn�es: un sch�ma relationnel . Pour impl�menter une
base de donn�es relationnelle , il faudra donc traduire le MCD r�sultat
de l'analyse en un sch�ma relationnel .

Une relation entre les entit�s sera repr�sent�e par une

relation poss�dant comme attributs toutes les cl�s des entit�s
, ainsi que les propri�t�s port�es par la relation. Un
�ventuel renommage de certains attributs peut �tre n�cessaire d�s lors
que sont d�finis pour des entit�s distinctes des attributs homonymes.

Comme pour les entit�s, on d�finit la notion de cl� d'une relation.

Ainsi dans la relation mariage_civil(n_insee_�poux, n_insee_�pouse,
date_mariage, date_divorce) les cl�s possibles seraient (n_insee_�poux,
n_insee_�pouse, date_mariage) ou (n_insee_�poux, n_insee_�pouse,
date_divorce) En effet certains couples (ex: Burton/Taylor) ont pu se
marier plusieurs fois et donc �galement divorcer plusieurs fois.

Les tables correspondant aux relations d'un MCD contiennent par

construction des cl�s �trang�res.

Cl� d'une relation

 Relations avec des cl�s communes

 Les valeurs ind�termin�es

Relations avec des cl�s communes

Lorsque deux relations (tables) ont en commun une cl� candidate (une
m�me valeur de cl� pouvant identifier un n-uple de chacune des
relations), il parait donc naturel de combiner ces deux n-uples en un seul,
ou encore de remplacer les deux relations par une seule dont l'ensemble
des attributs serait l'union des attributs de chacune des relations.

Ainsi la relation (au niveau conceptuel) �est occup� par� entre les
bureaux et leurs occupants, de cardinalit�
si l'affectation des bureaux est telle qu'une personne n'occupe qu'un seul
bureau (bien qu'un bureau puisse h�berger plusieurs personnes),
donnerait en principe lieu � trois relations (au niveau logique, c'est-�-dire
trois tables au niveau physique): bureau(num�ro, superficie, ... )
personne(matricule, nom, pr�nom, ... )
occupant(num�ro, matricule)

Cependant matricule est alors une cl� commune aux relations personne
et occupant. La relation occupant indique pour toute personne occupant
un bureau quel est le num�ro de ce bureau. Cette information pourrait
alors se retrouver dans une table personne_bis(matricule, nom,
pr�nom, ..., num�ro_bureau) qui permettrait de faire disparaitre la table
occupant.

Cette simplification du sch�ma relationnel pr�sente l'avantage

d'�conomiser de la place m�moire; de plus certaines interrogations
verront leur temps d'ex�cution diminuer.

Les valeurs ind�termin�es

La manipulation de tables � laquelle on vient de se livrer peut faire

appara�tre des situations particuli�res: on peut parfaitement admettre
que faute de place une personne n'ait pas de bureau propre. D�s lors,
l'attribut num�ro_bureau du t-uple correspondant � cette personne dans
la relation personne_bis n'a pas de valeur: elle est ind�termin�e.

Cette possibilit� (ne pas donner de valeur � un attribut) existe dans de

nombreux SGBDR.

 Analyse du projet Disc

o Approche na�ve
o Analyse
  Niveau Conceptuel
 Pr�sentation de la base de donn�es Disc
o Pr�sentation de la base de donn�es
o Structures des tables
 Chansons
 Oeuvres
 Artistes
 Genre
 Exemplaires
 Pr�t
 Adh�rents
 Villes
o Relations
o Derni�res remarques
o Autre analyse
 Description
 R�sultat

Approche na�ve

On souhaite m�moriser le contenu d'une dicoth�que dont le but est le

pr�t de disques (CD ou vinyl) � ses adh�rents.

Il faut conna�tre les uvres, les exemplaires de chaque uvre, les

artistes correspondants, les renseignements sur les adh�rents.

Pour ce faire la premi�re solution consisterait en un (gros) tableau

permettant de stocker toutes les informations dont on dispose sur un
album: nom de l'album, interpr�te, morceaux (plusieurs), le genre de
musique, le type de support (vinyl, CD), etc... ainsi que celles dont on
dispose sur les adh�rents.

La repr�représentation de ces informations �� plat� sous la forme d'un

seul tableau montre d'embl�e ses limites:
  En effet, on ne va pas reprendre systématiquement toutes les
informations liées à un album du fait que la colonne des titres
contient plusieurs titres pour un même album.
 Par ailleurs, cette disposition privilégie l'approche de ces
informations album par album. Et par cons�quent, elle est moins
commode pour une approche par interpr�te, par emprunteur.

Avec cette solution on a donc des difficult�s � percevoir s�parement des

�l�ments (entit�s ) qui sont pourtant bien distinctes (albums,
interpr�tes, adh�rents).

On a par la m�me occasion, des difficult�s � regrouper certaines

informations: les albums d'un m�me interpr�te, les albums d'un m�me
genre, les albums emprunt�s par un m�me adh�rent, etc. On dispose
bien dans un tableur de la possiblit� de trier un tableau suivant telle ou
telle colonne mais l� on se heurte � un probl�me de choix (il n'y a pas
de raison de privil�gier un ordre par rapport � un autre).

Par ailleurs, d�s lors qu'un tableau est tri�, il s'agit de respecter cet ordre
lors de toute mise-�-jour du tableau, ce qui complique la proc�dure de
saisie de nouveaux albums.

M�me si le tableau devait �tre tri�, la recherche d'une information

pr�cise demeurerait assez fastidieuse, cette recherche devient encore
moins ais�e s'il s'agit de retrouver des croisements d'information (X a t-il
fait une reprise d'un titre d�j� interpr�t� par Y). La difficult� se corse
encore lorsqu'il ne s'agit plus d'acc�der � une information mais d'extraire
une s�rie d'informations (les albums de Jean Ferrat qui contiennent des
textes d'Aragon).

On remarque �galement que, dans une telle repr�sentation, de

nombreuses informations figurent plusieurs fois (artiste: nom et pr�nom;
emprunteur: adresse ...). Ces informations �tant saisies individuellement,
outre la perte d'efficacit�, il existe des risques d'incoh�rence (une
m�me donn�e saisie diff�remment � deux endroits distincts).
La r�p�tition d'une m�me donn�e peut �tre �galement p�nalisante si
celle-ci vient � changer, en effet au lieu d'avoir � proc�der � une seule
mise-�-jour, on est oblig� de reporter la m�me modification partout o�
cette donn�e figure (l� encore perte d'efficacit� et risque
d'incoh�rence). Par exemple que faire lorsqu'un chanteur d�cide de
changer de nom ?

Niveau Conceptuel

Quelles entit�s peut-on identifier? Elles sont au nombre de 5:

1. Les uvres: L'entit� centrale de notre base de donn�es. Il s'agit de

l' uvre �abstraite�, comme on parle de l'album blanc des Beatles,
sans se r�f�rer � un exemplaire pr�cis, mais seulement � l'
uvre elle-m�me. Les propri�t�s d'une uvre seront:
o son intitul�,
o son ann�e de parution,
o les morceaux qui la composent.
2. Les Artistes: Qui a enregistr� tel disque? Les propri�t�s d'un
artiste seront:
o son nom,
o son pr�nom,
o �ventuellement le groupe dont il fait partie,
o son genre de musique (rock, classique, etc...) .
3. Les Exemplaires: L'entit� exemplaires est totalement diff�rente de
l'entit� uvres. Il s'agit de l'objet physique, l'exemplaire physique
d'une uvre, par exemple l'exemplaire en vinyl de l'album blanc des
Beatles qui se trouve dans la discoth�que de votre grand-m�re. Il
peut y avoir plusieurs exemplaires d'une m�me uvre. Les
propri�t�s d'un exemplaire seront:
o son type de support (CD ou vinyl),
o son prix (pour remboursement en cas de perte ou de
d�t�rioration).
 4. Les Adh�rents: Il s'agit des personnes inscrites au club. Les
propri�t�s d'un adh�rent seront:
o son nom,
o son pr�nom
o son adresse ,
o la date du d�but de son adh�sion,
o le nombre de personnes qui auront acc�s aux uvres
emprunt�s par cet adh�rent pour pouvoir faire quelques
statistiques sur la p�n�tration des uvres en stock dans le
public.
5. Les Pr�ts: tel adh�rent emprunte tel exemplaire . Les propri�t�s
d'un pr�t seront:
o sa date de d�but (date de sortie de l'exemplaire),
o sa date de fin (date de rentr�e de l'exemplaire).

Les relations existant entre ces entit�s sont d�crites dans la figure5.1.

Figure 5.1: Cardinalit�s apr�s une premi�re analyse

On remarque assez vite que ces choix vont amener des difficult�s:

 Si on fait figurer les villes dans chaque fiche d'adh�rent, on cr�e

une redondance des donn�es et un risque d'inconsistance . On va
donc cr�er une nouvelle entit�: Villes. Les propri�t�s d'une ville
seront:
o son nom,
o son code postal.
  M�me remarque pour le genre musical des artistes. On va donc
cr�er une nouvelle entit� Genres. La seule propri�t� d'un genre
sera son nom.
 Garder les titres des morceaux composant un disque avec les
renseignements concernant le disque lui-m�me pose un autre
probl�me: quelle place r�server? Si on r�serve peu de place, on
sera vite d�bord�. Si on r�serve beaucoup de place (par exemple
de quoi ranger 40 titres) on perdra une place �norme qui sera
r�serv�e pour tous les disques, y compris ceux qui ne contiennent
qu'une dizaine de morceaux (ce qui est le cas pour la plupart des
uvres); et il pourra quand m�me exister des disques qui aient plus
de morceaux que ce que vous aviez r�serv� . Un autre probl�me
r�sultant du choix d'une telle structure: elle rend presque
impossible la recherche d'un morceau particulier, dont on ne connait
que le titre, mais ni l'interpr�te, ni l' uvre.
Nous allons donc cr�er une nouvelle entit� pour ��clater� les
donn�es: chansons. Les propri�t�s d'une chanson seront:
o son titre,
o son num�ro d'ordre sur le disque.

Les relations existant entre ces entit�s sont d�crites dans la figure5.2.

Figure 5.2: Cardinalit�s apr�s �clatement des donn�es

Il n'est plus question maintenant, par exemple, de reporter sur la ligne

correspondant � un exemplaire toutes les informations relatives � l'
uvre. On placera donc, sur la ligne correspondante, une information
particuli�re � partir de laquelle on pourra retrouver, dans le tableau
correspondant, ce qui concerne l' uvre (ce type d'information est appel�
cl� �trang�re ).

Mais, a priori on ne dispose pas de cl� pour les uvres. Par contre, on
dispose de ce type d'information pour les villes, plus exactement les
bureaux distributeurs: le code postal. Ainsi, on pourra se contenter au
niveau de l'adresse d'une personne du bureau distributeur d�s lors que
l'on dispose d'un tableau (codePostal, bureauDistributeur).

Reprenons cette id�e du code (du num�ro, du matricule...) pour nos

albums, nos artistes... Cela fait partie de notre vie: vous avez un numero
INSEE, un num�ro de carte d'�tudiant, un num�ro de dossier pour votre
organisme logeur, un num�ro de compte en banque, les livres ont un
num�ro ISBN et une cote s'ils appartiennent � une biblioth�que, les
voitures ont un num�ro min�ralogique, les produits du commerce des
�codes � barres� etc, etc...

Pour les entit�s qui n'ont pas de cl� �naturelle�, nous devrons en
cr�er une de toutes pi�ces.

Pr�sentation de la base de donn�es

Maintenant que tous les travaux pr�liminaires ont �t� faits, nous allons
pouvoir enfin contempler la base que nous venons de construire.
(L'analyse a �t� faite la plus r�aliste possible, mais certains choix ont
�t� fait dans un but de facilit� plut�t que de r�alisme.)

Nous rappelons que, pour �viter les confusions, nous utiliserons les mots
suivants:

uvre:
l' uvre logique, comme on parle de l'album blanc des Beatles, sans
se r�f�rer � un exemplaire pr�cis, mais seulement � l' uvre
elle-m�me;
exemplaire:
un exemplaire physique d'une uvre, par exemple l'exemplaire en
vinyl de l'album blanc des Beatles qui se trouve dans la discoth�que
de votre grand-m�re;
intitul�:
le nom d'une uvre, par exemple l'album blanc;
chanson:
une des chansons qui se trouve dans une uvre, par exemple
Revolution 9 sur l'album blanc des Beatles.
On �vitera d'utiliser le mot titre qui peut pr�ter � confusion (on parle en
effet � la fois du titre d'un disque -pour son intitul�- ou du titre d'une
chanson). On �vitera �galement de parler d'un disque, on essaiera de
choisir entre les mots uvre et exemplaire.

Structures des tables

Quand on rencontrera le symbole devant une ligne, cela signifiera que

cette propri�t� a �t� choisie comme cl� dans cette table.

Si deux lignes sont pr�c�d�es de , cela signifiera, non pas qu'il y a

deux cl�s, mais qu'il s'agit d'une cl� compos�e.

Chansons

Une fiche correspond � une chanson dans une uvre (voir figure6.1). On
connait l' uvre par son code.

Figure 6.1: Structure de la table Chansons

Oeuvres

Une fiche correspond � une uvre (voir figure6.2), la plupart des

renseignements se trouvant dans d'autres tables auxquelles on aura
acc�s gr�ce aux cl�s �trang�res .

Figure 6.2: Structure de la table Oeuvres

Artistes

Une fiche correspond � un artiste (voir figure6.3). Pour la musique

contemporaine, il s'agit de l'interpr�te, pour la musique classique, il s'agit
du compositeur. Le choix est tout-�-fait discutable, mais tant pis...

Figure 6.3: Structure de la table Artistes

Genre

Une fiche correspond � un genre musical -rock, classique, blues, etc.-

(voir figure6.4).

Figure 6.4: Structure de la table Genre

Exemplaires

Une fiche correspond � un exemplaire physique en rayon (voir figure6.5).

Chaque exemplaire peut �tre sur vinyl ou CD.

Figure 6.5: Structure de la table Exemplaires

Son prix est indiqu� pour pouvoir �tablir une facture en cas de perte.

Exemplaires

Une fiche correspond � un exemplaire physique en rayon (voir figure6.5).

Chaque exemplaire peut �tre sur vinyl ou CD.

Figure 6.5: Structure de la table Exemplaires

Son prix est indiqu� pour pouvoir �tablir une facture en cas de perte.

Pr�t

Une fiche correspond � un emprunt d'un exemplaire (voir figure6.6).

Figure 6.6: Structure de la table Pr�t

Adh�rents

Une fiche correspond � un adh�rent (voir figure6.7).

Figure 6.7: Structure de la table Adh�rents

Villes

Une fiche correspond � un bureau distributeur (voir figure6.8).

Figure 6.8: Structure de la table Villes

Relations

La figure 6.9 donne une repr�sentation des relations entre les tables.

Figure 6.9: Relations dans la base Disc

Derni�res remarques
On a fait certaines approximations dans l'analyse de cette base. Certaines
ont d�j� �t� �voqu�es (par exemple le genre de musique, rattach�
� un artiste plut�t qu'� une uvre ou m�me � une chanson).

Une autre concerne le fait qu'un artiste peut enregistrer un album seul ou
� l'int�rieur d'un groupe. Cette information n'est pas g�r�e dans la
base. Il est, par exemple, impossible de trouver dans la base le moindre
lien entre les disques des Rolling Stones et ceux de Mick Jagger ou de
Keith Richard. M�me remarque pour les Beatles et John Lennon.

On a �galement fait de grosses approximations (si on se r�f�re au r�el)

sur les adresses: il a d�j� �t� mentionn� que l'on ne garde que la ville;
on n'a pas non plus tenu compte que certaines villes n'ont pas de bureau
distributeur propre; ce cas a �t� volontairement oubli� pour conserver
au champ CodePostal dans la table Villes sa fonction de cl�.

Toutes ces approximations ont �t� faites en g�n�ral dans un but

p�dagogique, afin de ne pas surcharger la base et pour en rendre la
compr�hension plus ais�e.

Il faut bien se souvenir que l'analyse d'un syst�me informatique n'est pas
un travail objectif mais qu'elle d�pend surtout de la vision (plus ou moins
claire, souvent) qu'en ont ses futurs utilisateurs. Quand un informaticien
r�alise une analyse pour le compte de quelqu'un d'autre, c'est � lui de
d�tecter les probl�mes �ventuels et de les signaler au client. Cependant
ce dernier peut parfaitement faire, en toute connaissance de cause, des
choix qui paraissent r�ducteurs, pour peu que les oublis ainsi commis ne
concernent que des informations qui ne l'int�ressent pas.

Le gros probl�me dans un tel cas est un �ventuel changement d'avis

dans le futur. Il serait alors sans doute impossible d'adapter la solution
choisie.
Mieux vaut donc une sur-abondance raisonnable d'informations qu'on
n'utilise pas pour l'instant, plut�t qu'un oubli d'informations dont on
pourrait avoir besoin plus tard.

Pour terminer ce chapitre, on trouvera ci-dessous une analyse totalement

diff�rente du m�me probl�me.

Description

Un disque est compos� de plages musicales. Pour avoir une base

performante, on d�sire distinguer les interpr�tations diff�rentes d'un
m�me titre.

Les informations suivantes sont � m�moriser: le titre du disque, ses

r�f�rences d'�dition, son code barre, les titres qui le composent; puis
pour chaque titre, le compositeur, la date d'enregistrement, le lieu
d'enregistrement, le ou les interpr�tes et la dur�e de l'interpr�tation.
Pour les compositeurs et les interpr�tes, on ne m�morise que le nom.

On adoptera les choix suivants:

 Les r�f�rences d'�dition sont celles que donne l'�diteur au disque

(exemple: ECM New Serie 736943). On ne s'occupera pas de
l'�diteur.
  Le compositeur d'un titre est consid�r� comme �tant unique. S'il y
avait plusieurs compositeurs (ce qui est relativement rare), ils
seraient not�s comme un nom unique et consid�r�s comme un
groupe.

Le compositeur peut donc �tre soit un individu, soit un groupe.

 Les interpr�tes varient selon les interpr�tations. Les interpr�tes
peuvent �tre: soit le compositeur (qui est alors un interpr�te
comme un autre), soit un groupe, soit un regroupement
d'interpr�tes, soit un groupe et des interpr�tes invit�s... Dans tous
les cas, seuls le ou les noms (du groupe, des interpr�tes s'il s'agit
d'un regroupement d'interpr�tes) nous int�ressent. Puis, dans une
recherche plus approfondie, les membres du groupe pourront �tre
demand�s.
Vous pouvez donc consid�rer un groupe comme un interpr�te
particulier.

 Une m�me interpr�tation peut appara�tre sur plusieurs disques.

 On ne tiendra pas compte des diff�rents mouvements � l'int�rieur
d'une composition (classique).
 La probabilit� pour qu'un m�me titre soit enregistr� par des
interpr�tes diff�rents, le m�me jour, sera consid�r�e comme
nulle. L'�galit� possible des lieux et des dates d'enregistrements
ne sera pas consid�r�e comme une redondance.

Il sera int�ressant de savoir quels sont les membres d'un groupe. Pour
cela, on m�morisera � partir de quelle date un interpr�te appartient �
un groupe et � quelle date on suppose qu'il le quitte. On supposera que le
programme g�re la validit� de ces dates.
R�sultat

On obtient le sch�ma conceptuel de la figure 6.10.

Figure 6.10: MCD

Les tables sont:

 La table DISQUES qui contient le code barre, le titre du disque, le

nombre de plages et les r�f�rences de l'�diteur.
 La table MORCEAUX qui correspond aux interpr�tations. Elle
contient les informations associ�es � l'enregistrement et la dur�e.
Une m�me interpr�tation peut appara�tre sur plusieurs disques.
 La table #TEX2HTML_WRAP6630# UVRES qui correspond � la
cr�ation du compositeur.
 La table COMPINTE (nom donn� pour COMPositeurs et INTErpr�tes)
contient les compositeurs et les interpr�tes. En effet, un
 compositeur pouvant �tre un interpr�te et les informations
m�moris�es dans les deux cas �tant les m�mes, on peut
regrouper les deux entit�s en une seule, �vitant ainsi de dupliquer
les informations pour tous les compositeurs-interpr�tes.
De plus cette table contient des fiches correspondant aussi bien �
des groupes qu'� des individus.

Quand une uvre est interpr�t�e par un groupe, on trouvera la fiche du

groupe et, le plus souvent possible, les fiches des interpr�tes qui
appartiennent au groupe. La fiche d'une interpr�tation, si elle est
interpr�t�e par un groupe, sera de pr�f�rence reli�e au groupe plut�t
qu'aux membres du groupe. On trouvera les membres du groupe par la
relation APPARTENANCE.

Cela permettra de traiter tous les cas possibles; en particulier, il n'y a

aucun probl�me pour une interpr�tation par un groupe invitant un
interpr�te. Il n'y a aucune difficult� pour enregistrer un groupe sans
conna�tre les membres, pour ajouter un membre � un groupe existant,
pour d�finir une interpr�tation effectu�e par un seul membre du
groupe...

On ajoute un champ logique, appel� EstGroupe, qui permettra de

diff�rencier les individus et les groupes. Il contiendra la valeur vrai si la
fiche est celle d'un groupe, la valeur faux s'il s'agit d'un individu.

APPARTENANCE est une relation entre la table COMPINTE, vue comme

contenant les fiches des groupes, et la table COMPINTE, vue comme
contenant les fiches des individus. A cette relation sont associ�es des
informations: les dates de d�but et de fin d'appartenance � un groupe.
Un �l�ment de cette relation indique qu'un individu, interpr�te dont la
fiche est dans la table COMPINTE, a appartenu � un groupe, dont la fiche
est aussi dans la table COMPINTE. Les dates seront g�r�es de telle
fa�on que la base reste coh�rente. Un interpr�te r�f�renc� sur une
fiche de la table MEMBRES est suppos� avoir particip� � tous les
enregistrements effectu�s par le groupe r�f�renc�, entre la date de
d�but et la date de fin d'appartenance � ce groupe.

Utilisation d'Access dans le cadre du projet Disc

 Vue globale de MicroSoft Access

o Les diff�rents objets d'Access
 Description des objets
 Gestion des objets
 Gestion des tables
o Introduction
o Gestion des tables en mode cr�ation
 Structure d'une table
 Noms des champs
 Les diff�rents types de donn�es
 Notions de cl� primaire et d'index
o Exercices
 Liens entre tables
o Pourquoi lier les tables entre elles?
o Relations entre les tables de la base Disc
o Exercices
 Les requ�tes
o Int�r�t des requ�tes
o Expression d'une requ�te dans un SGBD
 o Exemples
 Exemple de requ�te mono-table
 Exemple de requ�te multi-tables
 Exemple de r�sultat d'une requ�te
o Description de la requ�te
o Repr�sentation de la requ�te
o Requ�tes avec group by
 Qu'est-ce que c'est?
 Mise en uvre
o Requ�tes de mise � jour
o Exercices
 Requ�tes mono-table
 Requ�tes multi-tables
 Requ�tes avec calculs
 Requ�tes de mise � jour

Les diff�rents objets d'Access

La fen�tre Base de donn�es permet d'interagir avec la BD dont le nom

est donn� dans la barre de titre, c'est-�-dire cr�er de nouveaux objets,
les ouvrir, les modifier, etc. Une liste des objets standard manipul�s par
Access est donn�e dans la colonne gauche de la fen�tre i.e. table,
requ�te, formulaire, �tat, macro et module. Ces objets sont bri�vement
d�crits dans cette section. Certains d'entre eux sont d�taill�s dans les
chapitres suivants de ce rapport.

Description des objets

MicroSoft Access ne contient pas uniquement des donn�es. Il contient

�galement des objets n�cessaires � la gestion de ces donn�es. Il y a six
objets de base exploitables sous Access: table, requ�te, formulaire, �tat,
macro et module.
Table:

C'est la structure fondamentale d'une BD Access. Elle contient les

donn�es de la base. C'est le premier objet cr�� dans une BD. Une
fois les diff�rentes tables constituant une BD cr��es, il faut
�tablir des liens entre celles-ci pour garantir la coh�rence des
donn�es de la BD. Ces liens sont appel�s relations.

Requ�te:

C'est une structure permettant d'exprimer des op�rations

d'interrogation et de mise � jour de la BD. Elle permet �galement
de construire d'autres objets tels que le formulaire et l'�tat d�crits
ci-dessous.

Formulaire:

C'est un masque d'�cran permettant de saisir de fa�on simple et

rapide des donn�es dans une ou plusieurs tables. La
repr�sentation � l'�cran d'un formulaire est la m�me que celle
des imprim�s formulaires classiques. Un formulaire peut �tre
simple (une simple facture) ou �labor�, il int�gre dans ce cas des
graphiques ou des sous-formulaires qui sont eux-m�mes des
formulaires.

Etat:

Sert � afficher ou imprimer des donn�es de mani�re agr�able.

Ces donn�es peuvent �tre extraites directement � partir d'une
table. Elles peuvent �tre �galement le r�sultat de l'ex�cution
d'une requ�te. Un �tat peut �tre une �tiquette de publipostage,
une liste, une enveloppe, une facture, etc.

Macro:

A l'instar des fichiers de type batch de MS-DOS, une macro-

commande est une suite de commandes r�alisant une t�che
donn�e. Elle sert � automatiser un traitement souvent r�alis�
 sans avoir � r��crire � chaque fois la suite des commandes
constituant ce traitement. L'ex�cution d'une macro se fait par
simple appel � celle-ci.

Module:

Comme les macros, il sert � automatiser des traitements mais

cette fois-ci plus compliqu�s. Il est utilis� en g�n�ral par les
programmeurs car son utilisation n�cessite la connaissance du
langage Access Basic.

Gestion des objets

La fen�tre Base de donn�es permet la gestion des diff�rents objets

gr�ce � trois boutons: Nouveau, Ouvrir et Modifier.

Le bouton Nouveau:

permet de cr�er un objet d'un type s�lectionn�. La proc�dure de

cr�ation d'un objet est la suivante:

 s�lectionner le type d'objet � cr�er en cliquant sur l'onglet

correspondant dans la fen�tre Base de donn�es;
 puis cliquer sur le bouton Nouveau.

Access vous propose alors une cr�ation guid�e par un assistant ou

sans assistant dans une bo�te de dialogue.
Le bouton Ouvrir:

ouvre un objet d�j� cr��. La proc�dure d'ouverture d'un objet

est la suivante:

 s�lectionner le type d'objet � ouvrir en cliquant sur l'onglet

correspondant dans la fen�tre Base de donn�es. Une liste
des objets du type d'objet s�lectionn� est propos�e dans la
fen�tre Base de donn�es;
  s�lectionner l'objet � ouvrir � partir de la liste en cliquant
dessus;
 cliquer sur le bouton Ouvrir.

Le bouton Modifier:
modifie un objet existant. La proc�dure est la m�me que celle de
l'ouverture sauf que cette fois-ci il faut cliquer sur le bouton Modifier.

Introduction

Comme il a �t� dit pr�c�demment, les donn�es d'une BD sont

stock�es dans une ou plusieurs tables. Chaque table regroupe les
informations relatives � un sujet donn�. Les informations sont
pr�sent�es dans ces tables sous forme de tableaux. Par exemple, la
table Artistes de la BD Disc contient les caract�ristiques de chacun des
artistes ayant enregistr� les diff�rents albums.

Figure 8.1: La table Artistes de la base Disc

La figure8.1 montre les donn�es de cette table. Chaque ligne du tableau
concerne un artiste. Elle repr�sente un article de la table Artistes. Les
cinq colonnes du tableau contiennent respectivement les valeurs des
champs Code_Artiste, Nom, Pr�nom, Groupe et Code_Genre relatives �
un artiste. Dans ce chapitre, on d�crira la structure d'une table et les
diff�rentes op�rations de gestion des tables (cr�ation, consultation,
mise � jour et tri). Il existe deux modes de gestion de l'objet Table: le
mode cr�ation et le mode feuille de donn�es. Le premier mode agit sur
la structure de la table. Par contre, le deuxi�me mode agit sur les
donn�es de celle-ci.

Structure d'une table

Une table est une collection d'articles comportant exactement la m�me

structure (les m�mes champs, avec le m�me type, la m�me longueur et
le m�me nom, pour tous les articles). La structure d'une table peut �tre
alors d�crite par la structure d'un article i.e. l'ensemble des champs le
composant ainsi que leurs caract�ristiques. Les caract�ristiques d'un
champ sont les suivantes:

 son nom (ou identificateur);

 son type;
 sa taille: d�pend du type;
 est-il une cl� primaire ?
 est-il un index ?

Noms des champs

L'attribution de noms aux champs d'une table doit ob�ir aux r�gles
suivantes:

 Un nom de champ peut comporter jusqu'� 64 caract�res.

  Un nom de champ peut contenir des espaces.
 Deux champs ne peuvent pas avoir le m�me nom dans une m�me
table.
 Il est souhaitable pour des raisons de compr�hension qu'un nom de
champ soit parlant i.e. v�hicule le sens de l'information qu'il
contient. Par exemple, si un champ d�signe le code postal d'une
ville il serait pr�f�rable que le champ soit appel� CodePostal,
CodePost ou Postal.

Les diff�rents types de donn�es

Le type de donn�e d'un champ d�crit la plage des valeurs que peut
prendre ce champ. Par exemple, le type Num�rique d�crit l'ensemble
des valeurs r�elles que la machine peut repr�senter. Il existe huit types
de donn�es dans Access:

Texte:

c'est une suite d'au maximum 255 caract�res. Les caract�res

peuvent �tre des lettres ou des chiffres. Ils peuvent �tre
�galement des espaces.

Num�rique:

sert � stocker des nombres.

Date/Heure:

sert � stocker des dates et des heures.

Mon�taire:

sert � stocker des valeurs mon�taires.

Compteur:
 on ne peut pas saisir dans un champ de ce type. C'est Access qui le
g�re automatiquement. A chaque fois qu'un article est saisi, Access
incr�mente syst�matiquement la valeur d'un compteur puis
l'attribue au champ de type Compteur de cet article.

Oui/Non:

permet de saisir des valeurs bool�ennes. La valeur Oui correspond

� la valeur logique Vrai et Non correspond � la valeur Faux.

M�mo:

c'est une suite de 1 � 64000 caract�res. Il sert � ajouter des

commentaires �l'article.

Liaison OLE:

destin� � recevoir un objet de taille maximale 128Mo, cr�� par

une autre application Windows, une image dessin�e avec
Paintbrush par exemple.

Notions de cl� primaire et d'index

Notion de cl� primaire:

La notion de cl� primaire est tr�s importante. Celle-ci est un champ

ou une combinaison de plusieurs champs permettant d'identifier de
fa�on unique un article dans une table. Par exemple, le num�ro
d'INSEE est souvent utilis� pour identifier une personne dans une
table telle que Clients, Etudiants, Personnel, Fournisseurs, ... Comme
on le verra au chapitre9, une cl� primaire sert � �tablir des
relations entre tables.

Notion d'index:

Tr�s souvent, la saisie des informations ne se fait pas dans l'ordre

facilitant leur observation et leur analyse et permettant de les
 rechercher rapidement. Comme tous les SGBD, Access met � la
disposition de l'utilisateur une technique appel�e indexation pour
changer cet ordre. Cette technique consiste en une simple
d�signation par l'utilisateur d'un crit�re de tri appel� cl� d'index.
Ce crit�re est un champ ou une combinaison de plusieurs champs
d'une table. Les donn�es d'une table index�e sur un crit�re
donn� sont ordonn�es suivant ce crit�re. L'ordre peut �tre
croissant ou d�croissant. Par exemple, si on associe un index sur le
champ date du vol de la table Vols, donn�e pr�c�demment, alors
l'affichage des vols programm�s se fera suivant les dates de ces
derniers.
Mais, plus important, l'index permet une recherche plus efficace:
Access trouvera plus rapidement une information dans une table
index�e.

Exercices
Pourquoi lier les tables entre elles?

Dans la table Albums, pour qu'un article (un album) existe, il faut que son
auteur existe aussi dans la table Artistes. Il existe donc un lien (une
correspondance) logique entre le champ code_Artiste de la table Oeuvres
et le champ code_Artiste de la table Artistes.
Supposons maintenant qu'un article, par exemple celui qui d�crit l'auteur
ACDC, soit supprim� par accident de la table artistes. Access ne pourrait
plus r�pondre aux questions du style �afficher le nom de l'artiste de
Highway to hell�. Ce probl�me est connu sous le nom de probl�me
d'int�grit� r�f�rentielle. Access offre un moyen de renforcer cette
int�grit� en cr�ant explicitement une relation entre les deux tables ci-
dessus sur le champ CodeArt.

Pour plus de renseignements sur les relations et leurs cardinalit�s on se

reportera � la page .

Relations entre les tables de la base Disc

Les relations entre les tables de la base Disc sont donn�es dans la
figure9.1.

Figure 9.1: Relations entre les tables de la base Disc

Exercices
Les requ�tes

 Int�r�t des requ�tes

 Expression d'une requ�te dans un SGBD
 Exemples
o Exemple de requ�te mono-table
o Exemple de requ�te multi-tables
o Exemple de r�sultat d'une requ�te
 Description de la requ�te
 Repr�sentation de la requ�te
 Requ�tes avec group by
o Qu'est-ce que c'est?
o Mise en uvre
 Requ�tes de mise � jour
 Exercices
o Requ�tes mono-table
o Requ�tes multi-tables
o Requ�tes avec calculs
o Requ�tes de mise � jour
Dominique Gonzalez

Int�r�t des requ�tes

Une requ�te est un objet (outil) qui sert essentiellement �:

 Poser des questions sur une base de donn�es. Il s'agit d'une

extraction d'informations � partir d'une ou plusieurs tables de la
base de donn�es.
 Mettre � jour automatiquement la base de donn�es (ajouter,
supprimer et modifier des articles).
 Construire d'autres objets d'Access, les formulaires par exemple.

Expression d'une requ�te dans un SGBD

L'expression d'une requ�te dans un syst�me de gestion de base de

donn�es consiste en la sp�cification des �l�ments suivants:

 Les tables de la BD concern�es par la requ�te. Ces tables doivent

�tre ouvertes lors du traitement de la requ�te.
 Les liens (relations) entre les diff�rentes tables.

 Les champs � afficher si la requ�te est une question (c'est souvent

le cas).
 Les crit�res de s�lection. Ce sont des conditions qui portent sur un
ou plusieurs champs appartenant aux tables ouvertes. Ils
permettent de restreindre le champ d'action de la requ�te
(l'affichage par exemple) � certains articles, ceux qui les v�rifient.
 Crit�re de tri. Dans le cas o� les donn�es doivent �tre tri�es �
l'affichage, il faut pr�ciser le crit�re (champ) selon lequel elles sont
tri�es.
Exemple de requ�te mono-table

Requ�te Albm1985:

afficher, par ordre alphab�tique croissant, les titres de tous les

albums sortis en 1985.

Tables ouvertes:

albums

Champs affich�s:

albums.titreAlbum

Crit�res de s�lection:

albums.ann�eSortie="1985"

Crit�re de tri:

albums.titreAlbum (croissant)

Exemple de requ�te multi-tables

Requ�te AlbArt85:

Modifier la requ�te pr�c�dente pour afficher �galement les noms

des artistes des diff�rents albums.

Tables ouvertes:

albums, artistes

Jointures:

album.codeArtiste=artistes.codeArtiste

Champs affich�s:
 albums.titreAlbum, artistes.nomArtiste

Crit�res de s�lection:

albums.ann�eSortie="1985"

Crit�re de tri:

albums.titreAlbum (croissant)

On appelle jointures les liaison entre les champs qui permettent de lier
entre elle deux fiches de deux tables diff�rentes.

Exemple de r�sultat d'une requ�te

Soient les deux tables Oeuvres et Artistes.

Oeuvres contient les donn�es suivantes:

et Artistes contient les donn�es suivantes:

Le nom de l'artiste qui a compos� l' uvre se trouve dans le fichier

Artistes. Pour avoir une vue globale sur les deux fichiers on a la jointure :
Oeuvres.Code_Artiste = Artistes.Code_Artiste ce qui donne:

Description de la requ�te
Une requ�te est d�crite par :

 les tables utilis�es,

 les champs (ou expressions) affich�s,
 les liens entre les tables,
 les conditions (c'est-�-dire les expressions permettant de choisir les
informations qui seront trait�es ou affich�es),
 les champs (ou expressions) selon lesquels seront class�es (tri�es)
les informations affich�es.

Repr�sentation de la requ�te

Next: Mise en uvre Up: Requ�tes avec group by Previous: Requ�tes avec
group by

Qu'est-ce que c'est?

Certains probl�mes nous am�nent � nous poser des questions sur des
groupes d'articles:

 dans une base de donn�es o� figurent les factures d'une

entreprise, afficher les ventes par d�partement afin de voir o�
l'entreprise a la meilleure impl�mentation: grouper par les 2
premiers caract�res du code postal, et sommer les montants des
factures � l'int�rieur de chaque groupe;
  dans la base de donn�es Disc, quel est le nombre d' uvres de
chaque artiste: dans la table OEUVRES, grouper sur le champ
codeArtiste, et compter pour chaque groupe; �ventuellement faire
une jointure sur le fichier QUI.dbf pour conna�tre le nom, pas
seulement le code, des artistes;
 etc...

Mise en uvre

Il suffit de pr�ciser dans la requ�te:

Requ�tes de mise � jour

Une requ�te de mise � jour sert � modifier le contenu des tables. On

sp�cifie les enregistrements concern�s, les conditions �ventuelles, le(s)
champ(s) � modifier et la (les) valeur(s) de remplacement. On peut
utiliser les requ�tes avec variables pour les conditions.

La pr�sentation sera:

La valeur de remplacement peut �tre une expression qui contient le nom

d'un champ (entre crochets) quelconque (m�me le champ affect�: on
obtient alors une expression qui se comporte de la m�me fa�on que
l'expression a:=a+1 en Pascal).

Quand la requ�te est pr�te on peut utiliser:

  l'ic�ne feuille de donn�es pour visualiser les cellules qui seront
affect�es par le remplacement;
 l'ic�ne ex�cution (!) pour effectuer le remplacemen

Requ�tes mono-table

Requ�tes multi-tables
Requ�tes avec calculs
Requ�tes de mise � jour
A

Access:
Voir MicroSoft Access.
aide contextuelle:
Aide que fournit un logiciel et qui d�pend du contexte: l'aide
s'adapte � l'environnement.
analyse:
Partie de l'informatique qui traite de la fa�on d'obtenir les
renseignements pouvant mener � un cahier des charges (voir ce
mot) qui d�crive correctement le r�el � traiter. (Voir �galement
Merise.)
architecture en couche d'un SGBD:
 Description d'un SGBD par ses trois niveaux: conceptuel, externe
(ou logique) et interne (ou physique). Voir ces mots.
article:
Dans une table d'une base de donn�es, entit� qui correspond �
une fiche cartonn�e d'une base de donn�es non informatis�e. On
utilisera indiff�remment article ou fiche ou enregistrement.
Correspond au niveau logique (voir ce mot) � une entit� (voir ce
mot) du niveau conceptuel.
association:
Voir relation.
attribut:
Les entit�s ont des propri�t�s, appel�es attributs, chacun d'eux
prend une �valeur� parmi une vari�t� de valeurs possibles, le
domaine de l'attribut. L'ensemble des valeurs des attributs d'une
entit� caract�rise (compl�tement) l'entit� consid�r�e
relativement au SI (voir ce mot) dans lequel on se place. Une
propri�t� est une donn�e �l�mentaire que l'on per�oit sur une
entit� ou sur une relation. L'identification des attributs pertinents
des entit�s est une �tape cruciale dans la d�finition du mod�le
de donn�es.

base de donn�es:
Recueil d'informations en liaison avec un sujet donn�. Une base de
donn�es peut �tre informatis�e ou non.
BD:
Voir base de donn�es.
BIOS:
Basic Input Output System. Comme son nom l'indique, syst�me de
base g�rant les entr�es/sorties sur un ordinateur. C'est la couche
la plus basse du syst�me, en dessous du syst�me d'exploitation.

C
cahier des charges:
Description de ce que doit faire un logiciel. le cahier des charges
est r�alis� grace � l'analyse (voir ce mot) et pr�c�de la
programmation proprement dite.
cardinalit�:
Nombre d'�l�ments en relation. On parle de cardinalit�
maximale et de cardinalit� minimale.
champ:
Partie atomique d'un article (voir ce mot). Correspond
approximativement aux cases � remplir sur les fiches cartonn�es
d'une base de donn�es non informatis�e. (Voir �galement
prori�t�.)
cl�:
Propri�t� (ou groupe de propri�t�s) d'une entit� qui permet
d'identifier une occurrence (voir ce mot) de cette entit�.
conceptuel:
Pour l'architecture en couche d'un SGBD, on parlera de sch�ma
conceptuel ou de niveau conceptuel. Concerne le niveau le plus
�loign� de la machine. On n'y manipule que des concepts non
informatiques (ou si peu!).
contrainte d'int�grit�:
Contrainte que doit respecter une base de donn�es. On distingue:

 les contraintes de r�f�rence: il doit exister certains liens

entre certaines entit�s (par exemple un disque ne peut
exister que si le code l'artiste correspond bien � un artiste
existant);
 les contraintes de structure: les valeurs prises par certains
champs doivent satisfaire � certaines conditions (par exemple
la cl� doir �tre unique);
 les contraintes de domaine: les valeurs prises par les champs
doivent se trouver dans un ensemble bien d�limit�.
 D
 domaine:
 Ensemble des valeurs que peut prendre un attribut (voir ce mot)
d'une entit� (voir ce mot).
 donn�e:
 Information trait�e. (Voir aussi traitement.)
 E
 enregistrement:
 Voir article.
 entit�:
 Au niveau conceptuel, repr�sentation d'un objet mat�riel ou
immat�riel pourvu d'une existence propre. La notion d'entit� est
r�fractaire � toute d�finition formelle. Une entit� est une chose
(concr�te ou abstraite) qui existe et est distinguable des autres
entit�s. (Voir aussi article.)
 �tat:
 Outil permettant l'impression (voire la visualisation sur �cran) des
informations extraite de la base de donn�es, et ceci dans un format
agr�able.
 exportation:
 L'exportation de donn�es d'un logiciel A vers un logiciel B
consiste, alors qu'on se trouve dans logiciel A, � cr�er un fichier
dans le format de B � partir des donn�es de A. (Voir �galement
importation.)
 externe:
 Voir logique.
 F
 fiche:
 Voir article.
 fichier:
 Ensemble d'informations stock�es sur un syst�me de m�moire
de masse d'un ordinateur (disque, disquette, CD-ROM, bande,
cartes, etc.), formant un bloc, et accessible par son nom. C'est le
syst�me d'exploitation qui se charge de mettre en correspondance
le nom fourni par l'utilisateur et les donn�es stock�es sur le disque.
 formulaire:
 Outil permettant la consultation et la saisie (et dans un format si
possible agr�able) des informations d'une base de donn�es
 I
 identifiant:
 Voir cl�
 importation:
 L'importation de donn�es vers un logiciel A depuis un logiciel B
consiste, alors qu'on se trouve dans logiciel A, � lire un fichier dans
le format de B, pour en utiliser les donn�es dans A. (Voir
�galement exportation.)
 inconsistance:
 Quand une m�me information figure en deux endroits diff�rents,
avec deux valeurs diff�rentes. C'est la redondance (voir ce mot) qui
cr�e l'inconsistance des donn�es. Quand, par exemple, l'adresse
d'une personne figure en deux endroit diff�rents, il y a redondance;
si cette personne d�m�nage on risque de ne faire la correction
qu'en un seul endroit; on aura alors deucx adresses diff�rentes,
pour la m�me personne, sans possibilit� de savoir quelle est la
bonne: les donn�es seront alors inconsistantes.
 interne:
 Voir physique.
 L
 lien:
 Correspond dans le sch�ma logique (voir ce mot) � une
association ou une relation (voir ce mot) du sch�ma conceptuel
(voir ce mot).
 logique:
 Pour l'architecture en couche d'un SGBD, on parlera de sch�ma
logique ou de niveau logique. Concerne le niveau interm�diaire. On
commence � envisager le probl�me sous un angle informatique,
mais on ne se pr�occupe pas des solutions qui seront r�ellement
employ�es.
 M
 Merise:
 M�thode d'analyse (voir ce mot) cr��e en 1978, sous l'impulsion
du minist�re de l'industrie, par un groupement de 6 soci�t�s de
services et un centre de recherche informatique. Merise propose une
m�thode de conception et de d�veloppement de Syst�mes
d'Information (voir SI) compl�te, d�taill�e, en grande partie
formalis�e, qui garantit (en principe) une informatisation r�ussie.
 MicroSoft:
 Soci�t� am�ricaine cr��e par Bill Gates dont la principale
prodcution est la fabrication de logiciels: Access, Windows, Word,
etc.
 MicroSoft Access:
 L'un des produits de MicroSoft.
 normalisation:
 dans le cas d'un MCD, adapter ce MCD, cr�� d'apr�s la th�orie
de la m�thode, � la r�alit�. La normalisation est faite en g�n�ral
dans le but d'augmenter l'efficacit� et de r�duire l'espace occup�.
 n-uple:
 En math�matiques un n-uple est � l'ordre n ce qu'un couple est �
l'ordre 2. Par exemple est un 7-uple. On parle aussi
de tuple.
 O
 occurrence:
 Un exemplaire d'une entit� ou d'une relation.
 P
 physique:
 Pour l'architecture en couche d'un SGBD, on parlera de sch�ma
physique ou de niveau physique. Concerne le niveau le plus proche
de la machine.
 propri�t�:
 Voir attribut.
 R
  redondance:
 On parle de redondance lorsqu'une m�me information se trouve
en double exemplaire, ce qui entrine un risque d'inconsistance (voir
ce mot).
 relation:
 Une relation entre plusieurs occurences (d'entit�s diff�rentes ou
non) traduit l'existence de liens entre des entit�s. Ces liens peuvent
s'�tablir parfois au travers de formes particuli�res d'objets qui par
nature mettent en relation plusieurs entit�s. Une relation est une
association per�ue dans le r�el entre deux ou plusieurs entit�s.
Une relation est d�pourvue d'existence propre.
 requ�te:
 Outil permettant d'extraire des informations d'une base de
donn�es. On parle de requ�te mono-table lorsqu'elle ne concerne
qu'une seule table; on parle de requ�te multi-tables dans le cas
contraire.

SAI:
Syst�me Automatis� d'Information. Partie automatis�e du SI
(voit ce mot).
SI:
Syst�me d'Information. Un syst�me est un ensemble
d'�l�ments, mat�riels ou pas, en interaction entre eux,
transformant des �l�ments d'entr�e en �l�ments de sortie. On
peut, au sein de tels syt�mes, distinguer trois sous-syst�mes:

 Syst�me de pilotage: R�gulation, contr�le, d�cision,

d�finition d'objectifs.
 Syst�me op�rationnel (ou op�rant): R�alisation des actions.
 Syst�me d'information: Interface entre les deux pr�c�dents.
Compos� d'�l�ments divers (employ�s, ordinateurs,
r�gles...) il informe le syst�me de pilotage sur le
 fonctionnement du syst�me op�rant et renvoie � celui-ci
des directives.

Le SI est la m�moire de l'organisation.

SGBD:
Une BD est, en g�n�ral, cr��e pour �tre consult�e. Elle peut
�tre �galement mise � jour. Pour faciliter ces op�rations de
consultation et mise � jour, un outil logiciel est appr�ciable. Ces
logiciels sont appel�s SGBD (Syst�mes de Gestion de Base de
Donn�es). (Voir aussi base de donn�es.)
structure d'une table:
Description du format d'une table par la description de ses champs:
nom, type, longueur, etc. A rapprocher du masque repr�sent� par
une fiche cartonn�e non encore remplie.

table:
Repr�sentation d'une entit� (ou d'une relation) au niveu logique
du mod�le relationnel.
traitement:
Action effectu�e sur les donn�es d'une base de donn�es. Un
traitement produit en principe d'autres donn�es. (Voir aussi
donn�es.)
tuple:
Voir n-uple.

ANALYSE (Informatique)
Étape de la création d'un système d'information ou d'une application
logicielle au cours de laquelle on définit « ce que doit faire » le
système, avant de se préoccuper de la manière dont on va le
 réaliser techniquement. La phase d'analyse est suivie des phases de
conception, puis d'implémentation.

L'analyse informatique s'intégre dans un processus en quatre phases :

Étape Description Résultat

Cahier des charges,

Étude Étude de l'existant, mise
spécifications fonctionnelles
préalable en place de scénarii.
générales.

Analyse Spécifications fonctionnelles

Fonctionnelle Organisation détaillée. détaillées, préconisation de
Détaillée solutions.

Programmation, tests de Programmes, maquettes et

Réalisation
mise en œuvre. manuel utilisateur.

Compte rendu d'exploitation et

Maintenance Mise-à-jour.
dossiers de mise-à-jour.

ÉTUDE PRÉALABLE
Analyse de la situation actuelle. L'une des 4 phases essentielles
composant l'analyse informatique d'un projet.

L'Étude préalable permet de fournir un diagnostic et de rechercher les

solutions possibles. Elle doit estimer les besoins en termes de moyens à
mettre en ¶uvre. On en déduit globalement une solution nouvelle. Cette
phase doit répondre essentiellement aux deux questions suivantes :

1. Quoi faire ?
2. Avec quelles données ?
 L'Étude préalable doit élaborer une solution conceptuelle, indépendante
de tout moyen nécessaire à sa réalisation.

A.F.D.
Analyse Fonctionnelle Détaillée. L'une des 4 phases essentielles
composant l'analyse informatique d'un projet.

Plan de travail effectué par le programmeur au préalable à son

développement et devant être validé par la maîtrise d'ouvrage. Ce
document regroupe :

1. l'analyse de la demande formulée dans le cahier des charges,

2. la description du « comment » sera réalisé le programme,
3. l'expression des besoins en terme de ressources informatiques,
4. les suggestions de solutions lorsque plusieurs sont possibles (le
choix final n'appartenant pas au programmeur).

L'AFD affine la solution conceptuelle et définit la solution retenue par la

prise en compte des moyens de réalisation. Cette phase doit répondre aux
questions « Qui ? », « Où ? », « Quand ? » et « Comment ? » en tenant
compte des contraintes techniques qui doivent être justifiées.

L'ANALYSE ET SES METHODES

On a beaucoup dit et beaucoup écrit sur les méthodes informatiques. Il y

en a d'excellentes et d'autres qui sont plus complexes à mettre en oeuvre.
Toutes ont en commun le défaut d'être lourdes et difficiles à faire
fonctionner correctement. Il est vrai que de nombreuses méthodes
majorent les coûts et les délais sans contre-partie significative. Et si les
méthodes étaient beaucoup plus simples que ne laissaient croire les
promoteurs des méthodes. En effet, au lieu de compliquer les choses, il
est préférable de chercher à simplifier les choses en allant directement à
l'essentiel grâce à une approche pratique et concrète.
Je me souviens d'une pièce ou quatre policiers sont lancés à la poursuite
d'un dangereux malfaiteur. Pour qu'ils puissent le rattraper plus
facilement, leur chef met à leur disposition une voiture. Mais avant de les
autoriser à prendre le volant, il juge indispensable de leur faire assimiler
au préalable la théorie du moteur à explosion.

Cette scène me revient souvent en mémoire lorsque je lis des exposés sur
telle ou telle méthode d'analyse informatique. Car avant d'aborder le
sujet, l'auteur se lance neuf fois sur dix dans de longs développements,
bourrés de symboles et de locutions ésotériques, sur la modélisation de
l'entreprise, les systèmes décisionnels et autres schémas conceptuels. A
croire qu'il veut me démontrer à toute force l'universalité de sa méthode.

"VOUS SAVEZ, MOI, LES METHODES"

Ce niveau de généralité n'est-il pas bien éloigné de ce que doivent être

nos préoccupations de tous les jours ? Je suis un informaticien de terrain et
je n'ai que faire de la notion abstraite de système universel. J'opère dans
une entreprise précise, souvent même dans une partie seulement de cette
entreprise, qui est différente de toutes celles qui l'entourent.

Une autre caractéristique de ces ouvrages, c'est leur intolérance. On nous

prévient généralement dès le départ : hors de la méthode, point de salut !
Si on sort de la théorie pour aller voir sur place comment les choses se
passent, la vision est totalement différente. Dans de nombreux cas, les
systèmes en fonctionnement semblent avoir été étudiés et réalisés
essentiellement au fur et à mesure des demandes, sans méthode précise,
au hasard des connaissances et des habitudes des uns et des autres.
Lorsqu'on intéroge un analyste, il a tendance à répondre par un discours
du genre :

"Je ne suis dans cette entreprise que depuis quelques mois. Mon chef de
service voudrait que j'applique la méthode Merise. Mais dans l'entreprise
où j'étais auparavant, on ne jurait que par PacBase. Il est probable que ce
sera encore une autre qu'on voudra m'apprendre lorsque j'aurai encore
changé d'entreprise. A quoi bon faire des efforts que, compte tenu de mon
turn-over, je suis à peu près sûr de ne jamais amortir ?"

Que penser de tout cela ? En d'autres termes, faut-il avoir ou non une
méthode, et dans l'affirmative, laquelle choisir ?

EN AVOIR OU PAS

L'application d'une méthode supprime les astuces et les raccourcis. Les

études sont plus complètes et plus solides, mais elles durent en général
plus longtemps. Il y a aussi l'important travail de documentation. Bien sûr,
cette documentation sera utile plus tard, et contribuera à faciliter la
maintenance et à prolonger la durée de vie de l'application. Mais, en
attendant, il faut la rédiger, et cela prend beaucoup de temps.

"Des observations portant sur plus d'une centaine de grandes entreprises,

aux Etats-Unis et en Europe, montrent malheureusement que le manuel
des standards et procédures concernant le logiciel contient environ 500
pages et qu'il retarde en moyenne de plus de trois ans sur l'état de l'art le
plus récent."

Certes, une méthode est indispensable pour arriver au but, de même

qu'un certain niveau de documentation. Mais il ne faut pas que méthode
et documentation cessent d'être des moyens pour se transformer en buts.

LA MAQUETTE

Entre la nécessité d'une méthode et l'impossibilité d'y consacrer trop de

temps, la solution consiste-t-elle à faire vite et mal ? Je ne le pense pas,
car il me paraît possible de faire vite et bien. Plus exactement, il n'est pas
nécessaire d'attendre d'avoir tout étudié dans le détail pour lancer la
réalisation. Il y a un minimum de choses à définir avant de commencer à
bâtir un système. Mais ce minimum de choses peut s'obtenir très
rapidement, car il s'agit en somme de définir l'ossature du système. La
suite de l'étude, qui consiste à habiller cette ossature, peut se dérouler en
grande partie en même temps que les travaux de contruction.
IL FAUT ETRE GENTIL AVEC LES UTILISATEURS

Une fois venu le moment d'aborder la recherche d'une solution. Ici, la

culture informatique va servir, à condition de n'en pas faire état auprès
des utilisateurs. Si nous voulons vraiment les aider, il nous faut laisser aux
charlatans (qui abondent comme on le sait dans la profession des
informaticiens) l'usage du jargon. Les mots de tous les jours permettront
de mieux se comprendre, et d'entretenir un dialogue sans lequel on risque
de manquer la cible.

Au lieu donc de parler de schéma conceptuel, de règles de gestion,

d'ensembles entités-relations, de troisième forme normale, etc. dressons
la liste des objets à gérer : des clients, des produits, des commandes...
ensuite procurons-nous des spécimens de bons de commandes pour en
repérer l'architecture : ont-ils une seule ligne ou plusieurs ? Les produits
sont-ils désignés par un simple numéro de code ou par une description
plus ou moins longue ? Des codes sont-ils attribués systématiquement à
tous les clients ou seulement à quelques-uns ? etc. Acec ce genre de
démarche, l'architecture de l'application se dégage rapidement.

"Ce que l'on conçoit bien ....". Le vers célèbre s'applique parfaitement à
l'informatique qui n'était pourtant pas encore inventée du temps de
Boileau.

ALLER A L'ESSENTIEL

Comme on le voit, la démarche est simple. Il suffit de veiller à avoir

quelques idées claires et de chercher à dégager un schéma d'ensemble
qui met en évidence l'essentiel. C'est ça la vraie méthode. Tout le reste
n'est que littérature et bavardage.

Nous obtenons ainsi progressivement le schéma de la base de données de

l'application. Cependant, nous ne sommes pas encore au bout de nos
peines, car il reste à définir la logique des traitements. C'est une opération
difficile, surtout si l'on veut respecter les règles de la conception
structurée, c'est à dire construire des modules à forte cohésion interne et
aussi faiblement couplés que possible entre eux. Mais si on adopte la
démarche déscendante, on pourra démarrer la programmation et les
essais des modules supérieurs avant d'avoir achevé la mise au point des
modules situés plus bas dans la hiérarchie.

L'important est donc de conduire les travaux d'analyse, de conception et

de programmation selon une démarche logique. Peu importe au fond si
cette démarche relève de la méthode de Paul ou de celle de Jacques.

Trop souvent les méthodes informatiques aboutissent à compliquer un

problème facile. Il faut en fait avoir la démarche inverse et chercher à
rendre moins complexes des choses qui ne sont pas toujours simples.

Définition ANALYSE :

ANALYSE : Réduction d?un élément complexe en une multiplicité d?

éléments simples.