Discussion :

[Oppenheimer]

Bonjour!

Excusez-moi, je n'ai donné de nouvelles depuis un moment; j'ai eu un petit pépin de santé, mais c'est réglé.

Je vous écris, car j'ai un problème Access (2016).
J'ai pour but de créer une solution de bibliothèque - que j'espère pouvoir transposer sur Filemaker que je connais un peu moins - pouvant gérer tous les cas de figure. Ma structure, en une trentaine de tables, est vraisemblablement en D/KNF afin de minimiser les redondances, Access ne gérant manifestement pas 6NF.
Seul problème, même si je saisis dans quel ordre remplir les tables (d'abord celles de cardinalité 1, puis 1 à plusieurs, et enfin celles qui n'ont que des cardinalités de plusieurs), je ne pourrais sans doute pas demander au futur gérant de bibliothèque d'assimiler cette logique, même si elle paraît simple.
-J'ai donc tout de suite pensé aux formulaires. J'avais appris à créer un formulaire par table, ce qui est évidemment inutile - tout l'intérêt du formulaire étant de pouvoir remplir au moins deux tables.
Je me suis rappelé que j'avais à l'époque créé une base de journaux de travaux, que je pouvais classer par personne ou par titre de tâche, mais je ne me souviens plus comment j'avais fait cela - sinon grâce à une option "Grouper" en plus de filtre (qui sélectionne) et tri (qui ordonne).
Mais j'ai cherché. j'ai essayé d'exploiter la méthode de sous-formulaire. Après tout, je me dis que le modèle relationnel est équivalent à un modèle hiérarchique dont les dossiers vides sont simplement sans existence.
Mais je n'ai de possibilité que de mettre un seul sous-formulaire... qui apparaît comme une table. Alors que chaque table affiche ses implications (grâce au petit bouton "+" à gauche de l'enregistrement), celles-ci n'apparaissent pas dans le sous-formulaire, rendant ainsi le sous-formulaire caduc. Concrètement, si j'ai 4 tables entre ma cardinalité 1 et mes cardinalités plusieurs, j'aimerais pouvoir afficher 3 sous-formulaires imbriqués en plus du formulaire "racine".

--J'aimerais donc savoir si c'est vraiment impossible, ou s'il y a une solution de contournement pour pouvoir permettre à l'utilisateur d'entrer toutes ses données nécessaires dans toutes les tables.

-Vous trouverez en pièces jointes, mon schéma en Pdf, ainsi que des captures d'onglets.

-D'avance un grand merci pour vos réponses.

P. S.:
Sur pourquoi cette structure: J'avais fait un premier jet. Mais la première collection à répertorier:

• n'avait pas d'ISBN,
• avait 2 éditeurs,
• avait le 7ème volume en 2 tomes - ce pourquoi j'ai dû distinguer ces entités.

[loufab]

Bonjour,

En effet certaine approche sont difficiles à mettre en œuvre avec les IHM.

Cependant cela en me semble pas impossible. J'ai eu à mettre en œuvre le fameux cas d'un Abonné/inscription-contrat/versement dans un seul formulaire.
La méthode fonctionne parfaitement et est surement perfectible.

Voici une copie d'écran :

[Oppenheimer]

Bonjour Loufab,

Merci d'avoir répondu. Excusez-moi, je n'ai pas vu de suite la réponse (plus Pâques).

Nous parlons donc bien de Access... Pourrais-je bénéficier du schéma de données ? car je ne réalise pas vraiment quel schéma vous avez réussi à satisfaire avec vos données.

À vue de nez, je dirais 1 inscription pour 1 abonné, et plusieurs virements par abonnés (en principes annuels) ?

-L'inscription identifiant l'abonné, je ne suis pas vraiment avancé: En terme de sémantique, les deux étant identifiés (selon ma compréhension), c'est comme si vous aviez lié 2 tables (virements et abonné), ce que le sous-formulaire doit permettre.

Ma question est pour 3 tables et plus, sans relation d'identification (hormis peut-être ma table des comptes identifiant les personnes, que j'ai isolée, au cas où les comptes étaient sur le server, ce qui sera surement le cas, auquel cas on pourrait les supprimer de mon modèle Access).

