Construction projet (Modèle entité-association)

Bonjour à tous

Je suis actuellement en train d'essayer de modéliser un projet, mais bon, comme tout débutant, j'ai quelques difficultés...

Voici le schéma global de modélisation : http://gevona.chatoz-corp.org/diagramme.jpg

Bien entendu, ce n'est qu'un premier essai, très simpliste, mais qui me bloque déjà !

Par exemple, si je prend la relation entre coureur et école, j'ai quelque chose de ce genre là :

---|---|---|---|---| ---|---|---|---|-- -|---|---|---|---|---|---|--

| Ecole | / Etudie \ | Coureur |

|---|---|---|---|--| ---|-- 1,N ---|---| ---|---|---|---|---|---|---| ---|--1,1 ---|---|- |---|---|---|---|---|---|--|

| idecole | \ / | idcoureur |

---|---|---|---|---|- --|---|---|---|---|- --|---|---|---|---|---|---|-

En ffait, mon problème est tout simple, je ne sais pas faire en pratique des relations 1,N. Quelle démarche doit-on suivre pour que plusieurs coureurs étudient dans une école ?

Après, si en plus d'une réponse, vous avez des conseils sur la schématisation, je suis preneur !

Merci à tous

Yann

PS pour ceux qui ont regardé le diagramme : j'ai bidouillé par exemple entre utilisateur et structure. J'ai créer un champ "groupe" dans la table utilisateur pour récupérer un des 8 huits groupes de la structure. Je suis bloqué par exemple si un même utilisateur doit gérer deux groupes. J'ai donc défini des champs droitgroupe_n pour définir les droits d'accès aux paramètres d'un groupe pour tous les utilisateurs.

Salut,

ton problème vient de ce que tu n'as peut-être pas utilisé les bonnes cardinalités entre les entités « Utilisateur» et « Structure ». J'ajoute que tu auras un problème si tu dois ajouter ou retirer un groupe de ta structure : il y a des redondances et il me semblerait plus approprié d'avoir une entité groupe avec un identifiant et un libellé, puis une relation entre « Structure » et « Groupe ». Mais en relisant ta description, je me dis que cette entité « Groupe doit non seulement être indépendante de la structure mais en plus participer à la relation entre « Utilisateur » et « Structure ».

Ça nous donnerait le modèle conceptuel suivant :

+-------------+                           +-----------+
| utilisateur |             ________      | structure |
+-------------+            / etudie \     +-----------+
| uti_id      |--- 1:N -------------------| str_id    |
+-------------+            \________/     +-----------+
                                |
                                |
                           +--------+
                           | groupe |
                           +--------+
                           | grp_id |
                           +--------+

Nous avons là une relation « à trois pattes » (J'ai horreur de ça)

En modèle physique, la relation devient alors une table comportant une clé-primaire composite comme ceci :

+------------------+
| etudie           |
+-------------+----+
| uti_id      | PK |
| str_id      | PK |
| grp_id      | PK |
+-------------+----+

La combinaison des trois clé étrangères forme une clé primaire. De cette manière :

1. Un utilisateur peut appartenir à 1 ou n groupe et être rattaché à 1 ou n structures;
2. Tu peux ajouter autant de groupes que nécessaire au fil de la vie de ton application;
3. Une structure peut comporter 1 à n groupes et 1 à n utilisateurs;
4. Comme on a affaire à une clé primaire, un utilisateur qui appartient à un groupe précis dans une structure précise ne peut être identifié de la sorte qu'une seule et unique fois ou ne pas être du tout : pas de doublons. Si une notion de date peut avoir une importance, alors cette information peut s'y retrouver et faire accessoirement partie de la clé primaire, permettant les doublons sur le groupe des trois autres clés.

Est-ce que ça répond à ta question ?

C'est génial bien que complexe quand on commence ce genre de modélisation. Je crois que j'ai compris et je vais essayer d'avancer avec ces infos. Ca ne te dérange pas si je poste mes évolutions ici, cher mentor ?!

Question qui n'a rien à voir au passage : j'ai du mal à bien cerner quand on doit utiliser " " ou ' '.

Merci et à bientôt

Bon, j'ai essayé d'avancer, pas le droit de sourire en voyant le diagramme logique !

http://gevona.chatoz-corp.org/diaglogique.jpg

Pour voir si j'ai bien compris, je te propose de regarder les connexions en rouge (utilisateurs / navigation / coureurs). Pour moi, comme lors d'une navigation, il peut y avoir plusieurs coureurs, il faut passer par une table mysql spécifique pour gérer cette partie.

J'ai donc créer une table suivinav qui a un clé primaire composite avec date, user_id, coureur_id :

http://gevona.chatoz-corp.org/diagphysique.jpg

Dans le fichier, il y a aussi suivinav_id, mais après réflexion, je crois que cela ne sert à rien.

Bon, j'espère que je ne me suis pas trop égaré, en tout cas, c'est passionant !

A bientôt

Salut

bon, je ne sais pas quel outil de modélisation tu utilises, ça ressemble à du PowerAMC mais le look aurait changé depuis les versions que je connaissais.

En tout état de cause, le processus de modélisation vers la structure du schéma de donnée passe successivement par :

1. Le dictionnaire de données
2. Le modèle Conceptuel de données (MCD);
3. Le Modèle Physique de Données (MPD)

Je me demande si tu n'as pas court-circuité la première étape. Pourant, c'est là qu'on va identifier toutes les entités et les propriétés de ces entités. Ensuite, dans le modèle conceptuel, on va définir les cardinalités entre les entités : telle entité peut être liée x à y fois à telle autre entité.

Là, je dois dire que ton modèle me donne un peu le tournis ;) Cela dit, je sais que c'est facile d'en parler savamment, c'est une autre paire de manche d'en assimiler les concepts et les subtilités.

