Discussion :

[trolldom]

Bonjour,
J'ai un problème de conception que je n'arrive pas à résoudre.
description du domene

• Une livraison doit avoir une adresse d' envoyeur et une adresse de receveur. Une livraison peut avoir une adresse de ramassage et une de adresse de dépose mais seulement une minorité de livraison utilisent ces adresses facultatives.
• les adresses de livraison sont des données historiques et doivent être conservées
• Je peux choisir mes adresses dans mon carnet d'adresse où celles-ci sont qualifiées (receveur, dépose, ramassage, etc) ou les renseigner à la main mais
• je veux avoir un lien vers l'adresse du carnet quand j'utilise une adresse de mon carnet.
• Les adresses dans une livraison ont toutes le même format.
• Une adresse du carnet contient toutes les infos nécessaires pour remplir une adresse de livraison.

Mon probleme est que je ne sais pas où mettre mon envoyeur et receveur. Voici quelques renseignements suplémentaires

• peu d'accés concurrent en écriture
• Application OLTP avec parfois de nombreuses insertions (du à des captures automatisées)
• Presque toute requête sur une livraison va nécessiter de connaitre les adresses associées et quand une adresse est choisie pour une livriason elle est assez stable.
• quasiment tout traitement statistique ou autre (Olap light) se fait sur des données historiques qui ne seront donc pas modifiées. si ce type de traitement devient trop contraignant il sera deplassé vers une base destinnée à l'analyse.

En pièce jointe il y a 2 modèles,

