Discussion :

[baptistehgc]

Bonjours à tous,

Pas évident pour tout le monde la conception des tables et des relations...



Auriez-vous une idée pour regrouper ces différentes données:



"Numero client"

"Nom client"

"Structure client" (public ou privé)

"Précision structure client" (particulier; societe; commune; communauté de commune; ASA; ASL; CG; autre)

"Sous précision structure client" (agricole; industrielle; service; agglo; sivom; sivu)





Cela en sachant que les "précisions structure client": particulier; societe caractérisent les "structure client" privé

"précisions structure client": commune; communauté de commune; ASA; ASL; CG; autre caractérisent les "structure client" public


et, les "sous précision structure client": agricole; industrielle; service caractérisent les "précision structure client" societe

"sous précision structure client": agglo; sivom; sivu caractérisent les "précision structure client" communauté de commune



Je ne vois pas comment créer les tables pour établir ces liens puisqu'une "structure client" est caractérisé par une "précision structure client" et une "précision structure client" peut caractériser plusieurs "structure client".

Donc relation 1 à plusieurs entre "structure client" et "précision structure client"

relation 1 à plusieurs entre "structure client " et "sous précision structure client"

relation 1 à plusieurs entre "précision structure client" et "sous précision structure client"



Eventuellement, j'ai pensé avec une table "structure":
N° structure

structure client
précision structure client
sous précision structure client



Cette table "structure" serai reliée à la table "client":
N° client

nom client

N° structure

D'autre tables permetrai d'établir les relations un à plusieur entre "structure client"; "précision structure client"; "sous précision structure client".



Je ne suis pas sur que ce système soit pratique et je ne suis pas sur non plus qu'il soit réalisable...

Qu'en pensez-vous?

Merci d'avance

[Richard_35]

Bonjour Baptistehgc,

Pas évident pour tout le monde la conception des tables et des relations...

==> ta manière d'exposer ta problématique montre que tu te débrouilles plutôt pas mal !

D'après ce que je comprends, pour un client :

• "Structure" ne peut pas être NULL (public ou privé) ;
• "PrécisionStructureClient" ne peut pas être NULL (particulier; societe; commune; communauté de commune; ASA; ASL; CG; autre) ;
• "SousPrécisionStructureClient" peut être NULL (pour "PrécisionStructureClient"=commune, par exemple).

Est-ce bien cela ?

[Saintelaitlait]

Salut!

Perso, j'hésiterais entre deux approche.

Premièrement, tu fait 4 tables.

Donc une table de client
[id_client]
[nom_client]
[id_structure]

table structure
[id_structure]
[nom_structure]
[desc]
[prec_struc]

table prec_Struc
[id_prec_struc]
[nom_prec_struc]
[desc]
[sous_prec_struc]

table sous_prec_struc
[id_sous_prec_struc]
[nom_sous_prec_struc]
[desc]


Dans une autre optique (peut-être pas très propre), la méthode présentement utilisée par un système dans ma boîte, le principe de parent.


Admettons que tu veux avoir le nom et la description des structures, des précisions de structure et des sous précisions de structure.

Tu fait une table avec tout dedans. Tu ajoute le champ struc_parent.

Donc pour suivre ton exemple :

table struc

[id] - [nom] - [desc] - [parent]

[s01] - [privé] - [privé] - [NULL]
[s02] - [public] - [public] [NULL]
[s03] - [particulier] - [particulier] - [s01]
[s04] - [societe] - [societe] - [s01]
[s05] - [commune] - [commune] - [s02]
[s06] - [communauté de commune] - [communauté de commune] - [s02]
[s07] - [ASA] - [ASA] - [s02]
[s08] - [ASL] - [ASL] - [s02]
[s09] - [CG] - [CG] - [s02]
[s10] - [autre] - [autre] - [s02]
[s11] - [agricole] - [agricole] - [s04]
[s12] - [industrielle] - [industrielle] - [s04]
[s13] - [service] - [service] - [s04]
[s14] - [agglo] - [agglo] - [s06]
[s15] - [sivom] - [sivom] - [s06]
[s16] - [sivu] - [sivu] - [s06]


Dans le fond chaque record est un peu comme un noeud avec son parent.

Après ca je dit ca je dit rien! Si ca fait ton affaire j'en suis bien content!

