Discussion :

[ok.Idriss]

Bonsoir.

Une bonne partie y est, il me faudra quand même voir avec mon ami si j'ai bien respecté le cahier des charges (il me manque deux trois fonctionnalités dont il faut qu'on parle, je le mettrai à jour donc plus tard).

À vrai dire on ne peut pas trop vous dire si votre modèle respecte bien les règles de gestion qui ont été établies dans votre cahier des charges (ou pas ) sans ces règles de gestion ...

Par exemple, votre modèle fait en sorte qu'une adresse peut être habitée par 1 ou plusieurs étudiants et que ceux-ci ne peuvent habiter qu'à 0 ou une adresse. Ceci est une règle de gestion qu'illustre votre MCD. Est-ce bien celle qui a été décidée dans le cahier des charges ? Ce n'est qu'un exemple, cela ne remet aucunement le modèle en question.

désolé pour les noms des variables, AnalyseSI n'autorisant pas les variables de même nom, pareil pour les associations, il n'autorise pas les noms "vides" donc j'ai du laisser les "Association 57" .

De manière générale c'est mieux d'éviter que plusieurs entités ou associations portent le même noms (ceci dit c'est pas trop grave dans le cadre d'une association qui ne deviendra pas une relation par la suite).

Personnellement, pour les noms d'associations qui se répètent (les classiques comme correspondre, appartenir, etc), je rajoute les initiales des entités encadrant ces associations. Par exemple pour votre association 22 et votre association 23 j'aurais mis participer_et_d (pour étudiant et discussion) et participer_en_d (pour entreprise et discussion). On peut aussi chercher des synonymes comme intervenir, etc.

(Sinon on ne parle pas de variables mais d'attributs ou de propriétés d'une entité ou association).

même si vous vous êtes un peu engueulés entre vous et que j'ai pas compris toutes vos réponses :o).

meuh non

Cordialement,
Idriss

[Bakura]

Salut,

Merci de vos réponses (haha, j'ai pas l'habitude de vouvoyer sur un forum, vous m'en voudrez pas si je dis "tu" par réflex ).

À vrai dire on ne peut pas trop vous dire si votre modèle respecte bien les règles de gestion qui ont été établies dans votre cahier des charges (ou pas ) sans ces règles de gestion ...

Par exemple, votre modèle fait en sorte qu'une adresse peut être habitée par 1 ou plusieurs étudiants et que ceux-ci ne peuvent habiter qu'à 0 ou une adresse. Ceci est une règle de gestion qu'illustre votre MCD. Est-ce bien celle qui a été décidée dans le cahier des charges ? Ce n'est qu'un exemple, cela ne remet aucunement le modèle en question.

Mmhhh... En fait BEAUCOUP d'informations sont facultatives (l'étudiant n'est pas "obligé" d'entrer son adresse - mais du coup vous me faites douter, faut que j'en reparle avec mon ami qui s'occupe des autres aspects plus législatifs -, dans tous les cas 1...N ou 0...N ça ne change rien après au niveau du code si ?).

Mais effectivement, deux étudiants peuvent habiter la même adresse (un frère et une soeur par exemple), mais du coup je pense que ça impliquera la création d'une nouvelle entrée en base, sinon ça obligerait à vérifier si l'adresse correspond complètement, ça risque d'être lourd à gérer ?

Je voulais davantage avoir des avis s'il y avait des choses à normaliser, de nouvelles entités à créer, des choses mal pensées...

Personnellement, pour les noms d'associations qui se répètent (les classiques comme correspondre, appartenir, etc), je rajoute les initiales des entités encadrant ces associations. Par exemple pour votre association 22 et votre association 23 j'aurais mis participer_et_d (pour étudiant et discussion) et participer_en_d (pour entreprise et discussion). On peut aussi chercher des synonymes comme intervenir, etc.

Merci, c'est ce que je vais faire.

(Sinon on ne parle pas de variables mais d'attributs ou de propriétés d'une entité ou association).

Désolé, je suis programmeur C++ à la base

[ok.Idriss]

Bonjour.

Mais effectivement, deux étudiants peuvent habiter la même adresse (un frère et une soeur par exemple), mais du coup je pense que ça impliquera la création d'une nouvelle entrée en base, sinon ça obligerait à vérifier si l'adresse correspond complètement, ça risque d'être lourd à gérer ?

Cela dépend de ce qui a été spécifié au départ : l'adresse et la commune vont-elles être saisies ou sélectionnées ou les deux ? Dans le cas de saisies simples (avec formulaire simple), le plus simple à gérer selon moi serait de mettre une nouvelle entrée par occurrence ajoutée dans les futures tables entreprise et étudiant voire même d'ajouter les champs rue, ville, cp directement dans ces tables.

