Discussion :

[Shinosha]

Bonjour,

J'ai un doute sur mon design concernant la présence de certaines clés étrangères. Voyez plutôt :



J'ai donc une table de durées (de fabrication). Ces durées dépendent de plusieurs paramètres, comme le diamètre de la pièce, le type de produit etc... Seulement vous voyez que j'ai deux clés étrangères nullable dans cette table, et mon problème est que ces dernières sont mutuellement exclusives. Autrement dit une durée ne peut pas dépendre à la fois d'une longueur et d'un angle.

Ma question est donc : comment régler ce problème ? Suis-je censé gérer ça au niveau applicatif ou il y a t-il une meilleure solution ?

Merci

[Samuel_]

Une solution serait de modéliser une sorte d'héritage :

Création d'une nouvelle table Product avec seulement un attribut ID.
Remplacement des 2 clefs étrangères qui posent problème dans Durations par une clef étrangère de Product.
Création d'une clef étrangère de Product dans chacune des tables ProductLengths et ProductAngles.

Sinon tu peux créer un trigger au niveau de la table Durations qui gère l'eclusion mutuelle des deux clefs étrangères.

J'espère t'avoir aidé !

[Shinosha]

Merci pour votre réponse.

Création d'une nouvelle table Product avec seulement un attribut ID.
Remplacement des 2 clefs étrangères qui posent problème dans Durations par une clef étrangère de Product.
Création d'une clef étrangère de Product dans chacune des tables ProductLengths et ProductAngles.

Cela règle effectivement le problème, mais cela en pose un nouveau il me semble. En effet il faudrait contrôler qu'un ID z de Product ne soit pas dans ProductLength et ProductAngles à la fois. A vrai dire je vais développer un peu ma problématique...

Une durée dépend de certains paramètres qui sont communs à toutes durées (diamètre, machine opératrice et type de produit). Elle dépend également d'autres paramètres, qui eux sont mutuellement exclusifs :

- La longueur : Si c'est un pièce droite, il y aura alors plusieurs dimensions (1000mm->6000mm)
- L'angle : Si c'est une pièce courbée (4 angles possibles actuellement)
- Du nombre de membranes : Si c'est une sorte de soufflet, cela pourra avoir une ou plusieurs parties flexibles (Ce qui est défini par trois caractères entiers)
- Le sous type de pièce : Par rapport au idProductType, et attention un type donnée ne peut pas forcément prendre tous les sous types. (Ex : Un produit type Bride ne pourra avoir que les sous types "R" ou "P")

Étant déjà bloqué sur les deux premières je n'ai pas modélisé les deux dernières Cela dit pour l'histoire de sous type, il me parait pertinent de le spécifier dans ma table ProductType via un champ supplémentaire tout simplement.
Pour le reste, l'héritage me parait être une approche intéressante : On pourrait avoir une table "Spécialisation" avec un ID comme vous l'avez proposé qui serait lié à un et un seul paramètre. Le problème c'est qu'il faudrait donc encore une fois un contrôle pour s'assurer qu'une spécialisation ne puisse pas être défini par plusieurs paramètres. En clair cela reviendrait encore à faire un trigger

Au final : quelle solution est la plus adaptée ? Sachant que j'ai déjà des données existantes (non relationnelle en fait, en tableur) et que plus il y a de tables, plus le script d'export sera embêtant.

Faire un héritage+trigger ou adopter une approche peut être un peu plus dénormalisée+trigger ?

[Samuel_]

Faire un héritage+trigger ou adopter une approche peut être un peu plus dénormalisée+trigger ?

LA bonne question !
Moi j'utiliserais l'héritage ! Mais après c'est à toi de décider !
Je trouve l'utilisation de l'héritage plus "propre" et mieux au niveau de la modélisation.
Je pense également que l'héritage facilite la maintenance et les évolutions.

[Shinosha]

Ca me semble également être la voie la plus sage, je vais partir sur ça. Juste une question : C'est pas une mauvaise pratique d'avoir une table avec seulement une clé primaire ? Parce qu'au final ma spécialisation n'est caractérisée que par un ID, qui la relie à sa vraie valeur. En POO ça me choque pas mais niveau modèle relationnel je trouve ça curieux

EDIT :

J'ai eu une remarque qui m'a paru pertinente :

Pourquoi ne pas faire une table spécialisation avec un champ Type (correspond au type de la spécialisation, pourra même être externalisé dans une autre table) et à la propriété ? Vu que sans la contrainte de sous-type, toutes les valeurs seront numériques. De cette façon on aurait une clé étrangère dans durée qui correspondrait directement à la propriété, sans besoin de tous ces triggers.