Discussion :

[Heledir]

Bonjour fsmrl,

Raison de plus pour nous présenter ce MLD (qui n’est heureusement pas encore un MPD).

Dont acte, voici le MLD! Ne pas confondre avec : don't act ! N'est-il pas ?
Au passage, je constate que je mélange un peu MLD/MPD.

car il y a plusieurs scénarios de génération à proposer à l’AGL.

C'est amusant, je comprends tous les mots un par un, mais la phrase ne m'évoque rien. En effet, que vient faire l'acide gamma-linoléique (de la famille des oméga6) dans notre propos ? Et surtout, que vont bien pouvoir faire les oméga-6 des ces différents scénarios ? Je ne doute pas que la suite apporte tous les éclaircissements nécessaires à mon esprit par trop fatigué !

G.H. Hardy

Je suis toujours touché de sentir que la science peut rejoindre l’absolu, cela a quelque chose d’encourageant pour l’avenir.

Encore une fois, merci beaucoup.

[fsmrel]

Bonjour,

Arrivé à ce point, le modèle physique de données me semble : disons, humm, surprenant pour un oeil neuf !

Votre surprise en découvrant le MLD proposé par l’AGL n’a certainement d’égale que la stupeur de ces jeunes recrues de la Marine, qui aperçurent pour la première fois la Méditerranée, voyez à ce sujet le fameux monochrome d’Alphonse Allais dont voici une copie à peu près fidèle :

Bref. Avoir fait tout ce chemin pour en arriver à retrouver les attributs de la Personne recopiées dans toutes les tables dérivées des entités-types spécialisées...

De mon côté, voici ce que j’obtiens avec Power AMC (V11) (au fait, utiliseriez-vous PowerDesigner ?) :

On constate qu’il n’y a pas de redondance.

Mais pour cela, au niveau MCD, j’ai pris mes précautions, en cliquant sur la flèche visant PERSONNE, pour faire apparaître la fenêtre « Propriétés de l’héritage » et en cochant le bouton « N’hériter que des attributs primaires » :



Vous noterez que les choix proposés au sein de la fenêtre peuvent donner lieu à plusieurs scénarios, sans rapport direct avec les oméga-6...


Remarques.

1) L'attribut PsnId de votre table ENTREPRISE est accompagné du mickey "<pi>", mais je ne vois pas de mickey "<fi>" (à comparer avec le MLD que j'ai obtenu).

2) Votre table COMPOSER n’a pas de clé primaire. Ceci est une erreur, et l’AGL a dû le vous signaler (si vous lui avez demandé de vérifier le MLD).

[Heledir]

Bonsoir fsmrel,

au fait, utiliseriez-vous PowerDesigner ?

J'utilise PowerAMC (V15 en français). J'ai cherché toute la journée, mais impossible d'obtenir la même version de MLD que vous. Je soupçonne qu’en V15 PowerAMC génère un véritable MLD et non pas un intermédiaire :

un outil comme Power AMC sait produire un MLD (qu’il incorpore au MPD et mélange donc les niveaux, celui de la logique formelle et du fer à souder, mais on fera avec).

En v15, il existe plusieurs choix dont entre autre,
Onglet Outils, commande "Générer un modèle physique de données".
Onglet Outils, commande "Générer un Modèle Logique de données".

Mais pour cela, au niveau MCD, j’ai pris mes précautions,

C’est vrai, on ne le répètera jamais assez, sortez couvert ! De plus, ainsi on augmente ses chances de ne pas avoir de problème d'héritage. J'ai donc appliqué le même paramétrage et d'un seul coup, le MLD devient tout de suite plus conforme aux résultats attendus.

Concernant l’AGL, je suis bien content de ne pas être obligé de poster sur un forum de diététique pour améliorer mes connaissances très approximatives car j’ai déjà fort à faire avec notre sujet.

L'attribut PsnId de votre table ENTREPRISE est accompagné du mickey "<pi>", mais je ne vois pas de mickey "<fi>" (à comparer avec le MLD que j'ai obtenu).

Le f "<fi>" me semble correspondre à foreign. Quand je génère le MLD, avec le bon scénario, le résultat ne change pas. Sur votre MLD, j'ai l'impression qu'il n'y a qu'un mickey "<pk>" (primary ?) pour PsnID dans la table ENTREPRISE. Ou alors je ne sais pas lire le MLD ce qui me semble plus vraisemblable.

Par contre, la deuxième remarque : en faisant une clé primaire avec les deux clés étrangères de la table COMPOSER, je pense corriger l’erreur. C’est fort de constater qu’effectivement c’est une erreur et que PowerAMC ne fait que la signaler.

Encore une dure journée consacrée à l'apprentissage du MLD. Merci de votre aide.

[fsmrel]

Bonsoir Heledir,


Votre MLD a cette fois-ci fière allure.

En v15, il existe plusieurs choix dont entre autre,
Onglet Outils, commande "Générer un modèle physique de données".
Onglet Outils, commande "Générer un Modèle Logique de données".

Tout s’explique. Avec la V11 de Power AMC, on ne peut que passer du MCD au MPD. En fouillant dans la Toile, je viens de tomber sur un article de fadace (qui fait partie au demeurant de mes amis chez Developpez.com). Or, dans cet article qui a pour titre « Sybase PowerAMC 15 : entretien avec l'éditeur », il est précisé que l'on peut désormais passer du MCD au MLD avant d’en arriver au MPD. Ça me rappelle une histoire que j’ai vécue en 1995 : une banque française avait acquis l’AGL Silverrun (canadien à l’époque si ma mémoire est bonne), mais avait mis une condition préalable : que soit disponible la version Merise, avec ses ronds et ses carrés. L’éditeur l’a fait, mais en prenant les Français pour des frapadingues, car pour lui la conception commençait à peu de choses près au niveau du MLD que vous m’avez proposé...

