Discussion :

[Puiss51]

Bonjour,

j'ai actuellement une base de données contenant 3 entitées :

T_VERNIS avec pour PK VER_ID
T_REVETEMENT avec pour PK REV_ID (1 revetement constitué de 1 à n vernis)
T_ANALYSE avec pour PK ANA_ID (1 revetement rattaché à 0 à n analyses)

Je viens d'apprendre que mon MCD ne colle plus car certaines analyses fournies directement par le fournisseur de vernis ne concerne pas un revêtement complet mais un vernis.
Je pensais donc créer un lien entre T_ANALYSE et T_VERNIS avec pour cardinalité 1 vernis rattaché à 0 à n analyse ; créant ainsi une association ternaire. est ce correct?
question suivante : actuellement l'attribut REV_ID de mon entité T_ANALYSE est non null, dans mon nouveau MCD, il faudrait que je modifie ma contrainte pour avoir une contrainte de partition : REV_ID ou VER_ID non null mais il ne faut pas que les 2 soient non null pour une même occurence.
j'ai essayé une requete du type :

Code :

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

1
2
3
 
alter table T_ANALYSE
add constraint REV_ID not null OR VER_ID not null

mais cela ne fonctionne pas.
Merci de votre aide.

[SQLpro]

1) contrainte CHECK au niveau du MPD avec obligation de vernis ou revêtement, mais pas les deux à la fois
2) ajouter une table générique de type "surface" ou couche et gérer un héritage exclusif


A +

[Puiss51]

contrainte "CHECK" au niveau du MPD

ok donc directement dans SQL SERVER, je vais regarder l'utilisation de CHECK

ajouter une table générique de type "surface" ou couche et gérer un héritage exclusif

c'est bizarre je trouve un héritage car l'un compose l'autre. Séparer des véhicules en camion ou voiture pour séparer des attributs différents je comprends mais ici, les revêtements sont composés d'un ou plusieurs vernis.
De plus ayant commencé le développement en C# ca m'arrangerai de ne pas trop modifier le modèle ma BDD ... tu me diras je travaille principalement sur des vues donc ça devrait aller ... mais cette histoire d'héritage me laisse perplexe.

[SQLpro]

c'est bizarre je trouve un héritage car l'un compose l'autre. Séparer des véhicules en camion ou voiture pour séparer des attributs différents je comprends mais ici, les revêtements sont composés d'un ou plusieurs vernis.
De plus ayant commencé le développement en C# ca m'arrangerai de ne pas trop modifier le modèle ma BDD ... tu me diras je travaille principalement sur des vues donc ça devrait aller ... mais cette histoire d'héritage me laisse perplexe.

L'un n'empêche pas l'autre....

Tu peut avoir un vernis direct ou (exclusif) bien un revêtement composé de différentes couches de vernis et dans ce cas il y aura aussi une association n:m entre vernis et revêtement...

A +

[Puiss51]

J'ai trouvé pour CHECK :

Code :

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

1
2
3
 
alter table T_ANALYSE
add constraint CK_Partition CHECK ([REV_ID] IS NOT NULL OR [VER_ID] IS NOT NULL)

mais je suis toujours tenté d'ajouter directement VER_ID comme clé étrangère supplémentaire à mon entité T_ANALYSE...

[SQLpro]

Incomplet comme contrainte car les deux peuvent être valués ce qu'il faut éviter....

Code :

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

1
2
alter table T_ANALYSE
add constraint CK_Partition CHECK ([REV_ID] IS NOT NULL AND [VER_ID] IS NULL OR [REV_ID] IS NULL AND [VER_ID] IS NOT NULL)

A +

[Puiss51]

Ha oui très juste ! Merci pour de la correction.
Pourrais tu m'expliquer le problème que pose ma solution de clé étrangère VER _ID dans T_ANALYSE par rapport a ta proposition d'héritage, je cherche depuis ce matin mais je ne comprends pas. Merci

[Kropernic]

Hello,

D'expérience, quand j'en arrive à concevoir une relation ternaire, c'est dans 9 cas sur 10 qu'il y a une couille dans mon modèle de DB.

