Discussion :

[menas]

Bonjour tout le monde,

Je voudrais réaliser une application PHP/MySQL qui me permettrait de stocker des mesures dans un BdD.
Je vais essayer de faire simple et concis :

• Il existe plusieurs types de mesures, chacune d'elle pouvant être brute ou traitée (par exemple débruitée)
• les mesures traitées dérivent d'une mesure brute. End'autres termes, une mesure est brute si, et seulement si, elle n'a subi aucun traitement. D'où la nécessité d'établir une association entre une mesure brute et une mesure traitée.

Ci-joint une ébauche du MCD, réalisée avec Dia (les losanges devraient être des ellipses, mais la méthode MERISE n'est apparement pas supportée par Dia...). Les cardinalités n'y figurent pas, car je ne suis même pas sûr de mon schéma !
En effet :

1. Ai-je bien fait de décrire une association ternaire entre les entités "Type_traitement" et "Mesure" ?
2. Dois-je plutôt distinguer mesures brutes et mesures traitées en créant 2 entités différentes ?
3. Ou bien, devrais-je ajouter un attribut booléen dans l'entité "Type_Mesure", qui signalerait si la donnée est brute ou traitée ?

Merci d'avance pour votre aide !

[CinePhil]

• Il existe plusieurs types de mesures, chacune d'elle pouvant être brute ou traitée (par exemple débruitée)

Ca veut dire que 'brute' et 'traitée' sont les deux seuls types de mesure ?

• les mesures traitées dérivent d'une mesure brute. End'autres termes, une mesure est brute si, et seulement si, elle n'a subi aucun traitement. D'où la nécessité d'établir une association entre une mesure brute et une mesure traitée.

Ceci beut-il dire qu'on conserve les donnée de la mesure brute après son traitement ?

Ci-joint une ébauche du MCD, réalisée avec Dia (les losanges devraient être des ellipses, mais la méthode MERISE n'est apparement pas supportée par Dia...). Les cardinalités n'y figurent pas, car je ne suis même pas sûr de mon schéma !

Tu peux utiliser le logiciel de modélisation OpenModelsphere.

En effet :

1. Ai-je bien fait de décrire une association ternaire entre les entités "Type_traitement" et "Mesure" ?
2. Dois-je plutôt distinguer mesures brutes et mesures traitées en créant 2 entités différentes ?
3. Ou bien, devrais-je ajouter un attribut booléen dans l'entité "Type_Mesure", qui signalerait si la donnée est brute ou traitée ?

Si les types de traitements sont ce que tu as appelé précédemment des types de mesures et que ceux-ci ne sont et ne seront toujours que 'brute' ou 'traitée', un simple booléen suffit.

[menas]

Salut, et merci pour ta réponse

Ca veut dire que 'brute' et 'traitée' sont les deux seuls types de mesure ?

Non, il y a plusieurs types de mesures, par exemple I=f(Vc), I=f(Vt,t), I=F(Vc,Vrf)...bref, on obtient des graphiques de natures différentes. Chacun de ces types de mesure peut subir un traitement (comme un débruitage par exemple)

Ceci veut-il dire qu'on conserve les donnée de la mesure brute après son traitement ?

Tout à fait, la mesure traitée n'écrase PAS la mesure brute. On crée une (ou des) nouvelle(s) mesure(s) : la(les) mesure(s) traitée(s).

Si les types de traitements sont ce que tu as appelé précédemment des types de mesures et que ceux-ci ne sont et ne seront toujours que 'brute' ou 'traitée', un simple booléen suffit.

Il est dans tous les cas, nécessaire d'associer une mesure brute à sa "fille" qui a été traitée. Si j'opte pour l'attribut booléen dans une unique entité "MESURE", alors une association réflexive est nécessaire. Ce qui nous amène à l'association ternaire entre "TYPE TRAITEMENT" et "MESURE".
Or, je me demande si cette modélisation est normalisée. A vrai dire, je la trouve un peu tordue, et je flippe que ça pose des problèmes de cohérence.
De plus, j'ai lu que ce type de topologie (association ternaire) est difficile à implémenter (difficultés au niveau des cardinalités)
BREF, tu penses que c'est normalisé ?

Thx

[CinePhil]

Non, il y a plusieurs types de mesures, par exemple I=f(Vc), I=f(Vt,t), I=F(Vc,Vrf)...bref, on obtient des graphiques de natures différentes.

Donc on a le MCD suivant :
type_mesure -0,n----typer----1,1- mesure

Chacun de ces types de mesure peut subir un traitement (comme un débruitage par exemple)

Soyons précis de nouveau : Sont-ce les types de mesures qui peuvent subir des traitements ou les mesures ?
Autrement dit, une mesure étant d'un certain type subira t-elle toujours les mêmes traitements ou bien les traitements sont différents selion des mesures de même type ?

Tout à fait, la mesure traitée n'écrase PAS la mesure brute. On crée une (ou des) nouvelle(s) mesure(s) : la(les) mesure(s) traitée(s).

Petite subtilité ici...
Si on s'en tient au sens direct, en différenciant les mesures brutes et les mesures traitées, on a ce MCD :
Mesure (brute) -0,n----engendrer----1,1- Mesure (traitée)

Mais si une mesure traitée a les mêmes attributs qu'une mesure brute, alors c'est une seule entité pour les deux catégories de mesures et il faut passer au MCD suivant :
Mesure (brute) -0,n----engendrer----0,1- Mesure (traitée)

J'ai laissé les parenthèses pour plus de clarté. Eventuellement, elles pourraient dans un vrai MCD se transformer en rôles sur les branches de l'association.

Ce dernier MCD se traduirait par :
"Une mesure (brute) peut engendrer plusieurs mesures (traitées) et une mesure (traitée) peut être engendrée par une seule autre mesure (brute)."

Dans le premier cas, la table Mesure_traitee aurait une clé étrangère référençant la mesure brute qui l'a engendrée.
Dans le second cas, le couple de cardinalités {0,n - 0,1} engendrera normalement une table associative, comme dans le cas du couple {0,n - 0,n}.

Il est dans tous les cas, nécessaire d'associer une mesure brute à sa "fille" qui a été traitée.

D'après la phrase précédemment citée, une mesure brute peut engendrer plusieurs mesures filles. C'est donc plutôt la fille qui doit référencer sa mère et pas l'inverse. Ce qui veut sire que, si on met une clé étrangère faisant référence à la mesure mère dans la table des mesures, toutes les mesures brutes auront cette clé étrangère à NULL, ce qui n'est pas terrible. fsmrel dirait je crois que la thorie relationnelle l'interdit.

C'est pour cela que normalement on se retrouve dans le cas du second MCD et il y aura une table associative.

[quote]Si j'opte pour l'attribut booléen dans une unique entité "MESURE", alors une association réflexive est nécessaire. Ce qui nous amène à l'association ternaire entre "TYPE TRAITEMENT" et "MESURE".[quote]
Le booléen n'est plus nécessaire.
On peut compléter le MCD :
type_mesure -0,n----typer----1,1- mesure
|--------------------1,n----générer----1,1- traitement

A voir si un traitement ne s'applique qu'à un seul type de mesure ou s'il peut s'appliquer à plusieurs pour déterminer les cardinalités.

Maintenant, on change l'association 'engendrer' en 'traiter' :
Mesure -0,n--(brute)--traiter---(traitée)-0,1- Mesure
Traitement -0,n------------|

Il faut ajouter dans le MCD une contrainte d'inclusion entre les associations 'traiter' et 'typer' pour le traitement corresponde au type de mesure.

je flippe que ça pose des problèmes de cohérence.

La contrainte sur le MCD doit se gérer au niveau BDD par une contrainte CHECK.
Si le SGBD ne supporte pas les contraintes CHECK (MySQL), alors il faut sans doute passer par un trigger. Je n'ai jamais eu encore à mettre ce genre de truc en place.

De plus, j'ai lu que ce type de topologie (association ternaire) est difficile à implémenter (difficultés au niveau des cardinalités)

Bof, je viens de le faire ci-dessus pour les cardinalités.

Au niveau des tables, ça donne ceci pour les premières :
type_mesure (tm_id, tm_libelle, tm_description)
mesure (m_id, m_id_type, m_date...)
traitement (t_id, t_libelle, t_description)
tm_generer_t (tmt_id_traitement, tmt_id_type_mesure)

Pour la table issue de l'association 'traiter', la mesure traitée n'apparaît qu'une fois. Elle peut donc constituer seule la clé primaire :
traiter (trt_id_mesure_traitee, trt_id_mesure_brute, trt_id-traitement...)
Si une mesure brute ne peut subir qu'une seule fois un certain traitement pour engendrer une seule mesure traitée, alors il faudra ajouter une contrainte d'unicité sur le couple {trt_id_mesure_brute, trt_id-traitement}.

[menas]

Tout d'abord, merci encore pour le temps que vous me consacrez !

type_mesure -0,n----typer----1,1- mesure

Tout à fait d'accord ! Je débute, ça me prend un peu de temps pour acquérir les automatismes, mais j'ai finalement trouvé pareil.
________________________________________________

Soyons précis de nouveau : Sont-ce les types de mesures qui peuvent subir des traitements ou les mesures ?
Autrement dit, une mesure étant d'un certain type subira t-elle toujours les mêmes traitements ou bien les traitements sont différents selion des mesures de même type ?

Les traitements peuvent être différents pour des mesures qui sont du même type. Les traitements peuvent également être les mêmes pour des mesures de types différents. Les mesures subissent des traitements indépendamment de leur type_mesure.

J'obtiens les cardinalités suivantes (j'ai un doute sur le "c.", mais je crois aue c'est bon...)

Association “Traiter”:
a. Une mesure peut ne subir aucun traitement.
b. Une mesure peut subir plusieurs traitements.
c. Un traitement peut être défini dans la base de données sans qu’il ne soit appliqué sur une mesure.
d. Un même traitement peut être appliqué sur plusieurs mesures.

Ce qui donnerait :

type_traitement -0,n----traiter----0,n- mesure
________________________________________________
Pour ce qui est de l'association "Engendrer", tu me suggères donc de garder une même entité "Mesure", qu'elle soit traitée ou non, mais par contre d'ajouter une association réflexive "Engendrer", comme sur le schéma ci-joint ?
Dans ce cas les cardinalités seraient définies comme suit :
a. Une mesure traitée est egendrée par au moins une mesure brute
b. Une mesure traitée peut être engendrée par plusieurs mesures brutes (concaténation des données brutes)
c. Une mesure brute peut ne pas être traitée
d. Une mesure brute peut engendrer plusieurs mesures traitées différentes

Mesure (brute) -0,n------Engendrer-----1,n--Mesure (traitée)

Dans le MCD, s'agissant, d'une association réflexive, les cardinalités sont donc permutables, n'est-ce pas ?

Du coup, le MCD ci-joint est normalisé ?

Merci

[CinePhil]

Les traitements peuvent être différents pour des mesures qui sont du même type. Les traitements peuvent également être les mêmes pour des mesures de types différents. Les mesures subissent des traitements indépendamment de leur type_mesure.

J'obtiens les cardinalités suivantes (j'ai un doute sur le "c.", mais je crois aue c'est bon...)

Association “Traiter”:
a. Une mesure peut ne subir aucun traitement.
b. Une mesure peut subir plusieurs traitements.
c. Un traitement peut être défini dans la base de données sans qu’il ne soit appliqué sur une mesure.
d. Un même traitement peut être appliqué sur plusieurs mesures.

Ce qui donnerait :

type_traitement -0,n----traiter----0,n- mesure

En fait si je comprends bien, le traitement effectué sur une mesure ne dépend pas spécialement du type de la mesure.
Mon association suivante est donc inutile :
type_mesure -1,n----générer----1,1- traitement
________________________________________________

Pour ce qui est de l'association "Engendrer", tu me suggères donc de garder une même entité "Mesure", qu'elle soit traitée ou non, mais par contre d'ajouter une association réflexive "Engendrer", comme sur le schéma ci-joint ?

Oui pour l'association réflexive mais qui est en fait direcetement une ternaire avec l'entité que tu as appelée 'type_traitement'.
Mesure -0,n--(brute)-----------traiter---(traitée)-0,1- Mesure
Type_Traitement -0,n------------|

Dans ce cas les cardinalités seraient définies comme suit :
a. Une mesure traitée est egendrée par au moins une mesure brute
b. Une mesure traitée peut être engendrée par plusieurs mesures brutes (concaténation des données brutes)

Ca je ne l'avais pas compris de ta description précédente !

c. Une mesure brute peut ne pas être traitée
d. Une mesure brute peut engendrer plusieurs mesures traitées différentes

Ca j'avais compris !

Mesure (brute) -0,n------Engendrer-----1,n--Mesure (traitée)

Oui sur ce morceau.

Dans le MCD, s'agissant, d'une association réflexive, les cardinalités sont donc permutables, n'est-ce pas ?

Ben en fait pour comprendre dans quel sens l'association fonctionne, il faut ajouter les rôles sur les branches, comme tu l'as fait ci-dessus. Du coup, les cardinalités ne sont plus permutables ! On dit que cette association est réflexive parce qu'elle porte sur une seule entité.

Du coup, le MCD ci-joint est normalisé ?

Dans ton MCD, il me semble qu'il reste un problème :
Si je fais subir à une mesure brute plusieurs traitements. Ca va engendrer plusieurs mesures traitées. On pourra retrouver de quelle mesure brute vient la mesure traitée mais on ne sait pas par quel traitement car tu as deux associations distinctes.
Il me semble que la ternaire est meilleure.

Compte tenu de cet élément nouveau pour moi :

a. Une mesure traitée est egendrée par au moins une mesure brute
b. Une mesure traitée peut être engendrée par plusieurs mesures brutes (concaténation des données brutes)

Mon association ternaire deviendrait celle-ci :
Mesure -0,n--(brute)-----------traiter---(traitée)-0,n- Mesure
Type_Traitement -0,n------------|

Du coup la table qui en découle aura une clé primaire triple :
traiter (trt_id_mesure_traitee, trt_id_mesure_brute, trt_id-traitement...)

[menas]

Merci. Je ne veux pas abuser, ce serait sympa de me répondre quand tu en auras le temps, mais j'ai encore quelques questions !

• Ben en fait pour comprendre dans quel sens l'association fonctionne, il faut ajouter les rôles sur les branches, comme tu l'as fait ci-dessus. Du coup, les cardinalités ne sont plus permutables ! On dit que cette association est réflexive parce qu'elle porte sur une seule entité.

  Comment cela se traduira-t-il au niveau du MLD (et MPD)? Par la clé primaire triple dans la table SQL dérivant de l'association ternaire ?
  
  En tous cas, je suis rassuré que cette fameuse association ternaire ne te choque pas. Je craignais aue ce soit incohérent. Merci pour ton aide.

______________________________________________

• Sachant que 2 entités distinctes semblent nécessaires pour, d'une part, la MESURE, et d'autre part, le TYPE_MESURE, penses-tu que je devrais procéder de la même manière pour TYPE_ANALYSE et TYPE_TRAITEMENT ? A priori, ce serait superflu...
  
  Est-ce une solution évolutive d'utiliser des TYPES_TRAITEMENT et TYPES_ANALYSE dont le nom est un "enum", comme je l'ai décrit dans le premier MCD ? Ou existe-t-il une façon plus pro de procéder ?

______________________________________________
Pour résumer, je garde le premier MCD que j'ai joint, avec les bonnes cardinalités, et ça devrait aller ?

Merci.

[CinePhil]

Citation:
Ben en fait pour comprendre dans quel sens l'association fonctionne, il faut ajouter les rôles sur les branches, comme tu l'as fait ci-dessus. Du coup, les cardinalités ne sont plus permutables ! On dit que cette association est réflexive parce qu'elle porte sur une seule entité.

Comment cela se traduira-t-il au niveau du MLD (et MPD)? Par la clé primaire triple dans la table SQL dérivant de l'association ternaire ?

Si tu parles des rôles sur les branches, c'est pour la compréhension du MCD, puis du MLD si les y reproduis.
Le MLD généré automatiquement par un logiciel de modélisation risque de créer automatiquement les clés étrangères avec un nom similaire qu'il faudra corriger. Mais peut-être que les logiciels de modélisation tiennent compte du rôle ?

En tous cas, je suis rassuré que cette fameuse association ternaire ne te choque pas. Je craignais aue ce soit incohérent.

Non c'est assez courant.

Sachant que 2 entités distinctes semblent nécessaires pour, d'une part, la MESURE, et d'autre part, le TYPE_MESURE, penses-tu que je devrais procéder de la même manière pour TYPE_ANALYSE et TYPE_TRAITEMENT ? A priori, ce serait superflu...

D'après ce que j'ai compris de ton MCD, une analyse engendre une ou des mesures. Il est fort probable en effet que ces analyses soient typées.
Par contre, type_traitement intervient directement dans l'association ternaire en tant que traitement unitaire faisant référence à son type. Du moins c'est comme ça que je l'ai compris.

Est-ce une solution évolutive d'utiliser des TYPES_TRAITEMENT et TYPES_ANALYSE dont le nom est un "enum", comme je l'ai décrit dans le premier MCD ? Ou existe-t-il une façon plus pro de procéder ?

Je ne sais pas si le type ENUM est standard SQL.
Chez MySQL, il me semble qu'un ENUM est en fait stocké sur un octet et que c'est le SGBD qui fait la correspondance avec la valeur textuelle de l'ENUM pour la retourner à l'utilisateur. Une sorte de clé étrangère interne à la table en quelque sorte.

Il me semble que l'entité Type_traitement va comprendre d'autres attributs. Ne serait-ce qu'un descriptif du traitement à effectuer. Pareil pour les types d'analyses - un descriptif des opérations à effectuer pour ce type d'analyse.
Mais bon c'est ton domaine d'étude, je ne fais que des suppositions.

[menas]

Merci CinePhil,

J'ai volontairement supprimé des entités et des associations du MCD, pour aller à l'essentiel.
Je vais maintenant tâcher de passer au MLD, avec l'aide d'un outil automatique pour gagner du temps. A priori le modèle est normalisé jusqu'à la 3FN, je dis bien a priori, car c'est la première fois que j'utilise MERISE.

A la prochaine,

Cordialement.