Conception requêtes

Table des matières

Conception requêtes

L’objectif de ce document est d’expliquer la logique derrière la conception d’une requête.

Logique des requêtes

Qu’est-ce qu’une table ?

GEEF s’appuie sur une base de données relationnelle. Il s’agit d’un ensemble de données structuré sous la forme de « tables ». Une table est avant tout la description des données qu’elle contient. Une table est constituée de champs, ces champs peuvent être de plusieurs types (chaînes de caractères, entiers, réels, booléens, etc…) et avoir des contraintes/fonctions associées (clé primaire, clé étrangère, « null » admis).

Types de données ?

Entier : nombre composé de chiffres de 0 à 9, sans partie décimale. La majorité des clés primaires (et par conséquent étrangères) sont des entiers positives auto-incrémentés par le système (exception majeure : les matricules des carrières).

Réel : nombre composé de chiffres de 0 à 9 avec une partie décimale. La virgule est flottante dans GEEF mais les données de ce type sont généralement arrondies à deux chiffres après la virgule. Aucune clé n’est enregistrée en type « réel » dans GEEF.

Chaîne de caractère : ensemble de caractères (A-Z, a-z, 0-9, ponctuations, accentués, caractères spéciaux) organisés dans un ordre défini par l’utilisateur. Les libellés et noms sont stockés sous cette forme. Exception particulière : certaines chaînes très longues sont stockées dans des types de données appelés « texte » (ou CLOB pour « Character Long Object »).

Booléen : notion basique de « vrai » ou « faux » stocké sous la forme d’un entier simple (1 pour « vrai » ou 0 pour « faux » dans GEEF).

Dates : stockées sous la forme « AAAA-MM-JJ » par convenance technique, mais affichées sous la forme « JJ/MM/AAAA ». Les heures sont généralement stockées dans des chaînes de caractères sous la forme « HH:MM » (parfois en type « réel »).

« NULL » : lorsqu’un champ est laissé vide, cette pseudo-valeur « vide » est indiquée dans la ligne de données.

Contraintes et clés ?

La base d’une base de données « relationnelle » est de permettre des relations entre les tables : des champs sont ainsi définis comme « clé primaire », c’est-à-dire qu’ils permettent la distinction unique d’une ligne de données dans la table, et parfois utilisés comme « clé étrangère », c’est-à-dire que le champ fait référence au champ d’une autre table. En toute logique, une clé primaire ne peut jamais être « vide » (ou « NULL ») et une clé étrangère fait toujours référence à une clé primaire. Une clé étrangère peut être « vide » (ou « NULL ») dans le cas où la table « fille » ne fait référence à aucune donnée de la table « mère ». Dans le cas où la clé étrangère est renseignée, elle doit impérativement faire référence à une valeur existante dans la table mère.

N°Utilisateur (dernière modification)

La majorité des tables (à une ou deux exceptions près) de GEEF contiennent deux champs d’audit « N°Utilisateur (dernière modification) » et « Date de dernière modification ». Le champ « N°Utilisateur (dernière modification) » ne doit pas faire partie d’une jointure à moins que vous ne recherchiez l’utilisateur ayant modifié en dernière une ligne de données.

Vulgarisation

Une table peut être considérée comme une feuille de données Excel (ou Calc) dans laquelle un seul tableau de données est représenté avec un en-tête identifiant les noms des champs (colonnes) :

Agents :

Chaque ligne de données est appelée « n-uplet » (triplet, quadruplet, quintuplet… n-uplet). Chaque ligne est gérée par le système en fonction de son implémentation technique (chaînage, tableau…). Nous n’entrerons pas dans ces détails.