Donc j'éviterais (en plus, ne pas avoir de ternaire simplifie souvent beaucoup de choses).

Pour ton cas, je garderais donc les tables T_VERNIS et T_REVETEMENT mais je dédoublerais la table T_ANALYSE en T_ANALYSE_VERNIS et T_ANALYSE_REVETEMENT.

Après, tu pourras les regrouper à ta guise dans une vue mais au niveau du modèle, ce sera plus propre et plus évolutif. Car vu comme c'est parti, tu vas voir qu'on va te demander d'ajouter des attributs aux analyses qui ne seront pas les mêmes suivant le type d'analyse.

Et là, bin tout devient trivial.

En espérant avoir aidé (et ne pas me faire assassiner par sqlpro ).

[Puiss51]

En espérant avoir aidé (et ne pas me faire assassiner par sqlpro ).

Je sens qu'il va adorer faire deux entités quasi identiques
Je te remercie de ton retour d'expérience quoi qu'il en soit

[Kropernic]

Bah pourquoi pas ? L'important, c'est que ça colle à ton mcd. Tu peux en faire un héritage si tu préfères. Une table T_ANALYSE avec la pk et les attributs communs puis autant de tables que de types d'analyses avec leurs attributs spécifiques qui ont comme pk celle de table T_ANALYSE de base (c'est donc en même temps une fk).

N. B. : posté depuis le tel, sorry si ça fait un gros bloc...

[Puiss51]

Oui, je vois ce que tu veux dire. Ca me choque moins avec un héritage.
J'ai bien envie de tester la relation ternaire avec la contrainte comme mon idée de départ je vais aussi faire attention à la cardinalité pour éviter les cycles) car je ne comprends pas les complications que cela peut engendrer. Je garde vos idées sous le coude, au cas où je m'en morde les doigts

[aieeeuuuuu]

bonjour,

L'héritage semble pourtant la solution adaptée. les vernis, tous comme les revêtements, sont des "éléments analysables" tous les deux...

Par rapport aux autres solutions, elle aboutira en fait sur ds requêtes plus simples : peut être plus de jointure (même pas sûr), mais pas besoin d'UNION a tous bouts de champs pour "recoller" les vernis et les revêtements.

Par contre, pas un héritage au niveau des analyse, comme indiqué par Kropernic, mais bien entre les vernis et revetements



Pour être plus précis, il faudrait connaitre les propriétés de vernis et de revêtement.
Car en lie et place d'un héritage, on pourrait peut être avoir une seule table "revêtement", en considérant qu'un vernis est un revêtement, et qu'un revêtement peut être composé de plusieurs revêtements.

[Kropernic]

Bin tout dépend non ?

Comme déjà dit, l'important c'est que ça colle au MCD.

Perso, je ne me permettrais pas de me prononcer entre l'héritage proposé par aieeeuuuuu et le mien.

A moins d'avoir raté un détail, les deux me sembles pertinents. Tout dépend de vue dans lequel on se place.

[Puiss51]

bonjour,

L'héritage semble pourtant la solution adaptée. les vernis, tous comme les revêtements, sont des "éléments analysables" tous les deux...

Par rapport aux autres solutions, elle aboutira en fait sur ds requêtes plus simples : peut être plus de jointure (même pas sûr), mais pas besoin d'UNION a tous bouts de champs pour "recoller" les vernis et les revêtements.

Par contre, pas un héritage au niveau des analyse, comme indiqué par Kropernic, mais bien entre les vernis et revetements



Pour être plus précis, il faudrait connaitre les propriétés de vernis et de revêtement.
Car en lie et place d'un héritage, on pourrait peut être avoir une seule table "revêtement", en considérant qu'un vernis est un revêtement, et qu'un revêtement peut être composé de plusieurs revêtements.

Pour résoudre le problème de jointure, je pensais travailler avec des vues. Je ne peux pas considérer uniquement une table revêtement qui contiendrait une ou plusieurs couches de vernis car je peux avoir un vernis bicouche fabriqué par différents fournisseurs.

