Discussion :

[fsmrel]

Bonsoir Nono,

vous trouverez aussi un fichier Excel nommé "Construction relations" montrant l'ensemble des règles de gestion par révision avec en jaune les modifications (ça sera plus simple pour vous de voir où sont mes changements dans les relations).

Bravo, bel exercice.

Cerise possible sur le gâteau, et si vous vous en sentez le courage, vous pourriez ajouter en annexe les règles complémentaires, liées aux contraintes de chemin, d’exclusion (dont on en parlera peut-être plus tard) et autres qu’on rencontrera peut-être lors des chalutages à venir.

Exemple 1 :

(Rx) Si une prestation concerne une facture et un animal donnés, alors le client facturé et celui à qui appartient l’animal peuvent être distincts.

Ou bien (ce qui est votre cas !) :

(Rx’) Si une prestation concerne une facture et un animal donnés, alors le client facturé et celui à qui appartient l’animal ne doivent faire qu’un.

Exemple 2 :

(Ry) Si une prestation a été effectuée par un employé donné, et fait partie d’une facture donnée, alors cet employé peut être différent de celui édite la facture.

Vous me direz après analyse si mon raisonnement post #16 a été le bon

D’accord, le diagramme est correct, prendre la Zaza d’Hilary pour celle de Donald devient impossible...

En rajoutant un id prestation on pourrait rajouter autant de prestations que voulu avec le même id_client, id_animal, id_facture... Ce qui revient à facturer plusieurs prestations sur un même animal dans une et une seule facture !

Bien entendu. Comme je l’ai écrit dans le post #17, aujourd’hui, certes, on ne peut pas avoir plus d’une prestation pour un animal et une facture donnés, mais si un jour ça devenait possible (pour une raison que seule Mme Nono saurait justifier auprès de son comptable), la clé primaire de la table PRESTATION en prendrait un coup, d’où effets secondaires par exemple sur la table PRESTATION_SUPPLEMENT évoquée dans #17 (nécessité de modifier la structure de la clé étrangère référençant la clé primaire de la table PRESTATION, opération délicate pour une base de données opérationnelle).

