Vendeurs de normes

Version imprimable

30/05/2011, 14h00
Xploit

Vendeurs de normes

Bonjour à tou(te)s,

J'ai un problème de modélisation pour ma base de données.
Il s'agit d'une base de données qui contient plusieurs tables définies comme ci dessous :

Table 1 : L_REFERENCE_STANDARD_VENDOR

REFERENCE TYPE VENDOR
A Norme1 Vendor1
B Norme2 Vendor2

Table 2 : T_TYPE

ID TYPE
01 Norme1
02 Norme2

Table 3 : T_VENDOR_Norme1

ID VendorName Value
01 Vendor1 0xFC
02 vendor2 0x76

Table 4 : T_SERIAL_NORME1

ID VendorName NumeroAllocation
01 Vendor1 1
02 Vendor2 1

Table 5 : T_SERIAL_NORME2

ID VendorName NumeroAllocation
01 Vendor1 1
02 Vendor2 1

Table 6 : T_REFERENCE

ID Name
01 A

Sachant A, faire une requête pour récupérer T_VENDOR_NoRMEX.Value et T_SERIAL_NORMEX.NumeroAllocation

PB : je dois pouvoir faire une requete sur une table différente selon la valeur du champ TYPE de la table 1.

Possible en une seule requete avec des jointures ?

Je suppose qu'une base de donnée correctement réalisée doit permettre de faire ce genre de requete en une seule requête.
31/05/2011, 09h54
CinePhil

Il semble effectivement qu'il y a ait des problèmes de conception... :?

Citation:

Table 1 : L_REFERENCE_STANDARD_VENDOR

REFERENCE TYPE VENDOR
A Norme1 Vendor1
B Norme2 Vendor2

Table 2 : T_TYPE

ID TYPE
01 Norme1
02 Norme2

Je devine qu'il y a une association entre L_REFERENCE_STANDARD_VENDOR et T_TYPE donc voici le MCD :
L_REFERENCE_STANDARD_VENDOR -1,1----associer----0,n- T_TYPE

Dans ce cas, il y aura une clé étrangère dans la table L_REFERENCE_STANDARD_VENDOR référençant l'identifiant (et pas le libellé) du type sinon, la table de référence des types ne sert à rien.

Citation:

Table 6 : T_REFERENCE

ID Name
01 A

De même, il y a visiblement une association entre L_REFERENCE_STANDARD_VENDOR et T_REFERENCE et L_REFERENCE_STANDARD_VENDOR semble donc être une table associative issue de ce MCD :
T_REFERENCE -0,n----L_REFERENCE_STANDARD_VENDOR----0,n- T_TYPE

Et comme il y a aussi VENDOR, peut-être s'agit-il d'une association ternaire ?
T_REFERENCE -0,n----L_REFERENCE_STANDARD_VENDOR----0,n- T_TYPE
T_VENDOR_Norme1 -0,n------------------|

Citation:

Table 3 : T_VENDOR_Norme1

ID VendorName Value
01 Vendor1 0xFC
02 vendor2 0x76

La table s'appelant T_VENDOR_Norme1 laisse supposer qu'il existe aussi une table appelée T_VENDOR_Norme2.
Puisque Norme1 et Norme2 sont les types décrits dans la table T_TYPE, il devrait y avoir plutôt une table T_VENDOR et une association avec la table T_TYPE.
Si un vendeur peut vendre plusieurs types et un type être vendu par plusieurs vendeurs, tu as ce MCD :
T_VENDOR -0,n----vendre----0,n- T_TYPE
Il faut alors une table associative dont l'identifiant sera composé des clés étrangères référençant les identifiants des tables entrant en jeu dans l'association.
TJ_VENDOR_TYPE (vt_id_vendor, vt_id_type, vt_value)

Citation:

Table 4 : T_SERIAL_NORME1

ID VendorName NumeroAllocation
01 Vendor1 1
02 Vendor2 1

Table 5 : T_SERIAL_NORME2

ID VendorName NumeroAllocation
01 Vendor1 1
02 Vendor2 1

Là je ne comprends pas ce que sont ces tables !

En gros, il faut revoir complètement le modèle de données.
Commence par établir des règles de gestion de ce style, donné plus haut :

Citation:

un vendeur peut vendre plusieurs types et un type être vendu par plusieurs vendeurs

Il est ensuite facile d'établir le morceau de MCD correspondant puis d'en déduire les tables.

Bon courage !
31/05/2011, 11h09
Xploit

Salut,

D'abord merci de prendre du temps pour essayer de comprendre ce que je souhaite faire.

