Discussion :

[LecGaël]

Bonjour,

Après un weekend end chargé, j'ai effectué les modifications concernant le MCD.
Et j'ai quelque questions.
MCD:

Je me retrouve donc avec une boucle au niveau de mon entité exemplaire.
et je me pose une question sur la cardinalité entre Exemplaire-----[1,1]-----Concerner-------[1,n]-------Location.
J'ai mis [1,1] mais je pense avoir mal réfléchit. En effet un exemplaire ne concerne qu'une et une seul location à un instant t (ou pas) mais au sein de la base, il y aura pas mal de location prévisionnelle et donc il vaudrait mieux mettre [1,n].
Que pensez vous du modèle ? J'ai même séparer l'entité Constructeur et Modele de mon Article

Concernant le planning ( en référence à mes premiers postes) est ce que vous auriez des conseilles concernant la gestion des dates ?
Pour l'instant je ne récupère que le nombre de dispo par jour et par appareil et je ne suis pas sur de la méthode.

[escartefigue]

Bonjour,

Très rapidement faute de temps, il faut modéliser

[EXEMPLAIRE] 0,n --- concerner --- 1,? [LOCATION]


Mini zéro coté exemplaire, car un exemplaire peut exister sans jamais avoir été loué (nouveau produit par exemple)
Maxi zéro car un exemplaire peut être loué successivement plusieurs fois

[LecGaël]

Mini zéro coté exemplaire, car un exemplaire peut exister sans jamais avoir été loué (nouveau produit par exemple)

Merci pour la nuance.

Maxi zéro car un exemplaire peut être loué successivement plusieurs fois

Minimum 0 et maxi 0 ? Je suis pas sur de saisir, plutôt n ?

[escartefigue]

R002a: Une Location concerne qu'un et un seul article à la fois
R002b : Un Article peut être concerné par 0 ou plusieurs locations

Du coup, vous confirmez qu'une location ne concerne qu'un seul article, mais qu'il peut y avoir plusieurs exemplaires de cet article (comme l'autorise votre MCD ?)
exemple : location de 5 multimètres => OK, location d'un multimètre et d'une perceuse => KO ?

[LecGaël]

Du coup, vous confirmez qu'une location ne concerne qu'un seul article, mais qu'il peut y avoir plusieurs exemplaires de cet article (comme l'autorise votre MCD ?)
exemple : location de 5 multimètres => OK, location d'un multimètre et d'une perceuse => KO ?

Absolument ! je le jure !

[LecGaël]

Bonjour à tous ,
Je sens que j'approche du but, j'ai rempli mes tables etc, j'ai modifié quelques requêtes et ça commence à ressembler à quelque chose.
J'ai cependant encore quelques questions concernant le point le plus important de mon projet.


Concernant le MCD:
J'aimerais faire un historique des locations: Est t'il préférable d'avoir un attribut BOOL "rendu" dans location permettant de filtrer les locations (normalement finies et rendues) pour faire un historique.
Ou alors un trigger qui stock les locations dans une autre table ?

Concernant le planning, est t'il possible en SQL de détecter les périodes de chevauchements de locations et le nombre d'exemplaire concerné afin de faire des réservations ?

Voici comment je procède actuellement:

Prenons le scénario : Un utilisateur consulte la page des multimètres, il veut en louer 3 exemplaires (sur les 5 ) du 30/06/2020 au 30/07/2020. Je voudrais dans un premier temps pouvoir "diriger" la sélection de l'utilisateur et donc récupérer les dates de dispos pour une location de 3 exemplaires. Ce serait à l'étape d'initialisation de la page.
Ensuite une fois la période saisie, je veux vérifier que celle-ci soit encore valable.
Donc pour l'instant je récupère la date de début et la date de fin. Je reconstruit un tableau de jours entre les deux. Pour chaque jours je fais une requête qui retourne le nombre d'exemplaire de disponible avec une validation, si ma requête retourne un tableau avec 3 éléments ce jour alors je continue sinon false => et je déroule la tambouille du "ladate n'est plus dispo RAFRAICHIT TA PAGE !.(Plus poliment bien évidemment )