Bien entendu, vous n’êtes pas obligé de me suivre, mais une structure du genre ci-dessous mérite réflexion (je rappelle que, si la règle d’unicité concernant le triplet {id_client, id_animal, id_facture} volait en éclats, la clé alternative disparaîtrait, mais la structure du triplet {id_client, id_animal, id_prestation} serait inchangée :






A propos des adresses de facturation

L’entité-type ADRESSE_FACTURE a pour identifiant la paire {id_adresse_facture, id_date_ajout_adresse}, ce qui veut dire qu’on peut avoir les valeurs suivantes :

id_adresse_facture    id_date_ajout_adresse    id_client    id_ville    nom_adresse_facture    date_ajout_adresse

1                     1                        200            1         Hilary, 1 rue Truc     d1
1                     2                        100            1         Donald, 5 rue Chose    d1
...
1                     n                        800            5         Raoul, La péniche      d2  

...

Je trouve ça louche. Pourquoi, pour la valeur 1 de l’attribut id_adresse_facture, pourrait-on avoir plus d’une valeur (1,2,..., n) pour l’attribut id_date_ajout_adresse ?

Accessoirement, les entités-types ADRESSE_FACTURE et DATE_AJOUT_ADRESSE entretiennent une relation de bijection : balek ! cuidado ! Voyez ce que j’en pense ici. Autrement dit, il est plus que conseillé de fondre les deux entités-types en une seule.

Par ailleurs je vous demande de peser le pour et le contre, réfléchir à la suppression de l’attribut adresse facturation de l’entité-type FACTURE, au bénéfice d’une association entre FACTURE et ADRESSE_FACTURE (avec identification relative, suite à la contrainte de chemin à garantir, afin d’éviter de mélanger les adresses du binôme Hilary, Donald (mélange du reste parfaitement possible avec votre MCD actuel...))

Le lendemain matin je me suis fait engueuler par Madame

Mais c’était pour la bonne cause, elle aurait dû être contente...

Je vous l'ai modifié en PRE sur le post #16. ;-)

Merci. C’est quand même plus reposant pour la vue. A l’occasion, au sein des éléments balisés PRE, vous pouvez colorier le texte des nouvelles règles, de celles qui sont modifiées, supprimées, etc. C’est confortable d’avoir à la fois les éléments balisés, outre le ficher EXCEL. Vous me direz que c’est redondant, et que la redondance est l’ennemie implacable des bases de données, mais bon...

Si un jour vous avez à programmer un API

Je ne tiens pas à faire exploser la maison ! Je peux être redoutable, un véritable Raoul, ventiler façon puzzle !



On ne vote plus ? Le post #19 ne vous a pas inspiré ?

[Nono02P]

Bonsoir fsmrel,

Bravo, bel exercice.

Bof, je vous avoue que c'est plus par facilité et fainéantise...
Je l'ai fait dans un premier temps pour avoir des listes déroulante et pas me taper les "au moins 0 et au plus plusieurs" mais quand vous m'avez demandé l'urbanisation... Là j'ai fait ça !
J'allais pas vous envoyer les règles avec des trous entre deux et il était hors de question de tout me retaper manuellement.

Je déteste la dactylo inutile (je la fait si elle est nécessaire, la preuve je l'ai faite une fois pour les règles de gestion) !
J'aurais fait du vba permettant en plus l'ajout automatique des noms de révision dans les colonnes et dans le Name manager, la gestion de chaque élément de tables, leur type de donnée et en plus leurs type de clé ainsi que l'export au format texte de ce que je doit balancer sur le forum pour avoir la bonne mise en forme... Là j'aurais dis, "Oui ok, c'est bien j'ai été au bout des choses !"

Cerise possible sur le gâteau, et si vous vous en sentez le courage, vous pourriez ajouter en annexe les règles complémentaires, liées aux contraintes de chemin, d’exclusion (dont on en parlera peut-être plus tard) et autres qu’on rencontrera peut-être lors des chalutages à venir.

Si ça devient nécessaire, je gérerais les tables et leurs contenu...

(Rx) Si une prestation concerne une facture et un animal donnés, alors le client facturé et celui à qui appartient l’animal peuvent être distincts.

Ou bien (ce qui est votre cas !) :

(Rx’) Si une prestation concerne une facture et un animal donnés, alors le client facturé et celui à qui appartient l’animal ne doivent faire qu’un.

Vous avez raison, je vais essayer de couvrir le maximum de cas pour éviter que ma femme me casse tout une fois mis en place...
Un client peut régler une prestation sur un chien qui appartient à un autre client.
On ne sait jamais, si Mme Dupont voisine de M. Bonpoil (qui est très occupé par ailleurs) emmène de temps en temps (Jouck) le chien de M. Bonpoil en même temps que son chat (Gif)...
Alors elle pourra avoir dans une seule facture la prestation de son chat et du chien du voisin... Après tout, si ils s'arrangent entre eux, c'est leur problème, ça me va !

Exemple 2 :

(Ry) Si une prestation a été effectuée par un employé donné, et fait partie d’une facture donnée, alors cet employé peut être différent de celui édite la facture.

A vrai dire la table employe existe en grande partie pour dans une poignée d'années, quand Mme Nono aura un mini-nono à porter et qu'elle devra employer quelqu'un ou faire faire à une stagiaire ou apprentie une partie de son boulot...

On peut donc imaginer que l'apprentie bosse et fasse la prestation et que ma femme regarde, assise sur une chaise et fasse la facturation...

Effectivement, c'est une bonne idée !
Autre point important auquel vous me faites penser !
Il faudrait que j'intègre des niveaux d'accès aux différents employés et un accès à la BD par mot de passe...
Il va de soit, qu'une stagiaire (géré avec son niveau d'accès) n'ai pas le droit de consulter la marge des produits, le solde bancaire ou encore la partie comptabilité...

Bien entendu. Comme je l’ai écrit dans le post #17, aujourd’hui, certes, on ne peut pas avoir plus d’une prestation pour un animal et une facture donnés, mais si un jour ça devenait possible (pour une raison que seule Mme Nono saurait justifier auprès de son comptable), la clé primaire de la table PRESTATION en prendrait un coup, d’où effets secondaires par exemple sur la table PRESTATION_SUPPLEMENT évoquée dans #17 (nécessité de modifier la structure de la clé étrangère référençant la clé primaire de la table PRESTATION, opération délicate pour une base de données opérationnelle).

Bien entendu, vous n’êtes pas obligé de me suivre, mais une structure du genre ci-dessous mérite réflexion (je rappelle que, si la règle d’unicité concernant le triplet {id_client, id_animal, id_facture} volait en éclats, la clé alternative disparaîtrait, mais la structure du triplet {id_client, id_animal, id_prestation} serait inchangée :

Vous marquez un point de plus ! Qui peut le plus peut le moins...

A propos des adresses de facturation

L’entité-type ADRESSE_FACTURE a pour identifiant la paire {id_adresse_facture, id_date_ajout_adresse}, ce qui veut dire qu’on peut avoir les valeurs suivantes :

id_adresse_facture    id_date_ajout_adresse    id_client    id_ville    nom_adresse_facture    date_ajout_adresse

1                     1                        200            1         Hilary, 1 rue Truc     d1
1                     2                        100            1         Donald, 5 rue Chose    d1
...
1                     n                        800            5         Raoul, La péniche      d2  

...

Je trouve ça louche. Pourquoi, pour la valeur 1 de l’attribut id_adresse_facture, pourrait-on avoir plus d’une valeur (1,2,..., n) pour l’attribut id_date_ajout_adresse ?

En fait, j'ai fait ça de cette manière afin d'historiser les factures ! Une facture éditée ne peut pas changer (sinon de gros problèmes peuvent en découdre)...
Donc je suis parti du principe qu'une adresse est modifiable temps qu'elle n'est pas éditée dans une facture ou un devis et qu'elle devient "verrouillée" et ne peut plus être modifiée ou supprimée à partir du moment où une facture/un devis ai été éditée avec cette fameuse adresse !

J'ai pensé à cette solution dans cet unique but, ne connaissant pas d'autres solutions... Cependant si vous trouvez une solution efficace et fiable à cette problématique, je suis preneur !

EDIT (du 17/03/16 à 20:11) : Ah, je vient de comprendre où vous voulez en venir, effectivement c'est stupide mon histoire... Sauf si le client possède plusieurs adresses mais c'est un peu useless, qu'en pensez vous?

Accessoirement, les entités-types ADRESSE_FACTURE et DATE_AJOUT_ADRESSE entretiennent une relation de bijection : balek ! cuidado ! Voyez ce que j’en pense ici. Autrement dit, il est plus que conseillé de fondre les deux entités-types en une seule.

Vous savez quoi? C'est une coïncidence mais entre le moment où j'ai posté le message #16 et votre remarque, j'ai lu ce post que vous avez envoyé...

Par ailleurs je vous demande de peser le pour et le contre, réfléchir à la suppression de l’attribut adresse facturation de l’entité-type FACTURE, au bénéfice d’une association entre FACTURE et ADRESSE_FACTURE (avec identification relative, suite à la contrainte de chemin à garantir, afin d’éviter de mélanger les adresses du binôme Hilary, Donald (mélange du reste parfaitement possible avec votre MCD actuel...))

En fait le pour et le contre va vite être pesé... J'appelle ça un oubli !

Mais c’était pour la bonne cause, elle aurait dû être contente...

Comme vous le savez, une femme peut ronchonner pour tout et rien...

Merci. C’est quand même plus reposant pour la vue. A l’occasion, au sein des éléments balisés PRE, vous pouvez colorier le texte des nouvelles règles, de celles qui sont modifiées, supprimées, etc. C’est confortable d’avoir à la fois les éléments balisés, outre le ficher EXCEL. Vous me direz que c’est redondant, et que la redondance est l’ennemie implacable des bases de données, mais bon...

Le monde de nos jour veut toujours plus de redondance... Ça rime aussi avec continuité de service !

Je vous avoue que ça commence à me gonfler sévèrement de sélectionner chaque onglet, copier, coller, remplacer les tabulations, mettre en gras les au moins 0, au plus plusieurs etc, etc...

Vous avez gagné, mon âme de fainéant a été touché... Dès que j'ai un peu de temps, je vais faire un bout de vba me permettant d'exporter le tout en fichier .txt et balancer ça sur le forum sans me coltiner tout...
A ce moment j'ajouterais les balises de coloration de texte et ne mettrais PLUS le fichier Excel vu que vous préférez les PRE...

Hahaha, je vous taquine je continuerais à le joindre en PJ.

Je ne tiens pas à faire exploser la maison ! Je peux être redoutable, un véritable Raoul, ventiler façon puzzle !

L'automatisme ne rime pas avec explosion... Du moins pas toujours !
Je rigole bien sur, l'automatisme est un métier où tout est beau et rose...

Puis 20 ms plus tard, tout est cassé (une situation pas prise en compte au moment de l'étude du projet), c'est la situation de crise et tout le monde vous courent après pour vous tuer...

On ne vote plus ? Le post #19 ne vous a pas inspiré ?

J'aime passer du temps ici mais j'aime aussi mon travail, j'étais juste pressé de partir travailler ! J'ai été à l'efficacité...

J'ai voté, ce vote est comme les autres, largement mérité !
D'ailleurs mes votes vous concernant devraient compter au moins pour deux vu l'aide que vous m'apportez !

Bon bah je crois que j'ai un peu de pain sur la planche...

Je repasse une mise à jour dans la soirée si j'ai assez avancé, sinon demain !

[fsmrel]

Bonsoir Nono,

J'aurais fait du vba

VBA pourra sans doute nous servir pour déclarer les tables ACCESS, par exemple comme ici (cf. dans ce post le fichier joint).

Si ça devient nécessaire, je gérerais les tables et leurs contenu...

Constituez surtout le dossier de conception...

Un client peut régler une prestation sur un chien qui appartient à un autre client.
On ne sait jamais, si Mme Dupont voisine de M. Bonpoil (qui est très occupé par ailleurs) emmène de temps en temps (Jouck) le chien de M. Bonpoil en même temps que son chat (Gif)...
Alors elle pourra avoir dans une seule facture la prestation de son chat et du chien du voisin... Après tout, si ils s'arrangent entre eux, c'est leur problème, ça me va !

Vu comme on est parti (adoption de (Rx’) : si une prestation concerne une facture et un animal donnés, alors le client facturé et celui à qui appartient l’animal ne doivent faire qu’un), il y aura nécessairement deux factures, une concernant le trio <Bonpoil, Jouck, facture f1> et l’autre concernant le trio <Dupont, Gif, facture f2>.

Autre point important auquel vous me faites penser !
Il faudrait que j'intègre des niveaux d'accès aux différents employés et un accès à la BD par mot de passe...
Il va de soit, qu'une stagiaire (géré avec son niveau d'accès) n'ai pas le droit de consulter la marge des produits, le solde bancaire ou encore la partie comptabilité...

Les habilitations seront bien sûr à modéliser. A cette occasion n’oublions pas l’aide que peuvent apporter les vues SQL (mais avec ACCESS ça n'est peut-être pas évident...)

Sauf si le client possède plusieurs adresses mais c'est un peu useless, qu'en pensez vous?

Tout dépend du sort de la règle R009 : souhaitez-vous la conserver en l’état, ou préférez-vous ne gérer qu’une adresse par client ? A mon avis, on est oligé de garder la règle en l'état, car si un client peut déménager, ça n'est pas le cas des factures déjà enregistrées...)

A ce moment j'ajouterais les balises de coloration de texte et ne mettrais PLUS le fichier Excel vu que vous préférez les PRE...

J’aime bien avoir les deux : EXCEL pour le confort, la balise PRE quand je suis en train de répondre (exemple RG009 ci-dessus ), mais ne perdez pas de temps à cause de moi à ce sujet, mettez le paquet sur votre dossier de conception...


Concernant la génération du code SQL : pour le moment, partons des sous-domaines (Cœur, RDV, etc.), ça vous permettra de vous familiariser et de mettre en œuvre vos conventions de nommage des contraintes (on en reparlera).

Pour que les clés étrangères soient générées, il faut créer le MLD (Copy Product > Transform > Relational Model) puis générer le script SQL : File > Generate > Access.


En passant : virer dans chaque entité-type les attributs qui font référence aux identifiants des entités-types référencées (par exemple, dans FACTURE : id_client n’a pas à être là).

[Nono02P]

Bonsoir fsmrel,

C'est avec beaucoup de regrets que je vous annonce que je n'ai pas eu beaucoup de temps à consacrer au dossier de conception cette semaine, ni au reste de ce que j'avais prévu d'ailleurs...

Voilà cependant où j'en suis dans la rédaction de celui-ci :
Dossier conception-00.pdf


Pour l'instant j'ai rédigé les besoins, rappelé les règles de gestion et ajouté les schémas.
L'IHM n'est pas encore dessus !

Vous verrez aussi l'apparition de quelques nouvelles tables (pour le gestion des consommables (suite à une discussion avec ma femme, je me suis aperçu qu'effectivement pour toiletter un chien il fallait utiliser du shampoing... Je l'avais complètement oublié dans mes règles de gestion) ainsi qu'un début de la gestion des utilisateurs), pour faciliter l'ensemble voici les fichiers DB-Main et Excel :
Toilettage 280316.rar


J'ai une petite question, vis à vis de l'import de fichiers .sql vers Access...

J'ai pu créer les tables côté SGBD via des requêtes SQL (ajouté tables par tables et relations par relations) mais n'y a t-il pas un moyen d'importer l'ensemble d'un seul coup?
Sinon cela risque d'être plutôt fastidieux une fois passé sur la BD complète...

J'ai beau parcourir l'aide (DB-Main comme Access), je ne trouve pas grand chose là dessus !


Je présume aussi que tout les champs nommés RG0xx etc doivent être renommés en fonction des données qui y correspondent?

Voici un résumé de règles de gestion :

Achats :

RG001 : Un article peut être demandé au moins 0 et au plus plusieurs fois dans une ligne de commande.
RG002 : Une ligne de commande peut contenir au moins 1 et au plus 1 articles.
RG003 : Une commande contient au moins 1 et au plus plusieurs (articles/lignes) de commande.
RG004 : Une ligne de commande appartient à au moins 1 et au plus 1 commande.
RG005 : Un paiement de commande est réalisé via au moins 1 et au plus plusieurs type de paiement.
RG006 : Un moyen de paiement est utilisé dans au moins 0 et au plus plusieurs paiement de commandes.
RG007 : Un article est fourni par au moins 1 et au plus plusieurs fournisseurs.
RG008 : Un fournisseur peut fournir au moins 0 et au plus plusieurs articles.
RG009 : Un employé peut passer au moins 0 et au plus plusieurs commandes.
RG010 : Une commande peut être passée par au moins 1 et au plus 1 employé.
RG011 : Une commande est passée chez au moins 1 et au plus 1 fournisseur.
RG012 : Un fournisseur peut recevoir au moins 0 et au plus plusieurs commandes.

Animaux :

RG001 : Un animal peut faire l'objet d' au moins 0 et au plus plusieurs prestations.
RG002 : Une prestation peut être réalisée sur au moins 1 et au plus 1 animal.
RG003 : Une race définit au moins 1 et au plus 1 taille d'animal.
RG004 : Une taille d'animal se retrouve dans au moins 0 et au plus plusieurs races.
RG005 : Un détail des animaux en rdv contient au moins 1 et au plus 1 animal.
RG006 : Un animal peut se rendre à  au moins 0 et au plus plusieurs rdv.
RG007 : Un client possède au moins 0 et au plus plusieurs animaux.
RG008 : Un animal appartient à au moins 1 et au plus 1 maitre (client).
RG009 : Une longueur de poil se retrouve dans au moins 0 et au plus plusieurs prestations.
RG010 : Une prestation décrit au moins 1 et au plus 1 longueur de poil.
RG011 : Un animal appartient à au moins 1 et au plus 1 race.
RG012 : Une race est composée d' au moins 0 et au plus plusieurs animaux.
RG013 : Une race fait partie d' au moins 1 et au plus 1 type d'animal.
RG014 : Un type d'animal possède au moins 1 et au plus plusieurs races.

Clients :

RG001 : Un client prend  au moins 0 et au plus plusieurs rdv.
RG002 : Un rdv est pris par au moins 1 et au plus 1 client.
RG003 : Un client possède au moins 0 et au plus plusieurs contacts.
RG004 : Un contact est lié à au moins 1 et au plus 1 client.
RG005 : Un client appartiens à  au moins 1 et au plus 1 civilité.
RG006 : Une civilité désigne  au moins 0 et au plus plusieurs clients.
RG007 : Un client possède au moins 0 et au plus plusieurs animaux.
RG008 : Un animal appartient à au moins 1 et au plus 1 maitre (client).
RG009 : Un client a pu résider à au moins 0 et au plus plusieurs adresses.
RG010 : Une adresse appartient à au moins 1 et au plus 1 clients.
RG011 : Un client peut recevoir au moins 0 et au plus plusieurs devis.
RG012 : Un devis est adressée à au moins 1 et au plus 1 client.
RG013 : Un client peut recevoir  au moins 0 et au plus plusieurs factures.
RG014 : Une facture est adressée à au moins 1 et au plus 1 client.
RG015 : Une facture est liée à  au moins 0 et au plus plusieurs devis.
RG016 : Un devis abouti à  au moins 0 et au plus 1 facture.

Coeur :

RG001 : Un animal peut faire l'objet d' au moins 0 et au plus plusieurs prestations.
RG002 : Une prestation peut être réalisée sur au moins 1 et au plus 1 animal.
RG003 : Une facture peut contenir au moins 0 et au plus plusieurs lignes de prestations.
RG004 : Une prestation peut être au moins 1 et au plus 1 fois facturée.
RG005 : Un employé peut effectuer au moins 0 et au plus plusieurs prestations.
RG006 : Une prestation peut être réalisée par au moins 1 et au plus 1 employé.
RG007 : Un client possède au moins 0 et au plus plusieurs animaux.
RG008 : Un animal appartient à au moins 1 et au plus 1 maitre (client).
RG009 : Un client a pu résider à au moins 0 et au plus plusieurs adresses.
RG010 : Une adresse appartient à au moins 1 et au plus 1 clients.
RG011 : Une facture est éditée par au moins 1 et au plus 1 employé.
RG012 : Un employé peut éditer au moins 0 et au plus plusieurs factures.
RG013 : Un client peut recevoir  au moins 0 et au plus plusieurs factures.
RG014 : Une facture est adressée à au moins 1 et au plus 1 client.
RG015 : Une facture peut contenir au moins 0 et au plus plusieurs lignes de vente d'articles.
RG016 : Une ligne de facture concernant un article peut être au moins 1 et au plus 1 fois affiché sur la facture.
RG017 : Une adresse de facturation est datée par au moins 1 et au plus 1 date d'ajout d'adresse.
RG018 : Une date d'ajout d'adresse permet de dater au moins 1 et au plus 1 adresse de facturation.
RG019 : Une facture comporte au moins 1 et au plus 1 adresse de facturation.
RG020 : Une adresse de facturation se retrouve dans au moins 0 et au plus plusieurs factures.

Devis :

RG001 : Une facture est éditée par au moins 1 et au plus 1 employé.
RG002 : Un employé peut éditer au moins 0 et au plus plusieurs factures.
RG003 : Un devis est édité par au moins 1 et au plus 1 employé.
RG004 : Un employé peut éditer au moins 0 et au plus plusieurs devis.
RG005 : Un devis peut contenir au moins 0 et au plus plusieurs lignes avec des articles.
RG006 : Une ligne de devis pour un article fait partie d' au moins 1 et au plus 1 devis.
RG007 : Un devis peut contenir au moins 0 et au plus plusieurs lignes avec des forfaits de prestation.
RG008 : Une ligne de devis pour un forfait fait partie d' au moins 1 et au plus 1 devis.
RG009 : Une ligne dans un devis concernant un forfait comporte au moins 1 et au plus 1 forfait.
RG010 : Un forfait se retrouve dans au moins 0 et au plus plusieurs ligne de devis.
RG011 : Un client peut recevoir au moins 0 et au plus plusieurs devis.
RG012 : Un devis est adressée à au moins 1 et au plus 1 client.
RG013 : Un client peut recevoir  au moins 0 et au plus plusieurs factures.
RG014 : Une facture est adressée à au moins 1 et au plus 1 client.
RG015 : Une facture est liée à  au moins 0 et au plus plusieurs devis.
RG016 : Un devis abouti à  au moins 0 et au plus 1 facture.
RG017 : Un article apparait dans au moins 0 et au plus plusieurs lignes de devis.
RG018 : Une ligne dans un devis peut contenir au moins 1 et au plus 1 articles.

Factures :

RG001 : Une facture est éditée par au moins 1 et au plus 1 employé.
RG002 : Un employé peut éditer au moins 0 et au plus plusieurs factures.
RG003 : Un devis est édité par au moins 1 et au plus 1 employé.
RG004 : Un employé peut éditer au moins 0 et au plus plusieurs devis.
RG005 : Un employé peut effectuer au moins 0 et au plus plusieurs prestations.
RG006 : Une prestation peut être réalisée par au moins 1 et au plus 1 employé.
RG007 : Une facture peut contenir au moins 0 et au plus plusieurs lignes de prestations.
RG008 : Une prestation peut être au moins 1 et au plus 1 fois facturée.
RG009 : Une facture peut contenir au moins 0 et au plus plusieurs lignes de vente d'articles.
RG010 : Une ligne de facture concernant un article peut être au moins 1 et au plus 1 fois affiché sur la facture.
RG011 : Un paiement de facture est réalisé via au moins 1 et au plus 1 type de paiement.
RG012 : Un moyen de paiement est utilisé dans au moins 0 et au plus plusieurs paiement de factures.
RG013 : Un client peut recevoir  au moins 0 et au plus plusieurs factures.
RG014 : Une facture est adressée à au moins 1 et au plus 1 client.
RG015 : Une facture est liée à  au moins 0 et au plus plusieurs devis.
RG016 : Un devis abouti à  au moins 0 et au plus 1 facture.
RG017 : Une facture est réglée en  au moins 1 et au plus plusieurs règlements.
RG018 : Un paiement est en règlement d' au moins 1 et au plus plusieurs factures. (A voir si pas trop compliqué d'un point de vue compta)

