Discussion :

[jax54000]

Bonjour,

Je débute en BD.

Je me pose une question simple : est-il préférable de découper/diviser les tables le plus possible ? Exemple :

2 tables :
- Produit type A
- Produit type B
Déjà là : mieux vaut-t-il créer 2 tables (A et B) ou mieux vaut-il en avoir une seule avec un champ type ?

Imaginons ensuite que chaque type de produit soit lié à un document de spécification. Mieux vaut-il créer une table "Specification" unique avec un champ "type" ou mieux vaut-il en créer 2 : "Spécification A" et "Specification B" ?

En fait je suis en train d'essayer de créer ma base de données mais je trouve que j'ai déjà beaucoup de tables, environ 22, sachant que ça devrait monter, si je continue comme ça, à environ 40 (je suis parti sur la solution : diviser autant que possible les tables)

Merci.

A+

[CinePhil]

Il vaut mieux une table de stypes et une relation entre les produits et les types.
Le MCD suivant :
Produit -1,1----Typer----0,n- Type

Donne les tables :
Type (T_Id, T_Libelle)
Produit (P_Id, P_IdType, ...)

[Vincent Rogier]

la réponse n'est pas si simple... et dépend du type de données (liste attributs distincts, du volume stocké et du traitement effectué sut les données (sélection, dml massif, computation, etc..)

Dans le cas d'objets relativement simples, peu discordants, avec un faible volume de stockage et peu de traitement, la solution donnée précédemment s'applique.

mais dans le cas de gros volumes avec des requêtes complexe (grosses jointures, redondance des données, utilisation de fonctions analytiques et voir appels langage procédural serveur) et fréquentes, il peut être préférable de gérer plusieurs tables distinctes...

Tout dépend donc de l'utilisation des données...

[jax54000]

Merci à vous 2.

Je pense donc qu'il vaut mieux anticiper et créer plusieurs tables (les diviser).

Pas facile mais je pense que je vais partir sur cette solution.

A+

[Vincent Rogier]

attend, faut pas de presser sur un modele ! Faut bien y réflechir...

Si tes objets sont peu différenciés et que la disparité est limité à quelques dizaine, vaut peut être mieux la 1ere solution
Quand je parle de gros volume, je parle de millions d'items composant un réfentiel.
Quand je parle de grosse requête, je parle pas de 2 jointures sur un dml simple !
Quand je parle de traitement complexe, je fais référence à de l'analytique, utilisation de PL/SQL par exemple pour Oracle, computation avec sous interrogation, etc...

[CinePhil]

