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...

[Crackerz]

Bonjour fsmrel,

L'explication sur les index est très claire et accompagner de bon articles en complément. Je vais me renseigné sur l'instruction explain.

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

A vrai dire ce nom est le titre du chapitre 15 de l'ouvrage que j’étudie à savoir : Bases de données de Jean-Luc Hainaut. Je vais me pencher du cotés de : Parlez-vous Merise ? Merci.

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}}} ?

Je pense que je n'ai pas compris ce que vous appelez LIGNE_FACTURE.
Selon moi, LIGNE_FACTURE n'a pas raison d'être, c'est-à-dire que les lignes d'une facture font partis de la facture (sous forme d'attribut) donc pourquoi séparer le contenu d'une facture dans une autre table ?
Autrement dit, FACTURE { N°Facture, DateFacture, N°Article, Quantite }

Merci.

[fsmrel]

Je pense que je n'ai pas compris ce que vous appelez LIGNE_FACTURE.
Selon moi, LIGNE_FACTURE n'a pas raison d'être, c'est-à-dire que les lignes d'une facture font partis de la facture (sous forme d'attribut) donc pourquoi séparer le contenu d'une facture dans une autre table ?
Autrement dit, FACTURE { N°Facture, DateFacture, N°Article, Quantite }

Hum... La table FACTURE dont vous fournissez l'en-tête (les noms d'attributs) doit être dotée d’une clé (disons primaire). Supposons que cette clé ait pour seul élément l’attribut N°Facture : si la table contient 1000 lignes, elles se différencient par la valeur du numéro de facture, autrement dit deux factures distinctes ne peuvent pas avoir le même numéro de facture.

Supposons que la première ligne de la table contienne les données de la facture de numéro 1, que la 2e ligne contienne les données de la facture de numéro 2, etc., et que la 1000e ligne contienne les données de la facture de numéro 1000 :

Code :

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

1
2
3
4
5
6
7
 
N°Facture    DateFacture    N°Article    Quantite
        1    15/03/2010     314115             10
        2    17/05/2010     271828             50
        3    17/05/2010     314115             30
...
     1000    25/11/2012     926535             15

Dans ce système (où j’ai souligné la clé), comme il n’y a qu’une seule ligne de la table qui puisse avoir le numéro de facture 1, la facture concernée ne pourra faire mention que d’un seul article, en l’occurrence l’article de numéro 314115.

Pourtant, dans le cas général, une facture fait mention d’un nombre quelconque d’articles, mais dans notre exemple ça n’est pas possible...

Pour s’en sortir, on peut par exemple envisager la mise en œuvre d’un RVA (Relation Variable Attribute) dont j’ai déjà parlé, on peut encore se dire : « Le numéro de facture ne suffit pas, ajoutons le numéro d’article à la clé, laquelle devient donc : {N°Facture, N°Article} ». Cette fois-ci, (clé à nouveau soulignée), on peut ajouter des articles (pas deux fois le même) à une facture donnée :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
N°Facture    DateFacture    N°Article    Quantite
        1    15/03/2010     314115             10
        1    15/03/2010     926535             70
        1    15/03/2010     359793             70
        2    17/05/2010     271828             50
        3    17/05/2010     314115             30
        3    17/05/2010     123456             20
...
     1000    25/11/2012     926535             15

Mais vous observerez que dans la table, chaque ligne attribuée à la facture 1 comporte la même date, ce qui est normal puisqu’une facture ne peut avoir qu’une date, laquelle ne dépend évidemment pas du numéro d’article. En fait on vient de se planter, on a violé la 2e forme normale, c'est affreux, mais c'est un classique chez les débutants, et il faut mûrir...

Pour revenir à la raison, on applique (consciemment ou pas) ce qu’on appelle le théorème de Heath, lequel nous demande, pour éviter de commettre la faute, de décomposer la table FACTURE en deux tables, T1 et T2 :

T1 {N°Facture, DateFacture}

T2 {N°Facture, N°Article, Quantite}

Comme par hasard, T1 représente les données monovaluées (ne prenant qu’une seule valeur par facture, en l’occurrence la date de la facture), et T2 représente les données multivaluées de la facture, à savoir article et quantité.

Il est d’usage de renommer T1 en FACTURE et T2 en LIGNE_FACTURE ou quelque chose comme ça.

[Crackerz]

Bonjour,

L'exemple est beaucoup plus claire grâce à vos explications !

Suite à la lecture de lien que vous m'avez prescrit notamment Parlez-vous Merise ? de nouvelle interrogation me sont venue. Je vous les fait savoir à la suite, elles sont aux nombres de trois :

1)Est-ce qu'il y a une méthode pour nuancer ce qui dois être gérer par la modélisation de la base de donnée à ce qui dois être traiter par le code lors du développement ?
Pour être plus précis prenons un exemple, un contact peut créer un devis, si ce devis est accepter par le client alors un "travaille" est ouvert, dans le cas contraire
le devis est conservé mais "refuser". (aucun travaille ne sera ouvert)