Sur la relation que tu as soulignée de rouge : On va commencer par le commencement, tu as des redondances dans ton système : l'utilisateur a un nom, un prénom, une adresse etc... et le coureur a un nom, un prénom, une adresse, etc... (ça fait pas « tilt ! » là ;) ?) Tu as attribué en propriété de certaines entités des propriétés qui appartiennent à une autre entité non identifiée. Les adresses par exemple, ça peut être une entité à part. Tu éviterais les doublons d'adresses (dans un immeuble, il y a plusieurs résidants, pourtant, c'est la même adresse : si j'ai 30 résidant, dois-je doublonner trente fois l'adresse ou limiter à une clé étrangère sur une unique ligne indiquant cette adresse ? Et là je parle juste de 30... imagine si ton système grossit assez pour contenir 300 000 utilisateurs... gloups!...

Ensuite, le lien entre la structure et l'utilisateur : elle est double : d'une part on a une relation directe, d'autre part on a une relation qui transite par les groupes.... ça va être coton à gérer ton truc.... Si tu utilises bien PowerAMC, tu dois avoir un outil de validation inclus, exécute-le, je serais fort surpris qu'il ne te parle pas de « relations circulaires (invalides) » En fait, je dirais ceci : tu as noté la relation « Groupe -> gère -> Utilisateur » : le groupe ne gère riendu tout, c'est la structure qui gère à la fois des groupes et des utilisateurs, mais un utilisateur va appartenir à 1 et un seul groupe, ou encore à 1 à n groupes selon le cas, de toutes façons, un groupe comportera 0 à n utilisateurs.

Ensuite, regarde ceci : tu disposes de cinq chemins différents pour relier une structure à un coureur :

1. Directe : adhère;
2. via le groupe;
3. via l'utilisateur
4. via l'utilisateur puis le groupe;
5. via l'utilisateur puis la navigation.....

Ça fait beaucoup, tu ne trouves pas ? Il y a une hiérarchie dans les choses et tu as quelques entités non identifiées dans ton modèle, essaye de repenser de façon globale, tente de ralentir le rythme cérébral pour isoler une forme d'arborescence entre les éléments afin d'identifier les éléments eux-même.

Salut,

Merci pour ces éléments de réponses. Quand tu débutes, ce qui est dur, c'est le manque de vocabulaire. Tu te débats avec des recherches du style "conception base de données" qui renvoient certes des résultats, mais beaucoup moins intéressants que de faire des recherches sur "dictionnaire de données", "mcd" ou "mpd". Du coup, non seulement ton post m'éclaire un peu, mais il me permet aussi d'avoir accès à plein d'autres informations. Je vais essayer d'ingurgiter tout ça, le digérer, et je reviendrais avec une construction plus mure, enfin, je l'espère !

A bientôt

Re salut

Bon, je crois que je commence à piger un peu. Si j'ai tout compris :

- Le dictionnaire de données permet de voir toutes les données que l'on va devoir gérer et, par ce biais, on va pouvoir détecter plus facilement les redondances. C'est ça ?

Pour mon cas, j'ai décidé de ne pas séparer les adresses car je risque de ne pas avoir beaucoup de redondance vu que les personnes étant sur ce système ont quasiment tous des maisons individuelles et que je n'aurais pas non plus 10 000 individus, même dans 10 ans ! Par contre, pour la forme, j'ai essayé d'isoler code postal et ville. Pareil, j'ai essayé de définir une entité individu de laquelle découle les parents, les utilisateurs, et les coureurs.

**- Une fois le dictionnaire fait, il faut créer son modèle conceptuelle. Là, on va s'attacher à comprendre les liens etre les différentes table, et comprendre les différents types de relations qu'on peut avoir. C'est ça ? **

Du coup, j'ai refait un essai en changeant de logiciel : http://gevona.chatoz-corp.org/diaglogique.png

J'ai au moins deux choses qui me tracassent :

• La relation "a des parents". Ca me fait bizarre comme ça mais je trouve que c'est une solution correcte. Par contre je ne pense pas faire une table pour ça, mais plutôt un id_pere et un id_mere dans l'entité "coureur".

• La chaine de relation "organise", "évolue" puis navigue". Je me dis que ça fait beaucoup de jointures à faire, et qu'il vaudrait peut être mieux faire une entité qui regroupe saison et groupe.

- Une fois le modèle conceptuel réalisée, on passe au modèle physique. Là, on réfléchit sur la transformation des relations en table. C'est ça ?

Par exemple, pour la relation "habite", on doit choisir si on rajoute un id_ville dans les tables "école", "individu"et "structure" ou si on fait une table avec id_ville, id_structure, id_individu et id_ecole. Moi, j'aurais envie de rajouté un id_ville partout, mais comme j'ai envie de faire ça, je me dis que ça ne doit pas être la bonne solution xD !

J'ai hâte de vous lire (enfin, te lire, car je ne doute pas que c'est Cyrano qui risque de répondre !)

Salut Yannours,

effectivement, c'est moi qui réponds ;)

Pour le dictionnaire, tu en as parfaitement saisi le sens, c'est parfait. La suite est peut-être moins heureuse, mais je vais tenter d'éclairer un peu ta lanterne.