Forfaits :

RG001 : Un forfait appartient à  au moins 1 et au plus 1 type de forfait.
RG002 : Un type de forfait est composé d' au moins 0 et au plus plusieurs forfaits.
RG003 : Un forfait se retrouve dans au moins 0 et au plus plusieurs prestations.
RG004 : Une prestation est basé sur au moins 1 et au plus 1 forfait.
RG005 : Une taille d'animal se retrouve dans au moins 1 et au plus plusieurs forfaits.
RG006 : Un forfait se compose d' au moins 1 et au plus 1 taille d'animal.
RG007 : Une tva s'applique sur  au moins 1 et au plus plusieurs forfaits.
RG008 : Une forfait comporte au moins 1 et au plus 1 tva.
RG009 : Une ligne dans un devis concernant un forfait comporte au moins 1 et au plus 1 forfait.
RG010 : Un forfait se retrouve dans au moins 0 et au plus plusieurs ligne de devis.
RG011 : Un type d'animal définit au moins 1 et au plus plusieurs forfaits.
RG012 : Un forfait dépend d' au moins 1 et au plus 1 type d'animal.
RG013 : Un forfait est définit par au moins 1 et au plus 1 longueur de poil.
RG014 : Une longueur de poil définit au moins 1 et au plus plusieurs forfaits.

