Oui mais il semble quand même que la phase de conception ait été sautée
si j'en juge par les remarques de docgrainville (je n'ai toujours pas ma
propre idée de ta base car je n'ai pas beaucoup de temps pour m'y
plonger). Certaines de ses remarques me laissent à penser que le modèle
des données n'est pas normalisé (pas de 1ère forme normale, semble-t-il,
ni peut-être de 2nde ou 3ème).
Bon, je ne vais pas te faire un cours sur les formes normales de E.F.
Codd, tu as du avoir l'occasion de les approcher quand tu travaillais
sur les principes des bdd relationnelles.
Bernard
Le 23/04/2010 14:53, Marie-Pierre CORONEL a écrit :
A docgranville : concernant l'utilisation de base en production, je te
recommande d'aller faire un petit tour sur le forum, tu verras qu'on
est de plus en plus nombreux sur le sujet... je réponds actuellement à
quelqu'un qui veut mettre sur base sont cahier des variables de paye
par exemple.
A Bernard,
sur la théorie c'est là que je suis la plus forte, j'ai même eu dans
le temps mon concours de rédacteur option programmeur sur... les
principes de la base de données relationnelle... C'est sur la mise en
pratique que 20 ans après je pêche :D
Le 23 avril 2010 13:08, ribotb<rib...@gmail.com> a écrit :
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
<mariepierre....@gmail.com> 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<docgranvi...@aol.com> 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: users-unsubscr...@fr.openoffice.org
For additional commands, e-mail: users-h...@fr.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org
For additional commands, e-mail: users-h...@fr.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org
For additional commands, e-mail: users-h...@fr.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org
For additional commands, e-mail: users-h...@fr.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org
For additional commands, e-mail: users-h...@fr.openoffice.org