En phase de modélisation, il ne faut pas réfléchir en termes de tables et de colonnes, il faut penser "Entités", "propriétés de ces mêmes entités" et "relations entre les différentes entités". Le volume final de la base de données n'a pas vraiment d'importance, en fait, je devrais dire qu'il n'en aura pas moins d'importance parce que tu ne manipuleras pas des tera-octets de données. Donc ton observation quant aux adresse part d'une erreur d'analyse : ce sont les relations qui définiront au final les tables/colonnes, donc au niveau du modèle conceptuel, ne te préoccupes pas des tables. Tu as un certain nombre de données identifiées grâce à ton dictionnaire de données. Reste donc à déterminer les relations entre chacunes de ces données : si la relation entre une donnée X et une données Y sera toujours de 1:1/1:1, alors c'est que l'une est en fin de compte un propriété de l'autre ou encore que ce sont deux propriétés d'une même entité. S'il y a différence entre les cardinalités (partie x:y d'un coté et x:y de l'autre), alors les deux données sont probablement des entités différentes ou des propriétés d'entités différentes.

Je vais prendre un exemple qui m'a servi pour créer un tuto sur les jointures basiques en SQL sur PHPFrance : suppose que tu veuilles construire un petit annuaire, tes données sont : personnes, noms, prénoms, numéro de téléphone et type de téléphone (fixe, gsm, fax). Si tu définis qu'un nom et une personne sont liées, tu as un point de départ, maintenant, est-ce qu'une personne peut avoir plusieurs noms ? À priori non, c'est illogique. Même chose pour le prénom. Maintenant dans l'autre sens, on pourrait logiquement dire qu'un même prénom peut être utilisé par plusieurs personnes. Là, je pousse un peu et on ira pas à ce niveau de découpage qui ne présente en outre qu'assez peu d'intérêt. Par contre au niveau du téléphone, on fait face à une problématique différente : une personne peut avoir de 1 à n numéros de différents types, et dans l'autre sens, on peut dire qu'un téléphone n'appartient qu'à une et une seule personne. Je peux donc partir de deux entités distinctes, personnes et téléphones, puis les propriétés de ces entités sont nom et prénom pour l'entité Personne et numéro et type pour l'entité Téléphone. Si tu ajoutes l'adresse maintenant : même en admettant que beaucoup de personnes vivent dans des maisons individuelles, il y en a encore plus qui vivent dans des immeubles, or la caractéristique d'un immeuble, c'est qu'il n'a qu'une seule et unique adresse pour l'ensemble des logements qu'il comporte. On peut donc logiquement considérer l'adresse comme une entité à part avec pour propriétés le numéro, le nom de la voie, un complément éventuel d'adresses, un code postal et une commune. Là, on arrive à un choix qui va dépendre de l'ampleur de l'application envisagée. Si dans le pire des cas on a 1 000 adresses, il n'est pas forcément intéressant de séparer les communes de l'adresse : au-delà, ça peut devenir plus pratique de séparer en ayant une entité communes ayant comme propriétés le libellé de la ville et son code postal.

Comme tu vois, un simple petit annuaire avec des noms, téléphones et adresses nous amène assez logiquement à quatre entités avec des relations bien définies : personnes, téléphones, adresses, communes. De là, on a déjà défini les relations, on arrive donc à la phase où on passe au modèle physique de données et là on va définir des tables et des colonnes avec des clés étrangères selon le cas, et des tables relationnelles dans certains cas spécifiques.

Le terme de relation « parent=>enfant » doit être assez logique : un parent peut avoir 0 à n enfants. Maintenant, il existe aussi certains cas de relations récursives : prenons pour illustrer ça l'exemple d'un forum comme celui-ci : il y a des messages, leurs propriétés sont texte, auteur, heure d'envoi et... message d'origine. Là, nous avons une récursion : nous ne ferons pas deux entités messages, mais un message et sa/ses réponse(s) sont toujours des messages, il faut les lier entre eux, donc ce que tu as nommé « id_pere » correspondra à l'identifiant du sujet d'origine et se retrouvera en propriété de tous les messages, le sujet d'origine n'en ayant pas puisqu'il ne se rattache lui-même à aucun autre message « parent »

