Discussion: Modélisation d'un attribut complexe [Modèle Relationnel]

  1. #1
    Membre à l'essai
    Femme Profil pro
    Étudiant
    Inscrit en
    avril 2013
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : avril 2013
    Messages : 36
    Points : 16
    Points
    16

    Par défaut 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.

  2. #2
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 327
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 327
    Points : 29 775
    Points
    29 775
    Billets dans le blog
    4

    Par défaut

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

    Commençons par la règle de gestion :
    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 :
    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 ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  3. #3
    Membre à l'essai
    Femme Profil pro
    Étudiant
    Inscrit en
    avril 2013
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : avril 2013
    Messages : 36
    Points : 16
    Points
    16

    Par défaut

    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.

  4. #4
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 327
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 327
    Points : 29 775
    Points
    29 775
    Billets dans le blog
    4

    Par défaut

    Citation Envoyé par mathro Voir le message
    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.

    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.

    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.

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  5. #5
    Membre à l'essai
    Femme Profil pro
    Étudiant
    Inscrit en
    avril 2013
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : avril 2013
    Messages : 36
    Points : 16
    Points
    16

    Par défaut

    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?

  6. #6
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 115
    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 : 3 115
    Points : 6 859
    Points
    6 859
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par mathro Voir le message
    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
    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.

  7. #7
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 327
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 327
    Points : 29 775
    Points
    29 775
    Billets dans le blog
    4

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  8. #8
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 115
    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 : 3 115
    Points : 6 859
    Points
    6 859
    Billets dans le blog
    1

    Par défaut

    Dit autrement : à chaque fois que vous avez une liste à la place d'un attribut atomique, c'est que la modélisation est erronée

  9. #9
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 115
    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 : 3 115
    Points : 6 859
    Points
    6 859
    Billets dans le blog
    1

    Par défaut 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

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 11
    Dernier message: 27/05/2011, 09h48
  2. Modélisation et suivi d'historique sur multi-attributs
    Par Jinroh77 dans le forum Microsoft BI
    Réponses: 3
    Dernier message: 21/02/2011, 16h22
  3. Réponses: 5
    Dernier message: 14/01/2011, 17h15
  4. Modélisation : dimension et attributs pouvant changés
    Par patriceharel dans le forum Conception/Modélisation
    Réponses: 8
    Dernier message: 06/03/2009, 16h53
  5. Modélisation MCD complexe, comment simplifier?
    Par Kalion dans le forum Diagrammes de Classes
    Réponses: 2
    Dernier message: 22/01/2009, 23h45

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