Discussion :

[Crackerz]

Bonjour,

Actuellement dans des exercices , je m'entraîne à la modélisation ce basant sur l'entité-association.
Et je me pose cette même question, peut-on regrouper deux entités dans une même entité lorsqu'il corresponde à un même thème. En effet, prenons un exemple, les entreprises et "utilisateurs" peuvent être considérer comme étant des clients ( d'une autre entité, peu importe ce n'est que pour l'exemple appelons là X).

[ X ] ----- travailler ----- [ client ] //Entité X travaille avec un client(qui est soit une entreprise ou un utilisateur dans l'exemple).

Cependant comment modéliser que le client correspond à une des deux entités ? Sachant qu'ils ne partagent pas les même attributs.

La solution que j'ai envisagé vis à vis d'un tel problème est de dissocier les deux entités(Utilisateur et Entreprise) :
[X] ----- travailler ------- [ Utilisateur ]
[X] ----- travailler ------- [ Entreprise ]

(Je précise que j’étudie ce domaine pour les base de donnée relationnelle.)

Sans avoir un regard de modélisation, le rendu avec des tables je pense plutôt à ça ( je sais pas si ma modélisation signifie vraiment la même chose ).
T_X(id,nom, prénom,....)
Utilisateur(id,nom,prenom,adresse,...)
Entreprise(id, nomEntreprise, ..... )
Client(id, id_X, id_Utilisateur, id_Entreprise) //Un même travaille ne peut être fait avec deux entités différentes donc id_Utilisateur Ou id_Entreprise prendra la valeur null. Cependant je vous avou que je n'aime pas vraiment cette méthode par la présence de null..... :/

(Les cardinalités ont été ignoré volontairement afin de ne pas alourdir mon problème de compréhension ).

Merci pour toutes les informations que vous me donnerez !

[fsmrel]

Bonsoir Crackerz,


Un utilisateur est un client et une entreprise est un client : on procède à la généralisation des concepts d’utilisateur et de d’entreprise selon le concept de client, en factorisant dans l’entité-type CLIENT (surtype) les attributs communs (Nom, adresse de courriel, téléphone, etc.) et on conserve les attributs spécifiques dans les entités-types UTILISATEUR et ENTREPRISE (sous-types). Ces sous-types n’ont pas à être identifiés de façon spécifique, ils héritent en effet automatiquement de l’identifiant (ClientId) du surtype.

MCD



Cela n’empêche pas qu’un sous-type soit doté d’un identifiant supplémentaire (ou plusieurs), cas du Numéro Siren de l’entreprise. Même chose en ce qui concerne le surtype, cas de l’adresse de courriel :




MLD correspondant :



Où :

<pk> est le mickey qui symbolise l’appartenance d’un attribut à la clé primaire d’une table ;

<ak> est le mickey qui symbolise l’appartenance d’un attribut à une clé supplémentaire ;

<fk> est le mickey qui symbolise l’appartenance d’un attribut à une clé étrangère, c'est-à-dire qui fait référence à une clé primaire (ou supplémentaire) d’une autre table.

[Crackerz]

Bonjour merci pour cette première réponse !

Il y a cependant des choses que je ne suis pas sur d'avoir compris.
Pourquoi la table "travailler_avec" contient une clé primaire composée (Xid,ClientId) ? Cela voudrait dire qu'une entité X ne peut effectuer qu'un travail avec le client ?

Enfin, je ne comprend pas ce que signifie les flèche rouge et ce que vous voulez dire par " <ak> est le mickey qui symbolise l’appartenance d’un attribut à une clé supplémentaire ; ". J'étudie le modèle entité-association étendu via un bouquin et il n'a jamais fais référence à de tel annotation , merci à vous

[fsmrel]

Bonsoir Crackerz,

Pourquoi la table "travailler_avec" contient une clé primaire composée (Xid, ClientId) ? Cela voudrait dire qu'une entité X ne peut effectuer qu'un travail avec le client ?