[loufab]

Bonjour,

En effet, Jet ne sait pas faire autre chose que du 6NF.

Par mon exemple je te proposait d'arriver à mettre plusieurs sous-formulaire dans un, avec des liaisons entre sous-formulaire et non en cascades comme on le pratique habituellement. Car dans ce cas la barrière c'est l'affichage continu (pas de sous-form dans un form en continu).

Voici le mcd :


Jusque là pas de problème. Le seul bémol est d'arriver à présenter dans un même formulaire plusieurs contenu (sous-form) en continu.

Ici nous avons 1 adhérent qui est inscrit à plusieurs Contrats (je ne l'ai pas représenté car inutile pour le problème qui nous occupe) via la table Inscriptions (0 à n) et pour chaque inscription des versements (0 à n).

Si tu penses que l'astuce peut te convenir, fais-le moi savoir, je te la communiquerais avec plaisir.

Cordialement,

[fsmrel]

Bonsoir,


Oppenheimer,

Au sujet de cette discussion : J’ai cherché à vous joindre par M.P., mais votre boîte de réception est pleine.

Quoi qu’il en soit, avec loufab vous êtes en très bonne compagnie !

[Oppenheimer]

Bonsoir,


Oppenheimer,

Au sujet de cette discussion : J’ai cherché à vous joindre par M.P., mais votre boîte de réception est pleine.

Quoi qu’il en soit, avec loufab vous êtes en très bonne compagnie !

Merci Fsmrel pour votre retour!

-J'ai libéré de l'espace au cas où. Merci encore pour votre réponse.

[Oppenheimer]

Bonjour Loufab,

Merci pour votre réponse.

Bonjour,

En effet, Jet ne sait pas faire autre chose que du 6NF.

Jet? -Voulez-vous dire: je ? -Mais Access ne gère pas les intervalles, il me semble, donc son niveau de normalisation maximum est D/KNF ?

Par mon exemple je te proposait d'arriver à mettre plusieurs sous-formulaire dans un, avec des liaisons entre sous-formulaire et non en cascades comme on le pratique habituellement. Car dans ce cas la barrière c'est l'affichage continu (pas de sous-form dans un form en continu).

Voici le mcd :


Jusque là pas de problème. Le seul bémol est d'arriver à présenter dans un même formulaire plusieurs contenu (sous-form) en continu.

Ici nous avons 1 adhérent qui est inscrit à plusieurs Contrats (je ne l'ai pas représenté car inutile pour le problème qui nous occupe) via la table Inscriptions (0 à n) et pour chaque inscription des versements (0 à n).

Si tu penses que l'astuce peut te convenir, fais-le moi savoir, je te la communiquerais avec plaisir.

Cordialement,

Mmm.., je pense qu'elle peut me convenir. J'ai parlé à un informaticien de gestion. Il m'a parlé de champs cachés, et de FKs à clé sélectionnable dans une liste, mais ça restait abstrait - du coup j'opte pour votre solution, qui la rejoindra certainement.

Je vais encore essayer de corriger mes clés de t_pret_exemplaire, ou t_localite_rue, en enlevant cet "ID" qui m'insupporte, car je souhaite composer les FKs en PK, (il me semble que j'avais eu un problème - mais ça devrait aller).

Aussi, pour le contexte, je souhaite éviter les PK à numéro automatique, pour pas que ça fasse des trous en cas de suppression d'enregistrement. En fait, je souhaite avoir main mise sur les PKs, en les mettant comme attributs naturels, de sorte que la base puisse me dire avec certitude l'instance que je considère à partir d'une PK, et que celle-ci soit explicite.

Pour revenir à votre solution, il semble que votre schéma implique unidirectionnellement plusieurs enregistrements par deux fois, alors que mon schéma comprend des circularités, qui ne me gênent pas outre mesure, si ce n'est que j'ai quand-même ajouté t_responsable et t_auteur en plus de t_personne (les emprunteurs), car si je liais t_personne à elles-mêmes, que j'enregistrais, fermais, et revenais, t_personne était dédoublée, bien que j'avais coché l'intégrité référentielle.

En me réjouissant de vous lire à nouveau. Merci encore.

[loufab]

Jet est le nom du Sgbd intégré à Access. Access est un RAD qui peut s'accommoder de la plupart des SGBDs du marché au travers d'ODBC notamment.

Voici la solution :

L'inscription est liée via les propriétés Champs père et Champs fils de son container. Les deux contiennent Id_adherent. Celui coté tAdhérent et l'autre de tInsciption. Liaison tout à fait classique donc.

L'astuce vient pour le second. Pour le mettre en œuvre il faut créer une zone de texte, qu'il faudra mettre invisible à terme, car là pour la gestion et non destinée à l'utilisateur. Nommer cette zone de texte Id_inscription et la placer dans le formulaire (adherent). Cette zone n'a pas et ne peut avoir de source car il n'y a pas de colonne de ce nom dans la table tAdherent.

Cette zone de texte va servir de pont entre tInscription et tVersement.

Dans le container de sous-form Versement on met les propriétés Champs père et Champs fils à la valeur id_inscription. Coté Adhérent c'est notre zone de texte vide et sans source, par contre coté versement c'est la vrai colonne id_inscription.
Maintenant reste à valoriser la zone de texte pour que le tout fonctionne.

Dans le sous-formulaire Inscription, créer la fonction VBA suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Public Sub pMAJId_Inscription()
'---------------------------------------------------------------------------------------
' Procedure : pMAJId_Inscription
' Author    : Fabrice CONSTANS (MVP)
' Date      : 15/03/2016
' Purpose   : Si un contrat est sélectionné :
'             - on copie sont N° dans le controle de liaison du form parent
'             - on fait un requery des 2 sf Versement et Produit
'             -
' Parameters:
' Return    :
'---------------------------------------------------------------------------------------
'
10    On Error GoTo Errsub
 
20        If Not IsNull(Me.Id_inscription) Then
30           Me.Parent.Id_inscription = Me.Id_inscription
40           Me.Parent.Controls("sfVersement").Requery
60        End If
 
70    Exit Sub
 
Errsub:
80    If Err.Number = 440 Or Err.Number = 2455 Then
90       Exit Sub
100   End If
110   MsgBox Err.Description & vbCrLf & Err.Number
120   Resume Next
End Sub

La ligne 30 affecte le Id_inscription dans notre zone de texte.
La ligne 40 fait un requery du sous-form Versement.

il suffit ensuite de faire appel à cette fonction dans l'évènements Sur activation.

ça à l'air complexe comme ça mais en fait ce n'est que la création d'un pont entre 2 sous-formulaire à l'aide d'une zone de texte cachée.

Cordialement,

[loufab]

il me semble, donc son niveau de normalisation maximum est D/KNF ?

Probablement, tu es mieux placé que moi

[Oppenheimer]

Merci Loufab,

et je vois que vous n'avez pas oublié ma deuxième question!

Je ne sais pas si je vais trouvez l'opportunité de tester avant une semaine; je mettrai certainement la discussion en résolu avant de la tester, sachant que vous êtes le seul à m'avoir fourni cette solution.

Au pire, si j'éprouve des problèmes lors des tests, j'invaliderai l'option "résolu"; juste un petit truc pour me rassurer: Est-ce que votre solution marche pour les tables de liaison que j'ai insérées pour éviter les relations potentiellement "plusieurs-à-plusieurs", je pense à t_localite_rue qui ne devrait ne contenir que des FKs (composées en PK) ?

[loufab]

Je ne vois rien qui puisse empêcher de l'utiliser avec une table plusieurs-à-plusieurs. N'hésites pas à revenir vers moi si tu as des difficultés.

[Oppenheimer]

Merci beaucoup Loufab,

Je vais essayer de tester cela ce week-end. En fait, je vais reproduire vos 3 tables et y associer un formulaire. Ce sera beaucoup plus vite testé ainsi, et cela me permettra d'assimiler la méthode. À bientôt !