Discussion :

[wafiwafi]

Bonjour,
J’ai remarqué que dans certains modèles, on prend le choix de considérer une entité Date en relation avec d’autres entités qui en ont besoin. Je ne vois pas du tout l’utilité d’une telle considération ; c’est plutôt une table de plus à gérer !
Personnellement, si j’ai besoin d’une date, je fais appel tout simplement à un attribut de type date.
Je me trompe certainement pour ce choix, et j’aimerais trouver mon erreur.
Merci à vous

[Richard_35]

Bonjour Wafiwafi,

Eh bien, comme souvent, il n'y a pas de vérité universelle (ou alors elle est ailleurs...).

Je pense que, généralement, nous avons besoin d'une entité Date, quand l'usage d'un calendrier se fait sentir (planning, jours fériés/ouvrés/ouvrables, ...). Nous parlons donc, dans ce cas, d'une entité Calendrier.

Effectivement, si c'est pour stocker une date "simple" (date d'inscription, date du dossier, ...), il est inutile de créer une entité à part entière : un attribut de type Date (donc contrôlé par le système) suffit largement. En fait, dans ce cas, c'est le système qui possède une entité Calendrier et qui nous en fait profiter via le type de champ Date.

[fsmrel]

Bonsoir,

J’ai remarqué que dans certains modèles, on prend le choix de considérer une entité Date en relation avec d’autres entités qui en ont besoin. Je ne vois pas du tout l’utilité d’une telle considération ; c’est plutôt une table de plus à gérer !
Personnellement, si j’ai besoin d’une date, je fais appel tout simplement à un attribut de type date.
Je me trompe certainement pour ce choix, et j’aimerais trouver mon erreur.

Vous êtes piégé par le sophisme qui part de la prémisse (évidemment fausse) selon laquelle toute entité-type d’un MCD merisien donne lieu à une table du MLD.


Prenez le cas des règles de gestion suivantes :

A une date donnée, un fournisseur donné peut fournir plusieurs produits,

A une date donnée, un produit donné peut être fourni par plusieurs fournisseurs,

Un fournisseur donné peut fournir un produit donné à des dates différentes.

Considérez maintenant le MCD ci-dessous dans lequel Merise impose la mise en œuvre d'une entité-type DATE du fait de la présence d'une association ternaire, elle-même conséquence des règles de gestion :



Je demande à mon AGL — PowerAMC en l’occurrence — 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 une table pour chaque entité-type :




Bref, encore une légende à détruire...

[wafiwafi]

Très pertinent et convainquant.
Merci à vous

[ok.Idriss]

Bonjour.

J'ai comme vous l'habitude de représenter, au niveau conceptuel, une entité Date (ou autre) lorsque celle-ci doit participer à la clef de la relation issue de l'association.

Voici d'ailleurs ce que j'avais écris à ce sujet : http://ineumann.developpez.com/tutor...rise/#LIII-C-2

Cependant, je suis déjà tombé sur une écriture différente avec laquelle on se contente d'ajouter une propriété date à l'association en la soulignant pour indiquer qu'elle fait partie de l'identifiant de cette dernière. Je me demande si cette écriture est valide, qu'en pensez-vous ?

Merci.

Cordialement,
Idriss

[Richard_35]

Bonjour Ok.Idriss,

Cependant, je suis déjà tombé sur une écriture différente avec laquelle on se contente d'ajouter une propriété date à l'association en la soulignant pour indiquer qu'elle fait partie de l'identifiant de cette dernière. Je me demande si cette écriture est valide, qu'en pensez-vous ?

==> personnellement, c'est ce que je fais : cela permet de ne pas "alourdir" un MCD (parfois déjà bien dense).

Mais, c'est vrai, l'opinion des "merisiens de naissance" concernant ce formalisme serait précieuse.

[CinePhil]

OK.Idriss, lorsque l'entité type fictive Date participe à la clé primaire, il est peut-être plus propre de la faire figurer.

