IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Modélisation de propriétés variables en nombre et en type [MCD]


Sujet :

Schéma

  1. #1
    Membre régulier
    Homme Profil pro
    Webmaster
    Inscrit en
    Septembre 2016
    Messages
    67
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : Distribution

    Informations forums :
    Inscription : Septembre 2016
    Messages : 67
    Points : 90
    Points
    90
    Par défaut Modélisation de propriétés variables en nombre et en type
    Bonsoir,

    Il y a quelques temps, j'avais lancé un sujet concernant la modélisation d'une base de données de gestion de spectres d'étoiles variables (ici).
    Le projet avance lentement mais surement. Une bonne partie est déjà fonctionnelle mais pas encore en ligne.

    Je dois implémenter les propriétés des spectres, cette fois-ci, et je ne sais pas trop comment m'y prendre.
    La liste des propriétés est en pièce jointe.

    Pour résumer :

    Il existe 2 types de spectres :
    - les spectres classiques
    - les spectres échelles

    1 - Une propriété peut être commune aux 2 types (comme la résolution, l'unité de longueur d'onde utilisée, etc.)
    2 - Une propriété peut être spécifique à un type de spectre (la racine de l'ordre d'un spectre échelle n'est valide que pour les spectres échelles, par exemple)
    3 - Une propriété possède une valeur d'un type donné (qui dépend de l'unité de la propriété)
    4 - Une propriété possède une valeur qui peut répondre à un format spécifique
    5 - Une propriété possède une valeur qui peut se situer dans un intervalle donné
    6 - Une propriété possède un caractère obligatoire ou facultatif

    La plupart de ces propriétés sont extraites d'un en-tête de fichier de spectre (un fichier au format FITS) qui associe un mot-clé (le nom de la propriété) à une valeur. (la valeur de la propriété) Les valeurs des propriétés sont ensuite vérifiées puis ventilées dans les différentes tables de la base ; certaines propriétés font l'objet de tables à part entière (l'observateur, le site d'observation, le télescope utilisé, etc.) tandis que d'autres ne sont que des champs que je dois mettre quelque part, associées au spectre (résolution spectrale, la correction ou non de la vitesse héliocentrique, etc.).

    Mon problème vient du fait que je m'arrache les cheveux pour modéliser.

    Est-ce que je mets les propriétés et leurs valeurs dans une relation dédiée ou est ce que je dois faire un système d'héritage (un spectre échelle hérite d'un spectre classique) ?
    Comment créer des propriétés sans que je me retrouve avec des NULL partout si la propriété n'a pas de valeur ?
    Si je créé une relation dédiée pour supprimer les valeurs NULL, comment créer des propriétés de différents types ?
    Comment associer une propriété à sa règle de formatage et d'intervalle ?

    J'ai fait de nombreux essais et aucun ne me satisfait.
    Merci de votre aide

    Vincent
    Images attachées Images attachées

  2. #2
    Membre régulier
    Homme Profil pro
    Webmaster
    Inscrit en
    Septembre 2016
    Messages
    67
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : Distribution

    Informations forums :
    Inscription : Septembre 2016
    Messages : 67
    Points : 90
    Points
    90
    Par défaut
    Voici les 2 essais qui me paraissaient les plus prometteurs en terme de modélisation :

    La version n°1 avec 3 relations :

    Nom : test1.jpg
Affichages : 1343
Taille : 130,4 Ko

    La version n°2 avec 2 relations seulement :

    Nom : test2.jpg
Affichages : 1211
Taille : 95,1 Ko

    Le gros souci est qu'aucune des deux n'est capable de gérer ni le type de la propriété (entier, date ou décimal), ni la contrainte de format qui dépend de ce type, ni la plage de valeurs tolérée qui dépend aussi du type.


    La version 3, avec un système d'héritage, me paraît peu crédible, même si elle règle le problème du type de la propriété. Les contraintes de format et d'intervalle de valeurs pourraient être réglées par des contraintes CHECK ou des déclencheurs :

    Nom : test3.jpg
