Discussion :

[fsmrel]

Capitaine,

Un problème : un garçon attentif comme f-leb ne manquera pas de faire remarquer qu’un utilisateur a acquis une frénésie d’un monstre dans le contexte d’une formation donnée, autrement dit il existe la dépendance fonctionnelle suivante :

{UtilisateurId, MonstreId} —> {FormationId}

En conséquence de quoi la colonne FormationId doit être évacuée de la clé primaire de la table Acquerir.

[f-leb]

la colonne FormationId doit être évacuée de la clé primaire de la table Acquerir.

Evacuée et envoyée par le fond pour rejoindre le dernier pitalugue du Capt'aine...

[fsmrel]

Evacuée et envoyée par le fond pour rejoindre le dernier pitalugue du Capt'aine...

En compagnie de mon Echo des îles, mais c’est comment qu’on fait avec les outils conceptuels dont nous disposons ?
It is like a big caillou dans la chaussure...

[Paprick]

Bonsoir,

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

Je vous lis avec attention .
La première chose à faire est de formaliser la mise en œuvre graphique de la contrainte en question... Ce n'est pas très clair pour le moment ...
Son automatisation en termes de MLD et LDD pourra alors être étudiée.

[escartefigue]

Capitaine,

Un problème : un garçon attentif comme f-leb ne manquera pas de faire remarquer qu’un utilisateur a acquis une frénésie d’un monstre dans le contexte d’une formation donnée, autrement dit il existe la dépendance fonctionnelle suivante :

{UtilisateurId, MonstreId} —> {FormationId}

En conséquence de quoi la colonne FormationId doit être évacuée de la clé primaire de la table Acquerir.

sauf erreur de ma part, cette colonne n'a jamais fait partie de la PK, et donc tout va bien

