Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre du Club
    Réservation de matériel , gestion de période et de quantité.
    Bonjour à tous,

    Je suis actuellement en train de développer un site pour le boulot.

    contexte:Je travaille dans un bureau d'électrotech, et jusqu’à présent on a un vieux fichier Excel ou chacun rentre la date à laquelle il loue un multimètre (par exemple) et la date à laquelle il va le retourner et on a autant de ligne que l'on a de multimètre.

    objectif :Faire un site de réservation d'article au sein de l'équipe.

    Je dois pouvoir permettre aux collègues de louer un article via un planning de cette manière on aura plus de visibilité sur les locations.
    [B]
    Modélisation de ma base:
    Je suis sur une base MySQL version 10.4.10-MariaDB.

    Le problème est le suivant: Ma table location comprend une date_debut, une date_fin et une quantite.
    La première problématique était d'avoir la quantite par jour et par article. J'ai donc cherché et j'ai fait une table calendrier qui regroupe tous les jours de janvier 2020 à janvier 2050.
    Et pour avoir la quantite par jour et par article j'ai fait cette requête:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT calendrier.Jour,SUM(location.quantite) AS quantite,article.quantiteStock FROM `location` INNER JOIN article ON location.id_article = article.id CROSS JOIN calendrier WHERE calendrier.jour BETWEEN location.date_debut AND location.date_fin GROUP BY calendrier.Jour
    Je récupère bien la quantité loué par jour et par Article en l’occurrence ici je n'avais qu'un article.
    On peut voir dans le MCD que j'ai un champ quantiteStock dans la table Article.
    J'aimerais pouvoir générer la quantité de disponible par jour en fonction de la quantité loué et la quantité en stock.

    L'objectif final serait de pouvoir "alimenter" ce fameux calendrier sur la page de l'article concerné et de pouvoir bloquer les dates auxquelles la quantité disponible est à 0.

    Voila je vous ai exposé mon travail, si jamais vous avez des conseils d'amélioration concernant la modélisation ou autre, je suis ouvert, je n'ai jamais eu a gérer ce genre de problème avec des périodes de temps etc.
    Merci d'avance et bonne journée

  2. #2
    Rédacteur

    beaucoup d'erreur :
    1) l'entité Calendrier doit être liée l'entité location avec comme association "débute" en 1,1 / 0,n et "termine" en 0,1 / 0,n. Il faudra donc supprimer les deux dates date_debut et date_fin
    2) déterminez au plus juste vos VARCHAR et ne pas mettre 50 partout. Ce sera trop long ou trop court
    3) un code postal n'est pas un nombre, mais une chaine de caractère. Voir extrait de mon livre (à paraître) ci-dessous pour explication...
    4) une quantité doit être décimale. Sinon, lorsque vous allez à la pompe prendre de l'essence et que votre réservoir est plein, l'essence continuera de couler sur vos chaussettes si le remplissage du réservoir ne coïncide pas pile poil avec un nombre de litre !
    5) un email peut attendre 257 caractères.
    Un code postale n'est

    ce n'est que le début !



    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  3. #3
    Modérateur

    bonjour

    Vous pouvez essayer ceci :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    SELECT 
    		calendrier.Jour
    		,article.quantiteStock - COALESCE(SUM(location.quantite) , 0 ) AS quantiteDispo
    FROM calendrier
    LEFT JOIN `location`
    	ON	calendrier.jour BETWEEN location.date_debut AND location.date_fin
    LEFT JOIN article ON location.id_article = article.id 
    GROUP BY calendrier.Jour, article.id

  4. #4
    Membre du Club
    1) l'entité Calendrier doit être liée l'entité location avec comme association "débute" en 1,1 / 0,n et "termine" en 0,1 / 0,n. Il faudra donc supprimer les deux dates date_debut et date_fin
    J'ai modifié la structure comme vous me l'avez conseillé, en revanche, une location débute en 1,1/0,n mais se termine en 1,1/0,n ?
    2) déterminez au plus juste vos VARCHAR et ne pas mettre 50 partout. Ce sera trop long ou trop court
    Pour l'instant c'est la version 1 de la BDD et du site, effectivement il y a des trous dans le CDD, je dois faire un site "maquette" avant de me lancer dans le développement à proprement parlé.
    3) un code postal n'est pas un nombre, mais une chaine de caractère. Voir extrait de mon livre (à paraître) ci-dessous pour explication...
    Je vais aller lire ces extraits.
    4) une quantité doit être décimale. Sinon, lorsque vous allez à la pompe prendre de l'essence et que votre réservoir est plein, l'essence continuera de couler sur vos chaussettes si le remplissage du réservoir ne coïncide pas pile poil avec un nombre de litre !
    Je viens de le prendre en compte d'ailleurs la requête suivante :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    SELECT article.id AS id_article,
                calendrier.Jour,SUM(location.quantite) AS quantite,
                article.quantiteStock 
                FROM `location` INNER JOIN article ON location.id_article = article.id 
                CROSS JOIN calendrier 
                WHERE article.id = '31' AND calendrier.jour BETWEEN location.date_debut 
                AND location.date_fin AND quantite < quantiteStock GROUP BY calendrier.Jour
    Me retourne une ligne de donnée avec quantite = 4 et quantiteStock = 3, cette ligne ne devrait pas apparaitre, quand j'ai lu ce quatrième point je me suis dit que c'était la cause du problème.
    Hélas non j'ai toujours une erreur.

    ce n'est que le début !
    Effectivement

    Merci pour votre réponse et vos conseils.

    aieeeuuuuu Je viens de voir votre réponse , j'ai testé cette requête effectivement elle remplie bien mes attentes, je vais la décortiquer pour la comprendre, merci

  5. #5
    Membre du Club
    Bonjour,

    J'ai pris note des conseils que vous m'avez fait, et je voulais savoir si il était possible de limiter le nombre de locations par article sur une même période.
    Explication: Un article => Ordinateur D720 , quantiteStock = 3. Je ne veux pas que ce pc soit loué 4 fois sur une même période. Donc prendre en compte les overlaps etc.
    J'avais pensé au trigger mais ça va vite devenir une usine à gaz non ?

    Merci d'avance

  6. #6
    Rédacteur

    Deux possibilités :
    • par contraintes : dans ce cas rajouter un identifiant relatif de location dont le domaine va de 1 à 4 (donc une contrainte de domaine CHECK + une contrainte d'unicité)
    • par déclencheur (moins performant)



    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  7. #7
    Membre du Club
    Je vais creuser ces solutions, enfin je vais d'abord commencer par me renseigner sur les contraintes.
    Merci

  8. #8
    Expert éminent sénior
    Bonjour,

    Avant de vous intéresser aux contraintes, il faut construire un modèle cohérent, les contraintes en dépendent.
    Or, votre type d'entité "ARTICLE" est aberrant.
    Que vient faire la notion d'étagère et d'armoire ici ?
    Le constructeur (ou plus probablement le fournisseur) doit être externalisé dans une autre entité-type en lien avec l'article
    Qu'est ce que l'identification ?
    Si le stock est enregistré par localisation (magasin, dépôt, rayon...) alors elle n'a rien à faire ici non plus
    Si la quantité peut être décimale (fréquent pour les poids et volumes) alors il faut un type decimal.

  9. #9
    Membre du Club
    Bon,jour ,

    Que vient faire la notion d'étagère et d'armoire ici ?

    Tous cela je l'ai retiré, ce sera juste des relations avec d'autres tables.

    La clef de mon problème réside dans la gestion des locations(réservations des articles) et leur disponibilité.
    Ce qui gravite autour n'est là que pour rajouter de l'information. Ce sera un site web d'équipe utilisé par 30 à 60 personnes.

  10. #10
    Membre du Club
    Bonjour,

    Je reviens vers vous avec un MCD un peu plus fourni.
    Tout d'abord, je vais refaire un résumé de ce que je souhaite faire.
    Au bureau on a plusieurs étagères avec du matos que l'on peut emprunter.
    Mon objectif est de faire le suivit de ces emprunts et de faire un planning de réservations.
    Là ou je bloque et c'est peu dire c'est sur ce planning.
    Lorsque quelqu'un emprunte un Article, il peut en emprunter 1 ou bien 2 jusqu’a la quantité en stock de l'article (si ils sont tous dispos).
    A terme il faut que je puisse permettre aux collègues de sélectionner une quantité souhaitée, de générer un calendrier ou sont affichés les dates et période de dispo pour cette quantité afin de restreindre la saisie.
    Il faut aussi que je puisse effectuer des requêtes de contrôle pour m'assurer que la période qui a été choisie soit bien valide côté base de données. (si quelqu'un n'a pas rechargé la page et qu'il réserve sur un période qui vient justement d'être occupée.

    Jusque l'à j'ai essayé de m'inspirer de cet article sur dvp :https://denishulo.developpez.com/tutoriels/access/generer-disponibilite-materiel/


    MCD



    Règles de gestions:

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

    R002a: Une Location concerne qu'un et un seul article à la fois
    R002b : Un Article peut être concerné par 0 ou plusieurs locations
    Je ne sais pas si c'est la bonne méthode, sachant que un User peut faire une location concernant un article => PC DELL 720 mais en prendre 3 => quantite =3

    R003a: Un Article appartient à un seul Sous-ensemble
    R003b : Un Sous-ensemble concerne un ou plusieurs Articles.

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

    R005a: Une Etagère se situe dans une et une seule Armoire. Je ne sais pas ce que vous en pensez, mais ça me parait logique.
    R005b: Une Armoire contient 0 ou plusieurs Etagères

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

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

    Comme vous pouvez le voir les deux dernières règles sont bancales, tout bonnement, j'ai du mal à gérer cela.
    Concernant la table Article, je sais que je devrais avoir une table constructeur ainsi qu'une table Modèles, ça peut être fait après je pense sachant que ce ne sera que de l'information basique.
    Voilà Si vous avez une fois de plus du temps à me consacrer
    Bonne journée,

  11. #11
    Expert éminent sénior
    bonjour,

    Tout d'abord, les questions concernant la modélisation des données devraient être posées dans le forum consacré qui se trouve ici :
    https://www.developpez.net/forums/f6...sation/schema/
    Un modérateur fera sans doute le nécessaire pour déplacer cette discussion

    Ensuite, quelques remarques

    Entité-type USER
    Si l'attribut "CP" est un code postal, il n'a en principe rien à faire ici et son type devrait être char(5).
    que représente l'attribut "actif" suspect lui aussi. L'activité ou inactivité d'une utilisateur devrait être la conséquence de son historique de connexion ou de location par exemple.
    Donc à calculer quand nécessaire.


    Entité-type LOCATION
    D'après votre modèle, la location a plusieurs dates de début et de fin
    Supprimez les deux associations et créez deux attributs date dans l'entité-type


    Entité-type ARTICLE
    Comme indiqué précédemment, le constructeur ne devrait pas être un attribut enregistré ici, mais être une modélisé par une association entre article et fabricant ou fournisseur
    ARTICLE 1,n --- fabriquer --- 0,n FABRICANT
    Il y a confusion entre l'exemplaire de l'article (ayant son numéro de série unique) et l'article (au sens modèle, identifié par une référence commune à tous les exemplaires)
    Si tous les articles sont comptés à la pièce, alors le stock c'est le nombre d'exemplaires, mais si certains articles sont comptabilisés au litre, au kilogramme ou autre, alors la quantité en stock doit être calculée par la somme des quantités situées sur chaque étagère de chaque armoire. Il faut en ce cas également prévoir une entité-type "unité de mesure" en lien avec l'article.

  12. #12
    Membre du Club
    Tout d'abord, les questions concernant la modélisation des données devraient être posées dans le forum consacré qui se trouve ici :
    https://www.developpez.net/forums/f6...sation/schema/
    Un modérateur fera sans doute le nécessaire pour déplacer cette discussion
    Effectivement

    Ensuite, quelques remarques

    Entité-type USER
    Si l'attribut "CP" est un code postal, il n'a en principe rien à faire ici et son type devrait être char(5).
    que représente l'attribut "actif" suspect lui aussi. L'activité ou inactivité d'une utilisateur devrait être la conséquence de son historique de connexion ou de location par exemple.
    Donc à calculer quand nécessaire.
    Alors , pour ce qui est du CP, c'est le code personnel propre à chaque employé il est constitué de 7 chiffres et une lettre.
    Pour ce qui est de actif, c'est un booléen qui est modifié par l'admin du site, pour valider l'utilisateur.
    Quand un User s'inscris il n'est pas automatiquement "validé"

    Entité-type LOCATION
    D'après votre modèle, la location a plusieurs dates de début et de fin
    Supprimez les deux associations et créez deux attributs date dans l'entité-type
    Erf c'est ce que j'avais fait sur le premier MCD ^^"


    Entité-type ARTICLE
    Comme indiqué précédemment, le constructeur ne devrait pas être un attribut enregistré ici, mais être une modélisé par une association entre article et fabricant ou fournisseur
    ARTICLE 1,n --- fabriquer --- 0,n FABRICANT
    Il y a confusion entre l'exemplaire de l'article (ayant son numéro de série unique) et l'article (au sens modèle, identifié par une référence commune à tous les exemplaires)
    Si tous les articles sont comptés à la pièce, alors le stock c'est le nombre d'exemplaires, mais si certains articles sont comptabilisés au litre, au kilogramme ou autre, alors la quantité en stock doit être calculée par la somme des quantités situées sur chaque étagère de chaque armoire. Il faut en ce cas également prévoir une entité-type "unité de mesure" en lien avec l'article.
    C'est ce que j'ai précisé en fin du dernier post, c'est effectivement ce que je ferais, mais vu que le problème n'est pas là


    Merci pour votre attention

  13. #13
    Expert éminent sénior
    Citation Envoyé par LecGaël Voir le message
    Alors , pour ce qui est du CP, c'est le code personnel propre à chaque employé il est constitué de 7 chiffres et une lettre.
    Du coup il faut un type char(8) et non pas integer


    Citation Envoyé par LecGaël Voir le message
    Pour ce qui est de actif, c'est un booléen qui est modifié par l'admin du site, pour valider l'utilisateur.
    Ok en ce cas


    Citation Envoyé par LecGaël Voir le message
    C'est ce que j'ai précisé en fin du dernier post, c'est effectivement ce que je ferais, mais vu que le problème n'est pas là
    Pour pouvoir gérer la disponibilité ou non d'un article à la location, il faut bien distinguer l'exemplaire de l'article, c'est lui qui fait l'objet d'une location, du groupe d'articles de même référence et comprenant un à plusieurs exemplaires.

    Par exemple, un loueur de voitures a peut être plusieurs exemplaires de Renault clio série 3 avec moteur essence 1.2 litres, mais chaque contrat de location ne concernera que l'un des exemplaires de telle date à telle date. C'est pourquoi il faut distinguer l'article (la renault clio 3 1,2 litres) de l'exemplaire de l'article (la clio 3 immatriculée 1234 RW 72 ayant tel numéro de moteur et tel numéro de chassis)

  14. #14
    Membre du Club
    Pour pouvoir gérer la disponibilité ou non d'un article à la location, il faut bien distinguer l'exemplaire de l'article, c'est lui qui fait l'objet d'une location, du groupe d'articles de même référence et comprenant un à plusieurs exemplaires.

    Par exemple, un loueur de voitures a peut être plusieurs exemplaires de Renault clio série 3 avec moteur essence 1.2 litres, mais chaque contrat de location ne concernera que l'un des exemplaires de telle date à telle date. C'est pourquoi il faut distinguer l'article (la renault clio 3 1,2 litres) de l'exemplaire de l'article (la clio 3 immatriculée 1234 RW 72 ayant tel numéro de moteur et tel numéro de chassis)
    Je vois bien la chose mais pour l'implémenter
    En l’occurrence, prenons des multimètres, on en a trois et on se fiche de savoir le numéro de serie de celui ou ceux que l'on emprunte. Pour un loueur il pourrait faire la disctinction avec le numéro de plaque par exemple ? Mais dans mon cas ^^"

    Dans mon scénario: un collègue peut en réserver 1,2 ou 3 sur la même période, ou des périodes différentes, etc.

  15. #15
    Expert éminent sénior
    Identification unique classique : apposition d'un code à barre sur chaque exemplaire

    Le client emprunte tel exemplaire et lors du retour, l'application vérifie que l'exemplaire restitué est bien celui dont l'identifiant unique a été enregistré lors de la location
    C'est une façon de s'assurer que l'emprunteur n'a pas remplacé volontairement ou pas votre article par un autre similaire, mais éventuellement défectueux

  16. #16
    Membre du Club
    Citation Envoyé par escartefigue Voir le message
    Identification unique classique : apposition d'un code à barre sur chaque exemplaire

    Le client emprunte tel exemplaire et lors du retour, l'application vérifie que l'exemplaire restitué est bien celui dont l'identifiant unique a été enregistré lors de la location
    C'est une façon de s'assurer que l'emprunteur n'a pas remplacé volontairement ou pas votre article par un autre similaire, mais éventuellement défectueux
    Justement, nous n'avons pas de tels système... c'est encore géré à la "rustre". C'est pourquoi je suis resté simpliste et je ne fais pas de distinction entre article de même type.
    Je suis conscient du problème que cela peut occasionner, j'en ai déja fait part et on m'a dit de ne pas le prendre en compte

  17. #17
    Expert éminent sénior
    il n'en reste pas moins que
    - même en l'absence d'identification unique type code barres ou autre, chaque exemplaire d'article sera stocké à un emplacement différent, sur une même étagère ou pas, dans une même armoire ou pas.
    - la notion de stock n'a aucun sens au niveau de l'exemplaire alors que ça peut en avoir un au niveau de l'article

    On ne peut donc échapper à une modélisation rigoureuse si on souhaite gérer à la fois la localisation (exemplaire) et le stock (article)

  18. #18
    Membre du Club
    Citation Envoyé par escartefigue Voir le message
    il n'en reste pas moins que
    - même en l'absence d'identification unique type code barres ou autre, chaque exemplaire d'article sera stocké à un emplacement différent, sur une même étagère ou pas, dans une même armoire ou pas.
    Si j'ai trois multimètres ils sont forcément sur la même étagère.
    la notion de stock n'a aucun sens au niveau de l'exemplaire alors que ça peut en avoir un au niveau de l'article
    Je dois avoir une quantité de base dans mon entité ?

    On ne peut donc échapper à une modélisation rigoureuse si on souhaite gérer à la fois la localisation (exemplaire) et le stock (article)
    Quelle serait la bonne méthode ici ?

    Une table Exemplaire qui listerait les différents exemplaire pour chaque article ?
    Et donc ma quantité en stock serait le nombre d'entité dans la table exemplaire pour un id_article donné ?

  19. #19
    Expert éminent sénior
    Citation Envoyé par LecGaël Voir le message
    Si j'ai trois multimètres ils sont forcément sur la même étagère.
    Cette règle me semble plus que douteuse, si les dimensions d'une étagère ne permettent de ranger que n appareils d'un certain type, vous vous interdisez d'acheter un appareil supplémentaire du même type parceque l'étagère est pleine, alors que vous avez de la clientèle pour cet appareil supplémentaire ?



    Citation Envoyé par LecGaël Voir le message
    Je dois avoir une quantité de base dans mon entité ?
    Je ne comprends pas le sens de cette question.



    Citation Envoyé par LecGaël Voir le message
    Quelle serait la bonne méthode ici ?
    Une table Exemplaire qui listerait les différents exemplaire pour chaque article ?
    Et donc ma quantité en stock serait le nombre d'entité dans la table exemplaire pour un id_article donné ?
    Exactement ! Le MCD correct est :
    [ARTICLE (id, référence, description, prix...)] 0,n --- posseder --- 1,1(R) [EXEMPLAIRE (id, num_serie, date_fabrication...)] 1,1 --- situer --- 0,n [ETAGERE]
    La cardinalité 1,1(R) devant exemplaire symbolise l'identification de l'exemplaire relativement à l'article.
    Au niveau tabulaire, l'identifiant primaire de l'exemplaire sera composé de l'identifiant primaire de l'article plus l'identifiant de l'exemplaire

  20. #20
    Membre du Club
    Citation Envoyé par escartefigue Voir le message
    Cette règle me semble plus que douteuse, si les dimensions d'une étagère ne permettent de ranger que n appareils d'un certain type, vous vous interdisez d'acheter un appareil supplémentaire du même type parceque l'étagère est pleine, alors que vous avez de la clientèle pour cet appareil supplémentaire ?
    Etagère et armoire son juste des codes pour repérer les articles (5S au boulot oblige ).
    Je ne suis pas du tout dans l'optique de voir si tels article tient sur tel étagère, c'est juste une donnée de localisation géré par l'administrateur.




    Exactement ! Le MCD correct est :
    [ARTICLE (id, référence, description, prix...)] 0,n --- posseder --- 1,1(R) [EXEMPLAIRE (id, num_serie, date_fabrication...)] 1,1 --- situer --- 0,n [ETAGERE]
    La cardinalité 1,1(R) devant exemplaire symbolise l'identification de l'exemplaire relativement à l'article.
    Au niveau tabulaire, l'identifiant primaire de l'exemplaire sera composé de l'identifiant primaire de l'article plus l'identifiant de l'exemplaire
    D'accord et du point de vue logique pour le planning ?
    Comment pourrais je faire pour gérer les dispo sur les périodes ?

    La seule solution que j'ai trouvé c'est de regardé la quantité de dispo par jour. Donc il faudrait que je regarde la quantité dispo par jour par exemplaire par exemple .
    Cette notion d'exemplaire me complique la vie