La table article

Hi,

Je dois créer une table pour stocker des références d'article. Or, en fonction de la famille d'article, les attributs peuvent être différents (les caractéristiques d'une poudre sont forcément différentes d'une mousse ou d'une colle)

Il existe donc plusieurs manières de concevoir l(a)(es) tables(s) : créer une table reprenant les attributs communs à chaque famille d'article et créer ensuite différentes tables secondaires pour y stocker les caractéristiques propres à chaque famille d'article. Cela implique qu'il faudra gérer autant de tables qu'il existe de familles d'article.

Autre possibilité, créer une seule table reprenant les attributs de toutes les familles d'article. Dans ce cas, la plupart des champs de la table qui ont été créés pour entrer les caractéristiques de la mousse ne serviront que pour la mousse. Ces champs resteront vides pour la poudre, par contre il faudra créer des champs spécifiques aux caractéristiques de la poudre. Idem pour la colle, etc.

Voilà, l'une et l'autre méthode ont leurs avantages et inconvénients. Peut-être avez-vous solutionné le problème par une autre méthode, j'aimerais avoir un retour d'expérience sur la manière dont vous avez structuré votre table article ou d'éventuelles suggestions si de bonnes idées vous traversent l'esprit.

Merci.

JJ

C'est une bonne question.
De mon côté j'ai toujours fait une seule table (reste à voir le nb de chps au total) et je personnalise le formulaire selon la famille d'articles ...
:)

Citation:

---

Envoyé par Jean-Jacques Engels

créer une table reprenant les attributs communs à chaque famille d'article et créer ensuite différentes tables secondaires pour y stocker les caractéristiques propres à chaque famille d'article. Cela implique qu'il faudra gérer autant de tables qu'il existe de familles d'article.

---

C'est la bonne méthode et cela s'appelle l'héritage.
Cherche dans les tuto.

Bonjour

Citation:

---

Envoyé par CinePhil

C'est la bonne méthode et cela s'appelle l'héritage.
Cherche dans les tuto.

---

Héritage de table? Je n'en ai jamais entendu parler... Pourrais-tu développer ton idée?

Pour moi, la méthode de créer plusieurs tables (avec ou sans héritage) n'est pas la meilleure, car elle va compliquer les extractions de données. Si l'on veut rechercher par exemple les articles fournis par le même fournisseur ou vendues au même client, on va devoir utiliser des requêtes UNION sur les champs communs des différentes tables, et lorsque l'on va ajouter un nouveau type de produits, on va devoir créer un nouvelle table et modifier les requêtes UNION en conséquence...

Je trouverais pour ma part plus judicieux de ne créer qu'une table. S'il existe beaucoup de champs propres à chaque catégorie d'article, on pourrait concevoir des "sous-tables" reprenant les propriétés spécifiques d'une catégorie et pointant vers la clé primaire de la table des articles. Par programmation, il serait alors possible d'afficher tel ou tel sous-formulaire en fonction de la catégorie de l'article affiché dans le formulaire principal...

Cela étant, je suis ouvert à toute autre idée...

Tu n'y es pas du tout !
En plus j'ai déjà expliqué ça tout ce matin même dans ce message

Encore une fois cherche des infos et des tuto sur le concept d'héritage et tu y arriveras.

Pour répondre plus spécifiquement à ça :

Citation:

---

Si l'on veut rechercher par exemple les articles fournis par le même fournisseur ou vendues au même client, on va devoir utiliser des requêtes UNION sur les champs communs des différentes tables, et lorsque l'on va ajouter un nouveau type de produits, on va devoir créer un nouvelle table et modifier les requêtes UNION en conséquence...

---

Les articles sont TOUS dans la table articles qui pourrait avoir la structure suivante :
Articles(ArtId, ArtNom, ArtIdFournisseur, ...)
Il est donc très facile d'avoir tous les articles vendus par un fournisseur ou vendus au même client.