[contact]---0,N---(créer)---0,1---[devis]----1,1----(correspond)----1,N----[travaille]

2)J'ai du mal à savoir quand est-ce qu'on à affaire à une relation n-aire pour simplifier la chose : ternaire.
Prenons un exemple (toujours dans le même thème), un contact peut établir une facture concernant un travaille pour un client.
Si la facture est établit ces qu'un travaille doit être créer avec les informations de la facture ( pas de facture dans le vide..), un travaille peut être créer sans pour autant qu'il n'y ai encore du de facture.
On remarque donc que CONTACT, TRAVAILLE et FACTURE sont plus ou moins relié, d’où ma question comment savoir lorsque cela nécessite une relation n-aires (ternaire ici) ou non.
Ma vision des choses en relation binaire.

[CONTACT]--0,N--(Créer)--1,N[TRAVAIL]--1,1 (Pour)-- 0,N[CLIENT]
[CONTACT]--0,N--(Créer)--1,1[FACTURE]--1,1--(associer)--0,N[TRAVAIL]--1,1(Pour)-- 0,N[CLIENT]

Pour être sur que j'ai bien modélisé la situation à laquelle je pense, je vous donne la traduction littéraire :
Un contact peut Créer plusieurs Travaux pour plusieurs Client.
Un contact peut également créer plusieurs facture associer à un travail (le même ou un autre) pour un client.

La subtilité selon moi réside dans la deuxième ligne de la traduction, effectivement, si une facture est établit l'entité travail doit être remplit en conséquence ,ma traduction littéral ne mentionne jamais ce cas.
Hâte de savoir comment vous procéderez dans une telle situation

3)Enfin, au vu de ce que vous pensez du bonhomme nulle pourriez-vous m'affirmer que toute situation peut être modéliser sans son intervention ? ou durant votre expérience avez-vous été amené à le prendre en considération dans certains cas. Cette question vient du fait que lorsque je m'entraîne à modéliser différentes solutions, la valeur null s'y référence quelques fois.

Merci pour le temps que vous prendrez à me répondre

[fsmrel]

Bonsoir Crackerz,

A vrai dire ce nom est le titre du chapitre 15 de l'ouvrage que j’étudie à savoir : Bases de données de Jean-Luc Hainaut

Jean-Luc Hainaut est un crack, on lui doit l’excellent DB-MAIN, gratuit de surcroît. Je n’ai pas son ouvrage, mais en fouillant dans ses articles, on constate qu’au niveau MCD, on dispose du concept d’attribut multivalué (Multivalued Attribute), permettant d’emboîter une entité-type dans un attribut, grâce à quoi on peut donc retrouver le concept de RVA.

