[base] Affichage dans un formulaire

[PYS]

Bonjour

Lucien RUBEMPRE wrote:

La seule chose est que la solution proposée semble encore imparfaite,

Mon but n'était pas de t'apporter une solution parfaite (je n'aurais pas
cette prétention...) mais de répondre à Hugues qui demandait :

Hugues Bousquet wrote:

Si l'un d'entre vous peut me mettre sur la voie...

Pour donner davantage de précisions quant à ce qui a été proposé :
- Ajouter un champ "ref_membre" dans ta table enfant est incorrect pour le
modèle car, comme le montre l'exemple développé par Bernard sur cette base,
cela ne permet de saisir qu'un membre par enfant (sauf à dupliquer
complètement l'enregistrement enfant).
- Par ailleurs, le formulaire créé sur cette base ne met pas à jour la table
"relation" dont on se demande à quoi elle sert désormais...
- La gestion "par défaut' d'une seule barre de défilement des
enregistrements permet d'alléger l'interface mais elle est souvent, en
effet, incomprise : on pense naviguer dans le formulaire alors qu'on est
dans le sous-formulaire (ou vice-versa). Ceci peut se résoudre facilement
par l'inclusion de barre de navigations propres à chacun (cf. exemple
complété... qui ne se veut pas encore une solution... parfaite...).
- L'ajout d'enregistrements à la table de référence peut se gérer par clic
sur un bouton comme dans l'exemple joint (sans macro : simplement par un
appel d'url).

http://nabble.documentfoundation.org/file/n3462925/Membres.odb Membres.odb

Cordialement
Pierre-Yves

[ribotb]

Bonjour

Lucien RUBEMPRE wrote:

La seule chose est que la solution proposée semble encore imparfaite,

Mon but n'était pas de t'apporter une solution parfaite (je n'aurais pas
cette prétention...) mais de répondre à Hugues qui demandait :

Hugues Bousquet wrote:

Si l'un d'entre vous peut me mettre sur la voie...

Pour donner davantage de précisions quant à ce qui a été proposé :
- Ajouter un champ "ref_membre" dans ta table enfant est incorrect pour le
modèle car, comme le montre l'exemple développé par Bernard sur cette base,
cela ne permet de saisir qu'un membre par enfant (sauf à dupliquer
complètement l'enregistrement enfant).
- Par ailleurs, le formulaire créé sur cette base ne met pas à jour la table
"relation" dont on se demande à quoi elle sert désormais...
- La gestion "par défaut' d'une seule barre de défilement des
enregistrements permet d'alléger l'interface mais elle est souvent, en
effet, incomprise : on pense naviguer dans le formulaire alors qu'on est
dans le sous-formulaire (ou vice-versa). Ceci peut se résoudre facilement
par l'inclusion de barre de navigations propres à chacun (cf. exemple
complété... qui ne se veut pas encore une solution... parfaite...).
- L'ajout d'enregistrements à la table de référence peut se gérer par clic
sur un bouton comme dans l'exemple joint (sans macro : simplement par un
appel d'url).

http://nabble.documentfoundation.org/file/n3462925/Membres.odb Membres.odb

Cordialement
Pierre-Yves

--
View this message in context: http://nabble.documentfoundation.org/base-Affichage-dans-un-formulaire-tp3457087p3462925.html
Sent from the Users mailing list archive at Nabble.com.

Bonjour Pierre-Yves,

cela ne permet de saisir qu'un membre par enfant (sauf à dupliquer
complètement l'enregistrement enfant).

C'est pour cela que j'ai proposé un modèle "dénormalisé" en ajoutant dans la table "enfants" un autre champ pour un second parent (on peut se le permettre car le nombre de parents est fini et prévisible).

le formulaire créé sur cette base ne met pas à jour la table
"relation" dont on se demande à quoi elle sert désormais...

Je ne l'utilise pas et effectivement pour moi,elle ne sert pas.

inclusion de barre de navigations propres à chacun [formulaire]

Entièrement d'accord. Le formulaire doit être amélioré (c'est un formulaire que j'ai créé "vite fait" avec l'assistant")

L'ajout d'enregistrements à la table de référence peut se gérer par clic
sur un bouton

Oui, c'est comme ça que je fais dans mes formulaires sauf que j'utilise une macro Encore une belle amélioration !

Bernard

[jfn]

