Vous êtes sur la page 1sur 30

Chapitre 1

De lanalyse aux bases de donnes


1.1 Quest-ce quune base de donnes ?
Il est assez difcile de dnir ce quest une base de donnes ; on dira trivialement que tout systme dinformation peut tre quali de base de donnes. Il semble plus facile de dnir loutil principal de gestion dune base de donnes qui est le systme de gestion de bases de donnes (SGBD)1 : cest un outil permettant dinsrer, de modier et de rechercher efcacement des donnes spciques dans un grand nombre dinformations ; cest une interface entre les utilisateurs et la mmoire secondaire qui facilite le travail des utilisateurs en leur donnant lillusion que toute linformation est comme ils la souhaitent. Chacun doit avoir limpression quil est seul utiliser linformation. Le SGBD est compos de trois couches successives (voir la gure 1.1) : Le systme de gestion de chiers. Il gre le stockage physique de linformation. Il est dpendant du matriel utilis (type de support, facteur de blocage, etc.). Le SGBD interne. Il organise le placement et lassemblage des donnes, gre les liens et laccs rapide. Le SGBD externe. Il se charge de la prsentation et de la manipulation des donnes aux concepteurs
1

Ce qui se traduit en anglais par DBMS : DataBase Management System.

Chapitre 1 De lanalyse aux bases de donnes

et utilisateurs. Il gre les langages de requtes labors et les outils de prsentation, tels que les tats et formulaires.

Figure 1.1 Le modle 3 couches

1.2 Objectifs et avantages


Un systme dinformation peut toujours tre ralis sans outil spcique. On peut alors se demander quels sont les objectifs et avantages de lapproche SGBD, compars ceux des chiers classiques. La rponse tient en neuf points : 1. Indpendance physique. Les disques, la machine, les mthodes daccs, les modes de placement, les mthodes de tri, le codage des donnes ne sont pas apparents. Le SGBD offre une structure canonique permettant la reprsentation des donnes relles sans se soucier de laspect matriel du systme. 2. Indpendance logique. Chaque groupe de travail doit pouvoir se concentrer sur ce qui lintresse uniquement. Il doit pouvoir arranger les donnes comme il le souhaite, mme si dautres utilisateurs ont une vue diffrente. Ladministrateur doit pouvoir faire voluer le systme dinformation sans remettre en cause lorganisation de chaque groupe de travail. Exemple. Une base de donnes contient les informations suivantes :
vhicule(num-vhicule, marque, type, couleur) e e personne(num-ss, nom, prnom) e propritaire(num-ss, num-vhicule, date-achat). e e

Objectifs et avantages

Un groupe de travail ne sintressera quaux individus qui possdent une voiture :


individus(num-ss, nom, prnom, num-vhicule). e e

Un autre groupe ne sintressera quaux vhicules vendus une certaine date :


voiture(num-vhicule, type, marque, date-achat). e

3. Manipulation possible par des non-informaticiens. Le SGBD doit permettre dobtenir les donnes par des langages non procduraux. On doit pouvoir dcrire ce que lon souhaite sans dcrire comment lobtenir. 4. Accs efcace aux donnes. Les accs disque sont lents relativement laccs la mmoire centrale. Il faut donc offrir les meilleurs algorithmes de recherche de donnes lutilisateur. Remarque. Le systme de gestion des chiers y rpond parfois pour des monochiers (ISAM, VSAM, etc.). Mais dans le cas dintercroisements entre diffrents chiers, cela devient beaucoup plus complexe et parfois mme contextuel la recherche effectue. 5. Administration centralise des donnes. Le SGBD doit offrir, aux administrateurs des donnes, des outils de vrication de cohrence des donnes, de restructuration ventuelle de la base, de sauvegarde ou de rplication. Ladministration est centralise et est rserve un trs petit groupe de personnes pour des raisons videntes de scurit. 6. Non-redondance des donnes. Le SGBD doit permettre dviter la duplication dinformations qui, outre la perte de place mmoire, demande des moyens humains importants pour saisir et maintenir jour plusieurs fois les mmes donnes. 7. Cohrence des donnes. Cette cohrence est obtenue par la vrication des contraintes dintgrit. Une contrainte dintgrit est une contrainte sur les donnes de la base, qui doit toujours tre vrie pour assurer la cohrence de cette base. Les systmes dinformation sont souvent remplis de telles contraintes ; le SGBD doit permettre une gestion automatique de ces contraintes dintgrit sur les donnes. Par exemple : un identiant doit toujours tre saisi ; le salaire doit tre compris entre 4 000 F et 100 000 F ; le nombre de commandes du client doit correspondre au nombre de commandes dans la base ; lemprunteur dun livre doit tre un abonn du club. Dans un SGBD, les contraintes dintgrit doivent pouvoir tre exprimes et gres dans la base, et non dans les applications.

Chapitre 1 De lanalyse aux bases de donnes