Voila pour l'instant comment je déroule la logique, mais cela me parait lourd côté requête. Si un utilisateur sélectionne une période de 2 mois il faut balancer entre 60 et 62 requêtes (une par jour).

[escartefigue]

Merci pour la nuance.

Minimum 0 et maxi 0 ? Je suis pas sur de saisir, plutôt n ?

Bien sûr , j'aurais dû me relire

[LecGaël]

Bien sûr , j'aurais dû me relire

C'est surtout que vu mon niveau, je me suis dit, "C'est peut être une astuce de big boss"

[LecGaël]

Bonjour !

Après révisions du modèle avec le client:

Les règles:
R005a: Une Etagère se situe dans une et une seule Armoire.
R005b: Une Armoire contient 0 ou plusieurs Etagères

Ont changées en

R005a: Une Etagère se situe dans 0 ou plusieurs Armoires.
R005b: Une Armoire contient 0 ou plusieurs Etagères

En effet nous avons des noms d'étagères similaires d'une armoire à l'autre. Ce sont les règles du 5S.
Donc si je ne me trompe pas cela donne: Armoire------[0,n]------Avoir-------[0,n]-----Étagère.

Une relation [0,n] donne donc une table intermédiaire entre les deux qui va lier les id_etagere avec les id_armoire.
Pour l'instant je devrais avoir 30 étagères maximum dans ma table.

Qu'en pensez vous ? Est-ce dangereux de procéder de la sorte ?

Pour ce qui est de ma question concernant la gestion de mes requêtes SQL pour mon planning, devrais-je ouvrir un nouveau sujet dans la rubrique SQL ?

Bonne journée

===================================================================================================

EDIT:

===================================================================================================

Finalement ce que j'ai écris plus haut ne correspondait pas: il ne répond pas au besoin.
Il faut que je reste sur le fait qu'une étagère est une entité physique présente que dans une seule armoire en revanche les étagères peuvent avoir le même nom.
J'opterais donc pour une table d'association Position entre Etagères et Armoires pour faire la composition des différentes armoires avec les étagères mais au niveau MLD cette table aurait un id_unique qui sera associé à l'article en question.

Position

id_position

id_armoire

id_etagere

Je n'arrive pas a le modéliser en MCD avec JMerise.

Il y a eu du changement au niveau de mes règles des gestions également:

R001a: Un User peut Faire 1 à n Location(s)
R001b: Une Location est effectuée par un et un seul User

R002a: Un Article possède 0 à n Exemplaires.
R002b: Un Exemplaire concerne 1 et 1 seul Article.

R003a: Une Location concerne qu'un et un seul Exemplaire d'article à la fois
R003b : Un Exemplaire peut être concerné par 0 ou plusieurs locations


R004a: Un Article appartient à un seul Sous-ensemble
R004b : Un Sous-ensemble concerne un ou plusieurs Articles.

R005a: Un Article se situe sur une et une seule Etageres
R005b: Une Étagère "contient" 0 ou plusieurs Articles

R006a: Une Etagère se situe dans une et une seule Armoire.
R006b: Une Armoire contient 0 ou plusieurs Etagères

R007a: Une Location débute à un et un seul jours du Calendrier
R007b: Le Calendrier contient 0 ou plusieurs Locations.

R008a: Une Location finit à un seul jour du Calendrier.
R008b: Le Calendrier contient 0 ou plusieurs Locations.

Le but maintenant est d'avoir un planning individuel par exemplaire, un utilisateur doit pouvoir choisir l'exemplaire qu'il souhaite réserver, par contrainte technique (marge d’erreur de l'appareil qui doit rester la même, etc)

[escartefigue]

Bonjour LecGaël

Désolé pour mon manque de disponibilité, je reviens sur ce dernier message.

Il faut que je reste sur le fait qu'une étagère est une entité physique présente que dans une seule armoire en revanche les étagères peuvent avoir le même nom.

