Discussion :

[Miko95]

Ceci est vrai si le soin n'utilise qu'un seul produit, mais il doit bien y avoir des soins qui utilisent plusieurs produits. Dans ce cas la quantité unique ne convient pas.

Je ne comprends pas. Si l'attribut QuantiteUtilise se situe au niveau de l'association Utilise (entre Soin et Produit), alors pour chaque instance de l'association, il y a une valeur pour cet attribut. Autrement dis, pour chaque association d'un Produit a un Soin (possible car multiplicités 0,n), il y a une valeur a l'attribut indiquant la quantité utilisée du Produit pour ce Soin.


De même, j'ai modifié le MCD.

Merci et bonne nuit

[seabs]

Bonjour,

Je ne comprends pas. Si l'attribut QuantiteUtilise se situe au niveau de l'association Utilise (entre Soin et Produit), alors pour chaque instance de l'association, il y a une valeur pour cet attribut. Autrement dis, pour chaque association d'un Produit a un Soin (possible car multiplicités 0,n), il y a une valeur a l'attribut indiquant la quantité utilisée du Produit pour ce Soin.

Autant pour moi, j'ai fait cette réponse sans vérifier l'entité Soin, étant persuadé qu'elle comportait une quantité. Je t'ai fait une réponse imbécile.

Je vais mettre mon MCD en accord avec le tien, afin de faire une révision.

Déjà, il me semble nécessaire de modifier les points suivants

La relation
Soin -- 0,n -- Utilise -- 0,n -- Produit
doit devenir
Soin -- 0,n -- Utilise -- 0,n -- ESProduit
Le calcul du stock de chaque produit se fera par une vue qui fera l'addition des entrées et la soustraction des sorties pour un stock théorique à une date donnée. Le contrôle avec l'inventaire réel permettra de faire l'ajustement des écarts.

Supprimer également l'attribut QuantStockProd de l'entité Produit

Corrélativement, la relation
Produit -- 0,n -- Vendu -- 0,n Facture
devient
ESProduit -- 0,n -- Vendu -- 0,n Facture

Après cela, nous devrions approcher du but, sous réserve de la vérification.

A+

[Miko95]

Bonjour,

La relation
Soin -- 0,n -- Utilise -- 0,n -- Produit
doit devenir
Soin -- 0,n -- Utilise -- 0,n -- ESProduit
Le calcul du stock de chaque produit se fera par une vue qui fera l'addition des entrées et la soustraction des sorties pour un stock théorique à une date donnée. Le contrôle avec l'inventaire réel permettra de faire l'ajustement des écarts.

On aura donc une instance de UtiliseProduit pour chaque réalisation de soin?
Mais dans ce cas, ou est ce que la quantité de produit utilisée en général est stockée?


Sinon le reste c'est modifie.

[Miko95]

A part ça, j'ai créé un nouveau package avec un autre MCD pour la gestion des jours de travail.
Voici les règles de gestion:
L'utilisateur peut choisir des paramètres généraux qui définissent les horaires de travail générales. Par exemple, tous les Mercredi travail de 9h a 12h puis de 14h a 18h. C'est le rôle de l’entité JourTravailNormal.
Aussi, l'utilisateur peut modifier les horaires de travail pour certains jours. Par exemple, ce Mercredi 6 Avril, les horaires de travail serait de 9h a 12h puis de 16h a 19h. C'est le rôle de l’entité JourTravailModifie.
Pour chaque jour (normal ou modifie), le choix des horaires de travail se fait par la création de plages horaires (entité PlageHoraireTravail).
A part ça, il y a une autre entité qui représente les jours de congés.

Je n'ai pas relie ce modèle a l’entité RendezVous car je ne vois pas en quoi c'est nécessaire.

J'ai mis a jour les MCD en les décomposant en packages, j’espère que ce sera plus simple a regarder.

Merci

[seabs]

Bonjour,

Je ne t'oublies pas, mais actuellement, j'ai très peu de temps disponible. Ton MCD est sur mon bureau. Je regarde dès que possible.

Au premier regard, il me semble que des relations sont à modifier. De plus, il y a des entités fortes et des entités faibles d'où la nécessité de faire quelques modifications avec PowerAmc.