• un modele qui suit les entités de manière assez proche (j'ai regroupé les adresses de livraison donc il manque la contrainte _doit_ avoir receveur/envoyeur) - desavantage: nombreux joins pour chaque requete
• un modele qui met toutes les adresses dans la livriason, j'ai alors besoin d'un flagg pour savoir si il y a une depose/ramassage (indispensable pour d'autres raisons)
  désavantages:
  mappage dans les applications fastidieux
  nombruex DBnull
  nombreuses colones dans la table (en fait 5 entités*8 = 40 colones pour les adresses plus les autres champs ca monte autour de 55 colones)
• il manque: un modele hybride qui met les 2 adresses obligatoires dans la livraison et les facultatives dans une table. avantage: implemente la contrainte _doit_ de envoyeur/receveur, évite d'avoir de nombreuse colones nulles

Voilà, j'aimerai bien avoir des avis sur les trois solutions présentées (éventuellement aussi ds avis sur une entité = une table)

Bonne journée
dom

[trolldom]

Aide toi et le ciel t'aidera disait ma Grand-mère :-)
Bon au final je vais utilisé le modèle qui implémente les règles. Il sera toujours temps de bricoler plus tard si c'est trop ennuyeux à mapper.
La contrainte qui m'avait pertubée était qu'il devait être possible de renseigner les adresses soit depuis des registres, soit "à la main". (j'avais aussi une solution mais bon tout vient des registres finalement :-) )
J'ai "rentré" les historiques d'envoyeur et de receveur, vu que c'était des relations 1-1. De plus les requêtes vont quasiment toujours vouloir récupérer cette information et il est assez certain que l'unicité va rester.

Le diagramme (fait avec Toad mais j'ai fait un effort sur le formalisme )


Merci aux éventuels lecteurs et je suis bien sûr toujours aussi avide de commentaires.

Bon week end
Dom

[fsmrel]

Bonsoir,

Supposons qu’il existe une table CarnetAdresse, unique contenant toutes les adresses. D’après ce que vous dites, certaines adresses de ramassage et de dépose ne figurent pas nécessairement dans le carnet : dans un premier temps, pour ne pas multiplier les difficultés on admettra qu’elles y figurent quand même.

Une livraison doit avoir une adresse d' envoyeur et une adresse de receveur.

=> il doit y avoir une relation Envoi entre CarnetAdresse et Livraison, ainsi qu’une relation Reception entre ces 2 tables.

Une livraison peut avoir une adresse de ramassage et une de adresse de dépose mais seulement une minorité de livraison utilisent ces adresses facultatives.

=> Afin d’éviter la gabegie et les valeurs nulles, il est préférable de mettre en œuvre d’une table Ramassage et une table Depose qui seront de faible volumétrie et qui en proportion inverse éviteront l’obésité de la table Livraison (cf. votre table Livraison2...)

De la jointure :

Contrairement à la légende, les jointures ne coûtent pas cher si elles sont correctement prototypées : surveiller par Explain (ou instruction équivalente) que l’on n’effectue pas de produits cartésiens.
En outre, la jointure est l’opérateur relationnel par excellence, il a grandement contribué au succès des SGBDR : on doit savoir s’en servir les yeux fermés.
En outre, rien n’interdit de mettre en œuvre des vues pour encapsuler les jointures et ainsi se simplifier la vie dans l’écriture des requêtes (disons de consultation).

Une proposition :



____________________Figure 1


Code SQL correspondant (SQL Server) :

Code :

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
Create Table CarnetAdresse (
   AdrId                Int                  Not null,
   Destinataire         Varchar(38)          Not null,
   ComplementLigne2     Varchar(38)          Not null,
   ComplementLigne3     Varchar(38)          Not null,
   Voie                 Varchar(38)          Not null,
   Ligne5               Varchar(38)          Not null,
   CodePostal           Char(5)              Not null,
   Localite             Varchar(38)          Not null,
   Constraint PK_Carnetadresse Primary Key  (AdrId)
)
;

Create Table Livraison (
   LivraisonId          Int                  Not null,
   AdrEnvoiId           Int                  Not null,
   AdrReceptionId       Int                  Not null,
   LivraisonInfo        Varchar(48)          Not null,
   Constraint Livraison Primary Key  (LivraisonId),
   Constraint ReceptionAdresse Foreign Key (AdrLivraisonId)
      References CarnetAdresse (AdrId),
   Constraint EnvoiAdresse Foreign Key (AdrEnvoiId)
      References CarnetAdresse (AdrId)
)
;

Create Table Ramassage (
   LivraisonId          Int                  Not null,
   AdrId                Int                  Not null,
   Constraint Ramassage Primary Key  (LivraisonId),
   Constraint RamassageAdresse Foreign Key (AdrId)
      References CarnetAdresse (AdrId),
   Constraint RamassageLivraison Foreign Key (LivraisonId)
      References Livraison (LivraisonId)
         On Delete Cascade
)
;

Create Table Depose (
   LivraisonId          Int                  Not null,
   AdrId                Int                  Not null,
   Constraint Depose Primary Key  (LivraisonId),
   Constraint DeposeAdresse Foreign Key (AdrId)
      References CarnetAdresse (AdrId),
   Constraint DeposeLivraison Foreign Key (LivraisonId)
      References Livraison (LivraisonId)
         On Delete Cascade
)
;

Note : pour la structure des adresses, je me suis basé sur la norme AFNOR :




Variante

Pour des opérations facultatives telles que le ramassage et la dépose, vous préférerez peut-être replier le modèle et définir un type d’opération ad-hoc. Ceci est intéressant si d’autres types d’opérations de ce genre sont à prévoir.



____________________ Figure 2


Prise en compte des adresses ne figurant pas dans le carnet d’adresses

Je pense que le plus raisonnable est de demander à l’utilisateur d’enregistrer dans le carnet les adresses qui sont normalement saisies manuellement. Pour savoir si une adresse est de type carnet ou manuelle, il suffirait d’ajouter dans la table Adresse un attribut TypeAdresse, de type booléen. Après tout, une adresse saisie manuellement peut mériter un jour de figurer légalement dans le carnet : on se contente alors de basculer la valeur du booléen.

Maintenant, si vous ne souhaitez pas polluer une table stable par des données volatiles, vous pouvez remplacer CarnetAdresse par une table Adresse, à spécialiser en CarnetAdresse et AdresseManuelle, le booléen TypeAdresse permettant de connaître la nature de l’adresse en relation avec la livraison. L’ensemble des adresses peut faire l’objet d’une vue d’union des deux tables spécialisées.




____________________ Figure 3

Code :

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
 
Create Table Adresse (
   AdrId                Int                  Not null,
   TypeAdresse          Bit                  Not null,
   Constraint Adresse Primary Key  (AdrId)
) ;

Create Table CarnetAdresse (
   AdrId                Int                  Not null,
   Destinataire         Varchar(38)          Not null,
   ComplementLigne2     Varchar(38)          Not null,
   ComplementLigne3     Varchar(38)          Not null,
   Voie                 Varchar(38)          Not null,
   Ligne5               Varchar(38)          Not null,
   CodePostal           Char(5)              Not null,
   Localite             Varchar(38)          Not null,
   Constraint CarnetAdresse Primary Key  (AdrId),
   Constraint CarnetAdresse_Adresse Foreign Key (AdrId)
      References Adresse (AdrId)
         On Delete Cascade
) ;

Create Table AdresseManuelle (
   AdrId                Int                  Not null,
   Destinataire         Varchar(38)          Not null,
   ComplementLigne2     Varchar(38)          Not null,
   ComplementLigne3     Varchar(38)          Not null,
   Voie                 Varchar(38)          Not null,
   Ligne5               Varchar(38)          Not null,
   CodePostal           Char(5)              Not null,
   Localite             Varchar(38)          Not null,
   Constraint AdresseManuelle Primary Key  (AdrId),
   Constraint AdresseManuelle_Adresse Foreign Key (AdrId)
      References Adresse (AdrId)
         On Delete Cascade
) ;

Create Table Livraison (
   LivraisonId          Int                  Not null,
   AdrEnvoiId           Int                  Not null,
   AdrLivraisonId       Int                  Not null,
   LivraisonInfo        Varchar(48)          Not null,
   Constraint Livraison Primary Key  (LivraisonId),
   Constraint ReceptionAdresse Foreign Key (AdrLivraisonId)
      References Adresse (AdrId),
   Constraint EnvoiAdresse Foreign Key (AdrEnvoiId)
      References Adresse (AdrId)
) ;

Create Table TypeOperation (
   TypeOperId           Int                  Not null,
   Libelle              Varchar(48)          Not null,
   Constraint Typeoperation Primary Key  (TypeOperId)
) ;

Create Table OperationComplementaire (
   LivraisonId          Int                  Not null,
   AdrId                Int                  Not null,
   TypeOperId           Int                  Not null,
   Constraint OperationComplementaire Primary Key  (LivraisonId),
   Constraint OperationComplementaire_Adresse Foreign Key (AdrId)
      References Adresse (AdrId),
   Constraint OperationComplementaire_Livraison Foreign Key (LivraisonId)
      References Livraison (LivraisonId)
         On Delete Cascade,
   Constraint OperationComplementaire_TypeOperation Foreign Key (TypeOperId)
      References Typeoperation (TypeOperId)
) ;

Tout ceci peut être revu, aménagé et augmenté. Good luck !

[trolldom]

Bonsoir,
Merci Fsmrel pour votre réponse très complète.

La contrainte de pouvoir entrer des adresses manuellements a été, à ma plus grande joie, supprimée donc je n'aurai pas besoin d'implémenter de spécialisation comme vous l'avez élégamment proposé figure 3.

Il me semble que votre solution présentée en figure 1 correspond assez bien à la solution que j'ai présenté dans mon deuxième post (avec une petite faute d'identifiant sur les opérations complémentaires).
J'ai aussi mis les données historiques à l'intérieur des tables qui auraient donné des relations 1-1. Comme noté plus haut je suis obligé de garder trace des adresses complètes.

La différence notable est sur l'utilisation d'un unique carnet d'adresse contra l'utilisation de carnets spécialisés. La réalité du problème est que les rôles sont figés bien que tous soient des adresses et ces adresses sont relatés à 1 utlisateur. C'est pourquoi j'ai choisi d'utiliser plusieurs tables.
Ma solution actuelle est montrée plus bas.

En outre, rien n’interdit de mettre en œuvre des vues pour encapsuler les jointures et ainsi se simplifier la vie dans l’écriture des requêtes (disons de consultation).

C'est en effet la proposition que j'ai soumise.

pour la structure des adresses, je me suis basé sur la norme AFNOR

J'ai en effet simplifié la représentation des entités pour l'exposé de mon problème. Mes structures d'adresses sont en fait indirectement dictés par des standarts norvègiens .


Question subsidiaire:
une livraison passe par différents stades (2 pour l'instant mais suseptible d'évoluer) et chaque stade a quelques informations spécifiques. J'ai créé une table pour chaque état, chaque table ayant alors les informations relativs à l'état actuel.
Avez vous des commentaires sur ce choix?
le modèle d'origine (55 colones ) avait toutes ces informations dans la table Livraison (en gros le vieux modèle avait 2 tables, Livraisons et lignes et une relation non implémentée 1 - 0..n)

Merci encore pour votre contribution!

[fsmrel]

Bonsoir Dom,


Dans votre message daté du 25/05, apparaît un schéma dans lequel apparaît une table Commande :
http://home.online.no/~dominir/export_fr.png

Pourriez-vous donner la signification des différents attributs (eta, etd, xxNavnHisto).

Par ailleurs, vous y injectez des éléments d’historisation : avant de discuter de votre message du 26, pourriez-vous fournir un schéma déplié, c’est-à-dire dans lequel les données vives sont isolées des données historisées.

Concernant les techniques de modélisation de l’historisation, je vous suggère de vous pencher sur les articles suivants :

"Historiser deux entités et leurs relations" (discussion ouverte par fayred)
http://www.developpez.net/forums/sho...d.php?t=336896

puis

"Planning, dates et horaires" (discussion ouverte par fayred)
http://www.developpez.net/forums/sho...d.php?t=334343

"Modélisation gestion de projet" (discussion ouverte par sieldev)
http://www.developpez.net/forums/sho...d.php?t=342162

Bon courage...

[trolldom]

Bonsoir,

Merci de l'attention que vous portez à ce cas et milles excuses aux lecteurs pour la longueur du post.

Concernant les techniques de modélisation de l’historisation, je vous suggère de vous pencher sur les articles suivants :
[...]

Merci pour les liens, j'avais lu certaines de ces discussions où j'ai bien noté votre argument pour externisé les données aussi dans le cas de relations 1-1.
Le domaine à modéliser est très stable et je suis en grande partie contraint par des normes. C'est pourquoi j'ai choisi de "rentrer" les données historiques dans les entités "maitre" come illustrés dans les modèles du 25 et 26 mai.
Ces discussions sont par ailleurs intéressantes à lire

Dans votre message daté du 25/05, apparaît un schéma dans lequel apparaît une table Commande :
http://home.online.no/~dominir/export_fr.png

Pourriez-vous donner la signification des différents attributs (eta, etd, xxNavnHisto).

J'ai en effet été peu conséquent dans mes choix de noms qui sont traduit en francais pour ces posts. Le modèle ayant évolué j'ai modifiais les noms dans le post sans y préter garde.
xxNavnHisto: une coquille, Navn = nom
eta (resp. etd): des données relatives à un transport signifant Estimated Time Arrival (reps. Delivery). Cela peut être ignorer.
Le modèle publié le 25.05 est mis à jour sans en changer la structure.(http://home.online.no/~dominir/export_fr.png)

~Histo signifie que les xxNoms, xxAdresse, sont les valeurs enregistrées avec la commande et peuvent donc être différentes . Ces valeurs sont figées quand une commande est "acceptée" par un transporteur.

Je redécrit le problème pour plus de clarté.

• L'utilisateur remplit une commande de transport.
• La commande doit avoir un envoyeur et un receveur.
• La commande peut avoir un endroit de ramassage et un endroit de dépose.
• Les contacts sont enregistrés dans un/des carnet d'adresse et il sont regroupés par type de contact.
• Pour chaque commande il doit être possible de savoir quel contact a été utilisé et quels étaient ses noms, adresses, etc quand la commande a été passée.

par ailleurs une commande a un cycle de vie. Même si il s'agit en fait d'un autre problème je note en dessous les quelques règles que j'ai.

• Une commande peut être validée, au quel cas elle ne peut plus être redigé
• Une commande qui est validée peut être "dévalidée"
• une commande peut être "acceptée" par un transporteur, il faut pour cela qu'elle soit validée. La commande ne pourra plus être modifiée.
• il pourrait y avoir d'autres états pour une commande mais c'est hypothétiques et dans un futur lointain.

Le projet a été démaré l'an dernier puis suspendu. c'est actuellement implémenté dans une table avec entre 50 et 60 colones. Je reprends le projet et ayant l'occasion de changer en partie le schema de base de donnée, j'ai envie d'amaigrir la table, d'où mes questions.
Les cas d'utilisations impliquent (presques toujours) le rapatriement de toutes les informations de la commande. (envoyeur, receveur, ...).
Un modèle sub-optimal mais facile à mapper avec un orm aura la priorité par rapport à un modèle optimal pour le moteur de base de données.

Par ailleurs, vous y injectez des éléments d’historisation : avant de discuter de votre message du 26, pourriez-vous fournir un schéma déplié, c’est-à-dire dans lequel les données vives sont isolées des données historisées.

J'espère que les explications au dessus associées au modèles suivant clarifient la situation.
Ce modèle a regroupé toutes les adresses dans un seul carnet. Je suis en fait pas convaincu qu'il ya des avantages à cette approche par rapport à avoir une table par type de contact.
Les données "historiques" sont dépliées comme réponse à votre requêtes.


Merci encore pour vos remarques :-)
Dom

[fsmrel]

Bonsoir Dom,


Ça prend de l’ampleur ! Et votre schéma a une bonne tête.

Ce modèle a regroupé toutes les adresses dans un seul carnet. Je suis en fait pas convaincu qu'il ya des avantages à cette approche par rapport à avoir une table par type de contact.

De fait, tout coller dans une seule table revient à la faire grossir, d’où des durées de tâches de service plus longues (sauvegardes, réorganisations, unload/reload, etc.) toutes tâches qui peuvent être parallélisées si les tables sont distinctes. Par ailleurs, le nombre de niveaux d’index risque d’augmenter, donc les entrées/sorties. Il faudra peut-être envisager un index supplémentaire pour accéder aux carnets par type, d’où temps de traitement de mise à jour plus long. J’en passe et des meilleures : je suis pour que les carnets soient séparés. Il y a plus de fichiers physiques à gérer, mais là n’est pas le problème. Maintenant, c’est vous qui voyez en fonction de votre approche ORM.


Concernant le cycle de vie de la commande, votre solution alternative est intéressante, pour son côté gestion du cycle de vie et le raffinement côté métabolisme (cascade à loisir, tant que la commande n’a pas été acceptée). Évidemment se pose le problème de l’introduction de nouveaux états. Cela dit, ces états demeurent hypothétiques et s’ils voient le jour, n’auront sans doute pas l’importance de ceux que vous avez mis en évidence et pourront alors faire l’objet d’une entité-type ad-hoc, qui pourrait être une association réflexive orientée cycle de vie : tel état est mémorisé après tel autre, tout cela sans avoir à mettre en œuvre de nouvelles tables. Les scénarios méritent d’être étudiés à fond et la solution retenue agréée sans trop tarder par l’utilisateur...
A voir.
En tout cas, CommandeAcceptée doit continuer à mériter tous vos soins. On sent qu'elle a une importance certaine...