Discussion :

[0redd]

Bonsoir, J'ai réaliser un mcd de gestion de factures et je me suis aperçu qu'il y'avait un problème,
Afficher MCD
Normalement , une commande ne doit concerner qu'un seul marché, or dans mon mcd, je pourrai avoir une commande qui concerne plusieurs marchés, comment faire pour integrer cette contrainte? et merci d'avance

[seabs]

Bonjour,

Pour éviter le risque invoqué, il faut donc identifier Commande relativement au Marché. En pratique, il convient de traiter la commande comme une entité faible dépendante de l'entité forte marché.

Va voir cette discussion, elle devrait t'aider.

http://www.developpez.net/forums/d90...e-facturation/

Personnellement, j'aurais quelques difficultés à t'expliquer cela clairement.

Mais, je pense que @fsmrel ou @CinePhil prendront part à cette discussion et ils t'expliqueront tout cela en "deux temps trois mouvements".

D'autre part, je ne suis pas certain que ton MCD soit correctement conçu, il faudrait les règles de gestion pour apprécier. Mais, à titre d'exemple, je pense que les lignes de commande dépendent de la commande et non pas l'inverse.

De même, la commande ne devrait-elle pas découler directement du marché.

Je pense qu'il convient de réfléchir et de travailler ton MCD.

Bon courage en attendant mieux.

A+

[fsmrel]

Bonsoir,


@ 0redd

Qu’est-ce qu’’un marché ?
Qu’est-ce qu’une tache (tâche) ?
En vertu de quelle subtilité, contrairement à da situation classique, la commande n’est-elle pas en relation avec le client ?
Votre diagramme conceptuel est sec, merci d’y mettre un peu de rhum et de sémantique, de raconter ce dont il s’agit, bref de fournir et justifier l’ensemble des règles de gestion, en les commentant soigneusement (par exemple pourquoi la relation entre tache et ligne de commande).


@ seabs

Les lignes de commande dépendent bien de la commande. L’un de nous deux aurait-il abusé du rhum ?

[0redd]

Bonsoir et merci pour vos réponses ^^

@seabs
Oui vous avez raison, je dois mettre l'entité commande comme une entité faible dépendante de l'entité forte marché.
Mais même en faisant cela, rien ne me garanti que toutes les lignes de commandes d'une commande x, concerneraient des tâches d'un est d'un seul marché.

@fsmrel
Au fait , les entités marché et tâche sont des références ( les données qui sont fournies par le client ).
Par exemple une entreprise a 1 marché ( Réalisation d'une application de Gestion de paie par exemple ),
et ce marché contient des tâches :

1. Conception et génération de la base de donnée
2. Réalisation de la Charte Graphique
3. Réalisation de l'application

pourquoi la commande n’est-elle pas en relation avec le client,
bein si une commande concerne un seul marché, c'est qu'elle concerne un seul client,au fait j'avais oublié de mettre la relation entre les 2 entités, devrai-je ?

pourquoi la relation entre tâche et ligne de commande, parce qu'une ligne de commande contient les infos sur le prix, durée de réalisation de cette tache.

j'espère n'avoir oublié aucun point, et merci d'avance pour votre aide

[fsmrel]

Bonsoir,


Merci pour les exemples, on y voit plus clair.

Une commande ne doit concerner qu'un seul marché.

Étant donné qu’une commande concerne exactement un marché, on peut s’orienter vers la mise en relation des deux entités-types MARCHE et COMMANDE (on suppose ici qu’un marché peut donner lieu à plusieurs commandes). Une commande est une propriété (multivaluée) d’un client, la relation entre CLIENT et COMMANDE peut donc être une relation de composition, cela se traduit dans le diagramme par l’identification relative de COMMANDE par rapport à CLIENT. Même principe : on identifie LIGNE_COMMANDE relativement à COMMANDE.

Pour exprimer la règle selon laquelle le client de la commande est celui du marché, on peut mettre en œuvre une contrainte d’inclusion au sens de Merise 2. Bien sûr, comme on utilise Power AMC, on devra intervenir manuellement au stade du MLD pour assurer cette contrainte (ce qui entraîne l’identification relative de MARCHE par rapport à CLIENT, sinon on serait bon pour un trigger au stade SQL, c'est vous qui voyez... )

Un MCD :




MLD correspondant :



Comme à une tâche correspond au plus une ligne de commande, en plus de la clé primaire {NumClient, NumCde, NumLigneCde}, la table LIGNE_COMMANDE est dotée d’une clé alternative {NumClient, NumMarche, NumTache}.

N.B. Si d’aventure à un marché correspondait au plus une commande, la paire {NumClient, NumMarche} deviendrait clé alternative de la table COMMANDE.

MLD correspondant :

je pense que @fsmrel ou @CinePhil [...] en "deux temps trois mouvements".

Euh ? En deux coups les gros ? On n'est quand même pas des magiciens, c'est pas du billard...
On a quand même essayé d'aborder le problème par la bande...

[0redd]

Merci beaucoup pour votre aide, ça m'a beaucoup aider, mais il y'a des trucs qui m'échappent:

1)

ce qui entraîne l’identification relative de MARCHE par rapport à CLIENT...

J'ai pas très bien compris comment faire ...

2)
Vous avez mis comme clé primaire dans Ligne_Commande {NumClient, NumCde, NumLigneCde}, NumLigneCde n'est pas suffisant? De même pour les autres tables ( sauf client qui a une seul clé primaire)

3)
Une dernière petite question, j'ai l'entité Livraison qui ne contient que le champ date_livraison, ne serait t'il pas plus intéressant de mettre ce champ dans la commande? et donc de réduire le nombre de jointures? ou bien c'est mieux de garder l'entité livraison?

Faites simple, mais pas plus simple !

Est ce qu'en supprimant la table, j'essaie de faire plus simple ?

encore une fois merci

[CinePhil]

il y'a des trucs qui m'échappent:

1)

J'ai pas très bien compris comment faire ...

2)
Vous avez mis comme clé primaire dans Ligne_Commande {NumClient, NumCde, NumLigneCde}, NumLigneCde n'est pas suffisant? De même pour les autres tables ( sauf client qui a une seul clé primaire)

C'est justement ça, l'identification relative !
La ligne de commande n'est pas identifiée par un numéro allant de 1 à l'infini, quelle que soit la commande à laquelle elle se rattache, mais relativement à cette commande. Pour chaque commande, les numéros de ligne de commande repartent à 1.
C'est d'ailleurs souvent comme ça que c'est présenté dans les commandes papier si ma mémoire est bonne et si ça n'a pas changé depuis que j'ai quitté le monde des entreprises commerciales.

3)
Une dernière petite question, j'ai l'entité Livraison qui ne contient que le champ date_livraison, ne serait t'il pas plus intéressant de mettre ce champ dans la commande? et donc de réduire le nombre de jointures? ou bien c'est mieux de garder l'entité livraison?

Est ce qu'en supprimant la table, j'essaie de faire plus simple ?

S'il ne peut y avoir qu'une seule livraison pour une commande, à la rigueur mais on peuple la table des commandes du bonhomme NULL et fsmrel va troquer sa queue de billard pour une arme plus offensive !
En réalité, le cas le plus fréquent est qu'il peut y avoir plusieurs livraisons pour une commande. Il faut donc séparer ces deux concepts dans deux entités types différentes.

[fsmrel]

Bonjour 0redd,

Ce qui entraîne l’identification relative de MARCHE par rapport à CLIENT

J'ai pas très bien compris comment faire ...

Je suppose que vous voulez dire : « Je n’ai pas très bien compris comment faire avec Power AMC. »
Si tel est le cas, faites un double clic droit sur le lien qui relie MARCHE et MAR_CLI, puis vous cochez la case « Identifiant » dans la fenêtre « Propriétés du lien d’association » :

...

[fsmrel]

En complément...

Vous avez mis comme clé primaire dans Ligne_Commande {NumClient, NumCde, NumLigneCde}, NumLigneCde n'est pas suffisant ?

Si NumLigneCde est à lui seul identifiant, alors vous mettez en oeuvre l’identification absolue. CinePhil a bien expliqué cela (aussi mérite-t-il un bon point et je clique sur le pouce vert ).

La discussion avec knoxville « Définition 'lien identifiant' et 'identifiant relatif' » devrait vous apporter bon un éclairage.

Ensuite, vous pouvez méditer la discussion avec Monkeyget « Design de table, choix de clef primaire », dans laquelle je suis obligé de contredire un expert SQL, ce qui n’est pas pour déplaire à un spécialiste de DB2, qui se déclare, je cite :

« Contre la "dictature" du tout identifiant non significatif. »

Voyez aussi l’article Bases de données relationnelles et normalisation : de la première à la sixième forme normale, au paragraphe « Dénormalisation vs amélioration (optimisation) » (Note concernant l'identification relative et Conséquence de l'identification relative sur l'organisation des requêtes SQL).
Voyez aussi le paragraphe « Identification relative versus identification absolue ».