Bonjour Marie-Pierre, bonjour Docgrainville,
Je suis un peu vos échanges intéressants, aussi permettez-moi d'exprimer
mon point de vue sur la démarche à envisager éventuellement.
1) Je pense qu'il ne faut pas chambouler la base actuelle, surtout si
elle fonctionne de façon satisfaisante (je ne l'ai pas expertisée :-)
aussi je me garderais de me prononcer sur cet aspect des choses). Le
fait que OOo Base soit mono-poste n'est peut-être pas pour l'immédiat un
handicap s'il y a une seule utilisatrice.
Cette suggestion est le fruit de l'expérience :-)
2) On peut envisager parallèlement une refonte complète de la base (une
sorte de version 2) et sur ce point il y a deux aspects à prendre en
compte :
- l'aspect conceptuel
- l'aspect technique
3) La conception :
Il faut d'abord concevoir le modèle conceptuel des données qui consiste
à rechercher toutes les données à gérer, leurs règles de gestion,
définir les entités et les relations, ainsi que les contraintes;
La phase suivante consiste à normaliser le modèle. Il existe un certain
nombre de "formes normales" qui permettent d'avoir une base stable (elle
peut évoluer sans "bobos"), intègre malgré les mises à jour sur les
données, et sans redondance d'informations.
Les tables sont la matérialisation physique des relations définies lors
de la conception.
4) L'implémentation physique :
Il est certain que des "vrais" SGBDR (tels MySQL, PostgreSQL ou
Firebird) sont préférables à OOo Base pour une utilisation
professionnelle. Il n'en demeure pas moins que le modèle physique issu
de la phase conception peut être implémenté éventuellement avec OOo Base
(qui présente l'avantage de permettre de fabriquer assez simplement des
formulaires plus ou moins complexes.
Personnellement j'utilise Firebird (et aussi OOo Base, ça dépend du
"projet") comme serveur de bases de données et j'utilise IBEasy+ pour le
développement des applications. Je cite ce logiciel car il prend en
charge la phase conception (référentiel des données, manipulation des
concepts de base : domaines, relations, attributs, etc., conception
graphique de la base)
Vous me direz que ceci est très théorique mais mon propos n'était que de
suggérer à Marie-Pierre quelques axes de réflexion pour développer sa
future éventuelle base de données :-)
Bonne journée,
Bernard
Le 23/04/2010 11:29, Marie-Pierre CORONEL a écrit :
Ah et je suis parfaitement d'accord, le point d'entrée devrait être la
procédure. Mais le problème c'est qu'une procédure ne peut contenir
plusieurs conflits, alors qu'un même conflit peut contenir plusieurs
procédures...
Le 23 avril 2010 11:28, Marie-Pierre CORONEL
<[email protected]> a écrit :
En fait, ça m'évitait potentiellement d'ajouter un champ dans les
tables secondaires qui contienne civil ou pénal (un "connecteur" pour
savoir à quelle table on se branche) de manière à différencier la
médiation civile 0 de la médiation pénale 0. Mais évidemment, moi je
reste sur 2 procédures et toi tu défends la procédure unique :D
De mon côté, j'ai interrogé le service informatique de la mairie,
parce que si j'utilisais MySQL, ce n'est pas sur mon PC qu'il devrait
être installé mais sur l'un de leurs serveurs...
Le 23 avril 2010 10:37, Docgranville<[email protected]> a écrit :
Le 23/04/2010 09:45, Marie-Pierre CORONEL a écrit :
Salut,
Il y a quelque chose qui pourrait me permettre de réduire le nombre de
tables, c'est de jouer sur les clés (concaténation par exemple de
civ+numéro de médiation, pen+numéro de médiation). J'ai vu qu'il y
avait des fils sur le sujet dans le forum, mais prise par l'urgence,
je n'ai pas planché le sujet. Je vais aller voir, si ça peut se faire
sans programmation, ça allègerait considérablement la base.
Bonjour Marie-Pierre,
Je n'ai pas encore eu le temps de répondre utilement à ton message d'hier
soir, j'essaierai de le faire ce week-end.
En revanche, je ne vois pas bien par quel moyen la concaténation que tu
évoques pourrait être de nature à réduire le nombre de tes tables.
Pour moi, le point de départ de la réflexion, c'est que l'objectif de cette
base étant de gérer des procédures, il est indispensable que celles-ci
soient regroupées dans une seule et unique table ; je pense vraiment que, si
la médiation elle-même s'adresse aux personnes, la base de son côté,
constitue une aide à la gestion de la procédure et doit donc être centrée
sur elle ; en conséquence, le numéro d'identification unique de la procédure
(la clef primaire dans la table regroupant les procédures) servira ensuite
dans les autres tables, à identifier les personnes concernées par cette
procédure, les évènements affectant cette procédure, etc, etc... ; et je
pense que ça facilitera grandement la sortie de statistiques (parce que
elles, j'imagine bien qu'elles portent sur les procédures, pas sur les
personnes).
D'ailleurs, l'ambigüité que tu soulignais entre le nom et la fonction de ta
table Demandeurs, vient (selon moi) du fait quelle a une double fonction :
identifier les parties ET marquer la saisine du service ; même si elles sont
intimement liées (s'il n'y a pas de personnes, il n'y a pas de conflit et
donc pas de médiation) et qu'une distinction peut paraître artificielle, je
crois préférable (pour la souplesse d'utilisation et de maintenance
ultérieure de ta base, d'enregistrer dans des tables séparées les données
relatives aux procédures d'une part et celles relatives aux personnes
concernées d'autre part.
Il me semble que c'est cette démarche là qui devrait te permettre de réduire
un peu le nombre de tes tables.
A+
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
