Discussion :

[professeur shadoko]

Bon l'intitulé de ma question n'est pas très clair alors je vais essayer de préciser.
Imaginons qu'on ait différentes tables TB1, TB2, TB3 qui décrivent des produits différents vendus par un magasin.
Ces tables ont au moins une information commune: la référence unique du produit dans le magasin.
Maintenant comment chercher un produit en fonction de sa référence?

question 1: la question est-elle stupide parcequ'elle relève d'une mauvaise conception?

question 2: si possible: comment faire? une table qui relierait le numero unique à une autre table est-elle possible?

je veux dire pour simplifier peut-on faire" SELECT * from X" où X est calculé à partir d'une autre requête SELECT?

pour compliquer un peu plus la question: pas de base de référence! c'est une question purement abstraite.

merci

[Waldar]

Réponse à la question 1 : oui, c'est une mauvaise modélisation.

Réponse à la question 2 : oui, on peut quand même s'en sortir avec une requête de ce genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
SELECT reference, source
FROM
(
SELECT reference, 'TAB1' as source FROM Table1
UNION ALL
SELECT reference, 'TAB2' FROM Table2
UNION ALL
SELECT reference, 'TAB3' FROM Table3
) sr
WHERE reference = ...

[Oishiiii]

Ça ne me semble pas être une "mauvaise conception".
La description donnée fait penser à de l'héritage (mais sans la table "parent").

Quelque chose comme ceci (clé primaire soulignée, clé étrangère en italique):
Produit(prod_id, prod_nom)
Chaussure(prod_id, pointure)
Chapeau(prod_id, tourTete)
Jean(prod_id, longueur, largeur, couleur)

Ensuite, je ne voit pas quel est le problème

[Waldar]

Justement, c'est table principale manquante, c'est la mauvaise conception.
Heureusement, c'est ratrapable.

[professeur shadoko]

.
Pour simplifier le propos:
imaginons qu'on ait des tables "fabricant" qui décrivent des produits. Ces tables ont des informations assez diverses et de nouvelles tables peuvent se présenter rapidement dans la vie de l'application.
On gère par contre la vue "distributeur" quelque chose qui aurait l'aspect

Code :

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

1
2
 
ref_unique_distributeur;  prix;  stock;  table_fabricant;  clef_fabricant;

peut-on imaginer une requête propre qui donne toutes les informations "fabricant" connaissant la "ref_unique_distributeur" (par exemple).
contrainte: la liste des tables fabricant n'est pas en dur dans la requête.

bravo à ceux qui ont vu l'héritage: il est vrai que l'appli retransforme tout ça sur la base d'une classe abstraite Java "Produit". Bien entendu je peux tout à fait m'éviter une requête SQL tordue en gérant les choses en deux coups dans mon programme: consultation de la table distributeur puis aiguillage vers une autre requête SQL bien simple.
Je suis quand même curieux de savoir si ce genre de situation de configuration ne se produit jamais dans la "vraie vie" .

merci à tous.

[pacmann]

Salut !

Non, ce n'est pas possible sans mettre de nom en dur.
Je suppose que que la colonne "table_fabricant" contient le nom de la table à lire ?

Dans ce cas, soit tu fais la jointure systématique sur toutes les tables fabricant en incluant cette colonne comme critère de jointure, soit tu réalises ton exécution en deux fois (comme tu l'envisageais en Java).

[CinePhil]

.
Pour simplifier le propos:
imaginons qu'on ait des tables "fabricant" qui décrivent des produits.

Ça reste une mauvaise conception on dirait !
Une table "fabricant" décrit les fabricants, pas les produits !

Ces tables ont des informations assez diverses et de nouvelles tables peuvent se présenter rapidement dans la vie de l'application.

Normalement, le modèle de données est figé et l'application n'a pas à créer de nouvelles tables, sauf cas très particuliers (archivage de données régulières, importation de données brutes à des fins de statistiques par exemple).
Si ton application génère de nouvelles tables "fabricant", c'est de plus en plus probable qu'il y a une erreur de conception !

[quote]On gère par contre la vue "distributeur" quelque chose qui aurait l'aspect

Code :

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

1
2
 
ref_unique_distributeur;  prix;  stock;  table_fabricant;  clef_fabricant;

C'est une vue "distributeur" qui semble afficher des données relatives à des produits (stock, prix) et qui fait référence à des fabricants (ceux des produits j'imagine ?).
Il y a au moins un problème de sémantique dans ton machin !