Si un article est une poudre, il figurera en plus dans la table des poudres :
Poudres(P_IdArticle, PConditionnement, PDangerosité, PGranulometrie...)

Salut Cinéphil,

Dans ce message, tu expliques, me semble-t-il, exactement la même chose que moi... Je ne suis donc pas sûr de "n'y être pas du tout"...;)

Ce qui me "perturbait", c'est le mot "héritage" dont je n'ai jamais entendu parler au sujet des tables dans le cas présenté ici (et à mon avis, en absence de recherches plus approfondies de ma part, inapproprié dans ce contexte, car aucune table n'hérite de la structure d'une autre, ni en suivant tes explications, ni en suivant les miennes)... L'héritage de tables, tel que le concept est décrit généralement, n'est pas géré par Access. La recherche de tutos sur le sujet mènera donc à une impasse!

Mais je pense que nous développons exactement la même idée tous les deux, car si tu lis bien mon message, tu verras que j'y aborde la même démarche que la tienne, à savoir une table commune pour les propriétés communes, et une table pour chaque catégorie liée à cette table commune par un champ FK => PK ...

Salut tout le monde
cinephil pouvez-vous de temps en temps indiquer des exemples de liens quand vous suggérer des solutions de recherche. (excusez ma paresse:oops:).

Pour la solution multitable, les tables sont créées par le programmeur ou leur création est programmée puis exécuté par l'utilisateur?
Je voie déjà le problème de requête sur ces tables: une recherche sur ces tables deviens quasiment impossible.

J'ai eue le même problème pour la création d'un appli de gestion de matériels informatique. Ma solution était de créer une table proprietes(Idpropriete, idproduit, nompropriete, valeurpropriete). Quelles sont vos remarques?

Merci pour vos réponses.

Les solutions de CinePhil et Pierre Fauconnier correspondent à la première des solutions que je proposais comme exemple dans ma question.

La solution de alassanediakite apporte une nouveauté sur laquelle je vais me pencher. Elle a l'avantage de tenir en deux tables, peu importe le nombre de familles. Par contre, un petit problème va se poser lorsqu'il faudra afficher un article à l'écran dont les données se trouvent dans plusieurs enregistrements de la table proprietes. Il faudra gérer l'écran de la fiche article de manière dynamique, mais c'est sans doute faisable. A moins de présenter les propriétés sous forme de tableau. Faire admettre cette dernière présentation à un simple utilisateur du programme me semble moins évident.

Merci pour votre aide.

JJE

PS : L'héritage n'existe qu'en programmation orientée objets si je ne m'abuse. Je crois que certains éditeurs de base de données, notamment PostgreSQL, ont tenté de faire de l'héritage de table. D'après mes dernières informations (qui datent peut-être un peu) je n'ai pas l'impression que le résultat soit convainquant.

Un apport aux solutions de CinePhil et Pierre Fauconnier :

Tu peux effectivement créer autant de champs dans ta table que tu as de propriétés différentes pour l'ensemble de tes articles. Ce qui donnerait une table semblable a :

Champs principaux de la table en solution standard:
- ID_ARTICLE
- CATEGORIE_ARTICLE
- CAT_1_PROPRIETE_1
- ...
- CAT_1_PROPRIETE_n
- CAT_2_PROPRIETE_1
- CAT_2_PROPRIETE_n
- ...
- CAT_m_PROPRIETE_1
- CAT_m_PROPRIETE_n

Je proposerai une sorte de "factorisation" a cela:
- ID_ARTICLE
- CATEGORIE_ARTICLE
- REF_1
- REF_2
- ...
- REF_p (au final, p<m+n, a toi de factoriser autant que tu peux)
Avec une table CATEGORIE dont les champs seraient :
- ID_CATEGORIE ex1: 4783 / ex2: 3822
- DESCRIPTION_CATEGORIE ex1: Plaques Acier / ex2: Tuyaux testés
- DESCRIPTION_REF_1 ex1: Épaisseur / ex2: Diametre
- DESCRIPTION_REF_2 ex1: Largeur / ex2: Paroi
- ...
- DESCRIPTION_REF_p ex1: Type d'acier / ex2: Longueur

