Discussion :

[shimomura22]

Bonjour à tous
Voici l'énoncé de mon problème .
Bien-sûr je ne demande pas de solutions toutes faites mais un avis sur mon travail, sur la manière de l’améliorer et sur les erreurs que j'ai commis ( en espérant qu'il n'y en ait pas mais bon

L’entreprise propriétaire d’une chaîne de parkings souhaite proposer au public des réservations d’emplacement dans ses parkings situés dans le monde entier. Selon les parkings, les formules de prix (par heure, par jour, remise longue durée, abonnement), le nombre d’emplacements et d’étages sont différents.


1
J'ai déjà réaliser un cahier de charge dans lequel j'ai défini mes règles mais il n'est pas encore finalisé je peux le partager si le besoin s'en fait sentir
Voici donc le fruit de mon dur labeur
En espérant cette fois-ci être dans le bon forum
Je suis à l'étape du modèle entité association




Voici les points dont je ne suis pas satisfait

• La relation parking et adresse ... Un parking a une adresse mais je me demande si ce n'est pas mieux d'ajouter un champ adresse à l'entité parking ????
• Est-ce que je dois relier le client a l'adresse de facturation ???

Voilà pour l'instant les points qui me
Et bien-sûr mon point faible les cardinalités

Merci d'avance

[footsteps]

Bonjour. J'ai survolé seulement.

Personne 0 1 / habiter / 1 n Adresse 1 n / posséder / 1 1 Facture
La facture est reliée au client.
A condition bien sûr d'interroger le client du projet pour qu'il confirme : je parle des minima 0 1 ou 1 1 etc...

Pour l'entreprise , tu es sûr qu'il n'y en qu'une? Il faudrait une entité à part.

Pour les cardinalités c'est mini/maxi : essaie de formuler , je prends l'exemple Adresse/Facture cela donne ici :une ou plusieurs adresses sont 'possédées' par 1 facture _ 1 facture possède 1 et une seule facture.
Bonne continuation

[Gannox]

Bonjour,

Après avoir regardé juste une dizaine de minutes, j'aurais quelques remarques :

- Pourquoi faire une entité ADRESSE et ADRESSE DE FACTURATION ? Il serait préférable de mettre les informations d'adresse directement dans chaque entité correspondante non ? C'est en tout cas ce que j'ai vu dans cette page de cours : http://ineumann.developpez.com/tutor...iation-merise/
- Un abonnement n'a pas de date de fin ?
- Pour la cardinalité 0,N (à gauche) de RESERVATION à EMPLACEMENT, cela signifie qu'une réservation existante peut concerner 0 emplacements ? C'est pas plutôt 1,N ?
- Je mettrais les caractéristiques de HORAIRE dans ABONNEMENT et je supprimerais HORAIRE

[shimomura22]

Bonjour et merci d'avoir pris le temps de me répondre
J'ai corrigé le schéma en fonction de vos remarques
Pour l'entité Client et son adresse. Je propose une nouvelle solution qui j’espère sera plus optimale.

Je mettrais les caractéristiques de HORAIRE dans ABONNEMENT et je supprimerais HORAIRE

J'ai supprimé l'horaire car je me suis dit que je n'en voyais pas l'utilité car le parking sera ouvert 24/24 et 7/7

Pour la cardinalité 0,N (à gauche) de RESERVATION à EMPLACEMENT, cela signifie qu'une réservation existante peut concerner 0 emplacements ? C'est pas plutôt 1,N ?

Merci pour ta correction, je l'ai modifié dans mon schéma

Un abonnement n'a pas de date de fin ?

La date de fin n'est pas présente car le client choisira sa période d'abonnement qui implicitement sera la date de fin et il aura aussi le choix de résilier son abonnement



Merci encore et n'hésiter à me donner votre avis

[Gannox]

J'ai fais quelques recherches et j'ai vu qu'il était préférable de ne pas créer d'entité ADRESSE et de mettre toutes les informations relatives à cette entité dans CLIENT. Mais bon, c'est sans doute laissé à l'appréciation du sujet.

S'il existe plusieurs types d'abonnement, peut-on externaliser l'information du type d'abonnement dans une entité TYPE (avec id et libellé) car c'est une liste finie de valeurs possibles je suppose ?

Enfin, je me trompe peut-être mais je ne vois vraiment pas l'intérêt de l'association entre EMPLACEMENT et ABONNEMENT. L'entité RESERVATION se charge déjà des réservations non ? Il faudrait définir précisément les finalités de ces 2 entités, dire si un abonnement concerne une place ou un parking ou si c'est juste une information secondaire n'ayant pas de lien direct avec une place précise ou un parking précis. Si tu gardes cette association, tu peux la passer en 1,N comme pour RESERVATION car un abonnement ne concerne pas 0 emplacements je pense.

Tant que j'y suis, on a 1,1 de l'autre côté pour les deux cas, mais est-ce que ton sujet spécifie qu'un emplacement peut être libre et donc ne faire l'objet d'aucune réservation pour le moment ? Pareil avec un abonnement ?