Si tu cherches un outil de modélisation de bases de données, comme tu es probablement avec MySQL, je te recommande MySQL-Workbench, c'est disponible gratuitement (pour l'instant, avec Oracle, on ne sait pas si ça va durer) : ça ne fait pas du vrai modèle de données Entités/association selon la méthode MERISE (méthode correspondant à ce que j'ai exposé précédemment) mais ça fait directement un MPD en créant automatiquement les tables et les relations. Mais malheureusement, le meilleur outil que je connaisse pour faire ça n'est pas accessible pour les petits budgets, c'est PowerAMC et ça vaut plus de 2000 euros selon ce que j'en sais en ce moment. L'outil avec lequel tu as conçu les premiers modèle me semble très bien, je ne sais pas ce que c'est, mais coté modélisation, il est à mon sens meilleur que MySQL-Workbench pour bien comprendre le modèle.

En conclusion : pense d'abord "Entités" et relations entre ces entités : dessine ton modèle avec logique et montre-moi ça, on va avancer mais une fois au bout de ce chemin là, tu auras un modèle de données stable et durable. N'oublie surtout jamais un point sur les modèles de données : si ton modèle (et à terme la base de données) est bancal, même en admettant que tu sois un super-gourou de la programmation, ton application sera et restera bancale. Tu es dans la phase la plus importante du développement de ton application, n'essaye pas de gagner du temps en bâclant le MCD/MPD ;-)

Bon, là, je dois avouer que je suis largué...

Dans mon cas, les personnes concernées ont un certain niveau social, et ne vivent pas dans un immeuble. Je veux bien séparer l'adresse mais j'aurais quasiment autant d'adresse que de personnes. Au pire, je sors les adresses que je rajoute en relation sur la relation "habite". J'avais extrait code postal et ville, car ce sont des structures locales et beaucoup habitent la même ville, donc ça me semblait bien de séparer.

Pour le reste, j'ai vraiment l'impression que les entités sont toutes de relation 1,N / 1,1 ou 1,N / 1,N, et qu'elles sont bien séparées.

J'ai relu 3 fois ton post, mais je ne vois pas ce que je peux changer.

Je crois que je vais essayer de me lancer comme ça. Après tout, l'échec est aussi une source de progrès !

Re salut

Bon, ça m'empêche de dormir ces bétises ! J'ai donc commencé à essayer de faire ça en physique, et là, je crois que j'ai entrevu un soupçon de ce que tu voulais me dire. Je suis toujours plutôt perdu, mais il me semble percevoir certains principes, même si ça reste très flou.

J'ai retenté un modèle en essayant vraiment de m'éloigner de cette foutue réalité xD !

http://gevona.chatoz-corp.org/diagramme.jpg

Quelques remarques en vrac :

• Je ne sais pas ce que veulent réellement dire les flèches pointillées, je les ai mises pour exprimer le fait que le coureur découlait de l'individu.

• Je n'ai pas mis le lien entre coureur et parent, mais j'aurais mis une association "a des parents" qui renverrait vers l'entité "individu"

• Je ne suis pas bien sur de "entité de base", maisc'est la réalité qui m'a rejoint : je ne visualisais pas une table id_adresse id_ville id_structure id_ individu, car il y aura toujours id_structure ou id_individu qui restera vide.

• Je ne suis pas sur d'avoir tout compris, loin de là, mais un des buts ne serait pas d'éviter des tables avec des "cases" non remplies ?

Bon, j'espère que je suis sur la bonne voie, sinon, je range mon pc et me remet aux dominos !

A bientôt et merci encore pour le temps que tu passes à essayer de faire évoluer un inculte !

Salut,

Ça évolue, mais il reste des erreurs : ça reste quelque chose de difficile, je ne suis pas certain que plonger dans ce genre d'abstraction à 2h00 du matin soit le plus efficace ;)

mes suggestions :

1. l'entité ville doit se rattacher à l'adresse et non à ton entité de base : si quelqu'un a une adresse, cette dernière ne peut être que dans une seule ville avec un seul code postal;
2. Tu peux fusionner ton « entité de base » et« individu » : déjà ça va donner « Individu » habiteà une « adresse » laquelle est située dans une « ville »;
3. Là où j'ai un doute, c'est sur tonentité « email » : si c'est pour l'adresse de courriel, j'admets qu'il est possible qu'un individu ait plusieurs adresses, mais pour l'organisme utilisant l'application, il est préférable de ne pas collectionner les adresses desutilisateurs, donc « email » ne devrait être qu'une propriété de « individu ».
4. À la rigueur tu peux laisser l'entité « web » comme ça si ça correspond aux sites des utilisateurs, quoiqu'il reste un doute sur les cardinalités : un utilisateur aura 0 à n sites, mais un site est à un et un seul individu (ou organisme à la rigueur mais on arrive hors sujet puisque les organismes ne sont pas traités);
5. Les liens individu//structure//groupe me laisse perplexe : il faudrait que tu m'expliques à quoi ça correspond. Tel que je comprends la chose, je dirais que « Structure » comporte 1 à n « groupes », qu'un individu appart ient à une structure et en parallèle est membre de 1 à n « groupes »
6. «utilisateur » : je suppose qu'il s'agit des identifiants de l'individu pour se conncter à l'application : donc chaque individu n'aura qu'une seule correspondance dans « utilisateur » et un utilisateur ne correspondra qu'a un seul individu : en d'autres termes, username, password et fonction pourraient être des propriétés de individu;
7. «Ecole » : n'existe-t-il pas un lien avec la structure ? Je peux me tromper, mais je me demande si l'école ne comporterait pas 1 à n structures et dans ce cas, s'intercalerait entre individu et structure... ? là, je ne sais pasce que tu as tenté de matérialiser;
8. Mais directement en lien avec le point précédent, il y a une notion de « sports » au sein de l'école, ce serait donc une des structures de l'école ..?

Je vais déjà te laisser digérer ça, je dirais que tu es en bonne voie : je sais que c'est très abstrait et difficile à appréhender, mais sois patient et attentif, l'objectif final mérite que tu prennes le temps de l'analyse, tu vas y arriver :)

Salut Cyrano

Une fois de plus, merci de tes réponses. Dans un premier temps, j'aimerais si possible que tu répondes à quelques questions dont je ne trouve pas de réponses sur google et qui sont importantes pour mo. Je sais, je vais te parler des tables alors qu'on en est pas là, mais c'est quand même aussi en voyant ce que l'on peut faire en physique que l'on peut conceptualiser :

• Est-ce que un des buts ne serait pas d'avoir des tables avec le minimum de cases vides ?

• Est-ce que c'est génant d'avoir une table avec par exemple id_adresse, id_utilisateur et id_structure par exemple ? En fait, ça rejoint la question d'avant, ce genre de table impliquerait que à chaque adresse, il y ait dans la majorité des cas soit un utilisateur, soit une structure, et donc dans la majorité des cas un champs resterait vide.

Après, pour revenir sur la modélisation, je vais essayer de te répondre point par point sur comment j'ai réfléchi, du coup, je vais te contredire parfois, mais juste pour le plaisir ;) :

1. l'entité ville doit se rattacher à l'adresse et non à ton entité de base : si quelqu'un a une adresse, cette dernière ne peut être que dans une seule ville avec un seul code postal; ***--> Il peut y avoir des "12, place de la Mairie" ou des "23, avenue du général de Gaulle" dans plusieurs villes, non ? En exagérant, on pourrait même séparé le numéro car on va en avoir de manière redondante, non ? ***
2. Tu peux fusionner ton « entité de base » et« individu » : déjà ça va donner « Individu » habiteà une « adresse » laquelle est située dans une « ville »; ***--> En fait, mon entité de base est censée être le parent de structure, école et individu, et individu être le parent de coureur et utilisateur. ***
3. Là où j'ai un doute, c'est sur tonentité « email » : si c'est pour l'adresse de courriel, j'admets qu'il est possible qu'un individu ait plusieurs adresses, mais pour l'organisme utilisant l'application, il est préférable de ne pas collectionner les adresses desutilisateurs, donc « email » ne devrait être qu'une propriété de « individu ».--> OK
4. À la rigueur tu peux laisser l'entité « web » comme ça si ça correspond aux sites des utilisateurs, quoiqu'il reste un doute sur les cardinalités : un utilisateur aura 0 à n sites, mais un site est à un et un seul individu (ou organisme à la rigueur mais on arrive hors sujet puisque les organismes ne sont pas traités); --> Imagine un équipage composé de 3 individus qui ont un site pour leur équipage ?
5. Les liens individu//structure//groupe me laisse perplexe : il faudrait que tu m'expliques à quoi ça correspond. Tel que je comprends la chose, je dirais que « Structure » comporte 1 à n « groupes », qu'un individu appart ient à une structure et en parallèle est membre de 1 à n « groupes » --> C'est ça
6. «utilisateur » : je suppose qu'il s'agit des identifiants de l'individu pour se conncter à l'application : donc chaque individu n'aura qu'une seule correspondance dans « utilisateur » et un utilisateur ne correspondra qu'a un seul individu : en d'autres termes, username, password et fonction pourraient être des propriétés de individu; --> Bah non, je ne crois pas, les coureurs sont des individus mais n'ont pas de username et de password.
7. «Ecole » : n'existe-t-il pas un lien avec la structure ? Je peux me tromper, mais je me demande si l'école ne comporterait pas 1 à n structures et dans ce cas, s'intercalerait entre individu et structure... ? là, je ne sais pasce que tu as tenté de matérialiser; --> L'individu étudie dans une école, qui est un enfant de l'entité de base.

Une petite dernière question pour la route : est-ce qu'il ne vaut pas mieux avoir :

• une entité "individu" qui serait le parent de coureur et utilisateur,
• une entité "structure" qui serait le parent de école et structure d'entrainement.

A très bientôt !

Salut, commençons avec tes questions : -1- « Est-ce que un des buts ne serait pas d'avoir des tables avec le minimum de cases vides ? * » Tout à fait exact, on évite autant que possible d'avoir des tables avec trop de valeurs NULL; C'est ce qui explique le découpage de mon exemple d'annuaire entre personne et téléphone. Sur un système très basique, on pourrait avoir dans mon entité personne une ptopriété tel_fixe, tel_mobile et tel_fax, mais je pourrais avoir pas mal de lisgnes de personnes sans aucun numéro et manquer de colonnes pour des personnes qui auraient plus d'un numéro de tel_mobile par exemple. -2- « *Est-ce que c'est génant d'avoir une table avec par exemple id_adresse, id_utilisateur et id_structure par exemple ? En fait, ça rejoint la question d'avant, ce genre de table impliquerait que à chaque adresse, il y ait dans la majorité des cas soit un utilisateur, soit une structure, et donc dans la majorité des cas un champs resterait vide. » Je crois que tu visualises à l'envers. L'idée d'une table adresse est précisément que tu peux lier une ou plusieurs adresses à différentes entités, par exemple à individu, ou bien à ecole ou structure selon la signification de l'un ou l'autre. Si tu observes les cardinalités, c'est là que sera défini dans quelle tables tu introduiras des clés étrangères. Donc par exemple l'entité individu deviendra la table individu avec sa clé primaire et en clé étrangère l'identifiant de l'adresse.

La suite :

1. Le découpage des adresses à ce niveau est certes logique mais ça va devenir ingérable au niveau du traitement (programmation) et tu vas avoir des requêtes à coucher dehors pour récupérer tes données;
2. Là je sais pas trop : définis ce que tu nommes « structure » et « entité de base , que représente l'élément ?
3. Ok, rien à ajouter;
4. Là, tu fais état d'une donnée qui n'apparait pas dans ton modèle actuel : « Équipe » est-ce que cette donnée apparaît dans ton dictionnaire de données ? En tout état de cause, l'individu peut avoir un site web, l'équipe aussi, or là je vais partir du principe qu'un individu peut être ou non membre d'une équipe.
5. Ok, donc ton système de relation entre ces trois éléments serait à revoir selon cette description, je te laisse y penser un peu;
6. Je n'ai pas dit le contraire, l'identifiant et le mot de passe ne correspondent qu'à des individus, pas à des coureurs. Si un individu est un coureur, rien n'oblige à attribuer un identifiant à l'individu. Là, c'est un cas où on aura des valeurs NULL pour certains individus.
7. Voir le point 2;

Les deux derniers éléments :

pour le premier, ce serait en effet une solution à considérer si elles simplifie ton modèle.

pour le second, je suis plus circonspect : schématiquement, je vois ça de la manière suivante : l'école serait l'entité de base, dans l'école, il y a n structures et donc éventuellement une structure dont le nom serait « entrainement » à laquelle tu pourrais rattacher l'inscription des coureurs.

Sommairement, tu as divers blocs généraux : l'établissement, les personnes, des données génériques : pour la partie établissement, tu as école, structure, pour personne tu auras individu et coureur avec ce qui s'y relie directement, pour les donnés génériques, tu as ce qui concerne les adresses et villes. Il est possible que des entités diverses soient reliées à celles de la partie générique, par exemple tu pourras lier des adresses aussi bien à des individus qu'à des écoles sans qu'il y ait conflit.

Voilà, je t'invite à revoir ton mdèle sur ces base et à me montrer ça, on avance assez bien je trouve :)

Re salut

La suite de mes travaux :http://gevona.chatoz-corp.org/diagramme.jpg

J'ai changé un peu la terminologie pour que se soit plus clair :

• L'établissement est forcément une école (scolaire) ou un club (de voile)
• L'individu est forcément un coureur ou un utilisateur ou un parent

J'ai essayé de repenser à la relation coureurs / utilisateurs / clubs de voile / groupe / saison.

En gros, le club organise la saison, la saison est composée de différents groupes, les individus appartiennent (ou pas) à un ou plusieurs groupes, et les groupes naviguent.

Le lien entre club de voile et utilisateur me semble dans mon modèle assez long (utilisateur --> individu --> groupe --> saison --> club). J'aurais surement intérêt à établir un lien direct, non ?

J'ai hâte de te lire !

A bientôt

Hello,

il y a un soucis avec tes relations «communique» et «habite» la même relation ne peut concerner les deux paires d'entités, ainsi, tu dois avoir une relation «etablissement» -> «domicilié» -> «adresse»d'une part et «individu»->«habite»->«adresse» d'autre part.J'ai tenté de te faire un croquis qui sera peut-être plus clair :

+---------+                +-------------+                   +---------------+                  +------------+
| ville   | 1:n situe  1:1 | adresse     | 1:1 domicilie 1:1 | etablissement | 1:n  comm_1  1:1 | telephone  |
+---------+ -------------- +-------------+ ----------------- +---------------+ ---------------- +------------+
| vil_id  |                | adr_id      |                   | etb_id        |                  | tel_id     |
| vil_nom |                | adr_numero  | 0:n               | etb_nom       |      comm_2  1:1 | tel_numero |
| vil_cp  |                | adr_libelle | --,               | etb_mail      |     ,----------- | tel_type   |
+---------+                | adr_compl   |   |               | etb_site      |     |            +------------+
                           +-------------+   |               +---------------+     |
                                             |                                     |
                                             |               +--------------+      |
                                             | habite    1:1 | individu     | 1:n  |
                                             '-------------- +--------------+ -----'
                                                             | ind_id       |
                                                             | ind_nom      |
                                                             | ind_prenom   |
                                                             | ind_mail     |
                                                             +--------------+

Comme tu vois, à partir de telephone, nous avons comm_1 qui vient de etablissement et comm_2 qui vient de individu : là nous avons un modèle conceptuel correct.

Un petit conseli au passage : note de quelle manière je nomme les propriété des entités : elles sont toutes préfixées selon le nom de l'entité. Pour passer au modèle physique, tu vas avoir des clés primaire à ajouter. Mais c'Est là qu'on va découvrir que le croquis qui précède devient faux sur un pointL la ralation etablissement//telephone. Au téléphone, ce n,est pas un établissement que tu appelles mais un interlocuteur qui a une fonction dans cet établissement.

On va s'arrêter un peu sur ce point et voici ma suggestion :

+---------+                +-------------+                   +---------------+                   +---------------+
| ville   | 1:n situe  1:1 | adresse     | 1:1 domicilie 1:1 | etablissement | 1:n  emploie  1:n | interlocuteur |
+---------+ -------------- +-------------+ ----------------- +---------------+ ----------------- +---------------+
| vil_id  |                | adr_id      |                   | etb_id        |                   | int_id        |
| vil_nom |                | adr_numero  | 1:n               | etb_nom       |       est     1:1 | int_fonction  |
| vil_cp  |                | adr_libelle | --,               | etb_mail      |     ,------------ +---------------+
+---------+                | adr_compl   |   |               | etb_site      |     |
                           +-------------+   |               +---------------+     |
                                             |                                     |
                                             |               +--------------+      |
                                             | habite    1:1 | individu     | 1:1  |
+------------+                               '-------------- +--------------+ -----'
| telephone  | 1:1         communique                    0:n | ind_id       |
+------------+ --------------------------------------------- | ind_nom      |
| tel_id     |                                               | ind_prenom   |
| tel_numero |                                               | ind_mail     |
| tel_type   |                                               +--------------+
+------------+

Observeun détali : j'ai rajouté une entité interlocuteur avec des cardinalités 1:n/1:n entre l'établissement et l'interlocuteur : un établissement emploie de 1 à n interlocuteurs, un interlocuteur peut être employé de plusieurs établissement, par exemple être prof salarié dans une école et animateur bénévole dans un club. Ce type de ralation dans un modèle conceptuel aboutiraà la transformation de la relation « emploie » en table relationnelle dans le modèle physique.

Je te suggère de commencer par analyser cette partie avant d'aller plus loin dans ton modèle conceptuel et de bien en assimiler la logique. Si un point t'échappe, reviens avec les questions et si c'est bien clair, on continuera sur la suite et la partie gestion club/saisons/groupes : il y a des bizarreries dans tes formulations, on va tenter d'éclaircir certains détails.

Au fait, c'est quoi l'outil que tu utilises pour modéliser ?

Re salut

Le logiciel est un freeware appelé Open ModelSphere, mais il ne gère pas de dictionnaire de données.

L'autre modèle que tu avais vu une fois est analyseSI, un freeware également en java, qui intègre un dictionnaire, mais qui met de clés primaires partout dans le modèle conceptuel, mais qui est cependant plus simple à utiliser. En plus, tu ne peux pas ajouter une proriété qui n'est pas dans le dictionnaire.

Tes explications sont très claires et me vont bien. Je les remodelerais surement car je tiens à garder le numéro de standard et le numéro de télécopie même si je ne connais pas le nom de la secrétaire. J'avais déjà prévu avoir un prof principal et un proviseur, non modélisé car je ne me sens pas en difficulté sur cette partie.

En tout cas, merci pour l'explication, elle était très très clair et je pense qu'elle servira à beaucoup d'autre.

A bientôt

Je ne connais pas ces outils, mais je vais y jeter un oeil. Le second force les clés primaire ? Ce n'est pas une mauvaise chose en soi, si tu regardes mes croquis, j'en ai mis aussi sauf que je l'ai fait à la main. Quand à ne pas pouvoir mettre une propriété absente du dictionnaire, je trouve ça plutôt intelligent comme idée : ça te force à bien identifier toutes tes données.

Ok, pour la suite, pars du même principe. Le plus difficile, c'est de travailler avec de l'abstrait, j'en suis très conscient, mais ça reste de la logique, un peu comme ce que je disais sur l'interlocuteur que tu appelles en lieu et place d'un établissement, on a jamais vu qui que ce soit passer un coup de fil à un immeuble en béton, habituellement ce dernier ne décroche même pas le téléphone ;-)

Je vais tester un peu ApplicationSI et peut-être l'autre selon le cas et je te reviens dessus.

Certes,je comprends bien cette logique, mais après faut aussi rester un peu réaliste, non ? On n'envoie pas non plus un email à un immeuble (qui au demeurant n'est pas une propriété de la structure xD) !