mais dans le cas de gros volumes avec des requêtes complexe (grosses jointures,

Même avec de grosses tables et des jointures multiples, une base de données normalisée et bien indexée sur un serveur correctement dimensionné ne doit pas avoir peur des "grosses jointures" et répondre en un temps satisfaisant.

redondance des données,

Ca ne doit carrément pas exister dans un SGBDR, sauf base de données répartie sur plusieurs sites.

Commence par modéliser correctement tes données.
Implante fidèlement le modèle.
Alimente le en données.
Si il y a des requêtes trop longues, reviens nous voir avec des exemples pour qu'on t'aide à résoudre le problème.
La dénormlisation ne doit venir qu'en dernier ressort.

[fsmrel]

la réponse n'est pas si simple... et dépend du type de données (liste attributs distincts, du volume stocké et du traitement effectué sut les données (sélection, dml massif, computation, etc..)

Dans le cas d'objets relativement simples, peu discordants, avec un faible volume de stockage et peu de traitement, la solution donnée précédemment s'applique.

mais dans le cas de gros volumes avec des requêtes complexe (grosses jointures, redondance des données, utilisation de fonctions analytiques et voir appels langage procédural serveur) et fréquentes, il peut être préférable de gérer plusieurs tables distinctes...

Tout dépend donc de l'utilisation des données...

Votre approche n’est pas la bonne, vous mélangez tout. Quand on modélise les données, on ne s’intéresse ni à la volumétrie des données ni à la nature des traitements. On s’intéresse au quoi, mais ni au quand, ni au comment, ni au où. C’est la base du métier. Ceci vaut pour le niveau conceptuel et pour le niveau suivant, à savoir le niveau logique.

C’est dans une phase ultérieure que l’on agira au niveau physique pour que les traitements soient performants, à coups d’index, de partitionnement et autres regroupement des données. Pour faire court, on construira un prototype pour tester la performance des requêtes qui seront hébergées par les quelques transactions a priori les plus sensibles : prise de commandes par exemple (même principe pour les batchs). Mais si elle a été menée dans les règles de l’art, la modélisation conceptuelle (et par contrecoup la modélisation logique) n’a pas à être impactée.

Si donc, pour reprendre la solution proposée par CinePhil, on a N produits ressortissant chacun à un type de produit, sa modélisation n'est pas à remettre en cause, que l’on ait 10 produits et 3 types de produits, ou 100000 produits et 1000 types de produits. Le principe reste valable pour des tables qui contiendraient 500000000 de lignes.

[jax54000]

Merci.

Intéressant de vous lire.

Je modélise ma base avec Toad Data Modeler. Mais peut-être suis-je déjà dans le modèle physique...

Un idée de ce que je suis en train de créer : http://www.cijoint.fr/cj200911/cijIItKCng.jpg

Pour comprendre un peu : tout ce diagramme n'est destiné qu'à un produit (TWT).
Comme je suis parti, je vais devoir créer une duplication de ce diagramme pour un 2ème type de produit - TWTA (Je n'aurai au total que 2 types de produits.)
Donc à savoir que par exemple la table MIP ou TRB data ou encore EIDP et d'autres seront constituées exactement des même champs.

Je sais que ça ne doit pas être facile à dire à première vue mais pensez-vous à vue de nez que je devrais mettre ces tables en commun ?

Merci.

A+

[CinePhil]

Pour essayer de comprendre un peu mieux, c'est quoi un TWT ? Un TWTA ?

A quoi correspondent les autres tables dont le nom est pour le moins aussi obscur ?

Est-il bien nécessaire de séparer la table tTwtType qui ne contient qu'une colonne booléenne pour servir de clé étrangère uniquement à la table tTwt ?

La table tTwt distribue son numéro de série à la table tTwtFcDate. La relation indique que cette distribution peut être multiple mais rien dans la table des dates ne permet de différencier sémantiquement les différentes instances d'un même numéro de série. Qu'est donc sensée contenir cette table de dates ?

Les tables tPop, tLin, tFop, tTwtTrbData ont la même structure. Elles pourraient probablement être réunies en une seule table. Reste à savoir là aussi ce que sont ces Pop, Lin, Fop et TrbData.

tTwtEidp a presque la même structure que les précédente. A voir aussi dans ce cas de simplification potentielle.

Idem pour les tables tTwtNcr et tTwtRfw.

Avec un bout de cahier des charges (une liste de règles de gestion), on pourrait aider à une modélisation plus rationnelle parce que j'ai l'impression qu'il y a un gros boulot d'optimisation à faire !

[freyn]

A noter que si tu débutes, tu pourras trouver une tonne d'information ici (http://sqlpro.developpez.com/).

[jax54000]

CinePhil tu me fais rire avec tes .

Excellent !

Bon un peu de vocabulaire :

TWT : travelling wave tube (produit n°1)
TWTA : travelling wave tube amplifier (produit n°2)
NCR : non conformité. Un produit peut avoir de 0 à n non conformité(s).
RFW : autre type de non conformité : Idem
MIP : Major Inspection Point: inspection visuelle
POP: données livrées relatives au TWT (valeurs de tensions, courants), n'existe pas au niveau TWTA
FOP: idem (mais données plus fiables), n'existe pas au niveau TWTA
LIN: données livrées relatives au TWT (valeurs de phase), n'existe pas au niveau TWTA
TRB data et EIDP: données livrées relative au TWT, existe également pour le TWTA.
Event : évenmenents divers: chute, disjonctions....

Toutes les table FcDates sont des forecast dates soit des dates prévisionnelles, fournies dans des plannings (pour toutes les livraisons citées ci-dessus)

Petite version plus à jour de la BD : http://www.cijoint.fr/cjlink.php?fil...cijo1yazio.jpg

A votre dispo pour d'autres infos.
Merci.

[CinePhil]

Je vais employer le schéma MCD de la méthode Merise. Le MLD qui en découle est assez proche du modèle entity/relation de ton schéma.

1) Tu as donc des produits qui sont (actuellement) de deux types.
MCD :
Produit -1,1----Typer----0,n- TypeProduit

Tables :
TypeProduit (TP_Id, TP_Code, TP_Libelle)
Produit (P_Id, P_IdType, P_SerialNumber...)

Ne sachant pas ce que sont Band et ActualDate, je les laisse de côté pour le moment.

Au passage, tu remarqueras que je n'utilise pas le numéro de série du produit comme clé primaire mais un identifiant anonyme qui sera de type entier auto-incrémenté.

Données :
Type (T_Id, T_Code T_Libelle)
1, 'TWT', 'Travelling wave tube'
2, 'TWTA', 'Travelling wave tube amplifier'

Produit (P_Id, P_IdType, P_SerialNumber...)
1, 1, '0000001'
2, 1, '0000002'
3, 2, '0000001'
...

2) Ces produits peuvent faire l'objet de non-conformités qui peuvent être de plusieurs types.

MCD :
Produit -0,n----Concerner----1,1- Non_conformite -1,1----Typer----0,n- Type_NC

