Discussion :

[ced]

Bonjour,

Voici un modèle de données :


Par le jeu des identifications relatives, quand je mets en correspondance (association CORRESPONDRE) un arbre (entité ARBRE) avec son équivalent numérique (entité ARBRE_NUMERIQUE), il se trouve que l'identifiant du point (attribut ID_POINT) qui arrive côté ARBRE est le même identifiant de point que celui qui arrive côté ARBRE_NUMERIQUE.

Or, dans le modèle logique de données, je récupère deux identifiants de points différents (ID_POINT et ID_POINT1) dans la table CORRESPONDRE, après avoir coché la case "Générer une table de correspondance dans le MLD) :


Comment faire pour n'avoir qu'un seul ID_POINT dans la table de correspondance, vu que c'est le même identifiant issu des identifications relatives ?
Le problème reste le même si je clique sur le bouton de création d'une entité de correspondance.

Merci d'avance pour votre aide,

ced

[fsmrel]

Bonjour Ced,

Selon votre MCD, puisque SCAN est identifié relativement à POINT qui lui-même est identifié relativement à OPERATEUR, SCAN hérite transitivement de l’identifiant de OPERATEUR. Par ailleurs, vous identifiez SCAN relativement à OPERATEUR : ça a un goût puissant de redondance !
Commencez par supprimer l’identification relative de SCAN par rapport à OPERATEUR.
Quoi qu’il en soit, au stade MLD la table SCAN comportera encore deux fois l’attribut id_operateur, ce qui peut se justifier si un scan peut être piloté par un opérateur qui n’est pas celui qui a numérisé.

[ced]

Merci pour l'aide proposée.

C'est sûr que je n'ai pas fourni les règles de gestion, et notamment pas pour la partie opérateur. Mais ce n'est pas sur cette partie du modèle que porte ma question...
Pour répondre à la remarque sur l'opérateur, ce n'est pas le même opérateur qui est responsable des informations collectées sur un point (d'où la relation entre POINT et OPERATEUR) et celui qui se charge de numériser (acquisition d'une image par LiDAR) le même point, à un moment différent dans le temps. Il faut donc une relation également entre SCAN et OPERATEUR.
Attention, POINT n'est pas identifié relativement à OPERATEUR. Seul SCAN est identifié relativement à POINT (on réalise jusqu'à 4 scans LiDAR par point).

En revanche, là où il pourrait y avoir de la redondance, c'est sur l'opérateur des scans d'un point. Mais ces scans d'un même point peuvent être faits à plusieurs dates par des opérateurs différents, d'où la relation entre OPERATEUR et SCAN.

Le problème reste de toute façon le même, dans la table de correspondance entre arbres.

Mais merci pour les remarques pertinentes !

ced

[fsmrel]

Je vous cite :

Attention, POINT n'est pas identifié relativement à OPERATEUR. Seul SCAN est identifié relativement à POINT

Et pourtant, selon le MCD, POINT est bien identifié relativement à OPERATEUR, autrement dit le MCD est à aménager.

En attendant, toujours au vu du MCD actuel, ARBRE reste identifié relativement à OPERATEUR...

[ced]

Et pourtant, selon le MCD, POINT est bien identifié relativement à OPERATEUR, autrement dit le MCD est à aménager.

En attendant, toujours au vu du MCD actuel, ARBRE reste identifié relativement à OPERATEUR...

Si c'est la flèche côté OPERATEUR, ce n'est pas une identification relative... Ce qui indique l'identification relative, c'est le (R) dans la patte de la relation.
D'ailleurs, ID_OPERATEUR n'est pas dans ARBRE dans le MLD...

ced

[ced]

OK, j'ai trouvé d'où venait la flèche : c'est l'identification d'une DF dans le MCD.
Voici ce que ça donne en enlevant cette identification :


En tout cas, j'ai toujours ce problème de double ID_POINT alors que c'est le même point... Et comme, sous Looping, on n'a pas la main sur les colonnes générées automatiquement dans le MLD, je ne sais pas comment faire (si c'est faisable), sauf à changer le script SQL au moment de la création de la table...

ced

[fsmrel]

Si c'est la flèche côté OPERATEUR, ce n'est pas une identification relative... Ce qui indique l'identification relative, c'est le (R) dans la patte de la relation.

Mille excuses ! Vous avez raison.
Un an sans Looping et confusion avec d’autres outils, ça ne pardonne pas, Paprick et Escartefigue comprendront...

En son temps, le groupe 135 de l’Afcet avait traité des contraintes d’exclusion, inclusion, égalité, et sans doute est-on en présence de cette dernière.

Je rappelle la définition de l’Afcet :

Les relations R et S sont dites soumises à une condition d’égalité vis-à-vis d’une liste non vide (P, P’, ...) d’individus communs appelée « pivot » de la contrainte, si et seulement si R est incluse dans S, et S dans R, vis-à-vis de ce pivot.

A approfondir avec Paprick.

[ced]

Aucun souci, en tout cas merci pour l'aide.

[docdu92]

L'arbre numérique ?
De quoi s'agit-il ?
Du produit d'un scan à partir d'un point stationné ?
Du produit de plusieurs scans (cad dans des conditions différentes) à partir d'un même point stationné ?
dito mais à partir plusieurs points stationnés ?
Et les relations sont-elle bonnes !

[ced]

Peu importe le sens des entités, c'est un domaine très spécifique.
Le problème que je rencontre pourrait être présenté avec d'autres concepts... On pourrait les nommer A, B, C, etc., le problème serait le même.

Je n'ai pas de souci avec les règles de gestion, ni les entités, ni les concepts qui ici importent peu. C'est avec la transformation du MCD en MLD en mettant en correspondance deux tables (les arbres) issues d’identifications relatives d'une même entité de départ (l'entité POINT).

ced

[Paprick]

Bonsoir,

Effectivement, ce cas est intéressant.
Je le comprends à plusieurs niveaux de préoccupation :

• Tout d'abord au niveau purement conceptuel, d'après moi, le modèle proposé n'exprime pas le fait que le Id_Point issu de l'arbre doit forcément être le même que le Id_Point issu du Scan, et donc de l'arbre numérique. Si on veut exprimer cette égalité sur une partie de la clé primaire de Arbre et Arbre_Numérique, il faut le modéliser.
• Les contraintes inter-associations classiques (exclusivité, totalité, partition, simultanéité et inclusion) ne semblent pas couvrir cette problématique, et il ne me parait donc pas possible d'exprimer formellement la contrainte souhaitée.
• Pour ces cas, Looping propose l'outil "Règle" permettant d'exprimer une contrainte libre au niveau du MCD (par une description textuelle), mais également au niveau DDL en écrivant la requête SQL (par exemple avec un ALTER TABLE) qui adaptera en conséquence le schéma relationnel de la base : seul le MLD continuera à montrer les 2 clés, sachant que le code généré permettra d'en supprimer une.

Est-ce que cela peut répondre à votre besoin ?

[ced]

Merci Paprick pour cette réponse, à une heure aussi avancée de la nuit !

Effectivement, dans mon modèle actuel, rien n'empêche d'attacher un arbre numérique d'un point à un arbre réel d'un autre point... Il faut donc que modélise cette contrainte particulière.

ced