Discussion :

[Khezu]

Bonjour,

Je suis actuellement en stage et on m'a demandé de réaliser une base de donnée sous Access afin de gérer la gestion des élèves étrangers dans l'établissement où j'effectue mon stage. Cependant, n'étant pas une lumière dans le domaine de la conception, j'aurais bien besoin d'avis et de conseils.

J'ai déjà réalisé un premier jet du MCD, que vous trouverez ci-joint, dont je doute fortement de la qualité. Je vous demande donc votre avis là dessus.

Pour ce qui est des règles de gestion, elles sont comme suivent :

- Un étudiant [STUDENT] doit postuler [Applies] chaque année [YEAR] pour laquelle il souhaite s'inscrire.

- Des agents [AGENT] basés à l'étranger peuvent présenter [Introduces] des étudiants à l'établissement. Cependant un étudiant ne peut être présenté que par un seul agent.

- Si l'étudiant est accepté il reçoit un numéro CAS, auquel est affecté [Obtains (je sais que la traduction n'est pas très correcte ici...)] un certain statut [CAS STATUS] (actif, annulé, retiré...)

- Chaque année où il est accepté un étudiant :
* Suit [Follows] une formation [COURSE]
* Doit payer [Pays] des frais d'inscription [FEE]
* Obtient [Achieves (ici aussi...)] des résultats [OUTCOME] (Il s'agit en fait ici de ce qu'il ressort de l'année, s'il reçoit les félicitations, s'il doit être réorienté ...)

- Une année se divise en 3 trimestres [TERM] pour lesquels on évalue pour chaque étudiant :
* L'assiduité de l'étudiant en %age [Attendance Percentage]
* Le progrès de l'étudiant [Progression]

Egalement, concernant mon MCD, je sais que certains identifiants des certaines entités ne sont pas visibles, je les ai cachées volontairement, puisque ce n'est en quelque sorte qu'un brouillon.

Merci d'avoir pris le temps de me lire, et merci d'avance aux gens qui répondront à mon post.

[fsmrel]

Bonjour Khezu,


Pour un premier jet, ça n’est pas mal, les règles de gestion sont bien présentées, en bon français. Vous pourriez peut-être utiliser l’identification relative (ou encore passer de la notation Merise à la notation E/R), ce qui permettrait de prendre en compte des contraintes jusqu’ici implicites, du genre [Pays] -> [Applies]. En effet, en l’état un étudiant peut payer des frais d’inscription pour des années qui ne le concernent pas. Par ailleurs, selon votre représentation, ces frais d’inscription existent indépendamment des élèves, mais la présence d’un attribut tel que Paid paraît invalider cette proposition.

Exemple (à supposer que les frais d’inscription soient ceux d’un élève) :

Diagramme conceptuel :



Diagramme logique :



N.B. Ce commentaire vaut bien entendu pour les relations entre l'élève et les autres entités (les cours qu'il suit, ses résultats, son assiduité...)

A suivre.

[fsmrel]

J’ajoute ici la représentation E/R selon Power AMC, plus ramassée que la représentation merisienne (économie des ronds, si je puis dire).

[Khezu]

Merci pour votre réponse,

Ceci dit, je me pose du coup une question : si je fais des associations entre les étudiants, les frais, la formation, les résultats des entités et que j'utilise l'identification relative, qu'en est-il de ma première entité YEAR ?
En d'autres termes, en fait, comment dois-je diviser chaque année en trimestre ? Suis-je supposé garder la même structure avec YEAR, qui sera simplement liée à TERM, ou suis-je supposé faire davantage de modifications ?

[fsmrel]

qu'en est-il de ma première entité YEAR ?

A priori, elle part en fumée. Il ne faut pas oublier qu’il ne s’agit tout compte fait que d’une banale spécialisation du type ENTIER, et qui ne fait l’objet d’une entité-type que pour des questions de représentation graphique en Merise disons version 1. Il en va de même pour le trimestre, mutatis mutandis.

Par ailleurs, le suivi de la progression et celui de l’assiduité vont normalement de pair, auquel cas on peut les regrouper dans une même entité-type SUIVI (je vous laisse le soin de remplacer par le terme anglais qui convient...) :

Diagramme merisien



Diagramme E/R



Diagramme logique

[Khezu]

Merci encore pour votre réponse,

Je rencontre cependant un nouveau problème avec mon projet. Je ne sais pas si la section est du coup appropriée, mais je préfère encore éviter un nouveau post.

