Version imprimable
je me suis proposer de gerer les notes des etudiants d'une ecole en utilisant des règle de gestion supposé standart.
ce mcd comporte les avertissements suivants!
comment puis-je les coriger?
y'at-il quelque chose à dire sur le MCD?
Pièce jointe 286030
verifier: circularité formée de lien obligatoire
Pièce jointe 286035
Bonjour,
Il y a beaucoup de cardinalités mini 1 qui devraient être mises à zéro, par exemple un étudiant n'a pas forcément de diplôme, et un nouveau diplôme peut exister sans qu'aucun étudiant ne l'ait encoe obtenu
il faut donc remplacer ETUDIANT 1,n --- AvoirDiplome --- 1,n BACCALAUREAT par ETUDIANT 0,n --- Obtenir --- 0,n DIPLOME
Notez que j'en profite pour suggérer une simplification du nom de la relation, et une banalisation du type de diplôme, l'entité-type est bien un diplôme qui peut être en relation si vous le souhaitez avec un type de diplôme (type bac, type licence, etc...)
Quand vous aurez corrigé ces card, mini, on verra déjà plus clair ;)
Les messages d'erreur sont liés à des cardinalité 1, or il y a plusieurs choses suspectes (vous auriez du communiquer les règles de gestion pour lever toute ambiguïté) :
La card 1,1 entre ETUDIANT et inscrire : un étudiant n'a pas le droit de changer de filière ? ce serait étonnant. 1,n voire 0,n semble plus correct.
La card 1,1 entre SEMESTRE et ContenirSN : des explications s'imposent, c'est quoi cette relation entre SEMESTRE et NIVEAU ?:weird:
La card 1,1 entre DEVOIR et ProposerDev implique que si un enseignant est supprimé, le devoir disparait :aie: ca semble brutal !
Vérifiez aussi vos id primaires, un id primaire ne devrait jamais être de type texte (char, varchar etc...) encore moins un char long (ex : BACCALAUREAT)
Privilégiez le type integer pour vos identifiants primaires ;)
Une remarque : les noms d'entité-type devraient être des singuliers, par exemple ENSEIGNANT et non ENSEIGNANTS
Une autre remarque : ETUDIANT et ENSEIGNANT sont des personnes, il faut donc créer une ET "PERSONNNE" pour ce qui est commun aux enseignants et aux étudiants (nom, prénom, date de naissance...) et créer deux sous-types pour ce qui est spécifique à l'un et à l'autre.
Salut,
Merci pour les suggestion apportées!
Moi j'avais interprété la cardinalité 1,1 (de Etudiant --> innscrir) par un etudiant n'a pas le droit de s'inscrir deux foi pour la même année dans plus d'une filière.Citation:
...un étudiant n'a pas le droit de changer de filière ?
voici la lecture que j'y est faite a ce niveau: un semestre appartient 1 et 1 seul niveau et un niveau contient 1 ou n semestre.Citation:
La card 1,1 entre SEMESTRE et ContenirSN : des explications s'imposent, c'est quoi cette relation entre SEMESTRE et NIVEAU ?
jai supposer que l'enseignant proposait 1 et 1 seul devoir (en ce qui concerne sa matière)Citation:
a card 1,1 entre DEVOIR et ProposerDev implique que si un enseignant est supprimé, le devoir disparait ca semble brutal !
Tout de même j’aperçois maintenant ce que vous dites! Mais dites moi la démarche pour appréhender ce genre de perception!!
je ne metrise pas encore très bien la notion d'héritage, de laide serait la bien venu à ce niveau.Citation:
Une autre remarque : ETUDIANT et ENSEIGNANT sont des personnes, il faut donc créer une ET "PERSONNNE" pour ce qui est commun aux enseignants et aux étudiants (nom, prénom, date de naissance...) et créer deux sous-types pour ce qui est spécifique à l'un et à l'autre.
Si c'est ce que vous voulez faire, alors il faut créer une entité-type "ANNEE" et créer une association à 3 pattes en ajoutant année dans cette relation, car en l'état, année n'est qu'un attribut du coup un étudiant ne peut pas changer de filière meme l'année suivante !Citation:
Envoyé par Toogda
D'accord mais définissez d'abord ce qu'est un niveau et la nature de cette relation car je ne vois pas ce qui peut mettre en relation un semestre avec un niveau ?Citation:
Envoyé par Toogda
A chaque fois que vous mettez une cardinalité mini de 1, vous rendez obligatoire la relation donc, si vous voulez rendre possible le départ d'un enseignant (à la retraite par exemple) sans pour autant perdre les devoirs qu'il a proposés, il suffit de remplacer la cardinalité mini 1 par 0.Citation:
Envoyé par Toogda
Je vous recommande la lecture de ce sujet, il vous sera très utile ;)Citation:
Envoyé par Toogda
https://merise.developpez.com/faq/?p...ages-possibles
ça avance bien mais il y'a un avertissement sur l’héritage que j'aimerais pouvoir corriger.
voici le MCD corigé et l'avertissement
Pièce jointe 286425Pièce jointe 286430
y'aurait - il d'autres remarques?
Cette erreur est normalement non bloquante : Power AMC vous signale seulement que l'entité "Personne" n'est en relation avec aucune autre entité-type, pour que vous puissiez vérifier que ce n'est pas un oubli.
Vérifiez aussi vos id primaires, un id primaire ne devrait jamais être de type texte (char, varchar etc...) encore moins un char long (ex : BACCALAUREAT)
Privilégiez le type integer pour vos identifiants primaires
Salut alors comment gérer les code portant un suffixe école num facture: FC. 0010/19 ?
La question n'est pas claire
Quoi qu'il en soit, rien n'interdit, bien au contraire, d'ajouter à l'identifiant primaire (qui deviendra la PK au niveau tabulaire) des identifiants alternatifs, dits secondaires, qui peuvent, eux, être de tout type, y compris char ou varchar. Seul l'identifiant primaire doit être asémantique, car c'est lui qui participe aux contraintes d'intégrité. Les identifiants sémantiques ont vocation à changer, or, modifier un id primaire a des conséquences lourdes sur la BDD à cause des contraintes cascade.
Salut tout le monde !!!!
j'aimerais une PROCUREURE en c# qui me permettrais de créer une sauvegarde de ma base de données qui initialisera par exemple la table facture client
c'est a dire remettre son code a 1 puis garder la table par exemple client tout en rajoutant de nouveaux clients de l'année suivante.
j'utilise sql server 2014.....
Merci de votre aide mes salutations