Moi aussi j'aime bien le remplissage obligatoire du dictionnaire. Malheureusement, analyseSI ne permet pas de retoucher le mpd, et il génère obligatoirement une table par relation (me semble-t-il)

Salut,

je n'ai pas eu le temps de tester (j'ai quand même du boulot ;) ), mais je serais surpris que la création de tables relationnelles soit systématique : Elle est normale si on a des cardinalités similaires des deux cotés comme 1:n/0:n

En fait, si tu y réfléchis, dans une relation 1:1/0:n, de quel coté mettra-t-on une clé étrangère ? Et pourquoi ?

Salut

Je viens de vérfier pour AnalyseSI. Il ne crée effectivement pas de table à chaque fois. Il intègre la clé étrangère da,s la bonne table au moins dans les relations du type 1,1 / 1,N .

Pour la question de la clé étrangère dans une relation 1:1 / 0:n, ça sent le piège xD. Moi je la mettrais sans hésiter du côté 1:1 puisqu'il y en a forcément 1 et au maximum 1 (ma clé étrangère se sera jamais vide).

Pour revenir on mon premier schéma, voici les quelques modifications que j'apporterais pour la relation individu / groupe / saison / clubs :

• Pour la gestion de la saison, je mettrais bien une propriété "saison active" dans l'entité "club". Ca donnerait :