Normalement tu devrais avoir plutôt un schéma de données de ce type (formalisme MCD de la méthode Merise) :
Fabricant -0,n----Fabriquer----1,n- Produit -0,n----Distribuer----0,n- Distributeur

Ce qui donnerait par exemple les tables :
Fabricant (fab_id, fab_nom, fab_adresse...)
Distributeur (dis_id, dis_nom, dis_adresse...)
Produit (prd_id, prd_nom, prd_ref_interne, prd_prix_vente_ht...)
Fabriquer (fbq_id_produit, fbq_id_fabricant, fbq_prix_achat_ht...)
Distribuer (dtb_id_produit, dtb_id_distributeur, dtb_prix_achat_ht...)

[professeur shadoko]

apparemment je me suis mal expliqué: quand je parle de table "fabricant" ou "distributeur" je ne parle pas de table qui les décrit. Je veux dire d'un point de vue du fournisseur et du point de vue du distributeur.
Le point fondamental est celui-ci: chaque fois qu'on déploie ou on redéploie l'application des tables particulières peuvent se présenter en fonction de l'évolution du métier : on décide de vendre un nouveau produit avec des caractéristiques bien à lui.
on a donc différentes tables avec des champs différents.
quand on intègre un nouveau produit on met sa table dans la base et on complète une table de référence avec un code unique du vendeur.

Je suis vendeur: je décide d'ajouter à mon catalogue des Livres et des Téléphones portables. Ce sont des choses avec des caractéristiques fondamentalement différentes (chacunes dans une table particulière)
et je complète ma table qui gère ces produits:
ma_ref_unique; prix_public; stock; table_produit; clef_produit;

Inhabituel certes mais est ce vraiment si choquant? Si oui pourquoi?
(première piste: une forme normale est en danger effectivement)

Ensuite peut-on réaliser une requête qui me donne toutes les caractéristiques d'un produit à partir de sa référence unique (ma_ref_unique)?

avec une procédure stockée ça doit marcher ....
avec une requête SQL j'ai des trous de mémoire: il y a longtemps de ça je m'étais joyeusement tapé la lecture d'une norme SQL (était-ce SQL 2 ou 3?) et je crois me souvenir avoir découvert dans un coin obscur que la spécification d'une colonne ou d'une table pouvait elle même être le résultat d'une requête. J'avais mis ça de coté en espérant ne jamais avoir à implanter ça

[CinePhil]

Alors effectivement, à la suite de Oishii et Waldar, je dis que ce qu'il manque, c'est un véritable héritage. Pour reprendre mon modèle avec une table Produit, on aurait le modèle suivant :

Livre -(1,1)----Etre-------------------0,1- Produit
Téléphone_portable (1,1)----Etre----0,1--|

Ce qui donne les tables suivantes :
Produit (prd_id, prd_nom, prd_ref_interne, prd_prix_vente_ht...)
Livre (l_id_produit, l_titre, l_nb_pages, l_format...)
Tel_portable (tp_id_produit, tp_modele...)

Ensuite peut-on réaliser une requête qui me donne toutes les caractéristiques d'un produit à partir de sa référence unique (ma_ref_unique)?

Comme dans le modèle de l'héritage, l'identifiant de la table fille (Livre ou Tel_portable) est celui de la table mère (Produit), c'est très facile de récupérer tous les attributs du produit à partir de sa référence. Par exemple pour un livre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
SELECT l.l_titre, l.l_nb_pages, l.l_format,
  p.prd_prix_vente_ht,
  f.fab_nom,
  d.dis_nom
FROM Produit AS p
LEFT OUTER JOIN Livre AS l ON l.l_id_produit = p.prd_id
LEFT OUTER JOIN Fabriquer AS fbq ON fbq.fbq_id_produit = p.prd_id
  LEFT OUTER JOIN Fabricant AS f ON f.fab_id = fbq.fbq_id_fabricant
LEFT OUTER JOIN Distribuer AS dtb ON dtb.dtb_id_produit = p.prd_id
  LEFT OUTER JOIN Distributeur AS d ON d.dis_id = dtb.dtb_id_distributeur
WHERE p.prd_ref_interne = 'abc1234'

[professeur shadoko]