Pour moi, la dernière version du DDL proposée était la suivante (mais dans les précédentes, il n'y avait pas non plus cette colonne) :

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

[escartefigue]

Bonsoir,

Je vous lis avec attention .
La première chose à faire est de formaliser la mise en œuvre graphique de la contrainte en question... Ce n'est pas très clair pour le moment ...
Son automatisation en termes de MLD et LDD pourra alors être étudiée.

Les règles me semblent limpides pour le cas du scénario 2 de la réponse 54 de François, mais pour les deux autres je ne suis pas certain qu'on puisse les déterminer facilement.

[fsmrel]

Ave,

Je vous lis avec attention.
La première chose à faire est de formaliser la mise en œuvre graphique de la contrainte en question... Ce n'est pas très clair pour le moment

C’est effectivement un point qui mérite une réflexion poussée, espérons qu’avec le temps ça aboutira.
 

sauf erreur de ma part, cette colonne n'a jamais fait partie de la PK, et donc tout va bien.

D’accord dans le cas du tout 1er MCD présenté au début du post #54, car la règle attachée à Acquerir contient le code à cet effet.
Das le cas des scénarios présentant l’hypothétique contrainte U, il s’agit fondamentalement d’évacuer les colonnes redondantes, mais la clé primaire est alors le triplet {UtilisateurId, MonstreId, FormationId} et il faut la réduire à la paire {UtilisateurId, MonstreId}. Pour le moment la solution est de passer par une règle, Le défi est quand même d’éviter cette facilité, sachant toutefois qu’avec les contraintes proposées par Looping, on ne devrait pas s’en sortir. J’y réfléchis, mais si Paprick pouvait me démentir...

[fsmrel]

Il faut que le Pitalugue et l’Echo des îles reviennent à la surface.

Il s’agit d’évacuer la colonne FormationId de la clé primaire de la table Acquerir, ce qui suppose dans le MCD la mise en oeuvre d’une CIF ayant pour cible l’entité-type Formation. Manque de chance Formation n’est pas connectée à l’entité-type Acquerir...
Dommage. Je rappelle à cette occasion comment Looping permet de dégager une colonne d’une clé primaire, cf. le post #57 de Paprick dans la discussion traitant des courses hippiques :
 

Looping se contente de retirer, dans la clé primaire de l'association, l'identifiant de la classe d'entités ciblée par la CIF.

Quitte à recevoir des coups de partout, sous les yeux écarquillés de Dee, je propose une extension du concept de CIF...

Quel est le sens du le MCD suivant ?

 
L’hypothétique CIF ayant Formation comme cible a pour objet l’évacuation de la colonne FormationId dans la clé primaire de la table Acquerir (au niveau SQL). Etant donné que Formation n’est pas directement branchée sur Acquerir, on va considérer que le système utilisera les entités-types (faibles) Rencontrer et Agreger pour y rechercher la colonne FormationId, puisque d’une part ces entités-types sont branchées sur Acquerir, et que d’autre part elles déterminent fonctionnellement Formation.
Les liens de couleur bleue sont là pour préciser quelles entités-types sont impliquées dans cette histoire.

Vos avis ? Paprick, merci de ne pas taper trop fort...

En tout ca, ça en fait des extensions cette semaine...

[deedolith]

Question subsidiaire:

Concernant la Formation, la règle indique qu'un groupe comprend jusqu'à 8 formations.
Sachant que les formations sont numéroté de 0 à 7 (leurs numérotation au sein d'un groupe),
est-ce utile d'ajouter une table pour enforcer un numero de formation valide, ou enforcer cette règle par trigger, ou sachant que la base de données est sous Ms Access, utiliser une contrainte de validité ?

Et je me rend compte qu'il y a une erreur dans le modèle.
En effet, un monstre (agregeable) peut apparaitre dans plusieurs formations.
Une formation peut être vide.

J'ai modifié le modèle comme suit:
Ajouter une colonne ID dans la l'entité type Agreger (primary key).
Modifier les cardinalités de relation entre les entités Agréger et Formation (1:1 / 0:n).
Est-ce la bonne approche ?

Ci joint le fichier Looping.
FF6.zip

[fsmrel]

Bonjour,

Concernant la Formation, la règle indique qu'un groupe comprend jusqu'à 8 formations.
Sachant que les formations sont numéroté de 0 à 7 (leurs numérotation au sein d'un groupe),
est-ce utile d'ajouter une table pour enforcer un numero de formation valide, ou enforcer cette règle par trigger, ou sachant que la base de données est sous Ms Access, utiliser une contrainte de validité ?

Une contrainte de validité paraît plutôt indiquée.

Ça fait des années que je n’ai pas créé de table avec Access...

Je me suis donc remis les mains dans le cambouis.

Exemple de contrainte (de colonne) : "GroupeId Between 0 and 7"
 

 
Votre avis ?

[deedolith]

Ok, merci.

Y'a plus qu'a.

[fsmrel]

D'accord Dee.

N'hésitez pas à voter pour les réponses qui ont pu vous apporter de l'aide et vous conforter, tout le monde y a mis du sien...

[escartefigue]

Bonjour Deedolith

Et je me rend compte qu'il y a une erreur dans le modèle.
En effet, un monstre (agregeable) peut apparaitre dans plusieurs formations.
Une formation peut être vide.

Concernant le 1er point, pas de difficultés, la cardinalité maxi n de [monstre] vers (agréger) l'autorise,
Concernant le dernier point, s'il n'y a pas de difficultés en matière de modélisation, je m'interroge en quoi consiste une rencontre d'une formation vide , ça éveille ma curiosité.
Concernant le comment faire, je rejoins Fsmrel : une contrainte de validité sera plus facile à mettre en œuvre et à maintenir qu'un trigger et aussi probablement plus performante

Edit : notez que certains SGBD utilisent les contraintes de validité (contraintes CHECK) pour optimiser les stratégies d'accès, c'est le cas notamment de SQL server. Ce ne sera évidemment pas le cas avec un déclencheur (trigger). Argument supplémentaire en faveur d'une contrainte de validité

[fsmrel]

Bonjour,

@Dee, Achille, Capitaine

Comme je l’ai écrit dans mon message précédent, avec Access je me suis remis les mains dans le cambouis
J’ai même été jusqu’à traduire (à la mano) le MCD suivant (où Frenesie regagne le bercail) :

 
Bien entendu, en voulant créer les tables, j’ai eu le sentiment de retrouver le bon vieux temps des années soixante, avec le vocabulaire de l’époque ("champ", "enregistrement", "index" (à l’époque la méthode d’accès était QISAM), etc....)

Mais bon, j’arrive à faire des choses. Là où ça coince, c’est quand je cherche à créer une clé étrangère impliquant les tables Rencontrer (cible) et Acquerir (source), Access me balance un message méchant, une histoire débile d’index unique :

 

Access mélange allègrement MLD et MPD, ce qui n’est pas fait pour aider. La clé primaire de la table en cause (il s’agit manifestement de Rencontrer) est constituée de la paire {UtilisateurId, FormationId}, si donc un "index unique" est requis, n’a-t-il pas pour objet la clé primaire de Rencontrer ? Si oui, comment créer cet index ? 

Qu’ai-je raté ? Vos avis ? Hilarion est-il dans le coup ?

[f-leb]

Hello tout le monde,

[...] avec Access je me suis remis les mains dans le cambouis

C'est bien dégeu, hein ?

J’ai même été jusqu’à traduire (à la mano) le MCD suivant (où Frenesie regagne le bercail) :

Tu peux gagner du temps avec Looping (avec la cible SQL Access bien sûr). Tu copies-colles le SQL (une instruction SQL à la fois) dans le générateur de requêtes en mode SQL et tu cliques sur Exécuter. Avec du code VBA, on devrait pouvoir lire le fichier SQL généré par Looping et exécuter automatiquement les instructions une par une (je n'ai pas de code sous la main).

Qu’ai-je raté ? Vos avis ? Hilarion est-il dans le coup ?

Dans l'assistant, tu as dû tracer la relation dans le sens Acquerir vers Rencontrer. Il faut la tracer dans l'autre sens, Rencontrer vers Acquerir (côté 1, clé primaire vers côté ∞), clé étrangère).

D'après Hilarion, tu fais une relation « plusieurs-à-un », alors qu'il faut une relation « un-à-plusieurs »... Ben oui, c'est logique

[fsmrel]

Merci Achille !
 

Dans l'assistant, tu as dû tracer la relation dans le sens Acquerir vers Rencontrer. Il faut la tracer dans l'autre sens, Rencontrer vers Acquerir (côté 1, clé primaire vers côté ∞), clé étrangère).
D'après Hilarion, tu fais une relation « plusieurs-à-un », alors qu'il faut une relation « un-à-plusieurs »... Ben oui, c'est logique

Dans un sens c’est logique, mais l’inverse l’est tout autant. Exceptionnellement, je donne raison à Lefuneste ! En tant que vieux DBA, quand je définis une clé étrangère, je raisonne dans le sens allant du référençant au référencé. En effet, dans la table référençante, je sais exactement quelles seront les colonnes parties prenantes dans la clé étrangère, alors qu’en partant de la table référencée, parmi l’ensemble (qui peut être kolossal) des colonnes de la table référençante, on n’a aucune idée a priori des colonnes à y choisir pour composer la clé étrangère, la foire d’empoigne, quoi.
Partir du côté 1, pour aller vers le côté ∞ c’est ainsi que je procédais du temps lointain où je modélisais des bases de données hiérarchiques (IMS/DL1) ou réseaux (IDMS), listes inverses (TOTAL), c’est-à-dire avant le Déluge...
 
@Capitaine : j’aimerais connaître ton avis de vieux de loup de mer...
 
 

C'est bien dégeu, hein ?

C’est le moins qu’on puisse dire !
 
 

Tu copies-colles le SQL (une instruction SQL à la fois) dans le générateur de requêtes en mode SQL et tu cliques sur Exécuter.

Ça devient sportif ! Où est-il donc caché ce « générateur de requêtes » ? Bon, je joue le jeu. Access présente une diarrhée d’onglets, d’images et d’icônes dont je n’ai strictement rien à faire, seuls les éléments que j’ai encadrés ci-dessous en rouge sont a priori susceptibles de m’intéresser dans ma quête du fameux générateur :
 

 
Je voudrais commencer par Créer > "SQL Direct", mais c’est grisé, donc inaccessible.
 
Je tente ma chance avec "Création de requête".

 
Mais alors, que vois-je, quelle horreur !

Je me dis que c’est mal emmanché, ça n’est pas après 40 ans de Relationnel que je vais demander qu’on m’aide à coder une requête SQL (Sorry Query Language)...
 
Je clique quand même sur "Création de requête", puis en faisant un clic droit sur le nom de la requête (Requête1), j’ai droit à ce qui suit (quelle sera la prochaine surprise ?) :

 
Enfin je vois un début de vrai code SQL ! :
 

 
Je complète la requête avec un FROM qui va bien, la renomme et ferme la fenêtre.

Je peux accéder au code SQL en ouvrant la fenêtre (« SQL Mode SQL ») :

 
Ouf !
 
Maintenant, je voudrais soumettre mon paquet de CREATE TABLE, dont voici le début :
 

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
CREATE TABLE Groupe
(
    GroupeId INT NOT NULL
,   GroupeNom VARCHAR(24) NOT NULL
,   CONSTRAINT Groupe_PK PRIMARY KEY(GroupeId)
,   CONSTRAINT Groupe_AK UNIQUE(GroupeNom)
,   CONSTRAINT GroupeMaxId CHECK(GroupeId BETWEEN 0 AND 7)
);
CREATE TABLE Formation
(
    FormationId INT NOT NULL
,   GroupeId INT NOT NULL
,   FormationNom VARCHAR(24) NOT NULL
,   CONSTRAINT Formation_PK PRIMARY KEY(FormationId)
,   CONSTRAINT Formation_AK UNIQUE(FormationNom)
,   CONSTRAINT Groupe_Formation_FK FOREIGN KEY(GroupeId) REFERENCES Groupe(GroupeId)
);

 
Mais je me fais jeter, je déchante... Manifestement Access n’accepte qu’un seul CREATE TABLE à la fois ! Comment faire pour lui passer un paquet de CREATE d’un coup, alors que n’importe quel SGBD digne de ce nom accepte cela !
 
Et là où ça devient du délire c’est quand je lui soumets l’instruction suivante :
 

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
insert into Groupe values
  (0,'g0')
, (1,'g1')
, (2,'g2')
, (3,'g3')
, (4,'g4')
, (5,'g5')
, (6,'g6')
, (7,'g7')
;

Il exige un ";" à la suite de la 1re valeur, "(0,'g0')" ! les bras m’en tombent ! Quel est le farceur, l’inconscient chez µS qui a osé concevoir les choses comme ça ? Seulement des INSERT monovalués ! C’est le cousin américain d’Hilarion ? S’il n’y a pas d’alternative native, si j’ai cent mille valeurs à entrer dans une table, je ne vais quand même pas monter une usine à gaz pour y arriver... Soit Access a la solution native, sans VBA et autres bricolages palliatifs, soit c’est une incitation à passer à un SGBD relationnel. C’est mon opinion et je la partage...
 
Vos avis ?

[escartefigue]

hola valiente soldado del modelaje

[...] quand je définis une clé étrangère, je raisonne dans le sens allant du référençant au référencé [...]@Capitaine : j’aimerais connaître ton avis de vieux de loup de mer...

Parler de TOTAL et DL1 me rappelle mes souvenirs de moussaillon à bord d'un IBM 4381 sous DOS/VSE, autant dire le paléolithique
Et je suis bien d'accord.
Ça fait bien longtemps que je n'ai plus utilisé Access, mais je me souviens avoir aussi eu du mal avec cette approche contre intuitive par rapport à la logique qui est la mienne et qui vaut ce qu'elle vaut

Il exige un ";" à la suite de la 1re valeur, "(0,'g0')" ! les bras m’en tombent ! Quel est le farceur, l’inconscient chez µS qui a osé concevoir les choses comme ça ? Seulement des INSERT monovalués ! C’est le cousin américain d’Hilarion ? S’il n’y a pas d’alternative native, si j’ai cent mille valeurs à entrer dans une table, je ne vais quand même pas monter une usine à gaz pour y arriver... Soit Access a la solution native, sans VBA et autres bricolages palliatifs, soit c’est une incitation à passer à un SGBD relationnel. C’est mon opinion et je la partage...
 
Vos avis ?

Peut-être faut il faire comme avec DB2 for Z/OS en utilisant la syntaxe suivante (sans la pseudo-table SYSDUMMY1 bien entendu ) :

Code SQL :

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

1
2
3
4
5
6
7
INSERT INTO Ma_table (Col1, Col2, Col3)               
SELECT Val1, Val2, Val3   FROM SYSIBM.SYSDUMMY1  
UNION ALL                                                    
SELECT Val5, Val6, Val7   FROM SYSIBM.SYSDUMMY1  
UNION ALL
[...]
;

Cf. doc IBM de référence ICI

Il me semble qu'avec SQLite c'est du même tonneau

[fsmrel]

Bonsoir les lions,

hola valiente soldado del modelaje

είσαι άλλος ένας !

 
@Achille : dans ton précédent message ici, tu écris, je te cite :
 

Avec du code VBA

S’il faut en passer par VBA, cela revient à dire qu’Access a un goût de relationnel, mais n’est pas relationnel, car il enfreindrait alors la règle Zéro, préambule des fameuses 12 règles de Codd, publiées en octobre 1985 dans un article qui commence ainsi :
 

 
La règle Zéro dit ceci :
 

"These rules are based on a single fondation rule, which I shall call Rule Zero:
For any system that is advertised as, or claimed to be, a RELATIONAL DATABASE MANAGEMENT SYSTEM, that system must be able to manage databases entirely through its relational capabilities."

Les 12 règles datent de près de 40 ans et pourraient bien entendu être mises à jour, mais elles ont été attentivement étudiées par les fournisseurs de SGBD qui en ont en gros tenu compte, à une époque où les dinosaures dominaient.

D’après toi, avec Access existe-t-il une solution ensembliste (strictement SQL donc) pour traiter l’INSERT de mon message précédent et que je reprends ici :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
insert into Groupe values
  (0,'g0')
, (1,'g1')
, (2,'g2')
, (3,'g3')
, (4,'g4')
, (5,'g5')
, (6,'g6')
, (7,'g7')
;

 

[f-leb]

Hop,

[...]cela revient à dire qu’Access a un goût de relationnel, mais n’est pas relationnel, car il enfreindrait alors la règle Zéro, préambule des fameuses 12 règles de Codd...

Ah mais tu me fends le cœur, là... 30 ans qu'il est bloqué à la frontière du RelationLand, même pas accueilli avec un statut de réfugié, l'ONU n'a pas réagi, et tout ça à cause de quelques règles... dur, dur

D’après toi, avec Access existe-t-il une solution ensembliste (strictement SQL donc) pour traiter l’INSERT de mon message précédent et que je reprends ici :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
insert into Groupe values
  (0,'g0')
, (1,'g1')
, (2,'g2')
, (3,'g3')
, (4,'g4')
, (5,'g5')
, (6,'g6')
, (7,'g7')
;

 

À ma connaissance, non. Mais ce n'est pas grave, on remplit les tables depuis une feuille Excel, un fichier texte ou CSV, µS a tout prévu

[fsmrel]

Salve,

Ah mais tu me fends le cœur, là...

Tu as le coeur fendu par moi, mais comme tu le sais les gardiens du Relationland sont inflexibles...

on remplit les tables depuis une feuille Excel, un fichier texte ou CSV, µS a tout prévu

Yes! Un grand merci pour ton conseil, j’ai réussi à compléter la table Groupe à l’aide d’un fichier texte. Access tangente le relationnel.
Je pense que le Capitaine en conviendra, même s’il est aussi rouillé que moi dans la mise en oeuvre d’Access...