Modélisation d'un attribut complexe

Version imprimable

10/01/2018, 09h54
mathro

Modélisation d'un attribut complexe

Bonjour,

je suis en train de modéliser une base de données ou j'ai deux relations:
- Produits(Code, Designation, ListEmails)
- NosContacts(Email, Nom, Tel, Fax)

l'attribut ListEmails contient plusieurs adresses mail (plus de trois): deux adresses sont de deux contactes de la relation NosContacts (une de ces adresses ce répète pour tous les Produits, une contante) et les autres ne le sont pas dans la relation NosContacts.

Un Produit a exactement deux contacts de NosContacts et un contact de NosContacts peut apparaitre dans 0 à n produits.
Pourriez vous m'aider à modéliser ce cas?

merci d'avance.
10/01/2018, 10h51
CinePhil

Ce n'est pas comme ça qu'il faut modéliser ! :aie:

Commençons par la règle de gestion :

Citation:

Un Produit a exactement deux contacts de NosContacts et un contact de NosContacts peut apparaitre dans 0 à n produits.

MCD :
Produit -2,2----avoir----0,n- Contact

Au passage, remarque que je nomme les entités-types au singulier puisque la règle de gestion exprime ce qui se passe pour une instance de chaque entité-type (vous avez écrit : "Un Produit" et "un contact").

Ce morceau de MCD peut donner les tables suivantes :
1) S'il y a un ordre de préférence ou une signification particulière à chaque contact d'un produit, on référencera les deux contacts dans la table des produits :
Contact(cnt_id, email, nom, tel, fax)
Produit(prd_id, code, designation, id_contact_1, id_contact_2)

Remarques :
- là aussi, je nomme les tables au singulier parce qu'elles sont issues des entité-types du MCD et chaque ligne de la table représente, respectivement, un contact et un produit ;
- j'ai ajouté un identifiant qui sera de type entier et auto-incrémenté parce que c'est une bien meilleure clé primaire qu'un code ou un email ;
- en plus de l'identifiant, il faudra ajouter une contrainte d'unicité (ou index de type unique selon le SGBD) sur Contact.email et sur Produit.code ;
- j'ai mis id_contact_1 et id_contact_2 pour signifier leur ordre mais si les deux contacts ont une signification, il vaut mieux l'expliciter dans le nom de la colonne (par exemple id_contact_vendeur et id_contact_chef_produit).

2) Si les deux contacts sont indifférents et ont la même signification, il vaut mieux créer une table associative :
Contact(cnt_id, email, nom, tel, fax)
Produit(prd_id, code, designation)
Produit_Contact(id_produit, id_contact)

L'avantage de cette seconde solution est que s'il y a un jour besoin d'un troisième contact à associer à un produit, pas besoin de modifier la structure des tables et, par voie de conséquence, des programmes qui interrogent la BDD.

Ensuite, il faudra éclaircir cette partie de votre message :

Citation:

l'attribut ListEmails contient plusieurs adresses mail (plus de trois): deux adresses sont de deux contactes de la relation NosContacts (une de ces adresses ce répète pour tous les Produits, une contante) et les autres ne le sont pas dans la relation NosContacts.

Vous y dites :
- qu'il y aurait non pas deux mais plus de trois contacts ;
- qu'un des contacts serait le même pour tous les produits ; pourquoi alors l'enregistrer en autant d'exemplaires que de produits ?
- que d'autres contacts ne sont pas dans "NosContacts" ; ils sont enregistrés où, alors ?
10/01/2018, 11h32
mathro

Je vous remercie pour votre réponse.

