Discussion :

[DamKre]

Bonjour.

Je me suis lancé le défi ( assez étonnant, je sais ) de créer une base de données qui simulerait une "gestion" d'élections par "vote électronique".
Je pense que cela devrait être possible avec Access.

Dans ce "programme", se trouvent :

• les différentes élections ( de type nationales ou communales/municipales ) ;
• les différentes villes ;
• les listes des partis et les candidats par parti ;
• la liste des électeurs et s'ils ont voté ou non ;
• les résultats.

Lors de chaque élection :

• il faut déterminer le type, la date, ... ;
• il faut une liste des électeurs ( elle sera importée ) - avec la ville pour chacun d'eux ;
• il faut encoder, pour chaque ville, les différents partis politiques ( sachant qu'un parti peut présenter une liste dans la ville A, dans la ville C, ... mais peut-être pas dans la ville B ) ;
• il faut encoder, pour chaque liste, les différents candidats ( un candidat ne se présente que dans une seule liste ) ;
• un électeur ne vote que pour les listes de sa ville et peut choisir de mettre sa voix soit à une liste, soit à un candidat d'une liste, soit de voter "blanc" ( = ne choisir aucune liste ou aucun candidat ) ;
• les résultats d'une liste sont le total des voix en tête de liste + les voix de chaque candidat.

La première étape consiste donc à prévoir les tables et les liens entre elles. La conception des formulaires et rapports sera la seconde étape ( et ne me semblera pas être un problème insurmontable ;-) ).

Voici dès lors le début de ma réflexion :

Table "T_Elections"

• Id_Ele
• Ele_Type ( Nationale ; Communale )
• Ele_Date
• [Autres renseignements]

Table "T_Villes"

• Id_Ville
• Vil_Nom

Table "T_Electeurs"

• Id_Elt
• Elt_Ville ( -> Ville de l'électeur -> choix d'une des villes encodées )
• [Autres renseignements]
• Elt_AVote (Oui/Non)

Il manque donc les tables pour gérer les listes et leurs candidats. J'hésite entre une table commune "Listes + Candidats" ou deux tables différentes. Quels liens prévoir avec les villes ?

En ce qui concerne la gestion des résultats, un champ "nombre de voix" pour chaque candidat et pour chaque liste ?
Comment gérer également les votes "blancs" ? Une liste "Vote blanc" ?

Comment prévoiriez-vous les jointures ? Relations "classiques" ? Table(s) de jointures ?

Quelles autres tables feriez-vous également ?

Voyez-vous peut-être des choses auxquelles je n'ai pas pensé ?

Merci de votre aide !

[marot_r]

Bonjour.

Tu vas garder le détail de chaque vote ou tu vas faire seulement un cumul ?

Quand une personne vote pour une liste, Est-ce que chaque candidat est supposé avoir 1 vote ?

Pour les votes blanc, je créerai une liste "Votes Blancs", avec comme candidat "M/Mme Vote BLanc".

Après ce n'est plus qu'une liste parmi d'autre est évite d'avoir à faire un traitement spécifique pour elle.

A+

[DamKre]

Bonjour et merci de te pencher sur cette demande.

Tu vas garder le détail de chaque vote ou tu vas faire seulement un cumul ?

Je n'avais pas pensé à cela.
En principe, le vote est secret : un simple cumul devrait être suffisant.
Cela étant, on peut être amené à contrôler son propre vote et donc de savoir pour qui on a voté.
Donc, garder le détail de chaque vote ( par électeur ? ) peut être grandement intéressant.

Quand une personne vote pour une liste, Est-ce que chaque candidat est supposé avoir 1 vote ?

Non.
Par contre, si la liste X récolte 10 votes et le candidat TrucMachin de la liste X en récolte 78, la liste X doit avoir au final 10+78 = 88 votes.

Pour les votes blanc, je créerai une liste "Votes Blancs", avec comme candidat "M/Mme Vote BLanc".
Après ce n'est plus qu'une liste parmi d'autre est évite d'avoir à faire un traitement spécifique pour elle.

Je chipote peut-être, mais je serais plutôt partisan d'avoir une procédure spécifique à ce sujet.
Si les votes personnels sont sauvegardés ( voir la première question concernant le détail de chaque vote ), cette procédure me semble faisable.

Merci encore ;-)

[marot_r]

Un vote blanc est un vote donc voter pour un candidat "Vote blanc" permet de garder le même processus tout le temps.

Sinon, il va te falloir un écran spécifique et une table spécifique et un truc du genre :

Voullez-vous voter blanc ?