Livraisons :

RG001 : Un article peut être demandé au moins 0 et au plus plusieurs fois dans une ligne de commande.
RG002 : Une ligne de commande peut contenir au moins 1 et au plus 1 articles.
RG003 : Une commande contient au moins 1 et au plus plusieurs (articles/lignes) de commande.
RG004 : Une ligne de commande appartient à au moins 1 et au plus 1 commande.
RG005 : Une commande peut aboutir à au moins 1 et au plus plusieurs livraisons.
RG006 : Une livraison peut être à la suite d' au moins 1 et au plus plusieurs commandes.
RG007 : Un article est fourni par au moins 1 et au plus plusieurs fournisseurs.
RG008 : Un fournisseur peut fournir au moins 0 et au plus plusieurs articles.
RG009 : Un article apparait dans au moins 0 et au plus plusieurs ligne de bon de livraison.
RG010 : Une ligne de bon de livraison peut contenir au moins 1 et au plus 1 articles.
RG011 : Une commande est passée chez au moins 1 et au plus 1 fournisseur.
RG012 : Un fournisseur peut recevoir au moins 0 et au plus plusieurs commandes.
RG013 : Une livraison peut être délivrée par  au moins 1 et au plus 1 transporteur.
RG014 : Un transporteur peut effectuer au moins 0 et au plus plusieurs livraisons.
RG015 : Une livraison comporte au moins 1 et au plus plusieurs lignes dans le bon de livraison.
RG016 : Une ligne dans un bon de livraison se retrouve dans au moins 1 et au plus 1 une livraison.
RG017 : Un employé peut réceptionner au moins 0 et au plus plusieurs livraisons.
RG018 : Une livraison peut être réceptionnée par au moins 1 et au plus 1 employé.

RDV :

RG001 : Un client prend  au moins 0 et au plus plusieurs rdv.
RG002 : Un rdv est pris par au moins 1 et au plus 1 client.
RG003 : Un rdv contient  au moins 1 et au plus plusieurs animaux.
RG004 : Un détail des animaux en rdv est présent dans au moins 1 et au plus 1 rdv.
RG005 : Un détail des animaux en rdv contient au moins 1 et au plus 1 animal.
RG006 : Un animal peut se rendre à  au moins 0 et au plus plusieurs rdv.
RG007 : Un client possède au moins 0 et au plus plusieurs animaux.
RG008 : Un animal appartient à au moins 1 et au plus 1 maitre (client).
RG009 : Un client prenant rdv pour son animal prévoit  au moins 1 et au plus 1 type de forfait.
RG010 : Un type de forfait peut se retrouver dans au moins 0 et au plus plusieurs rdv d'animaux.
RG011 : Un type d'animal définit au moins 1 et au plus plusieurs forfaits.
RG012 : Un forfait dépend d' au moins 1 et au plus 1 type d'animal.
RG013 : Un forfait appartient à  au moins 1 et au plus 1 type de forfait.
RG014 : Un type de forfait est composé d' au moins 0 et au plus plusieurs forfaits.

Stocks :

RG001 : Un article apparait dans au moins 0 et au plus plusieurs ligne de vente de factures.
RG002 : Une ligne de vente dans une facture peut contenir au moins 1 et au plus 1 articles.
RG003 : Un article apparait dans au moins 0 et au plus plusieurs ligne de bon de livraison.
RG004 : Une ligne de bon de livraison peut contenir au moins 1 et au plus 1 articles.
RG005 : Un article peut appartenir à au moins 1 et au plus 1 catégorie d'articles.
RG006 : Une catégorie d'articles peut contenir au moins 0 et au plus plusieurs articles.
RG007 : Un article est fourni par au moins 1 et au plus plusieurs fournisseurs.
RG008 : Un fournisseur peut fournir au moins 0 et au plus plusieurs articles.

Suppléments :

RG001 : Un supplément de prestation fait partie d' au moins 0 et au plus plusieurs prestation.
RG002 : Une prestation contient au moins 0 et au plus plusieurs suppléments.
RG003 : Un supplément de prestation comporte au moins 1 et au plus 1 tva.
RG004 : Une tva s'applique sur  au moins 1 et au plus plusieurs suppléments.
RG005 : Une tva est datée par au moins 1 et au plus 1 date d'application.
RG006 : Une date d'application permet de dater au moins 1 et au plus plusieurs valeurs de tva.

TVA :

RG001 : Une ligne dans un bon de livraison comporte au moins 1 et au plus 1 tva.
RG002 : Une tva s'applique sur  au moins 1 et au plus plusieurs ligne de bon de livraison.
RG003 : Une ligne de facture concernant un article comporte au moins 1 et au plus 1 tva.
RG004 : Une tva s'applique sur  au moins 1 et au plus plusieurs ligne de facture concernant un article.
RG005 : Une ligne de devis concernant un article comporte au moins 1 et au plus 1 tva.
RG006 : Une tva s'applique sur  au moins 1 et au plus plusieurs ligne de devis concernant un article.
RG007 : Une tva s'applique sur  au moins 1 et au plus plusieurs forfaits.
RG008 : Une forfait comporte au moins 1 et au plus 1 tva.
RG009 : Une tva est datée par au moins 1 et au plus 1 date d'application.
RG010 : Une date d'application permet de dater au moins 1 et au plus plusieurs valeurs de tva.

Villes :

RG001 : Un pays est composé d' au moins 1 et au plus plusieurs villes.
RG002 : Une ville se situe dans au moins 1 et au plus 1 pays.
RG003 : Une ville contient au moins 0 et au plus plusieurs adresses de fournisseurs.
RG004 : Une adresse de fournisseurs se situe dans au moins 1 et au plus 1 ville.
RG005 : Une ville contient au moins 0 et au plus plusieurs adresses de clients.
RG006 : Une adresse de facturation se situe dans au moins 1 et au plus 1 ville.
RG007 : Une ville contient au moins 0 et au plus plusieurs adresses d'employés.
RG008 : Une adresse d'employé se situe dans au moins 1 et au plus 1 ville.
RG009 : Un client a pu résider à au moins 0 et au plus plusieurs adresses.
RG010 : Une adresse appartient à au moins 1 et au plus 1 clients.
RG011 : Une ville contient au moins 0 et au plus plusieurs adresses de transporteurs.
RG012 : Une adresse de transporteurs se situe dans au moins 1 et au plus 1 ville.

Je joue encore un peu avec les imports SQL sous Access, et je continue le document pour la partie IHM.

Merci par avance de votre réponse

Bonne nuit


PS: Ne vous en voulez pas pour avoir demandé la couleur dans les PRE, ça m'a pris moins de 2 min je me suis contenté d'une petite formule

[fsmrel]

Bonsoir Nono,


Je viens seulement de voir votre dernier message, je regarderai demain.

J’ai créé des billets (le 1er est ici) dans lesquels j’explique comment se servir de DB-MAIN.

Je compte sur vos remarques pour améliorer tout ça...


A propos de l’urbanisation :

Avec DB-MAIN, vous allez pouvoir urbaniser sans problème. J’ai creusé un peu le sujet, et lui consacrerai un billet.

En attendant, voilà par exemple comment procéder pour le référentiel (sous-domaine, sous-univers...) CŒUR :

Supposons que les entités-types parties prenantes soient les suivantes :

CLIENT

ANIMAL

PRESTATION

FACTURE

On va créer une vue DB-MAIN avec ces 4 entités-types (et leurs associations).

Pour cela, vous les marquez. Exemple avec CLIENT :

Clic droit sur le cartouche qui contient le nom CLIENT, l’élément qui nous intéresse est « Mark selected » :





On clique sur « Mark selected », et l’entité-type CLIENT est marquée, ce qui est confirmé par l’ombre portée par le rectangle :





De toute façon, si vous avez un doute sur le marquage, vous refaites un clic droit sur CLIENT et vérifiez que « Mark selected » est bien coché.