Mais imaginons que la propriété portée par l'association, et qui doit participer à son identification, ne soit plus une date mais par exemple un simple code sur une lettre.
Si on crée une entité type pour ce code, mais qu'à cette lettre ne soit affilié aucun libellé explicatif, cela ferait créer une table des codes ne contenant qu'une seule colonne et de 26 lignes (si l'on s'en tient à notre alphabet français bien entendu !). Certes, cela aurait pour mérite de fixer les valeurs acceptables pour ce code mais c'est quand même un peu luxueux.

On peut même imaginer que la propriété serait un simple booléen, autorisant ainsi le couple d'entités types associées à figurer deux fois dans l'association. On ne créerait alors pas d'entité type pour ce booléen.

Dans la pratique, je penche moi aussi en direction de l'allègement du MCD et je préfère faire figurer la propriété de date dans l'association.

fsmrel aura peut-être un avis plus rigoureux sur la question ?

[fsmrel]

Bonsoir tous,

Voici d'ailleurs ce que j'avais écris à ce sujet : http://ineumann.developpez.com/tutor...rise/#LIII-C-2

J’avais complètement oublié votre article sur lequel il y a des choses à dire. Par exemple, en ce qui concerne la date, vous devriez modifier la teneur du paragraphe III-A-2-a. Règle 1 - conversion d'une entité, préciser que la règle n’est pas absolue et y faire figurer un renvoi au paragraphe III-C-2.

Je suis déjà tombé sur une écriture différente avec laquelle on se contente d'ajouter une propriété date à l'association en la soulignant pour indiquer qu'elle fait partie de l'identifiant de cette dernière. Je me demande si cette écriture est valide, qu'en pensez-vous ?

J'espère qu'en tombant vous ne vous êtes pas fait trop mal...

Pour le reste, je ne suis pas un spécialiste de Merise, je ne fais pas autorité, mais je fais le constat suivant :

Dans les ouvrages de référence, par exemple La méthode Merise, Tome 1 Principes et outils de H. Tardieu, A. Rochfeld, R. Colletti (5e impression de l’ouvrage, 1991), je note que le paragraphe 4.4.5. « Formalisme graphique » fournit une grammaire, et selon celle-ci une association (relation-type dans l’ouvrage) n’a pas d’identifiant.

Dans un autre ouvrage de référence : Ingénierie des systèmes d'information : Merise, deuxième génération de D. Nanci et B. Espinasse, il est écrit en toutes lettres (cf. paragraphe « Identification d’une relation type ») :

Une relation type n’a pas d’identifiant propre.

Remontons le temps, et venons-en à l’époque à laquelle naquit MERISE ; faisons référence à l’ensemble des documents officiels « Méthode de définition d’un système d’information », émis par le centre technique informatique (CTI) du Ministère de l’Industrie (Mission à l’informatique). Faisons référence plus précisément au fascicule 4, « Guide pratique pour l’élaboration des modèles de données et de traitements », daté de juin 1979. On y lit (page 9) :


Pardon pour la qualité de la photo...

Maintenant, si vous prenez la précaution de rappeler la définition donnée par le CTI de l’identifiant de l’association et d’avertir que vous utilisez une définition étendue, je ne vois pas pour quelle raison un gardien du temple vous interdirait la représentation suivante en ce qui concerne les livraisons des produits par les fournisseurs (évolution, oui, révolution, non) :




A titre d’exemple, un AGL comme DB-MAIN le permet (avec une notation un peu différente) :




D’où le MLD :

L'opinion des "merisiens de naissance" concernant ce formalisme serait précieuse.

Je pense que le document du CTI est la référence incontournable, mais que l’évolution est possible (et même souhaitable). Dans cet esprit, avec DB-MAIN la possibilité d’agir sur l’identifiant d’une relation permet de se dispenser des CIF et autres DF merisiennes :

Par exemple, dans un monde non quantique, lors d’une course hippique un jockey ne peut monter qu’un seul cheval, un cheval ne peut être monté que par un seul jockey et être porteur d’un seul numéro. Ces 3 règles de gestion peuvent être prises en compte ainsi avec DB-MAIN :



