Discussion :

[frm013]

Bonjour à tous,

Après avoir pris connaissance de pas mal de fils de discussions dans ce forum et avoir lu avec beaucoup d'intérêt certains articles de la communauté, j'ai réalisé un premier modèle pour un nouveau projet.

J'aimerais pouvoir confronter ma vision avec celles et ceux qui voudront bien me conseiller et / ou me corriger.

Le Projet

Il s’agit d’un site d’offre et de demande de pièces détachées. Les utilisateurs pouvant rechercher ou proposer des pièces.

Le site propose à cet effet un catalogue de pièces déjà existant.

Règles de gestion principales

RG01 - Un utilisateur peut rechercher et/ou proposer des pièces détachées.
RG02 - Un utilisateur peut avoir en stock des pièces qu’il n’a pas publié sur le site.
RG03 - Un utilisateur peut être professionnel et acheteur.

RG04 - Le particulier publie une ou plusieurs listes de pièces qu’il recherche (demandes).
RG05 - Un professionnel répond à une demande en proposant une offre pour une ou plusieurs pièces d’une ou plusieurs demandes.

RG06 - Un utilisateur peut supprimer une demande à tout moment y compris après achat. Les réponses éventuelles seront supprimées.

Achats:

RGA01 - L’utilisateur peut faire une demande de devis pour une ou plusieurs pièces d’une réponse.
RGA02 - L’utilisateur peut passer commande d’un devis. Une commande doit porter sur la totalité du devis.
RGA03 - Après paiement de la commande, un bon de livraison et une facture sont établis.

RGA04 - On doit pouvoir facturer sans commande: intérêts, pénalités, etc...

Retours:

RGR01 - L’utilisateur peut faire une demande de retour pour une ou plusieurs pièces ayant été livrées.
TGR02 - S’il en est d’accord, le professionnel établi un bon de retour et un avoir pour les pièces concernées.

RGR03 - On doit pouvoir établir un avoir exceptionnel sans facture correspondante: remise exceptionnelle pour une vente à problème par exemple.

Préambule:

Afin de ne pas alourdir le modèle, la partie utilisateurs à été simplifiée, on admettra que les règles RG01 à RG03 sont respectées. Je les ai mentionnées afin d'avoir une bonne vision du sujet.

Si il est juste et pertinent ce modèle me fait me poser des questions quand à sa gestion au sein d'un SGBDR (postgresql ).

Je remercie d'avance tous ceux qui auront la gentillesse de participer.

[fsmrel]

Bonsoir frm013,


Je n’ai regardé que la partie du modèle relative aux demandes et aux réponses.


Entité-type REPONSE

Selon votre MCD, l’entité-type REPONSE est un sous-type de l’entité-type LISTE, une réponse est donc une liste.


Entité-type LISTE

De ce qui précède on déduit que l’entité-type LISTE a pour instances (occurrences) non seulement les listes de demandes des particuliers, mais aussi les listes des réponses des professionnels.


Association CONTENIR

Dans le MCD, la patte connectant les entités-types LISTE et ITEM_LISTE est porteuse d’une cardinalité 1,N, ce qui veut dire que chaque instance de LISTE est référencée par au moins une instance d’ITEM_LISTE, c'est-à-dire qu’ITEM_LISTE sert aussi bien pour les réponses que pour les demandes.


Association PROPOSER

Au vu de ce qui précède, on pourrait imaginer qu’en plus de réponses à des demandes, on ait des réponses à des réponses...

On peut quand même subodorer qu’ITEM_LISTE ne concerne que les demandes, donc que la cardinalité 1,N connectant les entités-types LISTE et ITEM_LISTE est à remplacer par 0,N.

Qu’en est-il ?

A ces remarques près, pour la partie relative aux demandes et aux réponses votre MCD a l'air de fonctionner, mais il ne serait pas mauvais de le déplier en spécialisant l’entité-type USER en PARTICULIER et PROFESSIONNEL, et au besoin en d’autres sous-types (en passant, attention, dans le cas de certains SGBD SQL, « USER » est un mot réservé, il serait prudent de le remplacer par autre chose). Ainsi, si certains attributs ne concernent qu’un des deux sous-types, vous pourrez les faire figurer au bon endroit. De même vous pourrez brancher l’entité-type MAGASIN sur l’entité-type PROFESSIONNEL et éviter au cours des opérations de brancher un magasin et un particulier. Ces remarques valent pour les commandes, devis, etc.


Cardinalités minimales (diagramme MWB)

En ce qui concerne votre diagramme MWB (MySQL Workbench), il faudrait synchroniser les cardinalités minimales avec celles du MCD, c'est-à-dire remplacer les cardinalités minimales 1 (que MWB propose par défaut) par 0 quand il le faut.


