Discussion :

[fsmrel]

Merci Achille, il s'agit d'une coquille, un copier/coller foireux...

J’ai modifié l’ALTER TABLE en cause dans mon post précédent.

[f-leb]

Je pense que c'est bon
Il fait des nœuds au cerveau ce MCD !

Je reste quand même sceptique, car dans la table 'Acquerir' il faut saisir la formation où l'on a rencontré le monstre. C'est nécessaire pour vérifier la fameuse règle "Un utilisateur ne peut acquérir une frénésie que si celle-ci appartient à un monstre d’une formation rencontrée par l’utilisateur.", mais cela reste une information qui n'est pas utile au départ. Que l'utilisateur acquiert la frenesie parce qu'il a rencontré le monstre dans la formation 1, 2, x ou y importe peu.

N'y aurait-il pas un autre moyen (avec ceinture et bretelles) pour vérifier la règle sans avoir à préciser la formation ?

[fsmrel]

Merci Achille,

L’utilisateur x acquiert la frénésie y du monstre z qui fait partie de la formation t rencontrée par x.

Dans ce contexte l’entité-type Agreger joue le rôle de ceinture et doit participer au schmilblick, je ne vois pas comment procéder autrement...

Et toi de ton côté ? Et du côté du Capitaine ?

[escartefigue]

Bonjour Fabien et merci pour ta contribution à ce sujet

Je pense que c'est bon
Que l'utilisateur acquiert la frenesie parce qu'il a rencontré le monstre dans la formation 1, 2, x ou y importe peu.

Nous sommes bien d'accord, et c'était la raison pour laquelle j'avais proposé un MCD qui nous simplifiait la vie sur ce point, mais deedolith a bien précisé

Je veux la liste des formations que j'ai rencontrées

, ce qui torpillé mon bon vieux Pitalugue avec tout ce qui était à son bord, MCD inclus :

N'y aurait-il pas un autre moyen (avec ceinture et bretelles) pour vérifier la règle sans avoir à préciser la formation ?

J'ai bien peur que toute autre solution passe par des triggers ou autres artifices hors modèle de données, mais j'avoue n'y avoir pas plus réfléchi

[deedolith]

Ne faudrait-il pas plutôt relier à 'Frenesie' ? Sachant qu'un utilisateur acquiert la frénésie d'un monstre, et qu'il peut y avoir des monstres sans frénésie.

Petite précision:
Certains monstre n'ont en effet pas de frénésie.
Ces derniers n'appartiennent à aucune formation non plus.

A mon sens, c'est plus une règle de gestion logicielle que conceptuelle, qui sera enforcée par trigger ou code client quelconque.

PS: Vous avez levé un sujet intéressant,
il faudra que je réalise des tests plus approfondis.

[f-leb]

Petite précision:
Certains monstre n'ont en effet pas de frénésie.
Ces derniers n'appartiennent à aucune formation non plus.

Ah oui mais tu connais la règle dans ce forum, nouvelle règle de gestion = nouveau MCD

[fsmrel]

Bonjour tout le monde !
 

Certains monstre n'ont en effet pas de frénésie.
Ces derniers n'appartiennent à aucune formation non plus.

 
La règle de gestion est-elle alors bien la suivante ?
 

Seuls les monstres associés à des formations peuvent posséder des frénésies.

 
Si tel et le cas, le MCD est à enrichir ainsi :

 

[fsmrel]

ce qui torpillé mon bon vieux Pitalugue avec tout ce qui était à son bord, MCD inclus

Voilà ce qu'il en coûte d’affronter des formations de monstres, mais tu en a vu d’autres... Courage, tu le remettras en état ce brave Pitalugue...

[escartefigue]

Un point de détail : je renommerais volontiers le type d'entité [RENCONTRER] en [RENCONTRE] et l'entité-type [UTILISATEUR] en [JOUEUR] avec une asso (effectuer) entre les deux

Soit : [JOUEUR] 0,n --- (effectuer) --- 1,1(R) [RENCONTRE]

