Discussion :

[menas]

Bonjour,

Je voudrais savoir s'il est d'usage de définir le chemin d'accès à des fichiers dans un MCD, tel que je l'ai fait ci-dessous.


Pour info, je voudrais arriver à une interface web PHP/MySQL, qui renvoie les fichiers associés à une mesure, ces fichiers étant des fichiers texte (.csv) et JPEG, pour afficher directement un aperçu (thumbnail) de la mesure dans que l'on ait à ouvrir le fichier.

D'autre part, est-ce que je dois créer de nouvelles entités pour normaliser mon MCD ? En effet :

• Le nombre de fichiers dépend du type de l'entité "APPAREIL" et du type de l'entité "MESURE"
• Le nombre de THUMBNAILS également
• Les attributs de CONFIGURATION APPAREIL dépendent du type d'APPAREIL

Ca fait beaucoup de dépendances ! Je m'y perd !

Et comme si ça ne suffisait pas, je ne sais pas comment définir les cardinalités, car celles-ci dépendent des différents types (Mesure, Appareil)

Association “Possède_Fichier_Mesure”:

Une MESURE possède :
> exactement 3 FICHIERs (si l'APPAREIL DE MESURE est de type S)
> ou bien, exactement 1 FICHIER (si l'APPAREIL DE MESURE est de type O ET la MESURE de type B
> ou bien, aucun FICHIER si l'APPAREIL DE MESURE est de type O ET la MESURE de type A, car l'appareil de type O ne permet pas d'effectuer ce type de mesure.

Association “Représente_Fichier_Mesure” OU “Possède_Thumbnail” [Quel chemin choisir ?]:
Une MESURE possède :
> exactement 2 THUMBNAILS (si l'APPAREIL DE MESURE est de type S)
> ou bien, exactement 2 THUMBNAILS (si l'APPAREIL DE MESURE est de type O ET la MESURE de type B
> ou bien, aucun THUMBNAIL si l'APPAREIL DE MESURE est de type O ET la MESURE de type A, car l'appareil de type O ne permet pas d'effectuer ce type de mesure.

Merci d'avance pour votre aide, parce que là je patine dans la choucroute !

[CinePhil]

Je voudrais savoir s'il est d'usage de définir le chemin d'accès à des fichiers dans un MCD, tel que je l'ai fait ci-dessous.

Oui. C'est généralement beaucoup mieux que de vouloir stocker le fichier dans la base de données.

D'autre part, est-ce que je dois créer de nouvelles entités pour normaliser mon MCD ? En effet :

• Le nombre de fichiers dépend du type de l'entité "APPAREIL" et du type de l'entité "MESURE"
• Le nombre de THUMBNAILS également
• Les attributs de CONFIGURATION APPAREIL dépendent du type d'APPAREIL

Ca fait beaucoup de dépendances ! Je m'y perd !

Euh... moi aussi avec cette explication partielle !

Et comme si ça ne suffisait pas, je ne sais pas comment définir les cardinalités, car celles-ci dépendent des différents types (Mesure, Appareil)

Association “Possède_Fichier_Mesure”:

Une MESURE possède :
> exactement 3 FICHIERs (si l'APPAREIL DE MESURE est de type S)
> ou bien, exactement 1 FICHIER (si l'APPAREIL DE MESURE est de type O ET la MESURE de type B
> ou bien, aucun FICHIER si l'APPAREIL DE MESURE est de type O ET la MESURE de type A, car l'appareil de type O ne permet pas d'effectuer ce type de mesure.

Ce qu'il faut retenir au niveau MCD c'est la règle de gestion générale suivante :
"Une mesure peut posséder plusieurs fichiers et un fichier correspond à une seule mesure."
Ce qui donne l'association suivante :
Mesure -0,n----Posséder----1,1- Fichier

Les différents cas évoqués ci-dessus me semblent trop complexes à modéliser dans le MCD. C'est plutôt au niveau du MCT qu'il faudra les prendre en comtpe. Un truc du genre :
Appareil de mesure de type S => Afficher 3 zones de saisie pour les fichiers

Association “Représente_Fichier_Mesure” OU “Possède_Thumbnail” [Quel chemin choisir ?]:
Une MESURE possède :
> exactement 2 THUMBNAILS (si l'APPAREIL DE MESURE est de type S)
> ou bien, exactement 2 THUMBNAILS (si l'APPAREIL DE MESURE est de type O ET la MESURE de type B
> ou bien, aucun THUMBNAIL si l'APPAREIL DE MESURE est de type O ET la MESURE de type A, car l'appareil de type O ne permet pas d'effectuer ce type de mesure.

Idem. Au niveau MCD, on modélisera la règle de gestion générale suivante :
"Une mesure peut posséder plusieurs thumbnails et un thumbnail ne représente qu'une seule mesure."
Mesure -0,n----Posséder----1,1- Thumbnails

Après au niveau de la pratique, les contraintes définies ci-dessus pourront être gérées par des triggers pour assurer la cohérence des données.

Bon courage !

[menas]

Merci pour ta réponse.
Penses-tu que l'association en ponitillés "Représente_Fichier_Mesure", ainsi que "Utiliser" (entre APPAREIL et OPERATEUR) peuvent être supprimés? Une boucle fermée dans un MCD c'est pas très bon signe...

[CinePhil]

Je n'avais pas regardé en détail ton MCD, ne répondant qu'aux questions posées.

Déjà, je vois que tu y as mis deux entités MESURE ! Je suppose que celle du haut est plutôt TYPE_MESURE ? Et bien sûr avec des attributs différents.

Venons-en à tes dernières questions...

Penses-tu que l'association en ponitillés "Représente_Fichier_Mesure", ainsi que "Utiliser" (entre APPAREIL et OPERATEUR) peuvent être supprimés? Une boucle fermée dans un MCD c'est pas très bon signe...

Nous avions donc deux associations :
1) Mesure -0,n----Posséder----1,1- Fichier
2) Mesure -0,n----Posséder----1,1- Thumbnails

Un FICHIER_MESURE est-il obligatoirement compris dans un THUMBNAIL ?

Si oui, alors l'association 2 est inutile puisqu'on peut retrouver l'appartenance du thumbnail à la mesure via le fichier.
MESURE -0,n----Posséder----1,1- Fichier -1,1----Représenter----1,n- Thumbnail

Ou alors on fait le contraire :
Mesure -0,n----Posséder----1,1- Thumbnail -1,n----Posséder----1,1- Fichier

Si l'appli génère d'abord le thumbnail chargé d'accueillir utlérieurement les fichiers, il vaut mieux le second schéma avec une cardinalité 0,n entre Thumbnail et Posséder (fichier) :
Mesure -0,n----Posséder----1,1- Thumbnail -0,n----Posséder----1,1- Fichier

Si non, si un fichier peut ne pas être inclus dans un Thumbnail mais qu'un thumbnail contient au moins un fichier et qu'il n'appartient qu'à une mesure, alors le premier schéma est mieux avec de même une cardinalité modifiée :
Mesure -0,n----Posséder----1,1- Fichier -0,1----Représenter----1,n- Thumbnail

À noter que ce dernier schéma avec ce couple de cardinalités (0,1 - 1,n) entraîne normalement la création d'une table associative entre Fichier et Thumbnail, de manière à éviter les clés étrangères nulles.

Passons à l'association entre appareil et opérateur...
Il me semble que ce qui importe ici c'est quel appareil de mesure a été utilisé pour faire la mesure. L'opérateur ayant effectué la mesure est une information certes importante mais indépendante de l'appareil utilisé.
En clair, l'appareil de mesure utilisé est un attribut de la mesure, pas de l'opérateur.

Donc je ferais plutôt ceci :
1) Operateur -0,n----Réaliser----1,1- Mesure
2) Mesure -1,1----Utiliser----0,n- Appareil
Configuration -0,n----|

J'ai fait une association ternaire car j'ai supposé que les configurations sont standard et dépendent peut-être du type de mesure. Si ça ne dépend que de l'appareil, on a plutôt ceci :
2) Mesure -1,1----Utiliser----0,n- Appareil -1,1----Configurer----0,n- Configuration

Mais j'ai l'impression, en voyant l'héritage sur la configuration, qu'il y a en fait deux types d'appareil et que c'est plutôt à ce niveau là qu'il faudrait faire l'héritage.
Appareil -1,1----Typer----0,n- Type_Appareil -1,1----Configurer----0,n- Configuration.

Ou bien, si comme je crois le comprendre, la configuration comprend un nombre limité de paramètres en fonction du type d'appareil :
Appareil -1,1----Typer----0,n- Type_Appareil -1,n----Avoir----1,1- Paramètre.

A vous de voir entre tous ces schémas et toutes ces suppositions la ou lesquelles sont bons.

[menas]

Merci beaucoup

Bonne journée

EDIT :
Re-bonjour,

Je te suis , une mesure ne dépend en efet que de l'apareil utilisé et de sa config, pas de l'opérateur
J'opterais pour cette solution :

Appareil -1,1----Typer----0,n- Type_Appareil -1,1----Configurer----0,n- Configuration.

Mais y a-t-il une raison particulière qui nous empêche d'associer la CONFIG à l'APPAREIL (tu suggères d'associer la CONFIG au TYPE d'APPAREIL)

Je subodore une raison subtile ça, peux-tu m'expliquer clairement pkoi ta solution est valable contrairement à la mienne ?
Je ne vois pas comment modéliser l'héritage avec la notation "partition totale" (XT). Peut-être n'est-ce pas nécessaire...?
En bref, mon souci c'est aue je ne parviens pas à formaliser ceci : "les paramütre 2,3,4,5 ne sont valables que pour l'appareil de type untel, le param 1 que pour untel...

U see what I mean ?

Merci

[CinePhil]

J'opterais pour cette solution :

Appareil -1,1----Typer----0,n- Type_Appareil -1,1----Configurer----0,n- Configuration.

Mais y a-t-il une raison particulière qui nous empêche d'associer la CONFIG à l'APPAREIL (tu suggères d'associer la CONFIG au TYPE d'APPAREIL)

C'est toi qui connais le domaine étudié beaucoup plus que nous !

A toi de voir si tous les appareils d'un certain type auront la même config quelle que soit la mesure ou si la config change selon la mesure effectuée avec un type d'appareil.

J'avais supposé que la config dépendait du type d'appareil plutôt que de la mesure, ce que semble confirmer ton adoption de mon schéma cité plus haut, ainsi que cet autre extrait de ton dernier message :

les paramütre 2,3,4,5 ne sont valables que pour l'appareil de type untel,

Et comme dans tes entités de configuration, il n'y a qu'une liste de paramètres, il me semblait plus logique que faire une entité de paramètre et d'affecter ceux-ci aux types d'appareils.

Donne nous un exemple concret de ton cas si tu veux qu'on t'aide plus efficacement à décder quelle est le bon modèle.

[menas]

Bonjour,

D'accord, je reformule ma question :
Peut-on dire que les deux schémas en piéces jointes (n°1 et n°2) sont équivalents ?
Car une occurence d'appareil sera nécessairement d'un certain type. Quelle différence y a-t-il entre associer une CONFIG à un APPAREIL d'un certain TYPE, et associer une CONFIG directement au TYPE d'appareil.

(à propos, l'association AFFECTER (en jaune) peut alors être supprimée sans pb?)

A toi de voir si tous les appareils d'un certain type auront la même config quelle que soit la mesure ou si la config change selon la mesure effectuée avec un type d'appareil.
J'avais supposé que la config dépendait du type d'appareil plutôt que de la mesure (...)

Je pars du principe qu'une CONFIG est un ensemble de paramètres propres à un TYPE d'APPAREIL. Donc indépendants du TYPE de MESURE, tu as raison.

Et comme dans tes entités de configuration, il n'y a qu'une liste de paramètres, il me semblait plus logique que faire une entité de paramètre et d'affecter ceux-ci aux types d'appareils.

Comme je le disais, un ensemble de paramètres est propre à un type d'appareil. En éclatant l'entité CONFIG en entité PARAMETRE, sera-t-il facile de spécifier la validité de chacun des paramètre pour tel TYPE d'APPAREIL ?
Sur le schéma n°3, j'ai éliminé l'aaociation Affecter aui n'a a priori plus raison d'être, et j'ai créé l'entité PARAMETRE.
Le fait d'associer une occurence de PARAMETRE directement à TYPE APPAREIL permettrait alors de spécifier la contrainte aue je cherche à modéliser ? (càd, rattachement d'un paramètre uniquement au Type d'appareil)
Ou bien faut-il ajouter un attribut dans l'entité PARAMETRE ?

A la limite, je me passerais bien de "Image Parametre 4" dans le MCD, et bricoler par la suite en PHP....j'ai hâte d'implémenter la base (et j'ai un peu peur d'avir de mauvaises surprises aussi)!

Merci

[menas]

Voilà ce que je propose.

J'espère que c'est cohérent.

Merci pour vos suggestions !

[CinePhil]

Peut-on dire que les deux schémas en piéces jointes (n°1 et n°2) sont équivalents ?

Le premier schéma suppose que la configuration d'un appareil dépend de son type alors que le deuxième permet que deux appareils du même types obéissent à deux configurations différentes. Les deux schémas ne sont donc pas équivalents.

(à propos, l'association AFFECTER (en jaune) peut alors être supprimée sans pb?)

Oui car c'est redondant avec l'autre chaîne d'associations donc ça peut produire des données incohérentes.

Ce qui pourrait être fait, c'est de dire qu'à un type de mesure correspond un type d'appareil. (éclairement => luxmètre, intensité => ampèremètre...).

Comme je le disais, un ensemble de paramètres est propre à un type d'appareil. En éclatant l'entité CONFIG en entité PARAMETRE, sera-t-il facile de spécifier la validité de chacun des paramètre pour tel TYPE d'APPAREIL ?

Ca ne pose pas de problème particulier.
A la limite c'est même peut-être plus facile parce que mettre un certains nombre de colonnes dans les différentes configuration ordonne d'une certaine façon les paramètres alors qu'une table de paramètres les donne en vrac mais reliés à un type d'appareil, éventuellement par une table associative si un paramètre peut s'appliquer à plusieurs types d'appareils.

Je veux vérifier que le paramètre bidule est bien réglé.
Avec ta solution, ce paramètre bidule est-il le paramètre 1, 2 ou 3 ? Quelle colonne interroger ?
Avec la table des paramètres, on cherche le paramètre bidule pour le type d'appareil truc dans une seule colonne de la table.

Sur le schéma n°3, j'ai éliminé l'association Affecter qui n'a a priori plus raison d'être, et j'ai créé l'entité PARAMETRE.
Le fait d'associer une occurence de PARAMETRE directement à TYPE APPAREIL permettrait alors de spécifier la contrainte que je cherche à modéliser ? (càd, rattachement d'un paramètre uniquement au Type d'appareil)

Oui.

Ou bien faut-il ajouter un attribut dans l'entité PARAMETRE ?

Au niveau MCD non. On n'y fait figurer que les attributs propres au paramètre.

A la limite, je me passerais bien de "Image Parametre 4" dans le MCD, et bricoler par la suite en PHP....

Non je le laisserais au contraire !
C'est cohérent de faire comme ça si tous les paramètres n'ont pas d'image.

Voilà ce que je propose.

J'espère que c'est cohérent.

Merci pour vos suggestions !

Je vois que tes appareils sont maintenant tous des spectromètres !
Il faudrait externaliser les fabricants des spectromètres.
Fabricant -0,n----Fabriquer----1,1- Spectromètre

Je lis :
Spectromètre -1,n----Etre de type----0,n- Type_Spectromètre

Un spectromètre peut être de plusieurs types ?

[menas]

Bonjour,

Merci pour ta réponse !

Un spectromètre peut être de plusieurs types ?

Eh oui, il ne s'agit en fait que de spectromètres, avec quelques petites différences techniques. Ces différences font que certains paramètres ne sont applicables que pour certains types de spectro, et que les types de mesures pouvant être réalisées dépendent du type de spectro.

Ce qui pourrait être fait, c'est de dire qu'à un type de mesure correspond un type d'appareil.

Tu as raison, j'avais oublié ce point. Un type de spectromètre peut réaliser certains types de mesures. Il faudrait donc associer Type_Spectro avec Type_mesure ? J'espère que ça ne créera pas de redondance.

Citation:
Sur le schéma n°3, j'ai éliminé l'association Affecter qui n'a a priori plus raison d'être, et j'ai créé l'entité PARAMETRE.
Le fait d'associer une occurence de PARAMETRE directement à TYPE APPAREIL permettrait alors de spécifier la contrainte que je cherche à modéliser ? (càd, rattachement d'un paramètre uniquement au Type d'appareil)
Oui.

Je pense que ce n'est pas suffisant. C'est pourquoi j'ai ajouté l'entité Type_paramètre ; car plusieurs PARAMETREs peuvent être du même TYPE_PARAM
ex : Plusieurs occurences possibles pour le TYPE_PARAMETRE "Température".
Merci pour ta suggestion, je trouve cette représentation (paramète au lieu de config) pas mal.

Citation:
A la limite, je me passerais bien de "Image Parametre 4" dans le MCD, et bricoler par la suite en PHP....
Non je le laisserais au contraire !
C'est cohérent de faire comme ça si tous les paramètres n'ont pas d'image.

Si j'ai bien compris, on crée une entité possédant comme attribut le chemin du fichier image, cet attribut pouvant être null si aucune image n'existe pour ce type de paramètre. Et après via de la prog (PHP) on affiche ou pas, en fonction de l'existence du chemin ...?

Voilà le MCD modifié : (je pense aue l'association "Valable pour" est superflue, compte-tenu de la cardinalité minimale à 0 :
[Paramètre]--0,1--(Posséeder Img Param)

Ce aue je crains, c'est une redondance au niveau de l'association entre le type de mesure et le type de spectro, pourtant insdispensable comme tu l'as souligné.

[CinePhil]

Un spectromètre peut être de plusieurs types ?

Eh oui, il ne s'agit en fait que de spectromètres, avec quelques petites différences techniques. Ces différences font que certains paramètres ne sont applicables que pour certains types de spectro, et que les types de mesures pouvant être réalisées dépendent du type de spectro.

Mon interrogation citée dans ton message portait sur la cardinalité ! Un spectromètre de numéro de série N n'est-il pas que d'un seul type ?

Tu as raison, j'avais oublié ce point. Un type de spectromètre peut réaliser certains types de mesures. Il faudrait donc associer Type_Spectro avec Type_mesure ? J'espère que ça ne créera pas de redondance.

Ce n'est pas de la redondance puisqu'il s'agit de dire ici que pour faire tel type de mesure il faut utiliser tel type de spectromètre.
Ensuite quand on passe à la mesure réellement effectuée, on indique quel spectromètre on utilise.
Et comme il doit être du type défini pour le type de mesure, il faut bidouiller quelque chose, une contrainte disant que le spectromètre S utilisé pour la mesure M doit être du même type T que celui préconisé par le type TM de la mesure.

Je ne sais pas trop comment représenter ça au niveau du MCD. Probablement une contrainte entre les trois associations 'Utiliser', 'Etre de type spectromètre' et 'Etre de type mesure'.
Si fsmrel passe par là...

Je pense que ce n'est pas suffisant. C'est pourquoi j'ai ajouté l'entité Type_paramètre ; car plusieurs PARAMETREs peuvent être du même TYPE_PARAM
ex : Plusieurs occurences possibles pour le TYPE_PARAMETRE "Température".
Merci pour ta suggestion, je trouve cette représentation (paramète au lieu de config) pas mal.

Oui ce que tu as fait est bon. Je 'lavais bien compris comme ça.

Si j'ai bien compris, on crée une entité possédant comme attribut le chemin du fichier image, cet attribut pouvant être null si aucune image n'existe pour ce type de paramètre. Et après via de la prog (PHP) on affiche ou pas, en fonction de l'existence du chemin ...?

Non. Puisque apparemment tous tes paramètres n'ont pas d'image, tu as l'association suivante :
Paramètre -0,1----Posséder----(1,1)- Image

Ce qui entraîne classiquement une clé étrangère référençant l'identifiant du paramètre dans la table Image. Et comme dans mon hypothèse ci-dessus une image ne se rapporte qu'à un seul paramètre, on utilise une identification relative et cette clé étrangère peut aussi être la clé primaire. Pas besoin d'identifiant propre pour l'image.
Tables :
Parametre (p_id, ...)
Image (i_id_param, ...)

Si une image peut s'appliquer à plusieurs paramètres, tu as alors ceci :
Paramètre -(0,1)----Posséder----1,n- Image

Il y aura alors une table associative 'Param_Posseder_Image' (par exemple) dont la clé primaire sera la clé étrangère référençant le paramètre puisqu'il a au maximum une seule image.
Tables :
Parametre (p_id, ...)
Image (i_id ...)
Param_Posseder_Image (ppi_id_param, ppi_id_image)

Si un paramètre peut avoir plusieurs images, on retrouve alors le classique :
Paramètre -0,n----Posséder----1,n- Image

Là encore, une table associative dont la clé primaire est cette fois composée des identifiants des deux tables entrant en jeu dans l'association :
Tables :
Parametre (p_id, ...)
Image (i_id ...)
Param_Posseder_Image (ppi_id_param, ppi_id_image)

Voilà le MCD modifié : (je pense que l'association "Valable pour" est superflue, compte-tenu de la cardinalité minimale à 0 :
[Paramètre]--0,1--(Posséeder Img Param)

Je pense aussi que l'association 'valable pour' est superflue puisqu'une image n'est que pour un paramètre et pas pour un type de paramètre.

Ce que je crains, c'est une redondance au niveau de l'association entre le type de mesure et le type de spectro, pourtant insdispensable comme tu l'as souligné.

Pas de redondance mais une contrainte entre les associations à mettre en oeuvre, comme indiqué plus haut.

Au niveau BDD, cela se traduit par un trigger pour vérifier que le spectromètre choisi est bien du type autorisé pour le type de mesure effectuée.

[menas]

Tout d'abord, merci pour le temps que tu passes.

Mon interrogation citée dans ton message portait sur la cardinalité ! Un spectromètre de numéro de série N n'est-il pas que d'un seul type ?

Très bonne remarque, mais certains spectromètres peuvent être "commutables", et donc polyvalents. On peut admettre qu'ils ont plus d'un type.

Ce n'est pas de la redondance puisqu'il s'agit de dire ici que pour faire tel type de mesure il faut utiliser tel type de spectromètre.

Je dirais plutôt "Pour faire tel type de mesure on peut utiliser tels types de spectro, et tel type de spectro peut servir à faire tels types de mesures. (d'où l'association 1,n 1,n)

Je ne sais pas trop comment représenter ça au niveau du MCD. Probablement une contrainte entre les trois associations 'Utiliser', 'Etre de type spectromètre' et 'Etre de type mesure'.
Si fsmrel passe par là...

"MERISE : Vers une modélisation orientée objet" José Morejon. Les éditions d'organisation.
Chapitre sur les contraintes sémantiques :
"Contrainte entre valeurs de propriétés:
Ces contraintes (...) n'apparaissent généralement pas dans la représentation graphique de la modélisation des données. Elles correspondent en fait à des règles sémantiques, fournies par les utilisateurs, pour modéliser des contraintes spécifiaues que le concepteur tente de représenter."
Le livre date un peu (1994), peut-être qu'aujourd'hui une notation existe pour spécifier ce genre de contrainte.

Je pense aussi que l'association 'valable pour' est superflue puisqu'une image n'est que pour un paramètre et pas pour un type de paramètre.

Pas tout à fait vrai. C'est bel et bien le type de paramètre (ainsi que le paramètre lui-même si on admet qu'une image est facultative) qui détermine l'existence d'une image.
ex : Une courbe des températures est un paramètre pouvant contenir une image (affichée sur l'interface Web, illustrant la courbe)
Alors que la pression est un paramète qui n'aura pas d'image associée associée.

Merci encore. Je m'y connais un peu plus en électronique et traitement du signal (j'ai pas dit expert!), alors si un jour t'as des questions dans ces domaines, n'hésite pas.

[menas]

Bonjour,

Peux-tu expliquer ce point s'il te plaît ? Je n'ai pas compris pourquoi un identifiant n'est pas indispensable. Merci.

Et comme dans mon hypothèse ci-dessus une image ne se rapporte qu'à un seul paramètre, on utilise une identification relative et cette clé étrangère peut aussi être la clé primaire. Pas besoin d'identifiant propre pour l'image.

[CinePhil]

Mon hypothèse était qu'une image ne se rapporte qu'à un seul paramètre mais que tous les paramètres n'ont pas d'image. En fait l'image est en quelque sorte un attribut facultatif du paramètre.

Cette hypothèse correspond au schéma suivant :
Paramètre -0,1----Avoir----(1,1)- Image

Les parenthèses indiquent une identification relative qui fait que l'image prend l'identifiant de son paramètre. Image est en quelque sorte une extension de l'entité Paramètre.

Concrêtement, les tables pourront avoir la forme suivante :
Parametre (p_id, p_attributs_autres...)
Image (i_id_parametre, i_attributs_image...)

i_id_parametre est à la fois clé primaire et clé étrangère faisant référence à l'identifiant du paramètre auquel est affecté l'image.

On utilise le même principe dans les mécanismes d'héritage :
Salarié -(1,1)----Etre----0,1- Personne
Contact -(1,1)----Etre----0,1------|

Une personne est soit un salarié, soit un contact. Il faudrait ci-dessus faire figurer une contrainte d'exclusion entre les deux associations.

Les tables qui découlent de ce schéma pourraient être les suivantes :
Personne (p_id, p_nom, p_prenom, p_adresse...)
Salarie (s_id_personne, s_indice, s_id_type_contrat...)
Contact (c_id_personne, c_id_type_contact...)

[menas]

Bonjour,

Merci infiniment !

@+