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 :

MCD Réservation d'un services


Sujet :

Schéma

  1. #1
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    405
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2017
    Messages : 405
    Points : 508
    Points
    508
    Par défaut MCD Réservation d'un services
    Bonjour/Bonsoir les développeurs, je viens d’être recruté dans une petite entreprise qui s’occupe de l’organisation des événements(Mariages, baptêmes, anniversaires, etc.)
    Pour cela, elle met à la disposition des clients :
    - Des salles de fêtes ;
    - Le service traiteur ;
    - Les décorations ;
    - La sonorisation.
    Pour avoir l’un des service, un client passe sa réservation en ligne et la commande est validée par un administrateur de la plateforme.
    Je vous présente ici le MCD de la future base de données qui va stocker les données de la plateforme.

    Nom : MCD.PNG
Affichages : 91
Taille : 28,5 Ko
    Merci pour vos lumières.

    Cordialement

  2. #2
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    5 253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 5 253
    Points : 15 526
    Points
    15 526
    Billets dans le blog
    1
    Par défaut
    Bonsoir Manequin,

    Le MCD doit être le reflet exact des règles de gestion collectées auprès de et validées par les experts du métier.
    Or vous n'avez communiqué aucune règle de gestion, il faut donc commencer par la.

    Sinon quelques remarques
    Cardinalités mini
    Si le mini est zéro, alors l'association est obligatoire.
    Ainsi, d'après votre MCD, un fournisseur ne peut être créé que s'il livre au moins un produit. Est-ce ce que vous souhaitez ? Ne doit on pas pouvoir créer un fournisseur qui ne livre pas encore de produits mais qu'on souhaite référencer ? Ce sont les règles de gestion validées par les experts métiers qui pourraient le dire...
    De même, pour les typologies, on applique en général une cardinalité mini de zéro coté typologie.
    Par exemple, rien ne garantit que tous les états de commandes sont présents simultanément à un instant 't' dans la base, d'où un modèle le plus souvent comme suit :
    COMMANDE 1,1 --- STATUER --- 0,n ETAT_COMMANDE
    Même remarque concernant les catégories de produits

    Client
    L'adresse n'est pas un attribut, mais un groupe d'attributs, normés par la poste pour ce qui concerne les adresses françaises.
    Une petite recherche sur le web vous permettra de retrouver facilement et gratuitement cette norme
    Attention : positionner l'adresse au niveau du client signifie que tout client possède une et une seule adresse. Est-ce votre cas ? on n'en sait rien faute de règles de gestion...
    Dans la négative, ce qui est probable (souvent il faut prévoir une adresse de facturation, une ou plusieurs adresses de livraison, une adresse du siège social...), il faut modéliser ainsi :
    CLIENT 0,n --- posseder --- (1,1) ADRESSE 1,1 --- typer --- 0,n TYPE_ADRESSE
    Avec 0 en cardinalité mini coté client, si, pour certains clients, l'absence d'adresse est possible, 1 sinon (encore une fois, seule la règle de gestion permettrait de le savoir)
    Les parenthèses autour des cardinalités des adresses vers les client matérialisent l'identification des adresses relativement aux clients (sans client, l'adresse n'existerait pas)
    Chaque adresse a un type (adresse de livraison, de facturation, de correspondance, du siège...)

    Commande et produit
    Sauf si toutes vos commandes sont mono-produit (devinez quoi... les règles de gestion manquent encore ), il manque une entité-type "LIGNE_COMMANDE" qui permettra de rapprocher la facturation et les règlements.
    Le modèle classique est le suivant
    COMMANDE 1,n --- posseder --- (1,1) LIGNE_COMMANDE 1,1 --- concerner --- 0,n PRODUIT
    Là encore, la ligne de commande est identifiée relativement à la commande dont elle dépend (parenthèses autour des cardinalités)
    Les attributs de COMMANDE restent le numéro de commande et sa date alors que la LIGNE_COMMANDE aura pour attribut la quantité commandée (en lien bien sur avec l'article avec laquelle cette ligne est en relation)

    Gestion des personnes
    Toutes les personnes, clients, fournisseurs, administrateurs, tiers... partagent des attributs en commun.
    Il faut donc utiliser l'héritage avec, dans le surtype, les attributs communs à toutes les personnes et, dans chaque sous-type ce qui est spécifique aux fournisseurs, aux clients, aux administrateurs...
    Voir ici pour la modélisation d'un héritage

    Client et Facture
    Le modèle adhoc pour le règlement des factures est le suivant
    CLIENT 0,n --- effectuer --- 1,1 REGLEMENT 1,n --- concerner --- 0,n FACTURE
    ................................................1,1│
    .....................................................└---utiliser --- 0,n MOYEN_PAIEMENT
    Là encore, les cardinalités dépendent des règles de gestion (une facture peut elle être réglée en plusieurs fois ?...)
    Les attributs de l'entité-type REGLEMENT sont la date du règlement, la devise, le montant
    Le moyen de paiement, en lien avec le règlement, permet d'identifier si le paiement est effectué en espèces, par chèque, traite, billet à ordre ou tout autre moyen


    Produit
    Il ne faut surtout pas répéter l'attribut "photo", la modélisation doit être la suivante
    PRODUIT 0,n --- représenter ---(1,1) PHOTO
    Là encore, la photo n'existe que si le produit existe, d'où l'identification relative matérialisée par les parenthèses

  3. #3
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    405
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2017
    Messages : 405
    Points : 508
    Points
    508
    Par défaut
    Merci beaucoup pour votre prompte réaction et de votre brillant exposé.
    je vais écrire les règles de gestion et modifier le MCD pour proposer demain.

    Merci encore.

    Cordialement.

  4. #4
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    405
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2017
    Messages : 405
    Points : 508
    Points
    508
    Par défaut
    Bonjour les développeurs,

    Règles de gestion
    - Un client peut passer la réservation de location d’une salle de fête à une date donnée et durant une plage horaire donnée.
    - Un client peut passer la réservation de location d’un service traiteur à une date donnée et durant une plage horaire donnée.
    - Un client peut passer la réservation de location d’une décoration à une date donnée et durant une plage horaire donnée.
    - Un client peut passer la réservation de location d’une sonorisation à une date donnée et durant une plage horaire donnée.
    - Un client peut passer la réservation de location d’une salle de fête ,d’un service traiteur, d’une décoration et d’une sonorisation à une date donnée et durant une plage horaire donnée.
    - Un client peut annulée sa réservation.
    - Administrateur valide les réservations passées par les clients. Une réservation peut-être : en cours, livrée ou annulée.
    - Un fournisseur peut être enregistré même s’il n’a pas de produit à livrer.
    - Un produit appartient à une et une seule catégorie.
    - Une ligne de commande peut concerner plusieurs produits.
    - Un client peut régler sa facture par virement, par chèque, par mobile money ou par orange money.
    - Plusieurs clients peuvent passer la réservation d’une même salle de fêtes ou d’un autre service le même si leur plage horaire est différente.(Exemple : un client peut passer la réservation de la salle des fêtes le 31/12/2019 de 8h à 12h. L’autre sollicite la même salle de fête de 13h à 16h).

    Nom : MCD1.PNG
Affichages : 67
Taille : 41,6 Ko

    Cordialement.

  5. #5
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    5 253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 5 253
    Points : 15 526
    Points
    15 526
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    Il n'y a guère de développeurs qui traînent leur guêtres dans ce secteur, mais ça n'est pas grave


    Les règles de gestion pointent le bout de leur nez
    Mais...
    On peut il faut encore améliorer ça :
    • pour chaque association, il faut à minima une règle par "patte", soit, pour une association binaire, 2 règles de gestion.
      Par exemple, pour la relation (effectuer) entre [CLIENT] et [REGLEMENT] les règles correspondant aux cardinalités du MCD sont
      - un client peut effectuer plusieurs règlements
      - un règlement est effectué par un et un seul client
      Le verbe utilisé pour nommer l'association étant repris pour décrire ces règles de gestion
    • dans certains cas, des règles de gestion supplémentaires sont requises, par exemple :
      - pour décrire les dépendances entre associations (ex : seul le client qui passe la commande peut effectuer le règlement)
      - pour décrire les dépendances entre les sous-types (ex : un client peut également être un fournisseur ou encore, un administrateur ne peut être ni client ni fournisseur)
    • à chaque règle de gestion, on attribue un n°, ce qui en permettra un suivi plus aisé, par exemple :
      R001 : un client peut effectuer plusieurs règlements
      R002 : un règlement est effectué par un et un seul client


    Vos premières règles de gestion décrivent les différents types de prestation possibles (chacun fera l'objet d'une ligne de commande), il n'est pas nécessaire de faire une règle pour chaque type sauf si certains types ont des règles particulières ce qui ne semble pas être le cas. Est-ce que lorsqu'un client réserve plusieurs prestations (une salle, une sono, une déco...) toutes ces prestations couvrent la même période ?
    Selon le cas, la période sera attribut de la commande ou de la ligne de commande.


    Quelques autres remarques :
    Personne
    Puisque vous avez créé une relation entre la personne et le sexe, alors l'attribut sexe n'a plus sa place dans l'entité-type personne
    Une autre solution pour ce genre d'attributs dont la liste de valeurs possible est très restreinte, est de ne pas modéliser d'entité-type sexe, mais de créer une contrainte de type "check".


    Produit
    Attention : l'attribut caractéristiques mis au pluriel laisse à penser qu'il s'agirait d'une liste de valeurs. À ne surtout pas faire.
    Si nécessaire, créez un nouveau type d'entité et une nouvelle association : [PRODUIT]1,n --- (caractériser) ---0,n [CARACTERISTIQUES]
    Vu que le prix est un attribut de produit, alors il est invariant quelque soit la quantité, le client, la date... ce qui est rarement le cas. À vérifier.


    Symbolique utilisée
    Attention : l'usage des flèches est réservé aux CIF, les pattes des associations ne doivent pas être fléché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
    6 911
    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 : 6 911
    Points : 25 884
    Points
    25 884
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Citation Envoyé par escartefigue Voir le message
    Il n'y a guère de développeurs qui traînent leur guêtres
    Untel traîne ses guêtres dans les salles d’opération (quand il arrive à franchir les défilés des manifestants se trouvant sur sa route) et préférerait les traîner chez DVP ; en tout cas dans ce genre de situation, la bilocation est impossible...


    Citation Envoyé par escartefigue Voir le message
    Attention : l'usage des flèches est réservé aux CIF, les pattes des associations ne doivent pas être fléchées
    Il n’y a pas franchement de norme Merise à ce sujet. L’AFCET se sert de la flèche pour les identifiants relatifs et pour sa part, Nanci (papa de WinDesign) l’utilise pour les dépendances fonctionnelles merisiennes (cf. Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), page 116, figure 7.22). La dépendance fonctionnelle merisienne n’a qu’un vague rapport avec la dépendance fonctionnelle de la théorie relationnelle (va justifier l’axiome d’augmentation chez Merise, alors qu’il est fondamental en relationnel, sans lui pas de théorie des dépendances, impossibilité de calculer les fermetures des DF, donc l’ensemble des clés, donc de vérifier la BCNF, etc...)


    Je vais essayer de trouver un creux pour voir le problème des recouvrements d’intervalles et des bilocations (par exemple, deux clients effectuant la même réservation de salle à T).

     
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  7. #7
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 911
    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 : 6 911
    Points : 25 884
    Points
    25 884
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par Manequin Voir le message
    Une ligne de commande peut concerner plusieurs produits.
    Il est d’usage qu’une ligne de commande concerne au moins et au plus un produit.


    Une réservation est à considérer comme un produit, d’accord. Y a-t-il des produits autres, c’est-à-dire qui ne sont pas concernés par la dimension temporelle (intervalles de temps) ? (par exemple un bouquet de fleurs, un gâteau, etc.)


     
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  8. #8
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    405
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2017
    Messages : 405
    Points : 508
    Points
    508
    Par défaut
    Bonsoir les développeurs. Une fois de plus merci pour votre précieux temps.

    Règles de gestion revues
    RG 1 : Un client passe au moins une commande et peut passer plusieurs.
    RG 2 : Une commande est passée par au plus un client.
    RG 3 : un client effectue peut ne pas effectuer un règlement et peut effectuer plusieurs règlements.
    RG 3 : un règlement est effectuer par au plus un client.
    RG 4 : un règlement concerne au moins une facture.
    RG 5 : un règlement utilise un et un seul moyen de payement.
    RG 6 : une facture peut ne pas être concernée par un règlement et peut être réglé plusieurs fois.
    RG 7 : un mode de paiement peut ne pas être utilisé et peut utiliser par un règlement.
    RG 8 : une facture appartient au moins à une commande.
    RG 9 : une commande appartient au moins à une facture.
    RG 10 : une commande est validée par un et un seul administrateur.
    RG 11 : un administrateur valide au moins un commande.
    RG 12 : une commande est concernée un et un seul état.
    RG 13 : Un état commande peut ne pas être concerné par une commande et peut être concernée par plusieurs commande.
    RG 14 : une commande possède au moins une ligne de commande.
    RG 15 : une ligne de commande est possédée par une et une seule commande.
    RG 16 : une ligne de commande contient au plus un produit.
    RG 17 : un produit ne pas contenir une ligne de commande et peut contenir plusieurs lignes de commande.
    RG 18 : un produit appartient à une et une seule catégorie.
    RG 19 : une catégorie peut pas avoir de produit et peut avoirs plusieurs produits.
    RG 20 : un produit peut ne pas être représenté par une photo et peut être représenté par plusieurs photos.
    RG 21 : une photo est représentée par un et un seul produit.
    RG 22 : un fournisseur peut ne pas livrer un produit et peut livrer plusieurs produits.
    RG 23 : un produit est livré par au moins un fournisseur.
    RG 24 : seul le client qui passe la commande peut effectuer le règlement
    RG 25 : un client peut également être un fournisseur.
    RG 26 : un administrateur ne peut être ni client ni fournisseur.


    MCD revu
    Nom : MCD2.PNG