Une fois que tous les éléments à sélectionner sont marqués (les entités-types et leurs associations), vous déclarez une vue DB-MAIN :

PRODUCT >View > Define view :

DB-MAIN demande le nom de la vue, allons-y pour VUE01 :





Puis on la crée ainsi :

PRODUCT >View > Generate view :

DB-MAIN propose la fenêtre :





On fait « OK » et maintenant on peut se focaliser sur le cœur...

[Nono02P]

Bonsoir fsmrel,

Clic droit sur le cartouche qui contient le nom CLIENT, l’élément qui nous intéresse est « Mark selected » :

La technique des views, je connaissais j'ai trouvé ça en bidouillant dessus (je vous en avais parlé dans un MP (c'est vrai que j'aurais du passer par ici mais je voulais pas up mon sujet devant les autres juste pour une petite question qui me paraissait presque banale) vous demandant si il n'y avait pas mieux que les Views) !
L’inconvénient c'est que ce n'est pas "sauvegardé", dans le sens où la view définie ne permet pas d'être réutilisée sur la révision supérieure (sans re-sélectionner tout les éléments pour ensuite les réorganiser, ce qui me parait un peu lourd au cas où j'oublie une relation par exemple)...


Je vais de ce pas jeter un oeil sur votre billet, et vous donnerais mon avis ;-)

Bonne journée (ou bonne nuit, si vous allez vous coucher) !


EDIT 28/03/16 à 5h58 : Je reviens sur ce que j'ai dit, j'avais du mal manipuler ou je ne sais pas ce que j'ai fait... En copiant un schéma les views sont conservés et en marquant l'ensemble et en rappelant une vue, tout se re-décompose comme il se doit !
Je suis tenté de refaire complètement mon urbanisation... Cependant votre application plante toujours à l'ouverture du gros fichier contenant la synthèse de tout ?

[fsmrel]

Bonsoir Nono,

Virer dans chaque entité-type les attributs qui font référence aux identifiants des entités-types référencées (par exemple, dans FACTURE : id_client n’a pas à être là).

Sinon, lors de la génération du MLD, pour ne pas créer des noms en double, DB-MAIN générera un attribut tout neuf, utilisé pour la clé étrangère faisant référence à la table cible. Dans l’exemple, ce nom sera RG013, c'est-à-dire le nom du rôle dans l’association entre FACTURE et CLIENT : l’attribut id_client que vous avez défini pour l’entité-type FACTURE deviendrait alors sans emploi et à supprimer...

Votre application plante toujours à l'ouverture du gros fichier contenant la synthèse de tout ?

J’arrive à ouvrir le fichier, mais j’ai pris le parti de faire une rétro-conception en DB-MAIN 9.2, à partir de votre code SQL. Le problème est qu’il y a le ménage à faire dans les attributs qui provoquent la création de noms en double, sinon lors de la rétro-conception j’ai des erreurs peut-être dues à cela.


J’ai l’impression qu’il y a une désynchronisation entre les règles de gestion des données et le MCD : par exemple, où est passé l’entité-type ADRESSE ? Il ne reste plus que l’adresse de facturation ? Ou bien ai-je mal fouillé ?

[Nono02P]

Bonjour fsmrel,

Sinon, lors de la génération du MLD, pour ne pas créer des noms en double, DB-MAIN générera un attribut tout neuf, utilisé pour la clé étrangère faisant référence à la table cible. Dans l’exemple, ce nom sera RG013, c'est-à-dire le nom du rôle dans l’association entre FACTURE et CLIENT : l’attribut id_client que vous avez défini pour l’entité-type FACTURE deviendrait alors sans emploi et à supprimer...

Je les ai supprimé dans la révision 003 des fichiers DB-Main (j'en ai peut être oublié mais id_client de la table FACTURE n'existe plus normalement ainsi que dans la table ANIMAL.)

J’arrive à ouvrir le fichier, mais j’ai pris le parti de faire une rétro-conception en DB-MAIN 9.2, à partir de votre code SQL. Le problème est qu’il y a le ménage à faire dans les attributs qui provoquent la création de noms en double, sinon lors de la rétro-conception j’ai des erreurs peut-être dues à cela.


J’ai l’impression qu’il y a une désynchronisation entre les règles de gestion des données et le MCD : par exemple, où est passé l’entité-type ADRESSE ? Il ne reste plus que l’adresse de facturation ? Ou bien ai-je mal fouillé ?

Je comprends mieux pourquoi vous avez encore id_client etc...
Dans mon archive les exports SQL étaient des essais intermédiaires que j'ai oublié de purger avant de vous transmettre le projet, désolé !

Pour ce qui est de la table ADRESSE, de mémoire elle n'a jamais existé (je vérifie ce soir) il a toujours été question de ADRESSE_FACTURE je pense.

Je vais re-exporter les fichiers SQL de chaque ensembles pour vous les transmettre à jour !

Si vous ne pouvez pas ouvrir directement les fichiers DB-Main à cause de la version, vous pouvez consulter le contenu du dossier de conception en pdf, normalement c'est la dernière version.

Dès que j'ai le temps je fais l'export SQL !

Bonne journée


EDIT 30/03/16 à 20h : Voici ci-dessous les fichiers avec les exports isl (au cas où ça fonctionne d'une version vers l'autre) et les SQL.
Toilettage.zip

[fsmrel]

Bonsoir Nono,

Voici ci-dessous les fichiers avec les exports isl

Les fichiers sont vides d’entités-types, il n’y a que des métadonnées... Pour exporter un schéma, par exemple « Cœur », il ne faut pas l’ouvrir, mais dans la fenêtre des projets, le sélectionner (dans son ovale) et là on peut l’exporter. Pour s’assurer que ça a marché, ouvrir le fichier .isl avec un éditeur de texte et chercher par exemple CLIENT ou FACTURE...

[Nono02P]

Bonsoir fsmrel,

Les fichiers sont vides d’entités-types, il n’y a que des métadonnées... Pour exporter un schéma, par exemple « Cœur », il ne faut pas l’ouvrir, mais dans la fenêtre des projets, le sélectionner (dans son ovale) et là on peut l’exporter. Pour s’assurer que ça a marché, ouvrir le fichier .isl avec un éditeur de texte et chercher par exemple CLIENT ou FACTURE...

Aie, désolé !

Je fini mes modifications avant d'aller me coucher et je met à jour l'ensemble avec les bons isl cette fois...

[fsmrel]

En complément :

Vous pouvez exporter N schémas (MCD, MLD, VUES) dans un seul fichier.

vous pouvez exporter en une fois tous les schémas : au lieu d'exporter, vous sauvegardez le projet non pas en .LUN mais en .ISL

Pour vérifier que ça marche, vous ouvrez carrément le .ISL au lieu d'un .LUN, ou bien vous créez un nouveau projet et vous importez le .ISL.

[Nono02P]

Vous pouvez exporter N schémas (MCD, MLD, VUES) dans un seul fichier.

vous pouvez exporter en une fois tous les schémas : au lieu d'exporter, vous sauvegardez le projet non pas en .LUN mais en .ISL

Pour vérifier que ça marche, vous ouvrez carrément le .ISL au lieu d'un .LUN, ou bien vous créez un nouveau projet et vous importez le .ISL.

Merci pour l'astuce. J'ai enfin fini de refaire l'urbanisation !

J'ai aussi sauvegardé en .lun et .isl (le .lun c'est au cas où d'autres personnes passent par là et veulent voir le fichier !)

J'ai pas eu le courage (cette nuit) de renuméroter chacune des RG pour chaque sous ensembles...
Je me suis contenté de faire la référence croisée dans Excel et les balises ci-dessous, cependant si ça vous dérange pour la compréhension n'hésitez pas à me le dire je repasserai dessus pour avoir les numérotations 001, 002, 003, etc... !

Ci-dessous les fichiers :
Toilettage.zip

Les règles de gestion:

Achats :

RG053 : Un article peut être demandé au moins 0 et au plus plusieurs fois dans une ligne de commande.
RG054 : Une ligne de commande peut contenir au moins 1 et au plus 1 articles.
RG059 : Une commande contient au moins 1 et au plus plusieurs (articles/lignes) de commande.
RG060 : Une ligne de commande appartient à au moins 1 et au plus 1 commande.
RG043 : Un paiement de commande est réalisé via au moins 1 et au plus plusieurs type de paiement.
RG044 : Un moyen de paiement est utilisé dans au moins 0 et au plus plusieurs paiement de commandes.
RG071 : Un article est fourni par au moins 1 et au plus plusieurs fournisseurs.
RG072 : Un fournisseur peut fournir au moins 0 et au plus plusieurs articles.
RG037 : Un employé peut passer au moins 0 et au plus plusieurs commandes.
RG038 : Une commande peut être passée par au moins 1 et au plus 1 employé.
RG045 : Une commande est passée chez au moins 1 et au plus 1 fournisseur.
RG046 : Un fournisseur peut recevoir au moins 0 et au plus plusieurs commandes.
RG119 : Un employé est désigné dans au moins 1 et au plus 1 niveau d'accès
RG120 : Un niveau d'accès permet de désigner les droits d' au moins 0 et au plus plusieurs employés.