8. Concurrence daccs aux donnes. Le SGBD doit permettre plusieurs personnes (ou applications) daccder simultanment aux donnes tout en conservant lintgrit de la base. Chacun doit avoir limpression quil est seul utiliser les donnes. 9. Scurit des donnes. Les donnes doivent tre protges des accs non autoriss ou mal intentionns. Il doit exister des mcanismes permettant dautoriser, contrler et enlever des droits daccs certaines informations nimporte quel usager. Par exemple, un chef de service pourra connatre les salaires des personnes quil dirige, mais pas de toute lentreprise. Le systme doit aussi tolrer les pannes : si une coupure de courant survient pendant lexcution dune opration sur la base, le SGBD doit tre capable de revenir un tat dans lequel les donnes sont cohrentes. Il en va de mme en cas dchec dans un programme. L aussi, le SGBD doit pouvoir revenir un tat cohrent, ce qui est rendu possible par la gestion des transactions. Remarque. Ces neuf points, caractrisant assez bien ce quest une base de donnes, sont rarement runis dans les SGBD actuels. Ils dtaillent les caractristiques pour obtenir un SGBD parfait.

1.3 Diffrents types de bases de donnes


Il existe actuellement cinq grands types de bases de donnes : Les bases hirarchiques. Ce sont les premiers SGBD apparus (notamment avec IMS dIBM). Elles font partie des bases navigationnelles constitues dune gestion de pointeurs entre les enregistrements. Le schma de la base doit tre arborescent. Les bases rseaux. Sans doute les bases les plus rapides, elles ont trs vite supplant les bases hirarchiques dans les annes soixante-dix (notamment avec IDS II de Bull). Ce sont aussi des bases navigationnelles qui grent des pointeurs entre les enregistrements. Cette fois-ci, le schma de la base est beaucoup plus ouvert. Les bases relationnelles. lheure actuelle, ce sont les plus utilises. Les donnes y sont reprsentes en tables (voir la gure 1.2). Elles sont bases sur lalgbre relationnelle et un langage dclaratif (gnralement SQL). Les bases dductives. Les donnes y sont aussi reprsentes en tables (prdicats), le langage dinterrogation se base sur le calcul des prdicats et la logique du premier ordre.

Quelques systmes reconnus

Les bases objet. Les donnes y sont reprsentes en tant quinstances de classes hirarchises. Chaque champ est un objet. De ce fait, chaque donne est active et possde ses propres mthodes dinterrogation et daffectation. Lhritage est utilis comme mcanisme de factorisation de la connaissance. La rpartition du parc des SGBD nest pas quitable entre ces cinq types de base : 75 % sont relationnels, 20 % rseaux, les 5 % restants tant partags entre bases dductives et objets. Ces chiffres risquent nanmoins dvoluer dici quelques annes, et la frontire entre bases relationnelles et objets pourrait tre limine par lintroduction dune couche objets sur les bases relationnelles.

Figure 1.2 Une base Access

1.4 Quelques systmes reconnus