Au niveau du MCD, les pattes connectées sur l’association TRAVAILLER_AVEC sont porteuses de cardinalités 0,N, ce qui signifie qu’un X peut travailler avec plusieurs clients et qu’un client pet travailler avec plusieurs X.

En conséquence de quoi, au niveau du MLD, la clé de la table TRAVAILLER_AVEC dérivée de l’association TRAVAILLER_AVEC a pour clé primaire la paire {Xid, ClientId}. Je mets ces noms d’attributs entre accolades parce qu’une clé est un ensemble, tout en rappelant que dans un ensemble il ne peut pas y avoir d’éléments en double.


Si les X sont Albert, Bernard et Carole, et si les clients sont Fernand, Raoul, Paul et Tomate :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
X                          CLIENT

Xid    Xnom                ClienId   ClientNom   ClientAdrCourriel
---                        -------
  1    Albert                    1   Fernand     fernand@machin.fr
  2    Bernard                   2   Raoul       raoul@volfo.fr
  3    Carole                    3   Paul        Paulo@volfo.fr
                                 4   Tomate      Toto@abcd.be

Albert travaille par exemple avec Fernand et Raoul, Carole travaille avec Raoul et Tomate :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
TRAVAILLER_AVEC

Xid     ClientId
---     --------
  1            1
  1            2
  3            2
  3            4

Vous pouvez constater que la paire {Xid, ClientId} ne contient pas de doublons.


Si vous ne disposez pas d’outil de modélisation, vous pouvez utiliser MySQL Workbench qui est gratuit (voyez l’article que je lui ai consacré). On est au niveau MLD (il n’y a pas de MCD), ça suffit largement pour entrer dans le monde de la modélisation.

MLD : variante MySQL Workbench (j’ai renommé X en CONTACT, ça cause plus) :

Je ne comprends pas ce que signifie les flèche rouge

C’est juste un dessin pour attirer l’œil sur le mickey <ai>...

et ce que vous voulez dire par " <ak> est le mickey qui symbolise l’appartenance d’un attribut à une clé supplémentaire ; "

Il s’agit de la notation utilisée par l’AGL PowerAMC : « ak » est l’abréviation de alternate key, ce que l’on peut traduire par clé alternative, clé supplémentaire, clé de rechange, etc.

Je vous rappelle qu’une clé candidate (c'est-à-dire primaire ou alternative) est un ensemble K d’attributs d’une table T tel que :

— Deux lignes distinctes de T ne peuvent pas avoir la même valeur pour K (règle d’unicité) ;

— Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité (règle d’irréductibilité).

Par exemple, le sous-ensemble K1 = {ClientId, ClientNom} de l’en-tête de la table CLIENT vérifie la règle d’unicité, mais pas celle d’irréductibilité, car K2 = {ClientId}, sous-ensemble strict de K1, garantit aussi la règle d’unicité. Au mieux K1 est ce qu’on appelle une surclé, tandis que K2 (irréductible) est clé candidate.

Table ENTREPRISE : {ClientId} est clé candidate de cette table, mais il en va de même pour {NoSiren} puisque deux entreprises ne peuvent pas avoir le même numéro Siren. Si vous retenez {ClientId} pour être clé primaire de la table, alors {NoSiren} sera ravalée au rang de clé alternative (adjectif qualificatif plus approprié pour le courant électrique, mais on fera avec).

CLIENT_CONTACT : La paire {ClientId, ContactId} est clé candidate de cette table, elle n’est pas réductible. En effet l’attribut ContactId (anciennement Xid) prend deux fois la valeur 1 (et prend deux fois aussi la valeur 3), et l’attribut ClientId prend deux fois la valeur 2.

[Crackerz]

Bonjour,

Merci pour toutes ces informations, c'est plus claire à présent.

Si vous ne disposez pas d’outil de modélisation, vous pouvez utiliser MySQL Workbench qui est gratuit (voyez l’article que je lui ai consacré). On est au niveau MLD (il n’y a pas de MCD), ça suffit largement pour entrer dans le monde de la modélisation.

Avant tout merci d'avoir pris le temps de rédiger un tel article, je l'ai lu dans son intégralité. Suite à cette lecture je me pose deux questions :

1)Comment déterminer le bonne ordre des colonnes d'une clés (vis-à-vis de la performance) ? Vous y faîtes référence ici.