Animaux :

RG047 : Un animal peut faire l'objet d' au moins 0 et au plus plusieurs prestations.
RG048 : Une prestation peut être réalisée sur au moins 1 et au plus 1 animal.
RG033 : Une race définit au moins 1 et au plus 1 taille d'animal.
RG034 : Une taille d'animal se retrouve dans au moins 0 et au plus plusieurs races.
RG025 : Un détail des animaux en rdv contient au moins 1 et au plus 1 animal.
RG026 : Un animal peut se rendre à  au moins 0 et au plus plusieurs rdv.
RG007 : Un client possède au moins 0 et au plus plusieurs animaux.
RG008 : Un animal appartient à au moins 1 et au plus 1 maitre (client).
RG027 : Une longueur de poil se retrouve dans au moins 0 et au plus plusieurs prestations.
RG028 : Une prestation décrit au moins 1 et au plus 1 longueur de poil.
RG103 : Un animal appartient à au moins 1 et au plus 1 race.
RG104 : Une race est composée d' au moins 0 et au plus plusieurs animaux.
RG031 : Une race fait partie d' au moins 1 et au plus 1 type d'animal.
RG032 : Un type d'animal possède au moins 1 et au plus plusieurs races.

Clients :

RG001 : Un client prend  au moins 0 et au plus plusieurs rdv.
RG002 : Un rdv est pris par au moins 1 et au plus 1 client.
RG101 : Un client possède au moins 0 et au plus plusieurs contacts.
RG102 : Un contact est lié à au moins 1 et au plus 1 client.
RG005 : Un client appartiens à  au moins 1 et au plus 1 civilité.
RG006 : Une civilité désigne  au moins 0 et au plus plusieurs clients.
RG007 : Un client possède au moins 0 et au plus plusieurs animaux.
RG008 : Un animal appartient à au moins 1 et au plus 1 maitre (client).
RG009 : Un client a pu résider à au moins 0 et au plus plusieurs adresses de facturation.
RG010 : Une adresse de facturation appartient à au moins 1 et au plus 1 clients.
RG011 : Un client peut recevoir au moins 0 et au plus plusieurs devis.
RG012 : Un devis est adressée à au moins 1 et au plus 1 client.
RG013 : Un client peut recevoir  au moins 0 et au plus plusieurs factures.
RG014 : Une facture est adressée à au moins 1 et au plus 1 client.
RG015 : Une facture est liée à  au moins 0 et au plus plusieurs devis.
RG016 : Un devis abouti à  au moins 0 et au plus 1 facture.
RG117 : Une facture comporte au moins 1 et au plus 1 adresse de facturation.
RG118 : Une adresse de facturation se retrouve dans au moins 0 et au plus plusieurs factures.

Coeur :

RG047 : Un animal peut faire l'objet d' au moins 0 et au plus plusieurs prestations.
RG048 : Une prestation peut être réalisée sur au moins 1 et au plus 1 animal.
RG067 : Une facture peut contenir au moins 0 et au plus plusieurs lignes de prestations.
RG068 : Une prestation peut être au moins 1 et au plus 1 fois facturée.
RG041 : Un employé peut effectuer au moins 0 et au plus plusieurs prestations.
RG042 : Une prestation peut être réalisée par au moins 1 et au plus 1 employé.
RG007 : Un client possède au moins 0 et au plus plusieurs animaux.
RG008 : Un animal appartient à au moins 1 et au plus 1 maitre (client).
RG009 : Un client a pu résider à au moins 0 et au plus plusieurs adresses de facturation.
RG010 : Une adresse de facturation appartient à au moins 1 et au plus 1 clients.
RG019 : Une facture est éditée par au moins 1 et au plus 1 employé.
RG020 : Un employé peut éditer au moins 0 et au plus plusieurs factures.
RG013 : Un client peut recevoir  au moins 0 et au plus plusieurs factures.
RG014 : Une facture est adressée à au moins 1 et au plus 1 client.
RG069 : Une facture peut contenir au moins 0 et au plus plusieurs lignes de vente d'articles.
RG070 : Une ligne de facture concernant un article peut être au moins 1 et au plus 1 fois affiché sur la facture.
RG113 : Une adresse de facturation est datée par au moins 1 et au plus 1 date d'ajout d'adresse.
RG114 : Une date d'ajout d'adresse permet de dater au moins 1 et au plus 1 adresse de facturation.
RG117 : Une facture comporte au moins 1 et au plus 1 adresse de facturation.
RG118 : Une adresse de facturation se retrouve dans au moins 0 et au plus plusieurs factures.

Devis :

RG019 : Une facture est éditée par au moins 1 et au plus 1 employé.
RG020 : Un employé peut éditer au moins 0 et au plus plusieurs factures.
RG021 : Un devis est édité par au moins 1 et au plus 1 employé.
RG022 : Un employé peut éditer au moins 0 et au plus plusieurs devis.
RG065 : Un devis peut contenir au moins 0 et au plus plusieurs lignes avec des articles.
RG066 : Une ligne de devis pour un article fait partie d' au moins 1 et au plus 1 devis.
RG063 : Un devis peut contenir au moins 0 et au plus plusieurs lignes avec des forfaits de prestation.
RG064 : Une ligne de devis pour un forfait fait partie d' au moins 1 et au plus 1 devis.
RG091 : Une ligne dans un devis concernant un forfait comporte au moins 1 et au plus 1 forfait.
RG092 : Un forfait se retrouve dans au moins 0 et au plus plusieurs ligne de devis.
RG011 : Un client peut recevoir au moins 0 et au plus plusieurs devis.
RG012 : Un devis est adressée à au moins 1 et au plus 1 client.
RG013 : Un client peut recevoir  au moins 0 et au plus plusieurs factures.
RG014 : Une facture est adressée à au moins 1 et au plus 1 client.
RG015 : Une facture est liée à  au moins 0 et au plus plusieurs devis.
RG016 : Un devis abouti à  au moins 0 et au plus 1 facture.
RG051 : Un article apparait dans au moins 0 et au plus plusieurs lignes de devis.
RG052 : Une ligne dans un devis peut contenir au moins 1 et au plus 1 articles.

Factures :

RG019 : Une facture est éditée par au moins 1 et au plus 1 employé.
RG020 : Un employé peut éditer au moins 0 et au plus plusieurs factures.
RG021 : Un devis est édité par au moins 1 et au plus 1 employé.
RG022 : Un employé peut éditer au moins 0 et au plus plusieurs devis.
RG041 : Un employé peut effectuer au moins 0 et au plus plusieurs prestations.
RG042 : Une prestation peut être réalisée par au moins 1 et au plus 1 employé.
RG067 : Une facture peut contenir au moins 0 et au plus plusieurs lignes de prestations.
RG068 : Une prestation peut être au moins 1 et au plus 1 fois facturée.
RG069 : Une facture peut contenir au moins 0 et au plus plusieurs lignes de vente d'articles.
RG070 : Une ligne de facture concernant un article peut être au moins 1 et au plus 1 fois affiché sur la facture.
RG023 : Un paiement de facture est réalisé via au moins 1 et au plus 1 type de paiement.
RG024 : Un moyen de paiement est utilisé dans au moins 0 et au plus plusieurs paiement de factures.
RG013 : Un client peut recevoir  au moins 0 et au plus plusieurs factures.
RG014 : Une facture est adressée à au moins 1 et au plus 1 client.
RG015 : Une facture est liée à  au moins 0 et au plus plusieurs devis.
RG016 : Un devis abouti à  au moins 0 et au plus 1 facture.
RG017 : Une facture est réglée en  au moins 1 et au plus plusieurs règlements.
RG018 : Un paiement est en règlement d' au moins 1 et au plus plusieurs factures. (A voir si pas trop compliqué d'un point de vue compta)
RG011 : Un client peut recevoir au moins 0 et au plus plusieurs devis.
RG012 : Un devis est adressée à au moins 1 et au plus 1 client.

Forfaits :

RG099 : Un forfait appartient à  au moins 1 et au plus 1 type de forfait.
RG100 : Un type de forfait est composé d' au moins 0 et au plus plusieurs forfaits.
RG093 : Un forfait se retrouve dans au moins 0 et au plus plusieurs prestations.
RG094 : Une prestation est basé sur au moins 1 et au plus 1 forfait.
RG095 : Une taille d'animal se retrouve dans au moins 1 et au plus plusieurs forfaits.
RG096 : Un forfait se compose d' au moins 1 et au plus 1 taille d'animal.
RG105 : Une tva s'applique sur  au moins 1 et au plus plusieurs forfaits.
RG106 : Une forfait comporte au moins 1 et au plus 1 tva.
RG091 : Une ligne dans un devis concernant un forfait comporte au moins 1 et au plus 1 forfait.
RG092 : Un forfait se retrouve dans au moins 0 et au plus plusieurs ligne de devis.
RG097 : Un type d'animal définit au moins 1 et au plus plusieurs forfaits.
RG098 : Un forfait dépend d' au moins 1 et au plus 1 type d'animal.
RG107 : Un forfait est définit par au moins 1 et au plus 1 longueur de poil.
RG108 : Une longueur de poil définit au moins 1 et au plus plusieurs forfaits.

