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

  1. #1
    Membre habitué
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    399
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juin 2004
    Messages : 399
    Points : 166
    Points
    166
    Par défaut MERISE et archivage ou autres façons de faire..
    Bonjour,

    Je me pose souvent le meme questionnement quand je conçois un modèle suivant la méthode MERISE, et ça m'embête vraiment. Je prends un exemple :

    J'ai une appli de gestion des commandes fournisseur.
    table COMMANDE : idcommande en clé primaire, idfournisseur en clé étrangère
    table FOURNISSEUR : idfournisseur en clé primaire

    J'enregistre un fournisseur, puis une commande chez ce fournisseur.
    Quelque temps après, le fournisseur change d'adresse
    Si je ressors le bon de commande déjà effectué, je vais avoir sur mon état la nouvelle adresse et pas l'ancienne. Alors que je veux ressortir le bon de commande exact tel qu'il a été fait.

    Donc pour palier à ça :
    - soit j'enregistre en dur dans ma table commande l'adresse du fournisseur. Mais du coup, on oublie la logique MERISE...
    - soit je crée une table COMMANDE_ARCHIVEES avec l'adresse du fournisseur en dur quand la commande est définitive mais ca m'oblige à faire une gestion lourde pour sortir les bons de comande archivés et les autres..

    Après recherche dans le forum, j'ai noté qu'on pouvait créer une table ADRESSE, ce qui résoud le problème ci dessus.
    Mais...
    Ce n'est pas un exemple que j'ai rencontré mais j'ai pris celui là parceque j'ai voulu prendre une appli de gestion courante. Mais j'ai ce genre de problème partout. Notamment en ce moment dans une appli de gestion de déclaration fiscale. Il y a plein de clés étrangères dans ma table de DECLARATION --> et je me demande si je dois laisser mes clés étrangères et gérer un archivage quand les déclarations sont définitives ou si je dois remplacer mes clés étrangères et écrire en dur les données liées (mais dans ce cas là la logique MERISE ne sert plus)

    En espérant avoir été clair. Merci de votre avis.

  2. #2
    Membre éprouvé Avatar de Paprick
    Homme Profil pro
    Professeur des Universités
    Inscrit en
    juin 2019
    Messages
    293
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Professeur des Universités
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2019
    Messages : 293
    Points : 1 143
    Points
    1 143
    Par défaut
    Bonsoir,

    Le logique Merise n'est pas mise en péril par ces questions d'archivage.
    Le plus important, pour commencer, est de définir correctement le dictionnaire des données : dans votre cas, on retrouvera (pour faire simple) une rubrique "Adresse courante" à placer dans la classe d'entités 'Fournisseur", et une rubrique "Adresse commande" qui sera conservée, soit dans la classe "Commande" (avec le risque de voir certaines redondances), soit dans une classe d'historisation des adresses (avec une gestion beaucoup plus lourde du modèle).
    Ce sont des situations que l'on rencontre régulièrement ; prenez par exemple le prix d'un produit : il est nécessaire de le stocker dans la commande car il peut évoluer à tout moment et générer une erreur en cas de duplicata de la commande (on aura donc, dans le dictionnaire des données, un prix courant et un prix commande).

    Enfin, avant de parler de clés étrangères et autres considérations techniques, réalisez votre modèle conceptuel de données (MCD) : c'est la première étape pour une bonne organisation des données ; le modèle logique (MLD) et le code SQL permettant la génération du schéma relationnel sur le SGBD de votre choix, se déduiront automatiquement de ce MCD.
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  3. #3
    Membre habitué
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    399
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juin 2004
    Messages : 399
    Points : 166
    Points
    166
    Par défaut
    Merci paprick pour votre réponse.
    En fait, j'arrive assez bien à concevoir les MCD (enfin je crois...) mais c'est une fois que je commence le développement que je me pose des questions.
    Si je prends l'exemple de l'application de gestion de déclaration fiscale que je développe en ce moment :

    Une déclaration nécessite la saisie d'un certain nombre de factures.
    Pour saisir une facture, il faut lui attribuer un certains nombre de caractéristiques (comme un régime de transaction par exemple, qui est une notion fiscale)
    J'ai donc une table FACTURE, une table REGIME, avec FACTURE 1,1 --> REGIME 1,n.
    Dans mon MLD, j'ai un idregime dans ma table FACTURE.
    Jusque là tout va bien.
    Je saisi mes factures en leur attribuant un idregime.
    Si dans 3 mois,l'administration supprime un régime fiscal, je ne peux pas supprimer mon régime de ma table, car il est lié aux factures précédentes.

    Est ce que vous remplaceriez dans ma table FACTURE, mon idregime par un champ regime en dur, afin de pouvoir supprimer le régime dans ma table REGIME et garder une table REGIME à jour ? (mais dans ce cas là j'ai plus de relation entre les tables)

    Est ce que vous feriez une table FACTURE ARCHIVEE une fois que la facture est définitive, avec un champ regime en dur dans ma table archive (mais dans ce cas là il faut que je gère des écrans pour les archives et les autres)

    Est ce que vous empecheriez de supprimer un régime en rajoutant des champs date début et de fin de validité dans ma table REGIME (mais dans ce cas là, il faut que je rajoute des dates début et de fin de validité dans toutes mes tables, parceque la problématique est la même partout) ?

    J'ai été un peu long, désolé
    Merci d'avance

  4. #4
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 121
    Points : 4 595
    Points
    4 595
    Par défaut
    Bonsoir devdev et Paprick,

    Ce n'est pas parce qu'un statut n'est plus valable qu'il faut, nécessairement, le supprimer PHYSIQUEMENT dans la table concernée : une suppression LOGIQUE est plus pertinente. Cela peut-être résolu par un flag booléen (supprimé O/N) ou par l'ajout d'autres informations qui, par leur présence, indiquerait que le statut n'est plus valide.

    Pour reprendre tes exemples :

    J'ai une appli de gestion des commandes fournisseur.
    table COMMANDE : idcommande en clé primaire, idfournisseur en clé étrangère
    table FOURNISSEUR : idfournisseur en clé primaireUne déclaration nécessite la saisie d'un certain nombre de factures.
    Pour saisir une facture, il faut lui attribuer un certains nombre de caractéristiques (comme un régime de transaction par exemple, qui est une notion fiscale)
    J'ai donc une table FACTURE, une table REGIME, avec FACTURE 1,1 --> REGIME 1,n.
    Dans mon MLD, j'ai un idregime dans ma table FACTURE.
    Jusque là tout va bien.
    Je saisi mes factures en leur attribuant un idregime.
    Si dans 3 mois,l'administration supprime un régime fiscal, je ne peux pas supprimer mon régime de ma table, car il est lié aux factures précédentes.

    J'enregistre un fournisseur, puis une commande chez ce fournisseur.
    Quelque temps après, le fournisseur change d'adresse
    Si je ressors le bon de commande déjà effectué, je vais avoir sur mon état la nouvelle adresse et pas l'ancienne. Alors que je veux ressortir le bon de commande exact tel qu'il a été fait.

    Donc pour palier à ça :
    - soit j'enregistre en dur dans ma table commande l'adresse du fournisseur. Mais du coup, on oublie la logique MERISE...
    - soit je crée une table COMMANDE_ARCHIVEES avec l'adresse du fournisseur en dur quand la commande est définitive mais ca m'oblige à faire une gestion lourde pour sortir les bons de comande archivés et les autres..
    ==> il manque une troisième possibilité :
    - créer une table ADRESSE avec, en clé primaire, Id_Adresse, et Id_Fournisseur en clé étrangère.
    De ce fait, les Id_Adresse sont toujours retrouvés dans la table COMMANDE et aucun besoin, de mon point de vue, d'une table COMMANDE_ARCHIVEE.

    Une déclaration nécessite la saisie d'un certain nombre de factures.
    Pour saisir une facture, il faut lui attribuer un certains nombre de caractéristiques (comme un régime de transaction par exemple, qui est une notion fiscale)
    J'ai donc une table FACTURE, une table REGIME, avec FACTURE 1,1 --> REGIME 1,n.
    Dans mon MLD, j'ai un idregime dans ma table FACTURE.
    Jusque là tout va bien.
    Je saisi mes factures en leur attribuant un idregime.
    Si dans 3 mois,l'administration supprime un régime fiscal, je ne peux pas supprimer mon régime de ma table, car il est lié aux factures précédentes.
    ==> Dans la table REGIME (Id_Regime en clé primaire), créer un champ booléen Supprime (O/N) ou une date de suppression par l'administration ou autre...
    Il est à noter qu'il serait très surprenant que l'administration supprime PHYSIQUEMENT le régime en question de leur base de données...
    Et, aucun besoin, de mon point de vue, d'une table FACTURE_ARCHIVEE.


    Ceci, bien entendu, si j'ai bien tout compris...
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  5. #5
    Membre habitué
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    399
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juin 2004
    Messages : 399
    Points : 166
    Points
    166
    Par défaut
    Merci bcp Richard_35 pour ta réponse,

    Effectivement une case à cocher et/ou une date de suppression pour le REGIME parait pertinente.
    Je vais adopter ce principe pour les suppressions.
    Par contre pour les modifications j'ai toujours des questions, exemple :

    FACTURE 1,1 --> TIERS 1,n
    Dans ma table TIERS, j'ai un idtiers, un nom, un numéro de tva.
    Dans ma table FACTURE, j'ai un idtiers.

    Dans mes factures déclarées je dois enregistrer le numéro de tva du tiers.
    Si je déclare ces factures, et que quelque temps après, je me rends compte qu'il y a une erreur de numéro de tva pour ce tiers..
    En corrigeant ce numéro de tva dans ma table TIERS, ce numéro va se répercuter dans mes factures déjà déclarées, et ce n'est pas bon du tout.

    Donc j'ai toujours ce questionnement, est ce qu'il faut que je crée une table ARCHIVE pour ma table FACTURE DECLAREE, ou est ce que je dois mettre en dur le numéro de TVA du tiers dans ma table FACTURE. Si je mets le numéro de tva en dur, c'est la même problématique pour beaucoup de donné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
    7 396
    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 : 7 396
    Points : 27 887
    Points
    27 887
    Billets dans le blog
    16
    Par défaut
    Bonjour devdev,


    Citation Envoyé par devdev Voir le message
    FACTURE 1,1 --> TIERS 1,n
    Dans ma table TIERS, j'ai un idtiers, un nom, un numéro de tva.
    Dans ma table FACTURE, j'ai un idtiers.

    Dans mes factures déclarées je dois enregistrer le numéro de tva du tiers.
    Si je déclare ces factures, et que quelque temps après, je me rends compte qu'il y a une erreur de numéro de tva pour ce tiers.
    En corrigeant ce numéro de tva dans ma table TIERS, ce numéro va se répercuter dans mes factures déjà déclarées,
    Vous dites que dans votre table FACTURE vous avez un attribut idtiers, lequel jouerait alors le rôle de clé étrangère en relation avec la table TIERS. Le numéro de tva fait l’objet d’un attribut dans la table TIERS (appelons NumeroTva cet attribut) et joue le rôle de clé alternative et de point d’accès pour l’utilisateur. Si vous modifiez la valeur de l’attribut NumeroTva, lequel en toute logique n’existe que dans la table TIERS, alors la table FACTURE ne subit pas de modification puisque pour sa part l’attribut idtiers n’a pas changé. Donc quel sens donnez-vous à la phrase :

    « En corrigeant ce numéro de tva dans ma table TIERS, ce numéro va se répercuter dans mes factures déjà déclarées  »

    Et quelles "répercussions" précises sont à envisager ?
    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
    7 396
    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 : 7 396
    Points : 27 887
    Points
    27 887
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par devdev Voir le message
    Si dans 3 mois,l'administration supprime un régime fiscal, je ne peux pas supprimer mon régime de ma table, car il est lié aux factures précédentes.
    Il est opportun de mettre en oeuvre un historique des régimes. Exemple de MCD avec Looping, gracieusement proposé par le professeur Patrick Bergougnoux (merci Paprick !) :
    Nom : devdev(regime_historique).png
Affichages : 43
Taille : 17,5 Ko
    Le régime applicable à une facture est connu grâce à la date de celle-ci, car elle est dans l’intervalle <regimeDateDebut,regimeDateFin> défini dans l’entité-type REGIME. Notez la clé alternative {regimeCode,regimeDateDebut} mise en oeuvre pour REGIME.

    Un jeu d’essai. Les instructions "CREATE TABLE" ci-dessous sont celles qui ont été produites par Looping :

    CREATE TABLE REGIME(
       regimeId INT IDENTITY,
       regimeCode CHAR(8) NOT NULL,
       regimeDateDebut DATE NOT NULL,
       regimeDateFin DATE NOT NULL,
       regimeStatut CHAR(8) NOT NULL,
       regimeLibelle VARCHAR(48) NOT NULL,
       CONSTRAINT REGIME_PK PRIMARY KEY(regimeId),
       CONSTRAINT REGIME_1_AK UNIQUE(regimeCode, regimeDateDebut)
    );
    
    INSERT INTO REGIME (regimeCode, regimeDateDebut, regimeDateFin, regimeStatut, regimeLibelle)
    VALUES
        ('reg01', '1970-01-01', '1995-12-31', 's01', 'regime 1')
      , ('reg01', '1996-01-01', '2017-12-31', 's02', 'regime 1 revu')
      , ('reg01', '2018-01-01', '9999-12-31', 's02', 'regime 1 encore revu')
      , ('reg02', '1970-01-01', '2015-07-13', 's05a', 'regime 5 supprimé')
      , ('reg02', '2015-07-14', '9999-12-31', 's05b', 'regime 5')
    ;
    SELECT regimeCode, regimeDateDebut, regimeDateFin, regimeStatut, regimeLibelle 
    FROM REGIME
    ; 
    =>

    regimeCode   regimeDateDebut   regimeDateFin   regimeStatut   regimeLibelle
    
    reg01        1970-01-01        1995-12-31      s01            regime 1
    reg01        1996-01-01        2017-12-31      s02            regime 1 revu
    reg01        2018-01-01        9999-12-31      s02            regime 1 encore revu
    reg02        1970-01-01        2015-07-13      s05a           regime 5 supprimé
    reg02        2015-07-14        9999-12-31      s05b           regime 5
    

    CREATE TABLE FACTURE(
       factureId INT IDENTITY,
       factureNumero CHAR(16) NOT NULL,
       factureDate DATE NOT NULL,
       etc VARCHAR(48) NOT NULL,
       regimeId INT NOT NULL,
       CONSTRAINT FACTURE_PK PRIMARY KEY(factureId),
       CONSTRAINT FACTURE_AK UNIQUE(factureNumero),
       CONSTRAINT FACTURE_REGIME_FK FOREIGN KEY(regimeId) REFERENCES REGIME(regimeId)
    );
    
    INSERT INTO FACTURE (factureNumero, factureDate, regimeId, etc)
    VALUES
        (
           'fac012', '1990-02-20' 
         , (SELECT regimeId 
           FROM   REGIME 
            WHERE  regimeCode = 'reg02'
               AND regimeDateDebut <= '1990-02-20'
               AND regimeDateFin>= '1990-02-20')
         , 'etc. blabla'   
        ) ;
    
    INSERT INTO FACTURE (factureNumero, factureDate, regimeId, etc)
    VALUES
        (
           'fac125', '2021-01-15' 
         , (SELECT regimeId 
           FROM   REGIME 
            WHERE  regimeCode = 'reg02'
               AND regimeDateDebut <= '2021-01-15'
               AND regimeDateFin>= '2021-01-15')
         , 'etc. blabla'   
        ) ;
    
    SELECT factureNumero, factureDate, regimeCode, regimeStatut, regimeLibelle  
    FROM FACTURE as x
    JOIN REGIME as y on x.regimeId= y.regimeId ;
    
    =>

    factureNumero    factureDate   regimeCode   regimeStatut   regimeLibelle
    
    fac012           1990-02-20    reg02        s05a           regime 5 supprimé
    fac125           2021-01-15    reg02        s05b           regime 5
    
    Vous noterez que les régimes en vigueur ont une date fin égale à « l’infini ».
    Si le libellé d’un régime ne change pas dans le temps, alors pour des raisons de 2NF (deuxième forme normale), c’est-à-dire pour éviter les redondances, il faudra mettre en oeuvre une table de ces libellés.
    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
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 121
    Points : 4 595
    Points
    4 595
    Par défaut
    Bonsoir devdev et fsmrel,

    En préambule :
    FACTURE 1,1 --> REGIME 1,n
    FACTURE 1,1 --> TIERS 1,n
    ==> Ce serait plutôt :
    FACTURE 1,1 --> REGIME 0,n (certains régimes ne sont pas, forcément, dans une facture) ;
    FACTURE 1,1 --> TIERS 0,n (certains tiers n'ont pas, forcément encore, de facture).


    Pour le reste :
    Dans ma table TIERS, j'ai un idtiers, un nom, un numéro de tva.
    Dans ma table FACTURE, j'ai un idtiers.

    Dans mes factures déclarées je dois enregistrer le numéro de tva du tiers.
    Si je déclare ces factures, et que quelque temps après, je me rends compte qu'il y a une erreur de numéro de tva pour ce tiers..
    En corrigeant ce numéro de tva dans ma table TIERS, ce numéro va se répercuter dans mes factures déjà déclarées, et ce n'est pas bon du tout.
    ==> plusieurs choses (en plus des remarques de fsmrel) à voir avec le DAF ou l'expert comptable concerné :
    - Ne faut-il pas ré-éditer (et les ré-envoyer, car fausses, également, chez le tiers) toutes les factures d'un tiers comportant un numéro de TVA erroné (en cas d'erreur de saisie, par exemple) ?
    Si oui, vous avez votre réponse (modifier le N° de TVA dans la table TIERS et ré-éditer) ;
    Si non, une table des NUMERO_TVA avec Id_NTva en clé primaire, Id_Tiers en clé étrangère, NUMERO_TVA en donnée.

    - Est-il possible qu'un tiers change de numéro de TVA ?
    Si oui, une table des NUMERO_TVA avec Id_NTva en clé primaire, Id_Tiers en clé étrangère, NUMERO_TVA en donnée ;
    Si non, un champ numéro de TVA dans la table TIERS est OK.

    A noter que la création d'une table NUMERO_TVA avec Id_NTva en clé primaire, Id_Tiers en clé étrangère, NUMERO_TVA en donnée, résout tous les problèmes...
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  9. #9
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 396
    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 : 7 396
    Points : 27 887
    Points
    27 887
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par devdev Voir le message
    Si je déclare ces factures, et que quelque temps après, je me rends compte qu'il y a une erreur de numéro de tva pour ce tiers..
    En corrigeant ce numéro de tva dans ma table TIERS, ce numéro va se répercuter dans mes factures déjà déclarées, et ce n'est pas bon du tout.
    Autrement dit, il s’agit d’historiser les numéros de TVA des tiers.
    Vous pouvez par exemple définir une entité-type « faible » TIERS_TVA (c’est-à-dire propriété multivaluée de TIERS), identifiée relativement à TIERS (cardinalité 1,1(R) avec Looping et WinDesign, (1,1) avec PowerAMC, 1,1 avec Open ModelSphere, etc.) .
    A noter qu'à une date donnée, le numéro de tva d’un tiers peut être le même que celui que ce tiers avait eu au cours d’une période précédente.

    Nom : devdev(numeroTva_historique).png
Affichages : 39
Taille : 11,8 Ko

    Un jeu d’essai. Les instructions "CREATE TABLE" ci-dessous sont celles qui ont été produites par Looping :

    Les tiers :

    CREATE TABLE TIERS(
       tiersId INT IDENTITY,
       tiersCode CHAR(8) NOT NULL,
       tiersNom VARCHAR(48) NOT NULL,
       CONSTRAINT TIERS_PK PRIMARY KEY(tiersId),
       CONSTRAINT TIERS_AK UNIQUE(tiersCode)
    ) ;
    
    INSERT INTO TIERS (tiersCode, tiersNom)
    VALUES
        ('t001', 'Fernand')
      , ('t002', 'Raoul')
    ;
    SELECT tiersCode, tiersNom
    FROM   TIERS
    ;
    =>

    tiersCode   tiersNom
    
    t001        Fernand
    t002        Raoul
    
    Les numéros de TVA des tiers :

    CREATE TABLE TIERS_TVA(
       tiersId INT,
       tiersTvaDebut DATE,
       tiersTvaFin DATE NOT NULL,
       tiersTvaNumero CHAR(11) NOT NULL,
       CONSTRAINT TIERS_TVA_PK PRIMARY KEY(tiersId, tiersTvaDebut),
       CONSTRAINT TIERS_TVA_TIERS_FK FOREIGN KEY(tiersId) 
           REFERENCES TIERS(tiersId)
    );
    INSERT INTO TIERS_TVA (tiersId, tiersTvaDebut, tiersTvaFin, tiersTvaNumero)
    VALUES
        (
           (SELECT tiersId FROM TIERS WHERE tiersCode = 't001') 
         , '2010-05-01', '2016-12-31', '12345678901'
        )
      ,
        (
           (SELECT tiersId FROM TIERS WHERE tiersCode = 't001') 
         , '2017-01-01', '2017-05-14', '12345678902'
        )
      ,
        (
           (SELECT tiersId FROM TIERS WHERE tiersCode = 't001') 
         , '2017-05-15', '9999-12-31', '12345678901'
        )
    ;
    INSERT INTO TIERS_TVA (tiersId, tiersTvaDebut, tiersTvaFin, tiersTvaNumero)
    VALUES
        (
           (SELECT tiersId FROM TIERS WHERE tiersCode = 't002') 
         , '1980-02-01', '9999-12-31', '23456789012'
        )
    ;
    SELECT tiersCode, tiersNom, tiersTvaDebut, tiersTvaFin, tiersTvaNumero 
    FROM   TIERS as x
      JOIN TIERS_TVA as y on x.tiersId = y.tiersId
    ;
    =>

    tiersCode   tiersNom     tiersTvaDebut   tiersTvaFin   tiersTvaNumero
    t001        Fernand      2010-05-01      2016-12-31    12345678901
    t001        Fernand      2017-01-01      2017-05-14    12345678902
    t001        Fernand      2017-05-15      9999-12-31    12345678901
    t002        Raoul        1980-02-01      9999-12-31    23456789012
    Pour chaque tiers, on sait toujours quel est (ou était) son numéro de TVA à une date donnée.
    Pour les adresses, même approche.


    Citation Envoyé par Paprick Voir le message
    Le logique Merise n'est pas mise en péril par ces questions d'archivage.
    Exact Nom : Paprick.jpg
Affichages : 39
Taille : 1,2 Ko ! Ça fait40 ans que j’essaie de le faire, et je n’y arrive pas !
    Mais me prendre les pieds dans le tapis, j’y arrive tous les jours, sans problème.
    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

  10. #10
    Membre habitué
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    399
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juin 2004
    Messages : 399
    Points : 166
    Points
    166
    Par défaut
    Bonjour à tous, et merci pour vos réponses, ça fait du bien de pouvoir échanger (j'ai un peu l'habitude d'être seul à mon boulot à faire mes propres choix...)

    Citation Envoyé par fsmrel Voir le message
    Bonjour devdev,

    Vous dites que dans votre table FACTURE vous avez un attribut idtiers, lequel jouerait alors le rôle de clé étrangère en relation avec la table TIERS. Le numéro de tva fait l’objet d’un attribut dans la table TIERS (appelons NumeroTva cet attribut) et joue le rôle de clé alternative et de point d’accès pour l’utilisateur. Si vous modifiez la valeur de l’attribut NumeroTva, lequel en toute logique n’existe que dans la table TIERS, alors la table FACTURE ne subit pas de modification puisque pour sa part l’attribut idtiers n’a pas changé. Donc quel sens donnez-vous à la phrase :

    « En corrigeant ce numéro de tva dans ma table TIERS, ce numéro va se répercuter dans mes factures déjà déclarées  »

    Et quelles "répercussions" précises sont à envisager ?
    Par répercussions je voulais dire que si on veut réafficher à l'écran la facture déclarée (pas en pdf ou autre mais bien sur le masque de saisie facture), et bien la facture ne va plus correspondre à ce qui a été déclarée. A l'écran j'aurai mon nouveau numéro de tva. Hors je veux l'état exact de ce qui a été fait. En tout cas si on reste sur idtiers en clé étrangère dans la table facture.

    J'ai bien noté les solutions proposées pour palier à ça, mais finalement quel serait l'inconvénient de ne pas faire de relationnel dans ce cas là et de mettre en dur le numéro de tva dans la table facture

  11. #11
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 121
    Points : 4 595
    Points
    4 595
    Par défaut
    Bonjour devdev et fsmrel,

    Il y a deux questions fondamentales qu'il faut poser à l'utilisateur expert avec lequel tu travailles :

    1. Une ancienne facture comportant un faux numéro de TVA (erreur de saisie de l'époque, par exemple) est-elle "hors la loi" ?
    2. Un même tiers peut-il changer de numéro de TVA ?
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

Discussions similaires

  1. Réponses: 27
    Dernier message: 15/12/2017, 23h08
  2. Y a-t-il une autre façon de faire ?
    Par Invité dans le forum jQuery
    Réponses: 1
    Dernier message: 06/03/2013, 21h51
  3. [JavaScript] [FAQ] une autre façon de faire des tableaux à coins arrondis
    Par SpaceFrog dans le forum Contribuez
    Réponses: 6
    Dernier message: 10/01/2007, 10h35
  4. D'autres idées pour faire la même chose ?
    Par Gromitou dans le forum Général JavaScript
    Réponses: 4
    Dernier message: 04/05/2006, 13h15
  5. Est ce bien la meilleure façon de faire un histogramme ?
    Par rvzip64 dans le forum Algorithmes et structures de données
    Réponses: 2
    Dernier message: 10/05/2005, 13h41

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