Les « clés primaires » sont, par convention, soulignées dans les modèles de données ; les « clés étrangères » sont, par convention, marquées avec le symbole dièse (#).

Carrières :

Sur l’exemple ci-dessus, la ligne dont le matricule carrière est « P00001 » est liée par le N°Agent à l’agent « Martin DUPONT ». Cette jointure doit être explicite dans les requêtes car le système, bien que connaissant les règles, n’est pas à même de décider si telle ou telle jointure doit être opérée lorsque plusieurs possibilités sont offertes.

Jointures et produit cartésien ?

Dans le requêteur, les jointures sont effectuées par l’entremise d’une opération appelée « produit cartésien » : les données de chaque table sélectionnée sont mises bout à bout et répétées pour chaque n-uplet de toutes les autres tables. En prenant l’exemple de deux tables ci-dessus, si on sélectionne une fois chaque table sans appliquer de jointure, on obtiendra un tableau de résultat de 8 lignes :

Cet exemple parait illogique, et il l’est. Il faut indiquer au système les lignes à retenir grâce aux « jointures ». La jointure à appliquer dans cet exemple est « N°Agent (A) = N°Agent (B) » :

Si l’utilisateur avait sélectionné en plus la table « Statut » qui contient 3 n-uplets, le résultat aurait contenu 24 lignes (3 statuts x 2 agents x 4 carrières). En prenant une collectivité de 500 agents avec 1500 carrières sur 4 statuts, le système brasse un total de 3 000 000 (3 millions) de lignes rien que pour ces 3 tables. Il est donc très important de bien faire les jointures de manière intelligente et de ne pas en oublier. Une règle « simple » mais admettant de nombreuse exception est que chaque table doit être reliée à au moins une autre table par une jointure et que deux tables ne doivent (généralement) pas être reliée par l’intermédiaire d’une table s’il existe déjà une jointure directe entre elles (exception faite des « N°Utilisateur (dernière modification) ».

Un schéma est généralement utile pour éviter les doubles (voir triples) liaisons :

Dans ce schéma exemple, la flèche rouge semble à proscrire (voir exemple en formation).

Des fonctions d’agrégations

Les fonctions d’agrégations utilisent des regroupements qui sont toujours effectués par rapport aux autres champs sélectionnés. Il est dont important de ne pas sélectionner trop de champs ou de ne pas sélectionner un champ clé primaire sur une table pour laquelle on souhaite compter les données. Exemple :

Tables :
- GRH : Agents
Champs :
- Nombre de – N°Agent
- Nom
- Prénom

Cette requête donnera le nombre d’agents regroupés par nom et prénom (autrement dit, les homonymes !)

Tables : a. GRH : Agents b. GRH : Carrières des agents
Champs :

a. N°Agent (A) b. Nom (A) c. Prénom (A) d. Nombre de – Matricule (B)
Conditions : a. N°Agent (A) = N°Agent (B)

Cette requête donnera le nombre de carrière par agent (autrement dit « 1 » si l’agent n’a qu’un statut et « 2 » s’il est double statut).

Traductions

Cet écran permet de lister et de modifier les traductions disponibles dans l’application. Les traductions concernent les noms techniques des tables et champs de l’application ainsi que certains mots clés. Les traductions sont utilisées dans le requêteur, ainsi que dans la plupart des libellés affichés dans l’application.

Pour rechercher une traduction, saisir un libellé technique et/ou un libellé traduit puis cliquer sur le bouton “Rechercher”.

Autres actions

Traductions absentes

Les traductions absentes en standard sont automatiquement remplacées par « Err. Trad. ». Vous pouvez corriger des « Err. Trad. » une par une ou utiliser le bouton « Importer » dans l’écran « Outils > Optimisation BD » pour les supprimer et remplacer par le standard.

Modification en direct

La case à cocher “modification en direct” permet de modifier le libellé d’un champ directement à l’écran lors de la navigation. Cocher cette case puis naviguer dans l’application. Lorsqu’un libellé doit être changé, cliquer sur le bouton droit de la souris avec le pointeur sur le libellé pour obtenir une fenêtre de modification en direct. Saisir le nouveau libellé puis cliquer sur “OK” pour valider la modification. Attention : une traduction peut être utilisée dans plusieurs écrans. Pour désactiver la modification en direct, il est possible de faire “Annuler” puis “OK” au second message de confirmation.