Discussion :

[Invité]

Bonjour,

Alors avant de demander des avis direcement sur mon modèle, j'aimerais savoir s'il est très correct d'avoir un "cycle" ??
C'est-à-dire, un groupe de table formant un cercle, exemple :
table1<-->table2<-->table3<-->table1 (les <--> représentent les liens entre les tables)

Merci de vos réponses!

[Nanci]

Dans le cas de tables (MLD/MPD), le lien entre tables est orienté.
Table B --> Table A = #a, clé étrangère dans table B, réfère #a de table A.

Théoriquement, un tel cycle pourrait marcher en 2 temps (à condition que les clés étrangères acceptent les valeurs nulles).
Table C --> Table B --> Table A --> Table C
mais quel est le cas concret qui conduit à une telle modélisation (MCD) ?
A voir....

[Invité]

En fait, j'ai un peu de mal à me décider sur mon schéma, j'ai l'impression de pas faire les bonnes choses.

En gros :
- 1 devis qui peut avoir ou non 1 ou n factures
- 1 facture est détaillée selon 1 ou n repères
- 1 devis est décomposé en 1 ou n repères
- 1 facture a une page de garde
- 1 facture a 1 ou n éléments particuliers (éléments supplémentaires à facturés en dehors des repères)

A savoir maintenant que les pages de garde des factures d'un même devis ont des informations communes (par exemple l'en-tête ne change jamais). S'il existe plusieurs factures pour un même devis, certaines informations concernant les repères sont communes entre les factures ...

Si je fais un schéma simple pour éviter d'avoir un cercle, je tombe sur ça :


Ou bien ce schéma là (qui me paraît plus correct) :


En fait le détail des repères diffèrent en fonction des factures (même pour un même devis).

Mais je suis pas sûr que ça aille vraiment avec mon problème. Je suis pas sure que la table facture se retrouve au bon endroit là ... Elle est pas directement liée au devis ... Je sais pas si je suis clair.
En plus ce qui me fait penser que j'ai peut-être pas la bonne solution, c'est que si je veux connaître le nombre de factures d'un devis, il faut que je travers d'abord 2 autres tables, alors qu'un devis a 0 ou plusieurs factures (alors devis devrait être relié à facture).

J'aimerais vos avis sur mon schéma svp, merci

[Le Pharaon]

- 1 devis qui peut avoir ou non 1 ou n factures
- 1 facture est détaillée selon 1 ou n repères
- 1 devis est décomposé en 1 ou n repères- 1 facture a une page de garde
- 1 facture a 1 ou n éléments particuliers (éléments supplémentaires à facturés en dehors des repères)

La règle de gestion en gras n'a à mon avis pas sa raison d'être. Un devis est composé de factures. Une facture regroupe des repères.
DOnc si on connait un devis en passant les foctures on trouvera forcément les repères correspondants.

[Invité]

En fait c'est vrai que j'hésitais entre le fait que ce soit la facture qui soit liée, ou les repères ...
Le problème, c'est qu'en fait un devis est vraiment composé de repères, et cela même dans la base de données déjà existante. Je veux dire par là, qu'à partir du numéro du devis, on retrouve les repères de ce devis dans d'autres tables ... Je sais pas si ça change quelque chose mais bon ...
De plus, même si aujourd'hui on s'en fiche, ça ne sera peut-être pas la cas demain. En fait pour l'instant, on ne souhaite pas rechercher les repères de la base pour pré-remplir la facture (trop de problèmes sur les repères pour l'instant), mais ça n'est pas dis que demain ça ne sera pas le cas. Si jamais ça arrive, le modèle que tu m'a proposé sera donc faux non ??

EDIT : Oups après reflexion je me dis que j'ai peut-être tort ! Même si on doit remonter les repères à partir des tables existantes vers la facture, ça ne pose pas de problème, puisque dans la facture, le numéro du devis est enregistré en clé étrangère, je pourrais donc m'en servir pour chercher les repères.
Qu'en pensez-vous ? J'ai juste ??