+---|---|---|---|---|---|+ +---|---|---|---|---|---|+ | club | ---|---|---|---|---| | saison | +---|---|---|---|---|---|+ ---| 0:N ---| < organise > ---| 1:N ---| +---|---|---|---|---|---|+ | club_id | ---|---|---|---|-- | saison_id | | club_saison | | saison_nom | | autres prop | +---|---|---|---|---|---|+ +---|---|---|---|---|---|+

• Après, pour la navigation, ce ne sont pas les groupes qui naviguent, mais les coureurs, donc tout le bloc navigation repasserait sur les coureurs

• Il reste juste la relation :

[ club ] 0:N ---| (Met en place) ---| 1:1 [ groupe ] 1:N ---| (appartienne) ---| 0:N [ individu ]

Qu'en penses-tu ? A bientôt

Voilà, la clé étrangère sera du coté logique : si un club comporte plusieurs groupes, j'aurai du coté du groupe la clé étrangère identifiant le club. Mais si j'ai une relation 1:N/1:N, je crée alors une table relationnelle qui va me permettre de mettre en place la relation entre mes deux entités. Le modèle [Table_1]-1:N--rel--1:N-[Table_2] va aboutir aux tables [Table_1]+[rel]+[Table_2] parce que logiquement, ça correspondra au modèle [Table_1]-1:N--lien_1--1:1--[rel]-1:1--lien_2--1:N--[Table_2] et là, la même règle s'applique.