Au fond, Power AMC étant français à l’origine (sous le nom d'AMC Designor), avec ses carrés, ses ronds, et son béret, il y a une sorte d’harmonisation pour que l’on puisse là aussi (du moins je je suppose) commencer à modéliser au stade du MLD. Curieusement, le style graphique du MLD est exactement celui que j’utilise pour nombre de mes MCD (Outils \ Options du modèle \Notation Entité/Relation), à ceci près que les attributs utilisés pour les identifiants ne sont pas dupliqués (il y a là cohérence avec Merise).

J'ai cherché toute la journée, mais impossible d'obtenir la même version de MLD que vous.

Il est bien possible que vous l’obteniez en dérivant le MLD en MPD. Si vous pouviez effectuer l’opération, afin qu’on y voie plus clair...
On risque de retrouver « mes » <pk> et <fk> (abréviations de « primary key » et de « foreign key »). Pour mémoire, les concepts de clé primaire (primary key, pk), clé alternative (alternate key, ak) et clé étrangère (foreign key, fk) ont été inventés par Ted Codd, père de la théorie relationnelle, laquelle adhère à la théorie des ensembles et à la logique du premier ordre, aussi je la trouve saumâtre que l’AGL ne les utilise qu'au niveau du MPD (fer à souder, quincaillerie et compagnie).

Par contre, la deuxième remarque : en faisant une clé primaire avec les deux clés étrangères de la table COMPOSER, je pense corriger l’erreur. C’est fort de constater qu’effectivement c’est une erreur et que PowerAMC ne fait que la signaler.

De manière générale, l’AGL signale les erreurs (croix blanche sur fond rouge) et les warnings. Apparemment, qu’une entité-type du MCD n’ait pas d’identifiant ne provoque qu’un warning. Mais il est fort curieux que dans la 1re version de votre MLD, l’AGL ait oublié d’identifier COMPOSER : cela ressemble à un bug à porter à l’attention de l’éditeur (essuieriez-vous les plâtres ?) En tout cas, si c’est vous qui avez ajouté manuellement la clé primaire, vous avez eu le bon réflexe.

En conséquence de quoi j’attends votre MPD (en espérant que l'AGL ne va pas le rendre obèse à son tour...)

Courage !

[Heledir]

Bonsoir fsmrel,

En conséquence de quoi j’attends votre MPD (en espérant que l'AGL ne va pas le rendre obèse à son tour...)

Voici le MPD issu directement du MLD (MCDSiege20090716_1.pdf). J’ai le sentiment que le résultat est conforme aux attentes.

Quand on passe du MCD au MLD, il n’y a pas de mickey "<pi>" de généré dans le MLD, mais seulement un warning. Par contre si l’on génère un MPD à partir du MCD, les mickey "<pk>" sont bien générés.

En tout cas, si c’est vous qui avez ajouté manuellement la clé primaire, vous avez eu le bon réflexe.

J’ai eu le bon réflexe, parce que vous aviez attiré mon attention sur ce point.

en espérant que l'AGL ne va pas le rendre obèse à son tour...

Effectivement, je suis bien content de constater que de prendre ses précautions abouti au résultat souhaité.

Merci pour votre gentillesse, votre humour et votre disponibilité. C’est un véritable plaisir de suivre vos conseils et d’apprendre avec vous.

[fsmrel]

Bonsoir Heledir,


Le MLD — car c’est bien un MLD, même s’il a été généré au stade MPD — mérite vingt sur vingt, et en cotant vache (pour citer Jean in Les tontons flingueurs).

Maintenant certains points restent à voir, on n’en pas fini avec ce sympathique MLD.

Le Modèle Relationnel de Données est allergique au Bonhomme NULL. Merci donc de vérifier que dans le MCD tous les attributs sont rendus obligatoires (case « O » cochée) et par voie de conséquence tous les attributs dans le MLD.

Revenons aux oméga-6 qui vous sont chers, ou parlons de physiologie (ou du métabolisme des données, peu importe...) En effet, nous n’avons vu jusqu’ici que le côté anatomique des choses.

Supposons que l’on veuille supprimer le produit "p1". A l’occasion de cette tentative, "p1" envoie des signaux, des stimuli dans toutes les directions. Sont touchées la famille dont provient "p1" ainsi que les lignes de commande composant les commandes concernées. En théorie, il faudra qu’une assertion SQL (une contrainte créée au moyen de l’instruction CREATE ASSERTION) garantisse que la famille touchée reste associée à au moins un produit. Si le SGBD n’offre pas l’instruction idoine, alors il faudra en passer par un trigger. Qu’en est-il des lignes de commande ? Pas besoin de programmer une assertion ou un trigger, on peut accepter que la mort d’un produit entraîne celle des lignes de commande qui y font référence, ou de préférence, faire en sorte que cette mort ne soit acceptée que si aucune ligne de commande ne fasse référence à ce produit, sinon, si la moindre ligne de commande fait référence à "p1", alors la mort de ce produit doit être refusée (ce qui est de loin préférable ! sinon imaginez le souk dans la gestion des commandes...)

Pour signifier les règles de comportement, on agit au niveau du MLD, c'est-à-dire du MPD avec la V11 de Power AMC (merci de me dire si on peut le faire au niveau du MLD avec la V15), et on procède ainsi :

— Clic droit sur la flèche qui connecte les tables PRODUIT et COMPOSER ;

— Clic sur « Intégrité référentielle ». Apparaît la fenêtre « Propriété de la référence » :

J’ai choisi le bouton « Restrict » quant à la contrainte de suppression : le SGBD interdira par la suite la suppression d’un produit pour lequel existe au moins une ligne de commande. Si par malheur j’avais autorisé la suppression des lignes de commande en relation avec ce produit, j’aurai retenu l’option « Cascade ».

Vous noterez la présence dans la fenêtre d’une rubrique « Contrainte de modification » : on la laissera en permanence à Restrict, car si l’on choisit Cascade, cela veut dire que l’on autorise le remplacement des valeurs de la clé primaire (ici de la table PRODUIT) avec propagation dans les tables référençantes. Or souvenez-vous que nous avons choisi de n’utiliser que des clés primaires invariantes.

Si l’on s’intéresse aux liens qui unissent COMMANDE et COMPOSER, vous conviendrez que cette-fois-ci, on choisit l’option Cascade, puisque des lignes de commande constituent une propriété multivaluée d’une commande et n’ont pas le pouvoir de s’opposer à la mort de celle-ci.

A titre d’exercice et pour vous faire transpirer un peu, je vous demanderai donc de définir et justifier les règles de comportement (Restrict/Cascade), table par table.

Pour en revenir au MCD — qui ne peut qu’évoluer harmonieusement... :

Certaines entités-types sont peut-être à ajouter. Par exemple, une entité-type NAF. En effet, cela peut rendre service à l’utilisateur s’il dispose du libellé correspondant au code.

Il faudrait recenser — si elles existent — les données qui varient dans le temps et pour lesquelles il faut conserver une trace. Par exemple, considérons à nouveau le code NAF : un changement du code NAF d’une entreprise se traduit-il par un simple « annule et remplace », ou bien conserve-t-on un historique ? Si des données sont à historiser, il faudra que je vous transmette des consignes à cet effet, pour vous éviter des cauchemars lors du développement des requêtes de consultation de la base de données.

Quand on passe du MCD au MLD, il n’y a pas de mickey "<pi>" de généré dans le MLD, mais seulement un warning. Par contre si l’on génère un MPD à partir du MCD, les mickey "<pk>" sont bien générés.

Il serait intéressant de voir ce que donne le passage du MLD « bogué » au MPD, et si la table COMPOSER a bien tout ce qu'il faut en termes de clés.


N.B. Auriez-vous produit le PDF il y a un an ? (il a pour nom MCD-MPD_20080729_1.pdf). Bon... je dois redevenir sérieux.

[Heledir]

Bonjour fsmrel,

Merci donc de vérifier que dans le MCD tous les attributs sont rendus obligatoires (case " O " cochée) et par voie de conséquence tous les attributs dans le MLD

C'est fait.

merci de me dire si on peut le faire au niveau du MLD avec la V15

On peut le faire dans le MLD (si j'ai bien compris, celui qui est en fait le MPD issu du MCD en v15).

A titre d’exercice et pour vous faire transpirer un peu, je vous demanderai donc de définir et justifier les règles de comportement (Restrict/Cascade), table par table.

ENTREPRISE PERSONNE : Restrict -> interdit la suppression d’une personne si elle est une " entreprise "
CONTACT ENTREPRISE : Restrict -> interdit la suppression d’une entreprise pour laquelle il existe un contact
ENTREPRISE TOURNEE : Restrict -> interdit la suppression d’une tournée pour laquelle il existe une entreprise
ENTREPRISE COMMERCIAL : Restrict -> interdit la suppression d’un commercial pour lequel il existe une entreprise
COMMANDE ENTREPRISE : Restrict -> interdit la suppression d’une ENTREPRISE pour laquelle il existe une commande
SUCCURSALE ENTREPRISE : Restrict -> interdit la suppression d’une ENTREPRISE pour laquelle il existe une succursale
SIEGE ENTREPRISE : Restrict -> interdit la suppression d’une ENTREPRISE pour laquelle il existe un siège
INDIVIDU PERSONNE : Restrict -> interdit la suppression d’une personne s’il est un individu
CONTACT INDIVIDU : Restrict -> interdit la suppression d’un individu s’il est un contact
LIVREUR INDIVIDU : Restrict -> interdit la suppression d’un individu s’il est un livreur
COMMERCIAL INDIVIDU : Restrict -> interdit la suppression d’un individu s’il est un commercial
TOURNEE LIVREUR : Restrict -> interdit la suppression d’un livreur affecté à une tournée
SUCCURSALE SIEGE : Restrict -> interdit la suppression d’une succursale pour laquelle il existe un siège
COMMERCIAL SECTEUR : Restrict -> interdit la suppression d’un secteur pour lequel il existe un commercial
COMMANDE COMMERCIAL : Restrict -> interdit la suppression d’un commercial pour lequel il existe une commande
COMMANDE STATUT : Restrict -> interdit la suppression d’un statut affecté à une commande
COMPOSER COMMANDE : cascade -> la suppression d’une commande est possible même s’il existe des lignes de commande
COMPOSER PRODUIT : Restrict -> interdit la suppression d’un produit pour lequel il existe une ligne de commande
PRODUIT FAMILLE : Restrict -> interdit la suppression d’une famille pour laquelle il existe un produit


Pourquoi la mise en œuvre (onglet " Intégrité référentielle " / fenêtre " Propriété de la référence " sur trigger par défaut) lorsqu’elle est passée sur déclarative :

si on ferme et que l'on ouvre la fenêtre de nouveau, la mise en œuvre se retrouve sur trigger ?

Certaines entités-types sont peut-être à ajouter.

Je comprends l’intérêt de la démarche mais dans notre cas, la demande reste au niveau du circuit commande-préparation-livraison. L’objectif est de produire des bons (de préparation et de livraison) résultant des commandes. Mais je garde le principe en mémoire, d'autant que j'ai cru comprendre que la gestion des " code postal/ville " devrait être gérée autrement afin d'éviter les doublons à la saisie.

Si des données sont à historiser,

Les seules données qui peuvent varier dans le temps et pour lesquelles il faudrait conserver une trace sont les tarifs des commandes et je m’étais imaginé avoir fait le nécessaire. Votre demande concernant les données à historiser m'amène à penser le contraire. Comme quoi : ce n’est pas parce que l’on croit qu’on a raison, qu’on a raison ! Surtout si on a tord !

il a pour nom MCD-MPD_20080729_1.pdf

Comme disait Muriel : " A mon avis, y a UNE BOULETTE !!! ". Je ne suis pas sur, mais il me semble qu'elle disait cela à frère TUCK. Mais ma mémoire me joue parfois des tours. Donc, voici le MPD issu du MLD lui-même issu du MCD en V15. Et cette fois, ce n'est pas de l'occasion !

Encore une bonne journée de travail qui ne s'achève pas, enfin pas tout de suite. mais comme le disait un professeur : Hardy-Petit !

Merci beaucoup.

[fsmrel]

Bonsoir Heledir,

merci de me dire si on peut le faire au niveau du MLD avec la V15

On peut le faire dans le MLD (si j'ai bien compris, celui qui est en fait le MPD issu du MCD en v15).

Je veux dire au niveau du MLD propre à la V15 (celui qui a les <pi> et <fi>), avant d’en arriver au MPD.

Pourquoi la mise en œuvre (onglet " Intégrité référentielle " / fenêtre " Propriété de la référence " sur trigger par défaut) lorsqu’elle est passée sur déclarative :
si on ferme et que l'on ouvre la fenêtre de nouveau, la mise en œuvre se retrouve sur trigger ?

Je n’ai pas ce problème. A mon avis, l’AGL doit être facétieux et vous a repéré...

Essayez : « Outils \ Options du modèle \ Paramètres du modèle \ Référence \Mise en œuvre par défaut » :

j'ai cru comprendre que la gestion des " code postal/ville " devrait être gérée autrement afin d'éviter les doublons à la saisie.

Qu’entendez-vous par « doublons à la saisie » ? Est-ce le fait que si l’on connaît le code postal on connaît la localité ? On peut montrer le contraire. Il suffit d’aller chez La Poste et de proposer par exemple le code postal 91190 : vous aurez trois localités...

Si ma réponse n’est pas celle que vous attendiez, merci de préciser la question que vous vous posez.

Les seules données qui peuvent varier dans le temps et pour lesquelles il faudrait conserver une trace sont les tarifs des commandes

Souhaitez-vous gérer un historique des tarifs des produits ?

mais comme le disait un professeur : Hardy-Petit !

Le papa de Carole ?


Du métabolisme des données.

Mettez votre casque. Souvenez-vous de la situation avant mise en œuvre de l’héritage. L’entreprise (en fait la succursale) était ainsi modélisée :





Si l'on supprime une entreprise, selon ce schéma c'est en une fois. En ayant programmé un RESTRICT entre ENTREPRISE et PERSONNE, vous vous imposez de commencer par supprimer d’abord la partie de la personne qui fait l’objet d’une instance (ou occurrence ou ligne ou n-uplet ou tuple...) ENTREPRISE avant de pouvoir supprimer la partie de cette personne qui fait l’objet d’une instance PERSONNE. Qui plus est, il faudra commencer par supprimer la partie de la personne qui fait l’objet d’une instance SUCCURSALE (idem pour SIEGE).

En réalité, il y a un distinguo essentiel à faire entre AVOIR et ÊTRE. Ainsi, une famille de produits est composée de produits, une famille a des produits. Mais une entreprise est une personne. De même, un siège est une entreprise, donc une personne, même principe pour une succursale. Si donc on supprime une personne, on la supprime en une fois, qu’elle ait été spatialement ventilée façon puzzle (à la Raoul Volfoni) ou non, car sémantiquement elle est bien un tout.

Autrement dit, entre PERSONNE et ENTREPRISE c’est CASCADE, même chose entre ENTREPRISE et SIEGE ainsi qu’entre ENTREPRISE et SUCCURSALE. Toutes choses égales, la règle est générale dès qu’intervient la mise en œuvre de l’héritage (et les individus sont évidemment soumis au même régime).

Supposons maintenant que l’on tente de supprimer un siège : sont donc touchées simultanément les 3 tables PERSONNE, ENTREPRISE et SIEGE. Mais par référence aux autres RESTRICT que vous avez proposés, pour que l’opération réussisse, il faut que ce siège n’ait aucune succursale (soit on détruit d’abord les succursales, soit on les rattache à un autre siège), qu’il n’ait aucune commande en cours et qu’il n’ait pas de contact.

Maintenant, vous me direz : tout ça c’est bien beau, mais ça aurait été plus simple si on avait conservé le système initial, avant mise en œuvre de l’héritage. En fait, à partir des tables de base que sont PERSONNE, ENTREPRISE et SIEGE, vous définirez une table virtuelle (ce que l’on appelle le plus souvent une vue) qui permettra de reconstruire virtuellement un siège, et vous l’appellerez par exemple SIEGEV (ou tout autre nom). Cette table est virtuelle dans la mesure où elle ne contient aucune instance, à la différence des tables de base, mais l’utilisateur ne fait aucune différence (on satisfait en l’occurrence à ce qu’on appelle l’indépendance logique). Autrement dit, on peut la manipuler comme une table de base :

Table de base et table virtuelle peuvent être perçues comme des spécialisations d’un concept TABLE plus général.

Le défi : toutes les opérations relationnelles que l’on applique à une table de base telle que CLIENT DESTINATION ou CLIENT PAYEUR doivent pouvoir l’être à la table dérivée SIEGEV.

Peut-être vous ai-je traumatisé, aussi peut-on remettre à la prochaine fois la façon concrète de définir et de manipuler SIEGEV.

Comme aurait pu le dire Maurice Champot, Y en a sous la partie émergée...


N.B. Avez-vous repéré que dans votre dernier MLD (façon V11), la table COMPOSER est dépourvue de clé primaire ? C’est affreux !

[Heledir]

Bonsoir fsmrel,

Je veux dire au niveau du MLD propre à la V15 (celui qui a les <pi> et <fi>), avant d’en arriver au MPD.

Dans ce cas, il n'y a pas d'onglet intégrité au niveau du MLD.

A mon avis, l’AGL doit être facétieux et vous a repéré...

N.B. Avez-vous repéré que dans votre dernier MLD (façon V11), la table COMPOSER est dépourvue de clé primaire ? C’est affreux !

Alors ça! Pas question de se laisser faire, je le passe en v15.1. Du coup les « <pi> » (MLD issu du MCD) et les « <pk> » (MPD issu du MLD) arrivent au bon endroit pour COMPOSER.
Par contre, après vérification des paramètres par défaut, cela ne change rien pour la mise en œuvre de l’intégrité référentielle, elle reste désespérément sur Trigger.

merci de préciser la question que vous vous posez.

Effectivement, il y a un point obscur qui n'est pas clair. En fait, je faisais référence à une discussion avec Tyrosmf

Concernant Ville et Code postal :

En utilisant la solution proposé, on doit pouvoir éviter le fait que :

si on saisi deux fois le même client et qu'une faute d’orthographe est faite dans le champ VILLE, on obtient deux fois le même client.

Car dans ce cas, c'est la base de données qui gère " ville / Code postal ". Mais peut-être que je me complique un peu trop la vie. En effet, si on fait une erreur dans l'adresse, le résultat est le même.

Souhaitez-vous gérer un historique des tarifs des produits ?

Si gérer un historique des tarifs des produits c’est : lorsque je demande l’édition d’une commande j’ai les tarifs en vigueur lors de la commande et pas ceux du jour qui peuvent avoir changés, alors oui ! Mais la table COMPOSER avec ses champs tarif et Qte ne fait-elle pas cela ?

Le papa de Carole ?

Absolument ! Mon père m’a pour ainsi dire initié. Mon beau-père est fan inconditionnel. Bien que je n’ai qu’un vernis, je ne me lasse pas d’y gouter de temps en temps pour le la plus grande joie de mes zygomatiques. Bien entendu, le plaisir de se laisser emporter par les envolés verbales de Raoul, Paul et autres Volfoni ne se rate pas !

Peut-être vous ai-je traumatisé, aussi peut-on remettre à la prochaine fois la façon concrète de définir et de manipuler SIEGEV.

« Ce qui s'énonce clairement ce conçoit bien, et les neurones pour le recevoir répondent aisément » (pauvre Nicolas Boileau qui doit se retourner dans sa tombe). Désolé CinePhil.

Clair et précis, je suis impatient de connaitre la suite.

merci.

[fsmrel]

Bonsoir Heledir,

Si gérer un historique des tarifs des produits c’est : lorsque je demande l’édition d’une commande j’ai les tarifs en vigueur lors de la commande et pas ceux du jour qui peuvent avoir changés, alors oui ! Mais la table COMPOSER avec ses champs tarif et Qte ne fait-elle pas cela ?

On pourrait avoir une image de l’historique des tarifs des produits en se basant sur la date qui figure dans chaque commande et du tarif qui figure dans chaque ligne de commande. Cela dit, les commandes peuvent à un moment donné disparaître de la base de données (quand on « purge » las commandes dont la présence n’est plus jugée utile). Ce que j’entends par historique des tarifs, c’est le suivi de leur évolution au fil du temps, pour eux-mêmes, indépendamment de leur environnement. J’avais fugacement évoqué le sujet :

Vous pouvez commencer à prendre en compte l’aspect temporel. Pour faire court, le principe est le suivant : une donnée peut être dans un certain état depuis une certaine date (c'est-à-dire à ce jour) et a pu être dans d’autres états durant des périodes antérieures connues.

En l’occurrence cela consisterait à dire que depuis telle date le tarif d’un produit coûte aujourd’hui tant (entité-type PRODUIT), alors que par le passé il a été de tant, entre telle et telle dates (entité-type PRODUIT_TARIF_HISTO). Le MCD évolue alors ainsi :




Observations

1) L’entité-type PRODUIT comporte la date de début d’application du tarif, c'est-à-dire la date qui fait foi pour les commandes du jour. En revanche, si l’entité-type PRODUIT_TARIF_HISTO comporte aussi une date de début, elle comporte en plus la date à laquelle le tarif impliqué a cessé d’être valable. Le jour où un nouveau tarif entrera en vigueur, on mettra à jour PRODUIT et PRODUIT_TARIF_HISTO.

2) l’entité-type PRODUIT_TARIF_HISTO ne comporte pas les attributs ProduitNom et ProduitDesc. En effet, s’il faut les historiser, ils feront chacun l’objet d’un historique spécifique.

3) Dans le MCD, la cardinalité 1,1 est entre parenthèses : cela signifie que j’ai utilisé l’identification relative (Power AMC la symbolise au moyen des parenthèses). En effet, on considère que l’historique d’un produit en est une propriété multivaluée, PRODUIT_TARIF_HISTO est une entité-type faible (weak entity). Cela se traduit par le fait que PRODUIT_TARIF_HISTO a pour identifiant celui de PRODUIT, et qu’on lui ajoute un complément d’identifiant pour distinguer chaque instance pour un même produit (attribut ProduitIdRelatif). Pour réaliser cela, avec Power AMC : clic droit sur le lien entre PRODUIT_TARIF_HISTO et PRODUIT_HISTORISER, sélectionner « Propriétés » et dans la fenêtre, cocher la case « Identifiant ».

Je veux dire au niveau du MLD propre à la V15 (celui qui a les <pi> et <fi>), avant d’en arriver au MPD.

Dans ce cas, il n'y a pas d'onglet intégrité au niveau du MLD.

D’accord. On n’en tiendra pas grief à l’AGL, car la théorie relationnelle considère les « actions référentielles » c'est-à-dire Cascade delete, etc. comme relevant du monde des triggers (triggered procedures), sujet sur lequel la théorie est délibérément silencieuse (contrairement à la norme SQL, plutôt volubile et aux SGBD qui tirent dans toutes les directions...)

Par contre, après vérification des paramètres par défaut, cela ne change rien pour la mise en œuvre de l’intégrité référentielle, elle reste désespérément sur Trigger.

Pourtant la fonctionnalité est proposée si l’on fait référence à l’aide en ligne...



Je persiste, l’AGL vous aurait-il repéré ?

c'est la base de données qui gère " ville / Code postal ". Mais peut-être que je me complique un peu trop la vie. En effet, si on fait une erreur dans l'adresse, le résultat est le même.

Sur un autre forum de Developpez.com (message "Liste des villes et codes postaux"), vous trouverez des références à Hexaposte, voire à un fichier des codes postaux (mais sans garantie). Ainsi, vous aurez la possibilité de charger les couples {Code postal / Ville} dans une table dérivée d’une entité-type que vous aurez ajoutée à votre MCD. Avec un bon menu déroulant, plus d’erreurs de saisie...

je suis impatient de connaitre la suite

Vous l’aurez voulu...

Je récapépète donc. Pour mutualiser ce qu’ils ont en commun, on a disloqué les entreprises (sièges et succursales) et les individus (commerciaux, contacts et livreurs). Ceci peut être rendu transparent, dans la mesure où l’on peut produire — au niveau logique — des tables virtuelles (vues), en sorte que l’utilisateur final (programme ou terminaliste) ne voie (et mette à jour) que des sièges, des succursales, des commerciaux, des contacts et des livreurs. Créer ce genre de tables peut se faire à l’aide de l’AGL (Outils \ créer une vue), mais personnellement je me sens plus à l’aise quand je le faire directement avec le SGBD, je continuerai donc de la sorte (le cœur de la base de données est bon, et on demande à AMC de générer le code SQL de création des tables). En l’occurrence, je me servirai de MS SQL Server Express 2005 (MSS). A ce propos, comme vous connaissez ACCESS, vous connaissez SQL, donc à peu de choses près MSS.

Pour créer une vue SIEGEV et retrouver la structure complète d’un siège, on met à profit la jointure naturelle, laquelle est simulée avec MSS à l’aide d’un jointure interne (INNER JOIN) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
CREATE VIEW SIEGEV 
(
   PsnId,
   RaisonSociale,
   Siret,
   Naf,
   VisiteurId,
   TourneeId,
   Adresse1,
   Adresse2,
   Adresse3,
   CodePostal,
   Ville,
   Tel,
   Gsm,
   Fax,
   Courriel
)
As Select 
   x.PsnId,
   x.RaisonSociale,
   x.Siret,
   x.Naf,
   x.PsnId_Visiteur,
   x.TourId,
   y.Adresse1,
   y.Adresse2,
   y.Adresse3,
   y.CodePostal,
   y.Ville,
   y.Tel,
   y.Gsm,
   x.Fax,
   y.Courriel
FROM ENTREPRISE AS x 
        INNER JOIN 
     PERSONNE AS y
            ON x.PsnId = y.PsnId   
        INNER JOIN 
     SIEGE AS z
            ON x.PsnId = z.PsnId   
;

Pour pimenter, je déplace l’attribut fax vers sa position « naturelle ». De même, je change deux trois noms d’attributs (ne vous sentez pas obligé d’en faire autant).

Passons à la manipulation des données.

SELECT

Consulter les données d’un siège est facile, avec un bon vieux SELECT.
L’affaire se corse (chef-lieu Ajaccio) quand il s’agit de mettre à jour.

INSERT

Par exemple, pour créer un siège (ou plus) à l’aide de la vue, on utilisera un trigger de type INSTEAD OF, grâce auquel on va pouvoir dire à MSS : Passe-moi la main si quelqu’un exécute une instruction INSERT ayant pour objet la table (virtuelle) SIEGEV. A la place (instead of), je fournis (dans le bon ordre, intégrité référentielle oblige) trois INSERT, un 1er ayant pour objet la table (de base) PERSONNE, un 2e ayant pour objet la table (de base) ENTREPRISE et un 3e, la table (de base) SIEGE.

Supposons que je soumette l’INSERT suivant :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
INSERT INTO SIEGEV 
 (   PsnId,
     RaisonSociale,
     Siret,
     Naf,
     VisiteurId,
     TourneeId,
     Adresse1,
     Adresse2,
     Adresse3,
     CodePostal,
     Ville,
     Tel,
     Gsm,
     Fax,
     Courriel
 )
 VALUES ('g03', 'Donald', 'siret', '711Z', 'c02', 'tr01', 'DVP', 'In the clouds', 'a3', 'cp ', 'loc ', 'tel ', 'gsm ', 'fax', 'x@y.fr' ) ;

MSS le sous-traitera au trigger que j’aurai défini, lequel ventilera dans les tables pertinentes les données récupérées dans une table de service répondant au nom original de INSERTED et ayant même en-tête (schéma) que SIEGEV :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
CREATE TRIGGER SIEGEV_INSERT ON SIEGEV Instead of Insert AS
 
INSERT INTO PERSONNE
    SELECT    PsnId,
              Adresse1,
              Adresse2,
              Adresse3,
              CodePostal,
              Ville,
              Tel,
              Gsm,
              Courriel
     FROM     INSERTED ;
 
INSERT INTO ENTREPRISE
    SELECT    PsnId
            , RaisonSociale
            , Siret
            , Fax
            , Naf
            , VisiteurId
            , TourneeId
     FROM     INSERTED ;
 
INSERT INTO SIEGE
    SELECT    PsnId
     FROM     INSERTED ;

DELETE

Supposons que je soumette le DELETE suivant :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
DELETE 
    FROM   SIEGEV ;

Il suffit cette fois-ci à MSS d'en passer par le trigger suivant, et d’exploiter la table de service, au nom aussi original que celui de sa petite sœur INSERTED, à savoir DELETED :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CREATE TRIGGER SIEGEV_DELETE ON SIEGEV Instead of Delete AS
 
DELETE  FROM PERSONNE
        WHERE EXISTS 
         (SELECT  *
          FROM    DELETED 
          WHERE   PERSONNE.PsnId = DELETED.PsnId) ;

En effet, comme il y a un CASCADE entre PERSONNE et ENTREPRISE ainsi qu’un autre entre ENTREPRISE et SIEGE, cela suffit pour supprimer les sièges. En revanche, en l’absence de CASCADE, on aurait codé (dans l’ordre inverse des tables, à cause de l’intégrité référentielle) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
CREATE TRIGGER SIEGEV_DELETE ON SIEGEV Instead of Delete AS
 
DELETE  FROM SIEGE
        WHERE EXISTS 
         (SELECT  *
          FROM    DELETED 
          WHERE   SIEGE.PsnId = DELETED.PsnId) ;             
 
DELETE  FROM ENTREPRISE
        WHERE EXISTS 
         (SELECT  *
          FROM    DELETED 
          WHERE   ENTREPRISE.PsnId = DELETED.PsnId) ;             
 
DELETE  FROM PERSONNE
        WHERE EXISTS 
         (SELECT  *
          FROM    DELETED 
          WHERE   PERSONNE.PsnId = DELETED.PsnId) ;

UPDATE

Les choses sont un peu plus fastidieuses, car on doit examiner chaque colonne pour s’assurer si oui ou non elle a été modifiée et répercuter si nécessaire dans la table PERSONNE et/ou la table ENTREPRISE. La table SIEGE n’est pas touchée, car elle n’a qu’un seul attribut, lequel en compose la clé primaire, or au sein du trigger, on programme le rejet de la modification de la clé primaire (au nom du principe d’invariance que nous avons retenu pour cette clé). Il existe un raccourci permettant d’être moins bavard dans le code, mais qui joue sur des combinaisons de bits reflétant l’ordre des attributs dans les en-têtes des tables, mais personnellement je me refuse à des bidouilles avec lesquelles on ne nomme pas les attributs (un en-tête peut évoluer dans sa structure, au fil des ans). Mais les rois du trigger nous fournirons peut-être des indications pour un code meilleur.

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
 
CREATE TRIGGER SIEGEV_UPDATE ON SIEGEV Instead of UPDATE AS
 
IF UPDATE (PsnId) 
     BEGIN
        RAISERROR ('On ne modifie pas les clés primaires !', 16, 1)
        ROLLBACK TRAN
        RETURN
    END
 
IF UPDATE(RaisonSociale) 
or UPDATE(Siret) 
or UPDATE(Naf) 
or UPDATE(Fax) 
or UPDATE(VisiteurId) 
or UPDATE(TourneeId)
   UPDATE ENTREPRISE SET RaisonSociale =  (SELECT DISTINCT RaisonSociale FROM INSERTED)
                      ,  Siret =          (SELECT DISTINCT Siret FROM INSERTED)
                      ,  Naf =            (SELECT DISTINCT Naf FROM INSERTED)
                      ,  Fax =            (SELECT DISTINCT Fax FROM INSERTED)
                      ,  PsnId_Visiteur = (SELECT DISTINCT VisiteurId FROM INSERTED)
                      ,  TourId =        (SELECT DISTINCT TourneeId FROM INSERTED)
 
                                           WHERE EXISTS (SELECT DELETED.RaisonSociale 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = ENTREPRISE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.Siret 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = ENTREPRISE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.Naf 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = ENTREPRISE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.Fax 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = ENTREPRISE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.VisiteurId 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = ENTREPRISE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.TourneeId 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = ENTREPRISE.PsnId)
IF UPDATE(Adresse1) 
or UPDATE(Adresse2) 
or UPDATE(Adresse3) 
or UPDATE(CodePostal) 
or UPDATE(Ville) 
or UPDATE(Tel)
or UPDATE(Gsm)
or UPDATE(Courriel)
   UPDATE PERSONNE   SET Adresse1   =  (SELECT DISTINCT Adresse1 FROM INSERTED)
                      ,  Adresse2   =  (SELECT DISTINCT Adresse2 FROM INSERTED)
                      ,  Adresse3   =  (SELECT DISTINCT Adresse3 FROM INSERTED)
                      ,  CodePostal =  (SELECT DISTINCT CodePostal FROM INSERTED)
                      ,  Ville =       (SELECT DISTINCT Ville FROM INSERTED)
                      ,  Tel =         (SELECT DISTINCT Tel FROM INSERTED)
                      ,  Gsm =         (SELECT DISTINCT Gsm FROM INSERTED)
                      ,  Courriel =    (SELECT DISTINCT Courriel FROM INSERTED)
 
                                           WHERE EXISTS (SELECT DELETED.Adresse1 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = PERSONNE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.Adresse2 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = PERSONNE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.Adresse3 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = PERSONNE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.CodePostal 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = PERSONNE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.Ville 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = PERSONNE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.Tel 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = PERSONNE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.Gsm 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = PERSONNE.PsnId)
 
                                           OR    EXISTS (SELECT DELETED.Courriel 
                                           FROM DELETED 
                                           WHERE DELETED.PsnId = PERSONNE.PsnId);

Retour sur RESTRICT / CASCADE

Si l’on supprime une entreprise (une succursale qui par exemple n’a plus de commandes), cela n’est pas possible tant qu’elle a des contacts. Or ces contacts sont à considérer comme appartenant à l’entreprise, et d’un point de vue ontologique, devraient disparaître avec celle-ci. Actuellement, la contrainte d’intégrité référentielle entre CONTACT et ENTREPRISE est RESTRICT (rebaptisée NO ACTION pour MSS). On pourrait vouloir remplacer RESTRICT par CASCADE, mais ça serait une erreur, car la suppression du contact ne serait pas répercutée dans les tables PERSONNE et INDIVIDU. Pour que les contacts disparaissent complètement, il faut donc aménager le trigger de suppression des sièges (et même chose bien sûr concernant le trigger de suppression des succursales).

Le trigger SIEGEV_DELETE de suppression des sièges devient le suivant, CONTACTV étant la table virtuelle définie pour les contacts (noter la séquence des suppressions) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE TRIGGER SIEGEV_DELETE ON SIEGEV Instead of Delete AS
 
 
DELETE FROM CONTACTV             
        WHERE EXISTS 
         (SELECT  *
          FROM    DELETED 
          WHERE   CONTACTV.PsnIdEntreprise = DELETED.PsnId) 
 
DELETE  FROM PERSONNE
        WHERE EXISTS 
         (SELECT  *
          FROM    DELETED 
          WHERE   PERSONNE.PsnId = DELETED.PsnId) ;

Le trigger de suppression des succursales devra évidemment être aménage de la même façon :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TRIGGER SUCCURSALEV_DELETE ON SUCCURSALEV Instead of Delete AS
 
DELETE FROM CONTACTV             
        WHERE EXISTS 
         (SELECT  *
          FROM    DELETED 
          WHERE   CONTACTV.PsnIdEntreprise = DELETED.PsnId) 
 
DELETE  FROM PERSONNE
        WHERE EXISTS 
         (SELECT  *
          FROM    DELETED 
          WHERE   PERSONNE.PsnId = DELETED.PsnId) ;

pauvre Nicolas Boileau qui doit se retourner dans sa tombe

Tout est relatif et réciproquement comme dirait Pierre Dac, autrement dit, à force de se retourner, Nicolas aura peut-être retrouvé sa position initiale et vous en saura donc (éternellement) reconnaissant.

__________________________

Et n’oubliez pas de fournir le code SQL (CREATE TABLE) généré par Power AMC à partir de l’onglet SGBD :
SGBD \ Générer la base données \

Avec par exemple comme options :






A suivre...

[Heledir]

Bonjour fsmrel,

Ce n'est pas la peur de prendre le pavé dans la figure : tel un CRS en mai 68. Mais, malgré mon envie de continuer l'aventure, je suis obligé de laisser mon apprentissage jusqu’à la semaine prochaine. Alors à bientôt.

Encore une fois merci.

[fsmrel]

Bonjour Heledir,


Surtout, prenez tout votre temps. Entre deux goulées et rasades, il faut bien que vous digériez tout ce dont je vous bombarde inlassablement : nos aïeux seraient horrifiés par les cadences infernales que nous nous imposons bêtement. Et puis votre subconscient travaillant en arrière-plan, vous aurez les idées sans doute plus claires quand vous reprendrez la discussion.


A plus tard donc.