Sinon je me demandais quelque chose ... les repères peuvent être rangés en sous catégories (elles même en sous-catégories, etc etc). Je me suis dis que j'allais créer une table titre comme suit :



(Bon pour les clés primaires étrangères, je suis pas très sure encore, c'est juste fait rapidement :p )

Ce qui me donne à la fin :


Ca vous parrait correct ?

Merci de vos réponses

[Le Pharaon]

il me faudra des régles de gestion supplémentaire pour mieux comprendre la situation.

Un titre c'est quoi ?
quel lien existe entre un repère général et un repère détaillé.

Il ne faut surtout pas vouloir coûte que coûte être en parfait "accord" avec la base actuelle, surtout si elle ne respecte pas toutes les règles

EDIT : Oups après reflexion je me dis que j'ai peut-être tort ! Même si on doit remonter les repères à partir des tables existantes vers la facture, ça ne pose pas de problème, puisque dans la facture, le numéro du devis est enregistré en clé étrangère, je pourrais donc m'en servir pour chercher les repères.
Qu'en pensez-vous ? J'ai juste ??

Je trouve ça juste. C'est ce que je crois t'avoir expliqué dans mon premier post.

Merci

[Invité]

Ok je vais essayer de t'expliquer ...

En fait, on a un devis. Ce devis contient n repères dans une base de données, mais pour l'instant on les importe pas dans la facture.
Donc on a :
- un devis a 0 ou n factures
- une facture est décomposée en 0 ou n sous-catégories (c'est ce que j'ai appelé titre)
- les sous-catégories contiennent en 0 ou n repères

--> la je me rends compte déjà que mon post de ce matin était faux puisque une facture contient directement en 0 ou n repères s'il n'y a pas de sous-catégories !!

- les repères peuvent être distingués selon deux tables : une qui contient les informations générales des repères (donc infos qui ne changeront pas en fonction des factures comme par exemple le nombre de repère commandés, puisque toutes les factures d'un même devis ont les mêmes repères), et une table qui contient els informations détaillées des repères (donc informations qui changent en fonction des factures, ça peut être par exemple le nombre de repères posés)

- une facture a également des éléments en plus
- une facture a une page de garde (la page de garde change en fonction des factures, donc ici, les informations détaillées de la page sont dans la facture, et sinon les informations communes aux factures du devis sont dans une autre table).


Je sais pas si tu vois mieu, c'est un peu compliqué, d'où le fait que j'ai du mal à fair mon schéma

[fsmrel]

Bonjour,

Vous écrivez :

j'aimerais savoir s'il est très correct d'avoir un "cycle" ??
C'est-à-dire, un groupe de table formant un cercle, exemple :
table1<-->table2<-->table3<-->table1 (les <--> représentent les liens entre les tables)

Du point de vue de la Théorie relationnelle, les cycles sont légaux. Du point de vue des SGBDR même chose, mais les mises-à-jour des tables pourront le cas échéant échouer.
Prenons par exemple le cas de DB2 : La règle y est la suivante : "Les opérations de mise-à-jour portant sur une table T1 ne doivent pas se propager transitivement jusqu'à T1".

Autrement dit, pour reprendre votre exemple, supposons que vous effectuiez une opération de DELETE de lignes de T1. Si T1 est parente de T2 et que l'action référentielle est de type RESTRICT, les suppressions ne pourront pas se propager, votre cycle ne met pas en l'occurrence l'édifice en péril, tout va bien.
Supposons maintenant que l'action référentielle soit de type CASCADE : s’il en existe, les lignes de T2 en relation avec celles de T1 sont bonnes pour la destruction et le SGBD doit maintenant vérifier les conséquences sur T3. Si présence d'un RESTRICT chez T3, il n'y a pas de propagation et on en reste là. Si présence d'un CASCADE et s’il existe des lignes de T3 en relation avec celles de T2, elles sont bonnes pour la destruction. Si l'action référentielle entre T3 et T1 est de type CASCADE, le SGBD se rend compte que le serpent va finir par se mordre la queue et rejette l'opération qui donc n'impacte pas T1.

Faites des tests avec votre SGBD favori.

Bon courage

[Invité]

Merci,

Je vais voir comment je vais me débrouiller

[Invité]

Finalement, je suis partie des derniers points dont on avait discuté pour me planter ...

En effet on arrivait à :
devis --> facture --> repere General

Or, les repères de la table repère général sont identiques pour toutes les factures d'un même devis, donc si je suis le schéma ci-dessus ça ne marche plus !!

Ben voilà, je me suis reperdue dans mon schéma, reste plus qu'à re-suer dessus

Je pense donc au schéma suivant :


Qu'en dites vous ??? (ici groupe=titre)

EDIT : Par contre, je crois qu'il vaut mieux mettre le numDevis en clé étrangère dans la table repere_general, sinon quand la personne créera ses repères, on ne saura pas avec quel devis ils vont (puisqu'on crée les repères avant els factures) ...Et dans ce cas, on va avoir un lien entre la table devis et la table repere_general et donc une boucle ... Ce schéma me rend dingue !! Par contre, si y'avais le numéro de devis en clé étrangère, ca faciliterais les choses si un jour les repères sont importés directement ... Je pense que dans mon cas, une boucle n'est pas "dangereuse" non ??

[Nanci]

Sauf erreur de ma part, le forum s'intitule Merise. Et l'un des piliers de Merise, pour la modélisation des données, c'est la réalisation d'un MCD (modèle conceptuel de données) avant de passer à la mise en oeuvre relationnelle (MLD / MPD).
Le MCD permet de se concentrer sur le Quoi avant de passer au Comment.

La situation où tu te trouves est une assez bonne illustration des difficultés de raisonner directement en logique.

Si on essayait de faire un "vrai" MCD

Repartons des éléments que tu indiques dans le post du 14.
Devis, facture je comprends
Repère, c'est quoi ? Donnes un peu des exemples (c'est des produits, des prestations, ...?). Il semble y avoir des Repères qui dépendent des devis; mais un repère peut il figurer dans plusieurs devis
Ces Repères semblent être utilisés et personnalisés dans le cadre des factures (ou plutôt lignes de factures)

