IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Access: Apprendre à normaliser les champs multi-valués
Un tutoriel de Denis Hulo

Le , par User

1PARTAGES

17  0 
Bonjour,

Les champs multivalués permettent d'afficher directement dans les tables, les requêtes ou les formulaires, des listes de choix avec des cases à cocher pour sélectionner des données provenant d'une autre source :



Cependant, comme ces champs peuvent contenir plusieurs valeurs pour un même enregistrement, ils ne répondent pas à la première forme normale de la théorie de la normalisation, nécessaire pour concevoir un bon schéma d'une base de données.

Leur utilisation dans les requêtes comme dans le code peut ainsi sembler déroutante et ils peuvent par la suite compliquer le développement et la maintenance de la base Access.

Comme on le constate sur le forum Access, les intervenants qui ont souvent tendance par commodité à utiliser ce type de champ, rencontrent ensuite des difficultés liées à ces choix.

J'ai donc pensé qu'il serait utile de montrer comment implémenter une fonction permettant d'extraire les valeurs contenues dans ce type de champ pour les enregistrer dans une table intermédiaire permettant de faire le lien entre la table principale et celle qui alimente le champ multivalué :

Normaliser les tables contenant des champs multivalués


Résultat après normalisation et mise en relation des tables :



Bonne lecture !

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de loufab
Rédacteur/Modérateur https://www.developpez.com
Le 14/11/2022 à 13:43
Bonjour,

"Champ multivalués" ou comment normaliser les UAG.

En bref c'est le truc bricolopipo réservé à ceux qui n'y comprennent rien et qui ne veulent/peuvent pas apprendre.

Entre ça et le PJ on se trimbale un paquet de dette technique dans certaines applis d'utilisateurs.

Cordialement,
2  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 19/05/2023 à 17:36
Bonsoir User,

Citation Envoyé par User
Je suis un peu rassuré même si je ne suis pas sûr d'avoir bien saisi toutes les subtilités


Soyez rassuré. Le sérieux que vous apportez dans votre travail très utile est tout à fait remarquable. Si vous avez un peu de temps à consacrer à l’étude, je vous conseille – si ce n’est déjà fait – de vous plonger dans Looping de Patrick Bergougnoux (Paprick chez DVP), ainsi qu’éplucher Database Design and Relational Theory - Normal Forms and All That Jazz.

En tout cas, bonne route !

François
2  0 
Avatar de micniv
Expert confirmé https://www.developpez.com
Le 14/11/2022 à 10:04
Bonjour Denis,

Tuto très utile et bien conçu. Merci !

Peut-être faudrait-il insister davantage sur le fait qu'utiliser des colonnes multivaluées n'est pas recommandé et même à proscrire !
Depuis 15 ans, je gère moi-même mes colonnes multivaluée grâce à une listView et en enregistrant les différentes valeurs dans un champ texte, séparées par un caractère approprié.
Bien sûr cela nécessite un peu de VBA mais on ne perd pas dans une logique bricolo sans issue.
1  0 
Avatar de User
Rédacteur/Modérateur https://www.developpez.com
Le 14/11/2022 à 18:35
Citation Envoyé par loufab Voir le message
Bonjour,

"Champ multivalués" ou comment normaliser les UAG.

En bref c'est le truc bricolopipo réservé à ceux qui n'y comprennent rien et qui ne veulent/peuvent pas apprendre.

Entre ça et le PJ on se trimbale un paquet de dette technique dans certaines applis d'utilisateurs.

Cordialement,
si après ça ils n'ont pas compris
1  0 
Avatar de loufab
Rédacteur/Modérateur https://www.developpez.com
Le 29/11/2022 à 15:21
Bonjour -Animabis-,

Un temps je me suis dit qu'un message stérile emmènerai forcément une réponse stérile, mais pour le bien de la communauté voici mon point de vue technique. Entre autre...

Tout d'abord ceux qui me connaissent savent que je ne range personne dans des cases. Si ils y sont c'est qu'ils s'y placent d'eux-mêmes.

Je vais donc tenter d'être le plus précis possible pour éviter le moindre doute, interprétation et surtout raccourci gratuit.

Concernant les "veulent/peuvent pas".
Le vocable "débiles" que tu associes aux "peuvent pas" n'engage que toi. Pour moi les "peuvent pas" sont simplement des utilisateurs qui ont besoin d'être guidés vers les bonnes pratiques. Le chemin peut être long, difficile, obscur mais si ils ont la volonté de s'informer et de progresser, ils y arriveront. Il y a assez de tutos et de bénévoles sur Developpez qui vulgarisent les méthodes. Tout l’intérêt de ce forum en somme.