[fsmrel]

J'ai bien peur que toute autre solution passe par des triggers ou autres artifices hors modèle de données, mais j'avoue n'y avoir pas plus réfléchi.

De mon côté, j’ai demandé poliment à Looping de tenir compte de la règle attachée à l’association Acquérir et il le fit (alter table Acquérir), cf. le post concerné. Evidemment c’est plutôt bourrin, mais ça fonctionne, même si Hilarion joue les trouble-fête histoire d’envoyer mon Echo des Iles par le fond, rejoindre le Pitalugue.

Je sens surtout que Merise (figée depuis longtemps) est à faire évoluer pour traiter des chemins collatéraux et des boucles inhérentes, sujet que j’ai abordé jadis, mais plutôt dans le cadre du Modèle Relationnel de Données. Il va falloir que je fouille dans mes archives. En attendant, Paprick a sans doute réfléchi à cela, mais peut-être est-il inopportun de le déranger pour le moment, il a tant à faire par ailleurs...
 
 

Un point de détail : je renommerais volontiers le type d'entité [RENCONTRER] en [RENCONTRE] et l'entité-type [UTILISATEUR] en [JOUEUR] avec une asso (effectuer) entre les deux

Soit : [JOUEUR] 0,n --- (effectuer) --- 1,1(R) [RENCONTRE]

Nihil obstat, à moins que, suite à une idée lumineuse, Rencontrer ne redevienne une association...
De mon côté, je préfère en rester au verbe, lequel rappelle qu’il s’agit d’associer Joueur et Formation, donc que l’on est en présence d’une entité-type faible de tous les côtés.

[deedolith]

Si j'ai bien tout suivi,
au final, ce devrait donner quelque chose comme suit:

[fsmrel]

Bonsoir,
 

au final, ce devrait donner quelque chose comme suit

 
D’accord. Bel effort.
 
Quelques remarques
 

1. L’entité-type Utilisateur a manifestement un identifiant de type Identity( ID) et un identifiant alternatif naturel, c’est-à-dire qui vous est propre (UID). C’est bien ça ?
    
2. Les cardinalités de l’association Regrouper sont à permuter ;
    
3. On comprend le sens de votre sympathique contrainte d’inclusion qui attire notre attention. Cela dit, dans la vraie vie des MCD, les contraintes d’inclusion se font entre associations (sauf peut-être chez Tabourier, cf. la figure 9a dans son document dont je fais mention ci-après). Voyez la référence Afcet ainsi que le document d’Yves Tabourier (Extension des contraintes) ;
    
4. Assurez-vous qu’au stade SQL, les ALTER TABLE concernant Acquerir seront en place...

[deedolith]

Oups,

Bien vu l'oeil de lynx.

Concernant l'entité utilisateur, oui, L'identifiant (ID) et UID ont le même comportement (unique / non bull), l'un est numérique, l'autre est une chaîne.
Concernant la contrainte d'inclusion, je l'ai volontairement laissée pour raison de compréhension (les relation qui y étaient soumises on déja été éclatées en tables).
Dernier défaut, un monstre "agrégeable" a obligatoirement une frénésie, mais Looping n'autorise pas les relations 1:1 / 1:1.

[fsmrel]

Bonsoir,

A propos de l’association Acquerir.

Reprenons le MCD fourni dans le post #39 : à l’entité-type Acquerir est attachée une règle, à savoir "Modif", où sont fournies les instructions ALTER TABLE permettant de nettoyer la structure de la table Acquerir.