Du singulier et du pluriel

Un type d’entité (ou entité-type) est une classe d’entités ayant en commun un ensemble de propriétés. Le type d’entité MAGASIN symbolise le magasin-type, lequel a pour propriétés (attributs) son nom, son Siret, etc. Quant à eux, les magasins proprement dits sont les entités, les instances (ou encore les occurrences) de la classe MAGASIN. Tout cela pour dire qu’un nom d’entité-type s’écrit de préférence au singulier : MAGASIN mais pas MAGASINS.


Cela dit, pour un premier modèle, c’est quand même pas mal, mais je vous engage à déplier...

[frm013]

Bonjour M. de Sainte Marie,

Tout d'abord, merci de votre participation à cette réflexion, en effet, après 2 semaines je commençais à tourner en rond et il est toujours bon d'avoir le "troisième oeil" dans ce cas.

Cela dit, pour un premier modèle, c’est quand même pas mal, mais je vous engage à déplier...

Merci aussi, ce n'est pas le premier modèle, il s'agit de re-modéliser une base datant de 1998 et d'y ajouter d'autres fonctionnalités. Il s'agissait d'un soft que je veux porter sur le web. J'ai essayé d'avancer au maximum avant de poster ici

Au vu de ce qui précède, on pourrait imaginer qu’en plus de réponses à des demandes, on ait des réponses à des réponses...

Effectivement, je ne sais pas modéliser cela
J'ai ajouté une contrainte entre CONTENIR et REPONDRE, mais je ne sais pas si c'est correct.

il ne serait pas mauvais de le déplier en spécialisant l’entité-type USER en PARTICULIER et PROFESSIONNEL

Comme je le disais en préambule, j'ai volontairement simplifié la partie "users".
J'ai donc modifié le MCD pour y inclure une partie de ce modèle, laissant de coté les adresses, téléphones et emails. Si vous le souhaitez, je vous fournirai ce modèle.

J'ai modifié le MPD MWB au niveau des cardinalités.

Egalement, j'ai ajouté la relation entre REPONSE et MAGASIN, un oubli de ma part.

Concernant le singulier, je ne savais pas que cela s'appliquait aussi au MCD, je le faisais en UML... doit on aussi nommer les tables physique de cette façon?
Mon framework considère qu'elles doivent être au pluriel Peut-être est-ce seulement leur convention.





En tous cas je crois qu'il est indispensable de solliciter un avis externe quand on modélise, je pensais que la partie demandes / réponse ne posait pas de problèmes...

A propos de MWB, avez vous trouvé une astuce pour plier les liens comme on veut, parce que les liens qui se croisent me plaisent moyen moyen...

A vous lire,
François

[fsmrel]

Bonsoir François,


Vous avez nommé les entités-types au singulier : parfait. Si vous en faisiez autant au stade MWB, ça serait bien (à moins que le framework ne tolère les noms de tables qu’au pluriel ). Comme de mon côté l’emploi du pluriel pour un prédicat me fait loucher, j’utiliserai le singulier dans ce qui suit.

Puisque vous êtes un habitué d’UML, vous pouvez en utiliser la notation avec MWB :





Dans le MLD (le diagramme MWB), vous avez fait figurer une association entre MAGASIN et ACTOR, mais cette association (sans nom) ne figure pas dans le MCD et d’autre part il manque une cardinalité, tout comme une clé étrangère. Quant aux liens qui se croisent, le plus souvent on essaie de d’en sortir à coups de vues. Par exemple, pour créer une vue (en fait un diagramme) des demandes et des offres, vous créez un nouveau diagramme (commande » CTRL-T »), vous lui donnez un nom (exemple Demandes ») en remplaçant le nom proposé par MWB (Menu : « Model » > « Diagram Properties and Size »), puis vous faites un glisser-déposer des noms des tables qui figurent dans le catalogue (Catalog tree). MWB se charge de faire figurer les associations existant entre les tables présentes dans le nouveau diagramme. Si vous voulez masquer des tables ou des associations : « Menu > Edit > Delete » et dans fenêtre « Delete Object » qui s’ouvre, cliquer sur « Keep » (sinon, avec « Delete » ça détruit...)


Concernant la contrainte d’exclusion, ce que vous avez représenté signifie effectivement qu’un item_liste ne peut pas appartenir à la fois à une liste et faire l’objet d’une réponse. Pour la forme, on peut faire figurer (trait en pointillés) le pivot de la contrainte (entités-types participant à la contrainte), on montre ainsi que c’est bien la table item_liste qui est la responsable des erreurs potentielles. :



