OFPPT
Filire : TSSSRI
REMERCIEMENT
La DRIF remercie les personnes qui ont contribu llaboration du prsent document. Pour la supervision :
Pour la conception :
- ELGHOLABZOURI MOUNIR
Pour la validation :
- JELLAL ABDELILAH
Les utilisateurs de ce document sont invits communiquer la DRIF toutes les remarques et suggestions afin de les prendre en considration pour lenrichissement et lamlioration de ce programme. Said Slaoui
Page 2/91
TABLE DE MATIERE
TABLE DE MATIERE ......................................................................................................................................1 PARTIE 1 OBJECTIFS ..................................................................................................................................4 PARTIE 2 SGBD PRINCIPE ET FONCTIONNEMENT ...................................................................7 I GENERALITES SUR LES BASES DE DONNEES .................................................................................................7 II OBJECTIFS DE L'APPROCHE SGBD ..............................................................................................................8 III ARCHITECTURE FONCTIONNELLE D'UN SGBD : ANSI-SPARC .............................................................9 IV FONCTIONNEMENT D'UN SGBD ................................................................................................................11 V PRINCIPAUX MODELES LOGIQUES ...............................................................................................................12 PARTIE 3 CONCEPTION ET DEMARCHE .........................................................................................16 I CONCEPTION DE BASES DE DONNEES ..........................................................................................................16 II DEMARCHE DE CREATION DUNE BASE DE DONNEES ................................................................................17 III LES REDONDANCES ....................................................................................................................................20 PARTIE 4 CREATION ET MANIPULATION DES BASES DE DONNEE AVEC MS ACCESS ..............................................................................................................................................................23 I CREATION DES TABLES .................................................................................................................................23 II SAISIE DE DONNEE ET CREATION DE FORMULAIRE ...................................................................................31 III MANIPULATION DES DONNEE ET CREATION DES REQUETE......................................................................40 IV LANGAGE SQL ............................................................................................................................................46 V LES FORMULAIRES ET SOUS- FORMULAIRES ..................................................................................56 VI LES ETATS ...............................................................................................................................................57 PARTIE 5 TRAVAUX D'APPLICATION .............................................................................................64 INTRODUCTION.................................................................................................................................................64 ATELIER N 1 CREATION DE TABLES ..........................................................................................................65 ATELIER N 2 REMPLISSAGE DES TABLES ..................................................................................................66 ATELIER N 3 PROPRIETE DES TABLES .......................................................................................................67 ATELIER N 4 LES REQUETES .....................................................................................................................68 ATELIER N 5 LES FORMULAIRES ...............................................................................................................70 ATELIER N 6 LES FORMULAIRES (SUITE) .................................................................................................71 ATELIER N 7 LES ETATS ............................................................................................................................72 ATELIER N 8 LES MACROS ........................................................................................................................73 ATELIER N 9 GESTION DES COMMANDES (ATELIER RECAPITULATIF) ....................................................75 PARTIE 6 EXERCICES DAPPLICATIONS (LANGAGE SQL) ...................................................78 PARTIE 7 EVALUATION............................................................................................................................83 ANNEXE .............................................................................................................................................................87
Filire : TSSSRI
COMPORTEMENT ATTENDU Pour dmontrer sa comptence, le stagiaire doit utiliser les techniques de manipulation d'une base de donnes l'aide d'un logiciel de bases de donnes selon les conditions, les critres et les prcisions qui suivent.
CONDITIONS DEVALUATION Travail effectu avec : un micro-ordinateur ; un logiciel de base de donnes ; une imprimante. Travail effectu partir des source de rfrence et tude de cas CRITERES GENERAUX DE PERFORMANCE Respect des consignes et du temps allou. Utilisation judicieuse des commandes. Interprtation juste des messages apparaissant l'cran. Sauvegarde et restauration appropries des donnes. Utilisation optimale des fonctions d'aide des logiciels et autres sources de rfrence. Respect des rgles de la scurit.
OBJECTIFS
A. Analyser la demande pour manipuler une Base de donnes B. Traiter et manipuler les donnes C. Adapter la structure de la base de donnes de nouveaux besoins D. Documenter la base de donnes
Filire : TSSSRI
LE STAGIAIRE DOIT MAITRISER LES SAVOIRS, SAVOIRS-FAIRE, SAVOIR-PERCEVOIR OU SAVOIR-ETRE JUGES PREALABLES AUX APPARENTISSAGES DIRECTEMENT REQUIS POUR LATTEINTE DE LOBJECTIF DE PREMIER NIVEAU, TELS QUE :
Avant dapprendre analyser la demande pour manipuler une Base de donnes. (A) :
1. Dcrire les consquences des systmes de gestion de base de donnes sur le fonctionnement dune entreprise. 2. Dcrire les caractristiques des bases de donnes. 3. Distinguer les types de bases de donnes. 4. Enumrer les utilisations possibles dune base de donnes. 5. Expliquer au stagiaire le principe des bases de donnes relationnelles.. 6. Dcrire au stagiaire les phases de cration dune base de donnes simple 7. Analyser la demande (2 tables avec une relation).
1. Enumrer les inconvnients dune mthode classique de recherche des donnes. 2. Montrer la souplesse dutilisation dun SGBDR pour la recherche des donnes.
Avant dapprendre adapter la structure de la base de donnes de nouveaux besoins. (C): Sensibiliser le stagiaire l'intrt de la scurit des donnes. Avant dapprendre documenter la base de donnes (D):
Filire : TSSSRI
Filire : TSSSRI
Rappel sur les systmes de gestion de fichiers Toute manipulation de fichier exige trois niveaux dintervention, et trois couches logicielles : Gestion du support physique : disques durs, disquette, streamers Pilote dentres-sorties (Driver) Gestion des structures internes des fichiers, et des mthodes daccs : ouverture, fermeture, lecture, criture Systme de gestion de fichiers (SGF) Gestion des contenus : calculs, tests, affichages ... Programmes applicatifs Applications Systme d'exploitation Matriel
Ouvrir, fermer lire, crire Programme applicatif Code derreur ou Donnes logiques
Niveau Logique Systme de Gestion de Base de donnes : SGBD
SGF
Code derreur ou Enregistrement physique
Niveau Physique
Filire : TSSSRI
dfinir des "bases de donnes", et des relations entre les lments de chaque base ; spcifier le traitement de ces donnes : interrogations, mises jour, calculs, extractions... Le SGBD reoit des commandes aussi bien des programmes d'application que des utilisateurs : il commande les manipulations de donnes, gnralement par l'intermdiaire d'un SGF.
Utilisateur Ouvrir, fermer, Gestion de la Base lire, crire SGBD Code rponse, Programme applicatif Donnes logiques SGF Enreg. physique ou code erreur Demande d'un enreg. physique Units De Lecture/ Ecriture
Intgration et corrlation Dans les systmes classiques, chaque application gre ses donnes dans ses propres "fichiers", do : Un risque de redondance, et un danger d'incohrence des donnes La mme donne peut appartenir plusieurs applications, induisant une dperdition de stockage. Toute modification de cette donne est enregistrer plusieurs fois : si cette mise jour multiple n'est pas effectue correctement, les donnes deviennent incohrentes. Le cot de la mise jour augmente du fait de la multiplication des entres-sorties physiques. Une difficult pour crer de nouveaux traitements Les nouvelles applications entranent des duplications supplmentaires de donnes. Leur intgration avec les applicatifs en exploitation entrane des modifications importantes.
Dans l'approche SGBD, un "rservoir" commun (intgration) est constitu, reprsentant une modlisation (corrlation) aussi fidle que possible de l'organisation relle de l'entreprise : Toutes les applications puisent dans ce rservoir, les donnes qui les concernent, vitant ainsi les duplications. Mais le partage des donnes entre les utilisateurs pose le problme de la synchronisation des accs concurrents.
Flexibilit ou indpendance Dans les systmes classiques, tout changement intervenant dans le stockage des donnes (support, mthode d'accs physique) entrane des modifications lourdes des applications correspondantes. L'approche SGBD poursuit trois objectifs, pour assurer lindpendance des donnes par rapport aux traitements : indpendance physique: tout changement de support, de mthode d'accs reste transparent au niveau de l'utilisateur. indpendance logique : les programmes d'application sont rendus transparents une modification dans l'organisation logique globale, par la dfinition de sous-schmas couvrant les besoins spcifiques en donnes.
Page 8/91
indpendance vis--vis des stratgies d'accs : l'utilisateur n'a plus prendre en charge l'criture des procdures d'accs aux donnes. Il n'a donc pas intgrer les modifications tendant optimiser les chemins d'accs (ex: cration d'index).
Disponibilit Le choix d'une approche SGBD ne doit pas se traduire par des temps de traitement plus longs que ceux des systmes antrieurs. Lutilisateur doit ignorer l'existence d'utilisateurs concurrents. L'aspect "performance" est donc crucial dans la mise en oeuvre d'une base de donnes. Un tel objectif ne peut tre atteint que si la conception d'une base de donnes est mene de faon rigoureuse avec un dcoupage fonctionnel adquat. Les rgles et contraintes inhrentes sont voques lors de l'apprentissage d'une mthodologie d'analyse (exemple MERISE).
Scurit La scurit des donnes recouvre deux aspects : l'intgrit, ou protection contre l'accs invalide (erreurs ou pannes), et contre l'incohrence des donnes vis--vis des contraintes de l'entreprise. la confidentialit, ou protection contre l'accs non autoris ou la modification illgale des donnes. Pour ne pas trop affecter les performances, la scurit doit galement tre prise en compte ds la phase de conception.
Modle externe
Schma Externe
Utilisateur 1
Schma externe
Utilisateur 2
Schma externe
Application 3
Modle conceptuel
Schma conceptuel
Analyste
Administrateur de la base
Niveau conceptuel Cest une abstraction aussi fidle que possible, de l'univers de l'entreprise, aprs modlisation et indpendamment de toute rfrence l'utilisation et l'implantation en machine.
Filire : TSSSRI
Le modle conceptuel de donnes (MCD) permet le passage d'un concret inaccessible (l'univers rel) un abstrait manipulable : le schma conceptuel. Celui-ci peut donc tre considr comme la description du contenu de la base : c'est le rsultat d'un travail d'analyse et de conception d'un systme d'information automatis. Un schma conceptuel doit offrir les caractristiques suivantes : puissance de reprsentation : aspects structurels, contraintes existant dans l'univers rel. stabilit et flexibilit : l'ajout d'une nouvelle donne ou d'une nouvelle contrainte ne doit pas entraner de changement important dans le schma. simplicit de comprhension : nombre d'lments rduit, dissociation claire des diffrents concepts. simplicit d'utilisation : nombre restreint d'outils ou de primitives de manipulation. base formelle : la dfinition du schma doit s'appuyer sur une mthode rigoureuse, mathmatique, pour viter toute ambigut d'interprtation et pour garantir la fiabilit des donnes. Pour aboutir au schma conceptuel, l'analyste doit reprer dans le rel, et recenser de manire exhaustive, toutes les entits et toutes les associations :
Une entit peut tre dfinie comme une personne, un objet, un lieu, un statut, un vnement qui ont une existence dans le monde rel. C'est un objet concret ou abstrait, possdant un certain nombre de caractristiques spcifiques (exemple : le produit x cote y francs). Gnralement, les entits du monde rel se manifestent travers des faits lmentaires. Certains faits faisant intervenir plusieurs entits, il apparat la notion d'association. Une association (ou lien) est un ensemble de deux ou plusieurs entits, chacune d'elles jouant un rle particulier. Exemple : le fait que la "voiture x" appartienne la "personne y" est une association entre les entits "voiture " et "personne". Selon la notation CODASYL, trois types de liens peuvent tre envisags :
les liens fonctionnels nots N : 1 On a un lien fonctionnel N:1 de A vers B si toute occurrence de A dtermine au plus une occurrence de B, et si toute occurrence de B, correspond un nombre quelconque doccurrences de A. Exemple : dans une compagnie arienne, connaissant le numro d'un vol, on en dduit d'une manire unique la destination, mais plusieurs vols peuvent avoir la mme destination.
Numros Vols
Destinations
X Y Z
X Y Z W
les liens hirarchiques nots 1 : N. On a un lien hirarchique 1:N de A vers B si une occurrence de A peut dterminer un nombre quelconque doccurrences de B et si, une occurrence de B, correspond au plus une occurrence de A. Exemple : la polygamie est un lien 1 : N de "homme" vers "femme". - les liens maills nots N : M. On a un lien maill de A vers B s'il n'existe aucune restriction sur le nombre d'occurrences de A et B intervenant dans le lien.
Exemple : dans un lyce donn, un enseignant peut dispenser des cours dans plusieurs matires diffrentes ; de la mme faon, une matire peut tre dispense par plusieurs enseignants.
Page 10/91
Niveau externe Le niveau externe comprend les "vues" spcifiques dfinies pour la manipulation des donnes. Il prend en compte les contraintes d'accs imposes par la nature des applications considrer (indpendamment des caractristiques techniques) et exprime les besoins en donnes des diffrents utilisateurs, ou applications. Le modle logique des donnes (MLD) utilis ce niveau externe peut diffrer de celui utilis au niveau conceptuel. Ainsi, certaines vues peuvent ne pas tre construites dans la base, mais dduites par calcul partir de certaines donnes du schma conceptuel (exemple : anciennet obtenue par diffrence entre anne en cours et annne d'embauche dans la socit).
Niveau interne ou Physique Il correspond la reprsentation en machine, aussi efficace que possible, du schma conceptuel : le schma physique intgre les caractristiques techniques (choix du SGBD, du matriel, du systme dexploitation). L'efficacit doit tenir compte d'une part des contraintes d'implantation (taille des disques, optimisation du systme de fichiers), d'autre part des critres d'utilisation (traitement interactif ou en batch, selon la frquence dutilisation et la dure du traitement).
Les langages d'un SGBD Cette prsentation des SGBD fait apparatre la ncessit de bien diffrencier deux tapes : la dfinition des donnes par ladministrateur de la base (DBA) leur utilisation par les utilisateurs ou les programmeurs d'application. Le SGBD met donc disposition deux types de langage : LDD et LMD Langage de Description de Donnes : LDD
Filire : TSSSRI
Il permet de dcrire prcisment la structure de la base et le mode de stockage des donnes. Alors que l'utilisation de fichiers permet seulement une description de donnes interne au programme, dans une approche Base de Donnes, on effectue la description de toutes les donnes une fois pour toutes : elle constitue l'ensemble des tables et dictionnaires de la base, son schma (terminologie CODASYL). En particulier, il prcise la structure logique des donnes (nom, type, contraintes spcifiques...), la structure physique (mode d'implantation sur les supports, mode d'accs), la dfinition des sous-schmas ou "vues".
Langage de Manipulation de Donnes : LMD L'utilisation d'une BDD suppose un grand nombre d'utilisateurs, souvent non informaticiens, ayant des tches et des besoins varis auxquels le LMD doit pouvoir rpondre. Le SGBD fournit deux niveaux daccs : le langage d'interrogation, ou langage de requte interactif vite le recours des langages gnraux de programmation. Il doit avoir une syntaxe souple, si possible graphique, tre accessible aux non-spcialistes et permettre la formulation de demandes utilisant des critres varis et combins. le langage hte pour les traitements rguliers, le SGBD doit fournir une interface permettant l'utilisation de la base l'aide des langages procduraux (COBOL, Pascal, C/C++.), en incorporant les requtes dans des programmes classiques. Classification des LMD langages navigationnels (ex : SYMBAD) dans les SGBD hirarchiques ou rseaux. Les requtes du langage dcrivent les chemins d'accs aux diffrentes donnes, celles-ci tant gnralement chanes entre elles. langages algbriques (ex : SQL voir en dtail chap. 4 part. 3) Dans les SGBD relationnels. Ils utilisent, pour fournir des rsultats aux requtes, les oprateurs de l'algbre relationnelle.
Socit
Salaris
Vols
Matriel
Pilotes
Htesses
Entretien
Administratif
L'anctre le plus rpandu est le SGBD IMS (Information Management System), dvelopp et commercialis par IBM dans les annes 70 Caractristiques gnrales du modle :
Page 12/91
Forte dpendance entre la description de la structure des donnes et la manire dont celles-ci sont enregistres sur le support physique. Les lments de base du modle sont des enregistrements logiques relis entre eux pour constituer un arbre ordonn. Les entits (ou segments) constituent les noeuds, celui de plus haut niveau portant le nom de racine ; les branches (pointeurs logiques entre entits) constituent les liens. Chaque segment est une collection d'objets appels champs (ou Fields). Chaque segment a obligatoirement un pre (sauf la racine), et peut avoir plusieurs fils. Avantages : rigueur des structures et des chemins d'accs simplicit relative de l'implmentation adquation parfaite du modle une entreprise structure arborescente.
Inconvnients : les accs se font uniquement depuis la racine la structure interdit les liens N:M, ne permettant que le lien 1:N. La reprsentation d'autres relations impose de ce fait une redondance de l'information. Exemple : comment reprsenter dans ce modle, un parc de vhicules et un ensemble de chauffeurs, chaque chauffeur pouvant conduire plusieurs vhicules, et un vhicule pouvant tre conduit par plusieurs chauffeurs ? les "anomalies" que l'on constate lors des oprations de mise jour (insertion, destruction, modification) : l'limination d'un noeud entrane l'limination de tous les segments de niveau infrieur qui lui sont rattachs (risque de perdre des donnes uniques) indpendance logique trs rduite : la structure du schma doit reflter les besoins des applications. pas d'interface utilisateur simple. Le modle en rseau Evolution du modle hirarchique intgrant les rsultats du travail du groupe CODASYL (comit de langage de programmation), qui avait dmarr l'tude d'une extension de COBOL pour manipuler les bases de donnes. En 1969, il donne ses premires recommandations concernant syntaxe et smantique du LDD et du LMD. Mme si cette vue est un peu simplificatrice, une base en rseau peut tre dcrite comme un certain nombre de fichiers comportant des rfrences les uns vers les autres. Les entits sont connectes entre elles l'aide de pointeurs logiques : un enregistrement d'un ensemble de donnes A est associ une srie d'enregistrements (ou records) d'un autre ensemble de donnes B. On constitue ainsi des SET, ou COSET, structure fondamentale du modle en rseau le lien entre les enregistrements de A et ceux de B est 1:N le COSET comporte un type d'enregistrement "propritaire" (l'enregistrement de A est dit OWNER) et un type d'enregistrement "membre" (les enregistrements de B sont MEMBER).
Avantages et inconvnients du modle : aucune restriction dans la conception : un type de "record" peut la fois tre propritaire et membre de plusieurs sets reprsentation naturelle des liens maills N:M pas d'anomalies pour les oprations de stockage commercialisation importante des systmes correspondants (DMS, IDMS, TOTAL, IDS II, SOCRATE...), MAIS pas d'indpendance par rapport aux stratgies d'accs procduralit importante des langages de manipulation ; l'utilisateur doit "naviguer" dans le rseau logique constitu par les enregistrements et les chanes de pointeurs. Exemple : schma reprsentant le sous-systme d'information Produits / magasins de stockages / fournisseurs / domiciliations bancaires
Filire : TSSSRI
Produits
Fournisseurs
Magasin de stockage
Produit/Fournisseur
Domiciliation bancaire
Le modle relationnel C'est un article publi en 1969 par un mathmaticien du centre de recherche IBM, Codd, qui dfinit les bases de ce modle relationnel. Codd s'est intress au concept d'information et a cherch le dfinir sans se proccuper de la technique informatique, de ses exigences et de ses contraintes. Il a tudi un modle de reprsentation des donnes qui repose sur la notion mathmatique de "relation". Dans la pratique, une relation sera reprsente par une table de valeurs.
Exemple: reprsentation d'une table du personnel Matricule 350 780 320 490 Nom Durand Dupond Veillon Martin poste Employ Cadre PDG Cadre Salaire 8000 15000 25000 15000 N dept 320 870 400 320
Dfinitions Une relation est un ensemble de tuples (lignes), dont l'ordre est sans importance. Les colonnes de la table sont appeles attributs ou champs. Lordre des colonnes est dfini lors de la cration de la table. Une cl est un ensemble ordonn d'attributs qui caractrise un tuple. Une cl primaire le caractrise de manire unique, l'inverse d'une cl secondaire. On dit qu'un attribut A est un dterminant si sa connaissance dtermine celle de l'attribut B (B dpend fonctionnellement de A). Caractristiques du modle Schma de donnes facile utiliser : toutes les valeurs sont des champs de tables deux dimensions. Amliore l'indpendance entre les niveaux logique et physique : pas de pointeurs visibles par l'utilisateur. Fournit aux utilisateurs des langages de haut niveau pouvant ventuellement tre utiliss par des non-informaticiens (SQL, L4G) et un ensemble d'oprateurs bas sur l'algbre relationnelle : union, intersection, diffrence, produit cartsien, projection, slection, jointure, division. Optimise les accs aux bases de donnes Amliore l'intgrit et la confidentialit : unicit de cl, contrainte dintgrit rfrentielle Prend en compte une varit d'applications, en gestion et en industriel Fournir une approche mthodologique dans la construction des schmas.
Page 14/91
Filire : TSSSRI
Filire : TSSSRI
Exemple: L'exemple porte sur un ensemble de donnes concernant des tests de types diffrents, effectus sur les lments matriel d'un systme de production : R (libell matriel, code marque, libell marque, type de test, date du test, rsultat du test) n'est pas en 1re forme normale car aucun attribut ne peut tre cl primaire : le libell matriel peut tre identique pour plusieurs lments. R (code matriel, libell matriel, code marque, libell marque, code type de test, libell du test, date du test, rsultat du test) n'est pas en 1re forme normale car on peut faire plusieurs tests sur un mme matriel, ce qui exige de rpter les informations "code type de test", "libell du test", "date du test", "rsultat du test", dans un mme nuple. La relation doit tre clate en deux, pour tre exprime en 1re forme normale : R-MATERIEL (code matriel, libell matriel, code marque, libell marque) R-TEST (code matriel, code type, libell test, date du test, rsultat du test) Les deux relations ne comportent que des attributs sans rptition. Dans R_TEST, la cl primaire est compose de "code matriel" et "code type" : un type de test peut concerner plusieurs matriels, un matriel peut tre test plusieurs fois, mais chaque matriel ne subit quune fois un type de test donn. 2me forme normale Une relation est dite en deuxime forme normale si elle est en premire forme normale, et si tout attribut n'appartenant pas la cl primaire ne dpend pas que d'une partie de cette cl.
R-TEST(code matriel, code type, libell test, date du test, rsultat du test) n'est pas en 2me forme normale car l'attribut "libell test" ne dpend que du "code type" et pas du "code matriel" ; La relation doit clate en deux, pour tre exprime en deuxime forme normale :
R-TEST (code matriel, code type, date du test, rsultat du test) R-TYPETEST (code type, libell test)
3me forme normale Une relation est dite en troisime forme normale si elle est en deuxime forme normale, et si toutes les dpendances fonctionnelles issues de la cl primaire sont directes
La dpendance entre "code matriel" et "libell marque" n'est pas directe, "libell marque" est en dpendance fonctionnelle directe avec le "code marque". La relation doit tre clate en deux, pour tre exprime en troisime forme normale : R-MATERIEL (code matriel, libell matriel, code marque) R-MARQUE (code marque, libell marque) Le schma conceptuel final de la base de donnes est donc : R-MATERIEL (code matriel, libell matriel, code marque) R-MARQUE (code marque, libell marque) R-TYPETEST (code type, libell test) R-TEST (code matriel, code type, date du test, rsultat du test) Commentaires: Le schma conceptuel fait apparatre 3 relations entits : R-MATERIEL, R-MARQUE, RTYPETEST et la relation association R-TEST qui ralise le lien Matriel <--> Type test de type N:M Le lien fonctionnel Matriel <--> Marque de type N:1 est ralis par la prsence du "code marque" dans la relation R-MATERIEL.
N MATERIEL 1
TEST N N
Filire : TSSSRI
Recenser tous les rsultats que votre application doit pouvoir vous fournir. Il sagit gnralement dtats produire. Ces tats doivent contenir des donnes. Une maquette papier des tats peut tre ralise afin de ne rien oublier. Si nous reprenons notre exemple, les rsultats obtenir sont : la liste des adhrents avec leur code, nom, prnom, date de naissance, adresse, code postal, ville et numro de tlphone la liste des quipements mis leur disposition avec le code, le nom et le tarif dutilisation la liste des adhrents et des quipements quils utilisent, ainsi que le montant pay. LE DICTIONNAIRE DES DONNEES Il faut alors crer le dictionnaire des donnes cest--dire recenser tous les renseignements grer sans distinguer ce quoi ils se rapportent. Nous aurons donc : Nom adhrent Prnom adhrent Date de naissance Adresse Code postal Ville Numro de tlphone Nom activit Tarif activit Lieu de pratique Droit dentre LA DEFINITION DES ENTITES Lentit peut tre un individu (client, adhrent), un bien (article, dpt, magasin, quipement), un concept (description dune commande, inscription). Nous voyons apparatre ici trois entits : les adhrents les activits et les lieux de pratique. Il sagit maintenant de dfinir quelle entit se rapportent les donnes recenses plus haut, cest-dire de quel objet ou entit elles deviennent lattribut (ou la caractristique). Nous pouvons dfinir le schma qui suit :
ADHERENT Nom adhrent Prnom adhrent Date de naissance Adresse Code postal Ville Numro de tlphone ACTIVITE Nom activit Tarif activit LIEU Nom du lieu Droit dentre
A chaque entit correspondra une table dans la base de donnes. LE MODELE ENTITE ASSOCIATION Lassociation est un lien entre 2 (ou plusieurs) entits. Entre lentit ADHERENT et lentit ACTIVITE, lassociation correspond la notion de PRATIQUE de lactivit, et est matrialise par le verbe Pratiquer. Entre lentit ADHERENT et lentit LIEU, lassociation correspond la notion dutilisation et est matrialise par le verbe Utiliser De plus nous allons rajouter un identifiant unique dans chaque table sous forme de Numro ou de Code. Le modle Entit Association prend lallure suivante :
Page 18/91
ADHERENT
Num_adh
PRATIQUE
ACTIVITE
Code_activ
Activ Tarif
UTILISE
LIEU
Code_lieu
Lieu Entre
Num_adh est lidentifiant de la table ADHERENT. Ce champ sera dfini comme cl primaire index sans doublon. Code_activ est lidentifiant de la table ACTIVITE. Il sera dfini comme cl primaire index sans doublon. Code_lieu est lidentifiant de la table LIEU. Il sera dfini comme cl primaire index sans doublon. LES REGLES DE GESTION Ce sont les rgles qui rgissent notre application. Ici un adhrent peut pratiquer plusieurs activits, sur un seul lieu. Il suffira quil paie le tarif des cotisations correspondant aux quipements utiliss, et le droit dentre sur le lieu de pratique. LE MODELE RELATIONNEL Nous devons maintenant crer le modle relationnel. Les activits Un adhrent peut pratiquer plusieurs ACTIVITES Une activit peut tre pratique par plusieurs ADHERENTS Il y a donc une relation de plusieurs plusieurs entre les tables ADHERENT et ACTIVITE. Avec ACCESS, il nest pas possible de crer un tel type de relation directement entre deux tables. Il faut ncessairement transiter par une table intermdiaire. Pour cela, il faut remplacer lassociation matrialise par le verbe utiliser par une nouvelle table qui servira de lien entre les 2 autres tables. Cette nouvelle table que nous appellerons PRATIQUE comprendra donc les champs suivants : Num_adh Code_activ N.B Ces deux champs correspondent aux cls primaires des deux autres tables. Nous tablirons une relation de type un plusieurs entre le champ Num_adh de la table ADHERENT et le champ Num_adh de la table PRATIQUE. Nous tablirons une relation de type un plusieurs entre le champ Code_activ de la table ACTIVITE et le champ Code_activ de la table PRATIQUE. Le lieu de pratique Un adhrent ne pratique que sur un seul lieu. Un lieu peut recevoir plusieurs adhrents. N.B Nous avons donc une relation de un plusieurs entre la table LIEU et la table ADHERENT. Pour crer cette relation, nous allons devoir rajouter dans la table ADHERENT le code du lieu de pratique, afin dtablir la relation directe entre le champ Code_lieu de la table LIEU et le champ Code_lieu de la table ADHERENT. Le modle relationnel sera donc le suivant
Filire : TSSSRI
La table fait apparatre une personne et ses coordonnes autant de fois quelle possde un vhicule. Pagnol Pagnol 7/7/89 21/4/90 76.45.34.34 76.45.34.34 554FG22 667TG22 Volvo Peugeot 245 305 8 6 blanc gris
Si Mr Pagnol change de N de tlphone, il faut sassurer que la mise jour seffectue bien sur les deux enregistrements le concernant. Une autre redondance est lie la correspondance Marque, Type, CV Durand Duval 10/2/88 15/8/90 23.32.32.23 78.25.68.52 3344RF45 129DR75 Renault Renault R25 R25 9 9 bleu blanc
Pour chaque propritaire ayant une R25, il faudra saisir la marque et la puissance. De plus, un mme vhicule peut passer entre les mains de plusieurs propritaires. Il faudra alors saisir toutes ces caractristiques lorsquil changera de mains. Solution Les champs que nous trouvons dans cette table sont les attributs dentits diffrentes. Nous allons rattacher ses attributs aux entits quils caractrisent Nom et Numro de tlphone caractrisent lentit PROPRIETAIRE Numro dimmatriculation, Marque, Type et Couleur caractrisent lentit VEHICULE Marque et Puissance caractrisent lentit TYPE. Lentit PROPRIETAIRE et lentit VEHICULE sont lies par la notion de Possession. La relation est matrialise par le verbe Possder : En effet, un propritaire possde un ou plusieurs vhicules. Mais, un mme vhicule pourra avoir t possd par plusieurs propritaires successifs. Nous avons donc entre ces deux entits une relation de plusieurs plusieurs. Lattribut Date dachat ne caractrise pas lune des entits mises en vidences ci-dessus. Par contre elle caractrise le moment ou le propritaire va possder le vhicule. Lentit VEHICULE et lentit TYPE seront lies par la notion dappartenance. La relation est matrialise par le verbe Appartenir. En effet un vhicule appartient un TYPE et un seul.
Page 20/91
PROPRIETAIRE Possde
VEHICULES TYPE
Numro
Appartien
La relation entre la table PROPRIETAIRES et la table VEHICULES est matrialise par la table POSSEDE. Celle-ci a comme attributs les deux cls primaires des deux tables et le champ Date dachat, point de dpart de la possession du vhicule. La relation entre la table VEHICULES et la table TYPES ne ncessite pas la cration dune table intermdiaire puisquil sagit dune relation de un plusieurs de la table TYPES vers la table VEHICULES.
Filire : TSSSRI
PARTIE 4 CREATION ET MANIPULATION DES BASES DE DONNEE AVEC MS ACCESS I Cration des tables
La table est Le principal organe de stockage de donnes d'ACCESS. Pour qu'une base de donnes Access existe, il faut au moins une table. Il peut bien videmment y en avoir plusieurs. Les tables servent emmagasiner les donnes stables (quand on dit donnes stables, cela veut dire que leur structure est stable ; par exemple une table clients contiendra toujours des noms, des adresses, etc. et ces lments se retrouveront un emplacement dtermin). La table ressemble physiquement une feuille de calcul Excel : il y a des colonnes, qui prennent ici le nom de champs et des lignes qu'on appelle enregistrements. Crer une table, c'est d'abord dcider de sa structure c'est--dire quels champs il faut crer et quel sera leur type de contenu (alphabtique, numrique, etc.) Exemple de fichier clients (exemple de gestion dun club de loisir) Champs (colonnes)
Enregistrements (lignes)
Chaque ligne contiendra les coordonnes dun client (On saisira ces donnes plus tard)