Si oui, ouvrir écran vote blanc.
Si non, écran vote non blanc.

Si tu veux garder les votes attentions, la préservation du secret est délicate ET primordiale.

Actuellement, je crois que le système de vote en ligne utilise une double indirection.

1. Le votant se voit attribuer un numéro.
2. Puis ce numéro se fait attribuer un autre numéro unique (aléatoirement à mon avis car sinon on pourrait déduire le vote de l'ordre dans lequel il a été créé).
   Cette association n'est faite qu'en mémoire au moment du traitement et n'est pas enregistrée.
3. On note que numéro votant a voté (pour éviter un double vote)
4. on notre le nouveau numéro unique et le vote associé.

Comme cela il devient quasiment impossible de savoir qui a voté pour qui (sauf à surveiller la mémoire de l'ordinateur).
Note que le votant ne peut pas revenir pour vérifier pour qui il a voté, seulement qu'il a voté.

Pour les votes par liste, il suffit de créer un vote pour chacun des candidats.

A+

[DamKre]

Tout cela alimente ma réflexion.

Reste la construction des tables...
Est-ce qu'il est alors intéressant de partir sur des relations "classiques" :

• T_Elections
  -Id_Election
  
  • T_Listes_
    -Id_Liste
    -Id_Election
    
    • T_Candidats
      -Id_Candidat
      -Id_Liste

Ou autre chose ?
Cela étant, je vais peut-être chercher une difficulté là où la logique....

Merci et @+

[marot_r]

Je suis d'accord.

Il te faut aussi une table des villes et une table d'association des villes et des listes.

Et un type d'élection (avec une table des types d'élection).

Et si tu veux garder des votes individuel une table des électeurs évidement.

Envisages-tu la notion de "tour" ?
Cela pourrait simplement être un champ dans la table Election si tu assignes toi-même l'identifiant d'élection.

Si on est strict, cela devrait être:

tblElection

tblTour
ClefElection
ClefTour

tblListeTour
ClefElection
ClefTour
ClefListe

Et ainsi de suite.

L'assignation manuelle de l'Identifiant d'élection me paraît plus simple.
Il n'y a pas tant d'élection que cela et cela évite une table sans grand intérêt.

A+

[DamKre]

Re ;-)

Il te faut aussi une table des villes et une table d'association des villes et des listes.

Donc, une "TJ_Assoc_VilleListes" avec Clé Ville + Clé Liste ?
La table des villes était d'office prévue ;-)

Et un type d'élection (avec une table des types d'élection).

Est-ce réellement nécessaire avec uniquement deux types d'élections ? Un champ "liste" avec les deux types n'est-il pas au final suffisant ?

Et si tu veux garder des votes individuel une table des électeurs évidement.

Et dès lors, dans cette table, un champ qui reprend son vote.

Envisages-tu la notion de "tour" ?
Cela pourrait simplement être un champ dans la table Election si tu assignes toi-même l'identifiant d'élection.

Non, du tout : on ne ferait qu'un seul tour ( c'est un système plus en vigueur en Belgique qu'en France, par exemple ).

@+

[marot_r]

Bonjour.

Est-ce réellement nécessaire avec uniquement deux types d'élections ? Un champ "liste" avec les deux types n'est-il pas au final suffisant ?

Je suis, je le reconnais, un peu maniaque en matière de table :-), une liste peut suffire.

Non, du tout : on ne ferait qu'un seul tour ( c'est un système plus en vigueur en Belgique qu'en France, par exemple ).

Désolé, j'avais supposé le système belge semblable au système français.

Pour le reste, il me semble que le modèle tient la route.

A+

[DamKre]

Merci pour toutes ces informations ;-)

En ce qui concerne la gestion des résultats, que penser d'un champ "Nombre de voix" pour chaque liste et pour chaque candidat ( valeur par défaut = 0 ) ?
Il est important que, dans l'impression des résultats, on puisse voir que le candidat X n'a récolté aucune voix ou que la liste L n'en a récolté aucune ( même si ses candidats en ont reçu )...

@+

[marot_r]

Il est important que, dans l'impression des résultats, on puisse voir que le candidat X n'a récolté aucune voix ou que la liste L n'en a récolté aucune ( même si ses candidats en ont reçu )...

`
En effet, avec cette précision il devient important de gérer les listes et les candidats séparément.
Ou alors considérer la liste comme un candidat particulier (clefListe, "M/Mme Tous LES CANDIDATS"), un peu comme le vote blanc.

A+

[DamKre]

Merci de toutes ces informations ;-)