Règles de validité des saisies, exercice Access

Pour partager cette vidéo sur les réseaux sociaux ou sur un site, voici son url :


Sujets que vous pourriez aussi aimer :


Contrôles de validité, Exercice Access

Nous abordons le septième exercice Access. Et nous poursuivons les travaux chirurgicaux consistant à parfaitement configurer les tables de notre base de données. Ces réglages sont absolument essentiels. Les tables constituent l'ossature de la base de données. Tous les objets de l'application que nous bâtirons au fil de la progression, hériteront de leurs propriétés et comportements.

Dans les précédents exercices, nous avions soigneusement typé, dimensionné et formaté les champs de chacune des tables. Et dans le précédent volet, nous avons construit des règles permettant de contrôler la saisie de l'utilisateur au fil de la frappe. Ici, nous souhaitons aller encore plus loin en termes de sécurité et d'intégrité. Il s'agit de déclencher des règles de validité. Contrairement à un masque de saisie, ces contrôles s'opèrent à validation du champ.

Base de données source
A chaque étape, nous capitalisons et consolidons les travaux précédents. Il est donc nécessaire de commencer par réceptionner la base de données source, offerte au téléchargement depuis le site Bonbache.fr.

• Télécharger la base clients-et-commandes-regles-validite.accdb en cliquant sur son lien,
• Double cliquer sur le fichier téléchargé pour l'ouvrir dans Access,
• Ensuite, cliquer sur le bouton Activer le contenu du bandeau jaune de sécurité,

Nous retrouvons les six tables de notre base de données. Elles sont énumérées dans le volet des objets Access sur la gauche de l'écran. Pour l'instant, le nombre d'objets n'a effectivement pas encore évolué. Nous sommes toujours dans les opérations de configuration des tables.

• Dans le volet des objets Access, cliquer droit sur la table Clients,
• Dans le menu contextuel, choisir Mode création,
• Dans la vue en conception, sélectionner le champ Client_nom,

Nous avons soigneusement défini le type de données pour chacun des champs. Et pour le champ Client_nom par exemple, vous pouvez constater les réglages opérés sur sa taille, son format et son masque de saisie. Dans un autre exercice, nous avions même créé des listes déroulantes sur certains champs appropriés.

Désormais, nous souhaitons renforcer les contrôles de validité des informations saisies. C'est déjà ce que réalisent les masques de saisie. Mais nous l'avions expliqué, les masques de saisie ne peuvent pas s'adapter à tous les champs. Certains ne proposent en effet aucune règle d'écriture. Ces contrôles en aval vont donc nous permettre de sécuriser l'information, un peu plus encore. L'objectif avoué est de disposer d'une base de données propre, dans laquelle aucune information erronée n'a pu filtrer.

Règles de validité
Cette table Clients n'offre aucun champ numérique, si ce n'est la clé primaire, qui ne doit pas être contrôlée. Les vérifications demeurent assez basiques. La saisie d'un nom de famille, d'un prénom ou encore d'une ville, avec trop peu de caractères, peut paraître suspicieuse. Nous proposons d'interdire la validation lorsque ces champs proposent des données de moins de 4 caractères.

• Sélectionner le champ Client_nom,
• En bas de la fenêtre, cliquer dans la zone de sa propriété Valide si,
• Cliquer ensuite sur le petit bouton qui se propose à l'extrémité droite,

Nous déclenchons ainsi l'affichage du générateur d'expression d'Access.

• Dans la liste de gauche, déployer l'arborescence des fonctions,
• Puis, sélectionner l'élément Fonctions intégrées,
• Dans la liste du centre, sélectionner la catégorie Texte,
• Dans la liste de droite, double cliquer sur la fonction NbCar,

De fait, elle s'inscrit dans la partie supérieure du générateur d'expression. Elle permet de compter le nombre de caractères contenu dans un champ à lui indiquer en paramètre, à la place de la mention «string» donc.

• Remplacer cette mention par le nom du champ à contrôler, soit : [Client_nom],
• Puis, à la suite de la syntaxe, taper l'inégalité suivante : > 3, pour le critère à vérifier,
• Ensuite, cliquer sur le bouton Ok pour valider l'expression,

La syntaxe ainsi construite s'inscrit dans la propriété Valide si du champ Client_nom. La règle est limpide. Dans ce champ, la saisie est validée si le nombre de caractères tapés est supérieur à 3. Il est même possible de communiquer avec l'utilisateur. L'objectif est de le guider dans les corrections à apporter, en cas de données non conformes. Nous l'avons dit et nous le répèterons à chaque occasion, Access est le logiciel qui permet de bâtir des applications destinées aux professionnels.

• Juste en-dessous, dans la propriété Message si erreur, taper l'indication suivante : Un nom de famille doit proposer plus de 3 caractères,