Voici mon MCD complet :
Je sais qu'il n'est pas parfait mais je dois aussi suivre les conseils de mon IT local

[Michel.Priori]

Il me semble étrange qu'il existe des fournisseurs pour des vernis, mais pas pour les additifs ou les molécules.

Je m'avance peut être mais, est-ce que les additifs ne seraient pas des constituants des vernis, et eux mêmes seraient constitués de molécules remarquables ?
Ce qui cadrerait avec l'analyse qui est associée avec le vernis et la molécule (via les résultats).

D'autre part, je ne saisi pas bien la nuance entre "contient" et "peut contenir" ; surtout en essayant de s'appuyer sur les cardinalités

L'association "code" me semble douteuse aussi. Explicitez les cardinalités svp.

[Puiss51]

Il me semble étrange qu'il existe des fournisseurs pour des vernis, mais pas pour les additifs ou les molécules.

il y en existe .... mais je m'en moque
nous sommes client des fournisseurs de vernis ; chez qui nos fournisseurs se fournissent les matières premières n'est pas mon soucis

Je m'avance peut être mais, est-ce que les additifs ne seraient pas des constituants des vernis, et eux mêmes seraient constitués de molécules remarquables ?
Ce qui cadrerait avec l'analyse qui est associée avec le vernis et la molécule (via les résultats).

les additifs sont considérés de manière générale dans les revêtements, ils sont (ou pas) ajoutés aux vernis.
Je ne considère pas leur composition. Les molécules sont bien rattachées aux revêtements

D'autre part, je ne saisi pas bien la nuance entre "contient" et "peut contenir" ; surtout en essayant de s'appuyer sur les cardinalités

L'association "code" me semble douteuse aussi. Explicitez les cardinalités svp.

la nomination de mes liens d'association est discutable, j'en conviens mais je manquais d'imagination à la fin mais ici elle se tient : un revêtement contient des molécules (que l'on choisira de lister ou non suivant si elles sont soumises à restriction et un revêtement peut contenir des additifs mais rien d'obligatoire, les additifs ne sont là que si besoin pour apporter certaines propriétés aux vernis. D'ailleurs je remarque une erreur de cardinalité de ma part : il peut y avoir plusieurs additifs dans un revêtement, je vais donc changer le 0,1 en 0,n

[Puiss51]

Apres nouvelle discussion avec les utilisateurs, il s'avère qu'il ne sera pas intéressant de considérer les analyses pour un Vernis seul mais plus de les entrer pour un revêtement en le considérant monocouche.
Par contre, pour faciliter la saisie de nouveau revêtement contenant des vernis déja entrés, il est intéressant que je considère les additifs et les molécules aussi bien pour un vernis que pour un revêtement. Pour ceci, je pense que je vais opter pour l'option d'héritage que vous m'avez tous conseillé, je ne vois pas vraiment la différence que cela va faire avec une relation ternaire et une contrainte mais je fais confiance à votre expérience.
Merci à tous pour votre aide

[Puiss51]

Voici donc mon nouveau MCD :



et j'ai une nouvelle question : mon héritage + ma relation Naire entre T_Additif et T_MadisonVernis (par exemple) fait que je me retrouve quasiment avec 2 tables d'associations : T_ADD_VER : qui contient implicitement ADD_ID et VER_ID ET "peut_contenir_VER" qui contient je pense les mêmes clés. N'est ce pas un peu redondant? les 2 entités ne rassemblent elles pas les même informations?
Je me demande si je n'aurais pas du modifier ma cardinalité : un vernis peut contenir 0 à n additif et un additif peut appartenir à 0 à n vernis mais de par l'héritage, n'aurait il pas fallu mettre 1,1 d'un coté ou de l'autre pour éviter cette redondance de tri?
J’espère que je suis clair dans mes explications.
Merci de votre avis

[Puiss51]

Bon j'ai la réponse à ma question de débutant : la table fille T_ADD_VER contient les mêmes attributs que la table mère donc pas de redondance... enfin si mais entre la table mère et la table fille... je vais supprimer ces attributs redondants de la table fille pour ne conserver que la clé ADD_ID.