IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Utilisateur, Client -> Contact


Sujet :

Schéma

  1. #1
    Candidat au Club
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2008
    Messages : 6
    Points : 2
    Points
    2
    Par défaut Utilisateur, Client -> Contact
    Bonjour,

    J'ai un MCD tout simple qui me pose problème.

    J'ai 2 entités : des utilisateurs et des clients.
    Chaque utilisateur peut contacter plusieurs clients.
    Chaque client peut être être contacté par plusieurs utilisateurs.

    La représentation au niveau MCD donne donc ceci :


    On se rend donc compte qu'un même utilisateur ne pourra jamais contacter le même client 2 fois.

    On est donc obligé de créer une entité date


    Laquelle des 2 solutions est la bonne ?

    Au niveau MLD, pourrais-je gommer cette table DATE afin d'obtenir ceci :

    USER (#id user, nom)
    CLIENT (#id client, nom)
    CONTACT (#id user, #id_client, #date, lieu)


    J'ai également quelques autres questions plus ou moins en rapport :

    - Si j'ajoute un attribut type au contact (ex: téléphone, fax, mail donc une petite liste figée dans le temps), est-il plus intéressant de le laisser en attribut (et au niveau MDP, faire une énumération) ou en faire une entité à part ?

    - Si je souhaite enregistrer les adresse dans les entités USER et CLIENT, est-il intéressant de créer une entité ADRESSE sachant que le nombre de cas ou un utilisateur et client auront la même adresse sera très faible voire inexistant ?

    - Il y a un concept que je n'ai toujours pas bien saisi, ce sont les CIF, quelqu'un pourrait-il m'expliquer de manière simple comment cela fonctionne ?

    Merci d'avance

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut La fameuse table DATE
    Bonjour tunsty,


    Citation Envoyé par tunsty Voir le message
    Au niveau MLD, pourrais-je gommer cette table DATE
    Oui. De mon côté j’ai passé bien des nuits chez mes clients, à « gommer » à la nausée cette table qui était référencée inutilement par des dizaines d’autres et qu’il fallait maintenir, sans pour autant qu’il y ait la moindre valeur ajoutée.

    Certains AGL permettent d'éviter d'avoir à réaliser cette tâche bien fastidieuse consistant à commencer par supprimer les clés étrangères avant d'éliminer la table DATE.

    Par exemple, dans le cas PowerAMC, à partir du MCD :



    Je lui demande de produire le MLD correspondant, mais sans table DATE :



    Ceci a été rendu possible parce que l’AGL offre la possibilité de ne pas produire de table pour une entité-type :



    Par contre je n’ai pas trouvé cette possibilité avec Open ModelSphere, aussi devrez-vous faire le ménage manuellement (mais j'ai peut-être mal cherché...)

    Maintenant, quelles sont vos règles de gestion ?

    Si on interprète les diagrammes ci-dessus :
    — Le même jour un utilisateur donné peut contacter plusieurs clients ;

    — Le même jour un client donné peut être contacté par plusieurs utilisateurs (au risque qu’il finisse par en être agacé )
    Ces règles sont-elles bien les vôtres ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  3. #3
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut Enumération vs table
    Suite...

    Citation Envoyé par tunsty Voir le message
    Si j'ajoute un attribut type au contact (ex: téléphone, fax, mail donc une petite liste figée dans le temps), est-il plus intéressant de le laisser en attribut (et au niveau MDP, faire une énumération) ou en faire une entité à part ?
    En SQL il est possible de mettre en œuvre une énumération contrôlée, comme dans le cas de la colonne TypeContact ci-dessous, grâce à une contrainte appropriée (CONTACT_TYPE en l’occurrence) :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    CREATE TABLE CONTACT (
       UtilisateurId        Int                  Not null,
       ClientId             Int                  Not null,
       DateContact          Date                 Not null,
       Lieu                 Varchar(64)          Not null,
       TypeContact          Varchar(16)          Not null,
       CONSTRAINT CONTACT_PK PRIMARY KEY (UtilisateurId, ClientId, Date),
       CONSTRAINT CONTACT_TYPE CHECK (TypeContact IN ('courriel', 'fax', 'téléphone')),
       CONSTRAINT CONTACT_UTILISATEUR_FK FOREIGN KEY (UtilisateurId)
          REFERENCES UTILISATEUR (UtilisateurId),
       CONSTRAINT CONTACT_CLIENT_FK FOREIGN KEY (ClientId)
          REFERENCES CLIENT (ClientId)
    ) ;

    Néanmoins, la recommandation est de prévoir une entité-type au niveau conceptuel (donc une table au niveau MLD) ad-hoc.

    Le code SQL devient :

    TABLE TYPE_CONTACT

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    CREATE TABLE TYPE_CONTACT 
    (
       TypeContactId        Int                  Not null,
       TypeContactLibelle   Varchar(64)          Not null,
       CONSTRAINT TYPE_CONTACT_PK PRIMARY KEY (TypeContactId)
    ) ;

    TABLE CONTACT

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    CREATE TABLE CONTACT 
    (
       UtilisateurId        Int                  Not null,
       ClientId             Int                  Not null,
       DateContact          Date                 Not null,
       TypeContactId        Int                  Not null,
       Lieu                 Varchar(64)          Not null,
       CONSTRAINT CONTACT_PK PRIMARY KEY (UtilisateurId, ClientId, Date),
       CONSTRAINT CONTACT_UTILISATEUR_FK FOREIGN KEY (UtilisateurId) REFERENCES UTILISATEUR,
       CONSTRAINT CONTACT_CLIENT_FK FOREIGN KEY (ClientId) REFERENCES CLIENT,
       CONSTRAINT CONTACT_TYPE_CONTACT_FK FOREIGN KEY (TypeContactId) REFERENCES TYPE_CONTACT
    ) ;

    Le MLD correspondant :




    Le MCD correspondant est plus problématique, car CONTACT étant une association, il faut y faire participer une entité-type TYPE_CONTACT avec une contrainte selon laquelle TYPE_CONTACT ne doit pas participer à l’identification de CONTACT :



    Dans cette représentation, la flèche rouge symbolise une CIF (contrainte d’intégrité fonctionnelle) qui se lit ainsi :
    UTILISATEUR X CLIENT X DATE -> TYPE_CONTACT
    C'est-à-dire que pour chaque occurrence de UTILISATEUR X CLIENT X DATE il y a exactement une occurrence de TYPE_CONTACT, ce qui ne serait pas le cas si TYPE_CONTACT participait à l'identification de CONTACT (et ça serait le b...). A noter que CIF est synonyme de DF (dépendance fonctionnelle).

    Pour ne pas avoir à affronter des difficultés qui sont la conséquence de la vision merisienne de l’identification des associations, le plus simple est peut-être de déguiser CONTACT en entité-type « faible » (weak entity-type)...

    Version Open ModelSphere pour varier un peu :

    MCD



    Notez l’utilisation de l’identification relative (cardinalités 1,1 soulignées) qui fait que les entités-types UTILISATEUR et CLIENT participent à l’identification de CONTACT (alors qu'en lecture rapide on pourrait se dire que seule la propriété ContactDate identifie CONTACT, ce qui serait absurde).


    MLD

    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

Discussions similaires

  1. Partage de table entre différents utilisateurs client
    Par Babylonian45 dans le forum Sql Developer
    Réponses: 2
    Dernier message: 25/06/2008, 11h35
  2. probleme lors de la création d'un utilisateur sur un poste client.
    Par passion_info dans le forum Windows Serveur
    Réponses: 5
    Dernier message: 29/11/2006, 12h13
  3. modifier le mot de passe utilisateur d'un client dans active directory
    Par passion_info dans le forum Windows Serveur
    Réponses: 1
    Dernier message: 23/11/2006, 01h18
  4. 1 pb connexion client, 1 pb création utilisateur
    Par ghyslain84 dans le forum MS SQL Server
    Réponses: 6
    Dernier message: 02/06/2006, 20h44

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