Pour éviter la redondance des attributs dans votre modélisation, vous pouvez également (ce n'est pas une obligation) créer une entité mère Personne avec les données communes dont hériteront les entités filles Entreprise (personne morale) et Etudiant (personne physique). Il s'agira ici d'un héritage avec partition (cf : la FAQ) ...

Dans le cas de sélection ou de système d'auto-completion (comme on le voit dans certains sites), on peut se servir de votre modélisation telle quel. Si c'est en permettant la saisie et la sélection en faisant attention à éviter les doublons, ce sera moins simple mais faisable (on pourra passer par des tests avec des regex, ce genre de choses, ...).

Bref, les règles de gestion doivent être décidées par rapport à la phase de spécifications qui précède. Les spécifications répondent à la question "Qu'est-ce que doit faire l'application ? Et par qui ?". Les règles de gestion rentrent déjà dans l'étape de conception (étape suivante) qui répond à la question "Comment doit-elle le faire ?".

Sinon à première vue, je ne vois pas d'erreur de normalisation dans ce nouveau MCD.

J'ai avancé mon MCD, en prenant en compte vos remarques, en complétant certaines entités, et en modifiant quelques petites choses pour respecter la... hum deuxième forme normale je crois (avec les adresses, et les langues).

Les formes normales sont des niveaux de normalisation au niveau relationnel, pas au niveau conceptuel .

dans tous les cas 1...N ou 0...N ça ne change rien après au niveau du code si ?).

Au niveau de la structure de la future table non. Mais le MCD permet de modéliser différentes règles de gestions qui peuvent aussi être implémentées par divers contrôles ou autres au niveau de la base (triggers, procédures stockées, etc) comme au niveau de l'application directement. On voit que vous êtes habitué à l'UML dans votre façon d'écrire les cardinalités .

P.S : le tutoiement ne me dérange aucunement (je tutoie dans d'autres forums)

Cordialement,
Idriss

[Bakura]

Cela dépend de ce qui a été spécifié au départ : l'adresse et la commune vont-elles être saisies ou sélectionnées ou les deux ? Dans le cas de saisies simples (avec formulaire simple), le plus simple à gérer selon moi serait de mettre une nouvelle entrée par occurrence ajoutée dans les futures tables entreprise et étudiant voire même d'ajouter les champs rue, ville, cp directement dans ces tables.

On souhaite au maximum garantir la validité des données donc on compte faire de l'auto-complétion pour les communes (d'où le fait que je l'ai séparée dans une autre entitée). Pour les adresses... effectivement ça risque d'être compliqué de faire de l'auto-complétion sur les noms de rue ! Donc effectivement c'est plutôt du 1...1 que du 1...N. J'ai changé !

Pour éviter la redondance des attributs dans votre modélisation, vous pouvez également (ce n'est pas une obligation) créer une entité mère Personne avec les données communes dont hériteront les entités filles Entreprise (personne morale) et Etudiant (personne physique). Il s'agira ici d'un héritage avec partition (cf : la FAQ) ...

Ouaip, j'y avais également pensé, et vu que l'ORM que j'utilise (Doctrine) gère l'héritage, je pense que je vais essayer de refactoriser ça pour utiliser de l'héritage.

Merci bien en tout cas . Si vous avez d'autres remarques n'hésitez pas, encore une fois les bases de données c'est vraiment pas mon domaine de prédilection, j'ai juste suivi quelques cours cette année...

EDIT : je mets en Résolu pour le moment puisque tu dis qu'il n'y a pas de soucis flagrants, mais si quelqu'un d'autre voit quelque chose de choquant qu'il n'hésite pas :o.

[ok.Idriss]

Re bonjour.

On souhaite au maximum garantir la validité des données donc on compte faire de l'auto-complétion pour les communes (d'où le fait que je l'ai séparée dans une autre entitée). Pour les adresses... effectivement ça risque d'être compliqué de faire de l'auto-complétion sur les noms de rue ! Donc effectivement c'est plutôt du 1...1 que du 1...N. J'ai changé !

Dans ce cas, je suggère de mettre directement un champs "rue" dans les entités Entreprise et Etudiant (car elles sont en dépendance fonctionnelle directe avec l'identifiant de ces dernières) et relier ces dernières à l'entité Commune avec les cardinalités qui vont bien. Ce sera plus simple à gérer à mon avis.

Sinon autre remarque : une ville peut parfois avoir plusieurs codes postaux (ceci dit, c'est assez rare et vous pouvez faire plusieurs entrées pour une même ville, voire passer cela sous silence).

P.S : entre temps, j'ai complété mon post précédant. (Sinon pour ma part, je suis développeur aussi et pas DBA, ça se voit d'ailleurs dira fsmrel ).

Cordialement,
Idriss

[Bakura]

Dans ce cas, je suggère de mettre directement un champs "rue" dans les entités Entreprise et Etudiant (car elles sont en dépendance fonctionnelle directe avec l'identifiant de ces dernières) et relier ces dernières à l'entité Commune avec les cardinalités qui vont bien. Ce sera plus simple à gérer à mon avis.

Bien vu ! Ca fait toujours une entité de moins à gérer dans ce joli bazar .

Sinon autre remarque : une ville peut parfois avoir plusieurs codes postaux (ceci dit, c'est assez rare et vous pouvez faire plusieurs entrées pour une même ville, voire passer cela sous silence).

Oui, j'avais déjà pensé à ce problème. Je pense que je passerai ça sous silence effectivement en entrant un code postal générique (type 75000 pour Paris), ou alors proposer tous les codes postaux possibles dans une liste déroulante...