Avec les "veulent pas" c'est tout à fait différent. Ils ont élevé le "Quick & Dirty" en véritable art de la programmation et créent des "Usines à Gaz" (L'UAG n'est pas que côté IHM, on le retrouve aussi côté code, comme base de données) en passant s'économiser du temps... D'ailleurs certains poussent l'économie de temps à faire faire leur boulot par la communauté (si si ça existe - il y a même des salariés dans le lot) A noter que les "peuvent pas" sont déjà à la recherche de la signification de "Quick & Dirty" alors que les "veulent pas" souhaitent qu'on se transforme en Docteur-es-tartine (google est ton ami Docteur-es-tartine).

Ce que tu affirmes ici est tout à fait louable et j'y souscris totalement :
...on est pas un crack des bases de données mais on a un but et on cherche des solutions...
Et même ceci quand on se sent "peuvent pas" :
...et de prime abord un champs multivalué semnle pas mal...
Donc oui ça semble pas mal mais jusqu'à un certain point. D'abord l'insert et la rédaction des requêtes en général (cf le tuto de 2016 de Christophe Warin https://warin.developpez.com/access/...sererValeurSQL - Google "champ multivalué" la première ligne) puis le fait d'utiliser un composant spécifique d'un moteur de base de données, quel qu'il soit, rend captif de celui-ci.
Microsoft Access n'est pas une base de données ! Si cela te semble obscur je donne le lien : http://blogaccess.free.fr/?p=354

Mais choisir le multivalué pour les raisons suivantes c'est dommage :
...ça évite la création d'une table et surtout ça peut très facilement être remplie avec une liste sous forme de case à cocher...
...J'aimerais éviter que ce soit une purge à remplir...
2 tables, un formulaire en mode continu et on ne laisse pas une belle enclume pour ceux qui viendront après.

