Sais-tu que tu as ouvert ta discussion dans le forum Microsoft Access ?Envoyé par Dotie
C'est pour ça que je réponds avec des schémas Access depuis le début
Sinon, sur quel SGBD tu es ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Sais-tu que tu as ouvert ta discussion dans le forum Microsoft Access ?
Sinon, sur quel SGBD tu es ?
Arduino, Raspberry Pi, ESP, Cypress PSoC, FPGA...
Forums Arduino, Raspberry Pi
Apprendre à développer sur FPGA avec Intel Quartus Prime - Communication SPI avec un convertisseur Analogique-Numérique, simulation fonctionnelle et analyse des signaux [Nouveau]
FPGA - Programmer un contrôleur pour écran VGA avec une carte de développement FPGA
Arduino : Le manuel de laboratoire, les Quiz, les cahiers pratiques, [Nouveau] les sources et outils
Sur MysqlSais-tu que tu as ouvert ta discussion dans le forum Microsoft Access ?
Sinon, sur quel SGBD tu es ?
MySQL Workbench permet de représenter les diagrammes à la ACCESS (onglet Model > Relationship Notation > Connect to column), cf. paragraphe 4.7.
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
quelqu'un peut il m'aider svp
Bonjour Dotie,
On va essayer de vous aider comme l’a fait f-leb qui est peut-être bien occupé pour le moment.
Une première remarque :
Selon vos diagrammes, un employé peut faire partie de plusieurs départements. Certes, au fil du temps un employé a pu faire partie de différents départements, mais je pose la question : à une date donnée, un employé ne fait-il pas partie que d’un seul département ?
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Salut,
Oui il existe dans l'entreprise des employes qui appartiennent a plusieurs departements a la fois...C'est vrai qu'ils ne sont pas nombreux dans ce cas..mais il en existe quand meme...merci
Bonjour Dotie,
Table EMPLOYE : l’attribut EmpMatricule est à déclarer comme clé candidate (cocher la case UQ pour cet attribut). Vous lui avez affecté le type BIGINT, lequel vous permet d’avoir 2^63 - 1 employés (ouch !)... Pour mémoire, le type INT vous permet d’en avoir 2^31 - 1 et le type SMALLINT 2^15 - 1.
Tous les attributs dans vos tables peuvent être marqués nuls : veuillez systématiquement cocher la case NN (Not Null).
La table DEPARTEMENT_EMPLOYE associe les tables DEPARTEMENT et EMPLOYE, elle est dite associative. Elle hérite des attributs DeptId et EmpId qui font l’objet de clés étrangères (cf. vos mickeys FK) mais qui donnent fondamentalement lieu simultanément à la clé primaire {DeptId, EmpId} de la table.
Pour établir l'association (cf. mon article, paragraphe 4.2), on clique sur l'icône « n:m Identifying Relationship », puis successivement sur les tables DEPARTEMENT et EMPLOYE ; au résultat :
Les clés primaires ont viré du jaune au rouge : ceci vient du fait que j’utilise ici la version 6.3 de MySQL Workbench, c’est sa façon de montrer qu’un attribut participe à la fois à une clé primaire et à une clé étrangère. Avec la version 6.0 (cf. mon article), les clés primaires restent en jaune. Avec la version 8, je ne sais plus, car quand je l’ai testée elle était en l’occurrence défectueuse et j’ai eu beau le signaler à l’éditeur, celui-ci n’a semble-t-il rien fait... Si vous avez aussi des problèmes de cette nature, alors utilisez la version 6.3.
Cela sous-entend-il qu’un employé ne peut suivre que les formations organisées par les département auxquels il est affecté ? Il est important de préciser ce point, car s’il est ainsi, le diagramme correspondant est le suivant :
On observe dans ce diagramme qu’une formation est organisée par un département et un seul. La clé primaire de la table FORMATION est composée de la paire {DepartId, FormationId}, l’attribut FormationId ne servant qu’à distinguer les unes des autres les formations organisées par un département. L’identification de FORMATION est relative cf. paragraphe 5.2 de l’article.
A son tour, la table SESSION permet pour chaque formation de distinguer les sessions les unes des autres. Elle a pour clé primaire le triplet {DepartId, FormationId, SessionDate}. L’attribut SessionDate permet de mettre en oeuvre ce distinguo (identification relative à nouveau), et tant qu’à faire, il est de type Date.
La table PARTICIPATION est associative. Plutôt que de mettre en relation les tables EMPLOYE et SESSION, il est plus judicieux de mettre en relation les tables DEPARTEMENT_EMPLOYE et SESSION, car ainsi on garantit qu’un employé n’ira pas suivre les formations organisées par des départements auxquels il n’est pas affecté.
Avant d’aller plus loin et poursuivre le travail entrepris par f-leb, j’attends la réponse à la question que j’ai posée et qui conditionne la pertinence du diagramme ci-dessus (structure de la table PARTICIPATION).
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Salut fsmel,
Merci beaucoup ! Je ne comprend pas trop pourquoi on met l'attribut EmplMatricule en cle candidate ..je peux avoir plus d'explication stp?..je me suis faite une idee sur ce que c'est une cle Candidate...pourquoi on l'utilise je n'ai pas bien compris..merci d'avance
Il peut arriver qu'un employe suive une formation offerte dans un autre departement pour une quelconque.
Il peut avoir des formations qui seront faite dans differents departements...genre les employes de differents departements doivent subir une meme formation.
Il y'a aussi des formations specifiques a chaque departement
Bonjour Dotie,
Dans le contexte de la modélisation des bases de données, plus précisément dans le contexte SQL, une clé candidate se définit par les caractéristiques suivantes :
Une clé candidate est un sous-ensemble d’attributs K d’une table T, où sont respectées les deux contraintes suivantes :
Unicité. Deux lignes distinctes de T ne peuvent pas avoir simultanément la même valeur de K ;
Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.
Pour une définition plus formelle, reportez-vous à celle qui est donnée dans mon article Bases de données relationnelles et normalisation :
de la première à la sixième forme normale.
Reprenons votre table EMPLOYE (les noms des attributs sont mis entre accolades pour qu’on obtienne des sous-ensembles d’attributs).
{EmpId} est un sous-ensemble de l’ensemble des attributs de la table EMPLOYE, et c’est une clé candidate car d’une part il est interdit que deux lignes de la table aient la même valeur pour l’attribut EmpId et d’autre part la seule réduction possible pour {EmpId} est l’ensemble vide {}, mais celui-ci ne respecte pas la contrainte d’unicité (dès que la table contient plus d’une ligne).
{EmpNom} est un sous-ensemble des attributs de la table EMPLOYE mais ça n’est pas une clé candidate car il est permis que deux employés portent le même nom.
La paire {EmpId, EmpNom} est un sous-ensemble des attributs de la table EMPLOYE mais ça n’est pas une clé candidate car bien que respectant la contrainte d’unicité, elle ne garantit pas celle d’irréductibilité puisqu’un de ses propres sous-ensembles, {EmpId}, garantit la contrainte d’unicité. Cette paire est alors une surclé (superkey).
{EmpMatricule} est un sous-ensemble des attributs de la table EMPLOYE est c’est une clé candidate car s’il est interdit que deux employés aient le même matricule, alors deux lignes de la table EMPLOYE ne peuvent pas avoir la même valeur pour l’attribut EmpMatricule, et d’autre part {EmpMatricule} est irréductible à l’ensemble vide {}, puisque celui-ci ne respecte pas la contrainte d’unicité.
La paire {EmpId, EmpMatricule} est réductible, donc ça n’est pas une clé candidate, même chose pour la paire {EmpMatricule, EmpNom}, pour le triplet {EmpMatricule, EmpNom, EmpPrenom} et autres sous-ensembles. Ainsi, {EmpId} et {EmpMatricule} sont les seules clés candidates de la table EMPLOYE.
Par ailleurs, en SQL on définit la « clé primaire » d’une table : quand celle-ci possède plus d’une clé candidate, on doit choisir celle qui sera cette clé primaire, les autres étant ravalées au rang de dauphines de la « Miss » clé primaire, elles seront appelées clés alternatives (alternate keys).
A titre d’exercice, vous pouvez dresser l’inventaire des clés candidates de la table des éléments chimiques et choisir celle qui sera clé primaire pour SQL.
Voulez-vous dire qu’un employé peut suivre des formations offertes par des départements dont il ne fait pas partie ?
S’il en est ainsi, alors le diagramme (moins restrictif) ci-dessous serait celui qui est pertinent :
Merci de confirmer.
Vous remarquerez que contrairement à ce qu’on voit dans votre diagramme, il n’y a pas de table FORMATION_EMPLOYE explicite, car elle n’est en fait qu’un sous-ensemble de la table PARTICIPATION, donc on peut en faire une vue, manipulable en SQL comme une table.
A suivre.
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Salut fsmrel,
Voulez-vous dire qu’un employé peut suivre des formations offertes par des départements dont il ne fait pas partie ?
Oui c'est ce que je voulais dire...merci
Maintenant dans ton diagramm on remarque que chaque formation est specifique a un departement ..Qu'en ai t'il des formations offertes dans different departement?..genre une meme formation que doit subir des employes de differents departements...d'ou la classe DepartementFormation dans mon Diagramm...merci d'avance
Bonjour Dotie,
De façon générale, je fais plutôt référence aux règles de gestion. Vous aviez fourni les deux règles suivantes :
J’ai interprété ainsi la 1re règle :
Une formation est dispensée dans un et un seul département
En effet, sans autre précision et selon l’usage « un » équivaut à « un et un seul ».
Disons que j’ai pu interpréter la règle un peu trop vite, car si on l’analyse, elle peut être réécrite ainsi sans en changer le sens :
Dans un département au moins une formation est dispensée
Ce qui revient à dire que cette règle est équivalente à la 2e ! Donc la véritable 1re règle est manquante...
Pour éviter tout quiproquo, il est préférable de rédiger les règles de la façon suivante :
Un département dispense au moins une formation
Une formation est dispensée dans au moins un département
C’est-à-dire que dans chaque phrase on commence par citer un des deux acteurs : « Un département », « Une formation » ;
Intervient ensuite le verbe, à la forme active ou passive : « dispense », « est dispensée » ;
Intervient en suite la cardinalité : « au moins », « au plus », « et au plus », etc.
Et intervient finalement l’autre acteur.
Bon, le diagramme évolue :
Mais f-leb rappelle que l’ubiquité n’est pas de mise ici, je le cite :
A une date donnée, si un employé ne peut donc participer qu’à une seule session, alors le diagramme précédent doit être aménagé : l’attribut FormationId est expulsé de la clé primaire de la table PARTICIPATION et se contente d’appartenir à la clé étrangère référençant la table SESSION (d’où le remplacement de la clé rougeâtre par un losange rougeâtre accompagnant cet attribut) :
A ce sujet, je fais référence au post #29 et rappelle les deux contraintes que doivent respecter les clés candidates (donc les clés primaires).
Soit K une clé candidate d’une table T :
Unicité. Deux lignes distinctes de T ne peuvent pas avoir simultanément la même valeur de K ;
Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.
Si le triplet {EmpId, FormationId, SessionDate} était retenu comme clé candidate, on pourrait avoir ceci :
D’où ubiquité...EmpId FormationId SessionDate e1 f1 2019_11_17 e1 f2 2019_11_17
En fait, la contrainte d’irréductibilité est violée, car le sous-ensemble du triplet, à savoir la paire {EmpId, SessionDate} garantit l’unicité. Cette paire devient clé primaire tandis que le triplet est ravalé au rang de surclé (respect de la contrainte d’unicité).
Quoi qu’il en soit, l’ubiquité reste possible, car il faut tenir compte de la durée des formations pour s’assurer que les périodes ne se recouvrent pas. A cette occasion je signale que l’attribut FormationDuree (table FORMATION) est du type entier (disons tinyint ou smallint) et pas TIME qui s’exprime en heures, minutes, secondes.
Avant d’aller plus loin sommes-nous en phase ?
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Salut fsmrel,
merci vraiment! oui c'est nous somme en phase...
La table Participation enregistre les informations de qui a subit quelle formations a quelle Sessions nespa? Maintenant quand je vois la relation entre la Table Session et participation je comprends que la table Participation ne peut enregistrer qu'une seule session.
.Il y'a des formations que les employes doivent subir deux fois l'annee par exemple oubien meme apres chaque 1 ans...ca veut dire qu'un employe peut participer a deux session differente d'une meme formation d'ou la table SessionParticiper dans mon diagramm...peut etre je comprend mal le role de ma prope Table Participer(table Participation chez toi) ...merci pour ton aide
Bonjour Dotie,
On est bien d’accord ! L’exemple ci-dessous, conforme à mon modèle, montre que l’employé e1 a participé à la formation f1 à la date d1 et à la date d2. L’attribut FormationId étant exclu de la clé primaire de la table PARTICIPATION, alors à la date d1 (même chose à d2) e1 ne pourra pas participer à une autre formation : ubiquité impossible.
Les clés primaires sont soulignées.
FORMATION {FormationId, ...} f1 ... f2 ... SESSION {FormationId, SessionDate} f1 d1 f1 d2 f2 d1 PARTICIPATION {EmpId, FormationId, SessionDate, Resultat} e1 f1 d1 r1 e1 f1 d2 r2 EMPLOYE {EmpId, ...} e1 ...
Passons à votre diagramme et voyons ce qui peut se passer avec l’employé e1. Je note en passant que votre table SessionParticiper est dépourvue de clé primaire : c’est une faute, veuillez remédier à cela.
Selon votre modèle, à l’instant d1 l’employé e1 peut participer à la fois à la formation f1 et à la formation f2. Qui plus est, rien n’interdit qu’il participe à d1 à la session s1 et à la session s2 de la formation f1 !
Employe {EmpId, ...} e1 ... Participer {ParticiperId, FK_EmpId, Resultat} p1 e1 r1 p2 e1 r2 SessionParticiper {FK_SessionId, FK_ParticiperId} s1 p1 s1 p2 s2 p1 s3 p1 Session {SessionId, FK_FormationId, SessionDateHeure, ...} s1 f1 d1 s2 f1 d1 s3 f2 d1 Formation {FormationId, ...} f1 ... f2 ...
Avec le modèle que je vous ai proposé, tout cela est impossible, pas d’ubiquité !
Pour mémoire, votre modèle pour la partie qui nous intéresse :
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Salut fsmel,
merci beaucoup c'est claire maintenant pour cette partie la
Pour le reste du modele c'est ok?
Bonjour Dotie,
Vous avez écrit
Et votre diagramme est conforme à ce que vous avez écrit :
[FORMATION]>|--------O|--[FORMATEUR]
Autrement dit, certaines formations peuvent ne pas avoir de formateur. Il s’agirait alors d’auto-formations ? Merci de nous éclairer à ce sujet.
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Salut fsmrel,
oui c'est exactement ca!
Il y'a des formations ou les employes recoivent juste des document qu'il devront lire et apres subir des controles.
Dotie,
Vu pour les auto-formations.
Par ailleurs vous avez écrit :
Cette phrase est-elle équivalente à celle-ci :
Une formation peut comporter un contrôle d'efficacité.
Autrement dit le mot « cours » est-il simplement du bruit, auquel cas il peut disparaître, sinon quel sens donner à ce mot ?
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager