Discussion :

[chesko]

Bonsoir,

Je dois réaliser une application qui doit permettre aux clients d'une société de transport d'encoder leur demande de livraison en ligne et le système se chargera du reste (si je puis dire).

Voici les données principales :

1. Dans cette application, le Client va pouvoir créer une demande de livraison, la modifier, la supprimer et la valider.
2. Il a aussi la possibilité de visualiser ses demandes en attente de validation et de gérer ses adresses.
3. Le fait qu'une demande soit validée (date de validation) permet au système d'envoyer la demande à DGC transport. Elle acquiert le statut de demande exportée.
4. Il y a lieu de distinguer 2 phases : la validation (confirmation) par l'utilisateur d'une part et l'export vers le SI de DGC d'autre part.
5. Un administrateur va pouvoir gérer les aspects administratifs (création d'utilisateur, gestion mot de passes...)
6. On souhaitera que l'application donne une estimation du coût de la livraison.
7. EXF-02 Demande de livraison Le client authentifié peut introduire une demande de livraison, la modifier et la supprimer.
8. EXF03 Validation demande de livraison Le client authentifié peut valider une demande de livraison et l'envoyer à DGC Transport.
9. LIV-RS01Demande de Livraison Le client peut enregistrer des demandes de livraisons et à chaque demande y associer un type de service parmi ceux de DGC Transport.
10. LIV-RS02 Colis Une demande de livraison se compose d’au moins un coli. Un colis a tou jours un type(boite, palette,…) et une description du contenu (commecial, courrier,...). Un colis peut bénéficier de services spéciaux ( conditionnement, contre remboursement…)
11. LIV-RS03 Courses Une demande de livraison implique plusieurs types de courses (ici un enlèvement et une livraison). Chaque course arrive à une adresse et a une personne de contact parmi les contacts du client (voir LIVRS04).
12. LIV-RS04 CIF Contact Un contact renseigné pour une course d’une demande de livraison doit appartenir au client qui enregistre la demande de livraison.
13. LIV-RS05 Client-Adresse Afin de faciliter l'utilisation, le Client peut conserver des adresses qu’il a utilisé pour des demandes antérieures( demandes validées), et les réutiliser.

Voici le schéma que j'ai pu sortir ( malheureusement avecmon outil , je ne sais pas représenter les CIF : inclusion, etc.. ) :
(voir attachements)

Mes questions sont les suivantes :

1. Quels corrections puis-je apporter à mon schéma ?
2. Comment gérer correctement les contraintes et les associations (1,n)---relation---(0,n) ?

Voila pour commencer.

J'utilise un DB mysql / InnoDB avec les clef étrangères, et quelques triggers, mais je coince sur ces relations (1,n)(1,1).

Et pour la relation "necessiter course" qu'est ce qui est mieux lors du MLD?

Ceci :
necessiter_course(demande_ID, type_cse_ID, #contact_ID , #adr_ID, remarque)

ce qui reviendrait à avoir une table d'entité et non plus une association.
ou ceci:
necessiter_course(demande_ID, type_cse_ID, contact_ID , adr_ID, remarque)

avec un index UNIQUE sur (demande_ID,type_cse_ID) afin de garantir une demande par type de course.

Ce qui correspond à mon schéma, mais oblige la présence des 4 clef étrangères dans ma clé primaire composite.

Ce qui me chiffonne c'est qu'il avait été question de permettre à l'utilisateur de compléter sa demande de livraison au fur et à mesure... et même de pouvoir pré-encoder (préparer) ses demandes avec certaines infos : (adresse, ou info colis ou contacts, et ce pour l'une des deux courses ou les deux).

Qu'est ce qui est plus correct? plus robuste, plus évolutif... ?

Vos commentaires et conseils seront précieux.

Merci

[chesko]

Suite aux lectures de quelques sujets du forum, j'en arrive à la conclusion que mon schéma ne garantis pas

1. Que 1 contact (P1) du Client (C1) ne soit pas associé à une demande du client (C2)
2. Qu'une adresse que je considère comme reliée à un client, ne soit pas utilisée par un autre client

Le fait qu'un client puisse gérer ses adresses et donc modifier, corriger (sous certaines conditions)... m'amène à penser ces adresses comme SES adresses.

Tout comme pour SES contacts ( ça c'était plus clair pour moi )

Voici une partie de cette association 4ternaire avec quelques compléments :


Avec CIF1 : Une adresse associée à une course doit obligatoirement appartenir au client qui enregistre la demande associée

CIF2 : Un contact renseigné pour une course doit obligatoirement appartenir au client qui enregistre la demande associée



Qu'en pensez-vous? Est-ce suffisant? Comment mettre ça en forme en MLD?

Dans mes CIF, je parle du Client(0,n) qui enregistre la demande (1,1), qui elle même (1,n) entraine les courses; est ce que client_ID peut faire partie de la clef primaire dans course?


aarrrgh trop de questions...

Merci pour votre lecture...

Chesko

[fsmrel]

Bonsoir Chesko,

D’après ce que vous écrivez, la demande du client fait référence à l’un de ses contacts pour l’enlèvement et à un autre pour la livraison, même principe en ce qui concerne l’adresse d’enlèvement et celle de la livraison.

Question :

Y-a-t-il d’autres types de courses que l’enlèvement et la livraison ?

Et pour la relation "necessiter course" qu'est ce qui est mieux lors du MLD?

Ceci :
necessiter_course(demande_ID, type_cse_ID, #contact_ID , #adr_ID, remarque)

ce qui reviendrait à avoir une table d'entité et non plus une association.
ou ceci:
necessiter_course(demande_ID, type_cse_ID, contact_ID , adr_ID, remarque)

avec un index UNIQUE sur (demande_ID,type_cse_ID) afin de garantir une demande par type de course.

Ce qui correspond à mon schéma, mais oblige la présence des 4 clef étrangères dans ma clé primaire composite.

Hum...

Au niveau du MLD, il n’y a plus de notion d’entité ou d’association, il n’y a que des tables : parler de table d’entité est donc hors de propos. Quoi qu’il en soit, la clé K de la table NECESSITER_COURSE est représentée par la paire {demande_ID, type_cse_ID}. Le quadruplet {demande_ID, type_cse_ID, contact ID, adr_ID} n’est qu’une surclé car surensemble strict de K. Avec votre SGBD, cela revient à coder « PRIMARY KEY (demande_ID, type_cse_ID) ».

Quant aux 4 clés étrangères, vous n’y couperez pas, mais ça n’est pas un problème.


Pour mettre en oeuvre les contraintes d’inclusion, toujours au niveau MLD on peut représenter les choses ainsi (avec MySQL Workbench en l’occurrence) :




Vous noterez l’utilisation de l’identification relative (par le truchement des liens identifiants), permettant de propager l’attribut ClientId depuis CLIENT jusqu’à NECESSITER_COURSE via DEMANDE_LIVRAISON, puis de garantir la contrainte selon laquelle le client de la demande est celui auquel appartiennent le contact et l’adresse impliqués.

Code SQL correspondant, histoire de fixer les idées :

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
CREATE TABLE CLIENT (
  ClientId       INT               NOT NULL,
  Etc            VARCHAR(45)       NOT NULL,
  PRIMARY KEY (ClientId))
;
CREATE TABLE CONTACT (
  ClientId       INT               NOT NULL,
  NoOrdreContact INT               NOT NULL,
  Etc            VARCHAR(45)       NOT NULL,
  PRIMARY KEY (ClientId, NoOrdreContact),
  FOREIGN KEY (ClientId)
    REFERENCES CLIENT (ClientId)
    ON DELETE CASCADE)
;
CREATE TABLE ADRESSE (
  ClientId       INT               NOT NULL,
  NoOrdreAdresse INT               NOT NULL,
  Etc            VARCHAR(45)       NOT NULL,
  PRIMARY KEY (ClientId, NoOrdreAdresse),
  FOREIGN KEY (ClientId)
    REFERENCES CLIENT (ClientId)
    ON DELETE CASCADE)
;
CREATE TABLE TYPE_COURSE (
  TypeCseId      INT               NOT NULL,
  Etc            VARCHAR(45)       NOT NULL,
  PRIMARY KEY (TypeCseId))
;
CREATE TABLE DEMANDE_LIVRAISON (
  ClientId       INT               NOT NULL,
  NoOrdreDemande INT               NOT NULL,
  Etc            VARCHAR(45)       NOT NULL,
  PRIMARY KEY (ClientId, NoOrdreDemande),
  FOREIGN KEY (ClientId)
    REFERENCES CLIENT (ClientId)
    ON DELETE NO ACTION)
;
CREATE  TABLE NECESSITER_COURSE (
  ClientId       INT               NOT NULL,
  NoOrdreDemande INT               NOT NULL,
  TypeCseId      INT               NOT NULL,
  NoOrdreContact INT               NOT NULL,
  NoOrdreAdresse INT               NOT NULL,
  PRIMARY KEY (ClientId, NoOrdreDemande, TypeCseId),
  FOREIGN KEY (ClientId, NoOrdreDemande)
    REFERENCES DEMANDE_LIVRAISON (ClientId, NoOrdreDemande)
    ON DELETE CASCADE,
  FOREIGN KEY (TypeCseId)
    REFERENCES TYPE_COURSE (TypeCseId)
    ON DELETE NO ACTION,
  FOREIGN KEY (ClientId, NoOrdreContact)
    REFERENCES CONTACT (ClientId, NoOrdreContact)
    ON DELETE NO ACTION,
  FOREIGN KEY (ClientId, NoOrdreAdresse)
    REFERENCES ADRESSE (ClientId, NoOrdreAdresse)
    ON DELETE NO ACTION)
;

[chesko]

Bonsoir Fsmrel

D'abord merci pour le temps consacré à me répondre

Y-a-t-il d’autres types de courses que l’enlèvement et la livraison ?

Non, en ce qui concerne la partie modélisée ici à savoir l'enregistrement en ligne d'une demande de livraison.

Ce que vous me proposez confirme bien ce que je présentais comme solution pour la modélisation des courses/adresses/contact.
Si ce n'est que j'étais parti pour mettre des triggers BEFORE INSERT, UPDATE sur la table de jointure NECESSITER_COURSE. Bref du bonheur!

L'identifiant relatif c'est ce que j'essayais de mettre en place ( sans succès ) avec le tuto de cyril-gruau http://cyril-gruau.developpez.com/merise/#LVI-B
J'ai du m'enmeller les pinceaux avec MySql et l'ordre des index .

J'ai une autre question existentielle concernant la relation ( ou la non relation) entre l'entité Demande Livraison et l'association quaternaire necessiter course :
Est-ce que mon 1-n est bien justifié?

A un état final (idéal), une demande de livraison nécessite 2 courses (enlèvement et livraison) arrivant chacune à une adresse et renseignant un contact. OK

Mais avec mon (1,n) lors du passage au MLD ou plutot au MPD je devrais mettre en place un mécanisme pour créer (au moins) une course (revoila le trigger).

Ne devrais-je pas créer 2 courses directement avec les 2 types?
Mais alors vient le problème des clé étrangères #Contact_ID, #Adresse_ID que je ne peux laisser à NULL !

N'est-ce pas mieux de mettre cette cardinalité à (0,N) ?:
Demande Livraison---(0,n)------------ necessiter course

Qu'en pensez-vous? est-ce permis d'être 'permissif' à cet endroit?



Avez-vous relevé d'autres anomalies sur le schéma ?

Merci pour vos réponses

[chesko]

Bonjour,

J'ai vraiment besoin d'un avis exterieur car ça fait quelques jours que j'ai le nez deans ce schema et j'ai peur d'oublier qualque chose.

Les conseils de FSMRL m'on bien aidés . Merci à vous.

Voici les 2 schémas :
MCD:

MLD:


J'ai identifié quelques triggers sur :

1. Sur les tables th_admin et th_client : afin d'éviter d'avoir un utilisateur qui joue les 2 roles à la fois ( ma partition sur l'héritage).
2. Sur te_demande_livraison pour gérer mon (1,N) et créer un colis, et mon (1,n) et créer une course (là ça coincera selon moi! j'y reviendrai + tard)
   
3. Sur te_colis afin d'empêcher de supprimer le seul (dernier) colis d'une demande de livraison.
   
4. Sur tj_effectuer_course... mmm j'ai oublié de les enlever ceux là, je n'en ai plus besoin . La règle selon laquelle une course ne doit rassembler que un contact et une adresse du client qui crée la demande associée aété gérée par l'intégrité référentielle grâce à l'identification relative etc...
   
5. Sur tj_conserver_adresse afin de garantir qu'on ne conserve que des adresses ayant déjà fait l'objet d'une course. (je devrais affiner et voir si je peux pousser le vice à ne le permettre que si la demande a été validée comme complète et recevable)
   
6. idem pour conserver contact.

Voyez vous d'autres cas à traiter? est-ce valable de traiter ceux ci?

Si vous ne voyez pas trop d'incohérences ou grosses lacunes dans ce schéma, on peut passer à la normalisation.

J'aimerai arriver à la 3e forme ou à la BCNF si possible.

Je ne suis pas sure d'avoir tout bien compris :

Par exemple dans mon MLD vous observez qu'il y a tout une série de tables de references (tr_type_course, tr_type colis...) dans lesquelles une série de champs se répètent :

• code
• libelle
• description
• rang
• base

Pensez-vous qu'il soit plus judicieux de rassembler ces champs dans une table ?
Et quelle relation entretenir alors entre les tables ? spécialisation ou association?

Qu'en pensez-vous?


PS: je repense encore à ce (1,n):

Demande_Livraison (1,n)------effectuer_course

ça me tente vraiment de le passer à (0,n), ça diminuerai le couplage fort qu'il y a entre demandeLivraison / colis / et la grappe Adresse,Contact,Type course.

En fait j'aimerai bien libérer Adresses et Contact aussi : transformer effectuer_course en une entité Course avec des associations entre Course et Adresse, Course et Contact, course et type:
Course(0,1)---renseigner----(0,n)Adresse,
Course(0,1)---renseigner2----(0,n)Contact,
Course(1,1)---etre----(0,n)typeCourse

Et il y aurait pas mal de NULL dans Course... mais cela permettrait à l'utilisateur d'ajouter des éléments à sa demande de livraison au gré de ses passages sur l'application. Il ne sera plus obligé de tout choisir d'un coup. Il pourra introduire les infos de l'enlèvement même s'il n'a pas le nom du contact... ou bien renseigner les adresses , mais pas encore les colis...

Bon, je passe trop de temps à tourner tout ça, et je craque un peu... mais si quelqu'un peut m'aider et couper court à tout ça ou bien valider cette piste ça m'aiderai... beaucoup.

Bien à vous .

Chesko

[fsmrel]

Bonjour Chesko,

J'ai vraiment besoin d'un avis exterieur car ça fait quelques jours que j'ai le nez deans ce schema et j'ai peur d'oublier qualque chose

On va s’en occuper, mais soyez patient, car il y a de la matière et personne ne peut vous consacrer tout son temps...

[fsmrel]

Bonsoir Chesko,



A propos du code SQL généré (cf. mon message précédent) : j’ai modifié l’ordre des attributs dans les clés étrangères de la table DEMANDE_LIVRAISON car MySQL Workbench se mélange un peu les pinceaux lors de la production du code...


Pour en venir à votre modélisation, il y a plein de choses à dire.


Associations n-aires (n > 2)

Je pense qu’une mise au point à propos des associations n-aires n’est pas inutile. Vous écrivez :

Voici une partie de cette association 4ternaire

Indépendamment du fait qu’une adresse et un contact doivent être en relation avec le client qui est à l’origine de la demande, il n’y a pas de relation particulière, de contrainte, entre un contact et une adresse, autrement dit votre quaternaire NECESSITER_COURSE est l’amalgame (en fait le produit) de deux ternaires, affublées chacune d'une CIF pour assurer les contraintes :

DEMANDE_LIVRAISON X TYPE_COURSE -> CONTACT,
DEMANDE_LIVRAISON X TYPE_COURSE -> ADRESSE.

Ternaire pour les contacts


Ternaire pour les adresses


A défaut, si la dérivation du MCD en MLD produit la clé suivante pour la table NECESSITER_COURSE :

{demande_ID, type_cse_ID, contact_ID, adr_ID}

Alors cette table (ou plutôt sa projection {demande_ID, type_cse_ID, contact_ID, adr_ID}, du fait de la présence précoce et perturbante de l’attribut Remarque) n’est pas en quatrième forme normale (4FN ou 4NF), ce qui est pour le moins peccamineux...

Je rappelle par ailleurs qu’une association-type n’a pas d’identifiant propre (cf. l’ouvrage de référence : Ingénierie des systèmes d’information Merise, de Dominique Nanci et Bernard Espinasse) ; J’observe toutefois que l’outil que vous utilisez passe manifestement outre et permet de définir un identifiant d’association-type (donc la clé dune table dérivée d’une association-type), cas par exemple de NECESSITER_COURSE :

id : TYPE COURSE, DEMANDE LIVRAISON.

C’est une façon intéressante de mettre en œuvre des CIF sans surcharger les diagrammes des dessins encombrants du genre de ceux que j’ai fait figurer. Mais il faut être conscient que la règle merisienne qui veut qu’une association-type n’ait pas d’identifiant propre en prend un sacré coup (ce qui personnellement ne me gêne du reste aucunement...)

On peut aussi éviter la surcharge des MCD en utilisant une représentation alternative pour les CIF. Par exemple, pour les contacts :


Mais dans votre cas ne pourrait-on pas se dispenser des ternaires ? Ça devrait pouvoir se faire. Je vous cite :

A un état final (idéal), une demande de livraison nécessite 2 courses (enlèvement et livraison) arrivant chacune à une adresse et renseignant un contact.

Si donc une demande fait l’objet d’un (et un seul) enlèvement, ainsi que d’une (et une seule) livraison, on peut représenter les choses ainsi au niveau MLD (pour des raisons de lisibilité, j’ai mis en œuvre deux vues au sens Workbench, une pour les enlèvements et une pour les livraisons) :


Dans l’exemple, la demande <C01, 1> du client <C01> fait l’objet de l’enlèvement <C01, 1> en relation avec le contact <C01, 1> et l’adresse <C01, 1>, tandis que cette demande fait l’objet de la livraison <C01, 1> en relation avec le contact <C01, 2> et l’adresse <C01, 2>.

Au besoin, pour voir comment mettre des vues en œuvre, voyez par exemple ici (y rechercher la phrase « Attention, le diagramme tend vers l’illisible »).


A propos de la cardinalité 1-n

Est-ce que mon 1-n est bien justifié?

Oui, dans la mesure où vous modélisez la finalité, le quoi, indépendamment des contraintes techniques imposées par les SGBD ou vos propres contraintes de saisie des données ; 1-n veut dire qu’en face d’une demande de livraison il doit y avoir au moins une course. Au niveau opérationnel, le respect de cette contrainte peut être sous-traité au SGBD si celui-ci en a les capacités, sinon ça sera par programmation.

Reprenons maintenant le MLD ci-dessus. Selon les cardinalités de l’association entre DEMANDE et ENLEVEMENT, une demande peut exister dans la base de données sans enlèvement, ce qui est contraire à la finalité. Pour respecter l’idéal que vous vous êtes fixé, si au moment où l'on crée une demande on est censé disposer aussi de toutes les données relatives à l’enlèvement, alors il en résulte une contrainte forte, qui se traduit par une bijection entre les deux tables, auquel cas la table ENLEVEMENT pourrait disparaître et ses attributs être absorbés par la table DEMANDE ; si l’idéal n’est pas atteignable, on en reste à la modélisation ci-dessus. Toutes choses égales, ce qui vaut pour la table ENLEVEMENT vaut pour la table LIVRAISON.


Je vais regarder les autres problèmes qui vous préoccupent...

Attention aux marques NULL : comme aime à le rappeler CinePhil, je tire à vue sur ces bêtes-là...

[chesko]

Bonjour FSMREL

Alors cette table (ou plutôt sa projection {demande_ID, type_cse_ID, contact_ID, adr_ID}, du fait de la présence précoce et perturbante de l’attribut Remarque) n’est pas en quatrième forme normale (4FN ou 4NF), ce qui est pour le moins peccamineux...

Je rappelle par ailleurs qu’une association-type n’a pas d’identifiant propre (cf. l’ouvrage de référence : Ingénierie des systèmes d’information Merise, de Dominique Nanci et Bernard Espinasse) ; J’observe toutefois que l’outil que vous utilisez passe manifestement outre et permet de définir un identifiant d’association-type (donc la clé dune table dérivée d’une association-type), cas par exemple de NECESSITER_COURSE :

id : TYPE COURSE, DEMANDE LIVRAISON.

Tout à fait d'accord, j'avais ajouter cela pour ne pas oublier les dépendances fonctionelles. Mon outil (DB-main) ne me permettant pas de le montrer... ou bien je ne sais pas comment.

Peccamineux! mea culpa ! waw quel adjectif!

Au fait vous utilisez quoi pour générer des schémas si clair? ( est ce gratuit ou en open source?)

On peut aussi éviter la surcharge des MCD en utilisant une représentation alternative pour les CIF

Oui en effet, je propose ce shema ci :

Avec la particularité qu'une demande puisse ne pas (encore) avoir de course.
Question:
Que mettre dans mon rond orange pour exprimer que si une demande est associée à un contact dans le cadre d'un type de course, elle doit aussi avoir une adresse. Est ce l'inclusion ou la simultanéité? Il manque peut-être une flèche.?

Qu'en pensez-vous?

Mais dans votre cas ne pourrait-on pas se dispenser des ternaires ?

Intéressant que vous me proposiez ça, c'est une possibilité que j'avais eu au tout début. et ça me dérangeait d'avoir 2 tables (ENLEVEMENT, LIVRAISON) avec des champs quasi identiques (même si la signification diffère un tout petit peu )

Ce qui m'embétais aussi c'est qu'au niveau MCD j'avais 2 associations ternaires.
comment j'y arrivait à ce ternaires? j'avais une entité ENLEVEMENT qui étant déjà une entité faible car n'existant que par la DEMANDE, elle n'avait que des associations (1,n) autour d'elle.:

ENLEVEMENT(1,1)---concerner---(0,n)DEMANDE
ENLEVEMENT(1,1)---avoir---(0,n)CONTACT
ENLEVEMENT(1,1)---avoir---(0,n)ADRESSE

Ce qui m'a amené à la transformer en association ternaire...

Mais j'avoue que le fait que CONTACT et ADRESSE n'aie pas vraiment de raison (fonctionelle) d'être liés m'avait échappé.
Si ce n'est à cause, dans le contexte d'un ENLEVEMENT ou LIVRAISON.

Reprenons maintenant le MLD ci-dessus. Selon les cardinalités de l’association entre DEMANDE et ENLEVEMENT, une demande peut exister dans la base de données sans enlèvement, ce qui est contraire à la finalité. Pour respecter l’idéal que vous vous êtes fixé, si au moment où l'on crée une demande on est censé disposer aussi de toutes les données relatives à l’enlèvement, alors il en résulte une contrainte forte, qui se traduit par une bijection entre les deux tables, auquel cas la table ENLEVEMENT pourrait disparaître et ses attributs être absorbés par la table DEMANDE ; si l’idéal n’est pas atteignable, on en reste à la modélisation ci-dessus. Toutes choses égales, ce qui vaut pour la table ENLEVEMENT vaut pour la table LIVRAISON.

En fait j'aimerai permettre à l'utilisateur de préparer sa demande de livraison et de pouvoir la compléter en plusieurs étapes.
Par exemple:

• Infos Colis
• Infos Expediteur :Adresse/Contact (ENLEVEMENT)
• Infos Destinataire :Adresse/Contact (LIVRAISON)

Et de pouvoir pré-encoder certaines parties et les valider une fois complétées.

Je comprends bien le lien fort entre DEMMANDE ENLEVEMENT LIVRAISON, mais avoir une grosse table DEMANDE ne me plait pas beaucoup.

Juste pour rappel, mon application n'est pas et ne sera pas le S.I. de la société de transport elle meme, mais bien une interface de saisie des demandes de livraisons. (la plus robuste et la plus flexible aussi, on peut rêver...héhé )


Merci pour ces commentaires, cela me donne des perspectives nouvelles.

J'attends vos message avec impatience (et bien sûr je cogite et me documente en parralelle)

Bien à vous.

chesko

[fsmrel]

Bonsoir Chesko,

Que mettre dans mon rond orange pour exprimer que si une demande est associée à un contact dans le cadre d'un type de course, elle doit aussi avoir une adresse. Est ce l'inclusion ou la simultanéité? Il manque peut-être une flèche.?

Par référence à l’ouvrage de Nanci et Lespinasse que j’ai mentionné précédemment, puisque pour une demande il y a à la fois un contact et une adresse, on va dire qu’il s’agit d’une contrainte de simultanéité (les pointes de flèche sont inutiles, mais il faut ajouter les cardinalités omises) :


Mais selon cette représentation, au vu des cardinalités maximales, une demande peut faire l’objet de plusieurs contacts (et d’autant d’adresses).

j'avais une entité ENLEVEMENT qui étant déjà une entité faible car n'existant que par la DEMANDE, elle n'avait que des associations (1,n) autour d'elle.:

ENLEVEMENT(1,1)---concerner---(0,n)DEMANDE

Mais dans ces conditions, pour une demande on pouvait avoir plusieurs enlèvements.

En fait j'aimerai permettre à l'utilisateur de préparer sa demande de livraison et de pouvoir la compléter en plusieurs étapes.
Par exemple:

• Infos Colis
• Infos Expediteur :Adresse/Contact (ENLEVEMENT)
• Infos Destinataire :Adresse/Contact (LIVRAISON)

Et de pouvoir pré-encoder certaines parties et les valider une fois complétées.
Je comprends bien le lien fort entre DEMMANDE ENLEVEMENT LIVRAISON, mais avoir une grosse table DEMANDE ne me plait pas beaucoup.

Pas d’objection. Dans la mesure où l’utilisateur complète en plusieurs étapes, la bijection ne se justifie pas, entre DEMANDE et ENLEVEMENT il y a seulement injection.

vous utilisez quoi pour générer des schémas si clair?

J’utilise les vues de MySQL Workbench, je les retouche avec MS Paint pour les fignolages...

Par exemple dans mon MLD vous observez qu'il y a tout une série de tables de references (tr_type_course, tr_type colis...) dans lesquelles une série de champs se répètent :

• code
• libelle
• description
• rang
• base

Pensez-vous qu'il soit plus judicieux de rassembler ces champs dans une table ?
Et quelle relation entretenir alors entre les tables ? spécialisation ou association?

Si pour les entités-types TYPE_COURSE, TYPE_COLIS, etc., les attributs que vous énumérez sont sujets à une gestion commune : leur typage, les contraintes dont ils doivent faire l’objet, vous pouvez envisager de regrouper ces attributs dans une nouvelle entité-type, nommée par exemple TYPE_GENERIQUE. Si par ailleurs vous sentez que cette entité-type représente la généralisation des autres entités-types, allez-y pour en faire un surtype ; si vous préférez la technique de l’association, pas de problème, car au niveau MLD le résultat sera le même...


Votre MLD est à revoir quant aux cardinalités. Par exemple, pour signifier qu’un utilisateur peut être un admin (ou un client), qu’un admin est toujours un utilisateur (même chose pour le client), on représente ainsi les choses :

Alors que si l’on vous suit, un utilisateur est en relation avec au moins un admin et un client...

Et profitez-en pour urbaniser, votre MLD est difficile à consulter. Pour cela utilisez des vues comme je vous l’ai suggéré précédemment.

Pour alléger un peu, vous pouvez utiliser la notation simplifiée de Workbench :


Concernant Workbench plus généralement, voyez chez jogodepau.


Question :

A quoi servent les associations Conserver_Contact et Conserver_Adresse ?

[chesko]

Merci pour ces commentaires,

on va dire qu’il s’agit d’une contrainte de simultanéité (les pointes de flèche sont inutiles, mais il faut ajouter les cardinalités omises) :

Effectivement j'avais oublié.

finalement, j'ai poussé ma réflexion et j'ai juste gardé deux associations
RenseignerAdresse et RenseignerContact ayant chacune une DF avec (Demande,TypedeCourse) sur Contact et Adresse respectivement.

Ainsi mes entités sont de vrai entités et j'evite d'avoir des NULLS (puisque je veux permettre de compléter la demande de livraison au fur et à mesure)
.

Quand il y a quelque chose (une association) j'ai un enregistrement...

et l'identification relative me permet de guarantir que j'associe un Contact du client.... etc

et l'index Unique sur (DemandeID,TypedeCourseID) vérifie la dépendance fonctionelle .

Voici les shémas MCD et MLD:




et :



Qu'en pensez-vous?

Concernant votre question :

Question :

A quoi servent les associations Conserver_Contact et Conserver_Adresse ?

Je souhaite que le client puisse conserver (marquer) certains contacts et certaines adresse afin de les sélectionner dans une liste de Favoris .
Un peu comme dans les applications d'opération bancaire on line.

Je pourrais simplement récupérer cette liste dans COntact ou Adresse directement, mais pour certains clients tres actifs cela risque de devenir long...

A ce sujet il y a aussi une contrainte que j'ajoute c'est que ce soit une adresse qui a déjà été utilisée pour une demande de livraison qui a été validée.
Mais là, je ne vois pas comment vérifier ça dans mon modèle , je m'en remets donc à un trigger lors de l'insertion pour vérifier :
s'il existe une demande associée à ce Contact ou cette adresse qui a une date de validation ou une date d'export dans ses attributs.




Est-ce que ça peut faire l'affaire ?

Merci pour votre dévouement... vous nous faite grandir !

Chesko

[fsmrel]

Bonsoir Chesko,

finalement, j'ai poussé ma réflexion et j'ai juste gardé deux associations
RenseignerAdresse et RenseignerContact ayant chacune une DF avec (Demande,TypedeCourse) sur Contact et Adresse respectivement.

Il en ressort qu’au lieu des deux règles :

1) Pour une demande on a exactement un enlèvement, un contact et une adresse d’enlèvement ;

2) Pour une demande on a exactement une livraison, un contact et une adresse de livraison ;

Vous préférez ceci :

Pour une demande et une adresse on peut avoir plusieurs types de courses ; même principe pour une demande et un contact.

Autrement dit, pour une demande et une adresse (idem pour un contact, toutes choses égales), au lieu d’avoir soit un enlèvement soit une livraison, vous préférez pouvoir avoir N types de courses. Hum...

et l'index Unique sur (DemandeID,TypedeCourseID) vérifie la dépendance fonctionnelle

Il serait préférable de parler d’identifiant alternatif au niveau conceptuel et de clé candidate au niveau logique (orienté relationnel). Le terme « index » est réservé pour le niveau physique, un index est un mécanisme d’accès qui s’oppose au mécanisme de balayage séquentiel des pages des fichiers hébergeant les données. Vous me direz que MySQL utilise le terme « index » au niveau logique, mais c’est une erreur (au sens de la norme SQL).

Je pourrais simplement récupérer cette liste dans Contact ou Adresse directement, mais pour certains clients très actifs cela risque de devenir long...

Ceci est subjectif et il est préférable de ne pas modéliser à l’émotion. Procéder rationnellement consiste à prototyper les performances des requêtes en cause. Si d’aventure le prototype montre que la mise en œuvre d’une table ADRESSE_CONSERVEE s’impose, la modélisation devrait être la suivante :


Pour mémoire, avec DB-MAIN (que je ne connais que modérément), la modélisation correspondante pourrait ressembler à quelque chose comme cela :

A ce sujet il y a aussi une contrainte que j'ajoute c'est que ce soit une adresse qui a déjà été utilisée pour une demande de livraison qui a été validée.
Mais là, je ne vois pas comment vérifier ça dans mon modèle , je m'en remets donc à un trigger lors de l'insertion pour vérifier :
s'il existe une demande associée à ce Contact ou cette adresse qui a une date de validation ou une date d'export dans ses attributs.

Une idée à creuser... En ce qui concerne la validation, vous pourriez procéder à une sorte de spécialisation des demandes : celles qui sont validées et celles qui ne le sont pas (ne serait-ce que pour éviter la marque NULL pour l’attribut ValidationDate). Il ne reste plus alors qu’à mettre en relation les demandes validées et les adresses conservées :



Concernant votre MLD (Workbench), je réitère les remarques que je vous ai faites dans mon précédent message : les cardinalités sont erronées. Dans le même sens, je fais observer une fois de plus que les marques NULL sont à éliminer (je l’avais écrit en rouge...)

[chesko]

Bonjour Fsmrel,

Merci, je vais réfléchir sur tes commentaires et je reviens...

Bonne journée