Les différentes descriptions viennent alimenter les labels de tes différents controles texte de ton formulaire principal, en fonction de CATEGORIE_ARTICLE, sur l'evenement Form_Current.

Citation:

---

Envoyé par Jean-Jacques Engels

PS : L'héritage n'existe qu'en programmation orientée objets si je ne m'abuse.

---

L'héritage est le concept selon lequel une entité (une classe) hérite des attributs (des propriétés) d'une autre. Ce ci se représente très facilement en MCD Merise ou en diagramme des classes UML et peut donc être implanté en base de données.

Exemple :
Personne -0,n----Etre----1,1- Salarié
Personne -0,n----Etre----1,1- ContactClient

On voit très bien ici que Salarié et ContactClient héritent de Personne.

On peut ainsi avoir les tables :
T_Personnes_P(P_Id, P_Nom, P_Prenom, ...)
T_Salaries_S(S_Id, S_IdPersonne, S_Salaire, ...)
T_ConctactsClients_CC(CC_Id, CC_IdPersonne, CC_IdEntreprise, ...)

Il suffit d'adapter ceci à votre cas, après un peu de lecture chez notre cher SQLPro.
Je précise que j'ai écrit ma réponse avant de voir qu'il avait écrit quelque chose sur le sujet donc sa méthode est peut-être différente de la mienne, pas le temps de lire maintenant.

Bonjour CinePhil,

Ce n'est pas trop le sujet de la discussion, mais j'ai une idée différente de la notion d'héritage.

On pourrait réellement parler d'héritage dans l'exemple que tu donnes si on pouvait faire ceci :

Code:

---

1 2 3 4

CREATE TABLE Personnes (Id Integer not null Primary, Nom varchar (35) not null, Prenom varchar (35) not null, ...)

---

Puis avoir une commande du genre :

Code:

---

1 2	CREATE TABLE Salaries Inherited Personne (Salaire Numeric(9,2) not null, ...)

---

et enfin lancer le query :

Code:

---

1 2	SELECT Id, Nom, Prenom, Salaire FROM Salaries

---

Dans ce cas, grâce à l'option Inherited Personne, la table Salaries possèderait automatiquement, ou "hériterait", de tous les champs de la table Personne.

Voilà donc l'idée que je me fais de l'héritage.

Bien à toi.

JJE

hello
Bravo alassanediakite, j'aime bien ta solution, j'appelle ça passer de colonnes en lignes.
Avant, je rajoutais des colonnes à chaque fois que j'en avais besoin. Ensuite j'ai essayé de leur donner des noms génériques, col1, col2, col3 ...
dont je remplace les intitulés sur formulaires et états suivant les utilisations: par exemple si poudre col1 = granulométrie, si mousse col1 = densité
le problème de ça est que c'est difficilement paramétrable, que la table est strictement illisible, que la gestion est en VB, et surtout qu'il manque toujours des colonnes

dans le modèle en ligne, on peut rajouter autant de lignes qu'on veut, y mettre les noms de propriétés les plus adapté et comme on présente les propriétés dans un sous formulaire, on n'a aucun ennui pour afficher 2 propriétés où 15

on peut même présenter ce sous formulaire comme si le nom de la propriété étais une étiquette
on peut aussi suivant les produits et d'après une table paramétrage ajouter d'office un certain nombre de lignes avec les noms des propriétés à renseigner suivant le type de produit

par contre, pour moi, l'Idpropriete n'est pas nécessaire, je préfère une clef double sur idproduit, nompropriete qui me garanti bien que je ne mets pas deux fois la même propriété sur le même article
et enfin, j'ai deux champs pour la valeur de la propriété, une pour les valeurs numériques et une pour les valeurs texte

A bientôt