Bonne journée

[JLCantara]

Autre solution: voir BD attachée...

JLCantara.

[baptistehgc]

Richard,

"Structure" ne peut pas être NULL (public ou privé) ;
"PrécisionStructureClient" ne peut pas être NULL (particulier; societe; commune; communauté de commune; ASA; ASL; CG; autre) ;
"SousPrécisionStructureClient" peut être NULL (pour "PrécisionStructureClient"=commune, par exemple).

---Oui c'est bien cela.

Merci pour vos infos les autres; j'ai finalement crée 7 tables:

Client
[N° client]
[Nom client]
[Ref structure]

Nom entier structure client ( c'est à ce niveau que je bloquai, car j'ai remarqué que les ID ou N°.. doivent représenter un ensemble qui ne varira pas; or, si je fais 4 tables avec ID structure, je crois qu'à partir de la table client, on ne peut pas connaitre la précision structure ...)
[N°nom entier structure]
[Ref structure]
[Ref precision structure]
[Ref sous precision structure]

structure
[N° structure]
[libelle structure]

precision structure
[N° precision structure]
[libelle precision structure]

sous precision structure
[N°sous precision structure]
[sous precision structure]

puis 2 tables pour établir les liens:

structure/precision structure
[N°structure]
[N°precision structure]

precision structure/sous precision structure
[N°precision structure]
[N°sous precision structure]

Voila, le systeme à une table j'y avais pensé, mais bon... on m'a dit: autant utiliser excel si c'est pour faire une seule table..



J'ai un autre bout de ma base de données à faire qui est plus complexe..
Je vous l'expose ici, c'est un peu le meme sujet


Pour chaque dossier on a des infos sur le thème du dossier.

Pour chaque thème, différentes caractéristiques
La premiere: sous theme
Puis, en fonction du sous theme: objet; nature; traitement; pollution; type ressource
En fonction de l'objet: sous objet
Et en fonction de la nature: sous nature

Thème: eau ou sol

Pour Theme eau;
Sous thème: eau superficielle; eau souterraine; eau pluviale; eau usée

Pour Theme sol;
Sous theme: sol pollué; geothermie; geotechnique; decharge; cimetiere; materiaux gisement; autre
Pour le theme sol; , les infos s'arretent à sous theme, pas de précision supplémentaire.

Pour les sous thème qui caractérisent le theme eau; d'autres infos

Sous thème eau superficielle;
Nature: eau potable ---sous nature: conditionnee; non conditionnee
eau recreative --- pas de sous nature
eau irrigation--- pas de sous nature

Objet: cour d'eau--- pas sous objet
captage---sous objet: pompage; prise gravitaire
barrage---pas sous objet
plan eau---pas sous objet
retenue collinaire--- pas sous objet
digue---pas sous objet
canal---pas sous objet
fosse---pas sous objet

Pollution: nitrate; pesticide; turbidite; hydrocarbure; PCB; autre

Sous theme eau souterraine:
Nature: eau potable---sous nature: non conditionnee; conditionnee
eau minerale naturelle---pas sous nature
eau recreative---pas sous nature
eau irrigation---pas sous nature

Objet: captage---sous objet forage; source; puits
nappe/acquifere

Type ressource: libre
captive

pollution: nitrate
pesticide
turbidite
hydrocarbure
PCB

Sous theme eau pluviale

Traitement: bassin/noue
chausse reservoir
puits infiltration

Pollution: turbidite
hydrocarbure
autre

Sous theme eau usee

Nature: domestique---sous nature STEP;non collectif
agricole---sous nature vinicole; distillerie; autre

traitement: FSTE
epandage
bassin evaporation
autre

Pollution: MO
pesticide
autre

On doit pouvoir choisir plusieurs themes; plusieurs sous theme; plusieurs natures; plusieurs objets; plusieurs pollutions; plusieurs type ressource et plusieurs traitements ci besoin.


L'objectif serai d'avoir un enregistrement pour chaque dossier,
et de réunir ces info dans une table (une table qui caractériserait le thème et ses précisions; en sachant qu'à partir de cette table, on doit pouvoir savoir quelle "pollution"-par ex- a subi le dossier correspondant)qui serai elle meme reliée à la table principale dossier...

Cela est il possible; avez vous une idée pour regrouper ces infos?

[baptistehgc]

Je suis finallement repassé à 5 tables et non 7; je n'arrivais pas à relier les table "structure/precision structure" ni "precision structure/sous precision structure"

[f-leb]

Bonjour,

Ces histoires de machin, sous-machin, sous-sous-machin etc. sont toujours bien embêtantes à modéliser.

Nom entier structure client ( c'est à ce niveau que je bloquai, car j'ai remarqué que les ID ou N°.. doivent représenter un ensemble qui ne varira pas; or, si je fais 4 tables avec ID structure, je crois qu'à partir de la table client, on ne peut pas connaitre la précision structure ...)
[N°nom entier structure]
[Ref structure]
[Ref precision structure]
[Ref sous precision structure]

Ici on mélange les structures, précision et s/précision dans une unique table qui ressemble furieusement à un tableau Excel (et en violation de la 3ème forme normale si je ne me trompe pas).
Si on conserve cette table pour faciliter certains traitements liés à l’IHM, il faut s’attendre à d’autres traitements pour empêcher les incohérences, gérer les mises à jour, etc.

Je comprends que le schéma normalisé:
Structure-1-----∞-PrecisionStructure-1-----∞-SousPrecisionStructure ,
convient mal lorsqu’il s’agit de raccorder les clients à l’un ou à l’autre.

Le modèle hiérarchique présenté par Saintelaitlait présente alors bien des avantages :
Structure(idStructure, LibelleStructure, #idStructureParent)
Structure-∞------1-Structure_1

S’il n’y a pas trop de branches et que l’on limite le nombre d’étages sans rentrer dans des sous-sous-sous…structures, nous ne sommes alors pas obligé de rentrer dans le bazar des fonctions récursives normalement nécessaires pour parcourir l’arborescence.

[Richard_35]

Bonjour à tous ,

Sur la première partie de la discussion :

puis 2 tables pour établir les liens:
structure/precision structure
[N°structure]
[N°precision structure]

precision structure/sous precision structure
[N°precision structure]
[N°sous precision structure]

==> ces deux tables sont inutiles, si j'ai bien compris (pas de relation n,n).
En effet, de tes exemples, ressort :

• privé ==> particulier; societe
• public ==> commune; communauté de commune; ASA; ASL; CG; autre
• societe ==> agricole; industrielle; service
• communauté de commune ==> agglo; sivom; sivu

Donc, les tables suivantes sont suffisantes (souligné=clé primaire, #=clé étrangère) :

Structure(IdStructure, Libelle, ...) ==> public ou privé
PrécisionStructure(IdPrécisionStructure, Libelle, #IdStructure, ...) ==> particulier; societe; commune; communauté de commune; ASA; ASL; CG; autre
SousPrécisionStructure(IdSousPrécisionStructure, Libelle, #IdPrécisionStructure, ...) ==> agricole; industrielle; service; agglo; sivom; sivu

D'autre part, je ne vois pas trop l'intérêt de la table Nom entier structure client qui, à terme, contiendra l'ensemble des combinaisons possibles.

Enfin, pour la liaison avec les clients, deux possibilités :

1. Client(IdClient, Nom, #IdStructure, #IdPrécisionStructure, #IdSousPrécisionStructure, ...) ==> si l'on admet que #IdSousPrécisionStructure puisse être NULL (éternel débat...) ;
2. Client(IdClient, Nom, #IdStructure, #IdPrécisionStructure, ...)
   Client_SousPrécisionStructure(IdClient, #IdSousPrécisionStructure, ...)==> si l'on tient à ce que #IdSousPrécisionStructure ne soit pas NULL.

[baptistehgc]

"Donc, les tables suivantes sont suffisantes (souligné=clé primaire, #=clé étrangère) :
Structure(IdStructure, Libelle, ...) ==> public ou privé
PrécisionStructure(IdPrécisionStructure, Libelle, #IdStructure, ...) ==> particulier; societe; commune; communauté de commune; ASA; ASL; CG; autre
SousPrécisionStructure(IdSousPrécisionStructure, Libelle, #IdPrécisionStructure, ...) ==> agricole; industrielle; service; agglo; sivom; sivu
D'autre part, je ne vois pas trop l'intérêt de la table Nom entier structure client qui, à terme, contiendra l'ensemble des combinaisons possibles.

Enfin, pour la liaison avec les clients, deux possibilités :
Client(IdClient, Nom, #IdStructure, #IdPrécisionStructure, #IdSousPrécisionStructure, ...) ==> si l'on admet que #IdSousPrécisionStructure puisse être NULL (éternel débat...) "

J'ai utilisé ça, je crois que ça va fonctionner!
Merci à vous

Et, serriez vous comment faire s'il était possible d'avoir plusieurs sous précision?
(j'ai une autre partie qui se construit de la meme façon, mais dans laquelle plusieurs choix sont possible).

[Richard_35]

Et, serriez vous comment faire s'il était possible d'avoir plusieurs sous précision?

==> plusieurs "sous précision" par quoi, client ou précision ?

[baptistehgc]

Par précision (soit indirectement par client)
mais oui, directement, par précicsion

[Richard_35]

mais oui, directement, par précicsion

==> c'est déjà le cas avec :

SousPrécisionStructure(IdSousPrécisionStructure, Libelle, #IdPrécisionStructure, ...)

plusieurs IdSousPrécisionStructure vont pouvoir accepter le même IdPrécisionStructure.


Si la réponse à ta question était "par client", alors il faut opter pour la seconde solution proposée :

2. Client(IdClient, Nom, #IdStructure, #IdPrécisionStructure, ...)
Client_SousPrécisionStructure(IdClient, #IdSousPrécisionStructure, ...)

en transformant

Client_SousPrécisionStructure(IdClient, #IdSousPrécisionStructure, ...)
par
Client_SousPrécisionStructure(IdClient, #IdSousPrécisionStructure, ...)

[baptistehgc]

D'accord, merci!

Maintenant, je crois que c'est mon dernier problème ...

Citation:
Envoyé par baptistehgc
mais oui, directement, par précicsion

==> c'est déjà le cas avec :
SousPrécisionStructure(IdSousPrécisionStructure, Libelle, #IdPrécisionStructure, ...)
plusieurs IdSousPrécisionStructure vont pouvoir accepter le même IdPrécisionStructure.
Mais avec une relation de plusieurs à plusieurs entre SousPrecisionStructure et PrecisionStructure

[Richard_35]

Mais avec une relation de plusieurs à plusieurs entre SousPrecisionStructure et PrecisionStructure

==> tu avais précisé qu'il y avait

PrecisionStructure -1---∞- SousPrecisionStructure

Mais bon, si

PrecisionStructure -∞---∞- SousPrecisionStructure

alors, au lieu de

PrécisionStructure(IdPrécisionStructure, Libelle, #IdStructure, ...)
SousPrécisionStructure(IdSousPrécisionStructure, Libelle, #IdPrécisionStructure, ...)

il faut

PrécisionStructure(IdPrécisionStructure, Libelle, #IdStructure, ...)
SousPrécisionStructure(IdSousPrécisionStructure, Libelle, ...)
PrécisionStructure_SousPrécisionStructure(#IdPrécisionStructure, #IdSousPrécisionStructure, ...)

Je te suggère de lire cet excellent billet de CinePhil qui balaye tous les cas possibles des relations entre deux entités (table).

[Richard_35]

Juste un petit aparté concernant l'excellente suggestion de Saintelaitlait, résumée par le non moins excellent F-leb :

Le modèle hiérarchique présenté par Saintelaitlait présente alors bien des avantages :
Structure(idStructure, LibelleStructure, #idStructureParent)
Structure-∞------1-Structure_1

Personnellement, j'utilise cette méthode quand les attributs des entités parents et enfants sont les mêmes (ou très proches), exemple : les nomenclatures d'article (d'ailleurs nombre de GPAO utilisent cette méthode).

En revanche, quand les entités parents et enfants possèdent (ou pourraient posséder, à terme) des attributs propres, alors la méthode "arborescence qualifiée" me paraît meilleure. Par exemple :

"Précision structure client" (particulier; societe; commune; communauté de commune; ASA; ASL; CG; autre)

pourrait posséder, à terme, des champs qui n'auraient aucun intérêt pour

"Sous précision structure client" (agricole; industrielle; service; agglo; sivom; sivu)

Fin de l'aparté...

[baptistehgc]

Oui, mais c'était pour éviter de te redonner toutes les tables car c'était pour une autre partie.

Merci pour ta réponse