Structuration d'une base Société

[SkyCorp]

Bonjour à tous,

Je souhaite mettre en place une base de données Société.
Plusieurs points importants :
* Une société peut comporter 1 ou plusieurs départements, qui peut comporter 1 ou plusieurs services (j'arrête là la décomposition, mais si ça se trouve, il existe des structures encore plus complexes)
* Chaque société comporte 1 ou plusieurs numéros de téléphone, 1 ou plusieurs adresses, 1 ou plusieurs emails. Idem pour les départements et les services.

Dans mon formulaire, l'utilisateur choisi une société dans une liste déroulante,
puis un département s'il y en a, dans une liste déroulante qui dépend de la précédente,
puis un service s'il y en a, dans une liste déroulante qui dépend de la précédente.

Voilà pour la théorie. Dans la pratique, j'ai commencé à faire ce qui ressemble à une usine à gaz, avec des tables de jonctions, .... Et dès que j'ai réfléchi aux listes déroulantes, je n'ai pas su comment les mettre en place..

Que pouvez-vous me conseiller ?

Merci d'avance

 

[Dranreb]

Re : Structuration d'une base Société

Bonsoir.
Si tout est rangé dans un tableau avec une colonne pour chaque chaque chose le plus simple à programmer c'est d'utiliser un objet ComboBoxLiées que j'ai créé. On n'a plus à s'occuper du tout des ComboBox.
L'UserForm ne voit plus qu'une sorte de Super-ComboBox virtuelle qui au lieu de lui renvoyer un ListIndex renvoie la liste des numéros de lignes dans le tableau qui correspondent à l'ensemble des choix effectués dans tous les ComboBox dont on lui a confié la charge. Il s’occupe bien évidemment d’abord de garnir leurs List de façon pertinente. C'est à dire par des listes classées et sans doublon, compatible avec les choix déjà effectués, voire la seule valeur possible assumée d'office.

 

[SkyCorp]

Re : Structuration d'une base Société

Mes téléphones, adresses et emails sont dans des tables à part, plus simple à gérer selon moi. Pour la structuration de la société, après réflexion, je l'ai incluse dans la même table.
Pour les ComboBox liées, je n'ai encore jamais fait ça et je trouve plusieurs pistes sur le net, mais rien de concluant. Comment puis-je faire ? Aurais-tu un exemple sous le coude ?
Merci d'avance

 

[Dranreb]

Re : Structuration d'une base Société

J'ai les modules de service. C'est votre classeur avec la base et l'UserForm que j'attends pour l'en équiper.
Sinon récupérez les d'un classeur nommé de la forme CBxLiéesDemandeur.xlsm joint à mes plus récentes discussions.

Je joins le dernier en date.

 

[SkyCorp]

Re : Structuration d'une base Société

Je suis sous Access

 

[Dranreb]

Re : Structuration d'une base Société

Je n'avais pas vu. Désolé. Je n'ai pas Access.

 

[chris]

Re : Structuration d'une base Société

Bonjour

Il faut :

• une table des sociétés
• une table des départements de sociétés : ID société + Id département et autres infos département. La relation est directe entre société et départements.
  Si tu normalises les départements (compabilité, RH, etc existe dans toutes es sociétés) tu peux effectivement avoir une liste de référence des départements en relation avec ta table départements de sociétés dont le champ type département pourrait être alimenté par une liste déroulante basée sur cette table. Néanmoins cela n'a d'intérêt que si la typologie des départements a un intérêt opérationnel, si on a besoin par exemple de cibler toutes les RH
• pour les services soit on adopte la même logique mais dans ce cas cela implique une structure similaire de toutes les sociétés.
  Il serait probablement plus simple de les stocker dans la même table que les départements avec un champ précisant département ou service et l'ID de rattachement le cas échéant.
  C'est comme une table de personnes : chaque personne peut avoir un parent dans la table; on indique dont l'ID du parent dans la zone de rattachement de l'enfant.
  Ce rattachement permet de construire tout l'arbre. Des outils existe dans Oracle pour construire les arbres, dans Access ce n'est pas prévu mais on en a rarement besoin.
  Comme pour toute décision lors de la modélisation, il faut mettre à plat les besoins d'exploitation avant de décider de la structure.

 

[SkyCorp]

Re : Structuration d'une base Société

Merci chris,

Pour l'instant, j'ai opté pour 3 tables séparées. Ca me permettra de faire des zones de liste déroulante synchronisées (c'est la seule solution à ma connaissance).
A présent, je cherche à créer une table ou une requête, avec :
- dans la 1ère colonne, un ID unique
- la 2ème colonne reprend toutes les sociétés
- la 3ème colonne reprend tous les départements
- la 4ème colonne reprend tous les services

Il faut pour chaque société, un ID qui l'identifie sans département, qu'elle en ait ou non. Idem pour les départements, il faut un ID qui l'identifie sans service.
Je pourrai alors relier cette table à une table adresse, une table téléphone, une table employés, ...

Comment pourrai-je créer cette table ou requête ?

 

[chris]

Re : Structuration d'une base Société

Re

Sans la structure des tables on ne peut répondre...

 

[SkyCorp]

Re : Structuration d'une base Société

Voilà une première tentative, qui ne me convient pas telle quelle pour ma table Structures

La structure de la table Structures serait quelque chose comme ça :


Peut-être passer par une requête aiderait, mais comment mettre ça en place pour obtenir un ID propre à cette requête ?

 

[chris]

Re : Structuration d'une base Société

Bonjour

C'est très peu lisible : je déchiffre à peine...

1ere remarque les tables de références (types structures juridiques et autres) devraient aussi être en relation 1 à N avec intégrité référentielle.

Comme je l'ai dit la structure de la base doit dépendre du contexte et des besoins opérationnels : je ne sais toujours pas ce que tu dois gérer, comment et pourquoi or c'est cela qui permet le choix entre plusieurs structures de bases.

Exemple si je vends des produits je peux

• soit stocker le prix de vente unitaire du produit dans la table du produit.
  Cela implique
  • de disposer du champ prix de vente dans les lignes de facture
  • de basculer la nuit les changements de prix
• soit créer une table de prix avec les dates de validité des prix :
  • on peux préparer les prix à l'avance
  • on n'a pas besoin du champ dans les lignes de facture car on sait le retrouver à la date d'émission
  • on peut analyser l'évolution des prix dans le temps

Les deux solutions sont bonnes mais on choisira en fonction de l'organisation et des besoins.

Le peu que j'arrive à lire de tes images montrent une structure complexe : se justifie-t-elle ? Je ne sais pas.

Pour répondre à ta question : une requête n'est qu'un interrogation des données stockées dans les tables. Elle ne contient aucune donnée, juste la "question" donc pas d'ID ou éventuellement un ID volatile regénéré à chaque fois qu'on exécute la requête mais qui n'a donc pas de sens en tant que repère...

 

[SkyCorp]

Re : Structuration d'une base Société

Désolé pour la résolution, c'est le site qui l'a modifié.

L'objectif est de gérer une base de contacts et de sociétés.
Dans le cadre des sociétés, je souhaite visualiser rapidement et facilement les coordonnées (email, tel, adresses), la structuration en départements et services si elle est présente, l'organigramme et les employés connus pour chaque service/dpt/société suivant la structuration de la société, les activités, les horaires de contact, les dates de fermeture (pour éviter d'appeler à ces dates)...
Je suis susceptible d'aller plus loin en vue de connaitre la santé de l'entreprise, les affaires et clients connus, les évènements majeurs (acquisition, fusion, ...), ...

Bref, il y a pas mal d'info à gérer

 

[chris]

Re : Structuration d'une base Société

RE

Il faut toujours joindre l'image en pièce jointe : ainsi en plus de l'image réduite on a la source.

D'un point de vue conception une seule notion de sous structure avec la référence du niveau supérieur suffit à descendre un organigramme : ce que semble être ta table de jointure entre structure et structure.

Cependant seules les SGDBR avancés, ORACLE, SQL server, POSTGRESQL disposent dans leurs possibilités SQL de celle de partir du sommet et de descendre l'arbre par requête.

Si le nombre de niveaux n'est pas trop important, disons 5 maxi on peut pour descendre l'organigramme enchaîner plusieurs requêtes et faciliter en donnant le niveau (0 = structure, 1 = département, 2 = service, etc) de chaque structure/sous-structure.

Il faut alors bien réfléchir aux champs de la table d'une part et à la façon de saisir/maj ces données.

Après je pense qu'il faut rattacher les personnes à une structure. Pour les données de contact de ces personnes, ou les adresses des sociétés, la plupart des applications de gestion, stockent effectivement toutes les adresses dans une même table...

Je ne sais combien d'entités tu comptes gérér ni combien d'utilisateurs vont utiliser la base mais j'ai peur qu'Access soit un peu léger...

 

[SkyCorp]

Re : Structuration d'une base Société

C'est bon, j'ai attaché les 2 images

Concernant ma table de jonction structure-structure, elle est destinée à préciser les liens entre différentes sociétés, du style maison mère - filiale, succursales, actionnaires, ...
J'avais pensé mettre mes liens société-département, et département-service, mais je bloque au niveau de l'un des formulaires dans ce cas. En effet, ce formulaire contient une zone de liste déroulante qui permet de sélectionner une société, et qui actualise une seconde zone de liste déroulante synchronisée qui permet de sélectionner un département. Idem pour sélectionner un service avec une 3è zone de liste déroulante synchronisée à cette seconde zone de liste déroulante.
Le seul moyen que je connais est de le faire avec des tables séparées.

Maintenant que j'y pense, il y a peut-être moyen de faire quelque chose avec une seule table + la table de jonction. Je vais tester mon idée.

Par contre, pour les autres SGDBR, pas sur que je m'y mette tout de suite. Access a cela de bien qu'il est relativement simple de concevoir une interface sympathique, et qu'il est fourni avec mon pack Office. Donc pas besoin d'acheter un autre produit. Mais je me trompe peut-être.
Il faut dire aussi qu'il s'agit de ma première base Access et j'ai passé du temps pour comprendre les rouages de base du logiciel. Et je me vois mal repasser autant de temps pour un autre logiciel. Il faut dire que ça change pas mal d'Excel, que je maitrise bien mieux.

 

[chris]

Re : Structuration d'une base Société

Re

C'est bon, j'ai attaché les 2 images

attachées mais as en pièce jointe donc pas plus grand. Il faut faire comme pour joindre un Excel.

...
J'avais pensé mettre mes liens société-département, et département-service, mais je bloque au niveau de l'un des formulaires dans ce cas. En effet, ce formulaire contient une zone de liste déroulante qui permet de sélectionner une société, et qui actualise une seconde zone de liste déroulante synchronisée qui permet de sélectionner un département. Idem pour sélectionner un service avec une 3è zone de liste déroulante synchronisée à cette seconde zone de liste déroulante.
Le seul moyen que je connais est de le faire avec des tables séparées.

Il y a une ambiguïté dans ce que tu décris : est-ce la consultation ou a saisie ?
Car en saisie on n'a pas de liste déroulante sauf pour éventuellement rattacher le département que l'on crée pour la société machin à une catégorie normalisée et idem pour les services.
En consultation si on veut chercher une service ou un département, une liste déroulante peut filtrer des départements ou les service en requêtant sur une même table...

...Access a cela de bien qu'il est relativement simple de concevoir une interface sympathique, et qu'il est fourni avec mon pack Office. Donc pas besoin d'acheter un autre produit. Mais je me trompe peut-être.
Il faut dire aussi qu'il s'agit de ma première base Access et j'ai passé du temps pour comprendre les rouages de base du logiciel...

Access fournit en effet et un moteur de SGBDR et un atelier logiciel pour construire les interfaces.
Cependant c'est un peu la Twingo comparée à la Ferrari Oracle.
L'avantage des bases de données relationnelles est que, si les concepts sont un gros morceau à avaler, c'est les mêmes quel que soit le moteur.