La gestion de la saison, j'ai un doute : en fait, une saison commence à une date et se termine à une autre date : du coup, on peut considérer que la saison est active si la date du jour se trouve dans cette période ou non... le coté actif est donc implicite. Partant de là, tu rattaches les courses à une saison ou l'autre simplement en y affectant une date.

Pour la navigation, c'est peut-être plus subtil : les courses peuvent être individuelles ou par équipe, non ? À moins que tu ne nommes "groupe" les équipes ? Ou bien les groupes correspondent aux catégories selon le type de bateau, ou l'âge des coureurs (benjamins, juniors, etc..) ?

Quant aux liens club/groupe/individu, j'hésite, ça dépend de la réponse au point précédent.

Enfin pour finir, un détail : j'ai idée que tu espérais plier rapidement cette modélisation. Ne t'en formalise pas, c'est quelque chose de difficile. Moi-même, malgré une certaine expérience, j'ai mis, il y a quelques années, trois semaines complètes à plein temps pour modéliser une base de petite boutique en ligne. Mais ça vaut la peine parce qu'après ça, d'abord tu maitrises parfaitement ton modèle à force d'en avoir bouffé et tu réalises ensuite que tes manipulations de données coté programmation se font beaucoup plus facilement :)

Salut

Bon, tu risques de me disputer ! Je confirme ton ressenti : je suis impatient mais je comprend quand même toute la nécessité du travail accompli en modélisation et je suis effectivement persuadé que c'est indispensable. Ceci étant dit, j'ai craqué, et j'ai commencé à essayer de réfléchir sur la partie physique (les jeunes de maintenant, c'est vraiment n'importe quoi !).