Le code SQL fourni par Looping est le suivant :
 

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE Acquerir(
   UtilisateurId INT,
   FormationId_1 INT,
   FormationId INT,
   MonstreId_1 INT,
   MonstreId INT,
   CONSTRAINT Acquerir_PK PRIMARY KEY(UtilisateurId, FormationId_1, FormationId, MonstreId_1, MonstreId),
   CONSTRAINT Acquerir_Rencontrer_1_FK FOREIGN KEY(UtilisateurId, FormationId_1) REFERENCES Rencontrer(UtilisateurId, FormationId),
   CONSTRAINT Acquerir_Agreger_1_FK FOREIGN KEY(FormationId, MonstreId_1) REFERENCES Agreger(FormationId, MonstreId),
   CONSTRAINT Acquerir_Frenesie_FK FOREIGN KEY(MonstreId) REFERENCES Frenesie(MonstreId)
);

 
Code certes en théorie conforme, mais on peut légitimement préférer la production du code suivant :
 

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE Acquerir
(
    UtilisateurId INT
,   MonstreId INT
,   FormationId INT NOT NULL
,   CONSTRAINT Acquerir_PK PRIMARY KEY(UtilisateurId, MonstreId)
,   CONSTRAINT Acquerir_Frenesie_FK FOREIGN KEY(MonstreId) REFERENCES Frenesie(MonstreId)
,   CONSTRAINT Acquerir_Agreger_FK FOREIGN KEY(FormationId, MonstreId) REFERENCES Agreger(FormationId, MonstreId)
,   CONSTRAINT Acquerir_Rencontrer_FK FOREIGN KEY(UtilisateurId, FormationId) REFERENCES Rencontrer(UtilisateurId, FormationId)
);

 
Autrement dit, il s’agit d’éviter la production des colonnes FormationId_1 et MonstreId_1 et des contraintes faisant intervenir ces colonnes.

Ce que l’on cherche narrativement parlant :

L’utilisateur x acquiert la frénésie y du monstre z qui fait partie de la formation t rencontrée par x.

 
Alors que l’on obtient quelque chose du genre :
 

L’utilisateur x acquiert la frénésie y du monstre z qui fait partie de la formation t’ rencontrée par x’.

 
C’est-à-dire que l’on a x’ ≠ x et t’ ≠ t.
 
Pour arriver au résultat voulu, c’est-à-dire x’ = x et t’ = t, je ne sais pas s’il est possible de se servir des contraintes proposées par Looping. Si ça n’est pas le cas, je suggère une extension des contraintes proposées par l’Afcet dans son document de référence (datant de 1990)...
 
Il s’agit à mon sens d’un problème de références circulaires (on part de x pour arriver à x), et ce problème n’est pas anodin, comme l’explique le chantre du Modèle Relationnel de Données, Chris Date, dans Relational Database Writings 1985-1989 :
 

“Why conterminous referential paths should be treated with caution” (pages 143 et suivantes).

 

 
Pour que l’AGL produise le code SQL attendu, je suggère la mise en oeuvre d’une contrainte d’unicité (ou de circularité, ou de quelque chose allant dans ce sens), symbolisée par exemple comme ceci dans le MCD :

Scenario 1

 
La flèche (ou un lien en pointillés) permet d’indiquer que l’entité-type Acquerir joue le rôle de cible dans la contrainte, et donnera lieu à une table dépourvue des attributs devenus redondants, à savoir FormationId_1 et MonstreId_1.

Le MCD suivant est une variante, dans la mesure où les associations ne sont pas nécessairement transformées en entités-types :
 

Scenario 2

 
Et pourquoi pas la représentation mixte suivante :

Scenario 3

 

Peut-être suis-je en train de délirer, j’attends paisiblement la contradiction, en tout cas ce problème de circularité, de “conterminous path” m’interpelle et j’aimerais qu’on y trouve une solution, si possible...
 
Merci d’avance pour vos commentaires...

[deedolith]

Heu ...

Je découvre seulement les contraintes proposées par Looping,
et la, tu m'envoies direction les anneaux de Saturne

[escartefigue]

Bravo François
Par contre, je ne te suis pas concernant le schéma 2 dans lequel les assos ne sont pas remplacées par des types d'entité, je ne vois pas comment tu implémentes la contrainte entre agréger et acquérir, puisque dans ce modèle, acquérir ne connait pas l'identifiant de la formation.
Faut il comprendre que la contrainte (U) ajouterait dans ce cas des colonnes dans la table acquérir ?

