[Résolu]états imbriqués, sous-états, sous-rapports , sql

Discussions sur le module de base de données Base et plus particulièrement sur le langage SQL ou sur les connexions aux SGBD tiers.
Les questions sur les macros doivent être postées dans la section dédiée en dessous.

Modérateur : Vilains modOOs

Règles du forum
Cette section est dédiée au module Base et plus particulièrement sur le langage SQL ou sur les connexions aux SGBD tiers. Vous ne devez pas poster ici de questions sur les macros mais utiliser la section éponyme.
Pour accélérer les réponses, vous pouvez mettre en ligne votre base en joignant un fichier ODB : comment faire.
Répondre
Avatar de l’utilisateur
martinbrait
InconditiOOnnel
InconditiOOnnel
Messages : 753
Inscription : 09 avr. 2013 09:15
Localisation : T'as pas dit bonjour, merci et à bientot !

[Résolu]états imbriqués, sous-états, sous-rapports , sql

Message par martinbrait »

Afin de produire un état, et en l'absence de sous-état avec liaison champ-maître -> champ-esclave,
me voilà parti à produire un sql de gourou :shock:

Je précise que ma construction sql "passe" via la console sql de libre office (outils/sql/commande à exécuter),
Je la sauvegarde comme sql, irrigant l'état depuis le navigateur de formulaire, et force l'enregistrement (message d'avertissement)

Bref, il suffit de forcer Instruction SQL, y coller une requête très élaborée,analyser l'instruction SQL = "oui".
Bien que ce genre de sql soit à la limite du lisible, ça produit le résultat attendu.
sqlNew.JPG

Code : Tout sélectionner

SELECT "t_e_personnel_per"."kt_matric_per", "t_e_personnel_per"."t_nomfam", "t_e_personnel_per"."t_prnomfam", "t_e_personnel_per"."d_naiss", "t_e_personnel_per"."m_obsrva", "t_j_notation_not"."kn_annot_not", "t_j_notation_not"."t_variation", "t_j_notation_not"."m_apprec", "t_j_notation_not"."n_notation" FROM "t_j_notation_not", "t_e_personnel_per" WHERE "t_j_notation_not"."kt_matric_per" = "t_e_personnel_per"."kt_matric_per" AND "t_j_notation_not"."kn_annot_not" = (SELECT "t_valeur" FROM "t_s_parametre_par" where "kt_clef_par" like 'AnMaxNot')-2
UNION
SELECT "t_e_personnel_per"."kt_matric_per", "t_e_personnel_per"."t_nomfam", "t_e_personnel_per"."t_prnomfam", "t_e_personnel_per"."d_naiss", "t_e_personnel_per"."m_obsrva", "t_j_notation_not"."kn_annot_not", "t_j_notation_not"."t_variation", "t_j_notation_not"."m_apprec", "t_j_notation_not"."n_notation" FROM "t_j_notation_not", "t_e_personnel_per" WHERE "t_j_notation_not"."kt_matric_per" = "t_e_personnel_per"."kt_matric_per" AND "t_j_notation_not"."kn_annot_not" = (SELECT "t_valeur" FROM "t_s_parametre_par" where "kt_clef_par" like 'AnMaxNot')-1
UNION
SELECT "t_e_personnel_per"."kt_matric_per", "t_e_personnel_per"."t_nomfam", "t_e_personnel_per"."t_prnomfam", "t_e_personnel_per"."d_naiss", "t_e_personnel_per"."m_obsrva", "t_j_notation_not"."kn_annot_not", "t_j_notation_not"."t_variation", "t_j_notation_not"."m_apprec", "t_j_notation_not"."n_notation" FROM "t_j_notation_not", "t_e_personnel_per" WHERE "t_j_notation_not"."kt_matric_per" = "t_e_personnel_per"."kt_matric_per" AND "t_j_notation_not"."kn_annot_not" = (SELECT "t_valeur" FROM "t_s_parametre_par" where "kt_clef_par" like 'AnMaxNot')

heritage_test.odb
(36.88 Kio) Téléchargé 125 fois
Connaissez-vous une meilleure façon de traiter vos états imbriqués ?
Existe-t-il un procédé moins amateur ?

Merci et à bientôt !
Dernière modification par martinbrait le 24 mai 2018 20:17, modifié 2 fois.
LibreOffice version 5.4.7.2.M6 (x64)
Windows 10
+
LibreOffice version 5.4.7.2.M6 (x64)
Windows 7

#HSQL Database Engine 1.8.0
version=1.8.0

Locale : fr-FR (fr_FR)

Obligation de version


Bonjour, merci et à bientôt !
Avatar de l’utilisateur
Dude
IdOOle de la suite
IdOOle de la suite
Messages : 25143
Inscription : 03 mars 2006 08:45
Localisation : 127.0.0.1
Contact :

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par Dude »

Je ne vois aucun intérêt pour la table t_h_per... dont la relation 1-1 est non conforme à la 3FN.
Tu t'éviteras ainsi une union inutile en SQL.

Si tu trouves une requête trop longue, sers toi des alias de table pour la rendre plus digeste.

NB : je t'invite à (re)lire le tutoriel sur la nomenclature.
Avatar de l’utilisateur
jeanmimi
Grand Maître de l'OOffice
Grand Maître de l'OOffice
Messages : 16955
Inscription : 03 mars 2006 17:02
Localisation : Venise verte

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par jeanmimi »

Bonjour,
Comme apparemment, toutes les données sont dans la même Table t_j_notation_not, cette Table peut servir pour les rapports.
Pièces jointes
heritage_test_v2.odb
(47.96 Kio) Téléchargé 104 fois
LibreOffice : Version : 24.2.1 (x64)(14 mars 2024)
Adoptium JRE ou Oracle JRE (x64), Windows 10, Thunderbird, Firefox
Avatar de l’utilisateur
martinbrait
InconditiOOnnel
InconditiOOnnel
Messages : 753
Inscription : 09 avr. 2013 09:15
Localisation : T'as pas dit bonjour, merci et à bientot !

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par martinbrait »

Bonjour Jeanmimi, Dude,

@Jeanmimi
En fait, il m'importe de voir des morceaux d'informations en provenance de plusieurs tables, dans le même rapport
(nom;prenom;observation)+(note2018,note2017,note2016)
sinon, ajouter une table dédiée, t_j_notations_not, devenant une table "de bricolage", n'ayant d'autre objectif que d'interfacer un rapport ?

@Dude
Même après le passage des normes (merci), ces requêtes sql, seront toujours hyperlongues, et mal fagotées, faute de disposer d'imbrications d'états.
Je vois un grand intérêt à ma table t_h_promouvables_prv,
  • t_h_promouvables_prv de relation 0/1-1, hérite de t_e_personnel_prs :
  • Mes personnels ne sont pas tous promouvables.
  • Mes promouvables sont toujours issus de la table des personnels
  • J'évite de laisser des champs dédiés aux promouvables,dans la table t_e_personnel_prs.
  • J'identifie mieux mes étapes métiers : personnel -> promouvables -> candidats -> promus, avec des champs particuliers à chaque étape.
Les tables à trous, non merci !!!
Dernière modification par martinbrait le 25 mai 2018 20:08, modifié 3 fois.
LibreOffice version 5.4.7.2.M6 (x64)
Windows 10
+
LibreOffice version 5.4.7.2.M6 (x64)
Windows 7

#HSQL Database Engine 1.8.0
version=1.8.0

Locale : fr-FR (fr_FR)

Obligation de version


Bonjour, merci et à bientôt !
Piaf
GourOOu
GourOOu
Messages : 5622
Inscription : 25 nov. 2011 19:07
Localisation : Guyane

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par Piaf »

Bonjour
martinbrait a écrit : héritage de la table t_e_personnel_prs, de relation 0-1 :
Nouveau type de relation :lol:
A+
Libre Office Version: 6.1.6 et Apache OpenOffice 4.1.6 Sur Xubuntu 18.04 AMD64
Avatar de l’utilisateur
jeanmimi
Grand Maître de l'OOffice
Grand Maître de l'OOffice
Messages : 16955
Inscription : 03 mars 2006 17:02
Localisation : Venise verte

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par jeanmimi »

martinbrait a écrit :En fait, il m'importe de voir des morceaux d'informations en provenance de plusieurs tables, dans le même rapport
(nom;prenom;observation)+(note2018,note2017,note2016)
Pour le faire, tu crées une Requête avec les renseignements que tu souhaites, puis tu t'en sers pour faire le Rapport.
Pièces jointes
heritage_test_v3.odb
(30.88 Kio) Téléchargé 108 fois
LibreOffice : Version : 24.2.1 (x64)(14 mars 2024)
Adoptium JRE ou Oracle JRE (x64), Windows 10, Thunderbird, Firefox
Avatar de l’utilisateur
martinbrait
InconditiOOnnel
InconditiOOnnel
Messages : 753
Inscription : 09 avr. 2013 09:15
Localisation : T'as pas dit bonjour, merci et à bientot !

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par martinbrait »

Hello, ravi de vous voir motivés par le sujet !

@Jeanmimi
Merci pour cette suggestion.
Je ne m'y retrouve pas dans ta proposition, car la requête produite ne respecte pas le lien 1 à plusieurs,
entre la table t_h_promouvable_prv et la table t_j_notation_not
Le rapport que je lis dans la version 3 est faux.

@Piaf !

En fait, je veux vraiment parler de l'héritage, en considérant que certains champs puissent vraiment concerner un workflow.
Il me semble préférable de rédiger un peu plus de jointures dans mes requêtes sql, quitte à les masquer par des vues le cas échéant.

Ca me semble bien étrange, au contraire, de concevoir des tables, avec des champs, qui auront vocation à être partiellement remplis !
Notamment, dans de tel cas, il me semble très important de les initialiser, et donc les remplir avec une valeur "faux",
afin de les identifier comme pas encore remplis, ou sinon de ne jamais oublier de tester le null, afin de différencier
une valeur jamais touchée, d'une valeur effacée par l'utilisateur.

En savoir plus à propos des héritages en base de données :
*ttps//warin.developpez.com/tutoriels/access/heritage-dans-base-donnees-access/
LibreOffice version 5.4.7.2.M6 (x64)
Windows 10
+
LibreOffice version 5.4.7.2.M6 (x64)
Windows 7

#HSQL Database Engine 1.8.0
version=1.8.0

Locale : fr-FR (fr_FR)

Obligation de version


Bonjour, merci et à bientôt !
Avatar de l’utilisateur
jeanmimi
Grand Maître de l'OOffice
Grand Maître de l'OOffice
Messages : 16955
Inscription : 03 mars 2006 17:02
Localisation : Venise verte

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par jeanmimi »

martinbrait a écrit :entre la table t_h_promouvable_prv et la table t_j_notation_not
La Requête est créée sur les Relations que tu as établies entre les Tables.
Pièces jointes
Relation.jpg
LibreOffice : Version : 24.2.1 (x64)(14 mars 2024)
Adoptium JRE ou Oracle JRE (x64), Windows 10, Thunderbird, Firefox
Avatar de l’utilisateur
martinbrait
InconditiOOnnel
InconditiOOnnel
Messages : 753
Inscription : 09 avr. 2013 09:15
Localisation : T'as pas dit bonjour, merci et à bientot !

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par martinbrait »

la clef primaire de la table personnel est matricule
la clef primaire de la table notation est matricule;annéenotation

Un matricule est lié à une notation,
en fonction d'une année particulière.
Mon sql tenait compte de cela en procédant à 2 unions dans la même requête.
Les regroupements de l'état masquaient les informations en doublon, du tupple.

Il s'agit de sortir 3 années différentes,
pour les années 2016, 2017, 2018,
pour le matricule considéré.

On constate que la requête de la base heritage_testV2 donne un résultat juste.

notation contient une clef composite !
A proprement parler, il s'agit d'une clef primaire et étrangère matricule composite :
-> année
-> matricule

Mon schéma relationnel est-il faux ??? :o
Y a t il moyen de sortir du bricolage approximatif, lors d'imbrications d'états, sous libre office ?
LibreOffice version 5.4.7.2.M6 (x64)
Windows 10
+
LibreOffice version 5.4.7.2.M6 (x64)
Windows 7

#HSQL Database Engine 1.8.0
version=1.8.0

Locale : fr-FR (fr_FR)

Obligation de version


Bonjour, merci et à bientôt !
Avatar de l’utilisateur
jeanmimi
Grand Maître de l'OOffice
Grand Maître de l'OOffice
Messages : 16955
Inscription : 03 mars 2006 17:02
Localisation : Venise verte

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par jeanmimi »

Dans cette version la Requête sélectionne les années 2016, 2017 et 2018 après avoir entré ces critères dans l'ébauche de requêtes.
J'ai créé de nouvelles Tables avec des ID en INTEGER AutoValeur comme clés primaires.
Pièces jointes
heritage_test_v4.odb
(23.72 Kio) Téléchargé 104 fois
LibreOffice : Version : 24.2.1 (x64)(14 mars 2024)
Adoptium JRE ou Oracle JRE (x64), Windows 10, Thunderbird, Firefox
Piaf
GourOOu
GourOOu
Messages : 5622
Inscription : 25 nov. 2011 19:07
Localisation : Guyane

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par Piaf »

Re
Relis ce que j'ai écris, je ne parle pas d'héritage mais de relation 0 à 1.
Au lieu de tes discours sur l'héritage, explique comment tu établis une relation 0 à 1.
Dude a écrit :Je ne vois aucun intérêt pour la table t_h_per... dont la relation 1-1 est non conforme à la 3FN.
qu'un personnel soit promouvable ou pas, il aura toujours une ancienneté professionnelle et une ancienneté dans le Show bizz.
tPers.png
Après pour la source de tes rapports, pourquoi ne pas créer directement tes requêtes et baser tes rapports dessus ?
La requête des promouvables.
Prom.png

Code : Tout sélectionner

SELECT CONCAT( CONCAT( "t_nomfam", ' ' ), "t_prnomfam" ) AS "Pers", "t_j_notation_not"."kn_annot_not" AS "Annees", "t_j_notation_not"."n_notation" AS "Notes", "t_j_notation_not"."t_variation" AS "Variations", "t_j_notation_not"."m_apprec" AS "Appreciations" FROM "t_j_notation_not", "t_e_personnel_per" WHERE "t_j_notation_not"."kt_matric_per" = "t_e_personnel_per"."kt_matric_per" AND "t_j_notation_not"."kn_annot_not" <= 2018 AND "t_j_notation_not"."kn_annot_not" >= 2016 AND "t_e_personnel_per"."Promouvable" = 'Oui' ORDER BY "Pers" ASC, "Annees" DESC
La requête All
All.png

Code : Tout sélectionner

SELECT CONCAT( CONCAT( "t_nomfam", ' ' ), "t_prnomfam" ) AS "Pers", "t_j_notation_not"."kn_annot_not" AS "Annees", "t_j_notation_not"."n_notation" AS "Notes", "t_j_notation_not"."t_variation" AS "Variation", "t_j_notation_not"."m_apprec" AS "Appreciations" FROM { oj "t_j_notation_not" RIGHT OUTER JOIN "t_e_personnel_per" ON "t_j_notation_not"."kt_matric_per" = "t_e_personnel_per"."kt_matric_per" } WHERE ( "t_j_notation_not"."kn_annot_not" <= 2018 AND "t_j_notation_not"."kn_annot_not" >= 2016 OR "t_j_notation_not"."kn_annot_not" IS NULL ) ORDER BY "Pers" ASC, "Annees" DESC
A+
Dernière modification par Piaf le 23 mai 2018 20:01, modifié 1 fois.
Libre Office Version: 6.1.6 et Apache OpenOffice 4.1.6 Sur Xubuntu 18.04 AMD64
Avatar de l’utilisateur
martinbrait
InconditiOOnnel
InconditiOOnnel
Messages : 753
Inscription : 09 avr. 2013 09:15
Localisation : T'as pas dit bonjour, merci et à bientot !

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par martinbrait »

Piaf a écrit :Re
Relis ce que j'ai écris, je ne parle pas d'héritage mais de relation 0 à 1.
Au lieu de tes discours sur l'héritage, explique comment tu établis une relation 0 à 1.
Dude a écrit :Je ne vois aucun intérêt pour la table t_h_per... dont la relation 1-1 est non conforme à la 3FN.
qu'un personnel soit promouvable ou pas, il aura toujours une ancienneté professionnelle et une ancienneté dans le Show bizz
Effectivement, par raccourci j'écris 0-1, pour évoquer la nature incomplète de la relation de généralisation/spécialisation.
Quel est le formalisme approprié ?

Dans ma situation, t_h_promouvable_prv est un héritage de personnel, car, à l'initialisation de mon jeu de personnels, je filtre d'abord sur la date de début de l'emploi (non évoquée dans ces tables), qui doit être supérieur à 3 ans.

Une fois ma population de promouvables établie, je laisse apparent les ancienneté professionnelles, et ancienneté dans le Show bizz, comme des critères qui me permettront de procéder à un classement des promouvables entre eux.

J'ai besoin de réutiliser ma table de personnel, sans indication d'ancienneté <>3 ans, pour inventorier toutes les identités de mes personnels, à réutiliser comme je l'entends dans un contexte de mutations, ou un contexte d'avancement. Avancement est la situation spécialisée pour laquelle je veux compter des anciennetés professionnelles et et des anciennetés showbiz.

Mes champs de calcul d'ancienneté sont établis pour servir uniquement à une gestion des promouvables. Je ne stocke pas cette précision (champ calculé) dans la table des personnels qui sont à la fois promouvables et non-promouvables.
Dernière modification par martinbrait le 24 mai 2018 19:48, modifié 1 fois.
LibreOffice version 5.4.7.2.M6 (x64)
Windows 10
+
LibreOffice version 5.4.7.2.M6 (x64)
Windows 7

#HSQL Database Engine 1.8.0
version=1.8.0

Locale : fr-FR (fr_FR)

Obligation de version


Bonjour, merci et à bientôt !
Piaf
GourOOu
GourOOu
Messages : 5622
Inscription : 25 nov. 2011 19:07
Localisation : Guyane

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par Piaf »

Re
Dans un premier temps Évite de citer que ce qui t'intéresses et répond aux questions que l'on te pose.
Ton raccourci est une aberration, comment établir une relation entre deux tables qui n'ont pas de champ en commun ? Le formalisme approprié tu le trouves dans la fenêtre des relations.
martinbrait a écrit : je filtre d'abord sur la date de début de l'emploi (non évoquée dans ces tables), qui doit être supérieur à 3 ans.
Merci de fournir une base exemple qui corresponde aux réponses que tu veux obtenir. Si le seul critère pour qu'un personnel soit promouvable est le nombre d'année d'ancienneté, il est facile de déterminer la valeur de promouvable.
Pour ce qui est des champs calculés, rien vu dans ta base exemple qui y ressemble.
martinbrait a écrit :]Je ne stocke pas cette précision (champ calculé) dans la table des personnels qui sont à la fois promouvables et non-promouvables.
Donc un personnel qui n'est pas promouvable n'a pas d'ancienneté ?
Après si ce que tu as fais correspond à tes besoins et que le seul problème est le SQL à rallonge, le mieux est de baliser le sujet comme Image[Résolu]
A+
Libre Office Version: 6.1.6 et Apache OpenOffice 4.1.6 Sur Xubuntu 18.04 AMD64
Avatar de l’utilisateur
martinbrait
InconditiOOnnel
InconditiOOnnel
Messages : 753
Inscription : 09 avr. 2013 09:15
Localisation : T'as pas dit bonjour, merci et à bientot !