Il serait bien de compléter tes règles de gestion ce qui te permettrait de vérifier ton MCD.

Exemple :

R1 - Un fournisseur peut fournir un ou plusieurs produire.
R2 - Un produit peut être acquis chez ou plusieurs fournisseurs.

Si chaque produit provient d'un seul fournisseurs, il faut changer la relation qui devient :
Fournisseur -- 0,1 -- VenduPar -- 1,1 -- Produit
Sinon, la cardinalité :
Fournisseur -- 0,1 -- VenduPar -- 1,n -- Produit
est exact.

Etc

A plus

[Miko95]

Bonsoir,

Dans ce cas merci, j'attends les conseils.
Sinon de mon cote, je vais me documenter pour les entités faibles et fortes.

Pour les règles de gestion au niveau Produit-Fournisseur:
R1 - Un fournisseur peut fournir un ou plusieurs produits (aucun produit aussi, ça permet d'enregistrer des fournisseurs en tant que contact ou historique).
R2 - Un produit peut être acquis chez au moins un fournisseur.
Dans ce cas, il me semble que les cardinalites sont correctes, je me trompe?

A bientot

[seabs]

Bonjour,

Pour les fournisseurs, c'est correct. Il s'agissait d'un exemple.

Tu as maintenant un MCD assez complet, même si je pense qu'il y aura des modifications à réaliser.

Tu peux passer au MLD qui te permettra de trouver des anomalies. Il conviendra de corriger dans le MCD. Tu sais, il faut souvent faire plusieurs aller retour avant d'obtenir un MCD satisfaisant.

Puis tu passeras au MPD qui va te permettre d'implémenter la quincaillerie dans ta base de données.

A partir de cette base, tu peux faire des essais afin te d'assurer que l'ensemble répond à ta demande et s'il n'existe pas des anomalies de conception. Si oui, retour au MCD pour faire les corrections.

Le métier de débutant s'étend de la naissance à la fin de vie, alors il faut tester, réaliser, comparer pour arriver à une approche de qualification. En dehors des personnages hors normes (Comme faire le 100 m en moins de 10 secondes, ou être agrégé de mathématiques à 21 ans), pour les autres, il faut besogner. Je suis de ceux-là.

Bon courage

A+

[Miko95]

Bonjour,

J'ai vu qu'on peut générer le MLD a partir du MCD avec PowerAMC.
Mais je ne vois pas en quoi avec le MLD, je pourrais tester si la conception est bonne? Au final, c'est juste une représentation du MCD dans le monde relationnel, en quoi cette représentation permet mieux de vérifier la conception, qu'avec la représentation conceptuelle?

Merci

[fsmrel]

Bonjour à vous deux,


Permettez-moi de m’immiscer...


Je n’ai pas lu tous les messages que vous avez échangés (loin s’en faut, vu leur grand nombre), mais je pense qu’il est temps de passer à l’urbanisation de l’univers du discours (l’institut de soins de beauté) et de présenter de façon structurée l’ensemble des règles de gestion disséminées au gré des discussions.


J’ai essayé d’interpréter le dernier MCD global de Miko95 :

http://www.fsmwarden.com/developpez_...ko_MCD_V04.png

L’entité-type ESProduit me paraît un peu tarabiscotée. Au vu des cardinalités 0,1 dont elle fait l’objet, je suppose qu’elle sert soit pour les lignes de facture de type vente de produit, soit pour les quantités des produits utilisés pour les soins. S’il en est ainsi, il serait à mon avis préférable de dégager cette entité-type, devenue forte par construction alors que sémantiquement elle est faible. Vous me direz que je repasse par la case départ et que la représentation qui suit soulève des problèmes, mais justement, j’aimerais savoir quels sont-ils, d’où la remise à plat objet de discussions :

[Facture]--0,N--()--1,1--[LigneFactureProduit(quantité)]--1,1--()--0,N--[Produit]

[Facture]--0,N--()--1,1--[LigneFactureSoin]--1,1--()--0,N--[Soin]--0,N--(Utiliser(quantité))--0,N--[Produit]

Vous me direz que cette représentation ne prend pas en compte les entrées/sorties en relation avec les stocks, mais si l’on urbanise, cet aspect des choses est à considérer dans un sous-modèle dédié à la tenue des stocks, dans lequel on raccrochera les wagons.


A propos des montants TTC

A tout le moins, la date d’application d’un taux de TVA doit être prise en compte. A défaut, toutes les factures concernées par un taux qui change verront leur montant TTC évoluer en conséquence, y-compris celles déjà en possession des clients. De même, que se passe-t-il quand le montant HT d’un produit change ? Quelles sont les incidences de tout cela sur le système de facturation, donc sur la comptabilité de l’entreprise ?

Il est prudent de prévoir l’historisation des données (prix HT des produits, taux TVA) servant à calculer les prix TTC. Dans la série ceinture, bretelles et épingle à nourrice, on peut par ailleurs prévoir de faire aussi figurer le prix HT et la TVA au niveau des lignes de facture, afin d'être sûr de ce que l’on a effectivement facturé au client. Cela introduit une redondance a priori parce qu’au moment de la fabrication d'une facture, ces éléments sont la copie de ce qu’on trouve dans les entités-types PRODUIT et TAUX_TVA, mais la validité a un prix.


Retour sur l’urbanisation

comment partitionner l'affichage du MCD sous PowerAMC car la il commence a devenir volumineux, encore un peu on verra plus rien dans les images.

Il faut utiliser les packages.

Comme je l’ai dit, avant toute chose, le MCD de Miko95 mérite d’être urbanisé. En effet, si ça continue, une poule n’y retrouvera pas ses poussins. Je ne dis pas que ce MCD est illisible, contrairement à celui que je sers à l’occasion pour l’édification des foules (et j’ai connu vingt fois pire...), qui tient plutôt de l'art contemporain new-yorkais :




Par exemple, il est d’usage de ne pas mélanger ce qui concerne les clients d'une part et les fournisseurs d'autre part : quand on s’intéresse aux soins de nos chers clients, passez-moi l’expression, on se contref... pas mal de la tenue des stocks, de la gestion des en-cours ou de la gestion du personnel, bref on se concentre sur les ventes, ce qui fait rentrer les sous, sans être distrait par le reste, et de la même façon, quand on s’occupe des achats, on se f... éperdument des abonnements des clients, on cherche surtout à acheter dans les meilleures conditions.

Ainsi, pour constituer un référentiel Clients (ou Ventes, comme vous préférez), en partant du MCD global suivant (ici volontairement simplifié par rapport au vôtre) :




On se cantonne alors à la vue suivante pour ne pas être distrait par la partie tenue des stocks :





Vous êtes parti sur l’utilisation de packages. Accessoirement, je vous propose une technique alternative, basée sur l’utilisation de vues, libre à vous d'utiliser ce qui vous convient le mieux.

Il y a vingt ans, quand l’outil s’appelait AMC*Designor (marque déposée de la société SDP, basée à Suresnes, c’était le bon temps, on se rendait chez eux en vingt minutes...), les packages n’existaient pas et l’on urbanisait les MCD de façon très simple, selon la méthode des vues, que pour ma part je continue à utiliser (c’est dans les vieilles marmites...)

A tout hasard, je vous montre cette méthode. Comme j’utilise la version 11 de Power AMC, il peut y avoir de légères différences avec la version que vous utilisez.

Définir un nouveau diagramme :




Appelons-le CLIENTS :





L’outil présente un diagramme CLIENTS vide. Il suffit de sélectionner les entités-types qui vont le constituer. Pour cela faire :

Menu > Symbole > Afficher les symboles :




Cocher les entités-types concernées :




Même chose pour les associations-types :




Et le tour est joué. Désormais, vous pouvez jouer avec le MCD global ou la nouvelle vue représentée par le diagramme CLIENTS.

Par ailleurs, vous pouvez définir de nouvelles entités-types et associations-types pour cette vue. Pour les voir apparaître dans le MCD global, il suffit de passer par la procédure d’affichage des symboles.


Divers

Aussi, selon les multiplicités, une facture peut ne contenir aucun soins réalisés, aucun produits vendus et aucune souscriptions d'abonnements. Est ce qu'il faut y remédier au niveau MCD ou au niveau de l'application plutôt?

On est en présence d’une contrainte de totalité, à prendre en compte non pas au niveau applicatif, mais au niveau de la base de données, en mettant en œuvre des triggers.

Accessoirement, utiliser le terme « cardinalité » (qui est consacré en Merise), plutôt que le terme « multiplicité », qui en français signifie quantité considérable (même si les Umliens l'utilisent sous la forme d'un anglicisme mal venu).


A suivre...

[Miko95]

Bonsoir,

L’entité-type ESProduit me paraît un peu tarabiscotée. Au vu des cardinalités 0,1 dont elle fait l’objet, je suppose qu’elle sert soit pour les lignes de facture de type vente de produit, soit pour les quantités des produits utilisés pour les soins. S’il en est ainsi, il serait à mon avis préférable de dégager cette entité-type, devenue forte par construction alors que sémantiquement elle est faible. Vous me direz que je repasse par la case départ et que la représentation qui suit soulève des problèmes, mais justement, j’aimerais savoir quels sont-ils, d’où la remise à plat objet de discussions :

[Facture]--0,N--()--1,1--[LigneFactureProduit(quantité)]--1,1--()--0,N--[Produit]

[Facture]--0,N--()--1,1--[LigneFactureSoin]--1,1--()--0,N--[Soin]--0,N--(Utiliser(quantité))--0,N--[Produit]

Vous me direz que cette représentation ne prend pas en compte les entrées/sorties en relation avec les stocks, mais si l’on urbanise, cet aspect des choses est à considérer dans un sous-modèle dédié à la tenue des stocks, dans lequel on raccrochera les wagons.

LigneFactureSoin est a définir comme une entité ou comme une association? Je vois que vous faites la différence entre [] et (). Le premier c'est pour l’entité et le deuxième pour l'association, c'est ça? Si oui, alors pourquoi il n'y a pas de nom pour l'association entre Facture et LigneFactureSoin?

A propos des montants TTC

A tout le moins, la date d’application d’un taux de TVA doit être prise en compte. A défaut, toutes les factures concernées par un taux qui change verront leur montant TTC évoluer en conséquence, y-compris celles déjà en possession des clients. De même, que se passe-t-il quand le montant HT d’un produit change ? Quelles sont les incidences de tout cela sur le système de facturation, donc sur la comptabilité de l’entreprise ?

Il est prudent de prévoir l’historisation des données (prix HT des produits, taux TVA) servant à calculer les prix TTC. Dans la série ceinture, bretelles et épingle à nourrice, on peut par ailleurs prévoir de faire aussi figurer le prix HT et la TVA au niveau des lignes de facture, afin d'être sûr de ce que l’on a effectivement facturé au client. Cela introduit une redondance a priori parce qu’au moment de la fabrication d'une facture, ces éléments sont la copie de ce qu’on trouve dans les entités-types PRODUIT et TAUX_TVA, mais la validité a un prix.

J'ai pense a l'historisation après avoir lu ce sujet sur le forum, j'attendais la fin pour voir ça. Dans ce cas, comment mettre en place l'historisation dans le MCD?

Retour sur l’urbanisation

Comme je l’ai dit, avant toute chose, le MCD de Miko95 mérite d’être urbanisé. En effet, si ça continue, une poule n’y retrouvera pas ses poussins. Je ne dis pas que ce MCD est illisible, contrairement à celui que je sers à l’occasion pour l’édification des foules (et j’ai connu vingt fois pire...), qui tient plutôt de l'art contemporain new-yorkais :



Par exemple, il est d’usage de ne pas mélanger ce qui concerne les clients d'une part et les fournisseurs d'autre part : quand on s’intéresse aux soins de nos chers clients, passez-moi l’expression, on se contref... pas mal de la tenue des stocks, de la gestion des en-cours ou de la gestion du personnel, bref on se concentre sur les ventes, ce qui fait rentrer les sous, sans être distrait par le reste, et de la même façon, quand on s’occupe des achats, on se f... éperdument des abonnements des clients, on cherche surtout à acheter dans les meilleures conditions.

J'ai pense utiliser les packages a partir du moment ou j'ai vu qu'au niveau de l'image ça devenait "flou" (zoom arrière trop grand). C'est vrai que c'est pas trop évident de choisir quels entités/associations mettre dans chaque package. Pouvez vous m'indiquer quoi mettre dans chaque package de sorte a mettre un peu d'ordre dans les diagrammes?

Divers

On est en présence d’une contrainte de totalité, à prendre en compte non pas au niveau applicatif, mais au niveau de la base de données, en mettant en œuvre des triggers.

Ok, dans ce cas, ça se passera au niveau du MPD, c'est bien ça? (pas tous les SGBD supportent les triggers, MySQL par exemple pour les INSTEAD OF)

Accessoirement, utiliser le terme « cardinalité » (qui est consacré en Merise), plutôt que le terme « multiplicité », qui en français signifie quantité considérable (même si les Umliens l'utilisent sous la forme d'un anglicisme mal venu).

D'accord, j'y ferais attention. J'ai utilise le terme multiplicité car l'outil de correction orthographique de Firefox ne reconnaissait pas le mot.

Merci

[fsmrel]

Bonjour,

pourquoi il n'y a pas de nom pour l'association entre Facture et LigneFactureSoin ?

Il n’y a pas de nom parce que je vous laisse choisir celui qui vous fait plaisir. L’objet de mes remarques ne porte pas sur la façon de nommer les associations-types.

LigneFactureSoin est a définir comme une entité ou comme une association? Je vois que vous faites la différence entre [] et (). Le premier c'est pour l’entité et le deuxième pour l'association, c'est ça?

J’ai utilisé des crochets pour les entités-types et des parenthèses pour les associations-types. Maintenant, les deux entités-types LigneFactureProduit et LigneFactureSoin sont parfaitement hypothétiques, je les ai utilisées uniquement pour exposer un problème concernant l’entité-type ESProduit. Cela dit, si l’on mettait réellement en œuvre l’entité-type LigneFactureProduit, il faudrait l’identifier relativement à l’entité-type Facture, en mettant entre parenthèses la cardinalité 1, 1 dans le style Power AMC :

[Facture]--0,N--()--(1,1)--[LigneFactureProduit(LigneFactureProduitId, Quantite)]--1,1--()--0,N--[Produit]

A vous de voir si vous préférez cette façon de faire ou si vous préférez utiliser une association-type :

[Facture]--0,N--(LigneFactureProduit(Quantite))-- 0,N--[Produit]

Même principe pour LigneFactureSoin.

J'ai pense a l'historisation après avoir lu ce sujet sur le forum, j'attendais la fin pour voir ça. Dans ce cas, comment mettre en place l'historisation dans le MCD?

Il y a plusieurs écoles. Pour ma part, j’adhère à la théorie des données intervallaires de Date, Darwen et Lorentzos, et j’isole les données actives des données historisées. Prenons le cas des produits :

On a une entité-type PRODUIT qui permet de connaître le prix en vigueur pour chaque produit (attribut PrixProduitHT) et la date depuis laquelle ce prix est en vigueur (attribut PrixProduitDepuis) :

PRODUIT {IdProduit, NomProduit, PrixProduitDepuis, PrixProduitHT}

(Vous noterez en passant que je ne retiens pas l’attribut QuantStockProd : au nom de l’urbanisation, il devrait de préférence dégager dans une entité-type croupion, concernant disons la tenue des stocks, mais si vous tenez à le conserver tel quel, à vous de voir).

On a par ailleurs une entité-type où l’on conserve le passé :

PRODUIT_HISTO {IdProduit, DateDebutPrix, DateFinPrix, PrixProduitHT}

L’idéal étant d’utiliser des périodes (attribut PeriodePrix) :

PRODUIT_HISTO {IdProduit, PeriodePrix, PrixProduitHT}

Mais le plus souvent, les SGBD dits relationnels ne proposent ni ne permettent de définir le type Periode.

Quoi qu’il en soit, Le MCD devient :

[PRODUIT]--0,N--(HistoriserPrixProduit)--(1,1)--[PRODUIT_HISTO]

Au niveau tabulaire, du point de vue théorique, la clé de la table PRODUIT_HISTO est la suivante :

{IdProduit, PeriodePrix}

Si l’on ne peut pas utiliser le type Periode, la clé de la table PRODUIT_HISTO est la suivante :

{IdProduit, DateDebutPrix}

Mais c’est vraiment pour la forme. En effet, dans tous les cas de figure il faudra prévoir des contraintes pour s’assurer que les périodes ne se recouvrent pas et plus généralement, il faudra garantir le respect des Nine requirements décrits dans l’ouvrage que j’ai cité (vous pouvez aussi consulter à ce sujet le support de cours de Hugh Darwen).

Attention : si des produits sont historisés mais ne font plus partie des produits en activité, au niveau du MLD on ne peut plus établir de contrainte référentielle entre les tables PRODUIT et PRODUIT_HISTO, en conséquence de quoi au niveau MCD, le lien entre PRODUIT et PRODUIT_HISTO disparaît. Pour éviter cela, on peut mettre en œuvre une entité-type supplémentaire, ayant la même structure que PRODUIT_HISTO, appelons-la par exemple PRODUIT ARCHIVÉ, donnant lieu à une table dans laquelle iront loger les produits qui n’ont plus cours mais dont on veut garder une trace (à l’intention des fouilleurs du XXIIe siècle...)

J'ai pense utiliser les packages a partir du moment ou j'ai vu qu'au niveau de l'image ça devenait "flou" (zoom arrière trop grand). C'est vrai que c'est pas trop évident de choisir quels entités/associations mettre dans chaque package. Pouvez vous m'indiquer quoi mettre dans chaque package de sorte a mettre un peu d'ordre dans les diagrammes?

Je vous ai dit que je n’utilisais pas les packages mais les vues. En tout cas je vous laisse réfléchir au rôle attribué à chaque sous-domaine, je vous ai donné des pistes. Pour chaque attribut de chaque entité-type, posez-vous déjà la question : Cet attribut concerne-t-il les ventes aux clients ? Les achats ? Les deux ?

ça se passera au niveau du MPD, c'est bien ça? (pas tous les SGBD supportent les triggers, MySQL par exemple pour les INSTEAD OF)

Au sens Power AMC, ça se passe au niveau MLD/MPD. Mais l’important est que la contrainte fasse l’objet d’une assertion au sens de la norme SQL (donc d’un trigger pour les SGBD qui ne proposent pas l’instruction CREATE ASSERTION).

Exemple d’assertion mettant en jeu les tables issues des entités-types hypothétiques LigneFactureProduit et LigneFactureSoin, à traduire en trigger en fonction de votre SGBD :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE ASSERTION AssertFacture01
  CHECK (NOT EXISTS 
    (SELECT FactureId 
     FROM   Facture AS x
     WHERE  NOT EXISTS 
             (SELECT * 
              FROM   LigneFactureProduit AS y 
              WHERE  x.FactureId = y.FactureId)
       AND  NOT EXISTS 
             (SELECT * 
              FROM   LigneFactureSoin AS y 
              WHERE  x.FactureId = y.FactureId)
      )) ;

[Miko95]

Bonsoir,

Cela dit, si l’on mettait réellement en œuvre l’entité-type LigneFactureProduit, il faudrait l’identifier relativement à l’entité-type Facture, en mettant entre parenthèses la cardinalité 1, 1 dans le style Power AMC :

[Facture]--0,N--()--(1,1)--[LigneFactureProduit(LigneFactureProduitId, Quantite)]--1,1--()--0,N--[Produit]

A vous de voir si vous préférez cette façon de faire ou si vous préférez utiliser une association-type :

[Facture]--0,N--(LigneFactureProduit(Quantite))-- 0,N--[Produit]

Même principe pour LigneFactureSoin.

Les deux façons sont donc équivalentes? Si oui, celle ou l'on utilise les associations-types me parait moins lourde au niveau du diagramme.


Est ce que les entités types en rapport avec l'historisation doivent être mis dans une vue a part? Sinon, je vais me renseigner sur le sujet avant de pouvoir en discuter.

Je vous ai dit que je n’utilisais pas les packages mais les vues. En tout cas je vous laisse réfléchir au rôle attribué à chaque sous-domaine, je vous ai donné des pistes. Pour chaque attribut de chaque entité-type, posez-vous déjà la question : Cet attribut concerne-t-il les ventes aux clients ? Les achats ? Les deux ?

Ce que j'essaye de comprendre, c'est pourquoi vous parlez au niveau attribut. J'aurais dis que pour chaque entité type, on devrait vérifier s'il concerne les ventes, achats ou les deux. Si l'on vérifie cela au niveau attribut, alors je comprends que dans deux vues, on peut retrouver la même entité type mais avec différents attributs affiches (dans chaque vue, les attributs qui sont concernés par le thème de la vue?)?
Sinon, j'ai pense décomposé le modèle en plusieurs vues:
-Rdv
-Achats
-Ventes(ça inclue les soins et les produits)
-GestionStocks
-Historisation (peut être?)
Qu'en pensez vous?

Au sens Power AMC, ça se passe au niveau MLD/MPD. Mais l’important est que la contrainte fasse l’objet d’une assertion au sens de la norme SQL (donc d’un trigger pour les SGBD qui ne proposent pas l’instruction CREATE ASSERTION).

Exemple d’assertion mettant en jeu les tables issues des entités-types hypothétiques LigneFactureProduit et LigneFactureSoin, à traduire en trigger en fonction de votre SGBD :

Si je comprends bien, le trigger vérifie qu'il n'existe pas de facture qui ne possèdent ni ligne de produits ni ligne de soins, c'est ça?
Au niveau SGBD justement, je ne sais pas encore quel SGBD choisir. Que me conseillez vous? (J'ai SQL Server 2008 que Microsoft fournit aux étudiants.)

Merci

[fsmrel]

Les deux façons sont donc équivalentes? Si oui, celle ou l'on utilise les associations-types me parait moins lourde au niveau du diagramme.

Faites votre choix non pas en fonction de la légèreté mais de la dimension sémantique de ce que vous représentez.

Pour paraphraser les frères Jolivet à propos d’un de leurs sondages fictifs, selon lequel 40% des Français ont un chat, 30% d’entre eux ont un chien et 30% n’ont pas d’opinion, je dirais que x% des concepteurs considèrent que les lignes de factures sont des composants des factures, donc mettent en oeuvre une entité-type (faible) LigneFacture, y% des concepteurs préfèrent voir la ligne de facture comme associant la facture et un produit, donc mettent en œuvre une association-type LigneFacture, tandis que z% des concepteurs n’ont pas d’opinion et à la limite plutôt que modéliser un carré ou rond n’auraient pas d’état d’âme à modéliser un « carrond »...

Je me souviens des soucis qu’avait un concepteur dans une banque. Celui-ci avait modélisé une opération sur titre sous forme d’association-type entre un titre, un trader, un broker, une place cotation, etc. Tout allait bien. Hélas ! l’utilisateur qui se piquait de connaître la modélisation a exigé que cette opération fasse l’objet d’une entité-type. J’ai expliqué au concepteur que le client était roi et qu’il fallait se plier à sa vision des choses. En effet, que l’opération soit représentée sous forme de carré ou de rond, peu importe, car après dérivation on produit des tables et le résultat est le même (à la structure de la clé près). Au fait, pourquoi l’utilisateur avait-il exigé que l’opération sur titre fasse l’objet d’une entité ? Tout simplement pour des raisons émotionnelles, car à l’époque, les titres furent dématérialisés, les papiers réduits à l’état de confettis ou de cendres, mais l’utilisateur en manque — un peu comme le manchot a mal à son bras manquant — sentait toujours son carnet à souches dans sa poche, et celui-ci n’avait pour lui rien d’une relation...

Comme beaucoup, je penche pour représenter de la ligne de facture sous forme d’entité-type, car outre l’aspect sémantique des choses, elle peut être associée à d’autres entités-types, alors qu’avec une représentation merisienne, vous ne pouvez pas associer une association-type avec une autre association-type.

En revanche, le choix d’une association-type peut s’avérer intéressant au niveau physique, car on consomme moins de ressources physiques en cas de mise à jour (gain d’un index).

En effet, si l’on met en œuvre une association-type au niveau conceptuel, la structure de la table correspondante au niveau logique sera la suivante :

Code SQL :

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

1
2
3
4
5
TABLE LigneFactureProduit 
    {FactureId, ProduitId, Quantite}
         PRIMARY KEY {FactureId, ProduitId}
         FOREIGN KEY {FactureId} REFERENCES Facture... 
         FOREIGN KEY {ProduitId} REFERENCES Produit...

Soit deux index, de clés respectives :

{FactureId, ProduitId},
{ProduitId}.

Si au niveau conceptuel on met en œuvre une entité-type, on a une clé supplémentaire :

Code SQL :

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

1
2
3
4
5
6
TABLE LigneFactureProduit 
    {FactureId, LigneFactureProduitId, ProduitId, Quantite}
         PRIMARY KEY {FactureId, LigneFactureProduitId}
         UNIQUE {FactureId, ProduitId}
         FOREIGN KEY {FactureId} REFERENCES Facture... 
         FOREIGN KEY {ProduitId} REFERENCES Produit...

En conséquence de quoi, au niveau physique on aura ainsi trois index de clés respectives :

{FactureId, LigneFactureProduitId},
{FactureId, ProduitId},
{FactureId, LigneFactureProduitId}.

Ce qui est plus coûteux lors des opérations de mise à jour (INSERT, UPDATE, DELETE, LOAD, etc.)

Est ce que les entités types en rapport avec l'historisation doivent être mis dans une vue a part?

Si l’on historise beaucoup, c'est-à-dire si les MCD finissent par être bien chargés, on peut effectivement préférer représenter les historiques dans des vues, sinon, du point de vue de l’urbanisation, l’historique des produits reste accroché aux produits et ne dégage pas dans une autre vue.

Un autre élément de réflexion pour urbaniser : une vue correspond en général à une vision métier des choses.

Ce que j'essaye de comprendre, c'est pourquoi vous parlez au niveau attribut. J'aurais dis que pour chaque entité type, on devrait vérifier s'il concerne les ventes, achats ou les deux. Si l'on vérifie cela au niveau attribut, alors je comprends que dans deux vues, on peut retrouver la même entité type mais avec différents attributs affiches (dans chaque vue, les attributs qui sont concernés par le thème de la vue?)?

J’ai parlé « attribut » parce que vous mélangiez au sein de l’entité-type Produit des données concernant les ventes mais aussi des données ne concernant que les stocks (attribut QuantStockProd). Une question à ce propos : Pourquoi avoir mis en œuvre l’attribut QuantStockProd ? Si pour un produit donné on sait en calculer la valeur, il doit disparaître. Si on ne sait pas le faire, quelle en est la raison ?

Cela dit, il est évident que celui dont la conception est le métier ne fera pas de cocktails. A noter que dans une vue Power AMC (contrairement aux vues SQL qui sont quand même s’une nature différente) on fait figurer des entités-types avec tous leurs attributs.

j'ai pense décomposé le modèle en plusieurs vues:
-Rdv
-Achats
-Ventes(ça inclue les soins et les produits)
-GestionStocks
-Historisation (peut être?)
Qu'en pensez vous?

Essayez déjà avec une vue Clients (on vend à des clients, c’est un métier) et une vue Fournisseurs (on achète à des clients, c’est un autre métier). Concernant la gestion des stocks, on est à la croisée des chemins et cela devrait donner lieu à une autre vue. Concrètement si dans votre cas la vue Fournisseurs n’est pas chargée, elle peut absorber la vue Gestion des Stocks. Pour la partie Historisation, on va éviter.

Si je comprends bien, le trigger vérifie qu'il n'existe pas de facture qui ne possèdent ni ligne de produits ni ligne de soins, c'est ça?

Un trigger permet effectivement de d’assurer qu’une facture a au moins une ligne (ligne produit, ligne soin, ou souscription d’après votre MCD).

Au niveau SGBD justement, je ne sais pas encore quel SGBD choisir. Que me conseillez vous? (J'ai SQL Server 2008 que Microsoft fournit aux étudiants.)

Si SQL Server 2008 vous donne satisfaction, conservez-le.

[seabs]

Bonjour,

Je remercie fsmrel d'avoir pris le relais, il vous expliquera mieux que moi, les modifications nécessaires pour établir un MCD satisfaisant.

Il possède un sens pédagogique pour vous expliquer clairement les modifications à faire et pourquoi les faire.

J'avais bien remarqué qu'il existait des points à éclaircir. Mais entre voir et expliquer, il y a un pas pour lequel, il me manque encore de l'expérience. Exemple : entité-type et association-type.

Je vous souhaite bon courage et A+