Tout à fait, c'est essentiel

J'opterais donc pour une table d'association Position entre Etagères et Armoires pour faire la composition des différentes armoires avec les étagères mais au niveau MLD cette table aurait un id_unique qui sera associé à l'article en question.

Inutile de se compliquer la vie. Il faut simplement considérer que l'étagère est ce qu'on appelle une entité-type faible : sans armoire, pas d'étagère.
Dans ce type de cas, on applique l'identification relative : l'identifiant de l'armoire contribue à identifier l'étagère

Au niveau du MCD ça se matérialise, selon le logiciel de modélisation par des parenthèses autour des cardinalités ou bien d'un R en suffixe de celles-ci.
Par exemple : ARMOIRE 0,n --- posseder --- 1,1R ETAGERE

Au niveau tabulaire, on trouve les tables suivantes (PK soulignées, FK suffixées #)
AR_ARMOIRE(AR_ident, AR_attribut1, AR_attribut2, ...)
ET_ETAGERE(AR_ident#, ET_ident, ET_attribut1, ET_attribut2...)
On constate que la PK de ET_etagere comporte comme première colonne la FK AR_ident


Par ailleurs, attention à ne pas renuméroter les règles de gestion (R005 est devenue R006), c'est un peu dangereux, on risque de s'y perdre : les précédents commentaires qui concernaient R005 concernent maintenant R006...
Si des règles obsolètes sont supprimées, ne réutilisez pas les numéros de règles, peu importe
Si de nouvelles règles surviennent, continuez en séquence la numérotation

Le but maintenant est d'avoir un planning individuel par exemplaire, un utilisateur doit pouvoir choisir l'exemplaire qu'il souhaite réserver, par contrainte technique (marge d’erreur de l'appareil qui doit rester la même, etc)

Ca signifie que les caractéristiques concernées ne sont pas des attributs de l'article, mais de l'exemplaire (si c'est potentiellement différent pour chaque exemplaire), ou qu'il faut créer des articles différents.
Ou encore, solution intermédiaire, créer des groupes de plages de caractéristiques et rattacher les exemplaires à ces groupes.


également

Du coup, vous confirmez qu'une location ne concerne qu'un seul article, mais qu'il peut y avoir plusieurs exemplaires de cet article (comme l'autorise votre MCD ?)
exemple : location de 5 multimètres => OK, location d'un multimètre et d'une perceuse => KO ?

Absolument ! je le jure !

R003a: Une Location concerne qu'un et un seul Exemplaire d'article à la fois
R003b : Un Exemplaire peut être concerné par 0 ou plusieurs locations

Cette règle de gestion est moins claire que ce qui ressort de nos échanges précédents, je propose la reformulation suivante :
R003a : une Location concerne 1 seul Article, pour un à plusieurs Exemplaires de cet Article.
R003b : un Exemplaire peut être concerné par 0 ou plusieurs Locations

[LecGaël]

Bonjour

Désolé pour mon manque de disponibilité, je reviens sur ce dernier message.

Pas de soucis, je me doutes que ce n'est pas une période facile, je poste au fur et a mesure de mes réflexions

Inutile de se compliquer la vie. Il faut simplement considérer que l'étagère est ce qu'on appelle une entité-type faible : sans armoire, pas d'étagère.
Dans ce type de cas, on applique l'identification relative : l'identifiant de l'armoire contribue à identifier l'étagère

Au niveau du MCD ça se matérialise, selon le logiciel de modélisation par des parenthèses autour des cardinalités ou bien d'un R en suffixe de celles-ci.
Par exemple : ARMOIRE 0,n --- posseder --- 1,1R ETAGERE

Au niveau tabulaire, on trouve les tables suivantes (PK soulignées, FK suffixées #)
AR_ARMOIRE(AR_ident, AR_attribut1, AR_attribut2, ...)
ET_ETAGERE(AR_ident#, ET_ident, ET_attribut1, ET_attribut2...)
On constate que la PK de ET_etagere comporte comme première colonne la FK AR_ident

Du fait que AR_ident#, ET_ident compose la "clef" primaire de l'entité Etagere ça assure donc qu'il n'y ai pas deux fois la même étagère dans une seule et même armoire ! Mais c'est génial et quand on y pense c'est super logique (Mais il faut y penser )
Je n'ai pas trouvé l'option sur JMerise pour modéliser ce type d'entité, je vais me pencher vers Looping.

Par ailleurs, attention à ne pas renuméroter les règles de gestion (R005 est devenue R006), c'est un peu dangereux, on risque de s'y perdre : les précédents commentaires qui concernaient R005 concernent maintenant R006...
Si des règles obsolètes sont supprimées, ne réutilisez pas les numéros de règles, peu importe
Si de nouvelles règles surviennent, continuez en séquence la numérotation

Je ferais attention dans le futur .

Ca signifie que les caractéristiques concernées ne sont pas des attributs de l'article, mais de l'exemplaire (si c'est potentiellement différent pour chaque exemplaire), ou qu'il faut créer des articles différents.
Ou encore, solution intermédiaire, créer des groupes de plages de caractéristiques et rattacher les exemplaires à ces groupes.

En fin de compte l'entité Article peut rester telle quelle je pense:
Exemple: L'article multimètre FLUKE, j'en possède trois exemplaires. l'article contient toujours de l'information sur l'exemplaire.
Finalement l'entité exemplaire contiendra juste une désignation_inventaire (une étiquette avec un numéro unique est collée sur l'appareil pour que l'opérateur ne se trompe pas lors de l'emprunt.)

Une légère modification de la règle R003a qui répondrait exactement à mon besoin:


R003a : une Location concerne 1 seul Article, pour un et un seul Exemplaires de cet Article.
R003b : un Exemplaire peut être concerné par 0 ou plusieurs Locations

On me demande qu'une location ne concerne qu'un seul article. Après j'ai du mal a faire la distinction entre ce que j'imagine côté IHM WEB/programmation et la base de données.
La façon de penser est bien différente parfois

EDIT

J'ai effectivement réussi avec Looping

En revanche je me pose la question de conserver l'entité Article , car finalement les association qui concerne l'entité Article peuvent très bien concerner les exemplaires de la mêmes façon.
Je peux très bien considérer les exemplaires comme des "Article" avec une désignation_inventaire unique (comme une seconde clef primaire).
Je manque de recul là ^^"

[escartefigue]

Du fait que AR_ident#, ET_ident compose la "clef" primaire de l'entité Etagere ça assure donc qu'il n'y ai pas deux fois la même étagère dans une seule et même armoire ! Mais c'est génial et quand on y pense c'est super logique (Mais il faut y penser )
Je n'ai pas trouvé l'option sur JMerise pour modéliser ce type d'entité, je vais me pencher vers Looping.

Avec looping, à partir du moment où la cardinalité est 1,1, une case à cocher "identifiant relatif" est proposée

Une légère modification de la règle R003a qui répondrait exactement à mon besoin:
R003a : une Location concerne 1 seul Article, pour un et un seul Exemplaires de cet Article.
R003b : un Exemplaire peut être concerné par 0 ou plusieurs Locations

On me demande qu'une location ne concerne qu'un seul article.

Du coup c'est en contradiction avec nos nos échanges n°24 et 25...

[LecGaël]

Du coup c'est en contradiction avec nos nos échanges n°24 et 25...

Oui j'ai présenté une maquette de mon outil ce matin et il y a eu beaucoup de remontés, de suggestions etc.
Et effectivement c'est une modification à faire.

===========================================
EDIT
===========================================

Pour symboliser ma question deux MCD fait avec looping.
Avec Article:


Sans Article:

[escartefigue]

Je ne vois aucune différence entre les deux MCD

[LecGaël]

Je ne vois aucune différence entre les deux MCD

C'est normal, c'est bibi qui est c**

J'ai modifié sur le post.

[escartefigue]

bonjour,

Quelques nouvelles (ou pas ) remarques


Cohérence entre les règles de gestion et les noms d'associations
Les verbes utilisés dans les règles de gestion doivent se retrouver dans les noms d'associations, sans quoi on s'y perd un peu
Par exemple, vous rédigez
R006a : Une Etagère se situe dans une et une seule Armoire.
R006b : Une Armoire contient 0 ou plusieurs Etagères
Et l'association s'appelle composer

à modifier ainsi :
R006a : Une Etagère est contenue dans une et une seule Armoire.
R006b : Une Armoire contient 0 ou plusieurs Etagères
et l'association devient "contenir"

Il n'est pas toujours facile de trouver des noms pertinents pour les assos. "etre" et "avoir" par exemple sont assez peu précis.
La bonne nouvelle est que les associations dont une patte au moins a une cardinalité maxi de 1 ne deviennent pas des tables, du coup on peut s'économiser l'effort de rechercher un nom parlant et laisser un nom laconique tel que "asso1", "asso2"...
Par contre ça ne vous autorise pas à oublier les règles de gestion de ces assos. Celles là comme les autres doivent être rédigées



Entités-type MODELE, ARTICLE et EXEMPLAIRE
Je pense que ce vous appelez MODELE est ce que j'avais compris comme étant l'article.
Auquel cas ces deux entité-type ne font qu'un en effet.



Entité-type ROLE
Il n'y a aucune règle de gestion concernant les rôles.
Un utilisateur peut il avoir plusieurs rôles, aucun rôle, changer de rôle ? à préciser



Association concerner
un utilisateur qui veut louer le même jour un multimètre et une perceuse devra donc souscrire deux contrats de location.
Pourquoi pas, mais à bien faire valider par vos experts métier.



Entité-type CATEGORIE
Il n'y a aucune règle de gestion concernant les catégories.
Que réprésente une catégorie ? S'agit il de modéliser des groupes de plages de caractéristiques comme je l'avais proposé hier (réponse n° 30) ?
Donnez des exemples de catégories pour plus de clarté.



Association localiser
La cardinalité 1,1 coté exemplaire ne va pas : quand un exemplaire est en location, il n'est sur aucune étagère
Profitez-en pour reformuler la règle R005 puisque l'article disparaît



Entité-type CONSTRUCTEUR
N'est-ce pas plutôt le fournisseur qui vous intéresse, voire les deux ?
Qu'est-ce que la date de création du constructeur ?



D'une façon générale, il y a très peu d'attributs dans les types d'entité, à compléter.

[LecGaël]

Bonjour

Cohérence entre les règles de gestion et les noms d'associations
Les verbes utilisés dans les règles de gestion doivent se retrouver dans les noms d'associations, sans quoi on s'y perd un peu
Par exemple, vous rédigez
R006a : Une Etagère se situe dans une et une seule Armoire.
R006b : Une Armoire contient 0 ou plusieurs Etagères
Et l'association s'appelle composer

à modifier ainsi :
R006a : Une Etagère est contenue dans une et une seule Armoire.
R006b : Une Armoire contient 0 ou plusieurs Etagères
et l'association devient "contenir"

Effectivement c'est mieux



Entités-type MODELE, ARTICLE et EXEMPLAIRE
Je pense que ce vous appelez MODELE est ce que j'avais compris comme étant l'article.
Auquel cas ces deux entité-type ne font qu'un en effet.
Oui c'est pour ça, en fin de compte modele contiendra les caractéristique de l'appareil finalement.

Entité-type ROLE
Il n'y a aucune règle de gestion concernant les rôles.
Un utilisateur peut il avoir plusieurs rôles, aucun rôle, changer de rôle ? à préciser

En effet j'ai oublié d'en parler, il s'agit juste de rôle pour le site en question:
R009a: Un Utilisateur possède un et un seul Rôle.
R009b: Un Rôle peut concerner 0 ou n Utilisateurs.

Il n'y aura que deux rôles, Admin et Utilisateur.

Entité-type CATEGORIE
Il n'y a aucune règle de gestion concernant les catégories.
Que réprésente une catégorie ? S'agit il de modéliser des groupes de plages de caractéristiques comme je l'avais proposé hier (réponse n° 30) ?
Donnez des exemples de catégories pour plus de clarté.

Oui il s'agit de former des groupes pour filtrer les recherches tels que , Multimètres, Enregistreurs,Oscilloscopes,Ordinateurs,...

Association concerner
un utilisateur qui veut louer le même jour un multimètre et une perceuse devra donc souscrire deux contrats de location.
Pourquoi pas, mais à bien faire valider par vos experts métier.

Cela est normalement validé.

Association localiser
La cardinalité 1,1 coté exemplaire ne va pas : quand un exemplaire est en location, il n'est sur aucune étagère
Profitez-en pour reformuler la règle R005 puisque l'article disparaît

La localisation sert uniquement pour trouver l'appareil lorsque l'on veut le réserver. Après on se retourne vers la personne qui l'a emprunté.

R005a: Un Exemplaire se situe sur une et une seule Etageres
R005b: Une Étagère "contient" 0 ou plusieurs Exemplaires

Entité-type CONSTRUCTEUR
N'est-ce pas plutôt le fournisseur qui vous intéresse, voire les deux ?
Qu'est-ce que la date de création du constructeur ?

La table Constructeur et Modele servent à avoir plus d'informations sur l'appareil à titre informatif, je pourrais rajouter des champs en fonctions des retours des agents. Pour ce qui est des fournisseurs il me faudrait plutôt rajouter une entité fournisseur associé avec l'entité exemplaire, imaginons que l'on change de fournisseur en cours de route, les appareils conservent le même constructeur. Je l'ai gardé dans un coin de ma tête pour l'instant car ma suggestion n'a pas fait suite

D'une façon générale, il y a très peu d'attributs dans les types d'entité, à compléter.

Effectivement, mais l'objectif est de faire un site de réservation assez simpliste en soit. J'espère juste arriver à avoir un modèle maintenable et ouvert à l'amélioration.

[escartefigue]

Cohérence entre les règles de gestion et les noms d'associations
Les verbes utilisés dans les règles de gestion doivent se retrouver dans les noms d'associations, sans quoi on s'y perd un peu
Par exemple, vous rédigez
R006a : Une Etagère se situe dans une et une seule Armoire.
R006b : Une Armoire contient 0 ou plusieurs Etagères
Et l'association s'appelle composer

à modifier ainsi :
R006a : Une Etagère est contenue dans une et une seule Armoire.
R006b : Une Armoire contient 0 ou plusieurs Etagères
et l'association devient "contenir"

Effectivement c'est mieux

[. . .]

La localisation sert uniquement pour trouver l'appareil lorsque l'on veut le réserver. Après on se retourne vers la personne qui l'a emprunté.

R005a: Un Exemplaire se situe sur une et une seule Etageres
R005b: Une Étagère "contient" 0 ou plusieurs Exemplaires

Oui mais non du coup , même combat ici : un même verbe à utiliser dans les deux sens de l'asso et dans le MCD
Un même verbe ne pouvant pas être utilisé pour deux asso distinctes
Et comme les règles de gestion doivent être le reflet de la stricte vérité, on doit bien avoir
R005a: Un Exemplaire est localisé sur zéro à une Etagere
R005b: Sur une Étagère sont localisés 0 à plusieurs Exemplaires

[LecGaël]

Oui mais non du coup , même combat ici : un même verbe à utiliser dans les deux sens de l'asso et dans le MCD
Un même verbe ne pouvant pas être utilisé pour deux asso distinctes
Et comme les règles de gestion doivent être le reflet de la stricte vérité, on doit bien avoir
R005a: Un Exemplaire est localisé sur zéro à une Etagere
R005b: Sur une Étagère sont localisés 0 à plusieurs Exemplaires

Merci il faut que je m'y fasse

[LecGaël]

Bonjour,

Je reviens sur le topic pour vous remercier et vous dire que j'avais finis ce projet .
Merci pour votre aide et peut être à bientôt.