Discussion :

[pims42]

Bonjour tout le monde,

Je suis entrain de créer un MCD pour mon projet en entreprise et je n'arrive pas vraiment à savoir si ce que j'ai fait est juste :

En créant certaines tables, je me suis aperçu qu'elles avaient 2 champs similaires : status et comment.
J'ai donc voulu sortir ces champs pour les mettre dans 2 tables indépendantes, et les relier à toutes les tables qui les utilisaient.

Du coup, je me retrouve avec 4 tables qui pointent vers mes nouvelles tables comment et status.

Est-ce que c'est correct?

Merci pour votre aide!

[CinePhil]

Tu n'en dis pas assez pour qu'on puisse juger de la pertinence de la chose.

Est-ce que, sémantiquement, les 4 tables sont des spécialisations de celle sur laquelle elles pointent ? Tu serais alors en présence d'un héritage de données.

Exemple...
Règles de gestion :
Une voiture est un véhicule et un véhicule peut être une voiture.
Un camion est un véhicule et un véhicule peut être un camion.

MCD :
voiture -(1,1)----être----0,1- vehicule
camion -(1,1)----être----0,1-------|

Tables :
te_vehicule_veh (veh_id, veh_immatriculation, [autres colonnes communes à tous les véhicules])
th_voiture_vtr (vtr_id_vehicule, vtr_nb_places, [autres colonnes spécifiques aux voitures])
th_camion_cam (cam_id_vehicule, cam_tonnage, [autres colonnes spécifiques aux camions])

Dans ton cas, que contiennent ces tables ?

[pims42]

Hey, merci pour ta réponse!

Concrètement, j'ai 4 tables qui contiennent des infos sur des contrats clients :
1st -> CONTRAT( id, titre,..., status,comments)
2nd -> CHAPITRE_CONTRAT (id, titre,desc,...,status,comments)
3rd -> SECTION_CLIENT (id, name, value,...,status,comments)
4th -> SECTION_STANDARD (id, ref,...,comments)

CONTRAT -1,n----a----1,1- CHAPITRE
CHAPITRE -1,n----a----1,n- SECTION_CLIENT
SECTION_CLIENT-1,n----est comparée----0,1- SECTION_STANDARD

J'ai donc voulu sortir status et comments, et en faire 2 tables indépendantes.
Mais utiliser 4 associations identiques sur 2 tables, je ne trouve pas ça très pertinent...

[pachot]

Bonjour,

J'ai donc voulu sortir ces champs pour les mettre dans 2 tables indépendantes, et les relier à toutes les tables qui les utilisaient.

Si la raison est seulement parce "les colonnes sont similaires", alors non, ce n'est pas une bonne raison. Il faut savoir si ces sont des entités indépendantes ou si c'est une information qui n'a de sens que pour une ligne d'une table.

A priori, un 'status' peut être une notion indépendante qui peut s'appliquer à plusieurs entités.

Un commentaire libre sera par contre souvent propre à un enregistrement particulier. Par contre, s'il n'est que rarement utilisé avec le reste de l'enregistrement, il peut y avoir un sens à le séparer dans le modèle physique.

Cordialement,
Franck.

[CinePhil]

Le statut est typiquement une donnée répétitive qu'il faut externaliser dans une table de référence. Attention cependant au fait que certains statuts peuvent être spécifiques aux contrats, d'autres spécifiques aux chapitres de contrats... À toi de le déterminer.

Par contre, les commentaires sont plutôt des données uniques qui sont des propriétés des entités auxquels ils se rapportent. Si le commentaire est systématiquement renseigné, le laisser dans la table du contrat, du chapitre... Si les commentaires sont rares, alors on peut aussi les externaliser dans des tables séparées commentaire_contrat, commentaire_chapitre...

[pims42]

Ok pour le status : cette table contiendra un nombre de données fixe ( agreed, in review, in negociation, obsolete, rejected). Toutes les tables citées auparavant l'utiliseront.

Mais pour les commentaires, ce n'est effectivement pas obligatoire hormis pour la table SECTION_CLIENT
Du coup, pour le status, est ce que ça se fait comme ça :



Ou alors, je fais une association relié à status pour chaque entité?

[fsmrel]

Bonsoir,

Ou alors, je fais une association relié à status pour chaque entité?

C'est au moins comme cela qu'il faut faire, sinon on lit ceci :

Un contrat a exactement un statut (c'est-à-dire au moins un et au plus un statut), un contrat a exactement un chapitre, exactement une section client, exactement une section standard, etc. On dérive vers la blijection à tous les étages.

Par ailleurs, si vous n’avez qu’une entité-type STATUT, cela veut dire que chaque valeur de statut a un sens pour chaque contrat, chaque chapitre, chaque section client et chaque section standard.

[pims42]

Ok, merci pour vos réponses!

[CinePhil]

pims , Ton schéma représente une association à 5 branches avec des cardinalités 1,1 sur 4 d'entre elles. Elle est donc fausse !

Règles de gestion :
Un contrat a un statut et un statut peut être celui d'un contrat.
Un chapitre a un statut et un statut peut être celui d'un chapitre.
Une section-client a un statut et un statut peut être celui d'une section-client.
Une section-standard a un statut et un statut peut être celui d'une section-standard.

Tu vois bien là qu'il y a 4 associations et non pas une seule !

contrat -1,1----avoir----0,n--------- statut
chapitre -1,1----avoir----0,n-------------|
section-client -1,1----avoir----0,n------|
section-standard -1,1----avoir----0,n--|