Voici ce que j'ai fait : http://www.chatoz-corp.org/gevona/diagramme.jpg

Bon, je comprendrais très bien que tu dises "Espèce de morveux, retourne à ton mcd et je continuerais à te parler. Si tu veux bruler les étapes, c'est sans moi !"

Si jamais tu ne dis pas ça, voici quelques explications :

• J'ai supprimé la distinction entre école et club car je n'en ai pas besoin en fait. Le numéro de club n'est pas une donnée importante.
• J'ai mis en jaune les tables qui gèrent des relations entre les différentes entités pour bien les repérer.
• La table-relation "embauche" a une colonne fonction qui permet de définir les différentes fonctions nécessaires au modèle : fonction "coureur" pour les coureurs, fonction "entraineur" ou "responsable" pour les utilisateurs, fonction "proviseur" ou "prof principal" lorsque l'établissement est de type école.
• La table-relation "est sous la tutelle de" a une colonne role qui prendra comme valeur "père", "mère", "tuteur" ou "prof principal".
• Pour la table groupe, commençons par une explication. Dans un groupe évolue des équipages ou des individus (en fonction du groupe).Ici, on se moque de la notion d'équipage. Le groupe est rattaché à une structure, une saison, a un ou plusieurs entraineurs (individu-utilisateur) et des coureurs (individu-coureurs)
• Je n'ai pas fait toutes les tables qui se rattachent au coureur (scolaire, médical, etc...) car je crois qu'elle ne me pose pas de problèmes, ni de modélisation, ni de mise en place.

Bon, j'ai hâte de savoir si je vais me faire engueuler xD

EN fait ton modèle commence à avoir pas mal d'allure. Il n'y a que cette relation « s la tutelle de» que je ne saisis pas bien : «rôle» peut très bien être une proptiété de « coureur» non ? Comme tu as déjà en plus «ind_id» en clé étrangère dans «coureur», cette relation ne se justifie pas vraiment. Ou alors c'est qu'il manque une notion quelque part... ?

Les cardinalitées entre adresse et individu en revanche, il semble y avoir une erreur : un individu habite à une et une seule adresse, mais une adresse peut héberger 0 à n individus... donc la clé étrangère «adr_id» devrait être présente dans «individu» et la relation «habite» devrait sauter purement et simplement.

Les cardinalités entre individu et utilisateur : au lieu de 0:N-1:1, ce devrait être à mon sens 0:1-1:1 : un individu peut avoir ou non un (et un seul) identifiant de connexion, un identifiant ne peut correspondre qu'à un et un seul individu.

Pour le reste, je n'ai rien de particulier à rajouter, tu es dans une assez bonne voie à mon avis ;)

Cool, je ne me suis pas fais engueuler et merci pour tes réponses

Pour le "est sous la tutelle de", je voudrais en fait pouvoir identifier le père du coureur par exemple, qui est un individu. Du coup, coureur_id pour qu'il soit lié au coureur, individu_id pour qu'il soit lié au parent (ici le père), et un rôle (père, mère, ...).

Pour les cardinalités entre adresses et individus, je suis d'accord avec toi, mais dans la réalité, je ne vais pas demandé les adresses de tous les individus. Par exemple, je ne renseignerais pas l'adresse des utilisateurs, ni du prof principal, ni du proviseur. Du coup, l'individu pourra avoir une adresse ou pas. J'ai mis une table intermédiaire pour éviter d'avoir trop d'invidus qui aurait une valeur null pour adresse_id.

Effectivement pour les cardinalités entre individu et utilisateur, c'est une erreur.Merci.

Bon, je crois y voir un peu plus clair. Je suis maintenant partagé à refaire une modélisation d'un sujet au hasard pour que ça reste gravé dans ma mémoire, ou à me plonger dans la partie programmation.

En tout cas, merci pour tout, c'est vraiment génial d'avoir un mentor pédagogue !

A très bientôt