Modèle

[khena]

J'ai fait un rapide modèle des tables et des relations. Sans cardinalité, difficile d'y voir plus clair. En plus, les "jointures" dans le where ne rendent pas la tâche de relecture plus facile. Evidemment, aucune norme n'est respectée (doublons des noms des champs dans la base, pas d'alias, etc.)

Une certaine structure se détache, si j'en crois une certaine logique du code :

• les champs avec le même préfixe que la table à laquelles ils appartiennent sont des attributs de la table ;
• les champs communs entre deux tables sont les clés étrangères > clés primaires (donc relation 0,n - 1,1)
• il faut réussir à relieer les relations 0,n-0,n là c'est pas gagné...

Ne peut-on pas se dispatcher les requêtes pour aller plus vite? Comment voulez-vous faire le retro-enginering sur la structure? en sql direct?

[jeantil]

il y a plein d'infos là https://t.co/CQhogzlevY

[jpotier]

J'ai ajouté dans src un fichier variables.txt reprenant les infos de https://t.co/CQhogzlevY

[inattendu]

J'ai aussi placé les infos sous forme de tableau dans le wiki.

[AxelVoitier]

La table a_rec reste un mystere pour moi. On pourrait supposer qu'elle contient les formations qu'un candidat demande, mais pas sur.

Pour les autres, a prioris (corrigez si c'est faux) :

• g_can : info sur les candidats
• i_ins : dossiers d'inscriptions
• a_voe : voeux des candidats

Y'a malheureusement pas tout (et meme peu) dans le fichier variable au final :(.

[Skrol29]

Si ça peut aider, voici ce qu'on peut déduire du code source :

[khena]

Comme c'est difficile de tous utiliser le même logiciel, je vous propose de compléter en sql le fichier structure avec les FK, noue ferons un reverse pour venir au modèle.

[jferard]

J'ai fait un script rapide qui isole les mots (et nombres) apparaissant dans le script apb.sql (https://gist.github.com/jferard/3b1f46a5af4cb535f7d30ca3d2f9bad9). Voici une version ramassée du résultat :

['', '0', '00001', '1', '10', '2', '21', '25', '26', '3', '4', '41', '45', '46', '5', '6', '7', '9', '999999', 'AND', 'BEGIN', 'BY', 'COMMIT', 'COUNT', 'CURSOR', 'DBMS_RANDOM', 'DECODE', 'DISTINCT', 'ELSE', 'END', 'EXCEPTION', 'EXCEPTION_INIT', 'EXISTS', 'FOR', 'FROM', 'FUNCTION', 'IF', 'IN', 'INSERT', 'INTO', 'IS', 'IS_prod', 'LOOP', 'MAJ_etat_classement', 'NOT', 'NO_DATA_FOUND', 'NULL', 'NUMBER', 'NVL', 'OR', 'ORDER', 'OTHERS', 'OUT', 'OWNER', 'PRAGMA', 'RETURN', 'ROLLBACK', 'ROWCOUNT', 'SELECT', 'SET', 'SQL', 'THEN', 'TO_CHAR', 'TYPE', 'UNION', 'UNIQUE_CONSTRAINT', 'UPDATE', 'VALUES', 'VARCHAR2', 'WHEN', 'WHERE', 'X', 'a_rec', 'a_ve_ord_aff', 'a_ve_ord_vg_rel', 'a_vg_ord', 'a_voe', 'all_catalog', 'c', 'c_can_grp', 'c_cg_ran', 'c_gp_cod', 'c_gp_eta_cla', 'c_gp_flg_cla_oto', 'c_gp_flg_sel', 'c_grp', 'c_ja_cod', 'c_jur_adm', 'c_rec', 'c_tj_cod', 'cg', 'class_aleatoire_autres_cddts', 'classement_aleatoire_efe', 'confirm', 'desc', 'dummy', 'dummy2', 'fr', 'g', 'g_Cn_Cod', 'g_aa_cod_bac_int', 'g_can', 'g_cn_cod', 'g_cn_flg_aefe', 'g_cn_flg_int_aca', 'g_ea_cod_ges', 'g_flh_sel', 'g_for', 'g_fr_cod', 'g_fr_cod_ins', 'g_fr_flg_sel', 'g_fr_reg_for', 'g_gf_cod', 'g_ic_cod', 'g_ta_cod', 'g_tg_cod', 'g_ti_cod', 'g_ti_flg_rec_idf', 'g_ti_flh_sel', 'g_tri_ins', 'gen_class_alea_V1_relatif_grp', 'gp', 'gp_eta_cla', 'i', 'i_ep_cod', 'i_ins', 'i_ip_cod', 'i_is_dip_val', 'i_is_val', 'indic', 'ja', 'l_c_gp_eta_cla', 'l_c_gp_flg_sel', 'l_c_ja_cod', 'l_c_tj_cod', 'l_g_ea_cod_ges', 'l_g_flh_sel', 'l_g_fr_reg_for', 'l_g_tg_cod', 'l_six_voe', 'login', 'mess_aff', 'mess_err', 'mode_dev', 'nip', 'niр', 'o_C_gp_cod', 'o_c_gp_cod', 'o_g_ea_cod_ins', 'o_g_tg_cod', 'o_g_ti_cod', 'pk_new_classement_commun', 'r', 'retour', 'saio', 'six_voeu_L1', 'sp_g_tri_ins', 'sqlcode', 'sqlerrm', 'ti', 'type_login', 'v', 'valid_classement_def', 'valid_classement_formation', 'value', 'Х']

On reconnaît d'abord les nombres, puis les mots-clés SQL (en majuscules). Ensuite,, on trouve les noms des tables et des champs, ainsi que ceux des fonctions, ou des variables utilisées par le script. On voit également deux erreurs de typo à corriger (o_C_gp_cod et g_Cn_Cod, je ferai un PR plus tard).

[jferard]

Structure de la base : à mon avis, d'après le nom, c_can_grp est la table de relation entre candidat (g_can) et groupe (c_grp), avec deux FK (logique) et (au moins) une propriété c_cg_ran, rang du candidat dans le groupe.

[khena]

Oui tout à fait, c'est ce que j'indiquais dans mon modèle au premier post. Essayons de remplir les champs de chaque table, on y verra plus clair

[jferard]

Pour info, voir #29. Il faudrait essayer de voir si ça colle.

[jferard]

Je pense qu'il faut continuer l'effort sur le fichier https://github.com/jeantil/admission_post_bac/blob/master/src/database.sql, afin de créer une structure minimale sur lequel le script peut fonctionner.

Pour la table a_rec, elle apparaît en lien avec g_tri_aff et g_tri_ins, dans le document sur l'établissement. Elle semble une table de relation entre ces deux tables, puisque sa clé primaire est composée de deux clés étrangères, les clés primaires de ces tables (g_tri_aff.g_ta_cod et g_tri_ins.g_ti_cod). Donc ce sont ces deux tables dont il faudrait comprendre le rôle.

[jferard]

Nouvelle version en PR. Je laisse ouvert pour commentaires éventuels.