Affichages : 62
Taille : 40,2 Ko

    Cordialement !

  9. #9
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    5 253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 5 253
    Points : 15 526
    Points
    15 526
    Billets dans le blog
    1
    Par défaut
    Bonsoir,

    Puisque la règle 25 stipule :
    RG 25 : un client peut également être un fournisseur
    et que la règle 26 indique :
    RG 26 : un administrateur ne peut être ni client ni fournisseur.
    Alors il faut modifier l'héritage
    première spécialisation (XT) : administrateur ou non administrateur
    deuxième spécialisation qui concerne les non administrateurs seulement (T) client et/ou fournisseur

    @Fsmrel : bon courage, ça doit pas être marrant de devoir ajouter les soucis de santé aux soucis de transport, surtout à Paris
    et, quand je disais qu'il n'y avait guère de développeurs... je ne parlais pas tant du nombre de contributeurs dans cette section, mais plutôt du fait que ce sont rarement les développeurs qui participent à l'élaboration du modèle de données

    @Manequin : vous n'avez pas tenu compte de mes remarques précédentes dans votre nouveau MCD. Mais bon, pour l'instant, priorité aux règles de gestion

  10. #10
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    405
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2017
    Messages : 405
    Points : 508
    Points
    508
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    ... quand je disais qu'il n'y avait guère de développeurs... je ne parlais pas tant du nombre de contributeurs dans cette section, mais plutôt du fait que ce sont rarement les développeurs qui participent à l'élaboration du modèle de données
    Les employeurs ne comprennent pas ça comme ça ici à Yaoundé.

    @Manequin : vous n'avez pas tenu compte de mes remarques précédentes dans votre nouveau MCD. Mais bon, pour l'instant, priorité aux règles de gestion
    J'apporte les modifications demain.

    Cordialement.

  11. #11
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    405
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2017
    Messages : 405
    Points : 508
    Points
    508
    Par défaut
    MCD revue :

    Nom : MCD3.PNG