• Enregistrer les modifications (CTRL + S),
• Valider par Oui, l'alerte Access sur les règles d'intégrité,

En effet, nous posons des contraintes sur des champs alors que des données sont déjà présentes. Access indique que ces nouvelles règles peuvent engager des pertes. Il n'en est rien bien sûr. Cette règle est destinée à contrôler les données après la saisie.

• Valider la nouvelle alerte qui suit, en cliquant sur le bouton Oui,

Access insiste. Il indique que les informations ne sont peut-être plus en conformité avec ces nouveaux paramétrages. Une fois encore, il n'en est rien.

• Dans le ruban contextuel Création, cliquer sur le bouton Affichage,

Nous basculons ainsi sur le contenu de la table Clients, en mode feuille de données. Les 34 enregistrements sont toujours bien présents.

• Atteindre la dernière ligne pour créer un nouvel enregistrement,
• Dans le champ Client_nom, taper seulement trois lettres : mar, par exemple,
• Puis, valider avec la touche Tab du clavier,

Comme vous le constatez, grâce à la règle de validité, cette information est jugée non conforme. Elle n'est pas acceptée. Et c'est notre message personnalisé, donc explicite, qui s'affiche.

• Cliquer sur le bouton Ok pour masquer l'alerte,
• Enfoncer la touche Echap du clavier pour annuler la saisie du nom,
• Sur cette nouvelle ligne, renseigner seulement le prénom : Julien, par exemple,
• Puis, cliquer sur la ligne du dessous pour valider l'enregistrement,

Comme vous le constatez et malgré tous nos paramétrages, rien n'empêche pour l'instant de valider des enregistrements complètement incohérents. Voilà typiquement le genre de données très incomplètes que nous ne souhaitons jamais voir alourdir notre base de données. Il n'est pas concevable de référencer un client seulement avec son prénom. Toutes les autres informations, hormis le prénom éventuellement, sont requises.

La règle de validité contrôle la conformité de la saisie. Mais si rien n'est écrit, elle ne se déclenche pas. Nous devons donc la combiner avec une sécurité complémentaire. Il s'agit d'une propriété n'autorisant pas de conserver le champ vierge (null en langage informatique).

• Supprimer le dernier enregistrement créé à titre de test,
• Dans le ruban Accueil, cliquer sur la flèche du bouton Affichage,
• Dans la liste, choisir Mode création,
• Dans la vue en conception, sélectionner de nouveau le champ Client_nom,
• Double cliquer dans la zone de sa propriété Null interdit, pour basculer sa valeur de non à oui,
• Enregistrer les modifications (CTRL + S) et valider l'alerte par Oui,
• Puis, cliquer sur le bouton Affichage dans le ruban Accueil,
• Sur la dernière ligne, taper un prénom dans le champ Client_prenom,
• Puis, cliquer sur la ligne du dessous pour valider le nouvel enregistrement,

Cette fois, la sécurité est sans appel. Aucun enregistrement pour lequel le nom n'est pas renseigné, n'est autorisé. Nous progressons dans la sécurité en vue de préserver l'intégrité de nos données. Nous devons étendre ces règles aux champs Client_ville et Client_dep. Concernant le second, seule la propriété null interdit doit être réglée. Son masque de saisie impose déjà d'inscrire nécessairement 5 chiffres.

• Valider l'alerte et enfoncer la touche Echap du clavier pour abandonner l'enregistrement,
• Puis, revenir en mode création de table,
• Dans la vue en conception, sélectionner le champ Client_dep,
• Puis, basculer sa propriété Null interdit sur oui,
• Sélectionner le champ Client_civilite,
• Basculer sa propriété Null interdit sur oui,
• Sélectionner le champ Client_ville,
• Dans sa propriété Valide si, taper l'expression adaptée à son champ : NbCar([Client_ville])>3,
• Dans la zone Message si erreur, taper une indication pour l'utilisateur, par exemple : Un nom de ville doit posséder au moins 4 lettres,
• Puis, basculer sa propriété Null interdit sur oui,
• Enregistrer les modifications,
• Confirmer toutes les alertes en cliquant sur le bouton Oui,
• Cliquer sur le bouton Affichage dans le ruban contextuel Création,
• Atteindre la dernière ligne pour créer un nouvel enregistrement,
• Choisir une civilité et taper un nom de plus de 3 lettres,
• Cliquer sur la ligne du dessous pour valider l'enregistrement,

Cette fois, c'est la sécurité posée sur les autres champs qui réagit. Un enregistrement ne peut pas être validé tant que les renseignements sur le code postal et la ville sont manquants. Le prénom n'est pas jugé indispensable en revanche. C'est pourquoi nous n'avons pas modifié sa propriété Null interdit.