Biologiquement un enfant n'a que deux parents. Ou alors la cigogne s'est gourée (encore bourrée celle-là [cf Gottlib)

Juridiquement aussi.

[andriant.sandy]

Certes mais je peux affirmer d'expérience que les nouveaux compagnons des parents séparés peuvent éventuellement venir chercher les beaux-enfants.

Cordialement,
Sandy-Pascal Andriant
Coordinateur de UPT-Paléographie

[Lucien_RUBEMPRE]

/Le 29/10/2011 08:31, pierre-yves samyn a écrit

/Pour donner davantage de précisions quant à ce qui a été proposé :
- Ajouter un champ "ref_membre" dans ta table enfant est incorrect pour le
modèle car, comme le montre l'exemple développé par Bernard sur cette base,
cela ne permet de saisir qu'un membre par enfant (sauf à dupliquer
complètement l'enregistrement enfant)./

Sans vouloir te contrarier, Pierre-Yves, je crois que tu oublies les précisions données par Hugues, dans sa question, au départ :

/
J'ai

   une table de membres (id_membre, nom, prénom, adresse)
   une table d'enfants (id_enfant, nom, prénom)
   une table relation_membre_enfants (id_relation, id_membre, id_enfant) /

Nous sommes ici dans le cas d'une relation plusieurs-à-plusieurs (qui justifie la présence de la table de liaison (table relation_membre_enfants).
Donc cette configuration permet bel et bien de saisir plusieurs membres par enfant, et inversement.
/

/- Par ailleurs, le formulaire créé sur cette base ne met pas à jour la table
"relation" dont on se demande à quoi elle sert désormais.../

Là je crois que tu mets le doigt sur une limitation de Base (presque assimilable à un bug (en tous cas au moins une amélioration souhaitable).
En effet, le propre des relations entre tables (la fameuse "mise à jour en cascade") ne semble pas respecté.
Personnellement, pour contourner cette difficulté, je me contente d'implanter un bouton qui déclenche l'ouverture d'un formulaire (pour la table de liaison) que je renseigne manuellement. Un peu comme dans ton exemple.

Bien cordialement à tous.

[PYS]

Bonjour Lucien

Lucien RUBEMPRE wrote:

Sans vouloir te contrarier, Pierre-Yves, je crois que tu oublies les
précisions données par Hugues

Sans vouloir te contrarier Lucien, je te suggère de relire mes propos et de
décortiquer mes exemples...

Je n'oublie pas les précisions de départ de Hugues et je maintiens que son
modèle est bon et qu'il ne doit pas être modifié pour obtenir le résultat.

Je ne mets en lumière aucune limitation de Base sur cette question ; les
limitations que j'évoque portent sur ta proposition d'ajouter un champ à la
table enfants. Proposition qui, en effet, débouche sur une mauvaise gestion
de la table relation.

J'en profite pour revenir sur :

Lucien RUBEMPRE wrote:

je n’utilisais pas le bon bouton. Il fallait prendre le bouton
"Actualiser" de la barre d'outils "Contrôles de formulaire". Là ça
fonctionne.
Par contre, notez bien le numéro de votre enregistrement. Car si vous en
avez plus de 10.000 (comme moi), ça vous ramène au début de la table.

Comme tu le verras dans mon exemple la barre d'outils de navigation dispose
d'un bouton "Rafraîchir le contrôle". C'est ce bouton qu'il faut utiliser...

Eléments de réflexion :
http://user.services.openoffice.org/fr/forum/viewtopic.php?f=29&t=6460

Cordialement
Pierre-Yves

[ribotb]

Bonjour Pierre-Yves,

De façon générale, il est préférable quelquefois, pour des raisons de simplification ou de performance par exemple, de "dénormaliser" le modèle. On n'est pas obligé de rester à tout prix en 3FN (3ème Forme Normale)

Bon dimanche à tous,

Bernard

[Francois_Gatto]

Bonjour,

je maintiens que son
modèle est bon et qu'il ne doit pas être modifié pour obtenir le
résultat.

Bonjour Pierre-Yves,

De façon générale, il est préférable quelquefois, pour des raisons de
simplification ou de performance par exemple, de "dénormaliser" le
modèle. On n'est pas obligé de rester à tout prix en 3FN (3ème Forme
Normale)

Avis non partagé, sauf cas très particuliers.
Ne pas prendre en compte la 3FN c'est à coup sûr générer des redondances et accroitre le risque en terme de maintenance des données.

Bon dimanche à tous,

Bon dimanche.

Bernard

François GATTO

[jfn]

Oui mais non. Les beaux-parents ne sont pas des parents...

Ce cas impose effectivement de revoir la structure de la base pour prévoir par exemple une liste de personnes autorisées (grands-parents, beaux parents, nounou, fils de la voisine...)

[ribotb]

Tiens ! Bonjour François.

Ça, c'est de la théorie.

Ayant travaillé pendant plusieurs années sur les bases de données relationnelles (Total Information System, DB2), je peux te dire qu'on a quelquefois intérêt à dénormaliser pour des raisons de simplification et de performance. De même qu'on va rarement au-delà de la 3FN bien qu'en théorie cela soit possible.

Dans le cas présent et conformément à cet usage (dénormalisation), compte tenu du fait que la redondance de l'attribut "parent" est maîtrisée (nombre d'occurrences prévisible et fini), on peut dénormaliser la relation.