Je vous laisse modéliser (représentation graphique) ceci en Merise « classique » avec respect des 3 règles de gestion ci-dessus.

[ok.Idriss]

Re bonsoir.

vous devriez modifier la teneur du paragraphe III-A-2-a. Règle 1 - conversion d'une entité, préciser que la règle n’est pas absolue et y faire figurer un renvoi au paragraphe III-C-2.

Je suis d'accord. La façon dont c'est formulé "Toute entité devient une relation[...]" laisse penser que cette règle est absolue alors qu'elle est contredite quelques paragraphes plus loin

Bon en ce moment j'ai un peu moins le temps de rédiger, j'avais un article sur l'optimiser et l'algèbre relationnel en suspend que je n'ai toujours pas pris le temps de continuer ... mais pour cette mise à jour, j'essayerai de la faire prochainement.

Et merci pour les explications de qualité comme toujours

Idriss

[fsmrel]

Je vous laisse modéliser (représentation graphique) ceci en Merise « classique » avec respect des 3 règles de gestion ci-dessus.

J'espère qu'il n'y a pas de confusion, en disant cela, je ne m'adresse pas particulièrement à Richard, mais à tous

Par contre, si Richard veut bien noter les copies...

[Correcteur] -- 0,N ---- (Noter) ---- 1,1 -- [Copie]

Espérons que N ne restera pas à 0...

[CinePhil]

Je vous laisse modéliser (représentation graphique) ceci en Merise « classique » avec respect des 3 règles de gestion ci-dessus.

Compte tenu de la contrainte d'unicité pour une course sur le numéro porté par le jockey et par son cheval, je transformerais "PARTICIPER" en entité type associative "PARTICIPATION" identifiée relativement au couple {jockey, cheval} et avec la propriété Numéro qui participe à l'identification de l'entité associative.

Avec Open Modelsphere, ça donne ce MCD :

Et ce diagramme Entité / association :

EDIT :
À la relecture, je constate quand même un défaut à mon schéma : Un couple {jockey, cheval} ne peut pas participer à deux courses avec le même numéro !

Si j'ajoute la course à l'identification de la participation - ce qui reviendrait à rétablir l'association ternaire de départ - un couple {jockey, cheval} peut participer avec plusieurs numéros à la même course !

À ce stade de ma réflexion, je ne ferais finalement pas participer le numéro à l'identification de l'association et je mettrais une contrainte sur l'unicité du numéro pour une course.

[Richard_35]

Bonjour à tous,

J'allais le dire, Philippe !... avec une petite nuance.

En décomposant la réflexion, avec BlocNote , cela donnerait ceci :

1°/ Idée brute (dans les deux sens...) :

Code :

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

1
2
3
4
5
6
7
8
9
               Course
                 |
                0,n
                 |
            [Participer]
                 |
                0,n
                 |
Jockey -0,n---[Monter]---0,n- Cheval

2°/ Si l'association entre deux associations n'est pas permise, décomposition de la relation n,n (comme indiqué par Philippe) :

Code :

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

1
2
3
4
5
6
7
8
9
                                  Course
                                    |
                                   0,n
                                    |
                               [Participer (N°)]
                                    |
                                   0,n
                                    |
Jockey -0,n---[Monter]---1,1- Jockey_Cheval -1,1---[Etre monté]---0,n- Cheval

3°/ Ou encore, dans le même esprit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
                                  Course
                                    |
                                   0,n
                                    |
                               [Participer]
                                    |
                                   1,1
                                    |
                               Participation
                                    |
                                   1,1
                                    |
                               [Participer]
                                    |
                                   0,n
                                    |
Jockey -0,n---[Monter]---1,1- Jockey_Cheval -1,1---[Etre monté]---0,n- Cheval

4°/ Donnant, en final :

Jockey(IdJockey, Nom, ...)
Cheval(IdCheval, Nom, ...)
Course(IdCourse, Nom, ...)