2)Je ne comprend pas bien pourquoi les lignes d'une facture ne font pas partir de ses attributs : Facture(id,nom,.....). Cette logique semble appliquer également pour les lignes d'une commande. Vous pouvez visualiser les deux paragraphes concernant mon problème respectivement ici et ici

Pour terminer, pourriez-vous m'indiquer l'indispensable que je dois connaître afin d'avoir un bon niveau en modélisation ?
Je suis un peu perdu sur toutes les notions : Merise, UML, entité-association étendue, faire un MCD avant un MLD, ....

Merci.

[fsmrel]

Bonsoir Crackerz,

Comment déterminer le bonne ordre des colonnes d'une clés (vis-à-vis de la performance) ? Vous y faites référence ici.

Bonne question !

Pour reprendre l’exemple auquel vous faites allusion : Changer l'ordre des colonnes d'une clé :

Si l’on exécute une transaction de prise de commande, il est probable que les dépôts ne seront pas (ou peu) concernés dans les requêtes SQL correspondantes, alors que les articles le seront (deux fois plutôt qu’une !) Dans ces conditions, il est évident que la clé de l’index doit être ainsi ordonnée : {ArticleId, DepotId}. Par contre, si l’on effectue des traitements d’inventaire dans les dépôts, c’est la séquence { DepotId, ArticleId} qui est à privilégier et l’on créera l’index qui va bien (de façon provisoire ou définitive), car il ne s’agit quand même pas de supprimer l’index {ArticleId, DepotId} et pénaliser la prise de commandes.

Le choix des index est bien sûr décisif pour la performance des applications. Il s’agit donc d’identifier les traitements les plus sensibles, tels que la prise des commandes, et vérifier que les requêtes SQL hébergées ne se traîneront pas au motif d’une absence d’index (en supposant que ces requêtes ont été codées correctement...) Anticiper, prévoir les performances passe par un travail de prototypage, c'est-à-dire de mesure des performances des requêtes SQL avant même que les développements ne commencent. Un outil incontournable pour connaître le comportement de l’optimiseur du SGBD : l’instruction EXPLAIN.

Mais attention à ne pas abuser des index, car si les opérations de lecture en sont les principales bénéficiaires, les opérations de mise à jour peuvent être pénalisées, voyez par exemple le paragraphe Retour sur la dénormalisation a priori de l’article traitant de la normalisation.

Voyez aussi cette partie : Identification relative versus identification absolue.

« Je ne comprend pas bien pourquoi les lignes d'une facture ne font pas partir de ses attributs : Facture(id,nom,.....) »

Voulez-vous dire que vous souhaiteriez que l’entité-type FACTURE puis la table qui en sera dérivée aient cette allure :

FACTURE {N°Facture, DateFacture, {LIGNE_FACTURE{N°Ligne, N°Article, Quantite}}} ?

Si c’est le cas, c’est que vous modéliserez un RVA (Relation Valued Attribute}, mais au stade SQL, alors vous sortirez du champ de ce langage, autant renoncer tout de suite et faire une entité-type de LIGNE_FACTURE...

Je suis un peu perdu sur toutes les notions : Merise, UML, entité-association étendue, faire un MCD avant un MLD, ....

Pour ce qui concerne Merise, voyez l’ouvrage dont Michel Diviné nous a généreusement fait cadeau, Parlez-vous Merise ?. UML : voyez après, sinon vous allez tout mélanger. Par « entité-association étendue », je suppose que vous faites allusion à la note de bas de page ici, mais vous allez rentrer dans la jungle des variantes du modèle E/R de Chen : pour le moment restez-en prudemment à Merise : étude du MCD puis du MLD, même si avec MySQL Workbench on escamote la partie MCD pour jouer directement au niveau MLD...