Mais au stade SQL, il faudra qu’un trigger soit programmé pour que la contrainte soit effective.


Maintenant, le fait que l’entité-type LISTE (j’utilise les lettres capitales pour mieux voir) serve aussi bien pour les listes de réponses que de demandes me fait un peu tiquer. Au-delà de la dimension sémantique, je pense aux opérations de mise à jour. Supposons qu’on effectue un traitement de mise à jour de masse sur les réponses, la table LISTE sera donc verrouillée. Si pendant ce temps des transactions concernent des demandes, elles seront bloquées. Je séparerais donc volontiers les demandes des réponses dans des tables distinctes. En plus la volumétrie des tables sera (pour faire court) divisée par deux, la contrainte d'exclusion représentée plus haut n’aura pas lieu d’être et moins il y a de triggers plus on se simplifie la vie. Par ailleurs selon votre modèle, rien n'interdit par le biais de la table REPONSE de brancher par mégarde une réponse sur une réponse ou de faire figurer une demande à la place d'une réponse (attribut id_liste de la table REPONSE).

Cette séparation nette passe par la spécialisation des utilisateurs en PROFESSIONNEL et PARTICULIER comme j’en avais fait mention dans mon message précédent. Si MACHIN (voir de quelle entité-type il s'agit dans votre MCD) est le surtype commun à ces deux types d’utilisateurs, je verrais quelque chose comme ceci où l’on déplie :


MCD

Un particulier fait des demandes d’articles, chaque demande pour un article fait l’objet d’un item demande.

Un professionnel fait des réponses, chaque réponse fait l’objet d’un ou plusieurs items réponse faisant chacun référence à un item demande.

Les cardinalités 1,1 mises entre parenthèses sont caractéristiques de l’identification relative (notation PowerAMC), cas des pattes connectant ITEM_DEMANDE et REP_PRO d’une part, DEM_ART d’autre part.




MLD




N.B. A propos de la règle RG06 : Si au stade SQL on utilise l’option CASCADE, la suppression d’une demande entraîne celle des items demande et réponse correspondants, mais le stimulus ne parvient pas jusqu’à la table REPONSE, on se retrouverait donc avec des réponses sans items. A voir.

J’espère ne pas trop vous faire tiquer à votre tour, en tout cas, bon courage,


François

[frm013]

Bonsoir François,

Je suis toujours sur le "dossier", mais je suis un peu au ralenti ces jours-ci, luttant contre un sale virus..

Dans le MLD (le diagramme MWB), vous avez fait figurer une association entre MAGASIN et ACTOR

C'est encore un croisement mal à propos de MWB d'une association concernant l'entité DOCUMENTS don't nous n'avons pas encore parlé.

Concernant MACHIN, il s'agit de l'entité-type ACTOR dans mon MCD.

L'entité LISTE doit d'ailleurs y être associée à la place de PARTICULIER, car un professionnel peut faire une demande (RG01).

C'est la raison pour laquelle j'ai créé ce sur-type, n'importe quel acteur dans ce système doit pourvoir utiliser n'importe quelle fonctionnalité. J'avais cette erreur de modélisation dans la précédente base: client, personnel, fournisseur... ça fini par coincer

J’espère ne pas trop vous faire tiquer à votre tour, en tout cas, bon courage,

Merci, vous ne me faîtes pas tiquer, c'est ce modèle qui le fait...

Le mien produit des listes sans items, c'est bof bof.

Dans le votre, deux entités sont quasi identiques, pour le coup, c'est moi qui louche.
Il est vrai que j'ai la (fâcheuse?) tendance à vouloir tout factoriser et à différencier les cas en caractérisant les entités ainsi factorisées.

J'espère vous fournir un autre modèle bientôt... pour l'instant ça fume!

A propos, vous ne dormez jamais?

A très bientôt,
François

PS: si vous souhaitez que je vous fournisse les fichiers MWB ou JMerise, n'hésitez pas.

[frm013]

Bonjour François,

Me voici de retour en meilleure forme.

Après réflexion, je préfère encore deux entités similaires ( REPONSE, DEMANDE ).

J'ai ajouté à votre MCD l'association REPONDRE car nous avons besoin, lors de la sélection d'une REPONSE, des lignes des la DEMANDE auxquelles nous n'aurions pas encore répondu. Cela résout le problème du ON DELETE CASCADE

J'ai également "branché" DEMANDE sur ACTOR, comme je vous l'expliquais dans mon précédent message.

Je suppose, que d'un point de vue SQL, nous aurons besoin d'une vue (demandeurs par ex. ) pour récupérer soit une personne soit une société lors de la sélection des demandes. Probablement un SELECT... UNION. Cela vous semble-il une bonne pratique?

MCD :



MPD:



Demeure un problème, si je suis votre rigueur d'analyse, rien d'empêche d'associer un ITEM_REPONSE à un ITEM_DEM d'une autre DEMANDE...
Même si ce sera impossible au niveau software.

Pour résoudre cela on pourrait rendre identifiante l'association REPONDRE, mais auquel cas on se retrouverais avec deux fois l'id_dem dans ITEM_REPONSE. A moins q'un attribut puisse, au sens SQL, participer à deux contraintes référentielles ??

Au passage, j'ai abandonné l'idée de la demande de devis ( RGA01 ) qui, quelle que soit la façon dont on la traite, complique les choses et n'apporte rien puisque on peut considérer qu'une réponse à été faite au bon prix, inutile d'avoir un devis en plus.

Merci d'avance de votre retour et désolé pour ce délai.

Cordialement,
François

[fsmrel]

Bonsoir François,

Demeure un problème, si je suis votre rigueur d'analyse, rien d'empêche d'associer un ITEM_REPONSE à un ITEM_DEM d'une autre DEMANDE...
Même si ce sera impossible au niveau software.
Pour résoudre cela on pourrait rendre identifiante l'association REPONDRE, mais auquel cas on se retrouverais avec deux fois l'id_dem dans ITEM_REPONSE. A moins q'un attribut puisse, au sens SQL, participer à deux contraintes référentielles ?

Un attribut d'une table donnée peut participer à plus d'une clé étrangère et ça permet de résoudre le problème des contraintes de chemin. A titre d’exemple, voyez ici où là.

Dans le 2e exemple, PMACU signifie que pour une année universitaire A, un module M (exemple : Bases de données) d’une unité d’enseignement U (exemple : Informatique) et une catégorie C (exemple : travaux dirigés), un professeur ne peut noter que des élèves qui au cours de l’année universitaire A ont suivi les cours correspondant au module M de l’unité d’enseignement U dans la catégorie C. Il y a 4 attributs communs dans les tables PMACU et NOTATION et ainsi la note obtenue (table NOTATION_EFFECTIVE) ne peut pas être donnée par un prof non concerné...

[frm013]

Bonsoir François,

Un attribut d'une table donnée peut participer à plus d'une clé étrangère et ça permet de résoudre le problème des contraintes de chemin. A titre d’exemple, voyez ici où là.

En voilà une nouvelle qu'elle est bonne.
Cela m'ouvre de nouvelles perspectives, de la même façon que lorsque j'ai appris que l'on pouvait avoir des associations d'associations, ce que je croyais, à tort, mal.

Je joins donc les modèles corrigés. Peut-on les considérer comme valides?

Si oui, je m'attaquerai à la partie commandes.
A moins que vous n'ayez déjà des remarques sur cette partie, ce qui ne m'étonnerai pas.

MCD :



MPD:



Cordialement,
François

[fsmrel]

Bonsoir François,


On est sur le bon chemin quant aux contraintes du même nom...



Concernant le diagramme MWB :

1) L’association entre les tables REPONSE et DEMANDE est redondante, donc inutile, car pour connaître la réponse à une demande, il suffit de coder :