1- En ce qui concerne les contacts ils sont indifférents, ce qui nous intéresse c'est d'avoir la liste des contacts (emails) pour chaque produit.
2- J'ai dis que "il y aurait non pas deux mais plus de trois contacts" car deux contacts sont enregistrer dans la table Contact et on a au moins une autre adresse mail d'une personne qui n'est pas enregistrer dans la base. Dans votre 2ème modélisation, comment ajouter ces adresses mails?
3- "un des contacts serait le même pour tous les produits" c'est un contact qui est enregistrer dans la table Contact et qui doit apparaitre dans la liste des contacts(emails) de tous les produits, il ya t-il un autre moyen que de l'enregistrer dans toutes les instances?
4- "que d'autres contacts ne sont pas dans "NosContacts" ", ces contacts ne sont pas enregistrer dans la base de données, des personnes externes et on ne dispose que de leur adresses mails.
10/01/2018, 12h09
CinePhil

Citation:

Envoyé par mathro

1- En ce qui concerne les contacts ils sont indifférents, ce qui nous intéresse c'est d'avoir la liste des contacts (emails) pour chaque produit.

Donc il faut plutôt opter pour la solution 2.

Citation:

2- J'ai dis que "il y aurait non pas deux mais plus de trois contacts" car deux contacts sont enregistrer dans la table Contact et on a au moins une autre adresse mail d'une personne qui n'est pas enregistrer dans la base. Dans votre 2ème modélisation, comment ajouter ces adresses mails?

On peut avoir, d'une part, les contacts complets et d'autre part les emails. D'ailleurs, ne serait-il pas possible qu'un contact ait en fait plusieurs emails ?

Règles de gestion possibles :
R1.1 : Un contact possède un seul e-mail et un e-mail peut être possédé par un seul contact.
R1.2 : Un contact possède de un à plusieurs emails et un email peut être possédé par un contact.
R1.3 : Un contact possède un seul e-mail et un e-mail peut être possédé par plusieurs contacts.
R1.4 : Un contact possède de un à plusieurs emails et un e-mail peut être possédé par plusieurs contacts.

Ajoutons la règle de gestion entre les produits et les contacts, déjà établie précédemment :
R2 : Un Produit a exactement deux contacts et un contact peut apparaitre dans 0 à n produits.

MCD pour la règle R1 (et je vous laisse chercher le MCD éventuellement pour les autres règles) :
Produit -2,2----avoir----0,n- Contact -1,1----posséder----0,n- Email

Tables :
E_mail(eml_id, eml_adresse)
Contact(cnt_id, nom, tel, fax, id_email)
Produit(prd_id, code, designation)
Produit_Contact(id_produit, id_contact)

Ajoutons la règle de gestion pour les emails sans contact et associés aux produits (cette règle est hypothétique de ma part ; à vous de la formuler correctement) :
R3 : Un produit est associé à un à plusieurs emails non possédé par un contact et un email non possédé par un contact peut être associé à plusieurs produits.

Note : Ce que j'ai mis en italique dans la règle est une contrainte que je ne peux malheureusement pas dessiner dans un MCD en format texte.

Complétons maintenant le MCD :
Produit -2,2----avoir----0,n- Contact -1,1----posséder----0,n- Email
|---------------------------------------1,n-associer--------------------------------0,n----------|

Ajoutons la table associative qui en résulte :
Produit_E_Mail (id_produit, id_e_mail)

La contrainte se traduira dans la base de données par l'utilisation d'un trigger empêchant l'insertion dans la table Produit_E_Mail d'un e-mail associé à un contact.

Citation:

3- "un des contacts serait le même pour tous les produits" c'est un contact qui est enregistrer dans la table Contact et qui doit apparaitre dans la liste des contacts(emails) de tous les produits, il ya t-il un autre moyen que de l'enregistrer dans toutes les instances?

Enregistrer une information redondante est inutile. L'application qui exploite la BDD peut très bien se charger de présenter le produit avec ce contact récurrent. C'est juste éventuellement un paramètre de l'application si le contact peut changer.

Citation:

4- "que d'autres contacts ne sont pas dans "NosContacts" ", ces contacts ne sont pas enregistrer dans la base de données, des personnes externes et on ne dispose que de leur adresses mails.

Le point est résolu ci-dessus.

Pour vous aider à concevoir ainsi, je vous renvoie sur mes billets de mon ancien blog sur les règles de gestion des données et sur les tables associatives.
10/01/2018, 15h05
mathro

