IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Schéma Discussion :

Association ternaire, ou pas [Entité-Association]


Sujet :

Schéma

  1. #1
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2013
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Février 2013
    Messages : 13
    Points : 12
    Points
    12
    Par défaut Association ternaire, ou pas
    Bonjour tout le monde,

    Je voudrais avoir votre avis sur la pertinence de l'utilisation d'une association ternaire dans le cas suivant :
    J'ai une entité recette utilisée pour garder trace des rentrées d'argent de l'association de réparation pour laquelle je développe une base de données.
    Ces recettes peuvent être issues :
    1. d'une vente d'un objet réparé
    2. d'un événement au cours duquel les adhérents enregistrés paient un droit d'entrée. Dans ce cas une recette est associée à la fois à l'événement et à l'adhérent.
    3. d'un événement "extérieur" qui accueille des participants, non adhérents donc absents de la BdD. Dans ce cas on considère que c'est l'événement seul qui génère la recette.
    4. d'une subvention d'un collaborateur qui demande un événement
    5. d'un don/subvention d'un collaborateur non associée à un événement
    6. d'un don d'un adhérent


    C'est dans les cas 2 et 4 que je me demande si une association ternaire est justifiée car un adhérent peut participer à un atelier sans forcément générer de recette, et de même un collaborateur peut demander un événement sans le subventionner.
    Ils correspondent aux associations collaborateur <--demande-->evenement et adherent<--participe-->evenement dans le modèle que je joins à mon post.

    Quelle serait la meilleure façon de modéliser cela ?
    Toute proposition de correction sur d'autre partie du modèle est bien sûr aussi la bienvenue ! Merci d'avance !
    Images attachées Images attachées  

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Déplier le MCD
    Bonjour dazzle,



    Vous avez défini une seule entité-type RECETTE, pour différentes sources de recettes, d’où un MCD comportant des boucles et compliquant la tâche.

    Je suggère que dans un 1er temps on déplie tout ça.



    Citation Envoyé par dazzle
    Ces recettes peuvent être issues :

    1.d'une vente d'un objet réparé
    Etant donné que l’objet en question appartient à un adhérent, il existe la vue suivante :

    [ADHERENT]--0,N--------(POSSEDER)--------1,1--[OBJET]--0,1--------(VENTE)---------1,1--[RECETTE_VENTE {recette)}]

    Ce qui permet de savoir quel est l’adhérent bénéficiaire de la recette de la vente (que j’ai baptisée RECETTE_VENTE).



    Citation Envoyé par dazzle
    2. d'un événement au cours duquel les adhérents enregistrés paient un droit d'entrée. Dans ce cas une recette est associée à la fois à l'événement et à l'adhérent.
    Pour distinguer ce genre d’événement des événements extérieurs, pour fixer les idées je parlerai ci-dessous d’événement interne.

    Le montant du droit d’entrée pour un événement interne est-il unique ?

    (2.a) Supposons que la réponse soit affirmative. Ce montant est-il le même pour tous les adhérents qui participent à cet événement ? Sinon, pour quels motifs des adhérents pourraient payer des montants différents ?

    (2.b) Supposons que la réponse soit négative. Il y aurait donc différentes catégories de droit d’entrée, chacune avec son montant. Ce montant est-il le même pour tous les adhérents qui participent à cet événement ? Sinon, pour quels motifs des adhérents pourraient payer des montants différents pour une catégorie donnée ?



    Citation Envoyé par dazzle
    3. d'un événement "extérieur" qui accueille des participants, non adhérents donc absents de la BdD. Dans ce cas on considère que c'est l'événement seul qui génère la recette.
    Ceci infirme la cardinalité minimale 1 portée par la patte connectant EVENEMENT et PARTICIPE. Cela dit, je suppose que la recette totale portée par ce genre d’événement est, fonctionnement parlant, portée par l’événement :

    [EVENEMENT_EXTERNE {recette}]



    Citation Envoyé par dazzle
    4. d'une subvention d'un collaborateur qui demande un événement.
    La recette serait donc le montant de la subvention :

    [COLLABORATEUR]--0,N--------(DEMANDER)--------1,1--[EVENEMENT_INTERNE {subvention}]



    Citation Envoyé par dazzle
    5. d'un don/subvention d'un collaborateur non associée à un événement.
    [COLLABORATEUR]--0,N--------(FAIRE_DON)--------1,1--[COLLABORATEUR_DON{montant}]



    Citation Envoyé par dazzle
    6. d'un don d'un adhérent.
    [ADHERENT]--0,N--------(ADH_FAIRE_DON)--------1,1--[ADHERENT_DON{montant}]


    Le MCD va bouger, mais au préalable, il faudrait que vous répondiez aux questions posées et confirmiez les vues et assertions que j’ai faites.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  3. #3
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2013
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Février 2013
    Messages : 13
    Points : 12
    Points
    12
    Par défaut
    Bonjour fsmrel, et merci pour votre réponse très complète !


    Citation Envoyé par fsmrel Voir le message
    Etant donné que l’objet en question appartient à un adhérent, il existe la vue suivante :

    [ADHERENT]--0,N--------(POSSEDER)--------1,1--[OBJET]--0,1--------(VENTE)---------1,1--[RECETTE_VENTE {recette)}]

    Ce qui permet de savoir quel est l’adhérent bénéficiaire de la recette de la vente (que j’ai baptisée RECETTE_VENTE).
    Il n'était pas prévu que les adhérents puissent vendre des objets. L'association (VENTE) ne concerne en fait que les objets dont le propriétaire est l'atelier (qui est enregistré comme adhérent mais représente l'association).

    Citation Envoyé par fsmrel Voir le message
    Pour distinguer ce genre d’événement des événements extérieurs, pour fixer les idées je parlerai ci-dessous d’événement interne.

    Le montant du droit d’entrée pour un événement interne est-il unique ?

    (2.a) Supposons que la réponse soit affirmative. Ce montant est-il le même pour tous les adhérents qui participent à cet événement ? Sinon, pour quels motifs des adhérents pourraient payer des montants différents ?

    (2.b) Supposons que la réponse soit négative. Il y aurait donc différentes catégories de droit d’entrée, chacune avec son montant. Ce montant est-il le même pour tous les adhérents qui participent à cet événement ? Sinon, pour quels motifs des adhérents pourraient payer des montants différents pour une catégorie donnée ?
    Pour les événements internes, le droit d'entrée varie selon la situation de l'adhérent :
    - l'événement est gratuit/prix libre pour tous les adhérents ayant cotisé au moins 20 euros depuis leur première cotisation de l'année (suivi par l'attribut date_cotisation dans [ADHERENT])
    - il est de 5 euros dans les autres cas

    Dans le cas idéal, un adhérent obtient l'accès libre à tous les événements après avoir participé et cotisé à 4 événements. Mais il peut exister des cas où l'adhérent cotise plus de 5 euros d'un coup s'il le désire.


    Citation Envoyé par fsmrel Voir le message

    Ceci infirme la cardinalité minimale 1 portée par la patte connectant EVENEMENT et PARTICIPE. Cela dit, je suppose que la recette totale portée par ce genre d’événement est, fonctionnement parlant, portée par l’événement :

    [EVENEMENT_EXTERNE {recette}]
    La recette des événements externe consistera en la somme des droits d'entrée + des dons au cours de ces événements.
    En effet, la cardinalité minimale pourrait être à 0. En pratique, il y aura toujours un des membres actifs/bénévoles qui sera présent à l'événement externe et chargé de l'animation.


    Citation Envoyé par fsmrel Voir le message
    La recette serait donc le montant de la subvention :

    [COLLABORATEUR]--0,N--------(DEMANDER)--------1,1--[EVENEMENT_INTERNE {subvention}]
    Oui, mais un collaborateur interviendra plutôt pour demander des événements externes. Cela peut-être par exemple des associations ou institutions qui demandent une intervention ou un atelier dans des locaux différents de ceux de l'association.



    Citation Envoyé par fsmrel
    [COLLABORATEUR]--0,N--------(FAIRE_DON)--------1,1--[COLLABORATEUR_DON{montant}]

    [ADHERENT]--0,N--------(ADH_FAIRE_DON)--------1,1--[ADHERENT_DON{montant}]
    En suivant la logique de séparation des recettes, tout à fait.

    Citation Envoyé par fsmrel
    Le MCD va bouger, mais au préalable, il faudrait que vous répondiez aux questions posées et confirmiez les vues et assertions que j’ai faites.
    J'espère avoir répondu à vos questions, si vous voulez plus de précisions n'hésitez pas.
    Si je comprends bien, il faudrait séparer l'entité recette en différentes entités selon l'origine de la recette ? et de même pour les événements, selon qu'ils soient internes ou externes ?
    Selon cette même logique, est-ce qu'il serait souhaitable de séparer également l'entité [DEPENSE] ?

  4. #4
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir dazzle,


    Citation Envoyé par dazzle
    Citation Envoyé par fsmrel
    Etant donné que l’objet en question appartient à un adhérent, il existe la vue suivante :

    [ADHERENT]--0,N--------(POSSEDER)--------1,1--[OBJET]--0,1--------(VENTE)---------1,1--[RECETTE_VENTE {recette)}]

    Ce qui permet de savoir quel est l’adhérent bénéficiaire de la recette de la vente (que j’ai baptisée RECETTE_VENTE).
    Il n'était pas prévu que les adhérents puissent vendre des objets. L'association (VENTE) ne concerne en fait que les objets dont le propriétaire est l'atelier (qui est enregistré comme adhérent mais représente l'association).
    Que seul l’ atelier puisse vendre des objets, soit. Mais puisqu’il est enregistré comme adhérent, la vue n’est pas invalidée. Chaque instance de RECETTE_VENTE fait référence à un objet en possession de l’atelier.



    Citation Envoyé par dazzle
    Pour les événements internes, le droit d'entrée varie selon la situation de l'adhérent :
    - l'événement est gratuit/prix libre pour tous les adhérents ayant cotisé au moins 20 euros depuis leur première cotisation de l'année (suivi par l'attribut date_cotisation dans [ADHERENT])
    - il est de 5 euros dans les autres cas

    Dans le cas idéal, un adhérent obtient l'accès libre à tous les événements après avoir participé et cotisé à 4 événements. Mais il peut exister des cas où l'adhérent cotise plus de 5 euros d'un coup s'il le désire.
    En première approche, le montant réglé peut faire l’objet d’un attribut porté par l’association PARTICIPE :

    [ADHERENT]--0,N--------(PARTICIPE {Montant})--------1,N--[EVENEMENT]

    Concernant les adhérents pour qui l’accès est gratuit, le montant prend la valeur 0.



    Citation Envoyé par dazzle
    La recette des événements externe consistera en la somme des droits d'entrée + des dons au cours de ces événements.
    En effet, la cardinalité minimale pourrait être à 0. En pratique, il y aura toujours un des membres actifs/bénévoles qui sera présent à l'événement externe et chargé de l'animation.
    Donc vous n’infirmez pas la représentation :

    [EVENEMENT_EXTERNE {recette}]



    Citation Envoyé par dazzle
    Oui, mais un collaborateur interviendra plutôt pour demander des événements externes. Cela peut-être par exemple des associations ou institutions qui demandent une intervention ou un atelier dans des locaux différents de ceux de l'association.
    D’accord. J’ai utilisé le terme « EVENEMENT_INTERNE » car je ne savais comment nommer la chose de façon pertinente. Si le principe de la modélisation utilisée vous convient, je vous laisse le soin du choix du nom qui convient.



    Citation Envoyé par dazzle
    Si je comprends bien, il faudrait séparer l'entité recette en différentes entités selon l'origine de la recette ? et de même pour les événements, selon qu'ils soient internes ou externes ?
    Oui. Le but de la manoeuvre est d’éviter d’avoir un modèle qui boucle, donc d’avoir à programmer des contraintes de chemin / d’inclusion dans tous les sens au stade SQL, sans parler des contraintes d’exclusion, et des problèmes posés par l’affreux bonhomme Null... Bref, il faut prévoir d’éviter de ficher la zoubia dans la base de données.



    Citation Envoyé par dazzle
    Selon cette même logique, est-ce qu'il serait souhaitable de séparer également l'entité [DEPENSE] ?
    Oui.


    Je vous ferai une proposition de MCD révisé pour les recettes, mais pour le moment il se fait tard... ^^
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  5. #5
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2013
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Février 2013
    Messages : 13
    Points : 12
    Points
    12
    Par défaut
    Bonjour,

    J'ai mis à jour le modèle pour représenter les modifications dont nous avons parlé.

    Je m'aperçois que, dans cette représentation, les cas suivants posent problème :
    1. les collaborateurs peuvent subventionner un événement externe (à distinguer d'un don), on doit pouvoir lier une subvention à l'événément et au collaborateur.
    2. il existe une boucle autour de ADHERENT, REPARATION et EVEN_INTERNE. On doit pouvoir connaitre, pour une réparation donnée, les adhérents impliqués et l'événément au cours duquel elle a lieu. Cette boucle doit elle tout de même être brisée ?


    J'anticipe un peu en vous donnant quelques informations sur les dépenses :
    • chaque dépense doit être liées à un adhérent actif considéré comme responsable de celle-ci
    • elle peut servir à acheter des objets
    • elle peut permettre de couvrir les frais éventuels nécessaires à la tenue d'un événement. Cela peut inclure le dédommagement de bénévoles (frais de transports etc...), dans ce cas on doit savoir lesquels. Mais il peut s'agir de frais non liés à un bénévole, par exemple la location d'un lieu.
    • elle peut servir à rémunérer un salarié (qui n'a pas le statut juridique d'adhérent mais sera stocké dans ADHERENT)
    Images attachées Images attachées  

  6. #6
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir dazzle,


    Votre entité-type COL_DON comporte un attribut « type » : de quoi s’agit-il ? D’une typologie des dons ?

    D’une manière générale, un attribut tel que « type » dans une entité-type (ou dans une association) entraîne la mise en oeuvre d’une entité-type ad-hoc, TYPE_DON pour reprendre l’exemple.


    Identification relative

    Un collaborateur peut faire plusieurs dons, autrement dit, l’entité-type COL_DON est une caractéristique de l’entité-type COLLABORATEUR, un attribut (multivalué certes, mais attribut quand même), ce que l’on symbolise par l’identification relative de COL_DON par rapport à COLLABORATEUR :






    COL_DON est une entité-type dite faible (weak). Au sens Merise du terme, son identifiant est composé de l’association col_donne et de l’attribut id_recette.

    Les choses sont plus claires au niveau relationnel. Par exemple, en SQL :

    
    CREATE TABLE COLLABORATEUR 
    (
       id_collab            INT NOT NULL,
       nom_collab           VARCHAR(32) NOT NULL,
       mail_collab          VARCHAR(64) NOT NULL,
       CONSTRAINT COLLABORATEUR_PK PRIMARY KEY (id_collab),
    ) ;
    
    CREATE TABLE COLLAB_DON 
    (
       id_collab            INT NOT NULL,
       id_collab_don        INT NOT NULL,
       id_type_don          INT NOT NULL,
       date_collab_don      DATETIME NOT NULL,
       montant_collab_don   DECIMAL(7,2) NOT NULL,
       commentaires_don     VARCHAR(64) NOT NULL,
       CONSTRAINT COLLAB_DON_PK PRIMARY KEY (id_collab, id_collab_don),
       CONSTRAINT COLLAB_DON_COLLABORATEUR_FK FOREIGN KEY (id_collab)
          REFERENCES COLLABORATEUR,
       CONSTRAINT COLLAB_DON_TYPE_DON_FK FOREIGN KEY (id_type_don)
          REFERENCES TYPE_DON
    ) ;
    
    
    Attention, lors de la transformation du MCD en MLD, donc ensuite de la génération du code SQL, JMerise se plante dans l’ordre des attributs de la clé primaire de la table COLLAB_DON (effet Dagobert), un truc à faire ramer les requêtes.


    L’identification relative est à utiliser pour les entités-types ADH_DON et RECETTE_VENTE.



    Citation Envoyé par dazzle
    Je m'aperçois que, dans cette représentation, les cas suivants posent problème :
    1.les collaborateurs peuvent subventionner un événement externe (à distinguer d'un don), on doit pouvoir lier une subvention à l'événement et au collaborateur.
    C’est ce qui était sous-entendu dans ce que j’avais proposé :

    [COLLABORATEUR]--0,N--------(DEMANDER)--------1,1--[EVENEMENT_INTERNE {subvention}]

    Cela dit, dans votre dernier MCD, la patte connectant l’entité-type EVENEMENT_EXTERNE et l’association DEMANDE est porteuse d’une cardinalité 0,1, ce qui veut dire qu’il existe des événements externes qui n’ont pas les collaborateurs pour origine.

    Je propose donc de faire le distinguo entre les types d’événements externes, ceux qui ont les collaborateurs pour origine, et les autres, autrement dit de procéder à leur spécialisation :





    Je suppose que l’entité-type EVENEMENT_EXTERNE_DIVERS est associée à d’autres objets du MCD qui ne concernent pas les événements ayant les collaborateurs pour origine. Qu’en est-il ?

    De même qu’il y a les événements externes, il y a les événements internes : on peut procéder à leur généralisation (soeur jumelle de la spécialisation) pour obtenir l’entité-type EVENEMENT, où l’on factorise les attributs communs à tous les événements :







    Pour le moment, j’en suis à quelque chose comme ceci en ce qui concerne les recettes :




    Sommes-nous à peu près en phase ?


    MLD correspondant :





    Citation Envoyé par dazzle
    2.il existe une boucle autour de ADHERENT, REPARATION et EVEN_INTERNE. On doit pouvoir connaître, pour une réparation donnée, les adhérents impliqués et l'événement au cours duquel elle a lieu. Cette boucle doit elle tout de même être brisée ?
    A priori, je ne pense pas que cette boucle soit à « briser », mais je vais regarder ça de plus près. Dans le cas général, il y a quand même des boucles dont la rupture entraînerait la perte de fonctionnalités, de règles de gestion, donc qu’on ne brise pas, mais qui en contrepartie nécessitent la mise en oeuvre de contraintes d’inclusion.

    Dans la mesure où une réparation concerne un ou plusieurs objets et que cette réparation peut être effectuée par un ou plusieurs adhérents, il y a une boucle entre REPARATION, ADHERENT et OBJET car les objets utilisés pour réparer (ou à réparer ?) appartiennent chacun à un adhérent. Mais s’il n’y a pas de contrainte en relation avec le possesseur d’un objet, cette boucle ne devrait pas poser de problème.

    Vous écrivez : « l'événement au cours duquel elle a lieu », ce qui veut dire qu’une réparation donne lieu à un et un seul événement. Par contre, la patte connectant l’entité-type REPARATION et l’association AU_COURS_DE est porteuse d’une cardinalité 0,N. Que retient-on ?

    Une autre boucle : OBJET > REPARATION > REPARE > APPAREIL > OBJET. A priori, un objet à réparer pourrait servir à sa propre réparation...



    Je n’ai pas encore regardé les dépenses.


    En passant, quel est votre SGBD ?


    N.B. Un troll auquel je ne peux résister... A propos des dons : avez-vous eu un don du Cosaque ? ^^
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  7. #7
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2013
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Février 2013
    Messages : 13
    Points : 12
    Points
    12
    Par défaut
    Bonjour fsmrel,

    Hehe... J'ai du faire appel à Wikipédia pour le comprendre, comme quoi un troll peut parfois être informatif ! ^^

    Citation Envoyé par fsmrel
    Votre entité-type COL_DON comporte un attribut « type » : de quoi s’agit-il ? D’une typologie des dons ?
    Au temps pour moi, j'ai bêtement copié-collé l'entité recette. L'attribut type devait servir à différencier les ventes, dons,cotisations etc... mais n'a donc plus lieu d'être.

    Merci pour ces clarifications sur l'identification relative ! Ce que j'en avais compris auparavant, c'est qu'elle était utile pour identifier des entités qui ne sont pas porteuses en elle-même de l'information nécessaire. Par exemple un numéro de salle, qui doit être allié à un numéro de bâtiment pour qu'on sache de quelle salle il s'agit. Quel est le raisonnement derrière son utilisation dans notre situation ?

    Citation Envoyé par fsmrel
    Citation Envoyé par dazzle
    Je m'aperçois que, dans cette représentation, les cas suivants posent problème :
    1.les collaborateurs peuvent subventionner un événement externe (à distinguer d'un don), on doit pouvoir lier une subvention à l'événement et au collaborateur.
    C’est ce qui était sous-entendu dans ce que j’avais proposé :

    [COLLABORATEUR]--0,N--------(DEMANDER)--------1,1--[EVENEMENT_INTERNE {subvention}]
    Tout à fait ! Décidément va falloir que je remette le cerveau en route...

    Citation Envoyé par fsmrel
    Cela dit, dans votre dernier MCD, la patte connectant l’entité-type EVENEMENT_EXTERNE et l’association DEMANDE est porteuse d’une cardinalité 0,1, ce qui veut dire qu’il existe des événements externes qui n’ont pas les collaborateurs pour origine.

    Je propose donc de faire le distinguo entre les types d’événements externes, ceux qui ont les collaborateurs pour origine, et les autres, autrement dit de procéder à leur spécialisation : [...]
    J'ai demandé confirmation au sujet de la possibilité d'un événement externe non lié à un collaborateur, et ce cas ne devrait pas arriver. On en restera du coup à une seule entité EVENEMENT_EXTERNE.

    Citation Envoyé par fsmrel
    De même qu’il y a les événements externes, il y a les événements internes : on peut procéder à leur généralisation (soeur jumelle de la spécialisation) pour obtenir l’entité-type EVENEMENT, où l’on factorise les attributs communs à tous les événements :
    Absolument !

    Citation Envoyé par fsmrel
    Pour le moment, j’en suis à quelque chose comme ceci en ce qui concerne les recettes :
    ## SCHEMA MCD ##
    Sommes-nous à peu près en phase ?
    Nous le sommes, à l'exception de cette histoire de types de dons qui est une erreur de ma part
    J'aurais cependant une question sur la création des entités-type, puisqu'elles apparaissent dans d'autres cas que les dons : quel est l'avantage de cette modélisation ? Est-ce lié à minimiser l'espace de stockage, l'apparition de valeurs NULL ou autre ?

    Citation Envoyé par fsmrel
    Vous écrivez : « l'événement au cours duquel elle a lieu », ce qui veut dire qu’une réparation donne lieu à un et un seul événement. Par contre, la patte connectant l’entité-type REPARATION et l’association AU_COURS_DE est porteuse d’une cardinalité 0,N. Que retient-on ?
    Dans ce cas c'est bien la cardinalité qu'il faut retenir : une réparation pourra avoir lieu au cours de plusieurs événements. Elle n'est pas forcément terminée en une seule fois et peut nécessiter d'être poursuivie plus tard.

    Citation Envoyé par fsmrel
    Une autre boucle : OBJET > REPARATION > REPARE > APPAREIL > OBJET. A priori, un objet à réparer pourrait servir à sa réparation...
    Hmm j'avais pas vu ça en effet ! En fait une réparation peut nécessiter des objets de la catégorie OUTIL et/ou PIECES mais pas d'APPAREIL. On pourrait éventuellement utiliser une contrainte X ?

    Nom : outil_piece.jpg
Affichages : 1565
Taille : 129,8 Ko

    Citation Envoyé par fsmrel
    En passant, quel est votre SGBD ?
    Classiquement, cela devrait être MySQL. Il me semble que notre service d'hébergement ne propose que ce SGBD.

    Vos réponses très riches sont un vrai plaisir à lire !

  8. #8
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Réparations
    Bonsoir dazzle,


    Citation Envoyé par dazzle
    J'aurais cependant une question sur la création des entités-type, puisqu'elles apparaissent dans d'autres cas que les dons : quel est l'avantage de cette modélisation ? Est-ce lié à minimiser l'espace de stockage, l'apparition de valeurs NULL ou autre ?
    S’il s’agit des entités-types telles que TYPE_EVENEMENT et TYPE_COLLAB, le but est de contrôler de façon fiable les valeurs prises par les types d’événements et de collaborateurs, autrement que, par exemple, au moyen d’un type ENUM dans les tables SQL. Il y a quelques décennies, TYPE_EVENEMENT et TYPE_COLLAB auraient appartenu à la catégorie de ce qu’on appelait alors les « tables de codes » ; Spitab était alors le logiciel le plus populaire en France pour gérer ce genre de « tables », c’était l’bon temps...



    Citation Envoyé par dazzle
    En fait une réparation peut nécessiter des objets de la catégorie OUTIL et/ou PIECES mais pas d'APPAREIL. On pourrait éventuellement utiliser une contrainte X ?
    Vous avez représenté une contrainte d’exclusion entre les associations Utilise_outil et Utilise_piece, avec l’entité-type REPARATION comme pivot : cela veut dire que pour une réparation donnée, on utilise sot un outil, soit une pièce : il y a là une contradiction avec ce que vous avez écrit : « une réparation peut nécessiter des objets de la catégorie OUTIL et/ou PIECES »...

    Si l’on fit abstraction de la contrainte d’exclusion en cause, la modélisation des réparations est correcte. Incidemment, l’association UTILISE_PIECE ne requiert-elle pas un attributs Quantite (de pièces) ?



    Citation Envoyé par dazzle
    Vos réponses très riches sont un vrai plaisir à lire !
    Alors n’hésitez pas à lever un pouce vert pour les réponses qui ont pu vous apporter quelque chose, et au passage à confirmer ici des médailles acquises sur différents terrains, souvent accidentés...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  9. #9
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Dépenses
    Bonsoir dazzle,


    En ce qui concerne les dépenses, a priori on conserve l’entité-type DEPENSE car, quelle que soit la nature de la dépense, celle-ci est gérée par un adhérent, d’où factorisation (généralisation) en conséquence. Concernant les rémunérations et les achats, la partie correspondante du MCD pourrait être celle-ci :





    Reste le cas des financements externes : ceux-ci feront l’objet d’un sous-type de DEPENSE (appelons-le par exemple FINANCEMENT_EXTERNE), au même titre que REMUNERATION et ACHAT. Selon votre modélisation, ce sous-type serait en relation avec l’entité-type existante EVENEMENT_EXTERNE, mais celle-ci est utilisée pour les recettes (présence de l’attribut montant_recette). Il faudrait donc définir un nouveau sous-type d’EVENEMENT, dédié aux dépenses. Appelons provisoirement EVENEMENT_DEPENSE, ce sous-type d’EVENEMENT. Je vous laisse le soin de poursuivre le film, améliorer, confirmer ou infirmer ce que j’ai écrit...

    En passant, merci pour les votes.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  10. #10
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2013
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Février 2013
    Messages : 13
    Points : 12
    Points
    12
    Par défaut
    Bonjour fsmrel,

    Désolé pour le long silence... j'ai enfin le temps de me remettre sur le projet.

    Citation Envoyé par fsmrel
    En ce qui concerne les dépenses, a priori on conserve l’entité-type DEPENSE car, quelle que soit la nature de la dépense, celle-ci est gérée par un adhérent, d’où factorisation (généralisation) en conséquence
    Oui tout à fait.

    Citation Envoyé par fsmrel
    Reste le cas des financements externes : ceux-ci feront l’objet d’un sous-type de DEPENSE (appelons-le par exemple FINANCEMENT_EXTERNE), au même titre que REMUNERATION et ACHAT. Selon votre modélisation, ce sous-type serait en relation avec l’entité-type existante EVENEMENT_EXTERNE, mais celle-ci est utilisée pour les recettes (présence de l’attribut montant_recette). Il faudrait donc définir un nouveau sous-type d’EVENEMENT, dédié aux dépenses. Appelons provisoirement EVENEMENT_DEPENSE, ce sous-type d’EVENEMENT. Je vous laisse le soin de poursuivre le film, améliorer, confirmer ou infirmer ce que j’ai écrit...
    Je ne comprends pas la nécessité de créer un sous-type d'évènement, notamment en quoi la gestion des dépenses est incompatible avec celle des recettes ?

    Je fais la proposition suivante, dans laquelle la liste des attributs d'EVENEMENT_EXTERNE n'est pas modifiée, c'est FINANCEMENT qui enregistre le montant des dépenses :
    (j'ai mis le modèle dans son ensemble pour qu'on ait une vue de l'état actuel)
    Nom : modele_v3.jpg
Affichages : 1576
Taille : 274,3 Ko

    Ce qui donne après passage vers le modèle relationnel :
    Nom : modele_v3_rel.png
Affichages : 1621
Taille : 41,0 Ko

    Qu'en pensez-vous ?

    Citation Envoyé par fsmrel
    En passant, merci pour les votes.
    Ils sont mérités ! ^^

  11. #11
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Le coup des 3 montants pour un financement
    Bonsoir dazzle,


    Citation Envoyé par dazzle
    Je ne comprends pas la nécessité de créer un sous-type d'événement, notamment en quoi la gestion des dépenses est incompatible avec celle des recettes ?
    Avant de prendre position, je souhaiterais quelques éclaircissements quant aux règles de gestion et au fonctionnement des recette et des dépenses.

    Ainsi, vous aviez écrit :


    Citation Envoyé par dazzle Voir le message
    les collaborateurs peuvent subventionner un événement externe (à distinguer d'un don), on doit pouvoir lier une subvention à l'événement et au collaborateur.

    (1) D’une part, les collaborateurs peuvent faire des dons, d’accord. Mais s’autre part, s’ils font des subventions, selon une lecture littérale, là encore, il y a là recettes pour l’association : confirmez-vous ?

    (2) Pourquoi a-t-on deux montants pour un événement externe (EVENEMENT_EXTERNE, attributs subvention et montant_recette) ?

    (3) Si une dépense (entité-type DEPENSE) est un financement (entité-type FINANCEMENT), le montant de cette dépense est donc connu par l’attribut montant de l’entité-type DEPENSE. Mais comme un financement détermine un événement externe, on infère qu’une dépense de financement est en outre caractérisée par une subvention et un montant de recette (EVENEMENT_EXTERNE) : du coup, il y a 3 montants caractérisant un financement : en l’occurrence, quel rôle joue chacun de ces montants ? Sont-ils dépendants les uns des autres ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  12. #12
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2013
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Février 2013
    Messages : 13
    Points : 12
    Points
    12
    Par défaut
    Bonjour fsmrel,

    Citation Envoyé par fsmrel
    (1) D’une part, les collaborateurs peuvent faire des dons, d’accord. Mais s’autre part, s’ils font des subventions, selon une lecture littérale, là encore, il y a là recettes pour l’association : confirmez-vous ?
    Oui.
    Citation Envoyé par fsmrel
    (2) Pourquoi a-t-on deux montants pour un événement externe (EVENEMENT_EXTERNE, attributs subvention et montant_recette) ?
    Pour préciser ma réponse à la première question, et répondre à la deuxième : dans le modèle, je distingue les dons des subventions, ces dernières constituent les éventuels financement reçus pour organiser/rémunérer un événement externe. Il est possible que ces événements aient aussi un prix d'accès, dont le montant total est enregistré dans montant_recette. On peut ainsi garder une trace de l'origine des rentrées d'argent.

    (3) Si une dépense (entité-type DEPENSE) est un financement (entité-type FINANCEMENT), le montant de cette dépense est donc connu par l’attribut montant de l’entité-type DEPENSE. Mais comme un financement détermine un événement externe, on infère qu’une dépense de financement est en outre caractérisée par une subvention et un montant de recette (EVENEMENT_EXTERNE) : du coup, il y a 3 montants caractérisant un financement : en l’occurrence, quel rôle joue chacun de ces montants ? Sont-ils dépendants les uns des autres ?
    Dans le cas de l'entité FINANCEMENT, la confusion vient d'un mauvais choix des mots : cette entité représente en fait les frais éventuels dépensés par l'atelier pour organiser un événement, ce qui inclue d'éventuels dédommagement des bénévoles dans leurs frais de transports par exemple (d'où l'association ADH_FINANCEMENT avec ADHERENT). C'est un cas limite, puisque dans l'état actuel cela ne devrait se produire que très exceptionnellement mais pourrait devenir plus fréquent à mesure que l'asso se développe.

    Pour résumer, il y a donc bien 3 montants qui caractérisent un évenement externe, dont deux recettes et une dépense :
    • une subvention pour organiser l'événement, provenant d'un collaborateur
    • le montant total issu des droits de participation à l'événement
    • les dépenses de l'atelier pour organiser l'événement, incluant les dédommagements des bénévoles

    Ces montants sont indépendants les uns des autres, et sont tous facultatifs (l'événement peut être gratuit, ne recevoir aucune subvention, ou ne nécessiter aucun frais d'organisation).

    Dans le cas de l'entité FINANCEMENT, les dépenses peuvent :
    • constituer des frais non associés à un adhérent : par exemple la location d'un lieu, l'impression de flyers etc...
    • dédommager un bénévole si nécessaire pour qu'il puisse assister à l'événement, par exemple pour ses frais de déplacement. On crée alors une entrée par bénévole.

  13. #13
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Ventilation des dépenses pour le financement d’un événement externe
    Bonsoir dazzle,



    Citation Envoyé par dazzle
    Ces montants sont indépendants les uns des autres, et sont tous facultatifs (l'événement peut être gratuit, ne recevoir aucune subvention, ou ne nécessiter aucun frais d'organisation).

    Dans le cas de l'entité FINANCEMENT, les dépenses peuvent :
    — constituer des frais non associés à un adhérent : par exemple la location d'un lieu, l'impression de flyers etc...
    — dédommager un bénévole si nécessaire pour qu'il puisse assister à l'événement, par exemple pour ses frais de déplacement. On crée alors une entrée par bénévole.
    D’accord. Maintenant, quand vous écrivez « On crée alors une entrée par bénévole », je suppose que l’association adh_financement sert à cela, c'est-à-dire connaître la liste des bénévoles pour lesquels il y a dédommagement pour un financement, donc un événement donnés, sinon je ne vois pas bien l’intérêt de cette association. Mais ne cherchez-vous pas à savoir quelle part du montant de la dépense correspond au dédommagement (individuel ou collectif) des bénévoles pour ce financement ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  14. #14
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2013
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Février 2013
    Messages : 13
    Points : 12
    Points
    12
    Par défaut
    Bonjour fsmrel,

    En fait l'idée serait de créer une entrée dans FINANCEMENT pour chaque dépense associée à un événement. C'est à dire qu'on ne stockerait pas le montant total dépensé dans FINANCEMENT, mais plutôt chaque dépense liée à l'événement.

    Par exemple, une entrée pour les frais de location, et une autre pour les flyers. Dans ce cas, adh_financement n'intervient pas. Ensuite, supposons que deux adhérents doivent payer un voyage en train pour y assister. On crée alors deux entrée dans FINANCEMENT, liée chacune à un adhérent par adh_financement.

    Cela vous parait-il correct ? Avez-vous une autre proposition ?

  15. #15
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Financements
    Bonjour dazzle,



    Citation Envoyé par dazzle
    l'idée serait de créer une entrée dans FINANCEMENT pour chaque dépense associée à un événement.

    Supposons que l’événement e1 (qui a fait l’objet d’une recette de 5000 euros et d’une subvention de 0 euro), fasse l’objet de deux financements : 1020 euros pour la location et 210 euros pour les flyers (what’s a flyer ?). Au stade tabulaire (genre SQL), on résumerait les choses ainsi (les clés primaires sont en gras) :


    
    ADHERENT
    
    id_adherent    nom             ...
    -----------    ------------    ---
    a1             Spirou          ...
    a2             Haddock         ...
    a3             Tintin          ...
    a4             Fantasio        ...
    
    
    EVENEMENT_EXTERNE 
    
    id_evenement    subvention    montant_recette
    ------------    ----------    ---------------
    e1                       0               5000
    
    
    DEPENSE
    
    id_depense    date_depense    montant    commentaires    adh_gestionnaire
    ----------    ------------    -------    ------------    ----------------
    d1            date1              1020    commentaire1    a1
    d2            date1               210    commentaire2    a4
    
    
    FINANCEMENT
    
    id_depense    id_evenement    commentaire
    ----------    ------------    -----------
    d1            e1              comm1
    d2            e1              comm2
    
    
    Pour le moment, ça tient la route.



    Citation Envoyé par dazzle
    Supposons que deux adhérents doivent payer un voyage en train pour y assister. On crée alors deux entrée dans FINANCEMENT, liée chacune à un adhérent par adh_financement.
    Supposons que les deux adhérents aient payé, l’un 42 euros (voyage en 1re classe), l’autre 31 euros (voyage en 2e classe) :


    
    ADHERENT
    
    id_adherent    nom             ...
    -----------    ------------    ---
    a1             Spirou          ...
    a2             Haddock         ...
    a3             Tintin          ...
    a4             Fantasio        ...
    
    
    EVENEMENT_EXTERNE 
    
    id_evenement    subvention    montant_recette
    ------------    ----------    ---------------
    e1                       0               5000
    
    
    DEPENSE
    
    id_depense    date_depense    montant    commentaires      adh_gestionnaire
    ----------    ------------    -------    --------------    ----------------
    d1            date1              1020    commentaire1      a1
    d2            date1               210    commentaire2      a4
    d3            date2                31    c’est Haddock     a1
    d4            date1                42    c’est Tintin      a1
    
    
    FINANCEMENT
    
    id_depense    id_evenement    commentaire
    ----------    ------------     -----------
    d1            e1              comm1
    d2            e1              comm2
    d3            e1              Pour Haddock
    d4            e1              Pour Tintin
    
    
    ADH_FINANCEMENT
    
    id_depense    id_adherent
    ----------    -----------
    a2            d3
    a3            d4
    
    

    Ça tient toujours la route. Donc votre MCD aussi.

    Accessoirement, si l’attribut commentaire de FINANCEMENT fait double emploi avec celui de DEPENSE, alors il peut disparaître.


    Attention si vous utilisez JMerise pour produire le MLD et le script SQL de création des tables, il lui arrive de dérailler...


    Dès que j’aurai cinq minutes, Je vous ferai part du script qui devrait être produit.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  16. #16
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Script SQL
    Bonsoir dazzle,


    J’avais un script SQL en magasin, mais je vous ai oublié, je suis désolé...

    Voici donc ce script (MySQL), précédé du MCD dont est il est dérivé. Je n’ai pas forcément fourni tous les attributs des tables, cas notamment de la table ADHERENT, mais la structure est là.


    MCD : Recettes





    MCD : Dépenses






    MCD : Réparations





    Script SQL :


    
    USE temp ;
    
    SET default_storage_engine=InnoDB ;
    
    DROP TABLE IF EXISTS UTILISE_OUTIL ;
    DROP TABLE IF EXISTS UTILISE_PIECE ;
    DROP TABLE IF EXISTS PIECE_DEMANTELEE ;
    DROP TABLE IF EXISTS REMUNERATION ;
    DROP TABLE IF EXISTS PARTICIPE ;
    DROP TABLE IF EXISTS PIECE ;
    DROP TABLE IF EXISTS OUTIL ;
    DROP TABLE IF EXISTS EFFECTUE ;
    DROP TABLE IF EXISTS COLLAB_DON ;
    DROP TABLE IF EXISTS AU_COURS ;
    DROP TABLE IF EXISTS EVENEMENT_INTERNE ;
    DROP TABLE IF EXISTS REPARATION ;
    DROP TABLE IF EXISTS APPAREIL ;
    DROP TABLE IF EXISTS ADH_FINANCEMENT ;
    DROP TABLE IF EXISTS FINANCEMENT ;
    DROP TABLE IF EXISTS EVENEMENT_EXTERNE ;
    DROP TABLE IF EXISTS EVENEMENT ;
    DROP TABLE IF EXISTS TYPE_EVENEMENT ;
    DROP TABLE IF EXISTS COLLABORATEUR ;
    DROP TABLE IF EXISTS TYPE_COLLAB ;
    DROP TABLE IF EXISTS ACHAT ;
    DROP TABLE IF EXISTS DEPENSE ;
    DROP TABLE IF EXISTS RECETTE_VENTE ;
    DROP TABLE IF EXISTS OBJET ;
    DROP TABLE IF EXISTS ADH_DON ;
    DROP TABLE IF EXISTS ADHERENT ;
    
    -- -----------------------------------------------------------------------------------------------
    
    CREATE TABLE ADHERENT 
    (
       id_adherent          INT               NOT NULL,
       nom_adherent         VARCHAR(32)       NOT NULL,
       prenom_adherent      VARCHAR(32)       NOT NULL,
       CONSTRAINT ADHERENT_PK PRIMARY KEY (id_adherent)
    ) ;
    
    CREATE TABLE ADH_DON 
    (
       id_adherent          INT               NOT NULL,
       date_adh_don         DATE              NOT NULL,
       montant_adh_don      DECIMAL(7,2)      NOT NULL,
       commentaires_adh_don VARCHAR(64)       NOT NULL,
       CONSTRAINT ADH_DON_PK PRIMARY KEY (id_adherent),
       CONSTRAINT ADH_DON_ADHERENT_FK FOREIGN KEY (id_adherent)
          REFERENCES ADHERENT (id_adherent)
    ) ;
    
    CREATE TABLE OBJET 
    (
       id_objet             INT               NOT NULL,
       id_adherent          INT               NOT NULL,
       origine_obj          VARCHAR(32)       NOT NULL,
       etat_obj             VARCHAR(32)       NOT NULL,
       localisation_obj     VARCHAR(32)       NOT NULL,
       commentaire_obj      VARCHAR(64)       NOT NULL,
       CONSTRAINT OBJET_PK PRIMARY KEY (id_objet),
       CONSTRAINT OBJET_ADHERENT_FK FOREIGN KEY (id_adherent)
          REFERENCES ADHERENT (id_adherent)
    ) ;
    
    CREATE TABLE RECETTE_VENTE 
    (
       id_objet             INT               NOT NULL,
       date_vente           DATE              NOT NULL,
       montant_vente        DECIMAL(7,2)      NOT NULL,
       commentaires_vente   VARCHAR(64)       NOT NULL,
       CONSTRAINT RECETTE_VENTE_PK PRIMARY KEY (id_objet),
       CONSTRAINT RECETTE_VENTE_OBJET_FK FOREIGN KEY (id_objet)
          REFERENCES OBJET (id_objet)
    ) ;
    
    CREATE TABLE DEPENSE 
    (
       id_depense           INT               NOT NULL,
       id_adherent_gestion  INT               NOT NULL,
       date_depense         DATE              NOT NULL,
       montant_depense      INT               NOT NULL,
       commentaire_depense  VARCHAR(64)       NOT NULL,
       CONSTRAINT DEPENSE_PK PRIMARY KEY (id_depense),
       CONSTRAINT DEPENSE_ADHERENT_FK FOREIGN KEY (id_adherent_gestion)
          REFERENCES ADHERENT (id_adherent)
    ) ;
    
    CREATE TABLE REMUNERATION 
    (
       id_depense           INT               NOT NULL,
       id_adherent          INT               NOT NULL,
       CONSTRAINT REMUNERATION_PK PRIMARY KEY (id_depense),
       CONSTRAINT REMUNERATION_ADHERENT_FK FOREIGN KEY (id_adherent)
          REFERENCES ADHERENT (id_adherent),
       CONSTRAINT REMUNERATION_DEPENSE_FK FOREIGN KEY (id_depense)
          REFERENCES DEPENSE (id_depense) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE ACHAT 
    (
       id_depense           INT               NOT NULL,
       id_objet             INT               NOT NULL,
       CONSTRAINT ACHAT_PK PRIMARY KEY (id_depense),
       CONSTRAINT ACHAT_OBJET_FK FOREIGN KEY (id_objet)
          REFERENCES OBJET (id_objet),
       CONSTRAINT ACHAT_DEPENSE_FK FOREIGN KEY (id_depense)
          REFERENCES DEPENSE (id_depense)
    ) ;
    
    CREATE TABLE TYPE_COLLAB 
    (
       id_type_collab       INT               NOT NULL,
       libelle_type_collab  VARCHAR(32)       NOT NULL,
       CONSTRAINT TYPE_COLLAB_PK PRIMARY KEY (id_type_collab)
    ) ;
    
    CREATE TABLE COLLABORATEUR 
    (
       id_collab            INT               NOT NULL,
       id_type_collab       INT               NOT NULL,
       nom_collab           VARCHAR(32)       NOT NULL,
       mail_collab          VARCHAR(64)       NOT NULL,
       CONSTRAINT COLLABORATEUR_PK PRIMARY KEY (id_collab),
       CONSTRAINT COLLABORATEUR_TYPE_COLLAB_FK FOREIGN KEY (id_type_collab)
          REFERENCES TYPE_COLLAB (id_type_collab)
    ) ;
    
    CREATE TABLE COLLAB_DON 
    (
       id_collab            INT               NOT NULL,
       id_collab_don        INT               NOT NULL,
       date_collab_don      DATE              NOT NULL,
       montant_collab_don   DECIMAL(7,2)      NOT NULL,
       commentaires_don     VARCHAR(64)       NOT NULL,
       CONSTRAINT COLLAB_DON_PK PRIMARY KEY (id_collab, id_collab_don),
       CONSTRAINT COLLAB_DON_COLLABORATEUR_FK FOREIGN KEY (id_collab)
          REFERENCES COLLABORATEUR (id_collab)
    ) ;
    
    CREATE TABLE TYPE_EVENEMENT 
    (
       id_type_evt          INT               NOT NULL,
       libelle_type_evt     VARCHAR(64)       NOT NULL,
       CONSTRAINT TYPE_EVENEMENT_PK PRIMARY KEY (id_type_evt)
    ) ;
    
    CREATE TABLE EVENEMENT 
    (
       id_evt               INT               NOT NULL,
       id_type_evt          INT               NOT NULL,
       date_evt             DATE              NOT NULL,
       heure_evt            TIME              NOT NULL,
       lieu_evt             VARCHAR(64)       NOT NULL,
       adresse_evt          VARCHAR(64)       NOT NULL,
       url_evt              VARCHAR(64)       NOT NULL,
       capacite_evt         INT               NOT NULL,
       prix_evt             DECIMAL(7,2)      NOT NULL,
       commentaire_evt      VARCHAR(64)       NOT NULL,
       CONSTRAINT EVENEMENT_PK PRIMARY KEY (id_evt),
       CONSTRAINT EVENEMENT_TYPE_EVENEMENT_FK FOREIGN KEY (id_type_evt)
          REFERENCES TYPE_EVENEMENT (id_type_evt)
    ) ;
    
    CREATE TABLE EVENEMENT_EXTERNE 
    (
       id_evt               INT               NOT NULL,
       id_collab            INT               NOT NULL,
       subvention           INT               NOT NULL,
       montant_recette      INT               NOT NULL,
       CONSTRAINT EVENEMENT_EXTERNE_PK PRIMARY KEY (id_evt),
       CONSTRAINT EVENEMENT_EXTERNE_COLLABORATEUR_FK FOREIGN KEY (id_collab)
          REFERENCES COLLABORATEUR (id_collab),
       CONSTRAINT EVENEMENT_EXTERNE_EVENEMENT_FK FOREIGN KEY (id_evt)
          REFERENCES EVENEMENT (id_evt) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE FINANCEMENT 
    (
       id_depense           INT               NOT NULL,
       id_evt               INT               NOT NULL,
       CONSTRAINT FINANCEMENT_PK PRIMARY KEY (id_depense),
       CONSTRAINT FINANCEMENT_EVENEMENT_EXTERNE_FK FOREIGN KEY (id_evt)
          REFERENCES EVENEMENT_EXTERNE (id_evt),
       CONSTRAINT FINANCEMENT_DEPENSE_FK FOREIGN KEY (id_depense)
          REFERENCES DEPENSE (id_depense) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE ADH_FINANCEMENT 
    (
       id_adherent          INT               NOT NULL,
       id_depense           INT               NOT NULL,
       CONSTRAINT ADH_FINANCEMENT_PK PRIMARY KEY (id_adherent, id_depense),
       CONSTRAINT ADH_FINANCEMENT_ADHERENT_FK FOREIGN KEY (id_adherent)
          REFERENCES ADHERENT (id_adherent),
       CONSTRAINT ADH_FINANCEMENT_FINANCEMENT_FK FOREIGN KEY (id_depense)
          REFERENCES FINANCEMENT (id_depense) ON DELETE CASCADE
    ) ;
    CREATE TABLE EVENEMENT_INTERNE 
    (
       id_evt               INT               NOT NULL,
       CONSTRAINT EVENEMENT_INTERNE_PK PRIMARY KEY (id_evt),
       CONSTRAINT EVENEMENT_INTERNE_EVENEMENT_FK FOREIGN KEY (id_evt)
          REFERENCES EVENEMENT (id_evt) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE PARTICIPE 
    (
       id_evt               INT               NOT NULL,
       id_adherent          INT               NOT NULL,
       montant              DECIMAL(5,2)      NOT NULL,
       CONSTRAINT PARTICIPE_PK PRIMARY KEY (id_evt, id_adherent),
       CONSTRAINT PARTICIPE_EVENEMENT_INTERNE_FK FOREIGN KEY (id_evt)
          REFERENCES EVENEMENT_INTERNE (id_evt),
       CONSTRAINT PARTICIPE_ADHERENT_FK FOREIGN KEY (id_adherent)
          REFERENCES ADHERENT (id_adherent) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE APPAREIL 
    (
       id_appareil          INT               NOT NULL,
       marque               VARCHAR(32)       NOT NULL,
       modele               VARCHAR(32)       NOT NULL,
       prix                 INT               NOT NULL,
       en_vente             BIT               NOT NULL,
       CONSTRAINT APPAREIL_PK PRIMARY KEY (id_appareil),
       CONSTRAINT APPAREIL_OBJET_FK FOREIGN KEY (id_appareil)
          REFERENCES OBJET (id_objet) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE REPARATION 
    (
       id_reparation        INT               NOT NULL,
       id_appareil          INT               NOT NULL,
       statut               INT               NOT NULL,
       difficulte           VARCHAR(32)       NOT NULL,
       duree                INT               NOT NULL,
       CONSTRAINT REPARATION_PK PRIMARY KEY (id_reparation),
       CONSTRAINT REPARATION_APPAREIL_FK FOREIGN KEY (id_appareil)
          REFERENCES APPAREIL (id_appareil)
    ) ;
    
    CREATE TABLE AU_COURS 
    (
       id_evt               INT               NOT NULL,
       id_reparation        INT               NOT NULL,
       CONSTRAINT AU_COURS_PK PRIMARY KEY (id_evt, id_reparation),
       CONSTRAINT AU_COURS_EVENEMENT_INTERNE_FK FOREIGN KEY (id_evt)
          REFERENCES EVENEMENT_INTERNE (id_evt),
       CONSTRAINT AU_COURS_REPARATION_FK FOREIGN KEY (id_reparation)
          REFERENCES REPARATION (id_reparation)
    ) ;
    
    CREATE TABLE EFFECTUE 
    (
       id_adherent          INT               NOT NULL,
       id_reparation        INT               NOT NULL,
       CONSTRAINT EFFECTUE_PK PRIMARY KEY (id_adherent, id_reparation),
       CONSTRAINT EFFECTUE_ADHERENT_FK FOREIGN KEY (id_adherent)
          REFERENCES ADHERENT (id_adherent) ON DELETE CASCADE,
       CONSTRAINT EFFECTUE_REPARATION_FK FOREIGN KEY (id_reparation)
          REFERENCES REPARATION (id_reparation)
    ) ;
    
    CREATE TABLE OUTIL 
    (
       id_outil             INT               NOT NULL,
       utilite              VARCHAR(32)       NOT NULL,
       CONSTRAINT OUTIL_PK PRIMARY KEY (id_outil),
       CONSTRAINT OUTIL_OBJET_FK FOREIGN KEY (id_outil)
          REFERENCES OBJET (id_objet) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE PIECE 
    (
       id_piece             INT               NOT NULL,
       marque               VARCHAR(32)       NOT NULL,
       prix                 INT               NOT NULL,
       quantite             INT               NOT NULL,
       en_vente             BIT               NOT NULL,
       caracteristique      VARCHAR(32)       NOT NULL,
       CONSTRAINT PIECE_PK PRIMARY KEY (id_piece),
       CONSTRAINT PIECE_OBJET_FK FOREIGN KEY (id_piece)
          REFERENCES OBJET (id_objet) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE PIECE_DEMANTELEE 
    (
       id_piece             INT               NOT NULL,
       id_appareil          INT               NOT NULL,
       CONSTRAINT PIECE_DEMANTELEE_PK PRIMARY KEY (id_piece),
       CONSTRAINT PIECE_DEMANTELEE_PIECE_FK FOREIGN KEY (id_piece)
          REFERENCES PIECE (id_piece) ON DELETE CASCADE,
        CONSTRAINT PIECE_DEMANTELEE_APPAREIL_FK FOREIGN KEY (id_appareil)
          REFERENCES APPAREIL (id_appareil) 
    ) ; 
    
    CREATE TABLE UTILISE_PIECE 
    (
       id_reparation        INT               NOT NULL,
       id_piece             INT               NOT NULL,
       quantite             INT               NOT NULL,
       CONSTRAINT UTILISE_PIECE_PK PRIMARY KEY (id_reparation, id_piece),
       CONSTRAINT UTILISE_PIECE_REPARATION_FK FOREIGN KEY (id_reparation)
          REFERENCES REPARATION (id_reparation),
       CONSTRAINT UTILISE_PIECE_PIECE_FK FOREIGN KEY (id_piece)
          REFERENCES PIECE (id_piece) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE UTILISE_OUTIL 
    (
       id_outil             INT               NOT NULL,
       id_reparation        INT               NOT NULL,
       CONSTRAINT UTILISE_OUTIL_PK PRIMARY KEY (id_outil, id_reparation),
       CONSTRAINT UTILISE_OUTIL_OUTIL_FK FOREIGN KEY (id_outil)
          REFERENCES OUTIL (id_outil),
       CONSTRAINT UTILISE_OUTIL_REPARATION_FK FOREIGN KEY (id_reparation)
          REFERENCES REPARATION (id_reparation)
    ) ;
    
    

    Bon week-end !
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  17. #17
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2013
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Février 2013
    Messages : 13
    Points : 12
    Points
    12
    Par défaut
    Bonjour fsmrel,

    Citation Envoyé par fsmrel
    Ça tient toujours la route. Donc votre MCD aussi.
    [...]
    J’avais un script SQL en magasin, mais je vous ai oublié, je suis désolé...

    Voici donc ce script (MySQL), précédé du MCD dont est il est dérivé. Je n’ai pas forcément fourni tous les attributs des tables, cas notamment de la table ADHERENT, mais la structure est là.
    Super !!

    Je voudrais vous poser quelques questions sur le script MySQL, pour comprendre et apprendre :

    1. J'ai remarqué que vous assignez aux types VARCHAR des tailles qui ne sont pas anodines (puissances de 2) : 32, 64... quelle en est la raison ? S'agit-il par exemple de tailles optimales pour le stockage/la vitesse d'accès/autres ?
    2. Je découvre l'existence du type BIT en SQL. Une recherche rapide m'envoie vers des articles qui le décrivent comme une "bad practice", mais y a-t-il une autre version de l'histoire ? C'est à dire, ce type a-t-il des avantages par rapport au type BOOL par exemple ?
    3. Je réfléchis à utiliser l'autoincrement pour les clés primaires... est-ce une bonne idée ? Connaissez vous une autre méthode pour générer des identifiants uniques ?



    CREATE TABLE ADH_DON
    (
    id_adherent INT NOT NULL,
    date_don DATE NOT NULL,
    montant_don DECIMAL(7,2) NOT NULL,
    commentaires VARCHAR(64) NOT NULL,
    CONSTRAINT ADH_DON_PK PRIMARY KEY (id_adherent),
    CONSTRAINT ADH_DON_ADHERENT_FK FOREIGN KEY (id_adherent)
    REFERENCES ADHERENT (id_adherent)
    ) ;
    Les dons des adhérents (par exemple), sont identifiés par id_adherent, ce qui est cohérent avec ce dont nous avions discuté, à savoir l'identification relative pour les dons. Mais cela ne va-t-il pas poser problème, en particulier si un adhérent fait plusieurs dons ? L'identification par id_adherent seul serait alors insuffisante, ou quelque chose m'échappe

    Bon week-end à vous !

  18. #18
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir dazzle,


    Citation Envoyé par dazzle
    J'ai remarqué que vous assignez aux types VARCHAR des tailles qui ne sont pas anodines (puissances de 2) : 32, 64... quelle en est la raison ? S'agit-il par exemple de tailles optimales pour le stockage/la vitesse d'accès/autres ?
    C’est une vieille habitude que j’ai prise du temps où, il y a plus de 40 ans, je fus ingénieur système : on causait binaire et hexadécimal, donc tout était à une puissance de 2... Mais aujourd’hui, je pense que, plutôt que VARCHAR(32), je coderai VARCHAR(31) , voire VARCHAR(30) ou même VARCHAR(29) : je ne suis pas spécialiste de MySQL, donc j’irais d‘abord vérifier combien d’octets supplémentaires « de service » se réserve le SGBD pour que les valeurs prises par l’attribut occupent exactement 32 octets. Mais en 2015, que ce soit 29 ou 34 octets, peu importe... Maintenant pourquoi 32 plutôt que 64 octets ? Pour un nom de personne ou de ville, une trentaine d’octets maximum paraît raisonnable, Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch est quand même une exception. Mon nom plus prénom tiennent au large, mais je ne me formalise pas quand dans le courrier qui m’est adressé il y a troncature... Il ne faut pas oublier non plus que lorsqu'on code VARCHAR(N), en général un SGBD réserve N octets en mémoire (plus un ou deux ou trois octets de service), mais si on utilise la compression, ça zippe bien sur le disque pour les noms, donc le choix de l’allocation devient moins crucial, alors que du temps où les SGBD ne compressaient pas, les DBA étaient très regardants. Pour ma part, quitte à paraître ringard, je continue à « tailler » les attributs comme du temps où l’on ne compressait pas...


    Citation Envoyé par dazzle
    Je découvre l'existence du type BIT en SQL. Une recherche rapide m'envoie vers des articles qui le décrivent comme une "bad practice", mais y a-t-il une autre version de l'histoire ? C'est à dire, ce type a-t-il des avantages par rapport au type BOOL par exemple ?
    J’ai laissé l’AGL (PowerAMC) générer la version de son choix quant aux booléens, sans y prêter plus d’attention que ça... Cela dit, MySQL prévoit le type BOOLEAN, mais qui n’a rien de ... booléen, type qui, comme vous le savez, n’admet que deux valeurs : vrai, faux. Les auteurs de MySQL autorisent des valeurs comprises entre -128 et +127 ! (0 comptant pour faux er le reste pour vrai...). A tout prendre, je préfère encore le type BIT, mais en codant BIT(1) pour n’autoriser que deux valeurs, à savoir 0 et 1.



    Citation Envoyé par dazzle
    Je réfléchis à utiliser l'autoincrement pour les clés primaires... est-ce une bonne idée ? Connaissez vous une autre méthode pour générer des identifiants uniques ?
    Je connais d’autres méthodes, mais compliquées et nécessitant de bonnes compétences en assembleur (instruction STCK, en assembleur 370 IBM (mainframe) pour ce qui me concerne), donc je ne vais aller plus avant. Certains SGBD proposent l’instruction CREATE SEQUENCE, mais pas MySQL... Vous pouvez utiliser l’auto-incrémentation.



    Citation Envoyé par dazzle
    Les dons des adhérents (par exemple), sont identifiés par id_adherent, ce qui est cohérent avec ce dont nous avions discuté, à savoir l'identification relative pour les dons. Mais cela ne va-t-il pas poser problème, en particulier si un adhérent fait plusieurs dons ? L'identification par id_adherent seul serait alors insuffisante, ou quelque chose m'échappe
    Bien vu, Œil-de-Lynx ! Il est évident que mon MCD est incomplet, quant à l’entité-type ADH_DON. Voici ce qu’on doit lire :






    D’où le code SQL :


    
    CREATE TABLE ADH_DON 
    (
       id_adherent          INT               NOT NULL,
       id_adh_don           INT               NOT NULL    DEFAULT 0,
       date_adh_don         DATE              NOT NULL,
       montant_adh_don      DECIMAL(7,2)      NOT NULL,
       commentaires_adh_don VARCHAR(64)       NOT NULL,
       CONSTRAINT ADH_DON_PK PRIMARY KEY (id_adherent, id_adh_don),
       CONSTRAINT ADH_DON_ADHERENT_FK FOREIGN KEY (id_adherent)
          REFERENCES ADHERENT (id_adherent)
    ) ;
    
    
    L’attribut id_adh_don est sujet à auto-incrémentation relative (commence à 1 pour chaque adhérent) mais ceci entraîne la mise en œuvre d’un trigger ad-hoc :

    
    DELIMITER GO
    
    CREATE TRIGGER ADH_DON_INSERT_BEFORE BEFORE INSERT ON ADH_DON 
    FOR EACH ROW
        BEGIN
            SET new.id_adh_don = (SELECT COALESCE(MAX(id_adh_don) + 1, 1)
                                  FROM   ADH_DON
                                  WHERE  id_adherent = new.id_adherent
                                 ) ;        
        END
    GO
    
    DELIMITER ;
    
    
    Exemple :

    
    INSERT INTO ADH_DON (id_adherent, date_adh_don, montant_adh_don, commentaires_adh_don) VALUES (1, '2016-02-21', 100, 'généreux') ;
    
    INSERT INTO ADH_DON (id_adherent, date_adh_don, montant_adh_don, commentaires_adh_don) VALUES (2, '2016-02-19', 150, 'néant') ;
    
    INSERT INTO ADH_DON (id_adherent, date_adh_don, montant_adh_don, commentaires_adh_don) VALUES (1, '2016-02-22', 200, 'ras') ;
    
    
    Un coup d’oeil :

    
    SELECT * from ADH_DON ;
    
    
    =>

    
    id_adherent   id_adh_don   date_adh_don   montant_adh_don   commentaires_adh_don
    -----------   ----------   ------------   ---------------   --------------------
    1             1            2016-02-21     100.00            généreux
    1             2            2016-02-22     200.00            ras
    2             1            2016-02-19     150.00            néant
    
    
    Mais si deux transactions sont en concurrence, il peut y avoir collision...

    Pour éviter d’avoir à mettre en œuvre le trigger, on peut en passer par l’auto-incrémentation absolue, et ça n’est pas grave, même si en réalité la paire {id_adherent, id_adh_don} est une surclé plutôt qu’une clé primaire au sens théorique (tandis que ce clancul de MySQL exige à tort que l’attribut id_adh_don fasse l’objet d’une clé candidate, mais bon, ça n’est pas trop grave...) :


    
    CREATE TABLE ADH_DON 
    (
       id_adherent          INT               NOT NULL,
       id_adh_don           INT               NOT NULL AUTO_INCREMENT,
       date_adh_don         DATE              NOT NULL,
       montant_adh_don      DECIMAL(7,2)      NOT NULL,
       commentaires_adh_don VARCHAR(64)       NOT NULL,
       CONSTRAINT ADH_DON_PK PRIMARY KEY (id_adherent, id_adh_don),
       CONSTRAINT ADH_DON_UK UNIQUE (id_adh_don),   
       CONSTRAINT ADH_DON_ADHERENT_FK FOREIGN KEY (id_adherent)
          REFERENCES ADHERENT (id_adherent)
    ) ;
    
    
    Le résultat ne varie que par les valeurs prises par l’attribut id_adh_don, ce qui n’est pas un problème :

    
    id_adherent   id_adh_don   date_adh_don   montant_adh_don   commentaires_adh_don
    -----------   ----------   ------------   ---------------   --------------------
    1             1            2016-02-21     100.00            généreux
    1             3            2016-02-22     200.00            ras
    2             2            2016-02-19     150.00            néant
    
    
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  19. #19
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2013
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Février 2013
    Messages : 13
    Points : 12
    Points
    12
    Par défaut
    Bonjour fsmrel,

    Merci pour vos réponses ! Je vais utiliser l'autoincrémentation absolue pour les dons, ça sera plus simple et les conséquences sur le fonctionnement de la base semblent négligeable dans notre situation.

    Et surtout un grand merci pour votre aide précieuse à la construction de cette base de données !! J'apprécie beaucoup le fait que vous ayez pris le temps de voir l'ensemble des problèmes et améliorations possibles en dehors de la question initiale et je pense qu'on va pouvoir mettre tout ça en service d'ici peu !

  20. #20
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonjour dazzle,


    Bonne route ! Et en cas de problème, vous connaissez la maison où l'on répare les tables
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 11
    Dernier message: 15/06/2011, 16h10
  2. [MCD] Association ternaire et CIF
    Par Nillak dans le forum Schéma
    Réponses: 7
    Dernier message: 22/04/2008, 13h36
  3. Réponses: 8
    Dernier message: 25/01/2008, 14h38
  4. Pb avec une association ternaire
    Par jamy79 dans le forum Hibernate
    Réponses: 1
    Dernier message: 20/11/2006, 11h38
  5. Réponses: 1
    Dernier message: 17/10/2006, 20h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo