1 Initiation aux bases de données et à la programmation événementielle VBA sous ACCESS Cours N° 4 Support de cours rédigé par Bernard COFFIN Université Paris 10 – Nanterre2007/2008
2 Requête Définition générale : Commande permettant la manipulation d'informations à l'intérieur d'une base de données Le langage de manipulation d’une BD relationnelle est SQL Il existe plusieurs variétés de requêtes : sélection ajout suppression mise à jour création ACCESS parle de « types » de requêtes
3 Éviter les confusions Ne pas utiliser le même mot pour des choses différentes ni plusieurs mots pour la même chose La requête décrit un traitement (pas un ensemble de données) Le résultat de la requête de sélection est une relation La relation est liée à un objet qui permet de travailler sur ses éléments (les enregistrements eux-mêmes composés de champs)
4 Requête sélection Crée une nouvelle relation Ensemble ordonné d’enregistrements La requête est la source d’un objet : formulaire, état, zone de liste déroulante … mais aussi feuille de données C’est l’objet dont elle est la source qui permet de manipuler les données de la relation construite par la requête Tous les objets ne permettent pas les mêmes traitements Ne confondez pas avec la propriété « Source contrôle » qui établit un lien entre les propriétés « Valeur » d’un contrôle et d’un champ
5 Opérations de base (rappel) Une requête sélection réalise les opérations suivantes : 1.Produit cartésien 2.Projection 3.Restriction des relations dont le nom suit le mot clef From sur les champs dont le nom suit le mot clef Select aux enregistrements respectant la clause suivant le mot clef Where
6 Ordre de la relation Les enregistrements d’une relation sont ordonnés Par défaut, ce peut être l’ordre croissant d’une clef primaire Possibilité de contrôler cet ordre par la requête qui crée la relation Clause « Order By » suivie des clefs du tri dans l’ordre où elles sont prises en compte Préciser « Desc » pour un tri décroisant Select Nom, Prénom From Étudiant Order By Nom, Prénom Desc;
7 Déclenchement du calcul de la requête La requête est une chaîne de caractères qui décrit la relation qui doit être calculée Elle est soumise à un « moteur de recherche » qui l’analyse et fait le nécessaire pour obtenir la relation décrite Cela se produit lors des événements suivants : 1.Ouverture de l’objet dont la requête est la source (ou le contenu – zones de listes) 2.Affectation de la requête à la propriété source ou contenu de l’objet 3.Application de la méthode Requery de l’objet
8 Que devient la relation ? Les données de la relation sont disponibles 1.Jusqu’à la fermeture de l’objet auquel elle est liée (par la propriété Source ou Contenu de l’objet) 2.A moins qu’un événement ne déclenche la méthode Requery de cet objet 3.Ou bien qu’une affectation ne modifie la valeur de cette propriété
9 Mise à jour de la relation Les enregistrements contenus dans la relation sont ceux qui ont été construits au moment du calcul de la requête (en fonction de l’état de la BD à ce moment là) Auxquels il faut ajouter ceux créés par l’objet lié Mais pas ceux qui seraient construits avec des données ajoutées à la BD par d’autres objets depuis le calcul de la requête Et pas ceux qui ont été construits à partir de données supprimées par d’autres objets depuis le calcul de la requête Les valeurs des champs de la relation qui sont modifiées par d’autres objets sont mises à jour immédiatement
10 Exemple de l’application de ces principes sur deux formulaires utilisant la même requête en propriété « Source » Le cas est peu fréquent, mais on retrouve souvent le même problème avec un formulaire et une zone de liste déroulante L’exemple utilise une table dont le nom est Personne Liste des champs et propriétés de ces champs 1.[N° personne] – clef primaire déclarée NuméroAuto 2.Sexe – texte de 1 caractère ; valeur par défaut "M" ; valeurs autorisées " M" ou "F" 3.Nom – texte de 50 caractères 4.Prénom – texte de 50 caractères
11 Source du formulaire Tout_le_monde : Select * From Personne Order By Nom, Prénom ; Source du formulaire Filles : Select * From Personne Where Sexe = "F" Order By Nom, Prénom ;
12 Les deux formulaires ont été ouverts ensemble en mode « Formulaires continus » Ils sont construits à partir des mêmes données (l’état de la table Personne) au moment de leur ouverture La clause de restriction de la requête source du formulaire Filles est la raison de la différence des contenus Ces formulaires permettent d’ajouter des enregistrements à la table Personne (c’est toujours le cas pour des requêtes sources qui ne concernent qu’une seule table) Dans chaque formulaire, la dernière ligne permet de saisir les données d’un nouvel enregistrement Le caractère « M » dans le champ Sexe du nouvel enregistrement est sa valeur par défaut
13 On a ajouté un enregistrement sur le formulaire Filles Parce que les relations liées aux formulaires ont été calculées alors que la table ne contenait pas encore ces enregistrements puis un sur le formulaire Tout_le_monde : ils n’apparaissent pas dans l’autre formulaire
14 On a pu créer un enregistrement dont la valeur du champ sexe est "M" dans le formulaire Filles Parce que la clause de restriction « Where Sexe = "F" » n’est prise en compte qu’au moment du calcul de la relation (et pas en cas d’ajout d’enregistrement) De même les nouveaux enregistrements ne sont pas insérés à leur place dans l’ordre alphabétique des valeurs du champ Nom : la clause « Order By Nom, Prénom » n’est prise en compte qu’au moment du calcul de la relation En revanche si on essaye de taper un caractère autre que F ou M dans le champ Sexe, on obtient un message d’erreur parce que « Valide si » est une propriété de la table et est toujours en vigueur
15 Si on recalcule la relation liée au formulaire (en le fermant puis en le rouvrant, par exemple), on constate que les nouveaux enregistrements ont bien été enregistrés dans la table ; la clause de restriction et les critères de tri sont appliqués normalement aux calculs des nouvelles relations
16 Si on modifie la valeur d’un champ dans un formulaire, elle est modifiée dans la relation liée à l’autre formulaire … dès que la mise à jour a été effectuée dans la table (changement d’enregistrement actif)! On a changé le Nom, mais pas d’enregistrement actif
17 La suppression de l’enregistrement actif dans un formulaire le fait disparaître immédiatement (l’enregistrement {9, F, LEMAIRE, Béatrice} a été supprimé dans le formulaire Tout_le_monde en cliquant sur le bouton de commande ) De la même façon, les suppressions sont immédiatement répercutées dans l’ensemble des relations concernées
18 Champs calculés La projection n’est pas le seul moyen de définir les champs d’une relation construite par une requête On peut définir un nouveau champ (nouveau nom) et déterminer sa valeur au moyen d’une expression ; c’est un champ calculé Syntaxe : expression As nom_nouveau_champ On peut ne pas attribuer de nom au nouveau champ si on n’a pas besoin de s’y référer directement (possible pour des zones de listes déroulantes)
19 Premier exemple Comment disposer d’un champ dont la valeur soit la concaténation du Nom, d’un espace et du Prénom ? Select [Nom] & " " & [Prénom] As Identité From Personne ; Deuxième exemple Dans une table tabLigne_commande on a un champ [Quantité_commandée] et une clef externe [Réf produit] établissant un lien avec la table tabProduit ; dans la table tabProduit, dont la clef primaire est [N° produit] on dispose d’un champ [Nom produit] et un champ [Prix unitaire]. Comment décrire une relation où chaque enregistrement correspond à un enregistrement de la tabLigne_commande et comportant le nom du produit, la quantité commandée, le prix unitaire et le prix total ? Select [Nom produit], [Quantité commandée], [Prix unitaire], [Quantité commandée]*[Prix unitaire] As [Prix total] From tabLigne_commande, tabProduit Where [N° produit] = [Réf produit] ;