[fsmrel]

Merci au Capitaine et à Dee !

Dee, attention à Saturne, car comme dit le poète :

Il est morne, il est taciturne
Il préside aux choses du temps
Il porte un joli nom « Saturne »
Mais c’est un Dieu fort inquiétant.

 
 
Je précise maintenant comment je vois les choses sous le capot :

La contrainte U permet de collecter dans un panier les identifiants des objets (entités-types ou associations) qui lui sont connectés : Acquerir, Rencontrer, Agreger.
En l’absence de cette contrainte, le système doit renommer les doublons, d’où les noms tels que :

FormationId_1 et MonstreId_1

Du fait de la contrainte, ces noms sont à évacuer du panier, et ce qui reste, le triplet {UtilisateurId, FormationId, MonstreId}, constituera l’en-tête (schéma) de la table cible, Acquerir en l’occurrence (en compagnie bien sûr des colonnes non identifiantes de cette table s’il y en a). La clé primaire de la table est constituée du triplet, tandis que les clés étrangères sont ajustées en conséquence.

Faut il comprendre que la contrainte (U) ajouterait dans ce cas des colonnes dans la table acquérir ?

En vertu de ce qui précède, elle annule et remplace.


N.B. Jai modifié mon post précédent, pour numéroter les 3 scénarios que j’ai présentés.

[escartefigue]

Ce serait formidable si Looping pouvait automatiser une telle contrainte ! Paprick, si tu nous lis

[fsmrel]

Dernier défaut, un monstre "agrégeable" a obligatoirement une frénésie, mais Looping n'autorise pas les relations 1:1 / 1:1.

Même pas grave. Vous vous rattraperez au stade SQL...
Normalement, puisqu’un tel monstre possède au moins et au plus une frénésie, quand on modélise dans les hauteurs éthérées des MCD, celle-ci doit faire l’objet d’un attribut (rubrique) de l’entité-type Monstre. Il s’ensuit que l’association Acquerir connecte désormais Utilisateur et Monstre, et permet de savoir que le 1er a fait l’acquisition d’une frénésie du 2e.

[Utilisateur]---0,N---(Acquerir)---0,N---[Monstre]

Mais redescendons sur terre, dans la glaise de la base de données SQL.

Les monstres et leurs frénésies :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE Monstre
(
    MonstreId INT
,   MonstreNom VARCHAR(24) NOT NULL
,   ...
,   Frenesie VARCHAR(24) NOT NULL
, ...
,   CONSTRAINT Monstre_PK PRIMARY KEY(MonstreId)
,   CONSTRAINT Monstre_AK UNIQUE(MonstreNom)
);

Par le passé j’ai été obligé, comme vous, de sortir une colonne C de la table T et de mettre en oeuvre une autre table pour héberger C. Pour quel motif avoir agi ainsi ?

Scénario :

• La colonne C occupe en mémoire 1% de ce qu’occupe la table T (volumineuse évidemment !) ;
   
• Cette colonne est copieusement et en permanence mise à jour, alors que les autres colonnes de la table le sont infiniment moins.

Le DBA sait que les buffers affectés aux tables vont être bien secoués à cause de cette fichue colonne C, d’où problèmes de contention, de réorganisation et autres joyeusetés... Il ne mettra pas longtemps à évacuer C de T et l’isoler dans une table ad-hoc, à l’instar de la table Frenesie.

Le Capitaine doit avoir des tas d’exemples de ce genre...

[fsmrel]

Heu ...

Je découvre seulement les contraintes proposées par Looping,
et la, tu m'envoies direction les anneaux de Saturne

C’est l’occasion, outre le très didactique bouquin de Paprick, de lire celui de Dominique Nanci (RIP) durant le voyage (Ingénierie des systèmes d’information – Merise deuxième génération).

Bonne lecture.