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
Gestion de cours
Bonjour,
Je suis en train de planifier le développement d'un système pour une petite entreprise.
J'ai fait une petite explication des données, puis un modèle entité-association.
Est-ce que vous verrez quelque chose que j'ai mal fait ou que j'aurais oublié?
Merci
Salutations
Bonsoir ale252,
Votre diagramme est dépourvu de toute cardinalité : il faudrait les faire figurer.
N’y a-t-il qu’une seule secrétaire ?Envoyé par ale252
Votre diagramme est-il réalisé à la main ? Avec un outil de modélisation ?
Quel sera le SGBD ?
(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.
Bonsoir,
Tout d'abord merci pour vos commentaires!!
Ensuite, effectivement j'ai oublié une des parties les plus importantes, voici une version avec les cardinalités.
Il peut effectivement y avoir plusieurs secrétaires, il faut donc que je change le texte le "la" par "une".
J'ai dessiné le diagramme avec https://www.lucidchart.com/
Il d'agirait de mysql.
Merci encore
Salutations
Bonsoir ale252,
Il s’agit là d’une contrainte forte. Où figure dans votre diagramme le concept de site ?
Prenons cette partie du diagramme :
Je suppose que « nc » est synonyme de « 0,N ». De quoi est-ce l’abréviation ? A quoi correspond, quelle est la finalité du mot « Text » ?
Ce sont des permis de quoi ? De chasse ? De conduire des voitures ? De piloter des aéronefs ? D’enseigner ? ... ?
D’accord. Mais vous avez aussi créé dans le diagramme une association « Contient »entre les entités-types PERMIS et TYPE, non décrite dans votre document « Description de la base de données ». Quel est son rôle ? Pourquoi une cardinalité 0,1 sur la patte connectant l’entité-type TYPE et l’association Contient ? Par ailleurs, je note qu’il y a deux chemins possibles pour aller d’ELEVE à TYPE :
1) [ELEVE] > (Possède) > [PERMIS] > (Contient) > [TYPE]
2) [ELEVE] > (Est inscrit) > [Cours] > [INDIVIDUEL] > [A) > [TYPE]
Ce qui revient à dire que pour un élève donné E1, le type de chaque cours individuel auquel il est inscrit donne lieu à un ensemble T1 de types dont l’intersection avec l’ensemble T2 constitué des types associés aux permis possédés par l’élève E1 peut être vide (T1 ∩ T2 = ∅). Donc danger.
(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.
Il s'agit d'une modélisation d'une auto-école.
Pour être plus précis, il s'agit de plusieurs auto-écoles. Chaque auto-école a un seul moniteur, donc moniteur = auto-école.
Chaque auto-école a un site internet. Si l'élève vient depuis un site et désire s'inscrire, il tombera automatiquement sur le formulaire qui le liera directement au moniteur de cette auto-école. C'est ce que j'entends par:
nc veut bien dire 0..n, par contre le "text" est en trop, c'est mon outil de modélisation qui l'a rajouté, je ne sais pour quelle raison, je le supprime à l'instant.Un élève peut s’inscrire lui-même et selon de quel site il vient, il sera associé à un moniteur ou à un autre.
Un permis est un permis de conduire. Il peut s'agir d'un permis de voiture (catégorie B), ou un permis de camion (catégorie C), ou un permis de moto (catégorie A), etc...
Un cours individuel, est un cours ou le moniteur et l'élève sont seuls dans le véhicule. Un cours individuel a donc un type de cours (c'est un cours standard: par exemple un cours pratique voiture, qui a un prix donné, une description, indique s'il est facturable ou non). Un élève pour sa part peut avoir obtenu déjà un ou plusieurs permis. Un type contient donc également un permis, vu qu'un type de cours est un cours pour le permis x. Un type peut contenir un permis ou aucun. Par contre un permis peut être dans aucun, un ou plusieurs types.
Voilà j'espère que je suis assez clair, je vois que mon diagramme est encore pas prêt... Merci pour vos remarques!
Bonsoir ale252,
Maintenant que vous avez défini l’univers du discours (les auto-écoles et leurs élèves), j’y vois évidemment plus clair. Votre diagramme n’est pas mal, mais quelques points sont à vérifier.
L’entité-type UTILISATEUR est dotée de nombreux attributs : sont-ils tous pertinents quel que soit le sous-type ? Par exemple, l’attribut SoldeDuCompte concerne-t-il vraiment les secrétaires ?
Je propose que vous précisiez par oui/non la pertinence de chaque attribut pour chaque sous-type :
Attribut Eleve Moniteur Secrétaire DateDeNaissance Nom Prenom DateDeNaissance DateCreation DateDerniereConnexion Telephone Portable EstActif Nationalite SoldeDuCompte Adresse Login LienActivation
Dans votre document, il est précisé :
« La secrétaire peut inscrire, modifier ou supprimer un moniteur ».
Comme il y a plusieurs secrétaires, il devrait a priori y avoir une association à cet effet entre les sous-types MONITEUR et SECRETAIRE.
Selon votre diagramme, un élève est associé à un seul moniteur. Mais si un élève qui a passé avec succès un certain type de permis souhaite s’inscrire plus tard pour un autre type de permis, ça sera donc forcément avec un autre moniteur. Qu’en est-il dans la réalité ?
Je dirais plutôt maintenant que l’intersection T1 ∩ T2 = ∅ doit être systématiquement vérifiée, sinon un élève pourrait être inscrit pour suivre des cours concernant un permis qu’il a déjà. Suis-je trop strict ? Y a-t-il des subtilités faisant que la contrainte est trop forte ?
(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.
Il y a en effet des attributs qui ne sont pas lié à tous, voici le tableau. J'ai changé le modèle en conséquence.
Attribut Eleve Moniteur Secrétaire Remarques Nom oui oui oui Prenom oui oui oui DateDeNaissance oui non non DateCreation oui oui oui DateDerniereConnexion oui oui oui Telephone oui non non oui oui oui Si une fois on veut implémenter un système pour envoi de mails (qui n'est pas prévu actuellement Portable oui non non EstActif oui non non Nationalite oui non non SoldeDuCompte oui non non Adresse oui non non Login oui oui oui LienActivation oui non non
Concernant le modèle c'est vrai que je suis pas très bon pour choisir des verbes...
Sinon j'ai aussi rajouté les id, je les avait oublié.
J'ai aussi rajouté le lien entre la secrétaire et le moniteur.
Concernant le lien entre élève et moniteur c'est vrai que je sais pas trop quoi en penser. Vu que c'est des auto-écoles séparés, les coordonnées d'un élèves ne seront connus que par le moniteur qui lui est lié, il faut pas que les autres moniteurs aient accès à cette information. Par contre, s'ils changent de moniteur en cours de route, je suppose que le nouveau moniteur doit créer un nouveau compte pour l'élève...
Concernant le fait qu'un élève peut être inscrit a un cours qu'il a déjà, pourquoi pas, parfois des élève peuvent venir pour refaire des cours qu'ils ont déjà fait pour se rafraîchir (souvent pour des personnes âgées, mais pas uniquement)...
Bonsoir ale252,
Voilà qui est parfait !
On en est tous là, donc pas de panique. S’il y a des verbes dont le choix est à surveiller, ce sont ceux qui nomment des associations qui feront l’objet de tables au stade SQL. Alors là, foin de l’inspiration et de la littérature. Par exemple, l’association connectant les entités-types ELEVE et PERMIS a pour nom « Possède », et ce nom est tout à fait pertinent. Cela dit, pour ma part, au niveau SQL, je remplacerai ce nom par ELEVE_POSSEDER_PERMIS ou ELEVE_PERMIS, mais c’est quand même une histoire de choix personnel et d’habitude pour me faciliter la vie quand je cherche à m’y retrouver dans la masse des tables, mais ça reste assez subjectif, et si vous avez vos propres habitudes, et conservez le nom POSSEDE pour une table, c’est parfait.
Dans un contexte de généralisation/spécialisation, les sous-types héritent de facto des identifiants des surtypes : les attributs eid, mid, sid, cid, iid doivent donc disparaître...
J’observe en passant que l’attribut tid n’est pas rattaché à l’entité-type TYPE.
Pourriez-vous développer le scénario d’une création de compte ? Cela dit, ma question portait sur le cas où le moniteur Albert a donné un cours C1 à l’élève Raoul à la date D1 puis un cours C2, toujours à Raoul, à la date D2.
D’accord. A surveiller quand même, car je suppose que ceux qui viennent suivre un cours qu’ils ont déjà suivi ne sont pas la majorité...
(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.
Alors, pour créer un compte:
Eleve: Soit l'élève s'inscrit de lui même en remplissant un formulaire sur le site du moniteur en question. Soit le moniteur lui-même inscrit un de ses élèves. Cet élève va reste lié tout du long a ce moniteur, uniquement ce moniteur peut avoir accès a cet élève. Néanmoins si cet élève s'inscrit à un cours collectif, les moniteurs qui ont été annoncé dans le cours collectif doivent avoir accès à son nom et prénom (et c'est tout).
Moniteur: Uniquement la secrétaire peut créer un formulaire. Dans le système un fois la secrétaire identifié, elle aura accès à un formulaire permettant de créer un compte moniteur.
Secrétaire: C'est le même principe que pour moniteur, uniquement une secrétaire peut en créer une autre.
Effectivement c'est même extrêmement rare. Mais pas impossible
Bonsoir ale252,
D’accord pour le MCD, à la réserve près que j’ai déjà formulée : en l'état, l’élève Tryphon ne peut avoir qu’une seule fois le moniteur Fernand en cours individuel (cf. l’association « est lié »).
D’accord. Ça sera à l’application de garantir cette contrainte.
D’accord. Mais ça sera une fois encore à l’application de garantir cette contrainte.
Maintenant, y a plus qu’à...
Exemple d’amorce de brouillon de script avec MySQL :
USE test ; DROP TABLE IF EXISTS ELEVE ; DROP TABLE IF EXISTS MONITEUR ; DROP TABLE IF EXISTS SECRETAIRE ; DROP TABLE IF EXISTS UTILISATEUR ; CREATE TABLE UTILISATEUR ( uId INT NOT NULL , nom VARCHAR(32) NOT NULL , prenom VARCHAR(32) NOT NULL , login VARCHAR(32) NOT NULL , email VARCHAR(32) NOT NULL , CONSTRAINT UTILISATEUR_PK PRIMARY KEY (uId) , CONSTRAINT UTILISATEUR_AK1 UNIQUE (email) ) ; CREATE TABLE SECRETAIRE ( uId INT NOT NULL , CONSTRAINT SECRETAIRE_PK PRIMARY KEY (uId) , CONSTRAINT SECRETAIRE_UTILISATEUR_FK FOREIGN KEY (uId) REFERENCES UTILISATEUR (uId) ON DELETE CASCADE ) ; CREATE TABLE MONITEUR ( uId INT NOT NULL , uIdSecretaire INT NOT NULL , CONSTRAINT MONITEUR_PK PRIMARY KEY (uId) , CONSTRAINT MONITEUR_UTILISATEUR_FK FOREIGN KEY (uId) REFERENCES UTILISATEUR (uId) ON DELETE CASCADE , CONSTRAINT MONITEUR_SECRETAIRE_FK FOREIGN KEY (uIdSecretaire) REFERENCES SECRETAIRE (uId) ) ; CREATE TABLE ELEVE ( uId INT NOT NULL , telephone VARCHAR(24) NOT NULL , portable VARCHAR(24) NOT NULL , nationalite VARCHAR(32) NOT NULL , soldeDuCompte INT NOT NULL DEFAULT 0 , adresse VARCHAR(64) NOT NULL , dateDeNaissance DATE NOT NULL , uIdMoniteur INT NOT NULL , CONSTRAINT ELEVE_PK PRIMARY KEY (uId) , CONSTRAINT ELEVE_UTILISATEUR_FK FOREIGN KEY (uId) REFERENCES UTILISATEUR (uId) ON DELETE CASCADE , CONSTRAINT ELEVE_MONITEUR_FK FOREIGN KEY (UidMoniteur) REFERENCES MONITEUR (uId) ) ; INSERT INTO UTILISATEUR (uId, nom, prenom, login, email) VALUES (1, 'Castafiore', 'Bianca', 'casta', 'casta.bianca@chose.fr') , (11, 'Naudin', 'Fernand', 'naufer', 'fernand@truc.fr') , (12, 'Volfoni', 'Raoul', 'raoul', 'raoul@truc.fr') , (13, 'Volfoni', 'Paul', 'paulo', 'paulvolf@truc.fr') , (21, 'Tournesol', 'Tryphon', 'prof', 'tryphon@truc.fr') , (22, 'Lampion', 'Séraphin', 'thelamp', 's.lamp@machin.fr') , (23, 'Halambique', 'Nestor', 'totor', 'nestor@machin.fr') ; INSERT INTO SECRETAIRE (uId) VALUES (1) ; INSERT INTO MONITEUR (uId, uIdSecretaire) VALUES (11, 1), (12, 1), (13, 1) ; INSERT INTO ELEVE (uId, telephone, portable, nationalite, adresse, dateDeNaissance, UidMoniteur) VALUES (21, '0123456789', '0678901234', 'be', '3 rue Martin', '1997-07-14', 11) , (22, '0123456780', '0678901235', 'be', '13 place de Moulinsart', '1997-04-01', 11) , (23, '0123456781', '0678901236', 'be', '1 place de Moulinsart', '1996-01-01', 12) ; Etc.
(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.
Bonjour,
Voici mon modèle relationnel, j'ai quelques doutes concernant sa justesse:
Login: La table login doit être créé à part? Au final juste un attribut login et un autre password devrait suffire non?
Pour la spécialisation/generalisation, on implémente comment les tables? Je suppose que tous ont le id qui s'appelle la même chose?
Concernant adresse par exemple, me faut-il une table pour adresse une autre pour code postal, une autre pour adresse, etc?
La date de naissance de même, j'aurais besoin d'une table date de naissance, ou un simple attribut de type datetime suffit?
J'ai pas vraiment compris la différence entre la ligne continue et non continue, relation identifié et non identifié?
Je crois aussi que j'ai un bon mélange entre les fk et les pk...
Merci
Bonne soirée
Bonsoir ale252,
Si chaque utilisateur a au moins un et au plus un login (et un password), alors il n’y a pas lieu de créer de table LOGIN (reportez vous au script SQL que j’ai fourni dans mon message précédent : l’attribut Login fait partie de l’en-tête de la table UTILISATEUR et c'est tout). Par contre, si seuls certains utilisateurs on un login, alors cette table doit exister, sinon le bonhomme Null va se manifester et faire patiner l’algèbre relationnelle du fait de sa logique à trois états (vrai, faux, peut-être).
Je subodore que Lucidchart est dans le coup... En effet, vous avez un objet login contenant deux objets, login et password :
Partant de là, Lucidchart n’a-t-il pas pondu une table LOGIN a deux attributs, login et password (outre un éventuel attribut identifiant, du genre idLogin) ? Ponte que vous auriez recopiée à l’identique dans le diagramme MySQL Workbench ?
Que se passe-t-il si vous modifiez votre diagramme ainsi :
Non, à moins que certains élèves puissent ne pas avoir d’adresse ou puissent en avoir plus d’une, sinon si un élève a exactement une adresse, ni plus, ni moins, alors la table UTILISATEUR convient. On est manifestement dans un contexte identique au précédent...
Un attribut de type Date suffit (cf. le script de mon message précédent). Là encore, on est manifestement dans un contexte identique à celui du login...
J’ai l’impression que vous n’êtes pas passé par la case MySQL Workbench...
Prenons l’exemple simple des lignes de commande. Supposons qu’on ait le modèle conceptuel suivant (n’ayant pas Lucidchart, j’utilise ici l’AGL DB-MAIN) :
Selon ce diagramme :
— Un client peut passer plusieurs commandes, et une commande est passée par un seul client ;
— Une commande contient au moins une ligne de commande et une ligne de commande appartient à exactement une commande ;
— Un produit entre dans la composition d’au moins une ligne de commande et une ligne de commande comporte exactement un produit.
A noter en particulier l’identification des entités-types :
L’entité-type CLIENT est identifiée au moyen de d’attribut ClientId. Elle possède un identifiant alternatif {ClientNoSiret}, garantissant l’unicité des Sirets : en effet, deux clients distincts ne peuvent pas avoir le même Siret.
L’entité-type COMMANDE n’est pas identifiée au moyen du seul attribut CommandeId, mais de la paire {PASSER.CLIENT, CommandeId}, ce qui sous-entend qu’elle a pour identifiant la paire {ClientId, CommandeId}, en conséquence de quoi, au niveau tabulaire la clé primaire de la table COMMANDE sera la paire {ClientId, CommandeId}. Elle possède un identifiant alternatif {CommandeNumero}, garantissant l’unicité des numéros de commande : en effet, deux commandes distinctes ne peuvent pas avoir le même numéro.
Au stade tabulaire, le diagramme devient le suivant :
Au format MySQL Workbench :
L’association entre les tables CLIENT et COMMANDE est représentée par un trait continu, ce qui traduit le fait que la table COMMANDE est identifiée relativement à la table CLIENT, ce qui veut dire qu’elle a pour clé primaire non pas le singleton {CommandeId}, mais la paire {ClientId, CommandeId}. L’attribut ClientId de la table COMMANDE est accompagné d’une clé de couleur rougeâtre, ce qui veut dire que cet attribut, non seulement entre dans la composition de la clé primaire de COMMANDE, mais est aussi l’objet de la contrainte référentielle {ClientId}, voulant que chaque commande fasse obligatoirement référence à un client présent dans la table CLIENT (pas d’orphelins ! Toute commande fait référence à un client !) On dit encore que le singleton {ClientId} de la table COMMANDE est clé étrangère par rapport à la clé primaire {ClientId} de la table CLIENT (mais attention, en l’occurrence le terme « clé » ne signifie pas unicité : un client peut passer plus d’une commande...)
Exemple de contenu correspondant pour la table COMMANDE :
On voit ici que la valeur de l’attribut CommandeId commence à 1 pour chaque client. Conceptuellement, il n’y a pas d’avantage particulier, mais au niveau physique on s’y retrouve : gain d’un index, regroupement des commandes d’un client donné dans une même page, et les DBA sont d’accord sur ce point.ClientId CommandeId CommandeNumero CommandeDate CommandeMontant -------- ---------- -------------- ------------ --------------- 1 1 2015_00056 2015-01-15 123,45 1 2 2015_00089 2015-01-26 456,78 1 3 2015_00457 2015-03-11 1500,02 2 1 2015_00021 2015-01-07 458,12 2 2 2015_00074 2015-01-19 821,90 3 1 2015_00057 2015-01-15 502,56 3 2 2015_00545 2015-04-07 300,15 3 3 2015_00712 2015-04-30 1428,17 3 4 2015_00715 2015-04-30 987,00 ... ... ... ... ...
L’association entre les tables COMMANDE et LIGNE_COMMANDE est représentée elle aussi par un trait continu, ce qui traduit le fait que la table LIGNE_COMMANDE est identifiée relativement à la table COMMANDE, ce qui veut dire qu’elle a pour clé primaire non pas le singleton {LigneCommandeId}, mais le triplet {ClientId, CommandeId, LigneCommandeId}. Les attributs ClientId et CommandeId de la table LIGNE_COMMANDE sont accompagnés d’une clé de couleur rougeâtre, ce qui veut dire que ces attributs, non seulement entrent dans la composition de la clé primaire de LIGNE_COMMANDE, mais sont aussi l’objet de la contrainte référentielle {ClientId, CommandeId}, voulant que chaque ligne de commande fasse obligatoirement référence à une commande présente dans la table COMMANDE. La paire {ClientId, CommandeId} de la table LIGNE_COMMANDE est clé étrangère par rapport à la clé primaire {ClientId, CommandeId} de la table COMMANDE (mais attention une fois de plus, le terme « clé » ne signifie pas unicité : une commande peut comporter plusieurs lignes...)
La valeur de l’attribut LigneCommandeId commence à 1 pour chaque commande. Conceptuellement, comme précédemment il n’y a pas d’avantage particulier, mais au niveau relationnel on pourra faire ressortir que la ligne de commande n’est qu’une propriété multivaluée d’une commande : au-delà du côté purement structure, « anatomique » du diagramme conceptuel, on injectera du métabolisme (clause CASCADE adjointe à la contrainte référentielle, signifiant que si l’on supprime une commande, alors ses lignes sont supprimées elles aussi). Là encore on s’y retrouve au niveau physique, gain d’un index, regroupement des lignes de commande d’une commande donnée (donc d’un client donné) dans une même page, et côté manipulation, on diminue le nombre de jointures, quand par exemple on cherche le données du client pour telle ligne de commande. Un bon exemple à ce propos : voir le 4eme exemple de Dénormalisation vs amélioration (optimisation).
L’association entre les tables PRODUIT et LIGNE_COMMANDE est représentée par un trait en pointillés, ce qui traduit le fait que la table LIGNE_COMMANDE se contente de faire référence à la table PRODUIT. L’attribut ProduitId de la table LIGNE_COMMANDE est accompagné d’un losange de couleur rougeâtre, ce qui veut dire que cet attribut n’entre pas dans la composition de la clé primaire de LIGNE_COMMANDE, mais fait toutefois l’objet de la contrainte référentielle {ProduitId}, voulant que chaque commande fasse obligatoirement référence à un produit présent dans la table PRODUIT (une fois de plus, pas d’orphelins ! Pas de référence à des produits inexistants !) Le singleton {ProduitId} de la table LIGNE_COMMANDE est clé étrangère par rapport à la clé primaire {ProduitId} de la table PRODUIT.
Exemple de contenu correspondant pour la table LIGNE_COMMANDE :
ClientId CommandeId LigneCommandeId ProduitId LigneCommandeQuantite -------- ---------- --------------- ---------- -------------------- 1 1 1 4012 25 1 1 2 0017 20 1 1 3 5471 17 1 1 4 7850 42 1 2 1 7121 10 1 2 2 4012 20 1 2 3 0004 50 1 3 1 0017 40 1 3 2 0058 12 1 3 3 7121 28 2 1 1 0283 30 2 1 2 5471 29 ... ... ... ... ...
En entité-association, on spécialise les entités-types. Côté SQL : la norme SQL permet l’héritage entre tables, mais selon une approche qui n’apporte rien (cf. pages 822-884 de An Introduction to Database Systems Eighth Edition de C.J. Date), et les SGBD que je connais n’offrent pas cette possibilité. Il est un fait que, comme ci-dessous, on se débrouille très bien sans cette fonctionnalité décrite dans la norme, mais qui est vraiment sans intérêt avec SQL.
En vous reportant au script SQL que j’ai fourni dans mon message précédent, vous constaterez qu’il correspond diagramme suivant :
Diagramme ainsi complété pour tenir compte des associations entre SECRETAIRE et MONITEUR d’une part, MONITEUR et ELEVE d’autre part (conformément au script SQL) :
Les traits symbolisant ces associations sont en pointillés, ce qui veut dire qu’un moniteur n’est pas identifié relativement à une secrétaire, il n’est pas la propriété de celle-ci, il fait seulement référence dans le cadre de la gestion des moniteurs... De même, un élève n’est pas la propriété d’un moniteur, à moins, par exemple, que la suppression d’un moniteur ait pour effet la suppression de ses élèves...
Certes !
Selon votre diagramme, la table UTILISATEUR a pour clé primaire le quadruplet {uId, Moniteur_uId, Secretaire_uId, Eleve_uId}, alors que cette clé doit se résumer singleton {uId}...
En outre, cette table possède 3 clés étrangères : {Moniteur_uId}, {Secretaire_uId}, {Eleve_uId}, faisant respectivement référence aux tables MONITEUR, SECRETAIRE, ELEVE : un utilisateur est donc nécessairement à la fois moniteur, secrétaire et élève... c’est carrément le monde à l’envers, et à l’instar de Dagobert il va falloir remettre tout ça à l’endroit
En passant, n'hésitez pas à voter pour les messages qui ont pu vous aider...
(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.
Merci pour cette belle explication.
J'ai lu le tutoriel, et j'essai de comprendre, je vais y aller par étapes.
J'ai essayé de faire la généralisation de l'utilisateur:
Mais je n'y arrive pas, je m'explique:
Si je clique sur un lien 1-1 avec la ligne continue, et que je ne met pas de id sur la table élève par exemple, aucune relation n'est créé. Si je laisse l'id, alors une nouvelle clé est créé dans la table utilisateur comme précédemment et si je la supprime, ça me supprime aussi la relation.
Qu'est-ce que je fais pas juste?
Bonsoir,
Après tout, j'ai compris mon erreur:
Il fallait cliqué d'abord sur élève et ensuite sur utilisateur. J'ai pu ainsi faire de même avec toutes les autres relations et ça a fonctionné a merveille.
Concernant le login, je me demande s'il est possible de laisser ainsi, si par exemple dans un futur on fait une extension a la sécurité, et on veut enregistrer les vieux mot de passe, ou quelque chose du genre? Ca pose problème de laisser ainsi?
Concernant l'adresse, je vais mettre une liste de pays de de code postaux directement dans la base de donnée, l'utilisateur devra cliquer sur un des code deja existants dans la base de donnée, du coup des tables sont nécessaire non?
Pour le reste les liaisons et le fk, pk semblent juste non?
Concernant le moniteur, en effaçant un moniteur on efface forcément tous ses élèves, par conséquent, il faut une liaison identifié non?
Il vaut mieux utiliser un type date plutôt que datetime si je comprend bien?
Merci encore
Salutations
Bonsoir ale252,
Bingo !
A propos de l’attribut DateDerniereConnexion :
Cet attribut est a priori instable, c'est-à-dire plus souvent mis à jour que les autres attributs de la table UTILISATEUR, or plus une table au cœur du système telle que celle-ci est chahutée, moins la base de données se porte bien...
Il serait donc opportun d’anticiper et mettre en œuvre une table ad-hoc :
L’attribut uId de la table DERNIERE_CONNEXION est utilisé à la fois pour la clé primaire {uId} de la table et pour la clé étrangère {uId} faisant référence à la clé primaire {uId} de la table UTILISATEUR. Notez l’emploi que je fais des accolades, car une clé primaire ou étrangère est un ensemble (au sens de la théorie des ensembles) dont les éléments sont les noms des attributs appartenant à l’en-tête d’une table (en-tête qui est lui-même un ensemble, l’ensemble des noms des attributs de la table).
J’ai renommé DateDerniereConnexion en HorodatageConnexion, car je pense qu’il n’est pas mal d’avoir le moment de la connexion en plus de la date de celle-ci : en l’occurrence, cet attribut est du type TIMESTAMP. Cela dit, c’est à vous de juger si ce changement de type convient.
La mise en œuvre d’une table LOGIN ne pose aucun problème, mais elle ne doit servir que pour historiser ce qui n’est plus d’actualité. Ainsi, vous conservez dans la table UTILISATEUR le login et le mot de passe en cours d’activité. Maintenant, si vous historisez les logins et mots de passe, vous pourrez mettre en place un système comme celui-ci :
Les attributs HorodatageLogin et HorodatagePassword sont du type TIMESTAMP. Un utilisateur a la possibilité de changer plus d’une fois de login ou de mot de passe. Ainsi la table LOGIN_HISTO a pour clé primaire la paire {uId, HorodatageLogin} et pour clé étrangère le singleton {uId} référençant la clé primaire {uId} de la table UTILISATEUR. Même principe en ce qui concerne la table PASSWORD_HISTO. A toutes fins utiles, vous pouvez consulter la partie que je consacre à l’historisation des données.
A propos de l’effet Dagobert...
Dans votre diagramme, le singleton {Login_id} de la table UTILISATEUR est clé étrangère par rapport à la clé primaire {idLogin} de la table LOGIN, ce qui revient à dire qu’un login a un utilisateur, alors que, sémantiquement parlant, c’est l’inverse : un utilisateur a un login...
Par ailleurs, le trait symbolisant l’association entre UTILISATEUR et LOGIN est en pointillés, ce qui veut dire qu’un utilisateur n’est pas la propriété d’un login, ce qui à nouveau est vrai, sémantiquement parlant. Mais attention aux cardinalités : vous signifiez qu’un utilisateur n’est pas toujours associé à un login, ce qui est pour le moins suspicieux...
Bref, il faut remettre les choses à l’endroit : un utilisateur a toujours un login en cours d’activité (et éventuellement un historique de logins passés, comme dans la représentation que j’en ai fait plus haut), et celui-ci doit regagner le bercail.
L’effet Dagobert vaut pour l’association entre TYPE et PERMIS, car selon ce que vous avez modélisé, un permis peut être de plusieurs types, tandis qu’un type peut être associé à au plus un permis...
Même chose pour l’association entre TYPE et MONITEUR.
Si vous souhaitez assurer l’intégrité des valeurs pour les pays et les codes postaux, Il faudra effectivement une table PAYS et une table CODE_POSTAL. Pour le reste les tables ADRESSE_COMPLETE et ADRESSE ne se justifient pas et leurs attributs devraient réintégrer la table ELEVE.
Oui. Mais attention à l’effet en cascade de la suppression. Par exemple, si un élève n’a pas payé ses cours, la suppression sera refusée, parce qu’il n’y aura pas de cascade entre les tables ELEVE et ELEVE_has_COURS (tant qu’à faire !)
Qui plus est, si un moniteur disparaît, il faudra le faire disparaître aussi en tant qu’utilisateur, même chose pour les élèves et les secrétaires... On verra cela au stade SQL.
Divers :
Vous avez souvent des losanges « blancs » accompagnant les noms des attributs : il va falloir qu’ils deviennent tous bleus ! (ou rougeâtres pour les clés étrangères).
Il serait préférable de renommer certaines tables :
COLLECTIF_has_MONITEUR en COLLECTIF_MONITEUR,
ELEVE_has_COURS en ELEVE_COURS,
PERMIS_has_ELEVE en PERMIS_ELEVE.
Association MONITEUR – SECRETAIRE : vous avez modélisé une cardinalité 0,1, alors qu’elle doit être 1,1 car tous les moniteurs font l’objet d’une gestion par une secrétaire. Ce remplacement de 0,1 par 1,1 vaut pour d’autres associations :
ELEVE – ADRESSE_COMPLETE
ADRESSE_COMPLETE – CODE_POSTAL
ADRESSE_COMPLETE – PAYS
ADRESSE_COMPLETE – ADRESSE
A ceci près que les tables ADRESSE_COMPLETE et ADRESSE devraient être absorbées par la table ELEVE, comme je l'ai évoqué précédemment.
Lien d’activation : vous avez établi une bijection entre les tables ELEVE et LIEN_ACTIVATION : la 2e devrait être absorbée par la 1re.
(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.
Login: c'est par rapport a la spécification du programme. Un moniteur peut créer un eleve, celui-ci revevra un mail dans lequel il y aura un lien qui lui permettra de creer lui-même un login et un mot de passe. C'est pourquoi je met la possibilité de ne pas avoir de login
TYPE et PERMIS: un type de cours peut ne pas avoir un permis. Les cours vont être utilisé pour créer des événements dans l'agenda. Un événement privé par exemple n'aura pas de permis.
TYPE et MONITEUR: le moniteur au départ n'a encore créé aucun type, d'ou le fait qu'il puisse avoir 0 types
Concernant les losages blancs, cela veut dire qu'il peuvent être null non? Un élève peut par exemple ne pas avoir de téléphone ou de nationalité non?
j'ai pas vraiment compris ce que vous entendez par là?
Bonsoir ale252,
Selon votre modélisation, il y a une relation fonctionnelle entre ELEVE et LIEN_ACTIVATION, telle qu’à chaque élève correspond exactement un lien d’activation et à chaque lien d’activation correspond exactement un élève. Autrement dit, il n’y a pas de lien d’activation correspondant à l’élève Raoul s’il n’y a pas d’élève Raoul, et il n’y a pas d’élève Raoul s’il n’y a pas de lien d’activation pour lui. C’est ce qu’expriment les cardinalités de votre diagramme :
Mais si l’élève Raoul existe, et s’il est possible qu’il n’y ait pas de lien d’activation pour lui, alors la règle de gestion devient : à chaque élève correspond 0 ou 1 un lien d’activation, et à chaque lien d’activation correspond exactement un élève.
Conformément à votre propre modèle, on a par exemple les valeurs suivantes (l’attribut uId est du type numérique, mais pour faciliter la lecture, j’ai utilisé le prénom des élèves) :
Table ELEVE
uId idLienActivation --------- ---------------- Raoul 171 Fernand 259 Paul 172 Antoine 304 Patricia 305
Table LIEN_ACTIVATION
idLienActivation cle expirationDate ---------------- ------------ -------------- 171 ABCEDEFGHIJK 2015-02-25 172 null null 259 ZYXWVUTSRQPO 2015-07-14 304 null null 305 AZERTYUIOPQR 2015-03-01
Mais pour Paul et Antoine, on n’a pas encore de clé d’activation, d’où l’apparition du bonhomme Null, interdit de séjour dans les bases de données conformes au modèle relationnel de données.
Pour être conforme, on renverse la vapeur : si l’attribut idLienActivation appartient à la clé primaire {idLienActivation} de la table LIEN_ACTIVATION, alors il appartient aussi à la clé étrangère {idLienActivation} faisant référence à la clé primaire {uId} de la table ELEVE :
Table LIEN_ACTIVATION
La modélisation devient la suivante, dans laquelle les losanges bleuissent, car si un lien d’activation existe c’est que la clé et la date d’activation existent ! On a remplacé une bijection par une injection : chaque cle d’activation appartient à un et un seul élève, et un élève possède 0 ou 1 clé.idLienActivation cle expirationDate ---------------- ------------ -------------- Raoul ABCEDEFGHIJK 2015-02-25 Fernand ZYXWVUTSRQPO 2015-07-14 Patricia AZERTYUIOPQR 2015-03-01
N.B. Vous pouvez renommer IdLienActivation en uId ou conserver ce nom, peu importe. Toujours pour des raisons de lisibilité, au lieu d’utiliser des valeurs numériques, j’ai conservé les noms des élèves pour cet attribut dans les exemples.
La règle de gestion est donc la suivante : un utilisateur a de 0 à 1 login ; un login a toujours au moins un et au plus un login. On retrouve le principe de l’injection évoqué ci-dessus. La table LOGIN ne contient que les logins des utilisateurs qui en sont munis. Là encore, les attributs Login et Password prennent la couleur des bleuets :
Les liens entre les tables ELEVE et CODE_POSTAL ainsi que PAYS sont à revoir...
Par exemple, dans votre modèle, selon les cardinalités de l’association entre ELEVE et CODE_POSTAL, un code postal fait référence à un et un seul élève. En outre, le bonhomme Null continue à sévir :
La modélisation doit devenir :
Souvenez-vous de ce que j’ai proposé dans mon message précédent pour la dernière connexion :
Alors que vous avez modélisé une bijection avec présence du bonhomme Null :
Si un élève peut ne pas avoir de téléphone, soit vous vous inspirez de ce que j’ai proposé pour le login ou le lien de connexion (mise en oeuvre d’une table TELEPHONE), soit, puisque l’attribut téléphone est du type VARCHAR, si Raoul n’a pas de téléphone, vous lui affecterez la valeur '' (chaîne de caractères de longueur égale à 0, donc Not Null).
Je regarderai la suite de votre modèle un peu plus tard.
(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.
Bonsoir,
Voilà mon nouveau modèle corrigé, je crois avoir compris un certains nombre de chose.
Pour code postal par exemple, un élève n'est pas obligé d'avoir renseigné le code postal, hors comme je l'ai modélisé là, c'est obligatoire, sinon il prendra une valeur null, vous savez ce que je peux y faire? De même pour pays.
Concernant permis_id dans l'entité TYPE, elle peut contenir ou non un permis, du coup la valeur peut encore une fois contenir un null?
Si je comprend bien, pour l'entité eleve qui a beaucoup d'attribut pouvant etre null, on est obligé de créer une nouvelle table pour chaque attribut non?
Merci
Bonne soirée
Bonsoir ale252,
D’accord. Si donc un élève peut ne pas fournir son code postal, on va modifier la modélisation ainsi :
C'est-à-dire qu’on met en œuvre une table ELEVE_CODE_POSTAL dans laquelle ne figureront que les uId des élèves ayant fourni un code postal.
En théorie, oui... Mais comme je l’ai écrit dans mon précédent message, si Raoul n’a pas de téléphone, vous lui affecterez la valeur '' (chaîne de caractères de longueur égale à 0, donc Not Null). Vous n’êtes donc pas obligé de créer une table des téléphones des élèves.
Prenons l’exemple de Fernand qui a le téléphone et de Raoul qui n’en a pas :
Table ELEVE :
Et l’attribut telephone est « not null », donc le losange qui l’accompagne devient bleu.uId telephone 'Fernand' '0123456789' 'Raoul' ''
Ceci vaut pour les autres attributs « nullables ».
A propos de l’attribut numeroRue : vous avez défini cet attribut comme étant numérique. Pour ma part je serais prudent et basculerais à VARCHAR, car il peut exister des numéros tels que « 132 bis », « 132 ter », « 132 quater »...
Dans votre dernier diagramme, la table UTILISATEUR contient toujours les attributs login et password : ce sont des scories à supprimer.
Jamais de Null pour une clé étrangère. On va faire comme pour le code postal :
(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.
Parfait.
Merci beaucoup pour votre aide, je suppose que mon modèle est à peu près valide cette fois! J'ai vraiment appris beaucoup de choses avec votre aide!
Voilà la version corrigée
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