certes certes il y a héritage (les classes java correspondantes héritent d'une classe abstraite Produit)
prenons donc une configuration du style:
Produit(ma_ref_unique, prixHt, stock, etc....
Livre(ma_ref_unique, refISBN, titre, auteur, etc....
(d'ailleurs auriez vous un lien expliquant bien la configuration de tables en cas d'héritage? merci)

je peux imaginer une requète classique si je sais que je cherche un Livre.
mais si je le sais pas? (sans faire la totale des tables disponibles)

[CinePhil]

certes certes il y a héritage (les classes java correspondantes héritent d'une classe abstraite Produit)
prenons donc une configuration du style:
Produit(ma_ref_unique, prixHt, stock, etc....
Livre(ma_ref_unique, refISBN, titre, auteur, etc....

Non ! Puisque que Livre hérite de Produit, le livre hérite aussi, en tant que clé primaire et étrangère, de l'identifiant du produit, donc est identifié par "ma_ref_unique".

(d'ailleurs auriez vous un lien expliquant bien la configuration de tables en cas d'héritage? merci)

http://sqlpro.developpez.com/cours/m...tion/heritage/

je peux imaginer une requète classique si je sais que je cherche un Livre.
mais si je le sais pas? (sans faire la totale des tables disponibles)

Idée vite fait, pas forcément très propre du point de vue conceptuel :
On type le produit :
Produit -1,1----Typer----0,n- Type_Produit
On cherche le type du produit à partir de sa référence puis on interroge la table fille correspondant au type-produit qu'on a récupéré.

[professeur shadoko]

Non ! Puisque que Livre hérite de Produit, le livre hérite aussi, en tant que clé primaire et étrangère, de l'identifiant du produit, donc est identifié par "ma_ref_unique".

yes sir, je voulais dire que ISBN est aussi unique (et aussi clef? d'où quelques problèmes de création de la table?)

Idée vite fait, pas forcément très propre du point de vue conceptuel :
On type le produit :
Produit -1,1----Typer----0,n- Type_Produit
On cherche le type du produit à partir de sa référence puis on interroge la table fille correspondant au type-produit qu'on a récupéré.

on est d'accord mais comment on fait ça techniquement? (comment trouver la table en fonction du type de produit?)

merci pour l'ensemble des remarques.

[CinePhil]

yes sir, je voulais dire que ISBN est aussi unique (et aussi clef? d'où quelques problèmes de création de la table?)

ISBN est une clé candidate mais n'est pas la clé primaire de la table. C'est l'identifiant du produit qui doit jouer ce rôle.

on est d'accord mais comment on fait ça techniquement? (comment trouver la table en fonction du type de produit?)

J'avais dit "vite fait" donc toujours vite fait : en deux requêtes lancées par le logiciel qui paramètre la seconde requête en fonction du résultat de la première. Pas le temps de développer maintenant.

[professeur shadoko]

ISBN est une clé candidate mais n'est pas la clé primaire de la table. C'est l'identifiant du produit qui doit jouer ce rôle.

après reflexion je ne suis pas totalement convaincu .... (mais je veux bien l'être ).
Pourquoi? ceci nous amène dans une autre discussion.
Les principes de conception sont importants et doivent être maitrisés (ce n'est plus mon cas en BDD ) mais souvent les exposés à ce sujet ont une vue "transcendentale" c'est à dire le concepteur sait tout voit tout entend tout prévoit tout... Or dans la réalité c'est loin d'être le cas et les hypothèses de réingénierie doivent être considérées. On a plusieurs phases de conception et on doit savoir faire face à une situation préexistante.

Certes j'expose ici un "cas d'école" non réél (et criticable) mais il est dérivé d'une situation réellement observée sur le terrain.
La société Fnac2 vend des Livres et met en place sa base:
Livre( isbn, titre, auteur, etc....)
les applications A, B, C, D partagent cette vision des données d'entreprise.

Plus tard apparait l'application E qui gère un nouveau métier car le magasin va aussi vendre des téléphones portables. L'application E a donc une vision Produit et une autre vision de Livre. Comment modifier la base pour tenir compte de ce concept sachant qu'il est hors de question (pour le moment) de modifier les applications A,B, D ?
En définissant des vues? quel est alors le statut des clefs dans les tables?

[CinePhil]

après reflexion je ne suis pas totalement convaincu .... (mais je veux bien l'être ).

Voir chez SQLPro :
- La modélisation de l'héritage en BDD.
- Qu'est-ce qu'une bonne clé ?

Pourquoi? ceci nous amène dans une autre discussion.
Les principes de conception sont importants et doivent être maitrisés (ce n'est plus mon cas en BDD ) mais souvent les exposés à ce sujet ont une vue "transcendentale" c'est à dire le concepteur sait tout voit tout entend tout prévoit tout... Or dans la réalité c'est loin d'être le cas et les hypothèses de réingénierie doivent être considérées. On a plusieurs phases de conception et on doit savoir faire face à une situation préexistante.

Un concepteur qui ne fait que de la théorie conceptuelle sans avoir la moindre idée sur la manière dont sa conception pourra être mise en oeuvre va au devant de problèmes graves !

Ainsi, en conception théorique de BDD, on peut considérer qu'un code, une référence, uniques par définition, sont des identifiants de données suffisants pour une entité. Mais codes ou références sont susceptibles de changer et seront probablement d'un type alphanumérique, moins performant à traiter par le SGBD que les entiers, constitueraient au final un mauvais choix d'identifiant pour la table issue de l'entité. Je vous renvoie de nouveau à l'article de SQLPro et aux nombreuses discussions sur ce sujet pour des arguments plus détaillés.
Il faut donc ajouter, dès la conception, l'identifiant artificiel qui sera utilisé par le SGBD.

Dans votre cas, comme Livre hérite de Produit et que ISBN est un attribut du livre mais pas du produit, ISBN ne peut pas être la clé de l'entité Livre ; ce sera forcément l'identifiant du produit qui jouera ce rôle.

Certes j'expose ici un "cas d'école" non réél (et criticable) mais il est dérivé d'une situation réellement observée sur le terrain.
La société Fnac2 vend des Livres et met en place sa base:
Livre( isbn, titre, auteur, etc....)
les applications A, B, C, D partagent cette vision des données d'entreprise.

Plus tard apparait l'application E qui gère un nouveau métier car le magasin va aussi vendre des téléphones portables. L'application E a donc une vision Produit et une autre vision de Livre. Comment modifier la base pour tenir compte de ce concept sachant qu'il est hors de question (pour le moment) de modifier les applications A,B, D ?
En définissant des vues? quel est alors le statut des clefs dans les tables?

L'héritage permet effectivement d'ajouter des tables filles sans toucher à la structure existante de la BDD et au code des applications existantes.
Et effectivement, c'est par le mécanisme des vues qu'on adapte la livraison des données à l'application.
Le statut des clés ne change pas parce qu'on passe par une vue. Une clé est une clé et le restera tant qu'on aura pas modifié la structure de la table.

[professeur shadoko]

Il faut donc ajouter, dès la conception, l'identifiant artificiel qui sera utilisé par le SGBD.

Dans votre cas, comme Livre hérite de Produit et que ISBN est un attribut du livre mais pas du produit, ISBN ne peut pas être la clé de l'entité Livre ; ce sera forcément l'identifiant du produit qui jouera ce rôle.

ok mais ici Livre n'hérite pas de Produit au démarrage. Il a donc sa propre clef dans son contexte.
(nota: dans le cas très particulier du Livre les id "naturels" ISBN sont vraiment uniques et universels, mais il n'empêche que tout un chacun se doit d'avoir sa propre référence unique).
Produit arrive ensuite avec son propre système de clef....

Si les clefs sont générées dans un contexte "universel" (de la base) ça pose pas de problème. Mais si c'est dans le contexte de chaque table on repart pour un tour. Que faut-il faire dans ce cas?
- deux clefs et on laisse la vision "ancienne" de Livre dans une vue?
- une seule clef mais on fait comment?

merci pour tout.

[CinePhil]

ok mais ici Livre n'hérite pas de Produit au démarrage.

Et depuis le début on te dit que c'est ce qui manque à ton modèle !

Il est beaucoup plus logique, du point de vue conceptuel, de partir de la généralité "Je gère des produits qui ont tous une référence interne, un nom, un prix de vente hors-taxes, qui sont tous fabriqués par des fabricants et qui peuvent potentiellement tous être distribués par des distributeurs que de partir du cas particulier vélo, livre, pâtes alimentaires ou fleurs et se reposer la même question à chaque fois, multiplier les associations avec les mêmes entités Fabricant et Distributeur (lesquels sont généralisables en Société par exemple).

[professeur shadoko]

Et depuis le début on te dit que c'est ce qui manque à ton modèle !

<mode bourrique (je suis ariégeois)>
N'ai je point précisé depuis quelque temps que je parle d'une situation d'évolution du modèle?

version 1: table Livre initiale gérée par plusieurs applications
version 2: une nouvelle application entre en scène met en place un modèle avec héritage (avec Produit). comment faire évoluer le système?
</mode bourrique>