Citation:

On peut avoir, d'une part, les contacts complets et d'autre part les emails. D'ailleurs, ne serait-il pas possible qu'un contact ait en fait plusieurs emails ?

En effet, on ne considère que les e-mails professionnels, donc chaque personne possède un seul e-mail et un e-mail est associé à une seule personne.

J'ai des connaissances basiques dans la base de données et je ne sais pas si c'est une bonne question mais pour les Tables Produit_Contact(id_produit, id_contact) et Produit_E_Mail (id_produit, id_e_mail), l'attribut id_produit est présent dans les deux tables, celà n'est pas considéré comme une redondance?

et pour les e-mails non possédé par un contact, on ne peut pas ajouter un attribut complexe (vecteur) de taille variables (car on ne sait pas le nombre des e-mails qu'on vas introduire) dans la table Produit au lieu de créer la table e-mail?
10/01/2018, 15h41
escartefigue

Citation:

Envoyé par mathro

J'ai des connaissances basiques dans la base de données et je ne sais pas si c'est une bonne question mais pour les Tables Produit_Contact(id_produit, id_contact) et Produit_Contact(id_produit, id_contact), l'attribut id_produit est présent dans les deux tables, celà n'est pas considéré comme une redondance?

Vous citez deux fois la même table Produit_Contact:weird:
Quoi qu'il en soit, les FK (clefs étrangères) sont les seuls attributs dont la redondance n'est pas une anomalie.
Qui plus est, toute table issue d'une association a pour clef primaire la concaténation des identifiants primaires de toutes les entités-types intervenant dans la relation.
10/01/2018, 16h16
CinePhil

Citation:

Envoyé par mathro

et pour les e-mails non possédé par un contact, on ne peut pas ajouter un attribut complexe (vecteur) de taille variables (car on ne sait pas le nombre des e-mails qu'on vas introduire) dans la table Produit au lieu de créer la table e-mail?

NON !
C'est justement parce que "on ne sait pas le nombre des e-mails qu'on vas introduire" qu'il faut une table associative !
Sinon, vous retombez dans votre modèle du début qui n'est pas bon.
Dans une base de données relationnelle, les propriétés sont "atomiques". Une colonne dans une ligne de table => une seule information. Sinon on va à la catastrophe pour traiter les données. Avec une table associative, si aujourd'hui vous n'avez que deux contacts pour un produit mais que demain vous en avez 3 ou 4, vous ne changez pas la structure de votre table. Si vous voulez spécialiser les contacts de vos produits, vous pouvez ajouter une table Type_contact et l'associer avec Contact ou avec la table associative Produit_Contact. Si vous avez plusieurs contacts pour un produit dans la table des produits, vous ne pourrez pas le faire.
Relisez mon article sur les tables associatives ; je crois que c'est très bien expliqué. Et dans les commentaires, il y a une discussion avec fsmrel sur les cardinalités de type 2,2.
10/01/2018, 17h35
escartefigue

Dit autrement : à chaque fois que vous avez une liste à la place d'un attribut atomique, c'est que la modélisation est erronée ;)
11/01/2018, 08h55
escartefigue

Externalisation des serveurs de domaines

Idéalement vous pouvez ajouter une nouvelle entité-type pour les noms de domaines

Si je reprends la proposition de Cinephil, il suffit d'ajouter ce que j'ai mis en couleur ci-dessous :
...Contact -1,1----posséder----0,n- Email - 1,1 --- héberger --- 0,n Domaine

Cette modélisation vous permet, en cas de changement de domaine, de n'avoir qu'une seule ligne à modifier dans la table Domaine plutôt que toutes les lignes adresses de la table Email
Exemple : l'entreprise trukmuch est rachetée par l'entreprise bidule. Tous vos contacts de l'entreprise absorbée avaient un adresse courriel se terminant par @trukmuch.com il faut désormais remplacer ces suffixes d'adresses par @bidule.com.

Plus il y a de contacts dans cette entreprise, plus l'opération est facilitée en modélisant ainsi ;)