conception de base de données

conception de base de données - SQL/NoSQL - Programmation

Marsh Posté le 05-07-2011 à 11:11:04    

Bonjour,
En premier lieu, merci d'avance !
 
Je me présente -succinctement- je suis en charge des services généraux dans un cabinet comptable (donc pas informaticien même si c'est ma marotte) et sollicite donc votre aide pour la conception d'une base de données.
J'ai beau avoir passé des heures sur internet à rechercher des infos sur le processus de création, il me manque clairement des connaissances en la matière pour m'en sortir - en plus du vocabulaire :/
 
Pour faire simple, nous utilisons actuellement une table access pour la gestion des archives papier (dossiers clients), avec pas loin de 10,000 lignes, celle-ci montre clairement ses limites. La recherche ou l'entrée de données n'est pas des plus aisé, de plus à la création personne n'a pensé à ajouter des champs pour gérer l'emplacement des dossiers ou leur externalisation (gérée dans une suite de fichiers excel). En un mot c'est le bordel!
 
Donc je souhaiterai remplacer ces différents fichiers par une unique base de données (mysql) et quelques pages php-html pour les recherches dans la base, modifications, ajouts, chercher précisément où est le dossier (à la cave, désarchivé, externalisé)...
Mon problème étant que la conception de la base m'échappe complètement (je pourrais bâcler un truc avec une table unique comme le fichier access en y ajoutant les infos sur l'externalisation, mais je n'apprends rien, ça sert pas à grand chose et puis j'aime pas bâcler!).
 
Comme une image vaut 1000 mots et que j'ai déjà pas mal bavassé, voici (en gros) les informations dans la base.
 
http://0140080813.free.fr/post.JPG
 
Pour ce qui est des détails:
1 archive = 1 classeur et donc un emplacement unique (sauf à le casser en 2 ^_^)
je ne pense pas que l'on puisse faire des tables Clients ou Affaires, dans la mesure ou un n°client s'entend pour la maison mère et ses filiales et donc le champ "nom client" peut varier pour un même "N° client", pas hyper logique mais c'est historique; c'est globalement idem pour les Affaires.
Le nombre de salles ou armoires dans la cave ne devrait pas varier dans l'avenir.
 
Merci à vous qui avez lu jusque là! Et par avance merci à ceux d'entre vous qui pourrez m'aider dans ce petit projet.

Reply

Marsh Posté le 05-07-2011 à 11:11:04   

Reply

Marsh Posté le 05-07-2011 à 13:11:12    

j'ai trouvé 2/3 docs supplémentaires sur le net qui m'ont permis un peu d'y voir plus clair.
 
Est-ce ça vous semble logique ou je délire? c'est vite-fait
 
http://0140080813.free.fr/test.png

Reply

Marsh Posté le 05-07-2011 à 13:39:31    

Juste une petite remarque vite fait : plutôt que de réinventer la roue, tu devrais peut-être regarder du côté des logiciels de gestion électronique de documents (GED) (ou ECM en anglais).
 
D'autant qu'il existe plein de solutions gratuites, si vous ne pouvez pas mettre un centime dans ce projet.

Reply

Marsh Posté le 09-07-2011 à 01:26:42    

lakuka a écrit :

j'ai trouvé 2/3 docs supplémentaires sur le net qui m'ont permis un peu d'y voir plus clair.
 
Est-ce ça vous semble logique ou je délire? c'est vite-fait
 
http://0140080813.free.fr/test.png


Salut
 
Bon ben tu as déjà des notions de schéma relationnel et cela devrait être pas mal. Tout ce qu'il faut savoir, c'est que
- deux infos liées l'une à l'autre par une relation 1-1 vont dans la même table => exemple: pour une personne, son nom va avec son âge => inutile de créer une table "personne" et une table "âge" => tu regroupes le nom et l'âge dans la même table
 
- deux infos liées par une relation 1-n font 2 tables => l'info qui y est "n" fois a sa propre table et récupère l'identifiant de l'info qui y est une fois => exemple: une personne peut avoir plusieurs voitures mais chaque voiture n'a qu'un seul propriétaires => la table "voiture" stockera l'identifiant de son propriétaire
 
- deux infos liées par une relation n-n font 3 tables => chaque info à sa propre table et une table de liaison sert à stocker la relation  => exemple: un livre peut être édité par plusieurs éditeurs et un éditeur peut éditer plusieurs livres => il faudra une table "livre", une table "éditeur" et une table de jointure qui stockera l'identifiant du livre et l'identifiant de l'éditeur. Si jamais une information particulière dépend de la jointure (comme par exemple la date d'édition), cette info sera stockée aussi dans la table de jointure
 
A partir de là, tu as tout pour faire une belle base bien solide...


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 10-07-2011 à 11:07:17    

Je suis entièrement d'accord avec shaoyin. Développer un soft de GED n'est pas ton coeur de métier, tout ce qui va se passer, c'est pour toi, perdre beaucoup de temps (même si tu vas apprendre) pour aboutir à un résultat au mieux pas trop pourri mais qui sera difficilement maintenable :/
 
Je te recommande Alfresco comme outil de GED. C'est gratuit (car sous licence GPL) et y'a du support (communauté). En plus, si y'a des bugs, la version suivante les corrigera ;)


Message édité par rufo le 10-07-2011 à 11:07:59

---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 14-08-2011 à 09:53:08    

Ouep Alfresco est le must have en GED open source. Par contre, très compliqué à mettre en oeuvre.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed