Par contre, il y a bien une erreur de conception que j'ai découverte ce soir. Cette erreur est issue des modifications qui m'ont été communiquées le 20 mars dernier alors que ma base était déjà toute montée... Il s'agit des critères ajoutés, attachés aux informations préalables, qui sont les mêmes que pour les médiations. Là c'est vrai, je n'ai pas réfléchi assez longtemps.
Le 23 avril 2010 19:20, Marie-Pierre CORONEL <mariepierre....@gmail.com> a écrit : > Et bien, je peux avoir fait des erreurs, mais il n'y a qu'à regarder > le nombre de tables à attribut unique pour voir que j'ai cherché à les > respecter. > > Après j'ai fait le choix de mettre dans une même table d'apparentes > redondances (les mêmes éléments d'information sur les deux parties) > mais ces éléments étant issus de tables, si les occurences changeaient > demain, elles changeraient pour les deux parties par exemple sans > qu'on soit obligés d'y veiller... > > Le 23 avril 2010 15:27, ribotb <rib...@gmail.com> a écrit : >> 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