Re: états imbriqués, sous-états, sous-rapports , sql à rallo

Message par martinbrait »

OK,
Merci Piaf, pour toutes ces réponses.
Piaf a écrit : qu'un personnel soit promouvable ou pas, il aura toujours une ancienneté professionnelle et une ancienneté dans le Show bizz.
Voici l'explication de mon modèle :
Qu'un personnel soit promouvable ou pas, il aura toujours une ancienneté professionnelle et une ancienneté dans le Show bizz.
C'est pas faux... mais
Lorsqu'un personnel n'est pas promouvable, je décide de ne jamais exploiter ses informations d'ancienneté professionnelle et d'ancienneté dans le Show bizz;
Lorsqu'un personnel est promouvable, je décide d'exploiter ses informations d'ancienneté professionnelle et d'ancienneté dans le Show bizz

Concernant la requête sql proposée, j'admet que le SQL proposé, est bien meilleur que celui que j'ai écrit : :super:

Code : Tout sélectionner

SELECT CONCAT( CONCAT( "t_nomfam", ' ' ), "t_prnomfam" ) AS "Pers", "t_j_notation_not"."kn_annot_not" AS "Annees", "t_j_notation_not"."n_notation" AS "Notes", "t_j_notation_not"."t_variation" AS "Variations", "t_j_notation_not"."m_apprec" AS "Appreciations" FROM "t_j_notation_not", "t_e_personnel_per" WHERE "t_j_notation_not"."kt_matric_per" = "t_e_personnel_per"."kt_matric_per" AND "t_j_notation_not"."kn_annot_not" <= 2018 AND "t_j_notation_not"."kn_annot_not" >= 2016 AND "t_e_personnel_per"."Promouvable" = 'Oui' ORDER BY "Pers" ASC, "Annees" DESC
'===========
Je concluerai en précisant, qu'à l'heure actuelle, base présente des défauts majeurs.
Développer des applications sous base, c'est faire en compliqué, ce qui se fait simplement sous access.
Ne perdez pas votre temps à y développer des bases :
  • pas de mode multiutilisateur, via le moteur hsql natif (des réglages savants permettent néanmoins de mettre hsql en mode serveur)
  • ergonomie déplorable des feuilles de navigation (difficulté d'adapter les dimensions, aux dimensions des écrans)
  • pas de logique d'imbrication entre les formulaires/sous-formulaires
  • pas de logique d'imbrication entre les états/sous-états.
  • mauvaise gestion de portée des variables.
  • Contrôles navigation de formulaire inexistants.
Bref, module base, à éviter, pour des applications professionnelles multiutilisateurs.
Eventuelle solution de dépannage, côté sql, pour croiser des contenus de tableau calc, après apprentissage du dialecte hsql.

Merci et à bientôt !
Dernière modification par martinbrait le 24 mai 2018 20:14, modifié 3 fois.
LibreOffice version 5.4.7.2.M6 (x64)
Windows 10
+
LibreOffice version 5.4.7.2.M6 (x64)
Windows 7

#HSQL Database Engine 1.8.0
version=1.8.0

Locale : fr-FR (fr_FR)

Obligation de version


Bonjour, merci et à bientôt !
Avatar de l’utilisateur
Dude
IdOOle de la suite
IdOOle de la suite
Messages : 25143
Inscription : 03 mars 2006 08:45
Localisation : 127.0.0.1
Contact :

Re: [Résolu]états imbriqués, sous-états, sous-rapports , sql

Message par Dude »

martinbrait a écrit :Je concluerai
Quand le forgeron est mauvais, il accuse son marteau.
Répondre