Bonsoir bangaromaric,
Envoyé par
bangaromaric
sur mon AGL jMerise je trouve pas la clé <ai> mais c'est pas bien grave vais trouver un moyen de l'insérer
Vous pouvez effectivement le faire manuellement au stade du code SQL (clause UNIQUE dans l’instruction CREATE TABLE), le tout est de ne pas oublier de le faire...
Envoyé par
bangaromaric
Lorsque j écris une règle de gestion entre deux entités est ce que je suis obligé de faire un vas et viens ex: "un permis peux être utilisé par plusieurs clients et un client utilise un seul ou plusieurs permis " permis (0,n)-----utiliser-----(1,n) client.
Oui. Il faut effectivement préciser la règle côté PERMIS et côté CLIENT :
(R1) Un permis peut être utilisé par plusieurs clients ;
(R2) Un client utilise au moins un permis.
Cela dit, par permis vous sous-entendez manifestement catégorie de permis. Pour lever toute ambiguïté , il faudrait renommer l’entité-type PERMIS en CATEGORIE_PERMIS (ou TYPE_PERMIS) , donc reformuler les règles, par exemple :
(R1) Une catégorie de permis peut être utilisée par plusieurs clients ;
(R2) Un client rentre dans au moins une catégorie de permis.
Autre remarque : La patte connectant l’entité-type CLIENT et l’association POSSEDER est porteuse d’une cardinalité 1,N : si un client n’a pas de permis, il ne peut donc pas louer de voiture, même s’il propose de passer par les services d’un chauffeur ?
Envoyé par
bangaromaric
Et pour facture et réservation pourquoi ne pas dire: une réservation donne lieu à une facture (facturation) et une facture peux être donnée par une réservation.
Vous pouvez bien sûr formuler ces deux règles ainsi. Simplement, il faudra ensuite attirer l’attention du lecteur sur le fait que cette réservation est faite par le client qui règle la facture. En l’occurrence, je fais référence à ce que avez écrit dans votre 1er message :
« Le client à la possibilité de faire une réservation ou de directement louer une voiture »
Là encore, il s’agit de faire attention aux ambiguïtés inhérentes à la rédaction et les MCD doivent permettre de pallier.
Envoyé par
bangaromaric
Et l entité-type historique pas besoin de règle de gestion
Si elle n’entretient aucune relation avec les autres entités-types, il suffit effectivement d’expliquer son rôle, d’expliquer et justifier ses attributs.
Partager