J'ai généré mon MPD et essayé de générer la Base de Données, cependant lors de la génération je me retrouve face à de nombreuses erreurs. En fait, il y en a sur quasiment chacune de mes instructions, il est de fait difficile de les énumérer, je vous joins donc mon MPD et mon MCD.
Je pense que la plupart viennent du fait qu'AMC présente à Access des types de données avec une mauvaise syntaxe. Par exemple CURRENCY qui devrait être MONEY, ou COUNTER qui devrait être AUTOINCREMENT, si je ne dis pas de bêtise.

D'avance, merci.

EDIT : Après un peu de bidouillage, le script semble mieux marcher, cependant certaines erreurs persistent. Et ma table STUDENT manque toujours à l'appel dans ma base de données.
MCD/MPD mis à jours dans l'archive jointe, les derniers étant encore plus erronés.

[fsmrel]

Bonjour,


Je ne dispose que de la version 11 de Power AMC et il ne m’est pas possible de reproduire vos erreurs. Vous avez réussi à dériver le MCD, il n’y a donc rien de bloquant. Cela dit, les SGBD SQL n’aiment pas particulièrement les noms de colonnes comportant des espaces : commencez par normaliser ces noms, par exemple : « Agent_First_Name » ou « AgentFirstName » plutôt que « Agent First Name » et dites-moi s’il y a autant d’erreurs au stade MPD.


A propos des index, avez-vous consulté la documentation en ligne de Power AMC ?





Remarques :

Je note que l’entité-type AGENT n’a pas d’identifiant : corriger.

Le nom des entités-types est à mettre au singulier (STUDENT est un nom de type, STUDENTS n’en est pas un).

Avec Power AMC V11, je peux tout de même accéder en lecture à vos modèles. Attention à la consommation d’espace : CHAR(128) est excessif pour un nom d’étudiant et autres données du même acabit.

Evitez les NULLs.


Tenez-moi au courant, on devrait résoudre les problèmes.

[Khezu]

Merci encore pour la lumière.

Je sais que 128 caractères pour un nom d'étudiant peut paraître démesuré, mais on traite ici d'étudiants étrangers, principalement indiens, pakistanais, qui ont parfois des noms vraiiiiment très long (un des élèves inscrit a un nom qui, comptant les espaces, atteint les 95 caractères). Enfin, merci tout de même pour le conseil.
Qu'entendez-vous par "évitez les NULLs" ? Essayer de mettre un maximum d'attributs en "obligatoire" afin d'avoir des NOTNULLs ?

Les erreurs lors de la génération persistent, ci-joint le journal d'exécution du script SQL.

[fsmrel]

Bonsoir,

Les erreurs lors de la génération persistent

J'ai fait un test avec Access 2003.

Il faut remplacer le type CURRENCY par le type MONEY.

Concernant la table STUDENT, il faut remplacer CHAR(n) par VARCHAR(n) dès que n > 10 (disons de cet ordre de grandeur). Ceci vaut pour toutes les tables. VARCHAR permet de compacter les données. Exemple :

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
18
19
20
21
22
23
24
25
CREATE TABLE STUDENT
(
    STU_NO               CHAR(8)         not null,
    CAS_CODE             SMALLINT,
    AG_ID                INTEGER,
    CAS_NO               VARCHAR(32),
    STU_FNAME            VARCHAR(128)    not null,
    STU_SNAME            VARCHAR(128)    not null,
    STU_DOB              DATE            not null,
    STU_NAT              VARCHAR(64)     not null,
    STU_PASS             VARCHAR(64)     not null,
    STU_VISANO           VARCHAR(64),
    STU_VISAEXP          DATE,
    STU_HADD1            VARCHAR(254)    not null,
    STU_HADD2            VARCHAR(254),
    STU_TADD1            VARCHAR(254),
    STU_TADD2            VARCHAR(254),
    STU_EMAIL            VARCHAR(254),
    STU_TEL              CHAR(10),
    STU_MOB              CHAR(11),
    STU_ENG              VARCHAR(254),
    STU_QUAL             VARCHAR(254),
    STU_ENROL            DATE,
    STU_ACCEPT           BINARY(1)
)

Concernant NULL, voyez par exemple ici ou là...

[Khezu]

Bonjour,

Pour ce qui est des NULLs, je comprends mieux l'importance de les éviter. Mais question quand même, pauvre étudiant de première année que je suis (si en plus on considère que j'ai raté énormément de cours ...), mon vocabulaire est un peu limité. Lorsqu'on parle de table associative, on parle de la table intermédiaire, comme dans les liens n-n ?

Par contre je me suis repenché sur le MCD, plus particulièrement l'entité COURSE, je me trompe peut-être, mais si j'ai une identification relative comme suit :

COURSE -(1,1)----FOLLOWS----0,n- APPLICATION