Ainsi, avec DB-MAIN on peut définir l’attribut LIGNE_FACTURE comme étant composé d’autres attributs, à savoir N°Ligne, N°Article et Quantite. FACTURE a pour identifiant N°Facture et LIGNE_FACTURE a pour identifiant N°Ligne :





Mais le MLD généré par DB-MAIN est le suivant, dans lequel il n’y a pas de RVA, ici LIGNE_FACTURE est une table à part entière, au même titre que FACTURE :

[fsmrel]

Bonsoir Crackerz,

Est-ce qu'il y a une méthode pour nuancer ce qui doit être géré par la modélisation de la base de données et ce qui doit être traité par le code lors du développement ?

Traiter par le code de développement est quelque chose dont le sens évolue avec le temps.
Bien des règles ayant trait à la modélisation des bases de données, qui il y a trente ans étaient traitées de manière applicative, sont aujourd’hui sous-traitées au SGBD. Par exemple, dans le cas de DB2, jusqu’en juin 1988, on programmait soi-même le contrôle des contraintes d’intégrité référentielle, en PL/1, en COBOL, en assembleur ou autre langage de son choix, et enfin on a pu mettre tout le code correspondant à la poubelle (ouf !). Pour Oracle et compagnie, il a fallu attendre encore quelques années supplémentaires. Le jour on l’on a disposé des triggers, même principe, on a pu rapatrier bien des contrôles du côté du SGBD. Et ça sera encore mieux le jour où les SGBD permettront de déclarer des assertions (c'est-à-dire mettre en œuvre l’instruction CREATE ASSERTION décrite par la norme SQL). Par parenthèses, tout ce qui fait référence à la base de données et à ses tables peut aujourd’hui être développé dans un langage approprié (PL/SQL pour Oracle, T-SQL pour SQL Server, etc., et la norme fournit SQL/PSM).

« Nuancer » dépend donc de l’époque à laquelle on se situe, des types de traitements à réaliser et de ce que propose le SGBD. En gros, tout ce qui est contrôle (ne serait-ce qu’un banal contrôle de structure de date) devrait être du ressort du SGBD, les programmes étant chargés pour leur part de produire, tout en sachant qu’avec SQL, les triggers peuvent y prendre une part active (c’est du reste en réalité leur finalité selon leurs inventeurs Don Chamberlin et son équipe du prototype System R, où les assertions sont dédiées aux contrôles).

Pour être plus précis prenons un exemple, un contact peut créer un devis, si ce devis est accepté par le client alors un "travail" est ouvert, dans le cas contraire le devis est conservé mais "refusé" (aucun travail ne sera ouvert).
[contact]---0,N---(créer)---0,1---[devis]----1,1----(correspond)----1,N----[travaille]

En l’occurrence, avec SQL on sait évidemment effectuer les contrôles garantissant la santé de la base de données, mais on peut même produire. Supposons que le contact Raoul vienne de proposer un devis au client Fernand. Le statut du devis est « proposé » (cf. attribut DevisStatut ci-dessous, lequel ne peut prendre que les valeurs « proposé », « refusé » et « accepté », valeurs évidemment contrôlées par le SGBD avec la clause CHECK VALUES associée à l’attribut).
Si le devis est refusé, la personne chargée d’enregistrer l’événement modifiera la valeur de l’attribut DevisStatut qui passera à l’état « refusé ».

Si le devis est accepté, au moment de l’update du devis, par trigger on pourra demander au SGBD de participer aux opérations, de créer une ligne dans la table TRAVAIL, avec par convention valorisation de l’attribut TravailDate à la date du jour, et de l’attribut TravailDescription avec une chaîne vide. A charge de qui de droit par la suite de modifier la date si nécessaire et de renseigner TravailDescription.




Maintenant, pour en revenir à la modélisation, si vous tenez à ce que le travail créé fasse mention du devis qui en est à l’origine, vous pourrez préférer modéliser ainsi :

[Crackerz]

Merci fsmrel.

[fsmrel]

Bonne route, Crackerz !


François