Tables :
Type_NC (TNC_Id, TNC_Code, TNC_Libelle)
Non_conformite (NC_Id, NC_IdTypeNC, NC_IdProduit, NC_Reference, NC_Title, NC_IsSigned, NC_File)

La table produit ne change pas.

Je constate sur ton schéma qu'une NC peut se rapporter à plusieurs produits ?
Je change le MCD :
Produit -0,n----Concerner----1,n- Non_conformite -1,1----Typer----0,n- Type_NC

Je change la table Non_conformite :
Non_conformite (NC_Id, NC_IdTypeNC, NC_Reference, NC_Title, NC_IsSigned, NC_File)

J'ajoute une table de jointure entre les produits et les non-conformités :
NC_Produit (NCP_IdProduit, NCP_IdNC)

Ne sachant pas ce que contient tDocIssue, je l'ignore pour le moment. Bizarre d'ailleurs qu'il y ait propagation de son identifiant dans les tables qui y sont liées. Quelle en est la raison ?

3) Un produit peut faire l'objet de un à plusieurs Major Inspection Point
MCD :
Major_inspection_point -1,1----Concerner----0,n- Produit

Tables :
Major_inspection_point (MIP_Id, MIP_IdProduit...)
Bizarre qu'il n'y ait pas de date ici !

La table Produit ne change pas.
Rien de spécial à dire sur les autres colonnes de ta table tTwtMip.

4) Un produit peut avoir des données associées (POP, FOP, LIN, TRB, EIDP) que j'appelerai paramètres et qui sont donc apparemment d'un certain type.
MCD :
Produit -0,n----posséder----1,1- Parametre -1,1----Typer----TypeParametre

Tables :
TypeParametre (TP_Id, TP_Code, TP_Libelle)
Parametre (PA_Id, PA_IdTypeParametre, PA_ActualDate, PA_File)

La table Produit ne change pas.

5) Un produit peut avoir plusieurs événements
MCD :
Produit -0,n----Avoir----1,1- Evenement

Tables :
Evenement (E_Id, E_IdProduit, E_Description)
Bizarre qu'il n'y ait pas de date ici !

Bilan :
Liste des tables :
- Produit
- TypeProduit
- TypeNC
- Non_conformite
- NC_Produit
- Major_inspection_point
- TypeParametre
- Parametre
- Evenement

Soit 9 tables au lieu de 14 dans ton modèle. Il reste à résoudre l'utilité des tables TwtFCDate et tDocIssue. Au maximum, il y aurait 11 tables au lieu de 16, et pas besoin de duppliquer une grande partie de la structure pour un autre type de produit.

Et si dans le futur un type de produit nouveau apparait, il suffit de l'ajouter à la table TypeProduit et le modèle reste valable.

[jax54000]

Intéressant de voir comment tu t'y prends pour modéliser.

Band est une bande de radio-fréquence (bande C, bande Ku, Bande Ka, Bande S...)

ActualDate est la date effective de livraison (du produit, du POP, du FOP...)

1)
Pardon en réalité il y a 3 types de produits :
- un TWT (tube)
- un EPC (alimentation du tube)
- un TWTA = 1 EPC + 1 à 2 TWTs = amplificateur complet

Pourquoi ne pas utiliser le Serial Number du produit comme clef primaire puisqu'il est censé définir de manière unique le produit ?


2) Je confirme qu'une NCR ou RFW peut se rapporter à plusieurs produits
Doc issue est une table contenant toutes les issues possibles des divers documents que nous sommes amenés à traiter (00, 01, 02, ..., 99, A, B, C,..., Z) Je propage l'issue dans les autres tables car par exemple une NCR est un document avec une référence et une issue (couple servant à identifier de manière unique un document).

3) je confirme qu'il faut une date pour le MIP. Un MIP est notifié par email (il aura lieu à telle date), il est ensuite soit délégué au fournisseur soit exécuté par notre société à la date donnée puis nous recevons un rapport de MIP (document avec une référence et une issue)

4)livraisons liées aux produits :
- TWT : POP, FOP, LIN, TRB data, EIDP (chaque livraison étant plannifiée plusieurs fois au cours du projet d'où les FcDate pour enregistrer les dates prévisionnelles fournies au fur et à mesure du projet)
- EPC : aucune donnée livrée
- TWTA : TRB data, EIDP

Attention un TRB data et un EIDP sont des documents (des résultats de test) et donc non des paramètres.


TwtFcDate est la table qui regroupe toutes les dates prévisionnelles de livraison du TWT fournies au fur et à mesure du projet.


Encore une clarification : cette base de données servirait à gérer un projet d'approvisionnement de TWTA (composé de TWT et d'EPC). Nous achetons N TWTA et nous devons suivre l'approvisionnement de ces N TWTA. Certains TWTA sont dit single (un TWT par TWTA) d'autres sont dual (2 TWT par TWTA). Dans quelques années nous en mettrons probablement 3 par TWTA etc...

Merci de ton aide.