Livraisons :

RG053 : Un article peut être demandé au moins 0 et au plus plusieurs fois dans une ligne de commande.
RG054 : Une ligne de commande peut contenir au moins 1 et au plus 1 articles.
RG059 : Une commande contient au moins 1 et au plus plusieurs (articles/lignes) de commande.
RG060 : Une ligne de commande appartient à au moins 1 et au plus 1 commande.
RG061 : Une commande peut aboutir à au moins 1 et au plus plusieurs livraisons.
RG062 : Une livraison peut être à la suite d' au moins 1 et au plus plusieurs commandes.
RG071 : Un article est fourni par au moins 1 et au plus plusieurs fournisseurs.
RG072 : Un fournisseur peut fournir au moins 0 et au plus plusieurs articles.
RG055 : Un article apparait dans au moins 0 et au plus plusieurs ligne de bon de livraison.
RG056 : Une ligne de bon de livraison peut contenir au moins 1 et au plus 1 articles.
RG045 : Une commande est passée chez au moins 1 et au plus 1 fournisseur.
RG046 : Un fournisseur peut recevoir au moins 0 et au plus plusieurs commandes.
RG073 : Une livraison peut être délivrée par  au moins 1 et au plus 1 transporteur.
RG074 : Un transporteur peut effectuer au moins 0 et au plus plusieurs livraisons.
RG089 : Une livraison comporte au moins 1 et au plus plusieurs lignes dans le bon de livraison.
RG090 : Une ligne dans un bon de livraison se retrouve dans au moins 1 et au plus 1 une livraison.
RG039 : Un employé peut réceptionner au moins 0 et au plus plusieurs livraisons.
RG040 : Une livraison peut être réceptionnée par au moins 1 et au plus 1 employé.

RDV :

RG001 : Un client prend  au moins 0 et au plus plusieurs rdv.
RG002 : Un rdv est pris par au moins 1 et au plus 1 client.
RG003 : Un rdv contient  au moins 1 et au plus plusieurs animaux.
RG004 : Un détail des animaux en rdv est présent dans au moins 1 et au plus 1 rdv.
RG025 : Un détail des animaux en rdv contient au moins 1 et au plus 1 animal.
RG026 : Un animal peut se rendre à  au moins 0 et au plus plusieurs rdv.
RG007 : Un client possède au moins 0 et au plus plusieurs animaux.
RG008 : Un animal appartient à au moins 1 et au plus 1 maitre (client).
RG029 : Un client prenant rdv pour son animal prévoit  au moins 1 et au plus 1 type de forfait.
RG030 : Un type de forfait peut se retrouver dans au moins 0 et au plus plusieurs rdv d'animaux.
RG097 : Un type d'animal définit au moins 1 et au plus plusieurs forfaits.
RG098 : Un forfait dépend d' au moins 1 et au plus 1 type d'animal.
RG099 : Un forfait appartient à  au moins 1 et au plus 1 type de forfait.
RG100 : Un type de forfait est composé d' au moins 0 et au plus plusieurs forfaits.

Stocks :

RG049 : Un article apparait dans au moins 0 et au plus plusieurs ligne de vente de factures.
RG050 : Une ligne de vente dans une facture peut contenir au moins 1 et au plus 1 articles.
RG055 : Un article apparait dans au moins 0 et au plus plusieurs ligne de bon de livraison.
RG056 : Une ligne de bon de livraison peut contenir au moins 1 et au plus 1 articles.
RG057 : Un article peut appartenir à au moins 1 et au plus 1 catégorie d'articles.
RG058 : Une catégorie d'articles peut contenir au moins 0 et au plus plusieurs articles.
RG071 : Un article est fourni par au moins 1 et au plus plusieurs fournisseurs.
RG072 : Un fournisseur peut fournir au moins 0 et au plus plusieurs articles.
RG121 : Un article peut être  au moins 0 et au plus plusieurs fois consommé.
RG122 : Une consommation d'article décrit au moins 1 et au plus 1 article consommé

Suppléments :

RG109 : Un supplément de prestation fait partie d' au moins 0 et au plus plusieurs prestation.
RG110 : Une prestation contient au moins 0 et au plus plusieurs suppléments.
RG111 : Un supplément de prestation comporte au moins 1 et au plus 1 tva.
RG112 : Une tva s'applique sur  au moins 1 et au plus plusieurs suppléments.
RG115 : Une tva est datée par au moins 1 et au plus 1 date d'application.
RG116 : Une date d'application permet de dater au moins 1 et au plus plusieurs valeurs de tva.

TVA :

RG083 : Une ligne dans un bon de livraison comporte au moins 1 et au plus 1 tva.
RG084 : Une tva s'applique sur  au moins 1 et au plus plusieurs ligne de bon de livraison.
RG085 : Une ligne de facture concernant un article comporte au moins 1 et au plus 1 tva.
RG086 : Une tva s'applique sur  au moins 1 et au plus plusieurs ligne de facture concernant un article.
RG087 : Une ligne de devis concernant un article comporte au moins 1 et au plus 1 tva.
RG088 : Une tva s'applique sur  au moins 1 et au plus plusieurs ligne de devis concernant un article.
RG105 : Une tva s'applique sur  au moins 1 et au plus plusieurs forfaits.
RG106 : Une forfait comporte au moins 1 et au plus 1 tva.
RG115 : Une tva est datée par au moins 1 et au plus 1 date d'application.
RG116 : Une date d'application permet de dater au moins 1 et au plus plusieurs valeurs de tva.
RG111 : Un supplément de prestation comporte au moins 1 et au plus 1 tva.
RG112 : Une tva s'applique sur  au moins 1 et au plus plusieurs suppléments.

Villes :

RG035 : Un pays est composé d' au moins 1 et au plus plusieurs villes.
RG036 : Une ville se situe dans au moins 1 et au plus 1 pays.
RG081 : Une ville contient au moins 0 et au plus plusieurs adresses de fournisseurs.
RG082 : Une adresse de fournisseurs se situe dans au moins 1 et au plus 1 ville.
RG075 : Une ville contient au moins 0 et au plus plusieurs adresses de clients.
RG076 : Une adresse de facturation se situe dans au moins 1 et au plus 1 ville.
RG077 : Une ville contient au moins 0 et au plus plusieurs adresses d'employés.
RG078 : Une adresse d'employé se situe dans au moins 1 et au plus 1 ville.
RG009 : Un client a pu résider à au moins 0 et au plus plusieurs adresses de facturation.
RG010 : Une adresse de facturation appartient à au moins 1 et au plus 1 clients.
RG079 : Une ville contient au moins 0 et au plus plusieurs adresses de transporteurs.
RG080 : Une adresse de transporteurs se situe dans au moins 1 et au plus 1 ville.

Voilà voilà !
J'espère ne pas m'être planté cette fois (le précédent isl, on va dire que c'était un poisson d'avril)...

A bientôt

[fsmrel]

Bonsoir Nono,

J'ai pas eu le courage (cette nuit) de renuméroter chacune des RG pour chaque sous ensembles...
Je me suis contenté de faire la référence croisée dans Excel et les balises ci-dessous, cependant si ça vous dérange pour la compréhension n'hésitez pas à me le dire je repasserai dessus pour avoir les numérotations 001, 002, 003, etc... !

Je préfère comme c’est. La règle Rx est nommé Rx partout, c’est parfait !

J'espère ne pas m'être planté cette fois (le précédent isl, on va dire que c'était un poisson d'avril)...

J’ouvre le fichier ISL sans problème avec DB-MAIN 9.2, les vues sont ... visibles , tout va bien.

Vous pouvez postuler pour une médaille DB-MAIN !

[Nono02P]

Bonsoir fsmrel,

Je préfère comme c’est. La règle Rx est nommé Rx partout, c’est parfait !

Parfait alors, je ferais tout de même une règle pour les classer par ordre alphabétique, ça fera moins bricolage (j'avoue qu'après la nuit blanche juste avant d'aller bosser, j'avais pas le courage lol)...

Vous pouvez postuler pour une médaille DB-MAIN !

Comme vous y tenez, c'est fait !

[fsmrel]

Bonsoir Nono,

je ferais tout de même une règle pour les classer par ordre alphabétique

Mas l’ordre numérique me convient parfaitement ! C’est ce qui convient pour fouiller dans le MCD...

Comme vous y tenez, c'est fait !

Problème : dans votre profil pro, seul l’onglet « Activité sur developpez » apparaît... N’auriez-vous pas fermé la case de la médaille (cliqué sur la croix normalement rouge) dans l’onglet « Compétences » ?