[shimomura22]

Bonjour Gannox
Merci pour tes conseils, ils ont ouvert mes chakras

Enfin, je me trompe peut-être mais je ne vois vraiment pas l'intérêt de l'association entre EMPLACEMENT et ABONNEMENT.

Maintenant que tu me le fait remarquer c'est évident qu'il n'y a pas de lien entre abonnement et emplacement car le client qui prend un abonnement à le droit de se garer dans le parking où bon lui semble et non à un emplacement bien défini
Que pense-tu de lier l'abonnement à un parking ?? Par là je veux dire que le client qui prend un abonnement "s'abonne" à un parking et à l'intérieur de celui-ci peut se garer sur n'importe quel emplacement
Dans les cardinalités ça donnera ceci :

• Client 0-N possède 1-1 abonnement. Donc un client possède de 0 à N abonnement car il peut avoir plusieurs abonnements mais dans des parkings différents Et un abonnement est la propriété d'une seule personne
• Abonnement 1-1 pour 0-N parking. Donc un abonnement est pour un parking et dans un parking on peut retrouver plusieurs abonnements mais pas de la même personne

Tant que j'y suis, on a 1,1 de l'autre côté pour les deux cas, mais est-ce que ton sujet spécifie qu'un emplacement peut être libre et donc ne faire l'objet d'aucune réservation pour le moment ? Pareil avec un abonnement ?

Oui un emplacement peut être libre, car tu m'as fait remarquer que les abonnés ne s'abonnent pas pour un emplacement mais pour un parking

S'il existe plusieurs types d'abonnement, peut-on externaliser l'information du type d'abonnement dans une entité TYPE (avec id et libellé) car c'est une liste finie de valeurs possibles je suppose ?

Oui l'abonnement a plusieurs types, je voulais externaliser aussi les infos mais je ne voyais pas quoi mettre dans l'entité Abonnement à part son ID,
Que penses-tu de mettre dans l'entité Abonnement les infos suivantes :

• IdAbonnement
• Date de début

et dans l'entité type les informations statiques :

• IdType
• Prix
• Période => le temps que coure l'abonnement (20 jours, 45 jours etc....)
• Libelle

Merci encore, je corrige et poste les corrections

[shimomura22]

Bonjour
Voilà un corrigé de mon schéma..
Comme toujours n'hésitez pas à le critiquer car la critique me permet d'aller de l'avant

[escartefigue]

Bonjour,

Pour les adresses, il est préférable de ne créer qu'une seule relation entre client et adresse et de typer les adresses

client 0,n---- posseder --- 1,1 adresse

La relation posséder héritera d'un type adresse issu d'une entité-type "type adresse" (qui vous fournira le libellé correspondant) elle aussi en lien avec la relation "posseder"
Vous pouvez également ajouter des attributs date de validité (début, fin) dans la relation posséder

En procédant ainsi, vous pouvez avoir autant de types adresse que souhaité, et gérer les adresses à date

[shimomura22]

Merci escartefigue !!!
tu viens de résoudre mon problème d'adresses rien n'est plus efficace que la simplicité j'ai corrigé mon schéma mais plus j'avance plus il y a d'obstacles.
J'ai encore un problème concernant la facture. Les connectivités autour de Facture telles qu’elles sont dessinées signifient qu' une facture concerne une ou plusieurs réservations et un ou plusieurs abonnement. Mais j'aimerai améliorer cela car une facture ne concerne que soit une réservation ou un abonnement et que les associations ternaire ne sont pas recommandé. Pour le moment mon schéma ressemble à ça




Est ce qu'il est aussi préférable de donner un type à la facture comme pour l'adresse ??
Ou ne pas mettre de relation entre facture/abonnement/Réservation??
Ou une autre solution ??

[Gannox]

Tu as remis en 0,N la cardinalité de RESERVATION on dirait

Je viens de constater quelque chose à propos de RESERVATION et EMPLACEMENT :
- Déjà tu dis qu'un emplacement correspond à une et une seule réservation, bah pas forcément, d'une manière logique, on peut très bien avoir pour une place donnée une réservation pour la matinée d'une personne et une autre réservation pour l'après-midi d'une autre personne dans la même journée
- Une idée pour l'historique : ajouter un attribut date et tarif directement dans l'association "est pour", comme ça tu auras l'id reserv, l'id place, la période de réservation, le tarif associé pour une telle réservation (c'est une ébauche d'idée, à vérifier)
- Pour une réservation, il faut qu'on connaisse l'id de la place mais aussi l'id du parking en question sinon on ne sait pas à quel parking il se réfère ?

[shimomura22]

Je te remercie pour le temps que tu m'accordes. Je vais améliorer mon travail grâce à tes remarques et je t'en suis reconnaissant.

[escartefigue]

Il y a pas mal de boucles dans le MCD,

Avant de se demander comment les résoudre, il faut d'abord corriger les choses qui ne semblent pas cohérentes avec le prédicat du début, par exemple est il normal de ne facturer que les réservations, ne peut on pas utiliser un parking sans réserver