Affichages : 48
Taille : 39,6 Ko

    Cordialement.

  12. #12
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 911
    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 : 6 911
    Points : 25 884
    Points
    25 884
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    On déboule manifestement sur la modélisation du lettrage (rapprochement des lignes de commande et des lignes de facture), telle qu’en parle brièvement Michel Diviné dans Parlez-vous Merise ?, pages 58,59.

    La partie correspondante du MCD pourrait être celle-ci :

    Nom : manequin_mcd_lettrage.png
Affichages : 46
Taille : 26,4 Ko


    Le code SQL correspondant étant celui-ci (ce que produit l’AGL étant à retoucher, car n’étant pas à même de produire exactement ce code) où — grâce à la propagation systématique de l’attribut personneId par l’identification relative des entités-types — l’on sait démontrer que les lignes de commande et de facture sont bien celles d’un même client, ainsi que les règlements :

    CREATE TABLE PERSONNE
    (
            personneId            INTEGER           NOT NULL
          , personneNom           VARCHAR(48)       NOT NULL
          , personeAdresse        VARCHAR(48)       NOT NULL
        , CONSTRAINT PERSONNE_PK PRIMARY KEY(personneId)
    );
    
    CREATE TABLE FOURNISSEUR
    (
            personneId            INTEGER           NOT NULL
          , tauxRemise            NUMERIC(4,2)      NOT NULL
        , CONSTRAINT FOURNISSEUR_PK PRIMARY KEY(personneId)
        , CONSTRAINT FOURNISSEUR_PERSONNE_FK FOREIGN KEY(personneId) 
              REFERENCES PERSONNE(personneId) 
                  ON DELETE CASCADE
    );
    
    CREATE TABLE CLIENT
    (
            personneId            INTEGER           NOT NULL
          , conditionsTarifaires  VARCHAR(48)       NOT NULL
        , CONSTRAINT CLIENT_PK PRIMARY KEY(personneId)
        , CONSTRAINT CLIENT_PERSONNE_FK FOREIGN KEY(personneId) 
              REFERENCES PERSONNE(personneId) 
                  ON DELETE CASCADE
    );
    
    CREATE TABLE COMMANDE
    (
            personneId            INTEGER           NOT NULL
          , commandeId            INTEGER           NOT NULL
          , commandeNo            CHAR(12)          NOT NULL 
          , commandeDate          DATE              NOT NULL
          , commandeMontant       INTEGER           NOT NULL
        , CONSTRAINT COMMANDE_PK PRIMARY KEY(personneId, commandeId)
        , CONSTRAINT COMMANDE_AK UNIQUE(commandeNo)
        , CONSTRAINT COMMANDE_CLIENT_FK FOREIGN KEY(personneId) 
              REFERENCES CLIENT(personneId)
    );
    
    CREATE TABLE LIGNE_COMMANDE
    (
            personneId            INTEGER           NOT NULL
          , commandeId            INTEGER           NOT NULL
          , ligneCommandeId       INTEGER           NOT NULL
          , quantiteCommandee     INTEGER           NOT NULL
          , livraisonDate         DATE              NOT NULL
        , CONSTRAINT LIGNE_COMMANDE_PK PRIMARY KEY(personneId, ligneCommandeId)
        , CONSTRAINT LIGNE_COMMANDE_COMMANDE_FK FOREIGN KEY(personneId, commandeId) 
              REFERENCES COMMANDE(personneId, commandeId)
    );
    
    CREATE TABLE FACTURE
    (
            personneId            INTEGER           NOT NULL
          , factureId             INTEGER           NOT NULL
          , factureNo             CHAR(12)          NOT NULL
          , factureDate           DATE              NOT NULL
          , factureMontant        INTEGER           NOT NULL
        , CONSTRAINT FACTURE_PK PRIMARY KEY(personneId, factureId)
        , CONSTRAINT FACTURE_AK UNIQUE(factureNo)
        , CONSTRAINT FACTURE_CLIENT_FK FOREIGN KEY(personneId) 
              REFERENCES CLIENT(personneId)
    );
    
    CREATE TABLE REGLEMENT
    (
            personneId            INTEGER           NOT NULL
          , reglementId           INTEGER           NOT NULL
          , reglementDate         DATE              NOT NULL
          , reglementMontant      INTEGER           NOT NULL
        , CONSTRAINT REGLEMENT_PK PRIMARY KEY (personneId, reglementId)
        , CONSTRAINT REGLEMENT_CLIENT_FK FOREIGN KEY(personneId)
              REFERENCES CLIENT(personneId)
    );
    
    CREATE TABLE LIGNE_FACTURE
    (
            personneId            INTEGER           NOT NULL
          , factureId             INTEGER           NOT NULL
          , ligneFactureId        INTEGER           NOT NULL
          , reglementId           INTEGER           NOT NULL
          , quantiteFacturee      INTEGER           NOT NULL
        , CONSTRAINT LIGNE_FACTURE_PK PRIMARY KEY(personneId, ligneFactureId)
        , CONSTRAINT LIGNE_FACTURE_FACTURE_FK FOREIGN KEY(personneId, factureId) 
              REFERENCES FACTURE(personneId, factureId)
        , CONSTRAINT LIGNE_FACTURE_REGLEMENT_FK FOREIGN KEY(personneId, reglementId) 
              REFERENCES REGLEMENT(personneId, reglementId)
    );
    
    CREATE TABLE LETTRAGE
    (
            personneId            INTEGER           NOT NULL
          , ligneCommandeId       INTEGER           NOT NULL
          , ligneFactureId        INTEGER           NOT NULL
        , CONSTRAINT LETTRAGE_PK PRIMARY KEY(personneId, ligneCommandeId, ligneFactureId)
        , CONSTRAINT LETTRAGE_LIGNE_COMMANDE_FK FOREIGN KEY(personneId, ligneCommandeId) 
              REFERENCES LIGNE_COMMANDE(personneId, ligneCommandeId)
        , CONSTRAINT LETTRAGE_LIGNE_FACTURE_FK FOREIGN KEY(personneId, ligneFactureId) 
              REFERENCES LIGNE_FACTURE(personneId, ligneFactureId)
    );
    

     
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  13. #13
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    5 253
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 5 253
    Points : 15 526
    Points
    15 526
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    Au sujet des personnes et des adresses.

    On a vu que les règles de gestion 25 et 26 stipulent qu'un client peut être aussi fournisseur, mais qu'un administrateur n'est ni l'un ni l'autre.
    Par ailleurs, un client comme un fournisseur peuvent être des personnes physique (avec un nom, prénom, date de naissance...) ou morale (avec un SIREN, NIC, code NAF, une raison sociale...)
    Il faut donc utiliser l'héritage pour distinguer les PP des PM dont les attributs sont très différents et attribuer des rôles pour lequels on contrôlera, par trigger, qu'il n'y a pas de chevauchement de période entre une période ADMINISTRATEUR et une période d'un autre rôle.
    Dans la table issue de l'association EXERCER, on ajoutera la colonne EX_dtdeb comme composante de la PK (en plus de l'identifiant personne et de l'identifiant rôle)

    De plus, les clients et fournisseurs de type personne morale ont le plus souvent plusieurs adresses (de livraison, de facturation, de correspondance, de gestion du contentieux...)
    d'où l'intérêt d'identifier une entité-type adresse, en lien avec un type d'adresse et dans laquelle on en profite pour appliquer une norme de codification des adresses (ici celle de la poste, à adapter si contexte internationnal)

    Nom : Sans titre.png
Affichages : 41
Taille : 40,4 Ko

    Norme des adresses postales : https://www.presse-poste.laposte.fr/...s%20plis_3.pdf

Discussions similaires

  1. [MCD] MCD Réservation d'activité
    Par deteklover dans le forum Schéma
    Réponses: 8
    Dernier message: 05/03/2014, 20h14
  2. [AC-2007] MCD Réservation d'une chambre d'hotel F1
    Par andy331 dans le forum Modélisation
    Réponses: 1
    Dernier message: 05/03/2010, 17h24
  3. [Normalisation] Normalisation MCD service technique
    Par merise_lover dans le forum Schéma
    Réponses: 42
    Dernier message: 30/04/2008, 11h55
  4. [MCD] Système de réservation
    Par Le_Kosovar dans le forum Schéma
    Réponses: 2
    Dernier message: 23/05/2007, 13h38
  5. Réponses: 2
    Dernier message: 07/05/2007, 12h30

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