Je me retrouve avec les informations concernant l'année et l'étudiant dans ma table COURSE. Or ce n'est pas ce que je souhaite, puisque dans cette table là doivent figurer uniquement le code, le nom et le numéro des formations.
Puisque :
Un élève suit obligatoirement une formation chaque année, et une formation peut être suivie par plusieurs élèves (Ou aucun, à un moment donné, si une nouvelle formation est créée pour l'année suivante, par exemple)
Si on fait juste un lien entre COURSE et STUDENT, on obtiendrait quelque chose comme :

COURSE -0,n----FOLLOWS----1,1- STUDENT

Or mon problème est que je souhaite connaître aussi l'année pour laquelle l'élève a suivi cette formation. Si c'est APPLICATION qui est relative à COURSE, je vais me retrouver avec l'identifiant de COURSE (CourseId) dans les tables MONITORING (le suivi), FEE, et OUTCOME, je crois donc que cette solution n'est absolument pas viable.
Si je fais simplement :

COURSE -0,n----FOLLOWS----1,1- APPLICATION

J'aurai CourseId en clé étrangère dans ma table APPLICATION, et il me semble que c'est là ce que je veux. Le problème maintenant, c'est que quand je fais ça, je me retrouve à nouveau avec des erreurs lors de la génération de ma base de données : La contrainte CHECK n'existe pas [...]

(Le problème est le même avec l'entité OUTCOME, ce sont des valeurs prédéfinies, un peu comme le statut CAS, il n'en existe que trois : Full Award, Partial Award et Articulation. Je me retrouve donc dans une situation similaire à celle de COURSE avec cette entité-là.)

[fsmrel]

Bonsoir Khezu,

Lorsqu'on parle de table associative, on parle de la table intermédiaire, comme dans les liens n-n ?

Oui, mais utilisez surtout l’expression « table associative », beaucoup plus adéquate, parlante et précise.

Si je fais simplement :

COURSE -0,n----FOLLOWS----1,1- APPLICATION

J'aurai CourseId en clé étrangère dans ma table APPLICATION, et il me semble que c'est là ce que je veux.

Et en plus, c’est ce qu’il faut !

Même chose pour OUTCOME.

Le problème maintenant, c'est que quand je fais ça, je me retrouve à nouveau avec des erreurs lors de la génération de ma base de données : La contrainte CHECK n'existe pas [...]

Plus précisément ? Est-ce ACCESS qui râle ? Pour quelle table ? Quel est exactement le message ? Toutes vos tables sont-elles présentes dans la base de données ACCESS ? J’ai fait un test, toujours avec ACCESS 2003, je n’ai pas d’erreur. Pour y voir plus clair, j’ai supprimé (provisoirement) la plupart des attributs de la table STUDENT. Par ailleurs, j’ai remplacé tous les COUNTER(2) par COUNTER (les attributs participant aux clés étrangères sont alors du type INTEGER).

Le MLD proposé par ACCESS 2003 :

[Khezu]

Bonjour,

Apparemment l'erreur ne s'est produite que sur la première fois que j'ai essayé d'exécuter le script, puisqu'en réessayant ce matin, aucune erreur ne s'est produite. J'ai bien toutes mes tables dans la base de données, et toutes les relations correspondent.

Du coup je crois que tout est bon.

Donc un grand merci, fsmrel, de m'avoir sorti une énorme épine du pied.

Petite curiosité au passage :
Si j'ai bien retenu la leçon quant au NULLs, étant donné que mon association entre STUDENT et AGENT était de type 0,1 - 0,n, j'ai crée une entité associative entre ces deux entités. Cependant PowerAMC me force à insérer des attributs dans ladite entité associative (j'ai donc mis un attribut en autoincrément pour faire tourner la chose), or j'ai déjà vu des tables associatives n'ayant pour champ que les deux clefs primaires des tables associées. Et si j'en crois ce que j'avais lu à ce sujet, l'autoincrément dans une telle table ne sert strictement à rien voire même il complique les choses pour rien.
De fait je me demande : est-il possible d'en effet n'avoir que les deux clefs primaires en tant que champs dans ma table ?

[fsmrel]

Bonsoir Khezu,

Étant donné que mon association entre STUDENT et AGENT était de type 0,1 - 0,n, j'ai créé une entité associative entre ces deux entités.

C’est parfait.

Cependant PowerAMC me force à insérer des attributs dans ladite entité associative

... Ou il vous force à modifier les paramètres de génération !


Partons donc de la représentation suivante :


Avant de générer le MLD, faites (au moins avec la version 11 de Power AMC) :

Outils > Vérifier le modèle

Il y a affichage de la fenêtre « Paramètres de vérification du modèle » : vous ouvrez le dossier Entité et vous décochez la case « Existence d’attributs ». Bien que ce ne soit pas une nécessité, vous pouvez aussi décocher la case « Existence d’identifiants ».

Après cela, roulez !

Est-il possible d'en effet n'avoir que les deux clefs primaires en tant que champs dans ma table ?

Attention au vocabulaire. En SQL il n’y a pas de champs mais des colonnes (Haro sur ACCESS qui donne le mauvais exemple !) Pour ma part, j’utilise aussi le terme attribut, mais je me situe alors dans le contexte du Modèle Relationnel de Données. Par ailleurs, une clé primaire est un ensemble (au sens de la théorie des ensembles) dont les éléments sont des noms de colonnes.

La table STUDENT ayant pour clé primaire {StudentNumber}, la table AGENT ayant pour clé primaire {AgentId}, la table ST_AG a pour clé primaire {StudentNumber}, elle a pour clés étrangères {StudentNumber} et {AgentId}. Elle n’a que deux attributs : StudentNumber et AgentId.

[Khezu]

Bonjour,

Mon dernier enregistrement s'étant apparemment mal effectué, je me suis retrouvé avec tous mes fichiers corrompus, et ai donc du tout rebâtir. Or maintenant je me retrouve, après création de mon entité associative (STU_AG) et passage au MLR, avec deux liens entre STU_AG et STUDENTS, et lors de la vérification du modèle, il détecte une dépendance circulaire pour ces deux-là : soient IL2 et IL3 les deux liens entre STU_AG et STUDENTS, j'ai pour cardinalités :

- Pour IL2 :
STU_AG vers STUDENT Dépendant; Obligatoire; 1,1
STUDENT vers STU_AG Obligatoire; 1,1

- Pour IL3
STU_AG vers STUDENT Dépendant; Obligatoire; 1,1
STUDENT vers STU_AG Obligatoire; 1,1

PowerAMC me propose de corriger le problème en décochant la propriété "Dépendant" du lien ou en supprimant un lien d'héritage.

Si je supprime un lien, deux références sont créées lors du passage au MPD, toujours au même endroit, et il m'indique une référence circulaire.
Si je décoche "Dépendant", je me retrouve avec deux fois plus de références, et j'ai toujours mes références circulaires.

Encore une fois, l'aide de PowerAMC propose comme correction manuelle de décocher "check on commit", pas cochée et grisée, ou de décocher "parent obligatoire". Il me semble que c'est sensiblement la même chose que supprimer la dépendance.

Si je décoche "parent obligatoire", je peux générer ma base de données, mais ma table associative n'a plus d'intérêt, non ? Puisqu'au final, elle ne se remplira pas en fonction du couple STU_NO - AG_ID entré dans ma table STUDENT.

Encore une fois, merci pour la lumière. C'est que je me sens de plus en plus incompétant

[fsmrel]

Bonjour Khezu,


De mon côté, je ne dispose pas de la version 15 de Power AMC, mais seulement de la V11, avec laquelle on passe directement du MCD au MPD. Ce que je raconte ci-dessous est donc à aménager, mais en principe vous ne devriez pas rencontrer de problème.

Quittez la notation Merise au bénéfice de la notation Entité/Relation. Pour cela :

Outils > Options du modèle, puis choisissez « Notation Entité/Relation ».

Automatiquement, le MCD prend l'allure suivante (qui la première fois peut surprendre, mais on s'y fait vite) :


Cliquez sur le lien connectant STUDENT et ST_AG et choisissez « Propriétés » Définissez un rôle dominant, dans le sens STUDENT -> ST_AG :


Au résultat :



Après dérivation le diagramme ne comporte plus de cycle :


Conclusion : demandez à l’éditeur de Power AMC de prévoir la fonctionnalité « Rôle dominant » pour la notation Merise . Maintenant, si vous tenez à conserver cette notation, après dérivation vous supprimerez à la main le lien perturbateur (de lui-même AMC supprimera aussi dans STUDENT l’attribut parasite source de la clé étrangère référençant ST_AG).

Encore une fois, merci pour la lumière. C'est que je me sens de plus en plus incompétant

N'oubliez pas qu'en vertu du principe de Peter, nous tendons tous à nous élever vers notre niveau d'incompétence, mais y sommes nous déjà asymptotiques ? Là est la question...

Quoi qu'il en soit, si certaines de mes réponses vous paraissent utiles, n'hésitez pas à voter, ça me récompensera de mes efforts...

[Khezu]

Bonjour,

Apparemment tout marche correctement maintenant (:

Désolé, j'étais tellement plongé dans mes lectures sur Access que j'en ai complètement oublié de vous remercier.

Donc bah, un énorme merci pour tout le temps investi.

[fsmrel]

Bonjour Khezu,

Puisque tout va, alors il ne me reste plus qu'à vous souhaiter bon vent !