Oracle (http://www.oracle.com), base relationnelle. DB2 (http://www.software.ibm.com), base relationnelle. Sybase (http://www.sybase.com), base relationnelle. SQL Server (http://www.microsoft.com), base relationnelle. Ingres (ftp://s2k-ftp.CS.Berkeley.EDU/pub/ingres/), base relationnelle. Informix (http://www.informix.com), base relationnelle. O2 (http://www.o2tech.fr ou http://www.ardentsoftware.com), base objet. Gemstone (http://www.gemstone.com), base objet. ObjectStore (http://www.objectdesign.com ou http://www.odi.com), base objet. Jasmine (http://cai.com/jasmine), base objet.

10

Chapitre 1 De lanalyse aux bases de donnes

et sur micro : Access 2000 (http://www.microsoft.com), Paradox 8.0 (http://www.corel.com), Visual Dbase (http://www.borland.com), FoxPro (http://www.microsoft.com), FileMaker 4.0 (http://www.claris.fr), 4D 6.5 (http://www.aci.fr), Windev (http://www.pcsoft.fr). Il existe aussi quelques freewares et sharewares que lon peut trouver sur Internet pour sinitier aux bases de donnes relationnelles comme : MySQL (http://www.mysql.net ou http://www.mysql.com) ; MSQL (http://Hughes.com.au/) ; Postgres (http://www.postgresql.org) ; InstantDB (http://www.instantdb.co.uk) qui est entirement crit en Java.

1.5 Les niveaux ANSI/SPARC


Pour assurer les objectifs prcdemment dcrits, les trois niveaux suivants de description (voir la gure 1.3) ont t distingus par le groupe ANSI/X3/SPARC en 1975 : Le niveau conceptuel. Il correspond ce que lon retrouve dans la mthode Merise avec les modles de donnes (MCD2 , MLD3 ). Le niveau interne. Il correspond la structure de stockage des donnes : types de chiers utiliss, caractristiques des enregistrements (longueur, composants), chemins daccs aux donnes (types dindex, chanages, etc.). Le niveau externe. Il est caractris par lensemble des vues externes quont les groupes dutilisateurs. Ces trois niveaux correspondent trois mtiers bien prcis de lentreprise. Le concepteur de SGBD soccupe principalement du schma interne. Il travaille sur les structures de donnes de base, loptimisation des techniques daccs aux donnes4 et les dispositifs
2 3 4

Modle conceptuel de donnes. Modle logique de donnes. Techniques de hachage.

Modliser les donnes

11

modles externes

modle externe

modle externe

modle externe

Schma conceptuel

Schma interne

Figure 1.3 Le modle Ansi/Sparc doptimisation de requtes. Ladministrateur de bases de donnes conoit les bases, organise les tables, optimise les requtes5 et gre les droits daccs. Enn les dveloppeurs et utilisateurs crivent les programmes applicatifs et utilisent les outils de haut niveau du SGBD permettant une abstraction logique sur les donnes6 .

1.6 Modliser les donnes


Avant de sattaquer tout problme, il est toujours ncessaire de rflchir profondment aux tenants et aboutissants de ce que lon veut raliser. La phase de conception ncessite souvent de nombreux choix qui auront parfois des rpercussions importantes par la suite. La conception des bases de donnes ne fait pas exception la rgle. Les thoriciens de linformation ont donc propos des mthodes permettant de structurer un projet et de prsenter de manire abstraite le travail que lon souhaite raliser. Ces mthodes ont donn naissance une discipline, lanalyse, et un mtier, lanalyste. Lanalyse est la discipline qui tudie et prsente abstraitement le travail effectuer. La phase danalyse est trs importante puisque cest elle qui sera valide par les utilisateurs avant la mise en uvre du systme concret. Il existe de nombreuses mthodes danalyse (AXIAL, OMT, etc.), la plus utilise en France tant la mthode Merise. Merise spare les donnes et les traitements effectuer avec le systme dinformation en diffrents modles conceptuels et physiques. Le plus intressant pour la conception dune base de donnes est le MCD.
5 6

Notamment en dnissant des index. Notamment les vues.

12

Chapitre 1 De lanalyse aux bases de donnes

Le MCD (modle conceptuel de donnes) est un modle abstrait de la mthode Merise permettant de reprsenter linformation dune manire comprhensible aux diffrents services de lentreprise. Il permet une description statique du systme dinformation laide dentits et dassociations. Le travail de cration dune base de donnes par le concepteur commence juste aprs celui des analystes qui ont tabli le MCD. Commenons par quelques dnitions propres au MCD. La proprit est une donne lmentaire et indcomposable du systme dinformation, par exemple, une date de dbut de projet, la couleur dune voiture, une note dtudiant. Lentit est la reprsentation, dans le systme dinformation, dun objet matriel ou immatriel ayant une existence propre et conforme aux choix de gestion de lentreprise (voir la gure 1.4). Lentit est compose de proprits. Par exemple, une personne, une voiture, un client, un projet sont en gnral des entits.
nom de l'entit . . . liste des proprits . . .

Figure 1.4 Reprsentation graphique dune entit Lassociation traduit dans le systme dinformation le fait quil existe un lien entre diffrentes entits. Le nombre dintervenants dans cette association caractrise sa dimension : rflexive sur une mme entit ; binaire entre deux entits ; ternaire entre trois entits ; n-aire entre n entits.
Personne
. . .

Service Travaille dans un


. . .

Figure 1.5 Reprsentation graphique dune association

Modliser les donnes

13

Les gures 1.5, 1.7 et 1.8 prsentent des exemples typiques de ces diffrentes associations. Des proprits peuvent tre attaches aux associations. Par exemple, un employ peut passer 25 % de son temps dans un service, et 75 % de son temps dans un autre. Lassociation travaille dans qui relie une personne un service portera dans ce cas la proprit volume de temps pass (voir la gure 1.6). Les cardinalits caractrisent le lien entre une entit et une association. La cardinalit dune association est constitue dune borne minimale et dune borne maximale : minimale : nombre minimal de fois quune occurrence dune entit participe aux occurrences de lassociation, gnralement 0 ou 1 ; maximale : nombre maximal de fois quune occurrence dune entit participe aux occurrences de lassociation, gnralement 1 ou n. Les cardinalits maximales sont ncessaires pour la cration de la base de donnes. Les cardinalits minimales sont ncessaires pour exprimer les contraintes dintgrit.

. . .

. . .

Figure 1.6 Reprsentation des cardinalits De la gure 1.6, on dduit qu une personne peut travailler dans un ou plusieurs services . On constate de plus que, dans chaque service, il y a au moins une personne mais il peut y en avoir plusieurs . Enn, une mesure du volume de travail est stocke pour chaque personne travaillant dans un service donn. Remarque. Il existe une notation des cardinalits lamricaine dans laquelle on ne note que les cardinalits maximales. Il peut donc y avoir deux sortes de cardinalits amricaines : (1 : n) et (n : m). Dans la gure 1.6, la notation amricaine serait n : m, puisquune personne peut travailler dans plusieurs services et que, dans un service, il peut y avoir plusieurs personnes. Un lien hirarchique est un lien 1 : n en notation amricaine. Un lien maill est un lien n : m en notation amricaine.

14

Chapitre 1 De lanalyse aux bases de donnes

Matriel NumMat . . . 0,n est compos de 0,n

Figure 1.7 Lien rexif typique


Avion NumAvion . . . Pilote NumPilote . . .

0,n

0,n

Vol

0,n Ligne NumLigne . . .

Figure 1.8 Lien ternaire typique Nous verrons par la suite que seules les cardinalits maximales permettent de dterminer le nombre de tables ncessaires. Les cardinalits minimales servent exprimer certaines contraintes dintgrit mais ne modient en aucun cas la structure des tables de la base. Identiant. Lidentiant dune entit est constitu dune ou plusieurs proprits de lentit de sorte que, chaque valeur de lidentiant, corresponde une et une seule occurrence de lentit. Lidentiant dune association est constitu de la runion des identiants des entits qui participent lassociation. La gure 1.7 reprsente lentit Matriel dont lidentiant est le numro de matriel. Cet exemple illustre de plus un lien rflexif dune entit sur elle-mme : un matriel peut tre constitu dun ou plusieurs autres matriels et vice-versa. La gure 1.8 reprsente les entits Avion, Pilote et Ligne, relies par lassociation ternaire dnissant le vol. Un vol est ici caractris par un numro davion x, un

Exemple de MCD

15

numro de pilote x et un numro de ligne x. Il en rsulte quun pilote peut voler avec le mme avion sur plusieurs lignes et quun pilote peut voler avec des avions diffrents sur une mme ligne. Lidentiant est reprsent en soulign dans le MCD. Il constituera par la suite la cl dune table relationnelle. La conception dun MCD avec de nombreuses entits est parfois une tche ardue et ncessite un savoir-faire que seuls les analystes professionels peuvent acqurir par lexprience. La gestion des dates, par exemple, est souvent dlicate. Dans le MCD, gure 1.9, la relation entre Salari et Tche est constitue dun lien maill dont les dates sont de simples proprits. Il en rsulte quun salari ne pourra participer plusieurs fois la mme tche ! En effet, la cl de la table correspondant lassociation sera constitue du couple (numro de salari, numro de tche) qui devra donc tre unique. Dans de nombreux MCD, on est souvent oblig de crer une entit Date ds quune date doit faire partie dune cl, et bien que lon ne traduise jamais cette entit par une table. Prcisons, enn, quil est toujours difcile de dissocier les donnes des traitements qui seront effectus. Le MCD est donc en gnral associ un MCT (modle conceptuel de traitements). Souvent, on modie le MCD, ou directement le MLD, pour amliorer les traitements. Cest pourquoi, dans lexemple prcdent, on ne cre pas une table pour les dates. Pendant la conception, on ne traite que les cas normaux , puis on vrie et modie, si besoin, les modles en fonction des cas exceptionnels !

1.7 Exemple de MCD


Le modle conceptuel de donnes, gure 1.9, dcrit le systme dinformation dune petite socit de services. Cette socit ralise des projets commands par ses clients. Les projets sont composs de plusieurs tches qui seront ralises par les salaris de lentreprise. Chaque tche a un cot qui lui est propre. Plusieurs salaris peuvent participer une mme tche et, bien sr, une tche est en gnral ralise par plusieurs salaris. En gnral, les salaris sont affects une tche pour une dure, dtermine par une date de dbut et de n. On considre quun salari ne peut participer quune seule fois une tche donne. Pour effectuer son travail, il utilise diffrents matriels rfrencs par lentreprise. Un matriel peut tre compos de plusieurs autres matriels de lentreprise. Un projet est toujours coordonn par un chef de projet, salari de lentreprise. Un chef de projet encadre donc dautres salaris. Le personnel est obligatoirement rattach une seule des divisions de lentreprise mais peut, en revanche, tre regroup dans diffrentes quipes de lentreprise.

16

Chapitre 1 De lanalyse aux bases de donnes

Figure 1.9 Exemple de MCD On le voit, le MCD ncessaire cette petite entreprise contient des liens hirarchiques comme travaille, des liens maills comme regroupe, des liens rflexifs comme encadre ou compose.

1.8 Le modle relationnel


Les systmes de gestion de bases de donnes relationnelles organisent les donnes en tables ( la manire dun tableur). Il est simple, facile comprendre et dle un cadre mathmatique (lalgbre relationnelle). Le concept mathmatique sous-jacent est celui de relation de la thorie des ensembles, qui se dnit comme un sousensemble du produit cartsien de plusieurs domaines. Un domaine est un ensemble ni ou inni de valeurs possibles : le domaine des entiers, le domaine des boolens, le domaine des couleurs du drapeau franais {bleu, blanc, rouge}, etc. On utilise alors le produit cartsien dun ensemble de domaines pour dnir un ensemble de n-uplets.

Le modle relationnel

17

Le produit cartsien dun ensemble de domaines D1 , D2 , . . . , Dn que lon crit D1 D2 . . . Dn est lensemble des n-uplets (ou tuples) < V1 , V2 , . . . , Vn > tel que Vi Di . Exemple. Le produit cartsien des domaines D1 = {durand, lefebvre, martin} et D2 = {christian, franck} donne : durand durand lefebvre lefebvre martin martin christian franck christian franck christian franck

Le produit cartsien est une opration plus gnrale que la simple application des domaines. On peut par exemple lappliquer aussi des ensembles de tuples, ce que nous ferons en algbre relationnelle. Une table relationnelle7 est un sous-ensemble du produit cartsien dune liste de domaines. Elle est gnralement caractrise par un nom permettant de lidentier clairement. Personne D1 D2 lefebvre christian martin franck durand franck An de rendre lordre des colonnes sans importance tout en permettant plusieurs colonnes de mme domaine, on associe un nom chaque colonne. Les diffrentes colonnes dune table constituent ce que lon appelle les attributs de la table relationnelle (voir les gures 1.16 et 1.10). Remarque. Comme pour toute dnition densembles, il existe en fait deux possibilits pour dnir une relation, en intention ou en extension. La forme intentionnelle est utilise dans les bases de donnes dductives, par exemple {(x, y, z ) (N, Z, Q) tels que x + y > z }, mais pas dans les bases relationnelles ni objet. La forme extensionnelle qui consiste spcier un un tous les tuples de la relation est la seule forme utilisable dans les bases de donnes relationnelles. Elle est bien sr utilise aussi dans tous les autres types de base.
7

On dira parfois uniquement table ou relation selon le contexte.

18

Chapitre 1 De lanalyse aux bases de donnes

Le schma dune table relationnelle est constitu de lensemble des attributs de la table. Par extension, le schma de la base de donnes est constitu de lensemble de toutes les tables. Une base de donnes relationnelle est une base de donnes dont le schma est un ensemble de schmas de tables relationnelles et dont les occurrences sont des tuples de ces tables.

1.9 Exemple dune base de donnes relationnelle


titre dexemple, voici une base de donnes relationnelle rudimentaire, utilisant trois tables reprsentant les commandes de produits des fournisseurs. Cet exemple sera utilis de nombreuses fois par la suite pour illustrer lcriture de requtes. produits pno 101 102 103 104 105 106 107 108 design fauteuil fauteuil bureau bureau armoire caisson caisson classeur prix poids couleur 2 000 7 gris 1 500 9 rouge 3 500 30 vert 4 000 40 gris 2 500 35 rouge 1 000 12 gris 1 000 12 jaune 1 500 20 bleu

fournisseurs fno nom adresse ville 10 Dupont Lille 11 Martin Amiens 12 Jacquet Lyon 13 Durand Lyon 14 Martin Nice 15 Durand Lille 16 Dupont Paris 17 Lefebvre Lille 19 Maurice Paris

10 Passage du MCD aux tables relationnelles

19

commandes cno fno pno qute 1 001 17 103 10 1 003 15 103 2 1 005 17 102 1 1 007 15 108 1 1 011 19 107 12 1 013 13 107 5 1 017 19 105 3 1 019 14 103 10 1 023 10 102 8 1 029 17 108 15 Le schma de cette base est donc (voir la gure 1.15) :
produits(pno, design, prix, poids, couleur) fournisseurs(fno, nom, adresse, ville) commandes(cno, fno, pno, qute)

Figure 1.10 Visualisation dune table Access

1.10 Passage du MCD aux tables relationnelles


Une fois le MCD crit par les analystes, le travail du concepteur de bases de donnes consiste traduire ce modle en un modle plus proche du SGBD utilis : le MLD (modle logique de donnes). Dans le MLD relationnel, lunique type dobjet existant est la table. La mthode de passage dun MCD Merise aux tables relationnelles est simple et systmatique : Traitement des entits : chaque entit devient une table ; chaque proprit dune entit devient une colonne de cette table ; lidentiant dune entit devient la cl primaire de la table correspondante (cration dun index).

20

Chapitre 1 De lanalyse aux bases de donnes

Traitement des associations : une association (0,n)(0,1) (lien hirarchique) provoque la migration dune cl trangre (lidentiant ct 0,n) vers la table de lentit ct (0,1). Si des proprits taient sur lassociation, elles migreraient ct (0,1) (voir les gures 1.11 et 1.12) ;

Figure 1.11 MCD avec lien hirarchique


Table 1 A B C E Table 2 C D

Figure 1.12 MLD correspondant la gure 1.11 une association (0, n) (0, n) (lien maill) donne naissance une nouvelle table. Les identiants des entits auxquelles lassociation est relie migrent dans cette table. La cl primaire de cette nouvelle table est constitue de la runion de ces identiants. Si des proprits taient portes par lassociation, elles migreraient dans la nouvelle table aussi ct (0,1) (voir les gures 1.13 et 1.14) ; les associations n-aires sont gres, comme prcdemment, avec la naissance dune nouvelle table. Les schmas du MLD contiennent gnralement des flches indiquant les reports de cl (cls trangres). Ces flches sont prsentes titre informatif. En aucun cas, ces flches ne correspondent un pointeur physique. Les tables relationnelles sont toutes physiquement indpendantes.

10 Passage du MCD aux tables relationnelles

21

Figure 1.13 MCD avec lien maill


Table 1 A B Table 3 A C E Table 2 C D

Figure 1.14 MLD correspondant la gure 1.13

Figure 1.15 MCD Fournisseur-Produits-Commandes Dans le cas Fournisseur-Produits-Commandes (voir la gure 1.15), lassociation Commandes est un lien maill porteur dune proprit. Il y a donc cration dune table Commandes avec report des cls des entits lies, ce qui nous donne bien les trois tables vues prcdemment8 . Rappel : seules les cardinalits maximales servent dnir le nombre de tables et les reports de cls. Les cardinalits minimales ne servent qu prciser par la suite si les colonnes peuvent prendre la valeur NULL ou pas.

Le lecteur averti notera que, dans ce schma, il nest pas possible de passer deux commandes diffrentes au mme fournisseur. Pour rsoudre ce problme, il aurait fallu transformer la relation Commandes en une entit Commandes.

22

Chapitre 1 De lanalyse aux bases de donnes

Si lon reprend le MCD de notre mini-entreprise de la page 15, on obtient les onze tables suivantes : partir des entits Division quipe Client Matriel Salari Projet Tche partir des associations Regroupe Participe Compose Utilise

Figure 1.16 Structure dune table sous Access

1.11 Exercices
1. tablir le MCD dun systme dinformation permettant la gestion dune discothque. On prendra notamment en compte les morceaux, interprtes, auteurs, disques, passages, genres, etc. 2. tablir le MCD dun systme dinformation permettant la gestion dun aroport. On prendra notamment en compte les avions, compagnies, pilotes, personnel de bord, vols, horaires, clients, rservations, etc. 3. tablir le MCD dun systme dinformation permettant la gestion des comptes bancaires. On prendra notamment en compte les clients, types de comptes, comptes, critures, chanciers, etc. 4. tablir le MCD dun systme dinformation permettant la gestion dune prison. On prendra notamment en compte les gardiens, prisonniers, cellules, quartiers, rondes, etc.

11 Exercices

23

5. tablir le MCD dun systme dinformation permettant la gestion des notes dun tablissement scolaire. On prendra notamment en compte les formations, matires, enseignants, tudiants, types de cours, notes, moyennes, etc. 6. tablir le MCD et les traitements ncessaires la gestion dun tournoi de tennis. On prendra comme hypothse simplicatrice que le nombre de joueurs est une puissance de 2 et quil ny a aucun rattrapage (une solution ce problme est prsente dans ce livre). 7. tablir le MCD de gestion dun SGBD, ce qui est communment appel la mtabase. Cet exercice difcile ncessite de connatre les objets principaux dun SGBD : colonnes, tables, requtes, index, droits, vues (une solution ce problme est prsente dans ce livre). Chaque exercice peut tre trait diffrents niveaux plus ou moins complexes selon les choix que vous effectuez. Plus le nombre dobjets pris en compte est important, plus la solution est complte. Contentez-vous dune solution simple au dpart, puis tendezla avec des notions plus complexes. Dans chaque cas, vous dtaillerez les entits avec leurs proprits et les cls primaires, les associations avec les cardinalits. Si des choix se prsentent, vous prciserez loption choisie en la justiant. Vous dessinerez le MCD, puis fournirez le MLD correspondant.

Chapitre 2

Prsentation des donnes


Une fois la base et les tables cres, il faut les exploiter. Lutilisateur nal aura besoin de visualiser et de saisir des donnes, deffectuer des calculs et dimprimer des rsultats. La rponse ces diffrents problmes de prsentation des donnes est fournie par les formulaires destins tre afchs lcran et les tats destins tre imprims. Ce sont les formulaires et tats qui forment la partie visible dune base de donnes. Si le concepteur cre, remplit et administre les tables, lutilisateur, lui, ne sera en contact quavec les formulaires et tats. Il lui faudra donc des prsentations agrables, la prsence du logo de lentreprise et de laide la manipulation du logiciel. Cest de ses formulaires et de ses tats quune application tire son ergonomie. Cest dire leur importance. Il ny a en gnral rien de trs technique dans leur conception. Nanmoins, lergonomie dun formulaire ou dun tat est capitale pour une application. Cest en gnral la seule partie que lutilisateur nal considrera ! Tout le travail fait en amont peut tre refus par les utilisateurs si les formulaires sont pnibles utiliser. On ne le rptera jamais assez : linformaticien nest pas dans lentreprise pour se faire plaisir, mais pour faire plaisir aux utilisateurs. La cration de formulaires et tats nest malheureusement pas normalise, et chaque SGBD fournit ses propres outils plus ou moins ergonomiques. Oracle fournit SQLForms ou Developper 2000. Access et Windev fournissent des outils intgrs. De plus, les logiciels comme Access ou Windev fournissent des assistants qui gnrent automatiquement des formulaires et des tats sans que le concepteur nait connatre quoi que ce soit en programmation. Bien que lutilisation dassistants soit un avantage

26

Chapitre 2 Prsentation des donnes

indniable, ils restent dun usage limit et il faut souvent les retoucher an dobtenir lergonomie souhaite. Il nen reste pas moins quun certain nombre de points fondamentaux sont dtailler pour bien comprendre la cration de formulaires et dtats.

2.1 Les formulaires


Un accs aux tables1 offre la possibilit de voir plusieurs enregistrements simultanment et de les modier directement. Malheureusement, si la table contient de nombreuses colonnes, il faut faire dler les colonnes pour visualiser un enregistrement en entier. De plus, on ne peut pas mettre jour plusieurs tables simultanment. Enn, la prsentation tabulaire nest pas ergonomique et est source de nombreuses erreurs de saisie. Si lon souhaite afcher, saisir ou modier des donnes dans une table, les SGBD offrent des objets spcialiss que lon appelle formulaires. Un formulaire est destin tre afch lcran pour offrir lutilisateur une interface agrable la mise jour des tables. Il y a deux types de formulaires : les formulaires de prsentation de donnes dont lobjectif est de prsenter, saisir ou modier les donnes dune ou plusieurs tables ; les formulaires de distribution qui ne sont attachs aucune table et servent uniquement de page de menu pour orienter lutilisateur vers dautres formulaires ou tats. Ils ne contiennent que du texte et des boutons dorientation. En principe, un formulaire de prsentation afche un seul enregistrement la fois mais peut contenir des champs provenant de plusieurs tables. Le formulaire de prsentation est toujours attach une table ou, comme nous le verrons par la suite, une requte principale. Sous sa forme la plus simple, un formulaire se prsente comme une page blanche (voir la gure 2.1) dans laquelle on place des composants graphiques permettant lafchage dun enregistrement (voir les gures 2.2 et 2.3). On dispose en gnral dobjets de type : label, permettant dafcher du texte ; zone de texte, permettant de saisir ou dafcher la valeur dun champ de la table ; boutons doptions (Radio button) ;
1

Quand il est disponible, comme avec Developper 2000 ou Access. Sur de gros systmes, il ny a en gnral aucun accs de ce type.

Les formulaires

27

Figure 2.1 Structure dun formulaire vide sous Access cases cocher (CheckBox) ; zones de liste, pour afcher des listes de valeurs ; boutons, pour tester le clic de souris, par exemple ; bascules, pour un champ de type boolen, par exemple ; images ; onglets ; attributs graphiques de type rectangle, segment, ovale, etc., pour agrmenter le formulaire. Il est bien sr possible deffectuer des calculs qui seront afchs dans les formulaires sans que le rsultat du calcul ne soit explicite dans aucune table. Il arrive frquemment que lon souhaite afcher des donnes de deux tables qui sont en relation lune avec lautre. Cela se produira si lon souhaite afcher une commande avec la liste des produits commands, un compte bancaire avec les critures en cours sur ce compte, ou les vols ariens avec le personnel de bord.

Figure 2.2 Formulaire rudimentaire

28

Chapitre 2 Prsentation des donnes

Figure 2.3 Structure du formulaire de la gure 2.2 On utilise dans ce cas un formulaire qui contient les donnes de la table principale, et un sous-formulaire qui contient les donnes de la table lie (voir la gure 2.4). Le sous-formulaire est alors plac dans le formulaire principal, crant ainsi une relation pre-ls entre formulaires.

Figure 2.4 Structure dun formulaire avec sous-formulaire Le sous-formulaire nafche alors que les enregistrements relatifs lenregistrement en cours du formulaire principal (voir la gure 2.5). Si lutilisateur change denregistrement principal, le sous-formulaire est automatiquement mis jour. Avec les outils les plus ergonomiques en ce domaine, un simple glisser au moyen de la souris permet de placer un sous-formulaire dans un formulaire principal avec mise en place automatique du lien entre les deux. Un formulaire principal peut contenir autant de sous-formulaires que lon souhaite. De plus, un sous-formulaire peut lui aussi contenir un autre sous-formulaire. On pourra, par exemple, afcher dans le formulaire principal les coordonnes dun client

Les tats

29

Figure 2.5 Formulaire avec sous-formulaire avec, dans le sous-formulaire, les commandes de ce client et, lintrieur de ce sousformulaire, un autre sous-formulaire dtaillant chaque commande. Pour agrmenter la prsentation, chaque formulaire possde ses propres proprits comme la couleur de fond, la prsence ou non de boutons de dplacement ou de barres de dlement. De mme, chaque objet plac dans le formulaire possde lui aussi ses propres proprits comme sa couleur ou la taille de la police utilise. Il est aussi possible, dans de nombreux SGBD, de prciser un mode dutilisation dun formulaire. On indiquera, par exemple, que tel formulaire ne doit servir qu effectuer des saisies et que tel autre ne pourra tre utilis que pour afcher des donnes sans mise jour possible. Ces fonctionnalits augmentent grandement la scurit dutilisation au niveau de lutilisateur. Cette partie, bien qutant trs importante pour lergonomie dune application professionnelle, nest pas dtaille dans ce livre car elle est propre chaque outil. Lune des rgles fondamentales suivre, lors de la conception de formulaires de saisie de donnes, est dessayer de minimiser les saisies au clavier par lutilisateur. Cest pourquoi les listes droulantes bases sur des requtes, listes de choix et sous-formulaires ont tant dimportance lors de la conception de bases de donnes nalises. Pourquoi en effet saisir un code postal alors que lon peut afcher la liste et cliquer dessus, pourquoi saisir le numro de fournisseur dune commande alors quon peut le choisir dans une liste, etc.

2.2 Les tats


Si les formulaires permettent une prsentation lgante des donnes lcran, ils ne sont pas adapts la prsentation papier. Pour analyser les donnes et les mettre en page pour limpression, on utilise un tat. Celui-ci permet bien sr lafchage de

30

Chapitre 2 Prsentation des donnes

plusieurs enregistrements simultans mais aussi le calcul de cumuls, de regroupements et lafchage de synthses. Il permet aussi llaboration de graphiques de prsentation, la gestion dtiquettes ou de publipostages. En gnral, un tat est cr pour prsenter les donnes contenues dans une ou plusieurs tables. Il est donc toujours li au moins une table ou, comme nous le verrons par la suite, une requte principale. Comme pour les formulaires, un tat peut trs bien prsenter des calculs qui ne sont explicits dans aucune table.

Figure 2.6 Structure dun tat vide sous Access Un tat est un objet structur qui comprend plusieurs niveaux. Dans sa forme la plus simple (voir la gure 2.6), il contient : un en-tte de formulaire qui nest afch quune seule fois en dbut dtat. Il contient en gnral le titre du formulaire avec toutes les informations permettant didentier prcisment ce qui sera ensuite prsent. Il contient aussi le logo de la socit, la date et lheure dimpression ; un en-tte de page qui est afch en haut de chaque page. Si ltat simprime sur n pages, il sera afch n fois. Il contient en gnral les intituls des colonnes qui sont imprims an que le lecteur puisse se reprer facilement dans ltat ; une zone de dtail qui contient les donnes proprement dites. Elle est rpte pour chaque enregistrement qui sera afch. Elle peut bien sr tenir sur plusieurs lignes et afcher des champs calculs ; un pied de page qui est le pendant de len-tte de page. Il est afch en bas de chaque page et contient en gnral au moins le numro de page ;

Les tats

31

un pied de formulaire qui est le pendant de len-tte de formulaire. Il nest afch quune fois en n de formulaire pour, par exemple, imprimer une synthse de ce qui a t afch dans ltat. Mise part la zone de dtail, toutes les autres zones sont facultatives et peuvent ventuellement tre vides (voir les gures 2.7 et 2.8).

Figure 2.7 tat rudimentaire

Figure 2.8 Structure de ltat de la gure 2.7 Comme pour les formulaires, la notion de sous-tat existe mais prsente peu dintrt. Lors de lafchage de donnes provenant de plusieurs tables, on prfrera la solution

32

Chapitre 2 Prsentation des donnes

qui consiste crer une requte reprenant tous les champs imprimer, puis crer un tat sur cette nouvelle requte. Cette solution, trs gnrale, est beaucoup plus pratique et ergonomique que la solution base sur des sous-tats. Quand les donnes proviennent (indirectement) de plusieurs tables, il arrive frquemment que lon souhaite afcher des informations complmentaires en cas de rupture de logique dans la prsentation de ces donnes ; par exemple, afcher la somme des commandes aprs chaque dtail dune commande ou afcher le solde dun compte aprs la liste des oprations sur ce compte. Dans un tel cas, les oprations effectues regroupent plusieurs enregistrements sur une ou plusieurs valeurs communes comme le numro de commande ou le numro de compte. Pour afcher sur ltat des informations complmentaires en cas de changement de zone de regroupement, les tats requirent deux nouvelles structures (voir la gure 2.10) : en-tte de regroupement Len-tte de regroupement contient les informations afcher avant que le dtail des critures qui seront regroupes ne soit afch. On y place en gnral un soustitre ou un cadre ; pied de regroupement Le pied de regroupement contient les informations qui seront afches aprs le dtail des critures regroupes. On y place en gnral les oprations de cumul et de synthse (nombre, somme, moyenne, etc.) des informations afches.

Figure 2.10 Structure de ltat de la gure 2.9

Exercices

33

Figure 2.9 tat avec regroupement et champs calculs En-tte et pied de regroupement sont afchs pour chaque groupe de donnes prsent dans ltat (voir la gure 2.9). Pour agrmenter la prsentation, chaque tat possde ses propres proprits. Chaque zone constituant un tat possde elle aussi ses proprits comme la couleur de fond, la police utilise. Enn, chaque objet plac dans ltat possde lui aussi ses propres proprits comme sa couleur, la taille de la police utilise, etc. Comme pour les formulaires, cette partie trs importante pour lergonomie dune application professionnelle nest pas dtaille dans ce livre car elle est propre chaque outil.

2.3 Exercices
1. Crer une table unique Agenda dans laquelle on trouvera notamment les nom, prnom, adresse, code postal, ville, tlphone, portable, fax, email, remarques, deuxime adresse, etc., pour chaque individu. Crer un formulaire prsentant des donnes qui soient accessibles uniquement en lecture, puis un formulaire de saisie et un formulaire de modication. Vous proposerez ensuite un tat dtaillant toutes les donnes et un tat restreint sous format dtiquette par exemple, ne prsentant que les nom, prnom et adresse. Vous terminerez enn par un menu gnral dappel des formulaires et tats crs.

34

Chapitre 2 Prsentation des donnes

2. Crer une base de donnes gnalogique simplie. Pour cela, on utilisera une table unique famille contenant des renseignements classiques sur les personnes comme les numro didentication, nom, prnom, sexe, nom marital, adresse, ville, identiant du pre, de la mre et du conjoint. On simpliera le problme en considrant quon ne peut avoir quun seul conjoint dans une vie et que des enfants lgitimes. Concevoir les formulaires de lecture et de saisie avec le moins de saisie possible notamment pour pre, mre, conjoint qui doivent tre proposs dans des listes choix. Concevoir un formulaire afchant lascendance deux niveaux dune personne (parents et grands-parents). Proposer des tats rcapitulatifs ainsi que des tats tiquettes pour le mailing aux familles. 3. Mme exercice, mais cette fois-ci on autorise plusieurs conjoints et des enfants lgitimes ou illgitimes. Il faut donc plusieurs tables. 4. Mme exercice, mais avec le MCD de gestion de la discothque du chapitre prcdent. Cette fois-ci, les formulaires contiendront des sous-formulaires et les tats des zones de regroupements. Vous terminerez par un menu gnral dappel des formulaires et tats crs. 5. Mme exercice, mais avec le MCD de gestion des comptes bancaires du chapitre prcdent. Un formulaire doit permettre de rechercher les clients, puis dafcher ses comptes et enn dafcher les critures pour chaque compte pour lequel le dtail est demand. Un formulaire devra permette de saisir des critures, un tat dditer un relev de compte des oprations du mois et un autre tat prsentera un rcapitulatif des comptes avec leurs soldes respectifs pour chaque client. Vous terminerez par un menu gnral dappel des formulaires et tats crs.