Les reprères-type semblent appartenir à une structure de groupe / sous-groupe.

Quand à la page de garde d'une facture, les éléments en plus d'une facture, il faudrait en dire plus pour savoir si on peut les modéliser comme des propriétés de facture ?
Quand aux éléments commun aux factures d'un devis, ne serait-ce pas des propriétés de Devis ?

A mon avis, commençons par discuter du fond du problème en MCD avant de passer au logique

Je propose d'amorcer la discussion par le MCD suivant

[Invité]

Merci de te pencher sur mon problème qui me rend chèvre !
En fait j'ai essayé de faire le moèle conceptuel avant, mais je tourne tellement le problème dans tous les sens que j'y arrive pas et j'essaye de voir si en logique ça irait mieux.

Alors je réexplique :
- un devis contient toutes les informations du devis (la date de création, le client, le montant, ....)
- un devis contient des repères (en fait un repère = une fenêtre, ici c'est des devis de commandes de fenêtres, et un devis peut contenir plusieurs fenêtres bien sur).
- un devis se transforme (une fois les fenêtres livrées) en facture --> il peut y avoir plusieurs factures car plusieurs livraisons( une facture = une livraison)
- sur ces factures, on retrouve le listing des repères qui peuvent-être regroupés en sous-catégories pour la présentation de la facture
- chaque facture peut contenir des éléments en plus (une assurance qui s'ajoute par exemple)
- et enfin une facture a une page de garde (avec l'adresses du client, la référence de la facture, etc etc)

Maintenant :
- un devis a plusieurs factures, mais ces factures ont des informations en commun comme la tva par exemple --> je pense donc mettre la tva dans devis car c'est logique je trouve, ce qui me donne une table facture qui ne contient que les informations propres à chaque facture.
- de même, toutes les factures d'un même devis ont une même page de garde (c'est la même page pour toutes les factures du devis, car même client, même addresses, etc etc) --> donc la page de garde est une table ne contenant que les informations communes à toutes les factures du devis (le reste, comme la référence de la facture, se trouvera dans la table facture, puisqu'elle est propre à la facture)
- les repères sont les mêmes pour toutes les factures d'un devis, mais en fonction des devis, ils ont certaines informations qui diffèrent : par exemple le repère A s'appellera A pour toutes les factures du devis x, mais pour la facture 1, il y en aura 5 de livré, pour la 2 il y en aura 10, etc etc

Je sais que c'est assez lourd à comprendre (et à expliquer), mais j'espère que ça éclaire un peu plus !!

Pour répondre précisémment à tes questions :
- un repère ne peut appartenir qu'à un seul devis (les repères sont uniques)
- un repère dépend donc d'un devis --> PROBLEME : il existe déjà une table avec les repères mais pour l'instant on ne veut pas les importer directement, or je pensais déjà prévoir le fait qu'un jour il serait importé directement dans le corps de la facture (peut-être que ça change le schéma je sais pas), mais sinon faisons au plus simple !! un devis = liste de repères ; un devis = plusieurs factures ; une facture = liste de repères

EDIT : sinon pour ton modèle, je suis assez d'accord (si bien sur on ne prend pas en compte les informations communes ou non de certaines éléments). EN fait moi je cherchais à tout prix à éviter une boucle (je ne sais pas pourquoi d'ailleurs), mais j'ai l'impression que c'est impossible, et en plus si on fait un boucle au niveau du devis, si un jour on importe directement les repères liés au devis dans la base, alors ce la fonctionnera toujours d'après ton schéma !!

[Nanci]

Essayons de modéliser ton dernier post...
Nouvelle version du MCD


Devis: Ok
Je propose faire apparaitre Client si on gère explicitement les clients (réutilisable) sinon on le modélise comme de simples informations du devis (nom, adresse, etc)
Repère semble correspondre à des "produits" mais qui ne sont pas "re-référençables" au delà d'un devis. Je le modélise donc par une entité Repère identifiée relativement à Devis (la relation porte sur). Je m'interroge toutefois sur l'existence d'une modélisation de produit catalogue. La fenêtre proposée dans le cadre d'un devis peut elle être proposée dans le cadre d'un autre devis ? Cette fenêtre a probablement des caractéristiques techniques et commerciales indépendantes d'une devis; à moins que l'on fasse du sur-mesure à chaque devis ! Dans ce cas, la modélisation proposée est correcte..
Toutefois, ta remarque sur l'importation de repères me fait pencher vers une vision catalogue de fenêtres. Si tel était le cas, le modèle est à réviser !

La relation "porte sur" entre devis et repère traduit les repères commandés (les fenêtres différentes).
A niveau de chaque repère, on précise la quantité (de fenêtres identiques...) et le montant unitaire HT

Les livraisons des repères du devis donnent lieu à des Factures (OK)
Chaque Facture fait référence à des repères commandés. Toutefois, pour chaque ligne de facture (modélisé par la relation réfère à), on précise la qté livrée de ce repère. On peut ainsi avoir commandé 10 fenêtres de repère A dans le devis, et livrer 4 repères A dans la première facture et les 6 suivantes dans la seconde facture.

Pour les éléments complémentaires, on peut modéliser ces items en précisant la nature et le montant unitaire HT. Ces éléments sont rattachés à chaque facture et identifiés relativement par un n° d'item à chaque facture.

Pour le reste...
La page de garde d'une facture, il s'agit, à mon avis, d'un aspect de présentation car toutes informations figurent déjà dans la facture, le devis d'origine ou le client concerné. En tout cas au niveau conceptuel, il n'y a aucune raison de modéliser une telle page. Au niveau logique, pour des motifs de performance (?), on pourra s'interroger sur une telle redondance.

La TVA; s'agit-il du taux ou du montant ? Pour le montant, il n'est surement pas commun ! Pour le taux, c'est un peu plus compliqué; il existe des taux qui dépendent de règles de gestion parfois tordues. Si le taux est unique au niveau de chaque devis (il s'applique à tous les montants dépendant directement ou indirectement du devis), alors il faut mettre Taux TVA en propriété de devis. Mais la fiscalité n'est jamais simple....

[Invité]

Waouw ! Tout d'abord merci, parce que c'était super clair

Alors, commençons par la chose la plus simple :
- pour la page de garde, c'est vrai que la plupart des informations existent déjà (sauf deux ou trois mais je pourrais les mettre dans le devis au pire). Moi-même à force je trouvais ça bête d'avoir une table juste pour me faire une page de garde

Ensuite, la TVA est normalement un taux (ou pourra y être assimilée d'après ce qu'on m'a dis), donc un champ dans mon devis suffit.

La fenêtre proposée dans le cadre d'un devis peut elle être proposée dans le cadre d'un autre devis ? Cette fenêtre a probablement des caractéristiques techniques et commerciales indépendantes d'une devis; à moins que l'on fasse du sur-mesure à chaque devis !

--> En fait, une repère ne correspond qu'à un devis. Il est certain que les fenêtres ont des propriétés communes je pense, mais aucunes de ces propriétés n'est à renseigner dans la base, en fait pour un repèer, on va stocker sa désignation, la quantité commandée et son prix. Ensuite en fonction de la facture, on stockera la quantité posée et le prix de facturation (en fonction de la quantité ...). Donc je pense que là c'est bon, non ?

Toutefois, ta remarque sur l'importation de repères me fait pencher vers une vision catalogue de fenêtres.

--> Pourquoi donc ?

Donc si je me trompes pas on obtient quelque chose dans le genre (j'ai pas remis les clients, car en fait ils sont gérés de ta manière depuis lontemps, et la relation entre facture et repere a donné la table detail_facture) :

[Nanci]

Je crois qu'on y est ...


Pour la notion de Repère, je la laisse comme unique par rapport à un devis (identification relative) mais je fais quand même référence à un Produit catalogue (qui pourrait être dans une autre base....) sur lequel on pourrait s'appuyer sur chaque référence. Mais c'est à voir....

Pour le reste, au niveau MCD, on en reste là.
Par contre, au niveau logique, il faut absolument prendre en compte les identifications relatives (repère, élément) qui se traduisent par l'intégation des clés étrangères dans les clés primaires.
De plus, dans groupe, on ne peut pas dupliquer idGroupe commme clé primaire, puis clé étrangère. Un groupe de sous-groupes s'appelle alors un Titre.

[Invité]

Alors je suis ok (bon pour la table produit, c'est pas encore d'actualité hein ).

Par contre ça fait un petit moment (presque trois ans) que j'avais pas fais de merise aussi poussé (et surtout suivant autant les règles), je me souviens pas d'avoir vu les (R) dans les schéma. Je me doute que ça veut dire relationnel, mais là, je vois pas trop pourquoi, on doit les mettre en clé primaires aussi ... Tu pourrais juste m'expliquer en quelques mots, histoire que je sois moins bête pour la suite

Merci bien

EDIT : je suppose que c'est pour faire en sorte que la clé devienne unique (enfin qu'il n'y ait aucun risque d'en trouver une autre pareille), non ?

[Nanci]

Le (R) sur une patte de relation signifie une identification relative
Cf la FAQ
http://merise.developpez.com/faq/?pa...CD_Identifiant
Au niveau logique, cela se traduit par l'intégration de la clé étrangère dans la clé primaire.

[Le Pharaon]

Au niveau logique, cela se traduit par l'intégration de la clé étrangère dans la clé primaire.

lapsus ?

[Invité]

J'étais aller voir ce même lien en attendant que quelqu'un me réponde

Ok je crois que j'ai compris (c'est bizarre que je ne l'ai jamais vu avant, m'enfin )

Je crois que mon problème est résolu non ??

Merci de m'avoir aidé à y voir plus clair dans mon projet !!

[Nanci]

lapsus ?

Non. Mais formulation raccourcie.
Dans la table Repère
la clé étrangère n° devis référant à Devis est intégrée dans la clé primaire de Repère. L'unicité d'occurrrence (rôle de la clé primaire) est assurée par n° devis + id repère.