[Nono02P]

fsmrel,

Mas l’ordre numérique me convient parfaitement ! C’est ce qui convient pour fouiller dans le MCD...

Je crois que je me suis mal exprimé sur le coup !

Je vais laisser tel quel mais remis dans l'ordre par exemple pour RDV :

RG001 : Un client prend  au moins 0 et au plus plusieurs rdv.
RG002 : Un rdv est pris par au moins 1 et au plus 1 client.
RG003 : Un rdv contient  au moins 1 et au plus plusieurs animaux.
RG004 : Un détail des animaux en rdv est présent dans au moins 1 et au plus 1 rdv.
RG025 : Un détail des animaux en rdv contient au moins 1 et au plus 1 animal.
RG026 : Un animal peut se rendre à  au moins 0 et au plus plusieurs rdv.
RG007 : Un client possède au moins 0 et au plus plusieurs animaux.

Deviendrait

RG001 : Un client prend  au moins 0 et au plus plusieurs rdv.
RG002 : Un rdv est pris par au moins 1 et au plus 1 client.
RG003 : Un rdv contient  au moins 1 et au plus plusieurs animaux.
RG004 : Un détail des animaux en rdv est présent dans au moins 1 et au plus 1 rdv.
RG007 : Un client possède au moins 0 et au plus plusieurs animaux.
RG025 : Un détail des animaux en rdv contient au moins 1 et au plus 1 animal.
RG026 : Un animal peut se rendre à  au moins 0 et au plus plusieurs rdv.

Pour les compétences elles n'étaient visibles que par les recruteurs et l'équipe DVP.
C'est corrigé !


Bonne soirée !

[fsmrel]

Bonsoir Nono,

Je vais laisser tel quel mais remis dans l'ordre par exemple pour RDV

C’est une affaire qui marche !

C'est corrigé !

Vu !

Bonne nuit.

[Nono02P]

Bonjour fsmrel,

Ma question va sans doute paraitre débile mais si je me pose la question c'est que ce n'est pas encore totalement clair chez moi (et de plus je ne suis que débutant DB-Main ) !

Au passage du MCD au MLD, celui-ci me crée une multitude d'éléments ce qui est normal, c'est l’œuvre des relations.

Afin de rendre plus compréhensible l'ensemble, je renomme mon MLD avant d'importer sous access et commencer à faire une première ébauche d'IHM pour le dossier de conception.

Bref, sous la table FORFAIT le MLD généré par exemple :




Si on se concentre uniquement sur RG100_RG097 / RG100_id_type_forfait et RG106_RG116 / RG106_id_tva.

Nous avons un doublet de clefs pour la liaison avec une table (corrigez moi si je me trompe) ce qui ferait dans l'ordre.
RG100_RG097 ==> id_type_animal
RG100_id_type_forfait ==> id_type_forfait

RG106_RG116 ==> id_date_applic_prix
RG106_id_tva ==> id_tva


Au final, dans la table FORFAIT, je pense que c'est ça
{RG095, id_type_animal, id_type_forfait, RG108, id_forfait, date_application, prix_forfait, id_date_applic_prix, id_tva}

Mais surtout pas ça
{RG095, id_type_animal_id_type_forfait, RG108, id_forfait, date_application, prix_forfait, id_date_applic_prix_id_tva}

Pouvez vous me le confirmer ?

Je me rend aussi bien compte qu'un truc ne colle pas avec les tables de date d'application pour la tva par exemple mais aussi pour l'adresse de facturation.
Je pense les fondre dans la table concernée (ADRESSE_FACTURE / TVA) mais je voulais que l'id_date fasse office de clef primaire, est ce nécessaire?
Comment procéderiez vous sur ce coup là ?

Merci par avance pour votre réponse !

[fsmrel]

Bonsoir Nono,


RG106_RG116 est synonyme de id_date_applic_prix, donc il n’y a pas concaténation de id_type_animal et id_type_forfait ou encore de id_date_applic_prix avec id_tva. C’est bien ça qu’il faut lire :

{RG095, id_type_animal, id_type_forfait, RG108, id_forfait, date_application, prix_forfait, id_date_applic_prix, id_tva}

Pour vous en persuader, il vous suffit de générer un MLD à partir de la vue RELATIONS/Forfaits, puis le script SQL à partir de ce MLD.

De mon côté, voilà ce que cela donne :

create table FORFAIT (
     RG095 int not null,
     RG100_RG097 int not null,
     RG100_id_type_forfait int not null,
     RG108 int not null,
     id_forfait int not null,
     date_application date not null,
     prix_forfait int not null,
     RG106_id_date_applic_prix int not null,
     RG106_id_tva int not null,
     constraint ID_FORFAIT_ID primary key (RG095, RG100_RG097, RG100_id_type_forfait, RG108, id_forfait)); 

En clair :

create table FORFAIT (
     id_taille_animal int not null,
     id_type_animal int not null,
     id_type_forfait int not null,
     id_longueur_poil int not null,
     id_forfait int not null,
     date_application date not null,
     prix_forfait int not null,
     id_date_applic_prix int not null,
     id_tva int not null,
     constraint ID_FORFAIT_ID primary key (id_taille_animal, id_type_animal, id_type_forfait, id_longueur_poil, id_forfait));

Je me rend aussi bien compte qu'un truc ne colle pas avec les tables de date d'application pour la tva par exemple mais aussi pour l'adresse de facturation.

Je suis trop à la ramasse... Je regarderai dès que j’aurai la tête moins encombrée...


En attendant, bonne dimanchade !

[fsmrel]

Bonsoir Nono,


Tout ce qui suit n’est qu’une proposition de scénario, vous me direz ce que vous en pensez...


A propos de l’adresse de facturation


Je propose que l’on distingue bien ce qui sert de référence, à savoir les adresses utilisables pour créer les factures, de ce qui est gravé dans le marbre, à savoir les adresses qui figurent sur les factures expédiées.

Si votre utilisatrice unique et préférée souhaite créer une facture pour Mme Hilary, vous lui affichez le contenu de la table ADRESSE FACTURE concernant cette cliente et elle fait son choix. Une fois la facture « validée » l’adresse qui y figure ne doit plus être modifiée, mais vous avez précisé que votre utilisatrice avait tendance à toucher un peu à tout, donc, pourquoi pas n’irait-elle pas modifier le contenu de la table ADRESSE FACTURE ?

Pour assurer le coup, tout en laissant l’utilisatrice bricoler les adresses, on pourrait reprendre votre scénario initial : loger dans la facture l’adresse utilisée pour celle-ci, et en contrepartie, pour ne pas avoir de redondance, rompre le lien entre les tables FACTURE et ADRESSE_FACTURE :





Remarques :


Entité-type FACTURE

— L’attribut ligne1_adresse correspond à la ligne 1 de l’adresse, c'est-à-dire au titre de civilité, au nom et au prénom du destinataire de la facture ;

— L’attribut ligne2_adresse correspond la ligne 2 de l’adresse, c'est-à-dire à la voie et au numéro dans la voie ;

— Etc.

Entité-type ADRESSE_FACTURE

On retrouve les mêmes ingrédients, mais disons que si votre utilisatrice y touche, ça n’a pas de conséquence sur les factures étant entendu qu’elle n’aura pas le moyen de toucher à ces dernières une fois enregistrées.

J’ai fait figurer la période durant laquelle un client a résidé à une adresse (le recouvrement des périodes est à rendre possible ou non : à vous d’en décider avec le maître d’ouvrage, à savoir Mme Nono...) A moins qu’ACCESS propose nativement le type PERIODE, une période est définie au moyen d’une date de début et d’une date de fin. On pourrait se passer de la date de fin, mais cela complique les recherches ayant trait au dates. Si une période n’est pas achevée, la date de fin peut être le 31/12/9999. Cette date particulière peut permettre de déterminer l’adresse actuelle, sauf si vous souhaitez prendre en compte les adresses futures, auquel cas, pour récupérer l’adresse actuelle, il faudra effectuer des comparaisons de dates. Il faudra aussi veiller à ce que la date de début d’une période (autre que la 1re) soit égale à la date de fin de la période précédente + 1 jour (avec ACCESS ça serait au moyen d’une procédure VBA plutôt que d’un trigger).


N.B. Je n’ai pas regardé le sous-univers VILLES, mais bon...



A propos de la TVA :


On pourrait tenir un raisonnement analogue pour tout ce qui fait partie de la facture. Ainsi, on romprait le lien entre VENTE et TVA, en logeant dans VENTE le taux (en dur) utilisé. Le montant hors taxe et la TVA figureraient systématiquement dans les entités-types concernées, à savoir en plus de VENTE : PRESTATION et PRESTA_SUPPLEMENT (remplaçant l’association entre PRESTATION et SUPPLEMENT).





En revanche, des entités-types comme SUPPLEMENT ou FORFAIT restent en l’état. Si la valeur du taux de TVA qu’elles référencent change, c’est cette nouvelle valeur qui désormais leur est applicable.