Entre parenthèse et pour être tout à fait exact, dans le cas qui nous intéresse c'est en fait la 1FN que je proposais de dénormaliser.

Je viens de regarder mes archives : notre dernière discussion remonte à un an tout juste (nous n'étions pas tout à fait d'accord sur la typologie des jointures ).

A dans un an ?
Bernard

[Francois_Gatto]

Bonjour,

je maintiens que son
modèle est bon et qu'il ne doit pas être modifié pour obtenir le
résultat.

Bonjour Pierre-Yves,

De façon générale, il est préférable quelquefois, pour des raisons de
simplification ou de performance par exemple, de "dénormaliser" le
modèle. On n'est pas obligé de rester à tout prix en 3FN (3ème Forme
Normale)

Avis non partagé, sauf cas très particuliers.
Ne pas prendre en compte la 3FN c'est à coup sûr générer des
redondances et accroitre le risque en terme de maintenance des données.

Bon dimanche à tous,

Bon dimanche.

Bernard

François GATTO

Tiens ! Bonjour François.

Ça, c'est de la théorie.

Ayant travaillé pendant plusieurs années sur les bases de données
relationnelles (Total Information System, DB2), je peux te dire qu'on a
quelquefois intérêt à dénormaliser pour des raisons de simplification et
de performance. De même qu'on va rarement au-delà de la 3FN bien qu'en
théorie cela soit possible.

Dans le cas présent et conformément à cet usage (dénormalisation),
compte tenu du fait que la redondance de l'attribut "parent" est
maîtrisée (nombre d'occurrences prévisible et fini), on peut
dénormaliser la relation.

Entre parenthèse et pour être tout à fait exact, dans le cas qui nous
intéresse c'est en fait la 1FN que je proposais de dénormaliser.

Je viens de regarder mes archives : notre dernière discussion remonte à
un an tout juste (nous n'étions pas tout à fait d'accord sur la
typologie des jointures ).

C'est donc un anniversaire

A dans un an ?

Rendez-vous est pris !

Bernard

François GATTO

[Hugues_Bousquet_Prof]

Ne sachant trop après quel message il me serait le plus judicieux de répondre, j'ai choisi l'option de répondre au premier, c'est à dire au mien, pour être sûr de ne vexer personne...

Préambule étant fait, je tenais à vous remercier tous du temps que vous avez consacré à me répondre, voulais insister sur trois points :

    - le plus important à court terme, c'est qu'avec votre aide, j'ai
    réussi à obtenir un comportement de mon formulaire qui me sied,
    - j'ai découvert, toujours grâce à vos interventions des
    possibilités que j'ignorais et qui me seront certainement utilises
    prochainement,
    - je n'ai pas toujours compris l'intégralité de tous les messages,
    notamment ceux qui font référence à l'usage de la dénormalisation et
    de la 3FN, mais je vais insister...

Toujours est-il que j'étais bloqué et que vous m'avez débloqué, et en plus je me coucherai moins bête ce soir : rien que pour cela je vous remercie encore !

Hugues

[ribotb]

Pour faire simple :
- une relation [id_enfant, nom, prénom, id_membre(1), ... , id_membre(n ] est dite non normalisée à cause de la répétition d'un même attribut (id_membre);
- pour être en 1FN [*] les répétitions d'attributs doivent être éliminées de la relation qui devient [id_enfant, nom, prénom]; ce qui oblige à créer cette autre relation [id_relation, id_enfant, id_membre].

Lors du passage du modèle conceptuel des données au modèle logique, pour des raisons de simplification et de performance, on "s'autorise" dans certains cas à dénormaliser la 1FN, dans la mesure où le nombre de répétions de l'attribut est fixe et peu élevé (par exemple 2 : 2 membres tout au plus liés à 1 enfant).

[*] Il existe d'autres formes normales (2FN, 3FN, etc.) mais qui n'ont pas lieu d'être dans ton modèle.

En espérant que ça t'a un peu aidé... :-).

Bernard