Code SQL :

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

1
2
SELECT id_dem
FROM   REPONSE AS x INNER JOIN ITEM_REPONSE AS y ON x.id_rep = y.id_rep

2) Selon votre diagramme, une réponse peut être faite par un acteur A1 et concerner le magasin M1 de l’acteur A2, est-ce bien normal ? Buen camino ?

[frm013]

Bonsoir François,

1) L’association entre les tables REPONSE et DEMANDE est redondante, donc inutile, car pour connaître la réponse à une demande, il suffit de coder :

Code SQL :Sélectionner tout - Visualiser dans une fenêtre à part
1
2
SELECT id_dem
FROM REPONSE AS x INNER JOIN ITEM_REPONSE AS y ON x.id_rep = y.id_rep

Je comprends ce que vous dites, mais comment avoir les ITEM_DEMANDE auxquels REPONSE n'a pas encore répondu?

D'autre part, sauf erreur, nous perdons l'identification relative nous permettant d'éviter de répondre à plusieurs demandes par une seule réponse.

2) Selon votre diagramme, une réponse peut être faite par un acteur A1 et concerner le magasin M1 de l’acteur A2, est-ce bien normal ?

Oui, vrai, oops!
Là je sèche, faire de l'association POSSEDER une association identifiante?

C'est assez nouveau pour moi les contraintes de chemin... mais passionnant.

[frm013]

Bonjour François,