Donc, si vous renseignez le code postal et la ville, la création de l'enregistrement est autorisée. Au fil de notre progression, les règles de sécurité posées sur notre base de données sont de plus en plus importantes. C'est le B.A-BA d'un gestionnaire de bases de données relationnelles afin de monter des applications professionnelles, sécurisant les données de l'entreprise.

• Cliquer sur la croix de l'onglet pour fermer la table Clients,
• Puis, afficher la table Produits en mode création,

Nous ignorons les tables Commandes, Communes et Detail_commandes. La table Communes est déjà complètement renseignée. Elle est vouée à être purgée de ses doublons lorsque nous saurons maîtriser les requêtes. Mais aucune ville supplémentaire ne sera ajoutée. Les tables Commandes et Detail_commandes doivent être renseignées par des actions automatisées. Nous le comprendrons lorsque nous aborderons les formulaires que nous ferons interagir avec les requêtes. Il n'est donc pas nécessaire d'ajouter des règles de sécurité consistant à contrôler la saisie de l'utilisateur.

Concernant la table Produits, tous les renseignements ou presque, doivent être fournis. La référence et le nom doivent être indiqués. Le prix et le poids sont nécessairement strictement positifs. Le stock ne peut pas être une valeur négative. Le champ produit_vues est une information statistique rendant compte du nombre de visites sur la fiche article. Nous pouvons l'ignorer. Le champ produit_code doit indiquer un numéro de promotion issu de la table Remises. Ce numéro est nécessairement compris entre 1 et 9.

• Dans la vue en conception, sélectionner tout d'abord le champ produit_ref,
• Dans sa propriété Valide si, taper l'expression suivante : NbCar([produit_ref])>5,
• Ajouter un message d'erreur : Une référence article doit proposer au moins 6 caractères,

Comme vous le constatez, sa propriété Null interdit est déjà réglée sur Oui. Il s'agit du champ de la clé primaire. Ce réglage est automatiquement lié. Une clé primaire est forcément renseignée.

• Sélectionner le champ produit_nom,
• Créer la même règle de validité adaptée au champ : NbCar([produit_nom])>5,
• Lui associer un message d'erreur : Une désignation doit comporter au moins 6 caractères,
• Puis, basculer sa propriété Null interdit sur Oui,
• Sélectionner maintenant le champ produit_prix,
• Inscrire la règle de validité suivante : >0,
• Lui associer un message d'erreur : Le prix doit être indiqué,
• Basculer sa propriété Null interdit sur Oui,
• Sélectionner le champ produit_poids,
• Créer sa règle de validité : >0,
• Adapter le message d'erreur : Le poids ne peut être nul,
• Puis, basculer sa propriété Null interdit sur Oui,
• Sélectionner le champ produit_stock,
• Créer sa règle de validité : >=0,
• Lui associer un alerte d'erreur : Un stock ne peut être négatif,
• Puis, basculer sa propriété Null interdit sur Oui,
• Sélectionner le champ produit_code,
• Créer sa règle de validité : Entre 1 Et 9,

L'opérateur Access Entre est la traduction de l'opérateur Between. Comme vous l'avez compris, il permet de définir les bornes dans lesquelles la valeur du champ doit se situer.

• Lui associer un message : Un code promotionnel est nécessairement compris entre 1 et 9,

Cette fois, nous ne modifions pas la propriété Null interdit. Les opérations promotionnelles se définissent sur des périodes précises. A sa création, un article n'est pas en promotion.

• Enfin, sélectionner le champ produit_vues,
• Régler sa propriété Valeur par défaut à 0,

Ainsi, nous initialisons le compteur de visite à chaque création de produit.

• Enregistrer les modifications et valider tous les messages d'alerte,
• Cliquer sur le bouton Affichage du ruban contextuel Création,
• Atteindre le tout dernier enregistrement et saisir un code article arbitraire,

Si vous validez l'enregistrement, Access vous en empêche. Le nom est premièrement requis. Le système est identique en cascade pour les autres champs. Si la désignation est trop courte, le champ est refusé. Si vous entrez un stock négatif, la règle de validité se déclenche, etc...



Si vous tapez un code promotionnel en dehors des bornes, la saisie est refusée. En revanche, si vous ne le renseignez pas, l'enregistrement est accepté. Bref, le comportement de la table Produits est fidèle à nos attentes. Une fois encore, l'intégration des données est parfaitement calibrée pour assurer des informations qualitatives et en cohérence.

Enfin, une dernière règle de validité peut être posée sur le champ remise_taux de la table Remises. Elle doit consister à vérifier que la remise accordée est bien supérieure ou égale à zéro. Tous les codes promotionnels sont déjà prévus dans cette table. Seuls les taux peuvent varier en fonction de la politique de la société.



Dans le prochain exercice, nous terminerons le paramétrage des champs de tables Access. Nous définirons quels champs doivent être indexés et pourquoi.