Jockey_Cheval(#IdJockey, #IdCheval, ...)
Participation(#IdCourse, #IdJockey, #IdCheval, NumeroParticipant, ...) ==> index unique #IdCourse/#IdJockey/#IdCheval/NumeroParticipant

Par contre, si Richard veut bien noter les copies...

==> hum... je me garderai bien de noter quoi que ce soit, n'étant pas "merisien de naissance" !... juste quelques avis à partager. En revanche, les conseils des "merisiens de naissance" sont toujours précieux.

[CinePhil]

Participation(#IdCourse, #IdJockey, #IdCheval, NumeroParticipant, ...) ==> index unique #IdCourse/#IdJockey/#IdCheval/NumeroParticipant

L'index unique est insuffisant. Je peux avoir ceci dans la table :

#IdCourse, #IdJockey, #IdCheval, NumeroParticipant
1, 12, 5, 1
1, 3, 6, 1

La clé primaire est unique, l'index unique aussi !
Il faut que le numéro soit unique pour la course. Je ne vois pas comment modéliser ça autrement qu'en indiquant une contrainte.

[Richard_35]

: exact, Philippe.

Ce pourrait être :

Participation(#IdCourse, #IdJockey, #IdCheval, NumeroParticipant, ...) ==> index unique #IdCourse/NumeroParticipant

[CinePhil]

Je pense que ça colle mais au niveau modélisation (MCD) on ne peut pas représenter les contraintes d'unicité je crois.
À part avec les logiciels de modélisation modernes peut-être ?

[Richard_35]

@Fsmrel

Par contre, si Richard veut bien noter les copies...
[Correcteur] -- 0,N ---- (Noter) ---- 1,1 -- [Copie]
Espérons que N ne restera pas à 0...

==> . Le but du forum doit rester :

[Correcteur] -- 1,N ---- (Noter) ---- 1,N -- [Copie]

fichu N,N !...

[fsmrel]

'soir à tous,


J’ai proposé avant-hier un MCD réalisé avec DB-MAIN, voici le MLD correspondant produit par l’AGL :



Ce qui correspond sous forme textuelle à ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
COURSE {CourseId, CourseNom, CourseDate}
    KEY {CourseId} ;

CHEVAL {ChevalId, ChevalNom, DateNaissance}
    KEY {ChevalId} ;

JOCKEY {JockeyId, JockeyNom, JockeyPrenom}
    KEY {JockeyId} ;

PARTICIPER {CourseId, ChevalId, JockeyId, Numero, Poids}
    KEY {CourseId, ChevalId}
    KEY {CourseId, JockeyId}
    KEY {CourseId, Numero}
    FOREIGN KEY {CourseId} REFERENCES COURSE
    FOREIGN KEY {ChevalId} REFERENCES CHEVAL
    FOREIGN KEY {JockeyId} REFERENCES JOCKEY ;

A toutes fins utiles, voici le code SQL généré par DB-MAIN :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
create table CHEVAL (
     ChevalId numeric(4) not null,
     ChevalNom varchar(48) not null,
     DateNaissance date not null,
     constraint ID_CHEVAL_ID primary key (ChevalId));
 
create table COURSE (
     CourseId numeric(4) not null,
     CourseNom varchar(48) not null,
     CourseDate date not null,
     constraint ID_COURSE_ID primary key (CourseId));
 
create table JOCKEY (
     JockeyId numeric(4) not null,
     JockeyNom varchar(48) not null,
     JockeyPrenom varchar(48) not null,
     constraint ID_JOCKEY_ID primary key (JockeyId));
 
create table PARTICIPER (
     CourseId numeric(4) not null,
     ChevalId numeric(4) not null,
     JockeyId numeric(4) not null,
     Numero numeric(32) not null,
     Poids numeric(3,2) not null,
     constraint ID_PARTICIPER_ID primary key (CourseId, ChevalId),
     constraint SID_PARTICIPER_1_ID unique (CourseId, JockeyId),
     constraint SID_PARTICIPER_ID unique (CourseId, Numero));
 
alter table PARTICIPER add constraint REF_PARTI_JOCKE_FK
     foreign key (JockeyId)
     references JOCKEY;
 
alter table PARTICIPER add constraint REF_PARTI_COURS
     foreign key (CourseId)
     references COURSE;
 
alter table PARTICIPER add constraint REF_PARTI_CHEVA_FK
     foreign key (ChevalId)
     references CHEVAL;

@Fsmrel
==> . Le but du forum doit rester :

[Correcteur] -- 1,N ---- (Noter) ---- 1,N -- [Copie]

Soit ! Autrement dit, plein de gens vont corriger plein de copies : pas de problème, plus on est de fous, plus on !

À ce stade de ma réflexion, je ne ferais finalement pas participer le numéro à l'identification de l'association et je mettrais une contrainte sur l'unicité du numéro pour une course.

Hum... Le défi est de prendre en compte les règles de gestion seulement au niveau MCD. Est-il bien sous-entendu que cette contrainte fait partie du MCD ?

Quoi qu’il en soit, vous aurez au moins plus de contrôle sur l’intégrité de la base de données que ne l’ont ceux qui on modélisé les équipes de la NBA, avec par exemple deux joueurs des Blazers qui portent le numéro 23 (parmi les choses bizarres, je remarque à cette occasion que le pauvre Nicolas Batum ne doit pas avoir grand-chose à manger...)

Participation(#IdCourse, #IdJockey, #IdCheval, NumeroParticipant, ...) ==> index unique #IdCourse/NumeroParticipant

Il s’agit là d’une intervention manuelle au niveau physique (le concept d’index est inconnu au niveau logique, en conséquence de quoi il ne fait pas partie de la norme SQL, pour qui la technologie physique reste sous le capot). Comme je viens de le préciser, le défi est déjà de prendre en compte les règles de gestion seulement au niveau MCD...

Au niveau modélisation (MCD) on ne peut pas représenter les contraintes d'unicité je crois.
À part avec les logiciels de modélisation modernes peut-être ?

La Bentley WinDesign permet de le faire contrairement à la Rolls PowerAMC. La FAQ Merise comporte un paragraphe à ce sujet : CIF (ou dépendance fonctionnelle) de A à Z (pour une Matière, un Candidat ne compose que dans une Salle).


Je vais essayer maintenant de représenter les contraintes sans sortir du moule Merise, en essayant de suivre à cet effet ce qui est écrit dans le document de référence :

afcet - Le formalisme de données Merise - Extensions du pouvoir d’expression - Journée d’étude organisée par le Groupe de Travail 135 « Conception des systèmes d’information (Collège AFCET-GID) - Jeudi 15 novembre 1990, Paris.

Les CIF, DF et plus généralement les contraintes d’unicité y sont définies ainsi que les règles à respecter pour les représenter :





A noter que le terme « rôle » y est défini ainsi :

Expression de la sémantique portée par la patte d’une relation.

Mais j’avoue que cette purée de marron me laisse perplexe et si quelqu’un a le courage de la remettre forme de façon claire, sinon lumineuse, il aura ma gratitude... je suis peut-être délinquant en représentant les choses comme je le fais ci-dessous car je ne dispose pas de WinDesign, donc si quelqu’un l’a sous la main, qu’il n’hésite surtout pas à faire part du verdict de l’AGL.

Au passage, je rappelle s’il est besoin, que contrairement à ce qui se passe avec DB-MAIN, on ne peut pas en Merise classique faire figurer dans une association quelque attribut que ce soit qui participe à l’identification d’icelle : de l’attribut Numero on est donc obligé de faire une pseudo entité-type :



A la lecture du document afcet, il me semble que la CIF (contrainte d’intégrité fonctionnelle) de la figure 2 est conforme. Elle exprime la contrainte selon laquelle pour une course et un cheval, il n’y a qu’un jockey :



Si la contrainte CIF1 est conforme, alors il doit en aller de même pour la CIF de la figure 3 :



Par référence aux axiomes d’Armstrong (plus particulièrement la règle d'union), je n’hésite pas à remplacer CIF1 et CIF2 par leur union (mais j’accepte d’être contesté, je ne suis pas merisement très orthodoxe ), on gagne ainsi en densité :



De la même façon, on signifie que pour une course et un jockey, il y a un seul cheval et un seul numéro :



Enfin, pour une course et un numéro, il y a un seul cheval et un seul jockey :



On a donc 6 CIF (compactées en 3) pour exprimer les contraintes d’unicité. Je ne me sens pas l’envie de les faire figurer toutes à la fois, dans un seul diagramme...

Peu importe. Je retiens en tout cas que ce malheureux Nicolas Batum peut laisser tomber le basket et devenir jockey.

[CinePhil]

Hum... Le défi est de prendre en compte les règles de gestion seulement au niveau MCD. Est-il bien sous-entendu que cette contrainte fait partie du MCD ?

Oui, je pensais simplement à l'ajout d'une note pointant vers l'association (ou l'entité type associative) qui préciserait la contrainte, ne sachant pas comment la représenter.

Tu as trouvé le moyen de définir complètement la contrainte sous forme de 3 CIF multiples.
Je ne sais pas si ce formalisme serait accepté par les pères de Merise mais il me convient.

Cependant, n'y aurait-il pas, dans la théorie relationnelle, quelle axiome, théorème ou autre tambouille qui permettrait de réduire l'ensemble de CIF suivantes en une seule ?
COURSE x CHEVAL --> JOCKEY, NUMERO
COURSE x JOCKEY --> CHEVAL, NUMERO
COURSE x NUMERO --> CHEVAL, JOCKEY

Ça me fait penser à un système d'équations que l'on essaierait de résoudre.

[JPhi33]

Bonjour à tous,

Pour éviter la modélisation d'une entité Date quand ce n'en est pas une, certains auteurs (au moins André FLORY en 82 repris par José MOREJON en 95) proposent la modélisation d'une "propriété spatio-temporelle". Il s'agit d'une simple propriété conceptuelle, la plupart du temps liée au temps ou à la localisation spatiale (d'où son nom), et entrant dans la composition d'une association. Elle se représente graphiquement dans un rectangle simple (ce n'est pas une entité).

L'avantage est double.
1) Elle participe à l'association et par conséquent participe à la composition de l'identifiant de l'association, respectant la règle qui veut qu'une association n'ait pas d'identifiant propre ni même une partie de cet identifiant.
2) Elle ne génère pas de table lors de la transformation du MCD en MLD puisqu'elle n'est pas une entité.

L'inconvénient est que, comme pour tous les concepts Merise "avancés" (après Merise/2), aucun AGL de modélisation n'intègre la propriété saptio-temporelle. La procédé de modélisation le plus proche de ce concept reste celui proposé par fsmrel (post #3) : créer une entité Date et ne pas générer la table.

[fsmrel]

Pour éviter la modélisation d'une entité Date quand ce n'en est pas une, certains auteurs (au moins André FLORY en 82 repris par José MOREJON en 95) proposent la modélisation d'une "propriété spatio-temporelle".

C’est vrai, et j’ai oublié d’en faire mention alors que vous aviez déjà signalé cette possibilité ici.


Cela dit, d’après vous, WinDesign accepte-t-il les CIF : CIF1 et CIF2 que j’ai représentées dans mon message précédent ? Le doute que je peux avoir vient du fait que, par exemple dans le cas de DIF1, l’entité-type NUMERO est branchée sur PARTICIPER, mais ne fait pas partie de la « source » (Unicité incomplète).

n'y aurait-il pas, dans la théorie relationnelle, quelle axiome, théorème ou autre tambouille qui permettrait de réduire l'ensemble de CIF suivantes en une seule ?
COURSE x CHEVAL --> JOCKEY, NUMERO
COURSE x JOCKEY --> CHEVAL, NUMERO
COURSE x NUMERO --> CHEVAL, JOCKEY

En mettant à contribution l’ensemble des axiomes d’Armstrong, on aboutit à la conclusion que ce trio est irréductible (c’est son côté gaulois...), on est passé de 6 représentations de CIF à 3 et on ne peut pas faire mieux. Désolé...