2) Selon votre diagramme, une réponse peut être faite par un acteur A1 et concerner le magasin M1 de l’acteur A2, est-ce bien normal ? Buen camino ?

Oubliez ce que j'ai dit avant, je pense qu'il faut supprimer l'association REP_PRO. Qu'en pensez vous?

A bientôt,
François

[fsmrel]

Bonsoir François,

comment avoir les ITEM_DEMANDE auxquels REPONSE n'a pas encore répondu?

Que vaut une réponse sans item_reponse ? Ne vaut-elle pas ce que vaut une commande sans ligne de commande ? Ne créé-t-on pas une réponse en même temps qu’on crée au moins un item_reponse ?

sauf erreur, nous perdons l'identification relative nous permettant d'éviter de répondre à plusieurs demandes par une seule réponse.

Il est exact que si une réponse ne concerne qu’une demande (ce dont je n’avais pas tenu compte ) alors l’association REPONDRE est nécessaire, donc on la conserve.

je pense qu'il faut supprimer l'association REP_PRO.

Oui, elle est inutile puisqu’inférable (par transitivité) des associations PROVENIR et POSSEDER (ça fait une contrainte de chemin en moins à assurer ).


Buen camino.

[frm013]

Que vaut une réponse sans item_reponse ? Ne vaut-elle pas ce que vaut une commande sans ligne de commande ? Ne créé-t-on pas une réponse en même temps qu’on crée au moins un item_reponse ?

Pas toujours évident de se comprendre... Je pense que ma RG05 n'est pas claire, j'aurai du écrire : "RG05 - Un professionnel répond à une demande en proposant une offre pour une ou plusieurs pièces" tout court!
En pratique, sur son interface, et avant toute création de nouvelles réponses il voit toutes les lignes des demandes, qu'il peut trier à loisir afin de se faciliter la tâche. D'ou ma règle confuse, j'en suis navré.

Après avoir répondu, il doit pouvoir revenir sur une réponse en particulier, pour la corriger par exemple.

A l'écran, voici comment je vois les choses sommairement:



Ainsi, s'il s'avère qu'il à oublié de mentionné que la porte est dispo aussi, il peut le faire.

ça fait une contrainte de chemin en moins à assurer

Oui, d'ailleurs, je me pose des questions quand aux performances. J'ai vu sur une des discussions ou vous intervenez : facturation et devis que le nombre de colonnes constituant les clés primaires avait tendance à grimper. Qu'en est il des perfs dans ce cas?
En effet j'ai toujours lu que l'utilisation de PK avec un entier séquentiel permettait d'accélérer les jointures.

Dans ce cas ici, si on veut toutes les lignes de réponses du mois de octobre:

Code sql :

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

1
2
3
4
5
6
7
8
 
SELECT item_reponse.id_article, article.reference, article.designation, item_reponse.qte as qte_rep, item_reponse.prix
FROM demande
JOIN item_reponse ON item_reponse.id_dem = demande.id_dem
JOIN item_dem ON  item_dem.id_dem = item_reponse.id_dem AND
                     item_dem.id_article = item_reponse.id_article
JOIN article ON article.id_article = item_dem.id_article
WHERE demande.date_liste BETWEEN '01/10/2013' AND '31/10/2013'

cette requête ne pourra utiliser l'index de la PK de ITEM_REPONSE puisque id_dem est en troisième position, nous devront donc ajouter un index sur cette seule colonne si j'en réfère à l'article de SQLPro sur le fonctionnement des index.
Quelles implications cette multiplication des index, ainsi que la taille des clés primaires, sur les performances?

Je dépasse le cadre de ce sujet, mais ça me trotte dans la tête depuis un moment...

Cordialement,
François

[fsmrel]

Bonsoir François,


A propos des règles de gestion :

On aura beau évacuer les ambiguïtés des énoncés, il restera toujours des éléments de confusion, c’est inhérent à la langue, et c’est pour cela que doubler les énoncés par un MCD est nécessaire.


A propos des performances