Affichages : 1263
Taille : 89,4 Ko

    Dans ce modèle, il est difficile de modifier une propriété (la rendre obligatoire, par exemple, quoiqu'en la définissant comme NOT NULL on puisse le mimer, non sans problème) et la quantité de valeurs NULL devient énorme puisque bon nombre de propriétés sont facultatives ou conditionnelles.

    Bref, je sèche un peu...

    Vincent

  3. #3
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 130
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 130
    Points : 38 543
    Points
    38 543
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par aras-vbo Voir le message
    Bonsoir,

    Il y a quelques temps, j'avais lancé un sujet concernant la modélisation d'une base de données de gestion de spectres d'étoiles variables (ici).
    Oui je me souviens de ce sujet passionnant et présenté avec soin, j'espère que vous en viendrez à bout

    Pour la question de ce soir,
    - combien y a -t- il de propriétés communes aux deux types de spectre et combien sont spécifiques à chaque type
    - combien de ces propriétés sont obligatoires

  4. #4
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir,

    Sans doute avez-vous déjà répondu aux questions qui suivent, mais je n’ai fait que survoler votre discussion précédente.

    Dans le cadre de votre application, devez-vous prendre en compte l’ensemble des mots-clés figurant dans le tableau que vous nous avez transmis, ou bien ignorez-vous ceux qui ne concernent pas directement les spectres ? Par exemple, devez-vous impérativement prendre en compte le nom de l’astre (attribut OBJNAME), celui de l’observateur (attribut OBSERVER), l’instrument utilisé (attribut BSS-INST) ? Quels sont les mots-clés mis en jeu dans le cas des seuls spectres ?

    Avez-vous l’intention de mettre en œuvre une table MOT_CLE à partir de la structure du tableau ? Je dirai plutôt une métatable, car des attributs tels que format, unité, intervalle, se situent à un niveau d’abstraction supérieur.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  5. #5
    Membre régulier
    Homme Profil pro
    Webmaster
    Inscrit en
    Septembre 2016
    Messages
    67
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : Distribution

    Informations forums :
    Inscription : Septembre 2016
    Messages : 67
    Points : 90
    Points
    90
    Par défaut
    J'ai fait le ménage dans ces propriétés et filtré celles qui sont à implémenter dans la base.
    Pour simplifier, voici la liste des différentes propriétés que je dois intégrer dans mon modèle, avec leur nom, le type, le format, le motif (s'il existe), un exemple et le caractère obligatoire ou non.


    11 propriétés sont communes aux 2 types (spectre classique et spectre échelle) :

    CRVAL1 (double)
    intervalle de validité : 300-10000
    ex : 6233.45
    Obligatoire

    CDELT1 (double)
    intervalle : 0.0001-30
    ex : 0.116
    Obligatoire

    CRPIX1 (float)
    pas d'intervalle
    ex : 1.0
    Obligatoire

    CUNIT1 (char)
    valeurs possibles : angstrom ou nm
    ex : nm
    Obligatoire

    CTYPE1 (char)
    valeur possible (et par défaut) : wavelength
    ex : wavelength
    Obligatoire

    BSS_ESRP (double)
    intervalle : positif ou nul
    ex : 17000
    Facultatif

    BSS_BINN (char)
    pas d'intervalle, pas de format
    ex : Poor SNR, binned with fixed step of 5 nm
    Facultatif

    BSS_VHEL (float)
    intervalle : -200 à +200
    ex : -9.45
    Obligatoire

    BSS_TELL (char)
    Valeurs possibles : none / removed / method xx
    ex : none
    Obligatoire

    BSS_COSM (char)
    Valeurs possibles : none / removed / method xx
    ex : none
    Obligatoire

    BSS_NORM (char)
    Valeurs possibles : none / removed / method xx
    ex : none
    Obligatoire


    1 propriété est spécifique aux seuls spectres de type Echelle :

    BSS_ORD (char)
    Pas d'intervalle, pas de format
    ex : OHP20030808_obj0013n



    Pour information, dans la spécification, il y a 52 propriétés au total, dont 48 sont communes aux 2 types de spectres. Ces propriétés sont liées à des mots-clés dans l'en-tête du fichier de spectre.
    14 propriétés sont obligatoires. Parmi ces 14 propriétés obligatoires, 13 peuvent faire l'objet d'un champ ; le 14ème équivaut au nom de l'observateur qui est associé à une relation à part entière (USER).
    18 propriétés sont conditionnelles, c'est à dire conditionnées à la présence/absence d'autres propriétés. Parmi ces 18, 13 sont déjà intégrées dans différentes relations (OBJECT, TELESCOPE, SITE). Juste à titre purement indicatif, voici le document décrivant les règles des propriétés/règles de gestion de la base stellaire qui nous sert de modèle : BeSS ; c'est édifiant.

    Cette spécification ne sera pas implémentée dans son intégralité dans un premier temps mais je ne doute pas qu'on me demande un jour de le faire... J'appréhende.

    Vincent

  6. #6
    Membre régulier
    Homme Profil pro
    Webmaster
    Inscrit en
    Septembre 2016
    Messages
    67
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : Distribution

    Informations forums :
    Inscription : Septembre 2016
    Messages : 67
    Points : 90
    Points
    90
    Par défaut
    fsmrel,

    Pour le moment, je ne vais intégrer que les 12 propriétés/mots-clés ci-dessus : 11 communs aux 2 types de spectres et 1 spécifique au spectre de type échelle. Ce sont les 12 propriétés minimales nécessaires pour caractériser complètement un spectre. Elles seront directement exploitées dans le site et le service web que nous mettons en place.
    Toutefois, j'aimerai pouvoir rendre la modélisation suffisamment flexible pour pouvoir y intégrer à terme l'intégralité des autres mots-clés afin de constituer pour chaque spectre un en-tête "idéal", c'est à dire homogène, cohérent et bien formaté ; cet en-tête théorique pourrait remplacer celui fourni par l'observateur dans son fichier.

    Certains mots-clés font l'objet de relations à part entière dans la base (USER, SITE, TELESCOPE, OBJECT, etc.) mais une métatable MOT_CLE permettrait de reconstituer cet en-tête idéal, quitte à ce qu'il y ait une redondance d'informations. Je préfère une petite information dupliquée plutôt qu'une perte.
    Rien n'est encore décidée sur cette métatable. Une option peut consister à stocker l'en-tête complet du fichier en tant que type dans la base.

    Vincent

  7. #7
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 130
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 130
    Points : 38 543
    Points
    38 543
    Billets dans le blog
    9
    Par défaut
    Pour ce besoin, je pense qu'on peut faire ainsi :

    TYPE_SPECTRE (SP_id, attribut1, attribut2, …, attributn) 0,n --- posseder (obligatoire) --- 0,n PROPRIETE(PR_id, PR_type, PR_long, PR_min, PR_max) 0,n --- valoriser --- (1,1)VALEUR(VA_id, VA_valeur)

    La relation posséder devient une table dont l'identifiant est SP_ID+PR_ID, elle porte une propriété indiquant le caractère obligatoire ou non de la propriété pour le type de spectre
    Les attributs PR_MIN et PR_MAX contiennent les valeurs mini et maxi (identiques si une seule valeur autorisée), null si liste de valeurs
    La table issue de l'entité-type VALEUR est identifiée relativement à la propriété à laquelle elle est rattachée (PR_id+VA_id), il y aura autant d'occurrences dans la table que de valeurs autorisées pour la propriété.

  8. #8
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir aras-vbo et escartefigue,

    Une variante...

    Citation Envoyé par aras-vbo Voir le message
    Dans ce modèle, il est difficile de modifier une propriété (la rendre obligatoire, par exemple, quoiqu'en la définissant comme NOT NULL on puisse le mimer, non sans problème) et la quantité de valeurs NULL devient énorme puisque bon nombre de propriétés sont facultatives ou conditionnelles.
    Les propriétés obligatoires communes aux 2 types de spectres (CRVAL1, CDELT1, CRPIX1, CUNIT1, CTYPE1, BSS_VHEL, BSS_TELL, BSS_COSM, BSS_NORM) pourraient faire chacune faire l’objet, sans que ça gêne, d’une colonne de l’en-tête de la table SPECTRE, et le contrôle de la validité des valeurs prises par chaque colonne faire l’objet d’une contrainte, par exemple pour la colonne BSS_NORM (je reprends ici le nom de la propriété du tableau pour le nom de la colonne) :

    ALTER TABLE SPECTRE
        ADD CONSTRAINT SPECTRE_BSS_NORM CHECK (BSS_NORM IN ('none', 'removed', 'method xx')) ;
    
    Pour chaque propriété facultative (ou conditionnelle, à quoi correspond cet adjectif ?), en l’occurrence BSS_ESRP et BSS_BINN, on pourrait mettre en œuvre une table dédiée à la propriété. Par exemple :

    CREATE TABLE BSS_ESRP
    (
            spectre_id       INTEGER              NOT NULL 
          , bss_esrp         DOUBLE PRECISION     NOT NULL 
        , CONSTRAINT BSS_ESRP_PK PRIMARY KEY (spectre_id)
        , CONSTRAINT BSS_ESRP_FK FOREIGN KEY (spectre_id) REFERENCES SPECTRE (spectre_id)
        , CONSTRAINT BSS_ESRP_CHK CHECK (bss_esrp >= 0)
    ) ;
    
    Si la propriété devenait obligatoire, on pourrait envisager la mise en œuvre d’un trigger vérifiant la chose (puis procéder à l’opération relativement lourde d’ajout de la colonne bss_esrp dans la table SPECTRE si la performance de l’application l’exigeait).

    Ce qui vaut pour la table SPECTRE, vaut évidemment pour la table SPECTRE_ECHELLE, toutes choses égales (propriété BSS_ORD).

    L’idée est qu’avec des contraintes telles que BSS_ESRP_CHK ou SPECTRE_BSS_NORM, on puisse déléguer un maximum de contrôles à SQL.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  9. #9
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    J’ai oublié un point important : dans ce que je viens de proposer, la table SPECTRE voit une partie de ses informations être expulsées dans des tables satellites (sic !) tellles que BSS_ESRP et BSS_BINN, d’où jointures (externes) pour recomposer la table SPECTRE (devenue soleil (resic !)) selon sa structure originelle. Il sera préférable que les requêtes (y-compris celle de mise à jour) portent sur une vue (de jointure) de ces tables, d’où gain en stabilité et en simplicité des requêtes, la recomposition se passant sous le capot.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  10. #10
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonjour,


    Note concernant la modélisation

    Sémantiquement parlant, l’entité-type SPECTRE est une propriété multivaluée de l’entité-type ASTRE (composition au sens UML). Au stade du MCD, vous pourriez mettre ceci en évidence, en utilisant l’identification relative. Avec JMerise :




    Dans ces conditions, au stade SQL, la table SPECTRE a pour clé primaire le couple {id_spectre, id_astre}. Pour les requêtes mettant en jeu les tables SPECTRE et ASTRE, ont y gagnera en performance (et on pourra éviter la mise en oeuvre d’un index pour la clé étrangère référençant ASTRE). Attention à l’ordre des colonnes dans la clé primaire, la colonne id_spectre doit figurer en tête, sinon on perdra le bénéfice de l’opération. Je signale que dans sa version actuelle, JMerise fait exactement l’inverse.

    Quelle est votre position ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  11. #11
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 130
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 130
    Points : 38 543
    Points
    38 543
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    Attention à l’ordre des colonnes dans la clé primaire, la colonne id_spectre doit figurer en tête, sinon on perdra le bénéfice de l’opération. Je signale que dans sa version actuelle, JMerise fait exactement l’inverse.
    Et dans Power-AMC, l'ordre semble aléatoire, ou en tout cas je n'ai pas compris s'il y a possibilité de choisir l'ordre et du coup je vérifie systématiquemet
    Désolé pour cette digression (pas au sens astronomique du terme )

  12. #12
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    @escartefigue,

    Par acquit de conscience, j’ai vérifié la génération du MPD et du code SQL à partir du MCD dans le contexte de l’identification relative à plusieurs niveaux : l’ordre des colonnes dans les clés primaires (et étrangères !) est le bon (PowerAMC V15). Ça fait 25 ans que j’utilise AMC, et de mémoire je n’ai jamais connu de problème (et vous savez combien je suis chatouilleux quant à cet ordre des colonnes...)
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  13. #13
    Membre régulier
    Homme Profil pro
    Webmaster
    Inscrit en
    Septembre 2016
    Messages
    67
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : Distribution

    Informations forums :
    Inscription : Septembre 2016
    Messages : 67
    Points : 90
    Points
    90
    Par défaut
    Merci pour vos remarques !

    @escartefigue,

    Votre solution est très séduisante car elle offre une grande souplesse dans les propriétés. Mais est-ce que je ne suis pas contraint à transtyper toute les valeurs PR_long, PR_min et PR_max pour vérifier les contraintes sur chaque propriété ? Dans ce cas, est-ce que je ne peux pas définir les formats et intervalles de validité des propriétés pour chaque PR_id, directement dans la table sous forme d'une expression rationnelle, par exemple ?


    @fsmrel

    J'avais pensé à une solution de ce type, en externalisant les propriétés facultatives et en intégrant les propriétés obligatoires dans les tables SPECTRE et SPECTRE_ECHELLE. Ce qui m'avait un peu freiné était justement le problème du passage possible de facultatif à obligatoire d'une propriété.
    Pouvez-vous me confirmer que le modèle suivant reflète bien votre solution ?

    Nom : test4.jpg
Affichages : 1299
Taille : 179,8 Ko

    Si on pousse l'externalisation encore plus loin, peut-on envisager directement la création de toutes les propriétés sous forme d'une table individuelle (soit 12 tables différentes) ? Est-ce que cette solution ne deviendrait pas problématique si j'implémente plus tard les 52 propriétés correspondant aux 52 mots-clés ? Une telle quantité de jointures pour la création d'une vue ne serait-elle pas utopique ?

    Votre remarque sur la composition est intéressante et je pense l'intégrer. Je pense faire de même sur le problème, assez semblable, de l'association ternaire entre Site, Instrument et Spectre que je pourrais réduire en une simple association binaire avec une composition ; puisque SPECTRE est aussi, à mon avis, une propriété multivaluée de l'association SITE / INSTRUMENT. Qu'en pensez-vous ?

    Je vous soumettrai l'intégralité du MCD lorsque j'aurai intégré la modélisation des propriétés.

    Encore merci à vous pour votre aide,

    Vincent

  14. #14
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir Vincent et Capitaine,

    Citation Envoyé par aras-vbo Voir le message
    Je pense faire de même sur le problème, assez semblable, de l'association ternaire entre Site, Instrument et Spectre que je pourrais réduire en une simple association binaire avec une composition ; puisque SPECTRE est aussi, à mon avis, une propriété multivaluée de l'association SITE / INSTRUMENT. Qu'en pensez-vous ?
    Hum... Vous avez défini une entité-type associative INSTRUMENT_SITE : parfait. Au stade MLD, on aura une table INSTRUMENT_SITE ayant pour clé primaire la paire {id_instrument, id_site} et là j’estime que ça coince, car cela veut dire que l’instrument I1 peut être simultanément localisé sur les sites S1, S2,..., Sn. Si par exemple à l’instant T1 l’ instrument I1 ne peut que se trouver sur le site S2, comment le savoir ? Autrement dit il faudrait ajouter un attribut du genre Date_localisation_intrument dans l’en-tête de la table INSTRUMENT_SITE et c’est la paire {{id_instrument, Date_localisation_intrument} qui alors deviendra clé primaire. Dans ces conditions, à un instant donné un instrument ne peut être que sur un site et un seul. Mais peut-être avez-vous des arguments à faire valoir pour la pertinence de la clé {id_instrument, id_site} ?

    Cela dit, si vous considérez que SPECTRE est aussi une propriété multivaluée de l'entité-type associative SITE_INSTRUMENT, cela revient à dire que SITE_INSTRUMENT et ASTRE se partagent la possession de SPECTRE qui devient entité-type associative : pourquoi pas ? comme aurait pu dire le roi Salomon, il faudra qu’on examine plus à fond l’intérêt de la chose.


    Citation Envoyé par aras-vbo Voir le message
    Si on pousse l'externalisation encore plus loin, peut-on envisager directement la création de toutes les propriétés sous forme d'une table individuelle (soit 12 tables différentes) ? Est-ce que cette solution ne deviendrait pas problématique si j'implémente plus tard les 52 propriétés correspondant aux 52 mots-clés ?
    C’est faisable (et les tables respecteraient la sixième forme normale, rien que ça !), mais attention, pour chaque propriété « obligatoire » telle que CTVAL1, vous seriez obligé de mettre en œuvre un trigger garantissant la bijection entre les tables SPECTRE et chaque table satellite (telle que CTVAL1). Personnellement je ne m’y risquerais pas, vu la charge de développement et de maintenance, sans compter que la performance pourrait être affectée.


    Citation Envoyé par aras-vbo Voir le message
    Une telle quantité de jointures pour la création d'une vue ne serait-elle pas utopique ?
    Je pense que pour PostgreSQL ça n’est pas un problème, mais il faudrait tester la performance.


    Citation Envoyé par aras-vbo Voir le message
    Pouvez-vous me confirmer que le modèle suivant reflète bien votre solution ?
    Pas tout à fait car, sémantiquement parlant, disons que si l’entité-type SPECTRE est bien cette fois-ci à considérer comme une propriété mulltivaluée de l’entité-type ASTRE (on dit encore que SPECTRE est une entité-type faible), les entités-types BSS_ESRP et BSS_BINN sont encore plus faibles, en effet chacune d’elles est une propriété monovaluée — cas particulier de la propriété multivaluée — de l’entité-type SPECTRE, il faut donc là encore symboliser la chose par des liens identifiants.

    MCD (avec PowerAMC)



    Vous noterez que l’attribut id_spectre (à l’instar de l’attribut id_astre) ne figure qu’une seule fois dans le MCD, il est absent dans le cas des entités-types BSS_ESRP et BSS_BINN, ainsi du reste que dans le cas de l’entité-type spécialisée SPECTRE_ECHELLE : dans tous ces cas de figures, il y a héritage implicite de l’identifiant. Au stade MLD, cet héritage est rendu explicite. Cette non redondance est une exigence de Merise, alors qu’au niveau suivant (MLD), la redondance est nécessaire pour pouvoir effectuer les opérations de jointure entre tables.

    JMerise ne traite pas encore des associations avec des entités-types qui sont des propriétés monovaluées (cardinalité 0,1 / (1,1)).


    MLD (PowerAMC)



    A titre indicatif, je joins un code SQL (PostgreSQL) plus complet :

    -- -------------------------
    -- Tâches initiales
    -- -------------------------
    
    SET search_path TO aras_vbo ;
    
    DROP VIEW  IF EXISTS SPECTRE_VUE ;
    DROP TABLE IF EXISTS BSS_ESRP ;
    DROP TABLE IF EXISTS BSS_BINN ;
    DROP TABLE IF EXISTS BSS_ORD ;
    DROP TABLE IF EXISTS SPECTRE_ECHELLE ;
    DROP TABLE IF EXISTS SPECTRE ;
    DROP TABLE IF EXISTS ASTRE ;
    
    -- -------------------------
    -- Déclaration des tables 
    -- -------------------------
    
    CREATE TABLE ASTRE
    (
            id_astre          SERIAL                NOT NULL 
          , affichage_astre   BOOLEAN               NOT NULL  
          , ad_fk5_astre      FLOAT                 NOT NULL 
          , dec_fk5_astre     FLOAT                 NOT NULL 
      , CONSTRAINT ASTRE_PK PRIMARY KEY (id_astre)
    ) ;
    
    INSERT INTO ASTRE (affichage_astre, ad_fk5_astre, dec_fk5_astre) VALUES (true, 45, 180) ;
    
    SELECT * FROM ASTRE ;
    
    CREATE TABLE SPECTRE
    (
            id_astre          INTEGER               NOT NULL 
          , id_spectre        SERIAL                NOT NULL 
          , crval1            DOUBLE PRECISION      NOT NULL   
          , cdelt1            DOUBLE PRECISION      NOT NULL 
          , crpix1            FLOAT                 NOT NULL 
          , cunit1            VARCHAR(32)           NOT NULL 
          , ctype1            VARCHAR(32)           NOT NULL 
          , bss_vhel          FLOAT                 NOT NULL  
          , bss_tell          VARCHAR(32)           NOT NULL 
          , bss_cosm          VARCHAR(32)           NOT NULL 
          , bss_norm          VARCHAR(32)           NOT NULL 
      , CONSTRAINT SPECTRE_PK PRIMARY KEY (id_astre, id_spectre)
      , CONSTRAINT SPECTRE_ASTRE_FK FOREIGN KEY (id_astre) REFERENCES ASTRE (id_astre)
    ) ;
    
    -- --------------------------------
    -- Contraintes de la table SPECTRE
    -- --------------------------------
    
    ALTER TABLE SPECTRE
        ADD CONSTRAINT SPECTRE_CRVAL1 CHECK (crval1 BETWEEN 300 AND 10000) ;
    ALTER TABLE SPECTRE
        ADD CONSTRAINT SPECTRE_CDELT1 CHECK (cdelt1 BETWEEN 0.0001 AND 30) ;
    ALTER TABLE SPECTRE
        ADD CONSTRAINT SPECTRE_CUNIT1 CHECK (cunit1 IN ('angstrom', 'nm')) ;
    ALTER TABLE SPECTRE
        ADD CONSTRAINT SPECTRE_CTYPE1 CHECK (ctype1 IN ('wavelength')) ;
    ALTER TABLE SPECTRE
        ADD CONSTRAINT SPECTRE_BSS_VHEL CHECK (bss_vhel BETWEEN -200 AND +200) ;
    ALTER TABLE SPECTRE
        ADD CONSTRAINT SPECTRE_BSS_TELL CHECK (bss_tell IN ('none', 'removed', 'method xx')) ;
    ALTER TABLE SPECTRE
        ADD CONSTRAINT SPECTRE_BSS_COSM CHECK (bss_cosm IN ('none', 'removed', 'method xx')) ;
    ALTER TABLE SPECTRE
        ADD CONSTRAINT SPECTRE_BSS_NORM CHECK (bss_norm IN ('none', 'removed', 'method xx')) ;
    
    -- ------------------------------
    -- INSERTS
    -- ------------------------------
    
    INSERT INTO SPECTRE (id_astre, crval1, cdelt1, crpix1, cunit1, ctype1, bss_vhel, bss_tell, bss_cosm, bss_norm)
           VALUES (1, 6233.45, 0.116, 1.0, 'nm', 'wavelength', -9.45, 'none', 'removed', 'none') ;
    INSERT INTO SPECTRE (id_astre, crval1, cdelt1, crpix1, cunit1, ctype1, bss_vhel, bss_tell, bss_cosm, bss_norm)
           VALUES (1, 6233.45, 0.116, 1.0, 'nm', 'wavelength', -9.45, 'none', 'removed', 'none') ;
    
    -- ----------------------------------
    -- Tables satellites de SPECTRE
    -- ----------------------------------
    
    CREATE TABLE SPECTRE_ECHELLE
    (
            id_astre          INTEGER               NOT NULL
          , id_spectre        INTEGER               NOT NULL 
          , bss_ord           VARCHAR(254)          NOT NULL 
        , CONSTRAINT SPECTRE_ECHELLE_PK PRIMARY KEY (id_astre, id_spectre)
        , CONSTRAINT SPECTRE_ECHELLE_FK FOREIGN KEY (id_astre, id_spectre) REFERENCES SPECTRE (id_astre, id_spectre)
    ) ;
    
    CREATE TABLE BSS_ESRP
    (
            id_astre          INTEGER               NOT NULL
          , id_spectre        INTEGER               NOT NULL 
          , bss_esrp          DOUBLE PRECISION      NOT NULL 
        , CONSTRAINT BSS_ESRP_PK PRIMARY KEY (id_astre, id_spectre)
        , CONSTRAINT BSS_ESRP_FK FOREIGN KEY (id_astre, id_spectre) REFERENCES SPECTRE (id_astre, id_spectre)
        , CONSTRAINT BSS_ESRP_CHK CHECK (bss_esrp >= 0)
    ) ;
    INSERT INTO BSS_ESRP (id_astre, id_spectre, bss_esrp)
           VALUES (1, 2, 17.0005) ;
    
    CREATE TABLE BSS_BINN
    (
            id_astre          INTEGER               NOT NULL
          , id_spectre        INTEGER               NOT NULL 
          , bss_binn          VARCHAR(254)          NOT NULL 
        , CONSTRAINT BSS_BINN_PK PRIMARY KEY (id_astre, id_spectre)
        , CONSTRAINT BSS_BINN_FK FOREIGN KEY (id_astre, id_spectre) REFERENCES SPECTRE (id_astre, id_spectre)
    ) ;
    INSERT INTO BSS_BINN (id_astre, id_spectre, bss_binn)
           VALUES (1, 2, 'tout baigne') ;
    
    -- -------------------------------------------------------
    -- Vue pour encapsuler les jointures et voir en une fois 
    -- l'ensemble des propriétés des spectres.
    -- -------------------------------------------------------
    CREATE VIEW SPECTRE_VUE (id_astre, id_spectre, crval1, cdelt1, crpix1, cunit1, ctype1, bss_vhel, bss_tell, bss_cosm, bss_norm, bss_binn, bss_esrp)
    AS
        SELECT x.id_astre, x.id_spectre, crval1, cdelt1, crpix1, cunit1, ctype1, bss_vhel, bss_tell, bss_cosm, bss_norm, COALESCE(bss_binn, 'nib !')
             , COALESCE(NULLIF(CAST(bss_esrp AS VARCHAR), ''), 'néant !') 
        FROM   SPECTRE AS x LEFT JOIN BSS_ESRP AS y ON x.id_astre = y.id_astre AND x.id_spectre = y.id_spectre
                            LEFT JOIN BSS_BINN AS z ON x.id_astre = z.id_astre AND x.id_spectre = z.id_spectre
    ;
    
    -- -------------------------------------------------------------------------------
    -- Pour voir l'ensemble des propriétés obligatoires et optionnelles des spectres 
    -- -------------------------------------------------------------------------------
    
    SELECT * FROM SPECTRE_VUE ;
    
    =>

    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  15. #15
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 130
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 130
    Points : 38 543
    Points
    38 543
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par aras-vbo Voir le message
    @escartefigue,

    Votre solution est très séduisante car elle offre une grande souplesse dans les propriétés. Mais est-ce que je ne suis pas contraint à transtyper toute les valeurs PR_long, PR_min et PR_max pour vérifier les contraintes sur chaque propriété ? Dans ce cas, est-ce que je ne peux pas définir les formats et intervalles de validité des propriétés pour chaque PR_id, directement dans la table sous forme d'une expression rationnelle, par exemple ?
    Une contrainte ne peut s'appliquer qu'a toutes les occurrences de la table, par contre un trigger peut faire ces contrôles

    Citation Envoyé par fsmrel Voir le message
    @escartefigue,
    Par acquit de conscience, j’ai vérifié la génération du MPD et du code SQL à partir du MCD dans le contexte de l’identification relative à plusieurs niveaux : l’ordre des colonnes dans les clés primaires (et étrangères !) est le bon (PowerAMC V15). Ça fait 25 ans que j’utilise AMC, et de mémoire je n’ai jamais connu de problème (et vous savez combien je suis chatouilleux quant à cet ordre des colonnes...)
    Pourtant je viens de reprendre un cas pour un sujet ouvert ici et que j'avais conservé, avec Power AMC V16.5 voici ce que produit la génération du MLD à partir du MCD, les colonnes identifiantes sont bel et bien inversées, et je suis obligé d'intervenir dans le MLD pour rétablir la situation
    Pièce jointe 360971
    Il n'y a aucun paramètre particulier dans la définition de la relation.
    Ce n'est pas toujours le cas, parfois l'ordre est bien celui souhaité

  16. #16
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    @Capitaine,

    J'ai créé les mêmes modèles que les tiens, mais à la différence que l'ordre est le bon (AMC m'a reconnu )

    Pour éviter de polluer le beau travail de Vincent, pourrais-tu ouvrir une discussion dans le forum AMC, que nous essayions de comprendre cette histoire ?

    [EDITJ'ai compris mais ouvre la discussion dans le forum AMC[/EDiT]
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  17. #17
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Vincent,


    Combien de lignes a-t-on dans les tables ASTRE, SPECTRE ?

    J’ai retrouvé des résultats de tests (PostgreSQL 9.3.5) portant sur un SELECT qui est la jointure de 90 tables (d’une base de données que j’ai dû supprimer...), dont celle qui est disons l’équivalent de la table SPECTRE contient un peu plus de 100000 lignes. Cette grande jointure est composée de 6 inner joins, le reste étant des left outer joins. Pour lire les données de l’équivalent de 20 spectres : 0,45 seconde.

    Cela dit, je ne me sens pas le courage de recréer la base de données pour refaire des tests de performance divers et variés, portant notamment sur une vue encapsulant le SELECT...

    Bon week-end.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  18. #18
    Membre régulier
    Homme Profil pro
    Webmaster
    Inscrit en
    Septembre 2016
    Messages
    67
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : Distribution

    Informations forums :
    Inscription : Septembre 2016
    Messages : 67
    Points : 90
    Points
    90
    Par défaut
    @fsmrel

    Merci, je n'en demandais pas tant ! L'explication est limpide concernant l'identification relative.
    Je pense que je vais juste renommer les attributs de façon à ne pas nécessairement les lier aux noms des mots-clés FITS correspondants. C'est un parti_pris purement pratique ; cela découplera les attributs d'une implémentation particulière (le format FITS) car, qui sait si ce format ne sera pas amené à évoluer dans le futur.


    La liaison entre INSTRUMENT, SITE, UTILISATEUR, SPECTRE et ASTRE est un peu un casse-tête car il s'agit quasiment d'une association quinternaire difficile à décomposer ; les entités sont très imbriquées.
    Vous me poser une vraie colle avec mon entité-type associative INSTRUMENT_SITE. Je pensais qu'elle résoudrait mon problème et qu'elle me permettrait de défaire ce sac de noeuds...

    Un SPECTRE est effectivement une entité-type faible de ASTRE. Ca ne fait aucun doute selon la manière dont vous l'expliquez.

    Je pense qu'un SPECTRE peut aussi être considéré comme une entité-type faible du couple INSTRUMENT_SITE.
    D'un point de vue conceptuel, c'est nécessairement un INSTRUMENT installé sur un SITE qui enregistre le SPECTRE et non l'INSTRUMENT seul. C'est tellement vrai que, d'un point de vue pratique cette fois-ci, un spectre sans localisation terrestre (donc sans SITE) n'a que peu de valeur puisqu'il devient impossible de déterminer certaines de ses propriétés (la vitesse héliocentrique BSS_VHEL à retrancher, par exemple). C'est sans doute le couple le plus imbriqué de l'association.

    Pour terminer, il faut que j'associe l'UTILISATEUR qui utilise le couple INSTRUMENT_SITE.

    Je peux donc éventuellement décomposer en (INSTRUMENT, SITE), SPECTRE, ASTRE, UTILISATEUR.
    Un UTILISATEUR utilise (INSTRUMENT, SITE).
    Un (INSTRUMENT, SITE) enregistre un SPECTRE, qui dépend lui-même totalement de l'ASTRE (entité-type forte).
    Qu'en pensez-vous ?


    Enfin, concernant le nombre de spectres.
    La base ARAS actuelle contient environ 10 000 spectres, d'environ 150 à 200 astres.
    La base BeSS (notre modèle) contient actuellement 155 000 spectres de 2330 étoiles.
    La base ARAS ne peut que grossir fortement car le nombre d'astres qui sont potentiellement à surveiller avoisine les 10 000 (sur la centaine de milliers que comportent les catalogues) alors que le catalogue de la base BeSS est quasiment complet ; on estime les étoiles Be accessibles à l'observation spectrale amateur à seulement quelques milliers.

    Vos tests semblent indiquer qu'il serait possible de considérer chaque propriété comme une entité unique sans que cela ne pose de problèmes dramatiques de performance.


    Vincent

  19. #19
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Vincent,

    Je ne vous oublie surtout pas, mais je suis en train de traiter de certaines urgences, notamment en ce qui concerne JMerise, voyez ici. Quelque part, vos êtes concerné par ce que j’expose à rabDev

    Je ne vous lâcherai pas ! A moins que les aléas de la vie...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  20. #20
    Membre régulier
    Homme Profil pro
    Webmaster
    Inscrit en
    Septembre 2016
    Messages
    67
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : Distribution

    Informations forums :
    Inscription : Septembre 2016
    Messages : 67
    Points : 90
    Points
    90
    Par défaut
    Bonjour François,

    Pas de problème. Je suis en déplacement et je n'aurai sans doute pas beaucoup de temps cette semaine pour me consacrer à ce MCD.
    Je suis la discussion avec le concepteur de JMerise. C'est très intéressant de pouvoir lui soumettre des correctifs directement !

    Vincent

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Boucler sur une propriété "variable"
    Par maxxou dans le forum C#
    Réponses: 3
    Dernier message: 13/04/2010, 21h53
  2. Récupération d'une propriété variable
    Par imhotep_zr7s dans le forum ANT
    Réponses: 2
    Dernier message: 18/07/2008, 12h27
  3. Javabean avec nombre de propriétés variable
    Par nicolas33400 dans le forum AWT/Swing
    Réponses: 8
    Dernier message: 06/06/2008, 01h02
  4. [MCD] Modéliser une propriété dans une relation
    Par korrigan dans le forum PowerAMC
    Réponses: 4
    Dernier message: 04/09/2007, 15h33
  5. Parametre variables en nombre et en type
    Par tinico dans le forum Langage
    Réponses: 9
    Dernier message: 18/04/2007, 16h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo