Discussion :

[Aedonya]

Bonjour à tous,

Je sais que le sujet location de véhicule existe déjà (je l'ai lu ) mais chaque sujet de projet étant différent, pourriez-vous me donner votre avis sur le MCD que j'ai fait.

Il s'agit d'un projet de gestion de location de véhicules par une société qui possède plusieurs agence.


Quelques contraintes :

1. un véhicule est sous la responsabilité d'une seule agence mais il peut être loué à des clients par d'autres agences. En effet, un véhicule appartenant à l'agence A peut être loué par l'agence A à un client qui va le rendre l'agence B. L'agence B peut alors conclure un contrat avec un client sur ce véhicule alors même que le véhicule ne lui "appartient" pas.
2. le tarif de location journalier dépend du type, de la catégorie et de l'agence où s'effecture la location
3. le véhicule est fourni avec le plein et le client doit le rendre avec le plein sinon l'agence le fait et le facture au client
4. j'ai également une liste imposée d'informations à représenter

A part quelques incertitudes, j'ai une question particulière au sujet du type et de la catégorie d'un véhicule : ici j'ai 6 types de véhicules (camion, utilitaire, tourisme, 4x4, moto, scooter) et 5 catégories (Eco, Standard, Moyenne gamme, Haut de gamme, Luxe). Je voudrais savoir s'il est possible de modéliser le fait q'on ai une liste fixe de types et de catégories (ceux énumérés ci-avant) et comment limiter les associations entre ces deux entités ? Par exemple, comment permettre qu'un véhicule de type Tourisme puisse être associé aux 5 catégories et qu'un véhicule de type utilitaire ne soit associé qu'à 3 catégories ?

Merci à tous de votre aide

Ci-joint le MCD et le MLD (fait avec AnalyseSI)

[JPhi33]

Bonjour Aedonya,

Je voudrais savoir s'il est possible de modéliser le fait q'on ai une liste fixe de types et de catégories (ceux énumérés ci-avant)

Oui, Merise n'a jamais interdit l'utilisation de nombres finis (> 1) pour la cardinalité maxi d'une patte d'association. On trouve même un exemple de cardinalité 0,2 dans "La Méthode Merise - Tome 1" mais il est vrai que cette pratique est très peu usitée car elle n'offre pas un grand intérêt.

Ce qu'on veut connaître grâce à une cardinalité maximale, c'est la capacité associative de l'entité par rapport à l'association dans laquelle elle intervient. Et pour cela, 1 et n suffisent.

et comment limiter les associations entre ces deux entités ? Par exemple, comment permettre qu'un véhicule de type Tourisme puisse être associé aux 5 catégories et qu'un véhicule de type utilitaire ne soit associé qu'à 3 catégories ?

Le MCD ne se limite pas à sa partie graphique. Certes, on essaie d'y faire figurer le maximum de choses mais ce type de contraintes entre occurrences d'entités ne se modélise pas graphiquement. A ma connaissance il n'y a que la "modélisation textuelle" qui peut le spécifier. En clair, il faut écrire la contrainte textuellement dans la description de l'association.

[Aedonya]

Bonjour JPhi33,

Merci pour tes réponses.

Bonjour Aedonya,
Oui, Merise n'a jamais interdit l'utilisation de nombres finis (> 1) pour la cardinalité maxi d'une patte d'association. On trouve même un exemple de cardinalité 0,2 dans "La Méthode Merise - Tome 1" mais il est vrai que cette pratique est très peu usitée car elle n'offre pas un grand intérêt.

Oui effectivement, j'avais oublié cette possibilité. J'étudie UML cette année mais dans le cadre de mon projet, il faut faire le MLD et le MPD et Merise était un peu loin dans mes souvenirs...

Ce qu'on veut connaître grâce à une cardinalité maximale, c'est la capacité associative de l'entité par rapport à l'association dans laquelle elle intervient. Et pour cela, 1 et n suffisent.

J'utilise AnalyseSi pour mon MCD et seules les cardinalité usuelles sont possibles. Je vais devoir faire une petite bidouille visuelle pour que cela apparaisse !

Le MCD ne se limite pas à sa partie graphique. Certes, on essaie d'y faire figurer le maximum de choses mais ce type de contraintes entre occurrences d'entités ne se modélise pas graphiquement. A ma connaissance il n'y a que la "modélisation textuelle" qui peut le spécifier. En clair, il faut écrire la contrainte textuellement dans la description de l'association.

Je pensais que le modèle devait se suffire à lui-même. En cours, on n'avait jamais de texte accompagnant le MCD et les seules explications textuelles que l'on devait faire apparaitre concernaient l'expression des clés étrangères dans le MLD, la prof n'appréciant guère la notation avec le dièse (#).

D'ailleurs, j'ai une question à propos du MLD : AnalyseSi propose une version graphique assez simpliste du MLD (les clé étrangère ne sont pas vraiment explicites) mais nous avons appris à le faire sous forme de texte. Par exemple :

CARBURANT(CodeCarburant, TypeCarburant)
PLEIN(CodePlein, prixAuLitre, NbLitres, NoContrat)
PLEIN_DE(CodeCarburant,CodePlein)

CodeCarburant de PLEIN_DE fait référence à CodeCarburant de CARBURANT.
CodePlein de PLEIN_DE fait référence à CodePlein de PLEIN.

Y-at-il une meilleure façon (graphique ou textuelle) de représenter le MLD ou est-ce juste une question de choix personnel ?

AnalyseSi ne proposant pas de faire MPD, j'ai installé DbDesigner mais lui ne fait pas les MCD... Je dois également faire quelques maquettes IHM et j'ai choisi Dia qui à l'air pas mal. L'inconvénient à jongler avec tous ces logiciels c'est qu'il faut retaper à chaque fois les noms des tables, attributs... Si vous avez des tuyaux pour des logiciels qui permettent de tout modéliser (IHM, Merise, UML), je suis preneuse même peut-être dans des logiciels payants s'il faut en passer par là

En PJ, ma dernière version du MCD, j'ai rajouté quelques petites choses.
Merci de me donner vos avis sur le fond du MCD

[CinePhil]

Essaie Open ModelSphere.

MCD et génération de MLD, ou plus précisément génération de modèle Entité/relation.

[Aedonya]

Merci beaucoup CinePhil , après un rapide coup d'oeil, c'est exactement ce que je cherchait. Reste pour l'IHM, mais vu que j'avais déjà crée des tables sous Access je vais peut-être rester la dessus pour ne pas perdre trop de temps à chercher l'idéal

Sinon que penses-tu de mon MCD, le trouves-tu cohérent ?

[f-leb]

bonjour,

CARBURANT(CodeCarburant, TypeCarburant)
PLEIN(CodePlein, prixAuLitre, NbLitres, NoContrat)
PLEIN_DE(CodeCarburant,CodePlein)

CodeCarburant de PLEIN_DE fait référence à CodeCarburant de CARBURANT.
CodePlein de PLEIN_DE fait référence à CodePlein de PLEIN.

comme ça par exemple: PLEIN_DE(#CodeCarburant,#CodePlein)

...l'expression des clés étrangères dans le MLD, la prof n'appréciant guère la notation avec le dièse (#).

juste pour l'emm#&@$¤ dans ce cas

Sinon j'ai pas bien compris cette histoire de cardinalités maxi à 5,6 dans ton cas particulier.
Categorie----0,n-----être----0,n-----type
par contre je verrais bien en plus :
Vehicule-----1,1----appartenir-----0,n------Categorie

Je ne vois pas bien non plus l'intérêt de l'association 4-aire Location (qui devrait plutôt s'appeler 'Louer' d'ailleurs).
Un contrat concerne un client qui loue un véhicule à une agence non ?
Contrat---1,1---signer----0,n-----Client
Contrat---1,1---concerner----0,n----Vehicule
Contrat---1,1---situer----0,n---Agence

autre question, comment on sait où se trouve tel véhicule dans ta base puisque le véhicule peut être ramené dans n'importe quelle agence ?
Il y a bien une colonne 'agence retour' dans Contrat, il y a quoi dedans ? L'agence de retour du véhicule est prévu dans le contrat ?

voilou pour l'instant

[CinePhil]

Comme il a déjà été dit, mettre une cardinalité maximale différente de 1 et entière n'apporte pas grand chose dans un MCD.

Dans certains cas, ça pourrait exprimer une contrainte, par exemple qu'une instance d'une entité A ne puisse être associé au maximum qu'à deux instances d'une entité B.

Dans ton schéma, les cardinalités de l'association 'Est de catégorie' signifient qu'un type ne peut être au maximum associé qu'à 5 catégories et qu'une catégorie ne peut être associée au maximum qu'à 6 types. Je ne sais pas si c'est vraiment ce que tu veux exprimer.

Dernier détail sur cette association : évite les cardinalités minimales à 1 des deux côtés, ça pose des problèmes à l'implémentation en BDD et c'est rarement nécessaire.

A la place de l'association 'location', j'aurais mis 'louer', un verbe comme dans toutes les autres associations.

D'après la cardinalité, un contrat peut être impliqué dans plusieurs locations. Est-ce vraiment le cas ? Il me semble plutôt qu'un contrat est en rapport avec une seule voiture pour un seul client et une seule agence.
J'aurais tendance à mettre 1,1 comme cardinalité du côté du contrat et 0,n sur les autres pattes de l'association 'louer' mais je sais que c'est contestable. A ce sujet, cette discussion peut te donner un éclairage.

Association 'plein de' (que j'appellerais plutôt 'remplir') : Tu mélanges les carburants dans un plein ? ==> Cardinalité 1,1 du côté du plein me semble plus juste.

Détail général : pour les clés primaires, préférer un identifiant anonyme de type entier non nul non signé et auto-incrémenté plutôt qu'une clé candidate qui peut être modifiée par la suite.
Notamment, noImmatriculation, noPermis et type_vehic seront probablement de type alphanumérique et donc de mauvaises clés. Voir à ce sujet l'article de SQLPro.

[Aedonya]

Re!
Merci beaucoup pour vos éclaircissements. J'ai fais quelques étourderies effectivement .

Comme il a déjà été dit, mettre une cardinalité maximale différente de 1 et entière n'apporte pas grand chose dans un MCD.

Sur ce point, je suis d'accord, dans mon cas cela n'apporte finallement pas grand chose. Mieux vaudra exprimer cette contrainte textuellement. D'ailleurs au niveau de l'implémentation, mieux vaut-il exprimer cette contrainte dans le code ou bien par un trigger dans la base ? Tu me diras tout dépend peut-être des évolutions éventuelles envisagées par le client. En l'occurence pour le projet, j'ai un texte de besoins exprimés assez succint et c'est à moi de préciser certaines règles de gestion.

Dans certains cas, ça pourrait exprimer une contrainte, par exemple qu'une instance d'une entité A ne puisse être associé au maximum qu'à deux instances d'une entité B.

Dans ton schéma, les cardinalités de l'association 'Est de catégorie' signifient qu'un type ne peut être au maximum associé qu'à 5 catégories et qu'une catégorie ne peut être associée au maximum qu'à 6 types. Je ne sais pas si c'est vraiment ce que tu veux exprimer.

Oui, comme un match de tennis en double par exemple ! La contrainte que je veux exprimer ne ressort pas de cette cardinalité puisque je voudrais que certains types ne puissent être rattachés qu'à 3 catégories sur les 5 qui sont censées exister. S'il doit exister un jour d'autres catégories, les types de véhicules pourront évidemment y être attachés et inversement et du coup cela remettrait en cause ces contraintes. Donc tu as tout à fait raison, c'est totalement inutile.

Dernier détail sur cette association : évite les cardinalités minimales à 1 des deux côtés, ça pose des problèmes à l'implémentation en BDD et c'est rarement nécessaire.

Un type de véhicule sera nécessairement rattaché à une (ou plusieurs) catégorie mais une catégorie peut n'être liée à aucun type ou à plusieurs type. La cardinalité est donc effectivement :

CATEGORIE --0,N-- est de catégorie --1,N-- TYPE

Par contre, pourrais-tu m'expliquer pourquoi cela pose des problèmes d'implémentation d'avoir des cardinalités minimum à 1 des deux côté d'une association ?

A la place de l'association 'location', j'aurais mis 'louer', un verbe comme dans toutes les autres associations.

Oui, tu as encore raison

D'après la cardinalité, un contrat peut être impliqué dans plusieurs locations. Est-ce vraiment le cas ? Il me semble plutôt qu'un contrat est en rapport avec une seule voiture pour un seul client et une seule agence.
J'aurais tendance à mettre 1,1 comme cardinalité du côté du contrat et 0,n sur les autres pattes de l'association 'louer' mais je sais que c'est contestable. A ce sujet, cette discussion peut te donner un éclairage.

Effectivement le contrat doit n'apparaître qu'une seule fois dans la relation louer.
Cet aspect du modèle m'a donné pas mal de fil à retordre.
J'ai tenté de faire les cardinalités comme tu me l'avais suggéré :
- 1,1 côté contrat,
- 1,N cote CLIENT car je pense qu'un client n'a rien à faire dans le système s'il n'a pas souscrit un contrat. De ce fait, au moment de la création d'un contrat, soit on crée un nouveau client soit on le rattache à un client déjà existant et qui a déjà loué un véhicule auparavant.
- 0,N sur les pates AGENCE et VEHICULE car un véhicule peut ne pas être loué et une agence ne pas avoir encore de contrat (si elle vient d'être créee par exemple, et c'est dans la logique de la responsabilité d'un véhicule)

Avec AnalyseSi cela ne passe pas : "Les cardinalités maximales des liens de l'association "louer" sont incorrectes ".

J'ai donc repensé l'association entière. Cela m'a donné le 1er shéma en PJ.

Comme je compte continuer avec Open ModelSphere, j'ai tenté le même schéma et il me l'accepte...

Association 'plein de' (que j'appellerais plutôt 'remplir') : Tu mélanges les carburants dans un plein ? ==> Cardinalité 1,1 du côté du plein me semble plus juste.

Et bien, je devais être drôlement fatiguée quand j'ai fais ce schéma !! Bien sûr que je ne mélange pas les carburants, sauf si je veux foutre en l'air le moteur ou si je met "huile de friture" comme carburant !!!

Détail général : pour les clés primaires, préférer un identifiant anonyme de type entier non nul non signé et auto-incrémenté plutôt qu'une clé candidate qui peut être modifiée par la suite.
Notamment, noImmatriculation, noPermis et type_vehic seront probablement de type alphanumérique et donc de mauvaises clés. Voir à ce sujet l'article de SQLPro.

Je te remercie pour le lien extrêmement intéressant sur les clés primaire.
Pour ce qui est des véhicules, l'immatriculation est désormais unique pour toute la vie d'un véhicule mais pour ceux qui n'ont pas encore cette immatriculation, il est vrai qu'elle peut changer, sans parler des immatriculations étrangères puisque la société de location du projet est une société internationale.
Pour ce qui est permis, même combat, mieux vaut effectivement une clé artificielle.
Enfin, pour le type de véhicule, par "typeVehicule" j'entendais "codeTypeVehicule" comme dans MODELE, CATEGORIE, CARBURANT, AGENCE. Je vais donc mettre des id artificiels sur toutes les tables.

bonjour,
juste pour l'emm#&@$¤ dans ce cas

Sinon j'ai pas bien compris cette histoire de cardinalités maxi à 5,6 dans ton cas particulier.
Categorie----0,n-----être----0,n-----type
par contre je verrais bien en plus :
Vehicule-----1,1----appartenir-----0,n------Categorie

Comme je l'ai dit plus haut à CinePhil, c'est inutile de mettre des contraintes de cardinalités maximale fixe. Pour ce qui est de ta proposition, voici un extrait du projet :
"Chaque véhicule appartient à un type (6 types sont répertoriés : camion, utilitaire, tourisme, 4x4, moto,scooter), et est classé dans une catégorie (Exemple : dans le type Tourisme, il existe 5 catégories (Economique, Standard, Gamme moyenne, haut de gamme, luxe, dans les utilitaires seules les 3 premières catégories existent)"
Un véhicule appartient donc forcément à un et un seul type, un type peut faire référence à plusieurs véhicules. Ensuite un type fait partie d'une ou plusieurs catégories mais une catégorie peut n'être liée à aucun type (pas de véhicule luxe à louer par exemple).

Je ne vois pas bien non plus l'intérêt de l'association 4-aire Location (qui devrait plutôt s'appeler 'Louer' d'ailleurs).
Un contrat concerne un client qui loue un véhicule à une agence non ?
Contrat---1,1---signer----0,n-----Client
Contrat---1,1---concerner----0,n----Vehicule
Contrat---1,1---situer----0,n---Agence

Je n'ai lu ton message qu'après avoir pondu mon nouveau MCD. Quand j'ai vu ta proposition, cela m'a un peu rassurée et je me suis demandée pourquoi j'étais allée chercher une telle association !
Par contre entre les 2 modèles en PJ (ma/ta solution) et celle proposée par CinePhil (1,1 cote contrat et 0,N sur les 3 autres branches), je trouve que cela veut dire la même chose mais peut-être que je me trompe. Est-ce juste une autre façon de modéliser ou cela aura-t-il un impact significatif pour la suite ? Ce que je vois e, tout cas, c'est que j'économise une table donc des jointures.

autre question, comment on sait où se trouve tel véhicule dans ta base puisque le véhicule peut être ramené dans n'importe quelle agence ?
Il y a bien une colonne 'agence retour' dans Contrat, il y a quoi dedans ? L'agence de retour du véhicule est prévu dans le contrat ?

voilou pour l'instant

Oui, la colonne agence_retour avait cet office mais avec le recul j'ai modifié cela autrement avec le contrat qui a un idAgence pour savoir de quelle agence le véhicule est parti et donc quelle agence a signé le contrat, quelle agence est censée recevoir le véhicule (ce qui va entrainer des majorations sur la facturation pour ceux qui n'auraient pas rendu le véhicule à l'endroit prévu initialement au contrat.

Je vous remercie infiniment tous les 2 de vos conseils, et suis prête à accepter et discuter toute nouvelle critique
Je met les 2 nouveaux MCD en PJ. Sachant que je pense opter pour les cardinalités "binaires" et non la relation 4-aire

[JPhi33]

Bonjour à tous,

Je pensais que le modèle devait se suffire à lui-même.

Oui, le modèle se suffit à lui-même. Tout dépend de ce qu'on entend par "modèle".

Le MCD est issu d'un énoncé ou d'un cahier des charges dans lequel figurent les contraintes et les règles de gestion. Donc, normalement, il n'y aurait pas besoin d'y ajouter quoi que ce soit.

Mais si on pousse le bouchon, on pourrait aussi ne rien modéliser du tout puisque toutes les propriétés, entités et associations figurent déjà de manière sous-jacente dans ledit énoncé ou cahier des charges... et on construirait directement la base de données à partir de celui-ci (le rêve, quoi !)

En conséquence, puisqu'on modélise, pourquoi se limiter à ce qui peut se représenter graphiquement ? Il faut accepter le fait que, en dépit des efforts considérables effectués ces 30 dernières années pour améliorer le modèle Entité-Association, tout ne peut pas encore se représenter graphiquement.

Donc, je maintiens qu'un modèle (MCD ou MLD) est consitué d'une partie graphique et, si besoin, d'une partie textuelle comprenant les contraintes et règles (statiques) non modélisables graphiquement. D'ailleurs, les logiciels de modélisation (comme PowerAMC) prévoient la possibilité de saisie de texte au niveau des entités, des association et des propriétés.

En cours, on n'avait jamais de texte accompagnant le MCD et les seules explications textuelles que l'on devait faire apparaitre concernaient l'expression des clés étrangères dans le MLD, la prof n'appréciant guère la notation avec le dièse (#).
D'ailleurs, j'ai une question à propos du MLD : AnalyseSi propose une version graphique assez simpliste du MLD (les clé étrangère ne sont pas vraiment explicites) mais nous avons appris à le faire sous forme de texte. Par exemple :

CARBURANT(CodeCarburant, TypeCarburant)
PLEIN(CodePlein, prixAuLitre, NbLitres, NoContrat)
PLEIN_DE(CodeCarburant,CodePlein)

Y-at-il une meilleure façon (graphique ou textuelle) de représenter le MLD ou est-ce juste une question de choix personnel ?

Quand on choisit une méthode de modélisation, on doit utiliser le formalisme qui va avec. Ainsi, si on choisit Merise, on réalise un MLD sous forme graphique.

La forme textuelle ci-dessus correspond au Modèle Relationnel dans lequel on ne distingue pas le conceptuel et le logique, il n'y a qu'un niveau de modélisation. Ce n'est pas moins bien que Merise, c'est différent -- bien que l'objectif soit le même, à savoir la construction d'une base de données cohérente avec le besoin exprimé.

[Aedonya]

Bonjour JPhi33,

En l'occurence, je travaille sur un énoncé partir duquel je dois rédiger le cahier des charges. Certaines règles de gestion sont imposées ainsi que la représentation de certaines informations, pour le reste c'est à moi de préciser certains points.
Les choses que je dois fournir sont :
- cahier des charges
- architecture générale du système
- quelques schémas d'écran ou formulaires
- en UML : use case, qualques diagrammes de séquence, diagrammes de classes
- schéma logique et schéma physique (sans précision de méthode Merise)
- requêtes de création des tables en SQL

Mais si on pousse le bouchon, on pourrait aussi ne rien modéliser du tout puisque toutes les propriétés, entités et associations figurent déjà de manière sous-jacente dans ledit énoncé ou cahier des charges... et on construirait directement la base de données à partir de celui-ci (le rêve, quoi !)

oui, c'est poussé le bouchon un peu loin . Je trouve que ces schémas sont extrêmement utiles pour cotruire la base justement sans trop y aller à taton. Le MCD, en tout cas pour ma part, sert à communiquer avec le client, le MLD à visualiser les tables et les liens qu'elles auront entre elles (ce qui n'intéresse guère le client je pense) et le MPD sert à créer véritablement les tables avec les contraintes et les types de champs.
Le fait d'avoir une représentation graphique est plus agréable que d'avoir un texte avec une sémentique parfois un peu ambigüe !

Quand à la présentation graphique du MLD en Merise, pour une prof "pro-Merise", c'est léger ce qu'elle nous a enseigné !!

En tout cas merci à tous pour votre aide, je crsois que je peux maintenant avancer dans le projet la conscience tranquille.

[CinePhil]

Comme il a déjà été dit, mettre une cardinalité maximale différente de 1 et entière n'apporte pas grand chose dans un MCD.

Sur ce point, je suis d'accord, dans mon cas cela n'apporte finallement pas grand chose. Mieux vaudra exprimer cette contrainte textuellement.

j'ai 6 types de véhicules (camion, utilitaire, tourisme, 4x4, moto, scooter) et 5 catégories (Eco, Standard, Moyenne gamme, Haut de gamme, Luxe).

Ce n'est pas une contrainte, c'est juste un fait actuel qui peut évoluer. Il n'est pas impossible qu'à l'avenir un nouveau type (bateau, vélo, avion, trotinette, hélicoptère, pousse-pousse ...) ou une nouvelle catégorie (Grand Luxe, Hors catégorie...) soit ajoutée.
Donc ici tu dois mettre une cardinalité maxi à n et il n'y a pas de contrainte autre que celle qui sera naturellement exprimée par l'association et qui voudra dire qu'un véhicule doit être d'un type figurant dans l'entité Type et qu'un type sera forcément associé à l'une des catégories figurant dans l'entité Catégorie.

La contrainte que je veux exprimer ne ressort pas de cette cardinalité puisque je voudrais que certains types ne puissent être rattachés qu'à 3 catégories sur les 5 qui sont censées exister.

Je ne vois pas bien l'utilité de cette contrainte mais éventuellement elle pourra faire l'objet d'un trigger ou d'une précédure incluse dans le programme utilisateur.

S'il doit exister un jour d'autres catégories, les types de véhicules pourront évidemment y être attachés et inversement et du coup cela remettrait en cause ces contraintes. Donc tu as tout à fait raison, c'est totalement inutile.

J'ai écrit trop vite, je vois que tu as compris.

Par contre, pourrais-tu m'expliquer pourquoi cela pose des problèmes d'implémentation d'avoir des cardinalités minimum à 1 des deux côté d'une association ?

Soit l'association suivante :
Commercial -1,n----Avoir----1,n- Contact
Je crée un commercial ; je dois en même temps lui attribuer un contact mais les aucun contact réel du commercial n'existe encore dans la BDD.
Je crée un contact pour un commercial que je viens d'embaucher et qui n'existe pas encore dans la BDD, je suis coincé aussi.
A l'implémentation, je serai donc obligé de créer une procédure spéciale pour créer en même temps le commercial et le contact.
Il est plus simple de se dire qu'un commercial existe indépendemment du contact et que le contact peut exister indépendemment du commercial et passer les cardinalités mini à 0. C'est suffisant dans l'écrasante majorité des cas.

J'ai tenté de faire les cardinalités comme tu me l'avais suggéré :
- 1,1 côté contrat,
- 1,N cote CLIENT car je pense qu'un client n'a rien à faire dans le système s'il n'a pas souscrit un contrat. De ce fait, au moment de la création d'un contrat, soit on crée un nouveau client soit on le rattache à un client déjà existant et qui a déjà loué un véhicule auparavant.

Et tu te retrouves avec la problématique que je viens d'expliquer.
Tu ne peux pas créer le contrat parce que le client n'existe pas et tu ne peux pas créer le client parce que le contrat n'existe pas.
Imaginons que le client soit une entreprise qui passe un marché à des tarifs préférentiels, il pourrait être enregistré en tant que client avant d'avoir effectué la moindre location. Donc 0,n du côté du client selon moi. Inutile de se compliquer la vie pour rien.

J'ai donc repensé l'association entière. Cela m'a donné le 1er shéma en PJ.

C'est mieux, à un détail près : quand tu crées le contrat, tu sais effectivement d'où part le véhicule mais tu ne sais pas a priori dans quelle agence il va revenir. Il m'est arrivé, pour un problème de denière minute, de devoir changer d'aéroport de retour lors d'un voyage professionnel en Alsace. J'ai pris le véhicule à Mulhouse et j'ai pris l'avion du retour à Strasbourg où j'ai déposé le véhicule. Donc cardinalité 0,1 car l'information sera connue à la clôture du contrat.
A moins de considérer que la valeur par défaut est identique au lieu de départ, ce qui nécessite un trigger.

Je vais donc mettre des id artificiels sur toutes les tables.

C'est une bonne résolution !
Euh... sauf sur les tables associatives bien sûr, donc la clé primaire est constituée des clés étrangères issues des clés primaires des tables entrant en jeu dans l'association.

Bon courage pour la suite.

[Aedonya]

Je ne vois pas bien l'utilité de cette contrainte mais éventuellement elle pourra faire l'objet d'un trigger ou d'une précédure incluse dans le programme utilisateur.

Moi non plus ! je trouve que cette contrainte est étrange quoi qu'un camion "luxe"... mais bon cela fait partie du sujet du projet alors...

Soit l'association suivante :
Commercial -1,n----Avoir----1,n- Contact
Je crée un commercial ; je dois en même temps lui attribuer un contact mais les aucun contact réel du commercial n'existe encore dans la BDD.
Je crée un contact pour un commercial que je viens d'embaucher et qui n'existe pas encore dans la BDD, je suis coincé aussi.
A l'implémentation, je serai donc obligé de créer une procédure spéciale pour créer en même temps le commercial et le contact.
Il est plus simple de se dire qu'un commercial existe indépendemment du contact et que le contact peut exister indépendemment du commercial et passer les cardinalités mini à 0. C'est suffisant dans l'écrasante majorité des cas.

Et tu te retrouves avec la problématique que je viens d'expliquer.
Tu ne peux pas créer le contrat parce que le client n'existe pas et tu ne peux pas créer le client parce que le contrat n'existe pas.
Imaginons que le client soit une entreprise qui passe un marché à des tarifs préférentiels, il pourrait être enregistré en tant que client avant d'avoir effectué la moindre location. Donc 0,n du côté du client selon moi. Inutile de se compliquer la vie pour rien.

Oui, je comprend mieux. C'est logique. Du coup c'est au niveau du programme que cela doit se passer. Pour l'utilisateur, le contrat et le nouveau client seront crées en même temps, c'est un artifice. Mais dans la base on aura d'abord un client crée puis un contrat rattaché à ce client.

La validation du formulaire de création de contrat entrainera une requête de création du client dans un premier temps puis la création du contrat avec la référence au nouveau client. Si le client a déjà loué alors seule une requête de création de contrat avec la référence vers le client sera exécutée. C'est bien ça ?

C'est mieux, à un détail près : quand tu crées le contrat, tu sais effectivement d'où part le véhicule mais tu ne sais pas a priori dans quelle agence il va revenir. Il m'est arrivé, pour un problème de denière minute, de devoir changer d'aéroport de retour lors d'un voyage professionnel en Alsace. J'ai pris le véhicule à Mulhouse et j'ai pris l'avion du retour à Strasbourg où j'ai déposé le véhicule. Donc cardinalité 0,1 car l'information sera connue à la clôture du contrat.
A moins de considérer que la valeur par défaut est identique au lieu de départ, ce qui nécessite un trigger.

J'avais déjà intégré cela mais je n'avais pas enregistré l'image ! oups !

C'est une bonne résolution !
Euh... sauf sur les tables associatives bien sûr, donc la clé primaire est constituée des clés étrangères issues des clés primaires des tables entrant en jeu dans l'association.

Evidemment !

Bon courage pour la suite.

Merci Merci

[CinePhil]

La validation du formulaire de création de contrat entrainera une requête de création du client dans un premier temps puis la création du contrat avec la référence au nouveau client. Si le client a déjà loué alors seule une requête de création de contrat avec la référence vers le client sera exécutée. C'est bien ça ?

Oui c'est ça.

[f-leb]

bonjour,

ça avance bien le MCD

"Chaque véhicule appartient à un type (6 types sont répertoriés : camion, utilitaire, tourisme, 4x4, moto,scooter), et est classé dans une catégorie (Exemple : dans le type Tourisme, il existe 5 catégories (Economique, Standard, Gamme moyenne, haut de gamme, luxe, dans les utilitaires seules les 3 premières catégories existent)"

chaque véhicule est aussi classé dans une catégorie donc:
véhicule----1,1----classer-----0,n------Catégorie

avec une contrainte (pas forcément représentable graphiquement sur un MCD) du type: La catégorie du véhicule est parmi celles comprises dans son type (euhh je suis clair là?)

Je vois en plus que d'après la ternaire 'tarif fixé", connaitre le type du véhicule ne suffit pas pour fixer tarifJournalier, il faut aussi sa catégorie.

[Aedonya]

bonjour,

ça avance bien le MCD

chaque véhicule est aussi classé dans une catégorie donc:
véhicule----1,1----classer-----0,n------Catégorie

avec une contrainte (pas forcément représentable graphiquement sur un MCD) du type: La catégorie du véhicule est parmi celles comprises dans son type (euhh je suis clair là?)

Oui tu as raison, je vois ce que tu veux dire pour la contrainte, j'étais partie sur une transitivité mais effectivement ça ne fonctionne pas . J'ai tenté une ternaire mais ça ne va pas non plus car je me retrouve avec une "table association" en MLD comme ça :
APPARTIENT(idCategorie,idType,idVehicule)
or, une véhicule dans cette table ne doit apparaître qu'une seule fois. Sur les forums, une ternaire 1-1,0-N,0-N n'étant pas recommandée, je suis partie sur une nouvelle table de couple de types et de catégorie, ce qui me donne le nouveau MCD en PJ. Il s'agira alors d'une sorte de table de paramétrage, sur laquelle l'utilisateur pourra créer les couples possibles de type/catégorie. Je trouve ça un peu compliqué mais j'ai ce que je souhaite au niveau du modèle logique. Cette table me sert du coup à affecter un véhicule à n'importe quel couple existant et elle me sert aussi pour les tarifs. Merci de m'avoir poussée à réfléchir à nouveau à ce point

Je vois en plus que d'après la ternaire 'tarif fixé", connaitre le type du véhicule ne suffit pas pour fixer tarifJournalier, il faut aussi sa catégorie.

C'est une question ? si oui, j'ai répondu juste avant . En fait, "le tarif de location journalier dépend du type du véhicule, de la catégorie et de l'agence où s'effectue la location."

[f-leb]

....Cette table me sert du coup à affecter un véhicule à n'importe quel couple existant et elle me sert aussi pour les tarifs. Merci de m'avoir poussée à réfléchir à nouveau à ce point

on ne se comprend pas ma faute je vais essayer d'être plus clair

Tu reprends la structure du post#12 qui vérifiait parfaitement tes règles de gestion:

Vehicule---1,1---est de type---0,n---Type---0,n---est de catégorie---0,n---Catégorie

mais tu rajoutes, en plus
véhicule----1,1----classer-----0,n------Catégorie

...Reste pour l'IHM, mais vu que j'avais déjà crée des tables sous Access ...

Sous Access donc. Comme l'animal ne gère pas les triggers, il te faudra passer par un formulaire qui te permets de rentrer du code évènementiel.
Du style un formulaire principal de source "véhicule" avec deux contrôles "listes déroulantes" ChoixType et ChoixCatégorie. Il est alors assez simple avec un peu de SQL+VBA de faire dépendre le contenu de ChoixCatégorie en fonction de ChoixType (si ChoixType=Utilitaire alors dans ta liste ChoixCatégorie tu ne pourra pas sélectionner "Luxe" puisque l'occurrence utilitaire-luxe n'existe pas dans l'association est de catégorie)

(pardon le forum, je sors un peu du cadre 'Schéma' là)

[Aedonya]

on ne se comprend pas ma faute je vais essayer d'être plus clair

Tu reprends la structure du post#12 qui vérifiait parfaitement tes règles de gestion:

Vehicule---1,1---est de type---0,n---Type---0,n---est de catégorie---0,n---Catégorie

mais tu rajoutes, en plus
véhicule----1,1----classer-----0,n------Catégorie


Sous Access donc. Comme l'animal ne gère pas les triggers, il te faudra passer par un formulaire qui te permets de rentrer du code évènementiel.
Du style un formulaire principal de source "véhicule" avec deux contrôles "listes déroulantes" ChoixType et ChoixCatégorie. Il est alors assez simple avec un peu de SQL+VBA de faire dépendre le contenu de ChoixCatégorie en fonction de ChoixType (si ChoixType=Utilitaire alors dans ta liste ChoixCatégorie tu ne pourra pas sélectionner "Luxe" puisque l'occurrence utilitaire-luxe n'existe pas dans l'association est de catégorie)

(pardon le forum, je sors un peu du cadre 'Schéma' là)

Je comprend mieux ce que tu veux dire mais je suis troublée car je croyais avoir trouvé la bonne solution. Je ne voudrais pas te vexer ou te contredire mais ce que tu me propose n'est-il pas similaire à ce que j'avais fais avec ma table de couples de type/catégorie ?

Il y a autant de tables en implémentation même si le MCD est un peu plus tordu. C'est peut-être un peu de la triche mais seul le MLD apparaitra dans le projet, pas le MCD.
Cependant, si tu penses que ta solution est plus correcte du point de vue de la modélisation,alors j'opterais pour celle là.

[f-leb]

Je ne voudrais pas te vexer ou te contredire...

me vexer moi? meuhh non voyons, il m'en faudrait plus quant à me contredire, j'ai pas la science infuse non plus heinça se saurait.

par contre, il y a un choix de modélisation assez subtil. Et je ne pense pas non plus que le choix d’une pseudo-entité CatégorieType soit nécessairement faux dans certains cas.

Je rappelle ton extrait d’énoncé :

"Chaque véhicule appartient à un type (6 types sont répertoriés : camion, utilitaire, tourisme, 4x4, moto,scooter), et est classé dans une catégorie (Exemple : dans le type Tourisme, il existe 5 catégories (Economique, Standard, Gamme moyenne, haut de gamme, luxe, dans les utilitaires seules les 3 premières catégories existent)"

Je ne suis donc pas sûr qu’une pseudo-entité « TypeCatégorie » soit plus avantageuse dans ton cas précis et rien à priori dans l’énoncé ne justifie son existence.

Une différence tout de même:
CatégorieType (id, #idType, #idCategorie) si je remplis des lignes de la table :
Id.....idType....... idCategorie
1.........1..................1
2.........1..................1
…
Ah ! je peux rentrer deux fois le couple (4x4+eco). Attention lors de la saisie.

je reprends l'association "associer_TypeCategorie" dans
Type---0,n---associer_TypeCategorie---0,n---Catégorie

Associer_TypeCategorie(#idType, #idCategorie) et je remplis les lignes
idType.......idCategorie
1....................1
1....................1
Ah non, la deuxième ligne ne peut être validée (doublon dans la clé primaire). Dans ce modèle, je ne peux pas saisir deux fois le couple (4x4+eco).

...C'est peut-être un peu de la triche mais seul le MLD apparaitra dans le projet, pas le MCD.

ça aussi c'est tordu C'est dans quel cadre ce projet ? C'est un vrai projet professionnel pour une agence de location où c'est un exercice d'étudiant ?

ouf, j'aurais bien quelques remarques aussi sur cette histoire de plein, de réservoir... mais passe moi une aspirine d'abord.

[Aedonya]

Je vais essayer de faire plus attention, je n'avais pas tilté que je pouvais entrer 2 fois le même couple !

ça aussi c'est tordu C'est dans quel cadre ce projet ? C'est un vrai projet professionnel pour une agence de location où c'est un exercice d'étudiant ?

C'est un projet de DUT

ouf, j'aurais bien quelques remarques aussi sur cette histoire de plein, de réservoir... mais passe moi une aspirine d'abord.

J'ai justement la boite d'aspirine à côté de moi ! Je t'en offre une volontiers et même deux !

Sur cette histoire de plein... Justement j'y suis aussi. Y'a un truc qui me chiffonne. J'ai voulu faire :
VEHICULE--1,1--utilise--0,N--CARBURANT--0,N--faire le plein--0,1--CONTRAT

AnalyseSI refuse cela "Les cardinalités maximales de l'association "faire le plein" sont incorrectes.
Peut-être que je me complique pour rien parce le sujet dit juste que si le client n'a pas fait le plein, l'agence le fait et note le montant pour le facturer au client. J'ai aussi l'information "montant carburant" figurer obligatoirement. Mais cela me semblait plus cohérent de modéliser le type de carburant avec le véhicule...

[Aedonya]

Sur cette histoire de plein... Justement j'y suis aussi. Y'a un truc qui me chiffonne. J'ai voulu faire :
VEHICULE--1,1--utilise--0,N--CARBURANT--0,N--faire le plein--0,1--CONTRAT

AnalyseSI refuse cela "Les cardinalités maximales de l'association "faire le plein" sont incorrectes.
Peut-être que je me complique pour rien parce le sujet dit juste que si le client n'a pas fait le plein, l'agence le fait et note le montant pour le facturer au client. J'ai aussi l'information "montant carburant" figurer obligatoirement. Mais cela me semblait plus cohérent de modéliser le type de carburant avec le véhicule...

En fait, si je met l'attribut nbLitres dans le contrat au lieu de le mettre sur l'association, ça passe. J'ai hésité à le mettre dans la facture mais comme c'est une constatation lors du retour du véhicule, j'ai préféré le mettre dans CONTRAT. Du coup lors du calcul du montantMajorationCarburant (FACTURE), je devrais regarder si l'idCarburant (clé étrangère dans CONTRAT) est renseigné. Si oui, on va chercher le prixAuLitre du carburant lié au contrat qu'on multiplie par le nombre de litre, sinon, le montantMajorationCarburant est égal à 0.

Un autre problème se poste pour faire le plein : cette association faire le plein n'impose en rien le type de carburant pour le véhicule loué dans le contrat.
Sinon, je pensais ! Si je met juste le nombre de litres dans le contrat avec une valeur par défaut à 0. Si cette valeur est supérieure à 0 alors dans la table VEHICULE je vais chercher l'id du carburant qui me fournit le prix au litre.