En fait le but est de récupérer deux valeurs.
Ces deux valeurs sont dépendantes du couple (vendor, type).

vendor, type -> vendor_id (uniques)
vendor, type -> numero_allocation

vendor_id et numero_allocation sont tous deux utilisés pour construire le numéro de série pour un produit d'un vendeur et pour une norme.

SERIALS(#vendor, #type, vendor_id, numero_allocation)

ceci me semblait une bonne idée, le problème qu'il y a c'est que le vendor_id n'est pas du même type (pas codé sur le même nombre de bits, INTIER OU Chaine de caractère) selon que l'on utilise un type de numéros ou un autre. C'est pourquoi j'avais séparé en plusieurs tables.

Les tables T_TYPES et T_REFERENCES me servent uniquement pour avoir
une liste des types et references existant et pouvant être insérés dans les autres tables. Je voyais ça comme une sécurité pour ne pas pouvoir insérer des références inexistantes ou farfelues...
07/06/2011, 11h51
Xploit

1 pièce(s) jointe(s)

Proposition de MCD basé sur ce que je veux faire

Salut à tou(te)s,

Voici un MCD qui représente ce que je voudrais faire.
J'ai compris avec la réponse précédente qu'il fallait partir du début et donc du MCD avant de vouloir passer à la suite.
Le problème est que l'élaboration du MCD est sujette à variation selon les points de vue.

Je n'arrive pas bien à déterminer quelles sont les entités/associations incontournables du MCD. Je vais essayer de normaliser le schéma que je propose. Déjà, il semblerait que l'entité PRODUIT puisse se remplacer par une association du fait des cardinalités max internes 1 et externe n.

Que pensez-vous du schema E/A ?

Dépendances fonctionnelles :
REFERENCE, INTERFACE -> TYPE, VENDOR
TYPE, VENDOR -> SERIAL
10/06/2011, 13h35
JPhi33

Bonjour Xploit,

Les concepts semblent difficiles à mettre en place. Pour t'aider, il va falloir que tu expliques un peu plus dans le détail.

Par exemple, ceci n'est pas clair du tout :

Citation:

Envoyé par Xploit

En fait le but est de récupérer deux valeurs.
Ces deux valeurs sont dépendantes du couple (vendor, type).

vendor, type -> vendor_id (uniques)
vendor, type -> numero_allocation

A la lecture de ceci, on comprend que un "vendor" + un "type" (un type de quoi ?) déterminent un "vendor_id". Cela pose quand même un gros problème sémantique : quelle est la différence entre un "vendor" et un "vendor_id".

A la lecture du MCD fourni :
- "vendor" est une entité,
- "vendor_id" n'y est pas représenté (est-ce "N° vendeur" ?)

On en conclut qu'une entité détermine une propriété. C'est incohérent. Si le symbole "->" représente une dépendance fonctionnelle, il exprime alors une relation entre attributs, pas entre une entité et un attribut. Ces deux notions ne se situent pas au même niveau d'abstraction.

Pour remettre le sujet en cohérence, il faut une démarche ordonnée. Par exemple, tu pourrais commencer par lister tous les attributs intervenant dans ce sujet avec une liste de valeurs (concrètes) pour chaque attribut.
Ensuite il faudrait exprimer les DF existant entre ces attributs.

Citation:

Envoyé par Xploit

le problème qu'il y a c'est que le vendor_id n'est pas du même type (pas codé sur le même nombre de bits, INTIER OU Chaine de caractère) selon que l'on utilise un type de numéros ou un autre.

Il faudrait des exemples pour illustrer cette difficulté.
10/06/2011, 14h06
CinePhil

Dans le MCD que tu présentes, tu fais une association ternaire incorrecte :
Produit -1,1----Posséder----0,n- Type
Vendor -0,n----------|

Puisque qu'un produit ne peut posséder qu'une seule fois, il ne possède donc qu'un type et un vendeur, ce qui se traduit en fait par deux associations binaires :
Produit -1,1----Posséder----0,n- Type
|------------1,1----Posséder----0,n- Vendor

Si, comme le suggère ton MCD, un produit est identifié par une seule référence et une référence n'identifie qu'un seul produit, alors la référence est un attribut du produit.

Quant au n° de série, n'est-il pas lui aussi un attribut du produit, même s'il est généré à partir de l'identifiant du vendeur et celui du type ?

Il faut effectivement que tu apportes plus de précision et que tu clarifie ton besoin.
Lis la phrase en bleu de ma signature et applique son principe !