Les PJ :
Comme toujours les "peuvent pas" ont déjà trouvé la signification de ce mot barbare (sinon c'est Google >> Ms Access PJ).
Avec les PJ non seulement on se rend captif du moteur ACE (bigre ! comme le champ multivalué ?!), mais on prend des risques avec des fichiers de données qui peuvent rapidement dépasser les 2 Go (pour ceux qui pensent que scinder les bases est un solution, arrêtez de penser à court terme !). Mais c'est vrai que là aussi "ça semble pas mal" et "ça évite" de perdre du temps à faire un truc propre, perenne, sécure et portable et si on est pas regardant sur ce qui n'est pas documenté explicitement. Ce problème n'est pas nouveau, il y a une très large littérature sur le sujet depuis son introduction et ce n'est pas propre à ACE (Google>>> Ms Access ACE -1er lien non commercial) tous les moteurs de bdd posent des warnings sur le sujet.

Tout ce qu'il faut retenir c'est que choisir la facilité (PJ, Champ Multi) a toujours un prix. User et en abuser n'est pas un crime. Quand on en fait le choix délibérément il faut le faire en connaissance de cause et surtout ne pas s'étonner des limitations ou se vexer quand se voit opposer, à juste titre, que c'est un truc bricolopipo pour les "peuvent/veulent pas". D'ailleurs si ce n'est pas le cas, à quoi peu bien servir ce tuto ? La réponse est dedans : https://denishulo.developpez.com/tut...ser-tables/#LI ou encore celui-ci https://denishulo.developpez.com/tut...s-a-plusieurs/ qui y figure en lien.

Pour conclure je pense que le "Quick & Dirty" semble avoir de beau jour devant lui et contribue d'enfoncer toujours plus loin Ms Access dans sa mauvaise réputation.

Cordialement,
PS : Ceci n'est que mon avis, je n'oblige personne à y souscrire ni d'ailleurs à en faire une interprétation ou faire des raccourcis.
(Humour, Second degrés mais également premier sont présents dans cette non-réponse )
1  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 21/03/2023 à 2:47
Bonsoir User,

Citation Envoyé par User
comme ces champs peuvent contenir plusieurs valeurs pour un même enregistrement, ils ne répondent pas à la première forme normale de la théorie de la normalisation, nécessaire pour concevoir un bon schéma d'une base de données.


Vous avez évidemment parfaitement raison de faire évoluer la structure de la table initiale, T_Examen, présentée dans votre 1er post, pour aboutir aux trois tables, T_Examen, T_Candidat, T_Inscription_Examen.

Une remarque toutefois : la table initiale T_Examen respecte la première forme normale (1NF) !

En effet, selon la théorie relationnelle, la valeur de l’attribut Inscrits est celui d’une une RVA (Relation Valued Attribute) et T_Examen une relvar (variable relationnelle).

La 1NF n’impose aucune limitation quant aux types des attributs, donc le type Relation est légal.

Cela peut paraître surprenant, mais je vous renvoie aux ouvrages de C. J. Date, compagnon d’armes de E.F. Codd :

Relational DATABASE, Writings 1991-1994, au chapitre 8,

Database Design and Relational Theory Normal Forms and All That Jazz (Apress. 2019).

Dans cet ouvrage, la 1NF est définie de façon très rigoureuse :

Let relation r have attributes A1, ..., An, of types T1, ..., Tn, respectively. Then r is in first normal form (1NF) if and only if, for all tuples t appearing in r, the value of attribute Ai in t is of type Ti (i = 1, ..., n).

Attention, une relation est bien ici une valeur de relvar.

Accessoirement, en 2008, j’avais pondu pour developpez.com un article : Bases de données relationnelles et normalisation : de la première à la sixième forme normale, article dans lequel j’évoque les RVA et bien sûr l’évolution de cette chère 1NF.

Désolé pour le dérangement...
1  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 13/05/2023 à 16:01
Bonjour User,

Pardonnez-moi d’abuser de votre patience... Vous avez bien entendu tout à fait raison d’insister sur la normalisation des tables (ou plutôt des relations dans le cadre de la théorie relationnelle). Eu égard à la théorie, j’apporte quelques précisions à propos de la première forme normale (1NF), quitte à redonder avec ce que j’ai écrit dans mon précédent message (post #11).  

Au vu de l’attribut Inscrits de la table T_Examen (cf. le post #1), vous êtes en phase avec E.F. Codd - père de la théorie relationnelle - pour qui cette table viole la 1NF. Je rappelle à ce propos la définition qu’il en donna en 1971 (cf. [Codd1971], page 31) :

A relation is in first normal form if it has the property that none of its domains has elements which are themselves sets.


Codd précise ce qu’est une relation (cf. [Codd1969], [Codd1970]) :  

The term relation is used here in its accepted mathematical sense. Given sets S1,S2, ..., Sn (not necessarily distinct), R is a relation on these n sets if it is a set of n-tuples each of which has its first element from S1, its second element from S2, and so on. We shall refer to Sj as the jth domain of R.


Ainsi, une relation est bien un ensemble, et Jeff Ullman ([Ullman1982] page 235) conclut que « relation » et « relation en 1NF » sont synonymes, donc autant faire l’économie du qualificatif « 1NF » : Ullman passe à juste titre un coup de rasoir d’Ockham. Il est en phase avec C. J. Date, qui dans son dictionnaire relationnel [Date2015] écrit ceci (je traduis) :

« Par définition, toutes les variables relationnelles sont en première forme normale, 1NF. Appliqués à une variable relationnelle les termes 1NF et normalisée veulent dire la même chose.


En passant, une variable relationnelle (relvar) est une variable dont les valeurs sont des relations.

Quant à la table SQL (cf. [Date2019], page 69), elle doit respecter les contraintes suivantes pour mériter le label relation :

  •  elle ne doit pas contenir de lignes en double (ce qui est garanti par la déclaration d’une clé primaire, sinon la table n’est qu’un sac (bag)) ;
  •  les colonnes n’ont pas à être ordonnées (sous-entendu de gauche à droite) ;
  •  les lignes n’ont pas à être ordonnées (sous-entendu de haut en bas) ;
  •  les colonnes sont régulières, ce qui veut dire ceci :
     (a)  chaque colonne a un nom et deux colonnes de la table ne doivent pas avoir le même nom,
     (b)  une colonne ne peut être « cachée » :
           =>   Il ne peut y avoir d’identifiants autres que les clés déclarées, donc pas de row id, d’object id et timestamps cachés,
     (c)  le bonhomme NULL n’a pas sa place dans le Relationland, les colonnes doivent donc être déclarées NOT NULL.

Il faut observer que Chris Date, collègue et compagnon de route dès l’origine de Codd, et qui est la référence en ce qui concerne la théorie de la normalisation, donne la définition suivante de la 1NF (cf. [Date2019], page 66), je traduis :

Soit la relation r dont les attributs A1, ..., An, sont respectivement du type T1, ..., Tn. Alors r est en première forme normale (1NF) si et seulement si, pour tous les tuples t de r, la valeur de l’attribut Ai dans t est du type Ti (i = 1, ..., n).


Le type d’un attribut peut être le type RELATION et cet attribut prend alors des valeurs qui sont des relations (RVA).

Il va de soi que Date décrit les opérateurs permettant de replier/déplier les relations (Group/Ungroup), sans violer la 1NF. Mais il insiste sur le fait qu’au stade de la modélisation, il faut éviter les RVA (cf. [Date2019], page 67), ce qui veut dire que vous êtes toujours en phase avec lui quand vous recommandez d’« exploser façon puzzle »  la table T_Examen, même si selon les définitions de Date, cette table T_Examen est en 1NF, alors qu’elle ne l’est pas pour Codd... 

Date dit bien que cela ne pose pas de problème que des résultats contiennent des RVA, mais, bis repetita, qu’il faut toujours éviter celles-ci dans la modélisation des données, par exemple sous forme de hiérarchies, comme cela se passe avec IMS, SGBD amiral d’IBM des années 70-80 (pour avoir beaucoup utilisé IMS, je plaide un peu coupable , tout en ayant usé de tous les moyens techniques possibles pour respecter la symétrie, mais ceci est une autre histoire...) En effet, de par leur nature asymétrique, les modèles hiérarchiques forcent à complexifier bien des requêtes a priori simples (cf. [Date2012] page 295). Pour l’anecdote, afin qu’en ces temps lointains IMS ne soit pas pénalisé, Date avait été contraint par IBM (chez qui il émargeait) d’attendre 1975 ans avant d’être autorisé à publier son fameux An Introduction to Database Systems, écrit en 1972 (cf. [Haigh2007], pages 17-18).

---------------------------

[Codd1969] Derivability, Redundancy and Consistency of Relations Stored in Large Data Banks.

[Codd1970] A Relational Model for Large Shared Data Banks.

[Codd1971] Further Normalization of the Data Base Relational Model.

[Date2012] Date on Database Writings 2000-2006.

[Date2015] The New Relational Database Dictionary.

[Date2019] Database Design and Relational Theory Normal Forms and All That Jazz.

[Haigh2007] Oral History of C. J. Date.

[Ullman1982] Principles of Database Systems Second Edition (Computer Science Press. 1982
1  0 
Avatar de -Animabis-
Futur Membre du Club https://www.developpez.com
Le 13/11/2022 à 12:48
Bonjour,

Confronté à ces champs multivaleurs, j'ai sauté de joie en voyant ce tuto (je m’apprêtais à lancé un SOS sur le forum sur ce sujet), merci !

Cependant s'il permet de repartir sur quelque chose de propre, le problème auquel un champ multivaleur aurait pu apporter une solution reste là.
Comme beaucoup de novice Access ayant à gérer la configuration typique de l'exemple donné, le vrai problème est la saisie de la correspondance id_Exam-id_Candidat pour l'utilisateur, problème dont les solutions (évidentes au débutant) sont:

-Faire plein de champs id_Candidat dans la table Examen et passer par autant de liste dans le formulaire pour la correspondance, on voit de suite qu'on a de grandes chances d'avoir des champs vides (galère pour les requêtes), pas assez de champs, et un formulaire ignoble...

-Un champ candidat multivaleur, facile à remplir avec une liste choix multiple, s'adapte par essence au nombre de candidat, bref génial. Seulement on se rend compte que Insert To ne marche pas pour remplir ce champ et quand on creuse le pourquoi on voit des termes tel que "abomination", "hérésie" ou "contre-nature" sur les champs multivaleurs que l'on fini par comprendre.

-Une table jonction qui semble être la bonne pratique, comme dans l'exemple de ce tuto, mais comment la remplir par formulaire ? A ce jour, je ne vois qu'une liste à choix multiple sur les id_candidat traitée par VBA pour alimenter la table jonction, là le problème sera solutionné. Je pense que les manipulations d'objets de ton code vont beaucoup m'aider (je suis plutôt Excel, les objets Access c'est autre chose) pour y arriver. Je partagerais le code si j'arrive à quelque chose de probant.

Merci pour ce tuto !
0  0 
Avatar de User
Rédacteur/Modérateur https://www.developpez.com
Le 13/11/2022 à 18:54
Bonjour et merci,

Concernant la saisie des correspondances dans la table intermédiaire, je vous donne quelques liens pour faciliter la mise en place de ces formulaire/sous-formulaire de saisie basés sur une relation plusieurs-à-plusieurs (avec une table intermédiaire comme source du sous-formulaire) :

Relation plusieurs-à-plusieurs

Quelques discussions sur le même sujet :

https://www.developpez.net/forums/d2126431/logiciels/microsoft-office/access/aide-application-suivi-intervention/
https://www.developpez.net/forums/d2123698/logiciels/microsoft-office/access/formulaire-base-relation-plusieurs-plusieurs/

Cordialement.
0  0 
Avatar de -Animabis-
Futur Membre du Club https://www.developpez.com
Le 13/11/2022 à 20:21
Hello !

Merci beaucoup, je zieute ça de suite !

Cordialement,
0  0