Je me prononce ici en fonction du SGBD que j’ai utilisé depuis plus de 25 ans, à savoir DB2. Concernant les autres SGBD (dont PostgreSQL que je n’ai jamais eu l'occasion de chahuter), j’espère qu’on peut extrapoler, mais dans tous les cas c’est à partir des résultats du prototypage des performances qu’on peut de prononcer objectivement.

Avec DB2 donc :

L’incidence du nombre de colonnes n’a pas d’incidence sur les performances. Évidemment, il s’agit de colonnes de type INTEGER (4 octets par colonne). En moyenne la hauteur d’un arbre (index) est égale à 3 (soit 3 I/O).

Le nombre d’index dans le cas des consultations n’a pas d’effet négatif, au contraire. Dans le cas traitements de masse faisant de la mise à jour à haute dose, changement de chanson. Je vous invite à méditer l’exemple de la ville méridionale où il fait bon vivre.

Le phénomène de l’I/O bound est celui qu’il faut surveiller (d’où les prototypages des performances), voyez ici. Le choix de l’index cluster est évidemment capital. Dans mes exemples j’ai regroupé les commandes par client, mais il est des situations où il faut les éparpiller (mais en regroupant les lignes par commande), tout dépend des transactions qu’on a privilégiées.

L’ordre des colonnes dans les clés index est capital lui aussi. Examinez l’ordre que j’ai retenu dans mon MLD et l’ordre que vous avez retenu : je pense que dans votre cas l’I/O bound se manifestera plus au vu de votre requête lors des jointures des tables DEMANDE, ITEM_REPONSE, ITEM_DEMANDE. Dans tous les cas, la jointure avec ARTICLE est à surveiller, car plus que les autres sujette à provoquer des I/O bound.

Donc pour s’assurer des performances, une fois choisis les index clusters et ordonnées au mieux les clés dans les index (colonne id_dem en tête y compris dans DEMANDE), reste à soumettre les EXPLAIN permettant de connaître la stratégie d’accès au données par le SGBD, vérifier les index manquants (cf. le coup de la date). Bref, il faut prototyper encore et encore...

[frm013]

Bonjour François,

Ahh DB2, une légende pour moi

Effectivement, le prototypage et les tests font partie de mes préalables, je posait cette question pour le cas général.
J'ai bien peur en effet, que selon les requêtes, il n'y ait pas d'ordre idéal des colonnes dans les index.

J'avais effectivement lu avec beaucoup d'intérêt cette section de votre article.

Concernant votre publication, malheureusement, faute de suffisamment de connaissance théorique en algèbre relationnelle j'ai assez vite décroché malgré plusieurs re-lectures ( je suis autodidacte ).

En pratique, Postgresql ne prend pas en charge les index cluster pour le moment, il faudra donc que je m'en passe. Je fais des tests de perfs depuis un moment qui m'ont l'air prometteurs tout de même: une jointure de 3 tables de 170 000 lignes en 3ms ça me va ( 50 lignes retournées ), 0.6 ms pour 28 lignes, le tout trié sur la référence de l'article ( il s'agit de la nomenclature des pièces ).

Pour aller plus loin... et à propos du modèle des acteurs du système, que j'ai partiellement publié ici.

ACTOR peut avoir plusieurs adresses.
ACTOR doit avoir une adresse principale. Ce qui donne le modèle suivant:

MCD :



MPD :



Le problème, c'est que la règle de gestion pratique est celle-ci:
ACTOR peut avoir zéro ou plusieurs adresses.
ACTOR doit avoir une adresse principale s'il a au moins une adresse.

En effet il faut envisager le cas de utilisateur qui s'enregistre par le biais de l'un de ses comptes de réseaux sociaux. Dans ce cas, ni adresse, ni email jusqu'à ce qu'il faille le livrer.

On pourrait remplacer RESIDER par un flag ( main_address BOOL ) dans ADDRESS, mais j'aime pas les flags, cela produit des index très peu sélectifs...
Je ne veut pas laisser enter le bonhomme NULL , bien entendu, j'en ai assez bavé auparavant en le laissant faire parti de la danse

Qu'en pensez vous?

NB: La table ACTOR_ADDRESS existe car ADDRESS est utile à MAGASINS aussi, donc je ne peut pas faire migrer id_actor dans ADDRESS.
NB 2: Je ne vous soumet que cette partie pour l'instant car j'ai le même souci ailleurs et je souhaite vous fournir un modèle entier plus tard, si vous êtes d'accord bien sûr.

Cordialement,
François

[fsmrel]

Bonsoir François,


L’usage chez les concepteurs est de modéliser la finalité. Comme vous dites, en toute rigueur la règle est la suivante :

Une personne peut avoir plusieurs adresses ;
Une personne doit avoir une adresse principale.

Ce qu’en passant je formulerais (je pinaille) :

Une personne doit avoir une adresse principale ;
Une personne peut en plus avoir plusieurs adresses secondaires.

Peu importe, comme vous le faites observer, cette règle est utopique puisqu’en conflit avec la réalité, à savoir qu’une personne n’est pas obligée de fournir d’adresse tant qu’il n’y a pas de livraison pour elle.

La finalité devient :

Si on doit effectuer une livraison pour une personne, alors celle-ci doit avoir une adresse principale ;
En plus de son adresse principale, une personne peut avoir des adresses secondaires.

Si l’utilisateur y voit un inconvénient c’est qu’il n’a pas tout dit quant aux règles de gestion...

La table ACTOR_ADDRESS existe car ADDRESS est utile à MAGASINS aussi, donc je ne peut pas faire migrer id_actor dans ADDRESS.

Dommage, on aurait pu voir les choses ainsi :



Lors de la saisie de l’adresse de livraison pour un client donné, au stade SQL on va chercher cette adresse dans la table ADRESSE_PPALE : si elle ne s’y trouve pas, le programme ne pourra que s’en rendre compte.

Et l’on aurait pu continuer : pour renforcer les contrôles, établir une association entre l’adresse et la livraison :



Avec vraisemblablement à la clé une contrainte de chemin à résoudre, la livraison pouvant faire référence à la personne concernée par une autre voie : ça se résout par trigger ou par identification relative propageant l’attribut PersonneId jusqu’à LIVRAISON via cette voie.

Mais bon, puisqu’on ne peut pas modifier la structure de la table ADRESSE, la mise en œuvre de la table ACTOR_ADDRESS s’impose, comme vous l’avez fait, avec au passage la remarque suivante : selon votre MCD une adresse fait référence à une seule personne alors que d’après la clé de la table ACTOR_ADDRESS de votre diagramme MWB (en conflit du reste avec les cardinalités), ça peut être à plusieurs personnes : ci-dessous je par du principe que c’est le MCD qui prime.

Votre diagramme montre qu’il y a une contrainte de chemin à résoudre. En effet, supposons que dans la table ACTOR_ADDRESS on ait la paire <adr1, act1> où la valeur <adr1> fait référence à la valeur <adr1> de la table ADDRESS et la valeur <act1> fait référence à la valeur <act1> de la table ACTOR, so far so good, mais l’affaire se corse (chef-lieu Ajaccio) ensuite, car rien n’empêche que dans la table ACTOR on ait la paire <act1, adr2>, aïe !

Pour éviter cela, on peut spécialiser ACTOR_ADDRESS en mettant en œuvre une table ADRESSE_PPALE pour les adresses principales :




Et dans l’esprit de ma remarque faite à propos des livraisons, des fois que ça serve à un moment donné, on peut garder sous le coude la mise œuvre d’une association avec LIVRAISON :



J'espère avoir compris votre problème, en tout cas je n'ai guère d'autres solutions à sortir de mon chapeau...

[SQLpro]

...
En pratique, Postgresql ne prend pas en charge les index cluster pour le moment, il faudra donc que je m'en passe. Je fais des tests de perfs depuis un moment qui m'ont l'air prometteurs tout de même: une jointure de 3 tables de 170 000 lignes en 3ms ça me va ( 50 lignes retournées ), 0.6 ms pour 28 lignes, le tout trié sur la référence de l'article ( il s'agit de la nomenclature des pièces )....

ATTENTION : PG commence à, décrocher dès que l'on dépasse 12 jointures en pratique (algo geko....), vous pouvez augmenter ce seuil, à condition d'avoir un serveur physique très surdimensionné.... En effet, le nombre de possibilités de plans de requêtes est exponentiel et PG les explore tous... Là ou Oracle ou SQL Server ont des algo très rapide pour minimiser le nombre de chemins à explorer. En pratique, des requêtes avec 20 ou 30 jointures sont extrêmement performantes avec SQL Server notamment qui dispose d'un des meilleurs optimiseur du marché !

PG ne dispose pas non plus des index couvrants (avec clause INCLUDE) très intéressant afin de se passer de la double lecture recherche (index) + lecture (table).

De plus, le moteur SQL de SQL Server dispose de plus de 110 opérateurs interne, là ou PG n'en possède qu'une trentaine. par exemple il existe 7 modes d'accès aux tables/index différents, là ou PG n'en fait que 2 :

• scan de table (ou plus récemment d'inex)
• recherche en index

...

Enfin, Last bu not Least, PGG n'est pas un SGBDR multithreadé, c'est à dire qu'une même requête n'est prise en compte que par un seul thread, alors que dans Oracle ou SQL Server c'est multi threadé (une même requête étant parallélisée).

A +

[SQLpro]

Pour aller plus loin... et à propos du modèle des acteurs du système, que j'ai partiellement publié ici.

ACTOR peut avoir plusieurs adresses.
ACTOR doit avoir une adresse principale. Ce qui donne le modèle suivant:

ATTENTION : votre table address montre un pseudo viol de la 1FN... En effet, pourquoi 3 lignes d'adresse ? Si une seule suffit les deux autres seront nulles, ce qui contrevient à l'essence même du modèle (pas de NULL)
Si 3 lignes ne suffisent pas, ou loger la 4e ?
Les lignes devant faire au maximum 38 caractères (norme Européenne de la Poste)

En conclusion, vos lignes d'adresse ne doivent pas être située dans cette table, mais dans une table fille.

Voir le MCD que j'ai publié ici http://blog.developpez.com/exercices..._d_une_adresse

A +

[frm013]

Bonjour M. Brouard et merci pour votre intervention.

Concernant Postgresql:

Le choix de l'abandon de Windows est ferme et définitif, ce qui disqualifie d'entrée de jeu SQL Server dont je ne doute pas des qualités intrinsèques.

Concernant sa limitation à 12 jointures, je ferai des tests et vous en donnerai le retour... sur un autre fil si vous le voulez bien, car nous somme en modélisation ici, mon propos sur les perfs étant une digression visant à valider un choix.

Index couvrants: PG 9.2 et suivants en disposent.

Enfin, Last bu not Least, PGG n'est pas un SGBDR multithreadé

Ceci est un choix de conception que je partage, les gens de postgresql vous ont par ailleurs déjà répondu sur leur forum.


Concernant le pseudo viol de la 1NF:

Heureusement que ce n'est qu'un pseudo viol, pauvre 1NF...
Vous remarquerez que ces colonnes sont marquées NOT NULL, une chaine vide est une valeur.
Il est évident, que l'utilisation d'une entité-type LIGNES_ADDRESS serait plus élégante, mais je ne vois pas de cas ou l'on doive faire une recherche sur une partie des lignes d'adresse, des lignes vides ne me gênent donc pas.
A propos de l'utilisation d'entités-type CODE_POSTAUX, DEPARTEMENTS, VILLES et PAYS, je n'ai pas fait de choix, mais l'idée de me battre à nouveau avec les fichiers de la poste ne m'attire pas plus que cela, ce n'est pas une appli de publi-postage.
A voir, en pratique je n'ai pas eu à souffrir d'une telle modélisation.

Cependant, effectivement, 45 caractères, c'est trop long, erreur de ma part, et il manque une ligne. Mais de tout façon, cette entité-type ADDRESS, n'était là qu'au fins de l'exemple pour résoudre un autre problème, aucuns modèles fournis dans ce fils ne sont complets au niveau des attributs.

Cordialement,
François

[frm013]

Bonjour François,

Votre diagramme montre qu’il y a une contrainte de chemin à résoudre. En effet, supposons que dans la table ACTOR_ADDRESS on ait la paire <adr1, act1> où la valeur <adr1> fait référence à la valeur <adr1> de la table ADDRESS et la valeur <act1> fait référence à la valeur <act1> de la table ACTOR, so far so good, mais l’affaire se corse (chef-lieu Ajaccio) ensuite, car rien n’empêche que dans la table ACTOR on ait la paire <act1, adr2>, aïe !

Le solution était là, me crevant les yeux!
Une adresse principale n'existe que relativement à ADDRESS ET ACTOR!! Donc est une ADDRESS_ACTOR spéciale...

Et dans l’esprit de ma remarque faite à propos des livraisons, des fois que ça serve à un moment donné, on peut garder sous le coude la mise œuvre d’une association avec LIVRAISON

Concernant l'adresse principale, c'est, selon moi, l'adresse de résidence donc de facturation, le client pouvant se faire livrer ailleurs, par exemple chez son garagiste. Mais j'anticipe

A propos:

Si l’utilisateur y voit un inconvénient c’est qu’il n’a pas tout dit quant aux règles de gestion...

L'utilisateur, c'est moi, je ne travaille pas pour un client

Concernant MAGASIN qui fiche le désordre:

La table ACTOR_ADDRESS existe car ADDRESS est utile à MAGASINS aussi, donc je ne peut pas faire migrer id_actor dans ADDRESS.

J'ai bien pensé à en faire une sorte d'ACTOR, ce qui n'est pas complètement faux, puisque c'est bien une entité extérieure au système étudié.

Mais, car il y a un mais.

Il y a 3 principaux types utilisateurs:

Les particuliers, qui ne peuvent qu'acheter,
Les professionnels acheteurs : Mécaniciens, Réparateurs Automobile dits MRA ou même une société ou une association,
Les professionnels vendeurs : les démolitions autos ( il s'agit de pièces d'occasions )
Je ne vois pas comment différencier les professionnels, à part "typer" ACTOR, car un mécanicien peut être une personne

MAGASIN n'entre pas dans ces cas...

Je vais essayer de modéliser cela en faisant encore plus abstraction du système étudié et vous le soumettre.

A vous lire,
François